Forge: do prompt cru ao escopo executável

O pipeline canônico não é convenção de doc — é um array. DEFAULT_FORGE_STEPS (packages/forge/src/front-end/index.ts:21–29) registra os 7 passos na ordem, e runForgeFrontEnd (index.ts:42–55) os executa sequencialmente, parando no primeiro erro ("the first failure short-circuits the pipeline"). Cada passo é uma função pura sobre o contexto (ForgeStep, front-end/types.ts:53–56) que escreve seu artefato em scopeDir — o orquestrador nunca muta o contexto.

// trecho real, não editado
export const DEFAULT_FORGE_STEPS: readonly ForgeStepRegistry[] = [
  { name: 'grill', run: grillStep },
  { name: 'research', run: researchStep },
  { name: 'prototype', run: prototypeStep },
  { name: 'prd', run: prdStep },
  { name: 'issues', run: issuesStep },
  { name: 'goal', run: goalStep },
  { name: 'review', run: reviewStep },
];

Pense como… um cartório de obra: ninguém levanta parede sem a pasta carimbada — projeto, memorial, ART, alvará — e cada carimbo depende do anterior. Onde quebra: no cartório os carimbos são burocracia sobre papel; aqui cada "carimbo" é um arquivo que o passo seguinte LÊ de verdade (o Scope Gate consome o trio do passo 6).

O primeiro dos 5 gates da run é o Scope Gate: loadScope (packages/forge/src/scope.ts:37). Ele lê e valida os insumos (goal não pode ser vazio, scope.ts:44–47; contrato é parseado por Zod, scope.ts:62–67) e então materializa o layout completo do run-dir via createNewScope (scope.ts:151–269): o runId é content-addressed — runIdFor({ goal, contract, planPath }) (scope.ts:158), um run-<sha256 dos 16 primeiros hex> sobre JSON canônico (packages/swarm/src/ids.ts:19–30) — e GOAL.md, contrato e plan module são copiados para dentro do diretório.

// trecho real, não editado
const planExt = extname(input.planPath);
const planDestName = `alembic.plan${planExt}`;
const planDest = fs.joinPath(runDir, planDestName);
const planCopyResult = await copyText(input.planPath, planDest);
if (!planCopyResult.ok) return err(planCopyResult.error);

Além das cópias, o gate escreve meta.json (goal + contrato + planPath + runId, scope.ts:202–215), semeia LOOP-LOG.md e review.md (scope.ts:230–244) e cria os subdiretórios council/ units/ workflows/ park/ course/ reports/ (scope.ts:246–253) — as gavetas que os gates seguintes (Council, Proof, Validator, Publish) vão preencher.

Com --resume <run-id>, loadScope desvia para loadExistingScope (scope.ts:77–148): reutiliza o run-dir, mas ANTES compara goal, planPath e contrato contra o meta.json gravado na criação. Qualquer divergência é um err imediato — "resume mismatch: GOAL.md differs from original run" (scope.ts:106–108), idem para plan (:109–111) e contrato (:112–114). Um resume não pode trocar de escopo por acidente; journals e cache existentes são preservados.

O caminho completo tem dois comandos. alembic forge "<prompt>" roda o front-end via runForgeFrontEndCli (apps/cli/src/commands.ts:2469–2533): cria scopeDir = <dataDir>/forge/<slug> (:2480), chama ANTES o planf3 (createPlan, :2487–2490 — lição 15) para gerar o plano HTML, injeta os artefatos extraídos como planArtifacts e então executa os 7 passos. Depois, alembic run --goal GOAL.md --plan alembic.plan.ts --yes entrega o trio ao Scope Gate e a run nasce.

Bônus do pacote: um lifecycle puro

O forge também abriga lifecycle.ts — a máquina Stage/Gate do founder-core reescrita como primitivo PURO: estágios ordenados, cada um guardado por checks numéricos (gte|lte|eq|gt|lt), e checkLifecycleGate devolvendo Result onde a fonte original lançava exceção (packages/forge/src/lifecycle.ts:5–24). Sem relógio, sem aleatório — plan-VM-safe por construção, o mesmo contrato de determinismo da lição 14.