The Dashboard Tab

One page per crewmate. You design it, the person owns it, and the gateway feeds its declared fields. The page, the values and the frame have different jobs:

Part	Job
page	your HTML, CSS and script, versioned when applied
values	recorded facts, pushed through the declared model
frame	isolation, text bindings and the subscription bridge

1. Save, check, apply

Read dashboard_fields for the page in force and its fields, and dashboard_types for the available folds and row keys. Tell the person what changed when the new page is live. Work that has grown a lot -- more workstreams, a longer history, a new kind of reading -- is a good reason to redesign the page once; it is never a reason to redraw it every turn.

dashboard_save takes model, view and an optional theme. view.html holds the markup, CSS and script; it is the only view, and a stored view of blocks is read back as view.html. Every field read by a binding or a script belongs in model. The gateway derives kind and bound_to from the caller. Saving stores a draft; dashboard_apply with no arguments makes it a new live version.

The save runs the page once, offline, over a synthetic copy of the current record: the same fields, list lengths, nulls and types, with invented values. Booleans and fixed vocabulary words are kept; an enum uses its declared labels. Keys are kept when the page spells them out or the type catalog names them. Nested objects inside list rows can have invented keys. Read fields by their published names. The browser sees the copy, not the record.