oxe-cc 0.6.2 → 0.6.4

package/oxe/workflows/oxe.md

@@ -1,115 +1,115 @@
-# OXE — Workflow: oxe (entrada universal)
-
-<objective>
-Ponto de entrada inteligente do OXE. Faz uma de três coisas dependendo do input do usuário:
-
-1. **Sem input / "o que faço agora?"** → lê `STATE.md` e recomenda exatamente 1 próximo passo (lógica de `next.md`).
-2. **Input em linguagem natural** (ex.: "quero adicionar login", "preciso revisar um PR") → traduz para o comando OXE correto e executa ou orienta (lógica de `route.md`).
-3. **"help", "o que é OXE" ou "comandos"** → apresenta o fluxo dos 8 comandos essenciais e a cadeia canônica.
-
-**Princípio:** o usuário não precisa decorar o nome do comando — `/oxe [contexto]` resolve.
-</objective>
-
-<context>
-- Este workflow **não gera artefatos** por conta própria. Ele orienta ou delega para o workflow correto.
-- Lê `STATE.md` quando disponível para personalizar a resposta ao estado atual do projeto.
-- Quando o input for claro o suficiente para um workflow específico, **executar diretamente** esse workflow (carregar e seguir o `.md` correspondente) em vez de só sugerir o comando.
-- Quando houver ambiguidade genuína, apresentar 2 opções e pedir escolha — nunca listas longas.
-</context>
-
-<modo_status>
-## Modo: Status + Próximo Passo (sem input ou "o que faço agora?")
-
-Aplicar a lógica completa de `oxe/workflows/next.md`:
-
-1. Se `.oxe/` ou `STATE.md` não existir → **scan** (`npx oxe-cc@latest` primeiro se OXE não instalado)
-2. Se `.oxe/codebase/` incompleto e não for quick isolado → **scan**
-3. Se `quick_active` ou `QUICK.md` sem `PLAN.md` → avaliar promoção (ver `next.md`)
-4. Se sem `SPEC.md` → **spec**
-5. Se SPEC mas sem PLAN → verificar `discuss_before_plan` → **discuss** ou **plan**
-6. Se PLAN sem VERIFY pós-implementação → **execute** ou **verify**
-7. Se VERIFY com falha → **plan --replan**
-8. Se VERIFY OK → próxima feature ou milestone
-
-**Saída:** exatamente 1 passo, 1 comando, 1 frase de justificativa.
-</modo_status>
-
-<modo_route>
-## Modo: Roteamento de Linguagem Natural (input com contexto)
-
-Mapear o input para o workflow correto e executar ou orientar:
-
-| Se o usuário disser | Executar |
-|---------------------|----------|
-| "quero [feature / tarefa / entrega]" | Verificar estado → **spec** ou **quick** |
-| "analisa / mapeia o projeto" | **scan** (modo refresh se codebase/ existir) |
-| "pesquisa / spike / quero entender X" | **research** |
-| "revisa PR / diff" | **review-pr** |
-| "auditoria de segurança" | **security** |
-| "valida / verifica" | **verify** |
-| "milestone / release / versão" | **project milestone** |
-| "trilha paralela / workstream" | **project workstream** |
-| "snapshot / checkpoint" | **project checkpoint** |
-| "recuperação / erro / algo quebrou" | **forensics** |
-| "debug / teste falhando" | **debug** |
-| "obs / observação / nota" | **obs** |
-| "atualiza / update OXE" | **update** |
-
-Se o input não mapear claramente → apresentar 2 opções mais prováveis e perguntar.
-</modo_route>
-
-<modo_help>
-## Modo: Help (quando o usuário pede "help", "o que é OXE", "comandos")
-
-Apresentar de forma concisa:
-
-### Os 8 comandos que você precisa conhecer
-
-```
-/oxe              → onde estou / o que faço / help
-/oxe-obs          → registrei algo importante agora
-/oxe-quick        → tarefa pequena, sem cerimônia
-/oxe-scan         → mapeia o projeto (ou atualiza o mapa)
-/oxe-spec         → nova feature ou entrega: perguntas → requisitos → roteiro
-/oxe-plan         → detalhar em tarefas (--agents para multi-agente)
-/oxe-execute      → implementar (A: completo | B: por onda | C: por tarefa)
-/oxe-verify       → validar que está pronto
-```
-
-### A cadeia
-
-```
-/oxe-obs (qualquer momento)
-     ↓
-/oxe-scan → /oxe-spec → /oxe-plan → /oxe-execute → /oxe-verify → /oxe-retro
-                                  ↓
-                           /oxe-quick (trabalho pequeno)
-```
-
-### Para saber o próximo passo agora
-
-```
-/oxe
-```
-
-### Escape hatches (não precisa decorar — aparecem quando necessários)
-
-`/oxe-research`, `/oxe-forensics`, `/oxe-debug`, `/oxe-loop`, `/oxe-security`,
-`/oxe-validate-gaps`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-review-pr`,
-`/oxe-project` (milestone, workstream, checkpoint)
-</modo_help>
-
-<process>
-1. Verificar se há input adicional na mensagem:
-   - **Sem input ou "next / o que faço / status":** aplicar `<modo_status>`.
-   - **"help / comandos / o que é OXE":** aplicar `<modo_help>`.
-   - **Qualquer outra coisa (linguagem natural com contexto):** aplicar `<modo_route>` e, se o workflow for claro, carregar e executar diretamente o `oxe/workflows/<nome>.md` correspondente.
-2. Nunca produzir listas longas de alternativas. Um passo, um comando, uma frase.
-3. Se o workflow executado diretamente gerar artefatos, reportar no chat conforme esse workflow.
-</process>
-
-<success_criteria>
-- [ ] Usuário recebe exatamente 1 próximo passo (modo status) OU 1 workflow executado (modo route) OU o bloco help compacto (modo help).
-- [ ] Nenhum artefato criado por este workflow diretamente (a menos que o workflow delegado o faça).
-- [ ] Nunca lista mais de 2 alternativas ao mesmo tempo.
-</success_criteria>
+# OXE — Workflow: oxe (entrada universal)
+
+<objective>
+Ponto de entrada inteligente do OXE. Faz uma de três coisas dependendo do input do usuário:
+
+1. **Sem input / "o que faço agora?"** → lê `STATE.md` e recomenda exatamente 1 próximo passo (lógica de `next.md`).
+2. **Input em linguagem natural** (ex.: "quero adicionar login", "preciso revisar um PR") → traduz para o comando OXE correto e executa ou orienta (lógica de `route.md`).
+3. **"help", "o que é OXE" ou "comandos"** → apresenta o fluxo dos 8 comandos essenciais e a cadeia canônica.
+
+**Princípio:** o usuário não precisa decorar o nome do comando — `/oxe [contexto]` resolve.
+</objective>
+
+<context>
+- Este workflow **não gera artefatos** por conta própria. Ele orienta ou delega para o workflow correto.
+- Lê `STATE.md` quando disponível para personalizar a resposta ao estado atual do projeto.
+- Quando o input for claro o suficiente para um workflow específico, **executar diretamente** esse workflow (carregar e seguir o `.md` correspondente) em vez de só sugerir o comando.
+- Quando houver ambiguidade genuína, apresentar 2 opções e pedir escolha — nunca listas longas.
+</context>
+
+<modo_status>
+## Modo: Status + Próximo Passo (sem input ou "o que faço agora?")
+
+Aplicar a lógica completa de `oxe/workflows/next.md`:
+
+1. Se `.oxe/` ou `STATE.md` não existir → **scan** (`npx oxe-cc@latest` primeiro se OXE não instalado)
+2. Se `.oxe/codebase/` incompleto e não for quick isolado → **scan**
+3. Se `quick_active` ou `QUICK.md` sem `PLAN.md` → avaliar promoção (ver `next.md`)
+4. Se sem `SPEC.md` → **spec**
+5. Se SPEC mas sem PLAN → verificar `discuss_before_plan` → **discuss** ou **plan**
+6. Se PLAN sem VERIFY pós-implementação → **execute** ou **verify**
+7. Se VERIFY com falha → **plan --replan**
+8. Se VERIFY OK → próxima feature ou milestone
+
+**Saída:** exatamente 1 passo, 1 comando, 1 frase de justificativa.
+</modo_status>
+
+<modo_route>
+## Modo: Roteamento de Linguagem Natural (input com contexto)
+
+Mapear o input para o workflow correto e executar ou orientar:
+
+| Se o usuário disser | Executar |
+|---------------------|----------|
+| "quero [feature / tarefa / entrega]" | Verificar estado → **spec** ou **quick** |
+| "analisa / mapeia o projeto" | **scan** (modo refresh se codebase/ existir) |
+| "pesquisa / spike / quero entender X" | **research** |
+| "revisa PR / diff" | **review-pr** |
+| "auditoria de segurança" | **security** |
+| "valida / verifica" | **verify** |
+| "milestone / release / versão" | **project milestone** |
+| "trilha paralela / workstream" | **project workstream** |
+| "snapshot / checkpoint" | **project checkpoint** |
+| "recuperação / erro / algo quebrou" | **forensics** |
+| "debug / teste falhando" | **debug** |
+| "obs / observação / nota" | **obs** |
+| "atualiza / update OXE" | **update** |
+
+Se o input não mapear claramente → apresentar 2 opções mais prováveis e perguntar.
+</modo_route>
+
+<modo_help>
+## Modo: Help (quando o usuário pede "help", "o que é OXE", "comandos")
+
+Apresentar de forma concisa:
+
+### Os 8 comandos que você precisa conhecer
+
+```
+/oxe              → onde estou / o que faço / help
+/oxe-obs          → registrei algo importante agora
+/oxe-quick        → tarefa pequena, sem cerimônia
+/oxe-scan         → mapeia o projeto (ou atualiza o mapa)
+/oxe-spec         → nova feature ou entrega: perguntas → requisitos → roteiro
+/oxe-plan         → detalhar em tarefas (--agents para multi-agente)
+/oxe-execute      → implementar (A: completo | B: por onda | C: por tarefa)
+/oxe-verify       → validar que está pronto
+```
+
+### A cadeia
+
+```
+/oxe-obs (qualquer momento)
+     ↓
+/oxe-scan → /oxe-spec → /oxe-plan → /oxe-execute → /oxe-verify → /oxe-retro
+                                  ↓
+                           /oxe-quick (trabalho pequeno)
+```
+
+### Para saber o próximo passo agora
+
+```
+/oxe
+```
+
+### Escape hatches (não precisa decorar — aparecem quando necessários)
+
+`/oxe-research`, `/oxe-forensics`, `/oxe-debug`, `/oxe-loop`, `/oxe-security`,
+`/oxe-validate-gaps`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-review-pr`,
+`/oxe-project` (milestone, workstream, checkpoint)
+</modo_help>
+
+<process>
+1. Verificar se há input adicional na mensagem:
+   - **Sem input ou "next / o que faço / status":** aplicar `<modo_status>`.
+   - **"help / comandos / o que é OXE":** aplicar `<modo_help>`.
+   - **Qualquer outra coisa (linguagem natural com contexto):** aplicar `<modo_route>` e, se o workflow for claro, carregar e executar diretamente o `oxe/workflows/<nome>.md` correspondente.
+2. Nunca produzir listas longas de alternativas. Um passo, um comando, uma frase.
+3. Se o workflow executado diretamente gerar artefatos, reportar no chat conforme esse workflow.
+</process>
+
+<success_criteria>
+- [ ] Usuário recebe exatamente 1 próximo passo (modo status) OU 1 workflow executado (modo route) OU o bloco help compacto (modo help).
+- [ ] Nenhum artefato criado por este workflow diretamente (a menos que o workflow delegado o faça).
+- [ ] Nunca lista mais de 2 alternativas ao mesmo tempo.
+</success_criteria>

