@haaaiawd/anws 2.2.6 → 2.4.0

package/templates/.agents/skills/tech-evaluator/SKILL.md

@@ -1,144 +1,252 @@
----
-
-## name: tech-evaluator
-
-description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
-
-# 技术评估师手册 (The Tech Evaluator's Manual)
-
-> "没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
-
-本技能基于 **SEI 的 ATAM (Architecture Tradeoff Analysis Method)** 和 **加权决策矩阵** 方法论。
-
----
-
-## 强制深度思考
-
-> [!IMPORTANT]
-> 在进行评估之前，你**必须**使用 `sequential-thinking` skill，视复杂情况组织 **3—7 个 thought** 推理。
-> 思考内容例如：
->
-> 1. "用户的核心需求是什么？必须支持哪些场景？"
-> 2. "团队目前熟悉什么技术？学习新技术的时间预算是多少？"
-> 3. "预算约束是什么？云服务成本敏感吗？"
-> 4. "这个项目预期规模是什么？需要支持多少并发用户？"
-> 5. "有没有合规要求（GDPR、等保）影响技术选择？"
-
----
-
-## 任务目标
-
-产出 **ADR (Architecture Decision Record)** 文档，记录技术栈决策及其理由。
-
----
-
-## 评估流程 (The Evaluation)
-
-### 第一步：收集约束 (Gather Constraints)
-
-**必须从用户处获取**:
-
-- **功能需求**: 核心功能列表
-- **非功能需求**: 性能目标、可用性要求、安全等级
-- **团队情况**: 人数、技能栈、学习意愿
-- **预算**: 开发预算、运维预算、时间预算
-- **特殊约束**: 合规要求、现有系统集成、客户指定技术
-
-### 第二步：识别候选技术栈 (Identify Candidates)
-
-**2025 主流技术栈参考**:
-
-
-| 场景         | 推荐栈                         | 备选                          |
-| ---------- | --------------------------- | --------------------------- |
-| **Web 全栈** | Next.js + TypeScript        | Nuxt, SvelteKit             |
-| **后端 API** | Go / Rust / Node.js         | Python FastAPI, Java Spring |
-| **桌面应用**   | Tauri (Rust + Web)          | Electron, Flutter Desktop   |
-| **移动应用**   | React Native / Flutter      | Swift/Kotlin 原生             |
-| **AI/ML**  | Python + PyTorch/TensorFlow | Rust (Candle), Julia        |
-| **数据密集**   | PostgreSQL + TimescaleDB    | ClickHouse, DuckDB          |
-
-
-### 第三步：12 维度评估 (12-Dimension Evaluation)
-
-使用以下矩阵对每个候选栈打分 (1-5 分):
-
-
-| 维度            | 权重建议 | 评估问题            |
-| ------------- | ---- | --------------- |
-| **需求匹配**      | —    | 能否实现所有核心功能？     |
-| **扩展性**       | —    | 能否支撑 10x 增长？    |
-| **性能**        | —    | 能否满足响应时间/吞吐量要求？ |
-| **安全性**       | —    | 内置安全特性？合规支持？    |
-| **团队技能**      | —    | 团队熟悉程度？学习曲线？    |
-| **人才市场**      | —    | 招人容易吗？          |
-| **开发速度**      | —    | 能否快速迭代？         |
-| **TCO (总成本)** | —    | 开发+运维+许可证成本？    |
-| **社区生态**      | —    | 库/工具丰富度？问题解答速度？ |
-| **长期维护**      | —    | 技术寿命？LTS 支持？    |
-| **集成能力**      | —    | 与现有系统/第三方服务集成？  |
-| **AI 就绪**     | —    | 集成 AI/LLM 的便利性？ |
-
-
-### 第四步：权衡分析 (Trade-off Analysis)
-
-使用 **ATAM 方法**:
-
-1. 识别**质量属性场景** (如 "1000 并发用户时响应 < 200ms")
-2. 评估每个候选栈对场景的**支持程度**
-3. 识别**权衡点** (如 "选 Go 性能好但团队需学习")
-4. 识别**风险点** (如 "选新框架可能踩坑")
-
-### 第五步：产出 ADR (Generate ADR)
-
-你**必须**创建 `ADR_001_TECH_STACK.md`，并将其写入 `.anws/v{N}/03_ADR/`。
-
----
-
-## ADR 输出模板
-
-```markdown
-# ADR-001: 技术栈选择
-
-## 状态
-Accepted / Proposed / Deprecated
-
-## 背景
-[项目背景和约束描述]
-
-## 决策
-[选择的技术栈及核心理由]
-
-## 候选方案对比
-
-| 候选 | 总分 | 优势 | 劣势 |
-|------|------|------|------|
-| 方案 A | 42/60 | ... | ... |
-| 方案 B | 38/60 | ... | ... |
-
-## 权衡点
-- [权衡 1]
-- [权衡 2]
-
-## 后果
-- 正面: [...]
-- 负面: [...]
-- 需要的后续行动: [...]
-```
-
----
-
-## 老师傅守则
-
-1. **"无聊"技术优先**: 除非有充分理由，优先选择成熟稳定的技术。
-2. **创新预算有限**: 每个项目只有 1-2 个"创新点"配额，其余用"无聊"技术。
-3. **团队能力为王**: 再好的技术，团队不会用也是白搭。
-4. **TCO 不只是钱**: 时间成本、认知成本也是成本。
-
----
-
-## 工具箱
-
-- `references/ADR_TEMPLATE.md`: ADR 模板
-- `references/TECH_RADAR_2025.md`: 2025 技术雷达参考
-
+---
+name: tech-evaluator
+description: 【ALPHA】服务于 `/genesis` Step 3「技术选型」：以 ATAM 与 12 维加权矩阵评估候选栈，产出可追溯的对比结论与 ADR 升格素材；不写正式 ADR 文件（落盘在 Step 5）。与 shipped `templates/` 中同名 skill 同源；优先读本 bundle 内同相对路径的 references。
+---
+
+# 技术评估师手册 — 【ALPHA】Genesis Step 3
+
+> "没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
+
+本技能基于 **SEI 的 ATAM (Architecture Tradeoff Analysis Method)** 与 **加权决策矩阵**。在 **`templates_alpha/`** / **`templates_alpha_en/`** ALPHA 工作流中与 `/genesis` 绑定为 **Step 3**；ADR 的**正式写入**与编号治理以 **Step 5** 与 `genesis.md` 为准。
+
+---
+
+## CRITICAL /genesis 门禁（与 shipped skill 的差异收口）
+
+> [!IMPORTANT]
+>
+> - **`/genesis` Step 3**：**只输出评估结果与 Markdown 对比素材**，**不得**在本步创建或修改 `.anws/v{N}/03_ADR/` 下任何 ADR 文件。原因见 `genesis.md` Step 3 / Step 5：ADR 为正式决策记录，须在 Step 5 完整审视后落盘。
+> - **Step 5 落盘目标**（供下游引用，非 Step 3 执行项）：将 Step 3 对比表升格为 `.anws/v{N}/03_ADR/ADR_001_TECH_STACK.md`（及姊妹 ADR），**章节结构以 `references/ADR_TEMPLATE.md` 为唯一权威**。
+> - 若宿主会话声明 **非** `/genesis` 或显式授权「本步即写 ADR」，以**当场工作流**为准；默认仍按 Step 3 不写 ADR。
+
+> [!NOTE]
+> **ADR 时序**：Step 3 只产出评估与对比素材，不写 `03_ADR/`；Step 4 产出系统边界与 `02_*`；Step 5 再升格 ADR，使影响范围与真实系统 ID 对齐。阶段表与四点论证见 **`genesis.md`** Step 3 的 NOTE。若会话非 `/genesis` 或用户授权本步写 ADR，以当场工作流为准。
+
+---
+
+## CRITICAL spec 产出契约（Step 3 交付物）
+
+> [!IMPORTANT]
+>
+> - **可核对**：约束块须覆盖功能需求、非功能需求、团队、预算、特殊约束；缺的项写「未提供—评估基于假设 H-…」，不得静默省略。
+> - **可计算**：每个候选栈须有 12 维得分表（1–5）或逐维「不适用 + 原因」；禁止只给总分不给细表。
+> - **可推演**：ATAM 段落须含至少一个**质量属性场景**、若干**权衡点**、若干**风险点**；不得用形容词堆叠代替场景。
+> - **可升格**：最终对比表须能**无损映射**到 **`references/ADR_TEMPLATE.md`** 的章节与必填节，供 Step 5 粘贴与润色。
+> - **验证策略显式**：须回答或标注待决：单测 / 集成 / E2E 侧重、冒烟 / 回归门禁、质量门禁落在 PR / INT / 预发 / 发布的哪一层（与 `genesis.md` Step 3 要求一致）。
+> - **单一真源**：数值与结论以 Step 3 产出表为准；Step 5 仅做编辑与状态流转，不得在无新证据时反向改分。
+
+---
+
+## 强制深度思考
+
+> [!IMPORTANT]
+> 在开始评估前**必须**调用 `sequential-thinking` skill，按复杂度组织 **3—7 个 thought**，例如：
+>
+> 1. 用户核心场景与必须支持的用例边界是什么？
+> 2. 团队熟悉度与可接受的学习成本？
+> 3. 预算与云 / 许可证 TCO 敏感度？
+> 4. 预期规模与并发 / 数据量级？
+> 5. 合规（GDPR、等保等）是否一票否决某些栈？
+
+---
+
+## 任务目标（Step 3）
+
+在**不写 ADR 文件**前提下，产出：
+
+1. 结构化**约束摘要**与**候选栈列表**；
+2. **12 维打分矩阵**与加权汇总说明（权重须声明或采用本文建议并说明）；
+3. **ATAM 权衡与风险**短文；
+4. 供 Step 5 直接使用的 **Markdown 候选方案对比总表**。
+
+---
+
+## 评估流程 (The Evaluation)
+
+### 第一步：收集约束 (Gather Constraints)
+
+**必须从用户或已加载工件取得**（不足的按 spec 契约标注假设）：
+
+- **功能需求**：核心能力列表（可引用 `01_PRD.md`）。
+- **非功能需求**：性能、可用性、安全等级。
+- **团队情况**：人数、技能栈、学习意愿。
+- **预算**：开发、运维、时间。
+- **特殊约束**：合规、存量系统集成、客户指定技术。
+- （如已执行 Step 2.5）`/explore` 研究结论中的证据与备选方案。
+
+#### 做什么
+
+固化输入边界，列出缺口与假设编号。
+
+#### 为什么
+
+避免无约束的偏好打分和不复现的结论。
+
+#### 怎么验收
+
+输出中可出现「假设 H-xx」对照表；无静默缺项。
+
+---
+
+### 第二步：识别候选技术栈 (Identify Candidates)
+
+**主流技术栈参考**（可按项目替换或增删）：
+
+
+| 场景         | 推荐栈                         | 备选                          |
+| ---------- | --------------------------- | --------------------------- |
+| **Web 全栈** | Next.js + TypeScript        | Nuxt, SvelteKit             |
+| **后端 API** | Go / Rust / Node.js         | Python FastAPI, Java Spring |
+| **桌面应用**   | Tauri (Rust + Web)          | Electron, Flutter Desktop   |
+| **移动应用**   | React Native / Flutter      | Swift/Kotlin 原生             |
+| **AI/ML**  | Python + PyTorch/TensorFlow | Rust (Candle), Julia        |
+| **数据密集**   | PostgreSQL + TimescaleDB    | ClickHouse, DuckDB          |
+
+
+#### 做什么
+
+列出 2 个及以上**具名**候选（语言 / 框架 / 关键中间件级），附一句选型范围说明。
+
+#### 为什么
+
+单候选无权衡，无法完成 ATAM。
+
+#### 怎么验收
+
+每个候选可被独立打分；无匿名「方案 A/B」。
+
+---
+
+### 第三步：12 维度评估 (12-Dimension Evaluation)
+
+对每个候选按 1–5 分打分：
+
+
+| 维度            | 权重建议 | 评估问题            |
+| ------------- | ---- | --------------- |
+| **需求匹配**      | —    | 能否实现所有核心功能？     |
+| **扩展性**       | —    | 能否支撑 10x 增长？    |
+| **性能**        | —    | 能否满足响应时间 / 吞吐量？ |
+| **安全性**       | —    | 内置安全与合规支持？      |
+| **团队技能**      | —    | 熟悉度与学习曲线？       |
+| **人才市场**      | —    | 招聘与外包可得性？       |
+| **开发速度**      | —    | 迭代与交付速度？        |
+| **TCO (总成本)** | —    | 开发 + 运维 + 许可证？   |
+| **社区生态**      | —    | 库、工具与排障资源？      |
+| **长期维护**      | —    | 技术寿命与 LTS？       |
+| **集成能力**      | —    | 与存量与第三方集成？      |
+| **AI 就绪**     | —    | 接入 AI / LLM 的便利度？ |
+
+
+#### 做什么
+
+填满矩阵；声明权重（均匀或加权）并计算可比总分或档级。
+
+#### 为什么
+
+多维透明，便于 Step 5 写入 ADR 证据节。
+
+#### 怎么验收
+
+表在 Markdown 中可复算；不适用维度有单行解释。
+
+---
+
+### 第四步：权衡分析 (Trade-off Analysis) — ATAM
+
+1. 识别**质量属性场景**（例：「1000 并发用户时 P95 < 200ms」）。
+2. 各候选对该场景的**支持程度**分级说明。
+3. 列出**权衡点**（例：性能好 vs 团队学习成本）。
+4. 列出**风险点**（例：新版本框架成熟度）。
+
+#### 做什么
+
+把「为什么不是第二名」说清楚。
+
+#### 为什么
+
+ADR 核心价值在取舍与后果，不单是赢家声明。
+
+#### 怎么验收
+
+至少 1 个场景 + 若干权衡 / 风险，可与候选表交叉引用。
+
+---
+
+### 第五步：产出 ADR 升格素材（Step 3，非落盘）
+
+在 **`/genesis` Step 3** 下，你**不得**新建或修改 `03_ADR/*.md`。产出完整 **Markdown** 对比结论与升格素材，使 Step 5 能对照 **`references/ADR_TEMPLATE.md`** 无损升格；段落与章节可标 `Proposed` / `待定`。
+
+若工作流显式要求本步预创建占位文件（极少见），仅允许空文件或 MANIFEST 约定路径，**不得**将占位等同于已接受 ADR。
+
+**禁止**：在本 SKILL 内再嵌一套与 **`references/ADR_TEMPLATE.md`** 重复的完整 ADR 范文；章节疑问一律以该文件为准。
+
+#### 做什么
+
+生成完整对比与符合 `references/ADR_TEMPLATE.md` 场域的草稿（内存或会话消息中的 Markdown）。
+
+#### 为什么
+
+与 `genesis` 决策关口对齐，避免未成文的早期 ADR。
+
+#### 怎么验收
+
+父代理能在 Step 5 打开 `references/ADR_TEMPLATE.md` 并对齐各节而无信息断档。
+
+---
+
+## 老师傅守则
+
+1. **"无聊"技术优先**：除非有充分理由，选成熟栈。
+2. **创新预算有限**：每项目 1–2 个创新点配额，其余求稳。
+3. **团队能力为王**：再好的技术用不了等于零。
+4. **TCO 不只是钱**：时间与认知负载计入成本。
+
+---
+
+## references 与同 bundle 路径说明
+
+本 bundle 在 **`templates_alpha/.agents/skills/tech-evaluator/references/`** 已包含与 shipped **`templates/`** 镜像的 **`ADR_TEMPLATE.md`**。读取时 **仅以本 SKILL 旁 `references/`** 为准；**禁止**同一会话与 shipped `templates/.agents/skills/tech-evaluator/` 混读同名条文。
+
+| 文件 | 用途 |
+|------|------|
+| `references/ADR_TEMPLATE.md` | ADR 体格与必填节 |
+
+---
+
+## 执行形态与子代理编排
+
+### 做什么
+
+- **优先**：若宿主提供 **AGENT / 子代理**：可委派**候选搜集**、**单候选多维打分草稿**或 **ATAM 风险草案**；编排侧下发本文 **spec 产出契约 + 门禁 + ADR 模板字段**，收束后为**单一合并稿**。
+- **父代理**：持有 `sequential-thinking` **必须**在主会话或由明确指定的合并代理执行一轮完整 thought 链后再定稿；子代理不可替代该义务除非工作流写明。
+- **回退**：无子代理时，由当前会话完整执行全流程。
+
+### 为什么
+
+并行搜集与串行裁决分离，降低遗漏维度的概率。
+
+### 怎么验收
+
+合并稿仍满足 spec 契约；无互相矛盾的分数或重复候选名；`/genesis` Step 3 **仍无** `03_ADR` 写操作。
+
+---
+
+## Handoff checklist（编排 / 子代理 / Step 5）
+
+- [ ] 约束与假设 H-xx 已列全或显式欠缺已声明。
+- [ ] 12 维矩阵 + 权重说明完整。
+- [ ] ATAM：场景、权衡、风险齐全。
+- [ ] Markdown 对比表可映射 `references/ADR_TEMPLATE.md`。
+- [ ] 验证策略与测试分层门禁已作答或单列「待 Step 5 / design-system」。
+- [ ] **`/genesis` Step 3**：确认未创建 / 修改 `03_ADR/*.md`。
+
+---
+
+<completion_criteria>
+- `sequential-thinking` 已完成 3—7 thought，且可在输出中见其结论被评估吸收。
+- 交付物满足 **CRITICAL spec 产出契约**（可核对 / 可计算 / 可推演 / 可升格 / 验证策略显式）。
+- 在 `/genesis` Step 3 默认路径下，**未**对 `.anws/v{N}/03_ADR/` 进行 ADR 落盘。
+- Handoff checklist 全部为真或显式豁免项已记入最后一节「未决事项」。
+- 若装载自 `templates_alpha` 或 `templates_alpha_en`，与本次会话其他 skill 取自**同一 overlay 树**，不与 shipped `templates/` 混用同一步骤的异版 skill，以免门禁语义漂移。
+</completion_criteria>

