Identity comes from the forge: /admin opens for a forge admin and the password sign-in is gone #21

Approved. Two nits from #13, each in one commit, no behaviour beyond them and no dependency. I read every changed line, ran the suite at 64f2686 (42 pass / 0 fail) and reverted context.ts to the old ctx.url.pathname to confirm the new server test does fail without the fix — it does. I exercised the preview as a visitor: / in ~230 ms over the network, /search?q=beans renders to=%2Fsearch%3Fq%3Dbeans, / renders to=%2F, add-to-cart → /cart → /checkout still walks the whole path, and the security floor is intact on every response (CSP with script-src 'none' and base-uri 'none', nosniff, Referrer-Policy, HttpOnly/SameSite=Lax/Secure sid).

Security of returnTo specifically, since it is a string this app hands to the forge:

• No open redirect. The value is always url.pathname (+ re-serialised query), so it always begins with a single /, and signInHref percent-encodes it. I tried the usual protocol-relative shapes against the preview: //evil.com/x normalises to to=%2Fevil.com%2Fx, /\/evil.com comes back as to=%2F%255C%2Fevil.com. Nothing escapes the origin.
• No injection. ?q="><script> round-trips as %2522%253E%253Cscript%253E inside the href, and account() escapes on top of that.
• token stripping is right, and delete removes every copy of the parameter, not just the first. The 512-character fallback to the bare path is measured before encoding, which is the conservative direction.

Two observations, neither blocking, neither worth a round:

1. The token still reaches the forge by the other door. Referrer-Policy: strict-origin-when-cross-origin sends the full URL on a same-origin navigation, so clicking Sign in from /orders/1001?token=… puts ?token=… in the Referer on the request to /__forge/signin. to= was the more durable of the two channels (it survives into a redirect target), so this commit is still a net win — but if you want the rest of it closed, Referrer-Policy: same-origin in the floor in src/server.ts is the one-line version.
2. The cost you named in the description is real and I agree with the trade: an anon on an order page who signs in lands on /orders/N without its token and gets nothing. Worth a follow-up only if someone reports it; the emailed link still works.

The CSS does what it claims. In the desktop picture the categories, Admin, search, Cart and the account corner sit on one row with the search box shrunk; in the phone picture the header wraps into clean rows with the categories together and no overlap. nav.cats { flex: 1 0 auto } means the categories no longer shrink, which is the point — the wrap below 9rem of search box is the escape hatch.

One cosmetic thing for whoever next touches README.md: the new sentence left The terminal takes the same three roles from the trailing on an over-long line, out of step with the wrapping around it.

Approved — this is the follow-up I asked for on #13, plus a third commit I had not asked for and that is right.

I read all three commits, ran the suite at 735cbd0 (43 pass / 0 fail) and exercised the preview as a visitor. The direction holds: identity still comes only from the forge's signed headers, /admin is still 403 with no password field for anyone the forge has not signed as an admin, and no dependency arrived.

returnTo is the right shape. One function owns the return path; src/context.ts and the /admin guard both call it, so the header and the door can no longer disagree. The value is always built from url.pathname plus a re-serialised query, so it cannot be steered by a form field, and signInHref percent-encodes it: ?q="><script> round-trips as %2522%253E%253Cscript%253E inside the href and account() escapes on top. query.delete("token") removes every copy of the parameter, not just the first.

The rel="noreferrer" commit is correct rather than cargo-culted. The floor sets referrer-policy: strict-origin-when-cross-origin, which is decided per origin, and /__forge/ is served on this one — so without it the Referer on the way to the sign-in would have carried the whole current URL, including the very token that to= strips. Closing both channels or neither is the only coherent choice. Verified on the preview: the header is intact on every response, and every /__forge/ anchor in the tree goes through the constant.

The preview behaves. / 200 in ~230 ms over the network, /search?q=beans renders to=%2Fsearch%3Fq%3Dbeans, /admin is 403 with the sign-in link and to=%2Fadmin. The desktop picture shows the header on one row with both the Admin link and the account corner, which is what the CSS commit was for; the phone wraps to a second row as before, with no shift.

