@xulthekl/team-flow 0.39.1 → 0.41.0

package/skills/ce-brainstorm/references/business-scenarios.md

@@ -0,0 +1,122 @@
+# Phase 1.5 — Business Scenario Analysis
+
+Detailed scenario extraction and validation logic for Phase 1.5. Triggered after Phase 1.4 completes; applies to all tiers. This phase is analytical with user confirmation — loops until the user confirms.
+
+## Trigger & Input
+
+**Trigger**: Phase 1.4 completed.
+
+**Input files**:
+- `requirement/vN/dialogue-log.md` — conversation evidence
+- `requirement/ledger.md` — archived scenario entries (read-only during this phase)
+- `requirement/vN/business-analysis.md` — current version scenarios (if any exist)
+
+## Step 1: Extract Candidate Scenarios
+
+Read `dialogue-log.md` and identify all business scenarios implied by the conversation. A candidate scenario is a discrete business activity involving one or more roles pursuing a goal under specific conditions. Extract:
+
+- The roles mentioned or implied
+- The goals each role pursues
+- Triggering conditions and preconditions
+- Constraints and acceptance criteria mentioned
+
+Output a raw candidate list — one entry per distinct business activity. Do not merge or deduplicate yet.
+
+## Step 2: Compare with Existing Scenarios
+
+Read two sources:
+
+1. **Archived entries** — `requirement/ledger.md` (scenarios from previous versions that have been archived)
+2. **Current version** — `requirement/vN/business-analysis.md` (scenarios already drafted in this version)
+
+For each candidate from Step 1, classify:
+
+| Classification | Action |
+|---|---|
+| **New** — no matching entry in either source | Create entry with status 🔵 pending |
+| **Optimized** — existing entry needs revision per new evidence | Create a revised version in current `business-analysis.md`, mark change type |
+| **Unchanged** — existing entry already covers it | Skip |
+
+Matching criteria: same business activity (role + goal overlap), not merely same domain.
+
+## Step 3: Six-Dimension Structuring
+
+For each new or optimized scenario, fill all six dimensions:
+
+| Dimension | Description |
+|---|---|
+| **Role** | Who performs this activity (specific role, not generic "user") |
+| **Goal** | What the role aims to achieve |
+| **Trigger** | What event or condition initiates this scenario |
+| **Precondition** | What must be true before the scenario can start |
+| **Constraint** | Rules, limits, or policies that bound the scenario |
+| **Acceptance** | Testable conditions that prove the scenario succeeded |
+
+**Entry metadata**:
+
+| Field | Value |
+|---|---|
+| Scenario ID | `SC-xxx` (sequential within version) |
+| Status | 🔵 pending |
+| Related requirements | `REQ-xxx` references |
+| Related process | Process name or ID if applicable |
+| Change history | Version, date, change type (create/modify), summary |
+
+## Step 3.5: QA-1 Quality Check
+
+Dispatch `scenario-quality-checker` sub-agent after structuring completes.
+
+**Check items**:
+
+| ID | Category | Check | Level |
+|---|---|---|---|
+| C1 | Completeness | All roles from dialogue-log have corresponding scenario coverage | Error |
+| C2 | Completeness | Every scenario has all six dimensions filled | Error |
+| C3 | Consistency | Related requirement IDs (`REQ-xxx`) exist in the requirement list | Error |
+| C4 | Consistency | New scenarios do not overlap/conflict with archived ledger entries | Warning |
+| C5 | Accuracy | Each scenario has traceable evidence in dialogue-log (not fabricated) | Error |
+| C6 | Accuracy | Acceptance criteria are testable (specific conditions, not vague) | Warning |
+| C7 | Completeness | Optimized scenarios include a change reason | Warning |
+
+**Routing**:
+
+- **PASS** (0 Errors) → proceed to Step 4
+- **FAIL** (≥1 Error) → return to Step 3, fix flagged items, re-check
+- **Maximum 3 rounds** — if still failing after round 3, escalate to user for decision
+
+Warnings are reported but do not block progression.
+
+## Step 4: Present & Confirm (Blocking Question)
+
+Display all scenarios (new + optimized) with full six-dimension detail. Ask the user for formal confirmation:
+
+- **✅ Confirm** → upgrade status to ✅ confirmed, write to `requirement/vN/business-analysis.md`, exit phase
+- **✏️ Adjust** → apply user feedback, return to Step 3, re-run QA-1
+
+This is a blocking question — do not proceed until the user explicitly confirms.
+
+## Write Rules
+
+On confirmation:
+
+1. Write confirmed scenarios to `requirement/vN/business-analysis.md` (requirements list + scenario list sections)
+2. **Do not update `ledger.md`** — ledger is batch-updated during version archival (Phase 3.6), not during scenario confirmation
+
+## Deprecation Handling
+
+When a scenario is deprecated (user explicitly requests removal):
+
+1. Delete the entry from `requirement/ledger.md`
+2. Delete the entry detail from the version's `business-analysis.md`
+3. Update `doc/active-registry/active-items.md` to reflect the current active set
+
+## Status Lifecycle
+
+Only two states exist:
+
+| State | Meaning |
+|---|---|
+| 🔵 pending | Drafted, awaiting QA-1 pass and user confirmation |
+| ✅ confirmed | User confirmed, written to business-analysis.md |
+
+No other states. Scenarios transition from 🔵 to ✅ only via Step 4 user confirmation.

