@xulthekl/team-flow 0.60.0 → 0.61.0

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

@@ -1,3 +1,3 @@
-# team-flow v0.60.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.61.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 + independent business analysis. 28 skills + 17 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.60.0",
+      "version": "0.61.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.60.0",
+  "version": "0.61.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) + business-analysis (independent requirement/scenario artifact) + design-system (design tokens + component contract + AI primer + showcase) + test-strategy (test strategy design) + project-initialize (new service onboarding) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
   "source": "./",
   "author": {

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.60.0",
+  "version": "0.61.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.60.0"
+    "version": "0.61.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) + business-analysis (independent requirement/scenario artifact) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
-  "version": "0.60.0",
+  "version": "0.61.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.60.0"
+    "version": "0.61.0"
   },
   "plugins": [
     {
       "name": "team-flow",
       "description": "Unified workflow with planning artifacts, execution contracts, TDD, review gates, systematic debugging, delta spec sync, architecture-design, independent business analysis, and local HTML prototyping.",
-      "version": "0.60.0",
+      "version": "0.61.0",
       "source": ".",
       "author": {
         "name": "LT",

package/CHANGELOG.md

@@ -4,6 +4,18 @@ All notable changes to `team-flow` will be documented in this file.
 
 The format loosely follows Keep a Changelog.
 
+## [0.61.0] - 2026-09-21
+
+### Added（三优化点：决策话术人类化 / Hotfix 命中源 change / 拆分粗粒度优先）
+
+1. **决策话术人类化规范**（v0.61.0 新增）：在 `workflow-orchestrator` 与 `workflow-start` 两入口 skill 新增「决策话术规范（人类化原则）」节（4 条规则 + 反例），并在 `docs/decision-points.md` 顶部加锚点。面向用户的决策提问用白话、给可理解选项，避免暴露内部路径名/技术术语（反例：S1 直接问"path 路由名" → 改为"你这步想做什么" + 白话选项）。
+2. **Hotfix 增强：命中源 change**（v0.61.0 新增，纯文档承载）：bug 修复时优先匹配源 change（`git blame` 定位）→ 命中则复用源 change 的 design/specs/tests 上下文做轻量修复，并在 `change-brief.md` frontmatter 写入 `source_change_ref`；非命中走原 Hotfix 快通道。绝不静默 reopen 源 change，失准须降级并请用户确认。**实现形态**：复用 `bug-investigator` 报告段 + `change-brief` `source_change_ref` + learnings 承载，**不动 `state-loader` SETTABLE_FIELDS**（规避门禁变更）。
+3. **change 拆分粗粒度优先**（v0.61.0 新增）：`ce-plan/references/change-splitting.md` 顶部加「拆分默认姿态（粗粒度优先）」节——宁粗勿细，仅当「越过所有权边界 / 需独立并行验证 / 团队领取需要」任一成立才拆细；`change-split-auditor` D3「Too small」段加主动建议合并（change 数 > Standard 5 时给合并候选）。拆太细仅建议不硬拦（D3 维持 advisory）。
+
+### Changed（设计增强方案）
+
+- 设计增强方案升 `docs/architecture-api-db-design-enhancement-v0.26.md`（承袭 v0.25，目标插件 v0.61.0）：§202 话术规范、§203 bugfix 增强 Hotfix 纯文档承载、§204 粗粒度优先、§205 P1.5 可跳过判定、§206 制品链校验清单、§207 决策落实状态表。
+
 ## [0.60.0] - 2026-09-12
 
 ### Changed（`decision-surrogate` → `jarvis`：更名 + 重定位 + 首次通道实测修订）

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

package/README.md

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

package/agents/change-split-auditor.md

@@ -58,6 +58,7 @@ Use Bash for mechanical extraction (`grep` for depends_on patterns) and manual g
 1. For each change, assess scope from its description, task count, and affected modules
 2. **Too large** signals: >5 modules affected, >15 tasks estimated, spans multiple bounded contexts → Important (recommend split)
 3. **Too small** signals: single-file change, <2 tasks, trivial config tweak → Important (recommend merge)
+   - **主动建议合并（v0.61.0 粗粒度优先，设计依据 v0.26 §204）**：当本 PRD 的 change 总数超过中等上限（Standard > 5）时，审计员除标记单体"太小"外，**必须主动给出合并候选**——列出可合并的 change 对及其共同所有权单元，供 ce-plan 回退收敛。目的：落实"宁粗勿细"默认姿态，避免每个细 change 都走完整 8 态 + 4+1 产物 + 架构增量 + 复利回写（ceremony 开销 > 价值）。
 4. Report the distribution: list changes by estimated size, flag outliers (>2x median or <0.5x median)
 
 This dimension is advisory — flag but do not FAIL on granularity alone.

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.60.0`
+- Current: `v0.61.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/docs/decision-points.md

@@ -2,6 +2,10 @@
 
 本文档集中定义了 team-flow 工作流中所有需要用户明确确认的决策点。每个决策点（Decision Point）都是工作流中的关键门禁，确保用户在自动化流程中始终保持最终决策权。工作流中的 skill 在到达决策点时必须暂停执行、向用户呈现所需信息，并等待明确指令后方可继续。
 
+## 话术规范（人类化原则，v0.61.0 新增）
+
+所有 DP 的提问文案必须遵守「用大白话讲结果、不讲机制」：选项 label ≤ 12 字、零术语，描述"选了会怎样"；技术术语下沉 description 且首现括注白话等价；决策点 = 帮你拍板的岔路口，不让你做机制选型。详细规则与正反例见 `workflow-orchestrator` / `workflow-start` SKILL.md 的「决策话术规范」节（设计依据：设计增强方案 v0.26 §202）。
+
 ## DP-0: 设计前确认（User Confirmation Gate）
 
 - **编号**：DP-0

package/docs/plans/2026-09-21-001-three-optimization-eval.md

@@ -0,0 +1,127 @@
+# 三个工作流优化点 · 设计评估笔记
+
+> 日期：2026-09-21
+> 遵循流程：`CONTRIBUTING.md`「Large Changes」——重大工作流变更先写 design note，再同步改 skills / templates / examples。
+> 本文档为**评估稿（第一步）**：评估现状、缺口、影响面、可行性与建议方案。实施待评估通过后再落地。
+
+## 0. 评估结论速览
+
+| # | 优化点 | 现状 | 缺口 | 可行性 | 实施强度 |
+|---|--------|------|------|--------|----------|
+| 1 | 决策话术人类化（避免太技术） | DP 门禁集中定义于 `docs/decision-points.md`，但提问文案由各 skill 的 AskUserQuestion 自定，无"白话"硬规则 | 选项 label/description 含术语（执行模式 SDD/Inline、聚合/限界上下文/CQRS），非技术用户看不懂 | 高（纯文案/规则层，不动状态机） | 改 `decision-points.md` + 各含 DP 的 skill 文案 |
+| 2 | bugfix 匹配源头 change 快速修复 | 执行期 bug 走 `workflow-start → bug-investigator`（debugging 侧路径）；S1 有 Hotfix 入口。但**无"bug 回溯到引入它的源 change"机制** | 发现 bug 时无法复用源 change 的 scope/AC/design/tests 上下文，每次从零确认 | 中（新增 `source_change` 字段 + 匹配检索 + 轻量修复路由，复用 hotfix/tweak 通道） | 改 S1 + workflow-start + bug-investigator + change-brief 模板 + state schema |
+| 3 | change 拆分原则明确定义，不建议拆太细 | `change-split-auditor` D5（所有权自包含，v0.9 根因判据）已防"切碎"FAIL；D3 粒度"太小"仅 Important（advisory）；`ce-plan/references/change-splitting.md` 有完整判据 | 缺**显式默认姿态**："宁粗勿细，只有越过所有权边界才拆"。文档是判据（什么算坏），不是原则（默认怎么拆） | 高（文档/判据层微调） | 改 `change-splitting.md` + `change-split-auditor` D3 权重 |
+
+---
+
+## 1. 优化点①：决策话术人类化
+
+### 1.1 现状
+- 所有需要用户拍板的节点集中在 `docs/decision-points.md`（DP-0 ~ DP-7），由各 skill 通过平台阻塞问题工具（AskUserQuestion）发起。
+- 现有话术规范只管**流程**（need-explorer「一次一问」「给 2-3 个选项带取舍」「先复述确认」），**不管话术的"技术浓度"**。
+- 术语直灌选项，非技术 PM / 业务方看不懂，例如：
+  - DP-4「执行模式选择」：`propose waves` / `SDD` / `Inline` / `Batch Inline`（机制词进 label）。
+  - DP-A「架构产品确认」：`聚合` / `限界上下文` / `CQRS` / `读模型`（架构术语无白话等价）。
+  - S1 路径路由：`续版需求` / `重新计划` / `单 change 快速通道`（行话，未解释"选了会怎样"）。
+
+### 1.2 缺口（需新增的硬规则）
+1. **可见文案用"人话"**：用"结果/价值"描述而非"机制"；术语首次出现必须括注白话等价（如 `聚合（一组相关的业务数据，比如一张订单及其明细）`）。
+2. **选项口吻**：以"你选哪个"的口吻；label ≤ 12 字；description 讲"选它会怎样"，不写"这是什么"。
+3. **术语下沉**：SDD / Inline / 契约 / 聚合等技术细节沉到 description 或折叠区，**不进 label**。
+4. **定位**：决策点是"帮你拍板的岔路口"，不是考试——避免让用户做他没能力判断的技术选型。
+
+### 1.3 影响面（需 audit 的 DP 文案）
+- `need-explorer`（DP-1）、`workflow-start`（DP-0 / G4 同步 / DP-4 / DP-6 / DP-7）、`contract-builder`（DP-3）、`architecture-design`（DP-A）、`ce-plan` / `ce-brainstorm`（模式选择）、`workflow-orchestrator`（S1 路由、S4 G5 同步）、`prototype`（决策点中继）。
+- 落点：`docs/decision-points.md` 新增「话术规范」一节 + 上述 skill 的提问 prompt 文案。
+
+### 1.4 方案与风险
+- 方案：新增一处统一话术规范（原则 + 正反例），并 audit 现有所有 DP 文案，改写为白话版；术语保留在 description 内以保证精度。
+- 风险：过度口语化可能损失精度 → 用"label 白话 + description 含术语"分层化解。可行性高，不动状态机。
+
+---
+
+## 2. 优化点②：bugfix 匹配源头 change 快速修复
+
+### 2.1 现状
+- 执行期 bug：`workflow-start`「Route to bug-investigator」→ `executing → debugging` 侧路径 → 回 `build-executor`。`bug-investigator` 是纯科学根因调查，**不认 change 来源**。
+- 产品级：`workflow-orchestrator` S1「紧急修复（Hotfix）」入口 → 直接建 change（`type:hotfix`，注入 bug 描述替代 PRD）→ `workflow-start`，closing 强制补录复利。
+- **关键缺口**：无论执行期还是线上发现的 bug，都**没有"把缺陷回溯到引入它的源 change"的机制**。无法复用源 change 的 `change-brief` / `design.md` / `specs/` / `tests` / `learnings.md` 上下文，每次都从零确认修复 scope。
+
+### 2.2 方案建议（新增"bugfix 快速修复"模式）
+1. **触发**：用户报 bug / 线上问题 / 已 closing change 暴露缺陷（独立于 Hotfix）。
+2. **匹配源 change**：
+   - `git blame` + 受影响文件/符号 → 定位引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查 `change_dir`；
+   - 或按受影响 capability 在全局 `specs/` 检索归属 change。
+3. **快速修复路由**：
+   - **命中源 change** → 复用其 `change-brief` / `design.md` / `specs` 作"已知设计约束"上下文，走轻量修复（tweak / hotfix 形态，但带 `source_change` 引用字段），省去重复 scope 确认。
+   - **非命中**（独立缺陷 / 新文件）→ 走现有 Hotfix。
+4. **字段与产物**：
+   - `workflow-start` 状态文件新增 `source_change` 字段；新增 `reopen` / `quick-fix` 路由（reopen 仅限用户确认，绝不静默）。
+   - `bug-investigator` 报告新增「源 change 关联」段（命中则填 change_dir + 复用约束）。
+
+### 2.3 影响面
+- `workflow-orchestrator` S1（增强/新增 Hotfix 判据，叠加"是否命中源 change"分支）。
+- `workflow-start`（新增 `source_change` 字段 + reopen/quick-fix 路由 + Guardrails）。
+- `bug-investigator`（报告模板加溯源段）。
+- `changes/<name>/change-brief.md` 模板（加 `source_change_ref` frontmatter）。
+- `src/schema/change.ts` 状态 schema + `docs/artifact-contract.md`。
+
+### 2.4 可行性与风险
+- 可行性：中。核心是"源 change 关联"检索，可基于既有 `git blame` + change 元数据（已有 `change_dag` / `change-brief`）。复用 hotfix/tweak 快速通道，不新造状态。
+- 风险：`git blame` 关联可能失准（重构 / 多 change 共改一行）→ **必须让用户确认匹配结果**，不做静默自动 reopen；匹配失败时优雅降级到 Hotfix。
+
+---
+
+## 3. 优化点③：change 拆分原则明确定义，不建议拆太细
+
+### 3.1 现状
+- `change-split-auditor` D5（v0.9 根因判据·所有权自包含）：≥2 change 瓜分同一聚合/上下文/读模型/契约 → **FAIL（切碎）**；细到无设计单元 → **FAIL**；跨无关节所有权单元 → **FAIL**。
+- D3 粒度均衡：`太大 → Important（建议拆）`；`太小 → Important（建议合）`，**advisory，不单独 FAIL**。
+- `ce-plan/references/change-splitting.md`：完整所有权判据 + Good/Anti-Patterns + Depth Guidance（Standard 2-5 个 change）。
+
+### 3.2 缺口
+- 现有内容是**判据（什么算坏）**，不是**原则（默认怎么拆）**。用户/ce-plan 在"可拆可不拆"时缺一条**显式默认姿态**："宁粗勿细——只有越过所有权边界、或需要独立并行验证、或需要团队分别领取时，才向下拆细"。
+- D3「太小」仅 Important 不阻断，倾向多拆时 auditor 不拦；需把"拆太细"的代价上升为**默认原则**。
+
+### 3.3 方案建议
+1. `change-splitting.md` 顶部显式声明**默认拆分姿态**（粗粒度优先三条件：越过所有权边界 / 可独立并行验证 / 团队领取需要——三者任一成立才拆细）。
+2. `change-split-auditor` D3 提升"太小"信号权重：当单 PRD 的 change 数超过中等规模上限（如 Standard > 5）时，auditor 主动建议合并并给出合并候选；在 Depth Guidance 写"粗粒度优先"。
+3. 明确"拆太细"的代价：每个 change 走完整 8 态 + 4+1 产物 + 架构增量 + 复利回写，ceremonies 开销 > 价值（现有 anti-pattern 已提，上升为默认原则）。
+
+### 3.4 可行性与风险
+- 可行性：高（文档/判据层微调，不动状态机）。风险低。
+
+---
+
+## 4. 按 plugin 流程的后续实施路径
+
+> 本笔记评估通过后，依 `CONTRIBUTING.md` 同步改 skills / templates / examples：
+
+1. **设计笔记**：本文（已完成评估）。
+2. **话术规范**：`docs/decision-points.md` 新增「话术规范」节 + audit 改写各 DP 文案（优化点①）。
+3. **bugfix 模式**：S1 + workflow-start + bug-investigator + change-brief 模板 + state schema（优化点②）。
+4. **拆分原则**：`change-splitting.md` + `change-split-auditor` D3（优化点③）。
+5. **tests**：`npm test` 过 frontmatter-lint；补「决策话术白话」自检 / change-split 粗粒度优先用例（如需要）。
+6. **CHANGELOG.md**：记录三处用户可见变更。
+7. **examples**：必要时更新 `docs/examples/` 中 bugfix / 粗粒度拆分样例。
+
+## 5. 开放问题（待大哥拍板）
+
+## 6. 决策记录（大哥拍板，2026-09-21）
+
+| # | 开放问题 | 决策 | 落地影响 |
+|---|---------|------|---------|
+| ② | 新增独立 bugfix 入口 vs 增强现有 Hotfix | **增强现有 Hotfix**（改动小） | S1 Hotfix 入口内叠加"是否命中源 change"分支；不新增独立入口 |
+| ① | 全 DP 改双行 vs 仅关键 DP | **最小改动：在两个入口 skill 内各加一小段「话术规范」定义**（workflow-orchestrator + workflow-start） | 不逐个改 subagent skill；入口 skill 设标准，subagent 提问沿用同一口径（need-explorer/ce-plan 等后续可引用，非本次强制） |
+| ③ | D3「太小」升 Critical vs 加强建议 | **只建议、不硬拦**（2026-09-21 拍板） | 保持 advisory；声明"粗粒度优先"原则 + 审计员主动建议合并，不升 Critical |
+
+### 6.1 据此锁定的实施方案（待 ③ 拍板后一并实施）
+
+- **优化点①（最小改动）**：在 `workflow-orchestrator/SKILL.md` 与 `workflow-start/SKILL.md` 各新增一节「决策话术规范」（label 白话 + description 含术语；术语首现括注白话等价；选项口吻"你选哪个"；决策点=帮拍板的岔路口）。同步在 `docs/decision-points.md` 顶部加"话术规范"引用锚点。
+- **优化点②（增强 Hotfix）**：
+  - `workflow-orchestrator` S1 Hotfix 入口：用户报 bug 时，先尝试 `git blame` + change 元数据反查源 change；命中则在建 change 时携带 `source_change` 引用，非命中走原 Hotfix。
+  - `workflow-start` Hotfix 路由：新增 `source_change` 字段消费 + "复用源 change 上下文做轻量修复"说明 + Guardrail（匹配结果必须用户确认，失准降级 Hotfix，绝不静默 reopen）。
+  - `bug-investigator` 报告模板：新增「源 change 关联」段。
+  - `changes/<name>/change-brief.md` 模板：`source_change_ref` frontmatter（可选）。
+  - `src/schema/change.ts` 状态 schema：新增 `source_change` 字段（additive）+ `docs/artifact-contract.md` 记录。
+- **优化点③（待 ③ 拍板）**：`change-splitting.md` 顶部声明"粗粒度优先"原则；`change-split-auditor` D3 主动建议合并（不升 Critical）。

package/docs/{usage-guide.md → team-flow /344/275/277/347/224/250/350/257/264/346/230/216/357/274/210/347/240/224/345/217/221/345/233/242/351/230/237/347/211/210/357/274/211.md" }

@@ -1,6 +1,6 @@
 # team-flow 使用说明（研发团队版）
 
-> 版本锚点：v0.60.0（28 skills + 17 agents）· 更新日期：2026-09-12
+> 版本锚点：v0.61.0（28 skills + 17 agents）· 更新日期：2026-09-21
 > 读者：使用 team-flow 做日常研发的工程师。不需要你懂插件内部实现，只需要照着路径走。
 > 配套文档：安装细节见 [INSTALL.md](../INSTALL.md)；状态机细节见 [state-machine.md](state-machine.md)；决策点细节见 [decision-points.md](decision-points.md)；平台差异见 [platform-matrix.md](platform-matrix.md)。
 
@@ -42,7 +42,7 @@
 
 ```
 产品级（workflow-orchestrator）——管"做什么、什么顺序"
-  模糊需求 → PRD+原型 → 实施计划 → 产品级架构 → change 拆分分发 → 全局监控
+  模糊需求 → PRD+原型 → 产品级架构（ARCH）→ 实施计划 → change 拆分分发 → 全局监控
                               │
                               ▼ 每个 change 独立走一遍
 变更级（workflow-start）——管"怎么做"，8 态状态机
@@ -65,13 +65,15 @@
 npm install -g @xulthekl/team-flow
 ```
 
-> SessionStart hook 会在每次会话启动时自动核对 tf CLI 版本与插件版本，不一致会自动 `npm install -g` 同步，**通常你不需要手动升级 CLI**。
+> SessionStart hook 会在每次会话启动时自动核对 tf CLI 版本与插件版本，**只升不降**（CLI 比插件新时跳过同步——避免旧版插件缓存把新 CLI 降级），低于插件版本时自动 `npm install -g` 同步，**通常你不需要手动升级 CLI**。
 
 ### 2.2 验证安装
 
 ```bash
-tf --version        # 应输出 0.44.0
-tf doctor           # 体检：版本一致性、hooks、runtime skills、docs 完整性
+tf --version        # 应输出 0.60.0
+tf doctor           # 体检 13 项固定 + 1 项条件：版本一致性 / plugin author / hooks / Codex manifest / skills /
+                    # runtime 分发 / dist / Node 版本 / docs / change 状态 / change 测试门禁 / 架构状态 / 复利台账
+                    # （末项"配置"仅在仓库根存在 team-flow.config.json 时出现）
 ```
 
 在 Claude Code 会话中，新开一个会话应能看到注入的 team-flow 上下文提示。输入 `/team-flow:` 应能补全出 `workflow-start`、`workflow-orchestrator` 等 skill。
@@ -83,8 +85,8 @@ tf doctor           # 体检：版本一致性、hooks、runtime skills、docs
 | 等级 | 平台 | 门禁能力 |
 |------|------|---------|
 | ★ 完整 | Claude Code | PreToolUse 硬拦截（非 build 态禁止写实施代码）+ 状态机门禁 + 规则注入 |
-| ☆ 中等 | Cursor | SessionStart 注入 + phase-guard 规则文件（软约束，无硬拦截） |
-| ○ 提示级 | Codex / Gemini CLI / OpenCode / Cline / Kiro / Windsurf 等 | phase-guard 规则文件常驻上下文 + CLI 门禁；依赖模型自觉 |
+| ☆ 中等 | Cursor / GitHub Copilot CLI | SessionStart 注入 + phase-guard 规则文件（软约束，无硬拦截） |
+| ○ 提示级 | Codex / Gemini CLI / OpenCode / WorkBuddy / ZCODE / Trae / Cline / Kiro / Windsurf 等 | phase-guard 规则文件常驻上下文 + CLI 门禁；依赖模型自觉 |
 
 **含义**：在非 Claude Code 平台上，状态机门禁（`tf state transition` 时的 guard 校验）依然硬生效，但"非 build 态写代码"没有运行时硬拦截——靠规则文件提示约束。
 
@@ -97,6 +99,9 @@ tf doctor           # 体检：版本一致性、hooks、runtime skills、docs
 ```
 你手头是什么任务？
 │
+├─ 工作空间还没有代码服务（空目录 / 无技术栈特征）
+│     → /team-flow:project-initialize（服务初始化引导，见 5.1）
+│
 ├─ 既有项目第一次用 team-flow（还没有 docs/architecture/baseline.md）
 │     → 先跑一次 workflow-bootstrap（一次性接入，见 5.1）
 │
@@ -106,20 +111,27 @@ tf doctor           # 体检：版本一致性、hooks、runtime skills、docs
 ├─ 已在一个 change 目录里（有 .team-flow.yaml），要继续 / 开始 / 恢复
 │     → /team-flow:workflow-start（变更级唯一入口，见 5.3）
 │
-├─ 紧急小 bug 修复（≤2 任务、≤2 文件、不动 schema/API）
+├─ 紧急小 bug 修复（≤2 任务、≤2 文件，不动 schema/API、不新增模块）
 │     → hotfix 模式（workflow-start 会自动识别，见 5.4）
 │
-├─ 极小调整（≤4 任务的纯配置/文案类）
+├─ 极小调整（≤4 任务、纯配置/文档类文件，不动 schema/API、不新增模块）
 │     → tweak 模式（workflow-start 自动识别，见 5.4）
 │
 └─ 独立的工具性操作
       ├─ 纯架构设计（不走工作流）→ /team-flow:architecture-design
       ├─ 原型绘制/迭代 → /team-flow:prototype
-      ├─ 设计系统创建 → /team-flow:design-system
+      ├─ 设计系统创建/迭代 → /team-flow:design-system
+      ├─ 业务场景/流程分析 → /team-flow:business-analysis
       ├─ 想法探索（不产 PRD）→ /team-flow:ce-ideate
       ├─ 聚焦头脑风暴（已有明确主题，不要全流程）→ /team-flow:ce-brainstorm
+      ├─ 已有冻结 PRD，只做实施计划 → /team-flow:ce-plan
+      ├─ 产品战略锚点 STRATEGY.md → /team-flow:ce-strategy
+      ├─ 把 markdown 发布到 Proof 共享 → /team-flow:ce-proof
       ├─ E2E 测试生成/执行 → /team-flow:e2e
-      └─ 沉淀一条经验 → /team-flow:ce-compound
+      ├─ 长对话上下文交接 → /team-flow:session-handoff
+      ├─ 沉淀一条经验 → /team-flow:ce-compound
+      ├─ 夜间/离席期间代做决策（可选启用）→ /team-flow:jarvis
+      └─ 反馈工作流本身的问题 → /team-flow:workflow-feedback
 ```
 
 **三条反模式，不要做**：
@@ -150,21 +162,25 @@ exploring ──→ specifying ──→ bridging ──→ approved-for-build
 - tweak：`exploring → approved-for-build`（跳过探索/规划/契约）
 
 **规则**：
-- 所有状态转换必须走 `tf state transition`，它内部自动执行 guard 门禁校验，任一维度 FAIL 就不落盘。**不要手工编辑 `.team-flow.yaml` 的 state 字段**——这是红线，CLI 会拒绝非法写入，hook 也永远拦截对该文件的手工修改。
-- 回退是合法的：executing 可以退回 specifying/bridging（发现需求变了，回去改规划，而不是硬改代码）。
+- 所有状态转换必须走 `tf state transition`，它内部自动执行 guard 门禁校验，任一维度 FAIL 就不落盘。**不要手工编辑 `.team-flow.yaml` 的 state 字段**——这是红线：`state` 不在 `tf state set` 白名单（CLI 直接拒绝），且非 build 态下对该文件的 Write/Edit 会被 hook 拦截（build 三态的放行是留给子代理回写产物的，不是留给改状态的）。
+- 回退是合法的（共 7 条路径）：`specifying→exploring`、`bridging→specifying`、`approved-for-build→specifying|bridging`、`executing→specifying|bridging`、`closing→specifying`。发现需求变了就回去改规划，而不是硬改代码。
 - `closing` 即收尾完成态；`abandoned` 是终态，不能再转出。
 
 ### 4.2 三种 workflow 模式
 
-workflow-start 在初始化时自动推断（`tf runtime infer`），你也可以在 DP-0 确认时调整：
+workflow-start 在初始化时自动推断（`tf runtime infer`），你也可以在 DP-0 确认时调整。**推断只在 `workflow` 为 `auto`/未设置时发生**——一旦显式定成 full/hotfix/tweak，后续直接沿用，不再重新推断：
 
-| 模式 | 判据（自动推断） | 特点 | 豁免项 |
+| 模式 | 判据（自动推断） | 特点 | 门禁差异（对比 full） |
 |------|----------------|------|--------|
-| **full** | 默认（不满足下面两个） | 全流程：需求探索→架构门→四件套→契约→执行计划→TDD→逐 wave 审查→完整收尾 | 无 |
-| **hotfix** | ≤2 任务、≤2 文件、不动 schema/API | 跳过需求探索和规划制品，最小契约仍需 DP-3 批准 | test-matrix-complete、执行计划回执 |
-| **tweak** | ≤4 任务的纯配置/文档类 | 直接进 approved-for-build，直接编辑 | 执行计划、逐 wave 审查回执、测试矩阵 |
+| **full** | 默认（不满足下面两个） | 全流程：需求探索→架构门→四件套→契约→执行计划→TDD→逐 wave 审查→完整收尾 | 基准：`executing→closing` 挂 10 维 |
+| **hotfix** | ≤2 任务、≤2 文件，且不动 schema/API、不新增模块 | 跳过需求探索和规划制品，最小契约仍需 DP-3 批准 | 入口换一套更轻的维度：`contract-current`+`dp3-approved` 取代 full 的 artifacts-exist / schema-valid / contract-fresh / dp-gate-passed；不查 `test-matrix-ready`。出口 6 维——省 `test-matrix-complete`、`arch-snapshot`、`delegation-status`、`arch-merged`，**但执行计划与逐 wave 审查回执仍要** |
+| **tweak** | ≤4 任务，且文件全是配置/文档类（无代码文件）、不动 schema/API、不新增模块 | 直接进 approved-for-build，直接编辑 | 入口不查 `execution-plan-ready` / `test-matrix-ready`，但仍查 `artifacts-exist`+`contract-fresh`+`dp-gate-passed`。出口仅 3 维（`tasks-complete`、`tests-passing`、`specs-merged`），省掉其余 7 项 |
+
+**注意三件事**：
 
-**注意**：hotfix/tweak 豁免测试矩阵与 `tasks.md` 时**必须显式 skip 并写明理由**（`tf state set test_matrix_skipped true` + `test_matrix_skip_reason`；`tf state set tasks_skipped true` + `tasks_skip_reason`），门禁不接受无理由跳过。架构设计判断门（五项检查）**两种模式都不豁免**。
+1. hotfix/tweak 豁免测试矩阵与 `tasks.md` 时**必须显式 skip 并写明理由**（`tf state set <dir> test_matrix_skipped true` + `test_matrix_skip_reason`；`tf state set <dir> tasks_skipped true` + `tasks_skip_reason`），门禁不接受无理由跳过。
+2. **架构设计判断门（五项检查）两种模式都不豁免**，tweak/hotfix 同样要过 architecture-design 子代理（通常结论是 skip）。
+3. **tweak 仍要完成一次 DP-4**：它的 `approved-for-build→executing` 挂着 `dp-gate-passed`，该维度要求 `dp_4_result` 非空，而这个字段只能由 `tf execution plan --confirm` 写入（前置是 `tf execution recommend`）。轻的是**逐 wave 审查**，不是决策点本身。
 
 ### 4.3 决策点（DP）——什么时候需要你拍板
 
@@ -176,13 +192,18 @@ workflow-start 在初始化时自动推断（`tf runtime infer`），你也可
 | DP-1 | 需求探索结束 | scope / non-goals / 成功标准 |
 | DP-A | 架构设计产出后 | 架构三件套是否接受（可选调整，调整回原子代理修改） |
 | DP-2 | 四件规划制品完成 | proposal/specs/design/tasks 评审批准 |
-| DP-3 | 执行契约生成后 | **硬门禁**：契约批准。没有你的批准记录，任何实施都不被允许 |
-| DP-4 | 执行模式选择 | `tf execution recommend` 展示证据后，你选 SDD/Inline/Batch Inline |
+| DP-3 | 执行契约生成后 | **硬门禁**：契约批准。取值须以 `approved` 开头，否则 `bridging→approved-for-build` 转换被拒 |
+| DP-4 | 执行模式选择 | `tf execution recommend` 展示证据后，你选 `inline` / `batch-inline` / `sdd` / `glaf4-delegation` 四种之一 |
 | DP-5 | 调试受阻 | 3+ 次修复失败 → 升级为架构问题的判断确认 |
 | DP-6 | 收尾验证 | 验证结论 pass/conditional/fail |
 | DP-7 | 归档 | 确认归档（系统会核验 DP-0~DP-6 全部齐备） |
 
-产品级编排还有 G1-G5 五个团队同步点（`tf publish` 推送阶段产物），每次都会问你：推送 / 仅提交 / 暂不同步。
+**除了 DP，还有两类阻塞确认点**：
+
+- **Step 5c Code Landing**（收尾验证内，早于 DP-6）：worktree 代码是否合并回主分支——A 现在合并 / B 暂不合并 / C 无需合并。
+- **G1-G5 团队同步点**（`tf publish` 推送阶段产物）：每次问你 推送 / 仅提交 / 暂不同步。G1（PRD）/ G2（ARCH）/ G3（S4 拆分）在产品级编排；**G4 在变更级 workflow-start（DP-3 之后）**，**G5 在 release-archivist 收尾**。
+
+**确认点可以合并**（v0.50.0 起，减少交互轮次而非门禁强度）：DP-0 + DP-A、DP-3 + G4 + DP-4、DP-7 + Code Landing + G5 三组，在条件满足时可各合并成一次 AskUserQuestion；合并后 `dp_0_confirmed` / `dp_a_result` / `dp_3_result` / `dp_4_result` 等字段仍照常落盘。
 
 ### 4.4 核心产物清单
 
@@ -211,56 +232,91 @@ workflow-start 在初始化时自动推断（`tf runtime infer`），你也可
 tf runtime guard check <change-dir> <from-state> <to-state> [--workflow full|hotfix|tweak]
 ```
 
-关键门禁与应对（完整清单见 [9. FAQ](#9-faq-与排障)）：
+**full 模式的完整转换矩阵**（19 个维度 + 1 个 workflow 限制维度）：
+
+| 转换 | 维度 |
+|------|------|
+| exploring→specifying | arch-design、arch-readiness |
+| specifying→bridging | artifacts-exist、schema-valid |
+| bridging→approved-for-build | artifacts-exist、schema-valid、contract-fresh、dp-gate-passed、dp3-approved |
+| approved-for-build→executing | artifacts-exist、contract-fresh、dp-gate-passed、execution-plan-ready、test-matrix-ready |
+| **executing→closing** | **10 维**：tasks-complete、tests-passing、specs-merged、execution-plan-ready、execution-reviews-passed、compound-captured、test-matrix-complete、arch-snapshot、delegation-status、arch-merged |
+| executing↔debugging | debugging 入口无门禁；回 executing 挂 contract-fresh、execution-plan-ready |
+| exploring→bridging / exploring→approved-for-build | 0 维，但**一一对应**：`exploring→bridging` 仅 hotfix 可走、`exploring→approved-for-build` 仅 tweak 可走；full 走或其他组合都直接 FAIL |
+| 7 条回退 + 6 条放弃 | 0 维（回退是合法操作，不需要门禁放行） |
+
+高频阻断与应对：
 
 | 门禁 | 拦在哪 | 常见原因与出路 |
 |------|--------|---------------|
-| contract-fresh | bridging→approved-for-build 等 | 规划制品改了没重建契约 → 回 contract-builder 重生成 |
-| dp-gate-passed | approved-for-build→executing | DP-3/DP-4 没记录 → 完成对应决策 |
-| test-matrix-ready | approved-for-build→executing | 契约缺 Test Matrix 段或 test-matrix.md 为空 → 回 bridging 生成，或显式 skip+理由 |
-| tests-passing | executing→closing | 只认 `tf test record` 的程序化证据 → 跑测试并记录 |
-| execution-reviews-passed | executing→closing | 有 wave 缺 pass 审查回执 → 补审查 |
-| compound-captured | executing→closing | 缺 learnings.md → `tf solutions capture` 或显式 skip |
+| contract-fresh / contract-current | bridging→approved-for-build 等 | 规划制品改了没重建契约 → 回 contract-builder 重生成，或 `tf state rebuild` 后重生成 |
+| dp-gate-passed | bridging→approved（要 dp_3）/ approved→executing（要 dp_4） | DP-3/DP-4 没记录 → 完成对应决策 |
+| dp3-approved | bridging→approved-for-build | `dp_3_result` 不以 `approved` 开头（HOLD、pending 等值都会被拒） |
+| execution-plan-ready | approved→executing、executing→closing | 执行计划缺失或 hash/revision 与当前不一致 → 重跑 `tf execution recommend` + `plan --confirm` |
+| test-matrix-ready / complete | approved→executing / executing→closing | 契约缺 Test Matrix 段或 test-matrix.md 为空 → 回 bridging 生成，或显式 skip+理由 |
+| tasks-complete | executing→closing | tasks.md 有未勾选项 → 回写勾选；hotfix/tweak 可显式 skip+理由（full 不允许） |
+| tests-passing | executing→closing | 只认 `tf test record` 的程序化证据（`recorded-by=tf-test-record` + 证据文件存在 + `failed=0` + `total>0`） |
+| specs-merged | executing→closing | 有 delta specs 但没合并 → 跑 `tf sync <change-dir>`（无 delta 即天然放行） |
+| execution-reviews-passed | executing→closing | 有 wave 缺 pass 审查回执 → 补审查（回执 base≠head 且 base 是 head 祖先） |
+| compound-captured | executing→closing | 缺 `learnings.md`（change 根目录，非空）→ 写它，或 `tf state set <dir> compound_skipped true` |
 | arch-snapshot | executing→closing | 产品级架构快照缺失 → 补快照或物化 SKIPPED 标记 |
 | arch-merged | executing→closing | 架构增量未回写全局台账 → **先跑 `tf arch-merge <change-dir>` 再转换**（v0.53.0 B' 时序）；确无增量可回写时 `tf state set <dir> arch_merge_skipped true` + `arch_merge_skip_reason` |
+| delegation-status | executing→closing | 非 glaf4-delegation 模式直接 PASS；该模式须 `delegation_status=success` |
+| artifacts-exist / schema-valid | specifying→bridging 起 | 四件套缺失或 Validator 不通过（SHALL/MUST、Scenario、跨段冲突） |
 
-**设计哲学**：门禁硬，但每条都有逃生舱——存量豁免（字段缺失即视为老 change）、显式 skip+理由、`--force`/`--acknowledge-*` 参数。豁免一律留痕，可审计。
+**设计哲学**：门禁硬，但**可豁免的维度都有留痕出口，不可豁免的维度只能改产物**——这点要分清，不要以为万事都能绕：
+
+- **可豁免**（显式登记，可审计）：`schema_version` 缺失（= 存量 change）、`arch_baseline` 缺失（= 存量项目，WARN 放行）、`test_matrix_skipped`+理由、`tasks_skipped`+理由（**仅 hotfix/tweak**）、`compound_skipped`、`arch_merge_skipped`+理由、`arch_design_decision=skipped`、`iterations/vN/SKIPPED` 物化。
+- **不可豁免**（判据不满足即 FAIL，无 skip 键）：`dp3-approved`、`dp-gate-passed`、`artifacts-exist`、`schema-valid`、`contract-fresh`/`contract-current`、`execution-plan-ready`、`execution-reviews-passed`、`delegation-status`。这些只能靠补产物/补决策通过。
+- `--force` 与 `--acknowledge-recommendation` **不是 guard 门禁的逃生舱**——前者属 `tf isolate` / `tf deisolate --merge`，后者属 `tf execution plan`（选了非推荐模式时的确认）。
 
 ### 4.6 复利闭环——change 关闭时自动发生什么
 
 closing 阶段 release-archivist 会按**固定顺序**执行回写链（v0.53.0 起**状态转换插在 arch-merge 之后**——`executing→closing` 挂 `arch-merged` 门禁，未回写则转换被拒）：
 
 ```
-tf arch-merge（架构增量 → docs/architecture/ 全局当前态）
-  → tf state transition closing（状态转换；受 arch-merged 门禁校验）
-  → tf prototype-sync（UX 增量 → 全局 prototype/）
-  → tf test-merge（测试矩阵 → docs/test-ledger/ 全局台账）
-  → tf solutions promote（learnings.md 经验 → docs/solutions/）
-  → tf deisolate --merge（worktree 代码合并回主分支，Step 5c Code Landing）
+① tf arch-merge（架构增量 → docs/architecture/ 全局当前态）
+② tf state transition closing（状态转换；受 arch-merged 门禁校验）
+③ tf prototype-sync（UX 增量 → 全局 prototype/）
+④ tf test-merge（测试矩阵 → docs/test-ledger/ 全局台账）
+⑤ tf solutions promote（learnings.md 经验 → docs/solutions/）
+⑥ 设计系统待办检查（只读 .team-flow/design-system/pending.md，写进 closing summary）
 ```
 
+> **代码合并不在这条链上**：`tf deisolate --merge` 属收尾验证的 **Step 5c Code Landing**——在回写链**之前**执行，且是阻塞确认点（现在合并 / 暂不合并 / 无需合并）。
+
 这就是"改动不烂尾、知识不流失"的机制保障。经验沉淀后，下一个 change 的对应阶段会通过 `tf solutions inject` 自动注入相关经验（默认 top-5；调用点须显式传 `--limit`，否则 cross-phase 条目满载时本阶段新增条目永不可达）。
 
 ---
 
 ## 5. 场景实战
 
-### 5.1 场景一：既有项目首次接入（一次性）
+### 5.1 场景一：项目首次接入（一次性）
+
+**适用**：项目已有代码，第一次用 team-flow。
 
-**适用**：项目已有代码，第一次用 team-flow。全新空项目跳过本节直接看 5.2。
+**如果工作空间还是空的**（没有代码服务、没有技术栈特征），先走服务初始化：
+```
+在 Claude Code 中：
+> /team-flow:project-initialize
+```
+它会引导你选架构形态（glaf4 体系 / 前端分离 / 单体微服务 / 拆分）、确认服务命名、创建服务子目录，再委托对应的初始化骨架（glaf4 走 glaf4-dev 的 PROJECT_INITIALIZE，非 glaf4 则回到下面的 bootstrap 全新项目路径）。
 
+**已有代码库**则直接接入：
 ```
 在 Claude Code 中：
 > /team-flow:workflow-bootstrap
 ```
 
-流程（B1→B5）：
-1. **B1 代码侦察**：确定性脚本 + 并行子代理分析代码库，产出 `docs/architecture/baseline.md`（核心基线）
-2. **B1.5 conventions 生成**：按技术栈（java/js/python）生成项目规范到 `.team-flow/conventions/`
-3. **B2 架构基线文档化**：ARCHITECTURE.md / DATABASE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md（≥5 模块或 ≥10 文件才执行；优先导入你已有的 DDL/物理模型/Swagger 成果物）
+流程（B1 → B1.5 → B2 → B3 → B4 → B4.5 → B4.6 → B5）：
+1. **B1 代码侦察**：确定性脚本 + 并行子代理分析代码库，产出 `docs/architecture/baseline.md`（**As-Is 叙述的唯一载体**）
+2. **B1.5 conventions 生成**：按技术栈（java/js/python）生成项目规范到 `.team-flow/conventions/`；全新项目在此做交互式技术栈选择 + 可选骨架生成
+3. **B2 架构基线文档化**（≥5 模块或 ≥10 文件才执行）：经 `tf arch scaffold` 建全局台账空骨架，再把你的成果物并入——**DDL 进 `schema-baseline.sql`，物理模型和 Swagger 端点清单并入 `baseline.md`**。注意 `DATABASE.md` / `PHYSICAL-MODEL.md` / `API-INDEX.md` / `INDEX.md` 四个文件是 `tf arch-merge` 无条件重建的**生成式制品，B2 不写它们**（手写的会在首次 merge 时被整体覆盖，知识就丢了）
 4. **B3 领域词汇提取**：从代码命名提取术语到 `docs/architecture/CONCEPTS.md`
-5. **B4 目录初始化**：requirement/ 、prototype/ 、docs/ 、changes/
-6. **B5 路径判断**：问你接下来去哪（进 orchestrator / 头脑风暴 / 仅建基线等）
+5. **B4 目录初始化**：`requirement/ prototype/ docs/architecture/ docs/solutions/ changes/`
+6. **B4.5 项目 CLAUDE.md 初始化**：生成/更新项目级开发约定
+7. **B4.6 设计系统起点选择**（advisory，不阻断）：检测到项目没有设计系统时，问你六选一（模板库导入 / 逆向建库 / 从零创建 / 移植同类 / 通用起点 / 从规范文档导入）或跳过
+8. **B5 路径判断**：分两组问你——**地基组**（A 逆向重建完整架构 / B 交叉验证 bootstrap 产物 / C 真实性核对）与**进流程组**（D 具体功能需求 → orchestrator / E 模糊产品方向 → ce-brainstorm / F 仅建基线）
 
 **你要做的**：回答它的问题；有现成的架构文档/DDL/Swagger 就喂给它（比 AI 推断准确得多）。
 
@@ -274,16 +330,19 @@ tf arch-merge（架构增量 → docs/architecture/ 全局当前态）
 > 我想给订单系统加一个批量导出功能，支持异步任务和邮件通知
 ```
 
-编排器会带你走 S1→S5（每步都会等你确认）：
+编排器会带你走 S1 → S2 → ARCH → S3 → S4 → S5（每步都会等你确认）：
 
 | 阶段 | 发生什么 | 你要做什么 |
 |------|---------|-----------|
-| S1 路径路由 | 读 registry.yaml，判断入口路径（全新/续版/重新计划…），注入基线+复利经验 | 确认路由（路由是建议，你可以改） |
-| S2 PRD+原型 | ce-brainstorm 产出 `requirement/vN/prd.md` 草稿 → PRD 完整性自动评审 → 原型循环（产出→自动评审≤3轮） | 回答澄清问题；审 PRD；审原型（美观/体验只有你能判）；确认后冻结 |
-| S3 计划 | ce-plan 产出 `requirement/vN/plan.md`：change 拆分 + 依赖 DAG + 技术方向 | 审计划；发现 PRD 问题会回退 S2 |
-| ARCH 产品级架构 | architecture-design product 模式 8 步设计，产出 `docs/architecture/iterations/vN/architecture.md` 快照，自动评审 PASS 才放行 | 审架构（skip 也要物化 SKIPPED 标记） |
+| S1 路径路由 | 读 registry.yaml，判断入口路径（全新/续版/重新计划…），确认项目模式（single/monorepo/multi-repo，写 `repo_layout`），注入基线 + 复利经验 | 确认路由与项目模式（路由是建议，你可以改） |
+| S2 PRD+原型 | ce-brainstorm 产出 `requirement/vN/prd.md` 草稿 → PRD 完整性自动评审（含 §8.4 契约级细节维度）→ 原型循环（产出→自动评审≤3轮） | 回答澄清问题；审 PRD；审原型（美观/体验只有你能判）；确认后冻结 |
+| **ARCH 产品级架构** | architecture-design product 模式 8 步设计，产出 `docs/architecture/iterations/vN/architecture.md` 快照，产品级评审门 PASS 才放行 | 审架构（skip 也要物化 SKIPPED 标记） |
+| **Pre-check 服务初始化检测** | 从架构快照的注册表提取本次涉及的服务，检查服务子目录与技术栈特征是否就绪 | 缺服务 → 按引导跑 project-initialize；已存在但没拉取 → git pull |
+| S3 计划 | ce-plan 产出 `requirement/vN/plan.md`：change 拆分 + 依赖 DAG + 技术方向（**基于 ARCH 定稿**） | 审计划；发现 PRD 问题会回退 S2 |
 | S4 拆分分发 | change-split-auditor 审计拆分质量（PASS 硬前置）→ 创建 `changes/v{N}-C{n}-{name}/` 脚手架 + change-brief.md | 确认拆分结果 |
-| S5 监控 | 多 change 并行时跟踪进度、跨 change 冲突检测 | 按提示进入各 change 执行 |
+| S5 监控 | 多 change 并行时跟踪进度、跨 change 冲突检测（**change ≥ 2 时必选**） | 按提示进入各 change 执行 |
+
+> **ARCH 排在 S3 之前**（2026-08-19 起的顺序）：S3 的计划与 S4 的拆分是**最终任务拆分**，必须基于架构定稿——先有架构再拆任务，避免拆完发现架构支撑不了。
 
 **然后**：对每个 change 进目录走 5.3（执行顺序按 DAG，如 C1 →（C2∥C3）→ C4）。
 
@@ -306,14 +365,21 @@ workflow-start 会自动：
 
 ```
 需求模糊？ → need-explorer 交互式澄清（DP-1）
-  → architecture-design 五项检查（涉及架构变更才做三件套，否则 skip；自动审查+DP-A）
+  → architecture-design 五项检查（涉及架构变更才做三件套，否则 skip；自动审查 + DP-A）
   → spec-writer 产出四件套（proposal/specs/design/tasks，逐个确认后 DP-2）
-  → contract-builder 产出契约+测试矩阵（DP-3 批准，硬门禁）
-  → tf execution recommend → 你选执行模式 → tf execution plan --confirm（DP-4）
+  → contract-builder 产出契约 + 测试矩阵
+  → Pre-check 服务缺漏检测（workflow-start 路由前触发；缺服务 → 引导 project-initialize）
+  → DP-3 批准契约（硬门禁）+ G4 团队同步 + DP-4 执行模式（三点可合并为一次确认）
+  → tf execution recommend → tf execution plan --confirm
+       （四选一：inline / batch-inline / sdd / glaf4-delegation）
   → tf isolate（worktree 隔离，保护 main）
   → build-executor 逐 wave TDD 实施（RED→GREEN→REFACTOR）
   → 每个 wave 完成 → code-reviewer 审查 → findings 修复 → re-review
-  → 全部 wave pass → release-archivist 收尾验证（DP-6/DP-7）→ 回写链 → closing
+  → 全部 wave pass → release-archivist 收尾验证：
+       ├─ Step 5b E2E 验证（矩阵含 E2E 用例时触发）
+       ├─ Step 5c Code Landing（阻塞确认：合并 / 暂不合并 / 无需合并）
+       └─ DP-6 验证结论 → DP-7 归档（DP-7 + Code Landing + G5 可合并）
+  → 回写链（arch-merge → transition → prototype-sync → test-merge → promote → DS 待办检查）→ closing
 ```
 
 **关键纪律**（工作流会引导，你知道原理更好配合）：
@@ -324,20 +390,28 @@ workflow-start 会自动：
 
 ### 5.4 场景四：hotfix 与 tweak（快速路径）
 
-**hotfix**（紧急 bug，≤2 任务 ≤2 文件不动 schema/API）：
+**hotfix**（紧急 bug：≤2 任务 ≤2 文件，不动 schema/API、不新增模块）：
+
 ```
 workflow-start 自动识别为 hotfix
-→ exploring 直接跳 bridging（跳过需求探索和四件套）
-→ 最小契约仍要 DP-3 批准 → 实施 → tests-passing 仍要程序化证据 → closing
+→ exploring 直接跳 bridging（跳过需求探索；proposal.md / design.md / specs/ 可省）
+→ 最小契约仍要 DP-3 批准（bridge→approved-for-build 挂 contract-current + dp3-approved）
+→ 进 executing 仍要 execution-plan-ready（即 DP-4 的执行计划）
+→ 实施 → closing 仍考 6 维：tasks-complete、tests-passing、specs-merged、
+   execution-plan-ready、execution-reviews-passed、compound-captured
 ```
 
-**tweak**（纯配置/文案小调整，≤4 任务）：
+**tweak**（≤4 任务、纯配置/文档类文件，不动 schema/API、不新增模块）：
+
 ```
 workflow-start 自动识别为 tweak
-→ exploring 直接跳 approved-for-build → 直接编辑 → 收尾（豁免执行计划与逐 wave 审查）
+→ exploring 一步跳到 approved-for-build（0 维门禁，比 hotfix 还快）
+→ 直接编辑 → closing 只考 3 维：tasks-complete、tests-passing、specs-merged
 ```
 
-两者都：**架构五项检查不豁免**（通常结果是 skip，但检查会跑）；测试矩阵豁免必须显式 skip+理由。
+> **tweak 的"轻"在出口，不在入口**（实测）：它的 `approved-for-build→executing` 挂着 `artifacts-exist` + `contract-fresh` + `dp-gate-passed` 三项——即使编排层不派 spec-writer / contract-builder，转换时**仍要求** proposal/design/tasks/specs 与 `execution-contract.md` 存在且 hash 一致，并完成一次 DP-4。从零新建的 tweak change 会卡在这一步。
+
+两者共同点：**架构五项检查不豁免**（通常结论是 skip，但检查会跑）；测试矩阵/tasks.md 豁免必须显式 skip + 理由（`tasks_skipped` 在 full 模式下会被直接拒绝）。
 
 ### 5.5 场景五：会话中断了怎么办
 
@@ -365,8 +439,9 @@ cd changes/<name>
 | 改了规划制品后刷新 hash | `tf state rebuild <change-dir>` |
 | 转换状态 | `tf state transition <change-dir> <to-state>`（门禁自动执行） |
 | 预检门禁 | `tf runtime guard check <change-dir> <from> <to>` |
-| 记录测试结果（closing 必需） | `tf test record <change-dir> --from <runner输出文件>`（支持 maven-surefire/jest/pytest，可 auto 识别） |
-| 隔离工作区 | `tf isolate <change-dir>`（建 worktree；失败无 --force 会 STOP 要求人工处理） |
+| 记录测试结果（closing 必需） | `tf test record <change-dir> --from <runner输出文件或目录>`（支持 maven-surefire/jest/pytest，可 auto 识别；jest 须 `--json` 输出） |
+| 探测多仓库结构 | `tf repo-layout detect <项目根>`（识别 single/monorepo/multi-repo 并写入 `repo_layout` 配置） |
+| 隔离工作区 | `tf isolate <change-dir> [change-name]`（建 worktree；失败无 --force 会 STOP 要求人工处理） |
 | 收尾合并代码 | `tf deisolate <change-dir> --merge`（dirty 会阻断；merge commit 不 rebase） |
 | 沉淀一条经验 | `tf solutions capture --phase <p> --domain <d> --type <t> --severity <s> --summary "..."` |
 | 生成决策点审计报告 | `tf audit <change-dir>` |
@@ -386,56 +461,86 @@ tf doctor                              # 环境体检
 tf state init <dir>                    # 创建 change 状态（打戳 schema_version，计算三 hash）
 tf state check <dir>                   # artifacts_hash 一致性检查
 tf state get <dir> <field>             # 读字段
-tf state set <dir> <field> <value>     # 写白名单字段（dp_N_*、arch_design_*、skip 类等）
+tf state set <dir> <field> <value>     # 写白名单字段（41 个：dp_N_result/timestamp、arch_design_*、
+                                       # dp_a_*、skip 类、delegation_* 等）
 tf state rebuild <dir>                 # 重算三 hash（改完规划制品必跑）
 tf state transition <dir> <to-state>   # 状态转换（自动执行 guard 门禁）
 tf audit <dir>                         # 生成 decision-point-audit.md
 ```
 
-**不可手工 set 的字段**（CLI 有专用报错引导）：`state`（用 transition）、`test_result`（用 `tf test record`）、`schema_version`（仅 init 打戳的存量豁免键）。
+**字段可写性分三类**：
+
+- **白名单内可 set**（41 个）：`dp_{0,1,2,3,5,6,7}_result` 及其 `_timestamp`、`dp_0_decisions`/`dp_0_confirmed`、`dp_a_*`、`arch_design_*`、`arch_review_*`、`delegation_*`、`dp_4_glaf4_mode`/`dp_4_write_set_hash`、`compound_skipped`、`test_matrix_skipped(+reason)`、`tasks_skipped(+reason)`、`arch_merge_skipped(+reason)`、`workflow`、`batches_completed`、`spec_merged`。
+- **不可 set，但有专用报错引导**（3 个）：`state`（改走 `tf state transition`）、`test_result`（改走 `tf test record`）、`schema_version`（仅 `tf state init` 打戳，是存量豁免键）。
+- **其余一律不可 set**（通用报错 `Field '<x>' is not settable`）：包括 `artifacts_hash`/`contract_hash`/`test_matrix_hash`、`execution_mode`、**`dp_4_result`**（这个最容易误以为可设——它只能由 `tf execution plan --confirm` 程序化写入）。
 
 ### 执行计划
 ```bash
-tf execution recommend <dir>           # 证据驱动的执行模式推荐（DP-4 前置）
-tf execution plan <dir> --mode <m> --confirm --reason "..." --wave ...
+tf execution recommend <dir>           # 证据驱动的执行模式推荐（DP-4 前置，必须先跑）
+tf execution plan <dir> --mode <m> --confirm --reason "..." \
+    --wave <id>:<strategy>:<task,...>[:<depends-on,...>]   # strategy = parallel|serial
+    [--acknowledge-recommendation]     # 选了非推荐模式时必须加；跟随推荐却加了也会报错
 tf execution show <dir> [--json]       # 查看当前计划（current:true 才能开工）
-tf execution revise <dir> --mode sdd   # 修订计划（只能升级/重规划，不能降级）
-tf execution review <dir> --wave <id> --base <sha> --head <sha> --report <path> --verdict pass|fail
+tf execution revise <dir> --mode sdd --confirm --reason "..." --wave ...
+                                       # 修订计划（只能升级/重规划，不能降级）
+tf execution review <dir> --wave <id> --base <sha> --head <sha> \
+    --report <path> --verdict pass|fail [--repo <path>] \
+    [--tests-total N --tests-passed N --tests-failed N]
+                                       # --report 必须落在 <dir>/.superpowers/sdd/reviews/ 内；
+                                       # base 必须 ≠ head 且是 head 的祖先
 tf execution refresh-hash <dir>        # 不 bump revision 刷新 plan 内 hash
 ```
 
+> `recommend` 与 `plan` 是**强耦合**的一对：两次的 `--wave` 集合必须逐字一致，中间 artifacts_hash / contract_hash / workflow 任一变化即失效，需重跑 `recommend`。
+
 ### 测试与收尾
 ```bash
-tf test record <dir> --from <output> [--runner auto|maven-surefire|jest|pytest]
-tf test-merge <dir> [--dry-run]        # 测试矩阵 → docs/test-ledger/
-tf test-matrix-export <in.json> <out.md>   # glaf4 矩阵格式桥接
-tf sync <dir>                          # delta specs 语义合并进主 spec 基（ADDED/MODIFIED/REMOVED/RENAMED；幂等 + fail-closed，自动写 spec_merged）
-tf arch-merge <dir> [--dry-run]        # 架构增量 → docs/architecture/
-tf prototype-sync <dir>                # UX 增量 → 全局 prototype/
-tf publish --prd|--arch|--changes <dir>|--all [--push] [--dry-run]
+tf test record <dir> --from <output|dir> [--runner auto|maven-surefire|jest|pytest]
+tf test-merge <dir> [--project-root <path>] [--dry-run]   # 测试矩阵 → docs/test-ledger/
+tf test-matrix-export <in.json> <out.md> [--change-id <id>] [--batch-id <id>]   # glaf4 矩阵桥接
+tf glaf4-evidence-export <run-dir> <out-file> [--mode <m>]  # glaf4 run 证据 → surefire 行，喂给 test record
+tf sync <dir>                          # delta specs 语义合并进主 spec 基（ADDED/MODIFIED/REMOVED/RENAMED；
+                                       # 幂等 + fail-closed，自动写 spec_merged；主基不存在时走拷贝）
+tf arch-merge <dir> [--project-root <path>] [--dry-run]   # 架构增量 → docs/architecture/
+tf prototype-sync <dir> [--source <ux-delta>] [--prototype-dir <path>]
+tf publish --prd|--arch|--changes <dir>|--all [--project-root <path>] [--push] [--dry-run]
 ```
 
 ### 隔离与恢复
 ```bash
-tf isolate <change-dir> [--force]      # worktree 隔离（build 前置）
+tf isolate <change-dir> [change-name] [--force]      # worktree 隔离（build 前置）
 tf deisolate <change-dir> [--merge] [--clean] [--force] [--json]
-tf checkpoint save|list|show           # 任务级恢复点
+tf checkpoint save|list|show           # 任务级恢复点（save 须 --task <id> --next <text>）
 tf handoff create|list|finish|resolve  # prototype/research/experiment 交接单
+                                       # create 须 --type --objective --expected-output --acceptance
+                                       # resolve 须 --decision accept|reject|defer
 tf prototype branch <prd-vN> | tf prototype deisolate <prd-vN> [--merge]
 ```
 
 ### 复利与架构
 ```bash
-tf solutions capture|index-gen|inject|promote
+tf solutions capture|index-gen|inject|promote|backfill
+                                       # backfill [--dry-run]：为存量条目补 title: 字段（检索依赖）
 tf arch init [--mode reconstruction|design]   # 项目架构基线打戳（存量豁免键）
 tf arch scaffold                              # 全局台账脚手架（目标格式空基线，v0.53.0 §102）
 tf arch show
 tf arch precheck <change-dir> [--json]        # 架构判断门证据（signal none/weak/strong，退出码恒 0）
-tf inject <dir> [--platforms claude,cursor,...]   # 按当前状态生成 phase-guard 注入各平台
-tf config [--resolve-model <profile>]          # mechanical/standard/strong/review 四档
+tf inject <dir> [--platforms claude,cursor,copilot,gemini|all]   # 按当前状态生成 phase-guard 注入（可逗号多选）
+tf config [--get <path>] [--set <path>=<value>] [--resolve-model <profile>]   # 四档 model profile
 tf runtime check-update | infer <dir> | guard ... | config ... | asset read <path>
 ```
 
+### 多仓库 / glaf4 委托 / 版本
+```bash
+tf repo-layout detect <root> [--json]  # 探测 single/monorepo/multi-repo + 代码仓库清单
+tf glaf4-delegation detect|confirm|verify-write-set|verify-tasks|record-partial|reset
+                                       # GLAF4 生产+测试委托协议（写集边界校验、状态位）
+tf version <semver> [--dry-run]        # 版本号同步到全部 manifest 与文本文件
+tf install-cursor | install-workbuddy | install-cline | install-kiro | install-windsurf |
+   install-qwen | install-amazon-q | install-roocode | install-continue | install-pi |
+   install-qoder | install-zcode       # 各平台部署（12 个）
+```
+
 ---
 
 ## 8. 产物目录全景
@@ -448,32 +553,43 @@ tf runtime check-update | infer <dir> | guard ... | config ... | asset read <pat
 │   ├── handoffs/                      # session-handoff 交接文档（gitignore）
 │   ├── feedback/                      # workflow-feedback 问题记录
 │   ├── conventions/                   # 项目规范（bootstrap 生成，按技术栈）
-│   ├── design-system/                 # 设计系统（base.md + b-end/c-end 变体 + preview.html）
+│   ├── design-system/                 # 设计系统（base 品牌层 + 端变体 + 派生件）
+│   │   ├── base.md                    # 品牌共享层（组件契约表权威真源）
+│   │   ├── <port>-end.md              # 端变体（b-end / c-end…）；主题变体在 variants/
+│   │   ├── primer.md                  # AI primer：组件白名单 + token 速查 + 硬规则（生成物）
+│   │   ├── preview.html               # 预览画廊
+│   │   ├── pending.md                 # 设计系统迭代待办（closing 只读检查）
+│   │   └── showcase/                  # 展示板（可选）
 │   ├── arch-state.json                # 架构基线打戳（tf arch init，存量豁免键）
-│   └── team-flow.config.json          # 项目配置（v0.26+ 迁入 .team-flow/ 规划中）
+│   └── team-flow.config.json          # 项目配置（查找第一优先；仓库根的旧位置仅作 legacy 回退）
 │
 ├── requirement/vN/                    # 产品级需求制品（vN = PRD 迭代版本）
 │   ├── prd.md                         # PRD（frontmatter 冻结态是单一真相源）
 │   ├── plan.md                        # 实施计划（change 拆分+DAG+技术方向，无接口清单）
+│   ├── detail-ledger.md               # 功能细节澄清台账（§8.4 契约级，v0.47.0）
 │   ├── business-analysis.md           # 业务场景/流程分析
+│   ├── dialogue-log.md                # 澄清过程记录
 │   ├── prd-completeness-review.md     # PRD 完整性自动评审报告
 │   ├── prototype-auto-review.md       # 原型自动评审报告
 │   └── change-split-audit.md          # 拆分质量审计报告
 │
 ├── prototype/                         # 全局唯一原型（独立 git 仓库，按 PRD 版本分支）
-│   ├── index.html / pages/ / components/ / assets/
-│   ├── design-tokens.css / design-system.md / flow.md
+│   ├── index.html / pages/ / components /
+│   ├── assets/design-tokens.css + design-tokens.js
+│   └── flow.md
+│   （设计系统不在此目录——权威位置是 .team-flow/design-system/）
 │
 ├── docs/
 │   ├── architecture/                  # L1 全局架构当前态（arch-merge 回写，权威）
 │   │   ├── ARCHITECTURE.md            # marker 区 = 所有已合并 change 增量的投影
 │   │   ├── DATABASE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md
+│   │   │                              # ↑ 生成式制品，由 arch-merge 重建，勿手写
 │   │   ├── CONCEPTS.md                # 领域词汇表
-│   │   ├── baseline.md                # bootstrap 产出的项目基线画像
+│   │   ├── baseline.md                # bootstrap 产出的项目基线画像（As-Is 叙述唯一载体）
 │   │   ├── changelog/                 # DDL/migration 归档
 │   │   └── iterations/vN/architecture.md   # L3 迭代快照（预测态，收尾标 archived）
-│   ├── solutions/                     # 复利经验库（INDEX.md ≤150 条 + 分阶段目录）
-│   └── test-ledger/                   # 全局测试台账（test-merge 回写）
+│   ├── solutions/                     # 复利经验库（INDEX.md ≤150 条 + 按 phase 分子目录）
+│   └── test-ledger/                   # 全局测试台账（test-merge 回写；含 baselines/、changelog/、INDEX.md）
 │
 ├── specs/<capability>/spec.md         # 主 spec 基（spec-merger 合并 delta 的目标）
 │
@@ -486,8 +602,9 @@ tf runtime check-update | infer <dir> | guard ... | config ... | asset read <pat
 │   ├── execution-contract.md          # 执行契约（contract_hash）
 │   ├── test-matrix.md                 # 测试矩阵（12 列，test_matrix_hash）
 │   ├── learnings.md                   # 复利经验（closing 门禁要求或显式 skip）
-│   └── .superpowers/                  # 运行时 overlay（审查报告已迁至 sdd/reviews/）
-│       ├── sdd/                       # execution-plan.json / reviews/ / checkpoints / progress.md
+│   └── .superpowers/                  # 运行时 overlay（审查报告落在 sdd/reviews/）
+│       ├── sdd/                       # execution-plan.json / execution-recommendation.json /
+│       │                              # reviews/<waveId>.json / checkpoints / handoffs/ / progress.md
 │       └── test-evidence/             # tf test record 的 runner 原始输出证据
 │
 ├── .worktrees/                        # worktree 隔离区（tf isolate 创建，gitignore）
@@ -503,7 +620,7 @@ tf runtime check-update | infer <dir> | guard ... | config ... | asset read <pat
 
 ### Q1：门禁 BLOCK 了我，怎么看原因、怎么解？
 
-转换失败时 CLI 会逐条打印 `[dimension] failure` 及具体原因。也可预检：
+转换失败时 CLI 会逐条打印 `[FAIL] <dimension>: <failure>` 及具体原因。也可预检：
 
 ```bash
 tf runtime guard check <change-dir> <from> <to> --json
@@ -515,15 +632,15 @@ tf runtime guard check <change-dir> <from> <to> --json
 |---------|------|------|
 | `execution-contract.md is stale: artifacts hash mismatch` | 规划制品改了，契约没重建 | 回 bridging 重跑 contract-builder，或 `tf state rebuild` 后重新生成 |
 | `no programmatic test evidence recorded` | 没有 `tf test record` 记录 | 跑测试 → `tf test record <dir> --from <输出文件>` |
-| `recorded-by` 校验失败 | 手工写了 test_result | 手工通道已关闭，必须走 tf test record；或显式 skip+理由 |
-| `test matrix skip reason missing` | skip 了矩阵没写理由 | `tf state set test_matrix_skip_reason "<理由>"` |
-| `tasks skip reason missing` | skip 了 tasks.md 没写理由 | `tf state set tasks_skip_reason "<理由>"` |
+| `test_result must be recorded by 'tf test record'` | 手工写了 test_result | 手工通道已关闭，必须走 tf test record；或显式 skip+理由 |
+| `test_matrix_skipped=true requires test_matrix_skip_reason` | skip 了矩阵没写理由 | `tf state set <dir> test_matrix_skip_reason "<理由>"` |
+| `tasks_skipped=true requires tasks_skip_reason` | skip 了 tasks.md 没写理由 | `tf state set <dir> tasks_skip_reason "<理由>"` |
 | `tasks_skipped is only valid for hotfix/tweak` | full/auto 路径置了 skip 键 | 产出 tasks.md，或 `tf state set <dir> workflow <hotfix\|tweak>` 先声明模式 |
-| `dp_3_result` / `dp_4_result` 缺失 | DP 决策未记录 | 回到对应决策点完成确认 |
+| `DP-3 ... is not recorded` / `DP-4 (dp_4_result) is not recorded` | DP 决策未记录 | 回到对应决策点完成确认；**dp_4_result 只能由 `tf execution plan --confirm` 写** |
 | `plan revision <N>` 不匹配 | DP-4 记录没引用当前计划版本 | 重新 `tf execution plan`（或 revise） |
-| `base == head` review 被拒 | 空 diff 审查 | 用真实的 wave 起止 commit |
+| `Review receipt base must differ from head` | 空 diff 审查 | 用真实的 wave 起止 commit（base 须是 head 的祖先） |
 | `Unknown transition` | 非法状态转换对 | 状态机闭合，按合法路径走（如需放弃用 →abandoned） |
-| hook block："implementation editing is limited to build states" | 非 build 态在 change 目录外写实施代码 | 推进工作流到 approved-for-build/executing/debugging；change 目录内制品写永远放行 |
+| hook block：`implementation edits ... OUTSIDE the change directory are blocked while the change is in state '<state>'` | 非 build 态在 change 目录外写实施代码 | 推进到 approved-for-build/executing/debugging；change 目录内制品写永远放行 |
 
 ### Q2：存量 change / 老项目会被新门禁卡死吗？
 
@@ -533,13 +650,20 @@ tf runtime guard check <change-dir> <from> <to> --json
 
 ### Q3：我真的要跳过某个门禁怎么办？
 
-每条门禁都有合法逃生舱，但**必须显式+留痕**：
+**不是每条门禁都有逃生舱**，分两类：
+
+**可豁免**（显式登记，留痕可审计）：
 - 测试矩阵：`test_matrix_skipped=true` + `test_matrix_skip_reason`
 - tasks.md：`tasks_skipped=true` + `tasks_skip_reason`（**仅 hotfix/tweak**；full/auto 置键会被 `tasks-complete` 直接 FAIL——先 `tf state set <dir> workflow <hotfix|tweak>` 声明模式，或产出 tasks.md）
-- 复利：`tf state set compound_skipped true`
-- 架构 skip：物化 `iterations/vN/SKIPPED` 标记 + 理由
-- 隔离失败：`--force`（会警告）
-- 偏离执行推荐：`--acknowledge-recommendation`
+- 复利：`tf state set <dir> compound_skipped true`（不要求理由）
+- 架构增量回写：`arch_merge_skipped=true` + `arch_merge_skip_reason`（确无增量可回写时）
+- change 级架构判断门：`arch_design_decision=skipped` + `arch_design_reason`（由 architecture-design 子代理写）
+- 产品级架构阶段：物化 `iterations/vN/SKIPPED` 标记 + 理由
+- 存量豁免：`schema_version` 缺失（= 老 change）、`arch_baseline` 缺失（= 老项目，WARN 不 FAIL）
+
+**不可豁免**（只能补产物 / 补决策）：`dp3-approved`、`dp-gate-passed`、`artifacts-exist`、`schema-valid`、`contract-fresh` / `contract-current`、`execution-plan-ready`、`execution-reviews-passed`、`delegation-status`。
+
+> `--force`（属 `tf isolate` / `tf deisolate --merge`）与 `--acknowledge-recommendation`（属 `tf execution plan`）**不是 guard 门禁的逃生舱**，别混为一谈。
 
 不要用手工编辑 `.team-flow.yaml` 的方式绕——writeState 会拒绝非法值，hook 永远拦截该文件。
 
@@ -588,7 +712,7 @@ tf runtime guard check <change-dir> <from> <to> --json
 2. ⛔ 非 build 态写实施代码（Claude Code 硬拦；其他平台靠自觉+转换门禁兜底）
 3. ⛔ 绕过 DP-3 开始实施（无契约批准 = 非法开工）
 4. ⛔ 手工伪造 test_result（通道已关闭，只认 tf test record）
-5. ⛔ 主代理直接改子代理的产物（违反 Artifact Ownership，修改要经 SendMessage 回原子代理）
+5. ⛔ 主代理直接改子代理的产物（违反 Artifact Ownership；v0.39.0 起更严：主代理不得直接 Edit/Write `changes/<name>/` 或 `.worktrees/` 下**任何**文件，改动一律经 SendMessage 回原子代理）
 6. ⛔ 用 rebase 合并收尾代码（规范是 merge commit，保真实历史可回退）
 7. ⛔ 空 diff 记 review receipt（base==head 被 CLI 拒绝）
 
@@ -599,13 +723,19 @@ tf runtime guard check <change-dir> <from> <to> --json
 | 平台 | 安装方式 | SessionStart 注入 | 硬拦截（PreToolUse） | 门禁生效形式 |
 |------|---------|------------------|---------------------|-------------|
 | Claude Code | Marketplace / plugin.json | ✅ | ✅ | hook + guard + 规则 |
+| GitHub Copilot CLI | Marketplace | ✅ | ❌ | SessionStart + copilot-instructions |
 | Cursor | 一键脚本 | ✅ | ❌ | SessionStart + phase-guard.mdc |
 | Codex CLI/App | 插件目录 / release tag | ❌ | ❌ | phase-guard 规则 |
 | Gemini CLI | gemini-extension.json | ❌ | ❌ | GEMINI.md marker 注入 |
 | OpenCode | JS plugin | ❌ | ❌ | bootstrap 注入 |
+| WorkBuddy | `tf install-workbuddy` | ❌ | ❌ | rules/phase-guard.md |
+| ZCODE | `tf install-zcode` | ❌ | ❌ | `.zcode/rules/` |
+| Trae IDE / TRAE Work | `.trae/skills` / zip / marketplace | ❌ | ❌ | 无 rules 目录 |
 | Cline/Kiro/Windsurf/Qwen/Amazon-Q/Roo/Continue/Pi/Qoder | `tf install-<平台>` | ❌ | ❌ | phase-guard 规则文件 |
 
-> 所有平台的 skills/agents/CLI 能力一致，差异只在守卫强度。非 Claude Code 平台建议：关键状态转换后手动 `tf inject <change-dir>` 刷新 phase-guard 规则文件。
+> 所有平台的 skills/agents/CLI 能力一致，差异只在守卫强度。共 **19 个平台**——上表末行含 Cline、Kiro、Windsurf、Qwen、Amazon Q、Roo、Continue、Pi、Qoder 九个；`Codex CLI` 与 `Codex App` 是两个独立平台（同一行）；Trae IDE 与 TRAE Work 计一个。
+>
+> **关于 `tf inject`**：它只支持 `claude,cursor,copilot,gemini` 四个平台（可用逗号一次传多个，或 `all`；其余平台传参会报 `Unsupported platform(s)`）。这四家在关键状态转换后可手动 `tf inject <change-dir>` 刷新规则；**其他平台的 phase-guard 规则是安装时静态写入的**（不含当前 state），状态纪律靠每次会话让 agent 读 `.team-flow.yaml`。
 
 ---
 
@@ -622,4 +752,4 @@ tf runtime guard check <change-dir> <from> <to> --json
 
 ---
 
-*本文档基于 v0.44.0 源码全量分析产出。发现与实际行为不符，请 `/team-flow:workflow-feedback` 反馈——这正是本插件的演进方式。*
+*本文档基于 v0.60.0 源码全量核对产出（2026-09-13 同步）。发现与实际行为不符，请 `/team-flow:workflow-feedback` 反馈——这正是本插件的演进方式。*

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) + business-analysis (independent requirement/scenario artifact) + jarvis (team-flow decision agent, opt-in). 28 skills, one install.",
-  "version": "0.60.0",
+  "version": "0.61.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.60.0: auto-sync CLI version with plugin version
+# v0.61.0: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.60.0"
+PLUGIN_VERSION="0.61.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.60.0.
+Current version: v0.61.0.
 
 ## 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.60.0",
+  "version": "0.61.0",
   "description": "Unified plugin (28 skills + 17 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback, business-analysis 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.60.0",
+  "version": "0.61.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) + business-analysis (independent requirement/scenario artifact) + design-system (design tokens + component contract + AI primer + showcase) + test-strategy (test strategy design) + project-initialize (new service onboarding) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
   "author": {
     "name": "LT"

package/scripts/check-version-consistency.mjs

@@ -73,7 +73,7 @@ const TEXT_CHECKS = [
   { file: 'GEMINI.md',              extract: /# team-flow v(\d+\.\d+\.\d+) \|/ },
   // v0.59.0：新增 usage-guide 版本锚点（此前不在扫描面内，0.58.0 与 0.59.0 两次发版均靠人工改；
   // P3-15 ② 半项闭合——**检出**已覆盖，本段仍无 --fix 分支，自动修复待做）
-  { file: 'docs/usage-guide.md',    extract: /版本锚点：v(\d+\.\d+\.\d+)/ },
+  { file: 'docs/team-flow 使用说明（研发团队版）.md',    extract: /版本锚点：v(\d+\.\d+\.\d+)/ },
 ];
 
 for (const check of TEXT_CHECKS) {
@@ -165,7 +165,7 @@ for (const check of SKILL_COUNT_JSON_CHECKS) {
 const SKILL_COUNT_TEXT_CHECKS = [
   { file: 'README.md', extract: /(\d+) skills/, replace: (content, count) => content.replace(/(\d+) skills/, `${count} skills`) },
   { file: 'AGENTS.md', extract: /Skills 索引（(\d+) 个）/, replace: (content, count) => content.replace(/Skills 索引（(\d+) 个）/, `Skills 索引（${count} 个）`) },
-  { file: 'docs/usage-guide.md', extract: /(\d+) 个 skills/, replace: (content, count) => content.replace(/(\d+) 个 skills/, `${count} 个 skills`) },
+  { file: 'docs/team-flow 使用说明（研发团队版）.md', extract: /(\d+) 个 skills/, replace: (content, count) => content.replace(/(\d+) 个 skills/, `${count} 个 skills`) },
   { file: 'docs/platform-matrix.md', extract: /(\d+) 个 skill 部署/, replace: (content, count) => content.replace(/(\d+) 个 skill 部署/, `${count} 个 skill 部署`) },
   { file: 'INSTALL.md', extract: /应有 (\d+) 个 skill 目录/, replace: (content, count) => content.replace(/(\d+) 个 skill 目录/g, `${count} 个 skill 目录`) },
   { file: 'INSTALL.md', extract: /包含 (\d+) 个 skill、/, replace: (content, count) => content.replace(/(\d+) 个 skill、/, `${count} 个 skill、`) },

package/skills/bug-investigator/SKILL.md

@@ -92,6 +92,14 @@ Write the investigation report with this structure:
 - **Mechanism:** [How the bug works, step by step]
 - **Evidence:** [What proves this is the cause]
 
+## 源 Change 关联（v0.61.0 新增，设计依据 v0.26 §203）
+
+- **是否匹配到源 change**：是 / 否
+- **源 change 目录**：`<changes/<name>/>`（若匹配到；否则填「独立缺陷 / 新文件，无源 change」）
+- **匹配方式**：`git blame` 受影响文件/符号 → 引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查；或全局 `specs/` 按 capability 检索
+- **复用约束**：修复时复用源 change 的 `design.md` / `specs/` / `tests` 作为已知设计约束，避免偏离原设计意图；若源 change 已 closing，仅在本 bugfix change 内复用上下文，**不重开**源 change
+- **用户确认**：匹配结果须由用户确认；失准时本段填「匹配失败，按独立缺陷处理」
+
 ## Recommended Fix
 [Suggested approach — describe what to change and why, but do NOT implement it]
 - **Fix location:** [where to change]

package/skills/ce-plan/references/change-splitting.md

@@ -17,6 +17,18 @@ Break the work into logical **changes** (team-flow change units). Each change re
 - 一个内聚功能模块（如"下单""权限体系"）通常对应一个所有权单元 → 通常 = 一个 change
 - 但"一个用户故事"不等于"一个 change"的充要条件——若多个故事共享同一所有权单元（如看板多视角共享同一读模型），它们应合为一个 change
 
+## 拆分默认姿态（粗粒度优先，v0.60.x 新增）
+
+**默认不拆细。** 把一个迭代版本的工作拆成 change 时，优先合并为少量**粗粒度** change（按所有权单元计）。只有在以下三条中**至少一条成立**时，才向下拆细：
+
+1. **越过所有权边界**：子块对应不同的聚合 / 限界上下文 / 读模型 / 契约所有权，必须各自独立做架构增量设计（即 D5 判据要求拆）。
+2. **需要独立并行验证**：子块可被不同人/不同时间独立实现并验证，合在一起反而难测。
+3. **团队领取需要**：协作分发时，必须拆开才能分给不同成员认领。
+
+**"拆太细"的代价**：每个 change 都要走完整 8 态 + 4+1 产物 + 架构增量设计 + 复利回写——当 change 细到单接口/单文件/单方法时，这些仪式开销远大于改动本身价值。`change-split-auditor` D3 会主动提示合并候选（见该 agent D3），但**仅为建议、不硬拦**（与 D5「切碎所有权」的硬 FAIL 不同级）。
+
+> 一句话：**宁粗勿细。拆细是例外，不拆是默认。**
+
 ## Good Changes
 
 **根因判据**：每个 change 的 scope 必须对应**一个所有权自包含的架构设计单元**——持有不被其它 change 分享的聚合/上下文/读模型/契约所有权，且该设计能在本 change 内闭合。

package/skills/workflow-orchestrator/SKILL.md

@@ -23,6 +23,18 @@ description: >-
 
 **设计哲学（v0.7）**：编排层**只编排**（状态判断、路由、阶段转换、用户确认），执行委托 subagent/会话 skill；从「固定管道」升级为「默认路径 + 任意时刻可重规划」；PRD vN = 一次迭代版本，迭代内变更不升版。
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认，含 S1 路径路由、S4 同步门禁）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（续版需求 / 重新计划 / 单 change 快速通道 / 聚合 / 限界上下文 等）下沉到 description，首次出现括注白话等价。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（走哪条路径 / 是否同步），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语。
+
+反例：S1 直接问 `单 change 快速通道 / 续版需求 / 重新计划` 不解释区别。
+正例：S1 问 `你这步想做什么？`；A「从头做新功能（推荐）」B「在已有版本上加功能」C「只调一下计划」——各自 desc 说明选了会怎样。
+
 ## Use This Skill When
 
 - 用户提出新的产品级需求：「我有个想法」「做一个 XX 功能」「从头开始」、模糊需求

package/skills/workflow-orchestrator/references/s1-path-router.md

@@ -24,7 +24,13 @@ S1 只做编排动作（需求选择、存在性检查、路径判断、阻塞
 | **重新计划** | PRD 已冻结，plan 需调整 | → S3 | 跳过 brainstorm；S3 完成后进 ARCH（产品级架构设计，v0.35.0）再拆 change |
 | **继续执行** | changes 已拆分，继续下一个 | → S4/S5 | 先输出状态恢复简报，用户确认后继续 |
 | **单 change 快速通道** | 需求极清晰，无需 PRD（仅限单一功能点、无 UI、无跨模块依赖的极小变更） | → 直接创建 change → workflow-start | 最轻量路径，无 PRD 锚点，**不可触发 S3→S2 回退** |
-| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 直接创建 change（type: hotfix，注入 bug 描述替代 PRD）→ workflow-start | closing 时强制补录复利 |
+| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 匹配源 change（见下「Hotfix 命中源 change」）→ 直接创建 change（type: hotfix，注入 bug 描述替代 PRD，带源 change 引用）→ workflow-start | closing 时强制补录复利 |
+
+**Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：用户报 bug / 线上问题时，先尝试把缺陷回溯到引入它的源 change，再做轻量修复：
+1. **匹配**：`git blame` 受影响文件 / 符号 → 定位引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查 `change_dir`；或按受影响 capability 在全局 `specs/` 检索归属 change。
+2. **命中** → 新建 hotfix change 时携带「源 change 引用」（写 `change-brief.md` 的 `source_change_ref`，无 brief 则记 `learnings.md`），workflow-start 路由时复用源 change 的 `design.md` / `specs` / `tests` 上下文做轻量修复，省去重复 scope 确认。
+3. **非命中**（独立缺陷 / 新文件）→ 走原 Hotfix，无源 change 引用。
+4. **必须用户确认匹配结果**；失准优雅降级 Hotfix，**绝不静默自动 reopen** 源 change。
 | **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做/重跑原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4） | PRD 不动，保留有效 S3 plan / S4 changes，闭环后恢复原 phase；`replan_log` 记往返 |
 
 **判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `requirement/` 目录（有 PRD → 「续版」候选；legacy: `prd/`），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。

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

@@ -87,6 +87,7 @@ upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_arch_ref: docs/architecture/iterations/vN/architecture.md  # 产品级架构快照（v0.36.3）；ARCH skip 或 hotfix 为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
+source_change_ref: <change-dir>         # 可选：本 change 是对某已存在 change 缺陷的快速修复（v0.61.0 bugfix 增强，设计依据 v0.26 §203）；非 bugfix 留空
 ---
 # Change Brief: <change-name>
 

package/skills/workflow-start/SKILL.md

@@ -26,6 +26,18 @@ Do NOT invoke for: general coding tasks outside team-flow changes, casual questi
 3. **Overlay recovery scan**: Run `tf handoff list <change-dir> --json` and `tf checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `tf handoff resolve` before resuming the affected work. An `active` handoff is non-blocking side work. Show a non-stale checkpoint as recovery context; show a stale checkpoint only as historical evidence.
 4. **Execution-control recovery scan**: For `approved-for-build`, `executing`, `debugging`, or `closing`, run `tf execution show <change-dir> --json`. Treat only `current: true` plus `waves[].eligible: true` as permission to start a wave; report plan revision, mode, next eligible wave, and every wave's receipt/blockers. A missing, invalid, or stale plan blocks implementation and routes to `build-executor`; do not infer progress from chat history.
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（SDD / Inline / 聚合 / 限界上下文 / CQRS 等）下沉到 description，且首次出现括注白话等价（如 `聚合（一组相关的业务数据，比如一张订单及其明细）`）。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（范围 / 优先级 / 方向），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语；需要精确术语时在 description 内保留。
+
+反例：DP-4 label `执行模式选择：SDD / Inline / Batch Inline`。
+正例：DP-4 label `怎么推进这批改动？`；A「稳妥分批（推荐）」desc `每批带测试、可回退，最稳`；B「一口气写完」desc `快但出错难定位`；C「内联小改」desc `改动极小时用（术语 SDD=……）`。
+
 ## DP-0: User Confirmation Gate
 
 Run DP-0 when: change folder doesn't exist, planning artifacts missing/empty, or `dp_0_confirmed` ≠ `true`. Skip if `dp_0_confirmed` is `true`.
@@ -184,6 +196,7 @@ work.
 **不合并**：`arch_design_decision == required` 时 DP-A 必须独立——用户需单独审架构产物。
 
 - **Hotfix**: Route to contract-builder (minimal), skip need-explorer + spec-writer, guard check `exploring bridging --workflow hotfix`, then `bridging -> approved-for-build`, after DP-3 → build-executor (recommend, show, and confirm an execution mode), after → release-archivist (lightweight). Hotfix may skip `proposal.md`, `design.md`, and `specs/`, but it still requires a fresh minimal `execution-contract.md`, DP-3 approval, and a current execution plan before build. **`tasks.md` 不得静默缺失（v0.22 §85）**：hotfix 默认不产出该文件，但必须由 contract-builder 显式登记 `tasks_skipped=true` + `tasks_skip_reason`（或一并产出最小任务清单，归属 contract-builder）——`tasks-complete` 在 closing 考核该维度，静默缺失会死锁（修复前即此状态）。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门，快速判定是否涉及架构变更（hotfix 可能正是架构缺陷导致）
+- **Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：若 S1 已匹配到引入该缺陷的源 change（`source_change_ref`），本 change 路由时**复用源 change 的 `design.md` / `specs/` / `tests` 作为已知设计约束上下文**，省去重复 scope 确认——修复只针对缺陷点，不重做整体设计。消费方式：读取 `change-brief.md` 的 `source_change_ref`（或 `learnings.md` 记录）指向的源 change 目录，将其 design/specs 作为背景注入 contract-builder / build-executor。**门禁**：源 change 匹配结果由 S1 阶段用户确认；本层**绝不静默 reopen** 源 change，仅在本 hotfix change 内复用其上下文。匹配失准时退化为普通 Hotfix。
 - **Tweak**: Route to build-executor (direct edit), skip need-explorer + spec-writer + contract-builder, guard check `exploring approved-for-build --workflow tweak`, after → release-archivist (lightweight). **`tasks.md` 须显式 skip（v0.22 §85）**：tweak 跳过 spec-writer 与 contract-builder，故既无原生 `tasks.md` 也无人代写——由**主代理**经 `tf state set` 写入 `tasks_skipped=true` + `tasks_skip_reason`（`tf state set` 是 CLI 调用，不违反 Artifact Ownership 的 Edit/Write 禁令），否则 `tasks-complete` 在 closing 死锁。tweak 的 `executing:closing` 不含 `test-matrix-complete`（`guard.mjs:82`），矩阵豁免非 guard 必需。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门
 
 Post-transition: 💡 `tf inject <change-dir>` to update phase-guard artifacts.