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>

_bmad/wds/workflows/5-agentic-development/workflow-development.md

@@ -0,0 +1,89 @@
+---
+name: development
+description: Write production code from approved specifications
+---
+
+# [D] Development — Write Production Code
+
+**Goal:** Write production-quality code from approved specifications using structured agent collaboration.
+
+**When to use:**
+- An approved specification exists (page spec, feature spec, or component spec)
+- Prototype has been validated (if prototyping was part of the process)
+- The codebase and tech stack are established (this is NOT for greenfield project setup)
+- You need to turn a spec into committed, tested, production-ready code
+
+**When NOT to use:**
+- No approved spec exists yet — use [A] Analysis or spec writing first
+- You need to explore or understand an existing codebase — use [R] Reverse Engineering
+- You are fixing a bug in existing code — use [F] Bugfixing
+- You need a throwaway prototype to validate ideas — use [P] Prototyping
+
+---
+
+## CORE PRINCIPLES
+
+1. **Spec-driven.** The approved specification is the source of truth. Every implementation decision traces back to the spec. If the spec is ambiguous, clarify before coding — do not guess.
+
+2. **Incremental.** Implement one feature or component at a time. Commit after each meaningful unit of work. Never let uncommitted changes grow large.
+
+3. **Test as you go.** Run tests after each significant change. Do not batch all testing to the end. A failing test discovered early is cheap; discovered late it is expensive.
+
+4. **Follow existing patterns.** Match the codebase's conventions for file structure, naming, styling, state management, and error handling. Consistency with the existing code matters more than personal preference.
+
+5. **Document deviations.** If you must deviate from the spec (technical constraint, discovered issue), document what you changed and why before moving on.
+
+---
+
+## REFERENCE MATERIAL
+
+Guides in `./data/guides/` support this workflow:
+
+| Guide | Use When |
+|-------|----------|
+| EXECUTION-PRINCIPLES.md | Core execution discipline (document before acting, sketch fidelity, plan-then-execute) |
+| INLINE-TESTING-GUIDE.md | Self-verifying implementation with Puppeteer before presenting to user |
+| SEO-VALIDATION-GUIDE.md | Public-facing pages that need SEO compliance |
+| SESSION-PROTOCOL.md | Managing agent sessions and handoffs |
+| FEEDBACK-PROTOCOL.md | Handling user feedback during development |
+
+---
+
+## INITIALIZATION
+
+### Design Log
+Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
+
+---
+
+## STEPS
+
+Execute steps in `./steps-d/`:
+
+| Step | File | Purpose |
+|------|------|---------|
+| 01 | step-01-scope-and-plan.md | Read spec, identify work items, create implementation order |
+| 02 | step-02-setup-environment.md | Verify environment, install dependencies, establish baseline |
+| 03 | step-03-implement.md | Build features one at a time from the plan |
+| 04 | step-04-verify.md | Walk through every acceptance criterion |
+| 05 | step-05-finalize.md | Clean up, test suite, PR preparation |
+
+---
+
+## DESIGN LOG REPORTING POINTS
+
+Append to the Design Loop Status table in `{output_folder}/_progress/00-design-log.md`:
+
+**On entry (step 01 complete):** `| [Scenario slug] | [NN.X] | [Page name] | building | [YYYY-MM-DD] |`
+**On completion (step 05 approved):** `| [Scenario slug] | [NN.X] | [Page name] | built | [YYYY-MM-DD] |`
+
+## AFTER COMPLETION
+
+Design log updated with `built` status (see above). Present the transition:
+
+<output>
+**"[page name]" is built!**
+
+1. **Run acceptance testing** — validate against the specification
+2. **Explore the next scenario step** — [next page name]
+</output>