oxe-cc 0.6.5 → 0.7.0

package/oxe/workflows/retro.md

@@ -34,6 +34,27 @@ Pode ser chamado:
 **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)
+
+**Campos obrigatórios de cada lição:**
+```
+- **Lição C-NN-L1:** <instrução prescritiva — o que fazer diferente>
+- **Raiz:** <por que aconteceu>
+- **Tipo:** spec | plan | execute | verify | process | agents
+- **Aplicar em:** /oxe-spec | /oxe-plan | /oxe-execute | etc.
+- **Status:** ativo | resolvido
+- **Frequência:** N  ← quantos ciclos registraram ou confirmaram esta lição
+- **Impacto:** alto | médio | baixo  ← criticidade se repetida
+- **Última aplicação:** YYYY-MM-DD
+```
+
+**Regras de scoring:**
+- **Frequência:** começa em `1`. A cada novo ciclo em que a mesma lição se repete (mesma raiz + tipo), incrementar `Frequência: N+1` e atualizar `Última aplicação` **em vez de criar entrada duplicada**.
+- **Impacto alto:** causou retrabalho de ciclo inteiro, falha no verify, ou seria crítico se repetido — tipo auth, schema, contrato público.
+- **Impacto médio:** causou atraso ou retrabalho localizado (1–3 tarefas).
+- **Impacto baixo:** menor, já tem mitigação óbvia, ou restrito a contexto muito específico.
+
+**Como os consumidores usam o scoring (instrução para spec e plan):**
+Ao ler `LESSONS.md`, priorizar entradas com **`Frequência >= 2`** ou **`Impacto: alto`** — aplicar como restrições explícitas. Lições com `Frequência: 1` e `Impacto: baixo` são contexto secundário.
 </taxonomy>
 
 <process>
@@ -43,12 +64,14 @@ Pode ser chamado:
 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**
+   - Formato: **Lição** + **Raiz** + **Tipo** + **Aplicar em** + **Frequência** + **Impacto** (ver taxonomia)
+   - Avaliar impacto: `alto` se causou retrabalho de ciclo/falha crítica; `médio` se localizado; `baixo` se menor
 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.
