🎛️ Control plane overview
O Guidance Control Plane é onde policies viram comportamento real. Quatro verbos: compile (transformar regras), retrieve (buscar policies relevantes em runtime), enforce (bloquear o que viola) e evolve (atualizar conforme aprendizado). Mental model: é o tribunal interno do swarm.
🔄Os 4 verbos do guidance
- •compile — pega YAML/DSL e produz regras executáveis
- •retrieve — busca policies aplicáveis ao contexto da operação
- •enforce — bloqueia, permite ou pede aprovação humana
- •evolve — propõe atualizações de policy baseadas em padrões observados
📊Por que control plane?
Sem control plane, você espalha checks pelo código. Com guidance, policies ficam declarativas e centralizadas. Auditoria fica trivial — você prova compliance mostrando o policy file, não rastreando 500 if-statements.
📜 Compile policies
Policies em Ruflo são escritas em YAML ou DSL e compiladas para regras executáveis. O compilador faz validação estática — detecta typos, dependências quebradas e contradições antes de produção. Política não compila = não vai pro runtime.
📝Exemplo policy YAML
policy: prevent-prod-delete
when:
operation: delete
environment: production
require:
approvals: 2
approvers: ["sre-team", "security"]
deny_message: "Delete em prod requer 2 aprovações"⚡Comando de compilação
npx claude-flow@v3alpha guidance compile \
--input ./policies/*.yaml \
--output ./dist/policies.wasm💡Validação estática
O compilador detecta: typos em campos, referências a aprovadores inexistentes, regras conflitantes (uma permite, outra nega o mesmo), policies que nunca podem ser satisfeitas. Você descobre na build, não em produção.
🚦 Enforce gates
Gates de enforcement são pontos de checagem em operações sensíveis. Pre-hooks param a operação se policy nega; post-hooks verificam pós-execução e podem disparar rollback. O agente que tenta deletar dados em produção bate no gate antes de qualquer query SQL ser executada.
✓ Pre-hooks bloqueiam
- ✓Deploy em produção sem aprovação
- ✓Delete de dados sensíveis
- ✓Mudança de schema sem migration plan
- ✓Outbound network call para domínio bloqueado
- ✓Spawn de agente sem permissão claims
✗ Sem gates você arrisca
- ✗Agente derrubando produção por engano
- ✗Vazamento de dados via API misconfigurada
- ✗Compliance violation em horário não-business
- ✗Spawn descontrolado de subagentes
- ✗Spending acima do budget
🔬 WASM kernel (Rust-powered)
O kernel de enforcement do guidance é escrito em Rust e compilado para WASM. Duas vantagens: performance (avaliação de policy em microssegundos) e sandboxing (policy maliciosa não pode comprometer o host). Mesmo que alguém injete código numa policy, ele roda confinado no WASM.
🚀Vantagens do WASM
- •Performance — avaliação de policy em <1ms típico
- •Sandbox — não acessa filesystem nem network sem permissão explícita
- •Cross-platform — mesmo binary roda em Linux, macOS, Windows
- •Determinístico — mesmo input produz mesmo output sempre
- •Type-safe — Rust impede categorias inteiras de bugs
📊Comparativo
Policy engine em JavaScript puro: ~50ms por avaliação, sem sandboxing real. Policy engine em WASM/Rust: ~0.5ms por avaliação, sandbox forte. Em hot paths com milhares de chamadas, a diferença é gigante.
🎯 Trust anchors
Trust anchors são pontos de referência confiáveis que ajudam o guidance a tomar decisões sob informação parcial ou ambígua. Se você só tem 60% de certeza sobre o que uma operação faz, o anchor define o comportamento default — preferir bloquear ou permitir, com qual peso temporal.
Uncertainty handling
Decisão sob dúvida
Quando confiança é baixa, o anchor decide: conservador (negar e pedir clarificação humana) ou permissivo (permitir com audit alto). Healthcare = conservador. Dev sandbox = permissivo.
Temporal reasoning
Time-aware policies
Anchors temporais permitem regras como "deploys só entre 9h-17h dias úteis", "delete em prod proibido 30 dias antes de auditoria", "rollback automático se métrica degrada por >5min".
Default bias
Quando policies conflitam
Se duas policies aplicáveis dão veredictos opostos, o trust anchor resolve. Geralmente: policy mais restritiva ganha (fail-safe). Configurável por contexto.
✅ Conformance kit
O Conformance Kit roda baterias de testes contra suas policies para validar HIPAA, SOC2 ou GDPR. Não é só checklist — é simulação ativa: gera operações sintéticas de violação e confirma que o guidance bloqueia. Se passa, você tem evidência objetiva para auditoria.
🧪Comandos de validação
Validar HIPAA:
npx claude-flow@v3alpha guidance conformance --suite hipaaValidar SOC2:
npx claude-flow@v3alpha guidance conformance --suite soc2Validar GDPR:
npx claude-flow@v3alpha guidance conformance --suite gdprGerar relatório PDF:
npx claude-flow@v3alpha guidance conformance \
--suite all \
--report pdf \
--output ./compliance-report.pdf💡Auditoria de verdade
Auditor não pede só documento — pede prova. O conformance kit gera relatório com casos de teste, inputs, outputs e veredictos. É evidência objetiva, não promessa.
📋Resumo do Módulo
Próximo Módulo:
3.7 - Multi-Provider Routing: 4 LLMs, 3 tiers, cost optimization