@zeyue0329/xiaoma-cli 1.0.48 → 1.0.66

package/src/core/tasks/xiaoma-create-prd/steps-c/step-12-complete.md

@@ -0,0 +1,115 @@
+# Step 12: Workflow Completion
+
+**Final Step - Complete the PRD**
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- ✅ THIS IS A FINAL STEP - Workflow completion required
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
+- 🛑 NO content generation - this is a wrap-up step
+- 📋 FINALIZE document and update workflow status
+- 💬 FOCUS on completion, validation options, and next steps
+- 🎯 UPDATE workflow status files with completion information
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 💾 Update the main workflow status file with completion information (if exists)
+- 📖 Offer validation workflow options to user
+- 🚫 DO NOT load additional steps after this one
+
+## TERMINATION STEP PROTOCOLS:
+
+- This is a FINAL step - workflow completion required
+- Update workflow status file with finalized document
+- Suggest validation and next workflow steps
+- Mark workflow as complete in status tracking
+
+## CONTEXT BOUNDARIES:
+
+- Complete and polished PRD document is available from all previous steps
+- Workflow frontmatter shows all completed steps including polish
+- All collaborative content has been generated, saved, and optimized
+- Focus on completion, validation options, and next steps
+
+## YOUR TASK:
+
+Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
+
+## WORKFLOW COMPLETION SEQUENCE:
+
+### 1. Announce Workflow Completion
+
+Inform user that the PRD is complete and polished:
+- Celebrate successful completion of comprehensive PRD
+- Summarize all sections that were created
+- Highlight that document has been polished for flow and coherence
+- Emphasize document is ready for downstream work
+
+### 2. Workflow Status Update
+
+Update the main workflow status file if there is one:
+
+- Check workflow configuration for a status file (if one exists)
+- Update workflow_status["prd"] = "{outputFile}"
+- Save file, preserving all comments and structure
+- Mark current timestamp as completion time
+
+### 3. Validation Workflow Options
+
+Offer validation workflows to ensure PRD is ready for implementation:
+
+**Available Validation Workflows:**
+
+**Option 1: Check Implementation Readiness** (`skill:xiaoma-check-implementation-readiness`)
+- Validates PRD has all information needed for development
+- Checks epic coverage completeness
+- Reviews UX alignment with requirements
+- Assesses epic quality and readiness
+- Identifies gaps before architecture/design work begins
+
+**When to use:** Before starting technical architecture or epic breakdown
+
+**Option 2: Skip for Now**
+- Proceed directly to next workflows (architecture, UX, epics)
+- Validation can be done later if needed
+- Some teams prefer to validate during architecture reviews
+
+### 4. Suggest Next Workflows
+
+PRD complete. Invoke the `xiaoma-help` skill.
+
+### 5. Final Completion Confirmation
+
+- Confirm completion with user and summarize what has been accomplished
+- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
+- Ask if they'd like to run validation workflow or proceed to next workflows
+
+## SUCCESS METRICS:
+
+✅ PRD document contains all required sections and has been polished
+✅ All collaborative content properly saved and optimized
+✅ Workflow status file updated with completion information (if exists)
+✅ Validation workflow options clearly presented
+✅ Clear next step guidance provided to user
+✅ Document quality validation completed
+✅ User acknowledges completion and understands next options
+
+## FAILURE MODES:
+
+❌ Not updating workflow status file with completion information (if exists)
+❌ Not offering validation workflow options
+❌ Missing clear next step guidance for user
+❌ Not confirming document completeness with user
+❌ Workflow not properly marked as complete in status tracking (if applicable)
+❌ User unclear about what happens next or what validation options exist
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## FINAL REMINDER to give the user:
+
+The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
+
+**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉

package/src/core/tasks/xiaoma-create-prd/templates/prd-skeleton-reference.md

