Service Times 1.0.0: every campus's services, and what production can't use #20

2026-09-24T11:27:11-04:00

christian commented

2026-09-24 11:27:11 -04:00

Four campuses run different Sunday schedules and take their resi feed from one of two broadcast origins. When a service goes wrong — a machine crashes, a feed is unusable — the booth has to know which service at which campus can be altered, and which campuses are riding on the one that broke. That lived in people's heads and in messages.

The times come from the church website rather than from configuration, because the site is what stays current when services change through the year. Each campus page carries a "Times" block; the module reads it and re-reads it on a timer. Two things on those pages are not services and are excluded on purpose: the main-office hours in every page's footer, and the "Office Hours" block Apollo Beach carries inside its own Times section.

A mark on a service — issue, replay, do not use, with a note, and for a resi campus which of the origin's services it is taking — is the booth's shared answer, so it lives in the module's server state and reaches every tile over SSE. Per-tile settings would let two campuses disagree about whether the 9:30 is going out. Marks are written to the data directory so a restart mid-morning does not lose them, and they expire after 36 hours.

Campuses added by hand in admin are a stopgap for a site that has not caught up yet: as soon as the website publishes that campus, the site's times take over and the admin health line says the manual line can be removed.

Verified: the parser against all five live campus pages, and 31 unit tests plus 16 client checks, each proven to fail under mutation — both parse guards, the merge rule, dependent recording, and three client behaviours. The suite runs under JavaScriptCore, since the authoring machine has no Node; node modules/service-times/parse.test.js runs the parser half natively.

Not verified: the module guide's resilience checklist needs a running ProdDash — upstream loss and recovery, two tiles side by side, and tile removal leaving no timers behind. Worth running on the ProdDash box before a Sunday.

🤖 Generated with Claude Code

Four campuses run different Sunday schedules and take their resi feed from one of two broadcast origins. When a service goes wrong — a machine crashes, a feed is unusable — the booth has to know which service at which campus can be altered, and which campuses are riding on the one that broke. That lived in people's heads and in messages. The times come from the church website rather than from configuration, because the site is what stays current when services change through the year. Each campus page carries a "Times" block; the module reads it and re-reads it on a timer. Two things on those pages are not services and are excluded on purpose: the main-office hours in every page's footer, and the "Office Hours" block Apollo Beach carries inside its own Times section. A mark on a service — issue, replay, do not use, with a note, and for a resi campus which of the origin's services it is taking — is the booth's shared answer, so it lives in the module's server state and reaches every tile over SSE. Per-tile settings would let two campuses disagree about whether the 9:30 is going out. Marks are written to the data directory so a restart mid-morning does not lose them, and they expire after 36 hours. Campuses added by hand in admin are a stopgap for a site that has not caught up yet: as soon as the website publishes that campus, the site's times take over and the admin health line says the manual line can be removed. **Verified:** the parser against all five live campus pages, and 31 unit tests plus 16 client checks, each proven to fail under mutation — both parse guards, the merge rule, dependent recording, and three client behaviours. The suite runs under JavaScriptCore, since the authoring machine has no Node; `node modules/service-times/parse.test.js` runs the parser half natively. **Not verified:** the module guide's resilience checklist needs a running ProdDash — upstream loss and recovery, two tiles side by side, and tile removal leaving no timers behind. Worth running on the ProdDash box before a Sunday. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

christian added 1 commit 2026-09-24 11:27:11 -04:00

Service Times 1.0.0: every campus's services, and what production can't use 3ca960baf6

Four campuses run different Sunday schedules and take their resi feed from one
of two broadcast origins. When a service goes wrong — a machine crashes, a feed
is unusable — the booth has to know which service at which campus can be
altered, and which campuses are riding on the one that broke. That lived in
people's heads and in messages.

The times come from the church website rather than from configuration, because
the site is what stays current when services change through the year. Each
campus page carries a "Times" block; the module reads it and re-reads it on a
timer. Two things on those pages are not services and are excluded on purpose:
the main-office hours in every page's footer, and the "Office Hours" block
Apollo Beach carries inside its own Times section. The parse is bounded to the
Times heading and stops at either.

A mark on a service — issue, replay, do not use, with a note, and for a resi
campus which of the origin's services it is taking — is the booth's shared
answer, so it lives in the module's server state and reaches every tile over
SSE. Per-tile settings would let two campuses disagree about whether the 9:30 is
going out. Marks are written to the data directory so a restart mid-morning
does not lose them, and they expire after 36 hours so last week's never greet a
new Sunday.

Campuses added by hand in admin are a stopgap for a site that has not caught up
yet: as soon as the website publishes that campus, the site's times take over
and the admin health line says the manual line can be removed.

Verified: the parser against all five live campus pages, and 31 unit tests plus
16 client checks, each proven to fail under mutation — both parse guards, the
merge rule, dependent recording, and three client behaviours. The suite is run
here under JavaScriptCore, since this machine has no Node.

Not verified here: the module guide's resilience checklist needs a running
ProdDash — upstream loss and recovery, two tiles side by side, and tile removal
leaving no timers behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

christian added 1 commit 2026-09-24 11:34:07 -04:00

Merge remote-tracking branch 'origin/main' into claude/service-times-module f542b34b6c

# Conflicts:
#	README.md

christian merged commit ea3a920d5e into main

2026-09-24 11:34:40 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: michael/ProdDash#20