oxe-cc 1.0.0 → 1.3.0

package/oxe/templates/PLAN-REVIEW.template.md

@@ -1,31 +1,31 @@
----
-oxe_doc: plan_review
-status: draft
-updated: YYYY-MM-DD
-plan_ref: PLAN.md
----
-
-# OXE — Revisão do Plano
-
-## Estado
-
-- **Status:** draft
-- **Atualizado em:** YYYY-MM-DDTHH:mm:ssZ
-- **Origem:** dashboard local ou revisão textual
-
-## Decisão
-
-- **Resultado:** pendente
-- **Justificativa:** —
-
-## Comentários abertos
-
-- Nenhum
-
-## Comentários resolvidos
-
-- Nenhum
-
-## Próxima ação recomendada
-
-- `/oxe-dashboard` para revisar visualmente, ou `/oxe-plan --replan` se houver ajustes estruturais.
+---
+oxe_doc: plan_review
+status: draft
+updated: YYYY-MM-DD
+plan_ref: PLAN.md
+---
+
+# OXE — Revisão do Plano
+
+## Estado
+
+- **Status:** draft
+- **Atualizado em:** YYYY-MM-DDTHH:mm:ssZ
+- **Origem:** dashboard local ou revisão textual
+
+## Decisão
+
+- **Resultado:** pendente
+- **Justificativa:** —
+
+## Comentários abertos
+
+- Nenhum
+
+## Comentários resolvidos
+
+- Nenhum
+
+## Próxima ação recomendada
+
+- `/oxe-dashboard` para revisar visualmente, ou `/oxe-plan --replan` se houver ajustes estruturais.

package/oxe/templates/SESSION.template.md

@@ -1,34 +1,34 @@
-# Session sNNN — <nome>
-
-## Metadados
-
-- **ID:** sNNN
-- **Nome:** <nome>
-- **Status:** active
-- **Criada:** YYYY-MM-DD
-- **Última atividade:** YYYY-MM-DD
-- **Resumo:** <uma linha>
-- **Forked from:** —
-- **Forked at:** —
-
-## Índice de artefatos
-
-| Artefato | Caminho | Status |
-|----------|---------|--------|
-| SESSION | `sessions/sNNN-<slug>/SESSION.md` | ativo |
-
-## Dependências cruzadas
-
-- **Estende:** —
-- **Referenciada por:** —
-- **Decisões globais:** `.oxe/STATE.md`, `.oxe/SESSIONS.md`
-
-## Tags
-
-- `<tag>`
-
-## Histórico
-
-| Data | Evento |
-|------|--------|
-| YYYY-MM-DD | Sessão criada |
+# Session sNNN — <nome>
+
+## Metadados
+
+- **ID:** sNNN
+- **Nome:** <nome>
+- **Status:** active
+- **Criada:** YYYY-MM-DD
+- **Última atividade:** YYYY-MM-DD
+- **Resumo:** <uma linha>
+- **Forked from:** —
+- **Forked at:** —
+
+## Índice de artefatos
+
+| Artefato | Caminho | Status |
+|----------|---------|--------|
+| SESSION | `sessions/sNNN-<slug>/SESSION.md` | ativo |
+
+## Dependências cruzadas
+
+- **Estende:** —
+- **Referenciada por:** —
+- **Decisões globais:** `.oxe/STATE.md`, `.oxe/SESSIONS.md`
+
+## Tags
+
+- `<tag>`
+
+## Histórico
+
+| Data | Evento |
+|------|--------|
+| YYYY-MM-DD | Sessão criada |

package/oxe/templates/SKILL.template.md

