@xulthekl/team-flow 0.42.0 → 0.44.0

package/skills/release-archivist/references/worktree-merge.md

@@ -0,0 +1,69 @@
+# Worktree 合并规范（v0.43.1）
+
+> 设计依据：设计增强方案 v0.18 §74。来源：workflow-feedback 2026-08-06（20260806-180100-sop-flow）——C2-policy-management 合并时无标准流程，主代理临时设计方案、手动执行、遇到依赖链顺序与冲突无章可循。
+> 本文件是 release-archivist Step 5c「Code Landing」的详细规范；SKILL.md 只保留摘要。
+
+## 背景
+
+team-flow 的 change 实施在 worktree 隔离环境（`tf isolate` → `.worktrees/<change>/<repo>`，v0.30.0 RC-D）。change closing 时，代码需要从 worktree feature 分支**落地到主分支**——否则"开发完成 ≠ 交付"。
+
+## 合并模式：merge commit（不 rebase）
+
+| 项 | 决策 | 理由 |
+|----|------|------|
+| 合并命令 | `git merge --no-edit`（merge commit） | 保留真实合并历史，审计可追溯 |
+| rebase | **明确不使用** | rebase 重写历史：多仓库 + 依赖链场景需 force push、冲突需逐 commit 重放、失败难回退。merge commit 冲突只解决一次、可安全回退。强壮性优先于历史线性美观 |
+| 工具入口 | `tf deisolate <change-dir> --merge` | 自动识别 Case A/B 布局，逐 repo 合并 |
+
+## 合并前置条件（命令已防护）
+
+`tf deisolate --merge`（v0.43.1 增强）自动执行：
+
+1. **dirty 检查**：worktree 有未提交改动 → 默认阻断（未提交改动不该混入 master），`--force` 跳过。
+2. **ahead==0 短路**：分支相对目标分支无新 commit → 跳过合并（幂等，可安全重复调用）。
+3. **目标分支**：合并到主仓库当前分支（release-archivist 调用前确保主仓库在 master/main）。
+
+## 多仓库策略（Case A）
+
+多仓库工作区（bff/ui 等独立 git 仓库）中，`tf deisolate` 自动识别 Case A 布局（`.worktrees/<change>/<repo>/`），逐 repo 执行合并。每个独立仓库是一个独立 git 操作，互不依赖。
+
+## 依赖链顺序
+
+合并顺序**不能随意**——后合入者可能覆盖先合入者的共享代码：
+
+1. 读 change DAG（`change_dag` / 依赖关系），确定依赖序。
+2. 按依赖序合并：**C1（被依赖者）→ C2 → C3**。
+3. 共享代码（如枚举、公共模型）先合入者先落地——先合入者的定义是后合入者的基座。
+4. 若依赖 change 尚未合入，当前 change 应选择 **DEFERRED**（暂不合并），待依赖合入后再执行。
+
+## 冲突处理
+
+`tf deisolate --merge` 冲突时：
+1. 命令返回非零 exit code + 报告冲突文件清单（`git status --porcelain` 的 unmerged 文件）。
+2. 冲突**必须人工介入**解决（命令不自动解决——自动解决可能选错语义）。
+3. 解决流程：
+   ```bash
+   # 在主仓库解决冲突（git merge 已在冲突状态）
+   git status            # 查看 unmerged 文件
+   # 编辑冲突文件，保留正确语义
+   git add <resolved-files>
+   git commit            # 完成 merge
+   ```
+4. 解决后**重新执行主分支编译验证**（编译 + 测试）。
+
+## 合并后验证（硬性）
+
+合并完成后必须验证主分支可构建：
+
+- **Java 项目**：`mvn test`（exit 0 且 Tests run > 0）
+- **前端/Node 项目**：`npm run build`（exit 0 且产物非空）
+- 其他语言按项目类型对应命令
+
+编译验证失败 → 回退合并（`git reset --hard <merge前>`）或修复后重新合并。
+
+## 与产物同步的关系
+
+- **代码落地**（Step 5c，本文件）管代码：worktree → master。
+- **产物归档**（Step 5b 及之前，arch-merge/prototype-sync/test-merge）管文档：change → 全局 docs/。
+- 两者独立但都在 closing 完成；代码落地不替代产物归档，反之亦然。
+- 团队同步用 `tf publish`（v0.37.0，提交 + push 确认制）。

package/skills/session-handoff/SKILL.md

@@ -53,7 +53,7 @@ argument-hint: "[下一个会话的关注点描述]"
 | 需求注册表 | `.team-flow/registry.yaml` | 活跃需求、需求列表 |
 | 编排状态 | `.team-flow/requirements/<req-id>/orchestrator.yaml` | SOP 阶段（S1-S5） |
 | 变更级状态 | `<change>/.team-flow.yaml` | 状态机 8 态中的当前态 |
