oxe-cc 0.7.1 → 0.9.1

package/oxe/workflows/dashboard.md

@@ -5,19 +5,29 @@ Gerar ou atualizar uma camada visual opcional para acompanhar execução, agente
 </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, blueprint de agentes e `VERIFY.md` quando existirem.
+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 artefato visual local ou estado preparado para renderização.
+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

@@ -6,8 +6,9 @@ Orientar **investigação técnica** de um sintoma (teste a falhar, erro em runt
 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>
-- Pré-requisito: sintoma reproduzível ou descrição clara (mensagem de erro, Tn em falha).
+<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.
@@ -22,8 +23,12 @@ Diferente de **`verify`**, que audita **aceite** contra SPEC/PLAN. Depois de est
    - **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: hipótese principal e próximo comando OXE.
-</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.

package/oxe/workflows/discuss.md

@@ -6,8 +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>
-- 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.
@@ -36,10 +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, listando decisões com seus IDs.
-</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

@@ -90,15 +90,19 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 </failure_mode>
 
 <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.
+
 **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/`.
+**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.
@@ -138,6 +142,12 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 
 <process>
 1. Ler **`.oxe/STATE.md`** global para resolver `active_session`, depois ler **`PLAN.md`** (se existir) e **`QUICK.md`** do escopo resolvido.
+1a. Resolver o context pack `execute` primeiro:
+   - ler `.oxe/context/packs/execute.md|json` (ou `oxe-cc context inspect --workflow execute --json`);
+   - se o pack estiver fresco e coerente, usá-lo como mapa primário para o reconhecimento inicial da onda/tarefa;
+   - 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%`;
@@ -151,24 +161,36 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
    - 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:
+5. **Gate de permissões:** se `.oxe/config.json` define `permissions[]` (array não-vazio):
+   - Para cada tarefa da onda, coletar os caminhos listados em **Arquivos prováveis:** do PLAN.md
+   - Avaliar cada caminho contra as regras em ordem (first-match wins):
+     - `action: deny` → **bloquear** a onda. Listar arquivos bloqueados e a regra que disparou. Não avançar sem que o utilizador remova a regra ou altere o plano.
+     - `action: ask` → **pausar** e apresentar: "Os seguintes arquivos requerem confirmação: [lista]. Regra: `pattern`. Confirma execução? (s/n)". Avançar só após confirmação explícita.
+     - `action: allow` ou nenhuma regra matchou → avançar normalmente
+   - O mesmo gate aplica-se em Azure `apply` quando `scope: apply` ou `all`
+6. **Seleção de modo** (apenas se PLAN.md com 2+ ondas e `execute_mode` não definido em STATE): se o argumento já for `A`, `B` ou `C`, usá-lo diretamente; senão apresentar opções A/B/C e aguardar escolha; registrar em STATE.md.
+7. Identificar **onda ou bloco atual**: no PLAN, todas as tarefas da mesma onda sem dependências pendentes; no QUICK, passos ainda não marcados como feitos.
+8. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
+8a. Antes de implementar, explicitar no chat:
+   - **Contexto lido** (incluindo se veio de pack fresco ou de fallback)
+   - **Alvo da mudança**
+   - **Validação prevista**
+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.
    - **Modo Por tarefa:** executar próxima tarefa pendente, parar.
-   - 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:
+   - Em qualquer modo: atualizar `EXECUTION-RUNTIME.md` a cada mudança de onda, bloqueio, retry, handoff, checkpoint ou saída do pack por falta de evidência.
+10. 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)
    ```
-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.
+11. Atualizar **`.oxe/STATE.md`** global com progresso resumido e, com sessão ativa, escrever o detalhe operacional em `execution/STATE.md`.
+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.
 </process>
 
 <success_criteria>

package/oxe/workflows/forensics.md

@@ -1,14 +1,15 @@
 # OXE — Workflow: forensics
 
 <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**).
+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>
+<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.
+- 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`.
@@ -24,19 +25,23 @@ Não reescrever `SPEC.md` nem apagar `PLAN.md`; apenas **recomendar** o reingres
 
 <process>
 1. Confirmar diretório raiz do projeto e existência de `.oxe/`.
-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).
-3. Redigir **`FORENSICS.md`** no escopo resolvido com secções fixas:
+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.
    - **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: resumo do diagnóstico e **só** o próximo passo (sem lista equiparável de alternativas).
-</process>
+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>
 
 <success_criteria>
-- [ ] `FORENSICS.md` existe no escopo correto com **Próximo passo OXE recomendado** igual a **um** entre `scan`, `plan`, `execute`.
+- [ ] `FORENSICS.md` existe no escopo correto com **Próximo passo OXE recomendado** igual a **um** entre `scan`, `plan`, `execute`.
 - [ ] Não há conclusão “feito” sem indicar reingresso na trilha canónica.
 - [ ] `SPEC.md` / `PLAN.md` não foram apagados nem substituídos sem ação explícita do utilizador.
 </success_criteria>

package/oxe/workflows/help.md

