oxe-cc 0.6.2 → 0.6.5

package/oxe/workflows/session.md

@@ -0,0 +1,153 @@
+# OXE — Workflow: session
+
+<objective>
+Gerenciar **sessões OXE** em `.oxe/sessions/` para isolar artefatos por ciclo de trabalho, mantendo **`.oxe/STATE.md`** como índice global e preservando o **modo legado** quando não houver sessão ativa.
+
+Subcomandos:
+- `new <nome>`
+- `list`
+- `switch <id-ou-nome>`
+- `resume <id-ou-nome>`
+- `status`
+- `close`
+- `migrate <nome>`
+</objective>
+
+<context>
+- Fonte de regra de path: `oxe/workflows/references/session-path-resolution.md`
+- Template da sessão: `oxe/templates/SESSION.template.md`
+- Índice global: `.oxe/SESSIONS.md`
+- Sessão ativa fica sempre em `.oxe/STATE.md`, campo `active_session`, com path relativo completo: `sessions/sNNN-slug`
+- Sem sessão ativa, os workflows continuam a operar na raiz `.oxe/`
+- Esta entrega é **workflows only**: `oxe-cc status` / `doctor` continuam legados e isso deve ser assumido nesta versão
+</context>
+
+<index_format>
+## Formato fixo de `.oxe/SESSIONS.md`
+
+```markdown
+# OXE — Índice de sessões
+
+| ID | Nome | Status | Criada | Última atividade | Resumo | Path |
+|----|------|--------|--------|------------------|--------|------|
+| s001 | auth-redesign | active | 2026-04-07 | 2026-04-07 | Sessão criada por migrate | `sessions/s001-auth-redesign` |
+```
+
+- Linha mais recente no topo
+- `switch` e `resume` atualizam **Última atividade**
+- `close` atualiza **Status** para `archived`
+</index_format>
+
+<process_new>
+## `new <nome>`
+
+1. Garantir `.oxe/`, `.oxe/sessions/` e `.oxe/global/`.
+2. Normalizar o nome para slug ASCII em kebab-case.
+3. Ler `.oxe/SESSIONS.md` se existir; calcular o próximo ID `sNNN`.
+4. Criar `.oxe/sessions/sNNN-slug/` com:
+   - `spec/`
+   - `plan/`
+   - `execution/`
+   - `verification/`
+   - `checkpoints/`
+   - `research/`
+   - `artifacts/`
+   - `workstreams/`
+5. Criar `SESSION.md` a partir de `SESSION.template.md`.
+6. Criar ou atualizar `.oxe/SESSIONS.md` com a nova linha no topo.
+7. Atualizar `.oxe/STATE.md`:
+   - `active_session: sessions/sNNN-slug`
+   - `session_id: sNNN`
+   - fase resumida e próximo passo coerentes com a sessão nova
+8. Responder no chat com ID, path da sessão e próximo passo sugerido.
+</process_new>
+
+<process_list>
+## `list`
+
+1. Ler `.oxe/SESSIONS.md`.
+2. Se o ficheiro não existir, responder que não há sessões registadas.
+3. Exibir a tabela do índice; se o utilizador pedir filtro, aceitar `--status active|archived`.
+</process_list>
+
+<process_switch>
+## `switch <id-ou-nome>`
+
+1. Ler `.oxe/SESSIONS.md`.
+2. Resolver a sessão por `sNNN`, slug ou nome exibido na tabela.
+3. Atualizar `.oxe/STATE.md` global:
+   - `active_session`
+   - `session_id`
+   - `Última atividade` dessa sessão em `.oxe/SESSIONS.md`
+4. Não mover artefatos; apenas mudar o contexto ativo.
+</process_switch>
+
+<process_resume>
+## `resume <id-ou-nome>`
+
+- Mesmo comportamento de `switch`
+- Usar wording de retomada no chat, mas sem lógica diferente
+</process_resume>
+
+<process_status>
+## `status`
+
+1. Ler `.oxe/STATE.md` global.
+2. Se houver `active_session`, abrir `SESSION.md` da sessão ativa e resumir:
+   - metadados
+   - índice de artefatos
+   - tags
+   - último evento do histórico
+3. Se não houver sessão ativa, responder com a tabela de `.oxe/SESSIONS.md` (equivalente funcional a `list`).
+</process_status>
+
+<process_close>
+## `close`
+
+1. Ler `.oxe/STATE.md`; se não houver sessão ativa, pausar e informar.
+2. Abrir `SESSION.md` da sessão ativa e marcar `Status: archived`.
+3. Atualizar `.oxe/SESSIONS.md` com `Status = archived` e `Última atividade = hoje`.
+4. Limpar de `.oxe/STATE.md`:
+   - `active_session`
+   - `session_id`
+5. Responder com a sessão encerrada e lembrar que sessões arquivadas continuam legíveis.
+</process_close>
+
+<process_migrate>
+## `migrate <nome>`
+
+1. Executar logicamente `new <nome>` para abrir uma nova sessão.
+2. Mover apenas artefatos session-scoped existentes da raiz `.oxe/`:
+   - `SPEC.md`, `ROADMAP.md`, `DISCUSS.md`, `UI-SPEC.md` → `spec/`
+   - `PLAN.md`, `QUICK.md`, `plan-agents.json`, `quick-agents.json`, `plan-agent-messages/` → `plan/`
+   - `OBSERVATIONS.md`, `DEBUG.md`, `FORENSICS.md`, `SUMMARY.md` → `execution/`
+   - `VERIFY.md`, `VALIDATION-GAPS.md`, `SECURITY.md`, `UI-REVIEW.md` → `verification/`
+   - `checkpoints/`, `CHECKPOINTS.md` → `checkpoints/`
+   - `research/`, `RESEARCH.md` → `research/`
+   - `workstreams/` → `workstreams/`
+3. Não mover:
+   - `.oxe/STATE.md`
+   - `.oxe/config.json`
+   - `.oxe/codebase/`
+   - `.oxe/SESSIONS.md`
+   - `.oxe/global/`
+4. No chat, listar:
+   - movidos
+   - mantidos globais
+   - ignorados por inexistência
+</process_migrate>
+
+<process_default>
+## Sem subcomando
+
+- Se houver sessão ativa: executar `status`
+- Se não houver sessão ativa: executar `list`
+</process_default>
+
+<success_criteria>
+- [ ] `.oxe/sessions/sNNN-slug/` é o path da sessão criado/consultado.
+- [ ] `active_session` guarda o path relativo completo no `STATE.md` global.
+- [ ] `.oxe/SESSIONS.md` usa as colunas mínimas `ID | Nome | Status | Criada | Última atividade | Resumo | Path`.
+- [ ] `close` arquiva sem apagar artefatos.
+- [ ] `migrate` move só artefatos session-scoped e preserva os globais.
+</success_criteria>