+   - **Antes de adicionar:** verificar se alguma lição de ciclo anterior tem a mesma raiz e tipo. Se sim, **incrementar `Frequência`** e atualizar `Última aplicação: YYYY-MM-DD` nessa entrada existente — **não duplicar**.
+   - Apenas entradas genuinamente novas recebem uma nova linha na tabela de índice (mais recente primeiro).
+   - Adicionar seção `### C-NN` com as lições novas do ciclo (ou referência às entradas incrementadas).
+   - **Nunca apagar** entradas anteriores — só mudar `Status: resolvido` se a lição foi definitivamente 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>
@@ -57,6 +80,8 @@ Pode ser chamado:
 - [ ] `.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.
+- [ ] Cada lição tem campos `Frequência`, `Impacto` e `Última aplicação` preenchidos.
+- [ ] Lições com raiz e tipo iguais a entradas anteriores têm `Frequência` incrementada, não duplicadas.
 - [ ] `STATE.md` tem `last_retro` atualizado.
-- [ ] Entradas anteriores preservadas; apenas `Status` pode mudar.
+- [ ] Entradas anteriores preservadas; apenas `Status` pode mudar para `resolvido`.
 </success_criteria>

package/oxe/workflows/scan.md

@@ -35,6 +35,7 @@ Flag `--refresh`: forçar modo refresh.
 <process>
 1. Garantir pastas `.oxe/` e `.oxe/codebase/`.
 2. Inventariar o repo (Glob/Grep): linguagens, manifests (`package.json`, `pom.xml`, `go.mod`, etc.), pastas principais — aplicando foco/ignore da config se houver.
+2d. **Detecção de Azure:** se o inventário revelar uso de Azure — pacotes `@azure/*` em `package.json`, `com.microsoft.azure.*` em `pom.xml`, `github.com/Azure/...` em `go.mod`, imports `azure.*` em `.py` / `.cs` / `.java`, ou variáveis de ambiente com prefixo `AZURE_` — registrar em **INTEGRATIONS.md** com: serviços detectados, versão do SDK quando disponível, variáveis de ambiente usadas (sem valores) e referência ao provider nativo `oxe-cc azure`. Se `.oxe/cloud/azure/INVENTORY.md` existir, mencionar o inventário materializado em INTEGRATIONS.md. **Esta detecção é apenas informativa** — registra a presença de SDKs Azure em INTEGRATIONS.md, mas não altera o fluxo canônico OXE nem aciona steps Azure em projetos que não dependem do provider. O provider `oxe-cc azure` é opt-in: só deve ser usado quando o usuário informar explicitamente na SPEC ou ativar via `oxe-cc azure auth login`.
 2b. **Legado / brownfield:** se o inventário revelar sinais de mainframe ou desktop legado (ex.: `*.cbl`, `*.jcl`, pastas `jcl/`, `cpy/` ou `copy/`, `*.cpy`, `*.frm` / `*.vbp`, volume de `*.sql` com procedures), aplicar **`oxe/workflows/references/legacy-brownfield.md`** ao preencher STACK, STRUCTURE, INTEGRATIONS, TESTING e CONCERNS — **sem** assumir Node/Java nem omitir TESTING.md quando não houver CI.
 2c. **`docs/` / `src/docs/` com documentação humana:** se existir pasta de documentação com índice (`docs/INDICE-GERAL.md`, `docs/README.md`, `**/00-*INDICE*.md`, ou enciclopédia por camadas), em **OVERVIEW** e **STRUCTURE** resumir o **papel das subpastas** (ex.: `tecnico/`, `negocio/`, `glossary/`, comparativos, baixa plataforma) e linkar o ficheiro índice em backticks. Em **INTEGRATIONS** (e se útil em OVERVIEW), quando o repo for híbrido host + distribuído + externos, incluir bullets **Alta plataforma**, **Baixa plataforma**, **Externo** conforme `legacy-brownfield.md`. Sugerir template opcional `oxe/templates/DOCS_BROWNFIELD_LAYOUT.md` ao utilizador se a árvore `docs/` estiver em crescimento.
 3. Produzir **sete** arquivos em `.oxe/codebase/` (paralelize subagentes quando disponível):

package/oxe/workflows/spec.md

@@ -13,20 +13,27 @@ Para trabalho **muito pequeno** que não justifica spec completa: redirecionar p
 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.
 </objective>
 
-<context>
-**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
-
-**Resolução de sessão:** antes de ler ou escrever artefatos desta trilha, resolver `active_session` em `.oxe/STATE.md` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa:
-- `SPEC.md`, `ROADMAP.md` e `DISCUSS.md` vivem em `.oxe/<active_session>/spec/`
-- `OBSERVATIONS.md`, `RESEARCH.md` e `research/` seguem o escopo da sessão
-- `LESSONS.md` continua global em `.oxe/global/LESSONS.md`
-- sem sessão ativa, manter o modo legado na raiz `.oxe/`
-
-Ler no início:
-- `.oxe/STATE.md` — fase atual, decisões, workstream ativo
-- `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
-- **OBS do escopo ativo** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
-- **`.oxe/global/LESSONS.md`** — se existir, ler entradas com `Aplicar em: spec` e status `ativo`. Usar como restrições explícitas ou alertas durante a Fase 1 (perguntas) e Fase 3 (requisitos). Exemplo: se uma lição diz "perguntar explicitamente sobre integração com X", adicionar essa pergunta no Bloco B da Fase 1.
+<context>
+**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
+
+**Contrato de robustez:** seguir `oxe/workflows/references/flow-robustness-contract.md`. Antes de escrever, resolver artefatos obrigatórios, validar pré-condições e só então produzir a spec. O output desta fase deve deixar evidência estruturada suficiente para o `plan` decidir se o plano é realmente o melhor disponível.
+
+**Discovery adaptativo:** antes da primeira pergunta, aplicar `oxe/workflows/references/adaptive-discovery.md`. Classificar a demanda, modular os blocos de perguntas conforme o domínio, limitar rodadas e consolidar incertezas estruturadas que depois alimentarão a confiança do plano.
+
+**Resolução de sessão:** antes de ler ou escrever artefatos desta trilha, resolver `active_session` em `.oxe/STATE.md` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa:
+- `SPEC.md`, `ROADMAP.md` e `DISCUSS.md` vivem em `.oxe/<active_session>/spec/`
+- `OBSERVATIONS.md`, `RESEARCH.md` e `research/` seguem o escopo da sessão
+- `LESSONS.md` continua global em `.oxe/global/LESSONS.md`
+- sem sessão ativa, manter o modo legado na raiz `.oxe/`
+
+Ler no início:
+- `.oxe/STATE.md` — fase atual, decisões, workstream ativo
+- `EXECUTION-RUNTIME.md`, `CHECKPOINTS.md` e `memory/` do escopo ativo se existirem — usar como contexto auxiliar, nunca como substituto da SPEC
+- `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
+- **OBS do escopo ativo** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
+- **`.oxe/global/LESSONS.md`** — se existir, ler entradas com `Aplicar em: spec` e status `ativo`. **Priorizar entradas com `Frequência >= 2` ou `Impacto: alto`** — aplicar como restrições explícitas. Entradas com `Frequência: 1` e `Impacto: baixo` são contexto secundário. Usar durante a Fase 1 (perguntas) e Fase 3 (requisitos). Exemplo: se uma lição diz "perguntar explicitamente sobre integração com X", adicionar essa pergunta no Bloco B da Fase 1.
+- `.oxe/CAPABILITIES.md` e `.oxe/INVESTIGATIONS.md` — usar para sugerir capacidades e pesquisas já existentes antes de abrir novas lacunas
+- Se o problema tocar Azure, ler `.oxe/cloud/azure/profile.json`, `auth-status.json` e `INVENTORY.md` antes de fechar requisitos; se o inventário estiver ausente ou stale, exigir discovery via `oxe-cc azure sync` antes de consolidar a spec
 
 **Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — épicos por trilha, critérios A* verificáveis por Grep/leitura/checklist.
 
@@ -38,6 +45,8 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 
 **Objetivo:** entender completamente a ideia antes de qualquer escrita de artefato.
 
+**Classificar a demanda no início:** antes do primeiro bloco, rotular a trilha com um tipo dominante (`feature`, `bugfix`, `refactor`, `investigação`, `migração`, `integração`, `infra`, `dados`, `ui`, `segurança`). Registar esse tipo na seção de contexto da SPEC.
+
 **Regra de ouro:** nunca uma pergunta por vez — sempre um **bloco coeso** de 3-5 perguntas por rodada. Máximo **3 rodadas**; sinalize quando achar que tem entendimento completo e peça confirmação antes de avançar.
 
 **Blocos de perguntas (adaptar ao contexto):**
@@ -64,6 +73,12 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - Após rodada 3: avançar para Fase 2 mesmo com suposições explícitas
 
 **Ao final:** "Acho que entendi completamente. Confirma antes de avançarmos para pesquisa/requisitos? [resumo em 3-5 bullets]"
+
+**Registar incertezas estruturadas:** ao fim de cada rodada, consolidar:
+- o que já está estável;
+- o que segue ambíguo;
+- quais evidências faltam;
+- quais riscos podem reduzir a confiança do plano.
 </fase_1_perguntas>
 
 <fase_2_pesquisa>
@@ -71,12 +86,14 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 
 **Objetivo:** investigar domínios incertos antes de escrever requisitos.
 
-**Proposta ao usuário:** com base na Fase 1, listar 2-4 áreas de investigação sugeridas e perguntar quais investigar. Exemplos:
-- "Há 3 áreas com incerteza técnica: autenticação JWT, integração com Stripe, e deploy em edge. Quer investigar alguma antes de avançar para requisitos?"
+**Proposta ao usuário:** com base na Fase 1, listar 2-4 áreas de investigação sugeridas e perguntar quais investigar. Exemplos:
+- "Há 3 áreas com incerteza técnica: autenticação JWT, integração com Stripe, e deploy em edge. Quer investigar alguma antes de avançar para requisitos?"
+- "A trilha depende de Azure e o inventário está incompleto. Quer sincronizar recursos reais antes de congelar os requisitos?"
 
 **Se aprovado:**
-- Criar notas de pesquisa datadas em `research/YYYY-MM-DD-<slug>.md` no escopo ativo (usar fluxo de `research.md`)
-- Atualizar `RESEARCH.md` no mesmo escopo
+- Criar notas de pesquisa datadas em `research/YYYY-MM-DD-<slug>.md` no escopo ativo (usar fluxo de `research.md`)
+- Atualizar `RESEARCH.md` no mesmo escopo
+- Atualizar `INVESTIGATIONS.md` com objetivo, fontes, profundidade, resultado e impacto na trilha
 - Consolidar descobertas relevantes antes de avançar para Fase 3
 
 **Se pulado:** registrar em `SPEC.md` as áreas de incerteza como suposições explícitas.
@@ -111,7 +128,7 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 <fase_4_roteiro>
 ## Fase 4 — Roteiro
 
-**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `ROADMAP.md` no escopo ativo da sessão.
+**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `ROADMAP.md` no escopo ativo da sessão.
 
 **Lógica de agrupamento:**
 - Agrupar requisitos v1 em fases por **dependência técnica** e **valor entregável**
@@ -119,14 +136,14 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - Fase 1 = o que `/oxe-plan` implementará no próximo ciclo
 - Fases 2+ = ciclos futuros de spec→plan→execute→verify
 
-**Escrever `ROADMAP.md`** usando `oxe/templates/ROADMAP.template.md` no escopo ativo:
+**Escrever `ROADMAP.md`** usando `oxe/templates/ROADMAP.template.md` no escopo ativo:
 
 ```markdown
 ---
 oxe_doc: roadmap
 status: draft
 updated: <data>
