oxe-cc 1.6.0 → 1.7.0

package/oxe/workflows/spec.md

@@ -30,6 +30,10 @@ Se **`.oxe/config.json`** tiver `discuss_before_plan: true`: mencionar no final
 
 **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.
 
+**Rastreabilidade forte:** todo requisito `R-ID` precisa apontar para pelo menos um critério `A*` verificável, ou aparecer como v2/fora com justificativa. Critério sem método de verificação não entra como v1.
+
+**Setup externo:** quando o sucesso depender de conta, variável de ambiente, dashboard, fila, banco, credencial, VPN ou recurso cloud, registrar em SPEC a seção **Setup externo e pré-condições**. O plano deve transformar isso em checkpoint ou tarefa explícita; não deixar como suposição solta.
+
 **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
@@ -89,6 +93,7 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - o que segue ambíguo;
 - quais evidências faltam;
 - quais riscos podem reduzir a confiança do plano.
+- quais anchors, fixtures ou investigações serão obrigatórios para permitir `Confiança > 90%` no plano.
 </fase_1_perguntas>
 
 <fase_2_pesquisa>
@@ -111,6 +116,151 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 **Explorações grandes / sistemas legado:** ver **`oxe/workflows/references/legacy-brownfield.md`** — progressive disclosure por área, multiple sessions, epicos por trilha.
 </fase_2_pesquisa>
 