package/oxe/workflows/spec.md

@@ -13,14 +13,20 @@ Para trabalho **muito pequeno** que não justifica spec completa: redirecionar p
 Se **`.oxe/config.json`** tiver `discuss_before_plan: true`: mencionar no final da Fase 5 que o próximo passo é **`oxe:discuss`** antes do plano.
 </objective>
 
-<context>
-**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
-
-Ler no início:
-- `.oxe/STATE.md` — fase atual, decisões, workstream ativo
-- `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
-- **`.oxe/OBSERVATIONS.md`** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
-- **`.oxe/LESSONS.md`** — se existir, ler entradas com `Aplicar em: spec` e status `ativo`. Usar como restrições explícitas ou alertas durante a Fase 1 (perguntas) e Fase 3 (requisitos). Exemplo: se uma lição diz "perguntar explicitamente sobre integração com X", adicionar essa pergunta no Bloco B da Fase 1.
+<context>
+**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
+
+**Resolução de sessão:** antes de ler ou escrever artefatos desta trilha, resolver `active_session` em `.oxe/STATE.md` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa:
+- `SPEC.md`, `ROADMAP.md` e `DISCUSS.md` vivem em `.oxe/<active_session>/spec/`
+- `OBSERVATIONS.md`, `RESEARCH.md` e `research/` seguem o escopo da sessão
+- `LESSONS.md` continua global em `.oxe/global/LESSONS.md`
+- sem sessão ativa, manter o modo legado na raiz `.oxe/`
+
+Ler no início:
+- `.oxe/STATE.md` — fase atual, decisões, workstream ativo
+- `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
+- **OBS do escopo ativo** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
+- **`.oxe/global/LESSONS.md`** — se existir, ler entradas com `Aplicar em: spec` e status `ativo`. Usar como restrições explícitas ou alertas durante a Fase 1 (perguntas) e Fase 3 (requisitos). Exemplo: se uma lição diz "perguntar explicitamente sobre integração com X", adicionar essa pergunta no Bloco B da Fase 1.
 
 **Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — épicos por trilha, critérios A* verificáveis por Grep/leitura/checklist.
 
