bmad-method 6.0.0-alpha.7 → 6.0.0-alpha.9

package/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/validation-criteria.yaml

@@ -1,189 +0,0 @@
-# Implementation Readiness Validation Criteria
-# Defines systematic validation rules by project level
-
-validation_rules:
-  # Level 0-1 Projects (Simple, minimal planning)
-  level_0_1:
-    required_documents:
-      - tech_spec
-      - stories_or_tasks
-
-    validations:
-      - name: "Tech Spec Completeness"
-        checks:
-          - "All features defined with implementation approach"
-          - "Technical dependencies identified"
-          - "API contracts defined if applicable"
-          - "Data models specified"
-
-      - name: "Story Coverage"
-        checks:
-          - "All tech spec features have corresponding stories"
-          - "Stories are sequenced logically"
-          - "Technical tasks are defined"
-          - "No critical gaps in coverage"
-
-  # Level 2 Projects (PRD + Tech Spec, no separate architecture)
-  level_2:
-    required_documents:
-      - prd
-      - tech_spec # Includes architecture decisions
-      - epics_and_stories
-
-    validations:
-      - name: "PRD to Tech Spec Alignment"
-        checks:
-          - "All PRD requirements addressed in tech spec"
-          - "Architecture embedded in tech spec covers PRD needs"
-          - "Non-functional requirements are specified"
-          - "Technical approach supports business goals"
-
-      - name: "Story Coverage and Alignment"
-        checks:
-          - "Every PRD requirement has story coverage"
-          - "Stories align with tech spec approach"
-          - "Epic breakdown is complete"
-          - "Acceptance criteria match PRD success criteria"
-
-      - name: "Sequencing Validation"
-        checks:
-          - "Foundation stories come first"
-          - "Dependencies are properly ordered"
-          - "Iterative delivery is possible"
-          - "No circular dependencies"
-
-  # Level 3-4 Projects (Full planning with separate architecture)
-  level_3_4:
-    required_documents:
-      - prd
-      - architecture
-      - epics_and_stories
-
-    validations:
-      - name: "PRD Completeness"
-        checks:
-          - "User requirements fully documented"
-          - "Success criteria are measurable"
-          - "Scope boundaries clearly defined"
-          - "Priorities are assigned"
-
-      - name: "Architecture Coverage"
-        checks:
-          - "All PRD requirements have architectural support"
-          - "System design is complete"
-          - "Integration points defined"
-          - "Security architecture specified"
-          - "Performance considerations addressed"
-          - "If architecture.md: Implementation patterns defined"
-          - "If architecture.md: Technology versions verified and current"
-          - "If architecture.md: Starter template command documented (if applicable)"
-
-      - name: "PRD-Architecture Alignment"
-        checks:
-          - "No architecture gold-plating beyond PRD"
-          - "NFRs from PRD reflected in architecture"
-          - "Technology choices support requirements"
-          - "Scalability matches expected growth"
-          - "If UX spec exists: Architecture supports UX requirements"
-          - "If UX spec exists: Component library supports interaction patterns"
-
-      - name: "Story Implementation Coverage"
-        checks:
-          - "All architectural components have stories"
-          - "Infrastructure setup stories exist"
-          - "Integration implementation planned"
-          - "Security implementation stories present"
-
-      - name: "Comprehensive Sequencing"
-        checks:
-          - "Infrastructure before features"
-          - "Authentication before protected resources"
-          - "Core features before enhancements"
-          - "Dependencies properly ordered"
-          - "Allows for iterative releases"
-
-# Special validation contexts
-special_contexts:
-  greenfield:
-    additional_checks:
-      - "Project initialization stories exist"
-      - "If using architecture.md: First story is starter template initialization"
-      - "Development environment setup documented"
-      - "CI/CD pipeline stories included"
-      - "Initial data/schema setup planned"
-      - "Deployment infrastructure stories present"
-
-  ux_workflow_active:
-    additional_checks:
-      - "UX requirements in PRD"
-      - "UX implementation stories exist"
-      - "Accessibility requirements covered"
-      - "Responsive design addressed"
-      - "User flow continuity maintained"
-
-  api_heavy:
-    additional_checks:
-      - "API contracts fully defined"
-      - "Versioning strategy documented"
-      - "Authentication/authorization specified"
-      - "Rate limiting considered"
-      - "API documentation stories included"
-
-# Severity definitions
-severity_levels:
-  critical:
-    description: "Must be resolved before implementation"
-    examples:
-      - "Missing stories for core requirements"
-      - "Conflicting technical approaches"
-      - "No infrastructure setup for greenfield"
-      - "Security requirements not addressed"
-
-  high:
-    description: "Should be addressed to reduce risk"
-    examples:
-      - "Incomplete acceptance criteria"
-      - "Unclear story dependencies"
-      - "Missing error handling coverage"
-      - "Performance requirements not validated"
-
-  medium:
-    description: "Consider addressing for smoother implementation"
-    examples:
-      - "Documentation gaps"
-      - "Test strategy not defined"
-      - "Monitoring approach unclear"
-      - "Minor sequencing improvements possible"
-
-  low:
-    description: "Minor improvements for consideration"
-    examples:
-      - "Formatting inconsistencies"
-      - "Optional enhancements identified"
-      - "Style guide compliance"
-      - "Nice-to-have features noted"
-
-# Readiness decision criteria
-readiness_decisions:
-  ready:
-    criteria:
-      - "No critical issues found"
-      - "All required documents present"
-      - "Core alignments validated"
-      - "Story sequencing logical"
-      - "Team can begin implementation"
-
-  ready_with_conditions:
-    criteria:
-      - "Only high/medium issues found"
-      - "Mitigation plans identified"
-      - "Core path to MVP clear"
-      - "Issues won't block initial stories"
-
-  not_ready:
-    criteria:
-      - "Critical issues identified"
-      - "Major gaps in coverage"
-      - "Conflicting approaches found"
-      - "Required documents missing"
-      - "Blocking dependencies unresolved"

