oxe-cc 1.4.1 → 1.5.1

package/oxe/templates/IMPLEMENTATION-PACK.template.json

@@ -0,0 +1,52 @@
+{
+  "schema_version": "1",
+  "generated_at": "YYYY-MM-DDTHH:MM:SSZ",
+  "ready": false,
+  "critical_gaps": [],
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "substituir pelo título da tarefa",
+      "mode": "mutating",
+      "ready": false,
+      "exact_paths": [
+        "src/example.ts"
+      ],
+      "write_set": "closed",
+      "symbols": [
+        {
+          "kind": "function",
+          "name": "exampleHandler",
+          "path": "src/example.ts",
+          "signature": "(input: ExampleInput) => ExampleOutput"
+        }
+      ],
+      "contracts": [
+        {
+          "name": "example-contract",
+          "input_shape": "ExampleInput",
+          "output_shape": "ExampleOutput",
+          "invariants": [
+            "não perder campos obrigatórios"
+          ],
+          "not_allowed": [
+            "mutar schema fora do write set"
+          ]
+        }
+      ],
+      "snippets": [
+        {
+          "source_ref": "not_applicable",
+          "path": "not_applicable",
+          "summary": "not_applicable",
+          "status": "not_applicable"
+        }
+      ],
+      "expected_checks": [
+        "npm test -- example"
+      ],
+      "requires_fixture": false,
+      "critical_gaps": []
+    }
+  ]
+}

package/oxe/templates/IMPLEMENTATION-PACK.template.md

@@ -0,0 +1,36 @@
+# OXE — Implementation Pack
+
+> Contrato racional de implementação por tarefa. Este arquivo complementa o `PLAN.md` e fecha write-set, symbols, contracts e checks esperados antes do `/oxe-execute`.
+
+## Status
+
+- **Status:** ready | not_ready | not_applicable
+- **Critical gaps abertos:** nenhum | listar
+- **Fonte:** `PLAN.md` + código real + anchors locais
+
+## Tarefas
+
+### T1 — (título)
+
+- **Mode:** mutating | docs_only | external | not_applicable
+- **Ready:** true | false
+- **Exact paths:** `src/...`, `config/...`
+- **Write set:** closed | external | not_applicable
+- **Symbols alvo:**
+  - `kind:name(path)` — assinatura ou shape esperado
+- **Contracts:**
+  - **Nome:** (ex.: payload parser)
+  - **Entrada:** ...
+  - **Saída:** ...
+  - **Invariants:** ...
+  - **Not allowed:** ...
+- **Expected checks:**
+  - `...`
+- **Requires fixture:** true | false
+- **Snippet/base local:** path ou `not_applicable`
+- **Critical gaps:** nenhum | listar
+
+## Observações
+
+- Use caminhos exatos; não usar `...`.
+- Tarefa mutável sem `symbols`, `contracts`, `write_set: closed` e `expected_checks` não deve sustentar confiança `> 90%`.

package/oxe/templates/PLAN.template.md

@@ -14,35 +14,36 @@ inputs: []
 
 > Gerado a partir de `.oxe/SPEC.md`. Cada tarefa deve ter bloco **Verificar**.
 
-## Resumo
-
-- **Spec vinculada:** (data ou versão informal)
-- **Ondas:** (número)
-- **Tarefas:** (número)
+## Resumo
+
+- **Spec vinculada:** (data ou versão informal)
+- **Ondas:** (número)
+- **Tarefas:** (número)
+- **Artefatos racionais:** `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS`, `FIXTURE-PACK`
 
 ## Autoavaliação do Plano
 
 - **Melhor plano atual:** sim
-- **Confiança:** 80%
+- **Confiança:** 92%
 - **Base da confiança:**
-  - Completude dos requisitos: 20/25
-  - Dependências conhecidas: 12/15
-  - Risco técnico: 15/20
-  - Impacto no código existente: 12/15
-  - Clareza da validação / testes: 13/15
-  - Lacunas externas / decisões pendentes: 8/10
+  - Completude dos requisitos: 23/25
+  - Dependências conhecidas: 14/15
+  - Risco técnico: 18/20
+  - Impacto no código existente: 14/15
+  - Clareza da validação / testes: 14/15
+  - Lacunas externas / decisões pendentes: 9/10
 - **Principais incertezas:** (0–3 bullets)
 - **Alternativas descartadas:** (1–2 linhas)
 - **Condição para replanejar:** (critério objetivo)
 
 <confidence_vector cycle="C-NN" generated_at="YYYY-MM-DDTHH:MM:SSZ">
