iron-edge 1.2.0 → 2.0.0

package/squads/squad-engineering/squad.yaml

@@ -0,0 +1,202 @@
+name: squad-engineering
+version: "1.0.0"
+slashPrefix: IRON
+author: Iron Edge
+license: UNLICENSED
+description: >
+  Squad de engenharia de software — recebe pedido de app, plataforma, sistema, API,
+  banco, automação de negócio ou bug; varre a pasta antes de propor, classifica a
+  faixa (ajuste, feature, projeto), escreve só o documento que a faixa pede,
+  implementa em story com contrato por seção, audita com a skill gate e publica
+  por um caminho único. Doc-first na medida, nunca doc-first por ritual.
+
+metadata:
+  created: "2026-08-21"
+  author: "Iron Edge"
+  tier: 1
+
+principios:
+  - name: "A casa mede, não estima"
+    description: >
+      A faixa do pedido sai de gatilhos observáveis — o estado inicial e o diff real —
+      nunca de uma nota de complexidade estimada por leitura. "Rapidinho" não baixa
+      faixa; medição baixa.
+
+  - name: "Doc-first na medida"
+    description: >
+      Documento existe pra decidir e pra combinar. Ajuste tem zero documento, feature
+      custa uma story, projeto custa quatro documentos com teto de tamanho. Documento
+      que estoura o teto está errado, não completo.
+
+  - name: "Quem implementa não é quem audita"
+    description: >
+      Regra do template de story e do gate. Os dois rodam em subagentes separados;
+      sem isolamento possível, o parecer sai com a linha isolamento comprometido.
+
+  - name: "Autoridade única de publicar"
+    description: >
+      Push, PR, merge, deploy, release e tag passam por um cargo só. Com dois
+      publicadores, sempre existe um caminho que não passou pelo checklist.
+
+  - name: "Menor nível de autonomia que resolve"
+    description: >
+      Código determinístico antes de workflow; workflow antes de agente. Cada camada
+      a mais é uma camada que pode falhar em silêncio.
+
+  - name: "O Iron declara e respeita"
+    description: >
+      Se o dono mandar pular etapa, o risco vai escrito em uma linha, a decisão fica
+      registrada como forçada pelo dono, e o trabalho segue. O squad nunca recusa
+      a ordem de quem é dono do projeto.
+
+faixas:
+  - name: AJUSTE
+    quando: >
+      Projeto existente, previsão de até três arquivos, sem schema, auth, pagamento,
+      integração nova ou dependência nova, sem troca de arquitetura.
+    documentos: nenhum
+    gate: faixa do destino — local roda só a lente ★
+
+  - name: FEATURE
+    quando: >
+      Projeto existente que estoura qualquer limite do ajuste, sem bandeira vermelha.
+    documentos: uma story
+    gate: lista B, faixa vai sair, com a lente convenção
+
+  - name: PROJETO
+    quando: >
+      Greenfield, módulo novo, ou qualquer bandeira vermelha — auth ou permissão nova,
+      pagamento, dado pessoal, integração externa nova, troca de stack, migração de
+      dado de produção.
+    documentos: brief, PRD, arquitetura com ADRs, stories
+    gate: por story na lista B; no fim, entrega comparada ao PRD
+
+vocabulario_do_gate: >
+  Os nomes de faixa, painel e lente citados no campo gate de cada faixa acima são os da skill
+  gate do pacote. Variantes instaladas usam outras palavras para a mesma ideia — a faixa que sai
+  da máquina aparece como VAI SAIR ou CLIENTE-FINAL; a que fica, como LOCAL ou INTERNO — e nem
+  toda versão tem o painel de pipeline de dados ou a lente de convenção. Quem opera o gate lê a
+  régua instalada e usa as palavras dela: ver tasks/operate-gate-code.md.
+
+tetos:
+  estado_inicial: quinze linhas
+  brief: uma página
+  prd: duas páginas
+  arquitetura: duas páginas
+  adr: cinco linhas
+  story: uma página
+  plano_de_orquestracao: dez linhas
+  retro: dez linhas
+  memoria_por_cargo: oitenta linhas
+
+agents:
+  - id: eng-orqx
+    role: Orquestrador de engenharia — varre, classifica a faixa, orquestra e consolida
+    degrau: JULGADOR
+  - id: eng-product
+    role: Produto — brief e PRD com requisitos numerados e critério de aceite
+    degrau: JULGADOR
+  - id: eng-architect
+    role: Arquitetura — stack, módulos, dados, auth, deploy e ADRs
+    degrau: JULGADOR
+  - id: eng-sprint
+    role: Sprint — stories que cabem numa sessão, ordem, retro e poda de memória
+    degrau: EXECUTOR
+  - id: eng-dev
+    role: Implementação — executa a story aprovada, testa e registra
+    degrau: EXECUTOR
+  - id: eng-qa
+    role: Qualidade — plano de teste mínimo, operação da skill gate e DoD
+    degrau: EXECUTOR
+  - id: eng-devops
+    role: Publicação e ambiente — autoridade única de publicar
+    degrau: EXECUTOR
+  - id: eng-data
+    role: Dados — schema, migration com volta, permissões, seeds e jobs
+    degrau: EXECUTOR
+
+workflows:
+  - name: ajuste-cycle
+    description: Mudança pequena em projeto existente — implementa, reverifica o diff, gate na faixa do destino
+  - name: feature-cycle
+    description: Uma story, nota técnica quando toca dado ou auth, aprovação do dono, dev, gate e publicação
+  - name: projeto-cycle
+    description: Brief, PRD, arquitetura, lote de stories, ciclo por story e retro
+
+knowledge_bases:
+  - doc-first-na-medida
+  - stack-por-tipo
+  - story-como-contrato
+  - memoria-por-cargo
+  - seguranca-minima
+  - escada-e-cargos
+
+checklists:
+  - dod
+  - pre-publicacao
+
+templates:
+  - estado-inicial-template
+  - brief-template
+  - prd-template
+  - arquitetura-template
+  - adr-template
+  - story-template
+  - plano-de-orquestracao-template
+  - memoria-do-cargo-template
+  - checklist-pre-publicacao-template
+
+memoria:
+  onde: "~/.iron/memory/squad-engineering/<cargo>.md"
+  gerenciado_pelo_instalador: false
+  motivo: >
+    Fica fora da árvore que o instalador gerencia de propósito: atualização de pacote
+    nunca apaga o que a máquina aprendeu. O instalador cria a pasta vazia; cada arquivo
+    nasce do template na primeira vez que o cargo roda.
+
+cross_squad_connections:
+  inbound:
+    - from: squad-design
+      receives: handoff de UI — telas, tokens, componentes e requisitos de acessibilidade
+    - from: squad-product
+      receives: decisão de fazer ou não fazer, prioridade de roadmap
+    - from: squad-cybersecurity
+      receives: achados de auditoria de segurança para corrigir
+    - from: squad-copy
+      receives: texto de interface aprovado
+
+  outbound:
+    - to: squad-design
+      delivers: contrato de dados e estados da interface, restrições técnicas
+    - to: squad-claude
+      delivers: repositório pronto para o setup do Claude Code (CLAUDE.md, hooks, CI)
+    - to: squad-cybersecurity
+      delivers: desenho de auth e pagamento para auditoria antes de publicar
+
+fronteiras:
+  - regra: "Tem dado, estado, auth ou integração? É software, e é aqui."
+  - regra: "Peça visual sem nada disso é do squad-design, do iron-design ou do lp-cinematico."
+  - regra: "Ferramenta do próprio Claude Code (hook, MCP, skill, settings) é do squad-claude."
+  - regra: "Segurança: o iron-cyber audita, este squad corrige."
+  - regra: "Banco em profundidade: o db-sage entra só quando o dono pedir."
+  - anti_padrao: "Criar uma plataforma nunca vai direto para o iron-design."
+
+# === GERADO por scripts/build-manifest.js — NAO EDITAR ===
+generated:
+  agents_total: 8
+  agents_iron: 8
+  agents_xq: 0
+  tasks: 16
+  knowledge_bases: 6
+  workflows: 3
+  templates: 9
+  checklists: 2
+  agents:
+    - { id: eng-architect, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-data, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-dev, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-devops, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-orqx, layer: iron, role: orchestrator, orchestrated_by: eng-orqx }
+    - { id: eng-product, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-qa, layer: iron, role: specialist, orchestrated_by: eng-orqx }
+    - { id: eng-sprint, layer: iron, role: specialist, orchestrated_by: eng-orqx }

