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

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

@@ -1,550 +1,590 @@
-# Implementation status, 2026-10-07
+# Plano implementado: Agent Fabric workflows R2.1
 
-This is the reviewed R2.1 design plan, including proposed illustrative syntax. For the
-executable alpha contract and its conservative F6/F7 boundaries, read
-[program workflows](../../agent-fabric-programs.md),
-[implementation decisions](WORKFLOW_PROGRAM_V2_ADR.md) and
-[evidence](WORKFLOW_PROGRAM_V2_EVIDENCE.md). An implementation release does not mark every
-future acceptance item in this plan complete.
+Este documento preserva os requisitos e a revisão do plano. A implementação adota a arquitetura diretamente, conforme a decisão posterior do usuário de ignorar compatibilidade legada. Estado e evidências da implementação: WORKFLOW_PROGRAM_V2_EVIDENCE.md; contrato operacional: WORKFLOW_PROGRAM_V2_ADR.md. Correções e acabamento R2.2 estão em WORKFLOW_PROGRAM_V2_CORRECTIONS.md; o ADR e o guia de API prevalecem sobre detalhes históricos de armazenamento/autoria abaixo. Extensões da seção 22 continuam fora do núcleo.
 
-# Agent Fabric: plano corrigido para workflows expressivos e duráveis
+# Plano revisado do Agent Fabric Workflows
 
-Data: 7 de outubro de 2026. Estado: proposta de evolução, não implementação nem aceite de produto. Revisão R2.1: incorpora os dois bloqueios e as seis correções importantes encontrados na revisão independente de R1, mais a clarificação de escopo da revisão integral R2. A versão final é submetida ao mesmo novo revisor. Todas as APIs, tipos e arquivos v2 abaixo são propostas, salvo indicação explícita de capacidade existente.
+Versão editorial R2.1, 07/10/2026. Baseline observado: Forge `083077bdc9aee74e81d941a67c3c38bd31d8e2d0`, alpha.70. O corpo abaixo preserva o plano na data da proposta; a implementação e suas correções são registradas nos documentos indicados na introdução. A arquitetura R2 recebeu confirmação independente; R2.1 incorpora a restrição posterior do usuário de não executar testes reais com LLM. Antes desta implementação, o baseline publicado alpha.70 reconhecia operatorVersion 1; o working tree atual implementa operatorVersion 2. A versão npm não foi incrementada/publicada nesta rodada. O número da versão comercial futura será escolhido na implementação, sem ser inferido deste documento.
 
-Baseline de código consultado: `C:\Users\stahl\Projects\forge`, commit `c8dfdf0c0c3cd6610bab68b4872ab9dcf8d4214c`. Os documentos e alterações locais já existentes não foram substituídos. O plano não autoriza mudanças de código, novos workers pagos, publicação, deploy ou configuração global. A implementação futura usará a autorização que o usuário conceder para seu escopo, sem solicitar confirmação redundante para cada passo reversível.
+**Restrição vigente de validação: nenhum teste, piloto ou benchmark pode chamar LLM real, incluindo CLI/SDK de agentes, providers pagos, assinatura ou modelos locais.** Usar executores determinísticos, mocks/stubs de transportes e fixtures. Não iniciar comandos/subprocessos que possam acessar um modelo como fallback. Avaliação com modelos reais fica adiada e requer nova autorização explícita do usuário; sua ausência não bloqueia a entrega técnica do runtime, mas limita as alegações de qualidade do produto.
 
-## 1. Objetivo e critérios de sucesso
+## 1. Objetivo e critério de sucesso
 
-O objetivo é permitir que Codex e desenvolvedores escrevam workflows que descubram trabalho, distribuam tarefas, avaliem resultados, corrijam candidatos e integrem alterações, com uma forma de autoria tão acessível quanto um programa de orquestração. O runtime deve preservar estado, evidências e decisões durante falhas e intervenções.
+Criar uma solução programática para múltiplos agentes com autoria acessível, execução explícita, trabalho concluído recuperável e obrigações verificadas pelo runtime. A proposta de valor combina expressividade, recuperação, revisão, cobertura e integração; não depende de usar YAML, de permitir mais agentes ou de adicionar mais operadores.
 
-A meta de superar Claude Code Dynamic Workflows deve ser avaliada, e não assumida. O diferencial pretendido é combinar autoria expressiva, recuperação por dependências, continuidade explícita de candidatos e intervenção humana persistida. Formato JSON, número de agentes, schemas ou pareceres adversariais não demonstram superioridade isoladamente.
+O objetivo de superar Claude Code Dynamic Workflows será avaliado por dimensão e em tarefas/configurações delimitadas: menos chamadas repetidas após falha, cumprimento de obrigações, menos falsos aceites/regressões, esforço de autoria aceitável e custo total observado. Não declarar superioridade geral a partir de fixtures ou do formato da DSL.
 
-Critérios de produto:
+## 2. Baseline e mudanças desejadas
 
-1. Uma lista descoberta durante execução pode gerar trabalho sem o coordenador escrever um nó e um executor manualmente para cada item.
-2. Revisão negativa alimenta correção dentro do workflow sem aprovar o resultado final.
-3. Reinício conserva candidatos, resultados válidos, decisões e obrigações; não repete efeitos desconhecidos silenciosamente.
-4. Alterar um ramo não repete ramos independentes com entradas ainda compatíveis.
-5. Integração, revisão e checks finais observam o mesmo candidato integrado.
-6. Um evento humano autorizado altera o comportamento futuro de forma persistida e auditável.
-7. Quantidade de itens, concorrência, contexto, tempo e uso são limitados por política externa ao programa.
-8. Autoria, execução e inspeção permanecem disponíveis pelo Codex; o usuário não precisa operar uma segunda interface ou escrever requests JSON.
+| Área | Alpha.70 observada | Alvo deste plano |
+|---|---|---|
+| Autoria | Subconjunto finito TS e IR JSON; opções genéricas | Mesmo núcleo, tipos discriminados, referências tipadas e diagnósticos com localização |
+| Scheduling | Raízes percorridas sequencialmente, referências resolvidas sob demanda; map concorrente | Dependências de dados e controle, scopes explícitos, fila pronta persistida e quotas separadas |
+| Waiting | Falta de evento lança erro; na raiz needs-attention, em map vira failed | Suspensão durável do ramo, sem consumir slot e sem contar como falha |
+| Resume SDK | Resultado completo passa pelo caminho de preparação/cache, sem reuso SDK nativo | Continuação de invocação intacta devolve resultado persistido sem nova chamada |
+| Revisão | Repair com candidate/review/checks/budgets | Preservar; acrescentar evidências de avaliação e diagnósticos de fase |
+| Aplicação | Gate e ApplyIntent congelado, reconciliação | Preservar fronteira e vincular todas as novas evidências ao candidato exato |
+| Persistência | Snapshots completos/histórico a cada transação | Instrumentar; otimizar somente após profiling e testes de recuperação |
+| UI/browser | Sem integração automática com browser do chat | Adaptador explícito e artefatos duráveis vinculados à build/candidato |
+| Providers | Codex e comandos | Consolidar esse contrato; outros harnesses como extensão posterior |
 
-## 2. Baseline implementado e lacunas
+O plano anterior do repo diz que a ordem de steps não cria sequência; o executor atual percorre as raízes com await e pode antecipar uma raiz por forward reference. P0 resolve essa divergência formalmente. Não apresentar o comportamento atual como sequência estrita.
 
-O Fabric atual já tem tarefas acompanhadas `attached-*`, snapshots, revisão distinta, checks, cobertura e prontidão. Possui reducer de workflow com dependências, decisões, joins, tentativas, gerações, revisões e invalidação transitiva. Runs gerenciados `run-*` despacham SDK e comandos, criam clones, compõem artefatos das dependências e aplicam mudanças locais com gates. Esses fatos foram conferidos no código; o piloto SDK real de 05/10/2026 está registrado nos docs, mas não foi reexecutado para escrever este plano.
-
-Limitações relevantes:
-
-| Situação existente | Evolução proposta |
-| --- | --- |
-| Cada nó gerenciado exige executor explícito | Templates e fábricas validadas materializam nós e executores |
-| Replan exige ausência de tentativas ativas/incertas | Primeiro barreiras seguras; depois extensão independente e fencing por ramo |
-| `changes_requested` marca falha e bloqueia o run | Resultado operacional separado do verdict; feedback consumível |
-| Relatório SDK fixa campos genéricos | Envelope operacional com saída tipada por etapa e artefatos por referência |
-| Obrigações ligadas a nós `required` | Contrato de aceite estável, separado da topologia das rodadas v2 |
-| Eventos de status são uma janela limitada | Histórico durável de operações e projeções compactas de progresso |
-| Limites gerenciados de 32 nós e concorrência 4 | Expansão paginada e limites distintos de template, itens, janela e concorrência |
-| Bridge acompanhado invalida pelo escopo inteiro | Preservar conservadorismo v1; melhorar v2 somente com entradas completas |
-
-Não há garantia atual de App fechado, wakeup, serviço de sistema, encerramento de toda árvore de processos ou atomicidade da aplicação de múltiplos arquivos contra desligamento. Esses limites não são apagados pelo desenho v2.
-
-## 3. Decisão arquitetural
-
-Preservar o reducer puro, os mecanismos de concorrência, capturas, artefatos e reconciliação. Acrescentar uma camada de programa e um contrato v2, sem redefinir silenciosamente as APIs ou os resultados dos runs v1.
-
-```text
-Pedido no Codex / autoria humana
-              ↓
-DSL tipada e limitada de workflow
-              ↓ validação e lowering sem executar código arbitrário
-ProgramIR versionada: templates, expressões, schemas e obrigações
-              ↓ expansão persistida conforme os resultados
-ExecIR: operações materializadas, dependências, gerações e tentativas
-              ↓
-Owner: scheduler, journal, políticas, workers e artefatos
-              ↓
-Gates de candidato, revisão, checks e aplicação local
-```
-
-O DAG é uma projeção materializada do trabalho corrente; não precisa conter todas as iterações e itens futuros desde o início. O programa contém templates para materializá-los.
-
-Workflows de aplicação do Forge e workflows do Fabric continuam subsistemas distintos. Podemos reutilizar primitives compatíveis de idempotência, persistência e retry depois de mapear seus contratos; seu runtime atual não deve ser apresentado como um interpretador pronto de programas dinâmicos.
-
-## 4. Autoria v2: uma DSL, não TypeScript arbitrário
-
-Escolha inicial: DSL com aparência e tipos TypeScript, compilada por um lowerer que reconhece um subconjunto declarativo. O lowerer não importa e executa o módulo do usuário para obter um objeto.
-
-Subconjunto inicial: imports declarativos somente da biblioteca DSL versionada; literais; bindings constantes sobre esses literais; referências de dados; construtores de operações; templates aninhados e expressões puras reconhecidas pelo compilador. Condições e seletores usam operações como `eq`, `and`, `field` e `output`, convertidas a uma AST de expressão tipada. Sem `eval`, closures arbitrárias, I/O, imports dinâmicos, acesso ao relógio, aleatoriedade ou leitura implícita de variáveis de ambiente.
-
-O catálogo de transformações puras deve ser finito, versionado, limitado em tempo/tamanho e validado. Bibliotecas e módulos não reconhecidos falham na validação; não são executados para descobrir seu significado. Uma transformação complexa pode virar atividade explícita com entradas, saída e política próprias. Não esconder efeitos em expressões.
-
-Antes de congelar a autoria ou implementar o compilador de produto, produzir ADR semântica e um protótipo limitado de expressividade. Comparar opções de autoria sobre a mesma IR quando necessário, sem construir dois runtimes de produto. Se uma API assíncrona restrita for preferível, uma ADR substitutiva deve definir replay, isolamento e compatibilidade; não prometer compilação genérica de `async`/closures.
-
-O protótipo precisa expressar pesquisa com filtro/deduplicação/ranking e resultados parciais, migração de 80 itens, loop com estado acumulado, branch com saídas diferentes e merge tipado, map aninhado/subworkflow, conflito de integração e evento enviado antes do wait. Medir tamanho do programa, erros de autoria e clareza da inspeção. A aparência TypeScript não comprova equivalência à expressividade de um script JavaScript.
-
-Schemas, executores, receitas e contratos externos usam referências de registry com versão e digest, resolvidas pelo owner sem executar módulos de autoria. Schemas inline só podem usar literais reconhecidos. Um símbolo importado de um módulo arbitrário não é um schema válido da DSL. Referências de outputs inferem dependências; a ordem do array steps não cria sequência implícita. O programa declara uma expressão result compatível com outputSchema, inclusive os estados de negócio permitidos.
-
-Operações mínimas de ProgramIR:
-
-| Operação | Semântica |
-| --- | --- |
-| `agent` | Worker com papel, prompt/entradas, schema de saída, efeito e limites |
-| `command` | Comando com argv explícito, parser/classificação de resultado e política de efeitos |
-| `map` | Expande coleção persistida usando identidade estável, template, limite e política de conclusão |
-| `branch` | Seleciona ramos por expressão pura ou decisão estruturada de agente |
-| `loop` | Materializa rodadas com estado persistido, progresso e término explícitos |
-| `compose` | Combina candidatos com ancestralidade e política de conflito |
-| `gate` | Avalia obrigações e evidências sobre um candidato identificado |
-| `subworkflow` | Invoca programa versionado, com identidade de invocação e orçamento herdado |
-| `waitEvent` | Aguarda entrada humana/externa autorizada, tipada e persistida |
-
-`repair` é uma receita versionada de biblioteca sobre agent/command/loop/gate; não introduz um segundo motor. Toda invocação, inclusive no body de map, recebe ID estável. Seus passos internos usam namespace de invocação/item/rodada/etapa. Checkpoints são fronteiras de commit do runtime; um operador de checkpoint explícito pode etiquetá-las, mas nenhuma etiqueta sozinha garante durabilidade.
-
-Branch registra a seleção e valida o merge tipado. Ramos não selecionados ficam skipped e não prendem o join; isso não remove obrigações externas de aceite. Uma decisão de agente só seleciona alternativas autorizadas pelo owner. Subworkflow fixa programa/operadores, identidade de invocação, profundidade e orçamento herdado; retry do pai não cria outro filho nem repete efeitos do filho. Cancelamento e incerteza pertinentes propagam ao pai. Recursão fica desabilitada inicialmente.
-
-## 5. Contratos de dados e identidades
-
-Tipos conceituais propostos:
+## 3. Arquitetura
 
 ```text
-WorkflowProgram: schemaVersion, workflowId, programVersion, programDigest,
-  DSLVersion, operatorVersions, inputSchema, outputSchema,
-  templates, acceptanceRef, policyRef
-
-Run: runId, programDigest, baselineRef, acceptanceVersion, policyVersion,
-  stateVersion, status, journalCursor, scopes, budgets
-
-LogicalOperation: logicalStepId, templateId, invocationPath, itemId?, round?,
-  generation, localSemanticDigest, dependencies, executorSpec, inputRefs
-
-Attempt: attemptId, logicalStepId, generation, inputDigest, executorIdentity,
-  executionOutcome, startedAt, completedAt?, receipts, outputRef?
-
-StepOutput: schemaId, schemaVersion, dataRef, artifacts[], evidence[], summary
-
-Candidate: candidateId, snapshotDigest, baselineRef, parentCandidateRefs[],
-  artifactRefs[], producerAttemptRefs[]
-
-CandidateDelta: deltaId, inputCandidateDigest, outputCandidateDigest,
-  beforeimages, changes, producerAttemptRef
-
-Assessment: assessmentId, candidateRef, verdict, findings[], checkResults[],
-  assessorAttemptRef, provenance
-
-PopulationContract: populationId, version, baselineRef, definition,
-  inventoryValidatorRef, allowedExclusions, allowNoWork, requiredEvidence
-
-CoverageManifest: populationContractRef, expectedMembersRef, observedMembersRef,
-  exclusionsWithReasons, inventoryDigest, discoveryDigest, provenance, verdict
-
-CapabilityContract: adapterIdentity, argv, cwd, effectiveEnvironmentRef,
-  tools, network, candidateWriteScope, allowedGeneratedPaths, isolationEvidence
-
-ApplyIntent: intentId, candidateDigest, gateReceiptId, populationDigest,
-  collectionSeals, programRevision, acceptanceVersion, policyVersion,
-  authorizationRefs, targetBaseline, beforeimages, expectedAfterimages
+Chat/CLI/SDK de autoria
+        ↓
+DSL TypeScript finita ou IR JSON
+        ↓ lowering estático + validação + plano de capacidades
+IR versionada com dados, controle, scopes e obrigações
+        ↓
+Owner autenticado: registry, estado autoritativo, scheduler
+        ↓
+Atividades: Codex / comandos / adaptadores aprovados
+        ↓
+Resultados tipados, candidatos, evidências e receipts
+        ↓
+Composição → avaliação integrada → gate → aplicação autorizada
 ```
 
