Implement the minimal functionality necessary to make BDD scenario tests pass. Focus on delivering complete user experiences that match business requirements.
- Failing integration tests from Red Phase
- BDD scenarios with acceptance criteria and edge cases
- Existing system architecture (entry points, data flow, system boundaries)
- Feature interfaces that need implementation
- Persistence contracts that need implementation
- State management patterns used in the system
- Identify broken user journey: Which user experience is incomplete?
- Determine missing functionality: What prevents user success?
- Map to system architecture: Which layers/modules need implementation?
- Prioritize by user impact: Focus on core user value first
- User interaction layer: Entry points, interfaces, user touchpoints
- Critical state management: Data that drives user experience
- Data persistence: State that must survive system sessions
- Business rules enforcement: Requirements from acceptance criteria
- System integration points: Where modules connect to complete flows
- Error handling: Graceful failures that don't break user experience
// Follow the user path through your system
// 1. Entry point (where users start)
// 2. State management (what drives user experience)
// 3. Persistence layer (what survives sessions)
// 4. Module integration (connecting system pieces)
// 5. Business logic (enforcing requirements)
- Follow the user path: Implement in the order users experience it
- Implement complete flows: Don't leave partial user journeys
- Handle state persistence: Critical for user experience continuity
- Enforce business rules: Requirements from acceptance criteria
- Keep it simple: Minimal code to satisfy user requirements
- Test frequently: Run integration tests after each implementation step
- Run integration tests: After each implementation step
- Verify complete user journey: User can finish the entire flow
- Test state persistence: Critical data survives system restarts
- Validate business rules: Requirements are properly enforced
- Check edge cases: Handle scenarios from BDD edge cases
- Manual verification: Actually use the feature as intended
- User can initiate the journey (entry point works)
- User can progress through the flow (transitions work)
- User can complete the journey (success state reached)
- Critical state persists across system sessions
- Business rules are enforced
- Error cases are handled gracefully
- Integration test passes
- Manual user verification confirms experience
- KISS: Keep implementation simple and focused on user value
- DRY: Extract reusable patterns, but don't over-engineer
- YAGNI: Only implement what's needed for current user scenarios
- Single Responsibility: Each module has a clear user-facing purpose
- Testable: Code supports the integration tests you've written
- β All BDD scenario integration tests pass
- β Users can complete journeys described in scenarios
- β Critical user state persists across system sessions
- β Business rules from acceptance criteria are enforced
- β User experience is smooth and intuitive
- β Edge cases from BDD scenarios are handled
- β No technical debt that impacts user experience
- β Manual testing confirms the feature works as intended
- β Implementing technical features that don't serve user needs
- β Over-engineering solutions beyond BDD requirements
- β Ignoring state persistence requirements
- β Implementing partial user flows
- β Focusing on making tests pass without considering user experience
- β Adding complexity that doesn't match BDD scenarios
- β Skipping manual verification of user experience
- Integration tests pass: All BDD scenarios work
- Manual user testing: Actually use the feature
- State persistence testing: Restart system, verify state
- Business rule validation: Requirements are enforced
- Edge case verification: Handle error scenarios gracefully
- User experience review: Flow feels natural and intuitive