[P0][Extension Integration] Conectar loop-oss ao Loop core/Hub sem duplicar arquitetura

[wesleysimplicio]

Core contract: https://github.com/wesleysimplicio/simplicio-loop/issues/557
Parent ecosystem: https://github.com/wesleysimplicio/simplicio-loop/issues/555

Correção de arquitetura

simplicio-loop-oss é a extensão oficial do Loop para contribuição em projetos open source. Ela não é cliente/produto paralelo e não deve criar coordinator, scheduler, queue, daemon ou completion engine próprios.

standalone significa carregar o mesmo Loop core em modo embedded.

Objetivo

Empacotar o fluxo OSS como extensão loop.oss: herdar toda a arquitetura operacional do Loop e acrescentar somente fontes, perfis, políticas, especializações de stages/agentes, efeitos GitHub e relatórios de contribuição open source.

Fronteira da extensão

Herdado do Loop

• goal/run/task/stage/attempt e stage graph;
• coordinator, Hub, queue, scheduler, lease, fence e backpressure;
• agentes-base, retries, recovery, cancel e budgets;
• mapper/dev-cli/runtime bindings;
• receipts, findings, reports e semântica de conclusão;
• modos embedded/daemon/remote e conformance.

Fornecido pelo OSS

• source adapter GitHub/upstream repository;
• RepoProfile e schemas de contexto OSS;
• políticas de seleção, reputação, newcomer, CLA/DCO e limites de PR;
• especializações para triage, reprodução, implementação e review;
• gates de upstream policy, CI, review e mergeability;
• efeitos idempotentes: branch/PR/comment/update;
• relatórios de contribuição e handoff.

Passo a passo

1. Fixar requires_core e consumir simplicio.loop-extension/v1.
2. Criar manifesto loop.oss com capabilities, schemas, overlays, roles, gates, effects e budgets.
3. Converter o conteúdo do SKILL em configuração/políticas/bindings, não em motor de workflow.
4. Registrar GitHub/upstream como source adapter.
5. Mapear fases OSS aos hooks do stage graph canônico.
6. Declarar workers determinísticos e boundaries de agent conforme [P0][OSS Extension][Performance] Executar fases mecânicas como bindings do Loop e reservar agents para decisões OSS #9.
7. Delegar scheduling, claims, leases, fence, retries e stop modes ao core.
8. Centralizar snapshot/cache/rate limit via serviços do core.
9. Tornar branch/PR/comment efeitos governados com idempotência e confirmação remota.
10. Propagar os mesmos run/task/attempt/fence IDs.
11. Preservar isolamento por repo/worktree.
12. Expor doctor/status com core, extensão, capabilities e budgets.
13. Implementar embedded com o mesmo core do daemon/remote.
14. Migrar logs/backlogs sem false COMPLETE.
15. Rodar conformance e benchmarks multi-host/multi-repo.
16. Documentar instalação e scheduling sem daemon duplicado.

Testes obrigatórios

• manifesto válido/incompatível;
• dois hosts/IDEs no mesmo repo;
• múltiplos repos e fairness;
• candidato/PR duplicado;
• CLA/DCO/newcomer policy;
• CI red→green, review e conflito;
• rate limit/outage/stale snapshot;
• worker/agent crash e lease reclaim;
• stale fence e efeito duplicado;
• cancel/drain/budget exhausted;
• embedded/daemon/remote parity;
• E2E até PR verificado;
• benchmark de API calls, tokens, processos, p50/p95, CPU e RSS.

Revisão complementar do projeto: simplicio-loop-oss

Responsabilidade avaliada: open source. Esta issue deve ser entendida no contexto da auditoria-mãe do repositório.

Objetivo específico

validar issue → plano → branch → patch → testes → PR

Fluxo de testes obrigatório

conflito, licença, segredo, dependência externa, rollback e escopo

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.

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.

Execução

• Implementar o objetivo descrito.
• Fazer a implantação aplicável.
• Executar e registrar os testes.

[wesleysimplicio]

A separação agent vs worker e remoção de polling/token churn das fases mecânicas foi detalhada em #9. Parent de ownership/SLOs: https://github.com/wesleysimplicio/simplicio-loop/issues/555.