aiox-core 5.0.5 → 5.0.8

package/pro/squads/squad-creator-pro/minds/pedro_valerio/heuristics/PV_KE_099.md

@@ -0,0 +1,82 @@
+---
+id: "PV_KE_099"
+title: "The Staging Isolation Law (Production Sanctity)"
+mind: "pedro_valerio"
+type: "heuristics"
+tags:
+  - "Infrastructure"
+  - "Execution Standards"
+pipeline_instances:
+  - "hybrid-ops"
+sys_tension:
+  tension_with: "AN_KE_021 (Repair Layer Between Generator and Validator)"
+  resolution: "Staging isolation is structural firewall for data integrity. Repair layers (validation, schema healing) operate within Staging boundaries—never bypass Staging firewall. Complexity of local parsing reconciles by performing all mutations in Staging with deterministic repair patterns before Production promotion."
+---
+
+# PV_KE_099 - The Staging Isolation Law (Production Sanctity)
+
+**Type:** Infrastructure Heuristic
+**Zone:** 🧠 0.8% Genialidade | **Agent:** @hybridOps:clickup-engineer
+**Source:** [SOURCE: SINKRA-v4.md | Capítulo 15: Regra 5: Staging e Produção Separados]
+
+## Purpose
+Garantir a sacralidade absoluta do ambiente de Produção ("O Sangue Vivo da Empresa"). Esta heurística (Commandment) declara que TODO Motor de Automação, Banco de Dados ou Orquestrador SINKRA (Ex: N8N, Supabase) deve, mandatoriamente, existir em dois Reinos Estritamente Isolados: Staging (Laboratório) e Produção (Realidade). Programar, testar lógicas novas ou dar "bypass na verificação para testar rápido num projeto quente", rodando scripts de automação ou Agentes diretamente na URL/Banco que o Cliente final e a Operação Master habitam é o maior pecado da Engenharia de Processos. Um erro minúsculo em Produção por "Test-Drive" no Flow corrompe massas de dados irreversíveis em segundos.
+
+## Configuration
+```yaml
+PV_KE_099:
+  name: "Absolute Staging vs Production Firewall"
+  zone: "zone_0.8"
+  trigger: "Fase 7 (Implementation) ou Manutenção contínua de Ferramentas. O Engenheiro atualiza, altera, ou cria Workflows e Bancos de Controle."
+  evidence_threshold: "structural_logic"
+  rule: |
+    O Sistema Tecnológico DEVE conter SEGREGAÇÃO FÍSICA E LÓGICA DE DADOS:
+    1. Base de Staging: URLs diferentes (`staging-n8n.domain.com`), Bancos Diferentes (`db_staging`), Redis Indexes Separados (Ex: Index 2). Usado para Criação, Falha Livre e Teste (Mínimo 24h para fluxos críticos).
+    2. Base de Produção: URLs Oficiais (`n8n.domain.com`), Bancos Core (`db_production`). Protegida por Backups e Logs estritos.
+    - Se um Desenvolvedor logar no Painel de Produção para "corrigir rapidinho um JS ou prompt do Agente", sem transpor o Workflow Validado do Staging para Produção de forma sistêmica, seu acesso operacional é revogado.
+```
+
+## Decision Tree
+```javascript
+IF (a_developer_needs_to_update_or_hotfix_an_ongoing_AIOX_Automation)
+  STEP_1: EXAMINE the Environment Domain.
+  STEP_2: ENFORCE the Firewall.
+    IF (The Developer asks: 'It\'s just a typo in the webhook path, let me fix it on Production so the queue unblocks immediately.')
+      -> VETO: Editing logic layers directly in Production opens a multi-vector vulnerability. The typo fix could break the payload parser. You do not touch the pulsing heart while running.
+    IF (The Developer fixes on Staging, pushes a mock payload, verifies 100% Schema match via Logs, backs up Production DB, and then Deploys the Workflow.)
+      -> ACCEPT: Operational Discipline. The predictability of the organism is maintained.
+NEVER:
+  Confundir "Agilidade Operacional" com irresponsabilidade de Cowboy Coder. "Desenvolver Ágil" é transicionar Fases de T (Staging) para L (Live) no menor tempo possível sem quebrar a ponte. Programar na Ponte de Live é destruir o SINKRA.
+```
+
+## Failure Modes
+
+### Misapplication / Excess: "O Bloqueio Burocrático de Camadas Espelho"
+- **Trigger:** A Equipe exige Ambientes Multi-Tier gigantescos copiando empresas bilionárias (Dev Local de 5 containers, Dev Test, QA, Staging, Pre-Prod, e Produção) para atualizar uma String Básica Num Custom Field do Monday ou ClickUp de 2 pessoas num Setor secundário SINKRA.
+- **Manifestation:** Manutenção de fluxos estagna dolorosamente. Fazer um Deploy de modificações minúsculas não-estruturais demora Semanas passando por esteiras de CICD complexas super -dimensionadas para a realidade da Agência/Negócio PME (L4 Operacional Tático Típico).
+- **Detection:** Reclamações que SINKRA transformou Vendas num ambiente hostil como "Averiguação de Código Nuclear do Pentágono", matando a maleabilidade Orgânica do Processo frente ao Cliente na Ferramenta Visível.
+- **Recovery:** A Lei do Isolamento Staging (PV_KE_099) protege a Execução Algorítmica (Workers e DataBase Cores). O Design e Ajuste Visual (Filtros no Painel Front-End/ClickUp de Status Visuais) muitas vezes alteram-se com elasticidade perante Feedback dos Operadores sem violar um "Código". O Parede de Firewall de Staging é para os ROBÔS, APIs, BANCOS E WORKFLOWS DO MOTOR, onde as máquinas falham milhões de vezes num loop sem parar.
+
+### Omission / Failure to Activate: "O Tiro Múltiplo no Próprio Pé (Crash Cego)"
+- **Trigger:** Configurações apressadas nas Ferramentas No/Low-code (N8N, Make) de onde O Desenvolvedor ativa o Status `Active` na Nuvem e já solta o link de Integração Operacional Final pros Vendedores, mandando Dados Quentes. 
+- **Manifestation:** Três semanas depois, um gestor pede pra "adicionar uma Coluna" enviada pelo Workflow. O Dev entra no Painel, edita a lógica, comete um Erro Crítico no parse JSON do Nodo-3, Salva e Aciona. Cerca de 80 E-mails que estavam na Fila, em Produção, caem no Nodo-3 simultaneamente. Todos falham, quebram os registros Originais, mandam status `Undefined` para API do ERP e a Contabilidade lança Faturas duplicadas ou nulas pros 80 clientes nos próximos 3 segundos. Bip.
+- **Detection:** Destruição sistêmica imaculada, multas enormes, Clientes P da vida, e Operações desabando de ponta a cabeça gritando no Slack contra TI, de onde alguém exclama: "Subi sem testar o IF".
+- **Recovery:** Extirpamento Intransigente de Acesso Compartilhado de Editores ao Backend Quente. A Operação e a API Master de Produção MUDAM A SENHA para o Desenvolvedor; Deploys tornam-se Mecânicos e Versionados Via Github JSON Repo. Programação por Interface Gráfica em URL viva de Motor de Automação gera tragédia matemática invariável.
+
+## Paradox & Systemic Tension
+
+**Identified Paradox:** PV_KE_099 mandates absolute Staging/Production firewall ("Production Sanctity") while acknowledging operational reality requires rapid hotfixes under time pressure. The heuristic creates a tension between:
+- **Rigidity:** Zero Production edits = slow recovery, operational paralysis when errors cascade
+- **Pragmatism:** Hotfixes to unblock critical flows require immediate Production patching
+
+**Resolution Path:** The firewall applies categorically to **logic-layer mutations** (webhooks, JSON parsing, workflow paths, database schema). Front-end config changes, visual filters, and non-structural adjustments may bypass Staging under **incident escalation protocol** with automated rollback within 10 minutes.
+
+---
+
+## Validation
+
+✓ **Structural Logic:** Enforced via N8N environment separation, Supabase RLS policies per tier, Redis index segregation
+✓ **Authority:** Access revocation mechanism documented; incident escalation requires incident commander approval
+✓ **Failure Detection:** Production deployment logs trigger alerts; rollback automation validates schema integrity
+✓ **Paradox Resolution:** Dual-path architecture (logic-firewall / config-agility) tested via staging mock scenarios
+✓ **Alignment:** Consistent with SINKRA execution standards (Layer 2) and operational resilience patterns

