@maestro-ai/cli 1.2.0 → 1.3.0

package/content/rules/complexity-rules.md

@@ -0,0 +1,43 @@
+# 🧠 Regras de Classificação de Complexidade
+
+> Este arquivo define a lógica para analisar o **PRD (Produto)** e calcular automaticamente a complexidade do projeto.
+
+---
+
+## 1. Tabela de Pontuação
+
+**Instrução:** Leia o conteúdo do `docs/01-produto/PRD.md` e some os pontos baseados nos critérios abaixo.
+
+| Critério | O que buscar (Regex/Keywords) | Pontos |
+| :--- | :--- | :--- |
+| **1. Entidades de Domínio** | Conte substantivos únicos relevantes (ex: Usuário, Pedido, Produto).<br>- `> 15 entidades`: **+3**<br>- `> 8 entidades`: **+2**<br>- `Até 8`: **+1** | `___` |
+| **2. Integrações Externas** | Palavras-chave: `API`, `integração`, `webhook`, `pagamento`, `stripe`, `auth0`, `firebase`.<br>- Se encontrar qualquer uma: **+3** | `___` |
+| **3. Requisitos de Segurança** | Palavras-chave: `LGPD`, `GDPR`, `criptografia`, `JWT`, `permissões`, `roles`.<br>- Se encontrar qualquer uma: **+3** | `___` |
+| **4. Escala e Performance** | Palavras-chave: `milhares`, `milhões`, `alta disponibilidade`, `concorrência`, `cluster`.<br>- Se encontrar qualquer uma: **+3** | `___` |
+| **5. Multi-tenancy / B2B** | Palavras-chave: `multi-tenant`, `workspace`, `organização`, `saas`.<br>- Se encontrar qualquer uma: **+2** | `___` |
+| **6. Cronograma Estimado** | Verifique seções de tempo.<br>- `> 6 meses`: **+3**<br>- `> 2 meses`: **+2**<br>- `Curto prazo`: **+1** | `___` |
+| **7. Regras de Negócio** | Frequência de palavras: `regra`, `validação`, `fluxo`, `condição`.<br>- `Alta densidade`: **+3**<br>- `Média densidade`: **+2** | `___` |
+
+---
+
+## 2. Tabela de Decisão (Nível)
+
+**Instrução:** Use a soma total dos pontos para definir o nível e o fluxo do projeto.
+
+| Pontuação Total | Nível Definido | Total de Fases do Fluxo |
+| :--- | :--- | :--- |
+| **0 a 8 pontos** | **🥉 Simples** | **7 Fases** (Produto → Requisitos → UX → Arq → Backlog → Front → Back) |
+| **9 a 15 pontos** | **🥈 Médio** | **13 Fases** (Adiciona: Modelo, Banco, Segurança, Contrato, Testes, Integração) |
+| **16+ pontos** | **🥇 Complexo** | **17 Fases** (Adiciona: Arq. Avançada, Performance, Observabilidade, Deploy Final) |
+
+---
+
+## 3. Ação Pós-Classificação (Apenas Fase 1)
+
+Se você acabou de concluir a Fase 1 (Produto):
+1.  **Calcule** a pontuação.
+2.  **Determine** o nível.
+3.  **Atualize** o arquivo `.maestro/estado.json` com:
+    *   `"nivel": "simples" | "medio" | "complexo"`
+    *   `"total_fases": 7 | 11 | 15`
+    *   `"pontuacao_complexidade": {numero}`

package/content/rules/quality-gates.md

