AdminSection

One section of the admin panel, as a plugin declares it. A section IS a Milpa Component — or a whole VIEW of them. It either names a component the panel already knows (the dashboard primitives — `metric-card`, `data-table`, `dashboard-grid`… — rendered with `$props`), or it brings its own: a `$definition` plus the `$renderer` that paints it, which the panel registers under `$component` before composing; or it brings a `$view` ({@see DeclaredView}) — a tree of components with their definitions, renderers, props and signal seeds, which the panel registers and compiles the same way (greenhouse decisions/0211). Either way the panel never learns the plugin's name — it learns the section's, and that is enough to list it, route it, render it and attribute it: the header of every section says «declared by <Plugin>», read from the catalogue, never from the section. What the panel hands the component: the `ComponentContext` it mounts with carries the section's component id (`milpa-admin-section-<id>`), the `principal` the gate authenticated (the actor's id, or null when nobody is signed in — the same fact the topbar shows), the `locale` the page answers in, the panel's `route` (its mount point) and, in `meta`, the host facts a guest may need without widening any contract: the gate in effect, the active section's id and the request's query ({@see \Milpa\Admin\View\AdminShell::META_GATE}, `META_SECTION`, `META_QUERY`). For the narrow shape the props are `$props` plus the request's query under `query`; a view's props are its own, per component. One prop name is RESERVED: `query`. The shell hands every active section the request's query params under `props['query']` (greenhouse decisions/0205), so a section that declared its own `query` would see it silently replaced on every request — the constructor refuses it instead. The sidebar lists sections by `$group` — one heading per distinct value, `admin` (the panel's own) first, then `app` (the default), then `agent`, then any other name in alphabetical order — and, within a group, by `$order` (lower first; ties break by `$id`, alphabetically). The panel OPENS on the first section in that same (`order`, `id`) order across every group, which is why the convention matters: the panel's own sections take 10..40 (Plugins 10, Routes 20, Settings 25, Stack 30, Dev tools 40), and a guest picks an order AFTER those — greenhouse decisions/0210 names 60 for the Desktop's Agent section — unless it means to be the page the panel opens on. A guest at order 10 named `agent` would tie with Plugins, win the tie by id, and become the front page. What a section may not do: bring its own `$definition` under a name the panel registers itself (a dashboard primitive, `admin-sidebar`, `admin-section-header`) — naming one is fine, redefining one would repaint every section that names it, so the panel refuses the section and says so.

public function __construct(string $id, string $title, string $component = '', array $props = [], int $order = 0, string $group = self::GROUP_APP, ?Milpa\Live\Contracts\Component\ComponentDefinitionInterface $definition = null, ?Milpa\Live\Contracts\Rendering\ComponentRendererInterface $renderer = null, string $icon = '', ?Milpa\Admin\Section\DeclaredView $view = null, string $parent = ''):

Parameters

public static function ofView(string $id, string $title, Milpa\Admin\Section\DeclaredView $view, int $order = 0, string $group = self::GROUP_APP, string $icon = '', string $parent = ''): self

A section that declares a whole {@see DeclaredView} — the shape a plugin brings its own UI in (greenhouse decisions/0211). The same as the constructor with `view:`, said in one line.

Parameters

public function isCustom(): bool

True when the section brings its own component instead of naming a registered one.

public function hasView(): bool

True when the section declares a whole view instead of one component.