-`logicalStepId` identifica o trabalho, não o conteúdo nem a posição atual na fila. Sua identidade deriva de caminho de invocação, operação, item estável e rodada. `attemptId` é outra identidade para cada execução concreta. Conteúdo alterado muda o inputDigest e a geração aplicável, não necessariamente o item lógico.
-
-A chave de map precisa ser única e estável. Duplicatas ou colisões de normalização são erros visíveis. Índices de lista não são identidades. Paths só servem como itemId se o contrato tratar renames; o exemplo usa um ID de componente separado do path. Ordem de enumeração e ordem de composição são declaradas e normalizadas.
-
-Referências são imutáveis, vinculadas ao run ou a uma fonte permitida. Um worker não pode introduzir referências arbitrárias ao filesystem, fabricar receipts ou usar handles pertencentes a outra revisão. Resolver uma referência sempre revalida escopo, digest e disponibilidade.
-
-Candidate é uma descrição imutável de snapshot. Aceite, rejeição e supersessão são eventos/projeções vinculados ao digest, não campos mutáveis no objeto. Delta descreve a transformação entre dois snapshots; não confundir patch com snapshot completo.
-
-## 6. Resultado operacional separado de avaliação
-
-`executionOutcome`: `completed | infrastructure_failed | invalid_output | uncertain | canceled_confirmed`.
-
-`reviewVerdict`: `approved | changes_requested | inconclusive`.
-
-Uma revisão pode terminar como completed e retornar changes_requested. Isso produz feedback válido, mas não aprova o candidato. Schema inválido não vira reprovação de negócio: é invalid_output e só tem retry sob política explícita. Inconclusive não é aprovado nem refutado.
-
-Comandos possuem resultado observado de processo separado do significado de um checker. Um exit code não zero esperado pode significar completed com checkResults.failed. Falha de lançamento, deadline ou processo sem resultado conhecido são categorias próprias. A classificação é definida pelo adaptador/política versionados; o modelo não redefine quais códigos significam teste aprovado.
-
-O envelope de relatório operacional é controlado pelo executor. O payload de negócio usa schema por etapa, validado antes de consumo. Schemas, resolvers e validators têm digest/versão; requests e objetos têm limites de tamanho e profundidade. Relato agent_reported continua distinto de observação executor_observed e de aceite humano.
-
-## 7. Transporte de dados, artefatos e contexto
-
-Dados pequenos são serializados e validados; dados grandes, patches, logs e imagens vão a artefatos imutáveis referenciados por digest. Persistir metadata e resumo no estado quente, evitando copiar relatórios inteiros para cada prompt ou recibo.
-
-Workers recebem seleção explícita de entradas e referências das dependências, com resolvers somente leitura limitados ao escopo e ao orçamento. Dados de outros agentes são fonte não confiável, não instrução que amplia autorização. Mensagens de coordenação pertencem ao contrato do owner.
-
-Chunks, paginação e streaming de coleções precisam de integridade e versão. Para v2 inicial, discovery produz uma coleção finita persistida; streaming incremental virá depois. Não concluir um map porque a janela atual esvaziou enquanto ainda há itens não materializados.
-
-Garbage collection só remove artefatos fora das referências de runs ativos, checkpoints, retenção de recuperação e relatórios publicados. Antes de remover, calcular reachability; replay com artefato ausente falha explicitamente e não dispara um efeito externo para tentar reconstruí-lo.
+O owner é a autoridade local do projeto; sua existência não implica serviço distribuído, funcionamento com App fechado nem wakeup instalado. O runtime pode ser compartilhado sem instalar Forge como dependência do projeto alvo. CLI/MCP/cliente futuro usam a mesma autoridade e o mesmo estado.
 
-## 8. Persistência, checkpoints e replay
+O registry confiável contém schemas, executores, políticas, contratos de aceite, populações e child programs versionados. Cada run fixa seus contratos. Um plano gerado por agente não amplia permissões nem substitui o registry. Dados, imagens e relatórios dos agentes são entradas não confiáveis, não autorização.
 
-Transições de run, expansão, tentativa, evento humano e intent de efeito precisam de commit durável antes do despacho correspondente. ACK só confirma estado persistido. Reutilizar requestId exige corpo idêntico; mutations usam versão esperada. Preservar as invariantes de CAS e replay existentes.
+## 4. Modelo público e compatibilidade
 
-Implementar um journal durável versionado e checkpoints, com recuperação de gravações incompletas, integridade e monotonicidade de cursors. A janela de eventos para UI é uma projeção desse histórico, não o único registro de causalidade. A ADR define uma única fonte autoritativa de transições, integrada ao store existente; não manter dois stores independentes com dual write. Checkpoints são folds derivados, validados contra cursor/digest do journal. Artefatos precisam estar persistidos e íntegros antes de confirmar outputRefs. Staging, commit e recuperação de órfãos fazem parte do contrato.
+Manter schemaVersion da persistência e operatorVersion como eixos diferentes. Proposta: operatorVersion 2 identifica as novas semânticas de scheduling/scopes/wait/resume. Se novas estruturas de persistência exigirem migração, usar discriminador próprio; não fingir compatibilidade binária apenas mantendo schemaVersion 2.
 
-Especificar separadamente falha do processo e perda de energia. Flush, replace e garantias reais do filesystem/host precisam de evidência; não atribuir durabilidade contra desligamento a um rename ou ACK em memória.
+Programas operatorVersion 1 continuam interpretados por seu comportamento histórico. Não migrar runs ativos automaticamente. Uma conversão gera proposta/diff, explicita dependências de controle e exige confirmação do owner dentro da autorização da tarefa. Não deduzir silenciosamente ordem a partir de uma lista ambígua.
 
-O reinício não restaura uma pilha JavaScript. Reconstrói ProgramIR, ExecIR, estado de loops/maps, outputs, decisões e intents a partir de dados persistidos. Expressões puras são reavaliadas sobre as mesmas entradas persistidas; chamadas de agentes já concluídas retornam sua saída válida sem nova chamada.
+O novo formato tem `mode: "data" | "candidate"` para ergonomia. Em data, resultado tipado não autoriza publicação. Em candidate, o resultado que declara aceite precisa do gate do owner. Nenhum perfil pode enfraquecer política, cobertura ou autoridade de efeitos. Perfis são configurações do mesmo núcleo, não dois runtimes.
 
-Isso não torna o modelo determinístico: replay reutiliza a saída observada. Uma nova tentativa pode produzir outro resultado e recebe attemptId próprio.
+Blocos canônicos usam `{ steps, result }`. Blocos de map/loop/subworkflow e braços de branch têm escopo lexical. Um body contendo uma única operação é um shorthand: o lowerer cria o bloco e sua expressão de resultado. Não usar implicitamente a última operação de um bloco com várias etapas como resultado. Referência entre irmãos usa IDs locais; referência a um filho interno de outro scope é inválida. Só o resultado público do scope atravessa sua fronteira.
 
-Fingerprint de reutilização inclui entradas completas, candidato e artefatos, prompt, schemas/validators, semântica local de template/receita/operadores, executor, configuração efetiva de modelo quando observável, ferramentas, ambiente/lockfiles e política pertinente. O inputDigest captura o estado realmente preparado, não apenas o hash declarado pelo autor.
+## 5. Semântica de ordem, dependências e scopes
 
-programDigest global registra auditoria; localSemanticDigest determina compatibilidade da operação. Adicionar um item independente não invalida todos os itens pelo hash global. Membership e proveniência da coleção são separados das entradas individuais; aggregators e operações que dependem do conjunto recebem o digest do conjunto fechado. Mudança de texto descritivo sem efeito semântico não altera a compatibilidade. Mudança de operador/intérprete exige regra explícita de compatibilidade; o default é recusar reuso sem prova.
+No operatorVersion 2, `steps` no nível de grafo é um conjunto finito de operações identificadas; ordem textual não é aresta. Referências de output/candidate/evidence criam dependências de dados. O campo comum `after: [stepId, ...]` cria dependências de controle que não exigem consumir dados. `after` é campo, não uma função JavaScript executada.
 
-Output de geração antiga nunca satisfaz diretamente a nova geração. Um ReuseReceipt validado registra output original, nova operação/geração, fingerprint e regra de compatibilidade. Sem observação confiável de read set, incluir todo o snapshot preparado visível ao worker, mesmo que isso reduza reuso. WriteScope pequeno não prova read scope pequeno.
+Uma operação fica pronta somente quando todos os predecessores exigidos satisfazem o contrato. “Processo terminou” não equivale a “dependência satisfeita”: repairs requeridos precisam de aceite, waits requerem decisão válida e scopes exigem join. Falha não satisfaz after. Receber uma decisão válida de declínio por waitEvent pode concluir a espera, mas não autoriza escrita/aplicação: after/sequence ordenam controle, e o owner exige a decisão aprovadora vinculada quando policy requer autorização. Uma política de collection pode representar um resultado parcial de forma explícita, sem converter falhas em sucesso.
 
-Sem observação completa das entradas, usar invalidation conservadora. Eventos SDK não garantem um read set completo. Dependências externas mutáveis exigem observação versionada ou não são reutilizáveis. Cache cross-run fica desabilitado inicialmente; reuso no mesmo run depende de compatibilidade comprovada.
+`sequence` adiciona arestas de controle em ordem declarada e tem resultado explícito. Referência de uma etapa anterior à saída de uma posterior no mesmo sequence cria ciclo e é rejeitada. `parallel` permite executar filhos independentes quando prontos; dependências entre filhos continuam valendo. O pai não ocupa um slot de worker aguardando seus filhos. Join e cancelamento pertencem ao scope.
 
-Mudança de programa não altera uma execução em curso implicitamente. Continuar com versão antiga ou pausar e aplicar migração explícita, com diff de operações, efeitos sobre inputs e aceite, referências de evidência e nova revisão. Não migrar tentativas incertas. Versões antigas permanecem interpretáveis durante sua retenção.
+`parallel.onFailure` inicialmente suporta `collect-all` e `cancel-siblings`. O primeiro coleta desfechos em ScopeResult persistido para diagnóstico; um filho obrigatório falho impede sucesso do scope. O campo result é avaliado somente após join bem-sucedido; na falha, output(scope) não fornece valor de sucesso. status/history/explain expõem os outcomes sem inventar output de filho falho, null ou recovery implícito. Não adicionar outcome()/catch ao núcleo inicial. O segundo solicita cancelamento dos filhos pendentes/ativos, preserva os completos e aguarda observação/reconciliação. Não implementar race ou “primeiro resultado ganha” sem contrato separado de efeitos.
 
-## 9. Distribuição dinâmica e fechamento de map
+Todos os roots declarados pertencem ao scope raiz; trabalho obrigatório falho não pode desaparecer porque result referencia apenas um subconjunto. Arms não escolhidos são skipped, sem obrigações ativas. Ordem de agregação e de composição é determinística; ordem de conclusão de workers pode variar. Não prometer reproduzir o mesmo interleaving de efeitos externos.
 
-Map contém template, coleção versionada, chave, política de conclusão, limite de itens, concorrência e ordem de agregação. Materialização persiste itemId, operação, geração e claim antes do dispatch. Filas são paginadas; a janela materializada pode ser pequena mesmo com muitos itens.
+## 6. Catálogo completo das funções de autoria desejadas
 
-Default para migração: `completion: all-required`. Pesquisa pode declarar parcialidade ou quorum; o relatório deve mostrar itens falhos/incertos e não apresentar cobertura completa. Essas políticas não podem reduzir um requisito externo de cobertura total. Após quorum, cancelamento dos demais trabalhos exige resultado observado; incerteza pertinente impede conclusão sem reconciliação, mesmo que o número de respostas já seja suficiente.
+Este é o catálogo fechado do núcleo proposto, não uma promessa de JavaScript irrestrito. A significa função existente cujo contrato é preservado/aprimorado; N significa função proposta. Recursos de fases posteriores são marcados no texto. Não incluir funções internas de hashing/locking como APIs de workflow.
 
-Map só conclui após coleção fechada, cobertura da população validada, todos os itens obrigatórios em estado terminal aceito, agregação persistida e nenhuma tentativa incerta pertinente. Um seal é imutável. Antes de aplicar, item tardio cria nova versão da coleção, invalidando gates/aggregators pertinentes; não edita o seal antigo. Durante aplicação segue a fronteira da seção 12. Após run terminal, trabalho adicional exige revisão sucessora explícita e vinculada; não altera retroativamente o run nem seus arquivos aplicados.
+### 6.1 Definição e referências de registry
 
-### População e cobertura independente da descoberta
+| Função | Estado | Contrato |
+|---|---|---|
+| `defineWorkflow(definition)` | A | Define identidade, versões, schemas, policy, mode, população opcional, steps e result |
+| `schemaRef(id, version)` | A | Referência a schema resolvido e fixado pelo owner |
+| `executorRef(id, version)` | A | Referência a executor autorizado, com schemas/capacidades/efeitos |
+| `policyRef(id, version)` | A | Referência a limites e autoridade; não alteração de policy |
+| `acceptanceRef(id, version)` | A | Obrigações e critérios definidos pelo owner |
+| `populationRef(id, version)` | A | Catálogo fechado, baseline, evidência e exclusões justificadas |
+| `recipeRef(id, version)` | A | Receita versionada; inicialmente repair built-in, não extensão arbitrária |
+| `programRef(id, version)` | A | Child program registrado, sem import/eval arbitrário |
 
-All-required comprova todos os itens da coleção recebida, mas não comprova que discovery encontrou todos os itens do objetivo. PopulationContract externo fixa baseline, definição da população, validator registrado e exclusões permitidas. CoverageManifest compara membros esperados e observados, registra origem/digests e justificativas de exclusão. O owner valida a cobertura por inventário/validator independente do agente de discovery; não aceita a própria declaração de completude do agente como prova.
+### 6.2 Operadores de execução
 
