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

package/xiaoma-core/tasks/test-design.md

@@ -1,176 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# test-design
-
-Create comprehensive test scenarios with appropriate test level recommendations for story implementation.
-
-## 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)
-```
-
-## Purpose
-
-Design a complete test strategy that identifies what to test, at which level (unit/integration/e2e), and why. This ensures efficient test coverage without redundancy while maintaining appropriate test boundaries.
-
-## Dependencies
-
-```yaml
-data:
-  - test-levels-framework.md # Unit/Integration/E2E decision criteria
-  - test-priorities-matrix.md # P0/P1/P2/P3 classification system
-```
-
-## Process
-
-### 1. Analyze Story Requirements
-
-Break down each acceptance criterion into testable scenarios. For each AC:
-
-- Identify the core functionality to test
-- Determine data variations needed
-- Consider error conditions
-- Note edge cases
-
-### 2. Apply Test Level Framework
-
-**Reference:** Load `test-levels-framework.md` for detailed criteria
-
-Quick rules:
-
-- **Unit**: Pure logic, algorithms, calculations
-- **Integration**: Component interactions, DB operations
-- **E2E**: Critical user journeys, compliance
-
-### 3. Assign Priorities
-
-**Reference:** Load `test-priorities-matrix.md` for classification
-
-Quick priority assignment:
-
-- **P0**: Revenue-critical, security, compliance
-- **P1**: Core user journeys, frequently used
-- **P2**: Secondary features, admin functions
-- **P3**: Nice-to-have, rarely used
-
-### 4. Design Test Scenarios
-
-For each identified test need, create:
-
-```yaml
-test_scenario:
-  id: "{epic}.{story}-{LEVEL}-{SEQ}"
-  requirement: "AC reference"
-  priority: P0|P1|P2|P3
-  level: unit|integration|e2e
-  description: "What is being tested"
-  justification: "Why this level was chosen"
-  mitigates_risks: ["RISK-001"] # If risk profile exists
-```
-
-### 5. Validate Coverage
-
-Ensure:
-
-- Every AC has at least one test
-- No duplicate coverage across levels
-- Critical paths have multiple levels
-- Risk mitigations are addressed
-
-## Outputs
-
-### Output 1: Test Design Document
-
-**Save to:** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
-
-```markdown
-# Test Design: Story {epic}.{story}
-
-Date: {date}
-Designer: Quinn (Test Architect)
-
-## Test Strategy Overview
-
-- Total test scenarios: X
-- Unit tests: Y (A%)
-- Integration tests: Z (B%)
-- E2E tests: W (C%)
-- Priority distribution: P0: X, P1: Y, P2: Z
-
-## Test Scenarios by Acceptance Criteria
-
-### AC1: {description}
-
-#### Scenarios
-
-| ID           | Level       | Priority | Test                      | Justification            |
-| ------------ | ----------- | -------- | ------------------------- | ------------------------ |
-| 1.3-UNIT-001 | Unit        | P0       | Validate input format     | Pure validation logic    |
-| 1.3-INT-001  | Integration | P0       | Service processes request | Multi-component flow     |
-| 1.3-E2E-001  | E2E         | P1       | User completes journey    | Critical path validation |
-
-[Continue for all ACs...]
-
-## Risk Coverage
-
-[Map test scenarios to identified risks if risk profile exists]
-
-## Recommended Execution Order
-
-1. P0 Unit tests (fail fast)
-2. P0 Integration tests
-3. P0 E2E tests
-4. P1 tests in order
-5. P2+ as time permits
-```
-
-### Output 2: Gate YAML Block
-
-Generate for inclusion in quality gate:
-
-```yaml
-test_design:
-  scenarios_total: X
-  by_level:
-    unit: Y
-    integration: Z
-    e2e: W
-  by_priority:
-    p0: A
-    p1: B
-    p2: C
-  coverage_gaps: [] # List any ACs without tests
-```
-
-### Output 3: Trace References
-
-Print for use by trace-requirements task:
-
-```text
-Test design matrix: qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
-P0 tests identified: {count}
-```
-
-## Quality Checklist
-
-Before finalizing, verify:
-
-- [ ] Every AC has test coverage
-- [ ] Test levels are appropriate (not over-testing)
-- [ ] No duplicate coverage across levels
-- [ ] Priorities align with business risk
-- [ ] Test IDs follow naming convention
-- [ ] Scenarios are atomic and independent
-
-## Key Principles
-
-- **Shift left**: Prefer unit over integration, integration over E2E
-- **Risk-based**: Focus on what could go wrong
-- **Efficient coverage**: Test once at the right level
-- **Maintainability**: Consider long-term test maintenance
-- **Fast feedback**: Quick tests run first

package/xiaoma-core/tasks/trace-requirements.md

@@ -1,266 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# trace-requirements
-
-Map story requirements to test cases using Given-When-Then patterns for comprehensive traceability.
-
-## Purpose
-
-Create a requirements traceability matrix that ensures every acceptance criterion has corresponding test coverage. This task helps identify gaps in testing and ensures all requirements are validated.
-
-**IMPORTANT**: Given-When-Then is used here for documenting the mapping between requirements and tests, NOT for writing the actual test code. Tests should follow your project's testing standards (no BDD syntax in test code).
-
-## Prerequisites
-
-- Story file with clear acceptance criteria
-- Access to test files or test specifications
-- Understanding of the implementation
-
-## Traceability Process
-
-### 1. Extract Requirements
-
-Identify all testable requirements from:
-
-- Acceptance Criteria (primary source)
-- User story statement
-- Tasks/subtasks with specific behaviors
-- Non-functional requirements mentioned
-- Edge cases documented
-
-### 2. Map to Test Cases
-
-For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
-
-```yaml
-requirement: "AC1: User can login with valid credentials"
-test_mappings:
-  - test_file: "auth/login.test.ts"
-    test_case: "should successfully login with valid email and password"
-    # Given-When-Then describes WHAT the test validates, not HOW it's coded
-    given: "A registered user with valid credentials"
-    when: "They submit the login form"
-    then: "They are redirected to dashboard and session is created"
-    coverage: full
-
-  - test_file: "e2e/auth-flow.test.ts"
-    test_case: "complete login flow"
-    given: "User on login page"
-    when: "Entering valid credentials and submitting"
-    then: "Dashboard loads with user data"
-    coverage: integration
-```
-
-### 3. Coverage Analysis
-
-Evaluate coverage for each requirement:
-
-**Coverage Levels:**
-
-- `full`: Requirement completely tested
-- `partial`: Some aspects tested, gaps exist
-- `none`: No test coverage found
-- `integration`: Covered in integration/e2e tests only
-- `unit`: Covered in unit tests only
-
-### 4. Gap Identification
-
-Document any gaps found:
-
-```yaml
-coverage_gaps:
-  - requirement: "AC3: Password reset email sent within 60 seconds"
-    gap: "No test for email delivery timing"
-    severity: medium
-    suggested_test:
-      type: integration
-      description: "Test email service SLA compliance"
-
-  - requirement: "AC5: Support 1000 concurrent users"
-    gap: "No load testing implemented"
-    severity: high
-    suggested_test:
-      type: performance
-      description: "Load test with 1000 concurrent connections"
-```
-
-## Outputs
-
-### Output 1: Gate YAML Block
-
-**Generate for pasting into gate file under `trace`:**
-
-```yaml
-trace:
-  totals:
-    requirements: X
-    full: Y
-    partial: Z
-    none: W
-  planning_ref: "qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md"
-  uncovered:
-    - ac: "AC3"
-      reason: "No test found for password reset timing"
-  notes: "See qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md"
-```
-
-### Output 2: Traceability Report
-
-**Save to:** `qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`
-
-Create a traceability report with:
-
-```markdown
-# Requirements Traceability Matrix
-
-## Story: {epic}.{story} - {title}
-
-### Coverage Summary
-
-- Total Requirements: X
-- Fully Covered: Y (Z%)
-- Partially Covered: A (B%)
-- Not Covered: C (D%)
-
-### Requirement Mappings
-
-#### AC1: {Acceptance Criterion 1}
-
-**Coverage: FULL**
-
-Given-When-Then Mappings:
-
-- **Unit Test**: `auth.service.test.ts::validateCredentials`
-  - Given: Valid user credentials
-  - When: Validation method called
-  - Then: Returns true with user object
-
-- **Integration Test**: `auth.integration.test.ts::loginFlow`
-  - Given: User with valid account
-  - When: Login API called
-  - Then: JWT token returned and session created
-
-#### AC2: {Acceptance Criterion 2}
-
-**Coverage: PARTIAL**
-
-[Continue for all ACs...]
-
-### Critical Gaps
-
-1. **Performance Requirements**
-   - Gap: No load testing for concurrent users
-   - Risk: High - Could fail under production load
-   - Action: Implement load tests using k6 or similar
-
-2. **Security Requirements**
-   - Gap: Rate limiting not tested
-   - Risk: Medium - Potential DoS vulnerability
-   - Action: Add rate limit tests to integration suite
-
-### Test Design Recommendations
-
-Based on gaps identified, recommend:
-
-1. Additional test scenarios needed
-2. Test types to implement (unit/integration/e2e/performance)
-3. Test data requirements
-4. Mock/stub strategies
-
-### Risk Assessment
-
-- **High Risk**: Requirements with no coverage
-- **Medium Risk**: Requirements with only partial coverage
-- **Low Risk**: Requirements with full unit + integration coverage
-```
-
-## Traceability Best Practices
-
-### Given-When-Then for Mapping (Not Test Code)
-
-Use Given-When-Then to document what each test validates:
-
-**Given**: The initial context the test sets up
-
-- What state/data the test prepares
-- User context being simulated
-- System preconditions
-
-**When**: The action the test performs
-
-- What the test executes
-- API calls or user actions tested
-- Events triggered
-
-**Then**: What the test asserts
-
-- Expected outcomes verified
-- State changes checked
-- Values validated
-
-**Note**: This is for documentation only. Actual test code follows your project's standards (e.g., describe/it blocks, no BDD syntax).
-
-### Coverage Priority
-
-Prioritize coverage based on:
-
-1. Critical business flows
-2. Security-related requirements
-3. Data integrity requirements
-4. User-facing features
-5. Performance SLAs
-
-### Test Granularity
-
-Map at appropriate levels:
-
-- Unit tests for business logic
-- Integration tests for component interaction
-- E2E tests for user journeys
-- Performance tests for NFRs
-
-## Quality Indicators
-
-Good traceability shows:
-
-- Every AC has at least one test
-- Critical paths have multiple test levels
-- Edge cases are explicitly covered
-- NFRs have appropriate test types
-- Clear Given-When-Then for each test
-
-## Red Flags
-
-Watch for:
-
-- ACs with no test coverage
-- Tests that don't map to requirements
-- Vague test descriptions
-- Missing edge case coverage
-- NFRs without specific tests
-
-## Integration with Gates
-
-This traceability feeds into quality gates:
-
-- Critical gaps → FAIL
-- Minor gaps → CONCERNS
-- Missing P0 tests from test-design → CONCERNS
-
-### Output 3: Story Hook Line
-
-**Print this line for review task to quote:**
-
-```text
-Trace matrix: qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
-```
-
-- Full coverage → PASS contribution
-
-## Key Principles
-
-- Every requirement must be testable
-- Use Given-When-Then for clarity
-- Identify both presence and absence
-- Prioritize based on risk
-- Make recommendations actionable

package/xiaoma-core/tasks/validate-next-story.md

@@ -1,136 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# Validate Next Story Task
-
-## Purpose
-
-To comprehensively validate a story draft before implementation begins, ensuring it is complete, accurate, and provides sufficient context for successful development. This task identifies issues and gaps that need to be addressed, preventing hallucinations and ensuring implementation readiness.
-
-## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
-
-### 0. Load Core Configuration and Inputs
-
-- Load `.xiaoma-core/core-config.yaml`
-- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story validation."
-- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`
-- Identify and load the following inputs:
-  - **Story file**: The drafted story to validate (provided by user or discovered in `devStoryLocation`)
-  - **Parent epic**: The epic containing this story's requirements
-  - **Architecture documents**: Based on configuration (sharded or monolithic)
-  - **Story template**: `xiaoma-core/templates/story-tmpl.md` for completeness validation
-
-### 1. Template Completeness Validation
-
-- Load `xiaoma-core/templates/story-tmpl.md` and extract all section headings from the template
-- **Missing sections check**: Compare story sections against template sections to verify all required sections are present
-- **Placeholder validation**: Ensure no template placeholders remain unfilled (e.g., `{{EpicNum}}`, `{{role}}`, `_TBD_`)
-- **Agent section verification**: Confirm all sections from template exist for future agent use
-- **Structure compliance**: Verify story follows template structure and formatting
-
-### 2. File Structure and Source Tree Validation
-
-- **File paths clarity**: Are new/existing files to be created/modified clearly specified?
-- **Source tree relevance**: Is relevant project structure included in Dev Notes?
-- **Directory structure**: Are new directories/components properly located according to project structure?
-- **File creation sequence**: Do tasks specify where files should be created in logical order?
-- **Path accuracy**: Are file paths consistent with project structure from architecture docs?
-
-### 3. UI/Frontend Completeness Validation (if applicable)
-
-- **Component specifications**: Are UI components sufficiently detailed for implementation?
-- **Styling/design guidance**: Is visual implementation guidance clear?
-- **User interaction flows**: Are UX patterns and behaviors specified?
-- **Responsive/accessibility**: Are these considerations addressed if required?
-- **Integration points**: Are frontend-backend integration points clear?
-
-### 4. Acceptance Criteria Satisfaction Assessment
-
-- **AC coverage**: Will all acceptance criteria be satisfied by the listed tasks?
-- **AC testability**: Are acceptance criteria measurable and verifiable?
-- **Missing scenarios**: Are edge cases or error conditions covered?
-- **Success definition**: Is "done" clearly defined for each AC?
-- **Task-AC mapping**: Are tasks properly linked to specific acceptance criteria?
-
-### 5. Validation and Testing Instructions Review
-
-- **Test approach clarity**: Are testing methods clearly specified?
-- **Test scenarios**: Are key test cases identified?
-- **Validation steps**: Are acceptance criteria validation steps clear?
-- **Testing tools/frameworks**: Are required testing tools specified?
-- **Test data requirements**: Are test data needs identified?
-
-### 6. Security Considerations Assessment (if applicable)
-
-- **Security requirements**: Are security needs identified and addressed?
-- **Authentication/authorization**: Are access controls specified?
-- **Data protection**: Are sensitive data handling requirements clear?
-- **Vulnerability prevention**: Are common security issues addressed?
-- **Compliance requirements**: Are regulatory/compliance needs addressed?
-
-### 7. Tasks/Subtasks Sequence Validation
-
-- **Logical order**: Do tasks follow proper implementation sequence?
-- **Dependencies**: Are task dependencies clear and correct?
-- **Granularity**: Are tasks appropriately sized and actionable?
-- **Completeness**: Do tasks cover all requirements and acceptance criteria?
-- **Blocking issues**: Are there any tasks that would block others?
-
-### 8. Anti-Hallucination Verification
-
-- **Source verification**: Every technical claim must be traceable to source documents
-- **Architecture alignment**: Dev Notes content matches architecture specifications
-- **No invented details**: Flag any technical decisions not supported by source documents
-- **Reference accuracy**: Verify all source references are correct and accessible
-- **Fact checking**: Cross-reference claims against epic and architecture documents
-
-### 9. Dev Agent Implementation Readiness
-
-- **Self-contained context**: Can the story be implemented without reading external docs?
-- **Clear instructions**: Are implementation steps unambiguous?
-- **Complete technical context**: Are all required technical details present in Dev Notes?
-- **Missing information**: Identify any critical information gaps
-- **Actionability**: Are all tasks actionable by a development agent?
-
-### 10. Generate Validation Report
-
-Provide a structured validation report including:
-
-#### Template Compliance Issues
-
-- Missing sections from story template
-- Unfilled placeholders or template variables
-- Structural formatting issues
-
-#### Critical Issues (Must Fix - Story Blocked)
-
-- Missing essential information for implementation
-- Inaccurate or unverifiable technical claims
-- Incomplete acceptance criteria coverage
-- Missing required sections
-
-#### Should-Fix Issues (Important Quality Improvements)
-
-- Unclear implementation guidance
-- Missing security considerations
-- Task sequencing problems
-- Incomplete testing instructions
-
-#### Nice-to-Have Improvements (Optional Enhancements)
-
-- Additional context that would help implementation
-- Clarifications that would improve efficiency
-- Documentation improvements
-
-#### Anti-Hallucination Findings
-
-- Unverifiable technical claims
-- Missing source references
-- Inconsistencies with architecture documents
-- Invented libraries, patterns, or standards
-
-#### Final Assessment
-
-- **GO**: Story is ready for implementation
-- **NO-GO**: Story requires fixes before implementation
-- **Implementation Readiness Score**: 1-10 scale
-- **Confidence Level**: High/Medium/Low for successful implementation