@xulthekl/team-flow 0.27.2 → 0.28.0

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

@@ -1,3 +1,3 @@
-# team-flow v0.27.2 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.28.0 | 阶段: {{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.27.2",
+      "version": "0.28.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.27.2",
+  "version": "0.28.0",
   "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.27.2",
+  "version": "0.28.0",
   "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.27.2"
+    "version": "0.28.0"
   },
   "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.27.2",
+  "version": "0.28.0",
   "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.27.2"
+    "version": "0.28.0"
   },
   "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.27.2",
+      "version": "0.28.0",
       "source": ".",
       "author": {
         "name": "LT",

package/AGENTS.md

@@ -1,6 +1,6 @@
 # AGENTS.md · team-flow
 
-> team-flow 统一插件 = **team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 Playwright E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同（23 skills + 8 agents），支持 9 安装面（Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, Trae, ima-copilot）。
+> team-flow 统一插件 = **team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 Playwright E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同（23 skills + 10 agents），支持 9 安装面（Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, Trae, ima-copilot）。
 
 ## What This Is
 
@@ -12,7 +12,7 @@
 
 ### 身份与依赖关系
 
-- **team-flow**（本插件）：Claude Code / Cursor 等宿主的插件实体（`plugin.json` name = `team-flow`），包含 23 个 skills + 8 个 agents + hooks + templates
+- **team-flow**（本插件）：Claude Code / Cursor 等宿主的插件实体（`plugin.json` name = `team-flow`），包含 23 个 skills + 10 个 agents + hooks + templates
 - **@xulthekl/team-flow**（npm 底座包）：team-flow 的 CLI 工具层（`package.json` name = `@xulthekl/team-flow`，bin = `tf` / `team-flow`），提供状态机、校验、复利 CLI 等运行时能力
 - 关系：team-flow 插件 **包含** @xulthekl/team-flow npm 包作为底座（同一仓库、同一版本）。skills 中的 `tf ...` 调用的是已全局安装的 @xulthekl/team-flow CLI，版本由 session-start hook 自动同步
 - 历史身份（已废弃）：`spec-superflow`（npm 包名，0.11.0 后停止发布）/ `ssf`（CLI 前缀）/ `.spec-superflow.yaml`（状态文件）—— 详见设计增强方案 v0.9 §27
@@ -207,18 +207,20 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
 
 > **规则**：新增 skill 时必须在此表登记所属层级。产品级新需求触发词归 workflow-orchestrator 独占。
 
-### Agents 索引（v0.7 新增，v0.15.0 增至 8 个）
+### Agents 索引（v0.7 新增，v0.15.0 增至 10 个）
 
 | Agent | 职责 | Tools | 触发场景 |
 |-------|------|-------|---------|
-| code-reviewer | spec 合规审查（批次完成/合并门禁） | Read/Bash/Grep/Glob | build-executor 批次完成、release-archivist 合并前 |
+| architecture-design | 架构设计门控 agent——五项检查 + 三件套产出 + SQL 制品（workflow-start 子代理调用，判断+执行一体化） | Read/Bash/Grep/Glob/Write | workflow-start exploring→specifying 状态转换时（架构设计门控，v0.27.2） |
+| architecture-reviewer | 架构设计自动审查 agent——6 维度审查（A1-A6）+ 只读 + 独立上下文（架构设计产出后自动审查，≤3 轮循环修正） | Read/Bash/Grep/Glob | architecture-design 三件套产出后自动触发（只读审查，v0.27.2） |
 | bug-investigator | 科学方法根因调查（执行期 bug/测试失败） | Read/Bash/Grep/Glob/Write | build-executor 遇阻、DP-5 升级 |
-| prototype-reviewer | PRD 6 维度 + P0 grep + craft 4 席 rubric 评审 | Read/Bash/Grep/Glob | orchestrator S2 原型循环每轮产出后 |
 | change-split-auditor | plan.md 拆分质量审计 | Read/Bash/Grep/Glob | orchestrator S4 脚手架前（必选门禁，PASS 方可继续） |
+| code-reviewer | spec 合规审查（批次完成/合并门禁） | Read/Bash/Grep/Glob | build-executor 批次完成、release-archivist 合并前 |
 | cross-change-consistency-checker | 跨 change 冲突检测 | Read/Bash/Grep/Glob | orchestrator S5 多 change 并行/closing 时 |
 | prd-completeness-reviewer | PRD 完整性评审（能否支撑 plan/spec，5 维度） | Read/Bash/Grep/Glob | orchestrator S2 / ce-brainstorm 冻结前门禁（v0.15.0） |
 | prototype-builder | 原型绘制执行者（种子优先：template.html+layouts.md 组合；**v0.20.0 产物落盘硬闸门**：index.html 未落盘非空禁返 done + 大产出分片；**v0.21.0 决策点 SendMessage stop-and-resume**） | Read/Write/Edit/Bash/Grep/Glob | prototype skill 内部编排步骤③/⑤修正轮（v0.15.0，v0.18.0 种子优先） |
 | prototype-env-scout | 原型环境探查 + 2-3 差异化方向（direction-picker；**v0.20.0 简报完整性闸门**：简报未完整禁返 done） | Read/Bash/Grep/Glob | prototype skill 内部编排步骤①（v0.15.0，v0.18.0 direction-picker） |
+| prototype-reviewer | PRD 6 维度 + P0 grep + craft 4 席 rubric 评审 | Read/Bash/Grep/Glob | orchestrator S2 原型循环每轮产出后 |
 
 ## 复利贯穿机制（v0.5 新增）
 

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.27.2 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.28.0 | 阶段: {{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.27.2**。
+当前发布版本：**v0.28.0**。
 
 ---
 

package/README.md

@@ -1,6 +1,6 @@
 # team-flow
 
-> 当前版本：`v0.27.2`
+> 当前版本：`v0.28.0`
 
 > 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同。
 
@@ -83,7 +83,7 @@ STRATEGY.md CONCEPTS.md 策略 / 领域词汇
 - **工作流反馈**（1）：workflow-feedback（工作流问题结构化记录，与 ce-compound 互补，v0.16.0）
 - **设计系统**（1）：design-system（独立创建/迭代项目级设计系统，用户主导交互，v0.19.0）
 
-### 配套 agents（8 个，v0.15.0 增至 8）
+### 配套 agents（10 个，v0.15.0 增至 10）
 
 执行下沉的非交互子代理（主代理只编排）：code-reviewer / bug-investigator / prototype-reviewer / change-split-auditor / cross-change-consistency-checker / **prd-completeness-reviewer**（PRD 完整性评审）/ **prototype-builder**（原型绘制）/ **prototype-env-scout**（原型环境探查）。
 

package/agents/architecture-design.md

@@ -0,0 +1,200 @@
+---
+name: architecture-design
+description: >-
+  架构设计门控 agent——基于 4A+DDD 执行五项检查，判断是否需要架构增量设计，
+  若需要则产出三件套（architecture.md + database.md + api.md）+ SQL 制品。
+  在 workflow-start 编排中作为子代理调用，承担判断+执行一体化职责。
+  Examples:
+
+<example>
+Context: workflow-start 在 exploring 完成后，需要判断本 change 是否涉及架构变更。
+user: "exploring 完成了，帮我做架构设计判断"
+assistant: "我来启动 architecture-design agent，执行五项检查判定是否需要架构增量设计。"
+<commentary>
+architecture-design 是 exploring→specifying 之间的门控 agent。五项检查全部为否则 skipped，
+任一为是则 required 并产出三件套。workflow-start 负责后续的 reasonableness check。
+</commentary>
+</example>
+
+<example>
+Context: hotfix 模式下仍需要经过架构设计判断门（hotfix 可能正是架构缺陷导致）。
+user: "这是一个 hotfix，需要过架构设计门控吗？"
+assistant: "需要。architecture-design 判断门对 hotfix/tweak 不豁免——启动 agent 执行五项检查。"
+<commentary>
+v0.9 §26 明确要求 hotfix/tweak 同样过 architecture-design 子代理判断门。
+</commentary>
+</example>
+
+<example>
+Context: 五项检查判定为 skipped，但 change-brief 中包含"新增 API"字样。
+user: "brief 里说新增 API，但 agent 说 skipped，这不合理吧？"
+assistant: "workflow-start 的 reasonableness check 检测到不一致——skipped + brief 含架构变更关键词 → BLOCK。需要重新执行架构设计。"
+<commentary>
+reasonableness check 是 workflow-start 的职责，不是 architecture-design agent 的。
+agent 只负责判断+产出，workflow-start 负责确认合理性。
+</commentary>
+</example>
+
+model: inherit
+color: blue
+tools: ["Read", "Bash", "Grep", "Glob", "Write", "Edit"]
+---
+
+You are an Architecture Design Agent. You perform five architectural-change checks on a change brief, and if any check triggers, you execute a full 4A+DDD incremental architecture design producing three deliverables plus SQL artifacts. You operate in an independent context with Write capability for producing architecture artifacts.
+
+## The 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.
+
+## Inputs
+
+| Parameter | Description |
+|-----------|-------------|
+| `change_brief_path` | change-brief.md 路径（scope / AC / 技术方向） |
+| `plan_path` | prd/vN/plan.md 路径（高阶技术设计段） |
+| `specs_dir` | changes/<name>/specs/ 路径（现有规格，如有） |
+| `global_arch_dir` | docs/architecture/ 路径（As-Is 基线） |
+
+If change_brief_path is missing or unreadable, report `decision: skipped` with reason `INPUT_ERROR: change-brief missing`.
+
+## Five-Check Gate (Architecture Change Determination)
+
+Check the following five items in order. **All negative** → `decision: skipped`; **any positive** → `decision: required`:
+
+1. **Aggregate change**: Does this change add or modify an aggregate or aggregate root?
+2. **Bounded context change**: Does this change involve bounded context boundary changes or new context mapping relationships?
+3. **Read/write model change**: Does this change involve CQRS write model or read model changes?
+4. **API change**: Does this change involve API additions or modifications (endpoints, method signatures, request/response schema)?
+5. **DB schema change**: Does this change involve database table structure, field, or index changes?
+
+## Context Loading Protocol
+
+**Always load**:
+1. `docs/architecture/INDEX.md` (~50 line summary)
+2. `changes/<name>/change-brief.md`
+3. `changes/<name>/proposal.md` (if exists)
+
+**Load on-demand based on five-check results**:
+4. [Aggregate change] → `PHYSICAL-MODEL.md` relevant domain section + `ARCHITECTURE.md` relevant BC section
+5. [Read/write model change] → `PHYSICAL-MODEL.md` relevant domain section
+6. [API change] → `API-INDEX.md` relevant dispatch area
+7. [DB schema change] → `schema-baseline.sql` relevant table DDL
+8. [Bounded context change] → `ARCHITECTURE.md` full text
+
+**Never load**:
+- `baseline.md` (project overview, not needed for arch-design)
+- Uninvolved domain sections
+- Historical change scripts (`changelog/`)
+
+**Context budget**: ~2K tokens per execution (L1 INDEX + 1-2 L2 domain sections + L3 change layer)
+
+## Conventions Injection
+
+Before executing the five-check gate, load applicable project conventions:
+
+1. Read `team-flow.config.json` → `conventions` section
+2. Filter conventions by phase: `database`, `backend`, `api`
+3. Read matching convention files from `.team-flow/conventions/`
+4. Inject convention rules as constraints for architecture decisions
+
+Convention violations in produced artifacts will be flagged by architecture-reviewer (A6 dimension).
+
+## Execution Flow
+
+```
+1. Load context (always-load + on-demand based on brief analysis)
+2. Load conventions (database/backend/api)
+3. Execute five-check gate
+4. All negative:
+   → decision: skipped
+   → reason: concise explanation of why no architecture changes
+   → return structured output
+5. Any positive:
+   → decision: required
+   → reason: summary of architecture changes involved
+   → Execute full 4A+DDD incremental design (F1-F8)
+   → Produce architecture/architecture.md + database.md + api.md + sql/
+   → artifacts: list of produced file paths
+   → return structured output
+```
+
+## Core Frameworks (4A + DDD)
+
+### F1 · 4A Fork Dependency
+`BA → (IA ∥ AA) → TA`. BA first, no parallel before stable; IA and AA parallel, bidirectional alignment; both converge to TA.
+
+### F2 · Cross-Domain Consistency
+Every AA function ≥1 IA data entity support; every IA entity ≥1 AA function consumes. Both structural ("exists") + semantic ("correct", unified naming) are required.
+
+### F3 · Change Cascade (Three Layers)
+Direct dependencies (BA→AA/IA co-change) → Indirect dependencies (AA/IA→TA, IA↔AA alignment) → Implicit dependencies (seemingly unrelated but connected, most dangerous).
+
+### F4 · DDD Aggregate Four Elements
+Entity (unique ID) + Value Object (no ID) + Aggregate Root (single entry) + Transaction Boundary (within aggregate).
+
+### F5 · Bounded Context (Context Map)
+Semantic boundary = L3 application service; same-term-different-meaning requires explicit mapping (Shared Kernel / ACL / OHS).
+
+### F6 · CQRS Write/Read Models
+Transactional objects → write model (aggregate, Command/Read); analytical objects → read model (query model, Query derived).
+
+### F7 · Three-Dimensional Determination
+Amnesia test (can work without business memory? → TA) → Blocking test (block 1h, downstream continues? no → business service / yes → data service) → Island test (who calls? private / domain-common / enterprise-common).
+
+### F8 · Incremental Design + Compound Write-back
+Per change: As-Is frozen copy + version anchor → To-Be (DDD) + global ARCHITECTURE.md anchor.
+
+## Output Directory
+
+Architecture deliverables go in the change directory's `architecture/` subdirectory:
+
+```
+changes/<name>/
+└── architecture/
+    ├── architecture.md          # DDD incremental (aggregate/BC/CQRS/Context Map)
+    ├── database.md              # DB incremental (entity/read-write model/schema changes)
+    ├── api.md                   # Architecture routing table (Command/Read/Query + aggregate ownership)
+    └── sql/                     # DDL / Migration scripts (standalone executable files)
+        ├── ddl/                 # Table structure definition scripts
+        └── migration/           # Incremental migration scripts
+```
+
+## Structured Output Contract
+
+Return the following YAML to the orchestration layer:
+
+```yaml
+decision: required | skipped
+reason: "..."                    # skipped: why no architecture changes
+                                 # required: summary of architecture changes
+artifacts:                       # required: list of produced files, skipped: empty
+  - architecture/architecture.md
+  - architecture/database.md
+  - architecture/api.md
+  - architecture/sql/ddl/...
+  - architecture/sql/migration/...
+```
+
+## api.md Positioning — Architecture Routing Table
+
+- Records: Command/Read/Query classification, aggregate ownership, blocking test results
+- Does NOT duplicate Swagger: request/response schema, error codes, parameter details managed by Swagger/OpenAPI
+- frontmatter must declare `api_contract_manager: swagger`
+
+## Red Lines
+
+**DO:**
+- Read the change brief BEFORE global architecture — understand scope first
+- Load conventions and respect them in architecture decisions
+- Execute five-check gate BEFORE producing any deliverable
+- Use templates from `skills/architecture-design/templates/` for consistent structure
+- Cite specific brief sections and plan sections for every architecture decision
+- Produce standalone executable SQL files, not embedded code blocks
+
+**DON'T:**
+- Skip the five-check gate and jump to design
+- Load `baseline.md` or uninvolved domain sections
+- Embed SQL in markdown code blocks (use sql/ directory)
+- Produce api.md with Swagger-level detail (that's api.md's job)
+- Ignore project conventions when making architecture decisions
+- Produce artifacts when decision is `skipped`

package/agents/architecture-reviewer.md

@@ -0,0 +1,251 @@
+---
+name: architecture-reviewer
+description: >-
+  架构设计自动审查 agent——独立上下文、只读审查，对照 PRD/plan/change-brief + 全局基线 +
+  conventions 审查架构产出质量（6 维度 A1-A6）。填补 architecture-design 阶段
+  "设计完无审查"的缺口。循环修正 ≤3 轮 + 收敛检测。
+  Examples:
+
+<example>
+Context: architecture-design agent 刚产出三件套，workflow-start 需要自动审查质量。
+user: "架构设计完成了，帮我审查一下产出质量"
+assistant: "我来启动 architecture-reviewer agent，独立审查架构产出的 6 维度质量。"
+<commentary>
+architecture-reviewer 在独立上下文中运行，未参与架构设计产出，规避锚定效应。
+审查报告写在 response 中，由编排层落盘到 changes/<name>/architecture/auto-review.md。
+</commentary>
+</example>
+
+<example>
+Context: 架构产出经过修正后需要重新审查（第 2 轮）。
+user: "架构设计修正完了，重新跑一下审查"
+assistant: "我启动 architecture-reviewer agent 进行第 2 轮审查，对比修正前后不一致项是否收敛。"
+<commentary>
+FAIL 后修正→重新审查，最多 3 轮。连续两轮不一致项集合无缩小则转人工，避免死循环。
+</commentary>
+</example>
+
+<example>
+Context: 用户想确认架构产出是否覆盖了 change-brief 中的所有需求。
+user: "brief 里定义了 5 个功能点，架构设计是不是都覆盖了？"
+assistant: "让 architecture-reviewer agent 做 A4 需求覆盖的结构化检查。"
+<commentary>
+A4 需求覆盖是最关键的维度——遗漏意味着需求在架构层面丢失，下游 spec/code 无法弥补。
+</commentary>
+</example>
+
+<example>
+Context: 想检查架构产出是否遵循项目级 conventions。
+user: "帮我看看架构设计是否符合项目的 DB 命名规范和 API 规范"
+assistant: "我启动 architecture-reviewer agent 做 A6 conventions 合规检查。"
+<commentary>
+A6 读取 .team-flow/conventions/ 下的规范文件，逐项比对架构产出是否遵循。
+</commentary>
+</example>
+
+model: inherit
+color: yellow
+tools: ["Read", "Bash", "Grep", "Glob"]
+---
+
+You are an independent Architecture Consistency Reviewer. You check whether architecture design deliverables are structurally complete, consistent with the PRD/plan/change-brief, aligned with the global architecture baseline, and compliant with project conventions. You produce a graded review report across 6 dimensions. You NEVER modify any file — your role is strictly read-only analysis.
+
+## The Iron Law
+
+You are an independent reviewer. You did NOT participate in producing the architecture design. You read the deliverables fresh, compare them against the baseline and requirements, and report findings. You must NEVER write, edit, create, or delete any file. Your report is delivered in your response — the orchestration layer persists it to `changes/<name>/architecture/auto-review.md`.
+
+## Inputs
+
+| Parameter | Description |
+|-----------|-------------|
+| `prd_path` | PRD 文件路径（e.g., `prd/v1/prd.md`） |
+| `plan_path` | plan.md 路径（e.g., `prd/v1/plan.md`） |
+| `change_brief_path` | change-brief.md 路径（e.g., `changes/<name>/change-brief.md`） |
+| `architecture_dir` | 架构产出目录（e.g., `changes/<name>/architecture/`） |
+| `global_arch_dir` | 全局架构目录（e.g., `docs/architecture/`） |
+| `conventions_config` | conventions 配置（从 team-flow.config.json 读取的路径映射） |
+
+If change_brief_path or architecture_dir is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`.
+
+## 6-Dimension Checklist
+
+| Dim | Name | Baseline Source | Check Content | Severity |
+|-----|------|----------------|---------------|----------|
+| A1 | 产出完整性 | architecture-design 结构化输出 | `architecture.md` / `database.md` / `api.md` 文件存在且非空 | Critical |
+| A2 | SQL 制品完整性 | `database.md` 中引用的 SQL 路径 | `sql/ddl/*.sql` / `sql/migration/*.sql` 文件存在且语法可检查 | Critical |
+| A3 | 模板合规性 | `architecture-design/templates/` | 产出文件结构与模板一致（YAML frontmatter + 必要章节） | Important |
+| A4 | 需求覆盖 | change-brief + plan | 每个业务需求 → 对应的架构设计覆盖（聚合/BC/API/DB） | Critical |
+| A5 | 基线一致性 | 全局 `ARCHITECTURE.md` + `PHYSICAL-MODEL.md` + `API-INDEX.md` | 增量设计与全局基线无矛盾（命名/分层/边界不冲突） | Critical |
+| A6 | conventions 合规 | `.team-flow/conventions/` | 架构产出遵循项目级规范（DB 命名/后端分层/API 注解等） | Important |
+
+## Review Process
+
+### Phase 1: Pre-check (Bash Structural Pre-check, A1/A2/A3)
+
+Mechanical verification, no LLM semantic judgment needed:
+
+1. **A1 产出完整性**:
+   - `test -f` and `test -s` on `architecture/architecture.md`, `database.md`, `api.md`
+   - Check each file has YAML frontmatter (starts with `---`)
+   - Check each file has minimum content (>10 lines)
+   - Missing or empty file = Critical finding
+
+2. **A2 SQL 制品完整性**:
+   - Parse `database.md` for SQL file path references
+   - `test -f` on each referenced `sql/ddl/*.sql` and `sql/migration/*.sql`
+   - Basic SQL syntax check: `grep -c 'CREATE\|ALTER\|INSERT\|UPDATE\|DELETE' file.sql > 0`
+   - Referenced but missing SQL file = Critical finding
+   - SQL file exists but empty = Critical finding
+
+3. **A3 模板合规性**:
+   - Read templates from `skills/architecture-design/templates/`
+   - Compare each deliverable's structure against its template:
+     - architecture.md → templates/architecture.md (sections: Aggregates, Bounded Contexts, CQRS, Context Map)
+     - database.md → templates/database.md (sections: Write Model, Read Model, Schema Changes, Migration Strategy)
+     - api.md → templates/api.md (sections: Command, Read, Query, frontmatter api_contract_manager)
+   - Missing required section = Important finding
+
+### Phase 2: Deep-check (LLM Semantic Comparison, A4/A5/A6)
+
+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)
+   - Read plan.md → extract relevant technical design sections
+   - For each requirement, 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?
+   - Uncovered requirement = Critical finding
+   - Build coverage matrix table
+
+5. **A5 基线一致性**:
+   - Read global `ARCHITECTURE.md` → check naming conventions, BC boundaries
+   - Read global `PHYSICAL-MODEL.md` → check table naming patterns, field conventions
+   - Read global `API-INDEX.md` → check API routing patterns
+   - Compare incremental design against baseline:
+     - Aggregate naming conflicts with existing aggregates → Critical
+     - Table naming conflicts with PHYSICAL-MODEL → Critical
+     - API endpoint conflicts with API-INDEX → Critical
+     - BC boundary contradictions → Critical
+
+6. **A6 conventions 合规**:
+   - Read `team-flow.config.json` → `conventions` section
+   - Load applicable convention files:
+     - `conventions.database` → check DB naming rules, primary key strategy, audit fields
+     - `conventions.backend` → check DDD layering, assembler pattern
+     - `conventions.api` → check annotation style, permission declaration
+   - For each convention rule, check if architecture deliverables comply
+   - Non-compliance = Important finding
+
+### Phase 3: Summary and Verdict
+
+Aggregate all findings and determine verdict.
+
+## Judgment Criteria
+
+| Verdict | Condition | Action |
+|---------|-----------|--------|
+| **PASS** | Critical=0 且 Important=0 | 进入 spec-writer 阶段 |
+| **PASS_WITH_WARNINGS** | Critical=0 且 Important>0 | 警告项交人工裁定，不阻断 |
+| **FAIL** | Critical>0 | 必须修正后重新审查 |
+
+**FAIL only triggered by Critical findings**. Important findings (template non-compliance, convention violations) generate warnings but do not block.
+
+## Output Format
+
+```markdown
+# Architecture Auto-Review Report
+
+## Metadata
+- **PRD**: {prd_path}
+- **Plan**: {plan_path}
+- **Change Brief**: {change_brief_path}
+- **Architecture Dir**: {architecture_dir}
+- **Global Arch Dir**: {global_arch_dir}
+- **Review round**: {N}
+- **Reviewer**: architecture-reviewer agent (independent, read-only)
+- **Timestamp**: {ISO 8601}
+
+## Verdict: {PASS | PASS_WITH_WARNINGS | FAIL}
+
+| Severity | Count |
+|----------|-------|
+| Critical | {n} |
+| Important | {n} |
+| Minor | {n} |
+
+## A1 产出完整性 — {PASS/FAIL}
+| File | Exists | Non-empty | Frontmatter | Lines | Status |
+|------|--------|-----------|-------------|-------|--------|
+| architecture.md | ✅ | ✅ | ✅ | {n} | OK |
+| database.md | ✅ | ✅ | ✅ | {n} | OK |
+| api.md | ✅ | ❌ | — | 0 | ❌ FAIL |
+
+## A2 SQL 制品完整性 — {PASS/FAIL}
+| SQL File | Referenced In | Exists | Non-empty | Syntax | Status |
+|----------|--------------|--------|-----------|--------|--------|
+| sql/ddl/new_tables.sql | database.md §3 | ✅ | ✅ | ✅ | OK |
+| sql/migration/data.sql | database.md §5 | ❌ | — | — | ❌ FAIL |
+
+## A3 模板合规性 — {PASS/WARN}
+| File | Template | Required Sections | Missing Sections | Status |
+|------|----------|-------------------|-----------------|--------|
+| architecture.md | templates/architecture.md | Aggregates, BC, CQRS, Context Map | — | ✅ |
+| database.md | templates/database.md | Write Model, Read Model, Schema, Migration | Migration Strategy | ⚠️ |
+
+## A4 需求覆盖 — {PASS/FAIL} ({m}/{n} covered)
+| Requirement | Source | Architecture Coverage | Status |
+|-------------|--------|----------------------|--------|
+| 新增 XX 聚合 | brief §2.1 | architecture.md §1 | ✅ |
+| 修改 YY 表结构 | brief §2.3 | database.md §2 | ✅ |
+| 新增 ZZ API | brief §2.5 | — (not covered) | ❌ |
+
+## A5 基线一致性 — {PASS/FAIL}
+| Check Item | Global Baseline | Incremental Design | Status |
+|-----------|----------------|-------------------|--------|
+| Aggregate naming | ARCHITECTURE.md §2 | architecture.md §1 | ✅ Consistent |
+| Table naming | PHYSICAL-MODEL.md | database.md §3 | ✅ Consistent |
+| API routing | API-INDEX.md | api.md §2 | ⚠️ Conflict |
+
+## A6 conventions 合规 — {PASS/WARN}
+| Convention File | Rule | Deliverable | Compliance | Status |
+|----------------|------|-------------|-----------|--------|
+| db-design.md | t_ prefix | database.md §3 | ✅ Compliant | ✅ |
+| api-conventions.md | hasAuthority | api.md §2 | ❌ Not used | ⚠️ |
+
+## Inconsistency Summary
+| # | Dim | Severity | Baseline Source | Deliverable Location | Description |
+|---|-----|----------|----------------|---------------------|-------------|
+| 1 | A1 | Critical | — | api.md | api.md is empty |
+| 2 | A4 | Critical | brief §2.5 | — | ZZ API not covered in architecture |
+| 3 | A6 | Important | conventions/api-conventions.md | api.md §2 | Permission declaration not using hasAuthority |
+
+## Coverage Statistics
+| Dimension | Required | Covered | Rate |
+|-----------|----------|---------|------|
+| Aggregates | {n} | {m} | {percent}% |
+| Bounded Contexts | {n} | {m} | {percent}% |
+| APIs | {n} | {m} | {percent}% |
+| DB Changes | {n} | {m} | {percent}% |
+```
+
+## Red Lines
+
+**DO:**
+- Read the change brief BEFORE reading the architecture deliverables — establish requirements baseline first
+- Read global architecture baseline BEFORE checking consistency — understand As-Is before judging To-Be
+- Cite baseline source (global file:section) AND deliverable location (file:line) for every finding
+- Load and check conventions when conventions_config is provided
+- Build an explicit coverage matrix for A4, not a vibes-based assessment
+- Give a clear, unambiguous verdict
+
+**DON'T:**
+- Modify any file — you are read-only, report goes in your response
+- Guess or infer requirements not explicitly in change-brief or plan
+- FAIL on Important findings — FAIL is Critical-only
+- Skip the Pre-check phase and jump straight to semantic analysis
+- Omit the baseline source reference for any finding
+- Evaluate architecture "elegance" or "beauty" — those are subjective, for human review only
+- Check convention files that don't exist — if conventions_config is empty, skip A6 silently

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.27.2`
+- Current: `v0.28.0`
 - 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.27.2",
+  "version": "0.28.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.27.2: auto-sync CLI version with plugin version
+# v0.28.0: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.27.2"
+PLUGIN_VERSION="0.28.0"
 
 # ═══════════════════════════════════════════════════════════════
 # 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.27.2.
+Current version: v0.28.0.
 
 ## Key Documents
 - README.md: Chinese homepage with full usage guide and FAQ

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.27.2",
-  "description": "Unified plugin (23 skills + 8 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.",
+  "version": "0.28.0",
+  "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",
   "bin": {

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "team-flow",
-  "version": "0.27.2",
-  "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.0",
+  "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/config-loader.mjs

@@ -22,6 +22,12 @@ const DEFAULTS = {
   prd: {
     template: 'templates/prd.md',
   },
+  conventions: {
+    // 项目级规范文件路径映射（v0.11 §33）
+    // key = 规范类别，value = 相对于项目根的路径
+    // 各 skill 上下文加载时按 phase 过滤注入
+    // 示例: { database: ".team-flow/conventions/db-design.md", ... }
+  },
 };
 
 export const MODEL_PROFILES = Object.freeze([

package/skills/architecture-design/SKILL.md

@@ -156,6 +156,12 @@ change 进入 closing 阶段时，由 release-archivist 调用 `tf arch-merge` C
 
 architecture-design 执行时的上下文组装：
 
+**conventions 注入（v0.11 §33）**：
+1. 通过 `tf runtime config --get conventions` 获取 conventions 配置
+2. 按 phase 过滤：`database` / `backend` / `api`
+3. 读取匹配的 `.team-flow/conventions/*.md` 文件
+4. 注入为架构决策约束（advisory 级）
+
 **始终加载**：
 1. `Read docs/architecture/INDEX.md`（~50行摘要）
 2. `Read changes/<name>/change-brief.md`（如有）
@@ -177,3 +183,28 @@ architecture-design 执行时的上下文组装：
 
 ## Scope & Limits
 本 skill 覆盖 4A+DDD 架构设计方法及其与 team-flow/compound-engineering 的衔接。落地实现结合项目具体工具；超出本范围见相关 skill 或直接问 agent。
+
+## 阶段转换前规范建议（v0.11 §33，被动式自动沉淀）
+
+architecture-design 阶段即将结束、进入 spec-writer 之前，执行以下规范沉淀协议：
+
+1. **回顾本阶段工作**：扫描本阶段所有用户纠正、CC 观察到的项目既有模式、踩坑记录
+2. **生成规范建议列表**：提取跨 change 可复用的规范条目（排除仅适用于本次 change 的特定业务逻辑）
+3. **去重检查**：对比已有 convention 文件，排除已存在的条目
+4. **向用户展示建议**：
+
+```
+📋 架构设计阶段规范建议
+┌───┬──────────────────────────────────────────────────┐
+│ # │ 规范条目                                          │
+├───┼──────────────────────────────────────────────────┤
+│ 1 │ [条目描述]                                        │
+│   │   来源：[来源说明]                                  │
+│   │   建议写入：.team-flow/conventions/[目标文件]       │
+└───┴──────────────────────────────────────────────────┘
+
+请逐条确认（接受/拒绝/修改），或输入「全部接受」：
+```
+
+5. **用户确认后写入**：接受的条目追加到对应 convention 文件，更新 YAML frontmatter 的 date 字段
+6. **无建议时静默跳过**：如果本阶段没有可沉淀的规范，不弹出确认，直接进入下一阶段

package/skills/architecture-design/templates/conventions/api-conventions.md

@@ -0,0 +1,26 @@
+---
+phase: api
+domain: api
+severity: high
+date: 2026-07-31
+---
+
+# API 规范
+
+> 本文件由 team-flow 被动式自动沉淀机制维护（v0.11 §33）。
+> 请勿手动编辑模板——此文件作为参考模板，实际项目规范在 `.team-flow/conventions/api-conventions.md` 中维护。
+
+## 注解风格
+- （项目级规范在此补充，如：使用 @PostResource / @GetResource 注解）
+
+## 权限声明
+- （项目级规范在此补充，如：统一使用 hasAuthority 进行权限声明）
+
+## 请求/响应格式
+- （项目级规范在此补充）
+
+## 错误码规范
+- （项目级规范在此补充）
+
+## 版本管理
+- （项目级规范在此补充）

package/skills/architecture-design/templates/conventions/backend-patterns.md

@@ -0,0 +1,26 @@
+---
+phase: backend
+domain: backend
+severity: high
+date: 2026-07-31
+---
+
+# 后端分层规范
+
+> 本文件由 team-flow 被动式自动沉淀机制维护（v0.11 §33）。
+> 请勿手动编辑模板——此文件作为参考模板，实际项目规范在 `.team-flow/conventions/backend-patterns.md` 中维护。
+
+## 分层架构
+- （项目级规范在此补充，如：DDD 四层——web / application / domain / infrastructure）
+
+## Assembler 层
+- （项目级规范在此补充，如：必须包含 assembler 层，使用 MapStruct）
+
+## 异常处理
+- （项目级规范在此补充）
+
+## 日志规范
+- （项目级规范在此补充）
+
+## 依赖注入
+- （项目级规范在此补充）

package/skills/architecture-design/templates/conventions/db-design.md

@@ -0,0 +1,31 @@
+---
+phase: database
+domain: db
+severity: high
+date: 2026-07-31
+---
+
+# DB 设计规范
+
+> 本文件由 team-flow 被动式自动沉淀机制维护（v0.11 §33）。
+> 请勿手动编辑模板——此文件作为参考模板，实际项目规范在 `.team-flow/conventions/db-design.md` 中维护。
+
+## 表命名
+- （项目级规范在此补充，如：表名必须以 `t_` 前缀开头）
+
+## 主键策略
+- （项目级规范在此补充，如：主键使用 sequence generator 表生成）
+
+## 审计字段
+- （项目级规范在此补充，如：所有表必须包含 BaseEntity 审计字段）
+
+## DDL 管理
+- 所有 DDL 必须写入 `schema-baseline.sql`
+- 增量变更必须提供 migration 脚本
+- SQL 文件放在 `changes/<name>/architecture/sql/` 目录
+
+## 索引规范
+- （项目级规范在此补充）
+
+## 字段命名
+- （项目级规范在此补充，如：snake_case、禁止使用 SQL 保留字）

package/skills/architecture-design/templates/conventions/frontend-patterns.md

@@ -0,0 +1,26 @@
+---
+phase: frontend
+domain: frontend
+severity: medium
+date: 2026-07-31
+---
+
+# 前端规范
+
+> 本文件由 team-flow 被动式自动沉淀机制维护（v0.11 §33）。
+> 请勿手动编辑模板——此文件作为参考模板，实际项目规范在 `.team-flow/conventions/frontend-patterns.md` 中维护。
+
+## 框架选型
+- （项目级规范在此补充，如：Vue 2 Options API）
+
+## UI 组件库
+- （项目级规范在此补充，如：Ant Design Vue 1.7）
+
+## 权限指令
+- （项目级规范在此补充，如：使用 v-has 权限指令）
+
+## 状态管理
+- （项目级规范在此补充）
+
+## 路由规范
+- （项目级规范在此补充）

package/skills/build-executor/SKILL.md

@@ -17,6 +17,11 @@ When `architecture/sql/` exists, also read:
 
 Check workflow mode first: `tf state get <change-dir> workflow`. If `tweak` → direct edit mode. If `hotfix` or `full` → standard contract-first discipline.
 
+**conventions 注入（v0.11 §33）**：
+- 通过 `tf runtime config --get conventions` 获取 conventions 配置
+- 按 phase 过滤：`backend` / `api`
+- 注入为实施约束（代码产出时遵循）
+
 Branch/worktree preflight before ANY implementation edit (mandatory — do not skip):
 1. Run the isolation check:
    ```bash
@@ -165,3 +170,28 @@ Don't report completion until: tests pass, contract obligations satisfied, revie
 - **Parse failures**: Stop and report exact line/format issue. Route back to `contract-builder`.
 - **Missing artifacts**: Route back to appropriate upstream skill. Don't guess.
 - **User interruption**: Progress ledger enables recovery. Check ledger on resume.
+
+## 阶段转换前规范建议（v0.11 §33，被动式自动沉淀）
+
+build-executor 阶段即将结束、进入 closing 之前，执行以下规范沉淀协议：
+
+1. **回顾本阶段工作**：扫描本阶段所有用户纠正、CC 观察到的项目既有模式、踩坑记录
+2. **生成规范建议列表**：提取跨 change 可复用的规范条目（排除仅适用于本次 change 的特定业务逻辑）
+3. **去重检查**：对比已有 convention 文件，排除已存在的条目
+4. **向用户展示建议**：
+
+```
+📋 构建执行阶段规范建议
+┌───┬──────────────────────────────────────────────────┐
+│ # │ 规范条目                                          │
+├───┼──────────────────────────────────────────────────┤
+│ 1 │ [条目描述]                                        │
+│   │   来源：[来源说明]                                  │
+│   │   建议写入：.team-flow/conventions/[目标文件]       │
+└───┴──────────────────────────────────────────────────┘
+
+请逐条确认（接受/拒绝/修改），或输入「全部接受」：
+```
+
+5. **用户确认后写入**：接受的条目追加到对应 convention 文件，更新 YAML frontmatter 的 date 字段
+6. **无建议时静默跳过**：如果本阶段没有可沉淀的规范，不弹出确认，直接进入下一阶段

package/skills/spec-writer/SKILL.md

@@ -53,6 +53,11 @@ Read `docs/solutions/INDEX.md` if it exists. Filter entries where `phase = spec
 
 `architecture/` 目录不存在时（判定为 `skipped`）跳过本段。
 
+**conventions 注入（v0.11 §33）**：
+- 通过 `tf runtime config --get conventions` 获取 conventions 配置
+- 读取所有匹配的 convention 文件
+- 注入为规格约束（specs/design/tasks 产出时遵循）
+
 ## Config Check
 
 Run: `tf runtime config --get artifacts.order` — generate in configured order (default: proposal → specs → design → tasks). Run with `artifacts.skip` — skip any listed artifacts.
@@ -149,3 +154,28 @@ Do not start implementation after writing planning artifacts. Once stable, valid
 - **Missing templates**: Fall back to artifact structure defined in this skill
 - **User interruption**: Artifacts on disk are the recovery checkpoint; resume from first missing/incomplete one
 - **Validation failure**: Fix before handoff — do not hand off broken artifacts
+
+## 阶段转换前规范建议（v0.11 §33，被动式自动沉淀）
+
+spec-writer 阶段即将结束、进入 build-executor 之前，执行以下规范沉淀协议：
+
+1. **回顾本阶段工作**：扫描本阶段所有用户纠正、CC 观察到的项目既有模式、踩坑记录
+2. **生成规范建议列表**：提取跨 change 可复用的规范条目（排除仅适用于本次 change 的特定业务逻辑）
+3. **去重检查**：对比已有 convention 文件，排除已存在的条目
+4. **向用户展示建议**：
+
+```
+📋 规格编写阶段规范建议
+┌───┬──────────────────────────────────────────────────┐
+│ # │ 规范条目                                          │
+├───┼──────────────────────────────────────────────────┤
+│ 1 │ [条目描述]                                        │
+│   │   来源：[来源说明]                                  │
+│   │   建议写入：.team-flow/conventions/[目标文件]       │
+└───┴──────────────────────────────────────────────────┘
+
+请逐条确认（接受/拒绝/修改），或输入「全部接受」：
+```
+
+5. **用户确认后写入**：接受的条目追加到对应 convention 文件，更新 YAML frontmatter 的 date 字段
+6. **无建议时静默跳过**：如果本阶段没有可沉淀的规范，不弹出确认，直接进入下一阶段

package/skills/workflow-orchestrator/SKILL.md

@@ -39,6 +39,9 @@ Do NOT invoke for:
 ### S1: 路径路由器
 **先做需求选择**（v0.15.0 多需求）：读 `.team-flow/registry.yaml`，确定 `active_requirement`（多需求则询问操作哪个/新建）。再判断 7 种入口路径之一；检查 baseline.md / CONCEPTS.md 并注入；复利注入（INDEX.md top-5）。**路由结果必须向用户显式确认**（路由是建议非决定）。详见 `references/s1-path-router.md`。
 
+**conventions 注入（v0.11 §33）**：
+- 读取 conventions 配置，注入为需求分析上下文
+
 ### S2: PRD + 原型阶段
 
 **⛔ MANDATORY：执行S2阶段前，必须先读取 `references/s2-prd-prototype-loop.md`**
@@ -180,3 +183,28 @@ plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层
 1. 当前所处阶段（S1-S5）与 `.team-flow/requirements/<req-id>/orchestrator.yaml` 状态
 2. 已产出的制品（PRD/原型/plan/changes）
 3. 下一步建议（调用哪个 skill / 进入哪个 change）
+
+## 阶段转换前规范建议（v0.11 §33，被动式自动沉淀）
+
+workflow-orchestrator S1 阶段即将结束、进入 S2 之前，执行以下规范沉淀协议：
+
+1. **回顾本阶段工作**：扫描本阶段所有用户纠正、CC 观察到的项目既有模式、踩坑记录
+2. **生成规范建议列表**：提取跨 change 可复用的规范条目（排除仅适用于本次 change 的特定业务逻辑）
+3. **去重检查**：对比已有 convention 文件，排除已存在的条目
+4. **向用户展示建议**：
+
+```
+📋 需求编排阶段规范建议
+┌───┬──────────────────────────────────────────────────┐
+│ # │ 规范条目                                          │
+├───┼──────────────────────────────────────────────────┤
+│ 1 │ [条目描述]                                        │
+│   │   来源：[来源说明]                                  │
+│   │   建议写入：.team-flow/conventions/[目标文件]       │
+└───┴──────────────────────────────────────────────────┘
+
+请逐条确认（接受/拒绝/修改），或输入「全部接受」：
+```
+
+5. **用户确认后写入**：接受的条目追加到对应 convention 文件，更新 YAML frontmatter 的 date 字段
+6. **无建议时静默跳过**：如果本阶段没有可沉淀的规范，不弹出确认，直接进入下一阶段

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

@@ -5,10 +5,12 @@
 ## Route to need-explorer
 Change is fuzzy, scope unclear, comparing options, no stable change name.
 
-## Route to architecture-design (v0.9 §26)
+## Route to architecture-design (v0.9 §26, v0.11 §34 审查增强)
 
 Guard: `arch_design_decision` in `.team-flow.yaml` is `null` → must run before spec-writer.
 
+### Step 1: Dispatch architecture-design sub-agent
+
 Dispatch `architecture-design` as sub-agent with inputs:
 - `change-brief.md`（scope / AC / 技术方向）
 - `prd/vN/plan.md` 高阶技术设计段
@@ -26,9 +28,38 @@ artifacts:                       # required 时必填
   - architecture/api.md
 ```
 
-**Reasonableness check**（workflow-start 确认后写入 yaml）：
+### Step 2: Auto-review (v0.11 §34, decision=required 时触发)
+
+When `decision: required`, dispatch `architecture-reviewer` as sub-agent with inputs:
+- `prd_path`, `plan_path`, `change_brief_path`
+- `architecture_dir`（Step 1 产出目录）
+- `global_arch_dir`（`docs/architecture/`）
+- `conventions_config`（从 `team-flow.config.json` 读取）
+
+**交接后产物校验**（defense in depth）：
+```bash
+test -f <architecture_dir>/architecture.md && test -s <architecture_dir>/architecture.md && echo OK
+```
+- OK → dispatch reviewer
+- 缺失/为空 → **不派 reviewer**，resume architecture-design 补全
+
+**审查循环**（≤3 轮 + 收敛检测）：
+```
+reviewer 报告 → FAIL → 不一致项交给 architecture-design 修正 → 重新审查
+  → 收敛（不一致项缩小）→ 继续循环
+  → 不收敛（连续两轮不一致项集合无缩小）→ 立即转人工
+  → 满 3 轮仍 FAIL → 转人工
+reviewer 报告 → PASS / PASS_WITH_WARNINGS → 进入 Step 3
+```
+
+报告落盘到 `changes/<name>/architecture/auto-review.md`。
+
+### Step 3: Reasonableness check
+
+workflow-start 确认后写入 yaml：
 - `skipped` + reason inconsistent with brief/plan scope → **BLOCK**（如 scope 含"新增 API"但 reason 说"不涉及架构变更"）
 - `required` + artifacts files missing on disk → **BLOCK**
+- `required` + auto-review FAIL → **BLOCK**（修正后再写入）
 - `null`（未判定）→ **BLOCK**
 
 ```bash
@@ -39,7 +70,7 @@ tf state set <change-dir> arch_design_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 tf state set <change-dir> arch_design_artifacts "architecture/architecture.md,architecture/database.md,architecture/api.md"
 ```
 
-**hotfix / tweak 不豁免**：同样过 architecture-design 子代理判断门。
+**hotfix / tweak 不豁免**：同样过 architecture-design 子代理判断门（hotfix 可能正是架构缺陷导致）。
 
 ## Route to spec-writer
 Guard: `tf runtime guard check <dir> exploring specifying --json` → fail = BLOCK.