+<domain_question_library>
+## Biblioteca de perguntas por domínio
+
+Complemento adaptativo para a Fase 1. Quando o domínio for confirmado (via scan ou resposta da Fase 1), adicionar o bloco correspondente às perguntas de rodada 2 ou 3. **Nunca adicionar todos os blocos** — usar apenas os relevantes.
+
+---
+
+### Domínio: API REST / GraphQL
+
+*Adicionar ao Bloco B quando o escopo toca endpoints ou contratos de API:*
+
+- O contrato da API é público (consumido por outros times/clientes externos) ou interno?
+- Quais endpoints existentes serão modificados vs criados do zero?
+- Há versionamento de API (v1/v2)? O que acontece com clientes na versão antiga?
+- Qual a estratégia de autenticação: JWT Bearer, API Key, OAuth, sessão?
+- Há rate limiting, throttling ou quotas a considerar?
+- Como erros de validação devem ser retornados (formato JSON, campos obrigatórios)?
+- Há documentação de API (OpenAPI/Swagger) que deve ser atualizada junto?
+
+*Critérios A* a sugerir (adaptar ao contexto):*
+- `A-N: POST /recurso retorna 201 com payload correto quando input válido`
+- `A-N: POST /recurso retorna 400 com campo errors[] quando input inválido`
+- `A-N: GET /recurso retorna 401 sem Bearer token válido`
+- `A-N: Stack trace ausente em todas as respostas de erro`
+
+---
+
+### Domínio: Autenticação e Autorização
+
+*Adicionar ao Bloco B quando o escopo toca auth, sessões, permissões ou RBAC:*
+
+- Qual o mecanismo de autenticação existente? Está sendo mantido ou substituído?
+- Há multi-tenancy? Usuários de tenant A podem ver dados de tenant B?
+- Qual o modelo de autorização: RBAC, ABAC, ACL, baseado em ownership?
+- O que acontece com tokens existentes se o sistema de auth mudar?
+- Como o logout funciona: client-side only, blacklist server-side, ou short TTL?
+- Há requisitos de MFA, SSO ou integração com IdP externo (Keycloak, Auth0, SAML)?
+- Qual o TTL dos tokens de acesso e de refresh?
+
+*Critérios A* a sugerir:*
+- `A-N: Rota protegida retorna 403 para usuário autenticado sem permissão`
+- `A-N: Token expirado recebe 401, não 500`
+- `A-N: Usuário de tenant A não retorna dados de tenant B em nenhum endpoint`
+- `A-N: Senha armazenada como hash bcrypt/argon2 — nenhum plaintext no banco`
+
+---
+
+### Domínio: Banco de dados e Migrations
+
+*Adicionar ao Bloco B quando o escopo toca schema ou dados persistidos:*
+
+- Há dados existentes que serão afetados? Quantas linhas aproximadamente?
+- A migration é aditiva (add column, new table) ou destrutiva (drop, rename, type change)?
+- Qual é a janela de manutenção? A migration pode rodar online (zero-downtime)?
+- Se a migration falhar no meio, qual o estado do banco? É reversível via `down()`?
+- Há dependências: outras tabelas, serviços, ou queries que leem os campos afetados?
+- Os índices existentes serão afetados? Há criação de índice em tabela grande (lock)?
+- Há necessidade de backfill de dados? Com qual estratégia (batch, job assíncrono)?
+
+*Critérios A* a sugerir:*
+- `A-N: Migration é reversível via down() sem perda de dados`
+- `A-N: Zero registros com campo NOT NULL ausente após migration`
+- `A-N: Nenhum índice existente é dropado inadvertidamente`
+- `A-N: Backfill completa sem timeout e sem bloquear leituras`
+
+---
+
+### Domínio: UI e Frontend
+
+*Adicionar ao Bloco B quando o escopo toca interface de usuário:*
+
+- Qual o dispositivo alvo primário — desktop, mobile, ambos?
+- Há design system ou biblioteca de componentes obrigatória (ex.: Material, Tailwind)?
+- O estado deve ser persistido entre reloads de página?
+- Há requisitos de acessibilidade (WCAG)? Qual nível (A, AA, AAA)?
+- Como carregamento de dados é gerenciado: loading state, error state, empty state?
+- Há internacionalização (i18n) ou múltiplos idiomas a suportar?
+- Qual a estratégia de tratamento de erros visível ao usuário?
+
+*Critérios A* a sugerir:*
+- `A-N: Componente exibe loading state enquanto dados carregam`
+- `A-N: Erro de API exibe mensagem legível, não stack trace`
+- `A-N: Formulário desabilita submit enquanto request está em andamento`
+- `A-N: Todos os campos de formulário têm label associada (WCAG básico)`
+
+---
+
+### Domínio: Filas, Eventos e Processamento Assíncrono
+
+*Adicionar ao Bloco B quando o escopo toca mensageria ou jobs:*
+
+- O que acontece se a mensagem não puder ser processada? Há dead-letter queue?
+- Qual a garantia de entrega: at-most-once, at-least-once, ou exactly-once?
+- O consumer é idempotente? O que acontece se a mesma mensagem chegar duas vezes?
+- Há ordering guarantee? As mensagens precisam ser processadas em ordem?
+- Qual o SLA de processamento? Há timeout esperado?
+- Como monitorar backlog? Há alertas quando a fila cresce além de N mensagens?
+- Qual a estratégia de retry? Com backoff exponencial? Limite de tentativas?
+
+*Critérios A* a sugerir:*
+- `A-N: Consumer idempotente — processar a mesma mensagem 2x não duplica efeito`
+- `A-N: Mensagem inválida vai para DLQ com metadados de diagnóstico`
+- `A-N: Consumer continua operando após falha transiente (retry com backoff)`
+- `A-N: Backlog não cresce indefinidamente — processamento acompanha produção`
+
+---
+
+### Domínio: Dados, ETL e Pipelines
+
+*Adicionar ao Bloco B quando o escopo toca ingestão, transformação ou exportação:*
+
+- Qual o volume de dados (linhas/dia, GB/hora)?
+- Qual a janela de processamento: batch diário, near-realtime, ou streaming?
+- O que acontece se o dado de entrada estiver malformado ou faltando campos?
+- Há dependência de fuso horário? Como timestamps são normalizados?
+- O pipeline é idempotente — reprocessar o mesmo input não duplica saída?
+- Como o progresso é rastreado? Há checkpointing para retomada após falha?
+- Quais são as métricas de qualidade de dados obrigatórias (completude, unicidade)?
+
+*Critérios A* a sugerir:*
+- `A-N: Registro inválido é rejeitado e vai para dead-letter com motivo explicito`
+- `A-N: Reprocessar o mesmo input não duplica registros de saída`
+- `A-N: Pipeline completa dentro da janela de SLA definida`
+
+---
+
+### Domínio: Infraestrutura e Deploy
+
+*Adicionar ao Bloco B quando o escopo toca infraestrutura ou processo de deploy:*
+
+- Em qual ambiente a mudança será implantada primeiro (dev/staging/prod)?
+- Há downtime aceitável? Ou é obrigatório zero-downtime (rolling deploy)?
+- Qual o processo de rollback se algo der errado em produção?
+- Há variáveis de ambiente a adicionar? Quem configura em produção e quando?
+- A mudança requer scaling ou mudança de capacidade (CPU, memória, instâncias)?
+- Health checks ou readiness probes precisam ser atualizados?
+- Como validar em produção: feature flag, canary release, A/B, smoke test?
+
+*Critérios A* a sugerir:*
+- `A-N: Deploy não causa downtime perceptível (< 30s de interrupção)`
+- `A-N: Rollback é possível em < 15 minutos sem perda de dados`
+- `A-N: Health check retorna 200 após deploy bem-sucedido`
+- `A-N: Todas as variáveis de ambiente estão documentadas em SPEC antes do deploy`
+</domain_question_library>
+
 <fase_3_requisitos>
 ## Fase 3 — Requisitos
 
@@ -140,20 +290,85 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 
 **Objetivo:** propor proativamente critérios de hardening baseados no stack detectado, antes de criar o roteiro. Garante que segurança e robustez entrem na spec — e portanto no plan, nos testes e no verify — em vez de ficarem como auditoria pós-hoc.
 
