oxe-cc 1.0.0 → 1.3.0

package/oxe/workflows/checkpoint.md

@@ -1,7 +1,11 @@
 # OXE — Workflow: checkpoint
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-execute`.
+> Use: `/oxe-execute --checkpoint "<nome>"` para criar snapshot nomeado da sessão.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
-Criar um **marco nomeado em disco** em `checkpoints/YYYY-MM-DD-HHmm-<slug>.md` do escopo resolvido e atualizar `CHECKPOINTS.md` correspondente (índice): **snapshot da sessão / trilha corrente** para pausar e retomar sem apagar SPEC/PLAN.
+Criar um **marco nomeado em disco** em `checkpoints/YYYY-MM-DD-HHmm-<slug>.md` do escopo resolvido e atualizar `CHECKPOINTS.md` correspondente (índice): **snapshot da sessão / trilha corrente** para pausar e retomar sem apagar SPEC/PLAN.
 
 **Não** duplica o papel de `git commit` nem de `verify`; é **registo explícito** para humanos e agentes. Para **atualizar o mapa do projeto inteiro** e alinhar `.oxe/codebase/` ao código, usar **`compact.md`** (`/oxe-compact`), não este passo.
 </objective>
@@ -9,25 +13,25 @@ Criar um **marco nomeado em disco** em `checkpoints/YYYY-MM-DD-HHmm-<slug>.md` d
 <context>
 - **Checkpoint vs compact** e **momentos chave** da rotina: tabelas canónicas em **`help.md`** (secções *Checkpoint vs compact* e *Momentos chave*) — evitar divergência; este ficheiro descreve só a execução do checkpoint.
 
-- Entrada: texto do utilizador = **slug** e/ou **nota** (ex.: `antes-refactor-auth` + “estado estável, falta T4”).
-- Nome do ficheiro: **`YYYY-MM-DD-HHmm-<slug-kebab>.md`** (hora 24h local ou UTC — documentar na nota se misturar fusos).
-- Frontmatter YAML no checkpoint (ver `oxe/templates/CHECKPOINT.template.md`): `created`, `slug`, `linked` (lista de paths relativos à raiz do repo, tipicamente `.oxe/STATE.md`, `.oxe/SPEC.md`, …).
-- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, checkpoints vivem em `.oxe/<active_session>/checkpoints/`; sem sessão ativa, usar `.oxe/checkpoints/`.
-- **Índice** `CHECKPOINTS.md` do mesmo escopo: tabela **mais recente primeiro** com colunas **Data** | **Ficheiro** | **Slug** | **Nota (1 linha)**.
+- Entrada: texto do utilizador = **slug** e/ou **nota** (ex.: `antes-refactor-auth` + “estado estável, falta T4”).
+- Nome do ficheiro: **`YYYY-MM-DD-HHmm-<slug-kebab>.md`** (hora 24h local ou UTC — documentar na nota se misturar fusos).
+- Frontmatter YAML no checkpoint (ver `oxe/templates/CHECKPOINT.template.md`): `created`, `slug`, `linked` (lista de paths relativos à raiz do repo, tipicamente `.oxe/STATE.md`, `.oxe/SPEC.md`, …).
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, checkpoints vivem em `.oxe/<active_session>/checkpoints/`; sem sessão ativa, usar `.oxe/checkpoints/`.
+- **Índice** `CHECKPOINTS.md` do mesmo escopo: tabela **mais recente primeiro** com colunas **Data** | **Ficheiro** | **Slug** | **Nota (1 linha)**.
 - Não mover nem apagar artefactos canónicos; o checkpoint é **documento adicional**.
 </context>
 
 <process>
-1. Garantir pasta `checkpoints/` do escopo resolvido.
+1. Garantir pasta `checkpoints/` do escopo resolvido.
 2. Normalizar slug a partir dos argumentos do utilizador (kebab-case, ASCII; se vazio, usar `checkpoint`).
 3. Escolher nome único; se colisão, acrescentar sufixo `-b`, `-c`, …
 4. Escrever o ficheiro de checkpoint a partir do template: preencher frontmatter `linked` com os `.oxe/*.md` relevantes que **existem**; corpo com nota do utilizador e **snapshot** (trecho de STATE, uma linha de objetivo SPEC, resumo PLAN).
-5. Se `CHECKPOINTS.md` do escopo resolvido não existir, criar com título `# OXE — Índice de checkpoints` e tabela com cabeçalho; senão, **inserir linha no topo** da tabela.
+5. Se `CHECKPOINTS.md` do escopo resolvido não existir, criar com título `# OXE — Índice de checkpoints` e tabela com cabeçalho; senão, **inserir linha no topo** da tabela.
 6. Responder no chat: caminho do ficheiro novo + como usar na retomada (ler checkpoint + `linked` + próximo `oxe:*`).
 </process>
 
 <success_criteria>
-- [ ] Novo ficheiro em `checkpoints/` do escopo correto com frontmatter e corpo úteis.
-- [ ] `CHECKPOINTS.md` do mesmo escopo atualizado com entrada correspondente.
+- [ ] Novo ficheiro em `checkpoints/` do escopo correto com frontmatter e corpo úteis.
+- [ ] `CHECKPOINTS.md` do mesmo escopo atualizado com entrada correspondente.
 - [ ] SPEC/PLAN/VERIFY intocados salvo o utilizador pedir outra coisa explicitamente.
 </success_criteria>

package/oxe/workflows/dashboard.md

@@ -1,33 +1,33 @@
-# OXE — Workflow: dashboard
-
-<objective>
-Gerar ou atualizar uma camada visual opcional para acompanhar execução, agentes, ondas, checkpoints e verify, usando apenas artefatos OXE como fonte de verdade.
-</objective>
-
-<context>
-- Aplicar `oxe/workflows/references/reasoning-status.md`. A dashboard deve sintetizar estado e recomendação sem inventar progresso.
-- A visualização é opcional e não substitui `.oxe/STATE.md`, `PLAN.md`, runtime operacional nem `VERIFY.md`.
-- A dashboard deve refletir o estado atual, nunca inventar progresso.
-- Quando criar `PLAN-REVIEW.md`, usar `oxe/templates/PLAN-REVIEW.template.md` como estrutura inicial.
-</context>
-
-<process>
-1. Ler `.oxe/STATE.md`, runtime operacional (`ACTIVE-RUN.json`, `OXE-EVENTS.ndjson`), blueprint de agentes e `VERIFY.md` quando existirem.
-2. Consolidar: fase, onda atual, agentes, checkpoints, bloqueios e evidências.
-3. Gerar ou atualizar o artefato de saída:
-   - **Dashboard inline (padrão):** resumo em texto/Markdown no chat com a visão atual.
-   - **`PLAN-REVIEW.md` (revisão de equipe):** quando o utilizador pedir revisão colaborativa, escrever em **`.oxe/PLAN-REVIEW.md`** usando `oxe/templates/PLAN-REVIEW.template.md` como estrutura inicial.
-   - **Dashboard visual (`oxe-cc dashboard`):** aponta para `localhost` — este workflow não inicia o servidor; orienta o utilizador a correr `npx oxe-cc dashboard`.
-4. Se faltar runtime operacional, explicar a lacuna antes de tentar visualizar.
-5. No resumo inline, manter a ordem:
-   - **Leitura atual**
-   - **Recomendação**
-   - **Motivo**
-   - **Confiança / lacuna**
-</process>
-
-<success_criteria>
-- [ ] A dashboard usa somente artefatos OXE como entrada.
-- [ ] Conflitos entre artefatos são explicitados.
-- [ ] O artefato de saída é identificado: inline (chat) ou `.oxe/PLAN-REVIEW.md` (em disco, se pedido).
-</success_criteria>
+# OXE — Workflow: dashboard
+
+<objective>
+Gerar ou atualizar uma camada visual opcional para acompanhar execução, agentes, ondas, checkpoints e verify, usando apenas artefatos OXE como fonte de verdade.
+</objective>
+
+<context>
+- Aplicar `oxe/workflows/references/reasoning-status.md`. A dashboard deve sintetizar estado e recomendação sem inventar progresso.
+- A visualização é opcional e não substitui `.oxe/STATE.md`, `PLAN.md`, runtime operacional nem `VERIFY.md`.
+- A dashboard deve refletir o estado atual, nunca inventar progresso.
+- Quando criar `PLAN-REVIEW.md`, usar `oxe/templates/PLAN-REVIEW.template.md` como estrutura inicial.
+</context>
+
+<process>
+1. Ler `.oxe/STATE.md`, runtime operacional (`ACTIVE-RUN.json`, `OXE-EVENTS.ndjson`), blueprint de agentes e `VERIFY.md` quando existirem.
+2. Consolidar: fase, onda atual, agentes, checkpoints, bloqueios e evidências.
+3. Gerar ou atualizar o artefato de saída:
+   - **Dashboard inline (padrão):** resumo em texto/Markdown no chat com a visão atual.
+   - **`PLAN-REVIEW.md` (revisão de equipe):** quando o utilizador pedir revisão colaborativa, escrever em **`.oxe/PLAN-REVIEW.md`** usando `oxe/templates/PLAN-REVIEW.template.md` como estrutura inicial.
+   - **Dashboard visual (`oxe-cc dashboard`):** aponta para `localhost` — este workflow não inicia o servidor; orienta o utilizador a correr `npx oxe-cc dashboard`.
+4. Se faltar runtime operacional, explicar a lacuna antes de tentar visualizar.
+5. No resumo inline, manter a ordem:
+   - **Leitura atual**
+   - **Recomendação**
+   - **Motivo**
+   - **Confiança / lacuna**
+</process>
+
+<success_criteria>
+- [ ] A dashboard usa somente artefatos OXE como entrada.
+- [ ] Conflitos entre artefatos são explicitados.
+- [ ] O artefato de saída é identificado: inline (chat) ou `.oxe/PLAN-REVIEW.md` (em disco, se pedido).
+</success_criteria>

package/oxe/workflows/debug.md

@@ -1,37 +1,41 @@
 # OXE — Workflow: debug
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-execute`.
+> Use: `/oxe-execute --debug` para ativar diagnóstico técnico explícito.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Orientar **investigação técnica** de um sintoma (teste a falhar, erro em runtime, flake, regressão) **durante** a execução de tarefas do `PLAN.md` ou passos do `QUICK.md`: ciclo **hipótese → experiência mínima → evidência → próximo passo**.
 
 Diferente de **`verify`**, que audita **aceite** contra SPEC/PLAN. Depois de estabilizar com debug, a trilha continua com **`execute`** e, no fecho, **`verify`**.
 </objective>
 
-<context>
-- Aplicar `oxe/workflows/references/reasoning-execution.md`. O debug deve partir de evidência real, testar hipóteses pequenas e fechar com próximo passo único.
-- 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.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-execution.md`. O debug deve partir de evidência real, testar hipóteses pequenas e fechar com próximo passo único.
+- 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.
 </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:
+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).
 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**
-   - **Hipótese principal**
-   - **Evidência atual**
-   - **Próximo passo**
-</process>
+4. Resumo no chat em ≤8 linhas, nesta ordem:
+   - **Contexto lido**
+   - **Hipótese principal**
+   - **Evidência atual**
+   - **Próximo passo**
+</process>
 
 <success_criteria>
-- [ ] `DEBUG.md` no escopo correto contém sessão datada com sintoma e **Próximo passo** explícito.
+- [ ] `DEBUG.md` no escopo correto contém sessão datada com sintoma e **Próximo passo** explícito.
 - [ ] Quando aplicável, a sessão referencia **Tn** do PLAN.
 - [ ] Não se confunde com verify: não se declara “entrega aprovada” só com debug.
 </success_criteria>

package/oxe/workflows/discuss.md

@@ -6,9 +6,9 @@ Esclarecer requisitos **antes** do plano: registrar perguntas, respostas e decis
 Usar quando: SPEC existe mas há ambiguidade, risco técnico, ou `discuss_before_plan: true` em `.oxe/config.json`.
 </objective>
 
-<context>
-- Aplicar `oxe/workflows/references/reasoning-discovery.md`. Antes de perguntar, explorar SPEC, STATE, codebase e notas para reduzir perguntas desnecessárias.
-- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, usar `.oxe/<active_session>/spec/` para `SPEC.md` e `DISCUSS.md`; sem sessão ativa, manter `.oxe/`.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-discovery.md`. Antes de perguntar, explorar SPEC, STATE, codebase e notas para reduzir perguntas desnecessárias.
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, usar `.oxe/<active_session>/spec/` para `SPEC.md` e `DISCUSS.md`; sem sessão ativa, manter `.oxe/`.
 - Ler `SPEC.md` do escopo resolvido, `.oxe/STATE.md` e trechos relevantes de `.oxe/codebase/OVERVIEW.md` / `STACK.md`.
 - Se a SPEC mencionar **Azure explicitamente** (Azure Service Bus, Azure Event Grid, Azure SQL, Azure CLI, ARM, subscription Azure): verificar `auth-status.json` e, se ativo, ler `.oxe/cloud/azure/INVENTORY.md` para contextualizar recursos existentes. Sugerir até 3 perguntas padrão quando o contexto for novo: (1) região/location preferida e resource group existente ou a criar; (2) tier/SKU necessário (ex.: Standard vs Premium para Service Bus); (3) se a operação exige VPN ou service principal dedicado. Referenciar recursos existentes no inventário pelo nome em vez de criar novos quando possível. **Nota:** SQL genérico (PostgreSQL, MySQL, SQL Server on-prem, SQLite) não aciona este bloco — somente quando a SPEC qualificar explicitamente com "Azure".
 - Se existir `OBSERVATIONS.md` do escopo resolvido com entradas `pendente` de impacto `spec`, `plan` ou `all`, carregá-las como contexto adicional para as perguntas e decisões; marcá-las `incorporada → discuss (data)` após uso.
@@ -37,15 +37,15 @@ Regras:
    - **Perguntas** — numeradas; para cada uma: resposta (se o usuário já respondeu na mensagem) ou `_(pendente)_`.
    - **Decisões** — tabela com colunas **ID** / **Decisão** / **Data** / **Impacto no plano** (só as já fechadas). Atribuir IDs **D-01**, **D-02**, … em sequência.
    - **Implicações para o plano** — bullets (ex.: "migrations necessárias", "feature flag").
-5. Se ainda houver perguntas **pendentes** críticas, listá-las no chat (máx. 7) e parar até resposta; depois atualizar DISCUSS.md.
-6. Atualizar **`.oxe/STATE.md`** global: fase `discuss_complete`, próximo passo `oxe:plan`. Registrar os IDs de decisão na seção **Decisões persistentes** do STATE (ex.: `D-01: escolheu JWT — 2025-01-15`).
-7. Resumo no chat em ≤8 linhas, nesta ordem:
-   - **Fatos**
-   - **Inferências**
-   - **Lacunas**
-   - **Próximo passo**
-   Listar decisões com seus IDs sempre que existirem.
-</process>
+5. Se ainda houver perguntas **pendentes** críticas, listá-las no chat (máx. 7) e parar até resposta; depois atualizar DISCUSS.md.
+6. Atualizar **`.oxe/STATE.md`** global: fase `discuss_complete`, próximo passo `oxe:plan`. Registrar os IDs de decisão na seção **Decisões persistentes** do STATE (ex.: `D-01: escolheu JWT — 2025-01-15`).
+7. Resumo no chat em ≤8 linhas, nesta ordem:
+   - **Fatos**
+   - **Inferências**
+   - **Lacunas**
+   - **Próximo passo**
+   Listar decisões com seus IDs sempre que existirem.
+</process>
 
 <discuss_md_format>
 ```markdown

package/oxe/workflows/execute.md

@@ -1,8 +1,36 @@
 # OXE — Workflow: execute
 
 <objective>
-Guiar a **implementação** de um plano OXE com dois modos possíveis:
+Guiar a **implementação** de um plano OXE com dois modos possíveis.
 
+**Flags suportadas:**
+- `--note "texto"` — registrar observação contextual em `OBSERVATIONS.md` antes de iniciar a execução (equivalente a `/oxe-obs`). Pode ser usado com qualquer outro argumento.
+- `--debug` — ativar diagnóstico técnico explícito ao primeiro sinal de falha em vez de esperar 2 tentativas (equivalente a `/oxe-debug`). Fornece stack trace detalhado, hipóteses e fix.
+- `--deep-diagnosis` — iniciar diretamente em modo de diagnóstico pós-falha persistente (equivalente a `/oxe-forensics`). Usar quando a execução já falhou repetidamente e o estado está corrompido ou inconsistente.
+- `--checkpoint "<nome>"` — criar snapshot nomeado do estado da sessão antes de iniciar ou após concluir (equivalente a `/oxe-checkpoint`). Útil antes de experimentos ou ondas arriscadas.
+- `--iterative` — ativar modo B com loop automático até verify passar, com retry controlado por `loop_max` (equivalente a `/oxe-loop`).
+
+**Nota de compatibilidade v1.1.0:** `/oxe-obs`, `/oxe-debug`, `/oxe-forensics`, `/oxe-checkpoint` e `/oxe-loop` foram incorporados por este comando. Esses comandos legados continuam funcionando mas exibem aviso de migração.
+
+</objective>
+
+<flags_processing>
+## Processamento de flags (executar antes do step 1)
+
+Ao receber qualquer argumento, verificar flags antes de iniciar o fluxo principal:
+
+1. **`--note "texto"`**: escrever entrada em `OBSERVATIONS.md` do escopo resolvido com status `pendente`, impacto `execute`, severidade `info`. Marcar como `incorporada → execute (data)` imediatamente após registrar. Continuar com o fluxo normal.
+
+2. **`--checkpoint "<nome>"`**: executar a lógica de `oxe/workflows/checkpoint.md` com o slug fornecido antes de iniciar a onda. Reportar confirmação do snapshot. Continuar.
+
+3. **`--deep-diagnosis`**: saltar diretamente para o fluxo de `oxe/workflows/forensics.md` com o contexto atual do `EXECUTION-RUNTIME.md` e `STATE.md`. Não iniciar nova onda sem resolução explícita.
+
+4. **`--debug`**: ajustar `<failure_mode>` para acionar diagnóstico imediato na primeira falha (sem 2 tentativas antes). Reportar hipóteses, evidências e fix com mais detalhe.
+
+5. **`--iterative`**: registrar em STATE.md: `execute_mode: por_onda` e `loop_max: 3` (ou o valor de config). Informar ao usuário que o modo iterativo está ativo.
+</flags_processing>
+
+<execution_modes>
 **Modo Solo (padrão):** seguir `PLAN.md` do escopo resolvido da sessão onda a onda sem `plan-agents.json`. O agente implementa diretamente cada tarefa Tn da onda atual, roda a verificação e avança. Não exige nenhum artefato além do PLAN.md.
 
 **Modo com Agentes (extensão):** quando existe `plan-agents.json` válido no escopo resolvido (schema 2+, lifecycle ativo, runId alinhado ao STATE), adotar roles e personas por agente conforme o blueprint.
@@ -10,7 +38,7 @@ Guiar a **implementação** de um plano OXE com dois modos possíveis:
 **Seleção de execução (redução de requisições):** quando o plano tem 2+ ondas, o usuário escolhe entre Completo (1 sessão), Por onda (N sessões) ou Por tarefa (N tarefas). A escolha é feita **uma vez** no início.
 
 Se existir apenas **`QUICK.md`** no escopo resolvido: tratar passos numerados como onda única (modo sempre Completo).
-</objective>
+</execution_modes>
 
 <modo_solo>
 ## Modo Solo — Execução direta do PLAN.md
@@ -98,6 +126,12 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 
 **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.
 
+**Runtime enterprise como caminho padrão:** quando `oxe-cc runtime` estiver disponível no ambiente, preferir o caminho formal deste passo:
+- executar `oxe-cc runtime compile --dir <projeto>` antes da primeira mutação para materializar `compiled_graph`, `canonical_state` e `verification_suite`;
+- tratar `ACTIVE-RUN.json` e `.oxe/runs/<run_id>.json` como fonte operacional primária da onda/tarefa atual;
+- executar `oxe-cc runtime project --dir <projeto>` ao fim de cada onda ou bloco concluído para reprojetar `PLAN.md`, `STATE.md`, `VERIFY.md`, `RUN-SUMMARY.md`, `COMMIT-SUMMARY.md` e `PROMOTION-SUMMARY.md`.
+Se o runtime não estiver compilado, falhar por indisponibilidade do pacote ou não puder ser executado no ambiente atual, declarar `fallback legado` explicitamente antes de seguir apenas com os artefatos markdown.
+
 **Checkpoints de aprovação:** usar `CHECKPOINTS.md` do escopo resolvido para gates humanos explícitos. Estados válidos: `pending_approval`, `approved`, `rejected`, `overridden`. Se houver checkpoint pendente antes de uma onda de risco, side effect externo ou fecho sensível, a execução deve pausar até resolução explícita.
 
 **Capabilities nativas:** ler `.oxe/CAPABILITIES.md` e capabilities locais relevantes antes de propor automações, pesquisa extra, publicação ou conectores. Só sugerir capabilities que existam no projeto ou estejam claramente ausentes.
@@ -156,6 +190,11 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 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;
+   - se existir gate operacional além dos checkpoints markdown, consultar `oxe-cc runtime gates list --dir <projeto>` antes da onda de mutação;
+   - se falhar apenas por indisponibilidade do runtime, registrar `fallback legado` e continuar com o fluxo markdown.
 4. Verificar **`OBSERVATIONS.md`** do escopo resolvido antes de iniciar cada onda:
    - Se houver obs com `Status: pendente` e `Severidade: blocking`: **não avançar** para nenhuma tarefa da onda — apresentar ao usuário o bloqueio com contexto da onda e opções A/B/C de resolução
    - Se houver obs com `Status: pendente` e `Severidade: adjustment`: incorporar como restrição nas tarefas afetadas desta onda antes de executar
@@ -187,7 +226,9 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
    - [ ] Implementação da onda concluída
    - [ ] Comando Verificar de cada tarefa executado (ou agendado)
    ```
+10a. Quando o runtime enterprise estiver ativo, executar ou solicitar `oxe-cc runtime project --dir <projeto>` após cada onda ou bloco concluído para projetar os markdowns derivados a partir do estado canónico, em vez de depender só de edição manual.
 11. Atualizar **`.oxe/STATE.md`** global com progresso resumido e, com sessão ativa, escrever o detalhe operacional em `execution/STATE.md`.
+11a. Se o runtime enterprise estiver ativo, preferir o `STATE.md`, `PLAN.md`, `VERIFY.md` e summaries projetados por `runtime project` como superfície oficial; complementar manualmente apenas o que o projection engine ainda não cobrir.
 12. Atualizar ou criar `CHECKPOINTS.md` quando surgir gate humano explícito; refletir o status resumido no `STATE.md` global (`checkpoint_status`) e no runtime (`runtime_status`).
 13. Marcar OBS incorporadas como `incorporada → execute (data)` em `OBSERVATIONS.md` do escopo resolvido.
 14. Se a execução parar por hipótese crítica não verificada, conflito estrutural ou falta de evidência operacional, terminar com bloqueio explícito e um único próximo passo. Se o bloqueio tiver vindo de pack stale/incompleto, dizer isso explicitamente.
@@ -202,4 +243,5 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 - [ ] 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

@@ -1,14 +1,18 @@
 # OXE — Workflow: forensics
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-execute`.
+> Use: `/oxe-execute --deep-diagnosis` para diagnóstico pós-falha persistente.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Diagnosticar **incidentes de fluxo** após falha ou incoerência entre artefatos `.oxe/`, Git e saída de `oxe-cc doctor`: produzir **`FORENSICS.md`** no escopo resolvido com linha do tempo, hipótese de causa e **exatamente um** próximo passo canónico OXE (`scan`, `plan` ou `execute` — incluindo ações como reinstalar workflows ou correr verify como parte do movimento **execute**).
 
 Não reescrever `SPEC.md` nem apagar `PLAN.md`; apenas **recomendar** o reingresso na trilha.
 </objective>
 
-<context>
-- Aplicar `oxe/workflows/references/reasoning-execution.md` para montar a linha do tempo e `oxe/workflows/references/reasoning-status.md` para devolver um único reingresso recomendado.
-- Usar quando: `VERIFY.md` com falhas ou gaps não explicados, `oxe-cc doctor` com **FALHA**, `STATE.md` contradiz ficheiros presentes (ex.: “onda concluída” sem `VERIFY.md`), ou o utilizador indica estar **preso** após várias tentativas de replan.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-execution.md` para montar a linha do tempo e `oxe/workflows/references/reasoning-status.md` para devolver um único reingresso recomendado.
+- Usar quando: `VERIFY.md` com falhas ou gaps não explicados, `oxe-cc doctor` com **FALHA**, `STATE.md` contradiz ficheiros presentes (ex.: “onda concluída” sem `VERIFY.md`), ou o utilizador indica estar **preso** após várias tentativas de replan.
 - 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.
@@ -33,12 +37,12 @@ Não reescrever `SPEC.md` nem apagar `PLAN.md`; apenas **recomendar** o reingres
    - **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).
-5. Responder no chat em ≤8 linhas, nesta ordem:
-   - **Leitura atual**
-   - **Hipótese de causa**
-   - **Próximo passo**
-   - **Motivo**
-</process>
+5. Responder no chat em ≤8 linhas, nesta ordem:
+   - **Leitura atual**
+   - **Hipótese de causa**
+   - **Próximo passo**
+   - **Motivo**
+</process>
 
 <success_criteria>
 - [ ] `FORENSICS.md` existe no escopo correto com **Próximo passo OXE recomendado** igual a **um** entre `scan`, `plan`, `execute`.