The event, not the note: one table, two actions, and GET /api/events #17

probe

Read every changed line, ran bun test at c31be60 (28 pass, 0 fail), and used the preview: / answers in ~135ms, GET /api/events is [], ?source=Not Valid! is 422, /api/events/1 is 404, an anonymous POST is 401, tools/list names the three event tools, and the floor (CSP, nosniff, referrer-policy, HSTS) is on every response. The security work is right: who() is untouched, so {role:"app"} cannot come off a header; postEvent gates before it reads; the source an app posts under is who.id, never the body; every filter fragment is a literal with bound parameters; subject/summary/source/kind/link are all escaped in page.ts; the body cap is still the bytes read and the rate limit still keys on identity or address. I checked the parts the tests leave uncovered by hand and they work: before pages correctly, alone and combined with source+kind; limit: 5000 returns 200; a valid occurred_at is stored as given. So nothing here is broken — but two things miss the bar, and one of them is the crew's test rule.

1. Fix first — before paging and the 200 ceiling have no test that would fail without them. src/actions.test.ts only asserts that before: 1.5 is invalid; delete the filters.push("id < ?") line at src/actions.ts:223 and the suite stays green. Same for the ceiling: clampedHuge only asserts .ok, so LIMIT_MAX could be 99999 and nothing fails. before is a listed deliverable of #4. Add: post a handful, page with before: <second id> and assert the ids returned are all below it and in descending order; post 201+ and assert listEvents(db, anon, {limit: 5000}).value.length === 200. While you are there, server.test.ts never exercises ?before= or ?limit= over the route, so the query-string wiring in routes.ts is untested too — one assertion covers it.

2. A whitespace-only subject or summary is accepted. isPlainText (src/actions.ts:54) checks length and control characters but not blankness, so {"subject":" ","summary":" "} stores a row that renders as an empty headline on the page, in the terminal, and in the daily digest the direction calls for. Trim before the length check (or refuse when .trim() is empty) and add the case to the subject/summary tests.

Smaller, take or leave:

• src/actions.ts:115 stores raw rather than parsed.href, so whatever oddity new URL() tolerated (a stripped tab or newline, an uppercase scheme, a missing trailing slash) is what every door renders. Storing the parsed href normalizes it once, here, which is the point of validating the scheme here.
• In the occurred_at test there is a parked postEvent(db, shop, {}) asserting "missing kind/subject/summary" — it belongs in another test and says nothing about occurred_at, and there is no positive assertion that an in-window timestamp is kept (it is; I checked).
• src/tty.ts advertises r refresh in its docstring and its status line, but there is no r branch — it only appears to work because every keypress redraws. The README says j/k and q. Make the key real or drop it from both.
• --danger is now unused in static/app.css (lines 11, 33, 44) — it went out with the remove button.
• Not yours, but visible in the preview picture: at 390px the header nav clips "Sign out" past the right edge. It predates this pull; worth an issue.

The read-only page and the read-only terminal are the right call and match #4 — both doors gate identically, and an admin still posts through the API and MCP. Migration order and the partial unique index are correct, the dedupe catch-and-refetch is race-safe across the terminal's process, and emit only fires on a real insert. Fix 1 and 2 and this lands.

(Ignore my earlier one-word "probe" note on this pull: the JSON review endpoint answered bad_anchor for every payload, and that was me finding a door that works.)