-spec_ref: SPEC.md
+spec_ref: SPEC.md
 ---
 
 ## Fase 1 — [Nome]
@@ -166,6 +183,12 @@ Percorrer esta lista de verificação:
 - **3+ problemas** → apresentar lista ao usuário com a Fase 3 revisada (não reiniciar do zero).
 
 O resultado desta reflexão é **invisível ao usuário** — é trabalho interno do agente. Somente os ajustes feitos aparecem na spec final.
+
+**Saída estruturada obrigatória para o plan:** após esta reflexão, a SPEC final deve deixar explícitos:
+- requisitos estáveis;
+- ambiguidades restantes;
+- conflitos resolvidos ou ainda abertos;
+- evidências faltantes que podem reduzir a confiança do plano.
 </auto_reflexao>
 
 <fase_5_aprovacao>
@@ -198,24 +221,26 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 </fase_5_aprovacao>
 
 <process>
-1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
-2. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
-3. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
-4. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
-5. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
-6. Escrever **`SPEC.md`** usando `oxe/templates/SPEC.template.md` no escopo ativo:
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
+2. Aplicar `adaptive-discovery.md`: classificar a demanda, verificar se há capabilities úteis e se investigações anteriores reduzem incerteza.
+3. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
+4. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
+5. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
+6. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
+7. Escrever **`SPEC.md`** usando `oxe/templates/SPEC.template.md` no escopo ativo:
    - Frontmatter YAML (`oxe_doc: spec`, `status`, `updated`, `inputs`)
    - Objetivo, Escopo (dentro/fora), Critérios de aceite (tabela A*), Suposições e riscos, Referências
