--- title: "A 6:33 AM Tailscale DNS Error and a Missing .gpg File" canonical: https://dxdev.com/blog/bootstrap-bundle-forgotten-upload/ datePublished: 2026-07-04 --- ## The bundle that was never there At 6:33 AM, the daily sweep logged one line and moved on: archive drop failed, a remote host unreachable over Tailscale, DNS resolution failing. The obvious read was that a PC was off. We filed it as a network blip and went back to the problem of the day, which was getting a second, freshly wiped machine talking to the rest of our setup. That machine couldn't restore. Restore was not slow; it had nothing to restore from. The reason took most of a day to find, because we spent the first chunk of it reviewing the wrong layer. ## The architecture that passed review The backup design has four pieces. Everything, the full `.secrets/` tree and every repo's `.env*` file, lives in Cloudflare R2 via restic, versioned and deduplicated. A small cold-start bundle, just R2 access keys, the restic passphrase, and SSH keys, gets encrypted and dropped somewhere a fresh machine can reach before any of the rest exists. The passphrase that unlocks that bundle lives in a password manager. And the fresh box needs a short list of prereqs, restic and the `ops-cli` CLI on PATH, before any of it works. The design is sound, and we had two separate AI reviewers go through it the same day the restore failed. That review is where we burned the hours. Before the reviews, we'd floated an alternative: split the key material across two Google accounts, encrypted secrets in one, the unlock key in the other, so a compromise of a single account never hands over both halves. We liked it enough to ask for a formal `/multi-review` before building it. Manus dismissed it in one paragraph. The split only defends against a single compromised account, and the normal bootstrap case is one Claude session that can read both accounts anyway, so it adds operational fragility without adding real security. A password manager with a printed emergency copy does the same job with one less moving part. Codex's independent pass caught something we would have shipped without noticing: our runbook had rclone syncing to R2 when restic already speaks S3 directly, and R2 exposes a standard S3 endpoint. Adding rclone meant one more install and one more failure surface in the exact path that is supposed to stay minimal. Both reviews were right. That session ran from 8:37 PM to 1:19 PM the next day, sixteen hours and forty-two minutes, and it produced a better runbook for a system that was never actually deployed. ## What the review couldn't see The design had no fault in it. When we finally searched our own Drive for the cold-start bundle, there was nothing there. No matching file, no `.gpg`, nothing. Somewhere between designing the four-piece scheme and calling it done, we ran the review, wrote the doc, closed the ticket, and never executed the one manual step the whole thing depended on: generate the bundle, upload it, confirm it's there. The fresh machine failed to restore because step two of a four-step plan had a checkbox nobody ever checked. On the healthy machine we ran `ops-cli bootstrap bundle .tmp/cold-start.gpg --passphrase ''`, uploaded the one resulting file to Drive, and deleted the local copy. On the fresh box, with restic and `ops-cli` on PATH, `ops-cli bootstrap unbundle` pulls the keys and SSH material back down, then `backup_r2.sh restore-all` pulls everything else from R2. No architecture change. No split-key scheme. No rclone. Manus and Codex did what we asked, and did it well. Manus found a real security tradeoff in our own idea before we built it. Codex found a dependency we would have shipped. Neither could have found that the artifact the whole design assumes doesn't exist, because we never put that question to them. We asked whether the design was good and got a correct, detailed answer. Whether we had actually done the thing is a different question, and it gets answered by looking. A design review tells you whether a plan is sound if executed. It has no way to see past the plan to the world, so the execution check has to be separate, dumb and literal: does the file exist at the path where the runbook says it should. We've since added that as its own automated check, run on a schedule and independent of any review, looking at Drive directly instead of trusting that a closed ticket meant a completed action. The network error that started the day pointed at a path that was fine. The missing file had been sitting unnoticed since the ticket closed, and nothing we had was built to find it. ## Check the artifact A passed design review does not show that the plan was carried out. For any backup or recovery plan, check directly that each artifact it depends on exists where the runbook says it does, on a schedule and separate from the review. A closed ticket is no evidence that a manual step was done.