@xulthekl/team-flow 0.44.0 → 0.46.0

package/skills/contract-builder/references/glaf4-delegation.md

@@ -0,0 +1,130 @@
+# GLAF4 Delegation 段产出协议（v2.1 §6.1/§6.2）
+
+> 设计溯源（工作区开发期文档，非运行时加载路径）：`docs/plan/glaf4-dev-integration-design.md` v2.1（glaf4-dev 集成增强方案，位于 team-flow-workspace 工作区根）。
+> 职责：contract-builder 在产出 execution-contract.md 时，对 GLAF4 Java change 追加 `## GLAF4 Delegation` 段，
+> 作为**实施委托交接**（非矩阵设计委托）。经 DP-4 批准后生效。
+
+## 1. 运行时探测（v2.1 §4 接口①）
+
+contract-builder 产出 execution-contract 时（DP-4 前）实时探测——**显式运行 CLI 命令**（第三轮复评接线统一：探测必须写 config，纯库函数不落盘）：
+
+```bash
+tf glaf4-delegation detect <target_root> [--delegation-mode <auto|manual|off>]
+```
+
+`detect` 内部调用 `conventions-generator.mjs` 的 `detectGlaf4Delegation(root)` 解析 `~/.claude/plugins/installed_plugins.json`（glaf4-dev 条目含 installPath + version），产出三态：
+
+- `is_glaf4_java`（技术栈命中：pom.xml/build.gradle + Spring Boot/JUnit5/Mockito）
+- `glaf4_dev_available`（插件可用，含 version）
+- `delegation_mode`（auto/manual/off，用户可开关）
+
+探测结果写 `team-flow.config.json` 的 `glaf4_dev: {enabled, version, delegation_mode}` 段
+（git root ≠ target_root 时写 git root 冗余副本，monorepo 下多服务 OR 聚合；未传 `--delegation-mode` 保留已有值）。
+
+**判定**：`is_glaf4_java && glaf4_dev_available && delegation_mode !== 'off'` → 产出 GLAF4 Delegation 段。
+**依赖**：`recommendExecutionModesForChange` 读 `config.glaf4_dev.enabled` 决定是否注入 glaf4-delegation——**必须**先跑 detect 写 config，否则委托链不可达。
+
+## 2. change 性质 → 委托模式映射（v2.1 §6.1）
+
+| change 性质 | glaf4-dev 模式 | 权限位 |
+|---|---|---|
+| 新功能 / 新增接口 / 新增模块 | FEATURE_TDD | after-red |
+| 缺陷修复 | BUGFIX_REGRESSION | after-red |
+| 行为不变重构 | REFACTOR_PROTECTED | allowed + baseline_green_required |
+| 补单元测试(存量) | COMPLETE_UNIT_TESTS | none(test-only) |
+| 补集成测试(存量) | COMPLETE_INTEGRATION_TESTS | none(test-only) |
+| 测试环境冷启动(零测试) | TEST_BOOTSTRAP | none(test-only) |
+
+> REFACTOR 委托前置：存量基线不绿时委托必 NEEDS_INPUT → 先走 TEST_BOOTSTRAP/COMPLETE_UNIT_TESTS 补基线。
+
+## 3. GLAF4 Delegation 段结构
+
+execution-contract.md 追加段（write_set_boundary 权威源，不落 state YAML）：
+
+```markdown
+## GLAF4 Delegation
+
+- mode: FEATURE_TDD
+- permission: after-red
+- write_set_boundary:
+  - src/main/java/com/example/OrderService.java
+  - src/main/java/com/example/OrderRepository.java
+- target_root: <工程根绝对路径>
+- delegation_mode: auto
+- glaf4_dev_version: 0.3.0
+```
+
+## 4. DP-4 委托方案确认（v2.1 §6.6）
+
+先走 S1 执行模式选择（v2.1 §6.6），选 `glaf4-delegation` 产单 wave 计划：
+
+```bash
+# 0. 选模式（DP-4 决策门；单 wave = 委托 glaf4-dev 完成 change）
+tf execution plan <change-dir> --mode glaf4-delegation --wave w1:serial:delegate --confirm --reason "<委托理由>"
+```
+
+模式选定后，确认 5 项并写状态：
+
+```bash
+# 1. 写 write-set.json（边界文件清单）+ dp_4_glaf4_mode + dp_4_write_set_hash
+tf glaf4-delegation confirm <change-dir> --mode FEATURE_TDD --write-set <write-set.json>
+
+# 2. 置 delegation_status（委托进行中）
+tf state set <change-dir> delegation_status in_progress
+```
+
+5 项确认：① change→mode 映射 ② write_set_boundary ③ 串行特征 ④ 两级门预期 ⑤ 授权委托。
+`dp_4_glaf4_mode` 入 state；`dp_4_write_set_boundary`（文件清单）不落 state YAML（writeState 硬编码字段列表 +
+parseYaml 仅标量），落 `.superpowers/glaf4/write-set.json`，state 只存 `dp_4_write_set_hash` 引用 hash。
+`dp_4_result` 由 `tf execution plan --confirm` 程序化写入，手工 set 会被覆写。
+
+## 5. 委托 run 后对账（v2.1 §6.3）
+
+```bash
+# write-set 对账（门禁级 FAIL，阻断 closing）
+tf glaf4-delegation verify-write-set <change-dir> --run-dir <run-dir>
+
+# task 完成度审计（WARN，人工核对）
+tf glaf4-delegation verify-tasks <change-dir>
+```
+
+允许集（change 边界之外允许写入）：pom.xml/build.gradle、src/test/java/**、src/test/resources/**、
+.glaf4-dev/runs/**、test-environment.json。这是唯一约束 change 边界的机械机制。
+
+## 6. 委托失败恢复（v2.1 §6.7）
+
+- delegation_status=failed → guard 阻断 closing 直到人工重置（三选一）
+- ① 重试（retry_count 封顶 3，达上限禁止继续重试）② 降级（reset 删 plan 重走 DP-4）③ 标记阻塞转人工
+- 环境错误（environment_error=true）直接转 ②/③，不浪费重试
+- BLOCKED 残留 partial writes：`tf glaf4-delegation record-partial <change-dir> --run-dir <run-dir>` 落 `delegation_partial_writes` 清单，人工核对从"扫盘"降为"确认清单"
+
+## 7. 骨架矩阵先行时序（v2.1 §5，I6 固化防 H1 死锁复发）
+
+**顺序写死，不可颠倒**——否则骨架矩阵缺失 → GLAF4 change 进不了 executing（原 H1 死锁复发）：
+
+```
+bridging：contract-builder 产非空骨架矩阵 test-matrix.md（过 test-matrix-ready 入口门）
+  → tf state rebuild（捕获骨架矩阵 hash）
+  → 委托 run（glaf4-dev 七模式流）
+  → run 终局 → 矩阵回灌覆盖骨架（test-matrix-export v2 转 MD）
+  → tf state rebuild（过 test-matrix-complete 出口门）
+```
+
+## 8. closing 时序协议（v2.1 §6.3，I5 固化防 plan 过期卡死）
+
+**顺序不可乱**——tasks.md 翻转/矩阵回灌改变 artifacts_hash → plan 过期（receipt 失效）；必须先 refresh-hash 再记录 review：
+
+```
+run 终局 PASS
+  → 矩阵回灌（test-matrix-export v2 + 覆盖 test-matrix.md）
+  → tf state rebuild（只改 state 文件，不动 plan JSON）
+  → tf execution refresh-hash（更新 plan.artifacts_hash，防 plan 过期）
+  → 委托代理 commit glaf4-dev 产物
+  → code-reviewer 独立审查 base..head（报告落 .superpowers/sdd/reviews/）
+  → tf execution review --wave w1 --verdict pass
+  → tf glaf4-delegation verify-write-set（门禁级对账，FAIL 阻断）
+  → tf state set delegation_status success
+  → tf state transition ... closing
+```
+
+> `tf state rebuild` 不能替代 `refresh-hash`（前者不动 plan JSON）；review 需真实 git base≠head，必须 commit 后取 SHA。

package/skills/project-initialize/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: project-initialize
+description: 项目初始化引导。工作空间代码服务为空时触发：识别需初始化 → 引导架构选择（glaf4 体系/前端分离/单体微服务/拆分）→ 服务命名确认 → 创建服务子目录 → 委托初始化骨架（glaf4 走 glaf4-dev PROJECT_INITIALIZE，非 glaf4 走内置引导）。
+---
+
+# Project Initialize（项目初始化引导）
+
+产品级初始化引导流程（v2.1 §6.5，2026-08-19 LT 定案）。工作空间代码服务为空时，引导用户完成架构决策、创建服务子目录并委托初始化骨架。
+
+## 触发条件
+
+由编排层 Pre-check 检测驱动（v2.1 §6.5 触发接入，评审 M2 补全）：
+- **场景①（orchestrator）**：需求迭代架构设计（ARCH）评审 PASS 后、S3 计划前——架构快照涉及服务未初始化
+- **场景②（workflow-start）**：change 阶段发现服务缺漏——AskUserQuestion 区分「未拉取」（git pull/检出后继续）vs「需要初始化」（引导本 skill）
+- **场景③（直接）**：工作空间代码服务为空（无服务子目录/技术栈特征），用户显式初始化
+
+## 流程（顺序执行）
+
+### Step 1 识别需初始化
+
+检测工作空间是否有服务子目录/技术栈特征；为空 → 进入引导。
+
+### Step 2 引导新会话
+
+提示用户启动新会话（干净上下文，避免与 change 工作流混杂）。参考 session-handoff 会话交接机制。
+
+### Step 3 架构选择（AskUserQuestion 逐项）
+
+1. **是否 glaf4 体系**？（影响委托路径——glaf4 走 glaf4-dev，非 glaf4 走内置引导）
+2. **是否前端分离**？（前后端独立目录 vs 合并）
+3. **单体 or 微服务**？
+4. **若微服务 → 拆分方式**？（按领域/按模块/按团队）
+
+决策树与判定依据见 `references/architecture-choice.md`。
+
+### Step 4 服务命名确认
+
+基于架构选择确定服务列表，AskUserQuestion 确认命名（禁止擅自命名）。
+
+### Step 5 创建服务子目录
+
+team-flow 创建空目录（如 `services/<svc>/`）+ `git init` + `.gitignore`（忽略 `.glaf4-dev/` 等运行期目录）。布局与命名规则见 `references/service-layout.md`。
+
+### Step 6 委托初始化
+
+- **glaf4 体系** → 委托 glaf4-dev PROJECT_INITIALIZE（进入空服务子目录初始化骨架）。协议见 `references/glaf4-initialize-delegation.md`
+- **非 glaf4** → workflow-bootstrap **B1.5 全新项目路径**（交互式技术栈选择 + 可选骨架生成，test-capability v1.0 §4.3）
+
+## Guardrails
+
+- 服务命名必须用户确认，不擅自命名
+- 不创建非空目录、不覆盖已有内容
+- glaf4 委托前置：glaf4-dev 已装 + JDK8 + 离线依赖就绪（见 reference）
+- **glaf4 委托前置风险（评审 B1）**：gen-service 空检查需对 `.git`/`.gitignore`/`.glaf4-dev` 白名单化——glaf4-dev v0.3.0 未实现前 glaf4 委托会 BLOCK（缓解与调时序见 reference）
+- 与 workflow-bootstrap 边界：本 skill 管**骨架生成引导**（含 B1.5 全新项目路径），bootstrap 管**既有项目侦察/基线**（职责分离）
+
+## 产出
+
+- 服务子目录（骨架工程）
+- `.gitignore`（忽略 `.glaf4-dev/`）
+- 委托记录（若 glaf4 委托，run 终局证据）

package/skills/project-initialize/references/architecture-choice.md

@@ -0,0 +1,55 @@
+# 架构选择决策树（project-initialize Step 3）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（PROJECT_INITIALIZE 定案）
+> 用途：初始化引导时，逐项 AskUserQuestion 收集架构决策，确定服务列表与委托路径。
+
+## 决策维度（4 项，顺序执行）
+
+### 1. 是否 glaf4 体系？
+
+**判定依据**：团队技术栈是否基于 GLAF4 框架（Maven 依赖 `gtmc-glaf4-starter-parent`，包前缀 `com.gtmc.glaf4.framework.*`）。
+
+**影响**：
+- ✅ glaf4 → Step 6 委托 glaf4-dev PROJECT_INITIALIZE（骨架生成走 gen-service.py 六套模板）
+- ❌ 非 glaf4 → Step 6 workflow-bootstrap 内置引导（Java/JS/Python 技术栈选择）
+
+**判定**（AskUserQuestion）：
+- 是（GLAF4 框架体系）
+- 否（标准 Spring Boot / 其他技术栈）
+- 不确定 → 提示检查团队既有项目依赖，或选"否"走标准引导
+
+### 2. 是否前端分离？
+
+**判定**：业务是否有独立前端团队/部署单元。
+
+- 前后端分离 → 服务子目录拆为 `services/backend/` + `services/frontend/`（或独立 repo）
+- 合并（monolith 内嵌前端资源）→ 单服务目录
+
+### 3. 单体 or 微服务？
+
+**判定**：业务复杂度/团队规模/部署独立性需求。
+
+- 单体（monolith）→ 单服务，gen-service `--type monolith`
+- 微服务 → 进入维度 4（拆分）
+
+### 4. 微服务拆分方式？
+
+| 拆分维度 | 依据 | 例 |
+|---|---|---|
+| 按领域（DDD） | 业务域边界清晰，独立演进 | order/user/payment 服务 |
+| 按模块 | 技术模块独立部署 | gateway/backend/bff 服务 |
+| 按团队 | 团队自治部署 | 每团队一服务 |
+
+拆分结果 → 服务列表（每个服务一个子目录，命名走 Step 4 确认）。
+
+## 服务列表推导
+
+```
+单体 + glaf4        → [backend]（monolith）
+单体 + 非 glaf4     → [backend]（标准技术栈）
+单体 + 前端分离     → [backend(monolith), frontend]
+微服务 + glaf4      → [<svc1>, <svc2>, ...]（按拆分维度）
+微服务 + 前端分离   → [<svc1>, ..., frontend]
+```
+
+服务列表进入 Step 4 命名确认。

package/skills/project-initialize/references/glaf4-initialize-delegation.md

@@ -0,0 +1,55 @@
+# glaf4-dev PROJECT_INITIALIZE 委托协议（project-initialize Step 6）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（2026-08-19 定案）
+> 用途：glaf4 体系服务子目录创建后，委托 glaf4-dev 初始化骨架。
+
+## 前置（实证就绪，2026-08-19）
+
+| 前置 | 状态 | 验证 |
+|---|---|---|
+| glaf4-dev 插件已装 | ✅ | `~/.claude/plugins/installed_plugins.json` 有 glaf4-dev v0.3.0 |
+| JDK 8 | ✅ | 本机 jdk-1.8.jdk（1.8.0_411）+ Corretto 8；flow 要求 JDK8（模板 1.8 + 旧 Lombok） |
+| 离线 Maven 依赖 | ✅ | 本地 `~/.m2/repository/com/gtmc/` 有 gtmc-glaf4-starter-parent；编译走 `--offline` |
+| 服务子目录为空 | ✅ | Step 5 team-flow 创建空目录 + git init + .gitignore |
+
+## 委托流程
+
+```text
+1. 确认前置（上表）
+2. 调 glaf4-dev 统一入口（mode_hint=PROJECT_INITIALIZE）
+   → 路由到 PROJECT_INITIALIZE 七模式流：
+     inspect → plan → scaffold → test-bootstrap → smoke-green → validate
+3. run 终局 PASS → 骨架工程落地服务子目录
+4. 证据回灌（可选）：glaf4-evidence-export → test record（骨架基线测试）
+```
+
+## gen-service 空目录冲突（实证 + 缓解）
+
+**实证（2026-08-19）**：flow scaffold 写死 `gen-service.py --out <target_root>`，而 run 树 `.glaf4-dev/runs/` 先建在 target_root 下 → gen-service 空检查 `os.listdir` 非空 → **BLOCKED**（`out dir not empty`）。
+
+**非空来源（评审 B1 补全，2026-08-19）**：gen-service 空检查 `os.listdir` **无任何隐藏文件过滤**，以下三类都会触发 BLOCK：
+1. `.glaf4-dev/`（run 树，glaf4-dev 自建基础设施）
+2. `.git/`（Step 5 `git init` 产生）
+3. `.gitignore`（Step 5 写入）
+
+**缓解**：gen-service 空检查需对 `.git`/`.gitignore`/`.glaf4-dev` 三类基础设施条目**白名单化**（run 树与 git 元数据非工程内容）；**或调时序**——先对真空目录跑 gen-service（此时仅 run 树在，`.git` 未建），完成骨架后再 `git init` + `.gitignore`，且 gen-service 至少容忍 `.glaf4-dev`。**glaf4-dev v0.3.0 未实现白名单化前，glaf4 委托会 BLOCK**（SKILL Guardrails 已标注此前置风险）。
+
+**run 树位置（LT 决策 2026-08-19）**：不设专门外置方案——run 树在 target_root 是 glaf4-dev 统一约定，`.glaf4-dev/` 由 `.gitignore` 忽略，非关键路径。
+
+## gen-service 参数（scaffold 调用）
+
+```bash
+python3 <plugin-root>/scripts/gen-service.py \
+  --type <monolith|agg|infra|gateway|bff-backend|bff-open> \
+  --domain <业务域> --name <服务名> --out <服务子目录>
+```
+
+- `--type/--domain/--name/--out` 必填（gen-service.py L182-185）
+- 六种服务类型对应 templates/ 下模板树
+- 骨架含 pom.xml（引用 `gtmc-glaf4-starter-parent`）+ src + 资源，≈90+ 文件（monolith/infra 92、agg 68、bff-backend 48、bff-open 40、gateway 11）
+
+## 边界
+
+- **本协议只委托骨架生成**：业务代码（Controller/Service/Repository 等）走后续 change 级委托（FEATURE_TDD 等）
+- 委托失败 → run 终局 FAIL/BLOCKED → 恢复路径（重试/降级/转人工）
+- 与 workflow-bootstrap 边界：本协议管 glaf4 骨架，workflow-bootstrap 管既有项目侦察/基线

package/skills/project-initialize/references/service-layout.md

@@ -0,0 +1,63 @@
+# 服务子目录布局与命名（project-initialize Step 4/5）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（PROJECT_INITIALIZE 定案）
+
+## 目录布局约定
+
+```
+<workspace>/
+├── services/               # 服务容器（微服务/多服务）
+│   ├── <svc>/              # 每个服务一个子目录（Step 5 创建）
+│   │   ├── .gitignore
+│   │   └── （骨架，委托初始化后）
+│   └── ...
+├── docs/                   # 工作空间文档
+└── .team-flow/             # team-flow 项目状态
+```
+
+- **单体**：可直接在 `<workspace>/` 根或 `services/<svc>/` 下建
+- **微服务/多服务**：统一 `services/<svc>/` 容器，每服务独立子目录 + 独立 git
+
+## 命名规则
+
+- **kebab-case**（小写 + 连字符），如 `order-service`、`user-backend`
+- 语义：业务域 + 服务类型（`<domain>-<type>`），如 `order-backend`、`bff-open`
+- **必须用户确认**（Step 4 AskUserQuestion），禁止擅自命名
+
+## .gitignore 模板（Step 5 写入）
+
+```gitignore
+# team-flow / glaf4-dev 运行期基础设施
+.team-flow/
+.glaf4-dev/
+
+# 构建产物
+target/
+build/
+.gradle/
+
+# IDE
+.idea/
+.vscode/
+*.iml
+
+# OS
+.DS_Store
+
+# Node（前端分离场景）
+node_modules/
+dist/
+```
+
+> `.glaf4-dev/` 是 glaf4-dev 的 run 树（运行期基础设施，RUNS_REL 约定），必须 gitignore 避免污染版本库（v2.1 §6.5 实证：run 树在 target_root 下，不忽略会被 git add 跟踪）。
+
+## 创建动作（Step 5）
+
+```bash
+mkdir -p services/<svc>
+cd services/<svc>
+git init
+# 写入 .gitignore（如上模板）
+```
+
+创建后确认空目录 + git init + .gitignore 就绪，再进入 Step 6 委托。

package/skills/workflow-bootstrap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-bootstrap
-description: 既有项目接入初始化器。在首次使用 team-flow 时执行一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → 路径判断。完成后进入 workflow-orchestrator。不适用于：全新项目（无代码库，直接用 workflow-orchestrator）、已建立基线的项目（baseline.md 已存在）。
+description: 既有项目接入初始化器。在首次使用 team-flow 时执行一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → 路径判断。完成后进入 workflow-orchestrator。不适用于：全新项目（无代码库，直接用 workflow-orchestrator）、已建立基线的项目（baseline.md 已存在）。B1.5 提供全新项目骨架引导（交互式技术栈选择 + 可选骨架生成，被 project-initialize 非 glaf4 分支委托，2026-08-19）。
 ---
 
 # Workflow Bootstrap（既有项目接入初始化器，v0.6 新增）

package/skills/workflow-orchestrator/SKILL.md

@@ -68,23 +68,29 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 
 调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"）；原型循环由编排层直接编排（prototype skill 内部编排产出 → prototype-reviewer 自动评审 → 人工评审 → 冻结）；冻结语义为 `frozen_downstream`（迭代内变更不升版）。反馈环路检查点：scope 是否合理。详见 `references/s2-prd-prototype-loop.md`。
 
-### S3: 计划阶段
-**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `requirement/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。完成条件：plan.md 产出 + S3 状态 = completed，**下一步进 ARCH**（v0.36.0）。
-
-### ARCH: 产品级架构设计（v0.36.0 新增，S3 之后、S4 之前）
+### ARCH: 产品级架构设计（v0.36.0 新增；2026-08-19 LT 调整上移 S3 前——S3 计划/S4 拆分是最终任务拆分，须基于架构）
 
 **⛔ MANDATORY：执行 ARCH 阶段前，必须先读取 `references/state-model.md`「architecture 阶段」+ `architecture-design/references/s3.5-product-architecture.md`**
 
-产品级架构设计：基于迭代版本 vN 产出覆盖所有模块的整体详细架构（预测态快照，P1：只写快照不写全局）。
+产品级架构设计：基于迭代版本 vN 产出覆盖所有模块的整体详细架构（预测态快照，P1：只写快照不写全局）。**ARCH 在 S3 之前**——计划（S3）与拆分（S4）是最终任务拆分，必须基于架构定稿（聚合/服务/模块）进行。
 
 **场景判定（入口三态）**：全新项目 → 正向设计（首轮不可跳过）；旧项目首轮（`arch_baseline` 缺失）→ 逆向重建 L0 骨架 → 渐进深化；已建档 + 迭代无结构性变更 → 跳过（**skip 必须物化**：写 `docs/architecture/iterations/vN/SKIPPED` 标记 + 理由，判定者=编排器+用户确认）。
 
 **执行**：调用 architecture-design skill 的 **product 模式**子代理（8 步设计：限界上下文/聚合注册表/指令事件/状态机/概念 ER/时序），产出 `docs/architecture/iterations/vN/architecture.md`（6 产物，provenance 标注）。
 
-**评审门**：产出经 architecture-reviewer product 视角（`review_mode: product`，A1-A6）评审，**PASS 才进 S4**。
+**评审门**：产出经 architecture-reviewer product 视角（`review_mode: product`，A1-A6）评审，**PASS 才进 S3**。
 
 **输出契约**：`docs/architecture/iterations/vN/architecture.md` + 评审 verdict；`orchestrator.yaml` 中 ARCH phase 状态 = completed（`workflow_phase: architecture`）。**首轮项目（`arch_baseline` 缺失）评审 PASS 后执行 `tf arch init --mode reconstruction|design --baseline-ref requirement/vN/` 打戳**（v0.36.3）——arch 门禁豁免键由此建立，项目进入「已建档」正轨。
 
+**ARCH 后 Pre-check：服务初始化检测（v0.45.0 project-initialize 触发接入，场景①）**：评审 PASS 后、S3 计划前，检查架构设计涉及的服务是否已初始化——
+1. 从 `docs/architecture/iterations/vN/architecture.md`（聚合注册表/服务列表）提取本次迭代涉及的服务
+2. 检查工作空间是否有对应服务子目录 + 技术栈特征（pom.xml/package.json 等）
+3. 缺漏服务 → 提示用户：「架构设计涉及服务 X/Y/Z 尚未初始化，需要初始化对应项目代码吗？」确认后引导执行 `project-initialize` skill（架构选择 → 服务命名确认 → 创建空服务子目录 → 委托初始化）
+4. 已存在（未拉取）→ 提示用户 git pull/检出对应服务
+
+### S3: 计划阶段
+**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `requirement/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。**S3 在 ARCH 之后**——基于架构定稿（聚合/服务/模块）做计划与拆分（2026-08-19 LT 调整）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。完成条件：plan.md 产出 + S3 状态 = completed，**下一步进 S4**。
+
 ### S4: 拆分验证与分发
 
 **⛔ MANDATORY：执行S4阶段前，必须先读取 `references/s4-split-validate.md`**

package/skills/workflow-orchestrator/references/s3-plan-pipeline.md

@@ -42,10 +42,10 @@ ce-plan 在 orchestrator pipeline 上下文中减少仪式开销，但**保留
 
 - plan 是否暴露了 PRD 的范围问题？
   - **是** → 回退 S2，触发 PRD vN 内修订（记录变更原因）。详见 feedback-loops.md「S3 → S2」
-  - **否** → 进 ARCH（architecture 阶段，v0.35.0 产品级架构设计，见 state-model.md「architecture 阶段」）
+  - **否** → 完成 S3，进 S4（2026-08-19：ARCH 已上移 S3 前完成，S3 基于架构定稿——见 state-model.md「architecture 阶段」）
 
 ## 完成条件
 
 - `requirement/vN/plan.md` 已产出，含 change 拆分 + 依赖 DAG + 技术方向
 - `.team-flow/requirements/<req-id>/orchestrator.yaml` 中 S3 状态 = completed
-- 下一步：进入 ARCH 阶段，产出 `docs/architecture/iterations/vN/architecture.md` 后进 S4（v0.35.0）
+- 下一步：进 S4 拆分验证与分发（ARCH 已在 S3 前完成，产出 `docs/architecture/iterations/vN/architecture.md`，2026-08-19）

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

@@ -20,7 +20,7 @@
 
 进入拆分前先校验：
 
-- **项目 arch_baseline 缺失（存量/重建未完成）** → WARN 不阻断（reason: 'project architecture baseline not established — S3.5 reconstruction pending'），提示先跑 S3.5 重建产出 L0 骨架。
+- **项目 arch_baseline 缺失（存量/重建未完成）** → WARN 不阻断（reason: 'project architecture baseline not established — ARCH reconstruction pending'），提示先跑 ARCH（原名 S3.5）重建产出 L0 骨架。
 - **已建档项目** → 校验 `docs/architecture/iterations/vN/architecture.md` 存在且覆盖 plan.md 各 change 触及的全部 BC。不覆盖 → FAIL，回退 ARCH 阶段补快照（feedback-loops.md「S4 → ARCH」）。
 - **skip 物化**：ARCH 阶段显式跳过（iterations/vN/ 占位含 skipped 标记 + 理由）→ PASS。
 

package/skills/workflow-orchestrator/references/state-model.md

@@ -76,7 +76,7 @@ prd_version: v1                       # PRD 版本
 
 ## architecture 阶段（S3.5，v0.35.0 新增）
 
-> 产品级架构设计阶段，位于 S3 计划之后、S4 拆分之前。设计依据：设计增强方案 v0.14 §59。
+> 产品级架构设计阶段。**2026-08-19 调整：位于 S2 之后、S3 计划之前**（ARCH 上移，S3 计划/S4 拆分是最终任务拆分须基于架构；原" S3 计划之后、S4 拆分之前"历史位置）。设计依据：设计增强方案 v0.14 §59。
 
 **phase id**：`ARCH`；顶层 `workflow_phase: architecture`（语义 kebab-case）。
 **命名约定**：新阶段一律用 kebab-case 语义名（历史值保留不迁移，避免无价值 churn）。
@@ -110,7 +110,7 @@ phases:
 **门禁**（v0.14 §59.4）：
 | 门禁 | 挂点 | 校验 | 豁免 |
 |------|------|------|------|
-| 产品级评审门 | ARCH→S4 | architecture-reviewer product 视角 PASS | skip 时仍要物化标记 |
+| 产品级评审门 | ARCH→S3（2026-08-19：ARCH 上移 S3 前，原 ARCH→S4） | architecture-reviewer product 视角 PASS | skip 时仍要物化标记 |
 | arch-readiness | exploring:specifying（guard 存在性）+ S4 拆分（LLM 覆盖校验） | iterations/vN/ 快照覆盖 change 触及的 BC | arch_baseline 缺失 → WARN 不 FAIL |
 | arch-snapshot | executing→closing | 本轮快照已落盘 | 在途 change legacy 豁免 |
 

package/skills/workflow-start/SKILL.md

@@ -88,7 +88,13 @@ Full protocol in `references/routing-rules.md`「Route to architecture-design」
 Guard: `tf runtime guard check <dir> exploring specifying --json` → fail = BLOCK. **arch_design_decision must not be null** → fail = BLOCK (v0.9 §26). User knows what they want, artifacts missing/incomplete.
 
 ### Route to contract-builder (dispatch sub-agent)
-Guard: `... check <dir> specifying bridging --json` → fail = BLOCK. Artifacts exist, implementation requested, contract missing/stale. Include `DP-3: 契约批准`. **full workflow 必产 test-matrix.md（v0.13 §52 B1）**：契约 `## Test Matrix` 段 + 非空矩阵文件 + `tf state rebuild` 捕获 hash；确无测试需求只能显式 skip + 理由（`test_matrix_skipped=true` + `test_matrix_skip_reason`）。GLAF4 Java 项目矩阵生成的工具选择见 `references/routing-rules.md`「Route to glaf4-tests」。
+Guard: `... check <dir> specifying bridging --json` → fail = BLOCK. Artifacts exist, implementation requested, contract missing/stale. Include `DP-3: 契约批准`. **full workflow 必产 test-matrix.md（v0.13 §52 B1）**：契约 `## Test Matrix` 段 + 非空矩阵文件 + `tf state rebuild` 捕获 hash；确无测试需求只能显式 skip + 理由（`test_matrix_skipped=true` + `test_matrix_skip_reason`）。GLAF4 Java 项目实施委托（glaf4-dev）与矩阵工具选择见 `references/routing-rules.md`「Route to glaf4-dev 实施委托」。
+
+### Route 前 Pre-check：服务缺漏检测（v0.45.0 project-initialize 触发接入，场景②；位置 = contract-builder 后、DP-4 前）
+
+dispatch build-executor 前，检查 change 涉及的服务是否在工作空间存在：从 design.md/specs 涉及的 target 类提取所属服务，检查服务子目录 + 技术栈特征（pom.xml/package.json 等）。**缺漏 → AskUserQuestion 确认**：
+- **「未拉取」**：服务已存在于远端/其他分支 → 提示 git pull/检出对应服务后继续
+- **「需要初始化」**：全新服务 → 引导 `project-initialize` skill（架构选择 → 服务命名确认 → 创建空服务子目录 → 委托初始化骨架），完成后回 change 继续
 
 ### Route to build-executor (dispatch sub-agent)
 Contract exists and approved, contract matches artifacts. Include `DP-4: 执行模式选择`: propose waves, run `tf execution recommend <change-dir> [--wave ...]`, show the user every available mode plus evidence and the recommendation, then obtain a clear selection. The command saves a current receipt; before the first implementation edit, `build-executor` must run `tf execution plan <change-dir> --mode <selected> --confirm ...` (and `--acknowledge-recommendation` when the selected mode differs from the recommendation) using matching artifacts, contract, and waves, then `tf execution show <change-dir> --json`; report the saved revision, selected mode, recommendation alignment, ordered waves, and actual concurrent-dispatch capability. A revision must repeat recommend and confirmation. Do not transition to `executing` until `show` reports `current: true`; then run `... check <dir> approved-for-build executing --json` → fail = BLOCK. **v0.13 §49 门禁前移**：该 guard 含 `test-matrix-ready` 维度——full 模式非存量 change 必须"带着矩阵开工"（矩阵存在非空 OR 显式 skip 附理由）；FAIL 时回 bridging 让 contract-builder 补矩阵，或按指引显式 skip，禁止绕过。

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

@@ -313,23 +313,23 @@ Inference: **hotfix** (≤2 tasks, ≤2 files, no schema/API/new modules), **twe
 ## Post-transition
 💡 `tf inject <change-dir>` to update phase-guard artifacts.
 
-## Route to glaf4-tests (v0.12 §46, v0.31.0, v0.13 §52 B3 归位)
+## Route to glaf4-dev 实施委托 (v0.12 §46, v0.31.0, v0.13 §52 B3 归位; v2.1 §1.3 统一到 glaf4-dev)
 
-**归位说明（v0.13）**：本段的触发主体是 **bridging 阶段的 contract-builder 子代理**（矩阵生成者），workflow-start 主路由表不包含 glaf4-tests 条目——放在本文件仅作 bridging 期参考。
+**归位说明**：本段的触发主体是 **bridging 阶段的 contract-builder 子代理**（矩阵生成者 + GLAF4 Delegation 段产出者）。glaf4-test 已统一到 glaf4-dev（v2.1 §1.3），矩阵设计委托改为 glaf4-dev 实施委托全链路。
 
-**强制性澄清（v0.13 §52 B1）**：full workflow 生成 test-matrix.md 本身是**必选动作**（`test-matrix-ready`/`test-matrix-complete` 门禁强制）；**可选的是工具选择**——GLAF4 Java 项目可选用 glaf4-tests 流水线做精细矩阵设计，非 GLAF4 项目用内置 test-strategy skill。两条路都必须产出非空 `test-matrix.md` + contract `## Test Matrix` 段 + `tf state rebuild`。
+**强制性澄清（v0.13 §52 B1 + v2.1）**：full workflow 生成 test-matrix.md 本身是**必选动作**（`test-matrix-ready`/`test-matrix-complete` 门禁强制）；GLAF4 Java change 走 glaf4-dev 实施委托（生产+测试整体委托七模式流），team-flow 矩阵骨架定位为**审计基线**（回灌后对比 vNext 覆盖）。
 
-**触发条件**：`project_type == glaf4-java`（Spring Boot / JUnit 5 / Mockito）。
+**触发条件**：`project_type == glaf4-java`（pom.xml/build.gradle + Spring Boot/JUnit5/Mockito）∧ glaf4-dev 插件可用（运行时探测 delegation_mode ≠ off）。
 
 **协议**：
-1. contract-builder 检测项目技术栈（读取 `pom.xml` / `build.gradle` 判断是否 GLAF4 Java）
-2. GLAF4 项目 → 提示用户：「检测到 GLAF4 Java 项目，是否调用 `glaf4-test:glaf4-tests` 做精细测试矩阵设计？」
-3. 用户同意 → 调用 `glaf4-test:glaf4-tests-design` 生成 `test-matrix.json`
-4. `glaf4-tests-validate` 校验矩阵完整性
-5. `tf test-matrix-export <test-matrix.json> <change-dir>/test-matrix.md` 转换为 team-flow 格式
-6. 用户确认（轻量版 DP-A）
-7. contract 中添加 `## Test Matrix` 段引用 + `tf state rebuild` 捕获 test_matrix_hash
+1. contract-builder 运行时探测（`detectGlaf4Delegation`，v2.1 §4）
+2. 命中 GLAF4 Java → 产出 `## GLAF4 Delegation` 段（mode + write_set_boundary + 权限位，v2.1 §6.1/§6.2），**实施委托交接**——完整协议见 contract-builder `references/glaf4-delegation.md`
+3. 委托 run 回灌 → `tf test-matrix-export`（v2，支持 vNext）转 team-flow 12 列 MD 作为**审计基线**（v2.1 §5）
+4. 证据回灌：`tf glaf4-evidence-export` → `tf test record --from`（v2.1 §7）
+5. `tf glaf4-delegation confirm`（DP-4 委托确认 5 项）+ `verify-write-set`/`verify-tasks`（双层对账，v2.1 §6.3/§6.6）
+
+**混合栈串行承接（v2.1 §6.8，L1 明确）**：委托仅限 Java 文件边界（src/main/**、src/test/** 的 Java 面）；change 内非 Java 文件（SQL DDL / src/main/resources / 前端）由 build-executor 在委托 run 终局后、closing 前**串行承接**（S1 单 wave 计划不新增 wave）。这是与 glaf4-dev 租约模型唯一兼容的选项——委托 run 期间主线程零写入，非 Java 承接必须在 run 终局释放租约后。
 
 **非 GLAF4 项目**：contract-builder 使用预加载的 test-strategy skill 直接生成 `test-matrix.md`（同等强制）。
 
-**用户拒绝 glaf4-tests 时**：回退内置 test-strategy 生成（不是跳过矩阵）。确无测试需求的特例走显式 skip + 理由。
+**委托不可用（glaf4-dev 未装 / delegation_mode=off / 用户拒绝）**：回退 build-executor 实施 + 内置 test-strategy 生成矩阵（不是跳过矩阵）。**两类 skip 区分**：① 委托路径（glaf4-delegation 模式）矩阵是审计基线，`test_matrix_skipped` 被禁止（v2.1 §6.3 skip 禁令，唯一例外 TEST_BOOTSTRAP 零测试）；② 非委托路径确无测试需求（纯文档/纯配置）才走显式 skip + 理由（v0.13 §48.2 可审计豁免）。

package/templates/execution-contract.md

@@ -69,13 +69,25 @@ wave 才可以开始。`parallel` 只表示允许在宿主支持并发派发时
 ## Execution Mode
 
 - **可用方式与推荐**：`tf execution recommend <change-dir> [--wave <id>:<parallel|serial>:<task,...>[:<depends-on,...>]]`
-- **用户确认的模式**：`sdd` | `inline` | `batch-inline`
+- **用户确认的模式**：`sdd` | `inline` | `batch-inline` | `glaf4-delegation`
 - **推荐理由 / 项目事实**：
 - **非推荐选择的风险确认**：`--acknowledge-recommendation`（若适用）
 - **执行计划命令**：`tf execution plan <change-dir> --mode <mode> --confirm --reason <text> --wave <id>:<parallel|serial>:<task,...>[:<depends-on,...>] [--acknowledge-recommendation]`
 - **允许的修订**：将已有计划保留/升级为 `sdd`；先重新 recommend，并以 `--confirm` 生成新 revision 和清除旧 receipt；不允许降级：`tf execution revise <change-dir> --mode sdd --confirm --reason <text> --wave <id>:<parallel|serial>:<task,...>[:<depends-on,...>] [--acknowledge-recommendation]`
 - **计划 revision / artifact hash**：
 
+## GLAF4 Delegation（v2.1 §6.1/§6.2，GLAF4 Java change 实施委托时填写）
+
+> 运行时探测（`tf glaf4-delegation detect <root>`）命中 GLAF4 Java 且 glaf4-dev 可用时产出本段。write_set_boundary 权威源 = 本段；机械对账读 `.superpowers/glaf4/write-set.json`（`tf glaf4-delegation confirm` 写入）。
+
+- mode: FEATURE_TDD | BUGFIX_REGRESSION | REFACTOR_PROTECTED | COMPLETE_UNIT_TESTS | COMPLETE_INTEGRATION_TESTS | TEST_BOOTSTRAP
+- permission: after-red | none(test-only) | allowed+baseline_green_required
+- write_set_boundary:
+  - <相对 target_root 的 Java 文件路径，如 src/main/java/com/example/OrderService.java>
+- target_root: <工程根绝对路径>
+- delegation_mode: auto | manual | off
+- glaf4_dev_version: <运行时探测的插件版本，如 0.3.0>
+
 ## Verification Dimensions
 
 | 维度 | 状态 | 发现 |