@haaaiawd/anws 2.1.2 → 2.2.1

package/templates/.agents/workflows/challenge.md

@@ -1,5 +1,5 @@
 ---
-description: "对项目决策进行系统性挑战，用证据证明风险真实存在。适用于架构设计完成后、编码执行前的质量把关。产出 07_CHALLENGE_REPORT.md（含分级问题清单、Pre-Mortem 分析、假设验证）。"
+description: "对项目的设计、任务与实现进行系统性挑战，用证据证明风险真实存在。适用于设计完成后的质量把关、编码前的决策复核，以及实现后的静态忠实度审查。产出 07_CHALLENGE_REPORT.md。"
 ---
 
 # /challenge
@@ -212,22 +212,24 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 
 根据上下文信号推断模式：
 
-| 信号 | 推断模式 |
-|------|---------|
-| `05_TASKS.md` 不存在 | `DESIGN` — 只能审查设计 |
-| 用户明确提到任务/任务清单有问题 | `TASKS` |
-| 用户明确说「全面审查」或「都看看」 | `FULL` |
-| `05_TASKS.md` 存在，但用户无明确指向 | `DESIGN`，任务审查**按需自适应升级** |
+| 信号 | 推断模式 |
+|------|---------|
+| `05_TASKS.md` 不存在 | `DESIGN` — 只能审查设计 |
+| 用户明确提到任务/任务清单有问题 | `TASKS` |
+| 用户明确提到实现代码 / 交付验收 / 静态代码质检 | `CODE` |
+| 用户明确说「全面审查」或「都看看」 | `FULL` |
+| `05_TASKS.md` 存在，但用户无明确指向 | `DESIGN`，任务审查与代码审查**按需自适应升级** |
 | 本轮是修复后的复查，上轮有任务类问题 | `FULL` |
 
 **如果模式仍不明确，直接询问用户**：
 
-> 本次审查侧重什么？
-> 1. **设计/架构**（design-reviewer）— 架构完整性、接口、运行时行为
-> 2. **任务清单**（task-reviewer）— 任务质量、REQ 覆盖、US 完整性
-> 3. **全面审查**（两者都跑）
-
-**设置** `REVIEW_MODE` = `DESIGN` / `TASKS` / `FULL`，后续步骤依据此值触发。
+> 本次审查侧重什么？
+> 1. **设计/架构**（design-reviewer）— 架构完整性、接口、运行时行为
+> 2. **任务清单**（task-reviewer）— 任务质量、REQ 覆盖、US 完整性
+> 3. **实现代码**（code-reviewer）— 契约忠实度、测试漂移、回流遗漏
+> 4. **全面审查**（全都跑）
+
+**设置** `REVIEW_MODE` = `DESIGN` / `TASKS` / `CODE` / `FULL`，后续步骤依据此值触发。
 
 ---
 
@@ -254,9 +256,9 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 **触发条件**（满足任一即执行，`05_TASKS.md` 必须存在）：
 
 1. `REVIEW_MODE` = `TASKS` 或 `FULL`
-2. **自适应升级**：`REVIEW_MODE` = `DESIGN`，且 design-reviewer 的发现满足以下任一条件：
-   - 存在「架构组件在任务中无覆盖」类问题（对应 task-reviewer Pass D2）
-   - Critical/High 级设计问题超过 3 条，需确认是否已有任务跟进
+2. **自适应升级**：`REVIEW_MODE` = `DESIGN`，且 design-reviewer 的发现满足以下任一条件：
+   - 存在「架构组件在任务中无覆盖」类问题（对应 task-reviewer Pass D2）
+   - Critical/High 级设计问题超过 3 条，需确认是否已有任务跟进
 
 **自适应升级时，询问用户**：
 
@@ -264,19 +266,47 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 > 1. 是，追加 task-reviewer
 > 2. 否，继续
 
