@zeyue0329/xiaoma-cli 1.12.0 → 1.13.0

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

@@ -2,9 +2,107 @@
 stepsCompleted: []
 inputDocuments: []
 workflowType: 'prd'
+templateVersion: '2.0-m1'
+densityLevel: ''
+domainTier: ''
+projectType: ''
+version: '0.1.0'
 ---
 
-# Product Requirements Document - {{project_name}}
+# 产品需求文档（PRD） — {{project_name}}
 
-**Author:** {{user_name}}
-**Date:** {{date}}
+**作者：** {{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}}

package/src/xmc/agents/sm.agent.yaml

@@ -47,3 +47,7 @@ agent:
     - trigger: AFP or fuzzy match on auto-full
       exec: "skill:auto-full-pipeline"
       description: "[AFP] Auto Full Pipeline: End-to-end automated requirements-to-delivery — from requirements analysis through PRD, epics, architecture, sprint planning, and story development"
+
+    - trigger: APS or fuzzy match on auto-prd-to-stories
+      exec: "skill:auto-prd-to-stories"
+      description: "[APS] Auto PRD-to-Stories: From an existing prd.md, generate epics + per-story detailed files. STOPS before dev/review/test so business architects can evaluate user-story quality"

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/data/prd-quality-rubric.csv

