Laboratório e projeto final | INEMA Agent Runtime

Volte à escada antes do laboratório

A vontade de "abrir o programa por dentro" aparece quando algo parece impossível. Antes disso, uma regra do LEIA-ME.md e do AGENTS.md: suba a escada e teste cada nível com um comando.

O laboratório é o degrau 7. Só se chega a ele depois de os seis de cima responderem "não", com evidência. Muitas vezes a via existe e só não estava documentada.

Como ler o desenho: a escada desce do mais estável (âmbar) para o mais frágil. A linha vermelha tracejada separa os seis degraus de produção do degrau 7, que fica só no laboratório.

🎯 Objetivo: ter evidência de cada degrau antes de pensar em laboratório

Abra claude (ou codex) na pasta do kit e cole, trocando o nome do sistema:

Leia runtime/LEIA-ME.md e suba a escada das vias para o <meu sistema>. Para cada nível, de API até ponte local, diga qual comando ou menu testa esse nível e o que você encontrou. Não conclua "não dá" sem mostrar o teste de cada nível.

Como verificar: a resposta tem seis níveis, cada um com um teste e um resultado. Se algum nível vier sem teste, peça de novo só aquele.

🪜

Escada

a mais alta que existir

🧾

Evidência

um teste por nível

📤

Exportar

quase sempre existe

🧪

Degrau 7

só depois dos seis

Trate engenharia reversa como laboratório

A POLITICA.md diz numa linha: engenharia reversa é laboratório: anote em LIMITES.md e não use em produção. Laboratório quer dizer máquina de teste, dados de teste e prazo de validade.

O objetivo do laboratório é responder uma pergunta: "por onde esse programa conversa?". Achou a resposta, volte à escada e procure a via oficial que faz o mesmo.

🆕 Novo aqui? Máquina de teste e etiqueta "frágil"

Máquina de teste é um computador (ou máquina virtual) sem os seus dados reais e sem as suas contas logadas. Se algo der errado, nada de valor se perde. Etiqueta "frágil" é escrever, ao lado do achado, que ele pode quebrar na próxima atualização e em que data foi testado.

Separe a máquina

Nada de testar no computador da clínica da Clara nem no ERP de produção do cliente da Sônia.

Anote antes de começar

Uma linha em runtime/LIMITES.md: data, o que tentou, o que barrou, contorno e status.

Etiquete o achado

"Frágil, testado em <data>". Sem data, ninguém sabe se ainda vale.

Volte à escada

O achado vira pergunta: "existe exportação, CLI ou MCP que faça isso?". A resposta entra no CAPACIDADES.md; o truque, não.

📄 Exemplo de linha no runtime/LIMITES.md (a Sônia escreveria)

| data | o que tentei | o que barrou | contorno | status |
|---|---|---|---|---|
| <data> | achar por onde o ERP grava as vendas (máquina de teste, frágil) | sem API nem CLI | exportação CSV de vendas, ponte local (nível 6) | aceito |

O que olhar: a coluna "contorno" aponta para uma via da escada, não para o truque do laboratório.

⚠️ Nunca em produção

O que nasceu por engenharia reversa quebra na próxima atualização do programa, sem aviso, e só quem montou sabe consertar. Se o laboratório não achou via oficial, o achado fica no laboratório.

Respeite termos de uso e credenciais

Até no laboratório valem as três regras de integração da POLITICA.md. Elas protegem a sua conta, os seus dados e o seu acordo com quem fornece a ferramenta.

O ponto mais sensível é a credencial. O login do Claude Code é do Claude Code. O do Codex é do Codex. Copiar o token de um para dentro do outro, ou de um script, é exatamente o que a regra proíbe.

📄 runtime/POLITICA.md, seção Integração (texto do kit)

- Só ferramentas oficiais pela assinatura (Claude Code, Codex CLI).
- Nunca passe credencial de uma ferramenta para outra.
- Engenharia reversa é laboratório: anote em LIMITES.md e não use em produção.

🆕 Novo aqui? Credencial e token

Credencial é qualquer coisa que prova quem você é: senha, chave, cookie de sessão. Token é a credencial que um programa guarda depois do seu login, para não pedir a senha de novo. Quem tem o token age como você.

✓ Pode

✓ Claude chamar o Codex pela ponte codex-exec.sh: cada um com o próprio login
✓ Usar o codex login e o login do claude pela assinatura
✓ Você fazer o login no site; o agente só lê a página
✓ Ler os termos de uso antes de automatizar um site

✗ Não pode