@@ -5,7 +5,11 @@ Apresentar o fluxo OXE (scan → spec → research opcional → plan → execuç
 </objective>
 
 <context>
-OXE é um fluxo **spec-driven** com artefatos em `.oxe/` no projeto alvo — **o núcleo é o mesmo** em Cursor, Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity ou outra CLI suportada pelo instalador. **Poucos comandos** por ferramenta em relação a fluxos de planeamento mais pesados; *context engineering* com arquivos pequenos por etapa. **GitHub Copilot (VS Code)** usa **`~/.copilot/`** após `npx oxe-cc` (bloco mesclado em `copilot-instructions.md` + **prompt files** em `~/.copilot/prompts/`), não `.github/` dentro do repo alvo por padrão; outras ferramentas usam os respetivos homes (ver secção **Multi-agente** abaixo).
+Aplicar `oxe/workflows/references/reasoning-status.md`. A ajuda deve ser curta, orientada a decisão e explícita sobre o próximo passo recomendado.
+
+OXE é um fluxo **spec-driven** com artefatos em `.oxe/` no projeto alvo — **o núcleo é o mesmo** em Cursor, Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity ou outra CLI suportada pelo instalador. **Poucos comandos** por ferramenta em relação a fluxos de planeamento mais pesados; *context engineering* com arquivos pequenos por etapa. **GitHub Copilot (VS Code)** é **workspace-first**: o `oxe-cc` escreve `.github/copilot-instructions.md` e `.github/prompts/` no projeto. `~/.copilot/` fica para o runtime do **Copilot CLI** e para limpeza de legado detectável, não como fonte primária da IDE.
+
+O OXE distingue cinco famílias de raciocínio multi-runtime: `discovery`, `planning`, `execution`, `review` e `status`. Essa semântica nasce em `oxe/workflows/references/reasoning-*.md`, entra nos workflows canónicos e é renderizada nos prompts/skills de cada runtime. A mesma etapa deve produzir respostas mais exploratórias, decision-complete e auditáveis em qualquer agente suportado.
 
 No **projeto**, os passos canónicos estão em **`.oxe/workflows/*.md`** (layout mínimo) ou **`oxe/workflows/*.md`** (layout clássico com `--global`); no **pacote npm**, os modelos vivem em **`oxe/workflows/*.md`**.
 </context>
@@ -78,13 +82,14 @@ Tudo o mais é ativado automaticamente por contexto, por config, ou existe como
 
 Slash commands essenciais: `/oxe`, `/oxe-obs`, `/oxe-quick`, `/oxe-scan`, `/oxe-spec`, `/oxe-plan`, `/oxe-execute`, `/oxe-verify`
 
-Slash commands completos: `/oxe-discuss`, `/oxe-plan-agent`, `/oxe-project`, `/oxe-loop`, `/oxe-security`, `/oxe-update`, `/oxe-forensics`, `/oxe-debug`, `/oxe-route`, `/oxe-research`, `/oxe-validate-gaps`, `/oxe-compact`, `/oxe-checkpoint`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-milestone`, `/oxe-workstream`, `/oxe-next`, `/oxe-help` (instalados em `~/.cursor/commands/` pelo `oxe-cc`). **Review de PR:** no Cursor não há slash dedicado — peça em linguagem natural seguindo `oxe/workflows/review-pr.md` em contexto.
+Slash commands completos: `/oxe-discuss`, `/oxe-plan-agent`, `/oxe-project`, `/oxe-loop`, `/oxe-security`, `/oxe-update`, `/oxe-forensics`, `/oxe-debug`, `/oxe-route`, `/oxe-research`, `/oxe-validate-gaps`, `/oxe-compact`, `/oxe-checkpoint`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-milestone`, `/oxe-workstream`, `/oxe-skill`, `/oxe-next`, `/oxe-help` (instalados em `~/.cursor/commands/` pelo `oxe-cc`). **Review de PR:** no Cursor não há slash dedicado — peça em linguagem natural seguindo `oxe/workflows/review-pr.md` em contexto.
 
 ### GitHub Copilot (VS Code)
 
-1. **Instruções do usuário:** arquivo **`~/.copilot/copilot-instructions.md`** (conteúdo mesclado pelo instalador; contém o bloco OXE entre marcadores).
-2. **Prompt files:** em **`~/.copilot/prompts/`** (ex.: `oxe-scan.prompt.md`). No chat, `/` e escolha **`oxe-scan`**, **`oxe-spec`**, etc. Requer `"chat.promptFiles": true` (exemplo em `.vscode/settings.json` do repo com layout `--global`).
-3. **`/oxe-review-pr`** — revisão de PR/diff (prompt na pasta do usuário; fluxo em `review-pr.md`).
+1. **Instruções do workspace:** arquivo **`.github/copilot-instructions.md`** (conteúdo mesclado pelo instalador; contém o bloco OXE entre marcadores).
+2. **Prompt files:** em **`.github/prompts/`** (ex.: `oxe-scan.prompt.md`). No chat, `/` e escolha **`oxe-scan`**, **`oxe-spec`**, etc. Requer `"chat.promptFiles": true` (exemplo em `.vscode/settings.json` do repo com layout `--global`).
+3. **`/oxe-review-pr`** — revisão de PR/diff (prompt no workspace; fluxo em `review-pr.md`).
+4. Se existir conteúdo OXE em `~/.copilot/prompts/`, trate como legado e limpe com `npx oxe-cc uninstall --copilot-legacy-clean`.
 
 **Checkpoint vs compact (rotina de contexto em disco):**
 
@@ -128,6 +133,7 @@ Com **`compact_max_age_days`** em `.oxe/config.json` (ver `oxe/templates/CONFIG.
 - **`/oxe-loop`** — iteração até verify passar (disponível standalone; integrado ao Modo B do execute via `loop_max`).
 - **`/oxe-research`** — notas datadas em `.oxe/research/` para spikes, mapas de sistema, engenharia reversa.
 - **`/oxe-capabilities`** — catálogo nativo de capabilities locais, por script ou conector, com metadata e diagnóstico.
+- **`/oxe-skill`** — descobrir, invocar e gerenciar skills (unificação de personas e capabilities via `@<id>`).
 - **`/oxe-dashboard`** — leitura visual/operacional do runtime, checkpoints e ondas ativas.
 - **`/oxe-route`** — traduz linguagem natural → comando. Equivalente a `/oxe [texto]`.
 - **`/oxe-compact`** — refresh explícito do codebase. Equivalente a `/oxe-scan` sem `--full`.
@@ -160,7 +166,7 @@ Um único comando para: `milestone new|complete|status|audit`, `workstream new|s
 ## CLI (terminal)
 
 - **`npx oxe-cc`** ou **`npx oxe-cc install`** — mesma instalação (alias explícito).
-- Instala workflows em `.oxe/` (layout mínimo) ou `oxe/` + `.oxe/` com **`--global`**; integrações em `~/.cursor`, `~/.copilot`, `~/.claude` (e mais destinos com **`--copilot-cli`** / **`--all-agents`**).
+- Instala workflows em `.oxe/` (layout mínimo) ou `oxe/` + `.oxe/` com **`--global`**; integrações em `~/.cursor`, `.github/` (Copilot VS Code), `~/.claude`, `~/.copilot/skills` (Copilot CLI) e mais destinos com **`--copilot-cli`** / **`--all-agents`**.
 - **`oxe-cc doctor`** — Node, workflows do pacote vs projeto, `config.json`, bootstrap mínimo de `.oxe/`, mapas do codebase, **coerência STATE vs arquivos**, sessão ativa, autoavaliação do plano, scan antigo (`scan_max_age_days`), compact antigo (`compact_max_age_days`), seções SPEC, ondas do PLAN e **saúde lógica** (`healthy` | `warning` | `broken`).
 - **`oxe-cc status`** — coerência `.oxe/` + **um** próximo passo (espelha `next.md`). Com **`--full`**, visão ANSI extendida: coverage matrix (SPEC/PLAN/VERIFY/LESSONS), readiness gate e active run — caminho padrão de inspeção no terminal. Com **`--json`**, uma linha JSON com `healthStatus`, `activeSession`, `planSelfEvaluation` e `diagnostics` completos. Com **`--hints`**, bloco **Lembretes (rotina OXE)**.
 - **`oxe-cc dashboard`** — UI web opt-in em `localhost` para revisão de equipe e aprovação do plano; use `oxe-cc status --full` para inspeção diária no terminal. Fonte de verdade: apenas artefatos OXE reais, incluindo `ACTIVE-RUN.json` e `OXE-EVENTS.ndjson`.
@@ -172,11 +178,11 @@ Um único comando para: `milestone new|complete|status|audit`, `workstream new|s
 - **`/oxe-update`** (Cursor; noutras ferramentas use o terminal no projeto) — workflow de atualização: verificar npm, correr `oxe-cc update`, `doctor`.
 - **`oxe-cc update --check`** — só comparar versão em execução com a `latest` no npm (sem instalar).
 - **`oxe-cc update --if-newer`** — só executa o `npx oxe-cc@latest` se houver versão mais nova no npm.
-- **`oxe-cc update` / `npx oxe-cc@latest --force`** — atualizar ficheiros OXE no projeto. Aceita flags extras como `--ide-local`, `--cursor`, `--copilot-cli`, `--global`, `--global-cli`.
+- **`oxe-cc update` / `npx oxe-cc@latest --force`** — atualizar ficheiros OXE no projeto. Aceita flags extras como `--ide-local`, `--cursor`, `--copilot`, `--copilot-cli`, `--global`, `--global-cli`.
 
 **CI / sem perguntas:** `OXE_NO_PROMPT=1` — layout mínimo e integrações padrão no HOME, salvo flags (`--global`, `--cursor`, …). Se existir **`.oxe/config.json`** com bloco **`install`** (perfil, `repo_layout`), aplica-se quando **não** há flags IDE explícitas; para ignorar: **`--no-install-config`**. Detalhes: `oxe/templates/CONFIG.md`.
 
-**Flags úteis (resumo):** `--force` / `-f`, `--dry-run`, `--all` / `-a` (Cursor+Copilot), `--oxe-only`, `--no-init-oxe`, `--global` / `--local`, `--copilot-cli`, `--all-agents`, `--vscode` (com `--global`), `--no-global-cli` / `-l`, `--config-dir` / `-c` (uma IDE de cada vez), `--dir <pasta>`. Ajuda completa: `oxe-cc --help`.
+**Flags úteis (resumo):** `--force` / `-f`, `--dry-run`, `--all` / `-a` (Cursor+Copilot VS Code), `--copilot-vscode`, `--copilot-cli`, `--oxe-only`, `--no-init-oxe`, `--global` / `--local`, `--all-agents`, `--vscode` (com `--global`), `--no-global-cli` / `-l`, `--config-dir` / `-c` (uma IDE de cada vez, exceto `--copilot`), `--dir <pasta>`. Ajuda completa: `oxe-cc --help`.
 
 **WSL:** usar Node instalado **no** WSL; o instalador recusa Node do Windows dentro do WSL.
 
@@ -267,7 +273,7 @@ Ver **`lib/sdk/README.md`** e **`lib/sdk/index.d.ts`**.
 | `OXE_NO_BANNER` | `1` / `true`: sem banner no CLI |
 | `OXE_UPDATE_SKIP_REGISTRY` | `1` / `true`: não consultar npm em `update --check` / `--if-newer` (saída `2` ou skip) |
 | `CURSOR_CONFIG_DIR` | Base Cursor (default `~/.cursor`) |
-| `COPILOT_CONFIG_DIR` / `COPILOT_HOME` | Base Copilot |
+| `COPILOT_CONFIG_DIR` / `COPILOT_HOME` | Base do Copilot CLI e do legado detectável |
 | `CLAUDE_CONFIG_DIR` | Base `~/.claude` |
 | `XDG_CONFIG_HOME` | OpenCode e outros (multi-agente) |
 | `CODEX_HOME` | Prompts Codex em instalação multi-agente |
@@ -291,3 +297,8 @@ Quando o usuário disser “oxe scan”, “oxe quick”, “executar onda OXE
 
 **Multi-agente:** `npx oxe-cc --all-agents` (ou opção **6** no instalador) replica os mesmos fluxos para **OpenCode** (`~/.config/opencode/commands` + `~/.opencode/commands`), **Gemini CLI** (`~/.gemini/commands` — `/oxe`, `/oxe:scan`, …; use **`/commands reload`**), **Codex** (`~/.agents/skills` + `~/.codex/prompts` com `/prompts:oxe-*`), **Windsurf** (`~/.codeium/windsurf/global_workflows` — `/oxe-scan`), **Google Antigravity** (`~/.gemini/antigravity/skills`), além de **Claude** (`~/.claude/commands`) e o já descrito Copilot.
 </output>
+
+<success_criteria>
+- [ ] O utilizador recebeu orientação sobre o fluxo OXE, comandos disponíveis e como invocar na IDE ativa.
+- [ ] Nenhum artefato em `.oxe/` foi criado ou alterado (passo puramente informativo).
+</success_criteria>

package/oxe/workflows/loop.md

@@ -6,8 +6,9 @@ Executar uma **onda do PLAN.md** em ciclo iterativo até que a verificação inl
 Quando verify falha, não interrompe — diagnostica (2-3 hipóteses), corrige, tenta de novo. Escala para **`/oxe-forensics`** apenas quando esgota as tentativas.
 </objective>
 
-<context>
-- **Pré-requisito:** `.oxe/PLAN.md` existente com pelo menos 1 onda; `STATE.md` com fase ≥ `plan_ready`.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-execution.md`. Cada iteração deve deixar explícitos o contexto lido, a hipótese testada e a validação executada.
+- **Pré-requisito:** `.oxe/PLAN.md` existente com pelo menos 1 onda; `STATE.md` com fase ≥ `plan_ready`.
 - **Máximo de iterações:** padrão = 3; configurável via argumento `max:<N>` (ex.: `/oxe-loop onda 2 max:5`). Nunca exceder 10.
 - **Artefato:** não cria novos arquivos — atualiza `STATE.md` com campos `loop_*` e registra cada iteração como bloco inline no chat.
 - **Escalação:** se esgotou tentativas e ainda falhou → registrar estado em STATE.md + sugerir `/oxe-forensics` com contexto das hipóteses já tentadas.
@@ -41,11 +42,16 @@ Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalo
       - Incrementar iteração: `loop_iteracao: K+1/<max>`.
       - Se `K+1 > max`: ir para passo 4 (escalação).
       - Senão: aplicar fix para a hipótese mais provável → voltar a `c`.
-4. **Escalação (tentativas esgotadas):**
-   - Registrar `loop_status: escalated` em STATE.md.
-   - Exibir no chat: tentativas realizadas, hipóteses testadas, evidência de cada falha.
-   - Sugerir `/oxe-forensics` com contexto: "onda N falhou após <max> tentativas — hipóteses testadas: H1, H2, H3".
-</process>
+4. **Escalação (tentativas esgotadas):**
+   - Registrar `loop_status: escalated` em STATE.md.
+   - Exibir no chat: tentativas realizadas, hipóteses testadas, evidência de cada falha.
+   - Sugerir `/oxe-forensics` com contexto: "onda N falhou após <max> tentativas — hipóteses testadas: H1, H2, H3".
+5. Em toda resposta ao utilizador, manter a ordem:
+   - **Contexto lido**
+   - **Validação executada**
+   - **Resultado**
+   - **Próximo passo**
+</process>
 
 <success_criteria>
 - [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.

package/oxe/workflows/next.md

@@ -5,6 +5,7 @@ Inspecionar `.oxe/STATE.md` global, a sessão ativa quando existir, e a existên
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-status.md`. O passo devolve leitura curta, recomendação única e motivo.
 - O usuário pode rodar **`npx oxe-cc status`** no terminal para a mesma lógica resumida. **`npx oxe-cc status --hints`** (ou **`--json --hints`**) acrescenta lembretes **paralelos** (idade do scan/compact por config) — **não** altera o único passo canónico que este workflow deve devolver.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, preferir os artefatos da sessão antes de olhar a raiz legada.
 - Se houver empate aparente (ex.: poderia ser spec ou quick), preferir **spec** quando já existir mapa de codebase; preferir **quick** só se o usuário deixar explícito que é correção mínima.
@@ -30,10 +31,11 @@ Inspecionar `.oxe/STATE.md` global, a sessão ativa quando existir, e a existên
 **Saída obrigatória (só isto, nesta ordem):**
 
 - **Próximo passo:** um único entre `scan` | `spec` | `discuss` | `plan` | `quick` | `execute` | `verify`
-- **Comando:** o slash correspondente (ex.: `/oxe-scan`) **ou** `npx oxe-cc status` para conferir de novo
-- **Por quê:** uma frase
-- **Artefatos em jogo:** lista curta (máx. 4 itens)
-</process>
+- **Comando:** o slash correspondente (ex.: `/oxe-scan`) **ou** `npx oxe-cc status` para conferir de novo
+- **Por quê:** uma frase
+- **Confiança / lacuna:** só quando o estado estiver incompleto ou ambíguo
+- **Artefatos em jogo:** lista curta (máx. 4 itens)
+</process>
 
 <success_criteria>
 - [ ] Foi indicado **exatamente um** próximo passo entre os valores canónicos (`scan`, `spec`, `discuss`, `plan`, `quick`, `execute`, `verify`) ou mensagem explícita de fluxo concluído.

package/oxe/workflows/plan-agent.md

@@ -14,6 +14,7 @@ Se o utilizador pedir **`--replan`**: aplicar a mesma lógica de replanejamento
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-planning.md`. O blueprint e o PLAN devem sair decision-complete; não deixar decisões relevantes implícitas para a execução dos agentes.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, `PLAN.md`, `plan-agents.json` e `plan-agent-messages/` vivem em `.oxe/<active_session>/plan/`; sem sessão ativa, manter `.oxe/`.
 - O `plan-agent` herda integralmente o contrato `oxe/workflows/references/flow-robustness-contract.md`. Não pode emitir percentuais concorrentes por agente; a confiança final do plano é única e visível no `PLAN.md`.
 - **Pré-requisitos** iguais a **`plan.md`**: `.oxe/SPEC.md` obrigatória; `discuss_before_plan` + `DISCUSS.md` quando configurado; consumir **NOTES**, **UI-SPEC**, **DISCUSS**, **RESEARCH**, **CODEBASE-DELTA** / **RESUME**, **config.json** (`plan_max_tasks_per_wave`, `default_verify_command`) como em **`plan.md`**.
@@ -130,8 +131,8 @@ Resumo obrigatório no chat: `Gate plan-agent: OK` ou `Gate plan-agent: corrigid
 6. Criar `plan-agent-messages/` e `plan-agent-messages/README.md` no escopo resolvido a partir de **`oxe/templates/plan-agent-messages-README.template.md`**.
 7. Atualizar **`.oxe/STATE.md`**: fase `plan_ready`, próximo passo `oxe:execute`; preencher **Blueprint de agentes (sessão)** — `run_id` (= `runId`), `lifecycle_status` (= `pending_execute`), **última onda** — (ou `—`).
 8. Aplicar **`<plan_agent_quality_gate>`**; corrigir até passar.
-9. No chat: resumo do gate plan-agent, `runId`, número de agentes, ondas, tarefas, referência ao protocolo em **`references/plan-agent-chat-protocol.md`**.
-</process>
+9. No chat: resumo do gate plan-agent, `runId`, número de agentes, ondas, tarefas, riscos e assumptions relevantes, e referência ao protocolo em **`references/plan-agent-chat-protocol.md`**.
+</process>
 
 <success_criteria>
 - [ ] `PLAN.md` existe e passa o gate de **`plan.md`**.

package/oxe/workflows/plan.md

@@ -12,12 +12,21 @@ Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_fai
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-planning.md` como contrato deste passo. O `PLAN.md` deve sair decision-complete e não deixar decisões relevantes para a execução.
 - Seguir `oxe/workflows/references/flow-robustness-contract.md` como contrato canónico de robustez. A ordem obrigatória é: ler artefatos, resolver sessão/paths, validar pré-condições, escrever o plano, autoavaliar o plano, registrar próximo passo único.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, o plano vive em `.oxe/<active_session>/plan/` e lê a spec em `.oxe/<active_session>/spec/`.
+- Antes do scan amplo, carregar `.oxe/context/packs/plan.md` e `.oxe/context/packs/plan.json` como entrada prioritária do contexto do passo.
+- Se o pack existir e estiver fresco/coerente, usar `read_order`, `selected_artifacts`, `gaps` e `conflicts` como mapa primário de leitura e como insumo direto da autoavaliação.
+- Se o pack estiver stale, ausente ou incompleto, fazer fallback explícito para leitura direta e, quando viável, regenerar ou inspecionar o contexto com `oxe-cc context inspect --workflow plan --json`.
 - Quando existirem, ler `INVESTIGATIONS.md`, `RESEARCH.md`, `CAPABILITIES.md`, `memory/` do projeto e `CHECKPOINTS.md` para calibrar dependências, riscos, automações disponíveis e gates humanos necessários.
 - Se a SPEC ou artefatos do projeto mencionarem **Azure explicitamente** (Azure Service Bus, Azure SQL, Azure Event Grid, az CLI, ARM, subscription Azure, ou `.oxe/cloud/azure/` existir no projeto), **antes de detalhar tarefas**: (1) verificar `auth-status.json` — se `login_active: false` ou `subscription_id` ausente, registrar como **pré-condição bloqueante** no PLAN.md e sugerir `oxe-cc azure status` / `oxe-cc azure auth login`; (2) verificar staleness do inventário via `inventory.synced_at` — se stale além de `inventory_max_age_hours`, sugerir `oxe-cc azure sync` antes de executar; (3) se `vpn_required: true` no config, registrar como restrição explícita nas tarefas de mutação Azure. O plano deve vincular tarefas a recursos existentes em INVENTORY.md, SERVICEBUS.md, EVENTGRID.md ou SQL.md, ou declarar explicitamente os recursos Azure a criar com `oxe-cc azure <domínio> plan`. **SQL genérico, bancos on-prem ou outras nuvens não acionam este bloco.**
 - Se existir `OBSERVATIONS.md` do escopo resolvido com entradas `pendente` de impacto `plan` ou `all`, incorporar nas tarefas relevantes antes de finalizar o plano (ajustar implementação, verificação ou escopo de Tn) e marcar essas entradas como `incorporada → plan (data)`.
-- Se existir **`.oxe/global/LESSONS.md`**, ler entradas com `Aplicar em: /oxe-plan` e `Status: ativo`. **Priorizar entradas com `Frequência >= 2` ou `Impacto: alto`** — aplicar como restrições explícitas no planejamento: ajuste de complexidade de tarefas, padrões de verificação, escolha de modo solo vs agentes. Lições com `Frequência: 1` e `Impacto: baixo` são contexto secundário. Registrar aplicações como comentário no PLAN.md: `<!-- lição C-NN aplicada: ... -->`.
+- Se existir **`.oxe/global/LESSONS.md`**, ler entradas com `Aplicar em: /oxe-plan` e `Status: ativo`. **Priorizar entradas com `Frequência >= 2` ou `Impacto: alto`** — aplicar como restrições explícitas no planejamento. Lições com `Frequência: 1` e `Impacto: baixo` são contexto secundário. Registrar aplicações como comentário no PLAN.md: `<!-- lição C-NN aplicada: ... -->`.
+- **Filtro de efetividade:** se `.oxe/lessons-metrics.json` existir, antes de aplicar cada lição verificar seu `status` e `success_rate`:
+  - `status: "deprecated"` → informar que a lição foi depreciada por baixa efetividade; não aplicar como restrição.
+  - `success_rate < 0.7` e `applied_cycles.length >= 2` → aplicar com ressalva explícita: `<!-- lição C-NN aplicada com ressalva: success_rate=X.X -->`.
+  - `applied_cycles.length === 1` → aplicar com nota: `<!-- lição C-NN: 1 observação, evidência limitada -->`.
+  - `success_rate >= 0.7` e `applied_cycles.length >= 2` → aplicar com alta confiança sem ressalva.
 - **LESSONS + OBS juntos:** se houver tanto LESSONS quanto OBS pendentes, LESSONS orientam o *como planejar* e OBS orientam o *o que incluir*. Não confundir os papéis.
 - Não inventar APIs inexistentes: cruzar com **STRUCTURE.md**, **INTEGRATIONS.md** e arquivos reais; respeitar **CONCERNS.md** (evitar agravar dívida conhecida sem tarefa explícita).
 - Se existir **`.oxe/NOTES.md`**, rever entradas em aberto: incorporar em tarefas (com **Aceite vinculado** quando aplicável) ou registar na secção **Replanejamento** / nota explícita *fora de âmbito desta trilha*. Se não existir e houver necessidade de registrar notas, criar a partir de `oxe/templates/NOTES.template.md`.
@@ -121,6 +130,7 @@ Antes de finalizar a resposta ao utilizador, o agente **deve** percorrer este ga
 12. **Rastreabilidade de evidência:** cada tarefa deve ter entrada observável de origem na SPEC, no codebase, em DISCUSS, OBS, RESEARCH ou LESSONS; tarefa sem evidência de entrada explícita = falha do gate.
 13. **Mudanças de risco:** tarefas com risco relevante (migração, auth, schema, contrato público, segurança) devem incluir contenção, rollback, fallback ou verificação reforçada.
 14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
+15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
 
 Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
 
@@ -129,16 +139,29 @@ Resumo obrigatório no chat: `Gate do plano: OK` ou `Gate do plano: corrigido (N
 
 <process>
 1. Resolver `active_session` e ler `SPEC.md` do escopo correto (obrigatório). Se faltar, pedir **spec** primeiro.
+1a. Resolver o context pack `plan` primeiro:
+   - ler `.oxe/context/packs/plan.md|json` (ou `oxe-cc context inspect --workflow plan --json`);
+   - se estiver fresco e coerente, usar o pack como mapa primário;
+   - se estiver stale, incompleto ou ausente, registar `fallback para leitura direta` e seguir com leitura bruta.
+1b. Com pack válido, ler primeiro o resumo do pack e os artefatos de `read_order`; só abrir outros artefatos quando faltarem evidências para fechar tarefas, riscos ou autoavaliação.
 2. Se `.oxe/config.json` tiver `discuss_before_plan: true` e **não** existir `DISCUSS.md` no escopo resolvido com decisões fechadas, pedir **discuss** antes de planejar.
 3. Se existir **`.oxe/NOTES.md`**, consumir ou explicitamente adiar cada bullet relevante (ver **context**).
-4. Ler `.oxe/codebase/*.md` (incl. CONVENTIONS / CONCERNS) e inspecionar pontos de entrada se a spec exigir.
+4. Ler `.oxe/codebase/*.md` (incl. CONVENTIONS / CONCERNS) e inspecionar pontos de entrada se a spec exigir. Se o pack não bastar, expandir a leitura apenas para os artefatos adicionais necessários e registar essa expansão.
 5. Escrever ou atualizar `PLAN.md` no escopo resolvido usando `oxe/templates/PLAN.template.md` como cabeçalho; **preservar** YAML inicial (`oxe_doc: plan`, `status`, `inputs`) se já existir e **atualizar** `updated:` (ISO); em **--replan**, preencher a seção **Replanejamento** (data, motivo, lições de VERIFY/SUMMARY, tarefas removidas/alteradas).
 6. Definir ondas: onda 1 = tarefas sem dependência entre si; onda seguinte = dependentes; respeitar `plan_max_tasks_per_wave` se configurado.
-7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos.
+6a. **Calibração histórica:** se `.oxe/calibration.json` existir e tiver ≥ 2 registros, ler as últimas 3 entradas antes de preencher a autoavaliação. Para cada dimensão com `calibration_error > 0.25` em 2+ ciclos consecutivos, adicionar `[⚠ historicamente subestimado]` na nota da dimensão e reduzir o score em 0.10 ou justificar explicitamente por que o ciclo atual é diferente.
+7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos. As lacunas, conflitos e freshness do pack devem aparecer nessa autoavaliação quando forem relevantes. **Incluir o bloco `<confidence_vector>`** com as 6 dimensões usando o template em `oxe/templates/PLAN.template.md`.
+7a. **Hipóteses Críticas:** ao criar tarefas `L` ou `XL` ou qualquer tarefa que dependa de lib externa, API de terceiros ou serviço de infra não testado ainda — adicionar seção `## Hipóteses Críticas` com pelo menos uma `<hypothesis>` por dependência crítica. Usar `oxe/templates/HYPOTHESES.template.md` como referência. Omitir a seção se todas as tarefas forem `S`/`M` e sem dependências externas não verificadas.
 8. Aplicar integralmente o bloco **`<plan_quality_gate>`** acima ao `PLAN.md` em disco; corrigir o ficheiro até passar ou documentar gaps explícitos.
 9. Atualizar `.oxe/STATE.md` global: fase `plan_ready`, próximo passo `oxe:execute` apenas se `Melhor plano atual: sim` e a confiança estiver no limiar executável; caso contrário, próximo passo deve reduzir incerteza (`oxe:discuss`, `oxe:research` ou replanejamento).
 10. **Sugestão de agentes (inteligente):** após o gate passar, verificar se o plano tem 3+ domínios distintos (ex.: backend + frontend + DB, ou auth + notificações + UI). Se sim, sugerir proativamente: "Este plano tem N domínios distintos. Quer gerar um blueprint de agentes com `/oxe-plan --agents`?" — não executar automaticamente, apenas oferecer. Se o usuário incluiu `--agents` no input original, executar imediatamente a lógica de `oxe/workflows/plan-agent.md`.
 11. Listar no chat: resultado do gate (OK ou corrigido), ondas, contagem de tarefas, comando de teste guarda-chuva se houver, melhor-plano-atual e confiança.
+12. No resumo em chat, deixar explícitos:
+   - objetivo e escopo do plano;
+   - principais riscos e contenções;
+   - assumptions relevantes;
+   - se o plano foi produzido com pack fresco ou com fallback explícito;
+   - comando único recomendado para o próximo passo.
 </process>
 
 <success_criteria>

package/oxe/workflows/quick.md

@@ -8,8 +8,9 @@ Quando o trabalho envolve **2 ou mais domínios distintos** (ex.: backend + fron
 Usar quando: correção pontual, refactor local, feature pequena ou protótipo que **não** justifica critérios de aceite completos.
 </objective>
 
-<context>
-- Seguir `oxe/workflows/references/flow-robustness-contract.md`. Quick continua leve, mas não pode fingir que existe plano formal quando ele não existe.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-planning.md` em modo lean. Mesmo sem plano formal completo, o quick deve explicitar objetivo, validação, riscos e condição de promoção.
+- Seguir `oxe/workflows/references/flow-robustness-contract.md`. Quick continua leve, mas não pode fingir que existe plano formal quando ele não existe.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, `QUICK.md` e `quick-agents.json` vivem em `.oxe/<active_session>/plan/`; sem sessão ativa, manter `.oxe/`.
 - Ler `.oxe/STATE.md` e, se existirem, `OVERVIEW.md` e `STACK.md` em `.oxe/codebase/` para não contradizer o repo.
 - Não apagar `SPEC.md` / `PLAN.md` se existirem; este fluxo é paralelo ou temporário.
@@ -162,7 +163,13 @@ Se **sim**, o próximo passo recomendado no chat é **`/oxe-spec`** (depois disc
 5. Se existir **`.oxe/plan-agents.json`** com schema 2 e lifecycle ainda não `invalidated`, aplicar a invalidação descrita em **context** (actualizar JSON + **STATE.md** — blueprint de agentes).
 6. Se existir **`.oxe/quick-agents.json`** anterior com `status` não-terminal, invalidá-lo (ver **context**).
 7. Atualizar **`.oxe/STATE.md`**: fase `quick_active`, próximo passo `oxe:execute` ou implementação manual + `oxe:verify`; se PDDA ativo, registrar `quick_agents_status: active` e `quick_id: <quickId>`.
-8. Responder no chat com resumo em ≤10 linhas: objetivo, passos, agentes (se PDDA ativo), verificação; se promover = sim, destacar **`/oxe-spec`** como próximo passo lógico; se blueprint plan-agent foi invalidado, mencionar **`/oxe-plan-agent`** para novo roteiro.
+8. Responder no chat com resumo em ≤10 linhas, nesta ordem:
+   - **Objetivo**
+   - **Plano**
+   - **Validação**
+   - **Riscos / assumptions**
+   - **Próximo passo**
+   Se promover = sim, destacar **`/oxe-spec`** como próximo passo lógico; se blueprint plan-agent foi invalidado, mencionar **`/oxe-plan-agent`** para novo roteiro.
 9. **Sugestão de commit (pós-verify bem-sucedido):** após o bloco **Verificar** passar, sugerir ao usuário: *"Quick concluído. Commitar? `git add -p && git commit -m 'quick: <objetivo em uma linha>'`"* — apenas sugerir, não executar automaticamente.
 </process>
 

package/oxe/workflows/references/reasoning-discovery.md

@@ -0,0 +1,28 @@
+# OXE — Contrato de Raciocínio: Discovery
+
+Use este contrato em workflows de descoberta, leitura situacional e redução de ambiguidade.
+
+## Ordem obrigatória
+
+1. Explorar artefatos e repositório antes de perguntar.
+2. Separar fatos confirmados, inferências e lacunas.
+3. Perguntar apenas ambiguidades de alto impacto.
+4. Responder com base em evidência do workspace.
+5. Fechar com um próximo passo único quando fizer sentido.
+
+## Regras
+
+- Não perguntar o que pode ser resolvido por leitura de arquivos, código, config ou estado.
+- Distinguir explicitamente:
+  - fato confirmado;
+  - inferência;
+  - lacuna de evidência.
+- Se o contexto local já for suficiente, não abrir rodada de perguntas por hábito.
+- Quando a resposta envolver estado incompleto, dizer a confiança da leitura e o artefato ausente.
+
+## Saída esperada
+
+- **Fatos**
+- **Inferências**
+- **Lacunas**
+- **Próximo passo**

package/oxe/workflows/references/reasoning-execution.md

@@ -0,0 +1,29 @@
+# OXE — Contrato de Raciocínio: Execution
+
+Use este contrato em workflows de execução, correção, loop operacional e mutação controlada.
+
+## Ordem obrigatória
+
+1. Fazer reconhecimento curto do contexto real antes de editar ou aplicar efeitos colaterais.
+2. Explicitar o alvo da mudança e a fatia atual.
+3. Operar no menor write set viável.
+4. Validar após cada fatia relevante.
+5. Parar e registrar bloqueio quando a hipótese crítica não estiver verificada.
+
+## Regras
+
+- Não saltar direto para mutação sem ler os artefatos e arquivos necessários.
+- Preferir mudanças pequenas e verificáveis em vez de alteração ampla e opaca.
+- Se surgir conflito estrutural ou ambiguidade de alto impacto, pausar e explicitar.
+- Toda execução deve terminar com:
+  - avanço confirmado;
+  - bloqueio claro; ou
+  - próxima ação única.
+
+## Saída esperada
+
+- **Contexto lido**
+- **Alvo da mudança**
+- **Validação executada**
+- **Resultado**
+- **Próximo passo**

package/oxe/workflows/references/reasoning-planning.md

@@ -0,0 +1,32 @@
+# OXE — Contrato de Raciocínio: Planning
+
+Use este contrato em workflows que produzem plano, roteiro de implementação ou decomposição de trabalho.
+
+## Ordem obrigatória
+
+1. Ler artefatos de contrato e contexto técnico.
+2. Validar pré-condições e incertezas abertas.
+3. Produzir um plano decision-complete.
+4. Autoavaliar o plano com confiança explícita.
+5. Registrar o próximo passo único.
+
+## Regras
+
+- Não deixar decisões importantes para quem implementar depois.
+- Tornar explícitos:
+  - interfaces e artefatos esperados;
+  - validação mínima;
+  - riscos e contenção;
+  - assumptions;
+  - condição para replanejar.
+- Se faltar evidência crítica, refletir isso na confiança e no próximo passo.
+- Não propor execução direta quando a própria confiança ou os gates não sustentam isso.
+
+## Saída esperada
+
+- **Objetivo**
+- **Plano**
+- **Validação / testes**
+- **Riscos e contenção**
+- **Assumptions**
+- **Confiança**