How a planning Claude and an executing Claude were wired into a closed loop that writes its own briefs, builds, reviews its own work, merges to production, and starts the next job — while I'm away from the computer.
It works. It also took down my site for four hours, deadlocked twice, shipped a watchdog that was broken in exactly the way it was written to prevent, and came one click away from git reset --hard on the only copy of a finished feature. Every mistake below is real and cost something. Copy the architecture; skip the tuition.
The scripts, the rules, the preflight, the destructive-git hook — packaged and free.
npx skills add jeremyinthebay/relay-skillsgithub.com/jeremyinthebay/relay-skills · on skills.sh
Nine skills: two-claude-relay (the architecture) · autonomous-loop-safety (the 54 rules and the code behind each) · agent-preflight (force every permission dialog while a human is watching) · adversarial-audit (find the bugs before your users do) · destructive-git-hook (make reset --hard impossible, not merely discouraged) · production-canary (check prod after every merge, auto-revert if it broke) · mobile-verification (a test harness that isn't structurally blind) · alert-routing (stop paging a human for routine events) · brand-logos-without-rehosting (real company logos, resolved at runtime from each brand's own favicon — nothing scraped, nothing rehosted).
One Claude does the work. A different Claude checks it. They talk through two files in a git repo, and a shell script keeps the whole thing turning.
The split matters more than it sounds. When a model verifies its own work it grades its own homework — it knows what it meant to do, so it tends to see what it meant to do. A separate reviewer, with a separate context window and no memory of writing the code, has no such loyalty. That isn't a theoretical benefit. It caught a real bug on the first run, and I'll get to it.
ghGeneric on purpose — nothing here names a project. Read your own system into it. Every line that sounds oddly specific is scar tissue; each one cost a night.
Human
Sets goals. Decides policy. Paged only for emergencies.
↓ chat — goals in, verdicts out. Never a status update nobody asked for.
Two agents · separate contexts · adversarial by design
Writes the brief. Independently verifies the result. Merges. Never commits.
Builds in an isolated worktree. Commits. Opens the PR. Never merges.
↓ writes brief · reads report ↑
The channel — files in git, not an API
TASK.mdplanner → executor · header Status: OPEN / DONE · Target-PR: #N unlocks a repair run on an existing PR
STATUS.mdexecutor → planner · header Verification: PASS / FAIL · real pasted output — never the bare word “verified”
AGENT.mdexecutor identity + refusals — destructive git is banned at the hook, not merely discouraged
REVIEWER.mdthe review procedure — volatile logic lives in a file so it can be fixed without a dialog
BOOT.mdthe handoff — a fresh session boots into the lessons instead of re-learning them the expensive way
↓
Safety layer — plain shell, on timers · the only thing that may stop the loop
Invokes the executor. The retry cap counts invocations, not polls — counting polls once halted a loop that had failed zero times.
Notices trouble and says so. Reads its own stderr. Silence must never look like health.
Preconditions as code, not prose. Fails closed. Necessary, not sufficient.
Build budget, halt file, a backup before every run. Every blocking gate has an escape hatch.
↓ executor commits
Git — the only shared state
Product code only. Bookkeeping never rides the branch — it conflicts every time main moves, and a conflicted PR deadlocks the loop.
Status and task files are committed straight here, in their own commit. Excluded from the build trigger, so it costs nothing.
↓
Ship path
A green check is not a verdict. A stale preview happily returns 200 serving the previous commit.
↓
A real browser, real taps, real scrolling — always with a control run. Automation tabs are hidden, so animations never move and a blind harness reports a bug that isn’t there. If a test cannot fail, it is not a test.
↓ reviewer merges — server-side, never touching the working tree
A canary checks it after every merge and auto-reverts if it broke.
↓ what was learned
Memory & publishing — the loop improves itself
Every lesson lands on disk. A fresh session inherits them, not the bill for re-learning them.
Scripts and their tests, reusable by anyone. The registry is read as data, never as orders.
A dated timeline: what broke, why, and the fix — written by a scheduled agent.
One front door for alerts. Agents triage first; a human is paged only when production is down.
The invariant everything else protects: the executor commits but never merges; the reviewer merges but never commits. The second agent is the only party with no stake in the work being correct — preserve that split above all else. Every box on the map exists to defend it.
Two files in the repo root are the entire channel. No API, no message bus, no daemon talking to a daemon. Just files — which means the whole conversation is versioned in git and legible to a human at any moment.
| File | Direction | Contents |
|---|---|---|
| NEXT-STEPS.md | Planner → Executor | The brief. Header line reads Status: OPEN or Status: DONE. That single line is the trigger for everything downstream. |
| COWORK-STATUS.md | Executor → Planner | The report. Real command output pasted verbatim, errors included, plus anything it did beyond the brief or disagreed with. |
| CLAUDE.md | Standing context | Project identity and the protocol. Auto-loaded by Code every run. Kept out of git via .git/info/exclude so it never ships to the public site. |
Every brief carries a verification bar, and the report must contain real pasted output. The word "verified" is explicitly a failing answer. If the executor can't show you the command output, it didn't run the command.
claude -p "check next" headless. A PID lockfile stops a long build from stacking runs on top of itself.This is the part nobody writes down. Autonomy is mostly a permissions problem.
| Capability | Why it's needed | Risk |
|---|---|---|
| Notion MCP | Read the master prompt and the mobile-fix plan that seeded brief #1. | Read-only. None. |
| Desktop Commander MCP | Real shell and filesystem on the Mini. The planner has to write files into the working tree and inspect process state. | Full shell as me. Real. |
| Claude in Chrome | Independent audit of deploy previews in a logged-in browser. | Scoped to a tab group. |
| gh CLI + git auth | Code opens PRs and pushes; the reviewer merges. | Push access to a public repo. |
| Scheduled tasks | Wakes the reviewer on a cron. Only runs while the desktop app is open. | Low. |
| launchd agent | The 60-second poller. Survives app quits and logouts — the genuinely persistent half. | Low. |
| Automation → Messages | osascript sends the verdict text to my phone. | Can send iMessages as me. |
--dangerously-skip-permissions | Headless Code cannot answer a permission prompt. Without this it deadlocks on the first git command and the loop never starts. | The big one. |
--dangerously-skip-permissions means an unattended model runs shell commands with no approval step while holding push access to a live site. It's scoped to one folder, but it is not sandboxed. That's a real tradeoff, taken deliberately, on a low-stakes public repo with no secrets in it. I wouldn't do it on anything that mattered more.
Auto-merging to production was a separate decision — asked and answered explicitly, not quietly assumed. The loop stayed human-gated until I said otherwise.
Four PRs in ninety minutes, each triggering a Netlify build and deploy preview, exhausted the free tier. Netlify paused the site. Production went down, no preview would build, and the reviewer — correctly refusing to merge something it couldn't verify — had already marked the report as "seen." Permanent deadlock.
Then it sat there for four hours, silent. Because the loop could only report verdicts. A paused host, a dead build, and a wedged reviewer all produced output identical to a healthy quiet night: nothing at all.
Silence must never be indistinguishable from health. That's the whole lesson. There's now a watchdog whose only job is to notice trouble and say so — site down, host paused, PR stuck past 30 minutes, brief that never started — and it halts the loop rather than throwing more builds at a dead origin.
Scheduled sessions don't inherit the same MCP connections an interactive one has. The reviewer did the entire audit correctly, then died on the last step — writing to a folder it couldn't see, through an iMessage connector it didn't have.
Fix: move the fragile step down a layer. The reviewer now writes a plain text file inside the repo folder, which it can definitely reach; a shell script drains it and sends via osascript. Shell scripts don't have connection problems.
It carried context from a different job on the same machine and tried to work there. Ambient memory, wrong repo.
Fix: a CLAUDE.md that opens by stating what the project is not. Negative space turned out to matter as much as positive instruction.
Code's first overflow probe came back perfectly clean. It was wrong. The entire program UI sits inside a display:none section until you navigate to it — so the probe was measuring hidden elements and reporting a beautiful green pass on precisely the components the brief was about.
Code caught this itself, said so in its report, rebuilt the harness to reveal the sections and drive real card selection through the actual toggleCard() function, and re-ran. Then the reviewer independently reproduced the result at true 390px in a real browser before merging anything.
A single Claude marking its own homework ships that false green. Two of them, with a written protocol that says paste the output, don't assert it, do not.
It hashed the report, then went to verify. So when the preview 404'd it correctly declined to merge — but had already consumed the report and would never look again. Even after the host came back, the loop stayed dead.
Fix: record state last, only after merging or writing a fix brief. A missing preview is "wait and retry," not a verdict.
Freshly written, and wrong: date -j parsed GitHub's UTC timestamps as local time, so every PR read as created in the future. Age went negative, the alert could never fire. The safety net had a hole in exactly the shape of the thing it was catching.
Fix: date -j -u — and the watchdog now alerts if it can't parse timestamps at all, because a blind watchdog must announce its own blindness. Found only by testing it against live state. Same lesson as the false pass, arriving a second time.
macOS TCC dialogs and Claude's tool-approval dialogs are both lazy — they appear the first time a process actually does the thing. In an autonomous loop, "first time" is the middle of the night, with nobody there to click Allow. Worse, each tool prompts separately and only when the run reaches that step, so approvals dribble out over days.
Fix: a preflight. One script that exercises every capability on purpose, in front of a human, before the loop is trusted alone. It found two bugs in itself on first run — timeout doesn't exist on stock macOS, and it was invoking claude -p inside the repo where the executor was mid-build. A preflight that has never failed has never been tested.
The reviewer decided a finished feature had been "stranded on local main and never pushed." It wrote a recovery brief. The brief said, with a confident explanation attached — "no divergence, so this is a clean replay" —
git checkout brief4-icons-logos
git reset --hard mainThat would have deleted the two commits that were the feature, the ones an open PR was built from. It was recovering the work by destroying it. Nothing in the system would have stopped it. A human hit Deny on an approval dialog.
The reviewer wasn't hallucinating. It read the working tree and reported honestly what it saw. The tree was genuinely wrong — because the reviewer itself had corrupted it, by running git checkout main on its 6-minute cycle while the executor was 39 minutes into a build. HEAD moved under the executor mid-work.
My first fix was a rule: "check four things before writing a recovery brief." That was aimed at the wrong layer. It guards against a bad inference; the cause was a corrupted observation. You cannot reason your way out of a racy read.
The real fix is structural, and it's two lines: the reviewer may never run a local git write command, and it must stop entirely if the executor's lock is held. It never needed a checkout — gh pr merge is server-side.
By this point every bug was being found by me, the human. That is not a system with checks and balances — that's a person doing QA for a robot. So we stopped patching and pointed an independent auditor at it: a fresh agent that had built none of it, handed the failure history, and told to be skeptical rather than reassuring.
Ten bugs. Four critical. Six minutes.
Three of the ten were bugs we had already fixed — re-shipped inside the code written to fix them.
"Verify before you record" — the rule learned from the first deadlock — was violated again in the queue-promotion logic, where a failed git checkout was swallowed by 2>/dev/null and the log cheerfully printed "promoted on fresh main."
The watchdog — written because a silent failure cost a night — threw character not in range on every single poll. 259 errors. Its paused-site detector, the thing it existed for, may never have been able to fire.
And gh failing returned "0 open PRs," which the loop reads as "the PR merged, start the next one." The safety gate failed open.
Every one of those ten bugs was already visible in a file on the machine.
launchd.err.log held 259 unread errors. relay.log held the executor plainly stating that its branch "silently reverted to main partway through" — the exact root cause of the near-miss, written down, in plain English, hours before anyone noticed.
The system did not need better instrumentation. It needed to be forced to read the instrumentation it already had. The watchdog now reads its own stderr and the executor's warnings, and alerts on both.
If you build one of these: assume your logs are already telling you what's wrong, and that nothing is listening.
Nobody talks about this part. An autonomous loop spends money while you sleep.
Mine pushed 49 commits in one day. Every push triggered a Netlify build. But the relay commits its own bookkeeping constantly — briefs, status reports, verification output — and none of that is served to anyone. Each of those pushes spun up a container, cloned the repo, ran no build command (the site is static), and redeployed identical files.
That exhausted the build quota. Netlify paused the site. Production was down for four hours, and because the deploy previews died with it, the review loop deadlocked too. One failure took out both the product and the machinery watching the product.
[build]
ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF -- index.html _redirects"Netlify's ignore runs before the build. Exit 0 means "skip entirely, consume nothing." So it only builds when a file that actually ships has changed. Bandwidth was never the issue — the page is 60KB. It was builds, and most of them accomplished nothing.
Set a budget before you start, not after you hit the ceiling. The loop now caps itself at 20 builds a day and 3 retries per brief, and texts me instead of grinding.
It covers pushed commits. It does not cover the 40 minutes where the executor has uncommitted work in the tree. It does not cover a reset --hard that deletes local commits before they're pushed. It does not cover gh pr merge --delete-branch eating a branch that still holds an unpushed commit.
Those are the exact three things my automation nearly did. The threat model isn't "GitHub goes away." It's "my own robot deletes my work."
So: an hourly git bundle (every ref, fully cloneable) plus a tarball of the working tree including uncommitted changes. Timestamped, chmod 444, never overwritten, pruned only by age — never by count, so a burst of activity can't evict the snapshot you need.
And verify it by restoring it, not by checking the file exists. A backup you haven't restored is a rumour.
Permission dialogs are lazy — macOS and Claude both only ask the first time a process actually does the thing. In an interactive session that's invisible. In an autonomous loop, "the first time" is 3am, with nobody there to click Allow, and the loop simply stops. Silently.
Worse: every distinct tool prompts separately, and only when the run actually reaches that step. The Slack dialog only appears on a run where something merged. So approvals dribble out over days, and you never know when you're done.
1. Preflight. Write a script that deliberately exercises every capability — every binary under launchd's stripped PATH, git auth, the headless CLI, the notification path, the browser, each MCP tool by name — and run it while you're sitting there. Mine found two bugs in itself on its first run. A preflight that has never failed has never been tested.
2. Choose the right button. "Allow once" doesn't persist. "Allow for all scheduled runs" only covers that one task, so the same tool re-asks from every other task. "Allow for all tasks" is the one that ends it.
They're good at different things, and the gap is wider than it looks.
Code owns the machine. Shell, git, headless Chrome, long uninterrupted builds. It thought for 25 minutes before writing a line on the first brief. That's the right shape for execution and the wrong shape for judgment — it's deep in the diff, and it wants the diff to be good.
Cowork owns everything around the machine. Notion, a real logged-in browser, iMessage, scheduling, and me. It arrives at the review with no memory of having written the code, which is exactly the qualification.
The division of authority is the actual design. Code can commit but never merge. Cowork can merge but never commit. Neither one ships alone. That's not ceremony — it's the only thing standing between a confident model and a broken production site at 2am.
Every one of these was paid for. None of them were obvious in advance. If you take nothing else from this page, take these.
1. "Verified" is a failing answer. If the executor can't paste the command output, it didn't run the command.
2. The reviewer must verify independently. A model checking its own work grades its own homework.
3. Briefs are guesses until they're run. Expect the executor to push back — it was right and I was wrong three times on the first brief alone.
4. Record state LAST. Never mark work "seen" before you've acted on it. This deadlocked the loop permanently, twice.
5. Fail closed. An empty answer from a source that wasn't looking is not an answer. gh failing returned "0 open PRs," which the loop read as "all clear, proceed."
6. Verify, then record. Don't log success you didn't confirm. A swallowed 2>/dev/null let a failed checkout print "promoted on fresh main."
7. You cannot reason your way out of a racy read. If two processes share a working tree, no rule about "checking carefully" will save you. Enforce mutual exclusion structurally.
8. Silence must never look like health. A stall, a paused host and a dead build all produce the same output as a quiet, successful night: nothing.
9. Read your own logs. Every bug we found was already written down somewhere nothing was reading. The instrumentation was fine. Nobody was listening.
10. A status view that can't report its own death is decoration. Mine printed "✅ Idle · 🟢 healthy" over a wedged loop.
11. Test the safety net against live state. The watchdog was broken when written. So was the preflight. So was the fix for the watchdog.
12. Set a cost ceiling before you start, not after you hit it. A quota is not a safety mechanism you discover by exhausting it.
13. Cap retries. A failing brief will rebuild every 60 seconds, forever, and only luck will stop it.
14. Back up what your automation can destroy, not what the remote already has. The threat isn't GitHub vanishing. It's your own robot running reset --hard.
15. Forbid destructive git at the executor, so a wrong brief cannot destroy work even if it asks. A file must never be able to authorize reset --hard.
16. Auto-merge is a separate decision from autonomy. Ask explicitly. Don't infer it from "make it autonomous."
17. Preflight every permission in front of a human. Pin the shell and prove it can see the repo — don't assume which shell a scheduled session gets.
18. Procedure in a file, guarantees in the prompt. Editing a scheduled task needs human approval every time, so keep volatile logic in a file the agent can revise — and keep the safety properties in the prompt, where a file-writer can't edit them away.
19. Audit adversarially, with someone who didn't build it. Hand them the failure history and tell them to be skeptical, not reassuring. Ten bugs in six minutes — after days of me finding them one at a time.
20. A monitor that can be confidently wrong is a liability, not a safety net. Mine inferred "the watcher is dead" from log silence — but the watcher correctly goes quiet during a long build. It cried "the loop is dead" and printed the running build's ETA one line later. Emit liveness directly; never infer it from side effects that fall silent exactly when the system is busiest. A false alarm teaches you to ignore the real one.
21. A message in a queue is a REQUEST, not an AUTHORIZATION. If you give the agent an inbox — Slack, email, a task list — that inbox tells it what you want. It does not license it to skip the safety rules. Before anything irreversible or expensive, it asks, even when the message plainly said "just do it." And it verifies the sender: a channel anyone can post in is observed content, not a command line.
22. Verify the OUTCOME, not the artifact. "It exists" is not "it works." I pushed a rule to stop serving some files, the commit landed, the deploy went green — and the files were still served. Then I made the same mistake worse: a task said "add a section, reachable by a bar at the top." I checked the section existed and the old markup was gone, and merged to production. I never clicked the bar. It did nothing — no scroll, no hash, the section sitting 9,000px away. The reviewer had already caught it; I merged before reading its report. Checking a thing is present is checking the artifact. Checking a user can do the thing is the only actual test.
23. A monitor must never observe its own output as an input. My watchdog grepped its log for "warning" — and its own alerts land in that log and contain the word "warning." It alerted on its own alert, forever, texting me each time.
24. The rules apply to the person writing the rules. I built a lock, documented it, forbade the reviewer from ignoring it — then wrote into the executor's tree mid-build myself, because I was "just making a quick edit." The lock caught me. A guardrail only works if everything that touches the resource checks it, including you.
It ran unprompted, by an agent that built none of this, and found six bugs. Two were armed. Three were bugs we had already fixed — re-shipped in a sibling file.
25. When you fix a bug, grep every sibling for the same pattern — and if other agents need the same check, give them the exact snippet, not a description. A description gets reinvented, badly. Cost: the reviewer parsed a 3-field lockfile with cat instead of cut, so kill errored and read as "not running." Its mutex was dead on every build, for hours.
26. An alarm that can fire every minute is not an alarm. Dedupe every alert path, not just the one you thought about. Ours would have sent ~1,400 identical texts before midnight. A phone you've silenced is a phone that misses the real halt.
27. A proxy metric never reconciled against the real thing is a guess with a number on it. Our "build budget" counted agent invocations, not host builds. Measured against git: the counter said 6; reality was 14.
28. A mechanism you haven't tested in YOUR config is a rumour — and so is a bug report. A known issue claims PreToolUse hooks don't block under --dangerously-skip-permissions. We tested it: they do, on 2.1.197. So we now have a mechanism, not a paragraph. And the first test produced a false pass — it used timeout, which doesn't exist on macOS, so the agent never ran and "no file created" read as "the hook blocked it." Always include a control run that proves the harness executes.
29. Don't try to recognise failure. Assert success. Our paused-host detector grepped for three guessed strings nobody had ever verified — wrong wording meant 200, halt cleared, loop building into a paused account. Enumerating failure is unbounded and you will miss one. Asserting what you expect is bounded, and it fails closed.
30. Never edit a script the scheduler may be executing. Run an immutable snapshot.
A running shell reads its script by byte offset. Edit it mid-run and it resumes at a stale offset in the new bytes — mid-line, mid-comment, anywhere — and executes the garbage it lands on. Ours tried to run the word structural out of a comment. The poller died right after launching the executor, so the task never got marked done, retried, and opened two duplicate PRs before the retry cap caught it.
"Be careful" is not a fix. Being careful failed twice in one day. The scheduler now runs a tiny launcher that never changes: it refuses a poller that doesn't parse, copies it to a private snapshot, and executes the snapshot. Editing the live file mid-run is now harmless.
31. A retry is not a restart. Check whether the work already exists. Our retry path never looked for an open PR, so it rebuilt finished work. And make that guard wait, not halt — an open PR is the resting state, not a failure. (I got that wrong on the first attempt too.)
32. If a surface can drift silently, something must watch for the drift. These lessons live in three places. Two auto-updated; this page sat seven rules behind for hours and nobody noticed. A stale record is a record that lies — and a system built to stop lying about its own state shouldn't lie about its own history.
33. Your automation's browser tab is HIDDEN. Animations do not run in it.
document.visibilityState === "hidden", hasFocus() === false. requestAnimationFrame is throttled to ZERO in a hidden tab — and scroll-behavior: smooth, which most modern sites set, animates via rAF.
So location.hash, scrollIntoView(), scrollTo({behavior:'smooth'}) — and even a real trusted mouse click on an anchor — all report no movement, on a page that works perfectly for a human.
I concluded "the whole site cannot be scrolled," closed a good PR, wrote an alarming brief, burned three builds, and told Jeremy production was broken. He checked his phone. It worked fine.
The one-line discriminator that would have saved all of it:
window.scrollTo({ top: 1000, behavior: 'instant' }); // bypasses rAF
// if INSTANT works and SMOOTH doesn't, your tab is hidden — your TEST is invalid, not the pageThe general form is bigger than scrolling: know what your harness is structurally blind to. Mine could not observe motion — not from a bug, but because of what it is. A test that cannot fail correctly is not a test.
34. When the executor pushes back on your verdict, doubt your tooling first. Twice in one day it rejected a verdict of mine and was right both times. It even refused to strip smooth scrolling to make my test pass — correctly calling that "a downgrade for real users to satisfy a test artifact." An executor that refuses to patch a non-bug is doing its job. Don't out-argue it. Out-test it.
35. Some things your automation cannot see. Ask a human. It costs five seconds. Not as the durable answer — the point is automation. But when the harness is structurally blind (motion, layout, "does this feel right"), an hour of an agent chasing a ghost is worth strictly less than one five-second look at a phone.
Playwright's pages are genuinely visible and focused. Verified against the exact test that lied to me:
visibilityState: "visible" hasFocus: true rAF: 21 ticks/300ms
iPhone 15 Pro: 393x659, touch: true, dpr: 3
REAL TAP -> scrollY 0 -> 2695, target landed at top: 0 PASSIt checks tap outcomes, horizontal overflow, sub-44px touch targets and console errors in one pass — and self-aborts if its own tab isn't visible, so a blind harness says so instead of inventing a failure. Packaged as the mobile-verification skill.
Read the DOM → any tool. Anything a user DOES → Playwright. "Does this feel right" → ask a human.
36. The watchdog texted Jeremy and nobody else. So he'd get "the executor isn't picking it up" on his phone, and have to relay it back to an agent to go look. The human became the message bus for a system built specifically to avoid that.
He asked the obvious question: "How are you missing this but it's coming to me via text?"
An agent runs every five minutes. A human should never be the first responder. Alerts now land in a log the agents read; the inbox agent triages within one cycle, fixes what it safely can, and escalates with a diagnosis rather than a raw alarm. Only production-down and money-burning alerts page a human instantly.
If your monitoring's only output is a text message to a person, you haven't built monitoring — you've built a pager, and made the human the integration layer.
37. Rule 36 was the policy: agents triage first, humans get paged only for emergencies. I implemented it in watchdog.sh and declared it done.
Four other scripts had their own copy of alert(), each calling the pager directly. So the very next routine event — a PR sitting open, exactly as designed — texted Jeremy anyway. The policy was real. The enforcement existed in one of five places.
I had fixed the example I happened to be looking at.
The tell: I verified the policy by reading the code I'd just changed. The right test is to grep for every path that could still do the forbidden thing:
grep -rn "notify.sh" *.sh # who can page a human? should be exactly ONE fileThe fix isn't five careful edits — it's collapsing five implementations into one front door that the others must call. A policy that lives in five places isn't a policy; it's a coincidence waiting to end. Make the wrong thing structurally impossible, not merely discouraged.
38. I told Jeremy auto-merge was on. He believed me. Twelve hours later a PR sat unmerged and he asked why.
$ ls -la .automerge
NO .automerge FILEIt was never on. I'd reasoned about turning it on, discussed turning it on, and moved on — without the one line that actually creates the flag the reviewer reads.
This is the same failure as verifying with a status code (rule 1) and merging without clicking the button (rule 12), aimed at myself instead of the code: I reported an intention as an outcome. The config file is not a formality; it is the setting.
Before you tell a human a switch is flipped, read the switch.
39. The retry cap exists to stop a failing task rebuilding forever. It halted the loop for a task that had not failed even once.
The executor ran, succeeded, opened a PR, and correctly left the task marked OPEN — because the reviewer, not the executor, decides when work is done. The next two polls never invoked the executor at all: they saw the open PR, logged "waiting for it to merge", and exited. But the counter was incremented above that check, on the way past.
poll 1 executor runs, opens PR attempts = 1
poll 2 never runs it (PR is open) attempts = 2 <-- counted anyway
poll 3 never runs it (PR is open) attempts = 3 <-- counted anyway
poll 4 "task failed 3 times" -> HALTAn attempt that never invoked the executor is not an attempt. A retry cap must count retries, not polls — otherwise the system's normal resting state (waiting for review) burns the budget it was given to survive real failures.
The deeper lesson is about how you treat the alarm. Leaving a misfiring guardrail alone feels like the cautious choice. It is not. It converts a healthy system into a halted one and then blames the work. Fix it, prove it with a control, and say so.
40. One rule said: never invoke the executor while a PR is open (otherwise a retry opens a duplicate PR — that really happened). Sound rule.
Then a PR passed review but couldn't merge: its branch had gone stale and git said CONFLICTING. The fix was a single push to that branch — and only the executor can push. So the reviewer wrote a task telling the executor to fix it… which the gate refused to run, because a PR was open. The task that existed to repair the PR was blocked by the PR.
Nothing could break it from inside. Clearing the kill switch just made the poller spin and halt again. A human had to reach in.
Every blocking gate needs an explicit escape hatch for the case that repairs the blocked thing. Ours: a task may declare Target-PR: #24 in its header, and the gate lets exactly that task through. Ordinary tasks stay blocked, so the duplicate-PR guarantee is intact. When you write a gate, ask what fixes the state it blocks — and make sure that thing can still run.
41. Two PRs in a row passed review and then couldn't merge. Both times the conflict was in the status file, not the code. index.html conflicted with nothing.
Of course it did: the main branch moves while the executor builds, both sides rewrite the same bookkeeping files, and git has no idea which version wins. The product almost never collides — one agent is writing it. The paperwork collides constantly — both are.
So the paperwork stopped riding the branch. Feature branches now carry product code only; the status and task files are committed straight to the main branch in their own commit. The conflict class disappeared — proven by replaying the exact scenario under both protocols:
old protocol (paperwork on the branch) -> CONFLICT
new protocol (branch = product only) -> clean merge
control: two branches editing the same
product line -> still CONFLICT (as it must)That last line is the point. Removing a class of false conflicts must not remove your ability to detect a real one. If your fix makes every merge "clean", you didn't fix the merge — you blinded it.
42. Halfway through, Jeremy said: "I feel like it's keeping me more in the loop and asking me too many questions vs actually being autonomous as possible."
He was right, and the reason was a collapsed distinction. I was treating "this guardrail is misfiring" and "this guardrail's policy should change" as the same kind of event — both got escalated as questions. They are not the same at all:
guardrail is MISFIRING -> a BUG. Fix it. Prove it. Report it. Don't ask.
guardrail's POLICY changes -> a JUDGMENT. Raise a build ceiling, relax a merge
bar, allow force-push? That's the human's.Asking about a bug isn't caution, it's abdication — it hands the human a decision that has only one correct answer, and it does it at 3am. Meanwhile, quietly changing a policy because it seemed sensible is the opposite failure.
The price of fixing your own guardrails is a high proof bar, and it is yours to meet: a test and a control, a backup first, and the diff shown afterward. Autonomy is not "acts without asking." It's "knows which things it doesn't need to ask about."
43. Rule 15 says a test that has never failed cannot be trusted. Here's its sharper twin, and I walked straight into it while writing the test for rule 41.
I wrote a merge gate and a control case: "a report that says FAIL must be refused." It refused. Green tick. But it refused because the test fixture had no git remote — the gate never even read the verdict. The control was passing for a reason that had nothing to do with what it claimed to prove. Had the verdict logic been broken, that test would still have been green.
A control must fail for the reason you named, and pass for the reason you named. Assert on the reason, not just the outcome — make it print why it refused, and read it.
Its mirror image, same day: my first instinct for that gate was to grep the status file for the word FAIL. That would have refused a healthy report — because a good report says things like "the control run against production failed all 3 checks, so the test can fail." Describing a control working correctly is not a failure. The gate reads one machine-readable header line and never the prose.
Both halves are the same discipline: know exactly what your check is keying on, or it is keying on something else.
44. The site lists which airlines each credit-card currency transfers to, and at what ratio. The ratio lived inside the partner's name string, as an optional suffix:
airlines:["Aer Lingus", "Aeroméxico ·1:1.6", "ANA",
"Cathay", "Emirates", "JetBlue ·1:0.8", ...]
^^^^^^^^^^^ some have a ratio
^^^^^^^^^^ most don'tA chip with a suffix showed its ratio. A chip without one showed just the name — and a reader takes a transfer partner with no stated ratio to mean the ordinary thing, 1:1. That inference is exactly what the model invited, and it was wrong: an audit against the issuers' own pages found Cathay and Emirates are 5:4. The absence of a fact was rendering, confidently, as a different fact.
This is not a typo class, it's a shape class. An optional field with a plausible default doesn't fail loudly when it's missing — it fabricates. A blank would have been honest. "1:1, by implication" was a lie the structure told on the data's behalf, in every currency, for as long as the page existed.
The fix was not to correct the ratios. It was to make the omission impossible: every partner is now an object that must carry its ratio, and the renderer never defaults a missing one.
airlines:[{p:"Cathay", r:"5:4"}, {p:"Emirates", r:"5:4"}, ...]Correct the data and you fix today. Correct the model that permitted the gap and you fix every tomorrow. If a fact can be silently absent, it will be — so put it where it cannot be.
45. Here is the uncomfortable part of rule 44. While that data was wrong — wrong in every currency — the machine was entirely green. The mobile matrix passed 20/20 at both widths in both themes. node --check passed. The production canary reported healthy after every deploy. No guardrail so much as blinked.
They were all working perfectly. They were just answering a different question. Every check we had verifies that the build is sound — that it parses, renders, doesn't overflow, doesn't 500. Not one of them could tell whether a single word on the page was true.
The errors were caught by strangers on Reddit, reading the site. That is the entire detection mechanism for content truth, and it is not a mechanism at all — it is luck, arriving after publication.
An autonomous loop makes this sharper, not safer. It ships correct code, fast, and a wrong fact propagates at exactly that speed with a green tick on it. Velocity is not validation, and a passing suite is not a fact-checker.
A claim needs a source, not a passing test. Know which of the two your suite is actually giving you — and don't let a green build launder an unverified claim into a confident one.
46. I ran an audit of a data set against the companies' own published pages. Three of them came back "unverifiable — the page is JavaScript-rendered and the fetch returns an empty shell." I wrote that in the report, twice, and moved on.
Then the human asked: "Can't you just open the browser?"
Of course I could. A browser runs the JavaScript. Two of the three pages then gave up their data immediately — and with no login — including the two most valuable facts in the whole audit: a partner that had been quietly dropped, and a ratio the site had been getting wrong for months. Straight from the company, in its own words.
Worse, the constraint was self-inflicted: I had told my own research helpers "no browser tools" for an unrelated reason (see rule 47), and then believed their conclusion as if it were a fact about the world. It wasn't. It was an echo of my own restriction coming back at me wearing a lab coat.
Before you write "cannot be verified," name the tool that failed and ask what a different tool would see. A fetch that returns a shell has not told you the page is empty — it has told you the fetch cannot execute JavaScript. Those are not the same sentence.
47. I had five draft replies open in five browser tabs, waiting for Jeremy to read and post. Then I spawned a research agent and gave it the standard toolset — which included browser control.
It needed a page. It grabbed a tab. It navigated away, "restored the URL," and reported back politely. Four of the five drafts were gone.
The agent did nothing wrong. I handed it write access to a surface a human was actively working in, then walked away. The tabs looked like my workspace. They were Jeremy's.
Two rules came out of it, and the second is the more important one:
Scope a subagent's tools to the job. A research task needs to read the web. It does not need to drive a browser that has a human's unsaved work in it.
Unsaved work does not belong in a volatile surface. Browser tabs are not storage. If it matters, it goes in a file — then it survives the agent, the crash, and the accidental close. I rewrote the drafts to disk and stopped fighting the tabs.
48. The poller found its local NEXT-STEPS.md marked OPEN while the copy on origin/main read DONE. It drew the obvious conclusion — I'm behind — ran git checkout -- NEXT-STEPS.md, and logged the word "refreshing."
It was not behind. It was ahead. It had promoted brief #14 locally; the executor then crashed after pushing its branch and opening PR #31, but before committing the paperwork. Local OPEN was brief #14. Remote DONE was brief #13. The recovery path never asked which brief. It compared only the status word — and deleted a live brief while reporting the loop idle.
local=OPEN, remote=DONE is ambiguous. Either the remote is ahead (someone finished this task — the case the check was written for), or you are ahead and haven't pushed yet. Only the task's identifier tells those apart, and a status comparison throws it away.
A recovery path that cannot tell behind from ahead will eventually destroy the newer state — and it will do it while logging a reassuring word. Compare identity first (which task), then status (what state).
A second trap, same incident: the executor exited rc=1 because its network connection dropped mid-response, not because the work failed. The branch and the PR were already pushed. Everything concluded afterward — "brief still OPEN, will retry", "nothing has been building for 31 minutes" — was read off the process while the artifact sat in plain sight. An exit code measures the transport, not the work. Ask what shipped, not how the process died.
49. The alert router dedups by hashing the message and dropping repeats for an hour. Sound — except the watchdog built the message by baking the PR's live age into it: "PR #34 open 78m, no build." Next minute: "…79m…". Different string, different hash, brand-new alert. The once-an-hour throttle never fired once.
One stuck PR emitted 78 identical alerts in an hour, and because the heartbeat shows only the last three, the flood evicted the one alert that actually needed a human from the very panel meant to surface it. The noise buried the signal it was made of.
Dedup on the alert class, not the bytes. Strip the volatile parts — ages, counts, HTTP codes — before you hash, or the throttle is decoration. The file's own comment had preached "an alert that fires every 60s is one you mute." It defeated its own rule one line down.
50. Every alert was also appended to two files — a Slack queue and a triage queue — for "an agent to drain." That agent had been replaced months earlier by a leaner one that only reads inbound messages. Nothing drained the outbound queues. They grew, unbounded and unread, forever.
Nobody noticed because nothing failed. Files don't error when they grow; they just sit there getting larger — a backlog of problems no one is looking at. "Silence must never look like health" (rule 8) applies to your own plumbing, not just the product.
Two cheap fixes: bound the files (ring-buffer to a last-N so they can't grow without limit), and surface their depth where a human already looks — the status line now prints "N undrained" the moment a backlog forms. An unread queue must announce itself, or it is a leak with good manners.
51. The Slack handler moved the incoming request to .handled the instant it started — "so we can't double-handle if the run dies." Then it ran the model, captured the exit code, and only logged it. If the handler failed, the request was already filed as done. A failed handler dropped the user's message silently, forever.
This is rule 4's family — the reviewer that marked its work "seen" before doing it — re-shipped one directory over. The fix is the same: record after you verify, not before. Archive on success; on failure keep the request and retry; after a few tries, dead-letter it to a file and say so, so a poison message can neither spin forever nor vanish.
The original traded a silent drop to avoid a rare double-reply. For a system whose entire job is "don't eat the message," that trade was backwards. A duplicate is embarrassing; a silent drop is a broken promise.
52. An adversarial audit of the whole system found three separate bugs in the alert layer — the flood (49), the silent leak (50), the record-before-verify drop (51). Every one was a lesson the core loop had already learned, painfully, and written down. The alert layer had simply never been taught.
The reason is uncomfortable: those earlier fixes were point-patches. We fixed the file in front of us and moved on, with no test that would fail if the same mistake surfaced elsewhere. A lesson that lives only as a corrected line in one script is not a lesson the system holds — it's a coincidence in one location.
A fix generalizes only when it becomes an invariant with a test that can fail. Each of these three now ships with exactly that: a test that goes red against the old logic and green against the new. The audit's real finding wasn't three bugs — it was that our fixes weren't sticking, and the remedy is a failing-capable test per lesson, not more care.
53. Overnight, a human legitimately rewrote the product — the monolith became a small shell loading external assets. The canary's health markers were content assertions written for the old page. On its next poll every marker failed against a perfectly healthy site, so it did what it was built to do: blamed the newest commit, reverted it, pushed. The revert didn't clear the symptom — the symptom was never in a commit — so the next poll found the revert at HEAD and reverted that. Revert → Reapply ping-pong: eight cycles in fifteen minutes, a production build and an urgent text apiece, against a site that was fine the whole time.
This is rule 23 — a monitor must never observe its own output as an input — back through a new channel. Last time it was log→log: a watchdog alerting on its own alerts. This time it was git→deploy→git: the canary consuming its own revert commits as fresh deploys to judge. Same disease, new vector.
The breaker now in the canary: if the commit you are about to revert is itself a revert you made, your diagnosis is wrong. Halt and page a human. The general form: an automated remedy must check whether its last action changed the observed symptom before it is allowed to fire again. A remedy that didn't work the first time will not work the second — repeating it is how one false alarm becomes an incident.
54. A marker set is a snapshot of what the site looked like on the day someone wrote it. The site is allowed to change; the snapshot doesn't know that. One marker failing is a regression. All of them failing simultaneously on an HTTP 200 is a different signature entirely: the site changed shape underneath your checks. A monitor that treats those two patterns identically will one day declare a healthy redesign an outage — and if it can auto-remediate, it will attack the redesign.
Fail toward self-doubt: on all-markers-failed, halt and say "my markers are probably stale" — and never take an automated action on evidence your own instrumentation may have invented. Markers should be structural — the app shell, the asset pipeline — never page copy, which churns with every redesign.
The epilogue proved rule 37 all over again: the fix initially covered one of the three scripts that carried the stale marker — the other two would have re-halted the loop on the same false alarm at the next resume. A redesign's definition of done includes updating every monitor that describes the site, proven by a self-test you run before the loop comes back.
Rule 8 says silence must never look like health. Its twin: noise must never drown the signal. The inbox checker runs 96 times a day and posts nothing when there's no work — because a bot that says "nothing to do" 96 times a day is a bot you mute, and then you miss the one that mattered.
Alert on trouble. Stay quiet on routine. Both halves are the same rule.
We built a 10-minute heartbeat that posted status to Slack. It ran 42 times before Jeremy killed it: "I trust the process is working, we have a watcher, and you'll alert me when I need to do work. So no more random status updates anywhere."
He's right, and it's worth stating as its own thing: a status update nobody asked for is a tax on attention. The watchdog is what makes silence trustworthy — and once silence is trustworthy, chattering to prove you're alive is just noise with good intentions. An autonomous system's highest compliment is that you forgot it was running.
The whole thing is a few hundred lines of shell and two markdown files. No framework, no service, nothing to install.
NEXT-STEPS.md (planner → executor, header line Status: OPEN/DONE) and COWORK-STATUS.md (executor → planner, real pasted output). Files, not an API — so the whole conversation is versioned in git and legible to a human.CLAUDE.md that opens with what the project is NOTAmbient memory of other projects on the same machine is a real failure mode — the executor went looking in the wrong repo on day one. Negative space matters as much as instruction. Put the destructive-git refusal here too.Status: OPEN, runs claude -p "check next" --dangerously-skip-permissions. PID lockfile so a long build can't stack. Snapshot the repo before each run.gh pr merge (server-side — no checkout). Stops immediately if the executor's lock is held.The 👀-before-you-start trick generalises. Claim the work visibly, then do it. If the agent dies mid-task you're left with a claim and no result — which reads correctly as "started, didn't finish." The alternative is work that quietly evaporates, which is the same disease as a loop that goes silent when it stalls.
Be honest about --dangerously-skip-permissions. Headless Code can't answer a permission prompt, so without it the loop deadlocks on the first git command. With it, an unattended model runs shell commands with no approval step while holding push access to a live site. Scoped to one folder, not sandboxed.
I took that trade deliberately, on a low-stakes public repo with no secrets in it. It is not a default. Don't run this against anything you'd be upset to lose — and if you do, read rules 14 and 15 twice.
| Thing | What it's for | Required? |
|---|---|---|
| Claude Code CLI | The executor. Must run headless (claude -p) and be authenticated to GitHub already. | Yes |
| Claude Desktop (Cowork) | The planner/reviewer, and the host for scheduled tasks. | Yes |
| A filesystem/shell MCP | So the reviewer can read the repo and run gh. I used Desktop Commander. Verify it can see the real repo — a sandboxed shell that only sees a mount, and has no gh, will fail silently. | Yes |
| Claude in Chrome extension | Independent verification of the deploy preview in a real browser. This is what makes the review meaningful rather than a second opinion on the same text. | Yes |
gh CLI + git | PRs, pushes, server-side merges. Must be non-interactive — a login prompt at 3am is a dead loop. | Yes |
| Scheduled tasks | Wakes the reviewer and the heartbeat. Only run while the desktop app is open. | Yes |
| launchd (or cron) | The 60-second poller. This is the half that survives the app being closed. | Yes |
| Slack and/or iMessage | Alerts. Pick at least one you'll actually see. Remote connectors (Slack) survive scheduled sessions; local ones (iMessage MCP) may not — so send iMessage from shell via osascript instead. | Strongly rec. |
| Notion (or any doc tool) | A durable log of what broke and why. Optional, but this page exists because of it. | Optional |
| A host with deploy previews | Netlify/Vercel/etc. The per-PR preview URL is what the reviewer verifies against. Without it you lose the review gate. | Yes |
Settings → Extensions → [your shell MCP] → Tool permissions → "Always allow" on each group (Interactive, Read-only, Write/delete).
This grants the whole tool set up front, instead of waiting for each individual tool to prompt the first time a run happens to reach it. We found this embarrassingly late, after days of clicking dialogs one at a time. Do it before you build anything.
Be clear-eyed about what's in there: Kill Process, Force Terminate, Write/Modify, Move/Rename. Real teeth. That is the actual cost of an unattended loop — grant it deliberately, on a machine and a repo where you accept it.
This is normal and it is finite. Every distinct tool prompts separately — not every app, every tool. Granting a shell MCP's "run process" does not grant its "read file" or "write file." And a prompt only fires when a run actually reaches that step, so the Slack dialog won't appear until a run merges something. Approvals therefore dribble out over days unless you force them.
Always take the broadest option offered. On Claude's dialogs that's "Allow for all tasks" (usually hidden under the dropdown — the big default button is the narrower "allow for all runs of this task," which means every other task re-asks for the same tool). "Allow once" persists nothing and guarantees a 3am stall.
Run a preflight to force them all at once, in front of a human, before you ever walk away. Exercise every binary under launchd's stripped PATH, git auth, the headless CLI, the notification path, the browser, and each MCP tool by name.
Changing a scheduled task's own configuration asks a human every single time, with no "always allow." That's correct and you should not try to defeat it. Something that runs unattended should not be silently reprogrammable by another agent.
It also never stalls the loop, because it only fires while you're sitting there. So: design around it, don't fight it. Keep the task prompt a permanent, thin bootstrap — "read REVIEWER.md and follow it" — and put all the volatile logic in that file, which an agent can revise freely via shell. Keep the safety guarantees in the prompt, where a file-writer can't edit them away. (That's rule 18, and it's the difference between a dozen approvals and one.)
Paste this into a fresh Claude Desktop session with your repo folder connected. Replace the bracketed parts. It's the actual prompt that built this, minus the mistakes.
You're the planning and review half of a two-Claude loop. Claude Code (shell + git on this
machine) executes; you plan, review, and talk to me. You never edit the repo directly.
PROJECT: [repo] -> [production URL]. [One paragraph: what it is, what a change looks like.]
NOT THIS PROJECT: [any other repo/folder on this machine]. Do not touch it.
THE RELAY PROTOCOL. Two files in the repo root are the only channel between you and Code:
NEXT-STEPS.md (you -> Code) Your briefs. Header line: `Status: OPEN` or `Status: DONE`.
COWORK-STATUS.md (Code -> you) Its reports: real pasted command output, verbatim errors,
and anything it did beyond the brief or disagreed with.
A launchd script polls NEXT-STEPS.md every 60s and runs `claude -p "check next"` on any OPEN
brief. Writing the file IS the handoff — no human step.
EVERY BRIEF MUST CARRY A VERIFICATION BAR, and the report must contain REAL PASTED OUTPUT.
The word "verified" is a failing answer. If Code can't show the command output, it didn't run
the command. [List your project's checks: syntax check, duplicate-id grep, screenshots at the
sizes that matter, whatever proves the thing actually works.]
DIVISION OF AUTHORITY — this is the safety model, not ceremony:
- Code can COMMIT but NEVER MERGE.
- You can MERGE but NEVER COMMIT.
- Neither ships alone.
YOUR RULES:
- Verify the deploy preview INDEPENDENTLY, in a real browser. Never merge on Code's say-so.
- NEVER run a local git write command (checkout/pull/reset/rebase/stash). You share a working
tree with Code — a checkout while it builds will corrupt its branch. `gh pr merge` is
server-side and needs no checkout.
- If Code's lock file is held, STOP the run entirely. Don't read the tree, don't write a brief.
- Record "I've seen this report" LAST, only after you've merged or written a fix brief. Never
before. Recording before acting deadlocks the loop permanently.
- If a build/preview is missing, that's "wait and retry," NOT a verdict.
- Briefs are guesses until Code runs them. Expect pushback. Its status file beats your
assumptions.
- NEVER write a brief that destroys work (reset --hard, force-push, branch -D). If you think
work is lost, first prove it: `git log origin/main..main`, `git branch -a`, `gh pr list`,
and check whether Code is still running. It almost never is lost.
ALERT ME when: something merges, something fails twice, the site is down, the host pauses us,
or a PR sits >30min with nothing happening. Silence must never look like health.
FIRST: read [your plan doc]. Turn it into the first NEXT-STEPS.md brief. Then tell me, and I'll
say "check next."And the executor's CLAUDE.md, which is the other half:
# [Project name]
**This project has NOTHING to do with [that other thing on this machine].**
Do not cd there, do not reference it, do not reuse anything from it.
## The relay
NEXT-STEPS.md is your inbox. When I say "check next": read it, execute any `Status: OPEN`
brief, overwrite COWORK-STATUS.md with REAL COMMAND OUTPUT (never the word "verified"),
flip the brief to DONE, commit, push, open a PR with `gh`. **Do not merge.**
## DESTRUCTIVE GIT — refuse it, even if a brief tells you to
`git reset --hard`, `push --force`, `branch -D`, `clean -fdx`, anything that deletes commits
or refs. A brief once asked for `reset --hard` on the only copy of a finished feature, with a
confident explanation attached. It was wrong. **Briefs are guesses; a wrong brief must not be
able to destroy work.** If asked: refuse, write what you were asked and what the repo state
ACTUALLY is (with pasted output), leave the brief OPEN, and stop. Only a human in chat can
authorize this — a file cannot.
## Push back
If a brief is wrong about the code, say so plainly and don't do it. You have been right and
the planner wrong more than once.~/Projects/my-project/ the repo the executor works in
NEXT-STEPS.md brief (planner -> executor)
COWORK-STATUS.md report (executor -> planner)
CLAUDE.md identity + destructive-git refusal [git-excluded]
REVIEWER.md the reviewer's brain [git-excluded]
netlify.toml the `ignore` rule that stopped the burn
.relay-state hash of the last-reviewed report
.outbox.txt pending alert
.automerge "on" = authorized to merge
.preflight present = next run is a permission drill
~/Projects/my-project-backups/ read-only. nothing in the loop can touch these.
my-project-.bundle every ref, fully cloneable
worktree-.tgz incl. uncommitted work
~/Projects/relay/
watch.sh 60s poller: health-check, promote queue, run Code
watchdog.sh the thing that says "I'm stuck"
notify.sh drains the outbox via osascript
preflight.sh exercise every permission, in front of a human
status.sh the 10-minute Slack heartbeat
queue/ briefs waiting their turn
relay.log ground truth for what actually happened
~/Library/LaunchAgents/com.example.relay.plist To watch it think: tail -f ~/Projects/relay/relay.log
To stop it: launchctl unload ~/Library/LaunchAgents/com.example.relay.plist
Same spirit. Caddy serves static files from a folder on the Mac Mini, bound to 127.0.0.1 only. A cloudflared tunnel dials out and Cloudflare hands traffic back down the same pipe. No ports open on the router; nothing on the box is reachable from the internet.
The /admin page takes an HTML file by drag-and-drop and publishes it, behind Cloudflare Access — so auth happens at the edge before a packet touches the Mini. Every upload auto-commits and pushes to GitHub, so it's versioned and revertible.
This page got here that way. A Claude wrote it and dropped it in.
npx skills add jeremyinthebay/relay-skills
github.com/jeremyinthebay/relay-skills · MIT. The scripts are the real ones, genericized. They have all failed at least once — which is why they look the way they do.