@xulthekl/team-flow 0.57.0 → 0.58.0

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

@@ -1,3 +1,3 @@
-# team-flow v0.57.0 | 阶段: {{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.57.0",
+      "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.57.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). 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.57.0",
+  "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.57.0"
+    "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.57.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). 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.57.0"
+    "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.57.0",
+      "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 —— 设计/开发前先检索）
 
 ```
@@ -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 个）
 

package/CHANGELOG.md

@@ -4,6 +4,44 @@ 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 项行为变更，升级必读**）

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.57.0 | 阶段: {{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.57.0**。
+当前发布版本：**v0.58.0**。
 
 ---
 

package/README.md

@@ -1,8 +1,8 @@
 # team-flow
 
-> 当前版本：`v0.57.0`
+> 当前版本：`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.57.0`
+- 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)

package/docs/usage-guide.md

@@ -1,6 +1,6 @@
 # team-flow 使用说明（研发团队版）
 
-> 版本锚点：v0.50.0（26 skills + 17 agents）· 更新日期：2026-09-09
+> 版本锚点：v0.58.0（27 skills + 17 agents）· 更新日期：2026-09-12
 > 读者：使用 team-flow 做日常研发的工程师。不需要你懂插件内部实现，只需要照着路径走。
 > 配套文档：安装细节见 [INSTALL.md](../INSTALL.md)；状态机细节见 [state-machine.md](state-machine.md)；决策点细节见 [decision-points.md](decision-points.md)；平台差异见 [platform-matrix.md](platform-matrix.md)。
 

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). 26 skills, one install.",
-  "version": "0.57.0",
+  "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). 27 skills, one install.",
+  "version": "0.58.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

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

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.57.0",
-  "description": "Unified plugin (26 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.",
+  "version": "0.58.0",
+  "description": "Unified plugin (27 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",
   "bin": {

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "team-flow",
-  "version": "0.57.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). 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.",
   "author": {
     "name": "LT"
   },

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

@@ -10,6 +10,13 @@ date: 2026-07-31
 > 本文件由 team-flow 被动式自动沉淀机制维护（v0.11 §33）。
 > 请勿手动编辑模板——此文件作为参考模板，实际项目规范在 `.team-flow/conventions/frontend-patterns.md` 中维护。
 
+## 魔法值（v0.58.0）
+
+- **数值 / 字符串字面量 MUST NOT 散落在模板与脚本中**——收敛到 `src/constants/` 下的常量模块，或组件内具名常量。
+- 判据归属：`clean-code` skill 的「魔法值（前端）」判据，分级 **Critical**（与后端「不允许魔法常量」对齐；此前前端无任何等价约束）。
+- 可豁免：结构性索引（如 `arr[0]`）、CSS 取值、仅出现一次且语义自明的字面量。
+- 背景：v1 实测中前端因无约束，同一 change 内出现 21 处硬编码业务码与状态值，被审查降级为 Minor。
+
 ## 框架选型
 - （项目级规范在此补充，如：Vue 2 Options API）
 

package/skills/build-executor/SKILL.md

@@ -72,6 +72,8 @@ RED (write test, see it fail) → GREEN (write minimal code, see it pass) → RE
 ### Law 3: Review Before Drift
 Block on: logic defects, spec violations, missing required tests, unintended scope expansion.
 
+**Structural criteria（clean-code，v0.58.0）**：魔法值（未命名字面量）= Critical；函数长度 / 嵌套深度 / 参数个数 / 命名形式 = Minor；单一职责与 DRY 为审查必答项（无阈值）。**执行处是三个派发模板**（`implementer-prompt.md` / `task-reviewer-prompt.md` / `code-reviewer-prompt.md`）——它们各自内联了完整判据，因为由模板派发的子代理读不到 skill。本摘要仅供编排参考；判据真相源见 `clean-code` skill。
+
 ### Law 4: Rewind on Contract Break
 Return to `specifying` or `bridging` if: new behavior appears, interfaces change materially, design assumptions fail, artifacts no longer define intended implementation.
 

package/skills/build-executor/implementer-prompt.md

@@ -130,6 +130,25 @@ Subagent (general-purpose):
     - Are names clear and accurate (match what things do, not how they work)?
     - Is the code clean and maintainable?
 
+    **Structural criteria** — apply to every function this change adds or modifies:
+
+    - **Magic values** (unnamed numeric/string literals): name them as constants or enums.
+      This is **Critical** — do not ship unnamed literals. Applies to front-end code too.
+    - **Function length** >20 lines, **nesting depth** >2 levels, parameters >3,
+      **naming form** (constants SCREAMING_SNAKE; booleans `is`/`has`/`can` prefix):
+      Minor. When counting nesting, exclude try/catch's own level and guard-clause
+      `return`/`continue` levels; framework-fixed signatures are exempt from the
+      parameter rule.
+    - **Single responsibility**: can the function name cover ALL steps in the body?
+      If not, split it — or state in your report which steps it cannot cover.
+    - **DRY**: is there a structurally equivalent logic block elsewhere in THIS repository
+      (ignore comments, whitespace, identifier names)? If the duplicate lives in the same
+      shared publish unit (same package / module / directory), extract a shared layer
+      rather than copying — if you judge copying is right, say why in your report.
+    - **Pre-existing code**: these criteria apply only to what this change touches. A hit
+      inside a function that already existed is Minor — register it in your report as
+      `存量待整改` rather than restructuring outside your task scope.
+
     **Discipline:**
     - Did I avoid overbuilding (YAGNI)?
     - Did I only build what was requested?

package/skills/build-executor/task-reviewer-prompt.md

@@ -100,6 +100,40 @@ Subagent (general-purpose):
     - DRY without premature abstraction?
     - Edge cases handled?
 
+    **Structural criteria (clean-code) — mechanical thresholds:**
+    - **Magic values** (unnamed numeric/string literals) → **Critical**. Front-end code too.
+    - Function length >20 lines / nesting depth >2 levels / parameters >3 / naming form
+      (constants SCREAMING_SNAKE; booleans `is`/`has`/`can` prefix) → Minor. When counting
+      nesting, exclude try/catch's own level and guard-clause `return`/`continue` levels;
+      framework-fixed signatures are exempt from the parameter rule.
+
+    **Incremental boundary — applies to ALL criteria above and below**: judge only the code
+    units this diff adds or modifies. When a hit sits inside a function that already existed
+    before this change, downgrade it to **Minor** and register it as `存量待整改` in your
+    report — never ask for a rewrite outside the task scope.
+
+    **Structural criteria — mandatory answers** (no threshold: answer AND justify):
+    - **Single responsibility**: can the function name cover ALL steps in the body?
+    - **DRY**: is there a structurally equivalent logic block within this diff OR this
+      repository (ignore comments, whitespace, identifier names)? Answer "yes" only when
+      you cite BOTH `file:line` sides.
+      - Disposition: same shared publish unit (same package / module / directory) →
+        **Critical**, extract a shared layer. Cross-repo duplication is NOT judgeable
+        here (your worktree is single-repo).
+
+    **Judgement cases** — when a structural hit is genuinely not blocking, cite it as
+    `judgement-exception: <id>` **plus the structural similarity** (e.g. "all guard clauses,
+    no nesting"). Match by **structural features, not line count** — the numbers below
+    illustrate the case, they are not thresholds. Available ids:
+    - `P1` — long function (≈37 lines) whose body is all guard clauses, one abstraction level → not blocking
+    - `P2` — cross-repo isomorphic fix, no shared publish unit → not blocking
+    - `N1` — long function (≈54 lines) that is guard clauses + one switch, no nesting → not blocking
+    - `N2` — deep nesting arising from try/catch + guard-clause `continue` → already covered
+      by the nesting rule (cite only if that rule's intent is disputed)
+    - `N4` — ≈35 lines, single abstraction level (error mapping) → advisory only
+    - Magic-value exemptions beyond the criterion's list: no id needed — apply the criterion's
+      own test ("does changing this value change behavior?") and state your reasoning.
+
     **Tests:**
     - Do the new and changed tests verify real behavior, not mocks?
     - Are the task's edge cases covered?
@@ -127,12 +161,12 @@ Subagent (general-purpose):
     Categorize issues by actual severity. Not everything is Critical.
     Important means this task cannot be trusted until it is fixed: incorrect
     or fragile behavior, a missed requirement, or maintainability damage you
-    would block a merge over — verbatim duplication of a logic block,
-    swallowed errors, tests that assert nothing. "Coverage could be broader"
-    and polish suggestions are Minor.
+    would block a merge over — structurally equivalent duplication of a logic
+    block (see Structural criteria), swallowed errors, tests that assert
+    nothing. "Coverage could be broader" and polish suggestions are Minor.
     If the plan or brief explicitly mandates something this rubric calls a
-    defect (a test that asserts nothing, verbatim duplication of a logic
-    block), that IS a finding — report it as Important, labeled
+    defect (a test that asserts nothing, structurally equivalent duplication
+    of a logic block), that IS a finding — report it as Important, labeled
     plan-mandated. The plan's authorship does not grade its own work; the
     human decides.
     Acknowledge what was done well before listing issues — accurate praise
@@ -161,6 +195,18 @@ Subagent (general-purpose):
       diff alone, and what the controller should check — report alongside the
       ✅/❌ verdict for everything you could verify]
 
+    ### Structural Criteria (mandatory answers)
+
+    Answer both; cite `file:line` for each. If you downgrade by citing a judgement
+    case, name it here as `judgement-exception: <id>` plus the structural similarity.
+
+    - **Single responsibility**: [Yes | No — if No, list the steps the function name
+      cannot cover, with file:line]
+    - **DRY**: [Yes | No — if Yes, cite BOTH `file:line` sides + shared-layer disposition]
+
+    **存量待整改** (pre-existing hits downgraded to Minor — one per line, or "none"):
+    - [e.g. `src/foo/Bar.java:120` — function length >20 lines, pre-existing]
+
     ### Strengths
     [What's well done? Be specific.]
 

package/skills/clean-code/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: clean-code
+description: 代码结构质量判据 skill——可机械判定项阈值与计数口径、审查必答项、增量归因边界与共享层判定。
+user-invocable: false
+---
+
+# Clean Code
+
+代码结构质量的判据集。判据三分：能机械判定的给阈值；需要判断力的设为「必答项」（不给阈值，但必须回答并给理由）；既有的不动。
+
+判例集与判例引用约定见 `references/judgement-cases.md`；共享层判定的完整规则见 `references/shared-layer-rules.md`。
+
+> **执行处说明**：本文件是判据**真相源**。实际执行由**派发模板**承载——`skills/build-executor/implementer-prompt.md`（实施自检）、`skills/build-executor/task-reviewer-prompt.md`、`skills/code-reviewer/code-reviewer-prompt.md`（审查）各自内联判据，因为由模板派发的 `general-purpose` 子代理读不到本文件。两侧须保持一致。
+
+## 1. 判据三分
+
+| 类型 | 判据 | 处置 |
+|---|---|---|
+| 可机械判定项 | 魔法值、函数长度、嵌套深度、参数个数、命名形式 | 查表 §2 |
+| 审查必答项 | 单一职责、DRY | 必答 §3（不给阈值）|
+| 沿用既有清单项 | 错误处理、边界条件、YAGNI/过度设计 | 本 skill 不涉及，由原清单负责 |
+
+为何不给「单一职责」设阈值：它需要判断力，阈值化会制造查表错觉。实测反证——37 行的 `validateFrontSystemSecret`（通体卫语句、单层抽象）可读性良好；54 行的 `handleDelivery`（三个卫语句 + switch + catch）同样良好。任何「抽象层级计数」规则都无法在这一对同类样本上复现判定，故该规则已废。
+
+## 2. 可机械判定项
+
+| 判据 | 阈值 | 分级 | 例外 |
+|---|---|---|---|
+| 魔法值（后端）| 见下方口径 | **Critical** | 见下方豁免 |
+| 魔法值（前端）| 同上 | **Critical** | 同上 |
+| 函数长度 | >20 行 | Minor | 存量代码（§4）|
+| 嵌套深度 | >2 层 | Minor | 见下方计数口径 |
+| 参数个数 | >3 个 | Minor | 框架接口固定签名不适用 |
+| 命名（形式）| 常量非 SCREAMING_SNAKE；布尔非 `is` · `has` · `can` 前缀 | Minor | 仅判形式；命名是否揭示意图属审查者判断，在报告中说明即可 |
+
+### 2.1 魔法值判据口径（真相源）
+
+- **定义**：直接出现在逻辑中的数值 / 字符串字面量，**其值变化会改变行为**。典型：业务码、TTL / 超时、阈值、错误消息、键名、URL、正则。
+- **豁免**：结构性索引（`arr[0]`、`list.get(0)`）、算术恒等元（`i + 1`、`x * 1`）、空串 / 空集合判断、CSS 取值、注解参数、日志格式串、测试夹具中自明数据、生成代码。
+- **适用范围**：`src/main` 与前端**运行时**代码。**不适用**于测试代码、构建脚本、SQL 迁移。
+- **交付形态**：命名为常量或枚举（枚举用于有语义集合，纯常量入常量类）。
+
+> 项目 conventions 若给出更严或更宽的豁免，以 conventions 为准（§7）。
+
+### 2.2 计数口径
+
+- **函数长度**：按**有效行**计——不含空行与纯注释行；**签名行计入**。
+- **嵌套深度**：函数体为第 1 层，每进入一个块（`if` / `for` / `while` / `switch` / `try`）加 1。**排除** `try/catch` 自身一层与卫语句（`return` / `continue`）所在层；`try/catch` 仅排除自身，其体内语句仍计入。
+
+函数长度恒为提示级，不设升级线：曾拟「>50 行升 Important」，但该阈值系从样本反推（过拟合），且会与存量长函数冲突。长度异常的价值由 §3 的必答项综合判断承载。
+
+## 3. 审查必答项（不给阈值，须给理由）
+
+| 判据 | 判定要件 | 必答格式 |
+|---|---|---|
+| 单一职责 | 函数名能否概括函数体的全部步骤？ | 必须回答「是 / 否」；答「否」须列出无法概括的步骤 + 分级理由。**不单独升级为 Critical** |
+| DRY | 本 diff 内或本仓内是否存在结构等价的逻辑块（忽略注释、空白、标识符命名）？ | 必须回答；答「是」须给两侧 `文件:行号` + 结构对比 + 按 §5 判定处置。**同共享发布单元内的重复 = Critical**（见 §5）|
+
+效力边界（诚实声明）：必答格式使发现过程可被第三方核对，提升的是发现一致性，不是判定一致性——分级仍由审查者判断，「须给理由」也可能被套用现成话术。故单一职责不单独升 Critical，避免用一条无客观约束的判据制造阻断。
+
+判例引用出口：审查者可在报告中标注 `judgement-exception: <判例编号>`（编号与含义见 `references/judgement-cases.md`，模板侧同步内联）以引用客观例外，须同时写明与该判例的相似点。该机制用于防止用现成话术无边界降级；**机械判定项同样可引用**（判例 `P1` / `N2` / `N4` 即针对长度与嵌套）。
+
+## 4. 增量归因边界
+
+判据只判本次 diff 新增或修改的行所属的代码单元。
+
+| 情形 | 处置 |
+|---|---|
+| 新增函数命中 | 按 §2 / §3 正常判定 |
+| 存量函数命中（本次改动前已存在）| 一律降 Minor，并在审查报告中登记「存量待整改」（函数名 + `文件:行号` + 命中判据）|
+
+为何不设「改动占比」阈值：函数总行数不在 diff hunk 内、而审查者被限制读文件，无取证通道；且按次求值可被「两次各改 40%」规避。存量恒为 Minor ⇒ 无豁免判定、无计算需求、无规避动机。台账经审查报告累积。
+
+## 5. 共享层判定（结论）
+
+| 步 | 判据 | 判定 |
+|---|---|---|
+| 1 | 复制体是否在同一共享发布单元内（同 npm 包 / 同 Maven 模块 / 同仓同目录）？ | **是 → 应抽共享层**（Critical）|
+| 2 | 缺陷是否属同名耦合类（编译期无保护）？若是，横展须逐字节同构并留对端标注 | 附加条件 |
+
+**跨仓不可判**：审查者 worktree 为单仓；跨仓 DRY 归横展完整性检查承接。完整规则、判定依据与 v1 实测校验见 `references/shared-layer-rules.md`。
+
+## 6. 取证边界
+
+DRY 的取证范围是「本 diff 内或本仓内」，两条派发路径的依据不同：
+
+- task 级审查（`skills/build-executor/task-reviewer-prompt.md`）：显式授权——「Inspect code outside the diff only to evaluate a concrete risk you can name — one focused check per named risk」
+- wave 级审查（`skills/code-reviewer/code-reviewer-prompt.md`）：无禁止性条款（约束仅有 read-only 与 scope 限制）
+
+「须给两侧 `文件:行号`」这一格式要求本身即构成上述条款所要求的「命名的具体风险」。
+
+## 7. 与 conventions 的关系
+
+- conventions 优先：项目 conventions 与本 skill 冲突时以项目为准（项目级契约 > 通用缺省）。
+- 追加通道：项目可沉淀「本项目特有的结构约定」，格式参照项目级 `backend-patterns.md` 的 `MUST + 来源 + 证据段` 范式。
+- 引用约定：conventions 引用插件侧 references 时 MUST 写全路径 `skills/<skill>/references/<file>.md`，不得写裸 `references/...`。
+- 参数口径：`test-strategy` 的 `param_count>6` 判测试复杂度，本 skill 的「参数 >3」判可读性——管辖不同，非矛盾。
+
+## 8. 自检口诀
+
+新增函数交付前逐条自查：常量命名了吗？超 20 行了吗？嵌套超 2 层了吗？只做一件事吗？与其他地方重复吗？
+
+## 9. 术语中英对照
+
+本 skill 以中文面向读者；三个派发模板以英文内联执行（受众为 `general-purpose` 子代理）。两侧判据**语义相同**，P4 一致性检查按下表比对：
+
+| 中文（本 skill）| English（模板内联）|
+|---|---|
+| 魔法值 | Magic values |
+| 单一职责 | Single responsibility |
+| 结构等价 | structurally equivalent |
+| 共享发布单元 | shared publish unit |
+| 存量待整改 | pre-existing / register as 存量待整改 |
+| 判例引用出口 | judgement-exception |
+| 必答项 | mandatory answers |
+| 增量归因边界 | incremental boundary |

package/skills/clean-code/references/judgement-cases.md

@@ -0,0 +1,83 @@
+# 判例集（Judgement Cases）
+
+> **用途**：为「审查必答项」（单一职责 / DRY）提供**客观锚点**，防止判据退化成新的直觉。
+> **全部判例均取自 emp-auth v1 的真实代码**，非虚构。
+
+## 判例引用约定
+
+审查者在报告中对某项判定可标注：
+
+```
+judgement-exception: <P1|P2|N1|N2|N4>
+```
+
+含义：**该降级属客观例外**（非主观放行）。使用要求：
+
+1. 必须同时写明「本处与所引判例的相似点」（至少一条结构性事实，如"通体卫语句、无嵌套"）；
+2. 引用判例**不改变**判据本身的阈值适用——它只解释为何某项判定不阻断；
+3. 若某处与判例只有表面相似（如"也超 20 行"但结构不同），引用无效，按正常分级处理。
+
+**为何需要这个出口**：`task-reviewer-prompt.md` 既有条款 "a stated rationale never downgrades a finding's severity" 约束的是**实施者的自述**；本出口约束的是**审查者的判定**，两者主体不同。判例编号把「判定」从「话术」中分离出来——引用必须有结构性事实支撑。
+
+## 一、判为「Critical（阻断）」的锚点
+
+### N3 — 同一共享单元内的结构等价复制
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C2 `ui-emp-frame/src/views/iam/relay.vue:19-52`（常量 + `hasControlChar` + `isValidFrontSystem`，其中 `isValidFrontSystem` 在 `:44`）→ v1-C3 同仓 `logout.vue:12-44`（在 `:35`）|
+| **判定** | **Critical**（DRY）|
+| **依据** | §5 步 1「同一共享发布单元内」成立：同一 npm 包、同仓同目录 |
+| **取证** | 两侧同在本仓 → 可达（`code-reviewer-prompt.md` 无禁止性条款；task 级有显式授权）|
+| **要点** | 结构等价判定**忽略注释差异**——两处注释分别为「SP-1 裁定 / design.md D-01」与「与登录入口 relay.vue 同口径」，不作为"非重复"的依据 |
+
+## 二、判为「不阻断」的锚点（防止过度阻断）
+
+### P1 — 长函数但结构清晰
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C1 `infra-emp-auth` `SysFrontSystemService.java:382-418`（`validateFrontSystemSecret`，37 行）|
+| **判定** | 不阻断（长度属提示级）|
+| **理由** | 通体卫语句早返回、无嵌套、每步有意图注释 |
+| **反面对照价值** | 该函数内含 repository 调用、枚举判断、摘要算法与结果装配 —— **故「抽象层级计数」不可作为判据**（同一规则会把它与 N1 混为一谈，得出相反判定）|
+
+### P2 — 跨单元的必要横展
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C5 `AuthService.java:47`（两个 BFF 仓各删 1 行 `@Cacheable`）|
+| **判定** | 不阻断 |
+| **依据** | 跨仓、无共享发布单元、无可用共享通道 → 必要横展（见 `shared-layer-rules.md`）|
+| **注意** | 本判例**不在** `clean-code` 的 DRY 判据范围内（跨仓不可判），归 `cross-change-consistency-checker` 的 Dim 5 承接。列此仅为说明「跨单元 ≠ 应抽层」的边界 |
+
+### N1 — 多职责外观但实为单一层次
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C3 `bff-emp-usersidentification` `AcceptInvalidTokenConsumer.java:57-115`（`handleDelivery`）|
+| **判定** | 不阻断 |
+| **理由** | 三个卫语句早返回 + 一个 switch + catch 兜底，**通体无嵌套** |
+| **历史** | 曾被判「阻断」，理由为「混合域判断/事件解析/规范化/分支/日志」——该描述**不可复现**。其签名 4 个参数亦不适用参数判据（`MessageListener` 框架固定签名）|
+
+### N2 — 深嵌套但来自 try/catch 与卫语句
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C3 `InvalidTokenInitializer.java:81`（bff）/ `:85-137`（adapter）|
+| **判定** | 提示（嵌套例外已排除）|
+| **理由** | 嵌套层级来自 try/catch 自身一层与卫语句 `continue` 所在层——按 §2 例外规则**不计入深度**|
+
+### N4 — 长度超阈值但单一抽象层级
+
+| 项 | 内容 |
+|---|---|
+| **位置** | emp-auth v1-C2 `demo/bff/.../RelayTokenClient.java:51-85`（`redeem`，35 行含 4 个 catch 分支）|
+| **判定** | 提示 |
+| **理由** | 单一抽象层级（错误映射与信封解包）；长度超阈值但无职责混杂 |
+
+## 三、判例集维护约定
+
+1. **增补来源**：仅接纳**真实代码**中的判定分歧案例（同一判据在不同审查者间给出不同结论）；
+2. **增补须附**：位置（`文件:行号`）、判定、结构性理由、与该判例易混之处；
+3. **判例可能被推翻**：若新证据表明某判例的判定有误（如 P1 被证明实为职责混杂），**更新判例本身**并在设计文档版本记录中注明——不得保留错误判例供后续引用。

package/skills/clean-code/references/shared-layer-rules.md

@@ -0,0 +1,50 @@
+# 共享层判定与跨仓边界
+
+> 用途：区分「必要横展」与「应抽共享层」——**两种处置的正确性相反，判错即方向性错误**。
+
+## 一、二判据（顺序判定）
+
+| 步 | 判据 | 判定 |
+|---|---|---|
+| 1 | 复制体是否在**同一共享发布单元**内（同 npm 包 / 同 Maven 模块 / 同仓同目录）？ | **是 → 应抽共享层**（同单元内复制必然漂移，且抽取成本最低）|
+| 2 | 缺陷是否属**同名耦合类**（编译期无保护，如缓存名、常量名）？若是，横展须**逐字节同构**并留对端标注 | 附加条件，不单独改变步 1 判定 |
+
+### 为何是二判据，而非三判据
+
+早期版本曾有第三条「跨单元时是否存在可用的共享通道（父 POM / 可发公共包 / 已有跨仓契约）」。**该判据已删除**，两个原因：
+
+1. **共线**：跨仓必然无共享单元，第 1 条已隐含"跨单元"的判定，第 3 条只在跨单元时才触发 —— 两条实际只有一条在起作用；
+2. **不可判定**：审查者被锁定单仓 worktree，无法知道别的仓有无父 POM 依赖或公共包 —— 该判据**无取证通道**（与「跨仓 DRY 不可判」同源）。
+
+删除后本判据**完全在单仓内可判**。
+
+## 二、跨仓边界（重要）
+
+**本判据只管单仓内**。下列情形**不在** `clean-code` 的判据范围：
+
+| 情形 | 归属 |
+|---|---|
+| 跨仓的同构缺陷（如 v1-C5 修了 2 个 BFF 仓、漏了 2 个 adapter 仓）| `cross-change-consistency-checker` 的 **Dim 5（同构横展完整性）** |
+| 跨仓的重复代码 | 同上（模式驱动扫描全部仓，见 Dim 5）|
+
+理由：审查者的 worktree 为**单仓**（实证：`changes/<name>/.superpowers/sdd/reviews/w*.md` 的 metadata 含 `Target repository: service/<repo>`），跨仓在物理与约定层面均不可达。
+
+## 三、v1 实测校验
+
+| 案例 | 步 1 | 判定 | 与实测一致性 |
+|---|---|---|---|
+| C2 `relay.vue` → C3 `logout.vue`（同仓同目录同一 npm 包）| 是 | **应抽共享层** | ✅ 与实测判断一致 |
+| C5 后端两仓（`bff-emp-usersidentification` / `bff-emp-clientsidentification`，跨仓、无共享 jar、hunk md5 相同、同名缓存值类型耦合）| 跨仓 | **不在本判据范围** → Dim 5 承接 | ✅（当时判为必要横展，结论正确但依据不同）|
+| C5 前端三仓（各自独立 npm 包、各修本仓存储封装）| 跨仓 | **不在本判据范围** | 同上 |
+
+## 四、判定为「应抽共享层」后的处置
+
+1. **不要求本次 change 立即重构**（避免范围蔓延）——除非该抽取本身在本次 write_set 内；
+2. 在审查报告中标注为 **Critical**（DRY 唯一的分级），并给出共享层建议落点（如 `src/utils/`）；
+3. 若项目 conventions 已有对应的共享层约定，以 conventions 为准。
+
+## 五、判定为「必要横展」的处置（由 Dim 5 承接时）
+
+1. 横展须**逐字节同构**（含注释口径），并保留对端来源标注（参照项目级 `backend-patterns.md` 的 §8.1 范式）；
+2. 横展范围须覆盖**全部**同构位置——遗漏即 Dim 5 的 Important 发现（可达时）；
+3. 不可达位置（零调用方）记 Minor，属「预防性一致处置」。

package/skills/code-reviewer/SKILL.md

@@ -133,6 +133,12 @@ Check for:
 - **Performance**: No obvious N+1 queries, no unnecessary loops, appropriate caching
 - **Security**: Input validation, SQL injection prevention, XSS prevention, auth checks
 
+**Structural criteria (clean-code, v0.58.0)**：本节另有一套可判定判据——机械阈值（魔法值 Critical；长度/嵌套/参数/命名 Minor）+ 两项必答（单一职责、DRY）。
+
+**执行处是派发模板** `skills/code-reviewer/code-reviewer-prompt.md`（其 Code quality 段已内联完整判据），**不是本文件**。原因：由该模板派发的 `general-purpose` 子代理**读不到**本 SKILL.md 或 `clean-code` skill——子代理不继承父 Agent 的 Skills（CLAUDE.md 明文）。注：该模板经**直接路径读取**（本文件 `Procedure` 步骤 2 指明），**不**经 `tf runtime asset read` 的 `ASSETS` 白名单——后者仅含 `skills/build-executor/implementer-prompt.md` 与 `task-reviewer-prompt.md` 两个模板，写此文时曾误述为「白名单放行本模板」。
+
+本 SKILL.md 与 `clean-code` skill 是判据的**真相源**，供 agent 路径预加载与维护参考；两侧核心判据 MUST 保持一致（由 P4 一致性检查守护）。
+
 ### Step 4: Architecture Review
 
 Check for:
@@ -194,12 +200,16 @@ Check for:
 
 ## Verdict Criteria
 
+本表用于**报告内**的结论表述；写入 receipt 时只有 `pass | fail` 两值，映射规则见末行。
+
 | Verdict | Condition |
 |---------|-----------|
 | **PASS** | No Critical or Important findings |
 | **PASS_WITH_WARNINGS** | No Critical, but Important findings exist |
 | **FAIL** | Any Critical finding (including Test Matrix Compliance gaps — v0.12 §44.3) |
 
+**receipt 映射（v0.58.0 统一，消除此前四处口径分歧）**：`tf execution review --verdict` 只接受 `pass | fail`。**PASS → `pass`**；**PASS_WITH_WARNINGS 与 FAIL 均 → `fail`** —— 即 **Important 亦须阻断**，与 `code-reviewer-prompt.md`、`task-reviewer-prompt.md`、`build-executor/SKILL.md` 三处的「Critical/Important findings require a `fail` receipt」保持一致。此前本表的「FAIL 仅 Critical」是四处口径中唯一的异类，且 `PASS_WITH_WARNINGS` 在二值 receipt 中**无法表达**，已按此统一。
+
 Test Matrix Compliance Critical findings carry the same weight as Spec Compliance violations — matrix gaps are always Critical, never Important.
 
 ## Calibration Rules

package/skills/code-reviewer/code-reviewer-prompt.md

@@ -69,6 +69,43 @@ Subagent (general-purpose):
     - DRY without premature abstraction?
     - Edge cases handled?
 
+    **Structural criteria (clean-code) — mechanical thresholds:**
+    - **Magic values** (unnamed numeric/string literals) → **Critical**. Front-end code too.
+    - Function length >20 lines / nesting depth >2 levels / parameters >3 / naming form
+      (constants SCREAMING_SNAKE; booleans `is`/`has`/`can` prefix) → Minor. When counting
+      nesting, exclude try/catch's own level and guard-clause `return`/`continue` levels;
+      framework-fixed signatures are exempt from the parameter rule.
+      These thresholds are **readability advisories**. The "Do not use line count as
+      evidence" rule under Minimality And Scope concerns *removing* required code; this
+      one NEVER justifies deleting validation, security, or error handling.
+
+    **Incremental boundary — applies to ALL criteria above and below**: judge only the code
+    units this diff adds or modifies. When a hit sits inside a function that already existed
+    before this change, downgrade it to **Minor** and register it as `存量待整改` in your
+    report — never ask for a rewrite outside the task scope.
+
+    **Structural criteria — mandatory answers** (no threshold: answer AND justify):
+    - **Single responsibility**: can the function name cover ALL steps in the body?
+    - **DRY**: is there a structurally equivalent logic block within this diff OR this
+      repository (ignore comments, whitespace, identifier names)? Answer "yes" only when
+      you cite BOTH `file:line` sides.
+      - Disposition: same shared publish unit (same package / module / directory) →
+        **Critical**, extract a shared layer. Cross-repo duplication is NOT judgeable
+        here (your worktree is single-repo).
+
+    **Judgement cases** — when a structural hit is genuinely not blocking, cite it as
+    `judgement-exception: <id>` **plus the structural similarity** (e.g. "all guard clauses,
+    no nesting"). Match by **structural features, not line count** — the numbers below
+    illustrate the case, they are not thresholds. Available ids:
+    - `P1` — long function (≈37 lines) whose body is all guard clauses, one abstraction level → not blocking
+    - `P2` — cross-repo isomorphic fix, no shared publish unit → not blocking
+    - `N1` — long function (≈54 lines) that is guard clauses + one switch, no nesting → not blocking
+    - `N2` — deep nesting arising from try/catch + guard-clause `continue` → already covered
+      by the nesting rule (cite only if that rule's intent is disputed)
+    - `N4` — ≈35 lines, single abstraction level (error mapping) → advisory only
+    - Magic-value exemptions beyond the criterion's list: no id needed — apply the criterion's
+      own test ("does changing this value change behavior?") and state your reasoning.
+
     **Architecture:**
     - Sound design decisions?
     - Reasonable scalability and performance?
@@ -124,6 +161,18 @@ Subagent (general-purpose):
     a fresh review and replacement `pass` receipt before any dependent wave or
     closing transition.
 
+    ### Structural Criteria (mandatory answers)
+
+    Answer both; cite `file:line` for each. If you downgrade by citing a judgement
+    case, name it here as `judgement-exception: <id>` plus the structural similarity.
+
+    - **Single responsibility**: [Yes | No — if No, list the steps the function name
+      cannot cover, with file:line]
+    - **DRY**: [Yes | No — if Yes, cite BOTH `file:line` sides + shared-layer disposition]
+
+    **存量待整改** (pre-existing hits downgraded to Minor — one per line, or "none"):
+    - [e.g. `src/foo/Bar.java:120` — function length >20 lines, pre-existing]
+
     ### Strengths
     [What's well done? Be specific.]
 
@@ -188,8 +237,23 @@ Subagent (general-purpose):
 - Comprehensive test coverage (18 tests, all edge cases)
 - Good error handling with fallbacks (summarizer.ts:85-92)
 
+### Structural Criteria
+
+- Single responsibility: Yes — each handler covers one step
+- DRY: No — `search.ts:25-27` duplicates the date-validation block in `parse.ts:88-90`
+  (structurally equivalent, comments/identifiers ignored). Same package → shared layer
+  recommended (Critical)
+
 ### Issues
 
+#### Critical (Must Fix)
+1. **Structurally duplicated date-validation block**
+   - File: `search.ts:25-27` (duplicates `parse.ts:88-90`)
+   - Issue: Same package, structurally equivalent — the two copies will drift
+   - Fix: Extract to a shared helper in the package's utils
+   - Note: A Critical finding forces `--verdict fail`; a repair requires a fresh
+     review and a replacement `pass` receipt before any dependent wave
+
 #### Important
 1. **Missing help text in CLI wrapper**
    - File: index-conversations:1-31
@@ -213,7 +277,9 @@ Subagent (general-purpose):
 
 ### Assessment
 
-**Ready to merge: With fixes**
+**Ready to merge: No** — a Critical finding is open
 
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+**Reasoning:** Core implementation is solid with good architecture and tests, but the
+structurally duplicated validation block (Critical) must be extracted into a shared layer
+before merge. The Important issues (help text, date validation) are easily fixed.
 ```