-Quando a população é enumerável, omissões, extras fora do escopo e exclusões sem autorização impedem seal aceito. Renames seguem o mapeamento de identidade do contrato. Se o alvo é semântico, globs ou inventário AST não provam sozinhos que todos os casos semânticos foram encontrados: o contrato precisa da evidência/avaliação adequada, e cobertura inconclusiva fica needs-attention. Não prometer prova universal de discovery por LLM.
+Todos usam ID estável e opções discriminadas. Campos comuns: after, label e input onde pertinente. Recursos/efeitos efetivos são a interseção da solicitação com a policy/registry. A autoria não declara autoridade nova.
 
-Coleção vazia não produz sucesso por verdade vacuamente satisfeita. Só pode gerar resultado explícito no-work se allowNoWork estiver autorizado e a ausência de trabalho tiver evidência independente suficiente para o objetivo. Caso contrário é cobertura inválida/inconclusiva. No-work satisfaz apenas obrigações cujo contrato admite esse resultado e não gera uma aplicação vazia disfarçada de migração concluída.
+| Função | Estado/fase | Contrato e resultado |
+|---|---|---|
+| `value(id, {value})` | A | Calcula expressão pura finita, sem I/O; resultado é o valor tipado |
+| `agent(id, {executor,input,candidate?,writeScope?})` | A/P1 | Executa agente registrado; output entrega seus dados tipados, candidato/evidência permanecem identidades separadas |
+| `command(id, {executor,input,candidate?,writeScope?})` | A/P1 | Executa argv registrado e retorno tipado; não shell arbitrário do autor |
+| `map(id, {items,key,coverage?,completion,quorum?,concurrency,body,order})` | A/P1 | Fan-out finito, chaves únicas, seal e ledger; retorna CollectionResult tipado |
+| `branch(id, {condition,then,else})` | A/P0 | Seleciona um bloco; condition booleano validado, merges tipados, outro braço skipped |
+| `loop(id, {initialState,maxRounds,body,next,until})` | A/P1 | Rodadas com state/counters persistidos; next e until têm contratos de tipo explícitos |
+| `repair(id, options)` | A/P1/P2 | Receita de implementação/avaliação limitada, com candidato e critérios; ver seção 11 |
+| `compose(id, {candidates,onConflict})` | A/P1 | Integra lineage compatível, conserva produtores; conflito preserva inputs e bloqueia; continuidade por resolução é extensão posterior |
+| `gate(id, {candidate,coverage?,authorization?})` | A/P1/P2 | Owner verifica obrigações e emite GateReceipt para o candidato exato; não aplica arquivos |
+| `subworkflow(id, {program,input})` | A/P1 | Materializa child program registrado, herdando autoridade e limites globais |
+| `waitEvent(id, {type,correlation,schema,subject?,timeoutMs})` | A/P1 | Aguarda evento autorizado, devolve dados/receipt tipados, sem contar espera como falha |
+| `sequence(id, {steps,result})` | N/P1 | Scope com arestas de controle em ordem explícita |
+| `parallel(id, {steps,result,onFailure})` | N/P1 | Scope com paralelismo estruturado, join e política de falha/cancelamento |
 
-Backpressure controla itens pendentes, workers ativos, bytes de artefatos e retenção de resultados. Não resolver escala apenas aumentando o limite de 32 nós. Introduzir limites distintos de templates, itens, operações materializadas totais, janela ativa, tentativas e concorrência. O default inicial não aumenta concorrência 4 sem medição.
+`map.key` deve produzir string Unicode válida. V2 normaliza NFC **antes** de verificar unicidade e rejeita colisões; v1 conserva sua regra histórica de rejeitar keys não NFC. Default proposto de 256 bytes UTF-8 por key, com limite efetivo fixado pela policy antes do dispatch. A key canônica é usada em invocation, seal, evento, ledger e resultado; o original é apenas metadata. Scope path é tupla de segmentos; representação textual usa um único encoding percent UTF-8 sem ambiguidades, sem concatenação crua e sem dupla decodificação. Slash/separadores dentro da key nunca criam scopes. `map.order` inicialmente é `key` ou `input`; default v2 `key`, ordenação por bytes UTF-8, sem localeCompare. Ordem input usa ordinal persistido no seal. É ordem de resultado, não de dispatch nem identidade.
 
-## 10. Loops e receita de repair
+`completion` deve ser declarada: all-required, partial ou quorum. Partial/quorum só são admitidos por contrato owner compatível, nunca alimentam gate all-required por acidente. `quorum: { minAccepted: K }` é obrigatório para quorum, proibido nos demais modos; K inteiro entre 1 e o tamanho do seal. Collection vazia segue decisão no-work explícita, sem quorum 0 implícito. Em data, contar outputs válidos segundo o contrato; em candidate, somente contribuições aceitas. Failed, inconclusive, canceled e skipped não contam. Atingir K não fecha cedo: o núcleo exige todos os outcomes observados e settled. Waiting conserva obrigação e mantém collection aberta. Deadline pode fixar timeout terminal permitido pelo contrato, sem esconder efeito incerto nem retirar obrigação required. Abaixo de K ao final: collection reprovada e diagnóstico, sem result de sucesso. Quorum com 2/3 e um waiting permanece aberto; se o terceiro terminar por timeout admitido, pode fechar apenas se o contrato aceitar esse desfecho. Unknown/uncertain nunca é settled para liberar gate/apply. Fechamento antecipado exige extensão owner específica para remaining, cancelamento e reconciliação, fora do MVP.
 
-Loop tem estado tipado, limite de rodadas e tempo, critérios de progresso, predicate de aceite, política de exaustão e mapa de artefatos/candidatos por rodada. Cada rodada materializa novas identidades; não recicla tentativas para simular continuidade.
+`map.concurrency` limita atividades ativas no subgrafo do map, incluindo implement/review/check/evidence, e não a quantidade de itens em voo. Um futuro scope activity limit usa a mesma unidade. Pais e waits não ocupam slot; todos os limites de ancestral/run/owner são aplicados conjuntamente. Limite de itens em voo, se necessário, recebe campo separado e não muda a definição de concurrency.
 
-Recipe repair fixa entryMode, progressPolicy, limites e versão. Implement-first executa a primeira migração antes da avaliação. Assess-first avalia o candidato recebido e pode retornar accepted com zero implementações; é o default de integração. Em ambos os modos, revisão/checks da decisão observam exatamente o mesmo candidato.
+CollectionResult canônico proposto: `{ items: [{key,outcome,valueRef?}], sealRef, totals, coverageReceiptRef?, contributionLedgerRef? }`. As saídas de filhos são resolvidas por referências tipadas; a experiência de autoria pode oferecer projeção de dados sem duplicar conteúdo no estado. Esse envelope não é uma lista que pode ser filtrada para esconder falhas. acceptedCandidates/coverageReceipt leem registros emitidos pelo owner.
 
-Recipe repair:
+ScopeResult é diagnóstico autoritativo acessível por status/history/explain, não um envelope adicional de output(sequence/parallel). Loop devolve state final tipado somente quando until é satisfeito; exaustão preserva state/diagnóstico na inspeção e bloqueia output de sucesso. Branch arms e loop body usam Block. `loop.next` é avaliado após body terminar e ter seus outputs públicos; `until` usa o state novo e outputs permitidos. Terminação falsa após maxRounds produz exhaustion visível. Uma rodada não pode remover obligations de rodadas anteriores sem contrato próprio; loop não é escape de budgets.
 
-1. Receber candidato inicial, critérios, escopo e checks.
-2. Preparar workspace sobre o candidato anterior, aplicando sua ancestralidade.
-3. Conforme entryMode e avaliação anterior, executar implementação ou correção com feedback vinculado ao candidato observado; assess-first não modifica um candidato já aceito.
-4. Capturar novo artefato e candidato, validando beforeimages e writeScope.
-5. Executar revisão distinta e checks configurados sobre esse candidato.
-6. Se satisfeito o gate da rodada, registrar aceite do candidato; senão persistir findings e decidir a próxima rodada permitida. Inconclusive permite reavaliação/escalada limitada por política; não é ordem automática para editar código.
-7. Em interrupção/efeito incerto, parar esse ramo para reconciliação; não transformar incerteza em reprovação comum.
+### 6.3 Expressões puras e referências de resultados
 
-Não exigir aprovação de todos os candidatos antigos. `supersedes` identifica a substituição, conservando história e razões; não autoriza apagar requisitos. O candidato final precisa cobrir as obrigações ainda vigentes.
+| Função | Contrato |
+|---|---|
+| `workflowInput()` | Entrada tipada e congelada do programa corrente, inclusive child |
+| `item()` | Item corrente do map; inválido fora desse contexto |
+| `loopState()` | State da rodada; inválido fora de loop |
+| `output(id)` | agent/command: dados tipados; sequence/parallel: Block.result após join válido; branch: result do braço escolhido; subworkflow: result público do child program; loop: state final quando until satisfeito; repair/map: envelopes tipados; falha obrigatória não entrega valor de sucesso |
+| `field(value,key)` | Acesso a propriedade conhecida; campo obrigatório ausente é erro, não undefined silencioso |
+| `literal(value)` | Literal JSON finito, com budgets de profundidade/bytes |
+| `object(fields)` | Objeto de valores/expressões com chaves permitidas |
+| `array(...values)` | Lista finita de valores/expressões |
+| `eq(left,right)` | Igualdade canônica dos tipos permitidos; sem coerção JS |
+| `and(...values)` | Conjunção de booleanos |
+| `or(...values)` | Disjunção de booleanos |
+| `not(value)` | Negação de booleano |
+| `concat(...arrays)` | Concatenação com budget antes da alocação |
+| `filter(values,key,equals)` | Seleção pura por igualdade de campo; não é step nem callback livre |
+| `unique(values,key)` | Unicidade determinística; não dispensa map validar todas as chaves originais |
+| `sort(values,key)` | Ordenação estável explícita; tipos/normalização definidos |
+| `take(values,count)` | Prefixo limitado; não enfraquece population/coverage |
+| `length(value)` | Tamanho permitido pelo tipo registrado |
+| `population()` | Contrato/manifesto do owner para o programa, não catálogo inventado pelo agente |
+| `acceptance()` | Critérios e digest fixados pelo owner |
+| `candidateFromBaseline(entry)` | Candidato inicial sobre o baseline capturado; entry descreve o item, não concede writes |
+| `outputCandidate(id)` | Candidato observado produzido por atividade/compose; não implica aceite |
+| `acceptedCandidate(id)` | Candidato com assessment válido de repair/controle correspondente |
+| `acceptedCandidates(id)` | Candidatos/contribuições aceitas de collection fechada, sem omitir obrigações |
+| `coverageFor(contract,discovered)` | Solicita validação owner da descoberta contra o catálogo; não declaração literal de completude |
+| `coverageReceipt(id)` | Receipt owner da collection relevante, seal e obrigações |
+| `acceptanceWriteScope(id)` | Escopo do contrato de aceite, limitado pela policy |
+| `approvedChecksFor(entry)` | Checks owner da avaliação do item, resolvidos por fase/contexto; não lista escolhida pelo autor |
+| `acceptanceChecks(id)` | Checks owner da avaliação correspondente ao ID/contexto, inclusive fase final; v1 mantém sua lista única |
 
-Terminação: `accepted | exhausted | stalled | uncertain | canceled`. MaxRounds atingido sem aceite produz exhausted e needs-attention por default; nunca retorna o último resultado como aprovado. Stalled usa critérios verificáveis, como candidato inalterado e fingerprint de findings repetido por rodadas declaradas. Não usar só a opinião do implementador para medir progresso.
+Todas essas 29 expressões já têm nomes no subsistema de programas atual; os contratos exatos serão versionados. Elas não fazem chamadas de modelos, rede, filesystem, relógio do host ou random. Tipos inválidos são erros de validação. Transformações complexas usam atividades registradas. Operadores adicionais, reduce/race/streaming e callbacks gerais ficam fora do núcleo inicial, com proposta de versão separada se a necessidade for demonstrada.
 
-maxRepairRounds conta implementações/correções com resultado capturado, incluindo a implementação inicial em implement-first. Avaliações iniciais e reavaliações têm contador/limite assessmentAttempts; falhas de infraestrutura têm infrastructureAttempts. Todos consomem orçamento global; reservar tentativas antes de dispatch, inclusive as que não chegam a produzir candidato. progressPolicy declara critérios e janela de observação, como candidato inalterado ou findings repetidos por duas rodadas, sem atribuir progresso somente à opinião do agente. Cada retry verifica política do efeito e backoff; não é ilimitado. Replan é alteração de estratégia, não sinônimo de retry ou repair.
+### 6.4 APIs de compilação e validação
 
-RepairResult é união discriminada: accepted contém acceptedCandidate e receipts de avaliação; exhausted/stalled/uncertain/canceled contêm estado, último candidato diagnóstico e pendências, sem campo acceptedCandidate. Seletores acceptedCandidate/acceptedCandidates exigem prova de estado accepted. Compose não consome um candidato apenas porque existe uma saída de repair; branches de falha devem tratar a união explicitamente.
+`lowerWorkflowSource(source)` converte AST finita em IR sem importar/transpilar/executar authored code. `validateWorkflowProgram(program,registry)` valida estrutura, refs, tipos, grafo, scope, efeitos e budgets. `validateProgramData(value,schema)` valida entradas/saídas. `validateProgramTypes(program,registry)` é etapa da validação, não mecanismo de aprovação. O cliente pode expor essas APIs offline; a validação autoritativa é sempre a do owner.
 
-## 11. Aceite independente da topologia
+Melhoria de P1: tipos discriminados e branded refs para não confundir schema/executor/candidate/data/receipt. Gerar declarações de tipos a partir do registry versionado. Diagnósticos incluem arquivo/linha/operação/caminho de schema/razão. Um handle tipado é shorthand compilado para ref; não objeto que executa callback. sourceMap é metadata com digest próprio e não amplia autoridade.
 
-AcceptanceContract é versionado e controlado pelo owner: objetivo, escopo, critérios com IDs estáveis, checks, cobertura, revisão, autorização e evidências exigidas. O programa define estratégia para cumpri-lo, mas não pode reduzir obrigações ou aprovar a própria expansão de privilégios.
+## 7. Controle do run e inspeção
 
-Final gate precisa comprovar:
+| Operação lógica | Situação | Contrato |
+|---|---|---|
+| `program-validate` | Existe, ampliar | Validação sem dispatch; devolve diagnósticos, capabilities e plano de efeitos |
+| `program-start` | Existe, ampliar | Fixa programa/input/registry/baseline e autorização; persiste antes de agendar |
+| `program-status` | Existe, ampliar | Estado autoritativo, waits, obrigações, uso e razões de bloqueio |
+| `program-wait` | Existe | Long poll com cursor/timeout; distinto de waitEvent no programa |
+| `program-pause` | Existe, esclarecer | Suspende novo dispatch; atividades em voo continuam ou recebem pedido explícito conforme escopo |
+| `program-resume` | Existe, corrigir | Continua fatos persistidos; não recria budgets nem repete completados intactos |
+| `program-signal` | Existe, ampliar | Entrada autorizada idempotente; receipt de recebimento separado do consumo/decisão |
+| `program-replan` | Existe, esclarecer | Diff versionado com preservação/invalidação explícitas e reason/evidence |
+| `program-cancel` | Existe, ampliar | Solicita cancelamento; conclusão exige observação dos efeitos, não apenas abort enviado |
+| `program-reconcile` | Existe, ampliar | Reconcilia attempts/apply com observação verificável e identidade exata |
+| `program-apply` | Existe, preservar | Gate atual + autorização + beforeimages + ApplyIntent; efeito local separado de compute |
+| `program-history` | Proposta P1 | Transições, stateRefs e decisões antigas sem mutação |
+| `program-artifact-get` | Proposta P1/P2 | Resolve referência autorizada; metadata/bytes limitados, sem acesso por path arbitrário |
+| `program-explain` | Proposta P1 | Explica ready/wait/blocked, dependências e motivo de replay/invalidação |
+| `program-diff` | Proposta P0/P1 | Mostra proposta de replan/migração, efeitos e gates afetados sem aplicar |
 
