@xulthekl/team-flow 0.45.0 → 0.47.0

package/skills/architecture-design/references/s3.5-product-architecture.md

@@ -1,6 +1,6 @@
 # S3.5 产品级架构设计 SOP（v0.35.0，v0.14 §59/§60）
 
-> architecture 阶段（S3 之后、S4 之前）的执行 SOP。产出 `docs/architecture/iterations/vN/architecture.md`（预测态快照）。
+> architecture 阶段（2026-08-19 调整：S2 之后、S3 之前——ARCH 上移，S3 计划/S4 拆分是最终任务拆分须基于架构；原" S3 之后、S4 之前"历史位置）的执行 SOP。产出 `docs/architecture/iterations/vN/architecture.md`（预测态快照）。
 > **owner**：architecture-design skill 的 **product 模式**子代理（唯一 owner，声明见 architecture-design/SKILL.md「独立调用」扩展）。
 > **时序（P1）**：只写快照不写全局；change 关闭时 arch-merge 回写实际增量；迭代收尾快照标 `archived` 退役。
 
@@ -48,7 +48,7 @@
 | A5 | 与全局基线一致性（旧项目逆向重建产物 vs 现状代码） |
 | A6 | conventions 合规 |
 
-规则：≤3 轮修复循环 + 收敛检测（连续两轮不一致项不缩小 → 转人工）；PASS 才进 S4。
+规则：≤3 轮修复循环 + 收敛检测（连续两轮不一致项不缩小 → 转人工）；PASS 才进 S3（2026-08-19：ARCH 上移 S3 前，原"进 S4"）。
 **skip 时**：architecture-reviewer 不执行，但 skip 必须物化（iterations/vN/SKIPPED 标记 + 理由）。
 
 ### 复利捕获（Step 9，v0.36.3 复利链路修复）

package/skills/ce-brainstorm/SKILL.md

@@ -19,7 +19,7 @@ Brainstorming answers **WHAT** to build through collaborative dialogue, producin
 
 > **显式参数规约**：orchestrator 调用时必须传入 `mode: orchestrated`。ce-brainstorm 检测到该参数即跳过 Phase 3.5 并在输出中回执"原型循环已委托编排层"。未收到该参数时默认为 standalone 模式。
 >
-> **重要：`orchestrated` 模式仅跳过 Phase 3.5（原型内循环）。Phase 0（含 PRD 模板选择）、Phase 1（含 1.4/1.5/1.6）、Phase 2、Phase 3、QA-4、Phase 3.6、版本归档均正常执行，不可跳过。**
+> **重要：`orchestrated` 模式仅跳过 Phase 3.5（原型内循环）。Phase 0（含 PRD 模板选择）、Phase 1（含 1.3b/1.4/1.5/1.6）、Phase 2、Phase 3、QA-4、Phase 3.6、版本归档均正常执行，不可跳过。**
 
 ## Core Principles
 
@@ -40,12 +40,12 @@ Brainstorming answers **WHAT** to build through collaborative dialogue, producin
 | 职责 | 执行方 | 说明 |
 |------|--------|------|
 | 需求澄清、场景确认、流程确认、方案决策 | **主会话** | 需要用户交互和判断的工作 |
-| PRD 文档撰写（Phase 3） | **子代理**（推荐） | 执行性文档生成，主会话做 QA 和冻结 |
+| PRD 文档撰写（Phase 3） | **prd-writer agent**（v0.47） | 执行性文档生成（契约级 §8.4），主会话做 QA 和冻结 |
 | 流程图绘制（mermaid） | **子代理**（推荐） | 基于已确认的流程数据生成图表 |
 | 活动表批量生成 | **子代理**（推荐） | 基于已确认的 L4 子流程生成表格 |
 | 综合报告（synthesis summary） | **子代理**（可选） | 大量数据的汇总整理 |
 
-**子代理委托方式**：使用 `Agent` 工具（`context: fork` 或自定义 agent），将已确认的结构化数据作为输入，要求子代理按模板产出。主会话审查产出后决定接受或修正。
+**子代理委托方式**：使用 `Agent` 工具（`context: fork` 或自定义 agent），将已确认的结构化数据作为输入，要求子代理按模板产出。主会话审查产出后决定接受或修正。PRD 撰写（Phase 3）固定委托命名 agent **prd-writer**（预加载 ce-brainstorm，只执行 Phase 3、不提问）；其余执行性产出（流程图/活动表/综合报告）可委托通用子代理。
 
 ### Stage Breakpoints
 
@@ -155,6 +155,8 @@ For detailed routing logic, read `references/phase0-routing.md`. Summary:
 
 **1.3 Dialogue** — Follow Interaction Rules. Fire blindspot gate (if tripwire armed) and visual-probe gate (before first shape decision). Rigor probes fire as open-ended questions before Phase 2. Before exit: integration check for non-obvious consequences. **Exit when**: primary actor, outcome, scope, success criteria all known or recorded as assumptions.
 
