SOP：每轮开工

目标：不要靠记忆开工。上一轮的状态、还挂着什么、下一步做什么，全在仓库里。

步骤

确认位置
```
pwd    # 应为项目根目录
```
读状态（按顺序）
- harness/progress.md — 「当前已验证状态」一节 + 最后一条 session 记录
- harness/feature_list.json — 哪些是 passing、哪些 not_started、哪些 blocked
看最近提交
```
git log --oneline -5
```
跑基础验证
```
bash harness/init.sh
```

验证失败就先修基础状态，不要在坏的基础上叠新功能。

4b. 校验 harness 结构（很快，别省）

   node harness/tools/validate-harness.mjs

它会检查必备文件、游离的计划文件、feature_list.json 的假 passing / 多个 in_progress、progress.md 的会话编号重复。退出码非 0 就先修它。

选一件事做

只选一个未完成功能，围绕它工作，直到：

验证通过（并把证据写进 progress.md 与 feature_list.json），或
被明确记为 blocked（写清阻塞原因和需要谁决定什么）

别做的事

不要一次开多个功能 —— 半成品是最常见的翻车形态
不要跳过第 4 步 —— 构建挂着的状态下改代码，问题会叠在一起分不清
不要凭记忆开工 —— 想不起来上轮做到哪，就说明该看文件了

这个项目的已知坑（开工前扫一眼）

界面样式必须与原版一致；既有 UI 的可选项、文案、筛选逻辑不要擅自改动
新协议能力走适配层翻译成内容标记，不要新建带自有样式的 UI 组件
src/components/stream-message-coordinator.ts 是保留的旧协议实现，不要动
排查协议问题必须读原始 SSE 载荷（见 sops/verification.md）