plan-fix

修复计划

plan-feature 的修复流程对应项：起草 SPEC，并冻结验收标准和两份规划台账，然后停止。review-plan 会在干净的上下文中审查计划；只有审查结果为 PASS 后，execute-phase --fix 才会实施各阶段。修复单元没有 Product 部分，也绝不会虚构一个——其依据是复现、根因、回归范围和回滚。

轮次约定——结束轮次前验证

✓ The fix SPEC is committed on its `fix/<n>-<topic>` branch (commit sha pasted) — NOT pushed, NO PR
✓ Both ledgers are frozen in the SPEC, `stage: plan` readiness printed
  `READY-FOR-REVIEW`, and the `artifactRevisionId` of this write is named in the hand-off
✓ This fix has no fabricated Product half, and the hand-off routes to
  `/review-plan` — never straight to `/execute-phase`
✓ The Hand-off block was printed exactly as specified
✓ A multi-issue unit? The hand-off names every issue once as `#primary + #n2 + …`; a single-issue unit names only its issue
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English artifacts unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

准备结束轮次时，还有任何一项未勾选？轮次就尚未完成——先完成缺失项（弱模型会遗漏文档末尾的任务）。

角色

资深软件架构师：保持审慎、严格控制范围，并以证据为依据。选择最小变更集，指出二阶影响，并引用证据。

输入

一个或多个本仓库的 GitHub issue 编号，以空格分隔。

• **一个编号：**保持单 issue 行为不变（plan-fix 17）。
• **多个编号：**第 5 步决定将其归为一个功能包，还是同质的机械批次；若由同一结果、验证器和回滚边界负责，不同症状或文件可以合并。
• **无效输入：**指出错误的 token 并停止；绝不部分执行。

输出

• docs/fix/<primary>-<topic>/SPEC.md — 模板以及必需章节和 ## Phases 台账（始终 ≥2 个阶段；最后一个阶段为 Hardening & PR）。主编号为唯一的 issue 编号，或合并的 issue 中编号最小者；合并后的 SPEC 必须保留每个 issue 的验收标准。
• docs/fix/<primary-issue-number>-<topic>/ACCEPTANCE.md — 来自 verification-contract 的精简冻结完成标准，每个 issue 保留一项标准。
• SPEC 中的 ### Planning evidence 和 ### Obligations — 两份冻结台账（规划台账），其中修复行 evidence-grounding 指定的名称为：复现、带代码证据的根因、回归范围、回滚路径，以及受影响的不变量或用例。缺少复现行时，应标记为 unknown 并指定负责人，而不是写“可能是这个”。
• 从 main 创建分支 fix/<primary>-<topic>。
• 一个本地提交，包含 SPEC 和 docs/fix/README.md（pending，包含所有合并的 issue）。
• **停止：不要推送或创建 PR。**移交给 review-plan，然后执行 execute-phase --fix。

调研与引用追踪（规划阶段）

• **有条件的网络调研。**仅当有界问题（ROWS.md Q1–Q5）无法通过仓库证据回答时，才进行规划阶段调研：在生成各阶段之前，恰好执行一次网络查询，并将返回内容作为证据行冻结（URL 和访问日期）。仓库能够回答的问题绝不重新查询。
• **强制引用追踪。**通过符号／引用搜索定位受影响的代码——环境支持时使用 LSP／serena，否则使用 grep；影响范围必须从搜索结果中推导，绝不能依赖模型记忆：新增或变更的代码可能破坏调用方，计划必须指出这些调用方。

硬性规则

• 遵循 Workflow 约定：先创建 fix/<n>-<topic>，绝不在 main 上操作；必须遵守门禁、文档语言和证据要求。代码问题引用文件路径，文档问题引用章节；新问题应作为单独的修复／路线图条目跟踪，绝不内联处理。
• 语言优先级：用户明确指示 > 声明的文档语言 > 英语——对话语言不决定文档语言。若 issue 正文不是工件所用语言，应静默翻译；若翻译存在歧义、不一致或语义不通，应在提交前询问。
• 绝不推送，绝不创建 PR——这由 execute-phase --fix 负责。

渐进式加载——起草前先验证

允许列表仅包含以下五个路径：

1. 每次调用：读取规划流程，并执行其验证和多问题门控；拒绝或输入无效时，停止。
2. 提出实质性问题或编写 SPEC 前：读取问题与 SPEC 合约。
3. 任何可能编写修复 SPEC 的路径：在起草前使用规划预检（负责读取规范化的仓库状态，并进行唯一一次最终架构分类）。
4. 输出阶段前：加载阶段合约，以进行 8 项阶段检查和阶段指纹验证。
5. 提交前：使用验证合约，并编写冻结的 ACCEPTANCE.md。
6. 起草期间：按照 evidence-grounding 提供依据，并按照 pre-execution-review 冻结两份台账；交接前运行 evidence-grounding 的 stage: plan 就绪预检，并粘贴相应区块。READY-FOR-REVIEW 仅表示可以交接，绝不是审查结论；本技能不会审查自己的计划。

资源具有规范效力，且仅需从本文件前往一级。缺少必需资源时 → 停止；切勿近似替代固定区块或阶段规则。

交接

提交后，准确输出：

SPEC drafted: docs/fix/<primary>-<topic>/SPEC.md
Branch: fix/<primary>-<topic> (local, not pushed)
Commit: <short hash>
Issue set: #<primary> + #<n2> + #<n3> (print every issue in this unit; single issue → #<primary>)

→ Next: /review-plan fix-<primary> — an independent context reviews this plan and
  these ledgers before any phase runs; /execute-phase --fix <primary> follows its
  PLAN-REVIEW-PASS (issue set #<primary> + #<n2> + #<n3>)
  · PLAN-REVIEW-FAIL → repair here as one batch, rotate the artifact revision, re-review
  · a product choice is open → /design-feature, then /review-spec, then replan this fix
  · after PASS, explicit atomic mode → /execute-phase --fix <primary> P<n> (same issue set)
  · the final `Hardening & PR` phase pushes and opens the PR with `Closes #<primary>`
    plus one `Closes #<n>` line for every other issue listed in the Issue set
  · scope looks wrong → adjust the SPEC and re-run /plan-fix

输出前，将每个占位符替换为完整的实际问题集；实时交接中绝不输出 <n2>、<n3> 或 …。

然后用用户的语言，以 2–3 句话总结：SPEC 将交付什么、最大的风险，以及留给实现者决定的未决事项。

可移植性（适用于 Claude Code 以外的 Agent）

当某个原语不可用时，使用明确的替代方案：在新的上下文中打开指定的 SKILL.md 文件；使用能力最强的模型进行架构层级的范围界定，然后将实现工作交给成本更低的工作 Agent。

完成条件

• SPEC 和冻结的 ACCEPTANCE.md 遵循规范合约，指出风险／阻塞项，在 docs/fix/README.md 中登记，并在本地提交至 fix/<n>-<topic>（不推送／不创建 PR）。打印结尾的 → Next: 交接内容。