-如触发，调用 `task-reviewer` skill：
-- 输入: `{TARGET_DIR}` 下的 `05_TASKS.md`, `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`
-- 输出: 任务审查报告（6-Pass + REQ 覆盖率 + US 完整性 + 问题清单）
-
-**使用方式要求**:
-- 将 `task-reviewer` 视为**规范契约在任务层的承接证据**
-- 优先确认：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴
-
-**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Task review skipped`（附原因）。
-
----
-
-## Step 4: 承诺闭合验证与假设证伪 (Closure Validation)
+如触发，调用 `task-reviewer` skill：
+- 输入: `{TARGET_DIR}` 下的 `05_TASKS.md`, `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`, `04_SYSTEM_DESIGN/`
+- 输出: 任务审查报告（含契约覆盖、基础单测承接、REQ 覆盖率、US 完整性 + 问题清单）
+
+**使用方式要求**:
+- 将 `task-reviewer` 视为**规范契约在任务层的承接证据**
+- 优先确认：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴
+- 额外确认：公共契约是否被任务和验证接住，基础层低依赖逻辑是否被单元测试充分承接，而不是只靠高层集成测试兜底
+
+> [!IMPORTANT]
+> **若 `04_SYSTEM_DESIGN/` 存在，则 task-reviewer 必须读取。**
+> 如任务涉及公共契约而 `04_SYSTEM_DESIGN/` 缺失，不应静默降级，而应在审查中明确标记为“证据不足 / 设计契约缺口”。
+
+**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Task review skipped`（附原因）。
+
+---
+
+## Step 3.7: 代码审查 (Code Review)
+
+**触发条件**（满足任一即执行，`src/` 必须存在）：
+
+1. `REVIEW_MODE` = `CODE` 或 `FULL`
+2. **自适应升级**：`REVIEW_MODE` = `DESIGN` 或 `TASKS`，且发现满足以下任一条件：
+   - 契约已定义、任务已承接，但需要确认实现是否忠于这些承诺
+   - 存在“测试可能只是表面覆盖”的高风险信号
+   - 存在“代码里可能出现未回流的新公共契约”的高风险信号
+
+如触发，调用 `code-reviewer` skill：
+- 输入: 当前工作目录下的 `src/`, `{TARGET_DIR}/01_PRD.md`, `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`, `{TARGET_DIR}/03_ADR/`, `{TARGET_DIR}/04_SYSTEM_DESIGN/`, `{TARGET_DIR}/05_TASKS.md`, 如存在再加 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`
+- 输出: 代码审查报告（Contract Drift / Task Drift / Test Drift / Missing Change Backflow / Foundational Test Gaps + 安全与测试摘要）
+
+**使用方式要求**:
+- 将 `code-reviewer` 视为**实现侧证据层**，不是泛化风格审查器
+- 优先确认：实现是否忠于既有契约与任务承诺，而不是先盯代码美观度
+- 它必须是**纯静态审查**：不启动项目、不跑测试、不修改代码
+
+**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Code review skipped`（附原因）。
+
+---
+
+## Step 4: 承诺闭合验证与假设证伪 (Closure Validation)
 
 **目标**: 识别隐含假设，并验证关键承诺在边界条件下是否**真正闭合**。
 
@@ -293,7 +323,7 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
     | **并发态** | 多用户/并发冲突时，状态与副作用是否可控？ | |
     | **观测态** | 是否留有足够日志/审计证据，同时不扩大泄露面？ | |
 
-2.  **技术与运行健壮性检查**:
+2.  **技术与运行健壮性检查**:
 
     | 检查项 | 问题 | 契约位置 |
     |---------|------|:-------:|
@@ -304,11 +334,21 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
     | **接口定义** | 所有关键 API 都有完整输入/输出/错误 Schema 吗？ | |
     | **配置管理** | 秘钥/配置如何管理？硬编码了吗？ | |
     | **日志监控** | 关键操作有日志吗？日志是否越界记录敏感信息？ | |
-    | **版本控制** | 数据格式/升级如何处理？ | |
-    | **Prompt 模板** | LLM 的 Prompt 有完整定义吗？ | |
-    | **工具定义** | LLM Tool Use 有 JSON Schema 吗？ | |
-
-3.  **记录验证结果**（内部分析可详细，最终报告只保留高信号摘要）:
+    | **版本控制** | 数据格式/升级如何处理？ | |
+    | **Prompt 模板** | LLM 的 Prompt 有完整定义吗？ | |
+    | **工具定义** | LLM Tool Use 有 JSON Schema 吗？ | |
+
+3.  **契约与验证责任闭合检查**:
+
+    | 检查项 | 问题 | 契约位置 |
+    |---------|------|:-------:|
+    | **契约承接** | 所有公共契约是否都有实现任务承接？ | |
+    | **验证承接** | 所有高风险公共契约是否都有至少一层明确验证承接？ | |
+    | **基础单测** | 基础层、共享层、纯逻辑层是否默认获得单元测试承接？ | |
+    | **错误路径** | 契约的失败态、边界态是否有对应测试责任？ | |
+    | **回归责任** | 影响既有关键能力的变更是否有最小回归验证？ | |
+
+4.  **记录验证结果**（内部分析可详细，最终报告只保留高信号摘要）:
 
     ```markdown
     | 项目 | 结论 | 证据 | 对应问题 |
@@ -319,7 +359,20 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
     | 运行态 | Pass / Partial / Fail | ... | CH-04 |
     ```
 
