[P1][Continuous Evolution] Coordenador deve descobrir, priorizar e abrir issues de evolução e melhoria

[wesleysimplicio]

Contexto

Relacionada a #466, que trata findings/problemas obrigatoriamente rastreados.

Além de reagir a defeitos, o coordenador do simplicio-loop deve conseguir identificar oportunidades reais de evolução durante intake, mapping, planning, execution, validation, review, delivery, watching e retrospectiva. Essas oportunidades precisam virar issues profundas e priorizáveis, sem misturar melhoria com bug e sem gerar backlog infinito ou desviar do objetivo atual.

Objetivo

Implementar um Continuous Evolution Coordinator capaz de:

1. detectar melhorias técnicas, arquiteturais, operacionais e de produto;
2. validar se há evidência e benefício suficiente;
3. procurar issue existente antes de criar;
4. abrir ou atualizar a issue no repositório proprietário;
5. produzir especificação profunda, plano passo a passo, testes e critérios de aceite;
6. priorizar por impacto, esforço, risco e alinhamento;
7. continuar a entrega atual, salvo quando a melhoria for requisito necessário para segurança, correção ou critérios de aceite;
8. nunca executar automaticamente trabalho fora do escopo autorizado apenas porque abriu a issue.

Taxonomia obrigatória

Classe	Significado	Tratamento
defect	comportamento viola contrato existente	usar lifecycle obrigatório de #466
regression	algo funcionava e deixou de funcionar	reabrir/vincular issue e revogar terminal quando aplicável
improvement	aperfeiçoa comportamento existente	issue de melhoria priorizada
evolution	nova capacidade ou mudança arquitetural	issue/epic com rollout e compatibilidade
optimization	performance, custo, memória, tokens ou latência	exigir baseline e meta mensurável
hardening	segurança, resiliência e observabilidade	exigir threat/failure model
discovery	hipótese ainda sem evidência suficiente	issue de investigação/RFC
maintenance	dívida, atualização, simplificação ou remoção	demonstrar custo/risco atual

O coordenador não pode rotular defeito como “melhoria” para evitar bloqueio, nem hipótese como fato confirmado.

Fontes de oportunidades

• repetição de retries, falhas ou trabalho manual;
• hotspots de performance, tokens, memória ou I/O;
• lacunas de integração entre componentes do ecossistema;
• código duplicado, complexidade crescente ou contratos divergentes;
• testes frágeis, lentos, ausentes ou com baixa capacidade de detectar regressão;
• feedback de review, watcher, usuário e retrospectiva;
• precedentes reutilizáveis ainda não automatizados;
• capabilities disponíveis mas não exercidas no fluxo real;
• versões, APIs ou formatos incompatíveis;
• observabilidade insuficiente;
• riscos de segurança e resiliência;
• documentação, instalação, empacotamento e onboarding deficientes;
• oportunidades de simplificação e redução de custo operacional.

Contrato da proposta

Criar simplicio.evolution-proposal/v1 com:

• proposal/fingerprint/run/task/stage/agent IDs;
• classe, componente e owner repository;
• problema ou limitação atual;
• evidências e baseline;
• resultado desejado;
• benefício esperado e métricas;
• impacto, blast radius, esforço e risco;
• dependências e incompatibilidades;
• alternativas consideradas;
• hipótese e confidence;
• prioridade calculada;
• issue target/URL e remote confirmation;
• estado: observed | validated | issue-created | linked | deferred | rejected | delivered.

Gate antes de abrir issue

O coordenador deve responder com evidência:

1. Existe problema, limitação ou oportunidade concreta?
2. Já existe issue, PR, RFC ou implementação equivalente?
3. Qual usuário/fluxo/componente se beneficia?
4. Qual resultado é mensurável?
5. Qual repositório é proprietário?
6. A proposta conflita com decisões arquiteturais?
7. É uma issue isolada ou precisa de epic/subissues?
8. Pode ser entregue incrementalmente e revertida?
9. O custo de manter como está justifica a mudança?

Propostas sem evidência mínima viram discovery, não implementação prometida.

Priorização

Implementar score explicável, nunca “prioridade inventada”:

• impacto no usuário/entrega;
• segurança e confiabilidade;
• frequência;
• economia de tempo/tokens/custo;
• desbloqueio de outras tasks;
• esforço;
• risco/migração;
• confidence da evidência;
• alinhamento ao objetivo/roadmap.

O report deve preservar os valores individuais e a justificativa. P0 fica restrito a segurança crítica, perda de dados, bloqueio sistêmico ou regressão grave.

Conteúdo mínimo da issue criada

• resumo e motivação;
• origem da descoberta;
• estado atual e limitação;
• evidências/baseline;
• resultado esperado e métricas;
• escopo e fora de escopo;
• arquitetura/contratos afetados;
• plano passo a passo;
• compatibilidade, migração e rollback;
• riscos e alternativas;
• plano de testes unitário, integração, sistema/E2E, performance e segurança conforme aplicável;
• critérios de aceite verificáveis;
• Definition of Done;
• links para reports, receipts, issues e PRs relacionados;
• marker/fingerprint estável para deduplicação.

