docs: update all documentation and add AI tooling configs
- 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>
This commit is contained in:
@@ -0,0 +1,145 @@
|
||||
---
|
||||
name: 'step-03-plan-implementation'
|
||||
description: 'Create an ordered, incremental implementation plan with verification points'
|
||||
|
||||
# File References
|
||||
nextStepFile: './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.
|
||||
Reference in New Issue
Block a user