forgeos 0.1.0-alpha.70 → 0.1.0-alpha.72

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_COMPETITIVE_PLAN.md

@@ -0,0 +1,137 @@
+# Forge Agent Fabric — plano técnico final
+
+Data: 2026-10-10. Baseline: `3e7475f7a0e47be0d351d5c37355ed9f3a5c0ecd`.
+Escopo autorizado: implementação local completa com subagentes, validação focada e redução de redundâncias na CI. Nenhuma publicação, push, deployment ou instalação global faz parte desta entrega. Este plano não autoriza inferência paga para benchmarks.
+
+## Objetivo e critérios de sucesso
+
+Evoluir `program-*` para workflows de programação completos, observáveis, recuperáveis e eficientes. Superioridade competitiva exige qualidade externa, tempo e consumo por resultado correto, trabalho repetido após falha e intervenções humanas; aprovação do próprio gate não é a definição de sucesso. Comparações precisam declarar modelos, ferramentas, contexto, versões e budgets.
+
+O baseline já contém DSL finita/IR v2, schemas e tipos nominais, owner exclusivo, gates, aplicação separada, templates básicos, contexto de repositório em `run-*`, cache verificado de dependências, journal encadeado e artefatos por conteúdo. Não reconstruir esses mecanismos.
+
+## Invariantes
+
+- Modelo propõe; owner valida registry, autoridade, escopo e aceitação.
+- Completed não significa accepted. Review/checks/evidence/coverage pertencem ao candidato observado.
+- Cancelamento solicitado não comprova término da árvore de processos.
+- Efeitos não observados continuam uncertain; não há exactly-once externo.
+- Resume não repõe débitos nem estende deadlines.
+- Apply continua separado e vinculado ao gate atual; múltiplos arquivos não formam transação atômica.
+- Eventos tardios não concluem gerações sucessoras.
+- Telemetria distingue observado, estimado e desconhecido; desconhecido nunca é zero.
+- Mudanças de semântica/persistência são versionadas; não reinterpretar checkpoints antigos silenciosamente.
+- Command e adapters cooperativos não são sandbox forte.
+
+## Entregas, prioridade e dependências
+
+| ID | Prioridade | Entrega | Depende de |
+|---|---|---|---|
+| E0 | P0 | Baseline e protocolo de avaliação externa | — |
+| E1 | P0 | Telemetria durável e diagnóstico | definições E0 |
+| E2 | P0 | Round-robin real e capacidade owner configurável | E0/E1 para liberação |
+| E3 | P0 | Cancelamento, reconciliação e recuperação segura | E1 |
+| E4 | P0 | Review, bugfix e migration completos; autoria assistida | E1/E3 |
+| E5 | P1 | Contexto existente em program workers | E0/E1 |
+| E6 | P1 | Orçamento de admissão e reservas | E1/E2/E3 |
+| E7 | P1 | Eficiência de preparação/persistência | profiling E0/E1, invariantes E3 |
+| E8 | P1 | Resolução de conflitos e replan assistido | E3/E4 |
+| E9 | P2 | Harness adicional, owner background e multimodalidade | gates específicos |
+
+## E0 — baseline e avaliação
+
+Separar workloads determinísticos (runtime) de tarefas de programação (qualidade externa). Registrar configuração, versão, workload, modelo, ambiente e fontes. Medir fila, preparo, execução, captura, persistência, integração, tokens, consumo desconhecido, bytes, sucesso externo, regressões e intervenção humana. Relatório recusa tratar acceptance do próprio owner como sucesso externo.
+
+Aceite: relatórios validados, campos ausentes explícitos, condições comparáveis declaradas e métricas de sucesso definidas antes da avaliação. Benchmarks reais ficam pendentes de execução explicitamente autorizada; fixtures demonstram apenas seus contratos.
+
+## E1 — telemetria
+
+Normalizar observações de lifecycle e usage com identidade, sequência, origem, unidade e semântica delta/cumulative. Persistir usage antes de validar output final. Preservar observações em falhas e restart; deduplicar. Armazenar detalhes limitados sem credentials nem transcripts ilimitados. Expor status/explain compartilhados CLI/MCP com motivos e ações possíveis.
+
+Módulos: `codex-sdk-worker`, `program-worker`, `program-contract`, `program-service`, `program-store`, `program-view`; interfaces públicas CLI/MCP.
+
+Aceite: output inválido não apaga usage observado; duplicatas não somam duas vezes; unknown não é zero; eventos antigos não aprovam sucessor; razões de bloqueio são estruturadas. Telemetria não cria escrita de snapshot por mensagem token a token.
+
+## E2 — scheduling
+
+Filas por run e round-robin explícito entre runs elegíveis. Config owner validada (default quatro, teto inicial existente 32), run e ancestor scopes. Alteração para capacidade menor impede novas admissões sem matar atividades. Reservas uncertain permanecem ativas.
+
+Módulos: `program-scheduler`, `program-service`, `program-contract`, `program-view`.
+
+Aceite: >=3 runs continuamente admissíveis recebem atendimento; quotas respeitadas; parent controls não ocupam slots; release idempotente; cancelamento não vaza slots. Usar barreiras determinísticas, não assertions de throughput baseadas em sleeps curtos.
+
+## E3 — continuidade
+
+Observar processo/thread/workspace/candidato antes de decidir reutilização, resume thread, nova tentativa ou reconcile. SDK já suporta resume; program adapter deve recebê-lo apenas com workspace original compatível e efeitos verificados. Registrar checkpoints e observações, preservar deltas parciais e owners epochs. Expor reconciliação assistida com fatos e desconhecidos.
+
+Módulos: `program-worker`, `codex-sdk-worker`, `managed-workspace`, `program-service`, `program-contract`, `program-store`, `program-owner`, `program-lock`, `program-view`.
+
+Aceite: sem redispatch incerto/escritor duplicado; intactos independentes reutilizados; prazos/budgets preservados; workspace incompatível bloqueia resume; callbacks tardios não alteram sucessor. Não prometer cancelamento de árvore sem adapter capaz de observar essa garantia.
+
+## E4 — autoria e workflows
+
+Três templates owner-validated: revisão sem alteração, bugfix limitado, migration por população fechada. Entrada natural do agente produz proposta de template/IR; proposta não substitui registry. Schemas, scopes, checks, review e parada explícitos. Gerar refs tipadas a partir do registry. Explicar erros por operação/campo e distinguir completion/acceptance/apply. Aproveitar DSL finita e exemplos existentes; não criar interpretador geral.
+
+Módulos: `program-api`, `program-dsl`, `program-types`, `program-structure`, módulos de authoring/templates, `program-view`, CLI/MCP e exemplos.
+
+Aceite: proposta válida contém refs/criteria/checks/scopes/limites; checks obrigatórios não podem desaparecer; caso correto não exige edits; alteração invalida review incompatível; workflows executam com fixtures sem LLM.
+
+## E5 — contexto
+
+Integrar `prepareFabricRepositoryContext` existente ao clone/candidato de programas. Selecionar símbolos, contratos, dependências, checks sugeridos e lacunas por papel/atividade. Contexto limitado e identificado por snapshot; checks sugeridos não executam implicitamente. Ausência de manifesto segue diagnóstico/política explícita.
+
+Aceite: clone atual e contexto correspondem; mudanças revalidam; truncamento explícito; melhoria de qualidade ou eficiência deve ser medida, não inferida de tamanho menor do prompt.
+
+## E6 — recursos
+
+Ledger observado/reservado/estimado/desconhecido, tokens por run/owner, reservas para atividades e avaliação final. Serializar admissão agregada sob owner exclusivo, reservas duráveis associadas à tentativa. Reinício reconstrói saldo/reservas. Monetary reporting somente com modalidade/pricing declarados; subscription não vira dólar fictício. Hard enforcement somente conforme capability do adapter; demais perfis têm admission budget e overshoot possível de trabalho em curso.
+
+Módulos: `program-contract`, `program-service`, `program-scheduler`, `program-store`, `program-worker`, `program-view`.
+
+Aceite: admissões não gastam o mesmo saldo; restart não repõe; unknown policy explícita; atingir limite preserva resultados e bloqueia novos dispatches; revisão/checks conservam reserva. Não transformar orçamento em licença para omitir obrigações.
+
+## E7 — eficiência
+
+Instrumentar cache hit/verificação/cópia/instalação; materialização de workspace; serialização/validação/fsync/bytes. Aplicar melhorias locais que evitem trabalho redundante comprovado. Cache existente permanece verificado; mutable trees não são compartilhadas. Snapshot incremental, GC e cache de respostas LLM são extensões condicionais ao profiling e não obrigatórias sem gargalo demonstrado.
+
+Aceite: ganho demonstrado em workload definido; cache corrupto bloqueia; isolamento, histórico e recuperação permanecem íntegros; artefatos ligados a apply uncertain preservados.
+
+## E8 — conflitos e adaptação
+
+Resolver recebe baseline, candidatos conflitantes e contrato e produz novo candidato, sem aprovação herdada. Requer nova avaliação final. Replan propõe delta sem enfraquecer obrigações; preserva branches intactos. Repetição sem progresso termina explicitamente.
+
+Módulos: `program-service`, contratos/types/structure, worker/workspace, templates/view.
+
+Aceite: conflito não vira approval automático; candidato integrado reavaliado; checks/obligations mantidos; late callbacks fenced. Fencing local e novos operadores só entram por necessidade demonstrada.
+
+## E9 — expansão opt-in
+
+- Segundo harness nativo: schema, identidade, usage, término, cancelamento, isolamento, retomada e late callbacks conformes. CLI externa via command não basta. Adapter Claude explícito com capabilities honestas, sem bypass automático nem inferência real nesta validação.
+- Owner background local: preservar IPC autenticado, lease e recovery; pausar/uncertain não retomam implicitamente. Reutilizar startup existente, sem instalar serviço global silenciosamente.
+- Multimodal: imagem explicitamente entregue pelo adapter, provenance vinculada; receipts não demonstram compreensão. UI exige avaliação integrada final e cobertura do catálogo.
+
+## Mudanças por módulo
+
+| Módulo | Mudança |
+|---|---|
+| program-contract/service | observações, admissão, recovery, compose resolver |
+| program-scheduler | fairness/capacidade/quota |
+| program-store | observações duráveis e métricas; preservação CAS |
+| program-worker/codex-sdk-worker | lifecycle/usage/context/resume/multimodal |
+| managed-environment/workspace | profiling/materialização/compatibilidade |
+| repository-context | contexto por candidato |
+| program-api/dsl/types/structure | autoria e refs typed; resolver options |
+| program-view | diagnóstico e garantias reais |
+| program-owner/lock/project-runtime | exclusividade/background seguro |
+| cli/fabric, agent-memory/mcp, local-task-server | paridade pública e autoria sem dispatch |
+| examples/agent-fabric-v2 | três workflows completos |
+| tests/agent-fabric, scripts, CI | validação focada e redução de redundância |
+
+## Validação rápida e CI
+
+Usar poucos testes agrupados de alto valor para invariantes novas: usage+invalid output+restart, fairness>=3, orçamento concorrente, recovery incompatível, proposta/gate e resolver. Reutilizar fixtures existentes; não adicionar testes que apenas espelham implementação. Não executar modelos reais. Typecheck/lint e geração/check necessários permanecem. Uma rodada focada após integração; repetir só por mudança/falha.
+
+CI: reduzir matrix/smokes redundantes, seleção de PR fail-closed (common/unknown/missing history mantém cobertura ampla), preservar checks de contrato/segurança e checks exigidos. Não apagar testes existentes ou enfraquecer assertions para conseguir green. Branch principal preserva verificação abrangente; mudanças de packaging mantêm smoke relevante.
+
+## Gates e conclusão
+
+G1 integridade; G2 continuidade; G3 operação explicável; G4 qualidade externa nos três workflows; G5 eficiência vs baseline; G6 competitividade controlada. G1-G3 validados deterministicamente. G4-G6 ficam condicionados a avaliações representativas posteriores, não ao sucesso de fixtures nem a implementação local. Documento de evidências deve distinguir implementado, verificado, opt-in e não medido.

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_COMPETITIVE_REVIEW.md

