Proof Gates
Uma função configurada não é um resultado. Cruze a fronteira real, guarde os recibos e nomeie a fronteira bloqueada.
O fluxo privilegia logs, timestamps e diffs sobre autodescrição. Aqui aplicamos essa regra ao roteamento.
Ao final, você consegue
- separar prova de configuração de prova de runtime
- reconhecer comportamento fail-closed
- relatar uma fronteira bloqueada sem exagero
A grande ideia
Toda afirmação precisa de um recibo correspondente. Um teste unitário prova o mapeamento; um comando real prova a inicialização; um container provaria o sandbox.
Pense nos portões de um aeroporto. O cartão de embarque leva ao portão, não ao destino. A analogia quebra porque gates de software podem ser repetidos deterministicamente.
No código
O preflight exige raiz do gateway, token do gateway e token do GitHub antes de construir o roster. O baseline completo passou. Docker permanece explicitamente sem prova porque o Colima não ficou SSH-ready.
Em uma imagem
No código
packages/factory/src/FactoryRuntime.ts
const parsed = factoryEnvironmentSchema.safeParse(env);
if (!parsed.success) {
const field = parsed.error.issues[0]?.path[0];
return failure(
`Missing required Factory environment variable: ${String(field ?? "unknown")}`,
);
}Como achar ou executar isto
FACTORY_CLIPROXY_URL= FACTORY_CLIPROXY_TOKEN= GH_TOKEN= pnpm exec tsx .factory/run.ts termina antes de container ou chamada de modelo.
Experimente
Alterne os dois recibos. O simulador só permite a afirmação completa quando ambos existem.
Simulador de fronteira
Os dois recibos existem.
Relate o que passou e nomeie o que não passou.
Vire os três cartões, faça uma previsão e só então responda ao teste.