-| PRD 版本 | `prd/vN/prd.md` frontmatter | 迭代版本、冻结状态 |
+| PRD 版本 | `requirement/vN/prd.md` frontmatter | 迭代版本、冻结状态 |
 
 **降级规则**：上述文件均不存在 → 通用 handoff 模式（跳过工作流状态节）。
 

package/skills/session-handoff/references/handoff-template.md

@@ -76,8 +76,8 @@ change_dir: <path | null>
 
 ### §9 关键产物引用（不复制，只引用路径）
 
-- PRD: `prd/vN/prd.md`
-- 实施方案: `prd/vN/plan.md`
+- PRD: `requirement/vN/prd.md`
+- 实施方案: `requirement/vN/plan.md`
 - 原型: `prototype/index.html`
 - 设计方案: `docs/architecture-api-db-design-enhancement-v0.8.md`
 - 复利经验: `docs/solutions/INDEX.md`

package/skills/spec-writer/SKILL.md

@@ -14,7 +14,7 @@ Read `.team-flow.yaml` (especially `dp_0_decisions`, `dp_0_confirmed`) and any e
 ### Global Prototype Reading (v0.5, v0.37.0 版本化)
 
 Before generating artifacts, **resolve the PRD version and locate the prototype worktree**:
-1. **版本推导（v0.37.0 §68.5）**：读 `change-brief.md` 的 `upstream_plan_ref: prd/vN/plan.md`（无 brief 时从 change 目录名 `v{N}-` 前缀推导）→ PRD 版本 vN
+1. **版本推导（v0.37.0 §68.5）**：读 `change-brief.md` 的 `upstream_plan_ref: requirement/vN/plan.md`（无 brief 时从 change 目录名 `v{N}-` 前缀推导）→ PRD 版本 vN
 2. **原型定位**：原型为独立仓库（有远程），版本 worktree = `<workspace>/.worktrees/prd-vN/prototype/`（该 worktree 不存在时回退 `<workspace>/prototype/` 并提示"原型应位于版本 worktree，`tf prototype branch <prd-vN>` 创建"）
 3. Read `prototype/flow.md` if it exists — this defines page navigation and user flows
 4. List `prototype/pages/` directory — these are the UI contract pages
@@ -33,12 +33,12 @@ Read `docs/solutions/INDEX.md` if it exists. Filter entries where `phase = spec
 
 若 `change-brief.md` 存在（本 change 由 workflow-orchestrator S4 分发），读取其 Scope / 约束 / AC 列表 / 全局技术方向：
 - **Scope** 作为 proposal.md 的 scope 边界基线——不静默超出 brief scope。
-- **AC 列表** 作为 specs/ 的 AC 覆盖上限——brief 列出的 AC 必须在 specs/ 中体现，**不**静默丢弃；若认为 brief AC 有误或与 plan.md 冲突，以 `prd/vN/plan.md` / PRD 为准并在 proposal 注明，而非静默改写。
+- **AC 列表** 作为 specs/ 的 AC 覆盖上限——brief 列出的 AC 必须在 specs/ 中体现，**不**静默丢弃；若认为 brief AC 有误或与 plan.md 冲突，以 `requirement/vN/plan.md` / PRD 为准并在 proposal 注明，而非静默改写。
 - brief 不存在时（手动新建 / 快速通道）跳过本段，按原流程从 `dp_0_decisions` 取意图。
 
 ### Plan Technical Direction (v0.9)
 
-若产品级 `prd/vN/plan.md` 存在，读取其**高阶技术设计段**（模块边界 / 技术选型 / 数据流方向 / 关键聚合与上下文划分），作为 design.md 的 `## Decisions` 约束输入——保证各 change 的技术方案与全局方向一致，避免各自为政。**禁止**反向要求 plan.md 提供接口清单 / 字段定义 / 方法签名（这些是 spec-writer / architecture-design 在本 change 内的产出，plan.md 不含，见 ce-plan 作用边界与 v0.8 §18.7.2）。plan.md 不存在时跳过本段。
+若产品级 `requirement/vN/plan.md` 存在，读取其**高阶技术设计段**（模块边界 / 技术选型 / 数据流方向 / 关键聚合与上下文划分），作为 design.md 的 `## Decisions` 约束输入——保证各 change 的技术方案与全局方向一致，避免各自为政。**禁止**反向要求 plan.md 提供接口清单 / 字段定义 / 方法签名（这些是 spec-writer / architecture-design 在本 change 内的产出，plan.md 不含，见 ce-plan 作用边界与 v0.8 §18.7.2）。plan.md 不存在时跳过本段。
 
 ### Architecture Design Outputs (v0.9 §26)
 
@@ -88,6 +88,8 @@ Run: `tf runtime config --get artifacts.order` — generate in configured order
 Must state: problem, what changes, capabilities affected, impact areas.
 
 ### specs/
