@haaaiawd/anws 2.2.4 → 2.2.6

package/README.md

@@ -4,7 +4,7 @@
 <img src="assets/logo-cli.png" width="260" alt="Anws">
 
 [![License: MIT](https://opensource.org/licenses/MIT)](https://opensource.org/licenses/MIT)
-[![Version](https://img.shields.io/badge/version-v2.2.2-7FB5B6)](https://github.com/Haaaiawd/ANWS/releases)
+[![Version](https://img.shields.io/badge/version-v2.2.5-7FB5B6)](https://github.com/Haaaiawd/ANWS/releases)
 [![Targets](https://img.shields.io/badge/Targets-Windsurf%20%7C%20Claude%20Code%20%7C%20Copilot%20%7C%20Cursor%20%7C%20Codex%20Preview%20%7C%20OpenCode%20%7C%20Trae%20%7C%20Qoder%20%7C%20Kilo%20Code-blueviolet)](https://github.com/Haaaiawd/ANWS)
 
 [English](./README.md) | [中文](./README_CN.md)
@@ -36,33 +36,28 @@ Anws enforces design-first principles, preserves context in files, and prevents
 
 ## Why Anws Exists
 
-Modern AI coding sessions fail in predictable ways:
+Many so-called spec systems are good at one thing: generating documents up front. That is not the hard part. The hard part is keeping implementation, verification, review, and upgrades aligned with those documents after the initial planning pass.
 
-- **Architecture drift**
-  - different sessions generate incompatible structures
-- **Context amnesia**
-  - a fresh chat loses system decisions, trade-offs, and task state
-- **Planning collapse**
-  - code gets written before requirements and interfaces are stabilized
-- **Unsafe upgrades**
-  - workflow files change over time, but existing projects cannot be updated cleanly
+That is where AI coding usually breaks down:
 
-Anws addresses those problems with:
+- docs and code drift apart until nobody is sure which one is the real source of truth
+- a new session loses context and starts guessing about boundaries, trade-offs, and task state
+- code starts before requirements and interfaces are stable, so rework becomes inevitable
+- automation increases speed, but review discipline and evidence quality quietly drop
+- template upgrades become risky because existing projects cannot absorb new rules cleanly
 
-- **Versioned architecture docs** under `.anws/v{N}/`
-- **A root anchor file** via `AGENTS.md`
-- **Workflow-first execution** instead of prompt-only improvisation
-- **Controlled update semantics** for `AGENTS.md`, installed targets, and upgrade history
+Anws is not just a system for writing specs. It is a framework for keeping **design, execution, verification, review, and upgrade** tied together.
 
----
-
-## What's New in v2.2.2
-
-**v2.2.2** centers the **`/forge`** chain: **`/forge` AUTO** keeps checkpoint ceremony with **`AUTO`** signatures; **`code-reviewer`** follows **wave cadence** (typically **once per wave** at the wave’s last task, with a **~2–3 wave** catch-up if long skipped—not after every task by default); **`e2e-testing-guide`** is **guide first**, then live browser steps when tooling exists—otherwise **guide-only**, never claim “tested” without evidence. **`/change`** handles doc/task backflow only—it **does not run `code-reviewer`** (static fidelity stays in **`/forge` §3.4.5** and **`/challenge`**).
-
-**v2.2.0** shipped closed-loop **challenge**, explicit contract closure, **`code-reviewer`** as static evidence, forge challenge-report gates, and **`e2e-testing-guide`**. Full history: **[RELEASE_NOTES.md](../RELEASE_NOTES.md)** · [GitHub Releases](https://github.com/Haaaiawd/ANWS/releases).
-
-**v2.0.0** was the protocol-level major (unified **`.anws/`**, controlled **`AGENTS.md`**, multi-target projection). See **[RELEASE_NOTES.md](../RELEASE_NOTES.md)** for the complete major changelog.
+- **Documents are operating state, not attachments**
+  - PRD, Architecture, ADR, System Design, `05A_TASKS.md`, `05B_VERIFICATION_PLAN.md`, and `AGENTS.md` are part of the workflow runtime, not disposable planning notes.
+- **Highly documented, but for control rather than ceremony**
+  - Design, task, and verification are separated on purpose so task ownership, validation responsibility, and evidence output stay traceable.
+- **Automation stays fast without becoming sloppy**
+  - `/forge AUTO` speeds delivery up, but it does not bypass challenge pressure, code review, validation gates, or evidence closure.
+- **It orchestrates verification, not only implementation**
+  - `05A` owns execution flow and `05B` owns verification planning. E2E, for example, is declared as a trigger assumption during planning and executed later in `/forge`, instead of being hand-waved as “already tested.”
+- **Upgrades are controlled, not overwrite-driven**
+  - Templates, projections, and `AGENTS.md` have explicit update semantics, so existing projects can evolve without being effectively reinstalled from scratch.
 
 ---
 
@@ -127,7 +122,7 @@ What using Anws looks like in practice: architecture-first **`/genesis`**, **hum
 ## Philosophy
 
 **1. Docs first—specs keep you in command**  
-PRD, architecture, tasks, and design land in the repo before code does—so the project doesn’t drift in aimless “vibe runs.” Scope and progress live in `.anws/`, `05_TASKS.md`, and **`AGENTS.md`**: you stay **in control of the system**, not whichever chat window is open.
+PRD, architecture, tasks, and design land in the repo before code does—so the project doesn’t drift in aimless “vibe runs.” Scope and progress live in `.anws/`, `05A_TASKS.md`, `05B_VERIFICATION_PLAN.md`, and **`AGENTS.md`**: you stay **in control of the system**, not whichever chat window is open.
 
 **2. Full autonomy inside the rails**  
 **`/forge` AUTO** is delegation with checkpoints: keep moving inside agreed contracts. **Code review**, **e2e-testing-guide**, and the rest of the template gates keep runs **auditable** and **bounded**. When a wave is executing, it’s reasonable to **walk away—coffee, a walk**—because confidence comes from the spec and gates, not from staring at the model.
@@ -149,7 +144,7 @@ Use Anws as a lifecycle, not just a folder pack.
 | `/probe`          | Analyze a legacy codebase before change                                     | Existing code         | Risk report              |
 | `/design-system`  | Design one system in depth                                                  | Architecture overview | System design doc        |
 | `/challenge`      | Review design, tasks, and implementation fidelity with adversarial pressure | Docs / tasks / code   | Challenge report         |
-| `/blueprint`      | Break architecture into executable work                                     | PRD + architecture    | `05_TASKS.md`            |
+| `/blueprint`      | Break architecture into executable work                                     | PRD + architecture    | `05A_TASKS.md` + `05B_VERIFICATION_PLAN.md` |
 | `/forge`          | Turn approved tasks into code with challenge-report and contract gates      | Tasks + review state  | Working implementation   |
 | `/change`         | In-version task/contract tweaks (controlled expansion: few new tasks)       | Small scoped change   | Updated task/design docs |
 | `/explore`        | Research ambiguous or strategic topics                                      | Topic                 | Exploration report       |

package/lib/manifest.js

@@ -44,7 +44,8 @@ const RESOURCE_REGISTRY = [
   { id: 'system-designer-detail-template', type: 'skill', source: '.agents/skills/system-designer/references/system-design-detail-template.md', fileName: 'system-designer/references/system-design-detail-template.md' },
   { id: 'system-designer-template', type: 'skill', source: '.agents/skills/system-designer/references/system-design-template.md', fileName: 'system-designer/references/system-design-template.md' },
   { id: 'task-planner', type: 'skill', source: '.agents/skills/task-planner/SKILL.md', fileName: 'task-planner/SKILL.md' },
-  { id: 'task-planner-template', type: 'skill', source: '.agents/skills/task-planner/references/TASK_TEMPLATE.md', fileName: 'task-planner/references/TASK_TEMPLATE.md' },
+  { id: 'task-planner-template-05a', type: 'skill', source: '.agents/skills/task-planner/references/TASK_TEMPLATE_05A.md', fileName: 'task-planner/references/TASK_TEMPLATE_05A.md' },
+  { id: 'task-planner-template-05b', type: 'skill', source: '.agents/skills/task-planner/references/TASK_TEMPLATE_05B.md', fileName: 'task-planner/references/TASK_TEMPLATE_05B.md' },
   { id: 'task-reviewer', type: 'skill', source: '.agents/skills/task-reviewer/SKILL.md', fileName: 'task-reviewer/SKILL.md' },
   { id: 'tech-evaluator', type: 'skill', source: '.agents/skills/tech-evaluator/SKILL.md', fileName: 'tech-evaluator/SKILL.md' },
   { id: 'tech-evaluator-adr-template', type: 'skill', source: '.agents/skills/tech-evaluator/references/ADR_TEMPLATE.md', fileName: 'tech-evaluator/references/ADR_TEMPLATE.md' },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haaaiawd/anws",
-  "version": "2.2.4",
+  "version": "2.2.6",
   "description": "Anws — A spec-driven workflow framework for AI-assisted development. Empowers prompt engineers to build production-ready software through structured PRD → Architecture → Task decomposition. Works with Claude Code, GitHub Copilot, Cursor, Windsurf, and any tool that reads AGENTS.md.",
   "keywords": [
     "anws",

package/templates/.agents/skills/anws-system/SKILL.md

@@ -1,108 +1,108 @@
----
-name: anws-system
-description: 当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。
----
-
-# ANWS System Router Manual
-
-你是 **ANWS Router**。
-
-你的职责不是直接替代所有工作流，而是作为 **skills-only 模式** 下的统一导航入口：
-
-- 判断当前请求应路由到哪个工作流
-- 告诉模型还需要读取哪个 `references/*.md`
-- 在开始执行前明确权限边界，避免把 `/forge`、`/change`、`/genesis` 混用
-
-## 激活规则
-
-出现以下任一情况时使用本 Skill：
-
-1. 用户不知道该从哪个工作流开始
-2. 用户明确提到 `/quickstart`、`/forge`、`/change`、`/genesis` 等工作流，但当前环境只有 skills
-3. 用户请求涉及“下一步该走哪个流程”
-4. 用户请求跨越设计、任务、实现多个阶段，需要先判断阶段边界
-
-## 首次激活的强制步骤
-
-1. 先读取 `references/quickstart.md`
-2. 判断当前请求更接近哪一种场景
-3. 再按需读取对应 workflow reference
-4. 没有读完对应 reference 前，不得直接执行该 workflow 的写操作
-
-## Workflow Map
-
-- `references/quickstart.md`
-  - 用途：总入口。用于判断项目目前处于哪一阶段，以及应先调用哪个工作流
-- `references/probe.md`
-  - 用途：接手遗留项目、重大改动前做系统风险探测
-- `references/genesis.md`
-  - 用途：新项目、重大重构、架构升级、需要新版本时使用
-- `references/design-system.md`
-  - 用途：为单个系统补详细设计文档
-- `references/blueprint.md`
-  - 用途：将架构设计拆成可执行的 `05_TASKS.md`
-- `references/challenge.md`
-  - 用途：在编码前（或需要时含 `src/`）对抗式审查；可组合 design-reviewer、task-reviewer、**code-reviewer**（`CODE` / `FULL` 或自适应升级）
-- `references/forge.md`
-  - 用途：按 `05_TASKS.md` 执行编码；在验证与提交之间调用 **code-reviewer**（静态忠实度）及按需 **`e2e-testing-guide`**（浏览器/E2E 指南或实测）
-- `references/change.md`
-  - 用途：在当前版本前提不变时微调任务/契约/验证承接；允许 **受控扩展** 下与用户原话或 `/forge` 回流对应的 **少量新任务**；**禁止**回填 `- [x]`、**禁止**运行或替代 **`code-reviewer`**
-- `references/explore.md`
-  - 用途：做调研、探索、方案发散与收敛
-- `references/craft.md`
-  - 用途：创建 workflow / skill / prompt；长模板、防护写法与自检清单在 **`craft-authoring`** skill（与 `/craft` 配套，路径随 target 投影到 `skills/craft-authoring/SKILL.md`）
-- `references/upgrade.md`
-  - 用途：处理 `anws update` 之后的升级编排
-
-## 路由规则
-
-### Route 1: 不确定起点
-
-如果用户不知道从哪里开始，或你对当前阶段没有把握：
-
-1. 读取 `references/quickstart.md`
-2. 根据项目状态判断入口
-3. 给出建议 workflow，并说明理由
-4. 等待用户确认
-
-### Route 2: 请求是“开始编码 / 继续实现 / 做当前波次”
-
-1. 读取 `references/forge.md`
-2. 检查 `.anws/v{N}/05_TASKS.md` 是否存在且任务已定义
-3. 若缺任务清单，不得直接实现，先回到 `blueprint` 或 `genesis`
-4. 若任务含 **E2E / 浏览器手动验证**：在执行路径上读取 **`e2e-testing-guide`** skill（同目录 `skills/e2e-testing-guide/SKILL.md`）；投影环境下路径以目标 IDE 的 `skills/` 为准
-5. 在提交前需要静态契约核对时：读取 **`code-reviewer`** skill。**若宿主支持子代理**（如 Task、并行子会话等）→ **优先委派子代理**按该 skill 专职执行（隔离上下文，输出结构以 skill 为准）。**若无子代理能力** → 由**当前会话**按同一 skill 完整执行（检查清单、证据与输出要求不得缩水）。
-
-### Route 3: 请求是“微调现有任务 / 修正文案 / 调整验收标准 / 受控补任务”
-
-1. 读取 `references/change.md`
-2. 判断变更是否仍属 `/change` 权限（含 **Q8 少量新任务**、契约/验证补全）；若已改动需求/架构/ADR **前提** → `genesis`
-3. **受控扩展**允许少量新任务（须可追溯用户原话或 forge 回流）；**凭空加需求**或版本前提断裂 → `genesis`
-
-### Route 4: 请求是“新项目 / 大重构 / 新版本 / 架构升级”
-
-1. 读取 `references/genesis.md`
-2. 进入版本化架构流程
-
-### Route 5: 请求是“先调研 / 先探测风险”
-
-- 遗留项目或重大变更前 → `references/probe.md`
-- 技术调研或方案发散 → `references/explore.md`
-
-## 边界守则
-
-1. 你是导航层，不是所有 workflow 的替身
-2. 每次只路由到一个主 workflow；如需串联，必须说明顺序
-3. 未读取目标 workflow reference 前，不得假装已经遵循该流程
-4. 若用户请求同时跨越设计与实现，先收敛边界，再决定 `/change` 或 `/genesis`
-5. skills-only 模式下，workflow 详情全部位于 `references/`
-
-## 输出格式
-
-当你完成路由判断时，输出应包含：
-
-- 当前判断的阶段
-- 建议读取的 reference
-- 建议进入的 workflow
-- 为什么不是其他 workflow
-- 是否需要等待用户确认
+---
+name: anws-system
+description: 当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。
+---
+
+# ANWS System Router Manual
+
+你是 **ANWS Router**。
+
+你的职责不是直接替代所有工作流，而是作为 **skills-only 模式** 下的统一导航入口：
+
+- 判断当前请求应路由到哪个工作流
+- 告诉模型还需要读取哪个 `references/*.md`
+- 在开始执行前明确权限边界，避免把 `/forge`、`/change`、`/genesis` 混用
+
+## 激活规则
+
+出现以下任一情况时使用本 Skill：
+
+1. 用户不知道该从哪个工作流开始
+2. 用户明确提到 `/quickstart`、`/forge`、`/change`、`/genesis` 等工作流，但当前环境只有 skills
+3. 用户请求涉及“下一步该走哪个流程”
+4. 用户请求跨越设计、任务、实现多个阶段，需要先判断阶段边界
+
+## 首次激活的强制步骤
+
+1. 先读取 `references/quickstart.md`
+2. 判断当前请求更接近哪一种场景
+3. 再按需读取对应 workflow reference
+4. 没有读完对应 reference 前，不得直接执行该 workflow 的写操作
+
+## Workflow Map
+
+- `references/quickstart.md`
+  - 用途：总入口。用于判断项目目前处于哪一阶段，以及应先调用哪个工作流
+- `references/probe.md`
+  - 用途：接手遗留项目、重大改动前做系统风险探测
+- `references/genesis.md`
+  - 用途：新项目、重大重构、架构升级、需要新版本时使用
+- `references/design-system.md`
+  - 用途：为单个系统补详细设计文档
+- `references/blueprint.md`
+  - 用途：将架构设计拆成可执行的 `05A_TASKS.md`（任务）与 `05B_VERIFICATION_PLAN.md`（验证）
+- `references/challenge.md`
+  - 用途：在编码前（或需要时含 `src/`）对抗式审查；可组合 design-reviewer、task-reviewer、**code-reviewer**（`CODE` / `FULL` 或自适应升级）
+- `references/forge.md`
+  - 用途：按 `05A_TASKS.md` 执行编码，并读取 `05B_VERIFICATION_PLAN.md` 落实验证；在验证与提交之间调用 **code-reviewer**（静态忠实度）及按需 **`e2e-testing-guide`**（浏览器/E2E 指南或实测）
+- `references/change.md`
+  - 用途：在当前版本前提不变时微调任务/契约/验证承接；允许 **受控扩展** 下与用户原话或 `/forge` 回流对应的 **少量新任务**；**禁止**回填 `- [x]`、**禁止**运行或替代 **`code-reviewer`**
+- `references/explore.md`
+  - 用途：做调研、探索、方案发散与收敛
+- `references/craft.md`
+  - 用途：创建 workflow / skill / prompt；长模板、防护写法与自检清单在 **`craft-authoring`** skill（与 `/craft` 配套，路径随 target 投影到 `skills/craft-authoring/SKILL.md`）
+- `references/upgrade.md`
+  - 用途：处理 `anws update` 之后的升级编排
+
+## 路由规则
+
+### Route 1: 不确定起点
+
+如果用户不知道从哪里开始，或你对当前阶段没有把握：
+
+1. 读取 `references/quickstart.md`
+2. 根据项目状态判断入口
+3. 给出建议 workflow，并说明理由
+4. 等待用户确认
+
+### Route 2: 请求是“开始编码 / 继续实现 / 做当前波次”
+
+1. 读取 `references/forge.md`
+2. 检查 `.anws/v{N}/05A_TASKS.md` 与 `.anws/v{N}/05B_VERIFICATION_PLAN.md` 是否存在且已定义
+3. 若缺任务清单，不得直接实现，先回到 `blueprint` 或 `genesis`
+4. 若任务含 **E2E / 浏览器手动验证**：在执行路径上读取 **`e2e-testing-guide`** skill（同目录 `skills/e2e-testing-guide/SKILL.md`）；投影环境下路径以目标 IDE 的 `skills/` 为准
+5. 在提交前需要静态契约核对时：读取 **`code-reviewer`** skill。**若宿主支持子代理**（如 Task、并行子会话等）→ **优先委派子代理**按该 skill 专职执行（隔离上下文，输出结构以 skill 为准）。**若无子代理能力** → 由**当前会话**按同一 skill 完整执行（检查清单、证据与输出要求不得缩水）。
+
+### Route 3: 请求是“微调现有任务 / 修正文案 / 调整验收标准 / 受控补任务”
+
+1. 读取 `references/change.md`
+2. 判断变更是否仍属 `/change` 权限（含 **Q8 少量新任务**、契约/验证补全）；若已改动需求/架构/ADR **前提** → `genesis`
+3. **受控扩展**允许少量新任务（须可追溯用户原话或 forge 回流）；**凭空加需求**或版本前提断裂 → `genesis`
+
+### Route 4: 请求是“新项目 / 大重构 / 新版本 / 架构升级”
+
+1. 读取 `references/genesis.md`
+2. 进入版本化架构流程
+
+### Route 5: 请求是“先调研 / 先探测风险”
+
+- 遗留项目或重大变更前 → `references/probe.md`
+- 技术调研或方案发散 → `references/explore.md`
+
+## 边界守则
+
+1. 你是导航层，不是所有 workflow 的替身
+2. 每次只路由到一个主 workflow；如需串联，必须说明顺序
+3. 未读取目标 workflow reference 前，不得假装已经遵循该流程
+4. 若用户请求同时跨越设计与实现，先收敛边界，再决定 `/change` 或 `/genesis`
+5. skills-only 模式下，workflow 详情全部位于 `references/`
+
+## 输出格式
+
+当你完成路由判断时，输出应包含：
+
+- 当前判断的阶段
+- 建议读取的 reference
+- 建议进入的 workflow
+- 为什么不是其他 workflow
+- 是否需要等待用户确认

package/templates/.agents/skills/code-reviewer/SKILL.md

@@ -2,20 +2,20 @@
 
 ## name: code-reviewer
 
-description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计与 05_TASKS，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 1 §1.4 波前）共用。
+description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计、05A_TASKS 与 05B_VERIFICATION_PLAN，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 3 §3.4.5 波末）共用。
 
 # Code Reviewer — 实现侧证据层
 
 你是 **CODE REVIEWER**。你的职责不是泛化 PR review，也不是风格打分，而是用纯静态证据回答：
 
-> **实现是否忠实兑现了已经写入 PRD / ADR / System Design / 05_TASKS 的承诺？如果没有，风险在哪里，证据是什么？**
+> **实现是否忠实兑现了已经写入 PRD / ADR / System Design / 05A_TASKS / 05B_VERIFICATION_PLAN 的承诺？如果没有，风险在哪里，证据是什么？**
 
 ## 硬边界（必须遵守）
 
 - **纯静态**：不启动项目、不跑 Docker、不自动执行测试、不修改代码、不连外部服务。
 - **不夸大**：运行时、网络、浏览器、外部集成相关结论只能写 **无法通过静态审查确认** 或 **需人工验证**。
 - **证据**：Critical / High / Pass / Fail 等强结论必须带 `**path:line`**。无证据则降级为「疑似」或「无法确认」。
-- **锚点**：判断必须回到 PRD / ADR / System Design / `05_TASKS.md` / 本轮任务描述。
+- **锚点**：判断必须回到 PRD / ADR / System Design / `05A_TASKS.md` / `05B_VERIFICATION_PLAN.md` / 本轮任务描述。
 
 ## 严重级别（与质疑报告对齐）
 
@@ -24,7 +24,7 @@ description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD
 ## 激活时机
 
 - `**/challenge`**：`REVIEW_MODE` = `CODE` / `FULL`，或从 design/task 审查**自适应升级**到实现侧。
-- `**/forge`**：**Step 1 §1.4 波前**门禁（默认**每新波一次**，进入 Step 2 之前；豁免与跳过见 `forge` workflow）。
+- `**/forge`**：Step 3 §3.4.5 波末门禁（本波最后一项任务、§3.4 自动侧通过后，§3.4.6 之前；默认**每波一次**）。`/forge` 在 §3.4.5 之后另有 **§3.4.5.1 极简交付索引表**（workflow 规定，**非**本 skill 的报告体，不得用该表替代正文）。
 
 ## 执行形态（宿主能力）
 
@@ -35,8 +35,9 @@ description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD
 
 1. `src/`（或仓库约定的实现根）
 2. `{TARGET_DIR}/01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/`
-3. `{TARGET_DIR}/05_TASKS.md`
-4. 若存在：`{TARGET_DIR}/07_CHALLENGE_REPORT.md`
+3. `{TARGET_DIR}/05A_TASKS.md`
+4. `{TARGET_DIR}/05B_VERIFICATION_PLAN.md`
+5. 若存在：`{TARGET_DIR}/07_CHALLENGE_REPORT.md`
 
 缺失输入时收缩范围，并在输出中写明。
 
@@ -55,7 +56,7 @@ description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD
 
 ### Lens 2: 任务兑现与交付闭合（Task Fulfillment）
 
-`05_TASKS.md` 的输出、验收标准和边界是否有真实实现/测试/文档产物承接？Mock / Stub / Hardcode 是否有明确边界，是否可能误用于正式路径？
+`05A_TASKS.md` 的输出、验收标准和边界，及 `05B_VERIFICATION_PLAN.md` 的验证方案/证据要求，是否有真实实现/测试/文档产物承接？Mock / Stub / Hardcode 是否有明确边界，是否可能误用于正式路径？
 典型发现：`Task Drift`、`Acceptance Gap`、`Mock Boundary Risk`。
 
 ### Lens 3: 架构适配与复杂度健康（Architecture Fit）