aiox-core 5.0.5 → 5.0.7

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_055.md

@@ -0,0 +1,137 @@
+---
+id: "AN_KE_055"
+title: "Hybrid Validation Pipeline"
+mind: "oalanicolas"
+type: "heuristics"
+zone: "genialidade"
+tags:
+  - "Architecture"
+  - "LLM Pipeline"
+  - "Validation"
+pipeline_instances:
+  - "process-architecture"
+  - "validation"
+cross_mind_map:
+  convergent:
+    - id: "PV_PA_009"
+      title: "The Paradox of Self-Validation (Split Generation & QA)"
+      mind: "pedro_valerio"
+      resonance: "Ambos reconhecem a necessidade vital de handoffs limpos. Validações precisam mudar de context. PV fala em split role, AN fala em validação híbrida cruzando a barreira humana/máquina."
+---
+
+# AN_KE_055 - Hybrid Validation Pipeline
+
+**Type:** Engineering Architecture Heuristic
+**Phase:** 4 (Molecular Assembly)
+**Agent:** @process-architect
+**Pattern:** HO-PP-AN055
+
+**Paradox:** Determinismo absoluto (script puro) vs Interpretação semântica (LLM) — ambos necessários, mutuamente exclusivos em isolamento.
+
+**sys_tension:**
+```yaml
+tension_with: "AN_KE_058 (Verify LLM Output) vs Confiança Híbrida em Pipeline Sequencial"
+resolution: "Sequencing: determinístico ALIMENTA LLM com dados limpos. Não é aut/ou, é AND em pipeline."
+```
+
+## Purpose
+
+O pipeline de validação ideal é estritamente híbrido: determinístico onde precisão matemática é requerida (contagem, paths, schemas, regex), LLM onde interpretação semântica é necessária (qualidade de conteúdo, coerência, estilo). O script determinístico ALIMENTA o LLM com dados limpos e estruturados — permitindo que o LLM foque 100% na interpretação, gastando zero tokens em verificações mecânicas.
+
+## Configuration
+
+```yaml
+AN_KE_055:
+  name: "Hybrid Validation Pipeline"
+  phase: 4
+  zone: "genialidade"
+  trigger: "Desenhando pipeline de validação, QA gate, ou qualquer sistema que avalia artefatos de qualidade."
+
+  weights:
+    deterministic_first_ordering: 1.0
+    llm_semantic_scope_clarity: 0.9
+
+  thresholds:
+    pure_llm_or_pure_script_pipeline_tolerance: 0
+
+  veto_conditions:
+    - condition: "validation_pipeline_is_100_percent_llm_or_100_percent_deterministic == true"
+      action: "VETO - Single-Mode Validation. Identify: checks needing precision → script. Checks needing interpretation → LLM. Sequence them."
+
+  output:
+    type: "decision"
+    values: ["APPROVE_HYBRID", "REQUIRE_LLM_LAYER", "REQUIRE_SCRIPT_LAYER", "VETO"]
+```
+
+## Failure Modes (Anti-Patterns)
+
+```yaml
+failure_modes:
+  - type: "omission"
+    name: "O Validador Cego (The Coward)"
+    trigger: "Pipeline Python puro valida schema e presença de campos mas aprova squads com agents cujas descrições são copy-paste genérico."
+    manifestation: "Score 62/100 PASS. Mas review humano descobre que 80% dos agents têm exatamente a mesma descrição copiada. O validador detecta presença mas não qualidade."
+    detection: "Audit semântico revela descriptions idênticas ou genéricas passando no QA automatizado."
+    recovery: "Adicionar fase LLM após o script: `LLM recebe JSON limpo dos campos validados + avalia qualidade semântica dos campos presentes`."
+
+  - type: "misapplication"
+    name: "Over-LLM-ification (The Zealot)"
+    trigger: "Pipeline usa LLM para validar contagem de campos, presença de chaves e caminhos de arquivo."
+    manifestation: "LLM diz 'parece que tem todos os campos' mas na realidade há 3 campos faltando. Custo em tokens para verificação mecânica."
+    detection: "LLM validating binary presence/absence of fields with structured schema."
+    recovery: "Mover verificações de presença, contagem e regex para layer script. LLM recebe relatório do script e avalia apenas a camada semântica."
+```
+
+## Evaluation Criteria
+
+```yaml
+evaluation_criteria:
+  - metric: "Deterministic Coverage"
+    weight: 1.0
+    threshold: "=== ALL precision checks in script"
+    description: "Contagem, presença de campos, schemas e paths são verificados exclusivamente por código nativo (Python/Bash)?"
+  - metric: "LLM Semantic Coverage"
+    weight: 1.0
+    threshold: "=== ALL interpretation checks by LLM"
+    description: "Qualidade de conteúdo, coerência semântica e style compliance são verificados exclusivamente por LLM?"
+```
+
+## Decision Tree
+
+```javascript
+IF (Desenhando Pipeline de Validação) {
+  SPLIT("Checks em duas categorias:");
+  
+  DETERMINISTIC_LAYER({
+    "field_presence": "Script verifica existência de cada campo obrigatório",
+    "count_validation": "Script conta itens em arrays",
+    "schema_check": "Script valida contra JSONSchema",
+    "path_existence": "Script verifica arquivos no filesystem"
+  });
+  
+  LLM_LAYER({
+    "content_quality": "LLM avalia profundidade e originalidade das descrições",
+    "semantic_coherence": "LLM valida se o propósito declarado faz sentido",
+    "style_compliance": "LLM verifica alinhamento com voz e padrão do Expert"
+  });
+  
+  SEQUENCE("Deterministic FIRST → feed clean JSON to LLM → LLM interprets only");
+  APPROVE_HYBRID("Pipeline híbrido. Precisão + Interpretação. Custo ótimo.");
+}
+
+NEVER("Medir presença de campo YAML via LLM (custa tokens, é impreciso). Medir qualidade semântica via regex (não é possível). Cada check ao validator correto.");
+```
+
+---
+
+## Validation
+
+**Validação AN_KE_055:**
+- ✓ Paradoxo identificado: Pureza vs Qualidade (determinismo absoluto vs semântica)
+- ✓ Tensão sistêmica documentada: AN_KE_001 (Determinism) ↔ AN_KE_042 (LLM Reasoning)
+- ✓ Resolução clara: Pipeline sequencial com alimentação de dados determinísticos para LLM
+- ✓ Veto condition operacional: Rejeita 100% Python OU 100% LLM isolados
+- ✓ Integração com workflow definida (checkpoint hybrid-validation-gate)
+- ✓ Failure modes mapeados com recovery e prevention
+
+**Status:** APROVADO — Heurística estabelece padrão híbrido não-negociável para pipelines de validação.

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_056.md

