[P1][Elastic Replication] Coordenador solicitar agents duplicados e execução especulativa para reduzir tempo total

[wesleysimplicio]

Contexto

Complementa #468 (Adaptive Architecture), #467 (Continuous Evolution) e a infraestrutura de stage agents/coordinator de #422–#424.

A missão operacional é concluir o backlog no menor tempo possível sem reduzir qualidade, segurança ou evidência. Para isso, o coordinator precisa distinguir:

1. Parallel sharding: distribuir tarefas independentes entre agents diferentes — estratégia padrão.
2. Stage fan-out: executar revisões/verificações independentes simultaneamente.
3. Speculative replication / hedged execution: criar réplicas da mesma task/etapa quando houver risco de tail latency, stall, abordagem incerta ou capacidade ociosa.

A duplicação ingênua gera custo, conflitos e efeitos repetidos. A replicação governada reduz o tempo de cauda: o primeiro resultado verificado vence; não simplesmente o primeiro a responder.

Objetivo

Implementar um Elastic Agent Replication Coordinator capaz de solicitar dinamicamente novos agents/replicas, dividir o trabalho, executar estratégias em paralelo, selecionar um vencedor por evidência, cancelar perdedores e preservar exactly-once effects.

Objetivo de otimização:

minimize verified_time_to_completion
subject to:
  acceptance_criteria = satisfied
  safety_gates = passed
  mutation_effects = exactly_once
  budget <= configured_limits
  evidence = independently_verified

Modos de paralelismo

Modo	Uso	Regra
shard	tasks independentes	um owner/claim por task
stage_fanout	reviewers/checks independentes	resultados sintetizados; não first-wins
replica_same_strategy	straggler/falha transitória	first verified wins
replica_diverse_strategy	problema difícil/incerto	abordagens/modelos/tools diferentes
redundant_verification	risco alto	quorum/independência, não first-wins
hot_standby	worker/runtime instável	assume somente após fence/lease válido
portfolio	várias decomposições/planos candidatos	planner/synthesizer escolhe antes da mutação

Quando replicar

O coordinator pode solicitar réplicas quando um ou mais sinais ocorrerem:

• duração ultrapassa threshold baseado no histórico/p95;
• heartbeat sem progresso útil;
• mesmo failure fingerprint/retry;
• alta variância de latência do runtime/provider/tool;
• tarefa critical-path bloqueia múltiplas dependências;
• confidence baixa ou múltiplas estratégias plausíveis;
• capacidade/slots ociosos e budget disponível;
• risco de timeout/SLA;
• operação read-only ou candidate-producing segura para especulação;
• policy exige redundância para task crítica.

Não replicar automaticamente quando:

• mutação não é isolável/idempotente;
• há aprovação humana em andamento;
• efeito externo não possui intent/confirmation/reconciliation;
• custo excede ganho estimado;
• task é pequena e startup overhead domina;
• slots são mais valiosos para outras tasks ready;
• duplicação viola rate limit, licença, provider policy ou recurso escasso.

Protocolo de solicitação

Criar simplicio.agent-replication-request/v1:

• request/run/task/stage/attempt/fence IDs;
• mode e reason code;
• requested/min/max replicas;
• deadline e latency target;
• strategy diversity requirements;
• capability/model/runtime/tool constraints;
• isolation level;
• mutation policy;
• token/cost/CPU/RAM/slot budget;
• cancellation policy;
• verification/winner policy;
• evidence requirements;
• parent/coordinator identity;
• idempotency key e manifest hash.

Resposta simplicio.agent-replication-decision/v1:

• admitted/partial/denied;
• replicas materializadas e identities;
• adapter/slots resolvidos;
• budgets reservados;
• rejected candidates/reasons;
• start timestamps e leases.

Segurança de mutação

Regra fundamental

Réplicas da mesma task não escrevem simultaneamente no target compartilhado.

Caminhos permitidos:

1. read-only analysis;
2. candidate patch/plan em artifact content-addressed;
3. worktree/branch isolada por replica;
4. sandbox/transaction privada;
5. mutation intent sem commit externo;
6. promoção por um único winner_committer após verificação.

Requisitos:

• claim/lease/fence por replica;
• target/resource locks explícitos;
• side-effect class;
• idempotency key;
• intent/confirmation/reconciliation;
• stale replica perde mutation authority;
• somente winner receipt libera promoção;
• loser não pode push/merge/close/commentar terminal;
• efeitos externos irreversíveis desabilitam hedge salvo adapter transacional comprovado.