package/src/modules/bmm/workflows/4-implementation/dev-story/AUDIT-REPORT.md

@@ -1,367 +0,0 @@
-# Workflow Audit Report
-
-**Workflow:** dev-story
-**Audit Date:** 2025-10-25
-**Auditor:** Audit Workflow (BMAD v6)
-**Workflow Type:** Action Workflow
-**Module:** BMM (BMad Method)
-
----
-
-## Executive Summary
-
-**Overall Status:** GOOD - Minor issues to address
-
-- Critical Issues: 0
-- Important Issues: 3
-- Cleanup Recommendations: 2
-
-The dev-story workflow is well-structured and follows most BMAD v6 standards. The workflow correctly sets `web_bundle: false` as expected for implementation workflows. However, there are several config variable usage issues and some variables referenced in instructions that are not defined in the YAML.
-
----
-
-## 1. Standard Config Block Validation
-
-**Status:** PASS ✓
-
-The workflow.yaml contains all required standard config variables:
-
-- ✓ `config_source: "{project-root}/bmad/bmm/config.yaml"` - Correctly defined
-- ✓ `output_folder: "{config_source}:output_folder"` - Pulls from config_source
-- ✓ `user_name: "{config_source}:user_name"` - Pulls from config_source
-- ✓ `communication_language: "{config_source}:communication_language"` - Pulls from config_source
-- ✓ `date: system-generated` - Correctly set
-
-All standard config variables are present and properly formatted using {project-root} variable syntax.
-
----
-
-## 2. YAML/Instruction/Template Alignment
-
-**Variables Analyzed:** 9 (excluding standard config)
-**Used in Instructions:** 6
-**Unused (Bloat):** 3
-
-### YAML Variables Defined
-
-1. `story_dir` - USED in instructions (file paths)
-2. `context_path` - UNUSED (appears to duplicate story_dir)
-3. `story_file` - USED in instructions
-4. `context_file` - USED in instructions
-5. `installed_path` - USED in instructions (workflow.xml reference)
-6. `instructions` - USED in instructions (self-reference in critical tag)
-7. `validation` - USED in instructions (checklist reference)
-8. `web_bundle` - CONFIGURATION (correctly set to false)
-9. `date` - USED in instructions (config variable)
-
-### Variables Used in Instructions But NOT Defined in YAML
-
-**IMPORTANT ISSUE:** The following variables are referenced in instructions.md but are NOT defined in workflow.yaml:
-
-1. `{user_skill_level}` - Used 4 times (lines 6, 13, 173, 182)
-2. `{document_output_language}` - Used 1 time (line 7)
-3. `{run_until_complete}` - Used 1 time (line 108)
-4. `{run_tests_command}` - Used 1 time (line 120)
-
-These variables appear to be pulling from config.yaml but are not explicitly defined in the workflow.yaml file. While the config_source mechanism may provide these, workflow.yaml should document all variables used in the workflow for clarity.
-
-### Unused Variables (Bloat)
-
-1. **context_path** - Defined as `"{config_source}:dev_story_location"` but never used. This duplicates `story_dir` functionality.
-
----
-
-## 3. Config Variable Usage
-
-**Communication Language:** PASS ✓
-**User Name:** PASS ✓
-**Output Folder:** PASS ✓
-**Date:** PASS ✓
-
-### Detailed Analysis
-
-**Communication Language:**
-
-- ✓ Used in line 6: "Communicate all responses in {communication_language}"
-- ✓ Properly used as agent instruction variable (not in template)
-
-**User Name:**
-
-- ✓ Used in line 169: "Communicate to {user_name} that story implementation is complete"
-- ✓ Appropriately used for personalization
-
-**Output Folder:**
-
-- ✓ Used multiple times for sprint-status.yaml file paths
-- ✓ All file operations target {output_folder} correctly
-- ✓ No hardcoded paths detected
-
-**Date:**
-
-- ✓ Available for agent use (system-generated)
-- ✓ Used appropriately in context of workflow execution
-
-### Additional Config Variables
-
-**IMPORTANT ISSUE:** The workflow uses additional variables that appear to come from config but are not explicitly documented:
-
-1. `{user_skill_level}` - Used to tailor communication style
-2. `{document_output_language}` - Used for document generation
-3. `{run_until_complete}` - Used for execution control
-4. `{run_tests_command}` - Used for test execution
-
-These should either be:
-
-- Added to workflow.yaml with proper config_source references, OR
-- Documented as optional config variables with defaults
-
----
-
-## 4. Web Bundle Validation
-
-**Web Bundle Present:** No (Intentional)
-**Status:** EXPECTED ✓
-
-The workflow correctly sets `web_bundle: false`. This is the expected configuration for implementation workflows that:
-
-- Run locally in the development environment
-- Don't need to be bundled for web deployment
-- Are IDE-integrated workflows
-
-**No issues found** - This is the correct configuration for dev-story.
-
----
-
-## 5. Bloat Detection
-
-**Bloat Percentage:** 11% (1 unused field / 9 total fields)
-**Cleanup Potential:** Low
-
-### Unused YAML Fields
-
-1. **context_path** (line 11 in workflow.yaml)
-   - Defined as: `"{config_source}:dev_story_location"`
-   - Never referenced in instructions.md
-   - Duplicates functionality of `story_dir` variable
-   - **Recommendation:** Remove this variable as `story_dir` serves the same purpose
-
-### Hardcoded Values
-
-No significant hardcoded values that should be variables were detected. The workflow properly uses variables for:
-
-- File paths ({output_folder}, {story_dir})
-- User personalization ({user_name})
-- Communication style ({communication_language}, {user_skill_level})
-
-### Calculation
-
-- Total yaml fields: 9 (excluding standard config and metadata)
-- Used fields: 8
-- Unused fields: 1 (context_path)
-- Bloat percentage: 11%
-
-**Status:** Acceptable (under 15% threshold)
-
----
-
-## 6. Template Variable Mapping
-
-**Not Applicable** - This is an action workflow, not a document workflow.
-
-No template.md file exists, which is correct for action-type workflows.
-
----
-
-## 7. Instructions Quality Analysis
-
-### Structure
-
-- ✓ Steps numbered sequentially (1, 1.5, 2-7)
-- ✓ Each step has clear goal attributes
-- ✓ Proper use of XML tags (<action>, <check>, <goto>, <anchor>, <output>)
-- ✓ Logical flow control with anchors and conditional checks
-- ✓ Repeat patterns used appropriately (step 2-5 loop)
-
-### Critical Tags
-
-- ✓ Critical blocks present and well-defined
-- ✓ Clear references to workflow execution engine
-- ✓ Workflow.yaml load requirement specified
-- ✓ Communication preferences documented
-
-### Variable Usage Consistency
-
-**ISSUE:** Inconsistent variable syntax found:
-
-1. Lines 4, 5 use `{project_root}` (underscore)
-2. Line 166 uses `{project-root}` (hyphen)
-
-**Recommendation:** Standardize to `{project-root}` throughout (hyphen is the standard in BMAD v6)
-
-### Step Quality
-
-**Excellent:**
-
-- Steps are focused and single-purpose
-- Clear HALT conditions defined
-- Comprehensive validation checks
-- Good error handling patterns
-- Iterative execution model well-structured
-
-**Areas for improvement:**
-
-- Step 1 is complex and could potentially be split
-- Some <action if="..."> conditionals could be clearer with <check> blocks
-
----
-
-## Recommendations
-
-### Critical (Fix Immediately)
-
-None - No critical issues detected.
-
-### Important (Address Soon)
-
-1. **Document or Define Missing Variables**
-   - Add explicit definitions in workflow.yaml for: `user_skill_level`, `document_output_language`, `run_until_complete`, `run_tests_command`
-   - OR document these as optional config variables with defaults
-   - These variables are used in instructions but not defined in YAML
-   - **Impact:** Reduces clarity and may cause confusion about variable sources
-
-2. **Standardize project-root Variable Syntax**
-   - Change line 4 `{project_root}` to `{project-root}` (hyphen)
-   - Ensure consistency with BMAD v6 standard naming convention
-   - **Impact:** Maintains consistency with framework standards
-
-3. **Remove or Use context_path Variable**
-   - Variable `context_path` is defined but never used
-   - Since `story_dir` serves the same purpose, remove `context_path`
-   - OR if there's a semantic difference, document why both exist
-   - **Impact:** Reduces bloat and potential confusion
-
-### Cleanup (Nice to Have)
-
-1. **Consider Splitting Step 1**
-   - Step 1 handles both story discovery AND file loading
-   - Could be split into "1. Find Story" and "2. Load Story Files"
-   - Would improve clarity and maintainability
-   - **Impact:** Minor improvement to workflow structure
-
-2. **Add Variable Documentation Comment**
-   - Add a comment block in workflow.yaml listing all variables used by this workflow
-   - Include both explicit YAML variables and config-pulled variables
-   - Example format:
-     ```yaml
-     # Workflow-specific variables
-     # - story_file: Path to story markdown
-     # - story_dir: Directory containing stories
-     #
-     # Config-pulled variables (from bmm/config.yaml)
-     # - user_skill_level: User's technical skill level
-     # - document_output_language: Language for generated docs
-     ```
-   - **Impact:** Improves developer understanding and maintenance
-
----
-
-## Validation Checklist
-
-### Structure ✓
-
-- [x] workflow.yaml loads without YAML syntax errors
-- [x] instructions.md exists and is properly formatted
-- [x] No template.md (correct for action workflow)
-- [x] All critical headers present in instructions
-- [x] Workflow type correctly identified (action)
-- [x] All referenced files exist
-- [x] No placeholder text remains
-
-### Standard Config Block ✓
-
-- [x] config_source points to correct module config
-- [x] output_folder pulls from config_source
-- [x] user_name pulls from config_source
-- [x] communication_language pulls from config_source
-- [x] date is system-generated
-- [x] Config source uses {project-root} variable
-- [x] Standard config comment present
-
-### Config Variable Usage ✓
-
-- [x] Instructions communicate in {communication_language}
-- [x] Instructions address {user_name}
-- [x] All file outputs use {output_folder}
-- [x] No hardcoded paths
-- [x] Date available for agent awareness
-
-### YAML/Instruction/Template Alignment ⚠️
-
-- [⚠️] Some variables used in instructions not defined in YAML
-- [x] Template variables N/A (action workflow)
-- [x] Variable names are descriptive
-- [⚠️] One unused yaml field (context_path)
-
-### Web Bundle Validation ✓
-
-- [x] web_bundle: false is correct for this workflow
-- [x] No web_bundle section needed
-- [x] Workflow is local/IDE-integrated only
-
-### Instructions Quality ✓
-
-- [x] Steps numbered sequentially
-- [x] Clear goal attributes
-- [x] Proper XML tag usage
-- [x] Logical flow control
-- [⚠️] Minor inconsistency: {project_root} vs {project-root}
-
-### Bloat Detection ✓
-
-- [x] Bloat percentage: 11% (acceptable, under 15%)
-- [x] No significant hardcoded values
-- [x] No redundant configuration
-- [x] One cleanup recommendation (context_path)
-
----
-
-## Next Steps
-
-1. **Define missing variables** - Add explicit YAML definitions or document as config-pulled variables
-2. **Standardize variable syntax** - Change `{project_root}` to `{project-root}`
-3. **Remove context_path** - Clean up unused variable
-4. **Re-run audit** - Verify improvements after fixes
-
----
-
-## Additional Notes
-
-### Strengths
-
-1. **Comprehensive Workflow Logic:** The dev-story workflow is well-thought-out with proper error handling, validation gates, and iterative execution
-2. **Config Integration:** Excellent use of config variables for user personalization and output management
-3. **Clear Documentation:** Instructions are detailed with specific HALT conditions and validation checkpoints
-4. **Proper Web Bundle Setting:** Correctly identifies this as a local-only workflow with web_bundle: false
-5. **Step Flow:** Excellent use of anchors, goto, and conditional checks for complex flow control
-
-### Workflow Purpose
-
-This workflow executes user stories by:
-
-- Finding ready-for-dev stories from sprint status
-- Implementing tasks and subtasks incrementally
-- Writing comprehensive tests
-- Validating against acceptance criteria
-- Updating story status through sprint lifecycle
-- Supporting different user skill levels with adaptive communication
-
-The workflow is a critical part of the BMM implementation phase and shows mature design patterns.
-
----
-
-**Audit Complete** - Generated by audit-workflow v1.0
-
-**Pass Rate:** 89% (62 passed / 70 total checks)
-**Recommendation:** Good - Minor fixes needed
-
-The dev-story workflow is production-ready with minor improvements recommended. The issues identified are primarily documentation and consistency improvements rather than functional problems.