package/templates/.agents/workflows/blueprint.md

@@ -1,77 +1,200 @@
 ---
-description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_VERIFICATION_PLAN.md，并完成收口检查。"
+description: "【ALPHA】编排 /blueprint：基于已批准设计输入生成 05A/05B；宿主只保留序、门禁与移交契约；字段与模板以 **本 overlay** `.agents/skills/task-planner/`（与 shipped `templates/` 同源镜像）为唯一权威。"
 ---
 
-# /blueprint
+# /blueprint (ALPHA)
 
-你是 **TASK ARCHITECT (任务规划师)**。
+<phase_context>
+你是 **TASK ARCHITECT（任务规划师）— ALPHA 线**。
 
-## 目标
+**使命**：把已批准的设计输入编排为可执行的 `05A_TASKS.md` 与 `05B_VERIFICATION_PLAN.md`，并跑通收口门禁。  
+**能力**：版本定位、前置校验、契约映射、调用 `task-planner`、收口检查、`AGENTS.md` 双文档入口更新。  
+**限制**：只做编排与关卡；**不**在宿主内复述 `task-planner` 的字段级规范或粘贴 `TASK_TEMPLATE_*` 全文；**不**在 Step 2 之前预读 `task-planner`（见下文 **预读门禁**）。  
+**与用户的关系**：交付可验证的任务/验证骨架与追溯链，不越权执行实现或 E2E。  
+**Output Goal**：`.anws/v{N}/05A_TASKS.md` + `.anws/v{N}/05B_VERIFICATION_PLAN.md`。
+</phase_context>
 
