{
  "subjectSha": "6ac56de2",
  "modelId": "claude-opus-5",
  "promptTemplateVersion": "jt-v1",
  "rung": "R1",
  "templateHash": "7f974b9ad9f6955462b4da1586cd3ebd8f6e47b371b48483fc3906609d0160bf",
  "docHash": "075f98b785e3a1828ab0c130cd713d797e259abee258eb00b6fa12062153fcc4",
  "sampleId": "observe/oneshot-plan",
  "iteration": 4,
  "appendCost": 5,
  "unitsToModify": [
    "✅ 执行状态（2026-08-31 收尾回填）",
    "File Structure",
    "🔴 预注册（Task 1 里写死进源码，先 commit 再跑）",
    "Task 5: status 登记 + 收尾",
    "Self-Review（写完计划后自查，已执行）"
  ],
  "wallMs": 48923,
  "exitCode": 0,
  "raw": "**条目类型判定**：这份文档登记/组织的单元是 **Task**（Task 1–5，`- [ ]` 步骤块）。新增一个同类条目 = 新增一个 Task。\n\n为让新 Task 完整生效，必须改动的既有部分：\n\n1. **`## ✅ 执行状态（2026-08-31 收尾回填）`** —— 表内每 Task 一行（含「Task / 状态 / 实际产出·偏差」），新 Task 必须在此表加行；表头上方那句「**全部 Task 已执行完毕**」的总述也随之失真。\n2. **`## File Structure`** —— Create / Modify 文件清单是按文件横切写的（不是按 Task 分块），新 Task 涉及的文件要插进这份既有清单。\n3. **`## 🔴 预注册（Task 1 里写死进源码，先 commit 再跑）`** —— `PREREG` 是单个全局常量块；新 Task 若有任何预注册量，只能改这个已存在的块。该节末尾的「🔴 探针撞出的两条，**必须进 Task 2 与 Task 4**」按任务号点名，任务集合变动时要一起改。\n4. **`## Task 5: status 登记 + 收尾`** —— 该 Task 是全局收尾（`git status` 确认干净 + push + work-log + N81 登记），位置固定在末尾；新 Task 追加在其后会使收尾先于新工作执行，须改动其内容或位置（若插在中间，Task 3/4/5 的编号及正文里的编号引用也要改）。\n5. **`## Self-Review（写完计划后自查，已执行）`** —— 第 1 项「Spec 覆盖」是 spec 条目 → Task 编号的映射表；第 3 项「类型一致性」逐字点名 `Task 1 Step 3/4 与 Task 2 Step 3/5/6` 的跨任务字段；第 4 项风险指向 `Task 3 Step 1`。新增 Task 后这三项都要重写。\n\n另有两处随内容而定、非必然：`**Architecture:**`（若新 Task 引入第二个量具文件，该段现描述「新增唯一文件」）、`## Global Constraints`（若新 Task 引入新纪律）。\n\n若把「条目」理解为 Task 2 内的一条**控制**（`must-hit` / `must-not-hit`），则必改：Task 2 Step 8 的 commit message（写死「9 条控制」）、Task 2 Step 1 的两臂说明所属编号序列（`must-hit-0..8` 连号）、以及 Self-Review 第 3 项。\n\n```json\n{\"unitsToModify\": [\"✅ 执行状态（2026-08-31 收尾回填）\", \"File Structure\", \"🔴 预注册（Task 1 里写死进源码，先 commit 再跑）\", \"Task 5: status 登记 + 收尾\", \"Self-Review（写完计划后自查，已执行）\"], \"appendCost\": 5}\n```"
}