oxe-cc 1.2.1 → 1.3.0

package/oxe/workflows/ship.md

@@ -1,142 +1,142 @@
-# OXE — Workflow: ship (entrega / commit)
-
-<objective>
-Criar um commit local a partir do trabalho verificado — gerando a mensagem de commit a partir de `SPEC.md`, `PLAN.md` e `VERIFY.md` e chamando `git commit`.
-
-Fecha o ciclo de desenvolvimento com um commit limpo, rastreável e alinhado aos artefatos OXE.
-</objective>
-
-<flags>
-- `--message "mensagem"` — sobrescreve a mensagem de commit gerada automaticamente.
-- `--amend` — usa `git commit --amend` em vez de criar um commit novo.
-- `--verify-first` — rodar `/oxe-verify` antes de criar o PR se VERIFY ainda não passou.
-- `--no-checks` — pular checagem de verify (commitar mesmo sem verify completo — gera aviso).
-- `--dry-run` — mostrar a mensagem de commit e o comando `git commit` sem commitar.
-</flags>
-
-<context>
-- Ship requer que `VERIFY.md` exista e indique aprovação, OU que o usuário confirme explicitamente com `--no-checks`.
-- A mensagem de commit é gerada a partir dos artefatos OXE — não a partir do histórico git cru.
-- Salvar o rascunho da mensagem em `.oxe/commit-draft.md`.
-- Salvar referência do commit em `.oxe/commit-record.json` após commitar.
-- Se houver alterações não relacionadas no worktree, pausar e pedir confirmação antes de stagear tudo.
-</context>
-
-<process>
-
-### Step 1 — Pré-voo
-
-1. Ler `.oxe/STATE.md` e sessão ativa (se houver).
-2. Verificar branch atual: `git branch --show-current`.
-3. Verificar status do verify:
-   - Existe `VERIFY.md` e está aprovado? → continuar.
-   - Existe `VERIFY.md` mas tem falhas? → avisar. Se `--no-checks`, continuar. Se não, sugerir `/oxe-verify` primeiro.
-   - Não existe `VERIFY.md`? → se `--verify-first`, executar `oxe/workflows/verify.md` antes de continuar. Caso contrário: bloquear a entrega e orientar `/oxe-verify` ou `--no-checks`.
-
-4. Verificar worktree (`git status --short`):
-   - Se não houver mudanças staged ou unstaged: informar que não há nada para commitar e encerrar.
-   - Se houver mudanças fora do escopo planejado: avisar e pedir confirmação antes de prosseguir.
-
-### Step 2 — Gerar mensagem de commit
-
-Ler os artefatos disponíveis nesta ordem de prioridade:
-1. `SPEC.md` (ou `QUICK.md` se for quick task) → objetivo / resumo curto
-2. `PLAN.md` → tarefas concluídas / ondas fechadas
-3. `VERIFY.md` → checks passados, evidências, riscos residuais
-4. `CONCERNS.md` ou `SUMMARY.md` → notas adicionais se houver
-
-Template da mensagem:
-```markdown
-feat: <descrição concisa em <= 72 chars>
-
-<Resumo de 1-2 parágrafos derivado de SPEC/QUICK e PLAN>
-
-Validation:
-- <check 1>
-- <check 2>
-
----
-OXE: spec-driven workflow
-```
-
-Gerar também uma variante `fix:` ou `refactor:` quando os artefatos indicarem esse tipo de mudança. Se `--message` existir, usá-la como título e manter o corpo gerado abaixo.
-
-Salvar a mensagem em `.oxe/commit-draft.md`.
-
-### Step 3 — Stage e commit
-
-1. Fazer stage explícito:
-   - padrão: `git add -A`
-   - se houver arquivos claramente fora do escopo, parar e confirmar antes
-2. Executar:
-   - commit novo:
-     ```bash
-     git commit -F .oxe/commit-draft.md
-     ```
-   - amend:
-     ```bash
-     git commit --amend -F .oxe/commit-draft.md
-     ```
-
-Salvar em `.oxe/commit-record.json`:
-```json
-{
-  "commit_sha": "<sha>",
-  "subject": "...",
-  "amend": false,
-  "committed_at": "ISO",
-  "branch": "...",
-  "verify_status": "passed|skipped|failed_with_override"
-}
-```
-
-Se `git commit` falhar por hooks, conflitos ou falta de stage válido:
-- registrar o erro
-- não apagar `.oxe/commit-draft.md`
-- reportar o bloqueio com o comando falhado
-
-### Step 4 — Saída final
-
-**Sucesso:**
-```
-✓ Commit criado: [sha-curto]
-Branch: [current]
-Mensagem: [subject]
-Próximo: push manual, revisão de diff ou /oxe-session milestone (se for a última feature do ciclo)
-```
-
-**Dry-run:**
-```
-[dry-run] Commit não criado. Mensagem gerada em .oxe/commit-draft.md
-Comando para commitar: git commit -F .oxe/commit-draft.md
-```
-
-**Falha / bloqueio:**
-```
-Commit não realizado. Rascunho mantido em .oxe/commit-draft.md
-Resolva o bloqueio (verify, stage, hook ou conflito) e rode /oxe-ship novamente.
-```
-</process>
-
-<message_generation>
-## Geração automática da mensagem
-
-O subject é gerado a partir de `SPEC.md` (primeira linha de objetivo) ou de `QUICK.md` (primeira tarefa):
-
-Formato padrão: `feat: [descrição concisa da feature em ≤ 72 chars]`
-
-Exemplos:
-- `feat: add OAuth2 login with Google provider`
-- `fix: resolve race condition in payment processor`
-- `refactor: extract auth middleware to standalone module`
-
-Se houver ticket/issue referenciado na SPEC: `feat(AUTH-123): add OAuth2 login`
-</message_generation>
-
-<success_criteria>
-- [ ] Commit criado (ou dry-run mostrou a mensagem e o comando).
-- [ ] `.oxe/commit-record.json` atualizado com SHA e subject.
-- [ ] Mensagem de commit inclui resumo derivado de SPEC/QUICK, mudanças de PLAN e validação de VERIFY.
-- [ ] Se VERIFY não passou: só continuou com `--no-checks`, com aviso explícito.
-- [ ] Sugeriu próximo passo (push, revisão de diff ou milestone).
-</success_criteria>
+# OXE — Workflow: ship (entrega / commit)
+
+<objective>
+Criar um commit local a partir do trabalho verificado — gerando a mensagem de commit a partir de `SPEC.md`, `PLAN.md` e `VERIFY.md` e chamando `git commit`.
+
+Fecha o ciclo de desenvolvimento com um commit limpo, rastreável e alinhado aos artefatos OXE.
+</objective>
+
+<flags>
+- `--message "mensagem"` — sobrescreve a mensagem de commit gerada automaticamente.
+- `--amend` — usa `git commit --amend` em vez de criar um commit novo.
+- `--verify-first` — rodar `/oxe-verify` antes de criar o PR se VERIFY ainda não passou.
+- `--no-checks` — pular checagem de verify (commitar mesmo sem verify completo — gera aviso).
+- `--dry-run` — mostrar a mensagem de commit e o comando `git commit` sem commitar.
+</flags>
+
+<context>
+- Ship requer que `VERIFY.md` exista e indique aprovação, OU que o usuário confirme explicitamente com `--no-checks`.
+- A mensagem de commit é gerada a partir dos artefatos OXE — não a partir do histórico git cru.
+- Salvar o rascunho da mensagem em `.oxe/commit-draft.md`.
+- Salvar referência do commit em `.oxe/commit-record.json` após commitar.
+- Se houver alterações não relacionadas no worktree, pausar e pedir confirmação antes de stagear tudo.
+</context>
+
+<process>
+
+### Step 1 — Pré-voo
+
+1. Ler `.oxe/STATE.md` e sessão ativa (se houver).
+2. Verificar branch atual: `git branch --show-current`.
+3. Verificar status do verify:
+   - Existe `VERIFY.md` e está aprovado? → continuar.
+   - Existe `VERIFY.md` mas tem falhas? → avisar. Se `--no-checks`, continuar. Se não, sugerir `/oxe-verify` primeiro.
+   - Não existe `VERIFY.md`? → se `--verify-first`, executar `oxe/workflows/verify.md` antes de continuar. Caso contrário: bloquear a entrega e orientar `/oxe-verify` ou `--no-checks`.
+
+4. Verificar worktree (`git status --short`):
+   - Se não houver mudanças staged ou unstaged: informar que não há nada para commitar e encerrar.
+   - Se houver mudanças fora do escopo planejado: avisar e pedir confirmação antes de prosseguir.
+
+### Step 2 — Gerar mensagem de commit
+
+Ler os artefatos disponíveis nesta ordem de prioridade:
+1. `SPEC.md` (ou `QUICK.md` se for quick task) → objetivo / resumo curto
+2. `PLAN.md` → tarefas concluídas / ondas fechadas
+3. `VERIFY.md` → checks passados, evidências, riscos residuais
+4. `CONCERNS.md` ou `SUMMARY.md` → notas adicionais se houver
+
+Template da mensagem:
+```markdown
+feat: <descrição concisa em <= 72 chars>
+
+<Resumo de 1-2 parágrafos derivado de SPEC/QUICK e PLAN>
+
+Validation:
+- <check 1>
+- <check 2>
+
+---
+OXE: spec-driven workflow
+```
+
+Gerar também uma variante `fix:` ou `refactor:` quando os artefatos indicarem esse tipo de mudança. Se `--message` existir, usá-la como título e manter o corpo gerado abaixo.
+
+Salvar a mensagem em `.oxe/commit-draft.md`.
+
+### Step 3 — Stage e commit
+
+1. Fazer stage explícito:
+   - padrão: `git add -A`
+   - se houver arquivos claramente fora do escopo, parar e confirmar antes
+2. Executar:
+   - commit novo:
+     ```bash
+     git commit -F .oxe/commit-draft.md
+     ```
+   - amend:
+     ```bash
+     git commit --amend -F .oxe/commit-draft.md
+     ```
+
+Salvar em `.oxe/commit-record.json`:
+```json
+{
+  "commit_sha": "<sha>",
+  "subject": "...",
+  "amend": false,
+  "committed_at": "ISO",
+  "branch": "...",
+  "verify_status": "passed|skipped|failed_with_override"
+}
+```
+
+Se `git commit` falhar por hooks, conflitos ou falta de stage válido:
+- registrar o erro
+- não apagar `.oxe/commit-draft.md`
+- reportar o bloqueio com o comando falhado
+
+### Step 4 — Saída final
+
+**Sucesso:**
+```
+✓ Commit criado: [sha-curto]
+Branch: [current]
+Mensagem: [subject]
+Próximo: push manual, revisão de diff ou /oxe-session milestone (se for a última feature do ciclo)
+```
+
+**Dry-run:**
+```
+[dry-run] Commit não criado. Mensagem gerada em .oxe/commit-draft.md
+Comando para commitar: git commit -F .oxe/commit-draft.md
+```
+
+**Falha / bloqueio:**
+```
+Commit não realizado. Rascunho mantido em .oxe/commit-draft.md
+Resolva o bloqueio (verify, stage, hook ou conflito) e rode /oxe-ship novamente.
+```
+</process>
+
+<message_generation>
+## Geração automática da mensagem
+
+O subject é gerado a partir de `SPEC.md` (primeira linha de objetivo) ou de `QUICK.md` (primeira tarefa):
+
+Formato padrão: `feat: [descrição concisa da feature em ≤ 72 chars]`
+
+Exemplos:
+- `feat: add OAuth2 login with Google provider`
+- `fix: resolve race condition in payment processor`
+- `refactor: extract auth middleware to standalone module`
+
+Se houver ticket/issue referenciado na SPEC: `feat(AUTH-123): add OAuth2 login`
+</message_generation>
+
+<success_criteria>
+- [ ] Commit criado (ou dry-run mostrou a mensagem e o comando).
+- [ ] `.oxe/commit-record.json` atualizado com SHA e subject.
+- [ ] Mensagem de commit inclui resumo derivado de SPEC/QUICK, mudanças de PLAN e validação de VERIFY.
+- [ ] Se VERIFY não passou: só continuou com `--no-checks`, com aviso explícito.
+- [ ] Sugeriu próximo passo (push, revisão de diff ou milestone).
+</success_criteria>

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/ui-review.md

@@ -1,36 +1,36 @@
-# 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>
-
-<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.
-- [ ] Bloqueios P0 são explícitos ou declarado que não há.
-- [ ] Fica claro que **`/oxe-verify`** ainda é necessário para a trilha.
-</success_criteria>
+# 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>
+
+<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.
+- [ ] Bloqueios P0 são explícitos ou declarado que não há.
+- [ ] Fica claro que **`/oxe-verify`** ainda é necessário para a trilha.
+</success_criteria>

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

@@ -51,6 +51,9 @@ Ao receber qualquer argumento, verificar flags antes de iniciar o fluxo principa
 - 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.
@@ -176,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>`.
@@ -191,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
@@ -236,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>