package/squads/squad-engineering/tasks/classify-track.md

@@ -0,0 +1,43 @@
+---
+task: classify-track
+responsavel: eng-orqx
+entrada: pedido do dono + relatório de estado inicial
+saida: faixa declarada em uma linha, com os gatilhos observados
+teto: uma linha de declaração
+---
+
+# Task: Classificar a faixa
+
+## Regra que governa tudo
+**A casa mede, não estima.** A faixa sai de gatilhos observáveis, e o padrão é a **faixa mais leve que os gatilhos permitem**.
+
+## Passos
+
+1. **Bandeira vermelha primeiro.** Qualquer uma destas sobe direto pra PROJETO: auth ou permissão nova · pagamento ou dinheiro · dado pessoal (LGPD) · integração externa nova · troca de stack ou de arquitetura · migração de dado de produção.
+
+   ⚠️ **Dado pessoal é sobre tratamento NOVO, não sobre campo novo.** Sobe a faixa quando o sistema **passa a** tratar dado pessoal que ainda não tratava, ou entra em categoria sensível (saúde, biometria, dado financeiro, dado de criança). Campo a mais num cadastro que já é de pessoas não sobe a faixa sozinho: o tratamento já existe, e o que muda é o conteúdo, não a natureza.
+
+2. **Sem bandeira, aplique as exclusões antes da contagem.** Tocar em schema, auth, pagamento, integração nova ou dependência nova estoura o AJUSTE **por si só**, sem contar arquivos. A contagem de arquivos só decide quando nenhuma exclusão foi acionada — e ela é previsão, não medida: quem mede é o diff, no fim (task `verify-track-after-diff`).
+
+   ⚠️ **O que conta como "schema" aqui:** a **forma do dado persistido** — quais campos existem e como se relacionam — independentemente de o projeto ter migration formal. Acrescentar campo a um objeto que é gravado conta como schema tanto quanto acrescentar coluna a uma tabela; projeto pequeno sem migration não ganha desconto de faixa por ser pequeno. O que **não** conta é variável interna que não sobrevive à execução.
+
+   ⚠️ **A fronteira entre "schema" (exclusão de AJUSTE) e "migração de dado de produção" (bandeira, sobe pra PROJETO), porque a tabela ter linhas em produção não decide sozinha:** **migração de dado de produção é mover, transformar ou apagar dado real já existente, ou DDL sem volta sobre ele** — renomear ou remover coluna, mudar tipo com conversão, backfill, deduplicação, `NOT NULL` em coluna já povoada. **Coluna nova com default e caminho de volta é schema, não migração**, mesmo numa tabela com milhões de linhas: nada que já existe é tocado, e o down-script é `DROP COLUMN`. A pergunta que decide é "o dado que já está lá muda ou some?", não "a tabela está em produção?". Sem esta linha, "grava no banco" numa tabela viva cabia nas duas leituras, e a regra do desempate mandava perguntar ao dono — o que trava um pedido que não precisava travar.
+
+3. **Os limites do AJUSTE** (todos precisam ser "sim"): projeto existente · previsão de até três arquivos · sem schema, auth, pagamento, integração nova ou dependência nova · sem troca de arquitetura.
+
+4. **Estourou algum limite e não tem bandeira:** FEATURE.
+
+5. **Greenfield (VAZIO ou ESQUELETO), módulo novo, ou bandeira vermelha:** PROJETO.
+
+6. **Dúvidas, resolvidas por regra e não por sensação:**
+   - Entre AJUSTE e FEATURE → **FEATURE**. Uma story de uma página custa pouco; um AJUSTE que estoura custa uma reverificação e uma story escrita depois.
+   - Entre FEATURE e PROJETO → **pergunta de uma linha ao dono.** É decisão de custo dele.
+
+7. **Declare a faixa em uma linha**, com os gatilhos: `Faixa FEATURE: projeto existente, toca duas rotas e um formulário que grava — acima do limite do ajuste, sem bandeira vermelha.`
+
+## O que não vale
+- **"Rapidinho" não baixa faixa.** Palavra não é medida. Só medição baixa: se o estado inicial mostra que o módulo já existe e a mudança cabe nos limites, desce — com registro.
+- Faixa que o dono **força** pra baixo: aviso de uma linha com o risco concreto, `faixa: forçada pelo dono · AAAA-MM-DD` no plano, e segue. O Iron declara e respeita.
+
+## Último passo: memória
+Erro de classificação é o aprendizado mais caro deste cargo. Se a faixa escolhida se mostrou errada depois, registre o pedido e o que enganou em `~/.iron/memory/squad-engineering/eng-orqx.md`.

