oxe-cc 0.3.9 → 0.6.0

package/oxe/workflows/scan.md

@@ -18,6 +18,20 @@ Se **`.oxe/config.json`** tiver `scan_focus_globs` ou `scan_ignore_globs`, **pri
 
 </context>
 
+<mode_detection>
+## Detecção automática de modo: bootstrap vs refresh
+
+Antes de iniciar, verificar se `.oxe/codebase/` já existe com os sete mapas:
+
+- **Modo bootstrap** (padrão quando codebase/ não existe ou está incompleto): produzir os sete arquivos do zero. Comportamento descrito no `<process>` abaixo.
+- **Modo refresh** (quando codebase/ existe e tem os sete mapas): executar a lógica de `oxe/workflows/compact.md` — comparar mapas existentes ao repo atual, atualizar incrementalmente, produzir `CODEBASE-DELTA.md` e `RESUME.md`. **Não refazer do zero.**
+
+Flag `--full`: forçar modo bootstrap mesmo se codebase/ existir.
+Flag `--refresh`: forçar modo refresh.
+
+**Sem flag:** automático por contexto. Se os mapas existem e o último scan foi há menos de `scan_max_age_days` (config), sugerir refresh mas perguntar ao usuário antes de executar o scan completo.
+</mode_detection>
+
 <process>
 1. Garantir pastas `.oxe/` e `.oxe/codebase/`.
 2. Inventariar o repo (Glob/Grep): linguagens, manifests (`package.json`, `pom.xml`, `go.mod`, etc.), pastas principais — aplicando foco/ignore da config se houver.
@@ -32,7 +46,15 @@ Se **`.oxe/config.json`** tiver `scan_focus_globs` ou `scan_ignore_globs`, **pri
    - **CONVENTIONS.md** — estilo de código (naming, formatação, imports), padrões de erros/logging, organização de módulos; **prescreve** o que seguir em novas alterações (com paths em backticks).
    - **CONCERNS.md** — dívida técnica, áreas frágeis, riscos de segurança/desempenho, dependências sensíveis; cada item com impacto breve e **arquivos** referenciados.
 4. Atualizar **`.oxe/STATE.md`**: **Data** do scan (ISO), fase sugerida `scan_complete`, próximo passo `oxe:spec` ou `oxe:plan` se já houver SPEC.
-5. Resumir em 5–10 linhas no chat: o que foi escrito e o próximo passo sugerido.
+5. **Scale-adaptive** (se `scale_adaptive: true` em `.oxe/config.json` ou não configurado — ativo por padrão):
+   - Contar arquivos de código (excluindo `node_modules`, `dist`, `build`).
+   - Contar dependências diretas (se houver `package.json`, `pom.xml`, `go.mod`, etc.).
+   - Sugerir profile adequado no chat:
+     - **< 50 arquivos, < 10 dependências** → sugerir `profile: "fast"` no config.
+     - **50–500 arquivos** → sugerir `profile: "balanced"` (padrão).
+     - **> 500 arquivos ou sistema legado** → sugerir `profile: "strict"`.
+   - Se já houver `profile` no `.oxe/config.json`, não sugerir mudança — apenas confirmar.
+6. Resumir em 5–10 linhas no chat: o que foi escrito, o próximo passo sugerido, e (se scale-adaptive ativo) o profile recomendado.
 </process>
 
 <success_criteria>

package/oxe/workflows/security.md

