IDEA PIN (T8) — DESIGN-GATED (2026-07-05 sweep): `! ?persist`
Code
// ASPIRATION — TODO idea pin. T8 statically-resolved DI: `! ?persist` is
// an optional resume arm on the store's contract (optional arms ruled
// 2026-07-03 @7c37406a). Installed => the write-subflow calls it per
// write (sole-write-path boundary keeps deltas coherent); not installed
// => `if(persist) | else` resolves at comptime and the arm costs nothing.
// Void side-effecting arm per the ORM-showcase grounding; the install
// SURFACE (arms on watch? on link?) is PROVISIONAL.
~import std/io
~import std/store
~std/store:new(game) { hp: 0[i64] }
! ?persist i64
~std/store:watch(game)
! persist v |> std/io:print.ln("persist {{ v:d }}")
~std/store:stored { game.hp: 4 }
~std/store:stored { game.hp: 6 }
Expected output
persist 4
persist 6
Flows
Test Configuration
Awaiting ruling:
T8 firing granularity: does an installed `! ?persist` arm fire per write, or once per batch — and may its handler hold a live connection? Two questions, one pin, because the store-side semantics need both answered before the surface can be written. The optional-arm machinery already exists (400_144, arms ruled 2026-07-03 @7c37406a); what is open is what the store does with it. - Granularity: per-write keeps deltas coherent at the sole-write-path boundary; batch is what a fused apply wants (see 690_019, which asks the sibling of this question for watches). - Connection purity: a handler holding a live connection collides with transplant purity — the ORM-showcase collision. Unresolved. Also provisional, and not the ruling itself: the install SURFACE (arms on `watch`? on `link`?). Do not invent it in a test. Blocks: this pin, and every DI story downstream of it. Marked DESIGN-GATED in the 2026-07-05 sweep and still parked — it is not machinery-cheap, it needs the walk.