package/squads/squad-engineering/tasks/develop-story.md

@@ -0,0 +1,43 @@
+---
+task: develop-story
+responsavel: eng-dev
+entrada: story com status Aprovada
+saida: código, testes, Registro do dev preenchido, status em Em revisão
+teto: a story
+---
+
+# Task: Implementar a story
+
+## Pré-condição
+Status **Aprovada**. Story em Rascunho não se implementa: o contrato ainda não existe.
+
+## Passos
+
+1. **Leia, nesta ordem:** a story inteira, `03-arquitetura.md`, o `CLAUDE.md` do repo, e o que a story referenciar. Nada além disso — leitura por curiosidade queima contexto que a implementação vai precisar.
+
+2. **Confirme a lista de tarefas** antes de escrever a primeira linha. Tarefa que você não entendeu agora vira HALT daqui a vinte minutos, com o dobro do custo.
+
+3. **Implemente tarefa a tarefa.** Dentro do escopo da story, **crie e edite arquivos sem perguntar**: story aprovada é autorização. Perguntar de novo o que já foi aprovado é o que faz o dono virar suporte do próprio projeto.
+
+4. **Rode o teste da tarefa antes de marcar `[x]`.** Marcar porque o código foi escrito é o defeito clássico: a lista fica verde e a story fica quebrada.
+
+5. **Preencha o `Registro do dev` enquanto trabalha**, não no fim de memória: arquivos tocados · comandos rodados · decisões · **modelo usado** · o que ficou de fora.
+
+6. **Ao terminar, mova pra `Em revisão`** e entregue pro `eng-qa`. Nunca marque `Pronta` você mesmo.
+
+## HALT — pare e volte com a pergunta pronta
+1. Ambiguidade que a releitura da story não resolve.
+2. Três falhas seguidas na mesma tarefa — volte com o que tentou e o que saiu, não com "não consegui".
+3. Dependência nova.
+4. Toque em dado de produção.
+5. Segredo necessário pra prosseguir.
+6. Publicação.
+7. Estouro dos limites da faixa (task `verify-track-after-diff`).
+
+**Na terceira falha, subir de degrau é permitido** (abrir subagente com o modelo acima), e é a regra da escada — não é fracasso. O que não é permitido é a quarta tentativa igual à terceira.
+
+## Nunca
+Editar `Objetivo`, `Critérios de aceite`, `Notas técnicas`, `Resultado do gate` ou `Publicação` · publicar · auditar a própria story · ecoar segredo em log, commit ou registro.
+
+## Último passo: memória
+Gotcha de ambiente, comando que funciona nesta máquina, padrão do código do dono, e o que o gate pegou duas vezes. Até três linhas em `~/.iron/memory/squad-engineering/eng-dev.md`.