+   - Preencher explicitamente `Tipo de demanda` e `Incertezas estruturadas`
    - Preservar chaves existentes se SPEC.md já existir; atualizar `updated:`
-6b. **Auto-reflexão:** executar integralmente o bloco `<auto_reflexao>` antes de avançar. Corrigir a spec conforme necessário. Não apresentar a lista de verificação ao usuário — apenas a spec corrigida.
-7. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
-8. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
-9. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
+7b. **Auto-reflexão:** executar integralmente o bloco `<auto_reflexao>` antes de avançar. Corrigir a spec conforme necessário. Não apresentar a lista de verificação ao usuário — apenas a spec corrigida.
+8. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
+9. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
+10. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
 </process>
 
 <success_criteria>
-- [ ] `SPEC.md` existe no escopo correto (`spec/` da sessão ou `.oxe/` legado) com critérios A* e coluna Como verificar; `STATE.md` global atualizado.
-- [ ] `ROADMAP.md` existe no mesmo escopo com fases mapeadas a R-IDs e A*, status `approved` (ou `draft` se usuário não confirmou).
+- [ ] `SPEC.md` existe no escopo correto (`spec/` da sessão ou `.oxe/` legado) com critérios A* e coluna Como verificar; `STATE.md` global atualizado.
+- [ ] `ROADMAP.md` existe no mesmo escopo com fases mapeadas a R-IDs e A*, status `approved` (ou `draft` se usuário não confirmou).
 - [ ] Tabela de requisitos R-ID foi apresentada e validada (v1/v2/fora) antes do roteiro.
 - [ ] Usuário foi consultado no gate da Fase 5 e escolheu o próximo passo.
 - [ ] OBS pendentes com impacto `spec` foram incorporadas e marcadas `incorporada`.

