oxe-cc 0.6.4 → 0.6.6

package/oxe/templates/PLAN.template.md

@@ -14,13 +14,28 @@ inputs: []
 
 > Gerado a partir de `.oxe/SPEC.md`. Cada tarefa deve ter bloco **Verificar**.
 
-## Resumo
-
-- **Spec vinculada:** (data ou versão informal)
-- **Ondas:** (número)
-- **Tarefas:** (número)
-
-## Dependências globais
+## Resumo
+
+- **Spec vinculada:** (data ou versão informal)
+- **Ondas:** (número)
+- **Tarefas:** (número)
+
+## Autoavaliação do Plano
+
+- **Melhor plano atual:** sim
+- **Confiança:** 80%
+- **Base da confiança:**
+  - Completude dos requisitos: 20/25
+  - Dependências conhecidas: 12/15
+  - Risco técnico: 15/20
+  - Impacto no código existente: 12/15
+  - Clareza da validação / testes: 13/15
+  - Lacunas externas / decisões pendentes: 8/10
+- **Principais incertezas:** (0–3 bullets)
+- **Alternativas descartadas:** (1–2 linhas)
+- **Condição para replanejar:** (critério objetivo)
+
+## Dependências globais
 
 - (ex.: branch base, feature flags, migrations)
 

package/oxe/templates/SESSION.template.md

@@ -0,0 +1,32 @@
+# Session sNNN — <nome>
+
+## Metadados
+
+- **ID:** sNNN
+- **Nome:** <nome>
+- **Status:** active
+- **Criada:** YYYY-MM-DD
+- **Última atividade:** YYYY-MM-DD
+- **Resumo:** <uma linha>
+
+## Í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/STATE.md

