Installing and managing apps: deployment adoption, the us-apps record, launcher and lifecycle

[lannbot]

Tracking issue for the "Installing and managing apps" NOTES.md section (recorded 2026-08-26). The direction: install = adopting a deployment — packaging, verification, transparency, and delivery are delegated to polymorph-pkg (deployment manifests signed by a curator key, verified fetch by digest over untrusted mirrors, the trust-compiles rule); polyvisor owns the ceremony, the replicated install record, the launcher/lifecycle UX, and the contact-graph detection layer. The user's one judgment act is the install ceremony (grants + petname/mark); everything downstream is pure mechanism — no "continue anyway?" ever.

Settled directions (see the NOTES section for rationale):

• The home origin stays app-agnostic beyond the release-carried core set (no operator catalogs; the origin never learns the install set).
• The core set ships inside the framework's own deployment; split trigger: the first core app needing off-cycle updates or uninstallability.
• Updates: silent adoption — manifest freshness is revocation; the visor announces, never asks. Curator-root generation changes are announcement-grade.
• The us-apps record is replicated account state (sibling to User-system partition: device-group state sync (profile, trust records, contacts, devices) #36), including seq/generation rollback floors — devices inherit floors from siblings instead of re-TOFUing after eviction.
• Uninstall revokes grants and drops bytes; partition data outlives the app (keep / rebind / erase, the last erase-ceremony-grade).
• Bucket-as-mirror deferred with a guard (the dumb-store contract already satisfies the mirror model; nothing may preclude it).

Open sub-questions:

• The polyvisor app statement (extends the deployment manifest by reference, never by fields): requested capabilities/destinations (Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7's manifest), service dependencies, partition declarations, UI entry points. Schema and signing story.
• Mark nomination source: today a mount-time read; under installs it could ride the app statement (install-time, before any code runs) — same isAppMarkIcon firewall, different arrival.
• Install ceremony UX: tier-graded arming (pure-local light; data+egress compound heavy); drawer sheet composition; how the grant sheet renders manifest-derived strings (app voice until named).
• Launcher composition: page vs drawer; relationship to the storage picker's two voice-marked lists; glyph-vocabulary scale pressure (28 app glyphs meet many installs — collision repair becomes routine).
• Back-chevron stack: launcher → management page → ceremony is the second nesting level the null-or-one setBack ruling parked on.
• Uninstall / orphaned-partition semantics: the two ceremony weights; what an orphaned partition looks like in the visor; rebind to a different app.
• CSP contract change (Home origin contract: required headers, MIME, service-worker scope - and an origin conformance checker #2): third-party manifest/mirror fetches want broad connect-src on the visor/worker paths; rule it in the header contract rather than discover it. App frames stay at zero network regardless.
• Manifest-poll metadata (Threat model: the adversary table and the "nothing is both live and trusted" invariant #1): each installed app's mutable-fetch endpoint learns IP, install status, and usage cadence per curator host. Within the metadata non-goal — record the stance explicitly.
• Version skew × System services: schema-authority data services, computed capability profiles, the egress-reachability badge #21: devices adopting manifests at different times write one partition; schema-authority services carry the write-new-read-both window; the synced floors bound the skew. Needs the System services: schema-authority data services, computed capability profiles, the egress-reachability badge #21 migration memo to close.
• Kill honesty depends on App guests run in workers: per-app blast zone, preemptive kill #45: launcher suspend/kill affordances are honest only once apps run in workers.
• Per-app budgets as install-visible governance: doc-count (the subduction ~2,400-doc wall multiplies with app count), storage attribution, push/wake-tag budgets, the egress audit surface.

Parked with triggers: multi-window (own design pass), app-to-app intents (powerbox pickers cover the near term; trigger: a real consumer), background app execution (trigger: an app that genuinely needs liveness — #12 territory), discovery (web-of-trust shaped, never adjacent-equal to installed lists — the picker ruling's discovery clause applies unchanged).

Related: #52 (rescoped: the publishing/transparency half is delegated to polymorph-pkg; polyvisor keeps contact-graph gossip and the visor alarm/response UX), #36 (us-apps as a user-system partition), #7, #21, #45, #2, #1.