@zmice/zc 0.2.8 → 0.3.0

package/vendor/packages/toolkit/src/content/skills/planning-and-task-breakdown/body.md

@@ -1,83 +1,162 @@
-# 规划与任务拆解
-
-## 何时使用
-
-- 已有规格，需要拆成可执行单元
-- 任务太大、太模糊或依赖顺序不明显
-- 需要并行推进多个切片
-- 需要向人类清楚表达范围、风险和检查点
-
-不适用于单文件且边界显而易见的小改动。
-
-## 输入前提
-
-- 已有规格，或至少有清楚的问题定义
-- 已读相关代码并识别主要约束
-- 愿意在规划阶段保持只读，不边做边改
-
-## 执行步骤
-
-1. 进入只读分析模式，先看规格和现有代码
-2. 识别依赖图，确定哪些必须先做
-3. 优先做纵向切片，而不是按数据库、API、UI 横向分层
-4. 为每个任务写清：
-   - 描述
-   - Acceptance criteria
-   - Verification
-   - Dependencies
-   - Files likely touched
-5. 排出顺序，并设置阶段性检查点
-
-## 提问纪律
-
-- 能从规格、代码、配置、测试或用户原话判断的，不问。
-- 只有缺失信息会改变架构、数据模型、任务顺序、破坏性操作或并行边界时才问。
-- 一轮最多问 1-3 个关键问题，问题要说明选择会避免什么风险或解锁什么能力。
-- 用户已经给出偏好时，把它写进计划假设；不要把偏好扩展成长期配置或跨会话记忆授权。
-
-## 计划产物要求
-
-计划不是任务名列表，至少要包含：
-
-- `decision log`：关键取舍和采用原因
-- `evidence`：读取过的规格、代码、配置、测试或上游证据
-- `open risks`：尚未证明的风险和验证方式
-- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否需要 `zc team plan`
-- `fan-in gate`：实现后如何合流、审查、验证和清理
-
-## 决策日志格式
-
-每个关键取舍都要写成可审查的推荐，而不是只写“建议这样做”：
-
-```text
-Recommendation: <chosen action> because <evidence and trade-off>.
-- Chosen:
-- Rejected alternative:
-- Evidence:
-- Cost / risk:
-- Verification gate:
-```
-
-理由必须说明被放弃的替代方案，以及当前选择为什么更适合本任务。不能只写“更稳”“更简单”“更符合最佳实践”。
-
-## 成功标准
-
-- 每个任务都能独立实现、测试和验证
-- 任务粒度足够小，不会一次触碰过多文件
-- 依赖顺序和可并行项是显式的
-- 人类看完计划后能明确判断“方案对不对”
-- 计划中的问题和风险都能落到后续验证命令或审查项
-- 并行任务必须有明确文件所有权或隔离理由
-
-## 相关原则
-
-- 计划服务实现，不是形式化文档
-- 先控制复杂度，再讨论并行度
-- 任务必须能验证，不能只写动作名
-- 计划阶段发现的问题要进入计划本身，不能只留在聊天里
-
-## 与其他技能的衔接
-
-- 接在 `spec-driven-development` 之后
-- 计划确认后交给 `incremental-implementation`
-- 涉及方案争议时，可搭配 `multi-perspective-review`
+# 规划与任务拆解
+
+## 何时使用
+
+- 已有规格，需要拆成可执行单元
+- 任务太大、太模糊或依赖顺序不明显
+- 需要并行推进多个切片
+- 需要向人类清楚表达范围、风险和检查点
+
+不适用于单文件且边界显而易见的小改动。
+
+## 输入前提
+
+- 已有规格，或至少有清楚的问题定义
+- 已读相关代码并识别主要约束
+- 愿意在规划阶段保持只读，不边做边改
+
+## 执行步骤
+
+1. 进入只读分析模式，先看规格和现有代码
+2. 识别依赖图，确定哪些必须先做
+3. 优先做纵向切片，而不是按数据库、API、UI 横向分层
+4. 为每个任务写清：
+   - 描述
+   - Acceptance criteria
+   - Verification
+   - Dependencies
+   - Files likely touched
+5. 排出顺序，并设置阶段性检查点
+6. 如果发现会改变计划路线的阻塞问题，先进入 `stop gate`，不要把问题静默写进计划后继续推进
+
+## 提问纪律
+
+- 能从规格、代码、配置、测试或用户原话判断的，不问。
+- 只有缺失信息会改变架构、数据模型、任务顺序、破坏性操作或并行边界时才问。
+- 一轮最多问 1-3 个关键问题，问题要说明选择会避免什么风险或解锁什么能力。
+- 用户已经给出偏好时，把它写进计划假设；不要把偏好扩展成长期配置或跨会话记忆授权。
+
+## 计划产物要求
+
+计划不是任务名列表，至少要包含：
+
+- `decision log`：关键取舍和采用原因
+- `evidence`：读取过的规格、代码、配置、测试或上游证据
+- `open risks`：尚未证明的风险和验证方式
+- `stop gates`：会改变架构、数据模型、破坏性边界、并行边界或验收口径的阻塞决策
+- `agent_opportunity`：本计划是否需要只读协助、串行子代理、上下文级并行或 `zc team`
+- `fan-out eligibility`：是否能并行、按哪些文件或模块拆、是否有确认边界、是否需要 `zc team plan`
+- `fan-in gate`：实现后如何合流、审查、回归、验证和清理
+- `implementation tasks`：从计划或评审发现转化来的可执行任务列表
+
+## 决策日志格式
+
+每个关键取舍都要写成可审查的推荐，而不是只写“建议这样做”：
+
+```text
+Recommendation: <chosen action> because <evidence and trade-off>.
+- Chosen:
+- Rejected alternative:
+- Evidence:
+- Cost / risk:
+- Verification gate:
+```
+
+理由必须说明被放弃的替代方案，以及当前选择为什么更适合本任务。不能只写“更稳”“更简单”“更符合最佳实践”。
+
+## Stop Gate
+
+以下发现必须先停下来收敛，不允许直接写进计划然后继续：
+
+- 现有证据推翻了原始目标或核心假设
+- 任务顺序、数据模型、权限边界、破坏性操作或并行边界需要重新选择
+- 评审发现如果不处理会导致后续实现返工
+- 缺少验证方式，导致任务无法判断完成
+
+Stop gate 输出格式：
+
+```text
+STOP: <阻塞发现>
+- Evidence:
+- Impact:
+- Options:
+- Recommendation:
+- Required decision:
+```
+
+只有用户已经给出明确偏好，或仓库证据能支持保守路线时，才把 `Required decision` 写成显式假设并继续；否则先问。
+
+## Implementation Tasks
+
+从计划或评审发现生成任务时，统一使用这个可执行格式：
+
+```text
+- [ ] T1 (P1) — <component> — <imperative title>
+  - Source finding:
+  - Files likely touched:
+  - Acceptance criteria:
+  - Verification:
+  - Dependencies:
+```
+
+规则：
+
+- `P1`：阻塞当前交付，必须本轮处理
+- `P2`：应在同一分支处理，否则会留下明显质量缺口
+- `P3`：可延后的跟进项，必须说明为什么不阻塞当前目标
+- 每个任务必须来自具体发现、需求或证据；不能为了填表新增空任务
+- 任务标题用动作开头，能直接交给实现阶段
+
+## Agent Opportunity
+
+计划阶段必须给出明确的多 agent 结论，而不是只写“可并行”：
+
+```text
+agent_opportunity:
+- mode: none | readonly-consult | serial-subagent | context-fanout | zc-team
+- trigger:
+- recommended agents/workers:
+- ownership:
+- confirmation:
+- fan-in gate:
+```
+
+判断规则：
+
+- `readonly-consult`：适合架构、测试、安全、性能、产品或审查侧评；用户已授权只读 agent 默认启用时通知式启动，否则先预告并等待确认，不能改文件。
+- `serial-subagent`：任务独立但存在依赖顺序，主线程逐个委派并 fan-in。
+- `context-fanout`：任务可按文件、模块或证据问题拆开，写入前必须确认文件所有权。
+- `zc-team`：只有用户明确要求或确认，且 `zc team plan` 返回可启动时才进入。
+- `none`：任务简单、强耦合、同文件冲突或缺少验证方式。
+
+fan-in gate 必须说明：
+
+- 主线程如何整合结果。
+- 谁负责修复问题：`producer owns fix`。
+- 谁负责回归确认：`reviewer owns regression`。
+- 哪些命令或人工检查作为最终验证。
+- 是否需要保留、合并或清理分支 / worktree / 临时文件。
+
+## 成功标准
+
+- 每个任务都能独立实现、测试和验证
+- 任务粒度足够小，不会一次触碰过多文件
+- 依赖顺序和可并行项是显式的
+- 人类看完计划后能明确判断“方案对不对”
+- 计划中的问题和风险都能落到后续验证命令或审查项
+- `agent_opportunity` 已给出 mode、触发原因、确认边界和 fan-in gate
+- 并行任务必须有明确文件所有权或隔离理由
+- 阻塞发现已经进入 stop gate 或被转成 P1 implementation task
+
+## 相关原则
+
+- 计划服务实现，不是形式化文档
+- 先控制复杂度，再讨论并行度
+- 任务必须能验证，不能只写动作名
+- 计划阶段发现的问题要进入计划本身，不能只留在聊天里
+
+## 与其他技能的衔接
+
+- 接在 `spec-driven-development` 之后
+- 计划确认后交给 `incremental-implementation`
+- 涉及方案争议时，可搭配 `multi-perspective-review`