package/oxe/workflows/project.md

@@ -1,50 +1,50 @@
-# OXE — Workflow: project (gestão de projeto)
-
-<objective>
-Ponto de entrada unificado para as três operações de gestão de projeto OXE:
-
-- **milestone** — marcos de entrega (M-NN): `new`, `complete`, `status`, `audit`
-- **workstream** — trilhas paralelas: `new <nome>`, `switch <nome>`, `list`, `close <nome>`
-- **checkpoint** — snapshot nomeado de sessão: `[slug]`
-
-Detecta a operação pelo primeiro token do input e delega ao workflow canônico correspondente.
-</objective>
-
-<context>
-- Este workflow é um **dispatcher**: lê o input, identifica a operação e executa o workflow correto.
-- Workflows canônicos: `oxe/workflows/milestone.md`, `oxe/workflows/workstream.md`, `oxe/workflows/checkpoint.md`.
-- Se o input for ambíguo, apresentar as 3 operações disponíveis e pedir escolha.
-- Sem input: mostrar o estado atual de milestones e workstreams ativos lendo `STATE.md`, `MILESTONES.md` e `CHECKPOINTS.md`.
-</context>
-
-<dispatch_table>
-| Input começa com | Delega para | Exemplos |
-|------------------|-------------|---------|
-| `milestone new ...` | `milestone.md` + subcomando `new` | `/oxe-project milestone new v1.0` |
-| `milestone complete` | `milestone.md` + subcomando `complete` | `/oxe-project milestone complete` |
-| `milestone status` | `milestone.md` + subcomando `status` | `/oxe-project milestone status` |
-| `milestone audit` | `milestone.md` + subcomando `audit` | `/oxe-project milestone audit` |
-| `workstream new <nome>` | `workstream.md` + subcomando `new` | `/oxe-project workstream new auth` |
-| `workstream switch <nome>` | `workstream.md` + subcomando `switch` | `/oxe-project workstream switch auth` |
-| `workstream list` | `workstream.md` + subcomando `list` | `/oxe-project workstream list` |
-| `workstream close <nome>` | `workstream.md` + subcomando `close` | `/oxe-project workstream close auth` |
-| `checkpoint [slug]` | `checkpoint.md` | `/oxe-project checkpoint pre-refactor` |
-| *(sem input)* | Status atual | `/oxe-project` |
-</dispatch_table>
-
-<process>
-1. Ler o input do usuário (texto após o comando).
-2. Identificar o primeiro token:
-   - `milestone` → carregar e executar `oxe/workflows/milestone.md` passando o restante como subcomando.
-   - `workstream` → carregar e executar `oxe/workflows/workstream.md` passando o restante como subcomando.
-   - `checkpoint` → carregar e executar `oxe/workflows/checkpoint.md` passando o slug (se houver).
-   - *(vazio)* → ler `STATE.md`, `MILESTONES.md` (se existir) e listar: milestone ativo (M-NN / nenhum), workstreams abertos, último checkpoint. Sugerir próxima operação.
-   - *(ambíguo)* → listar as 3 operações disponíveis com exemplos de uso.
-3. Executar o workflow delegado integralmente.
-</process>
-
-<success_criteria>
-- [ ] O workflow correto foi executado com base no input.
-- [ ] Sem input: STATUS atual de milestone ativo, workstreams e último checkpoint mostrado.
-- [ ] Input ambíguo: máximo 3 opções apresentadas com exemplos, não listas longas.
-</success_criteria>
+# OXE — Workflow: project (gestão de projeto)
+
+<objective>
+Ponto de entrada unificado para as três operações de gestão de projeto OXE:
+
+- **milestone** — marcos de entrega (M-NN): `new`, `complete`, `status`, `audit`
+- **workstream** — trilhas paralelas: `new <nome>`, `switch <nome>`, `list`, `close <nome>`
+- **checkpoint** — snapshot nomeado de sessão: `[slug]`
+
+Detecta a operação pelo primeiro token do input e delega ao workflow canônico correspondente.
+</objective>
+
+<context>
+- Este workflow é um **dispatcher**: lê o input, identifica a operação e executa o workflow correto.
+- Workflows canônicos: `oxe/workflows/milestone.md`, `oxe/workflows/workstream.md`, `oxe/workflows/checkpoint.md`.
+- Se o input for ambíguo, apresentar as 3 operações disponíveis e pedir escolha.
+- Sem input: mostrar o estado atual de milestones e workstreams ativos lendo `STATE.md`, `MILESTONES.md` e `CHECKPOINTS.md`.
+</context>
+
+<dispatch_table>
+| Input começa com | Delega para | Exemplos |
+|------------------|-------------|---------|
+| `milestone new ...` | `milestone.md` + subcomando `new` | `/oxe-project milestone new v1.0` |
+| `milestone complete` | `milestone.md` + subcomando `complete` | `/oxe-project milestone complete` |
+| `milestone status` | `milestone.md` + subcomando `status` | `/oxe-project milestone status` |
+| `milestone audit` | `milestone.md` + subcomando `audit` | `/oxe-project milestone audit` |
+| `workstream new <nome>` | `workstream.md` + subcomando `new` | `/oxe-project workstream new auth` |
+| `workstream switch <nome>` | `workstream.md` + subcomando `switch` | `/oxe-project workstream switch auth` |
+| `workstream list` | `workstream.md` + subcomando `list` | `/oxe-project workstream list` |
+| `workstream close <nome>` | `workstream.md` + subcomando `close` | `/oxe-project workstream close auth` |
+| `checkpoint [slug]` | `checkpoint.md` | `/oxe-project checkpoint pre-refactor` |
+| *(sem input)* | Status atual | `/oxe-project` |
+</dispatch_table>
+
+<process>
+1. Ler o input do usuário (texto após o comando).
+2. Identificar o primeiro token:
+   - `milestone` → carregar e executar `oxe/workflows/milestone.md` passando o restante como subcomando.
+   - `workstream` → carregar e executar `oxe/workflows/workstream.md` passando o restante como subcomando.
+   - `checkpoint` → carregar e executar `oxe/workflows/checkpoint.md` passando o slug (se houver).
+   - *(vazio)* → ler `STATE.md`, `MILESTONES.md` (se existir) e listar: milestone ativo (M-NN / nenhum), workstreams abertos, último checkpoint. Sugerir próxima operação.
+   - *(ambíguo)* → listar as 3 operações disponíveis com exemplos de uso.
+3. Executar o workflow delegado integralmente.
+</process>
+
+<success_criteria>
+- [ ] O workflow correto foi executado com base no input.
+- [ ] Sem input: STATUS atual de milestone ativo, workstreams e último checkpoint mostrado.
+- [ ] Input ambíguo: máximo 3 opções apresentadas com exemplos, não listas longas.
+</success_criteria>

