Green Baseline Before Asset Switch
当一个 agent 连续几轮修测试、lint 或格式问题时，最后一轮不要再机械加覆盖率；先把项目拉回一条可复核的 green baseline，再切换到更有资产价值的写作、技能或收入实验。
适用场景
- 上一轮刚修完 lint、format、test、build 里的某个红灯。
- 当前 repo 启动时是 clean，或者本轮能只提交自己明确相关的文件。
- 候选任务里既有“继续打磨同一区域”，也有“转向文档、书稿、技能、收入实验”。
- 项目已经有聚合命令，例如
npm run validate、pnpm test、make ci、just check。
原则
先证明“现在能交付”，再决定“下一步做什么”。
这条规则避免两种漂移：
- 修复漂移：连续围绕同一批测试文件做微调，产出越来越小。
- 资产漂移：项目其实还没恢复可交付，却急着写总结或包装方法论。
30 分钟执行卡
| 步骤 | 动作 | 产出 |
|---|---|---|
| 1 | 记录启动状态：git status --short --branch | 确认哪些 dirty path 不是本轮所有 |
| 2 | 找项目级入口：优先 package/script 里的 validate、check、ci | 避免只跑局部测试造成假绿 |
| 3 | 跑聚合验证命令 | 得到真实通过/失败输出 |
| 4 | 若失败，只修最小、明确、可验证的红灯 | 一次只接管本轮相关文件 |
| 5 | 若通过，停止在同一区域机械扩展 | 下一轮转向更高价值资产 |
| 6 | 在 notebook 中写清验证命令、结果和下一段接力点 | 让后续 agent 能复核与接力 |
决策表
| 结果 | 本轮动作 | 下一段建议 |
|---|---|---|
| 聚合验证通过且无代码变化 | 不提交项目代码；记录 green baseline | 切换到教程、书稿、技能、收入实验准备 |
| 聚合验证因本轮附近问题失败 | 修最小红灯并重跑聚合验证 | 提交修复，下一段再判断是否切换 |
| 聚合验证因既有、归属不清问题失败 | 不接管脏文件；记录失败边界 | 留下具体命令和错误摘要，等待授权或独立任务 |
| 没有聚合验证命令 | 组合 lint/test/build 的最小替代链 | 可新增一张“验证入口漂移”卡 |
报告模板
- 实际推进：在 `project/` 跑项目级验证入口，确认 lint/format/test/build 全部通过；没有继续机械修改同一区域。
- 变更文件：无（或列出本轮明确相关文件）。
- 验证方式：`npm run validate`，输出 lint、format、test、build 全部通过。
- 后续接力：下一段优先转向 `docs/...`、`books/...` 或 `skills/skills/...` 的资产化任务。反例
- 只跑一个目标测试就宣布项目健康。
- 明知 workspace 有用户脏文件，却用
git add .混入提交。 - 聚合验证已经通过，还继续给同一模块补低价值测试，只为了“本轮看起来有代码改动”。
- 把 notebook 更新当成本轮主要成果，而没有形成可复核的项目状态或资产增量。