oxe-cc 1.0.0 → 1.3.0

package/oxe/workflows/skill.md

@@ -1,44 +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>
+# 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

@@ -11,6 +11,14 @@ Conduzir as **5 fases** do processo de especificação e produzir dois artefatos
 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.
+
+**Flags suportadas:**
+- `--refresh` — antes de iniciar, atualizar `.oxe/codebase/` em modo incremental (equivalente a `scan` modo refresh). Usar quando o codebase mudou desde o último scan.
+- `--full` — antes de iniciar, forçar scan completo do codebase (equivalente a `scan --full`). Usar quando o mapa está obsoleto ou ausente.
+- `--research` / `--deep` — ativar Fase 2 (Pesquisa) de forma explícita, mesmo que a incerteza detectada seja baixa. Útil para spikes, mapas de sistema, engenharia reversa.
+- `--ui` — ao final da Fase 5, gerar contrato UI/UX em `.oxe/UI-SPEC.md` (equivalente a `/oxe-ui-spec`). Ativar automaticamente quando UI for domínio crítico detectado.
+
+**Nota de compatibilidade v1.1.0:** `/oxe-scan`, `/oxe-research` e `/oxe-ui-spec` foram incorporados por este comando. Esses comandos legados continuam funcionando mas exibem aviso de migração.
 </objective>
 
 <context>
@@ -242,9 +250,16 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 **Ao finalizar:**
 - Marcar `ROADMAP.md` → `status: approved`
 - Atualizar `STATE.md`: `phase: spec_ready`, próximo passo conforme escolha
+- Se flag `--ui` foi recebida **ou** se UI foi detectada como domínio crítico: executar a lógica de `oxe/workflows/ui-spec.md` e produzir `.oxe/UI-SPEC.md` como extensão desta spec. Mencionar ao usuário que o contrato UI foi gerado.
 </fase_5_aprovacao>
 
 <process>
+0. **Processar flags recebidas:**
+   - `--refresh`: executar a lógica de `oxe/workflows/compact.md` (modo incremental) antes de continuar. Reportar breve resumo das mudanças detectadas.
+   - `--full`: executar a lógica de `oxe/workflows/scan.md` (modo bootstrap completo) antes de continuar. Reportar arquivos-chave mapeados.
+   - `--research` / `--deep`: registrar internamente que a Fase 2 (Pesquisa) deve ser executada de forma explícita, mesmo se incerteza parecer baixa.
+   - `--ui`: registrar internamente que ao final da Fase 5, o contrato UI-SPEC deve ser gerado automaticamente.
+   - Sem flags: verificar se `.oxe/codebase/` existe e está relativamente recente; se não existir, mencionar que scan seria recomendado antes da spec.
 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.

package/oxe/workflows/ui-review.md

@@ -1,29 +1,33 @@
 # OXE — Workflow: ui-review
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-verify`.
+> Use: `/oxe-verify --ui` para incluir auditoria de implementação UI.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Produzir **`.oxe/UI-REVIEW.md`**: auditoria da implementação UI face a **`.oxe/UI-SPEC.md`** (e critérios **A*** da SPEC quando tocarem UI), tipicamente **após** trabalho de implementação e **antes** ou **como entrada** para **`verify`**.
 
 Não substitui **`verify`**: cruza contrato UI; o verify global continua a amarrar PLAN + SPEC + evidência técnica.
 </objective>
 
-<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>
+<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 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>
+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 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/ui-spec.md

@@ -1,5 +1,9 @@
 # OXE — Workflow: ui-spec
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-spec`.
+> Use: `/oxe-spec --ui` para gerar o contrato UI/UX ao final da spec.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Produzir **`.oxe/UI-SPEC.md`**: contrato de UI/UX derivado de **`.oxe/SPEC.md`** (e mapas em `.oxe/codebase/` quando útil), para **planear e verificar** trabalho front-end na mesma trilha OXE.
 
@@ -13,9 +17,9 @@ Produzir **`.oxe/UI-SPEC.md`**: contrato de UI/UX derivado de **`.oxe/SPEC.md`**
 </context>
 
 <process>
-1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
-2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais).
-3. Atualizar **`.oxe/STATE.md`** global: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
+1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
+2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais).
+3. Atualizar **`.oxe/STATE.md`** global: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
 4. Resumo no chat: o que ficou no UI-SPEC e como o **`/oxe-plan`** deve citar as secções (ex.: “cumprir UI-SPEC §2”).
 </process>
 

