Apps live on the instance, not in your home

Maintainer, 2026-10-10:

• "Apps should be globally installed, not under user account. User should see apps depending on his roles and functions (access control). For each user, let's store apps in cache for like 5 min sliding scale."
• "remove stuff from home. only actual user data will be stored in home, but not app"
• "remove install in this sense, it is not robust"
• "plan well and migrate across the fleet. see we don't have a gazillion apps appearing. what is settings tabs should be in settings apps, what is examples should be in examples app. make nice app design."
• "user data can still be installed. courses, when we start them."
• On the design (mockups linked from the pull request): "app screen, like it, make search (filter) bigger. personal: like design. we should offer the connect to mail / calendar, home entertainment, ... in setup phase. not just google, but any email, linkedin, ..." and "maps => this must go to instance admin app. in user examples, we should see examples how to use them."

Status: plan, phase 0. This page is the design of record for the migration. It builds on Settings extensions (plans only, Manage apps, three settings homes). It retires the per-user half of Installing and of the home surface. Plan → access, the access-check half, is carried by a parallel change (see §3).

1. What is wrong today — measured

An app is already stored once, as a partition on the instance (Signature/, Crm/, Edu/). "Install" then copies part of it into every user's home and writes bookkeeping beside the copy. Measured with get @{user}/* for one long-standing account on the control instance, 2026-10-10:

The copy machinery. It has four copy engines: Localizer.Localize, ItemRestore, StandardPacks.EnsureFor* and the Reinsurance demo importer. About 20 trigger sites call them. Two of those triggers are page renders: StandardPacksOnboarding.EnsureForViewer on the catalog/home render, and Edu EnsureCopy on the lesson render. Keeping the copies converging takes Store/Installer, about 8,900 lines, plus about 320 node-test methods.

Every way it has failed is a property of copying. One per-user state machine per app per home gives one chance per viewer per app to go wrong:

