@mir-code/specs-platform 1.0.1

package/assets/template/.agents/skills/test-strategy/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: test-strategy
+description: Estratégia de testes do projeto — matriz de cobertura por camada, os três níveis de gate (rápido/completo/build), co-location de teste na mesma task, o Test Adequacy Review (suficiente, não-raso, necessário, conforme) e a tabela de trapaças de verificação. Carregue ao refinar uma task que produz código testável e antes de fechar qualquer task de implementação.
+---
+
+# Estratégia de testes
+
+Duas regras governam tudo aqui:
+
+1. **O teste deriva da spec, nunca da implementação.** Escrever teste lendo o código e afirmando
+   o que ele já faz não prova nada — congela o bug junto com o comportamento.
+2. **Quem decide se a task passou é o runner, não o agente.** "Parece correto" não fecha task.
+   Gate verde fecha.
+
+## Matriz de cobertura por camada
+
+A matriz concreta — camada, tipo de teste, onde o teste mora e qual comando roda — está em
+[`.agents/project.md`](../../project.md), seção **Pacotes, testes e comandos**. Leia-a antes de
+decidir o tipo de teste de qualquer task.
+
+O que a matriz não dita, e vale em qualquer projeto:
+
+| Camada | Expectativa de profundidade |
+|---|---|
+| Use case / regra de negócio | 1:1 com os critérios de aceite; todo caminho triste listado tem teste |
+| Adapter / repositório | caminhos de query principais + tratamento de erro |
+| Rota / controller | toda rota tocada: feliz + cada caso listado + cada erro documentado |
+| Utilitário compartilhado | todos os ramos; em módulo de segurança, 1 caso positivo + 1 malicioso por função |
+| Lib / hook / helper puro | todos os ramos da função |
+| Tela / componente | fluxo feliz + erro + vazio, em cada breakpoint declarado |
+| Entidade, DTO, tipo, config, schema | nenhum teste próprio — só o gate de build |
+
+**A matriz é piso, não teto.** O alvo de profundidade vem dos critérios de aceite da task, não do
+que o repositório já tem. Mas nunca produza teste **menos** rigoroso que os existentes na mesma
+camada — o `project.md` indica qual módulo serve de referência de rigor.
+
+## Os três gates
+
+| Nível | Quando |
+|---|---|
+| **rápido** | task com teste unitário no pacote tocado |
+| **completo** | task com teste de integração/contrato, ou que toca 2+ pacotes |
+| **build** | última task da feature, ou task só de config/entidade/tipo |
+
+Os comandos de cada nível estão em [`.agents/project.md`](../../project.md), seção **Pacotes,
+testes e comandos** — incluindo a flag obrigatória do runner e qual comando roda o repositório
+inteiro.
+
+Regras do gate:
+
+- **Filtre pelo pacote tocado.** Rodar o repositório inteiro é caro; só o gate build da última
+  task justifica esse custo, e ainda assim prefira filtrar.
+- **Use a flag de execução única** que o `project.md` indica — sem ela o runner entra em watch mode
+  e trava o agente.
+- **Saída ≠ 0 = pare.** Corrija, rode de novo, não siga. Não existe "sigo e arrumo depois".
+- **Confira a contagem de testes** antes e depois. Caiu? algum teste foi deletado ou pulado —
+  investigue antes de qualquer coisa.
+- Task que não produz código testável (doc, config, tipo) declara `Gate: build` e roda o comando de
+  build do `project.md`.
+
+No refinamento, cada task declara os dois campos num bloco `<details>` de Testes:
+
+```markdown
+<details>
+<summary>Testes</summary>
+
+**Tipo:** unit · **Gate:** rápido (`<comando do pacote tocado, ver project.md>`)
+
+- [ ] `create-user-use-case.test.ts` cobre CADASTRO-01 a CADASTRO-04
+- [ ] caso malicioso por campo sanitizado
+
+</details>
+```
+
+## Co-location: o teste é da mesma task
+
+Task que cria ou altera camada com tipo de teste exigido **escreve esses testes na própria task**.
+Teste nunca é task separada.
+
+"Vai ser testado na task seguinte" é **adiamento de teste** — exatamente o anti-padrão que esta
+regra existe para impedir. Se o código de uma task só fica testável depois de outra, o recorte das
+tasks está errado. Resolva assim:
+
+- **Junte para a frente:** mova os testes para a primeira task em que eles rodam (ex.: a task de
+  wiring inclui o wiring **e** os testes de contrato da rota que ela habilita).
+- **Junte para trás:** absorva a dependência bloqueante na task atual (ex.: a task da rota inclui o
+  próprio registro no módulo).
+
+Escolha o que mantiver as tasks atômicas e coesas. O objetivo é único: **nenhuma task produz código
+não verificado.**
+
+## Integridade de teste — restrições duras
+
+Nunca, em nenhuma circunstância:
+
+- enfraquecer uma asserção para ela passar;
+- deletar um caso de teste para reduzir falha;
+- usar `.skip`, `.todo`, `it.skip`, `describe.skip` ou equivalente para contornar teste vermelho;
+- alterar o teste depois para acomodar a implementação.
+
+Teste genuinamente errado (afirma comportamento que contraria a spec)? **pare e pergunte** antes de
+mexer. O teste é a spec executável; a implementação se conforma a ele, não o contrário.
+
+## Test Adequacy Review
+
+Roda **antes de fechar a task** (antes do halt, no `feature-runner`/`refinement-runner`). Quatro
+checagens; qualquer uma falha = reescreva e rode o gate de novo.
+
+### A — Suficiente (cobertura com evidência)
+
+Monte a tabela. **Evidence-or-zero:** critério sem `file:line` **e** sem a expressão da asserção
+conta como **NÃO coberto**. Não declare um critério ausente sem antes procurar — mostre a busca.
+
+| Critério (ID EARS) | `file:line` + asserção | Desfecho definido na spec | Coberto? |
+|---|---|---|---|
+| CADASTRO-03 | `tests/unit/auth-use-cases.test.ts:88` — `expect(res.errorCode).toBe('CPF_ALREADY_REGISTERED')` | 409 + `CPF_ALREADY_REGISTERED` | ✅ |
+| CADASTRO-05 | — | não definido precisamente na spec | ⚠️ lacuna de precisão |
+
+**Checagem ancorada na spec:** não basta existir asserção — o **valor afirmado** tem que ser o
+desfecho que a spec define. Onde a spec não define valor preciso, marque `⚠️ lacuna de precisão` e
+registre; nunca passe asserção vaga como se fosse cobertura.
+
+### B — Não-raso (litmus)
+
+Rejeite:
+
+- teste sem asserção, ou tautologia (`expect(true).toBe(true)`);
+- "não lançou erro" como única asserção — salvo quando não lançar **é** o comportamento especificado;
+- asserção só na contagem de chamadas do mock quando o critério exige o resultado;
+- só caminho feliz quando a task lista caso de erro ou de borda.
+
+**Regra do payload/conjunção.** Para cada campo nomeado de um evento emitido, objeto retornado ou
+registro persistido: (1) abra o objeto construído no `file:line`; (2) confirme que a asserção mira
+o **valor ou estado** do campo, não a chamada que o produziu; (3) `emit(...)` / `save(...)` presente
+não prova o campo — só a asserção sobre o resultado prova; (4) afirmar que um método foi chamado
+≠ afirmar o estado resultante. Os dois podem ser necessários; nenhum substitui o outro.
+
+**Litmus geral:** a asserção é rasa se **passaria com uma implementação plausivelmente errada**.
+Passou nesse teste? fortaleça antes de commitar.
+
+### C — Necessário (mapeamento reverso)
+
+Todo teste mapeia de volta para um critério de aceite, um caso de borda listado ou um item do
+escopo. O que não mapeia para nada → **remova**.
+
+| `file:line` + asserção | Mapeia para | Manter? |
+|---|---|---|
+| `tests/unit/cpf.test.ts:12` — `expect(isValidCpf('...')).toBe(false)` | CADASTRO-02 | ✅ |
+
+Não escreva teste especulativo "e se...", não teste comportamento de framework ou de biblioteca, e
+não duplique numa camada a asserção que outra camada já faz para o mesmo cenário.
+
+### D — Conforme
+
+Os testes seguem as convenções do repositório — nome do arquivo, path, idioma do código e runner
+estão em [`.agents/project.md`](../../project.md). Cite no relatório qual convenção seguiu.
+
+**Limite:** o teste prova o trabalho, não o expande. O repositório é o **piso** de rigor; os
+critérios de aceite são o **teto** de escopo. Não invente requisito nem teste sem âncora.
+
+## Trapaças de verificação (falha automática)
+
+| Trapaça | Por que falha |
+|---|---|
+| Fechar a task antes do gate passar | pula o verificador determinístico; o gate não é opcional |
+| Afirmar contagem de chamada em vez do estado resultante | prova que o método rodou, não que fez a coisa certa |
+| Marcar critério coberto sem citar `file:line` | viola evidence-or-zero; suspeita de cobertura não é cobertura |
+| Enfraquecer asserção para forçar o verde | move a trave em vez de consertar o código |
+| Deletar ou pular teste para a suíte passar | destrói cobertura permanentemente; teste vermelho é sinal, não ruído |
+| "Testado em outro lugar" sem citar onde | lacuna escondida atrás de afirmação vaga |
+| Teste especulativo sem âncora em critério | expande escopo além do teto; remova no Check C |
+| Testar comportamento de framework/lib | testa dependência, não a feature; remova no Check C |
+
+Esta review é inspeção — julgamento de modelo. Ela **complementa** o gate (que prova que a suíte
+roda) e o sensor de discriminação da skill `verification` (que prova que a suíte detecta
+regressão). Nenhuma das três substitui as outras.