package/skills/ce-brainstorm/references/evidence-chain-validation.md

@@ -0,0 +1,114 @@
+# Evidence Chain Validation — Phase 3.6 + QA-4 + Version Archiving
+
+This reference covers three connected operations after PRD generation: QA-4 quality check, bidirectional evidence chain validation, and version archiving. They execute in strict sequence: QA-4 → validation → archive.
+
+## QA-4: PRD Quality Checker (prd-quality-checker)
+
+**Trigger:** PRD document written (Phase 3 complete), before Phase 3.6 validation.
+**Route:** PASS → enter Phase 3.6; FAIL → return to Phase 3 to fix PRD.
+
+| ID | Category | Check | Severity |
+|----|----------|-------|----------|
+| C1 | Completeness | PRD §2 includes a business process overview table (L1–L4)? | Error |
+| C2 | Completeness | PRD §3 includes a flowchart + activity table for each confirmed process? | Error |
+| C3 | Completeness | Every feature in PRD §7 carries REQ-xxx + SC-xxx + BP-xxx triple-ID linkage? | Error |
+| C4 | Completeness | PRD §8 feature modules organized by process (BP-xxx grouping)? | Error |
+| C5 | Consistency | PRD §2 process overview table matches business-analysis.md process list? | Error |
+| C6 | Consistency | PRD §3 process descriptions match business-analysis.md process details? | Error |
+| C7 | Metadata | PRD frontmatter complete (title / project_name / iteration_version / date / prd_template)? | Warning |
+| C8 | Format | §8.4 feature extraction preserves original requirements detail (not over-summarized)? | Warning |
+
+**Verdict rule:** All Error-level checks pass → PASS. Any Error fails → FAIL. Warnings are reported but do not block.
+
+## Phase 3.6: Bidirectional Validation
+
+**Trigger:** QA-4 verdict = PASS.
+**Nature:** Automatic validation + user confirmation.
+
+### Inputs
+
+- `requirement/vN/prd.md` — the generated PRD
+- `requirement/ledger.md` — the master requirements ledger
+
+### Five Validation Dimensions
+
+**V1 — Scenario Coverage Completeness**
+Every scenario marked ✅ in the ledger must have functional coverage in PRD §7/§8. Check: for each ledger SC-xxx row with status ✅, find at least one PRD §7 feature referencing that SC-xxx ID.
+
+**V2 — Process Coverage Completeness**
+Every process marked ✅ in the ledger must appear in PRD §3. Check: for each ledger BP-xxx row with status ✅, find a corresponding PRD §3 section describing that process.
+
+**V3 — Step-to-Function Mapping**
+Each step of each confirmed process must map to a PRD §7 feature. Check: for every BP-xxx step listed in the ledger, find a PRD §7 feature whose triple-ID includes that BP-xxx and a matching step description.
+
+**V4 — Function Traceability Completeness**
+Every PRD §7 feature must carry a valid REQ-xxx + SC-xxx + BP-xxx triple. Check: parse each feature's ID block; verify each ID resolves to an existing ledger row. Flag orphan IDs or missing links.
+
+**V5 — Process Description Consistency**
+PRD §3 process descriptions must be consistent with business-analysis.md. Check: compare process name, step count, step names, and actor assignments between the two documents. Semantic equivalence is sufficient; verbatim match is not required.
+
+### Validation Verdict and Routing
+
+| Verdict | Condition | Next Step |
+|---------|-----------|-----------|
+| PASS | V1–V5 all pass | Proceed to version archiving, then Phase 4 |
+| CONDITIONAL_PASS | Failures in V1–V5 are explicitly marked "defer this iteration" by user | User annotates exempt items with justification → proceed to archiving |
+| FAIL | Unresolvable gaps remain | Return to Phase 3 to fix PRD, or return to Phase 1.5/1.6 to supplement requirements |
+
+## Version Archiving
+
+**Trigger:** Phase 3.6 verdict = PASS or CONDITIONAL_PASS.
+**Tier:** All tiers.
+**Nature:** Atomic, automated, no user interaction.
+
+### Pre-Checks (all must hold)
+
+1. Current-version business-analysis.md: all REQ status = ✅
+2. Current-version business-analysis.md: all SC status = ✅
+3. Current-version business-analysis.md: all BP status = ✅
+4. Phase 3.6 verdict = PASS or CONDITIONAL_PASS
+
+### Processing Steps
+
+**Step 1 — Ledger batch write/refresh**
+
+For every item in the current version's business-analysis.md:
+
+- New item → append a row to ledger.md
+- Modified item → refresh the existing row's `last_modified_version` and `directory` fields
+- Reverse references → refresh the `linked_processes` field in scenario/requirement ledger rows
+
+**Step 2 — Append archive record**
+
+Append one row to ledger.md's "Version Archive" section:
+
+| archive_version | archive_date | included_requirements | included_scenarios | included_processes | prd_path | status |
+
+**Step 3 — Mark business-analysis.md archived**
+
+Set frontmatter field `archived: true` in the current version's business-analysis.md.
+
+**Step 4 — Update active registry**
+
+Update `doc/active-registry/active-items.md` to reflect the newly archived items and retire any superseded entries.
+
+### Outputs
+
+- `requirement/ledger.md` — batch update complete
+- `requirement/vN/business-analysis.md` — archived flag set
+- `doc/active-registry/active-items.md` — updated
+
+### Exit
+
+Archiving complete → ready to enter `ce-plan` (development phase).
+
+## Compound Interest Archive Sync
+
+When archiving completes, the compound interest (复利) system should also update:
+
+1. Append a row to the ledger's "Release Records" table
+2. Fill the `release_version` field on relevant items
+3. Update PRD frontmatter metadata (mark published version)
+4. Item statuses remain unchanged (stay ✅ confirmed)
+
+This reference documents the trigger relationship only. Compound interest automation is owned by the `ce-compound` skill.