@@ -0,0 +1,56 @@
+# Forge Agent Fabric — revisão da implementação contra o plano
+
+Data: 2026-10-10. Plano: `WORKFLOW_PROGRAM_COMPETITIVE_PLAN.md`.
+Revisão e correções locais sobre a implementação em andamento, sem commit, push ou publicação.
+
+## Método e resultado
+
+Três subagentes revisaram módulos diferentes daqueles que implementaram: runtime, workers e autoria/CI. A integração principal revisou a interface pública MCP e os limites das evidências. A revisão encontrou bugs e lacunas de implementação, corrigidos nesta entrega. Testes determinísticos foram direcionados aos caminhos afetados; nenhum modelo Codex/Claude real foi executado.
+
+## Correções por prioridade e módulo
+
+| Prioridade / etapa | Problema encontrado | Mudança e critério de aceite |
+|---|---|---|
+| P0 / E3,E5 | Recuperação podia aceitar contexto/evidências diferentes; segunda recuperação podia perder a thread | `program-worker` vincula contexto entregue, observações adicionais e bytes das evidências ao fingerprint; `program-service` persiste threadId no novo dispatch. Retomada compatível passa e incompatibilidades bloqueiam antes do modelo. |
+| P0 / E8 | Colisões arquivo/diretório e diferenças de caixa escapavam; resolver podia descartar arquivos fora de seu scope | `program-service` detecta colisões por trie e exige scope cobrindo todos os arquivos propostos. Resolver ainda produz candidato novo, com avaliação final nova. |
+| P0 / E4 | Templates aceitavam contratos de aprovação/captura sem construir o fluxo necessário | `program-templates` exige approvalSchema compatível, cria waitEvent vinculado e gate autorizado; captura exige migration com population/evidence. Perfis não suportados são rejeitados antes do dispatch. |
+| P0 / E1,E6 | Contadores inválidos ou semânticas misturadas podiam contaminar accounting | `program-observation` valida inteiros seguros, cached ≤ input e semântica por origem antes da persistência. Observações inválidas não alteram registro. |
+| P1 / interface pública | MCP author-types sem argumentos exigia runId e falhava | `agent-memory/mcp` trata a ação separadamente. Chamada autenticada com `{}` chega ao owner; argumentos extras são rejeitados. |
+| P1 / E4 | Autoria podia produzir scopes incompatíveis com executores/policy | Preflight intersecta permissões de acceptance/policy/executor e valida reviewers, checks, implementers e resolver, incluindo override explícito. |
+| P1 / E2 | Capacidade em execução não podia diminuir pela API do host | `program-scheduler` e `program-service.updateRuntimeOptions` preservam attempts ativos e limitam novas admissões. Arquivo de configuração continua aplicado no startup/restart. |
+| P1 / E6 | Usage desconhecido após apply não podia ser reconciliado | Reconciliação autenticada de usage aceita em applied, sem reabrir publicação, gate ou resume. |
+| P1 / workers | UTF-8 dividido entre chunks podia ser corrompido | Workers command/Claude usam decodificação streaming; fixture de subprocesso local preserva caracteres multibyte. |
+| P1 / CI | Bun retorna sucesso com filtro sem testes; guardas poderiam desaparecer silenciosamente | Política valida arquivos/nome dos testes; runner exige linha de resultado passing para cada gate crítico. Cobertura ampla continua nos módulos centrais. |
+| P1 / lifecycle | Razão antiga de espera permanecia após aprovação e sucesso | Serviço limpa reason ao acordar e concluir validamente, preservando razões reais de falha e histórico. |
+| P2 / E0 | Resumo individual não comparava equivalência entre relatórios | `compareBenchmarkReports` e CLI pareada verificam tasks/model/tools/context/contract/budget/criteria. Missing permanece null, contadores inválidos/overflow são rejeitados e entradas diferentes não autorizam superioridade controlada. |
+| P2 / E7 | Perfil não separava cache/preparação/execução | `managed-environment` emite cache.verify/cache.copy/dependencies.install; worker observa workspace, environment, captura e execução, inclusive falhas. Duracões aninhadas não são soma de wall time. |
+
+## Dependências e compatibilidade
+
+- ApprovalSchema e evidence executors pertencem ao registro do owner; workers não autorizam aprovação humana.
+- Resume depende de término observado, reconciliação, workspace original e fingerprint compatível. Markers antigos sem a nova vinculação não são reescritos para parecer compatíveis.
+- Redução de capacidade usa API confiável do host. Não há watcher automático nem parâmetro de workflow alterando a capacidade global.
+- Review/bugfix convenience templates não suportam diretamente captura de população; migration suporta o perfil explícito. Fluxos UI mais amplos continuam disponíveis via IR existente, não devem ser apresentados como autoria automática universal.
+- Métricas de preparação podem ocorrer antes da admissão; orçamento de tokens não mede custo de CPU/storage e não garante teto monetário.
+
+## Verificação focada
+
+| Grupo | Evidência |
+|---|---|
+| Runtime | Quatro testes focados: counters inválidos/semântica, recuperação dupla, resize sem interrupção, reconciliação pós-apply e conflitos exact/hierarchy/case. Caso de conflito: 8,78 s após trie. |
+| Workers | Dois testes direcionados, 23 assertions, aproximadamente 3 s; fingerprint adicional com 4 assertions. Git/contexto reais locais, sem provedor. |
+| Interface pública | Dois testes, 17 assertions, 2,95 s; inclui owner HTTP local autenticado para MCP author-types. |
+| Autoria/templates/benchmark/CI | Sete testes passaram em 4,99 s, incluindo aprovação humana consumida e gate novo. Seis testes unitários passaram em 316 ms após a guarda final de resultados de CI; sintaxe do runner válida. |
+| Typecheck global e lint | Exit 0 em ambos. |
+| Geração/export e framework | Geração, exports generic/codex e framework aprovados; 11 etapas, nenhuma falha, typecheck/testes omitidos somente nesta execução. Aviso existente FORGE_RLS_PGLITE_NOT_AUTHORITATIVE preservado. |
+
+Os números correspondem a rodadas específicas e não devem ser somados como testes únicos. Verificação de framework omite suíte completa e repetição de typecheck, executados separadamente no escopo indicado. Não houve instalação de dependências, GitHub Actions ou inferência paga.
+
+## O que ainda falta
+
+1. **P0 de avaliação, G4–G6:** executar avaliação independente pareada de qualidade, eficiência e robustez em tarefas representativas. Depende de inputs controlados, critérios externos e medição completa. Sem essa evidência, não afirmar superioridade sobre Claude Code.
+2. **P1 operacional:** smoke com versão real compatível do Claude CLI e execução da nova CI no GitHub. Fixtures de protocolo não comprovam compatibilidade instalada ou duração real da CI.
+3. **P2 de conveniência:** ampliar templates review/bugfix para perfis UI/população, se necessário ao produto. Hoje a rejeição explícita impede gerar programas impossíveis; IR customizado oferece o fluxo completo.
+4. **Condicionais do plano:** cache entre runs, snapshots incrementais, GC e owner distribuído permanecem extensões, dependentes de medição ou necessidade concreta. Não são apresentados como implementados.
+
+Os artefatos gerados são atualizados pelo gerador. Mudanças permanecem locais; arquivos preexistentes foram preservados. Esta revisão delimita a implementação e suas evidências, sem certificar produção ou qualidade de modelos.

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_V2_ADR.md

