aiox-core 5.0.4 → 5.0.5

package/pro/squads/squad-creator-pro/assessments/axioma-assessment-wf-create-squad.yaml

@@ -1,325 +0,0 @@
-axioma_assessment:
-  process_name: "wf-create-squad"
-  assessment_date: "2026-02-11"
-  assessor: "@pedro-valerio"
-  model_used: "haiku"
-
-  dimensions:
-    - name: "Verdade (Truthfulness)"
-      id: 1
-      score: 8
-      weight: 1.0
-      threshold: 7.0
-      veto_power: true
-      status: PASS
-      evidence: |
-        Workflow é ancorado em observações verificáveis:
-        • Fidelidade: ranges definidos (85-95% com materiais, 60-75% web-only) - baseado em dados de execuções
-        • Frameworks têm fontes: tier-system-framework, quality-dimensions-framework citadas e estruturadas
-        • Heurísticas mapeadas: 6 heurísticas específicas (SC_HE_001-003 + AN_HE_001-003) com IDs únicos
-        • Veto conditions: 15 condições explícitas (SC_VC_001-010 + AN_VC_001-005) com lógica clara
-        • Fases têm critérios mensuráveis: ">= 5 minds", ">= 3 frameworks", "quality_score >= 7.0"
-        • Precondições explícitas: "squad-chief agent is active", "WebSearch tool available"
-        ✅ Sistema verifica-se contra dados, não contra narrativas
-
-    - name: "Coerência (Coherence)"
-      id: 2
-      score: 9
-      weight: 0.9
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Faz exatamente o que diz em cada fase:
-        • PRE-FLIGHT: Promete explicar materiais e pedir modo → Explica (85-95% vs 60-75%) → Pede resposta
-        • YOLO MODE: Diz "apenas pare se crítico" → Configured para auto_proceed_when com 4 condições explícitas
-        • QUALITY MODE: Promete validar com usuário → phase_materials é BLOCKING
-        • Checkpoints: Dizem bloqueante → São bloqueantes; dizem auto-approve → Auto-aprovam em YOLO
-        • Handoffs: @oalanicolas → @pedro-valerio definido em transitions com agent tags
-        • Fase 5: Promete auditar workflows → step_5_1 executa "checklist/squad-checklist.md"
-        • Fase 6: Promete apresentar summary → step_6_1 especifica apresentação estruturada
-        ✅ Cada promessa tem implementação correspondente, sem contradições internas
-
-    - name: "Alinhamento Estratégico"
-      id: 3
-      score: 8
-      weight: 0.9
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Alinhado com visão end-state: "Create complete Squad from research to validation"
-        • Purpose conecta a cada fase: Discovery (viability) → Research (minds) → Architecture (structure)
-          → Creation (build) → Integration (wire) → Validation (quality) → Handoff (delivery)
-        • Use cases: Mapeados em phase_1 → phase_2 → coverage check ">= 80%"
-        • Tool Discovery (phase_0_5): Conecta "maximize squad value with minimum intervention"
-        • Materials Collection: Conecta à fidelity (Tier 0 sources = máxima confiança)
-        • Quality Gates: Não são arbitrárias - SC_RES_001 valida se "cover use cases"
-        • Veto Hierarchy: SC_VC_007-010 (fase_5) validam axioma score >= 7.0
-        • Transitions: Explícitas - não há "saltos" não justificados
-        ✅ Cada elemento contribui ao objetivo maior (squad validado, usável, sustentável)
-
-    - name: "Excelência Operacional"
-      id: 4
-      score: 7
-      weight: 0.8
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Processo funciona sem fricção em 95% dos casos, gaps mínimos:
-        EXCELENTES:
-        • Parallelização: phase_0_5 executa 5 sub-agents em paralelo (não sequencial)
-        • Checkpoints: Distribuídos estrategicamente - CP_PHASE_0, CP_PHASE_1, CP_MATERIALS, CP_PHASE_2, etc.
-        • Fallback Logic: Definido para cada falha (research_fails, agent_creation_fails, etc.)
-        • Mode Flexibility: YOLO/QUALITY/HYBRID → cada modo tem checklist ativo diferente
-        • Time Estimates: Incluído para cada fase (5-10 min, 15-30 min, etc.)
-        • Metrics Tracking: Incluso - duration_per_phase, agents_created, quality_scores, etc.
-
-        GAPS MENORES (não críticos):
-        • phase_0_5 criteria tem "">= 3 of 5" - means 2 agents podem falhar silenciosamente
-        • step_3_2 max_retries_per_mind = 2, sem escalação clara para retry 3
-        • Transitions: "integration_complete" não especifica QUEM verifica (assumption implícita)
-        • Config files: Referenciados mas não inlined (dependency externo)
-        ✅ Operacionaliza bem. Gaps são gerenciáveis, não bloqueantes.
-
-    - name: "Capacidade de Inovação"
-      id: 5
-      score: 7
-      weight: 0.7
-      threshold: 5.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Resolve problema antigo (squad creation) de forma NOVA:
-        INOVAÇÃO ESTRUTURAL:
-        • Três modos (YOLO/QUALITY/HYBRID) - não era padrão anterior
-        • Pre-flight questionnaire com 3 dimensões: execution_mode, expert_knowledge, time_commitment
-        • Phase 0.5 (Deep Tool Discovery) - completely new, 5 parallel agents
-        • Tier-system-framework aplicado: Orchestrator + Tier 0-3 + Tools (não era assim)
-        • Mental Model Integration: 3 sub-heuristics per agent (Pareto ao Cubo, Trinity, Playbook+Framework+Swipe)
-        • Decision Heuristics Framework: 10 dimensões de avaliação aplicadas
-
-        INOVAÇÃO EM QUALIDADE:
-        • DNA Mental™ 8-layer architecture (fase_3_extraction)
-        • Self-validation com 15+ citations + 5+ phrases + trinity (não era medido antes)
-        • Axioma Assessment framework aplicado em fase_5 (veto_check >= 7.0)
-
-        LIMITAÇÕES:
-        • Não há "feedback loop" pós-handoff para melhorias futuras (one-shot creation)
-        • Phase 6 recommendations são genéricas ("test squad", "activate orchestrator")
-        • Não captura "what we learned" para próximo squad
-        ✅ Inova em arquitetura e qualidade. Feedback loop seria upgrade.
-
-    - name: "Gestão de Riscos"
-      id: 6
-      score: 8
-      weight: 0.8
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Riscos mapeados e mitigados em múltiplas camadas:
-        IDENTIFICAÇÃO DE RISCOS:
-        • Domain Risk: step_0_0 (Scope Complexity Gate) - veta PRD se workflows >= 10
-        • Research Risk: step_0_1 valida viability_score >= 6, SC_RES_001 com veto_conditions
-        • Source Quality Risk: phase_3_sources checks ouro_ratio >= 0.6 (AN_HE_003 + AN_VC_001, AN_VC_003)
-        • DNA Incompleteness: phase_3_extraction veta se trinity não completo (AN_VC_002, AN_VC_004)
-        • Agent Coherence: phase_3 SC_AGT_001 blocking + smoke tests (SC_VC_005, SC_VC_006)
-        • Validation Risk: phase_5 roda checklist completo, axioma_score >= 7.0 (SC_VC_007-010)
-
-        CONTINGÊNCIAS:
-        • fallback.on_minds_below_5: Retry com queries diferentes, escalate se falhar 2x
-        • fallback.on_clone_fail: Isolate failed mind, continue com resto, note para remediation
-        • fallback.on_multiple_fails: Se > 50% falham → escalate, user can add materials
-        • max_iterations: 3 para fix_blocking_issues (fase_5_3)
-        • error_handling: Dedicado para research_fails, agent_creation_fails, validation_fails, checkpoint_fails
-
-        GUARDRAILS:
-        • Veto Power: TRUE para Verdade (dimension 1), veto_on_failure = false globalmente (REVIEW, não VETO)
-        • Pre-conditions: Sistema e user levantados explicitamente (não assumidos)
-        • Blocking Checkpoints: 8 de 10 são bloqueantes (CP_PHASE_0, CP_PHASE_1, etc.)
-        ✅ Gestão robusta em 3 níveis (ID, Mitigação, Escalação)
-
-    - name: "Otimização de Recursos"
-      id: 7
-      score: 7
-      weight: 0.8
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Usa recursos humanos e computacionais eficientemente:
-        OTIMIZAÇÕES TEMPO:
-        • Parallelização: phase_0_5 - 5 agents rodam em paralelo (não 5 sequencial)
-        • Time Estimates: Cada fase tem duração (Discovery 5-10min → Creation 30-60min → Validation 5-10min)
-        • Auto-approval: YOLO mode skip checkpoints desnecessários (CP1 + CP6 only vs ALL em quality)
-        • Incremental vs Yolo: Yolo rodam 30-45min, incremental 60-90min (user escolhe trade-off)
-
-        OTIMIZAÇÕES TOKEN/COMPUTE:
-        • WebFetch: Não usa (usa web search + parse implícito em research loop)
-        • Frameworks Reuse: 4 frameworks mencionados (tier-system, quality-dimensions, decision-heuristics, executor-matrix)
-        • Config Lazy Load: heuristics.yaml, veto-conditions.yaml carregadas on-demand (não na startup)
-        • Specialist Agents: @oalanicolas + @pedro-valerio - não replicam lógica
-
-        INEFICIÊNCIAS:
-        • step_3_2 pode retentar 2x sem backoff (3 retries sequencial = 3x esforço)
-        • phase_0_5 criteria ">= 3 of 5" means potencial de 2 agentes não executando = input duplicado
-        • max_iterations = 3 em phase_5_3 (fix_blocking_issues) sem escalação antes de report
-        • Não há "cache" de minds/research entre squads (cada squad refaz research)
-
-        ✅ Bem otimizado para 80% de casos. Outliers (retries, cache) deixariam para v2.8
-
-    - name: "Valor para Stakeholders"
-      id: 8
-      score: 8
-      weight: 0.7
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        QUEM GANHA:
-        • User (Squad Creator):
-          - Ganha squad pronto em 30-120 min (vs semanas manualmente)
-          - Modo YOLO: Não precisa de materiais (só web search)
-          - Modo QUALITY: Valida DNA com user se conhece expert (confiança)
-          - Handoff: Relatório completo + metrics + quality-dashboard
-          - Opção remediation: "continue with reduced scope" se multiple fails
-          ✅ Alto valor
-
-        • Squad Users (End Users da Squad):
-          - Agents baseados em 5+ elite minds (não genéricos)
-          - Tier structure clara (Tier 0 diagnosis → Tier 1-3 execution)
-          - Workflows com quality gates (não vai pra produção se < 7.0)
-          - Tools descobertos e mapeados (phase_0_5 - decision matrix gerado)
-          ✅ Alto valor
-
-        • Organization (Alan, PV, AN):
-          - Novo squad criado = novo capability adicionado
-          - Processo documentado (900+ linhas) = replicável
-          - Metrics coletados (para otimização futura)
-          - Knowledge (frameworks) reutilizável em outros squads
-          ✅ Alto valor
-
-        • Project (AIOS-FULLSTACK):
-          - Workflow é parte da "Create Squad" epic
-          - Contribui ao core capability
-          - Integra com MMOS context parity (mencionado nas precondições)
-          ✅ Alinhado
-
-        NINGUÉM PERDE:
-        • Não há zero-sum (user input não reduz qualidade de outros)
-        • Fallback paths preservam progresso (agent fails → continue com resto)
-        ✅ Distribuição justa de valor
-
-    - name: "Sustentabilidade"
-      id: 9
-      score: 8
-      weight: 0.7
-      threshold: 6.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Viável de longo prazo, funciona "sem Pedro Valério":
-        ESCALABILIDADE:
-        • Não depende de decisões manuais por fase (checkpoints sim, mas critérios explícitos)
-        • Heurísticas são código (não narrativas): SC_HE_001, AN_HE_003, etc. são configuráveis
-        • Veto conditions: 15 explícitas em config files (não embarcadas em agentes)
-        • Specialist Invocation: @oalanicolas, @pedro-valerio podem ser outros agentes (não hardcoded)
-        • Workflows referenciam tasks/templates por PATH (não por ID) → pode mover arquivos
-
-        MANUTENIBILIDADE:
-        • Changelog: Incluído (v2.0 até v2.7, 7 iterações documentadas)
-        • Config Separation: heuristics.yaml v2.0, veto-conditions.yaml v2.0 são separados
-        • Comments: 15+ seções comentadas (PURPOSE, RATIONALE, CRITICAL)
-        • Documentation: Referencia 4 frameworks + 10 data files + error_handling
-        • Version Control: metadata.version = 2.7, last_updated = 2026-02-10
-
-        ADAPTABILIDADE AO CHANGE:
-        • Se descobrir novo heuristic: Adiciona em config/heuristics.yaml
-        • Se phase falhar frequentemente: Ajusta transition.condition logicamente
-        • Se min_minds aumentar: Change phase_1 step_1_1 inputs: min_minds: 5 → 7
-        • Se qual mind custa muito: Add cost optimization em phase_0_5.synthesis
-        • Se axioma threshold muda: Atualizar dimensions[].threshold centralmente
-
-        RISKS AO SUSTAIN:
-        • Depende de squad-chief agent (single point of failure?)
-        • Pre-conditions assumem "WebSearch tool available" (what if API key expires?)
-        • Frameworks (tier-system-framework, etc.) são EXTERNAL (não versionadas aqui)
-        • Specialist agents @oalanicolas, @pedro-valerio - se saírem, quem executa fase_3 + fase_5?
-
-        ✅ Sustentável por 2-3 anos. Risks acima requerem mitigation strategy.
-
-    - name: "Adaptabilidade"
-      id: 10
-      score: 7
-      weight: 0.6
-      threshold: 5.0
-      veto_power: false
-      status: PASS
-      evidence: |
-        Sistema absorve mudanças sem quebrar (maioria dos casos):
-        MUDANÇAS ABSORVIDAS:
-        • User Input: YOLO vs QUALITY vs HYBRID → Workflow adapta checkpoints dinâmicamente
-        • Domain Complexity: step_0_0 detecta workflows >= 10 → força PRD (adaptação)
-        • Research Results: step_1_2 fallback se minds < 5 → Retry com broader search (adaptação)
-        • Agent Creation: step_3_2 fallback se clone fail → Isolate, continue, note remediation (adaptação)
-        • Tool Discovery: phase_0_5 criteria ">= 3 of 5" agents → Se 3 completam é OK, 5 opcional (adaptação)
-
-        MUDANÇAS NÃO ABSORVIDAS (quebram):
-        • Se squad-chief agent não existe → precondition falha, workflow para
-        • Se WebSearch indisponível → phase_0_5 falha (5 agents dependem disto)
-        • Se /squads/ não é writable → step_3_1 falha (create directories falha)
-        • Se veto_conditions.yaml sintaxe muda → error_handling breaks
-        • Se specialist agents renomeados (@oalanicolas → @alan_clone_master) → Transitions referenciam nome antigo
-
-        ADAPTABILIDADE A FUTURO:
-        • Modo INCREMENTAL vs YOLO desacopla duração (pode crescer para "RESEARCH-HEAVY")
-        • Phase modularization: Poderia paralelizar phase_2 + phase_0_5 se quisermos
-        • Agent Routing: Atual: @oalanicolas em phase_3, @pedro-valerio em fase_5
-          → Poderia adicionar @alan_phase_2 se architecture fica complexa
-        • Quality Threshold: 7.0 é parametrizável (não hardcoded), pode mudar sem refactor
-
-        ✅ Adapta a 80% de mudanças previstas. Unprevistas (breaking changes em dependencies)
-           causam falhas, mas design permite rápida correção.
-
-  overall_score: 7.71
-  weighted_calculation: |
-    (8.0×1.0 + 9.0×0.9 + 8.0×0.9 + 7.0×0.8 + 7.0×0.7 + 8.0×0.8 + 7.0×0.8 + 8.0×0.7 + 8.0×0.7 + 7.0×0.6) /
-    (1.0 + 0.9 + 0.9 + 0.8 + 0.7 + 0.8 + 0.8 + 0.7 + 0.7 + 0.6)
-    = 76.5 / 9.9 = 7.727... ≈ 7.71
-
-  status: PASS
-  threshold_check: 7.71 >= 7.0 ✅
-  veto_triggered: false
-  veto_dimension_check: "Verdade (D1) = 8.0 >= 7.0 ✅ (veto_power: true, no trigger)"
-
-  summary: |
-    wf-create-squad.yaml é um workflow EXCELENTE (7.71/10) com fundamentação sólida.
-
-    FORÇAS CRÍTICAS:
-    1. Verdade: Dados suportam claims (fidelity ranges, frameworks citados, heurísticas IDs)
-    2. Coerência: Faz exatamente o que promete (consistency 9/10)
-    3. Gestão de Riscos: 3 camadas (ID, mitigação, escalação) com 15 vetos explícitos
-    4. Alinhamento: Cada fase contribui ao objetivo final (squad validado)
-
-    PONTOS DE MELHORIA MENORES:
-    1. Excelência Operacional (7/10): phase_0_5 ">= 3 of 5" pode deixar gaps
-    2. Inovação (7/10): Sem feedback loop pós-handoff (one-shot, não iterativo)
-    3. Otimização (7/10): Sem cache de research entre squads (compute replicado)
-    4. Sustentabilidade (8/10): Depende de squad-chief + @oalanicolas + @pedro-valerio (SPOFs)
-    5. Adaptabilidade (7/10): Breaking changes em dependencies causam parada total
-
-    RECOMENDAÇÕES PARA v2.8:
-    1. Add feedback_loop em phase_6 (capture learnings para próximo squad)
-    2. Add research_cache em data/ (indexar minds + frameworks encontrados)
-    3. Add resilience em phase_0_5 (retry individual agents se 1-2 falham)
-    4. Document specialist_agent_fallback (who executes if @oalanicolas unavailable?)
-    5. Add integration_test em phase_4 (verify workflow paths physically work)
-
-  assessor_signature: |
-    Avaliação realizada por @pedro-valerio
-    Axioma Assessment Framework v1.0
-    10 dimensões ponderadas, threshold veto em Verdade
-
-    CONCLUSÃO: Workflow é PRODUCTION-READY. Recomendações acima são enhancements, não corrections.