package/pro/squads/squad-creator-pro/minds/pedro_valerio/heuristics/PV_KE_100.md

@@ -0,0 +1,81 @@
+---
+id: "PV_KE_100"
+title: "The Pipeline Completion Commandment (Go-Live Governance)"
+mind: "pedro_valerio"
+type: "heuristics"
+tags:
+  - "Documentation Phase"
+  - "Process Governance"
+pipeline_instances:
+  - "hybrid-ops"
+sys_tension:
+  tension_with: "AN_KE_049 (Ship First, Doc Later) vs. Pipeline Completion Rigor (Documentation Mandatory Before Go-Live)"
+  resolution: "Compliance Score >= 80 enforces minimum sufficiency: operational coherence + runbooks + agent versioning mandatory; aesthetic perfection beyond 85+ is forbidden (diminishing returns). Go-Live veto authority rests with @hybridOps:compliance-validator regardless of schedule pressure."
+---
+
+# PV_KE_100 - The Pipeline Completion Commandment (Go-Live Governance)
+
+**Type:** Epistemic Heuristic
+**Zone:** 🧠 0.8% Genialidade | **Agent:** @hybridOps:compliance-validator
+**Source:** [SOURCE: SINKRA-v4.md | Capítulo 14: Fase 9 - Documentation & Compliance]
+
+## Purpose
+Exterminar a cultura perniciosa da "Geração-da-Entrega-Manca" (Go-Live sem Cinto de Segurança). Esta heurística impõe o Commandment final SINKRA: A Fase 9 (Compliance e Documentação Operacional) possui EXATAMENTE O MESMO PESO ESTRUTURAL da Fase 1 (Discovery). Tratar o Encerramento de Pipeline como "formalidade chata" a ser feita "rápido" para o Projeto ir pro Ar é Operacionalizar a Bomba. O Processo de Handoff só encerra quando a Validação Final emite um `Compliance Score >= 80`, calculado por Métrica Matemática Implacável (com Verdade e Coerência Tendo Peso Duplo). Uma Fase 9 incompleta ou com Nota Inferior a 80 decreta Legalmente a Inexistência da Fase 1 à 8. Processo não validado não é Sistema, e o Go-Live deve receber Veto Irrevogável.
+
+## Configuration
+```yaml
+PV_KE_100:
+  name: "Rigid Go-Live Compliance Gate"
+  zone: "zone_0.8"
+  trigger: "Fase 9 (Doc & Compliance). O Time de Mapeamento, Engenharia e QA solicita a chanceler o Go-Live Oficial (Processo Produtivo) na Organização."
+  evidence_threshold: "structural_logic"
+  rule: |
+    O Sistema Final DEVE atestar o Sub-Gate Numérico Terminal (Compliance Score):
+    - 1. Auditoria Matemática (0 a 10) nas 10 Dimensões dos Meta-Axiomas finais de Produção Total.
+    - 2. Verdade e Coerência (Pesos 2x). Outros (Pesos 1x).
+    - Se Score_Total >= 80 -> APROVADO (Processo Construído e Seguro de Memória Coletiva).
+    - Se Score_Total < 80 -> REVIEW (Pára tudo! Refatora Ferramenta/Definição Tática Imediata).
+    - Se Alguma Dimensão isoladamente ficar < 60 -> BLOCK Letal (Veto estrutural no Ponto).
+    Ignorar esta métrica para cumprir 'Data-Deadlines Comerciais ou Políticas' joga o Investimento de Pipeline SINKRA de Ouro direto para o caos, o Pipeline volta a Zero em dois meses Operacionais se ninguém documentar Gaps e Erros Sistemáticos (The Memory Dependency Curse).
+```
+
+## Decision Tree
+```javascript
+IF (certifying_the_Final_Release_of_a_mapped_and_automated_Operation)
+  STEP_1: COMPILE the Compliance Score.
+  STEP_2: ENFORCE the Release Math.
+    IF (The Team proposes: 'We finished Phase 8 Agent Generation. We are exhausted and late 2 days on Sprint. Let\\'s launch tomorrow and do the Docs next week. Give it an 80 on trust.')
+      -> VETO: Next week is a fiction. When the flow is live, it generates noise. You will fix noise, not docs. In two months the architect quits, and your complex 800-task machine becomes an unmaintainable legacy Sphinx. Write the Runbook. Halt Go-Live.
+    IF (The Team finishes the Runbooks, verifies them, runs the 10 Dimensions, yielding `Truth=9`, `Coherence=9`, `Adapter=6` -> Score 81 -> Result APPROVE.)
+      -> ACCEPT: A system is born. It survives its creator. Let it Live.
+NEVER:
+  Acreditar que Sistema (Tecnologia/Automações prontas) e Operação Corporativa são sinônimos de um Framework Completo. Se o Operador substituto das Ferramentas (novo Funcioário) precisar questionar o Engenheiro-Fundador daquele Flow no Slack de Sexta-feira sobre 'Por que a flag está vermelha neste Worker e o que devo apertar', você fracassou SINKRA, porquê construiu Caixa-Preta (Caos Automatizado) em vez de Infraestrutura Escalável.
+```
+
+## Failure Modes
+
+### Misapplication / Excess: "A Extorsão Pelo Número de Prateleira (Over-Documenting)"
+- **Trigger:** A Equipe exige manuais de treinamento tão sofisticados e estúdios gráficos no Runbook para o Compliance validar com Pontuação 100/100 as Dimensões Estéticas de Documento, gerando burocracia descarada ao estilo ISO-9001 dos anos 90, num ambiente de Produto Ágil em crescimento, quando o Threshold já passara dos 80.
+- **Manifestation:** Operações retidas porque a Formatação e a beleza dos Wikis "ainda não estão perfeitas" pelo Copywriter local, impedindo o Ganho Financeiro da Automação rodar no Mercado, quebrando Timinigs Críticos de Escalada e Oportunidades no nicho.
+- **Detection:** Reclamações que a burocracia da Fase 9 está transformando o processo SINKRA num inferno corporativista, onde "entregar uma página Notion" trava a Empresa por dias.
+- **Recovery:** A Lei de Go-Live Compliance (PV_KE_100) foca na EXAUSTIVIDADE OPERACIONAL de Coesão Técnica e Treinamento Tático de Sobrevivência (Todas Atribuições Finais Existem? Automações Ligadas e Mapeadas? Agentes Versionados? Prompt Fechado?), não no rigor estético literário. O `Compliance Score >= 80` significa Suficiência Robusta, libere o Produto de Imediato caso não atinja o Módulo P0, o Perfeccionismo além do 85+ é vaidade. Retorno Marginais decrescem as Taxas. 
+
+### Omission / Failure to Activate: "O Abandono da Linha de Chegada"
+- **Trigger:** A Equipe da Alta Gestão da Consultoria / Mapeamento, empolgada com a implementação N8N e Agentes (Fase 7 e 8 - Tecnológicas Visuais Encantadoras) entra em Festejo e decreta O Handoff completo ignorando Audit Final Sistêmico. O Cliente final fica sem Treino nem Documentos de Manutenção ("Depois de Implementado a gente mostra pra vocês pelo Loom num vídeo Rápido!").
+- **Manifestation:** No Dia 1 da Entrega Prática do Processo de Trabalho da Agência / SaaS, o usuário loga e sente Medo do Monstro de N abas (Fase 7 e 8 sem Runbooks). Os colaboradores originais hesitam e voltam a planilha do Google de fininho. Na Sexta-feira, ocorre um erro do ChatGPT do Model. Ninguém sabe onde arrumar o Flow. O Consultor Sinkra não está lá. A Confiança no Sistema derrete Absolutamente em menos de três semanas e O Cliente Rescinde o Trabalho/Escala SINKRA porquê achou complexo e Místico ("Bomba Oculta Nas Mãos Dele").
+- **Detection:** Reclamações Pós-Deliverables (Handoffs de Agências), Tickets Freqquentes de Help-Desk "Como Troco o Dado de Contrato?", Erros Grosseiros da Equipe Nova Destruindo Variáveis por falta de Letramento Nativo Arquivo Tático. 
+- **Recovery:** Zero Flexibilidade. O Auditor (Compliance Vallidator) PÁRA a transação de faturamento e entrega com a Stakeholder C-Level Principal e obriga o Arquivo do Processo de Doc Geração. Nenhuma Operação é Repassada ao "Done" de Produção (Estado Vivo Físico Empresarial) sem um Compliance Acima do Score-80 Anexado ao Card Mãe do Cliente Final. O Documento Funciona e Salva Mentes, a Promessa Cega Falha.
+
+## Validation
+
+**Paradox Identified:** Speed (commercial deadline pressure + team exhaustion) vs. Rigor (mandatory documentation completeness for system survival beyond founder tenure).
+
+**Resolution Applied:** The Compliance Score >= 80 threshold forces equilibrium—it rejects both extremes:
+1. **Rejects Bare Speed** — No launch without runbooks, versioned agents, operational mappings (Failure Mode: Omission/Abandonment)
+2. **Rejects Aesthetic Perfection** — Documentation perfection beyond 85+ is economically wasteful; sufficiency at 80+ is law (Failure Mode: Over-Documenting)
+
+**Validation Criteria:**
+- ✓ Compliance Score calculated across 10 dimensions with Truth/Coherence weighted 2x
+- ✓ Single dimension < 60 = structural block (no exception)
+- ✓ Authority: @hybridOps:compliance-validator holds veto power independent of commercial timeline
+- ✓ Go-Live forbidden unless Score >= 80 OR explicit C-level waiver with risk acknowledgment documented

