Skip to navigation
Development Process

Publish And Operate

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

Operate interface language

The primary Operate shell, home, inbox, conversations, and channel navigation are available in English and German. Change the interface language from the account controls; Cessy keeps the same route and remembers the choice across authentication and Operate pages.

Localization applies only to Cessy interface copy. App names, channel names, messages, document values, domain-model labels, and other user-authored content remain exactly as entered.

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.

For a failed shadow rebuild, wait for that attempt to settle and inspect its status before starting a serial retry against the same runtime source. The live collection stays authoritative until the replacement is ready. Cessy rechecks readiness after dropping or renaming the temporary collection; a retry does not require waiting for a cache timeout or changing the projection definition. If the same missing-relation error recurs, retain the failure evidence for platform investigation instead of starting repeated rebuilds.

In the Design Release v2 Alpha cohort, a new projection can publish without a rebuild only when every event it handles is also introduced by the same exact Candidate. Cessy commits that event/projection pair inside the existing atomic Domain release, and the projection consumes future events normally. Changes to an existing projection, removals, existing-event projections, and ambiguous history remain blocked until rebuild or migration support is available.

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

An attempt-zero recovery_progress_exhausted is a bounded progress failure, not proof that a policy handler ran or that external effects are absent. Use list_policy_reconciliation_work to inspect the exact work/version/runtime assessment. A null safeDecision forbids replay; do not repeatedly reconcile or reissue the source command. Queue deduplication alone is not execution proof.

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