@@ -69,8 +75,8 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - "Há 3 áreas com incerteza técnica: autenticação JWT, integração com Stripe, e deploy em edge. Quer investigar alguma antes de avançar para requisitos?"
 
 **Se aprovado:**
-- Criar notas de pesquisa datadas em `.oxe/research/YYYY-MM-DD-<slug>.md` (usar fluxo de `research.md`)
-- Atualizar `.oxe/RESEARCH.md` com índice
+- Criar notas de pesquisa datadas em `research/YYYY-MM-DD-<slug>.md` no escopo ativo (usar fluxo de `research.md`)
+- Atualizar `RESEARCH.md` no mesmo escopo
 - Consolidar descobertas relevantes antes de avançar para Fase 3
 
 **Se pulado:** registrar em `SPEC.md` as áreas de incerteza como suposições explícitas.
@@ -105,7 +111,7 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 <fase_4_roteiro>
 ## Fase 4 — Roteiro
 
-**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `.oxe/ROADMAP.md`.
+**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `ROADMAP.md` no escopo ativo da sessão.
 
 **Lógica de agrupamento:**
 - Agrupar requisitos v1 em fases por **dependência técnica** e **valor entregável**
@@ -113,14 +119,14 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - Fase 1 = o que `/oxe-plan` implementará no próximo ciclo
 - Fases 2+ = ciclos futuros de spec→plan→execute→verify
 