-1. Conjunto exigido de itens fechado e coberto.
-2. Candidato escolhido e artefatos de composição identificados.
-3. Revisão distinta aplicável ao digest desse candidato.
-4. Checks obrigatórios satisfeitos sobre o mesmo candidato e ambiente pertinente.
-5. Findings bloqueantes resolvidos com evidência ou decisão autorizada; inconclusivos não são aprovação.
-6. Ausência de tentativas/efeitos incertos pertinentes ou publicação parcial.
-7. Autorização compatível com ação, escopo e versão de aceite.
+Os nomes novos são propostas, não comandos instalados. CLI usa request JSON e MCP traduz para fabric_program_*; ambos passam pelo mesmo contrato. Mutations usam requestId único e expectedVersion. Repetir requestId com corpo diferente conflita. ACK idempotente não significa efeito externo exatamente uma vez. Capabilities devem declarar versão de operadores, adapters, isolamento e limites observados.
 
-O gate produz GateReceipt imutável ligado ao candidato, CoverageManifest, seals de coleções, revisão do programa, obrigações/política, avaliações e autorizações pertinentes. Atualização de métrica/UI não invalida o gate; mudança semântica de qualquer entrada pertinente invalida. Gate aprovado significa acceptance-ready, não arquivos aplicados. Um retorno de programa declara explicitamente accepted/no-work/needs-attention conforme seu schema; o estado aplicado depende de outra operação e receipt.
+## 8. Estados e scheduler durável
 
-IDs diferentes são evidência cooperativa de separação de execução; não garantem diversidade intelectual ou identidade criptográfica. Preservar tentativas/contextos distintos e observar executores quando disponível. Não promover um texto de agente a execução autenticada.
+Operações propostas: declared → ready → preparing → running → completed; waiting, skipped, failed, canceled-confirmed e uncertain têm significado separado. needs-attention é razão operacional agregada, não substituto universal de todos os estados. Parent join conserva cada outcome; resultados conhecidos não são apagados por falha de outro filho.
 
-Uma evidência é consumida segundo um validator registrado para sua semântica, não por um rótulo livre como test-passed. Se os próprios testes foram modificados, a revisão e o aceite consideram esse fato; passar testes alterados pelo autor não comprova adequação sem avaliação dos critérios.
+Run executing se há atividade/controle autorizado em progresso; waiting quando só restam waits autorizados e não há trabalho pronto/ativo; paused por decisão explícita; needs-attention se exige correção/reconciliação; completed para compute de dados; acceptance-ready para candidato gated; applying/applied/apply-uncertain para efeito local. canceled só após settle/observação das atividades pertinentes. Histórico preserva cancel-requested e instantes reais.
 
-Gate aceito permite ação autorizada, não autoriza automaticamente commit, push, release, deploy ou mensagem externa. Cada aplicação local mantém sua intenção e reconciliação próprias.
+Fila persistida com invocations e claims; capacidade do owner distinta de quota por run e limite por scope/map. Só atividades reservam slots. Espera e pais aguardando filhos não reservam worker. Fairness inicial: round-robin entre runs elegíveis e scopes, com tie-breaker estável; reentrada não pode esgotar a fila de outros runs. Não prometer scheduling distribuído. Claims de dispatch são persistidos antes do processo/modelo; epoch do owner/generation impedem resultado antigo de satisfazer trabalho substituído. Uma única autoridade ativa por projeto admite dispatch: exclusividade local via lock de processo/host e CAS do estado/epoch, validada em toda mutação autoritativa; não inferir exclusividade de TTL. Não é um protocolo distribuído.
 
-## 12. Composição, conflitos e integração
+Reservas têm ID de invocação/tentativa e debit transacional antes do dispatch; reconstrução usa intents/outcomes autoritativos. Release observado acontece uma vez. Crash antes de dispatch pode liberar apenas após provar que nenhum processo foi iniciado; crash depois de possível dispatch preserva reserva e classifica uncertain até observação. Claim expirado, PID indisponível e novo epoch não provam morte nem ausência de efeito. Worker órfão vivo continua contando na quota. Resultado tardio fica no histórico para reconciliação; não satisfaz automaticamente geração substituída. Dois owners concorrentes não podem ambos admitir o mesmo trabalho.
 
-Candidate lineage conserva baseline, candidatos pais, beforeimages, artefatos e produtores. Aplicação segue ordem determinística de ancestralidade; nunca last-writer-wins silencioso.
+Materialização é limitada/paginada: não criar todos os clones/processos de 10 mil itens antes de haver capacidade. Persistir o catálogo/seal, uma janela de invocations e cursor; resolver resultados por key. Quotas incluem calls de implementer, reviewer, checks/evidence e child programs. Subagentes internos de um harness só têm teto agregado se o adapter realmente os observa/controla; declarar o limite caso contrário.
 
-Writers independentes sobre o mesmo arquivo podem produzir conflito. A composição detecta antes de aplicação final e gera needs-resolution. Uma atividade de resolução autorizada cria novo candidato e deve ser revisada/verificada; não reclassificar o conflito como sucesso.
+Backpressure impõe bytes/ready queue/atividade e admite/nega expansão antes de alocar. Aumentar cap não prova performance. Começar concurrency 4 até medir. Cancelamento ou revogação de policy retira admissões novas; não invalida fatos históricos já observados.
 
-Resultados de map aceitos por item não substituem revisão e checks da integração. Ao combinar os itens, congelar candidato integrado, revisar comportamento global e executar verificações pertinentes. Se a integração precisar de repair, usar a mesma receita com candidato integrado anterior; aprovações de componentes continuam históricas, mas não aprovam mudanças novas automaticamente.
+## 9. Retomada, replan e cache
 
-Composição valida um DAG de ancestralidade sem ciclos, ancestrais ausentes ou baselines incompatíveis. Em um diamond A → C/D, o delta compartilhado de A é aplicado uma vez; C/D são compostos sobre essa base validada. Deduplicar ancestral comum por identidade/digest e ligação comprovada, não por igualdade textual de patches de produtores independentes. Patches iguais de produtores independentes passam por política explícita; o default é sinalizar conflito. Resolução cria novo candidato e conserva os originais.
+| Caso | Regra |
+|---|---|
+| Mesmo run/invocação intacta concluída | Ler resultado, candidato e receipts duráveis; não preparar clone nem chamar adapter/modelo de novo |
+| Resultado de activity persistido, parent sem commit | Reconstruir parent a partir dos fatos dos filhos, com validação/join; não repetir activity |
+| Execução interrompida sem resultado observado | Marcar uncertain, consultar/observar se adapter permite, reconciliar antes de redispatch |
+| Replan | Diff de dados/controle/obrigações, invalidação transitiva; preservação explícita de invocations intactas |
+| Novo run/cache entre runs | Contrato opt-in separado, fechado sobre entradas e validade; posterior ao MVP |
 
-### Fronteira entre aceite e aplicação
+A retomada exige integridade e acesso a resultados/artifacts/candidates. Corrupção/ausência bloqueia com diagnóstico; não vira cache miss que dispara efeito. Mudança de código do adapter/CLI não reescreve o passado: owner pode ler fatos antigos mas bloquear novo dispatch/apply se incompatível ou revogado. Uma consulta externa com exigência de frescor precisa de nova atividade/obrigação, não I/O implícito em replay.
 
-Lifecycle de aplicação: executing → acceptance-ready → applying → applied. Antes de aplicar, falha de condição retorna à execução/needs-attention com motivo. Depois de iniciar aplicação, resultado parcial/desconhecido vai a apply-uncertain e exige reconciliação. Cancelamento solicitado não comprova aplicação cancelada; distinguir cancelamento observado. Gate aprovado não significa applied.
+Capturar definição de invocação: runId, scope path, itemKey/round, operationId, generation, semantic/input/candidate digests e executor/contract refs. attemptId identifica uma execução concreta; reattempt não muda identidade do item. Cada fato de resultado inclui produtor, uso, artifacts e candidato. As operações de controle são reconstruídas deterministicamente desses fatos; não reexecutam chamadas externas.
 
-O owner relê a tupla semântica pertinente e faz CAS/transação para registrar ApplyIntent e estado applying antes de chamar o publisher. A transação valida candidateDigest, GateReceipt, CoverageManifest, seals, programRevision, acceptanceVersion, policyVersion, autorizações vigentes, baseline/escopo de destino e beforeimages. O publisher verifica o destino novamente antes de escrever: CAS no store não bloqueia modificações externas no filesystem. Se uma revisão pertinente ganhou a corrida antes do intent, o intent antigo não inicia. Registrar bytes/digests esperados e receipts dos arquivos efetivos; métrica/status de UI não faz parte da tupla semântica.
+Barrier/additive/fenced globais existentes continuam conservadores. Preservação de work intacto deve ser explícita mesmo quando a revisão global aumenta: generation de trabalho não deve obrigatoriamente ser igual ao contador editorial do plano. Alterar população/aceite/autoridade fixados requer successor run conforme contrato, não replan que enfraqueça obrigações. Fenced replan local independente é extensão posterior e exige reconciliação de efeitos, não só ignorar outputs tardios.
 
-Durante applying o intent fica congelado: replan, novos seals e steering não podem mudar o alvo da aplicação. Eventos pertinentes recebidos nesse período são persistidos como pending-after-apply; o ACK distingue recebido de consumido e não afirma que o steering já ocorreu. Após reconciliação ou conclusão, esses eventos exigem decisão explícita de revisão sucessora vinculada; não mudam retroativamente o run terminal nem seus arquivos. Revogação de autoridade/cancelamento é exceção de interrupção: verificar em fronteiras seguras, tentar parar e registrar o observado; arquivos já escritos ou revogação durante um write podem exigir apply-uncertain, sem promessa de rollback universal.
+## 10. Eventos, decisões humanas e deadlines
 
-Aplicação de múltiplos arquivos localmente não vira transação atômica por existir journal. Crash após write e antes do receipt requer inspeção/reconciliação dos before/afterimages e do intent; nenhuma nova aplicação/dispatch pertinente é liberada enquanto houver apply-uncertain. Não sobrescrever divergências para simular sucesso. Applied exige receipt persistido que comprove o resultado inteiro do intent congelado; apenas emitir um ACK não é prova.
+waitEvent registra alvo, scope, generation, tipo, correlation, subject e prazo. Subject pode ligar decisão a candidate/contract digests. Um evento aprovado para candidato antigo não autoriza outro. Payload válido por schema não basta: actor/autoridade, bindings, expiração e consumo precisam ser verificados pelo owner.
 
-## 13. Replanejamento, gerações e resultados tardios
+Eventos anteriores ao wait podem ficar em inbox autorizada bounded, sem inventar targets futuros. Duplicatas são idempotentes; geração antiga fica stale e auditável. Consumir evento e fixar decisão é transação única. Receipt de entrada aceita, receipt de decisão e GateReceipt são distintos. Declínio é decisão válida, mas não aprovação; gate exige aprovação compatível quando policy requer.
 
-Fase inicial mantém barreiras seguras: suspender novos despachos, observar workers ativos e reconciliar incertezas antes de alterar suas entradas.
+Deadlines persistidos são absolutos. Tempo de espera conta no deadline do run por default; uma extensão exige decisão autorizada versionada com limite, não reset por resume. Prazo de atividade/check inclui preparação quando pertinente. Owner vivo pode despertar somente o ramo autorizado após evento. Run paused não desperta por evento; restart do owner reconcilia e exige política explícita de continuação. Não instalar serviço/wakeup/automation como efeito da autoria.
 
-Depois habilitar extensão monotônica: adicionar ramos independentes e itens ainda não despachados, sem alterar contratos/entradas/escopo de workers ativos nem enfraquecer aceite. A expansão e seus limites são uma transação versionada. Joins aguardam fechamento explícito do conjunto de produtores.
+## 11. Repair e aceite
 
-Substituição de ramos durante atividade só entra após protocolo de fencing: generation/token por tentativa, relação de dependência observada, rejeição de output da geração antiga e invalidation transitiva. Resultados tardios são conservados para auditoria, mas não satisfazem operações novas. Workers afetados precisam terminar, cancelar ou reconciliar.
+`repair` preserva implement-first e assess-first. Campos existentes: recipe, implement, review, checks, entryMode, initialCandidate, writeScope, maxRepairRounds, maxAssessmentAttempts, maxInfrastructureAttempts, progressPolicy. Campos novos propostos: input tipado para contexto, assessmentScope: "item" | "final" e evidence para executores readonly que preparam evidências de avaliação. Todos são refs autorizadas, não código livre.
 
-Fencing rejeita o resultado; não desfaz efeito externo de um worker antigo. Nenhuma troca de geração permite presumir que o processo terminou. App-closed e serviço de sistema continuam fora deste aceite.
+**Obrigações por fase, sem enfraquecimento pelo autor.** Acceptance v2 tem obligation IDs imutáveis, critérios/evidências e `requiredChecksByScope`; registry vincula operation/recipe aos contextos item ou final admitidos. `assessmentScope` solicita uma dessas bindings, mas o owner verifica a correspondência estrutural: repair dentro do map cobre sua key, avaliação pós-compose obrigatória é final. Declarar item na fase final ou omitir checks não reduz obrigações; validação rejeita antes do dispatch. V1 mantém acceptance.requiredChecks e seu intérprete histórico.
 
-Propostas de agente são payloads tipados de replan, não mutations autoritativas. O owner pode aceitar automaticamente mudanças dentro de regras e autorização existentes; mudanças de objetivo, escopo ou efeitos fora desses limites precisam de decisão autorizada. A política não delega autoaprovação ao implementador.
+No caso UI, o contrato fixa uma obrigação de layout por key do catálogo, mais obrigações de integração/inventário. Item exige ui-layout@v2 e typecheck@v1 para sua avaliação. Final exige ui-regression@v2 e typecheck@v1, evidência nova de todo o catálogo e revisão com cobertura explícita de cada obrigação de layout e integração. O check de regressão deve observar por item as constraints requeridas de layout; essa ligação entre critérios e validators é aprovada no registry, não inferida pela semelhança de nomes. Se o validator final não comprovar uma obrigação local, o contrato também exige seu checker local no candidato final. O workflow pode pedir checks extras admitidos; nunca um subconjunto mais fraco.
 
-## 14. Eventos humanos, steering e aprovações
+**Interfaces de avaliação propostas (schemas do registry, não novos operadores).**
 
-Eventos são tipados, identificados, ordenados e persistidos antes de consumo. Contêm run, produtor/autorização observada, alvo, payload, versão esperada, correlação e validade quando pertinente. Deduplicação conserva idempotência. Mensagens de workers não são autorização humana.
-
-Steering opera em checkpoints e sobre etapas futuras. Não prometer injeção em worker ativo se o adaptador não suporta. Um evento que modifica entradas produz nova revisão/geração e invalidation explícita; não apenas acrescenta texto ao próximo prompt.
+```text
+AssessmentContext = {
+  runId, invocationId, assessmentId, phase, candidateRef,
+  obligationIds, itemKey?, populationSealRef?, environmentRef,
+  evidenceRefs, input
+}
+EvidenceResult = {
+  outcome: observed | infrastructure_failed | inconclusive,
+  artifactRefs, proposedCoverage, producerAttemptId
+}
+AssessmentReceipt = {
+  assessmentId, candidateRef, contractRef, phase,
+  environmentRef, evidenceRefs, checkResultRefs, reviewResultRef,
+  satisfiedObligationIds, unsatisfiedObligationIds, verdict, ownerRecordRef
+}
+```
 