----
+---
+
+## Step 4.5: 审查门禁 (Review Gate)
+
+**目标**: 防止高严重度挑战结果被后续执行链静默绕过。
+
+> [!IMPORTANT]
+> **如果最新 `07_CHALLENGE_REPORT.md` 中存在未处理的 Critical 问题，不得直接进入 `/forge`。**
+>
+> 处理方式：
+> - 通过 `/change` 消化当前版本内可收敛的问题
+> - 或通过 `/genesis` / `/design-system` 重开设计前提
+>
+> 如仅存在 High 问题，可由用户显式签名决定是否继续；AUTO 模式不得自动穿过这一关。
 
 ## Step 5: 生成质疑报告 (Challenge Report)
 
@@ -367,12 +420,13 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 | Low | X |
 | Total Findings | X |
 
-| 证据来源 | 结论 |
-|----------|------|
-| design-reviewer | {执行 / 跳过} |
-| task-reviewer | {执行 / 跳过 / 自适应升级} |
-| Pre-Mortem | {关键结论一句话} |
-| 承诺闭合检查 | {Pass / Partial / Fail} |
+| 证据来源 | 结论 |
+|----------|------|
+| design-reviewer | {执行 / 跳过} |
+| task-reviewer | {执行 / 跳过 / 自适应升级} |
+| code-reviewer | {执行 / 跳过 / 自适应升级} |
+| Pre-Mortem | {关键结论一句话} |
+| 承诺闭合检查 | {Pass / Partial / Fail} |
 
 ---
 
@@ -380,9 +434,9 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 
 | ID | 类别 | 严重度 | 契约/Pass | 位置 | 发现 | 影响 | 建议 |
 |----|------|--------|-----------|------|------|------|------|
-| CH-01 | 承诺失真 | Critical | 错误承诺 | PRD §X / ADR §Y | 默认失败路径未统一，契约未闭合 | 客户端错误处理分叉 | 统一错误语义并补验证任务 |
-| CH-02 | 任务承接 | High | E1 | 05_TASKS.md §X | P0 需求无对应任务 | 核心能力无法落地 | 补充实现与验证任务 |
-| CH-03 | 设计闭合 | Medium | RS-5 | 04_SYSTEM_DESIGN/... | 故障传播路径未说明 | 出现级联失败时难以恢复 | 增加降级与超时策略 |
+| CH-01 | 承诺失真 | Critical | 错误承诺 / Contract Drift | PRD §X / ADR §Y / src/... | 默认失败路径未统一，契约未闭合 | 客户端错误处理分叉 | 统一错误语义并补验证任务或实现修复 |
+| CH-02 | 任务承接 | High | E1 / Task Drift | 05_TASKS.md §X / src/... | P0 需求无对应任务或实现未兑现承接 | 核心能力无法落地 | 补充实现与验证任务 |
+| CH-03 | 设计闭合 | Medium | RS-5 / Code Drift | 04_SYSTEM_DESIGN/... / src/... | 故障传播路径未说明或实现未按设计落地 | 出现级联失败时难以恢复 | 增加降级与超时策略 |
  
 > 仅保留真正影响判断的问题。低价值措辞、泛泛而谈的担忧不要写进表。
  

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

@@ -1,5 +1,5 @@
 ---
-description: "处理当前版本内的局部修订与 task 调整请求，仅适用于已进入 /forge 编码阶段后。编码前的文档/任务调整直接修改即可；重构过大或需要重塑架构时运行 /genesis。"
+description: "处理当前版本内的受控变更与 task 调整，并在需要时升级到 /genesis。适用于已进入 /forge 编码阶段后的文档、契约、测试与任务回流。"
 ---
 
 # /change
@@ -7,17 +7,19 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 <phase_context>
 你是 **CHANGE MANAGER (变更管理师)**。
 
-**核心使命**：
-- 处理当前版本内的**局部修订与 task 调整**。**仅在已进入 `/forge` 编码阶段后使用**；若尚未开始编码，直接修改相关文档即可，无需走本工作流。重构过大或需要重塑架构时运行 `/genesis`。
+**核心使命**：
+- 处理当前版本内的**受控变更、契约回流与 task 调整**。**仅在已进入 `/forge` 编码阶段后使用**；若尚未开始编码，直接修改相关文档即可，无需走本工作流。只有当变更已经改变当前版本的核心前提时，才升级到 `/genesis`。
 
