Publishing Safety

Publishing safety

Dashless separates states that conventional Publish buttons often blur:

1. Saved in WordPress
2. Preview built
3. Published in WordPress
4. Production site built
5. Release deployed
6. Public route verified

Every operation reports these states independently. A successful WordPress save is never presented as a successful public deployment.

Content provenance

WordPress is the sole production source for Posts, Pages, media, terms, and editorial metadata. A request to design, preview, deploy, or launch the Astro site grants no permission to create or rewrite those objects.

Dashless renders an honest empty state when WordPress has no published content. Theme demos, screenshots, test fixtures, and generated sample copy never become deployable fallback editorial content.

Codex may create or revise content only after an explicit editorial request. New authored content is saved as a WordPress draft and follows the same preview-lock and approval rules.

Stale-write protection

WordPress supplies modified_gmt for every editable item. Draft updates and published changes are tied to the value that was read before editing. If it changes first, Dashless refuses the write.

This prevents an agent from silently overwriting a newer change made in wp-admin, another integration, or another Codex task.

Exact preview locks

When Dashless builds an editorial preview, it records:

• the connected site;
• post type and WordPress ID;
• public slug and route;
• base modified_gmt;
• staged change ID, when applicable;
• Astro project path;
• preview URL; and
• a SHA-256 digest of the stable editorial fields.

The digest covers post type and ID, slug, raw title, raw semantic HTML, raw excerpt, featured-media ID, category IDs, and tag IDs. Status and timestamps are excluded so an approved draft can transition to published without altering the payload.

Publication fails when:

• the preview build did not complete;
• the parent changed after preview;
• the staged payload no longer matches the digest;
• the token belongs to another connected site; or
• the single-use token was already consumed.

Editing after preview is normal; it simply requires a new preview and approval.

Site-wide generation locking

The WordPress companion increments a monotonic content generation for changes to Posts, Pages, terms, and attachments. Preview and production builds read it before and after Astro runs.

If any relevant WordPress content changes during a build, the build fails closed—even when the change was not to the item currently being previewed. This prevents a static tree assembled from two different site states.

WP Cloud release manifests also carry the generation. The companion refuses activation if the current WordPress generation no longer matches the completed build.

Immutable deployment

Dashless never copies a candidate build over the active site in place.

• Local and SSH deployments create a new release directory, then atomically change a current symlink.
• WP Cloud uploads a complete release directory, verifies its SHA-256 manifest, then atomically changes one WordPress option.

A failed build, copy, upload, integrity check, or activation leaves the prior release selected.

Public WP Cloud verification

After activation, Dashless requests the public page with cache-busting and verifies the exact active release ID. Editorial publication also verifies the previewed content digest on the public route. The companion's authenticated release status must agree with both.

If public verification fails after WP Cloud activation, Dashless automatically restores the previous verified release and reports the verification and rollback states separately.

Partial failure behavior

WordPress publication and static deployment cannot form one distributed transaction. WordPress may accept a publication before a later build or upload fails.

When that happens, Dashless:

• reports published_in_wordpress: true;
• reports the production, deployment, and verification failure independently;
• leaves the prior static release online; and
• allows deploy_frontend to retry without republishing or duplicating the content.

If WordPress normalizes the saved payload so its digest differs from the preview, Dashless keeps the prior release online and requires a preview of the actual saved version.

Recovery

• Rebuild current published content with deploy_frontend.
• Restore the immediately previous WP Cloud release with rollback_wpcloud_release after explicit confirmation.
• Restore editorial content by staging an older WordPress revision and passing it through a fresh preview.

Rollback of the static frontend does not alter WordPress editorial content. Revision restoration does not bypass preview approval.