-**Escrever `.oxe/ROADMAP.md`** usando `oxe/templates/ROADMAP.template.md`:
+**Escrever `ROADMAP.md`** usando `oxe/templates/ROADMAP.template.md` no escopo ativo:
 
 ```markdown
 ---
 oxe_doc: roadmap
 status: draft
 updated: <data>
-spec_ref: .oxe/SPEC.md
+spec_ref: SPEC.md
 ---
 
 ## Fase 1 — [Nome]
@@ -192,24 +198,24 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 </fase_5_aprovacao>
 
 <process>
-1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `.oxe/OBSERVATIONS.md` (verificar pendentes).
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
 2. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
 3. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
 4. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
-5. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `.oxe/ROADMAP.md`.
-6. Escrever **`.oxe/SPEC.md`** usando `oxe/templates/SPEC.template.md`:
+5. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
+6. Escrever **`SPEC.md`** usando `oxe/templates/SPEC.template.md` no escopo ativo:
    - Frontmatter YAML (`oxe_doc: spec`, `status`, `updated`, `inputs`)
    - Objetivo, Escopo (dentro/fora), Critérios de aceite (tabela A*), Suposições e riscos, Referências
    - Preservar chaves existentes se SPEC.md já existir; atualizar `updated:`
 6b. **Auto-reflexão:** executar integralmente o bloco `<auto_reflexao>` antes de avançar. Corrigir a spec conforme necessário. Não apresentar a lista de verificação ao usuário — apenas a spec corrigida.
 7. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
-8. Atualizar **`.oxe/STATE.md`**: `phase: spec_ready`, próximo passo.
-9. Marcar OBS incorporadas em `.oxe/OBSERVATIONS.md` se houver pendentes de impacto `spec`.
+8. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
+9. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
 </process>
 
 <success_criteria>
-- [ ] `.oxe/SPEC.md` existe com critérios A* e coluna Como verificar; `STATE.md` atualizado.
-- [ ] `.oxe/ROADMAP.md` existe com fases mapeadas a R-IDs e A*, status `approved` (ou `draft` se usuário não confirmou).
+- [ ] `SPEC.md` existe no escopo correto (`spec/` da sessão ou `.oxe/` legado) com critérios A* e coluna Como verificar; `STATE.md` global atualizado.
+- [ ] `ROADMAP.md` existe no mesmo escopo com fases mapeadas a R-IDs e A*, status `approved` (ou `draft` se usuário não confirmou).
 - [ ] Tabela de requisitos R-ID foi apresentada e validada (v1/v2/fora) antes do roteiro.
 - [ ] Usuário foi consultado no gate da Fase 5 e escolheu o próximo passo.
 - [ ] OBS pendentes com impacto `spec` foram incorporadas e marcadas `incorporada`.

package/oxe/workflows/ui-review.md

@@ -13,9 +13,9 @@ Não substitui **`verify`**: cruza contrato UI; o verify global continua a amarr
 </context>
 
 <process>
-1. Ler `.oxe/UI-SPEC.md`, `.oxe/SPEC.md` e inspecionar ficheiros de UI relevantes (paths do PLAN ou indicados pelo utilizador).
-2. Escrever **`.oxe/UI-REVIEW.md`** com: **Data**, **Âmbito revisto**, **Checklist** (passou / falhou / N/A), **Bloqueios**, **Sugestões**.
-3. Atualizar **`.oxe/STATE.md`** se útil (referência a UI-REVIEW pendente de verify).
+1. Resolver `active_session` conforme `session-path-resolution.md`; ler `UI-SPEC.md` e `SPEC.md` do escopo resolvido e inspecionar ficheiros de UI relevantes (paths do PLAN ou indicados pelo utilizador).
+2. Escrever **`UI-REVIEW.md`** no escopo de `verification/` da sessão ativa (ou `.oxe/` legado) com: **Data**, **Âmbito revisto**, **Checklist** (passou / falhou / N/A), **Bloqueios**, **Sugestões**.
+3. Atualizar **`.oxe/STATE.md`** global se útil (referência a UI-REVIEW pendente de verify).
 4. Indicar no chat: se há P0 → próximo passo típico **`/oxe-execute`** (correções); senão **`/oxe-verify`** para fecho global.
 </process>
 

package/oxe/workflows/ui-spec.md

@@ -13,9 +13,9 @@ Produzir **`.oxe/UI-SPEC.md`**: contrato de UI/UX derivado de **`.oxe/SPEC.md`**
 </context>
 
 <process>
-1. Ler `.oxe/SPEC.md` e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
-2. Criar ou atualizar **`.oxe/UI-SPEC.md`** com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais).
-3. Atualizar **`.oxe/STATE.md`**: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
+1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
+2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais).
+3. Atualizar **`.oxe/STATE.md`** global: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
 4. Resumo no chat: o que ficou no UI-SPEC e como o **`/oxe-plan`** deve citar as secções (ex.: “cumprir UI-SPEC §2”).
 </process>
 

package/oxe/workflows/validate-gaps.md

@@ -6,20 +6,21 @@ Após **`verify`**, produzir ou atualizar **`.oxe/VALIDATION-GAPS.md`**: auditor
 Não substitui **`verify`**: não reescreve a evidência em `VERIFY.md`; adiciona uma camada de “gaps” e melhorias para a próxima ronda ou replan.
 </objective>
 
-<context>
-- **Pré-requisitos:** `.oxe/VERIFY.md` e `.oxe/PLAN.md` existem. `.oxe/SPEC.md` altamente recomendado para cruzar IDs **A***.
+<context>
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, `VERIFY.md`, `PLAN.md`, `SPEC.md` e `VALIDATION-GAPS.md` vivem no escopo da sessão; sem sessão ativa, manter `.oxe/`.
+- **Pré-requisitos:** `VERIFY.md` e `PLAN.md` existem no escopo resolvido. `SPEC.md` altamente recomendado para cruzar IDs **A***.
 - **Quando usar:** equipas que querem fechar dívida de testes, evidência fraca ou desalinhamento após um verify (passou ou falhou).
 - **Edição do PLAN:** só se o utilizador pedir explicitamente incorporar as sugestões no plano.
 </context>
 
 <process>
-1. Ler `.oxe/PLAN.md` (cada `### Tn`, **Verificar**, **Aceite vinculado:**), `.oxe/VERIFY.md` (tabelas de tarefas e de critérios SPEC), e `.oxe/SPEC.md` se existir.
+1. Ler `PLAN.md` (cada `### Tn`, **Verificar**, **Aceite vinculado:**), `VERIFY.md` (tabelas de tarefas e de critérios SPEC), e `SPEC.md` do escopo resolvido se existir.
 2. Aplicar checklist de deteção (marcar cada achado nos **Gaps**):
    - **A*** na SPEC sem linha clara na tabela de critérios do VERIFY, ou com evidência inexistente/vaga.
    - **Tn** com `Comando: —` ou **Manual** vago quando o critério associado pede rigor reprodutível.
    - VERIFY indica sucesso mas a coluna de evidência é só genérica (sem path, comando ou trecho identificável).
    - Tarefa no PLAN sem linha correspondente na tabela de tarefas do VERIFY (verify focado em subset — documentar como gap de escopo).