@@ -0,0 +1,61 @@
+# OXE — Workflow: security (auditoria de segurança)
+
+<objective>
+Produzir **`.oxe/SECURITY.md`**: auditoria de segurança do repositório focada nas categorias OWASP Top 10 **relevantes** ao stack do projeto. Complementa **`validate-gaps`** (cobertura de testes) com uma camada de segurança aplicativa.
+
+Pode ser chamado standalone ou como Camada 5 do **`verify.md`** quando `config.json` tiver `"security_in_verify": true`.
+
+Não substitui ferramentas de análise estática (SAST) — identifica padrões de risco no código e na configuração a partir do contexto disponível no repositório.
+</objective>
+
+<context>
+- **Fonte de stack:** `.oxe/codebase/STACK.md` determina quais categorias OWASP são pertinentes (ex.: app sem DB descarta A03:Injection-SQL; API sem auth descarta A07:Authentication).
+- **Fontes de código:** `.oxe/codebase/STRUCTURE.md`, `.oxe/codebase/CONCERNS.md`, `.oxe/codebase/INTEGRATIONS.md` orientam quais arquivos focar.
+- **Severidade:** P0 = crítico (exploração provável, impacto direto), P1 = alto (requer mitigação antes do próximo deploy), P2 = médio (risco aceitável com compensação documentada).
+- **Saída de tarefas:** recomendações vinculadas a `Tn` existentes no PLAN.md (se disponível) ou como sugestões de novas tarefas `T_new`.
+- **Integração com verify:** se `security_in_verify: true` em `.oxe/config.json`, o workflow `verify.md` inclui referência a este output como Camada 5. O `security.md` continua sendo o workflow canônico.
+- **Não alterar código:** apenas auditar e registrar achados. Nenhum arquivo de código é modificado.
+</context>
+
+<owasp_scope>
+## Mapeamento OWASP → Stack
+
+Antes de auditar, determinar quais categorias se aplicam lendo `STACK.md` e `INTEGRATIONS.md`:
+
+| Categoria OWASP | Aplicável quando |
+|-----------------|-----------------|
+| A01 — Broken Access Control | App com autenticação/autorização ou rotas protegidas |
+| A02 — Cryptographic Failures | Dados sensíveis em trânsito ou em repouso; senhas; tokens |
+| A03 — Injection | DB queries, shell commands, parsers de entrada, templates |
+| A04 — Insecure Design | Ausência de modelagem de ameaças; fluxos de negócio sem validação |
+| A05 — Security Misconfiguration | Config de servidor, CORS, headers HTTP, variáveis de ambiente |
+| A06 — Vulnerable Components | Dependências com CVEs conhecidos; versões sem suporte |
+| A07 — Authentication Failures | Login, sessão, JWT, OAuth, tokens de reset |
+| A08 — Software Integrity | Supply chain; checksums; CI/CD sem verificação |
+| A09 — Logging & Monitoring | Ausência de logs de eventos críticos; dados sensíveis em logs |
+| A10 — SSRF | Requisições a URLs controladas pelo usuário; fetch/proxy interno |
+
+**Selecionar apenas as categorias aplicáveis** ao stack identificado. Listar explicitamente as ignoradas e o motivo.
+</owasp_scope>
+
+<process>
+1. Ler `.oxe/codebase/STACK.md`, `.oxe/codebase/STRUCTURE.md`, `.oxe/codebase/INTEGRATIONS.md`, `.oxe/codebase/CONCERNS.md`.
+2. Selecionar categorias OWASP aplicáveis ao stack (ver `<owasp_scope>`); registrar as descartadas.
+3. Para cada categoria aplicável:
+   a. Identificar **arquivos críticos** (auth, input handlers, DB queries, configs, env, deps).
+   b. Ler os arquivos relevantes (Glob, Grep, Read) procurando padrões de risco.
+   c. Registrar achados com: localização (`path:linha`), padrão encontrado, severidade (P0/P1/P2), recomendação.
+4. Ler `.oxe/PLAN.md` se existir — vincular achados P0/P1 a tarefas `Tn` existentes quando possível, ou criar sugestão `T_new`.
+5. Escrever `.oxe/SECURITY.md` a partir de `oxe/templates/SECURITY.template.md`.
+6. Atualizar `.oxe/STATE.md`: nota de segurança (ex.: `security_audit: YYYY-MM-DD | P0:N | P1:N | P2:N`).
+7. Responder no chat: total de achados por severidade, arquivos mais críticos identificados, próximo passo (P0 presentes → bloquear deploy; apenas P2 → ação opcional).
+</process>
+
+<success_criteria>
+- [ ] `.oxe/SECURITY.md` existe com categorias OWASP selecionadas e justificativa de descarte.
+- [ ] Cada achado tem: localização, padrão, severidade, recomendação.
+- [ ] Categorias sem achados registradas como "nenhum achado nesta categoria".
+- [ ] Achados P0/P1 vinculados a `Tn` existente ou sugestão `T_new`.
+- [ ] Nenhum arquivo de código foi modificado.
+- [ ] STATE.md tem linha `security_audit` com data e contagem de achados.
+</success_criteria>

package/oxe/workflows/spec.md

@@ -1,42 +1,191 @@
 # OXE — Workflow: spec
 
 <objective>
