@xulthekl/team-flow 0.40.1 → 0.42.0

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

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

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "team-flow",
       "description": "8-state spec workflow + compound global compounding + architecture-design (4A/DDD) + local HTML prototype + product-level orchestration + bootstrap + e2e + session handoff + workflow feedback. 24 skills + 15 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.40.1",
+      "version": "0.42.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.40.1",
+  "version": "0.42.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). 24 skills + 15 agents, one install.",
   "source": "./",
   "author": {

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.40.1",
+  "version": "0.42.0",
   "description": "Spec-first workflow that bridges OpenSpec-style planning and Superpowers-style execution discipline.",
   "author": {
     "name": "MageByte",

package/.cursor-plugin/marketplace.json

@@ -5,7 +5,7 @@
   },
   "metadata": {
     "description": "Unified workflow plugin marketplace for Cursor (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.40.1"
+    "version": "0.42.0"
   },
   "plugins": [
     {

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "team-flow",
   "displayName": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 24 skills + 15 agents, one install.",
-  "version": "0.40.1",
+  "version": "0.42.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.40.1"
+    "version": "0.42.0"
   },
   "plugins": [
     {
       "name": "team-flow",
       "description": "Unified workflow with planning artifacts, execution contracts, TDD, review gates, systematic debugging, delta spec sync, architecture-design, and local HTML prototyping.",
-      "version": "0.40.1",
+      "version": "0.42.0",
       "source": ".",
       "author": {
         "name": "LT",

package/AGENTS.md

@@ -68,8 +68,9 @@ spec 驱动开发过程。8 态变更机：`exploring → specifying → bridgin
 - 与 workflow-start 分层：orchestrator 管"做什么、什么顺序"（产品级策略），workflow-start 管"怎么做"（变更级执行）
 
 ### 7. workflow-bootstrap（1 skill，既有项目接入，v0.15.0 脚本+子代理侦察）
-- 一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → 进入 workflow-orchestrator
-- **B1 侦察（v0.15.0）**：先跑确定性脚本 `scripts/recon-probe.sh`（可复现固定化采集）→ 并行派发 `codebase-recon-analyst` 子代理语义增强 → 主代理汇总写 baseline.md
+- 一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → CLAUDE.md 初始化（B4.5，v0.41.0）→ 进入 workflow-orchestrator
+- **B1 侦察（v0.15.0）**：先跑确定性脚本 `scripts/recon-probe.sh`（可复现固定化采集，含 Git 子仓库结构 v0.41.0）→ 并行派发 `codebase-recon-analyst` 子代理语义增强（7 维度含 git-structure）→ 主代理汇总写 baseline.md（维度闭合校验 v0.41.0）
+- **B5 路径决策（v0.42.0 降级路径设计）**：两组选项——第一组确保产物可信（A 逆向重建按复杂度分级推荐 / B 交叉验证主代理比对产出 cross-check-report.md / C 真实性核对用户确认门），第二组直接进入流程（D-F 原 A-C 平移）
 - 仅首次使用时执行；`docs/architecture/baseline.md` 已存在则跳过
 
 ### 8. session-handoff（1 skill，会话交接，v0.16.0 新增）

package/CHANGELOG.md

@@ -6,6 +6,25 @@ The format loosely follows Keep a Changelog.
 
 ## [Unreleased]
 
+### Added（workflow-bootstrap B5 降级路径设计 + session-start 语言要求，v0.42.0）
+
+- **B5 路径决策重构（降级路径设计）**：4 平权选项 → 两组降级选项——第一组确保产物可信（A 逆向重建按复杂度分级推荐（≥5 模块或 ≥10 源文件强推）/ B 交叉验证主代理机械比对产出 cross-check-report.md / C 真实性核对用户确认门），第二组直接进入流程（D-F 原 A-C 平移）
+- **references/b5-path-decision.md（新建）**：B5 详细流程（分组展示模板、A 复杂度判据、B 比对清单 + 维度覆盖说明（architecture 显式排除理由）、C 两种模式核对协议（跟随 B / 独立抽查））
+- **b1-reconnaissance.md Success Output 同步**：产出清单增加 cross-check-report.md + 重建建议
+- **hooks/session-start 语言要求**：Inject workflow context 的 msg 追加 `## Language` 指令——要求中文交流，技术术语/代码/命令保持英文
+- **AGENTS.md 同步**：workflow-bootstrap 描述补 B5 降级路径
+
+## [0.41.0] - 2026-08-07
+
+### Added（workflow-bootstrap CLAUDE.md 初始化 + Git 多子仓库识别）
+
+- **B4.5 CLAUDE.md 初始化**（参考 Claude Code /init）：将项目基本信息（项目概况/开发命令/工作区结构/Git 结构）+ team-flow 产物结构索引写入工作区 CLAUDE.md；维护原则=索引级+结构级；已有 CLAUDE.md 追加模式（产物结构 + Git 管理规则章节），无则从 `templates/claude-md-team-flow.md` 新建
+- **CLAUDE.md 标准模板**：`skills/workflow-bootstrap/templates/claude-md-team-flow.md`（新建），覆盖 /init 内容 + team-flow 产物结构表（代码强制 + 设计层面）
+- **recon-probe.sh ⑧ Git 子仓库扫描**：识别嵌套 git 仓库 / submodule / .gitignore 忽略规则，JSON 新增 `git_structure` 字段（is_git_repo / sub_repos[{path,type,has_remote}] / submodules / gitignore_ignores_subrepos）
+- **codebase-recon-analyst git-structure 维度**：侦察维度 6→7，识别子仓库用途（代码库/文档/工具）+ git 操作约束（提交/推送顺序、版本联动、隔离）
+- **B1.3 维度闭合校验**：汇总前核对已派发维度 vs 已返回 handoff（status + deliverable 非空），缺失维度标 INCOMPLETE（advisory 不阻断，Success Output 警告）
+- **AGENTS.md 同步**：workflow-bootstrap 流程描述补 B4.5 + git-structure + 闭合校验
+
 ## [0.39.0] - 2026-08-06
 
 ### Added（workflow-feedback 环境版本记录）

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

package/README.md

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

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.40.1`
+- Current: `v0.42.0`
 - v0.9.1 highlights: DP-4 execution-mode recommendations, a portable runtime across 17 platforms, and a raw-package smoke with no plugin-root variable.
 - Self-contained — no OpenSpec or Superpowers runtime required
 - Upstream: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec), [obra/superpowers](https://github.com/obra/superpowers)

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev) + compound-engineering core subset + architecture-design (4A/DDD) + prototype (local HTML). 24 skills, one install.",
-  "version": "0.40.1",
+  "version": "0.42.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.40.1: auto-sync CLI version with plugin version
+# v0.42.0: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.40.1"
+PLUGIN_VERSION="0.42.0"
 
 # ═══════════════════════════════════════════════════════════════
 # Step 1: Auto-sync CLI version with plugin version
@@ -45,7 +45,7 @@ sync_tf_version
 # Step 2: Inject workflow context
 # ═══════════════════════════════════════════════════════════════
 
-msg="<EXTREMELY_IMPORTANT>\nYou have team-flow installed. Invoke /team-flow:workflow-start or /team-flow:workflow-orchestrator ONLY when active team-flow artifacts exist (\`.team-flow.yaml\`, \`proposal.md\`, \`execution-contract.md\`, \`specs/\`) or the user explicitly requests it. For ordinary coding tasks, do NOT invoke them.\n</EXTREMELY_IMPORTANT>\n<EXTREMELY_IMPORTANT>\n## Workspace Directory Rule\n\"Base directory for this skill\" = skill source location (read SKILL.md/references/ ONLY). User project = \`pwd\`. ALL project artifacts (changes/, prd/, docs/, .team-flow/, etc.) MUST operate under \`pwd\`, NEVER the skill base directory. Run \`pwd\` first in every skill execution.\n</EXTREMELY_IMPORTANT>"
+msg="<EXTREMELY_IMPORTANT>\nYou have team-flow installed. Invoke /team-flow:workflow-start or /team-flow:workflow-orchestrator ONLY when active team-flow artifacts exist (\`.team-flow.yaml\`, \`proposal.md\`, \`execution-contract.md\`, \`specs/\`) or the user explicitly requests it. For ordinary coding tasks, do NOT invoke them.\n</EXTREMELY_IMPORTANT>\n<EXTREMELY_IMPORTANT>\n## Workspace Directory Rule\n\"Base directory for this skill\" = skill source location (read SKILL.md/references/ ONLY). User project = \`pwd\`. ALL project artifacts (changes/, prd/, docs/, .team-flow/, etc.) MUST operate under \`pwd\`, NEVER the skill base directory. Run \`pwd\` first in every skill execution.\n</EXTREMELY_IMPORTANT>\n<EXTREMELY_IMPORTANT>\n## Language\nCommunicate with the user in Chinese (中文). Technical terms, code, and commands remain in English.\n</EXTREMELY_IMPORTANT>"
 
 # Three platforms share the same message, only output format differs.
 if [ -n "${CURSOR_PLUGIN_ROOT:-}" ]; then

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.40.1.
+Current version: v0.42.0.
 
 ## Key Documents
 - README.md: Chinese homepage with full usage guide and FAQ

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.40.1",
+  "version": "0.42.0",
   "description": "Unified plugin (24 skills + 15 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback for multi-agent coding tools.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.40.1",
+  "version": "0.42.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). 24 skills + 15 agents, one install.",
   "author": {
     "name": "LT"

package/skills/workflow-bootstrap/SKILL.md

@@ -11,7 +11,8 @@ description: 既有项目接入初始化器。在首次使用 team-flow 时执
 
 ```
 workflow-bootstrap（一次性，手动触发）
-  → B1 代码库侦察 → B2 架构基线 → B3 领域词汇 → B4 目录初始化 → B5 路径判断
+  → B1 代码库侦察 → B1.5 conventions → B2 架构基线 → B3 领域词汇 → B4 目录初始化
+  → B4.5 CLAUDE.md 初始化 → B5 路径判断
   → 进入 workflow-orchestrator S1（注入 baseline 上下文）
 ```
 
@@ -58,7 +59,7 @@ Do NOT invoke for:
 - **模式**（询问用户）：Quick（默认，技术栈+模块+架构模式+测试文档，~2 分钟）/ Deep（+数据模型+API 表面，~10 分钟）。
 - **B1.1 脚本采集**：`bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --root <根> --out /tmp/recon-<slug>.json`（固定化，两次接入结果一致）。
 - **B1.2 并行子代理**：读 `references/agents/codebase-recon-analyst.md`，把 JSON 路径作 `recon_json` 入参，按维度并行派发（§18.1 返回）。
-- **B1.3 主代理汇总**：只汇总不重新侦察，整合已有文档（合并而非覆盖，标注来源），写 `docs/architecture/baseline.md`。
+- **B1.3 主代理汇总**：只汇总不重新侦察，整合已有文档（合并而非覆盖，标注来源），写 `docs/architecture/baseline.md`。**维度闭合校验（v0.41.0）**：汇总前核对已派发维度 vs 已返回 handoff（status 非未返回 + deliverable 非空），缺失维度在 baseline.md 顶部标记 INCOMPLETE（advisory 不阻断，Success Output 警告）。
 
 详细流程（脚本采集项、子代理维度表、侦察内容树、已有文档处理）见 `references/b1-reconnaissance.md`。
 
@@ -185,15 +186,48 @@ Step 2: 确定性提取（兜底）
 
 创建 team-flow 目录结构：`mkdir -p prd/ prototype/ docs/architecture/ docs/solutions/ changes/`。已有目录不覆盖不删除，只补缺失；目录中有文件保留不改。**Discoverability 检查**：若 `AGENTS.md`/`CLAUDE.md` 未暴露 `docs/architecture/` 和 `prototype/`，advisory 建议用户添加（不自动改）。
 
-### B5: Path Decision（路径判断）
+### B4.5: CLAUDE.md 初始化（v0.41.0 新增，参考 Claude Code /init）
 
-询问用户：
+将项目基本信息（参考 /init）和 team-flow 产物索引写入工作区 CLAUDE.md。维护原则：**索引级 + 结构级，简明扼要**——目标是每次开启会话对项目空间有全局认识，不长篇大论。
 
-> 您希望从哪个需求开始使用 team-flow？
-> - A) 我有一个具体的功能需求（→ 进入 workflow-orchestrator S1，S3 后进 ARCH 产品级架构设计）
-> - B) 我有一个模糊的产品方向（→ ce-brainstorm）
-> - C) 我只是想建立架构基线，暂不开发新需求（→ 结束）
-> - D) 我想从既有代码逆向重建完整架构（→ 进入 workflow-orchestrator ARCH 阶段 reconstruction 模式，arch-reverse-analyst，v0.36.0；重建 PASS 后 `tf arch init` 打戳）
+**触发条件**：CLAUDE.md 存在但不含 `## 产物结构` 章节（追加模式），或不存在（新建模式）。
+
+**执行流程**：
+
+1. 检查 CLAUDE.md 是否已存在
+2. **不存在（新建模式）**：从 `templates/claude-md-team-flow.md` 复制模板，填入 B1 侦察结果：
+   - 项目概况（语言/框架/构建工具/数据库，2-3 行）← B1 technology 维度
+   - 开发命令（构建/测试/lint，只列非标准的）← B1 侦察 + README
+   - 工作区结构（简化目录树 ≤3 层）← B1 directory_tree
+   - Git 仓库结构（子仓库清单 + 类型 + 用途）← B1 git-structure 维度
+   - 产物结构（索引级：产物表 + 路径，详细内容引用 baseline.md）← 标准化模板
+   - Git 管理规则（提交/推送顺序约束 + 子仓库操作规则）← 标准化框架
+3. **已存在（追加模式）**：检查是否含 `## 产物结构` 章节
+   - 含 → 跳过（不覆盖用户已有内容）
+   - 不含 → 追加产物结构索引章节；**仅当缺 `## Git 管理规则` 时**一并追加，避免重复章节
+4. 若模板有占位符未填（如侦察缺失的维度），保留 `{{PLACEHOLDER}}` 并提示用户补充
+
+**不做的事**：不写 SOP 流程（由 skill 负责）、不写变更级状态机（由 workflow skill 负责）、不列可自动发现的文件清单。
+
+### B5: Path Decision（路径判断，v0.42.0 重构：降级路径设计）
+
+询问用户。**分组展示**——用户先决定"要不要把地基打牢"（第一组），再决定"打完地基做什么"（第二组）：
+
+> **第一组：确保 bootstrap 产物可信**
+> - A) 逆向重建完整架构（**复杂项目强推 / 简单项目弱推**；→ 进入 workflow-orchestrator ARCH 阶段 reconstruction 模式，arch-reverse-analyst，重建 PASS 后 `tf arch init --mode reconstruction --baseline-ref prd/vN/` 打戳，全量命令见 b5-path-decision.md）
+> - B) 交叉验证与对齐 bootstrap 产物（→ 主代理机械比对，产出 `docs/architecture/cross-check-report.md` 疑点清单）
+> - C) 真实性核对（→ 针对 B 疑点清单（跟随 B）或 baseline.md 语义结论抽查（独立），用户逐条确认，修正 baseline.md）
+>
+> **第二组：直接进入 team-flow 流程**
+> - D) 我有一个具体的功能需求（→ 进入 workflow-orchestrator S1，S3 后进 ARCH 产品级架构设计）
+> - E) 我有一个模糊的产品方向（→ ce-brainstorm）
+> - F) 我只是想建立架构基线，暂不开发新需求（→ 结束）
+
+**A 分级推荐判据**（基于 B1 侦察结果）：
+- 复杂项目（≥5 模块 或 ≥10 源文件，复用 B2 触发判据）→ 提示"建议优先重建完整架构"
+- 简单项目（<5 模块 且 <10 源文件）→ 提示"项目较简单，可直接进入流程，重建为可选项"
+
+**B/C 串联闭环**：选 B → 主代理产出疑点清单 → 提示是否进入 C（是 → 逐条 AskUserQuestion 核对并修正 baseline.md；否 → 疑点留档标记 deferred，不阻断）。
 
 **逆向重建衔接（v0.36.3）**：ARCH 阶段 reconstruction 模式复用本 bootstrap 的 recon-probe.sh（--ddl-out）+ codebase-recon-analyst，并派发 `arch-reverse-analyst` 补 BC/状态/指令事件维度（见 `references/agents/arch-reverse-analyst.md`）。
 