@@ -1,26 +1,26 @@
----
-oxe_skill: true
-id: <skill-id>
-name: <Human Readable Name>
-version: 1.0.0
-type: persona | capability | composite
-scope: global | project
-description: <one-line description>
-invoke: "@<skill-id>"
-references: []
-tags: []
----
-
-# Skill: <name>
-
-## Descrição
-
-(Quando e como usar este skill. Uma ou duas frases.)
-
-## Ativação
-
-Mencionar `@<skill-id>` no chat ou incluir na atribuição de agente em plan-agents.json (`"persona": "<skill-id>"`).
-
-## Saída esperada
-
-(O que o agente faz ao adotar este skill.)
+---
+oxe_skill: true
+id: <skill-id>
+name: <Human Readable Name>
+version: 1.0.0
+type: persona | capability | composite
+scope: global | project
+description: <one-line description>
+invoke: "@<skill-id>"
+references: []
+tags: []
+---
+
+# Skill: <name>
+
+## Descrição
+
+(Quando e como usar este skill. Uma ou duas frases.)
+
+## Ativação
+
+Mencionar `@<skill-id>` no chat ou incluir na atribuição de agente em plan-agents.json (`"persona": "<skill-id>"`).
+
+## Saída esperada
+
+(O que o agente faz ao adotar este skill.)

package/oxe/templates/STATE.md

@@ -1,15 +1,15 @@
 # OXE — Estado
 
-## Fase atual
-
-`initial` — defina após primeiro scan: `scan_complete` | `spec_ready` | `discuss_complete` | `plan_ready` | `quick_active` | `executing` | `verify_complete` | `verify_failed`
-
-## Sessão ativa (opcional — `/oxe-session`)
-
-- **active_session:** (path relativo a `.oxe/` — ex.: `sessions/s001-auth-redesign` — ou — se nenhuma)
-- **session_id:** (ex.: `s001` — ou —)
-
-## Último scan
+## Fase atual
+
+`initial` — defina após primeiro scan: `scan_complete` | `spec_ready` | `discuss_complete` | `plan_ready` | `quick_active` | `executing` | `verify_complete` | `verify_failed`
+
+## Sessão ativa (opcional — `/oxe-session`)
+
+- **active_session:** (path relativo a `.oxe/` — ex.: `sessions/s001-auth-redesign` — ou — se nenhuma)
+- **session_id:** (ex.: `s001` — ou —)
+
+## Último scan
 
 - **Data:** (use **YYYY-MM-DD** para o `oxe-cc doctor` avisar scan antigo com `scan_max_age_days` em `.oxe/config.json`)
 - **Notas:** (opcional)
@@ -20,32 +20,32 @@
 - **Notas:** (opcional; ex.: "só STRUCTURE e TESTING")
 - **last_retro:** (YYYY-MM-DD — preenchido por **`/oxe-retro`** ao concluir retrospectiva; lido por `oxe-cc doctor` para rastrear ciclos sem lições)
 
