2.9 KiB
2.9 KiB
Decision Record - Filesystem Fault Core Policy
Status
Accepted
Contexto
A agenda 003-filesystem-fault-semantics.md existia para fechar fault semantics de fs depois das discussoes de superficie.
Com o split de fs em:
- decisao
011(gamememcard slots); - agenda
014(apphome sandbox);
ficou claro que:
- existe um nucleo de politica que pode ser decidido agora;
- os detalhes por perfil devem ser fechados no contrato de
gamee no deapp.
Isso permite remover a agenda 003 sem perder rigor.
Decisao
1. Fronteira canonica de falhas para fs
fs segue o modelo de 16a:
Trap: violacao estrutural de contrato ABI/chamada.status: condicao operacional de dominio.Panic: quebra de invariante interno do runtime/host.
2. O que e estrutural (Trap) em fs
No dominio fs, sao estruturais:
- assinatura de chamada invalida (
arg_slots/ret_slots); HeapRefinvalido/dead;- kind de objeto incompativel para a operacao;
- janela de bytes invalida (offset/length fora do buffer VM-owned).
3. O que e operacional (status) em fs
Sao operacionais (nao estruturais):
- recurso ausente (
not found/slot vazio quando aplicavel); - permissao/sandbox negada;
storage full;- indisponibilidade temporaria do backend;
- conflitos/corrupcao detectados no dominio.
4. Integracao obrigatoria com decisao 003
Operacoes de bytes em fs devem usar:
HeapRef<Bytes>VM-owned;- janela explicita (
offset+max_bytes); - retorno com
statusebytes_transferredquando aplicavel.
5. Regra de escrita parcial
write nao pode produzir sucesso parcial silencioso.
Se o dominio nao conseguir concluir a escrita segundo seu contrato de atomicidade:
- retorna
statusde falha; - nao mascara o resultado como sucesso.
6. Responsabilidade por perfil (movida para decisao 011 e agenda 014)
Fica sob responsabilidade das agendas de superficie:
- catalogo final de codigos
statuspor operacao; - matriz completa por operacao (
status/Trap/Panic); - shape final de retorno para cada operacao de cada perfil.
7. Encerramento da agenda 003
A agenda 003-filesystem-fault-semantics.md e considerada absorvida e removida.
Consequencias
Positivas
- elimina uma agenda transversal que atrasava fechamento;
- preserva um nucleo unico de fault policy para todo
fs; - deixa
gameeappfocados nos detalhes reais de produto.
Custos
- exige disciplina para manter a matriz de faults distribuida em duas agendas;
- exige revisao de consistencia entre decisao
011e agenda014antes de PR final de implementacao.
Follow-up Obrigatorio
011-game-memcard-slots-surface-and-semantics.mdfecha a matriz de fault/status do perfilgame;014-app-home-filesystem-surface-and-semantics.mddeve incluir a matriz de fault/status do perfilapp;- specs
16/16adevem absorver esta decisao quando o contrato estiver implementado e estavel.