Spec-adherence harness — trigger registry as SSOT, just-in-time spec injection, and gates with a false-positive budget

Document format reference: meta/docs/stack/policies/document-format.kmd

Status: ACCEPTED 2026-06-11 (owner). Proveniência da ratificação: arco OpenSpec→Governance Plane de 2026-06-11 (threads t19–t25 do koderrootbot, preservadas em meta/context/backlog/done/745/746/747 + history repo) → deliberação /k-arch na sessão do notebook → owner /k-go (variante c).

1. Contexto e problema

A Stack tem specs/policies maduras e uma tabela "ação → leia a spec" no CLAUDE.md — mas a tabela é 100% consultiva. A aderência depende de a IA ler e escolher cumprir; sob pressão de contexto, ela escorrega. Evidência recorrente: a landing do Kodix shipou fora da spec de responsividade; cortesias de sessão corrigindo facets/frontmatter inválidos que quebravam builds repo-wide; o incidente t26 (deploy matou task em voo porque a regra de drain era memória, não gate). O dia 2026-06-11 consolidou o diagnóstico: o gap é enforcement e condução determinística, não falta de especificação.

Há hoje DUAS camadas de condução que funcionam e uma que vaza:

2. Decisão

Três movimentos, nesta ordem de valor:

1. Provar o padrão na dor real (fase 1): gate de responsividade de landing

   que reprova build — converte o post-mortem do Kodix em regressão estrutural.

2. SSOT de gatilhos (fase 2): registries/spec-triggers.kmd estruturado;

   o CLAUDE.md renderizado a partir dele (nunca editado à mão nessa seção — drift entre registry e render é CI fail). É o mesmo registry que alimenta o hook (fase 3) e, depois, o avaliador Kanon (RFC-015).

3. Injeção just-in-time (fase 3): o hook PreToolUse injeta a spec na hora

   da ação. Para IA, prevenir na ação custa menos que pegar no CI — mas o hook é guia (não-bloqueante, Claude-Code-only); os dentes ficam no gate.

3. Requisitos normativos

• R1 (SSOT). Um gatilho ação→spec existe em exatamente UM lugar: o

  trigger-registry. Render no CLAUDE.md é artefato derivado.

• R2 (subsunção, não acréscimo). Nenhum mecanismo novo de condução além de:

  registry→{render, hook, avaliador} e broadcast-alerts. Três mecanismos independentes de "regra→sessão" é o anti-padrão que esta RFC elimina.

• R3 (budget de falso-positivo). Todo gate block declara um budget de FP

  (default: 2 FPs confirmados / 30 dias). FP confirmado = override registrado cuja justificativa a triagem aceita.

• R4 (escape hatch auditado). Todo gate block tem override de 1 comando

  que registra ator+motivo+diff em log versionado. Override silencioso (--no-verify cru) em path coberto é, ele próprio, drift detectável.

• R5 (demoção automática). Gate que estoura o budget é demovido a warn

  automaticamente e abre ticket de recalibração no componente dono. Gate ruim ensina cultura de bypass — demoção mantém a confiança no conjunto.

4. Não-objetivos

Construir o produto de governança multi-tenant (RFC-016 fases 2–3); criar a linguagem de predicados (RFC-015 — esta RFC consome, não define).

5. Inventário deferido (memória do levantamento t25 — não abrir tickets ainda)

• D1 lifecycletemporal de spec (supersedestransitional_until/expires

  unificado com fires_on dos notices) — candidato a fase futura da RFC-013/014.

• D3 obrigações por matriz de variante (surface×target×form-factor).
• D4 parametrização/herança das 6 landing-specs (reuse-first nas próprias specs).

Fase 3b — action-aware (bash_patterns)

Emenda 2026-06-27: o JIT inject (jit-spec-inject.sh) passou a casar tambem comandos Bash via campo bash_patterns: no registry, alem de paths:. Fecha o quadrante das regras COMPORTAMENTAIS pos-acao (ex.: deploy-feedback — emitir URL clicavel apos publish) que nenhum path representa. Mesmo hook, mesmo registry, fail-open (RFC-014 R2: nada paralelo). Primeiro caso registrado: deploy-feedback-url-clicavel. settings.json matcher: +Bash.