-**核心原则**：
-- **局部修订优先** - 普通文件、设计、任务定义修订默认优先走 `/change`
-- **不偏离 ADR 的 task 调整优先** - 验收标准、估时、优先级、任务编排、少量承接任务补充默认由 `/change` 处理
-- **只改不乱增** - 允许在当前版本内补足必要承接项，但禁止无明确请求的功能蔓延
-- **忠于 Blueprint** - 所有修改必须在 `01_PRD.md` 已定义的需求范围内
-- **人类审批** - 所有写操作必须先展示计划，经人类确认后才能执行
-- **可追溯** - 所有变更都记录在 CHANGELOG
-- **不维护完成状态** - `/change` 只修改任务定义，不负责回填 `05_TASKS.md` checkbox
+**核心原则**：
+- **当前版本内统一入口** - 只要不改变当前版本的核心前提，文档、设计、任务、测试与契约修订默认都走 `/change`
+- **前提判断优先于文件类型** - 是否触发 `/genesis`，取决于是否改变需求/架构前提，而不是是否碰了 PRD、ADR 或 Architecture 文件
+- **任务与契约一起回流** - `/forge` 发现任务不足、契约漂移、验证责任缺失时，应优先回流 `/change`
+- **Git 分支连续性** - `/change` 属于当前版本内修正，继续使用当前 `feature/*` 分支；如需保护点，可在进入 `/change` 前先打 checkpoint commit
+- **只改不乱增** - 允许在当前版本内补足必要承接项，但禁止无明确请求的功能蔓延
+- **忠于 Blueprint** - 所有修改必须在 `01_PRD.md` 已定义的需求范围内
+- **签名机制** - 所有写操作必须先展示计划，经签名后才能执行；`/forge自动` 回流时使用 `AUTO` 签名
+- **可追溯** - 所有变更都记录在 CHANGELOG
+- **不维护完成状态** - `/change` 只修改任务定义，不负责回填 `05_TASKS.md` checkbox
 
 **Output Goal**: 
 - 更新 `.anws/v{N}/05_TASKS.md`
@@ -28,29 +30,32 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 ## ⚠️ CRITICAL 权限边界
 
 > [!IMPORTANT]
-> **`/change` 的权限被严格限定**:
->
-> | 能力 | 允许 | 禁止 |
-> |------|:----:|:----:|
-> | 修改已有任务的描述 | ✅ | |
-> | 修改已有任务的验收标准 | ✅ | |
-> | 调整已有任务的估时 | ✅ | |
-> | 标记任务阻塞/重分优先级 | ✅ | |
-> | 微调 `04_SYSTEM_DESIGN/` 中已有文件的细节 | ✅ | |
-> | 修改当前版本中的普通文档/设计文件细节 | ✅ | |
-> | 为承接已明确请求的局部修订而补充少量必要任务 | ✅ | |
-> | 更新任务说明字段，但不改变完成状态 | ✅ | |
-> | 调整任务编排、Sprint/Wave 内排序（不改变 ADR 前提） | ✅ | |
-> | **回填 `05_TASKS.md` checkbox** | | ❌ |
-> | **创建新文件** | | ❌ |
-> | **添加 AI 自认为好的功能** | | ❌ |
-> | **修改 [REQ-XXX] 需求引用** | | ❌ |
-> | **修改 `01_PRD.md`** | | ❌ |
-> | **修改 `02_ARCHITECTURE_OVERVIEW.md`** | | ❌ |
-> | **修改 `03_ADR/` 中的任何文件** | | ❌ |
-> | **修改系统边界或跨系统架构基线** | | ❌ |
->
-> **违反以上任何一条 → 变更无效，引导用户运行 `/genesis`。**
+> **`/change` 的权限边界以“是否改变当前版本核心前提”为准，而不是以文件类型为准**:
+>
+> | 能力 | 允许 | 禁止 |
+> |------|:----:|:----:|
+> | 修改已有任务的描述 | ✅ | |
+> | 修改已有任务的验收标准 | ✅ | |
+> | 调整已有任务的估时 | ✅ | |
+> | 标记任务阻塞/重分优先级 | ✅ | |
+> | 微调 `04_SYSTEM_DESIGN/` 中已有文件的细节 | ✅ | |
+> | 修改当前版本中的普通文档/设计文件细节 | ✅ | |
+> | 修改 `01_PRD.md` 中**不改变需求前提**的表达/命名/澄清内容 | ✅ | |
+> | 修改 `02_ARCHITECTURE_OVERVIEW.md` 中**不改变架构前提**的表达/命名/澄清内容 | ✅ | |
+> | 修改 `03_ADR/` 中**不改变 ADR 核心决策前提**的接口、命名、契约补全或澄清内容 | ✅ | |
+> | 为承接当前版本内变更创建少量必要文档文件 | ✅ | |
+> | 为承接已明确请求的局部修订而补充少量必要任务 | ✅ | |
+> | 更新任务说明字段，但不改变完成状态 | ✅ | |
+> | 调整任务编排、Sprint/Wave 内排序（不改变 ADR 前提） | ✅ | |
+> | **回填 `05_TASKS.md` checkbox** | | ❌ |
+> | **添加 AI 自认为好的功能** | | ❌ |
+> | **修改 [REQ-XXX] 需求引用** | | ❌ |
+> | **改变需求目标、用户故事集合或需求边界** | | ❌ |
+> | **改变系统边界、跨系统架构基线或关键执行模型** | | ❌ |
+> | **推翻 ADR 的核心决策前提** | | ❌ |
+> | **让当前 `05_TASKS.md` 整体失效、必须整体重建任务树** | | ❌ |
+>
+> **一旦命中禁止项 → 当前版本无法继续承接，升级到 `/genesis`。**
 
 ---
 
