calctext/_bmad/wds/workflows/5-agentic-development/steps-e/step-02-analyze-impact.md

name, description, nextStepFile

name	description	nextStepFile
step-02-analyze-impact	Understand how the proposed changes affect existing code and identify risks	./step-03-plan-implementation.md

Step 2: Analyze Impact

STEP GOAL:

Understand how the proposed changes affect existing code, and identify risks.

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 affected code, mapping dependencies, identifying breaking change risks, and assessing database/API impacts
• 🚫 FORBIDDEN to begin planning or implementing changes — that is a later step
• 💬 Approach: Deep dive into affected code with user, mapping what depends on what
• 📋 Document a risk assessment table with likelihood, impact, and mitigation

EXECUTION PROTOCOLS:

• 🎯 Produce a dependency map, breaking change risk list, and risk assessment
• 💾 Document risk assessment in the dialog file
• 📖 Reference the boundary map and integration points from Step 1
• 🚫 Do not plan implementation order or write any code

CONTEXT BOUNDARIES:

• Available context: Scope definition, boundary map, and integration points from Step 1
• Focus: Impact analysis — dependencies, risks, breaking changes
• Limits: No implementation planning, no code changes
• Dependencies: Step 1 must be complete (scope defined)

Sequence of Instructions (Do not deviate, skip, or optimize)

1. Read Code for All Affected Areas

• Open and read every file identified as "modified" in the boundary map
• Read files adjacent to integration points
• Understand the current behavior before planning changes

2. Map Dependencies

• For each modified file, identify:
  • What imports it / calls it / depends on it
  • What it imports / calls / depends on
• Build a dependency graph (mental or documented) of the affected area
• Flag shared utilities, components, or state that multiple features rely on

3. Identify Breaking Change Risks

• Will any existing interface signatures change?
• Will any existing data shapes change?
• Could new code paths affect timing or ordering of existing operations?
• Are there implicit assumptions in existing code that the new feature violates?

4. Assess Database/API Impacts

• Are database schema changes needed? (migrations, new tables, altered columns)
• Are API contract changes needed? (new endpoints, changed response shapes)
• Can changes be additive (non-breaking) or do they require migration?
• Will existing clients (other services, mobile apps) be affected?

5. Document What Could Go Wrong

Write a risk assessment in the dialog file:

Risk	Likelihood	Impact	Mitigation
Shared component breaks for existing use	Medium	High	Test all existing consumers
API change breaks mobile client	Low	High	Make change additive, not breaking
State management conflict	Medium	Medium	Isolate new state, feature flag

6. Verify Checklist

• All affected code read and understood
• Dependencies mapped
• Breaking change risks identified
• Database/API impacts assessed
• Risk assessment documented in dialog file

7. Present MENU OPTIONS

Display: "Select an Option: [C] Continue to Step 3: Plan Implementation"

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 impact analysis is complete with dependencies mapped and risks documented will you then load and read fully {nextStepFile} to execute.

---

🚨 SYSTEM SUCCESS/FAILURE METRICS

✅ SUCCESS:

• All affected code read and understood
• Dependencies mapped
• Breaking change risks identified
• Database/API impacts assessed
• Risk assessment documented in dialog file

❌ SYSTEM FAILURE:

• Beginning implementation planning without completing impact analysis
• Not reading all affected code
• Skipping dependency mapping
• Not documenting risks

Master Rule: Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.