Publish And Operate

Publishing moves builder intent into runtime behavior. Treat it as a controlled release, even when the change is small.

Before publishing

Check the workspace or draft:

• validation passes
• open errors are understood and intentionally deferred
• command and event names still express the business language
• projections support the needed read paths
• permissions match expected actors
• policy side effects are visible and expected
• adapters and credentials target the right environment
• custom pages still call generated runtime surfaces

For AI-assisted work, ask the Design MCP reviewer to summarize the diff and remaining risk before promotion.

Promotion

Use a changeset for scoped design work:

1. create or update the workspace
2. validate the workspace
3. create the changeset
4. review validation output
5. promote to the target environment with explicit approval

Record the workspace id, changeset id, target environment, and validation id in the handoff.

After publishing

Run a runtime smoke test:

$
curl https://your-instance.com/api/rest/<tenant-id>/<app-id>/openapi

Then execute one representative command and read one projection that should show the resulting state.

Projection rebuilds

Rebuild projections when projection definitions change, after event import, or during recovery work. Do not rebuild casually in production without understanding the event volume and downstream expectations.

Operational checks

After publish, inspect:

• Activity for command, event, policy, and webhook traces
• Data Explorer for projection state
• error logs for validation, policy, adapter, webhook, or auth failures
• runtime agents or custom pages touched by the change

If a smoke test fails, fix the model or permissions before asking external consumers to adapt.