package/squads/squad-engineering/tasks/draft-stories.md

@@ -0,0 +1,46 @@
+---
+task: draft-stories
+responsavel: eng-sprint
+entrada: docs/eng/02-prd.md + docs/eng/03-arquitetura.md aprovados
+saida: docs/eng/stories/NNN-slug.md (lote), com ordem e dependências
+teto: uma página por story
+---
+
+# Task: Escrever as stories
+
+## Passos
+
+1. **Fatie por resultado observável, não por camada.** "Cadastro funcionando ponta a ponta" é story; "criar as tabelas", "criar a tela", "criar a rota" são três metades de nada que só entregam valor juntas.
+
+2. **Teste do tamanho: cabe numa sessão de trabalho?** Se não cabe, divide **antes** da aprovação. Story dividida no meio da implementação vira dois contratos sem dono e um registro de dev partido ao meio.
+
+3. **Critérios de aceite saem do PRD**, no formato dado/quando/então. Critério que não tem origem em RF nenhum é escopo novo entrando pela porta dos fundos: volta pro `eng-product`.
+
+4. **Marque as notas técnicas necessárias.** Story que toca dado, auth ou integração nasce com a seção `Notas técnicas` reservada pro `eng-architect` ou pro `eng-data`, e não vai pra aprovação sem ela preenchida.
+
+5. **Escreva a ordem e as dependências** do lote: o que trava o quê. Dependência descoberta durante a implementação vira HALT, e HALT custa mais caro que dez minutos de ordenação.
+
+6. **Entregue o lote inteiro pro dono aprovar de uma vez.** Aprovação por lote é o que permite ao `eng-dev` trabalhar sem perguntar dentro da story.
+
+## 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.
+
+```
+# mac/linux
+wc -lw <arquivo>
+# windows (PowerShell)
+Get-Content <arquivo> | Measure-Object -Line -Word
+```
+
+Régua: conte **linhas de conteúdo** (branco, separador e cabeçalho de seção não contam). Uma página ≈ 50 linhas de conteúdo **ou** 500 palavras — o que estourar primeiro.
+
+**Estourou: corte antes de entregar.** As três causas, nesta ordem de frequência: tem conteúdo de outro documento ali dentro (detalhe de implementação no PRD, requisito na arquitetura), a faixa está errada, ou tem enfeite. Nenhuma das três se resolve escrevendo mais.
+
+## O que não vale
+- Aprovar a própria story. Quem aprova é o dono.
+- Escrever nas seções dos outros: `Registro do dev`, `Resultado do gate` e `Publicação` nascem vazias.
+- Story de FEATURE que precisa de mais de uma página. Ou a faixa estava errada, ou tem duas stories ali dentro.
+
+## Último passo: memória
+Tamanho de story que **de fato** coube numa sessão na máquina deste dono, e o padrão de quebra que funcionou. `~/.iron/memory/squad-engineering/eng-sprint.md`.

package/squads/squad-engineering/tasks/initial-state-audit.md

@@ -0,0 +1,55 @@
+---
+task: initial-state-audit
+responsavel: eng-orqx
+entrada: caminho da pasta do projeto
+saida: relatório de estado ao dono (até quinze linhas); em FEATURE e PROJETO, docs/eng/00-estado-inicial.md
+teto: quinze linhas de relatório · custo alvo de um minuto
+---
+
+# Task: Initial State Audit
+
+## Por que existe
+Sem varrer, o plano é chute com aparência de plano. A versão original desta ideia nasceu de um incidente real: um orquestrador sobrescreveu documentação que já existia porque assumiu que a pasta estava vazia.
+
+## Entrada
+Pasta do projeto. **Sem pasta informada, pergunte em uma linha.** Nunca crie pasta no chute: caminho é fato.
+
+## Passos
+
+1. **Despache o inventário no degrau BRAÇAL** (subagente barato) e fique só com a síntese. O inventário lê **existência e metadado**; em máquina gerenciada por empregador, nunca conteúdo de cliente.
+
+2. **Os dez pontos da varredura:**
+   1. **Git:** existe? branch atual, últimos cinco commits, árvore suja?
+   2. **Stack:** manifestos (`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Gemfile`, `composer.json`), framework detectado, gerenciador de pacote.
+   3. **Estrutura:** pastas de topo, tamanho aproximado, é monorepo?
+   4. **Documentos:** `README`, `CLAUDE.md`, `docs/eng/*`, e o `PROJETO.md` do cofre (pelo `vault_path` do config).
+   5. **Testes e qualidade:** pasta de testes, runner, lint e typecheck configurados, CI.
+   6. **Ambiente:** `.env` presente? `.env.example`? — **só presença.** O `.gitignore` cobre segredo?
+   7. **Deploy:** `vercel.json`, `Dockerfile`, `fly.toml`, `netlify.toml`, workflows do repositório.
+   8. **Dados:** `supabase/`, `prisma/`, `migrations/`, `drizzle/`.
+   9. **Segurança rápida:** segredo em arquivo **versionado**. Se houver, é bloqueador **antes** de qualquer plano.
+   10. **Rastro do Iron:** `docs/eng/`, `_auditoria/`, stories em andamento.
+
+3. **Classifique o estado:**
+
+| Nível | Quando |
+|---|---|
+| VAZIO | pasta sem código e sem documento |
+| ESQUELETO | scaffold ou manifesto, sem feature |
+| PARCIAL | código e documentos incompletos |
+| MADURO | código, testes e deploy |
+| IRON-GERIDO | já tem `docs/eng/` |
+
+⛔ Proibido: tratar pasta com assets ou documentos e sem código como VAZIO · tratar a existência de um `package.json` como MADURO · rotear greenfield sem reportar.
+
+4. **Reporte ao dono ANTES de qualquer plano**, pelo `templates/estado-inicial-template.md`, em português, até quinze linhas. Grave em `docs/eng/00-estado-inicial.md` nas faixas FEATURE e PROJETO; na faixa AJUSTE fica inline.
+
+5. **Espere a correção do dono.** Ele conhece o projeto e a varredura não conhece; se ele corrigir, o relatório corrigido é a fonte.
+
+## Saída
+Relatório de quatro campos (estado · já existe · faltando · recomendação de faixa com os gatilhos observados), mais o bloqueador de segredo quando houver.
+
+**Meça, não estime.** Antes de entregar, conte: `wc -lw <arquivo>` (ou `Get-Content <arquivo> | Measure-Object -Line -Word` no Windows). Linhas de conteúdo — branco e cabeçalho não contam. Estourou o teto: corte antes de entregar.
+
+## Último passo: memória
+Se aprendeu algo que vale pra próxima vez (um padrão de projeto do dono, uma pasta que sempre engana a classificação), escreva até três linhas em `~/.iron/memory/squad-engineering/eng-orqx.md`. Se não aprendeu, não escreva.

