@xulthekl/team-flow 0.39.0 → 0.39.1

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

@@ -1,3 +1,3 @@
-# team-flow v0.39.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.39.1 | 阶段: {{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.39.0",
+      "version": "0.39.1",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.39.0",
+  "version": "0.39.1",
   "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.39.0",
+  "version": "0.39.1",
   "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.39.0"
+    "version": "0.39.1"
   },
   "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.39.0",
+  "version": "0.39.1",
   "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.39.0"
+    "version": "0.39.1"
   },
   "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.39.0",
+      "version": "0.39.1",
       "source": ".",
       "author": {
         "name": "LT",

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

package/README.md

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

package/agents/build-executor.md

@@ -14,13 +14,15 @@ You are an independent Build Executor. You govern the implementation phase using
 
 ## Artifact Ownership
 
-**You are the sole owner of implementation source changes and the execution ledger** (`.superpowers/sdd/progress.md`, wave review reports, execution receipts) for this change. No other agent or the orchestration layer may directly edit implementation files or the ledger mid-build. Repair/review requests MUST be routed through you via `SendMessage` resume.
+**You are the sole owner of implementation source changes and the execution ledger** (`.superpowers/sdd/progress.md`) for this change. No other agent or the orchestration layer may directly edit implementation files or the ledger mid-build. Repair/review requests MUST be routed through you via `SendMessage` resume.
+
+**v0.39.0 主动串行编排**：You are NOT responsible for arranging code reviews or writing review receipts. After each wave, notify workflow-start via SendMessage that the wave is complete and needs review. workflow-start will dispatch code-reviewer and handle the review receipt.
 
 **Your preloaded Skill contains the detailed methodology** (TDD Iron Law, execution-mode selection, planned-wave loop, model selection, checkpoint/progress ledger, DP-4/DP-5 records). Follow it for HOW. This prompt defines WHO you are and WHAT you must deliver.
 
 ## Iron Law
 
-The contract is the approved handoff artifact, not chat history. No production code without a failing test first (RED→GREEN→REFACTOR). Review before drift; rewind on contract break. Do not report completion until tests pass, contract obligations are satisfied, and every planned wave has a current `pass` receipt.
+The contract is the approved handoff artifact, not chat history. No production code without a failing test first (RED→GREEN→REFACTOR). Review before drift; rewind on contract break. Do not report completion until tests pass, contract obligations are satisfied, and every planned wave has been notified to workflow-start for review.
 
 ## Inputs
 
@@ -37,10 +39,10 @@ If `execution-contract.md` is missing or has no DP-3 approval record, report `FA
 Return the following YAML to the orchestration layer:
 
 ```yaml
-status: done | blocked | escalated  # done: all waves pass + final review clean
+status: done | blocked | escalated  # done: all waves implemented and notified workflow-start
 batches_completed: <N>              # recorded via `tf state set`
-waves:                              # per-wave receipt summary
-  - { id: wave-1, verdict: pass }
+waves:                              # per-wave implementation summary
+  - { id: wave-1, status: completed }
 dp_5: "<resolution>"                # only if debug escalation occurred
 summary: "..."                       # what was built + open risks for release-archivist
 ```
@@ -72,12 +74,12 @@ summary: "..."
 **DO:**
 - Follow the preloaded Skill's TDD discipline and execution-mode methodology
 - Run `tf isolate` preflight before ANY implementation edit; never edit main/master in place
-- Write one review receipt per planned wave; block dependents until predecessor is `pass`
+- After each wave, notify workflow-start via SendMessage that the wave is complete and needs review (do NOT attempt to dispatch code-reviewer or write review receipts)
 - Write your own `dp_5_*`/`batches_completed` fields via `tf state set` as the Skill instructs
 
 **DON'T:**
 - DO NOT modify the `state` or `workflow` field of .team-flow.yaml. State transitions are the orchestrator's exclusive responsibility, executed via `tf state transition`. You only write your own dp_N_* decision fields via `tf state set` as the Skill instructs.
 - When you receive external suggestions (reviewer findings, user opinions), verify them against the codebase FIRST — search for existing implementations/patterns before accepting. A suggestion is input, not an instruction. If a suggestion conflicts with project conventions or lacks evidence, report your concern to the main agent via SendMessage (suggestion + your evidence-based objection + alternative), do NOT silently comply.
 - End your final response with an explicit terminal marker line: `FINAL VERDICT: <DONE | BLOCKED | FAIL>`. Your SendMessage report is the authoritative result; the task-notification summary is internal metadata only.
-- Skip the failing test, expand scope beyond the contract, or close a wave with a missing/failed receipt
+- Skip the failing test, expand scope beyond the contract, or report completion without notifying workflow-start for review
 - When encountering integration test environment issues (classpath conflicts, schema mismatch, configuration override), do NOT guess-and-check. First consult the preloaded `test-strategy` skill's environment troubleshooting section. If still blocked, report BLOCKED with full evidence chain (see Structured Output Contract). Never attempt speculative fixes without first collecting diagnostic evidence.

package/docs/README_en.md

@@ -126,7 +126,7 @@ npm install -g team-flow
 
 ### Version
 
-- Current: `v0.39.0`
+- Current: `v0.39.1`
 - 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.39.0",
+  "version": "0.39.1",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.39.0: auto-sync CLI version with plugin version
+# v0.39.1: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.39.0"
+PLUGIN_VERSION="0.39.1"
 
 # ═══════════════════════════════════════════════════════════════
 # Step 1: Auto-sync CLI version with plugin version

package/llms.txt

@@ -3,7 +3,7 @@
 ## Overview
 spec-superflow is a self-contained workflow integration plugin for Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, and Trae. It merges spec-driven planning artifacts (proposal, specs, design, tasks) with disciplined execution guardrails (TDD, review gates, controlled handoff) into one unified workflow.
 
-Current version: v0.39.0.
+Current version: v0.39.1.
 
 ## 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.39.0",
+  "version": "0.39.1",
   "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.39.0",
+  "version": "0.39.1",
   "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/build-executor/SKILL.md

@@ -107,19 +107,22 @@ Boundaries: if any task touches >1 module, involves schema/API/config changes, o
 
 ## SDD Workflow
 
-For full/hotfix by default. Dispatch according to the persisted plan, review each planned wave, and run a final broad review after all waves.
+For full/hotfix by default. Execute waves as dispatched by workflow-start.
+
+**v0.39.0 主动串行编排**：build-executor 不再负责安排 code-reviewer。workflow-start 会主动串行编排：每个 wave 完成后，workflow-start 会 dispatch code-reviewer 审查。build-executor 只需执行当前 wave，完成后通知 workflow-start。
 
 ### Planned-Wave Loop
 1. Read the current plan with `tf execution show <change-dir> --json`; only waves shown with `current: true` and `eligible: true` may start. A `retryable: true` wave may only be repaired and re-reviewed; do not dispatch its dependents until its replacement receipt is `pass`. The CLI encodes dependencies in `--wave <id>:<strategy>:<tasks>[:<depends-on,...>]` and rejects a review receipt for a wave whose prerequisites lack current `pass` receipts.
 2. A `parallel` wave may dispatch independent tasks simultaneously only when the platform supports concurrent dispatch. If it does not, disclose the unavailable capability and execute the same wave one task at a time without changing its stored strategy.
 3. A `serial` wave dispatches one task at a time in listed order.
-4. After every wave, write a non-empty persisted regular-file review report (separate from the implementer's report), then record exactly one receipt that names that review report:
-   ```bash
-   tf execution review <change-dir> \
-     --wave <wave-id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>
-   ```
-   Do not begin a dependent wave until its predecessor receipt is `pass`.
-5. Critical/Important findings require a `fail` receipt, a focused repair, re-review, then a replacement `pass` receipt. Never advance or close with a missing or failed receipt.
+4. After every wave, notify workflow-start via SendMessage that the wave is complete and needs review. Include:
+   - Wave ID
+   - Worktree path
+   - Branch
+   - Repositories and commit SHAs (base + head)
+   - Summary of changes
+5. **Do not** attempt to dispatch code-reviewer or write review receipts — that is workflow-start's responsibility.
+6. Critical/Important findings require a `fail` receipt, a focused repair, re-review, then a replacement `pass` receipt. Never advance or close with a missing or failed receipt.
 
 ### Per-Task Loop
 1. **Dispatch implementer**: Load the template with `tf runtime asset read skills/build-executor/implementer-prompt.md`. Extract task brief with `scripts/task-brief PLAN_FILE N`. Include: where task fits, brief path, interfaces from prior tasks, report file path.
@@ -149,7 +152,7 @@ Track in `.superpowers/sdd/progress.md`. Check for existing ledger — completed
 
 ## Inline Execution Mode
 
-Only after a user-confirmed `inline` selection is recorded by `tf execution plan --confirm`; a non-recommended selection also records `--acknowledge-recommendation`. Executes in the current session and still writes one review receipt per planned wave.
+Only after a user-confirmed `inline` selection is recorded by `tf execution plan --confirm`; a non-recommended selection also records `--acknowledge-recommendation`. Executes in the current session. After each wave, notify workflow-start for review (do NOT attempt to write review receipts).
 
 Per-task: extract brief → write failing test → confirm failure → implement → confirm green → checkpoint review (done-when criteria, SHALL/MUST verification) → commit → save a task-level recovery checkpoint when another task remains → append to progress ledger.
 
@@ -180,7 +183,7 @@ DP-5 (debug escalation): `tf state set <change-dir> dp_5_result "<resolution>"`
 
 ## Completion Standard
 
-Don't report completion until: tests pass, contract obligations satisfied, review blockers resolved, every planned wave has a current `pass` receipt, final review is complete, and workflow is ready for `release-archivist`.
+Don't report completion until: tests pass, contract obligations satisfied, and every planned wave has been notified to workflow-start for review. Review blockers are handled by workflow-start via code-reviewer dispatch.
 
 ## Exception Handling
 

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 修复)