Parte 2 de 4. Mapeia como o framework Synkra AIOX usa os
mecanismos nativos do harness Claude Code — CLAUDE.md,
rules/, agents/,
hooks/, skills/,
commands/ — para produzir um sistema multi-agente com
constituicao, quality gates e lifecycle rules. Evidencia file:line ao lado de cada afirmacao.
Agent/Domain:nome por dominio
O AIOX (framework Synkra) nao
e um fork do Claude Code. Nao reimplementa o loop de ferramentas, nao substitui o streaming,
nao toca no sistema de compactacao. Ele faz algo mais humilde, e por isso mais interessante:
escreve arquivos nos lugares onde o harness ja le por conta propria.
CLAUDE.md, .claude/rules/*.md,
.claude/agents/*.md, .claude/hooks/*.cjs,
.claude/skills/*/SKILL.md, .claude/commands/**/*.md
— tudo isso sao pontos de extensao publicos do harness, documentados pela Anthropic. O AIOX
preenche cada um com uma camada constitucional, de personas e de quality gates.
A analogia mais direta: se o harness e o kernel que expoe syscalls (tool calls, stream events, compaction hooks), o AIOX e o userland — init, policies, PAM, cgroups e editorial style guide, tudo empacotado num “sistema operacional editorial”. Ha uma constituicao (Art. I--VIII), um due process de amendments, uma matriz de autoridade por agente, hooks que funcionam como seccomp filters (exit 2 = syscall deny), e rules que funcionam como environment variables carregadas sob demanda por path-matching.
Nada aqui e magico. Cada peca e um arquivo que ja esta num path que o harness respeita. A inteligencia e a composicao: quais arquivos, em quais paths, com quais severidades, enforced por quais hooks. Essa parte descasca cada camada.
Parte 1 cobre o harness cru (como o Claude Code decide o que ler, como invoca tool calls, como compacta contexto). Parte 3 traz estudos de caso. Parte 4 faz a critica: onde AIOX paga custo, onde repete o harness sem precisar, onde a abstracao vaza. Esta parte (2) so descreve o que o AIOX E, com evidencia no repositorio.
A Constituicao do AIOX vive em
.aiox-core/constitution.md v1.3.0. Sao sete principios numerados em
romanos (I, II, III, IV, V, VII, VIII — Art. VI foi removido no passado, explicando o gap),
cada um com uma severidade formal e um gate nominal que o enforca. A mesma tabela aparece
como contrato no .claude/CLAUDE.md do projeto, o que fecha o loop: o
harness ingere CLAUDE.md como memoria permanente; o CLAUDE.md aponta pra constituicao; a
constituicao aponta pros gates.
| Art. | Principio | Severidade | Gate real? | Onde |
|---|---|---|---|---|
| I | CLI First | NON-NEGOTIABLE | Sim | dev-develop-story.md |
| II | Agent Authority | NON-NEGOTIABLE | Sim | agent definitions + l1-boundary-guard.cjs |
| III | Story-Driven Dev | MUST | Sim | dev-develop-story.md + story-completeness-guard.cjs |
| IV | No Invention | MUST | Sim | spec-write-spec.md |
| V | Quality First | MUST | Sim | pre-push.md + pre-commit-verification-gate.cjs |
| VII | Verify Before Report | MUST | Sim | independent-verify.md (SDC Phase 3.5) |
| VIII | Agent Lifecycle | MUST | Sim | agent-lifecycle-guard.cjs (PostToolUse) |
“Apenas @devops pode executar git push
para remote... Nenhum agente pode assumir autoridade de outro.” Esse paragrafo vira
configuracao nos arquivos de cada agente (.claude/agents/*.md) e
tambem vira check nos hooks de boundary. O harness Claude Code, puro, nao sabe disso. O AIOX
adiciona o check.
Violar um NON-NEGOTIABLE = hook retorna
exit 2 pro harness, que aborta a tool call e mostra o
stderr no UI. E o mecanismo nativo do Anthropic (PreToolUse deny), so que o AIOX
aponta ele pra regras constitucionais nomeadas.
Hook exit 2. Tool call abortada. Exemplo:
escrita em .aiox-core/core/ sem amendment ratificado.
Hook exit 0 + mensagem no stderr.
Tool call prossegue, mas o usuario/agente ve o alerta. Exemplo: edicao em L2 sem amendment.
Reportado em relatorios / logs. Nao toca o fluxo. Exemplo: diminuicao de cobertura de testes sem falhar build.
Uma das decisoes de design mais carregadas do AIOX: ele nao trata “codigo do framework”
vs “codigo do usuario” como uma distincao social (convencao, review, code review). Trata
como tabela de paths em quatro camadas, cada uma com regra de mutabilidade
propria. Um hook lê o file_path de cada
Write/Edit e decide antes da escrita se
e permitido.
Isso e o equivalente a read-only filesystem mounts num container: voce nao precisa
convencer ninguem de que nao deveria editar /lib/libc.so; o sistema
simplesmente nao deixa.
| Camada | Mutabilidade | Paths | Enforcement |
|---|---|---|---|
| L1 Core | NEVER | .aiox-core/core/ (todos subdirs por padrao), constitution.md, bin/ |
l1-boundary-guard.cjs → exit 2 |
| L2 Templates | NEVER | .aiox-core/development/{tasks,templates, checklists,workflows} |
l1-boundary-guard.cjs → exit 0 + WARN |
| L3 Config | Restricted | .aiox-core/data/, core-config.yaml | convencoes + amendment |
| L3 Exception | Restricted | .aiox-core/core/execution/ | AMA-001 + dual approval |
| L4 Runtime | ALWAYS | docs/stories/, packages/, squads/, tests/, .aiox/agent-customizations/ |
livre |
l1-boundary-guard.cjs roda como PreToolUse
no matcher Write|Edit. Ele normaliza o
file_path recebido via stdin (JSON), decide se e L1, L2 ou livre, e
checa dinamicamente se algum amendment ratificado cobre o path.
// .claude/hooks/l1-boundary-guard.cjs:124-143 (isL1Protected) function isL1Protected(filePath) { const normalized = filePath.replace(/^\//, "").replace(/^\.\//, ""); // .aiox-core/core/* is L1 by default if (normalized.startsWith(L1_CORE_PREFIX)) return true; // constitution.md is L1 if (normalized === CONSTITUTION_PATH) return true; // bin/ is L1 if (normalized.startsWith(BIN_PREFIX)) return true; return false; }
Quando o arquivo e L1 e nao ha amendment, a saida e um JSON com
result: "block" e uma mensagem explicando qual amendment criar:
// :262-267 const msg = JSON.stringify({ result: "block", reason: `[L1-Guard] BLOCKED: ${relativePath} is in L1 Core (NEVER mutability). No RATIFIED amendment found for this path. Create an amendment in .aiox/amendments/ and get dual approval (@aiox-master + @architect).`, }); process.stdout.write(msg); process.exit(0);
Curioso: a saida usa exit 0 + JSON result:"block", nao exit 2 direto. Essa e a forma estruturada que o harness Claude Code recentemente passou a preferir — permite razoes estruturadas ao inves de stderr cru. Parte 1 desta serie explica o protocolo.
Claude Code expoe um mecanismo primitivo: o Agent tool (tambem
chamado Task). Voce chama com subagent_type: "dev"
e o harness busca um arquivo com aquele name em
.claude/agents/. Ponto. E so isso que o kernel entrega.
O AIOX preenche esse diretorio com 20 personas, cada uma um character envelope fino
apontando pra um arquivo “volumoso” em .aiox-core/development/agents/
com tasks, constraints, workflow. A separacao e intencional: o
.claude/agents/ fica pequeno (o harness carrega no spawn), e o
development/agents/ carrega sob demanda.
// .claude/agents/dev.md:1-26 --- name: dev description: | Full Stack Developer (Pickle Rick). Use for code implementation, debugging, refactoring, and development best practices context: fork agent: dev model: opus --- ## Mission: $ARGUMENTS You are the dev wrapper. 1. Read `.aiox-core/development/agents/dev.md` for commands, constraints, and workflow rules. 2. Apply the Character Envelope below as the authoritative cosmetic voice layer... 3. Generate and show greeting via `node .aiox-core/development/scripts/generate-greeting.js dev`. 4. Execute the mission in character, following `.aiox-core/constitution.md`. 5. Do not invent requirements beyond project artifacts. ## Character Envelope (rick-and-morty | cosm) - Character: Pickle Rick - Tone: manic-resourceful - Voice anchor: "I'M PICKLE RIIICK!"
O frontmatter name, description,
model, context e consumido pelo harness
nativo. O corpo (“You are the dev wrapper“) e o prompt que o harness injeta quando o
subagent e spawnado. Tudo depois da primeira linha e AIOX decidindo o que
o agent faz, o kernel so entrega o arquivo.
| Persona | Nome | Escopo |
|---|---|---|
| @dev | Dex / Pickle Rick | Implementacao, git local |
| @qa | Quinn | Testes, verdicts, qa-gate |
| @architect | Aria | Decisoes tecnicas |
| @pm | Morgan | Epics, PRDs |
| @po | Pax | Validacao stories |
| @sm | River | Drafting stories |
| @analyst | Atlas | Pesquisa, research |
| @data-engineer | Dara | Schema, migrations, RLS |
| @ux-design-expert | Uma | Design specs |
| @devops | Gage / Rick Sanchez | EXCLUSIVO git push / PR |
| @aiox-master | Unity | Framework governance |
| @squad-creator | — | Criacao de squads |
| @tech-writer | Paige | Docs e knowledge curation |
| @sop-chief | — | Orquestracao SOP squad |
| @copy-chief | — | Orquestracao copy squad |
| @design-chief | — | Orquestracao design squad |
| @workspace-chief | — | Orquestracao workspace |
Diretiva CTO 2026-04-15: todos os agents AIOX em
model: opus. Nao Haiku/Sonnet.
O arquivo .claude/agents/devops.md:4-7 declara: “ONLY agent
authorized to push to remote repository.” Essa frase nao e um aviso social — ela e
backed pelo git-safety.md rule (always-on) e pelo
agent-authority.md rule (always-on), mais o fluxo documentado na
constituicao. Quando @dev tenta um git push,
o proprio prompt do agent (carregado de .aiox-core/development/agents/dev.md)
instrui a delegar via @devops *push. Essa e a camada comportamental.
Em ambientes maduros, ainda ha hooks Bash que interceptam o comando e bloqueiam.
Hooks sao a parte mais agressiva do AIOX — e tambem a mais importante: e onde
“regra” vira policy executavel. O harness Claude Code oferece tres pontos
de extensao: UserPromptSubmit, PreToolUse,
PostToolUse, mais PreCompact. Cada hook e
um processo Node ou Python que recebe um JSON via stdin, decide
alguma coisa, e sinaliza via exit code: 0 (ALLOW, com output opcional
no stdout/stderr), 2 (BLOCK).
O AIOX empilha 25+ hooks nos subdiretorios de .claude/hooks/.
Alguns cobrem constituicao (boundary), alguns cobrem incidentes historicos
(parallel-subagent-isolation), alguns sao infraestrutura
(langfuse-trace-manager, synapse-engine).
Bloqueia escritas em L1. Le amendments dinamicamente.
Exige isolation:"worktree" quando tree
dirty ou outro writer ativo.
Bloqueia worktrees pinnados em base stale (INC-2 fix).
Cobre o caso mega-workflow lock (pre-existente ao INC-1).
Impede operacoes git perigosas (reset --hard, push -f) na main.
Art. VIII. Tracks tool uses, consecutive reads, failures. Thresholds adaptativos.
Evita escritas de impl fora do escopo de uma story ativa.
Avisa quando um agent maestro tenta executar “manualmente” algo que deveria delegar.
Detecta conflito em arquivos compartilhados entre stories concorrentes.
Bloqueia rm -rf em paths sensiveis (VPS, master.env).
Art. V. Exige testes verdes antes de qualquer git merge.
Bloqueia commits em zonas de amendment sem aprovacao dupla.
Detecta story marcada “Done” com checkboxes nao batidos.
Context engine: injeta contexto relevante no prompt do usuario.
Reinjeta contexto critico apos compactacao.
Captura digest da sessao antes da compactacao destruir contexto.
Depois do incidente INC-1 2026-04-15 (tres
@dev e @sm subagents correndo na mesma
working tree, corrompendo branches), o AIOX adicionou um hook que bloqueia spawn de writing
subagents concorrentes sem worktree. Nao e regra moral: e exit 2
pro harness.
// .claude/hooks/parallel-subagent-isolation-guard.cjs:168-178 } else if (dirty && isWriting) { block = true; reason = `working tree is dirty and subagent_type="${subagentType}" can write files. ` + `Running without isolation:"worktree" risks data loss from concurrent git operations. ` + `Either (a) commit or stash pending changes, or (b) pass isolation:"worktree".`; } else if (activeWriters >= 1 && isWriting) { block = true; reason = `${activeWriters} writing subagent(s) already active. ` + `Launching another writing subagent without isolation:"worktree" causes branch collision ` + `(incident 2026-04-15). Pass isolation:"worktree" to proceed.`; } if (block) { process.stderr.write(`\n❌ BLOCKED: Parallel Subagent Isolation rule violation\n...`); process.exit(2); }
Cada hook termina com main().catch(err => process.exit(0)). Se o
proprio guard explodir, o AIOX prefere deixar passar — e o unico jeito razoavel de operar:
um hook bugado travando todo o trabalho seria pior que a regra nao ser enforced.
Tradeoff intencional, com log em stderr pra auditoria.
O diretorio .claude/rules/ e a memoria estruturada do projeto. O
harness nativo ja le arquivos CLAUDE.md como instrucoes permanentes
(user-level e project-level). O AIOX usa esse mecanismo, mas introduz uma convencao: cada rule
pode declarar no frontmatter um campo paths: com globs. Se presente,
a rule carrega on-demand — so quando o arquivo tocado bate com o glob. Se
ausente, a rule e always-on, ingerida em toda sessao.
Sao 38 arquivos. Tres sao always-on (sempre carregados):
agent-authority.md,
git-safety.md,
parallel-subagent-isolation.md.
Os outros 35 sao on-demand, carregando quando o path-matching casa.
Matriz Art. II: quem pode o que. @devops
EXCLUSIVO em git push/PR/release.
1 task = 1 worktree = 1 agent. Never force-push to main. Never
--no-verify sem pedido explicito.
NON-NEGOTIABLE. Concurrent writing subagents MUST pass
isolation:"worktree". Backed pelo hook.
| context-budget.md | Limites de tokens por task |
| context-sharding.md | Sharding de PRD/Architecture |
| context-reset-discipline.md | Quando dar /clear |
| scope-discipline.md | Art. III: nao escrever fora do escopo |
| step-file-execution.md | Pipeline stepfile (Maestro) |
| ids-principles.md | REUSE > ADAPT > CREATE (Art. IV-A) |
| verification-protocol.md | Art. VII: testes+typecheck antes de report |
| url-fetching.md | Jina Reader para URLs |
| workflow-execution.md | Como executar workflows AIOX |
| sau-routing.md | Lumos architecture routing |
| mandatory-tests.md | Testes obrigatorios Art. V |
| zero-trust-agents.md | Verificar outputs de agents |
A rule parallel-subagent-isolation.md nao existia antes de 2026-04-15.
Ela foi criada como resposta ao incidente INC-1. Frontmatter dela aponta:
enforced_by: .claude/hooks/parallel-subagent-isolation-guard.cjs e
incident: .aiox/incidents/2026-04-15-.... Isso e a propria rule fazendo
rastreabilidade: regra vira hook, hook referencia incidente, incidente referencia amendment.
Ciclo de governance formal, nao so markdown literario.
Skills sao um mecanismo nativo do harness Claude Code: o Claude le o
description do frontmatter de cada
.claude/skills/nome/SKILL.md e decide sozinho quando invocar,
usando o Skill tool. O AIOX coloca skills pequenos e proprios nesse
diretorio — cada uma e uma capacidade auto-descoberta.
A lista atual em .claude/skills/:
cli-router, deep-strategic-planning,
doc-rot, gowa,
tech-research, telegram. Mais o symlink
mega-brain apontando pra um repositorio irmao. Skills mais gordas
(squad-creator, Mega Brain) moram em squads/ e sao invocadas via
comandos /Domain:skill.
Roteia tarefa pra persona/agent correto via CLI (Gemini, Claude, Codex).
“Modo Dr. Estranho” — 7-10 futuros analisados por 12 lentes mentais.
Encontra documentacao podre pra DELETAR. TODOs stale, comentarios mentirosos, @ts-nocheck desnecessario.
Gerencia GOWA WhatsApp Gateway — API, groups, history, webhook, MCP.
Pipeline de deep technical research. Query → Decompose → Search → Synthesize. So pesquisa, nunca codifica.
Gateway multi-runtime / multi-channel — setup, deploy, logs, webhook.
/Domain:nome por dominio
O diretorio .claude/commands/ contem comandos slash que o usuario
invoca tipo /AIOX:help ou
/Sop:map-core-sop-backlog. Cada comando e um arquivo
.md com um prompt que o harness injeta quando voce digita o slash.
O AIOX organiza por dominio: 14 pastas em nivel raiz, mais 4 comandos sueltos
(greet, mega-brain,
sync-repos, system-architect).
| Dominio | Conteudo | Exemplos |
|---|---|---|
| AIOX/ | agents + workflows | /AIOX:help, /AIOX:init, /AIOX:workflows:maestro, /AIOX:agents:dev |
| Sop/ | agents + SOP tasks | /Sop:map-core-sop-backlog, /Sop:agents:sop-chief |
| SquadCreator/ | agents + create-from-sop | /SquadCreator:create-from-sop, /SquadCreator:agents:squad-chief |
| SquadCreatorPro/ | mind-clone personas | /SquadCreatorPro:agents:pedro-valerio, oalanicolas, thiago_finch |
| MegaBrain/ | 70+ commands (symlink) | /MegaBrain:jarvis-full, /MegaBrain:rag-search, /MegaBrain:conclave |
| Workspace/ | CIO/COO/CMO/CTO | /aiox-workspace:cio-engineer, /aiox-workspace:coo-orchestrator |
| Copy/ | copy-chief + copywriters | /Copy:agents:copy-chief |
| Design/ | design-chief + brand-me | /Design:brand-me, /Design:agents:design-chief |
| Doceng/ | doceng-chief | /Doceng:agents:doceng-chief |
| ComunidadeIaYolo/ | community chief | /ComunidadeIaYolo:agents:chief |
| Kb/ | knowledge base chief | /Kb:agents:kb-chief |
| Support/ | 8 agents de support-squad | /Support:agents:support-chief, triage, dna-coach, etc. |
| aiox-workspace/ | C-level vision | /aiox-workspace:vision-chief, caio-architect |
| clickup-ops/ | ClickUp automation | /clickup-ops:clickup-chief, api-builder, playwright-ops |
Inferencia: tipicamente um prompt curto ou um wrapper que ativa um agent e carrega uma task.
Por exemplo, /AIOX:agents:dev vira o agent
dev. /AIOX:workflows:maestro executa o
workflow Maestro step-file. /Sop:map-core-sop-backlog e uma task
direta do squad SOP.
O harness Claude Code nao entende squad — ele so le
.claude/commands/**/*.md e faz a expansao do slash. A organizacao em
pastas e puramente AIOX.
Squad e um empacotamento AIOX: cada diretorio squads/nome/
tem a mesma forma — agents/, tasks/,
templates/, checklists/, mais
data/ (minds, DNA, dossies) e docs/. O
squad-registry.yaml agrega metadata de todos os squads: versao, scores, maturity,
slash-prefix, contagens.
Sao 16 squads registradas, de operacionais (aiox-ads,
clickup-ops) a meta-squads (squad-creator,
squad-creator-pro) a C-level (c-level,
aiox-workspace).
Squads moram em squads/ (L4 runtime, livre pra editar). Agents/hooks/rules
moram em .aiox-core/ (L1/L2, protegidos) e
.claude/ (consumido pelo harness). Um squad usa os agents e
rules do core, mas adiciona seus proprios agents, tasks e templates. E uma expansao horizontal
do framework, nao uma alteracao dele. Analogia: squads sao “distros”
ou “pacotes” instalados sobre o kernel AIOX.
Ja aparece espalhado nas secoes anteriores, mas merece ser consolidado. “Gate” em AIOX e qualquer ponto onde uma condicao constitucional ou operacional e checada e resulta em tres comportamentos possiveis:
NON-NEGOTIABLE + MUST criticos. Nao prossegue, mostra stderr, exige correcao. Exemplos: L1 boundary, parallel subagent sem worktree, merge sem testes verdes, commit em zona de amendment sem aprovacao.
MUST nao-criticos. Tool call prossegue, alerta visivel. Exemplos: edit em L2 sem amendment, shared file entre stories, lifecycle threshold (consecutive reads), maestro delegation.
SHOULD. Registrado em logs, traces (Langfuse), reports. Nao toca o fluxo. Exemplos: queda de cobertura, context injection do synapse-engine, session digest precompact.
E o protocolo que o harness Claude Code entende. Hook e um subprocess que o harness spawna no
PreToolUse ou PostToolUse: se o subprocess
sai com codigo 2, o harness interpreta como “deny this tool call”. Nao ha
exception, nao ha API custom. E a mesma unix wisdom de grep saindo
com 1 quando nao encontra match — exit codes como sinal.
O AIOX escolheu abracar esse mecanismo ao pe da letra, ao inves de construir uma abstracao maior. Isso mantem o framework compativel com qualquer evolucao do harness: Anthropic pode mudar internals, mas enquanto o protocolo de hook (stdin JSON → exit code) continuar estavel, AIOX continua funcionando.
Amendments sao o unico jeito legitimo de relaxar L1/L2, reclassificar paths, ou adicionar
novas regras NON-NEGOTIABLE. Cada amendment e um YAML em
.aiox/amendments/ com campos bem definidos:
amendment_id, status,
severity, affected_path,
justification, signatures (dual approval
@aiox-master + @architect ou equivalente).
O hook l1-boundary-guard.cjs le esses YAMLs em tempo real —
cada escrita em L1 carrega todos amendments com
status: RATIFIED e checa se algum cobre o path. Isso significa que
“ratificar” e literal: basta editar o campo status pra
RATIFIED e adicionar as assinaturas pro hook parar de bloquear.
core/execution/ L1 → L3Primeiro amendment formal. Justificativa: wave-executor + metrics + crash recovery nao cabiam em wrappers L4 sem indirecao insustentavel. 9/9 reviewers disseram que wrapper era over-engineering. Dual approval @aiox-master + @architect, both signed 2026-03-28.
Reacao ao INC-1. Formaliza que Agent tool com writing subagent MUST
passar isolation:"worktree" em concorrencia ou tree dirty.
Enforced por hook + regression test. Retirement criteria: so desativa se harness passar a
enforcar nativamente ou outro isolation primitive substituir worktree.
Reacao ao INC-2 (Follow-up). Harness cria worktree pinned em base
stale — agents spawnados ali nao veem stories recentes. Hook
worktree-base-verifier.cjs bloqueia worktree com base >5 commits
behind HEAD ou sem paths criticos.
QA gate enhancement, course-correction retrospective, quick-dev expansion, novos L2 tasks, brainstorming refactor, APC menu markers, step-file architecture, elicitation methods, project-context-gen. Cada um com justificativa e assinatura.
O Claude Code harness tem memoria nativa: arquivos CLAUDE.md em
cascata (user-level, project-level), auto-memory em
~/.claude/projects/..., e o sistema de “remember this”
via tool. O AIOX nao substitui nada disso. Ele usa e impoe uma precedencia formal.
O .claude/CLAUDE.md do projeto comeca com exatamente essa linha:
// .claude/CLAUDE.md:5
Precedencia: Constitution > .claude/rules/ > Story AC >
project-conventions.yaml > Este arquivo > Best practices
Essa linha e uma declaracao de conflito-resolucao. Quando duas instrucoes colidem (ex: CLAUDE.md diz “push livre”, rule diz “push EXCLUSIVO @devops”), a rule ganha. Quando story AC colide com CLAUDE.md, AC ganha. Isso e governance as configuration: o modelo nao precisa racionalizar, so seguir a tabela.
.aiox-core/constitution.mdpaths:.docs/stories/.
Em toda sessao, o harness injeta na system-reminder o conteudo de:
(a) user-level ~/.claude/CLAUDE.md (global),
(b) project-level .claude/CLAUDE.md (projeto),
(c) auto-memory em ~/.claude/projects/.../memory/MEMORY.md,
(d) always-on rules, (e) skills discoverable via SKILL.md frontmatter.
Todos esses mecanismos sao do harness. O AIOX so preenche, com convencao de
precedencia explicita no proprio CLAUDE.md.
Mapeando tudo isso de fora: o AIOX nao estende o harness Claude Code no sentido de
adicionar capacidade nova ao modelo. Ele instala uma camada editorial em cima dos
pontos de extensao ja publicos: CLAUDE.md, rules, agents, hooks,
skills, commands. O que muda com isso:
E tambem ha custo, que a Parte 4 vai criticar: o overhead de onboarding (um agente novo tem que absorver constituicao, 38 rules, 25 hooks, registry de squads), o risco de rules entrarem em conflito silencioso, a dependencia de um CLAUDE.md bem-mantido, a pressao sobre o token budget quando always-on rules crescem. Mas antes da critica, vem a Parte 3 com os estudos de caso — como o AIOX se comportou em incidentes reais (INC-1, INC-2), em workflows maestro-v2, em pipelines SDC, em parallel story execution.