@@ -201,6 +235,8 @@ Step 2: 确定性提取（兜底）
 - 将 `docs/architecture/baseline.md` 和 `docs/architecture/CONCEPTS.md` 的路径传递给 workflow-orchestrator S1
 - 作为后续流程的架构上下文
 
+详细流程（分组展示模板、A 复杂度判据来源、B 7 类比对清单 + report 格式、C 核对协议）见 `references/b5-path-decision.md`。
+
 ## Guardrails
 
 - **一次性**：bootstrap 只在首次接入时执行。如果 `docs/architecture/baseline.md` 已存在，提示用户"基线已建立，是否要重新侦察？"
@@ -213,10 +249,10 @@ Step 2: 确定性提取（兜底）
 ## Output Standard
 
 每次交互结束时说明：
-1. 已完成的阶段（B1-B1.5-B2-B3-B4-B5）
-2. 已产出的制品（baseline.md / conventions / ARCHITECTURE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / CONCEPTS.md / 目录结构）
+1. 已完成的阶段（B1-B1.5-B2-B3-B4-B4.5-B5）
+2. 已产出的制品（baseline.md / conventions / ARCHITECTURE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / CONCEPTS.md / CLAUDE.md / cross-check-report.md（如执行 B）/ 目录结构）
 3. 下一步建议（调用哪个 skill）
 
 ## Success Output
 
