93 lines
7.7 KiB
Markdown
93 lines
7.7 KiB
Markdown
# 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` 重复，待用户确认是否清理
|
||
|
||
### 待办
|
||
- [x] 旧 `2026-W29.md` 去留（同 W29-周报 内容重复），已移入回收站
|
||
- [x] 清理 `media/inbound` 下已处理的 12 封周报 eml，已移入回收站
|
||
- [x] `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 份周报完整，未受影响
|