+**路径契约（v0.43.1，设计增强方案 v0.18 §77）**：每个 capability 一个子目录——`specs/<capability>/spec.md`。**禁止** flat 文件 `specs/<capability>.md`（`tf validate` 会拒绝：`Invalid spec path`）。示例：`specs/capability-cascade-selection/spec.md`。多个 capability 则多个子目录，各自一个 spec.md。
+
 Every requirement must be testable. Use SHALL or MUST. Every requirement must have at least one `#### Scenario:` with WHEN/THEN. Group under ADDED/MODIFIED/REMOVED Requirements headers.
 
 Optional structured AC tags under a Scenario are supported for E2E extraction (v0.4, design spec ch.16): `##### Exception:` (→ EX AC, ×2), `##### State:` (→ ST AC, ×2), `##### Boundary:` (→ BND AC, ×1). These are **OPTIONAL** — omitting them does NOT fail validation. The `e2e` skill applies dimension-conditional gating (absent dimension = N/A, not 0%) plus keyword fallback (error/invalid/fail/边界), so no spec is forced to add tags.
@@ -133,6 +135,7 @@ Generate one at a time. Confirm each before next. This prevents scope drift —
 - `## Why` > 50 chars, `## What Changes`, `## Scope` (In/Out), `## Impact`, `## Capabilities`, no TBD/TODO
 
 ### specs/
+- **路径契约（v0.43.1，设计增强方案 v0.18 §77）**：specs 采用 `specs/<capability>/spec.md` 子目录结构（flat 文件 `specs/<capability>.md` 会被 `tf validate` 拒绝）。
 - SHALL/MUST for required behavior, `#### Scenario:` with WHEN/THEN per requirement, grouped under delta headers, no contradictions; optional `##### Exception:/State:/Boundary:` sub-tags allowed but NOT required (absent dimension = N/A, not 0%); optional `##### Unit:/Integration:` sub-tags allowed but NOT required (test-matrix hints for contract-builder). Regression: a spec containing `##### Exception:` must still pass `npm run validate` (validateDeltaSpec must not reject unknown sub-headings).
 
 ### design.md

package/skills/workflow-bootstrap/SKILL.md

@@ -184,7 +184,7 @@ Step 2: 确定性提取（兜底）
 
 ### B4: Directory Initialization（目录初始化）
 
-创建 team-flow 目录结构：`mkdir -p prd/ prototype/ docs/architecture/ docs/solutions/ changes/`。已有目录不覆盖不删除，只补缺失；目录中有文件保留不改。**Discoverability 检查**：若 `AGENTS.md`/`CLAUDE.md` 未暴露 `docs/architecture/` 和 `prototype/`，advisory 建议用户添加（不自动改）。
+创建 team-flow 目录结构：`mkdir -p requirement/ prototype/ docs/architecture/ docs/solutions/ changes/`。已有目录不覆盖不删除，只补缺失；目录中有文件保留不改。**Discoverability 检查**：若 `AGENTS.md`/`CLAUDE.md` 未暴露 `docs/architecture/` 和 `prototype/`，advisory 建议用户添加（不自动改）。
 
 ### B4.5: CLAUDE.md 初始化（v0.41.0 新增，参考 Claude Code /init）
 
@@ -214,7 +214,7 @@ Step 2: 确定性提取（兜底）
 询问用户。**分组展示**——用户先决定"要不要把地基打牢"（第一组），再决定"打完地基做什么"（第二组）：
 
 > **第一组：确保 bootstrap 产物可信**
-> - A) 逆向重建完整架构（**复杂项目强推 / 简单项目弱推**；→ 进入 workflow-orchestrator ARCH 阶段 reconstruction 模式，arch-reverse-analyst，重建 PASS 后 `tf arch init --mode reconstruction --baseline-ref prd/vN/` 打戳，全量命令见 b5-path-decision.md）
+> - A) 逆向重建完整架构（**复杂项目强推 / 简单项目弱推**；→ 进入 workflow-orchestrator ARCH 阶段 reconstruction 模式，arch-reverse-analyst，重建 PASS 后 `tf arch init --mode reconstruction --baseline-ref requirement/vN/` 打戳，全量命令见 b5-path-decision.md）
 > - B) 交叉验证与对齐 bootstrap 产物（→ 主代理机械比对，产出 `docs/architecture/cross-check-report.md` 疑点清单）
 > - C) 真实性核对（→ 针对 B 疑点清单（跟随 B）或 baseline.md 语义结论抽查（独立），用户逐条确认，修正 baseline.md）
 >

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

@@ -102,7 +102,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/workflow-bootstrap/scripts/recon-probe.sh --ro
 - docs/architecture/INDEX.md（架构文档索引，v0.23.0）
 - docs/architecture/CONCEPTS.md（领域词汇，N 个术语）
 - CLAUDE.md（项目概况 + 产物结构索引，B4.5）
-- 目录结构：prd/ prototype/ docs/ changes/
+- 目录结构：requirement/ prototype/ docs/ changes/
 
 关键发现：
 - 技术栈：Java 17 + Spring Boot 3 + MySQL 8

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

