Passo 4 · Blind Planning · Playbook do prompt cego · a lição final
Alembic · Blind Planning · Visual Course

Playbook do prompt cego

A lição final junta tudo: como colar os dois prompts em sessões limpas, gerar N planos independentes e comparáveis, pontuá-los com a rubrica R1–R10 e exigir as 16 seções obrigatórias em cada PLAN.md — para então agregar com confiança.

Leia primeiro (fontes primárias)
docs/alembic/PROMPT-BLIND-PLANNING.md & PROMPT-CORPUS-EMBEDS.md

Esta lição destila o manual do operador: a § Fase 4 (a rubrica) e a § estrutura de entrega (as 16 seções) de PROMPT-BLIND-PLANNING.md, mais o par de prompts que se cola na sessão. Idioma de trabalho: raciocínio e entregáveis em PT-BR; código, comandos e identificadores em English. Tudo aqui é citado do manual real.

Leia a versão simples, ou abra a camada técnica em qualquer seção.
O que você vai conseguir fazer
  • Executar o fluxo do operador em cinco estações: sessão nova → colar 2 arquivos → Fase 1 → PLAN.md de saída → comparar.
  • Explicar por que N sessões cegas e isoladas produzem planos mais confiáveis do que uma única conversa contaminada.
  • Pontuar um plano com a rubrica R1–R10 (0–2 por critério) e somar uma nota honesta.
  • Verificar se um PLAN.md traz exatamente as 16 seções, na ordem — o que torna dois planos comparáveis.
  • Rodar o checklist de handoff e saber quando um plano está pronto para a agregação.
Suposições tolas (o que presumimos de você — bem pouco)
  • Você fez as lições 1 a 3: sabe que o harness é o produto, conhece a disciplina de evidência e os três acordes (os três reverse-engineerings que se fundem).
  • Você já abriu uma sessão de um agente de CLI (Codex, Kimi, Grok ou Claude) e colou um texto longo nela.
  • Você não precisa decorar os dez critérios nem as dezesseis seções — esta página é a sua cola; consulte-a na hora de revisar.
1

O fluxo do operador


O objetivo de tudo é simples de dizer e difícil de fazer: obter N planos comparáveis a partir de N sessões limpas. Mesmo par de prompts, mesma rubrica, mesmas 16 seções — e só então agregar os resultados.

Você não pede um plano para um agente e confia nele. Você dá o mesmo briefing fechado a vários agentes diferentes (cada um numa sessão sem memória do que os outros fizeram), recebe um PLAN.md de cada um, e compara — como pedir a três arquitetos independentes uma planta para o mesmo terreno, com o mesmo edital. Onde eles concordam, você ganha confiança; onde divergem, você aprendeu onde está o risco.

Pense como… uma prova de redação corrigida às cegas: cada candidato responde ao mesmo enunciado sem ver a resposta do outro, e o corretor usa a mesma rubrica para todos. A cegueira é o que torna a comparação justa. A analogia quebra num ponto: aqui os "candidatos" são modelos diferentes (Codex, Kimi, Grok) — a diversidade é desejada, não um problema de cola.

Infografico do fluxo do operador: sessao nova, colar dois arquivos, agente roda Fase 1, PLAN.md de saida, comparar e agregar; tres sessoes isoladas convergindo para uma sintese.

Fig. 1 — O fluxo em cinco estações; ao fundo, três sessões cegas (codex-gpt55 · kimi-k2 · grok-4) convergindo para uma única síntese.

por que N, e não 1: o sinal nasce da comparação UM PLANO PLAN.md sólido ou só convincente? ✗ sem base de comparação N PLANOS CEGOS codex kimi grok ✓ concordam → confiança ✓ divergem → onde está o risco
Um plano isolado não pode ser julgado; N planos cegos transformam concordância e divergência em sinal.

As cinco estações, uma a uma

Clique cada estação para ver o que fazer — e a armadilha a evitar. É o mesmo caminho da Fig. 1, agora interativo.

Estação 1 de 5

Sessão nova