@@ -74,19 +79,19 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 
 ## ⚠️ CRITICAL 变更分类
 
-> [!IMPORTANT]
-> **变更分类决定处理方式**:
-> - **局部修订 (Local Refinement)** → 本工作流处理
-> - **受控扩展 (Controlled Expansion)** → 本工作流处理，但必须显式展示影响范围
-> - **架构演进 (Architectural Evolution)** → 引导用户运行 `/genesis`
+> [!IMPORTANT]
+> **变更分类决定处理方式**:
+> - **局部修订 (Local Refinement)** → 本工作流处理
+> - **受控扩展 (Controlled Expansion)** → 本工作流处理，但必须显式展示影响范围
+> - **前提演进 (Foundational Evolution)** → 升级到 `/genesis`
 
-> [!NOTE]
-> **默认判断原则**:
-> 只要变更仍然遵守现有 ADR、系统边界与版本基线，即使需要调整多个 task，也应优先留在 `/change`。
+> [!NOTE]
+> **默认判断原则**:
+> 只要变更不改变当前版本的需求前提、架构前提与任务树可承接性，即使需要调整 PRD、ADR、System Design、TASKS 与测试要求，也应优先留在 `/change`。
 
 ---
 
-## Step 0: 定位当前版本
+## Step 0: 定位当前版本
 
 1.  **扫描版本**:
     扫描 `.anws/` 目录，找到最新版本号 `v{N}`
@@ -99,38 +104,46 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
     - [ ] `{TARGET_DIR}/05_TASKS.md` 存在
     - [ ] `{TARGET_DIR}/06_CHANGELOG.md` 存在
 
-4.  **如果缺失**: 提示先运行 `/genesis` 和 `/blueprint`。
+4.  **如果缺失**: 提示先运行 `/genesis` 和 `/blueprint`。
+
+5.  **Git 分支说明**:
+    - `/change` 不负责切换开发主题分支
+    - 只要仍属于当前版本、当前交付主题，就继续使用当前 `feature/*`
+    - `/change` 结束后回到同一条 `feature/*` 分支继续推进
 
 ---
 
 ## Step 1: 变更影响评估 (分级判定)
 