@@ -32,7 +32,7 @@
 | ≥5 模块 或 ≥10 源文件（复杂） | "建议优先重建完整架构——项目有实质架构，基线快照不足以支撑后续设计" |
 | <5 模块 且 <10 源文件（简单） | "项目较简单，可直接进入流程，逆向重建为可选项" |
 
-**去向**：A → workflow-orchestrator ARCH 阶段 reconstruction 模式（arch-reverse-analyst，`references/agents/arch-reverse-analyst.md`）→ architecture-reviewer product 视角评审（≤3 轮循环）→ PASS 后 `tf arch init --mode reconstruction --baseline-ref prd/vN/` 打戳。
+**去向**：A → workflow-orchestrator ARCH 阶段 reconstruction 模式（arch-reverse-analyst，`references/agents/arch-reverse-analyst.md`）→ architecture-reviewer product 视角评审（≤3 轮循环）→ PASS 后 `tf arch init --mode reconstruction --baseline-ref requirement/vN/` 打戳。
 
 ## B 交叉验证与对齐：主代理机械比对
 

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

@@ -44,8 +44,8 @@ team-flow 工作流在 `changes/<name>/` 下通过状态机驱动变更，核心
 
 | 产物 | 路径 | 状态 |
 |------|------|------|
-| 产品级 PRD | `prd/vN/prd.md` | ce-brainstorm 引用 |
-| 产品级计划 | `prd/vN/plan.md` | ce-plan 引用 |
+| 产品级 PRD | `requirement/vN/prd.md` | ce-brainstorm 引用 |
+| 产品级计划 | `requirement/vN/plan.md` | ce-plan 引用 |
 | 变更简报 | `changes/<name>/change-brief.md` | orchestrator S4 产出，hash 显式排除 |
 | 架构设计 | `changes/<name>/architecture/{architecture,database,api}.md` | hash 纳入 artifacts_hash |
 | 需求注册表 | `.team-flow/registry.yaml` | workflow-orchestrator 引用 |

package/skills/workflow-orchestrator/SKILL.md

@@ -69,7 +69,7 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"）；原型循环由编排层直接编排（prototype skill 内部编排产出 → prototype-reviewer 自动评审 → 人工评审 → 冻结）；冻结语义为 `frozen_downstream`（迭代内变更不升版）。反馈环路检查点：scope 是否合理。详见 `references/s2-prd-prototype-loop.md`。
 
 ### S3: 计划阶段
-**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `prd/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。完成条件：plan.md 产出 + S3 状态 = completed，**下一步进 ARCH**（v0.36.0）。
+**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `requirement/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。完成条件：plan.md 产出 + S3 状态 = completed，**下一步进 ARCH**（v0.36.0）。
 
 ### ARCH: 产品级架构设计（v0.36.0 新增，S3 之后、S4 之前）
 
@@ -83,7 +83,7 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 
 **评审门**：产出经 architecture-reviewer product 视角（`review_mode: product`，A1-A6）评审，**PASS 才进 S4**。
 
-**输出契约**：`docs/architecture/iterations/vN/architecture.md` + 评审 verdict；`orchestrator.yaml` 中 ARCH phase 状态 = completed（`workflow_phase: architecture`）。**首轮项目（`arch_baseline` 缺失）评审 PASS 后执行 `tf arch init --mode reconstruction|design --baseline-ref prd/vN/` 打戳**（v0.36.3）——arch 门禁豁免键由此建立，项目进入「已建档」正轨。
+**输出契约**：`docs/architecture/iterations/vN/architecture.md` + 评审 verdict；`orchestrator.yaml` 中 ARCH phase 状态 = completed（`workflow_phase: architecture`）。**首轮项目（`arch_baseline` 缺失）评审 PASS 后执行 `tf arch init --mode reconstruction|design --baseline-ref requirement/vN/` 打戳**（v0.36.3）——arch 门禁豁免键由此建立，项目进入「已建档」正轨。
 
 ### S4: 拆分验证与分发
 
@@ -136,7 +136,7 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 ```yaml
 upstream_source: orchestrator          # orchestrator | manual | null
 upstream_req_id: <req-id>              # 对应 requirement ID
-upstream_plan_ref: prd/vN/plan.md      # hotfix/快速通道为 null
+upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
 ```

package/skills/workflow-orchestrator/references/feedback-loops.md

@@ -51,7 +51,7 @@ S5→S4 回退时，按在途 change 状态分区处置（前置条件）：
 
 - S3→S2 回退 = **临时解除 frozen_downstream**，S2 重新完成后恢复
 - 若 PRD 处于 `frozen_absolute`（用户显式确认或 vN+1 已启动），任何修改必须升版 vN+1，**不允许 vN 内修订**
-- frozen 状态以 `prd/vN/prd.md` frontmatter 为单一真相源。详见 state-model.md「双层冻结」
+- frozen 状态以 `requirement/vN/prd.md` frontmatter 为单一真相源。详见 state-model.md「双层冻结」
 
 ## 复利集成
 