-WaitEvent tem política de prazo e cancelamento. Timeout não significa aprovação. Um evento enviado antes de o wait ser materializado não pode se perder; matching usa invocação lógica, geração/revisão, tipo, correlação e validade. Eventos dirigidos a wait antigo não são consumidos pelo wait novo. Consumo e decisão correspondente são uma transação; deduplicação e receipt impedem consumo duplo. Autorizações duradouras podem ser reutilizadas dentro de sua finalidade, mas isso não reutiliza automaticamente o mesmo sinal de negócio para decisões distintas. Durante applying vale o pending-after-apply da seção 12.
+O owner cria AssessmentContext. Executores evidence recebem contexto com evidenceRefs inicialmente vazio; seus outputs são validados, e o owner liga CaptureReceipts/artefatos válidos ao contexto dos checks/reviewer. Esses consumidores recebem referências autorizadas com quotas de bytes, imagens e acesso readonly; não escolhem candidate/environment/obligation IDs. proposedCoverage de agente é alegação, não prova owner. Owner emite AssessmentReceipt a partir dos outcomes/critério observáveis, registra cada obrigação satisfeita ou faltante e rejeita evidência de outro candidato, ambiente ou geração. Output aprovado com cobertura omitida não fecha a matriz. Input.ui/catalog ajuda a tarefa, mas não substitui o contexto confiável.
 
-Aprovação, quando necessária, é vinculada a ação, candidato/digest, escopo, versão e validade. Reutilizar autorizações já dadas quando aplicáveis; não introduzir aprovação obrigatória em toda etapa. Receipts de aprovação seguem o mecanismo confiável do host, sem inventar identidade autenticada quando só há registro cooperativo.
+Sequência de uma avaliação: persistir fase/counters → preparar evidência para candidato exato → construir AssessmentContext validado → executar checks pertinentes e reviewer distinto → validar outputs/cobertura → decisão do owner. Checks e review podem rodar paralelos quando dependências de evidência permitem. Reviewer visual recebe capturas emitidas/validadas pelo adapter, não path textual qualquer. Dados de reviewer são assessment proposto; owner emite receipt após verificar linkage/checks/criteria.
 
-## 15. Efeitos, retry e reconciliação
+Approved + nenhum finding pendente + checks exigidos aprovados + evidências pertinentes válidas permite aceite. Changes_requested ou check de código reprovado permite implementação limitada. Inconclusive ou captura inválida não deve ser transformada automaticamente em defeito visual; corrigir infraestrutura/reavaliar dentro dos budgets ou parar para intervenção. Uma falha de build genuína do candidato é finding/check negativo, distinta de browser indisponível.
 
-Classes propostas: read, isolated-write, idempotent-effect e non-idempotent-effect. A declaração é validada por política/adaptador; não confiar na auto-classificação do script. Clones e checagem de diffs não são contenção contra processo malicioso com acesso à mesma conta do sistema operacional.
+MaxRepairRounds conta implementações, inclusive tentativa antes de seus efeitos serem observados; maxAssessmentAttempts conta ciclos de avaliação; maxInfrastructureAttempts conta reattempts operacionais, sem devolver tentativas consumidas. `maxAttempts` global conta dispatches de atividades e reattempts **visíveis ao owner**, incluindo implement/review/check/evidence. Uma atividade SDK não equivale a uma única RPC/model call. Reservar/debitar por tentativa antes do efeito, com ID transacional; reconstrução não devolve nem cobra novamente a mesma reserva. Resume de completed intacto debita zero; reattempt observado debita nova tentativa. maxRepairRounds/maxAssessmentAttempts/maxInfrastructureAttempts têm unidades separadas e counters persistidos. RPCs, provider retries e subagentes internos têm contagem/limite próprios somente quando o adapter realmente os observa/controla; caso contrário declarar unknown/cooperative e não prometer teto de requisições/tokens/dinheiro. Guardar phase, debit e dispatch antes de cada efeito evita replenishment por crash. Efeito incerto sempre exige observação/reconciliação.
 
-CapabilityContract é obrigatório antes do primeiro dispatch v2, inclusive read e command. O owner valida argv/cwd, ambiente efetivo, binários/configuração, ferramentas, rede, escopo de escrita do candidato, paths gerados permitidos e evidência de isolamento do adaptador. Preferência declarada é separada de capacidade efetivamente observada. Comando sem contenção é execução cooperativa com seu acesso real explicitado; se o contrato exige restrição forte de rede/escrita, um adaptador incapaz é recusado, não relabelado como seguro.
+Progress policy mede candidato/deltas e findings canonicalizados por schema; thresholds configurados não são prova semântica de melhoria. Stalled/exhausted/inconclusive ficam visíveis e bloqueiam consumers obrigatórios. Um value final não mascara repair rejeitado. Reviewer distinto pode usar mesmo modelo, mas essa separação não garante independência estatística de julgamento.
 
-Escopo efetivo de escrita é a interseção entre escopos solicitados pelo programa/executor, aceite, política e capacidade observada. Paths sugeridos pela discovery são dados a validar, nunca autorização. Sem escopo resolvido, dispatch de escrita é recusado. acceptanceWriteScope identifica uma projeção registrada do contrato de aceite; não concede acesso adicional nem permite que o executor redefina o próprio limite.
+## 12. Cobertura, contribuições, composição e gate
 
-Checks podem criar cache/build em allowedGeneratedPaths de scratch isolado por tentativa, fora do candidato imutável avaliado. Não podem modificar source do candidato para fazer o check passar. Alteração do candidato invalida a avaliação e exige novo candidato/gate. Hash de executor/ambiente considera binário, configuração e variáveis pertinentes sem armazenar segredos. Scratch autorizado não amplia escopo dos artefatos capturados ou aplicação final.
+Population fixa o catálogo esperado, baseline/evidência, itens e exclusões justificadas. Discovery propõe itens; coverageFor compara identidades e checks de inventário owner. Chaves estáveis não são índices de lista. “Todas as UIs” significa todas do catálogo aceito; a qualidade do catálogo é obrigação separada, não prova por declaração do capturador.
 
-Read e isolated-write podem ser retentados quando entradas, limites e integridade permitem. Efeitos idempotentes usam chave e receipts do destino quando disponíveis. Efeito não idempotente recebe intent persistido antes do despacho e exige resultado observado/reconciliação; não tem retry automático depois de resultado desconhecido.
+Seal fecha a collection. CoverageReceipt prova cumprimento do catálogo. ContributionLedger liga cada item à avaliação e candidato/contribuição aceitos, inclusive zero-delta legítimo. Todos os itens obrigatórios precisam aparecer; filter/take/unique não retiram obrigações. No-work só com autorização em population e acceptance. Partial/quorum têm denominador/seal e faltantes explícitos, sem transformar skipped/failed em aceito.
 
-Comandos arbitrários não recebem garantia exactly-once. Restrições de rede/ferramentas e isolamento devem ser demonstradas pelo executor, não inferidas da declaração effect. Não ampliar automaticamente acesso aos MCPs globais, credenciais ou APIs externas dos workers.
+Compose mantém baseline, pais e deltas de cada produtor; ancestral compartilhado aparece uma vez, patches iguais independentes ainda requerem política de conflito. Antes de aceitar, validar closures e beforeimages. onConflict inicialmente needs-resolution: preservar inputs, emitir conflito e parar. P1/P2 detecta e bloqueia conflito, preserva candidatos/receipts e não promete continuar automaticamente a composição. Não aplicar last-writer-wins nem criar operador resolve automático. Uma extensão de resolução/successor só entra com ResolutionReceipt owner ligando conflictRef, parents/inputs, supersededDeltas, obligations e candidateRef resultante; não exigir que deltas substituídos permaneçam literalmente no novo patch. Contribuições originais permanecem auditáveis e a nova solução exige avaliação final completa. Sem esse contrato implementado, a resolução é trabalho separado autorizado, e o run permanece bloqueado.
 
-Cancelamento solicitado, processo terminado e efeitos conhecidos são estados distintos. Deadline ou abort sem conclusão observada produz uncertain. Reconciliar só com observações pertinentes; manter os limites atuais de fechamento de árvores de processos enquanto não houver teste específico.
+Gate verifica candidato, população/contribuições/seals, avaliações, checks, versão semântica e autorização pertinente. Candidato global após composição exige revisão/checks globais mesmo se cada item passou. No MVP UI, a avaliação final cobre **todo o catálogo** no candidato final; cada rodada que altera esse candidato exige nova avaliação completa. Receipts locais são histórico de contribuições, não prova atual de preservação semântica. Otimização seletiva por impacto e reuso por equivalência são posteriores, com regras owner demonstradas; lineage sozinho não basta. Contexto de autorização/decision fica ligado ao candidato e contratos exatos. Approved é aceite de contrato técnico, não aceite humano ou produção por implicação.
 
-## 16. Políticas, orçamento e escala
+### 12.1 Resultados e receipts canônicos a fechar em P0
 
-PolicyContract é externo ao programa e versionado. Autor define preferências dentro dos tetos; não amplia sua autorização. Subworkflows herdam orçamento restante e não reiniciam contadores para contornar limites.
+| Schema desejado | Campos/invariantes mínimos |
+|---|---|
+| ScopeResult | scopeRef, requiredChildIds, outcomes tipados por filho, joinStatus, successValueRef?; valor só no join válido, diagnóstico disponível mesmo na falha |
+| CollectionResult | sealRef, keys/outcomes/valueRefs, totals, completion/quorum, coverage/contribution refs; não pode esconder itens faltantes/uncertain |
+| RepairResult | outcome accepted/exhausted/stalled/inconclusive/uncertain/canceled, candidateRef, assessmentReceiptRefs, counters; acceptedCandidate só resolve accepted válido |
+| CaptureReceipt | candidate/build/environment/item identities, artifactRef/digest/MIME/dimensões, producerAttempt, freshness/observação owner; não confundir captura registrada com ausência de defeito |
+| AssessmentContext/Receipt | Contratos da seção 11; cobertura por obrigação, candidato e ambiente exatos |
+| GateReceipt | candidate/program/acceptance/population/seal/contribution refs, matriz final de assessment/checks/evidence, authorizationRef quando requerida, ownerRecordRef |
 
-Controlar concorrência, tentativas totais, rodadas, revisões, itens, tamanho/profundidade de outputs, artefatos, prazo por worker/run e operações de transform. Reservar capacidade antes de despachar e reconciliar uso observado depois. Pausa por quota não reinicia efeitos desconhecidos.
+Outcomes tipados distinguem execução, verdict e aceite. As unions serão schemas discriminados versionados; um JSON com campos iguais a um receipt não recebe autoridade. ScopeResult falho fica em inspeção, sem output fictício. CoverageReceipt histórico do map valida inventário/contribuições e não substitui o AssessmentReceipt final. Gate depende de ambos.
 
-Distinguir elapsed wall-clock, tempo ativo de execução e expiração de autorização. Espera humana pode pausar apenas o contador que a política permitir; deadlines absolutos e validade de autorização continuam valendo. Reinício não zera contadores. Registrar modelo solicitado, modelo efetivo quando observável e qualquer fallback autorizado; configuração desconhecida não vira confirmação de equivalência.
+## 13. Efeitos e aplicação
 
-Distinguir teto rígido implementável de estimativa: tentativas/concorrência/deadlines têm enforcement local; uso financeiro e tokens só são limites rígidos quando o provider/adaptador permite medição e interrupção apropriadas. Uso reportado ao final pode exceder reserva estimada; não prometer teto monetário exato ou ausência de consumo após abort.
+Cada executor declara read, isolated-write, idempotent-effect ou non-idempotent-effect; os dois últimos não ganham exactly-once pela declaração. Adapter precisa especificar chave/receipt/probe/reconciliação; sem isso a execução é cooperativa com outcome uncertain possível. Fonte do autor não faz rede/shell diretamente.
 
-Usar fila persistida com justiça entre ramos, backpressure e limites de bytes. Falta de workers, limites de provider e indisponibilidade de ambiente produzem estados visíveis. Não adicionar serviço de sistema ou scheduler de wakeup implicitamente.
+Aplicar é operação externa ao programa de compute por default. program-apply exige GateReceipt atual, autorização válida e destinos/beforeimages observados. Owner persiste ApplyIntent antes da primeira escrita, com candidate/program/contract digests e expected files. Múltiplos arquivos não são transação única de filesystem; partial/interrupted/divergent gera apply-uncertain. Preservar arquivos e reconciliar; nunca repetir automaticamente uma publicação ambígua.
 
-Reduzir contexto por referências, entradas selecionadas e resumos. Caching depende da compatibilidade efetiva de modelo, ferramentas, schemas, diretório e provider; medir hits e economia reais. Model routing permanece dentro das preferências e autorização existentes; nenhuma troca silenciosa para modelo mais caro.
+Eventos/replans durante aplicação ficam pending-after-apply; não alteram intent em voo. Revogação/cancelamento verifica admissão e próximas escritas, mas não desfaz o já observado. Applied/canceled final exigem successor run para novo trabalho. Não ampliar publicação npm/deploy como efeito de concluir um plano.
 
-Prompt caching do provider reduz processamento de prefixos; reuso de output evita executar a operação. Registrar essas métricas separadamente. Clones/diretórios distintos podem reduzir cache hits. Não compartilhar workspaces mutáveis apenas para obter cache.
+## 14. Adaptadores, capacidades e imagens
 
-## 17. Observabilidade e experiência no Codex
+Contrato comum de atividade: prepare/admit, dispatch, observe, requestCancel, result, usage, artifacts e reconcile, com versão/identidade. Garantias efetivas explicitam plataforma, sandbox, rede, filesystem e ferramentas. Default Codex atual continua fechado; acesso browser/rede/MCP só entra por capability específica aprovada e adapter que a implemente. Não herdar ferramentas do chat por conveniência.
 
-Visões mínimas: objetivo/aceite, programa e revisão, itens/rodadas, candidatos, gates, workers ativos, pendências, incertezas, uso observado e próximos passos. Comparar revisões do plano e explicar por que um resultado foi reutilizado ou invalidado.
+Command adapters são cooperativos, mesmo com workspace clonado; isso não é sandbox de host/rede. Não afirmar cancelamento confirmado apenas por AbortController ou SIGKILL enviado. Um adapter de outro harness só pode entrar quando os outcomes forem representados corretamente. Subagentes internos precisam de IDs/usage/parent linkage se o produto prometer limites sobre eles.
 
-Status compacto e wait com cursor; journal detalhado consultado sob demanda. Resumos mostram coverage e itens não verificados. Logs passam por redaction antes de outputs ou prompt, e armazenamento de artefatos tem controles de acesso/escopo.
+P2 de UI: artefato imutável de bytes com digest/MIME/dimensões, producerAttempt, baseline/candidate/build/environment digests e identificação de rota/estado/viewport. Browser serve build originada do candidato preparado, com dados de teste/auth fixtures definidos. Caminho em scratch ou URL sem conteúdo persistido não basta para prova. Resolver somente leitura com capacidades scoped; bytes fora do JSON de estado e budgets de imagem/quantidade/resolução.
 