-**目标**: 判断变更属于局部修订、受控扩展，还是必须升级到 `/genesis` 的架构演进。
-
-> [!IMPORTANT]
-> **你必须逐一回答以下 7 个问题**，并据此给出分级。
-
-| # | 评估问题 | Local / Controlled 条件 |
-|---|---------|---------|
-| 1 | 是否改变系统边界或新增系统? | 否 |
-| 2 | 是否修改 ADR、Architecture Overview 或版本基线? | 否 |
-| 3 | 是否影响多个系统的接口? | 否或影响可控且不改基线 |
-| 4 | 是否需要新增外部依赖 (npm包/API/服务)? | 否或仅限当前版本内小范围可控引入 |
-| 5 | 用户是否明确要求新版本? | 否 |
-| 6 | **是否需要在 `05_TASKS.md` 中新增承接当前变更的少量任务?** | **允许，但必须与用户原话直接对应** |
-| 7 | **变更是否超出 `01_PRD.md` 中已定义的需求范围?** | **否** |
-
-> [!IMPORTANT]
-> **Q6 和 Q7 是核心防线**:
-> - Q6 允许必要的最小承接，但不允许借机注入无关新功能
-> - Q7 阻止了超出 PRD 范围的"功能蔓延"
-> - 当你不确定 Q7 时，**必须读取 `01_PRD.md` 进行验证**，不允许凭印象判断
-> - **如果变更只是为了更好地兑现现有 ADR 与 PRD，应优先判为 `/change` 可处理**
-
-**判定逻辑**:
-- 不改变系统边界 / ADR / 版本基线，且影响半径局部 → **局部修订 (Local Refinement)**
-- 不改变系统边界 / ADR / 版本基线，但需要少量任务、任务重排或设计同步调整以兑现当前版本目标 → **受控扩展 (Controlled Expansion)**
-- 只要触及系统边界、ADR、版本基线，或已经无法在当前 ADR 前提下继续收敛 → **架构演进 (Architectural Evolution)**，跳转 Step 4
+**目标**: 判断变更属于局部修订、受控扩展，还是已经改变当前版本前提，必须升级到 `/genesis`。
+
+> [!IMPORTANT]
+> **你必须逐一回答以下 10 个问题**，并据此给出分级。
+
+| # | 评估问题 | `/change` 条件 |
+|---|---------|---------|
+| 1 | 是否改变需求目标、用户故事集合或需求边界? | 否 |
+| 2 | 是否改变系统边界、关键执行模型或架构基线? | 否 |
+| 3 | 是否推翻 ADR 的核心决策前提? | 否 |
+| 4 | 是否只是表达、命名、接口、契约、示例、测试要求或澄清层面的修订? | 是，或影响可控且不改前提 |
+| 5 | 是否影响多个系统的接口? | 允许，但必须仍不改变前提 |
+| 6 | 是否需要新增外部依赖 (npm包/API/服务)? | 否或仅限当前版本内小范围可控引入，且不改前提 |
+| 7 | 用户是否明确要求新版本? | 否 |
+| 8 | **是否需要在 `05_TASKS.md` 中新增承接当前变更的少量任务?** | **允许，但必须与用户原话或 `/forge` 回流原因直接对应** |
+| 9 | **是否新增或修改公共契约，并需要补充验证承接?** | **允许，但必须显式展示影响范围** |
+| 10 | **当前 `05_TASKS.md` 是否仍可通过局部修订继续承接?** | **是** |
+
+> [!IMPORTANT]
+> **Q8/Q9/Q10 是本工作流的核心防线**:
+> - Q8 允许最小承接任务，但不允许借机注入无关新功能
+> - Q9 让契约补全与测试责任补全明确留在 `/change`
+> - Q10 决定是否还能在当前版本内收敛；若任务树整体失效，必须升级 `/genesis`
+> - **如果变更只是为了更好地兑现现有 PRD / ADR / 设计契约，应优先判为 `/change` 可处理**
+
+**判定逻辑**:
+- 不改变当前版本的需求前提 / 架构前提 / 任务树承接性，且影响半径局部 → **局部修订 (Local Refinement)**
+- 不改变当前版本的核心前提，但需要补充契约、测试责任、少量任务或任务重排以兑现当前版本目标 → **受控扩展 (Controlled Expansion)**
+- 只要改变需求前提、架构前提、ADR 核心前提，或已经无法在当前任务树上继续收敛 → **前提演进 (Foundational Evolution)**，跳转 Step 4
 
 **输出示例**:
 ```markdown
@@ -156,7 +169,7 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 
 ## Step 2: 定位受影响的已有任务
 
-**目标**: 找到受影响的现有任务与文档，并判断是否需要补充最小承接项。
+**目标**: 找到受影响的现有任务、文档与契约，并判断是否需要补充最小承接项。
 
 > [!IMPORTANT]
 > **优先复用已有任务。**
@@ -175,10 +188,10 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
     - 如仅需在当前 ADR 前提下重排任务、调整 Sprint/Wave 归属或补充少量承接项，仍由 `/change` 处理
     - 如需要重做任务结构的根因是 ADR 已不成立或系统边界已变化 → 跳转 Step 4
 
-4.  **定位相关设计文件** (如需要):
-    - 检查 `{TARGET_DIR}/04_SYSTEM_DESIGN/` 中是否有对应的系统设计文件
-    - 仅当任务的修改涉及设计细节时才需要同步修改
-    - **只能修改已有文件，禁止创建新文件**
+4.  **定位相关设计文件** (如需要):
+    - 检查 `{TARGET_DIR}/04_SYSTEM_DESIGN/` 中是否有对应的系统设计文件
+    - 仅当任务的修改涉及设计细节时才需要同步修改
+    - 如为了承接当前版本内的契约补全或测试约束，需要新增少量设计/附录文件，允许创建，但必须在 Step 3 显式展示
 
 5.  **ADR 引用检测** (CRITICAL):
     > [!IMPORTANT]
@@ -187,38 +200,47 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
     > - SYSTEM_DESIGN §8 Trade-offs **只引用 ADR，不复制决策内容**
     > - 修改时：ADR 是源头，SYSTEM_DESIGN 通过引用关联
     
-    **检测规则**:
-    - 如果修改 `04_SYSTEM_DESIGN/` 中的文件：
-      - 扫描文件中是否有 `[ADR-XXX]` 或 `../03_ADR/` 引用
-      - 如果有引用，**必须提醒用户**：该系统设计依赖 ADR 决策
-    - 如果用户请求修改 ADR：
-      - **禁止通过 /change 修改 ADR**（见权限边界表）
-      - 引导用户运行 `/genesis` 创建新版本
-
-6.  **确定修改内容**:
-    对每个受影响的文件，明确要修改什么:
-    - 05_TASKS.md: 描述调整? 验收标准修改? 估时调整? 优先级变更?
-    - 04_SYSTEM_DESIGN: 接口细节? 参数调整? 样式微调?
-    - **ADR 引用**: 如果修改涉及决策，确认是否需要更新 ADR 引用
+    **检测规则**:
+    - 如果修改 `04_SYSTEM_DESIGN/` 中的文件：
+      - 扫描文件中是否有 `[ADR-XXX]` 或 `../03_ADR/` 引用
+      - 如果有引用，**必须提醒用户**：该系统设计依赖 ADR 决策
+    - 如果用户请求修改 ADR：
+      - 先判断是否只是命名同步、接口补全、表达澄清或测试约束补充
+      - 如不改变 ADR 核心决策前提 → 允许通过 `/change` 修改
+      - 如改变 ADR 核心决策前提 → 升级 `/genesis`
+
+6.  **契约与验证承接检查**:
+    - 如变更涉及公共契约（接口、CLI 参数、配置结构、文件格式、错误语义、跨系统协议）
+    - 明确这些契约是否已有任务承接
+    - 如无验证承接，确定是否需要补充验证任务、验收标准或验证说明
+
+7.  **确定修改内容**:
+    对每个受影响的文件，明确要修改什么:
+    - 05_TASKS.md: 描述调整? 验收标准修改? 估时调整? 优先级变更?
+    - 04_SYSTEM_DESIGN: 接口细节? 参数调整? 样式微调?
+    - 01_PRD / 02_ARCHITECTURE_OVERVIEW / 03_ADR: 命名同步? 契约补全? 表达澄清? 测试约束补充?
+    - **验证承接**: 是否需要新增/调整验证类型、验证说明或补充测试任务
+    - **ADR 引用**: 如果修改涉及决策，确认是否需要更新 ADR 引用
 
 ---
 
-## Step 3: 人类确认检查点 ⚠️
-
-**目标**: 展示变更计划，获得人类批准后才能执行。
-
-> [!IMPORTANT]
-> **这是强制检查点。未经人类确认，禁止修改任何文件。**
-> 你必须在此处暂停并等待用户回复。
+## Step 3: 签名检查点 ⚠️
+
+**目标**: 展示变更计划，获得签名后才能执行。
+
+> [!IMPORTANT]
+> **这是强制检查点。未经签名，禁止修改任何文件。**
+> 普通模式下等待用户签名；如本次 `/change` 明确来自 `/forge自动` 的连续回流，则保留完整检查点展示，并以 `AUTO` 作为签名继续执行。
 
 **展示变更计划**:
 
 ```markdown