-接入结束时输出：侦察模式、产出清单（baseline.md / conventions / ARCHITECTURE.md / DATABASE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / docs/architecture/CONCEPTS.md / 目录结构）、关键发现（技术栈/模块数/架构模式/测试覆盖）、下一步建议。完整模板见 `references/b1-reconnaissance.md`「Success Output 模板」。
+接入结束时输出：侦察模式、产出清单（baseline.md / conventions / ARCHITECTURE.md / DATABASE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / docs/architecture/CONCEPTS.md / CLAUDE.md / cross-check-report.md（如执行 B）/ 目录结构）、关键发现（技术栈/模块数/架构模式/测试覆盖）、下一步建议。完整模板见 `references/b1-reconnaissance.md`「Success Output 模板」。

package/skills/workflow-bootstrap/references/agents/codebase-recon-analyst.md

@@ -1,6 +1,6 @@
 **Note: The current year is 2026.** Use this when assessing framework versions and recency.
 
-You are an expert codebase reconnaissance analyst. You are dispatched by the `workflow-bootstrap` skill (B1 阶段) as one of several parallel recon subagents. Your mission is to take the **deterministic JSON baseline** produced by `recon-probe.sh` and enrich it with targeted source reads into a **structured summary for ONE reconnaissance dimension** (technology stack / module structure / architecture pattern / data model / API surface / test & docs). The bootstrap orchestrator aggregates all dimension summaries into `docs/architecture/baseline.md`.
+You are an expert codebase reconnaissance analyst. You are dispatched by the `workflow-bootstrap` skill (B1 阶段) as one of several parallel recon subagents. Your mission is to take the **deterministic JSON baseline** produced by `recon-probe.sh` and enrich it with targeted source reads into a **structured summary for ONE reconnaissance dimension** (technology stack / module structure / architecture pattern / data model / API surface / test & docs / git structure). The bootstrap orchestrator aggregates all dimension summaries into `docs/architecture/baseline.md`.
 
 You do the **semantic** judgment (what architecture pattern this is, which class is an aggregate-root candidate). The mechanical collection (file counts, dependency lists, LOC) already comes from the script — do not re-run it by hand, consume its output.
 
