@xulthekl/team-flow 0.28.1 → 0.29.1

package/.claude/always/phase-guard.md

@@ -1,3 +1,3 @@
-# team-flow v0.28.1 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.29.1 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "team-flow",
       "description": "8-state spec workflow + compound global compounding + architecture-design (4A/DDD) + local HTML prototype + product-level orchestration + bootstrap + e2e + session handoff + workflow feedback. 23 skills + 8 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.28.1",
+      "version": "0.29.1",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 23 skills + 8 agents, one install.",
   "source": "./",
   "author": {

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "description": "Spec-first workflow that bridges OpenSpec-style planning and Superpowers-style execution discipline.",
   "author": {
     "name": "MageByte",

package/.cursor-plugin/marketplace.json

@@ -5,7 +5,7 @@
   },
   "metadata": {
     "description": "Unified workflow plugin marketplace for Cursor (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.28.1"
+    "version": "0.29.1"
   },
   "plugins": [
     {

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "team-flow",
   "displayName": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 23 skills + 8 agents, one install.",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "author": {
     "name": "LT",
     "url": "https://github.com/LT"

package/.github/plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Unified workflow plugins and skills for AI coding agents (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.28.1"
+    "version": "0.29.1"
   },
   "plugins": [
     {
       "name": "team-flow",
       "description": "Unified workflow with planning artifacts, execution contracts, TDD, review gates, systematic debugging, delta spec sync, architecture-design, and local HTML prototyping.",
-      "version": "0.28.1",
+      "version": "0.29.1",
       "source": ".",
       "author": {
         "name": "LT",

package/CHANGELOG.md

@@ -6,6 +6,47 @@ The format loosely follows Keep a Changelog.
 
 ## [Unreleased]
 
+## [0.29.1] - 2026-08-01
+
+### Fixed（子代理复用 SOP 强化）
+
+- **skills/workflow-start/SKILL.md**：四步协议摘要中明确"记录子代理 ID + 循环修正/DP-A 调整必须 SendMessage 恢复原子代理"
+- **skills/workflow-start/references/routing-rules.md**：Step 1 增加子代理 ID 记录指令；Step 2 审查循环从隐式 resume 改为"⛔ 必须 SendMessage 恢复，禁止启动新子代理"；Step 4d 从"优先 SendMessage"改为"⛔ 必须 SendMessage"；反模式清单增加"启动新子代理"禁令
+- 来源：LT 实测发现主代理在循环修正时启动新子代理而非恢复原子代理
+
+## [0.29.0] - 2026-07-31
+
+### Added（§37 DP-A 确认门 + 产物权限规则 + A4 增强，来源：workflow-feedback 2026-07-31 × 7）
+
+#### DP-A 用户确认门（解决 feedback #1 #5）
+- **skills/workflow-start/SKILL.md**：三步协议升级为四步协议，Step 4 DP-A 用户确认门（架构决策摘要输出 + AskUserQuestion + 调整转交子代理）
+- **skills/workflow-start/references/routing-rules.md**：Step 4 完整协议（4a 摘要 + 4b 项目规范变更提示 + 4c AskUserQuestion + 4d 选择处理 + SendMessage 复用指导）
+- **scripts/lib/state-loader.mjs**：新增 `dp_a_result` / `dp_a_timestamp` / `dp_a_adjustments` 字段（BUILTIN_DEFAULTS + writeState）
+- **scripts/lib/cmd-state.mjs**：`dp_a_*` 加入 SETTABLE_FIELDS 白名单
+
+#### Artifact Ownership 产物修改权限规则（解决 feedback #5 #6）
+- **skills/workflow-start/SKILL.md**：Guardrails 新增"主代理不得直接修改子代理产物"显式禁令
+- **skills/workflow-orchestrator/SKILL.md**：Guardrails 同步新增 Artifact Ownership 条款
+- **agents/architecture-design.md**：新增"architecture/ 目录唯一负责人"声明
+
+#### A4 审查 PRD 功能清单交叉验证（解决 feedback #7）
+- **agents/architecture-reviewer.md**：A4 维度增加双对照源（brief + PRD 功能清单）、子实体 CRUD 完整性检查、PRD vs api.md 端点交叉验证
+- **skills/architecture-design/SKILL.md**：api.md 增加 PRD 功能清单→API 端点映射表要求
+- **agents/architecture-design.md**：Red Lines 增加 PRD 映射表产出要求
+- **agents/change-split-auditor.md**：Dim 1 增加子实体操作完整性检查
+
+#### change 目录命名版本前缀（解决 feedback #2）
+- **skills/workflow-orchestrator/references/s4-split-validate.md**：命名规范 `v{N}-C{n}-{kebab-name}`、change_dag 增加 `prd_version` 字段
+
+### Fixed（代码层贯通）
+
+- **scripts/lib/state-loader.mjs**：补齐 `arch_review_verdict` / `arch_review_rounds` / `arch_review_report` 字段（v0.28.1 §36 遗留的"死命令"问题）
+- **scripts/lib/cmd-state.mjs**：`arch_review_*` 加入 SETTABLE_FIELDS 白名单
+
+### Documentation
+
+- 工作区 **CLAUDE.md**：更新 arch_design_* 差异表（代码层已全链路贯通）、代码强制执行点、内置字段列表
+
 ## [0.26.0] - 2026-07-29
 
 ### Added（配置管理与 Skill 降级逻辑补强，4 项）

package/GEMINI.md

@@ -8,7 +8,7 @@ The workflow is self-contained and does not require OpenSpec or Superpowers at r
 
 
 <!-- team-flow-phase-guard-start -->
-# team-flow v0.28.1 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.29.1 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。
 <!-- team-flow-phase-guard-end -->

package/INSTALL.md

@@ -7,7 +7,7 @@
 - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) — 规划引擎（Schema 验证、Delta Spec、工件解析）
 - [obra/superpowers](https://github.com/obra/superpowers) — 执行纪律（TDD 铁律、SDD、系统化调试、代码审查）
 
-当前发布版本：**v0.28.1**。
+当前发布版本：**v0.29.1**。
 
 ---
 

package/README.md

@@ -1,6 +1,6 @@
 # team-flow
 
-> 当前版本：`v0.28.1`
+> 当前版本：`v0.29.1`
 
 > 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同。
 

package/agents/architecture-design.md

@@ -44,6 +44,10 @@ skills:
 
 You are an independent Architecture Design Agent. Your job: perform five architectural-change checks on a change brief, and if any check triggers, execute a full 4A+DDD incremental architecture design. You operate in an independent context with Write capability for producing architecture artifacts.
 
+## Artifact Ownership (v0.29.0 §37)
+
+**You are the sole owner of the `architecture/` directory** within the change directory. No other agent or the orchestration layer (workflow-start / workflow-orchestrator) may directly modify files under `architecture/`. All modifications to architecture deliverables — whether from auto-review FAIL fixes or human review feedback — MUST be executed through you (via `SendMessage` resume or new dispatch). The orchestration layer routes modification requests to you; it does not edit your artifacts directly.
+
 ## Iron Law
 
 You are an independent architecture designer. You read the change brief, plan, existing specs, and global architecture baseline, then make an architectural judgment. If architecture changes are involved, you produce structured deliverables. You return a structured YAML output to the orchestration layer.
@@ -116,6 +120,7 @@ artifacts:                       # required: list of produced files, skipped: em
 - Execute five-check gate BEFORE producing any deliverable
 - Produce standalone executable SQL files, not embedded code blocks
 - Cite specific brief sections and plan sections for every architecture decision
+- **Produce a PRD Feature → API Endpoint mapping table in api.md** (v0.29.0 §37): before finalizing the API routing table, read `prd/vN/prd.md` feature list (e.g., F001_P0_P1 ~ P0_PN) and map each feature to its corresponding API endpoint(s). For features involving sub-entities (明细/子项), ensure independent CRUD endpoints exist — a query-only endpoint does NOT cover "新增/编辑" functionality. Include this mapping as a dedicated section in api.md for traceability
 
 **DON'T:**
 - Skip the five-check gate and jump to design

package/agents/architecture-reviewer.md

@@ -109,16 +109,24 @@ Mechanical verification, no LLM semantic judgment needed:
 
 Dimensions requiring semantic understanding, marked as "advisory, false positives can be overridden":
 
-4. **A4 需求覆盖**:
-   - Read change-brief.md → extract all requirement items (scope, AC, technical direction)
+4. **A4 需求覆盖** (v0.29.0 §37 增强：双对照源 + 子实体 CRUD 检查):
+   - **对照源 1（现有）**：Read change-brief.md → extract all requirement items (scope, AC, technical direction)
+   - **对照源 2（v0.29.0 新增）**：Read `prd/vN/prd.md` → extract feature list (e.g., F001_P0_P1 ~ P0_PN)
    - Read plan.md → extract relevant technical design sections
-   - For each requirement, check if architecture deliverables provide corresponding design:
+   - For each requirement from BOTH sources, check if architecture deliverables provide corresponding design:
      - New aggregate → architecture.md covers it?
      - DB change → database.md covers it?
      - New API → api.md covers it?
      - BC boundary change → architecture.md Context Map updated?
+   - **子实体 CRUD 完整性检查（v0.29.0 新增）**：
+     - PRD 中含"明细管理/子项管理/详情维护"类功能 → api.md 必须有该子实体的**独立 CRUD 端点**（新增/编辑/删除）
+     - 仅查询接口（如 `/detail/list`）**不算覆盖**"新增/编辑"功能 → 缺失的写操作端点 = Critical finding
+     - 主表与子实体的操作必须分离审查——PRD 中"新增/编辑主表"和"新增/编辑明细"是两个独立功能点
+   - **PRD 功能清单 vs api.md 端点路由表交叉验证（v0.29.0 新增）**：
+     - 逐条对照 PRD 功能清单与 api.md 端点，PRD 中有但 api.md 中没有的功能点 = Critical finding
+     - 如 api.md 包含"PRD Feature → API Endpoint 映射表"（v0.29.0 architecture-design 产出），验证其完整性
    - Uncovered requirement = Critical finding
-   - Build coverage matrix table
+   - Build coverage matrix table (MUST include columns for both brief source AND PRD source)
 
 5. **A5 基线一致性**:
    - Read global `ARCHITECTURE.md` → check naming conventions, BC boundaries
@@ -201,6 +209,7 @@ Aggregate all findings and determine verdict.
 | 新增 XX 聚合 | brief §2.1 | architecture.md §1 | ✅ |
 | 修改 YY 表结构 | brief §2.3 | database.md §2 | ✅ |
 | 新增 ZZ API | brief §2.5 | — (not covered) | ❌ |
+| 新增明细 CRUD | PRD F001_S4_F1 | api.md 仅有 /detail/list | ❌ 缺写操作端点 |
 
 ## A5 基线一致性 — {PASS/FAIL}
 | Check Item | Global Baseline | Incremental Design | Status |

package/agents/change-split-auditor.md

@@ -76,6 +76,10 @@ If either path is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`
    - **Gap** (requirement not covered by any change) → Critical
    - **Overlap** (requirement covered by 2+ changes without explicit justification) → Important
    - **Orphan** (change scope not traceable to any PRD requirement) → Important
+5. **子实体操作完整性检查（v0.29.0 §37 新增）**：
+   - PRD 中含"明细管理/子项管理/详情维护"类功能（如 F001_S4_F1 领域方针内容明细管理）→ 对应 change 的 scope/AC 必须包含该子实体的**独立 CRUD 操作**（新增/编辑/删除），不能仅覆盖查询
+   - 主表操作与子实体操作必须分别覆盖——PRD 中"新增/编辑主表"和"新增/编辑明细"是两个独立功能点
+   - 子实体写操作未被任何 change 覆盖 → Critical（与 Gap 同级）
 
 ### Dimension 2: DAG Validity + Dependency Integrity
 

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.28.1`
+- Current: `v0.29.1`
 - v0.9.1 highlights: DP-4 execution-mode recommendations, a portable runtime across 17 platforms, and a raw-package smoke with no plugin-root variable.
 - Self-contained — no OpenSpec or Superpowers runtime required
 - Upstream: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec), [obra/superpowers](https://github.com/obra/superpowers)

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev) + compound-engineering core subset + architecture-design (4A/DDD) + prototype (local HTML). 17 skills, one install.",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.28.1: auto-sync CLI version with plugin version
+# v0.29.1: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.28.1"
+PLUGIN_VERSION="0.29.1"
 
 # ═══════════════════════════════════════════════════════════════
 # Step 1: Auto-sync CLI version with plugin version

package/llms.txt

@@ -3,7 +3,7 @@
 ## Overview
 spec-superflow is a self-contained workflow integration plugin for Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, and Trae. It merges spec-driven planning artifacts (proposal, specs, design, tasks) with disciplined execution guardrails (TDD, review gates, controlled handoff) into one unified workflow.
 
-Current version: v0.28.1.
+Current version: v0.29.1.
 
 ## Key Documents
 - README.md: Chinese homepage with full usage guide and FAQ

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "description": "Unified plugin (23 skills + 10 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback for multi-agent coding tools.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.1",
+  "version": "0.29.1",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 23 skills + 10 agents, one install.",
   "author": {
     "name": "LT"

package/scripts/lib/cmd-state.mjs

@@ -26,6 +26,10 @@ const SETTABLE_FIELDS = [
   // Architecture design gate (v0.9 §26, v0.22.5 评审修复 F02)
   'arch_design_decision', 'arch_design_reason',
   'arch_design_timestamp', 'arch_design_artifacts',
+  // Architecture review (v0.28.1 §36 审查增强)
+  'arch_review_verdict', 'arch_review_rounds', 'arch_review_report',
+  // DP-A user confirmation gate (v0.29.0 §37)
+  'dp_a_result', 'dp_a_timestamp', 'dp_a_adjustments',
   // Compound engineering capture gate (v0.24.0 复利贯穿强制化)
   'compound_skipped',
 ];

package/scripts/lib/state-loader.mjs

@@ -43,6 +43,14 @@ const BUILTIN_DEFAULTS = {
   arch_design_reason: null,
   arch_design_timestamp: null,
   arch_design_artifacts: null,
+  // Architecture review (v0.28.1 §36 审查增强)
+  arch_review_verdict: null,
+  arch_review_rounds: null,
+  arch_review_report: null,
+  // DP-A user confirmation gate (v0.29.0 §37)
+  dp_a_result: null,
+  dp_a_timestamp: null,
+  dp_a_adjustments: null,
   // Compound engineering capture gate (v0.24.0 复利贯穿强制化)
   compound_skipped: null,
 };
@@ -120,6 +128,16 @@ export function writeState(changeDir, state) {
   lines.push(`arch_design_timestamp: ${state.arch_design_timestamp ?? 'null'}`);
   lines.push(`arch_design_artifacts: ${state.arch_design_artifacts ?? 'null'}`);
   lines.push('');
+  lines.push('# === Architecture review (v0.28.1 §36) ===');
+  lines.push(`arch_review_verdict: ${state.arch_review_verdict ?? 'null'}`);
+  lines.push(`arch_review_rounds: ${state.arch_review_rounds ?? 'null'}`);
+  lines.push(`arch_review_report: ${state.arch_review_report ?? 'null'}`);
+  lines.push('');
+  lines.push('# === DP-A user confirmation gate (v0.29.0 §37) ===');
+  lines.push(`dp_a_result: ${state.dp_a_result ?? 'null'}`);
+  lines.push(`dp_a_timestamp: ${state.dp_a_timestamp ?? 'null'}`);
+  lines.push(`dp_a_adjustments: ${state.dp_a_adjustments ?? 'null'}`);
+  lines.push('');
   lines.push('# === Compound engineering capture gate (v0.24.0) ===');
   lines.push(`compound_skipped: ${state.compound_skipped ?? 'null'}`);
 

package/skills/architecture-design/SKILL.md

@@ -136,6 +136,7 @@ changes/<name>/
 - **不**重复 Swagger 管理的内容：请求/响应 schema、错误码定义、参数明细等由 Swagger/OpenAPI 规范承载
 - frontmatter 须声明 `api_contract_manager: swagger`，表明详细契约由 Swagger 工具链管理
 - sql/ 目录中的 DDL 和 migration 脚本为独立可执行 `.sql` 文件，不嵌入 markdown 文档
+- **PRD 功能清单 → API 端点映射表（v0.29.0 §37 新增）**：在 api.md 中增加独立章节，逐条对照 `prd/vN/prd.md` 功能清单（如 F001_P0_P1 ~ P0_PN），映射每个功能点到对应的 API 端点。对于涉及子实体（明细/子项）的功能，必须确保独立 CRUD 端点存在——仅查询端点不覆盖"新增/编辑"功能。此映射表供 architecture-reviewer A4 交叉验证使用
 
 **下游消费**：
 - `architecture/architecture.md` → spec-writer：design.md Decisions 约束

package/skills/workflow-orchestrator/SKILL.md

@@ -176,6 +176,7 @@ plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层
 - **路由是建议非决定**：S1 路由判断必须用户确认；重规划必须 DP-R 阻塞确认
 - **回退必写 replan_log**：active → pending 回退必须记录；受影响制品归档为 .revN，重入不读旧制品
 - **不阻断流程**：所有复利操作为 advisory 级，INDEX.md 读取失败时静默跳过
+- **Artifact Ownership — 主代理不得直接修改子代理产物** (v0.29.0 §37)：子代理是其产物的唯一负责人（architecture-design → `architecture/` 目录，spec-writer → `proposal.md`/`specs/`/`design.md`/`tasks.md`，contract-builder → `execution-contract.md`，prototype-builder → `prototype/` 目录）。主代理（workflow-orchestrator）不得通过 Read + Edit/Write 直接修改子代理的产物文件。修改必须通过 `SendMessage` 恢复原子代理（优先）或启动新子代理执行。例外：仅当子代理无法启动且用户明确授权时，主代理可直接修改，但必须在修改后重新触发对应的 review 验证。编排层自己负责的产物（change-brief.md、orchestrator.yaml、审计报告落盘）不受此限制
 
 ## Output Standard
 

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -1,7 +1,8 @@
-# S4 拆分验证与分发（v0.7 重写，v0.17.0 审计必选）
+# S4 拆分验证与分发（v0.7 重写，v0.17.0 审计必选，v0.29.0 命名规范）
 
 > 原 v0.5「拆分与分发」。v0.7 新增拆分质量审计与并行策略。设计依据：设计增强方案 v0.7 §17.2 / §17.8。
 > v0.17.0 变更：change-split-auditor 审计由隐含步骤升级为「必选门禁」，PASS 前不可创建 change 脚手架。change_dag 字段 `spec_dir` 更名为 `change_dir`，路径修正为 `changes/<change-name>/`。
+> v0.29.0 变更：change 目录命名增加 PRD 版本号前缀（`changes/v1-C1-domain-policy/`），change_dag 增加 `prd_version` 字段，S5 按版本分组展示。
 
 ## 编排层 vs 执行层
 
@@ -36,11 +37,24 @@ verdict = FAIL → 必须回退 S3 调整拆分后重新审计，不可绕过直
 
 按 plan 中的 change 拆分方案，为每个 change 创建目录并初始化状态文件：
 
+**命名规范（v0.29.0）**：`changes/<prd-version>-<C-ID>-<kebab-name>/`
+
 ```bash
-mkdir -p changes/<change-name>
-tf state init changes/<change-name>
+# 格式：changes/v{N}-C{n}-{kebab-name}/
+# 示例：
+mkdir -p changes/v1-C1-domain-policy
+tf state init changes/v1-C1-domain-policy
+
+mkdir -p changes/v1-C2-policy-management
+tf state init changes/v1-C2-policy-management
 ```
 
+**命名规则**：
+- `v{N}`：创建时的 PRD 版本号（取自 orchestrator.yaml 的 `prd_version`），**创建后不变**（即使后续 PRD 升版，已创建的 change 目录名不改）
+- `C{n}`：plan.md 中的 C-ID 稳定编号（never renumbered）
+- `{kebab-name}`：plan.md 中 `### C{n}. [Name]` 的 kebab-case 形式
+- 续版需求（vN+1）新增的 change 使用新版本号前缀，与旧版本 change 天然区分
+
 > ⚠️ **路径约束**：change 脚手架目录固定为项目根 `changes/<change-name>/`。
 > 不要与 `specs/<cap>/`（change 内部行为规格目录）或 `architecture/`（change 内部架构设计目录）混淆。
 > 不要放入 `.team-flow/`（仅存产品级编排状态）。
@@ -88,7 +102,20 @@ plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层
 
 ### 4. 写入 change_dag
 
-把每个 change 的 id / change_dir / state_file / depends_on / priority / parallel_group / status 写入 `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag`。详见 state-model.md「change_dag 结构」。
+把每个 change 的 id / change_dir / state_file / depends_on / priority / parallel_group / status / **prd_version**（v0.29.0 新增）写入 `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag`。详见 state-model.md「change_dag 结构」。
+
+**change_dag 条目格式（v0.29.0）**：
+```yaml
+change_dag:
+  - id: C1
+    change_dir: changes/v1-C1-domain-policy/
+    state_file: changes/v1-C1-domain-policy/.team-flow.yaml
+    depends_on: []
+    priority: 1
+    parallel_group: null
+    status: pending
+    prd_version: v1              # v0.29.0 新增：创建时的 PRD 版本号
+```
 
 ### 5. 分发
 
@@ -102,7 +129,7 @@ Change C1 已就绪，运行 /workflow-start 进入变更级流程。
 ## 完成条件
 
 - change-split-auditor 审计 verdict = PASS（必选门禁已通过，含 v0.9 D5 拆分维度合规）
-- 所有 change 目录已创建在项目根 `changes/` 下（非 `specs/` 或 `.team-flow/`），`.team-flow.yaml` 已初始化
+- 所有 change 目录已创建在项目根 `changes/` 下（非 `specs/` 或 `.team-flow/`），**命名符合 `v{N}-C{n}-{kebab-name}` 规范**（v0.29.0），`.team-flow.yaml` 已初始化
 - 每个 change 目录已落盘 `change-brief.md`（v0.9 交接物，含 scope/AC/技术方向/frontmatter）
-- `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag` 已填充
+- `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag` 已填充（含 `prd_version` 字段）
 - S4 状态 = completed，已告知用户执行顺序

package/skills/workflow-start/SKILL.md

@@ -55,14 +55,15 @@ Validate mode against artifact content. If hotfix/tweak criteria not met → upg
 ### Route to need-explorer
 Change is fuzzy, scope unclear, comparing options, no stable change name.
 
-### Route to architecture-design (v0.9 §26, v0.28.1 §36 审查增强)
+### Route to architecture-design (v0.9 §26, v0.28.1 §36 审查增强, v0.29.0 §37 DP-A 确认门)
 Guard: `arch_design_decision` in `.team-flow.yaml` is `null` → must run before spec-writer.
 
-**Three-step protocol (MUST execute in order)**:
+**Four-step protocol (MUST execute in order)**:
 
-1. **Dispatch**: `architecture-design` as sub-agent → returns `decision` + `reason` + `artifacts`
-2. **Auto-review** (decision=required 时触发): 校验产物文件存在且非空 → dispatch `architecture-reviewer` sub-agent → FAIL 则循环修正（≤3 轮 + 收敛检测，不收敛转人工）→ 报告落盘 `changes/<name>/architecture/auto-review.md`
+1. **Dispatch**: `architecture-design` as sub-agent → returns `decision` + `reason` + `artifacts`。**⛔ 记录子代理 ID**（后续循环修正和 DP-A 调整必须通过此 ID 恢复，禁止启动新子代理）
+2. **Auto-review** (decision=required 时触发): 校验产物文件存在且非空 → dispatch `architecture-reviewer` sub-agent（**记录子代理 ID**）→ FAIL 则通过 **SendMessage 恢复原 architecture-design 子代理**修正（≤3 轮 + 收敛检测，不收敛转人工）→ 报告落盘 `changes/<name>/architecture/auto-review.md`
 3. **Reasonableness check + state write**: PASS/PASS_WITH_WARNINGS → write `arch_design_decision` + `arch_review_*` to yaml; skipped + brief 含架构关键词 → BLOCK; required + artifacts 缺失 → BLOCK; required + auto-review FAIL → BLOCK
+4. **DP-A 用户确认门（v0.29.0 §37）**: 输出架构决策摘要 → AskUserQuestion 确认 → 需要调整时**必须通过 SendMessage 恢复原子代理**修改（禁止主代理直接修改，禁止启动新子代理）→ 修改后 SendMessage 恢复原 reviewer 重新 auto-review → 回到本步骤重新确认。含项目规范变更提示（advisory）。详见 `references/routing-rules.md`「Step 4: DP-A」
 
 Full protocol in `references/routing-rules.md`「Route to architecture-design」.
 
@@ -144,6 +145,8 @@ Use content inspection, not timestamps.
 - No merging delta specs from abandoned change
 - **No routing to spec-writer without architecture-design gate pass** (v0.9 §26): `arch_design_decision` must be `required` or `skipped` (not `null`). hotfix/tweak 不豁免
 - **No arch state write without auto-review PASS** (v0.28.1 §36): when `decision: required`, auto-review MUST complete with PASS or PASS_WITH_WARNINGS before writing `arch_design_decision` to yaml. FAIL → loop fix (≤3 rounds) or escalate to human
+- **No routing past DP-A without user confirmation** (v0.29.0 §37): architecture-design 三步协议完成后，必须经 DP-A 用户确认门（AskUserQuestion）才能路由到 spec-writer。用户选择"需要调整"时，修改必须通过子代理执行，修改后重新 auto-review + 重新 DP-A 确认
+- **Artifact Ownership — 主代理不得直接修改子代理产物** (v0.29.0 §37): 子代理是其产物的唯一负责人（architecture-design → `architecture/` 目录，spec-writer → `proposal.md`/`specs/`/`design.md`/`tasks.md`，contract-builder → `execution-contract.md`）。主代理（workflow-start）不得通过 Read + Edit/Write 直接修改子代理的产物文件。修改必须通过 `SendMessage` 恢复原子代理（优先）或启动新子代理执行。例外：仅当子代理无法启动且用户明确授权时，主代理可直接修改，但必须在修改后重新触发对应的 review 验证
 
 ## State Writes (v0.22.5 F06 修复)
 
@@ -173,6 +176,11 @@ workflow-start 负责写入以下字段到 `.team-flow.yaml`：
 - `arch_review_rounds`：审查轮次（1-3）
 - `arch_review_report`：`architecture/auto-review.md` 路径
 
+**DP-A 确认门字段**（v0.29.0 §37，DP-A 用户确认后写入）：
+- `dp_a_result`：`confirmed` | `adjustment_requested`（用户确认结果）
+- `dp_a_timestamp`：ISO 8601 时间戳（UTC）
+- `dp_a_adjustments`：用户调整意见摘要（adjustment_requested 时必填，confirmed 时为空）
+
 **职责边界**：architecture-design 负责判断+产出，architecture-reviewer 负责 6 维度审查，workflow-start 负责编排三步协议（dispatch → auto-review → reasonableness check）+ 状态写入。详细写入命令见 `references/routing-rules.md`「Route to architecture-design」。
 
 ## Output Standard
@@ -180,7 +188,7 @@ workflow-start 负责写入以下字段到 `.team-flow.yaml`：
 Always state: (1) current detected state, (2) why (cite file/content/condition), (3) which skill should run next. If blocking, explain missing artifact/approval.
 
 Decision point references when routing:
-- architecture-design → DP-A（架构设计判断门，v0.9 §26）, contract-builder → DP-3, build-executor → DP-4, bug-investigator (escalation) → DP-5, release-archivist (verification failure) → DP-6, release-archivist → DP-7
+- architecture-design → DP-A（架构设计用户确认门，v0.9 §26 判断门 + v0.29.0 §37 用户确认门）, contract-builder → DP-3, build-executor → DP-4, bug-investigator (escalation) → DP-5, release-archivist (verification failure) → DP-6, release-archivist → DP-7
 
 ## Exception Handling
 

package/skills/workflow-start/references/routing-rules.md

@@ -5,7 +5,7 @@
 ## Route to need-explorer
 Change is fuzzy, scope unclear, comparing options, no stable change name.
 
-## Route to architecture-design (v0.9 §26, v0.11 §34 审查增强, v0.28.1 §36 主干补强)
+## Route to architecture-design (v0.9 §26, v0.11 §34 审查增强, v0.28.1 §36 主干补强, v0.29.0 §37 DP-A 确认门)
 
 Guard: `arch_design_decision` in `.team-flow.yaml` is `null` → must run before spec-writer.
 
@@ -17,6 +17,12 @@ Dispatch `architecture-design` as sub-agent with inputs:
 - existing `specs/`
 - global `docs/architecture/`（As-Is 基线）
 
+**⛔ 子代理 ID 记录（v0.29.0 §37，必须执行）**：dispatch 后**立即记录**子代理 ID（Agent 工具返回的 `agentId` 或 task-notification 中的 `task-id`），后续 Step 2 审查循环和 Step 4 DP-A 调整**必须通过此 ID 恢复子代理**，不得启动新子代理。记录格式：
+```
+arch_design_agent_id = <agentId>   # Step 1 dispatch 返回
+arch_reviewer_agent_id = <agentId> # Step 2 dispatch 返回
+```
+
 Sub-agent returns structured output:
 ```yaml
 decision: required | skipped
@@ -52,6 +58,12 @@ reviewer 报告 → FAIL → 不一致项交给 architecture-design 修正 →
 reviewer 报告 → PASS / PASS_WITH_WARNINGS → 进入 Step 3
 ```
 
+**⛔ 循环修正必须通过 SendMessage 恢复原子代理（v0.29.0 §37，禁止启动新子代理）**：
+- FAIL 后修正：`SendMessage(to: arch_design_agent_id, message: "审查 FAIL，不一致项如下：{findings}。请修正后返回更新的结构化输出。")`
+- 重新审查：`SendMessage(to: arch_reviewer_agent_id, message: "第 {N} 轮审查，架构产物已修正。请重新执行 6 维度审查。")`
+- **禁止**在循环中启动新的 architecture-design 或 architecture-reviewer 子代理——原子代理拥有完整的设计上下文和审查历史，新子代理需要重新加载全部上下文（浪费 10-20K tokens 且可能丢失修正连贯性）
+- **唯一例外**：SendMessage 恢复失败（子代理 transcript 不可用）时，启动新子代理作为 fallback，但必须在 dispatch prompt 中传入：原产物路径 + auto-review 报告 + 历次修正记录
+
 报告落盘到 `changes/<name>/architecture/auto-review.md`。
 
 ### Step 3: Reasonableness check
@@ -76,6 +88,107 @@ tf state set <change-dir> arch_review_report "architecture/auto-review.md"
 
 **hotfix / tweak 不豁免**：同样过 architecture-design 子代理判断门（hotfix 可能正是架构缺陷导致）。
 
+### Step 4: DP-A 用户确认门 (v0.29.0 §37)
+
+> **设计动机**：v0.28.1 的三步协议是全自动闭环（dispatch → auto-review → state write → 路由下一步），缺少人工审批环节。用户在架构设计完成后无法确认或提出调整意见，被迫手动打断流程。DP-A 在 Step 3 之后、路由 spec-writer 之前插入结构化用户确认门。
+
+Step 3 reasonableness check + state write 完成后，**必须**执行 DP-A：
+
+**4a. 输出架构决策摘要**：
+
+```
+📐 架构设计完成 — 决策摘要
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+判定：{decision} ({reason})
+审查：{arch_review_verdict}（{arch_review_rounds} 轮）
+
+聚合定义：
+  {列出新增/修改的聚合及聚合根}
+
+限界上下文：
+  {列出 BC 边界变更}
+
+API 端点概览：
+  {端点总数} 个（Command: {n}, Query: {n}）
+  {列出关键端点}
+
+DB 变更概览：
+  {新增/修改的表数量}
+
+ADR 列表：
+  {列出关键架构决策记录}
+
+产物路径：
+  - changes/<name>/architecture/architecture.md
+  - changes/<name>/architecture/database.md
+  - changes/<name>/architecture/api.md
+  - changes/<name>/architecture/auto-review.md
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+**4b. 项目规范变更提示（advisory，不阻断）**：
+
+在摘要末尾附加：
+```
+📋 项目规范变更检查（advisory）：
+  本次架构设计是否引入了新的项目级规范？
+  （如：新模块不使用 CQRS、Mapper 放 domain 等）
+  如是，请确认已更新 docs/architecture/ 相关文档
+  （ARCHITECTURE.md / baseline.md / CONCEPTS.md）。
+```
+
+**4c. AskUserQuestion 确认**：
+
+```
+AskUserQuestion:
+  question: "架构设计确认？"
+  options:
+    [A] "确认，进入 spec-writer"（推荐）
+    [B] "需要调整（列出调整点）"
+    [C] "需要查看详细产物（给出文件路径）"
+```
+
+**4d. 处理用户选择**：
+
+- **选择 A（确认）**：
+  ```bash
+  tf state set <change-dir> dp_a_result "confirmed"
+  tf state set <change-dir> dp_a_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+  tf state set <change-dir> dp_a_adjustments ""
+  ```
+  → 路由到 spec-writer
+
+- **选择 B（需要调整）**：
+  1. 记录用户调整意见
+  2. **⛔ 必须通过 SendMessage 恢复原 architecture-design 子代理修改（禁止启动新子代理，禁止主代理直接 Edit）**：
+     ```
+     SendMessage(to: arch_design_agent_id, message: "用户评审反馈（DP-A 调整）：
+       {用户调整意见}
+       请修改架构产物，保持内部一致性，返回更新后的结构化输出。")
+     ```
+     原子代理拥有完整的设计上下文（PRD、brief、基线、conventions），能保持修改的一致性。启动新子代理会丢失上下文（重新加载 10-20K tokens）且可能引入不一致。
+  3. 子代理修改完成后，**通过 SendMessage 恢复原 architecture-reviewer 子代理重新审查**（即使之前已 PASS）：
+     ```
+     SendMessage(to: arch_reviewer_agent_id, message: "架构产物已按用户评审意见修正。请重新执行 6 维度审查。")
+     ```
+  4. auto-review PASS 后，更新 yaml 状态（arch_review_verdict / arch_review_rounds）
+  5. 回到 Step 4a 重新输出摘要 + 重新确认
+  6. **唯一 fallback**：SendMessage 恢复失败时，启动新子代理，但必须在 dispatch prompt 中传入：调整意见 + 原产物路径 + auto-review 报告 + 历次修正记录
+  ```bash
+  tf state set <change-dir> dp_a_result "adjustment_requested"
+  tf state set <change-dir> dp_a_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+  tf state set <change-dir> dp_a_adjustments "<调整意见摘要>"
+  ```
+
+- **选择 C（查看详细产物）**：
+  输出文件路径列表，等待用户阅读后重新 AskUserQuestion（回到 4c）
+
+**⛔ 反模式（禁止）**：
+- 主代理直接 Read + Edit `architecture/*.md` 文件（违反 Artifact Ownership 规则）
+- 跳过 DP-A 直接路由 spec-writer
+- 用户选择 B 后不重新 auto-review 就直接重新确认
+- **循环修正或 DP-A 调整时启动新的 architecture-design / architecture-reviewer 子代理**（必须通过 SendMessage 恢复原子代理，原子代理拥有完整上下文；新子代理 = 上下文断裂 + token 浪费。唯一例外：SendMessage 恢复失败时的 fallback）
+
 ## Route to spec-writer
 Guard: `tf runtime guard check <dir> exploring specifying --json` → fail = BLOCK.
 **arch_design_decision must not be null** → fail = BLOCK（architecture-design gate not passed，v0.9 §26）。