package/assets/template/.agents/skills/verification/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: verification
+description: Verificação independente antes do halt — sub-agente Verifier (autor ≠ verificador), cobertura re-derivada com evidence-or-zero, sensor de discriminação por injeção de falha em git worktree descartável, o relatório de validação e o loop limitado de correção. Carregue antes do halt de qualquer task que produza código com teste automatizado.
+---
+
+# Verificação independente
+
+O agente que escreveu o código e os testes é o **autor**. Autor conferindo o próprio trabalho
+reaplica o mesmo modelo mental que produziu as lacunas — e não as vê. Por isso a verificação é
+delegada a um **sub-agente novo**, que re-deriva a cobertura a partir dos critérios de aceite, sem
+herdar o raciocínio de quem implementou.
+
+Essa separação é o portão de qualidade. Não é preferência de estilo.
+
+## Quando roda
+
+Depois da última task implementada e **antes** do relatório de halt, sempre que a entrega produziu
+código com teste automatizado. O resultado vira uma seção do relatório de halt — o code review
+humano recebe uma tabela de evidência em vez de prosa.
+
+**Não roda** em: task só de documentação, só de config/infra sem lógica, ou ajuste visual puro
+(nesse caso quem verifica é o E2E, conforme o `project.md`).
+
+O Verifier é **read-only** sobre a árvore real: ele não escreve, não corrige e não commita.
+
+## Como delegar
+
+Um `Agent` (Claude Code) / `Task` (Cursor) novo, com o payload:
+
+- os critérios de aceite da task (com os IDs, se houver) — **a fonte de verdade**;
+- o range de diff da entrega (`git diff --stat` do working tree, ou o range de commits);
+- os arquivos de teste no escopo;
+- esta skill como checklist de operação;
+- a matriz de cobertura e o comando de gate da skill `test-strategy`.
+
+## 1. Cobertura ancorada na spec (evidence-or-zero)
+
+Para cada critério de aceite, o Verifier monta:
+
+| Critério (ID / EARS) | Desfecho definido na spec | `file:line` + asserção | Resultado |
+|---|---|---|---|
+| CADASTRO-03 | 409 + `CPF_ALREADY_REGISTERED` | `src/__tests__/unit/auth-use-cases.test.ts:88` — `expect(res.errorCode).toBe('CPF_ALREADY_REGISTERED')` | ✅ |
+| CADASTRO-07 | — | — | ❌ sem evidência |
+
+Regras:
+
+- **Sem `file:line` + expressão da asserção, o critério conta como NÃO coberto.** Nome do `it(...)`
+  não é evidência; a expressão da asserção é.
+- Onde a spec define desfecho preciso, a asserção tem que mirar **aquele** valor. Asserção que
+  existe mas afirma outra coisa é lacuna, não cobertura.
+- Onde a spec **não** define desfecho preciso, marque `⚠️ lacuna de precisão na spec` e reporte.
+  Não passe asserção vaga como cobertura.
+- Antes de declarar um critério descoberto, mostre a busca feita (`Grep` no arquivo de teste).
+  Ausência declarada sem busca é chute.
+
+## 2. Gate
+
+Rode o gate de build da `test-strategy` para os pacotes tocados e registre: total, passou, falhou,
+pulado (cada `skip` com justificativa), e a **variação da contagem** de testes em relação ao estado
+anterior. Contagem que caiu sem justificativa é achado, não detalhe.
+
+## 3. Sensor de discriminação
+
+Gate verde prova que a suíte **roda**. O sensor prova que ela **detecta regressão**.
+
+### Procedimento
+
+1. **Baseline.** Rode `git status --porcelain` e guarde a saída. Ela tem que estar idêntica no fim.
+2. **Scratch isolado.** Crie um worktree descartável:
+   ```bash
+   git worktree add <prefixo do project.md> HEAD
+   ```
+   Sem worktree disponível: copie só os arquivos afetados para um diretório temporário e mute as
+   cópias.
+   **Proibido `git stash`.** O stash grava o estado *antes* da mutação; dar `pop` depois não
+   reverte a mutação aplicada em seguida, e numa árvore limpa ele nem cria entrada — a falha fica
+   na árvore real.
+3. **Injete a falha** no scratch, no código novo desta entrega. Escolha proporcional ao risco:
+   - inverter condição booleana (`if (x)` → `if (!x)`, `>` → `>=`);
+   - mudar valor de retorno (status errado, campo errado, zero no lugar do calculado);
+   - erro de um (deslocar limite de loop, índice de slice);
+   - remover side-effect exigido pela spec (apagar uma chamada de persistência ou de log).
+4. **Rode os testes que cobrem o código mutado**, apontando para o scratch.
+5. **Confirme que o mutante morreu** (os testes FALHAM). Descarte:
+   ```bash
+   git worktree remove --force <prefixo do project.md>
+   ```
+6. **Confirme o isolamento.** `git status --porcelain` na árvore real tem que bater com o baseline
+   do passo 1. Divergiu? **pare**, restaure a árvore e trate a rodada do sensor como inválida.
+7. **Mutante sobrevivente** (testes continuam verdes com a falha injetada) = o teste não discrimina
+   aquele comportamento. Vira item de correção **antes** do halt.
+
+### Profundidade
+
+| Contexto | Mutações |
+|---|---|
+| Padrão | 1 a 3, focadas no código novo de maior risco |
+| Caminho crítico — pagamento, autenticação, consulta veicular, integridade de dado | ≥5, cobrindo todos os ramos |
+
+## 4. Relatório
+
+O Verifier devolve ao agente que o disparou:
+
+```markdown
+## Verificação — <task> — PASS ✅ | FAIL ❌
+
+**Cobertura ancorada na spec:** <N/N critérios com desfecho batendo> | <M lacunas de precisão>
+**Gate:** <X passou, Y falhou> (contagem antes: <A> → depois: <B>)
+**Sensor:** <N mutações, N mortas, N sobreviventes>
+
+| Critério | Desfecho na spec | `file:line` + asserção | Resultado |
+|---|---|---|---|
+
+| Mutação | `file:line` | O que mudou | Morreu? |
+|---|---|---|---|
+
+**Lacunas, por severidade:**
+1. <lacuna> — <critério> — <file:line ou "sem evidência">
+```
+
+Esse bloco entra **integral** no relatório de halt, como seção `### Verificação independente`.
+
+## 5. Loop de correção
+
+`FAIL` ⇒ o agente autor corrige as lacunas na ordem reportada e **redispara um Verifier novo**
+(não reaproveite o anterior: ele já viu a resposta).
+
+**Máximo de 3 rodadas** correção → reverificação. Persistindo lacuna na quarta, **pare e escale ao
+usuário** com o que foi tentado. Não fique iterando.
+
+## 6. Blast radius
+
+Aprovar spec ou escopo autoriza **implementação local** e nada mais; o commit só acontece após um **"Complete"** explícito, pedido uma vez só no fim de tudo. Não autoriza
+`git push --force`, deploy, migration em produção, nem nenhuma operação externamente visível ou
+destrutiva — cada uma dessas exige go-ahead explícito **para aquela ação**, mesmo que a execução já
+tenha sido aprovada.
+
+## Se não houver como rodar sub-agente
+
+Rode o mesmo checklist você mesmo, mas **do zero**: releia os critérios de aceite e o diff
+ignorando o que você lembra da implementação, aplique evidence-or-zero, rode o sensor, e declare no
+relatório: *"Verificação executada pelo próprio autor (sub-agente indisponível) — o portão autor ≠
+verificador não foi satisfeito."* O usuário precisa saber que a garantia foi mais fraca.