-O Codex monta os requests e explica resultados em linguagem natural. Workers SDK continuam execuções separadas, sem promessa de novas conversas na sidebar ou controle da conversa nativa. CLI/MCP compartilham owner e contratos; disponibilidade real do transporte precisa ser observada no host.
+Captura inválida é outcome separado de defeito visual. Validar tela carregada, URL/estado/viewport, assets/renderização pertinentes e build esperada. Autenticação usa capacidades efêmeras; não persistir tokens/segredos em registry, prompts ou receipts. Ambientes externos voláteis só suportam garantias limitadas declaradas.
 
-## 18. Exemplo completo de intenção e programa
+Evidence executor pode reaproveitar uma captura já emitida para o mesmo candidato/item/environment dentro da validade owner. Se candidato/contexto mudou, recapturar. Isso evita capturar novamente todas as telas intactas apenas por uma retomada; não confundir com cache cross-run de respostas LLM.
 
-Pedido: migrar componentes de uma API antiga para uma nova, preservar comportamento, corrigir rejeições e verificar o conjunto integrado. Paths e bibliotecas são ilustrativos.
+## 15. Exemplo principal: captura, revisão e correção de UIs
 
-A descoberta retorna ComponentList: itens com id estável, path, entradas, escopo permitido e checks sugeridos. Sugestão de check não é autorização para executá-lo; o owner valida contra o contrato. Neste exemplo, o registry contém os contratos/schemas/executores versionados e a população migration-components exige conjunto não vazio. Um objetivo que permita ausência de trabalho precisa declarar schema/branch no-work explícitos, com o validator da seção 9; este exemplo não aprova discovery vazia.
+API desejada operatorVersion 2, proposta P2. Usa operações/expressões existentes com novas semânticas e campos input/assessmentScope/evidence/mode/operatorVersion. Não é executável na alpha.70. Os executores, schemas, catálogos e checks abaixo são nomes de configuração proposta, não registros já instalados.
 
 ```typescript
-// API CONCEITUAL PROPOSTA. Não existe nem foi executada nesta entrega.
-// Construtores são lowered estaticamente; nenhum callback arbitrário é executado.
-defineWorkflow({
-  id: "migrate-components",
+import {
+  defineWorkflow, schemaRef, executorRef, policyRef,
+  acceptanceRef, populationRef, recipeRef,
+  agent, map, repair, compose, gate,
+  output, field, item, population, coverageFor,
+  candidateFromBaseline, acceptedCandidates,
+  outputCandidate, acceptedCandidate, coverageReceipt,
+} from "forgeos/agent-fabric/workflows";
+
+const itemRepair = {
+  recipe: recipeRef("repair", "v2"),
+  implement: executorRef("corrigir-ui", "v2"),
+  review: executorRef("revisar-ui", "v2"),
+  assessmentScope: "item",
+  evidence: [executorRef("capturar-candidato-ui", "v2")],
+  checks: ["ui-layout@v2", "typecheck@v1"],
+  entryMode: "assess-first",
+  maxRepairRounds: 3,
+  maxAssessmentAttempts: 6,
+  maxInfrastructureAttempts: 2,
+  progressPolicy: {
+    unchangedCandidateRounds: 2,
+    repeatedFindingsRounds: 2,
+  },
+};
+
+export default defineWorkflow({
+  id: "revisar-e-corrigir-uis",
   version: 1,
-  inputSchema: schemaRef("migration-input", "v1"),
-  outputSchema: schemaRef("migration-result", "v1"),
-  acceptance: acceptanceRef("migration", "v1"),
-  population: populationRef("migration-components", "v1"),
-  policy: policyRef("local-coding", "v1"),
+  operatorVersion: 2,
+  mode: "candidate",
+  inputSchema: schemaRef("entrada-ui", "v2"),
+  outputSchema: schemaRef("gate-ui", "v2"),
+  policy: policyRef("ui-local", "v2"),
+  acceptance: acceptanceRef("qualidade-ui", "v2"),
+  population: populationRef("catalogo-uis", "v2"),
+
   steps: [
-    agent("discover", {
-      role: "investigator",
-      input: workflowInput(),
-      outputSchema: schemaRef("component-list", "v1"),
-      effect: "read",
-      prompt: "Identifique os componentes e suas dependências; não altere arquivos.",
+    agent("capturas", {
+      executor: executorRef("capturar-uis", "v2"),
+      input: { catalog: population() },
     }),
-    map("migrate", {
-      items: field(output("discover"), "items"),
-      coverage: coverageFor(population(), output("discover")),
+
+    map("uis", {
+      items: field(output("capturas"), "items"),
       key: field(item(), "id"),
-      concurrency: 4,
+      order: "key",
       completion: "all-required",
-      body: repair("component", {
-        recipe: recipeRef("repair", "v1"),
-        entryMode: "implement-first",
+      concurrency: 4,
+      coverage: coverageFor(population(), output("capturas")),
+      body: repair("avaliar-e-corrigir", {
+        ...itemRepair,
+        input: { ui: item() },
         initialCandidate: candidateFromBaseline(item()),
         writeScope: field(item(), "allowedPaths"),
-        implement: executorRef("migrate-component", "v1"),
-        review: executorRef("review-component", "v1"),
-        checks: approvedChecksFor(item()),
-        maxRepairRounds: 3,
-        maxAssessmentAttempts: 6,
-        maxInfrastructureAttempts: 3,
-        progressPolicy: { unchangedCandidateRounds: 2, repeatedFindingsRounds: 2 },
-        onExhausted: "needs-attention",
-        onUncertain: "reconcile",
-        preserveCandidateHistory: true,
       }),
     }),
-    compose("integrate", {
-      candidates: acceptedCandidates("migrate"),
+
+    compose("integrado", {
+      candidates: acceptedCandidates("uis"),
       onConflict: "needs-resolution",
     }),
-    repair("repair-integration", {
-      recipe: recipeRef("repair", "v1"),
+
+    repair("regressao-global", {
+      recipe: recipeRef("repair", "v2"),
+      implement: executorRef("corrigir-regressao-ui", "v2"),
+      review: executorRef("revisar-ui-integrada", "v2"),
+      assessmentScope: "final",
+      evidence: [executorRef("capturar-candidato-completo", "v2")],
+      checks: ["ui-regression@v2", "typecheck@v1"],
+      input: { catalog: population() },
       entryMode: "assess-first",
-      initialCandidate: outputCandidate("integrate"),
-      writeScope: acceptanceWriteScope("integration"),
-      implement: executorRef("fix-integration", "v1"),
-      review: executorRef("review-integrated-result", "v1"),
-      checks: acceptanceChecks("integration"),
+      initialCandidate: outputCandidate("integrado"),
+      writeScope: ["src"],
       maxRepairRounds: 2,
-      maxAssessmentAttempts: 6,
-      maxInfrastructureAttempts: 3,
-      progressPolicy: { unchangedCandidateRounds: 2, repeatedFindingsRounds: 2 },
-      onExhausted: "needs-attention",
-      onUncertain: "reconcile",
+      maxAssessmentAttempts: 4,
+      maxInfrastructureAttempts: 2,
+      progressPolicy: {
+        unchangedCandidateRounds: 2,
+        repeatedFindingsRounds: 2,
+      },
     }),
+
     gate("final", {
-      candidate: acceptedCandidate("repair-integration"),
-      obligations: acceptance(),
-      coverage: coverageReceipt("migrate"),
+      candidate: acceptedCandidate("regressao-global"),
+      coverage: coverageReceipt("uis"),
     }),
   ],
-  result: object({
-    status: literal("accepted"),
-    candidate: acceptedCandidate("repair-integration"),
-    gate: output("final"),
-    coverage: coverageReceipt("migrate"),
-  }),
+
+  result: output("final"),
 });
 ```
 
-Semântica: coverageFor/coverageReceipt são projeções de validação local determinística do owner, não um prompt que pede ao discover para se autovalidar. O lowerer infere a dependência de descoberta e inventário, e map aguarda cobertura/seal aceitos. Seletores acceptedCandidate(s) criam dependências condicionadas à união accepted; falha da receita suspende consumidores e retorna status operacional needs-attention, sem avaliar result como sucesso. O schema migration-result valida o objeto terminal de negócio quando o programa chega ao result; falhas operacionais pertencem ao envelope do run.
-
-Map aceita somente candidatos approved por seus gates de rodada. Compose detecta sobreposição e produz candidato integrado imutável. Assess-first avalia o candidato de integração antes de modificar: se já passar revisão/checks, não cria alteração vazia nem gasta uma implementação desnecessária. Caso falhe, rodadas seguintes partem desse candidato e seu feedback. O gate final reaproveita apenas evidências de revisão/checks que correspondam exatamente ao candidato escolhido e às obrigações vigentes. Result accepted significa candidato aceito, não aplicado. Aplicação local é uma ação posterior autorizada, com ApplyIntent/receipt e lifecycle da seção 12, não implícita no retorno de gate.
-
-Exemplo de falha: após duas reprovações e nenhuma mudança de digest, um item fica stalled. Os outros candidatos continuam persistidos, mas map all-required não conclui. Após instrução autorizada e reparo do item, retomar com apenas os ramos invalidados; integração e gates finais só usam o novo conjunto fechado.
-
-## 19. Compatibilidade e pontos de código
-
-Não mudar comandos v1, persisted schemaVersion 1 ou sua definição histórica de succeeded/ready. Runs antigos continuam em seu executor/intérprete. Novo protocolo deve ter discriminador e validação explícitos; não aceitar mistura de envelopes v1/v2.
-
-Introduzir módulos de responsabilidade conceituais: workflow-program-contract/lowering, expression-evaluator, operation-store/journal, dynamic-expansion, outcome-contract, typed-output/artefact-resolver, candidate-lineage, acceptance-gates e recipes. Nomes finais dependem da inspeção do projeto; não criar um serviço paralelo para cada primitive.
-
-Mapeamento de reuso:
-
-| Código existente | Tratamento |
-| --- | --- |
-| workflow-engine.ts | Reutilizar reducer/invalidation para operações materializadas; adapter v2 explicita semântica de controle |
-| managed-run-contract/store/service.ts | Acrescentar contratos versionados e lifecycle; preservar v1 |
-| codex-sdk-worker.ts | Envelope separado de payload tipado; modelos e isolamento observados |
-| managed-workspace.ts | Reusar snapshots, beforeimages, scopes e composição; acrescentar Candidate metadata |
-| workflow-task-actions.ts | Não relaxar validação de snapshots acompanhados ao introduzir v2 |
-| CLI fabric / agent-memory MCP | Transportes do mesmo owner, sem instalação/configuração global implícita |
-| tests/agent-fabric | Contratos, crash/replay, loops, expansão, artefatos, efeitos e compatibilidade |
-
-V2 review rejeitada não pode ser despachada pelo path v1 que a converte em failed/blocked sem adaptação explícita. Controle puro (branch/join/expansion/gate) usa executor local determinístico e receipt próprio, não um worker LLM obrigatório para cada nó. Não enfraquecer o contrato legado que exige executor por nó; o contrato v2 define suas categorias próprias.
-
-Freeze P0a/P0b, acceptance records e cronologia não são reescritos. Mudanças materiais em invariantes exigem ADR/supersessão com baseline, compatibilidade, evidência e commit de aplicabilidade. Migrar run antigo só por operação explícita, pausada e sem incertezas, mantendo o original recuperável; nenhuma conversão automática em abertura de owner.
-
-## 20. Entregas, dependências e critérios de aceite
-
-| Etapa | Entrega | Dependências | Gate verificável |
-| --- | --- | --- | --- |
-| F0 | ADR semântica: IR, identidades, população/aceite, capacidades, efeitos, lifecycle e persistência autoritativa | Baseline | Contraexemplos de cobertura, rejeição, exaustão, crash e corrida de aplicação resolvidos na especificação; review independente |
-| F0b | Protótipo limitado de expressividade e decisão de autoria | F0 | Cenários da seção 4 expressos/inspecionados; schemas/result/dependências/IDs sem execução arbitrária; medir esforço antes de congelar DSL |
-| F1 | Contrato v2, outputs/avaliações e CapabilityContract antes do dispatch | F0 | Feedback separado de falha; restrições efetivas validadas; envelope v1 preservado; sem dispatch antes de validação |
-| F2 | Lowerer de produto e expressões puras da autoria escolhida | F0b/F1 | Lowering determinístico; imports/I/O inválidos rejeitados sem execução; schemas/result/merge e limites verificados |
-| F3a | Journal autoritativo, artefatos, receipts e checkpoints | F1/F2 | Crash em commit/artefato/ACK recuperável; projeções verificadas; sem dual write independente; limites de durabilidade documentados |
-| F3b | Map/loop de dados, seals, coverage e budgets | F3a | Inventário de 80 itens sem omissões; janela limitada; vazio inválido/no-work distintos; loops de dados duráveis e contadores conservados |
-| F4a | Candidate snapshot/delta, ancestralidade e composição | F3a | Três deltas no mesmo arquivo; diamond aplica ancestral uma vez; ciclos/baselines/conflitos rejeitados |
-| F4b | Repair de código, avaliações/gates e ApplyIntent/lifecycle | F3b/F4a | Assess-first/implement-first corretos; união accepted exclusiva; review/checks do digest final; CAS/eventos/apply-uncertain seguros |
-| F5 | Recuperação seletiva, sinais humanos e extensão monotônica | F4b | Evento não perdido/duplicado; alterar item reexecuta só dependentes; joins fechados; reuse receipt explícito; geração antiga não satisfaz nova |
-| F6 | Substituição online com fencing e escala medida | F5 | Corridas entre replan/result/abort/restart seguras; fila justa e backpressure; limites externos efetivos |
-| F7 | Benchmark pareado e piloto real autorizado | Gates anteriores pertinentes | Relatório de resultados/limites reproduzível; sem claims de produção/EasyGrow/App-closed a partir de fixtures |
-
-F3a entrega persistência antes da expansão de F3b. F3b usa dados/fixtures, sem declarar repair de código seguro. F4a vem antes de F4b; F4b depende também de cobertura/loops F3b. CapabilityContract é obrigatório em F1, sem aguardar fencing ou escala F6. Novas capacidades entram opt-in e nunca substituem imediatamente o modo v1.
-
-Cada slice termina com checks pertinentes, revisão independente sobre snapshot atual e validações exigidas pelo AGENTS.md do checkout. Testes reais SDK, dependências, MCP nativo e efeitos externos têm evidência separada e respeitam autorização/custos. Não iniciar chamadas pagas em toda CI nem executar checks apenas porque um manifesto os sugere.
+Dependências são obtidas pelas refs: capturas → uis → integrado → regressao-global → final. Não há dependência por posição no array. Capturador entrega 20 itens, por exemplo; a primeira avaliação cria 20 reviewer activities. Se 3 itens têm problemas, somente esses itens iniciam implementer. Reavaliações desses itens e avaliação global criam chamadas adicionais; não prometer que o fluxo inteiro usa exatamente 20 revisores e 3 implementadores.
 
-## 21. Matriz mínima de verificação
+`allowedPaths` do item deve ser confirmado contra o catálogo e as policies owner, inclusive componentes compartilhados. Capturador não concede write authority. Capturar-candidato-ui usa a captura inicial somente se sua identidade/validade corresponder à avaliação; depois de cada alteração produz nova captura do novo candidato.
 
