oxe-cc 1.0.0 → 1.3.0

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/route.md

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

package/oxe/workflows/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`.