Orbitr field guide

CMS publishing

Connect a publishing surface, preserve a snapshot, verify the public result, and roll back through Orbitr.

Connect the real publishing surface

Use the integration flow for the site platform. For repository-backed sites, connect the repository that actually serves the selected domain. For a CMS, select the site or store returned by the provider.

Capability discovery

Orbitr determines whether it can read content, create a snapshot, publish the requested change, and verify the public URL. A connected integration does not mean every task shape is supported.

Publishing path

Approved supported writes pass through Orbitr's publishing service or a snapshot-instrumented adapter. A successful operation should retain the task, site, changed resource, and provider or snapshot identity needed to inspect the result. Public verification is recorded separately from the provider write.

Partial and failed publishes

If a provider accepts only part of a change, times out, or returns an ambiguous result, Orbitr should not present the task as publicly verified. Review the task result, visible error, and provider operation before retrying.

Retry and idempotency

Retry from the existing task only when the app offers that action. Do not create or approve a duplicate task to retry the same provider mutation. Reusing the original task and operation identity reduces duplicate-write risk.

Rollback

Rollback is available only when the original operation has a supported restoration path and retained prior state. If Orbitr exposes a rollback operation, use that original operation identity and then inspect the customer-visible URL. If no rollback action is available, do not rerun the task as a substitute; contact support with the site ID and task ID.