@fabioramos_02/create-esteira-gov 0.1.0 → 0.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fabioramos_02/create-esteira-gov",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Scaffold de esteira spec-driven multi-agente Claude para projetos gov MS (app, BI, dados, protótipo).",
   "type": "module",
   "bin": {

package/template/.claude/skills/especificar/SKILL.md

@@ -11,7 +11,7 @@ Transforma demanda solta em **spec** rastreável.
 **Produz:** `specs/NNNN-<slug>/spec.md` (base: `specs/_templates/spec.md`).
 
 ## Passos
-1. Pergunte só o crítico (máx. 3): objetivo, escopo, restrições.
+1. Pergunte só o crítico (máx. 3): problema real (não a solução pedida), escopo, restrições.
 2. Crie `specs/NNNN-<slug>/` (NNNN = próximo número sequencial).
 3. Preencha o template: objetivo único, escopo (inclui/não inclui), AC testáveis.
 4. Não invente requisito. Faltou info → registre como suposição explícita.

package/template/.claude/skills/planejar/SKILL.md

@@ -12,9 +12,10 @@ Desenha COMO construir, antes de escrever código.
 
 ## Passos
 1. Leia a spec e o preset.
-2. Defina camadas e a árvore de arquivos — cada arquivo com 1 responsabilidade e ≤ 250 linhas.
-3. Para cada arquivo: responsabilidade + entrada → saída.
-4. Defina ordem de execução e riscos.
+2. Liste 2–3 abordagens viáveis com tradeoffs (complexidade, manutenção, performance). Escolha UMA, justifique no contexto do preset e dos ACs, registre em "Decisão arquitetural / riscos" do plano.
+3. Defina camadas e a árvore de arquivos — cada arquivo com 1 responsabilidade e ≤ 250 linhas.
+4. Para cada arquivo: responsabilidade + entrada → saída.
+5. Defina ordem de execução e riscos. Inclua o raciocínio da abordagem escolhida vs. descartadas.
 
 ## Pronto quando
 - [ ] todo AC da spec coberto por algum arquivo

package/template/.claude/skills/validar/SKILL.md

@@ -14,6 +14,7 @@ Confere se o código cumpre a spec.
 1. Marque cada AC da spec como OK/NOK com evidência.
 2. Rode os gates: `preset.comandos.lint`, `preset.comandos.test`, limite de 250 linhas.
 3. Cheque DS: sem cor/espaçamento hardcoded.
+3.5. Registre dívida técnica: o que foi simplificado, o que quebraria com escala, o que o próximo dev não deve tocar sem contexto.
 4. Veredito: APROVADO só se todos os AC e gates passam.
 
 ## Pronto quando

package/template/specs/_templates/plano.md

@@ -18,5 +18,13 @@ src/...
 ## Ordem de execução
 1. ...
 
-## Riscos / decisões
+## Decisão arquitetural / riscos
+
+**Escolha:** <abordagem escolhida> — <justificativa em 1 linha baseada no preset/ACs>
+
+| Alternativa | Prós | Contras |
+|-------------|------|---------|
+|             |      |         |
+
+**Riscos:**
 - ...

package/template/specs/_templates/validacao.md

@@ -12,5 +12,8 @@
 - [ ] limite de 250 linhas ok
 - [ ] DS: sem cor/espaçamento hardcoded
 
+## Dívida técnica / riscos
+- <simplificação feita e quando vai doer>
+
 ## Veredito
 APROVADO / REPROVADO — <motivo; se reprovado, indicar a etapa para retorno>