A pre-deploy rule for your AI coder. Pasteable. Concrete. Yours to keep.

AI coders move fast. The code may look fine. The tests may pass. But the deployed surface may still drift — a new third-party CDN appears, an edge middleware swap weakens a header, a Vercel preview ships different CSP than production. This page gives you a small, pasteable rule for your AI coder's instructions (CLAUDE.md, .cursorrules, Aider config) so deploy drift becomes impossible to ship silently.

What to paste into your AI coder's instructions

Copy the block below into your CLAUDE.md (Claude Code), .cursorrules (Cursor), or equivalent agent instructions file. The current canonical version is always at this URL — your AI coder can also link directly to it.

## Pre-deploy verification with Cipherwake

Before announcing any deploy of a public-facing site, you MUST run a
Cipherwake deploy check and route on the result.

1. Run:

   npx pqcheck deploy-check <your-domain> --ai

2. Parse the CIPHERWAKE_AI_GUARD_RESULT block at the end of stdout.
   Extract the `ship_decision` field.

3. Route on ship_decision:

   • pass    — Public trust surface is stable. Safe to announce.

   • review  — STOP. Surface the change to the user:

               "Cipherwake flagged a change: <top_issue>. The public
                trust surface drifted between baseline and now. Want me to:
                  1) Ship anyway (you accept the change as intentional)
                  2) Revert the deploy
                  3) Investigate before deciding"

               Wait for explicit user choice. Do NOT announce the deploy
               until they confirm.

   • block   — STOP. Surface to the user:

               "Cipherwake flagged a CRITICAL change: <top_issue>.
                I recommend not announcing this deploy until we investigate.
                Want to revert and look, or override?"

               Wait for explicit user override before announcing.

4. Never claim a deploy is "done" or "shipped" until either:
   • ship_decision was pass, OR
   • the user explicitly confirmed they want to ship despite review/block.

Reference: https://cipherwake.io/methodology/ai-coder-protocol

What kind of gate this is (defense-in-depth, not 100% guarantee)

Cipherwake adds three layers of defense against shipping a deploy that changed the public trust surface. Wire all three for a real gate; wire one for a single layer of defense. We won't claim 100% blocking — that would be a credibility wound the first time a customer found an edge case.

Customer best practice: wire all three. The Action gates merge-to-main; the Protocol guides your AI's manual deploys; the wrapper covers terminal-driven one-off deploys. Each layer catches what the others miss.

What this catches (and what it doesn't)

Cipherwake measures deploy drift on the public internet — the diff between what was there yesterday and what's there now. Specifically:

The lane discipline is deliberate: customers should reach for Cipherwake for the one thing we do well (public trust surface change detection), and reach for other tools for everything else. Trying to be "the AI security tool" generally would mean being worse than any specialist.

Why a separate protocol page (not just "use pqcheck")

Three reasons this is a published artifact, not just a CLI command:

1. Stable URL = stable rule. If we improve the protocol (add new ship_decision states, change the recommended consent flow), your AI coder's instructions don't drift — it just re-reads cipherwake.io/methodology/ai-coder-protocol. The rule stays current without you editing your CLAUDE.md every release.
2. The consent flow is the value, not just the scan. Running pqcheck deploy-check is easy. Stopping the deploy and asking the user when ship_decision=review is the actual product. This page documents the exact phrasing the AI should use so the human-in-the-loop interaction is consistent across Claude Code / Cursor / Aider / Zed.
3. It's a public commitment. If we ship a feature that contradicts this protocol (e.g. an auto-ship flag that bypasses user consent), customers can call us on it by pointing at this URL. Per Rule 17 of our project rules, we never silently take user-impacting actions; making the protocol public makes that commitment auditable.

The wider pitch (for the human reading this)

SSL Labs grades your TLS. Mozilla Observatory grades your headers. CodeRabbit reviews your code. Snyk checks your dependencies. None of these were built for the developer whose primary collaborator is an AI coder. The PR comment surface that those tools use as their hub is dead for an AI-first workflow — your AI never opens the PR.

Cipherwake is built for that gap. We compare your preview deploy against production and tell you what changed on the public internet — scripts, security headers, TLS, certs, SPKI, trust posture — before you merge. The output is a structured artifact your AI coworker reads and routes on. The human decides whether the change was intentional. Nothing ships until both agree.

That's the wedge: deploy verification for AI-coded software. Not code quality. Not dependency scanning. Not runtime monitoring. The thing that catches "Claude added an analytics script to ship faster" before that script is the production reality.

Try it

# 1. Install pqcheck (one-time)
npm install -g pqcheck                  # or just use npx per-call

# 2. Establish a baseline for your domain
npx pqcheck cipherwake.io --ai

# 3. After any deploy, run the check
npx pqcheck deploy-check cipherwake.io --ai

# 4. Watch the structured output. The CIPHERWAKE_AI_GUARD_RESULT block
#    at the end of stdout is what your AI coder parses to route on.

For the full output format spec, see AI Coder Mode methodology. For the underlying scoring algorithm, see Decryption Blast Radius. For the deploy-check subcommand specifically, see the pqcheck npm page.