oxe-cc 1.5.1 → 1.7.0

package/oxe/templates/PLAN.template.md

@@ -2,8 +2,18 @@
 oxe_doc: plan
 status: draft
 updated: YYYY-MM-DD
-inputs: []
----
+inputs: []
+spec_version: ""
+plan_confidence_threshold: 90
+goal_backward_verification: required
+rationality_gate: required
+risk_level: low | medium | high | critical
+autonomous: false
+must_haves: []
+dependencies: []
+checkpoints: []
+evidence_expectation: manifest | command | manual | mixed
+---
 
 <!--
   Metadados OXE. Manter --- antes do primeiro #. Atualize `updated` a cada revisão significativa.
@@ -14,36 +24,39 @@ 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)
-- **Artefatos racionais:** `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS`, `FIXTURE-PACK`
+## Resumo
 
-## Autoavaliação do Plano
+- **Spec vinculada:** (data ou versão informal)
+- **Ondas:** (número)
+- **Tarefas:** (número)
+- **Artefatos racionais:** `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS`, `FIXTURE-PACK`
 
-- **Melhor plano atual:** sim
+## Autoavaliação do Plano
+
+- **Melhor plano atual:** sim
 - **Confiança:** 92%
-- **Base da confiança:**
+- **Limiar para execute:** > 90%
+- **Resultado do gate racional:** ready | not_ready
+- **Base da confiança:**
   - 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)
+  - 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)
+- **Bloqueadores de execução:** nenhum | listar gaps críticos
 
 <confidence_vector cycle="C-NN" generated_at="YYYY-MM-DDTHH:MM:SSZ">
-  <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" />
+  <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>
 
 <!--
@@ -67,10 +80,10 @@ inputs: []
 </hypothesis>
 -->
 
-## Dependências globais
-
-- (ex.: branch base, feature flags, migrations)
-
+## Dependências globais
+
+- (ex.: branch base, feature flags, migrations)
+
 ## Artefatos racionais de execução
 
 - **IMPLEMENTATION-PACK:** `ready | not_ready | not_applicable`
@@ -78,7 +91,21 @@ inputs: []
 - **FIXTURE-PACK:** `ready | not_ready | not_applicable`
 - **Critical gaps abertos:** (nenhum | listar IDs/causas)
 
-## Replanejamento
+### Contrato goal-backward
+
+| Critério | Evidência esperada | Tarefa(s) | Risco se falhar |
+|----------|--------------------|-----------|-----------------|
+| A1 | comando, arquivo, fixture ou UAT | T1 | high |
+
+### Must-haves de execução
+
+- Nenhuma tarefa mutável com path ambíguo.
+- Nenhum símbolo alvo indefinido.
+- Nenhuma referência crítica não materializada.
+- Nenhuma tarefa de parsing/integração/transformação sem fixture ou justificativa `not_applicable`.
+- Nenhum checkpoint humano pendente antes de side effect crítico.
+
+## Replanejamento
 
 > Preencher apenas em **--replan** ou após verify falhado. Manter histórico legível.
 
@@ -90,16 +117,20 @@ inputs: []
 
 ### T1 — (título)
 
-- **Arquivos prováveis:** `…`
+- **Arquivos alvo:** `src/exato.ts`
 - **Depende de:** —
 - **Onda:** 1
 - **Complexidade:** S
+- **Risco:** low | medium | high | critical
+- **Evidência de entrada:** SPEC A1 | DISCUSS D-01 | RESEARCH RA-01 | codebase path
+- **Checkpoint:** nenhum | CHK-01
 - **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`)
+- **Rollback/contensão:** obrigatório para risco high/critical; `not_applicable` se low/medium.
 
 ---
 

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

@@ -1,24 +1,28 @@
-# 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">
+# 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"
+    id="RA-01"
+    task="T1"
+    critical="true"
+    status="resolved"
+    source_type="local"
     path=".oxe/investigations/externals/exemplo.txt"
+    snippet_ref="lines 10-30"
     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>
+    <critical_fields>IDs, colunas, offsets, eventos ou contratos que não podem ser improvisados.</critical_fields>
   </anchor>
 </reference_anchors>
-
-## Regras
-
-- Se não houver referência aplicável, usar `<reference_anchors ... status="not_applicable" ready="true">`.
+
+## 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/`.
+- Referência solta em texto não é evidência. Se o path/range/snippet não puder ser materializado, marcar `status="missing"` e derrubar readiness.
+- Anchors podem ser locais, externos materializados, predecessor interno, contrato público, fixture ou decisão registrada.