-- 产出 `.anws/v{N}/05A_TASKS.md`（执行主清单）
-- 产出 `.anws/v{N}/05B_VERIFICATION_PLAN.md`（验证计划）
+---
+
+## CRITICAL 凝练与版式（/craft + /challenge 思想）
+
+> [!IMPORTANT]
+> **craft**：改稿前 Read shipped `.agents/skills/craft-authoring/SKILL.md` 与 `.agents/workflows/craft.md`；各 `## Step …` 使用 **`### 做什么` / `### 为什么` / `### 怎么验收`**；文末 `<completion_criteria>` 必填。  
+> **凝练**：会话与对用户的说明 **一句一事**；与 `task-planner` 重复的表格口径 **只保留在 SKILL/references**。  
+> **不注入**：不在本 workflow 粘贴 `TASK_TEMPLATE_05A` / `TASK_TEMPLATE_05B` 大段或示例任务块——**唯一权威**见下文 **task-planner 路径**。
 
 ---
 
-## 编排边界
+## CRITICAL 编排约束（规范闸门不可削弱）
+
+> [!IMPORTANT]
+> **task-planner 唯一权威（字段 / 表结构）**  
+> 读取 **本 overlay** `.agents/skills/task-planner/SKILL.md`（与 shipped `templates/` 同名路径**同源镜像**；**禁止**同会话混读 shipped 树与 alpha 树两套条文）。  
+> `.agents/skills/task-planner/references/TASK_TEMPLATE_05A.md`  
+> `.agents/skills/task-planner/references/TASK_TEMPLATE_05B.md`  
+>
+> - 输入文档（`01` / `02` / `03` / 条件 `04`）是拆解的**唯一事实源**。  
+> - 若上游规范冲突，**修正 SKILL/references 事实源**；禁止仅在 `blueprint.md` 内打补丁稀释权威。  
+> - **仅在 05A/05B 记录** E2E 触发条件、范围与证据预期；**`/blueprint` 阶段不得执行 `e2e-testing-guide`**。  
+>
+> **格言**：带着已知契约缺口调用 `task-planner`，等于把技术债**分期付款**写进 sprint。
+
+---
 