-**Referência:** `oxe/workflows/references/robustness-elevation.md`
+**Referência canônica:** `oxe/workflows/references/robustness-elevation.md`
 
 **Execução:**
 
-1. **Detectar domínios** presentes: AUTH, API, DB, FRONTEND, FILE — conforme tabela de detecção do arquivo de referência.
-2. **Para cada domínio detectado**, percorrer o checklist correspondente e filtrar critérios já cobertos por A* existentes.
-3. **Propor** os critérios restantes como R-RB-NN com prioridade sugerida (v1 / v2 / fora).
-4. **Apresentar ao usuário** em bloco único — domínios detectados, critérios propostos com justificativa breve para v1 críticos.
-5. **Aguardar decisão** — usuário confirma, ajusta versão ou descarta cada critério.
-6. **Incorporar aprovados** na tabela da Fase 3; registrar descartados com justificativa na seção "Suposições e riscos" da SPEC.
+1. **Detectar domínios** presentes: AUTH, API, DB, FRONTEND, FILE — via scan artifacts ou inferência da Fase 1.
+2. **Para cada domínio detectado**, percorrer o catálogo abaixo e filtrar critérios já cobertos por A* existentes.
+3. **Propor** os critérios restantes como R-RB-NN com prioridade sugerida.
+4. **Apresentar ao usuário** em bloco único — domínios detectados, critérios propostos com justificativa breve para os v1 críticos.
+5. **Aguardar decisão** — usuário confirma, ajusta versão ou descarta.
+6. **Incorporar aprovados** na tabela da Fase 3; registrar descartados com justificativa em "Suposições e riscos".
+
+**Regra:** nunca forçar inclusão. Se o usuário descartar um v1 crítico, registrar o motivo explicitamente para auditoria futura.
 
-**Regra:** nunca forçar inclusão. Se o usuário descartar um v1, registrar o motivo explicitamente.
+**Pulável apenas se:** stack não se encaixa em nenhum domínio (ex.: script CLI puro sem auth, sem HTTP, sem DB). Nesse caso, registrar explicitamente: "Fase 3.5 não aplicável: [motivo]".
 