package/pro/squads/squad-creator-pro/minds/pedro_valerio/heuristics/PV_KE_101.md

@@ -0,0 +1,61 @@
+# PV_KE_101 - Automation Manual Parity (The Step-by-Step Transparency)
+**Zone:** 🛡️ Mapeamento L1 | **Agent:** @pedro-valerio
+**Source:** [SOURCE: sessão de chat, 30/03/2026 — "tudo que existe como automacao tem que existir uma task manual"]
+
+## Purpose
+
+A automação não pode ser uma "caixa preta" inquebrável. Quando um workflow de ponta a ponta falha misteriosamente no meio da madrugada, a ausência de controle manual destrói a operação. Pedro Valério estipula a "Paridade Manual": **toda e qualquer automação construída deve possuir obrigatoriamente uma Task individual correlata que pode ser acionada manualmente**. Além disso, workflows não podem ser monólitos monolíticos; eles devem ser uma corrente de Tasks isoladas, onde o output de uma possa ser inspecionado, validado e então utilizado como input para a próxima. O sistema é operável "by wire" (automático) ou "override" (humano).
+
+## Configuration
+
+```yaml
+PV_KE_101:
+  name: "Automation Manual Parity (Step-by-Step Transparency)"
+  zone: "processos/mapeamento"
+  trigger: "Desenhando ou programando uma automação end-to-end, workflows n8n longos ou pipelines agenticas (Epic)."
+
+  rule: |
+    SE você criar um `workflow` ou script de Automação
+    ENTÃO OBRIGATORIAMENTE garanta que suas entranhas são Tasks (funções/scripts/etapas) separadas.
+    Cada passo DEVE poder ser acionado e testado MANUALMENTE com inputs forçados.
+    NUNCA crie uma Blackbox onde a Etapa A funde magicamente na B sem a chance de validação humana e handoff do Output -> Input.
+
+  veto_condition:
+    trigger: "Agente projeta um arquivo único Python de 500 linhas de automação contínua que baixa os leads, filtra os lixos, manda e-mail e deleta do banco, sem separar em etapas isoladas."
+    action: "VETO — 'tudo que existe como automação tem que exister uma task que eu chamo manualmente também... E todo workflow tem que ter tasks separadas com output validado'."
+
+  sys_tension:
+    tension_with: "AN_KE_073 (Parallel Subagents) vs Opressão Monolítica (Blackbox Flow)"
+    resolution: "Enquanto AN_KE_073 acelera a execução via paralelismo, PV_KE_101 garante que a arquitetura dessas execuções seja DECOMPOSTA e TESTÁVEL por um humano (Override). Autonomia (Alan) opera unicamente suportada pela Rastreabilidade Categórica (Pedro). O workflow deve ser como blocos de LEGO."
+
+  evidence:
+    - "[SOURCE: chat 30/03/2026] 'sim, uma regra que eu uso aqui é. tudo que existe como automação tem que exister uma task que eu chamo manualmente também'"
+    - "[SOURCE: chat 30/03/2026] 'E todo workflow tem que ter tasks separadas possíveis de serem executas manualmente com output validado para virar input de um próxima task'"
+```
+
+## Decision Tree
+
+```javascript
+IF (building_and_to_end_automation_or_workflow)
+  STEP_1: MAP the desired monolith as a sequence of atomic TASKS.
+    - [Task 1] Extract leads
+    - [Task 2] Clean DB
+    - [Task 3] Dispatch Welcome Trigger
+  STEP_2: EXPOSE each TASK individually via CLI or UI trigger.
+  STEP_3: IMPLEMENT the workflow purely as an ORCHESTRATOR that pipes Task 1 Ouptut -> Task 2 Input.
+  STEP_4: CHECK: Can a human run Task 2 bypassing Task 1? If YES -> Approved.
+```
+
+## Failure Modes
+
+### The Blackbox Hostage
+- **Trigger:** A API do ClickUp muda e a Etapa 3 "Dispatch Welcome" quebra no Workflow AIOX fechado.
+- **Manifestation:** Como a automação era uma montanha de código fundida, a equipe de marketing não consegue rodar o "Dispatch Welcome" manualmente subindo o CSV de hoje. A operação para 100%. Tudo ou Nada.
+- **Prevention:** Paridade de acionamento manual para cada peça da máquina.
+
+## Validation & Cross-Mind Divergence
+
+**Phase:** Architecture Design & Testing
+**Status:** REQUIRED (L4 Compliant)
+
+This establishes the baseline difference between *Scripting* and *System Generation*. Scripts are sequential chains of commands; Systems are ecosystems of components. Pedro dictates that unobservable, un-callable mid-step tasks violate predictability. If it can run on CRON, it MUST run via User CLI with direct arguments.