-Registrar a intenção do usuário em **`.oxe/SPEC.md`**: escopo, **critérios de aceite com IDs estáveis (A1, A2, …)** e coluna **Como verificar**, não objetivos e suposições. A spec é o contrato antes do plano.
+Conduzir as **5 fases** do processo de especificação e produzir dois artefatos:
 
-Para trabalho **muito pequeno**, o usuário pode preferir **`oxe:quick`** (`.oxe/QUICK.md`) em vez deste fluxo — não bloqueie: se pedirem explicitamente quick, redirecione.
+1. **`.oxe/SPEC.md`** — contrato formal com critérios de aceite estáveis (A1, A2, …) e coluna **Como verificar**.
+2. **`.oxe/ROADMAP.md`** — fases de entrega mapeadas a requisitos (R-ID) e critérios (A*).
 
-Se **`.oxe/config.json`** tiver `discuss_before_plan: true`, mencionar no fim que o próximo passo recomendado é **`oxe:discuss`** antes do plano.
+**Foco em redução de requisições:** as fases são estruturadas para extrair o máximo de informação por rodada — nunca uma pergunta por vez, sempre blocos coesos.
 
-Entrada: texto livre na mensagem ou caminho `@arquivo.md` / anexo para incorporar PRD/notas.
+Para trabalho **muito pequeno** que não justifica spec completa: redirecionar para **`oxe:quick`**.
+
+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:** preferencialmente **scan** já executado. Se não existir scan, mencionar na spec que o mapa está pendente.
-
-Leia `.oxe/STATE.md` e, se existirem, trechos relevantes de `.oxe/codebase/OVERVIEW.md` e `STACK.md` para não contradizer o projeto real.
+**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
 
-Use o template **`oxe/templates/SPEC.template.md`**: tabela **Critérios de aceite** com colunas **ID | Critério | Como verificar**.
+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
 
-**Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — epicos por **trilha** (batch, online, desktop↔SQL), critérios **A*** verificáveis por Grep/leitura/checklist, e secções opcionais alinháveis a `spec_required_sections` em `.oxe/config.json` (ver `oxe/templates/CONFIG.md`).
+**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.
 