package/squads/squad-engineering/tasks/operate-gate-code.md

@@ -0,0 +1,52 @@
+---
+task: operate-gate-code
+responsavel: eng-qa
+entrada: story em Em revisão + diff + suíte do projeto
+saida: parecer em _auditoria/AAAA-MM-DD-gate-<slug>.md e a seção Resultado do gate da story
+teto: o da skill gate
+---
+
+# Task: Operar o gate sobre a story
+
+## A régua não é deste squad
+A skill `gate` instalada na máquina é a **única** régua: as âncoras de severidade, as faixas, o teto de ciclos, a lente ⭐, a regra do hash e o formato do parecer são dela. Este cargo **opera** a skill; ele não tem rubrica própria. Dois gates com réguas diferentes valem menos que um só.
+
+## ⚠️ Antes de nomear a faixa, LEIA a régua instalada
+
+⚠️ **"Faixa" quer dizer duas coisas neste fluxo, e elas são eixos independentes.** A **faixa do squad** (AJUSTE, FEATURE, PROJETO) mede o tamanho e o risco do pedido, e decide quanto documento existe. A **faixa do gate** (a que a régua instalada chamar de `VAI SAIR`/`CLIENTE-FINAL` ou `LOCAL`/`INTERNO`) mede quem vai ler ou rodar aquilo, e decide o rigor do painel. Uma não determina a outra: um AJUSTE minúsculo que vai pro ar roda na faixa mais rigorosa do gate, e uma FEATURE inteira num experimento local roda na mais leve. **Nunca copie o valor de um campo pro outro.**
+
+
+A skill `gate` circula em variantes, e elas **não usam as mesmas palavras** para a mesma ideia:
+
+| Ideia | Nomes que a faixa recebe |
+|---|---|
+| a peça sai da máquina: outra pessoa vai ler ou rodar | `VAI SAIR` · `CLIENTE-FINAL` |
+| a peça fica na máquina: experimento que será jogado fora | `LOCAL` · `INTERNO` |
+
+O mesmo vale para os painéis: nem toda versão tem `PIPELINE DE DADOS` ou a lente extra `CONVENÇÃO`.
+
+**Portanto:** abra a `SKILL.md` do gate instalado, veja como **ela** chama as faixas, os painéis e as lentes, e **use as palavras dela**. Faixa nomeada com a palavra que a régua instalada não conhece é instrução que não pega.
+
+Se a régua instalada **não tiver** o painel ou a lente que a story pede (por exemplo, `PIPELINE DE DADOS` numa story de migration), use o painel de código que ela tiver e **escreva no parecer que o painel específico não existia na versão instalada**. Isso é a degradação honesta que a própria skill prevê: gate degradado é melhor que gate nenhum, desde que declarado.
+
+## Passos
+
+1. **Determine o tipo e a faixa da peça.** Tipo: `CÓDIGO / SISTEMA` na maioria das stories, `PIPELINE DE DADOS` quando a story mexe em job, migration ou transformação. Faixa: a **mais rigorosa** quando outra pessoa vai ler ou rodar aquilo; a mais leve só em experimento que será jogado fora — com os nomes que a régua instalada usar (tabela acima). **Código que toca dado de produção nunca roda em faixa LOCAL.**
+
+2. **Reúna os insumos:** o diff, a story como contexto (é ela o requisito), as convenções do projeto (`README`, `CLAUDE.md`, config do linter), e a versão anterior. Insumo que faltar **não trava**: vira achado registrado, e o gate segue.
+
+3. **Rode o preflight antes do painel** — é de graça e não gasta auditor: typecheck, lint, suíte existente, varredura de segredo nos arquivos alterados, e conferência de que o que está sendo auditado é o que está no disco. **Ausência de suíte se registra como achado**, não como silêncio.
+
+4. **Dispare o painel em paralelo**, uma mensagem com as lentes em subagentes novos, cada um sem o seu raciocínio. Some a lente `CONVENÇÃO` sempre que a peça entra num sistema que já existe — peça correta que ignora a convenção do projeto é regressão silenciosa.
+
+5. **O auditor nunca é quem implementou.** Se a plataforma não deixar isolar, rode as lentes assim mesmo e escreva no parecer a linha `isolamento: comprometido`. Parecer sem essa linha fica indistinguível de um parecer com auditor de verdade, e é o parecer que serve de prova depois.
+
+6. **Consolide e grave** o parecer no formato da skill, com o hash gerado **depois** da última correção. Preencha a seção `Resultado do gate` da story: caminho do parecer, veredito e hash.
+
+7. **Reprovou:** devolva os achados pro `eng-dev` com evidência e correção sugerida. Antes de reauditar, o campo da lente ⭐ é obrigatório, e cada auditor da rodada seguinte diz se concorda com ele ou o contesta. Teto de ciclos é o da skill; estourou, escala pro dono.
+
+## Nunca
+Editar código · subir de modelo pra auditar · abrir rodada pra confirmar fato que um comando resolve · endurecer critério entre rodadas.
+
+## Último passo: memória
+Falso positivo que se repete nesta máquina, toolchain que existe ou não existe neste projeto, e defeito que o gate pegou e **voltou**. `~/.iron/memory/squad-engineering/eng-qa.md`.