package/oxe/templates/RESEARCH.template.md

@@ -1,4 +1,4 @@
-# OXE — Nota de pesquisa
+# OXE — Nota de pesquisa
 
 > Um ficheiro por sessão: copie para `.oxe/research/YYYY-MM-DD-<slug-kebab>.md` (data ISO; slug curto e único).
 
@@ -7,16 +7,16 @@
 - Ligação à SPEC: objetivo, IDs **A*** tocados (ou *N/A — SPEC ainda não existe* + recomendação de `oxe:spec`).
 - Entrada do utilizador / âmbito (paths, módulos, perguntas).
 
-## Perguntas em aberto
-
-1. … (critério para considerar “fechado”)
-
-## Investigação estruturada
-
-- **Objetivo:** …
-- **Modo:** `surface` | `standard` | `deep`
-- **Fontes:** …
-- **Profundidade:** …
+## Perguntas em aberto
+
+1. … (critério para considerar “fechado”)
+
+## Investigação estruturada
+
+- **Objetivo:** …
+- **Modo:** `surface` | `standard` | `deep`
+- **Fontes:** …
+- **Profundidade:** …
 
 ## Evidência
 

package/oxe/templates/SPEC.template.md

@@ -19,12 +19,12 @@ inputs: []
 
 (Uma frase: o que entregar.)
 
-## Contexto
-
-- Repositório / produto: …
-- Links úteis: …
-- Tipo de demanda: feature | bugfix | refactor | research | ops | mixed
-- Incertezas estruturadas: …
+## Contexto
+
+- Repositório / produto: …
+- Links úteis: …
+- Tipo de demanda: feature | bugfix | refactor | research | ops | mixed
+- Incertezas estruturadas: …
 
 ## Escopo
 

package/oxe/templates/SUMMARY.template.md

@@ -1,20 +1,50 @@
 # OXE — Resumo de sessão
 
-> Usado por **verify** (append) e por **plan --replan** para contexto incremental. Podes criar manualmente a partir deste template.
+> Usado por **execute**, **verify** e **plan --replan** para contexto incremental, evidência e retomada.
 
 ## Sessão
 
 - **Data:** (ISO ou legível)
+- **Run:** ...
 - **Spec / plano:** (referência breve a `.oxe/SPEC.md` / `.oxe/PLAN.md`)
+- **Modo:** completo | por_onda | por_tarefa | runtime
+
+## Performance
+
+- **Ondas concluídas:** N/N
+- **Tarefas concluídas:** N/N
+- **Retries:** N
+- **Checkpoints:** aprovados N | pendentes N | waived N
 
 ## Feito nesta sessão
 
 - …
 
-## Decisões / notas
+## Arquivos criados/modificados
 
-- …
+| Path | Motivo | Tarefa |
+|------|--------|--------|
+| `src/example.ts` | implementação do contrato | T1 |
+
+## Decisões / desvios
+
+- **Decisões aplicadas:** D-01, D-02
+- **Desvios do plano:** nenhum | listar com motivo, impacto e evidência
+- **Fixes inline:** nenhum | listar hipótese e comando de verificação
+
+## Evidências
+
+- **Manifest:** `verification-manifest.json` | not_available
+- **Coverage:** `evidence-coverage.json` | not_available
+- **Residual risk:** `residual-risk-ledger.json` | not_available
+- **Comandos executados:** ...
 
 ## Pendente ou follow-up
 
 - …
+
+## Next Step Readiness
+
+- **Próximo passo recomendado:** `/oxe-verify` | `/oxe-plan --replan` | `/oxe-execute`
+- **Bloqueadores:** nenhum | listar
+- **Risco residual:** low | medium | high | critical

package/oxe/templates/config.template.json

@@ -3,7 +3,7 @@
   "profile": "balanced",
   "discuss_before_plan": false,
   "verification_depth": "standard",
-  "plan_confidence_threshold": 90,
+  "plan_confidence_threshold": 90,
   "security_in_verify": false,
   "adversarial_verify": false,
   "after_verify_suggest_pr": true,

package/oxe/workflows/debug.md

