[P0][OSS Extension][Performance] Executar fases mecânicas como bindings do Loop e reservar agents para decisões OSS

[wesleysimplicio]

Parent: #8
Core contract: https://github.com/wesleysimplicio/simplicio-loop/issues/557
Related: wesleysimplicio/simplicio-loop#555, #556

Diagnóstico

O SKILL.md descreve bootstrap, git/GitHub, scans, dedupe, CI/review babysit, planning, implementação, testes, persistência e scheduling. Parte mecânica pode consumir turnos/tokens e repetir polling por host.

A solução não é compilar um workflow engine OSS. O Loop core mantém o stage graph e a autoridade operacional; a extensão OSS registra bindings de domínio.

Objetivo

Executar coleta, dedupe, policies, mapper, testes e CI como handlers determinísticos da extensão loop.oss. Acionar agentes do core somente em decisões OSS que exigem interpretação, criação ou revisão semântica.

Mapeamento ao Loop

• intake/planning → descobrir upstream, RepoProfile, candidato e policy preflight;
• executing → sync/worktree, reprodução e implementação;
• validating → lint/build/test, CLA/DCO, diff e policy gates;
• watching/recovery → CI/review events, conflitos e recovery;
• delivering → branch/PR/comment como efeitos governados;
• reporting → contribution report, reputation e handoff;
• completion → auditoria herdada do core com confirmação remota.

Classificação

Handler determinístico

• clone/sync/status/worktree;
• coleta issue/PR/CI;
• dedupe e anti-duplicate index;
• CLA/DCO/policy checks estruturados;
• mapper/search/retrieval;
• build/test/lint;
• métricas, receipts e event collection;
• publicação previamente autorizada.

Agent especializado

• avaliar relevância/mergeability quando a policy é inconclusiva;
• investigar bug novo;
• produzir mudança não mecânica;
• fazer review semântico adversarial;
• responder feedback técnico não classificável;
• escolher recovery quando não existe regra segura.

Passo a passo

1. Inventariar cada fase do SKILL e classificar handler/agent/híbrido.
2. Registrar os bindings no manifesto loop.oss.
3. Usar apenas hooks oficiais do stage graph; não criar DAG próprio.
4. Criar RepoProfile declarativo por upstream.
5. Substituir polling por eventos/webhooks; coalescer fallback polling no core.
6. Reutilizar snapshot/cache/rate limit por repo.
7. Usar mapper canônico e Dev CLI pelos bindings do Loop.
8. Executar router deterministic-first antes de agent.
9. Isolar worktree/branch e propagar fence/idempotency.
10. Modelar reputation/newcomer/PR caps como policies.
11. Reutilizar AgentHost/context/memory quando compatível.
12. Emitir handoff sem bloquear outros repos.
13. Delegar stop/drain/budget/fairness ao core.
14. Preservar one-shot por core embedded.
15. Migrar logs/backlogs e documentar operação.

Testes obrigatórios

• classificação de routes e receipt de decisão;
• dois hosts no mesmo repo;
• múltiplos repos/orgs;
• duplicate candidate/PR;
• CI red→green, review feedback e conflict;
• GitHub rate limit/outage;
• worker/agent crash e lease reclaim;
• CLA block/newcomer caps;
• cancel/drain/stale snapshot/stale fence;
• embedded/daemon/remote parity;
• benchmark polling, tokens, API calls, processos, p95 e PR verificado.

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.