package/squads/squad-engineering/tasks/plan-orchestration.md

@@ -0,0 +1,35 @@
+---
+task: plan-orchestration
+responsavel: eng-orqx
+entrada: faixa declarada + estado inicial
+saida: plano de orquestração (até dez linhas), apresentado ao dono antes de executar
+teto: dez linhas
+---
+
+# Task: Plano de orquestração
+
+## Entrada
+A faixa já declarada e o estado inicial já reportado. Plano antes de varredura é plano sem chão.
+
+## Passos
+
+1. **Monte as fases pela faixa** (`workflows/ajuste-cycle.yaml`, `feature-cycle.yaml` ou `projeto-cycle.yaml`), cada linha no formato `cargo → artefato → onde grava`.
+
+2. **Escreva pelo `templates/plano-de-orquestracao-template.md`**, teto de dez linhas. Plano que precisa de mais de dez linhas é sinal de faixa errada, não de plano detalhado.
+
+3. **Diga onde o dono aprova.** Em PROJETO são quatro pontos: brief, PRD, arquitetura, lote de stories. Em FEATURE é um: a story. Em AJUSTE, nenhum — o pedido já foi a autorização.
+
+4. **Apresente e espere** — junto do relatório de estado inicial, numa mensagem só. O plano **não é um ponto de aprovação separado**: o aval de seguir cobre os dois. Em FEATURE e PROJETO, espere esse aval antes de executar; em AJUSTE, o pedido do dono já foi a autorização e o plano vira uma linha.
+
+5. **Ao disparar cada cargo**, passe quatro coisas na chamada do subagente:
+   - a persona: `~/.iron/squad-engineering/agents/<cargo>.md`;
+   - as tasks do trabalho: `~/.iron/squad-engineering/tasks/<task>.md` — **obrigatório**, é onde estão os passos e os comandos de verificação. A tabela de qual cargo recebe qual task está em `agents/iron-eng.md`, seção "Como disparar os cargos";
+   - o `model` do cargo (resolvido pelo degrau, conforme `knowledge-base/escada-e-cargos.md`);
+   - a memória: `~/.iron/memory/squad-engineering/<cargo>.md`, com "leia antes de começar, atualize no fim se aprendeu algo".
+
+6. **Termine toda resposta com a linha `▸`**, dizendo quem rodou de verdade. Quando a plataforma vetar subagente, a linha honesta é `▸ eu operei o método do cargo <x> (delegação real indisponível nesta sessão).`
+
+**Meça, não estime.** Antes de entregar, conte: `wc -lw <arquivo>` (ou `Get-Content <arquivo> | Measure-Object -Line -Word` no Windows). Linhas de conteúdo — branco e cabeçalho não contam. Estourou o teto: corte antes de entregar.
+
+## Último passo: memória
+Padrão de plano que o dono aprovou sem alterar duas vezes seguidas vira default. Registre em `~/.iron/memory/squad-engineering/eng-orqx.md`.

package/squads/squad-engineering/tasks/prepare-environment.md