• snapshots that never refresh (AgenticOffice);
• a Reset that deleted nothing because an empty read meant "Anonymous" (211 nodes kept);
• a verify that failed 42 times on Agent/Voice vs voice (MeshWeaver#4817);
• tile names, icons and groups that drift and need a mesh-wide heal sweep;
• AdvancedBusinessRules · 1/17 · 1/14 · 1/14 …;
• a free-pack sweep that minted grants for 60+ users;
• unrecorded learner copies nothing can update (#1606).

That is what "not robust" means here, and the fix is to stop copying apps, not to copy more carefully. Only material the user explicitly starts (a course) is still copied, because that copy is the user's own work (§5).

2. The model in one table

3. Who sees an app — access, not install

visible(app, viewer) = app.content.app == true                 ← one of the roster (§6)
                     AND Read(viewer, app entry point)          ← the ONE access check
Read on gated package content =
      PlanAccess.Covers(viewer, package)                        ← effective plan covers package.tier
  AND (app._Policy.audience is empty OR viewer ∈ audience)      ← roles / functions, transitively via GroupMembership
  OR  an explicit AccessAssignment / publicRead _Policy          ← as today, BUT capped by the audience (below)

• Roles and functions are groups. "Only underwriters see Underwriting" means the admin sets Underwriting/_Policy.audience: [Underwriters] in Manage apps. The plan still has to cover the tier. With no audience set, everybody the plan covers sees the app.
• The access check is the only gate. It answers the launcher, opening by URL, search and agents identically, so a restricted app cannot leak through any of them.
• The plan → access seam is carried by a parallel change on branch feat/covered-plan-opens-without-get. It provides PlanAccess.Covers / PlanAccess.Grants in Store/Licensing/Source/PlanAccess.cs and folds them into core's PermissionEvaluator. This plan consumes it and does not touch Store/Licensing, PluginGate or the cover areas. The audience field was agreed with it on 2026-10-10.
• The audience is a cap, not one more grant. The gating pass writes a package's audience as deny rows over everyone outside it, so a legacy package-wide grant cannot reopen an app its audience excludes. One example is the PluginGate.Enroll row that an old Get or Subscriptions.Unlock minted. The parallel change retracts plan-derived legacy grants and keeps deliberate one-time purchases (the eternal entitlement records).
• The probe is the app's entry point, not its root, because a gated root is readable by everyone as the storefront ("root + _-satellites").

4. The launcher list: live, kept warm 5 minutes

Core gets AppDirectory (in MeshWeaver.Graph, beside UserActivityLayoutAreas.BuildAppsBand, which reads it instead of path:{owner}/_App):

1. The app roots. One process-wide query in the established package-root shape: nodeType:(Space OR Store/Plugin) is:main partitions:all (DataModelExplorerLogic.AllPluginRootsQuery, because a root can still be indexed as Space), filtered to content.app == true and bounded by an explicit limit. It goes through IMeshNodeStreamCache. It is the same for every viewer.

2. Per root, PermissionEvaluator.HasPermission(viewer, entryPoint, Read). Its inputs are the process-wide $security-* streams, so the result is live: a grant, a membership, a plan change or a revoke re-emits.

3. Plus the platform entries every viewer has.

   • Settings (/{user}/Settings) for everyone.
   • Administration (Admin) when IsGlobalAdmin.
   • Inbox.

   These are not records, so SeedDefaultAppsLogonAction, SeedInboxAppLogonAction, InstanceAppTileLogonAction and the icon-adoption logon actions are retired.

4. Display (name, icon, description, category) comes straight from the package root, so there is nothing to stamp or heal.

The 5-minute cache. AppDirectoryCache is a singleton keyed by viewer, holding Replay(1) of the live stream.

• Each subscription resets the clock.
• After the last subscriber leaves, the stream is kept warm for 5 minutes, then disposed.
• A user who comes back within 5 minutes paints instantly. One who is idle longer recomputes once.

5. The home holds only the user's own data

Rule for every app author: an app writes into a user's home only in response to that user creating something. Signing in, opening an app, being covered by a plan and rendering a page write nothing.

What remains of "install" is Start: copying user-data templates into the home on an explicit user act. A package declares them in startPaths (today's installPaths, narrowed). They are material the user will work in, such as a course's exercises or a template workspace. They are never the app's own code, agents, skills, guides or examples, which stay in the package partition and reach the user through access. Start writes the copy and its fingerprint record ({user}/_Install/{package}, kept for refresh and restore). It writes no tile, no workspace root of its own and no agent/skill copies. The copy engine stays for exactly this: Localizer.Localize, narrowed to startPaths, with RefreshPlan and ItemRestore.

6. The fleet consolidation — 111 packages → about a dozen apps

Scanned 2026-10-10 at origin/main of Plugins (76 roots), SocialMedia (5), Reinsurance (17), Manufacturing (1), Education (11), Crm (1) and FundReporting (1). Every root lands in exactly one place:

Apps — the whole launcher

A pro user sees 12 tiles, an admin 13, and an enterprise user adds one per vertical. Today the home shows ~50 roots plus a tile per install.

Settings sections — no tile

Capabilities — no surface

Essentials, Publish, Import, Indexing, Collaboration, Export (the menu action; its gallery is in Examples), OgCard (embed; gallery in Examples), RemoteControl, Video, AzureBlob, Store (the engine). They are listed in Manage apps so an admin can see they are present.

The roster gate — no gazillion apps

validate-repos.py gets check_app_roster, which holds a literal set of the package ids allowed to declare app: true. It follows the pattern of check_one_agent_master, and each satellite carries its own set. A new launcher tile is therefore a deliberate, reviewed one-line diff. Everything else must declare hostedIn or nothing.

• A Plugins package that sets app: true without being on the roster is red.
• A hostedIn naming a host that does not exist is red.

7. App design — one look for every app

Every surface is built from the platform's controls (Stack, LayoutGrid, Title, Markdown, Button, DataGrid), never from markup of its own.

The launcher. A large filter field at the top of the home, 64 px tall, full width, with / to focus it. It matches app names and what an app does ("sign a contract" finds Signature), and it filters the one grid in place. Below it is one grid of rounded-square icons, grouped by category. It has the existing ⋯ menu, Recent / Favorites / All, and Icons / Cards / Rows. With a dozen apps the grouping shrinks to four headings:

Administration sits last, admins only. Icons follow one system: a 48-unit rounded square (rx=10), one brand colour or a two-stop gradient, and a white glyph, as Developer, Store and Crm already do. Packages whose icon is an emoji or a currentColor outline (Agent, Skill, Training, Voice, …) get redrawn in that system.

The app front page (AppFrontPage, one shared builder in Store/Core, used by every app's entry point):

1. Hero: the icon at 64 px, the name, a one-line promise, and one primary button. That button is Open or, for a suite, the first section. A secondary button reads Settings when the app has any.
2. What you can do: three cards, each a sentence and a deep link.
3. Ask the agent: two or three example prompts, which start a thread through hub.StartThread.
4. Sections: for suite apps (Personal, Games, Social Media, Reinsurance, Examples, Learning), a card grid of the hosted packages, from the existing ExtensionShelf query.
5. Not covered: one line, Included in Pro → see plans, never a buy button.

Setup: connect what you already use. The first sign-in walks through Profile → Connect → Your apps. Connect offers every kind of account at once, by any provider:

• Mail & calendar: Microsoft 365, Google, iCloud, other email (IMAP/SMTP), other calendar (CalDAV or a subscribed link).
• Professional & social: LinkedIn, X, YouTube.
• Messaging: Teams, WhatsApp, iMessage.
• Home & entertainment: Home Assistant, Apple Music, Weather.

Each one is optional, and Skip for now is always there. Every connection is the user's own data ({user}/_Connections/{provider}, secrets encrypted through ConnectionSecrets), so this is exactly the kind of write §5 allows. The same list is Settings › Connections › Accounts afterwards, and an app with a missing connection links there.

The Settings app. A left rail grouped into Account (Profile, Account, Preferences, Sharing, Plan & billing), Personal (AI, Notifications, Signing authority) and Connections (Accounts, Messaging, MCP clients). There is no Maps tab: map keys are instance configuration. Each tab is a UiContribution context: PersonApp from the owning package, shown only when the access check passes.

Administration. Manage apps first: a DataGrid of every app on the instance (icon, name, tier, Who sees it, status), with Add (the registry catalog) and Remove. Each app's row opens its management page, which holds its instance settings inline and the audience picker. Then Users & access, Plans & seats, AI providers, Maps, Channels, Mail, Payments, Operations.

App settings. A Settings tab on the host app, fed by a new context: AppSettings contribution. Threads, Signature, Personal and Social Media use it.

8. Migration — phases, repos, gates

Each phase is its own pull request or set of pull requests. Phases 1–5 are additive or retire code paths. Nothing in them deletes user data. Phase 6 deletes, and runs only on the maintainer's go, per instance, after a dry run.

Order of landing: 1a → 1b → 2 → 3 → 4 → 5 → 6. Phase 2 can run in parallel with phase 3.

Deploy before recycle. A core change (phase 1a's AppDirectory, the AppSettings context) is process-loaded. It reaches an instance only through the CD roll of a core image that contains it: confirm the instance's /api/version against the merge first. A module or package change reaches an instance through the registry publish (after main's settle-locks PR) and the instance's update. Only once the instance runs the new build does a recycle make sense. Then recycle the per-node hubs that serve the changed types:

• the person app on a test user, and Admin;
• AI/AiThreads;
• Developer/Home;
• Store/Catalog;
• every new host.

Then verify on the public instance as anonymous, free, pro and admin.

9. Decisions taken here, and the ones left