@@ -15,17 +15,19 @@ Diferente de **`verify`**, que audita **aceite** contra SPEC/PLAN. Depois de est
 - Pré-requisito: sintoma reproduzível ou descrição clara (mensagem de erro, Tn em falha).
 - Preferir ancorar ao identificador de tarefa **`Tn`** do `PLAN.md` do escopo resolvido quando existir.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, usar `.oxe/<active_session>/execution/DEBUG.md`; sem sessão ativa, usar `.oxe/DEBUG.md`.
-- Artefato: **`DEBUG.md`** no escopo correto — ficheiro único com **sessões** datadas (append); não dispersar em vários ficheiros sem convenção.
+- Artefato: **`DEBUG.md`** no escopo correto — ficheiro único com **sessões** datadas (append); não dispersar em vários ficheiros sem convenção.
+- Agente especializado: quando disponível, usar `oxe-debugger` para conduzir hipótese, reprodução mínima, evidência, eliminados e handoff retomável. O agente não deve declarar entrega aprovada; após correção, a trilha volta para `execute` e depois `verify`.
 </context>
 
 <process>
 1. Ler `PLAN.md` do escopo resolvido e `.oxe/STATE.md`; se o foco for uma tarefa, localizar **Tn** e o bloco **Verificar**.
-2. Registar em **`DEBUG.md`** do escopo resolvido uma nova sessão:
-   - **Data** / **Sintoma** (com stack ou comando que falhou).
-   - **Hipóteses** (ordenadas por plausibilidade).
-   - **Experiências** — o que foi tentado e resultado (uma linha cada).
-   - **Evidência atual** — ficheiros, linhas, conclusão parcial.
-   - **Próximo passo:** `execute` (continuar correção) | `discuss` (decisão técnica em grupo) | `spec` ou `plan` (requisito ambíguo ou impossível como escrito).
+2. Registar em **`DEBUG.md`** do escopo resolvido uma nova sessão:
+   - **Data** / **Sintoma** (com stack ou comando que falhou).
+   - **Hipóteses** (ordenadas por plausibilidade).
+   - **Experiências** — o que foi tentado e resultado (uma linha cada).
+   - **Eliminados** — hipóteses descartadas e evidência.
+   - **Evidência atual** — ficheiros, linhas, conclusão parcial.
+   - **Próximo passo:** `execute` (continuar correção) | `discuss` (decisão técnica em grupo) | `spec` ou `plan` (requisito ambíguo ou impossível como escrito).
 3. Se a causa for **requisito errado**, documentar em DEBUG e recomendar **`/oxe-spec`** ou **`/oxe-plan`** (e opcionalmente **`/oxe-discuss`**).
 4. Resumo no chat em ≤8 linhas, nesta ordem:
    - **Contexto lido**

package/oxe/workflows/execute.md

@@ -120,16 +120,18 @@ 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.
+
+**Agente executor especializado:** quando um runtime suportar agentes OXE, o papel esperado é `oxe-executor`. Para ondas com UI, debug, integração ou validação pesada, consultar os agentes especializados correspondentes, mas manter o estado operacional em `.oxe/` e no runtime.
 
 **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.
 
@@ -189,20 +191,21 @@ 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%`;
-   - 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`).
+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;
+   - `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.
+   - se uma tarefa mutável usar path com `...`, símbolo indefinido, write-set aberto ou fixture obrigatória ausente, bloquear a tarefa mesmo que o `PLAN.md` pareça completo.
+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;
@@ -222,12 +225,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)
-   - **Artefatos racionais lidos** (implementation/anchors/fixtures e eventuais gaps)
-   - **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.
@@ -253,11 +256,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.
-- [ ] 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.
+- [ ] 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/forensics.md

@@ -16,7 +16,8 @@ Não reescrever `SPEC.md` nem apagar `PLAN.md`; apenas **recomendar** o reingres
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`; ler `.oxe/STATE.md` global e os artefatos de sessão (`VERIFY.md`, `PLAN.md`, `SPEC.md`, `QUICK.md`) no escopo resolvido.
 - **Git é opcional:** em sandbox sem Git ou sem permissão de terminal, **não** falhar o workflow; registar em `FORENSICS.md` que Git não foi avaliado.
 - Opcional: saída resumida de `npx oxe-cc doctor` no diretório do projeto.