+**1.3b 功能细节澄清（v0.47）** — Follow the brainstorm profile's「功能细节（契约级）」core dimension. Standard/Deep scope **强制契约级澄清**（UI 布局/字段/交互/异常/权限；非 UI 触发/输入输出/处理/异常/幂等并发/性能），Lightweight 简化。产出 **detail_ledger**（`requirement/vN/detail-ledger.md`，逐功能维度 → 已澄清/待澄清/NA），供 Phase 3 §8.4 撰写 + 冻结前 D6 核对。
+
 **1.4 Dialogue Log Persistence** — Automated step, no user interaction. Trigger: Phase 1.3 dialogue exits. Traverse each Q&A round extracting original text + decisions, generate dialogue summary and decision summary table. Write to `requirement/vN/dialogue-log.md` (create or append). No ledger update.
 
 **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.
@@ -191,34 +193,23 @@ Propose **2-3 approaches** (or recommend directly if one is clearly best). Use n
 - `requirement/ledger.md` — all requirement/scenario/process items and their associations
 - `requirement/vN/dialogue-log.md` — §1.2 revision record reference path
 - `requirement/vN/business-analysis.md` — data source for §2/§3/§7/§8
+- `requirement/vN/detail-ledger.md` — 功能细节澄清产出（v0.47），§8.4 逐功能详述数据源 + D6 核对基准
 
 **⛔ MANDATORY：生成PRD文档前，必须先读取 `references/brainstorm-sections.md`**
 
-**§8.4 功能模块提取规则（关键规则，必须遵守）**：
-- **详细程度**：保留原始需求文档中的关键细节，不要过度概括
-- **必须保留的内容**：
-  - 页面布局（上下分栏、标准列表等）
-  - 搜索模块（具体字段）
-  - 表格列定义（完整字段列表）
-  - 交互规则（默认选中、点击切换、筛选联动等）
-  - 按领域动态字段（如有）
-  - 动态列名说明
-  - 操作说明（已发布/草稿状态等）
-  - 级联选择逻辑（如有）
-- **⛔ 错误行为**：只提取输入/输出/业务规则，丢失原始需求文档中的大量关键细节
-- **⛔ 正确行为**：充分利用原始需求文档的详细内容，保持信息完整性
+**§8.4 功能模块提取规则（v0.47）**：规范唯一权威 = 模板 `templates/prd.md` §8.4「必含维度检查清单」（UI 11 维 / 非 UI 7 维双形态 + NA 机制），**本处不再重复维护维度清单**。生成 PRD 前必须读取模板检查清单，逐功能模块按适用维度详述；维度不适用标注 `NA + 理由`；**未标注 NA 且未覆盖 = 缺失**。
 
 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 审查和冻结确认。
+> **子代理委托（v0.47）**：Phase 3 PRD 撰写委托 **prd-writer** agent。主会话将已确认结构化数据（business-analysis.md + dialogue-log.md + **detail_ledger** + synthesis summary + template_path）作为参数传入；prd-writer 按模板 §8.4 契约级检查清单逐功能详述，不提问、不虚构，`missing_info` 返回主会话决定是否回 Phase 1.3 补澄清。主会话负责 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.
+**`orchestrated` mode skips this phase.** For standalone: read `references/prototype-loop.md`. Trigger: PRD 有 UI 功能则执行原型循环；**完整性评审（§3.5.5）对 standalone 全路径适用**（含非 UI / 跳过原型路径，不因无 UI 而跳过）。Steps: produce prototype → review vs PRD → fix loop (max 3) → completeness review → freeze PRD.
 
 ### QA-4: PRD Quality Check
 
-Fires after Phase 3 (or Phase 3.5 if prototype loop ran). Read `references/evidence-chain-validation.md` for QA-4 criteria. Evaluates PRD completeness and traceability against business analysis artifacts.
+Fires after Phase 3 (or Phase 3.5 if prototype loop ran). Read `references/evidence-chain-validation.md` for QA-4 criteria. Evaluates PRD completeness and traceability against business analysis artifacts. **冻结前完整性评审（6 维，含 §8.4 契约级细节 D6）的派发点已归并**：standalone 路径由 Phase 3.5（`references/prototype-loop.md` §3.5.5）派发 prd-completeness-reviewer；orchestrated 路径由 orchestrator S2 派发（见 `workflow-orchestrator/references/s2-prd-prototype-loop.md`）；**QA-4 自身不重复派发**，仅按评审结果判定是否回 Phase 1.3/Phase 3 修订。
 
 ### Phase 3.6: PRD ↔ Scenario/Process Bidirectional Validation
 
@@ -250,6 +241,7 @@ requirement/
 ├── vN/                                # Iteration version
 │   ├── prd.md                         # PRD document
 │   ├── dialogue-log.md                # Dialogue log (Phase 1.4 output)
+│   ├── detail-ledger.md               # 功能细节澄清产出（v0.47，§8.4 数据源 + D6 核对基准）
 │   └── business-analysis.md           # Business analysis (requirements + scenarios + processes)
 doc/
 └── active-registry/

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

