@jaimevalasek/aioson 1.7.2 → 1.9.0

package/docs/pt/4-agentes/orchestrator.md

@@ -0,0 +1,118 @@
+# @orchestrator — Coordene lanes paralelas em projetos MEDIUM
+
+> **Para quem é:** quem trabalha em projetos MEDIUM e precisa dividir a implementação em frentes paralelas.
+> **Tempo de leitura:** 4 min.
+> **O que você vai sair sabendo:**
+> - O que é uma "lane" e quando paralelizar faz sentido
+> - Comandos CLI do sistema de lanes
+
+---
+
+## Para que serve
+
+Em projetos MEDIUM, a implementação pode ser grande o suficiente para ter partes independentes — backend de autenticação e frontend de listagem, por exemplo — que podem acontecer em paralelo sem conflito. Tentar fazer isso manualmente sem coordenação é receita para conflitos de merge e arquivos sobrescritos.
+
+`@orchestrator` divide o trabalho em **lanes** (faixas de execução): cada lane tem seu escopo, seus arquivos permitidos, e seu estado independente. Ele garante que as lanes não escrevam nos mesmos arquivos e coordena o merge no final.
+
+**Regra dura:** `@orchestrator` só ativa em projetos MEDIUM. Para MICRO e SMALL, execução sequencial é o suficiente.
+
+---
+
+## Quando invocar
+
+- Projetos MEDIUM, após `@pm`, quando há implementação paralelizável.
+- Quando você tem múltiplos devs (humanos ou IAs) trabalhando na mesma feature.
+- Quando uma feature tem frentes claramente independentes (ex: API + UI + migrations).
+
+---
+
+## Quando NÃO invocar
+
+- Projeto MICRO ou SMALL → ele mesmo recusa e te avisa.
+- A feature tem dependências lineares fortes → implemente sequencialmente com `@dev`.
+
+---
+
+## Diálogo típico
+
+```
+Você > @orchestrator
+
+@orchestrator > Verificando classificação... MEDIUM. OK.
+                Lendo architecture.md, tasks.md, ui-spec.md...
+                
+                Dividindo em 3 lanes:
+                Lane 1 — backend
+                  Escopo: src/models/payment.js, src/services/payment-service.js, src/routes/checkout.js
+                Lane 2 — frontend
+                  Escopo: src/views/checkout/, src/components/PaymentForm/
+                Lane 3 — migrations
+                  Escopo: db/migrations/add-payment-table.sql
+                
+                Guard configurado: lanes não podem escrever fora do próprio escopo.
+                
+                $ aioson parallel:init .          ✓
+                $ aioson parallel:assign .        ✓
+                Workspace pronto em .aioson/context/parallel/
+                
+                Quando terminar cada lane, rode:
+                  aioson parallel:status .
+                  aioson parallel:merge . --apply
+```
+
+---
+
+## Saídas em disco
+
+| Arquivo/Diretório | Conteúdo |
+|---|---|
+| `.aioson/context/parallel/lane-1.md` | Escopo e estado da lane 1 |
+| `.aioson/context/parallel/lane-2.md` | Escopo e estado da lane 2 |
+| `.aioson/context/parallel/lane-N.md` | ... |
+
+---
+
+## Como ele lê seu projeto
+
+- `.aioson/context/project.context.md` — confirma `classification: MEDIUM`
+- `.aioson/context/discovery.md`, `architecture.md`, `prd.md`, `ui-spec.md`
+- `.aioson/context/implementation-plan-{slug}.md` — se existir
+- `.aioson/context/parallel/` — ao retomar sessão
+
+---
+
+## Comandos CLI relacionados
+
+```bash
+# Inicializar workspace de lanes
+aioson parallel:init .
+
+# Distribuir escopos
+aioson parallel:assign .
+
+# Ver progresso de cada lane
+aioson parallel:status .
+
+# Validar que uma lane está autorizada a escrever num arquivo
+aioson parallel:guard . --lane=1 --paths=src/models/payment.js
+
+# Merge final (só quando todas as lanes estão prontas)
+aioson parallel:merge . --apply
+
+# Corrigir workspace quebrado
+aioson parallel:doctor . --fix
+```
+
+---
+
+## Handoff típico
+
+- **Vem de:** `@pm`
+- **Vai para:** `@dev` (em cada lane)
+
+---
+
+## Próximo passo
+
+- [Ficha do @dev](./dev.md) — executa dentro de cada lane
+- [Decisões iniciais: MEDIUM](../2-comecar/decisoes-iniciais.md#medium--workflow-completo)

package/docs/pt/4-agentes/pentester.md

@@ -0,0 +1,131 @@
+# @pentester — Revisão adversarial de segurança
+
+> **Para quem é:** quem vai publicar uma feature e quer garantir que não abriu brechas de segurança.
+> **Tempo de leitura:** 5 min.
+> **O que você vai sair sabendo:**
+> - O que `@pentester` cobre (e o que está fora de escopo)
+> - As superfícies de ataque que ele mapeia sistematicamente
+
+---
+
+## Para que serve
+
+Segurança não é um checklist de última hora. Mas também não precisa ser uma consultoria de dois meses. `@pentester` ocupa o meio-termo: ele é estruturado, com escopo definido, e produz findings rastreáveis — não uma impressão subjetiva de "parece seguro".
+
+Ele mapeia **superfícies de ataque** da feature (não apenas "checou XSS?"), gera um contrato de revisão antes de começar, e produz findings com ID, severidade, evidência e recomendação. Assim o `@dev` e o `@qa` podem agir sem ambiguidade.
+
+Coberturas recentes adicionadas: **LLM Top 10** (vulnerabilidades específicas de sistemas com IA), **supply chain** (dependências com CVEs conhecidos), **tooling** (ferramentas de build e CI).
+
+**Limite duro de escopo:** ele só atua no workspace local. Qualquer pedido de testar URLs externas, sistemas de terceiros, ou produção real é recusado e registrado como "out of scope".
+
+---
+
+## Dois modos de operação
+
+`@pentester` opera em **dois modos** com catálogos de ataque distintos. O modo é escolhido pelo target da auditoria — não pelo usuário.
+
+| Modo | Quando ativa | O que audita | Catálogo de ataque |
+|---|---|---|---|
+| **`framework_target`** (padrão) | Você está dentro de um repositório AIOSON (raiz tem `.aioson/`) e a auditoria é sobre o próprio framework | Prompts dos agentes, handoffs entre agentes, `last-handoff.json`, escalada via injeção de contexto, manipulação de `dev-state.md`, leak via `project-pulse.md` | Prompt injection inter-agente, context smuggling, agent impersonation, handoff tampering |
+| **`app_target`** | Auditoria explicitamente sobre a aplicação que você está construindo *com* AIOSON (pedido com `--mode=app_target` ou handoff explícito) | Código de aplicação: rotas, autenticação, upload, queries SQL, dependências | OWASP Top 10, LLM Top 10, supply chain CVE, secrets em código |
+
+Os dois modos produzem `security-findings-{slug}.json` com a mesma estrutura, mas o campo `target_mode` distingue. Se a sua feature mexe **tanto** no framework quanto na app (raro), rode os dois separadamente — não misture.
+
+---
+
+## Quando invocar
+
+- Antes de publicar uma feature para produção.
+- Quando a feature toca autenticação, pagamentos, upload de arquivos, ou dados sensíveis.
+- Quando você quer um audit point de segurança antes de uma release.
+- Quando o `@tester` encontrou indícios de problemas de segurança.
+
+---
+
+## Quando NÃO invocar
+
+- Você quer testar segurança de um sistema externo (API de terceiro, site alheio) → recusado por design.
+- Você quer validação de comportamento funcional → use `@qa`.
+- Você quer cobertura de testes → use `@tester`.
+
+---
+
+## Diálogo típico
+
+```
+Você > @pentester
+
+@pentester > Qual feature está sob revisão? (slug)
+Você > checkout-stripe
+
+@pentester > Carregando prd-checkout-stripe.md e spec-checkout-stripe.md...
+             security-findings-checkout-stripe.json não existe — criando novo.
+             
+             Gerando review contract...
+             
+             Superfícies de ataque mapeadas para checkout-stripe:
+             TS-checkout-stripe-01: memory_context     → injeção via context files
+             TS-checkout-stripe-02: tool_invocation    → path traversal em Bash
+             TS-checkout-stripe-03: secret_handling    → API key Stripe em logs
+             TS-checkout-stripe-04: supply_chain       → dependência stripe@npm vulnerável?
+             
+             Revisando...
+             
+             Findings:
+             HIGH  SEC-CS-01: stripe secret key aparece em dev-state.md linha 12
+             MEDIUM SEC-CS-02: sem rate-limit no POST /checkout
+             LOW   SEC-CS-03: dependência stripe@11.x — verificar CVE
+             
+             security-findings-checkout-stripe.json gravado.
+             Recomendações prontas para @dev resolver HIGH/MEDIUM antes da release.
+```
+
+---
+
+## Saídas em disco
+
+| Arquivo | Conteúdo |
+|---|---|
+| `.aioson/context/security-findings-{slug}.json` | Findings com ID, severidade, evidência, recomendação |
+| `.aioson/context/security-findings-project.json` | Findings de nível projeto (quando relevante) |
+
+---
+
+## Como ele lê seu projeto
+
+- `.aioson/context/project.context.md` — confirma workspace e layout
+- `.aioson/context/prd-{slug}.md` e `spec-{slug}.md` — mapa de superfície de ataque
+- `.aioson/context/security-findings-{slug}.json` — findings anteriores (para não duplicar)
+- `.aioson/rules/security-baseline.md` — controles `SEC-SBD-01..08` obrigatórios
+
+---
+
+## Superfícies cobertas
+
+**Obrigatórias para qualquer feature:**
+
+| ID | Tipo | O que verifica |
+|---|---|---|
+| TS-{slug}-01 | `memory_context` | Injeção de prompt, contaminação de context files |
+| TS-{slug}-02 | `tool_invocation` | Chamadas shell inseguras, path traversal |
+| TS-{slug}-03 | `delegation_handoff` | Escalada de trust em `last-handoff.json` |
+| TS-{slug}-04 | `protocol_contract` | Violações de schema, bypass de workflow |
+| TS-{slug}-05 | `secret_handling` | Credenciais em context files, logs, prompts |
+| TS-{slug}-06 | `runtime_permissions` | Bypass de política de autonomia |
+
+**Condicionais (quando aplicável):** OWASP Top 10 Web (input injection, broken auth, etc.), LLM Top 10 (prompt injection, training data leakage, etc.), supply chain (CVEs em dependências).
+
+---
+
+## Handoff típico
+
+- **Vem de:** você diretamente, ou `@tester` (que encontrou indício)
+- **Vai para:** `@dev` (para corrigir findings HIGH/MEDIUM) → `@qa` (re-validação)
+
+---
+
+## Próximo passo
+
+- [Ficha do @qa](./qa.md) — re-valida após correções
+- [Ficha do @dev](./dev.md) — corrige os findings
+- [Glossário: Zero Trust, Security Baseline](../1-entender/glossario.md#zero-trust)

package/docs/pt/4-agentes/pm.md

@@ -0,0 +1,97 @@
+# @pm — Backlog e user stories para projetos MEDIUM
+
+> **Para quem é:** quem trabalha em projetos MEDIUM e precisa transformar requisitos em histórias de usuário priorizadas.
+> **Tempo de leitura:** 3 min.
+> **O que você vai sair sabendo:**
+> - Quando `@pm` é obrigatório e quando é dispensável
+> - O que ele produz em no máximo 2 páginas
+
+---
+
+## Para que serve
+
+Em projetos MEDIUM, a quantidade de requisitos pode crescer ao ponto de o `@dev` não saber o que implementar primeiro, ou implementar tudo ao mesmo tempo e não terminar nada. `@pm` existe para **priorizar, sequenciar e deixar os ACs testáveis** — sem reescrever o que `@product` já decidiu.
+
+Sua regra interna de ouro: máximo 2 páginas. Se o output excede isso, ele está fazendo mais do que deveria. Corta.
+
+---
+
+## Quando invocar
+
+- Projetos MEDIUM, após `@ux-ui` e antes de `@orchestrator`.
+- Quando a feature é grande o suficiente para ter múltiplas histórias de usuário independentes.
+- Quando você quer sequenciar entregas por prioridade (ex: MVP → iteração 2).
+
+---
+
+## Quando NÃO invocar
+
+- Projetos MICRO → `@dev` lê o contexto direto.
+- Projetos SMALL → também desnecessário na maioria dos casos.
+- Você quer refinar produto, não backlog → use `@product`.
+
+---
+
+## Diálogo típico
+
+```
+Você > @pm
+
+@pm > Lendo prd-checkout-stripe.md, architecture.md e ui-spec.md...
+      
+      User stories priorizadas:
+      
+      P1 — Fluxo crítico (MVP)
+      - US-01: Como cliente, posso inserir meus dados de cartão e finalizar compra
+        AC: formulário valida em tempo real · POST /checkout retorna 200 com order_id
+      - US-02: Como cliente, vejo confirmação após pagamento aprovado
+        AC: redirect para /checkout/success com número do pedido
+      
+      P2 — Tratamento de erro
+      - US-03: Como cliente, vejo mensagem clara se cartão recusar
+        AC: resposta Stripe CARD_DECLINED → mensagem amigável em tela, sem reload
+      
+      Fora de escopo desta iteração: webhooks de estorno, emails de recibo.
+      
+      tasks.md criado em .aioson/context/tasks.md
+      Próximo: @orchestrator.
+```
+
+---
+
+## Saídas em disco
+
+| Arquivo | Conteúdo |
+|---|---|
+| `.aioson/context/tasks.md` | User stories priorizadas com ACs testáveis |
+
+---
+
+## Como ele lê seu projeto
+
+- `.aioson/context/prd.md` ou `prd-{slug}.md` — **base do produto; nunca reescreve**
+- `.aioson/context/discovery.md`, `architecture.md`, `ui-spec.md`
+- `.aioson/rules/` — regras com `agents: pm`
+
+---
+
+## Comandos CLI relacionados
+
+```bash
+# Estado do workflow — confirmar posição do @pm
+aioson workflow:status .
+```
+
+---
+
+## Handoff típico
+
+- **Vem de:** `@ux-ui`
+- **Vai para:** `@orchestrator`
+
+---
+
+## Próximo passo
+
+- [Ficha do @orchestrator](./orchestrator.md)
+- [Ficha do @dev](./dev.md) — quem executa as histórias

package/docs/pt/4-agentes/product.md

@@ -0,0 +1,114 @@
+# @product — Defina o que vai ser construído e por quê
+
+> **Para quem é:** quem está começando uma feature ou um projeto e precisa transformar uma ideia em escopo concreto.
+> **Tempo de leitura:** 4 min.
+> **O que você vai sair sabendo:**
+> - Quando e como invocar `@product`
+> - O que ele produz e onde fica
+
+---
+
+## Para que serve
+
+Quando você vai a um dev e diz "preciso de um app de agendamento", ele vai te perguntar: "para quem? com que restrições? o que é fora de escopo?". Se você não responde bem, ele implementa o que imaginou, não o que você precisava.
+
+`@product` faz essas perguntas por você — antes de qualquer linha de código. Ele conduz uma conversa estruturada que transforma intenções vagas numa especificação que todos os agentes subsequentes vão usar como base.
+
+Ele é o primeiro agente técnico num projeto novo (logo após `@setup`) e o ponto de entrada para cada nova feature em projetos existentes.
+
+Se você tiver notas no `plans/` ou `prds/`, o `@product` as detecta automaticamente e pergunta se deve usá-las como material. Os arquivos originais nunca são modificados.
+
+**Modo briefing-aware:** se existir `.aioson/briefings/` com algum briefing `status: approved` e `prd_generated: null`, o `@product` lista esses briefings antes da detecção de modo e oferece converter em PRD. Se aceito, o PRD nasce com `briefing_source: {slug}` no frontmatter — rastreio completo do briefing original. Veja [Da ideia ao PRD via @briefing](../3-receitas/da-ideia-ao-prd-via-briefing.md).
+
+---
+
+## Quando invocar
+
+- Início de projeto: você quer construir algo mas ainda não tem spec.
+- Nova feature: projeto existe, você quer adicionar funcionalidade nova.
+- Refinamento: a spec existe mas ficou desatualizada e precisa de revisão.
+- Síntese de anotações: você tem notas em `plans/*.md` e quer transformar em PRD real.
+
+---
+
+## Quando NÃO invocar
+
+- Você já tem a spec pronta e quer ir direto para implementação → invoke `@dev`.
+- Você quer refinar UX, não produto → invoke `@ux-ui`.
+- Você quer entender o estado do projeto antes de escolher → invoke `@neo`.
+
+---
+
+## Diálogo típico
+
+```
+Você > @product
+
+@product > Li project.context.md. Projeto "minha-loja", SMALL, pt-BR.
+           Encontrei plans/checkout-v2.md. Usar como material para o PRD? Os originais ficam intactos.
+Você > Sim
+
+@product > [lê plans/checkout-v2.md]
+           Feature identificada: "Checkout com cartão de crédito via Stripe".
+           
+           Para afinar o escopo:
+           1. O usuário pode salvar cartões para uso futuro?
+           2. Precisa suportar múltiplos cartões no mesmo pedido?
+           3. O que está fora de escopo agora?
+
+Você > Não salvar cartões. Um cartão por pedido. Fora de escopo: parcelamento.
+
+@product > PRD criado em .aioson/context/prd-checkout-stripe.md
+           Spec inicial em .aioson/context/features/checkout-stripe/spec.md
+           Próximo agente: @analyst (para mapear domínio).
+```
+
+---
+
+## Saídas em disco
+
+| Arquivo | Quando cria |
+|---|---|
+| `.aioson/context/prd.md` | Projeto novo |
+| `.aioson/context/prd-{slug}.md` | Feature nova |
+| `.aioson/context/features/{slug}/spec.md` | Sempre |
+| `plans/source-manifest.md` | Quando consome material de `plans/` |
+
+---
+
+## Como ele lê seu projeto
+
+Antes de qualquer pergunta, lê:
+- `.aioson/context/project.context.md` — classificação, idioma, stack
+- `.aioson/context/bootstrap/what-is.md` e `what-it-does.md` — se existirem
+- `plans/*.md` e `prds/*.md` — detecta fontes de entrada
+- `.aioson/rules/` — regras com `agents: product`
+
+---
+
+## Comandos CLI relacionados
+
+```bash
+# Ver estado atual do workflow (qual agente é o próximo)
+aioson workflow:next .
+
+# Verificar contexto válido antes de invocar
+aioson context:validate .
+```
+
+---
+
+## Handoff típico
+
+- **Vem de:** `@setup` (projeto novo) ou você mesmo (nova feature)
+- **Vai para:** `@analyst` (SMALL/MEDIUM) ou `@dev` (MICRO sem novas entidades)
+
+---
+
+## Próximo passo
+
+- Trilha canônica de feature completa → [Feature completa com @sheldon](../3-receitas/feature-completa-com-sheldon.md)
+- Ideia ainda vaga? → [Da ideia ao PRD via @briefing](../3-receitas/da-ideia-ao-prd-via-briefing.md)
+- Já planejou em outro chat? → [Plans externos para @product](../3-receitas/plans-externos-para-product.md)
+- [Ficha do @analyst](./analyst.md) — próximo no fluxo SMALL/MEDIUM
+- [Glossário: Dossier, Spec, PRD](../1-entender/glossario.md)

package/docs/pt/4-agentes/profiler-enricher.md

@@ -0,0 +1,93 @@
+# @profiler-enricher — Analisar cognitivamente o material de pesquisa
+
+> **Para quem é:** quem já tem o material coletado pelo `@profiler-researcher` e quer transformá-lo em um perfil cognitivo estruturado.
+> **Tempo de leitura:** 3 min.
+> **O que você vai sair sabendo:**
+> - O que o enricher produz e em que formato
+> - Quais frameworks ele aplica sobre o material
+
+---
+
+## Para que serve
+
+Material bruto coletado não é perfil. O `@profiler-enricher` lê o `research-report.md` gerado pelo researcher e aplica análise psicométrica e comportamental baseada em evidências — extraindo padrões de decisão, comunicação, valores e pontos cegos.
+
+Esta é a **etapa 2 de 3** do pipeline Profiler:
+
+```
+@profiler-researcher → @profiler-enricher → @profiler-forge
+     coleta                  analisa              gera
+```
+
+O enricher **não inventa** características — cada inferência é atribuída a uma fonte específica do material. Se não há evidência, ele declara incerteza.
+
+---
+
+## Quando invocar
+
+- O `@profiler-researcher` já rodou e gerou `research-report.md`
+- Você quer adicionar materiais extras (transcrições, textos pessoais) antes da análise
+- Você está reprocessando um perfil com material novo
+
+---
+
+## Quando NÃO invocar
+
+- O `research-report.md` ainda não existe — rode `@profiler-researcher` primeiro
+- Você quer apenas o genome final sem revisar a análise intermediária — o `@profiler-forge` pode rodar após o enricher sem interação extra
+
+---
+
+## Diálogo típico
+
+```
+Você > @profiler-enricher david-ogilvy
+
+@profiler-enricher > Base de pesquisa carregada para David Ogilvy (27 fontes).
+                     Você pode enriquecer com materiais extras agora.
+                     Envie textos, links ou transcrições, ou digite 'proceed'.
+Você > proceed
+
+@profiler-enricher > Analisando...
+                     DISC: D-moderado / C-alto
+                     Enneagram: 3w4 (realizador com autoconhecimento artístico)
+                     Big Five: baixo Neuroticismo, alto Conscienciosidade
+                     MBTI: ENTJ
+                     Estilo de decisão: pesquisa exaustiva antes de executar; confia em dados, não em instintos
+                     Pontos cegos: pode subestimar audiências sem background publicitário
+
+@profiler-enricher > Perfil salvo em:
+                     .aioson/profiler-reports/david-ogilvy/enriched-profile.md
+                     Próximo: @profiler-forge david-ogilvy
+```
+
+---
+
+## Saídas em disco
+
+```
+.aioson/profiler-reports/{slug}/
+├── research-report.md       ← entrada (criada pelo researcher)
+└── enriched-profile.md      ← saída desta etapa
+```
+
+---
+
+## Como ele lê seu projeto
+
+- `.aioson/profiler-reports/{slug}/research-report.md` — base obrigatória
+- `.aioson/context/project.context.md` — idioma de interação
+
+---
+
+## Handoff típico
+
+- **Vem de:** `@profiler-researcher`
+- **Vai para:** `@profiler-forge` — geração do Genome 4.0 e do advisor
+
+---
+
+## Próximo passo
+
+- Etapa anterior: [profiler-researcher.md](./profiler-researcher.md)
+- Próxima etapa: [profiler-forge.md](./profiler-forge.md)

package/docs/pt/4-agentes/profiler-forge.md

@@ -0,0 +1,93 @@
+# @profiler-forge — Gerar Genome 4.0 e advisor a partir do perfil enriquecido
+
+> **Para quem é:** quem quer transformar o perfil cognitivo analisado em um artefato utilizável — genome ou advisor.
+> **Tempo de leitura:** 3 min.
+> **O que você vai sair sabendo:**
+> - O que o profiler-forge gera e onde salva
+> - Como usar o advisor gerado no seu projeto
+
+---
+
+## Para que serve
+
+Análise cognitiva na cabeça não serve para nada. O `@profiler-forge` pega o `enriched-profile.md` e o transforma em dois artefatos deployáveis: um **Genome 4.0** (YAML estruturado com todos os campos psicométricos e operacionais) e/ou um **Advisor Agent** (prompt pronto para vincular a um squad ou usar diretamente no cliente AI).
+
+Esta é a **etapa 3 de 3** do pipeline Profiler:
+
+```
+@profiler-researcher → @profiler-enricher → @profiler-forge
+     coleta                  analisa              gera
+```
+
+O forge **não pesquisa nem analisa** — ele sintetiza, estrutura e formata.
+
+---
+
+## Quando invocar
+
+- O `@profiler-enricher` já gerou `enriched-profile.md`
+- Você quer o genome em formato 4.0 (com campos `anchor_prompt`, `relations`, `hexaco_h`, `trait_interactions`)
+- Você quer um advisor pronto para o cliente AI
+
+---
+
+## Quando NÃO invocar
+
+- O `enriched-profile.md` ainda não existe — o forge vai te pedir para voltar às etapas anteriores
+- Você não precisa de um artefato formal — para uso rápido, `@genome --quick` gera algo sem pipeline
+
+---
+
+## Diálogo típico
+
+```
+Você > @profiler-forge david-ogilvy
+
+@profiler-forge > Perfil cognitivo carregado para David Ogilvy.
+                  DISC: D-moderado/C-alto | Enneagram: 3w4 | MBTI: ENTJ
+                  Pontos de evidência: 27 | Confiança: alta
+
+                  O que você quer gerar?
+                  [1] Genome 4.0
+                  [2] Advisor Agent
+                  [3] Ambos
+                  [4] Ambos + aplicar a um squad
+Você > 3
+
+@profiler-forge > Gerando...
+                  Genome: .aioson/genomes/david-ogilvy.genome.json
+                  Advisor: .aioson/genomes/david-ogilvy-advisor.md
+
+                  Para usar o advisor: inclua o arquivo no seu cliente AI
+                  ou vincule ao squad via squad.json → genome_binding.
+```
+
+---
+
+## Saídas em disco
+
+```
+.aioson/genomes/{slug}.genome.json       ← Genome 4.0 completo
+.aioson/genomes/{slug}-advisor.md        ← advisor como prompt utilizável
+```
+
+---
+
+## Como ele lê seu projeto
+
+- `.aioson/profiler-reports/{slug}/enriched-profile.md` — entrada obrigatória
+
+---
+
+## Handoff típico
+
+- **Vem de:** `@profiler-enricher`
+- **Vai para:** uso direto do advisor / vinculação ao squad via `@squad`
+
+---
+
+## Próximo passo
+
+- Etapa anterior: [profiler-enricher.md](./profiler-enricher.md)
+- Usar o genome num squad: [squad.md](./squad.md)
+- Publicar o genome: `aioson system:publish --type=genome --slug=<slug>`