-
Notifications
You must be signed in to change notification settings - Fork 0
Editorial Workflow
Dashless is designed for ordinary language, but its operating sequence is intentionally strict. Codex can make the work conversational without making publication ambiguous.
get_status reports the active WordPress connection, authentication, configured Astro project, deployment target, and whether WordPress is newer than the last build or deploy.
inspect_site reads the WordPress content model, settings, content counts, Page hierarchy, generated route map, companion version, and content generation. Use it before creating a frontend or after the site structure changes.
Neither tool mutates WordPress.
An explicit editorial request may create a Post or Page. create_draft always saves it with WordPress status draft, even if the surrounding request mentions a future launch or deployment.
Each create uses a stable client key. Repeating the same request with the same key returns the original draft instead of creating a duplicate.
The normal sequence is:
- Create the draft.
- Assign existing or newly requested terms.
- Upload or choose WordPress media.
- Build the exact route with
create_preview. - Review the local site.
- Make changes and build a new preview as needed.
- Explicitly approve
publish_previewed.
update_draft changes only draft, pending, or future items. It requires the modified_gmt value read with the item. If another actor edits the item first, the update is refused rather than overwriting newer work.
Read the fresh item, reconcile the difference with the user, and retry with its new timestamp.
Dashless does not edit a published parent while a change is being prepared. stage_update records a local changeset tied to the parent's current modified_gmt.
The staged payload can be built at the real public route. Only publish_previewed applies it to WordPress, allowing WordPress to create a normal revision at publication time.
If WordPress changes after staging or preview, the lock is stale and publication stops.
Use list_terms before creating taxonomy. ensure_terms reuses exact existing category or tag names and creates only the explicitly requested missing names. WordPress term IDs, not names, are attached to content.
Categories become topic archives in the stock Astro frontend. Tags receive their own directory and archive routes.
list_media browses WordPress media, including accessible text and image dimensions. upload_media sends a local file to WordPress and records alt text, caption, title, and description. update_media repairs metadata without replacing the file.
Meaningful images require useful alt text. An empty alt value is appropriate only when the image is intentionally decorative.
The Astro build mirrors WordPress media into its output. Public HTML does not depend on WordPress media URLs remaining uncached at request time.
Pages support WordPress parent IDs and menu order. The Astro route is derived from the complete parent chain, so a Page can render at a nested route such as /about/team/.
The configured front Page supplies the homepage's editorial introduction. The configured posts Page informs the stories route when no custom route was requested.
list_revisions reads WordPress revisions. stage_revision_restore copies one older revision into a local staged change; it does not overwrite the parent.
Build and inspect that restoration exactly like any other published-content change. Only a fresh, explicitly approved preview may publish it.
preview_frontend rebuilds and opens the complete site without creating a publication lock or changing WordPress publication state. Use it for layout, CSS, navigation, template, accessibility, and responsive work.
Changing the frontend does not authorize content creation. The Astro project must remain honest when WordPress is empty.
The WordPress companion increments its content generation when a Post, Page, term, or attachment changes through any route, including wp-admin or another integration.
get_status then reports that the site needs a build or deploy. deploy_frontend rebuilds the current canonical published state and activates a new release without republishing any item.
Because there is no remote Dashless worker, future-dated WordPress publication cannot trigger a static rebuild while the local computer and Codex are offline.
disconnect_site requires explicit confirmation. By default it:
- revokes the dedicated Application Password in WordPress;
- removes the local connection and secret; and
- erases this site's idempotency, staged-change, preview-lock, and preview-payload records.
It preserves all WordPress content, the generated Astro project, and deployed static releases. If remote revocation fails, Dashless retains the local connection so it can be retried.
Continue with Publishing Safety for exact publication guarantees.
Dashless 1.0 · WordPress without the dashboard · Regionally Famous · MIT license