package/oxe/workflows/verify.md

@@ -13,15 +13,19 @@ 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.
 </objective>
 
-<context>
-- 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.
-- Preferir rodar comandos reais no terminal quando o ambiente permitir; se o sandbox bloquear, marcar como "não executado aqui" e deixar o comando para o usuário.
+<context>
+- 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.
+- Seguir `oxe/workflows/references/flow-robustness-contract.md`. O verify não valida só se passou; valida também se o plano estava bem calibrado para começar.
+- Ler `EXECUTION-RUNTIME.md` e `CHECKPOINTS.md` do escopo resolvido quando existirem. Eles são evidência tática para saber o que realmente foi executado, bloqueado, aprovado ou desviado.
+- Se a trilha tocar Azure, ler `.oxe/cloud/azure/INVENTORY.md`, `SERVICEBUS.md`, `EVENTGRID.md`, `SQL.md` e `operations/*.md|json` para confirmar recursos reais, checkpoints e mutações aplicadas.
+- **Observações CI como evidência:** se `OBSERVATIONS.md` do escopo resolvido tiver obs do tipo `ci_failure` com `CI-evidência` preenchida, usar como evidência adicional para critérios A* de qualidade (ex.: cobertura, build verde). Se obs tiver `ci_run_url`, referenciar na coluna **Evidência** da tabela de critérios. Se obs estiver `pendente` e critério A* de qualidade existir, marcar o critério como `evidence_pending_ci` — não como passou — até o CI ser resolvido.
+- Preferir rodar comandos reais no terminal quando o ambiente permitir; se o sandbox bloquear, marcar como "não executado aqui" e deixar o comando para o usuário.
 - Não destruir `PLAN.md`; registrar achados em `VERIFY.md`.
 - Ler **`.oxe/config.json`** se existir: `after_verify_draft_commit`, `after_verify_suggest_pr`, e `verification_depth` (`"standard"` por padrão; `"thorough"` ativa camadas 3–4 completas; `"quick"` pula camadas 3–4 e UAT).
 - Os critérios na SPEC devem estar na tabela **Critérios de aceite** com colunas **ID** / **Critério** / **Como verificar**; o verify deve **cruzar cada ID** com evidência (arquivo, comando, trecho).
 - **Legado:** quando **Comando** for `—` ou inexistente, evidência válida inclui **Read/Grep**, existência de ficheiros referenciados e checklist manual — não marcar critério como passou sem evidência; se o ambiente host/desktop não estiver disponível, registar **não executado aqui** e próximo passo. Ver **`oxe/workflows/references/legacy-brownfield.md`**.
 - **Debug:** investigação técnica de falhas **durante** a implementação segue **`oxe/workflows/debug.md`** (`/oxe-debug`). Resolver um bug com debug **não** dispensa este passo — após correções, **ainda** é necessário **`verify`** para fechar a trilha face à SPEC/PLAN.