Abra uma sessão fresca do agente. Sem contexto de reverse-engineering anterior, sem gist, sem tratar docs de outros agentes como verdade. A página em branco é o ponto: cada plano nasce isolado.

contexto: zero · começa limpo

Armadilha: reaproveitar uma sessão com história — ela contamina o plano e quebra a comparação cega.

1 sessão 2 colar 3 Fase 1 4 PLAN.md 5 comparar R1–R10 · 16 seções

O par de prompts e o path de saída

Na estação 2 você cola dois arquivos, sempre os mesmos: o PROMPT-BLIND-PLANNING.md completo (ou apenas o bloco <prompt> dele) e o PROMPT-CORPUS-EMBEDS.md inteiro. O segundo é o corpus que o agente usa como base; gerá-lo de novo é bash docs/alembic/build-corpus-embeds.sh.

Na estação 3, o agente não pode pular para a implementação: ele inicia a Fase 1, fazendo o RE-A (as Droid Missions) primeiro. Na estação 4, cada agente grava em um path próprio para você não misturar saídas:

outputs/alembic-blind-plan-<agent-id>/PLAN.md
outputs/alembic-blind-plan-<agent-id>/reverse/
# Substitua agent-id: codex-gpt55, kimi-k2, grok-4, ...
o que entra em cada sessão SESSÃO CEGA ✓ PROMPT-BLIND-PLANNING.md PROMPT-CORPUS-EMBEDS.md só o briefing fechado entra SESSÃO CONTAMINADA ✗ gist anterior docs-como-verdade + o briefing também o histórico enviesa o plano
A cegueira é uma restrição de entrada: a sessão recebe o par de prompts e nada mais — nenhum viés de execuções passadas.
Faça uma aposta antes de revelar

Por que dar a mesma tarefa a três agentes cegos é melhor do que pedir um plano caprichado a um só agente bom?

Porque um único plano não tem com o que ser comparado: você não sabe se ele é sólido ou só convincente. Três planos cegos viram um sinal: a concordância entre modelos diferentes aumenta a confiança, e a divergência aponta exatamente onde mora o risco e a decisão difícil. É a mesma lógica de um council ou de uma fusion — diversidade independente vence a opinião única.
2

A rubrica R1–R10


Depois que os planos chegam, você precisa de uma régua. A rubrica é dez critérios; cada um vale 0, 1 ou 2. Auto-pontue cada plano, some, e seja honesto: a nota só é útil se for sincera.

Sem uma rubrica, "qual plano é melhor" vira gosto pessoal. Com ela, comparar fica objetivo: você lê o plano, marca 0 quando o critério está ausente, 2 quando está provado por inteiro, e 1 no meio do caminho. Dez critérios, nota máxima 20.

Pense como… a ficha de um jurado de ginástica: a nota não sai do "achei bonito", sai de itens fixos (execução, dificuldade, aterrissagem). Todo mundo é medido pela mesma ficha, então as notas se comparam entre si.

Cartao de pontuacao da rubrica R1-R10, dez criterios com escala de 0 a 2, com a nota 2 acesa em oliva e a legenda da escala.

Fig. 2 — A rubrica como cartão de pontuação: dez critérios, escala 0–2, a coluna "2" acesa quando o plano prova o item.

a escala de cada critério (0–2) 0 ausente 1 parcial 2 provado por inteiro 10 critérios × no máximo 2 = nota máxima 20
Cada um dos dez critérios é uma régua de três pontos; some os dez para a nota do plano.

Os dez critérios e seus extremos

O que separa um 0 de um 2 em cada linha. Fonte: PROMPT-BLIND-PLANNING.md § Fase 4.

IDCritérioNota 0Nota 2
R1Três REs com evidência binária + disco + webRE ausenteTrês provados forensicamente
R2Síntese unificadaContradiçõesTabela de fusão limpa
R3Loop Engineering operacionalizadoSó citadoGates no runtime
R4Reuso do spine @alembic/harnessGreenfieldMapa explícito de pacotes
R5Interface do operadorSó backendCLI + TUI + web mockups
R6Spec alembic.plan.tsEsboçoHooks API completa
R7Layout ~/.alembic/VagoÁrvore completa
R8Protocolo APIParcialREST/SSE/MCP/CLI
R9Slices A0–A9Sem proof gatesMensurável por slice
R10Estrutura comparávelAd hocAs 16 seções abaixo