-3. Escrever ou atualizar **`.oxe/VALIDATION-GAPS.md`** com secções fixas:
+3. Escrever ou atualizar **`VALIDATION-GAPS.md`** no escopo resolvido com secções fixas:
    - **Data** (ISO) e **Contexto** (verify passou / falhou; ambiente se relevante).
    - **Gaps** — tabela: **ID ou Tn** | **Tipo de gap** | **Severidade sugerida** (P0/P1/P2) | **Nota**.
    - **Sugestões de tarefas** — rascunhos `T_new` ou bullets para incorporar no próximo `oxe:plan --replan`; **apenas texto**.

package/oxe/workflows/verify.md

@@ -13,14 +13,15 @@ Resultado registrado em **`.oxe/VERIFY.md`** com atualização de **STATE**.
 Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela nas camadas 1–2; as camadas 3–4 são sempre de escopo completo.
 </objective>
 
-<context>
-- Preferir rodar comandos reais no terminal quando o ambiente permitir; se o sandbox bloquear, marcar como "não executado aqui" e deixar o comando para o usuário.
+<context>
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, `VERIFY.md`, `VALIDATION-GAPS.md`, `SECURITY.md`, `UI-REVIEW.md` e `SUMMARY.md` vivem no escopo da sessão; `.oxe/STATE.md` continua global.
+- Preferir rodar comandos reais no terminal quando o ambiente permitir; se o sandbox bloquear, marcar como "não executado aqui" e deixar o comando para o usuário.
 - Não destruir `PLAN.md`; registrar achados em `VERIFY.md`.
 - Ler **`.oxe/config.json`** se existir: `after_verify_draft_commit`, `after_verify_suggest_pr`, e `verification_depth` (`"standard"` por padrão; `"thorough"` ativa camadas 3–4 completas; `"quick"` pula camadas 3–4 e UAT).
 - Os critérios na SPEC devem estar na tabela **Critérios de aceite** com colunas **ID** / **Critério** / **Como verificar**; o verify deve **cruzar cada ID** com evidência (arquivo, comando, trecho).
 - **Legado:** quando **Comando** for `—` ou inexistente, evidência válida inclui **Read/Grep**, existência de ficheiros referenciados e checklist manual — não marcar critério como passou sem evidência; se o ambiente host/desktop não estiver disponível, registar **não executado aqui** e próximo passo. Ver **`oxe/workflows/references/legacy-brownfield.md`**.
 - **Debug:** investigação técnica de falhas **durante** a implementação segue **`oxe/workflows/debug.md`** (`/oxe-debug`). Resolver um bug com debug **não** dispensa este passo — após correções, **ainda** é necessário **`verify`** para fechar a trilha face à SPEC/PLAN.
-- **UI:** se existirem `.oxe/UI-SPEC.md` / `.oxe/UI-REVIEW.md`, incorporar na evidência quando os critérios **A*** ou tarefas **Tn** tocarem interface.
+- **UI:** se existirem `UI-SPEC.md` / `UI-REVIEW.md` no escopo resolvido, incorporar na evidência quando os critérios **A*** ou tarefas **Tn** tocarem interface.
 - **Camada 5 — Validate-gaps (automático quando `verification_depth: "thorough"`):** após as 4 camadas, se `verification_depth: "thorough"` em `.oxe/config.json`, executar automaticamente a lógica de `oxe/workflows/validate-gaps.md` e produzir `.oxe/VALIDATION-GAPS.md` como parte deste verify. Não requer comando separado.
 - **Camada 6 — Security (automático quando `security_in_verify: true`):** se `security_in_verify: true` em `.oxe/config.json`, executar automaticamente a lógica de `oxe/workflows/security.md` e produzir `.oxe/SECURITY.md` como parte deste verify. Não requer comando separado.
 - **Rotina compact/checkpoint (opcional):** se esta entrega alterou **estrutura**, **stack** ou **pastas** de forma relevante, `/oxe-scan` em modo refresh alinha `.oxe/codebase/` ao repo. Após **verify** com sucesso, `/oxe-project checkpoint` com slug curto pode marcar estado estável.
@@ -32,7 +33,7 @@ Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela nas camadas 1–2;
 Verificar que o PLAN.md está apto para verificação:
 1. Toda tarefa `### Tn` tem bloco **Verificar** com pelo menos Comando ou Manual.
 2. Todo **Aceite vinculado** referencia IDs que existem na tabela de SPEC.md (`A1`, `A2`, …).