Seleção do vencedor

Não usar first_response_wins. Usar first_verified_candidate_wins ou policy equivalente.

Candidate precisa:

• cobrir ACs;
• compilar/lintar/testar conforme contrato;
• passar safety;
• não possuir findings bloqueantes;
• manter scope e compatibilidade;
• produzir receipt válido/fresco/hash-bound;
• passar verificação independente;
• comparar custo/qualidade quando dois candidatos chegam próximos.

Para portfolio/diverse strategies, um synthesizer independente pode:

• escolher um candidate;
• combinar partes não conflitantes;
• solicitar correção;
• rejeitar todos.

Combinação nunca ocorre diretamente no target sem composed validation.

Cancelamento e cleanup

Após winner confirmation:

1. persistir winner intent/receipt;
2. revogar leases/fences dos losers;
3. enviar cancel;
4. kill-tree/process/session quando autorizado;
5. impedir late receipts de promover state;
6. preservar artifacts/evidence mínimos para auditoria;
7. remover worktrees/temp resources com ownership comprovado;
8. liberar budgets/slots;
9. reportar cancel/cleanup confirmation;
10. reconciliar agentes não observáveis.

STOP/cancel global prevalece sobre replica lifecycle.

Scheduler e política de velocidade

Prioridade recomendada:

1. shardar todas as tasks ready independentes;
2. manter coordinator e gates essenciais com slots reservados;
3. proteger critical path;
4. replicar stragglers/uncertain tasks;
5. usar capacidade restante para antecipar validações read-only;
6. reduzir réplicas quando queue pressure aumentar.

Implementar adaptive admission usando:

• dependency DAG/critical path;
• historical duration distribution;
• queue depth;
• available slots;
• startup cost;
• token/cost budget;
• probability of replica beating original;
• value of saved time;
• cancellation latency;
• provider/rate limits.

Diversidade de estratégias

Réplicas podem variar controladamente:

• decomposição/plano;
• modelo local/remoto;
• provider/runtime;
• tool/skill;
• retrieval context;
• algoritmo/implementation approach;
• ordem de investigação.

Não variar:

• ACs;
• safety policy;
• mutation authority;
• source revision;
• manifest/gate contract;
• forbidden actions.

O report deve indicar diversidade real; nomes diferentes com prompt/context idêntico não contam como estratégia independente.

Reports

Cada stage/run report deve mostrar:

• tasks sharded;
• replication requests/decisions;
• replica identities/strategies;
• slots e budgets;
• progresso/heartbeats;
• winner e verification;
• losers/cancel/cleanup;
• tempo economizado estimado e medido;
• custo/tokens adicionais;
• conflitos/late results;
• denied replication reason;
• evidence links.

Métricas:

• verified time-to-completion;
• p50/p95/p99 stage/task latency;
• hedge win rate;
• wasted compute ratio;
• cancellation latency;
• duplicate-effect count (meta = 0);
• quality regression rate (meta = 0);
• cost per verified task;
• queue throughput.

Integração multi-runtime

O coordinator solicita capacidade; adapters materializam conforme disponível:

1. native subagents/sessions;
2. processos CLI isolados;
3. queue workers locais/remotos;
4. hot standby;
5. denial honesto BLOCKED/DEGRADED(no_replica_capacity).

Poucos slots não removem roles obrigatórios. O scheduler executa ondas e decide se replicar é melhor que iniciar outra task.

Plano de implementação

1. Definir schemas request/decision/replica/candidate/winner/cancel/cleanup.
2. Instrumentar duration/heartbeat/progress histórico.
3. Implementar critical-path e straggler detector.
4. Implementar admission controller com slots/budgets.
5. Estender StageAgentCoordinator/adapters para replica groups.
6. Implementar strategy diversity planner.
7. Implementar isolamento por worktree/sandbox/artifact.
8. Implementar candidate registry content-addressed.
9. Implementar independent verifier/winner selector.
10. Implementar winner_committer exactly-once.
11. Implementar lease/fence revocation e late-result rejection.
12. Implementar cancel/kill-tree/cleanup/reconciliation.
13. Integrar stage reports e GitHub reporting.
14. Expor CLI:

• agents capacity --json;
• agents replicate request|status|cancel --json;
• agents replicas list --json;
• agents hedge doctor|metrics --json.

15. Implementar policy/budgets e defaults conservadores.
16. Atualizar manifests, skills, docs e bundles.
17. Validar em native/command/queue adapters.
18. Executar benchmarks antes/depois e publicar receipts.

