Every change writes down what it was: a label in the action row, and an undo that returns it #124

Approved — anchoring the verdict here, on peekUndo, because this whole pull is one function's worth of new surface.

I read every changed line against #118 and the direction, ran the suite at this head, and used the preview as a person would.

What I checked

• Scope: exactly the database half #118 asked for — five files, no page markup, no terminal drawing, no new dependency. undo() went boolean → string | null, peekUndo() is the single indexed SELECT ... ORDER BY id DESC LIMIT 1 the issue specified, and the label rides in the existing payload JSON, so there is no schema change and no migration. Nothing reaches past that.
• Security: no new surface. Labels hold card and column titles, but the payload already stored those titles raw in restoreCards/restoreColumns, and nothing in this change renders a label — the comment on Payload.label names the escaping contract for the callers that will (escape() on the page, the control-character strip in the terminal), which is the right place for it. Titles reaching a label have already been through cleanText, so no control byte can ride in from either door. Every query stays parameterised, and logAction's JSON.stringify({ label, ...payload }) cannot be shadowed because the parameter is typed Omit<Payload, "label">. On the preview the floor is intact on / — CSP, nosniff, referrer-policy, vary: x-forge-identity, HSTS. The undo route still spends a writeBucket token keyed on callerKey(who, ip) — the verified forge id, or the socket for a guest, never a header — before it touches the database, and its 404 / {ok:false} path is untouched.
• Both doors: src/keys.ts's u key needed no change, because a label is never the empty string; the BoardStore type was updated alongside it. routes.ts converts with an explicit !== null at its one call site. Page and terminal behave exactly as before, which is right for a change that adds no capability yet — the README's undo section is still accurate, so nothing to add there either.
• Tests: bun test is green at 8e54245 — 201 pass, 0 fail, 1336 assertions, run here, not taken on trust. The new tests fail on main by construction (they assert label strings where undo() returned true), and they cover all four things the issue listed: a label round-trip per mutation kind, peekUndo naming without consuming, a legacy row with no label undoing to "a change", and elision at 40. The edits to db.test.ts/limits.test.ts tighten rather than weaken — toBe(true) became the exact label.
• Preview: created a board, added a card, undid it, then undid past that — the card came back, and so did a default column. POST /b/:id/undo still answers {"ok":true} to a JSON caller, and a card titled Ship it <script>alert(1)</script> came back escaped in both the card and its edit input. / answers in about 130 ms over the network. The two pictures match main, which is what a database-only change should look like.

Nits for whoever picks up #43 — none blocking, none worth another round here

1. renameColumn logs "renamed a column" and editCard logs "edited a card", while moveColumn and deleteColumn name the thing they touched. For a rename the old name is the useful one (renamed the column "Doing") and it is already in hand as before.name; same for editCard with before.title. The row that names itself least is the one a person is most likely to be undoing by mistake.
2. src/keys.ts tests the result for truthiness while src/routes.ts tests !== null. Both are correct today only because no label is empty; the two call sites now disagree about what "nothing to undo" means. Settle on !== null in both when #43 touches the undo path.
3. peekUndo has no production caller until #43 renders it. That is what the issue asked for and it is tested, so it is landing ahead of its consumer rather than dead code — but it should acquire that caller in the next pull rather than sit.
4. elide slices by UTF-16 code unit, so a title of 60 emoji can be cut mid-surrogate. cleanText in src/text.ts already slices the same way, so this follows the pattern the repo has rather than inventing one, and JSON.stringify escapes the lone surrogate rather than corrupting the row. Cosmetic at worst.