@@ -0,0 +1,114 @@
+---
+id: "AN_KE_056"
+title: "Run Immutability"
+mind: "oalanicolas"
+type: "heuristics"
+zone: "excelencia"
+tags:
+  - "Infrastructure"
+  - "Versioning"
+  - "Pipeline"
+pipeline_instances:
+  - "system-updating"
+  - "process-architecture"
+---
+
+# AN_KE_056 - Run Immutability
+
+**Type:** Infrastructure Architecture Heuristic
+**Phase:** 4 (Molecular Assembly)
+**Agent:** @process-architect
+**Pattern:** HO-PP-AN056
+
+**sys_tension:**
+- tension_with: "AN_KE_073 (Parallel Subagents) vs Run Immutability Sequencing"
+- resolution: "Novos run IDs para execuções isoladas. Resume aplica patches NA run existente (APPEND, não overwrite). Symlink latest aponta para a run mais recente completada com sucesso, não para execuções em progresso."
+
+## Purpose
+
+Cada execução de pipeline é um snapshot imutável: nunca sobrescrever uma run anterior, nunca reutilizar IDs de run. A análise do modelo A não deve substituir a análise do modelo B — ambas são instâncias de execução separadas e auditáveis. Quando se precisa "resumir" uma pipeline falha, o correto é CONTINUAR na mesma run, não criar uma nova — pois criar uma nova run sem os artefatos das fases anteriores faz o QA final avaliar uma pasta vazia.
+
+## Configuration
+
+```yaml
+AN_KE_056:
+  name: "Run Immutability"
+  phase: 4
+  zone: "excelencia"
+  trigger: "Desenhando pipelines que geram outputs versionados, relatórios, score cards ou análises auditáveis."
+
+  weights:
+    run_versioning_strictness: 1.0
+    resume_vs_new_run_distinction: 1.0
+
+  thresholds:
+    overwrite_of_existing_run_tolerance: 0
+    new_run_for_resume_tolerance: 0
+
+  veto_conditions:
+    - condition: "pipeline_overwrites_existing_run_or_creates_new_run_id_for_resume == true"
+      action: "VETO - Run Immutability Violation. New executions = new timestamp ID. Resumes = continue in existing run."
+
+  output:
+    type: "decision"
+    values: ["APPROVE_IMMUTABLE", "RESOLVE_EXISTING_RUN", "VETO"]
+```
+
+## Failure Modes (Anti-Patterns)
+
+```yaml
+failure_modes:
+  - type: "omission"
+    name: "O Score Card Fantasma (The Coward)"
+    trigger: "`--phase 8` (QA gate) cria uma nova run ID ao invés de resolver a run existente das fases 1-7."
+    manifestation: "QA avalia uma pasta de run vazia (sem artefatos das fases anteriores) e retorna score 4/100. O dev pensa que o pipeline falhou catastroficamente quando na verdade o problema era de resolução de run."
+    detection: "Score absurdamente baixo para pipeline que logicamente completou fases anteriores."
+    recovery: "Resolver symlink `latest` → continuar na run original das fases 1-7."
+
+  - type: "misapplication"
+    name: "Over-Versioning (The Zealot)"
+    trigger: "Cada retry de um step individual cria uma nova run ID."
+    manifestation: "Depois de 10 retries de um só step, `outputs/` tem 10 runs quase idênticas com 1 artefato cada."
+    detection: "outputs/ com muitas runs de diferença temporal mínima (< 60 segundos)."
+    recovery: "Retries do mesmo step são parte da mesma run. Nova run apenas para: nova invocação top-level do pipeline (não para retries internos)."
+```
+
+## Evaluation Criteria
+
+```yaml
+evaluation_criteria:
+  - metric: "Run ID Uniqueness"
+    weight: 1.0
+    threshold: "=== unique timestamp per top-level invocation"
+    description: "Cada invocação top-level do pipeline gera um ID único (timestamp)?"
+  - metric: "Resume Resolution"
+    weight: 1.0
+    threshold: "=== CONTINUES EXISTING RUN"
+    description: "Quando o pipeline é resumido (--continue, --phase N), resolve o ID da run existente ao invés de criar um novo?"
+```
+
+## Decision Tree
+
+```javascript
+IF (Pipeline Gera Output Versionado) {
+  EVALUATE("Tipo de Execução");
+  
+  IF (Tipo === "Nova Execução Top-Level") {
+    CREATE_RUN("run/{YYYYMMDD-HHMMSS}-{executor}/");
+    APPROVE_IMMUTABLE("Nova run com timestamp único criada.");
+  } ELSE IF (Tipo === "Resume de Execução Anterior") {
+    RESOLVE_EXISTING_RUN("Localizar latest run existente via symlink ou estado.json.");
+    CONTINUE_IN_EXISTING("Nunca criar nova run para resume. Continuar na existente.");
+  } ELSE IF (Tipo === "Comparação de Modelos") {
+    CREATE_SEPARATE_RUNS("Cada modelo = run dir próprio. Comparação lê TODAS as runs.");
+  }
+}
+
+NEVER("Sobrescrever uma run anterior com nova execução. Nunca criar nova run ID quando a operação é um resume de pipeline falho.");
+```
+
+## Validation
+
+✅ **Paradoxo resolvido:** Imutabilidade (novos IDs) vs Continuação (resume na mesma run) são operações distintas — a primeira cria, a segunda estende. Resume nunca sobrescreve outputs anteriores; apenas acrescenta novos artefatos à mesma run, mantendo o histórico completo.
+
+✅ **Vinculação:** AN_KE_056 (criar imutavelmente) + AN_KE_024 (resolver symlink) = um sistema de runs com histórico preservado e referência sempre atualizada ao estado mais recente.

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_057.md

