feat(events): publish runId on a public calendar run entry (Rust D125) #208

wtclaude · 2026-09-25T12:39:19Z

wtclaude commented

2026-09-25 12:39:19 +00:00

Core's part of module-rust phase 15, D125 (docs/modules/rust/PLAN.md §31, merged in docs#273).

What changes: GET /public/events now includes runId on each entry whose kind is run. It is the same id PublicEventOccurrence.runId already publishes on the event page, and the id /events/:slug?run= takes.

Why: a Rust map marker for a site event carries core's run id and nothing else about its event. The app's event page is addressed by slug, and the public calendar was the one public shape that listed a run without saying which one. Without this, the only way to find the event was to fetch every live event's page.

What does not change:

A projected entry has no runId, because nothing is committed to it.
Rehearsals and unlisted events are still absent from the calendar (SQL, publicOnly), so their markers stay unlinked.
The web calendar ignores the field.
The file header's rule still holds: the field is added by a line in publicRunEntry, not by a spread.

Changes:

eventPublic.model.js: runId on publicRunEntry.
swagger.js: PublicEventEntry.runId, and the regenerated swagger-output.json.
eventPublic.test.js: the exact-keys test now lists runId. A new test pins that a run entry's id is its run's, that the event page publishes the same id, and that a projection has none. The existing rehearsal test still passes, unchanged.

Tests: eventPublic.test.js passes 27/27. The full suite in node:20 shows 2 failures, both in routeManifest.test.js, and both caused by this machine's git-ignored modules/uo and modules/rust installs adding their mounts to the live route stack. In a clean worktree of this branch with no modules installed, routeManifest.test.js and eventPublic.test.js pass 31/31.

The docs change (EVENTS.md § API surface, which BACKEND_DESIGN.md defers to for the event routes) lands with phase 15's as-built docs PR.

AI-assisted: Claude Code (Claude Opus 5.5)

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Core's part of module-rust phase 15, D125 (`docs/modules/rust/PLAN.md` §31, merged in docs#273). **What changes:** `GET /public/events` now includes `runId` on each entry whose `kind` is `run`. It is the same id `PublicEventOccurrence.runId` already publishes on the event page, and the id `/events/:slug?run=` takes. **Why:** a Rust map marker for a site event carries core's run id and nothing else about its event. The app's event page is addressed by slug, and the public calendar was the one public shape that listed a run without saying which one. Without this, the only way to find the event was to fetch every live event's page. **What does not change:** - A projected entry has no `runId`, because nothing is committed to it. - Rehearsals and unlisted events are still absent from the calendar (SQL, `publicOnly`), so their markers stay unlinked. - The web calendar ignores the field. - The file header's rule still holds: the field is added by a line in `publicRunEntry`, not by a spread. **Changes:** - `eventPublic.model.js`: `runId` on `publicRunEntry`. - `swagger.js`: `PublicEventEntry.runId`, and the regenerated `swagger-output.json`. - `eventPublic.test.js`: the exact-keys test now lists `runId`. A new test pins that a run entry's id is its run's, that the event page publishes the same id, and that a projection has none. The existing rehearsal test still passes, unchanged. **Tests:** `eventPublic.test.js` passes 27/27. The full suite in `node:20` shows 2 failures, both in `routeManifest.test.js`, and both caused by this machine's git-ignored `modules/uo` and `modules/rust` installs adding their mounts to the live route stack. In a clean worktree of this branch with no modules installed, `routeManifest.test.js` and `eventPublic.test.js` pass 31/31. The docs change (`EVENTS.md` § API surface, which `BACKEND_DESIGN.md` defers to for the event routes) lands with phase 15's as-built docs PR. - [x] AI-assisted: Claude Code (Claude Opus 5.5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

wtclaude added 1 commit 2026-09-25 12:39:21 +00:00

feat(events): publish runId on a public calendar run entry (Rust D125)

PR Checks / bot-tests (pull_request) Successful in 39s

Details

PR Checks / client-build (pull_request) Successful in 42s

Details

PR Checks / server-tests (pull_request) Successful in 5m54s

Details

b5616f359c

A run entry on GET /public/events now names its run, the same id the
event page already publishes on each occurrence and `?run=` takes. A
Rust map marker carries core's run id and nothing else about its event,
so without this the app could only find the event by fetching every
event page.

A projected entry has no runId: nothing is committed to it. Rehearsals
and unlisted events stay absent from the calendar, so their markers
stay unlinked. The web calendar ignores the field.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

whitlocktech approved these changes 2026-09-25 17:43:44 +00:00

whitlocktech merged commit 90ba8cca16 into main

2026-09-25 17:43:53 +00:00

whitlocktech deleted branch feat/public-calendar-run-id

2026-09-25 17:43:54 +00:00

whitlocktech referenced this issue from a commit

2026-09-25 17:43:56 +00:00

Merge pull request 'feat(events): publish runId on a public calendar run entry (Rust D125)' (#208) from feat/public-calendar-run-id into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/website#208