Protocol-relative paths, since returnTo is now the chokepoint. A request to //evil.com/x renders to=%2F%2Fevil.com%2Fx on our 404 page. I followed it: the forge collapses the path and /__forge/signin sanitises it back to to=%2F, so there is no open redirect today. One line here — require /^\/[^/\\]/ or fall back to "/" — would stop that safety depending on the forge's behaviour rather than ours. Not blocking.

Two things left, neither a reason to hold this:

1. The sign-in link is a dead end on the money path. An order opens only with its token, so a person part-way through checkout at /pay/1001?token=… who clicks Sign in returns to /pay/1001 and gets a 404. The pull discloses it, but a 404 mid-purchase is a lost sale, not a missing page, and it sits on the one path the whole shop exists for. The token must not go to the forge, so the fix is elsewhere: either do not offer the link on a token-opened order or pay page, or let an order open for the account that placed it — #12's ground now that ctx.who exists. Worth an issue before that path is walked for real.
2. The deny-list is a list of one. Dropping token is complete today, because every other query parameter in this app is q, m or added, but it will not stay complete on its own: the next code or key that arrives in a query string rides along to the forge silently. A line in returnTo's comment naming that rule would keep the next person honest.

Nit, one line: SIGN_OUT_HREF now sits against returnTo's closing brace with no blank line between them, and the new doc block follows it — a blank line above line 82 puts the file back in the shape the rest of it has.

Approved. Four small commits, all inside the direction (identity from the forge, nothing of our own), no dependency, and the security reasoning runs the right way round. Anchored here because this line is the only new surface in the change.

What I read and ran

• returnTo is the whole new attack surface. The guard /^\/($|[^/\\])/ rejects a pathname a browser would read as a host — I ran it: //evil.com/x, /\\evil.com/x and ///evil.com all come back /. Everything else is a URL pathname, so ?, # and control characters are already percent-encoded, and the result is encodeURIComponentd in signInHref and escaped into the attribute. No injection path, and not leaning on the forge to sanitise to= is the right instinct.
• Stripping token is complete, not just illustrative: token is the only secret query parameter the app reads (src/shop.ts:221); every other read is m, q, added. ?TOKEN=x survives the filter, but searchParams.get("token") is case-sensitive so a surviving variant is not a working token. Naming the rule rather than the parameter in the comment is what keeps that true later.
• rel="noreferrer" closes the other half of the same leak, and closes all of it: Referrer-Policy: strict-origin-when-cross-origin does nothing for a same-origin hop to /__forge/, and every anchor to /__forge/ in the tree (src/html.ts:59,62, src/pages/admin.ts:34,44) now goes through FORGE_LINK_ATTRS. None left behind.
• Tests: bun test is 44 pass / 0 fail at 5b9f4fd. I reverted context.ts to the old ctx.url.pathname in a scratch copy and both new server assertions fail, so the behaviour is genuinely pinned.
• Preview: / and /search?q=beans serve to=%2F and to=%2Fsearch%3Fq%3Dbeans with rel="noreferrer"; /admin/orders is 403 with the same link and no password field anywhere; the floor is on every response (CSP with script-src 'none' and base-uri 'none', nosniff, Referrer-Policy, HttpOnly; SameSite=Lax; Secure sid). I bought a thing as a guest through the simulated gateway: 303 to /pay/BZ-…?token=…, the pay page renders, and its header Sign in is to=%2Fpay%2FBZ-… with the token gone — exactly as advertised.

One nit, for this pull or the next hand on the header. nav.cats { flex: 1 0 auto } forbids the categories from shrinking below their single-line content width (the item wraps internally, so its auto basis is max-content). Signed in as an admin the five links measure ~322px in the phone picture; at a 360px viewport, minus the wrap padding, they no longer fit and the header scrolls sideways instead of wrapping — the old flex: 1 squeezed and wrapped. flex: 1 1 auto; min-width: 0 keeps what you fixed (the search box still gives up its 14rem basis first) without that floor. Worth a look at 320–360px signed in as an admin; a sideways-scrolling header is the first thing a person sees.

The cost you documented — signing in from a token-opened order or pay page lands on a 404 (I confirmed /pay/BZ-… without a token is "Not here") — is not a regression, since the old pathname dropped the token too, and it is already #24. Leaving #12 alone was right.

Housekeeping: a stray x comment above is mine, from probing this API; its thread is resolved.