@@ -1,10 +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`
-
-## Ú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)

package/oxe/templates/config.template.json

@@ -2,8 +2,9 @@
   "_comment": "OXE config — copie para .oxe/config.json no seu projeto. Remova esta linha.",
   "profile": "balanced",
   "discuss_before_plan": false,
-  "verification_depth": "standard",
-  "security_in_verify": false,
+  "verification_depth": "standard",
+  "plan_confidence_threshold": 70,
+  "security_in_verify": false,
   "after_verify_suggest_pr": true,
   "after_verify_draft_commit": true,
   "after_verify_suggest_uat": false,

package/oxe/workflows/ask.md

@@ -0,0 +1,62 @@
+# OXE — Workflow: ask
+
+<objective>
+Responder perguntas sobre a situação atual do trabalho OXE com máxima robustez, usando o contexto real do repositório, a sessão ativa quando existir, e os artefatos mais recentes da trilha.
+</objective>
+
+<context>
+- Resolver `active_session` via `oxe/workflows/references/session-path-resolution.md`.
+- Ler sempre `.oxe/STATE.md` global primeiro.
+- Com sessão ativa, priorizar artefatos em `.oxe/<active_session>/...` antes do modo legado.
+- Usar `.oxe/codebase/` como mapa do repositório, não como substituto dos artefatos da trilha.
+- Se a pergunta estiver ambígua, responder em modo “situação atual + próximos riscos + melhor próxima ação”.
+</context>
+
+<process>
+1. Ler `.oxe/STATE.md` global e determinar se há `active_session`.
+2. Se houver sessão ativa, ler nesta ordem:
+   - `SESSION.md`
+   - `spec/SPEC.md`, `spec/ROADMAP.md`, `spec/DISCUSS.md`, `spec/UI-SPEC.md` se existirem
+   - `plan/PLAN.md`, `plan/QUICK.md`, `plan/plan-agents.json`, `plan/quick-agents.json` se existirem
+   - `execution/STATE.md`, `execution/OBSERVATIONS.md`, `execution/DEBUG.md`, `execution/FORENSICS.md`, `execution/SUMMARY.md` se existirem
+   - `verification/VERIFY.md`, `verification/VALIDATION-GAPS.md`, `verification/SECURITY.md`, `verification/UI-REVIEW.md` se existirem
+3. Sem sessão ativa, ler o equivalente legado na raiz `.oxe/`.
+4. Em ambos os casos, ler também:
+   - `.oxe/codebase/OVERVIEW.md`
+   - `.oxe/codebase/STACK.md`
+   - `.oxe/codebase/CONCERNS.md`
+   - `.oxe/global/LESSONS.md` se existir, com fallback para `.oxe/LESSONS.md`
+   - `.oxe/SESSIONS.md` se a pergunta mencionar sessões, histórico ou retomada
+5. Responder à pergunta do utilizador com base em evidência explícita dos artefatos lidos.
+6. Se faltar artefato crítico para responder com segurança, dizer exatamente o que falta e qual comando OXE fecha essa lacuna.
+
+## Modo diagnóstico padrão
+
+Se o utilizador só disser algo genérico como “o que está acontecendo?”, “qual a situação?” ou “me contextualize”, responder com:
+
+- **Situação atual**
+- **Escopo ativo**
+- **Artefatos relevantes**
+- **Riscos ou lacunas**
+- **Próximo passo recomendado**
+
+## Regras de robustez
+
+- Não assumir que `doctor` ou `status` sejam session-aware; eles não substituem a leitura direta dos artefatos da sessão.
+- Se houver conflito entre `.oxe/STATE.md` global e `execution/STATE.md` da sessão, explicitar o conflito.
+- Se `VERIFY.md` existir e contradizer o estado declarado, priorizar a evidência do `VERIFY.md` e mencionar a incoerência.
+- Se o mapa `.oxe/codebase/` estiver ausente ou incompleto, dizer isso explicitamente antes de extrapolar sobre o repositório.
+</process>
+
+<output>
+- Resposta direta à pergunta do utilizador
+- Referência curta aos artefatos usados
+- Quando necessário, um único próximo passo OXE
+</output>
+
+<success_criteria>
+- [ ] A resposta parte de `.oxe/STATE.md` global e resolve corretamente a sessão ativa quando existir.
+- [ ] O contexto da sessão ativa tem precedência sobre artefatos legados.
+- [ ] Conflitos ou lacunas entre artefatos são explicitados.
+- [ ] A saída responde à pergunta sem inventar estado que não esteja nos arquivos.
+</success_criteria>

package/oxe/workflows/checkpoint.md

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

package/oxe/workflows/debug.md

@@ -8,13 +8,14 @@ Diferente de **`verify`**, que audita **aceite** contra SPEC/PLAN. Depois de est
 
 <context>
 - Pré-requisito: sintoma reproduzível ou descrição clara (mensagem de erro, Tn em falha).
-- Preferir ancorar ao identificador de tarefa **`Tn`** do `.oxe/PLAN.md` quando existir.
-- Artefato: **`.oxe/DEBUG.md`** — ficheiro único com **sessões** datadas (append); não dispersar em vários ficheiros sem convenção.
+- Preferir ancorar ao identificador de tarefa **`Tn`** do `PLAN.md` do escopo resolvido quando existir.
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, usar `.oxe/<active_session>/execution/DEBUG.md`; sem sessão ativa, usar `.oxe/DEBUG.md`.
+- Artefato: **`DEBUG.md`** no escopo correto — ficheiro único com **sessões** datadas (append); não dispersar em vários ficheiros sem convenção.
 </context>
 
 <process>
-1. Ler `.oxe/PLAN.md` e `.oxe/STATE.md`; se o foco for uma tarefa, localizar **Tn** e o bloco **Verificar**.
-2. Registar em **`.oxe/DEBUG.md`** uma nova sessão:
+1. Ler `PLAN.md` do escopo resolvido e `.oxe/STATE.md`; se o foco for uma tarefa, localizar **Tn** e o bloco **Verificar**.
+2. Registar em **`DEBUG.md`** do escopo resolvido uma nova sessão:
    - **Data** / **Sintoma** (com stack ou comando que falhou).
    - **Hipóteses** (ordenadas por plausibilidade).
    - **Experiências** — o que foi tentado e resultado (uma linha cada).
@@ -25,7 +26,7 @@ Diferente de **`verify`**, que audita **aceite** contra SPEC/PLAN. Depois de est
 </process>
 
 <success_criteria>
-- [ ] `.oxe/DEBUG.md` contém sessão datada com sintoma e **Próximo passo** explícito.
+- [ ] `DEBUG.md` no escopo correto contém sessão datada com sintoma e **Próximo passo** explícito.
 - [ ] Quando aplicável, a sessão referencia **Tn** do PLAN.
 - [ ] Não se confunde com verify: não se declara “entrega aprovada” só com debug.
 </success_criteria>

package/oxe/workflows/discuss.md

@@ -6,9 +6,10 @@ 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>
-- Ler `.oxe/SPEC.md`, `.oxe/STATE.md` e trechos relevantes de `.oxe/codebase/OVERVIEW.md` / `STACK.md`.
-- Se existir **`.oxe/OBSERVATIONS.md`** 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.
+<context>
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, usar `.oxe/<active_session>/spec/` para `SPEC.md` e `DISCUSS.md`; sem sessão ativa, manter `.oxe/`.
+- Ler `SPEC.md` do escopo resolvido, `.oxe/STATE.md` e trechos relevantes de `.oxe/codebase/OVERVIEW.md` / `STACK.md`.
+- Se existir `OBSERVATIONS.md` do escopo resolvido com entradas `pendente` de impacto `spec`, `plan` ou `all`, carregá-las como contexto adicional para as perguntas e decisões; marcá-las `incorporada → discuss (data)` após uso.
 - Se existir **`.oxe/NOTES.md`**, rever bullets em aberto: promover para perguntas/decisões em `DISCUSS.md` ou marcar como *descartado* / *adiado* com uma linha de justificativa.
 - Se `.oxe/config.json` existir e `discuss_before_plan` for `true`, tratar este passo como **recomendado** antes de `oxe:plan`.
 </context>
@@ -25,16 +26,16 @@ Regras:
 </decision_ids>
 
 <process>
-1. Se não existir `.oxe/SPEC.md`, pedir **spec** primeiro (ou **quick** se for trabalho trivial).
+1. Se não existir `SPEC.md` no escopo resolvido, pedir **spec** primeiro (ou **quick** se for trabalho trivial).
 2. Se existir **`.oxe/NOTES.md`**, rever bullets em aberto e decidir o que entra em **Perguntas** ou **Decisões** (ou marcar *descartado* / *adiado* com justificativa curta).
 3. Identificar **lacunas** (escopo, dados, UX, edge cases, compatibilidade) — no máximo **7** perguntas objetivas.
-4. Criar ou atualizar **`.oxe/DISCUSS.md`** com estrutura fixa:
+4. Criar ou atualizar **`DISCUSS.md`** no escopo resolvido com estrutura fixa:
    - **Contexto** — 2–4 bullets do que já se sabe da SPEC.
    - **Perguntas** — numeradas; para cada uma: resposta (se o usuário já respondeu na mensagem) ou `_(pendente)_`.
    - **Decisões** — tabela com colunas **ID** / **Decisão** / **Data** / **Impacto no plano** (só as já fechadas). Atribuir IDs **D-01**, **D-02**, … em sequência.
    - **Implicações para o plano** — bullets (ex.: "migrations necessárias", "feature flag").
 5. Se ainda houver perguntas **pendentes** críticas, listá-las no chat (máx. 7) e parar até resposta; depois atualizar DISCUSS.md.
-6. Atualizar **`.oxe/STATE.md`**: fase `discuss_complete`, próximo passo `oxe:plan`. Registrar os IDs de decisão na seção **Decisões persistentes** do STATE (ex.: `D-01: escolheu JWT — 2025-01-15`).
+6. Atualizar **`.oxe/STATE.md`** global: fase `discuss_complete`, próximo passo `oxe:plan`. Registrar os IDs de decisão na seção **Decisões persistentes** do STATE (ex.: `D-01: escolheu JWT — 2025-01-15`).
 7. Resumo no chat em ≤8 linhas, listando decisões com seus IDs.
 </process>
 
@@ -69,7 +70,7 @@ updated: YYYY-MM-DD
 </discuss_md_format>
 
 <success_criteria>
-- [ ] `.oxe/DISCUSS.md` existe com perguntas e decisões alinhadas à SPEC.
+- [ ] `DISCUSS.md` existe no escopo correto com perguntas e decisões alinhadas à SPEC.
 - [ ] Cada decisão fechada tem ID único **D-NN** na tabela de Decisões.
 - [ ] Se existir `.oxe/NOTES.md`, as entradas relevantes foram tratadas (promovidas, descartadas ou adiadas com nota).
 - [ ] Nenhuma ambiguidade crítica ficou sem registro (como pendente ou suposição explícita na SPEC).

package/oxe/workflows/execute.md

@@ -3,13 +3,13 @@
 <objective>
 Guiar a **implementação** de um plano OXE com dois modos possíveis:
 
-**Modo Solo (padrão):** seguir `.oxe/PLAN.md` onda a onda sem `plan-agents.json`. O agente implementa diretamente cada tarefa Tn da onda atual, roda a verificação e avança. Não exige nenhum artefato além do PLAN.md.
+**Modo Solo (padrão):** seguir `PLAN.md` do escopo resolvido da sessão onda a onda sem `plan-agents.json`. O agente implementa diretamente cada tarefa Tn da onda atual, roda a verificação e avança. Não exige nenhum artefato além do PLAN.md.
 
-**Modo com Agentes (extensão):** quando existe `.oxe/plan-agents.json` válido (schema 2, lifecycle ativo, runId alinhado ao STATE), adotar roles e personas por agente conforme o blueprint.
+**Modo com Agentes (extensão):** quando existe `plan-agents.json` válido no escopo resolvido (schema 2+, lifecycle ativo, runId alinhado ao STATE), adotar roles e personas por agente conforme o blueprint.
 
 **Seleção de execução (redução de requisições):** quando o plano tem 2+ ondas, o usuário escolhe entre Completo (1 sessão), Por onda (N sessões) ou Por tarefa (N tarefas). A escolha é feita **uma vez** no início.
 
-Se existir apenas **`.oxe/QUICK.md`**: tratar passos numerados como onda única (modo sempre Completo).
+Se existir apenas **`QUICK.md`** no escopo resolvido: tratar passos numerados como onda única (modo sempre Completo).
 </objective>
 
 <modo_solo>
@@ -32,6 +32,8 @@ O modo padrão. Funciona sem `plan-agents.json`. O agente lê PLAN.md, segue as
 <execution_mode_selection>
 ## Seleção de Modo de Execução
 
+**Argumento direto:** se o foco/argumento recebido já for `A`, `B` ou `C` (sozinho), usar diretamente como seleção de modo sem apresentar o menu.
+
 **Quando aplicar:** ao início do execute, se PLAN.md tiver **2 ou mais ondas**. Apresentar UMA VEZ e armazenar a escolha em STATE.md para não perguntar novamente nas rodadas seguintes.
 
 **Não aplicar** quando: QUICK.md (sempre Completo), PLAN.md com 1 onda (executar diretamente).
@@ -87,10 +89,12 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 **Auto-loop no Modo B:** se `execute_mode: por_onda` e `loop_max` > 1 em STATE.md, o ciclo de retry roda automaticamente até `loop_max` tentativas antes de escalar para forensics.
 </failure_mode>
 
-<context>
-**Observações pendentes:** verificar `.oxe/OBSERVATIONS.md` no início de cada onda. Se houver entradas `pendente` com impacto `execute` ou `all`, incorporar no trabalho da onda atual e marcá-las `incorporada → execute (data)`.
+<context>
+**Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de executar, validar os artefatos obrigatórios e o gate do plano.
+
+**Observações pendentes:** verificar `OBSERVATIONS.md` do escopo resolvido no início de cada onda. Se houver entradas `pendente` com impacto `execute` ou `all`, incorporar no trabalho da onda atual e marcá-las `incorporada → execute (data)`.
 
-**Quick-agents (lean PDDA):** se existir **`.oxe/quick-agents.json`** com `status: active` e a execução for baseada em **`QUICK.md`** (não há PLAN.md), adotar o `role` e `persona` de cada agente para os `steps[]` atribuídos. Ao concluir todos os steps, marcar `quick-agents.json` → `status: done` e sugerir `/oxe-verify`.
+**Quick-agents (lean PDDA):** se existir **`quick-agents.json`** do escopo resolvido com `status: active` e a execução for baseada em **`QUICK.md`** (não há PLAN.md), adotar o `role` e `persona` de cada agente para os `steps[]` atribuídos. Ao concluir todos os steps, marcar `quick-agents.json` → `status: done` e sugerir `/oxe-verify`.
 
 **Model hints (blueprint com agentes):** ao apresentar a atribuição de cada agente no início da onda, exibir `model_hint` se presente:
 ```