package/skills/ce-brainstorm/references/phase0-routing.md

@@ -11,6 +11,8 @@ If the user references an existing brainstorm topic or document, or there is an
 - If resuming, summarize the current state briefly, continue from its existing decisions and outstanding questions, and update the existing document instead of creating a duplicate
 - **Resume preserves the existing artifact's format, except pipeline mode.** Write back in whatever format the existing artifact uses — markdown if `.md`, HTML if `.html`. Explicit `output:` arguments override. Pipeline mode always forces `OUTPUT_FORMAT=md`.
 
+**`requirement/` directory scan (v0.38.0+).** In addition to `prd/`, also scan `requirement/` for existing iteration versions (v1, v2, …). If `requirement/ledger.md` exists, read it to understand cross-iteration context — archived versions, entry statuses, and the overall requirement trajectory. When both `prd/` and `requirement/` exist, merge signals from both; when only `requirement/` exists (no `prd/`), treat `requirement/` as the authoritative source for resume decisions.
+
 Historical `docs/brainstorms/*-requirements.{md,html}` files remain legacy inputs for `ce-plan`, but new outputs write to `prd/{ITERATION_VERSION}/prd.md`.
 
 ## 0.1b Classify Task Domain
@@ -88,9 +90,13 @@ The spine is five tasks, in order:
 ## 0.5 Resolve Iteration Version
 
 Scan the `prd/` directory to detect existing iteration versions (v1, v2, v3, ...).
