@zeyue0329/xiaoma-cli 1.0.49 → 6.0.0-alpha.14

package/xiaoma-core/tasks/requirements-coverage-audit.md

@@ -1,198 +0,0 @@
-# Requirements Coverage Audit Task
-
-# 需求覆盖度审计任务
-
-## 任务概述
-
-系统性检查和验证产品需求到用户故事的转化完整性和实施状态，确保所有PRD需求都被正确转化为用户故事并得到有效实施。
-
-## 核心功能
-
-### 📋 需求转化检查
-
-- PRD文档需求是否完全转化为用户故事
-- 模块级需求的用户故事覆盖度分析
-- 需求优先级和实施状态匹配度验证
-
-### ✅ 用户故事完整性检查
-
-- 验证用户故事包含完整的验收标准
-- 检查数据库设计是否完整实施
-- 确认API接口是否完全实现
-- 评估任务分解是否合理且完成
-
-### 🎯 实施状态验证
-
-- 用户故事状态的准确性检查
-- 开发任务的完成度评估
-- QA结果的真实性验证
-- 交付物的完整性确认
-
-## 使用方法
-
-### 基础审计
-
-```bash
-*requirements-coverage-audit
-```
-
-### 专注特定模块的审计
-
-```bash
-*coverage-audit --epic=模块-1基础设施与核心文档展示
-```
-
-### 验证用户故事状态准确性
-
-```bash
-*story-validation --focus=implementation-status
-```
-
-## 执行流程
-
-### 第一阶段：需求源文档分析 (5-8分钟)
-
-1. **加载PRD文档**
-   - 读取主PRD文档
-   - 扫描docs/prd/目录下的模块文件
-   - 提取所有需求和用户故事定义
-   - 构建需求层次结构
-
-2. **提取需求矩阵**
-   - 识别所有模块和用户故事
-   - 提取验收标准和功能点
-   - 分析需求优先级
-   - 构建需求依赖关系
-
-### 第二阶段：用户故事实施分析 (8-12分钟)
-
-1. **扫描已实施用户故事**
-   - 扫描docs/stories/目录
-   - 解析每个用户故事文档
-   - 提取实施状态和完成度
-   - 分析任务完成情况
-
-2. **分析用户故事完整性**
-   - 检查必需章节完整性
-   - 验证数据库设计实施
-   - 检查API接口实现
-   - 分析任务分解和完成度
-
-### 第三阶段：覆盖度映射和差距分析 (5-8分钟)
-
-1. **需求到故事映射**
-   - 建立需求-用户故事映射关系
-   - 识别已实施的需求
-   - 识别未实施的需求
-   - 分析实施覆盖度
-
-2. **识别差距和问题**
-   - 识别需求覆盖差距
-   - 发现不一致的实施状态
-   - 分析质量问题
-   - 生成改进建议
-
-### 第四阶段：生成综合审计报告 (2-5分钟)
-
-1. **生成覆盖度报告**
-   - 计算整体覆盖度指标
-   - 生成需求实施矩阵
-   - 创建可视化图表
-   - 提供详细分析
-
-2. **生成行动计划**
-   - 优先级排序未实施需求
-   - 制定实施路线图
-   - 生成具体行动项
-   - 估算工作量
-
-## 检查维度
-
-### 1. 需求覆盖度分析
-
-- **最低覆盖度**：95%
-- **关键需求覆盖**：100%
-- **指标**：总需求数量、已转化需求数量、覆盖度百分比、未覆盖需求清单
-
-### 2. 用户故事完整性分析
-
-- **结构完整性**：30% 权重
-- **内容质量**：40% 权重
-- **实施细节**：30% 权重
-- **检查项**：必需章节、验收标准、数据库设计、API接口规范、任务分解
-
-### 3. 实施状态准确性验证
-
-- 状态声明与实际内容匹配度
-- QA结果的真实性
-- 开发者记录的完整性
-- 交付物的存在性
-
-### 4. 业务价值实现分析
-
-- 关键功能实施状态
-- 用户价值主张实现度
-- 业务目标达成情况
-- ROI预期实现度
-
-## 输出报告
-
-### 主要报告
-
-- **需求覆盖度审计报告**：执行摘要、详细分析、改进建议
-- **实施差距分析报告**：差距矩阵、优先级排序、行动项
-
-### 数据导出
-
-- **需求矩阵**：结构化需求映射数据 (JSON)
-- **覆盖度指标**：覆盖度指标数据 (JSON)
-- **完整性评分**：用户故事完整性评分 (JSON)
-
-## 质量检查规则
-
-### 用户故事必需元素
-
-- **用户故事格式**：作为...我希望...以便... (HIGH)
-- **验收标准**：至少3条编号列表 (HIGH)
-- **数据库设计相关**：实体、操作、约束 (MEDIUM)
-- **API接口规范**：端点、设计、映射关系 (HIGH)
-- **开发者记录**：代理模型、实现记录、文件列表 (LOW)
-
-### 实施状态验证规则
-
-- **Completed**：需要QA结果、开发记录、文件列表、验收标准实施
-- **InProgress**：需要部分验收标准实施记录和开发记录
-- **Draft**：需要基本结构完整
-
-## 成功标准
-
-### 审计完整性
-
-- 所有PRD需求识别和分类
-- 所有用户故事完整性评估
-- 覆盖度映射100%完成
-- 差距分析全面准确
-
-### 报告质量
-
-- 执行摘要清晰简明
-- 分析数据准确可靠
-- 改进建议具体可行
-- 行动计划优先级明确
-
-### 可执行洞察
-
-- 识别具体的覆盖度差距
-- 提供可执行的改进建议
-- 制定合理的实施时间表
-- 估算准确的工作量
-
-## 预期时长
-
-**总计**：20-30 分钟
-
-## 相关文件
-
-- **模板文件**：`xiaoma-core/templates/requirements-coverage-audit.yaml`
-- **输出位置**：`audit-reports/`
-- **数据源**：`docs/prd/`, `docs/stories/`