-- Se o sintoma for **mapa OXE desatualizado** (ex.: `STACK.md` / estrutura em `.oxe/codebase/` claramente atrás do repo) sem workflows em falta, a **Hipótese de causa** ou a **Justificativa** pode mencionar **`/oxe-compact`** como ação complementar **depois** de escolhido o passo canónico — o próximo passo OXE recomendado continua a ser **um** entre `scan` | `plan` | `execute`.
+- Se o sintoma for **mapa OXE desatualizado** (ex.: `STACK.md` / estrutura em `.oxe/codebase/` claramente atrás do repo) sem workflows em falta, a **Hipótese de causa** ou a **Justificativa** pode mencionar **`/oxe-compact`** como ação complementar **depois** de escolhido o passo canónico — o próximo passo OXE recomendado continua a ser **um** entre `scan` | `plan` | `execute`.
+- Agentes úteis: `oxe-debugger` para falha técnica, `oxe-integration-checker` para divergência entre ondas/artefatos, `oxe-validation-auditor` para evidence gaps e `oxe-codebase-mapper` quando o mapa estiver obsoleto.
 
 **Git (opcional)** — se o agente puder correr terminal **ou** o utilizador colar saída, preferir recolher:
 
@@ -32,8 +33,9 @@ Não reescrever `SPEC.md` nem apagar `PLAN.md`; apenas **recomendar** o reingres
 2. Recolher evidência: STATE, VERIFY, PLAN, SPEC, QUICK (trechos relevantes), saída de **doctor** se disponível, e **Git (opcional)** conforme bloco no context (se indisponível, seguir sem Git). Se `OXE-EVENTS.ndjson` existir no escopo resolvido, correr `npx oxe-cc runtime replay --write` para gerar **`REPLAY-SESSION.md`** — timeline completa da execução com deltas entre eventos; incluir achados relevantes na seção **Linha do tempo** do `FORENSICS.md`.
 3. Redigir **`FORENSICS.md`** no escopo resolvido com secções fixas:
    - **Data** (ISO) e **Sintoma** (1–3 frases).
-   - **Linha do tempo** — bullets curtos (o que se tentou, ordem aproximada); **incorporar** commits/datas e ficheiros mais tocados quando houver evidência Git; se Git não foi avaliado, linha explícita: *Git não avaliado (ambiente/indisponível)*.
-   - **Hipótese de causa** — uma ou duas hipóteses ranqueadas (ex.: plano desalinhado, mapa desatualizado, workflows em falta, implementação incompleta); usar padrões Git (ficheiros repetidos, working tree suja) quando útil.
+   - **Linha do tempo** — bullets curtos (o que se tentou, ordem aproximada); **incorporar** commits/datas e ficheiros mais tocados quando houver evidência Git; se Git não foi avaliado, linha explícita: *Git não avaliado (ambiente/indisponível)*.
+   - **Divergências de consistência** — diferenças entre `ACTIVE-RUN.json`, run file, eventos, gates, policy decisions, VERIFY e STATE quando existirem.
+   - **Hipótese de causa** — uma ou duas hipóteses ranqueadas (ex.: plano desalinhado, mapa desatualizado, workflows em falta, implementação incompleta); usar padrões Git (ficheiros repetidos, working tree suja) quando útil.
    - **Próximo passo OXE recomendado:** **um único** valor entre `scan` | `plan` | `execute` e o **comando** correspondente (`/oxe-scan`, `/oxe-plan`, `/oxe-execute` ou `npx oxe-cc@latest` / `npx oxe-cc doctor` quando a causa for tooling).
    - **Justificativa** — uma frase que liga evidência ao passo escolhido.
 4. Atualizar **`.oxe/STATE.md`** global com uma linha opcional sob decisões ou contexto: referência a `FORENSICS.md` e fase sugerida (ex.: `forensics_complete` → próximo conforme passo recomendado).

package/oxe/workflows/milestone.md

@@ -10,10 +10,10 @@ Subcomandos:
 - `/oxe-milestone audit` — verificar se o milestone atingiu sua definição de pronto.
 </objective>
 