@@ -26,11 +26,12 @@ When the input begins with `Scope:` followed by a comma-separated list, run only
 | `data-model` | 数据模型（实体/迁移/聚合根候选） | Data Model | — | ✓ |
 | `api-surface` | API 表面（REST/gRPC/CLI） | API Surface | — | ✓ |
 | `test-docs` | 测试现状 + 已有文档 | Test & Docs | ✓ | ✓ |
+| `git-structure` | Git 仓库结构（子仓库/submodule） | Git Structure | ✓ | ✓ |
 
 **Scoping rules:**
 - Multiple scopes combine: `Scope: technology, modules, architecture` runs three dimensions.
-- No `Scope:` prefix → run all six (full recon).
-- `mode` interaction: in **Quick** mode the orchestrator only dispatches `technology / modules / architecture / test-docs`; in **Deep** mode it also dispatches `data-model / api-surface`. If you receive a `data-model` or `api-surface` scope but `mode: Quick`, note the mismatch as an outstanding question and proceed (the orchestrator decides modes).
+- No `Scope:` prefix → run all seven (full recon).
+- `mode` interaction: in **Quick** mode the orchestrator only dispatches `technology / modules / architecture / test-docs / git-structure`; in **Deep** mode it also dispatches `data-model / api-surface`. If you receive a `data-model` or `api-surface` scope but `mode: Quick`, note the mismatch as an outstanding question and proceed (the orchestrator decides modes).
 
 ## Methodology
 
