The forge's own release journey is not rate-limited by the forge and does not spend the strangers' daily allowance #12221

The forge's own release journey now carries a key that only the running boot holds. With it, starting a forge skips the strangers' per-minute plan limit and their daily allowance in src/spawn/door.ts. A good release should no longer show as unproven because the forge rate-limited its own probe and sent it to /?start=rate.

• src/release/prober.ts (new): the key is an HMAC of the per-boot hook secret, sent in an x-forge-prober header and compared in constant time. It is never the hook secret itself, so a leaked header can't open the internal listener. An IP address or user agent is never accepted as proof.
• src/release/journey.ts: takes an optional proberKey and sends it only to the host's own origin, never to the throwaway forge it creates.
• src/release/prove.ts and src/main.ts: pass this boot's key to the journey.
• src/spawn/door.ts: a request with the right key is treated like a paid order. It skips the per-minute plan limit and the daily check, and its spawn is not counted against the allowance.

test/release-prober.test.ts covers the guard against a forged exemption:

• With the strangers' daily allowance spent, a request with no key, a made-up key, the hook secret itself, or another boot's key all still land on /?start=rate. The right key starts a forge and leaves the count unchanged.
• With the per-minute plan limit spent by a forged key, the right key still gets through.
• The journey sends the key to its host and never to the new forge.

Two of these tests fail when the change to door.ts is reverted.

What to look at: the key only matches when the process that answers the public address is the one doing the proving. If an older process is still serving that address, the walk is rate-limited as it was before this change, so this makes things no worse in that case. Other stranger limits outside door.ts (for example the per-minute limit on the ready check, if there is one) are left alone, as the issue scoped it.

How it was checked: bun scripts/gate.ts and bun x tsc --noEmit pass. I ran the new test with release-journey, release-prove, home-start-forge and spawn-anon: 66 pass, none fail. scripts/fast.ts named 2045 test files for this diff, so I chose those five rather than run them all.

🤖 Generated with Claude Code

Closes #12169

The forge's own release journey now carries a key that only the running boot holds. With it, starting a forge skips the strangers' per-minute plan limit and their daily allowance in src/spawn/door.ts. A good release should no longer show as unproven because the forge rate-limited its own probe and sent it to /?start=rate.

• src/release/prober.ts (new): the key is an HMAC of the per-boot hook secret, sent in an x-forge-prober header and compared in constant time. It is never the hook secret itself, so a leaked header can't open the internal listener. An IP address or user agent is never accepted as proof.
• src/release/journey.ts: takes an optional proberKey and sends it only to the host's own origin, never to the throwaway forge it creates.
• src/release/prove.ts and src/main.ts: pass this boot's key to the journey.
• src/spawn/door.ts: a request with the right key is treated like a paid order. It skips the per-minute plan limit and the daily check, and its spawn is not counted against the allowance.

test/release-prober.test.ts covers the guard against a forged exemption:

• With the strangers' daily allowance spent, a request with no key, a made-up key, the hook secret itself, or another boot's key all still land on /?start=rate. The right key starts a forge and leaves the count unchanged.
• With the per-minute plan limit spent by a forged key, the right key still gets through.
• The journey sends the key to its host and never to the new forge.

Two of these tests fail when the change to door.ts is reverted.

What to look at: the key only matches when the process that answers the public address is the one doing the proving. If an older process is still serving that address, the walk is rate-limited as it was before this change, so this makes things no worse in that case. Other stranger limits outside door.ts (for example the per-minute limit on the ready check, if there is one) are left alone, as the issue scoped it.

How it was checked: bun scripts/gate.ts and bun x tsc --noEmit pass. I ran the new test with release-journey, release-prove, home-start-forge and spawn-anon: 66 pass, none fail. scripts/fast.ts named 2045 test files for this diff, so I chose those five rather than run them all.

🤖 Generated with Claude Code

The forge's own release walk is no longer treated as a stranger by its rate limits. Each boot derives a prober key from the hook secret (src/release/prober.ts) and sends it only to its own host when it walks the release journey (src/release/journey.ts). It's passed to that walk in src/release/prove.ts. In src/spawn/door.ts, a request that carries the key skips the stranger rate limits and the daily allowance. The key is compared in constant time, and a missing or forged key is handled like any other stranger.

This push fixes the failed check: four new comment lines broke the gate's 100-column rule, and they are now rewrapped. Nothing else changed.

Things to look at:

• isProber in src/release/prober.ts, which compares the header against the key.
• The counted check in src/spawn/door.ts, the one place the key changes what a request is allowed.

Checks run before pushing: bun scripts/gate.ts and bun x tsc --noEmit pass. The prober, journey, prove and door tests pass (338 tests in 49 files). scripts/fast.ts picked nearly the whole suite for this comment-only change; that run was still going in the background at push time and hasn't reported, so the forge's check is the full run.

🤖 Generated with Claude Code