@zeyue0329/xiaoma-cli 1.0.48 → 1.0.66

package/src/core/skills/xiaoma-shard-doc/workflow.md

@@ -0,0 +1,100 @@
+# Shard Document
+
+**Goal:** Split large markdown documents into smaller, organized files based on level 2 sections using `npx @kayvan/markdown-tree-parser`.
+
+## CRITICAL RULES
+
+- MANDATORY: Execute ALL steps in the EXECUTION section IN EXACT ORDER
+- DO NOT skip steps or change the sequence
+- HALT immediately when halt-conditions are met
+- Each action within a step is a REQUIRED action to complete that step
+
+## EXECUTION
+
+### Step 1: Get Source Document
+
+- Ask user for the source document path if not provided already
+- Verify file exists and is accessible
+- Verify file is markdown format (.md extension)
+- If file not found or not markdown: HALT with error message
+
+### Step 2: Get Destination Folder
+
+- Determine default destination: same location as source file, folder named after source file without .md extension
+  - Example: `/path/to/architecture.md` --> `/path/to/architecture/`
+- Ask user for the destination folder path (`[y]` to confirm use of default: `[suggested-path]`, else enter a new path)
+- If user accepts default: use the suggested destination path
+- If user provides custom path: use the custom destination path
+- Verify destination folder exists or can be created
+- Check write permissions for destination
+- If permission denied: HALT with error message
+
+### Step 3: Execute Sharding
+
+- Inform user that sharding is beginning
+- Execute command: `npx @kayvan/markdown-tree-parser explode [source-document] [destination-folder]`
+- Capture command output and any errors
+- If command fails: HALT and display error to user
+
+### Step 4: Verify Output
+
+- Check that destination folder contains sharded files
+- Verify index.md was created in destination folder
+- Count the number of files created
+- If no files created: HALT with error message
+
+### Step 5: Report Completion
+
+- Display completion report to user including:
+  - Source document path and name
+  - Destination folder path
+  - Number of section files created
+  - Confirmation that index.md was created
+  - Any tool output or warnings
+- Inform user that sharding completed successfully
+
+### Step 6: Handle Original Document
+
+> **Critical:** Keeping both the original and sharded versions defeats the purpose of sharding and can cause confusion.
+
+Present user with options for the original document:
+
+> What would you like to do with the original document `[source-document-name]`?
+>
+> Options:
+> - `[d]` Delete - Remove the original (recommended - shards can always be recombined)
+> - `[m]` Move to archive - Move original to a backup/archive location
+> - `[k]` Keep - Leave original in place (NOT recommended - defeats sharding purpose)
+>
+> Your choice (d/m/k):
+
+#### If user selects `d` (delete)
+
+- Delete the original source document file
+- Confirm deletion to user: "Original document deleted: [source-document-path]"
+- Note: The document can be reconstructed from shards by concatenating all section files in order
+
+#### If user selects `m` (move)
+
+- Determine default archive location: same directory as source, in an `archive` subfolder
+  - Example: `/path/to/architecture.md` --> `/path/to/archive/architecture.md`
+- Ask: Archive location (`[y]` to use default: `[default-archive-path]`, or provide custom path)
+- If user accepts default: use default archive path
+- If user provides custom path: use custom archive path
+- Create archive directory if it does not exist
+- Move original document to archive location
+- Confirm move to user: "Original document moved to: [archive-path]"
+
+#### If user selects `k` (keep)
+
+- Display warning to user:
+  - Keeping both original and sharded versions is NOT recommended
+  - The discover_inputs protocol may load the wrong version
+  - Updates to one will not reflect in the other
+  - Duplicate content taking up space
+  - Consider deleting or archiving the original document
+- Confirm user choice: "Original document kept at: [source-document-path]"
+
+## HALT CONDITIONS
+
+- HALT if npx command fails or produces no output files

package/src/core/skills/xiaoma-shard-doc/xiaoma-skill-manifest.yaml

@@ -0,0 +1 @@
+type: skill