Testes obrigatórios

Unitários

• shard versus replica classification;
• straggler detection;
• critical path;
• admission/budget;
• strategy diversity;
• winner policy;
• stale fence;
• late receipt;
• cancel state machine;
• metric calculation.

Integração

• original vence e cancela hedge;
• hedge vence e original perde authority;
• dois candidates chegam simultaneamente;
• winner falha verification;
• todos candidates falham;
• replica crash/restart;
• coordinator crash antes/depois do winner intent;
• capacity reduz durante execução;
• provider rate limit;
• worktree conflict;
• cleanup parcial e reconciliation.

Sistema/E2E

• backlog com tasks independentes maximiza sharding;
• uma task critical-path lenta recebe hedge;
• diverse strategies para bug difícil;
• redundant verification para security-critical;
• 4 slots executam roles em ondas sem starvation;
• 100 agents/replicas sob backpressure;
• STOP cancela todo replica group;
• winner único entrega PR/merge/close;
• nenhum loser produz efeito externo.

Segurança/adversarial

• agent pede milhares de replicas;
• prompt injection altera budget/policy;
• replica tenta usar fence do winner;
• loser tenta push/merge;
• secret inheritance;
• forged winner receipt;
• cancellation race com delivery;
• malicious candidate artifact;
• symlink/path traversal no cleanup.

Performance

• medir p50/p95/p99 antes/depois;
• threshold onde hedge compensa startup/custo;
• throughput sob queue pressure;
• wasted compute;
• cancellation latency;
• token/cost overhead;
• duplicate effects = 0.

Critérios de aceite

• Coordinator diferencia sharding, fan-out, replication, redundant verification e portfolio.
• Tarefas independentes são paralelizadas antes de replicar indiscriminadamente.
• Replicação ocorre por sinais, critical path, capacidade e budget mensuráveis.
• Primeiro candidate apenas vence após verificação independente.
• Réplicas não aplicam mutações concorrentes no mesmo target.
• Exatamente um winner possui authority para promoção/delivery.
• Leases/fences impedem late loser de alterar state.
• Cancel/cleanup/reconciliation são observáveis e recuperáveis.
• Estratégias diversas preservam ACs e safety policy.
• Scheduler evita starvation de tasks ready e roles obrigatórios.
• Budgets impedem explosão de agents, tokens, custo, CPU e RAM.
• Native/command/queue adapters obedecem ao mesmo contrato.
• Reports mostram replicas, winner, losers, custo e tempo economizado.
• p95/p99 e verified time-to-completion melhoram no benchmark-alvo.
• Quality regression e duplicate-effect permanecem zero.
• Testes unitários, integração, sistema, segurança, recovery e performance passam.
• Cada critério aponta para receipt/test/benchmark reproduzível.

Definition of Done

Executar um backlog sandbox com tasks independentes, uma task critical-path lenta, uma task incerta e uma task de alto risco. O coordinator deve maximizar sharding, lançar hedge somente quando vantajoso, testar estratégias diversas, exigir redundância onde necessário, selecionar o primeiro resultado verificado, cancelar losers, preservar exactly-once effects e demonstrar redução mensurável de p95/p99 sem regressão de qualidade.

Relações

• Complementa: [P1][Adaptive Architecture] Coordenador propor novos stages, agents e ajustes amplos do fluxo #468
• Reutiliza evolução e issue routing: [P1][Continuous Evolution] Coordenador deve descobrir, priorizar e abrir issues de evolução e melhoria #467, [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466
• Estende stage agent coordinator/adapters: [EPIC][P0][Portable Stage Agents] Materializar agentes concretos em cada etapa do simplicio-loop em qualquer runtime #422–[P0][Stage Agents][Driver] Criar coordinator portátil e adapters para materializar agentes em qualquer runtime #424
• Integra stage reporting: [P0][Stage Agents][GitHub Reporting] Reportar cada item, agente e transição do fluxo por comentários idempotentes #433

[wesleysimplicio]

Implementado via PR #470

[wesleysimplicio]

UNVERIFIED — auditoria do run de 2026-07-17 encontrou que o comentário anterior “Implementado via PR” aponta para PRs que não existem neste repositório, e origin/main não contém commits correspondentes a esta issue. Reaberta para preservar a evidência-gated Definition of Done; não considerar encerrada até haver PR/commit verificável em main, testes e receipts ligados.