aiox-core 5.0.4 → 5.0.5

package/pro/squads/squad-creator-pro/tasks/parallel-discovery.md

@@ -1,58 +0,0 @@
-# Task: Parallel Discovery
-
-**Task ID:** parallel-discovery
-**Version:** 1.0.0
-**Execution Type:** Hybrid (Worker parallelization + Agent synthesis)
-**Purpose:** Run domain discovery streams in parallel and merge deterministically
-**Orchestrator:** @squad-chief
-
-## Parallel Streams
-
-```yaml
-streams:
-  market_signals:
-    source: web + docs
-    output: market-signals.yaml
-
-  expert_minds:
-    source: mind research
-    output: expert-candidates.yaml
-
-  tooling_stack:
-    source: tool registry + MCP discovery
-    output: tooling-options.yaml
-
-  risk_constraints:
-    source: architecture and governance docs
-    output: risks-and-vetos.yaml
-```
-
----
-
-## Merge Strategy
-
-1. Normalize outputs to YAML schema.
-2. Deduplicate by key and source confidence.
-3. Resolve conflicts using priority: `local > primary source > secondary source`.
-4. Emit `discovery-merged.yaml` and `discovery-summary.md`.
-
----
-
-## Output
-
-```yaml
-discovery_bundle:
-  merged_file: outputs/discovery/{domain}/discovery-merged.yaml
-  summary_file: outputs/discovery/{domain}/discovery-summary.md
-  confidence_score: 0-1
-  unresolved_conflicts:
-    - "..."
-```
-
----
-
-## Success Criteria
-
-- At least 3 streams completed successfully.
-- Merged output has explicit source attribution.
-- No unresolved critical conflicts.

package/pro/squads/squad-creator-pro/tasks/pv-audit.md

