@xulthekl/team-flow 0.39.1 → 0.40.1

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

@@ -11,6 +11,8 @@ If the user references an existing brainstorm topic or document, or there is an
 - 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.
+
 Historical `docs/brainstorms/*-requirements.{md,html}` files remain legacy inputs for `ce-plan`, but new outputs write to `prd/{ITERATION_VERSION}/prd.md`.
 
 ## 0.1b Classify Task Domain
@@ -88,9 +90,13 @@ The spine is five tasks, in order:
 ## 0.5 Resolve Iteration Version
 
 Scan the `prd/` directory to detect existing iteration versions (v1, v2, v3, ...).
-- If no iterations exist: suggest creating v1, ask user to confirm
+- 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.
+- 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 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.
 - Scan `prototype/` directory to confirm prototype branch aligns with PRD iteration version (if prototype exists).

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

@@ -7,13 +7,13 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 | PRD 章节 | 信息来源 | 填充策略 |
 |---|---|---|
 | 一、版本修订记录 | 元数据（日期、作者、版本、状态） | **自动填充**：从对话上下文提取日期、用户信息；版本/状态按下方「版本格式规范」填充，**文档状态必须与 frontmatter `frozen` 一致** |
-| 二、业务流程一览 | Phase 1.3 对话：用户/流程/系统交互 | **对话填充**：brainstorm 对话中收集的业务流程信息 |
-| 三、D7.1_业务流程 | Phase 1.3 对话：Key Flows | **对话填充**：从 brainstorm 的 Key Flows 映射 |
+| 二、业务流程一览 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（业务流程一览表） + `requirement/ledger.md`（流程台账 L1~L4 分组） | **对话+台账填充**：优先从 business-analysis.md 的业务流程一览表（L1 分组 ~ L4 子流程）提取；对话补充未落账的流程信息 |
+| 三、D7.1_业务流程 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（流程详情：流程图 + 活动一览表） | **对话+台账填充**：优先从 business-analysis.md 的流程详情（流程图 + 活动一览表）提取；对话补充 Key Flows 中未落账的细节 |
 | 四、D7.2_画面原型及设计 | Phase 1.3 对话：UI/交互需求 | **对话填充**：如涉及 UI，从对话中收集原型信息 |
 | 五、D7.3_报表清单 | Phase 1.3 对话 | **占位保留**：brainstorm 不涉及报表细节，保留模板占位符 |
 | 六、D7.4_业务术语字典 | Phase 1.3 对话 + CONCEPTS.md | **部分填充**：从对话中提取的领域术语，其余保留占位符 |
-| 七、D7.5_系统功能清单 | Phase 1.3 对话：Requirements | **对话填充**：从 brainstorm 的 Requirements 映射 |
-| 八、D7.6_系统功能处理说明书 | Phase 1.3 对话：Key Decisions + Constraints | **部分填充**：权限/交互/异常等从对话收集，硬件/网络保留占位符 |
+| 七、D7.5_系统功能清单 | Phase 1.3 对话 + `requirement/ledger.md`（需求台账 + 场景台账） + `requirement/vN/business-analysis.md` | **对话+台账填充**：每个功能标注关联需求 ID、关联场景 ID、关联流程步骤；从需求台账和场景台账提取关联关系 |
+| 八、D7.6_系统功能处理说明书 | Phase 1.3 对话 + `requirement/vN/business-analysis.md`（按流程组织的功能模块） + `requirement/ledger.md`（流程台账） | **部分填充**：按流程组织，每个功能模块标注所属流程；权限/交互/异常从对话收集，硬件/网络保留占位符 |
 | 九、D7.7_要件定义自查报告 | 自动 | **占位保留**：这是 BA 自查工具，brainstorm 阶段不填充 |
 | 十、D7.8_要件定义完成报告 | 自动 | **占位保留**：这是完成态产物，brainstorm 阶段不填充 |
 | 十一、D7.9_评审会议纪 | 自动 | **占位保留**：这是评审产物，brainstorm 阶段不填充 |