package/vendor/packages/toolkit/src/content/skills/sdd-tdd-workflow/body.md

@@ -1,95 +1,130 @@
-# SDD + TDD 开发工作流
-
-## 角色定位
-
-这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。
-
-渐进式披露规则：
-
-- 当前只需要路由和门控时，只读取本文。
-- 进入某个阶段时，再加载该阶段 skill。
-- 不把所有阶段规则同时塞进上下文。
-- 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。
-
-## 快速路径
-
-1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
-2. 若需求模糊，先进入 `brainstorming-and-design` 或 `spec-driven-development`。
-3. 若规格清楚，进入 `planning-and-task-breakdown`。
-4. 计划确认后，进入 `incremental-implementation` + `test-driven-development`。
-5. 实现完成后，进入 `code-review-and-quality`。
-6. 准备声明完成前，进入 `verification-before-completion`。
-7. 需要提交时，进入 `git-workflow-and-versioning`，并等待用户确认。
-8. 周期结束或需要沉淀经验时，进入 `sprint-retrospective`。
-
-## 阶段门控
-
-| 阶段 | 默认入口 | 通过条件 |
-|---|---|---|
-| Brainstorm（可选） | `brainstorming-and-design` | 目标、约束、方案方向已收敛 |
-| Specify | `spec-driven-development` | 规格可测试，假设已显式列出 |
-| Plan | `planning-and-task-breakdown` | 任务有依赖、文件边界和验证方式 |
-| Plan Review（可选） | `multi-perspective-review` | `GO / REVISE / NO-GO` 结论明确 |
-| Build | `incremental-implementation` + `test-driven-development` | 每个切片实现、测试、回归通过 |
-| Review | `code-review-and-quality` | Critical/Important 已处理或有明确延后理由 |
-| Verify | `verification-before-completion` | 新鲜验证命令通过，输出已读 |
-| Commit（可选） | `git-workflow-and-versioning` | 用户确认提交范围和消息 |
-| Retro（可选） | `sprint-retrospective` | 偏差、复盘和行动项已记录 |
-
-## 构建模式选择
-
-- **Manual（默认）**：你自己按任务串行实现。适合大多数改动。
-- **Subagent-Driven**：任务彼此独立，但用户没有要求并行时，可作为串行委派建议。
-- **Parallel**：用户明确要求多 agent / 并行 / team 模式，且任务有清晰文件所有权时，使用 `parallel-agent-dispatch`。
-- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离或多 CLI worker 时，使用 `team-orchestration`。
-
-除非用户已经明确要求并行，否则只给并行建议，不直接启动子代理或 `zc team`。
-
-推荐提示格式：
-
-```text
-Recommendation: 按 Manual / Parallel / Team 模式推进 because <证据与 trade-off>。
-- 并行收益：
-- 并行代价：
-- 文件所有权：
-- fan-in 验证：
-```
-
-## 阶段切换纪律
-
-- 进入新阶段前，说明当前阶段已满足的证据。
-- 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
-- 长会话变慢或内容开始混乱时，切到 `context-budget-audit` / `context-engineering`。
-- 变更涉及浏览器体验时，在单元/API 测试之外补 `browser-qa-testing`。
-- 涉及高风险命令、生产数据或敏感文件时，先切到 `safety-guardrails`。
-
-## 停线条件
-
-立即停止当前阶段并重新定位：
-
-- 测试、构建或 lint 失败但原因未读清。
-- 用户纠正了需求、范围或安全边界。
-- 计划要求修改的文件和实际代码结构明显不一致。
-- 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
-- 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
-
-## 输出契约
-
-完整交付过程中的关键结论都要使用可审查的推荐格式：
-
-```text
-Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。
-```
-
-不要只说“更稳”“更好”“建议继续”。必须说明为什么这个动作优于至少一个替代方案，以及如何验证它成立。
-
-## 验证
-
-声明完成前至少给出：
-
-- 实际运行的验证命令
-- 退出结果
-- 与本次任务相关的关键输出
-- 未运行的验证及原因
-
-不能用历史结果、主观判断或“应该没问题”替代验证证据。
+# SDD + TDD 开发工作流
+
+## 角色定位
+
+这是完整交付的编排 skill，不是每个阶段的详细教程。它负责把需求按阶段推进，并在进入具体阶段时再读取对应专项 skill。
+
+渐进式披露规则：
+
+- 当前只需要路由和门控时，只读取本文。
+- 进入某个阶段时，再加载该阶段 skill。
+- 不把所有阶段规则同时塞进上下文。
+- 发现任务变成 bug、文档、发布或上下文问题时，切换到对应入口，不继续硬走完整流程。
+
+## 快速路径
+
+1. 判断任务是否需要完整交付；简单修复、文档或调查任务不要套完整流程。
+2. 若需求模糊，先进入 `brainstorming-and-design` 或 `spec-driven-development`。
+3. 若规格清楚，进入 `planning-and-task-breakdown`。
+4. 计划确认后，进入 `incremental-implementation` + `test-driven-development`。
+5. 实现完成后，进入 `code-review-and-quality`。
+6. 准备声明完成前，进入 `verification-before-completion`。
+7. 需要提交时，进入 `git-workflow-and-versioning`，并等待用户确认。
+8. 周期结束或需要沉淀经验时，进入 `sprint-retrospective`。
+
+## 阶段门控
+
+| 阶段 | 默认入口 | 通过条件 |
+|---|---|---|
+| Brainstorm（可选） | `brainstorming-and-design` | 目标、约束、方案方向已收敛 |
+| Specify | `spec-driven-development` | 规格可测试，假设已显式列出 |
+| Plan | `planning-and-task-breakdown` | 任务有依赖、文件边界和验证方式 |
+| Plan Review（可选） | `multi-perspective-review` | `GO / REVISE / NO-GO` 结论明确 |
+| Build | `incremental-implementation` + `test-driven-development` | 每个切片实现、测试、回归通过 |
+| Review | `code-review-and-quality` | Critical/Important 已处理或有明确延后理由 |
+| Verify | `verification-before-completion` | 新鲜验证命令通过，输出已读 |
+| Commit（可选） | `git-workflow-and-versioning` | 用户确认提交范围和消息 |
+| Retro（可选） | `sprint-retrospective` | 偏差、复盘和行动项已记录 |
+
+## 构建模式选择
+
+进入 Build 前先选择执行模式，而不是直接默认手动实现：
+
+- **Manual**：简单任务、小修复或同一文件内紧耦合改动，主线程直接实现。
+- **Readonly Consult**：复杂任务需要架构、测试、安全、性能、产品或审查侧评；只有用户已授权本会话或项目默认启用只读 agent 时，才可通知式启动，不改文件。
+- **Serial Subagent**：已有计划，任务彼此独立但有依赖顺序；使用 `subagent-driven-development` 串行委派。
+- **Context Fan-Out**：任务可以按文件、模块或证据问题并行，且有清晰 fan-in gate；使用 `parallel-agent-dispatch`。
+- **Team Orchestration**：需要 tmux + git worktree 文件系统隔离、长时间多 worker 或 Codex / Qwen 多 CLI 协作；使用 `team-orchestration`，必须用户明确要求或确认。
+
+主线程是 controller / integrator：
+
+- 主线程负责目标、计划、分派、文件所有权、stop gate、fan-in 和最终验证。
+- 只读 agent 只汇报结构化结论，不改文件。
+- 写入 agent 只处理被分配的任务和文件，并返回修改文件、验证结果、风险和待 fan-in 项。
+- 审查 agent 默认只读；提出 finding 后负责回归确认。
+- 主线程可以处理小任务、集成冲突、最终修补和验证失败分析，但在已经选择多 agent 模式后，不抢占已分配给 worker 的任务。
+
+推荐提示格式：
+
+```text
+Recommendation: 按 Manual / Readonly Consult / Serial Subagent / Context Fan-Out / Team 模式推进 because <证据与 trade-off>。
+- agent_opportunity:
+- 只读协助:
+- 写入边界:
+- fan-in 验证:
+- 是否需要确认:
+```
+
+## 审查与回归闭环
+
+多 agent 任务必须遵循闭环所有权：
+
+```text
+producer owns fix
+reviewer owns regression
+controller owns fan-in
+```
+
+- 实现方或产生方负责优先修复自己引入的问题。
+- 审查方或提出方负责给出复现条件、断言、期望行为、风险等级，并在修复后复验原 finding。
+- 主线程负责判断 finding 是否成立、优先级是否阻塞、是否转派、是否接受结果。
+- 实现方两次修不好时，主线程可以缩小问题后转给更合适的 agent 或自己接手。
+- 审查方默认不直接修；机械小修或用户明确要求时，主线程可以把 finding 转成修复任务。
+
+审查等级：
+
+- `light review`：实现方自审 + 主线程检查。
+- `standard review`：实现方自审 + 独立 reviewer + 提出方回归。
+- `strict review`：规格审查 + 代码质量审查 + 测试 / 安全 / 性能按风险加入。
+
+中等以上任务默认 `standard review`，高风险任务默认 `strict review`。
+
+## 阶段切换纪律
+
+- 进入新阶段前，说明当前阶段已满足的证据。
+- 阶段中发现前提失真时，回退到上游阶段，不继续堆实现。
+- 长会话变慢或内容开始混乱时，切到 `context-budget-audit` / `context-engineering`。
+- 变更涉及浏览器体验时，在单元/API 测试之外补 `browser-qa-testing`。
+- 涉及高风险命令、生产数据或敏感文件时，先切到 `safety-guardrails`。
+
+## 停线条件
+
+立即停止当前阶段并重新定位：
+
+- 测试、构建或 lint 失败但原因未读清。
+- 用户纠正了需求、范围或安全边界。
+- 计划要求修改的文件和实际代码结构明显不一致。
+- 出现破坏性操作、凭据、生产数据或不可逆迁移风险。
+- 需要并行但没有文件所有权、隔离策略和 fan-in 验证。
+- review finding 未闭环，或提出方尚未完成回归确认。
+
+## 输出契约
+
+完整交付过程中的关键结论都要使用可审查的推荐格式：
+
+```text
+Recommendation: <下一步动作> because <具体证据、取舍和被放弃的替代方案>。
+```
+
+不要只说“更稳”“更好”“建议继续”。必须说明为什么这个动作优于至少一个替代方案，以及如何验证它成立。
+
+## 验证
+
+声明完成前至少给出：
+
+- 实际运行的验证命令
+- 退出结果
+- 与本次任务相关的关键输出
+- 未运行的验证及原因
+
+不能用历史结果、主观判断或“应该没问题”替代验证证据。