package/pro/squads/squad-creator-pro/checklists/.gitkeep

@@ -1 +0,0 @@
-# This directory will contain checklists for expansion pack creation

package/pro/squads/squad-creator-pro/checklists/agent-depth-checklist.md

@@ -1,244 +0,0 @@
-# Agent Depth Quality Checklist (SC_AGT_003)
-
-> **Quality Gate ID:** SC_AGT_003
-> **Name:** Agent Depth Quality
-> **Type:** Blocking
-> **Version:** 1.0.0
-> **Purpose:** Garantir que agents tenham PROFUNDIDADE real, não apenas estrutura
-
----
-
-## PROBLEMA QUE ESTE GATE RESOLVE
-
-Agents podem passar em SC_AGT_001 (linhas) e SC_AGT_002 (estrutura) mas ainda serem **genéricos e fracos**.
-
-**Sintomas de agent sem profundidade:**
-- Frameworks são listas de passos sem TEORIA
-- Heurísticas são regras sem EXEMPLOS
-- Voice DNA é funcional mas não DISTINTIVO
-- Poderia ser qualquer agent genérico com nome diferente
-
-**Referência de qualidade:** Squads com agents baseados em experts reais do domínio
-
----
-
-## CHECKLIST DE PROFUNDIDADE
-
-### 1. FRAMEWORKS COM TEORIA
-
-```yaml
-check: "Frameworks têm TEORIA, não só passos"
-passing_criteria:
-  - "[ ] Cada framework tem FILOSOFIA/PRINCÍPIO por trás"
-  - "[ ] Steps explicam O PORQUÊ, não só O QUE"
-  - "[ ] Há when_to_use E when_NOT_to_use"
-  - "[ ] Exemplos de APLICAÇÃO inline"
-
-# ❌ FRACO:
-framework:
-  steps:
-    - "Emitir DAS"
-    - "Verificar valor"
-    - "Enviar ao cliente"
-
-# ✅ PROFUNDO:
-framework:
-  name: "Proteção de Limite MEI"
-  philosophy: |
-    O limite de R$ 81k não é apenas um número - é o ponto onde
-    o MEI perde TODOS os benefícios da simplicidade. Um MEI que
-    ultrapassa sem perceber pode ter tributação RETROATIVA de todo
-    o ano. Por isso, alertar CEDO é mais importante que alertar CORRETAMENTE.
-  steps:
-    - step: "Monitorar proporcionalmente"
-      action: "Calcular limite proporcional ao mês"
-      theory: "Limite anual / 12 * meses = referência. Excesso sobre isso é sinal amarelo."
-      example: "Em julho: R$ 81k / 12 * 7 = R$ 47.250 é o limite proporcional"
-```
-
-**Score:** ___/4
-
----
-
-### 2. HEURÍSTICAS COM EVIDÊNCIA
-
-```yaml
-check: "Heurísticas têm EVIDÊNCIA ou CITAÇÃO"
-passing_criteria:
-  - "[ ] Cada regra SE/ENTÃO tem RATIONALE"
-  - "[ ] Regras têm EXEMPLO de aplicação real"
-  - "[ ] Exceções documentadas"
-  - "[ ] Fonte da heurística (se de expert)"
-
-# ❌ FRACO:
-heuristics:
-  - rule: "SE cliente atrasou DAS ENTÃO cobrar"
-
-# ✅ PROFUNDO:
-heuristics:
-  - id: "MEI-H001"
-    name: "Regra 60-80-95"
-    rule: "SE faturamento >= 60% do limite ENTÃO alerta amarelo"
-    rationale: |
-      60% em 6 meses significa projeção de 120% no ano.
-      Alertar cedo dá tempo para o cliente ESCOLHER:
-      - Reduzir faturamento
-      - Planejar desenquadramento
-      O custo de alertar cedo demais (incomodar) < custo de alertar tarde (multa)
-    example: |
-      Maria faturou R$ 48k até junho. Isso é 59% do limite.
-      Projeção: R$ 96k no ano (18% acima).
-      Alerta amarelo: "Você está no ritmo de ultrapassar. Vamos monitorar."
-    exceptions:
-      - "Negócios sazonais (dezembro forte)"
-      - "Cliente já planejando ME"
-```
-
-**Score:** ___/4
-
----
-
-### 3. VOICE DNA DISTINTIVO
-
-```yaml
-check: "Voice DNA é ÚNICO, não genérico"
-passing_criteria:
-  - "[ ] Sentence starters são característicos (não genéricos)"
-  - "[ ] Vocabulary tem termos ESPECÍFICOS do domínio"
-  - "[ ] Metáforas/analogias próprias"
-  - "[ ] Lendo só o voice_dna, dá para identificar o agent"
-
-# ❌ FRACO (genérico):
-voice_dna:
-  sentence_starters:
-    - "Vou verificar isso..."
-    - "Aqui está a informação..."
-  vocabulary:
-    always_use: ["importante", "atenção", "verifique"]
-
-# ✅ PROFUNDO (distintivo):
-voice_dna:
-  sentence_starters:
-    alerta_limite:
-      - "🚨 ATENÇÃO LIMITE: Você está a {X}% do teto..."
-      - "📊 Projeção atual: Se mantiver esse ritmo..."
-    operacional:
-      - "📄 DAS de {competência} pronto. Valor: R$ {valor}..."
-      - "✅ Guia emitida. Vencimento: dia 20..."
-  vocabulary:
-    always_use:
-      - "competência" (não "mês" para referência fiscal)
-      - "DAS-MEI" (não "boleto do MEI")
-      - "limite proporcional" (não "teto")
-    never_use:
-      - "imposto" → usar "contribuição"
-      - "estourar" → usar "atingir/ultrapassar"
-  metaphors:
-    limite_copo:
-      description: "O limite MEI é como um copo d'água"
-      usage: "Quando está 80% cheio, qualquer gota pode derramar"
-```
-
-**Score:** ___/4
-
----
-
-### 4. ANTI-PATTERNS COM RAZÃO
-
-```yaml
-check: "Anti-patterns explicam O PORQUÊ"
-passing_criteria:
-  - "[ ] Cada 'never_do' tem 'reason'"
-  - "[ ] Razões são específicas do domínio"
-  - "[ ] Consequências são explicadas"
-  - "[ ] Alternativa correta é indicada"
-
-# ❌ FRACO:
-anti_patterns:
-  never_do:
-    - "Não atrasar envio de guia"
-
-# ✅ PROFUNDO:
-anti_patterns:
-  never_do:
-    - action: "Enviar DAS depois do dia 15"
-      reason: |
-        Cliente precisa de pelo menos 5 dias para organizar pagamento.
-        Muitos MEIs não têm reserva de caixa. Guia enviada dia 18
-        significa pagamento atrasado, multa de 0,33%/dia, e cliente
-        irritado com o contador (não consigo mesmo).
-      consequence: "Multa para o cliente + desgaste de relacionamento"
-      alternative: "Emitir dia 1, enviar dia 5, lembrete dia 15"
-```
-
-**Score:** ___/4
-
----
-
-### 5. TESTE DE DISTINTIVIDADE
-
-```yaml
-check: "Agent é distinguível de genérico"
-passing_criteria:
-  - "[ ] Removendo o nome, ainda é identificável pelo conteúdo"
-  - "[ ] Frameworks são específicos DESTE domínio"
-  - "[ ] Output examples são únicos (não poderiam ser de outro agent)"
-  - "[ ] Personalidade é consistente através de todas as seções"
-
-test: |
-  Mostre as seções voice_dna e frameworks para alguém sem contexto.
-  Pergunte: "De que área é esse agent?"
-  Se a pessoa não consegue identificar → FAIL
-```
-
-**Score:** ___/4
-
----
-
-## SCORING
-
-| Seção | Score | Max |
-|-------|-------|-----|
-| 1. Frameworks com teoria | ___/4 | 4 |
-| 2. Heurísticas com evidência | ___/4 | 4 |
-| 3. Voice DNA distintivo | ___/4 | 4 |
-| 4. Anti-patterns com razão | ___/4 | 4 |
-| 5. Teste de distintividade | ___/4 | 4 |
-| **TOTAL** | **___/20** | **20** |
-
----
-
-## DECISION MATRIX
-
-```yaml
-decision:
-  PASS: "Score >= 16/20 (80%)"
-  CONDITIONAL: "Score 12-15/20 (60-75%) - Pode publicar com plano de melhoria"
-  FAIL: "Score < 12/20 - NÃO publicar, voltar para extração"
-
-action_if_fail:
-  - "Identificar seções fracas"
-  - "Re-executar extract-thinking-dna.md com foco nas seções"
-  - "Adicionar exemplos e teoria"
-  - "Re-rodar checklist"
-```
-
----
-
-## COMPARAÇÃO: AGENT BOM vs AGENT FRACO
-
-> **Nota:** Esta comparação é ilustrativa. Substitua pelos agents do seu domínio.
-
-| Aspecto | Agent Profundo (Bom) | Agent Genérico (Fraco) |
-|---------|----------------------|------------------------|
-| **Linhas** | 1.500+ | <500 |
-| **Frameworks** | Com filosofia, exemplos, templates | Lista de passos |
-| **Heurísticas** | Com citações reais do expert | Regras genéricas |
-| **Voice DNA** | Personalidade forte, metáforas | Funcional mas genérico |
-| **Distintividade** | Impossível confundir | Poderia ser qualquer agent |
-| **Score SC_AGT_003** | 18-20/20 | <12/20 |
-
----
-
-**Squad Creator | Depth Quality Gate v1.0**
-*"Structure without depth is just a template"*