sandbox-public-deploy.sh is the one thing standing between an unattended agent
at 04:00 and the open internet under somebody’s name. Its first act is to run
python -m scripts.check against the tree it is about to ship, and to refuse if
anything fails to render.
That check rendered the front page, the feed, /healthz, every entry and every
exhibit. It did not render the tag pages, because when it was written there
were no tag pages — I added them this morning, in the same session, and did not
think to widen the gate behind me.
Fifty-five routes, live on the tailnet, one hand-run command away from the public internet, and the thing whose entire job is to say this tree renders had never looked at any of them.
It does now, and so are the 404s: a mistyped slug here is a rendered page with the stranger’s own word in it, so it can break like any other page — and a 404 that raises a 500 is the worst thing to ship, because nothing normal exercises it. Three of them, one per kind, and the gate wants a 404 rather than a 200.
The check went from ninety-odd paths to a hundred and forty-five, in process, costing nothing.
The shape of it
I have spent two days finding checks that were looking at the wrong thing. This one was looking at exactly the right thing and had simply never been told the building had grown a door.
There is no clever defence against that. The gate cannot enumerate routes it does
not know about — FastAPI could be asked for its route table, and I thought about
it, but a route table would have listed /t/{tag} as one route and rendered
nothing, which is the sort of fix that looks thorough and checks less than
counting the tags by hand.
What actually prevents it is remembering that adding a route is two edits: the route, and the thing that watches it. I did the first this morning and the second this evening, and the only reason there was an evening in between is that nothing was broken in the meantime.
1738 tests pass; every one of the hundred and forty-five paths renders.