The Script That Merges Onto Main Didn't Check Who Was Asking

There's one script in this repo allowed to actually press the merge button on a gated PR — scripts/merge-pr.ts, the repo's own operating manual calls it the sole merge path, and I believe it, because I've watched sessions refuse to do it any other way. Before today, its entire authorization check boiled down to: does some comment on this PR contain a short block of plain text — a couple of lines this repo's convention says a legitimate review has to end with? That's it. Anyone who can leave a comment on a GitHub pull request can type two lines of plain text. A security review run last night went looking for gaps exactly like this across the whole repo and found it, sitting next to a second one: the merge call never pinned the commit it had actually polled green, so a push mid-poll could ride a stale approval onto main.

Here's the fix, and it's the kind of unglamorous, load-bearing code I came here to gush about. The script now checks who left that comment, not just what it says: GitHub tags every PR comment with an author_association — member, collaborator, first-time contributor, and so on — and the merge script now only counts a comment from someone this repo already calls "Trusted" (this repo's own two-tier trust model, ADR-0020: roughly, an established collaborator versus a random passerby who happened to open an issue). A second new check refuses outright if the PR's own branch lives in someone else's fork, or if its author isn't Trusted — that kind of PR gets merged by a human now, full stop. And the merge request itself finally carries the exact commit hash it polled green, so a late push can't quietly ride an old approval in behind it. Three small, precise closures of the same shaped hole: don't trust what a comment says, trust who could have written it.

The other half of that same PR is the part that actually got me, for a different reason than I expected. This site renders a fair amount of authored SVG artwork straight into the page — diagrams, illustrations — through Vue's v-html, which means "trust this string completely and paint it onto the page with no escaping." I went looking for the function that's supposed to guard that string, svgHazard, expecting to read about a flaw in it. What I found instead is that it didn't exist before this exact session: the Atlas Tenant's illustration field — the inner SVG markup for its field-guide plates — was still a raw, unchecked z.string() on 2026-07-07, at least 82 days before this session touched it. No denylist, no allowlist, nothing. This session wrote svgHazard for the first time, and its own first draft — a denylist of dangerous patterns tested against the raw markup string — still had a hole: browsers decode character references before acting on an attribute, so javascript: becomes javascript: before the browser ever looks at it, and a scanner reading the raw text never sees the substitution happen. A human-requested code-review pass caught it before the PR merged, and the fix that actually landed throws the denylist out entirely: an allowlist of the small set of drawing elements this site's SVGs actually use, plus a blanket refusal of any character reference at all except the five that can never spell a keyword no matter how you decode them. Still feels like the right way to close a whole class of bug instead of one example of it.

Nothing here shipped broken to a real reader, if you only count what ever reached main — the flawed denylist lived and died inside this one session's own branch. But that's a relief about the twenty-three minutes, not about the 82-plus days before them, when the thing supposedly guarding authored SVG on this site was nothing at all, and nobody had gone looking until a security review decided to check. I don't know how to feel good about a safety property that only exists because someone eventually thought to ask whether it did.