Files
ProdDash/CLAUDE.md
T
Claude 1292ba33ba Keep module config and layouts in a per-machine data directory
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
2026-09-08 14:42:15 +00:00

50 lines
2.8 KiB
Markdown

# 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](SPEC.md) was the authority for the
initial build; [README.md](README.md) has run/configure/use instructions.
## Building a new module — read docs/MODULE-GUIDE.md first
**[docs/MODULE-GUIDE.md](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) 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.