Pontue você mesmo

Imagine que está revisando o plano do agente codex-gpt55. Clique uma nota (0/1/2) em cada critério; a soma e o veredito atualizam embaixo. É a sua ficha de jurado, ao vivo.

R1Três REs provados (binário + disco + web)
R2Síntese unificada (tabela de fusão)
R3Loop Engineering como gates no runtime
R4Reuso do spine, com mapa de pacotes
R5Interface do operador (CLI+TUI+web)
R6Spec do alembic.plan.ts + hooks API
R7Layout ~/.alembic/ (árvore completa)
R8Protocolo API (REST/SSE/MCP/CLI)
R9Slices A0–A9 mensuráveis (proof gates)
R10Estrutura comparável (16 seções)
nota: 0 / 20 — pontue os dez critérios
o valor não é a nota — é o delta entre planos (R1…R10) 0 2 R1R2R3R4R5R6R7R8R9R10 codex-gpt55 (18/20) kimi-k2 (12/20 — vales em R5/R8/R9)
Comparados, os vales saltam: kimi-k2 zera R8 e R9 (API e slices) — não um veredito de "ruim", mas o mapa exato do que falta nele.

A rubrica é uma régua, não um ranking automático

A pontuação é auto-aplicada: o agente pontua o próprio plano na seção 15 ("Rubrica auto-score + gaps honestos"), e você re-pontua na revisão. A honestidade é o ponto — um plano que se dá 20/20 mas esconde gaps falha em R10 e na disciplina de evidência (lição 2). O valor não é a nota absoluta; é o delta entre planos e o que cada nota baixa revela sobre o que falta.

auto-score: vaidade vs honestidade INFLADO ✗ 20/20 sem nenhum gap confessado → suspeito; falha em R10 e na evidência HONESTO ✓ 16/20 + 3 gaps listados (R5, R8, R9) → confiável; sabe o que falta
Uma nota menor com gaps confessados vale mais que um 20/20 que esconde o que falta — a honestidade é o que a rubrica recompensa.

Repare como R1–R3 medem o material da lição anterior: R1 é a disciplina de evidência aplicada aos três REs; R2 é a fusão dos três acordes numa tabela só; R3 é o Loop Engineering virando gates de verdade no runtime, não citação.

a rubrica mede as lições anteriores R1 R2 R3 Lição 2 · evidência binária + disco + web Lição 3 · fusão dos três acordes (1 tabela) Loop Engineering · gates no runtime
R1–R3 não são novos: são as lições 2, 3 e o Loop Engineering transformados em itens pontuáveis.
3

As 16 seções de entrega


A última peça do briefing: todo PLAN.md deve conter exatamente estas 16 seções, na mesma ordem. Esse esqueleto fixo é o que transforma planos diferentes em planos comparáveis — é literalmente o critério R10.

Se cada agente organizasse o plano do seu jeito, você gastaria a revisão caçando "onde ele falou de riscos?". Com 16 seções fixas, a seção 14 é sempre riscos, em todos os planos — então você compara a seção 14 de um com a do outro, lado a lado. O formato é a régua que faz a comparação ser rápida.

Pense como… um formulário de imposto de renda: todo mundo preenche os mesmos campos na mesma ordem, então o auditor compara a linha 7 do seu com a linha 7 do vizinho sem reler tudo. Chato? Sim. É justamente a chatice que dá a comparabilidade.

Checklist numerado das 16 secoes obrigatorias do PLAN.md em duas colunas, agrupadas em reverse engineering, arquitetura e honestidade.

Fig. 3 — As 16 seções como checklist, agrupadas em três blocos: reverse engineering + síntese, arquitetura + plano, honestidade + provas.