-**Pulável apenas se:** stack não se encaixa em nenhum domínio detectável (ex.: script CLI puro sem auth, sem HTTP, sem DB).
+---
+
+### Catálogo de critérios por domínio
+
+#### AUTH — critérios de segurança de autenticação
+
+| R-RB | Critério | Prioridade | Justificativa |
+|------|----------|------------|---------------|
+| R-RB-A01 | Senha nunca retornada em resposta de API (nem em log) | v1 crítico | Vazamento via resposta ou observabilidade |
+| R-RB-A02 | Rate limit em tentativas de login falhas (ex.: 5/min por IP) | v1 crítico | Proteção contra brute force |
+| R-RB-A03 | JWT valida `iss`, `aud`, `exp` e `iat` em toda rota protegida | v1 crítico | Tokens de outros sistemas aceitos |
+| R-RB-A04 | Refresh token rotacionado a cada uso | v1 | Prevenção de token replay |
+| R-RB-A05 | Logout invalida token server-side (blacklist ou short TTL) | v1 | Logout não impede uso do token |
+| R-RB-A06 | Headers de segurança presentes: CSP, X-Frame-Options, HSTS | v2 | Proteção contra XSS/clickjacking |
+| R-RB-A07 | Cookies com `Secure` + `HttpOnly` + `SameSite=Strict` | v1 se usa cookies | CSRF + XSS via cookie |
+| R-RB-A08 | Credenciais de admin não hardcoded em código ou config | v1 crítico | Secret exposto no repositório |
+
+#### API REST — critérios de segurança de endpoint
+
+| R-RB | Critério | Prioridade | Justificativa |
+|------|----------|------------|---------------|
+| R-RB-R01 | Toda rota tem validação de schema de entrada (DTO/Zod/Joi) | v1 crítico | Input não validado = injection risk |
+| R-RB-R02 | Erros de validação retornam 400 com campo `errors[]` estruturado | v1 | Feedback objetivo ao cliente |
+| R-RB-R03 | Stack trace ausente em todas as respostas de erro (4xx e 5xx) | v1 crítico | Exposição de internals ao cliente |
+| R-RB-R04 | Paginação obrigatória em listas (sem retornar N ilimitado) | v1 | DoS por dump de tabela grande |
+| R-RB-R05 | Rate limiting em endpoints públicos e autenticados | v1 | Abuso de API |
+| R-RB-R06 | CORS configurado explicitamente — nunca `Access-Control-Allow-Origin: *` em produção | v1 se frontend externo | Acesso cross-origin não intencional |
+| R-RB-R07 | IDs de recursos opacos (UUID/ULID/nanoid, não int sequencial) | v2 | Enumeração de recursos |
+| R-RB-R08 | Timeout em todas as chamadas a dependências externas | v1 | Hang em falha de dependency |
+
+#### DB — critérios de segurança de banco de dados
+
+| R-RB | Critério | Prioridade | Justificativa |
+|------|----------|------------|---------------|
+| R-RB-D01 | Queries usam prepared statements ou ORM — zero concatenação de string | v1 crítico | SQL injection |
+| R-RB-D02 | Connection pool com tamanho máximo configurado | v1 | Esgotamento de conexões em load |
+| R-RB-D03 | Transações em operações multi-step (atomicidade garantida) | v1 | Dados inconsistentes em falha parcial |
+| R-RB-D04 | Migrations idempotentes e com `down()` reversível | v1 | Rollback impossível |
+| R-RB-D05 | Campos sensíveis (PII, segredos) criptografados ou hasheados | v1 se há PII | Exposure em dump de banco |
+| R-RB-D06 | Índices para queries de alta frequência | v2 | Degradação de performance sob load |
+| R-RB-D07 | Soft delete preferido sobre hard delete em entidades de negócio | v2 | Perda acidental irrecuperável de dados |
+
+#### FRONTEND — critérios de segurança de UI
+
+| R-RB | Critério | Prioridade | Justificativa |
+|------|----------|------------|---------------|
+| R-RB-F01 | Dados do usuário escapados antes de renderizar no DOM | v1 crítico | XSS via conteúdo dinâmico |
+| R-RB-F02 | Formulários têm proteção CSRF (token ou SameSite) | v1 se usa cookies/sessão | CSRF attack |
+| R-RB-F03 | API keys / segredos ausentes no bundle client-side | v1 crítico | Exposição de credenciais via DevTools |
+| R-RB-F04 | Loading, error e empty states implementados em todos os fluxos | v1 | UX quebrada em falha de rede |
+| R-RB-F05 | Inputs sanitizados antes de envio (sem XSS via form) | v1 | Injection via campo de formulário |
+| R-RB-F06 | Deep links funcionam no reload da página (rota não quebra) | v1 | UX ruim e links não compartilháveis |
+| R-RB-F07 | Labels acessíveis em todos os inputs (WCAG 2.1 AA mínimo) | v2 | Acessibilidade básica |
+
+#### FILE / Storage — critérios de segurança de upload
+
+| R-RB | Critério | Prioridade | Justificativa |
+|------|----------|------------|---------------|
+| R-RB-S01 | Tipo de arquivo validado por magic bytes, não apenas extensão | v1 crítico | Upload de executável com extensão .jpg |
+| R-RB-S02 | Tamanho de arquivo com limite máximo configurado | v1 crítico | DoS por upload de arquivo gigante |
+| R-RB-S03 | Arquivos armazenados fora do webroot (não servíveis diretamente) | v1 crítico | Path traversal + execução remota |
+| R-RB-S04 | Nome do arquivo sanitizado — nunca usar nome original do cliente | v1 | Path traversal no sistema de arquivos |
+| R-RB-S05 | URLs de download com TTL (presigned URLs, não permanentes) | v1 se dados sensíveis | Vazamento por link compartilhado |
+| R-RB-S06 | Scan de malware em uploads (se domínio crítico de segurança) | v2 | Upload e redistribuição de malware |
 </fase_35_elevacao_robustez>
 
 <fase_4_roteiro>
@@ -223,6 +438,84 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 - evidências faltantes que podem reduzir a confiança do plano.
 </auto_reflexao>
 