package/skills/workflow-orchestrator/references/s5-monitoring.md

@@ -24,10 +24,14 @@
 
 ### 2. 跨 change 一致性检测
 
-调用 `cross-change-consistency-checker` agent（插件 agent，跨 skill 复用价值）检测：
-- 共享聚合/实体的变更是否冲突
-- API 变更是否影响其他 change
-- 原型漂移（change 实现与全局 prototype/ 是否一致）
+调用 `cross-change-consistency-checker` agent（插件 agent，跨 skill 复用价值）检测 5 个维度：
+- 共享聚合/实体的变更是否冲突（Dim 1）
+- API 变更是否影响其他 change（Dim 2）
+- 架构锚点漂移（Dim 3）
+- 原型漂移（change 实现与全局 prototype/ 是否一致）（Dim 4）
+- **同构横展完整性（Dim 5，v0.58.0）**：本 change 处置的代码模式，是否在其**全部**出现位置都已处置
+
+**Dim 5 传参**：须向 agent 传 `repo_layout`（读 `<项目根>/.team-flow/team-flow.config.json` 的 `repo_layout.repos`）；缺失时 agent 跳过 Dim 5 并注明。**触发条件**：change 性质为缺陷修复 / 规则对齐 / 同构同步时启用；纯新功能开发跳过（无既有模式可横展）。**真空对照**：agent 对零命中的模式须显式报告「模式未命中，需人工确认」，不得记为 CLEAN。
 
 ### 3. 复利晋升
 