package/oxe/workflows/quick.md

@@ -140,7 +140,7 @@ No final de **`.oxe/QUICK.md`**, mantenha a linha:
 Se **sim**, o próximo passo recomendado no chat é **`/oxe-spec`** (depois discuss/plan conforme config).
 
 <process>
-1. Garantir `.oxe/` (usar template de STATE só se `STATE.md` não existir).
+1. Garantir `.oxe/` (usar template de STATE só se `STATE.md` não existir). Verificar **`.oxe/OBSERVATIONS.md`** — se houver entradas `pendente` com impacto `all`, registrar como restrições nos **Passos** ou no **Contexto** do QUICK.md antes de finalizar; marcar as OBS como `incorporada → quick (data)`.
 2. Avaliar se PDDA lean se aplica (ver `<plan_driven_dynamic_agents_lean>` — domínios distintos, 5+ passos, ou flag `--agents`).
 3. Criar ou substituir **`.oxe/QUICK.md`** com:
    - **Objetivo** — uma frase. *(Esta é a minispec: restringe o escopo de todos os agentes e passos.)*

package/oxe/workflows/retro.md

@@ -1,62 +1,62 @@
-# OXE — Workflow: retro (retrospectiva de ciclo)
-
-<objective>
-Sintetizar os aprendizados de um ciclo completo (spec → verify) em **`.oxe/LESSONS.md`** — um arquivo prescritivo e cumulativo que alimenta automaticamente ciclos futuros.
-
-**Princípio:** lições não são diário — são instruções para o próximo ciclo. Cada entrada diz COMO agir diferente, não apenas o que aconteceu.
-
-Pode ser chamado:
-- Após `/oxe-verify` (ciclo normal completo)
-- Após `/oxe-verify` com falha e replanejamento (ciclo com retrabalho)
-- A qualquer momento para capturar aprendizados antes que se percam
-</objective>
-
-<context>
-- **Pré-requisito preferível:** `.oxe/VERIFY.md` existente. Sem ele, a retro é baseada em STATE.md e relato do usuário.
-- **Artefato:** `.oxe/LESSONS.md` — append-only por padrão; nunca apagar entradas anteriores, apenas mudar `Status` para `resolvido`.
-- **Consumidores:** `/oxe-spec` (lições tipo `spec`), `/oxe-plan` (lições tipo `plan`), `/oxe-scan` (lições tipo `process`), `/oxe-execute` (lições tipo `execute`).
-- **Ciclo ID:** sequencial `C-01`, `C-02`, … (continuar do último em LESSONS.md).
-- Template: `oxe/templates/LESSONS.template.md`.
-</context>
-
-<taxonomy>
-## Taxonomia de tipos de lição
-
-| Tipo | Quando usar | Consumido por |
-|------|-------------|---------------|
-| `spec` | Problemas na definição de requisitos ou critérios A* | `/oxe-spec` Fase 1/3 |
-| `plan` | Problemas de granularidade, ondas, verificações | `/oxe-plan` |
-| `execute` | Padrões de falha na implementação, hipóteses erradas | `/oxe-execute` |
-| `verify` | Critérios vagos, evidências insuficientes, camadas puladas | `/oxe-verify` |
-| `process` | Escolha errada de workflow (quick vs spec, solo vs agents) | `/oxe-scan`, qualquer entry |
-| `agents` | Problemas de orquestração, runId, dependências de agente | `/oxe-plan-agent`, `/oxe-execute` |
-
-**Formato de lição (prescritivo, não descritivo):**
-- ❌ "A tarefa T4 demorou muito" (descritivo — não ajuda no próximo ciclo)
-- ✅ "Tarefas com integração de terceiros devem ter Complexidade L mínimo + Verificar com mock fallback" (prescritivo — o próximo plan pode aplicar)
-</taxonomy>
-
-<process>
-1. Ler **`.oxe/VERIFY.md`** se existir: identificar tarefas que falharam, critérios A* sem evidência, gaps documentados.
-2. Ler **`.oxe/FORENSICS.md`** se existir: capturar causa raiz de falhas de execução.
-3. Ler **`.oxe/SUMMARY.md`** se existir: capturar contexto de replans e decisões forçadas.
-4. Ler **`.oxe/STATE.md`**: capturar número de ondas, execute_mode usado, se houve loop, se houve escalação para forensics.
-5. Sintetizar **3–5 lições prescritivas** (não mais — qualidade sobre quantidade):
-   - Cada lição responde: "O que o próximo ciclo deve fazer diferente?"
-   - Formato: **Lição** (o que fazer) + **Raiz** (por que isso aconteceu) + **Tipo** + **Aplicar em**
-6. Determinar o próximo **ciclo ID** (C-NN) lendo `.oxe/LESSONS.md` existente ou começando em C-01.
-7. Criar ou atualizar **`.oxe/LESSONS.md`** usando `oxe/templates/LESSONS.template.md`:
-   - Adicionar linha na tabela de índice (mais recente primeiro).
-   - Adicionar seção `### C-NN` com as lições sintetizadas.
-   - **Nunca apagar** entradas anteriores — só mudar `Status: resolvido` se a lição foi superada.
-8. Atualizar **`.oxe/STATE.md`**: campo `last_retro: YYYY-MM-DD`.
-9. Responder no chat: ID do ciclo (C-NN), número de lições registradas, lição mais crítica em 1 frase, sugestão do próximo ciclo (`/oxe-scan` ou `/oxe-spec`).
-</process>
-
-<success_criteria>
-- [ ] `.oxe/LESSONS.md` existe com entrada C-NN na tabela e seção de detalhe.
-- [ ] Cada lição é prescritiva (diz o que fazer) não descritiva (não é só o que aconteceu).
-- [ ] 3–5 lições por ciclo — não um dump completo de eventos.
-- [ ] `STATE.md` tem `last_retro` atualizado.
-- [ ] Entradas anteriores preservadas; apenas `Status` pode mudar.
-</success_criteria>
+# OXE — Workflow: retro (retrospectiva de ciclo)
+
+<objective>
+Sintetizar os aprendizados de um ciclo completo (spec → verify) em **`.oxe/LESSONS.md`** — um arquivo prescritivo e cumulativo que alimenta automaticamente ciclos futuros.
+
+**Princípio:** lições não são diário — são instruções para o próximo ciclo. Cada entrada diz COMO agir diferente, não apenas o que aconteceu.
+
+Pode ser chamado:
+- Após `/oxe-verify` (ciclo normal completo)
+- Após `/oxe-verify` com falha e replanejamento (ciclo com retrabalho)
+- A qualquer momento para capturar aprendizados antes que se percam
+</objective>
+
+<context>
+- **Pré-requisito preferível:** `.oxe/VERIFY.md` existente. Sem ele, a retro é baseada em STATE.md e relato do usuário.
+- **Artefato:** `.oxe/LESSONS.md` — append-only por padrão; nunca apagar entradas anteriores, apenas mudar `Status` para `resolvido`.
+- **Consumidores:** `/oxe-spec` (lições tipo `spec`), `/oxe-plan` (lições tipo `plan`), `/oxe-scan` (lições tipo `process`), `/oxe-execute` (lições tipo `execute`).
+- **Ciclo ID:** sequencial `C-01`, `C-02`, … (continuar do último em LESSONS.md).
+- Template: `oxe/templates/LESSONS.template.md`.
+</context>
+
+<taxonomy>
+## Taxonomia de tipos de lição
+
+| Tipo | Quando usar | Consumido por |
+|------|-------------|---------------|
+| `spec` | Problemas na definição de requisitos ou critérios A* | `/oxe-spec` Fase 1/3 |
+| `plan` | Problemas de granularidade, ondas, verificações | `/oxe-plan` |
+| `execute` | Padrões de falha na implementação, hipóteses erradas | `/oxe-execute` |
+| `verify` | Critérios vagos, evidências insuficientes, camadas puladas | `/oxe-verify` |
+| `process` | Escolha errada de workflow (quick vs spec, solo vs agents) | `/oxe-scan`, qualquer entry |
+| `agents` | Problemas de orquestração, runId, dependências de agente | `/oxe-plan-agent`, `/oxe-execute` |
+
+**Formato de lição (prescritivo, não descritivo):**
+- ❌ "A tarefa T4 demorou muito" (descritivo — não ajuda no próximo ciclo)
+- ✅ "Tarefas com integração de terceiros devem ter Complexidade L mínimo + Verificar com mock fallback" (prescritivo — o próximo plan pode aplicar)
+</taxonomy>
+
+<process>
+1. Ler **`.oxe/VERIFY.md`** se existir: identificar tarefas que falharam, critérios A* sem evidência, gaps documentados.
+2. Ler **`.oxe/FORENSICS.md`** se existir: capturar causa raiz de falhas de execução.
+3. Ler **`.oxe/SUMMARY.md`** se existir: capturar contexto de replans e decisões forçadas.
+4. Ler **`.oxe/STATE.md`**: capturar número de ondas, execute_mode usado, se houve loop, se houve escalação para forensics.
+5. Sintetizar **3–5 lições prescritivas** (não mais — qualidade sobre quantidade):
+   - Cada lição responde: "O que o próximo ciclo deve fazer diferente?"
+   - Formato: **Lição** (o que fazer) + **Raiz** (por que isso aconteceu) + **Tipo** + **Aplicar em**
+6. Determinar o próximo **ciclo ID** (C-NN) lendo `.oxe/LESSONS.md` existente ou começando em C-01.
+7. Criar ou atualizar **`.oxe/LESSONS.md`** usando `oxe/templates/LESSONS.template.md`:
+   - Adicionar linha na tabela de índice (mais recente primeiro).
+   - Adicionar seção `### C-NN` com as lições sintetizadas.
+   - **Nunca apagar** entradas anteriores — só mudar `Status: resolvido` se a lição foi superada.
+8. Atualizar **`.oxe/STATE.md`**: campo `last_retro: YYYY-MM-DD`.
+9. Responder no chat: ID do ciclo (C-NN), número de lições registradas, lição mais crítica em 1 frase, sugestão do próximo ciclo (`/oxe-scan` ou `/oxe-spec`).
+</process>
+
+<success_criteria>
+- [ ] `.oxe/LESSONS.md` existe com entrada C-NN na tabela e seção de detalhe.
+- [ ] Cada lição é prescritiva (diz o que fazer) não descritiva (não é só o que aconteceu).
+- [ ] 3–5 lições por ciclo — não um dump completo de eventos.
+- [ ] `STATE.md` tem `last_retro` atualizado.
+- [ ] Entradas anteriores preservadas; apenas `Status` pode mudar.
+</success_criteria>

