- featureTable.ts: areas, per-feature flags, core flags, modes as presets; sparse storage, ownership (an area that is off turns off what it owns), mode switching that keeps or drops manual changes, table validation
- featureModules.ts: createFeatureRegistry (flag + surface gating, scoped context, palette commands under the area with a budget of 5, settings dialog, probes, hotfix selector overrides and kill flags)
- settingsForm.ts: a settings schema normalizes stored values and draws the controls from the UI kit
- domHub observeSelector; api.observe goes through the shared hub (a root of the caller's own keeps its observer)
- createFeatureFlags: a delivery is the whole state (a flag it does not name is at its default), resolve() for ownership, current()
What every app's page runtime entry did by hand (moved from wayBetter for X's inject/entry.tsx):
- siteRuntime.ts: pageInvoke (the IPC bridge read at call time), createFeatureFlags (parts that
install on enable and dispose on disable, the flags native code delivers, a deck column's
overrides on top of them, recorded at once and applied when <html> exists) and
installSiteRuntime (the runtime object with the members native code calls, the plugin API views,
developer-mode errors, its window names, the queued native deliveries, the command report).
- pageStrings.ts: the page's language (English built in, deliveries checked as data, the
bundled-plugin namespace rule).
- panelButton.ts: the way into the panel from the page (the site's own navigation entry when the
adapter mounts one, else a floating button that hides under the site's overlays and sits above
its bottom bar).
- commandReport.ts: the palette command report and developer-mode start errors.
- tests/siteRuntime.test.ts.
