yangxuan/openclaw-config
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7a5ca9f1a72e17f1ad8d3ac1775cf85f0dc2ece9
openclaw-config/workspace-resume/memory/2026-08-27.md
T

7.7 KiB
Raw Blame History

2026-08-27

6-7月周报缺失补全（eml 解析归档）

背景

用户发现 6-7 月周报记录缺失（2026 目录中 W23-W26 是占位/示例内容，W29-W31 部分旧格式）。用户从钉邮下载了周报邮件 eml 文件补全。

完成的工作

  1. 定位 eml：附件上传后自动落盘在 /home/yangxuan/.openclaw/media/inbound/*.eml，共 12 封（含 W23 那封）
  2. 编写解析工具：
    • weekly-reports/parse_eml_to_md.py：解码 multipart 邮件的 text/plain base64 正文 → 生成标准格式 2026/2026-Www-周报.md
    • weekly-reports/import_md_to_db.py：读 Markdown → 全量重建 SQLite（主表+每日明细+问题），覆盖旧占位
  3. 归档结果：12 份周报全部生成并入库，归档文件与数据库一一对应（校验 ✅）

归档的周报（2026）

  • 6 月：W23(极简app) W24(库存缺陷修复) W25(主数据) W26(库存需求) W27(版本发布支撑)
  • 7 月：W28(消息通知功能) W29(库存出库缺陷修复) W30(主数据页面) W31(G6 委外发料)
  • 8 月：W32(G6 工程配置) W33(销售管理) W34(G6 销售采购)

关键经验 / 坑

  • eml 列表项 * 与文字常被拆成两行，需整行归入当日明细
  • 日期行有 周一（2026-06-08）（带年）和 周一（06-08）（不带年）两种，还有 📅 emoji 前缀
  • 「存在问题」区：无/暂无 不算问题；下周计划 等小标题需退出问题区，但正文字段如「本周部分...」不能误判（正则要收紧）
  • 项目名据内容自动判 G5/G6，标题随之动态
  • 数据库有历史孤儿问题记录（report_id 无对应主表），需清理
  • 旧格式 2026-W29.md 与标准 2026-W29-周报.md 重复，待用户确认是否清理

待办

  • 旧 2026-W29.md 去留（同 W29-周报 内容重复），已移入回收站
  • 清理 media/inbound 下已处理的 12 封周报 eml，已移入回收站
  • eml-archive/ 目录：核实全部 50 份历史周报在 weekly-reports 均有副本（零缺失），属迁移后遗留冗余，已移入回收站

技能文档更新 & 归档链路盘点（10:44）

  • 更新 skills/weekly-report/SKILL.md：补全第 5 步「自动归档」——说明 send_to_drafts() 默认 archive=True，存草稿箱后自动归档 Markdown 到 weekly-reports/YYYY/YYYY-Www-周报.md；但脚本本身不写 SQLite，入库需手动 sync_reports_db.py / import_md_to_db.py；命令行 --no-archive 可跳过；原「最后通知」改序号为 6
  • 修正 TOOLS.md & MEMORY.md 不准确描述：原写 send_weekly_report.py 会「同步元数据到 db」——实际脚本不写库，已改为如实说明

归档操作全景（已盘点）

  1. send_weekly_report.py（生成周报时）→ archive_report() 只写 md，不入库
  2. parse_eml_to_md.py + import_md_to_db.py（本次新加）→ eml→md→db 全链
  3. sync_reports_db.py / sync_reports_to_db.py（备用）→ md→db 同步
  4. migrate_legacy_reports.py → 旧 txt→md 迁移
  5. cron「周五周报发送检查」 → 只查草稿箱，不归档
  • 结论：归档链路完整，但 send_weekly_report.py 生成周报后不会自动入库数据库，需手动 sync

MySQL 周报数据中枢（方案 A）建立（10:45-10:55）

  • 背景：用户备有本地 MySQL resume 库（简历业务库），问为何用 SQLite。确认方案 A：SQLite 做本地归档，MySQL 做统一数据中枢（月度/年度/OKR 取数）
  • 在 resume 库建 3 张周报表：weekly_reports（主）、weekly_report_daily（明细）、weekly_report_problems（问题），外键 report_id 级联
  • 撰写 weekly-reports/migrate_to_mysql.py：SQLite → MySQL 全量迁移（--dry-run 预览）
  • 迁移 12 份核心周报（2026-W23~W34，G5×9+G6×3），明细 60 条、问题 1 条，SQLite↔MySQL 字节级一致（HEX 对比 0 不一致）
  • send_weekly_report.py 加 MySQL 同步：新增 sync_to_mysql()/_parse_plain_for_db()，send_to_drafts() 默认 sync_mysql=True，命令行 --no-mysql 跳过；已用测试数据验证写入正常后清理
  • 文档更新：SKILL.md（自动归档章节加 MySQL 同步）、TOOLS.md（新增 MySQL 中枢小节）、MEMORY.md（新增方案 A 章节）
  • 用户决策：只迁高质量核心数据（39 份叙述式 txt 不迁）；OKR 后续再处理

OKR 1月绩效归档（11:00）

  • 用户提供 研究院-维云智造G5-1月OKR-杨轩.xlsx，要求解析归档 202601（方案 A：入库 MySQL resume）
  • 在 resume 库建 2 张 OKR 表：okr_monthly_records（主）+ okr_objectives（目标明细外键级联）
  • 撰写 okr/parse_okr_to_mysql.py（读 Excel sheet → 写 MySQL；--month/--dry-run）
  • 已归档 202601 杨轩：6 项目标、月度评价 7.0、权重 0.15/0.2/0.15/0.1/0.2/0.2
  • Excel 特点：一文件多 sheet（202511/202512/202601/实施总监/Sheet1），实为 3 个月数据；用户只要 202601
  • 文档：MEMORY.md、TOOLS.md 已更新

OKR 8月新模板归档（11:01）

  • 用户提供 研究院-产品开发部开发组-8月OKR-杨轩.xlsx，提示“8月换了模版”
  • 新模板差异：单 sheet OKR考核（旧模板多 sheet）；表头行5-6（旧行4）；目标行8起跳过示例行7，5 项（旧 6 项行5-10）；列位变（旧E/KR→新D/KR，旧F/完成→新E/完成，评分新在G）；人员信息在 B3（旧B2）；跨月周期“7月27日-8月27日”取考核期末→202608
  • 扩展 parse_okr_to_mysql.py：新增 detect_template()/parse_sheet_new()/parse_sheet_old()，自动识别新旧模板
  • 已归档 202608 杨轩：5 项目标（权重 0.5/0.25/0.1/0.1/0.05，评分均7），月度评价字段上级未填→NULL（I13 的 1 是“月度工作补充”得分非月度评价，已修正不误取）
  • 与 202601 并存于 okr_monthly_records（id 1、2）
  • 文档：TOOLS.md、MEMORY.md 已更新

OKR 2-7月批量归档（11:04）

  • 用户提供 研究院-维云智造G5-7月OKR-杨轩.xlsx（旧模板，含多个考核月 sheet），要求归档 2-7 月
  • 扩展 parse_okr_to_mysql.py：重构为 process_sheet() 批量模式，支持 --month 202602-202607（范围）、逗号分隔、单个月份
  • 已归档 202602~202607：每月 6 项目标、月度评价均 7.0
  • 至此 MySQL 里 OKR 完整：202601~202608 共 8 个月、47 项目标

上半年自我诊断分析（11:06-11:08，仅对话未保存）

  • 用户要求“先分析汇总上半年工作，防止年底才暴露问题”，输出自我诊断问题清单 + 工作重心分布，打印到对话、不保存
  • 工作重心演进：1-3月主数据/经销存/销售 → 4月库存爆发(app扫码入库28项) → 5月OpenAPI+大规模重构(740行→50行) → 6月库存预警/MRP/物料转换
  • 要点发现：
    • 🔴 目标3(质量bug)1-6月每月同一模板话术，无量化 → 质量无法证明
    • 🔴 3-6月每月加班8次（2月5次），无产出关联说明
    • 🟡 1-2月“未产生概要设计”，3月起才留方案文档
    • 🟡 上半年大量字段/打印/导出等优化杂活，新功能占比偏低
    • 🟡 6月密集历史技术债修复（MRP预留/汇率/空指针），存量债未系统性治理
    • ✅ 亮点：架构重构能力、跨模块广度、复杂业务扎实
  • 已给 4 条行动建议：数字化记录质量/加班/缺陷、补量化证据、评估杂活分担、推动技术债整改清单

清理说明（回收站）

  • 无系统 trash 命令，改用 mv 移到 ~/.local/share/Trash/files/（可恢复）
  • 移入对象：12 封周报 eml + 2026-W29.md + eml-archive/ 目录，共 14 个
  • inbound 内其他非周报文件（账单/证明/PDF/PBS 文档等）保留未动
  • 数据库 12 份周报完整，未受影响
Reference in New Issue View Git Blame Copy Permalink