Regras contra backlog infinito

1. Buscar por fingerprint e similaridade antes de criar.
2. Atualizar issue existente quando a oportunidade for equivalente.
3. Limitar propostas novas por run através de orçamento configurável.
4. Não criar issue a partir de mera preferência estilística sem impacto.
5. Agrupar ocorrências sistêmicas em epic + subissues responsáveis.
6. Não criar meta-issues recursivas sobre o próprio mecanismo sem evidência nova.
7. Registrar propostas rejeitadas/deferred para não regenerá-las em todo run.
8. Nunca pausar a task atual por melhoria não bloqueante.
9. Nunca incluir a nova issue automaticamente no working set atual sem autorização/política explícita.
10. Separar claramente backlog observado de escopo contratado.

Reports

Cada etapa deve reportar:

• oportunidades observadas;
• propostas validadas/rejeitadas/deferred;
• issues criadas/vinculadas;
• owner e prioridade;
• impacto na task atual;
• orçamento consumido;
• razão para não criar issue;
• confirmação remota.

O run report final deve incluir um Evolution Ledger, sem misturar propostas com defects de #466.

Plano de implementação

1. Definir schema, state machine e taxonomy.
2. Implementar collector transversal de oportunidades.
3. Integrar com stage reports e learning/retrospective.
4. Implementar evidence gate e proposal validator.
5. Implementar ownership routing reutilizando [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466.
6. Implementar dedup e busca de issues/PRs/RFCs.
7. Implementar scoring explicável e budgets.
8. Criar renderer profundo por classe de proposta.
9. Integrar GitHub outbox/confirmation de [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466.
10. Implementar policy para bloquear, apenas registrar ou incluir no backlog.
11. Adicionar CLI evolution list|report|flush|reconcile|doctor --json.
12. Atualizar SKILL.md, schemas, docs, bundle/plugin/wheel.
13. Criar conformance tests multi-runtime e multi-repo.
14. Medir taxa de duplicação, precisão das propostas e crescimento do backlog.

Testes obrigatórios

Unitários

• taxonomy e classificação;
• defect não reclassificado como improvement;
• fingerprint/dedup;
• evidence gate;
• scoring e prioridade;
• budget;
• target resolver;
• template validator;
• deferred/rejected memory;
• scope protection.

Integração

• oportunidade em cada stage;
• issue nova versus existente;
• outro repositório proprietário;
• fallback sem permissão;
• outbox offline/recovery;
• proposta não entra na execução atual;
• defect é encaminhado a [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466;
• optimization exige baseline/meta;
• evolution gera epic/subissues quando necessário.

Sistema/E2E

• run multi-repo com defects e melhorias simultâneos;
• reports separam findings obrigatórios de evolution proposals;
• múltiplos agents convergem sem duplicação;
• 100 observações iguais geram uma issue;
• proposta deferred não reaparece indefinidamente;
• entrega original conclui apesar de melhorias não bloqueantes;
• melhoria necessária aos ACs é promovida a dependência explícita.

Segurança e adversarial

• prompt injection tentando criar milhares de issues;
• agente inflando prioridade;
• dados sensíveis em evidência;
• owner malicioso/incorreto;
• issue content tratado como untrusted;
• tentativa de ampliar escopo automaticamente.

Critérios de aceite

• Coordenador detecta e classifica defects, improvements, evolutions, optimizations, hardening, discovery e maintenance.
• Defeitos continuam sujeitos ao contrato obrigatório de [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466.
• Melhorias validadas criam ou atualizam exatamente uma issue no owner correto.
• Toda issue contém evidência, baseline quando aplicável, passos, testes, critérios de aceite e DoD.
• Otimizações possuem baseline e meta mensurável.
• Prioridade é explicável e P0 não é usado indiscriminadamente.
• Dedup evita issues repetidas entre stages, agents e runs.
• Budgets e memória de rejected/deferred impedem backlog infinito.
• Melhorias não bloqueantes não interrompem a entrega atual.
• Nenhuma issue nova amplia automaticamente o escopo executado sem autorização.
• Stage e final reports apresentam Evolution Ledger separado do Finding Ledger.
• Criação/atualização possui outbox, retry e confirmação remota.
• Source/plugin/bundle/wheel permanecem em parity.
• Testes unitários, integração, sistema/E2E, recovery e segurança passam.
• Cada critério aponta para evidência reproduzível.

Definition of Done

Executar um run sandbox multi-repo com oportunidades injetadas em todas as etapas. O coordenador deve separar defeitos de melhorias, deduplicar propostas equivalentes, criar issues profundas nos owners corretos, priorizar com score explicável, respeitar budget, não ampliar o working set atual e entregar um Evolution Ledger confirmado remotamente.

Relações

• Complementa: [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466
• Reutiliza: stage reporting e receipts de [P0][Stage Agents][GitHub Reporting] Reportar cada item, agente e transição do fluxo por comentários idempotentes #433

[wesleysimplicio]

Implementado via PR #472

[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.