@@ -1,43 +1,55 @@
-# 🔐 Quality Gates por Transição
-
-| De → Para | Checklist Obrigatória | Validadores sugeridos |
-|-----------|----------------------|------------------------|
-| Produto → Requisitos | MVP 100% coberto nos requisitos; personas refletidas | `validarCoberturaMVP(PRD, requisitos)` |
-| Requisitos → UX Design | Fluxos/jornadas definidos; critérios de aceite aprovados | `analisarFluxosUsuarios(requisitos)` |
-| UX Design → Prototipagem (Stitch) | Wireframes completos; estilo aprovado | `validarWireframes(designDoc)` |
-| Prototipagem → Arquitetura | Feedback aplicado; requisitos atualizados | `verificarConsistencia(designDoc, requisitos)` |
-| Arquitetura → Modelo de Domínio | Stack confirmada; contexto alinhado | `compararModelagem(arquitetura, modeloDominio)` |
-| Modelo de Domínio → Banco de Dados | Entidades → tabelas; regras documentadas | `validarModeloDominio(modeloDominio, designBanco)` |
-| Banco → Segurança | Dados sensíveis catalogados; políticas definidas | `analisarSensibilidade(designBanco)` |
-| Segurança → Testes | Controles críticos definidos; riscos registrados | `validarChecklistSeguranca(checklist)` |
-| Testes → Backlog | Estratégia de testes aprovada; cobertura planejada | `verificarPlanoTestes(plano)` |
-| Backlog → Contrato API | Stories/radar de integrações aprovados | `compararBacklogContrato(backlog, openapi)` |
-| Contrato API → Frontend | OpenAPI completo; mocks disponíveis | `validarContrato(openapi)` |
-| Frontend → Backend | Componentes integrados a mocks; testes passando | `executarSuite('frontend-tests')` |
-| Backend → Integração/Deploy | Testes unitários/integração/contrato passando | `executarSuite('backend-tests')` |
-| Integração → Observabilidade (fluxo complexo) | Pipelines verdes; monitoração básica configurada | `validarPipeline(ciCdConfig)` |
-| Observabilidade → Performance | Dashboards + alertas definidos | `validarObservabilidade(config)` |
-| Performance → Deploy Final | Testes de carga concluídos; tuning aplicado | `executarLoadTest(plan)` |
-
-## Exemplo de validação cruzada (Produto → Requisitos)
-
-```javascript
-function validarCoberturaMVP(prdPath, requisitosPath) {
-  const prd = lerArquivo(prdPath);
-  const requisitos = lerArquivo(requisitosPath);
-  const mvpItems = extrairItens('MVP', prd);
-  const faltantes = mvpItems.filter(item => !requisitos.includes(item));
-
-  return {
-    percentual: ((mvpItems.length - faltantes.length) / mvpItems.length) * 100,
-    faltantes
-  };
-}
-```
-
-## Uso no /avancar-fase
-
-1. Determine a transição atual (fase `N` → `N+1`).
-2. Carregue o checklist correspondente na tabela acima.
-3. Execute as funções auxiliares indicadas (ou use lógica equivalente).
-4. Só permita avanço quando **todos** os itens estiverem `true` e o score da fase atingir o mínimo definido em `validation-rules.md`.
+# 🔐 Quality Gates e Estruturas
+
+> Este arquivo é a fonte da verdade para validar a qualidade e estrutura dos entregáveis.
+
+---
+
+## 🏗️ 1. Validação Estrutural (Obrigatória)
+
+**Instrução:** Para cada fase, consulte o arquivo `rules/structure-rules.md`. Ele contém a tabela exata de regexes obrigatórias.
+
+| Fase | Arquivo Alvo | Referência |
+|------|--------------|------------|
+| **Todas as Fases** | `docs/XX-nome/arquivo.md` | Consulte `rules/structure-rules.md` |
+
+---
+
+## 🧠 2. Validação Lógica (Semântica)
+
+**Instrução:** Leia o conteúdo e aplique a lógica de verificação da transição atual.
+
+### Transição: Produto → Requisitos
+*   **Contexto:** Comparar `PRD.md` vs `requisitos.md`.
+*   **Regra Lógica:**
+    *   `PARA CADA` funcionalidade no MVP do PRD:
+        *   `VERIFIQUE SE` existe um requisito funcional correspondente em `requisitos.md`.
+    *   `SE` cobertura < 100%:
+        *   ❌ Falha: Cite as funcionalidades faltantes.
+
+### Transição: Requisitos → UX Design
+*   **Contexto:** Ler `requisitos.md` vs `design-doc.md`.
+*   **Regra Lógica:**
+    *   `PARA CADA` requisito funcional crítico:
+        *   `VERIFIQUE SE` existe um fluxo de usuário ou tela descrita no Design Doc.
+
+### Transição: Arquitetura → Banco de Dados
+*   **Contexto:** Ler `arquitetura.md` e `modelo-dominio.md`.
+*   **Regra Lógica:**
+    *   `VERIFIQUE SE` todas as entidades listadas no Modelo de Domínio possuem tabelas/coleções correspondentes no Design de Banco.
+
+### Transição: Contrato API → Implementação (Backend/Frontend)
+*   **Contexto:** Ler `openapi.yaml` vs Código.
+*   **Regra Lógica:**
+    *   `VERIFIQUE SE` todos os endpoints definidos no contrato existem no código.
+
+---
+
+## 🚦 3. Tabela de Decisão (Score)
+
+Use em conjunto com `validation-rules.md` para determinar o Tier.
+
+| Score Calculado | Ação do Agente |
+| :--- | :--- |
+| **100%** | ✅ **APROVAR**: Executar o avanço de fase. |
+| **70% - 99%** | ⚠️ **ALERTA**: Listar pendências, mas permitir avanço (pergunte ao usuário). |
+| **< 70%** | 🛑 **BLOQUEAR**: Não avance. Liste erros e pare. |