-| ID | Cenário | Resultado esperado |
-| --- | --- | --- |
-| T01 | Revisão concluída, changes_requested | Feedback consumível; candidato não aprovado |
-| T02 | Checker produz diagnósticos com exit esperado não zero | Diagnóstico válido; obrigação de check passou continua pendente |
-| T03 | Schema inválido/truncado/referência fora de escopo | Falha explícita; output não consumido e nenhum efeito adicional implícito |
-| T04 | maxRepairRounds e mesma falha repetida | exhausted/stalled; jamais último candidato tratado como accepted |
-| T05 | Crash antes/depois de persistir expansão/claim/resultado | Nenhum dispatch sem registro; operações incertas reconciliadas; ACK não inventado |
-| T06 | Lista reordenada, chave duplicada, rename | Identidades estáveis; duplicata rejeitada; rename segue regra declarada |
-| T07 | 80 itens, janela pequena e restart | Sem itens omitidos/duplicados; all-required e fechamento corretos |
-| T08 | Três patches no mesmo arquivo em rodadas | Ancestralidade correta; beforeimage divergente rejeitada |
-| T09 | Writers independentes conflitantes | Needs-resolution; nada de last-writer-wins silencioso |
-| T10 | Item novo após fechamento, antes/durante/depois de apply | Antes: novo seal invalida gate; durante: pending-after-apply; terminal: sucessor explícito sem mudar run aplicado |
-| T11 | Resultado tardio após fencing | Histórico preservado; nenhuma conclusão da geração nova |
-| T12 | Replan com worker incerto | Operação recusada ou ramo bloqueado até reconciliação pertinente |
-| T13 | Mensagem humana antes do wait, após timeout ou repetida | Matching/validade/consumo persistidos; timeout nunca aprova |
-| T14 | Efeito termina, owner cai antes de receipt | uncertain e reconciliação; sem retry automático não idempotente |
-| T15 | Artefato apagado/alterado ou dependência externa mudou | Reuso recusado; nenhum efeito refeito para esconder corrupção |
-| T16 | Subworkflow tenta reiniciar budget/ampliar escopo | Política externa bloqueia; contadores globais conservados |
-| T17 | Modelo/ambiente/schema/validator mudou | Fingerprint atualizado; reuso somente sob compatibilidade explícita |
-| T18 | Reviewer/check report aplica a candidato anterior | Gate recusa mesmo que o texto diga aprovado |
-| T19 | Publicação parcial e cancelamento sem árvore encerrada | Estado incerto visível; inspeção/reconciliação exigidas |
-| T20 | Run v1 antigo após instalar v2 | Semântica original preservada; nenhuma migração silenciosa |
-| T21 | Inventário de 80, discovery com 79/zero/extras/exclusão/rename | Omissão/vazio não provado/extras bloqueados; exclusão autorizada e rename contabilizados |
-| T22 | Vazio legítimo e alvo semântico não comprovado por glob | No-work somente com contrato/evidência; cobertura semântica inconclusiva permanece pendente |
-| T23 | Steering/revisão disputa CAS antes do ApplyIntent | Tupla vencedora determina aplicação; gate obsoleto não inicia |
-| T24 | Evento entre intent/primeiro write e entre dois writes | Intent congelado; ACK recebido/pending, nunca consumido; aplicado pertence à versão congelada |
-| T25 | Revogação, cancelamento ou crash após write e antes de receipt | Interrupção observada/reconciliação; nenhuma nova aplicação com apply-uncertain |
-| T26 | Assess-first aprovado, inconclusive repetido, limites distintos | Zero implementação quando aprovado; reavaliação limitada; counters/união accepted corretos |
-| T27 | Adicionar item, reordenar, alterar prompt/schema/receita/operador | Reuso por semântica local e entradas; aggregators invalidam; receipt vincula nova geração |
-| T28 | Worker vê arquivo compartilhado fora de writeScope | Snapshot visível entra no digest conservador; mudança pertinente impede falso reuso |
-| T29 | Diamond, ancestral ausente/ciclo e patches iguais de produtores distintos | Ancestral comum aplicado uma vez; estruturas inválidas rejeitadas; igualdade textual não deduplica automaticamente |
-| T30 | Check edita source, gera cache autorizado ou command alega read sem contenção | Source invalida candidato; scratch isolado permitido; capacidade insuficiente impede dispatch forte |
-| T31 | Crash na gravação de artefato/journal/checkpoint/ACK | Fonte autoritativa íntegra; outputRef nunca aponta a artefato não confirmado; power-loss tem escopo declarado |
-| T32 | Branch não selecionado, merge incompatível, child retry/cancel/uncertain | Join não espera skipped; obrigações externas preservadas; tipos validados; filho/effect não duplicado |
-| T33 | Evento antigo em wait novo, consumo duplicado, prazo e budget após restart | Matching de geração/invocação; decisão/consumo atômicos; expiração/contadores conservados |
-| T34 | DSL importa schema arbitrário, result não tipado ou receita sem ID | Rejeição sem executar módulo; registry/result/identidade exigidos |
+Regressão-global exige contribution lineage das 20 UIs. A avaliação final recaptura e verifica todas as UIs no candidato integrado, mesmo sem correção global. Se ela modificar código/CSS compartilhado, uma nova avaliação de todo o catálogo é obrigatória; receipts locais anteriores são históricos e não aprovações do conteúdo alterado. AssessmentContext liga capturas aos checks/reviewer, e AssessmentReceipt registra cobertura de cada obrigação. Nenhuma análise seletiva de impacto é presumida neste MVP. O gate valida a matriz de obrigações final para o candidato integrado. Se onConflict detectar overlap, run para antes da avaliação/aplicação, preserva candidatos e bloqueia; continuação por resolução exige o contrato de extensão descrito na seção 12. Saída acceptance-ready não aplica arquivo; aplicação é decisão posterior autorizada.
 
-Usar fault injection determinística nas fronteiras de commit/despacho/efeito; workers fake validam o runtime. Depois executar pilotos delimitados com SDK real para validar integração, distinguindo resultados de fixture, modelo, sistema e aceite humano.
+## 16. Exemplos auxiliares de paralelismo e controle humano
 
-## 22. Benchmark e prova da vantagem
+Fragmentos da API futura, não workflows executáveis isolados. Parallel expõe resultado explícito somente no join bem-sucedido; collect-all com filho required falho conserva ScopeResult para status/explain e bloqueia consumidores, sem avaliar result abaixo. Sequence cria controle independente de dados.
 
-Separar benchmark do runtime, com workers determinísticos e mesmas entradas, do benchmark de produto com modelos reais. Codex e Claude podem usar modelos distintos; diferenças de qualidade não devem ser atribuídas exclusivamente ao workflow.
-
-Não presumir que Claude real aceita injeção de fake workers. Se não houver mecanismo suportado, comparar fixtures do Fabric com scheduler de referência baseado na documentação, rotulado como modelo de referência, sem atribuir suas medições ao Claude real. Comparação de produto usa execuções efetivamente observadas, com avaliação externa e limitações causais declaradas.
-
-Cenários pareados: descoberta e migração de muitos itens; dois itens reprovados e restantes aceitos; falha intermediária no fan-out; crash/retomada; instrução humana na integração; conflito entre writers; composição aprovada por item que falha integrada.
-
-Congelar base, requisitos, ferramentas permitidas, política de efeitos, limites, avaliação externa e versões. Medir regime de recursos comparável e registrar defaults de produto em um regime separado. Caso o outro produto não permita um cenário, documentar limite e resultado alternativo; não transformar ausência de equivalência em benchmark numérico inventado.
-
-Métricas: requisitos aceitos/cobertos, falhas silenciosas, operações semânticas válidas repetidas com entradas compatíveis, duplicação de efeitos, intervenções, tempo, uso e cached tokens, custo quando realmente disponível, latência de recuperação, memória/bytes de artefatos e esforço de autoria/reuso. Separar retry por schema/infraestrutura de repair, prompt caching de reutilização de output, e medir programas inválidos/erros de autoria e overhead de clone/journal. Executar múltiplas repetições e registrar dispersão e limitações.
-
-Definir metas e tamanho das execuções antes das medições. Gate inicial de correção: nenhum aceite de candidato reprovado/obsoleto ou efeito duplicado nos cenários determinísticos; recuperação preserva ramos independentes comprovadamente válidos. Gate de expressividade: programas pequenos cobrem todos os padrões sem reconstrução manual do plano pelo chat. Metas de vantagem de tempo/custo/qualidade dependem da linha de base medida, sem prometer percentuais antecipados.
-
-O piloto real deve ser escolhido no contexto e autorização do projeto alvo. Um resultado local não prova aceite EasyGrow, produção, serviço always-on ou execução depois de fechar o App. Nenhuma medição é realizada pela escrita deste plano.
-
-## 23. Fora do primeiro aceite
-
-TypeScript/JavaScript irrestrito; migração arbitrária de pilhas async; streaming ilimitado de discovery; cache cross-run automático; efeitos externos exactly-once genéricos; replan arbitrário com workers ativos; concorrência alta não medida; novo serviço de sistema; auto-wakeup; novos providers/MCPs/credenciais; deployment; edição automática de memórias; reescrita de freezes ou aceites antigos.
-
-Itens podem virar entregas futuras explícitas após o núcleo e sua evidência. A DSL restrita tem menos liberdade que JavaScript geral: provar que expressa os workflows alvo é requisito, não supor paridade pela aparência TypeScript.
+```typescript
+parallel("analises", {
+  onFailure: "collect-all",
+  steps: [
+    agent("acessibilidade", {
+      executor: executorRef("revisar-acessibilidade", "v2"),
+      input: { captures: output("capturas") },
+    }),
+    agent("consistencia", {
+      executor: executorRef("revisar-consistencia", "v2"),
+      input: { captures: output("capturas") },
+    }),
+  ],
+  result: object({
+    accessibility: output("acessibilidade"),
+    consistency: output("consistencia"),
+  }),
+});
 
-## 24. Fontes e revisão
+sequence("decidir", {
+  steps: [
+    waitEvent("aprovacao", {
+      type: "candidate-approval",
+      correlation: field(acceptedCandidate("regressao-global"), "digest"),
+      subject: {
+        candidate: acceptedCandidate("regressao-global"),
+        contract: acceptance(),
+      },
+      schema: schemaRef("decisao-humana", "v2"),
+      timeoutMs: 3600000,
+    }),
+    gate("ready", {
+      candidate: acceptedCandidate("regressao-global"),
+      coverage: coverageReceipt("uis"),
+      authorization: output("aprovacao"),
+    }),
+  ],
+  result: output("ready"),
+});
+```
 