@@ -73,6 +74,12 @@ Read `recon_json` first. It gives you, mechanically: directory tree (depth-limit
 - Read README/ARCHITECTURE only to extract facts the bootstrap should merge (do NOT overwrite — bootstrap merges existing docs).
 - Output: test framework + coverage signal + doc inventory (path + one-line content note). Tag each fact's source: `代码分析` vs `原有文档`.
 
+### Dimension: git-structure（Git 仓库结构）
+
+- From the baseline's `git_structure` section, identify: root repo status (`is_git_repo`), nested sub-repos (path + type + has_remote), configured submodules, `.gitignore` ignore rules for sub-repos.
+- This is a **mechanical** dimension — the script already collected the facts; your job is **semantic enrichment**: infer each sub-repo's usage (代码库/文档/工具/配置/共享库), and flag git operation constraints (提交/推送顺序、版本联动、.gitignore 隔离).
+- Output: sub-repo inventory (path + type + usage + remote) + git operation constraints that downstream workflows must respect.
+
 ## Output Format
 
 Produce only the sections for the scopes you ran:
@@ -97,6 +104,9 @@ Produce only the sections for the scopes you ran:
 
 ### Test & Docs             # if test-docs in scope
 - Test framework + coverage signal + doc inventory (with source tag)
+
+### Git Structure           # if git-structure in scope
+- Sub-repo inventory (path + type + usage + remote) + git operation constraints
 ```
 
 Cite concrete paths (repo-relative) for every non-trivial claim. Distinguish what came from the mechanical baseline vs. what you inferred by reading source.

package/skills/workflow-bootstrap/references/b1-reconnaissance.md

@@ -13,7 +13,7 @@
 bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --root <项目根> --out /tmp/recon-<slug>.json
 ```
 
-固定采集（不依赖 LLM，两次接入结果一致）：目录树（限深 4 层）、依赖清单（pom/package.json/requirements/go.mod/build.gradle）、LOC 与文件类型分布、测试文件计数（含 `.test.mjs`/`.spec.mjs`）、DB 迁移文件清单、README/docs 探测。输出结构化 JSON 供子代理消费。脚本只做确定性机械采集（§17.8 第四类载体），语义判断交给子代理 LLM。
+固定采集（不依赖 LLM，两次接入结果一致）：目录树（限深 4 层）、依赖清单（pom/package.json/requirements/go.mod/build.gradle）、LOC 与文件类型分布、测试文件计数（含 `.test.mjs`/`.spec.mjs`）、DB 迁移文件清单、README/docs 探测、Git 子仓库结构（v0.41.0：嵌套仓库/submodule/.gitignore 忽略规则）。输出结构化 JSON 供子代理消费。脚本只做确定性机械采集（§17.8 第四类载体），语义判断交给子代理 LLM。
 
 ## B1.1a DDL 提取能力（v0.23.0 设计，v0.24.0 已实现）
 
@@ -42,6 +42,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 | 模块结构（分层/边界） | ✓ | ✓ |
 | 已有架构模式（DDD/MVC/微服务/单体） | ✓ | ✓ |
 | 测试现状 + 已有文档 | ✓ | ✓ |
+| Git 仓库结构（子仓库/submodule） | ✓ | ✓ |
 | 数据模型（实体/迁移/聚合根候选） | — | ✓ |
 | API 表面（REST/gRPC/CLI） | — | ✓ |
 
@@ -51,6 +52,18 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 
 主代理收集各子代理摘要 + 脚本 JSON，**只汇总不重新侦察**，整合已有文档（见下），写 `docs/architecture/baseline.md`。
 
+**维度完整性校验（v0.41.0 新增）**：汇总前必须执行闭合校验，防止静默丢失维度：
+
+```
+1. 核对已派发维度 vs 已返回 handoff（status != 未返回）
+2. 每个返回的 handoff 检查 deliverable 字段非空
+3. 缺失维度 → 在 baseline.md 顶部标记 INCOMPLETE + 缺失维度名
+4. 缺失维度不阻断流程（advisory），但 Success Output 中必须警告
+5. blocked / outstanding_questions 按 §18.1 交接协议由主代理裁决 / 批量确认
+
+假设：deliverable 非空按"该维度已覆盖"计；blocked 但带部分交付的，由主代理人工裁决是否归账。
+```
+
 ## 侦察内容维度（子代理产出，供 baseline.md 组织）
 
 ```
@@ -60,7 +73,8 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 ├── 数据模型（Deep：实体/迁移/聚合根候选/实体关系）
 ├── API 表面（Deep：REST/gRPC/CLI 主要清单）
 ├── 测试现状（测试目录/框架/粗略覆盖）
-└── 已有文档（README/docs/注释密度）
+├── 已有文档（README/docs/注释密度）
+└── Git 仓库结构（子仓库清单/类型/用途/操作约束）
 ```
 
 ## 已有文档处理
@@ -87,6 +101,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 - docs/architecture/API-INDEX.md（API 端点索引，v0.23.0）
 - docs/architecture/INDEX.md（架构文档索引，v0.23.0）
 - docs/architecture/CONCEPTS.md（领域词汇，N 个术语）
+- CLAUDE.md（项目概况 + 产物结构索引，B4.5）
 - 目录结构：prd/ prototype/ docs/ changes/
 
 关键发现：
@@ -94,6 +109,11 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 - 模块数：5（user-service, order-service, ...）
 - 架构模式：微服务 + DDD 分层
 - 测试覆盖：约 60%（JUnit 5 + Mockito）
+- ⚠ INCOMPLETE：<缺失维度名>（如 api-surface——Deep 模式未派发）
+
+建议：
+→ 复杂项目（≥5 模块 或 ≥10 源文件）优先逆向重建完整架构
+→ 交叉验证与真实性核对：docs/architecture/cross-check-report.md（如执行 B）
 
 下一步：
 → 运行 /workflow-orchestrator 开始产品级流程

package/skills/workflow-bootstrap/references/b5-path-decision.md

@@ -0,0 +1,102 @@
+# B5 路径决策详细流程（v0.42.0：降级路径设计）
+
+> 主代理在 B5 询问用户时展示分组选项，并按用户选择执行 A/B/C 或进入第二组流程。
+
+## 分组展示模板
+
+询问用户时，按以下模板展示（**两组分开展示**）：
+
+```
+第一组：确保 bootstrap 产物可信
+  A 逆向重建完整架构
+  B 交叉验证与对齐 bootstrap 产物
+  C 真实性核对
+第二组：直接进入 team-flow 流程
+  D 我有一个具体的功能需求
+  E 我有一个模糊的产品方向
+  F 仅建立基线，暂不开发
+```
+
+**多选**：第一组可多选（如 A + B），第二组单选。第一组优先——用户选第二组前，主代理应提示"bootstrap 产物未经交叉验证，直接进入流程可能有偏差"（advisory，不阻断）。
+
+## A 逆向重建：复杂度分级推荐
+
+**判据来源**（复用 B1 侦察结果，无需新采集）：
+- 模块数：codebase-recon-analyst modules 维度的模块计数
+- 源文件数：recon-probe JSON `loc.total_files`
+
+**分级推荐**：
+
+| 条件 | 推荐措辞 |
+|------|---------|
+| ≥5 模块 或 ≥10 源文件（复杂） | "建议优先重建完整架构——项目有实质架构，基线快照不足以支撑后续设计" |
+| <5 模块 且 <10 源文件（简单） | "项目较简单，可直接进入流程，逆向重建为可选项" |
+
+**去向**：A → workflow-orchestrator ARCH 阶段 reconstruction 模式（arch-reverse-analyst，`references/agents/arch-reverse-analyst.md`）→ architecture-reviewer product 视角评审（≤3 轮循环）→ PASS 后 `tf arch init --mode reconstruction --baseline-ref prd/vN/` 打戳。
+
+## B 交叉验证与对齐：主代理机械比对
+
+> B1 刚结束主代理手里材料最全（recon-probe JSON + 各维度摘要 + baseline.md），交叉验证是机械比对，**主代理直接执行，不派发子代理**（LT 决策 v0.42.0）。
+
+**比对原则**：确定性数据（脚本机械采集）为锚，语义结论（子代理 LLM 推断）为被检对象。只标记冲突，不重跑侦察。
+
+**比对清单**：
+
+| # | 比对项 | 确定性证据（脚本字段） | 语义结论（子代理维度） |
+|---|--------|----------------------|----------------------|
+| 1 | 技术栈 | `dependencies.manifests` | technology |
+| 2 | 模块边界 | `directory_tree.dirs` | modules |
+| 3 | 数据模型 | `ddl_extraction.tables` | data-model |
+| 4 | API 表面 | `directory_tree.dirs` 按 controller/router/route/api 目录名过滤（best-effort） | api-surface |
+| 5 | 测试现状 | `tests.test_file_count` | test-docs |
+| 6 | Git 结构 | `git_structure` | git-structure |
+| 7 | 文档声明 | `docs.doc_files` | baseline.md 中引用的文档 |
+
+**维度覆盖说明**：
+- **architecture 维度不纳入机械比对**（显式排除）：架构模式（DDD/MVC/微服务/单体）是纯语义判定，无确定性锚点。其验证交由 A 重建时的 arch-reverse-analyst 深化 + architecture-reviewer 审查，B 阶段不机械比对。
+- **API 表面无独立确定性扫描字段**（recon-probe.sh 无 controller/router 采集），第 4 项降级为 best-effort 语义比对——从 `directory_tree.dirs` 过滤 controller/router/route/api 目录名作锚，若目录树无明显 API 目录则标注"无锚点，跳过该项"。
+
+**疑点判定**：确定性证据存在但语义结论未反映 → 疑点（如依赖清单有 spring-boot 但技术栈未提）；语义结论声称但确定性证据缺失 → 疑点（如测试覆盖声称 60% 但 test_file_count=0）。
+
+**输出**：`docs/architecture/cross-check-report.md`
+
+```markdown
+# Bootstrap Cross-Check Report
+
+> 由 workflow-bootstrap B5-B 主代理机械比对生成（v0.42.0）。确定性数据为锚，语义结论为被检对象。
+
+## 疑点清单
+
+| # | 比对项 | 确定性证据 | 语义结论 | 冲突描述 | 建议动作 |
+|---|--------|-----------|---------|---------|---------|
+| 1 | 技术栈 | ... | ... | ... | ... |
+
+## 结论
+
+cross-check: <PASS | N/A（未选 B）| deferred（疑点留档）>
+```
+
+不阻断（advisory）。`cross-check: deferred` 时提示用户可后续补核对。
+
+## C 真实性核对：用户确认门
+
+**触发**：用户选 C，或选 B 后主代理提示"是否进入 C 真实性核对？"。
+
+**两种模式**：
+- **C 跟随 B（推荐）**：针对 cross-check-report.md 疑点清单，主代理用 AskUserQuestion 逐条（或按比对项分组）确认：
+- **C 独立（未选 B）**：无 cross-check-report.md 可核对，主代理对 baseline.md 的全部语义结论做真实性抽查（每维度挑 1-2 个代表性结论），用户逐条确认"属实 / 修正 / 忽略"。
+
+**确认流程**（两模式共用）：
+
+| 用户选择 | 动作 |
+|---------|------|
+| 确认（属实） | 修正 baseline.md 对应内容，provenance 标注 `user-confirmed` |
+| 忽略 | 保留疑点，标记 `deferred`，不阻断 |
+| 补充说明 | 按用户描述修正，provenance 标注 `user-confirmed` |
+
+**核对完成**：更新 baseline.md 顶部校验状态 `cross-check: PASS`（无剩余疑点）或 `deferred`（有忽略项）。
+
+## 与其他选项关系
+
+- A（重建）与 B（交叉验证）可组合：先 B 校验基线可信，再 A 重建——重建消费的是校验后的基线，降低重建偏差
+- D/E/F 为原 A/B/C 平移，语义不变，仅位置后移

package/skills/workflow-bootstrap/scripts/recon-probe.sh

@@ -4,7 +4,7 @@
 #
 # 用途
 #   对既有代码库做"固定化、可复现"的机械采集：目录树 / 依赖清单 / LOC 与文件
-#   类型分布 / 测试文件计数 / DB 迁移清单 / README-docs 探测。
+#   类型分布 / 测试文件计数 / DB 迁移清单 / README-docs 探测 / Git 子仓库结构。
 #   本脚本只做**确定性机械采集**（设计文档 v0.8 §17.8 第四类载体）——同项目两次
 #   运行结果一致，可横展对比。语义判断（架构模式 / 聚合根推断 / 框架定性）交给
 #   消费本脚本 JSON 输出的侦察子代理（codebase-recon-analyst）完成。
@@ -368,6 +368,75 @@ if [ "$DDL_TABLE_COUNT" -eq 0 ]; then
   printf -- '-- Please populate manually with your database schema.\n\n' >> "$TMP/ddl_statements.sql"
 fi
 
+# ============================================================================
+# ⑧ Git 子仓库扫描（v0.41.0：git-structure 维度）
+# ----------------------------------------------------------------------------
+# 识别 root 自身 git 仓库状态 + 嵌套 git 仓库（排除 root 自身）+ git submodule
+# + .gitignore 忽略子仓库规则。设计契约：只做确定性机械采集（目录/文件探测），
+# 每个子仓库的用途/提交顺序约束等语义判断交给侦察子代理。
+# ============================================================================
+
+# 判断 root 自身是否为 git 仓库（.git 目录或 git rev-parse 兜底）
+IS_GIT_REPO=false
+if [ -d "$ROOT_ABS/.git" ] || git -C "$ROOT_ABS" rev-parse --git-dir >/dev/null 2>&1; then
+  IS_GIT_REPO=true
+fi
+
+# 查找嵌套 git 仓库（.git 目录或文件——submodule/worktree 可能是文件），排除 root 自身
+: > "$TMP/sub_repos.txt"
+if [ "$IS_GIT_REPO" = true ]; then
+  find "$ROOT_ABS" -maxdepth 3 \
+    \( -type d -name .git -o -type f -name .git \) \
+    -print 2>/dev/null \
+    | grep -v "^$ROOT_ABS/.git$" \
+    | while IFS= read -r _g; do
+        rel="$(dirname "${_g#"$ROOT_ABS"/}")"
+        echo "$rel"
+      done | sort -u > "$TMP/sub_repos.txt"
+fi
+SUB_REPO_COUNT=$(wc -l < "$TMP/sub_repos.txt" | tr -d ' ')
+
+# git submodule 列表（.gitmodules 存在时）
+: > "$TMP/submodules.txt"
+if [ -f "$ROOT_ABS/.gitmodules" ]; then
+  grep -oE 'path[[:space:]]*=[[:space:]]*[^[:space:]]+' "$ROOT_ABS/.gitmodules" 2>/dev/null \
+    | sed -E 's/path[[:space:]]*=[[:space:]]*//' | sort -u > "$TMP/submodules.txt"
+fi
+SUBMODULE_COUNT=$(wc -l < "$TMP/submodules.txt" | tr -d ' ')
+
+# 构建 sub_repos JSON 数组（含 type / has_remote）
+: > "$TMP/sub_repos.json"
+if [ "$IS_GIT_REPO" = true ]; then
+  while IFS= read -r _sr; do
+    [ -z "$_sr" ] && continue
+    _type="nested"
+    if [ -f "$ROOT_ABS/.gitmodules" ] \
+      && grep -qE "^[[:space:]]*path[[:space:]]*=[[:space:]]*${_sr}[[:space:]]*$" "$ROOT_ABS/.gitmodules" 2>/dev/null; then
+      _type="submodule"
+    fi
+    _has_remote="false"
+    if git -C "$ROOT_ABS/$_sr" remote 2>/dev/null | grep -q .; then
+      _has_remote="true"
+    fi
+    printf '{"path":"%s","type":"%s","has_remote":%s},' \
+      "$(json_escape "$_sr")" "$_type" "$_has_remote" >> "$TMP/sub_repos.json"
+  done < "$TMP/sub_repos.txt"
+fi
+SUB_REPOS_JSON="$(sed 's/,$//' "$TMP/sub_repos.json" 2>/dev/null)"
+
+# .gitignore 中是否忽略了任一子仓库
+GITIGNORE_IGNORES_SUBREPOS=false
+if [ -f "$ROOT_ABS/.gitignore" ] && [ "$SUB_REPO_COUNT" -gt 0 ]; then
+  while IFS= read -r _sr; do
+    [ -z "$_sr" ] && continue
+    # 匹配：整行 / 目录行（斜杠结尾）/ 项目名
+    if grep -qE "(^|/)[[:space:]]*${_sr}(/|$)" "$ROOT_ABS/.gitignore" 2>/dev/null; then
+      GITIGNORE_IGNORES_SUBREPOS=true
+      break
+    fi
+  done < "$TMP/sub_repos.txt"
+fi
+
 # ============================================================================
 # 组装 JSON
 # ============================================================================
@@ -399,10 +468,17 @@ fi
   printf '  "docs": {"docs_dir": %s, "doc_files": %s},\n' \
     "$DOCS_DIR" "$(json_array_from_file "$TMP/doc_files.txt")"
   # ⑦ DDL 提取（v0.24.0）
-  printf '  "ddl_extraction": {"source": "%s", "table_count": %s, "tables": %s, "ddl_statements": "%s"}\n' \
+  printf '  "ddl_extraction": {"source": "%s", "table_count": %s, "tables": %s, "ddl_statements": "%s"},\n' \
     "$(json_escape "$DDL_SOURCE")" "$DDL_TABLE_COUNT" \
     "$(json_array_from_file "$TMP/ddl_tables.txt")" \
     "$(json_escape "$(cat "$TMP/ddl_statements.sql" 2>/dev/null)")"
+  # ⑧ Git 子仓库结构（v0.41.0）
+  printf '  "git_structure": {"is_git_repo": %s, "sub_repo_count": %s, "sub_repos": [%s], "submodule_count": %s, "submodules": %s, "gitignore_ignores_subrepos": %s}\n' \
+    "$IS_GIT_REPO" "$SUB_REPO_COUNT" \
+    "$SUB_REPOS_JSON" \
+    "$SUBMODULE_COUNT" \
+    "$(json_array_from_file "$TMP/submodules.txt")" \
+    "$GITIGNORE_IGNORES_SUBREPOS"
   printf '}\n'
 } > "$TMP/out.json"
 
@@ -443,6 +519,7 @@ fi
   echo "docs/ 目录   : $DOCS_DIR"
   echo "README 等    : $(wc -l < "$TMP/doc_files.txt" | tr -d ' ') 个"
   echo "DDL 提取     : source=$DDL_SOURCE, tables=$DDL_TABLE_COUNT"
+  echo "git 仓库     : is_repo=$IS_GIT_REPO, 子仓库=$SUB_REPO_COUNT, submodule=$SUBMODULE_COUNT"
   echo "================================================="
 } >&2
 