@@ -99,7 +103,7 @@ Tarefas: T1, T2
 ```
 Se `model_hint` estiver ausente, não exibir a linha. O usuário pode configurar o modelo no IDE antes de iniciar aquele agente.
 
-**Blueprint plan-agent (Modo com Agentes):** adotar `role`/`scope` de **`.oxe/plan-agents.json`** SOMENTE quando:
+**Blueprint plan-agent (Modo com Agentes):** adotar `role`/`scope` de **`plan-agents.json`** do escopo resolvido SOMENTE quando:
 1. `lifecycle.status` ∈ `{ pending_execute, executing }` (não usar se `closed` ou `invalidated`).
 2. **`runId`** no JSON coincide com **`run_id`** no STATE.md (secção Blueprint de agentes).
 3. O pedido mapeia para pelo menos uma tarefa **`Tn`** no **`PLAN.md`**.
@@ -108,7 +112,7 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 
 **Transição `pending_execute` → `executing`:** na primeira onda com blueprint válido, atualizar `plan-agents.json` → `lifecycle: { "status": "executing", "since": "<ISO>" }` e espelhar em STATE.md.
 
-**Protocolo agente → agente (blueprint):** mensagens em `.oxe/plan-agent-messages/` conforme `oxe/workflows/references/plan-agent-chat-protocol.md`.
+**Protocolo agente → agente (blueprint):** mensagens em `plan-agent-messages/` do escopo resolvido conforme `oxe/workflows/references/plan-agent-chat-protocol.md`.
 
 **Se PLAN.md não existir mas QUICK.md existir:** seguir QUICK.md — passos = onda única, sempre Modo Completo.
 
@@ -119,26 +123,31 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
 **Rotina compact/checkpoint:** antes de onda experimental ou refactor grande, `/oxe-checkpoint` com slug ajuda a retomar. Após ondas que mudem stack ou árvore, lembrar `/oxe-compact`.
 </context>
 
-<process>
-1. Ler **`.oxe/STATE.md`**, **`PLAN.md`** (se existir) e **`QUICK.md`** (se PLAN não existir).
-2. Verificar **`.oxe/OBSERVATIONS.md`** — incorporar pendentes de impacto `execute` ou `all` antes de iniciar.
-3. **Seleção de modo** (apenas se PLAN.md com 2+ ondas e `execute_mode` não definido em STATE): apresentar opções A/B/C e aguardar escolha; registrar em STATE.md.
-4. Identificar **onda ou bloco atual**: no PLAN, todas as tarefas da mesma onda sem dependências pendentes; no QUICK, passos ainda não marcados como feitos.
-5. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
-6. **Implementar** conforme o modo escolhido:
-   - **Modo Completo:** executar todas as ondas em sequência com verificação inline entre ondas; sumarizar ao final.
-   - **Modo Por onda:** executar onda atual, apresentar checklist, parar.
-   - **Modo Por tarefa:** executar próxima tarefa pendente, parar.
-7. Após cada onda concluída, incluir checklist:
-   ```markdown
-   ## Checklist — Onda N (OXE)
-   - [ ] Pré-requisitos da onda conferidos (dependências Tk atendidas)
-   - [ ] Implementação da onda concluída
-   - [ ] Comando Verificar de cada tarefa executado (ou agendado)
-   ```
-8. Atualizar **`.oxe/STATE.md`**: última onda executada, tarefas concluídas (Tn), próximo passo.
-9. Marcar OBS incorporadas como `incorporada → execute (data)` em `.oxe/OBSERVATIONS.md`.
-</process>
+<process>
+1. Ler **`.oxe/STATE.md`** global para resolver `active_session`, depois ler **`PLAN.md`** (se existir) e **`QUICK.md`** do escopo resolvido.
+2. Se existir `PLAN.md`, validar a seção `## Autoavaliação do Plano` antes de qualquer implementação:
+   - `Melhor plano atual` deve ser `sim`;
+   - `Confiança` deve existir em `0–100%`;
+   - se `.oxe/config.json` definir `plan_confidence_threshold`, usar esse limiar; senão, usar `70%`;
+   - se a confiança estiver abaixo do limiar, **não executar**. Registrar o bloqueio e orientar redução de incerteza (`/oxe-discuss`, `/oxe-research` ou `/oxe-plan --replan`).
+3. Verificar **`OBSERVATIONS.md`** do escopo resolvido — incorporar pendentes de impacto `execute` ou `all` antes de iniciar.
+4. **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.
+5. 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.
+6. Listar no chat: tarefas/passos desta onda, arquivos prováveis, comando **Verificar** de cada tarefa.
+7. **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.
+8. 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)
+   ```
+9. Atualizar **`.oxe/STATE.md`** global com progresso resumido e, com sessão ativa, escrever o detalhe operacional em `execution/STATE.md`.
+10. Marcar OBS incorporadas como `incorporada → execute (data)` em `OBSERVATIONS.md` do escopo resolvido.
+</process>
 
 <success_criteria>
 - [ ] Modo de execução foi selecionado (ou herdado do STATE) antes de implementar.

package/oxe/workflows/forensics.md

@@ -1,14 +1,14 @@
 # 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 **`.oxe/FORENSICS.md`** 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>
-- 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.
-- Ler: `.oxe/STATE.md`, `.oxe/VERIFY.md` (se existir), `.oxe/PLAN.md`, `.oxe/SPEC.md` (se existir), `.oxe/QUICK.md` (se existir).
+- Usar quando: `VERIFY.md` com falhas ou gaps não explicados, `oxe-cc doctor` com **FALHA**, `STATE.md` contradiz ficheiros presentes (ex.: “onda concluída” sem `VERIFY.md`), ou o utilizador indica estar **preso** após várias tentativas de replan.
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`; ler `.oxe/STATE.md` global e os artefatos de sessão (`VERIFY.md`, `PLAN.md`, `SPEC.md`, `QUICK.md`) no escopo resolvido.
 - **Git é opcional:** em sandbox sem Git ou sem permissão de terminal, **não** falhar o workflow; registar em `FORENSICS.md` que Git não foi avaliado.
 - Opcional: saída resumida de `npx oxe-cc doctor` no diretório do projeto.
 - 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`.
@@ -25,18 +25,18 @@ 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 **`.oxe/FORENSICS.md`** com secções fixas:
+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`** 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).
+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>
 
 <success_criteria>
