[P0][Integration] Tornar Simplicio Code cliente interativo prioritário do Loop Hub sem Runtime/map/scheduler duplicado

[wesleysimplicio]

Emenda canônica — Code não duplica o ecossistema

Precedência: esta seção substitui qualquer menção conflitante abaixo a “Agent opcional” ou a um modo produtivo que dispense o Agent.

• O modo produtivo do Simplicio Code exige Simplicio Agent + Simplicio Runtime compatíveis, conforme [P0][Integration] Tornar Runtime + Agent obrigatórios no Code e entregar painel proativo do Agent #50.
• Para goals em waves, processamento de múltiplas issues, filas globais ou coordenação paralela, o Loop Hub é obrigatório; o Code não pode cair silenciosamente para scheduler/fan-out local.
• Operações simples podem não criar um workflow Loop, mas continuam passando por Agent + Runtime; isso não autoriza agente embutido nem efeitos locais.
• Mapper fornece mapa/contexto canônico e overlay; Dev CLI fornece contratos/comandos de desenvolvimento; o Code expõe esses comandos por adapters versionados, sem copiar suas engines.
• O bundle/instalador pode distribuir o ecossistema inteiro, mas ownership, processos e estados continuam independentes.
• A aceitação deve provar o comando natural “termine todas as issues do projeto X” como Code → Agent → Loop Hub → Runtime/Mapper/workers → reconsulta remota, com receipts e sem duplicação.

Texto histórico abaixo permanece para rastreabilidade.

---

Parent: wesleysimplicio/simplicio-loop#555
Related: #49, #50; closed #42/#43; wesleysimplicio/simplicio-loop#496, #497, #555; wesleysimplicio/simplicio-runtime#3327

Diagnóstico verificado no código

O Code já usa Tokio e possui bons boundaries Runtime-first, porém há pontas soltas de velocidade/economia:

• simplicio-runtime-client::RuntimeClient::spawn_in inicia um processo Runtime MCP por client/workspace;
• start_workspace_map usa MAPPED_WORKSPACES somente process-local, inicia outro child e thread;
• duas instâncias TUI/headless/ACP podem repetir Runtime, handshake e mapa;
• xai-prompt-queue é fila de prompts da UX, não deve virar segunda fila global;
• xai-computer-hub-* é transporte/registry de tools herdado, não deve competir com o Loop Hub;
• list/stat/edit/exec e bypasses restantes estão em [P0][Regression/Audit] Eliminar bypasses restantes do Runtime após o fechamento da #5 #49;
• AgentHost opcional está em [P0][Integration] Tornar Runtime + Agent obrigatórios no Code e entregar painel proativo do Agent #50 e não pode criar segundo loop cognitivo.

Objetivo

Integrar TUI, headless, ACP e workspace ao Loop Hub como clientes interativos de alta prioridade, compartilhando Runtime, mapa, inference/process capacity e workflow state sem perder sandbox, fail-closed ou responsividade.

Decisão de ownership

• Code: UX, sessão, prompt/interjection, approval, diffs, progress e evidence presentation.
• Loop Hub: workflow, queue, fairness, claims e dedupe.
• Runtime: filesystem/process/effects/resources/inference.
• Mapper: canonical map/overlay/context handle.
• Agent: reasoning opcional via CoordinatorAdapter [P0][Integration] Tornar Runtime + Agent obrigatórios no Code e entregar painel proativo do Agent #50.
• Computer Hub existente: tool transport adapter; não scheduler/work queue.
• Prompt queue existente: entrada do usuário/session ordering; não resource queue.

Passo a passo