package/content/rules/security-rules.md

@@ -0,0 +1,40 @@
+# 🛡️ Regras de Análise de Segurança (Code Review)
+
+> Estas regras devem ser verificadas manualmente pela IA ao ler arquivos de código, especialmente antes de commits ou deploys.
+
+Baseado no **OWASP Top 10**.
+
+## 🔴 Crítico (Bloqueante)
+
+| ID | Regra | O que buscar (Padrão/Regex) | Correção Sugerida |
+| :--- | :--- | :--- | :--- |
+| **A01-ADMIN** | **Bypass de Admin** | `isAdmin\s*[=!]=\s*(true\|false)` ou check confiavel só no frontend | Verificar roles apenas no Backend/Token. |
+| **A02-SECRET** | **Secret Hardcoded** | `(password\|secret\|key\|token)\s*[:=]\s*['"][^'"]{8,}['"]` | Mover para variáveis de ambiente (`process.env`). |
+| **A03-SQLI** | **SQL Injection** | `query\("SELECT ... " + var` (Concatenação direta) | Usar Prepared Statements ou ORM. |
+| **A03-EVAL** | **Uso de Eval** | `eval\(` | **Remover**. Usar JSON.parse ou alternativas seguras. |
+
+## 🟠 Alto (Requer Correção)
+
+| ID | Regra | Padrão Visual | Correção |
+| :--- | :--- | :--- | :--- |
+| **A02-WEAK** | **Criptografia Fraca** | `md5(`, `sha1(` | Usar `bcrypt`, `argon2` ou `SHA-256`. |
+| **A07-XSS** | **XSS (HTML Injection)** | `innerHTML =`, `dangerouslySetInnerHTML` | Usar sanitização (DOMPurify) ou textContent. |
+| **A01-ID-REF** | **Exposição de ID** | URL com ID incremental `/user/123` sem auth check | Implementar verificação de permissão por recurso. |
+
+## 🟡 Médio (Sugestão de Melhoria)
+
+| ID | Regra | Padrão Visual | Correção |
+| :--- | :--- | :--- | :--- |
+| **SEC-LOG** | **Log em Produção** | `console.log(` | Remover ou usar `logger.debug()`. |
+| **SEC-TODO** | **TODO de Segurança** | `// TODO: security`, `// TODO: fix auth` | Resolver antes do merge. |
+| **SEC-CORS** | **CORS Permissivo** | `Access-Control-Allow-Origin: *` | Restringir domínios. |
+
+---
+
+## 🚦 Como Usar
+
+Durante a fase de **Implementação** ou **Refatoração**:
+
+1.  Ao gerar código, faça uma auto-verificação rápida usando esta tabela.
+2.  Se encontrar um padrão **Crítico**, corrija imediatamente.
+3.  Se encontrar um padrão **Alto**, avise o usuário e sugira a correção.

package/content/rules/structure-rules.md

