[Epic] Criar Simplicio Loop Hub: processamento central compartilhado por LLMs, IDEs e agents

[wesleysimplicio]

Problema

Várias instâncias do Simplicio Loop abertas por Codex, Claude, Cursor, VS Code, CLIs e agents podem repetir scanning, polling, embeddings, chamadas LLM e subprocessos, saturando CPU, RAM, disco, GPU e limites de API.

Resultado esperado

Um único Simplicio Loop Hub por usuário/máquina recebe trabalhos de todos os clientes, centraliza filas e caches e distribui capacidade com fairness, deduplicação, quotas e backpressure. O cliente continua funcionando em modo standalone quando o Hub não estiver disponível.

Arquitetura proposta

• Daemon singleton descoberto por lock/PID + socket Unix; named pipe no Windows; TCP local autenticado apenas como fallback.
• Protocolo versionado para register, submit, claim, heartbeat, progress, cancel, result e report.
• Fila durável local com WAL, idempotency key, lease/visibility timeout e dead-letter queue.
• Scheduler DRR/WFQ por workspace/cliente/prioridade, evitando monopolização.
• Resource governor com orçamentos de CPU, RSS, disco, GPU/VRAM, subprocessos, conexões e tokens/rate limits.
• Deduplicação por hash de projeto+commit+task+config; single-flight para mapper, embeddings e chamadas equivalentes.
• Cache central de mapas, precedentes, prompts e respostas permitidas, com invalidação explícita.
• Observabilidade: fila, utilização, latência, custo/tokens, retries, motivos de throttle e auditoria.
• Segurança: autenticação local, permissões do socket, isolamento por workspace, redaction e nenhuma exposição externa por padrão.

Plano passo a passo

1. Especificar contratos, threat model, estados e invariantes.
2. Implementar daemon e eleição singleton com recuperação de PID/lock obsoleto.
3. Implementar armazenamento durável e máquina de estados idempotente.
4. Implementar scheduler justo e limites hierárquicos global/cliente/workspace/provider.
5. Adicionar backpressure, circuit breaker, adaptive concurrency e proteção contra OOM.
6. Criar SDK/CLI cliente e auto-discovery com fallback standalone.
7. Migrar internamente mapper/dev-cli/remote workers atrás de adapters.
8. Implementar dedupe/single-flight/cache e invalidação.
9. Adicionar dashboard/doctor/status/drain/shutdown.
10. Executar rollout por feature flag, shadow mode e canário.
11. Publicar contrato para loop-oss, loop-marketing, agent, sprint e runtime.
12. Documentar operação multi-IDE/multi-LLM.

Cenários de teste

• 20+ clientes concorrentes e múltiplos workspaces.
• Cliente trava durante lease; daemon reinicia; rede/provider oscila.
• Pressão de RAM/CPU/GPU e limites de rate/token.
• Mesmo trabalho submetido simultaneamente por clientes diferentes.
• Segurança do IPC e tentativa de acesso entre usuários.
• Compatibilidade Windows/macOS/Linux e upgrade de protocolo.

Critérios de aceite

• Exatamente um Hub ativo por escopo configurado.
• Fairness mensurável e nenhum cliente causa starvation.
• Limites impedem saturação/OOM e propagam backpressure aos clientes.
• Dedupe executa trabalho equivalente uma vez e entrega resultado a todos os solicitantes.
• Reinício não perde tarefas confirmadas nem duplica efeitos não idempotentes.
• Modo standalone continua disponível.
• Contrato versionado, métricas, threat model e runbook publicados.
• Benchmark compara N processos isolados versus Hub em CPU, RSS, I/O, throughput e p95.

[wesleysimplicio]

🔁 Simplicio Loop — status da execução

Campo	Valor
Estado	PLANNED
Run / attempt	r-loop-cron-20260717 / a1

[wesleysimplicio]

PLANNING — WI-3291 (#496 Simplicio Loop Hub)

Canonical transition mapping → planning COMPLETE this tick.

• MEASURED| Planning receipt bound: verdict=COMPLETE, expires 2026-07-17T23:24:21Z, task_contract_hash dd9a9612…, plan_hash 92b68137….
• MEASURED| Epic decomposed into 4 child WIs (AC4 satisfied):
  • WI-3294 — Hub Daemon Singleton
  • WI-3295 — Durable Queue / WAL
  • WI-3296 — Fair Scheduler
  • WI-3297 — Resource Governor
• Each child WI carries its own acceptance criteria and depends on WI-3291.
• honest-close-gate active: architecture epic will not be closed by a working sub-command.

Next: each child WI advances mapping→planning→executing in isolated Orca worktrees with bounded --yolo (tencent/hy3:free); Codex independent review in validating; fresh reviewer in watching.

[wesleysimplicio]

MEASURED| GitHub-only decomposition migrated from the prior Orca comment:

• [Hub] Implementar daemon singleton e contrato IPC versionado #503 — Hub singleton + versioned IPC contract
• [Hub] Implementar fila durável WAL, leases e dead-letter #504 — Durable WAL queue, leases and dead-letter
• [Hub] Implementar scheduler justo DRR/WFQ e quotas por cliente #505 — Fair DRR/WFQ scheduler and client quotas
• [Hub] Implementar resource governor e limites globais #506 — Resource governor and global limits

These child issues are the GitHub source of truth for #496. The parent remains open until all children have independently verified PRs merged into main, live re-query confirmation, and the parent ACs are re-checked.

[wesleysimplicio]

MEASURED|Slice merged via PR #527 (c5215d5): governor standalone com budgets globais/cliente, admission/leases, circuit breaker, drain/shutdown e receipts redacted; 6 testes, cobertura focada 94%. UNVERIFIED|Integração scheduler/daemon/reports, probes OS reais, stress/benchmarks e canary/rollback continuam pendentes no #506.

[wesleysimplicio]

MEASURED|Slices Hub merged em main: PR #523 (daemon/IPC,

[wesleysimplicio]

Status rollup (agente automatizado) — os 4 sub-issues desta epic receberam um slice real e testado na wave 1, todos mergeados em claude/simplicio-loop-issues-jvhe89:

• [Hub] Implementar daemon singleton e contrato IPC versionado #503 (daemon singleton + IPC): transporte real via Unix domain socket (0600), doctor/status, shutdown idempotente, singleton provado com um teste cross-process real (dois processos disputando o mesmo lock).
• [Hub] Implementar fila durável WAL, leases e dead-letter #504 (fila durável WAL/leases/dead-letter): confirmado admission/lease/retry existentes; extensão focada em robustez.
• [Hub] Implementar scheduler justo DRR/WFQ e quotas por cliente #505 (scheduler DRR/WFQ): fairness medida (Jain's index) sob carga assimétrica + aging anti-starvation.
• [Hub] Implementar resource governor e limites globais #506 (resource governor): nova ResourceProbe cross-platform (cgroups → psutil → stdlib → unavailable, nunca crasha) ligada ao circuit breaker existente; admissão pré-spawn e recuperação half-open→closed comprovadas.

Nenhum está 100% fechado (faltam named-pipe/TCP no Windows, stress com 20 clientes concorrentes, benchmarks de latência p50/p95 e cobertura ≥85% medida). Ver os comentários individuais em #503–#506 para o detalhe AC-a-AC. Esta epic (#496) permanece aberta.

---

Generated by Claude Code

[wesleysimplicio]

MEASURED|Atualização do child #503: PR #551 mergeada em origin/main (b5e1fba), com named pipe Windows, CLI/doctor e runbook. UNVERIFIED|O parent #496 permanece aberto até todos os children e seus critérios completos terem reconsulta independente.