@@ -1,41 +1,81 @@
-# Workflow program v2 implementation decisions
-
-Date: 2026-10-07. Scope: opt-in alpha foundation, additive to the existing v1 runtime.
-The user's implementation/release instruction authorizes this code release. Earlier
-historical adoption records and their acceptance claims retain their original scope.
-
-1. The canonical program is a finite typed JSON IR. TypeScript is statically lowered
-   using a restricted AST; the owner never executes authored source. This combines
-   convenient script-like authoring with inspectable bounded orchestration.
-2. Schemas, executors, policies, acceptance and population are trusted owner registries.
-   Requests select references and cannot lower their own review or effect authority.
-   Static inference is conservative; runtime validation remains mandatory.
-3. The current local project owner hosts v1 and v2. A checksummed atomic record commits
-   decisions and immutable artifacts, including full historical stateRefs. Recovery
-   observes uncertainty before explicit resume. No power-loss or external exactly-once
-   durability claim is made.
-4. Discovery seals identity and coverage against an owner inventory. Accepted work has
-   a separate collection ledger linking assessments and contributions to the final
-   candidate. File inventory is implemented; semantic inventory adapters remain separate.
-5. Repair is a finite built-in state machine with independent implementation,
-   assessment and infrastructure budgets. Rejection or uncertainty stops consumers.
-   Candidates preserve parents, producers and ordered deltas; equal independent patches
-   conflict, and shared ancestry is applied once.
-6. Only owner-issued gates authorize a candidate. ApplyIntent freezes the complete
-   decision before writes. Local multi-file application is observable and reconciled,
-   not one filesystem transaction. Partial application never retries automatically.
-7. Barrier, additive and opt-in fenced replanning preserve history and generations.
-   Fenced replanning uses a global scheduling barrier. Independent live branch
-   replacement is deferred until a scheduler can enforce each branch's full closure.
-8. Reuse defaults off. Declared command workspace caches require attested inputs.
-   SDK output cache remains disabled until instructions/plugins/model inputs are closed.
-   Commands are cooperative host processes; strong sandbox claims are rejected for them.
-9. Initial authoring/runtime budgets are finite. A shared capacity wait rechecks the
-   count after waking. Maximum-scale performance and archive/GC are not established.
-10. The procedural benchmark is labelled as a reference scheduler, not Claude Code.
-    Real SDK proof is a readonly typed activity. Full coding quality, integration
-    acceptance, production delivery and product superiority require additional evidence.
-
-See [the executable contract](../../agent-fabric-programs.md),
-[reviewed design plan](WORKFLOW_PROGRAM_V2_PLAN.md) and
-[verification evidence](WORKFLOW_PROGRAM_V2_EVIDENCE.md).
+# Agent Fabric workflow runtime: decisão normativa
+
+
+
+Status: implementado em desenvolvimento, 2026-10-07. O usuário dispensou compatibilidade com Forge legado. Não há interpretador operatorVersion 1 nem migração automática de checkpoints antigos. Use runs novos ao trocar a semântica do runtime.
+
+
+
+## Autoria e estrutura
+
+
+
+TypeScript finito com 50 construtores públicos produz JSON IR schemaVersion 2/operatorVersion 2. O lowerer não executa código: aceita imports nomeados do módulo Forge, const, dados finitos, spreads de objetos const, `as const`, `satisfies` e imports de tipos de autoria. Rejeita callbacks, acesso ao filesystem, chamadas arbitrárias e loops JavaScript. Tipos nominais distinguem refs de schemas, executores, políticas, aceitação, populações, receitas e programas. JSON IR também é aceito diretamente; ambos passam pelo mesmo validador owner e pelas mesmas verificações de tipos/esquemas.
+
+
+
+O grafo inclui dependências de dados e `after`. Posição textual não ordena roots: `sequence` ordena filhos, `parallel` executa filhos requeridos com diagnóstico collect-all ou cancel-siblings. Blocks com vários filhos exigem `result`; shorthand de um filho é permitido. Branch, loop, map e subworkflow têm contextos léxicos explícitos. Loop retorna estado final. Map retorna envelope de coleção com itens identificados, outcome separado do dado, resultados, falhas e seal. IDs de membros usam NFC antes da unicidade, comparação UTF-8 e encoding único de segmentos. Coleções são finitas e seladas.
+
+
+
+## Owner, limites e recuperação
+
+
+
+Um owner exclusivo por diretório de estado usa lease com PID/token/epoch. Um segundo owner vivo é rejeitado; morte permite recuperação conservadora. O scheduler limita atividades, não controles pais: owner 4, run por política e scopes ancestrais por map. Fairness round robin entre runs elegíveis. Fila é persistida antes da admissão; limite absoluto de run vale também na fila.
+
+
+
+Intent/debit/reserva são persistidos antes de execute. Tentativa sem resultado observado é uncertain e retém sua reserva; restart reconstitui reservas. Timeout/cancel não prova término de árvore de processos. Worker sem confirmação de cancelamento não bloqueia close indefinidamente; permanece uncertain, sem redispatch ou apply. Reconciliação exige observação externa, não mera intenção de repetir. Resultado observado mas inválido é invalid_output e libera slot. A preparação cancelada não é despachada.
+
+
+
+Completed íntegro do MESMO run é reutilizado antes de preparar workspace/adapter. Digests fecham executor, inputs, candidato, escopo e contratos pinados. Artifact perdido/corrompido bloqueia; não vira cache miss. Isso não é cache entre runs e não prova replay exatamente uma vez de efeitos externos. Repair checkpointa rounds/assessment/infra antes da fase; resume não repõe débitos.
+
+
+
+Wait é waiting e não falha. Irmãos independentes continuam; eventos e deadlines absolutos acordam o scheduler enquanto o owner está vivo. Restart requer resume explícito. Eventos têm request CAS, identidade, target/generation/type/correlation, schema, proveniência, subject e expiry. Idempotência inclui subject/expiry. O host deve autenticar a origem da proveniência; texto vindo de worker não vira autorização humana.
+
+
+
+Barrier replan invalida ramos alterados e dependentes, preservando intactos; additive preserva templates existentes. Fenced replan é opt-in e conservador: parada global e uncertain até observação. Não há fencing local distribuído. Política/contrato/executor atuais são conferidos novamente antes de NOVO dispatch e apply; fatos históricos continuam legíveis.
+
+
+
+## Candidatos e aceitação
+
+
+
+Executor read não tem autoridade de alteração; isolated-write produz deltas com beforeimages em clones. Command é cooperativo; não se apresenta como sandbox forte. Codex usa sandbox e rede desabilitada; subprocessos/agentes internos não ganham garantia fictícia de quota agregada. Só owner registra CandidateRef, DeltaRef e receipts a partir de tentativas observadas.
+
+
+
+Owner AcceptanceContract declara critérios, obrigações por item/final, checks distintos e bindings de assessments. Autor não omite checks mandatórios. AssessmentContext traz candidato, invocation/assessment IDs, obrigações, ambiente e EvidenceRefs. Capturas PNG/JPEG/WebP têm limites de bytes/dimensões/pixels, origem da tentativa, candidato/build/env/item/route/viewport/state. Consumidores recebem arquivos readonly; metadata só não prova render correto ou qualidade visual. Limites: 8 MiB/imagem, 32 MiB/lote, 100 imagens/lote.
+
+
+
+Repair assess-first evita edição sem defeito. Aprovação exige findings vazios, checks passados e cobertura integral das obrigações. Report incompleto é inconclusive, sem edição. Infra/capture inválida é diferente de finding visual. Item assessment fecha o ledger local; compose integra candidatos compatíveis. Conflito para em needs-resolution, sem merge automático. Final assessment recaptura e verifica TODA a população sobre o candidato integrado atual; receipts locais antigos não substituem aceitação final.
+
+
+
+Gate exige o mesmo candidato, contratos, geração, seal, cobertura e tentativas distintas observadas. Partial/quorum exigem permissão owner e não aprovam por si uma obrigação all-required. Quorum tem threshold explícito e espera todos os outcomes assentarem. Collect-all produz diagnóstico e não avalia result de scope requerido falho. Se aprovação humana for exigida, gate consome sinal autorizado bound ao candidato/contrato; decline/expiry/fabricação não aprovam. Apply é ação separada, com autorização, gate congelado, beforeimages e reconciliação de publicação incerta.
+
+
+
+## Persistência, inspeção e limites
+
+
+
+R2.2: envelopes format 3 contêm ponteiros para snapshot e nó de journal imutáveis SHA256; nós encadeiam parentRef/version/runId. O histórico acumulado e o snapshot não são duplicados no envelope. Escrita atômica/fsync publica o envelope por último. Runs novos usam program-runs-v3, sem migração. Mutação interna sem mudança não escreve checkpoint; receipts autenticados continuam persistidos. Owner e store compartilham recuperação de reclaim abandonado. Transações são serializadas por run; definitions validadas são memoizadas pelo digest, sem dispensar verificação do envelope. History, explain, artifact-get e diff compartilham CLI/MCP/owner. Artifact-get só aceita refs alcançáveis pelo run; não lê paths livres.
+
+
+
+A durabilidade é local, com owner vivo; não há promessa de serviço remoto/App fechado. Sem GC automático, cache cross-run, streaming ilimitado, race, código TS arbitrário, YAML nativo, múltiplos harnesses completos ou resolução automática. Nenhuma superioridade sobre Claude DW foi medida. Validação sem LLM é requisito: FORGE_FABRIC_TEST_MODE=1 recusa factories reais Codex; adapters determinísticos e SDK stubs são permitidos. Qualidade de modelo permanece fora da evidência.
+
+
+
+## Correções R2.2
+
+
+
+Plano: WORKFLOW_PROGRAM_V2_CORRECTIONS.md. Subworkflow herda signal/scopes/item/estado lexical e não substitui população. visualCases vincula captura a rota/viewport/estado/dimensões esperados; requiredEvidence segue o escopo das obrigações. Receipt batch commit é atômico com o resultado observado. Ref/operation/expression generics preservam conexões de autoria; schemas owner continuam a autoridade. program-explain expõe grafo/Mermaid e instâncias separadas.

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_V2_CORRECTIONS.md