@@ -0,0 +1,63 @@
+# 📏 Regras de Validação Estrutural
+
+> Estas regras definem as SEÇÕES OBRIGATÓRIAS (Headers) que devem existir nos documentos para cada fase.
+> A validação deve ser feita via Regex no Header Markdown (`# ...` ou `## ...`).
+
+## 1. Produto (PRD)
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Problema** | `^#{1,2}\s*(problema|problem)` |
+| **MVP/Escopo** | `^#{1,2}\s*(funcionalidade|feature|mvp|escopo)` |
+| **Usuários** (Base+) | `^#{1,2}\s*(usuário|usuario|user|persona)` |
+| **Métricas** (Base+) | `^#{1,2}\s*(métrica|metrica|sucesso|kpi)` |
+
+## 2. Requisitos
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Funcionais** | `^#{1,2}\s*(requisito|requirement|rf\d|funcional)` |
+| **Não-Funcionais** | `^#{1,2}\s*(não.?funcional|nfr|rnf|performance|segurança)` |
+
+## 3. UX Design
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Jornadas** | `^#{1,2}\s*(jornada|journey|fluxo|flow)` |
+| **Wireframes** | `^#{1,2}\s*(wireframe|protótipo|prototipo|tela|screen)` |
+
+## 4. Banco de Dados
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Schema/Tabelas** | `^#{1,2}\s*(tabela|table|schema|modelo)` |
+
+## 5. Arquitetura
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Diagrama (C4)** | `^#{1,2}\s*(c4|diagrama|arquitetura|architecture)` |
+| **Stack** | `^#{1,2}\s*(stack|tecnologia|technology)` |
+| **Decisões** | `^#{1,2}\s*(adr|decisão|decision)` |
+
+## 6. Testes
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Estratégia** | `^#{1,2}\s*(estratégia|strategy|plano)` |
+| **Casos de Teste** | `^#{1,2}\s*(caso|case|cenário|scenario)` |
+
+## 7. Contratos API
+
+| Seção Obrigatória | Regex Sugerida |
+| :--- | :--- |
+| **Endpoints** | `^#{1,2}\s*(endpoint|api|openapi|swagger)` |
+
+---
+
+## ⚙️ Instrução de Validação
+
+Ao validar um entregável:
+1.  Verifique a fase.
+2.  Busque cada **Header** obrigatório usando a regex (case insensitive).
+3.  Se faltar algum, o Gate falha.

package/content/rules/validation-rules.md

