App lifecycle
How a change to an App goes live, from a preview on its own address to every Tenant, and how to take it back.
An App changes through a Change, goes live with App.publish, and rolls back by pointing at the previous Version. Records never move with the App: a rollback changes screens, not data.
Preview
Every Change renders at its own address against test data before it merges. The founder asks her agent to add a rent-history panel to the lease screen. The agent opens a Change, and the preview shows the new panel on Harbor Residential's test copy, with the live App untouched.
Change.review runs every check on the preview, from the speed gate to the Guards. A failing check holds the merge and names the fix.
Publish
Change.merge builds a new Version, and App.publish serves it. Every Tenant runs the newest build on its next request, so no Customer runs an old copy.
Publishing is a publish action: when the founder's approvals ask her first for that class, the publish waits on her Approval. Each publish leaves an Action and the Event App.published.
Roll back
To roll back, run Version.deploy on the previous Version. It takes one step and touches no record, so a lease renewed under the new build stays renewed.
A Customer's code is never broken by a rollback. The API keeps its version on each Tenant's pin (Tenant.pin), apart from the App's screens.
Pause
Status planned. App.pause stops an App serving its screens while the API keeps answering, and App.resume brings the screens back. A rollback to a known-good Version stops a bad build in one step.
Next
Tenancy and identity covers who signs in to each Tenant.