package/oxe/workflows/security.md

@@ -1,61 +1,61 @@
-# OXE — Workflow: security (auditoria de segurança)
-
-<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.
-
-Pode ser chamado standalone ou como Camada 5 do **`verify.md`** quando `config.json` tiver `"security_in_verify": true`.
-
-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>
-- **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`.
-- **Integração com verify:** se `security_in_verify: true` em `.oxe/config.json`, o workflow `verify.md` inclui referência a este output como Camada 5. O `security.md` continua sendo o workflow canônico.
-- **Não alterar código:** apenas auditar e registrar achados. Nenhum arquivo de código é modificado.
-</context>
-
-<owasp_scope>
-## Mapeamento OWASP → Stack
-
-Antes de auditar, determinar quais categorias se aplicam lendo `STACK.md` e `INTEGRATIONS.md`:
-
-| Categoria OWASP | Aplicável quando |
-|-----------------|-----------------|
-| A01 — Broken Access Control | App com autenticação/autorização ou rotas protegidas |
-| A02 — Cryptographic Failures | Dados sensíveis em trânsito ou em repouso; senhas; tokens |
-| A03 — Injection | DB queries, shell commands, parsers de entrada, templates |
-| A04 — Insecure Design | Ausência de modelagem de ameaças; fluxos de negócio sem validação |
-| A05 — Security Misconfiguration | Config de servidor, CORS, headers HTTP, variáveis de ambiente |
-| A06 — Vulnerable Components | Dependências com CVEs conhecidos; versões sem suporte |
-| A07 — Authentication Failures | Login, sessão, JWT, OAuth, tokens de reset |
-| A08 — Software Integrity | Supply chain; checksums; CI/CD sem verificação |
-| A09 — Logging & Monitoring | Ausência de logs de eventos críticos; dados sensíveis em logs |
-| A10 — SSRF | Requisições a URLs controladas pelo usuário; fetch/proxy interno |
-
-**Selecionar apenas as categorias aplicáveis** ao stack identificado. Listar explicitamente as ignoradas e o motivo.
-</owasp_scope>
-
-<process>
-1. Ler `.oxe/codebase/STACK.md`, `.oxe/codebase/STRUCTURE.md`, `.oxe/codebase/INTEGRATIONS.md`, `.oxe/codebase/CONCERNS.md`.
-2. Selecionar categorias OWASP aplicáveis ao stack (ver `<owasp_scope>`); registrar as descartadas.
-3. Para cada categoria aplicável:
-   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 `.oxe/PLAN.md` se existir — vincular achados P0/P1 a tarefas `Tn` existentes quando possível, ou criar sugestão `T_new`.
-5. Escrever `.oxe/SECURITY.md` a partir de `oxe/templates/SECURITY.template.md`.
-6. Atualizar `.oxe/STATE.md`: nota de segurança (ex.: `security_audit: YYYY-MM-DD | P0:N | P1:N | P2:N`).
-7. Responder no chat: total de achados por severidade, arquivos mais críticos identificados, próximo passo (P0 presentes → bloquear deploy; apenas P2 → ação opcional).
-</process>
-
-<success_criteria>
-- [ ] `.oxe/SECURITY.md` existe 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`.
-- [ ] Nenhum arquivo de código foi modificado.
-- [ ] STATE.md tem linha `security_audit` com data e contagem de achados.
-</success_criteria>
+# OXE — Workflow: security (auditoria de segurança)
+
+<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.
+
+Pode ser chamado standalone ou como Camada 5 do **`verify.md`** quando `config.json` tiver `"security_in_verify": true`.
+
+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>
+- **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`.
+- **Integração com verify:** se `security_in_verify: true` em `.oxe/config.json`, o workflow `verify.md` inclui referência a este output como Camada 5. O `security.md` continua sendo o workflow canônico.
+- **Não alterar código:** apenas auditar e registrar achados. Nenhum arquivo de código é modificado.
+</context>
+
+<owasp_scope>
+## Mapeamento OWASP → Stack
+
+Antes de auditar, determinar quais categorias se aplicam lendo `STACK.md` e `INTEGRATIONS.md`:
+
+| Categoria OWASP | Aplicável quando |
+|-----------------|-----------------|
+| A01 — Broken Access Control | App com autenticação/autorização ou rotas protegidas |
+| A02 — Cryptographic Failures | Dados sensíveis em trânsito ou em repouso; senhas; tokens |
+| A03 — Injection | DB queries, shell commands, parsers de entrada, templates |
+| A04 — Insecure Design | Ausência de modelagem de ameaças; fluxos de negócio sem validação |
+| A05 — Security Misconfiguration | Config de servidor, CORS, headers HTTP, variáveis de ambiente |
+| A06 — Vulnerable Components | Dependências com CVEs conhecidos; versões sem suporte |
+| A07 — Authentication Failures | Login, sessão, JWT, OAuth, tokens de reset |
+| A08 — Software Integrity | Supply chain; checksums; CI/CD sem verificação |
+| A09 — Logging & Monitoring | Ausência de logs de eventos críticos; dados sensíveis em logs |
+| A10 — SSRF | Requisições a URLs controladas pelo usuário; fetch/proxy interno |
+
+**Selecionar apenas as categorias aplicáveis** ao stack identificado. Listar explicitamente as ignoradas e o motivo.
+</owasp_scope>
+
+<process>
+1. Ler `.oxe/codebase/STACK.md`, `.oxe/codebase/STRUCTURE.md`, `.oxe/codebase/INTEGRATIONS.md`, `.oxe/codebase/CONCERNS.md`.
+2. Selecionar categorias OWASP aplicáveis ao stack (ver `<owasp_scope>`); registrar as descartadas.
+3. Para cada categoria aplicável:
+   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 `.oxe/PLAN.md` se existir — vincular achados P0/P1 a tarefas `Tn` existentes quando possível, ou criar sugestão `T_new`.
+5. Escrever `.oxe/SECURITY.md` a partir de `oxe/templates/SECURITY.template.md`.
+6. Atualizar `.oxe/STATE.md`: nota de segurança (ex.: `security_audit: YYYY-MM-DD | P0:N | P1:N | P2:N`).
+7. Responder no chat: total de achados por severidade, arquivos mais críticos identificados, próximo passo (P0 presentes → bloquear deploy; apenas P2 → ação opcional).
+</process>
+
+<success_criteria>
+- [ ] `.oxe/SECURITY.md` existe 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`.
+- [ ] Nenhum arquivo de código foi modificado.
+- [ ] STATE.md tem linha `security_audit` com data e contagem de achados.
+</success_criteria>

