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 da agenda 011.

O Que Precisa Ser Definido

Surface minima do servico. Fechar operacoes como:
- new(seed) -> rng_ref;
- next(rng_ref) -> int;
- destroy(rng_ref).
Determinismo e replay. Definir:
- seed explicita obrigatoria;
- regra de reproducao frame a frame;
- comportamento esperado em replay.
Lifecycle e validade. Definir:
- como lidar com rng_ref invalido/stale;
- relacao com GC;
- destruicao explicita vs cleanup por GC.
Fault/status do dominio. Definir:
- quais erros sao status;
- quais casos viram Trap;
- inexistencia de Panic operacional.
Metadados e versionamento. Definir IDs/version das operacoes de random para garantir mapeamento 1:1 FE/backend/runtime.

Open Questions de Arquitetura

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

Dependencias

011-vm-owned-stateful-core.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.

1.9 KiB Raw Blame History