oxe-cc 0.6.2 → 0.6.5

package/oxe/workflows/help.md

@@ -16,19 +16,36 @@ No **projeto**, os passos canónicos estão em **`.oxe/workflows/*.md`** (layout
 ```
 /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-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`.
+- Nesta versão, o suporte é **workflows only**: `oxe-cc status` / `doctor` ainda não são session-aware.
+
+### `/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
 

package/oxe/workflows/loop.md

@@ -1,57 +1,57 @@
-# OXE — Workflow: loop (execução iterativa até verificação passar)
-
-<objective>
-Executar uma **onda do PLAN.md** em ciclo iterativo até que a verificação inline passe ou o limite de tentativas seja atingido. Complementa o **Modo B** (por onda) do **`execute.md`** com retries automáticos e diagnóstico inline de falhas.
-
-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`.
-- **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.
-- **Não substitui** `/oxe-verify` global (4 camadas): o loop faz verificação **inline por onda** (comando `**Verificar:**` de cada Tn); o verify completo deve ser chamado ao final de todas as ondas.
-</context>
-
-<loop_state>
-## Campos em STATE.md durante o loop
-
-```yaml
-loop_onda: 2              # número da onda sendo executada
-loop_iteracao: 2/3        # tentativa atual / máximo
-loop_status: retrying     # retrying | passed | escalated
-loop_hipoteses: ["H1: ...", "H2: ..."]  # hipóteses da última falha
-```
-
-Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalou para forensics).
-</loop_state>
-
-<process>
-1. Ler `.oxe/STATE.md` e `.oxe/PLAN.md`. Identificar a onda alvo (argumento do usuário ou próxima onda pendente em STATE).
-2. Registrar em STATE.md: `loop_onda: N`, `loop_iteracao: 1/<max>`, `loop_status: retrying`.
-3. **Iteração:**
-   a. Listar tarefas da onda N com seus comandos `**Verificar:**`.
-   b. Implementar todas as tarefas da onda (seguindo `execute.md` `<modo_solo>`).
-   c. Executar os comandos `Verificar` de cada `Tn`.
-   d. **Se todos passaram:** registrar `loop_status: passed`; limpar campos `loop_*`; atualizar STATE.md com onda concluída; informar usuário e sugerir próxima onda ou `/oxe-verify`.
-   e. **Se algum falhou:**
-      - Listar 2-3 hipóteses de causa (baseado no erro/output da verificação).
-      - Registrar `loop_hipoteses` em STATE.md.
-      - 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>
-
-<success_criteria>
-- [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.
-- [ ] Cada falha gera 2-3 hipóteses registradas antes de tentar fix.
-- [ ] Ao passar: campos `loop_*` limpos; onda marcada como concluída em STATE.md.
-- [ ] Ao esgotar: `loop_status: escalated` + sugestão de `/oxe-forensics` com contexto completo.
-- [ ] Nunca excede `max` iterações configurado.
-- [ ] Não altera `.oxe/PLAN.md` (só implementa o que já está planejado).
-</success_criteria>
+# OXE — Workflow: loop (execução iterativa até verificação passar)
+
+<objective>
+Executar uma **onda do PLAN.md** em ciclo iterativo até que a verificação inline passe ou o limite de tentativas seja atingido. Complementa o **Modo B** (por onda) do **`execute.md`** com retries automáticos e diagnóstico inline de falhas.
+
+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`.
+- **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.
+- **Não substitui** `/oxe-verify` global (4 camadas): o loop faz verificação **inline por onda** (comando `**Verificar:**` de cada Tn); o verify completo deve ser chamado ao final de todas as ondas.
+</context>
+
+<loop_state>
+## Campos em STATE.md durante o loop
+
+```yaml
+loop_onda: 2              # número da onda sendo executada
+loop_iteracao: 2/3        # tentativa atual / máximo
+loop_status: retrying     # retrying | passed | escalated
+loop_hipoteses: ["H1: ...", "H2: ..."]  # hipóteses da última falha
+```
+
+Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalou para forensics).
+</loop_state>
+
+<process>
+1. Ler `.oxe/STATE.md` e `.oxe/PLAN.md`. Identificar a onda alvo (argumento do usuário ou próxima onda pendente em STATE).
+2. Registrar em STATE.md: `loop_onda: N`, `loop_iteracao: 1/<max>`, `loop_status: retrying`.
+3. **Iteração:**
+   a. Listar tarefas da onda N com seus comandos `**Verificar:**`.
+   b. Implementar todas as tarefas da onda (seguindo `execute.md` `<modo_solo>`).
+   c. Executar os comandos `Verificar` de cada `Tn`.
+   d. **Se todos passaram:** registrar `loop_status: passed`; limpar campos `loop_*`; atualizar STATE.md com onda concluída; informar usuário e sugerir próxima onda ou `/oxe-verify`.
+   e. **Se algum falhou:**
+      - Listar 2-3 hipóteses de causa (baseado no erro/output da verificação).
+      - Registrar `loop_hipoteses` em STATE.md.
+      - 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>
+
+<success_criteria>
+- [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.
+- [ ] Cada falha gera 2-3 hipóteses registradas antes de tentar fix.
+- [ ] Ao passar: campos `loop_*` limpos; onda marcada como concluída em STATE.md.
+- [ ] Ao esgotar: `loop_status: escalated` + sugestão de `/oxe-forensics` com contexto completo.
+- [ ] Nunca excede `max` iterações configurado.
+- [ ] Não altera `.oxe/PLAN.md` (só implementa o que já está planejado).
+</success_criteria>

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.

package/oxe/workflows/next.md

@@ -1,11 +1,12 @@
 # OXE — Workflow: next
 
 <objective>
-Inspecionar `.oxe/STATE.md` e a existência de `SPEC.md`, `PLAN.md`, `QUICK.md`, `VERIFY.md` e `.oxe/codebase/` para recomendar **exatamente um** próximo passo OXE e **uma** frase de justificativa — sem lista de alternativas equiparáveis.
+Inspecionar `.oxe/STATE.md` global, a sessão ativa quando existir, e a existência de `SPEC.md`, `PLAN.md`, `QUICK.md`, `VERIFY.md` e `.oxe/codebase/` para recomendar **exatamente um** próximo passo OXE e **uma** frase de justificativa — sem lista de alternativas equiparáveis.
 </objective>
 
 <context>
-- 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.
+- 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.
 - **Blueprint plan-agent:** se **`.oxe/plan-agents.json`** tiver `lifecycle.status === "invalidated"`, o próximo passo **não** assume papéis desse JSON; continuar a raciocinar só com **PLAN.md** / **QUICK.md** / **VERIFY.md** e **STATE.md**. Se o utilizador quiser de novo agentes + mensagens, indicar **`/oxe-plan-agent`**.
 </context>
@@ -13,9 +14,12 @@ Inspecionar `.oxe/STATE.md` e a existência de `SPEC.md`, `PLAN.md`, `QUICK.md`,
 <process>
 1. Se `.oxe/` ou `STATE.md` não existir → **único** passo: **scan** (ou `oxe-cc init-oxe` seguido de scan).
 2. Se não houver `.oxe/codebase/*.md` completos (sete mapas) e o trabalho **não** for só um quick isolado → **scan**.
-3. Se fase `quick_active` ou existir `QUICK.md` **sem** `PLAN.md` → se o `QUICK.md` tiver **mais de 10 passos**, ou o utilizador/descrição indicar **contrato público**, **segurança**, **dados pessoais**, ou **>8 ficheiros** tocados ou previstos → **spec** (promoção obrigatória, um único passo); senão → **execute** (há passos curtos a implementar) desde que o QUICK não declare **Promover para spec/plan?** `sim`.
-4. Se não houver `SPEC.md` e não for quick intencional declarado → **spec** (passo único).
-5. Se houver SPEC mas não PLAN → se `.oxe/config.json` tiver `discuss_before_plan: true` e faltar **`.oxe/DISCUSS.md`** com decisões → **discuss**; senão → **plan**.
+3. Se fase `quick_active` ou existir `QUICK.md` no escopo resolvido **sem** `PLAN.md`:
+   - Se `QUICK.md` contiver linha `Promover para spec/plan?: sim` → **spec** (promoção declarada pelo autor; ignorar demais heurísticas).
+   - Se o `QUICK.md` tiver **mais de 10 passos**, ou o utilizador/descrição indicar **contrato público**, **segurança**, **dados pessoais**, ou **>8 ficheiros** tocados ou previstos → **spec** (promoção obrigatória).
+   - Senão → **execute** (há passos curtos a implementar).
+4. Se não houver `SPEC.md` no escopo resolvido e não for quick intencional declarado → **spec** (passo único).
+5. Se houver SPEC no escopo resolvido mas não PLAN → se `.oxe/config.json` tiver `discuss_before_plan: true` e faltar **`DISCUSS.md`** com decisões → **discuss**; senão → **plan**.
 6. Se PLAN existe, **VERIFY.md** ainda **não** existe ou está claramente antes da implementação atual → **execute** (onda atual).
 7. Se PLAN existe e VERIFY falta após implementação declarada → **verify**.
 8. Se VERIFY indica falha ou gaps não resolvidos → **plan** (replanejamento) como passo único, com referência a `SUMMARY.md`.

package/oxe/workflows/obs.md

@@ -8,16 +8,17 @@ Registrar uma **observação contextual** em **`.oxe/OBSERVATIONS.md`** durante
 Entrada: texto livre com a observação (restrição, descoberta técnica, preferência, risco, decisão).
 </objective>
 
-<context>
+<context>
 - Pode ser chamado **a qualquer momento**: antes, durante ou após qualquer passo da trilha OXE.
 - Não interrompe o fluxo em curso — a observação é armazenada e incorporada na próxima oportunidade.
-- Se chamado **durante execute** (fase `executing` no STATE) com impacto `execute` ou `all`: oferecer opção de aplicar agora (pausar onda atual) ou continuar e aplicar na próxima rodada.
-- Ler **`.oxe/STATE.md`** para capturar o contexto automático (fase atual, tarefa ativa, workstream ativo).
-- Usar `oxe/templates/OBSERVATIONS.template.md` para criar o arquivo se ainda não existir.
-</context>
+- Se chamado **durante execute** (fase `executing` no STATE) com impacto `execute` ou `all`: oferecer opção de aplicar agora (pausar onda atual) ou continuar e aplicar na próxima rodada.
+- Ler **`.oxe/STATE.md`** para capturar o contexto automático (fase atual, tarefa ativa, workstream ativo).
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, `OBSERVATIONS.md` vive em `.oxe/<active_session>/execution/`; sem sessão ativa, manter `.oxe/`.
+- Usar `oxe/templates/OBSERVATIONS.template.md` para criar o arquivo se ainda não existir.
+</context>
 
 <format_observations_md>
-Arquivo: **`.oxe/OBSERVATIONS.md`**
+Arquivo: **`OBSERVATIONS.md`** no escopo resolvido da sessão
 
 ```markdown
 # Observações OXE
@@ -49,6 +50,16 @@ API deve retornar mensagens de erro em português do Brasil.
 **IDs:** sequenciais `OBS-001`, `OBS-002`, … (continuar do último ID existente no arquivo).
 
 **Impacto:** classificar automaticamente com base no conteúdo:
+
+| Texto menciona | Impacto atribuído |
+|----------------|------------------|
+| Requisitos, critérios A*, escopo, SPEC | `spec` |
+| Tarefas Tn, ondas, verificação, PLAN | `plan` |
+| Implementação, arquivos de código, comportamento técnico | `execute` |
+| Dois ou mais dos acima, ou restrição global | `all` |
+
+Se ambíguo, usar `all` (princípio de maior abrangência).
+
 - `spec` — afeta requisitos, critérios de aceite ou escopo
 - `plan` — afeta tarefas, ondas, dependências ou verificação
 - `execute` — afeta a implementação da tarefa atual ou próxima
@@ -59,14 +70,14 @@ API deve retornar mensagens de erro em português do Brasil.
 
 <process>
 1. Ler **`.oxe/STATE.md`**: capturar `phase`, `last_task` ou tarefa ativa na onda, `active_workstream`.
-2. Determinar o **próximo ID** (OBS-NNN): contar entradas existentes em `.oxe/OBSERVATIONS.md` ou começar em OBS-001.
+2. Determinar o **próximo ID** (OBS-NNN): contar entradas existentes em `OBSERVATIONS.md` do escopo resolvido ou começar em OBS-001.
 3. Classificar o **impacto** automaticamente com base no texto; se ambíguo, usar `all`.
 3b. **Propagação automática de constraints:**
    - Se existir **`.oxe/SPEC.md`**: ler a tabela de requisitos (R-ID) e critérios (A*) e identificar quais são diretamente afetados pelo texto da observação. Registrar em `**Afeta (spec):**`.
    - Se existir **`.oxe/PLAN.md`**: ler as tarefas (Tn) e identificar quais podem precisar de ajuste no campo `Verificar` ou `Implementar`. Registrar em `**Afeta (plan):**`.
    - Se nenhum R-ID ou Tn identificável: registrar `**Afeta:** (a cruzar na próxima incorporação)`.
    - Esta propagação é automática e não requer input do usuário.
-4. Criar ou atualizar **`.oxe/OBSERVATIONS.md`**:
+4. Criar ou atualizar **`OBSERVATIONS.md`** no escopo resolvido:
    - Adicionar linha na tabela de índice.
    - Adicionar seção `### OBS-NNN` com contexto, impacto, status e texto.
 5. Avaliar **urgência**:

package/oxe/workflows/oxe.md

@@ -1,115 +1,115 @@
-# OXE — Workflow: oxe (entrada universal)
-
-<objective>
-Ponto de entrada inteligente do OXE. Faz uma de três coisas dependendo do input do usuário:
-
-1. **Sem input / "o que faço agora?"** → lê `STATE.md` e recomenda exatamente 1 próximo passo (lógica de `next.md`).
-2. **Input em linguagem natural** (ex.: "quero adicionar login", "preciso revisar um PR") → traduz para o comando OXE correto e executa ou orienta (lógica de `route.md`).
-3. **"help", "o que é OXE" ou "comandos"** → apresenta o fluxo dos 8 comandos essenciais e a cadeia canônica.
-
-**Princípio:** o usuário não precisa decorar o nome do comando — `/oxe [contexto]` resolve.
-</objective>
-
-<context>
-- Este workflow **não gera artefatos** por conta própria. Ele orienta ou delega para o workflow correto.
-- Lê `STATE.md` quando disponível para personalizar a resposta ao estado atual do projeto.
-- Quando o input for claro o suficiente para um workflow específico, **executar diretamente** esse workflow (carregar e seguir o `.md` correspondente) em vez de só sugerir o comando.
-- Quando houver ambiguidade genuína, apresentar 2 opções e pedir escolha — nunca listas longas.
-</context>
-
-<modo_status>
-## Modo: Status + Próximo Passo (sem input ou "o que faço agora?")
-
-Aplicar a lógica completa de `oxe/workflows/next.md`:
-
-1. Se `.oxe/` ou `STATE.md` não existir → **scan** (`npx oxe-cc@latest` primeiro se OXE não instalado)
-2. Se `.oxe/codebase/` incompleto e não for quick isolado → **scan**
-3. Se `quick_active` ou `QUICK.md` sem `PLAN.md` → avaliar promoção (ver `next.md`)
-4. Se sem `SPEC.md` → **spec**
-5. Se SPEC mas sem PLAN → verificar `discuss_before_plan` → **discuss** ou **plan**
-6. Se PLAN sem VERIFY pós-implementação → **execute** ou **verify**
-7. Se VERIFY com falha → **plan --replan**
-8. Se VERIFY OK → próxima feature ou milestone
-
-**Saída:** exatamente 1 passo, 1 comando, 1 frase de justificativa.
-</modo_status>
-
-<modo_route>
-## Modo: Roteamento de Linguagem Natural (input com contexto)
-
-Mapear o input para o workflow correto e executar ou orientar:
-
-| Se o usuário disser | Executar |
-|---------------------|----------|
-| "quero [feature / tarefa / entrega]" | Verificar estado → **spec** ou **quick** |
-| "analisa / mapeia o projeto" | **scan** (modo refresh se codebase/ existir) |
-| "pesquisa / spike / quero entender X" | **research** |
-| "revisa PR / diff" | **review-pr** |
-| "auditoria de segurança" | **security** |
-| "valida / verifica" | **verify** |
-| "milestone / release / versão" | **project milestone** |
-| "trilha paralela / workstream" | **project workstream** |
-| "snapshot / checkpoint" | **project checkpoint** |
-| "recuperação / erro / algo quebrou" | **forensics** |
-| "debug / teste falhando" | **debug** |
-| "obs / observação / nota" | **obs** |
-| "atualiza / update OXE" | **update** |
-
-Se o input não mapear claramente → apresentar 2 opções mais prováveis e perguntar.
-</modo_route>
-
-<modo_help>
-## Modo: Help (quando o usuário pede "help", "o que é OXE", "comandos")
-
-Apresentar de forma concisa:
-
-### Os 8 comandos que você precisa conhecer
-
-```
-/oxe              → onde estou / o que faço / help
-/oxe-obs          → registrei algo importante agora
-/oxe-quick        → tarefa pequena, sem cerimônia
-/oxe-scan         → mapeia o projeto (ou atualiza o mapa)
-/oxe-spec         → nova feature ou entrega: perguntas → requisitos → roteiro
-/oxe-plan         → detalhar em tarefas (--agents para multi-agente)
-/oxe-execute      → implementar (A: completo | B: por onda | C: por tarefa)
-/oxe-verify       → validar que está pronto
-```
-
-### A cadeia
-
-```
-/oxe-obs (qualquer momento)
-     ↓
-/oxe-scan → /oxe-spec → /oxe-plan → /oxe-execute → /oxe-verify → /oxe-retro
-                                  ↓
-                           /oxe-quick (trabalho pequeno)
-```
-
-### Para saber o próximo passo agora
-
-```
-/oxe
-```
-
-### Escape hatches (não precisa decorar — aparecem quando necessários)
-
-`/oxe-research`, `/oxe-forensics`, `/oxe-debug`, `/oxe-loop`, `/oxe-security`,
-`/oxe-validate-gaps`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-review-pr`,
-`/oxe-project` (milestone, workstream, checkpoint)
-</modo_help>
-
-<process>
-1. Verificar se há input adicional na mensagem:
-   - **Sem input ou "next / o que faço / status":** aplicar `<modo_status>`.
-   - **"help / comandos / o que é OXE":** aplicar `<modo_help>`.
-   - **Qualquer outra coisa (linguagem natural com contexto):** aplicar `<modo_route>` e, se o workflow for claro, carregar e executar diretamente o `oxe/workflows/<nome>.md` correspondente.
-2. Nunca produzir listas longas de alternativas. Um passo, um comando, uma frase.
-3. Se o workflow executado diretamente gerar artefatos, reportar no chat conforme esse workflow.
-</process>
-
-<success_criteria>
-- [ ] Usuário recebe exatamente 1 próximo passo (modo status) OU 1 workflow executado (modo route) OU o bloco help compacto (modo help).
-- [ ] Nenhum artefato criado por este workflow diretamente (a menos que o workflow delegado o faça).
-- [ ] Nunca lista mais de 2 alternativas ao mesmo tempo.
-</success_criteria>
+# OXE — Workflow: oxe (entrada universal)
+
+<objective>
+Ponto de entrada inteligente do OXE. Faz uma de três coisas dependendo do input do usuário:
+
+1. **Sem input / "o que faço agora?"** → lê `STATE.md` e recomenda exatamente 1 próximo passo (lógica de `next.md`).
+2. **Input em linguagem natural** (ex.: "quero adicionar login", "preciso revisar um PR") → traduz para o comando OXE correto e executa ou orienta (lógica de `route.md`).
+3. **"help", "o que é OXE" ou "comandos"** → apresenta o fluxo dos 8 comandos essenciais e a cadeia canônica.
+
+**Princípio:** o usuário não precisa decorar o nome do comando — `/oxe [contexto]` resolve.
+</objective>
+
+<context>
+- Este workflow **não gera artefatos** por conta própria. Ele orienta ou delega para o workflow correto.
+- Lê `STATE.md` quando disponível para personalizar a resposta ao estado atual do projeto.
+- Quando o input for claro o suficiente para um workflow específico, **executar diretamente** esse workflow (carregar e seguir o `.md` correspondente) em vez de só sugerir o comando.
+- Quando houver ambiguidade genuína, apresentar 2 opções e pedir escolha — nunca listas longas.
+</context>
+
+<modo_status>
+## Modo: Status + Próximo Passo (sem input ou "o que faço agora?")
+
+Aplicar a lógica completa de `oxe/workflows/next.md`:
+
+1. Se `.oxe/` ou `STATE.md` não existir → **scan** (`npx oxe-cc@latest` primeiro se OXE não instalado)
+2. Se `.oxe/codebase/` incompleto e não for quick isolado → **scan**
+3. Se `quick_active` ou `QUICK.md` sem `PLAN.md` → avaliar promoção (ver `next.md`)
+4. Se sem `SPEC.md` → **spec**
+5. Se SPEC mas sem PLAN → verificar `discuss_before_plan` → **discuss** ou **plan**
+6. Se PLAN sem VERIFY pós-implementação → **execute** ou **verify**
+7. Se VERIFY com falha → **plan --replan**
+8. Se VERIFY OK → próxima feature ou milestone
+
+**Saída:** exatamente 1 passo, 1 comando, 1 frase de justificativa.
+</modo_status>
+
+<modo_route>
+## Modo: Roteamento de Linguagem Natural (input com contexto)
+
+Mapear o input para o workflow correto e executar ou orientar:
+
+| Se o usuário disser | Executar |
+|---------------------|----------|
+| "quero [feature / tarefa / entrega]" | Verificar estado → **spec** ou **quick** |
+| "analisa / mapeia o projeto" | **scan** (modo refresh se codebase/ existir) |
+| "pesquisa / spike / quero entender X" | **research** |
+| "revisa PR / diff" | **review-pr** |
+| "auditoria de segurança" | **security** |
+| "valida / verifica" | **verify** |
+| "milestone / release / versão" | **project milestone** |
+| "trilha paralela / workstream" | **project workstream** |
+| "snapshot / checkpoint" | **project checkpoint** |
+| "recuperação / erro / algo quebrou" | **forensics** |
+| "debug / teste falhando" | **debug** |
+| "obs / observação / nota" | **obs** |
+| "atualiza / update OXE" | **update** |
+
+Se o input não mapear claramente → apresentar 2 opções mais prováveis e perguntar.
+</modo_route>
+
+<modo_help>
+## Modo: Help (quando o usuário pede "help", "o que é OXE", "comandos")
+
+Apresentar de forma concisa:
+
+### Os 8 comandos que você precisa conhecer
+
+```
+/oxe              → onde estou / o que faço / help
+/oxe-obs          → registrei algo importante agora
+/oxe-quick        → tarefa pequena, sem cerimônia
+/oxe-scan         → mapeia o projeto (ou atualiza o mapa)
+/oxe-spec         → nova feature ou entrega: perguntas → requisitos → roteiro
+/oxe-plan         → detalhar em tarefas (--agents para multi-agente)
+/oxe-execute      → implementar (A: completo | B: por onda | C: por tarefa)
+/oxe-verify       → validar que está pronto
+```
+
+### A cadeia
+
+```
+/oxe-obs (qualquer momento)
+     ↓
+/oxe-scan → /oxe-spec → /oxe-plan → /oxe-execute → /oxe-verify → /oxe-retro
+                                  ↓
+                           /oxe-quick (trabalho pequeno)
+```
+
+### Para saber o próximo passo agora
+
+```
+/oxe
+```
+
+### Escape hatches (não precisa decorar — aparecem quando necessários)
+
+`/oxe-research`, `/oxe-forensics`, `/oxe-debug`, `/oxe-loop`, `/oxe-security`,
+`/oxe-validate-gaps`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-review-pr`,
+`/oxe-project` (milestone, workstream, checkpoint)
+</modo_help>
+
+<process>
+1. Verificar se há input adicional na mensagem:
+   - **Sem input ou "next / o que faço / status":** aplicar `<modo_status>`.
+   - **"help / comandos / o que é OXE":** aplicar `<modo_help>`.
+   - **Qualquer outra coisa (linguagem natural com contexto):** aplicar `<modo_route>` e, se o workflow for claro, carregar e executar diretamente o `oxe/workflows/<nome>.md` correspondente.
+2. Nunca produzir listas longas de alternativas. Um passo, um comando, uma frase.
+3. Se o workflow executado diretamente gerar artefatos, reportar no chat conforme esse workflow.
+</process>
+
+<success_criteria>
+- [ ] Usuário recebe exatamente 1 próximo passo (modo status) OU 1 workflow executado (modo route) OU o bloco help compacto (modo help).
+- [ ] Nenhum artefato criado por este workflow diretamente (a menos que o workflow delegado o faça).
+- [ ] Nunca lista mais de 2 alternativas ao mesmo tempo.
+</success_criteria>

package/oxe/workflows/plan-agent.md

@@ -13,8 +13,9 @@ O plano **não** é só uma lista de tarefas: cada agente é um **pacote de cont
 Se o utilizador pedir **`--replan`**: aplicar a mesma lógica de replanejamento descrita em **`plan.md`** (VERIFY, SUMMARY, secção Replanejamento) e **atualizar ou recriar** `plan-agents.json` em coerência com o novo `PLAN.md`; gerar **novo** `runId` e repor `lifecycle.status` → `pending_execute`. Se ainda existir pasta **`.oxe/plan-agent-messages/`** cheia do **run** anterior e o utilizador não precisar dela na raiz, **arquivar** primeiro em **`.oxe/archive/plan-agent-runs/<runId-antigo>/`** (ver **`references/plan-agent-chat-protocol.md`**) ou pedir confirmação antes de sobrescrever; depois recriar **`.oxe/plan-agent-messages/README.md`** para o novo `runId`.
 </objective>
 
-<context>
-- **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`**.
+<context>
+- 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/`.
+- **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`**.
 - **Fonte de verdade das tarefas:** `PLAN.md`. O JSON referencia tarefas via **`taskIds`** em cada agente — **não** duplicar o texto de **Verificar** no JSON; copiar só paths/resumo curto em **`outputs`** quando útil para routing.
 - **Agentes ≠ ferramentas externas fixas:** `role` e `scope` descrevem o **comportamento esperado** de um contexto focado (ex.: “Backend Auth Specialist”), não um binário. Quem executa pode ser um único modelo com instruções diferentes por onda.
 - **Protocolo agente → agente:** **`oxe/workflows/references/plan-agent-chat-protocol.md`** — mensagens em **`.oxe/plan-agent-messages/`** (ficheiros `W{onda}-{seq}-{from}-to-{dest}.md` com frontmatter YAML). Criar a pasta e copiar o índice a partir de **`oxe/templates/plan-agent-messages-README.template.md`** → `.oxe/plan-agent-messages/README.md`.
@@ -125,7 +126,7 @@ Resumo obrigatório no chat: `Gate plan-agent: OK` ou `Gate plan-agent: corrigid
 3. Escrever **`.oxe/PLAN.md`** (cabeçalho YAML como em `oxe/templates/PLAN.template.md`; em **--replan**, secção Replanejamento).
 4. Gerar **`runId`** novo e **`lifecycle`**: `{ "status": "pending_execute", "since": "<ISO agora>" }`.
 5. Escrever **`.oxe/plan-agents.json`** a partir de **`oxe/templates/plan-agents.template.json`**, com **`oxePlanAgentsSchema: 3`**, `goal`, `agents` (incluindo `model_hint` por agente conforme `<model_hints>`), `execution`, `runId`, `lifecycle`.
-6. Criar **`.oxe/plan-agent-messages/`** e **`.oxe/plan-agent-messages/README.md`** a partir de **`oxe/templates/plan-agent-messages-README.template.md`**.
+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`**.