oxe-cc 0.9.3 → 1.2.1

package/oxe/workflows/research.md

@@ -1,25 +1,29 @@
 # OXE — Workflow: research
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-spec`.
+> Use: `/oxe-spec --research` ou `/oxe-spec --deep` para spike/pesquisa explícita.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
-Produzir **notas de pesquisa rastreáveis** em `research/YYYY-MM-DD-<slug>.md` do escopo resolvido e manter `RESEARCH.md` correspondente como **índice e histórico** (ligações, tipo, estado, resumo). Serve para qualquer incerteza antes de um plano pesado: spikes, comparação de tecnologias, due diligence, requisitos ambíguos, **e** — com profundidade quando pedido — compreensão de **sistemas grandes**, **engenharia reversa / brownfield** e **hipóteses de modernização** (sempre ligadas a evidência ou suposições explícitas).
+Produzir **notas de pesquisa rastreáveis** em `research/YYYY-MM-DD-<slug>.md` do escopo resolvido e manter `RESEARCH.md` correspondente como **índice e histórico** (ligações, tipo, estado, resumo). Serve para qualquer incerteza antes de um plano pesado: spikes, comparação de tecnologias, due diligence, requisitos ambíguos, **e** — com profundidade quando pedido — compreensão de **sistemas grandes**, **engenharia reversa / brownfield** e **hipóteses de modernização** (sempre ligadas a evidência ou suposições explícitas).
 
 Não substitui **SPEC** nem **PLAN**; alimenta decisões que depois entram na SPEC ou no PLAN.
 </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.
+<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.
 - Nome do ficheiro: **`YYYY-MM-DD-<slug-kebab>.md`** (data ISO do dia acordado na mensagem ou data atual; slug único, curto, ASCII preferível).
-- **Índice:** `RESEARCH.md` do mesmo escopo deve conter tabela **Histórico** (mais recente primeiro) com colunas: **Data** | **Ficheiro** (`research/...`) | **Tema / âmbito** | **Tipo** (ex.: spike, mapa-sistema, reversa, modernização, decisão) | **Estado** (decidido / pendente / parcial) | **Resumo** (uma linha). Opcional: bloco **Última sessão** no topo com link para a nota mais recente.
+- **Índice:** `RESEARCH.md` do mesmo escopo deve conter tabela **Histórico** (mais recente primeiro) com colunas: **Data** | **Ficheiro** (`research/...`) | **Tema / âmbito** | **Tipo** (ex.: spike, mapa-sistema, reversa, modernização, decisão) | **Estado** (decidido / pendente / parcial) | **Resumo** (uma linha). Opcional: bloco **Última sessão** no topo com link para a nota mais recente.
 - Preferir **`.oxe/SPEC.md`** existente; se o pedido for mapear/reverter **antes** de spec, criar a nota mesmo assim com **Contexto** a declarar ausência de SPEC e próximo passo `oxe:spec`.
 - **Progressive disclosure:** sistemas grandes → profundidade por área; várias sessões/notas datadas em vez de um único ficheiro enorme.
-- Template: **`oxe/templates/RESEARCH.template.md`**.
-- Ler `INVESTIGATIONS.md` e investigações anteriores do escopo resolvido antes de abrir nova pesquisa sobre o mesmo assunto.
-- Ler `.oxe/CAPABILITIES.md` quando a investigação depender de capability local, script ou conector já existente.
-- Segurança: não gravar segredos nem valores de variáveis de ambiente.
-</context>
+- Template: **`oxe/templates/RESEARCH.template.md`**.
+- Ler `INVESTIGATIONS.md` e investigações anteriores do escopo resolvido antes de abrir nova pesquisa sobre o mesmo assunto.
+- Ler `.oxe/CAPABILITIES.md` quando a investigação depender de capability local, script ou conector já existente.
+- Segurança: não gravar segredos nem valores de variáveis de ambiente.
+</context>
 
 <thinking_depth>
 ## Profundidade de Raciocínio
@@ -38,25 +42,25 @@ Anotar `thinking_depth: surface | standard | deep` no frontmatter da nota de pes
 </thinking_depth>
 
 <process>
-1. Garantir pastas `.oxe/` e `research/` do escopo resolvido.
+1. Garantir pastas `.oxe/` e `research/` do escopo resolvido.
 2. Escolher `YYYY-MM-DD-<slug>.md` único; se colisão, acrescentar sufixo ao slug (ex. `-b`).
-3. Criar a nota a partir de `RESEARCH.template.md`: preencher secções **base**; preencher secções de **reforço** ou marcar **N/A** com justificação curta quando o âmbito for sistema grande, reversa ou modernização.
-4. Se `RESEARCH.md` do escopo resolvido não existir, criá-lo com título `# OXE — Índice de pesquisa`, parágrafo introdutório, secção **Histórico** com cabeçalho de tabela e primeira linha.
-5. Se já existir, **atualizar** `RESEARCH.md` do escopo resolvido: nova linha no topo da tabela **Histórico** (mais recente primeiro); opcionalmente atualizar **Última sessão** com link para o ficheiro novo.
-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, 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>
+3. Criar a nota a partir de `RESEARCH.template.md`: preencher secções **base**; preencher secções de **reforço** ou marcar **N/A** com justificação curta quando o âmbito for sistema grande, reversa ou modernização.
+4. Se `RESEARCH.md` do escopo resolvido não existir, criá-lo com título `# OXE — Índice de pesquisa`, parágrafo introdutório, secção **Histórico** com cabeçalho de tabela e primeira linha.
+5. Se já existir, **atualizar** `RESEARCH.md` do escopo resolvido: nova linha no topo da tabela **Histórico** (mais recente primeiro); opcionalmente atualizar **Última sessão** com link para o ficheiro novo.
+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, 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.
-- [ ] `RESEARCH.md` do mesmo escopo existe e a tabela **Histórico** inclui a nova entrada.
+- [ ] Existe novo ficheiro em `research/YYYY-MM-DD-<slug>.md` no escopo correto com secções base preenchidas de forma útil.
+- [ ] `RESEARCH.md` do mesmo escopo existe e a tabela **Histórico** inclui a nova entrada.
 - [ ] Nenhuma nota anterior foi sobrescrita sem instrução explícita do utilizador.
 - [ ] `STATE.md` reflete o progresso e o próximo passo sugerido.
 </success_criteria>