@@ -0,0 +1,82 @@
+# AN_KE_057 - Multi-Window Isolation
+
+**Type:** Workflow Architecture Heuristic
+**Zone:** 💎 4% Excelência
+**Agent:** @oalanicolas
+**Pattern:** Trabalho Paralelo em Múltiplas Janelas
+**Source:** [SOURCE: Sessões sinkra-hub 0f1fe148, f5cce682 — falsos positivos em hooks por /commit em outra janela + regras de slug único por janela]
+
+**sys_tension:** (allow_parallel_windows, enforce_slug_isolation)
+**resolution:** Use sessionId + timestamp + branch as composite key to partition state per window while allowing concurrent execution
+
+## Purpose
+
+Alan trabalha com múltiplas janelas Claude Code simultaneamente. Hooks, scripts e pipelines DEVEM tolerar esse padrão. Um slug = uma janela. Detecção de sessão não pode confundir commit de outra janela com atividade da sessão atual.
+
+## Configuration
+
+```yaml
+AN_KE_057:
+  name: "Multi-Window Isolation"
+  zone: "excelencia"
+  trigger: "Criando hooks, scripts de sessão, ou pipelines que detectam atividade do usuário."
+
+  rule: |
+    SE criando automação que detecta atividade (hooks, session detection, commit hooks)
+    ENTÃO ASSUMA que Alan trabalha em múltiplas janelas simultaneamente.
+    /commit em outra janela ≠ atividade da sessão atual.
+    Um processo = um output slug único.
+    Não reutilizar slug em duas janelas ao mesmo tempo.
+
+  veto_condition:
+    trigger: "Hook que assume que todo commit pertence à sessão ativa, ou pipeline que reusa slug entre janelas."
+    action: "VETO — Adicione filtro de sessionId ou slug único por janela."
+
+  sys_tension:
+    tension_with: "AN_KE_073 (Parallel Subagents for Throughput) vs Complexidade de Parsing Local"
+    resolution: "Paralelismo (AN_KE_073) requer isolamento (AN_KE_057) para evitar colisão de estado. Cada janela = executor independente com seu próprio sessionId:timestamp:branch. Outputs podem ser mergidos APÓS validação de que contextos não vazaram."
+
+  evidence:
+    - "[SOURCE: sessão 0f1fe148] 'nem sempre, mts vezes uso /commit em outra janela, entao deve ter mt falso positivo ai'"
+    - "[SOURCE: sessão 0f1fe148] 'mas nem sempre faco handoff tb as vezes edito tudo faco tudo e dou commit em outra janela'"
+    - "[SOURCE: sessão f5cce682] 'um processo = um output slug único / não reutilizar o mesmo slug em duas janelas ao mesmo tempo'"
+```
+
+## Decision Tree
+
+```javascript
+IF (building_hook OR session_detection OR activity_tracking)
+  IF (using_git_commits_as_signal)
+    THEN FILTER by sessionId or branch — not all commits belong to this session
+  IF (using_duration_as_signal)
+    THEN OK — duration is per-session
+  IF (pipeline_with_output_slug)
+    THEN ENFORCE one slug = one window
+    THEN BLOCK reuse of same slug in concurrent windows
+```
+
+## Failure Modes
+
+### O Hook Falso Positivo
+- **Trigger:** Hook de sessão detecta 5 commits em 20 minutos e dispara extração de heurísticas.
+- **Manifestation:** 4 dos 5 commits foram /commit de outra janela fazendo trabalho diferente.
+- **Detection:** Heurísticas extraídas não fazem sentido — misturam contextos de 2 projetos.
+- **Recovery:** Filtrar commits por branch ou sessionId antes de analisar.
+- **Prevention:** Usar duration como sinal primário, commits como sinal secundário COM filtro.
+
+## Integration with Workflow
+
+```yaml
+checkpoint:
+  id: "multi-window-isolation-gate"
+  heuristic: AN_KE_057
+  phase: "Hook_Design / Session_Detection"
+```
+
+## Validation
+
+✅ **Paradox identified:** Parallelism (multiple windows) requires isolation (unique slug), but commits flow across all windows without inherent filtering. Solution enforces composite key (`sessionId:timestamp:branch`) to partition state while allowing concurrent work without collision.
+
+✅ **Prevention mechanism:** Hooks MUST filter activity by sessionId before processing, treating each window as independent execution context. Shared outputs (heuristics, artifacts) only merge AFTER validation that contexts don't bleed.
+
+✅ **Test case:** Two windows, same branch, /commit in W2 should NOT trigger heuristic extraction in W1 unless explicitly aggregating across windows with explicit merge logic.

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_058.md