-- If no iterations exist: suggest creating v1, ask user to confirm
+- Also scan `requirement/` for iteration versions — the directory may contain v-prefixed subdirectories (v1, v1.1, v2, …) representing past or parallel iterations.
+- When both `prd/` and `requirement/` exist, union the detected versions and pick the highest as baseline for the next version number.
+- If only `requirement/` exists, derive the new version from its latest entry (e.g., `requirement/v2/` → suggest v3).
+- If no iterations exist in either directory: suggest creating v1, ask user to confirm
 - If iterations exist: suggest the latest iteration, offer to continue or create new
 - User confirms the target iteration version
 - Store as `ITERATION_VERSION` (e.g., "v1", "v2")
 - Target PRD path: `prd/{ITERATION_VERSION}/prd.md`
+- **Legacy `prd/` compatibility:** projects migrating from `prd/` to `requirement/` may have both directories. Treat `prd/v1` and `requirement/v1` as the same logical iteration; do not create a duplicate version number.
 - Scan `prototype/` directory to confirm prototype branch aligns with PRD iteration version (if prototype exists).

package/skills/ce-brainstorm/references/prd-mapping.md

@@ -7,13 +7,13 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 | PRD 章节 | 信息来源 | 填充策略 |
 |---|---|---|
 | 一、版本修订记录 | 元数据（日期、作者、版本、状态） | **自动填充**：从对话上下文提取日期、用户信息；版本/状态按下方「版本格式规范」填充，**文档状态必须与 frontmatter `frozen` 一致** |
-| 二、业务流程一览 | Phase 1.3 对话：用户/流程/系统交互 | **对话填充**：brainstorm 对话中收集的业务流程信息 |
-| 三、D7.1_业务流程 | Phase 1.3 对话：Key Flows | **对话填充**：从 brainstorm 的 Key Flows 映射 |
+| 二、业务流程一览 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（业务流程一览表） + `requirement/ledger.md`（流程台账 L1~L4 分组） | **对话+台账填充**：优先从 business-analysis.md 的业务流程一览表（L1 分组 ~ L4 子流程）提取；对话补充未落账的流程信息 |
+| 三、D7.1_业务流程 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（流程详情：流程图 + 活动一览表） | **对话+台账填充**：优先从 business-analysis.md 的流程详情（流程图 + 活动一览表）提取；对话补充 Key Flows 中未落账的细节 |
 | 四、D7.2_画面原型及设计 | Phase 1.3 对话：UI/交互需求 | **对话填充**：如涉及 UI，从对话中收集原型信息 |
 | 五、D7.3_报表清单 | Phase 1.3 对话 | **占位保留**：brainstorm 不涉及报表细节，保留模板占位符 |
 | 六、D7.4_业务术语字典 | Phase 1.3 对话 + CONCEPTS.md | **部分填充**：从对话中提取的领域术语，其余保留占位符 |
-| 七、D7.5_系统功能清单 | Phase 1.3 对话：Requirements | **对话填充**：从 brainstorm 的 Requirements 映射 |
-| 八、D7.6_系统功能处理说明书 | Phase 1.3 对话：Key Decisions + Constraints | **部分填充**：权限/交互/异常等从对话收集，硬件/网络保留占位符 |
+| 七、D7.5_系统功能清单 | Phase 1.3 对话 + `requirement/ledger.md`（需求台账 + 场景台账） + `requirement/vN/business-analysis.md` | **对话+台账填充**：每个功能标注关联需求 ID、关联场景 ID、关联流程步骤；从需求台账和场景台账提取关联关系 |
+| 八、D7.6_系统功能处理说明书 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（按流程组织的功能模块） + `requirement/ledger.md`（流程台账） | **部分填充**：按流程组织，每个功能模块标注所属流程；权限/交互/异常从对话收集，硬件/网络保留占位符 |
 | 九、D7.7_要件定义自查报告 | 自动 | **占位保留**：这是 BA 自查工具，brainstorm 阶段不填充 |
 | 十、D7.8_要件定义完成报告 | 自动 | **占位保留**：这是完成态产物，brainstorm 阶段不填充 |
 | 十一、D7.9_评审会议纪 | 自动 | **占位保留**：这是评审产物，brainstorm 阶段不填充 |
@@ -22,16 +22,44 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 
 1. **brainstorm 对话中没有信息的章节保留模板占位符**，不硬填
 2. **版本修订记录（§1）** 从元数据自动填充：日期、撰写人（如可获取）