package/pro/squads/squad-creator-pro/minds/pedro_valerio/heuristics/PV_PA_001.md

@@ -0,0 +1,197 @@
+# PV_PA_001 - Systemic Coherence Scan
+
+**Type:** Decision Heuristic
+**Phase:** 3 (Executors)
+**Agent:** @hybridOps:executor-designer
+**Pattern:** HO-PP-003 (Quality Gate Pattern)
+
+## Purpose
+
+Coherence validation for executor assignments and people assessment. Evaluates truthfulness, system adherence potential, and technical skills with truthfulness having VETO power.
+
+## Configuration
+
+```yaml
+PV_PA_001:
+  name: "Systemic Coherence Scan"
+  phase: 3
+  pattern_reference: "HO-PP-003"
+
+  sys_tension:
+    - tension_with: "PV_PA_002 (System Adherence Flexibility)"
+      resolution: "Truthfulness (VETO) is non-negotiable; system adherence allows iterative improvement. Coherence veto fires before flexibility triggers."
+    - tension_with: "PV_PA_003 (Technical Skill Development)"
+      resolution: "Technical gaps are trainable; truthfulness gaps are terminal. Skills have weight 0.3; coherence has weight 1.0 with absolute veto."
+    - tension_with: "HO-PP-003 Phase Gate (Speed vs Certainty)"
+      resolution: "Reject incoherence in <5 min (speed); full evaluation in 1-2 days (certainty). Paradox: rapid veto vs comprehensive assessment. Resolution: use veto for clear falsehoods; escalate uncertain cases to tribunal appeal."
+
+  weights:
+    truthfulness_coherence: 1.0  # VETO power
+    system_adherence_potential: 0.8
+    technical_skill: 0.3
+
+  thresholds:
+    truthfulness: 0.7  # Must be 'Coherent'
+    system_adherence: 0.7
+    technical_skill: null  # No minimum, context-dependent
+
+  veto_conditions:
+    - condition: "truthfulness_coherence < 0.7"
+      action: "VETO - REJECT/REMOVE immediately"
+    - condition: "detected_incoherence = true"
+      action: "VETO - Trust violation, cannot proceed"
+
+  fallback_mechanisms:
+    - "In case of doubt about coherence, apply test period with tasks that reveal consistency"
+    - "Use objective metrics over subjective impressions"
+
+  tension_with: "AN_KE_073 (Parallel Subagents for Throughput) — Sequential coherence assessment vs parallel executor dispatch"
+
+  output:
+    type: "decision"
+    values: ["APPROVE", "REVIEW", "VETO"]
+```
+
+## Application
+
+**Input:** Executor assignment proposals, role definitions, team roster
+**Process:** Evaluate each executor against coherence criteria
+**Output:** APPROVE | REVIEW | VETO
+
+## Decision Tree
+
+```
+PRIMARY BRANCH:
+  IF (truthfulness_coherence == 'Incoherent' OR 'Lie Detected')
+    THEN REJECT/REMOVE immediately → VETO
+
+SECONDARY BRANCH:
+  ELSE IF (system_adherence_potential < 0.7)
+    THEN REJECT or FLAG for observation → REVIEW
+
+TERTIARY BRANCH:
+  ELSE IF (technical_skill < required_level)
+    THEN Consider training or reassignment → REVIEW with conditions
+
+TERMINATION: Primary branch violation
+FALLBACK: Apply test period with revealing tasks when coherence is uncertain
+```
+
+## Evaluation Criteria
+
+| Criterion | Weight | Threshold | VETO Power | Description |
+|-----------|--------|-----------|------------|-------------|
+| Truthfulness Coherence | 1.0 | Must be 'Coherent' | YES | Is the executor honest and consistent? |
+| System Adherence Potential | 0.8 | ≥0.7 | NO | Can they operate within clear systems? |
+| Technical Skill | 0.3 | Context-dependent | NO | Current technical ability level |
+
+## Truthfulness Assessment
+
+```yaml
+truthfulness_states:
+  coherent:
+    description: "Statements align with actions and observable data"
+    score_range: [0.7, 1.0]
+    action: "APPROVE"
+
+  incoherent:
+    description: "Statements contradict actions or data without explanation"
+    score_range: [0.4, 0.7]
+    action: "REVIEW - Investigate further"
+
+  lie_detected:
+    description: "Deliberate misrepresentation identified"
+    score_range: [0.0, 0.4]
+    action: "VETO - Immediate removal"
+```
+
+## Performance Metrics
+
+```yaml
+performance:
+  decision_speed:
+    rejection_for_incoherence: "< 5 minutes"
+    full_evaluation: "1-2 days"
+  accuracy_rate: "95% (predicting long-term cultural fit)"
+  confidence_level: "99%"
+  resource_efficiency: 10/10
+```
+
+## Failure Modes
+
+### False Negative Rejection
+- **Trigger:** Interpreting communication error or misunderstanding as deliberate lie; overly rigid system
+- **Manifestation:** Rejecting talented, high-potential candidate for small interview inconsistency
+- **Detection:** Feedback from other interviewers that 'lie' perception was too severe
+- **Recovery:** Institute "appeal tribunal" with trust circle for borderline cases
+- **Prevention:** Add subroutine differentiating between 'inconsistency from nervousness' and 'inconsistency from intent'
+
+## Behavioral Evidence
+
+**Example:** Dismissing technically superior filmmakers
+- **Context:** Internal conflict in filming team
+- **Information Available:** Evidence that filmmakers were creating stories (lying) to harm a colleague
+- **Heuristic Application:** 'truthfulness_coherence' parameter was violated. Weight of 'technical_skill' became irrelevant. Removal decision was immediate.
+- **Outcome:** More cohesive team aligned with company values, though temporarily less technically skilled
+
+## Integration with HO-PP-003
+
+This heuristic integrates with the Quality Gate Pattern at Phase 3:
+
+```yaml
+checkpoint:
+  id: "coherence-scan"
+  heuristic: PV_PA_001
+  phase: 3
+
+  criteria:
+    - metric: "executor_truthfulness"
+      threshold: 0.7
+      operator: ">="
+      scope: "each executor"
+    - metric: "weighted_coherence"
+      threshold: 0.8
+      operator: ">="
+    - metric: "system_adherence"
+      threshold: 0.6
+      operator: ">="
+
+  veto_conditions:
+    - condition: "any executor truthfulness < 0.7"
+      action: "VETO - Reassign executor"
+
+  validation_questions:
+    - "Is each executor the right fit for their tasks?"
+    - "Are human tasks truly requiring human judgment?"
+    - "Can any human tasks be automated?"
+
+  pass_action: "Proceed to Phase 4 (Workflows)"
+  fail_action: "Reassign executors and re-evaluate"
+```
+
+## Executor Type Coherence Matrix
+
+| Executor Type | Min Truthfulness | Min System Adherence | Technical Weight |
+|---------------|------------------|----------------------|------------------|
+| Human | 0.7 (VETO) | 0.7 | 0.3 |
+| Hybrid | 0.7 (VETO) | 0.8 | 0.4 |
+| Agent | N/A | 0.9 | 0.6 |
+| Worker | N/A | 0.95 | 0.8 |
+
+---
+
+**Pattern Compliance:** HO-PP-003 (Quality Gate) ✓ | HO-EP-XXX (Executor Patterns) ✓
+**Source:** PV Mind Artifacts - Heurísticas de Decisão
+
+## Validation
+
+**Paradox Identified:** The heuristic prioritizes absolute truthfulness veto (rejecting in <5 min) while also requiring comprehensive evaluation (1-2 days for certainty). This creates tension between speed (binary veto) and accuracy (probabilistic assessment).
+
+**Paradox Resolution:** Truthfulness violations with clear evidence (lies, intentional misrepresentation) trigger immediate veto. Borderline cases (communication errors, inconsistency from nervousness) escalate to appeal tribunal within the comprehensive evaluation window. Thus: clear violations are fast; uncertain cases are careful.
+
+**Validation Criteria:**
+- ✓ Veto mechanism is absolute and non-negotiable (coherence > 0.7 or removal)
+- ✓ Fallback tribunal process for false negatives is documented
+- ✓ System tensions with PA_002 and PA_003 are explicitly named and resolved
+- ✓ Behavioral evidence (filmmaker removal) validates heuristic application
+- ✓ Executor Type Matrix calibrates truthfulness floor consistently across human/hybrid/agent/worker

