@xulthekl/team-flow 0.46.0 → 0.48.0

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

@@ -56,7 +56,7 @@ PRD草稿生成后：
 ### 2. 判断是否需要原型
 
 - 需要（涉及 UI/交互/页面）→ 进入原型循环
-- 不需要（纯后端/无 UI）→ PRD 直接冻结，跳到步骤 5
+- 不需要（纯后端/无 UI）→ **先走步骤 3.5 完整性评审**，再冻结，跳到步骤 5
 
 ### 3. 原型循环（编排层控制）
 
@@ -78,6 +78,14 @@ PRD草稿生成后：
 
 **人工介入 = 编排层阻塞确认**（非 subagent，因 subagent 不能 AskUserQuestion），呈现争议项 + 选项（接受现状 / 指定修正方向 / 升版 / 放弃原型）。
 
+### 3.5 PRD 完整性评审（冻结前门禁，v0.47）
+
+**orchestrated 路径下完整性评审由编排层在此派发**（standalone 路径由 ce-brainstorm Phase 3.5 内部派发，见 ce-brainstorm `references/prototype-loop.md` §3.5.5）。
+
+- 派发：按名派发插件 agent `prd-completeness-reviewer`（6 维，含 §8.4 契约级细节 D6），传入 `prd_path` + `concepts_path`（可选）+ `template_path`（默认 `templates/prd.md`）+ `detail_ledger_path`（如有）。
+- 判定：PASS / PASS_WITH_WARNINGS → 进入步骤 4 冻结；**FAIL（Critical>0：D1/D2/D6 核心维度缺失、D6 悬空功能）→ 回 ce-brainstorm Phase 1.3/Phase 3 修订后重审**。
+- **适用性**：需要原型（步骤 3 完成后）与不需要原型（纯后端无 UI，步骤 2 后）两条路径**均必须派发**——不因跳过原型循环而跳过完整性评审。
+
 ### 4. 冻结
 
 设置 `frozen_downstream`（见 state-model.md「双层冻结」）。冻结后，**迭代内变更不升版**，在 vN 内修订 + 记录决策/变更履历。
@@ -134,5 +142,6 @@ tf solutions capture --phase prd --domain <domain> --type pitfall --severity <se
 ## 完成条件
 
 - `requirement/vN/prd.md` frontmatter `frozen: true`（frozen_downstream 已设置）
+- `requirement/vN/prd-completeness-review.md` 已落盘（step 3.5 完整性评审门禁，v0.47）
 - 如需原型：`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-start/SKILL.md

@@ -34,6 +34,16 @@ Run DP-0 when: change folder doesn't exist, planning artifacts missing/empty, or
 
 若 `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」。
 
+### 项目模式确认（multi-repo-support-design v1.0 §3.3，2026-08-21）
+
+DP-0 时确认项目布局（`single`/`monorepo`/`multi-repo`），写 config 供 detect/review/isolate 按模式路由：
+1. **定位项目根**：`detectWorkspaceRoot(changeDir)`（change 目录 → `changes/` 父目录）；非标准布局回退 `getGitRoot`
+2. **已固化跳过**：`<项目根>/.team-flow/team-flow.config.json` 已有 `repo_layout` 段 → 直接读取，跳过 3-4
+3. **运行 `tf repo-layout detect <项目根>`**：判定 `single`/`monorepo`/`multi-repo` + 代码仓库清单，写 `<项目根>/.team-flow/team-flow.config.json` 的 `repo_layout` 段
+4. **多仓库项目首次确认**：向用户展示判定结果（`multi-repo + N 个代码仓库`），AskUserQuestion 确认；单仓库自动。**修正 repos 清单**：确认后编辑 `<项目根>/.team-flow/team-flow.config.json` 的 `repo_layout.repos`（缺省接受检测结果）
+5. **与 workflow-bootstrap 边界**：本步骤识别**存量结构**（single/monorepo/multi-repo 探测 + repos 清单）；全新项目骨架引导（生成 pom.xml/package.json）归 workflow-bootstrap B1.5
+6. 判定结果影响：detect（按仓库清单探测 GLAF4）/ review（`--repo` 放宽 git 约束）/ isolate（共享分支检测）
+
 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).
 
 After confirmation:

package/templates/prd-brainstorm-profile.md

@@ -14,12 +14,15 @@ Phase 2 产出的每个方案必须覆盖核心维度，按需覆盖扩展维度
 | 数据关系 | §4.3 信息结构图 | 核心业务实体之间的关联规则是什么？实体间的层级/归属/引用关系？ |
 | 业务规则 | §8.2.4 其他机制与规则 | 排序规则？搜索规则？加载机制？异常处理？校验逻辑？ |
 | 系统功能 | §7 D7.5 系统功能清单 | 需要哪些功能点？每个功能点关联哪个业务流程/活动？ |