package/oxe/workflows/retro.md

@@ -1,5 +1,9 @@
 # OXE — Workflow: retro (retrospectiva de ciclo)
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-verify`.
+> A retrospectiva agora é executada automaticamente ao fechar `/oxe-verify` (use `--skip-retro` para desativar).
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Sintetizar os aprendizados de um ciclo completo (spec → verify) em **`.oxe/LESSONS.md`** — um arquivo prescritivo e cumulativo que alimenta automaticamente ciclos futuros.
 

package/oxe/workflows/review-pr.md

@@ -1,12 +1,16 @@
 # OXE — Workflow: review-pr (revisão de diff / PR)
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-verify`.
+> Use: `/oxe-verify --pr` (branch atual) ou `/oxe-verify --diff branchA...branchB`.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 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>
-- 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`).
+<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.
@@ -29,14 +33,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:
-   - **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.
+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>
 

package/oxe/workflows/scan.md

@@ -1,5 +1,9 @@
 # OXE — Workflow: scan
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-spec`.
+> Use: `/oxe-spec --refresh` (atualização incremental) ou `/oxe-spec --full` (scan completo).
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Analisar o codebase e produzir documentação **estruturada e enxuta** em `.oxe/codebase/`, atualizando `.oxe/STATE.md`. Cada documento deve ser navegável por humanos e por agentes sem carregar o repositório inteiro no contexto.
 

package/oxe/workflows/security.md

@@ -1,5 +1,9 @@
 # OXE — Workflow: security (auditoria de segurança)
 
+> **[DEPRECATED v1.1.0]** Este comando foi incorporado por `/oxe-verify`.
+> Use: `/oxe-verify --security` para ativar auditoria OWASP explicitamente.
+> Este alias continuará funcionando nesta versão por compatibilidade.
+
 <objective>
 Produzir **`.oxe/SECURITY.md`**: auditoria de segurança do repositório focada nas categorias OWASP Top 10 **relevantes** ao stack do projeto. Complementa **`validate-gaps`** (cobertura de testes) com uma camada de segurança aplicativa.
 