✗ Copiar o token de uma ferramenta para outra
✗ Usar a assinatura por um cliente não oficial
✗ Pedir ao agente que guarde senha
✗ Pôr em produção o que veio do laboratório

💡 A ponte certa não carrega senha

Repare nas pontes do kit: a codex-exec.sh chama o comando oficial do Codex, que usa o login dele. A mcp-modelo lê um arquivo exportado. Nenhuma das duas guarda, copia ou repassa credencial. Use isso como teste para qualquer ponte nova.

🏷️

Oficial

pela assinatura

🔐

Credencial

fica onde nasceu

📜

Termos

lidos antes

🙋

é com você

Escolha seu sistema e preencha o mapa

Começa o projeto final. Escolha um sistema do seu trabalho que não tem API: uma planilha, um ERP antigo, o site de um fornecedor. Vale qualquer um em que um agente economizaria seu tempo.

A Sônia escolheu o ERP do cliente. A Clara, a agenda da clínica. Você vai percorrer as mesmas seis etapas que elas, do mapa até a lição aprovada.

Como ler o desenho: as cinco caixas azuis são trabalho; a caixa âmbar é a prova de que o trabalho ficou pronto. Nenhuma etapa pula a anterior: sem linha no mapa, não há ponte; sem ponte, o time não tem o que usar.

🎯 Objetivo: uma linha testada no CAPACIDADES.md para o seu sistema

Abra claude na pasta do kit e cole (o prompt do README):

Leia runtime/LEIA-ME.md e me ajude a preencher o CAPACIDADES.md para o meu trabalho.

Exemplo do próprio kit (a linha da Sônia antes do teste):