package/skills/workflow-orchestrator/references/s1-path-router.md

@@ -27,7 +27,7 @@ S1 只做编排动作（需求选择、存在性检查、路径判断、阻塞
 | **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 直接创建 change（type: hotfix，注入 bug 描述替代 PRD）→ workflow-start | closing 时强制补录复利 |
 | **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做/重跑原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4） | PRD 不动，保留有效 S3 plan / S4 changes，闭环后恢复原 phase；`replan_log` 记往返 |
 
-**判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `prd/` 目录（有 PRD → 「续版」候选），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。
+**判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `requirement/` 目录（有 PRD → 「续版」候选；legacy: `prd/`），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。
 
 **原型补跑/重跑判据（v0.20.0，与「重新计划」「续版」区分）**：当 PRD 已冻结时，按用户意图三分：
 - 用户要**重做/补做原型**（「重新跑一遍原型」「prototype 没有了」「原型重做」）∧ `prototype/` 缺失/为空或用户明确不满现有原型 → **原型补跑/重跑**（部分重入 S2 原型循环，**PRD/plan/changes 不动**）。

package/skills/workflow-orchestrator/references/s2-prd-prototype-loop.md

@@ -39,14 +39,14 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 
 调用 `/ce-brainstorm`，**显式传入** `mode: orchestrated`（B6 跨 skill 集成规约：用显式入参，禁止语义推断）。被 orchestrator 调用时 ce-brainstorm 跳过其内部 Phase 3.5 原型循环（循环归编排层），直接调用时（standalone）保留。
 
-> **阶段后压缩协议（A4）**：ce-brainstorm 冻结 PRD 后，编排层主动触发 compact，只保留 `prd/vN/prd.md` 路径与 frozen 状态，丢弃过程对话。会话级 skill 的过程对话会进入编排层上下文窗口，必须压缩。
+> **阶段后压缩协议（A4）**：ce-brainstorm 冻结 PRD 后，编排层主动触发 compact，只保留 `requirement/vN/prd.md` 路径与 frozen 状态，丢弃过程对话。会话级 skill 的过程对话会进入编排层上下文窗口，必须压缩。
 
 ### 1.5 用户确认 PRD 草稿（强制阻塞点）
 
 **⛔ 关键：PRD草稿完成后，必须等待用户确认，不能自动进入下一步。**
 
 PRD草稿生成后：
-1. 输出PRD文档位置：`prd/vN/prd.md`
+1. 输出PRD文档位置：`requirement/vN/prd.md`
 2. **阻塞等待用户确认**（使用 AskUserQuestion）
 3. 用户确认后，才能进入步骤2（判断是否需要原型）
 