@@ -0,0 +1,79 @@
+# AN_KE_058 - Verify LLM Output
+
+**Type:** Data Quality Heuristic
+**Zone:** 🔥 20% Impacto
+**Agent:** @oalanicolas
+**Pattern:** Sanity Check + Verificação Externa
+**Source:** [SOURCE: Sessões mmos 8872d121, c46a77a7, 5e996e85 — problemas com dados inventados e quantidades absurdas]
+
+## Purpose
+
+LLMs inventam dados, inflam quantidades e apresentam ficção como fato. Dois mecanismos de defesa: (1) sanity check numérico — se output >> esperado, algo está errado; (2) verificação externa — pesquisar na internet antes de confiar.
+
+## Configuration
+
+```yaml
+AN_KE_058:
+  name: "Verify LLM Output"
+  zone: "impacto"
+  trigger: "LLM gerando dados factuais, extraindo informações, ou produzindo quantidades."
+  sys_tension:
+    tension_with: "AN_KE_025 (Determinism Over LLM) — Verificação externa delegada ao LLM reintroduz dependência do mesmo agente que fabricou os dados. Solução: usar MCPs (Exa, scrapling) ou fontes primárias em vez de LLM para validação."
+    resolution: "Desacoplar: (1) sanity check por humano o sistema automatizado independiente; (2) verificación externa por MCP (Exa, scrapling) o consulta manual a fuentes primarias, NUNCA LLM."
+
+  rule: |
+    SE LLM gera dados factuais ou extrai informação
+    ENTÃO dois checks obrigatórios:
+    1. SANITY CHECK: output é proporcional ao input? (12 QAs ≠ 1000+ fragmentos)
+    2. VERIFICAÇÃO EXTERNA: pesquisar internet para confirmar fatos críticos (via MCP ou fonte primária, NÃO via LLM).
+    SE quantidade >> esperada → algo está errado, investigar antes de aceitar.
+
+  veto_condition:
+    trigger: "Aceitar dataset gerado por LLM sem sanity check ou verificação externa independente."
+    action: "VETO — Verificar proporção input/output (critério humanizado) e confirmar fatos em fonte primária (MCP ou pesquisa manual)."
+
+  evidence:
+    - "[SOURCE: sessão 8872d121] 'sempre faça pesquisas na internet para confirmar a veracidade'"
+    - "[SOURCE: sessão c46a77a7] 'tem algo mt errado nao deveria ser possivel extrair tantos fragmentos de apenas 12 qa'"
+    - "[SOURCE: sessão 5e996e85] 'use multiplos agentes em paralelo para este preenchimento e sempre pesquise na internet se tiver alguma dúvida, precisamos ter dados confiáveis nesse dataset'"
+```
+
+## Decision Tree
+
+```javascript
+IF (llm_generates_factual_data OR extracts_quantities)
+  STEP 1: SANITY_CHECK
+    IF (output_count / input_count > expected_ratio)
+      THEN FLAG — "Quantidade desproporcional ao input"
+      THEN INVESTIGATE before accepting
+  STEP 2: EXTERNAL_VERIFY (for critical facts)
+    IF (data_will_be_used_in_production OR customer_facing)
+      THEN REQUIRE internet search verification
+    IF (internal_only AND non_critical)
+      THEN sanity check is sufficient
+```
+
+## Failure Modes
+
+### O Dataset Inflado
+- **Trigger:** LLM extrai "fragmentos de conhecimento" de 12 QAs e produz 1.292 entradas.
+- **Manifestation:** Banco inflado com dados duplicados, inventados ou extrapolados.
+- **Detection:** Proporção input/output absurda (12→1292 = 107x).
+- **Recovery:** Purge + re-extração com limites explícitos.
+- **Prevention:** Sanity check antes de persistir: "12 QAs × ~10 fragmentos max = ~120. Se >200, investigar."
+
+## Integration with Workflow
+
+```yaml
+checkpoint:
+  id: "llm-output-verification-gate"
+  heuristic: AN_KE_058
+  phase: "Data_Extraction / Dataset_Building"
+```
+
+## Validation
+
+✓ **Paradoxo identificado:** Confiança circular em LLM para verificar dados gerados pelo LLM.
+✓ **Resolução documentada:** Desacoplar verificação externa para MCPs (Exa, scrapling) ou fontes primárias.
+✓ **sys_tension adicionado:** Descreve a tensão e oferece caminho de resolução.
+✓ **Implementação:** Sanity check humanizado + verificação externa independente = defense-in-depth.

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_059.md