-- [ ] `.oxe/FORENSICS.md` existe 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

@@ -11,24 +11,42 @@ No **projeto**, os passos canónicos estão em **`.oxe/workflows/*.md`** (layout
 </context>
 
 <output>
-## Os 8 comandos essenciais
+## Comandos principais
 
 ```
-/oxe              → onde estou / o que faço / help (entrada universal)
-/oxe-obs          → registrei algo importante — incorporado automaticamente nos próximos passos
-/oxe-quick        → tarefa pequena, sem cerimônia (com agentes lean quando necessário)
-/oxe-scan         → mapeia o projeto (ou atualiza o mapa se já existir)
+/oxe              → onde estou / o que faço / help (entrada universal)
+/oxe-ask          → entender a situação atual com leitura robusta de STATE + sessão + artefatos
+/oxe-obs          → registrei algo importante — incorporado automaticamente nos próximos passos
+/oxe-quick        → tarefa pequena, sem cerimônia (com agentes lean quando necessário)
+/oxe-session      → criar, alternar, retomar, fechar ou migrar sessões OXE
+/oxe-scan         → mapeia o projeto (ou atualiza o mapa se já existir)
 /oxe-spec         → nova feature: perguntas → pesquisa → requisitos → roteiro → aprovação
 /oxe-plan         → tarefas por onda (--agents para blueprint multi-agente)
 /oxe-execute      → implementar (A: 1 sessão | B: por onda | C: por tarefa)
 /oxe-verify       → validar (camadas 5+6 opcionais via config: gaps + segurança)
 ```
 
-Tudo o mais é ativado automaticamente por contexto, por config, ou existe como escape hatch.
+Tudo o mais é ativado automaticamente por contexto, por config, ou existe como escape hatch.
 
 ---
 
-## Integrações principais (referência)
+## Sessões OXE
+
+- `active_session` em `.oxe/STATE.md` define a sessão ativa com path relativo completo (`sessions/sNNN-slug`).
+- Com sessão ativa, workflows de spec/plan/execute/verify e suportes ligados à trilha escrevem em `.oxe/<active_session>/...`.
+- Permanecem globais: `.oxe/STATE.md`, `.oxe/config.json`, `.oxe/codebase/`, `.oxe/SESSIONS.md`, `.oxe/global/LESSONS.md`, `.oxe/global/MILESTONES.md`.
+- `oxe-cc status` / `doctor` devem refletir a sessão ativa, a autoavaliação do plano e a saúde lógica do fluxo.
+
+### `/oxe-session`
+
+- `new <nome>` — cria `.oxe/sessions/sNNN-slug/` e ativa a sessão
+- `list` — mostra `.oxe/SESSIONS.md`
+- `switch <id>` / `resume <id>` — alterna a sessão ativa
+- `status` — mostra o manifesto `SESSION.md`
+- `close` — arquiva a sessão ativa
+- `migrate <nome>` — move artefatos session-scoped da raiz para uma nova sessão
+
+## Integrações principais (referência)
 
 ### Cursor
 
@@ -72,8 +90,8 @@ Com **`compact_max_age_days`** em `.oxe/config.json` (ver `oxe/templates/CONFIG.
 1. **scan** — após clonar ou quando o codebase mudar. **Inteligente:** se `.oxe/codebase/` já existir, opera em modo refresh (incremental) automaticamente — sem precisar chamar `/oxe-compact` separadamente. Use `--full` para forçar scan completo. Repositórios **legado** (COBOL, JCL, VB6): aplica `legacy-brownfield.md` automaticamente.
 2. **spec** — fluxo em **5 fases**: perguntas (máx 3 rodadas) → pesquisa (proposta inline na Fase 2, sem sair do spec) → requisitos R-ID (v1/v2/fora) → roteiro (`.oxe/ROADMAP.md`) → aprovação. Se `discuss_before_plan: true` na config, o próximo passo após aprovação é `oxe:discuss` antes de plan.
 3. **plan** — plano executável + **Verificar** por tarefa. Se 3+ domínios distintos, **sugere automaticamente** blueprint de agentes (`/oxe-plan --agents`). Sem `--agents`: solo. Com `--agents`: gera também `plan-agents.json` (schema 3 com `model_hint`).
-4. **execute** — modo selecionado 1 vez: **A) Completo** (1 sessão), **B) Por onda**, **C) Por tarefa**. Se Verificar falhar inline: diagnóstico automático (2-3 hipóteses + fix), sem precisar chamar `/oxe-debug` separadamente. Escalação para `/oxe-forensics` só se esgotar tentativas.
-5. **verify** — até **6 camadas** por config: auditoria pré-exec, tarefas + critérios A*, fidelidade D-NN, UAT, **gaps de cobertura** (camada 5 — `verification_depth: "thorough"`), **segurança OWASP** (camada 6 — `security_in_verify: true`). Sem comandos extras.
+4. **execute** — modo selecionado 1 vez: **A) Completo** (1 sessão), **B) Por onda**, **C) Por tarefa**. Antes de executar, validar a **Autoavaliação do Plano**: se `Melhor plano atual: não` ou a confiança estiver abaixo do limiar, o fluxo deve replanear em vez de implementar. Se Verificar falhar inline: diagnóstico automático (2-3 hipóteses + fix), sem precisar chamar `/oxe-debug` separadamente. Escalação para `/oxe-forensics` só se esgotar tentativas.
+5. **verify** — até **6 camadas** por config: auditoria pré-exec, tarefas + critérios A*, fidelidade D-NN, **calibração do plano**, UAT, **gaps de cobertura** (camada 5 — `verification_depth: "thorough"`), **segurança OWASP** (camada 6 — `security_in_verify: true`). Sem comandos extras.
 6. **retro** *(opcional, recomendado após verify_complete)* — `/oxe-retro` sintetiza 3–5 lições prescritivas em `.oxe/LESSONS.md`. Cada lição diz **o que fazer diferente** no próximo ciclo — consumida automaticamente pelo próximo spec/plan.
 7. **→ próximo ciclo** — spec/plan do próximo ciclo lê LESSONS.md automaticamente. Os erros do ciclo anterior não se repetem.
 
@@ -115,14 +133,15 @@ Um único comando para: `milestone new|complete|status|audit`, `workstream new|s
 
 - **`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`**).
-- **`oxe-cc doctor`** — Node, workflows do pacote vs projeto, `config.json`, mapas do codebase, **coerência STATE vs arquivos**, scan antigo (`scan_max_age_days`), compact antigo (`compact_max_age_days`), seções SPEC, ondas do PLAN, **avisos** não bloqueantes sobre estrutura dos `.md` de workflow (ex.: `<objective>`, critérios de sucesso).
-- **`oxe-cc status`** — coerência `.oxe/` + **um** próximo passo (espelha `next.md`). Com **`--json`**, uma linha JSON com **`oxeStatusSchema: 2`**, `nextStep`, `cursorCmd`, `reason`, `artifacts`, `phase`, `scanDate`, `staleScan`, `compactDate`, `staleCompact`, `diagnostics` (e com **`--json --hints`** também o array **`hints`**). Com **`--hints`** em modo texto, bloco **Lembretes (rotina OXE)** (scan/compact antigos quando `scan_max_age_days` / `compact_max_age_days` estão ativos em `config.json`).
-- **`oxe-cc init-oxe`** — só bootstrap `.oxe/` (STATE, config, codebase).
-- **`oxe-cc uninstall`** — remove integrações no HOME e, por omissão, pastas de workflows no repo (`--ide-only` só HOME).
-- **`/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.
+- **`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 **`--json`**, uma linha JSON com `healthStatus`, `activeSession`, `planSelfEvaluation` e `diagnostics` completos além do próximo passo. Com **`--hints`** em modo texto, bloco **Lembretes (rotina OXE)** (scan/compact antigos quando `scan_max_age_days` / `compact_max_age_days` estão ativos em `config.json`).
+- **`oxe-cc init-oxe`** — só bootstrap `.oxe/` (STATE, config, codebase).
+- **`oxe-cc uninstall`** — remove integrações no HOME e, por omissão, pastas de workflows no repo (`--ide-only` só HOME).
+- **`oxe-cc uninstall --global-cli`** — além da limpeza dos artefatos OXE, executa `npm uninstall -g oxe-cc` para remover o binário global do PATH.
+- **`/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`.
 
 **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`.
 
@@ -136,8 +155,9 @@ Um pedido → **um** destino (sem gerar contrato). O agente aplica `route.md` ou
 
 | Se o utilizador disser (exemplos) | Comando / ação |
 |-----------------------------------|----------------|
-| Não sei que passo OXE sou / “o que faço agora?” | `/oxe-next` ou `npx oxe-cc status` |
-| Acabei de clonar / falta OXE no projeto | `npx oxe-cc@latest` (ou `oxe-cc`) na raiz do repo |
+| Não sei que passo OXE sou / “o que faço agora?” | `/oxe-next` ou `npx oxe-cc status` |
+| Quero entender rapidamente a situação real da trilha atual | `/oxe-ask [pergunta]` |
+| Acabei de clonar / falta OXE no projeto | `npx oxe-cc@latest` (ou `oxe-cc`) na raiz do repo |
 | Verify falhou várias vezes / doctor estranho / artefatos incoerentes | `/oxe-forensics` |
 | Teste ou erro técnico durante o trabalho (stack, flake) | `/oxe-debug` (com **Tn** se houver) |
 | Revisar diff / PR antes do merge | `oxe/workflows/review-pr.md` em contexto *(Copilot: `/oxe-review-pr`)* |

package/oxe/workflows/milestone.md

@@ -10,9 +10,10 @@ Subcomandos:
 - `/oxe-milestone audit` — verificar se o milestone atingiu sua definição de pronto.
 </objective>
 
-<context>
-- Milestone ≠ Checkpoint. **Checkpoint** (`/oxe-checkpoint`) é um snapshot de sessão — restaurável a qualquer momento. **Milestone** é uma entrega — marcador de versão com artefatos arquivados e critérios de pronto validados.
-- Milestones são rastreados em **`.oxe/MILESTONES.md`** (índice) e cada entrega tem uma entrada com status, data e links aos artefatos.
+<context>
+- Milestone ≠ Checkpoint. **Checkpoint** (`/oxe-checkpoint`) é um snapshot de sessão — restaurável a qualquer momento. **Milestone** é uma entrega — marcador de versão com artefatos arquivados e critérios de pronto validados.
+- Nesta versão, milestones são **globais**: usar `.oxe/global/MILESTONES.md` e `.oxe/global/milestones/`, ignorando `active_session` para escrita do índice global.
+- Milestones são rastreados em **`.oxe/global/MILESTONES.md`** (índice) e cada entrega tem uma entrada com status, data e links aos artefatos.
 - O milestone ativo é registrado no **STATE.md** na seção **Milestone ativo**.
 - Um milestone é considerado **pronto** quando:
   1. Todos os critérios A* da SPEC estão com `verify_complete` no STATE.
@@ -26,7 +27,7 @@ Subcomandos:
 
 1. Verificar se há milestone ativo em STATE.md. Se houver, alertar e pedir confirmação antes de criar novo.
 2. Gerar ID sequencial: **M-01**, **M-02**, …
-3. Criar entrada em **`.oxe/MILESTONES.md`**:
+3. Criar entrada em **`.oxe/global/MILESTONES.md`**:
    ```markdown
    ## M-01 — [nome] (ativo)
    - **Status:** ativo
@@ -50,13 +51,11 @@ Pré-requisitos (verificar antes de executar):
 Se pré-requisitos não forem satisfeitos: listar os que faltam e pausar. Com `--force`: documentar pré-requisitos não satisfeitos e continuar com aviso.
 
 Passos:
-1. Arquivar artefatos do milestone:
-   - Copiar `.oxe/SPEC.md` → `.oxe/milestones/M-NN/SPEC.md`
-   - Copiar `.oxe/PLAN.md` → `.oxe/milestones/M-NN/PLAN.md`
-   - Copiar `.oxe/VERIFY.md` → `.oxe/milestones/M-NN/VERIFY.md`
-   - Copiar `.oxe/DISCUSS.md` → `.oxe/milestones/M-NN/DISCUSS.md` (se existir)
-   - Criar `.oxe/milestones/M-NN/MILESTONE.md` com resumo da entrega.
-2. Atualizar **`.oxe/MILESTONES.md`**: marcar milestone como `entregue`, adicionar data de encerramento e links aos artefatos arquivados.
+1. Arquivar artefatos do milestone:
+   - Copiar os artefatos do escopo ativo da sessão, se houver, para `.oxe/global/milestones/M-NN/`
+   - Sem sessão ativa, copiar da raiz `.oxe/`
+   - Criar `.oxe/global/milestones/M-NN/MILESTONE.md` com resumo da entrega.
+2. Atualizar **`.oxe/global/MILESTONES.md`**: marcar milestone como `entregue`, adicionar data de encerramento e links aos artefatos arquivados.
 3. Atualizar **STATE.md**: limpar seção **Milestone ativo**, registrar **Último milestone** com ID e data.
 4. Sugerir próximo milestone ou nova spec: `Milestone M-NN concluído. Próximos passos: /oxe-milestone new v2 | /oxe-spec | /oxe-checkpoint`.
 </process_complete>
@@ -65,7 +64,7 @@ Passos:
 **`/oxe-milestone status`**
 
 1. Ler STATE.md para identificar milestone ativo (ID e nome).
-2. Ler MILESTONES.md para detalhes.
+2. Ler `.oxe/global/MILESTONES.md` para detalhes.
 3. Ler SPEC.md para listar critérios A* e seu status (verificado / pendente).
 4. Ler VERIFY.md (se existir) para gaps abertos.
 5. Exibir no chat:
@@ -89,7 +88,7 @@ Resultado: `Milestone M-NN: PRONTO` ou lista de itens pendentes.
 </process_audit>
 
 <success_criteria>
-- [ ] `.oxe/MILESTONES.md` existe e tem entrada para o milestone ativo.
+- [ ] `.oxe/global/MILESTONES.md` existe e tem entrada para o milestone ativo.
 - [ ] STATE.md indica milestone ativo (ID e nome).
 - [ ] Ao completar: artefatos arquivados em `.oxe/milestones/M-NN/`.
 - [ ] Ao completar: MILESTONES.md atualizado com status `entregue` e data.