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>
2026-03-19 13:29:03 -04:00
parent c5b377e788
commit 647cbec54f
3246 changed files with 479789 additions and 983 deletions
--- a/_bmad/wds/workflows/8-product-evolution/steps-p/step-01-create-delivery.md
+++ b/_bmad/wds/workflows/8-product-evolution/steps-p/step-01-create-delivery.md
@@ -0,0 +1,308 @@
+---
+name: 'step-01-create-delivery'
+description: 'Package incremental improvement as Design Delivery (DD-XXX)'
+
+# File References
+nextStepFile: './step-02-hand-off.md'
+
+# Data References
+deliveryTemplates: '../data/delivery-templates.md'
+---
+
+# Step 4: Create Design Delivery
+
+## STEP GOAL:
+
+Package your incremental improvement as a Design Delivery (DD-XXX) for BMad - using the same format as complete flows, but with focused scope and content.
+
+## 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 Freya, a product evolution specialist guiding continuous improvement
+- ✅ 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 delivery packaging expertise, user brings design work
+- ✅ Maintain organized and detail-oriented tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on packaging existing design work into delivery format
+- 🚫 FORBIDDEN to design new features or expand scope
+- 💬 Approach: Help user organize artifacts, reference specifications, define acceptance criteria
+- 📋 Ensure all artifacts are created and linked before packaging
+- 📋 Define clear success metrics and rollback criteria
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Guide user to create DD file following template exactly
+- 💾 Help user create matching test scenario (TS-XXX)
+- 📖 Reference templates from {deliveryTemplates} for both deliverables
+- 🚫 Do not allow vague descriptions or missing artifacts
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Completed step 03 (update designed), specifications created, change scope documented, before/after comparison ready
+- Focus: Packaging design work, creating delivery file, creating test scenario
+- Limits: Do not design new features, do not modify scope, do not skip metrics
+- Dependencies: Requires completed step 03, update specifications, change scope, before/after comparison, all artifacts ready
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Design Delivery Format Overview
+
+**Explain to user:**
+
+All design work uses Design Deliveries (DD-XXX), whether it's:
+- ✅ Complete new user flows (large scope)
+- ✅ Incremental improvements (small scope)
+
+**The format is the same - only the scope and content differ!**
+
+| Scope | Description | Effort |
+|-------|-------------|--------|
+| **Large** (New Flows) | Multiple scenarios, complete user flow | Weeks |
+| **Small** (Improvements) | Targeted changes, focused improvement | Days |
+
+**User is creating a small scope delivery.**
+
+### 2. Create Design Delivery File
+
+**File:** `deliveries/DD-XXX-description.yaml`
+
+**Numbering:** Ask user for last DD number, continue from there (use leading zeros: DD-001, DD-002, etc.)
+
+**Reference:** Use Design Delivery (Small Scope) template from {deliveryTemplates}
+
+Guide user through each section:
+
+#### 2a. Delivery Metadata
+
+```yaml
+delivery:
+  id: 'DD-XXX'
+  name: '[Short descriptive name]'
+  type: 'incremental_improvement'
+  scope: 'update'
+  version: 'v2.0'
+  previous_version: 'v1.0'
+  created_at: '[timestamp]'
+  designer: '[User name]'
+  status: 'ready_for_handoff'
+```
+
+#### 2b. Improvement Section
+
+Help user write:
+- **summary**: 2-3 sentences (what's changing and why)
+- **problem**: What problem does this solve? (with metrics)
+- **solution**: What's the solution? (specific changes)
+- **expected_impact**: What will improve? (with target metrics)
+
+#### 2c. Changes Section
+
+Guide user to specify:
+- **screens_affected**: List screens
+- **features_affected**: List features
+- **components_new**: New components with IDs and file paths
+- **components_modified**: Modified components with changes and file paths
+- **components_unchanged**: "All other components remain as-is"
+- **what_stays_same**: List unchanged elements
+
+#### 2d. Design Artifacts Section
+
+Help user link all artifacts:
+- **specifications**: Path to specifications.md
+- **change-scope**: Path to change-scope.md
+- **before-after**: Path to before-after.md
+- **components**: Paths to new/modified component files
+
+**Verify:** All files exist at specified paths.
+
+#### 2e. Technical Requirements Section
+
+Guide user to document:
+- **frontend**: List frontend implementation tasks
+- **backend**: List backend changes (if any)
+- **data**: List data model changes (if any)
+- **integrations**: List integration changes (analytics, etc.)
+
+#### 2f. Acceptance Criteria Section
+
+Help user define testable criteria:
+- Each criterion has: id (AC-001, AC-002...), description, verification method
+- Criteria must be objective and testable
+- Cover new functionality, edge cases, persistence
+
+#### 2g. Metrics Section
+
+Guide user to specify:
+- **baseline**: Current metrics with targets
+- **measurement_period**: Typically "2 weeks after release"
+- **success_threshold**: Minimum acceptable improvements
+- **rollback_criteria**: When to rollback if targets not met
+
+**Critical:** Ensure targets are realistic and measurable.
+
+#### 2h. Effort Estimate Section
+
+Help user estimate:
+- Design (already done)
+- Frontend implementation
+- Backend implementation (if any)
+- Testing
+- Total effort and complexity (Low/Medium/High)
+
+#### 2i. Timeline Section
+
+Work with user to define:
+- design_complete (today)
+- handoff_date (today or soon)
+- development_start (estimated)
+- development_complete (estimated)
+- testing_complete (estimated)
+- release_date (target)
+- measurement_end (release + 2 weeks)
+
+#### 2j. Handoff Section
+
+Specify:
+- architect: BMad Architect name
+- developer: BMad Developer name
+- handoff_dialog_required: false (for small updates)
+- notes: Brief note about scope
+
+#### 2k. Related Section
+
+Link related files:
+- improvement_file (from step 01)
+- analytics_report (if exists)
+- user_feedback (if exists)
+- original_delivery (if this is update to previous DD)
+
+### 3. Create Test Scenario
+
+**File:** `test-scenarios/TS-XXX-description.yaml`
+
+**Use same XXX number as DD-XXX.**
+
+**Reference:** Use Test Scenario (Incremental Improvement) template from {deliveryTemplates}
+
+Guide user to create:
+
+#### 3a. Test Metadata
+
+```yaml
+test_scenario:
+  id: 'TS-XXX'
+  name: '[Update Name] Validation'
+  type: 'incremental_improvement'
+  delivery_id: 'DD-XXX'
+  created_at: '[timestamp]'
+```
+
+#### 3b. Test Focus
+
+List key focus areas:
+- New functionality (what changed)
+- Regression testing (what should stay the same)
+- Edge cases specific to update
+- Accessibility
+
+#### 3c. Happy Path Tests
+
+Define tests for new functionality:
+- Each test has: id (HP-001, HP-002...), name, steps
+- Steps have: action, expected result
+- Cover the primary user flow through new feature
+
+#### 3d. Regression Tests
+
+Define tests for existing functionality:
+- Each test has: id (REG-001, REG-002...), name, steps
+- Verify existing features work exactly as before
+- Focus on areas adjacent to changes
+
+#### 3e. Edge Cases
+
+Define edge case tests:
+- Each test has: id (EC-001, EC-002...), name, steps
+- Cover unusual scenarios (dismissal persistence, multiple devices, cleared cache, etc.)
+
+#### 3f. Accessibility
+
+Define accessibility checks:
+- Each test has: id (A11Y-001, A11Y-002...), name, checks
+- Screen reader compatibility
+- Keyboard navigation
+- Focus management
+
+### 4. Review and Verify
+
+**Before proceeding, verify with user:**
+
+- [ ] DD file created with all sections complete
+- [ ] All artifact paths valid and files exist
+- [ ] Acceptance criteria are testable and objective
+- [ ] Metrics and targets are realistic
+- [ ] Success and rollback criteria defined
+- [ ] Test scenario created with all test types
+- [ ] TS file references correct DD-XXX
+- [ ] No vague descriptions or missing information
+
+**All must be checked before proceeding.**
+
+### 5. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to step-02-hand-off.md (next step in this activity)"
+
+#### 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 user selects [C] and delivery packaging is complete will you then load and read fully `{nextStepFile}` to execute and begin step 02 (hand off to BMad).
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Design Delivery file (DD-XXX) created following template exactly
+- All sections complete with no placeholders
+- Change scope clearly defined in delivery
+- All artifacts referenced with valid file paths
+- Acceptance criteria defined and testable
+- Metrics with baseline, targets, success threshold, and rollback criteria
+- Test scenario (TS-XXX) created with all test types
+- Happy path, regression, edge case, and accessibility tests defined
+- Effort estimate and timeline realistic
+- Ready for handoff to BMad
+
+### ❌ SYSTEM FAILURE:
+- Vague change description or missing sections
+- Missing artifacts or broken file paths
+- No success metrics or rollback criteria defined
+- Scope too large (not incremental improvement)
+- No before/after comparison referenced
+- Acceptance criteria not testable or missing
+- Test scenario missing or incomplete
+- No regression tests defined
+- Generating content without user input
+- Skipping verification checklist
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
--- a/_bmad/wds/workflows/8-product-evolution/steps-p/step-02-hand-off.md
+++ b/_bmad/wds/workflows/8-product-evolution/steps-p/step-02-hand-off.md
@@ -0,0 +1,244 @@
+---
+name: 'step-02-hand-off'
+description: 'Hand off Design Delivery to BMad for implementation'
+
+# File References
+workflowFile: '../workflow.md'
+activityWorkflowFile: '../workflow-deploy.md'
+---
+
+# Step 5: Hand Off to BMad
+
+## STEP GOAL:
+
+Hand off the Design Delivery (small scope) to BMad Developer for implementation - using simplified handoff for small updates or full dialog for larger ones.
+
+## 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 Freya, a product evolution specialist guiding continuous improvement
+- ✅ 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 handoff process expertise, user brings design delivery
+- ✅ Maintain clear and professional tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on clear handoff communication to BMad
+- 🚫 FORBIDDEN to modify design or add new requirements
+- 💬 Approach: Help user compose clear handoff message, ensure BMad has everything needed
+- 📋 Choose appropriate handoff method based on effort estimate
+- 📋 Update delivery status after handoff
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Guide user to choose handoff method (simplified vs full dialog)
+- 💾 Help user compose handoff notification with all necessary information
+- 📖 Update delivery status in DD file after handoff
+- 🚫 Do not allow handoff without all artifacts ready
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Completed step 04 (Design Delivery created), all artifacts ready, test scenario created
+- Focus: Handoff communication, status update
+- Limits: Do not modify design, do not add requirements, do not skip status update
+- Dependencies: Requires completed step 04, DD file created, TS file created, all artifacts ready
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Determine Handoff Method
+
+**Ask user about effort estimate:**
+
+Review the effort estimate in DD-XXX file:
+- **< 3 days total effort**: Use simplified handoff
+- **> 3 days total effort**: Use full handoff dialog
+
+Guide user to appropriate section below.
+
+### 2. Simplified Handoff (< 3 Days)
+
+**For small, focused updates:**
+
+Help user compose handoff notification:
+
+```
+WDS Designer → BMad Developer
+
+Subject: Design Delivery Ready: DD-XXX [Name]
+
+Hi Developer!
+
+Design Delivery ready for implementation.
+
+📦 **Delivery:** DD-XXX [Name]
+**Type:** Incremental Improvement
+**Scope:** Update (small)
+**Effort:** [X] days
+**Priority:** [High | Medium | Low]
+
+🎯 **Goal:**
+[One sentence describing the improvement]
+
+Example:
+"Add inline onboarding to Feature X to increase usage from 15% to 60%."
+
+📊 **Current Problem:**
+- [Metric 1]: [Current value]
+- [Metric 2]: [Current value]
+
+📈 **Expected Impact:**
+- [Metric 1]: [Current] → [Target]
+- [Metric 2]: [Current] → [Target]
+
+📁 **Artifacts:**
+- Design Delivery: deliveries/DD-XXX-name.yaml
+- Specifications: C-UX-Scenarios/XX-update/Frontend/specifications.md
+- Before/After: C-UX-Scenarios/XX-update/before-after.md
+- Components: D-Design-System/03-Atomic-Components/...
+- Test Scenario: test-scenarios/TS-XXX.yaml
+
+✅ **Acceptance Criteria:**
+- AC-001: [Description]
+- AC-002: [Description]
+- AC-003: [Description]
+
+⏱️ **Timeline:**
+- Development: [X] days
+- Target release: [Date]
+- Measurement: 2 weeks after release
+
+❓ **Questions:**
+Let me know if you need clarification on anything!
+
+Thanks,
+[Your name]
+WDS Designer
+```
+
+**Work with user to fill in all bracketed values from DD file.**
+
+### 3. Full Handoff Dialog (> 3 Days)
+
+**For larger updates:**
+
+Explain to user:
+
+"For larger updates (> 3 days effort), use full handoff dialog process from Phase 4 [H] Handover, Step 04."
+
+**Key topics to cover in dialog:**
+1. Problem and solution overview
+2. What's changing vs staying
+3. Technical requirements
+4. Component specifications
+5. Acceptance criteria
+6. Success metrics
+7. Rollback criteria
+
+**Note:** This is less common for Product Evolution workflow - most improvements are small scope.
+
+### 4. BMad Acknowledges
+
+**Help user understand expected response:**
+
+BMad Developer should respond with:
+
+```
+BMad Developer → WDS Designer
+
+Subject: Re: Design Delivery Ready: DD-XXX
+
+Received! Thank you.
+
+📋 **My Plan:**
+1. Review specifications ([date])
+2. Implement changes ([date])
+3. Run tests ([date])
+4. Notify for validation ([date])
+
+⏱️ **Estimated Completion:** [Date]
+
+❓ **Questions:**
+[Any clarification needed]
+
+Thanks!
+BMad Developer
+```
+
+**If user receives this acknowledgment, proceed to next step.**
+
+**If BMad has questions, help user answer them clearly.**
+
+### 5. Update Delivery Status
+
+**Update the DD-XXX file:**
+
+Help user modify the delivery status section:
+
+```yaml
+delivery:
+  status: 'in_development' # Changed from "ready_for_handoff"
+  handed_off_at: '[timestamp]'
+  developer: '[BMad Developer name]'
+  development_start: '[timestamp or estimate]'
+  expected_completion: '[timestamp or estimate]'
+```
+
+**Verify:** Status updated correctly in DD file.
+
+### 6. Present MENU OPTIONS
+
+Display: "**Select an Option:** [M] Return to Activity Menu (suggest [T] Acceptance Test)"
+
+#### Menu Handling Logic:
+- IF M: Return to {workflowFile} or {activityWorkflowFile}
+- 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
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN user selects [M] and handoff is complete will you then return to the activity workflow to suggest next step [T] Acceptance Test (after BMad completes implementation).
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Handoff notification composed with all required information
+- Appropriate handoff method chosen (simplified vs full dialog)
+- All artifacts referenced in handoff message
+- Goal, problem, expected impact clearly stated
+- Acceptance criteria included in notification
+- Timeline and effort estimate communicated
+- BMad Developer acknowledged receipt
+- Questions from BMad answered clearly (if any)
+- Delivery status updated to 'in_development'
+- handed_off_at timestamp recorded
+- Developer name and expected completion date recorded
+- User available for clarification questions during development
+
+### ❌ SYSTEM FAILURE:
+- Handoff without all artifacts ready
+- Vague or incomplete handoff message
+- Missing acceptance criteria or metrics
+- No timeline or effort estimate
+- Delivery status not updated after handoff
+- Not responding to BMad's questions
+- Adding new requirements during handoff (scope creep)
+- Modifying design after handoff without updating DD file
+- Generating handoff message without user input
+- Not recording developer name or timeline
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.