@@ -8,10 +12,10 @@ Pode ser chamado standalone ou como Camada 5 do **`verify.md`** quando `config.j
 Não substitui ferramentas de análise estática (SAST) — identifica padrões de risco no código e na configuração a partir do contexto disponível no repositório.
 </objective>
 
-<context>
-- 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).
+<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.
 - **Severidade:** P0 = crítico (exploração provável, impacto direto), P1 = alto (requer mitigação antes do próximo deploy), P2 = médio (risco aceitável com compensação documentada).
 - **Saída de tarefas:** recomendações vinculadas a `Tn` existentes no PLAN.md (se disponível) ou como sugestões de novas tarefas `T_new`.
@@ -47,14 +51,14 @@ Antes de auditar, determinar quais categorias se aplicam lendo `STACK.md` e `INT
    a. Identificar **arquivos críticos** (auth, input handlers, DB queries, configs, env, deps).
    b. Ler os arquivos relevantes (Glob, Grep, Read) procurando padrões de risco.
    c. Registrar achados com: localização (`path:linha`), padrão encontrado, severidade (P0/P1/P2), recomendação.
-4. Ler `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 nesta ordem: **Findings**, **Perguntas abertas**, **Riscos residuais**, **Resumo**. P0 presentes → bloquear deploy; apenas P2 → ação opcional.
-</process>
+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 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.
+- [ ] `SECURITY.md` existe no escopo correto com categorias OWASP selecionadas e justificativa de descarte.
 - [ ] Cada achado tem: localização, padrão, severidade, recomendação.
 - [ ] Categorias sem achados registradas como "nenhum achado nesta categoria".
 - [ ] Achados P0/P1 vinculados a `Tn` existente ou sugestão `T_new`.

package/oxe/workflows/session.md

@@ -3,7 +3,7 @@
 <objective>
 Gerenciar **sessões OXE** em `.oxe/sessions/` para isolar artefatos por ciclo de trabalho, mantendo **`.oxe/STATE.md`** como índice global e preservando o **modo legado** quando não houver sessão ativa.
 
-Subcomandos:
+Subcomandos de sessão:
 - `new <nome>`
 - `list`
 - `switch <id-ou-nome>`
@@ -13,6 +13,22 @@ Subcomandos:
 - `migrate <nome>`
 - `fork [nome-opcional]`
 - `revert <checkpoint-slug>`
+
+Subcomandos de milestone (absorvidos de `/oxe-project` e `/oxe-milestone`):
+- `milestone new [nome]` — iniciar marco de entrega (M-01, M-02, …)
+- `milestone complete` — fechar milestone ativo, arquivar em `.oxe/milestones/M-NN/`
+- `milestone status` — progresso do milestone ativo
+- `milestone audit` — Definition of Done do milestone
+
+Subcomandos de workstream (absorvidos de `/oxe-project` e `/oxe-workstream`):
+- `workstream new <nome>` — trilha paralela em `.oxe/workstreams/<nome>/`
+- `workstream switch <nome>` — definir workstream ativo
+- `workstream list` — listar trilhas
+- `workstream close <nome>` — fechar trilha
+
+Sem argumento: mostrar status atual (sessão ativa, milestone, workstream ativo).
+
+**Nota de compatibilidade v1.1.0:** `/oxe-project`, `/oxe-milestone` e `/oxe-workstream` foram incorporados por este comando. Esses comandos legados continuam funcionando mas exibem aviso de migração.
 </objective>
 
 <context>

package/oxe/workflows/ship.md

@@ -0,0 +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>

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,19 +1,23 @@
-# OXE — Workflow: ui-review
-
-<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>
-
+# 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>
+
+<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).
@@ -24,9 +28,9 @@ Não substitui **`verify`**: cruza contrato UI; o verify global continua a amarr
    - **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>
+
+<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/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.md

@@ -11,8 +11,40 @@ 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.
@@ -173,9 +205,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.