-⚠️ 人类检查点 — 变更确认
-
-**变更级别**: 局部修订 / 受控扩展
-**用户原始请求**: "{用户原话}"
-**受影响任务**: {N} 个
+⚠️ 签名检查点 — 变更确认
+
+**变更级别**: 局部修订 / 受控扩展
+**用户原始请求**: "{用户原话}"
+**受影响任务**: {N} 个
+**签名**: 用户 / AUTO
 
 ### 修改预览
 
@@ -234,14 +256,15 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 
 ---
 
-请确认: ✅ 批准 / ❌ 拒绝 / ✏️ 调整
-```
-
-- **用户批准** → 继续 Step 3.1 执行修改
-- **用户拒绝** → 终止，不做任何修改
-- **用户调整** → 根据反馈重新制定计划，重新进入 Step 3
-
-### Step 3.1: 执行修改 (仅在人类批准后)
+请签名: ✅ 批准 / ❌ 拒绝 / ✏️ 调整 / AUTO
+```
+
+- **批准** → 继续 Step 3.1 执行修改
+- **拒绝** → 终止，不做任何修改
+- **调整** → 根据反馈重新制定计划，重新进入 Step 3
+- **AUTO** → 仅当本次来自 `/forge自动` 且仍在 `/change` 权限范围内时有效；保留检查点仪式，自动继续执行
+
+### Step 3.1: 执行修改 (仅在签名后)
 
 1.  **修改任务清单**:
     使用 `replace_file_content` 修改 `{TARGET_DIR}/05_TASKS.md` 中的对应任务定义
@@ -264,34 +287,52 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
     - 更新 `最近一次更新` 日期。
     - (注意: 局部修订不改变待办任务数)
 
-4.  **报告**: 告知用户变更已完成。
+4.  **报告**: 告知用户变更已完成。
+
+5.  **最小复核判定**:
+    - 如果本次 `/change` 修改了以下任一内容：
+      - `05_TASKS.md` 中的 `契约承接`
+      - `05_TASKS.md` 中的 `验证类型` / `验证说明`
+      - `04_SYSTEM_DESIGN/`
+      - 公共接口、错误语义、配置结构、文件格式
+    - 则必须追加一次**最小复核**：
+      - 默认先运行 `task-reviewer`
+      - 如触及设计契约，再追加 `/challenge` 或 `design-reviewer`
+    - 生成一段**复核摘要**，至少包含：执行的 reviewer、发现数量、最高严重度、是否允许返回 `/forge`
+    - 如最小复核仍有未处理 Critical → **阻塞**，不得回到 `/forge`
+    - 如仍有未处理 High → 仅允许用户显式签名接受风险后继续；AUTO 不得自动带过
+    - 只有复核通过或用户明确签名接受风险后，才允许回到 `/forge`
 
 ---
 
