App previews and Versions
In the design, a definition change reaches an App as one Change: previewed on its own Domain, checked screen by screen, then published as a new Version.
In the design, a definition change reaches an App as one Change, previewed before it merges. The preview shows every screen the Change alters, and App.publish makes it a new Version.
One Change, one preview
A Change is a proposed set of writes to definitions, merged as one unit. Each open Change gets its own preview: a Domain with the role preview, such as change-12.leaseclock.com.
The preview serves every path the live App serves, from the Change's branch. Only the Startup's own team signs in there, so no Customer meets a screen before it publishes.
When the Startup keeps its definition in git, a pull request is the Change. Merging the pull request applies the Change, and closing it discards the Change and its preview.
The screens a Change alters
The preview starts with a list of the screens the Change alters, derived by the same rules as the live App. This Change gives Lease a notice period and a Verb that sends the notice.
documents?: string[]
+ renewalNoticeDays?: integer
property: Property
verbs:
renew: {}
terminate: {}
+ sendNotice: {}| Screen | What changes | Rule |
|---|---|---|
Lease list | No new column: 7 columns hold already. Send notice joins Renew and Terminate on each row. | list-columns, verb-action |
Lease record page | Renewal Notice Days shows as a number. Send notice joins the buttons. | control-number, verb-action |
Lease create form | Renewal Notice Days as a number box, not required. | control-number, required-input |
Lease edit form | The same number box, and a Send notice button. | control-number, verb-action |
Property screens | Unchanged. | — |
Each row names its rule, so a reviewer checks the outcome, not the code. The preview also opens each altered screen with sample records, at desktop and phone widths.
Checks before the merge
A Change merges only after its checks pass. Change.merge refuses while any required Evaluator lacks a passing verdict on the Change's head.
| Check | Passes when |
|---|---|
| The definition parses | Every Noun file and every Verb Function type-checks. |
| The Interfaces regenerate | The API, SDK, CLI and MCP forms of every Verb derive from the new definition. |
| The screens derive | Every screen in the list above renders with sample records. |
| The examples run | Each Verb example returns the Action its page shows. |
Every Change to a definition waits for a review, by a person or a designated Agent. A Change that widens what a Customer may do, such as a new Verb on /app, always needs a person's review.
Publish, then roll back in one step
App.publish builds a Version from the merged definition. A Version is immutable and named by its fingerprint, such as sha256:9f2c4e1a7b3d, and the App serves it from the next request.
The App keeps every earlier Version. To roll back, Change.revert opens a Change that restores the Version before, and publishing it serves that Version again.
| Version | From | Serves |
|---|---|---|
sha256:9f2c4e1a7b3d | Change 12, renewalNoticeDays and sendNotice | leaseclock.com, live |
sha256:41d7b09c2e6a | Change 11 | kept, one step back |
A rollback changes screens and Verbs, never records. A Lease saved with renewalNoticeDays keeps its value, and the property reappears when a later Version declares it again.
How an App is served
In the design, every App answers on the Startup's own Domain, derives its screens on each request, and calls one API behind every screen.
SaaS.Studio: what it adds over code
SaaS.Studio, in the design, builds Apps by prompt and canvas over the same records a Startup writes in code, and runs every App a Startup has.