The add-on catalog as the server fetched it on the phone's behalf (MICA-237), every
entry already checked with isCatalogEntry (a malformed row is dropped and logged).
The phone never asks the catalog's host itself, so the host sees the server and not
the player. off: the operator disabled remote add-ons. unavailable: the server
could not fetch a catalog, or the reply was not one — list bundled add-ons only.
What the player granted an add-on, or undefined if they were never asked.
Record the permission set a player just accepted for an add-on (MICA-201).
The shell's own consent record, written here and nowhere else. The Store calls it after the player answers — an install, or an update whose list grew — and the host refuses any permission a manifest declares without a matching grant, so an installed manifest is no longer its own authorization.
Re-check the configured catalog. Safe with none configured: the list empties.
Install the catalog's copy of a pending update, through the ordinary verified install path.
OS Service Hook for installing, removing, or updating an app (MICA-127).
registerApp(manifest, component)is the in-process path — core apps, and (dev-only) runtime fixtures.registerAddOn(manifest, source?)is everything else: an add-on's bundle is source text, run in a sandboxed iframe, never a component the shell executes itself (MICA-16 step 4). A caller inside a sandboxed add-on gets a twin where every member — includingregisterAddOn— throws, andIframeHostServer'sMEMBER_ALLOWLISTrefuses a rawpostMessagenaming this facet's members too: only a core app installs or removes apps, regardless of whether an add-on's manifest declaresapp-registry-write.Installing an app the server owner has disabled (MICA-234) is refused, through
registerAddOnandinstallFromCatalogalike, so the Store cannot put one back.