-## Step 4: 引导超出范围的变更
-
-**目标**: 告知用户需要运行 `/genesis` 创建新版本。
-
-> [!IMPORTANT]
-> **只有触及系统边界、ADR、版本基线或明确的新版本诉求时，才升级到 `/genesis`。**
-> 不要把普通局部修订过度升级为架构演进，也不要把架构演进伪装成 `/change`。
+## Step 4: 升级到 /genesis
+
+**目标**: 告知用户当前变更已经改变版本前提，必须升级到 `/genesis`。
+
+> [!IMPORTANT]
+> **只有当变更改变当前版本的需求前提、架构前提或任务树承接性时，才升级到 `/genesis`。**
+> 不要把普通命名同步、契约补全、测试责任补全过度升级为 `/genesis`，也不要把前提演进伪装成 `/change`。
+
+> [!IMPORTANT]
+> **Git 换轨动作**：
+> 如果本次是从现有 `feature/*` 分支中途升级到 `/genesis`，先冻结当前分支；必要时先创建一个 checkpoint / freeze commit，再从最新 `main` 开新的 `feature/*`` 承接新版本。不要继续在旧分支上混做新版本实现。
 
 ```markdown
-🚫 此变更**超出 /change 的权限范围**。
+🚫 此变更**已超出当前版本可承接范围**。
 
 **评估结果**:
 - [问题 X]: 是 — {理由}
 
-**为什么 /change 不能处理？**
-/change 的职责是处理当前版本内的局部修订与受控扩展，
-但不能改写架构基线、系统边界或版本级决策。
+**为什么 /change 不能处理？**
+/change 的职责是处理当前版本内的受控修订与回流，
+但当前变更已经改变了本版本的需求/架构前提，继续原地修补会破坏版本真相。
 
 **这能防止什么？**
 - ❌ AI 自行添加"觉得好"的功能
 - ❌ 架构文档与实现不一致
 - ❌ 绕过 PRD → 架构 → 任务的完整链条
 
-**建议**: 运行 `/genesis` 创建新的架构版本 `v{N+1}`。
+**建议**: 升级到 `/genesis` 创建新的架构版本 `v{N+1}`。
 
 📋 下一步: `/genesis` (将自动创建 v{N+1})
 ```
@@ -317,11 +358,12 @@ description: "处理当前版本内的局部修订与 task 调整请求，仅适
 
 ---
 
-<completion_criteria>
-- ✅ 完成 7 问题评估 (含 Q6 承接任务检查 + Q7 PRD 范围检查)
-- ✅ 局部修订 / 受控扩展: 定位受影响内容 + 展示计划 + 人类确认 + 执行修改 + 记录 CHANGELOG
-- ✅ 超出范围: 明确告知用户 /change 无权处理，引导 /genesis
-- ✅ 所有写操作前通过了人类检查点
-- ✅ 如有新增任务，必须与用户原话直接对应且影响范围已显式展示
-- ✅ 未添加任何 AI 自认为好的功能
-</completion_criteria>
+<completion_criteria>
+- ✅ 完成 10 问题评估（含契约补全、验证承接与任务树承接性检查）
+- ✅ 局部修订 / 受控扩展: 定位受影响内容 + 展示计划 + 人类确认 + 执行修改 + 记录 CHANGELOG
+- ✅ 超出范围: 明确告知用户 /change 无权处理，引导 /genesis
+- ✅ 所有写操作前通过了人类检查点
+- ✅ 如有新增任务，必须与用户原话直接对应且影响范围已显式展示
+- ✅ 如修改触及契约承接、验证责任或系统设计，已追加最小复核
+- ✅ 未添加任何 AI 自认为好的功能
+</completion_criteria>

package/templates/.agents/workflows/design-system.md

@@ -530,14 +530,16 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 ---
 
-## Step 6: 审核 (Review via /challenge) - 可选
+## Step 6: 审核 (Review via /challenge)
 
 **目标**: 质疑设计决策，识别盲点
 
-> [!IMPORTANT]
-> 这是**可选步骤**，但强烈建议执行。
->
-> **为什么？** 第三方视角能发现设计盲点。
+> [!IMPORTANT]
+> 当系统设计定义了公共接口、CLI 参数语义、配置结构、文件格式、错误语义或跨系统协议时，**此步骤为必需**。
+>
+> **为什么？** 这些契约会直接进入 Blueprint、Change、Forge 和 Challenge 的闭环，缺少审查容易让后续任务和执行漂移。
+>
+> 对这类系统，`11.5 Contract Verification Matrix` 也视为必填内容，不得留空。
 
 **调用方式**:
 ```