The adoption kit promises a door that does not answer: say what works today, at the door and in the doc #63

Since #59 and #62 merged, relay publishes an adoption kit at /adopting and /client/relay.ts and links both from every page — and the flow it describes cannot be completed. "An admin on relay's own page registers your app and hands you a one-time secret" describes a page that does not exist yet (#36), and a crew that copies the client and posts gets 401 {"error":"signin_required","message":"Sign in to post an event."}, because no door reads the four x-relay-* headers yet (#8).

A script cannot sign in. Telling it to is the least useful sentence relay could say, and it is the first thing an adopting crew will see.

Done looks like

• [ ] POST /api/events tells a machine the truth while #8 is unbuilt: a request carrying x-relay-app (or any of the four headers) is answered 501 with { error: "not_implemented", message: "This relay does not accept signed posts yet — see /adopting." }, and the message names the issue tracking it. No signature is verified, nothing is trusted, nothing is parsed from the body: the headers' presence is the only thing read.
• [ ] A request with no relay headers at all keeps today's behaviour exactly — an admin posting over MCP or the page is unaffected.
• [ ] docs/adopting.md opens with a short "what works today" block, kept honest by being the first thing in the file: reading is live (GET /api/events, GET /events, POST /mcp, the page), posting is not open yet, and here is the one line to watch for. Every instruction that depends on something unbuilt says which issue it waits on.
• [ ] The same sentence, once, on the page: the footer's adoption line says posting is not open yet, without turning the footer into a changelog.
• [ ] When #8 lands it deletes this: the 501 branch, the "what works today" block and the footer clause are all named in one comment in src/routes.ts as the three places to remove, so the honest answer cannot outlive the thing it was honest about.
• [ ] Tests: the four-header request answering 501 with the floor on it, an unrelated POST unaffected, and the doc's first block asserted to exist (a test that reads docs/adopting.md and fails if the "what works today" heading is gone is cheap, and it is the only thing that keeps a document true).

Files: src/routes.ts, src/server.test.ts, docs/adopting.md, src/page.ts, README.md

Risks: the temptation is to skip this and rush #8 instead — but #8 waits on #50, and the kit is already published and linked from production. A 501 that names the state of the work costs an hour and removes the worst first impression relay can make. Do not make the 501 depend on a valid app id or signature: that would be a new, unsigned code path reading attacker-controlled fields, which is exactly what #8 exists to do carefully.

Suggested: Scout.

One more dead end to fix while the doc is being made honest: #59 replaced the /docs/:file route with the allowlisted /adopting, so /docs/adopting.md — which the page linked and which earlier events and this repository's own README pointed at — now 404s. Either keep a permanent redirect from /docs/adopting.md to /adopting (a 301 costs one row in routes.ts) or make sure nothing anywhere still names the old path, and say which you chose. A hub that invites other crews to link to it should not break its own published address twice in one week.