package/oxe/workflows/verify.md

@@ -104,4 +104,6 @@ O preenchimento da checklist é responsabilidade do **usuário** (não do agente
 - [ ] SUMMARY.md atualizado quando houver falha ou gaps relevantes.
 - [ ] Se passou: seções **Rascunho de commit** e **Checklist PR** presentes em VERIFY.md, salvo se desativadas na config.
 - [ ] Se existiu DISCUSS.md: tabela de Fidelidade de decisões preenchida sem divergências não documentadas.
+- [ ] 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.
 </success_criteria>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oxe-cc",
-  "version": "0.6.2",
+  "version": "0.6.4",
   "description": "OXE — spec-driven workflows in .oxe/; integrates with Cursor, GitHub Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity (npx)",
   "license": "GPL-3.0",
   "author": "",
@@ -54,7 +54,7 @@
   ],
   "scripts": {
     "sync:cursor": "node scripts/sync-cursor-from-prompts.cjs",
-    "test": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-sdk.test.cjs tests/oxe-manifest.test.cjs tests/oxe-agent-install.test.cjs tests/oxe-install-resolve-full.test.cjs tests/oxe-health-extended.test.cjs tests/oxe-workflows-edge.test.cjs tests/oxe-sdk-edge.test.cjs tests/oxe-cli-edge.test.cjs tests/oxe-npm-version.test.cjs tests/oxe-scripts.test.cjs",
+    "test": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-sdk.test.cjs tests/oxe-manifest.test.cjs tests/oxe-agent-install.test.cjs tests/oxe-install-resolve-full.test.cjs tests/oxe-health-extended.test.cjs tests/oxe-workflows-edge.test.cjs tests/oxe-sdk-edge.test.cjs tests/oxe-cli-edge.test.cjs tests/oxe-npm-version.test.cjs tests/oxe-scripts.test.cjs tests/oxe-retro-health.test.cjs",
     "test:coverage": "c8 --check-coverage --lines 82 --functions 85 --branches 58 --statements 82 npm test",
     "scan:assets": "node scripts/oxe-assets-scan.cjs",
     "prepublishOnly": "node scripts/sync-cursor-from-prompts.cjs && npm test && npm run scan:assets && node bin/oxe-cc.js --version"