Skip to main content

Commands

Every command is registered under the SpiderPublish: prefix in the command palette (Cmd+Shift+P / Ctrl+Shift+P). Most also surface inline in the Changes view in the SpiderPublish Activity Bar.

This page covers what each command does, when to use it, and what to expect. For the link-audit hook and Code Actions, see the Link audit page.

Auth + binding​

SpiderPublish: Who Am I?​

Show the current authentication state. Useful as the first command after install to confirm the extension reads ~/.spideriq/credentials.json correctly. If no token is found, the command prompts you to paste one.

Output:

✓ Signed in as agent_xxxxxxxxxxxxxxxx
  email:    admin@your-company.com
  brand:    Your Brand (br_xxxx)
  project:  acme-corp (cli_xxxx)   ← if a project is bound

SpiderPublish: Select Project…​

Pick a project from the list of projects this token has access to. Writes spideriq.json to the workspace root.

If you're already bound to a project, this switches the binding and prompts to discard or stash uncommitted changes first.

Read​

SpiderPublish: Pull Content​

Fans out parallel per-type GETs (pages, posts, components, templates) and writes each record to disk. Performs a 3-way merge against the registry's last-known baseline so locally-edited files don't get clobbered.

After Pull:

  • pages/<slug>.json, posts/<slug>.json, etc. live on disk
  • .spideriq/objects.json records each file's sha256, original (base64 of the last-synced content), and status (unchanged / changed / new / notfound)
  • The Changes view shows entries grouped by type
  • Status bar: 📁 acme-corp · N changed · M undeployed

Run Pull whenever you want to sync from the server — typically after merging a teammate's PR or before starting a new edit session.

SpiderPublish: Discard Changes​

Revert a file to its last-pulled baseline (also auto-unstages it if staged). Available as a context menu action on changed files in the Changes view.

Stage​

The Changes view supports git-style staging. Push only sends staged records to the server.

SpiderPublish: Stage / Unstage​

Stage or unstage a single file. Inline + / − buttons on each entry in the Changes view.

SpiderPublish: Stage All Changes / Unstage All​

Bulk operations on every changed entry. Inline buttons in the Changes view title bar.

Write​

SpiderPublish: Push Content​

The destructive surface, in five phases. Snapshot-bound: every confirm token is paired to the exact dry-run payload that produced it.

Phase 0  Pre-push link audit
         └─ broken == 0  → pass through silently
         └─ broken > 0   → modal:
                            ├─ "Review"      → focus Problems pane + abort
                            ├─ "Push anyway" → log loudly, clear audit diags
                            └─ "Cancel"      → full teardown, no push

Phase 1  Dry-run fan-out (parallel, one per staged record)
         └─ each call returns {preview, confirm_token}
         └─ Map<recordId, PreviewedRecord> stays alive in memory

Phase 2  Consolidated review panel
         └─ webview shows every preview side-by-side
         └─ user clicks Approve all / Cancel

Phase 3  Confirm fan-out (parallel, paired tokens)
         └─ each token consumed exactly once with its paired payload

Phase 3.5  Diagnostics
         └─ JSONPath errors decode to inline vscode.Diagnostic at file:line

Phase 4  Pull-after-push
         └─ resync server-normalized fields (published_at, IDs, version bumps)

The snapshot-bound design means an agent that misbehaves mid-review — generates new payload, tries to slip it past the confirm — fails at the token check. The preview is what gets confirmed; nothing else.

If broken links are found in Phase 0, the modal forces an explicit decision. "Push anyway" is the escape hatch for cases you've already decided are intentional (e.g. a redirect that's about to be wired up); it logs the count loudly to the output channel for audit.

SpiderPublish: Push Current File​

Single-file variant. Useful for tight-loop edits on one record without firing the full fan-out. Skips Phase 0 audit.

Deploy​

SpiderPublish: Deploy Site​

Five-phase deploy:

Phase 1  Readiness check
         └─ /content/deploy/readiness → blockers list
         └─ if blockers > 0 → readiness webview, abort

Phase 2  Preview
         └─ POST /content/deploy/preview → { preview_url, confirm_token }

Phase 3  Confirm
         └─ POST /content/deploy/production?confirm_token=cft_…
         └─ returns { status: "live", version_id }

Phase 4  Status polling
         └─ /content/deploy/status while status = "deploying"
         └─ typically completes in 2–5s

Phase 5  Done
         └─ webview shows live URL + version ID
         └─ status bar: undeployed count drops to 0

Diagnostics from a failing deploy land in the same spiderpublish collection as Push errors — JSONPath-decoded, inline at the offending file:line.

SpiderPublish: Open Last Preview​

Reopens the most recent preview URL in a webview without re-running the deploy. Useful after a Deploy Site → "looks good in preview, let me show a teammate before I confirm."

Audit​

See the Link audit page for full coverage. Quick reference:

CommandWhere it fires
SpiderPublish: Audit Internal LinksManual run; emits inline diagnostics for broken /path references
Pre-push hookAutomatic Phase 0 of Push Content
SpiderPublish: Accept Proposed RedirectCode Action on each broken-link diagnostic

Diagnostic helpers​

SpiderPublish: Refresh Schemas from Server​

Re-fetch /content/help, /content/playbook, and /content/variables from the server. The extension caches these for 24 h by default; use this command if you've changed schema server-side and don't want to wait for the cache.

SpiderPublish: Show Diagnostic Info​

Dumps activation state, credentials.json layout, MCP subprocess status, and the latest get_auth_status round-trip into the output channel. Paste this into support tickets when something's off.

The dump is sanitized — actual token values are redacted, only the shape and freshness are surfaced.

Tree view (Changes)​

The SpiderPublish view in the Activity Bar shows your registry, grouped by type. Each entry has:

  • Status icon — M (changed), + (new), ? (notfound — exists locally but not in registry; may have been deleted server-side)
  • Filename — click to open the file in an editor tab
  • Inline actions — Stage / Unstage / Discard

Title-bar actions:

  • Pull (cloud-download icon) — SpiderPublish: Pull Content
  • Stage All — SpiderPublish: Stage All Changes
  • Unstage All — SpiderPublish: Unstage All

Context-menu actions on each entry:

  • Stage / Unstage (toggles based on current state)
  • Discard Changes (only on changed entries)

Status bar​

Bottom-right corner shows three slots:

📁 acme-corp     · 3 changed · 1 undeployed     · ✓ signed in
SlotMeaning
📁 <project>The project you're bound to via spideriq.json. Click to run Select Project….
N changedLocal edits not yet pushed. Click to focus the Changes view.
M undeployedPushed records not yet in the live deploy. Click to run Deploy Site.
✓ signed in / ✗ not signed inPAT presence. Click to run Who Am I? or paste a new token.

Native diff editor​

Click any changed entry in the Changes view to open VSCode's built-in side-by-side diff editor. The left side shows the last-pulled baseline (via the spiderpublish-baseline: virtual URI scheme), the right side shows the current file on disk.

To diff against the live server state instead of the baseline, right-click the entry → Compare with Remote. The right side becomes spiderpublish-remote:<id> (a fresh fetch from the API).

These are not custom webviews — they're the actual VSCode diff editor, so all the editor features work: inline-fold equal regions, jump to next change, keyboard navigation, etc.

Activation events​

The extension activates on:

  • VSCode startup if a spideriq.json exists somewhere in the workspace
  • Any spiderpublish.* command invoked from the palette
  • Opening the SpiderPublish view in the Activity Bar

Cold-start cost: ~336 ms (the MCP child process spawn). Warm starts are negligible.