@@ -0,0 +1,39 @@
+# Agent Fabric: plano de correção e acabamento R2.2
+
+Objetivo: fechar os achados da revisão independente de 07/10/2026, mantendo TypeScript finito → IR → owner → scheduler → evidências → gate → apply. Sem compatibilidade legada e sem testes com LLM. Não é uma promessa de superioridade empírica sobre Claude DW.
+
+## 1. Contexto e capacidades de subworkflow
+
+Herdar signal, scopes de atividades, dependências e identidade do item. Manter item e estado do loop como contexto lexical do chamador; workflowInput é o input explícito do filho. O filho não pode substituir policy, acceptance nem population do root. Verificar map concurrency=1 com várias atividades no filho, cancel-siblings, identidade de item e contratos herdados.
+
+## 2. Um protocolo de lease para owner e store
+
+Unificar admissão por hardlink, identidade PID/token, assert antes de release e reclaim de titulares mortos. Recuperar guardas abandonados sem retirar leases vivos. Testes determinísticos cobrem guarda morta, guarda viva, owner morto, exclusão e identidade alterada. PID vivo desconhecido continua conservador; não prometer exatamente uma vez.
+
+## 3. Obrigações e cobertura visual
+
+Derivar captura somente das obrigações aplicáveis ao assessment. Obrigações item se expandem para o item corrente ou toda a população no assessment final; obrigações final só se aplicam na fase final. Introduzir population.visualCases, um caso por member com itemKey, route, viewport, state, width e height esperados. Catálogo informado deve cobrir exatamente os members e ter tuplas únicas. Conferir receipt contra o catálogo antes de registrar. Captura final recobre todos os casos ativos. Sem catálogo visual, a garantia continua cobertura por item; não inferir todas as UIs. Header de imagem não prova renderização nem qualidade visual.
+
+Agrupar registros de capturas com o resultado observado da tentativa em uma transação; blobs são persistidos antes dela. Falha deixa blobs órfãos, nunca evidência aceita parcialmente.
+
+## 4. Tipos de autoria
+
+Adicionar generics de input/output nas refs, operações e expressões, output(operation), field com chaves verificadas e inputs tipados nos executores/subworkflows. Generics não substituem schemas do owner. Permitir inputSchema opcional no executor e validar antes de preparar/dispatch. O lowerer continua produzindo o mesmo IR, sem executar código. Testes de compilação devem demonstrar erros reais de tipo; exemplos devem baixar no mesmo lowerer.
+
+## 5. Persistência e perfil determinístico
+
+Remover a duplicação do snapshot inteiro no envelope e a regravação do histórico acumulado em cada transação. Persistir snapshot e nó de journal imutáveis, com parentRef/version/runId; publicar por último envelope compacto de ponteiros e receipts CAS. Read valida integridade e checkpoint; history percorre e valida cadeia/versionamento. Artefato perdido/corrompido bloqueia. Sem migração: runs antigos devem ser recriados.
+
+Medir todos os bytes efetivamente escritos, divididos em snapshot, journal, envelope e artifacts, com perfil fixo em 12/48/96 itens, fault+resume e zero chamadas a modelo. Relatar custo local e limites sem extrapolar throughput de LLM. Não agrupar intent/debit/dispatch de modo que enfraqueça recuperação.
+
+## 6. Autoria e inspeção
+
+Expor grafo estático e Mermaid em program-explain, com tipos, dependências e estado; distinguir templates de expansões observadas. Adicionar template de map → subworkflow com input explícito e um exemplo de população visual desktop/mobile. Documentar diagnóstico, herança, tipos, persistência e limitações no guia público/ADR/skill do repo.
+
+## Entrega e aceitação
+
+Executar generate, check, typecheck, testes determinísticos direcionados e verify framework com FORGE_FABRIC_TEST_MODE=1. Nenhum provider/LLM real, deploy ou publicação npm é necessário para esta correção. Registrar resultados e limites em relatório de entrega. Preservar alterações anteriores e restaurar apenas ruído gerado que já estava limpo antes desta rodada.
+
+## Estado final
+
+Implementado e validado em desenvolvimento. Última suíte completa: 1679 aprovados, nenhuma falha, 4 skips condicionais existentes; 11 gates passaram. Evidência detalhada: WORKFLOW_PROGRAM_V2_CORRECTIONS_EVIDENCE.md. O runtime e a validação herdam o contexto lexical do filho; inferência mantém rejeição de campos inexistentes.

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_V2_CORRECTIONS_EVIDENCE.md

