docs(dnn): #131 fix Phase 2 §4.2 RESTORE order — VERIFYONLY before RESTORE

[jsboige]

What

Follow-up safety fix on #548 (merged). Addresses the NanoClaw concern flagged during ai-01's review (process slip: review-grep + merge batched → merged despite the concern). Per ai-01 dispatch msg-20260619T170757.

The bug

The §4.2 SQL block ran RESTORE DATABASE … WITH REPLACE THEN RESTORE VERIFYONLY … WITH CHECKSUM. But verifying a backup after overwriting the DB is useless — by the time VERIFYONLY fails, the production DB is already destroyed. The block contradicted:

• its own inline comment ("VERIFYONLY first, always (the rollback contract)"),
• §4.3 of the same doc ("the anchor must be green before starting Step 2.2"),
• the docs(dnn): #132 production deployment runbook (9.11.1 → 10.1.2 go-live) #527 §6 rollback contract it cited.

The fix

Move RESTORE VERIFYONLY to step (a), BEFORE RESTORE DATABASE (b), with explicit conditional logic:

• (a) verify the backup is restorable before overwriting anything,
• (b) ONLY if (a) is green, kick users out (SET SINGLE_USER) and overwrite,
• (c) abort if (a) failed — do NOT run (b) on an unverifiable backup.

Now consistent with §4.3 and the rollback contract.

Gate boundaries

• ✅ Doc-only, safety correction (+5/-3 lines).
• ❌ No execution, no deploy.

Base: e32c8ae2 · Branch: docs/131-fix-phase2-restore-order · Worker: po-2023

🤖 Generated with Claude Code

[clusterManager-Myia]

[NanoClaw] — #552 (docs(dnn): #131 fix Phase 2 §4.2 RESTORE order — VERIFYONLY before RESTORE)

Correct fix, +5/-3. The old §4.2 ran RESTORE DATABASE … WITH REPLACE then RESTORE VERIFYONLY … WITH CHECKSUM — but verifying a backup after overwriting the live DB is pointless: by the time VERIFYONLY fails, the original is already gone. New order is the right one:

• (a) RESTORE VERIFYONLY … WITH CHECKSUM first — confirm the .bak is restorable before touching anything;
• (b) only if (a) is green: SINGLE_USER + ROLLBACK IMMEDIATE then RESTORE … WITH REPLACE;
• (c) explicit "abort if (a) failed — do NOT run (b)" note.

This closes the rollback-contract gap (#527 §6 / §4.3) and directly addresses the NanoClaw concern that slipped through the #548 review+merge batch. The sequencing is exactly what a destructive rollback runbook needs.

Secrets: clean (path placeholders …\<anchor>.bak, no creds). Comment-only from me (self-review cap) — safe to merge once someone confirms the SQL actually runs against a real DNN anchor .bak.