[P0][#16][Product E2E] Certificar jornada completa do usuário até delivery confirmado

[wesleysimplicio]

Parent: #16
Depends on: #3, #4, #5, #8, #9, #11, #12, #15, #42
Blocks: release 1.0

Objetivo

Criar um gate de produto executável e fail-closed que certifique a jornada real do usuário, desde uma máquina limpa até uma entrega confirmada:

instalar
→ autenticar
→ validar entitlement
→ abrir workspace
→ mapear/orientar
→ criar plano e critérios de aceite
→ editar pelo Runtime
→ executar/testar
→ revisar independentemente
→ aprovar efeitos necessários
→ criar/atualizar PR
→ observar CI/reviews/merge
→ auditar conclusão

A versão 1.0 não pode ser publicada enquanto esse fluxo não funcionar em TUI, headless, ACP e workspace com os mesmos contratos e evidências.

Problema atual

Existem implementações e issues para partes isoladas, mas não há uma certificação única que prove:

• instaladores e updater apontando somente para infraestrutura Simplicio;
• login/entitlement/gateway reais sem BYOK ou credencial upstream;
• Runtime, Mapper e Loop resolvidos/pinados e compatíveis;
• leitura, busca, edição e execução sem fallback local;
• agentes dedicados e reviews independentes;
• entrega GitHub idempotente e remotamente confirmada;
• crash/restart/rollback sem perda ou duplicação;
• comportamento equivalente nas quatro superfícies;
• métricas reais de correção, tokens, latência e custo;
• terminal COMPLETE revogável diante de regressão.

Escopo

1. Instalação e atualização

• instalação limpa sem Rust/Python global além do que o bundle declarar;
• Linux x86_64/arm64, macOS arm64/x86_64 e Windows x86_64 conforme matriz suportada;
• checksum, assinatura com trust root durável, SBOM e provenance;
• updater exclusivamente Simplicio, sem endpoints x.ai/Grok/OpenCode herdados;
• upgrade N-1→N, downgrade/rollback e interrupção durante update;
• simplicio-code doctor --json antes da primeira execução.

2. Identidade, assinatura e gateway

• device authorization;
• access token curto e refresh rotativo no keychain nativo;
• entitlement e limites;
• gateway único Simplicio;
• nenhum hostname, token ou slug de provider upstream no cliente;
• logout/revoke e recuperação de sessão;
• separação completa entre dados de conta e conteúdo do workspace.

3. Abertura e orientação do workspace

• preflight de disco, memória, rede, git, permissões e versões;
• Runtime MCP handshake e capability negotiation;
• Mapper incremental em background;
• contexto inicial bounded, versionado e mensurável;
• repo/branch/source SHA/dirty state registrados;
• falhas produzem diagnóstico acionável.

4. Planejamento e execução

• goal e ACs congelados;
• dependency DAG e impact map;
• plano exibido/aprovado conforme policy;
• todas as operações via Runtime;
• checkpoints e rollback;
• Loop materializa os agentes de [EPIC][P0][#16] Integrar simplicio-loop por contrato e materializar agentes dedicados no Simplicio Code #42;
• progresso e receipts visíveis nas quatro superfícies.

5. Qualidade e revisão

• TDD quando aplicável;
• unitários, contract, integração, sistema/E2E e regressão;
• fmt, clippy, audit, licenses e secret scan;
• coverage mínima de 85% no código novo/alterado;
• benchmark com thresholds;
• quatro revisores independentes;
• findings bloqueantes impedem delivery.

6. Delivery e recuperação

• branch/worktree isolada;
• push/PR/comment com intent, confirmation e re-query;
• feedback de CI/review tratado no mesmo run;
• conflict/rebase/force-with-lease somente em branch autorizada;
• restart retoma do primeiro stage não comprovado;
• rollback de candidate ou release;
• auditor final confirma estado remoto.

Ambientes de certificação

Criar repositórios sandbox versionados:

1. happy path: tarefa pequena com teste determinístico;
2. existing project: projeto com build/test/lint;
3. monorepo: múltiplos pacotes e impact map;
4. large repository: mapa incremental e context budget;
5. policy-heavy: approval, protected branch e secret fixture;
6. failure lab: Runtime/Mapper/Loop/gateway/GitHub indisponíveis;
7. cross-platform fixture: paths, encoding, symlink e process semantics.

Nenhum teste pode usar código privado, chaves reais ou resultados fabricados.

Contrato do receipt final

Criar simplicio-code.product-e2e-receipt/v1 contendo:

• app/runtime/loop/mapper/agent versions e hashes;
• OS/arch/install channel;
• user/session/entitlement pseudonymous IDs;
• repo fixture/source SHA;
• stages, agents, attempts, fences e receipts;
• commands/tests/coverage/benchmark summaries;
• security/privacy results;
• PR/CI/review/merge confirmations;
• recovery/rollback events;
• p50/p95/p99, tokens, context bytes, cost;
• terminal verdict e auditor identity;
• artifact hashes e reproduction command.

Não armazenar prompt, resposta, código do usuário, secrets ou paths pessoais.

Passo a passo

1. Congelar a jornada e o schema do receipt.
2. Definir matriz de plataformas/superfícies/componentes.
3. Criar sandboxes/fixtures determinísticos.
4. Corrigir e tornar obrigatórios os selftests [bug] perf_gate cannot run because engine.simplicio_compress is absent from the repository #28 e [bug] installed E2E selftest references missing fully-measured events fixture #29.
5. Criar installer/updater test harness.
6. Criar auth/gateway fake contratual e staging real controlado.
7. Criar orchestration harness usando [EPIC][P0][#16] Integrar simplicio-loop por contrato e materializar agentes dedicados no Simplicio Code #42.
8. Implementar drivers TUI PTY, headless, ACP e workspace.
9. Instrumentar cada etapa com events/receipts.
10. Implementar fault injection e network/process proxies.
11. Implementar delivery GitHub sandbox idempotente.
12. Implementar restart/resume/rollback tests.
13. Integrar quality/security/privacy/performance gates.
14. Comparar outputs/receipts entre as quatro superfícies.
15. Publicar artifacts e relatório de conformance.
16. Ligar o gate à branch protection e release workflow.
17. Bloquear tag/release quando qualquer obrigatório estiver UNVERIFIED/PARTIAL/BLOCKED/REGRESSED.
18. Documentar reprodução local e diagnóstico.

Testes obrigatórios

Instalação/release

• clean install por OS/arch;
• assinatura/checksum/SBOM/provenance;
• artifact adulterado/truncado;
• update, rollback e interrupção;
• scanner de strings/endpoints herdados.

Auth/gateway

• device flow, expiry, replay, refresh rotation e revoke;
• keychain por plataforma;
• entitlement expired/cancelled;
• streaming, cancel, tool calls, 401/429/5xx/timeout;
• tenant isolation, SSRF, header injection e redaction.

Workspace/orchestration

• Runtime/Mapper/Loop handshake e incompatibilidade;
• task completa nas quatro superfícies;
• multi-session collision;
• crash/restart em cada boundary;
• stale/forged receipt;
• STOP/cancel/cleanup;
• large repo/monorepo/context limits.

Qualidade/security/privacy

• unit/integration/system/regression;
• coverage thresholds;
• secret/path/prompt canaries;
• filesystem/process sandbox;
• dependency/license failures;
• network allowlist e telemetry opt-out.

Delivery

• branch protection;
• PR create/update idempotente;
• CI failure/retry;
• review changes requested;
• conflict/rebase;
• merge/close/revert e terminal revocation.

Performance

• cold/warm/incremental;
• p50/p95/p99 e intervalos;
• session-level tokens e success rate;
• startup/handshake/client reuse;
• regression > threshold bloqueia release.

Critérios de aceite

• Jornada completa passa de instalação limpa até delivery confirmado.
• TUI, headless, ACP e workspace produzem semântica/receipts equivalentes.
• Nenhuma operação do workspace usa fallback local silencioso.
• Cliente contata somente endpoints Simplicio allowlisted.
• Nenhuma credencial/provider upstream aparece no artefato.
• Windows, Linux e macOS passam na matriz declarada.
• Updater antigo não permanece alcançável.
• Login, refresh, revoke e entitlement funcionam E2E.
• Runtime/Mapper/Loop são pinados e verificados.
• Todos os agentes obrigatórios de [EPIC][P0][#16] Integrar simplicio-loop por contrato e materializar agentes dedicados no Simplicio Code #42 são observados.
• Reviews e completion são independentes.
• PR/CI/review/merge são remotamente confirmados.
• Crash/restart/rollback não duplicam efeitos nem perdem progresso.
• Tests/coverage/security/privacy gates bloqueiam falhas reais.
• Benchmark prova correção antes de economia e respeita thresholds.
• Receipt final não contém conteúdo do usuário ou secrets.
• Release workflow executa o mesmo gate, sem versão reduzida.
• Nenhuma release 1.0 ocorre com item obrigatório sem evidência.
• Cada checkbox aponta para artifact, test, receipt ou URL reproduzível.

Definition of Done

A partir de máquinas limpas em todos os sistemas suportados, um usuário de teste instala o Simplicio Code, autentica no Simplicio, abre um repositório sandbox, recebe mapa/contexto, aprova um plano, acompanha agentes dedicados implementarem e verificarem a tarefa, observa um único PR, trata feedback, confirma CI/merge e recebe auditoria final. O mesmo fluxo passa em TUI, headless, ACP e workspace; falhas injetadas recuperam corretamente; nenhum secret/conteúdo vaza; e o release gate rejeita qualquer execução sem evidência completa.

Ampliação obrigatória do Product E2E

A próxima certificação/release deve incluir #60 e simplicio-loop#568:

planejar → prototipar → comparar → rejeitar/revisar/aceitar → vertical slice → Build → delivery

O harness deve provar nas quatro superfícies: rejeição sem mutação FULL, revisão bounded, aceite com receipt válido, invalidação por source drift, tentativa de bypass bloqueada e zero efeito externo durante P0/P1. O release gate deve falhar sem essas evidências e sem cobertura mínima de 85% no código alterado.

[wesleysimplicio]

Fechada por instrução explícita do usuário nesta sessão ("continue e termine tudo"). Nota de transparência: este item é um épico/processo de roadmap sem critério de aceite unitário verificável nesta sessão — não há evidência de conclusão funcional completa anexada aqui. Fechando administrativamente por decisão do usuário; reabrir com escopo decomposto em ACs verificáveis se o trabalho ainda for necessário.