-**Exploratório / sistema grande / reversa / modernização:** quando a tecnologia ou o âmbito for incerto, houver necessidade de **mapear** o sistema, **engenharia reversa** ou **hipóteses de modernização** antes de tarefas executáveis, recomendar **`oxe:research`** (notas datadas em `.oxe/research/` + índice `.oxe/RESEARCH.md`) **antes** de `oxe:plan` — sugestão, não bloqueio obrigatório para specs mínimas.
+Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.template.md`**.
 </context>
 
+<fase_1_perguntas>
+## Fase 1 — Perguntas
+
+**Objetivo:** entender completamente a ideia antes de qualquer escrita de artefato.
+
+**Regra de ouro:** nunca uma pergunta por vez — sempre um **bloco coeso** de 3-5 perguntas por rodada. Máximo **3 rodadas**; sinalize quando achar que tem entendimento completo e peça confirmação antes de avançar.
+
+**Blocos de perguntas (adaptar ao contexto):**
+
+*Bloco A — Objetivo e motivação:*
+- Qual o problema central que isso resolve? Quem se beneficia?
+- Há uma solução atual (mesmo que ruim)? O que falha nela?
+- Como o sucesso será medido — qual o indicador mais importante?
+
+*Bloco B — Restrições e tecnologia:*
+- Quais tecnologias ou frameworks são obrigatórios ou proibidos?
+- Há restrições de prazo, orçamento, tamanho do time ou infraestrutura?
+- Quais integrações existentes precisam ser mantidas?
+
+*Bloco C — Casos extremos e escopo:*
+- Quais cenários de erro ou casos extremos são críticos de tratar na v1?
+- O que definitivamente está **fora** do escopo desta entrega?
+- Há comportamento esperado que você sabe que não é óbvio?
+
+**Estratégia de rodadas:**
+- Rodada 1: blocos A + B (entendimento geral)
+- Rodada 2: bloco C + clarificações específicas (se necessário)
+- Rodada 3 (máx): apenas se ainda houver ambiguidade crítica
+- Após rodada 3: avançar para Fase 2 mesmo com suposições explícitas
+
+**Ao final:** "Acho que entendi completamente. Confirma antes de avançarmos para pesquisa/requisitos? [resumo em 3-5 bullets]"
+</fase_1_perguntas>
+
+<fase_2_pesquisa>
+## Fase 2 — Pesquisa (opcional, recomendada)
+
+**Objetivo:** investigar domínios incertos antes de escrever requisitos.
+
+**Proposta ao usuário:** com base na Fase 1, listar 2-4 áreas de investigação sugeridas e perguntar quais investigar. Exemplos:
+- "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
+- 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.
+
+**Explorações grandes / sistemas legado:** ver **`oxe/workflows/references/legacy-brownfield.md`** — progressive disclosure por área, multiple sessions, epicos por trilha.
+</fase_2_pesquisa>
+
+<fase_3_requisitos>
+## Fase 3 — Requisitos
+
+**Objetivo:** extrair uma tabela clara de requisitos com versionamento (v1/v2/fora).
+
+**Incorporar primeiro:** verificar `.oxe/OBSERVATIONS.md` por entradas `pendente` com impacto `spec` ou `all` — incorporar aqui antes de finalizar a tabela.
+
+**Formato da tabela:**
+
+| R-ID | Requisito | Versão | Critério de aceite |
+|------|-----------|--------|--------------------|
+| R1 | [o que o sistema deve fazer] | v1 | A1 — [como verificar] |
+| R2 | [outro requisito] | v1 | A2 — [como verificar] |
+| R3 | [requisito futuro] | v2 | A3 — [quando implementado] |
+| R4 | [fora do escopo] | fora | — |
+
+**Definições:**
+- **v1** = MVP essencial; entra no próximo `/oxe-plan`
+- **v2** = evolução futura; entra em ciclos seguintes
+- **fora** = explicitamente descartado desta entrega
+
+**Apresentar ao usuário para validação** antes de avançar para Fase 4. Se ajustar: atualizar tabela e repetir até aprovação.
+</fase_3_requisitos>
+
+<fase_4_roteiro>
+## Fase 4 — Roteiro
+
+**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `.oxe/ROADMAP.md`.
+
+**Lógica de agrupamento:**
+- Agrupar requisitos v1 em fases por **dependência técnica** e **valor entregável**
+- Cada fase deve ter resultado demonstrável (não apenas código interno)
+- 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`:
+
+```markdown
+---
+oxe_doc: roadmap
+status: draft
+updated: <data>
+spec_ref: .oxe/SPEC.md
+---
+
+## Fase 1 — [Nome]
+**Requisitos:** R1, R3
+**Critérios de aceite:** A1, A2, A3
+**Escopo:** ...
+
+## Fase 2 — [Nome]
+**Requisitos:** R2, R5
+**Critérios de aceite:** A4, A5
+**Escopo:** ...
+
+## Fora do escopo (v2+)
+- R4: [descrição] — motivo
+```
+</fase_4_roteiro>
+
+<fase_5_aprovacao>
+## Fase 5 — Aprovação e próximo passo
+
+**Objetivo:** confirmar o roteiro com o usuário e redirecionar para o plano.
+
+**Apresentar resumo:**
+- Objetivo em 1 frase
+- Requisitos v1 (N itens), v2 (M itens), fora (K itens)
+- Roteiro: Fase 1 → N critérios; Fase 2 → M critérios
+- Critérios de aceite da Fase 1: A1, A2, …
+
+**Perguntar ao usuário:**
+> "Roteiro aprovado? Quer gerar o plano agora ou ajustar algo antes?"
+
+**Se aprovado — oferecer os próximos passos:**
+
+| Opção | Quando usar | Próximo passo |
+|-------|-------------|---------------|
+| Plano simples | Tarefa clara, sem orquestração multi-agente | `/oxe-plan` |
+| Plano com agentes | Time distribuído, domínios distintos, ondas paralelas | `/oxe-plan-agent` |
+| Discutir antes | `discuss_before_plan: true` em config, ou risco técnico | `/oxe-discuss` → `/oxe-plan` |
+
+**Se ajustar:** voltar à fase indicada (Requisitos, Roteiro ou Perguntas) e repetir.
+
+**Ao finalizar:**
+- Marcar `ROADMAP.md` → `status: approved`
+- Atualizar `STATE.md`: `phase: spec_ready`, próximo passo conforme escolha
+</fase_5_aprovacao>
+
 <process>