-`/blueprint` 只负责流程编排与关卡校验，不重复维护详细模板。  
-任务字段、验证字段、示例格式以 `task-planner/SKILL.md` 与 `references/TASK_TEMPLATE_05A.md`、`references/TASK_TEMPLATE_05B.md` 为唯一事实源。
+## CRITICAL 与 task-planner 配合契约（宿主 → SKILL）
+
+> [!IMPORTANT]
+> **预读门禁**  
+> **禁止**在 Step 0–1.5 预读 `task-planner/SKILL.md` 或 `TASK_TEMPLATE_*`（避免先背版式再凑合输入）。**仅当**进入 **Step 2** 且即将按 SKILL 执行拆解时，再读取 **`.agents/skills/task-planner/SKILL.md`** 与按需打开的 **references**；读完后立刻消费 Step 1 的契约映射，不在无关步骤复读 SKILL。
+>
+> **移交包（进入 Step 2 时须显式交给 task-planner 执行上下文）**  
+> 以下用**短列表或路径清单**即可（不必贴进 05A/05B）：
+>
+> - `TARGET_DIR`；本回合已读**真实路径**列表：`01`、`02`、`03_ADR/`（及已纳入的 `04_SYSTEM_DESIGN/` 文件）。  
+> - Step 1 产出的 **契约表**：每条含「契约类型/名称 → 拟承接的 05A 意图 + 拟承接的 05B 验证意图」（与 SKILL「契约覆盖规则」可逐条对读）。  
+> - 若 ADR 含**测试策略 / 质量门禁**：注明 **ADR 文件路径 + 条目/小节锚点**，满足 SKILL「若 ADR 中存在测试策略/质量门禁，必须优先遵循」。  
+> - **WBS Level-1 系统 ID** 必须与 `02_ARCHITECTURE_OVERVIEW` 系统清单一致，**禁止**发明未在 `02` 出现的系统代号。  
+> - PRD 中 `[REQ-*]`：要求任务行挂载关系由 SKILL 与模板约束；宿主须抽查「关键 REQ 未悬空」。
+>
+> **与 SKILL 硬约束对齐（宿主在 Step 2–4 负责盯紧，不替 SKILL 写字段定义）**  
+> 除上文 CRITICAL 与 Step 2 已列外，`task-planner` 尚含下列**不可被落盘结果违背**的条文类别——若产出违反，须**回 Step 2** 让 planner 迭代，**禁止**仅在 blueprint 会话里用自由表格「补丁冒充完成」：
+>
+> - **测试标准**：项目级须同时规划 **单元测试** 与 **API 接口功能测试**（见 SKILL「测试标准（硬约束）」）。  
+> - **05B 结构**：**Contract Coverage Overlay**、**Testing Coverage Overlay**、**Verification Traceability Matrix** 三章为硬性必选（见 SKILL 声明）。  
+> - **E2E 边界**：仅记录触发/范围/证据预期；**不**执行 `e2e-testing-guide`。  
+> - **反膨胀**：风险类别闭合优先，禁止无差别组合爆炸（见 SKILL「反测试膨胀原则」）。  
+> - **任务质量**：单 Task 粒度 **2h–2d**、依赖边须 **输入/输出产物对齐**（见 SKILL「任务质量守则」）；**INT-S{N}** 为 Sprint 关门任务，冒烟优先绑 INT。  
+>
+> **落盘对账**  
+> Step 3 写盘之后，Step 4 检查清单须与 SKILL 末节 **「输出质量检查」** 逐项对读；缺任一项 → **回 Step 2** 补一轮 planner，直至对账通过。
 
 ---
 
 ## Step 0: 定位版本与前置检查
 
