Files

T

Waters ChurchandClaude Opus 5 adac3a4785 Ship ProdDash as one app: its own Node, its own copy, a .dmg

Installing is dragging ProdDash to Applications. The app carries the
dashboard and the Node that runs it, so nothing has to be installed first and
nothing can go missing underneath it.

  ProdDash.app/Contents/
    MacOS/ProdDash            the launcher
    Resources/node/bin/node   Node 24.21.0 LTS, fetched and checksum-verified
    Resources/app/            server.js, public/, modules/

Everything mutable stays where it already was, in ~/Library/Application
Support/ProdDash — and that now includes app/, the copy of ProdDash that
actually runs. The copy is not ceremony: ProdDash updates itself in place,
and nothing may write inside a signed .app. So the bundle holds a read-only
baseline and the data directory holds the running copy, which means both
routes to a new version keep working and don't fight — installing a newer
.app replaces the copy, while a copy that has already updated itself past the
bundle is left alone.

build.sh now assembles all of it: fetches Node against nodejs.org's published
checksums (cached in .cache/), embeds the server, compiles each module's
native helper so the Mac running ProdDash needs no compiler, signs nested
code before the bundle, and builds the disk image. --dev skips the payload
for launcher work, which still runs against a checkout.

Signing is set up for a Developer ID with the hardened runtime and
notarisation (--notarize), and falls back to ad-hoc when no such certificate
is installed. Entitlements are split by what each binary actually does: JIT
for node, audio input for the launcher and for module helpers that read one.

Built and run end to end: first-run install, bundled node, dashboard and
admin serving, re-seed in both directions (newer app replaces an older copy;
an updated copy survives), disk image mounts and its app verifies.

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

2026-09-11 12:38:46 -04:00

3.6 KiB

Raw Permalink Blame History

ProdDash

Modular production dashboard web app for Waters Church, developed in this repo. The app lives at the repo root and is built: zero-dependency Node server (server.js, Node 18+), dashboard shell client in public/, admin page at /admin, modules in modules/, and a native macOS menu-bar launcher in launcher/macos/ (Swift, no dependencies — the shipped macOS app: it carries the server and its own Node runtime, supervises them, and owns the macOS permissions modules declare; see its README). Runtime state (module config, named layouts) is written to a per-machine data directory outside the checkout (PRODDASH_DATA_DIR overrides; see README "Where settings are kept") — never add code that writes runtime state into the repo folder. SPEC.md was the authority for the initial build; README.md has run/configure/use instructions.

Building a new module — read docs/MODULE-GUIDE.md first

docs/MODULE-GUIDE.md is the authority on the module contract (manifest, client factory + moduleApi, optional server entry, title-bar controls). The rules that matter most:

A module is one self-contained folder in modules/ — never modify the shell (server.js, public/) to add one. Installation = the admin page's Available modules (downloads from the repo into the data directory), or drop the folder and restart; configure in /admin.
All settings in the admin page (configSchema / instanceSchema) — never a separate setup page, hand-edited file or env var. Dependencies ship inside the module folder (zero deps is the norm). Everything the module does runs inside its server entry — no helper scripts, companion programs or daemons the operator starts by hand; a listener or decoder is started in init() and stopped in stop(). Declare "proddash": ">=x.y.z" and bump the module's version on every change.
Browsers never call upstream services directly; the module's server routes proxy everything (no CORS, secrets stay server-side).
Style with the shell's CSS variables only, scoped under [data-module="<id>"]; survive upstream loss (reconnect + setStatus).
Verify against the guide's testing section and resilience checklist. Mocks for the existing upstreams: node tools/prodcom-mock.js (ProdCom) and node band-lineup-display/tmp/pp-mock.js 1599 (ProPresenter).

Reference code (read-only forks — don't develop these here)

prodcom-listener/ — live ProdCom transcript web app. Zero-dependency Node server.js that serves public/ and proxies /prodcom/* (including the SSE transcript stream) to the ProdCom API at config.json → prodcomUrl (default http://10.3.11.152:24480). Good reference for: SSE handling, reconnect logic, channel colors/filtering, PWA install.
band-lineup-display/ — backstage Electron app (stage lineup photos with mic/pack labels) plus ProPresenter Now/Next:
- band-lineup-display/propresenter-core/ — shared ProPresenter 7/20 client, no deps, no Electron. All ProPresenter quirks live here (PP20 runtime route discovery, arrangement-expanded slide totals, uuid-then-name live-item matching). Reuse this rather than re-implementing ProPresenter access.
- band-lineup-display/propresenter-app/ — standalone Now/Next web display.
- band-lineup-display/tmp/pp-mock.js — mock ProPresenter API for testing without the real thing: node tmp/pp-mock.js 1599, then point at 127.0.0.1:1599.

Upstream sources: ProdCom Listener lives at github.com/michaelmcgary2008/prodcom-listener; BandLineupDisplay exists only on the production machine. These folders are snapshots, not submodules.

3.6 KiB Raw Permalink Blame History

ProdDash

Building a new module — read docs/MODULE-GUIDE.md first

Reference code (read-only forks — don't develop these here)

3.6 KiB

Raw Permalink Blame History