-- **UI:** se existirem `UI-SPEC.md` / `UI-REVIEW.md` no escopo resolvido, incorporar na evidência quando os critérios **A*** ou tarefas **Tn** tocarem interface.
+- **UI:** se existirem `UI-SPEC.md` / `UI-REVIEW.md` no escopo resolvido, incorporar na evidência quando os critérios **A*** ou tarefas **Tn** tocarem interface.
 - **Camada 5 — Validate-gaps (automático quando `verification_depth: "thorough"`):** após as 4 camadas, se `verification_depth: "thorough"` em `.oxe/config.json`, executar automaticamente a lógica de `oxe/workflows/validate-gaps.md` e produzir `.oxe/VALIDATION-GAPS.md` como parte deste verify. Não requer comando separado.
 - **Camada 6 — Security (automático quando `security_in_verify: true`):** se `security_in_verify: true` em `.oxe/config.json`, executar automaticamente a lógica de `oxe/workflows/security.md` e produzir `.oxe/SECURITY.md` como parte deste verify. Não requer comando separado.
 - **Rotina compact/checkpoint (opcional):** se esta entrega alterou **estrutura**, **stack** ou **pastas** de forma relevante, `/oxe-scan` em modo refresh alinha `.oxe/codebase/` ao repo. Após **verify** com sucesso, `/oxe-project checkpoint` com slug curto pode marcar estado estável.
@@ -33,8 +37,9 @@ Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela nas camadas 1–2;
 Verificar que o PLAN.md está apto para verificação:
 1. Toda tarefa `### Tn` tem bloco **Verificar** com pelo menos Comando ou Manual.
 2. Todo **Aceite vinculado** referencia IDs que existem na tabela de SPEC.md (`A1`, `A2`, …).
-3. Se houver `DISCUSS.md` no escopo resolvido, toda decisão técnica com ID **D-NN** aparece em **Decisão vinculada:** de alguma tarefa (ou nota explícita de gap no PLAN).
+3. Se houver `DISCUSS.md` no escopo resolvido, toda decisão técnica com ID **D-NN** aparece em **Decisão vinculada:** de alguma tarefa (ou nota explícita de gap no PLAN).
 4. Não há dependências `Tk` inválidas (ID inexistente no PLAN).
+5. `PLAN.md` contém a seção **Autoavaliação do Plano** com `Melhor plano atual`, `Confiança` e rubrica preenchida.
 
 Se auditoria falhar: registrar na seção **Auditoria de pré-execução** do VERIFY.md os itens com problema e **pausar** — pedir correção do PLAN antes de continuar. Se o usuário forçar continuar com `--skip-audit`, documentar e prosseguir com aviso.
 </camada_1_pre_exec_audit>
@@ -46,7 +51,7 @@ Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconju
 </camada_2_tarefas_e_criterios>
 
 <camada_3_fidelidade_decisoes>
-**Camada 3 — Fidelidade de decisões** (ativa se existir `DISCUSS.md` no escopo resolvido com IDs D-NN)
+**Camada 3 — Fidelidade de decisões** (ativa se existir `DISCUSS.md` no escopo resolvido com IDs D-NN)
 
 Para cada decisão na tabela de DISCUSS.md:
 1. Localizar a(s) tarefa(s) que referenciam esse ID em **Decisão vinculada:**.
@@ -74,22 +79,47 @@ Para cada critério da SPEC que exige validação manual:
 O preenchimento da checklist é responsabilidade do **usuário** (não do agente de IA).
 </camada_4_uat>
 
