Architecture
Runtime Resolution
How first-party apps resolve into tenant runtimes and why presentation never overrides entitlement
First-party rule
First-party apps resolve from:
- tenant app assignment
- plan app entitlements
They do not resolve from workspace-local install rows.
Runtime contract
For UI consumers, the important pair is:
workspace_statereason_code
That pair explains:
- whether the app is available
- whether it is visible
- why it is in that state
Presentation rule
Visibility hints such as show_in_switcher or visible_in_selector must not remove an entitled app from the runtime apps payload.
They only affect rendering.
Outcome
This gives:
- cleaner admin-app navigation
- cleaner saasdash-app app management
- simpler plan reasoning
- no seed-and-heal logic for first-party app presence
Boundary consequence
The runtime resolver should work with top-level apps first.
It should not be asked to resolve:
- product subpages as apps
- payment infrastructure as apps
- selector visibility as entitlement
That separation keeps the runtime aligned with the app boundary model.