@@ -267,17 +267,9 @@ as template placeholder.
   所属流程 (BP-xxx). Skip §8.3 (hardware/network) and §8.5 (non-functional)
   unless the brainstorm explicitly covered these.
 
-  **§8.4 功能模块提取规则**：
-  - **详细程度**：保留原始需求文档中的关键细节，不要过度概括
-  - **必须保留的内容**：
-    - 页面布局（上下分栏、标准列表等）
-    - 搜索模块（具体字段）
-    - 表格列定义（完整字段列表）
-    - 交互规则（默认选中、点击切换、筛选联动等）
-    - 按领域动态字段（如有）
-    - 动态列名说明
-    - 操作说明（已发布/草稿状态等）
-    - 级联选择逻辑（如有）
+  **§8.4 功能模块提取规则（v0.47）**：
+  - **规范权威**：模板 `templates/prd.md` §8.4「必含维度检查清单」是唯一权威（UI 11 维/非 UI 7 维双形态 + NA 机制），本文件不再重复维护维度清单。撰写（prd-writer）与审查（prd-completeness-reviewer D6）均以模板为基准。
+  - **详细程度**：保留原始需求文档中的关键细节，不要过度概括（页面布局/搜索字段/表格列/交互规则/动态字段/级联逻辑等——逐项见模板检查清单）
   - **错误行为**：只提取输入/输出/业务规则，丢失原始需求文档中的大量关键细节
   - **正确行为**：充分利用原始需求文档的详细内容，保持信息完整性
 

package/skills/ce-brainstorm/references/evidence-chain-validation.md

@@ -16,7 +16,7 @@ This reference covers three connected operations after PRD generation: QA-4 qual
 | C5 | Consistency | PRD §2 process overview table matches business-analysis.md process list? | Error |
 | C6 | Consistency | PRD §3 process descriptions match business-analysis.md process details? | Error |
 | C7 | Metadata | PRD frontmatter complete (title / project_name / iteration_version / date / prd_template)? | Warning |
-| C8 | Format | §8.4 feature extraction preserves original requirements detail (not over-summarized)? | Warning |
+| C8 | Detail | §8.4 契约级细节：逐功能模块按模板检查清单覆盖适用维度（UI 11 维/非 UI 7 维，单一权威 = 模板 §8.4）+ §7↔§8.4 交叉核对无悬空功能（v0.47 并入 D6 模型：核心维度缺失/悬空 = Critical，辅助维度缺失 = Important） | Critical |
 
 **Verdict rule:** All Error-level checks pass → PASS. Any Error fails → FAIL. Warnings are reported but do not block.
 

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

@@ -9,8 +9,8 @@ PRD 文档写入后、Handoff 之前，执行原型内循环。原型是 PRD 的
 检查 PRD 草稿中是否包含 UI/画面/交互相关功能点（§4 画面原型、§7 系统功能清单中的 UI 功能）。
 
 - **包含 UI 功能点** → 使用平台阻塞问题工具询问用户："PRD 包含 UI 功能点，是否需要产出原型进行验证？"
-- **不包含 UI 功能点** → 跳过原型内循环，直接进入 Phase 4
-- **用户选择跳过** → 跳过，PRD 直接冻结
+- **不包含 UI 功能点** → 跳过原型内循环，**先走 §3.5.5 PRD 完整性评审，再冻结（§3.5.6，跳过 prototype-review.md 写入）**，进入 Phase 4
+- **用户选择跳过** → 跳过原型，**先走 §3.5.5 PRD 完整性评审**，再冻结
 
 ## 3.5.2 原型产出
 
@@ -37,19 +37,21 @@ PRD 文档写入后、Handoff 之前，执行原型内循环。原型是 PRD 的
 - **最多循环 3 次**，超过则标记为"需人工介入"，在 PRD 中记录未解决项
 - 每次修正触发复利捕获：`tf solutions capture --phase prd --domain <domain> --type pitfall --severity medium --summary "<修正原因>"`
 
-## 3.5.5 PRD 完整性评审（冻结前门禁）
+## 3.5.5 PRD 完整性评审（冻结前门禁，v0.47 全路径适用）
 
-原型审查通过后、冻结前，派发 `prd-completeness-reviewer` 子代理（独立上下文），评审 PRD「是否完整到能支撑后续 plan/spec 实施」（区别于 Phase 2.6 claim verifier——后者管"说得对不对"，本评审管"说得全不全"）。
+**所有 standalone 路径的冻结前必过门禁**：有原型（原型审查通过后）、无 UI 功能点（§3.5.1）、用户跳过原型（§3.5.1）三条路径均须派发——不因跳过原型循环而跳过完整性评审（orchestrated 路径对应 `s2-prd-prototype-loop.md` step 3.5）。
 