+<spec_anti_patterns>
+## Anti-padrões de especificação
+
+Detectar e corrigir estes problemas antes de entregar a SPEC. A auto-reflexão da Fase 3.5 deve capturar a maioria, mas são registrados aqui como referência explícita para revisão manual.
+
+---
+
+### Critério A* não verificável
+
+**Problema:** `A3 — Sistema deve ser escalável e performático`
+**Por quê é ruim:** "escalável" e "performático" sem métrica são impossíveis de testar. O executor não sabe quando passou.
+**Solução:** `A3 — Sistema responde < 200ms em p95 com 100 usuários simultâneos (teste k6 smoke em staging)` — métrica, percentil, carga, ambiente.
+
+---
+
+### Escopo creep implícito
+
+**Problema:** usuário pediu "adicionar campo de telefone no perfil". A SPEC incluiu "refatorar módulo de perfil completo" em v1.
+**Por quê é ruim:** o usuário não pediu refatoração — foi decisão unilateral do agente. Scope não autorizado.
+**Solução:** incluir apenas o que emergiu da Fase 1/2. Refatorações sugeridas vão para v2 ou são registradas em CONCERNS com nota "sugerido, não solicitado".
+
+---
+
+### Suposição técnica não registrada
+
+**Problema:** a SPEC integra com Stripe e assume que `STRIPE_SECRET_KEY` já está configurada em produção.
+**Por quê é ruim:** o plan vai criar a integração, mas o executor vai falhar por falta de credencial sem diagnóstico claro.
+**Solução:** toda suposição de ambiente vai explicitamente em "Setup externo e pré-condições" da SPEC. O plan converte suposições críticas em tarefas de verificação (Onda 1, action_type: `collect_evidence`).
+
+---
+
+### Requisito v1 que depende de v2
+
+**Problema:** `R1 (v1) — Notificações em tempo real` depende de `R5 (v2) — WebSocket server`.
+**Por quê é ruim:** o plano de v1 não pode executar R1 sem R5 existir. O plano vai falhar na verificação.
+**Solução:** ou mover R1 para v2, ou mover R5 para v1, ou re-especificar R1 sem WebSocket (ex.: polling com SSE).
+
+---
+
+### Critérios que conflitam entre si
+
+**Problema:** `A1 — Processar arquivo CSV em < 5s` e `A7 — Arquivo CSV pode ter até 1 GB`.
+**Por quê é ruim:** 1 GB em 5s pode ser fisicamente impossível dependendo da infra. Os dois critérios são contraditórios sem especificação de condições.
+**Solução:** tornar as condições consistentes: "< 5s para arquivos até 10 MB; processamento assíncrono para arquivos > 10 MB com status via polling".
+
+---
+
+### Fase 3.5 pulada sem justificativa
+
+**Problema:** SPEC finalizada sem executar elevação de robustez, sem nota explicando por quê.
+**Por quê é ruim:** vulnerabilidades conhecidas (XSS, SQL injection, brute force) não entram na v1 e viram dívida técnica imediata.
+**Solução:** sempre executar Fase 3.5. Se o stack não se encaixa em nenhum domínio, registrar: "Fase 3.5 não aplicável: CLI puro sem HTTP, sem DB, sem auth".
+
+---
+
+### ROADMAP sem resultado demonstrável por fase
+
+**Problema:** `Fase 1 — Implementar a lógica interna de processamento` sem resultado visível.
+**Por quê é ruim:** fases sem resultado demonstrável são estágios de código interno que o usuário não consegue validar.
+**Solução:** toda fase do ROADMAP deve ter resultado demonstrável: "Fase 1 — Usuário consegue fazer login, receber JWT válido e acessar rota protegida".
+
+---
+
+### Setup externo invisível na SPEC
+
+**Problema:** SPEC menciona "integrar com serviço de email" sem listar as credenciais necessárias nem quem as configura.
+**Por quê é ruim:** o plan vai criar a integração, mas vai falhar em staging/produção por falta de configuração externa.
+**Solução:** adicionar seção obrigatória `## Setup externo e pré-condições` com: variáveis de ambiente necessárias, contas/recursos a criar, e quem é responsável por cada item.
+
+---
+
+### Requisito verificável apenas em produção
+
+**Problema:** `A5 — Sistema envia email de boas-vindas para usuário real após cadastro`.
+**Por quê é ruim:** não é possível verificar em CI/CD sem sandbox do provedor de email. O agente não tem acesso ao email real.
+**Solução:** tornar verificável em ambiente controlado: `A5 — Integração com SendGrid sandbox envia email para endereço de teste; log confirma `202 Accepted` do provider`. Ou marcar explicitamente "verificação manual necessária" com critério de como realizar.
+</spec_anti_patterns>
+
 <fase_5_aprovacao>
 ## Fase 5 — Aprovação e próximo passo
 

package/oxe/workflows/ui-review.md

@@ -12,14 +12,15 @@ Não substitui **`verify`**: cruza contrato UI; o verify global continua a amarr
 
 <context>
 - Aplicar `oxe/workflows/references/reasoning-review.md`. A revisão UI deve começar pelos achados e bloqueios, não por resumo.
-- Se não existir `UI-SPEC.md`, pedir **`/oxe-ui-spec`** primeiro ou documentar em UI-REVIEW que a revisão é **ad hoc** (menos preferível).
-- Incluir checklist curta (ex.: pilares: semântica, foco, contraste, mensagens de erro, mobile).
-- **Bloqueios P0** (ex.: inacessível, fluxo quebrado) devem ser listados explicitamente; P1/P2 como melhorias.
+- Se não existir `UI-SPEC.md`, pedir **`/oxe-ui-spec`** primeiro ou documentar em UI-REVIEW que a revisão é **ad hoc** (menos preferível).
+- Incluir checklist curta (ex.: pilares: semântica, foco, contraste, mensagens de erro, mobile).
+- **Bloqueios P0** (ex.: inacessível, fluxo quebrado) devem ser listados explicitamente; P1/P2 como melhorias.
+- Agente especializado: quando disponível, usar `oxe-ui-auditor` para comparar implementação contra `UI-SPEC.md`, evidência visual e critérios A*.
 </context>
 
 <process>
 1. Resolver `active_session` conforme `session-path-resolution.md`; ler `UI-SPEC.md` e `SPEC.md` do escopo resolvido e inspecionar ficheiros de UI relevantes (paths do PLAN ou indicados pelo utilizador).