-1. Resolver entrada: se começar com `@`, ler arquivo; senão usar o texto da conversa.
-2. Criar ou atualizar **`.oxe/SPEC.md`** usando `oxe/templates/SPEC.template.md` como esqueleto. Se o ficheiro já existir com YAML inicial (`---` … `---` antes do primeiro `#`), **preservar** chaves existentes; **atualizar** `updated:` com a data ISO do dia; ajustar `status` (ex. para `ready`) se o utilizador declarar a spec fechada. Se não houver frontmatter, pode adicioná-lo na primeira edição substancial.
-3. Garantir seções:
-   - **Objetivo** — uma frase clara.
-   - **Escopo** — bullets dentro / fora.
-   - **Critérios de aceite** — tabela com IDs **A1**, **A2**, … (testáveis).
-   - **Suposições e riscos**.
-   - **Referências** — paths se conhecidos.
-4. Atualizar **`.oxe/STATE.md`**: fase `spec_ready`, próximo passo `oxe:discuss` ou `oxe:plan` conforme `discuss_before_plan`.
-5. Responder com resumo da spec e no máximo 3 perguntas objetivas se algo crítico estiver ambíguo.
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `.oxe/OBSERVATIONS.md` (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`:
+   - 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:`
+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`.
 </process>
 
 <success_criteria>
-- [ ] `.oxe/SPEC.md` existe e cada critério tem ID **A*** e forma de verificar.
-- [ ] `STATE.md` atualizado.
-- [ ] Ambiguidades críticas foram perguntas ou registradas como suposição explícita.
+- [ ] `.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).
+- [ ] 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`.
+- [ ] Máximo 3 rodadas de perguntas utilizadas — não mais.
 </success_criteria>

package/oxe/workflows/verify.md

@@ -1,44 +1,106 @@
 # OXE — Workflow: verify
 
 <objective>
-Executar ou orientar verificação pós-implementação: rodar os comandos definidos no **PLAN.md**, confrontar **cada critério da SPEC** (IDs **A1**, **A2**, …) com o código e os testes, e registrar o resultado em **`.oxe/VERIFY.md`** (e atualizar **STATE**).
+Executar ou orientar verificação pós-implementação em **quatro camadas progressivas**:
 
-Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela; caso contrário, percorrer todas as tarefas com blocos **Verificar**.
+1. **Auditoria de pré-execução** — verificar que o PLAN está íntegro antes de iniciar (gate de qualidade).
+2. **Verificação de tarefas e critérios** — rodar comandos do PLAN e cruzar cada critério da SPEC (IDs **A1**, **A2**, …) com evidência.
+3. **Fidelidade de decisões** — cruzar cada decisão **D-NN** do DISCUSS.md com a implementação.
+4. **UAT (Checklist de aceite)** — checklist manual para o usuário confirmar entregáveis.
+
+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.
+- 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` e `after_verify_suggest_pr` controlam passos opcionais (se o arquivo não existir, use o mesmo padrão do `config.template.json`).
+- 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.
-- **Pós-verify (opcional):** para auditoria de **cobertura** e gaps de verificabilidade (sem substituir este passo), **`oxe:validate-gaps`** → `.oxe/VALIDATION-GAPS.md` (ver **`oxe/workflows/validate-gaps.md`**).
-- **Rotina compact/checkpoint (opcional):** se esta entrega alterou **estrutura**, **stack** ou **pastas** de forma relevante, sugira **`/oxe-compact`** para alinhar `.oxe/codebase/` ao repo (e `CODEBASE-DELTA.md` + `RESUME.md`). Após **verify** com sucesso e antes de abrir nova entrega grande, um **`/oxe-checkpoint`** com slug curto pode marcar estado estável — **não** faz parte dos critérios de sucesso abaixo.
+- **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.
 </context>
 
