Tcuzzo Understanding Gates
Effort: light — uma passada de validador por estágio, pontuada contra o pedido original e re-rodada depois de cada reparo. Remove: deriva validada contra uma paráfrase — o build que pousa verde mas responde uma pergunta que ninguém fez.
Uma disciplina de validação para builds. Ela interroga o trabalho em cinco estágios — Design, Plano, Build, Teste, Entrega — sempre contra o pedido ORIGINAL, nunca contra a reformulação que o próprio trabalho fez dele. Cada portão devolve evidência: notas, um veredicto, falhas nomeadas e ações de reparo. Ele amarra o agente, não o humano: nenhum passo novo de aprovação, nenhum atrito para quem pediu.
Quando rodar
- Qualquer build, conserto ou uplift que vai aterrissar em algum lugar real.
- Toda vez que você está prestes a dizer "pronto" e a única prova é um teste verde.
- Depois de cada reparo, no mesmo estágio que falhou.
Estágio 0 — ancore a intenção
Antes de pontuar qualquer coisa, fixe a âncora de comparação: as palavras ORIGINAIS do humano, mais uma diretiva traduzida de uma linha (veja intent-compiler). Todo portão pontua contra essa âncora. Nunca pontue contra a sua própria paráfrase — paráfrase deriva, e aí cada portão valida em silêncio a deriva em vez do pedido.
Os cinco portões
Cada portão faz uma pergunta contra a intenção original:
| Estágio | Pergunta |
|---|---|
| Design | A spec está clara e fiel ao pedido original? |
| Plano | O plano responde à intenção e cabe na superfície onde vai entrar? |
| Build | O código satisfaz a spec sem deriva? |
| Teste | Os testes exercitam o comportamento real, não um substituto dele? |
| Entrega | Aplica limpo, falha em voz alta, e a alegação de entrega sobrevive a uma checagem de fatos? |
Pontue TODO portão nas mesmas cinco lentes, cada uma de 0–4: aderência à spec, encaixe arquitetural, segurança de tipos, testabilidade, segurança — formuladas para o estágio (no Design, "testabilidade" pergunta se a spec é checável; na Entrega, se a alegação de entrega é). Consolidação: some as cinco lentes (0–20), multiplique por 5 — essa é a nota de veredicto do portão, de 0–100. Registre cada lente, não só o total — o total esconde qual lente falhou.
Veredictos
Consolide as lentes numa nota de 0–100 e enquadre:
- Aprovar (80+): evidência forte. Ainda não é prova de pronto — veja a segunda lei.
- Revisar (60–79): existem falhas nomeadas. Cada uma é um alvo de reparo.
- Rejeitar (abaixo de 60): o trabalho erra a intenção. Volte um estágio.
Um veredicto sem falhas nomeadas por trás é um veredicto de pouca informação. Exija a lista.
Disciplina de reparo
- Mantenha a intenção original como âncora de toda nova rodada.
- Registre as notas por lente, não só o número de cima.
- Trate toda falha nomeada como alvo de reparo. Nenhuma falha é decoração.
- Repare, depois RODE O MESMO PORTÃO DE NOVO. Reparo sem nova rodada é só alegação.
- Nunca promova confiança a prontidão. Os testes e a superfície real decidem.
As duas leis
1. A lei do eco. Uma checagem que só sabe concordar é um eco, não um validador. A prova de honestidade é a refutação: alimente-a com uma alegação que você sabe ser falsa e veja-a reprovar essa alegação. Se ela aprova a mentira, a checagem é teatro. Corolário sobre mock: mocke só a folha externa instável — uma API paga, uma rede instável. Nunca mocke o órgão cujo comportamento É a prova; a pontuação, a extração de alegações e a lógica de passa/falha dele precisam rodar de verdade.
2. Necessário, não suficiente. Um teste que passa é necessário, nunca suficiente. Pronto significa que a superfície real — a que o humano de fato usa — faz o trabalho sozinha. Nomeie essa superfície, dispare o caminho real e veja o resultado correto chegar. Nunca promova um recibo de teste unitário a alegação de capacidade viva.
Regras duras (o que derruba esta skill)
- Pontuar contra uma paráfrase em vez do pedido original.
- Um veredicto de revisar ou rejeitar sem falhas nomeadas anexadas.
- Reparar sem rodar de novo o portão que falhou.
- Mockar o próprio validador, ou a exata costura sob mudança.
- Declarar pronto a partir de um teste verde sem prova na superfície real.
Mantenha um registro do build
Para cada estágio guarde: a intenção, o artefato exato de entrada, as notas, as falhas nomeadas, o reparo feito, o resultado da nova rodada e a evidência da superfície real. Um registro que não aponta para evidência reproduzível é uma faixa de propaganda, não um registro.
Funciona bem com
- intent-compiler — traduza o pedido antes de pontuar.
- red-first — o contrato do portão de Teste: teste falhando commitado primeiro.
- sniper-testing — efeitos colaterais reais, sem teatro de mock.
- blind-tribunal — avaliadores independentes por cima destes portões.
- repair-loop — o loop que leva veredictos de revisar até o verde.