oxe-cc 0.6.4 → 0.6.5

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.

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.4",
+  "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": "",