@@ -1,97 +1,56 @@
-# 🛡️ Regras de Validação por Fase
-
-## Fase 1 - Produto
-- Problema central definido
-- Público-alvo/personas
-- MVP listado e priorizado
-- Métricas de sucesso (North Star + KPIs)
-- Score mínimo: **75/100**
-
-## Fase 2 - Requisitos
-- Cobertura 100% do MVP
-- Requisitos funcionais em formato testável
-- Requisitos não funcionais (performance, segurança)
-- Critérios de aceite (Given-When-Then)
-- Score mínimo: **70/100**
-
-## Fase 3 - UX Design
-- Wireframes para todas as telas principais
-- Jornadas/fluxos de usuário descritos
-- Navegação coerente
-- Consistência visual e de componentes
-- Score mínimo: **70/100**
-
-## Fase 4 - Prototipagem / Stitch (quando aplicável)
-- Protótipo navegável validado com stakeholders
-- Feedback registrado e aplicado
-- Export pronto para handoff ou Stitch output salvo
-- Score mínimo: **75/100**
-
-## Fase 5 - Arquitetura
-- Stack definida
-- Diagrama C4 nível 2 ou 3
-- ADRs para decisões críticas
-- Requisitos não funcionais endereçados
-- Score mínimo: **80/100**
-
-## Fase 6 - Modelo de Domínio
-- Entidades e relacionamentos definidos
-- Regras de negócio documentadas
-- Eventos e agregados identificados (quando necessário)
-- Score mínimo: **75/100**
-
-## Fase 7 - Banco de Dados
-- Modelo relacional ou NoSQL definido
-- Índices/partições planejados
-- Estratégia de migração descrita
-- Score mínimo: **75/100**
-
-## Fase 8 - Segurança
-- OWASP Top 10 avaliado
-- Autenticação/autorização descritas
-- Dados sensíveis mapeados e protegidos
-- Score mínimo: **80/100**
-
-## Fase 9 - Testes
-- Estratégia (pirâmide) definida
-- Casos de teste críticos descritos
-- Ferramentas e ambientes definidos
-- Score mínimo: **75/100**
-
-## Fase 10 - Backlog
-- Épicos e features priorizados
-- Histórias com critérios de aceite claros
-- Dependências mapeadas
-- Score mínimo: **75/100**
-
-## Fase 11 - Contrato de API
-- Esquema OpenAPI completo
-- Versionamento/documentação definidas
-- Mocks ou client SDK disponíveis
-- Score mínimo: **80/100**
-
-## Fase 12 - Frontend
-- Componentes implementados conforme design
-- Testes de componente ou integração passando
-- Responsividade e acessibilidade verificadas
-- Score mínimo: **80/100**
-
-## Fase 13 - Backend
-- Endpoints implementados conforme contrato
-- Testes unitários e de integração passando
-- Migrações e jobs documentados
-- Score mínimo: **80/100**
-
-## Fase 14 - Performance / Observabilidade (fluxo complexo)
-- Métricas e alertas configurados
-- Estratégia de cache/performance definida
-- Testes de carga planejados
-- Score mínimo: **80/100**
-
-## Fase 15 - Integração / Deploy
-- Pipeline CI/CD verde
-- Testes E2E executados
-- Plano de rollback/documentação de release
-- Score mínimo: **85/100**
-
-> Use essas regras para preencher `fase.validacoes` e justificar o `score` atribuído no estado.
+# 📏 Regras de Classificação e Score
+
+> Definição dos critérios de aprovação baseados na complexidade do projeto.
+
+## Tiers de Projeto (Nível de Rigor)
+
+Consulte `.maestro/estado.json` para saber o nível do seu projeto.
+
+### 🥉 Tier Essencial (POC, Script)
+*   **Foco**: Funciona?
+*   **Critérios de Check**:
+    1.  Código executa sem erro fatal?
+    2.  Objetivo principal foi atingido?
+    3.  Existe um README.md básico?
+
+### 🥈 Tier Base (Produto Interno, MVP)
+*   **Foco**: Qualidade Mínima
+*   **Critérios de Check (acumulativo)**:
+    1.  Critérios do Tier Essencial ✅
+    2.  Testes unitários existem (mesmo que poucos)?
+    3.  Não há erros visíveis de Lint/Typescript?
+    4.  Documentação técnica existe (`docs/`)?
+    5.  Validação de dados (ex: Zod) implementada?
+
+### 🥇 Tier Avançado (SaaS, Fintech, Alta Escala)
+*   **Foco**: Robustez e Segurança
+*   **Critérios de Check (acumulativo)**:
+    1.  Critérios do Tier Base ✅
+    2.  Segurança: Tratamento de erros e dados sensíveis?
+    3.  Observabilidade: Logs estruturados previstos?
+    4.  Testes de Integração/E2E previstos?
+    5.  Arquitetura desacoplada (SOLID/Clean Arch)?
+
+---
+
+## 🧮 Como Calcular o Score (Manual)
+
+Ao realizar o checklist do Tier correspondente:
+
+1.  Conte o número total de perguntas do checklist (ex: 5 critérios).
+2.  Conte quantas foram respondidas com "SIM" (ex: 4).
+3.  Aplique a fórmula:
+    ```
+    Score = (Itens OK / Total) * 100
+    ```
+    *Exemplo: (4 / 5) * 100 = 80*
+
+## 🚦 Tabela de Decisão
+
+| Score Calculado | Ação Recomendada | Comando |
+| :--- | :--- | :--- |
+| **100** | Aprovado | ✅ Pode executar `/02-avancar-fase` |
+| **70 a 99** | Aprovado com Ressalvas | ⚠️ Pode avançar, mas liste as pendências |
+| **0 a 69** | **BLOQUEADO** | 🛑 NÃO avance. Solicite correções. |
+
+> **Nota**: Se houver um bloqueio (Score < 70) mas o usuário EXIGIR avançar, trate como "Aprovação Manual" e peça uma justificativa.

package/content/workflows/{maestro.md → 00-maestro.md}

