iron-edge 2.3.1 → 2.3.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iron-edge",
-  "version": "2.3.1",
+  "version": "2.3.2",
   "description": "Ecossistema de agentes para Claude Code: 44 agentes de topo, 18 squads e 14 skills, com quality gate, memoria e instalador que nunca sobrescreve.",
   "keywords": [
     "claude",
@@ -25,7 +25,8 @@
     "iron-routing-map.md",
     "docs/",
     "!docs/interno",
-    "!docs/historico"
+    "!docs/historico",
+    "!**/_auditoria"
   ],
   "engines": {
     "node": ">=18.0.0"

package/skills/escada/SKILL.md

@@ -27,8 +27,14 @@ Nunca assuma quais modelos a conta do usuário tem — contas diferem. Conduza,
 **DIA A DIA** (feature, ajuste, bug): planejar no plan mode → executar no EXECUTOR → revisar no JULGADOR se a coisa for séria. Se `opusplan` apareceu na lista, `/model opusplan` automatiza exatamente isso — é o único caso em que `/model` é bem-vindo, porque aí mudar o padrão É a intenção.
 
 **DEMANDA ESTRUTURAL** (desenhar um sistema, arquitetura, decisão cara de errar) — o fluxo das TRÊS ABAS do terminal:
-- aba 1: JULGADOR planeja e **salva o plano num ARQUIVO**;
-- aba 2: EXECUTOR executa lendo o arquivo. Sobe um degrau em DOIS casos apenas: implementação pesada em si, ou o EXECUTOR travou 2 vezes no mesmo ponto. Regra de bolso: **sonnet até travar, degrau acima pra destravar** — e subir é FECHAR a aba e abrir outra com `claude --model "opus"`, nunca `/model` na aba aberta;
+- aba 1: JULGADOR planeja e **salva o plano num ARQUIVO**, com a **data no cabeçalho** (formato AAAA-MM-DD, que é o que o git lê sem ambiguidade). O plano só merece confiança se tiver três seções: **(a) arquivos exatos** (caminho + o que muda em cada um), **(b) checklist de gates** com `[ ]`, **(c) validação de ponta a ponta** no app/tela real, com o estado esperado. Sem isso o executor vai ter que explorar tudo de novo, e a economia some;
+- aba 2: EXECUTOR executa lendo o arquivo, sob o **bilhete do executor** (vai junto com o pedido "executa o plano: <caminho>"):
+  - **Confie no plano. Só escreva o código.** O JULGADOR já mapeou o projeto; não gastar esta aba relendo arquitetura nem redescobrindo o plano. Ler só os arquivos que o plano lista. Antes de começar, uma checagem só: o código mudou desde a data do cabeçalho do plano? Em projeto com git, `git status` (mudança não commitada) + `git log --since=<data do cabeçalho>` (commits). Sem git, ou se o comando falhar: pular a checagem e escrever isso no relatório. Pular a checagem NÃO libera explorar: a lista de arquivos do plano continua valendo. Só o arquivo que a checagem mostrou alterado pode ser aberto fora da lista, e vai registrado no relatório.
+  - **O plano inteiro, de uma vez.** Sem entregar um pedaço e perguntar "continuo?": cada ida e volta reenvia a conversa inteira, e é isso que gasta.
+  - **PRONTO só quando funcionou de verdade.** Teste de código verde não é PRONTO. PRONTO é o checklist do plano todo marcado `[x]`, incluindo a validação de ponta a ponta na tela real. Gate que só o humano fecha (cartão, celular, login) vai pro fim do relatório como passo dele.
+  - **O que não está no plano não vira código**: vira pendência escrita. Trecho impossível ou desatualizado: executar todo o resto e registrar o que travou, com o motivo. Nunca inventar caminho alternativo em silêncio.
+  - Por que isso economiza: o executor desperdiça em três lugares (reler o projeto que já foi lido, fatiar a entrega, e declarar pronto cedo demais, o que abre uma sessão de correção que relê tudo de novo). O bilhete fecha os três.
+  - Sobe um degrau em DOIS casos apenas: implementação pesada em si, ou o EXECUTOR travou 2 vezes no mesmo ponto. Regra de bolso: **sonnet até travar, degrau acima pra destravar** — e subir é FECHAR a aba e abrir outra com `claude --model "opus"`, nunca `/model` na aba aberta;
 - aba 3: JULGADOR dá o veredito comparando entrega × plano.
 - O canal entre as abas é sempre um arquivo, nunca copiar e colar conversa.
 
@@ -53,10 +59,11 @@ Os agentes do Iron Edge já vêm com `model:` por cargo (opus = estrategista, so
 Depois da medição, grave no `~/.claude/CLAUDE.md` do usuário (backup antes se existir; se a seção `## ESCADA DE MODELOS` já existir, ATUALIZE inteira no lugar, nunca duplique) a seção com:
 - a regra de ouro;
 - os três degraus MEDIDOS desta conta;
-- o fluxo das 3 abas, com a instrução de salvar o plano em arquivo;
+- o fluxo das 3 abas, com a instrução de salvar o plano em arquivo (e as três seções que o plano precisa ter);
+- o bilhete do executor, pra acordar sozinho quando o usuário disser "executa o plano";
 - a vacina do /model;
 - e a ordem de SUGERIR SOZINHO: quando o usuário pedir pra desenhar sistema/arquitetura/decisão grande, avisar em 1 linha que é demanda estrutural e dar o comando da aba do JULGADOR pronto pra copiar; quando um planejamento desses terminar, salvar o plano em arquivo sem pedir e dizer o caminho; quando a execução terminar, lembrar do veredito.
 
 Mostre a seção pronta ANTES de salvar. Lembre o usuário: CLAUDE.md novo só vale em sessão nova (fechar e abrir).
 
-**Teste de que pegou** (sessão nova): o usuário pede algo estrutural sem citar modelo nenhum. Critério duplo: (a) o Iron reconheceu sozinho e sugeriu a escada; (b) a sugestão veio com o comando pronto pra copiar. Se respondeu direto sem sugerir, a seção não carregou — conferir arquivo e sessão nova antes de qualquer outra coisa.
+**Teste de que pegou** (sessão nova): o usuário pede algo estrutural sem citar modelo nenhum. Critério triplo: (a) o Iron reconheceu sozinho e sugeriu a escada; (b) a sugestão veio com o comando pronto pra copiar; (c) numa aba de execução, ao dizer "executa o plano: <caminho>", o Iron abriu só os arquivos da lista do plano, entregou de uma vez e fechou com o checklist marcado (ou com o que ficou aberto, nomeado). Se respondeu direto sem sugerir, a seção não carregou — conferir arquivo e sessão nova antes de qualquer outra coisa.

package/squads/squad-engineering/knowledge-base/escada-e-cargos.md

@@ -59,3 +59,8 @@ O método da casa manda avisar, em uma linha, quando a demanda é **estrutural**
 
 ## O canal entre sessões é o arquivo
 Quando o trabalho atravessa sessões — uma planeja, outra executa, outra dá o veredito — o canal é `docs/eng/`, nunca copiar e colar conversa. É por isso que o doc-first e a escada são a mesma coisa vista de dois ângulos: a pasta que este squad escreve é exatamente o canal que a escada exige.
+
+## O plano que o executor recebe, e o bilhete que vai junto
+A skill `escada` é a fonte desta regra; aqui é o resumo pro squad não divergir dela. Um plano que vai ser executado em OUTRA aba precisa de: **data no cabeçalho** (formato AAAA-MM-DD), **(a) arquivos exatos** (caminho + o que muda em cada um), **(b) checklist de gates** com `[ ]`, **(c) validação de ponta a ponta** na tela real, com o estado esperado. O documento de arquitetura deste squad tem o formato dele; quando ele vira o plano de uma execução em aba separada, fecha com essas três seções.
+
+Na aba de execução vale o **bilhete do executor**: confie no plano e só escreva o código (o planejador já mapeou o projeto); leia só os arquivos da lista, com uma checagem única no início de "o código mudou desde a data do plano?" (`git status` + `git log --since=<data>`; sem git, pular e registrar); entregue o plano inteiro de uma vez, sem "continuo?"; PRONTO só com o checklist marcado `[x]`, incluindo a validação na tela real; o que não está no plano vira pendência escrita, e trecho travado vira registro com motivo, nunca caminho alternativo em silêncio.

package/squads/squad-engineering/tasks/write-architecture.md

@@ -22,6 +22,9 @@ teto: duas páginas, ADRs à parte
 
 6. **Apresente e espere a aprovação** antes de qualquer story ser escrita em cima.
 
+## Se este documento vai ser executado em OUTRA aba (escada de três abas)
+Feche-o com a data no cabeçalho (formato AAAA-MM-DD) e as três seções que o executor exige: arquivos exatos, checklist de gates `[ ]`, validação de ponta a ponta na tela real. A regra inteira está em `knowledge-base/escada-e-cargos.md`, seção "O plano que o executor recebe".
+
 ## Meça antes de entregar (não estime)
 
 Antes de apresentar o documento, **conte**. Instrução que depende de o autor achar que "ficou mais ou menos do tamanho" é instrução que falha: num teste real, um documento foi entregue como "perto do limite, mas dentro" e estava **acima** do teto quando medido.