package/oxe/workflows/validate-gaps.md

@@ -1,14 +1,18 @@
 # OXE — Workflow: validate-gaps
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-verify`.
+> Use: `/oxe-verify --gaps` para ativar auditoria de cobertura explicitamente.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Após **`verify`**, produzir ou atualizar **`.oxe/VALIDATION-GAPS.md`**: auditoria **complementar** de cobertura e verificabilidade (critérios **A***, tarefas **Tn**, alinhamento PLAN↔VERIFY), com **sugestões de novas tarefas em texto** — **sem** alterar `.oxe/PLAN.md` por defeito.
 
 Não substitui **`verify`**: não reescreve a evidência em `VERIFY.md`; adiciona uma camada de “gaps” e melhorias para a próxima ronda ou replan.
 </objective>
 
-<context>
-- 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/`.
+<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***.
 - **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.
@@ -26,12 +30,12 @@ Não substitui **`verify`**: não reescreve a evidência em `VERIFY.md`; adicion
    - **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`**: 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>
+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).

package/oxe/workflows/verify-audit.md

@@ -1,73 +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>
+---
+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

@@ -11,14 +11,49 @@ Executar ou orientar verificação pós-implementação em **quatro camadas prog
 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.
+
+**Flags suportadas:**
+- `--gaps` — ativar Camada 5 (auditoria de cobertura) explicitamente, independente de `verification_depth` na config (equivalente a `/oxe-validate-gaps`).
+- `--security` — ativar Camada 6 (auditoria OWASP) explicitamente, independente de `security_in_verify` na config (equivalente a `/oxe-security`).
+- `--ui` — incluir auditoria de implementação UI baseada em `UI-SPEC.md` (equivalente a `/oxe-ui-review`). Ativado automaticamente se `UI-SPEC.md` existir no escopo.
+- `--pr` — incluir revisão de PR antes de fechar o verify (equivalente a `/oxe-review-pr`). Usa o diff do branch atual contra o branch base.
+- `--diff branchA...branchB` — revisão de diff específico entre dois branches ou SHAs.
+- `--skip-retro` — pular a retrospectiva automática ao final do verify.
+
+**Retro automática:** ao fechar `verify_complete`, executar automaticamente a lógica de `oxe/workflows/retro.md` para sintetizar 3–5 lições em `.oxe/global/LESSONS.md`. Usar `--skip-retro` para desativar.
+
+**Nota de compatibilidade v1.1.0:** `/oxe-validate-gaps`, `/oxe-security`, `/oxe-ui-review`, `/oxe-review-pr` e `/oxe-retro` foram incorporados por este comando. Esses comandos legados continuam funcionando mas exibem aviso de migração.
 </objective>
 
+<flags_processing>
+## Processamento de flags (executar antes do step 1)
+
+Ao receber qualquer argumento, verificar flags antes de iniciar o fluxo principal:
+
+1. **`--gaps`**: registrar internamente que Camada 5 deve ser executada independentemente de `verification_depth` na config.
+
+2. **`--security`**: registrar internamente que Camada 6 deve ser executada independentemente de `security_in_verify` na config.
+
+3. **`--ui`**: registrar internamente que auditoria UI deve ser executada. Se `UI-SPEC.md` não existir no escopo, avisar e perguntar se deseja executar `/oxe-spec --ui` primeiro.
+
+4. **`--pr`**: após as camadas principais, executar a lógica de `oxe/workflows/review-pr.md` com o diff do branch atual. Incluir achados na seção **Revisão de PR** do VERIFY.md.
+
+5. **`--diff branchA...branchB`**: equivalente a `--pr`, mas com o diff específico informado.
+
+6. **`--skip-retro`**: registrar que a retro automática deve ser pulada ao final.
+
+**Verificação automática de UI:** independente de flags, se `UI-SPEC.md` existir no escopo e houver critérios A* que toquem interface, executar auditoria UI parcial.
+</flags_processing>
+
 <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.
 - 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`.