package/vendor/packages/toolkit/src/content/skills/sprint-retrospective/body.md

@@ -1,99 +1,99 @@
-# Sprint Retrospective
-
-## 角色定位
-
-在一个交付周期结束后，用证据复盘计划、实现、审查和验证的质量，并把下一轮要改变的行为写成少量可执行行动项。
-
-Retro 不是情绪总结，也不是长篇过程记录。没有行动项的 retro 通常只是仪式。
-
-## 何时使用
-
-- 完成一次 SDD+TDD 周期后。
-- 一周或一个里程碑结束后。
-- 生产事故、重大返工或计划偏差后。
-- 发现重复摩擦，但还没有明确改进项时。
-- 开始新大任务前，需要先复盘上一轮。
-
-## 快速路径
-
-1. 收集事实：提交、diff、测试、验证、PR/issue、事故记录。
-2. 对照原始 spec / plan，检查 scope drift。
-3. 识别有效做法、失败模式和根因。
-4. 评估流程健康：TDD、review、verify、build、handoff。
-5. 选出最多 3-5 个行动项。
-6. 给每个行动项写 owner、deadline、success metric。
-7. 判断哪些经验应该进入 ADR、docs、skill、memory 或保持为聊天结论。
-
-## 推荐数据
-
-按当前任务范围收集即可，不要为了复盘跑无关统计：
-
-- commit count / changed files / insertions / deletions
-- tests added or changed
-- verification commands and failures
-- review findings and resolution time
-- spec items delivered / modified / deferred / dropped
-- CI/build stability
-
-monorepo 中必须限定路径范围，避免 unrelated diff 污染结论。
-
-## Drift 判断
-
-```text
-Spec drift:
-- Delivered as planned:
-- Modified:
-- Deferred:
-- Added:
-- Dropped:
-- Reason:
-```
-
-drift 不一定是坏事。没有记录的 drift 才危险，因为下一轮会基于错误文档继续推进。
-
-## 行动项格式
-
-```text
-Action item:
-- What:
-- Why:
-- Owner:
-- Deadline:
-- Success metric:
-- Verification:
-```
-
-行动项最多 3-5 个。超过这个数量，优先级通常还没有收敛。
-
-## 知识沉淀边界
-
-- 架构或公共接口决策：进入 ADR / docs。
-- 项目长期约定：进入项目文档或入口规则。
-- 用户偏好或跨会话经验：只有明确授权后才进入 memory。
-- 一次性上下文和临时事故细节：只保留在本次记录中。
-
-## 输出契约
-
-```markdown
-# Retrospective: <period / milestone>
-
-## Evidence
-- ...
-
-## What Worked
-- ...
-
-## What Failed
-- ...
-
-## Drift
-- ...
-
-## Action Items
-- ...
-
-## Recommendation
-Recommendation: <keep / change / document / escalate> because <evidence, trade-off, and rejected alternative>.
-```
-
-推荐必须说明下一轮具体改变什么，而不是只说“继续保持”。
+# Sprint Retrospective
+
+## 角色定位
+
+在一个交付周期结束后，用证据复盘计划、实现、审查和验证的质量，并把下一轮要改变的行为写成少量可执行行动项。
+
+Retro 不是情绪总结，也不是长篇过程记录。没有行动项的 retro 通常只是仪式。
+
+## 何时使用
+
+- 完成一次 SDD+TDD 周期后。
+- 一周或一个里程碑结束后。
+- 生产事故、重大返工或计划偏差后。
+- 发现重复摩擦，但还没有明确改进项时。
+- 开始新大任务前，需要先复盘上一轮。
+
+## 快速路径
+
+1. 收集事实：提交、diff、测试、验证、PR/issue、事故记录。
+2. 对照原始 spec / plan，检查 scope drift。
+3. 识别有效做法、失败模式和根因。
+4. 评估流程健康：TDD、review、verify、build、handoff。
+5. 选出最多 3-5 个行动项。
+6. 给每个行动项写 owner、deadline、success metric。
+7. 判断哪些经验应该进入 ADR、docs、skill、memory 或保持为聊天结论。
+
+## 推荐数据
+
+按当前任务范围收集即可，不要为了复盘跑无关统计：
+
+- commit count / changed files / insertions / deletions
+- tests added or changed
+- verification commands and failures
+- review findings and resolution time
+- spec items delivered / modified / deferred / dropped
+- CI/build stability
+
+monorepo 中必须限定路径范围，避免 unrelated diff 污染结论。
+
+## Drift 判断
+
+```text
+Spec drift:
+- Delivered as planned:
+- Modified:
+- Deferred:
+- Added:
+- Dropped:
+- Reason:
+```
+
+drift 不一定是坏事。没有记录的 drift 才危险，因为下一轮会基于错误文档继续推进。
+
+## 行动项格式
+
+```text
+Action item:
+- What:
+- Why:
+- Owner:
+- Deadline:
+- Success metric:
+- Verification:
+```
+
+行动项最多 3-5 个。超过这个数量，优先级通常还没有收敛。
+
+## 知识沉淀边界
+
+- 架构或公共接口决策：进入 ADR / docs。
+- 项目长期约定：进入项目文档或入口规则。
+- 用户偏好或跨会话经验：只有明确授权后才进入 memory。
+- 一次性上下文和临时事故细节：只保留在本次记录中。
+
+## 输出契约
+
+```markdown
+# Retrospective: <period / milestone>
+
+## Evidence
+- ...
+
+## What Worked
+- ...
+
+## What Failed
+- ...
+
+## Drift
+- ...
+
+## Action Items
+- ...
+
+## Recommendation
+Recommendation: <keep / change / document / escalate> because <evidence, trade-off, and rejected alternative>.
+```
+
+推荐必须说明下一轮具体改变什么，而不是只说“继续保持”。