- 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.3 KiB
5.3 KiB
name, description, nextStepFile
| name | description | nextStepFile |
|---|---|---|
| step-04-implement | Implement changes incrementally, verifying at each step | ./step-05-verify-and-document.md |
Step 4: Implement
STEP GOAL:
Implement changes incrementally, verifying at each step.
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 implementing each planned commit, testing after each, and ensuring backward compatibility
- 🚫 FORBIDDEN to skip verification points or proceed with broken tests
- 💬 Approach: Execute each planned step methodically — implement, self-check, test, commit
- 📋 Backward compatibility must be verified at every commit
EXECUTION PROTOCOLS:
- 🎯 All planned steps implemented with passing tests and backward compatibility
- 💾 Update dialog file with implementation progress after each commit
- 📖 Reference the implementation plan from Step 3 and verification points
- 🚫 Do not proceed to next commit if current one is broken
CONTEXT BOUNDARIES:
- Available context: Scope from Step 1; risks from Step 2; implementation plan from Step 3
- Focus: Incremental implementation following the plan
- Limits: Only implement what is in the plan — no scope creep
- Dependencies: Step 3 must be complete (plan exists)
Sequence of Instructions (Do not deviate, skip, or optimize)
1. Create Feature Branch
- Branch from the current working branch
- Use a descriptive name:
feature/<short-description>orevolve/<feature-name> - Commit the branch before making changes
2. Implement Incrementally Per Plan
For each planned commit:
- Read the plan — What does this step require?
- Implement — Write the code for this step only
- Self-check — Does this change stay within its planned scope?
- Test — Run relevant tests, verify the step works
- Commit — Clean commit with descriptive message
3. Test After Each Step
- Run the verification point defined in Step 03
- If automated tests exist, run them after each commit
- If modifying existing features, verify they still work (baseline comparison)
- Do not proceed to the next step if the current one is broken
4. Ensure Backward Compatibility at Each Commit
At every commit, ask:
- Does the existing functionality still work?
- Can an existing user do everything they could before?
- Are any existing API consumers affected?
- If a commit breaks backward compatibility, either fix it or add a feature flag
5. Use Feature Flags if Needed
When the plan calls for feature flags:
- Implement the flag check early (before building the feature behind it)
- Default to "off" — new feature is hidden until explicitly enabled
- Ensure the "off" path is identical to the pre-change behavior
- Test both flag states: on (new behavior) and off (old behavior)
6. Verify Checklist
- Feature branch created
- Each planned step implemented and committed separately
- Tests pass after each commit
- Backward compatibility verified at each commit
- Feature flags implemented correctly (if applicable)
- Dialog file updated with implementation progress
7. Present MENU OPTIONS
Display: "Select an Option: [C] Continue to Step 5: Verify and 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 planned steps are implemented, tested, and committed with backward compatibility verified will you then load and read fully {nextStepFile} to execute.
🚨 SYSTEM SUCCESS/FAILURE METRICS
✅ SUCCESS:
- Feature branch created
- Each planned step implemented and committed separately
- Tests pass after each commit
- Backward compatibility verified at each commit
- Feature flags implemented correctly (if applicable)
- Dialog file updated with implementation progress
❌ SYSTEM FAILURE:
- Proceeding to next step with broken tests
- Not verifying backward compatibility
- Implementing outside the planned scope
- Not testing feature flag on/off states
Master Rule: Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.