@@ -21,7 +21,7 @@ Antes de qualquer decisão:
 1. **Ler estado** em `.maestro/estado.json` (se não existir, classificar como `novo_projeto`).
 2. **Validar consistência** comparando `estado.fases` com o fluxo MCP adequado.
 3. **Classificar estado** usando a função mental abaixo.
-4. **Mapear ação** (`/iniciar-projeto`, `/continuar-fase`, `/avancar-fase`).
+4. **Mapear ação** (`/01-iniciar-projeto`, `/03-continuar-fase`, `/02-avancar-fase`).
 5. **Responder** com resumo e próxima ação sugerida.
 
 ```javascript
@@ -31,14 +31,14 @@ const fluxo = estado?.projeto
   : null;
 
 if (!estado || !estado.projeto?.nome) {
-  return { status: 'novo_projeto', proximaAcao: '/iniciar-projeto' };
+  return { status: 'novo_projeto', proximaAcao: '/01-iniciar-projeto' };
 }
 
 const faseAtual = estado.fases[estado.faseAtual];
 if (!faseAtual || faseAtual.status !== 'concluida') {
   return {
     status: 'fase_incompleta',
-    proximaAcao: '/continuar-fase',
+    proximaAcao: '/03-continuar-fase',
     fase: estado.faseAtual,
     arquivoFoco: faseAtual?.artefatos?.slice(-1)[0] || fluxo?.fases?.find(f => f.numero === estado.faseAtual)?.entregavel_esperado,
     divergenciasFluxo: compararComFluxo(estado.fases, fluxo?.fases)
@@ -47,7 +47,7 @@ if (!faseAtual || faseAtual.status !== 'concluida') {
 
 return {
   status: 'pronto_para_avancar',
-  proximaAcao: '/avancar-fase',
+  proximaAcao: '/02-avancar-fase',
   fase: estado.faseAtual,
   proximaFase: estado.faseAtual + 1,
   divergenciasFluxo: compararComFluxo(estado.fases, fluxo?.fases)
@@ -59,8 +59,9 @@ return {
 ```
 📋 **Status Detectado:** {status}
 - Projeto: {estado.projeto.nome}
-- Fase atual: {estado.faseAtual}/{totalFases} - {faseAtual.nome}
-- Especialista: {faseAtual.especialista}
+- Fase atual: {estado.faseAtual}/{totalFases} - {faseAtual.nome} (Status: {faseAtual.status})
+- Tier: {estado.projeto.tier} | Nível: {estado.projeto.nivel}
+- Última atualização: {estado.updated_at}
 - Arquivo foco: {arquivoFoco}
 
 🎯 **Próxima ação sugerida:** {proximaAcao}

package/content/workflows/01-iniciar-projeto.md

@@ -0,0 +1,59 @@
+---
+description: Workflow para inicializar um novo projeto Maestro com estrutura completa
+---
+
+# 🚀 Workflow de Inicialização - /iniciar-projeto
+
+## 0. Fase Zero: Brainstorming (Opcional)
+
+*   **Condição:** Se o usuário não tem um escopo claro ou objetivo definido.
+*   **Ação:** Consulte `guides/guide-brainstorm.md` para conduzir uma sessão de ideação antes de iniciar.
+
+## 1. Coleta de Informações
+
+*   **Ação:** Pergunte ao usuário o nome do projeto (se não fornecido).
+*   **Ação:** Pergunte qual o objetivo principal (use a saída do Brainstorm).
+
+## 2. Setup de Diretórios
+
+*   **Ação:** Crie a estrutura de pastas usando `run_command` (mkdir) ou `write_to_file`.
+    *   `.maestro/`
+    *   `.maestro/history/`
+    *   `docs/01-produto/`
+
+## 3. Inicialização de Estado (JSON)
+
+*   **Ação:** Crie ` .maestro/estado.json` (Estado Base):
+```json
+{
+  "nome_projeto": "{NOME}",
+  "fase_atual": 1,
+  "fase_nome": "Produto",
+  "tier": "base",
+  "nivel": "a_definir",
+  "created_at": "{DATA}",
+  "updated_at": "{DATA}",
+  "entregaveis": {}
+}
+```
+
+*   **Ação:** Crie ` .maestro/resumo.json` (Cache de Memória):
+```json
+{
+  "resumo_executivo": "Projeto {NOME}: {OBJETIVO}",
+  "entregaveis": [],
+  "contexto_atual": {
+    "fase": "Produto",
+    "objetivo": "Definir o MVP e criar o PRD"
+  }
+}
+```
+
+## 4. Boot da Fase 1
+
+*   **Ação:** Identifique o especialista da fase 1 ("Gestão de Produto").
+*   **Ação:** Identifique o template da fase 1 (`templates/PRD.md`).
+*   **Resposta ao Usuário:**
+    *   Confirme que a "Infraestrutura Maestro" foi criada.
+    *   Assuma a persona de **Gerente de Produto**.
+    *   Inicie o Discovery do Produto.