-1. 扫描 `.anws/` 找到最新 `v{N}`，设定 `TARGET_DIR = .anws/v{N}`。
-2. 必需文件：
-   - `{TARGET_DIR}/01_PRD.md`
-   - `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`
-3. 条件必需：
-   - 若版本涉及公共契约（HTTP API、CLI 参数语义、配置结构、文件格式、错误语义、跨系统协议、持久化结构），`{TARGET_DIR}/04_SYSTEM_DESIGN/` 视为必需。
-4. 若前置不满足：停止并提示先运行 `/genesis` 或 `/design-system`。
+### 做什么
+
+1. 扫描 `.anws/` 取最新 `v{N}`，设 `TARGET_DIR = .anws/v{N}`。  
+2. **必需**：`{TARGET_DIR}/01_PRD.md`、`{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`。  
+3. **条件必需**：若本版涉及公共契约（HTTP API、CLI 语义、配置/文件格式、错误语义、跨系统协议、持久化结构等），`{TARGET_DIR}/04_SYSTEM_DESIGN/` **视为必需**。  
+4. 若不满足：停止，提示先 `/genesis` 或 `/design-system`。
+
+### 为什么
+
+无版本锚点与输入契约，`05A/05B` 会与真实架构脱节。
+
+### 怎么验收
+
+- 会话内可复述 `TARGET_DIR` 与「缺哪份输入导致停止」。  
+- 条件必需触发时，**未**在缺 `04` 的情况下继续调用 planner。
 
 ---
 
 ## Step 1: 加载输入并建立契约映射
 
