bmad-method 4.27.6 → 5.0.0

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

@@ -1,145 +0,0 @@
-# review-story
-
-When a developer marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
-
-[[LLM: QA Agent executing review-story task as Senior Developer]]
-
-## Prerequisites
-
-- Story status must be "Review"
-- Developer has completed all tasks and updated the File List
-- All automated tests are passing
-
-## Review Process
-
-1. **Read the Complete Story**
-   - Review all acceptance criteria
-   - Understand the dev notes and requirements
-   - Note any completion notes from the developer
-
-2. **Verify Implementation Against Dev Notes Guidance**
-   - Review the "Dev Notes" section for specific technical guidance provided to the developer
-   - Verify the developer's implementation follows the architectural patterns specified in Dev Notes
-   - Check that file locations match the project structure guidance in Dev Notes
-   - Confirm any specified libraries, frameworks, or technical approaches were used correctly
-   - Validate that security considerations mentioned in Dev Notes were implemented
-
-3. **Focus on the File List**
-   - Verify all files listed were actually created/modified
-   - Check for any missing files that should have been updated
-   - Ensure file locations align with the project structure guidance from Dev Notes
-
-4. **Senior Developer Code Review**
-   - Review code with the eye of a senior developer
-   - If changes form a cohesive whole, review them together
-   - If changes are independent, review incrementally file by file
-   - Focus on:
-     - Code architecture and design patterns
-     - Refactoring opportunities
-     - Code duplication or inefficiencies
-     - Performance optimizations
-     - Security concerns
-     - Best practices and patterns
-
-5. **Active Refactoring**
-   - As a senior developer, you CAN and SHOULD refactor code where improvements are needed
-   - When refactoring:
-     - Make the changes directly in the files
-     - Explain WHY you're making the change
-     - Describe HOW the change improves the code
-     - Ensure all tests still pass after refactoring
-     - Update the File List if you modify additional files
-
-6. **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
-
-7. **Acceptance Criteria Validation**
-   - Verify each AC is fully implemented
-   - Check for any missing functionality
-   - Validate edge cases are handled
-
-8. **Test Coverage Review**
-   - Ensure unit tests cover edge cases
-   - Add missing tests if critical coverage is lacking
-   - Verify integration tests (if required) are comprehensive
-   - Check that test assertions are meaningful
-   - Look for missing test scenarios
-
-9. **Documentation and Comments**
-   - Verify code is self-documenting where possible
-   - Add comments for complex logic if missing
-   - Ensure any API changes are documented
-
-## 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.
-
-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 (Senior Developer QA)
-
-### 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]
-
-### Final Status
-[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
-```
-
-## Key Principles
-
-- You are a SENIOR developer reviewing junior/mid-level work
-- You have the authority and responsibility to improve code directly
-- Always explain your changes for learning purposes
-- Balance between perfection and pragmatism
-- Focus on significant improvements, not nitpicks
-
-## 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. If all items are checked and approved: Update story status to "Done"
-2. If unchecked items remain: Keep status as "Review" for dev to address
-3. Always provide constructive feedback and explanations for learning

package/bmad-core/tasks/update-workflow-plan.md

@@ -1,248 +0,0 @@
-# Update Workflow Plan Task
-
-## Purpose
-
-Update the status of steps in an active workflow plan, mark completions, add notes about deviations, and maintain an accurate record of workflow progress. This task can be called directly by users or automatically by other tasks upon completion.
-
-## Task Instructions
-
-### 0. Load Plan Configuration
-
-[[LLM: First load core-config.yaml to get plan settings]]
-
-Check workflow configuration:
-
-- `workflow.planFile` - Location of the plan (default: docs/workflow-plan.md)
-- `workflow.trackProgress` - Whether tracking is enabled
-- `workflow.updateOnCompletion` - Whether to auto-update on task completion
-
-If tracking is disabled, inform user and exit.
-
-### 1. Verify Plan Exists
-
-[[LLM: Check if workflow plan exists at configured location]]
-
-If no plan exists:
-
-```
-No active workflow plan found at {location}.
-Would you like to create one? Use *plan command.
-```
-
-### 2. Determine Update Type
-
-[[LLM: Ask user what type of update they want to make]]
-
-Present options:
-
-```
-What would you like to update in the workflow plan?
-
-1. Mark step as complete
-2. Update current step
-3. Add deviation note
-4. Mark decision point resolution
-5. Update overall status
-6. View current plan status only
-
-Please select an option (1-6):
-```
-
-### 3. Parse Current Plan
-
-[[LLM: Read and parse the plan to understand current state]]
-
-Extract:
-
-- All steps with their checkbox status
-- Step IDs from comments (if present)
-- Current completion percentage
-- Any existing deviation notes
-- Decision points and their status
-
-### 4. Execute Updates
-
-#### 4.1 Mark Step Complete
-
-If user selected option 1:
-
-1. Show numbered list of incomplete steps
-2. Ask which step to mark complete
-3. Update the checkbox from `[ ]` to `[x]`
-4. Add completion timestamp: `<!-- completed: YYYY-MM-DD HH:MM -->`
-5. If this was the current step, identify next step
-
-#### 4.2 Update Current Step
-
-If user selected option 2:
-
-1. Show all steps with current status
-2. Ask which step is now current
-3. Add/move `<!-- current-step -->` marker
-4. Optionally add note about why sequence changed
-
-#### 4.3 Add Deviation Note
-
-If user selected option 3:
-
-1. Ask for deviation description
-2. Ask which step this relates to (or general)
-3. Insert note in appropriate location:
-
-```markdown
-> **Deviation Note** (YYYY-MM-DD): {user_note}
-> Related to: Step X.Y or General workflow
-```
-
-#### 4.4 Mark Decision Resolution
-
-If user selected option 4:
-
-1. Show pending decision points
-2. Ask which decision was made
-3. Record the decision and chosen path
-4. Update related steps based on decision
-
-#### 4.5 Update Overall Status
-
-If user selected option 5:
-
-1. Show current overall status
-2. Provide options:
-   - Active (continuing with plan)
-   - Paused (temporarily stopped)
-   - Abandoned (no longer following)
-   - Complete (all steps done)
-3. Update plan header with new status
-
-### 5. Automatic Updates (When Called by Tasks)
-
-[[LLM: When called automatically by another task]]
-
-If called with parameters:
-
-```
-task: {task_name}
-step_id: {step_identifier}
-status: complete|skipped|failed
-note: {optional_note}
-```
-
-Automatically:
-
-1. Find the corresponding step
-2. Update its status
-3. Add completion metadata
-4. Add note if provided
-5. Calculate new progress percentage
-
-### 6. Generate Update Summary
-
-After updates, show summary:
-
-```
-✅ Workflow Plan Updated
-
-Changes made:
-- {change_1}
-- {change_2}
-
-New Status:
-- Progress: {X}% complete ({completed}/{total} steps)
-- Current Step: {current_step}
-- Next Recommended: {next_step}
-
-Plan location: {file_path}
-```
-
-### 7. Integration with Other Tasks
-
-[[LLM: How other tasks should call this]]
-
-Other tasks can integrate by:
-
-1. **After Task Completion**:
-
-```
-At end of task execution:
-- Check if task corresponds to a plan step
-- If yes, call update-workflow-plan with:
-  - task: {current_task_name}
-  - step_id: {matching_step}
-  - status: complete
-```
-
-2. **On Task Failure**:
-
-```
-If task fails:
-- Call update-workflow-plan with:
-  - task: {current_task_name}
-  - status: failed
-  - note: {failure_reason}
-```
-
-### 8. Plan Status Display
-
-[[LLM: When user selects view status only]]
-
-Display comprehensive status:
-
-```markdown
-📋 Workflow Plan Status
-━━━━━━━━━━━━━━━━━━━━
-Workflow: {workflow_name}
-Status: {Active|Paused|Complete}
-Progress: {X}% complete ({completed}/{total} steps)
-Last Updated: {timestamp}
-
-✅ Completed Steps:
-- [x] Step 1.1: {description} (completed: {date})
-- [x] Step 1.2: {description} (completed: {date})
-
-🔄 Current Step:
-- [ ] Step 2.1: {description} <!-- current-step -->
-  Agent: {agent_name}
-  Task: {task_name}
-
-📌 Upcoming Steps:
-- [ ] Step 2.2: {description}
-- [ ] Step 3.1: {description}
-
-⚠️ Deviations/Notes:
-{any_deviation_notes}
-
-📊 Decision Points:
-- Decision 1: {status} - {choice_made}
-- Decision 2: Pending
-
-💡 Next Action:
-Based on the plan, you should {recommended_action}
-```
-
-## Success Criteria
-
-The update is successful when:
-
-1. Plan accurately reflects current workflow state
-2. All updates are clearly timestamped
-3. Deviations are documented with reasons
-4. Progress calculation is correct
-5. Next steps are clear to user
-6. Plan remains readable and well-formatted
-
-## Error Handling
-
-- **Plan file not found**: Offer to create new plan
-- **Malformed plan**: Attempt basic updates, warn user
-- **Write permission error**: Show changes that would be made
-- **Step not found**: Show available steps, ask for clarification
-- **Concurrent updates**: Implement simple locking or warn about conflicts
-
-## Notes
-
-- Always preserve plan history (don't delete old information)
-- Keep updates atomic to prevent corruption
-- Consider creating backup before major updates
-- Updates should enhance, not complicate, the workflow experience
-- If plan becomes too cluttered, suggest creating fresh plan for next phase

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

@@ -1,134 +0,0 @@
-# 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 `.bmad-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**: `bmad-core/templates/story-tmpl.md` for completeness validation
-
-### 1. Template Completeness Validation
-
-- Load `bmad-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