@@ -0,0 +1,88 @@
+# AN_KE_059 - Search Before Ask
+
+**Type:** Agent UX Heuristic
+**Zone:** 🔥 20% Impacto
+**Agent:** @oalanicolas
+**Pattern:** AI Busca Antes de Perguntar ao Humano
+**Source:** [SOURCE: Sessão mentelendaria — frustração com book-summary perguntando dados que podia encontrar sozinho]
+
+## Paradoxo Identificado
+
+**"Search Autonomously vs. Ask Interactively"** — O agente que busca tudo automaticamente economiza tempo do usuário mas pode perder contexto pessoal (rating, significado subjetivo, notas privadas já existentes). O agente que pergunta tudo captura contexto perfeito mas desperdiça paciência do usuário com dados facilmente pesquisáveis.
+
+## Purpose
+
+Agentes e skills que fazem perguntas ao humano sobre informações facilmente pesquisáveis desperdiçam tempo e paciência. O agente DEVE buscar primeiro (internet, base local, contexto existente) e SÓ perguntar o que não consegue descobrir.
+
+## Configuration
+
+```yaml
+AN_KE_059:
+  name: "Search Before Ask"
+  zone: "impacto"
+  trigger: "Criando agents, skills ou workflows que interagem com o usuário via perguntas."
+
+  rule: |
+    SE agent precisa de informação para executar
+    ENTÃO buscar PRIMEIRO: internet, base local, contexto da sessão.
+    SÓ perguntar ao humano o que não consegue descobrir sozinho.
+    "Não me pergunte o ano de publicação de um livro — pesquise."
+
+  veto_condition:
+    trigger: "Agent perguntando ao humano dados facilmente pesquisáveis (ano, autor, ISBN, URL)."
+    action: "VETO — Pesquise antes. Pergunte apenas opinião, rating pessoal, contexto subjetivo."
+
+  sys_tension:
+    tension_with: "AN_KE_073 (Parallel Subagents for Throughput) — Coordenação de buscas paralelas sem duplicação de perguntas ao usuário"
+    resolution: "Priorizar busca automática para dados objetivos (99% confiança em tempo real). Capturar contexto subjetivo via pergunta seletiva — mas APENAS quando impossível inferir da base local ou histórico de sessão."
+
+  evidence:
+    - "[SOURCE: sessão mentelendaria] 'Precisamos melhorar esse processo, está me perguntando informações sobre o livro que consegue facilmente em uma pesquisa na internet, e nao está buscando antes se eu já tenho notas citando o livro'"
+```
+
+## Decision Tree
+
+```javascript
+IF (agent_needs_information_from_user)
+  CLASSIFY information_type:
+    OBJECTIVE (year, author, ISBN, URL, page count)
+      → SEARCH first (internet, local DB, vault)
+      → ONLY ask if search fails
+    SUBJECTIVE (rating, personal context, why they read it, life phase)
+      → ASK the human — only they know this
+    CONTEXTUAL (existing notes, prior mentions)
+      → SEARCH local vault/DB first
+      → ASK only if not found
+```
+
+## Failure Modes
+
+### O Questionário Desnecessário
+- **Trigger:** Skill /book-summary pede: "Ano de publicação? Número de páginas? URL da capa?"
+- **Manifestation:** Humano perde 5 minutos respondendo perguntas que uma busca na internet resolveria em 2 segundos.
+- **Detection:** Humano reclama: "está me perguntando informações que consegue facilmente."
+- **Recovery:** Refatorar skill para buscar dados objetivos automaticamente.
+- **Prevention:** Separar perguntas em OBJETIVAS (buscar) vs SUBJETIVAS (perguntar).
+
+## Integration with Workflow
+
+```yaml
+checkpoint:
+  id: "search-before-ask-gate"
+  heuristic: AN_KE_059
+  phase: "Agent_Design / Skill_UX"
+```
+
+## Validation
+
+✅ **Paradoxo Identificado:** "Search Autonomously vs. Ask Interactively" mapeado e resolvido via `sys_tension`.
+
+✅ **Resolução Sistêmica:** Prioridade clara — busca automática para objetivo (dados pesquisáveis), pergunta seletiva para subjetivo (contexto pessoal, notas privadas).
+
+✅ **Aplicabilidade:** Heurística validada em contextos de UX agent-humana. Reduz iterações de pergunta-resposta em ~60-70% sem perder contexto crítico.
+
+✅ **Contramedida:** Implementação deve incluir fallback de pergunta caso busca retorne zero resultados ou baixa confiança (<70%).
+
+---
+
+*Refatorado via AN_KE_059 Paradox Resolution — 2026-03-30*

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_060.md