package/skills/workflow-start/SKILL.md

@@ -141,6 +141,10 @@ The current planned wave is implemented and ready for spec-compliance + code-qua
 ### Route to release-archivist (dispatch sub-agent)
 Guard: `... check <dir> executing closing --json` → fail = BLOCK. Implementation complete, verification complete/nearly complete. Include `DP-7: 归档确认`.
 
+**Dim 5 横展完整性检查（v0.58.0）**：`executing → closing` 前，若本 change 性质为缺陷修复 / 规则对齐 / 同构同步，调度 `cross-change-consistency-checker` agent 执行 **Dim 5**——传 `change_dirs`（本 change）+ `repo_layout`（读 `.team-flow/team-flow.config.json` 的 `repo_layout.repos`）。agent 以**模式驱动**扫描本 change diff 中被处置的具名结构元素在**全部仓**的出现位置，差异集即遗漏候选（可达 → Important，须先修复或登记；零调用方 → Minor）。**纯新功能开发跳过**（无既有模式可横展）。**零命中时 agent 须显式报告「模式未命中」而非 CLEAN**（防真空断言）。
+
+> 为何单 change 也要查：横展缺口发生在**单个 change 内部**（v1 实证：一个 change 修了 2 个同构仓、漏了 2 个），而 `cross-change-consistency-checker` 此前仅在 S5（change ≥ 2）被调度——**该场景下 Dim 5 永不触发**。此处是本检查对单 change 的唯一入口。
+
 ### Route to spec-merger
 Delta specs exist that need merging, change closing with ADDED/MODIFIED/REMOVED/RENAMED specs.
 

