WHY - Por que existe núcleo
Sem gravidade comum, cada agente inventa contexto próprio. O núcleo evita 11 versões diferentes da mesma verdade.
GRAVITYshared truth
Onze agentes giram em torno de um núcleo só
Antes de chamar qualquer agente, entenda o que ele orbita. O núcleo é CLAUDE.md + CoreConfig + PRD. Os agentes são planetas: cada um com função, gravidade e órbita própria. Instalou AIOX, dá vontade de sair criando squad, PO, agente. Erro clássico: pedreiro com marreta tentando subir prédio de doze andares. Faltou o ambiente. Onze agentes não é sobre volume; é sobre clareza de função.
11agentes originais
6órbitas principais
1núcleo de gravidade
Mapa da aula
Use este mapa para entender a sequência da aula antes de entrar nos detalhes.
Legenda de coresO que cada cor sinaliza nesta aula
Núcleo de gravidadeCLAUDE.md, CoreConfig e PRD - o que toda órbita lê antes de responder
Lei da órbitaregra de autoridade exclusiva que separa um agente do outro
Execução do agenteato concreto que só o agente dono daquela órbita pode fazer
Gate de transiçãoportão que valida a passagem de um status da Story para o próximo
Erro de roteamentochamar o agente errado, sobrepor função ou pular gate
Como ler esta aula
1. Existe um núcleoCLAUDE.md + CoreConfig + PRD são a gravidade. Tudo orbita isso.
2. Cada agente é uma órbitaDevOps, PO, PM, Architect, Dev, QA: autoridade exclusiva, não redundância.
3. Saber qual chamar é metade do trabalhoErrar o agente é pedir o prédio pro pedreiro antes do canteiro existir.
4. Volume não é o pontoOnze agentes claros derrotam quarenta confusos.
O núcleo: CLAUDE.md + CoreConfig + PRD
Três arquivos ditam a gravidade do sistema. Sem eles coerentes, os agentes flutuam, alucinam, perdem contexto.
Pensa no AIOX como um planeta. Três arquivos no centro fazem a gravidade. Os agentes não são autônomos: cada um, ao ser chamado por barra, roda um greeting builder que puxa contexto desses três antes de responder. Coerentes, os agentes orbitam com previsibilidade. Quebrados, todos flutuam.
WHAT - O que compõe o núcleo
Três arquivos: CLAUDE.md (leis físicas), CoreConfig (regras sociais), PRD (escopo do projeto). Os três contam a mesma história.
FILES3 sources
HOW - Como o agente puxa
Chamada por barra dispara greeting builder. O builder lê o núcleo antes de qualquer resposta. Chamada por arroba só carrega o arquivo do agente.
INVOKEgreeting builder
1. CLAUDE.md: as leis da física
Regras universais que valem pra tudo que roda dentro.
regra universalvale pra todos os agentes
2. CoreConfig: as regras sociais
Ferramentas ligadas, stack, CodeRabbit enable true/false.
toolingstackflags
3. PRD: o mapa do projeto
O que será construído, com qual stack, com qual objetivo.
objetivostackescopo
barra dispara o greeting builder · arroba só carrega o arquivo
1
Chamada por barra
Dispara o greeting builder do agente.
2
Lê o núcleo
Puxa CLAUDE.md + CoreConfig + PRD.
3
Puxa o específico
DevOps pega ambiente, PO pega backlog, Dev pega code standards.
4
Só então responde
Contexto carregado antes da primeira palavra.
As seis órbitas principais
DevOps, PO, PM, Architect, Dev, QA: cada um com responsabilidade exclusiva. Saber qual chamar é metade do trabalho.
Cada agente é uma órbita com autoridade exclusiva. Não é redundância, é divisão de trabalho desenhada por quem já quebrou a cabeça antes.
[ORBITAL 01] · Guardião do Ambiente
DevOps
Mestre de obras: prepara o terreno, libera os outros
- 1Environment bootstrap: Escaneia o computador, instala Node, Python, Git, CodeRabbit, MCPs.
- 2Gestão de ambientes: Cuida de local, staging e production.
- 3Push, PR, CI/CD: Toda subida pro GitHub passa por ele: autoridade exclusiva de push.
- 4MCP setup: Configura os MCPs que dão superpoderes aos outros agentes.
[ORBITAL 02] · Validador de Story
PO: Product Owner
Bate o draft contra template e épico antes do Dev tocar
- 1Validate Story Draft: Compara a Story com o template canônico e o readme do épico.
- 2Decisão de prosseguir: Passou, libera pro Dev. Não passou, devolve pra reescrever.
- 3Guarda do backlog: Sabe o que tá pronto, em revisão ou precisa de retrabalho.
[ORBITAL 03] · Arquiteto do PRD
PM: Product Manager
Converte briefing em PRD, PRD em épicos
- 1Cria o PRD: Do briefing nasce o documento que dita objetivos, stack e escopo.
- 2Quebra em épicos: Do PRD nascem épicos; de cada épico nascem Stories.
- 3Mantém coerência: Mudou algo estrutural, ele dispara análise de impacto no PRD.
[ORBITAL 04] · Dono da Tech Stack
Architect
Dev propõe, Architect decide
- 1Document project: Em brownfield, gera o architecture.md pro analista e pro PM.
- 2Decisões de stack: Stack, banco, arquitetura: autoridade exclusiva dele.
- 3Review crítica: Valida contra ADRs e a arquitetura do PRD antes do push.
[ORBITAL 05] · Implementador
Dev
Executa a Story em três modos
- 1Modo yolo: Autônomo, sem perguntar. Pra Story bem definida em local seguro.
- 2Modo interactive: Balanceado e educacional. Padrão pra quem aprende o sistema.
- 3Modo preflight: Lê a Story inteira e pergunta antes de começar. Pra Story crítica.
- 4Self-healing CodeRabbit: Lint, types, segurança corrigidos antes de finalizar. Não é opcional.
[ORBITAL 06] · Quality Gate
QA
Aprovação técnica final antes do deploy
- 1Acceptance Criteria: Valida cada AC. Falhou, devolve pra fix com finding registrado.
- 2Testes e cobertura: Unitário, integração e contrato passam. Cobertura mínima respeitada.
- 3Risk escalation: Risco de segurança ou regressão escala antes do push.
O ciclo da Story: draft → done
Toda Story é uma entidade com status próprios. Cada transição tem um dono. Pular etapa é abrir buraco; trocar a ordem é gerar retrabalho.
Tudo no AIOX é entidade: Story, épico, agente, task, e toda entidade tem ciclo. O da Story é o coração do desenvolvimento. A etapa que muita gente pula é o PO validar o draft antes do Dev pegar. Eu pulava. Hoje não pulo mais.
José Carlos encontrou a analogia certa
A imagem do mestre de obras fez a turma entender por que DevOps vem antes dos outros agentes.
Começou comoConfusão sobre qual agente chamar primeiro.
VirouUma metáfora operacional: canteiro antes do prédio.
ProvaQuando a analogia entra, o aluno para de tratar DevOps como detalhe técnico.
LiçãoBoa didática troca nomenclatura por imagem concreta antes de voltar ao processo.
1TerrenoComputador sem ambiente configurado.
2Mestre de obrasDevOps monta o canteiro e libera os especialistas.
3PrédioPO, PM, Architect, Dev e QA trabalham sem improvisar infraestrutura.
- Quando a analogia entra, o aluno para de tratar DevOps como detalhe técnico.
- Boa didática troca nomenclatura por imagem concreta antes de voltar ao processo.
- Analogia boa reduz carga cognitiva sem empobrecer o processo.
- Terreno: Computador sem ambiente configurado.
- Mestre de obras: DevOps monta o canteiro e libera os especialistas.
- Prédio: PO, PM, Architect, Dev e QA trabalham sem improvisar infraestrutura.
@sm → @po → @dev → @qa → done · depois @devops faz o deploy
1
draft
@sm cria via create-next-story a partir do épico aberto.
2
ready
@po valida o draft (Validate Story Draft) e move para ready. Gate crítico antes do Dev pegar.
3
in_progress
@dev pega a Story ready e implementa em yolo, interactive ou preflight.
4
in_review
@qa move para in review, roda Quality Gates + CodeRabbit e faz sign-off técnico.
5
done
@qa aprova → done. Done fecha o ciclo da Story (não é deploy).
6
deploy (ciclo separado)
@devops cria PR, roda CodeRabbit, executa CI/CD e faz merge. É outro ciclo, fora do status da Story.
Volume de agentes não é o ponto
Onze agentes bem definidos derrotam quarenta agentes confusos. O critério é necessidade, não sofisticação.
Eu criei vinte e oito copywriters aqui dentro porque minha operação precisava. Mas o critério foi necessidade, não volume. Mais agente sem responsabilidade exclusiva é mais confusão, não mais capacidade.
O que volume de agentes NÃO resolve
- Sobreposição de função: dois agentes brigando pela mesma decisão.
- Contexto disperso: ninguém é dono claro da transição.
- Push sem gate: qualquer um sobe código, ninguém valida.
- Sofisticação de fachada: quarenta agentes pra parecer maduro.
O que clareza de responsabilidade força
- Autoridade exclusiva: só DevOps faz push, só Architect decide stack.
- Delegação constitucional: quem propõe não é quem aprova.
- Ciclo previsível: cada status da Story tem um único dono.
- Criar novo agente só com necessidade real provada.
Qual agente tem autoridade para a tarefa que você quer fazer?
Antes de digitar, decida a órbita. Errar o agente é o erro mais caro do começo.
DevOps
É preparar ambiente, push, PR ou deploy?
action
Architect
É decisão de stack, banco ou arquitetura?
bench
↓ ↓ ↓
PO
É validar a Story antes do Dev pegar?
signal
↓ ↓ ↓
Dois agentes parecem igualmente donos da tarefa?
Se parecem, você ainda não entendeu a fronteira de autoridade: releia as seis órbitas.
Chame o DevOps: guardião exclusivo do ambiente e do push.É preparar ambiente, push, PR ou deploy?
Architect decide. Dev propõe, não decide sozinho.É decisão de stack, banco ou arquitetura?
PO valida draft → ready. Não pule esse gate.É validar a Story antes do Dev pegar?
A analogia do José Carlos: pedreiro vs mestre de obras
Um aluno traduziu o sistema numa imagem que vale mais que dez slides técnicos.
Um aluno chamado José Carlos desenhou no whiteboard a melhor analogia da aula. "Quando a gente instala AIOX, quer sair criando squad, criando PO. Mas é como pedreiro com marreta e carrinho de mão tentando subir prédio de doze andares. Faltou o ambiente." "DevOps é o mestre de obras. Antes de subir o prédio, ele analisa o terreno, prepara o canteiro, traz andaime, monta elevador de carga." No AIOX isso vira o bootstrap: o DevOps escaneia teu computador, configura tudo, e só aí libera os outros pra trabalhar. PO, PM, Architect, Dev, QA são os pedreiros especialistas. Sem o mestre de obras montando o canteiro primeiro, nenhum sobe um andar. Por isso o primeiro comando que você dá no AIOX é chamar o DevOps pro environment bootstrap.
o canteiro vem antes do prédio
1
Terreno vazio
Computador recém-instalado, nada configurado.
2
Mestre de obras chega
Você chama o DevOps pro environment bootstrap.
3
Canteiro montado
Node, Python, Git, CodeRabbit, MCPs prontos.
4
Pedreiros liberados
PO, PM, Architect, Dev, QA sobem o prédio andar por andar.
Glossário rápido
Sete termos pra fixar antes da próxima aula.
Agente orbital
Agente que gira em torno do núcleo CLAUDE.md + CoreConfig + PRD e puxa contexto via greeting builder.
Núcleo de gravidade
CLAUDE.md (leis), CoreConfig (regras do projeto) e PRD (escopo). Quebrou um, todos perdem direção.
Environment bootstrap
Primeira tarefa do DevOps: escaneia o computador, valida Node, Python, Git, CodeRabbit.
Ciclo da Story
draft → ready → in_progress → in_review → done. Cada transição tem um dono.
Greeting builder
Script que roda quando o agente é chamado por barra. Puxa o mínimo de contexto antes da resposta.
Self-healing loop
Ciclo do Dev com CodeRabbit CLI: lint, types e segurança corrigidos antes da Story sair de in_progress.
Onze agentes originais
Conjunto canônico do AIOX. Criar mais é legítimo com necessidade real, não pra parecer elaborado.
Portão da aulaVocê entendeu quando consegue olhar para uma tarefa e dizer qual agente tem autoridade, qual contexto ele puxa e qual transição ele deve mover.
Prática: escolha o agente certo
Pegue uma tarefa real e roteie para a órbita correta antes de executar.
Sequência para rotear uma tarefa ao agente certo
Use antes de digitar qualquer pedido: decida a órbita primeiro, execute depois.
descrever tarefa→classificar domínio→escolher órbita→nomear o gate→executarDescrever— Escreva a tarefa em uma frase concreta.Classificar— Ambiente, produto, arquitetura, código, qualidade ou deploy?Órbita— Escolha o agente com autoridade exclusiva: DevOps, PO, PM, Architect, Dev ou QA.Gate— Diga qual portão fecha a tarefa antes de chamar de pronta.
Exemplo preenchido: 'quero migrar o banco para Supabase'
TarefaMigrar Postgres self-hosted para Supabase no projeto X.
DomínioArquitetura. Decisão de stack + banco + RLS policies. Não é só código.
Agente dono@architect decide a stack e a estratégia de migração. @db-sage executa as migrations. @devops faz o deploy. @dev não decide isso sozinho.
Sequência@architect propõe ADR -> @db-sage desenha schema + RLS -> @dev implementa client -> @qa valida -> @devops faz push e deploy.
GateADR aprovado + migration testada em staging + RLS validada + zero downtime documentado. Só depois @devops promove pra prod.
Teste rápidoSe dois agentes parecem igualmente responsáveis, você ainda não entendeu a fronteira de autoridade.
- Tarefa: Escreva uma tarefa que você quer fazer no AIOX esta semana.
- Domínio: Classifique o domínio: ambiente, produto, arquitetura, código, qualidade ou deploy.
- Agente: Escolha o agente com autoridade exclusiva para esse domínio.
- Gate: Diga qual gate precisa passar antes da tarefa ser considerada pronta.
Bloco de código: roteamento de agente
Use este mapa antes de chamar qualquer agente por impulso.
01tarefa:02dominio: "ambiente | produto | arquitetura | codigo | qualidade | deploy"03agente_dono: "@devops | @pm | @architect | @dev | @qa"04gate: "qual prova fecha a tarefa?"05nao_chamar: "agentes que só opinam, mas não têm autoridade"