docs agent failed: published draft docs to production site

TL;DR

Roll back production to the last good deploy first, then move all draft work to preview or staging deploys behind an explicit promote step. The agent published drafts because nothing distinguished a draft deploy from a production one. Rollback stops the bleeding; the promote gate stops the repeat.

docs agent failed: published draft docs to production site

Steps

1. Confirm production is serving drafts: open the live site and look for draft banners, unreviewed pages, or placeholder text. Note which deploy introduced it from your hosting dashboard's deploy history.
2. Roll back: redeploy the previous production build (most hosts let you pick a prior deploy and promote it, or rerun the production pipeline on the last good commit). Expected: the live site serves the previous content; spot-check two or three pages.
3. Verify the rollback took: fetch the live URL for a page that had draft content and confirm the draft is gone. Expected: no draft markers anywhere on the production site.
4. Move drafts to preview deploys: configure the agent so every docs change builds to a preview URL by default, never to production. Expected: the agent's next run produces a preview link.
5. Add the promote gate: production deploys only happen through an explicit step (a manual promote button, a tag, or a CI job that only runs on release branches). The agent is not allowed to trigger it. Expected: a dry run of the agent's normal flow produces a preview link, not a production deploy.

Use this when

• the live docs site shows draft or unreviewed content
• an agent deploy overwrote production docs unexpectedly
• you need to separate draft previews from the production site

Not for this skill when

• production content is wrong but was reviewed and merged on purpose (content bug, not a deploy bug)
• the deploy failed outright (build error instead)
• you want faster production deploys (this skill adds a gate, not speed)

Variant phrasings

• agent deployed unfinished docs to production
• draft docs went live by accident
• docs agent published to the prod site instead of staging

Why it happens

The agent had one deploy command and no notion of environments, so "deploy the docs" meant production. Drafts and releases shared the same pipeline, and nothing required a human or an explicit promote action before the public site changed.

Edge cases

• Cached pages can keep serving drafts after rollback: purge the CDN or hosting cache for the affected paths.
• Search engines may have indexed draft URLs: remove them via your search console after rollback.
• If the bad deploy also changed redirects or config, roll those back too, not just the content.
• Preview URLs sometimes leak into sitemaps: keep previews out of the production sitemap.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstDJgw91Xas9wp5MnBVWq0Q