-2. Escrever **`UI-REVIEW.md`** no escopo de `verification/` da sessão ativa (ou `.oxe/` legado) com: **Data**, **Âmbito revisto**, **Checklist** (passou / falhou / N/A), **Bloqueios**, **Sugestões**.
+2. Escrever **`UI-REVIEW.md`** no escopo de `verification/` da sessão ativa (ou `.oxe/` legado) com: **Data**, **Âmbito revisto**, **Checklist** (passou / falhou / N/A), **Bloqueios**, **Sugestões**, evidência visual quando disponível e divergências justificadas.
 3. Atualizar **`.oxe/STATE.md`** global se útil (referência a UI-REVIEW pendente de verify).
 4. Indicar no chat nesta ordem:
    - **Findings**

package/oxe/workflows/ui-spec.md

@@ -12,13 +12,14 @@ Produzir **`.oxe/UI-SPEC.md`**: contrato de UI/UX derivado de **`.oxe/SPEC.md`**
 
 <context>
 - Se o projeto **não** tiver interface (só API/CLI/backend), não gerar UI-SPEC; indicar no chat que esta vertical não se aplica.
-- Não substituir a SPEC: UI-SPEC **refina** entrega visual/UX alinhada aos **A***.
-- Secções sugeridas em `UI-SPEC.md`: **Âmbito** (ecrãs/componentes), **Estados** (vazio/carregamento/erro/sucesso), **Acessibilidade** (foco, labels, teclado), **Breakpoints** (se aplicável), **Tokens ou estilo** (ligação a design system existente, se houver).
+- Não substituir a SPEC: UI-SPEC **refina** entrega visual/UX alinhada aos **A***.
+- Secções obrigatórias em `UI-SPEC.md`: **Âmbito** (ecrãs/componentes), **Design system**, **Tokens**, **Estados** (vazio/carregamento/erro/sucesso), **Copywriting**, **Acessibilidade** (foco, labels, teclado), **Breakpoints**, **Registry safety** e **Checker sign-off**.
+- Agentes úteis: `oxe-ui-researcher` cria o contrato; `oxe-ui-checker` valida se ele é implementável antes do plano.
 </context>
 
 <process>
 1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
-2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais).
+2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais). Se componente externo/registry for citado, registrar origem, inspeção mínima e risco.
 3. Atualizar **`.oxe/STATE.md`** global: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
 4. Resumo no chat: o que ficou no UI-SPEC e como o **`/oxe-plan`** deve citar as secções (ex.: “cumprir UI-SPEC §2”).
 </process>

package/oxe/workflows/verify.md

@@ -51,9 +51,10 @@ Ao receber qualquer argumento, verificar flags antes de iniciar o fluxo principa
 - 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.
 - Antes da leitura ampla, resolver `.oxe/context/packs/verify.md` e `.oxe/context/packs/verify.json` como entrada prioritária do passo.
 - Se o pack estiver fresco e coerente, usar `read_order`, `selected_artifacts`, `gaps` e `conflicts` como mapa primário da evidência. Se estiver stale, ausente ou com lacunas críticas, fazer fallback explícito para leitura direta e registar isso em `VERIFY.md`.
-- **Runtime enterprise como caminho padrão:** quando `oxe-cc runtime` estiver disponível, executar ou solicitar `oxe-cc runtime verify --dir <projeto>` como caminho primário deste passo. Tratar `verification-manifest.json`, `residual-risk-ledger.json` e `evidence-coverage.json` da run ativa como fonte primária de evidência técnica, e o `VERIFY.md` projetado pelo runtime como base do artefato final.
-- Se `runtime verify` retornar `partial`, continuar com as camadas manuais usando os gaps explícitos do runtime como backlog obrigatório da revisão; não cair silenciosamente para narrativa solta.
-- Se o runtime não estiver compilado, indisponível ou não puder ser executado no ambiente atual, declarar `fallback legado` explicitamente antes de seguir com a verificação manual baseada em markdown e comandos locais.
+- **Runtime enterprise como caminho padrão:** quando `oxe-cc runtime` estiver disponível, executar ou solicitar `oxe-cc runtime verify --dir <projeto>` como caminho primário deste passo. Tratar `verification-manifest.json`, `residual-risk-ledger.json` e `evidence-coverage.json` da run ativa como fonte primária de evidência técnica, e o `VERIFY.md` projetado pelo runtime como base do artefato final.
+- Se `runtime verify` retornar `partial`, continuar com as camadas manuais usando os gaps explícitos do runtime como backlog obrigatório da revisão; não cair silenciosamente para narrativa solta.
+- Se o runtime não estiver compilado, indisponível ou não puder ser executado no ambiente atual, declarar `fallback legado` explicitamente antes de seguir com a verificação manual baseada em markdown e comandos locais.
+- **Agentes de verificação:** quando disponíveis, usar `oxe-verifier`, `oxe-integration-checker`, `oxe-validation-auditor` e `oxe-ui-auditor` como papéis auxiliares para auditar evidência, integração, lacunas de validação e UI. O resultado final continua sendo `VERIFY.md` + manifest/evidence do runtime.
 - 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.
