Skip to content

[P0][Regression/Audit] Eliminar bypasses restantes do Runtime após o fechamento da #5 #49

Description

@wesleysimplicio

Contexto

Follow-up verificável da issue fechada #5. Relaciona-se a #42 e #43, ao simplicio-agent#222 e ao simplicio-runtime#3030.

A documentação arquitetural atual do repositório ainda registra explicitamente que:

  • os contratos tipados Runtime para list, stat, edit e exec existem no cliente, mas ainda não possuem consumidores reais no agente;
  • grep, hashline_grep e list_dir ainda possuem caminhos diretos por ripgrep, tokio::fs ou ignore::WalkBuilder;
  • o executor de bash ainda precisa ser ligado ao contrato Runtime de exec;
  • a presença de um contrato ou client method não prova que todas as superfícies o exercitam.

Logo, o aceite original de #5 — “100% dos caminhos de leitura, busca, mutação e execução usam Runtime MCP” — não está demonstrado pelo estado documentado atual. Esta issue não repete o desenho de #5: ela audita o fechamento, conclui o wiring restante e instala um gate que impeça a regressão.

Objetivo

Garantir, com inventário machine-readable, testes arquiteturais e E2E com Runtime real, que toda operação do workspace iniciada por TUI, headless, ACP, workspace ou tools do agente atravesse o boundary governado do Simplicio Runtime, sem fallback local silencioso.

Invariantes

  1. Runtime ausente, incompatível ou sem capability obrigatória bloqueia o efeito com erro tipado.
  2. Nenhum tool pode alternar silenciosamente para filesystem, processo ou busca local após falha do Runtime.
  3. Leitura, busca, listagem, metadata, edição, escrita, exclusão e execução usam os mesmos contratos semânticos nas quatro superfícies.
  4. Operações de bootstrap estritamente necessárias devem estar em allowlist curta, justificada e não alcançar conteúdo do workspace.
  5. Retry/fallback nunca repete efeito com outcome desconhecido.
  6. Receipts registram coordinator, session, turn, tool call, workspace, capability, policy revision e outcome sem conteúdo sensível.

Plano passo a passo

  1. Criar um inventário workspace-access-manifest/v1 com todos os call sites que acessam arquivos, diretórios, Git, pesquisa textual ou processos.
  2. Classificar cada call site como runtime-governed, bootstrap-allowlisted, test-fixture, generated ou violation.
  3. Congelar um baseline revisado; novas ocorrências sem classificação falham CI.
  4. Ligar list_dir e equivalentes ao contrato Runtime list.
  5. Ligar metadata, tamanho, tipo, existência e permissões ao contrato stat.
  6. Ligar grep, hashline_grep e demais buscas ao SearchBackend, removendo chamadas diretas concorrentes.
  7. Ligar apply/patch/edit ao contrato atômico edit, preservando checkpoint, approval, rollback e receipt.
  8. Ligar terminal/bash/process tools ao contrato exec, usando argv/cwd/env allow-listed, budgets, streaming, cancelamento e kill-tree.
  9. Remover ou encapsular imports/call sites diretos de std::fs, tokio::fs, Command, WalkBuilder e execução de ripgrep nos crates de agente/workspace.
  10. Unificar capability negotiation e taxonomia de erros.
  11. Implementar idempotency keys e estados not_started|denied|completed|effect_unknown para mutações/processos.
  12. Executar shadow comparison durante rollout: caminho antigo somente read-only versus Runtime, sem duplicar efeitos.
  13. Remover o caminho antigo depois da paridade.
  14. Atualizar docs/ARCHITECTURE.md, troubleshooting e capability matrix a partir do manifest gerado.
  15. Fazer [P0][#16][Product E2E] Certificar jornada completa do usuário até delivery confirmado #43 consumir este gate, em vez de confiar apenas no fechamento histórico de feat: mover busca, edição e execução para o Runtime #5.

Testes obrigatórios

Unitários e property-based

  • normalização de paths, globs e cwd;
  • traversal, caminhos absolutos, Unicode e separadores cross-OS;
  • symlink escape e troca concorrente do symlink;
  • capability ausente/incompatível;
  • idempotency e effect_unknown;
  • tradução estável dos erros Runtime.

Integração

  • Runtime real e fixture de protocolo para list/stat/search/read/edit/write/delete/exec;
  • streaming/cancelamento/timeout de processos;
  • arquivo grande, binário, diretório profundo e monorepo;
  • rollback após falha entre write e receipt;
  • conexão quebrada antes/durante/depois de um efeito.

Sistema/E2E

Executar a mesma tarefa em TUI, headless, ACP e workspace:

  1. listar;
  2. localizar símbolo/texto;
  3. ler;
  4. editar atomicamente;
  5. executar teste;
  6. cancelar comando longo;
  7. reiniciar Code/Runtime;
  8. confirmar estado e receipt.

Segurança e regressão

  • command injection, env injection, path traversal e symlink race;
  • Runtime falso ou downgrade de protocolo;
  • teste arquitetural proibindo novos bypasses;
  • secret/content canaries em logs e receipts;
  • cobertura mínima de 90% nos adapters críticos e 85% no código tocado.

Performance

Medir cold/warm p50/p95/p99 e throughput de list/stat/search/edit/exec. O canal governado não pode introduzir regressão superior ao budget aprovado sem ADR e evidência.

Critérios de aceite

  • O manifest cobre 100% dos call sites relevantes e não contém violation.
  • list/stat/edit/exec possuem consumidores produtivos reais.
  • grep/hashline_grep/list_dir/bash não bypassam o Runtime.
  • As quatro superfícies passam pela mesma implementação central.
  • Runtime ausente/incompatível falha fechado sem fallback local.
  • Efeitos desconhecidos nunca são repetidos automaticamente.
  • Testes com Runtime real passam em Linux, macOS e Windows.
  • CI impede a introdução de novos acessos diretos não allow-listed.
  • O E2E de [P0][#16][Product E2E] Certificar jornada completa do usuário até delivery confirmado #43 consome este gate e aponta para receipts reproduzíveis.
  • Documentação deixa de declarar wiring pendente somente após prova executável.

Não objetivos

  • mover UX ou raciocínio para o Runtime;
  • proibir arquivos internos do próprio aplicativo;
  • substituir o protocolo canônico sem ADR;
  • aceitar mocks como prova terminal.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions