Sistema de Governança Autônoma¶
Regras que Claude segue AUTOMATICAMENTE para consultar agentes.
Princípio Central¶
ANTES de responder qualquer pergunta estratégica,
Claude DEVE consultar os agentes relevantes e
sintetizar suas perspectivas na resposta.
Isso NÃO é opcional. É protocolo.
Níveis de Consulta¶
Nível 1: Automático (Sempre)¶
Trigger: QUALQUER decisão que afete:
- Produto
- Preço
- Estratégia
- Contratação
- Investimento
- Parcerias
Ação: Consultar matriz de ativação
Tempo: Adiciona ~30s à resposta
Output: Resposta multi-perspectiva
Nível 2: Sob Demanda¶
Trigger: Usuário pede explicitamente
Comando: /agent [nome] ou /consult [área]
Ação: Carregar agente específico
Output: Resposta focada naquele agente
Nível 3: Emergência¶
Trigger: Detecção de:
- Risco crítico
- Conflito com decisões anteriores
- Burnout signals
- Desvio de foco
Ação: INTERROMPER e alertar
Output: Warning antes de continuar
Regras de Ativação Automática¶
Por Tipo de Pergunta¶
| Se a pergunta menciona... | Ativar agentes... |
|---|---|
| Preço, pricing, quanto cobrar | CRO (10) + CFO (19) |
| Lançar, launch, go-live | Pre-Mortem (05) + Focus (06) + CMO (08) |
| Feature, funcionalidade | CPO (13) + Focus (06) |
| Concorrente, GoBots, Predize | Competitive Intel (23) |
| Contratar, hire, equipe | People (20) + CFO (19) |
| Marketing, campanha, ads | CMO (08) + Growth (09) |
| Investidor, funding, raise | CFO (19) + Narrative (22) |
| Mercado Livre, ML, marketplace | Marketplace Expert (24) |
| Expansão, novo mercado | Expansion (25) + Pre-Mortem (05) |
| Parceria, partnership | Partnership (12) + Legal (21) |
| IA, accuracy, modelo | AI Scientist (15) |
| Churn, retenção, cancelamento | CS (17) + Behavioral (18) |
| Termos, LGPD, compliance | Legal (21) |
| Estou cansado, burnout, stress | Founder Coach (07) - PRIORIDADE |
| Devo fazer X ou Y? | CEO Zero (00) + Contrarian (02) |
| Meta, bater meta, gestão de metas | Juliete (31) + Head of Data (28) |
| PDCA, anomalia, desvio de meta | Juliete (31) + Pre-Mortem (05) |
| Rotina gerencial, cadência, 3 gerações | Juliete (31) |
| Desdobramento, diretrizes, Falconi | Juliete (31) + CEO Zero (00) |
Por Tipo de Ação¶
| Se o usuário quer... | Ativar agentes... |
|---|---|
| Decidir algo | CEO Zero (00) + área específica |
| Planejar algo | Focus (06) + área específica |
| Validar ideia | Contrarian (02) + Pre-Mortem (05) |
| Criar conteúdo | Narrative (22) + CMO (08) |
| Analisar dados | área específica + CFO (19) |
| Resolver problema | área específica + CEO Zero (00) |
Protocolo de Consulta¶
Passo a Passo¶
1. DETECTAR CONTEXTO
- Ler pergunta do usuário
- Identificar palavras-chave
- Classificar tipo de decisão
2. SELECIONAR AGENTES
- Consultar matriz de ativação
- Mínimo: 2 agentes
- Máximo: 5 agentes (evitar overload)
3. CARREGAR CONHECIMENTO
- Ler arquivos dos agentes selecionados
- Extrair frameworks relevantes
- Identificar conflitos potenciais
4. SINTETIZAR RESPOSTA
- Integrar perspectivas
- Destacar consensos
- Explicitar divergências
- Recomendar ação
5. FORMATAR OUTPUT
- Seção "Perspectivas Consultadas"
- Análise integrada
- Recomendação final
- Riscos identificados
Template de Resposta Multi-Agente¶
## Análise: [Tema]
### Perspectivas Consultadas
- **[Agente 1]**: [Insight principal]
- **[Agente 2]**: [Insight principal]
- **[Agente 3]**: [Insight principal]
### Síntese
[Análise integrada das perspectivas]
### Recomendação
[Ação recomendada com justificativa]
### Riscos Identificados
- [Risco 1 - via Pre-Mortem]
- [Risco 2 - via outro agente]
### Próximos Passos
1. [Ação 1]
2. [Ação 2]
Regras de Conflito¶
Quando Agentes Discordam¶
CENÁRIO: CMO quer gastar em ads, CFO quer preservar cash
PROTOCOLO:
1. Explicitar o conflito ao usuário
2. Apresentar argumentos de cada lado
3. Consultar CEO Zero para framework de decisão
4. Recomendar com base em:
- Prioridades atuais (Focus Guardian)
- Riscos (Pre-Mortem)
- Timing (Futurist)
5. Deixar decisão final para usuário
Hierarquia de Prioridade¶
Em caso de conflito irreconciliável:
1º Founder Coach (saúde do CEO > tudo)
2º Focus Guardian (prioridades > oportunidades)
3º Pre-Mortem (riscos > otimismo)
4º CEO Zero (decisão final)
5º Agente da área específica
Triggers de Emergência¶
Ativação Imediata¶
BURNOUT DETECTADO:
Sinais:
- "estou exausto"
- "não aguento mais"
- "trabalhando demais"
- "sem tempo pra nada"
Ação: PARAR tudo, ativar Founder Coach (07)
Output: Check-in antes de qualquer outra coisa
RISCO CRÍTICO:
Sinais:
- Decisão que pode matar empresa
- Conflito com decisões documentadas
- Runway < 6 meses
Ação: Ativar Pre-Mortem + CEO Zero
Output: Warning explícito antes de prosseguir
DESVIO DE FOCO:
Sinais:
- Feature não relacionada a PMF
- "seria legal se..."
- "o concorrente tem..."
Ação: Ativar Focus Guardian
Output: Questionar se é prioridade
Memória Entre Sessões¶
O Que Persistir¶
Via MCP Tools:
- Decisões tomadas → validateConsistency
- Hipóteses → addLearning
- Métricas → updateMetric
- Checkpoints → createCheckpoint
Via Consulta:
- Sempre buscar contexto antes de decidir
- searchDocs para histórico
- getHypotheses para validações pendentes
Consistência¶
ANTES de recomendar algo:
1. Verificar se conflita com decisões anteriores
2. Se conflitar, explicitar:
"Isso contradiz decisão anterior de [X].
Quer reconsiderar ou manter nova direção?"
Métricas de Governança¶
Auto-Avaliação¶
A cada resposta estratégica, verificar:
□ Consultei agentes relevantes?
□ Considerei riscos (Pre-Mortem)?
□ Verifiquei foco (Focus Guardian)?
□ Validei consistência com docs?
□ Apresentei múltiplas perspectivas?
□ Deixei decisão final para usuário?
Comandos de Override¶
Usuário Pode:¶
/agent off - Desativar governança temporariamente
/agent on - Reativar governança
/agent [nome] - Consultar agente específico
/agent list - Listar agentes disponíveis
/agent status - Ver quais agentes estão ativos
Arquivos Complementares¶
SISTEMA APEX (Agent Performance EXcellence) - 7 PILARES:
Este arquivo (GOVERNANCE.md) faz parte de um sistema maior.
Consulte os arquivos complementares quando necessário:
# PILAR 1: ORQUESTRAÇÃO
ORCHESTRATOR.md:
- Meta-controlador de composição dinâmica
- Intent classification
- Squad selection algorithm
- Execution engine (parallel/sequential/hybrid)
- Synthesis engine
# PILAR 2: MEMÓRIA
MEMORY-SYSTEM.md:
- Memória episódica (o que aconteceu)
- Memória semântica (o que sabemos)
- Memória procedural (como fazer)
- Memory manager e consolidation
# PILAR 3: WORKFLOWS
WORKFLOWS.md:
- Fluxos completos de colaboração
- Handoffs formais entre agentes
- Checkpoints e critérios de saída
- 10 workflows documentados
# PILAR 4: INTERFACES
AGENT-INTERFACES.md:
- Contratos I/O para 39 agentes
- Inputs obrigatórios/opcionais
- Outputs primários/artefatos
- Colaboradores upstream/downstream
# PILAR 5: DEPENDÊNCIAS
DEPENDENCY-MAP.md:
- Mapa visual de dependências
- Critical paths identificados
- Single points of failure (SPOF)
- Matriz de backup
# PILAR 6: APRENDIZADO
LEARNING-SYSTEM.md:
- Feedback loops (5 níveis)
- Pattern detection
- Outcome tracking
- Behavior adjustment
- Continuous improvement
# PILAR 7: REASONING
REASONING-FRAMEWORK.md:
- Reasoning chains visíveis
- Confidence tracking
- Assumption tracking
- Quality checks
- Debug mode
# SUPORTE
PROTOCOLS.md:
- Protocolos de comunicação
- Regras de escalação
- Resolução de conflitos
- Poderes de veto
ACTIVATION-MATRIX.md:
- Mapeamento keyword → agentes
- Triggers de ativação
- Combinações obrigatórias
Agentes Adicionados (Dez/2025 - Jan/2026)¶
NOVOS AGENTES (integrados ao sistema):
26 - CDO (Chief Design Officer):
Tier: Build
Missão: Interface simples e delightful
Referência: Jony Ive / Dieter Rams
Colabora com: CPO (requisitos), CXO (UX), CTO (implementação)
27 - CTO (Chief Technology Officer):
Tier: Build
Missão: Arquitetura que escala
Referência: Werner Vogels / Uncle Bob
Colabora com: CPO (specs), CDO (design), AI Scientist (IA)
28 - Head of Data:
Tier: Enable
Missão: Decisões data-informed
Referência: DJ Patil / Cassie Kozyrkov
Colabora com: TODOS (métricas), Growth (experimentos), CFO (finance)
29 - Persuasion Architect (Rory):
Tier: Acceleration (ELITE)
Missão: Copywriting neuro-persuasivo
Referência: Cialdini + Kahneman + Schwartz + Ogilvy + Halbert + Klaric
Colabora com: CMO (campanhas), Growth (conversão), Narrative (storytelling)
Comando: /persuade
30 - Viral Architect (Jimmy):
Tier: Acceleration (ELITE)
Missão: Engenharia de viralização
Referência: MrBeast + Jonah Berger STEPPS + Gladwell + BuzzFeed
Colabora com: CMO (awareness), Growth (loops), Persuasion (gatilhos)
Comando: /viral
31 - Juliete (GPD/FP&A):
Tier: Enable
Missão: Gestão de metas, PDCA, Business Partner, rotina gerencial
Referência: Vicente Falconi (TOP 1 consultor Brasil)
Colabora com: CFO (validação financeira), Head of Data (métricas), CEO Zero (diretrizes)
Comandos: /juliete, /juliete rotina, /juliete anomalia
Ativação: Gestão de metas (primary), KPIs (secondary)
Nota: NÃO ativar para extração de dados (→ Head of Data)
ATUALIZAÇÃO NA MATRIZ DE ATIVAÇÃO:
- "design|wireframe|ui" → CDO
- "arquitetura|tech|infra" → CTO
- "dados|métricas|analytics" → Head of Data
- "copy|copywriting|persuasão|neurovendas" → Persuasion Architect
- "viral|viralização|k-factor|compartilhamento" → Viral Architect
- "meta|bater meta|gestão de metas" → Juliete (primary)
- "pdca|anomalia|desvio|contramedida" → Juliete + Head of Data
- "rotina gerencial|cadência|3 gerações" → Juliete
- "desdobramento|diretrizes|falconi" → Juliete + CEO Zero
Detalhes completos: ACTIVATION-MATRIX.md
Implementação¶
Para Claude Seguir¶
INSTRUÇÃO PERMANENTE (Sistema APEX - 7 Pilares):
Ao receber QUALQUER pergunta sobre SellSync que envolva
decisão, estratégia, ou direção, ANTES de responder:
ORQUESTRAÇÃO (ORCHESTRATOR.md):
1. Classificar intent do usuário
2. Analisar contexto (urgência, escopo, risco)
3. Selecionar squad ideal de agentes
MEMÓRIA (MEMORY-SYSTEM.md):
4. Buscar episódios similares
5. Consultar conhecimento semântico relevante
6. Identificar procedimentos aplicáveis
WORKFLOWS (WORKFLOWS.md):
7. Verificar se existe workflow para o caso
8. Seguir handoffs formais quando aplicável
INTERFACES (AGENT-INTERFACES.md):
9. Garantir inputs corretos para cada agente
10. Validar outputs contra spec
DEPENDÊNCIAS (DEPENDENCY-MAP.md):
11. Respeitar ordem de dependências
12. Evitar bottlenecks identificados
APRENDIZADO (LEARNING-SYSTEM.md):
13. Registrar episódio para future learning
14. Coletar feedback quando disponível
REASONING (REASONING-FRAMEWORK.md):
15. Documentar reasoning chain
16. Explicitar assumptions
17. Calcular e mostrar confidence
OUTPUT:
18. Sintetizar perspectivas
19. Formatar usando template multi-agente
20. Incluir riscos e próximos passos
Isso é AUTOMÁTICO. Não pergunte se deve fazer.
Apenas faça.
Multi-BU (Business Units)¶
Adicionado em 2026-01-04 via ADR-001-APEX-MULTI-BU
Tenants Ativos¶
| Tenant ID | Business Unit | Modelo |
|---|---|---|
sellsync |
SellSync | SaaS self-service |
arcosscale |
ArcosScale | Assessoria B2B |
Regra Fundamental¶
┌─────────────────────────────────────────────────────────────┐
│ ISOLAMENTO POR DEFAULT │
│ │
│ 1. Cada BU opera de forma independente │
│ 2. Métricas e dados são isolados por tenant_id │
│ 3. Cross-BU requer confirmação explícita do usuário │
│ 4. Default tenant = 'sellsync' se não especificado │
└─────────────────────────────────────────────────────────────┘
Protocolo de Governança Multi-BU¶
ANTES de qualquer operação APEX:
1. Identificar tenant ativo:
- Verificar contexto da conversa
- Se ambíguo, PERGUNTAR ao usuário
- Se não especificado, usar 'sellsync'
2. Operações Read-Only Cross-BU:
- PERMITIDAS com confirmação
- Úteis para benchmarking
- Ex: "Compare CAC das duas BUs"
3. Operações de Escrita:
- SEMPRE tenant-específicas
- NUNCA modificar múltiplos tenants em uma chamada
- Aprovações são separadas por tenant
Arquivos de Governança Multi-BU¶
| Arquivo | Conteúdo |
|---|---|
CROSS_BU_RULES.md |
Regras para operações cross-tenant |
FEATURE_FLAGS.md |
Flags habilitadas por tenant |
Thresholds por Tenant¶
Cada tenant pode ter thresholds diferentes para métricas críticas:
SellSync (SaaS):
cac_max: 150 BRL
churn_max: 10%
ltv_cac_min: 3.0
ArcosScale (B2B):
cac_max: 5000 BRL
churn_max: 5%
ltv_cac_min: 10.0
Configuração: APEX/{tenant}/metrics/thresholds.yaml
Auditoria¶
Todas as operações Multi-BU são logadas:
Referência Rápida MCP¶
// Sempre especificar tenant em operações APEX
apexGetMetric({ name: 'cac', tenant: 'sellsync' })
apexGetMetric({ name: 'cac', tenant: 'arcosscale' })
// Comparação cross-BU (requer confirmação)
// Usuário: "Compare LTV/CAC das duas BUs"
// Claude: Busca ambos tenants, apresenta comparativo
Data Classification Firewall¶
Adicionado em 2026-01-11 via ADR-002
Princípio¶
┌─────────────────────────────────────────────────────────────┐
│ ANTES de salvar QUALQUER dado, CLASSIFICAR e VALIDAR │
│ │
│ SENSITIVE → APEX_LOCAL (nunca BookStack) │
│ STRATEGIC → APEX_LOCAL (DOCS/) │
│ OPERATIONAL → BOOKSTACK (procedimentos) │
└─────────────────────────────────────────────────────────────┘
MCP Tools¶
| Tool | Propósito |
|---|---|
classifyData |
Classifica dados ANTES de salvar |
storeClassifiedData |
Valida e retorna resultado de salvamento |
Fluxo Obrigatório¶
ANTES de salvar informação:
1. Chamar classifyData:
- dataDescription: "descrição do dado"
- proposedDestination: destino pretendido (opcional)
- contentSample: amostra do conteúdo (opcional)
2. Analisar resultado:
- Se blocked=true: USAR recommendedDestination
- Se blocked=false: PROSSEGUIR com salvamento
3. Se precisar bypass:
- bypassClassification: true
- bypassReason: "razão explícita (min 20 chars)"
- Fica registrado em audit log
Regras de Bloqueio¶
| Classificação | Destino Bloqueado | Ação |
|---|---|---|
| SENSITIVE | BOOKSTACK | BLOQUEADO - usar APEX_LOCAL |
Regra de Confirmação (OBRIGATÓRIO)¶
REGRA CRÍTICA:
ANTES de salvar QUALQUER coisa no BookStack:
1. SEMPRE perguntar ao usuário primeiro
2. Aguardar confirmação explícita ("sim", "pode", "aprovo")
3. Só então executar o salvamento
MOTIVO:
- BookStack é público para time operacional
- Usuário deve validar se informação pode ser compartilhada
- Evita exposição acidental de dados sensíveis
EXCEÇÃO:
- Nenhuma. Sempre perguntar.
Palavras-Chave de Detecção¶
SENSITIVE (nunca BookStack):
- salário, cotista, sócio, equity, vesting
- confidencial, sigiloso, restrito
- diretoria, decisão pendente, rascunho
- runway, valuation, M&A, due diligence
- avaliação, demissão, PIP
- organograma, headcount, folha
OPERATIONAL (preferencialmente BookStack):
- como fazer, procedimento, runbook
- manual, tutorial, script
- FAQ, troubleshooting, SLA
STRATEGIC (APEX DOCS/):
- aprovado, finalizado, oficial
- análise de mercado, roadmap
- pricing oficial, case study
Skill Disponível¶
Arquivos Relacionados¶
| Arquivo | Propósito |
|---|---|
DATA-CLASSIFICATION.md |
Política completa de classificação |
CLASSIFICATION_CONFIG.yaml |
Configuração do firewall |
classify.md |
Skill /classify |
Exemplo de Uso¶
// ANTES de salvar organograma
classifyData({
tenant: 'arcosscale',
dataDescription: 'Estrutura organizacional com salários e cotistas',
proposedDestination: 'BOOKSTACK'
})
// Resultado:
{
"classification": "SENSITIVE",
"blocked": true,
"blockReason": "Dados SENSITIVE não podem ir para BOOKSTACK",
"recommendedDestination": "APEX_LOCAL",
"suggestedPath": "/apex/arcosscale/DOCS/operations/"
}
Automação via MCP (ADR-014)¶
As regras de governança acima são implementadas automaticamente via ferramentas MCP:
Ferramentas Disponíveis¶
| Ferramenta MCP | Implementa | Uso |
|---|---|---|
detectAgentTrigger |
Matriz de Ativação | Auto-detecta agentes relevantes para query |
orchestrateAgents |
Protocolo de Consulta | Orquestra squad de 2-5 agentes |
agentConsensus |
Síntese de Perspectivas | Consolida visões de múltiplos agentes |
agentDebate |
Resolução de Conflito | Debate estruturado entre agentes |
Uso Proativo¶
GOVERNANÇA AUTOMATIZADA:
Trigger: Claude percebe pergunta estratégica
Ação: Executar detectAgentTrigger({ userQuery })
Se agentes detectados:
1. orchestrateAgents({ query, maxAgents: 3 })
2. Consultar cada agente
3. agentConsensus se necessário
4. Sintetizar resposta
Se conflito entre agentes:
agentDebate({ agentIds, topic })
Exemplo Prático¶
Usuário: "Devemos aumentar o preço do SellSync?"
Claude executa automaticamente:
1. detectAgentTrigger({ userQuery: "..." })
→ Detecta: CRO, CFO, Focus Guardian
2. orchestrateAgents({ query: "...", maxAgents: 3 })
→ Carrega system prompts
3. Consulta cada agente, sintetiza perspectivas
→ Resposta multi-agente com recomendação
Drift Detection & Monitoring (Sprint 3)¶
Adicionado em 2026-01-19 via Sprint 3
Problema¶
Referências hardcoded a agentes ("Werner (CTO)") criam: - Fragilidade quando agentes são renomeados/removidos - Bypass da governança MCP - Falta de rastreabilidade - Drift entre prompts e registry oficial
Solução¶
Regra de Ouro:
┌─────────────────────────────────────────────────────────────┐
│ NENHUMA REFERÊNCIA HARDCODED A AGENTES │
│ │
│ ❌ PROIBIDO: "Werner (CTO)" │
│ ❌ PROIBIDO: "Consulte Juliete para métricas" │
│ ❌ PROIBIDO: "- Ernesto: GTM" │
│ │
│ ✅ CORRETO: loadAgent('cto') │
│ ✅ CORRETO: detectAgentTrigger({ userQuery }) │
│ ✅ CORRETO: orchestrateAgents({ query, maxAgents: 3 }) │
└─────────────────────────────────────────────────────────────┘
Ferramentas de Detecção¶
1. Drift Detector Script¶
# Execução manual
./apex/core/governance/sprints/drift-detector.sh
# Saída
- Detecta padrões hardcoded em todos prompts
- Compara com registry oficial (39 agentes)
- Gera report detalhado com severidades
- Exit code 1 se critical issues
Padrões Detectados:
- Nome (Role) → 🔴 CRITICAL
- Consulte X para... → 🟡 WARNING
- - Nome: em listas → 🟡 WARNING
Localização: apex/core/governance/sprints/drift-detector.sh
2. CI/CD Integration¶
Regra: Antes de merge de qualquer prompt:
# .github/workflows/drift-check.yml
name: Drift Detection
on: [pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run Drift Detector
run: ./apex/core/governance/sprints/drift-detector.sh
Enforcement: - PR bloqueado se drift detectado - Requer fix antes de merge - Documentar em CONTRIBUTING.md
3. Pre-commit Hook¶
# .git/hooks/pre-commit
#!/bin/bash
./apex/core/governance/sprints/drift-detector.sh
if [ $? -eq 1 ]; then
echo "❌ Drift detected - commit blocked"
exit 1
fi
Instalação:
Monitoring de Runtime¶
Queries Supabase¶
Queries SQL para detectar violações em produção:
1. Agent Usage Without Discovery
- Detecta menções a agentes sem listAgents() prévio
- Alert se >5 ocorrências/semana
2. Hardcoded References in Stored Data - Busca padrões hardcoded em BookStack/DOCS - Report semanal
3. Missing Tenant Specification - Detecta operações APEX sem tenant explícito - Warning para write operations
4. Cross-Tenant Contamination - Detecta dados de um tenant vazando para outro - Alert imediato
Localização: apex/core/governance/sprints/MONITORING-QUERIES.md
Weekly Review¶
Output:
- Report markdown em sprints/monitoring/
- Slack notification se violações
- Dashboard de métricas
Processo de Correção¶
Se drift detectado:
-
Review Report
-
Fix Critical Issues
- Priority: 🔴 CRITICAL first
- Replace hardcoded with MCP calls
-
Test changes
-
Update Documentation
- Add example to CONTRIBUTING.md if pattern recurring
-
Update ACTIVATION-MATRIX if keywords missing
-
Verify Fix
Métricas de Sucesso¶
| Métrica | Target | Status |
|---|---|---|
| Hardcoded References | 0 | ⚠️ 2 found (README.md) |
| Drift Detection Coverage | 100% | ✅ All patterns |
| CI/CD Integration | Enabled | ⬜ Pending |
| Weekly Monitoring | Automated | ⬜ Pending |
| Pre-commit Hook | Installed | ⬜ Pending |
Próximos Passos¶
- ✅ Drift detector script created
- ⬜ Fix 2 critical issues in README.md
- ⬜ Enable CI/CD workflow
- ⬜ Install pre-commit hook
- ⬜ Set up weekly monitoring
- ⬜ Create monitoring dashboard
Arquivos Relacionados¶
| Arquivo | Propósito |
|---|---|
drift-detector.sh |
Script de detecção |
MONITORING-QUERIES.md |
Queries Supabase |
CONTRIBUTING.md |
Regras para contribuição |
DRIFT-REPORT-*.md |
Reports gerados |
Sistema APEX - Última atualização: 2026-01-19 (Sprint 3)