Create SOP & Create Squad Pro

Premissa e metodologia

Tudo nesta parte é inferência a partir dos arquivos do repo. Eu vou citar file:line em EVIDENCE sempre que possível, e marcar com (inferência) quando estou colando pontos sem uma afirmação explícita no código. Se você ler só a primeira parte de cada callout, já vê qual é a diferença prática. O resto é aprofundamento.

Note que eu pesquei os dois fluxos sem olhar squads de produção (o copy, por exemplo). Se algum comportamento divergir do runtime real, é porque o runtime tem lógica extra (dynamic greeting via scripts/generate-squad-greeting.js, AI-FIRST-GOVERNANCE protocols) que não aparece só lendo as tasks.

Caso 1 · Create SOP (/SquadCreator:create-from-sop)

O comando transforma SOPs YAML canônicos do workspace em artefatos de squad: tasks candidatas, mapa de workflow, guardrails e open questions marcadas como gaps. Ele não inventa processo — ele lê YAMLs já estruturados que moram em workspace/businesses/{slug}/ e destila o que virou executável, o que virou contexto de suporte, e o que virou sinal de governança.

Disparo pelo usuário

# Forma mínima (vai perguntar selectors)
/SquadCreator:create-from-sop

# Forma completa
*create-from-sop --business=aiox --namespace=operations
*create-from-sop --business=italo_gustavo --namespace=L1-strategy --paths=L1-strategy/team-structure.yaml

Arquitetura em camadas

O comando é propositalmente magro. O que parece ser um fluxo linear é na verdade uma cadeia de 4 camadas onde cada uma aponta pra próxima:

Cada camada tem responsabilidade clara:

Orchestrator obrigatório & model tier

Metadata estruturada: SINKRA_TASK_METADATA + SINKRA_CONTRACT

Toda task do Pro tem duas caixas YAML marcadas com tags HTML no topo do arquivo. Isso não é documentação: é contrato estruturado que workers (Python/JS) podem parsear sem precisar de LLM. Olhar só o YAML já diz tudo que você precisa saber pra saber se a task tá bem formada.