package/src/modules/bmm/workflows/workflow-status/sample-level-3-workflow.yaml

@@ -1,49 +0,0 @@
-# Workflow Status Template
-# This tracks progress through phases 1-3 of the BMM methodology
-# Phase 4 (Implementation) is tracked separately in sprint-status.yaml
-
-# generated: 2025-10-29
-# project: Enterprise Customer Portal
-# project_type: software
-# project_level: 3
-# field_type: greenfield
-# workflow_path: greenfield-level-3.yaml
-
-# STATUS DEFINITIONS:
-# ==================
-# Initial Status (before completion):
-#   - required: Must be completed to progress
-#   - optional: Can be completed but not required
-#   - recommended: Strongly suggested but not required
-#   - conditional: Required only if certain conditions met (e.g., if_has_ui)
-#
-# Completion Status:
-#   - {file-path}: File created/found (e.g., "docs/product-brief.md")
-#   - skipped: Optional/conditional workflow that was skipped
-
-generated: 2025-10-29
-project: Enterprise Customer Portal
-project_type: software
-project_level: 3
-field_type: greenfield
-workflow_path: greenfield-level-3.yaml
-
-workflow_status:
-  # Phase 1: Analysis
-  brainstorm-project: docs/brainstorm-session-2025-10-15.md
-  research: docs/research-api-patterns.md
-  product-brief: docs/product-brief.md
-
-  # Phase 2: Planning
-  prd: docs/prd.md
-  validate-prd: skipped
-  create-design: docs/ux-design.md
-
-  # Phase 3: Solutioning
-  create-architecture: required
-  validate-architecture: optional
-  solutioning-gate-check: recommended
-
-  # Phase 4: Implementation
-  sprint-planning: required
-  # Note: Subsequent implementation workflows tracked in sprint-status.yaml

package/test/fixtures/agent-schema/invalid/persona/principles-as-string.agent.yaml

@@ -1,23 +0,0 @@
-# Test: principles as string instead of array
-# Expected: FAIL
-# Error code: invalid_type
-# Error path: agent.persona.principles
-# Error expected: array
-
-agent:
-  metadata:
-    id: principles-string
-    name: Principles String
-    title: Principles String
-    icon: ❌
-
-  persona:
-    role: Test agent
-    identity: Test identity
-    communication_style: Test style
-    principles: This should be an array, not a string
-
-  menu:
-    - trigger: help
-      description: Show help
-      action: display_help