-- 派发：按名派发插件 agent `prd-completeness-reviewer`（定义见插件 `agents/prd-completeness-reviewer.md`），传入 PRD 路径 + CONCEPTS.md 路径。
+派发 `prd-completeness-reviewer` 子代理（独立上下文），评审 PRD「是否完整到能支撑后续 plan/spec 实施」（区别于 Phase 2.6 claim verifier——后者管"说得对不对"，本评审管"说得全不全"）。
+
+- 派发：按名派发插件 agent `prd-completeness-reviewer`（定义见插件 `agents/prd-completeness-reviewer.md`），传入 `prd_path` + `concepts_path`（可选）+ `template_path`（默认 `templates/prd.md`）+ `detail_ledger_path`（如有）。
 - agent 直接写审查报告到 `requirement/{ITERATION_VERSION}/prd-completeness-review.md`。
-- 判定（柔性）：PASS / PASS_WITH_WARNINGS → 进入冻结；**FAIL（Critical>0）→ 回 Phase 1.3 补充**后重审。
-- 5 维度：用户故事完整性(Critical)/验收标准(Critical)/边界与非功能(Important)/术语一致性(Minor)/范围闭环(Important)。
+- 判定（柔性）：PASS / PASS_WITH_WARNINGS → 进入冻结；**FAIL（Critical>0）→ 回 Phase 1.3/Phase 3 补充**后重审。
+- 6 维度：用户故事完整性(Critical)/验收标准(Critical)/边界与非功能(Important)/术语一致性(Minor)/范围闭环(Important)/§8.4 契约级细节（核心维度缺失·悬空功能=Critical，辅助维度缺失=Important）。
 
 ## 3.5.6 冻结
 
 完整性评审通过后：