+| 功能细节（契约级） | §8.4 功能模块详细说明 | UI 功能：每个功能的页面布局/字段/交互/异常/权限是什么？非 UI 功能：触发条件/输入输出/处理步骤/异常/幂等并发/性能是什么？ |
+
+> **功能细节澄清分级（v0.47）**：按功能复杂度分级——Standard/Deep scope **强制契约级澄清**（布局/字段/交互/异常/权限 或 触发/输入输出/处理/异常/幂等并发/性能），Lightweight scope 简化澄清（需求已足够清晰时）。澄清产出 **detail_ledger**（逐功能维度 → 已澄清/待澄清/NA），作为 §8.4 撰写数据源 + prd-completeness-reviewer D6 核对基准。
 
 ## 扩展思考维度（按需触发）
 
 | 维度 | 触发条件 | 对应 PRD 章节 | 引导问题 |
 |------|---------|-------------|---------|
-| 画面设计 | 涉及 UI 交互 | §4 D7.2 | 画面结构如何？页面间如何迁移？ |
+| 画面设计 | 涉及 UI 交互 | §4 D7.2 | 画面结构如何？页面间如何迁移？（视觉层面辅助，功能细节见核心维度「功能细节（契约级）」） |
 | 业务术语 | 出现领域专有名词 | §6 D7.4 | 哪些术语需要统一定义？有无同义词？ |
 | 报表需求 | 用户提到"报表/统计/分析" | §5 D7.3 | 需要哪些报表？关联哪些流程和数据？ |
 | 交互机制 | 有特殊交互需求 | §8.2.2 | 键盘/画面/弹层交互细节？ |

package/templates/prd.md

@@ -267,13 +267,42 @@
 
 ### 8.4 功能模块详细说明
 
+**契约级详述规范（v0.47）**：每个功能模块按下述「必含维度检查清单」逐项详述。UI 功能覆盖 11 维、非 UI 功能覆盖 7 维（按「功能形态」选择其一）；维度不适用时标注 `NA + 理由`；**缺失适用维度 = PRD 不完整**；核心维度缺失将判 FAIL，辅助维度缺失为 PASS_WITH_WARNINGS 交人工裁定（prd-completeness-reviewer D6，v0.47）。规范唯一权威为本节——撰写 agent（prd-writer）与审查 agent 均读取本节获得检查清单，不在他处重复维护。
+
 #### 8.4.1 {模块名称}
 
 ##### 8.4.1.1 {功能名称}
 
-| 编号 | 系统功能 | 原型/UI | 关联活动 | 信息结构 | 画面说明 |
-|---|---|---|---|---|---|
-| {编号} | {功能名} | {原型截图} | {活动编号} | {信息结构列表} | {画面说明} |
+| 功能形态 | UI 功能 / 非 UI 功能 | | |
+|---|---|---|---|
+| 所属流程 | BP-{xxx} | 关联需求 | REQ-{xxx} |
+| 关联场景 | SC-{xxx} | 功能概述 | {1-2 句；若不能一句话说清，先拆分功能} |
+
+**UI 功能必含维度（11 维）**：
+
+- [ ] 页面布局：{布局结构（上下分栏/标准列表等）}
+- [ ] 权限规则：{角色/状态/操作权限；与 §8.2.1 全局权限的差异}
+- [ ] 区块说明：{各区块内容与职责}
+- [ ] 搜索模块：{搜索组件/占位符/选项/筛选联动}
+- [ ] 表格列定义：{完整列清单：列名/类型/格式/排序}
+- [ ] 交互规则：{默认选中/点击切换/筛选联动/级联选择逻辑等}
+- [ ] 弹层结构：{弹层触发/内容/交互}
+- [ ] 动态字段：{按领域动态字段/动态列名说明}
+- [ ] 导入导出规则：{格式/字段映射/校验}
+- [ ] 状态操作差异：{已发布/草稿/已停用等状态下的操作差异}
+- [ ] 异常边界：{空态/错误态/并发/极值}
+
+**非 UI 功能必含维度（7 维）**：
+
+- [ ] 触发条件：{定时/事件/手动触发}
+- [ ] 输入输出：{输入参数/输出结果/格式}
+- [ ] 处理步骤：{处理流程/算法/业务规则}
+- [ ] 异常处理：{异常场景/重试/补偿}
+- [ ] 权限角色：{可执行角色/鉴权}
+- [ ] 幂等并发：{幂等性/并发控制}
+- [ ] 性能约束：{耗时/吞吐/资源}
+
+> **NA 机制**：维度不适用时标注 `NA + 一句理由`（如 `页面布局：NA，后台批处理无画面`）；**未标注 NA 且未覆盖 = 缺失**，审查将判 FAIL。
 
 ### 8.5 非功能性需求说明