@@ -63,7 +63,7 @@ PRD草稿生成后：
 ```
 调用 prototype skill 产出原型
   → 自动评审（prototype-reviewer agent，独立上下文）
-    → 输出一致性报告（编排层落盘到 prd/vN/prototype-auto-review.md）
+    → 输出一致性报告（编排层落盘到 requirement/vN/prototype-auto-review.md）
     → FAIL（Critical > 0）→ 修正 → 重新自动评审（≤3 轮）
     → PASS_WITH_WARNINGS → 警告项交人工裁定
     → PASS → 进入人工评审
@@ -89,7 +89,7 @@ S2 冻结后，**阻塞确认**（AskUserQuestion）是否同步阶段产物（
 - **B 仅提交不推送**：`tf publish --prd`
 - **C 暂不同步**：继续 S3，后续可补
 
-同步对象：`prd/vN/` + 原型（push `prd-vN` 分支）+ `.team-flow/`（orchestrator.yaml / registry.yaml）。
+同步对象：`requirement/vN/` + 原型（push `prd-vN` 分支）+ `.team-flow/`（orchestrator.yaml / registry.yaml）。
 
 ### 5. 复利捕获
 
@@ -133,6 +133,6 @@ tf solutions capture --phase prd --domain <domain> --type pitfall --severity <se
 
 ## 完成条件
 
-- `prd/vN/prd.md` frontmatter `frozen: true`（frozen_downstream 已设置）
-- 如需原型：`prd/vN/prototype-auto-review.md` 已落盘且 verdict 为 PASS / PASS_WITH_WARNINGS（人工已裁定）
+- `requirement/vN/prd.md` frontmatter `frozen: true`（frozen_downstream 已设置）
+- 如需原型：`requirement/vN/prototype-auto-review.md` 已落盘且 verdict 为 PASS / PASS_WITH_WARNINGS（人工已裁定）
 - `.team-flow/requirements/<req-id>/orchestrator.yaml` 中 S2 状态 = completed，`prd_version` 已记录

package/skills/workflow-orchestrator/references/s3-plan-pipeline.md

@@ -1,11 +1,11 @@
 # S3 计划阶段（v0.7 修订，pipeline 快速路径）
 
-> 调用 ce-plan 产出 `prd/vN/plan.md`，使用 `pipeline_mode: orchestrator` 减少仪式开销。设计依据：设计增强方案 v0.7 §17.2 / §17.5。
+> 调用 ce-plan 产出 `requirement/vN/plan.md`，使用 `pipeline_mode: orchestrator` 减少仪式开销。设计依据：设计增强方案 v0.7 §17.2 / §17.5。
 
 ## 调用方式
 
 调用 `/ce-plan`，传递：
-- PRD 路径：`prd/vN/prd.md`
+- PRD 路径：`requirement/vN/prd.md`
 - 原型路径：`prototype/`（如存在）
 - 显式参数：`pipeline_mode: orchestrator`
 
@@ -46,6 +46,6 @@ ce-plan 在 orchestrator pipeline 上下文中减少仪式开销，但**保留
 
 ## 完成条件
 
-- `prd/vN/plan.md` 已产出，含 change 拆分 + 依赖 DAG + 技术方向
+- `requirement/vN/plan.md` 已产出，含 change 拆分 + 依赖 DAG + 技术方向
 - `.team-flow/requirements/<req-id>/orchestrator.yaml` 中 S3 状态 = completed
 - 下一步：进入 ARCH 阶段，产出 `docs/architecture/iterations/vN/architecture.md` 后进 S4（v0.35.0）

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -73,7 +73,7 @@ tf state init changes/v1-C2-policy-management
 
 ### 3.5 落盘 change-brief.md（v0.9 新增，产品级→变更级交接物）
 
-> **设计意图**：S3/S4 已把每个 change 的 scope、AC、依赖、技术方向定稿，但这些信息此前只活在产品级 `prd/vN/plan.md`，变更层（workflow-start / need-explorer / spec-writer）读不到，导致变更层在 DP-0 重新询问意图、在 need-explorer 重新决策拆分——两层产物断链。本步骤把产品级决策投影到 change 目录内的 `change-brief.md`，作为**上游输入交接物**，让变更层可继承而非重做。
+> **设计意图**：S3/S4 已把每个 change 的 scope、AC、依赖、技术方向定稿，但这些信息此前只活在产品级 `requirement/vN/plan.md`，变更层（workflow-start / need-explorer / spec-writer）读不到，导致变更层在 DP-0 重新询问意图、在 need-explorer 重新决策拆分——两层产物断链。本步骤把产品级决策投影到 change 目录内的 `change-brief.md`，作为**上游输入交接物**，让变更层可继承而非重做。
 
 **职责边界（写死）**：auditor 是只读 agent，**只在审计报告里输出 Dim1 覆盖矩阵**；**落盘动作归 orchestrator 自己**（与 Step 4 写 change_dag 同属编排层自做，见上文「编排层 vs 执行层」表）。即：读取 auditor 报告 Dim1 矩阵 → orchestrator 写入 brief 的 AC 段。
 
@@ -83,7 +83,7 @@ tf state init changes/v1-C2-policy-management
 ---
 upstream_source: orchestrator          # orchestrator | manual | null
 upstream_req_id: <req-id>              # 对应 .team-flow/requirements/<req-id>/
-upstream_plan_ref: prd/vN/plan.md      # hotfix/快速通道为 null
+upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_arch_ref: docs/architecture/iterations/vN/architecture.md  # 产品级架构快照（v0.36.3）；ARCH skip 或 hotfix 为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
@@ -103,13 +103,13 @@ plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层
 <取自 plan.md 高阶技术设计段的要点指针：模块边界/技术选型/数据流方向，供 spec-writer 作 design.md 约束；**BC 边界/聚合所有权以 `upstream_arch_ref` 产品级快照为准**（v0.36.3），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>
 ```
 
 **hash 豁免（重要）**：change-brief.md 放在 change 根目录，**不**属于 team-flow 五产物（proposal/specs/design/tasks/execution-contract），因此天然**不进入 `artifacts_hash`**（`hash.mjs` 只统计前四类）。空 change 的 `artifacts_hash` 仍为 null，状态机的"无产物"判定不受污染——**绝不**让 brief 入 hash。
 
-**双源权威规则**：scope/技术方向以 `prd/vN/plan.md` 为准、AC 以 PRD 功能清单为准；**brief 只是 S4 时刻的投影快照**，不是第二真相源。若变更层发现 brief 与 plan.md 冲突，以 plan.md 为准并触发 Brief drift 提示（见 workflow-start「Staleness Detection」）。
+**双源权威规则**：scope/技术方向以 `requirement/vN/plan.md` 为准、AC 以 PRD 功能清单为准；**brief 只是 S4 时刻的投影快照**，不是第二真相源。若变更层发现 brief 与 plan.md 冲突，以 plan.md 为准并触发 Brief drift 提示（见 workflow-start「Staleness Detection」）。
 
 ### 4. 写入 change_dag
 

package/skills/workflow-orchestrator/references/state-model.md