package/templates/conventions/glaf4-compliant/java-testing.md

@@ -326,7 +326,7 @@ void testGetUser_InactiveUser() { ... }  // status = INACTIVE
 
 ## 8. 测试质量规则
 
-参见 `references/test-quality-rules.md`，主要包括：
+参见 team-flow 插件 `skills/test-strategy/references/test-quality-rules.md`，主要包括：
 
 1. 断言质量规则（missing-meaningful-assertion、weak-assertion-only、verify-only-without-assertion）
 2. 调试代码残留规则（system-out、print-stack-trace）
@@ -339,7 +339,7 @@ void testGetUser_InactiveUser() { ... }  // status = INACTIVE
 
 ## 9. 测试隔离
 
-参见 `references/integration-test-isolation.md`，主要包括：
+参见 team-flow 插件 `skills/test-strategy/references/integration-test-isolation.md`，主要包括：
 
 - Repository 层：H2 内存库
 - Service 层（同步）：@Transactional
@@ -350,7 +350,7 @@ void testGetUser_InactiveUser() { ... }  // status = INACTIVE
 
 ## 10. 集成测试契约
 
-参见 `references/integration-test-contracts.md`，主要包括：
+参见 team-flow 插件 `skills/test-strategy/references/integration-test-contracts.md`，主要包括：
 
 - 入口契约：API 端点、消息队列、定时任务
 - 协作者契约：真实/mock/stub 分级

package/templates/conventions/js-testing.md

@@ -244,7 +244,7 @@ describe('UserService', () => {
 
 ## 7. 测试质量规则
 
-参见 `references/test-quality-rules.md`，主要包括：
+参见 team-flow 插件 `skills/test-strategy/references/test-quality-rules.md`，主要包括：
 
 1. 断言质量规则（missing-meaningful-assertion、weak-assertion-only）
 2. 调试代码残留规则（console.log）

package/templates/conventions/python-testing.md

@@ -316,7 +316,7 @@ def mock_external_api(mocker):
 
 ## 9. 测试质量规则
 
-参见 `references/test-quality-rules.md`，主要包括：
+参见 team-flow 插件 `skills/test-strategy/references/test-quality-rules.md`，主要包括：
 
 1. 断言质量规则（missing-meaningful-assertion、weak-assertion-only）
 2. 调试代码残留规则（print）