-3. Se houver `.oxe/DISCUSS.md`, toda decisão técnica com ID **D-NN** aparece em **Decisão vinculada:** de alguma tarefa (ou nota explícita de gap no PLAN).
+3. Se houver `DISCUSS.md` no escopo resolvido, toda decisão técnica com ID **D-NN** aparece em **Decisão vinculada:** de alguma tarefa (ou nota explícita de gap no PLAN).
 4. Não há dependências `Tk` inválidas (ID inexistente no PLAN).
 
 Se auditoria falhar: registrar na seção **Auditoria de pré-execução** do VERIFY.md os itens com problema e **pausar** — pedir correção do PLAN antes de continuar. Se o usuário forçar continuar com `--skip-audit`, documentar e prosseguir com aviso.
@@ -45,7 +46,7 @@ Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconju
 </camada_2_tarefas_e_criterios>
 
 <camada_3_fidelidade_decisoes>
-**Camada 3 — Fidelidade de decisões** (ativa se existir `.oxe/DISCUSS.md` com IDs D-NN)
+**Camada 3 — Fidelidade de decisões** (ativa se existir `DISCUSS.md` no escopo resolvido com IDs D-NN)
 
 Para cada decisão na tabela de DISCUSS.md:
 1. Localizar a(s) tarefa(s) que referenciam esse ID em **Decisão vinculada:**.
@@ -75,10 +76,10 @@ O preenchimento da checklist é responsabilidade do **usuário** (não do agente
 
 <process>
 1. **Camada 1 — Auditoria de pré-execução:** checar integridade do PLAN.md e DISCUSS.md conforme `<camada_1_pre_exec_audit>`. Documentar resultado.
-2. Ler `.oxe/SPEC.md`, `.oxe/PLAN.md`, `.oxe/STATE.md`.
+2. Ler `SPEC.md`, `PLAN.md` e `DISCUSS.md` do escopo resolvido, além de `.oxe/STATE.md` global.
 3. **Camada 2:** Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconjunto se foco Tn). Para **cada ID de critério** da SPEC (A1, A2, …), registrar se passou com evidência.
 4. **Camada 3:** Se existir `.oxe/DISCUSS.md` com IDs D-NN, executar **Fidelidade de decisões** conforme `<camada_3_fidelidade_decisoes>`.
-5. Escrever **`.oxe/VERIFY.md`** com:
+5. Escrever **`VERIFY.md`** no escopo resolvido com:
    - Data, ambiente (SO / versão do Node se relevante).
    - **Seção — Auditoria de pré-execução:** resultado da Camada 1.
    - **Tabela — Tarefas:** Tarefa (Tn) | Verificação (comando/checklist) | Passou? | Notas.