-1. 读取 `01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`（以及存在时的 `04_SYSTEM_DESIGN/`）。
-2. 从输入中提取公共契约与风险点。
-3. 形成契约映射规则（供 `task-planner` 执行）：
-   - 每个公共契约至少有一个实现承接任务（05A）
-   - 每个高风险公共契约至少有一个验证承接点（05B）
-   - 禁止把契约验证责任全部后移到高层集成或 E2E
+### 做什么
+
+1. 读取 `01`、`02`、`03_ADR/`（及存在/必需时的 `04_SYSTEM_DESIGN/`）。  
+2. 抽出**公共契约**与高风险点。  
+3. 形成交给 `task-planner` 的**硬约束**（口述或短列表即可，字段名遵从 SKILL）：  
+   - 每个公共契约至少一条 **05A 实现承接**；  
+   - 每个高风险公共契约至少一条 **05B 验证承接**；  
+   - **禁止**把契约验证责任全部后推到高层集成或 E2E。
+
+### 为什么
+
+planner 只负责拆解形态；**谁该实现、谁该证明**，必须在编排层先钉死。
+
+### 怎么验收
+
+- 能列出至少三条「契约 → 05A/05B 承接」映射，且无「全部推 E2E」式逃避。
 
 ---
 
-## Step 2: 调用 task-planner 生成 A/B 双文档
+## Step 1.5: 编排思考准绳（进入 planner 前）
+
+### 做什么
 