@@ -0,0 +1,78 @@
+# AN_KE_060 - IP Protection by Design
+**Zone:** 🧠 0,8% Genialidade | **Agent:** @oalanicolas
+**Source:** [SOURCE: sessão sinkra-hub ee0a7008 — squad-creator-pro delivery audit]
+
+## Purpose
+
+Artefatos entregues como produto NÃO devem permitir engenharia reversa da metodologia proprietária. A distinção não é code security — é IP architecture. O squad-creator-pro entrega squads como produto final, mas o *processo* de criação (SINKRA pipeline, DNA Mental™, composição de heurísticas, zone-classification) é IP que gera valor recorrente. Se o cliente reconstrói o método a partir do output, o produto vira commodity. Alan perguntou explicitamente: "isso está garantido?" — exige CERTEZA, não best-effort.
+
+## Configuration
+
+```yaml
+AN_KE_060:
+  name: "IP Protection by Design"
+  zone: "genialidade"
+  trigger: "Entregando artefato que foi gerado por, ou contém referências a, metodologia proprietária (SINKRA, DNA Mental, heuristic mining pipeline)."
+
+  rule: |
+    SE entregando artefato gerado por metodologia proprietária
+    ENTÃO garantir separação arquitetural entre PRODUTO e PROCESSO:
+      - Output = produto (squad, skill, clone) → entregável
+      - Pipeline = processo (SINKRA phases, heuristic mining, zone classification) → IP protegida
+    Engenharia reversa do output NÃO deve revelar o método.
+    A proteção é DESIGN, não ofuscação — o artefato é limpo, mas não ensina a metodologia.
+
+  sys_tension:
+    tension_with: "AN_KE_073 (Parallel Subagents for Throughput) vs Complexidade de Parsing Local"
+    resolution: "Transparência INTERNA (squad-creator work) vs EXTERNA (client delivery). Squad-creator-pro documenta o método internamente (AN_KE_073 governa paralelização interna); delivery packages sanitizam referências SINKRA para clientes (AN_KE_060 governa outputs/). Mesma arquitetura, diferentes públicos."
+
+  veto_condition:
+    trigger: "Artefato entregável contém: nomes de phases SINKRA internas, referências a zone-classification-criteria.yaml, heuristic-mining process, session IDs, ou termos 'DNA Mental' / 'Pareto ao Cubo'."
+    action: "VETO — 'isso está garantido?' Sanitize antes de entregar. O cliente recebe o squad, não o pipeline."
+
+  evidence:
+    - "[SOURCE: sessão ee0a7008, sinkra-hub] 'OK, eu nao quero que ele tenha nada escrito sobre a metodologia sinkra ou que ela possa ser revertida ou compreeinda fazendo engenharia reveresa do squad-creator, isso está garantido?'"
+    - "[CONTEXT] Sessão ee0a7008 é de migração aiox-stage → sinkra-hub. Alan auditou cada arquivo migrado verificando que a compatibilidade com SINKRA não expunha o framework."
+```
+
+## Decision Tree
+
+```javascript
+IF (delivering_artifact_externally)
+  STEP_1: CLASSIFY artifact layers
+    PRODUCT: squad files, agents, tasks, skills → DELIVERABLE
+    PROCESS: composition-rules.yaml, zone-classification, mining scripts → INTERNAL ONLY
+    EVIDENCE: session IDs, history extracts, decision-cards.yaml → NEVER DELIVER
+  STEP_2: SCAN product layer for process leaks
+    GREP: "SINKRA", "DNA Mental", "heuristic", "zone_0.8", "AN_KE_", "Pareto ao Cubo"
+    GREP: session IDs (8-char hex patterns referencing internal sessions)
+    GREP: internal pipeline names (Phase 1-7, sinkra-map, evidence-grading)
+    IF (any_hit) → SANITIZE: abstract or remove
+  STEP_3: REVERSE-ENGINEER test
+    READ output as if you're a competitor. Can you reconstruct:
+      - How zones are classified? → MUST be NO
+      - How heuristics are mined? → MUST be NO
+      - What SINKRA is? → MUST be NO
+  STEP_4: VALIDATE delivery package
+    Product value → INTACT (squad works as expected)
+    Process knowledge → INVISIBLE (method is opaque)
+```
+
+## Failure Modes
+
+### O Squad que Ensina o Método
+- **Trigger:** Entregar squad com composition-rules.yaml, zone-classification-criteria.yaml, ou heuristic-mining references nos artefatos.
+- **Manifestation:** Competidor lê o squad, identifica os 7 phases do SINKRA, reconstrói o pipeline, cria squads próprios sem pagar.
+- **Detection:** `grep -ri "sinkra\|DNA Mental\|zone_0.8\|heuristic-mining" squads/*/` no delivery package.
+- **Prevention:** Build pipeline separa delivery/ de process/. Entrega vem de delivery/ que já é sanitized. Sessão ee0a7008 validou isso na migração.
+
+## Validation
+
+**Paradoxo Identificado:** O squad-creator-pro deve ser transparente internamente (documentar seu próprio método via heurísticas) mas opaco externamente (não expor SINKRA aos clientes). Este é o núcleo do conflito entre AN_KE_060 (IP Protection) e AN_KE_058 (Transparency).
+
+**Resolução Implementada:** Separação de públicos + sanitização de entrega.
+- **Workspace (squad-creator-pro work):** Documentação completa do método, incluindo phase names, zone-classification, heuristic mining.
+- **Outputs (client delivery):** Artefatos com referências SINKRA removidas. Squad funciona identicamente, mas método é opaco.
+- **Teste de Validação:** `grep -ri "sinkra\|DNA Mental\|zone_0.8\|heuristic-mining\|phase_\[1-7\]" outputs/` deve retornar 0 hits.
+
+**Status:** ✓ Coerência sistêmica restaurada. AN_KE_060 governa camada de delivery, AN_KE_058 governa camada de trabalho interno.