@@ -73,12 +74,14 @@ Ao receber qualquer argumento, verificar flags antes de iniciar o fluxo principa
 <camada_1_pre_exec_audit>
 **Camada 1 — Auditoria de pré-execução** (roda *antes* de iniciar os comandos de verify)
 
-Verificar que o PLAN.md está apto para verificação:
+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).
 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.
+5. `PLAN.md` contém a seção **Autoavaliação do Plano** com `Melhor plano atual`, `Confiança` e rubrica preenchida.
+6. `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` existem quando a execução veio de plano e não possuem `critical_gap` não resolvido.
+7. Tarefas de risco têm evidência executável ou fixture/UAT explicitamente justificada.
 
 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>

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "oxe-cc",
-	"version": "1.6.0",
+	"version": "1.7.0",
 	"description": "OXE — spec-driven workflows in .oxe/ with runtime enterprise, evidence-first verification and multi-runtime integrations (npx)",
 	"license": "MIT",
 	"author": "",

package/packages/runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oxe/runtime",
-  "version": "1.6.0",
+  "version": "1.7.0",
   "private": true,
   "license": "MIT",
   "description": "OXE agentic execution engine — enterprise runtime core",

package/packages/runtime/src/compiler/graph-compiler.ts

@@ -199,6 +199,46 @@ export function validateGraph(graph: ExecutionGraph): string[] {
     }
   }
 
+  // Validate mutation_scope conflicts between parallel nodes in the same wave
+  const waveMap = new Map<number, string[]>();
+  for (const [id, node] of graph.nodes) {
+    const list = waveMap.get(node.wave) ?? [];
+    waveMap.set(node.wave, [...list, id]);
+  }
+
+  for (const [wave, waveNodeIds] of waveMap) {
+    for (let i = 0; i < waveNodeIds.length; i++) {
+      for (let j = i + 1; j < waveNodeIds.length; j++) {
+        const idA = waveNodeIds[i];
+        const idB = waveNodeIds[j];
+        const a = graph.nodes.get(idA)!;
+        const b = graph.nodes.get(idB)!;
+        const notDependent =
+          !a.depends_on.includes(idB) && !b.depends_on.includes(idA);
+        if (notDependent && a.mutation_scope.length > 0 && b.mutation_scope.length > 0) {
+          const overlap = a.mutation_scope.filter(p => b.mutation_scope.includes(p));
+          if (overlap.length > 0) {
+            errors.push(
+              `Wave ${wave}: nodes "${idA}" and "${idB}" mutate the same paths in parallel: ${overlap.join(', ')}`
+            );
+          }
+        }
+      }
+    }
+  }
+
+  // Validate wave ordering: a node must only depend on nodes from earlier waves
+  for (const [id, node] of graph.nodes) {
+    for (const dep of node.depends_on) {
+      const depNode = graph.nodes.get(dep);
+      if (depNode && depNode.wave >= node.wave) {
+        errors.push(
+          `Node "${id}" (wave ${node.wave}) depends on "${dep}" (wave ${depNode.wave}) — dependency must come from an earlier wave`
+        );
+      }
+    }
+  }
+
   return errors;
 }
 

package/packages/runtime/src/context/context-pack-builder.ts

@@ -237,6 +237,86 @@ export class ContextPackBuilder {
     return this.build(workItem, state, [], new Map(), lessons);
   }
 
