- Rewrite README.md with current architecture, features and stack - Update docs/API.md with all current endpoints (corporate, BI, client 360) - Update docs/ARCHITECTURE.md with cache, modular queries, services, ETL - Update docs/GUIA-USUARIO.md for all roles (admin, corporate, agente) - Add docs/INDEX.md documentation index - Add PROJETO.md comprehensive project reference - Add BI-CCC-Implementation-Guide.md - Include AI agent configs (.claude, .agents, .gemini, _bmad) - Add netbird VPN configuration - Add status report Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
5.4 KiB
5.4 KiB
name, description, nextStepFile
| name | description | nextStepFile |
|---|---|---|
| step-03-plan-implementation | Create an ordered, incremental implementation plan with verification points | ./step-04-implement.md |
Step 3: Plan Implementation
STEP GOAL:
Create an ordered, incremental implementation plan with verification points.
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 ordering changes, planning incremental commits, defining verification points, and estimating effort
- 🚫 FORBIDDEN to begin writing code — that is the next step
- 💬 Approach: Collaboratively sequence the implementation with user, ensuring each step leaves the system working
- 📋 Each commit must be a complete, working unit with clear verification criteria
EXECUTION PROTOCOLS:
- 🎯 Produce a sequenced implementation plan with verification points between steps
- 💾 Write implementation plan to the dialog file
- 📖 Reference the scope from Step 1 and risk assessment from Step 2
- 🚫 Do not write any code during this step
CONTEXT BOUNDARIES:
- Available context: Scope and boundary map from Step 1; impact analysis and risks from Step 2
- Focus: Implementation planning — order, commits, verification, feature flags
- Limits: No code writing
- Dependencies: Steps 1 and 2 must be complete
Sequence of Instructions (Do not deviate, skip, or optimize)
1. Order Changes by Dependency
- Start with foundational changes (data models, utilities, shared logic)
- Then build upward: API endpoints, components, pages, integrations
- Each step should build on the previous one
- No step should depend on a later step
2. Determine If Feature Flags Are Needed
Use feature flags when:
- The change is large enough that partial deployment is risky
- The feature needs to be toggled per environment or per user
- Rollback needs to be instant (without redeploying)
If not needed, keep it simple — branches and PRs are sufficient.
3. Plan Incremental Commits
Each commit should:
- Be a complete, working unit (system stays functional after each commit)
- Be small enough to review and understand
- Have a clear purpose described in its message
Example plan structure:
Commit 1: Add new data model (no UI, no routes)
Commit 2: Add API endpoint for new feature (behind feature flag)
Commit 3: Add new component (rendered only in new context)
Commit 4: Integrate component into existing page
Commit 5: Enable feature, update tests
4. Define Verification Points
Between steps, define what to check:
- After commit 1: "Run migrations, verify existing queries still work"
- After commit 3: "Render component in isolation, verify it matches spec"
- After commit 4: "Full regression on existing page, verify new feature appears"
5. Estimate Effort
- Note which steps are straightforward vs which carry risk
- Identify steps that may need designer/stakeholder input
- Flag any steps that might require splitting into sub-steps
6. Verify Checklist
- Changes ordered by dependency
- Feature flag decision made and documented
- Incremental commits planned (each leaves system working)
- Verification points defined between steps
- Effort estimated, risks flagged
- Implementation plan written to dialog file
7. Present MENU OPTIONS
Display: "Select an Option: [C] Continue to Step 4: Implement"
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 implementation plan is complete with ordered steps, verification points, and feature flag decisions will you then load and read fully {nextStepFile} to execute.
🚨 SYSTEM SUCCESS/FAILURE METRICS
✅ SUCCESS:
- Changes ordered by dependency
- Feature flag decision made and documented
- Incremental commits planned (each leaves system working)
- Verification points defined between steps
- Effort estimated, risks flagged
- Implementation plan written to dialog file
❌ SYSTEM FAILURE:
- Beginning implementation without a complete plan
- Planning commits that leave the system in a broken state
- Not defining verification points
- Skipping feature flag assessment
Master Rule: Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.