Claude
1292ba33ba
Connection settings, API keys, enabled flags and named layouts were written to config/ inside the checkout, so a re-clone or reset from main started the server with nothing configured. They now live in a data directory outside the app folder: Windows %APPDATA%\ProdDash macOS ~/Library/Application Support/ProdDash other $XDG_CONFIG_HOME/proddash, else ~/.config/proddash PRODDASH_DATA_DIR overrides the location (a relative path resolves against the app folder, so "config" restores the old spot). The first start after upgrading copies an existing config/modules.json and config/layouts/ into the data directory, so nothing has to be re-entered. If the directory cannot be created or written, the server warns and falls back to config/ rather than refusing to start. A proddash.json in the data directory overrides the checked-in defaults (port, adminPasscode). The startup banner prints the directory in use, /api/admin/state exposes it, and the admin page shows it under the Modules heading. Admin config and layout writes that fail on disk now report the path instead of a generic server error. README, MODULE-GUIDE and CLAUDE.md updated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RNYUv9EyrGSFmCnmH7WYKH
2.8 KiB
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/. 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 = drop the folder, restart, configure in/admin. - 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) andnode 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 Nodeserver.jsthat servespublic/and proxies/prodcom/*(including the SSE transcript stream) to the ProdCom API atconfig.json → prodcomUrl(defaulthttp://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 at127.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.