-调用 `task-planner`，并显式传递约束：
+快速自检三项（任一项失败则回到 Step 1 修映射，**再**调 planner）：
 
-- 输入文档是唯一事实来源
-- 若 ADR 存在测试策略与质量门禁，必须优先遵循
-- 验证类型按“最轻但足够”选择，避免 E2E 滥用
-- 单元测试与 API接口功能测试必须同时规划
-- 冒烟测试优先绑定 `INT-S{N}` 里程碑任务
-- 仅在 `05A/05B` 中记录 E2E 触发条件、范围与证据预期；**不得在 `/blueprint` 阶段执行 `e2e-testing-guide`**
+1. **真实性**：任务树是否承接**外部可观察契约**，而非仅堆砌实现动作。  
+2. **风险闭合**：高风险契约是否在 05B 有**明确、可降级**的验证落点（非盲目堆 E2E）。  
+3. **可验收**：Sprint/INT 关口是否可被日志/报告/截图等客观证据验证。
+
+### 为什么
+
+否则 planner 只会把混乱拆成更多行。
+
+### 怎么验收
+
+- 三项均有**是/否+一句理由**；若有「否」，会话显示已回退修补后再前进。
 
 ---
 
-## Step 3: 收口写入
+## Step 2: 调用 task-planner 生成 05A / 05B
+
+### 做什么
 
