initial commit
This commit is contained in:
@@ -0,0 +1,136 @@
|
||||
---
|
||||
name: 'step-01-reproduce'
|
||||
description: 'Confirm the bug exists and document exact reproduction steps'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-02-investigate.md'
|
||||
---
|
||||
|
||||
# Step 1: Reproduce
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Confirm the bug exists and document exact reproduction steps.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on gathering bug report details, setting up reproduction environment, and reproducing the bug
|
||||
- 🚫 FORBIDDEN to begin investigating root cause or implementing fixes — those are later steps
|
||||
- 💬 Approach: Methodically reproduce the issue with user, documenting every step and observation
|
||||
- 📋 Bug must be reproduced at least twice before proceeding; if non-reproducible, follow the non-reproducible protocol
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Confirm the bug exists with documented, repeatable reproduction steps
|
||||
- 💾 Update dialog file with reproduction details, screenshots/logs
|
||||
- 📖 Reference the bug report or user description
|
||||
- 🚫 Do not investigate code or attempt fixes during this step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Bug report or user description of the issue
|
||||
- Focus: Reproduction — confirming the bug exists and documenting how to trigger it
|
||||
- Limits: No code investigation, no fix attempts
|
||||
- Dependencies: A bug report or description must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Gather Bug Report Details
|
||||
|
||||
- Read the bug report or user description
|
||||
- Extract: what happened, what was expected, when it started
|
||||
- Note the reporter's environment (browser, device, OS, screen size)
|
||||
- Identify any relevant user actions leading up to the bug
|
||||
|
||||
### 2. Set Up Reproduction Environment
|
||||
|
||||
- Match the reporter's environment as closely as possible
|
||||
- Use the same browser, viewport, and device settings
|
||||
- Ensure you are on the same version/branch of the code
|
||||
- Load any required test data or user state
|
||||
|
||||
### 3. Reproduce the Bug
|
||||
|
||||
- Follow the reported steps exactly, in order
|
||||
- Document each action and its result
|
||||
- Capture screenshots or logs at each step
|
||||
- Record the exact error messages, console output, or visual artifacts
|
||||
|
||||
### 4. Confirm Reproducibility
|
||||
|
||||
- Reproduce at least twice to confirm consistency
|
||||
- Note if the bug is intermittent (and under what conditions)
|
||||
- Test slight variations to understand the trigger boundaries
|
||||
|
||||
### 5. Handle Non-Reproducible Bugs
|
||||
|
||||
If the bug cannot be reproduced:
|
||||
- Request more details from the reporter (exact steps, screenshots, browser version)
|
||||
- Check if the bug is environment-specific (browser, OS, network)
|
||||
- Check if recent changes resolved it inadvertently
|
||||
- Document what was tried and what remains unknown
|
||||
- Do NOT proceed to investigation without reproduction or a clear theory
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Bug report details gathered and understood
|
||||
- [ ] Reproduction environment matches reporter's setup
|
||||
- [ ] Bug reproduced at least twice
|
||||
- [ ] Reproduction steps documented precisely
|
||||
- [ ] Screenshots/logs captured
|
||||
- [ ] Dialog file updated with reproduction details
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 2: Investigate"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN the bug has been reproduced and documented with exact steps will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Bug report details gathered and understood
|
||||
- Reproduction environment matches reporter's setup
|
||||
- Bug reproduced at least twice
|
||||
- Reproduction steps documented precisely
|
||||
- Screenshots/logs captured
|
||||
- Dialog file updated with reproduction details
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Proceeding to investigation without reproducing the bug
|
||||
- Attempting to fix the bug before understanding how to trigger it
|
||||
- Not documenting reproduction steps
|
||||
- Skipping environment setup
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
name: 'step-02-investigate'
|
||||
description: 'Identify the root cause of the bug, not just the symptom'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-03-fix.md'
|
||||
---
|
||||
|
||||
# Step 2: Investigate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Identify the root cause of the bug, not just the symptom.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on reading code, tracing execution path, identifying root cause, and checking wider impact
|
||||
- 🚫 FORBIDDEN to begin implementing a fix — that is the next step
|
||||
- 💬 Approach: Trace the execution path from trigger to symptom with user, distinguishing symptom from cause
|
||||
- 📋 Root cause must be pinpointed to specific line(s) or logic before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Identify the exact root cause with proposed fix approach
|
||||
- 💾 Document root cause, symptom explanation, affected areas, and proposed fix in dialog file
|
||||
- 📖 Reference reproduction steps from Step 1
|
||||
- 🚫 Do not write fix code during this step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Bug report and reproduction details from Step 1
|
||||
- Focus: Root cause investigation — code reading, execution tracing, impact assessment
|
||||
- Limits: No fix implementation
|
||||
- Dependencies: Step 1 must be complete (bug reproduced)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Read the Relevant Code
|
||||
|
||||
- Open the files related to the bug's location (component, module, route)
|
||||
- Read the code around the symptom — understand what it is supposed to do
|
||||
- Check recent commits for changes in the affected area (`git log --oneline -20 -- <file>`)
|
||||
|
||||
### 2. Trace the Execution Path
|
||||
|
||||
- Start from the user action that triggers the bug
|
||||
- Follow the code path: event handler, state update, render, API call
|
||||
- Identify where the actual behavior diverges from the expected behavior
|
||||
- Use console logs, breakpoints, or Puppeteer to observe intermediate state
|
||||
|
||||
### 3. Identify Root Cause
|
||||
|
||||
- Distinguish symptom from cause — the visible bug is rarely the root issue
|
||||
- Common root causes to check:
|
||||
- State not reset or updated correctly
|
||||
- Race condition or timing issue
|
||||
- Missing null/undefined check
|
||||
- Wrong data type or format
|
||||
- CSS specificity or inheritance conflict
|
||||
- API response changed or error not handled
|
||||
- Pin down the exact line(s) or logic that cause the failure
|
||||
|
||||
### 4. Check Wider Impact
|
||||
|
||||
- Does this code path affect other features?
|
||||
- Are there similar patterns elsewhere that might have the same bug?
|
||||
- Could the root cause indicate a systemic issue (e.g., missing error handling pattern)?
|
||||
|
||||
### 5. Document the Root Cause
|
||||
|
||||
- Write a clear, concise explanation in the dialog file:
|
||||
- What causes the bug (root cause)
|
||||
- Why it manifests the way it does (symptom explanation)
|
||||
- What areas are affected
|
||||
- Proposed fix approach
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Relevant code read and understood
|
||||
- [ ] Execution path traced from trigger to symptom
|
||||
- [ ] Root cause identified (not just symptom)
|
||||
- [ ] Wider impact assessed
|
||||
- [ ] Root cause documented in dialog file
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 3: Fix"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN the root cause is identified and documented with proposed fix approach will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Relevant code read and understood
|
||||
- Execution path traced from trigger to symptom
|
||||
- Root cause identified (not just symptom)
|
||||
- Wider impact assessed
|
||||
- Root cause documented in dialog file
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Beginning to fix without identifying root cause
|
||||
- Treating the symptom instead of the cause
|
||||
- Not checking wider impact
|
||||
- Not documenting the root cause
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
130
_bmad/wds/workflows/5-agentic-development/steps-f/step-03-fix.md
Normal file
130
_bmad/wds/workflows/5-agentic-development/steps-f/step-03-fix.md
Normal file
@@ -0,0 +1,130 @@
|
||||
---
|
||||
name: 'step-03-fix'
|
||||
description: 'Implement the minimal fix targeting the root cause'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-04-verify.md'
|
||||
---
|
||||
|
||||
# Step 3: Fix
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Implement the minimal fix targeting the root cause.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on writing a failing test, implementing the minimal fix, and verifying the reproduction case passes
|
||||
- 🚫 FORBIDDEN to refactor surrounding code, add unrelated improvements, or fix other issues noticed nearby
|
||||
- 💬 Approach: Write test first, then minimal fix, then verify — test-driven bugfixing
|
||||
- 📋 The fix must be the smallest change that resolves the root cause
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Bug fixed with minimal change, regression test written, reproduction case passes
|
||||
- 💾 Update dialog file with fix details
|
||||
- 📖 Reference root cause from Step 2 and reproduction steps from Step 1
|
||||
- 🚫 Do not include unrelated changes in the fix
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Reproduction details from Step 1; root cause and proposed fix from Step 2
|
||||
- Focus: Minimal fix targeting root cause with regression test
|
||||
- Limits: No refactoring, no unrelated improvements
|
||||
- Dependencies: Step 2 must be complete (root cause identified)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Create Fix Branch
|
||||
|
||||
- Create a branch from the current working branch
|
||||
- Use a descriptive name: `fix/<short-description>` or `bugfix/<issue-id>`
|
||||
- Commit the branch before making changes
|
||||
|
||||
### 2. Write a Test That Catches the Bug
|
||||
|
||||
- Before writing the fix, write a test that reproduces the bug
|
||||
- The test should fail in the current state (proving the bug exists)
|
||||
- This ensures the fix is verifiable and the bug cannot silently return
|
||||
- If automated testing is not set up, document the manual test steps clearly
|
||||
|
||||
### 3. Implement the Minimal Fix
|
||||
|
||||
- Target the root cause identified in Step 02
|
||||
- Make the smallest change that resolves the issue
|
||||
- Do NOT:
|
||||
- Refactor surrounding code
|
||||
- Add unrelated improvements
|
||||
- Change formatting or style in unrelated lines
|
||||
- "Fix" other issues you noticed nearby
|
||||
- If the fix requires more than a few lines, pause and verify scope
|
||||
|
||||
### 4. Verify the Fix Resolves the Reproduction Case
|
||||
|
||||
- Run the reproduction steps from Step 01
|
||||
- Confirm the bug no longer occurs
|
||||
- Run the test from sub-step 2 — it should now pass
|
||||
- If the fix does not resolve the bug, revisit Step 02
|
||||
|
||||
### 5. Verify Checklist
|
||||
|
||||
- [ ] Fix branch created
|
||||
- [ ] Test written that catches the bug (fails before fix, passes after)
|
||||
- [ ] Minimal fix implemented targeting root cause
|
||||
- [ ] No unrelated changes included
|
||||
- [ ] Reproduction case passes with the fix
|
||||
- [ ] Dialog file updated with fix details
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 4: Verify"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN the fix is implemented, test passes, and reproduction case is resolved will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Fix branch created
|
||||
- Test written that catches the bug (fails before fix, passes after)
|
||||
- Minimal fix implemented targeting root cause
|
||||
- No unrelated changes included
|
||||
- Reproduction case passes with the fix
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Implementing fix without writing a regression test first
|
||||
- Including refactoring or unrelated improvements
|
||||
- Fix does not target root cause (treats symptom only)
|
||||
- Proceeding without verifying reproduction case
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
name: 'step-04-verify'
|
||||
description: 'Confirm the fix works and has not introduced regressions'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-05-document.md'
|
||||
---
|
||||
|
||||
# Step 4: Verify
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Confirm the fix works and has not introduced regressions.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on re-running reproduction steps, running full regression, testing edge cases, verifying no side effects, and cross-platform checks
|
||||
- 🚫 FORBIDDEN to add new features or make additional code changes — only verify and fix regressions
|
||||
- 💬 Approach: Systematic verification with user, testing the fix and all adjacent functionality
|
||||
- 📋 Any regression must be fixed before proceeding to documentation
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Fix confirmed working with no regressions
|
||||
- 💾 Update dialog file with verification results
|
||||
- 📖 Reference reproduction steps from Step 1 and fix details from Step 3
|
||||
- 🚫 Do not add features or make non-fix changes
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Reproduction from Step 1; root cause from Step 2; fix from Step 3
|
||||
- Focus: Comprehensive verification — fix works, no regressions, no side effects
|
||||
- Limits: No feature additions, only regression fixes if needed
|
||||
- Dependencies: Step 3 must be complete (fix implemented)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Re-Run Reproduction Steps
|
||||
|
||||
- Follow the exact reproduction steps from Step 01
|
||||
- Confirm the bug is fully resolved (not partially or intermittently)
|
||||
- Test on the same environment used for reproduction
|
||||
|
||||
### 2. Run Full Regression Tests
|
||||
|
||||
- Run the project's test suite (unit tests, integration tests)
|
||||
- If no automated test suite exists, manually test the core user flows
|
||||
- Pay extra attention to features that share code with the fixed area
|
||||
|
||||
### 3. Check Edge Cases
|
||||
|
||||
- Test boundary conditions around the fix:
|
||||
- Empty/null/undefined inputs
|
||||
- Maximum/minimum values
|
||||
- Rapid repeated actions
|
||||
- Network errors or slow responses (if applicable)
|
||||
- Test the exact scenario that was broken, but with slight variations
|
||||
|
||||
### 4. Verify No Side Effects
|
||||
|
||||
- Check features that are adjacent to or depend on the fixed code
|
||||
- If the fix changed shared state, verify all consumers of that state
|
||||
- If the fix changed a utility function, verify all callers
|
||||
- Compare behavior with baseline (if captured)
|
||||
|
||||
### 5. Cross-Platform Check
|
||||
|
||||
- If the bug was platform-specific, verify the fix works on that platform
|
||||
- Also verify the fix does not break other platforms
|
||||
- Test on relevant viewport sizes if the bug was visual
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Reproduction steps pass — bug is fixed
|
||||
- [ ] Test suite passes (all tests green)
|
||||
- [ ] Edge cases tested around the fix
|
||||
- [ ] No side effects on related features
|
||||
- [ ] Cross-platform verification done (if applicable)
|
||||
- [ ] Dialog file updated with verification results
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 5: Document"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN all verification passes with no regressions will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Reproduction steps pass — bug is fixed
|
||||
- Test suite passes (all tests green)
|
||||
- Edge cases tested around the fix
|
||||
- No side effects on related features
|
||||
- Cross-platform verification done (if applicable)
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Not re-running reproduction steps
|
||||
- Skipping regression test suite
|
||||
- Not testing edge cases
|
||||
- Ignoring side effects on related features
|
||||
- Proceeding with failing tests
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
name: 'step-05-document'
|
||||
description: 'Document the bug, the fix, and create a clean PR'
|
||||
|
||||
# File References
|
||||
activityWorkflowFile: '../workflow-bugfixing.md'
|
||||
---
|
||||
|
||||
# Step 5: Document
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Document the bug, the fix, and create a clean PR.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on documenting root cause, fix approach, updating tests, creating PR, and flagging similar risks
|
||||
- 🚫 FORBIDDEN to add new features or make code changes beyond test cleanup
|
||||
- 💬 Approach: Collaborative documentation and PR creation with user
|
||||
- 📋 Flag similar risks elsewhere in the codebase for future investigation
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Complete bug documentation, PR created, similar risks flagged
|
||||
- 💾 Finalize dialog file with complete bugfix record
|
||||
- 📖 Reference all previous steps for comprehensive documentation
|
||||
- 🚫 Do not add features or make non-documentation changes
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Reproduction from Step 1; root cause from Step 2; fix from Step 3; verification from Step 4
|
||||
- Focus: Documentation, PR creation, risk flagging
|
||||
- Limits: No feature additions, no code changes beyond test cleanup
|
||||
- Dependencies: Step 4 must be complete (verification passed)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Document What Caused the Bug
|
||||
|
||||
- Write a clear root cause summary in the dialog file
|
||||
- Explain why the bug existed (design oversight, edge case, regression from another change)
|
||||
- Include the relevant code context — what was wrong and why
|
||||
|
||||
### 2. Document the Fix Approach
|
||||
|
||||
- Explain what was changed and why this approach was chosen
|
||||
- If alternative approaches were considered, note why they were rejected
|
||||
- Reference the specific files and lines changed
|
||||
|
||||
### 3. Update Tests
|
||||
|
||||
- Ensure the regression test from Step 03 is complete and well-named
|
||||
- Add any additional test cases discovered during verification
|
||||
- Verify all tests pass with the final fix
|
||||
|
||||
### 4. Create PR with Clear Description
|
||||
|
||||
- Write a PR title that summarizes the fix: `fix: <what was fixed>`
|
||||
- PR body should include:
|
||||
- **Bug:** What the user experienced
|
||||
- **Root cause:** Why it happened
|
||||
- **Fix:** What was changed
|
||||
- **Testing:** How it was verified
|
||||
- Link to the bug report or issue if one exists
|
||||
|
||||
### 5. Flag Similar Risks
|
||||
|
||||
- If the root cause suggests similar bugs may exist elsewhere, note this
|
||||
- Examples: "This pattern of unchecked null access also exists in X and Y"
|
||||
- Create follow-up issues or add notes to the dialog for future investigation
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Root cause documented
|
||||
- [ ] Fix approach documented
|
||||
- [ ] Tests updated and passing
|
||||
- [ ] PR created with clear description
|
||||
- [ ] Similar risks flagged (if any)
|
||||
- [ ] Dialog file finalized with complete bugfix record
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF M: Update design log, then load, read entire file, then execute {activityWorkflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed when user selects 'M'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN documentation is complete, PR is created, and similar risks are flagged will you then load and read fully `{activityWorkflowFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Root cause documented
|
||||
- Fix approach documented
|
||||
- Tests updated and passing
|
||||
- PR created with clear description
|
||||
- Similar risks flagged (if any)
|
||||
- Dialog file finalized with complete bugfix record
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Not documenting root cause
|
||||
- Creating PR without clear description
|
||||
- Not flagging similar risks
|
||||
- Not finalizing dialog file
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
Reference in New Issue
Block a user