-3. **业务流程（§2-§3）** 从 brainstorm 的 Key Flows 和 Actors 映射
+3. **业务流程（§2-§3）** 优先从 `business-analysis.md` 提取（§2 ← 业务流程一览表，§3 ← 流程详情），对话中的 Key Flows 和 Actors 作为补充
 4. **画面原型（§4）** 仅在 brainstorm 涉及 UI 时填充
 5. **业务术语（§6）** 从对话中提取已定义的领域术语
-6. **系统功能（§7-§8）** 从 Requirements 和 Key Decisions 映射
+6. **系统功能（§7-§8）** 从 Requirements 和 Key Decisions 映射；§7 每个功能标注关联需求 ID + 场景 ID + 流程步骤（来源：`ledger.md`），§8 按流程组织并标注所属流程（来源：`business-analysis.md` + `ledger.md`）
 7. **自查/完成/评审（§9-§11）** 全部保留占位符，由后续流程填充
 
+## 台账与业务分析文档映射（v0.38 新增）
+
+当 `requirement/` 目录下存在台账和业务分析文档时，ce-brainstorm 应优先从中提取结构化数据填充 PRD，而非仅依赖对话收集。
+
+### 输入文件与职责
+
+| 文件 | 路径 | 职责 |
+|------|------|------|
+| 需求/场景/流程台账 | `requirement/ledger.md` | 全量条目和关联关系（需求 ID、场景 ID、流程 ID 及交叉引用） |
+| 修订记录 | `requirement/vN/dialogue-log.md` | §1.2 修订记录的引用路径（指向具体对话日志） |
+| 业务分析文档 | `requirement/vN/business-analysis.md` | §2/§3/§7/§8 的结构化数据来源 |
+
+### 章节级映射规则
+
+| PRD 章节 | 台账/文档来源 | 提取内容 |
+|----------|-------------|---------|
+| §1.2 修订记录 | `requirement/vN/dialogue-log.md` | 修订记录引用路径（文件名 + 日期） |
+| §2 业务流程一览 | `ledger.md` 流程台账 + `business-analysis.md` | L1 分组 ~ L4 子流程的业务流程一览表 |
+| §3 D7.1_业务流程 | `business-analysis.md` | 流程详情：流程图 + 活动一览表 |
+| §7 D7.5_系统功能清单 | `ledger.md` 需求台账 + 场景台账 | 每个功能标注：关联需求 ID + 关联场景 ID + 关联流程步骤 |
+| §8 D7.6_系统功能处理说明书 | `business-analysis.md` + `ledger.md` 流程台账 | 按流程组织，每个功能模块标注所属流程 |
+
+### 缺失降级策略
+
+- 台账或业务分析文档不存在时，退回对话填充策略（即原有行为），不阻断 brainstorm 流程
+- 台账存在但某章节对应字段为空时，该章节保留模板占位符并在备注中标注"台账数据待补充"
+- 复利归档后，PRD frontmatter 应更新已发布版本标记，与台账中的`发布版本`字段保持一致
+
 ## 迭代版本（vN）
 
-- `prd/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
-- ce-brainstorm 启动时扫描 `prd/` 目录检测已有迭代
+- `prd/vN/` 或 `requirement/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
+- ce-brainstorm 启动时扫描 `prd/` 和 `requirement/` 目录检测已有迭代（`requirement/` 优先）
 - 自动建议最新迭代或创建新迭代，用户确认后继续
 - 每个迭代目录下只有一个 `prd.md` 文件
 

package/skills/ce-brainstorm/references/synthesis-summary.md

@@ -22,6 +22,15 @@ The internal draft is structured in three labeled buckets. Items may appear in t
 
 A session-settled decision (per `references/settled-decisions.md`) is **Stated with provenance** — record it in the Stated bucket with its class, rejected alternative, and one-line reason, never in Inferred: it is the user's confirmed choice, not an agent bet.
 
