@xulthekl/team-flow 0.39.0 → 0.40.1

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-start/SKILL.md

@@ -93,6 +93,15 @@ Guard: `... check <dir> specifying bridging --json` → fail = BLOCK. Artifacts
 ### 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，禁止绕过。
 
+**v0.39.0 主动串行编排**：workflow-start 必须主动串行编排 build-executor 和 code-reviewer，而不是被动等待 build-executor 完成所有 wave。流程：
+1. 读取 execution plan 获取 wave 列表（`tf execution show <change-dir> --json`）
+2. 对每个 wave：
+   - dispatch build-executor 执行当前 wave
+   - 等待 build-executor 完成（task-notification）
+   - dispatch code-reviewer 审查当前 wave
+   - 等待 review receipt + verdict=pass
+3. 所有 wave 完成后，继续下一步路由
+
 ### 阶段产物同步门禁点（v0.37.0 §68.2 G4）
 
 契约批准（DP-3）后、进入实施（DP-4）前，**阻塞确认**（AskUserQuestion）是否同步 change 规划制品（团队协作：契约是实施授权）：
@@ -108,6 +117,8 @@ Execution hit blockage: test failure, unexpected behavior, build error, task can
 ### Route to code-reviewer
 The current planned wave is implemented and ready for spec-compliance + code-quality verification. A reviewer must write an `tf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <path> --verdict <pass|fail>` receipt before any dependent wave or closing transition.
 
+**v0.39.0 主动串行编排**：workflow-start 在每个 wave 完成后主动 dispatch code-reviewer，而不是等待 build-executor 完成所有 wave。这是 workflow-start 的编排责任，不是 build-executor 的责任。
+
 **逐 wave 审查纪律（v0.36.4）**：每次 code-reviewer dispatch 只审查**一个** wave。禁止将多个 wave 合并为一次审查（vrm4teamflow C1 事件：W1-W4 合并审查导致设计约定类问题在 W4 才发现，修复范围扩大到 8 个 batch）。parallel wave 内的多个 task 作为整体审查一次（receipt 是 wave 级别），但审查 prompt 必须包含每个 task 的独立 diff。
 
 ### Route to release-archivist (dispatch sub-agent)
@@ -158,6 +169,42 @@ Use content inspection, not timestamps.
 
 **Brief drift (advisory, v0.9, 不阻断)**: change-brief.md 是上游输入（非 team-flow 产物），**不**混入上述三条产物互查、**不**进入 `artifacts_hash`。当 brief 的 `plan_hash` 与当前 `prd/vN/plan.md` 不一致，或 brief AC 列表与 PRD 功能清单明显出入 → 提示"产品层已变更，brief 可能过期，建议回 orchestrator 重新分发（S4→S3 环路）"，**不**触发产物重审。
 
+## Review Findings 处理流程（v0.39.0）
+
+当 code-reviewer 返回 findings 时，workflow-start 必须：
+1. 分析 findings 的严重程度（Critical/Important/Minor）
+2. 通过 SendMessage 将 findings 转发给 build-executor，附带修复指令
+3. 等待 build-executor 修复并返回结果
+4. **禁止直接 Read/Edit/Write 任何代码文件**——无论改动量大小
+
+示例 SendMessage：
+```yaml
+to: build-executor
+message: |
+  code-reviewer 发现以下 findings，请修复：
+  - F-15: policyYear prop 未传递（Critical）
+  - F-16: 评价下拉缺符号（Important）
+  
+  修复后请通知我，我将 dispatch code-reviewer re-review。
+```
+
+## 修复后 Re-review 流程（v0.39.0）
+
+build-executor 修复 findings 后，workflow-start 必须：
+1. dispatch code-reviewer 进行 re-review（只审查修复的 findings）
+2. 等待 re-review 结果
+3. 如果 re-review 通过（PASS 或 PASS_WITH_WARNINGS），记录 review receipt（verdict=pass）
+4. 如果 re-review 不通过（FAIL），重复修复流程（≤3 轮，不收敛转人工）
+5. **禁止在 review receipt 未记录或 verdict!=pass 时进入下一阶段**
+
+## Closing 前置条件检查（v0.39.0）
+
+在路由到 release-archivist 之前，workflow-start 必须检查：
+- 所有 planned wave 的 review receipt 是否存在
+- 所有 review receipt 的 verdict 是否为 pass
+- 如果任何 receipt 缺失或 verdict!=pass，阻断并要求 re-review
+- 检查命令：`tf execution show <change-dir> --json` 查看每个 wave 的 receipt 状态
+
 ## Guardrails
 
 - No implementation before planning artifacts or contract exist