-  <dim name="requirements"   score="0.80" weight="25" note="completude dos requisitos" />
-  <dim name="dependencies"   score="0.80" weight="15" note="dependências conhecidas" />
-  <dim name="technical_risk" score="0.75" weight="20" note="risco técnico — ajustar se H* pendentes" />
-  <dim name="code_impact"    score="0.80" weight="15" note="impacto no código existente" />
-  <dim name="validation"     score="0.87" weight="15" note="clareza da validação / testes" />
-  <dim name="open_gaps"      score="0.80" weight="10" note="lacunas externas / decisões pendentes" />
-  <global score="0.80" gate="proceed_with_risk" />
+  <dim name="requirements"   score="0.92" weight="25" note="completude dos requisitos" />
+  <dim name="dependencies"   score="0.93" weight="15" note="dependências conhecidas" />
+  <dim name="technical_risk" score="0.90" weight="20" note="risco técnico — ajustar se H* pendentes" />
+  <dim name="code_impact"    score="0.93" weight="15" note="impacto no código existente" />
+  <dim name="validation"     score="0.93" weight="15" note="clareza da validação / testes" />
+  <dim name="open_gaps"      score="0.90" weight="10" note="lacunas externas / decisões pendentes" />
+  <global score="0.92" gate="proceed" />
 </confidence_vector>
 
 <!--
@@ -66,11 +67,18 @@ inputs: []
 </hypothesis>
 -->
 
-## Dependências globais
-
-- (ex.: branch base, feature flags, migrations)
-
-## Replanejamento
+## Dependências globais
+
+- (ex.: branch base, feature flags, migrations)
+
+## Artefatos racionais de execução
+
+- **IMPLEMENTATION-PACK:** `ready | not_ready | not_applicable`
+- **REFERENCE-ANCHORS:** `ready | not_ready | not_applicable`
+- **FIXTURE-PACK:** `ready | not_ready | not_applicable`
+- **Critical gaps abertos:** (nenhum | listar IDs/causas)
+
+## Replanejamento
 
 > Preencher apenas em **--replan** ou após verify falhado. Manter histórico legível.
 
@@ -80,18 +88,19 @@ inputs: []
 
 ## Tarefas
 
-### T1 — (título)
-
-- **Arquivos prováveis:** `…`
-- **Depende de:** —
-- **Onda:** 1
-- **Complexidade:** S
-- **Verificar:**
-  - Comando: `…`
-  - Manual: (opcional) …
-- **Implementar:** o mínimo para fazer a verificação acima passar.
-- **Aceite vinculado:** A1, A2 (IDs da tabela de critérios em SPEC.md)
-
----
+### T1 — (título)
+
+- **Arquivos prováveis:** `…`
+- **Depende de:** —
+- **Onda:** 1
+- **Complexidade:** S
+- **Verificar:**
+  - Comando: `…`
+  - Manual: (opcional) …
+- **Implementar:** o mínimo para fazer a verificação acima passar.
+- **Aceite vinculado:** A1, A2 (IDs da tabela de critérios em SPEC.md)
+- **Contrato racional:** ver `IMPLEMENTATION-PACK.json` (task `T1`)
+
+---
 
 _(Adicione T2, T3, … conforme o comando oxe:plan.)_

package/oxe/templates/REFERENCE-ANCHORS.template.md

@@ -0,0 +1,24 @@
+# OXE — Reference Anchors
+
+> Materialização de referências críticas usadas pelo plano. Toda referência externa, predecessor, layout ou contrato que sustente uma tarefa deve virar âncora reproduzível aqui.
+
+<reference_anchors version="1" ready="false" status="not_ready">
+  <anchor
+    id="RA-01"
+    task="T1"
+    critical="true"
+    status="resolved"
+    source_type="local"
+    path=".oxe/investigations/externals/exemplo.txt"
+    source_ref="external-ref: exemplo">
+    <relevance>Por que esta referência sustenta a tarefa.</relevance>
+    <action>copy | adapt | consult</action>
+    <summary>Resumo semântico curto do trecho relevante ou do contrato.</summary>
+  </anchor>
+</reference_anchors>
+
+## Regras
+
+- Se não houver referência aplicável, usar `<reference_anchors ... status="not_applicable" ready="true">`.
+- `critical="true"` exige `status="resolved"` antes do execute.
+- `path` deve ser reproduzível no workspace ou materializado em `.oxe/investigations/externals/`.

package/oxe/templates/config.template.json

@@ -3,7 +3,7 @@
   "profile": "balanced",
   "discuss_before_plan": false,
   "verification_depth": "standard",
-  "plan_confidence_threshold": 70,
+  "plan_confidence_threshold": 90,
   "security_in_verify": false,
   "adversarial_verify": false,
   "after_verify_suggest_pr": true,
