stack-RFC-016 — Koder Governance Plane (norte)

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

Status: ACCEPTED 2026-06-11 (owner) — como NORTE. Esta RFC não autoriza construir o produto; ela fixa a direção e o requisito de extraibilidade. Proveniência: visão formulada pelo owner em mensagem de voz (2026-06-11 18:13, thread t24 do koderrootbot — "abstrair mais um nível: contas e orgs criando as próprias regras, até regras para criação de regras"), veredito t24 ("formalizar como norte, não construir agora"), ratificada via /k-arch→/k-go (variante c) na sessão do notebook.

1. A visão, nomeada

Governance-as-Code para trabalho conduzido por IA — um governance plane: o tenant declara regras (e meta-regras), os agentes são conduzidos proativamente a cumpri-las (injeção just-in-time, não só bloqueio reativo), e o gate determinístico dá o veredito. O diferencial sobre a categoria existente (OPA/Rego, "AI guardrails"): a dupla condução + camada constitucional (regras sobre quem/como autora regras), que nenhum dos dois lados oferece junto.

As três camadas já têm protótipo rodando dentro da Stack — este produto é a extração de um padrão que já nos governa (Meta First, princípio #1):

2. Por que norte e não produto (timing)

Regra-dos-3 (stack-principles §1, resolução do conflito Meta-First×YAGNI): hoje há 1 consumidor real (a própria Koder). Crescer/Vivver são os consumidores 2 e 3 — por isso a fase 2 vem antes de qualquer externalização. Construir tenancy de produto agora seria abstração prematura; não fixar a extraibilidade agora seria a decisão barata-hoje-cara-depois que a D9 veta. O norte custa este documento; o rewrite evitado custaria meses.

3. Requisitos normativos (valem JÁ, para todo incremento interno)

• R1 (extraível por construção). Toda peça nova da máquina de governança

  (registry, avaliador, hook, política de gates) é construída sem dependência hard de paths/nomes Koder no motor — conteúdo Koder entra como dado.

• R2 (o seam é a linguagem). A fronteira motor↔conteúdo é exatamente a

  fronteira do Kanon (RFC-015): o motor avalia Kanon; o que é Koder-específico vive nas regras, nunca no avaliador. Mudanças que borrem esse seam exigem revisão desta RFC.

• R3 (constitucional generalizável). Toda regra de hierarquia nova segue o

  shape de 3 tiers (plataforma define o teto → org autora dentro dele → time/projeto aperta, nunca afrouxa) — o invariante da RFC-003 é o caso 1.

4. Inventário completo do levantamento de 2026-06-11 (memória durável)

Para que nada do arco OpenSpec→Governance Plane se perca (pedido explícito do owner por voz, thread t25), o mapa integral: A1→esta família de RFCs · A2A3A4 → RFC-014 fases 1–3 (tickets abertos) · B1+C1 → RFC-015 (fundidos) · C2–C5 → RFC-015 fases 2–5 (tickets abertos) · D2 → ticket aberto (proveniência because:) · D1D3D4 → deferidos, listados na RFC-014 §5 · E1 → esta RFC (fase 0, done) · E2/E3 → fases 2–3 desta RFC. Relatório-fonte: history repo do koderrootbot (dm/6397822540, 2026-06-11) + transcript t25.