1. Criar LoopHubClient crate/adapter versionado e capability handshake.
2. Descobrir/reusar daemon por usuário/máquina; não spawnar um por Code process.
3. Substituir Runtime child por workspace por Runtime session/connection handle do Hub quando ativo.
4. Fazer map request pelo Map Service #497; remover dedupe apenas process-local como autoridade.
5. Compartilhar map/context/cache handles entre TUI/headless/ACP.
6. Submeter coding goal/DAG ao Hub com classe interactive, deadline e budget.
7. Reservar capacidade mínima interativa sem furar quota global.
8. Integrar streaming progress, queue position, throttle, cancel, resume e receipts.
9. Ligar [P0][Regression/Audit] Eliminar bypasses restantes do Runtime após o fechamento da #5 #49: todas as operações continuam via Runtime gate.
10. Ligar [P0][Integration] Tornar Runtime + Agent obrigatórios no Code e entregar painel proativo do Agent #50: AgentHost é coordinator opcional; nunca executa tools/effects em paralelo ao loop nativo.
11. Fazer xai-computer-hub bridgear tool calls ao Runtime/Hub sem state machine duplicada.
12. Manter xai-prompt-queue limitada à UX e propagar backpressure ao submit.
13. Implementar idempotency por session/turn/goal e evitar duplo PR/tool effect.
14. Reusar gateway/model connections e inference pool.
15. Expor status no TUI: queue, worker, map/cache hit, tokens/custo, route agent/worker.
16. Implementar auto|hub|required|standalone e fail-closed configurável.
17. Criar migration/compatibility N/N-1 e rollout shadow/canário.
18. Atualizar product E2E com duas instâncias simultâneas.

SLOs interativos

• startup e workspace-open p50/p95;
• handshake count por workspace;
• tempo até mapa parcial/first token/first tool progress;
• queue wait interativa;
• tokens e custo por tarefa verde;
• Runtime/map/model processes por máquina;
• CPU/RSS/I/O cold/warm;
• cancel latency e resume latency.

Testes

• duas TUIs + headless + ACP no mesmo workspace;
• múltiplos workspaces/worktrees;
• Hub/Runtime/Mapper restart;
• protocol mismatch/fallback;
• queue full e interactive reservation;
• cancel durante inference/tool/process;
• AgentHost on/off e coordinator switching;
• no local filesystem/process bypass;
• duplicate prompt/turn/reconnect;
• xai-computer-hub/tool transport parity;
• prompt queue vs resource queue separation;
• cross-platform Unix socket/named pipe;
• E2E goal→diff→test→PR receipt;
• benchmark isolado vs compartilhado.

Critérios de aceite

