[P1][Adaptive Architecture] Coordenador propor novos stages, agents e ajustes amplos do fluxo

[wesleysimplicio]

Contexto

Complementa #467 (Continuous Evolution) e estende a arquitetura de stage agents entregue em #422–#433.

O simplicio-loop já possui manifesto, coordinator, papéis e receipts por etapa. O próximo nível é permitir que o coordenador reconheça quando a topologia atual deixou de ser suficiente e abra solicitações rastreáveis para:

• criar uma nova etapa;
• criar um novo papel/agente especializado;
• dividir ou fundir etapas;
• adicionar/remover/reordenar gates;
• mudar dependências e condições de ativação;
• ajustar retries, timeouts, capacidade, ondas, isolamento ou handoffs;
• adicionar novos adapters, ferramentas, verificadores ou receipts;
• criar subfluxos específicos por tipo de projeto, risco ou tarefa;
• simplificar/remover etapas que não geram valor comprovado.

Essa capacidade deve ser autoarquitetura governada, não automodificação silenciosa.

Objetivo

Implementar um Adaptive Workflow Architecture Coordinator que detecte necessidades estruturais amplas, produza RFCs/issues profundas, simule a mudança, valide segurança/compatibilidade e conduza promoção versionada com canário e rollback.

Fluxo obrigatório:

observation
  → topology gap
  → evidence/baseline
  → dedup + ownership
  → architecture proposal/RFC
  → static validation
  → DAG simulation + shadow run
  → risk/approval gate
  → versioned manifest candidate
  → canary
  → measured comparison
  → promote | revise | rollback

Princípios

1. Pode propor, não pode se autorizar sozinho. O coordenador abre a issue/RFC; aplicação depende da política de risco e autoridade.
2. Manifesto é a autoridade. Nenhum prompt pode criar um stage/agent fora de uma revisão versionada do manifesto.
3. Necessidade antes de quantidade. Novo agent exige boundary, capability, input/output, independência e evidência de valor; “mais agents” não é objetivo.
4. Etapa e agente são conceitos distintos. Uma etapa pode usar um papel existente; um papel pode materializar instâncias em vários stages.
5. Mudança mínima. Preferir ajustar regra/capability existente antes de criar nova etapa.
6. Fail-closed nos gates obrigatórios. Nenhuma proposta pode enfraquecer segurança, revisão ou completion sem aprovação explícita e prova equivalente.
7. Compatibilidade e migração. Runs ativos permanecem presos ao manifest hash inicial; nova topologia vale para novos runs/canários.
8. Reversibilidade. Toda mudança possui rollback e preserva receipts históricos.
9. Métricas honestas. Promoção exige comparação antes/depois.
10. Sem crescimento infinito. Budget, dedup, complexity ceiling e pruning obrigatório.

Quando propor nova etapa

Somente quando houver evidência de que um boundary independente é necessário, por exemplo:

• uma responsabilidade aparece em múltiplas etapas e fica sem owner;
• falha recorrente só é detectada tarde;
• um gate precisa ocorrer antes de mutações específicas;
• há input/output/receipt próprio e condição objetiva de sucesso;
• isolamento ou autoridade diferente é obrigatório;
• o estágio existente ficou amplo demais e viola separação de responsabilidades;
• existe subfluxo recorrente que não pode ser representado por activation condition simples.

A proposta deve justificar por que hook, policy, check, capability ou ajuste de stage existente não resolve.

Quando propor novo agente/papel

Novo AgentRole exige:

• missão única e boundary claro;
• capabilities mínimas;
• ferramentas permitidas/proibidas;
• context pack mínimo;
• input/output schemas;
• receipt e completion condition;
• independência exigida;
• modelo/runtime requirements;
• custo estimado e fallback;
• condição objetiva de ativação;
• relação com papéis existentes;
• prova de que não é apenas renomear ou duplicar outro agent.

Exemplos possíveis, apenas quando evidenciados: migration specialist, database reviewer, accessibility verifier, performance profiler, dependency/supply-chain auditor, release/package verifier, domain-specific compliance agent.

Tipos de alteração do fluxo

Criar taxonomy simplicio.topology-change/v1:

• add_stage;
• remove_stage;
• split_stage;
• merge_stages;
• reorder_dependency;
• change_activation;
• add_role;
• change_role_capabilities;
• change_isolation;
• add_gate;
• strengthen_gate;
• weaken_gate;
• change_retry_timeout;
• change_capacity_wave;
• add_adapter;
• add_receipt;
• add_subflow;
• deprecate_component.

Cada alteração declara risco: low | medium | high | critical.

Contrato da proposta arquitetural

A issue/RFC criada deve conter:

• proposal ID/fingerprint;
• observações e runs de origem;
• gap da topologia atual;
• evidências, frequência e baseline;
• arquitetura atual e proposta;
• diff semântico do DAG;
• stages/roles/gates afetados;
• capabilities e ferramentas;
• schemas e receipts;
• autoridade e isolamento;
• impacto em segurança, custo, tokens, latência e slots;
• compatibilidade com runtimes e modos;
• alternativas consideradas;
• plano passo a passo;
• migração e coexistência;
• canário, rollback e kill switch;
• métricas de promoção;
• testes e critérios de aceite;
• owner, priority e approval class.

Analisador de necessidade

Implementar sinais mensuráveis:

• mesmo finding recorrente em N runs/stages;
• handoffs/retries acima do threshold;
• stage com múltiplas responsabilidades ou outputs não relacionados;
• receipt frequentemente inválido/incompleto;
• gate tardio causando retrabalho;
• reviewer especializado necessário em determinado domínio;
• fila/slots ociosos ou saturados por desenho inadequado;
• custo/latência sem contribuição à detecção;
• falhas escapando até watcher/final audit;
• ferramenta/capability nova que exige boundary próprio;
• projeto com características não cobertas pelo fluxo atual.

Cada sinal gera topology_gap_observed, nunca uma mutação direta.

Validação e simulação

Antes da implementação:

1. validar schema e referências;
2. detectar ciclos, stages órfãos e dependências impossíveis;
3. provar que gates obrigatórios não foram pulados;
4. calcular critical path, slots, waves e custo;
5. simular success/failure/retry/cancel/recovery;
6. verificar independência e separation of duties;
7. comparar cobertura de findings/ACs;
8. executar shadow run sem autoridade de mutação;
9. executar replay de runs históricos;
10. produzir report antes/depois.

Política de aprovação

• Low: ajuste de timeout/retry/activation dentro de limites aprovados; pode seguir política automatizada com receipt.
• Medium: novo stage opcional ou papel sem mutação; exige review arquitetural independente.
• High: novo agent com ferramentas de mutação, mudança de dependências, isolamento ou delivery; exige aprovação humana/repo owner.
• Critical: enfraquecer/remover safety, review, audit, auth ou recovery; exige aprovação explícita múltipla e nunca é auto-promovido.

Prompt, issue externa ou agent filho não podem mudar essa classificação.

Versionamento e execução

• manifestos imutáveis e content-addressed;
• SemVer para contratos/topologia;
• run fixa manifest_version + manifest_hash no intake;
• proposal gera candidate manifest em branch/PR;
• canário selecionado por policy, não aleatoriamente sem registro;
• runs em andamento não migram no meio;
• receipts registram topologia usada;
• rollback aponta novos runs para versão anterior;
• histórico permanece legível;
• mudança incompatível exige migration guide e deprecation window.

Controle de complexidade

Definir budgets configuráveis:

• máximo de stages ativos por task;
• máximo de roles distintos;
• máximo de children/slots por wave;
• máximo de propostas por run/período;
• custo/token/latency ceiling;
• profundidade máxima de subflows;
• TTL de stages experimentais;
• revisão periódica de agents/stages sem valor medido.

O coordenador também deve abrir propostas de remoção/fusão quando componentes não melhorarem métricas.

Integração com reports e issues

Cada stage report e o Evolution Ledger de #467 devem mostrar:

• topology gaps observados;
• proposals/RFCs criadas ou vinculadas;
• candidate manifest/version;
• simulation status;
• approvals pendentes;
• canary metrics;
• promotion/rollback state;
• impacto na execução atual.

A task atual não recebe automaticamente a nova topologia. Ela mantém o manifest hash original, exceto recovery explicitamente aprovado.

Plano de implementação

