oxe-cc 0.9.2 → 0.9.3

package/.cursor/commands/oxe-retro.md

@@ -9,7 +9,7 @@ oxe_tool_profile: review_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 5afa357495cad615
+oxe_semantics_hash: 8f2925a220ed9bc2
 ---
 
 OXE — Retrospectiva de ciclo: 3–5 lições prescritivas em .oxe/LESSONS.md para ciclos futuros
@@ -25,7 +25,7 @@ OXE — Retrospectiva de ciclo: 3–5 lições prescritivas em .oxe/LESSONS.md p
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `5afa357495cad615`
+- **Checksum semântico:** `8f2925a220ed9bc2`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/retro.md` e `.oxe/context/packs/retro.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow retro --json`

package/.cursor/commands/oxe-spec.md

@@ -9,7 +9,7 @@ oxe_tool_profile: read_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 482d3eb12fe261ed
+oxe_semantics_hash: 598fcdce72e894c8
 ---
 
 OXE — Spec em 5 fases: perguntas → pesquisa → requisitos (R-ID v1/v2/fora) → roteiro (.oxe/ROADMAP.md) → aprovação → plan
@@ -25,7 +25,7 @@ OXE — Spec em 5 fases: perguntas → pesquisa → requisitos (R-ID v1/v2/fora)
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `482d3eb12fe261ed`
+- **Checksum semântico:** `598fcdce72e894c8`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/spec.md` e `.oxe/context/packs/spec.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow spec --json`

package/.github/prompts/oxe-retro.prompt.md

@@ -11,7 +11,7 @@ oxe_tool_profile: review_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 5afa357495cad615
+oxe_semantics_hash: 8f2925a220ed9bc2
 ---
 
 <!-- oxe-reasoning-contract:start -->
@@ -25,7 +25,7 @@ oxe_semantics_hash: 5afa357495cad615
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `5afa357495cad615`
+- **Checksum semântico:** `8f2925a220ed9bc2`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/retro.md` e `.oxe/context/packs/retro.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow retro --json`

package/.github/prompts/oxe-spec.prompt.md

@@ -11,7 +11,7 @@ oxe_tool_profile: read_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 482d3eb12fe261ed
+oxe_semantics_hash: 598fcdce72e894c8
 ---
 
 <!-- oxe-reasoning-contract:start -->
@@ -25,7 +25,7 @@ oxe_semantics_hash: 482d3eb12fe261ed
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `482d3eb12fe261ed`
+- **Checksum semântico:** `598fcdce72e894c8`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/spec.md` e `.oxe/context/packs/spec.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow spec --json`

package/README.md

