@maestro-ai/cli 1.1.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

@@ -0,0 +1,55 @@
+# 🔐 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

@@ -0,0 +1,56 @@
+# 📏 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/templates/estado-template.json

@@ -0,0 +1,73 @@
+{
+  "projeto": {
+    "nome": "[Nome do Projeto]",
+    "descricao": "[Resumo do projeto]",
+    "tipo": "[poc|script|internal|product]",
+    "complexidade": "[simples|medio|complexo]",
+    "tier": "[essencial|base|avancado]",
+    "usarStitch": false,
+    "criadoEm": "[ISO datetime]",
+    "atualizadoEm": "[ISO datetime]"
+  },
+  "faseAtual": {
+    "numero": 1,
+    "nome": "Produto",
+    "status": "in_progress",
+    "especialista": "Gestão de Produto",
+    "score": null,
+    "scoreMinimo": 75,
+    "iniciadoEm": "[ISO datetime]",
+    "ultimoUpdate": "[ISO datetime]"
+  },
+  "fases": {
+    "1": {
+      "numero": 1,
+      "nome": "Produto",
+      "especialista": "Gestão de Produto",
+      "status": "pending",
+      "score": null,
+      "scoreMinimo": 75,
+      "artefatos": ["docs/01-produto/PRD.md"],
+      "validacoes": {
+        "problema_definido": false,
+        "personas": false,
+        "mvp_listado": false,
+        "metricas": false
+      }
+    },
+    "2": {
+      "numero": 2,
+      "nome": "Requisitos",
+      "especialista": "Engenharia de Requisitos",
+      "status": "pending",
+      "score": null,
+      "scoreMinimo": 70,
+      "artefatos": ["docs/02-requisitos/requisitos.md"],
+      "validacoes": {
+        "requisitos_funcionais": false,
+        "requisitos_nao_funcionais": false,
+        "criterios_aceite": false,
+        "cobertura_mvp": false
+      }
+    }
+  },
+  "qualityGates": {
+    "1_para_2": {
+      "validado": false,
+      "score": null,
+      "checks": ["mvp_100_coberto"]
+    }
+  },
+  "historico": [
+    {
+      "acao": "projeto_iniciado",
+      "detalhes": "Projeto criado a partir do template",
+      "timestamp": "[ISO datetime]"
+    }
+  ],
+  "metrica": {
+    "fasesConcluidas": 0,
+    "ultimoComando": null,
+    "tempoPorFase": {}
+  }
+}

package/content/workflows/00-maestro.md

@@ -0,0 +1,78 @@
+---
+description: Workflow universal inteligente que detecta estado e toma a próxima ação
+---
+
+# 🤖 Workflow Universal - /maestro
+
+## Objetivo
+
+Detectar automaticamente o estado do projeto Maestro, validar se o estado reflete os fluxos MCP (7/13/17 fases + Stitch) e decidir a ação adequada, respondendo no chat com contexto completo.
+
+## Sincronização com os fluxos MCP
+
+Antes de qualquer decisão:
+
+1. Ler `.maestro/estado.json` **e** o template original em `packages/cli/content/templates/estado-template.json` para entender a estrutura completa.
+2. Ler `src/src/flows/types.ts` para conhecer `FLUXO_SIMPLES`, `FLUXO_MEDIO`, `FLUXO_COMPLEXO` e a inserção opcional de Stitch (`getFluxoComStitch`).
+3. Verificar se `estado.fases` segue a mesma ordem e quantidade de fases do fluxo correspondente. Se detectar divergências (fase faltando, numeração diferente), listar no resumo e sugerir ao usuário rodar `/iniciar-projeto` ou ajustar manualmente.
+
+## Como funciona
+
+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** (`/01-iniciar-projeto`, `/03-continuar-fase`, `/02-avancar-fase`).
+5. **Responder** com resumo e próxima ação sugerida.
+
+```javascript
+const estado = lerJson('.maestro/estado.json');
+const fluxo = estado?.projeto
+  ? getFluxoComStitch(estado.projeto.complexidade, estado.projeto.usarStitch)
+  : null;
+
+if (!estado || !estado.projeto?.nome) {
+  return { status: 'novo_projeto', proximaAcao: '/01-iniciar-projeto' };
+}
+
+const faseAtual = estado.fases[estado.faseAtual];
+if (!faseAtual || faseAtual.status !== 'concluida') {
+  return {
+    status: 'fase_incompleta',
+    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)
+  };
+}
+
+return {
+  status: 'pronto_para_avancar',
+  proximaAcao: '/02-avancar-fase',
+  fase: estado.faseAtual,
+  proximaFase: estado.faseAtual + 1,
+  divergenciasFluxo: compararComFluxo(estado.fases, fluxo?.fases)
+};
+```
+
+## Template de resposta
+
+```
+📋 **Status Detectado:** {status}
+- Projeto: {estado.projeto.nome}
+- 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}
+➡️ Execute o comando correspondente ou peça um ajuste específico.
+
+{divergenciasFluxo?.length ? `⚠️ Divergências detectadas entre estado e fluxo MCP:
+- ${divergenciasFluxo.join('\n- ')}` : ''}
+```
+
+## Regras rápidas
+
+- Sempre verificar se há bloqueios (`faseAtual.status === 'bloqueado'`) e destacar no resumo.
+- Se detectar `novo_projeto`, **não** tentar gerar estado: apenas orientar o usuário a rodar `/iniciar-projeto`.
+- Se o usuário preferir outra ação, respeitar e registrar no histórico (se aplicável).

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/03-continuar-fase.md