@@ -30,6 +30,7 @@
   "install": {
     "profile": "recommended",
     "repo_layout": "nested",
+    "ide_scope": "global",
     "vscode": false,
     "include_commands_dir": true,
     "include_agents_md": true

package/oxe/workflows/execute.md

@@ -120,9 +120,16 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 <context>
 **Contrato de raciocínio:** aplicar `oxe/workflows/references/reasoning-execution.md`. Antes de mutar, fazer reconhecimento curto; durante a execução, operar no menor write set viável e validar após cada fatia relevante.
 
-**Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de executar, validar os artefatos obrigatórios e o gate do plano.
-
-**Context pack prioritário:** antes de abrir o conjunto amplo de artefatos, resolver `.oxe/context/packs/execute.md` e `.oxe/context/packs/execute.json` como entrada principal do passo. Se o pack estiver fresco/coerente, usar `read_order` e `selected_artifacts` para limitar o reconhecimento inicial à onda/tarefa atual. Se estiver stale, ausente ou com lacunas críticas, fazer fallback explícito para leitura direta e registrar isso no runtime ou no resumo da execução.
+**Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de executar, validar os artefatos obrigatórios e o gate do plano.
+
+**Context pack prioritário:** antes de abrir o conjunto amplo de artefatos, resolver `.oxe/context/packs/execute.md` e `.oxe/context/packs/execute.json` como entrada principal do passo. Se o pack estiver fresco/coerente, usar `read_order` e `selected_artifacts` para limitar o reconhecimento inicial à onda/tarefa atual. Se estiver stale, ausente ou com lacunas críticas, fazer fallback explícito para leitura direta e registrar isso no runtime ou no resumo da execução.
+
+**Artefatos racionais obrigatórios:** quando a execução vier de `PLAN.md`, ler antes da primeira mutação:
+- `IMPLEMENTATION-PACK.md` / `IMPLEMENTATION-PACK.json`
+- `REFERENCE-ANCHORS.md`
+- `FIXTURE-PACK.md` / `FIXTURE-PACK.json`
+
+O `execute` é **pack-first**, não apenas `plan-first`. Esses artefatos existem para impedir improviso de paths, interfaces, referências externas e fixtures. Se estiverem ausentes, inconsistentes ou com `critical_gap`, a execução deve bloquear e devolver para replanejamento.
 
 **Runtime operacional:** usar `EXECUTION-RUNTIME.md` do escopo resolvido como artefato tático da execução. Ele deve refletir agentes ativos, onda atual, handoffs, evidências, retries, checkpoints pendentes e tarefas bloqueadas. O `PLAN.md` continua estratégico; o runtime regista a operação do ciclo.
 
@@ -182,14 +189,20 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
    - se estiver stale, incompleto ou ausente, declarar `fallback para leitura direta` antes de seguir.
 1b. **Verificação de hipóteses críticas:** se o context pack contiver o campo `hypotheses` com entradas `status: pending` cujo `checkpoint` coincide com a onda atual — validar cada uma antes de iniciar qualquer mutação. Se a hipótese for refutada, registrar bloqueio explícito em `EXECUTION-RUNTIME.md` e não editar código antes de resolver. Se for validada, atualizar `status: validated` no `PLAN.md`.
 1c. Fazer reconhecimento curto dos artefatos e arquivos prováveis da onda atual antes da primeira mudança. Com pack válido, limitar essa leitura aos artefatos de `read_order` e aos arquivos prováveis da onda; sem pack válido, expandir só o necessário.
-2. Se existir `PLAN.md`, validar a seção `## Autoavaliação do Plano` antes de qualquer implementação:
-   - `Melhor plano atual` deve ser `sim`;
-   - `Confiança` deve existir em `0–100%`;
-   - se `.oxe/config.json` definir `plan_confidence_threshold`, usar esse limiar; senão, usar `70%`;
-   - se a confiança estiver abaixo do limiar, **não executar**. Registrar o bloqueio e orientar redução de incerteza (`/oxe-discuss`, `/oxe-research` ou `/oxe-plan --replan`).
-3. Antes da primeira mudança, verificar `CHECKPOINTS.md` e `EXECUTION-RUNTIME.md` do escopo resolvido:
-   - se houver checkpoint `pending_approval` que se aplique à onda atual, **não avançar**;
-   - inicializar ou atualizar o runtime com onda atual, status, agentes ativos, handoffs e evidências esperadas.
+2. Se existir `PLAN.md`, validar a seção `## Autoavaliação do Plano` antes de qualquer implementação:
+   - `Melhor plano atual` deve ser `sim`;
+   - `Confiança` deve existir em `0–100%`;
+   - o bloco `<confidence_vector>` deve existir e ser coerente com a confiança declarada;
+   - se `.oxe/config.json` definir `plan_confidence_threshold`, usar esse limiar respeitando o piso canónico de `90%`; senão, usar `90%`;
+   - se a confiança não superar o limiar (`<=`) ou se a autoavaliação estiver incompleta, **não executar**. Registrar o bloqueio e orientar redução de incerteza (`/oxe-discuss`, `/oxe-research` ou `/oxe-plan --replan`).
+2a. Antes da primeira mutação, validar os artefatos racionais do plano:
+   - `IMPLEMENTATION-PACK.json` deve existir, estar `ready`, cobrir cada `Tn` mutável e usar `exact_paths` sem `...`, `symbols`, `contracts`, `write_set: "closed"` e `expected_checks`;
+   - `REFERENCE-ANCHORS.md` deve existir e manter todas as âncoras críticas em `status: resolved`;
+   - `FIXTURE-PACK.json` deve existir, estar `ready` e cobrir tarefas de parser/layout/integração/transformação/fila/migração/builder;
+   - se algum pack tiver `critical_gap`, **não executar**. Registrar o bloqueio explicitamente em `EXECUTION-RUNTIME.md` / `STATE.md` e recomendar um único próximo passo: normalmente `/oxe-plan --replan`.
+3. Antes da primeira mudança, verificar `CHECKPOINTS.md` e `EXECUTION-RUNTIME.md` do escopo resolvido:
+   - se houver checkpoint `pending_approval` que se aplique à onda atual, **não avançar**;
+   - inicializar ou atualizar o runtime com onda atual, status, agentes ativos, handoffs e evidências esperadas.
 3a. **Caminho padrão do runtime enterprise:** se `oxe-cc runtime` estiver disponível:
    - executar ou solicitar `oxe-cc runtime compile --dir <projeto>` antes da primeira mutação;
    - se compilar com sucesso, tratar `ACTIVE-RUN.json`, `.oxe/runs/<run_id>.json`, `compiled_graph` e `canonical_state` como estado operacional primário da execução;
@@ -209,11 +222,12 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
    - O mesmo gate aplica-se em Azure `apply` quando `scope: apply` ou `all`
 6. **Seleção de modo** (apenas se PLAN.md com 2+ ondas e `execute_mode` não definido em STATE): se o argumento já for `A`, `B` ou `C`, usá-lo diretamente; senão apresentar opções A/B/C e aguardar escolha; registrar em STATE.md.
 7. Identificar **onda ou bloco atual**: no PLAN, todas as tarefas da mesma onda sem dependências pendentes; no QUICK, passos ainda não marcados como feitos.
-8. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
-8a. Antes de implementar, explicitar no chat:
-   - **Contexto lido** (incluindo se veio de pack fresco ou de fallback)
-   - **Alvo da mudança**
-   - **Validação prevista**
+8. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
+8a. Antes de implementar, explicitar no chat:
+   - **Contexto lido** (incluindo se veio de pack fresco ou de fallback)
+   - **Artefatos racionais lidos** (implementation/anchors/fixtures e eventuais gaps)
+   - **Alvo da mudança**
+   - **Validação prevista**
 9. **Implementar** conforme o modo escolhido:
    - **Modo Completo:** executar todas as ondas em sequência com verificação inline entre ondas; sumarizar ao final.
    - **Modo Por onda:** executar onda atual, apresentar checklist, parar.
@@ -239,9 +253,11 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 - [ ] Onda ou bloco de passos explicitado antes de "implementar".
 - [ ] Checklist da onda apresentado ou refletido no STATE.md.
 - [ ] STATE.md registra progresso (Tn ou passos) e próximo passo.
-- [ ] Verificação alinhada ao bloco **Verificar** do PLAN ou QUICK.
-- [ ] OBS pendentes verificadas antes de cada onda: `blocking` resolvidos antes de avançar, `adjustment` incorporados como restrições, `info`/legado incorporados normalmente.
-- [ ] Com quick-agents ativos: cada agente trabalha só em seus `steps[]`; ao concluir, `quick-agents.json` → `done`.
-- [ ] Com blueprint schema 2 válido: não adotar persona para pedidos fora das `Tn`; `runId` alinhado entre JSON e STATE; handoffs escritos quando protocolo exige.
+- [ ] Verificação alinhada ao bloco **Verificar** do PLAN ou QUICK.
+- [ ] Com `PLAN.md`, `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` foram lidos e validados antes da primeira mutação.
+- [ ] Se qualquer artefato racional estiver ausente ou inconsistente, a execução bloqueia explicitamente e recomenda `/oxe-plan --replan`.
+- [ ] OBS pendentes verificadas antes de cada onda: `blocking` resolvidos antes de avançar, `adjustment` incorporados como restrições, `info`/legado incorporados normalmente.
+- [ ] Com quick-agents ativos: cada agente trabalha só em seus `steps[]`; ao concluir, `quick-agents.json` → `done`.
+- [ ] Com blueprint schema 2 válido: não adotar persona para pedidos fora das `Tn`; `runId` alinhado entre JSON e STATE; handoffs escritos quando protocolo exige.
 - [ ] Quando `oxe-cc runtime` estiver disponível, `runtime compile` foi tentado antes da primeira mutação e `runtime project` foi usado para reprojetar artefatos após a onda/bloco.
 </success_criteria>

package/oxe/workflows/next.md

@@ -22,7 +22,7 @@ Inspecionar `.oxe/STATE.md` global, a sessão ativa quando existir, e a existên
    - Senão → **execute** (há passos curtos a implementar).
 4. Se não houver `SPEC.md` no escopo resolvido e não for quick intencional declarado → **spec** (passo único).
 5. Se houver SPEC no escopo resolvido mas não PLAN → se `.oxe/config.json` tiver `discuss_before_plan: true` e faltar **`DISCUSS.md`** com decisões → **discuss**; senão → **plan**.
-6. Se PLAN existe mas a seção **Autoavaliação do Plano** disser `Melhor plano atual: não`, ou a `Confiança` estiver abaixo do limiar configurado (padrão 70%), o próximo passo deve ser **plan** (replanejar) ou **discuss/research** se a própria autoavaliação indicar isso.
+6. Se PLAN existe mas a seção **Autoavaliação do Plano** estiver incompleta, disser `Melhor plano atual: não`, ou a `Confiança` não superar o limiar configurado (padrão canónico `>90%`), o próximo passo deve ser **plan** (replanejar) ou **discuss/research** se a própria autoavaliação indicar isso.
 7. Se PLAN existe, **VERIFY.md** ainda **não** existe ou está claramente antes da implementação atual → **execute** (onda atual).
 8. Se PLAN existe e VERIFY falta após implementação declarada → **verify**.
 9. Se VERIFY indica falha ou gaps não resolvidos → **plan** (replanejamento) como passo único, com referência a `SUMMARY.md`.

package/oxe/workflows/plan.md

@@ -1,9 +1,18 @@
 # OXE — Workflow: plan
 
-<objective>
-Produzir **`.oxe/PLAN.md`**: tarefas **pequenas**, **ondas** (paralelizáveis vs sequenciais), e **cada tarefa com bloco de verificação** (comando de teste e/ou checklist manual).
-
-Base: `SPEC.md` do escopo resolvido da sessão (critérios com IDs **A1**, **A2**, …) + `.oxe/codebase/*` + código quando necessário (Grep/Read pontual).
+<objective>
+Produzir **`.oxe/PLAN.md`**: tarefas **pequenas**, **ondas** (paralelizáveis vs sequenciais), e **cada tarefa com bloco de verificação** (comando de teste e/ou checklist manual).
+
+Além do `PLAN.md`, este passo deve gerar no mesmo escopo resolvido da sessão os artefatos racionais de execução:
+- `.oxe/IMPLEMENTATION-PACK.md`
+- `.oxe/IMPLEMENTATION-PACK.json`
+- `.oxe/REFERENCE-ANCHORS.md`
+- `.oxe/FIXTURE-PACK.md`
+- `.oxe/FIXTURE-PACK.json`
+
+Esses artefatos são obrigatórios para considerar o plano executável. Quando algo não se aplicar, marcar explicitamente `not_applicable`; nunca omitir o arquivo.
+
+Base: `SPEC.md` do escopo resolvido da sessão (critérios com IDs **A1**, **A2**, …) + `.oxe/codebase/*` + código quando necessário (Grep/Read pontual).
 
 Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_failed`):
 - Ler `VERIFY.md` e `SUMMARY.md` do escopo resolvido, e o `PLAN.md` atual.
@@ -11,6 +20,37 @@ Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_fai
 - Se **SUMMARY.md** não existir, criar a partir de `oxe/templates/SUMMARY.template.md` para registrar o contexto do replan (ou dar append se já existir).
 </objective>
 
+<execution_rational_artifacts>
+## Artefatos racionais obrigatórios
+
+### IMPLEMENTATION-PACK
+Contrato de implementação por tarefa `Tn`, com:
+- caminhos exatos dos arquivos alvo, sem `...` e sem "arquivos prováveis" vagos;
+- symbols alvo (classe, função, método, listener, builder, config, migration);
+- assinatura/shape de entrada e saída;
+- dependências, invariantes, `not_allowed`, `write_set`, `expected_checks` e `requires_fixture`;
+- snippets somente quando ancorados em evidência local ou materializada.
+
+### REFERENCE-ANCHORS
+Materializa referências críticas que hoje ficam frouxas no plano:
+- predecessor, layout, contrato externo ou `external-ref`;
+- origem local ou materializada em `.oxe/investigations/externals/`;
+- `source_ref`, `path`, `relevance`, `action`, `summary`, `status`;
+- estados válidos: `resolved`, `missing`, `stale`, `conflicting`, `not_applicable`.
+
+### FIXTURE-PACK
+Fixtures mínimos por fluxo/tarefa de risco:
+- payloads, arquivos exemplo, trechos significativos, offsets/campos críticos;
+- expected outputs ou checks parciais/completos;
+- queries/checks de validação e smoke commands.
+
+Regra de readiness:
+- `IMPLEMENTATION-PACK` precisa estar `ready`;
+- `REFERENCE-ANCHORS` não pode ter âncora crítica em `missing|stale|conflicting`;
+- `FIXTURE-PACK` é obrigatório para tarefas mutáveis com parser/layout/integração/transformação/fila/migração/builder;
+- qualquer `critical_gap` aberto derruba a prontidão executável do plano.
+</execution_rational_artifacts>
+
 <plan_iteration_contract>
 ## Contrato de iteração do plano
 
@@ -112,11 +152,11 @@ Depois do resumo e antes das tarefas, o `PLAN.md` deve conter também:
 | Clareza da validação / testes | 15 |
 | Lacunas externas / decisões pendentes | 10 |
 
-**Faixas semânticas obrigatórias:**
-- `85–100%` → pronto para executar
-- `70–84%` → executável com risco controlado
-- `50–69%` → precisa refino antes de execução
-- `<50%` → não executar
+**Faixas semânticas obrigatórias:**
+- `91–100%` → pronto para executar
+- `80–90%` → plano racional, mas ainda não executável
+- `50–79%` → precisa refino antes de execução
+- `<50%` → não executar
 
 **Entradas obrigatórias da confiança:**
 - usar as incertezas estruturadas da SPEC e as investigações concluídas como base direta da rubrica;
@@ -131,7 +171,9 @@ Depois do resumo e antes das tarefas, o `PLAN.md` deve conter também:
 | `L` | < 1 dia, múltiplos componentes | Verificar que Verificar é específico |
 | `XL` | > 1 dia, impacto arquitetural | **Gate: deve ser quebrada em sub-tarefas ou ter justificativa** |
 
-**Princípio test-first:** escreva o `Verificar` antes de escrever o `Implementar`. A pergunta é: "Como saberei que está pronto?" — a resposta define o target; `Implementar` é o caminho mínimo até esse target.
+**Princípio test-first:** escreva o `Verificar` antes de escrever o `Implementar`. A pergunta é: "Como saberei que está pronto?" — a resposta define o target; `Implementar` é o caminho mínimo até esse target.
+
+**Contrato racional por tarefa:** se a tarefa for mutável ou tecnicamente relevante, o `PLAN.md` sozinho não basta. O `IMPLEMENTATION-PACK` deve fechar o write-set, os symbols e os checks; o `REFERENCE-ANCHORS` deve materializar evidência externa; o `FIXTURE-PACK` deve reduzir improviso em parsing/integração/transformação.
 
 **Projetos sem suíte de testes única (legado):** o bloco **Verificar** pode usar `Comando: —` e **Manual** com Grep, leitura de paths ou checklist — ver exemplos em **`oxe/workflows/references/legacy-brownfield.md`**. Todo critério **A*** da SPEC deve aparecer em **Aceite vinculado** de alguma tarefa ou como gap explícito.
 
@@ -150,14 +192,18 @@ Antes de finalizar a resposta ao utilizador, o agente **deve** percorrer este ga
 7. **Fidelidade de decisões:** se existir `DISCUSS.md` com IDs **D-NN** no escopo resolvido, cada decisão com impacto técnico deve aparecer em **Decisão vinculada:** de alguma tarefa, ou ter nota explícita de gap. Sem cobertura para D-NN técnico = falha do gate.
 8. **Complexidade XL:** toda tarefa com `Complexidade: XL` deve ter sub-tarefas explícitas (ex.: T3.1, T3.2 — como bullets dentro da tarefa) **ou** justificativa na tarefa explicando por que não pode ser quebrada. Tarefa XL sem sub-tarefas e sem justificativa = falha do gate.
 9. **Test-first:** em toda tarefa, `Verificar` deve preceder `Implementar` no texto. Se a ordem estiver invertida, corrigir antes de finalizar.
-10. **Autoavaliação presente:** o `PLAN.md` contém `## Autoavaliação do Plano`, `Melhor plano atual`, `Confiança`, rubrica completa e `Condição para replanejar`.
-11. **Calibração de execução:** se `Melhor plano atual: não` ou `Confiança < limiar configurado`, o plano não pode recomendar execução direta; deve recomendar refino, discuss ou research.
+10. **Autoavaliação presente:** o `PLAN.md` contém `## Autoavaliação do Plano`, `Melhor plano atual`, `Confiança`, rubrica completa, bloco `<confidence_vector>` coerente e `Condição para replanejar`.
+11. **Calibração de execução:** se `Melhor plano atual: não`, se a autoavaliação estiver estruturalmente incompleta, ou se `Confiança <= limiar configurado`, o plano não pode recomendar execução direta; deve recomendar refino, discuss ou research.
 12. **Rastreabilidade de evidência:** cada tarefa deve ter entrada observável de origem na SPEC, no codebase, em DISCUSS, OBS, RESEARCH ou LESSONS; tarefa sem evidência de entrada explícita = falha do gate.
-13. **Mudanças de risco:** tarefas com risco relevante (migração, auth, schema, contrato público, segurança) devem incluir contenção, rollback, fallback ou verificação reforçada.
-14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
-15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
-
-Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
+13. **Mudanças de risco:** tarefas com risco relevante (migração, auth, schema, contrato público, segurança) devem incluir contenção, rollback, fallback ou verificação reforçada.
+14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
+15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
+16. **Implementation contract:** toda tarefa mutável deve aparecer em `IMPLEMENTATION-PACK.json` com `exact_paths`, `symbols`, `contracts`, `write_set: "closed"`, `expected_checks` e `ready: true`. Path com `...`, símbolo indefinido ou contrato ausente = falha do gate.
+17. **Reference anchors:** toda referência `external-ref`, "copiar do predecessor", "usar layout X" ou equivalente deve aparecer em `REFERENCE-ANCHORS.md` com `status: resolved`. Âncora crítica em `missing|stale|conflicting` = falha do gate.
+18. **Fixture coverage:** toda tarefa de parser/layout/integração/transformação/fila/migração/builder deve ter fixture `ready` em `FIXTURE-PACK.json`, salvo `not_applicable` explicitamente justificado. Ausência de fixture em tarefa de risco = falha do gate.
+19. **Confiança > 90 de verdade:** `Confiança > 90%` só é válida se `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` estiverem íntegros e sem `critical_gap` aberto. Caso contrário, reduzir a confiança para `<= 90%` e recomendar refino.
+
+Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
 
 Resumo obrigatório no chat: `Gate do plano: OK` ou `Gate do plano: corrigido (N problemas)`.
 </plan_quality_gate>
@@ -178,12 +224,22 @@ Resumo obrigatório no chat: `Gate do plano: OK` ou `Gate do plano: corrigido (N
 3. Se existir **`.oxe/NOTES.md`**, consumir ou explicitamente adiar cada bullet relevante (ver **context**).
 4. Ler `.oxe/codebase/*.md` (incl. CONVENTIONS / CONCERNS) e inspecionar pontos de entrada se a spec exigir. Se o pack não bastar, expandir a leitura apenas para os artefatos adicionais necessários e registar essa expansão.
 5. Escrever ou atualizar `PLAN.md` no escopo resolvido usando `oxe/templates/PLAN.template.md` como cabeçalho; **preservar** YAML inicial (`oxe_doc: plan`, `status`, `inputs`) se já existir e **atualizar** `updated:` (ISO); em **--replan** ou **replan implícito**, preencher a seção **Replanejamento** (data, motivo, lições de VERIFY/SUMMARY, tarefas removidas/alteradas).
+5a. Gerar junto os artefatos racionais:
+   - `IMPLEMENTATION-PACK.md` e `IMPLEMENTATION-PACK.json` a partir de `oxe/templates/IMPLEMENTATION-PACK.template.*`
+   - `REFERENCE-ANCHORS.md` a partir de `oxe/templates/REFERENCE-ANCHORS.template.md`
+   - `FIXTURE-PACK.md` e `FIXTURE-PACK.json` a partir de `oxe/templates/FIXTURE-PACK.template.*`
+   Todos no mesmo escopo resolvido da sessão do `PLAN.md`.
 6. Definir ondas: onda 1 = tarefas sem dependência entre si; onda seguinte = dependentes; respeitar `plan_max_tasks_per_wave` se configurado.
 6a. **Calibração histórica:** se `.oxe/calibration.json` existir e tiver ≥ 2 registros, ler as últimas 3 entradas antes de preencher a autoavaliação. Para cada dimensão com `calibration_error > 0.25` em 2+ ciclos consecutivos, adicionar `[⚠ historicamente subestimado]` na nota da dimensão e reduzir o score em 0.10 ou justificar explicitamente por que o ciclo atual é diferente.
-7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos. As lacunas, conflitos e freshness do pack devem aparecer nessa autoavaliação quando forem relevantes. **Incluir o bloco `<confidence_vector>`** com as 6 dimensões usando o template em `oxe/templates/PLAN.template.md`.
+7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos. As lacunas, conflitos e freshness do pack devem aparecer nessa autoavaliação quando forem relevantes. **Incluir o bloco `<confidence_vector>`** com as 6 dimensões usando o template em `oxe/templates/PLAN.template.md`.
+7b. Antes de declarar `Confiança > 90%`, validar os artefatos racionais:
+   - `IMPLEMENTATION-PACK` sem write-set aberto e sem paths `...`;
+   - `REFERENCE-ANCHORS` com âncoras críticas resolvidas;
+   - `FIXTURE-PACK` cobrindo tarefas de risco.
+   Se algo falhar, a confiança deve cair para `<= 90%` e o próximo passo não pode ser `execute`.
 7a. **Hipóteses Críticas:** ao criar tarefas `L` ou `XL` ou qualquer tarefa que dependa de lib externa, API de terceiros ou serviço de infra não testado ainda — adicionar seção `## Hipóteses Críticas` com pelo menos uma `<hypothesis>` por dependência crítica. Usar `oxe/templates/HYPOTHESES.template.md` como referência. Omitir a seção se todas as tarefas forem `S`/`M` e sem dependências externas não verificadas.
 8. Aplicar integralmente o bloco **`<plan_quality_gate>`** acima ao `PLAN.md` em disco; corrigir o ficheiro até passar ou documentar gaps explícitos.
-9. Atualizar `.oxe/STATE.md` global: fase `plan_ready`, próximo passo `oxe:execute` apenas se `Melhor plano atual: sim` e a confiança estiver no limiar executável; caso contrário, próximo passo deve reduzir incerteza (`oxe:discuss`, `oxe:research` ou replanejamento).
+9. Atualizar `.oxe/STATE.md` global: fase `plan_ready`, próximo passo `oxe:execute` apenas se `Melhor plano atual: sim`, a autoavaliação estiver estruturalmente íntegra e a confiança superar o limiar executável; caso contrário, próximo passo deve reduzir incerteza (`oxe:discuss`, `oxe:research` ou replanejamento).
 10. **Sugestão de agentes (inteligente):** após o gate passar, verificar se o plano tem 3+ domínios distintos (ex.: backend + frontend + DB, ou auth + notificações + UI). Se sim, sugerir proativamente: "Este plano tem N domínios distintos. Quer gerar um blueprint de agentes com `/oxe-plan --agents`?" — não executar automaticamente, apenas oferecer. Se o usuário incluiu `--agents` no input original, executar imediatamente a lógica de `oxe/workflows/plan-agent.md`.
 11. Listar no chat: resultado do gate (OK ou corrigido), ondas, contagem de tarefas, comando de teste guarda-chuva se houver, melhor-plano-atual e confiança.
 12. No resumo em chat, deixar explícitos:
@@ -198,6 +254,8 @@ Resumo obrigatório no chat: `Gate do plano: OK` ou `Gate do plano: corrigido (N
 <success_criteria>
 - [ ] Cada tarefa tem seção **Verificar** com comando ou checklist explícito.
 - [ ] Dependências entre tarefas estão explícitas.
-- [ ] Cada critério da SPEC (IDs **A***) está mapeado em **Aceite vinculado** de alguma tarefa ou explicitamente marcado como gap no plano.
-- [ ] Cada R-ID `v1`/`v2` do SPEC tem ao menos um A* coberto por alguma tarefa, ou gap documentado (gate 14).
-</success_criteria>
+- [ ] Cada critério da SPEC (IDs **A***) está mapeado em **Aceite vinculado** de alguma tarefa ou explicitamente marcado como gap no plano.
+- [ ] Cada R-ID `v1`/`v2` do SPEC tem ao menos um A* coberto por alguma tarefa, ou gap documentado (gate 14).
+- [ ] `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` existem no escopo resolvido e não ficaram em branco.
+- [ ] Não há `critical_gap` aberto nos artefatos racionais quando a confiança declarada é `> 90%`.
+</success_criteria>

package/oxe/workflows/references/flow-robustness-contract.md

@@ -57,9 +57,9 @@ Todo `PLAN.md` deve conter uma seção visível `## Autoavaliação do Plano` co
 
 ### Faixas semânticas
 
-- `85–100%` → pronto para executar
-- `70–84%` → executável com risco controlado
-- `50–69%` → precisa refino antes de execução
+- `91–100%` → pronto para executar
+- `80–90%` → plano racional, mas ainda não executável
+- `50–79%` → precisa refino antes de execução
 - `<50%` → não executar
 
 ## Calibração pós-execução