@@ -96,7 +96,7 @@ phases:
 | S0 全新项目 | 无代码库 | 正向设计（首轮不可跳过） |
 | S1 存量代码+无基线 | 有 src/，无 baseline.md | 先 workflow-bootstrap → 逆向重建 |
 | S2 存量+瘦锚点 | baseline.md + ARCHITECTURE 无 BC/聚合层 | 逆向重建（深化） |
-| S3 存量+跑过迭代 | baseline + changes/ + prd/vN/，无 arch_baseline | 逆向重建（首轮强制） |
+| S3 存量+跑过迭代 | baseline + changes/ + requirement/vN/，无 arch_baseline | 逆向重建（首轮强制） |
 | S4 已有产品级架构 | arch_baseline 已打戳 + iterations/ | 正向设计（正轨） |
 
 **skip 条件（须物化）**：迭代无结构性变更（纯 bugfix/重构/不新增 BC 或聚合/不改变聚合边界或全局契约）。判定者 = **编排器 + 用户确认**（非 LLM 自判，防 v0.13 §54 绕过教训）。**skip 必须物化**：写入 `docs/architecture/iterations/vN/` 占位（含 skipped 标记 + 理由），guard 才放行——否则 hotfix/快速通道 change 会卡在 arch-readiness 上（v0.32.2 C1 死锁链同类）。
@@ -104,7 +104,7 @@ phases:
 **时间盒 + 深度分层**：时间盒 ≤1 天；非触及 BC 只维护锚点行，触及 BC 才做按域深化（v0.14 §60.4）。
 
 **输入输出契约**：
-- 输入：prd/vN/prd.md（frozen_downstream）+ plan.md + prototype/ + baseline.md + CONCEPTS.md + 现有全局基线（旧项目）
+- 输入：requirement/vN/prd.md（frozen_downstream）+ plan.md + prototype/ + baseline.md + CONCEPTS.md + 现有全局基线（旧项目）
 - 输出：`docs/architecture/iterations/vN/architecture.md`（6 产物权威快照，预测态，provenance 标注）+ 产品级评审 verdict；**不触发全局覆盖写**（P1：预测态不进实际态）
 
 **门禁**（v0.14 §59.4）：
@@ -119,7 +119,7 @@ phases:
 完全复刻 v0.13 §48.1 schema_version 防污染模式（设计增强方案 v0.14 §59.4/§63.1）：
 
 - **位置**：`.team-flow/arch-state.json`（项目级状态；架构阶段是产品/迭代级，不放 change 的 `.team-flow.yaml`）
-- **内容**：`{ arch_baseline: "v0", established_at: "<date>", mode: "reconstruction" | "design", snapshot_root: "iterations/", baseline_prd_ref: "prd/vN/" }`
+- **内容**：`{ arch_baseline: "v0", established_at: "<date>", mode: "reconstruction" | "design", snapshot_root: "iterations/", baseline_prd_ref: "requirement/vN/" }`
 - **防污染**：仅 `tf arch init` 写入；`tf state set`/rebuild/doctor 一律不得追加（缺失 = 存量信号）
 - **判定**：`arch_baseline == null` → arch-readiness/arch-snapshot 均 PASS + WARN（reason: 'project architecture baseline not established — S3.5 reconstruction pending'）
 
@@ -127,7 +127,7 @@ phases:
 
 - **`frozen_downstream`**（S2 完成时设置）：下游阶段（S3/S4/S5）不可直接修改 PRD，只能通过回退到 S2 修改。**S3→S2 回退 = 临时解除 frozen_downstream**，S2 重新完成后恢复。
 - **`frozen_absolute`**（用户显式确认或 vN+1 启动时设置）：任何修改都必须升版 vN+1。
-- **单一真相源**：frozen 状态以 `prd/vN/prd.md` frontmatter 为准，yaml 只存指针不重复存 frozen 值，避免双写不一致。
+- **单一真相源**：frozen 状态以 `requirement/vN/prd.md` frontmatter 为准，yaml 只存指针不重复存 frozen 值，避免双写不一致。
 
 ## 原型补跑/重跑：部分重入语义（v0.20.0，S1 第 7 入口）
 

package/skills/workflow-start/SKILL.md

@@ -32,7 +32,7 @@ Run DP-0 when: change folder doesn't exist, planning artifacts missing/empty, or
 
 ### Upstream Inheritance (v0.9)
 