+**Evidence anchor references (SC-xxx / BP-xxx).** When dialogue content references a specific scenario or business flow that has an assigned ID in the scenario ledger or flow catalog, cite the ID as an evidence anchor rather than relying on prose description alone. Rules:
+
+- Use `SC-xxx` for scenarios, `BP-xxx` for flows — always with the confirmation status tag (✅ confirmed / 🔵 pending).
+- An item that touches multiple scenarios or flows lists all relevant IDs.
+- Prefer ID anchors over prose re-description: "user checkout flow (BP-012 ✅)" is more precise and more traceable than re-describing the flow in words.
+- When no ID exists for a referenced scenario or flow, note it as `(no ID assigned)` so the gap is visible — downstream spec-writing may need to create one.
+
+This keeps internal-draft claims traceable to the source evidence that synthesis-quality-checker C3/C4 verify.
+
 This draft is internal. Do not paste it verbatim into chat. Compose it as a thinking step, then derive stage 2 from it.
 
 ---
@@ -32,6 +41,12 @@ The scoping synthesis is what the user actually sees. It reflects the dialogue's
 
 The scoping synthesis has up to four named sections, each **render-conditional** on having something to say. Empty sections are omitted, not padded.
 
+**Scenario / flow ID references.** When any section below refers to a scenario or business flow that carries an `SC-xxx` or `BP-xxx` ID, include the ID inline — e.g., "…covers the support mute flow (BP-012 ✅)." Conventions:
+
+- ✅ confirmed IDs need no further action in the synthesis.
+- 🔵 pending IDs must surface in the **Call outs** section (see below) so the user knows which scope dependencies are not yet validated.
+- When multiple IDs cluster under one bullet, list them all — partial ID coverage defeats traceability.
+
 1. **What we're building** (always present) — 1–3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of "you said X."
 2. **Key trade-offs** (conditional) — 1–3 bullets, each with a brief why. Render only when real trade-offs were made in dialogue.
 3. **What's not in scope** (conditional) — 1–3 bullets, or fold into a single sentence. Render only when deferred items would surprise a downstream reader if absent.
@@ -79,6 +94,12 @@ Each conditional section has its own keep test. Sections are render-conditional
 - **Cheap-now-expensive-later correction** — a scope bet that's cheap to fix now but expensive after the Product Contract lands and ce-plan consumes it
 - **Non-obvious consequence of multi-turn answers** — a downstream effect of combining user-stated answers that the user is unlikely to have tracked through dialogue. Surfaced forward-looking ("X means Y for the doc"), not retrospectively ("you said X"). This category is the multi-turn-dialogue reason call-outs exist at all in ce-brainstorm; do not filter these as "already implied by Stated"
 
+**Unconfirmed (🔵) scenario / flow annotation.** Any scenario (SC-xxx) or flow (BP-xxx) referenced in the synthesis that still carries 🔵 pending status in the ledger must appear as a call-out — even when no other keep-test category applies.
+
+- Format: `🔵 <ID> (<name>) — not yet confirmed by user; scope depends on confirmation.`
+- Example: `🔵 SC-007 (guest checkout) — not yet confirmed; notification scope depends on whether guests are included.`
+- This bypasses the normal keep test: a 🔵 ID always surfaces regardless of other keep-test categories. Confirmed (✅) IDs never appear as call-outs on this basis alone.
+
 Cut anything that doesn't match a keep-test category, including:
 
 - Session-settled decisions — already chosen; they render as `Carrying forward:` lines, never call-outs

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,6 +186,29 @@ Step 2: 确定性提取（兜底）
 
 创建 team-flow 目录结构：`mkdir -p prd/ prototype/ docs/architecture/ docs/solutions/ changes/`。已有目录不覆盖不删除，只补缺失；目录中有文件保留不改。**Discoverability 检查**：若 `AGENTS.md`/`CLAUDE.md` 未暴露 `docs/architecture/` 和 `prototype/`，advisory 建议用户添加（不自动改）。
 
+### B4.5: CLAUDE.md 初始化（v0.41.0 新增，参考 Claude Code /init）
+
+将项目基本信息（参考 /init）和 team-flow 产物索引写入工作区 CLAUDE.md。维护原则：**索引级 + 结构级，简明扼要**——目标是每次开启会话对项目空间有全局认识，不长篇大论。
+
+**触发条件**：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（路径判断）
 
 询问用户：
@@ -213,10 +237,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 / 目录结构）
 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 / 目录结构）、关键发现（技术栈/模块数/架构模式/测试覆盖）、下一步建议。完整模板见 `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,7 @@ 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 模式未派发）
 
 下一步：
 → 运行 /workflow-orchestrator 开始产品级流程