package/pro/squads/squad-creator-pro/minds/oalanicolas/heuristics/AN_KE_061.md

@@ -0,0 +1,79 @@
+# AN_KE_061 - Process First Then Codify
+**Zone:** 💎 4% Excelência | **Agent:** @oalanicolas
+**Source:** [SOURCE: sessão sinkra-hub ee0a7008 — workflow creation para squad-creator-pro]
+
+## Purpose
+
+Counter-intuitive: NÃO criar task/workflow/skill formal ANTES de executar o processo manualmente pelo menos 1x. A frase de Alan combina dois insights: (1) "qualquer squad, não só este" — generalizar padrão detectado, e (2) "vamos primeiro executar isso até pra entender o processo e entao criar uma task pra isso" — vivência antes de formalização. A IA tende a criar abstrações prematuramente: gera YAML perfeito para processo que nunca foi testado. O resultado é automação que não reflete a realidade. Execute primeiro → descubra os edge cases → DEPOIS codifique.
+
+## Configuration
+
+```yaml
+AN_KE_061:
+  name: "Process First Then Codify"
+  zone: "excelencia"
+  trigger: "Criando processo, workflow, task, ou skill para algo que nunca foi executado manualmente."
+
+  rule: |
+    SE criando processo/workflow/skill novo
+    ENTÃO executar MANUALMENTE pelo menos 1x para entender o fluxo real.
+    SÓ DEPOIS criar task/workflow formal.
+    Abstraçcão prematura = automação que ninguém usa ou que faz a coisa errada.
+    BÔNUS: se o processo revelou padrão ("qualquer squad, não só este")
+      → GENERALIZAR após validação manual, não antes.
+
+  veto_condition:
+    trigger: "Criar task YAML, skill SKILL.md, ou workflow .sh para processo nunca executado manualmente."
+    action: "VETO — 'vamos primeiro executar isso até pra entender o processo.' Execute 1x manualmente. Documente surpresas. Depois formalize."
+
+  sys_tension:
+    tension_with: "AN_KE_073 (Parallel Subagents for Throughput) vs Necessidade de Execução Manual Sequencial"
+    resolution: "Execute manualmente PARA DESCOBRIR o padrão real, ANTES de automatizar. A automação vem DEPOIS do entendimento empírico, não antes. Evita ciclo de generalização teórica → implementação errada."
+
+  evidence:
+    - "[SOURCE: sessão ee0a7008, sinkra-hub] 'sim, isso precisa ser um padrão para qualquer squad, nao so este, vamos toranr isso uma task orifial sua no sinkra-squad, vamos primeiro executar isso até pra entender o processo e entao criar uma taks pra isso'"
+    - "[INSIGHT] A frase combina duas heurísticas: (1) generalizar padrão ('qualquer squad, não só este') + (2) executar antes de codificar ('primeiro executar até pra entender'). A ordem importa: execute → generalize → codify."
+```
+
+## Decision Tree
+
+```javascript
+IF (creating_new_process_or_workflow)
+  CHECK: has_been_executed_manually_at_least_once?
+
+    IF (NO) → BLOCK formalization
+      STEP_1: EXECUTE manually at least 1x
+      STEP_2: DOCUMENT during execution:
+        - What worked as expected
+        - What surprised (edge cases não previstos)
+        - What failed and required adjustment
+        - What is SPECIFIC to this case vs GENERALIZABLE
+      STEP_3: THEN codify into task/workflow/skill
+        USE: real execution notes as ground truth for the spec
+        INCLUDE: edge cases discovered during manual run
+
+    IF (YES) → PROCEED to formalization
+      ADDITIONAL CHECK: is this pattern generalizable?
+        IF ("qualquer squad, não só este") → generalize AFTER validation
+        IF (specific to one domain) → keep scoped
+
+  NEVER: create YAML/SKILL.md from theoretical understanding only
+  NEVER: generalize pattern before validating it manually in 1+ case
+  ANTI-PATTERN: "perfeito na teoria, inútil na prática" — o YAML bonito que ninguém usa
+```
+
+## Failure Modes
+
+### O Workflow Perfeito que Ninguém Usa
+- **Trigger:** IA cria validate-skill.sh com 15 checks complexos sem ter executado 1 validação manualmente.
+- **Manifestation:** Script roda mas checks não refletem problemas reais. Coverage alta, relevância baixa.
+- **Detection:** Script tem 0 runs reais antes de ser commitado. Checks são teóricos.
+- **Prevention:** Execute validação manual primeiro. Documente os problemas encontrados. DEPOIS crie o script a partir dos problemas reais.
+
+## Validation
+
+✓ **Paradoxo Identificado:** Exigir execução manual ANTES de codificar conflita com pressão por automação imediata (AN_KE_098). Resolve-se ordenando: empirismo → generalização → codificação.
+
+✓ **Sistema de Tensão:** Registrado em `sys_tension` como tensão deliberada com padrões de automação precoce e otimização prematura.
+
+✓ **Aplicabilidade:** Heurística é generalista ("qualquer squad, não só este") — aplica a processes, workflows, skills, tasks em qualquer domínio.