+- **Runtime enterprise como caminho padrão:** quando `oxe-cc runtime` estiver disponível, executar ou solicitar `oxe-cc runtime verify --dir <projeto>` como caminho primário deste passo. Tratar `verification-manifest.json`, `residual-risk-ledger.json` e `evidence-coverage.json` da run ativa como fonte primária de evidência técnica, e o `VERIFY.md` projetado pelo runtime como base do artefato final.
+- Se `runtime verify` retornar `partial`, continuar com as camadas manuais usando os gaps explícitos do runtime como backlog obrigatório da revisão; não cair silenciosamente para narrativa solta.
+- Se o runtime não estiver compilado, indisponível ou não puder ser executado no ambiente atual, declarar `fallback legado` explicitamente antes de seguir com a verificação manual baseada em markdown e comandos locais.
 - 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.
@@ -144,6 +179,11 @@ Registrar em `VERIFY.md`: `Resultado de calibração | Confiança declarada | Re
    - 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.
+3a. **Caminho padrão do runtime enterprise:** se `oxe-cc runtime` estiver disponível:
+   - executar ou solicitar `oxe-cc runtime verify --dir <projeto>` antes das camadas manuais;
+   - usar `verification-manifest.json`, `residual-risk-ledger.json`, `evidence-coverage.json` e a projeção de `VERIFY.md` como base primária da verificação;
+   - se o resultado vier como `partial`, tratar os gaps explícitos como backlog obrigatório das camadas manuais;
+   - se o runtime não puder ser executado por indisponibilidade do pacote, registar `fallback legado`.
 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>`.
@@ -159,6 +199,7 @@ 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`.
+   Quando `runtime verify` já tiver projetado `VERIFY.md`, usar essa projeção como base e complementar manualmente apenas as seções ou evidências que o runtime ainda não cobrir.
 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
@@ -173,9 +214,16 @@ O `calibration_error` de cada dimensão = `|score declarado - resultado observad
    - 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.
+8b. **Retrospectiva automática (pós-verify):** se `verify_complete` e `--skip-retro` não foi passado, executar automaticamente a lógica de `oxe/workflows/retro.md`:
+   - Sintetizar 3–5 lições prescritivas com base nos achados do ciclo atual
+   - Escrever/atualizar `.oxe/global/LESSONS.md` (com fallback para `.oxe/LESSONS.md`)
+   - Incluir seção **Retrospectiva** resumida no VERIFY.md
+   - Especialmente importante quando: houve replanejamento, falhas em execute, critérios A* ajustados, ou ciclo durou mais de 2 ondas
+   - Com `--skip-retro`: pular esta etapa e mencionar que a retrospectiva está disponível via `/oxe-retro` manualmente
+8c. **Camada 5 — Validate-gaps:** se `verification_depth: "thorough"` em `.oxe/config.json` **ou** flag `--gaps` foi recebida, 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:** se `security_in_verify: true` em `.oxe/config.json` **ou** flag `--security` foi recebida, 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.
+8d2. **Camada UI — Revisão de implementação:** se `UI-SPEC.md` existir no escopo **ou** flag `--ui` foi recebida, executar a lógica de `oxe/workflows/ui-review.md` e adicionar seção **Auditoria UI** ao VERIFY.md. Também escrever `.oxe/UI-REVIEW.md` separado.
+8d3. **Revisão de PR/diff:** se flag `--pr` ou `--diff` foi recebida, executar a lógica de `oxe/workflows/review-pr.md` com o diff relevante e adicionar seção **Revisão de PR** ao VERIFY.md.
 8e. **Camada QC — Quality Contract automático:** se SPEC.md contiver requisitos `R-RB-NN` com versão `v1`, executar o bloco `<camada_qc_quality_contract>` e adicionar seção **Contrato de Qualidade** ao VERIFY.md. R-RB Piso não implementados bloqueiam `verify_complete` — registrar `verify_failed` até serem resolvidos ou explicitamente aceitos como risco P0.
 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.
@@ -197,4 +245,5 @@ O `calibration_error` de cada dimensão = `|score declarado - resultado observad
 - [ ] Se `verification_depth: "thorough"` em config: `.oxe/VALIDATION-GAPS.md` produzido como parte deste verify.
 - [ ] Se `security_in_verify: true` em config: `.oxe/SECURITY.md` produzido; achados P0 resolvidos ou `verify_failed` registrado.
 - [ ] Se SPEC.md contiver R-RB v1: seção **Contrato de Qualidade** presente em VERIFY.md com Quality Score realizado; R-RB Piso não implementados tratados como gaps P0.
+- [ ] Quando `oxe-cc runtime` estiver disponível, `runtime verify` foi tentado como caminho primário; se o resultado foi `partial`, os gaps explícitos do runtime foram cobertos ou documentados.
 </success_criteria>