oxe-cc 0.7.1 → 0.9.1

package/oxe/workflows/research.md

@@ -7,6 +7,7 @@ Não substitui **SPEC** nem **PLAN**; alimenta decisões que depois entram na SP
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-discovery.md`. A investigação deve separar fatos, inferências e lacunas antes de consolidar conclusões.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, research vive em `.oxe/<active_session>/research/`; sem sessão ativa, usar `.oxe/research/`.
 - Tratar pesquisa como **investigação estruturada**, não como nota solta. Cada investigação deve ter objetivo, fontes, modo, profundidade, conclusões e impacto na trilha.
 - **Uma sessão = um ficheiro novo** em `research/`; não sobrescrever notas antigas salvo correção explícita do utilizador.
@@ -45,8 +46,13 @@ Anotar `thinking_depth: surface | standard | deep` no frontmatter da nota de pes
 6. Atualizar `INVESTIGATIONS.md` do escopo resolvido com objetivo, fontes, modo, profundidade, conclusão e impacto na trilha. Se não existir, criá-lo.
 7. Ler **`.oxe/SPEC.md`**, **`.oxe/codebase/*`** e código alvo (Glob/Grep/Read) conforme âmbito.
 8. Atualizar **`.oxe/STATE.md`**: nota de fase / próximo passo típico `oxe:plan`, ou `oxe:spec` se faltar contrato, ou `oxe:ui-spec` se o foco for UI antes do plano.
-9. Responder no chat em 5–10 linhas: caminho da nota nova, confirmação de atualização do índice, próximo passo OXE.
-</process>
+9. Responder no chat em 5–10 linhas, nesta ordem:
+   - **Fatos**
+   - **Inferências**
+   - **Lacunas**
+   - **Próximo passo**
+   Incluir o caminho da nota nova e a confirmação de atualização do índice.
+</process>
 
 <success_criteria>
 - [ ] Existe novo ficheiro em `research/YYYY-MM-DD-<slug>.md` no escopo correto com secções base preenchidas de forma útil.

package/oxe/workflows/retro.md

@@ -72,8 +72,13 @@ Ao ler `LESSONS.md`, priorizar entradas com **`Frequência >= 2`** ou **`Impacto
    - Apenas entradas genuinamente novas recebem uma nova linha na tabela de índice (mais recente primeiro).
    - Adicionar seção `### C-NN` com as lições novas do ciclo (ou referência às entradas incrementadas).
    - **Nunca apagar** entradas anteriores — só mudar `Status: resolvido` se a lição foi definitivamente superada.
-8. Atualizar **`.oxe/STATE.md`**: campo `last_retro: YYYY-MM-DD`.
-9. Responder no chat: ID do ciclo (C-NN), número de lições registradas, lição mais crítica em 1 frase, sugestão do próximo ciclo (`/oxe-scan` ou `/oxe-spec`).
+8. **Atualizar `.oxe/lessons-metrics.json`** (se existir) ou criar se LESSONS.md já tiver entradas:
+   - Para cada lição nova ou incrementada neste ciclo, verificar se já existe entrada em `lessons-metrics.json` com o mesmo `id` (L-NN).
+   - Se existe: chamar `updateLessonMetric` com `{ cycle: "C-NN", verify_status: "<verify_complete|verify_failed>", saved_hours: <estimativa ou 0> }`.
+   - Se não existe: criar nova entrada com `applied_cycles: ["C-NN"]`, `outcomes: [...]`, `success_rate: 1.0` (ou `0.0` se falhou), `status: "active"`, `deprecation_threshold: 0.5`.
+   - Lições com `success_rate < 0.5` e ≥ 3 observações → marcar `status: "deprecated"` e registrar aviso no chat.
+9. Atualizar **`.oxe/STATE.md`**: campo `last_retro: YYYY-MM-DD`.
+10. Responder no chat: ID do ciclo (C-NN), número de lições registradas, lição mais crítica em 1 frase, lições depreciadas (se houver), sugestão do próximo ciclo (`/oxe-scan` ou `/oxe-spec`).
 </process>
 
 <success_criteria>

package/oxe/workflows/review-pr.md

@@ -4,8 +4,9 @@
 Rever alterações como num pull request: **URL do GitHub** (`…/pull/<n>`), **branches** ou **SHAs**. Cobre diff, risco, convenções do projeto e sugestões acionáveis. **Não** substitui CI nem testes manuais; complementa-os.
 </objective>
 
-<context>
-- **Base** e **head** são nomes de branch, tags ou SHAs (ex.: `main` e `feature/foo`).
+<context>
+- Aplicar `oxe/workflows/references/reasoning-review.md`. A revisão deve ser findings-first, com severidade e evidência antes de qualquer resumo.
+- **Base** e **head** são nomes de branch, tags ou SHAs (ex.: `main` e `feature/foo`).
 - **URL de PR no GitHub** — O usuário pode colar o link (ex.: `https://github.com/org/repo/pull/10` ou atalho `org/repo#10`). O número da PR é o segmento depois de `/pull/`.
 - Em Git, o diff “estilo PR” (só o que a branch introduz) usa o **merge base**: `git diff base...head` (três pontos).
 - Diff literal entre pontas: `git diff base..head` (dois pontos) — útil quando o usuário pede explicitamente.
@@ -28,12 +29,14 @@ Rever alterações como num pull request: **URL do GitHub** (`…/pull/<n>`), **
    Se o sandbox bloquear Git, pedir ao usuário que cole o output de `git diff base...head` ou use o diff da UI do GitHub/GitLab.
    Se o diff já foi obtido no passo 2 (URL da PR), **não** repetir este passo.
 4. **Ler contexto do projeto** — Se existirem, usar trechos relevantes de `.oxe/codebase/CONVENTIONS.md`, `STACK.md`, `OVERVIEW.md` e, se aplicável, `.oxe/SPEC.md` / `.oxe/PLAN.md` para alinhar expectativas (sem assumir que o PR cobre só OXE).
-5. **Analisar** — Estruturar a resposta com:
-   - **Resumo** — O que muda em 3–6 frases.
-   - **Arquivos / áreas** — Agrupar por domínio (API, UI, config, etc.).
-   - **Riscos** — Regressões, breaking changes, segurança (inputs, segredos, auth), desempenho óbvio, migrações.
-   - **Testes** — O que deveria ser coberto ou rodar localmente (comandos sugeridos se conhecidos do repo).
-   - **Checklist PR** — Título sugerido, descrição curta, breaking changes, rollback.
+5. **Analisar** — Estruturar a resposta com:
+   - **Findings** — achados ordenados por severidade, com arquivo/área afetada e evidência.
+   - **Arquivos / áreas** — Agrupar por domínio (API, UI, config, etc.).
+   - **Riscos** — Regressões, breaking changes, segurança (inputs, segredos, auth), desempenho óbvio, migrações.
+   - **Testes** — O que deveria ser coberto ou rodar localmente (comandos sugeridos se conhecidos do repo).
+   - **Perguntas abertas** — pontos que impedem confiança alta na revisão.
+   - **Resumo** — O que muda em 3–6 frases, apenas depois dos achados.
+   - **Checklist PR** — Título sugerido, descrição curta, breaking changes, rollback.
 6. **Opcional em disco** — Se o usuário pedir registro: criar ou atualizar **`.oxe/PR-REVIEW.md`** com data, URL ou refs (base/head), resumo, achados e próximos passos (Markdown legível).
 </process>
 
@@ -42,4 +45,5 @@ Rever alterações como num pull request: **URL do GitHub** (`…/pull/<n>`), **
 - [ ] A análise baseia-se no diff (terminal ou colado), não só em suposições.
 - [ ] Há seção de riscos e de testes/verificação sugerida.
 - [ ] Nenhum segredo ou credencial é repetido na análise; redigir se aparecerem no diff.
+- [ ] Se `.oxe/PR-REVIEW.md` foi criado (passo 6), a resposta menciona o caminho do artefato gerado.
 </success_criteria>

package/oxe/workflows/route.md

@@ -6,19 +6,22 @@ Desambiguar pedidos em **linguagem natural** e devolver **exatamente um** destin
 Este passo é **meta**: só orientação. A execução real pertence ao workflow apontado.
 </objective>
 
-<context>
-- A tabela canónica de mapeamento vive em **`oxe/workflows/help.md`** na secção **Router (linguagem natural)**.
-- Saída no chat: **um** comando (`/oxe-*` ou `npx oxe-cc …`) e **uma** frase de justificativa — alinhado a `next.md` (sem alternativas equiparáveis).
-</context>
-
-<process>
-1. Ler a secção **Router** em `oxe/workflows/help.md` (ou `.oxe/workflows/help.md` no projeto).
-2. Classificar a intenção do utilizador e escolher **uma** linha da tabela.
-3. Responder apenas:
-   - **Comando:** …
-   - **Workflow:** `oxe/workflows/<nome>.md`
-   - **Por quê:** (uma frase)
-4. Não criar ficheiros em `.oxe/` salvo o utilizador pedir explícito registo; opcional: uma linha em `STATE.md` (“última orientação route: …”) se o utilizador quiser rastreio.
+<context>
+- Aplicar `oxe/workflows/references/reasoning-status.md`. A saída deve ser curta, orientada a decisão e com confiança explícita quando houver ambiguidade real.
+- A tabela canónica de mapeamento vive em **`oxe/workflows/help.md`** na secção **Router (linguagem natural)**.
+- Saída no chat: **um** comando (`/oxe-*` ou `npx oxe-cc …`) e **uma** frase de justificativa — alinhado a `next.md` (sem alternativas equiparáveis).
+</context>
+
+<process>
+1. Ler a secção **Router** em `oxe/workflows/help.md` (ou `.oxe/workflows/help.md` no projeto).
+2. Classificar a intenção do utilizador e escolher **uma** linha da tabela.
+3. Se a classificação não for claramente dominante, ainda devolver um único destino, mas explicitar a confiança da escolha e a lacuna que poderia mudar o roteamento.
+4. Responder apenas:
+   - **Comando:** …
+   - **Workflow:** `oxe/workflows/<nome>.md`
+   - **Por quê:** (uma frase)
+   - **Confiança:** alta | média | baixa (só quando houver ambiguidade real)
+5. Não criar ficheiros em `.oxe/` salvo o utilizador pedir explícito registo; se o utilizador pedir rastreio: acrescentar uma linha em **`.oxe/STATE.md`** (ex.: `last_route: /oxe-scan — YYYY-MM-DD`).
 </process>
 
 <success_criteria>

package/oxe/workflows/security.md

@@ -9,6 +9,7 @@ Não substitui ferramentas de análise estática (SAST) — identifica padrões
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-review.md`. O resumo em chat deve começar por achados, não por panorama narrativo.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. O relatório de segurança segue a sessão ativa em `verification/`, mas continua a ler `codebase/` global.
 - **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.
@@ -49,8 +50,8 @@ Antes de auditar, determinar quais categorias se aplicam lendo `STACK.md` e `INT
 4. Ler `PLAN.md` do escopo resolvido se existir — vincular achados P0/P1 a tarefas `Tn` existentes quando possível, ou criar sugestão `T_new`.
 5. Escrever `SECURITY.md` no escopo resolvido 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>
+7. Responder no chat nesta ordem: **Findings**, **Perguntas abertas**, **Riscos residuais**, **Resumo**. P0 presentes → bloquear deploy; apenas P2 → ação opcional.
+</process>
 
 <success_criteria>
 - [ ] `SECURITY.md` existe no escopo correto com categorias OWASP selecionadas e justificativa de descarte.

package/oxe/workflows/session.md

@@ -11,6 +11,8 @@ Subcomandos:
 - `status`
 - `close`
 - `migrate <nome>`
+- `fork [nome-opcional]`
+- `revert <checkpoint-slug>`
 </objective>
 
 <context>
@@ -137,6 +139,45 @@ Subcomandos:
    - ignorados por inexistência
 </process_migrate>
 
+<process_fork>
+## `fork [nome-opcional]`
+
+1. Verificar que existe `active_session` em `.oxe/STATE.md`. Se não houver, informar e sair.
+2. Ler `SESSION.md` da sessão ativa; anotar ID de origem (`sNNN`).
+3. Calcular próximo ID `sMMM` a partir de `.oxe/SESSIONS.md`.
+4. Se nome não fornecido, usar `fork-<slug-original>`.
+5. Criar `.oxe/sessions/sMMM-<slug>/` com as mesmas subpastas: `spec/`, `plan/`, `execution/`, `verification/`, `checkpoints/`, `research/`, `artifacts/`, `workstreams/`.
+6. **Copiar** (não mover) todos os arquivos da sessão ativa para a nova sessão, preservando estrutura de diretórios. Não copiar diretórios vazios.
+7. Criar `SESSION.md` na nova sessão a partir de `SESSION.template.md`, com:
+   - `forked_from: sNNN`
+   - `forked_at: YYYY-MM-DD`
+   - `Status: active`
+   - `Resumo: Fork de sNNN — <slug-original>`
+8. Atualizar `.oxe/SESSIONS.md`:
+   - Adicionar linha da nova sessão (topo, status `active`)
+   - **Não** alterar status da sessão original
+9. Atualizar `.oxe/STATE.md`:
+   - `active_session: sessions/sMMM-<slug>`
+   - `session_id: sMMM`
+10. Registar evento no Histórico da SESSION.md original: `YYYY-MM-DD | Forked → sMMM`
+11. Responder no chat: ID novo, path, contagem de artefatos copiados, e lembrar que a sessão original permanece intacta.
+</process_fork>
+
+<process_revert>
+## `revert <checkpoint-slug>`
+
+1. Verificar que existe sessão ativa ou operar na raiz `.oxe/`.
+2. Resolver o checkpoint: procurar em `checkpoints/` (do escopo resolvido) arquivo cujo slug corresponda ao argumento. Se não encontrar, listar checkpoints disponíveis e pedir escolha.
+3. Ler o conteúdo do checkpoint (seção `## Snapshot`):
+   - Extrair campos de STATE: `phase`, `next_step` (campo `Comando:`), `execute_mode`, `Última onda executada`, `Tarefas concluídas`
+4. Atualizar `.oxe/STATE.md` com os valores do snapshot:
+   - Sobrescrever os campos extraídos do snapshot
+   - **Não apagar** campos ausentes no snapshot (preservar `active_session`, `session_id`, config refs, etc.)
+5. Registar no Histórico da SESSION.md (se sessão ativa): `YYYY-MM-DD | Revertido para checkpoint <slug>`
+6. Registar evento em `EXECUTION-RUNTIME.md` se existir: `Revert to checkpoint <slug>`
+7. Responder no chat: quais campos foram restaurados, quais permaneceram intactos, e próximo passo sugerido baseado no STATE restaurado.
+</process_revert>
+
 <process_default>
 ## Sem subcomando
 
@@ -150,4 +191,7 @@ Subcomandos:
 - [ ] `.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.
+- [ ] `fork` cria sessão nova com cópia dos artefatos sem modificar a sessão de origem.
+- [ ] `fork` registra `forked_from` na SESSION.md da sessão derivada.
+- [ ] `revert` restaura STATE.md a partir do snapshot do checkpoint, sem apagar campos ausentes.
 </success_criteria>

package/oxe/workflows/skill.md

@@ -0,0 +1,44 @@
+# OXE — Workflow: skill
+
+<objective>
+Descobrir, invocar e gerenciar **skills** — wrappers de invocação que unificam personas (comportamento LLM) e capabilities (ferramentas executáveis) num único ponto de entrada via `@<skill-id>`.
+
+Subcomandos:
+- `list`
+- `explain <id>`
+- `new <id>`
+- `@<id>` (invocação inline)
+</objective>
+
+<context>
+- **Skills globais** vivem em `oxe/personas/` (type: persona) — 8 roles builtin do pacote: `executor`, `planner`, `verifier`, `researcher`, `debugger`, `architect`, `ui-specialist`, `db-specialist`. Invocáveis via `@executor`, `@researcher`, etc.
+- **Skills de projeto** vivem em `.oxe/skills/<id>/SKILL.md` com frontmatter OXE. Têm prioridade sobre globais quando IDs colidem.
+- **Capabilities como skills:** capabilities em `.oxe/capabilities/<id>/` que tenham `SKILL.md` próprio também aparecem como skills de projeto.
+- **Resolução:** project (`.oxe/skills/`) → capabilities (`.oxe/capabilities/`) → global (`oxe/personas/`). Primeiro match vence.
+- Template: `oxe/templates/SKILL.template.md`
+</context>
+
+<process>
+1. **`list`** — Enumerar skills disponíveis em três camadas:
+   - Ler `oxe/personas/*.md` no pacote (globais, type persona)
+   - Ler `.oxe/skills/*/SKILL.md` se existir (projeto)
+   - Ler `.oxe/capabilities/*/SKILL.md` se existir (capabilities com manifest de skill)
+   - Apresentar tabela: `ID | Type | Scope | Invoke | Descrição`
+2. **`explain <id>`** — Resolver o skill pelo ID (project → capabilities → global), exibir frontmatter + seção Descrição + Saída esperada. Se não encontrar, listar skills disponíveis.
+3. **`new <id>`** — Criar `.oxe/skills/<id>/SKILL.md` a partir de `SKILL.template.md`. Solicitar ao utilizador: `name`, `type` (persona/capability/composite), `description`. Se o ID já existir, informar e oferecer `explain <id>`.
+4. **`@<id>` (inline)** — Quando o chat mencionar `@skill-id`:
+   - Resolver o skill pela ordem: project → capabilities → global
+   - Para type `persona`: ler e adotar o conteúdo da persona referenciada (princípios, ativação, saída esperada)
+   - Para type `capability`: ler manifesto da capability e orientar uso conforme `approval_policy`
+   - Para type `composite`: carregar ambas as referências em `references[]`
+   - Se não encontrado: listar skills disponíveis e pedir correção
+5. Atualizar `.oxe/STATE.md` apenas se o utilizador pedir registo explícito: `last_skill_invoked: @<id> — YYYY-MM-DD`.
+</process>
+
+<success_criteria>
+- [ ] `@<id>` resolve para exatamente um skill sem ambiguidade.
+- [ ] Skills de projeto têm prioridade sobre globais quando IDs colidem.
+- [ ] Nenhum artefato de SPEC/PLAN foi criado ou alterado por este passo.
+- [ ] `list` mostra skills de todas as três camadas com escopo identificado.
+</success_criteria>
+</output>

package/oxe/workflows/spec.md

@@ -13,8 +13,10 @@ 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.
+<context>
+**Contrato de raciocínio:** aplicar `oxe/workflows/references/reasoning-discovery.md`. Antes de perguntar, explorar o que o repo e os artefatos já respondem; separar fatos, inferências e lacunas.
+
+**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
 
 **Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de escrever, resolver artefatos obrigatórios, validar pré-condições e só então produzir a spec. O output desta fase deve deixar evidência estruturada suficiente para o `plan` decidir se o plano é realmente o melhor disponível.
 
@@ -220,22 +222,23 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 - Atualizar `STATE.md`: `phase: spec_ready`, próximo passo conforme escolha
 </fase_5_aprovacao>
 
-<process>
-1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
-2. Aplicar `adaptive-discovery.md`: classificar a demanda, verificar se há capabilities úteis e se investigações anteriores reduzem incerteza.
-3. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
-4. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
-5. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
-6. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
-7. 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
-   - Preencher explicitamente `Tipo de demanda` e `Incertezas estruturadas`
-   - Preservar chaves existentes se SPEC.md já existir; atualizar `updated:`
-7b. **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.
-8. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
-9. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
-10. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
+<process>
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
+2. Fazer uma exploração inicial do repo e dos artefatos antes da primeira rodada de perguntas. Consolidar internamente: fatos confirmados, inferências e lacunas.
+3. Aplicar `adaptive-discovery.md`: classificar a demanda, verificar se há capabilities úteis e se investigações anteriores reduzem incerteza.
+4. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
+5. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
+6. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
+7. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
+8. 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
+   - Preencher explicitamente `Tipo de demanda` e `Incertezas estruturadas`
+   - Preservar chaves existentes se SPEC.md já existir; atualizar `updated:`
+8b. **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.
+9. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
+10. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
+11. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
 </process>
 
 <success_criteria>

package/oxe/workflows/ui-review.md

@@ -6,18 +6,24 @@ Produzir **`.oxe/UI-REVIEW.md`**: auditoria da implementação UI face a **`.oxe
 Não substitui **`verify`**: cruza contrato UI; o verify global continua a amarrar PLAN + SPEC + evidência técnica.
 </objective>
 
-<context>
-- Se não existir `UI-SPEC.md`, pedir **`/oxe-ui-spec`** primeiro ou documentar em UI-REVIEW que a revisão é **ad hoc** (menos preferível).
-- Incluir checklist curta (ex.: pilares: semântica, foco, contraste, mensagens de erro, mobile).
-- **Bloqueios P0** (ex.: inacessível, fluxo quebrado) devem ser listados explicitamente; P1/P2 como melhorias.
-</context>
+<context>
+- Aplicar `oxe/workflows/references/reasoning-review.md`. A revisão UI deve começar pelos achados e bloqueios, não por resumo.
+- Se não existir `UI-SPEC.md`, pedir **`/oxe-ui-spec`** primeiro ou documentar em UI-REVIEW que a revisão é **ad hoc** (menos preferível).
+- Incluir checklist curta (ex.: pilares: semântica, foco, contraste, mensagens de erro, mobile).
+- **Bloqueios P0** (ex.: inacessível, fluxo quebrado) devem ser listados explicitamente; P1/P2 como melhorias.
+</context>
 
 <process>
 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>
+4. Indicar no chat nesta ordem:
+   - **Findings**
+   - **Perguntas abertas**
+   - **Riscos residuais**
+   - **Resumo**
+   Se há P0 → próximo passo típico **`/oxe-execute`** (correções); senão **`/oxe-verify`** para fecho global.
+</process>
 
 <success_criteria>
 - [ ] `UI-REVIEW.md` referencia secções do `UI-SPEC.md` quando existir.

package/oxe/workflows/update.md

@@ -16,7 +16,8 @@ Alinhar o projeto e integrações OXE à **versão mais recente** do pacote **ox
 1. Na raiz do projeto, executar **`npx oxe-cc update --check`** (ou equivalente com `oxe-cc` no PATH). Relatar ao utilizador: versão em execução, `latest` no npm e se há atualização.
 2. Se o utilizador quiser atualizar (ou se `--check` indicou versão mais nova e pediu explícito), executar **`npx oxe-cc update`** na mesma raiz — opcionalmente **`npx oxe-cc update --if-newer`** para evitar npx quando já está na última. Repassar flags extra ao pacote novo se o utilizador pedir (ex.: `--cursor --global`).
 3. Após uma instalação bem-sucedida, executar **`npx oxe-cc doctor`** e resumir o resultado (OK vs avisos/erros).
-4. Se o utilizador usar **Copilot CLI / skills**, lembrar **`/skills reload`** (ou reinício) após mudanças nos ficheiros do HOME; no **Gemini CLI**, **`/commands reload`** quando aplicável.
+4. Registar a atualização em **`.oxe/STATE.md`** do projeto (se existir): acrescentar linha `oxe_updated: YYYY-MM-DD vX.Y.Z` ou nota na secção Decisões com a versão nova.
+5. Se o utilizador usar **Copilot CLI / skills**, lembrar **`/skills reload`** (ou reinício) após mudanças nos ficheiros do HOME; no **Gemini CLI**, **`/commands reload`** quando aplicável.
 </process>
 
 <output>
@@ -29,5 +30,6 @@ Alinhar o projeto e integrações OXE à **versão mais recente** do pacote **ox
 - [ ] Correram na raiz do projeto, nesta ordem quando aplicável: `npx oxe-cc update --check`; depois `npx oxe-cc update` ou `npx oxe-cc update --if-newer` (ou o utilizador recusou atualizar após o `--check`).
 - [ ] Após qualquer instalação concluída, correr `npx oxe-cc doctor` e reportar se passou ou que avisos/erros restam.
 - [ ] O resumo menciona versões ou resultado da consulta ao npm quando `--check` ou update foi usado.
+- [ ] `.oxe/STATE.md` foi atualizado com a versão instalada (passo 4), quando o ficheiro existe.
 - [ ] Reload de skills/comandos externos (Copilot CLI, Gemini) foi lembrado quando relevante.
 </success_criteria>

package/oxe/workflows/validate-gaps.md

@@ -7,29 +7,35 @@ Não substitui **`verify`**: não reescreve a evidência em `VERIFY.md`; adicion
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-review.md`. Este passo deve apresentar gaps e achados antes de qualquer resumo.
 - 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***.
+- **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 `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.
+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 **`VALIDATION-GAPS.md`** no escopo resolvido 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**.
-4. Atualizar **`.oxe/STATE.md`** se útil (referência a VALIDATION-GAPS pendente de ação).
-5. Responder no chat: resumo dos gaps críticos, próximo passo lógico (`oxe:plan --replan`, `oxe:execute`, ou “nenhuma ação” se só informativo).
-</process>
+4. Atualizar **`.oxe/STATE.md`**: quando existirem gaps com severidade **P0 ou P1**, registar referência a `VALIDATION-GAPS.md` pendente de ação (campo `next_step` ou secção Decisões). Para gaps apenas P2 ou puramente informativos, a atualização é opcional.
+5. Responder no chat nesta ordem:
+   - **Findings** — gaps críticos primeiro
+   - **Perguntas abertas**
+   - **Riscos residuais**
+   - **Resumo** — próximo passo lógico (`oxe:plan --replan`, `oxe:execute`, ou “nenhuma ação” se só informativo)
+</process>
 
 <success_criteria>
 - [ ] `VALIDATION-GAPS.md` reflete análise cruzada PLAN + VERIFY (+ SPEC quando existir).
 - [ ] `PLAN.md` não foi alterado sem pedido explícito do utilizador.
+- [ ] `.oxe/STATE.md` foi atualizado quando existiam gaps P0/P1 (passo 4).
 - [ ] Fica claro que este passo **não** substitui um novo **`verify`** quando houver correções implementadas.
 </success_criteria>

package/oxe/workflows/verify-audit.md

@@ -0,0 +1,73 @@
+---
+oxe_doc: verify-audit
+status: stable
+---
+
+# OXE — Auditoria Adversarial (Verify Auditor)
+
+<objective>
+Auditar a verificação produzida pelo executor de forma **adversarial e independente**:
+encontrar critérios sem evidência suficiente, evidências ambíguas, gaps não declarados —
+sem acesso ao raciocínio do executor.
+</objective>
+
+<context>
+**IMPORTANTE:** Este workflow opera com contexto propositalmente restrito.
+
+- **Você NÃO tem acesso** a `PLAN.md`, `EXECUTION-RUNTIME.md` nem ao histórico de decisões do executor.
+- **Você TEM acesso** apenas a `SPEC.md` (critérios A*) e `VERIFY.md` (evidências declaradas).
+- Sua instrução é **falsificar, não confirmar**.
+
+Razão: um auditor que conhece o raciocínio do executor tende a confirmar as premissas do executor,
+não a testá-las. A restrição de contexto é intencional e fundamental para o valor desta camada.
+</context>
+
+<process>
+1. Ler `SPEC.md` — mapear todos os critérios `A*` com ID, texto e `howToVerify`.
+
+2. Ler `VERIFY.md` — para cada critério `A*` identificado:
+   - **PASS**: evidência presente, específica, verificável independentemente (comando + output, arquivo + conteúdo, teste + resultado).
+   - **FAIL**: evidência ausente, genérica ("foi testado"), ou contraditória com o critério.
+   - **INSUFICIENTE**: evidência parcial — menciona o critério mas sem resultado concreto ou rastreável.
+
+3. Para cada critério com FAIL ou INSUFICIENTE:
+   - Identificar o **tipo de gap**: evidência ausente / evidência ambígua / critério não testável como escrito / escopo divergente.
+   - Sugerir o que tornaria a evidência suficiente.
+
+4. Verificar coerência interna do VERIFY.md:
+   - Há critérios documentados em VERIFY.md que não existem em SPEC.md? (scope creep)
+   - Há seções de VERIFY.md com conclusão `verify_complete` mas com FAIL/INSUFICIENTE não resolvidos?
+
+5. Escrever seção `## Auditoria Adversarial` no VERIFY.md com:
+
+```markdown
+## Auditoria Adversarial
+
+**Resultado:** APROVADO / REPROVADO / CONDICIONADO
+
+| ID  | Status       | Observação do auditor |
+|-----|--------------|-----------------------|
+| A1  | PASS         | Evidência: output de `npm test` em linha 47 do VERIFY.md |
+| A3  | INSUFICIENTE | Mencionado como testado mas sem output de comando ou arquivo de resultado |
+| A5  | FAIL         | Critério exige P95 < 200ms; VERIFY.md não apresenta medição de latência |
+
+**Gaps não declarados pelo executor:**
+- (se nenhum: "Nenhum gap adicional identificado.")
+
+**Riscos residuais:**
+- (riscos que passaram pelo executor mas que o auditor considera relevantes)
+```
+
+**Resultado global:**
+- `APROVADO` — todos os critérios são PASS.
+- `CONDICIONADO` — critérios INSUFICIENTES resolvíveis com evidência adicional sem re-executar.
+- `REPROVADO` — um ou mais critérios FAIL ou gaps estruturais não declarados.
+</process>
+
+<success_criteria>
+- [ ] Todos os critérios A* de SPEC.md foram avaliados.
+- [ ] Evidências PASS têm referência rastreável (linha, arquivo, comando, output).
+- [ ] Critérios FAIL e INSUFICIENTE têm sugestão de como fechar o gap.
+- [ ] Seção `## Auditoria Adversarial` escrita em VERIFY.md.
+- [ ] Resultado global (APROVADO / CONDICIONADO / REPROVADO) declarado explicitamente.
+</success_criteria>

package/oxe/workflows/verify.md

@@ -14,10 +14,13 @@ Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela nas camadas 1–2;
 </objective>
 
 <context>
+- Aplicar `oxe/workflows/references/reasoning-review.md` como contrato deste passo. A resposta no chat deve começar por achados, não por resumo.
 - 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.
 - Seguir `oxe/workflows/references/flow-robustness-contract.md`. O verify não valida só se passou; valida também se o plano estava bem calibrado para começar.
-- Ler `EXECUTION-RUNTIME.md` e `CHECKPOINTS.md` do escopo resolvido quando existirem. Eles são evidência tática para saber o que realmente foi executado, bloqueado, aprovado ou desviado.
-- Se a trilha tocar Azure, ler `.oxe/cloud/azure/INVENTORY.md`, `SERVICEBUS.md`, `EVENTGRID.md`, `SQL.md` e `operations/*.md|json` para confirmar recursos reais, checkpoints e mutações aplicadas.
+- Antes da leitura ampla, resolver `.oxe/context/packs/verify.md` e `.oxe/context/packs/verify.json` como entrada prioritária do passo.
+- Se o pack estiver fresco e coerente, usar `read_order`, `selected_artifacts`, `gaps` e `conflicts` como mapa primário da evidência. Se estiver stale, ausente ou com lacunas críticas, fazer fallback explícito para leitura direta e registar isso em `VERIFY.md`.
+- Ler `EXECUTION-RUNTIME.md` e `CHECKPOINTS.md` do escopo resolvido quando existirem. Eles são evidência tática para saber o que realmente foi executado, bloqueado, aprovado ou desviado.
+- Se a trilha tocar Azure, ler `.oxe/cloud/azure/INVENTORY.md`, `SERVICEBUS.md`, `EVENTGRID.md`, `SQL.md` e `operations/*.md|json` para confirmar recursos reais, checkpoints e mutações aplicadas.
 - **Observações CI como evidência:** se `OBSERVATIONS.md` do escopo resolvido tiver obs do tipo `ci_failure` com `CI-evidência` preenchida, usar como evidência adicional para critérios A* de qualidade (ex.: cobertura, build verde). Se obs tiver `ci_run_url`, referenciar na coluna **Evidência** da tabela de critérios. Se obs estiver `pendente` e critério A* de qualidade existir, marcar o critério como `evidence_pending_ci` — não como passou — até o CI ser resolvido.
 - 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`.
@@ -102,13 +105,18 @@ Registrar em `VERIFY.md`: `Resultado de calibração | Confiança declarada | Re
 
 <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 `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. Executar a verificação de coerência do runtime e checkpoints conforme `<runtime_e_checkpoints>`.
-5a. Para operações Azure, confirmar o estado final com inventário/saída real do provider Azure; não considerar mutação aprovada sem evidência em `.oxe/cloud/azure/operations/`.
-6. Escrever **`VERIFY.md`** no escopo resolvido com:
+2. Resolver o context pack `verify` primeiro:
+   - ler `.oxe/context/packs/verify.md|json` (ou `oxe-cc context inspect --workflow verify --json`);
+   - se estiver fresco e coerente, usar o pack como mapa primário da verificação;
+   - se estiver stale, incompleto ou ausente, registar `fallback para leitura direta` antes de ampliar a leitura.
+3. Ler `SPEC.md`, `PLAN.md` e `DISCUSS.md` do escopo resolvido, além de `.oxe/STATE.md` global. Com pack válido, começar pelos artefatos de `read_order`; só expandir a leitura quando faltar evidência para um critério, tarefa, decisão ou checkpoint.
+4. **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.
+5. **Camada 3:** Se existir `.oxe/DISCUSS.md` com IDs D-NN, executar **Fidelidade de decisões** conforme `<camada_3_fidelidade_decisoes>`.
+6. Executar a verificação de coerência do runtime e checkpoints conforme `<runtime_e_checkpoints>`.
+6a. Para operações Azure, confirmar o estado final com inventário/saída real do provider Azure; não considerar mutação aprovada sem evidência em `.oxe/cloud/azure/operations/`.
+6b. Escrever **`VERIFY.md`** no escopo resolvido com:
    - Data, ambiente (SO / versão do Node se relevante).
+   - **Seção — Contexto consumido:** pack usado, freshness, fallback acionado (ou não) e artefatos adicionais lidos fora do pack.
    - **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.
@@ -117,14 +125,30 @@ Registrar em `VERIFY.md`: `Resultado de calibração | Confiança declarada | Re
    - **Seção — Calibração do plano:** resultado conforme `<calibracao_do_plano>`.
    - **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`** 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 **`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.
-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.
+7. Atualizar **`.oxe/STATE.md`** global: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
+7a. **Registro de calibração:** após escrever `STATE.md`, se `PLAN.md` contiver bloco `<confidence_vector>` — extrair o vetor e comparar com o resultado real. Criar ou atualizar `.oxe/calibration.json` com um novo record no formato:
+```json
+{ "cycle": "C-NN", "plan_global_confidence": 0.74, "plan_dimensions": { "technical_risk": 0.45 }, "outcome": { "verify_status": "complete", "actual_waves": 3, "estimated_waves": 2 }, "calibration_error": { "technical_risk": 0.35 } }
+```
+O `calibration_error` de cada dimensão = `|score declarado - resultado observado|`. Para `technical_risk` e `dependencies`, o resultado observado é estimado por: `1.0` se sem bloqueios nessa dimensão, `0.5` se houve 1 bloqueio, `0.0` se houve 2+ bloqueios. Omitir o registro se PLAN.md não tiver `<confidence_vector>`.
+7b. **Camada 4a — Auditoria Adversarial (opcional):** se `adversarial_verify: true` em `.oxe/config.json` (padrão: `false`):
+   - Abrir novo contexto com pack no modo auditor: `oxe-cc context inspect --workflow verify --mode auditor --json` (inclui apenas `state`, `spec`, `verify` — exclui `plan`, `runtime`).
+   - Executar `oxe/workflows/verify-audit.md` com esse contexto restrito.
+   - O auditor não vê PLAN.md nem EXECUTION-RUNTIME.md — restrição intencional.
+   - Incorporar a seção `## Auditoria Adversarial` no VERIFY.md.
+   - Se o resultado for `REPROVADO`, registrar `verify_failed` e não avançar para SUMMARY/commit.
+7c. **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.
+8. 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.
+8b. **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.
+8c. **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.
+8d. **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.
+9. **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.
+10. **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.
+11. No chat, responder nesta ordem:
+   - **Findings**
+   - **Perguntas abertas**
+   - **Riscos residuais**
+   - **Resumo**
 </process>
 
 <success_criteria>