oxe-cc 1.2.1 → 1.3.0

package/oxe/workflows/ask.md

@@ -1,96 +1,96 @@
-# OXE — Workflow: ask
-
-> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe`.
-> Use: `/oxe "sua pergunta"` ou simplesmente `/oxe` para o próximo passo.
-> Este alias continuará funcionando nesta versão por compatibilidade.
-
-<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>
-- Aplicar `oxe/workflows/references/reasoning-discovery.md` como postura cognitiva deste passo.
-- Resolver `active_session` via `oxe/workflows/references/session-path-resolution.md`.
-- Ler sempre `.oxe/STATE.md` global primeiro.
-- Antes de abrir o conjunto amplo de artefatos, tentar o contexto resolvido em `.oxe/context/packs/ask.md` e `.oxe/context/packs/ask.json` como entrada prioritária.
-- Se o pack existir e estiver fresco/coerente, ler primeiro o resumo do pack e depois inspecionar apenas os artefatos listados em `read_order` / `selected_artifacts` antes de expandir a leitura.
-- Se o pack estiver ausente, stale ou com lacunas críticas, fazer fallback explícito para leitura direta e declarar esse fallback na resposta.
-- 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. Resolver o contexto estruturado primeiro:
-   - tentar `.oxe/context/packs/ask.md` / `.oxe/context/packs/ask.json` (ou `oxe-cc context inspect --workflow ask --json`) para obter `read_order`, `selected_artifacts`, `gaps`, `conflicts` e `freshness`;
-   - se o pack estiver fresco e sem lacunas críticas, usá-lo como mapa primário de leitura;
-   - se o pack estiver stale, incompleto ou ausente, declarar `fallback para leitura direta` antes de abrir os artefatos brutos.
-3. Se houver pack válido, ler primeiro:
-   - o resumo humano do pack (`.md`);
-   - os artefatos de `read_order`;
-   - quaisquer artefatos adicionais de `selected_artifacts` necessários para responder com evidência.
-4. Se houver sessão ativa e o pack não bastar, 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
-5. Sem sessão ativa e se o pack não bastar, ler o equivalente legado na raiz `.oxe/`.
-6. 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
-7. Se a pergunta exigir evidência fora do pack, expandir a leitura apenas para os artefatos adicionais estritamente necessários e mencionar a expansão na resposta.
-8. Responder à pergunta do utilizador com base em evidência explícita dos artefatos lidos.
-9. Se faltar artefato crítico para responder com segurança, dizer exatamente o que falta e qual comando OXE fecha essa lacuna.
-10. Estruturar a resposta conforme o contrato de saída:
-   - **Fatos** — o que os artefatos confirmam sem ambiguidade
-   - **Inferências** — conclusões derivadas dos artefatos
-   - **Lacunas** — o que não pode ser afirmado com segurança
-   - **Próximo passo** — apenas quando fizer sentido operacional
-
-## 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.
-- O context pack acelera e comprime a leitura, mas não substitui a evidência. Se ele estiver stale ou insuficiente, o fallback deve ser explícito.
-- 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>
-- **Fatos**
-- **Inferências**
-- **Lacunas**
-- **Próximo passo** (quando necessário)
-- Referência curta aos artefatos usados
-</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>
+# OXE — Workflow: ask
+
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe`.
+> Use: `/oxe "sua pergunta"` ou simplesmente `/oxe` para o próximo passo.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
+<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>
+- Aplicar `oxe/workflows/references/reasoning-discovery.md` como postura cognitiva deste passo.
+- Resolver `active_session` via `oxe/workflows/references/session-path-resolution.md`.
+- Ler sempre `.oxe/STATE.md` global primeiro.
+- Antes de abrir o conjunto amplo de artefatos, tentar o contexto resolvido em `.oxe/context/packs/ask.md` e `.oxe/context/packs/ask.json` como entrada prioritária.
+- Se o pack existir e estiver fresco/coerente, ler primeiro o resumo do pack e depois inspecionar apenas os artefatos listados em `read_order` / `selected_artifacts` antes de expandir a leitura.
+- Se o pack estiver ausente, stale ou com lacunas críticas, fazer fallback explícito para leitura direta e declarar esse fallback na resposta.
+- 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. Resolver o contexto estruturado primeiro:
+   - tentar `.oxe/context/packs/ask.md` / `.oxe/context/packs/ask.json` (ou `oxe-cc context inspect --workflow ask --json`) para obter `read_order`, `selected_artifacts`, `gaps`, `conflicts` e `freshness`;
+   - se o pack estiver fresco e sem lacunas críticas, usá-lo como mapa primário de leitura;
+   - se o pack estiver stale, incompleto ou ausente, declarar `fallback para leitura direta` antes de abrir os artefatos brutos.
+3. Se houver pack válido, ler primeiro:
+   - o resumo humano do pack (`.md`);
+   - os artefatos de `read_order`;
+   - quaisquer artefatos adicionais de `selected_artifacts` necessários para responder com evidência.
+4. Se houver sessão ativa e o pack não bastar, 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
+5. Sem sessão ativa e se o pack não bastar, ler o equivalente legado na raiz `.oxe/`.
+6. 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
+7. Se a pergunta exigir evidência fora do pack, expandir a leitura apenas para os artefatos adicionais estritamente necessários e mencionar a expansão na resposta.
+8. Responder à pergunta do utilizador com base em evidência explícita dos artefatos lidos.
+9. Se faltar artefato crítico para responder com segurança, dizer exatamente o que falta e qual comando OXE fecha essa lacuna.
+10. Estruturar a resposta conforme o contrato de saída:
+   - **Fatos** — o que os artefatos confirmam sem ambiguidade
+   - **Inferências** — conclusões derivadas dos artefatos
+   - **Lacunas** — o que não pode ser afirmado com segurança
+   - **Próximo passo** — apenas quando fizer sentido operacional
+
+## 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.
+- O context pack acelera e comprime a leitura, mas não substitui a evidência. Se ele estiver stale ou insuficiente, o fallback deve ser explícito.
+- 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>
+- **Fatos**
+- **Inferências**
+- **Lacunas**
+- **Próximo passo** (quando necessário)
+- Referência curta aos artefatos usados
+</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

@@ -1,25 +1,25 @@
-# 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.
-5. Após qualquer operação de install ou remove bem-sucedida, atualizar **`.oxe/STATE.md`**: linha `capabilities_updated: YYYY-MM-DD` ou nota na secção Decisões registando a capability adicionada/removida.
-</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.
-- [ ] `.oxe/STATE.md` foi atualizado quando houve install ou remove (passo 5).
-</success_criteria>
+# 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.
+5. Após qualquer operação de install ou remove bem-sucedida, atualizar **`.oxe/STATE.md`**: linha `capabilities_updated: YYYY-MM-DD` ou nota na secção Decisões registando a capability adicionada/removida.
+</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.
+- [ ] `.oxe/STATE.md` foi atualizado quando houve install ou remove (passo 5).
+</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/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

@@ -126,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.
@@ -184,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
@@ -215,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.
@@ -230,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>