formato fixo → a seção k alinha entre planos (= R10) codex kimi grok §1§2§14§15§16 ↑ a coluna §14 (riscos) é comparada lado a lado nos três planos, sem reler tudo
Como toda seção tem o mesmo número em todo plano, a revisão compara colunas — a comparabilidade é literalmente o critério R10.

O esqueleto completo

Bloco A · reverse engineering + síntese
  1. Executive Summary (1 página)
  2. RE-A: Droid Missions
  3. RE-B: Claude Workflows
  4. RE-C: Kimi AgentSwarm
  5. Síntese: tabela unificada + regras de fusão
Bloco B · arquitetura + plano
  1. Arquitetura Alembic (diagramas mermaid)
  2. Loop Engineering: gates no runtime
  3. Estado em disco + event schema
  4. alembic.plan.ts + hooks API
  5. Interface operador (CLI + TUI ASCII + web)
  6. API protocol (REST, SSE, MCP, CLI)
  7. Mapa do código existente a reutilizar
  8. Plano de slices A0–A9 com DAG
Bloco C · honestidade + provas
  1. Riscos, forks, decisões user-gated
  2. Rubrica auto-score + gaps honestos
  3. Apêndice: comandos executados + outputs chave
Repare na simetria. As seções 2–4 são os três acordes da lição 3 (RE-A/B/C), a seção 5 é a fusão, e as seções 15–16 são a disciplina de evidência da lição 2 (gaps honestos + comandos com outputs). O briefing inteiro é as lições anteriores transformadas em formulário.
as 16 seções, em três blocos de propósito 12345 678910111213 141516 reverse engineering + síntese arquitetura + plano honestidade + provas blocos A e C reusam as lições 2–3; o bloco B é o desenho do sistema (lição 1).
Os três blocos mostram a lógica do formulário: provar o que se entendeu, desenhar o sistema, confessar os limites.

Onde salvar cada plano

um path por agente — nunca misture saídas
outputs/alembic-blind-plan-codex-gpt55/PLAN.md
outputs/alembic-blind-plan-codex-gpt55/reverse/
outputs/alembic-blind-plan-kimi-k2/PLAN.md
outputs/alembic-blind-plan-grok-4/PLAN.md
# cada agent-id em sua pasta → a agregação compara PLAN.md contra PLAN.md

Exemplo guiado: verificar as 16 seções

Worked example — auditando o PLAN.md de codex-gpt55
1
Abra outputs/alembic-blind-plan-codex-gpt55/PLAN.md e role até o topo: a seção 1 deve ser um Executive Summary de uma página. Presente? Marque ✓.
2
Confirme que as seções 2, 3 e 4 são os três REs separados (Droid, Claude, Kimi) — não um RE só. Cada um deve trazer evidência, não resumo.
3
Vá direto à seção 15: ela traz a auto-pontuação R1–R10 e uma lista de gaps honestos? Um plano sem gaps confessados é suspeito.
4
Agora você: conte as seções. São 16, na ordem? Se faltar alguma ou a ordem trocar, R10 não é 2 — anote o que faltou e devolva para correção antes de agregar.
4

Checklist de handoff


Antes de declarar um plano "pronto para agregar", passe-o por esta lista. É o portão final entre "um agente respondeu" e "tenho um plano em que confio".

os cinco portões antes de agregar (todos precisam de ✓) 1 · CEGUEIRAsessão limpa,sem gist nemdocs-verdade 2 · PRESENÇAPLAN.md +reverse/ napasta do agente 3 · ESTRUTURA16 seçõesna ordem(R10 = 2) 4 · PONTUAÇÃOR1–R10 comgaps honestos(seção 15) 5 · DIVERGÊNCIASmapeadas →decisões(seção 14) → pronto para agregar
Cinco portões em série: se qualquer um falha, o plano volta para correção — agregar um plano furado injeta ruído na síntese.

Simples ↔ Técnico: o mesmo handoff, duas alturas

Use a aba "Simples" para a intuição do que checar; a "Técnico" para os nomes e paths reais que você confere na revisão.