@@ -7,7 +7,7 @@
 [![npm](https://img.shields.io/npm/v/oxe-cc.svg?style=flat-square)](https://www.npmjs.com/package/oxe-cc)
 [![license](https://img.shields.io/npm/l/oxe-cc.svg?style=flat-square)](LICENSE)
 
-**Versão:** `0.9.2` · [package.json](package.json)
+**Versão:** `0.9.3` · [package.json](package.json)
 
 **Framework OXE — Orchestrated eXperience Engineering**
 

package/bin/banner.txt

@@ -15,4 +15,4 @@
 
 ══════════════════════════════════════════════════════
 
-                      v0.9.2
+                      v0.9.3

package/bin/lib/oxe-context-engine.cjs

@@ -256,6 +256,7 @@ function resolveArtifactCandidates(projectRoot, activeSession) {
     phase_summary: withFallback('phase_summary', 'summary', ctx.phaseSummaryJson, null, 'project'),
     context_pack_dashboard: withFallback('context_pack_dashboard', 'context_pack', ctx.defaultPackJson('dashboard'), null, 'project'),
     calibration: withFallback('calibration', 'calibration', path.join(base.oxe, 'calibration.json'), null, 'project'),
+    lessons_metrics: withFallback('lessons_metrics', 'metrics', path.join(base.oxe, 'lessons-metrics.json'), null, 'project'),
   };
 }
 

package/commands/oxe/retro.md

@@ -17,7 +17,7 @@ oxe_tool_profile: review_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 5afa357495cad615
+oxe_semantics_hash: 8f2925a220ed9bc2
 ---
 
 <!-- oxe-reasoning-contract:start -->
@@ -31,7 +31,7 @@ oxe_semantics_hash: 5afa357495cad615
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `5afa357495cad615`
+- **Checksum semântico:** `8f2925a220ed9bc2`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/retro.md` e `.oxe/context/packs/retro.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow retro --json`

package/commands/oxe/spec.md

@@ -15,7 +15,7 @@ oxe_tool_profile: read_heavy
 oxe_confidence_policy: explicit
 oxe_context_tier: standard
 oxe_contract_version: 2.0.0
-oxe_semantics_hash: 482d3eb12fe261ed
+oxe_semantics_hash: 598fcdce72e894c8
 ---
 
 <!-- oxe-reasoning-contract:start -->
@@ -29,7 +29,7 @@ oxe_semantics_hash: 482d3eb12fe261ed
 - **Política de confiança:** explícita
 - **Tier de contexto padrão:** padrão
 - **Versão do contrato:** 2.0.0
-- **Checksum semântico:** `482d3eb12fe261ed`
+- **Checksum semântico:** `598fcdce72e894c8`
 - **Entrada de contexto prioritária:** `.oxe/context/packs/spec.md` e `.oxe/context/packs/spec.json`
 - **Regra pack-first:** ler o context pack primeiro; se estiver stale, incompleto ou ausente, cair para leitura direta com fallback explícito.
 - **Inspeção estruturada:** `oxe-cc context inspect --workflow spec --json`

package/oxe/templates/LESSONS-METRICS.template.json

@@ -0,0 +1,13 @@
+{
+  "schema_version": "1.0.0",
+  "updated": "{{date}}",
+  "lessons": [],
+  "quality_contracts": [],
+  "summary": {
+    "total_lessons": 0,
+    "active": 0,
+    "deprecated": 0,
+    "high_impact": 0,
+    "avg_success_rate": null
+  }
+}

package/oxe/workflows/references/robustness-elevation.md

@@ -0,0 +1,295 @@
+# OXE — Quality Contract Elevation (Spec Fase 3.5)
+
+<objective>
+Transformar a Fase 3.5 de uma lista de checklist em um **Contrato de Qualidade** formal: um conjunto de compromissos mensuráveis que o projeto assume antes de qualquer linha de código. Cada item recusado torna-se um risco documentado com severidade e responsável — não silenciosamente ignorado.
+
+Cobre 6 dimensões: Segurança, Resiliência, Observabilidade, Confiança de Dados, Acessibilidade e Prontidão Operacional.
+</objective>
+
+---
+
+## Conceito fundamental
+
+Um checklist pergunta: *"você fez X?"*
+Um contrato de qualidade pergunta: *"a que piso de qualidade este sistema se compromete antes de ser construído?"*
+
+A diferença prática:
+- Itens aprovados → viram **R-RB-NN** na spec → **Tn** no plan → verificados no verify
+- Itens recusados → entram no **Accepted Risk Registry** com severidade, justificativa e responsável
+- Nenhum risco some silenciosamente
+
+---
+
+## Parte I — Detector de Arquitetura (executa sempre, antes de qualquer checklist)
+
+Oito cheiros detectáveis a partir da spec e stack descritos. Cada um detectado gera uma observação estruturada — não um bloqueio, mas um sinalizador que alimenta os checklists das Partes seguintes.
+
+| Smell | Sinal de detecção na spec | Risco gerado |
+|-------|--------------------------|--------------|
+| **AS-1 God Module** | Um único módulo/serviço cobre domínios não relacionados (ex.: auth + billing + notificações) | Acoplamento oculto; mudança em um domínio quebra outro |
+| **AS-2 Máquina de Estado Implícita** | Requisitos descrevem estados (rascunho, publicado, arquivado) sem tabela de transições explícita | Transições ilegais possíveis; comportamento indefinido em edge cases |
+| **AS-3 Sem Escape Assíncrono** | Todas as operações descritas como síncronas; nenhuma menção a filas, eventos ou jobs para operações longas | Timeouts em cascata; usuário travado aguardando operações de longa duração |
+| **AS-4 Serviço Escuro** | Nenhum requisito menciona logs, métricas ou rastreamento | Impossível diagnosticar falhas em produção; debugging cego |
+| **AS-5 Coleta Ilimitada** | Dados são coletados mas sem política de retenção, arquivamento ou deleção | Crescimento de banco ilimitado; risco LGPD/GDPR por dados retidos além do necessário |
+| **AS-6 Ponto Único de Falha Crítico** | Caminho crítico (auth, pagamento, core business) sem fallback, retry ou degradação definida | Falha de um componente derruba toda a operação |
+| **AS-7 API Sem Versão** | API pública descrita sem estratégia de versionamento ou deprecação | Mudanças futuras quebram clientes sem aviso; impossível evoluir contrato |
+| **AS-8 Deploy Acoplado** | Dois ou mais serviços/módulos distintos sempre fazem deploy juntos | Perda de autonomia; velocidade limitada pelo componente mais lento |
+
+**Ação:** para cada smell detectado, mencionar ao usuário antes dos checklists: *"Identifiquei AS-N [nome]: [sinal encontrado]. Vamos abordar isso nos requisitos ou prefere registrar como risco?"*
+
+---
+
+## Parte II — Derivação de Ameaças (STRIDE)
+
+Em vez de propor mitigações genéricas, derivar as **ameaças concretas** da arquitetura descrita e mapear mitigações ao vetor específico. O usuário vê *por que* cada controle existe, não apenas *o que* fazer.
+
+**Domínios → Vetores STRIDE:**
+
+| Domínio | Ameaça | Categoria STRIDE | Mitigações relacionadas |
+|---------|--------|-----------------|------------------------|
+| AUTH | Impostura de credenciais (brute force, credential stuffing) | **S**poofing | RB-SEC-A1, RB-SEC-A2, RB-SEC-A3 |
+| AUTH | Sequestro de sessão (token roubado via XSS ou rede) | **S**poofing + **I**nformation Disclosure | RB-SEC-A4, RB-SEC-A7 |
+| AUTH | Escalada de privilégio (acesso a recursos de outro usuário) | **E**levation of Privilege | RB-SEC-A4, RB-SEC-A7 |
+| AUTH | Ausência de trilha de auditoria (negação de ações realizadas) | **R**epudiation | RB-OBS-L3 |
+| API | Falsificação de requisição (CSRF, replay attacks) | **T**ampering | RB-SEC-H2, RB-SEC-A7 |
+| API | Esgotamento de recursos (flood de requisições) | **D**enial of Service | RB-SEC-H3, RB-SEC-A2 |
+| API | Vazamento de informação (stack traces, mensagens internas) | **I**nformation Disclosure | RB-SEC-H4, RB-OBS-L1 |
+| DB | Injeção de dados (SQL/NoSQL injection) | **T**ampering | RB-SEC-D1 |
+| DB | Exposição de dados sensíveis em repouso | **I**nformation Disclosure | RB-TRUST-T3 |
+| DB | Ausência de auditoria de acesso a dados PII | **R**epudiation | RB-TRUST-T4 |
+| FRONTEND | Injeção de script (XSS) | **T**ampering + **S**poofing | RB-SEC-F2 |
+| FRONTEND | Token exposto em armazenamento acessível por script | **I**nformation Disclosure | RB-SEC-F1 |
+| FILE | Execução de arquivo malicioso (malware upload) | **E**levation of Privilege | RB-SEC-FI1, RB-SEC-FI3 |
+| FILE | Esgotamento de disco (upload bombs) | **D**enial of Service | RB-SEC-FI2 |
+
+**Uso:** ao propor RB-SEC-NN ao usuário, referenciar a ameaça: *"RB-SEC-A2 (rate limiting) mitiga S1 — impostura de credencial por brute force identificada na sua arquitetura de login."*
+
+---
+
+## Parte III — 6 Dimensões de Qualidade
+
+### Sistema de Tiers
+
+| Tier | Nome | Significado | Risco se recusado |
+|------|------|-------------|-------------------|
+| 🔴 **Piso** | Floor | Ausente = falha ativa conhecida. Recusar = P0 no Accepted Risk Registry | P0 — bloqueia verify se `security_in_verify: true` |
+| 🟡 **Base** | Foundation | Ausente = risco operacional significativo. Recusar = P1 documentado | P1 — consta no SECURITY.md / CONCERNS.md |
+| 🟢 **Excelência** | Excellence | Diferencia sistemas bons de ótimos. Recusar = P2 ou mover para v2 sem fricção | P2 — registrado, não bloqueia |
+
+---
+
+### DIM-SEC — Segurança
+
+| ID | Critério | Ameaça mitigada | Tier |
+|----|----------|----------------|------|
+| RB-SEC-A1 | Senhas hashed com bcrypt ou argon2 (salt rounds ≥ 10) | S1 Credential Spoofing | 🔴 Piso |
+| RB-SEC-A2 | Rate limiting no login (≤ 10 tentativas / 15min / IP) | S1 Brute Force, D1 Flood | 🔴 Piso |
+| RB-SEC-A3 | Comparação timing-safe em credenciais e tokens | S1 Timing Attack | 🔴 Piso |
+| RB-SEC-A4 | Tokens de acesso em httpOnly cookie (nunca localStorage) | S2 Session Hijacking | 🔴 Piso |
+| RB-SEC-A7 | CSRF protection (double-submit ou SameSite=Strict) | T1 Request Forgery | 🔴 Piso |
+| RB-SEC-H1 | Security headers via Helmet ou equivalente | I1 Information Disclosure | 🔴 Piso |
+| RB-SEC-H2 | CORS restrito a origens explícitas (sem `*` em produção) | T1 Request Forgery | 🔴 Piso |
+| RB-SEC-H4 | Validação de schema em todas as entradas (Zod, Joi, etc.) | T1 Tampering, I1 Disclosure | 🔴 Piso |
+| RB-SEC-D1 | Queries parametrizadas — sem interpolação de input | T2 Injection | 🔴 Piso |
+| RB-SEC-F2 | Sanitização antes de `innerHTML` / `dangerouslySetInnerHTML` | T1 XSS | 🔴 Piso |
+| RB-SEC-FI1 | Validação de MIME no servidor para uploads | EP1 Malware | 🔴 Piso |
+| RB-SEC-H3 | Body size limit configurado | D1 Resource Exhaustion | 🟡 Base |
+| RB-SEC-A5 | Refresh token com rotação + revogação persistida | S2 Session Hijacking | 🟡 Base |
+| RB-SEC-FI3 | Nomes de arquivo sanitizados (sem path traversal) | EP1 Traversal | 🟡 Base |
+| RB-SEC-D3 | Erros sem expor stack trace ou mensagens internas | I1 Information Disclosure | 🟡 Base |
+| RB-SEC-FI2 | Limite de tamanho de arquivo configurável | D1 Disk Exhaustion | 🟡 Base |
+| RB-SEC-A6 | Expiração de sessão configurável via env | EP1 Stale Session | 🟢 Excelência |
+| RB-SEC-F3 | Links externos com `rel="noopener noreferrer"` | EP1 Tab Hijacking | 🟢 Excelência |
+
+*Critérios Piso que não se aplicam em MVPs demo sem usuários reais: RB-SEC-A1, RB-SEC-A5 — marcar `fora` com justificativa explícita.*
+
+---
+
+### DIM-RES — Resiliência
+
+Aplicar quando: qualquer dependência externa (API terceira, DB, serviço interno, fila).
+
+| ID | Critério | Padrão de resiliência | Tier |
+|----|----------|-----------------------|------|
+| RB-RES-1 | Timeout explícito em todas as chamadas externas (DB, HTTP, filas) | Timeout | 🔴 Piso |
+| RB-RES-2 | Comportamento definido quando dependência externa falha (fallback, erro amigável, degradação parcial) | Graceful Degradation | 🔴 Piso |
+| RB-RES-3 | Retry com backoff exponencial + jitter em operações transitórias | Retry | 🟡 Base |
+| RB-RES-4 | Circuit breaker em chamadas a serviços críticos (abre após N falhas consecutivas) | Circuit Breaker | 🟡 Base |
+| RB-RES-5 | Operações longas (> 2s) executadas de forma assíncrona (fila, job, evento) | Async Escape Valve | 🟡 Base |
+| RB-RES-6 | Idempotência garantida em operações críticas (pagamento, envio de email, criação de recurso) | Idempotency | 🟡 Base |
+| RB-RES-7 | Bulkhead: pool de recursos isolado por tipo de operação (leitura vs escrita, rápido vs lento) | Bulkhead | 🟢 Excelência |
+| RB-RES-8 | SLO definido: disponibilidade alvo (ex.: 99.9%) e latência p99 (ex.: < 500ms) | SLO | 🟢 Excelência |
+
+---
+
+### DIM-OBS — Observabilidade
+
+Aplicar quando: qualquer serviço com endpoints HTTP, jobs, ou processamento de dados.
+
+| ID | Critério | Pilar | Tier |
+|----|----------|-------|------|
+| RB-OBS-H1 | Endpoint `/health` ou `/api/health` retorna status 200 quando saudável | Health | 🔴 Piso |
+| RB-OBS-L1 | Logs estruturados (JSON) com nível, timestamp, request_id e contexto de negócio | Logs | 🔴 Piso |
+| RB-OBS-L2 | Erros críticos logados com stack trace + contexto suficiente para reproduzir | Logs | 🔴 Piso |
+| RB-OBS-L3 | Ações sensíveis logadas com user_id e timestamp (login, logout, mudança de permissão, deleção) | Logs + Audit | 🟡 Base |
+| RB-OBS-M1 | Métricas básicas expostas: latência de endpoint, taxa de erro, throughput | Metrics | 🟡 Base |
+| RB-OBS-M2 | Alerta definido para degradação acima do threshold (ex.: error rate > 1% por 5min) | Alerting | 🟡 Base |
+| RB-OBS-T1 | Request ID propagado em todos os serviços/chamadas de uma requisição | Traces | 🟢 Excelência |
+| RB-OBS-T2 | Tracing distribuído (OpenTelemetry ou equivalente) para caminhos críticos | Traces | 🟢 Excelência |
+| RB-OBS-D1 | Dashboard de golden signals: latência, tráfego, erros, saturação | Dashboard | 🟢 Excelência |
+
+---
+
+### DIM-TRUST — Confiança de Dados (LGPD / GDPR)
+
+Aplicar quando: qualquer dado pessoal coletado (nome, email, CPF, IP, localização, comportamento).
+
+| ID | Critério | Princípio legal | Tier |
+|----|----------|----------------|------|
+| RB-TRUST-T1 | Tabela de dados pessoais: campo, finalidade, base legal, quem acessa, tempo de retenção | Minimização + Finalidade | 🔴 Piso |
+| RB-TRUST-T2 | Somente campos estritamente necessários à finalidade declarada são coletados | Minimização | 🔴 Piso |
+| RB-TRUST-T3 | Dados sensíveis criptografados em repouso (campo ou disco) | Segurança | 🔴 Piso |
+| RB-TRUST-T4 | Acesso a dados PII logado com user_id e timestamp (auditoria de acesso) | Responsabilização | 🟡 Base |
+| RB-TRUST-T5 | Política de retenção automatizada: dados deletados ou anonimizados após N dias | Limitação de Retenção | 🟡 Base |
+| RB-TRUST-T6 | Capacidade de exportar todos os dados de um usuário (portabilidade LGPD Art. 18) | Portabilidade | 🟡 Base |
+| RB-TRUST-T7 | Capacidade de deletar completamente um usuário e seus dados (direito ao esquecimento) | Eliminação | 🟡 Base |
+| RB-TRUST-T8 | Pseudonimização de PII em ambientes de desenvolvimento/staging | Segurança | 🟢 Excelência |
+| RB-TRUST-T9 | Consentimento explícito registrado com timestamp e versão da política | Consentimento | 🟢 Excelência |
+
+*Se o sistema processa dados pessoais, RB-TRUST-T1 e RB-TRUST-T2 são Piso independente de outros domínios.*
+
+---
+
+### DIM-ACCESS — Acessibilidade e UX de Erro
+
+Aplicar quando: qualquer interface visível ao usuário final.
+
+| ID | Critério | Padrão | Tier |
+|----|----------|--------|------|
+| RB-ACC-W1 | Contraste mínimo 4.5:1 para texto normal, 3:1 para texto grande (WCAG 2.1 AA) | WCAG 2.1 AA | 🔴 Piso |
+| RB-ACC-W2 | Navegação completa por teclado (Tab, Enter, Esc em todos os fluxos críticos) | WCAG 2.1 AA | 🔴 Piso |
+| RB-ACC-E1 | Mensagens de erro em linguagem natural — sem códigos internos, stack traces ou jargão técnico | Error UX | 🔴 Piso |
+| RB-ACC-E2 | Estado de loading explícito em operações assíncronas (spinner, skeleton, texto) | Error UX | 🟡 Base |
+| RB-ACC-E3 | Estado de erro com ação de recuperação sugerida (retry, contato, próximo passo) | Error UX | 🟡 Base |
+| RB-ACC-W3 | Labels e ARIA em todos os campos e botões interativos | WCAG 2.1 AA | 🟡 Base |
+| RB-ACC-W4 | Imagens não decorativas com texto alternativo descritivo | WCAG 2.1 AA | 🟡 Base |
+| RB-ACC-E4 | Página de erro 404/500 com link de volta ao ponto seguro (home, dashboard) | Error UX | 🟡 Base |
+| RB-ACC-W5 | Foco visível em elementos interativos (outline customizado ou padrão visível) | WCAG 2.1 AA | 🟡 Base |
+| RB-ACC-W6 | Skip link para pular navegação repetitiva (acessibilidade para leitores de tela) | WCAG 2.1 AAA | 🟢 Excelência |
+
+---
+
+### DIM-OPS — Prontidão Operacional
+
+Aplicar quando: qualquer serviço que vai a produção ou será operado por outra pessoa.
+
+| ID | Critério | Categoria | Tier |
+|----|----------|-----------|------|
+| RB-OPS-S1 | Segredos exclusivamente via variáveis de ambiente — nunca hardcoded ou commitados | Secrets | 🔴 Piso |
+| RB-OPS-S2 | `.env.example` documenta todas as variáveis obrigatórias com descrição | Secrets | 🔴 Piso |
+| RB-OPS-D1 | Estratégia de deploy definida: como fazer deploy, rollback e smoke test | Deploy | 🟡 Base |
+| RB-OPS-D2 | Migrations de banco reversíveis (down migration definida para cada up migration) | Deploy | 🟡 Base |
+| RB-OPS-R1 | README com: pré-requisitos, como rodar localmente, como testar, variáveis necessárias | Docs | 🟡 Base |
+| RB-OPS-R2 | Runbook mínimo: o que fazer quando o serviço cai (quem acionar, como diagnosticar) | Runbook | 🟡 Base |
+| RB-OPS-D3 | Zero-downtime deploy ou janela de manutenção documentada para deploys com downtime | Deploy | 🟢 Excelência |
+| RB-OPS-D4 | Feature flag ou kill switch para desativar funcionalidade nova sem redeploy | Deploy | 🟢 Excelência |
+| RB-OPS-R3 | RTO / RPO definidos: quanto tempo de inatividade é aceitável, quanto dado pode ser perdido | Recovery | 🟢 Excelência |
+
+---
+
+## Parte IV — Accepted Risk Registry
+
+Todo item recusado pelo usuário **deve** ser registrado no registro de riscos aceitos — nunca silenciado.
+
+### Formato de entrada
+
+```
+| ID    | Critério recusado | Tier | Justificativa | Responsável | Data | Revisão |
+|-------|-------------------|------|---------------|-------------|------|---------|
+| AR-01 | RB-SEC-A2 (rate limiting) | Piso | MVP local sem exposição pública; revisitar em v2 | Eduardo | 2026-04-17 | Antes do deploy público |
+```
+
+### Onde registrar
+- Na seção **"Suposições e riscos"** do `SPEC.md`, como tabela `## Riscos Aceitos`
+- Itens com tier **Piso** recusados → também listados em `CONCERNS.md` com tag `[P0]`
+- Revisados obrigatoriamente na **Fase 5 de aprovação** — usuário confirma ciência de cada P0/P1 aceito
+
+### Regra de severidade no registry
+| Tier do item recusado | Severidade no registry | Impacto no verify |
+|----------------------|----------------------|-------------------|
+| Piso | P0 — risco crítico documentado | Bloqueia `verify_complete` se `security_in_verify: true` |
+| Base | P1 — risco operacional documentado | Aparece em SECURITY.md / CONCERNS.md |
+| Excelência | P2 — débito técnico consciente | Registrado, não bloqueia |
+
+---
+
+## Parte V — Quality Score
+
+Calculado ao final da Fase 3.5, antes de gerar o roteiro.
+
+```
+Quality Score = (Piso_aprovados / Piso_total × 60) + (Base_aprovados / Base_total × 40)
+```
+
+| Faixa | Significado | Ação |
+|-------|-------------|------|
+| 90–100 | Contrato de qualidade forte | Avançar; mencionar ao usuário |
+| 70–89 | Contrato sólido com lacunas documentadas | Avançar; destacar P1s aceitos |
+| 50–69 | Lacunas significativas — riscos operacionais relevantes | Avançar com alerta claro no SPEC |
+| < 50 | Qualidade insuficiente para produção | Apresentar ao usuário antes de avançar; sugerir revisão |
+
+**Regra de Piso:** se qualquer item Piso for recusado, o Quality Score é automaticamente exibido com `⚠ Piso incompleto` independente da pontuação total.
+
+---
+
+## Processo de elevação (Fase 3.5) — passo a passo
+
+```
+1. Executar Parte I (Detector de Arquitetura)
+   → Listar smells detectados; apresentar ao usuário antes dos checklists
+
+2. Executar Parte II (Derivação STRIDE)
+   → Mapear domínios detectados → ameaças concretas
+
+3. Para cada dimensão aplicável (SEC, RES, OBS, TRUST, ACCESS, OPS):
+   a. Filtrar itens já cobertos pelos A* da Fase 3
+   b. Propor itens restantes agrupados por Tier (Piso → Base → Excelência)
+   c. Para cada item Piso: referenciar a ameaça STRIDE ou smell que o motivou
+
+4. Apresentar ao usuário em bloco único:
+   - Smells detectados (se houver)
+   - Critérios por dimensão e tier (não todos de uma vez — agrupar por dimensão)
+   - Para cada item Piso, mencionar: "Este item mitiga [ameaça/smell] e sua ausência é risco P0"
+
+5. Aguardar decisão por dimensão (não item a item — reduz fricção)
+
+6. Incorporar aprovados na tabela da Fase 3 como R-RB-NN
+
+7. Registrar recusados no Accepted Risk Registry (Suposições e riscos do SPEC)
+
+8. Calcular e exibir Quality Score
+
+9. Se Quality Score < 50 ou Piso incompleto: apresentar resumo de riscos e confirmar com usuário antes de avançar
+```
+
+---
+
+## Detecção de domínios aplicáveis
+
+| Domínio | Ativa dimensões | Detectado quando |
+|---------|----------------|-----------------|
+| AUTH | SEC, OBS (audit), TRUST (se há dados pessoais) | Requisitos mencionam: login, logout, senha, sessão, JWT, token, autenticação |
+| API | SEC, RES, OBS | Stack inclui: Express, Fastify, Hono, NestJS, Flask, Django, Spring — ou há rotas HTTP |
+| DB | SEC, TRUST, OPS | Stack inclui: SQL, SQLite, PostgreSQL, MySQL, MongoDB, Prisma, Drizzle, Sequelize |
+| FRONTEND | SEC, ACCESS, OBS | Stack inclui: React, Vue, Angular, Svelte, Next.js — ou há interface web |
+| FILE | SEC, TRUST | Requisitos mencionam: upload, download, armazenamento de arquivos, S3, blob |
+| DADOS PESSOAIS | TRUST (Piso automático) | Requisitos mencionam: email, CPF, nome, endereço, telefone, localização, IP de usuário |
+| PRODUÇÃO | OPS | Requisitos ou contexto indicam deploy para ambiente acessível externamente |
+
+---
+
+## Regra de escopo mínimo
+
+Critérios marcados como Piso são **fortemente recomendados** mas o usuário tem autoridade final.
+Se recusar um Piso, registrar no Accepted Risk Registry com motivo — nunca forçar inclusão.
+O Quality Score e o registro de riscos garantem transparência sem impor; a decisão permanece do usuário.

package/oxe/workflows/references/workflow-runtime-contracts.json

@@ -606,9 +606,12 @@
         "global_lessons",
         "project_summary",
         "session_summary",
-        "phase_summary"
+        "phase_summary",
+        "lessons_metrics",
+        "spec"
       ],
-      "extraction_intent": "verification"
+      "extraction_intent": "verification",
+      "quality_contract_aware": true
     },
     "review-pr": {
       "reasoning_mode": "review",
@@ -715,9 +718,11 @@
         "codebase_overview",
         "codebase_integrations",
         "global_lessons",
-        "azure_inventory"
+        "azure_inventory",
+        "lessons_metrics"
       ],
-      "extraction_intent": "planning_input"
+      "extraction_intent": "planning_input",
+      "quality_contract_aware": true
     },
     "ui-review": {
       "reasoning_mode": "review",
@@ -777,6 +782,29 @@
       ],
       "extraction_intent": "verification"
     },