@@ -1,244 +0,0 @@
-# Task: Process Audit (*audit)
-
-> Pedro Valério | Loaded on-demand when `*audit {squad}` is invoked
-
-## Purpose
-
-Auditar squad/workflow por falhas de processo usando framework "Impossibilitar Caminhos"
-
-## CRITICAL: Token Budget
-
-**VETO CONDITION:** Audit que estoura contexto é audit quebrado.
-
-```
-Budget máximo por fase:
-- Phase 1: ~2k tokens (overview)
-- Phase 2: ~5k tokens (sample)
-- Phase 3: ~3k tokens (deep-dive sob demanda)
-TOTAL MÁXIMO: ~10k tokens
-```
-
-**NUNCA:**
-- Ler TODOS os agents de uma vez
-- Ler DNA files sem pedido explícito
-- Ler mais de 3 arquivos por fase
-
-## Input
-
-- Squad name ou workflow file path
-- `--all` flag para audit 100% (com batching)
-
-## Parâmetros
-
-| Flag | Comportamento |
-|------|---------------|
-| (default) | 3-Phase Staged - sample representativo |
-| `--all` | Audit 100% em batches de 3 agents |
-
----
-
-## Mode: Full Audit (`*audit {squad} --all`)
-
-**ATENÇÃO:** Audit completo consome mais tokens. Usa batching pra não estourar.
-
-### Step 1: Estimate & Confirm
-
-```bash
-# Calcular custo estimado
-wc -l squads/{squad}/agents/*.md | tail -1  # total lines
-```
-
-**Mostrar estimativa:**
-```
-⚠️ FULL AUDIT MODE
-
-Squad: {name}
-Agents: {N}
-Total lines: {X}
-Estimated tokens: ~{X * 2}
-
-Batches necessários: {ceil(N/3)}
-Tokens por batch: ~{batch_estimate}
-
-Confirma? (y/n)
-```
-
-**HALT:** Aguardar confirmação.
-
-### Step 2: Batch Execution
-
-Processar em batches de 3 agents:
-
-```
-Batch 1/N: agent-1, agent-2, agent-3
-→ Ler 3 agents
-→ Aplicar diagnostic framework
-→ Output parcial
-→ [CONTINUE para próximo batch]
-
-Batch 2/N: agent-4, agent-5, agent-6
-→ ...
-```
-
-**Entre batches:** Mostrar progresso e perguntar se continua.
-
-### Step 3: Consolidate
-
-Após todos os batches:
-- Consolidar findings
-- Gerar report final com 100% coverage
-
----
-
-## Mode: Staged Audit (default)
-
-### Phase 1: Structural Overview (~2k tokens)
-
-**Objetivo:** Mapear estrutura SEM ler conteúdo completo.
-
-```bash
-# Comandos a executar:
-ls -la squads/{squad}/agents/     # Lista agents (não lê)
-ls -la squads/{squad}/workflows/  # Lista workflows (não lê)
-wc -l squads/{squad}/agents/*.md  # Conta linhas por agent
-```
-
-**Ler APENAS:**
-- `config.yaml` (estrutura do squad)
-
-**Output Phase 1:**
-```yaml
-squad_overview:
-  name: "{squad}"
-  agent_count: N
-  workflow_count: N
-  total_lines: N
-  largest_agents: [top 3 por linhas]
-  has_dna_files: true/false
-  has_checklists: true/false
-```
-
-**HALT:** Mostrar overview e perguntar direção.
-
----
-
-### Phase 2: Pattern Sample (~5k tokens)
-
-**Objetivo:** Identificar padrões com AMOSTRA representativa.
-
-**Ler APENAS (máximo 3 arquivos):**
-- 1 agent PEQUENO (< 200 linhas)
-- 1 agent MÉDIO (200-400 linhas)
-- 1 workflow principal (se existir)
-
-**Aplicar Diagnostic Framework na amostra:**
-- "Se o executor não ler as instruções, o que acontece?"
-- "Se o executor tentar pular um passo, consegue?"
-- "Se o executor errar, o sistema detecta automaticamente?"
-
-**Check Red Flags:**
-- [ ] Processo depende de boa vontade do executor
-- [ ] Instruções fora do sistema
-- [ ] Caminhos errados possíveis mas "não recomendados"
-- [ ] Sem veto conditions
-
-**Check Green Flags:**
-- [ ] Veto conditions bloqueiam caminhos errados
-- [ ] Checklist inline na própria task
-- [ ] Handoff rules definidos
-- [ ] Smoke tests especificados
-
-**Output Phase 2:**
-```yaml
-sample_analysis:
-  agents_sampled: ["{small}", "{medium}"]
-  workflow_sampled: "{name}"
-
-  patterns_found:
-    consistent:
-      - "{pattern que se repete}"
-    inconsistent:
-      - "{pattern que varia}"
-
-  red_flags: [list]
-  green_flags: [list]
-
-  extrapolation: |
-    "Baseado na amostra de 2/{total} agents..."
-```
-
-**HALT:** Mostrar análise e perguntar se quer deep-dive.
-
----
-
-### Phase 3: Deep-Dive (sob demanda, ~3k tokens)
-
-**Trigger:** Usuário pede análise específica.
-
-**Comandos:**
-- `*audit {squad} agent:{name}` - Auditar 1 agent específico
-- `*audit {squad} workflow:{name}` - Auditar 1 workflow específico
-- `*audit {squad} dna` - Verificar DNA files
-
-**Ler APENAS o arquivo pedido.**
-
-**Output Phase 3:**
-```yaml
-deep_dive:
-  target: "{agent/workflow name}"
-
-  wrong_paths_found:
-    - point: "{decision point}"
-      wrong_path: "{what can go wrong}"
-      current_protection: "none | alert | block"
-      recommendation: "{veto condition}"
-
-  veto_conditions_proposed:
-    - id: "V{n}"
-      condition: "{description}"
-      check: "{how to verify}"
-      action: "VETO - {what to do}"
-
-  verdict: "PASS | NEEDS WORK | REDESIGN"
-```
-
----
-
-## Final Report (após todas as fases)
-
-```yaml
-audit_report:
-  squad: "{name}"
-  date: "{date}"
-  auditor: "@pedro-valerio"
-
-  scope:
-    agents_total: N
-    agents_sampled: N
-    coverage: "X%"
-
-  token_usage:
-    phase_1: "~Xk"
-    phase_2: "~Xk"
-    phase_3: "~Xk (se aplicável)"
-    total: "~Xk / 10k budget"
-
-  findings:
-    critical: [bloqueiam uso]
-    major: [precisam correção]
-    minor: [melhorias]
-
-  verdict: "PASS | NEEDS WORK | REDESIGN"
-
-  next_actions:
-    - "{ação 1}"
-    - "{ação 2}"
-```
-
-## Completion Criteria
-
-- [ ] Phase 1 completa com overview estrutural
-- [ ] Phase 2 completa com sample analysis
-- [ ] Token budget respeitado (< 10k total)
-- [ ] Usuário direcionou deep-dives (se necessário)
-- [ ] Veto conditions propostas para problemas encontrados