package/assets/template/.specs/config.json

@@ -0,0 +1,39 @@
+{
+  "agent": {
+    "cli": "claude",
+    "commands": {
+      "claude": "claude {model} {effort} --agent feature-runner \"{prompt}\"",
+      "cursor": "cursor-agent {model} \"Use the feature-runner subagent. {prompt}\""
+    },
+    "modelsCommand": {
+      "cursor": "cursor-agent --list-models"
+    },
+    "models": {
+      "claude": [
+        "opus",
+        "sonnet",
+        "haiku",
+        "fable"
+      ]
+    },
+    "openTerminal": "osascript",
+    "cwd": ".",
+    "scopes": {
+      "feature": "Execute a feature \"{featureTitle}\" ({featurePath}). Se houver task em progresso, continue de onde parou; senão, escolha a próxima task em pages[] do meta.json.",
+      "featureNoPause": "Execute a feature \"{featureTitle}\" ({featurePath}) por inteiro, sem pausar entre tasks. Continue executando cada próxima task pendente do meta.json automaticamente até completar todas. NÃO commite nada em nenhum momento: nenhum commit por task, nenhum push. Deixe todas as alterações de todas as tasks no working tree, sem commit, para um único code review no final. Os testes E2E e a solicitação de code review devem ser feitos apenas ao final de todas as tasks.",
+      "task": "Execute a task {featurePath}{task}.md. Se já houver trabalho em progresso nela, continue de onde parou."
+    },
+    "defaultExecutionMode": "inline",
+    "sound": true
+  },
+  "prototype": null,
+  "review": {
+    "openCommand": "cursor --goto {path}:{line}"
+  },
+  "theme": "dark",
+  "warnBelowWidth": 1024,
+  "featuresDir": ".specs/specs",
+  "discoveriesDir": ".specs/discoveries",
+  "drawingsDir": ".specs/drawings",
+  "port": 4321
+}