-若 `change-brief.md` 存在且 `upstream_source == orchestrator`（本 change 由 orchestrator S4 分发），**继承** brief 的 scope/约束/AC 为默认值，DP-0 从"从零问"改为"一次确认继承或修正"，**不**重新问"你想做什么"。否则（手动新建 / hotfix / 单 change 快速通道 / 存量 change 无 brief）照常 DP-0。**主信号 = brief 文件存在**（非 yaml 字段——可天然排除无 brief 的快速通道，且对存量手动 change 零误伤）；双源冲突以 `prd/vN/plan.md` 为准并触发 Brief drift（见「Staleness Detection」）。完整判定伪代码与主信号理由见 `references/routing-rules.md`「DP-0」。
+若 `change-brief.md` 存在且 `upstream_source == orchestrator`（本 change 由 orchestrator S4 分发），**继承** brief 的 scope/约束/AC 为默认值，DP-0 从"从零问"改为"一次确认继承或修正"，**不**重新问"你想做什么"。否则（手动新建 / hotfix / 单 change 快速通道 / 存量 change 无 brief）照常 DP-0。**主信号 = brief 文件存在**（非 yaml 字段——可天然排除无 brief 的快速通道，且对存量手动 change 零误伤）；双源冲突以 `requirement/vN/plan.md` 为准并触发 Brief drift（见「Staleness Detection」）。完整判定伪代码与主信号理由见 `references/routing-rules.md`「DP-0」。
 
 Ask (manual path): change name + one-sentence intent, known constraints, related optimizations (include or stay focused?), communication preference (ask per decision or draft for review).
 
@@ -167,7 +167,7 @@ Use content inspection, not timestamps.
 
 **Stale tasks**: requirement in specs has no corresponding task → stale tasks.
 
-**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 环路）"，**不**触发产物重审。
+**Brief drift (advisory, v0.9, 不阻断)**: change-brief.md 是上游输入（非 team-flow 产物），**不**混入上述三条产物互查、**不**进入 `artifacts_hash`。当 brief 的 `plan_hash` 与当前 `requirement/vN/plan.md` 不一致，或 brief AC 列表与 PRD 功能清单明显出入 → 提示"产品层已变更，brief 可能过期，建议回 orchestrator 重新分发（S4→S3 环路）"，**不**触发产物重审。
 
 ## Review Findings 处理流程（v0.39.0）
 

package/skills/workflow-start/references/routing-rules.md

@@ -15,8 +15,8 @@ Guard: `arch_design_decision` in `.team-flow.yaml` is `null` → must run before
 
 Dispatch `architecture-design` as sub-agent with inputs:
 - `change-brief.md`（scope / AC / 技术方向）
-- `prd/vN/plan.md` 高阶技术设计段
-- `docs/architecture/iterations/<vN>/architecture.md`（**产品级架构快照，主输入**，v0.36.0）——BC 边界/聚合所有权/全局契约唯一事实源；vN 从 change-brief 的 `upstream_plan_ref`（prd/vN/plan.md）推导；变更级只引用不重定义（触及产品级决策 → 架构修订决策门；仅 change 内细节 → 增量设计）
+- `requirement/vN/plan.md` 高阶技术设计段
+- `docs/architecture/iterations/<vN>/architecture.md`（**产品级架构快照，主输入**，v0.36.0）——BC 边界/聚合所有权/全局契约唯一事实源；vN 从 change-brief 的 `upstream_plan_ref`（requirement/vN/plan.md）推导；变更级只引用不重定义（触及产品级决策 → 架构修订决策门；仅 change 内细节 → 增量设计）
 - existing `specs/`
 - global `docs/architecture/`（As-Is 基线 + 已落地部分）
 
@@ -285,7 +285,7 @@ else:
 ```
 
 - **为何以 brief 存在为主信号**：hotfix / 单 change 快速通道也是 orchestrator 创建的 change，但不产 brief；以 brief 存在为信号可天然排除这两条路径，且对存量手动 change（无 brief）零误伤。
-- **双源权威**：继承的 scope/AC 若与 `prd/vN/plan.md` 冲突，以 plan.md 为准（brief 是 S4 时刻快照，非真相源）；冲突时触发 Brief drift 提示（见「Staleness Detection」）。
+- **双源权威**：继承的 scope/AC 若与 `requirement/vN/plan.md` 冲突，以 plan.md 为准（brief 是 S4 时刻快照，非真相源）；冲突时触发 Brief drift 提示（见「Staleness Detection」）。
 
 After confirmation:
 ```bash

package/templates/change-brief.md

@@ -1,7 +1,7 @@
 ---
 upstream_source: orchestrator          # orchestrator | manual | null
 upstream_req_id: <req-id>              # 对应 .team-flow/requirements/<req-id>/
-upstream_plan_ref: prd/vN/plan.md      # hotfix/快速通道为 null
+upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
 ---
@@ -20,5 +20,5 @@ plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层
 <取自 plan.md 高阶技术设计段的要点指针：模块边界/技术选型/数据流方向，供 spec-writer 作 design.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/templates/plan.md

@@ -1,6 +1,6 @@
 # {项目名称} - 实施方案
 
-> 关联 PRD：[prd/vN/prd.md](prd/vN/prd.md)
+> 关联 PRD：[requirement/vN/prd.md](requirement/vN/prd.md)
 > 模式：{业务模式 | 一人公司模式}
 > 版本：{版本号}
 > 创建日期：{YYYY-MM-DD}