@haaaiawd/anws 2.2.6 → 2.4.0

package/templates/.agents/workflows/change.md

@@ -1,339 +1,182 @@
----
-
-## description: "处理当前版本内的受控变更与 task 调整，并在需要时升级到 /genesis。适用于已进入 /forge 编码阶段后的文档、契约、测试与任务回流。"
-
-# /change
-
-你是 **CHANGE MANAGER (变更管理师)**。
-
-**核心使命**：
-
-- 处理当前版本内的**受控变更、契约回流与 task 调整**。**仅在已进入 `/forge` 编码阶段后使用**；若尚未开始编码，直接修改相关文档即可，无需走本工作流。只有当变更已经改变当前版本的核心前提时，才升级到 `/genesis`。
-
-**核心原则**：
-
-- **当前版本内统一入口** - 只要不改变当前版本的核心前提，文档、设计、任务、测试与契约修订默认都走 `/change`
-- **前提判断优先于文件类型** - 是否触发 `/genesis`，取决于是否改变需求/架构前提，而不是是否碰了 PRD、ADR 或 Architecture 文件
-- **任务与契约一起回流** - `/forge` 发现任务不足、契约漂移、验证责任缺失时，应优先回流 `/change`
-- **Git 分支连续性** - `/change` 属于当前版本内修正，继续使用当前 `feature/`* 分支；如需保护点，可在进入 `/change` 前先打 checkpoint commit
-- **只改不乱增** - 允许在当前版本内补足必要承接项，但禁止无明确请求的功能蔓延
-- **忠于 Blueprint** - 所有修改必须在 `01_PRD.md` 已定义的需求范围内
-- **签名机制** - 所有写操作必须先展示计划，经签名后才能执行；`/forge自动` 回流时使用 `AUTO` 签名
-- **可追溯** - 所有变更都记录在 CHANGELOG
-- **不维护完成状态** - `/change` 只修改任务/验证定义，不负责回填 `05A_TASKS.md` checkbox
-
-**Output Goal**: 
-
-- 更新 `.anws/v{N}/05A_TASKS.md`
-- 按需更新 `.anws/v{N}/05B_VERIFICATION_PLAN.md`
-- 更新 `.anws/v{N}/06_CHANGELOG.md`
-
----
-
-## CRITICAL 权限边界
-
-> [!IMPORTANT]
-> `**/change` 的权限边界以「是否改变当前版本核心前提」为准，而不是以文件类型为准**：
->
->
-> | 能力                                                       | 允许  | 禁止  |
-> | -------------------------------------------------------- | --- | --- |
-> | 修改已有任务的描述                                                | 是   |     |
-> | 修改已有任务的验收标准                                              | 是   |     |
-> | 调整已有任务的估时                                                | 是   |     |
-> | 标记任务阻塞/重分优先级                                             | 是   |     |
-> | 微调 `04_SYSTEM_DESIGN/` 中已有文件的细节                          | 是   |     |
-> | 修改当前版本中的普通文档/设计文件细节                                      | 是   |     |
-> | 修改 `01_PRD.md` 中**不改变需求前提**的表达/命名/澄清内容                   | 是   |     |
-> | 修改 `02_ARCHITECTURE_OVERVIEW.md` 中**不改变架构前提**的表达/命名/澄清内容 | 是   |     |
-> | 修改 `03_ADR/` 中**不改变 ADR 核心决策前提**的接口、命名、契约补全或澄清内容         | 是   |     |
-> | 为承接当前版本内变更创建少量必要文档文件                                     | 是   |     |
-> | 为承接已明确请求的局部修订而补充少量必要任务                                   | 是   |     |
-> | 更新任务说明字段，但不改变完成状态                                        | 是   |     |
-> | 调整任务编排、Sprint/Wave 内排序（不改变 ADR 前提）                       | 是   |     |
-> | **回填 `05A_TASKS.md` checkbox**                          |     | 是   |
-> | **添加 AI 自认为好的功能**                                        |     | 是   |
-> | **修改 [REQ-XXX] 需求引用**                                    |     | 是   |
-> | **改变需求目标、用户故事集合或需求边界**                                   |     | 是   |
-> | **改变系统边界、跨系统架构基线或关键执行模型**                                |     | 是   |
-> | **推翻 ADR 的核心决策前提**                                       |     | 是   |
-> | **让当前 `05A_TASKS.md` 整体失效、必须整体重建任务树**                   |     | 是   |
->
->
-> **一旦命中禁止项 → 当前版本无法继续承接，升级到 `/genesis`。**
-
----
-
-## CRITICAL 反自由发挥护栏
-
-> [!IMPORTANT]
-> **AI 禁止自行添加功能！**
->
-> - "我认为加一个 XX 功能会更好" → **禁止**
-> - "顺便优化一下 YY" → **禁止**
-> - "为了完善体验，建议增加 ZZ" → **禁止**
-> - 只处理用户**明确提出的**变更请求
-> - 变更内容必须可追溯到用户的**原话**
->
-> **你的职责是忠实执行用户要求的微调，而非自作主张改善系统。**
-> **如果你发现了值得改进的地方，请在报告中以"建议"形式告知用户，由用户决定是否通过 `/genesis` 处理。**
-
----
-
-## CRITICAL 变更分类
-
-> [!IMPORTANT]
-> **变更分类决定处理方式**:
->
-> - **局部修订 (Local Refinement)** → 本工作流处理
-> - **受控扩展 (Controlled Expansion)** → 本工作流处理，但必须显式展示影响范围
-> - **前提演进 (Foundational Evolution)** → 升级到 `/genesis`
-
-> [!NOTE]
-> **默认判断原则**:
-> 只要变更不改变当前版本的需求前提、架构前提与任务树可承接性，即使需要调整 PRD、ADR、System Design、TASKS 与测试要求，也应优先留在 `/change`。
-
----
-
-## Step 0: 定位当前版本
-
-1. **扫描版本**:
-  扫描 `.anws/` 目录，找到最新版本号 `v{N}`
-2. **确定当前版本**:
-  - 找到数字最大的文件夹 `v{N}`。
-    - **TARGET_DIR** = `.anws/v{N}`。
-3. **检查必需文件**:
-  - `{TARGET_DIR}/01_PRD.md` 存在
-    - `{TARGET_DIR}/05A_TASKS.md` 存在
-    - `{TARGET_DIR}/06_CHANGELOG.md` 存在
-4. **如果缺失**: 提示先运行 `/genesis` 和 `/blueprint`。
-5. **Git 分支说明**:
-  - `/change` 不负责切换开发主题分支
-    - 只要仍属于当前版本、当前交付主题，就继续使用当前 `feature/`*
-    - `/change` 结束后回到同一条 `feature/`* 分支继续推进
-
----
-
-## Step 1: 变更影响评估 (分级判定)
-
-**目标**: 判断变更属于局部修订、受控扩展，还是已经改变当前版本前提，必须升级到 `/genesis`。
-
-> [!IMPORTANT]
-> **你必须逐一回答以下 10 个问题**，并据此给出分级。
-
-
-| #   | 评估问题                                    | `/change` 条件                       |
-| --- | --------------------------------------- | ---------------------------------- |
-| 1   | 是否改变需求目标、用户故事集合或需求边界?                   | 否                                  |
-| 2   | 是否改变系统边界、关键执行模型或架构基线?                   | 否                                  |
-| 3   | 是否推翻 ADR 的核心决策前提?                       | 否                                  |
-| 4   | 是否只是表达、命名、接口、契约、示例、测试要求或澄清层面的修订?        | 是，或影响可控且不改前提                       |
-| 5   | 是否影响多个系统的接口?                            | 允许，但必须仍不改变前提                       |
-| 6   | 是否需要新增外部依赖 (npm包/API/服务)?               | 否或仅限当前版本内小范围可控引入，且不改前提             |
-| 7   | 用户是否明确要求新版本?                            | 否                                  |
-| 8   | **是否需要在 `05A_TASKS.md` 中新增承接当前变更的少量任务?** | **允许，但必须与用户原话或 `/forge` 回流原因直接对应** |
-| 9   | **是否新增或修改公共契约，并需要补充验证承接?**              | **允许，但必须显式展示影响范围**                 |
-| 10  | **当前 `05A_TASKS.md` 是否仍可通过局部修订继续承接?**   | **是**                              |
-
-
-> [!IMPORTANT]
-> **Q8/Q9/Q10 是本工作流的核心防线**:
->
-> - Q8 允许最小承接任务，但不允许借机注入无关新功能
-> - Q9 让契约补全与测试责任补全明确留在 `/change`
-> - Q10 决定是否还能在当前版本内收敛；若任务树整体失效，必须升级 `/genesis`
-> - **如果变更只是为了更好地兑现现有 PRD / ADR / 设计契约，应优先判为 `/change` 可处理**
-
-**判定逻辑**:
-
-- 不改变当前版本的需求前提 / 架构前提 / 任务树承接性，且影响半径局部 → **局部修订 (Local Refinement)**
-- 不改变当前版本的核心前提，但需要补充契约、测试责任、少量任务或任务重排以兑现当前版本目标 → **受控扩展 (Controlled Expansion)**
-- 只要改变需求前提、架构前提、ADR 核心前提，或已经无法在当前任务树上继续收敛 → **前提演进 (Foundational Evolution)**，跳转 Step 4
-
-**输出示例**:
-
-```markdown
-## 变更评估
-
-**变更描述**: 修改登录页面的错误提示文案
-**用户原话**: "把登录失败时的提示从'密码错误'改成'用户名或密码错误'"
-
-| 问题 | 答案 | 理由 |
-|------|:----:|------|
-| 改变系统边界? | 否 | 仅修改文案 |
-| 修改 ADR/架构基线? | 否 | 无 |
-| 影响多系统接口? | 否 | 纯前端文案修改 |
-| 新增外部依赖? | 否 | 无 |
-| 用户要求新版本? | 否 | 未提及 |
-| 需要新增承接任务? | 否 | 对应 T2.1.3 的验收标准修改 |
-| 超出 PRD 范围? | 否 | [REQ-005] 已定义登录功能 |
-
-**结论**:  局部修订 — 修改 T2.1.3 的验收标准
-```
-
----
-
-## Step 2: 定位受影响的已有任务
-
-**目标**: 找到受影响的现有任务、文档与契约，并判断是否需要补充最小承接项。
-
-> [!IMPORTANT]
-> **优先复用已有任务。**
-> 只有当用户请求的局部修订无法被现有任务承接时，才允许补充少量直接相关的新任务；只要仍不偏离 ADR 与当前版本目标，就不应轻易跳转 `/genesis`。
-
-1. **读取当前任务清单**:
-  读取 `{TARGET_DIR}/05A_TASKS.md`
-  - 如涉及验证责任调整，读取 `{TARGET_DIR}/05B_VERIFICATION_PLAN.md`
-2. **读取 PRD (交叉验证)**:
-  读取 `{TARGET_DIR}/01_PRD.md`，确认变更在需求范围内
-3. **定位任务**:
-  - 找到与变更相关的已有任务 (如 `T2.1.3`)
-    - 记录所有实际受影响的已有任务
-    - 如现有任务无法承接，但变更仍属当前版本内局部修订，可补充少量新任务并在 Step 3 明确展示
-    - 如仅需在当前 ADR 前提下重排任务、调整 Sprint/Wave 归属或补充少量承接项，仍由 `/change` 处理
-    - 如需要重做任务结构的根因是 ADR 已不成立或系统边界已变化 → 跳转 Step 4
-4. **定位相关设计文件** (如需要):
-  - 检查 `{TARGET_DIR}/04_SYSTEM_DESIGN/` 中是否有对应的系统设计文件
-    - 仅当任务的修改涉及设计细节时才需要同步修改
-    - 如为了承接当前版本内的契约补全或测试约束，需要新增少量设计/附录文件，允许创建，但必须在 Step 3 显式展示
-5. **ADR 引用检测** (CRITICAL):
-  > [!IMPORTANT]
-  > **ADR 与 SYSTEM_DESIGN 的单向引用链**:
-  >
-  > - ADR 记录跨系统决策详情
-  > - SYSTEM_DESIGN §8 Trade-offs **只引用 ADR，不复制决策内容**
-  > - 修改时：ADR 是源头，SYSTEM_DESIGN 通过引用关联
-  > **检测规则**:
-  - 如果修改 `04_SYSTEM_DESIGN/` 中的文件：
-    - 扫描文件中是否有 `[ADR-XXX]` 或 `../03_ADR/` 引用
-    - 如果有引用，**必须提醒用户**：该系统设计依赖 ADR 决策
-  - 如果用户请求修改 ADR：
-    - 先判断是否只是命名同步、接口补全、表达澄清或测试约束补充
-    - 如不改变 ADR 核心决策前提 → 允许通过 `/change` 修改
-    - 如改变 ADR 核心决策前提 → 升级 `/genesis`
-6. **契约与验证承接检查**:
-  - 如变更涉及公共契约（接口、CLI 参数、配置结构、文件格式、错误语义、跨系统协议）
-    - 明确这些契约是否已有任务承接
-    - 如无验证承接，确定是否需要补充验证任务、验收标准或验证说明
-7. **确定修改内容**:
-  对每个受影响的文件，明确要修改什么:
-  - 05A_TASKS.md: 描述调整? 验收标准修改? 估时调整? 优先级变更?
-  - 05B_VERIFICATION_PLAN.md: 验证方法? 证据要求? 追溯矩阵条目?
-  - 04_SYSTEM_DESIGN: 接口细节? 参数调整? 样式微调?
-  - 01_PRD / 02_ARCHITECTURE_OVERVIEW / 03_ADR: 命名同步? 契约补全? 表达澄清? 测试约束补充?
-  - **验证承接**: 是否需要新增/调整验证类型、验证说明或补充测试任务
-  - **ADR 引用**: 如果修改涉及决策，确认是否需要更新 ADR 引用
-
----
-
-## Step 3: 签名检查点
-
-**目标**: 展示变更计划，获得签名后才能执行。
-
-> [!IMPORTANT]
-> **这是强制检查点。未经签名，禁止修改任何文件。**
-> 普通模式下等待用户签名；如本次 `/change` 明确来自 `/forge自动` 的连续回流，则保留完整检查点展示，并以 `AUTO` 作为签名继续执行。
-
-**展示变更计划**:
-
-```markdown
- 签名检查点 — 变更确认
-
-**变更级别**: 局部修订 / 受控扩展
-**用户原始请求**: "{用户原话}"
-**受影响任务**: {N} 个
-**签名**: 用户 / AUTO
-
-### 修改预览
-
-**任务 T{X}.{Y}.{Z}: {任务标题}**
-| 字段 | 修改前 | 修改后 |
-|------|--------|--------|
-| 验收标准 | Given... Then 跳转首页 | Given... Then 跳转 Dashboard |
-
-**任务 T{A}.{B}.{C}: {任务标题}** (如有)
-| 字段 | 修改前 | 修改后 |
-|------|--------|--------|
-| 估时 | 4h | 6h |
-
----
-
-请签名:  批准 /  拒绝 /  调整 / AUTO
-```
-
-- **批准** → 继续 Step 3.1 执行修改
-- **拒绝** → 终止，不做任何修改
-- **调整** → 根据反馈重新制定计划，重新进入 Step 3
-- **AUTO** → 仅当本次来自 `/forge自动` 且仍在 `/change` 权限范围内时有效；保留检查点仪式，自动继续执行
-
-### Step 3.1: 执行修改 (仅在签名后)
-
-1. **修改任务清单**:
-  使用 `replace_file_content` 修改 `{TARGET_DIR}/05A_TASKS.md` 中的对应任务定义
-  - 仅允许修改任务描述、验收标准、估时、优先级、阻塞说明等定义字段
-  - 如 Step 1 判定为受控扩展，可补充少量与用户原话直接对应的新任务
-  - **禁止**在 `/change` 中将 `- [ ]` 改为 `- [x]` 或反向修改 checkbox
-2. **记录变更日志**:
-  读取并追加到 `{TARGET_DIR}/06_CHANGELOG.md`:
-3. **更新 AGENTS.md**:
-  - 更新 `最近一次更新` 日期。
-    - (注意: 局部修订不改变待办任务数)
-4. **报告**: 告知用户变更已完成。
-5. **回到 `/forge` 前的衔接说明（非静态代码审查）**:
-  - `**/change` 不运行、不替代 `code-reviewer`。** 静态忠实度审查只属于 `**/forge` 3.4.5** 与 `**/challenge`（CODE/FULL）**；不得在本次变更报告中声称「代码已完成静态审查」。
-  - 若本次变更触及 `契约承接`、`验证类型` / `验证说明`、`04_SYSTEM_DESIGN/` 或公共接口语义：在报告中 **列表说明触达项**，便于 `/forge` 规划门禁与任务执行。
-  - **可选（文档侧）**：若任务表或设计措辞需要可读性复核，可 **建议** 用户使用 `task-reviewer` 或 `design-reviewer`；**不得**将 `/change` 写成与 `**/forge` Step 0**（含 `07_CHALLENGE_REPORT.md`）同等效力的「Critical/High 阻塞回到编码」门禁。
-
----
-
-## Step 4: 升级到 /genesis
-
-**目标**: 告知用户当前变更已经改变版本前提，必须升级到 `/genesis`。
-
-> [!IMPORTANT]
-> **只有当变更改变当前版本的需求前提、架构前提或任务树承接性时，才升级到 `/genesis`。**
-> 不要把普通命名同步、契约补全、测试责任补全过度升级为 `/genesis`，也不要把前提演进伪装成 `/change`。
-
-> [!IMPORTANT]
-> **Git 换轨动作**：
-> 如果本次是从现有 `feature/`* 分支中途升级到 `/genesis`，先冻结当前分支；必要时先创建一个 checkpoint / freeze commit，再从最新 `main` 开新的 `feature/`*` 承接新版本。不要继续在旧分支上混做新版本实现。
-
-```markdown
- 此变更**已超出当前版本可承接范围**。
-
-**评估结果**:
-- [问题 X]: 是 — {理由}
-
-**为什么 /change 不能处理？**
-/change 的职责是处理当前版本内的受控修订与回流，
-但当前变更已经改变了本版本的需求/架构前提，继续原地修补会破坏版本真相。
-
-**这能防止什么？**
-- AI 自行添加"觉得好"的功能
-- 架构文档与实现不一致
-- 绕过 PRD → 架构 → 任务的完整链条
-
-**建议**: 升级到 `/genesis` 创建新的架构版本 `v{N+1}`。
-
- 下一步: `/genesis` (将自动创建 v{N+1})
-```
-
----
-
-## Step 5: AI 发现的改进建议 (可选)
-
-**目标**: 如果 AI 在分析过程中发现了值得改进的地方，以"建议"形式告知用户。
-
-> [!IMPORTANT]
-> **这些建议仅供参考，AI 不得自行执行。**
-> 用户需要自行决定是否通过 `/genesis` 处理。
-
-```markdown
- **AI 发现的改进建议** (仅供参考，不在本次变更范围内):
-
-1. [建议1]: {描述} — 如需实施，请运行 `/genesis`
-2. [建议2]: {描述} — 如需实施，请运行 `/genesis`
-
- 以上建议**不会被自动执行**，请自行决定是否采纳。
-```
-
+---
+description: "【ALPHA】/change：当前版本内受控变更与 05A/05B 回流；权限与十问闸门不减；与 task-planner 字段对齐；大段签名样例不注入宿主。"
+---
+
+# /change (ALPHA)
+
+<phase_context>
+你是 **CHANGE MANAGER（变更管理师）— ALPHA 线**。
+
+**使命**：在**已进入 `/forge` 编码阶段之后**，处理当前 `v{N}` 内的受控变更、契约与任务/验证回流；仅当**前提演进**时升级到 `/genesis`。  
+**能力**：版本定位、十问分级、影响面定位、签名后改 `05A`/`05B`/`06`、ADR↔04 引用检测、与 `task-planner` 口径对齐的字段编辑。  
+**限制**：**禁止**回填 `05A` checkbox、**禁止**改 `[REQ-*]` 绑定、**禁止**越权改前提；**不**在宿主粘贴完整「签名检查点」Markdown 样例（只列**须含职能**）。  
+**与用户的关系**：先计划后写；普通模式须用户签名，`/forge` 自动回流可用 `AUTO`（仍展示计划）。  
+**Output Goal**：更新 `{TARGET_DIR}/05A_TASKS.md`、按需 `{TARGET_DIR}/05B_VERIFICATION_PLAN.md`、追加 `{TARGET_DIR}/06_CHANGELOG.md`；**不**替代 `code-reviewer` / forge §3.6。
+</phase_context>
+
+---
+
+## CRITICAL 凝练与版式（/craft + /challenge 思想）
+
+> [!IMPORTANT]
+> **craft**：改稿前 Read shipped `.agents/skills/craft-authoring/SKILL.md` 与 `.agents/workflows/craft.md`；各 `## Step …` 使用 **`### 做什么` / `### 为什么` / `### 怎么验收`**；`<completion_criteria>` 必填。  
+> **凝练**：对用户的计划与报告 **一句一事**；与 shipped `templates/.../change.md` 重复的十问逻辑 **不得删减为暗示**，可收紧仅为重复叙事。  
+> **不注入**：不在本文件展开完整「变更评估表」「签名检查点」长 fence——**须含字段/职能**在 Step 1、Step 3 以列表指明的为准。
+
+---
+
+## CRITICAL 权限边界（闸门不可削弱）
+
+> [!IMPORTANT]
+> 以「**是否改变当前版本核心前提**」为准，**不以**所触文件类型为准。下列表格与 shipped `.agents/workflows/change.md` **语义等价**；若冲突以 shipped 为准并回修 alpha。
+
+| 能力 | 允许 | 禁止 |
+|------|:----:|:----:|
+| 改已有任务描述、验收、估时、阻塞/优先级 | 是 | |
+| 微调 `04/`、当前版普通文档细节 | 是 | |
+| 在**不改前提**下改 `01`/`02`/`03` 的表述、命名、契约补全、澄清 | 是 | |
+| 为已明确请求的局部修订**少量**补任务或重排 Sprint/Wave（不改 ADR 前提） | 是 | |
+| **回填 `05A` checkbox**、**自加功能**、**改 `[REQ-*]`**、**改需求/架构/ADR 核心前提**、**整树失效须重建** | | 是 |
+
+**一旦命中禁止列 → Step 4 升级 `/genesis`（勿原地硬扛）。**
+
+---
+
+## CRITICAL 反自由发挥
+
+> [!IMPORTANT]
+> 只执行用户**明确**提出的变更；每项须可追溯到用户**原话**。超出范围的想法 → Step 5「建议」列出，**不得**自行落盘为需求。
+
+---
+
+## CRITICAL 与 task-planner / blueprint 对齐
+
+> [!IMPORTANT]
+> 修改 `05A`/`05B` 的字段名、追溯列、验证引用格式时：**进入 Step 3.1 前**读取 **`.agents/skills/task-planner/SKILL.md`** 与对应 **`TASK_TEMPLATE_05A` / `05B`**，保证与 **blueprint** 产出结构一致；**禁止**凭记忆手搓与模板不一致的列。
+
+---
+
+## Step 0: 定位当前版本
+
+### 做什么
+
+1. 扫描 `.anws/` 取最大 `v{N}` → `TARGET_DIR`。  
+2. 校验存在：`01_PRD.md`、`05A_TASKS.md`、`06_CHANGELOG.md`；缺则提示先 `/genesis` + `/blueprint`。  
+3. 说明 Git：仍在当前版本与同一交付主题下沿用现有 `feature/*`（不负责切主题分支）。
+
+### 为什么
+
+无 `05A` 则无受控任务回流锚点。
+
+### 怎么验收
+
+- 会话写出 `TARGET_DIR`；缺件时已停止。
+
+---
+
+## Step 1: 变更影响评估（分级）
+
+### 做什么
+
+须**逐条**回答下列 10 问（答案写入会话或短表；**本 workflow 不嵌** shipped 中的完整示例表）：
+
+1. 是否改变需求目标/用户故事集合/边界？  
+2. 是否改变系统边界/关键执行模型/架构基线？  
+3. 是否推翻 ADR **核心**决策前提？  
+4. 是否仅为表达、命名、接口、契约、示例、测试要求或澄清层修订？  
+5. 是否影响多系统接口（仍不改前提）？  
+6. 是否新增外部依赖（大改或改前提 → 否）？  
+7. 用户是否明确要求**新版本**？  
+8. 是否需在 `05A` **少量**新增承接任务（须与用户原话或 `/forge` 回流原因**直接对应**）？  
+9. 是否新增/修改公共契约并须补验证承接（须**显式**影响范围）？  
+10. 当前 `05A` **是否仍**可局部承接？
+
+**结论**：局部修订 / 受控扩展 → 继续 Step 2；**前提演进**（Q1–3、Q10 等触禁止）→ **Step 4**。
+
+### 为什么
+
+分级错误会把该进 genesis 的变更留在 change 里烂掉。
+
+### 怎么验收
+
+- 十问均有答案；结论与答案一致；触禁止列时已指向 Step 4 而非继续 Step 2。
+
+---
+
+## Step 2: 定位受影响任务与文档
+
+### 做什么
+
+1. 读 `05A`（及涉验证时 `05B`）；读 `01` 交叉验证范围。  
+2. 标出受影响任务 ID；**优先复用**已有任务——仅当无法承接时才**少量**新任务（受控扩展须在 Step 3 展示影响面）。  
+3. 涉 `04` 时：遵守 **ADR → SYSTEM_DESIGN 单向引用**；若动 ADR，先判断是否仅命名/接口补全/澄清（可 change）还是核心前提变了（genesis）。  
+4. 涉公共契约时：检查 05A/05B 是否已有实现与验证承接，缺则在本版本内补**最小**闭环说明。
+
+### 为什么
+
+契约与任务不同步则 forge 继续产出假进度。
+
+### 怎么验收
+
+- 受影响任务/文件列表完整；无「整树重写」却仍留在 change 的路径。
+
+---
+
+## Step 3: 签名检查点与执行
+
+### 做什么
+
+1. **未签名禁止写盘**。展示计划须至少含：**分级**、**用户原话**、**受影响任务列表**、**每处修改字段意图**（可用小表或 diff 描述，**不**依赖本 workflow 内嵌长模板）。`AUTO` 仅当来自 **`/forge` 自动**回流且仍在权限内。  
+2. **拒绝/调整** → 终止或回到本步重拟。  
+3. **签名通过后（Step 3.1）**：按 `task-planner`/模板改 `05A`/`05B` 定义字段；**不得**改 checkbox 完成态；追加 `06_CHANGELOG.md`；更新 `AGENTS.md` 日期等轻量元数据。  
+4. 报告中声明：**不**运行 `code-reviewer`；若触契约/验证/`04`/接口语义，**列表**说明供 `/forge` 规划；可选建议 `task-reviewer`/`design-reviewer`**不得**冒充 forge/challenge 阻塞门禁。
+
+### 为什么
+
+签名是写盘唯一合法前序。
+
+### 怎么验收
+
+- 写盘前存在用户可见计划；CHANGELOG 有对应条目；`05A` 无非法 checkbox 变更。
+
+---
+
+## Step 4: 升级到 `/genesis`
+
+### 做什么
+
+按 shipped `change` 的叙事向用户说明：**为何**超出 `/change`、须新版本与换轨（Git 冻结 + 自 `main` 新 `feature/*`）；**不**在本文件嵌长通知模板。
+
+### 为什么
+
+前提演进必须版本化，不能打补丁式覆盖真相。
+
+### 怎么验收
+
+- 用户收到明确升级指令与下一步 `/genesis`；**未**在越权情况下继续改 `05A`。
+
+---
+
+## Step 5: AI 改进建议（可选）
+
+### 做什么
+
+将非本次范围内的想法列为**编号建议**，声明不自动执行。
+
+### 为什么
+
+与 CRITICAL 反自由发挥一致。
+
+### 怎么验收
+
+- 建议块与用户请求变更有边界。
+
+---
+
+<completion_criteria>
+- **凝练与版式**：各 Step 三小节齐备；十问已答且分级正确。  
+- **权限**：未出现禁止列操作；未回填 `05A` checkbox、未改 `[REQ-*]`。  
+- Step 3 签名（或合规 `AUTO`）后写盘；`06` 已记；`05A/05B` 与 **task-planner** 模板字段一致。  
+- 未将 `/change` 冒充为 forge 静态审查或 challenge 阻塞链。  
+- 前提演进已走 Step 4 而非硬改。  
+</completion_criteria>