package/assets/template/.specs/discoveries/meta.json

@@ -0,0 +1,4 @@
+{
+  "title": "Discoveries",
+  "pages": []
+}

package/assets/template/.specs/drawings/meta.json

@@ -0,0 +1,4 @@
+{
+  "title": "Desenhos",
+  "pages": []
+}

package/assets/template/.specs/specs/_templates/task-backend.md

@@ -0,0 +1,75 @@
+---
+title: "Backend"
+description: "<Descrição curta do que essa tarefa entrega na camada de API/serviço.>"
+status: pending
+---
+
+## Contexto da alteração
+
+<Por que esta task existe: como funciona hoje, o que passa a funcionar diferente e o que o
+usuário percebe (ou não percebe). 2 a 4 parágrafos curtos, sem detalhe de implementação.>
+
+**Depende de:**
+
+- [<Título da task>](./feat-<slug>-<task>.md) — <o que ela entrega para esta>
+
+## Visão Técnica
+
+```mermaid
+flowchart TB
+  A["<Componente alterado>"]:::changed
+  B["<Componente novo>"]:::added
+  C["<Componente removido>"]:::removed
+  D["<Componente inalterado, só contexto>"]:::untouched
+  D --> A --> B
+
+  classDef changed fill:#3b2f00,stroke:#eab308,color:#fde68a
+  classDef added fill:#052e1a,stroke:#22c55e,color:#bbf7d0
+  classDef removed fill:#3b0d0d,stroke:#ef4444,color:#fecaca
+  classDef untouched fill:#151515,stroke:#2a2a2a,color:#9ca3af
+```
+
+> 🟡 alterado · 🟢 adicionado · 🔴 removido · ⚪ inalterado (contexto)
+
+### O que muda, em resumo
+
+| # | Mudança | Efeito |
+|---|---------|--------|
+| 1 | <mudança> | <efeito prático> |
+
+### Detalhamento técnico
+
+<details>
+<summary><Recorte 1 — ex: Endpoint, Regra de negócio, Persistência></summary>
+
+<Explicação do recorte seguida dos critérios de aceite verificáveis dele.>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Segurança e sanitização de inputs</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Testes</summary>
+
+- [ ] ...
+
+</details>
+
+## Escopo
+
+- ...
+
+### Fora de escopo
+
+- ...
+
+## Code Review Checklist
+
+- [ ] ...