-## Contexto do plano / quick (opcional)
-
-- **Spec / plano:** (revisão informal ou data de `.oxe/SPEC.md` / `.oxe/PLAN.md`)
-- **Última onda executada:** (número ou —)
-- **Tarefas concluídas:** (ex.: T1, T2 ou passos 1–3 do QUICK.md)
-
-## Checkpoints de aprovação (opcional)
-
-- **checkpoint_status:** `pending_approval` | `approved` | `rejected` | `overridden` | —
-- **checkpoint_ref:** `.oxe/CHECKPOINTS.md` ou artefato de sessão correspondente
-- **Notas:** (ex.: aguardando aprovação para Onda 2)
-
-## Runtime operacional (opcional)
-
-- **runtime_status:** `planned` | `running` | `paused` | `waiting_approval` | `failed` | `completed` | `replaying` | `aborted` | —
-- **runtime_ref:** `.oxe/EXECUTION-RUNTIME.md` ou artefato de sessão correspondente
-- **active_run_ref:** `.oxe/ACTIVE-RUN.json` ou artefato de sessão correspondente
-- **events_ref:** `.oxe/OXE-EVENTS.ndjson` ou artefato de sessão correspondente
-- **Notas:** (agentes ativos, bloqueio principal, handoff pendente)
-
-## Revisão do plano (opcional — dashboard / aprovação)
-
-- **plan_review_status:** `draft` | `in_review` | `approved` | `rejected` | `needs_revision` | —
-- **plan_review_updated:** (ISO legível — ex.: `2026-04-10T14:22:00-03:00`)
-- **plan_review_ref:** `.oxe/PLAN-REVIEW.md` ou artefato de sessão correspondente
-- **Notas:** (ex.: aprovado para execute; revisão pendente da onda 2)
+## Contexto do plano / quick (opcional)
+
+- **Spec / plano:** (revisão informal ou data de `.oxe/SPEC.md` / `.oxe/PLAN.md`)
+- **Última onda executada:** (número ou —)
+- **Tarefas concluídas:** (ex.: T1, T2 ou passos 1–3 do QUICK.md)
+
+## Checkpoints de aprovação (opcional)
+
+- **checkpoint_status:** `pending_approval` | `approved` | `rejected` | `overridden` | —
+- **checkpoint_ref:** `.oxe/CHECKPOINTS.md` ou artefato de sessão correspondente
+- **Notas:** (ex.: aguardando aprovação para Onda 2)
+
+## Runtime operacional (opcional)
+
+- **runtime_status:** `planned` | `running` | `paused` | `waiting_approval` | `failed` | `completed` | `replaying` | `aborted` | —
+- **runtime_ref:** `.oxe/EXECUTION-RUNTIME.md` ou artefato de sessão correspondente
+- **active_run_ref:** `.oxe/ACTIVE-RUN.json` ou artefato de sessão correspondente
+- **events_ref:** `.oxe/OXE-EVENTS.ndjson` ou artefato de sessão correspondente
+- **Notas:** (agentes ativos, bloqueio principal, handoff pendente)
+
+## Revisão do plano (opcional — dashboard / aprovação)
+
+- **plan_review_status:** `draft` | `in_review` | `approved` | `rejected` | `needs_revision` | —
+- **plan_review_updated:** (ISO legível — ex.: `2026-04-10T14:22:00-03:00`)
+- **plan_review_ref:** `.oxe/PLAN-REVIEW.md` ou artefato de sessão correspondente
+- **Notas:** (ex.: aprovado para execute; revisão pendente da onda 2)
 
 ## Blueprint de agentes (sessão) (opcional — `/oxe-plan-agent`)
 
@@ -102,28 +102,28 @@ _(O agente pode preencher após cada onda.)_
 
 - (nome do workstream ativo — ou — para pipeline principal)
 
-## Memory (sidecars de sessão) (opcional — `/oxe-memory`)
+## Memory (sidecars de sessão) (opcional — `/oxe-memory`)
 
 Sidecars de memória persistente por agente/sessão. Armazenados em `.oxe/memory/`.
 
-- (nenhum ou lista: ex.: `architect-2025-01-15.md`, `researcher-auth-2025-01-14.md`)
-
-## Camadas de memória (contrato)
-
-- **memory_read_order:** `runtime_state -> session_memory -> project_memory -> evidence`
-- **session_memory_ref:** `SESSION.md` ou —
-- **project_memory_ref:** `.oxe/global/LESSONS.md`
-- **evidence_ref:** `INVESTIGATIONS.md`, `VERIFY.md` e derivados
-
-## Capabilities nativas (opcional)
-
-- **capabilities_ref:** `.oxe/CAPABILITIES.md`
-- **Capabilities ativas:** (IDs ou —)
-
-## Investigações estruturadas (opcional)
-
-- **investigations_ref:** `.oxe/INVESTIGATIONS.md` ou índice de sessão
-- **Última investigação:** (path ou —)
+- (nenhum ou lista: ex.: `architect-2025-01-15.md`, `researcher-auth-2025-01-14.md`)
+
+## Camadas de memória (contrato)
+
+- **memory_read_order:** `runtime_state -> session_memory -> project_memory -> evidence`
+- **session_memory_ref:** `SESSION.md` ou —
+- **project_memory_ref:** `.oxe/global/LESSONS.md`
+- **evidence_ref:** `INVESTIGATIONS.md`, `VERIFY.md` e derivados
+
+## Capabilities nativas (opcional)
+
+- **capabilities_ref:** `.oxe/CAPABILITIES.md`
+- **Capabilities ativas:** (IDs ou —)
+
+## Investigações estruturadas (opcional)
+
+- **investigations_ref:** `.oxe/INVESTIGATIONS.md` ou índice de sessão
+- **Última investigação:** (path ou —)
 
 ## Decisões persistentes
 