| ERP sem API | Exportação CSV diária | 6 | ler ~/erp/export/*.csv | ler (N4) | pendente |

Como verificar: a sua linha tem as seis colunas. A última só troca "pendente" pela data quando o teste da ponte (tópico 5) passar.

💡 Escolha pequeno

Um sistema, uma pergunta. "Total de vendas por cliente" é um bom projeto final. "Automatizar o escritório inteiro" não é. Depois que o primeiro passar, o segundo leva metade do tempo.

🎯

Um sistema

sem API

🗺️

Uma linha

no CAPACIDADES.md

⏳

Pendente

até o teste

📁

runtime/

o entregável

Construa a ponte e rode o time

A via que você escolheu decide a receita. Sistema que exporta arquivo vai pela R3 (ponte MCP). Sistema que só existe como site vai pela R5 (navegador com política).

Com a ponte de pé, o time de três papéis da R2 faz o trabalho. Aqui com uma diferença: política N2. O time pede antes de criar ou alterar qualquer arquivo.

Seu sistema	Receita	Teste da ponte	Módulo
Exporta CSV ou planilha	R3 · ponte MCP	`node runtime/pontes/mcp-modelo/server.mjs --selftest`	2.2 · 2.3
Só existe como site	R5 · navegador	`agent-browser open` + `agent-browser get title`	2.4

🎯 Objetivo: a ponte responde e está conectada ao Claude (caminho R3)

No terminal, na pasta do kit, depois de apontar PONTE_DADOS e trocar as colunas (módulo 2.3):

node runtime/pontes/mcp-modelo/server.mjs --selftest
claude mcp list

Saída real (05/10/2026, com os arquivos de exemplo do kit):

tools: 2 (listar_horarios_livres, resumo_vendas)
2026-10-06 09:00 · Dra. Ana
2026-10-06 10:00 · Dra. Ana
2026-10-06 15:00 · Dr. Bruno
TOTAL: R$ 856.00

ponte-modelo: node runtime/pontes/mcp-modelo/server.mjs - ✔ Connected

Como verificar: com os seus dados, os números mudam, mas o formato fica igual e a linha da ponte termina em ✔ Connected. Agora troque "pendente" pela data no CAPACIDADES.md.

🎯 Objetivo: o time de três papéis trabalha na sua ponte, pedindo antes (N2)

Abra claude na pasta do kit e cole (exemplo da Sônia; troque a tarefa pela sua):

Use o time: o planejador planeja, o executor faz e o revisor confere. Tarefa: use a tool resumo_vendas da ponte-modelo e grave em resumo-vendas.md o total de cada cliente e o TOTAL. Política N2: antes de criar ou alterar qualquer arquivo, mostre o que vai fazer e espere meu OK. Termine com a resposta do revisor.

Conta à mão do erp-vendas.csv, para você conferir o resumo:

Mercado Sol  10×18,50 + 40×5,20 = 185 + 208 = R$ 393,00
Padaria Lua  25×5,20 + 12×18,50 = 130 + 222 = R$ 352,00
Empório Mar  6×18,50             =             R$ 111,00
TOTAL                                          R$ 856,00

Como verificar: o Claude parou e pediu seu OK antes de gravar o arquivo; os totais batem com a conta à mão; a resposta termina com APROVADO.

🔌

arquivo vira ferramenta

🌐

site com política

👥

planeja, faz, confere

🚦

pede antes

Entregue com o verificar e uma lição aprovada

"Pronto" não é o agente dizer que terminou. É o verificar.mjs rodar os seus critérios e mostrar todos OK. Escreva um goal no formato do goal-exemplo.md, um critério por linha.

E o projeto só fecha com o ciclo completo: algo que aconteceu vira uma linha na tabela Aprendizado da POLITICA.md, e você aprova.

📋 Modelo de goal para copiar (salve como meu-goal.md na raiz do kit)

# Goal — ponte do <meu sistema>

## Resultado
O agente lê o <meu sistema> pela ponte, o time grava o resumo e o kit continua saudável.

## Critérios de pronto
- [ ] `node runtime/scripts/doctor.mjs` → `PRONTO`
- [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `tools: 2`
- [ ] `node runtime/pontes/mcp-modelo/server.mjs --selftest` → `TOTAL: R$ <total conferido à mão>`
- [ ] `claude mcp list` → `✔ Connected`
- [ ] `cat <arquivo que o time gravou>` → `<texto que tem de aparecer>`

## Portões humanos
Enviar, apagar, gastar ou publicar: pare e me pergunte.

O que olhar: cada critério passa só se o comando terminar sem erro e a saída contiver o texto entre crases depois da seta. Troque tudo que está entre < >.

🎯 Objetivo: ver o verificar dizer "todos OK"

Na pasta do kit, rode primeiro no goal de exemplo. Depois troque o caminho pelo do seu meu-goal.md:

node runtime/scripts/verificar.mjs runtime/exemplos/goal-exemplo.md

Saída real (05/10/2026, saída 0):

OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/pontes/mcp-modelo/server.mjs --selftest
OK     node runtime/scripts/doctor.mjs

4/4 critérios OK

Como verificar: a última linha diz N/N critérios OK com os dois números iguais. Se faltar algum, peça ao agente com o prompt da R6:

/goal Cumpra o goal em meu-goal.md. Depois de cada etapa rode node runtime/scripts/verificar.mjs meu-goal.md. Só pare com todos OK ou num portão humano do goal.

📄 Exemplo de linha aprovada na tabela Aprendizado (runtime/POLITICA.md)

| data | o que aconteceu (com evidência) | proposta (1 linha) | status: proposto / aprovado / recusado |
|---|---|---|---|
| <data> | o resumo do time somou um cliente duas vezes; o revisor pegou (FALTA:) | o revisor sempre compara o TOTAL com a soma por cliente | aprovado |

Depois: aprovado vira uma linha na seção Lessons do AGENTS.md (módulo 4.2).

✅ Checklist de entrega (a sua pasta `runtime/`)

☐ CAPACIDADES.md com a linha do seu sistema, via, nível, política e data do teste
☐ Ponte funcionando: selftest e ✔ Connected (R3) ou agent-browser lendo o site (R5)
☐ Time de três papéis rodado com política N2, terminando em APROVADO
☐ meu-goal.md no formato - [ ] `comando` → `esperado`, com portões humanos
☐ Saída do verificar.mjs com todos os critérios OK
☐ Uma linha com status aprovado na tabela Aprendizado e a regra nas Lessons
☐ Se houve laboratório: a linha em LIMITES.md com data e etiqueta "frágil"

Teste rápido (opcional): o que prova que o seu projeto final está pronto?

🎓 Resumo do módulo

✓

Escada primeiro — um teste por nível antes do "não dá".

✓

Engenharia reversa é laboratório — máquina de teste, LIMITES.md, frágil e data.

✓

Credencial fica onde nasceu — só ferramentas oficiais pela assinatura.

✓

Sistema sem API vira ponte — R3 ou R5, e o time R2 trabalha em N2.

✓

Pronto é prova — verificar todo OK e uma lição aprovada.

Fim do curso:

Você tem uma ponte, um time, um goal verificado e a primeira regra aprendida. Repita o ciclo com o próximo sistema.

← Voltar para a trilha Voltar ao início →