@@ -86,9 +87,9 @@ O preenchimento da checklist é responsabilidade do **usuário** (não do agente
    - **Tabela — Fidelidade de decisões** (se DISCUSS.md existir): ID | Decisão | Tarefa(s) | Implementado? | Evidência.
    - **Checklist UAT** (Camada 4).
    - **Gaps** — o que falhou e sugestão de correção; se não houver, escrever `Nenhum gap restante`.
-6. Atualizar **`.oxe/STATE.md`**: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
+6. Atualizar **`.oxe/STATE.md`** global: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
 6b. **Blueprint plan-agent:** se **todas** as verificações relevantes **passaram**, existir **`.oxe/plan-agents.json`** com `oxePlanAgentsSchema >= 2` e `lifecycle.status === "executing"` (ou `pending_execute`), actualizar o JSON: `lifecycle: { "status": "closed", "since": "<ISO>" }` e espelhar em **`STATE.md`** (**lifecycle_status** → `closed`). Não fechar como `closed` se `verify_failed` ou gaps por resolver.
-7. Acrescentar entrada em **`.oxe/SUMMARY.md`** (sessão): se não existir, criar a partir de **`oxe/templates/SUMMARY.template.md`**. **Obrigatório** quando `verify_failed` ou quando a seção **Gaps** tiver itens.
+7. Acrescentar entrada em **`SUMMARY.md`** do escopo resolvido: se não existir, criar a partir de **`oxe/templates/SUMMARY.template.md`**. **Obrigatório** quando `verify_failed` ou quando a seção **Gaps** tiver itens.
 7b. **Retrospectiva (pós-verify):** se `verify_complete`, sugerir **`/oxe-retro`** para capturar aprendizados do ciclo em `.oxe/LESSONS.md`. Especialmente importante quando: houve replanejamento (`--replan`), houve falhas em execute que precisaram de debug, critérios A* foram ajustados durante o ciclo, ou o ciclo durou mais de 2 ondas. Retro antes do próximo spec garante que lições orientem o próximo ciclo.
 7b. **Camada 5 — Validate-gaps automático:** se `verification_depth: "thorough"` em `.oxe/config.json`, executar a lógica de `oxe/workflows/validate-gaps.md` e adicionar seção **Gaps de Cobertura** ao VERIFY.md (mesmo conteúdo de VALIDATION-GAPS.md). Também escrever `.oxe/VALIDATION-GAPS.md` separado.
 7c. **Camada 6 — Security automático:** se `security_in_verify: true` em `.oxe/config.json`, executar a lógica de `oxe/workflows/security.md` e adicionar seção **Auditoria de Segurança** ao VERIFY.md. Também escrever `.oxe/SECURITY.md` separado. Achados P0 bloqueiam o `verify_complete` — registrar `verify_failed` até P0s serem resolvidos.
@@ -104,4 +105,6 @@ O preenchimento da checklist é responsabilidade do **usuário** (não do agente
 - [ ] SUMMARY.md atualizado quando houver falha ou gaps relevantes.
 - [ ] Se passou: seções **Rascunho de commit** e **Checklist PR** presentes em VERIFY.md, salvo se desativadas na config.
 - [ ] Se existiu DISCUSS.md: tabela de Fidelidade de decisões preenchida sem divergências não documentadas.
+- [ ] Se `verification_depth: "thorough"` em config: `.oxe/VALIDATION-GAPS.md` produzido como parte deste verify.
+- [ ] Se `security_in_verify: true` em config: `.oxe/SECURITY.md` produzido; achados P0 resolvidos ou `verify_failed` registrado.
 </success_criteria>

package/oxe/workflows/workstream.md

@@ -11,7 +11,7 @@ Subcomandos:
 - `/oxe-workstream close <nome>` — fechar workstream e mesclar contexto ao pipeline principal.
 </objective>
 
-<context>
+<context>
 **Por que workstreams?**
 
 O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entrega por vez. Workstreams permitem:
@@ -19,7 +19,7 @@ O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entre
 - Trabalho em `bugfix/auth` e `feature/billing` simultaneamente.
 - Times menores trabalhando em trilhas independentes com contextos separados.
 
-**Estrutura no disco:**
+**Estrutura no disco:**
 ```
 .oxe/
   workstreams/
@@ -32,17 +32,18 @@ O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entre
       config.json     (herda do config principal; pode sobrescrever keys)
 ```
 
-**Compatibilidade:**
-- O pipeline principal (`.oxe/SPEC.md`, `.oxe/PLAN.md`, etc.) continua funcionando normalmente.
-- Workstreams **não** substituem o pipeline principal — são adicionais.
-- `oxe-cc doctor` e `oxe-cc status` reportam cada workstream separadamente quando `--workstream=<nome>` for passado.
-- A seção **Workstreams ativos** do STATE.md principal lista os workstreams em andamento.
-</context>
+**Compatibilidade:**
+- O pipeline principal (`.oxe/SPEC.md`, `.oxe/PLAN.md`, etc.) continua funcionando normalmente.
+- Workstreams **não** substituem o pipeline principal — são adicionais.
+- `oxe-cc doctor` e `oxe-cc status` reportam cada workstream separadamente quando `--workstream=<nome>` for passado.
+- A seção **Workstreams ativos** do STATE.md principal lista os workstreams em andamento.
+- Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, workstreams vivem em `.oxe/<active_session>/workstreams/`; sem sessão ativa, usam `.oxe/workstreams/`.
+</context>
 
 <process_list>
 **`/oxe-workstream list`**
 
-1. Ler `.oxe/workstreams/` — listar subpastas.
+1. Ler `workstreams/` do escopo resolvido — listar subpastas.
 2. Para cada workstream, ler seu `STATE.md` local (fase e próximo passo).
 3. Exibir tabela no chat: Nome | Fase | Próximo passo | Última atividade.
 </process_list>
@@ -51,8 +52,8 @@ O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entre
 **`/oxe-workstream new <nome>`**
 
 1. Validar que `<nome>` é um slug seguro (letras, números, hífens — sem espaços ou caracteres especiais).
-2. Criar `.oxe/workstreams/<nome>/STATE.md` a partir de `oxe/templates/STATE.md`.
-3. Criar `.oxe/workstreams/<nome>/config.json` vazio (herda do config principal).
+2. Criar `workstreams/<nome>/STATE.md` no escopo resolvido a partir de `oxe/templates/STATE.md`.
+3. Criar `workstreams/<nome>/config.json` vazio (herda do config principal).
 4. Atualizar **STATE.md principal**: adicionar `<nome>` na seção **Workstreams ativos**.
 5. Confirmar no chat: `Workstream '<nome>' criado. Próximo passo: /oxe-spec (no contexto do workstream)`.
 
@@ -62,9 +63,9 @@ O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entre
 <process_switch>
 **`/oxe-workstream switch <nome>`**
 
-1. Verificar que `.oxe/workstreams/<nome>/` existe.
+1. Verificar que `workstreams/<nome>/` do escopo resolvido existe.
 2. Atualizar STATE.md principal: seção **Workstream ativo** com nome.
-3. Confirmar no chat: `Workstream ativo: <nome>. Artefatos em .oxe/workstreams/<nome>/`.
+3. Confirmar no chat: `Workstream ativo: <nome>. Artefatos em workstreams/<nome>/ do escopo atual`.
 
 Após ativar, os workflows `/oxe-spec`, `/oxe-plan`, `/oxe-execute`, `/oxe-verify` operam nos artefatos do workstream ativo em vez dos artefatos raiz.
 </process_switch>
@@ -73,7 +74,7 @@ Após ativar, os workflows `/oxe-spec`, `/oxe-plan`, `/oxe-execute`, `/oxe-verif
 **`/oxe-workstream status [nome]`**
 
 1. Se `nome` omitido: usar workstream ativo do STATE.md.
-2. Ler `.oxe/workstreams/<nome>/STATE.md` — fase e próximo passo.
+2. Ler `workstreams/<nome>/STATE.md` do escopo resolvido — fase e próximo passo.
 3. Ler SPEC, PLAN, VERIFY do workstream (se existirem).
 4. Exibir resumo: fase, critérios, gaps, próximo passo.
 </process_status>
@@ -83,7 +84,7 @@ Após ativar, os workflows `/oxe-spec`, `/oxe-plan`, `/oxe-execute`, `/oxe-verif
 
 1. Verificar que o workstream está com `verify_complete` no seu STATE.md local.
 2. Se não estiver: alertar e pedir confirmação com `--force`.
-3. Mover (ou arquivar) `.oxe/workstreams/<nome>/` → `.oxe/workstreams/closed/<nome>-YYYY-MM-DD/`.
+3. Mover (ou arquivar) `workstreams/<nome>/` do escopo resolvido → `workstreams/closed/<nome>-YYYY-MM-DD/`.
 4. Atualizar STATE.md principal: remover `<nome>` de **Workstreams ativos**, registrar em **Workstreams encerrados**.
 5. Confirmar no chat: `Workstream '<nome>' encerrado. Artefatos em .oxe/workstreams/closed/`.
 </process_close>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oxe-cc",
-  "version": "0.6.2",
+  "version": "0.6.5",
   "description": "OXE — spec-driven workflows in .oxe/; integrates with Cursor, GitHub Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity (npx)",
   "license": "GPL-3.0",
   "author": "",
@@ -54,7 +54,7 @@
   ],
   "scripts": {
     "sync:cursor": "node scripts/sync-cursor-from-prompts.cjs",
-    "test": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-sdk.test.cjs tests/oxe-manifest.test.cjs tests/oxe-agent-install.test.cjs tests/oxe-install-resolve-full.test.cjs tests/oxe-health-extended.test.cjs tests/oxe-workflows-edge.test.cjs tests/oxe-sdk-edge.test.cjs tests/oxe-cli-edge.test.cjs tests/oxe-npm-version.test.cjs tests/oxe-scripts.test.cjs",
+    "test": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-sdk.test.cjs tests/oxe-manifest.test.cjs tests/oxe-agent-install.test.cjs tests/oxe-install-resolve-full.test.cjs tests/oxe-health-extended.test.cjs tests/oxe-workflows-edge.test.cjs tests/oxe-sdk-edge.test.cjs tests/oxe-cli-edge.test.cjs tests/oxe-npm-version.test.cjs tests/oxe-scripts.test.cjs tests/oxe-retro-health.test.cjs",
     "test:coverage": "c8 --check-coverage --lines 82 --functions 85 --branches 58 --statements 82 npm test",
     "scan:assets": "node scripts/oxe-assets-scan.cjs",
     "prepublishOnly": "node scripts/sync-cursor-from-prompts.cjs && npm test && npm run scan:assets && node bin/oxe-cc.js --version"