-1. 写入 `requirement/{ITERATION_VERSION}/prototype-review.md`（审查结论 + 版本 + 日期 + 循环次数）
+1. 写入 `requirement/{ITERATION_VERSION}/prototype-review.md`（审查结论 + 版本 + 日期 + 循环次数；**无原型路径跳过本步**，完整性评审结论已落盘 `prd-completeness-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/project-initialize/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: project-initialize
+description: 项目初始化引导。工作空间代码服务为空时触发：识别需初始化 → 引导架构选择（glaf4 体系/前端分离/单体微服务/拆分）→ 服务命名确认 → 创建服务子目录 → 委托初始化骨架（glaf4 走 glaf4-dev PROJECT_INITIALIZE，非 glaf4 走内置引导）。
+---
+
+# Project Initialize（项目初始化引导）
+
+产品级初始化引导流程（v2.1 §6.5，2026-08-19 LT 定案）。工作空间代码服务为空时，引导用户完成架构决策、创建服务子目录并委托初始化骨架。
+
+## 触发条件
+
+由编排层 Pre-check 检测驱动（v2.1 §6.5 触发接入，评审 M2 补全）：
+- **场景①（orchestrator）**：需求迭代架构设计（ARCH）评审 PASS 后、S3 计划前——架构快照涉及服务未初始化
+- **场景②（workflow-start）**：change 阶段发现服务缺漏——AskUserQuestion 区分「未拉取」（git pull/检出后继续）vs「需要初始化」（引导本 skill）
+- **场景③（直接）**：工作空间代码服务为空（无服务子目录/技术栈特征），用户显式初始化
+
+## 流程（顺序执行）
+
+### Step 1 识别需初始化
+
+检测工作空间是否有服务子目录/技术栈特征；为空 → 进入引导。
+
+### Step 2 引导新会话
+
+提示用户启动新会话（干净上下文，避免与 change 工作流混杂）。参考 session-handoff 会话交接机制。
+
+### Step 3 架构选择（AskUserQuestion 逐项）
+
+1. **是否 glaf4 体系**？（影响委托路径——glaf4 走 glaf4-dev，非 glaf4 走内置引导）
+2. **是否前端分离**？（前后端独立目录 vs 合并）
+3. **单体 or 微服务**？
+4. **若微服务 → 拆分方式**？（按领域/按模块/按团队）
+
+决策树与判定依据见 `references/architecture-choice.md`。
+
+### Step 4 服务命名确认
+
+基于架构选择确定服务列表，AskUserQuestion 确认命名（禁止擅自命名）。
+
+### Step 5 创建服务子目录
+
+team-flow 创建空目录（如 `services/<svc>/`）+ `git init` + `.gitignore`（忽略 `.glaf4-dev/` 等运行期目录）。布局与命名规则见 `references/service-layout.md`。
+
+### Step 6 委托初始化
+
+- **glaf4 体系** → 委托 glaf4-dev PROJECT_INITIALIZE（进入空服务子目录初始化骨架）。协议见 `references/glaf4-initialize-delegation.md`
+- **非 glaf4** → workflow-bootstrap **B1.5 全新项目路径**（交互式技术栈选择 + 可选骨架生成，test-capability v1.0 §4.3）
+
+## Guardrails
+
+- 服务命名必须用户确认，不擅自命名
+- 不创建非空目录、不覆盖已有内容
+- glaf4 委托前置：glaf4-dev 已装 + JDK8 + 离线依赖就绪（见 reference）
+- **glaf4 委托前置风险（评审 B1）**：gen-service 空检查需对 `.git`/`.gitignore`/`.glaf4-dev` 白名单化——glaf4-dev v0.3.0 未实现前 glaf4 委托会 BLOCK（缓解与调时序见 reference）
+- 与 workflow-bootstrap 边界：本 skill 管**骨架生成引导**（含 B1.5 全新项目路径），bootstrap 管**既有项目侦察/基线**（职责分离）
+
+## 产出
+
+- 服务子目录（骨架工程）
+- `.gitignore`（忽略 `.glaf4-dev/`）
+- 委托记录（若 glaf4 委托，run 终局证据）

package/skills/project-initialize/references/architecture-choice.md

@@ -0,0 +1,55 @@
+# 架构选择决策树（project-initialize Step 3）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（PROJECT_INITIALIZE 定案）
+> 用途：初始化引导时，逐项 AskUserQuestion 收集架构决策，确定服务列表与委托路径。
+
+## 决策维度（4 项，顺序执行）
+
+### 1. 是否 glaf4 体系？
+
+**判定依据**：团队技术栈是否基于 GLAF4 框架（Maven 依赖 `gtmc-glaf4-starter-parent`，包前缀 `com.gtmc.glaf4.framework.*`）。
+
+**影响**：
+- ✅ glaf4 → Step 6 委托 glaf4-dev PROJECT_INITIALIZE（骨架生成走 gen-service.py 六套模板）
+- ❌ 非 glaf4 → Step 6 workflow-bootstrap 内置引导（Java/JS/Python 技术栈选择）
+
+**判定**（AskUserQuestion）：
+- 是（GLAF4 框架体系）
+- 否（标准 Spring Boot / 其他技术栈）
+- 不确定 → 提示检查团队既有项目依赖，或选"否"走标准引导
+
+### 2. 是否前端分离？
+
+**判定**：业务是否有独立前端团队/部署单元。
+
+- 前后端分离 → 服务子目录拆为 `services/backend/` + `services/frontend/`（或独立 repo）
+- 合并（monolith 内嵌前端资源）→ 单服务目录
+
+### 3. 单体 or 微服务？
+
+**判定**：业务复杂度/团队规模/部署独立性需求。
+
+- 单体（monolith）→ 单服务，gen-service `--type monolith`
+- 微服务 → 进入维度 4（拆分）
+
+### 4. 微服务拆分方式？
+
+| 拆分维度 | 依据 | 例 |
+|---|---|---|
+| 按领域（DDD） | 业务域边界清晰，独立演进 | order/user/payment 服务 |
+| 按模块 | 技术模块独立部署 | gateway/backend/bff 服务 |
+| 按团队 | 团队自治部署 | 每团队一服务 |
+
+拆分结果 → 服务列表（每个服务一个子目录，命名走 Step 4 确认）。
+
+## 服务列表推导
+
+```
+单体 + glaf4        → [backend]（monolith）
+单体 + 非 glaf4     → [backend]（标准技术栈）
+单体 + 前端分离     → [backend(monolith), frontend]
+微服务 + glaf4      → [<svc1>, <svc2>, ...]（按拆分维度）
+微服务 + 前端分离   → [<svc1>, ..., frontend]
+```
+
+服务列表进入 Step 4 命名确认。

package/skills/project-initialize/references/glaf4-initialize-delegation.md

@@ -0,0 +1,55 @@
+# glaf4-dev PROJECT_INITIALIZE 委托协议（project-initialize Step 6）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（2026-08-19 定案）
+> 用途：glaf4 体系服务子目录创建后，委托 glaf4-dev 初始化骨架。
+
+## 前置（实证就绪，2026-08-19）
+
+| 前置 | 状态 | 验证 |
+|---|---|---|
+| glaf4-dev 插件已装 | ✅ | `~/.claude/plugins/installed_plugins.json` 有 glaf4-dev v0.3.0 |
+| JDK 8 | ✅ | 本机 jdk-1.8.jdk（1.8.0_411）+ Corretto 8；flow 要求 JDK8（模板 1.8 + 旧 Lombok） |
+| 离线 Maven 依赖 | ✅ | 本地 `~/.m2/repository/com/gtmc/` 有 gtmc-glaf4-starter-parent；编译走 `--offline` |
+| 服务子目录为空 | ✅ | Step 5 team-flow 创建空目录 + git init + .gitignore |
+
+## 委托流程
+
+```text
+1. 确认前置（上表）
+2. 调 glaf4-dev 统一入口（mode_hint=PROJECT_INITIALIZE）
+   → 路由到 PROJECT_INITIALIZE 七模式流：
+     inspect → plan → scaffold → test-bootstrap → smoke-green → validate
+3. run 终局 PASS → 骨架工程落地服务子目录
+4. 证据回灌（可选）：glaf4-evidence-export → test record（骨架基线测试）
+```
+
+## gen-service 空目录冲突（实证 + 缓解）
+
+**实证（2026-08-19）**：flow scaffold 写死 `gen-service.py --out <target_root>`，而 run 树 `.glaf4-dev/runs/` 先建在 target_root 下 → gen-service 空检查 `os.listdir` 非空 → **BLOCKED**（`out dir not empty`）。
+
+**非空来源（评审 B1 补全，2026-08-19）**：gen-service 空检查 `os.listdir` **无任何隐藏文件过滤**，以下三类都会触发 BLOCK：
+1. `.glaf4-dev/`（run 树，glaf4-dev 自建基础设施）
+2. `.git/`（Step 5 `git init` 产生）
+3. `.gitignore`（Step 5 写入）
+
+**缓解**：gen-service 空检查需对 `.git`/`.gitignore`/`.glaf4-dev` 三类基础设施条目**白名单化**（run 树与 git 元数据非工程内容）；**或调时序**——先对真空目录跑 gen-service（此时仅 run 树在，`.git` 未建），完成骨架后再 `git init` + `.gitignore`，且 gen-service 至少容忍 `.glaf4-dev`。**glaf4-dev v0.3.0 未实现白名单化前，glaf4 委托会 BLOCK**（SKILL Guardrails 已标注此前置风险）。
+
+**run 树位置（LT 决策 2026-08-19）**：不设专门外置方案——run 树在 target_root 是 glaf4-dev 统一约定，`.glaf4-dev/` 由 `.gitignore` 忽略，非关键路径。
+
+## gen-service 参数（scaffold 调用）
+
+```bash
+python3 <plugin-root>/scripts/gen-service.py \
+  --type <monolith|agg|infra|gateway|bff-backend|bff-open> \
+  --domain <业务域> --name <服务名> --out <服务子目录>
+```
+
+- `--type/--domain/--name/--out` 必填（gen-service.py L182-185）
+- 六种服务类型对应 templates/ 下模板树
+- 骨架含 pom.xml（引用 `gtmc-glaf4-starter-parent`）+ src + 资源，≈90+ 文件（monolith/infra 92、agg 68、bff-backend 48、bff-open 40、gateway 11）
+
+## 边界
+
+- **本协议只委托骨架生成**：业务代码（Controller/Service/Repository 等）走后续 change 级委托（FEATURE_TDD 等）
+- 委托失败 → run 终局 FAIL/BLOCKED → 恢复路径（重试/降级/转人工）
+- 与 workflow-bootstrap 边界：本协议管 glaf4 骨架，workflow-bootstrap 管既有项目侦察/基线

package/skills/project-initialize/references/service-layout.md

@@ -0,0 +1,63 @@
+# 服务子目录布局与命名（project-initialize Step 4/5）
+
+> 设计来源：`docs/plan/glaf4-dev-integration-design.md` v2.1 §6.5（PROJECT_INITIALIZE 定案）
+
+## 目录布局约定
+
+```
+<workspace>/
+├── services/               # 服务容器（微服务/多服务）
+│   ├── <svc>/              # 每个服务一个子目录（Step 5 创建）
+│   │   ├── .gitignore
+│   │   └── （骨架，委托初始化后）
+│   └── ...
+├── docs/                   # 工作空间文档
+└── .team-flow/             # team-flow 项目状态
+```
+
+- **单体**：可直接在 `<workspace>/` 根或 `services/<svc>/` 下建
+- **微服务/多服务**：统一 `services/<svc>/` 容器，每服务独立子目录 + 独立 git
+
+## 命名规则
+
+- **kebab-case**（小写 + 连字符），如 `order-service`、`user-backend`
+- 语义：业务域 + 服务类型（`<domain>-<type>`），如 `order-backend`、`bff-open`
+- **必须用户确认**（Step 4 AskUserQuestion），禁止擅自命名
+
+## .gitignore 模板（Step 5 写入）
+
+```gitignore
+# team-flow / glaf4-dev 运行期基础设施
+.team-flow/
+.glaf4-dev/
+
+# 构建产物
+target/
+build/
+.gradle/
+
+# IDE
+.idea/
+.vscode/
+*.iml
+
+# OS
+.DS_Store
+
+# Node（前端分离场景）
+node_modules/
+dist/
+```
+
+> `.glaf4-dev/` 是 glaf4-dev 的 run 树（运行期基础设施，RUNS_REL 约定），必须 gitignore 避免污染版本库（v2.1 §6.5 实证：run 树在 target_root 下，不忽略会被 git add 跟踪）。
+
+## 创建动作（Step 5）
+
+```bash
+mkdir -p services/<svc>
+cd services/<svc>
+git init
+# 写入 .gitignore（如上模板）
+```
+
+创建后确认空目录 + git init + .gitignore 就绪，再进入 Step 6 委托。

package/skills/workflow-bootstrap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-bootstrap
-description: 既有项目接入初始化器。在首次使用 team-flow 时执行一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → 路径判断。完成后进入 workflow-orchestrator。不适用于：全新项目（无代码库，直接用 workflow-orchestrator）、已建立基线的项目（baseline.md 已存在）。
+description: 既有项目接入初始化器。在首次使用 team-flow 时执行一次性"侦察 + 基线建立"：代码库侦察 → 架构基线文档化 → 领域词汇提取 → 目录初始化 → 路径判断。完成后进入 workflow-orchestrator。不适用于：全新项目（无代码库，直接用 workflow-orchestrator）、已建立基线的项目（baseline.md 已存在）。B1.5 提供全新项目骨架引导（交互式技术栈选择 + 可选骨架生成，被 project-initialize 非 glaf4 分支委托，2026-08-19）。
 ---
 
 # Workflow Bootstrap（既有项目接入初始化器，v0.6 新增）

package/skills/workflow-orchestrator/SKILL.md

@@ -66,25 +66,31 @@ prd_draft → user_review → prototype_loop → prd_frozen → completed
 - **错误行为**：PRD草稿完成后直接标记S3阶段完成
 - **正确行为**：PRD草稿完成后等待用户查看，确认后继续S2阶段的后续步骤
 
-调用 `/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`。
+调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿（Phase 3 由 prd-writer agent 契约级撰写，v0.47）；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"；v0.47 并入 §8.4 契约级细节 D6 维度）；原型循环由编排层直接编排（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 + 技术方向）产出 `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 之前）
+### ARCH: 产品级架构设计（v0.36.0 新增；2026-08-19 LT 调整上移 S3 前——S3 计划/S4 拆分是最终任务拆分，须基于架构）
 
 **⛔ MANDATORY：执行 ARCH 阶段前，必须先读取 `references/state-model.md`「architecture 阶段」+ `architecture-design/references/s3.5-product-architecture.md`**
 