+    "verify-audit": {
+      "reasoning_mode": "review",
+      "question_policy": "none",
+      "output_contract": "findings",
+      "tool_profile": "review_heavy",
+      "confidence_policy": "explicit",
+      "required_artifacts": [
+        "state",
+        "spec",
+        "verify"
+      ],
+      "optional_artifacts": [
+        "session_summary",
+        "phase_summary"
+      ],
+      "extraction_intent": "verification",
+      "auditor_excluded": [
+        "plan",
+        "runtime",
+        "active_run",
+        "events"
+      ]
+    },
     "verify": {
       "reasoning_mode": "review",
       "required_artifacts": [

package/oxe/workflows/retro.md

@@ -77,6 +77,26 @@ Ao ler `LESSONS.md`, priorizar entradas com **`Frequência >= 2`** ou **`Impacto
    - Se existe: chamar `updateLessonMetric` com `{ cycle: "C-NN", verify_status: "<verify_complete|verify_failed>", saved_hours: <estimativa ou 0> }`.
    - Se não existe: criar nova entrada com `applied_cycles: ["C-NN"]`, `outcomes: [...]`, `success_rate: 1.0` (ou `0.0` se falhou), `status: "active"`, `deprecation_threshold: 0.5`.
    - Lições com `success_rate < 0.5` e ≥ 3 observações → marcar `status: "deprecated"` e registrar aviso no chat.
+8a. **Captura do Contrato de Qualidade** (se VERIFY.md contiver seção **Contrato de Qualidade**):
+    - Extrair Quality Score comprometido (da SPEC) e Quality Score realizado (do VERIFY).
+    - Extrair itens R-RB declined do Accepted Risk Registry da SPEC.
+    - Registrar em `lessons-metrics.json` na seção `quality_contracts` (criar arquivo se não existir, usando `oxe/templates/LESSONS-METRICS.template.json`):
+      ```json
+      {
+        "session": "<active_session ou 'default'>",
+        "cycle": "C-NN",
+        "date": "<YYYY-MM-DD>",
+        "quality_score_committed": <QS comprometido ou null>,
+        "quality_score_realized": <QS realizado>,
+        "floor_complete": <true|false>,
+        "approved_items": ["RB-SEC-A1", "..."],
+        "declined_items": [{ "id": "RB-X", "tier": "...", "reason": "..." }],
+        "gaps_p0": ["RB-SEC-A2"],
+        "verify_status": "<verify_complete|verify_failed>"
+      }
+      ```
+    - Se algum item R-RB Piso foi declined na spec E o verify registrou gap relacionado: criar lição com tipo `quality-contract`, Impacto: alto, instrução prescritiva sobre o critério específico.
+    - Se Quality Score realizado < comprometido em ≥ 10 pontos: criar lição com tipo `quality-contract` descrevendo o padrão de implementação não seguido.
 9. Atualizar **`.oxe/STATE.md`**: campo `last_retro: YYYY-MM-DD`.
 10. Responder no chat: ID do ciclo (C-NN), número de lições registradas, lição mais crítica em 1 frase, lições depreciadas (se houver), sugestão do próximo ciclo (`/oxe-scan` ou `/oxe-spec`).
 </process>
@@ -89,4 +109,5 @@ Ao ler `LESSONS.md`, priorizar entradas com **`Frequência >= 2`** ou **`Impacto
 - [ ] 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 para `resolvido`.
+- [ ] Se VERIFY.md contiver seção Contrato de Qualidade: `lessons-metrics.json` atualizado com entrada na seção `quality_contracts`.
 </success_criteria>

package/oxe/workflows/spec.md

@@ -13,10 +13,10 @@ 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>
-**Contrato de raciocínio:** aplicar `oxe/workflows/references/reasoning-discovery.md`. Antes de perguntar, explorar o que o repo e os artefatos já respondem; separar fatos, inferências e lacunas.
-
-**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
+<context>
+**Contrato de raciocínio:** aplicar `oxe/workflows/references/reasoning-discovery.md`. Antes de perguntar, explorar o que o repo e os artefatos já respondem; separar fatos, inferências e lacunas.
+
+**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.
 
@@ -34,8 +34,8 @@ Ler no início:
 - `.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
+- `.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.
 
@@ -88,9 +88,9 @@ 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?"
-- "A trilha depende de Azure e o inventário está incompleto. Quer sincronizar recursos reais antes de congelar os 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`)
@@ -127,6 +127,27 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 **Apresentar ao usuário para validação** antes de avançar para Fase 4. Se ajustar: atualizar tabela e repetir até aprovação.
 </fase_3_requisitos>
 
+<fase_35_elevacao_robustez>
+## Fase 3.5 — Elevação de Robustez (automática)
+
+**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`
+
+**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.
+
+**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 detectável (ex.: script CLI puro sem auth, sem HTTP, sem DB).
+</fase_35_elevacao_robustez>
+
 <fase_4_roteiro>
 ## Fase 4 — Roteiro
 
@@ -178,6 +199,7 @@ Percorrer esta lista de verificação:
 | 4 | **Conflito com stack:** algum requisito v1 pressupõe tecnologia ou capacidade que `STACK.md` indica ausente? (ex.: requer WebSocket mas stack usa REST puro) | Marcar como suposição explícita ou remover |
 | 5 | **Critérios vagos:** algum A* usa linguagem não-mensurável ("deve ser rápido", "interface amigável") sem métrica? | Refinar: "resposta < 200ms p95", "WCAG 2.1 AA" |
 | 6 | **Dependências implícitas:** algum requisito v1 pressupõe que outro requisito (v2 ou fora) já esteja implementado? | Tornar dependência explícita ou reordenar versioning |
+| 7 | **Elevação de robustez:** todos os domínios detectados (AUTH, API, DB, FRONTEND, FILE) tiveram R-RB-NN propostos ou explicitamente descartados com justificativa? | Se Fase 3.5 foi pulada sem justificativa, executar agora ou registrar como risco em "Suposições e riscos" |
 
 **Resultado obrigatório antes de avançar:**
 - **0 problemas** → avançar para Fase 5 normalmente.
@@ -222,23 +244,24 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 - Atualizar `STATE.md`: `phase: spec_ready`, próximo passo conforme escolha
 </fase_5_aprovacao>
 
-<process>
-1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
-2. Fazer uma exploração inicial do repo e dos artefatos antes da primeira rodada de perguntas. Consolidar internamente: fatos confirmados, inferências e lacunas.
-3. Aplicar `adaptive-discovery.md`: classificar a demanda, verificar se há capabilities úteis e se investigações anteriores reduzem incerteza.
-4. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
-5. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
-6. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
-7. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `ROADMAP.md` no escopo ativo.
-8. 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:`
-8b. **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.
-9. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
-10. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
-11. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
+<process>
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `OBSERVATIONS.md` do escopo ativo (verificar pendentes).
+2. Fazer uma exploração inicial do repo e dos artefatos antes da primeira rodada de perguntas. Consolidar internamente: fatos confirmados, inferências e lacunas.
+3. Aplicar `adaptive-discovery.md`: classificar a demanda, verificar se há capabilities úteis e se investigações anteriores reduzem incerteza.
+4. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
+5. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
+6. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
+6.5. **Fase 3.5 — Elevação de Robustez:** detectar domínios (AUTH/API/DB/FRONTEND/FILE); propor R-RB-NN não cobertos; aguardar decisão; incorporar aprovados na tabela antes de avançar.
+7. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases (incluindo R-RB aprovados); escrever `ROADMAP.md` no escopo ativo.
+8. 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:`
+8b. **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.
+9. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
+10. Atualizar **`.oxe/STATE.md`** global: `phase: spec_ready`, próximo passo e referência curta à sessão ativa quando existir.
+11. Marcar OBS incorporadas em `OBSERVATIONS.md` do escopo ativo se houver pendentes de impacto `spec`.
 </process>
 
 <success_criteria>
@@ -248,4 +271,5 @@ O resultado desta reflexão é **invisível ao usuário** — é trabalho intern
 - [ ] 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`.
 - [ ] Máximo 3 rodadas de perguntas utilizadas — não mais.
+- [ ] Fase 3.5 executada: domínios detectados tiveram R-RB-NN propostos, aprovados ou descartados com justificativa.
 </success_criteria>

package/oxe/workflows/verify.md

@@ -31,6 +31,7 @@ Se o usuário indicar uma tarefa (ex.: `T2`), focar só nela nas camadas 1–2;
 - **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.
+- **Camada QC — Quality Contract (automático quando SPEC.md contiver critérios R-RB):** se a SPEC.md do escopo resolvido contiver requisitos com ID `R-RB-NN` (gerados pela Fase 3.5 — Elevação de Robustez), executar a Camada QC conforme `<camada_qc_quality_contract>`. 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.
 </context>
 
@@ -103,6 +104,39 @@ Registrar em `VERIFY.md`: `Resultado de calibração | Confiança declarada | Re
 4. Usar esses artefatos como apoio para a seção de gaps e para a calibração do plano.
 </runtime_e_checkpoints>
 
+<camada_qc_quality_contract>
+**Camada QC — Contrato de Qualidade** (ativa quando SPEC.md contiver requisitos R-RB da Fase 3.5)
+
+**Objetivo:** verificar que os critérios de qualidade comprometidos na spec (R-RB aprovados como v1) foram efetivamente implementados — com o mesmo rigor de evidência aplicado aos critérios A*.
+
+**Execução:**
+
+1. Ler SPEC.md procurando requisitos com ID `R-RB-NN` e versão `v1` na tabela de requisitos.
+2. Localizar o **Accepted Risk Registry** da SPEC (seção "Suposições e riscos" ou "Riscos Aceitos") — anotar itens R-RB declinados.
+3. Para cada R-RB aprovado como v1, verificar implementação com evidência (Grep, Read, teste):
+
+   | ID R-RB | Critério (resumo) | Tier | Evidência | Implementado? |
+   |---------|-------------------|------|-----------|---------------|
+   | RB-SEC-A1 | Bcrypt salt≥10 | Piso | `grep bcrypt src/` → linha X | ✓ / ✗ |
+
+4. Calcular **Quality Score realizado:**
+   ```
+   QS_realizado = (Piso_implementados / Piso_aprovados × 60) + (Base_implementados / Base_aprovados × 40)
+   ```
+5. Comparar com Quality Score comprometido na spec (se registrado).
+6. Registrar na seção **Contrato de Qualidade** do VERIFY.md:
+   - Tabela de critérios R-RB (acima)
+   - Quality Score comprometido vs realizado
+   - Gap: itens aprovados como v1 mas não implementados
+
+**Severidade dos gaps:**
+- R-RB **Piso** não implementado → gap P0 → bloqueia `verify_complete` (mesma regra do security P0)
+- R-RB **Base** não implementado → gap P1 → registrar, não bloqueia
+- R-RB **Excelência** não implementado → informativo (estava em v2, não esperado)
+
+**Pulável apenas se:** SPEC.md não contiver nenhum R-RB-NN com versão v1.
+</camada_qc_quality_contract>
+
 <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. Resolver o context pack `verify` primeiro:
@@ -142,6 +176,7 @@ O `calibration_error` de cada dimensão = `|score declarado - resultado observad
 8b. **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.
 8c. **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.
 8d. **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.
+8e. **Camada QC — Quality Contract automático:** se SPEC.md contiver requisitos `R-RB-NN` com versão `v1`, executar o bloco `<camada_qc_quality_contract>` e adicionar seção **Contrato de Qualidade** ao VERIFY.md. R-RB Piso não implementados bloqueiam `verify_complete` — registrar `verify_failed` até serem resolvidos ou explicitamente aceitos como risco P0.
 9. **Só se todas as verificações relevantes passarem:** se `after_verify_draft_commit` não for `false`: acrescentar em **VERIFY.md** a seção **Rascunho de commit** — mensagem convencional (ex.: `feat:` / `fix:`) + bullets alinhados aos critérios **A*** e decisões **D-NN**; **não** incluir segredos.
 10. **Só se passou:** se `after_verify_suggest_pr` não for `false`: acrescentar **Checklist PR** — branch base, título sugerido, screenshots se UI, links a SPEC/PLAN/DISCUSS, testes executados.
 11. No chat, responder nesta ordem:
@@ -161,4 +196,5 @@ O `calibration_error` de cada dimensão = `|score declarado - resultado observad
 - [ ] Se existiu DISCUSS.md: tabela de Fidelidade de decisões preenchida sem divergências não documentadas.
 - [ ] Se `verification_depth: "thorough"` em config: `.oxe/VALIDATION-GAPS.md` produzido como parte deste verify.
 - [ ] Se `security_in_verify: true` em config: `.oxe/SECURITY.md` produzido; achados P0 resolvidos ou `verify_failed` registrado.
+- [ ] Se SPEC.md contiver R-RB v1: seção **Contrato de Qualidade** presente em VERIFY.md com Quality Score realizado; R-RB Piso não implementados tratados como gaps P0.
 </success_criteria>

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "oxe-cc",
-	"version": "0.9.2",
+	"version": "0.9.3",
 	"description": "OXE — spec-driven workflows in .oxe/; integrates with Cursor, GitHub Copilot, Claude, OpenCode, Gemini, Codex, Windsurf, Antigravity (npx)",
 	"license": "GPL-3.0",
 	"author": "",