<!-- SINKRA_TASK_METADATA:START -->
sinkra_task_metadata:
  task_id: create-from-sop
  task_name: Create Squad Artifacts From Workspace SOPs (Stub)
  status: pending
  responsible_executor: '@pedro-valerio'
  execution_type: Agent
  estimated_time: 30m
  domain: Tactical
  input:  [# referência circular — ver corpo da task]
  output: [# idem]
  action_items:
    - Executar os passos documentados no corpo da task
  acceptance_criteria:
    - Loader executado com `business` explicito e seletores explicitos
    - Nenhuma fonte fora de `workspace/businesses/{slug}` foi considerada valida
    - `runtime_mode` validado como `full_workspace_mode`
    - `source_of_truth` validado como `workspace_canonical`
    - Cada processo executavel virou task candidate com executor + guardrails
  output_persistence: canonical_workspace
  accountable_id: Human:Squad_Operator
  accountability_scope: review_only
  escalation_priority: medium
<!-- SINKRA_TASK_METADATA:END -->

Abaixo da metadata vem o Sinkra Contract — pre/post conditions + SLA:

sinkra_contract:
  Domain: Strategic
  atomic_layer: Atom
  executor: Agent
  pre_condition: "inputs, dependências e artefatos prévios resolvidos antes de iniciar a execução."
  post_condition: "output principal gerado, validado e pronto para handoff da próxima fase."
  performance: "executar dentro do SLA declarado, registrar erro explicitamente e escalar via handoff sem falha silenciosa."

Por que importa? Porque o campo accountable_id: Human:Squad_Operator diz que se o output der ruim, é um humano específico quem responde — não o modelo, não o squad, não “o AI”. Isso é audit trail embutido no arquivo.

Função de cada campo (leitura rápida)

Veto Conditions — os 5 bloqueios

A peça central do Create SOP são os vetos. Cada um é um pre-check que bloqueia a execução se falhar. Não é warning, não é “nota” — é BLOCK. O agente desliga e devolve o controle.

Por que 5 vetos e não 1 genérico?

Cada veto cobre uma falha específica que já aconteceu em operação (inferência, baseado no fato de ter ID único por falha — tipicamente isso surge depois de ver o modo de falha no wild):

• 001 evita o modo “cria squad genérico pra business inexistente”
• 002 evita rodar o comando no repo errado (full_workspace_mode só existe quando o workspace tá configurado)
• 003 evita o modo “vou usar SOPs de outro lugar” — SSOT é workspace_canonical
• 004 evita processar todo o business (o usuário tem que escolher o escopo)
• 005 evita fallback silencioso pra paths inexistentes (o loader lista missing_requested_sources e se houver qualquer item, bloqueia)

Pipeline — 5 steps determinísticos

Depois que os 5 vetos passam, entram 5 steps. A ordem é fixa — cada step recebe o output do anterior como input (contract chaining):

# Rodado pelo Hybrid executor — zero LLM tokens
node squads/squad-creator-pro/scripts/load-business-sops.cjs \
  --business={slug} \
  --namespace={namespace} \
  --paths={paths} \
  --format=yaml

mapped_process:
  source_path: string
  task_name: string
  executor: Human | Agent | Hybrid | Worker
  inputs: []
  outputs: []
  checkpoints: []
  guardrails: []
  dependencies: []

create_from_sop:
  business_slug: "{slug}"
  selectors:
    namespaces: []
    explicit_paths: []
  source_package:
    runtime_mode: full_workspace_mode
    source_of_truth: workspace_canonical
    loaded_sources: []
    missing_requested_sources: []
  creation_brief:
    objective: "{objective derived from SOPs}"
    canonical_sources:
      - path: "{path}"
        class: "executable_process|supporting_context|governance_signal"
    executable_processes:
      - task_name: "{name}"
        executor: "Human|Agent|Hybrid|Worker"
        inputs: []
        outputs: []
        guardrails: []
    supporting_context: [...]
    guardrails: [...]
    open_questions:
      - type: "MISSING|AMBIGUOUS|CONFLICT"
        description: "{what is unclear}"
        impact: "{what it blocks}"

Outputs canônicos & Quality Gate

Os 5 steps produzem 5 outputs — todos com path + formato fixos. Isso é crucial: a próxima sessão do Claude Code pode continuar de onde parou só lendo os arquivos.

Quality Gate como trava final

A task 0 (create-from-sop.md) aponta explicitamente pro quality gate:

## Checklist Reference

Before marking this task complete, verify against: checklists/quality-gate-checklist.md

O quality-gate-checklist define 10 campos obrigatórios por gate, 4 tipos válidos (manual | automated | hybrid | external), 3 severidades (blocking | warning | info), 3 placements (entry | transition | exit), tudo com checklist verificável. Não é opinião — é spec.

Comparativo: SEM AIOX vs COM AIOX (Caso 1)

Agora o lado a lado. Mesmo objetivo: “tenho SOPs YAML do meu negócio, quero transformar em squad.”

Diff dimensional

Caso 2 · Create Squad Pro

O Create Squad Pro (squad-creator-pro) é um animal bem diferente. Enquanto o Create SOP consome SOPs prontos, o Create Squad Pro cria squads a partir de personas/minds reais — gente com framework documentado, skin in the game, voice/thinking DNA extraível.

Arquitetura

Create Squad Pro é uma constelação de 4 architects especializados, cada um com mind extraída e artefatos próprios:

Os 4 agents da constelação

Tasks atômicas — 250+ arquivos

Enquanto o Create SOP tem 4 tasks (1 stub + 3 sub-tasks), o Create Squad Pro tem mais de 250 tasks atômicas cobrindo o ciclo inteiro: research, DNA extraction, clone review, smoke test, pipeline optimization, fidelity scoring, migration, modernization...

# Amostra do diretório tasks/ (grep de tipos)
auto-acquire-sources-*.md        # 4 tasks - busca automática de fontes
clone-mind-*.md                  # 3 tasks - smoke test + dashboard
collect-sources-*.md             # 5 tasks - classify/discover/validate/gap/gate
deep-research-*.md               # 5 tasks - local KB + execute + generate + validate
evd-*.md                         # 3 tasks - voice DNA extraction
etd-*.md                         # 7 tasks - executor type discovery
extract-expert-gold-*.md         # 5 tasks - context/enrichment/filter/multi-lense/validation
extract-implicit-*.md            # 5 tasks - analyze/prioritize/scan/synthesize/validate
extract-knowledge-*.md           # 5 tasks - checklist/framework/sop/source/validation
extract-sop-*.md                 # 4 tasks - analyze/assemble/extract/prepare
find-0-8-*.md                    # 2 tasks - classify/recommend
optimize-*.md                    # 18 tasks - diferentes focos de otimização
plan-squad-*.md                  # 7 tasks - contract/roadmap/architecture/etc
pv-audit-*.md                    # 3 tasks - pedro-valerio audit (deep-dive/overview/sample)
smoke-test-model-routing-*.md    # 4 tasks - comparison/execution/lookup/preflight/report

Minds — extrações de personas

Cada architect tem mind folder com artifacts que codificam o DNA da pessoa. Isso não é memória de sessão, é conhecimento versionado em disco.

Exemplo concreto: META_AXIOMAS do Pedro Valério

O META_AXIOMAS.md não é “biografia” — é um framework de validação com 10 dimensões, cada uma com weight + threshold + veto_power:

meta_axiomas:
  pattern_reference: "docs/analysis/framework-alignment-report.md"
  total_dimensions: 10

  scoring:
    overall_threshold: 7.0
    minimum_per_dimension: 6.0
    veto_on_failure: false  # Default to REVIEW, not VETO

  dimensions:
    1_truthfulness:
      name: "Verdade (Truthfulness)"
      weight: 1.0
      threshold: 7.0
      veto_power: true     # única com veto
      description: "Truth as systemic coherence verified by data"

    2_coherence:
      name: "Coerência (Coherence)"
      weight: 0.9
      threshold: 6.0
      veto_power: false
    # ... 3_strategic_alignment, 4_operational_excellence,
    # 5_innovation_capacity, 6-10 ...

Traduzindo em uso: quando o Create Squad Pro vai validar um squad candidato, ele roda essas 10 dimensões. Truthfulness com threshold 7.0 tem veto_power — se passar disso, BLOCK. As outras 9 só viram REVIEW. Isso é modelagem de julgamento de um humano específico, codificada.

Pipeline alto-nível do Create Squad Pro

Não vou destrinchar todos os steps como no Caso 1 (são dezenas). Mas aqui o mapa geral, referenciando os arquivos de task:

Checklists como quality gates

Comparativo: SEM AIOX vs COM AIOX (Caso 2)

Mesmo objetivo: “quero um squad de copywriting baseado em Alex Hormozi + Ry Schwartz.”

Reflexão: o que AIOX ganha, o que custa

Agora a parte honesta. O AIOX tem custo. Vale pra alguns casos e overhead pra outros. Aqui a leitura que eu faço:

Quando usar AIOX · quando não usar (inferência honesta)

Inferência pessoal: o Italo construiu isso porque já sentiu o custo da não-padronização. Você não escreve 250 tasks + 13 checklists + 6 workflows + 4 architects se você ainda não bateu na parede de “por que o squad de ontem tá diferente do squad de hoje e eu fiz a mesma pergunta”. O AIOX é a resposta a essa dor, não a resposta a um greenfield vazio.