# Agenda - Runtime Edge Test Plan

## Problema

O core da VM está muito melhor testado do que a borda do runtime.

O miolo já cobre verificador, scheduler, GC, patching e execução básica. Já a camada de syscalls de sistema, FS, assets, bank e fluxos de firmware ainda tem cobertura desigual e rasa.

## Dor

- A parte mais sujeita a integração com host é justamente a menos protegida.
- Regressões na borda podem passar com o core inteiro verde.
- O projeto ganha falsa sensação de maturidade porque o núcleo está sólido, mas a superfície pública do runtime ainda pode quebrar com facilidade.
- Sem matriz de testes da borda, futuras PRs tendem a cobrir só o happy path.

## Alvo da Discussao

Definir um plano de testes para a borda do runtime proporcional ao risco da plataforma.

Essa agenda deve produzir uma visão clara de:

- quais domínios precisam de testes;
- qual nível de teste pertence a cada domínio;
- quais cenários são mandatórios antes de chamar o runtime de estável.

## O Que Precisa Ser Definido

1. Matriz de cobertura por domínio.
   - system
   - fs
   - log
   - asset
   - bank
   - firmware transitions

2. Tipos de teste.
   - unitário puro
   - integração entre runtime e VM
   - testes de firmware
   - testes host-dependentes isolados

3. Casos obrigatórios.
   Cada domínio precisa definir:
   - happy path;
   - erro de contrato do guest;
   - indisponibilidade/estado inválido do host;
   - persistência/cleanup de estado quando aplicável.

4. Critério de severidade.
   Que mudanças exigem teste novo obrigatório antes de merge.

5. Organização.
   Onde os testes vivem para nao voltar a concentrar tudo em arquivos gigantes.

## O Que Necessita Para Resolver

- inventário da cobertura atual;
- definição dos cenários obrigatórios por domínio;
- política mínima para testes ignorados ou dependentes de host;
- decisão sobre helpers compartilhados para fixtures de runtime.

## Fora de Escopo

- benchmark/performance suite;
- fuzzing completo de toda a ISA;
- infraestrutura externa de CI além do necessário para os testes definidos.

## Critério de Saida Desta Agenda

Pode virar PR quando houver:

- matriz de cobertura aprovada;
- lista de cenários mínimos por domínio;
- decisão de organização dos testes;
- barra clara para aceitar novas syscalls e mudanças de runtime.