package/assets/template/.specs/specs/_templates/task-frontend.md

@@ -0,0 +1,89 @@
+---
+title: "Frontend"
+description: "<Descrição curta do que essa tarefa entrega na camada de UI.>"
+status: pending
+---
+
+## Contexto da alteração
+
+<Por que esta task existe: qual tela/fluxo existe hoje, o que passa a existir e o que o usuário
+ganha com isso. 2 a 4 parágrafos curtos, sem detalhe de implementação.>
+
+**Depende de:**
+
+- [<Título da task>](./feat-<slug>-<task>.md) — <o que ela entrega para esta>
+
+## Visão Técnica
+
+```mermaid
+flowchart TB
+  A["<Página/componente alterado>"]:::changed
+  B["<Componente novo>"]:::added
+  C["<Componente removido>"]:::removed
+  D["<API/DAL consumida, inalterada>"]:::untouched
+  D --> A --> B
+
+  classDef changed fill:#3b2f00,stroke:#eab308,color:#fde68a
+  classDef added fill:#052e1a,stroke:#22c55e,color:#bbf7d0
+  classDef removed fill:#3b0d0d,stroke:#ef4444,color:#fecaca
+  classDef untouched fill:#151515,stroke:#2a2a2a,color:#9ca3af
+```
+
+> 🟡 alterado · 🟢 adicionado · 🔴 removido · ⚪ inalterado (contexto)
+
+### O que muda, em resumo
+
+| # | Mudança | Efeito |
+|---|---------|--------|
+| 1 | <mudança> | <efeito prático para o usuário> |
+
+### Detalhamento técnico
+
+<details>
+<summary><Seção/componente 1></summary>
+
+<Estrutura, hierarquia e comportamento + critérios de aceite.>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Responsividade (Desktop · Tablet · Mobile)</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Estados de UI — loading, erro, vazio</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Acessibilidade e animações</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Testes E2E</summary>
+
+- [ ] ...
+
+</details>
+
+## Escopo
+
+- ...
+
+### Fora de escopo
+
+- ...
+
+## Code Review Checklist
+
+- [ ] ...

