docs(website): the public surface, and the flag that decides what reaches it (Phase 14a) #224

wtclaude · 2026-09-08T17:01:13Z

wtclaude commented

2026-09-08 17:01:13 +00:00

Events Phase 14a, docs half. One of two: website (website#196), docs — both onto edge.

EVENTS.md gains a new §I section on the public surface, the four API surface rows filled in, listed in §D, and the §J rows for player profiles and mobile. EVENTS_PLAN.md records the 14a/14b split and 14a as built. BACKEND_DESIGN.md names the two tiers the Phase 14a reads live on. MODULE_API.md records core's own capability list beside a module's.

`listed` is announcement, not permission

The decision that shaped the phase, and §D says why it is not a second answer to what state already answers: state says schedulable, listed says announced. The two came apart the moment there was a public surface at all, because publishing is what makes a definition runnable — so without the column a surprise invasion would have to be advertised a fortnight in advance in order to be allowed to happen. It defaults to 1, so every definition keeps the behaviour it had while the only reader was staff, and unlisting is the deliberate act.

Two things this phase corrected in the document rather than in code

A venue was never a field. §I's screens table and the API surface table had both described one since the first revision — the definition editor's sections, and what an event page shows. There has never been one: not a column, not a key in spec, not an input on Phase 13's form, not a string anywhere in either repo. Rather than add a field on the way past to a public page, both descriptions dropped it; the storyline already carries the where. (The word stays in §G and §B2 as ordinary English for a place in the world, which is what it always meant there.)

The url variable this document has carried as a promise since Phase 10 is now kept. eventUrl, carrying ?run=, arriving with the page it points at — which is what makes it a version bump rather than a correction.

What §I now records about the public surface

The rule for what reaches it (listed and ready and not a rehearsal, all three in SQL); that a visitor's calendar is a list where an operator's is a grid, because the same data is answering a different question; that the public shapes are a projection rather than a filtered admin shape, and that this is the security property — building the public answer by deleting fields from an operator's is the direction that fails silently; the three things absent from every shape and why each one is; and why failed/missed publish as cancelled while paused publishes as live.

It also records that participation history is mounted twice, and that it is the third screen to need the notificationPaths.js mapping for the reason the first two did: the route is role-agnostic and the web's RequirePlayer is what disagrees.

The three defects, written down

Because both suites were green on either side of each one, and that is the argument for the walk in a sentence. Two were the same mistake in two files — a split reading a status where it should read a clock — and the third was a screen the reviewing admin could not open at all.

Checks

docs has no CI. Every relative link and in-page anchor in the new sections was resolved by hand; the files are CRLF in the working tree and each diff is content-sized (--numstat 11/4, 127/14, 49/10, 11/0), so none carries the \r\r\n full-file rewrite.

🤖 Generated with Claude Code

https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

Events Phase 14a, docs half. One of **two**: `website` (website#196), `docs` — both onto `edge`. `EVENTS.md` gains a new §I section on the public surface, the four API surface rows filled in, `listed` in §D, and the §J rows for player profiles and mobile. `EVENTS_PLAN.md` records the 14a/14b split and 14a as built. `BACKEND_DESIGN.md` names the two tiers the Phase 14a reads live on. `MODULE_API.md` records core's own capability list beside a module's. ## `listed` is announcement, not permission The decision that shaped the phase, and §D says why it is not a second answer to what `state` already answers: **`state` says schedulable, `listed` says announced.** The two came apart the moment there was a public surface at all, because publishing is what makes a definition *runnable* — so without the column a surprise invasion would have to be advertised a fortnight in advance in order to be allowed to happen. It defaults to 1, so every definition keeps the behaviour it had while the only reader was staff, and unlisting is the deliberate act. ## Two things this phase corrected in the document rather than in code **A venue was never a field.** §I's screens table and the API surface table had both described one since the first revision — the definition editor's sections, and what an event page shows. There has never been one: not a column, not a key in `spec`, not an input on Phase 13's form, not a string anywhere in either repo. Rather than add a field on the way past to a public page, both descriptions dropped it; the storyline already carries the where. (The word stays in §G and §B2 as ordinary English for a place in the world, which is what it always meant there.) **The url variable this document has carried as a promise since Phase 10 is now kept.** `eventUrl`, carrying `?run=`, arriving with the page it points at — which is what makes it a version bump rather than a correction. ## What §I now records about the public surface The rule for what reaches it (`listed` **and** `ready` **and** not a rehearsal, all three in SQL); that a visitor's calendar is a **list** where an operator's is a grid, because the same data is answering a different question; that the public shapes are a **projection rather than a filtered admin shape**, and that this is the security property — building the public answer by deleting fields from an operator's is the direction that fails silently; the three things absent from every shape and why each one is; and why `failed`/`missed` publish as `cancelled` while `paused` publishes as `live`. It also records that **participation history is mounted twice**, and that it is the third screen to need the `notificationPaths.js` mapping for the reason the first two did: the route is role-agnostic and the web's `RequirePlayer` is what disagrees. ## The three defects, written down Because both suites were green on either side of each one, and that is the argument for the walk in a sentence. Two were the same mistake in two files — a split reading a **status** where it should read a **clock** — and the third was a screen the reviewing admin could not open at all. ## Checks `docs` has no CI. Every relative link and in-page anchor in the new sections was resolved by hand; the files are CRLF in the working tree and each diff is content-sized (`--numstat` 11/4, 127/14, 49/10, 11/0), so none carries the `\r\r\n` full-file rewrite. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

wtclaude added 2 commits 2026-09-08 17:01:18 +00:00

docs(website): the public surface, and the flag that decides what reaches it (Phase 14a) 9aee5920af

EVENTS.md gains what the phase settled -- a new §I section on the public
surface, the four API surface rows filled in, `listed` in §D, and the §J
rows for player profiles and mobile. EVENTS_PLAN.md records the 14a/14b
split and 14a as built. BACKEND_DESIGN.md points at the two tiers the
Phase 14a reads live on. MODULE_API.md records core's own capability list
beside a module's -- the same word, a separate list, and why.

Two things this phase corrected in the document rather than in code.

"Venue" was never a field. §I's screens table and the API surface table had
both described one since the first revision; there has never been a column,
a spec key, an input on Phase 13's form, or a string anywhere in either
repo. Rather than add a field on the way past to a public page, both
descriptions dropped it.

And the six public triggers' missing url variable, which this document has
carried as a promise since Phase 10, is now kept: `eventUrl`, carrying
`?run=`, arriving with the page it points at.

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

docs(website): the three defects the walk found, and the mount that answered one ed311a2e8d

EVENTS.md §I records that participation history is mounted twice and why --
the third screen to need the notificationPaths.js mapping, for the reason
the first two did -- and the three defects the live walk found with both
suites green on either side of it. EVENTS_PLAN.md says the same in one
paragraph under Phase 14a's verify line.

Two of the three were one mistake in two files: a split reading a STATUS
where it should read a clock.

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

wtclaude referenced this pull request from RunicGateway/website

2026-09-08 17:01:53 +00:00

feat(events): the public calendar, event pages and participation history (Phase 14a) #196

whitlocktech merged commit b6fefc5466 into edge

2026-09-08 17:04:30 +00:00

whitlocktech deleted branch docs/events-p14a-public-surface

2026-09-08 17:04:32 +00:00

whitlocktech referenced this issue from a commit

2026-09-08 17:04:33 +00:00

Merge pull request 'docs(website): the public surface, and the flag that decides what reaches it (Phase 14a)' (#224) from docs/events-p14a-public-surface into edge

Sign in to join this conversation.