-<context>
-- Milestone ≠ Checkpoint. **Checkpoint** (`/oxe-checkpoint`) é um snapshot de sessão — restaurável a qualquer momento. **Milestone** é uma entrega — marcador de versão com artefatos arquivados e critérios de pronto validados.
-- Nesta versão, milestones são **globais**: usar `.oxe/global/MILESTONES.md` e `.oxe/global/milestones/`, ignorando `active_session` para escrita do índice global.
-- Milestones são rastreados em **`.oxe/global/MILESTONES.md`** (índice) e cada entrega tem uma entrada com status, data e links aos artefatos.
+<context>
+- Milestone ≠ Checkpoint. **Checkpoint** (`/oxe-checkpoint`) é um snapshot de sessão — restaurável a qualquer momento. **Milestone** é uma entrega — marcador de versão com artefatos arquivados e critérios de pronto validados.
+- Nesta versão, milestones são **globais**: usar `.oxe/global/MILESTONES.md` e `.oxe/global/milestones/`, ignorando `active_session` para escrita do índice global.
+- Milestones são rastreados em **`.oxe/global/MILESTONES.md`** (índice) e cada entrega tem uma entrada com status, data e links aos artefatos.
 - O milestone ativo é registrado no **STATE.md** na seção **Milestone ativo**.
 - Um milestone é considerado **pronto** quando:
   1. Todos os critérios A* da SPEC estão com `verify_complete` no STATE.
@@ -27,7 +27,7 @@ Subcomandos:
 
 1. Verificar se há milestone ativo em STATE.md. Se houver, alertar e pedir confirmação antes de criar novo.
 2. Gerar ID sequencial: **M-01**, **M-02**, …
-3. Criar entrada em **`.oxe/global/MILESTONES.md`**:
+3. Criar entrada em **`.oxe/global/MILESTONES.md`**:
    ```markdown
    ## M-01 — [nome] (ativo)
    - **Status:** ativo
@@ -51,11 +51,11 @@ Pré-requisitos (verificar antes de executar):
 Se pré-requisitos não forem satisfeitos: listar os que faltam e pausar. Com `--force`: documentar pré-requisitos não satisfeitos e continuar com aviso.
 
 Passos:
-1. Arquivar artefatos do milestone:
-   - Copiar os artefatos do escopo ativo da sessão, se houver, para `.oxe/global/milestones/M-NN/`
-   - Sem sessão ativa, copiar da raiz `.oxe/`
-   - Criar `.oxe/global/milestones/M-NN/MILESTONE.md` com resumo da entrega.
-2. Atualizar **`.oxe/global/MILESTONES.md`**: marcar milestone como `entregue`, adicionar data de encerramento e links aos artefatos arquivados.
+1. Arquivar artefatos do milestone:
+   - Copiar os artefatos do escopo ativo da sessão, se houver, para `.oxe/global/milestones/M-NN/`
+   - Sem sessão ativa, copiar da raiz `.oxe/`
+   - Criar `.oxe/global/milestones/M-NN/MILESTONE.md` com resumo da entrega.
+2. Atualizar **`.oxe/global/MILESTONES.md`**: marcar milestone como `entregue`, adicionar data de encerramento e links aos artefatos arquivados.
 3. Atualizar **STATE.md**: limpar seção **Milestone ativo**, registrar **Último milestone** com ID e data.
 4. Sugerir próximo milestone ou nova spec: `Milestone M-NN concluído. Próximos passos: /oxe-milestone new v2 | /oxe-spec | /oxe-checkpoint`.
 </process_complete>
@@ -64,7 +64,7 @@ Passos:
 **`/oxe-milestone status`**
 
 1. Ler STATE.md para identificar milestone ativo (ID e nome).
-2. Ler `.oxe/global/MILESTONES.md` para detalhes.
+2. Ler `.oxe/global/MILESTONES.md` para detalhes.
 3. Ler SPEC.md para listar critérios A* e seu status (verificado / pendente).
 4. Ler VERIFY.md (se existir) para gaps abertos.
 5. Exibir no chat:
@@ -88,7 +88,7 @@ Resultado: `Milestone M-NN: PRONTO` ou lista de itens pendentes.
 </process_audit>
 
 <success_criteria>
-- [ ] `.oxe/global/MILESTONES.md` existe e tem entrada para o milestone ativo.
+- [ ] `.oxe/global/MILESTONES.md` existe e tem entrada para o milestone ativo.
 - [ ] STATE.md indica milestone ativo (ID e nome).
 - [ ] Ao completar: artefatos arquivados em `.oxe/milestones/M-NN/`.
 - [ ] Ao completar: MILESTONES.md atualizado com status `entregue` e data.

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** 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.
+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`.