Manage apps and the app-settings lane — what landed

The admin half of phase 3 of Apps live on the instance (§6, §7). It builds on the plan in Settings extensions. Everything here is a framework control (DataGrid + PropertyColumnControl, Stack, Title, Markdown, Button, MeshNodePickerControl); nothing writes a grant, creates a Space or copies a package.

Every page is a template (Doc/GUI/DataBinding, "Templates first, data later"): the grids are BindGrid and the lines BindMarkdown, fed by ManageAppsFeeds / InstanceMapsFeeds, which read the mesh and build no control; row buttons act on the clicked row (ctx.RowAs<TRow>()). The admin verdict and the page switch (grid / one app / capabilities) are structure, decided before any read.

The lane: UiContribution context AppSettings

A content module cannot reach another hub's configuration, so it could not add a tab to the Admin app or to another app's settings. Core gained one context for it (MeshWeaver#6445):

Field Meaning
context: AppSettings a tab on ONE app's settings page
host the app's path — Admin for an Administration section, AI/AiThreads for Threads
address + area the area embedded as the tab body; the address must lie in the contribution's own partition (the PersonApp rule)
gates.adminOnly every Administration section carries it; the Store areas refuse a non-admin as well

The tab joins the host's settings page (/{host}/Settings/{node id}) and no other. Seed validation reports a hostless tab and a foreign address; scripts/check-menu-contexts.py knows the context.

Administration (host Admin)

Tab Contribution Body
Manage apps Store/AdminTabs/ManageApps Store area ManageApps
Maps Store/AdminTabs/Maps Store area AdminMaps
Operations packages Store/AdminTabs/Operations Store area AdminOperations
Fleet console Hosting/AdminTabs/FleetConsole Hosting/Console › Content
Build queue Hosting/AdminTabs/BuildQueue Hosting/Console › Builds
Governed activities Governance/AdminTabs/Activities Governance/Activities › Overview

The existing compiled Admin tabs (Registration from HostingInstanceModuleAttribute, Fleet from InstancesAdminLayoutArea) are unchanged.

Manage apps

Maps

App settings (other hosts)

App Tabs Notes
Threads (AI/AiThreads) Models, Harnesses, Web search (AI/AppSettings/*) Models lists the ModelProvider nodes in the viewer's personal provider namespace (ModelProviderNodeType.UserNamespacePath, the one the picker and the credential resolver read; masked key dialog on each); the Setup page's model-provider sell-shelf is removed. Harnesses reuses the harness cards (Get = enable, settings link = /login). Web search states the instance default by the plugin's own rule (Google only with both key and cx; retired Bing never). No plan gates any tab.
Signature (Signature/MySignatures) Providers (Signature/AppSettings/Providers) embeds the existing SigningAuthority area; the signing authority stays in the person's own settings

Tests

Not executed by these suites (follow-up): the Maps Save chain (encrypt → create the Hosting/InstanceAction in the operational space → control-plane target) and the audience WriteAudience chain (admin check → System → owning _Policy hub) need a mesh rig with a layout host, an operational space and a real admin grant; the pure suites pin their shapes, and the live write is the deploy check below.

Deploy

Recycle after the merge and the core seal: Store (the catalog type), AI/AiThreads, Admin. The tabs appear only once the running platform carries MeshWeaver#6445; before that the contributions are inert (no consumer renders the context).