package/content/workflows/02-avancar-fase.md

@@ -0,0 +1,72 @@
+---
+description: Workflow MESTRE para avançar fases com validação, classificação e persistência robusta
+---
+
+# 🔄 Workflow de Avanço - /avancar-fase
+
+## 1. Leitura de Estado
+
+*   **Ação:** Leia o arquivo `.maestro/estado.json`.
+*   **Dados:** Identifique `fase_atual`, `tier`, `nome_projeto`.
+*   **Ação:** Identifique o arquivo entregável da fase atual (ex: `docs/01-produto/PRD.md`).
+
+## 2. Validação de Gate (Checklist Mestre)
+
+*   **Referência:** `.maestro/content/rules/quality-gates.md`
+*   **Passo 2.1: Estrutura**: Verifique se o entregável tem tamanho > 200 chars e possui as seções obrigatórias.
+*   **Passo 2.2: Semântica**: Verifique a lógica da transição específica.
+*   **Decisão**:
+    *   `SE` falhar em qualquer validação crítica: **PARE**. Retorne erro ao usuário.
+
+## 2.5 Orquestração de Review (Momentum)
+
+*   **Condição:** Se o projeto for **Tier Avançado** ou a fase for crítica (ex: Arquitetura).
+*   **Ação:** Ative o **Modo Squad** (via `guides/guide-orquestracao.md`) para simular uma banca examinadora:
+    1.  **Persona Produto:** "Isso atende o usuário?"
+    2.  **Persona Tech:** "Isso escala? É seguro?"
+    3.  **Persona QA:** "Está testável?"
+*   **Decisão:** Só aprove o gate se as 3 personas concordarem.
+
+## 3. Gestão Inteligente (Condicional)
+
+### Apenas se Fase Atual == 1 (Produto)
+*   **Ação:** Leia o arquivo `.maestro/content/rules/complexity-rules.md`.
+*   **Execução:**
+    1.  Analise o `PRD.md` buscando as keywords da tabela de pontuação.
+    2.  Some os pontos (Entidades + Integrações + Segurança + etc).
+    3.  Defina o **Nível** (Simples/Médio/Complexo).
+*   **Persistência**: Atualize `.maestro/estado.json` com o novo `nivel` e `total_fases`.
+
+## 4. Persistência de Resumo (Memória)
+
+*   **Ação:** Leia (ou crie) `.maestro/resumo.json`.
+*   **Execução**:
+    1.  Crie uma entrada na lista `entregaveis` com um resumo de 1 linha do que foi feito nesta fase.
+    2.  Atualize o campo `contexto_atual` com o objetivo da próxima fase.
+*   **Persistência**: Salve o arquivo atualizado.
+
+## 5. Atualização de Estado e Transição
+
+*   **Ação:** Atualize `.maestro/estado.json`:
+    *   `fase_atual`: incremente +1.
+    *   `status`: "in_progress".
+    *   `updated_at`: data/hora atual.
+    *   `entregaveis`: adicione o path do arquivo aprovado.
+
+## 6. Carregamento da Próxima Fase
+
+
+
+*   **Ação:** Identifique o próximo especialista usando `guides/fases-mapeamento.md`.
+*   **Ação:** Liste os **Prompts Recomendados** encontrados na tabela para o usuário.
+*   **Ação (Automática):** Se estiver concluindo a **Fase de UX (3)** e o projeto for visual:
+    *   Execute `guides/internal/automated-stitch.md` para verificar e ativar a prototipagem.
+*   **Ação Final:** Execute a automação `guides/internal/automated-system.md` para persistir o contexto global.
+*   **Ação Final:** Registre o evento usando `guides/internal/automated-events.md`.
+
+*   **Resposta ao Usuário:**
+    *   ✅ **Confirmação**: "Fase X concluída (Score: Y%)."
+    *   📊 **Classificação** (Se Fase 1): "Projeto classificado como **[NÍVEL]** ([PONTOS] pts)."
+    *   🚀 **Próximo Passo**: "Iniciando Fase [N+1]: [NOME]. Especialista carregado."
+    *   📚 **Prompts Sugeridos**: [Liste os prompts aqui]
+    *   **Imediatamente**: Assuma a persona e peça o primeiro input da nova fase.