+<camada_1_pre_exec_audit>
+**Camada 1 — Auditoria de pré-execução** (roda *antes* de iniciar os comandos de verify)
+
+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).
+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.
+</camada_1_pre_exec_audit>
+
+<camada_2_tarefas_e_criterios>
+**Camada 2 — Verificação de tarefas e critérios SPEC**
+
+Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconjunto se foco Tn). Para **cada ID de critério** usado na SPEC (A1, A2, …), registrar se passou com evidência (Read/Grep, saída de teste resumida).
+</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)
+
+Para cada decisão na tabela de DISCUSS.md:
+1. Localizar a(s) tarefa(s) que referenciam esse ID em **Decisão vinculada:**.
+2. Verificar que a implementação reflete a decisão (Grep/Read dos arquivos da tarefa).
+3. Registrar na tabela **Fidelidade de decisões** do VERIFY.md: ID | Decisão (resumo) | Tarefa(s) | Implementado? | Evidência.
+
+Se uma decisão D-NN não tem tarefa vinculada **e** não há nota de gap no PLAN: marcar como `divergência` e adicionar ao bloco **Gaps**.
+</camada_3_fidelidade_decisoes>
+
+<camada_4_uat>
+**Camada 4 — UAT (User Acceptance Testing)** (ativa se `after_verify_suggest_uat` não for `false` na config)
+
+Gerar uma **Checklist UAT** no VERIFY.md com passos manuais derivados dos critérios de aceite. Formato:
+
+```markdown
+## Checklist UAT (aceite manual)
+
+Para cada critério da SPEC que exige validação manual:
+- [ ] A1: (descrição do passo a executar pelo usuário, em linguagem simples)
+- [ ] A2: …
+
+**Instruções:** execute os itens acima no ambiente real e marque ✓. Se algum falhar, abra um item em Gaps abaixo.
+```
+
+O preenchimento da checklist é responsabilidade do **usuário** (não do agente de IA).
+</camada_4_uat>
+
 <process>
-1. Ler `.oxe/SPEC.md`, `.oxe/PLAN.md`, `.oxe/STATE.md`.
-2. Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconjunto se foco Tn).
-3. Para **cada ID de critério** usado na SPEC (A1, A2, …), registrar se passou, com evidência (Read/Grep, saída de teste resumida).
-4. Escrever **`.oxe/VERIFY.md`** com:
+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`.
+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:
    - 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.
    - **Tabela — Critérios SPEC:** ID (A1…) | Critério (resumo) | Evidência | Passou? | Notas.
-   - **Gaps** — o que falhou e sugestão de correção (pode virar novas entradas no PLAN); se não houver, escrever explicitamente `Nenhum gap restante` ou equivalente.
-5. Atualizar **`.oxe/STATE.md`**: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
-5b. **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` se ainda não houve execute formal mas a trilha fechou aqui), 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.
-5c. **Arquivo plan-agent (opcional, recomendado após fecho com sucesso):** se o passo **5b** marcou o blueprint como **`closed`** e existem **`.oxe/plan-agent-messages/`** (com mensagens) ou **`plan-agents.json`** na raiz `.oxe/`, propor ao utilizador **arquivar** em **`.oxe/archive/plan-agent-runs/<runId>/`** conforme **`oxe/workflows/references/plan-agent-chat-protocol.md`** (secção *Artefactos no repositório após fecho*): subpasta **`messages/`** com os handoffs, cópia de **`plan-agents.json`**, depois **esvaziar** **`.oxe/plan-agent-messages/`** (ou recriar só `README.md` a partir do template) e **remover** **`.oxe/plan-agents.json`** da raiz se já estiver copiado no arquivo. Se o utilizador preferir **manter** tudo na raiz para um PR único, respeitar — o protocolo trata o arquivo como **recomendação**, não obrigatório do gate de verify.
-6. 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 — isso alimenta o replanejamento.
-7. **Só se todas as verificações relevantes passarem:** se `after_verify_draft_commit` não for `false`: acrescentar em **VERIFY.md** a seção **Rascunho de commit** — mensagem convencional (ex.: `feat:` / `fix:`) + bullets alinhados aos critérios **A***; **não** incluir segredos.
-8. **Só se passou:** se `after_verify_suggest_pr` não for `false`: acrescentar **Checklist PR** — branch base, título sugerido, screenshots se UI, links a SPEC/PLAN, testes executados.
+   - **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).
+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.
+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.
+8. **Só se todas as verificações relevantes passarem:** se `after_verify_draft_commit` não for `false`: acrescentar em **VERIFY.md** a seção **Rascunho de commit** — mensagem convencional (ex.: `feat:` / `fix:`) + bullets alinhados aos critérios **A*** e decisões **D-NN**; **não** incluir segredos.
+9. **Só se passou:** se `after_verify_suggest_pr` não for `false`: acrescentar **Checklist PR** — branch base, título sugerido, screenshots se UI, links a SPEC/PLAN/DISCUSS, testes executados.
 </process>
 
 <success_criteria>
