# Agenda - VM-Owned Random Service

## Problema

Precisamos de random como primeiro consumidor stateful VM-owned, mas sem fechar um contrato minimo o dominio pode nascer incoerente e nao deterministico.

## Alvo da Discussao

Fechar o perfil minimo de random VM-owned em cima do core definido na decisao `006`.

## O Que Precisa Ser Definido

1. Surface minima do servico.
   Fechar operacoes como:
   - `new(seed) -> rng_ref`;
   - `next(rng_ref) -> int`;
   - `destroy(rng_ref)`.

2. Determinismo e replay.
   Definir:
   - seed explicita obrigatoria;
   - regra de reproducao frame a frame;
   - comportamento esperado em replay.

3. Lifecycle e validade.
   Definir:
   - como lidar com `rng_ref` invalido/stale;
   - relacao com GC;
   - destruicao explicita vs cleanup por GC.

4. Fault/status do dominio.
   Definir:
   - quais erros sao `status`;
   - quais casos viram `Trap`;
   - inexistencia de `Panic` operacional.

5. Metadados e versionamento.
   Definir IDs/version das operacoes de random para garantir mapeamento 1:1 FE/backend/runtime.

## Open Questions de Arquitetura

1. v1 aceita apenas modo deterministico por seed ou tambem entropy host?
2. `next` retorna apenas `int` ou precisamos variantes (`u32`, `float`) no mesmo ciclo?
3. precisamos de clone/split de gerador no MVP?
4. destruicao explicita deve ser obrigatoria para certificacao/custo ou opcional?

## Dependencias

- `../decisions/006-vm-owned-stateful-core-contract.md`
- `../virtual-machine/ISA_CORE.md`
- `../specs/16-host-abi-and-syscalls.md`
- `../specs/16a-syscall-policies.md`

## Fora de Escopo

- entropy nao deterministica como contrato base;
- PRNGs multiplos no mesmo ciclo de fechamento;
- APIs de colecoes stateful;
- window/app model.

## Criterio de Saida Desta Agenda

Pode virar PR quando houver decisao escrita sobre:

- surface minima de random VM-owned;
- contrato de determinismo/replay;
- fault/status de random;
- IDs/versionamento e validacoes de verifier para as operacoes do dominio.