SectionState

One admin section's state, read the way any surface reads it — by MOUNTING what the section declared. `decisions/0220` says the panel is one and has surfaces. This is the whole cost of the second one: a section declares its component once, for the panel, and the terminal mounts that same declaration and reads the state it returns. Nothing is declared twice, no section knows a terminal exists, and no renderer is involved — the state IS the picture, and `milpa/live-tui`'s `StateToNode` turns any state array into a node tree. ── TOTAL OVER THE THREE SHAPES A SECTION CAN HAVE ────────────────────────────────────────────────── A section brings a `$definition`; or a whole `$view` of them (greenhouse decisions/0211), whose state is each component's under its own name; or it merely NAMES a component the panel registers, which is resolved from the registry the panel composes with. A shape nothing can mount says so in its own state rather than disappearing: a section missing from the dashboard reads as a section that does not exist, which is the one thing worse than a section that says what is wrong with it. Mounting is LAZY and repeated: `state()` is called once per frame, so what the terminal shows is what the app is now — a dashboard that froze what it read when it opened is a screenshot.

public function __construct(Milpa\Admin\Section\AdminSection $section, ?Milpa\Live\Contracts\Component\ComponentRegistryInterface $components, string $route, ?string $unavailable = null):

Parameters

public function state(): array

The section's state right now — mounted on the spot, never remembered.