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.