@@ -0,0 +1,53 @@
+# Evidências das correções Agent Fabric R2.2
+
+Data: 07/10/2026. Fonte: working tree de C:/Users/stahl/Projects/forge, baseado em 083077bdc9aee74e81d941a67c3c38bd31d8e2d0 (forgeos 0.1.0-alpha.70). Não representa npm publicado, instalação global ou commit novo.
+
+## Implementação
+
+Subworkflow agora também recebe contexto lexical no preflight e na inferência de schemas, alinhado à execução; uso de item fora de map e campo inexistente continuam rejeitados.
+
+As seis frentes de WORKFLOW_PROGRAM_V2_CORRECTIONS.md estão implementadas: herança de contexto de subworkflow; lease compartilhado com recuperação de guardas mortos; captura por escopo/catálogo visual; conexões genéricas com schemas owner; persistência compacta/journal encadeado/no-op; templates e grafo/Mermaid. Capturas de uma tentativa são registradas atomicamente com seu resultado observado. Formato 3 usa program-runs-v3 e preserva sem carregar os diretórios anteriores.
+
+## Validação
+
+FORGE_FABRIC_TEST_MODE=1 em todos os comandos das suítes determinísticas desta revisão. Nenhum provider/LLM real foi executado nessas suítes. Os executores de teste são fixtures locais ou adapters/SDK stubs. O smoke real autorizado separadamente está documentado abaixo.
+
+- Generate, check e typecheck passaram.
+- Rodada inicial: 90 testes/4 arquivos, zero falhas, incluindo fixture de 20 páginas.
+- Rodada final direcionada: 43 testes/3 arquivos, zero falhas, incluindo templates/catálogo, quotas/cancelamento do filho, lock/reclaim, schema input/default, histórico compacto e fixture de empacotamento.
+- Verificação framework final: 1679 aprovados, 0 falhas, 4 skips condicionais existentes; 280 arquivos/71 chunks; todos os 11 gates passaram. A última rodada inclui o novo teste lexical de subworkflow. Generate/check/typecheck e exports foram renovados depois da correção final.
+- Regressão lexical adicional: 39 testes de workflows passaram, sem falhas. Os tipos de autoria incluem provas negativas via @ts-expect-error, compiladas no typecheck.
+
+Duas tentativas anteriores de verify framework falharam: exports de adapters desatualizados e uma asserção de concorrência baseada em 20 ms; depois, timeout de 10 s da fixture de empacotamento sob carga. Adapters foram regenerados, o teste de overlap usa barreira determinística, cleanup das fixtures tem limite de 30 s e subprocesso de empacotamento tem limite de 60 s. As asserções foram preservadas; uma rodada completa com dois jobs passou; após a correção lexical final, outra rodada completa com quatro jobs também passou. Nenhum gate foi desativado.
+
+## Perfil determinístico
+
+Adapter fixo, tarefas de 3 ms, uma falha em item-7 e close/reopen/resume. Cada conjunto teve uma repetição. Dados e hashes estão em FABRIC_CORRECTIONS_PROFILE.json na entrega da conversa.
+
+| Itens | Cold ms | Recovery ms | Disk bytes | Chamadas no recovery | Irmãos intactos repetidos | Transações recovery |
+|---|---:|---:|---:|---:|---:|---:|
+| 12 | 1930 | 1187 | 1008335 | 1 | 0 | 11 |
+| 48 | 13927 | 11727 | 9775520 | 1 | 0 | 11 |
+| 96 | 38570 | 26688 | 34308647 | 1 | 0 | 11 |
+
+Snapshot bytes escritos no cold: 766630 / 8948318 / 32700773. Envelope: 32427 / 118436 / 233156. Journal: 25875 / 94820 / 186788. Métricas incluem bytes temporários efetivamente escritos; locks não estão incluídos nas categorias de conteúdo. Pico de atividades observado: 1 nas tarefas de 3 ms; teste com barreira verifica overlap de duas roots. Não inferir throughput a partir de tarefas curtas.
+
+## Smoke real autorizado (2026-10-07)
+
+Uma execução curta do ProgramRunService com o adapter Codex real, modelo gpt-6.1-sol, modo data, executor investigador somente leitura, dependências desativadas, uma tentativa e timeout de 60 s. Repositório Git temporário com um único arquivo; resultado persistido {"ok":true}, status completed, arquivo original intacto. Duração: 28.979 ms. Uso informado pelo SDK: 20.421 tokens de entrada, 0 em cache, 15 de saída. A entrada foi maior que o esperado apesar do prompt mínimo; não houve nova chamada para otimização.
+
+Run: program-ec04371b16d7e8f844054d5b11ed011e. Thread Codex: 01a117e1-0e51-7261-ab3a-3e0cacd02432. Uma tentativa owner-visible concluída. O teste comprova o caminho básico owner/scheduler/workspace/SDK/schema/persistência; não comprova qualidade dos modelos, fluxos complexos, pixels de UI ou superioridade empírica sobre Claude DW. A restrição anterior de zero LLM aplica-se às suítes determinísticas; somente este smoke foi autorizado separadamente.
+
+## Limites da evidência
+
+## Gate de publicação Linux e correção concorrente
+
+A primeira tentativa de publicação da alpha.71 (GitHub Actions 37676855215, commit bf77032f) foi bloqueada: 1.841 testes passaram, 5 tiveram skip condicional e um falhou. A corrida ocorria quando um replanejamento aditivo invalidava a versão semântica durante a persistência do gate; o erro "Gate inputs changed" interrompia o programa antes do recálculo. Não houve publicação dessa tentativa.
+
+O runtime agora distingue a invalidação AF_PROGRAM_REVISED de falhas de execução, aguarda os irmãos e recalcula controles somente enquanto o programa segue executando com um plano diferente. Uma falha real de irmão tem prioridade e continua bloqueando conclusão. O teste usa barreira explícita antes do commit do gate e cobre ambos os casos, sem dependência de timing ou chamadas LLM.
+
+## Limites do runtime
+
+A validação direcionada também expôs uma corrida de shutdown: o ciclo era removido de active antes de terminar a leitura assíncrona do finalizador. close agora aguarda esse finalizador antes de liberar o owner, e um teste com barreira mantém a leitura pendente para verificar a retenção do ciclo. Nenhuma dessas correções usa chamadas LLM.
+
+Snapshots completos ainda dominam armazenamento e custo computacional; a otimização remove duplicação/journal acumulado e writes sem mudança, mas não torna o custo linear. Tempos são locais sob carga e não comparam Claude DW. Não há medida de qualidade/custo/produtividade dos modelos. Catálogo visual delimita casos exigidos; header e metadata não comprovam pixels/estado reais. WebP continua limitado a VP8X. Commands são cooperativos; não há sandbox forte geral. Durabilidade continua local, sem exactly-once externo, GC automático ou serviço distribuído.