@@ -0,0 +1,14 @@
+dimension_id,dimension_name,validation_step_ref,weight,pass_criteria,partial_criteria,fail_criteria,gate_threshold,evidence_required,detection_signals,auto_check_hint,severity_on_fail,remediation_hint
+D01,Discovery Completeness,step-v-01-discovery,5,"All inputDocuments loaded; PRD format detected (XiaoMa or Legacy); workflow state confirmed","PRD found but format detection ambiguous; one or more inputDocuments unloadable","No PRD file found OR workflow state unrecognizable","pass=any non-fail","PRD path; inputDocuments list; format detection result","missing inputDocuments frontmatter; missing workflowType field","frontmatter has inputDocuments[] non-empty; workflowType=='prd'",minor,"Re-run xiaoma-create-prd step-01 discovery; verify {planning_artifacts} path"
+D02,Format & Parity,step-v-02-format-detection + step-v-02b-parity-check,6,"Document follows XiaoMa 9-section structure OR legacy version passes parity check vs canonical","Section order non-standard but all 9 sections present; or legacy with ≤2 parity gaps","≥1 required section missing OR section names misaligned with prd-purpose.md canonical","80% of weight (4.8/6)","section header list with line numbers; parity diff if legacy","missing ## Level-2 section header; out-of-order sections; renamed canonical sections","regex /^## (\d+\.\s)?(Executive Summary|Success Criteria|Product Scope|User Journeys|Domain|Innovation|Project-Type|Functional|Non-Functional|产品|用户旅程|功能需求|非功能需求)/; expect 9 matches",major,"See prd-skeleton-reference.md for canonical section names; legacy → run xiaoma-edit-prd legacy-conversion"
+D03,Information Density,step-v-03-density-validation,10,"<3 fluff phrases per 100 lines; no slogan-style Executive Summary; FR/NFR bullets dense","3-7 fluff phrases per 100 lines","≥8 fluff phrases per 100 lines OR slogan-driven §1 (matches AP-01 signals)","70% of weight (7/10)","fluff phrase count; sample line numbers per phrase","打造|业界领先|一站式|赋能|数字化转型|智能化|全方位|the system will allow|it is important to note|in order to","grep -ciE '<signals>' prd.md; ratio = matches / non-blank-lines",major,"See prd-purpose.md Anti-Patterns + AP-01 口号化目标; rewrite Executive Summary with concrete metrics"
+D04,Brief Coverage,step-v-04-brief-coverage-validation,8,"All upstream-input-contract.md §3 'required: yes' fields mapped to PRD §; contract-check.json passed=true","≤3 TBDs unresolved; missing_required.length == 0","missing_required.length > 0 OR tbds.length > 3","75% of weight (6/8)","contract-check.json; PRD section diff vs brief fields list","TBD: <field> from <artifact>; missing source heading; brief field absent from mapped PRD §","load contract-check.json from {planning_artifacts}; count missing_required and tbds arrays",major,"See upstream-input-contract.md missing-field strategy; complete required fields or resolve TBD markers"
+D05,Measurability,step-v-05-measurability-validation,12,"All FRs follow '[Actor] can [capability]'; all NFRs carry metric+threshold+measurement+window; total violations <5","5-10 violations across FR+NFR; format compliant but some context missing",">10 violations OR any NFR without measurement method OR ≥1 NFR with subjective adjective only","80% of weight (9.6/12)","violation list per FR/NFR with line numbers; severity tally","easy|fast|simple|intuitive|user-friendly|responsive|quick|efficient|快速|易用|简单|高效|流畅|稳定|良好|显著|明显|多个|若干|各种","grep FR/NFR sections for signals; count FRs not matching '[Actor] can' pattern; count NFRs missing numeric threshold",blocker,"See prd-purpose.md SMART rules + AP-05 量词缺失; add baseline+target+measurement+window per NFR; rewrite subjective FRs with metrics"
+D06,Traceability,step-v-06-traceability-validation,12,"Vision (§1) → Success Criteria (§2) → User Journey (§4) → FR (§8) chain complete; Traceability Matrix populated with row per FR","Matrix exists but ≤20% FRs have empty 'Maps to' cells","Matrix missing OR >20% FRs have empty mappings OR ≥1 FR with no journey/success linkage","80% of weight (9.6/12)","Traceability Matrix table; FR list with link verification per FR","FR without §1/§2/§4 reference; capability area absent from §3 scope; orphan FR","for each FR-AREA-NN: search Traceability Matrix row presence; verify all 4 mapping cells non-empty",blocker,"Run/rebuild Traceability Matrix in step-11-polish; ensure each FR maps to vision + success criterion + journey step"
+D07,Implementation Leakage,step-v-07-implementation-leakage-validation,8,"Zero technology proper nouns in §1, §2, §4, §8; library/framework names absent from capability descriptions","1-3 leakages, all confined to §7 Project-Type Requirements (acceptable in tech context)",">3 leakages OR any leakage in §1, §2, §4, §8","80% of weight (6.4/8)","leaked terms list with §section + line numbers","Redis|PostgreSQL|MongoDB|MySQL|Kafka|RabbitMQ|JWT|OAuth|WebSocket|React|Vue|Angular|Spring|Django|Express|Docker|Kubernetes|AWS|GCP|Azure|gRPC|GraphQL|REST(?!\sAPI)","grep -nE '<signals>' in §1-§4 and §8 sections only",major,"See prd-purpose.md AP-03 实现泄漏; restate as capability or relocate quantitative facts to §9 NFR"
+D08,Domain Compliance,step-v-08-domain-compliance-validation,10,"All special_sections from domain-complexity.csv for detected domain are present and substantive (>200 chars each)","1 special section missing OR present as stub (<200 chars)","≥2 special sections missing for high-complexity domain (healthcare/fintech/govtech/aerospace/automotive/etc.)","80% of weight (8/10)","domain detected from frontmatter or §1 signals; required special_sections from CSV; PRD §5 content","domain ∈ high-complexity AND §5 missing OR labeled N/A; missing regulatory mention; absent industry terminology table","load domain-complexity.csv; resolve detected domain; cross-check special_sections column tokens vs §5 H3 headers",blocker,"Expand §5 per domain-complexity.csv special_sections column; consult domain-research.md for regulatory landscape"
+D09,Project-Type Fit,step-v-09-project-type-validation,7,"All project-types.csv required_sections for detected project_type are covered in §7; skip_sections marked N/A explicitly","1 required_section thin (<150 chars) or missing","≥2 required_sections missing","75% of weight (5.25/7)","project_type detected; required_sections coverage matrix","project_type detected AND §7 missing required area; required area present but <100 chars","load project-types.csv; verify required_sections (e.g., tenant_model for saas_b2b) appear as H3 in §7",major,"Expand §7 per project-types.csv required_sections; consult technical-research.md"
+D10,SMART (FR/NFR),step-v-10-smart-validation,12,"Every FR and NFR passes Specific/Measurable/Attainable/Relevant/Traceable; zero AP-04 复合需求 patterns","1-3 FRs/NFRs fail one S/M/A/R/T criterion (but not Measurability which is D05)",">3 FRs/NFRs fail OR ≥1 compound FR with multiple verbs / connectives (且|并|同时|and...and)","80% of weight (9.6/12)","per-FR/NFR SMART scorecard; compound-FR list","且|并|同时|以及|并且|FR with >1 action verb; NFR without baseline; capability spans 2+ data objects","for each FR: tokenize verbs and check connectives; for each NFR: regex for numeric threshold and measurement method",blocker,"See prd-purpose.md FR-to-Story Heuristics rules 1-4 + AP-04 复合需求; split compound FRs by Actor/Verb/Object/Channel axes"
+D11,Holistic Quality,step-v-11-holistic-quality-validation,5,"Cross-section consistency; §3 scope items each represented as ≥1 FR; tone uniform; no contradictions","1-2 minor inconsistencies (e.g., MVP item without explicit FR but capability implied)","Major contradictions: feature in MVP scope with no corresponding FR/NFR; vision claims unsupported by §2","60% of weight (3/5)","cross-reference consistency checks; scope-to-FR coverage matrix","scope item not represented as FR; FR with no scope phase tag; vision claim without §2 metric","for each §3 MVP scope item: search §8 for matching capability area or FR; flag uncovered items",minor,"Reconcile §3 with §8 — every MVP scope item must be at least one FR; every vision claim must have ≥1 success criterion"
+D12,Completeness,step-v-12-completeness-validation,5,"All 9 required sections present and non-trivial (>200 chars or explicit N/A justification); frontmatter fields complete (densityLevel/domainTier/projectType/version)","Sections present but 1-2 are stubs (<200 chars without justification)","Required section missing OR ≥3 stubs OR frontmatter missing required field","80% of weight (4/5)","section length statistics; frontmatter audit","H2 section header followed by <200 chars before next H2; missing frontmatter key; empty placeholder ({{...}}) remains","for each H2 in PRD: count chars until next H2 or EOF; verify frontmatter has templateVersion/projectType/etc.",major,"Expand stub sections; if section is N/A, write 1-sentence justification; resolve any residual {{...}} placeholders via step-11-polish"
+D13,Dual-Audience Readiness,step-v-13-report-complete (fused — informational),0,"Skim/Skip/Scan + Chunk/Anchor/Cite checklist (8 items in prd-purpose.md) all green","1-2 checklist items fail","≥3 checklist items fail","informational; not gating","checklist results per item with line numbers","section without summary opener; cross-ref using vague descriptor instead of FR-AREA-NN; forward references; inline lists in prose","scan for cross-refs not matching FR-[A-Z]+-\\d{2,}; check each H2 opener length and self-containedness",minor,"See prd-purpose.md Dual-Audience Writing Checklist; rewrite cross-references with full FR IDs; ensure each section opens with 1-2 sentence summary"

