@xulthekl/team-flow 0.41.0 → 0.43.1

package/skills/architecture-design/templates/change-brief.md

@@ -1,7 +1,7 @@
 ---
 upstream_source: orchestrator | manual | null
 upstream_req_id: <req-id>
-upstream_plan_ref: prd/vN/plan.md
+upstream_plan_ref: requirement/vN/plan.md
 upstream_change_id: C2
 plan_hash: sha256:<plan.md 内容摘要>
 ---
@@ -25,5 +25,5 @@ plan_hash: sha256:<plan.md 内容摘要>
 
 ## PRD & plan 引用
 
-- PRD: prd/vN/prd.md §<相关章节>
-- Plan: prd/vN/plan.md ### <C-ID>
+- PRD: requirement/vN/prd.md §<相关章节>
+- Plan: requirement/vN/plan.md ### <C-ID>

package/skills/build-executor/SKILL.md

@@ -46,7 +46,7 @@ Branch/worktree preflight before ANY implementation edit (mandatory — do not s
 ### UI Contract Prototype Location (v0.37.0 §68.5)
 
 When implementing UI tasks, the UI contract source is the **prototype version worktree**, not the change worktree's prototype copy:
-- **定位**：读 `change-brief.md` 的 `upstream_plan_ref: prd/vN/plan.md`（或 change 目录名 `v{N}-` 前缀）→ PRD 版本 vN → 原型 worktree = `<workspace>/.worktrees/prd-vN/prototype/`
+- **定位**：读 `change-brief.md` 的 `upstream_plan_ref: requirement/vN/plan.md`（或 change 目录名 `v{N}-` 前缀）→ PRD 版本 vN → 原型 worktree = `<workspace>/.worktrees/prd-vN/prototype/`
 - **回退**：该 worktree 不存在时用 `<workspace>/prototype/`，并提示 `tf prototype branch <prd-vN>` 创建
 - **引用**：execution-contract / design.md 中引用的原型页面（`prototype/pages/<page>.html` 等）以此为基准定位；**禁止**引用主干上其他版本的旧原型
 
@@ -111,6 +111,14 @@ 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。
 
+### Test Infrastructure Check (v0.43.1, before first wave)
+
+开始实施前检测项目测试基础设施，避免测试静默跳过（设计增强方案 v0.18 §76，来源：workflow-feedback 2026-08-06——surefire 2.22.2 不支持 JUnit 5 `@Nested`，64% 测试从未执行但报告 "91 tests pass"）：
+
+1. **Java 项目**：读 `pom.xml` 的 maven-surefire-plugin 版本 + JUnit 版本。
+2. **兼容性判断**：surefire < 2.22.2 且测试计划含 JUnit 5 `@Nested` → 警告"@Nested 自动发现不兼容，建议 flatten 测试类或升级 surefire"。
+3. **沉淀 conventions**：检测结果写入 `.team-flow/conventions/`（项目级测试基础设施约束，v0.11 §33 机制），供后续 change 复用。写入方式沿用下方「阶段转换前规范建议」协议——YAML frontmatter（name/description/date）+ 正文约束，用户确认后追加，更新 date 字段。
+
 ### 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.
@@ -124,12 +132,24 @@ For full/hotfix by default. Execute waves as dispatched by workflow-start.
 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.
 
+### Wave Verify: Actual Test Count (v0.43.1)
+
+每个 wave 完成、通知 workflow-start 审查前，验证测试**实际执行**的数量（设计增强方案 v0.18 §76，来源：workflow-feedback 2026-08-06——64% 测试静默跳过但报告全绿）：
+
+1. 运行测试套件后，用 `tf test record <change-dir> --from <runner-output-file>` 解析**实际执行数量**（`Tests run: N`）。
+2. 对照 test-matrix 当前 wave 覆盖的用例数（**分母排除 `test_tier=e2e`**——E2E case 由 Playwright 执行，不进入 `mvn test`/`npm test` 的 `Tests run: N`，口径与 code-reviewer Step 5b / release-archivist Step 2b 一致）：实际执行数明显低于预期（< 70%）→ **警告 + 调查**（@Nested 静默跳过、测试未被发现、编译期跳过等），未查明前不得报告 "N tests pass"。
+3. 报告引用实际执行数（`Tests run: N`），而非 BUILD SUCCESS 或编译通过数量。
+
 ### 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.
 2. **Handle response**: DONE → generate review package + dispatch reviewer. DONE_WITH_CONCERNS → assess. NEEDS_CONTEXT → provide context. BLOCKED → re-dispatch with better model or escalate.
-3. **Review**: Load `tf runtime asset read skills/build-executor/task-reviewer-prompt.md`. Reviewer returns spec compliance + code quality verdicts with the wave ID, git range, report path, and `pass`/`fail` receipt command.
-4. **Fix**: If Critical or Important issues, write the `fail` receipt, dispatch fix subagent, re-review, and write the replacement `pass` receipt.
-5. **Mark complete**: Append to `.superpowers/sdd/progress.md`: `Task N: complete (commits <base7>..<head7>, review clean)`
+3. **Verify task output（v0.43.1）**：任务标记完成前验证产物——**前置到审查前**（源头校验：文件存在性是审查的前提，让 reviewer 专注质量而非兜底）。设计增强方案 v0.18 §75，来源：workflow-feedback 2026-08-06——Task 标记 [x] 但文件未创建）：
+   - Create 任务：目标文件必须存在且非空（`test -s <path>`）
+   - Modify 任务：目标文件必须有变更（相对 wave base 的 `git diff --name-only` 包含该文件）
+   - 验证失败 → 不标记完成，先补创建/修改——"标记完成"与"文件存在"绑定，杜绝任务状态失真
+4. **Review**（task 级轻量审查；wave 级 code-reviewer 由 workflow-start 主动编排，v0.39.0）: Load `tf runtime asset read skills/build-executor/task-reviewer-prompt.md`. Reviewer returns spec compliance + code quality verdicts with the wave ID, git range, report path, and `pass`/`fail` receipt command.
+5. **Fix**: If Critical or Important issues, write the `fail` receipt, dispatch fix subagent, re-review, and write the replacement `pass` receipt.
+6. **Mark complete**: Append to `.superpowers/sdd/progress.md`: `Task N: complete (commits <base7>..<head7>, review clean)`
 
 ### Model Selection
 Use the configured profile that matches the task role. Resolve it before dispatch:

package/skills/build-executor/implementer-prompt.md

@@ -140,6 +140,7 @@ Subagent (general-purpose):
     - Did I follow TDD if required?
     - Are tests comprehensive?
     - Is the test output pristine (no stray warnings or noise)?
+    - Tests actually EXECUTED (`Tests run: N`), not just compiled — surefire/@Nested version mismatches can silently skip tests (v0.43.1)
     - If test-matrix.md exists: matrix coverage = passed cases / total cases for my module
     - Each case's `design_method` matches the actual test approach (boundary case uses real boundary values, not happy-path disguised as boundary)
 

package/skills/ce-brainstorm/SKILL.md

@@ -8,7 +8,7 @@ argument-hint: "[feature idea or problem to explore] [output:html]"
 
 **Note: The current year is 2026.** Use this when dating PRD documents.
 
-Brainstorming answers **WHAT** to build through collaborative dialogue, producing a **PRD document** (产品需求文档). It precedes `/ce-plan` (**HOW** to build). In compound engineering, write under `prd/vN/prd.md`. The PRD template is configurable via `prd.template` config (default: `templates/prd.md`). This skill explores, clarifies, and documents — it does not implement code.
+Brainstorming answers **WHAT** to build through collaborative dialogue, producing a **PRD document** (产品需求文档). It precedes `/ce-plan` (**HOW** to build). In compound engineering, write under `requirement/vN/prd.md`. The PRD template is configurable via `prd.template` config (default: `templates/prd.md`). This skill explores, clarifies, and documents — it does not implement code.
 
 ## 调用模式（v0.7 新增）
 
@@ -31,6 +31,42 @@ Brainstorming answers **WHAT** to build through collaborative dialogue, producin
 6. **YAGNI on carrying cost, not coding effort** — Simplest approach that delivers value; low-cost polish is worth including.
 7. **Don't turn coverage into decomposition** — Named devices/providers are coverage requirements, not separate workstreams.
 
+## Execution Architecture (v0.43.0+)
+
+> **核心原则：主会话负责规划和决策，子会话负责执行性产出。**
+
+### Session Split
+
+| 职责 | 执行方 | 说明 |
+|------|--------|------|
+| 需求澄清、场景确认、流程确认、方案决策 | **主会话** | 需要用户交互和判断的工作 |
+| PRD 文档撰写（Phase 3） | **子代理**（推荐） | 执行性文档生成，主会话做 QA 和冻结 |
+| 流程图绘制（mermaid） | **子代理**（推荐） | 基于已确认的流程数据生成图表 |
+| 活动表批量生成 | **子代理**（推荐） | 基于已确认的 L4 子流程生成表格 |
+| 综合报告（synthesis summary） | **子代理**（可选） | 大量数据的汇总整理 |
+
+**子代理委托方式**：使用 `Agent` 工具（`context: fork` 或自定义 agent），将已确认的结构化数据作为输入，要求子代理按模板产出。主会话审查产出后决定接受或修正。
+
+### Stage Breakpoints
+
+全流程设置 **4 个断点**，每个断点提供三个选项：
+
+| 断点 | 位置 | 触发时机 |
+|------|------|---------|
+| **BP-1** | Phase 1.5 之后 | 所有场景确认完成后 |
+| **BP-2** | Phase 1.6 之后 | 所有流程确认完成后 |
+| **BP-3** | Phase 2 之后 | 方案探索完成后 |
+| **BP-4** | Phase 2.5 之后 | 综合确认完成后（PRD 生成前） |
+
+**断点交互**（blocking question）：
+
+> "✅ [阶段名] 已完成。请选择：
+> 1. **继续** — 进入下一阶段
+> 2. **暂停并保存进度** — 保存当前产出，稍后可从断点恢复
+> 3. **回退修改** — 返回上一阶段进行调整"
+
+**Lightweight 模式例外**：Lightweight scope 可跳过 BP-1 至 BP-3（需求已足够清晰时），仅保留 BP-4。
+
 ## Interaction Rules
 
 1. **One question at a time** — Pick the single most useful one.
@@ -103,13 +139,13 @@ Built-in `templates/prd.md` is relative to the skill's base directory. Custom pa
 
 For detailed routing logic, read `references/phase0-routing.md`. Summary:
 
-- **0.1 Resume**: scan `prd/` for existing work; confirm before resuming
+- **0.1 Resume**: scan `requirement/` for existing work (legacy: fallback `prd/`); confirm before resuming
 - **0.1b Classify**: software → continue; non-software → `references/universal-brainstorming.md`; neither → respond directly
 - **0.1c Verdict**: verdict-shaped requests → offer `/ce-pov` handoff via `references/verdict-routing.md`
 - **0.2 Assess**: clear requirements → skip to Phase 2.5; ambiguous → full brainstorm
 - **0.3 Scope**: Lightweight / Standard / Deep (+ feature vs product); arm visual-probe and blindspot tripwires
 - **0.4 Spine**: create 5-task tracking spine for Standard/Deep
-- **0.5 Iteration**: resolve `ITERATION_VERSION` from `prd/` directory
+- **0.5 Iteration**: resolve `ITERATION_VERSION` from `requirement/` directory (legacy: fallback `prd/`)
 
 ### Phase 1: Understand the Idea
 
@@ -123,7 +159,11 @@ For detailed routing logic, read `references/phase0-routing.md`. Summary:
 
 **1.5 Business Scenario Analysis** — Read `references/business-scenarios.md` for methodology. Trigger: Phase 1.4 completed. Extract business scenarios from dialogue and context, produce QA-1 quality check, then **blocking question** for user confirmation. Output: `requirement/vN/business-analysis.md` (requirements + scenarios sections). Status marked 🔵 pending confirmation, ✅ confirmed on user approval. No ledger update at this stage.
 
-**1.6 Business Process Analysis** — Read `references/business-processes.md` for methodology. Trigger: Phase 1.5 confirmed (✅). Extract business processes, produce QA-2 quality check, then **blocking question** for user confirmation. Output: update `requirement/vN/business-analysis.md` (processes section + scenario/requirement association fields). Status marked 🔵 pending, ✅ confirmed on approval. No ledger update at this stage.
+> **🔲 BP-1 Breakpoint** — 场景确认后触发断点交互（Lightweight 可跳过）。
+
+**1.6 Business Process Analysis** — Read `references/business-processes.md` for methodology. Trigger: Phase 1.5 confirmed (✅). **Step 0: ask user to define L1–L3 hierarchy** (AI does NOT guess L1–L3). Then derive L4 sub-processes under user's framework, produce QA-2 quality check, then **two-stage confirmation** (L1–L3 framework → L4 details per process). Output: update `requirement/vN/business-analysis.md` (processes section + scenario/requirement association fields). Status marked 🔵 pending, ✅ confirmed on approval. No ledger update at this stage.
+
+> **🔲 BP-2 Breakpoint** — 流程确认后触发断点交互（Lightweight 可跳过）。
 
 ### Phase 2: Explore Approaches
 
@@ -135,12 +175,16 @@ Propose **2-3 approaches** (or recommend directly if one is clearly best). Use n
 
 **Granularity: profile-driven product thinking, not architecture.** Address profile dimensions (business process, state model, permissions, data, rules, functions). Do NOT cross into implementation specifics (tables, paths, classes, APIs).
 
+> **🔲 BP-3 Breakpoint** — 方案探索完成后触发断点交互（Lightweight 可跳过）。
+
 ### Phase 2.5: Synthesis Summary
 
 **Read `references/synthesis-summary.md` before composing.** Surface scoping synthesis — user's last chance to correct scope. Fires for all tiers. Path A (announce-only) for Lightweight + no blocking questions; Path B (confirmation gate) for all others. 2.6: dispatch claim verifier during Path B confirmation wait.
 
 **QA-3 quality check** fires after synthesis draft is complete, before the blocking question. Synthesis must reference confirmed scenario IDs (SC-xxx) and process IDs (BP-xxx) as evidence anchors. Unconfirmed (🔵) items are flagged in Call outs section.
 
+> **🔲 BP-4 Breakpoint** — 综合确认完成后、PRD 生成前触发断点交互（**所有 scope 必须触发**，不可跳过）。
+
 ### Phase 3: Generate PRD Document
 
 **Inputs** (read before generating PRD):
@@ -166,6 +210,8 @@ Propose **2-3 approaches** (or recommend directly if one is clearly best). Use n
 
 Read `references/brainstorm-sections.md` for doc-warranted criteria. If warranted: read template from `PRD_TEMPLATE_PATH`, fill via `references/prd-mapping.md`, write to `requirement/{ITERATION_VERSION}/prd.md`. Vocabulary capture: update `CONCEPTS.md` with resolved domain terms (only if it exists).
 
+> **子代理委托建议**：Phase 3 PRD 文档撰写是执行性工作，建议委托子代理完成。主会话将已确认的结构化数据（business-analysis.md + dialogue-log.md + synthesis summary）作为输入传给子代理，子代理按模板填充后产出 PRD 草稿，主会话负责 QA-4 审查和冻结确认。
+
 ### Phase 3.5: Prototype Inner Loop
 
 **`orchestrated` mode skips this phase.** For standalone: read `references/prototype-loop.md`. Trigger: PRD has UI functions. Steps: produce prototype → review vs PRD → fix loop (max 3) → completeness review → freeze PRD.

package/skills/ce-brainstorm/references/brainstorm-sections.md

@@ -9,7 +9,7 @@ the format-specific references (`markdown-rendering.md`, `html-rendering.md`).
 
 A great brainstorm produces the PRD document (业务要件) that defines **WHAT** to build.
 `ce-plan` then reads the PRD and produces an **independent implementation plan** (实施方案) that defines **HOW** to build it.
-The PRD and plan are separate documents in the same `prd/vN/` directory.
+The PRD and plan are separate documents in the same `requirement/vN/` directory.
 
 The PRD enables three audiences to act:
 
@@ -27,7 +27,7 @@ Sections earn their place by serving one of these audiences. Omit padding.
 
 New `ce-brainstorm` outputs follow the PRD artifact contract:
 
-- **Path:** `prd/vN/prd.md` (N is the iteration version number, e.g., v1, v2).
+- **Path:** `requirement/vN/prd.md` (N is the iteration version number, e.g., v1, v2). Legacy fallback: `prd/vN/prd.md`.
 - **Metadata:** `project_name`, `iteration_version`, `prd_template` (template path).
 - **Template source:** read `prd.template` from project configuration, or use
   the default `templates/prd.md`.
@@ -303,7 +303,7 @@ Every PRD produced by `ce-brainstorm` carries metadata in YAML frontmatter.
 - **`title`** — PRD title in format `{项目名称}_D7_业务要件` (matching the H1).
 - **`project_name`** — the project or product name.
 - **`iteration_version`** — the iteration version (e.g., "v1", "v2"),
-  corresponding to the `prd/vN/` directory.
+  corresponding to the `requirement/vN/` directory.
 - **`date`** — creation date in ISO 8601 (`YYYY-MM-DD`).
 - **`prd_template`** — relative path to the PRD template used (e.g.,
   `templates/prd.md`).

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

@@ -12,7 +12,31 @@ Detailed process derivation and structured output logic for Phase 1.6. The main
 - `requirement/vN/business-analysis.md` — confirmed scenarios with IDs (✅ SC-xxx)
 - `requirement/ledger.md` — archived process records from prior versions
 
-## Step 1: Derive Processes from Scenarios
+## Step 0: Elicit User's L1–L3 Hierarchy (v0.43.0+)
+
+> **核心原则**：L1–L3 是组织级知识（流程分类、流程分组、业务流程），用户通常已有清晰的规划。AI 的价值集中在 L4 子流程的细化上（活动拆解、步骤说明、异常处理）。不要自行猜测 L1–L3。
+
+**Blocking question** — 在推导任何流程之前，先询问用户：
+
+> "你们通常如何组织业务流程？请按以下层级告诉我：
+> - **L1 流程分类**（如：核心业务、支撑管理、战略决策）
+> - **L2 流程分组**（如：采购管理、销售管理、人力资源）
+> - **L3 业务流程**（如：采购申请流程、供应商评审流程）"
+
+**如果用户不熟悉 L1–L4 概念**，提供简要说明：
+
+| 层级 | 含义 | 示例 |
+|------|------|------|
+| L1 流程分类 | 最高层流程域划分 | 核心业务 / 支撑管理 |
+| L2 流程分组 | 分类下的业务领域 | 采购管理 / 销售管理 |
+| L3 业务流程 | 具体的端到端业务流程 | 采购申请流程 |
+| L4 子流程 | 流程内的具体活动段（AI 协助细化） | 需求提报 / 审批 / 下单 |
+
+**确认 L1–L3 框架后才进入 Step 1。** 如果用户说"你来帮我规划"或"我没有现成的分类"，AI 可以基于已确认的业务场景（SC-xxx）推导 L1–L3 建议，但必须经用户确认。
+
+## Step 1: Derive L4 Sub-processes from Scenarios
+
+Based on the user-confirmed L1–L3 framework, derive L4 sub-processes for each L3 process:
 
 For each confirmed scenario, derive a step sequence using BPMN thinking:
 
@@ -21,7 +45,7 @@ For each confirmed scenario, derive a step sequence using BPMN thinking:
 - **Events**: start event, intermediate events, end event
 - **Gateways**: decision points that branch the flow (exclusive / parallel / inclusive)
 
-Produce one draft process per scenario. A scenario may map to one or more L4 sub-processes.
+Map each scenario to the appropriate L3 process (from user's framework), then produce L4 sub-processes under that L3. A scenario may map to one or more L4 sub-processes.
 
 ## Step 2: Compare Against Existing Processes
 
@@ -42,12 +66,12 @@ Classify each draft process:
 
 ### 3.1 L1–L4 Classification Table
 
-Fill the business process overview table (aligns with PRD §2):
+Fill the business process overview table (aligns with PRD §2). **L1–L3 come from the user-confirmed framework (Step 0); L4 is derived by AI (Step 1):**
 
-| L1 Group | L2 Category | L3 Process | L4 Sub-process | Status | Related Scenarios |
+| L1 Group (用户定义) | L2 Category (用户定义) | L3 Process (用户定义) | L4 Sub-process (AI 细化) | Status | Related Scenarios |
 |----------|-------------|------------|----------------|--------|-------------------|
 
-**Hierarchy**: L1 → L2 → L3 → L4. L3 is a collection of L4 sub-processes. Each ledger record corresponds to one L4. **L4 is the minimum recording unit.**
+**Hierarchy**: L1 → L2 → L3 → L4. L1–L3 are user-defined organizational structure; L4 is AI-assisted refinement. L3 is a collection of L4 sub-processes. Each ledger record corresponds to one L4. **L4 is the minimum recording unit.**
 
 ### 3.2 Process Flow Diagram
 
@@ -117,12 +141,21 @@ Dispatch `process-quality-checker` sub-agent. Evaluate 9 checks:
 
 **Routing**: All Error checks PASS → proceed to Step 5. Any Error FAIL → return to correct (max 3 rounds). Warnings are reported but do not block.
 
-## Step 5: Display & Confirmation
+## Step 5: Layered Display & Confirmation (v0.43.0+)
+
+Use **two-stage confirmation** to reduce correction cost:
+
+**Stage A — L1–L3 Framework Review:**
+Present the L1–L4 classification table (3.1) to the user. Focus on confirming the L1–L3 framework is correct:
+- ✅ **L1–L3 框架确认** → proceed to Stage B
+- ✏️ **L1–L3 需要调整** → apply feedback on L1–L3; re-derive L4 under adjusted framework; re-present Stage A
 
-Present all three output forms to the user as a blocking question:
+**Stage B — L4 Detail Review (per L3 process):**
+For each L3 process, present its L4 sub-processes with flow diagrams (3.2), activity tables (3.3), and attribute blocks (3.4) as a blocking question:
+- ✅ **Confirmed** → upgrade status to ✅ 已确认
+- ✏️ **Adjust** → apply feedback; return to Step 3 for this L3; loop until confirmed
 
-- ✅ **Confirmed** → upgrade status to ✅ 已确认; write into current version `business-analysis.md`; exit (no ledger update).
-- ✏️ **Adjust** → apply feedback; return to Step 3; loop until confirmed.
+After all L3 processes confirmed: write into current version `business-analysis.md`; exit (no ledger update).
 
 ## Write Rules
 

package/skills/ce-brainstorm/references/handoff.md

@@ -112,7 +112,7 @@ Do not print the closing summary first.
 
 Load the `ce-proof` skill to publish the markdown PRD document. Pass:
 
-- **source file:** `prd/vN/prd.md`
+- **source file:** `requirement/vN/prd.md` (legacy: `prd/vN/prd.md`)
 - **doc title:** `PRD: <topic title>`
 - **identity:** `ai:compound-engineering` / `Compound Engineering`
 

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

@@ -4,16 +4,17 @@ Detailed routing logic for Phase 0 sub-phases. Phase 0.0 (output format + templa
 
 ## 0.1 Resume Existing Work When Appropriate
 
-If the user references an existing brainstorm topic or document, or there is an obvious recent matching PRD in the `prd/` directory:
-- Scan `prd/` for existing iteration versions (v1, v2, ...)
+If the user references an existing brainstorm topic or document, or there is an obvious recent matching PRD:
+- **Scan `requirement/` first** for existing iteration versions (v1, v2, ...)
+- **Legacy fallback**: if `requirement/` does not exist, scan `prd/` for existing versions
 - Read the latest PRD document
 - Confirm with the user before resuming: "Found an existing PRD for [topic]. Should I continue from this, or start fresh?"
 - 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.
+**`requirement/` is the authoritative source (v0.43.0+).** 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 `requirement/` and legacy `prd/` exist, merge signals from both (dedup by version number); when only `requirement/` exists, treat it as the authoritative source for resume decisions. **Do not create `prd/` directory for new projects.**
 
-Historical `docs/brainstorms/*-requirements.{md,html}` files remain legacy inputs for `ce-plan`, but new outputs write to `prd/{ITERATION_VERSION}/prd.md`.
+Historical `docs/brainstorms/*-requirements.{md,html}` files remain legacy inputs for `ce-plan`. New outputs write to `requirement/{ITERATION_VERSION}/prd.md`.
 
 ## 0.1b Classify Task Domain
 
@@ -89,14 +90,14 @@ The spine is five tasks, in order:
 
 ## 0.5 Resolve Iteration Version
 
-Scan the `prd/` directory to detect existing iteration versions (v1, v2, v3, ...).
-- 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.
+**Scan `requirement/` first** to detect existing iteration versions (v1, v2, v3, ...).
+- **Legacy fallback**: if `requirement/` does not exist, scan `prd/` for iteration versions.
+- When both `requirement/` and legacy `prd/` exist, union the detected versions (dedup by version number) 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 no iterations exist in either directory: suggest creating v1, ask user to confirm. **Only create `requirement/vN/` — do not create `prd/` directory.**
 - 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.
+- **Target PRD path: `requirement/{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. When reading from legacy `prd/` projects, continue to read existing files there but write new outputs to `requirement/`.
 - Scan `prototype/` directory to confirm prototype branch aligns with PRD iteration version (if prototype exists).

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

@@ -58,8 +58,8 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 
 ## 迭代版本（vN）
 
-- `prd/vN/` 或 `requirement/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
-- ce-brainstorm 启动时扫描 `prd/` 和 `requirement/` 目录检测已有迭代（`requirement/` 优先）
+- `requirement/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
+- ce-brainstorm 启动时扫描 `requirement/` 目录检测已有迭代（legacy fallback: `prd/`）
 - 自动建议最新迭代或创建新迭代，用户确认后继续
 - 每个迭代目录下只有一个 `prd.md` 文件
 
@@ -75,7 +75,7 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 | 产品版本 | 正文 §1.1 版本信息 | `vN.M`（v1.0/v1.1/…） | **文档修订次版本** | vN 内每次修订递增 M（呼应反馈环路「vN 内修订不升版」）|
 
 - vN 内修订（S3→S2 回退修订）→ 只递增正文 `vN.M` 的 M，**frontmatter `iteration_version` 不变**，并在 §1.2 修订记录追加一行 + 「决策与变更履历」章节记录。
-- 新迭代 → frontmatter `iteration_version` 升 vN+1，正文产品版本重置为 `v(N+1).0`，新建 `prd/v(N+1)/` 目录。
+- 新迭代 → frontmatter `iteration_version` 升 vN+1，正文产品版本重置为 `v(N+1).0`，新建 `requirement/v(N+1)/` 目录。
 
 **文档状态枚举（§1.1）——必须与 frontmatter `frozen` 一致**：
 

package/skills/ce-brainstorm/references/prototype-loop.md

@@ -42,14 +42,14 @@ PRD 文档写入后、Handoff 之前，执行原型内循环。原型是 PRD 的
 原型审查通过后、冻结前，派发 `prd-completeness-reviewer` 子代理（独立上下文），评审 PRD「是否完整到能支撑后续 plan/spec 实施」（区别于 Phase 2.6 claim verifier——后者管"说得对不对"，本评审管"说得全不全"）。
 
 - 派发：按名派发插件 agent `prd-completeness-reviewer`（定义见插件 `agents/prd-completeness-reviewer.md`），传入 PRD 路径 + CONCEPTS.md 路径。
-- agent 直接写审查报告到 `prd/{ITERATION_VERSION}/prd-completeness-review.md`。
+- agent 直接写审查报告到 `requirement/{ITERATION_VERSION}/prd-completeness-review.md`。
 - 判定（柔性）：PASS / PASS_WITH_WARNINGS → 进入冻结；**FAIL（Critical>0）→ 回 Phase 1.3 补充**后重审。
 - 5 维度：用户故事完整性(Critical)/验收标准(Critical)/边界与非功能(Important)/术语一致性(Minor)/范围闭环(Important)。
 
 ## 3.5.6 冻结
 
 完整性评审通过后：
-1. 写入 `prd/{ITERATION_VERSION}/prototype-review.md`（审查结论 + 版本 + 日期 + 循环次数）
+1. 写入 `requirement/{ITERATION_VERSION}/prototype-review.md`（审查结论 + 版本 + 日期 + 循环次数）
 2. PRD 标记为 frozen（在 PRD frontmatter 中增加 `frozen: true` + `frozen_date: YYYY-MM-DD`），并在正文标题下插入冻结声明（措辞见 `references/prd-mapping.md`「冻结声明」节）
 3. **冻结语义为 `frozen_downstream`（非升版）**：后续阶段（ce-plan、spec-writer）**不可直接回改** PRD；如 plan 或实施暴露 scope 问题，经 **S3→S2 回退在 vN 内修订**并记录「决策与变更履历」（不升版）。**仅当启动新迭代 vN+1 或用户显式绝对冻结（`frozen: absolute`）时才需升版。**
 4. 同步更新正文 §1.1 文档状态为「已冻结-下游」（与 frontmatter `frozen: true` 一致）

package/skills/ce-compound/references/three-tier-index.md

@@ -5,7 +5,7 @@
 ```
 docs/solutions/
 ├── INDEX.md                  # L1：轻量索引（≤150行，每条一行摘要+标签）
-├── prd/                      # 按阶段分目录
+├── requirement/              # 按阶段分目录
 ├── plan/
 ├── prototype/
 ├── spec/

package/skills/ce-plan/SKILL.md

@@ -10,7 +10,7 @@ argument-hint: "[optional: feature description, PRD doc path, plan path to deepe
 
 ## Purpose
 
-`ce-plan` produces an **independent implementation plan** (实施方案) from a PRD or any input, defining **HOW** to build what `ce-brainstorm` scoped as **WHAT**. The PRD and plan are separate documents in the same `prd/vN/` directory. `ce-work` executes implementation-ready plans. A prior brainstorm is useful context but never required.
+`ce-plan` produces an **independent implementation plan** (实施方案) from a PRD or any input, defining **HOW** to build what `ce-brainstorm` scoped as **WHAT**. The PRD and plan are separate documents in the same `requirement/vN/` directory. `ce-work` executes implementation-ready plans. A prior brainstorm is useful context but never required.
 
 **v0.5 scope**: ce-plan focuses on **product-level strategy** — change splitting (scope + dependencies + priority per change), inter-change dependency graph (DAG), and overall technical direction. It does NOT produce file-level Implementation Units, Files lists, or Test scenarios — those belong to spec-writer within each change.
 
@@ -87,7 +87,7 @@ See `references/planning-modes.md` for mode selection logic and PRD chapter mapp
 
 ### Phase 3: Structure the Plan
 
-1. Title: `{项目名称} - 实施方案`. File: `prd/{ITERATION_VERSION}/plan.md`.
+1. Title: `{项目名称} - 实施方案`. File: `requirement/{ITERATION_VERSION}/plan.md`.
 2. Break work into **changes** (C1, C2, …) — focused, independently implementable, dependency-ordered. See `references/change-splitting.md`.
 3. Include a change dependency DAG for 2+ changes. See `references/dependency-graph.md`.
 4. Define each change: Scope, Requirements (cite PRD §), Dependencies (C-ID), Priority (P0/P1/P2), Complexity (S/M/L), Prototype reference.

package/skills/ce-plan/references/core-principles.md

@@ -2,7 +2,7 @@
 
 ## Core Principles
 
-1. **Use the PRD as the source of truth** - If `ce-brainstorm` produced a PRD document, planning should read it as the primary input and produce an **independent implementation plan** (not modify the PRD). The PRD defines WHAT; the plan defines HOW. Both are separate artifacts in the same `prd/vN/` directory.
+1. **Use the PRD as the source of truth** - If `ce-brainstorm` produced a PRD document, planning should read it as the primary input and produce an **independent implementation plan** (not modify the PRD). The PRD defines WHAT; the plan defines HOW. Both are separate artifacts in the same `requirement/vN/` directory.
 2. **Decisions, not code** - Capture approach, boundaries, files, dependencies, risks, and test scenarios. Do not pre-write implementation code or shell command choreography. Pseudo-code sketches or DSL grammars that communicate high-level technical design are welcome when they help a reviewer validate direction — but they must be explicitly framed as directional guidance, not implementation specification.
 3. **Research before structuring** - Explore the codebase, institutional learnings, and external guidance when warranted before finalizing the plan.
 4. **Right-size the artifact** - Small work gets a compact plan. Large work gets more structure. The philosophy stays the same at every depth.

package/skills/ce-plan/references/intake-routing.md

@@ -40,16 +40,16 @@ Pipeline / `disable-model-invocation` runs already skip the chat confirmation (h
 
 ### Resume Existing Plan Work
 
-If the user references an existing plan file or there is an obvious recent matching plan in `prd/vN/plan.md`:
+If the user references an existing plan file or there is an obvious recent matching plan in `requirement/vN/plan.md`:
 - Read it
 - Confirm whether to update it in place or create a new plan
 - If updating, revise only the still-relevant sections. Plans do not carry per-unit progress state — progress is derived from git by `ce-work`, so there is no progress to preserve across edits
 
-**A PRD document is not a resume target.** A `prd/vN/prd.md` file is a *PRD input*, not an existing plan to resume — do **not** fire the update-or-create confirm for it. Fall through to Phase 0.2, which reads it as input for creating a new plan. This matters most for the hands-off `ce-brainstorm` -> `lfg` flow: `lfg` hands `ce-plan` the PRD path in `disable-model-invocation` pipeline mode, where no user is present to answer a resume prompt.
+**A PRD document is not a resume target.** A `requirement/vN/prd.md` file is a *PRD input*, not an existing plan to resume — do **not** fire the update-or-create confirm for it. Fall through to Phase 0.2, which reads it as input for creating a new plan. This matters most for the hands-off `ce-brainstorm` -> `lfg` flow: `lfg` hands `ce-plan` the PRD path in `disable-model-invocation` pipeline mode, where no user is present to answer a resume prompt.
 
 ### Deepen Intent
 
-The word "deepen" (or "deepening") in reference to a plan is the primary trigger for the deepening fast path. When the user says "deepen the plan", "deepen my plan", "run a deepening pass", or similar, the target document is a **plan** in `prd/vN/plan.md`, not a PRD document. Use any path, keyword, or context the user provides to identify the right plan. If a path is provided, verify it is actually a plan document. If the match is not obvious, confirm with the user before proceeding.
+The word "deepen" (or "deepening") in reference to a plan is the primary trigger for the deepening fast path. When the user says "deepen the plan", "deepen my plan", "run a deepening pass", or similar, the target document is a **plan** in `requirement/vN/plan.md`, not a PRD document. Use any path, keyword, or context the user provides to identify the right plan. If a path is provided, verify it is actually a plan document. If the match is not obvious, confirm with the user before proceeding.
 
 Words like "strengthen", "confidence", "gaps", and "rigor" are NOT sufficient on their own to trigger deepening. These words appear in normal editing requests ("strengthen that section about the diagram", "there are gaps in the test scenarios") and should not cause a holistic deepening pass. Only treat them as deepening intent when the request clearly targets the plan as a whole and does not name a specific section or content area to change — and even then, prefer to confirm with the user before entering the deepening flow.
 
@@ -99,8 +99,8 @@ Otherwise, read `references/universal-planning.md` and follow that workflow inst
 
 Before asking planning questions, resolve the upstream PRD source in this order:
 
-1. **Explicit path from the user.** If it points to a PRD document (`prd/vN/prd.md`), read it as the primary input. If it points to an existing plan (`prd/vN/plan.md`), treat it as a resume/deepening target. If it is a legacy `docs/brainstorms/*-requirements.{md,html}` file, use it as a legacy origin.
-2. **Recent PRD documents.** Scan `prd/` directory for iteration versions (v1, v2, ...). For each version, check if `prd.md` exists. Use the latest version's PRD as input.
+1. **Explicit path from the user.** If it points to a PRD document (`requirement/vN/prd.md`), read it as the primary input. If it points to an existing plan (`requirement/vN/plan.md`), treat it as a resume/deepening target. If it is a legacy `docs/brainstorms/*-requirements.{md,html}` file, use it as a legacy origin.
+2. **Recent PRD documents.** Scan `requirement/` directory for iteration versions (v1, v2, ...). For each version, check if `prd.md` exists. Use the latest version's PRD as input. Legacy fallback: scan `prd/` if `requirement/` does not exist.
 3. **Legacy requirements docs.** Search `docs/brainstorms/` for files matching `*-requirements.md` or `*-requirements.html`. These remain readable historical inputs; do not migrate or rewrite them.
 
 **Relevance criteria:** A PRD source is relevant if:

package/skills/ce-plan/references/plan-structure.md

@@ -6,9 +6,9 @@ Detailed structuring and writing logic for Phases 3 and 4.
 
 - Draft a clear title matching the PRD's project name: `{项目名称} - 实施方案`
 - Determine the plan type: `feat`, `fix`, or `refactor`
-- Build the filename: `prd/{ITERATION_VERSION}/plan.md`
+- Build the filename: `requirement/{ITERATION_VERSION}/plan.md`
   - Use the same iteration version as the PRD (resolved at Phase 0.2)
-  - The plan lives in the same directory as the PRD: `prd/vN/prd.md` (PRD) and `prd/vN/plan.md` (plan)
+  - The plan lives in the same directory as the PRD: `requirement/vN/prd.md` (PRD) and `requirement/vN/plan.md` (plan)
   - Create the directory if it does not exist
   - If a plan already exists at this path, confirm whether to update it or create a new one
 

package/skills/ce-plan/references/planning-modes.md

@@ -25,9 +25,9 @@ After resolving the PRD source, determine the planning mode:
 
 If a relevant PRD document exists:
 1. Read the PRD document thoroughly — all 11 chapters, focusing on filled chapters (业务流程, 系统功能清单, 画面原型, etc.).
-   1b. Read `prd/vN/prototype-review.md` if it exists — confirm the prototype inner loop completed and PRD is frozen. If PRD is not frozen (no `frozen: true` in frontmatter), warn the user that the PRD has not been through prototype review and recommend completing the inner loop before planning.
+   1b. Read `requirement/vN/prototype-review.md` if it exists — confirm the prototype inner loop completed and PRD is frozen. If PRD is not frozen (no `frozen: true` in frontmatter), warn the user that the PRD has not been through prototype review and recommend completing the inner loop before planning.
 2. Announce the selected planning mode (业务模式 or 一人公司模式, resolved at Phase 0.2).
-3. Announce that `ce-plan` will produce an independent implementation plan at `prd/vN/plan.md` (not modify the PRD).
+3. Announce that `ce-plan` will produce an independent implementation plan at `requirement/vN/plan.md` (not modify the PRD).
 4. The PRD is the WHAT; the plan is the HOW. Do not rewrite or re-interpret the PRD's business requirements.
 5. Carry forward all applicable information from the PRD:
    - 业务流程 (§2-§3) → informs task breakdown and dependencies

package/skills/ce-plan/references/review-and-write.md

@@ -35,7 +35,7 @@ If the plan originated from a requirements document, re-read that document and v
 
 Surface plan-time call-outs to the user before Phase 5.2 commits the plan to disk — the latest cheap moment to catch plan-time scope errors. The brainstorm already validated WHAT to build; this phase surfaces HOW the plan will execute on the forks that matter.
 
-Fires **whenever Phase 0.2 resolved an upstream PRD source** — a PRD document (`prd/vN/prd.md`) **or** a legacy `*-requirements.{md,html}` brainstorm doc — AND not on Phase 0.1 fast paths. Skip Phase 5.1.5 only in solo invocation (no upstream source found) — solo plans handled their synthesis in Phase 0.7.
+Fires **whenever Phase 0.2 resolved an upstream PRD source** — a PRD document (`requirement/vN/prd.md`) **or** a legacy `*-requirements.{md,html}` brainstorm doc — AND not on Phase 0.1 fast paths. Skip Phase 5.1.5 only in solo invocation (no upstream source found) — solo plans handled their synthesis in Phase 0.7.
 
 **Read `references/synthesis-summary.md` before composing the scoping synthesis.**
 
@@ -56,10 +56,10 @@ HTML note: `ce-doc-review` is markdown-only today. HTML plans still render the u
 Use the Write tool to save the complete plan:
 
 ```text
-prd/{ITERATION_VERSION}/plan.md
+requirement/{ITERATION_VERSION}/plan.md
 ```
 
-The plan is always written to the same `prd/vN/` directory as the PRD, using the iteration version resolved at Phase 0.2. The plan is always markdown (`.md`).
+The plan is always written to the same `requirement/vN/` directory as the PRD, using the iteration version resolved at Phase 0.2. The plan is always markdown (`.md`).
 
 Compose the plan using the content from `templates/plan.md` (the plan template) and the format-specific principles from the rendering reference loaded at Phase 0.0.
 

package/skills/code-reviewer/SKILL.md

@@ -100,6 +100,15 @@ The code-reviewer agent follows this 6-step process:
 3. Read `design.md` to understand architectural decisions
 4. Get the list of changed files: `git diff --name-only BASE..HEAD` or from the change directory
 
+### Step 1b: File Existence Check (前置, v0.43.1)
+
+在 spec-compliance 之前校验 tasks.md 声明的文件是否实际落地（设计增强方案 v0.18 §75，来源：workflow-feedback 2026-08-06——build-executor 标记 Task 完成但文件未创建，审查未发现直到 closing）：
+
+**推导当前 wave 文件集**：tasks.md 的 `## File Structure` 是 change 全局清单，需裁剪到当前 wave——取 `git diff --name-only BASE..HEAD`（本 wave 实际变更文件），与 File Structure 求交集：
+1. **Create 文件** = 声明为 Create 且**落在 diff 范围内**的文件 → 必须存在且非空（`test -s <path>`），缺失标 **Critical finding**（`missing-file`）。
+2. **Modify 文件** = 声明为 Modify 且**在 diff 中**的文件 → 必须有变更，无变更标 **Critical finding**（`no-change`）。
+3. 存在性校验是 spec-compliance 的前置——文件都不存在，谈不上合规。
+
 ### Step 2: Spec Compliance Check
 
 For each requirement in specs/:

package/skills/code-reviewer/code-reviewer-prompt.md

@@ -49,6 +49,13 @@ Subagent (general-purpose):
     merge-blocking complexity as Important and behavior-neutral redundancy as Minor. Do not use line count as evidence, and do not recommend removing
     required tests, validation, security, or error handling.
 
+    **File Existence Check (v0.43.1, 前置):**
+    Derive the current wave's file set: intersect `git diff --name-only BASE..HEAD`
+    with `tasks.md`'s `## File Structure` (Create/Modify list, change-global).
+    - Create files (in the diff) must exist and be non-empty → missing = Critical finding (`missing-file`)
+    - Modify files (in the diff) must have a diff → no change = Critical finding (`no-change`)
+    File existence is a precondition — a file that does not exist cannot be spec-compliant.
+
     **Code quality:**
     - Clean separation of concerns?
     - Proper error handling?

package/skills/need-explorer/SKILL.md

@@ -19,7 +19,7 @@ Before asking questions, understand what exists and what constraints are in plac
 
 ### 1.5 Upstream Inheritance (v0.9)
 
-若 `change-brief.md` 存在（本 change 由 workflow-orchestrator S4 分发），**先读它再提问**：把 brief 的 Scope / 约束 / AC 列表作为提问的**默认值**，只就 brief 未覆盖或用户存疑的部分追问，**不**重新询问已被产品级定稿的意图与 scope。若 brief 不存在（手动新建 / 快速通道），按原流程从零探索。brief 与 `prd/vN/plan.md` 冲突时以 plan.md 为准。
+若 `change-brief.md` 存在（本 change 由 workflow-orchestrator S4 分发），**先读它再提问**：把 brief 的 Scope / 约束 / AC 列表作为提问的**默认值**，只就 brief 未覆盖或用户存疑的部分追问，**不**重新询问已被产品级定稿的意图与 scope。若 brief 不存在（手动新建 / 快速通道），按原流程从零探索。brief 与 `requirement/vN/plan.md` 冲突时以 plan.md 为准。
 
 ### 2. One Question at a Time
 

package/skills/prototype/references/orchestration-flow.md

@@ -88,7 +88,7 @@ test -f <prototype_path>/index.html && test -s <prototype_path>/index.html && ec
 - **P0 工艺机械检查（v0.18.0）**：裸 hex / 靛蓝黑名单 / emoji / 填充文案 / scrollIntoView / data-testid / accent 超限——P0 违规 = Critical
 - **Craft Quality 4 席 rubric（v0.18.0）**：工艺(×0.4)+品牌(×0.2)+无障碍(×0.2)+文案(×0.2) 加权合成
 
-agent 直接写审查报告到 `prd/vN/prototype-auto-review.md`。
+agent 直接写审查报告到 `requirement/vN/prototype-auto-review.md`。
 
 判定（v0.18.0 升级）：
 - **PASS**：Critical=0 且 Important=0 且 craft 合成 ≥6.0
@@ -104,7 +104,7 @@ agent 直接写审查报告到 `prd/vN/prototype-auto-review.md`。
 ## 步骤 ⑥ 人工评审路由（主代理）
 
 主代理用 AskUserQuestion 呈现评审结论 + 争议项，LT 选择：
-- **PRD 有问题** → 回 orchestrator S2 修订 PRD（**vN 内修订 + 变更履历，非升版**；见 feedback-loops 设计）→ PRD 更新后再回 ① 更新原型。**独立调用 fallback**（非 orchestrator 触发时）：无 S2 可回，直接提示 LT 修订 `prd/vN/prd.md` 后重入本 skill。
+- **PRD 有问题** → 回 orchestrator S2 修订 PRD（**vN 内修订 + 变更履历，非升版**；见 feedback-loops 设计）→ PRD 更新后再回 ① 更新原型。**独立调用 fallback**（非 orchestrator 触发时）：无 S2 可回，直接提示 LT 修订 `requirement/vN/prd.md` 后重入本 skill。
 - **原型需调整**（美观/体验/品牌/信息密度等自动评审查不到的维度）→ **⛔ 必须通过 SendMessage 恢复原 prototype-builder 实施调整**（`SendMessage(to: builder_agent_id, message: "用户评审反馈：{调整意见}。请修改原型。")`），修改后 SendMessage 恢复原 prototype-reviewer 重新评审。**禁止启动新子代理**（唯一例外：SendMessage 恢复失败时的 fallback）
 - **通过** → 冻结：PRD frontmatter `frozen: true`（frozen_downstream），prototype 定版