@@ -0,0 +1,64 @@
+---
+description: Retoma a fase atual exatamente do ponto onde foi interrompida
+---
+
+# 🔄 Workflow de Continuação - /continuar-fase
+
+## 1. Ler estado atual
+
+```javascript
+const estado = lerJson('.maestro/estado.json');
+const faseAtual = estado.fases[estado.faseAtual];
+if (!faseAtual) throw new Error('Fase atual não encontrada');
+
+function salvarEstado(state) {
+  escreverJson('.maestro/estado.json', state, { spaces: 2 });
+}
+```
+
+## 2. Identificar último artefato
+
+- Use `faseAtual.artefatos` para encontrar o arquivo principal.
+- Se vazio, referencie o template padrão da fase (ex.: `docs/01-produto/PRD.md`).
+
+```javascript
+const arquivo = faseAtual.artefatos?.slice(-1)[0] || faseAtual.entregavel;
+const analise = analisarArquivo(arquivo);
+/* analise = {
+   secoesPreenchidas,
+   secoesFaltantes,
+   percentualCompleto,
+   proximaSecao
+} */
+```
+
+## 3. Mensagem de retomada
+
+```
+📋 **Retomando Fase {estado.faseAtual}/{estado.totalFases} - {faseAtual.nome}**
+- Especialista: {faseAtual.especialista}
+- Artefato: {arquivo}
+- Progresso: {analise.percentualCompleto}%
+- Última ação: {analise.ultimaSecao}
+- Próxima tarefa: {analise.proximaSecao}
+```
+
+## 4. Carregar contexto
+
+1. Consulte `content/guides/fases-mapeamento.md` para mapear fase → especialista/prompt/template/skills.
+2. Abra o especialista e prompt correspondentes. Ex.: fase 2 → `specialists/Especialista em Engenharia de Requisitos com IA.md` + `prompts/requisitos.md`.
+3. Carregue os templates associados (ver tabela) e compare com o artefato atual para detectar seções faltantes.
+4. Liste explicitamente na resposta quais arquivos serão atualizados (ex.: `docs/02-requisitos/requisitos.md`, `templates/matriz-rastreabilidade.md`).
+
+## 5. Retomar execução
+
+- Perguntar ao usuário se deseja continuar exatamente da próxima seção, revisar algo ou mudar o foco.
+- Ao continuar, seguir checklist da fase (regras em `content/rules/validation-rules.md`).
+
+## 6. Atualização de estado (manual)
+
+Quando terminar a sessão:
+- Atualizar `faseAtual.progresso` e `faseAtual.artefatos`.
+- Registrar nota no histórico, se necessário.
+- Atualizar `estado.metrica.ultimoComando = '/continuar-fase'`.
+- Chamar `salvarEstado(estado)` para persistir.

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`.