oxe-cc 0.6.5 → 0.7.0

package/oxe/templates/config.template.json

@@ -2,8 +2,9 @@
   "_comment": "OXE config — copie para .oxe/config.json no seu projeto. Remova esta linha.",
   "profile": "balanced",
   "discuss_before_plan": false,
-  "verification_depth": "standard",
-  "security_in_verify": false,
+  "verification_depth": "standard",
+  "plan_confidence_threshold": 70,
+  "security_in_verify": false,
   "after_verify_suggest_pr": true,
   "after_verify_draft_commit": true,
   "after_verify_suggest_uat": false,
@@ -15,9 +16,17 @@
   "scan_focus_globs": [],
   "scan_ignore_globs": [],
   "spec_required_sections": [],
-  "plan_max_tasks_per_wave": 0,
-  "install": {
-    "profile": "recommended",
+  "plan_max_tasks_per_wave": 0,
+  "azure": {
+    "enabled": false,
+    "default_resource_group": "",
+    "preferred_locations": [],
+    "inventory_max_age_hours": 24,
+    "resource_graph_auto_install": true,
+    "vpn_required": false
+  },
+  "install": {
+    "profile": "recommended",
     "repo_layout": "nested",
     "vscode": false,
     "include_commands_dir": true,

package/oxe/workflows/ask.md

@@ -0,0 +1,71 @@
+# OXE — Workflow: ask
+
+<objective>
+Responder perguntas sobre a situação atual do trabalho OXE com máxima robustez, usando o contexto real do repositório, a sessão ativa quando existir, e os artefatos mais recentes da trilha.
+</objective>
+
+<context>
+- Resolver `active_session` via `oxe/workflows/references/session-path-resolution.md`.
+- Ler sempre `.oxe/STATE.md` global primeiro.
+- Com sessão ativa, priorizar artefatos em `.oxe/<active_session>/...` antes do modo legado.
+- Usar `.oxe/codebase/` como mapa do repositório, não como substituto dos artefatos da trilha.
+- Se a pergunta estiver ambígua, responder em modo “situação atual + próximos riscos + melhor próxima ação”.
+- Aplicar discovery adaptativo leve: classificar se a pergunta é sobre estado atual, bloqueio, estratégia, execução, verificação, instalação ou investigação antes de decidir o conjunto de artefatos prioritários.
+</context>
+
+<process>
+1. Ler `.oxe/STATE.md` global e determinar se há `active_session`.
+2. Se houver sessão ativa, ler nesta ordem:
+   - `SESSION.md`
+   - `spec/SPEC.md`, `spec/ROADMAP.md`, `spec/DISCUSS.md`, `spec/UI-SPEC.md` se existirem
+   - `plan/PLAN.md`, `plan/QUICK.md`, `plan/plan-agents.json`, `plan/quick-agents.json` se existirem
+   - `execution/STATE.md`, `execution/EXECUTION-RUNTIME.md`, `execution/CHECKPOINTS.md`, `execution/OBSERVATIONS.md`, `execution/DEBUG.md`, `execution/FORENSICS.md`, `execution/SUMMARY.md` se existirem
+   - `research/INVESTIGATIONS.md`, `research/RESEARCH.md`, `research/investigations/` se existirem
+   - `verification/VERIFY.md`, `verification/VALIDATION-GAPS.md`, `verification/SECURITY.md`, `verification/UI-REVIEW.md` se existirem
+3. Sem sessão ativa, ler o equivalente legado na raiz `.oxe/`.
+4. Em ambos os casos, ler também:
+   - `.oxe/codebase/OVERVIEW.md`
+   - `.oxe/codebase/STACK.md`
+   - `.oxe/codebase/CONCERNS.md`
+   - `.oxe/CAPABILITIES.md` e `.oxe/capabilities/` se a pergunta tocar execução, pesquisa, automação ou integrações
+   - `.oxe/INVESTIGATIONS.md` se a pergunta tocar incertezas, descoberta ou evidência
+   - `.oxe/memory/` se existir memória persistente relevante ao assunto
+   - `.oxe/global/LESSONS.md` se existir, com fallback para `.oxe/LESSONS.md`
+   - `.oxe/SESSIONS.md` se a pergunta mencionar sessões, histórico ou retomada
+   - `.oxe/cloud/azure/INVENTORY.md`, `SERVICEBUS.md`, `EVENTGRID.md`, `SQL.md` e `auth-status.json` se a pergunta tocar Azure, cloud, infraestrutura, mensageria, integração ou banco gerido
+5. Responder à pergunta do utilizador com base em evidência explícita dos artefatos lidos.
+6. Se faltar artefato crítico para responder com segurança, dizer exatamente o que falta e qual comando OXE fecha essa lacuna.
+
+## Modo diagnóstico padrão
+
+Se o utilizador só disser algo genérico como “o que está acontecendo?”, “qual a situação?” ou “me contextualize”, responder com:
+
+- **Situação atual**
+- **Escopo ativo**
+- **Artefatos relevantes**
+- **Riscos ou lacunas**
+- **Próximo passo recomendado**
+
+## Regras de robustez
+
+- Não assumir que `doctor` ou `status` sejam session-aware; eles não substituem a leitura direta dos artefatos da sessão.
+- Se houver conflito entre `.oxe/STATE.md` global e `execution/STATE.md` da sessão, explicitar o conflito.
+- Se houver `CHECKPOINTS.md` com itens `pending_approval`, isso tem precedência operacional sobre o “próximo passo” implícito.
+- Se `EXECUTION-RUNTIME.md` ou `INVESTIGATIONS.md` existirem, tratá-los como evidência tática complementar para explicar bloqueios, handoffs, riscos e lacunas.
+- Se `VERIFY.md` existir e contradizer o estado declarado, priorizar a evidência do `VERIFY.md` e mencionar a incoerência.
+- Se existir inventário Azure materializado, priorizar esse inventário sobre suposições sobre recursos cloud.
+- Se o mapa `.oxe/codebase/` estiver ausente ou incompleto, dizer isso explicitamente antes de extrapolar sobre o repositório.
+</process>
+
+<output>
+- Resposta direta à pergunta do utilizador
+- Referência curta aos artefatos usados
+- Quando necessário, um único próximo passo OXE
+</output>
+
+<success_criteria>
+- [ ] A resposta parte de `.oxe/STATE.md` global e resolve corretamente a sessão ativa quando existir.
+- [ ] O contexto da sessão ativa tem precedência sobre artefatos legados.
+- [ ] Conflitos ou lacunas entre artefatos são explicitados.
+- [ ] A saída responde à pergunta sem inventar estado que não esteja nos arquivos.
+</success_criteria>

package/oxe/workflows/capabilities.md

@@ -0,0 +1,23 @@
+# OXE — Workflow: capabilities
+
+<objective>
+Gerir capabilities nativas do OXE: listar, explicar, instalar, remover e diagnosticar extensões opcionais em `.oxe/capabilities/`.
+</objective>
+
+<context>
+- Capabilities são extensões do projeto, não substituem o núcleo do OXE.
+- Cada capability vive em `.oxe/capabilities/<id>/` com manifesto próprio.
+- O índice canónico é `.oxe/CAPABILITIES.md`.
+</context>
+
+<process>
+1. Ler `.oxe/CAPABILITIES.md` e os manifestos em `.oxe/capabilities/` se existirem.
+2. Se o pedido for `list` ou genérico, responder com capabilities instaladas, escopo e riscos.
+3. Se o pedido for instalar ou remover, orientar o utilizador a usar `oxe-cc capabilities ...` ou o workflow equivalente aprovado pelo projeto.
+4. Se o pedido for diagnóstico, apontar drift entre índice, manifestos e artefatos esperados.
+</process>
+
+<success_criteria>
+- [ ] O estado do catálogo foi lido a partir dos artefatos reais.
+- [ ] A resposta deixa claro o que é capability nativa e o que é núcleo do OXE.
+</success_criteria>

package/oxe/workflows/dashboard.md

@@ -0,0 +1,23 @@
+# 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>
+- 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, blueprint de agentes e `VERIFY.md` quando existirem.
+2. Consolidar: fase, onda atual, agentes, checkpoints, bloqueios e evidências.
+3. Gerar artefato visual local ou estado preparado para renderização.
+4. Se faltar runtime operacional, explicar a lacuna antes de tentar visualizar.
+</process>
+
+<success_criteria>
+- [ ] A dashboard usa somente artefatos OXE como entrada.
+- [ ] Conflitos entre artefatos são explicitados.
+</success_criteria>

package/oxe/workflows/discuss.md

@@ -6,12 +6,14 @@ 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>
-- 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 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.
-- Se existir **`.oxe/NOTES.md`**, rever bullets em aberto: promover para perguntas/decisões em `DISCUSS.md` ou marcar como *descartado* / *adiado* com uma linha de justificativa.
+<context>
+- 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.
+- Se existir **`.oxe/NOTES.md`**, rever bullets em aberto: promover para perguntas/decisões em `DISCUSS.md` ou marcar como *descartado* / *adiado* com uma linha de justificativa. Se não existir e houver necessidade, criar a partir de `oxe/templates/NOTES.template.md`.
 - Se `.oxe/config.json` existir e `discuss_before_plan` for `true`, tratar este passo como **recomendado** antes de `oxe:plan`.
+- Usar `oxe/templates/DISCUSS.template.md` para criar o arquivo se ainda não existir.
 </context>
 
 <decision_ids>
@@ -26,16 +28,16 @@ Regras:
 </decision_ids>
 
 <process>
-1. Se não existir `SPEC.md` no escopo resolvido, pedir **spec** primeiro (ou **quick** se for trabalho trivial).
+1. Se não existir `SPEC.md` no escopo resolvido, pedir **spec** primeiro (ou **quick** se for trabalho trivial).
 2. Se existir **`.oxe/NOTES.md`**, rever bullets em aberto e decidir o que entra em **Perguntas** ou **Decisões** (ou marcar *descartado* / *adiado* com justificativa curta).
 3. Identificar **lacunas** (escopo, dados, UX, edge cases, compatibilidade) — no máximo **7** perguntas objetivas.
-4. Criar ou atualizar **`DISCUSS.md`** no escopo resolvido com estrutura fixa:
+4. Criar ou atualizar **`DISCUSS.md`** no escopo resolvido com estrutura fixa:
    - **Contexto** — 2–4 bullets do que já se sabe da SPEC.
    - **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`).
+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, listando decisões com seus IDs.
 </process>
 
@@ -70,7 +72,7 @@ updated: YYYY-MM-DD
 </discuss_md_format>
 
 <success_criteria>
-- [ ] `DISCUSS.md` existe no escopo correto com perguntas e decisões alinhadas à SPEC.
+- [ ] `DISCUSS.md` existe no escopo correto com perguntas e decisões alinhadas à SPEC.
 - [ ] Cada decisão fechada tem ID único **D-NN** na tabela de Decisões.
 - [ ] Se existir `.oxe/NOTES.md`, as entradas relevantes foram tratadas (promovidas, descartadas ou adiadas com nota).
 - [ ] Nenhuma ambiguidade crítica ficou sem registro (como pendente ou suposição explícita na SPEC).

package/oxe/workflows/execute.md

@@ -3,13 +3,13 @@
 <objective>
 Guiar a **implementação** de um plano OXE com dois modos possíveis:
 
-**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 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.
+**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.
 
 **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).
+Se existir apenas **`QUICK.md`** no escopo resolvido: tratar passos numerados como onda única (modo sempre Completo).
 </objective>
 
 <modo_solo>
@@ -90,9 +90,24 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 </failure_mode>
 
 <context>
-**Observações pendentes:** verificar `OBSERVATIONS.md` do escopo resolvido no início de cada onda. Se houver entradas `pendente` com impacto `execute` ou `all`, incorporar no trabalho da onda atual e marcá-las `incorporada → execute (data)`.
+**Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de executar, validar os artefatos obrigatórios e o gate do plano.
 
-**Quick-agents (lean PDDA):** se existir **`quick-agents.json`** do escopo resolvido com `status: active` e a execução for baseada em **`QUICK.md`** (não há PLAN.md), adotar o `role` e `persona` de cada agente para os `steps[]` atribuídos. Ao concluir todos os steps, marcar `quick-agents.json` → `status: done` e sugerir `/oxe-verify`.
+**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.
+
+**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.
+
+**Provider Azure:** quando a tarefa tocar Azure, usar os artefatos em `.oxe/cloud/azure/` como contexto real e tratar `oxe-cc azure ...` como capability operacional nativa. Operações `plan` e `apply` devem entrar no runtime, abrir checkpoint antes de mutação e registrar evidência em `.oxe/cloud/azure/operations/`.
+
+**Observações pendentes:** verificar `OBSERVATIONS.md` do escopo resolvido no início de cada onda. Processar por severidade antes de executar qualquer tarefa:
+- **`Severidade: blocking`** — não avançar para nenhuma tarefa da onda sem resolver. Apresentar o bloqueio ao usuário com contexto da onda atual e as opções A/B/C (ver `obs.md` passo 5). A onda só avança após o usuário escolher e o bloqueio ser tratado.
+- **`Severidade: adjustment`** — incorporar como restrição nas tarefas afetadas desta onda antes de executar; não bloqueia o avanço.
+- **`Severidade: info`** (ou sem campo Severidade — formato legado) — incorporar normalmente se impacto `execute` ou `all`.
+
+Após incorporar: marcar `incorporada → execute (data)` em `OBSERVATIONS.md`.
+
+**Quick-agents (lean PDDA):** se existir **`quick-agents.json`** do escopo resolvido com `status: active` e a execução for baseada em **`QUICK.md`** (não há PLAN.md), adotar o `role` e `persona` de cada agente para os `steps[]` atribuídos. Ao concluir todos os steps, marcar `quick-agents.json` → `status: done` e sugerir `/oxe-verify`.
 
 **Model hints (blueprint com agentes):** ao apresentar a atribuição de cada agente no início da onda, exibir `model_hint` se presente:
 ```
@@ -101,7 +116,7 @@ Tarefas: T1, T2
 ```
 Se `model_hint` estiver ausente, não exibir a linha. O usuário pode configurar o modelo no IDE antes de iniciar aquele agente.
 
-**Blueprint plan-agent (Modo com Agentes):** adotar `role`/`scope` de **`plan-agents.json`** do escopo resolvido SOMENTE quando:
+**Blueprint plan-agent (Modo com Agentes):** adotar `role`/`scope` de **`plan-agents.json`** do escopo resolvido SOMENTE quando:
 1. `lifecycle.status` ∈ `{ pending_execute, executing }` (não usar se `closed` ou `invalidated`).
 2. **`runId`** no JSON coincide com **`run_id`** no STATE.md (secção Blueprint de agentes).
 3. O pedido mapeia para pelo menos uma tarefa **`Tn`** no **`PLAN.md`**.
@@ -110,7 +125,7 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 
 **Transição `pending_execute` → `executing`:** na primeira onda com blueprint válido, atualizar `plan-agents.json` → `lifecycle: { "status": "executing", "since": "<ISO>" }` e espelhar em STATE.md.
 
-**Protocolo agente → agente (blueprint):** mensagens em `plan-agent-messages/` do escopo resolvido conforme `oxe/workflows/references/plan-agent-chat-protocol.md`.
+**Protocolo agente → agente (blueprint):** mensagens em `plan-agent-messages/` do escopo resolvido conforme `oxe/workflows/references/plan-agent-chat-protocol.md`.
 
 **Se PLAN.md não existir mas QUICK.md existir:** seguir QUICK.md — passos = onda única, sempre Modo Completo.
 
@@ -122,24 +137,38 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 </context>
 
 <process>
-1. Ler **`.oxe/STATE.md`** global para resolver `active_session`, depois ler **`PLAN.md`** (se existir) e **`QUICK.md`** do escopo resolvido.
-2. Verificar **`OBSERVATIONS.md`** do escopo resolvido — incorporar pendentes de impacto `execute` ou `all` antes de iniciar.
-3. **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.
-4. 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.
-5. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
-6. **Implementar** conforme o modo escolhido:
+1. Ler **`.oxe/STATE.md`** global para resolver `active_session`, depois ler **`PLAN.md`** (se existir) e **`QUICK.md`** do escopo resolvido.
+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.
+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
+   - Se houver obs sem campo Severidade (formato legado) ou `Severidade: info` com impacto `execute` ou `all`: incorporar normalmente
+   - Após incorporar: marcar `incorporada → execute (data)` em `OBSERVATIONS.md`
+5. **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.
+6. 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.
+7. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
+8. **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.
    - **Modo Por tarefa:** executar próxima tarefa pendente, parar.
-7. Após cada onda concluída, incluir checklist:
+   - Em qualquer modo: atualizar `EXECUTION-RUNTIME.md` a cada mudança de onda, bloqueio, retry, handoff ou checkpoint.
+9. Após cada onda concluída, incluir checklist:
    ```markdown
    ## Checklist — Onda N (OXE)
    - [ ] Pré-requisitos da onda conferidos (dependências Tk atendidas)
    - [ ] Implementação da onda concluída
    - [ ] Comando Verificar de cada tarefa executado (ou agendado)
    ```
-8. Atualizar **`.oxe/STATE.md`** global com progresso resumido e, com sessão ativa, escrever o detalhe operacional em `execution/STATE.md`.
-9. Marcar OBS incorporadas como `incorporada → execute (data)` em `OBSERVATIONS.md` do escopo resolvido.
+10. Atualizar **`.oxe/STATE.md`** global com progresso resumido e, com sessão ativa, escrever o detalhe operacional em `execution/STATE.md`.
+11. 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`).
+12. Marcar OBS incorporadas como `incorporada → execute (data)` em `OBSERVATIONS.md` do escopo resolvido.
 </process>
 
 <success_criteria>
@@ -148,7 +177,7 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 - [ ] 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 de impacto `execute` incorporadas no início da onda.
+- [ ] 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.
 </success_criteria>