Safe Publishing

SpiderPublish makes risky actions safe by separating deciding to change something from doing it. Every destructive action runs in two steps: a preview that shows exactly what will happen, and a confirm that carries it out. This is what lets you trust an AI agent with your live site.

The preview-then-confirm flow

When you (or an agent) trigger a destructive action — publishing, deleting, applying a theme, or deploying — the first call does not change anything. It returns:

  • a preview of the result (for a deploy, a preview URL and a summary of what is changing),

  • a confirmation token that represents that exact change.

You review the preview. If it is right, a second call with the token carries out the action. If the underlying content changed in the meantime, the token no longer matches and the action is refused — so you never accidentally apply a stale change.

Why it matters for agents

An AI agent is fast and literal. The preview-then-confirm flow means an agent can propose a change and you (or a supervising step) approve it. Agents default to preview mode: they show you what they intend to do and wait. Nothing lands on your live site without a confirmation.

Which actions are gated

The safe flow protects the actions that can lose work or change what visitors see — for example: deleting, publishing, and unpublishing a page; applying a theme; deploying to production; and similar component and deploy operations.

In practice

  • In the dashboard — you see a preview screen and click to confirm. The flow is invisible but always there.

  • In the CLI — commands like spideriq content deploy print a preview and prompt [y/N]. For automation, capture the token from a preview and pass it to the confirming call, or use the non-interactive flags.

  • With an agent — the agent receives the preview and the token, shows them to you, and only confirms when told to.

Scoping and isolation

On top of preview-and-confirm, every change is scoped to your workspace. Calls are bound to a workspace (and, optionally, a specific project) through your spideriq.json, and the server enforces that a request can only touch the workspace it is authorized for. An agent working on one site cannot reach into another.

Tips

  • Read the preview. It exists so you can catch a wrong slug or an unintended deletion before it happens.

  • Let tokens expire. A confirmation token is single-use and time-limited by design; if you waited too long, just preview again.

  • Keep humans on production. Automate previews freely; gate the final confirm on a person or a deliberate CI step for anything customer-facing.

Next steps

  • The CLI — how spideriq content deploy previews and confirms.

  • MCP Setup — connect an agent that respects this flow.

  • Deploy — push your site live to the edge.