Em linguagem de gente: cheque cinco coisas. (1) Cada agente trabalhou sozinho, numa sessão limpa? (2) Cada um entregou um PLAN.md na sua própria pasta? (3) Cada plano tem as 16 seções? (4) Você pontuou os dez critérios com honestidade? (5) Os pontos onde os planos discordam estão anotados como decisões a tomar? Se as cinco respostas são "sim", pode agregar.
Com os termos reais: verifique a cegueira (nenhuma sessão herdou contexto/gist/docs-como-verdade), a presença de outputs/alembic-blind-plan-<agent-id>/PLAN.md + reverse/ por agente, a conformidade estrutural (16 seções na ordem → R10=2), a pontuação R1–R10 com a seção 15 confessando gaps, e o mapa de divergências (onde os planos discordam vira a seção 14 "decisões user-gated"). Só então rode a agregação plano-contra-plano.

Cartões de memória

Vire cada cartão (clique, ou Enter/Espaço) e tente responder antes de ver o verso. É prática de recuperação — vale mais que reler.

Objetivo
Qual é o objetivo do fluxo do operador?
clique para virar
N planos comparáveis de N sessões limpas — mesmo par de prompts, mesma rubrica, mesmas 16 seções, depois agregar.
Cegueira
O que torna uma sessão "cega"?
clique para virar
Sem contexto de RE anterior, sem gist, sem tratar docs de outros agentes como verdade. Cada plano nasce isolado dos demais.
Rubrica
Como funciona a escala R1–R10?
clique para virar
Dez critérios, cada um 0 / 1 / 2 (ausente / parcial / provado). Máximo 20. Auto-pontuada, e a honestidade é o que vale.
Formato
Por que exigir 16 seções fixas?
clique para virar
Porque o esqueleto fixo torna os planos comparáveis (é o critério R10): a seção k de um plano alinha com a seção k do outro.
Path
Onde cada agente grava seu plano?
clique para virar
outputs/alembic-blind-plan-<agent-id>/PLAN.md + reverse/ — uma pasta por agente, para não misturar saídas.
Divergência
O que fazer onde os planos discordam?
clique para virar
Tratar como sinal, não ruído: a divergência marca onde está o risco e a decisão. Vira a seção 14 (forks / decisões user-gated).
Agora você consegue:
  • Colar o par de prompts em uma sessão fresca de qualquer agente.
  • Exigir a disciplina de evidência (lição 2) na revisão de cada plano.
  • Julgar a qualidade da fusão dos três acordes (lição 3).
  • Pontuar planos com R1–R10 e verificar as 16 seções.

Fontes primárias: docs/alembic/PROMPT-BLIND-PLANNING.md · docs/alembic/PROMPT-CORPUS-EMBEDS.md · loop-engineering/SKILL.md

5

Recapitulando


Esta foi a lição final. Antes de fechar o curso, passe o deck abaixo — ele recapitula o playbook inteiro e amarra as quatro lições do Blind Planning.

Recap · 1 de 6

O alvo: N planos comparáveis

Não um plano de um agente — vários, de sessões limpas, sob o mesmo briefing. A comparação é o produto.

codex-gpt55kimi-k2grok-4Síntese

Recap · 2 de 6

Cegueira = comparação justa

Sessão nova, sem gist, sem docs-como-verdade. Modelos diferentes (a diversidade é desejada); só o briefing é igual.

mesmo briefingcodex-gpt55kimi-k2grok-4

Recap · 3 de 6

Cinco estações

Sessão nova → colar 2 arquivos → Fase 1 (RE-A primeiro) → PLAN.md por agente → comparar e agregar.

12345

Recap · 4 de 6

R1–R10: a régua

Dez critérios, 0/1/2, máximo 20. Auto-pontuada e honesta — a nota baixa revela o que falta.

Recap · 5 de 6

16 seções = comparabilidade

O esqueleto fixo é o critério R10: a seção k de um plano alinha com a do outro. Formulário, não prosa livre.

§k alinha com §k

Recap · 6 de 6

O curso, fechado

Lição 1 o harness é o produto → 2 disciplina de evidência → 3 três acordes → 4 este playbook que opera as três.

1 / 6setas

