@xulthekl/team-flow 0.56.1 → 0.58.0

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

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

package/.claude-plugin/marketplace.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "description": "Unified workflow plugin: team-flow + compound-engineering core subset + architecture-design + prototype + workflow-orchestrator + workflow-bootstrap + e2e + session-handoff + workflow-feedback + business-analysis. 26 skills + 17 agents, one install.",
+  "description": "Unified workflow plugin: team-flow + compound-engineering core subset + architecture-design + prototype + workflow-orchestrator + workflow-bootstrap + e2e + session-handoff + workflow-feedback + business-analysis. 27 skills + 17 agents, one install.",
   "owner": {
     "name": "LT",
     "url": "https://github.com/LT"
@@ -8,8 +8,8 @@
   "plugins": [
     {
       "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. 26 skills + 17 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.56.1",
+      "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. 27 skills + 17 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
+      "version": "0.58.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

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

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.56.1",
+  "version": "0.58.0",
   "description": "Spec-first workflow that bridges OpenSpec-style planning and Superpowers-style execution discipline.",
   "author": {
     "name": "MageByte",
@@ -26,7 +26,7 @@
   "interface": {
     "displayName": "team-flow",
     "shortDescription": "Spec-first workflow with guarded execution.",
-    "longDescription": "A self-contained Codex workflow plugin with 26 skills for intent exploration, planning artifacts, execution contracts, TDD execution, review gates, systematic debugging, closure, delta spec sync, and independent business analysis.",
+    "longDescription": "A self-contained Codex workflow plugin with 27 skills for intent exploration, planning artifacts, execution contracts, TDD execution, review gates, systematic debugging, closure, delta spec sync, and independent business analysis.",
     "developerName": "MageByte",
     "category": "Developer Tools",
     "composerIcon": "./assets/icon.svg",

package/.cursor-plugin/marketplace.json

@@ -5,13 +5,13 @@
   },
   "metadata": {
     "description": "Unified workflow plugin marketplace for Cursor (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.56.1"
+    "version": "0.58.0"
   },
   "plugins": [
     {
       "name": "team-flow",
       "source": ".",
-      "description": "Unified workflow plugin: team-flow + compound-engineering core subset + architecture-design + prototype + business-analysis. 26 skills + 17 agents."
+      "description": "Unified workflow plugin: team-flow + compound-engineering core subset + architecture-design + prototype + business-analysis. 27 skills + 17 agents."
     }
   ]
 }

package/.cursor-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "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). 26 skills + 17 agents, one install.",
-  "version": "0.56.1",
+  "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact). 27 skills + 17 agents, one install.",
+  "version": "0.58.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.56.1"
+    "version": "0.58.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.56.1",
+      "version": "0.58.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**（既有项目接入）。一次安装，七套能力协同（26 skills + 17 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**（既有项目接入）。一次安装，十二套能力协同（27 skills + 17 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`），包含 26 个 skills + 17 个 agents + hooks + templates
+- **team-flow**（本插件）：Claude Code / Cursor 等宿主的插件实体（`plugin.json` name = `team-flow`），包含 27 个 skills + 17 个 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
@@ -33,11 +33,11 @@ node --test tests/e2e.test.mjs --test-name-pattern="parseDeltaSpec"
 npm run validate
 ```
 
-## 能力概览（十套合一，26 skills）
+## 能力概览（十二套合一，27 skills）
 
-### 1. team-flow（底座，9 skills）
+### 1. team-flow（底座，11 skills）
 spec 驱动开发过程。8 态变更机：`exploring → specifying → bridging → approved-for-build → executing → closing`（另有 `debugging` 侧路径 + `abandoned` 终态）。
-- `workflow-start` 启动 / `need-explorer` 需求探索 / `spec-writer` 写 spec / `contract-builder` 构建执行契约 / `build-executor` TDD 实现 / `code-reviewer` 代码审查 / `spec-merger` 合并 delta spec / `release-archivist` 发布归档 / `bug-investigator` bug 调查
+- `workflow-start` 启动 / `need-explorer` 需求探索 / `spec-writer` 写 spec / `contract-builder` 构建执行契约 / `build-executor` TDD 实现 / `code-reviewer` 代码审查 / `spec-merger` 合并 delta spec / `release-archivist` 发布归档 / `bug-investigator` bug 调查 / `test-strategy` 测试设计方法论（预加载）/ `clean-code` 代码结构质量判据（预加载，v0.58.0）
 
 ### 2. compound-engineering 核心子集（6 skills，全局复利）
 - `ce-brainstorm` 需求头脑风暴 / `ce-plan` PRD 规划 / `ce-compound` 全局复利回写 / `ce-strategy` 策略锚点(`STRATEGY.md`) / `ce-ideate` 设计创意 / `ce-proof` 验证证明
@@ -90,6 +90,16 @@ spec 驱动开发过程。8 态变更机：`exploring → specifying → bridgin
 - 支持多轮单问澄清、待办记录、新增/更新模式，写入前必须阻塞用户确认
 - 不进入核心工作流，作为独立外挂工具运行
 
+### 11. design-system（1 skill，项目级设计系统，v0.19.0）
+- 设计系统独立创建与维护，产出落 `.team-flow/design-system/`（base 品牌共享层 + B端/C端变体 + primer + 预览画廊）
+- 三条创建入口：交互式（LLM 推荐 + 用户确认）/ 内置模板库导入（registry.json 参考库）/ 从既有代码逆向建库（create-from-code）
+- 支持独立调用或 prototype skill 内部编排调用
+
+### 12. project-initialize（1 skill，项目初始化引导，v0.45.0）
+- 工作空间代码服务为空时触发：识别需初始化 → 引导架构选择（glaf4 体系 / 前端分离 / 单体微服务 / 拆分）→ 服务命名确认 → 创建服务子目录 → 委托初始化骨架
+- glaf4 体系走 glaf4-dev 的 PROJECT_INITIALIZE 模式；非 glaf4 走内置引导（B1.5 骨架生成）
+- 由 ARCH 后 Pre-check 服务初始化检测触发（缺失时引导接入）
+
 ## 全局产物结构（Discoverability —— 设计/开发前先检索）
 
 ```
@@ -109,9 +119,9 @@ prototype/             全局原型系统（UI 契约真相源）：index.html /
 docs/
   ├── architecture/    全局架构三层（v0.36.0）：L1 当前态（ARCHITECTURE.md marker 区 / PHYSICAL-MODEL.md / DATABASE.md / API-INDEX.md / INDEX.md / domains/<bc>.md / diagrams/ / schema-baseline.sql / baseline.md）+ L2 changelog/ + L3 iterations/vN/architecture.md（产品级快照，archived 退役）
   └── solutions/       复利经验库（v0.5 新增，三层索引）
-      ├── INDEX.md     # L1 轻量索引（≤150行，每条一行摘要+标签）
+      ├── INDEX.md     # L1 轻量索引（≤150 条，每条一行摘要+标签）
       ├── prd/ plan/ architecture/ prototype/ spec/ build/ review/ cross-phase/  # L2 分阶段目录（枚举权威：scripts/lib/solutions-phases.mjs）
-      └── <file>.md    # L3 经验文件（YAML frontmatter: phase/domain/type/severity）
+      └── <file>.md    # L3 经验文件（YAML frontmatter: phase/domain/type/severity/date/source/title/confirmations）
 changes/<name>/        变更脚手架（S4 创建）：.team-flow.yaml（变更级状态文件）/ change-brief.md（产品级交接物，含 upstream_arch_ref）/ proposal.md / design.md / tasks.md / execution-contract.md / learnings.md（变更级经验台账）/ architecture/（变更级三件套 + sql/）
 specs/<cap>/            每变更规格：spec.md（v0.49.0 §83.3.5：learnings.md 归 change 根，不在此目录）
 STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
@@ -134,7 +144,7 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
   产品级编排层（workflow-orchestrator，v0.7 重设计 + v0.15.0 多需求）
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   S1 路径路由器 → 需求选择（.team-flow/registry.yaml）+ 判断入口路径
-     检查 baseline.md / CONCEPTS.md → 注入上下文 + 复利注入（top-5）
+     检查 baseline.md / CONCEPTS.md → 注入上下文 + 复利注入（默认 top-5，调用点显式 `--limit`）
   S2 PRD + 原型阶段 → ce-brainstorm 产出 PRD
      冻结前 PRD 完整性评审（prd-completeness-reviewer，v0.15.0）
      原型循环由 orchestrator 直接编排（prototype skill 内部编排器，主代理只编排）：
@@ -174,7 +184,7 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
   全局作为下一 change / 下一 PRD 版本的 grounding → 闭环
 ```
 
-## Skills 索引（26 个）
+## Skills 索引（27 个）
 
 | Skill | 归属 | 用途 |
 |---|---|---|
@@ -184,6 +194,7 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
 | contract-builder | team-flow | 构建执行契约 |
 | build-executor | team-flow | TDD 实现 |
 | test-strategy | team-flow | 测试设计方法论（design_method 三级分层 + 对抗验证 + 复杂度分级，v0.12 §41） |
+| clean-code | team-flow | 代码结构质量判据（机械阈值 + 审查必答项 + 增量归因边界 + 共享层判定，v0.58.0） |
 | code-reviewer | team-flow | 代码审查 |
 | spec-merger | team-flow | 合并 delta spec |
 | release-archivist | team-flow | 发布归档 |
@@ -217,8 +228,11 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
 | 步骤级 - 独立工具 | ce-ideate, ce-strategy, ce-compound, ce-proof, architecture-design, prototype, e2e, session-handoff, workflow-feedback, **business-analysis** | 各自独特触发词 | 无冲突，可独立触发；business-analysis 不进入核心工作流 |
 | 步骤级 - 受限独立 | ce-brainstorm, ce-plan | 可独立触发，但产品级新需求应走 orchestrator | description 中标注路由指导 |
 | 步骤级 - 仅路由 | need-explorer, spec-writer, contract-builder, build-executor, code-reviewer, spec-merger, release-archivist, bug-investigator | 仅由 workflow-start 路由 | 不独立触发 |
+| 内部方法论（预加载）| test-strategy, clean-code | 无触发词——仅经 agent `skills:` 字段预加载，或由派发模板内联 | 不独立触发；判据真相源，执行处为派发模板（`user-invocable: false`）|
 
 > **规则**：新增 skill 时必须在此表登记所属层级。产品级新需求触发词归 workflow-orchestrator 独占。
+>
+> **新增 skill 的完整登记清单（v0.58.0 补，防「修复未传播」）**——需同步 **6 处**：① 本触发域分层表；② 上方**能力概览**的对应套枚举与组数；③ `README.md` 的「N 套能力」标题 + 枚举 + **首段摘要行**（"一次安装，N 套能力协同"易被遗忘，v0.58.0 实测残留 2 处）；④ 各 host manifest 的 skills 计数（`.claude-plugin/` / `.cursor-plugin/` / `.codex-plugin/` / `gemini-extension.json` / `package.json`）；⑤ `AGENTS.md` 的 Skills 索引表；⑥ 工作区 `CLAUDE.md`。`npm run check-versions --fix` **只覆盖其中一部分**（v0.58.0 实测漏 13+ 处），其余须人工核对。
 
 ### Agents 索引（v0.7 新增，v0.47.0 增至 17 个）
 
@@ -252,26 +266,32 @@ STRATEGY.md CONCEPTS.md 产品策略(BA) / 领域词汇
 
 ```
 docs/solutions/
-├── INDEX.md                  # L1：轻量索引（≤150行，每条一行摘要+标签，按 severity 降序）
+├── INDEX.md                  # L1：轻量索引（≤150 条，每条一行摘要+标签；排序 severity → date → file）
 ├── prd/ plan/ architecture/ prototype/ spec/ build/ review/ cross-phase/  # L2：分阶段目录（枚举权威：scripts/lib/solutions-phases.mjs）
-└── <date>-<summary>.md      # L3：经验文件（YAML frontmatter: phase/domain/type/severity/date/source）
+└── <date>-<slug>.md         # L3：经验文件（YAML frontmatter: phase/domain/type/severity/date/source/title/confirmations）
 ```
 
-### 四个核心动作
+### 核心动作（五）
 
 | 动作 | 触发时机 | CLI |
 |------|---------|-----|
-| **注入** | 进入每阶段时，自动加载相关经验（top-5） | `tf solutions inject --phase <p> --domain <d>` |
+| **注入** | 进入每阶段时，自动加载相关经验（默认 top-5，**调用方须显式 `--limit`**） | `tf solutions inject --phase <p> --domain <d> --limit <n>` |
 | **捕获** | 阶段转换点检测到可复利时刻 | `tf solutions capture --phase <p> --domain <d> --type <t> --severity <s> --summary "<text>"` |
 | **索引重建** | INDEX.md 损坏或手动触发 | `tf solutions index-gen` |
 | **晋升** | change closing 时，经验验证后晋升为产品级 | `tf solutions promote <change-dir>` |
+| **补字段** | 存量条目缺 `title:` 时（learnings-researcher 按它检索） | `tf solutions backfill [--dry-run]` |
+
+> **注入语义（v0.57.0）**：`--phase` 的 `cross-phase` 是**通配符**——任何 phase 查询都会一并返回它，
+> 故 `--phase prd` 在无 prd 条目的项目上注入的就是 cross-phase 那批。默认 top-5 在 cross-phase
+> 条目已达 5 条时**满载**，本阶段新增条目（低 severity）永不可达，故存在调用点时必须显式传 `--limit`。
 
 ### 关键约束
 
-- 所有复利操作为 **advisory 级**，INDEX.md 读取失败时静默跳过，不阻断流程
-- INDEX.md 硬上限 150 行，超限时按 severity 降序保留，淘汰 low + 最早条目
-- 晋升条件：severity ≥ medium 且 type = pitfall/pattern；与全局已有条目 domain+type 匹配则标记"已确认模式"并升级 severity
-- 上下文占用控制：最坏 ~6.5k token（L1 索引全量加载）
+- 所有复利操作为 **advisory 级**：INDEX 缺失/读取失败时 CLI 输出一行 WARN 并返回空结果，**不阻断流程**（v0.57.0 前为完全静默，无人可见"注入其实没发生"）
+- INDEX.md 硬上限 **150 条**（`MAX_INDEX_ENTRIES`，非行数），超限时按 **severity → date → file** 三级序保留（末键保证同日同 severity 的去留在跨机器上可复现）；被淘汰的文件保留在阶段目录中且**逐条 WARN 列出**（v0.57.0 前为静默）
+- 晋升条件：severity ≥ medium 且 type = pitfall/pattern。**命中既有条目（文件名 + 正文签名都相同）**则登记来源 change 到 `confirmations` 并按其升级 severity（`low → medium → high → critical`，新来源才升一档、重跑不升）——**不合并正文**（v0.57.0 废止 `domain+type` 合并：旧实现只把计数 +1 而丢弃正文，实测丢 13 条）。同名但正文不同的经验是**两条独立条目**，碰撞时文件名加 `-2`/`-3` 后缀
+- INDEX.md 是**派生物**，唯一写入者是 `refreshIndex()`（capture/promote 内部调用）——**禁止手工编辑 INDEX**
+- 上下文占用控制：最坏 ~6.5k token（L1 索引全量加载）；注入时**同源条目**（同 `source`）折叠为 1 条 + 标注条数，避免一次事故的多个面占满窗口
 
 ## 配置注入（插件层扩展字段）
 

package/CHANGELOG.md

@@ -4,6 +4,129 @@ All notable changes to `team-flow` will be documented in this file.
 
 The format loosely follows Keep a Changelog.
 
+## [0.58.0] - 2026-09-12
+
+### Added（clean-code 结构判据能力）
+
+设计来源：`docs/plan/clean-code-integration-design.md` **v1.3**（P1.5 标准档两轮对抗验证：第一轮 26 条 / 第二轮 18 条，收官 0 Critical；P4 三路验证——plugin-validator + skill-reviewer + 实证探针两轮）。
+
+**新增 `clean-code` skill**（第 27 个 skill，`user-invocable: false`）：代码结构质量的判据集，供 `build-executor` / `code-reviewer` 预加载。**判据三分**：① 可机械判定项（魔法值 **Critical**；函数长度 / 嵌套深度 / 参数个数 / 命名形式 **Minor**）② 审查必答项（单一职责、DRY——**不给阈值**，但必须回答并给理由）③ 沿用既有清单项（错误处理 / 边界 / YAGNI，本 skill 不涉及）。
+
+**关键设计决策**（均有实测依据）：
+
+- **不给「单一职责」设阈值**：实测反证——37 行的 `validateFrontSystemSecret`（通体卫语句、单层抽象）与 54 行的 `handleDelivery`（三卫语句 + switch）可读性均良好，任何「抽象层级计数」规则都无法在这一对同类样本上复现判定，该规则已废。
+- **判据内联、不做引用**：由模板派发的 `general-purpose` 子代理不继承 Skills，且 `scripts/lib/cmd-runtime.mjs` 的 ASSETS 白名单只含两个 build-executor 模板——三处判据**必须内联**，写成引用必然断链（子代理读不到）。
+- **增量归因边界**：只判本次 diff 触及的代码单元；存量命中一律降 Minor 并在审查报告登记「存量待整改」。
+- **判例集**：`references/judgement-cases.md` 收录 6 组真实判例（正例 `P1`/`P2`、反例 `N3`，及 `N1`/`N2`/`N4` 的例外说明），防止判据退化成新的直觉。
+
+**新增 Dim 5「同构横展完整性」**（`cross-change-consistency-checker` 4 → 5 维度）：检测本 change 处置的代码模式是否在其**全部**出现位置都已处置。**模式驱动**而非仓名驱动（实测缺口常跨同构组：4 个仓分属 `bff-emp-*` 与 `adapter-emp-*`，缺口恰在组间）；含**真空对照**（零命中须显式报告「模式未命中，需人工确认」，不得记 CLEAN）。单 change 场景的调用点补在 `workflow-start` 的 `executing → closing` 关口——此前该 agent 仅在 S5（change ≥ 2）被调度，**该场景下 Dim 5 永不触发**。
+
+### Changed（判据接线与口径统一）
+
+- 三处派发模板内联结构判据：`implementer-prompt.md`（自检）、`task-reviewer-prompt.md`、`code-reviewer-prompt.md`（含必答项输出容器 + example 演示 Critical 落位与 fail 联动）。
+- `code-reviewer/SKILL.md`：Step 3 加结构判据小节；**修正 verdict 口径矛盾**——`tf execution review --verdict` 只接受 `pass|fail`，`PASS_WITH_WARNINGS` 在二值 receipt 中无法表达，故 **Important 亦须阻断**（与三处模板一致）。此前「FAIL 仅 Critical」是四处口径中唯一的异类。
+- `agents/code-reviewer.md`：`skills:` 加 `clean-code`；verdict 段补 receipt 映射。
+- `agents/release-archivist.md`：新增 closing 时的「结构判据未覆盖」标注条件（glaf4-delegation 且契约未声明该条款时）。
+- `skills/architecture-design/templates/conventions/frontend-patterns.md`：补前端魔法值约束——此前后端有全局硬约束、**前端无任何等价约束**（实测同一 change 内 21 处前端硬编码业务码被审查降级为 Minor）。
+
+### Fixed
+
+- **源头模板 5 处裸 `references/` 引用**（`templates/conventions/js-testing.md:247`、`python-testing.md:319`、`glaf4-compliant/java-testing.md:329,342,353`）：目标文件真实存在于插件侧 `skills/test-strategy/references/`，但裸相对路径在项目内不可达。P3 横展检查发现——原计划只修下游产物（emp-auth 4 处），**未修源头**会让每个新接入项目继承同一缺陷。
+- **skills 计数残留 13+ 处**：`check-versions --fix` 只覆盖 4 个文件的单一模式，宿主 manifest（`.cursor-plugin/` / `.codex-plugin/` / `gemini-extension.json`）、`package.json`、`docs/usage-guide.md`、`docs/release-checklist.md`（「9 skills」实为 27）、`AGENTS.md` 底座计数与 `README.md` 枚举均漏改。**工具缺陷已登记**（建议扩展扫描面，或改为从 `skills/` 目录动态派生真值后全仓比对）。
+- 既有登记缺口补齐：`README.md` 枚举（补 `test-strategy` / `project-initialize`，修正「十套」→「十二套」，枚举合计 25 → 27）、`AGENTS.md` 能力概览（补 `design-system` / `project-initialize` 两节 + 新增「内部方法论（预加载）」分层行）。
+- `tests/lib/cmd-install-workbuddy.test.mjs`：`skillNames.length === 26` 硬编码改为健壮断言（验证从 package root 发现 skills + 含已知 skill），消除随 skill 数漂移的脆弱性——该断言并非该测试的核心意图（测试名：`uses the package root by default instead of the caller cwd`）。
+
+### Added（机械门禁）
+
+`tests/lib/doc-consistency.test.mjs` 新增 **clean-code 判据一致性门禁**：检查真相源（中文）与三处内联副本（英文）的判据锚点与**阈值锚点**（`>20 lines` / `>2 levels` / `parameters >3`）不得漂移；含正例/负例对照（含阈值漂移变异）。**首次运行即抓到一处真实漂移**——`implementer-prompt.md` 写作 `**parameter count** >3`（markdown 加粗致锚点不匹配），与另两处措辞不一致，已统一。
+
+**1209/1209 测试**（基线 1200，+9）；`npm run lint:skills` 81 issues（其中 5 errors 均为存量行数超标，`clean-code` 0 error）。
+
+## [0.57.0] - 2026-09-12
+
+### Changed（复利机制 P1 重构；**含 4 项行为变更，升级必读**）
+
+设计来源：`docs/plan/compound-lifecycle-governance-design.md` **v2.3**（P1.5 完整档**三轮**对抗验证：37 + 32 + 11 = **80 项问题全部采纳**，三轮 Critical 全闭合；P4 双门禁评审（plugin-validator + skill-reviewer）**均判 FAIL**，据此另修 **12 项**（5 Critical），见该文档附录 C.4）。
+
+**① 判重语义：废止 `domain+type` 合并（D1-B，最高影响）**
+
+旧实现命中同 `domain+type` 即"合并"，只把 `confirmed` 计数 +1 而**正文丢弃**——emp-auth 实测 **13 条内容丢失**（仅存于 change 的 `learnings.md`，其中含 2 条 critical 因旧 bug 从未晋升）。
+
+- **改为**：每条经验**独立成条**，内容零丢失；跨 change 的"复发"信号改由 `confirmations: [change-id…]` 来源集合承载
+- **幂等由「文件名 + 正文签名」保证**：同 change 重复 promote 记为 `unchanged`（旧实现每次重跑都 +1 confirmed 并升一档 severity，实测连跑 3 次即把 `medium` 推到 `critical`）
+  - ⚠️ **P4 修正**：初版仅用文件名作身份键，`cleanTitle` 剥离序号后 `## 3. 契约漂移` 与 `## 7. 契约漂移` 产出同一 slug ⇒ 第二条被判"已登记"直接跳过 ⇒ **正文与 severity 整条消失**（隔离复现证实，本版新引入的回归）。现身份 = 标题分量（**清洗后**，因序号是 change 局部编号）+ 内容分量（**不清洗**，区分同标题经验），碰撞时探测 `-2`/`-3` 后缀
+- **行为变更**：**同标题但正文不同**的经验现在各自成条（旧版会静默丢弃后一条）；同 change 重跑仍为 `unchanged`，但跨 change 的确认需"标题与正文都相同"——触发窗口比初版更窄（零丢失优先于复发信号）
+
+**② INDEX 写入权收归单一入口**
+
+旧实现有 **3 个 writer** 互相回滚：`promote` 只升 INDEX 行的 severity、`capture` 自建表头 + append、`index-gen` 从零重建（且**无任何流程调用者**）。实测：先 promote 再 index-gen 会把 `critical` **打回 `high`**（3/20 条）、`summary` 被改写（14/20 条）。
+
+- **改为**：`refreshIndex()` 为唯一写入者；`capture`/`promote` 写完条目文件后调用它（**入口内建**，不靠调用点枚举——两者各有多个落盘分支，逐处追加必然漏改）
+- `severity` 与 `confirmations` 的**真相源落条目文件 frontmatter**（唯一不被重建抹掉的持久层）
+- **否决**"重建时取 `max(旧 INDEX, 文件)`"——那会让 INDEX 成为并列真值源，把漂移固化为**不可降档**的不变量
+- 目录缺失时 `refreshIndex` **创建**而非 `exit 1`（旧 `index-gen` 会直接失败，中断首次晋升链）
+- **行为变更**：手工编辑 `INDEX.md` 会在下次捕获/晋升时被覆盖（`skills/ce-compound/references/write-flow.md` 已同步）
+
+**③ `tf test-merge` 的模块边界改为多段白名单**
+
+`extractModuleSections` 的 docstring 写「`## Cases` 下的 `###` 子段」，**实现却是全文扫描所有 `### `**。emp-auth 实测 v1-C1 的 21 个 `###` 中 **12 个是附录/台账段**（`### 执行结果（三仓实测…）`、`### Task 5.x`、`### W6-1 / W6-2 收口`），生成 440–520B 的无复用价值 baseline。
+
+- **改为**：白名单 = `## Cases` + **`## E2E / AC Verification`**（后者是 v0.38.0 引入 E2E 层级时的遗漏——只列 `## Cases` 会让 `vrm4teamflow` 的 `### AC1..AC8`（**32 个 AC/E2E 用例**）**静默冻结**：落选文件不会从 INDEX 消失，因 `rewriteIndex` 扫目录 ⇒ 既无报错也无计数变化）
+- 精确段名比较（`## Adversarial Cases` 含子串 `Cases`，用 `includes` 会误判）
+- 无白名单段时**回退全文扫描 + WARN**（旧实现静默打印 `0 modules processed`）
+- 导出 `extractModuleSections` / `MODULE_SECTIONS` 并补**真实 test-matrix 形态**测试（原 fixture 全是内联 `### Foo` 块，无法捕获本类缺陷）
+- **行为变更**：升级后新 `###` 若位于白名单段之外，**不再生成 baseline**；既有文件不受影响（不删除）
+
+**④ `tf solutions inject` 的排序与容量**
+
+- 排序补两级次级键：**阶段匹配度**（本阶段优先于通配的 `cross-phase`）→ **date 降序**（新条目优先）。旧实现仅 `severityRank` 单键，同级顺序取决于 INDEX 行序 ⇒ 旧条目永久压制新条目
+- 新增 `--limit <n>`（默认仍 5）与 `--all`；`--phase build` 与 `--phase cross-phase` 在旧实现下输出**只差表头**（cross-phase 是通配符），故 `build-executor` 改传 `--phase build` 并**删除**重复的 cross-phase 调用；`code-reviewer` 新增 `--phase review`（审查阶段此前无任何消费方）
+- **同源聚类**（P4 补实现）：同 `source` 的条目（同一次事故的多个面）折叠为 1 条 + 标注条数，把 top-N 槽位还给其他经验。仅作用于**展示**，不合并内容（与 ① 的 D1-B 一致）。INDEX 加 `source` 列（7→8，消费方对 7/8 列都容错）
+- ⚠️ **P4 修正**：初版只加了参数**没改任何调用点**（4 处全未传 `--limit`）——正是设计 §4.1 预警的"可配但没人配"。现 4 处全补 `--limit 15`，并加机械门禁断言"每个 inject 调用点必带 `--limit`/`--all`"
+- **行为变更**：同一批条目的 top-5 **内容与顺序可能变化**
+
+### Added
+
+- `tf solutions backfill [--dry-run]`：为存量条目补写 `title:` 字段（`learnings-researcher` 按 `title:`/`tags:`/`module:`/`problem_type:` grep，而 CLI 条目此前只有 `phase/domain/type/...` ⇒ 实测四模式在 emp-auth 21 条中**各只命中 1 条**）
+- `tf doctor` 新增 `Solutions` 维度（四类检查）：INDEX↔文件漂移、条目数/截断、非白名单目录与平铺文件、未 promote 的 change
+- 共享层新增 `md-normalize.parseTableRow`（**保留空列**的表格行解析）与 `solutions-index-gen.refreshIndex` / `parseFrontmatter` / `MAX_INDEX_ENTRIES`
+- `tests/lib/doc-consistency.test.mjs`（**机械门禁**）：把"同口径副本"清单固化为断言——**10 个**已废止口径短语零命中（含历史溯源行豁免）+ "每个 inject 调用点必带 `--limit`/`--all`"+ **正例/负例对照组**（防止断言退化为真空）。动因：本仓"修复未传播"已复发 4 次（v0.38.0 / v0.53.0 / v0.55.0 / v0.57.0 单次改动发现 8 处残留）
+- `scripts/lib/solutions-entry.mjs`（**共享层**）：条目身份（正文签名 + 碰撞定位）与 **frontmatter 读取**（含行尾注释剥离）的共享实现，capture / index-gen / cmd-doctor 及 promote 的 `parseLearnings` 共用；`promote.confirmByFile`（需整块替换）与 `backfill`（仅键存在性检测）为**已知例外**，理由见各自注释
+- `solutions-backfill.mjs` 与 3 个测试文件（`solutions-backfill` / `cmd-doctor-solutions` + inject/index-gen/promote/test-merge 的扩充用例）
+
+### Fixed
+
+- **列解析空列错位**：`filter(Boolean)` 丢空列且守卫只有下界 ⇒ 单元格含 `|` 时列数错位不被拦截。`inject`、`test-merge` 的 `extractCandidateLedger`/`extractDeferredItems` 改用 `parseTableRow` + 上下界校验；`promote` 的那处随判重通道整体删除（它已不再解析 INDEX）。另横展 `test-merge` 内 **4 处**仍在用的 inline 表格切分（`test-merge` 在 v0.38.0 修过同型缺陷，当时未横展到其余各处）
+- **INDEX 单元格转义**（P4）：内容含 `|` 会让该行列数膨胀 ⇒ 消费方列数校验丢弃整行 ⇒ 条目**永久隐身**，且 doctor 的修复建议（重跑 index-gen）产出同一坏行 ⇒ **死循环**。生成侧转义 `\|`、解析侧还原，并加 `file` 列语义校验兜住"列数在界内但已错位"
+- **`promote` 幂等判据塌缩**（P4，本版 ① 引入的回归）：见 ① 的 P4 修正条
+- **`refreshIndex` 排序不确定**（P4）：同日同 severity 条目在 `maxEntries` 边界的去留取决于 `readdirSync` 顺序 ⇒ 补文件名作决定性末键
+- **条目 frontmatter 值不剥行尾注释**（P4）：`severity: high # 说明` 会被当作未知值原样返回 ⇒ 该条**永不升级且无提示**
+- **`parseTableRow` 同名冲突**（P4）：本仓有 3 份同名不同语义实现（`md-normalize` 永不返回 null / `arch-parse` 与 `ds-parse` 返回 null 且做清洗）⇒ 补差异矩阵注释防止按名误挑
+- **`promote` 缺 phase 白名单校验**（`capture` 一直有）：实测接受 `phase: tools` 会建出 `docs/solutions/tools/` 并追加 INDEX 行，随后重建时该目录不被扫描 ⇒ 条目**静默消失且不计入 dropped**
+- **截断由静默改为可见**：`refreshIndex` 超 150 条时 WARN 并逐条列出被丢弃的文件（旧实现只打印一行计数）
+- **索引缺失由静默改为 WARN**：`solutions-inject` 原输出一行 HTML 注释并以 0 退出，无人可见
+- **`CONCEPTS.md` 路径**：`learnings-researcher` 只查仓库根，而 `workflow-bootstrap` B3 产出在 `docs/architecture/` ⇒ grounding 静默落空；改为两处探测
+- `MAX_INDEX_LINES` → `MAX_INDEX_ENTRIES`：该常量约束的是**条目数**（`entries.slice(0, N)`），但全仓 **15 处**文案写作"150 行"（文件另含 4 行头部，封顶时实为 154 行）
+
+### 验证
+
+- 全量测试 **1199/1199 通过**（基线 1112 项 —— 即 v0.56.1 的测试数，故 +87）
+- **变异验证**（本轮 3 项，均确认新增测试具备判别力）：
+  - 排序反向 → 「全部 critical 条目须被保留」等 3 条失败
+  - 白名单退化为「任意 `##` 段」（等价原全文扫描）→ 4 条边界用例失败，报「附录段「执行结果（三仓实测，命令 + 实际输出）」不得被当作测试模块」
+  - 去掉 `resolveBaselinePath` 的 legacy 回退 → v0.56.1 的回归用例失败
+  - **[P4]** `escapeCell` 不转义 `|` → index-gen 的管道符用例失败
+  - **[P4]** 去掉同源聚类 → inject 的聚类用例失败
+  - **[P4]** 身份键退化为单文件名（复现原缺陷）→ 「两条同标题经验都应落盘」报 `1 !== 2`
+  - **[P4]** 往 skill 注入肯定式旧口径 / 无 `--limit` 的 inject 命令 → doc-consistency 门禁精确报出行号与豁免提示
+- **P4 双门禁结论（七轮）**：每轮均由独立 agent 隔离复现；**前三轮均判 FAIL**，第四轮 reviewer PASS + validator 另报阻断，**第五~七轮 validator 均 PASS（0 阻断）**——七轮共处置 **52 项**：
+  - 第一轮（16 项，含 1 Critical）：**promote 身份键塌缩丢条**（本版新引入的回归，已隔离复现）→ 身份改为「标题分量 + 正文签名」；`--limit` 调用点落实数为 0；口径传播未闭合
+  - 第二轮（13 项，含 3 Critical）：`solutions-capture` **无碰撞保护会静默覆盖**（使 ①「内容零丢失」在 capture 通道为假）→ 抽 `solutions-entry.mjs` 共享层；frontmatter 注释剥离只落在 promote 一条读取路径；两处假闭合；门禁真空断言
+  - 第三轮（11 项，含 2 阻断）：`frontmatterBlock` 的 `(?:^|\n)` 误吞正文水平线 ⇒ **INDEX 出现幽灵条目**（本轮新引入的回归，已补反例断言）；`code-reviewer` 的注入只覆盖 agent 路径、`code-reviewer-prompt.md` 路径零处 inject（假闭合）→ 两条路径都注入 + 新增**正向存在性门禁**
+  - 第四/五轮：`frontmatterBlock` 的宽松匹配**三轮修复未触根因**（一轮放宽正则 → 二轮加防线 → 三轮加领域键校验），第四轮**换判据**（严格锚定段首）才闭合——前三轮都在"加防线"，真问题是判据查的是"块内有没有领域键"而非"该块是文件自身的 frontmatter"；第五轮 validator 判 **PASS（0 阻断）**
+  - 第五轮：validator **PASS（0 阻断）**；第六轮另报 1 项本轮引入的新失效面（`tf doctor` 的 Solutions 维度遇非普通文件抛异常 ⇒ **中止整轮巡检**，12 个维度全丢）——已把「条目枚举」抽为共享层 `listSolutionEntries`（判据 + 两层防御），三个消费方（`index-gen` / `cmd-doctor` / `backfill`）共用
+  - 逐轮闭合表见设计文档附录 **C.4 – C.10**；由此新增的机械门禁 `tests/lib/doc-consistency.test.mjs` 已含正例/负例对照组、`INJECT_CONSUMERS` 正向存在性与窗口参数断言
+
 ## [0.56.1] - 2026-09-12
 
 ### Fixed（v0.56.0 自身引入的回归 + P1.5 第一轮暴露的遗漏；**升级优先于 0.56.0**）

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

package/README.md

@@ -1,8 +1,8 @@
 # team-flow
 
-> 当前版本：`v0.56.1`
+> 当前版本：`v0.58.0`
 
-> 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同。
+> 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，十二套能力协同（详见下文「十二套能力」）。
 
 ## 30 秒上手
 
@@ -34,7 +34,7 @@
 git clone <your-repo> && <cli> plugin install ./team-flow
 ```
 
-> 不同宿主 CLI 的安装子命令略有差异（如 Claude Code 为 `/plugin add`，Cursor 为 `plugin install`）。以宿主文档为准；本插件提供单一 `plugin.json`，一次安装即加载全部 26 个 skills。
+> 不同宿主 CLI 的安装子命令略有差异（如 Claude Code 为 `/plugin add`，Cursor 为 `plugin install`）。以宿主文档为准；本插件提供单一 `plugin.json`，一次安装即加载全部 27 个 skills。
 
 ## 配置（插件层扩展字段）
 
@@ -70,9 +70,9 @@ specs/<cap>/        每变更规格：spec.md（learnings.md 归 change 根目
 STRATEGY.md CONCEPTS.md 策略 / 领域词汇
 ```
 
-## 十套能力（26 skills）
+## 十二套能力（27 skills）
 
-- **team-flow**（9）：workflow-start / need-explorer / spec-writer / contract-builder / build-executor / code-reviewer / spec-merger / release-archivist / bug-investigator
+- **team-flow**（11）：workflow-start / need-explorer / spec-writer / contract-builder / build-executor / code-reviewer / spec-merger / release-archivist / bug-investigator / test-strategy / clean-code
 - **compound 核心子集**（6）：ce-brainstorm / ce-plan / ce-compound / ce-strategy / ce-ideate / ce-proof
 - **architecture-design**（1）：architecture-design
 - **prototype**（1）：prototype
@@ -83,6 +83,7 @@ STRATEGY.md CONCEPTS.md 策略 / 领域词汇
 - **工作流反馈**（1）：workflow-feedback（工作流问题结构化记录，与 ce-compound 互补，v0.16.0）
 - **设计系统**（1）：design-system（独立创建/迭代项目级设计系统，用户主导交互，v0.19.0）
 - **业务分析**（1）：business-analysis（将任意输入整理为 requirement/vN/business-analysis.md，多轮单问澄清，独立外挂，v0.44.0）
+- **项目初始化**（1）：project-initialize（工作空间代码服务为空时的初始化引导：架构选择 → 服务命名 → 创建子目录 → 委托骨架，v0.45.0）
 
 ### 配套 agents（17 个，v0.47.0 增至 17）
 
@@ -95,8 +96,8 @@ Skills 命名保留其来源前缀，作为功能分组的自然标识：
 | 前缀 | 来源 | 含义 | Skills |
 |------|------|------|--------|
 | `ce-` | compound-engineering | 产品级思维工具（头脑风暴、计划、策略、复利、创意、验证） | ce-brainstorm, ce-plan, ce-strategy, ce-compound, ce-ideate, ce-proof |
-| 无前缀 | team-flow | 变更级开发流程工具（状态机、规格、构建、审查、归档） | workflow-start, need-explorer, spec-writer, contract-builder, build-executor, code-reviewer, spec-merger, release-archivist, bug-investigator |
-| 无前缀 | team-flow 新增 | 编排/接入/设计/原型/测试/交接/反馈 | workflow-orchestrator, workflow-bootstrap, architecture-design, prototype, e2e, session-handoff, workflow-feedback |
+| 无前缀 | team-flow | 变更级开发流程工具（状态机、规格、构建、审查、归档、内部方法论） | workflow-start, need-explorer, spec-writer, contract-builder, build-executor, code-reviewer, spec-merger, release-archivist, bug-investigator, test-strategy, clean-code |
+| 无前缀 | team-flow 新增 | 编排/接入/设计/原型/测试/交接/反馈/初始化 | workflow-orchestrator, workflow-bootstrap, architecture-design, prototype, e2e, session-handoff, workflow-feedback, design-system, project-initialize |
 
 > `ce-` 前缀来自 compound-engineering 项目，team-flow 整合时保留了这一命名以维持功能分组的可辨识性。这不是命名不一致，而是有意的来源标注。
 

package/agents/code-reviewer.md

@@ -7,6 +7,7 @@ color: blue
 tools: ["Read", "Grep", "Glob", "Bash", "Write"]
 skills:
   - code-reviewer
+  - clean-code
 ---
 
 You are an independent Code Reviewer. You review code changes for quality, spec compliance, architecture soundness, and implementation completeness. You write the review report to disk and return a summary.
@@ -48,6 +49,8 @@ Your preloaded Skill defines severity levels (Critical / Important / Minor) and
 - **PASS_WITH_WARNINGS**: No Critical, but Important findings exist
 - **PASS**: No Critical or Important findings
 
+**receipt 映射（v0.58.0）**：`tf execution review --verdict` 只接受 `pass | fail`。**PASS → `pass`**；**PASS_WITH_WARNINGS 与 FAIL 均 → `fail`** —— 即 **Important 亦须阻断**。理由：`PASS_WITH_WARNINGS` 在二值 receipt 中无法表达，且三个派发模板（`code-reviewer-prompt.md` / `task-reviewer-prompt.md`）与 `build-executor/SKILL.md` 均要求「Critical/Important findings require a `fail` receipt」。此前本节的「FAIL 仅 Critical」是四处口径中的唯一异类。
+
 ## Red Lines
 
 **DO:**

package/agents/cross-change-consistency-checker.md

@@ -1,6 +1,6 @@
 ---
 name: cross-change-consistency-checker
-description: 跨 change 冲突检测。在多 change 并行执行期或 change closing 时，检测共享聚合/实体被多个 change 修改、API 签名变更影响、与全局架构锚点漂移、与原型 testid 契约漂移。直接写冲突报告文件，返回摘要 + 文件路径。
+description: 跨 change 冲突检测。在多 change 并行执行期或 change closing 时，检测共享聚合/实体被多个 change 修改、API 签名变更影响、与全局架构锚点漂移、与原型 testid 契约漂移、以及同构横展完整性。直接写冲突报告文件，返回摘要 + 文件路径。
 
 
 model: inherit
@@ -22,10 +22,11 @@ You are a checker. You did NOT implement any change. You read all change artifac
 | `arch_path` | 全局架构目录（e.g., `docs/architecture/`，含 ARCHITECTURE.md / DATABASE.md） |
 | `product_snapshot_path` | 产品级架构快照 `docs/architecture/iterations/vN/architecture.md`（v0.36.3；聚合注册表唯一事实源，若存在） |
 | `prototype_path` | 全局原型目录（e.g., `prototype/`） |
+| `repo_layout` | 仓库布局映射（v0.58.0，Dim 5 用）。来源：`<项目根>/.team-flow/team-flow.config.json` 的 `repo_layout.repos`（key = 仓路径，value = 描述）。多仓工作区才有；缺失时 Dim 5 跳过并注明 |
 
-If `change_dirs` has fewer than 2 entries, Dim 1/2 are skipped (single change has no cross-change conflict). If `arch_path` or `prototype_path` is missing, the corresponding dimension is skipped with a note.
+If `change_dirs` has fewer than 2 entries, Dim 1/2 are skipped (single change has no cross-change conflict). If `arch_path` or `prototype_path` is missing, the corresponding dimension is skipped with a note. Dim 5 requires `repo_layout`.
 
-## 4-Dimension Detection
+## 5-Dimension Detection
 
 ### Dimension 1: Shared Aggregate/Entity Mutation
 
@@ -77,6 +78,23 @@ Use `grep` to search for API references across change specs and design docs.
    - Change adds UI elements that should have testids per prototype pattern but don't → Minor
    - testid value mismatch between prototype and implementation → Important
 
+### Dimension 5: Isomorphic Propagation Completeness (v0.58.0)
+
+**Goal**: Detect when a code pattern handled by this change is **not** handled at all of its occurrences — the failure mode where a defect fix is applied to some isomorphic locations but not others.
+
+**Why pattern-driven, not repo-name-driven**: isomorphic repos can be recognized by name similarity (longest common prefix + suffix ≥60%, e.g. `bff-emp-` + `users`/`clients` + `identification`), BUT real gaps are often **cross-group** — a v1 case had 4 isomorphic repos split across `bff-emp-*` and `adapter-emp-*`, and the gap lay *between* the groups. Group-based checking would have missed it. Scan by **pattern**, not by repo group.
+
+1. **Extract pattern features** from the change's diff: the named structural elements deleted or modified — annotation + constant reference (e.g. `@Cacheable(cacheNames = BO_SYSUSER_USERID)`), method signature, constant name. The pattern MUST contain a named symbol; generic patterns ("all `if` statements") are invalid and MUST be rejected.
+2. **Scan all repos**: `grep` over EVERY repo listed in `repo_layout.repos` (not just isomorphic groups).
+3. **Difference set**: hits NOT within this change's disposition scope = omission candidates. Cite `file:line` for each.
+4. **Reachability grading**:
+   - Omission has call sites (reachable) → **Important**
+   - Zero call sites (unreachable) → **Minor** (preventive alignment, optional)
+
+**Vacuum control (MANDATORY — prevents a vacuous assertion)**: if step 2 yields **zero hits**, do NOT silently report CLEAN. Explicitly report `模式未命中：<pattern> 在全部仓中零出现，需人工确认模式提取是否正确`. Rationale: zero hits cannot distinguish "no omission exists" from "pattern extraction failed" — calling it CLEAN would be a vacuous assertion.
+
+**Activation**: only for changes whose nature is defect-fix / rule-alignment / isomorphic sync. Pure new-feature development has no pre-existing pattern to propagate — skip Dim 5 and note the skip.
+
 ## Detection Process
 
 1. **Enumerate changes**: read each change directory's spec/design/tasks files
@@ -84,7 +102,8 @@ Use `grep` to search for API references across change specs and design docs.
 3. **Dim 2**: Extract API surface changes per change, cross-reference dependencies
 4. **Dim 3**: Read architecture anchors **+ 产品级快照聚合注册表**（`product_snapshot_path`，v0.36.3——聚合注册表是唯一事实源，跨 change 冲突检测以它为准），compare each change against them
 5. **Dim 4**: Scan prototype testids, compare against change implementations
-6. **Aggregate**: collect all findings, grade by severity, produce report
+6. **Dim 5**: Extract named pattern features from each change's diff, scan EVERY repo in `repo_layout.repos`, compute the difference set, grade by reachability — and apply the vacuum control when the scan yields zero hits
+7. **Aggregate**: collect all findings, grade by severity, produce report
 
 ## Judgment Criteria
 
@@ -141,6 +160,15 @@ Use `grep` to search for API references across change specs and design docs.
 |--------|-------------------|--------|-------|----------|
 | `order-submit-btn` | prototype/order.html:23 | change-1 | Renamed to `submit-order` | Important |
 
+## Dim 5: Isomorphic Propagation Completeness
+
+| Pattern Feature | Handled In | Omitted At | Reachable | Severity |
+|-----------------|-----------|-----------|-----------|----------|
+| `@Cacheable(cacheNames = BO_SYSUSER_USERID)` return-type mismatch | `bff-…users:47`, `bff-…clients:47` | `adapter-…users:47`, `adapter-…clients:47` | No (0 call sites) | Minor |
+
+> Vacuum control: when the repo-wide scan for a pattern yields **zero hits**, write instead —
+> `模式未命中：<pattern> 在全部仓中零出现，需人工确认模式提取是否正确`（不得记为 CLEAN）
+
 ## Conflict Summary & Suggested Resolution
 
 | # | Dim | Changes | Location | Severity | Suggested Resolution |
@@ -160,7 +188,7 @@ If no conflicts are found, output:
 ```markdown
 ## Result: CLEAN
 
-All 4 dimensions checked. No cross-change conflicts detected.
+All 5 dimensions checked. No cross-change conflicts detected.
 ```
 
 ## Red Lines
@@ -174,7 +202,7 @@ All 4 dimensions checked. No cross-change conflicts detected.
 
 **DON'T:**
 - Modify any change's files — only write the conflict report
-- Report single-change issues as cross-change conflicts (use code-reviewer for that)
+- Report single-change issues as cross-change conflicts (use code-reviewer for that) — **EXCEPTION**: a single change's **cross-repo isomorphic omission** IS in scope (Dim 5). The distinction is repo span: cross-repo → Dim 5; single-repo code quality → code-reviewer
 - Flag shared read-only references as conflicts (two changes READING the same file is fine)
 - Ignore architecture drift because "arch-merge will handle it later" — report it, let the orchestrator decide
 - Fabricate conflicts from vague similarity — require concrete file/symbol evidence

package/agents/release-archivist.md

@@ -47,6 +47,12 @@ writebacks:
 summary: "..."                       # closing summary + any WARNs needing user acceptance
 ```
 
+## Structural Criteria Coverage Note (v0.58.0)
+
+closing 时检查本 change 是否覆盖了结构判据（clean-code）：若该 change 走 `glaf4-delegation` 且 `execution-contract.md` 的 `## GLAF4 Delegation` 段**未**包含结构质量验收条款，须在 closing 报告中显式标注「本 change 结构判据未覆盖」。
+
+依据：glaf4-dev 的 `production-writer` 只按 `knowledge` 清单读取规范（`resolve-context.mjs` 无项目侧注入通道），故 clean-code 判据无法进入其实施层；审查层仍有效（`glaf4-delegation.md` 明确由 team-flow code-reviewer 审查 base..head），但若契约未声明该条款，审查者亦无据可依。
+
 ## Red Lines
 
 **DO:**

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.56.1`
+- Current: `v0.58.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/release-checklist.md

@@ -46,7 +46,7 @@ For each example in `docs/examples/`:
 - `node scripts/team-flow.mjs version <version> --dry-run` — reports all files in sync
 - `node scripts/check-version-consistency.mjs` — exits 0
 - `node scripts/team-flow.mjs --help` — all subcommands listed
-- `node scripts/team-flow.mjs install-workbuddy --dry-run` — finds all 9 skills and target paths
+- `node scripts/team-flow.mjs install-workbuddy --dry-run` — finds all 27 skills and target paths
 - `npm run test:raw-mode` — packs the current source and runs a canonical runtime in an empty directory with no plugin-root variables or global `tf`.
 - Run a representative local-installer smoke test.
 - `team-flow.config.json` absence still works (backward compatible defaults)