@@ -22,16 +22,44 @@ ce-brainstorm 的对话流程收集的信息需要映射到 PRD 模板的 11 个
 
 1. **brainstorm 对话中没有信息的章节保留模板占位符**，不硬填
 2. **版本修订记录（§1）** 从元数据自动填充：日期、撰写人（如可获取）
-3. **业务流程（§2-§3）** 从 brainstorm 的 Key Flows 和 Actors 映射
+3. **业务流程（§2-§3）** 优先从 `business-analysis.md` 提取（§2 ← 业务流程一览表，§3 ← 流程详情），对话中的 Key Flows 和 Actors 作为补充
 4. **画面原型（§4）** 仅在 brainstorm 涉及 UI 时填充
 5. **业务术语（§6）** 从对话中提取已定义的领域术语
-6. **系统功能（§7-§8）** 从 Requirements 和 Key Decisions 映射
+6. **系统功能（§7-§8）** 从 Requirements 和 Key Decisions 映射；§7 每个功能标注关联需求 ID + 场景 ID + 流程步骤（来源：`ledger.md`），§8 按流程组织并标注所属流程（来源：`business-analysis.md` + `ledger.md`）
 7. **自查/完成/评审（§9-§11）** 全部保留占位符，由后续流程填充
 
+## 台账与业务分析文档映射（v0.38 新增）
+
+当 `requirement/` 目录下存在台账和业务分析文档时，ce-brainstorm 应优先从中提取结构化数据填充 PRD，而非仅依赖对话收集。
+
+### 输入文件与职责
+
+| 文件 | 路径 | 职责 |
+|------|------|------|
+| 需求/场景/流程台账 | `requirement/ledger.md` | 全量条目和关联关系（需求 ID、场景 ID、流程 ID 及交叉引用） |
+| 修订记录 | `requirement/vN/dialogue-log.md` | §1.2 修订记录的引用路径（指向具体对话日志） |
+| 业务分析文档 | `requirement/vN/business-analysis.md` | §2/§3/§7/§8 的结构化数据来源 |
+
+### 章节级映射规则
+
+| PRD 章节 | 台账/文档来源 | 提取内容 |
+|----------|-------------|---------|
+| §1.2 修订记录 | `requirement/vN/dialogue-log.md` | 修订记录引用路径（文件名 + 日期） |
+| §2 业务流程一览 | `ledger.md` 流程台账 + `business-analysis.md` | L1 分组 ~ L4 子流程的业务流程一览表 |
+| §3 D7.1_业务流程 | `business-analysis.md` | 流程详情：流程图 + 活动一览表 |
+| §7 D7.5_系统功能清单 | `ledger.md` 需求台账 + 场景台账 | 每个功能标注：关联需求 ID + 关联场景 ID + 关联流程步骤 |
+| §8 D7.6_系统功能处理说明书 | `business-analysis.md` + `ledger.md` 流程台账 | 按流程组织，每个功能模块标注所属流程 |
+
+### 缺失降级策略
+
+- 台账或业务分析文档不存在时，退回对话填充策略（即原有行为），不阻断 brainstorm 流程
+- 台账存在但某章节对应字段为空时，该章节保留模板占位符并在备注中标注"台账数据待补充"
+- 复利归档后，PRD frontmatter 应更新已发布版本标记，与台账中的`发布版本`字段保持一致
+
 ## 迭代版本（vN）
 
