# SOP：每轮开工

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

## 步骤

1. **确认位置**

   ```bash
   pwd    # 应为项目根目录
   ```

2. **读状态**（按顺序）

   - `harness/progress.md` — 「当前已验证状态」一节 + 最后一条 session 记录
   - `harness/feature_list.json` — 哪些是 `passing`、哪些 `not_started`、哪些 `blocked`

3. **看最近提交**

   ```bash
   git log --oneline -5
   ```

4. **跑基础验证**

   ```bash
   bash harness/init.sh
   ```

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

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

   ```bash
   node harness/tools/validate-harness.mjs
   ```

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

5. **选一件事做**

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

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

## 别做的事

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

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

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