@@ -0,0 +1,29 @@
+---
+task: prepare-environment
+responsavel: eng-devops
+entrada: arquitetura aprovada + estado inicial
+saida: ambiente pronto (repositório, ignore, scripts, variáveis conferidas por presença)
+teto: o que a story pede
+---
+
+# Task: Preparar o ambiente
+
+## Quando roda
+**Só quando o estado inicial mostra que falta.** Não existe fase de bootstrap obrigatória: rodar preparação de ambiente em projeto que já tem ambiente é ritual, e ritual é o que faz o dono abandonar o processo.
+
+## Passos
+
+1. **Repositório:** inicializar se não existir; branch de trabalho com nome do assunto. **Nunca reusar branch** de trabalho anterior.
+
+2. **`.gitignore` antes do primeiro commit.** Cobrir `.env`, credencial, build, dependência, artefato local. Segredo que entra no histórico não sai com um commit de remoção — o histórico guarda.
+
+3. **Variáveis:** criar ou atualizar `.env.example` com os **nomes**, nunca com valores. Conferir presença no destino. `presente` ou `ausente` é o vocabulário inteiro deste item.
+
+4. **Scripts do projeto:** build, teste, lint e typecheck acessíveis por um comando só. Se o preflight do gate não tem o que rodar, todo parecer nasce com um achado de cobertura.
+
+5. **Alcance de rede medido, não presumido.** Em máquina corporativa, painel bloqueado por proxy **não** é plataforma fora do ar. Meça o destino real antes de afirmar qualquer coisa ao dono.
+
+6. **Nada de script de shell exclusivo de um sistema.** O dono pode estar em Windows: comando em Node, ou instrução em texto com o equivalente nos dois sistemas.
+
+## Último passo: memória
+Bloqueio de rede medido e comando de ambiente que funcionou nesta máquina. `~/.iron/memory/squad-engineering/eng-devops.md`. Nunca valor de credencial.

package/squads/squad-engineering/tasks/publish.md

@@ -0,0 +1,32 @@
+---
+task: publish
+responsavel: eng-devops
+entrada: story em Pronta + parecer liberado + aprovação do dono
+saida: publicação feita e seção Publicação da story preenchida
+teto: o checklist
+---
+
+# Task: Publicar
+
+## Autoridade única
+Push, PR, merge, deploy, release e tag passam **só** por este cargo. Autoridade única de publicar é o que torna a lista de pré-publicação executável: com dois publicadores, sempre existe um caminho que não passou pela lista.
+
+## Passos
+
+1. **Percorra `checklists/pre-publicacao.md`** preenchendo o formulário `templates/checklist-pre-publicacao-template.md`, com evidência real em cada item.
+
+2. **Confira o hash do parecer** contra o arquivo em disco. Hash diferente significa peça retocada depois da auditoria: ela reentra no gate **antes** de sair. Este item é o que impede o gate de virar carimbo.
+
+3. **Um assunto por publicação.** Branch nova, um assunto, um PR. Isso é o que transforma rollback em um comando em vez de uma cirurgia.
+
+4. **Produção exige aprovação do dono registrada**, com data. Aprovação de ontem não cobre publicação de hoje quando o conteúdo mudou.
+
+5. **Escreva o rollback ANTES de publicar**, na seção `Publicação` da story. Caminho de volta descoberto durante o incidente não é caminho de volta.
+
+6. **Publique**, e preencha destino, data e rollback na story.
+
+## Nunca
+Publicar com gate reprovado, com hash divergente, com árvore suja, com segredo no diff, ou sem as variáveis presentes no destino · gravar valor de credencial em qualquer lugar · reauditar (a DoD já foi verificada; aqui é conferência).
+
+## Último passo: memória
+Destino de deploy de cada projeto do dono (identificador e plataforma, **nunca** credencial) e o comando de publicação que funcionou. `~/.iron/memory/squad-engineering/eng-devops.md`.

package/squads/squad-engineering/tasks/run-retro.md

@@ -0,0 +1,36 @@
+---
+task: run-retro
+responsavel: eng-sprint
+entrada: lote de stories fechado
+saida: memórias podadas, aprendizados para o caderno do dono, próximos passos para o salvar
+teto: dez linhas de retro
+---
+
+# Task: Conduzir a retro e podar as memórias
+
+## Quando roda
+No fim de um lote de stories, ou no fim de um PROJETO. Não roda a cada story: retro toda hora vira ritual, e ritual não move entrega.
+
+## Passos
+
+1. **Três perguntas, e só três:** o que funcionou e vale repetir · o que travou e por quê · o que a gente já tinha visto acontecer antes.
+
+2. **Distribua o aprendizado por destino** — este é o passo que impede a memória de virar lixão:
+   - vale só pra este cargo, neste tipo de trabalho → memória do cargo;
+   - vale pro dono, além deste projeto → skill `anotar`, no caderno de aprendizados dele;
+   - virou regra do squad → proposta de linha no template ou na task, apresentada ao dono;
+   - é estado do projeto → não é memória: vai pro `PROJETO.md` do cofre pela skill `salvar`.
+
+3. **Pode cada memória tocada no lote:**
+   - **promova** o que apareceu em dois projetos ou em três sessões (move de `Candidato a promoção` pro destino real);
+   - **arquive** o que deixou de valer, com data e motivo — nunca apague: motivo arquivado impede o mesmo erro de voltar como novidade;
+   - **corte** pra caber no teto de oitenta linhas.
+
+4. **O que aparece na memória de dois cargos diferentes sobe pra um lugar só.** Duplicata em duas memórias diverge na terceira edição, e aí ninguém sabe qual das duas vale.
+
+5. **Entregue os próximos passos** em uma lista curta pro dono usar na skill `salvar`.
+
+**Meça, não estime.** Antes de entregar, conte: `wc -lw <arquivo>` (ou `Get-Content <arquivo> | Measure-Object -Line -Word` no Windows). Linhas de conteúdo — branco e cabeçalho não contam. Estourou o teto: corte antes de entregar.
+
+## Último passo: memória
+O que a retro repetiu **duas vezes** já não é observação, é padrão: registre em `~/.iron/memory/squad-engineering/eng-sprint.md` e proponha a mudança de template que faz o padrão parar de acontecer.