-- `prd/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
-- ce-brainstorm 启动时扫描 `prd/` 目录检测已有迭代
+- `prd/vN/` 或 `requirement/vN/` 中的 N 是产品迭代版本（v1=MVP, v2=扩展），不是文档版本
+- ce-brainstorm 启动时扫描 `prd/` 和 `requirement/` 目录检测已有迭代（`requirement/` 优先）
 - 自动建议最新迭代或创建新迭代，用户确认后继续
 - 每个迭代目录下只有一个 `prd.md` 文件
 

package/skills/ce-brainstorm/references/synthesis-summary.md

@@ -22,6 +22,15 @@ The internal draft is structured in three labeled buckets. Items may appear in t
 
 A session-settled decision (per `references/settled-decisions.md`) is **Stated with provenance** — record it in the Stated bucket with its class, rejected alternative, and one-line reason, never in Inferred: it is the user's confirmed choice, not an agent bet.
 
+**Evidence anchor references (SC-xxx / BP-xxx).** When dialogue content references a specific scenario or business flow that has an assigned ID in the scenario ledger or flow catalog, cite the ID as an evidence anchor rather than relying on prose description alone. Rules:
+
+- Use `SC-xxx` for scenarios, `BP-xxx` for flows — always with the confirmation status tag (✅ confirmed / 🔵 pending).
+- An item that touches multiple scenarios or flows lists all relevant IDs.
+- Prefer ID anchors over prose re-description: "user checkout flow (BP-012 ✅)" is more precise and more traceable than re-describing the flow in words.
+- When no ID exists for a referenced scenario or flow, note it as `(no ID assigned)` so the gap is visible — downstream spec-writing may need to create one.
+
+This keeps internal-draft claims traceable to the source evidence that synthesis-quality-checker C3/C4 verify.
+
 This draft is internal. Do not paste it verbatim into chat. Compose it as a thinking step, then derive stage 2 from it.
 
 ---
@@ -32,6 +41,12 @@ The scoping synthesis is what the user actually sees. It reflects the dialogue's
 
 The scoping synthesis has up to four named sections, each **render-conditional** on having something to say. Empty sections are omitted, not padded.
 
+**Scenario / flow ID references.** When any section below refers to a scenario or business flow that carries an `SC-xxx` or `BP-xxx` ID, include the ID inline — e.g., "…covers the support mute flow (BP-012 ✅)." Conventions:
+
+- ✅ confirmed IDs need no further action in the synthesis.
+- 🔵 pending IDs must surface in the **Call outs** section (see below) so the user knows which scope dependencies are not yet validated.
+- When multiple IDs cluster under one bullet, list them all — partial ID coverage defeats traceability.
+
 1. **What we're building** (always present) — 1–3 sentences. The shape that emerged from dialogue, forward-looking, plain words. Not a transcript of "you said X."
 2. **Key trade-offs** (conditional) — 1–3 bullets, each with a brief why. Render only when real trade-offs were made in dialogue.
 3. **What's not in scope** (conditional) — 1–3 bullets, or fold into a single sentence. Render only when deferred items would surprise a downstream reader if absent.
@@ -79,6 +94,12 @@ Each conditional section has its own keep test. Sections are render-conditional
 - **Cheap-now-expensive-later correction** — a scope bet that's cheap to fix now but expensive after the Product Contract lands and ce-plan consumes it
 - **Non-obvious consequence of multi-turn answers** — a downstream effect of combining user-stated answers that the user is unlikely to have tracked through dialogue. Surfaced forward-looking ("X means Y for the doc"), not retrospectively ("you said X"). This category is the multi-turn-dialogue reason call-outs exist at all in ce-brainstorm; do not filter these as "already implied by Stated"
 
+**Unconfirmed (🔵) scenario / flow annotation.** Any scenario (SC-xxx) or flow (BP-xxx) referenced in the synthesis that still carries 🔵 pending status in the ledger must appear as a call-out — even when no other keep-test category applies.
+
+- Format: `🔵 <ID> (<name>) — not yet confirmed by user; scope depends on confirmation.`
+- Example: `🔵 SC-007 (guest checkout) — not yet confirmed; notification scope depends on whether guests are included.`
+- This bypasses the normal keep test: a 🔵 ID always surfaces regardless of other keep-test categories. Confirmed (✅) IDs never appear as call-outs on this basis alone.
+
 Cut anything that doesn't match a keep-test category, including:
 
 - Session-settled decisions — already chosen; they render as `Carrying forward:` lines, never call-outs