Who really posted this: every event records the identity behind it, not just the source it claims #42

source is what an event claims, not who said it: for a signed app the action sets it from who.id, but an admin posts with any source they type and the row keeps no trace that a person, not that app, wrote it. On a hub whose whole premise is "signed with its own identity key", a row that cannot say which identity produced it is a row nobody should trust.

Done looks like

• [ ] A migration appends posted_by TEXT to event (nullable, because rows that already exist were never recorded), plus CREATE INDEX event_posted_by ON event (posted_by). Never edit a migration that has run; append to the end of the list in src/db.ts.
• [ ] postEvent sets it from who, in the action so every door agrees: app:<id> when who.role === "app", user:<id> when an admin posts. The value is derived, never read from input — an input field named posted_by is ignored, and a test proves it.
• [ ] An event whose posted_by does not match its source is shown as what it is: the page renders a small posted by <name> marker on that row (escaped), and only on that row — a normal signed app post stays visually quiet. src/tty.ts shows the same fact in its dim metadata.
• [ ] GET /api/events, GET /api/events/:id and the MCP tools carry posted_by in the JSON, because an agent deciding whether to act on an event needs the same fact a person gets.
• [ ] Provenance is public, and the issue says so on purpose: user:<id> is the forge's id, not an email, and the page shows the id only to signed-in viewers — an anonymous reader sees posted by an admin with no id. If that rule is wrong, argue it in the pull rather than quietly widening it.
• [ ] docs/adopting.md and the README.md event table gain the column with one line each: what it is, and that an app cannot set it.
• [ ] Tests in src/actions.test.ts: an app post records app:<id> and ignores a posted_by in the input; an admin post records user:<id> and keeps the claimed source; a deduped retry does not rewrite the original row's posted_by; the page marks a mismatched row and does not mark a matching one.

Files

src/db.ts, src/actions.ts, src/page.ts, src/tty.ts, src/actions.test.ts, src/server.test.ts, README.md, docs/adopting.md.

Risks

• Issue #35 also appends a migration (the app table). The list is positional, so whichever lands second moves its migration to the end — a rebase, not a conflict, and the reason this issue is not blocked on it.
• RETURNING * means the new column flows to every door for free; check the Event interface and the dedupe-collision SELECT both carry it, or an idempotent retry answers a row with a missing field.
• Backfilling old rows is out of scope: null means "posted before relay recorded it", and the page must render that without a marker rather than as posted by null.

Suggested

Scout to build, Sentinel to review — the interesting part is what an input may and may not influence.

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

Unparked, and deliberately not rewritten. Both parks here say the same thing — the run ended without a pull: no changes pushed, from a provider limit or a DNS failure — so no builder ever reached the code and nothing was learned that would change what done looks like. Splitting an issue that was never attempted would only make the map longer. It stands as written.

Re-read against main at 1be64f6 (the ration at the door, #40, merged since this was filed):

• postEvent still sets source from who.id for an app and from free text for an admin, and the row still keeps no trace of which. Unchanged by the merge.
• #43 still waits on it, so an admin-posted event is marked from the first one ever posted rather than retrofitted.