# 收尾检查清单

> 每次会话结束前过一遍，确保仓库处于**下一轮可以直接开工**的状态。
> agent 的收尾流程里也应当包含这些检查。

## 逐项检查

- [ ] **已提交并推送** —— 每次改动完成就该提交（不攒、也不留给用户手动提交）：
      `git add -A && git commit -m "..." && git push origin main`
- [ ] **标准启动路径还能用** —— `npm run dev` 能起在 8083，页面能打开
- [ ] **标准验证还能跑** —— `npm run build` 通过（不是"上次通过"，是这次跑过）
- [ ] **进度日志已更新** —— `harness/progress.md` 追加了本轮 session 记录
- [ ] **功能清单真实反映状态** —— `feature_list.json` 里
      - `passing` 的项都有 verification + evidence，没有**假 passing**
      - 同一时间只有一个 `in_progress`（没有的话，下一个重点应写在进度日志里）
      - `blocked` 的项写清了阻塞原因和需要的决策
- [ ] **没有半成品处于未记录状态** —— 做了一半的东西要么记进清单，要么回退
- [ ] **未验证的内容已显式记录** —— 没跑过的、只在特定条件下跑过的，写清楚
- [ ] **下一轮不需要人工修复就能继续** —— 新会话只靠仓库内文件就能接上
- [ ] **没有把待办塞进聊天就结束** —— 仓库内文件才是唯一事实来源
- [ ] **跑过结构校验** —— `node harness/tools/validate-harness.mjs` 退出码为 0
- [ ] **计划类文件在仓库里** —— 本轮的方案/计划写进了 `harness/docs/exec-plans/`，
      而不是只存在于聊天、或工具自带的仓库外计划目录（`~/.claude/plans/`）

## 最常见的漏项：记录比改动旧

**每次改动完成后就该更新记录，不要攒到会话结束。** 一轮会话常含多次改动，
攒到最后必然漏记；更隐蔽的是**已写下的描述会过期**（真实发生过：一次改动没记，
记录里还留着后来被推翻的旧结论，下一轮会话读到的是错的）。

自查方法：比对文件修改时间。

```bash
# 若 harness 文件的修改时间早于其它源文件，很可能有改动没被记录
ls -lt --time-style=+%H:%M:%S CLAUDE.md harness/progress.md harness/feature_list.json \n  src/components/api-chat-coordinator.ts | head
```

## 本项目的额外检查

- [ ] **没有擅自改动界面样式** —— 既有 UI 的样式、可选项、文案、筛选逻辑都应保持原样；
      确需新增时先取得确认
- [ ] **协议层改动没有破坏原渲染路径** —— 新协议内容仍通过适配层翻译成
      `<scope>` / `<!-- POLICY_TABLE -->` / `<ref_links>` / `<question-cards>`，
      渲染组件（BusinessRecord / PolicyMatch / QuestionCard / ScopeContent）未被改写
- [ ] **`stream-message-coordinator.ts` 仍未被改动** —— 它是保留的旧协议实现；确需改动需先说明理由
- [ ] **验证用了真实后端** —— 涉及接口的改动，除构建通过外，应对 `http://192.168.2.23:8000` 实测；
      后端不可达时要在记录里写明"本轮只做了静态验证"

## 常见红灯

| 现象 | 意味着 |
|---|---|
| "构建通过"但没跑过接口 | 只证明了能编译，没证明行为对 |
| 清单里 `passing` 却没有 evidence | 假 passing，必须降级 |
| 同一时间多个 `in_progress` | 违反了单功能纪律，收敛到一个 |
| 靠改写清单让状态变好看 | 掩盖未完成工作，比不写更糟 |
| 在坏的基础上继续叠新功能 | 先修基础状态 |