+  /**
+   * Remove artifacts with lowest relevance until the pack fits within targetTokens.
+   * Artifacts already sorted by relevance; we trim the tail.
+   */
+  compact(pack: ContextPack, targetTokens: number): ContextPack {
+    if (estimateTokens(pack.artifacts.map((a) => a.content).join('\n')) <= targetTokens) {
+      return pack;
+    }
+    const sorted = [...pack.artifacts].sort((a, b) => b.relevanceScore - a.relevanceScore);
+    const trimmed: ContextArtifact[] = [];
+    let used = 0;
+    for (const artifact of sorted) {
+      const t = estimateTokens(artifact.content);
+      if (used + t > targetTokens) break;
+      trimmed.push(artifact);
+      used += t;
+    }
+    return {
+      ...pack,
+      artifacts: trimmed,
+      redundancy_removed: pack.redundancy_removed + (pack.artifacts.length - trimmed.length),
+    };
+  }
+
+  /**
+   * Merge groups of similar artifacts (cosine similarity >= threshold) into single
+   * combined artifacts to reduce redundancy without discarding information entirely.
+   */
+  microCompact(artifacts: ContextArtifact[], similarityThreshold = 0.7): ContextArtifact[] {
+    const merged: ContextArtifact[] = [];
+    const used = new Set<number>();
+
+    for (let i = 0; i < artifacts.length; i++) {
+      if (used.has(i)) continue;
+      const group: ContextArtifact[] = [artifacts[i]];
+      for (let j = i + 1; j < artifacts.length; j++) {
+        if (!used.has(j) && cosineSimilarity(artifacts[i], artifacts[j]) >= similarityThreshold) {
+          group.push(artifacts[j]);
+          used.add(j);
+        }
+      }
+      used.add(i);
+      if (group.length === 1) {
+        merged.push(group[0]);
+      } else {
+        const combinedContent = group
+          .map((a) => a.content)
+          .join('\n---\n')
+          .slice(0, 4000);
+        merged.push({
+          id: group[0].id,
+          kind: group[0].kind,
+          content: combinedContent,
+          relevanceScore: group.reduce((s, a) => s + a.relevanceScore, 0) / group.length,
+          tags: [...new Set(group.flatMap((a) => a.tags))],
+        });
+      }
+    }
+    return merged;
+  }
+
+  /**
+   * Automatically compact a pack to fit within hardLimitTokens.
+   * First applies microCompact (lossless merging), then compact (trimming by relevance).
+   */
+  autoCompact(pack: ContextPack, hardLimitTokens: number): ContextPack {
+    const currentTokens = estimateTokens(pack.artifacts.map((a) => a.content).join('\n'));
+    if (currentTokens <= hardLimitTokens) return pack;
+
+    const microCompacted = this.microCompact(pack.artifacts);
+    const removedByMicro = pack.artifacts.length - microCompacted.length;
+
+    const interim: ContextPack = {
+      ...pack,
+      artifacts: microCompacted,
+      redundancy_removed: pack.redundancy_removed + removedByMicro,
+    };
+    return this.compact(interim, hardLimitTokens);
+  }
+
   /**
    * Filter artifacts to those whose path-like tags are within mutation_scope.
    * L0/L1 tiers apply the filter; L2/L3 skip it (full access).

package/packages/runtime/src/events/catalog.ts

@@ -20,6 +20,11 @@ export const EVENT_TYPES = [
   'RunCompleted',
   'RetroPublished',
   'LessonPromoted',
+  'RunAborted',
+  'RollbackExecuted',
+  'RollbackFailed',
+  'TaskErrorBoundaryTripped',
+  'WorkspaceDisposeFailed',
 ] as const;
 
 export type EventType = (typeof EVENT_TYPES)[number];

package/packages/runtime/src/executor/action-tool-map.ts

@@ -0,0 +1,46 @@
+import type { Action } from '../compiler/graph-compiler';
+import { ALL_BUILT_IN_SCHEMAS, BUILT_IN_TOOLS } from './built-in-tools';
+import type { ToolSchema } from './stream-completion';
+
+const READ_TOOLS: ToolSchema[] = [
+  BUILT_IN_TOOLS.read_file.schema,
+  BUILT_IN_TOOLS.glob.schema,
+  BUILT_IN_TOOLS.grep.schema,
+];
+
+const PATCH_TOOLS: ToolSchema[] = [
+  BUILT_IN_TOOLS.read_file.schema,
+  BUILT_IN_TOOLS.write_file.schema,
+  BUILT_IN_TOOLS.patch_file.schema,
+];
+
+const RUN_TOOLS: ToolSchema[] = [BUILT_IN_TOOLS.run_command.schema];
+
+const EVIDENCE_TOOLS: ToolSchema[] = [
+  BUILT_IN_TOOLS.read_file.schema,
+  BUILT_IN_TOOLS.glob.schema,
+  BUILT_IN_TOOLS.run_command.schema,
+];
+
+const ACTION_TOOL_MAP: Record<Action['type'], ToolSchema[]> = {
+  read_code: READ_TOOLS,
+  generate_patch: PATCH_TOOLS,
+  run_tests: RUN_TOOLS,
+  run_lint: RUN_TOOLS,
+  collect_evidence: EVIDENCE_TOOLS,
+  custom: ALL_BUILT_IN_SCHEMAS,
+};
+
+export function selectToolsForActions(actions: Action[]): ToolSchema[] {
+  const seen = new Set<string>();
+  const result: ToolSchema[] = [];
+  for (const action of actions) {
+    for (const tool of ACTION_TOOL_MAP[action.type] ?? ALL_BUILT_IN_SCHEMAS) {
+      if (!seen.has(tool.function.name)) {
+        seen.add(tool.function.name);
+        result.push(tool);
+      }
+    }
+  }
+  return result;
+}