• Uma máquina/workspace não abre Runtime/map/model worker redundante por superfície.
• Code não possui scheduler global concorrente.
• Computer Hub e prompt queue têm boundaries explícitos e testados.
• Interatividade recebe prioridade justa, sem starvation de background.
• Toda operação continua fail-closed pelo Runtime.
• AgentHost opcional não duplica tool calls ou efeitos.
• Cancel/restart/resume preservam idempotência.
• TUI/headless/ACP produzem receipts equivalentes.
• Startup, p95, tokens, CPU/RSS/I/O e processos melhoram contra baseline.
• E2E atualiza a evidência dos itens fechados [EPIC][P0][#16] Integrar simplicio-loop por contrato e materializar agentes dedicados no Simplicio Code #42/[P0][#16][Product E2E] Certificar jornada completa do usuário até delivery confirmado #43 e parent #555.

Revisão complementar do projeto: simplicio-code

Responsabilidade avaliada: IDE/orquestração. Esta issue deve ser entendida no contexto da auditoria-mãe do repositório.

Objetivo específico

validar usuário → plano → Agent/Runtime → alteração → testes → PR

Fluxo de testes obrigatório

comando → plano → execução → diff → testes → cancelamento → retomada

1. Registrar SHA/branch, ambiente, dependências e configuração.
2. Executar o caminho feliz completo e capturar logs/receipts.
3. Injetar entrada inválida, timeout, falha externa ou permissão ausente aplicável.
4. Verificar retry, cancelamento, idempotência e rollback quando o fluxo suportar.
5. Executar testes unitários, integração, sistema/E2E, regressão, segurança e desempenho aplicáveis.
6. Reexecutar com os mesmos dados e comparar resultado/hashes.
7. Confirmar que falha nunca vira sucesso e que recursos são liberados.

Critérios de aceite adicionais

• O comportamento principal está demonstrado por teste executável.
• Pelo menos um caminho de falha está coberto e documentado.
• Contratos entre projetos são validados nas versões/SHAs declarados.
• Logs e receipts permitem reconstruir a decisão.
• Métricas não observáveis são null com motivo, nunca estimadas.
• Segredos, PII e dados privados não aparecem nos artefatos.
• O procedimento é reproduzível localmente ou em container sem GitHub Actions pago.
• PR/commit, logs, hashes e riscos residuais estão anexados antes de fechar.

Evidências obrigatórias

• PR/commit vinculado;
• comandos e versões;
• logs do caminho feliz e da falha;
• testes/coverage/benchmark aplicáveis;
• receipts, hashes e relatório de rollback;
• limitações e próximos passos.

Regra de encerramento

Não fechar sem todos os critérios desta issue e da auditoria-mãe atendidos. Se faltar implementação, marcar como NEEDS-IMPLEMENTATION ou BLOCKED, nunca como concluída.

[wesleysimplicio]

Refinamento de Wave/Tokio e slot único — 2026-07-20

MEASURED| a baseline Runtime #3486 (ddc19f45726a5221e630b07880293386f332dbc0) define modelo/engine residentes, fila/backpressure e um slot físico. A integração deve preservar isso.

• Wave pertence ao Agent/Loop como DAG lógico; cada nó de inferência entra na fila única do Runtime.
• Tokio pertence ao Runtime para IPC, watchers, filesystem/process I/O, streaming e cancelamento.
• O engine deve ser um actor único/handle não exportável; max_active_inference == 1.
• Ferramentas e pré/pós-processamento podem paralelizar com quotas, mas geração permanece serial.
• Advisory background: no máximo uma inferência pendente, debounce/coalescing, prioridade inferior à interativa e anti-starvation.
• Economia: ferramentas determinísticas, deltas por hash, context packs mínimos, hot turns e KV/prefix cache sob posse exclusiva do Runtime.
• Code prompt queue continua somente ordenação de UX; nunca vira resource queue.

Aceite adicional local: duas TUIs + headless + ACP sob carga devem observar um único model_instance_id, fila bounded, zero Runtime/map/model duplicado e cancel/replay idempotentes. GitHub Actions não será usado como evidência.

[wesleysimplicio]

Emenda canônica — dependências produtivas, Loop e pausa local

Precedência: esta emenda supera qualquer texto histórico que descreva Agent como opcional, permita coordenador/bypass produtivo local, ou exija Loop para uma tarefa simples.

• O modo produtivo do Simplicio Code requer Simplicio Agent + Simplicio Runtime compatíveis; ausência/incompatibilidade bloqueia tools e efeitos, preservando apenas diagnóstico explícito sem efeito.
• Runtime e Agent continuam independentes do Code; Code os consome por contratos versionados, sem copiar engines, scheduler ou executor.
• Loop é opcional em uma tarefa simples. Ele passa a ser obrigatório apenas para waves, múltiplas issues, filas globais ou coordenação paralela; não há scheduler/fan-out local silencioso nesses casos.
• Inferência local (Qwen/llama.cpp/Ollama/MLX) fica pausada por padrão; não pode haver download/spawn/rede/fallback automático. Reativação ou provider remoto só por policy explícita, com receipt/reason estável.
• Ao selecionar MCP do Runtime para um efeito, Code/Agent usam exclusivamente o executor Runtime/EffectTransaction de wesleysimplicio/simplicio-runtime#3491; efeitos desconhecidos são reconciliados antes de retry.

Aceite adicional: testar TUI, headless, ACP e workspace para Agent+Runtime ausentes/incompatíveis, tarefa simples sem Loop, wave com Loop obrigatório, pausa local com interceptação de rede/processo, cancel/restart/replay e receipts causais. Evidência local, sem GitHub Actions.

[wesleysimplicio]

Auditoria da lane: contrato de admissão Loop Hub existe, porém o adapter/transporte compartilhado e o E2E Code → Agent → Loop Hub → Runtime ainda não estão presentes no Code. Mantida aberta para não confundir validator com integração executável.