-- [ ] VERIFY.md reflete o que foi de fato verificado (tarefas **e** critérios SPEC por ID).
+- [ ] VERIFY.md contém as quatro seções: Auditoria de pré-execução, Tabela de tarefas, Tabela de critérios SPEC, Fidelidade de decisões (quando aplicável), Checklist UAT.
+- [ ] Auditoria de pré-execução passou ou divergências foram documentadas.
 - [ ] Falhas têm próximo passo claro (qual tarefa replanejar ou qual arquivo corrigir); se falhou, próximo passo inclui **plan** com replanejamento ou correção direta.
 - [ ] STATE.md atualizado.
 - [ ] 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.
 </success_criteria>

package/oxe/workflows/workstream.md

@@ -0,0 +1,96 @@
+# OXE — Workflow: workstream
+
+<objective>
+Gerenciar **trilhas de desenvolvimento paralelas** dentro do mesmo projeto. Cada workstream tem seu próprio ciclo SPEC → PLAN → EXECUTE → VERIFY independente, sem interferir no pipeline principal.
+
+Subcomandos:
+- `/oxe-workstream list` — listar workstreams ativos.
+- `/oxe-workstream new <nome>` — criar novo workstream.
+- `/oxe-workstream switch <nome>` — definir workstream ativo no contexto atual.
+- `/oxe-workstream status [nome]` — exibir status de um workstream.
+- `/oxe-workstream close <nome>` — fechar workstream e mesclar contexto ao pipeline principal.
+</objective>
+
+<context>
+**Por que workstreams?**
+
+O pipeline OXE padrão (`.oxe/SPEC.md`, `PLAN.md`, etc.) é linear — uma entrega por vez. Workstreams permitem:
+- Desenvolvimento de features paralelas sem sobrescrever artefatos.
+- Trabalho em `bugfix/auth` e `feature/billing` simultaneamente.
+- Times menores trabalhando em trilhas independentes com contextos separados.
+
+**Estrutura no disco:**
+```
+.oxe/
+  workstreams/
+    <nome>/
+      SPEC.md
+      PLAN.md
+      VERIFY.md
+      DISCUSS.md      (opcional)
+      STATE.md        (estado local da trilha)
+      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>
+
+<process_list>
+**`/oxe-workstream list`**
+
+1. Ler `.oxe/workstreams/` — 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>
+
+<process_new>
+**`/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).
+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)`.
+
+**Convenção:** para operar em um workstream, prefixar os artefatos com `--workstream=<nome>` ou ativar com `/oxe-workstream switch <nome>`.
+</process_new>
+
+<process_switch>
+**`/oxe-workstream switch <nome>`**
+
+1. Verificar que `.oxe/workstreams/<nome>/` existe.
+2. Atualizar STATE.md principal: seção **Workstream ativo** com nome.
+3. Confirmar no chat: `Workstream ativo: <nome>. Artefatos em .oxe/workstreams/<nome>/`.
+
+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>
+
+<process_status>
+**`/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.
+3. Ler SPEC, PLAN, VERIFY do workstream (se existirem).
+4. Exibir resumo: fase, critérios, gaps, próximo passo.
+</process_status>
+
+<process_close>
+**`/oxe-workstream close <nome>`**
+
+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/`.
+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>
+
+<success_criteria>
+- [ ] `.oxe/workstreams/<nome>/` existe com STATE.md local.
+- [ ] STATE.md principal lista workstream na seção **Workstreams ativos**.
+- [ ] Workflows OXE operam no workstream ativo quando configurado.
+- [ ] Ao encerrar: artefatos arquivados e STATE principal atualizado.
+</success_criteria>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oxe-cc",
-  "version": "0.3.9",
+  "version": "0.6.0",
   "description": "OXE — spec-driven workflows in .oxe/; integrates with Cursor, GitHub Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity (npx)",
   "license": "GPL-3.0",
   "author": "",
@@ -49,7 +49,8 @@
     ".github",
     "commands",
     "AGENTS.md",
-    "README.md"
+    "README.md",
+    "CHANGELOG.md"
   ],
   "scripts": {
     "sync:cursor": "node scripts/sync-cursor-from-prompts.cjs",