Jesse_ChenandClaude Fable 5
40387ff9c7
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016P5RoqzmUQEbeC2qjAkeGr
54 lines
3.9 KiB
Markdown
54 lines
3.9 KiB
Markdown
# 任务书 · BUG-535 修复：文档 charts 上限未随 CHART_IDS 扩容（2026-09-04）
|
||
|
||
基线：`origin/staging` @ `e674cd38`（开工时 `git fetch` 后以 `origin/staging` HEAD 为准）。
|
||
|
||
## 事故实证
|
||
|
||
- staging request `20c94bf4`：五章正文全部 ready（narrative 757–1960 字、telemetry 全 stop、回溯通过），装配后终稿校验拒绝 → `report_schema_invalid / final_parse_rejected`（BUG-535）。
|
||
- 委托方本地在 `origin/staging` 最新代码上**确定性复现并闭环验证**（真实引擎 + schema 合规假 writer + 内存 sectionService，无模型依赖）：
|
||
- 5 主题（career/marriage/timing/wealth/health）→ `PIPELINE-FAILED final_parse_rejected`，与 staging 一致；
|
||
- 把 `personal-report-contract.ts` 的 `charts: z.array(reportDocumentV2ChartSchema).min(1).max(6)` 改为 `.max(CHART_IDS.length)` 后，同一管线 → **`PIPELINE-READY sections=5`**；
|
||
- 4 主题（不含 health）在未修复代码上一直 READY——解释了为什么此前四主题复现从未触发。
|
||
|
||
## 根因
|
||
|
||
`c2f23131`（health pipeline，09-03 上游同步）把 `CHART_IDS` 从 6 个（D1/D2/D9/D10/D11/D24）扩成 **9 个**（新增 D6/D8/D30，health 主题 `chartIds: ["D1","D6","D8","D30"]`），`DOCUMENT_VARGA_CHART_IDS` 同步扩到 8 张分盘；但文档 v2 合同的 **`charts.max(6)` 没有跟着改**。在分盘提取修好（blocked-repairs 轮）之后，5 主题 bundle 的 charts = D1+D2+D6+D8+D9+D10+D11+D24+D30 = 9 张 > 6 → `safeParseServerReportDocument` 拒绝。此前分盘提取是坏的，永远凑不满 6 张，所以这个半拉子改动一直没被触发。
|
||
|
||
## 硬红线
|
||
|
||
1. **只许放宽这一个"计数上限"**，且必须改成与 `CHART_IDS.length` 绑定（单一真源，防止下次扩枚举再脱节），不得写裸数字 9。任何**字段级内容校验**（长度、枚举、正则、evidenceRefs 绑定）一律不得放宽。
|
||
2. v1 文档合同（`REPORT_DOCUMENT_V1_CHART_IDS` 3 张、`charts.max(3)` 类）不动。
|
||
3. 顺带核对：grep `CHART_IDS` / `DOCUMENT_VARGA_CHART_IDS` 的**全部消费点**，找出其它随枚举硬编码的计数（bundle schema、按章过滤、UI 渲染、导出），有同类脱节一并对齐并逐条列进 PROGRESS；没有就写明核对结论。
|
||
4. 既有其余红线延续（不改 `.gitea/workflows/**`、不提升 main、`./node_modules/.bin/tsc`、隐私日志边界）。
|
||
|
||
## 任务
|
||
|
||
### 任务 1（P0）· 上限绑定 + 回归测试
|
||
|
||
- `charts.max(CHART_IDS.length)`（v2）；红线 3 的消费点核对。
|
||
- 回归测试：9 张图（全枚举）的文档过 `safeParseServerReportDocument`；5 主题（含 health）装配 fixture 走全管线 READY；4 主题不回归。
|
||
|
||
### 任务 2（P0）· 终稿校验失败可观测
|
||
|
||
BUG-535 取证难的根源是日志没有 parse 明细。`final_parse_rejected` 时把 zod error 的 **path 列表**（只有字段路径与 message 代号，不含任何值/正文）写进 `generation_failed` 日志。测试锁：日志包含 path、不含文档内容。
|
||
|
||
### 任务 3（P0）· 部署后真实收口
|
||
|
||
health SHA 对齐后真实生成 standard personal_full（5 主题）：报告 **ready 可打开**、五章正文、blocked 披露为空；BUG-535 收口（修复版本、验证、与 c2f23131 关联）。每章实测 tokens/墙钟继续如实记录（成本裁决另行处理，不在本单）。
|
||
|
||
## 不在本轮范围
|
||
|
||
- 成本（5.22× 实测的处置由产品另行裁决）；writer 合同；知识包；上游同步修复单其余项。
|
||
|
||
## 收尾
|
||
|
||
`docs/tasks/PROGRESS-report-chart-cap-20260904.md`；`docs/BUG_HISTORY.md` BUG-535 收口；推送后核对 health `.deployment.gitCommit`；不提升 main。
|
||
|
||
## 交付物清单
|
||
|
||
1. 上限绑定 diff + 枚举消费点核对清单
|
||
2. 回归测试（9 图文档 / 5 主题 READY / 4 主题不回归）
|
||
3. final parse 失败的 path 级日志 + 测试
|
||
4. 部署后真实报告 ready 截图或 JSON + BUG-535 收口
|
||
5. 全套质量门实际输出 + PROGRESS
|