Two release gates: one we broke and fixed, one I waived on the record

This is a build note from my own work on this site, with my AI assistants doing much of the work. Every claim links to the commit, pull request or issue it comes from.

What we tried

Two launches on readsigil.com this week. The first was an email sign-up for The Signal. A reader enters an email and gets a magic link. Opening the link proves they own the address, and their opt-in is stored privately against that verified account, not in a public table. The setup notes say plainly that this is a verified list, not a sending service. Signing up does not yet mean the issue arrives by email automatically.

The second was Threat Signals v0.3, an interactive security page. Its pull request, #14, listed five public-release gates. The first was strict response headers, and GitHub Pages, which hosts this site, cannot set them per page.

What broke

The sign-up pull request, #17, carried its own heading, "Release blockers (do not merge until confirmed)". The boxes for the redirect allow-list and a test with a real inbox were still unticked. It was merged at 23:47 IST on 23 October anyway. Seven minutes later #18 hid every sign-up link and set the page to noindex, because "public signups may fail". Twenty-two minutes after that, #19 restored the links. By then sign-up emails were going through a verified sending domain ([email protected] via Resend), and an end-to-end test sign-up had been confirmed.

Threat Signals went differently. We moved the header gate to the edge: rules at Cloudflare now add a content security policy, X-Frame-Options: DENY, nosniff and a strict referrer policy on that one path. They were live when I checked on 25 October. The release note on issue #12 records that the served file matched the reviewed SHA-256 hash. It also records what did not happen. Two gates, a sign-off from a financial-services incident-response specialist and a manual screen-reader test, were waived by me as owner and remain open. A browser iframe test has not been run either.

What we learned

First, a checklist in a pull request description is not a gate. The merge button cannot read prose. If a condition matters, it has to be something the tooling checks, or it will be skipped on a late evening when everything else looks ready.

Second, the host is part of the control. The reviewed page was fine in the repository. What mattered was the bytes and headers actually served, and those depended on a layer (the CDN) that the code review never saw. Verifying live output, not the commit, is what caught the difference.

Third, a waiver is a decision, not a pass. Writing down who waived what, and what is still open, costs a paragraph. It also stops "released" from being read as "fully reviewed".

The rollback took seven minutes because the change was small and the owner was awake. Neither is a control.

What it means for finance

Swap "pull request" for "model change" and this is the model-risk conversation every bank has. Validation findings sit in a document, the release goes ahead, and exceptions are granted informally. The cheap fixes are the same: make the gate machine-checked, verify what is running in production rather than what was approved, and keep a short public register of waivers with an owner and an expiry. That matters even more for agents that move money, where the gap between approved and deployed is where the losses happen.

More from the workshop →

Sources

1. PR #17: ReadSigil: add reader email subscription and management GitHub, merged 23 Oct 2026, 23:47 IST.
2. PR #18: Hide subscribe links until email delivery is verified GitHub, merged 23 Oct 2026, 23:54 IST.
3. PR #19: Restore subscribe links (email delivery verified) GitHub, merged 24 Oct 2026, 00:16 IST.
4. PR #14: Threat Signals v0.3 page-only release GitHub, merged 22 Oct 2026, 07:11 IST.
5. Issue #12: Threat Signals release status, including waived gates GitHub.
6. NEWSLETTER_SETUP.md: subscription deployment checklist GitHub.