Scheme at structure cadence, not render cadence
Source/status: Current decision. Source:
harness/docs/decisions/scheme-at-structure-cadence.md.
Scheme at structure cadence, not render cadence
Section titled “Scheme at structure cadence, not render cadence”Decision
Section titled “Decision”Scheme does not run on the hot paint/frame path. Layout structure evaluates at structure cadence in the tui worker; content updates ride MobX boxes. The UI thread admits only code with a real visual-performance reason.
Scheme-in-the-render-path is rejected because arrival’s eval is async-only, the membrane freezes borrowed host objects on first read (incompatible with MobX instrumentation), and cooperative yields do not fit an 8–16ms frame budget.
As shipped: layout structure is TS @computed LayoutNode trees in the tui worker
(../packages/harness/src/tui/tea.ts #root / #transcript / #composer;
row constructors in ../packages/harness/src/tui/work-cells.ts). Structure
vs content split and MobX computed/reaction for structure/content/composer are real.
Arrival-scheme layout macros and scheme-bodied layout programs remain the intended seat
once bound — not a requirement for paint correctness today. Boxes are host-minted
(quickdraw BoxRegistry); scheme/layout handles structure references, not mutable host
object graphs.
Rationale
Section titled “Rationale”Arrival is built for correctness-and-attribution (async suspension, freeze, cooperative yield, provenance). Those properties make it a trustworthy policy language and a bad hot-render language. Structure changes rarely and can absorb async; content needs synchronous dependency tracking — MobX’s job.