oxe-cc 1.5.1 → 1.6.0

package/oxe/workflows/plan.md

@@ -1,83 +1,83 @@
 # OXE — Workflow: plan
 
-<objective>
-Produzir **`.oxe/PLAN.md`**: tarefas **pequenas**, **ondas** (paralelizáveis vs sequenciais), e **cada tarefa com bloco de verificação** (comando de teste e/ou checklist manual).
-
-Além do `PLAN.md`, este passo deve gerar no mesmo escopo resolvido da sessão os artefatos racionais de execução:
-- `.oxe/IMPLEMENTATION-PACK.md`
-- `.oxe/IMPLEMENTATION-PACK.json`
-- `.oxe/REFERENCE-ANCHORS.md`
-- `.oxe/FIXTURE-PACK.md`
-- `.oxe/FIXTURE-PACK.json`
-
-Esses artefatos são obrigatórios para considerar o plano executável. Quando algo não se aplicar, marcar explicitamente `not_applicable`; nunca omitir o arquivo.
-
-Base: `SPEC.md` do escopo resolvido da sessão (critérios com IDs **A1**, **A2**, …) + `.oxe/codebase/*` + código quando necessário (Grep/Read pontual).
-
-Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_failed`):
-- Ler `VERIFY.md` e `SUMMARY.md` do escopo resolvido, e o `PLAN.md` atual.
-- Preservar tarefas já concluídas ou renumerar com nota em **Replanejamento**; não apagar histórico útil — deslocar para a seção **Replanejamento** e reescrever **Tarefas** conforme necessário.
-- Se **SUMMARY.md** não existir, criar a partir de `oxe/templates/SUMMARY.template.md` para registrar o contexto do replan (ou dar append se já existir).
-</objective>
-
-<execution_rational_artifacts>
-## Artefatos racionais obrigatórios
-
-### IMPLEMENTATION-PACK
-Contrato de implementação por tarefa `Tn`, com:
-- caminhos exatos dos arquivos alvo, sem `...` e sem "arquivos prováveis" vagos;
-- symbols alvo (classe, função, método, listener, builder, config, migration);
-- assinatura/shape de entrada e saída;
-- dependências, invariantes, `not_allowed`, `write_set`, `expected_checks` e `requires_fixture`;
-- snippets somente quando ancorados em evidência local ou materializada.
-
-### REFERENCE-ANCHORS
-Materializa referências críticas que hoje ficam frouxas no plano:
-- predecessor, layout, contrato externo ou `external-ref`;
-- origem local ou materializada em `.oxe/investigations/externals/`;
-- `source_ref`, `path`, `relevance`, `action`, `summary`, `status`;
-- estados válidos: `resolved`, `missing`, `stale`, `conflicting`, `not_applicable`.
-
-### FIXTURE-PACK
-Fixtures mínimos por fluxo/tarefa de risco:
-- payloads, arquivos exemplo, trechos significativos, offsets/campos críticos;
-- expected outputs ou checks parciais/completos;
-- queries/checks de validação e smoke commands.
-
-Regra de readiness:
-- `IMPLEMENTATION-PACK` precisa estar `ready`;
-- `REFERENCE-ANCHORS` não pode ter âncora crítica em `missing|stale|conflicting`;
-- `FIXTURE-PACK` é obrigatório para tarefas mutáveis com parser/layout/integração/transformação/fila/migração/builder;
-- qualquer `critical_gap` aberto derruba a prontidão executável do plano.
-</execution_rational_artifacts>
-
-<plan_iteration_contract>
-## Contrato de iteração do plano
-
-Quando já existir `PLAN.md` no escopo resolvido, a regra do OXE é esta:
-
-1. **Mesmo escopo e mesma spec, mas o usuário quer refinar o plano**:
-   - tratar uma nova chamada de `/oxe-plan` como **replan implícito**, mesmo sem `--replan`;
-   - preservar histórico útil e preencher a seção **Replanejamento**.
-2. **A estratégia técnica mudou** (arquitetura, tradeoff, sequencing, decisão de implementação, boundary entre componentes):
-   - **não** reescrever o plano como se fosse só refinamento;
-   - orientar ou executar `discuss` antes do novo plano;
-   - depois voltar a `plan` em modo de replanejamento.
-3. **O escopo mudou** (requisitos, critérios A*, prioridade, corte de entrega, aceite, roadmap):
-   - **não** tratar como replan simples;
-   - voltar para `spec` antes de gerar novo plano.
-4. **Regra de precedência**:
-   - mudança de escopo → `spec`
-   - mudança de estratégia → `discuss`
-   - mudança de decomposição/ordem/risco/validação mantendo o mesmo escopo → `plan --replan`
-
-Resumo operacional:
-- `/oxe-plan` repetido até o usuário ficar satisfeito é válido, mas, se já houver `PLAN.md`, isso deve ser tratado como **replan implícito** por padrão.
-- O agente só deve continuar refinando o plano na mesma trilha quando os requisitos e critérios da `SPEC.md` permanecerem válidos.
-</plan_iteration_contract>
-
-<context>
-- Aplicar `oxe/workflows/references/reasoning-planning.md` como contrato deste passo. O `PLAN.md` deve sair decision-complete e não deixar decisões relevantes para a execução.
+<objective>
+Produzir **`.oxe/PLAN.md`**: tarefas **pequenas**, **ondas** (paralelizáveis vs sequenciais), e **cada tarefa com bloco de verificação** (comando de teste e/ou checklist manual).
+
+Além do `PLAN.md`, este passo deve gerar no mesmo escopo resolvido da sessão os artefatos racionais de execução:
+- `.oxe/IMPLEMENTATION-PACK.md`
+- `.oxe/IMPLEMENTATION-PACK.json`
+- `.oxe/REFERENCE-ANCHORS.md`
+- `.oxe/FIXTURE-PACK.md`
+- `.oxe/FIXTURE-PACK.json`
+
+Esses artefatos são obrigatórios para considerar o plano executável. Quando algo não se aplicar, marcar explicitamente `not_applicable`; nunca omitir o arquivo.
+
+Base: `SPEC.md` do escopo resolvido da sessão (critérios com IDs **A1**, **A2**, …) + `.oxe/codebase/*` + código quando necessário (Grep/Read pontual).
+
+Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_failed`):
+- Ler `VERIFY.md` e `SUMMARY.md` do escopo resolvido, e o `PLAN.md` atual.
+- Preservar tarefas já concluídas ou renumerar com nota em **Replanejamento**; não apagar histórico útil — deslocar para a seção **Replanejamento** e reescrever **Tarefas** conforme necessário.
+- Se **SUMMARY.md** não existir, criar a partir de `oxe/templates/SUMMARY.template.md` para registrar o contexto do replan (ou dar append se já existir).
+</objective>
+
+<execution_rational_artifacts>
+## Artefatos racionais obrigatórios
+
+### IMPLEMENTATION-PACK
+Contrato de implementação por tarefa `Tn`, com:
+- caminhos exatos dos arquivos alvo, sem `...` e sem "arquivos prováveis" vagos;
+- symbols alvo (classe, função, método, listener, builder, config, migration);
+- assinatura/shape de entrada e saída;
+- dependências, invariantes, `not_allowed`, `write_set`, `expected_checks` e `requires_fixture`;
+- snippets somente quando ancorados em evidência local ou materializada.
+
+### REFERENCE-ANCHORS
+Materializa referências críticas que hoje ficam frouxas no plano:
+- predecessor, layout, contrato externo ou `external-ref`;
+- origem local ou materializada em `.oxe/investigations/externals/`;
+- `source_ref`, `path`, `relevance`, `action`, `summary`, `status`;
+- estados válidos: `resolved`, `missing`, `stale`, `conflicting`, `not_applicable`.
+
+### FIXTURE-PACK
+Fixtures mínimos por fluxo/tarefa de risco:
+- payloads, arquivos exemplo, trechos significativos, offsets/campos críticos;
+- expected outputs ou checks parciais/completos;
+- queries/checks de validação e smoke commands.
+
+Regra de readiness:
+- `IMPLEMENTATION-PACK` precisa estar `ready`;
+- `REFERENCE-ANCHORS` não pode ter âncora crítica em `missing|stale|conflicting`;
+- `FIXTURE-PACK` é obrigatório para tarefas mutáveis com parser/layout/integração/transformação/fila/migração/builder;
+- qualquer `critical_gap` aberto derruba a prontidão executável do plano.
+</execution_rational_artifacts>
+
+<plan_iteration_contract>
+## Contrato de iteração do plano
+
+Quando já existir `PLAN.md` no escopo resolvido, a regra do OXE é esta:
+
+1. **Mesmo escopo e mesma spec, mas o usuário quer refinar o plano**:
+   - tratar uma nova chamada de `/oxe-plan` como **replan implícito**, mesmo sem `--replan`;
+   - preservar histórico útil e preencher a seção **Replanejamento**.
+2. **A estratégia técnica mudou** (arquitetura, tradeoff, sequencing, decisão de implementação, boundary entre componentes):
+   - **não** reescrever o plano como se fosse só refinamento;
+   - orientar ou executar `discuss` antes do novo plano;
+   - depois voltar a `plan` em modo de replanejamento.
+3. **O escopo mudou** (requisitos, critérios A*, prioridade, corte de entrega, aceite, roadmap):
+   - **não** tratar como replan simples;
+   - voltar para `spec` antes de gerar novo plano.
+4. **Regra de precedência**:
+   - mudança de escopo → `spec`
+   - mudança de estratégia → `discuss`
+   - mudança de decomposição/ordem/risco/validação mantendo o mesmo escopo → `plan --replan`
+
+Resumo operacional:
+- `/oxe-plan` repetido até o usuário ficar satisfeito é válido, mas, se já houver `PLAN.md`, isso deve ser tratado como **replan implícito** por padrão.
+- O agente só deve continuar refinando o plano na mesma trilha quando os requisitos e critérios da `SPEC.md` permanecerem válidos.
+</plan_iteration_contract>
+
+<context>
+- Aplicar `oxe/workflows/references/reasoning-planning.md` como contrato deste passo. O `PLAN.md` deve sair decision-complete e não deixar decisões relevantes para a execução.
 - Seguir `oxe/workflows/references/flow-robustness-contract.md` como contrato canónico de robustez. A ordem obrigatória é: ler artefatos, resolver sessão/paths, validar pré-condições, escrever o plano, autoavaliar o plano, registrar próximo passo único.
 - Resolver `active_session` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa, o plano vive em `.oxe/<active_session>/plan/` e lê a spec em `.oxe/<active_session>/spec/`.
 - Antes do scan amplo, carregar `.oxe/context/packs/plan.md` e `.oxe/context/packs/plan.json` como entrada prioritária do contexto do passo.
@@ -152,11 +152,11 @@ Depois do resumo e antes das tarefas, o `PLAN.md` deve conter também:
 | Clareza da validação / testes | 15 |
 | Lacunas externas / decisões pendentes | 10 |
 
-**Faixas semânticas obrigatórias:**
-- `91–100%` → pronto para executar
-- `80–90%` → plano racional, mas ainda não executável
-- `50–79%` → precisa refino antes de execução
-- `<50%` → não executar
+**Faixas semânticas obrigatórias:**
+- `91–100%` → pronto para executar
+- `80–90%` → plano racional, mas ainda não executável
+- `50–79%` → precisa refino antes de execução
+- `<50%` → não executar
 
 **Entradas obrigatórias da confiança:**
 - usar as incertezas estruturadas da SPEC e as investigações concluídas como base direta da rubrica;
@@ -171,9 +171,9 @@ Depois do resumo e antes das tarefas, o `PLAN.md` deve conter também:
 | `L` | < 1 dia, múltiplos componentes | Verificar que Verificar é específico |
 | `XL` | > 1 dia, impacto arquitetural | **Gate: deve ser quebrada em sub-tarefas ou ter justificativa** |
 
-**Princípio test-first:** escreva o `Verificar` antes de escrever o `Implementar`. A pergunta é: "Como saberei que está pronto?" — a resposta define o target; `Implementar` é o caminho mínimo até esse target.
-
-**Contrato racional por tarefa:** se a tarefa for mutável ou tecnicamente relevante, o `PLAN.md` sozinho não basta. O `IMPLEMENTATION-PACK` deve fechar o write-set, os symbols e os checks; o `REFERENCE-ANCHORS` deve materializar evidência externa; o `FIXTURE-PACK` deve reduzir improviso em parsing/integração/transformação.
+**Princípio test-first:** escreva o `Verificar` antes de escrever o `Implementar`. A pergunta é: "Como saberei que está pronto?" — a resposta define o target; `Implementar` é o caminho mínimo até esse target.
+
+**Contrato racional por tarefa:** se a tarefa for mutável ou tecnicamente relevante, o `PLAN.md` sozinho não basta. O `IMPLEMENTATION-PACK` deve fechar o write-set, os symbols e os checks; o `REFERENCE-ANCHORS` deve materializar evidência externa; o `FIXTURE-PACK` deve reduzir improviso em parsing/integração/transformação.
 
 **Projetos sem suíte de testes única (legado):** o bloco **Verificar** pode usar `Comando: —` e **Manual** com Grep, leitura de paths ou checklist — ver exemplos em **`oxe/workflows/references/legacy-brownfield.md`**. Todo critério **A*** da SPEC deve aparecer em **Aceite vinculado** de alguma tarefa ou como gap explícito.
 
@@ -192,70 +192,70 @@ Antes de finalizar a resposta ao utilizador, o agente **deve** percorrer este ga
 7. **Fidelidade de decisões:** se existir `DISCUSS.md` com IDs **D-NN** no escopo resolvido, cada decisão com impacto técnico deve aparecer em **Decisão vinculada:** de alguma tarefa, ou ter nota explícita de gap. Sem cobertura para D-NN técnico = falha do gate.
 8. **Complexidade XL:** toda tarefa com `Complexidade: XL` deve ter sub-tarefas explícitas (ex.: T3.1, T3.2 — como bullets dentro da tarefa) **ou** justificativa na tarefa explicando por que não pode ser quebrada. Tarefa XL sem sub-tarefas e sem justificativa = falha do gate.
 9. **Test-first:** em toda tarefa, `Verificar` deve preceder `Implementar` no texto. Se a ordem estiver invertida, corrigir antes de finalizar.
-10. **Autoavaliação presente:** o `PLAN.md` contém `## Autoavaliação do Plano`, `Melhor plano atual`, `Confiança`, rubrica completa, bloco `<confidence_vector>` coerente e `Condição para replanejar`.
-11. **Calibração de execução:** se `Melhor plano atual: não`, se a autoavaliação estiver estruturalmente incompleta, ou se `Confiança <= limiar configurado`, o plano não pode recomendar execução direta; deve recomendar refino, discuss ou research.
+10. **Autoavaliação presente:** o `PLAN.md` contém `## Autoavaliação do Plano`, `Melhor plano atual`, `Confiança`, rubrica completa, bloco `<confidence_vector>` coerente e `Condição para replanejar`.
+11. **Calibração de execução:** se `Melhor plano atual: não`, se a autoavaliação estiver estruturalmente incompleta, ou se `Confiança <= limiar configurado`, o plano não pode recomendar execução direta; deve recomendar refino, discuss ou research.
 12. **Rastreabilidade de evidência:** cada tarefa deve ter entrada observável de origem na SPEC, no codebase, em DISCUSS, OBS, RESEARCH ou LESSONS; tarefa sem evidência de entrada explícita = falha do gate.
-13. **Mudanças de risco:** tarefas com risco relevante (migração, auth, schema, contrato público, segurança) devem incluir contenção, rollback, fallback ou verificação reforçada.
-14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
-15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
-16. **Implementation contract:** toda tarefa mutável deve aparecer em `IMPLEMENTATION-PACK.json` com `exact_paths`, `symbols`, `contracts`, `write_set: "closed"`, `expected_checks` e `ready: true`. Path com `...`, símbolo indefinido ou contrato ausente = falha do gate.
-17. **Reference anchors:** toda referência `external-ref`, "copiar do predecessor", "usar layout X" ou equivalente deve aparecer em `REFERENCE-ANCHORS.md` com `status: resolved`. Âncora crítica em `missing|stale|conflicting` = falha do gate.
-18. **Fixture coverage:** toda tarefa de parser/layout/integração/transformação/fila/migração/builder deve ter fixture `ready` em `FIXTURE-PACK.json`, salvo `not_applicable` explicitamente justificado. Ausência de fixture em tarefa de risco = falha do gate.
-19. **Confiança > 90 de verdade:** `Confiança > 90%` só é válida se `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` estiverem íntegros e sem `critical_gap` aberto. Caso contrário, reduzir a confiança para `<= 90%` e recomendar refino.
-
-Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
+13. **Mudanças de risco:** tarefas com risco relevante (migração, auth, schema, contrato público, segurança) devem incluir contenção, rollback, fallback ou verificação reforçada.
+14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
+15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
+16. **Implementation contract:** toda tarefa mutável deve aparecer em `IMPLEMENTATION-PACK.json` com `exact_paths`, `symbols`, `contracts`, `write_set: "closed"`, `expected_checks` e `ready: true`. Path com `...`, símbolo indefinido ou contrato ausente = falha do gate.
+17. **Reference anchors:** toda referência `external-ref`, "copiar do predecessor", "usar layout X" ou equivalente deve aparecer em `REFERENCE-ANCHORS.md` com `status: resolved`. Âncora crítica em `missing|stale|conflicting` = falha do gate.
+18. **Fixture coverage:** toda tarefa de parser/layout/integração/transformação/fila/migração/builder deve ter fixture `ready` em `FIXTURE-PACK.json`, salvo `not_applicable` explicitamente justificado. Ausência de fixture em tarefa de risco = falha do gate.
+19. **Confiança > 90 de verdade:** `Confiança > 90%` só é válida se `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` estiverem íntegros e sem `critical_gap` aberto. Caso contrário, reduzir a confiança para `<= 90%` e recomendar refino.
+
+Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
 
 Resumo obrigatório no chat: `Gate do plano: OK` ou `Gate do plano: corrigido (N problemas)`.
 </plan_quality_gate>
 
 <process>
-1. Resolver `active_session` e ler `SPEC.md` do escopo correto (obrigatório). Se faltar, pedir **spec** primeiro.
-1a. Se `PLAN.md` já existir no escopo resolvido:
-   - se o pedido atual só refina tarefas, ondas, dependências, riscos, validação ou sequencing, tratar como **replan implícito**;
-   - se o pedido atual mudar estratégia técnica, pedir ou executar `discuss` antes de seguir;
-   - se o pedido atual mudar escopo, critérios, prioridades ou aceite, pedir ou executar `spec` antes de seguir.
-   Registar explicitamente no chat qual dos três caminhos foi adotado.
-1b. Resolver o context pack `plan` primeiro:
-   - ler `.oxe/context/packs/plan.md|json` (ou `oxe-cc context inspect --workflow plan --json`);
-   - se estiver fresco e coerente, usar o pack como mapa primário;
+1. Resolver `active_session` e ler `SPEC.md` do escopo correto (obrigatório). Se faltar, pedir **spec** primeiro.
+1a. Se `PLAN.md` já existir no escopo resolvido:
+   - se o pedido atual só refina tarefas, ondas, dependências, riscos, validação ou sequencing, tratar como **replan implícito**;
+   - se o pedido atual mudar estratégia técnica, pedir ou executar `discuss` antes de seguir;
+   - se o pedido atual mudar escopo, critérios, prioridades ou aceite, pedir ou executar `spec` antes de seguir.
+   Registar explicitamente no chat qual dos três caminhos foi adotado.
+1b. Resolver o context pack `plan` primeiro:
+   - ler `.oxe/context/packs/plan.md|json` (ou `oxe-cc context inspect --workflow plan --json`);
+   - se estiver fresco e coerente, usar o pack como mapa primário;
    - se estiver stale, incompleto ou ausente, registar `fallback para leitura direta` e seguir com leitura bruta.
-1c. Com pack válido, ler primeiro o resumo do pack e os artefatos de `read_order`; só abrir outros artefatos quando faltarem evidências para fechar tarefas, riscos ou autoavaliação.
+1c. Com pack válido, ler primeiro o resumo do pack e os artefatos de `read_order`; só abrir outros artefatos quando faltarem evidências para fechar tarefas, riscos ou autoavaliação.
 2. Se `.oxe/config.json` tiver `discuss_before_plan: true` e **não** existir `DISCUSS.md` no escopo resolvido com decisões fechadas, pedir **discuss** antes de planejar.
 3. Se existir **`.oxe/NOTES.md`**, consumir ou explicitamente adiar cada bullet relevante (ver **context**).
 4. Ler `.oxe/codebase/*.md` (incl. CONVENTIONS / CONCERNS) e inspecionar pontos de entrada se a spec exigir. Se o pack não bastar, expandir a leitura apenas para os artefatos adicionais necessários e registar essa expansão.
-5. Escrever ou atualizar `PLAN.md` no escopo resolvido usando `oxe/templates/PLAN.template.md` como cabeçalho; **preservar** YAML inicial (`oxe_doc: plan`, `status`, `inputs`) se já existir e **atualizar** `updated:` (ISO); em **--replan** ou **replan implícito**, preencher a seção **Replanejamento** (data, motivo, lições de VERIFY/SUMMARY, tarefas removidas/alteradas).
-5a. Gerar junto os artefatos racionais:
-   - `IMPLEMENTATION-PACK.md` e `IMPLEMENTATION-PACK.json` a partir de `oxe/templates/IMPLEMENTATION-PACK.template.*`
-   - `REFERENCE-ANCHORS.md` a partir de `oxe/templates/REFERENCE-ANCHORS.template.md`
-   - `FIXTURE-PACK.md` e `FIXTURE-PACK.json` a partir de `oxe/templates/FIXTURE-PACK.template.*`
-   Todos no mesmo escopo resolvido da sessão do `PLAN.md`.
+5. Escrever ou atualizar `PLAN.md` no escopo resolvido usando `oxe/templates/PLAN.template.md` como cabeçalho; **preservar** YAML inicial (`oxe_doc: plan`, `status`, `inputs`) se já existir e **atualizar** `updated:` (ISO); em **--replan** ou **replan implícito**, preencher a seção **Replanejamento** (data, motivo, lições de VERIFY/SUMMARY, tarefas removidas/alteradas).
+5a. Gerar junto os artefatos racionais:
+   - `IMPLEMENTATION-PACK.md` e `IMPLEMENTATION-PACK.json` a partir de `oxe/templates/IMPLEMENTATION-PACK.template.*`
+   - `REFERENCE-ANCHORS.md` a partir de `oxe/templates/REFERENCE-ANCHORS.template.md`
+   - `FIXTURE-PACK.md` e `FIXTURE-PACK.json` a partir de `oxe/templates/FIXTURE-PACK.template.*`
+   Todos no mesmo escopo resolvido da sessão do `PLAN.md`.
 6. Definir ondas: onda 1 = tarefas sem dependência entre si; onda seguinte = dependentes; respeitar `plan_max_tasks_per_wave` se configurado.
 6a. **Calibração histórica:** se `.oxe/calibration.json` existir e tiver ≥ 2 registros, ler as últimas 3 entradas antes de preencher a autoavaliação. Para cada dimensão com `calibration_error > 0.25` em 2+ ciclos consecutivos, adicionar `[⚠ historicamente subestimado]` na nota da dimensão e reduzir o score em 0.10 ou justificar explicitamente por que o ciclo atual é diferente.
-7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos. As lacunas, conflitos e freshness do pack devem aparecer nessa autoavaliação quando forem relevantes. **Incluir o bloco `<confidence_vector>`** com as 6 dimensões usando o template em `oxe/templates/PLAN.template.md`.
-7b. Antes de declarar `Confiança > 90%`, validar os artefatos racionais:
-   - `IMPLEMENTATION-PACK` sem write-set aberto e sem paths `...`;
-   - `REFERENCE-ANCHORS` com âncoras críticas resolvidas;
-   - `FIXTURE-PACK` cobrindo tarefas de risco.
-   Se algo falhar, a confiança deve cair para `<= 90%` e o próximo passo não pode ser `execute`.
+7. Preencher `## Autoavaliação do Plano` com a rubrica fixa. A confiança é a soma ponderada das seis dimensões; não inventar percentagem sem justificar os pontos. As lacunas, conflitos e freshness do pack devem aparecer nessa autoavaliação quando forem relevantes. **Incluir o bloco `<confidence_vector>`** com as 6 dimensões usando o template em `oxe/templates/PLAN.template.md`.
+7b. Antes de declarar `Confiança > 90%`, validar os artefatos racionais:
+   - `IMPLEMENTATION-PACK` sem write-set aberto e sem paths `...`;
+   - `REFERENCE-ANCHORS` com âncoras críticas resolvidas;
+   - `FIXTURE-PACK` cobrindo tarefas de risco.
+   Se algo falhar, a confiança deve cair para `<= 90%` e o próximo passo não pode ser `execute`.
 7a. **Hipóteses Críticas:** ao criar tarefas `L` ou `XL` ou qualquer tarefa que dependa de lib externa, API de terceiros ou serviço de infra não testado ainda — adicionar seção `## Hipóteses Críticas` com pelo menos uma `<hypothesis>` por dependência crítica. Usar `oxe/templates/HYPOTHESES.template.md` como referência. Omitir a seção se todas as tarefas forem `S`/`M` e sem dependências externas não verificadas.
 8. Aplicar integralmente o bloco **`<plan_quality_gate>`** acima ao `PLAN.md` em disco; corrigir o ficheiro até passar ou documentar gaps explícitos.
-9. Atualizar `.oxe/STATE.md` global: fase `plan_ready`, próximo passo `oxe:execute` apenas se `Melhor plano atual: sim`, a autoavaliação estiver estruturalmente íntegra e a confiança superar o limiar executável; caso contrário, próximo passo deve reduzir incerteza (`oxe:discuss`, `oxe:research` ou replanejamento).
+9. Atualizar `.oxe/STATE.md` global: fase `plan_ready`, próximo passo `oxe:execute` apenas se `Melhor plano atual: sim`, a autoavaliação estiver estruturalmente íntegra e a confiança superar o limiar executável; caso contrário, próximo passo deve reduzir incerteza (`oxe:discuss`, `oxe:research` ou replanejamento).
 10. **Sugestão de agentes (inteligente):** após o gate passar, verificar se o plano tem 3+ domínios distintos (ex.: backend + frontend + DB, ou auth + notificações + UI). Se sim, sugerir proativamente: "Este plano tem N domínios distintos. Quer gerar um blueprint de agentes com `/oxe-plan --agents`?" — não executar automaticamente, apenas oferecer. Se o usuário incluiu `--agents` no input original, executar imediatamente a lógica de `oxe/workflows/plan-agent.md`.
 11. Listar no chat: resultado do gate (OK ou corrigido), ondas, contagem de tarefas, comando de teste guarda-chuva se houver, melhor-plano-atual e confiança.
-12. No resumo em chat, deixar explícitos:
-   - objetivo e escopo do plano;
-   - principais riscos e contenções;
-   - assumptions relevantes;
-   - se o plano foi produzido com pack fresco ou com fallback explícito;
-   - se a chamada foi tratada como plano novo, replan implícito, ou se foi devolvida para `spec`/`discuss`;
-   - comando único recomendado para o próximo passo.
+12. No resumo em chat, deixar explícitos:
+   - objetivo e escopo do plano;
+   - principais riscos e contenções;
+   - assumptions relevantes;
+   - se o plano foi produzido com pack fresco ou com fallback explícito;
+   - se a chamada foi tratada como plano novo, replan implícito, ou se foi devolvida para `spec`/`discuss`;
+   - comando único recomendado para o próximo passo.
 </process>
 
 <success_criteria>
 - [ ] Cada tarefa tem seção **Verificar** com comando ou checklist explícito.
 - [ ] Dependências entre tarefas estão explícitas.
-- [ ] Cada critério da SPEC (IDs **A***) está mapeado em **Aceite vinculado** de alguma tarefa ou explicitamente marcado como gap no plano.
-- [ ] Cada R-ID `v1`/`v2` do SPEC tem ao menos um A* coberto por alguma tarefa, ou gap documentado (gate 14).
-- [ ] `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` existem no escopo resolvido e não ficaram em branco.
-- [ ] Não há `critical_gap` aberto nos artefatos racionais quando a confiança declarada é `> 90%`.
-</success_criteria>
+- [ ] Cada critério da SPEC (IDs **A***) está mapeado em **Aceite vinculado** de alguma tarefa ou explicitamente marcado como gap no plano.
+- [ ] Cada R-ID `v1`/`v2` do SPEC tem ao menos um A* coberto por alguma tarefa, ou gap documentado (gate 14).
+- [ ] `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` existem no escopo resolvido e não ficaram em branco.
+- [ ] Não há `critical_gap` aberto nos artefatos racionais quando a confiança declarada é `> 90%`.
+</success_criteria>

package/oxe/workflows/references/adaptive-discovery.md

@@ -1,27 +1,27 @@
-# OXE — Descoberta Adaptativa
-
-<objective>
-Reduzir ambiguidade antes da escrita de `SPEC.md` e melhorar a qualidade do plano. Esta referência orienta `spec` e `ask`.
-</objective>
-
-## Regras
-
-- Classificar a demanda o mais cedo possível: `feature`, `bugfix`, `refactor`, `research`, `ops`, `mixed`.
-- Modular as perguntas pelo tipo de demanda e pelo risco.
-- Limitar rodadas; consolidar entendimento antes de escrever artefatos.
-- Registrar incertezas estruturadas, não apenas em texto solto.
-
-## Blocos mínimos
-
-- **Objetivo final**
-- **Impacto / público**
-- **Restrições técnicas**
-- **Riscos e casos extremos**
-- **Evidência faltante**
-
-## Saída esperada
-
-- resumo de entendimento;
-- demanda classificada;
-- incertezas remanescentes;
-- recomendação de próximo passo compatível com o risco.
+# OXE — Descoberta Adaptativa
+
+<objective>
+Reduzir ambiguidade antes da escrita de `SPEC.md` e melhorar a qualidade do plano. Esta referência orienta `spec` e `ask`.
+</objective>
+
+## Regras
+
+- Classificar a demanda o mais cedo possível: `feature`, `bugfix`, `refactor`, `research`, `ops`, `mixed`.
+- Modular as perguntas pelo tipo de demanda e pelo risco.
+- Limitar rodadas; consolidar entendimento antes de escrever artefatos.
+- Registrar incertezas estruturadas, não apenas em texto solto.
+
+## Blocos mínimos
+
+- **Objetivo final**
+- **Impacto / público**
+- **Restrições técnicas**
+- **Riscos e casos extremos**
+- **Evidência faltante**
+
+## Saída esperada
+
+- resumo de entendimento;
+- demanda classificada;
+- incertezas remanescentes;
+- recomendação de próximo passo compatível com o risco.

package/oxe/workflows/references/flow-robustness-contract.md

@@ -1,80 +1,80 @@
-# OXE — Contrato de Robustez do Fluxo
-
-<objective>
-Definir um contrato canónico para reduzir alucinação estrutural no OXE. Este ficheiro é consumido por `spec`, `plan`, `quick`, `execute`, `verify`, `next`, `status` e `doctor`.
-</objective>
-
-## Ordem determinística do fluxo
-
-Todo passo OXE deve seguir esta ordem, sem saltar etapas:
-
-1. Ler os artefatos obrigatórios do estado atual.
-2. Resolver `active_session` e os paths do escopo.
-3. Validar pré-condições mínimas antes de prosseguir.
-4. Produzir a saída principal do passo.
-5. Executar autoavaliação ou gate de qualidade do próprio passo.
-6. Registrar um próximo passo único.
-
-## Invariantes mínimos
-
-Todo workflow deve declarar com clareza:
-
-- quais artefatos lê;
-- quais artefatos escreve;
-- quais invariantes valida antes de operar;
-- qual fallback legado é permitido quando não há sessão ativa.
-
-## Proibição de saltos sem evidência
-
-- `plan` não deve avançar sem `SPEC.md` válido.
-- `execute` não deve avançar sem `PLAN.md` ou `QUICK.md` válido no escopo resolvido.
-- `verify` não deve avançar sem evidência mínima de execução ou de artefatos resultantes.
-- `next` não deve sugerir um passo que viole os gates acima.
-
-## Contrato de autoavaliação do plano
-
-Todo `PLAN.md` deve conter uma seção visível `## Autoavaliação do Plano` com:
-
-- `Melhor plano atual:` `sim` ou `não`
-- `Confiança:` `0–100%`
-- `Base da confiança:` rubrica fixa, não narrativa livre
-- `Principais incertezas:` lista curta
-- `Alternativas descartadas:` resumo curto
-- `Condição para replanejar:` critério objetivo
-
-### Rubrica obrigatória
-
-| Dimensão | Peso |
-|----------|------|
-| Completude dos requisitos | 25 |
-| Dependências conhecidas | 15 |
-| Risco técnico | 20 |
-| Impacto no código existente | 15 |
-| Clareza da validação / testes | 15 |
-| Lacunas externas / decisões pendentes | 10 |
-
-**Total:** 100 pontos
-
-### Faixas semânticas
-
-- `91–100%` → pronto para executar
-- `80–90%` → plano racional, mas ainda não executável
-- `50–79%` → precisa refino antes de execução
-- `<50%` → não executar
-
-## Calibração pós-execução
-
-`verify` deve comparar o resultado real com a autoavaliação do plano:
-
-- confiança alta + falha precoce = erro de calibração do plano;
-- confiança baixa + falha em risco previsto = autoavaliação aderente;
-- confiança alta + sucesso consistente = plano calibrado;
-- confiança baixa + sucesso amplo = plano conservador demais.
-
-## Uso por `status` e `doctor`
-
-`status` e `doctor` devem refletir a saúde lógica do fluxo com categorias determinísticas:
-
-- `healthy` — sem bloqueio lógico conhecido;
-- `warning` — fluxo operável, mas com gaps ou drift relevante;
-- `broken` — artefato crítico ausente, incoerência severa ou gate indispensável falhado.
+# OXE — Contrato de Robustez do Fluxo
+
+<objective>
+Definir um contrato canónico para reduzir alucinação estrutural no OXE. Este ficheiro é consumido por `spec`, `plan`, `quick`, `execute`, `verify`, `next`, `status` e `doctor`.
+</objective>
+
+## Ordem determinística do fluxo
+
+Todo passo OXE deve seguir esta ordem, sem saltar etapas:
+
+1. Ler os artefatos obrigatórios do estado atual.
+2. Resolver `active_session` e os paths do escopo.
+3. Validar pré-condições mínimas antes de prosseguir.
+4. Produzir a saída principal do passo.
+5. Executar autoavaliação ou gate de qualidade do próprio passo.
+6. Registrar um próximo passo único.
+
+## Invariantes mínimos
+
+Todo workflow deve declarar com clareza:
+
+- quais artefatos lê;
+- quais artefatos escreve;
+- quais invariantes valida antes de operar;
+- qual fallback legado é permitido quando não há sessão ativa.
+
+## Proibição de saltos sem evidência
+
+- `plan` não deve avançar sem `SPEC.md` válido.
+- `execute` não deve avançar sem `PLAN.md` ou `QUICK.md` válido no escopo resolvido.
+- `verify` não deve avançar sem evidência mínima de execução ou de artefatos resultantes.
+- `next` não deve sugerir um passo que viole os gates acima.
+
+## Contrato de autoavaliação do plano
+
+Todo `PLAN.md` deve conter uma seção visível `## Autoavaliação do Plano` com:
+
+- `Melhor plano atual:` `sim` ou `não`
+- `Confiança:` `0–100%`
+- `Base da confiança:` rubrica fixa, não narrativa livre
+- `Principais incertezas:` lista curta
+- `Alternativas descartadas:` resumo curto
+- `Condição para replanejar:` critério objetivo
+
+### Rubrica obrigatória
+
+| Dimensão | Peso |
+|----------|------|
+| Completude dos requisitos | 25 |
+| Dependências conhecidas | 15 |
+| Risco técnico | 20 |
+| Impacto no código existente | 15 |
+| Clareza da validação / testes | 15 |
+| Lacunas externas / decisões pendentes | 10 |
+
+**Total:** 100 pontos
+
+### Faixas semânticas
+
+- `91–100%` → pronto para executar
+- `80–90%` → plano racional, mas ainda não executável
+- `50–79%` → precisa refino antes de execução
+- `<50%` → não executar
+
+## Calibração pós-execução
+
+`verify` deve comparar o resultado real com a autoavaliação do plano:
+
+- confiança alta + falha precoce = erro de calibração do plano;
+- confiança baixa + falha em risco previsto = autoavaliação aderente;
+- confiança alta + sucesso consistente = plano calibrado;
+- confiança baixa + sucesso amplo = plano conservador demais.
+
+## Uso por `status` e `doctor`
+
+`status` e `doctor` devem refletir a saúde lógica do fluxo com categorias determinísticas:
+
+- `healthy` — sem bloqueio lógico conhecido;
+- `warning` — fluxo operável, mas com gaps ou drift relevante;
+- `broken` — artefato crítico ausente, incoerência severa ou gate indispensável falhado.