package/pro/squads/squad-creator-pro/tasks/pv-axioma-assessment-wf-clone-mind.yaml

@@ -1,256 +0,0 @@
-axioma_assessment:
-  process_name: "wf-clone-mind"
-  process_type: "workflow"
-  version: "2.1.0"
-  assessment_date: "2026-02-11"
-  assessor: "@pedro-valerio"
-  model_used: "haiku"
-
-  dimensions:
-    - id: 1
-      name: "Verdade (Truthfulness)"
-      score: 9.0
-      weight: 1.0
-      threshold: 7.0
-      veto: true
-      status: "PASS"
-      evidence: |
-        Workflow apresenta decisões baseadas em critérios mensuráveis e verificáveis.
-
-        O que faz BEM:
-        - Checkpoints com critérios objetivos explícitos (10+ fontes, 5+ Tier 1, 3+ tipos diferentes)
-        - Outputs são artefatos reais e verificáveis (sources_inventory.yaml, smoke_test_result.yaml, quality_dashboard.md)
-        - Smoke tests padronizados com pass_criteria explícitos (4/5 checks para cada teste)
-        - Decision matrix documenta o que "GO", "CONDITIONAL", "NO-GO" significam em termos de dados
-        - Fidelity_estimate é calculado a partir de métricas objetivas (sources_count, tier_1_ratio, voice_score, thinking_score)
-      recommendations: []
-
-    - id: 2
-      name: "Coerência (Coherence)"
-      score: 9.0
-      weight: 0.9
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Sistema é altamente coerente entre design e comportamento esperado.
-
-        O que faz BEM:
-        - Faz exatamente o que diz: Fase 0b promete "validação de cobertura" e implementa 5 checkpoints específicos
-        - Rework loops são aplicados consistentemente (max_iterations, on_score_below_X, retry_max)
-        - Escalation paths estão definidos para cada falha (quando gate falha, próximos passos estão claros)
-        - Specialist assignments são consistentes (@oalanicolas sempre aparece para DNA extraction)
-        - Brownfield check redireciona corretamente (não continua em greenfield se mind já existe)
-      recommendations: []
-
-    - id: 3
-      name: "Alinhamento Estratégico"
-      score: 8.0
-      weight: 0.9
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow contribui diretamente ao objetivo maior de criar agentes com DNA fidedigno.
-
-        O que faz BEM:
-        - Todas as 5 phases convergem para um deliverable actionable (mind_dna_complete.yaml)
-        - Output é input direto para create-agent.md (next_steps definido explicitamente)
-        - Quality dashboard fornece visibilidade sobre fidelidade do clone (alinha com visão squad-creator)
-        - Fase -1 (Brownfield) reconhece a visão de perpetuidade (update-mind vs create-agent)
-      recommendations:
-        - Documentar explicitamente como wf-clone-mind contribui ao roadmap squad-creator maior
-        - Adicionar seção "Strategic Contribution" que conecte às épicas do projeto
-
-    - id: 4
-      name: "Excelência Operacional"
-      score: 8.0
-      weight: 0.8
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Processo robusto com tratamento de erros, fallbacks, e retry strategies bem definidas.
-
-        O que faz BEM:
-        - Auto-acquire (Phase 0a) executa ANTES de pedir user, eliminando fricção
-        - Skip logic baseada em inputs (focus param, mode, auto_acquire toggle) - processo se adapta
-        - Parallel execution habilitado para Phases 1-2 (voice e thinking podem rodar simultaneamente)
-        - Durações específicas em cada phase (15-30min, 1.5-2h) - estimativas realistas
-        - Rework loops definem ações claras com max_iterations (previne loops infinitos)
-        - Fallbacks com tool_priority definidos (mcp-youtube-transcript → exa+WebFetch → WebSearch)
-      recommendations:
-        - Documentar SLAs esperados para cada phase (current: durações estão, falta timeout enforcement)
-        - Adicionar mecanismo de tracking de runtime vs estimated_time para calibração
-
-    - id: 5
-      name: "Capacidade de Inovação"
-      score: 8.0
-      weight: 0.7
-      threshold: 5.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Approach de DNA extraction é inovador para o contexto de agent cloning.
-
-        O que faz BEM:
-        - Voice + Thinking DNA trinity é solução não-óbvia para capturar "o que diz" vs "como pensa"
-        - Triangulação de 3+ fontes para validação de patterns (não é apenas clustering de similares)
-        - Smoke tests REAIS que executam o clone (não apenas validação de dados) - verifica se comportamento funciona
-        - Anti-patterns e immune_system documentados (o que NUNCA fazer, não apenas o que fazer)
-        - Contradições de voz documentadas (paradoxos autênticos do expert) - abordagem sofisticada
-      recommendations:
-        - Considerar adicionar A/B testing framework para comparar clone vs original em futuros melhoramentos
-        - Documentar lessons learned de clones anteriores no wf-clone-mind (torna-se feedback loop)
-
-    - id: 6
-      name: "Gestão de Riscos"
-      score: 8.0
-      weight: 0.8
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow identifica e mitiga riscos através de gates estratégicos e contingencies.
-
-        O que faz BEM:
-        - SOURCE_QUALITY gate blocking em Phase 0b (previne DNA extraction sem bases suficientes)
-        - SMOKE_TEST gate blocking em Phase 4 (previne deployment de clone não-testado)
-        - Fallback strategy explícita em Phase 0a (tool_unavailable, zero_sources, partial)
-        - Retry strategy com max_iterations e escalation paths definidos
-        - Brownfield check em Fase -1 detecta duplicate work antes de começar
-        - Rework loops capturam qualidade baixa antes de prosseguir (on_score_below_X triggers)
-      recommendations:
-        - Documentar riscos de "fidelity decay over time" (clone diverge do original após updates)
-        - Adicionar mecanismo de validation contínua (smoke tests periódicos após deployment)
-        - Criar veto matrix explícita (Pedro Valério style: quais falhas realmente BLOQUEIAM vs continuam com warning)
-
-    - id: 7
-      name: "Otimização de Recursos"
-      score: 7.0
-      weight: 0.8
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow otimiza recursos através de automação, parallelização, e prevenção de desperdício.
-
-        O que faz BEM:
-        - Auto-acquire (Phase 0a) executa ANTES de pedir user - evita ciclos desnecessários
-        - Parallel_phases [1,2] permite voice e thinking extraction simultâneos (reduz wall-clock time)
-        - Skip_if logic em Phases 0a, 1, 2 evita trabalho desnecessário quando focus='voice'|'thinking'
-        - Rework loops têm max_iterations (não rework infinito)
-        - Mode logic evita reprocessamento de minds existentes (greenfield vs brownfield)
-      recommendations:
-        - Documentar custo de especialistas (@oalanicolas chamado em 5 fases diferentes) - pode ser otimizado?
-        - Considerar caching de smoke_test results para updates subsequentes (evita re-teste se fonte não mudou)
-        - Adicionar métricas de "resource waste" ao quality_dashboard (quanto time gasto em rework?)
-
-    - id: 8
-      name: "Valor para Stakeholders"
-      score: 8.0
-      weight: 0.7
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow cria valor mensurável para múltiplos stakeholders sem ganho desigual.
-
-        O que faz BEM:
-        - User: recebe clone fidedigno com quality dashboard que documenta limitações (transparency)
-        - System: gera outputs reutilizáveis (mind_dna_complete.yaml é input para create-agent.md)
-        - Specialist (@oalanicolas): tem role claro e responsabilidades bem-definidas em cada phase
-        - Future maintainers: quality_dashboard documenta gaps e recommendations
-        - Brownfield flow previne re-trabalho (user pode update-mind em vez de re-clone)
-      recommendations:
-        - Documentar feedback loop explícito com user após SMOKE_TEST falhar (como comunicar que clone não funciona?)
-        - Adicionar seção "Limitations & Disclaimers" ao quality_dashboard (ajuda user entender fidelidade real vs esperada)
-
-    - id: 9
-      name: "Sustentabilidade"
-      score: 8.0
-      weight: 0.7
-      threshold: 6.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow gera outputs persistidos, reutilizáveis, e generalizados para perpetuidade.
-
-        O que faz BEM:
-        - Outputs persistem em outputs/minds/{mind_slug}/ (não são ephemeral)
-        - mind_dna_complete.yaml é input direto para create-agent.md (funciona sem manual intervention)
-        - Processo é completamente generalizado (mind_name, domain como inputs) - não hard-coded para caso específico
-        - Brownfield mode (Phase -1) permite updates sem re-clone (sustenta evolução do mind)
-        - Quality dashboard fornece base para future improvements (documentação persistida)
-      recommendations:
-        - Documentar versionamento de mind_dna (quando sources mudam, como track versions?)
-        - Adicionar "sunset condition" (quando parar mantendo um clone? decay triggers?)
-        - Criar mechanism para "mind lineage tracking" (quem atualizou, quando, o quê mudou)
-
-    - id: 10
-      name: "Adaptabilidade"
-      score: 7.0
-      weight: 0.6
-      threshold: 5.0
-      veto: false
-      status: "PASS"
-      evidence: |
-        Workflow absorve mudanças através de configuração e gates sem falha catastrófica.
-
-        O que faz BEM:
-        - Skip_if logic (focus param, mode, auto_acquire) - adapta-se a inputs diferentes
-        - Rework loops e escalation paths permitem adaptação dinamicamente (não falha, pivota)
-        - Brownfield redirection (não força greenfield workflow se mind já existe)
-        - Tool_priority com fallbacks (mcp-youtube → exa+WebFetch → WebSearch) - muda strategy conforme tools disponíveis
-        - Retry strategy com max_iterations (absorve falhas temporárias, escala quando permanentes)
-      recommendations:
-        - Versionar quality_gates criteria (atualmente hard-coded em Phase 0b) - como atualizar sem quebrar retrocompat?
-        - Documentar "breaking changes" protocol (e.g., se criteria de SOURCE_QUALITY mudar, o que acontece com minds existentes?)
-        - Adicionar "circuit breaker pattern" para Phase 0a (se 3 tools falham, skip direto para manual collection)
-
-  overall_score: 7.77
-  overall_score_rounded: 7.8
-  pass_threshold: 7.0
-
-  threshold_analysis:
-    individual_dimensions_below_threshold: 0
-    veto_triggered: false
-    status: "PASS"
-
-  summary:
-    strengths:
-      - Altamente verificável (Verdade 9/10) - critérios mensuráveis, outputs validáveis
-      - Altamente coerente (Coerência 9/10) - faz exatamente o que promete
-      - Bem estruturado em gates (Gerenciamento de Riscos 8/10) - SOURCE_QUALITY e SMOKE_TEST bloqueiam falhas
-      - Inovador em abordagem (DNA extraction + smoke tests reais)
-      - Reutilizável e escalável (outputs persistem, processo generalizado)
-
-    gaps:
-      - Versionamento de mind_dna não documentado (importante para updates)
-      - Custo de especialistas não quantificado (5 chamadas a @oalanicolas)
-      - Feedback loop com user após smoke test falhar não explícito
-      - Breaking changes protocol não definido (critérios de gates evoluem?)
-
-  recommendations:
-    - "HIGH: Documentar versionamento strategy para mind_dna (semver? hash-based?)"
-    - "HIGH: Definir 'breaking changes protocol' se quality_gates criteria forem atualizadas"
-    - "MEDIUM: Criar feedback loop explícito para comunicar SMOKE_TEST failures ao user"
-    - "MEDIUM: Quantificar custo de especialista (@oalanicolas) para resource planning"
-    - "MEDIUM: Adicionar 'circuit breaker pattern' em Phase 0a (fallback escalation)"
-    - "LOW: Implementar A/B testing framework para futuras otimizações de clone accuracy"
-    - "LOW: Adicionar continuous validation (smoke tests periódicos após deployment)"
-
-  assessor_notes: |
-    wf-clone-mind é um workflow bem pensado que aplicaria muitos dos axiomas de
-    Pedro Valério naturalmente - especialmente Verdade (dados verificáveis),
-    Coerência (sistema consistente), e Gestão de Riscos (gates estratégicos).
-
-    O que diferencia este workflow: ele não apenas DIZ o que faz, ele PROVA
-    através de smoke tests. Isso eleva a confiança em todo o sistema.
-
-    Oportunidades de melhoria estão em:
-    1. Versionamento (sustentabilidade de longo prazo)
-    2. Comunicação de falhas (valor para stakeholders quando algo não funciona)
-    3. Quantificação de recursos (otimização)
-
-    Recomendação: PASS com observações anotadas acima.