package/content/workflows/04-implementar-historia.md

@@ -0,0 +1,64 @@
+---
+description: Guia de implementação "Frontend-First" para Histórias de Usuário
+---
+
+# 🔨 Workflow de Implementação - /implementar-historia
+
+> Este workflow deve ser invocado durante a **Fase de Implementação** (seja em um projeto novo ou feature). Ele garante que uma História de Usuário (User Story) seja entregue com qualidade e testabilidade.
+
+## 0. Contexto
+
+*   **Entrada:** ID da História (ex: `US-01`, `FEAT-A`)
+*   **Pré-requisito:** Contrato de Interface definido (se houver API envolvida).
+*   **Estratégia:** Se a história for muito complexa, considere usar **`/05-nova-feature`** ou consulte `guides/guide-orquestracao.md` para dividir o trabalho entre "Persona Backend" e "Persona Frontend".
+
+## 1. 📜 Etapa 1: Definição de Contratos
+
+Antes de escrever código de produto, defina as interfaces.
+
+1.  **Schema OpenAPI (se Backend envolvido):**
+    *   Crie/atualize `docs/api/openapi.yaml` com o endpoint.
+2.  **Types TypeScript (Compartilhado):**
+    *   Gere interfacesTS que representam a entrada e saída do endpoint.
+    *   Salve em `src/types/` (ex: `src/types/pedido.ts`).
+
+## 2. 🎭 Etapa 2: Mocking
+
+Crie a infraestrutura para que o Frontend possa trabalhar independente do Backend.
+
+1.  **Mock Data:**
+    *   Crie um objeto JSON estático representando uma resposta de sucesso e casos de erro.
+
+## 3. 🎨 Etapa 3: Frontend (Componentes)
+
+Comece a UI usando os Mocks.
+
+1.  **Componentes Visuais:**
+    *   Implemente os componentes de UI (botões, formulários, listas).
+2.  **Hooks/Services:**
+    *   Crie a camada de serviço que consome o mock (e futuramente a API).
+3.  **Teste de Componente:**
+    *   Verifique se a tela renderiza corretamente com os dados do Mock.
+
+## 4. ⚙️ Etapa 4: Backend
+
+Implemente a lógica real.
+
+1.  **DTOs:** Validação de entrada.
+2.  **Controller/Service:** Lógica de negócio.
+3.  **Repository:** Persistência.
+4.  **Testes Unitários:** Garanta que a regra de negócio funcione isolada.
+
+## 5. 🔗 Etapa 5: Integração e Limpeza
+
+A hora da verdade.
+
+1.  **Troca de Chave:** Aponte o serviço do Frontend para a API real (remova/desabilite o Mock).
+2.  **Teste Integrado:** Siga o `guides/guide-testes.md` para validar casos de borda e happy path.
+3.  **Teste E2E Manual:** Navegue pelo fluxo completo.
+4.  **Validação de Segurança:** Consulte `rules/security-rules.md` e verifique seu código.
+
+> ✅ **Conclusão:** Quando o fluxo funcionar ponta-a-ponta:
+1.  Faça o `commit`.
+2.  Execute `guides/internal/automated-map.md` para atualizar a estrutura.
+3.  Registre o evento com `guides/internal/automated-events.md`.