-1. 保存：
-   - `.anws/v{N}/05A_TASKS.md`
-   - `.anws/v{N}/05B_VERIFICATION_PLAN.md`
-2. 在 `05A_TASKS.md` 中保留执行主线内容（WBS、依赖、Sprint、INT、User Story Overlay）。
-3. 在 `05B_VERIFICATION_PLAN.md` 中保留验证主线内容（Task-by-Task、Contract Coverage Overlay、Testing Coverage Overlay、Verification Traceability Matrix）。
-4. 更新 `AGENTS.md` 的 A/B 文档入口状态块。
+1. **本步开头**再读取 **`.agents/skills/task-planner/SKILL.md`**（及按需打开 `references/TASK_TEMPLATE_05A.md`、`TASK_TEMPLATE_05B.md`），按 SKILL 协议调用。  
+2. 将 **「CRITICAL 与 task-planner 配合契约」** 中的 **移交包** 全文交给 planner 执行上下文（路径、契约表、ADR 测试锚点、系统 ID 对齐声明）。  
+3. 显式传递（口径以 SKILL 为准，此处只列**门禁意图**）：输入为唯一事实源；ADR 测试策略与质量门禁**优先**；验证 **最轻但足够**；单元 + **API 接口功能测试**必规划；冒烟优先 `INT-S{N}`；E2E 仅记触发与证据预期，**不执行** e2e skill。  
+4. 产出须可逐条对照 SKILL **「输出质量检查」**；若本轮未过，**在同一 Step 内**修订映射或补读输入后再次走 planner，**不**前进到 Step 3。
+
+### 为什么
+
+字段与表结构以 SKILL 为真源；宿主负责 **移交完整 + 对账 SKILL 硬约束**，避免「调了 skill 但上下文半截」。
+
+### 怎么验收
+
+- 会话内可见：已读 SKILL 路径 + 移交包要点 + 一轮 planner 结果；或与用户约定的手工等效（须声明）且仍通过 Step 4 与 SKILL 输出质量检查对读。
+
+---
+
+## Step 3: 收口写入与状态更新
+
+### 做什么
+
+1. 将产物保存为 `{TARGET_DIR}/05A_TASKS.md` 与 `{TARGET_DIR}/05B_VERIFICATION_PLAN.md`。  
+2. `05A` 保留执行主线（WBS、依赖、Sprint、INT、User Story Overlay 等——**小节名与必填列**以 TASK_TEMPLATE_05A 为准）。  
+3. `05B` 保留验证主线（Task-by-Task、Contract Coverage、Testing Coverage、Traceability Matrix 等——以 TASK_TEMPLATE_05B 为准）。  
+4. 更新 `AGENTS.md` 中 **05A/05B 文档入口**状态（**不**在此粘贴长模板）。
+
+### 为什么
+
+落盘与入口一致，`/forge` 与审查才有锚。
+
+### 怎么验收
+
+- 两文件路径存在且非空占位；`AGENTS.md` 已反映双文档入口。
 
 ---
 
 ## Step 4: 必过检查清单
 
-- [ ] `05A_TASKS.md` 与 `05B_VERIFICATION_PLAN.md` 均已生成
-- [ ] 每个 05A 任务都含 `验证引用` 且可在 05B 定位到对应条目
-- [ ] 05B 中保留 Contract Coverage Overlay、Testing Coverage Overlay、Verification Traceability Matrix
-- [ ] 单元测试与 API接口功能测试职责均已规划
-- [ ] 测试覆盖按风险类别闭合，且未出现测试膨胀
-- [ ] `AGENTS.md` 已更新为 A/B 双文档入口
+### 做什么
+
+在进入 blueprint 收口或移交 `/forge` 前，对 `05A` / `05B` / `AGENTS.md` 与 **task-planner** 输出质量做一次硬性对账（下列清单逐项勾选）。
+
+### 为什么
+
+漏检会在 forge 阶段放大为返工；本步把「已生成」与「下游可执行」分开验收。
+
+### 怎么验收
+
+- [ ] `05A` 与 `05B` 均已生成。  
+- [ ] 与 **`task-planner` SKILL 末节「输出质量检查」** 对读无缺口（含：`验证引用`+`证据产出`、User Story Overlay 在 05A、三章在 05B、INT/冒烟关系、无 E2E 滥用）。  
+- [ ] 每个 05A 任务含 **验证引用** 且可在 05B 定位对应条目。  
+- [ ] 05B 保留 Contract / Testing / Traceability **三类覆盖叙事**（具体表头以模板为准）。  
+- [ ] 单元测试与 API 接口功能测试职责均已规划。  
+- [ ] 覆盖按风险闭合，无明显组合爆炸；任务粒度与依赖 **输入/输出对齐** 符合 SKILL 守则。  
+- [ ] `AGENTS.md` 已更新 A/B 入口。
+
+---
+
+<completion_criteria>
+- **凝练与版式**：`CRITICAL 凝练与版式` 已遵守；未向宿主粘贴 TASK 模板全文。  
+- 版本定位与前置阻断正确；契约映射在进入 planner 前已通过 Step 1.5。  
+- 未在 Step 2 之前预读 `task-planner`；Step 2 已交付完整 **移交包** 并按 SKILL **输出质量检查** 对账通过。  
+- **未**在 `/blueprint` 阶段执行 `e2e-testing-guide`。  
+- `AGENTS.md` 双文档入口已更新。  
+</completion_criteria>