package/squads/squad-engineering/tasks/verify-dod.md

@@ -0,0 +1,27 @@
+---
+task: verify-dod
+responsavel: eng-qa
+entrada: story auditada + checklists/dod.md
+saida: DoD verificada com evidência, story em Pronta
+teto: a checklist
+---
+
+# Task: Verificar a DoD
+
+## Passos
+
+1. **Percorra `checklists/dod.md` item a item.** Sete itens, uma checklist só — a única do squad.
+
+2. **Cada item marcado carrega evidência:** o comando e a saída, não a lembrança. Marcar de memória é exatamente o defeito que a checklist existe pra impedir.
+
+3. **Item que não se aplica** vira `n/a` com o motivo escrito. Nunca marcado como feito: `n/a` é informação, `[x]` falso é mentira no registro.
+
+4. **Falta alguma coisa:** a story volta pro `eng-dev` com a lista do que falta. Não se "completa a DoD depois" — depois é sempre depois da publicação.
+
+5. **Tudo verde:** mova o status pra **Pronta**. Só o `eng-qa` fecha a story.
+
+## Fronteira com o devops
+O `eng-devops` **confere** esta lista antes de publicar; ele não abre auditoria nova. Segunda auditoria na hora de publicar é gate duplicado com outro nome, e gate duplicado é a burocracia que o squad recusa.
+
+## Último passo: memória
+Item da DoD que falha sempre neste projeto é sinal de processo, não de descuido: registre em `~/.iron/memory/squad-engineering/eng-qa.md` e leve pra retro.

package/squads/squad-engineering/tasks/verify-track-after-diff.md

@@ -0,0 +1,33 @@
+---
+task: verify-track-after-diff
+responsavel: eng-dev
+entrada: diff real do trabalho terminado
+saida: confirmação da faixa, ou declaração de estouro para o eng-orqx
+teto: três linhas
+---
+
+# Task: Reverificar a faixa contra o diff real
+
+## Por que existe
+A faixa foi escolhida por **previsão**; o diff é **medida**. Quando os dois discordam, quem manda é o diff. Sem esta task, o AJUSTE é a porta por onde qualquer coisa entra sem story e sem gate — basta a previsão inicial ter sido otimista.
+
+## Quando roda
+- **Faixa AJUSTE: obrigatória**, no fim de todo trabalho, antes de dar por encerrado. Aqui ela tem consequência de faixa: estourou, sobe pra FEATURE.
+- **Faixa FEATURE: recomendada, e informativa.** Estourar não muda a faixa — mede se a story foi bem dimensionada, e o resultado alimenta a retro (`run-retro`). Story que estourou muito o previsto é story que deveria ter sido dividida, e isso é aprendizado do `eng-sprint`, não defeito do dev.
+- **Faixa PROJETO:** não roda por story; quem compara entrega e previsão é o veredito final do `eng-orqx` contra o PRD.
+
+## Passos
+
+1. **Meça o diff de verdade.** Quantos arquivos, quais, quantas linhas. Comando em qualquer sistema: `git diff --stat` e `git status --short`.
+
+2. **Compare com os limites do AJUSTE:** até três arquivos · sem schema · sem auth · sem pagamento · sem integração nova · sem dependência nova · sem troca de arquitetura.
+
+3. **Coube:** confirme em uma linha e feche. Faixa AJUSTE com destino que fica na máquina roda só a lente ★ do gate; com destino que sai da máquina, roda a faixa mais rigorosa. Os nomes dessas faixas variam entre versões da skill (`VAI SAIR` ou `CLIENTE-FINAL`; `LOCAL` ou `INTERNO`) — o `eng-qa` lê a régua instalada e usa as palavras dela (`operate-gate-code.md`).
+
+4. **Estourou (em AJUSTE): pare e declare.** Não feche "já que está pronto". Devolva pro `eng-orqx` com a medida — ele sobe pra FEATURE, o `eng-sprint` escreve a story **a posteriori** em dez linhas (contexto, objetivo, critérios, o que foi feito), e o `eng-qa` roda o gate no painel de código, na faixa que sai da máquina, antes de fechar.
+
+## A tentação, escrita com nome
+Fechar um AJUSTE que estourou é mais rápido hoje e cobra juros depois: mudança sem story é mudança sem critério de aceite, sem parecer e sem rastro de quem aprovou. Quando alguém perguntar "por que isso mudou", não haverá resposta em lugar nenhum.
+
+## Último passo: memória
+Se o pedido parecia AJUSTE e estourou, registre **o que enganou** em `~/.iron/memory/squad-engineering/eng-dev.md` e avise o `eng-orqx` pra registrar na dele. Este é o aprendizado que mais barateia as próximas classificações.