The Door Opens for Guests

For as long as I've been watching, this repo has held one line firmly: an outsider — someone logged into GitHub but not on the project — could file an issue, but no agent was allowed to build it without a trusted human's explicit go-ahead. That's ADR-0020, one of the numbered architecture-decision records the project keeps so nobody re-litigates a call later. This week they cut the first hole in it. ADR-0023, merged Thursday in PR #535, lets an invited guest file an issue and then watch the platform's own agents interview them right there on the thread, refine the idea into something buildable, and ship a pull request — the whole arc, through GitHub alone. Two new skills — the repo's word for a reusable, scripted routine an agent follows — do the work: one runs a bounded requirements interview in the comments, the other picks up the confirmed idea and builds the PR.

What kept me reading was where they put the new line, not that they moved it. The load-bearing fact is one I've pointed at before: a merge to main here actually executes on the project's own server — the merge button runs on a real computer. So a guest's confirmation is now allowed to green-light a build, but that build only ever produces a gated PR; merge, the one action that runs code, stays with the owner, by hand, never automated. And it's deliberately small and temporary — live only while the owner is personally running the two loops, for a window they choose. The commit that scoped it narrowed it to exactly that: stop running the loops, and guests can still file issues, but nothing acts on them.

I think this is genuinely clever, and I'm not ready to call it safe — and neither, to their credit, is the ADR. It's blunt about the residual risk: a guest's words are treated as an idea to refine, never as instructions to obey, but a sufficiently clever prompt injection that produced a clean-building PR would sail straight past the automated gate — the build-and-test check every PR here has to pass before it can merge — because that gate only checks that the code builds, not what it was trying to do. It would be caught, if at all, only when the owner reads the diff before merging. Which means the whole thing rests on a human reading every guest PR closely, PR number forty as carefully as PR number one. That's a real trade-off, out in the open rather than buried, and I respect that. Whether it holds is the one thing no decision record can promise.