package/xiaoma-core/tasks/review-story.md

@@ -1,316 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# review-story
-
-Perform a comprehensive test architecture review with quality gate decision. This adaptive, risk-aware review creates both a story update and a detailed gate file.
-
-## Inputs
-
-```yaml
-required:
-  - story_id: "{epic}.{story}" # e.g., "1.3"
-  - story_path: "{devStoryLocation}/{epic}.{story}.*.md" # Path from core-config.yaml
-  - story_title: "{title}" # If missing, derive from story file H1
-  - story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
-```
-
-## Prerequisites
-
-- Story status must be "Review"
-- Developer has completed all tasks and updated the File List
-- All automated tests are passing
-
-## Review Process - Adaptive Test Architecture
-
-### 1. Risk Assessment (Determines Review Depth)
-
-**Auto-escalate to deep review when:**
-
-- Auth/payment/security files touched
-- No tests added to story
-- Diff > 500 lines
-- Previous gate was FAIL/CONCERNS
-- Story has > 5 acceptance criteria
-
-### 2. Comprehensive Analysis
-
-**A. Requirements Traceability**
-
-- Map each acceptance criteria to its validating tests (document mapping with Given-When-Then, not test code)
-- Identify coverage gaps
-- Verify all requirements have corresponding test cases
-
-**B. Code Quality Review**
-
-- Architecture and design patterns
-- Refactoring opportunities (and perform them)
-- Code duplication or inefficiencies
-- Performance optimizations
-- Security vulnerabilities
-- Best practices adherence
-
-**C. Test Architecture Assessment**
-
-- Test coverage adequacy at appropriate levels
-- Test level appropriateness (what should be unit vs integration vs e2e)
-- Test design quality and maintainability
-- Test data management strategy
-- Mock/stub usage appropriateness
-- Edge case and error scenario coverage
-- Test execution time and reliability
-
-**D. Non-Functional Requirements (NFRs)**
-
-- Security: Authentication, authorization, data protection
-- Performance: Response times, resource usage
-- Reliability: Error handling, recovery mechanisms
-- Maintainability: Code clarity, documentation
-
-**E. Testability Evaluation**
-
-- Controllability: Can we control the inputs?
-- Observability: Can we observe the outputs?
-- Debuggability: Can we debug failures easily?
-
-**F. Technical Debt Identification**
-
-- Accumulated shortcuts
-- Missing tests
-- Outdated dependencies
-- Architecture violations
-
-### 3. Active Refactoring
-
-- Refactor code where safe and appropriate
-- Run tests to ensure changes don't break functionality
-- Document all changes in QA Results section with clear WHY and HOW
-- Do NOT alter story content beyond QA Results section
-- Do NOT change story Status or File List; recommend next status only
-
-### 4. Standards Compliance Check
-
-- Verify adherence to `docs/coding-standards.md`
-- Check compliance with `docs/unified-project-structure.md`
-- Validate testing approach against `docs/testing-strategy.md`
-- Ensure all guidelines mentioned in the story are followed
-
-### 5. Acceptance Criteria Validation
-
-- Verify each AC is fully implemented
-- Check for any missing functionality
-- Validate edge cases are handled
-
-### 6. Documentation and Comments
-
-- Verify code is self-documenting where possible
-- Add comments for complex logic if missing
-- Ensure any API changes are documented
-
-## Output 1: Update Story File - QA Results Section ONLY
-
-**CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
-
-**QA Results Anchor Rule:**
-
-- If `## QA Results` doesn't exist, append it at end of file
-- If it exists, append a new dated entry below existing entries
-- Never edit other sections
-
-After review and any refactoring, append your results to the story file in the QA Results section:
-
-```markdown
-## QA Results
-
-### Review Date: [Date]
-
-### Reviewed By: Quinn (Test Architect)
-
-### Code Quality Assessment
-
-[Overall assessment of implementation quality]
-
-### Refactoring Performed
-
-[List any refactoring you performed with explanations]
-
-- **File**: [filename]
-  - **Change**: [what was changed]
-  - **Why**: [reason for change]
-  - **How**: [how it improves the code]
-
-### Compliance Check
-
-- Coding Standards: [✓/✗] [notes if any]
-- Project Structure: [✓/✗] [notes if any]
-- Testing Strategy: [✓/✗] [notes if any]
-- All ACs Met: [✓/✗] [notes if any]
-
-### Improvements Checklist
-
-[Check off items you handled yourself, leave unchecked for dev to address]
-
-- [x] Refactored user service for better error handling (services/user.service.ts)
-- [x] Added missing edge case tests (services/user.service.test.ts)
-- [ ] Consider extracting validation logic to separate validator class
-- [ ] Add integration test for error scenarios
-- [ ] Update API documentation for new error codes
-
-### Security Review
-
-[Any security concerns found and whether addressed]
-
-### Performance Considerations
-
-[Any performance issues found and whether addressed]
-
-### Files Modified During Review
-
-[If you modified files, list them here - ask Dev to update File List]
-
-### Gate Status
-
-Gate: {STATUS} → qa.qaLocation/gates/{epic}.{story}-{slug}.yml
-Risk profile: qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
-NFR assessment: qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
-
-# Note: Paths should reference core-config.yaml for custom configurations
-
-### Recommended Status
-
-[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
-(Story owner decides final status)
-```
-
-## Output 2: Create Quality Gate File
-
-**Template and Directory:**
-
-- Render from `../templates/qa-gate-tmpl.yaml`
-- Create directory defined in `qa.qaLocation/gates` (see `xiaoma-core/core-config.yaml`) if missing
-- Save to: `qa.qaLocation/gates/{epic}.{story}-{slug}.yml`
-
-Gate file structure:
-
-```yaml
-schema: 1
-story: "{epic}.{story}"
-story_title: "{story title}"
-gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: "1-2 sentence explanation of gate decision"
-reviewer: "Quinn (Test Architect)"
-updated: "{ISO-8601 timestamp}"
-
-top_issues: [] # Empty if no issues
-waiver: { active: false } # Set active: true only if WAIVED
-
-# Extended fields (optional but recommended):
-quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
-expires: "{ISO-8601 timestamp}" # Typically 2 weeks from review
-
-evidence:
-  tests_reviewed: { count }
-  risks_identified: { count }
-  trace:
-    ac_covered: [1, 2, 3] # AC numbers with test coverage
-    ac_gaps: [4] # AC numbers lacking coverage
-
-nfr_validation:
-  security:
-    status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
-  performance:
-    status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
-  reliability:
-    status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
-  maintainability:
-    status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
-
-recommendations:
-  immediate: # Must fix before production
-    - action: "Add rate limiting"
-      refs: ["api/auth/login.ts"]
-  future: # Can be addressed later
-    - action: "Consider caching"
-      refs: ["services/data.ts"]
-```
-
-### Gate Decision Criteria
-
-**Deterministic rule (apply in order):**
-
-If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONCERNS), then NFR statuses, then top_issues severity.
-
-1. **Risk thresholds (if risk_summary present):**
-   - If any risk score ≥ 9 → Gate = FAIL (unless waived)
-   - Else if any score ≥ 6 → Gate = CONCERNS
-
-2. **Test coverage gaps (if trace available):**
-   - If any P0 test from test-design is missing → Gate = CONCERNS
-   - If security/data-loss P0 test missing → Gate = FAIL
-
-3. **Issue severity:**
-   - If any `top_issues.severity == high` → Gate = FAIL (unless waived)
-   - Else if any `severity == medium` → Gate = CONCERNS
-
-4. **NFR statuses:**
-   - If any NFR status is FAIL → Gate = FAIL
-   - Else if any NFR status is CONCERNS → Gate = CONCERNS
-   - Else → Gate = PASS
-
-- WAIVED only when waiver.active: true with reason/approver
-
-Detailed criteria:
-
-- **PASS**: All critical requirements met, no blocking issues
-- **CONCERNS**: Non-critical issues found, team should review
-- **FAIL**: Critical issues that should be addressed
-- **WAIVED**: Issues acknowledged but explicitly waived by team
-
-### Quality Score Calculation
-
-```text
-quality_score = 100 - (20 × number of FAILs) - (10 × number of CONCERNS)
-Bounded between 0 and 100
-```
-
-If `technical-preferences.md` defines custom weights, use those instead.
-
-### Suggested Owner Convention
-
-For each issue in `top_issues`, include a `suggested_owner`:
-
-- `dev`: Code changes needed
-- `sm`: Requirements clarification needed
-- `po`: Business decision needed
-
-## Key Principles
-
-- You are a Test Architect providing comprehensive quality assessment
-- You have the authority to improve code directly when appropriate
-- Always explain your changes for learning purposes
-- Balance between perfection and pragmatism
-- Focus on risk-based prioritization
-- Provide actionable recommendations with clear ownership
-
-## Blocking Conditions
-
-Stop the review and request clarification if:
-
-- Story file is incomplete or missing critical sections
-- File List is empty or clearly incomplete
-- No tests exist when they were required
-- Code changes don't align with story requirements
-- Critical architectural issues that require discussion
-
-## Completion
-
-After review:
-
-1. Update the QA Results section in the story file
-2. Create the gate file in directory from `qa.qaLocation/gates`
-3. Recommend status: "Ready for Done" or "Changes Required" (owner decides)
-4. If files were modified, list them in QA Results and ask Dev to update File List
-5. Always provide constructive feedback and actionable recommendations