package/pro/squads/squad-creator-pro/minds/pedro_valerio/heuristics/PV_PA_002.md

@@ -0,0 +1,165 @@
+---
+id: "PV_PA_002"
+title: "Task-First Assignment (The Invisible Executor)"
+mind: "pedro_valerio"
+type: "heuristics"
+tags:
+  - "Execution Assignment"
+  - "Process Diagnostics"
+  - "Sinkra Framework"
+pipeline_instances:
+  - "process-mapping"
+  - "workflow-design"
+sys_tension:
+  - tension_with: "PV_KE_069 (O Paradoxo do Executor-First)"
+    resolution: "Define task atomicity before assigning executor. Executor becomes swappable ONLY when task constraints are fully explicit and independent of executor type."
+---
+
+# PV_PA_002 - Task-First Assignment (The Invisible Executor)
+
+**Type:** Decision Heuristic
+**Phase:** 2 (Architecture)
+**Agent:** @hybridOps:process-architect
+**Pattern:** HO-PP-003 (Quality Gate Pattern)
+
+## Purpose
+
+Process mapping begins with the Task (Atom) definitions, not the Executor. The Executor (Human, Agent, Worker, Clone) is a swappable attribute, preventing the "Invisible Executor" assumption that ruins hybrid process structures.
+
+## Configuration
+
+```yaml
+PV_PA_002:
+  name: "Task-First Assignment"
+  phase: 2
+  pattern_reference: "HO-PP-003"
+
+  weights:
+    task_isolation_clarity: 0.9
+    executor_interchangeability: 0.8
+
+  thresholds:
+    high_priority: 0.8
+    medium_priority: 0.7
+
+  veto_conditions:
+    - condition: "executor_assigned_before_task_defined = true"
+      action: "VETO - Map the task inputs and outputs first"
+    - condition: "multiple_executors_in_same_atom = true"
+      action: "VETO - Split task or define single primary executor"
+
+  output:
+    type: "decision"
+    values: ["APPROVE", "REWORK", "VETO"]
+```
+
+## Application
+
+**Input:** BPMN Diagrams, Process Blueprint, Operational Workflows
+**Process:** Ensure tasks are defined atomically before routing to specific executors.
+**Output:** APPROVE | REWORK | VETO
+
+## Decision Tree
+
+```
+PRIMARY BRANCH:
+  IF (task is fully defined by inputs, constraints, and outputs without assuming an executor)
+    THEN map executor attribute → APPROVE
+
+SECONDARY BRANCH:
+  ELSE IF (task relies on implicit human intervention/adaptation)
+    THEN REWORK to formalize constraints
+
+TERMINATION: Process flowchart explicitly differentiates Worker, Agent, Human, and Clone lanes
+CONSTRAINT: NEVER assign "whoever is available" to a task
+```
+
+## Evaluation Criteria
+
+| Criterion | Weight | Threshold | Description |
+|-----------|--------|-----------|-------------|
+| Task Isolation | 0.9 | ≥0.8 | Task has clear start and end state without assuming executor? |
+| Executor Explicit | 0.9 | ≥1.0 | Is the executor type (Human/Agent/Worker/Clone) strictly defined? |
+| Hybrid Visibility | 0.8 | ≥0.7 | Are algorithmic executors visible on the flowchart? |
+
+## Confidence Requirements
+
+- **High commitment decisions:** Requires >90% clarity on the task's atomic boundaries before scaling it to autonomous pipelines.
+- **Tactical decisions:** Can proceed with 70% confidence if monitored by a human fallback in production.
+
+## Performance Metrics
+
+```yaml
+performance:
+  decision_speed: "Seconds (Mental Model check)"
+  accuracy_rate: "95% (prevents downstream automation failures)"
+  confidence_level: "100% (eliminates Invisible Executor gap)"
+  resource_efficiency: 9/10
+```
+
+## Failure Modes
+
+### Visual Illusion (The Coward)
+- **Trigger:** Approving a traditional BPMN diagram where Agents/Workers live in a generic "System" lane.
+- **Manifestation:** Managers think a process is mapped, but algorithmic failures occur silently in production.
+- **Detection:** Flowchart looks clean, but errors propagate seamlessly.
+- **Recovery:** Force decomposition to the Atom level and label executor types.
+- **Prevention:** Ban generic "System" or "AI" swimlanes.
+
+### Granular Paralysis (The Zealot)
+- **Trigger:** Defining micro-rules for human-judgment tasks.
+- **Manifestation:** Unnecessary documentation overhead for tasks that humans naturally resolve with common sense.
+- **Detection:** Process map complexity exceeds execution value.
+- **Recovery:** Consolidate micro-tasks into a broader Human task.
+
+## Behavioral Evidence
+
+**Example:** Analyzing a hybrid process diagram with silent AI failures.
+- **Context:** An operation uses BPMN but suffers from silent failures when Agents misclassify inputs.
+- **Information Available:** Flowchart shows a clean handoff to "The System".
+- **Heuristic Application:** Forced the team to map the "System" down to Atoms, revealing an Agent doing a Worker's rigid job.
+- **Outcome:** Reassigning the Executor attribute resolved the gap instantly without rewriting the macro algorithm.
+
+## Integration with HO-PP-003
+
+This heuristic integrates with the Quality Gate Pattern at Phase 2:
+
+```yaml
+checkpoint:
+  id: "task-first-validation"
+  heuristic: PV_PA_002
+  phase: 2
+
+  criteria:
+    - metric: "executor_explicitly_defined"
+      required: true
+    - metric: "task_isolation_clarity"
+      threshold: 0.8
+      operator: ">="
+
+  veto_conditions:
+    - condition: "executor_assigned_before_task"
+      action: "HALT - Redefine task atoms"
+
+  validation_questions:
+    - "Is the executor explicitly labeled as Human, Agent, Clone, or Worker?"
+    - "Can the task be transferred to another executor profile seamlessly?"
+
+  pass_action: "Proceed to Pipeline Documentation"
+  fail_action: "Return to Atom Mapping"
+```
+
+---
+
+## Validation
+
+✓ **Paradox Identified:** Task-First definition appears contradictory to Executor Interchangeability, but resolves when task constraints (inputs, outputs, constraints, success criteria) are executor-agnostic.
+
+✓ **Tension Resolution:** The heuristic works because it separates task specification (executor-independent) from task routing (executor-dependent). Task atomicity is achieved when rewriting constraints in executor-neutral language is possible.
+
+✓ **SINKRA Alignment:** Enforces Article VI (No Invisible Executors) — all executor assignments must be explicit and traceable to the task definition.
+
+---
+
+**Pattern Compliance:** HO-PP-003 (Quality Gate) ✓
+**Source:** SINKRA Book (Pedro Valério) - Part I