package/pro/squads/squad-creator-pro/tasks/pv-axioma-assessment.md

@@ -1,83 +0,0 @@
-# Task: Axioma Assessment (*axioma-assessment)
-
-> Pedro Valério | Loaded on-demand when `*axioma-assessment {process}` is invoked
-
-## Purpose
-
-Avaliar processo/sistema nas 10 dimensões de Meta-Axiomas de Pedro Valério
-
-## Pre-requisite
-
-Load `squads/squad-creator-pro/data/pv-meta-axiomas.yaml` for dimension definitions, weights, and thresholds.
-
-## Input
-
-- Process/system name and description
-- Relevant documentation or workflow files
-
-## Steps
-
-### 1. Load Framework
-
-Read `squads/squad-creator-pro/data/pv-meta-axiomas.yaml`
-
-### 2. Evaluate Each Dimension
-
-Score 0-10 for each of the 10 dimensions:
-
-| # | Dimension | Weight | Threshold | Veto? |
-|---|-----------|--------|-----------|-------|
-| 1 | Verdade (Truthfulness) | 1.0 | 7.0 | YES |
-| 2 | Coerência (Coherence) | 0.9 | 6.0 | no |
-| 3 | Alinhamento Estratégico | 0.9 | 6.0 | no |
-| 4 | Excelência Operacional | 0.8 | 6.0 | no |
-| 5 | Capacidade de Inovação | 0.7 | 5.0 | no |
-| 6 | Gestão de Riscos | 0.8 | 6.0 | no |
-| 7 | Otimização de Recursos | 0.8 | 6.0 | no |
-| 8 | Valor para Stakeholders | 0.7 | 6.0 | no |
-| 9 | Sustentabilidade | 0.7 | 6.0 | no |
-| 10 | Adaptabilidade | 0.6 | 5.0 | no |
-
-### 3. Calculate Overall Score
-
-- Weighted average of all dimensions
-- Check if any dimension is below its minimum threshold
-- Check if VETO dimension (Verdade) passes
-
-### 4. Generate Assessment Report
-
-Use `assessment_template` from `pv-meta-axiomas.yaml`
-
-```yaml
-axioma_assessment:
-  process_name: "{nome}"
-  assessment_date: "{data}"
-  assessor: "@pedro-valerio"
-
-  dimensions:
-    - name: "{dimension}"
-      score: X/10
-      evidence: "{observações}"
-      recommendations: ["melhorias"]
-    # ... all 10
-
-  overall_score: X.X  # weighted average
-  pass_threshold: 7.0
-  status: "PASS | FAIL | REVIEW"
-  veto_triggered: true/false
-  recommendations: ["prioritized list"]
-```
-
-## Scoring Rules
-
-- Overall threshold: 7.0
-- Minimum per dimension: 6.0
-- Verdade < 7.0 → VETO regardless of overall score
-- Status: PASS (>= 7.0) | FAIL (< 7.0 or VETO) | REVIEW (borderline)
-
-## Completion Criteria
-
-- All 10 dimensions scored with evidence
-- Overall weighted score calculated
-- PASS/FAIL/REVIEW verdict
-- Recommendations for dimensions below threshold