+<calibracao_do_plano>
+**Calibração do plano** (obrigatória quando existir `PLAN.md`)
+
+Ler a `## Autoavaliação do Plano` e comparar com o resultado real:
+1. Se `Confiança >= 85%` e houver falha precoce em critérios centrais ou tarefas iniciais, marcar **erro de calibração do plano**.
+2. Se `Confiança < 70%` e as falhas ocorrerem nas incertezas previstas, marcar **autoavaliação aderente**.
+3. Se `Confiança >= 70%` e os critérios/tarefas passarem de forma consistente, marcar **plano calibrado**.
+4. Se `Confiança < 70%` e o ciclo passar amplamente, marcar **plano conservador demais**.
+
+Registrar em `VERIFY.md`: `Resultado de calibração | Confiança declarada | Resultado observado | Notas`.
+</calibracao_do_plano>
+
+<runtime_e_checkpoints>
+**Coerência do runtime e checkpoints** (obrigatória quando `EXECUTION-RUNTIME.md` ou `CHECKPOINTS.md` existirem)
+
+1. Verificar se a onda/tarefa que o runtime marca como concluída bate com a evidência real nos arquivos e nos comandos executados.
+2. Verificar se checkpoints `pending_approval` foram respeitados, e se `approved`, `rejected` ou `overridden` têm evidência e nota curta.
+3. Se runtime ou checkpoints contradisserem `STATE.md`, `PLAN.md` ou `VERIFY.md`, registrar a incoerência explicitamente.
+4. Usar esses artefatos como apoio para a seção de gaps e para a calibração do plano.
+</runtime_e_checkpoints>
+
 <process>
 1. **Camada 1 — Auditoria de pré-execução:** checar integridade do PLAN.md e DISCUSS.md conforme `<camada_1_pre_exec_audit>`. Documentar resultado.
-2. Ler `SPEC.md`, `PLAN.md` e `DISCUSS.md` do escopo resolvido, além de `.oxe/STATE.md` global.
+2. Ler `SPEC.md`, `PLAN.md` e `DISCUSS.md` do escopo resolvido, além de `.oxe/STATE.md` global.
 3. **Camada 2:** Para cada tarefa relevante, executar **Verificar: Comando** do PLAN (ou subconjunto se foco Tn). Para **cada ID de critério** da SPEC (A1, A2, …), registrar se passou com evidência.
 4. **Camada 3:** Se existir `.oxe/DISCUSS.md` com IDs D-NN, executar **Fidelidade de decisões** conforme `<camada_3_fidelidade_decisoes>`.
-5. Escrever **`VERIFY.md`** no escopo resolvido com:
+5. Executar a verificação de coerência do runtime e checkpoints conforme `<runtime_e_checkpoints>`.
+5a. Para operações Azure, confirmar o estado final com inventário/saída real do provider Azure; não considerar mutação aprovada sem evidência em `.oxe/cloud/azure/operations/`.
+6. Escrever **`VERIFY.md`** no escopo resolvido com:
    - Data, ambiente (SO / versão do Node se relevante).
    - **Seção — Auditoria de pré-execução:** resultado da Camada 1.
    - **Tabela — Tarefas:** Tarefa (Tn) | Verificação (comando/checklist) | Passou? | Notas.
    - **Tabela — Critérios SPEC:** ID (A1…) | Critério (resumo) | Evidência | Passou? | Notas.
    - **Tabela — Fidelidade de decisões** (se DISCUSS.md existir): ID | Decisão | Tarefa(s) | Implementado? | Evidência.
+   - **Seção — Coerência operacional:** runtime, checkpoints, bloqueios, handoffs e divergências.
+   - **Seção — Calibração do plano:** resultado conforme `<calibracao_do_plano>`.
    - **Checklist UAT** (Camada 4).
    - **Gaps** — o que falhou e sugestão de correção; se não houver, escrever `Nenhum gap restante`.
-6. Atualizar **`.oxe/STATE.md`** global: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
+6. Atualizar **`.oxe/STATE.md`** global: `verify_complete` ou `verify_failed` + próximo passo (replan, corrigir ou publicar).
 6b. **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.
-7. 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.
+7. 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.
 7b. **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.
 7b. **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.
 7c. **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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oxe-cc",
-  "version": "0.6.5",
+  "version": "0.7.0",
   "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 tests/oxe-retro-health.test.cjs",
+    "test": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-dashboard.test.cjs tests/oxe-operational.test.cjs tests/oxe-azure.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"