@@ -0,0 +1,428 @@
+# PRD Skeleton Reference
+
+> **Audience:** PM agent (xiaochan / 小蝉) and human reviewers.
+> **Role:** Design reference and quality bar — what each PRD section "looks like done well".
+> **Not:** Copied to the output PRD. Loaded into agent context during `xiaoma-create-prd` and
+> used as the side-by-side standard during `xiaoma-validate-prd`.
+
+For density rules, SMART criteria, anti-pattern catalog (AP-01..AP-05), FR-to-Story
+heuristics, NFR industry baselines, and dual-audience checklist, read:
+`../data/prd-purpose.md`.
+
+For Analyst → PM upstream input expectations and field-to-section mapping, read:
+`../data/upstream-input-contract.md`.
+
+---
+
+## How to Use This Reference
+
+1. **Per-section guidance.** For each of the 9 required sections, this file provides:
+   purpose, fields, a good Chinese example, an anti-pattern Chinese example, and self-check questions.
+2. **Workflow alignment.** Each section maps to one or more `step-c` files; that step is the
+   primary author of the section. PM agent should read the relevant subsection of this reference
+   immediately before generating content for the corresponding step.
+3. **Validation alignment.** Each section's quality bar maps to one or more `step-v` validation
+   dimensions (D01..D13). The reference's "self-check questions" are the lightweight version of
+   those validations.
+4. **Skip rules.** Sections 5, 6, 7 may be marked "N/A" when not applicable — see the project-type
+   matrix at the end of this file.
+
+---
+
+## Section 1 — Executive Summary
+
+**Step source:** `steps-c/step-02c-executive-summary.md`
+**Validation refs:** D04 Brief Coverage · D06 Traceability · D11 Holistic Quality
+
+### Purpose
+
+Anchor the entire PRD in one screen. A reader who skims only this section must come away knowing:
+**what we are building, for whom, what problem it solves, and why it wins.**
+
+### Required fields
+
+| Field                  | Required | Length             |
+| ---------------------- | -------- | ------------------ |
+| Vision statement       | yes      | 1-2 sentences      |
+| Problem statement      | yes      | 1-2 sentences      |
+| Target users (primary) | yes      | bullet list, 2-4   |
+| Value proposition      | yes      | 2-4 bullets        |
+| Differentiation        | yes      | 1-3 bullets        |
+| Project classification | auto     | 1 line (from CSVs) |
+
+### Good example (中文)
+
+> **愿景：** 让中型企业的客户成功团队在统一画布上看见、解读并干预客户旅程，把流失预警的发现到触达从平均 7 天压到 24 小时内。
+>
+> **目标用户：** 客户成功经理（CSM）· 客服主管 · 数据分析师。
+>
+> **价值主张：**
+> - 跨系统聚合的客户旅程视图，单页可视化 ≥ 12 个月历史
+> - LLM 自动摘要近 30 天高风险对话，CSM 平均处理时间从 18 分钟降至 6 分钟
+> - 风险评分与触达建议同源，CSM 单人服务客户数提升 30%
+
+### Anti-pattern example (AP-01 口号化目标)
+
+> ❌ "打造业界领先的、智能化、一站式客户成功平台，赋能企业数字化转型。"
+>
+> 问题：无可测量目标、无主语、无差异化、纯营销话术。
+
+### Self-check
+
+- 愿景是否能被翻译成至少 1 条 Success Criteria 量化指标？
+- 目标用户是否唯一？没有"所有人"或"企业"这种泛主语？
+- 差异化点是否能与至少 1 个竞品对比？
+
+---
+
+## Section 2 — Success Criteria
+
+**Step source:** `steps-c/step-03-success.md`
+**Validation refs:** D05 Measurability · D06 Traceability · D10 SMART
+
+### Purpose
+
+Define what "success" means in numbers. Every metric must be testable post-launch.
+
+### Required fields per metric
+
+| Field             | Required | Example                                |
+| ----------------- | -------- | -------------------------------------- |
+| Metric name       | yes      | 流失预警触达率                         |
+| Baseline          | yes      | 当前 30%（来自 2025 Q4 客服日志抽样）  |
+| Target            | yes      | 上线后 6 个月内 ≥ 95%                  |
+| Measurement       | yes      | 工单系统标签 `risk_alert_acknowledged` |
+| Time window       | yes      | 滚动 30 天                             |
+| Linked to vision? | yes      | §1 愿景"24 小时内触达"                 |
+
+### Good example (中文)
+
+> **SC-01 流失预警触达率**
+> Baseline 30%（2025 Q4 客服日志抽样）→ 上线后 6 个月内 ≥ 95%。
+> 测量：工单系统标签 `risk_alert_acknowledged` ÷ 同期生成的 `risk_alert` 数。
+> 滚动窗口 30 天。对应愿景"24 小时内触达"。
+
+### Anti-pattern example (AP-05 量词缺失)
+
+> ❌ "客户满意度显著提升，流失率明显下降。"
+>
+> 问题：无 baseline、无 target、无测量方法、无时间窗。"显著"/"明显"是反模式。
+
+### Self-check
+
+- 每条指标是否可在产品上线 + 1 个完整测量周期内被验证？
+- 每条指标是否与 §1 中至少一项愿景或价值主张存在可追溯链接？
+- 是否避免了"提升用户体验"这类不可量化指标？
+
+---
+
+## Section 3 — Product Scope
+
+**Step source:** `steps-c/step-08-scoping.md`
+**Validation refs:** D04 Brief Coverage · D12 Completeness
+
+### Purpose
+
+明确写出"做什么、不做什么、之后做什么"。out-of-scope 与 in-scope 同等重要 — 它阻止后续无声扩张。
+
+### Required fields
+
+- **MVP（必须）：** 列表，按 capability area 分组
+- **Out-of-Scope（必须）：** 列表，每条附"为什么不做"一句话
+- **Growth Phase（推荐）：** 列表 + 大致时间窗
+- **Vision Phase（可选）：** 列表
+
+### Good example (中文)
+
+> **MVP（2026 H2 上线）**
+> - 客户档案管理：多源聚合 · 标签 · 检索
+> - 旅程画布：单租户 · 12 个月历史 · 时间轴视图
+> - 风险预警：3 类规则引擎 · 工单系统单向集成
+>
+> **Out-of-Scope**
+> - 海外多语：首期客户均为国内中型企业，海外需求量 < 5%
+> - 自营客服坐席系统：与现有合作伙伴 Salesforce/钉钉客服重叠
+>
+> **Growth Phase（2027 Q1）**
+> - 客户健康度模型可调校
+> - 移动端 PWA
+
+### Anti-pattern
+
+> ❌ "MVP 包含核心功能，后续根据需求迭代。"
+>
+> 问题：无具体功能列表，"核心"/"根据需求"全是占位词。
+
+### Self-check
+
+- Out-of-Scope 是否覆盖了至少 1 个"显然会被问到但本期不做"的场景？
+- MVP 列表是否能 1:1 映射到 §8 的 capability areas？
+
+---
+
+## Section 4 — User Journeys
+
+**Step source:** `steps-c/step-04-journeys.md`
+**Validation refs:** D04 Brief Coverage · D06 Traceability
+
+### Purpose
+
+For each primary persona from §1, capture an end-to-end journey. Journeys are the bridge from
+target users to functional requirements — every FR in §8 must trace back to at least one journey
+step.
+
+### Required fields per journey
+
+- Persona (与 §1 一致)
+- Trigger（旅程触发点）
+- 5-9 steps，每步含：动作 · 触点（系统/页面）· 情绪 · 痛点（如有）
+- Outcome（成功/失败两种结局）
+
+### Good example (中文)
+
+> **CSM 日检视旅程**
+>
+> 触发：上午 9:00 进入工作台。
+>
+> | # | 动作                       | 触点              | 情绪    | 痛点                |
+> | - | -------------------------- | ----------------- | ------- | ------------------- |
+> | 1 | 打开客户旅程画布           | Web 工作台首页    | 期望    | -                   |
+> | 2 | 查看高风险客户列表         | 风险预警面板      | 警觉    | 当前需手动多系统切换 |
+> | 3 | 点击客户卡片查看 30 天摘要 | 客户档案 · 摘要 Tab | 专注    | -                   |
+> | 4 | 决定干预动作               | 触达建议面板      | 紧迫    | -                   |
+> | 5 | 一键创建工单并触达客户     | 工单 + IM 集成   | 满足    | -                   |
+>
+> 结局：成功路径 = 触达后 24h 内客户回复；失败路径 = 工单进入超时队列。
+
+### Anti-pattern
+
+> ❌ "用户登录后查看数据并采取行动。"
+>
+> 问题：步骤过粗（无法映射到 FR）、无触点、无情绪、无失败路径。
+
+### Self-check
+
+- 每个 §1 中列出的 persona 是否至少有一条旅程？
+- 每个旅程步骤是否能追溯到至少 1 个 FR（即将在 §8 中出现）？
+- 是否包含了至少 1 条失败路径？
+
+---
+
+## Section 5 — Domain Requirements
+
+**Step source:** `steps-c/step-05-domain.md`
+**Driver:** `../data/domain-complexity.csv`
+**Validation ref:** D08 Domain Compliance
+
+### Purpose
+
+Industry-mandatory requirements (HIPAA, PCI-DSS, 等保, etc). Auto-detected from project signals;
+the PM agent expands `special_sections` from `domain-complexity.csv` into actual requirements.
+
+### When to write "N/A"
+
+- `domain` 检测为 `general` 且 `complexity` 为 `low`
+- 团队明确无合规外部约束
+
+### Good example (中文 — SaaS B2B 内部企业服务)
+
+> **5.1 数据合规**
+> - 等保二级（要求：访问控制 · 审计日志 · 数据备份 · 安全管理制度）
+> - 个人信息保护法：客户对话内容仅在租户内可见，跨租户隔离强制启用
+> - 数据本地化：客户数据仅存储于中国大陆 IDC
+>
+> **5.2 行业术语表**
+> - 客户健康度（Customer Health Score）：0-100 综合评分
+> - 流失预警（Churn Risk Alert）：触发条件参见 FR-RISK-01
+>
+> **5.3 外部依赖**
+> - 钉钉开放平台 API（v2，限流 100 QPS）
+> - Salesforce REST API（v55.0，OAuth 2.0 授权）
+
+### Anti-pattern
+
+> ❌ "系统满足相关法规要求，符合行业标准。"
+>
+> 问题：未列出具体法规、未列出可验证条款。
+
+---
+
+## Section 6 — Innovation Analysis
+
+**Step source:** `steps-c/step-06-innovation.md`
+**Validation ref:** D11 Holistic Quality
+
+### Purpose
+
+差异化与新颖度分析，避免"做一个市场已有的产品"。
+
+### When to write "N/A"
+
+- 项目为既有产品的复刻或维护性扩展
+- 内部工具，不与外部产品对比
+
+### Good example (中文)
+
+> **6.1 核心差异化**
+> - 唯一同时整合"客户旅程画布 + LLM 摘要 + 风险评分"三能力的国内 SaaS
+> - 国内同类产品（如 X、Y）只覆盖其中 1-2 项
+>
+> **6.2 技术新颖度**
+> - LLM 摘要质量基线 ≥ 4.2/5（人工标注 100 样本）
+> - 风险评分模型可解释性：每条预警附 top-3 触发因子
+>
+> **6.3 风险**
+> - LLM 输出稳定性 — 缓解：引入提示词回归测试集 + 摘要重生成机制
+> - 国内 LLM 厂商策略变化 — 缓解：抽象 LLM 适配层，支持 ≥ 2 家厂商
+
+---
+
+## Section 7 — Project-Type Requirements
+
+**Step source:** `steps-c/step-07-project-type.md`
+**Driver:** `../data/project-types.csv`
+**Validation ref:** D09 Project-Type Fit
+
+### Purpose
+
+Platform-specific 需求清单。从 `project-types.csv.required_sections` 展开，跳过 `skip_sections`
+中列出的章节。
+
+### Good example (saas_b2b)
+
+> - 多租户模型：行级数据隔离 + 租户级配置覆盖
+> - RBAC 矩阵：4 种角色（Admin / Manager / Operator / Viewer）× 8 类资源
+> - 订阅层级：Starter（≤ 10 人）/ Team（≤ 50 人）/ Business（≤ 200 人）
+> - 集成清单：钉钉 · 飞书 · Salesforce · Slack · Webhook
+> - 合规需求：等保二级 · ISO 27001（未来）
+
+---
+
+## Section 8 — Functional Requirements
+
+**Step source:** `steps-c/step-09-functional.md`
+**Validation refs:** D05 Measurability · D06 Traceability · D07 Implementation Leakage · D10 SMART
+
+### Format
+
+```
+### 8.x [Capability Area Name — 名词短语，非动词]
+
+- FR-AREA-NN: [Actor] can [capability]
+```
+
+- FR# 全局唯一，按 capability area 缩写编号（如 FR-PROFILE-01, FR-RISK-01）
+- 总量 20-50 条，按 5-8 个 capability area 分组
+- Capability area = **名词短语**（"客户档案管理"），不是动词短语（"管理客户档案"）
+
+### Good FR examples (中文)
+
+> ### 8.1 客户档案管理
+>
+> - **FR-PROFILE-01:** CSM 可以按公司名 · 标签 · 客户健康度区间检索客户档案
+> - **FR-PROFILE-02:** CSM 可以查看客户的 12 个月聚合活动时间轴
+> - **FR-PROFILE-03:** Admin 可以为客户档案添加自定义标签（最多 20 个/客户）
+>
+> ### 8.2 风险预警
+>
+> - **FR-RISK-01:** 系统可以基于规则引擎对客户产生风险评分（0-100）
+> - **FR-RISK-02:** CSM 可以接收 24 小时内未触达的高风险客户提醒
+
+### FR Anti-patterns (per AP-03 implementation leakage / AP-04 复合需求)
+
+> ❌ "**FR-X:** 系统使用 PostgreSQL 存储客户档案并通过 Redis 缓存查询结果"
+> 修复：剔除技术名词 → "FR-PROFILE-04: 客户档案查询 p95 < 200ms"（这条本应放 §9 NFR）
+>
+> ❌ "**FR-Y:** CSM 可以查询客户、添加标签并导出 Excel"
+> 修复：拆为 3 条 FR，每条单一动作
+
+### Self-check (per FR)
+
+- 单一 Actor？
+- 不含技术栈名词、库名、协议名？
+- 不含主观形容词（"快速"/"易用"）？
+- 能映射到 §4 中至少一个 journey 步骤？
+- 1 条 FR 能拆出 1-3 个 user story？（参见 prd-purpose.md "FR-to-Story Heuristics"）
+
+---
+
+## Section 9 — Non-Functional Requirements
+
+**Step source:** `steps-c/step-10-nonfunctional.md`
+**Profile driver:** `prd-purpose.md "NFR Industry Baselines"`
+**Validation refs:** D05 Measurability · D10 SMART
+
+### 6 dimensions
+
+Performance · Availability · Security · Scalability · Observability · Compliance.
+
+每条 NFR 必须含：metric · threshold · condition · measurement method · profile reference。
+
+### Format
+
+```
+- **NFR-PERF-01:** [metric] [condition] [threshold] (measured by [method])
+```
+
+### Good NFR examples (SaaS B2B profile)
+
+> - **NFR-PERF-01:** API 接口在正常负载下 p95 < 500ms（APM 监控统计）
+> - **NFR-AVAIL-01:** 工作时间（工作日 8:00-22:00）月度 SLA ≥ 99.9%（云厂商 SLA 监控）
+> - **NFR-SEC-01:** 客户对话数据传输强制 TLS 1.2+，静态加密 AES-256（架构评审条目）
+> - **NFR-SCALE-01:** 单租户支持并发 1000 用户，横向扩容时间 ≤ 5 分钟（压测报告）
+> - **NFR-OBS-01:** 关键链路 trace 覆盖率 ≥ 95%，错误率告警延迟 < 5 分钟（Grafana SLO）
+> - **NFR-COMP-01:** 审计日志保留 ≥ 180 天（数据归档策略）
+
+### NFR Anti-pattern
+
+> ❌ "**NFR-X:** 系统应具备良好的扩展性和稳定性"
+>
+> 修复：拆出 NFR-SCALE-01（横向扩容 ≤ 5 分钟）+ NFR-AVAIL-01（SLA ≥ 99.9%），各带阈值。
+
+---
+
+## Traceability Matrix
+
+**Built by:** `steps-c/step-11-polish.md`
+
+A table with one row per FR. Columns:
+
+| FR ID            | Capability Area | Maps to Vision | Maps to Success Criteria | Maps to Journey Step |
+| ---------------- | --------------- | -------------- | ------------------------ | -------------------- |
+| FR-PROFILE-01    | 客户档案管理     | §1 价值主张 1  | SC-03 检索效率           | §4.CSM日检视 step 2  |
+
+A FR with empty "Maps to" cells is a validation D06 Traceability failure.
+
+---
+
+## FR Numbering & Capability Area Naming
+
+- Capability area names: 名词短语（中英均可，与 `{document_output_language}` 一致）
+- Suggested prefixes: `PROFILE`, `JOURNEY`, `RISK`, `SUMMARY`, `TICKET`, `TENANT`, `AUTH`, ...
+- FR ID format: `FR-<AREA>-<NN>`，编号从 01 起，**不复用**已删除的编号
+- 跨章节引用 FR 时使用全 ID（避免歧义）
+
+---
+
+## When to Skip Sections
+
+| Project type     | Skip          | Mark as "N/A"        |
+| ---------------- | ------------- | -------------------- |
+| api_backend      | -             | §4 (replace with API consumer scenarios), §6 if internal |
+| cli_tool         | -             | §4 (replace with CLI usage scenarios) |
+| internal_tool    | -             | §6 if no external competition |
+| general / low complexity | - | §5, §6 |
+
+详见 `../data/project-types.csv` 的 `skip_sections` 列。
+
+---
+
+## Dual-Audience Writing Tips
+
+- **Section headers must be `## Level 2`** — used by LLMs as anchors
+- **One concept per paragraph** — LLMs chunk on paragraph boundaries
+- **Tables for matrices, lists for enumerations** — never inline lists in prose
+- **Cross-references use `§N` or full FR ID** — keeps anchor stable
+- **Avoid forward references** — every section should be self-contained
+
+For the full dual-audience checklist, see `../data/prd-purpose.md` "Dual-Audience Checklist".