package/docs/architecture/agent-fabric/WORKFLOW_PROGRAM_V2_EVIDENCE.md

@@ -1,109 +1,49 @@
-# Workflow program v2 verification evidence
-
-Date: 2026-10-07. Baseline: c8dfdf0c0c3cd6610bab68b4872ab9dcf8d4214c.
-Release target: forgeos 0.1.0-alpha.70. The release workflow binds its exact pushed SHA.
-
-## Scope established locally
-
-Focused suites cover finite AST lowering and schema constraints, typed references,
-80-item coverage/seals, owner-issued receipts, acceptance/candidate linkage, bounded
-repair and restart, event targeting, barriers/generations, data-only completion,
-immutable history, byte budgets and uncertain publication. Actual command-process
-fixtures cover two independent files, three successive same-file deltas, diamond
-composition, independently identical conflicting patches, authenticated owner
-transport and concurrent apply idempotency. Existing v1 SDK tests are retained.
-
-The initial strict framework TestGraph completed all 277 files/71 chunks with test
-status pass. The overall verify invocation failed on stale generic/codex adapter
-exports, which were then regenerated. Final release gates must be read from their
-actual local/CI outcomes; that initial adapter failure is not represented as a pass.
-
-## Independent implementation review
-
-A read-only subagent independently reproduced and verified fixes for forged receipts,
-input/result contracts, persistent counters, late worker outcomes, old additive gates,
-failed repairs masked by trailing values, omitted item contributions, retired branch
-ledgers and static-binding byte expansion. It ran 50 tests, then 6 focused delta tests,
-with zero failures. No remaining reproduced blocker was identified in that scope.
-This is implementation review of a bounded alpha, not complete plan/product acceptance.
-
-## Real Codex SDK pilot
-
-Started 2026-10-07T13:01:42.961Z; completed 13:02:22.229Z.
-Model gpt-6.1-sol, one attempt, outcome completed, status completed.
-Thread 01a11674-ab47-7b81-88b7-d5137124d19e.
-A typed readonly activity returned the exact fixture answer fabric-v2-pilot; the source
-input was unchanged. The reviewer inspected the persisted record, result artifact,
-source and nine transitions without spending a second model call.
-This does not establish SDK migration/review/application, production or App-closed
-operation. Reproduction is explicitly opt-in:
-
-    node --import tsx scripts/pilot-fabric-program-sdk.mjs --yes --model MODEL --output REPORT
-
-## Bounded recovery benchmark
-
-Three deterministic local runs: 80 items, concurrency four, two observed infrastructure
-failures, owner close/reopen/resume. Every run produced 80 results in 82 adapter calls,
-retaining 78 successful outputs. The pure fixture adapter explicitly attests reusable
-inputs. A procedural reference also completed in 82 calls; it has no equivalent disk
-journal, worker clones or models. The harness does not run Claude Code.
-
-| Observed mean | Fabric | Procedural reference |
-| --- | ---: | ---: |
-| Full elapsed | 49.276 s | 0.164 s |
-| Recovery elapsed | 29.333 s | not equivalent |
-| Retained disk | about 58.7 MB | no durable journal |
-
-There were 81 materialized operations and 897 transitions per Fabric run. These results
-show significant persistence overhead and bounded recovery correctness, not speed
-superiority, actual token/cost savings or maximum-scale acceptance.
-Reproduction: node --import tsx scripts/benchmark-fabric-programs.mjs --output REPORT.
-
-## Remaining acceptance
-
-Independent live branch scheduling, semantic inventory, extensible recipe registries,
-SDK output reuse, automatic GC, filesystem power-loss durability, maximum-scale tests,
-full SDK coding workflow and comparison against actual Claude Code remain unestablished.
-EasyGrow, production, human acceptance and native hook completion retain their earlier
-separate gates. The release includes the executable example and contract documentation.
-
-## Final local release gates
-
-After regenerating the stale adapters, verify framework passed all 11 steps, with the
-entire 277-file/71-chunk TestGraph, no skipped gates and elapsed 508.643 s. The warning
-about PGlite RLS being structural is retained; Postgres authoritative proof belongs to
-release CI. Focused v2+SDK suites passed 63 tests/210 expectations. After the separate
-template dependency adjustment, template/audit policy suites passed 8 tests/47 expectations.
-
-The eight-target dependency gate passed after overriding the Nuxt template's devtools
-to 4.0.0-beta.4, removing its vulnerable simple-git dependency. An attempted simple-git
-4.0.2 override passed audit but failed actual template typechecking because the old
-consumer imported its removed default export; that attempt was discarded. The accepted
-devtools adjustment passed real npm installation, generation, dev-once and smoke verification
-including typechecking in a fresh Nuxt template. Existing two scoped, expiring high-severity
-advisory exceptions were preserved, with no new exception. This is not a claim of zero
-advisories across the generated Nuxt dependency graph.
-
-The first packed-package smoke passed installation, CLI, repository maps, app generation/
-verification, native hook runner smoke, studio open and wrapper scaffold. A second run
-adds actual installed v2 DSL/example validation; its outcome and exact release CI SHA
-are recorded in the user-facing delivery report after execution.
-
-The final packed smoke passed, including importing the installed v2 authoring module
-and lowering/validating the shipped five-step example against its registry. The local
-package reported version 0.1.0-alpha.70. This smoke ran from an actual npm tarball,
-not a dry-run or a source-only import.
-
-## CI correction before publication
-
-The first exact-SHA release run 37630439335 was blocked before publication: 1797 tests
-passed, five platform/opt-in tests were skipped, and the pre-existing POSIX exporter
-cleanup test failed. SIGKILL had been requested without waiting for group termination.
-The fix observes the owned detached process group with signal zero until ESRCH, bounded
-at five seconds; unknown cleanup remains an error and preserves its scratch directory.
-A deterministic regression fixture models two still-live observations after the signal.
-Linux/WSL runtime suites passed 17 tests/74 expectations; Windows runtime suites passed
-16 tests/72 expectations, with the new POSIX-only case separately skipped on Windows.
-The independent reviewer approved the code/error-path delta (SHA256
-563B878677FDE2BC82539AEB5020D84F72DCECE0FDB6AB19B94F0EE69D476997).
-This is cooperative process-group cleanup, not universal process-tree containment.
+# Evidências: Agent Fabric workflows R2.1
+
+Data: 2026-10-07. Base do trabalho: 083077bdc9aee74e81d941a67c3c38bd31d8e2d0, forgeos 0.1.0-alpha.70. Implementação de desenvolvimento; não é uma publicação npm. O usuário dispensou compatibilidade legada e proibiu testes reais com LLM. Nenhum piloto SDK/modelo foi executado nesta implementação; relatos de pilotos anteriores não são evidência da revisão atual.
+
+> Registro da implementação R2.1. A revisão posterior R2.2 corrige herança de subworkflow/locks/capturas e muda o formato de persistência; consulte WORKFLOW_PROGRAM_V2_CORRECTIONS.md e WORKFLOW_PROGRAM_V2_CORRECTIONS_EVIDENCE.md. Os números abaixo são históricos desta rodada R2.1.
+
+## Núcleo entregue
+
+DSL/IR operatorVersion 2 com cinquenta construtores de autoria e quinze controles. Grafo com dependências de dados/after, sequence/parallel e Blocks explícitos. Quotas de atividades em owner/run/scopes, reserva/debit/queue persistidos, owner exclusivo, waiting e deadlines, completed íntegro reutilizado antes de prepare, replan seletivo e incerteza conservadora. Contratos owner por item/final, evidência binária imutável, review/checks/capturas ligados ao candidato, ledger local, compose, aceitação final integral e aprovação humana separada de apply. Catálogo API e exemplo atuais em docs/agent-fabric-programs.md e examples/agent-fabric-v2/ui-audit.workflow.ts. Skill distribuída atualizada.
+
+## Verificações focadas
+
+Uma execução focada completou 93 testes em cinco arquivos, zero falhas e 311 assertions: program-v2, program-v2-process, program-workflows, program-ui-fixture e codex-sdk-worker. SDK usa factories simuladas. Checks adicionais cobrem tipos/results dentro de Blocks/map e callbacks tardios de SDK: o owner antigo não altera o sucessor. O typecheck passou, incluindo o mesmo exemplo TS compilado/lowered e uma prova negativa de refs nominais. Testes de commands/apply executam processos Node determinísticos e Git temporário, não modelos.
+
+A verificação ampla inicial encontrou exports de adapters stale, uma expectativa de teste que assumia ordem de receipts com IDs aleatórios e um timeout isolado na fixture antiga de limpeza de pacote. Exports foram regenerados; expectativa passou a localizar conteúdo/candidato sem assumir ordem; a fixture antiga passou isoladamente sem alteração. Um teste novo de deadline foi ajustado para estabelecer primeiro reservas incertas com prazo normal e só então exercitar a fila bloqueada com prazo curto; assim não assume throughput do host durante a admissão. A execução ampla final passou: onze gates, 279 arquivos/71 chunks, 1667 testes e zero falhas; nenhum gate pulado. O callback tardio recebeu adicionalmente 43 testes focados e typecheck após sua alteração; outputs de geração/adapters foram reconferidos no fechamento. O primeiro resultado não é representado como sucesso.
+
+## P2: fixture UI
+
+Vinte páginas HTML locais com três defeitos conhecidos, executores command determinísticos e owner inventory: exatamente três implementações, 43 capturas (20 iniciais + 3 após correção + 20 finais), 20 capturas frescas finais e 21 obrigações finais satisfeitas. Destino preservado porque o exemplo não chama apply. Uma fixture separada usou Edge headless sobre uma página HTML local e produziu três screenshots reais (baseline, candidato corrigido e final), uma implementação, duas obrigações finais e zero LLM. Nenhuma prova de qualidade visual/modelo é inferida dessas fixtures.
+
+## P3: profiling determinístico
+
+Script reproduzível: scripts/benchmark-fabric-workflows.ts. Dataset congelado: doze itens, delay simulado 3 ms, uma falha em item-7, concorrência permitida quatro, três repetições com owner close/reopen/resume. Digest sha256:58c9295b62663693d909726bfef8e2ae3779d20507caabfd9161b705f46e3412.
+
+| Repetição | Inicial ms | Recuperação ms | Attempts | Calls na recuperação | Calls intactos repetidos | Disk bytes |
+|---|---:|---:|---:|---:|---:|---:|
+| 1 | 1389 | 1124 | 13 | 1 | 0 | 2141322 |
+| 2 | 1343 | 1224 | 13 | 1 | 0 | 2141031 |
+| 3 | 1374 | 1147 | 13 | 1 | 0 | 2141472 |
+
+As tarefas simuladas de 3 ms apresentaram pico observado um devido à persistência; não se confunde limite quatro com overlap efetivo. Métricas incluem transações/tempo/bytes por owner e retained disk. Serialização por run resolveu contenção; validação de definitions é memoizada por digest, mantendo checks de envelope/artifact. Não há comparação de velocidade com datasets antigos diferentes, benchmark Claude, custo/token real ou superioridade de produto comprovada.
+
+## Rastreabilidade da matriz
+
+| Cenários | Evidência técnica |
+|---|---|
+| T01–T09, T11–T16 | program-workflows + program-v2: grafo/controle/scopes, eventos/deadlines, reprise, falhas/reservas, artefatos e replan |
+| T10 | aprovação/declínio vinculados a candidato; owner gate rejeita receipt fabricado; nenhuma autorização por dado de worker |
+| T17, T22, T34, T42 | intent/debits persistidos, repair limitado/restart, outputs sem observação, gap de parent commit, SDK stub e fuse real-factory |
+| T18–T23, T26, T36–T37 | UI fixtures: imagem inválida/ambiente errado/cobertura incompleta/check omitido/final completo/regressão final, zero-edits quando correto |
+| T24–T25, T27–T29 | commands reais em Git temporário: conflitos, diamond/beforeimages, gate/candidate, apply idempotente/uncertain, readonly sem autoridade |
+| T30–T31 | finite AST, tipos/schema, IDs/ciclos, import/callback/I/O rejeitados, bounded expansion |
+| T32 | sandbox/capabilities e defaults SDK verificados com factory simulada; isolamento command cooperativo declarado, sem promessa de controle de agentes internos |
+| T33 | revogação live bloqueia novo dispatch; histórico completado continua legível; apply revalida owner |
+| T38–T40 | quorum explícito/settled, collect-all diagnóstico, NFC/encoding/order e user data separada de outcome |
+| T41 | owner exclusivo, restart incerto e reconstrução/liberação de reservas; filesystem power-loss e todos os interleavings não são alegados |
+| T35, T43 | Fora do núcleo: não existe GC/resolução automática; nenhuma extensão foi ativada |
+
+Limites: sem cache cross-run, distributed execution, live fencing local, race/streaming ilimitado, GC/resolução automática ou múltiplos harnesses completos. Durabilidade é local com owner vivo; nem qualidade LLM, produção, App fechado ou superioridade sobre Claude DW foram verificados. Testes de modelos dependem de autorização futura e não são gates desta entrega.