zhaoshang_client_ui/harness/sops/session-end.md

收尾检查清单

每次会话结束前过一遍，确保仓库处于下一轮可以直接开工的状态。 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/）
• 做完的计划已归档 —— 已实现的计划从 active/ 移到 completed/， 并把状态头改成实际结果（未做的验证要显式写「未做」，不要含糊过去）。 校验器会检查这条，但别等它报错才做

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

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

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

# 若 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	违反了单功能纪律，收敛到一个
靠改写清单让状态变好看	掩盖未完成工作，比不写更糟
在坏的基础上继续叠新功能	先修基础状态