package/src/core/tasks/xiaoma-create-prd/templates/prd-template.md

@@ -0,0 +1,108 @@
+---
+stepsCompleted: []
+inputDocuments: []
+workflowType: 'prd'
+templateVersion: '2.0-m1'
+densityLevel: ''
+domainTier: ''
+projectType: ''
+version: '0.1.0'
+---
+
+# 产品需求文档（PRD） — {{project_name}}
+
+**作者：** {{user_name}}　**日期：** {{date}}　**版本：** {{version}}
+
+<!--
+================================================================================
+PRD STRUCTURE — 9 required sections (per prd-purpose.md)
+
+Each section is a placeholder ({{xxx_body}}) to be filled by the create-prd
+workflow (steps-c/step-02c through step-10). Section-level guidance, good/bad
+examples, and naming conventions live in:
+
+  ./prd-skeleton-reference.md
+
+For PRD philosophy, density rules, SMART criteria, FR/NFR anti-patterns,
+NFR industry baselines, and Chinese-language patterns, see:
+
+  ../data/prd-purpose.md
+
+For upstream input expectations (Analyst → PM contract), see:
+
+  ../data/upstream-input-contract.md
+
+Transitional note (M1):
+  step-c steps still append at end-of-file. Until step-c migrates to
+  placeholder-replacement semantics (M3), step-11-polish must scan for any
+  residual {{...}} markers and resolve them before completion.
+================================================================================
+-->
+
+## 1. Executive Summary
+<!-- Purpose:  Vision · Problem · Target Users · Value Prop · Differentiation
+     Length:   3-5 short paragraphs (≤120 chars each)
+     Source:   step-02c (synthesized from steps 2 + 2b)
+     Anti:     口号化目标 (AP-01) · 模糊主语 (AP-02) -->
+{{executive_summary_body}}
+
+## 2. Success Criteria
+<!-- Purpose:  3-7 SMART metrics
+     Each:     baseline · target · measurement method · time window
+     Source:   step-03
+     Anti:     量词缺失 (AP-05) -->
+{{success_criteria_body}}
+
+## 3. Product Scope
+<!-- Purpose:  In-Scope · Out-of-Scope · Future Phases (MVP → Growth → Vision)
+     Format:   list-only, no slogans
+     Source:   step-08 -->
+{{product_scope_body}}
+
+## 4. User Journeys
+<!-- Purpose:  per-persona end-to-end journey
+     Each:     5-9 steps · touchpoints · emotion notes
+     Source:   step-04 -->
+{{user_journeys_body}}
+
+## 5. Domain Requirements
+<!-- Purpose:  mandatory compliance · industry terms · external dependencies
+     Driver:   domain-complexity.csv (auto-detected in step-02-discovery)
+     Empty:    write "N/A — general domain"
+     Source:   step-05 -->
+{{domain_requirements_body}}
+
+## 6. Innovation Analysis
+<!-- Purpose:  differentiation · novelty · competitive risk
+     Empty:    write "N/A"
+     Source:   step-06 -->
+{{innovation_body}}
+
+## 7. Project-Type Requirements
+<!-- Purpose:  platform-specific needs (saas_b2b / api_backend / mobile_app / ...)
+     Driver:   project-types.csv (required_sections · skip_sections)
+     Source:   step-07 -->
+{{project_type_body}}
+
+## 8. Functional Requirements
+<!-- Purpose:  20-50 FRs grouped into 5-8 capability areas
+     Format:   FR-AREA-NN: [Actor] can [capability]
+     Anti:     implementation leakage (AP-03) · 复合需求 (AP-04) · subjective adjectives
+     Source:   step-09 -->
+{{functional_requirements_body}}
+
+## 9. Non-Functional Requirements
+<!-- Purpose:  6 dimensions — Performance · Availability · Security · Scalability · Observability · Compliance
+     Each:     quantitative threshold + measurement method
+     Profile:  SaaS B2B / Internal Tool / High-concurrency C-end (see prd-purpose.md "NFR Industry Baselines")
+     Source:   step-10
+     Anti:     unmeasurable claim · missing context -->
+{{nonfunctional_requirements_body}}
+
+---
+
+## Traceability Matrix
+<!-- Built by step-11-polish:
+       Vision (§1) → Success Criteria (§2) → User Journey (§4) → FR (§8) → Capability Area
+     Format:  table with one row per FR -->
+{{traceability_matrix}}