package/oxe/templates/WORKFLOW_AUTHORING.md

@@ -36,7 +36,7 @@ Mantenha tags **abertas e fechadas** explicitamente (evita ambiguidade para leit
 - Template opcional de pasta `docs/` brownfield: [`DOCS_BROWNFIELD_LAYOUT.md`](DOCS_BROWNFIELD_LAYOUT.md) (copiado para `.oxe/templates/` na instalação).
 - O `SKILL.md` principal do passo deve permanecer o **mapa**: objetivo, contexto essencial, sequência, critérios de sucesso.
 
-## 4. Comandos Cursor e prompts Copilot (frontmatter)
+## 4. Comandos Cursor e prompts Copilot (frontmatter)
 
 Ficheiros em `.cursor/commands/` e `.github/prompts/` costumam ter YAML inicial:
 
@@ -49,23 +49,23 @@ description: Resumo de 5–8 palavras. Use quando o utilizador pedir X, Y ou Z.
 - **Resumo:** o que o passo faz.
 - **Gatilhos:** frases ou intenções que devem ativar o comando (evita disparar em tudo).
 
-O corpo do ficheiro deve **apontar** para o workflow em `oxe/workflows/<passo>.md` (ou `.oxe/workflows/`) sem duplicar a lógica por completo.
-
-### Metadata cognitiva multi-runtime
-
-Prompts e wrappers OXE podem carregar metadata adicional para sincronizar a postura de raciocínio entre runtimes:
-
-```yaml
-oxe_reasoning_mode: discovery | planning | execution | review | status
-oxe_question_policy: explore_first | ask_high_impact_only | none
-oxe_output_contract: situational | plan | execution | findings | routing
-oxe_tool_profile: read_heavy | write_bounded | review_heavy | mixed
-oxe_confidence_policy: explicit | rubric | optional
-```
-
-- Use a mesma metadata em `.github/prompts/` e `commands/oxe/`.
-- O corpo do wrapper deve incluir um bloco curto de **Contrato de raciocínio OXE deste comando** consistente com essa metadata.
-- Cursor, Codex e CLIs derivados devem preservar essa semântica; não manter regras cognitivas importantes só numa integração.
+O corpo do ficheiro deve **apontar** para o workflow em `oxe/workflows/<passo>.md` (ou `.oxe/workflows/`) sem duplicar a lógica por completo.
+
+### Metadata cognitiva multi-runtime
+
+Prompts e wrappers OXE podem carregar metadata adicional para sincronizar a postura de raciocínio entre runtimes:
+
+```yaml
+oxe_reasoning_mode: discovery | planning | execution | review | status
+oxe_question_policy: explore_first | ask_high_impact_only | none
+oxe_output_contract: situational | plan | execution | findings | routing
+oxe_tool_profile: read_heavy | write_bounded | review_heavy | mixed
+oxe_confidence_policy: explicit | rubric | optional
+```
+
+- Use a mesma metadata em `.github/prompts/` e `commands/oxe/`.
+- O corpo do wrapper deve incluir um bloco curto de **Contrato de raciocínio OXE deste comando** consistente com essa metadata.
+- Cursor, Codex e CLIs derivados devem preservar essa semântica; não manter regras cognitivas importantes só numa integração.
 
 ## 5. Script vs agente
 

package/oxe/workflows/ask.md

@@ -1,92 +1,96 @@
-# 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>
-- 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>