package/assets/template/.specs/specs/_templates/task-integracao.md

@@ -0,0 +1,72 @@
+---
+title: "Integração"
+description: "<Descrição curta da integração front↔back e validação fim-a-fim.>"
+status: pending
+---
+
+## Contexto da alteração
+
+<Que pontas já existem separadas, o que falta ligar e como fica o fluxo completo depois.>
+
+**Depende de:**
+
+- [<Feature> — Frontend](./feat-<slug>-frontend.md) — <o que entrega>
+- [<Feature> — Backend](./feat-<slug>-backend.md) — <o que entrega>
+
+## Visão Técnica
+
+```mermaid
+flowchart LR
+  FE["<Tela/componente>"]:::changed
+  API["<Cliente HTTP em api/>"]:::added
+  BE["<Endpoint>"]:::untouched
+  FE --> API --> BE
+
+  classDef changed fill:#3b2f00,stroke:#eab308,color:#fde68a
+  classDef added fill:#052e1a,stroke:#22c55e,color:#bbf7d0
+  classDef removed fill:#3b0d0d,stroke:#ef4444,color:#fecaca
+  classDef untouched fill:#151515,stroke:#2a2a2a,color:#9ca3af
+```
+
+> 🟡 alterado · 🟢 adicionado · 🔴 removido · ⚪ inalterado (contexto)
+
+### O que muda, em resumo
+
+| # | Mudança | Efeito |
+|---|---------|--------|
+| 1 | <mudança> | <efeito prático> |
+
+### Detalhamento técnico
+
+<details>
+<summary>Wire frontend ↔ backend</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Cenários E2E</summary>
+
+- [ ] ...
+
+</details>
+
+<details>
+<summary>Validações manuais</summary>
+
+- [ ] ...
+
+</details>
+
+## Escopo
+
+- ...
+
+### Fora de escopo
+
+- ...
+
+## Code Review Checklist
+
+- [ ] ...