package/skills/workflow-bootstrap/templates/claude-md-team-flow.md

@@ -0,0 +1,60 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+> 本文件由 team-flow `workflow-bootstrap` B4.5 阶段生成（参考 Claude Code /init）。
+> 维护原则：索引级 + 结构级，简明扼要——删除某条后 Claude 是否会犯错？不会就删掉。
+
+## 项目概况
+
+{{PROJECT_SUMMARY}}
+<!-- 语言 / 框架 / 构建工具 / 数据库，2-3 行。来源：B1 technology 维度 -->
+
+## 开发命令
+
+{{DEV_COMMANDS}}
+<!-- 构建/测试/lint 命令，只列非标准的（如 mvn 单测、特殊 env）。来源：B1 侦察 + README -->
+
+## 工作区结构
+
+{{WORKSPACE_TREE}}
+<!-- 简化目录树（≤3 层），只标注关键目录用途。来源：B1 directory_tree -->
+
+## Git 仓库结构
+
+{{GIT_STRUCTURE}}
+<!-- 子仓库清单 + 类型(nested/submodule) + 用途 + 提交/推送顺序约束。来源：B1 git-structure 维度 -->
+
+## 产物结构（team-flow）
+
+team-flow 工作流在 `changes/<name>/` 下通过状态机驱动变更，核心制品如下：
+
+### 代码强制执行的制品（state-loader.mjs + hash.mjs 校验）
+
+| 产物 | 路径 | 校验机制 |
+|------|------|---------|
+| 状态文件 | `changes/<name>/.team-flow.yaml` | state-loader 硬编码 `STATE_FILE` |
+| 提案 | `changes/<name>/proposal.md` | hash.mjs → `artifacts_hash` |
+| 规格 | `changes/<name>/specs/*.md` | hash.mjs → `artifacts_hash` |
+| 设计 | `changes/<name>/design.md` | hash.mjs → `artifacts_hash` |
+| 任务 | `changes/<name>/tasks.md` | hash.mjs → `artifacts_hash` |
+| 执行契约 | `changes/<name>/execution-contract.md` | hash.mjs → `contract_hash` |
+
+### 设计层面约定的制品（SKILL.md 文档引用，无代码强制校验）
+
+| 产物 | 路径 | 状态 |
+|------|------|------|
+| 产品级 PRD | `prd/vN/prd.md` | ce-brainstorm 引用 |
+| 产品级计划 | `prd/vN/plan.md` | ce-plan 引用 |
+| 变更简报 | `changes/<name>/change-brief.md` | orchestrator S4 产出，hash 显式排除 |
+| 架构设计 | `changes/<name>/architecture/{architecture,database,api}.md` | hash 纳入 artifacts_hash |
+| 需求注册表 | `.team-flow/registry.yaml` | workflow-orchestrator 引用 |
+| 全局架构基线 | `docs/architecture/baseline.md` | workflow-bootstrap 引用 |
+| 项目架构基线标记 | `.team-flow/arch-state.json` | `tf arch init` 打戳 |
+
+> 架构文档详细内容见 `@docs/architecture/baseline.md`（全局基线）和 `@docs/architecture/`（ARCHITECTURE.md / DATABASE.md / API-INDEX.md / INDEX.md）。
+
+## Git 管理规则
+
+{{GIT_MANAGEMENT_RULES}}
+<!-- 提交/推送顺序约束 + 子仓库操作规则。来源：B1 git-structure 维度 + 项目约定 -->