-Fontes de código do baseline: `src/forge/agent-fabric/workflow-engine.ts`, `managed-run-contract.ts`, `managed-run-service.ts`, `managed-run-store.ts`, `managed-workspace.ts`, `codex-sdk-worker.ts` e `workflow-task-actions.ts`. `tests/agent-fabric/managed-run-service.test.ts` registra rejeição de revisão e replanejamento preservando ramo independente. Os testes foram lidos, não reexecutados para este plano.
-
-Documentação atual do Fabric: `docs/agent-fabric.md` e `docs/architecture/agent-fabric/CODEX_DYNAMIC_WORKFLOWS.md`; planos históricos não são inventário atual.
+O schema decisao-humana descreve a decisão e receipt emitido pelo owner; não é booleano autodeclarado. Gate rejeita declínio, actor sem autoridade, expiração ou subject diferente. Esse sequence substituiria o gate direto do exemplo principal quando policy exigisse aprovação humana; não adicionar os dois gates independentes e permitir bypass. Timeout precisa caber no deadline do run. Pausar não significa cancelar automaticamente os irmãos; são operações distintas.
+
+## 17. Exemplo de registry e contratos do caso de UI
+
+Não persistir segredos. O registry abaixo é especificação de requisitos, não JSON de configuração atual. Schema/refs/digests serão validados na implementação.
+
+| Registro proposto | Responsabilidade |
+|---|---|
+| entrada-ui@v2 | Ambiente de teste identificado; overrides de ferramentas/domínios proibidos |
+| catalogo-uis@v2 | IDs rota/estado/viewport/auth fixture, baseline, paths autorizados, evidência e exclusões |
+| capturar-uis@v2 | Investigator readonly com browser autorizado; retorna itens/capturas duráveis e identidade da build |
+| capturar-candidato-ui@v2 | Evidence readonly de item/candidato, valida origem e emite CaptureReceipt |
+| revisar-ui@v2 | Reviewer distinto, saída approved/changes_requested/inconclusive, findings tipados e refs de evidências |
+| corrigir-ui@v2 | Implementer isolated-write, sem write fora do escopo owner |
+| ui-layout@v2 | Command check registrado, valida constraints objetivas pertinentes ao candidato/item |
+| capturar-candidato-completo@v2 | Evidence do catálogo para o candidato integrado |
+| revisar-ui-integrada@v2 | Avalia resultado integrado e possíveis regressões de componentes compartilhados |
+| corrigir-regressao-ui@v2 | Implementer limitado para correções globais autorizadas |
+| ui-regression@v2 | Check global de cobertura/renderização/constraints registradas |
+| qualidade-ui@v2 | IDs de obrigações por UI/final, bindings de scope/operation, requiredChecksByScope, evidências/cobertura e gate; no-work explicitamente decidido |
+| ui-local@v2 | Quotas, deadlines, byte budgets e capacidades browser/SDK/command por papel |
+| gate-ui@v2 | Receipt técnico de aceite ligado ao candidato; não recibo de deploy/aceite humano |
+
+Cada executor tem input/output schemas, timeout e capabilities efetivos. Contratos de captura e check recebem o candidato pelo contexto confiável do owner, não só pelo JSON do autor. Capacidade de browser aprovada não habilita rede arbitrária para todos os agentes.
+
+## 18. Persistência, observabilidade e budgets
+
+Manter uma fonte de verdade. Persista inputs/dispatch/results/decisões com ordem de commit definida; projection/UI é derivada. SHA verifica integridade, não autentica uma alegação de verdade por si só. Receipt owner fica em registro confiável e ligado às identidades; um objeto de agente com o mesmo formato não é receipt.
+
+Instrumentar desde P0/P1: tempo de lock/queue/preparation/SDK/check/serialização/hash/fsync, bytes gravados/retidos, uso de memória e recuperação. Cada invocation tem trace de deps/after, generation, attempts, candidate, evidence, budgets e razão de waiting/replay/invalidation. program-explain usa esses fatos. Logs têm redaction e budgets; não copiar transcript inteiro para cada snapshot.
+
+Profiling precede escolha de journal incremental/backend transacional. Otimização preserva atomicidade do registro autoritativo, references commitadas antes de uso, dispatch intent e correção em crash. Crash de processo tem prova separada de power-loss/filesystem. Migração, leitura de histórico e rollback precisam de contrato. GC posterior mantém artefatos alcançáveis por runs, gates, intents, receipts e retenção explícita; nunca apagar prova necessária para apply/reconcile.
+
+Budgets iniciais: owner slots, run/scope concurrency de atividades, itens/ops/profundidade, maxAttempts de dispatches visíveis, prazos, dados/artefatos/imagens e revisions. Reservas/debits têm unidade e ID persistidos, seguem seção 8 e não são repostos na retomada. Calls/retries internos só entram em limites próprios observáveis pelo adapter. Tokens/uso medidos por atividade e role. Cached input é subconjunto de input. Controle financeiro futuro requer preços versionados e reservas para calls em voo; sem limite verificável por chamada, declarar overshoot possível. Não prometer teto monetário rígido a partir de timeout/maxAttempts.
+
+## 19. Entregas e critérios de aceite
+
+| Fase | Entrega delimitada | Gate de aceite |
+|---|---|---|
+| P0 | ADR: grafo/after/scopes, outcomes/waits/quorum, obrigações por fase e schemas de receipts, resume/replan/cache, keys/compatibilidade; catálogo/API/examples; instrumentação básica | Contraexemplos têm comportamento único; v1 não muda; autorizações/ordens não ambíguas |
+| P1a | Resume de completed same-run, reconstrução de pais e budgets; diagnósticos | Siblings completos não chamam adapter/modelo novamente; gaps de commit/corrupção/uncertain tratados |
+| P1b | Fila pronta, exclusividade owner/reservas/quotas, sequence/parallel, waiting localizado, joins/quorum/cancelamento | Dependências de dados/controle respeitadas, fairness e deadlock de slots testados, espera não vira falha |
+| P1c | Tipos/diagnósticos e ciclo implementação/review/check/compose/gate com agentes simulados; transporte SDK stubado | Mesmo candidato e obrigações ligados, retomada preservada e políticas respeitadas nos cenários determinísticos; nenhuma chamada a modelo |
+| P2 | Caso UI com site local/fixtures, capturas e agentes simulados: artifacts/evidence/repair/integration | Capturas ligadas ao candidato, defeitos/infra separados e regressões conhecidas detectadas por checks determinísticos; sem alegar qualidade de revisão por LLM |
+| P3 | Profiling/otimização e benchmark determinístico do runtime | Metas e métricas publicadas; comparação real de produto com Claude/LLMs adiada até nova autorização |
+| Posterior | Outros harnesses, cache cross-run, fencing local, receitas extensíveis, planner adaptativo | Necessidade demonstrada e contratos anteriores preservados |
+
+Decisão do usuário em 07/10/2026: Forge é usado apenas pelo autor e está em dev; não há requisito de compatibilidade. O runtime adota operatorVersion 2 diretamente, sem interpretador legado ou migração de runs. P1b não é troca silenciosa de for-await por Promise.all. P1c usa implementadores/revisores simulados que produzem patches/findings conhecidos; P2 usa site local e fixtures com defeitos conhecidos. O contrato SDK pode ser validado com transporte stubado, sem iniciar cliente real conectado a provider. Generalização de pesquisa/data vem depois como exemplo adicional, sem bloquear o primeiro valor de produto.
+
+Cada etapa de implementação futura usa checks pertinentes do repo e evidência própria. Toda a matriz técnica deve rodar sem LLM: mocks/stubs fail-closed, contador de tentativas de provider esperado em zero e ausência de fallback para CLI/SDK real. Testes locais de filesystem, subprocessos determinísticos, browser sobre fixture e falhas/crashes injetados podem verificar efeitos reais do runtime sem modelo. Testes que dependem de modelos reais não são gates obrigatórios de implementação, CI ou release e permanecem desativados até nova autorização explícita. Este plano não inicia nenhuma dessas atividades.
+
+## 20. Matriz mínima de verificação
+
+| ID | Cenário | Resultado exigido |
+|---|---|---|
+| T01 | Grafo A/B independentes, C depende de ambos | Concorrência autorizada; C espera |
+| T02 | Controle humano A, writer B sem dado de A | B espera after/sequence, nunca só posição textual; declínio não concede autoridade de escrita |
+| T03 | Forward ref em grafo e em sequence | Grafo válido resolve; ciclo de sequence rejeitado |
+| T04 | Scope com filho required falho, result usa outro filho | Pai não oculta falha |
+| T05 | Cancel-siblings após falha | Completos preservados; ativos observados ou uncertain; nenhum falso sucesso |
+| T06 | Map nested com owner quota pequena | Pais não retêm slots; ausência de deadlock |
+| T07 | Dois runs/scopes competem | Sem starvation na policy de fairness testada |
+| T08 | Wait no root e dentro de map | waiting, não failed; irmãos independentes continuam |
+| T09 | Evento cedo/duplicado/expirado/geração antiga | Consumo único e binding correto; histórico preservado |
+| T10 | Declínio humano ou receipt fabricado | Não satisfaz gate nem autoriza apply |
+| T11 | Restart durante wait | Prazo absoluto e obrigação preservados |
+| T12 | Fan-out N−1 complete/um falho | Resume chama só o afetado; mesmo resultado/candidato para completos |
+| T13 | Activity commitada, parent não commitado | Reconstrução sem segunda execução |
+| T14 | Dispatch ocorreu, output não observado | Uncertain e reconciliação; não redispatch cego |
+| T15 | Artifact perdido/corrompido | Diagnóstico e bloqueio, sem cache-miss com efeito |
+| T16 | Replan troca entrada de um ramo | Invalidação de afetados/dependentes; intactos preservados explicitamente |
+| T17 | Resume após budget esgotado | Não repõe implementação/assessment/infra/global |
+| T18 | Capture inválida versus UI defeituosa | Classificação diferente, sem correção visual indevida |
+| T19 | Imagem de baseline antigo ou candidato diferente | Inconclusive/bloqueio; não aprovado |
+| T20 | Descoberta omite item required/no-work indevido | Coverage recusada |
+| T21 | Partial/quorum usado para gate all-required | Recusado, faltantes explícitos |
+| T22 | Repair rejeitado seguido de value | Rejeição não mascarada |
+| T23 | UI sem defeitos | Zero implementações do item, assessment/evidência válidos |
+| T24 | Duas correções de CSS compartilhado | Inputs/receipts preservados, conflito bloqueia MVP sem resolução automática |
+| T25 | Diamond/shared ancestor e patches iguais independentes | Ancestral uma vez; conflito independente preservado |
+| T26 | Correção global altera item antes aprovado | Todo o catálogo reavaliado no candidato final; obrigação antes aprovada pode reprovar |
+| T27 | Gate para candidato A, apply candidato B | Recusado |
+| T28 | Beforeimage alterada e aplicação parcial | Destino preservado; apply-uncertain, sem retry silencioso |
+| T29 | Dados readonly declaram accepted ou receipt falso | Sem autoridade de publicação |
+| T30 | Lowerer recebe import/callback/I/O arbitrário | Rejeitado antes de dispatch |
+| T31 | IDs/types/fields inválidos e expressão gigante | Diagnóstico/limite antes de alocação/execução |
+| T32 | Modelo/harness produz nested agents sem controle | Capacidade/limite declarado; nenhuma garantia agregada fictícia |
+| T33 | Policy revogada após atividade completa | Fato histórico legível, novo dispatch/apply bloqueado |
+| T34 | Crash em commit de decisão/result/intent | Fonte de verdade consistente; efeitos classificados |
+| T35 | GC/retention proposto apaga artifact gated | Impedido enquanto alcançável/retido |
+| T36 | Checks locais/finais distintos e omissão pelo autor | Binding owner correto; omissão/rebaixamento rejeitado antes de dispatch |
+| T37 | Reviewer/check sem refs, cobertura de item omitida ou ambiente trocado | AssessmentReceipt/gate recusados; contexto confiável exigido |
+| T38 | Quorum inválido, 2/3 com waiting e quorum impossível | K validado; waiting mantém aberto; timeout só por contrato; falha abaixo de K explícita |
+| T39 | Collect-all com filho required falho e result usando esse output | ScopeResult diagnóstico persistido; result não avaliado; sibling completo preservado |
+| T40 | Keys é/e\u0301, slash e restart em outro locale | Colisão NFC rejeitada; encoding único; identidade/ordem UTF-8 estáveis |
+| T41 | Dois owners, crash em reserva/dispatch e worker órfão vivo | Admissão exclusiva; reservas reconstruídas sem perda/dupla liberação; uncertain conservado |
+| T42 | Crash antes/depois do debit, retry SDK interno e completed resume | Debit por dispatch visível sem duplicar; retry novo debita; completed zero; limites internos declarados |
+| T43 | Futura resolução substitui deltas e perde obrigação | Receipt de extensão e cobertura final exigidos; não aceitação pelos receipts locais antigos |
+
+Fixtures testam contratos e não provam qualidade visual/modelo nem integração live com provider. Piloto SDK real e avaliação de qualidade com LLM estão adiados por instrução do usuário, sem bloquear os gates técnicos determinísticos. Typecheck/lowering/schema e execução futura devem testar a mesma definição; apenas aceitar sintaxe não valida semântica de API. Os cenários T01–T43 usam agentes simulados, transportes stubados e fixtures; T43 é teste da extensão apenas quando ela for implementada.
+
+## 21. Benchmark e comparação com Claude DW
+
+Executar somente a avaliação de correção/performance do runtime com adapters determinísticos e falhas injetadas. Avaliação do produto com modelos reais e execução de Claude DW ficam adiadas até nova autorização explícita. Uma referência procedural que não executa Claude nunca recebe rótulo “benchmark Claude”. O protocolo abaixo permanece documentado para eventual avaliação futura; não é trabalho autorizado agora. Se Fabric usa Codex e DW usa Claude, o resultado é do sistema completo. Comparação causal de runtime exige harness/modelo/ferramentas efetivamente equivalentes, quando isso for possível.
+
+Congelar tarefas/dataset/falhas, baseline, prompts por papel, ferramentas, isolamento, concorrência e critérios antes da execução. Dois cenários de autoria: workflow cuidadosamente escrito e geração por prompt; não misturá-los como se fossem a mesma medição. Repetições com ordem contrabalanceada; evaluator externo cego para origem do candidato. Avaliar candidato integrado, não só alterações isoladas.
+
+Métricas: obrigações/cobertura, falsos aceites, regressões, chamadas repetidas, tempo normal/recuperação, tokens por papel e uso/custo com incerteza, bytes/I/O e esforço/erros de autoria. Prompt cache é feature do provider distinta de saved-result replay. Preservar/configurar explicitamente defaults do concorrente e publicar limitações, falhas e dispersão.
+
+Hard gates iniciais: zero aceite fabricado/obsoleto nos cenários determinísticos; nenhuma repetição silenciosa de efeito incerto; same-run completed intacto gera zero novas chamadas; zero aplicação de candidato diferente do gated. Metas de latência/custo/esforço são fixadas após profiling baseline e antes do pareamento, sem inventar percentuais agora. Superioridade declarada somente nas dimensões/tarefas/configurações medidas.
+
+## 22. Limites e extensões posteriores
+
+Fora do núcleo inicial: JS/TS irrestrito, YAML nativo, discovery streaming ilimitado, race, serviço distribuído, novos MCPs/credenciais globais, wakeup automático, exactly-once externo genérico, cache SDK cross-run, live replan local, múltiplos providers completos e GC automático não especificado. Qualquer extensão exige necessidade demonstrada, versionamento e matriz de invariantes.
+
+Planner LLM posterior pode propor expansão/branches/plan diff, mas owner valida budgets, obrigações, capacidades e autoridade antes de materializar trabalho. Ele não pode retirar itens/critério porque ficou difícil, aprovar seu próprio candidato ou substituir decisão humana. Dados externos não tornam autorização legítima.
+
+## 23. Fontes e rastreabilidade
 
-Conceitos do Claude usados como paridade e referência: orquestração em script, operações de fan-out, outputs com schema, restrições de determinismo e I/O, progress/replay e caching. A documentação também descreve limites de input humano durante o run e regras de replay pela ordem de início. Esses detalhes são voláteis e foram consultados em 07/10/2026; validar novamente antes de benchmark ou implementação dependente de versão. Fonte primária: [Claude Code Dynamic Workflows](https://code.claude.com/docs/en/workflows).
+- [Claude DW](https://code.claude.com/docs/en/workflows): referência de autoria/script e comportamento público de replay; não avaliação de código interno.
+- [Claude subagents](https://code.claude.com/docs/en/sub-agents): referência de capacidades/isolamento que precisam de comparação equivalente.
+- [Temporal workflow definition](https://docs.temporal.io/workflow-definition): referência de determinismo/atividades; código também pode ser durável.
+- [Temporal messages](https://docs.temporal.io/encyclopedia/workflow-message-passing): referência da separação entre receber evento e obter decisão/resultado.
+- [LangGraph checkpointers](https://docs.langchain.com/oss/javascript/langgraph/checkpointers): referência de preservação de nós concluídos quando outro falha.
 
-Histórico: R1 foi revisada pelo novo subagente independente review_workflow_plan_v2, sobre SHA256 B0E6CC5A5BFF0E6DA5A8EF6E75EDA122149D3AE10D88B3EC5E874906B2D3FC68. Foram encontrados B1 (população/coverage) e B2 (gate/eventos/aplicação), além de I1–I6 (autoria, repair, reuso, ancestralidade, capacidades e milestones). R2 incorporou esses pontos e os refinamentos de branches, subworkflows, sinais, orçamento e benchmark. R2 foi lida integralmente pelo revisor sobre SHA256 7B14F970214FF86DF0D21D4F244A6E4795532D349E0F01EE0E89259817CD9BB8. R2.1 acrescenta somente a clarificação normativa do escopo e sua expressão no exemplo, além deste histórico/header. O relatório preserva os achados R1 e verifica o snapshot final vinculado ao digest.
+Baseline local lido: program-dsl.ts, program-contract.ts, program-service.ts, program-worker.ts, program-store.ts, codex-sdk-worker.ts em `C:\Users\stahl\Projects\forge\src\forge\agent-fabric`; docs/agent-fabric-programs.md e WORKFLOW_PROGRAM_V2_PLAN.md; evidências de entrega e revisão anterior em outputs. Artefatos anteriores: COMPARACAO_FABRIC_VS_CLAUDE_DW.md e REVISAO_PLANO_EVOLUCAO_FABRIC_VS_CLAUDE_DW.md. Esses documentos registram o baseline, não autorizações para implementar ou executar este plano.
 
-A revisão final combina leitura integral R2 e verificação do delta R2.1, avaliando contratos, exemplo, sequência de entregas e os 34 cenários, fechando ou mantendo explicitamente cada achado anterior. Relatório: `REVISAO_PLANO_WORKFLOWS_AGENT_FABRIC_V2.md`. Parecer arquitetural não comprova execução nem autoriza implementação.
+## 24. Revisão desta edição
+
+R1 examinada pelo novo subagente verify_revised_fabric_workflow_plan: SHA256 A1227F2CDE7C1E21DF3B468616B1346AD4728646C2575FDEEC0C8B6D54908893. Parecer: REVISAO_NOVO_PLANO_AGENT_FABRIC_WORKFLOWS.md, SHA256 C2727DCB39C58DBE1A423F392AEE9B972FE3CDE83BF22EC9780B7A6511B0DA24 (edição original do parecer, antes da confirmação R2).
+
+R2 incorpora F1–F7: obrigações item/final e AssessmentContext/Receipt; quorum com threshold e settle; collect-all diagnóstico; keys NFC antes de unicidade; exclusividade owner/reservas/órfãos; unidade observável de maxAttempts; MVP de conflitos bloqueia e resolução fica como extensão especificada. Acrescenta schemas canônicos e T36–T43. Catálogo fonte conferido: 11 operadores, 29 expressões, 7 refs e defineWorkflow; sequence/parallel são as únicas novas funções de autoria.
+
+A confirmação da R2 deve ser consultada no parecer independente, que registra o hash final examinado e sua conclusão. O hash do documento não pode ser embutido nele próprio; constará do parecer. Pesquisa/inspeção estática não constitui validação de implementação; não foram executados workflows, testes, owner ou modelos.
+
+R2.1: restrição direta posterior do usuário — “nao quero rodar testes reais com llm para nao gastar”. Substitui os gates de pilotos/modelos reais por validação determinística, transporte stubado e fixtures; posterga benchmark de produto/Claude até nova autorização. A aprovação independente registrada refere-se ao hash da R2, e não a esta edição posterior. A arquitetura e o exemplo conceitual permanecem os mesmos; nenhum teste ou workflow foi executado nesta atualização.