1. Criar schema/state machine de topology gap e topology change.
2. Implementar collector de sinais estruturais em todos os stages.
3. Implementar semantic DAG differ.
4. Implementar proposal/RFC renderer profundo.
5. Integrar dedup, owner routing e outbox de [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466/[P1][Continuous Evolution] Coordenador deve descobrir, priorizar e abrir issues de evolução e melhoria #467.
6. Implementar static validator e policy engine.
7. Implementar simulator de DAG/capacidade/custo/falhas.
8. Implementar replay de receipts/runs históricos.
9. Implementar shadow-run sem mutation authority.
10. Implementar approval matrix e separation of duties.
11. Implementar candidate manifest versioning.
12. Implementar canary selector, metrics comparator e kill switch.
13. Implementar promote/rollback transacional.
14. Implementar complexity budgets e pruning/deprecation.
15. Expor CLI:

• workflow gaps list|report --json;
• workflow propose --json;
• workflow diff|validate|simulate|shadow --json;
• workflow canary|promote|rollback --json;
• workflow doctor --json.

16. Atualizar SKILL.md, contracts, docs, bundle/plugin/wheel.
17. Criar conformance matrix multi-runtime/multi-project.
18. Publicar reports reproduzíveis antes/depois.

Testes obrigatórios

Unitários

• taxonomy e risk classification;
• role/stage distinction;
• DAG diff;
• cycle/orphan/missing gate;
• capability/isolation validation;
• budget enforcement;
• version/hash pinning;
• approval matrix;
• metric comparator;
• rollback selection.

Integração

• propor novo stage a partir de finding recorrente;
• propor novo agent especializado;
• ajustar activation/retry sem criar stage;
• dedup de propostas equivalentes;
• candidate manifest por branch/PR;
• run antigo permanece pinned;
• shadow run não consegue mutar;
• canário promove e reverte;
• falta de approval bloqueia;
• adapter/runtime incompatível impede promoção.

Sistema/E2E

• adicionar stage opcional;
• adicionar papel independente;
• split/merge de stages;
• reordenar dependência;
• tentar remover safety/review;
• regressão detectada no canário dispara kill switch;
• restart durante promoção/rollback;
• múltiplos coordinators propondo a mesma mudança;
• multi-repo com owner correto;
• source/plugin/bundle/wheel parity.

Segurança/adversarial

• prompt injection solicita agent com acesso irrestrito;
• proposta tenta herdar secrets;
• child tenta aprovar sua própria criação;
• manifest alterado após approval;
• receipt de outra topology version;
• bypass de critical approval;
• DAG aparentemente válido que pula gate por activation;
• issue/RFC maliciosa tratada como untrusted.

Performance

• comparação de critical path;
• custo e tokens por topologia;
• slot pressure e wave scheduling;
• 10.000 runs históricos no replay;
• complexidade do graph dentro do limite;
• ausência de regressão relevante no coordinator.

Critérios de aceite

• Coordenador detecta gaps estruturais sem alterar o fluxo diretamente.
• Pode abrir RFCs/issues para nova etapa, novo agente, novo gate, adapter, receipt ou ajuste amplo de fluxo.
• Toda proposta possui evidência, alternativas, DAG diff, plano, testes, critérios, canário e rollback.
• Novo agent possui boundary, capabilities, tools, schemas, isolamento, custo e fallback explícitos.
• Novo stage prova que ajuste em stage/hook/policy existente é insuficiente.
• Static validation rejeita ciclos, órfãos, gates ausentes e activation bypass.
• Shadow/replay/canary executam antes da promoção conforme risco.
• Runs ficam pinned ao manifest hash inicial.
• Mudanças high/critical exigem autoridade independente/humana.
• Coordenador ou agent proponente não aprova sua própria mudança.
• Nenhuma proposta enfraquece safety/review/audit silenciosamente.
• Budgets impedem explosão de agents, stages, tokens, custo e backlog.
• O sistema também propõe fusão/remoção quando não há valor medido.
• Promoção e rollback são transacionais, observáveis e recuperáveis.
• Reports exibem gap, RFC, candidate, approvals, canário e estado final.
• Dedup impede RFCs/issues repetidas entre agents/runs.
• Testes unitários, integração, sistema, segurança, recovery e performance passam.
• Cada critério aponta para receipt, teste, issue, PR ou report reproduzível.

Definition of Done

Em sandbox, injetar sinais que justifiquem: um novo stage, um novo agent, um ajuste simples de activation e uma tentativa de enfraquecer safety. O coordinator deve criar/deduplicar RFCs profundas; validar e simular o DAG; executar shadow/replay; exigir approvals corretas; promover apenas o canário seguro; reverter regressão; manter runs antigos pinned; e bloquear a tentativa crítica sem autorização.

Relações

• Complementa: [P1][Continuous Evolution] Coordenador deve descobrir, priorizar e abrir issues de evolução e melhoria #467
• Reutiliza findings/issues/outbox: [P0][Continuous Findings] Reports em todas as etapas e issue obrigatória para todo problema encontrado #466
• Estende stage agent manifest/coordinator: [EPIC][P0][Portable Stage Agents] Materializar agentes concretos em cada etapa do simplicio-loop em qualquer runtime #422–[P0][Stage Agents][Driver] Criar coordinator portátil e adapters para materializar agentes em qualquer runtime #424
• Reutiliza reporting: [P0][Stage Agents][GitHub Reporting] Reportar cada item, agente e transição do fluxo por comentários idempotentes #433

[wesleysimplicio]

Implementado via PR #471