Em uma frase, para você mesmo

"O fluxo do operador produz ____ a partir de sessões ____; eu pontuo cada plano com a régua ____ e exijo as ____ seções, e onde os planos ____ está a decisão." Se você preenche as cinco lacunas, dominou o playbook.

As três conexões com as lições anteriores

  • Lição 1 (o harness é o produto) → o plano não é sobre o prompt; é sobre desenhar o sistema (runtime, gates, estado em disco, API) — as seções 6–13.
  • Lição 2 (disciplina de evidência) → vira R1 (evidência binária + disco + web) e as seções 15–16 (gaps honestos + comandos com outputs).
  • Lição 3 (os três acordes) → vira R2 e as seções 2–5 (os três REs separados, depois fundidos numa tabela só).
o arco do curso — quatro lições, um playbook L1harness L2evidência L33 acordes L4playbook opera as três
As três primeiras lições constroem os conceitos; esta lição final é onde você os opera, de ponta a ponta.

As dez regras de ouro do prompt cego

  1. Uma sessão nova por agente — zero contexto herdado.
  2. Cole sempre o mesmo par de prompts (planning + corpus).
  3. Fase 1 primeiro: RE-A antes de qualquer implementação.
  4. Uma pasta por agent-id; nunca misture saídas.
  5. Exija as 16 seções, na ordem — é o critério R10.
  6. Pontue R1–R10 com honestidade brutal, não vaidade.
  7. Uma nota baixa não é derrota: é um mapa do que falta.
  8. Trate a divergência entre planos como sinal, não ruído.
  9. Diversidade de modelos é desejada; só o briefing é igual.
  10. Agregue por último — depois que cada plano passou no handoff.
6

Próximos passos


Você terminou o curso Blind Planning. A partir daqui, o caminho é praticar o playbook e voltar ao índice para revisar onde precisar.

O melhor próximo passo é fazer: abra duas sessões de agentes diferentes, cole o par de prompts em cada uma, e gere dois planos. Depois volte aqui e pontue os dois com a régua R1–R10 e o checklist de 16 seções. A primeira agregação ensina mais que reler qualquer lição.

Sua próxima missão prática

Rode o fluxo com pelo menos dois agentes. Pontue cada plano, confira as 16 seções, e escreva o seu primeiro mapa de divergências — a lista dos pontos em que os planos discordam. Esse mapa é o começo da sua síntese.

o que sai da comparação: consenso + decisões plano codex plano kimi concordam → consenso divergem → decisão (§14) mapa de divergências o consenso você adota; cada divergência vira uma decisão consciente — o início da síntese.
O entregável final da comparação é este mapa: o que adotar (consenso) e o que decidir (divergência) — a base da sua síntese.

Verifique seu entendimento

Três perguntas para fechar o curso. Escolha e leia o porquê de cada opção — o feedback ensina tanto quanto a pergunta.

Checagem cumulativa

Acerte as três para concluir o Blind Planning. A pontuação aparece abaixo.

1. Por que o fluxo usa várias sessões cegas em vez de uma só?
(b). A cegueira existe para a comparação: onde modelos independentes concordam, sobe a confiança; onde discordam, está a decisão. Não é economia (a) — roda-se vários. E não há revisão cruzada (c): cada sessão é isolada, sem ver a outra.
2. Na rubrica, o que significa um critério receber nota 0?
(c). 0 é "ausente", 2 é "provado", 1 é o meio. A nota baixa não reprova o plano todo (a) nem libera ignorar o item (b): ela revela um gap, e a soma honesta é o que importa para comparar.
3. Por que o PLAN.md precisa das 16 seções fixas?
(a). O formato fixo alinha a seção k de um plano com a do outro, então a revisão compara lado a lado — exatamente o que R10 mede. (b) e (c) inventam efeitos de velocidade/custo que não existem; a razão é a comparabilidade.
Acertos: 0/3
Curso concluído. Se você acertou as três e consegue preencher as lacunas do "em uma frase", você sabe operar o prompt cego de ponta a ponta. Volte ao índice para revisar qualquer lição quando precisar.