@@ -174,7 +221,8 @@ Use content inspection, not timestamps.
 - **No routing to spec-writer without architecture-design gate pass** (v0.9 §26): `arch_design_decision` must be `required` or `skipped` (not `null`). hotfix/tweak 不豁免
 - **No arch state write without auto-review PASS** (v0.28.1 §36): when `decision: required`, auto-review MUST complete with PASS or PASS_WITH_WARNINGS before writing `arch_design_decision` to yaml. FAIL → loop fix (≤3 rounds) or escalate to human
 - **No routing past DP-A without user confirmation** (v0.29.0 §37): architecture-design 四步协议完成后，必须经 DP-A 用户确认门（AskUserQuestion）才能路由到 spec-writer。用户选择"需要调整"时，修改必须通过子代理执行，修改后重新 auto-review + 重新 DP-A 确认
-- **Artifact Ownership — 主代理不得直接修改子代理产物** (v0.29.0 §37): 子代理是其产物的唯一负责人（architecture-design → `architecture/` 目录，spec-writer → `proposal.md`/`specs/`/`design.md`/`tasks.md`，contract-builder → `execution-contract.md`）。主代理（workflow-start）不得通过 Read + Edit/Write 直接修改子代理的产物文件。修改必须通过 `SendMessage` 恢复原子代理（优先）或启动新子代理执行。例外：仅当子代理无法启动且用户明确授权时，主代理可直接修改，但必须在修改后重新触发对应的 review 验证
+- **Artifact Ownership — 主代理不得直接修改子代理产物** (v0.29.0 §37): 子代理是其产物的唯一负责人（architecture-design → `architecture/` 目录，spec-writer → `proposal.md`/`specs/`/`design.md`/`tasks.md`，contract-builder → `execution-contract.md`，build-executor → 代码文件）。主代理（workflow-start）不得通过 Read + Edit/Write 直接修改子代理的产物文件。修改必须通过 `SendMessage` 恢复原子代理（优先）或启动新子代理执行。**v0.39.0 强化**：主代理 MUST NOT 直接 Edit/Write 任何文件 under `changes/<name>/` 或 `.worktrees/`——无论改动量大小，必须通过 SendMessage 委托子代理执行。例外：仅当子代理无法启动且用户明确授权时，主代理可直接修改，但必须在修改后重新触发对应的 review 验证
+- **修复后必须 re-review** (v0.39.0): build-executor 修复 findings 后，workflow-start 必须 dispatch code-reviewer re-review 确认修复有效，记录 review receipt（verdict=pass）。禁止在 review receipt 未记录或 verdict!=pass 时进入下一阶段
 - **No cross-change artifact modification (v0.30.0)**: 处理 change X 时 **MUST NOT** 编辑 `changes/Y/`（Y≠X）下任何产物。发现跨 change 依赖/问题时：① 在 change X 的 ADR/proposal 中显式声明依赖；② change Y 进入 workflow-start 时，扫描是否有其他 change 声明了对 Y 的依赖并提醒用户；③ change Y 的产物修改必须走 Y 自己的完整流程（architecture-design → auto-review → DP-A），不得绕过。跨 change 一致性核查可调度 `cross-change-consistency-checker` agent（来源：workflow-feedback 2026-08-01）
 
 ## State Writes (v0.22.5 F06 修复)