-产品级架构设计：基于迭代版本 vN 产出覆盖所有模块的整体详细架构（预测态快照，P1：只写快照不写全局）。
+产品级架构设计：基于迭代版本 vN 产出覆盖所有模块的整体详细架构（预测态快照，P1：只写快照不写全局）。**ARCH 在 S3 之前**——计划（S3）与拆分（S4）是最终任务拆分，必须基于架构定稿（聚合/服务/模块）进行。
 
 **场景判定（入口三态）**：全新项目 → 正向设计（首轮不可跳过）；旧项目首轮（`arch_baseline` 缺失）→ 逆向重建 L0 骨架 → 渐进深化；已建档 + 迭代无结构性变更 → 跳过（**skip 必须物化**：写 `docs/architecture/iterations/vN/SKIPPED` 标记 + 理由，判定者=编排器+用户确认）。
 
 **执行**：调用 architecture-design skill 的 **product 模式**子代理（8 步设计：限界上下文/聚合注册表/指令事件/状态机/概念 ER/时序），产出 `docs/architecture/iterations/vN/architecture.md`（6 产物，provenance 标注）。
 
-**评审门**：产出经 architecture-reviewer product 视角（`review_mode: product`，A1-A6）评审，**PASS 才进 S4**。
+**评审门**：产出经 architecture-reviewer product 视角（`review_mode: product`，A1-A6）评审，**PASS 才进 S3**。
 
 **输出契约**：`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 门禁豁免键由此建立，项目进入「已建档」正轨。
 
+**ARCH 后 Pre-check：服务初始化检测（v0.45.0 project-initialize 触发接入，场景①）**：评审 PASS 后、S3 计划前，检查架构设计涉及的服务是否已初始化——
+1. 从 `docs/architecture/iterations/vN/architecture.md`（聚合注册表/服务列表）提取本次迭代涉及的服务
+2. 检查工作空间是否有对应服务子目录 + 技术栈特征（pom.xml/package.json 等）
+3. 缺漏服务 → 提示用户：「架构设计涉及服务 X/Y/Z 尚未初始化，需要初始化对应项目代码吗？」确认后引导执行 `project-initialize` skill（架构选择 → 服务命名确认 → 创建空服务子目录 → 委托初始化）
+4. 已存在（未拉取）→ 提示用户 git pull/检出对应服务
+
+### S3: 计划阶段
+**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `requirement/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。**S3 在 ARCH 之后**——基于架构定稿（聚合/服务/模块）做计划与拆分（2026-08-19 LT 调整）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。完成条件：plan.md 产出 + S3 状态 = completed，**下一步进 S4**。
+
 ### S4: 拆分验证与分发
 
 **⛔ MANDATORY：执行S4阶段前，必须先读取 `references/s4-split-validate.md`**

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-orchestrator/references/s3-plan-pipeline.md