package/src/xmc/workflows/5-full-pipeline/auto-prd-to-stories/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: xiaoma-auto-prd-to-stories
+description: "Automated PRD-to-Stories pipeline (NO development): prd.md → epics → sprint-status → per-story detailed files. Stops before dev/review/QA so business architects can evaluate user-story quality. Use when the user says 'PRD 转故事', 'auto prd to stories', or 'APS'"
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/xmc/workflows/5-full-pipeline/auto-prd-to-stories/checklist.md

@@ -0,0 +1,43 @@
+# Auto PRD-to-Stories Pipeline Completion Checklist
+
+Use this checklist to validate the PRD-to-Stories pipeline completed successfully. This pipeline stops BEFORE development, so only planning + sprint-status + per-story files are in scope.
+
+## Phase 1 — Epics Creation Validation
+
+- [ ] **Input PRD Present** — `{planning_artifacts}/prd.md` exists and was readable at pipeline start
+- [ ] **Epics Created** — `{planning_artifacts}/epics.md` exists with full epic/story breakdown
+- [ ] **PRD Coverage** — Every major functional requirement in `prd.md` is covered by at least one epic
+- [ ] **Story Granularity** — Every epic contains at least one user story
+- [ ] **Acceptance Criteria Present** — Every story has BDD-formatted acceptance criteria (Given/When/Then)
+
+## Phase 2 — Sprint Planning Bridge Validation
+
+- [ ] **Sprint Status Generated** — `{implementation_artifacts}/sprint-status.yaml` exists with valid YAML
+- [ ] **All Epics Represented** — Every epic from `epics.md` has an `epic-N` entry in sprint status
+- [ ] **All Stories Represented** — Every story from `epics.md` has a `N-N-kebab-name` entry in sprint status
+
+## Phase 3 — Per-Story File Generation Validation
+
+- [ ] **One File Per Story** — Every story key in sprint-status.yaml has a corresponding `{implementation_artifacts}/{story_key}.md` file (excluding failed keys)
+- [ ] **Top-Level Sections Present** — Every story file contains: `Status`, `Story`, `Acceptance Criteria`, `Tasks / Subtasks`, `Dev Notes`
+- [ ] **Dev Notes Detailed-Design Subsections Present** — Every story file's `Dev Notes` contains these three mandatory subsections (per the step-04 Detailed Design Output Contract):
+  - [ ] `Functional Requirements Addressed` — lists FR/feature references from prd.md or epics.md
+  - [ ] `Data Model & Database Design` — concrete tables/fields/constraints/indexes OR an explicit `TBD by architect` line with reason
+  - [ ] `Implementation Logic` — concrete interface signatures / algorithm / state machine / error handling OR an explicit `TBD by architect` line with reason
+- [ ] **No Silent Omissions** — No story file contains a Dev Notes subsection that is only a heading with no body content
+- [ ] **Story Status Correct** — Every successfully created story file has `Status: ready-for-dev`
+- [ ] **No Stories Beyond ready-for-dev** — No story file shows status `in-progress`, `review`, or `done` (this pipeline never enters those states)
+- [ ] **Failed Stories Documented** — Any story key in `failed_story_keys` has its failure recorded in the final report with an error reason
+
+## Cross-Phase Traceability Validation
+
+- [ ] **FR Coverage Map Filled** — `epics.md` contains a `### FR Coverage Map` section with concrete `FR-N → Epic X / Story X.Y` mappings (not raw `{{placeholder}}`)
+- [ ] **FR Reverse Traceability** — Every functional requirement extracted from `prd.md` is referenced by at least one story file (verified by step-05's reverse-traceability check). Uncovered FRs are documented in Structural Warnings.
+
+## Pipeline-Level Validation
+
+- [ ] **All 5 Master Steps Executed** — Steps 1–5 completed without HALT (or HALT properly reported)
+- [ ] **No Dev/Review/Test Side Effects** — No code files modified outside `{planning_artifacts}` and `{implementation_artifacts}`
+- [ ] **Phase Boundary Summaries Output** — End-of-phase state snapshots logged for context-recovery
+- [ ] **Final Report Generated** — step-05 produced a unified completion report listing all artifacts and counts
+- [ ] **Artifact Consistency** — `sprint-status.yaml` story keys match story files on disk one-to-one (allowing for documented failures)