package/src/core/tasks/xiaoma-create-prd/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: xiaoma-create-prd
+description: 'Create a PRD from scratch. Use when the user says "lets create a product requirements document" or "I want to create a new PRD"'
+---
+
+Follow the instructions in ./workflow.md.

package/src/core/tasks/xiaoma-create-prd/data/domain-complexity.csv

@@ -0,0 +1,15 @@
+domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
+healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
+fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
+govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
+edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
+aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
+automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
+scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
+legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
+insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
+energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
+process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
+building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
+gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
+general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"

package/src/core/tasks/xiaoma-create-prd/data/prd-purpose.md

@@ -0,0 +1,354 @@
+# XiaoMa PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw XiaoMa Method.**
+
+---
+
+## What is a XiaoMa PRD?
+
+A dual-audience document serving:
+1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
+2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
+
+Each successive document becomes more AI-tailored and granular.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio**
+
+Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
+
+**Anti-Patterns (Eliminate These):**
+- ❌ "The system will allow users to..." → ✅ "Users can..."
+- ❌ "It is important to note that..." → ✅ State the fact directly
+- ❌ "In order to..." → ✅ "To..."
+- ❌ Conversational filler and padding → ✅ Direct, concise statements
+
+**Goal:** Maximum information per word. Zero fluff.
+
+---
+
+## The Traceability Chain
+
+**PRD starts the chain:**
+```
+Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
+```
+
+**In the PRD, establish:**
+- Vision → Success Criteria alignment
+- Success Criteria → User Journey coverage
+- User Journey → Functional Requirement mapping
+- All requirements traceable to user needs
+
+**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
+
+---
+
+## What Makes Great Functional Requirements?
+
+### FRs are Capabilities, Not Implementation
+
+**Good FR:** "Users can reset their password via email link"
+**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
+
+**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
+**Bad FR:** "Fast loading time" (subjective, unmeasurable)
+
+### SMART Quality Criteria
+
+**Specific:** Clear, precisely defined capability
+**Measurable:** Quantifiable with test criteria
+**Attainable:** Realistic within constraints
+**Relevant:** Aligns with business objectives
+**Traceable:** Links to source (executive summary or user journey)
+
+### FR Anti-Patterns
+
+**Subjective Adjectives:**
+- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
+- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
+
+**Implementation Leakage:**
+- ❌ Technology names, specific libraries, implementation details
+- ✅ Focus on capability and measurable outcomes
+
+**Vague Quantifiers:**
+- ❌ "multiple users", "several options", "various formats"
+- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
+
+**Missing Test Criteria:**
+- ❌ "The system shall provide notifications"
+- ✅ "The system shall send email notifications within 30 seconds of trigger event"
+
+---
+
+## What Makes Great Non-Functional Requirements?
+
+### NFRs Must Be Measurable
+
+**Template:**
+```
+"The system shall [metric] [condition] [measurement method]"
+```
+
+**Examples:**
+- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
+- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
+- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
+
+### NFR Anti-Patterns
+
+**Unmeasurable Claims:**
+- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
+- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
+
+**Missing Context:**
+- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
+
+---
+
+## Domain-Specific Requirements
+
+**Auto-Detect and Enforce Based on Project Context**
+
+Certain industries have mandatory requirements that must be present:
+
+- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
+- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
+- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
+- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
+
+**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections
+1. **Executive Summary** - Vision, differentiator, target users
+2. **Success Criteria** - Measurable outcomes (SMART)
+3. **Product Scope** - MVP, Growth, Vision phases
+4. **User Journeys** - Comprehensive coverage
+5. **Domain Requirements** - Industry-specific compliance (if applicable)
+6. **Innovation Analysis** - Competitive differentiation (if applicable)
+7. **Project-Type Requirements** - Platform-specific needs
+8. **Functional Requirements** - Capability contract (FRs)
+9. **Non-Functional Requirements** - Quality attributes (NFRs)
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+- Clear, professional language
+- Logical flow from vision to requirements
+- Easy for stakeholders to review and approve
+
+**For LLMs:**
+- ## Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Precise, testable language
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the PRD Feeds Next Artifacts:**
+
+**UX Design:**
+- User journeys → interaction flows
+- FRs → design requirements
+- Success criteria → UX metrics
+
+**Architecture:**
+- FRs → system capabilities
+- NFRs → architecture decisions
+- Domain requirements → compliance architecture
+- Project-type requirements → platform choices
+
+**Epics & Stories (created after architecture):**
+- FRs → user stories (1 FR could map to 1-3 stories potentially)
+- Acceptance criteria → story acceptance tests
+- Priority → sprint sequencing
+- Traceability → stories map back to vision
+
+**Development AI Agents:**
+- Precise requirements → implementation clarity
+- Test criteria → automated test generation
+- Domain requirements → compliance enforcement
+- Measurable NFRs → performance targets
+
+---
+
+## Summary: What Makes a Great XiaoMa PRD?
+
+✅ **High Information Density** - Every sentence carries weight, zero fluff
+✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
+✅ **Clear Traceability** - Each requirement links to user need and business objective
+✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
+
+---
+
+**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.
+
+---
+
+## Chinese PRD Anti-Patterns (中文 PRD 反模式)
+
+When `{document_output_language}` is Chinese, the same density/SMART/no-leakage rules apply, but a few culture-specific traps appear repeatedly. Each anti-pattern is numbered (AP-NN) so the validation rubric (`xiaoma-validate-prd/data/prd-quality-rubric.csv`) can reference it directly via `detection_signals`.
+
+### AP-01 — 口号化目标 (Slogan-style goals)
+
+PRDs written in Chinese B2B contexts often inherit marketing copy from internal slide decks. The result is unmeasurable, multi-claim sentences.
+
+- **Detection signals:** "打造", "业界领先", "一站式", "赋能", "数字化转型", "智能化", "全方位"
+- ❌ Bad: "打造业界领先的、智能化、一站式客户成功平台，赋能企业数字化转型。"
+- ✅ Good: "Vision — 让中型企业的客户成功团队在统一画布上看见、解读并干预客户旅程，把流失预警的发现到触达从平均 7 天压到 24 小时内。"
+- **Self-check:** 这一句能映射到至少 1 条可量化的 Success Criteria 吗？如果不能，重写。
+
+### AP-02 — 模糊主语 (Ambiguous subject)
+
+Chinese drops subjects more readily than English, which makes "系统应支持..." sentences feel natural but breaks FR traceability.
+
+- **Detection signals:** "系统应支持", "应当能够", "可以实现", subject-less imperative
+- ❌ Bad: "系统应支持客户档案的查询和管理。"
+- ✅ Good: "FR-PROFILE-01: CSM 可以按公司名 / 标签 / 客户健康度区间检索客户档案。"
+- **Self-check:** Every FR sentence starts with `[Actor]` (CSM, Admin, system, ...)? If actor is "system", is it because no human user is involved (e.g., scheduled jobs)?
+
+### AP-03 — 实现泄漏 (Implementation leakage)
+
+Tech stack names sneak in when authors come from engineering. PRD must describe *what*, not *how*.
+
+- **Detection signals:** "Redis", "PostgreSQL", "Kafka", "JWT", "WebSocket", "Spring Boot", "Vue", any technology proper noun
+- ❌ Bad: "FR-X: 系统使用 Redis 缓存订单查询结果，TTL 30 分钟。"
+- ✅ Good: "FR-ORDER-04: 订单查询 p95 < 200ms（移到 §9 NFR）。"
+- **Self-check:** Does this FR say *what capability exists* or *how it's built*? If "how", strip the tech and either restate as capability or move to NFR.
+
+### AP-04 — 复合需求 (Compound requirements)
+
+A single FR that bundles 2-3 distinct capabilities. Decomposes into multiple stories, breaks 1 FR ↔ 1-3 story mapping.
+
+- **Detection signals:** "且", "并", "同时", "以及", "并且能够"
+- ❌ Bad: "FR-Y: CSM 可以查询客户、添加标签并导出 Excel。"
+- ✅ Good: 拆为 FR-PROFILE-01（查询）/ FR-PROFILE-03（标签）/ FR-EXPORT-02（导出）
+- **Self-check:** Count the verbs in the FR. > 1 verb usually means split. Use the "Channel / Data Object / Action" axis from FR-to-Story Heuristics below.
+
+### AP-05 — 量词缺失 (Missing quantifiers)
+
+Subjective adjectives appear in success criteria and NFRs.
+
+- **Detection signals:** "显著", "明显", "极大", "尽可能", "高效", "快速", "稳定", "良好"
+- ❌ Bad: "客户满意度显著提升，流失率明显下降。"
+- ✅ Good: "SC-02 客户满意度 NPS ≥ 45（季度调研，N ≥ 100）；SC-03 月度流失率从 4.2% 降至 ≤ 2.5%（CRM 仪表板）。"
+- **Self-check:** Does every success metric carry baseline + target + measurement + time window?
+
+---
+
+## FR-to-Story Heuristics (FR→Story 启发式映射规则)
+
+A FR is the capability contract; user stories are the implementation contract. The PM agent uses these heuristics during `step-09-functional` to keep FR granularity right-sized for downstream Epic/Story breakdown.
+
+### Rule 1 — 1 FR maps to 1-3 stories
+
+A FR that decomposes into 4+ stories is too coarse — split it. A FR that decomposes into 0 stories is either redundant with another FR or belongs to NFR.
+
+- 1 story: simple CRUD or read-only capability
+- 2 stories: capability + admin/config variant
+- 3 stories: capability + read-side + write-side (or empty / typical / extreme states)
+
+### Rule 2 — Single Actor only
+
+If a FR mentions two actors, split. Two actors = two journeys = two FRs.
+
+- ❌ "Admin and CSM can both export reports." → split into FR-REPORT-01 (Admin) + FR-REPORT-02 (CSM)
+- Exception: when the actor is "system" for a background job, this rule doesn't apply.
+
+### Rule 3 — "且 / 并 / 同时" usually signals a split
+
+Composite requirements (AP-04 above) are the most common over-coarse pattern. The connective itself is a refactor signal.
+
+### Rule 4 — Split axes
+
+When unclear how to split, use these axes in priority order:
+
+1. **Actor** — who performs it (CSM vs. Admin vs. system)
+2. **Action verb** — what they do (create vs. read vs. update vs. delete)
+3. **Data object** — what they act on (customer vs. tag vs. ticket)
+4. **Channel** — through what surface (web vs. API vs. webhook)
+
+### Rule 5 — Capability area naming
+
+Capability areas (the §8 sub-headers grouping FRs) must be **noun phrases**.
+
+- ✅ "客户档案管理" / "Customer Profile Management"
+- ❌ "管理客户档案" / "Manage Customer Profiles" (verb phrase = becomes a story title, not a capability area)
+
+Suggested area prefixes when generating FR IDs: `PROFILE`, `JOURNEY`, `RISK`, `SUMMARY`, `TICKET`, `TENANT`, `AUTH`, `EXPORT`, `INTEGRATE`, `AUDIT`.
+
+---
+
+## NFR Industry Baselines (NFR 行业基准库)
+
+When the PM agent reaches `step-10-nonfunctional`, it selects a profile based on `project-types.csv` detection in `step-07`, then uses these baselines as the default candidate list. The user can override any threshold during the A/P/C menu, but every NFR must end up with a quantitative threshold + measurement method.
+
+### Profile selection rules
+
+1. If `project_type ∈ {saas_b2b, web_app}` and target users are external paying customers → **SaaS B2B**
+2. If `project_type ∈ {developer_tool, cli_tool}` or target is internal-only → **Internal Tool**
+3. If consumer-facing, public traffic, or expected ≥ 10k concurrent users → **High-concurrency C-end**
+4. Unmatched → fall back to **SaaS B2B** (most stringent middle ground)
+
+### Baseline matrix
+
+| Dimension       | SaaS B2B (默认)                                                   | Internal Tool                  | High-concurrency C-end                       |
+| --------------- | ----------------------------------------------------------------- | ------------------------------ | -------------------------------------------- |
+| Performance     | API p95 < 500ms · p99 < 1.5s · 页面 LCP < 2.5s                    | API p95 < 1s · LCP < 4s        | API p95 < 200ms · p99 < 800ms · LCP < 1.8s   |
+| Availability    | 月度 SLA 99.9% · RTO < 4h · RPO < 15min                           | SLA 99.5% · RTO < 1 day        | SLA 99.95% · RTO < 30min · RPO < 1min        |
+| Security        | OWASP Top 10 全覆盖 · TLS 1.2+ · 静态加密 AES-256 · MFA 可选       | RBAC 强制 · TLS 1.2+           | + DDoS 防护 · WAF · 风控规则引擎             |
+| Scalability     | 单租户 1k 并发 · 横向扩容 ≤ 5min                                  | 100 并发 (内部工具)            | 50k QPS · 弹性扩容触发延迟 < 2min            |
+| Observability   | 关键链路 trace 覆盖 ≥ 95% · 错误率告警 < 5min · 日志保留 90d       | 日志保留 30d · 错误日志告警    | + RUM 全采样 · 业务指标分钟级 · 日志保留 1y  |
+| Compliance      | 数据本地化 · 等保二级 · 审计日志 ≥ 180d · 个保法授权链             | 等保二级 (推荐)                | + 个保法专项 · 跨境数据评估 · 行业专项合规    |
+
+### Per-NFR template
+
+```
+NFR-<DIM>-<NN>: [metric] [condition] [threshold] (measured by [method]) [profile=<profile-name>]
+```
+
+Example (SaaS B2B):
+
+> NFR-PERF-01: API 接口在正常负载下 p95 < 500ms（APM 监控统计，profile=saas_b2b）
+
+When the threshold deviates from the baseline (either tighter or looser), the NFR must include a one-line **rationale**. Example:
+
+> NFR-AVAIL-01: 月度 SLA ≥ 99.95%（profile=saas_b2b override；rationale: 试点客户 SLA 合同要求 99.95%）
+
+---
+
+## Dual-Audience Writing Checklist
+
+A PRD that scores well on this checklist works equally well for the human reviewer (skim → skip → scan) and the LLM downstream consumer (chunk → anchor → cite).
+
+### Human-readable path (Skim · Skip · Scan)
+
+1. **Skim** — Reading only `## Level 2` headers reveals the full structure of the document
+2. **Skip** — Each section opens with a 1-2 sentence summary; reader can skip the rest if not relevant
+3. **Scan** — Tables, bulleted lists, and bolded keywords carry the dense data; prose is minimal
+
+### LLM-consumable path (Chunk · Anchor · Cite)
+
+4. **Chunk** — One concept per paragraph; paragraphs are separable without context loss
+5. **Anchor** — Every section/sub-section has a stable header used for cross-reference (`§N`, `FR-AREA-NN`)
+6. **Cite** — Cross-references inside the PRD use full IDs (e.g., `FR-PROFILE-01` not "the customer search FR")
+
+### Self-contained sections
+
+7. **Forward reference free** — A section never depends on reading a later section to be understood
+8. **Section-local definitions** — Domain terms first introduced in a section are defined within or linked to §5 Domain Requirements terminology table
+
+A section that fails 2+ checklist items is a D13 Dual-Audience Readiness flag in the validation rubric.

package/src/core/tasks/xiaoma-create-prd/data/project-types.csv

@@ -0,0 +1,11 @@
+project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
+api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
+mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
+saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
+developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
+cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
+web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
+game,"game,player,gameplay,level,character","REDIRECT TO USE THE XiaoMa Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
+desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
+iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
+blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"