@@ -42,10 +42,10 @@ ce-plan 在 orchestrator pipeline 上下文中减少仪式开销，但**保留
 
 - plan 是否暴露了 PRD 的范围问题？
   - **是** → 回退 S2，触发 PRD vN 内修订（记录变更原因）。详见 feedback-loops.md「S3 → S2」
-  - **否** → 进 ARCH（architecture 阶段，v0.35.0 产品级架构设计，见 state-model.md「architecture 阶段」）
+  - **否** → 完成 S3，进 S4（2026-08-19：ARCH 已上移 S3 前完成，S3 基于架构定稿——见 state-model.md「architecture 阶段」）
 
 ## 完成条件
 
 - `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）
+- 下一步：进 S4 拆分验证与分发（ARCH 已在 S3 前完成，产出 `docs/architecture/iterations/vN/architecture.md`，2026-08-19）

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

@@ -20,7 +20,7 @@
 
 进入拆分前先校验：
 
-- **项目 arch_baseline 缺失（存量/重建未完成）** → WARN 不阻断（reason: 'project architecture baseline not established — S3.5 reconstruction pending'），提示先跑 S3.5 重建产出 L0 骨架。
+- **项目 arch_baseline 缺失（存量/重建未完成）** → WARN 不阻断（reason: 'project architecture baseline not established — ARCH reconstruction pending'），提示先跑 ARCH（原名 S3.5）重建产出 L0 骨架。
 - **已建档项目** → 校验 `docs/architecture/iterations/vN/architecture.md` 存在且覆盖 plan.md 各 change 触及的全部 BC。不覆盖 → FAIL，回退 ARCH 阶段补快照（feedback-loops.md「S4 → ARCH」）。
 - **skip 物化**：ARCH 阶段显式跳过（iterations/vN/ 占位含 skipped 标记 + 理由）→ PASS。
 

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

@@ -76,7 +76,7 @@ prd_version: v1                       # PRD 版本
 
 ## architecture 阶段（S3.5，v0.35.0 新增）
 
-> 产品级架构设计阶段，位于 S3 计划之后、S4 拆分之前。设计依据：设计增强方案 v0.14 §59。
+> 产品级架构设计阶段。**2026-08-19 调整：位于 S2 之后、S3 计划之前**（ARCH 上移，S3 计划/S4 拆分是最终任务拆分须基于架构；原" S3 计划之后、S4 拆分之前"历史位置）。设计依据：设计增强方案 v0.14 §59。
 
 **phase id**：`ARCH`；顶层 `workflow_phase: architecture`（语义 kebab-case）。
 **命名约定**：新阶段一律用 kebab-case 语义名（历史值保留不迁移，避免无价值 churn）。
@@ -110,7 +110,7 @@ phases:
 **门禁**（v0.14 §59.4）：
 | 门禁 | 挂点 | 校验 | 豁免 |
 |------|------|------|------|
-| 产品级评审门 | ARCH→S4 | architecture-reviewer product 视角 PASS | skip 时仍要物化标记 |
+| 产品级评审门 | ARCH→S3（2026-08-19：ARCH 上移 S3 前，原 ARCH→S4） | architecture-reviewer product 视角 PASS | skip 时仍要物化标记 |
 | arch-readiness | exploring:specifying（guard 存在性）+ S4 拆分（LLM 覆盖校验） | iterations/vN/ 快照覆盖 change 触及的 BC | arch_baseline 缺失 → WARN 不 FAIL |
 | arch-snapshot | executing→closing | 本轮快照已落盘 | 在途 change legacy 豁免 |
 

package/skills/workflow-start/SKILL.md

@@ -90,6 +90,12 @@ Guard: `tf runtime guard check <dir> exploring specifying --json` → fail = BLO
 ### Route to contract-builder (dispatch sub-agent)
 Guard: `... check <dir> specifying bridging --json` → fail = BLOCK. Artifacts exist, implementation requested, contract missing/stale. Include `DP-3: 契约批准`. **full workflow 必产 test-matrix.md（v0.13 §52 B1）**：契约 `## Test Matrix` 段 + 非空矩阵文件 + `tf state rebuild` 捕获 hash；确无测试需求只能显式 skip + 理由（`test_matrix_skipped=true` + `test_matrix_skip_reason`）。GLAF4 Java 项目实施委托（glaf4-dev）与矩阵工具选择见 `references/routing-rules.md`「Route to glaf4-dev 实施委托」。
 
+### Route 前 Pre-check：服务缺漏检测（v0.45.0 project-initialize 触发接入，场景②；位置 = contract-builder 后、DP-4 前）
+
+dispatch build-executor 前，检查 change 涉及的服务是否在工作空间存在：从 design.md/specs 涉及的 target 类提取所属服务，检查服务子目录 + 技术栈特征（pom.xml/package.json 等）。**缺漏 → AskUserQuestion 确认**：
+- **「未拉取」**：服务已存在于远端/其他分支 → 提示 git pull/检出对应服务后继续
+- **「需要初始化」**：全新服务 → 引导 `project-initialize` skill（架构选择 → 服务命名确认 → 创建空服务子目录 → 委托初始化骨架），完成后回 change 继续
+
 ### 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，禁止绕过。
 

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 | 键盘/画面/弹层交互细节？ |