Files

36 KiB
Raw Permalink Blame History

Status Panel settings page — the plan

One web page on the Ingest Mac that holds every setting the panel has, shows what runs on which computer, and works the same at every campus. Nobody edits config.json or a script by hand any more.

Companion files: settings-plan-details.md (every field, the data model, the apply pipeline, tests), settings-plan-audit.md (how the plan was audited and what was cut), settings-inventory.md (the 544 things the system has today, each with where it lives and how it is changed now).

1. What it is

The Status Panel is the Stream Deck page that is green when the room is fine and flashes red naming the problem. A watchdog program on the Ingest Mac runs it from one settings file. This plan adds a settings page on that same Mac, opened in any browser on the church network. Every setting is a labelled field with help: which computers exist and what runs on each, which keys are on the deck, what each key checks, what holding it does, when auto-fix may act, which Spotify playlist, switcher file, Dante devices, HyperDecks and MIDI links are in use. The page checks a change, shows in plain words what it will do, keeps a copy of every version, applies it safely, and the same page runs at every campus with that campus's own computers and gear.

Four words are used everywhere on it: a key (on the Stream Deck), a computer (anything we log in to, this Mac included), a fix (what holding a key runs) and a connection (Companion's link to one device: a HyperDeck, the Tascam, the switcher). The code you type to switch Editing on is the editing code. The file this Mac uses to log in to the other computers is the login key.

2. Where it runs and how you open it

  • It runs on the Ingest Mac as a second background program beside the watchdog, installed by the same install.sh. Plain Python, nothing to install. It is a separate program so a bug in the page can never stop the panel, and the page keeps working while the watchdog restarts.
  • Open http://na-ingest.local:8020/ from any Mac, PC, iPad or phone on the church network. The address is printed on the cheat sheet and written into the ALL key's note in Companion, so anyone who finds the deck finds the page.
  • Anyone on the network can look at everything: the deck, the computers, the logs, the history, the help. Changing anything needs the editing code: switch Editing on in the top bar, type the code once and your first name; the browser remembers both. The code is a setting in the campus's config.json, which lives in the private git repo, so everyone who has the repo has it; change it on Site setup › Site. The page never shows it to anyone who is not already editing. It is not a password for anything else. Five wrong tries lock the browser out for ten minutes.
  • It edits the live settings file the watchdog reads (in ~/Library/Application Support/status-panel/). From then on the Ingest Mac's copy is the truth for that campus; the git repo keeps a snapshot you export from the page.

3. What you see

Eight entries, always visible and readable by anyone: Overview, Keys, Computers, Logs, History, Help, and under a divider "Set up once": Site setup and Fixes. Nothing is hidden; the editing code is what lets you change things. A search box at the top finds any key, fix, computer, device or setting by name. Every screen starts with two sentences saying what it is for. Every field has a ? with plain-words help, its default, and "what you will see on the key" where that applies. Numbers nobody changes (thresholds, waits) sit under an Advanced fold with the default shown beside them. Buttons say what they do and to what: "Run this fix on the Lighting PC", "Check computers now", "Restart the watchdog".

+---------------------------------------------------------------------------------+
| STATUS PANEL - North Attleboro                             [search ________ ]   |
|                                  [!] 3 unsaved - Review & Apply  [Editing: off] |
+------------------+--------------------------------------------------------------+
|  Overview        |                                                              |
|  Keys            |                                                              |
|  Computers       |                     (screen content)                         |
|  Logs            |                                                              |
|  History         |                                                              |
|  Help            |                                                              |
|  -- set up once -|                                                              |
|  Site setup      |   Site . Schedules . Companion . Network & Dante .           |
|  Fixes           |   Spotify . ATEM                                             |
+------------------+--------------------------------------------------------------+

Overview

The first screen answers "is the room OK, and what do I do". In this order: the problems in the room (one sentence each, mirroring the red keys, with the action: "MIDI: TRK LIVEBOX lost — hold the MIDI key, or [Run the MIDI fix on the Tracks Mac]"); a separate grey Needs Chris strip for housekeeping (pages out of sync, a failed apply that was rolled back); the live deck drawn exactly as the Stream Deck looks right now (real colours, real words, blinking; click a key to open it); the computers, one line each with one word (OK / Problem / Can't see from here); three job buttons for the changes you named: Change the playlist, Add or remove a HyperDeck, Add a MIDI link (and a small "More jobs" menu: Add a computer, Make a PC program startable). Below: the watchdog (running 3 days), Companion (5.0.7, pages OK), alarms, when auto-fix may act next, the last change (when, who, note). Buttons: Restart the watchdog (for a purple deck; Start and Stop sit under it, and Stop asks you to type a word) and Silence alarms until midnight (same as the ALARMS key). One status legend for the whole page, printed once under the top bar's ?: OK / Problem (with the reason) / Can't see from here — ask at the computer / Not needed / Done by hand.

+----------------------------------------------------------------------------------+
| 2 PROBLEMS IN THE ROOM                                                           |
|  . MIDI: TRK LIVEBOX lost - hold the MIDI key, or [Run the MIDI fix on Tracks Mac]|
|  . LED: UHDJr does not answer a ping - check its power and cable                 |
| Needs Chris: nothing                                                             |
+--------------------------------------------------+-------------------------------+
| LIVE DECK                                        | COMPUTERS                     |
| [UP ][ALL ][REC ][AUD ][RF  ][SHOW][VID ][STRM]  | OK       NA Ingest (this Mac) |
| [ 19][HD1 ][HD2 ][HD3 ][HD4 ][HD5 ][HD6 ][TASC]  | OK       ProPresenter Mac     |
| [DN ][X32 ][DANT][MIDI][APPS][VIST][RST ][SPOT]  | Problem  Tracks Mac: Ableton  |
| [ALM][ATEM][OBS ][RESI][NET ][ING ][LED ][AREN]  |          stopped since 09:12  |
|   click a key to open it                         | OK       Lighting PC          |
| [Change the playlist] [Add or remove a HyperDeck]| OK       LiveStream PC        |
| [Add a MIDI link]                [More jobs v]   | OK       Bible TV PC          |
|                                                  | OK       Studio B             |
+--------------------------------------------------+-------------------------------+
| WATCHDOG  OK, running 3 days   [Restart the watchdog]  [Silence alarms until midnight]
| COMPANION OK, 5.0.7, pages OK     ALARMS ON     AUTO-FIX next: Sunday 06:30-13:30 |
| LAST CHANGE 2026-10-13 14:02 by Chris "HD2 has a disk now"        [History]      |
+----------------------------------------------------------------------------------+

Keys

Two tabs, Status page and Restart page, each drawn as the 8×4 deck people hold. Every key is a chip you can drag to move, drag off the deck to hide, or click to edit. Column 0 (UP / page number / DOWN) is locked. ALL and ALARMS can be moved but not deleted; NET can be removed at a campus that does not want it. Keys with no spot of their own (AXIENT 1, AXIENT 2, ULXD, PSM 1–3) sit in a tray labelled "Shown inside the RF group (no key of their own)". Each tab header holds its page number; the Restart tab's also holds the switch "this campus has no Restart page". A yellow note says "Layout changed: Apply will re-import the Status page" when it will.

Click a key and its editor opens beside the grid. Two lines at the top answer the only two things a person needs to know: WHAT THIS KEY WILL SAY (every word the checks can put on it) and HOLDING 2 s WILL: ("switch HyperDeck_2's connection off and on, also when green"). Then only the fields that matter: the label, the group members (for a group key), the checks as a short list, and When held (which fix, and "also when the key is green"). "Add a check" asks a question first, not a type: Is a device answering? Is a program running? Is a MIDI link up? Is a recorder OK? Is a setting right? Is Spotify playing? Is Dante complete? Is the lighting console sending? You pick the computer or device from a live list (Companion's connections, the Dante devices, that Mac's MIDI sessions and peers, its programs) and the page builds the check. The raw check types and ids live under Advanced.

STATUS PAGE (Page 19)  |  RESTART PAGE (Page 20)                      | KEY "HD2"   row 1, column 2
+-----+-----+-----+-----+-----+-----+-----+-----+                | WHAT THIS KEY WILL SAY: HD2 NO DISK,
| UP  | ALL | REC |AUDIO| RF  |SHOW |VIDEO|STRM |                |  HD2 LOW 12m, HD2 FULL 3m, HD2 NOT REC,
+-----+-----+-----+-----+-----+-----+-----+-----+                |  HD2 OFFLINE, HD2 NOT IN COMPANION
|  19 | HD1 |[HD2]| HD3 | HD4 | HD5 | HD6 |TASCM|                | HOLDING 2 s WILL: switch HyperDeck_2's
+-----+-----+-----+-----+-----+-----+-----+-----+                |  connection off and on (also when green)
| DOWN| X32 |DANTE| MIDI| APPS|VISTA|RESTRT|SPOT|                | Label [HD2 ]
+-----+-----+-----+-----+-----+-----+-----+-----+                | CHECKS                      [+ Add a check v]
|ALARM| ATEM| OBS | RESI| NET |INGST| LED |ARENA|                | 1. HyperDeck  connection [HyperDeck_2 v]
+-----+-----+-----+-----+-----+-----+-----+-----+                |    [x] this deck may have no disk
Shown inside the RF group: [AXIENT 1][AXIENT 2][ULXD][PSM 1][PSM 2][PSM 3]        |    Advanced v                   [Remove]
[+ New key v]                                                   | WHEN HELD  runs [Switch the deck's connection off and on v]
                                                                |            [x] also when the key is green
                                                                | [Run this fix on HyperDeck_2 now]   [Delete key]

"Which HyperDecks are in use" is simply which HD keys exist. The Add or remove a HyperDeck job on the Overview edits the HD keys, the REC group and each kept deck's "may have no disk" flag together.

Fixes (set up once)

The list of everything a hold can run (27 today): key text, plain words, how it is built, which computer, used by which keys, and whether auto-fix may run it by itself. You never type a shell command: a fix is built from fields. "Start Vista on the Lighting PC if it is not running" is Start a Windows program + computer + program + wait. The builders cover every fix that exists today (start or restart a Mac or Windows program, start a Windows service, reopen Ableton with its last set, restart a helper on this Mac, restart DVS, play the playlist, reconnect a connection, switch a HyperDeck off and on, reconnect a MIDI peer, put the switcher back to the saved file, power-cycle a PoE port, Pro Tools solo mode). A raw "Custom command" exists under Advanced for the day something new appears; it shows in red in Review and asks for the editing code again. Most fixes have a Run this fix now button (the ones that only start or reconnect something); it goes through the watchdog exactly like a hold, so the same guards apply.

Computers

Answers "what runs where" in one look. The Map has one row per computer: a status word, what it does for the panel, and which keys turn red if it dies. Click a row for the card: everything that runs there with a light each (the watchdog, Companion, helpers, scheduled tasks, services, the apps the panel watches, MIDI sessions), what it is used by, and a folded "Everything found on this computer" list from a live look. The Gear filter lists the devices that are not computers (switcher, HyperDecks, Tascam, LED processors, Shure units, Resi boxes, Dante switches) with address, kind, where it is in the building, which key watches it, and a light. The Setup tab is the one-time checklist per computer with a light per line (OK / Not done / Can't see from here — ask at the computer / Not needed / Done by hand), a [how] on every line, and the setup script for that computer generated with the right names in it, ready to copy.

COMPUTERS - MAP                                 [Check computers now]   looked 2 min ago
 status    computer           what it does for the panel                 keys that turn red
 Problem   Tracks Mac         Ableton, Dante sound card, MIDI "NA Tracks"  APPS MIDI DANTE   (Ableton stopped 09:12)
 OK        Lighting PC        Vista, Resolume Arena, rtpMIDI, +2           VISTA ARENA MIDI
 OK        NA Ingest (this)   watchdog, settings page, Companion, +9       everything
 OK        ProPresenter Mac   ProPresenter, Dante sound card, MIDI "NA ProP" APPS MIDI DANTE
 OK        LiveStream PC      OBS                                          OBS
 OK        Bible TV PC        Bible app                                    APPS
 OK        Studio B           Pro Tools, solo-mode helper, MIDI peer       APPS MIDI DANTE
 OK        NA Translation     Church Translate, Dante sound card           APPS DANTE
 [Gear]  ATEM . HyperDeck 1-6 . Tascam . X32 . LED x2 . Shure x6 . Resi x2 . Netgear x2 . Studio B PoE x4

Logs, History, Help

Logs: the watchdog log with filters (Holds / Fixes / Auto-fix / Errors), the auto-fix daily logs, the apply log. This is where "check the log" happens. History: every version ever applied, who, when, the note, what was different, with Go back to this and Undo the last change. Help: opens on four cards (Read a red key; Purple means the watchdog is down; Which computer or device is that; What is a connection), then the generated What each key does (one entry per key: what it checks, what holding does, what words can appear, which computers and devices are involved), a glossary of every word a key can show grouped by what to do about it, a printable one-page cheat sheet, a first-day walkthrough, "Where things are" (every file, folder, log and port per computer, the one page allowed to show file names), and "Things only a person can do".

Site setup (set up once)

Six sections, each opening on the few things a person changes:

  • Site: site name, this Mac's name and addresses, contacts for the cheat sheet, the alert message hook. Advanced: page port, the login key (present / not, public half to copy), helper paths, the editing code, install the staged folder, export the site bundle.
  • Schedules: when auto-fix may act by itself (Sunday 06:30–13:30 today) and the tick list of fixes it may run; alarms are always on. Changes to the panel wait while a HyperDeck is recording, not by the clock (a campus can add clock windows here too; NA has none). Advanced: the timing numbers (a fault must last 3 s, flapping, the 60 s cooldown, the 2 s hold).
  • Companion: the lights (variables exist, blink trigger, our pages exist, quiet Tascam module, ATEM module), the live list of connections with their module and which key watches each, "Add a key for it" for the ones nothing watches, the page-number buttons ("coloured on 96 of 97 pages" + Colour them now / Undo). Advanced: address, variable names, nav settings, grid, purple-after, export stamps.
  • Network & Dante: the port and gateway the NET key watches, the Dante switches, and the Dante device list (the one place the DANTE key's devices are edited, with key text and per-device fix), "Check the Dante network now". Advanced: the blip rule, survey interval.
  • Spotify: one field for the playlist (paste the link; name and song count fill in), the two waits, a light saying the watchdog may control Spotify.
  • ATEM: the switcher address, the saved file (upload, or pick the newest from the Google Drive folder; you see what differs before it is applied), what to keep in line (audio, each camera setting), "Check the switcher now". A switch "this campus has no ATEM".

Review & Apply

The yellow badge. A plain change list ("HD2: this deck may have no disk — yes → no"; "Spotify playlist: Christian EDM 2026 → Sunday Set 2 (SPOTIFY key, the play fix and the key guide)"; "LED moved from row 3 col 6 to row 2 col 5"), one sentence about what it will feel like ("the deck goes purple for about 5 seconds and comes back; the Status page is re-imported"), any warnings, a note for history, one button. Details show the exact commands for anything built. (What a key will say after the change is already on the key's editor, so there is no separate "preview run".)

4. Everything you can change

Grouped here; every single field is in the details table.

Group What Where on the page
Keys which keys exist, label, position or hidden, group members, hold "also when green", the page numbers, the Restart page's keys and jump positions, whether a Restart page exists Keys
Checks every check on every key, per type: connection, HyperDeck (may have no disk, follows the recording, full/low minutes), Dante device list, Shure/PSM channels and battery bars, Tascam, ping, program running (Mac or PC), helper loaded, web address answering, disk space, MIDI peer (session, peer, Mac, fallback address), macOS preference, Spotify playlist, Bonjour name, MIDI heard, lighting Art-Net, switcher audio/camera; per check: the fix, the short tag, wait before it shows Keys → key editor
Fixes every fix: what it is built from, computer, program, waits, "may close a running program", "never runs by itself", reconnect Companion afterwards; the raw command under Advanced Fixes, and inline from a key's When held
Computers each computer: display name, kind (Mac/Windows), log-in address, wake-on-LAN, does not answer pings, notes, what runs there (programs, tasks, services, helpers, MIDI sessions), network ports, done-by-hand ticks Computers
Gear where each device is, notes Computers → Gear
Schedules the auto-fix windows (overnight allowed) and the fixes it may run, optional clock windows for the change guard (none at NA: a recording HyperDeck is the guard), the timing numbers, the daily log folder and how long logs are kept Site setup → Schedules
Companion address, variable names, page-number button settings, grid, purple-after, export stamps; the connection labels are read live Site setup → Companion
Network & Dante port, gateway, blip rule, switches, survey interval, Dante devices and key texts and per-device fixes Site setup → Network & Dante
Spotify playlist, name, waits Site setup → Spotify
ATEM address, saved file, what to compare, node/library patterns Site setup → ATEM
Site name, this Mac's name/addresses, contacts, alert hook, port, helper paths, editing code Site setup → Site
Not editable on purpose colours, the words on keys, the 3 s/1 s/0 s debounce defaults, poll rates, the hold/ack mechanics, Companion's API paths, the shell commands the page builds — these are how the panel works, the same at every campus (guideline 1), and are listed in Help › Glossary and Where things are Help

The four things you named, end to end: A new MIDI link = Add a MIDI link → pick the Mac → pick its session and peer from the live list (or type them if that Mac is off) → pick the key it goes on (MIDI if there is one, otherwise a new key) → it gains the check and the reconnect fix → Review & Apply. A different playlist = Change the playlist → paste the link → Apply (the key, the play fix and the key guide follow; only the watchdog restarts, and the key's note catches up at the next page re-import). HyperDecks 2 and 4 only = Add or remove a HyperDeck → untick 1, 3, 5, 6 → the HD keys and the REC group change (the emptied cells stay empty, or one click moves HD4 next to HD2), the page re-imports → Apply. A new campus = section 6.

5. Computers and what runs where

Each computer is a record the page owns: name, kind, how to log in, what runs there and whether the panel watches it. Today's eight are seeded from the inventory: NA Ingest (watchdog, settings page, Companion, Resi bridge, lobby captions and screen, ProdCom, ProdDash, Spotify, ATEM Software Control, DVS + helper, Google Drive for the switcher files, plus the other background tasks that are not the panel's), ProPresenter Mac, Tracks Mac, NA Translation, Studio B Mac Studio (the solo-mode helper, Accessibility), Lighting PC (Vista, Arena, rtpMIDI task + service, firewall, Public profile), LiveStream PC (OBS task with admin rights, wake-on-LAN), Bible TV PC (Bible app at logon, Wi-Fi power settings). The live look runs a fixed set of read-only commands on each computer (what launchd has loaded, which tasks and services exist, which programs run, is the login key accepted, is the helper installed), never during a fix, never waking a PC, with every name quoted so a typed name can never run as a command. The devices that are not computers are listed from the checks that watch them, with a note per device for where it lives.

The Setup tab generates each computer's one-time script (the Mac authorise script, the DVS helper, the Windows setup, the Studio B solo-mode agent) with that campus's key and addresses filled in. You still run them yourself (section 12); the page shows which lines are done.

6. The other campuses

Apollo Beach, Woonsocket and Southcoast each already have a Mac Studio running Companion; the page and the watchdog go on that Mac. One settings file per campus = one site block plus that campus's computers, keys, checks, fixes, windows and gear. The code never contains a site name, an address, a label, a playlist, a path or a day name; everything site-shaped is data. Differences between campuses are plain differences in that data: fewer HD keys, no Studio B, another playlist, other Dante names, an extra PC, other page numbers, a Saturday evening service that runs past midnight.

Setting up a new campus: install Companion and the command-line tools on its Ingest Mac, copy the folder over, run install.sh --site <name> once (it uses the repo's sites/<name>/ if there is one, otherwise the empty template), do the Companion one-time steps (section 12). Then on the page: New campus from this one starts from a site bundle (export NA's from its page and copy it over with the folder, or pick any sites/ folder in the copied repo) and walks you through it — keep, rename or drop each computer (dropping one drops every key, check and fix that used it and lists them), map the connection labels, Dante devices and MIDI sessions from that Companion's live lists, set the playlist, switcher, network and schedule, Review & Apply. Everything copied from NA is flagged "copied from North Attleboro — check it" until touched. The repo keeps one folder per site (sites/na/, sites/<new>/); the page's Export site bundle gives you the zip to drop in.

7. Saving a change

  1. Draft. Every edit is saved on the page's server as you go, so a closed tab loses nothing, and two people see the same draft. If someone else changes the same field, the page says so and shows both.
  2. Check. On every change and again at Apply: the rules (ids, positions, windows, addresses, every fix's computer exists…), the watchdog's own loader on a temporary copy, a build of both pages in memory, and live warnings (a connection label not in Companion, a computer unreachable, a private playlist).
  3. Review. The plain change list, warnings, anything built as a command in red, what Apply will do.
  4. Apply, each step only after the previous one worked: keep a copy of the current version in History → write the new file in one go (and the new switcher file with it, if there is one) → wait for any fix that is running to finish → restart the watchdog (a change to key notes alone skips this) → prove it came back (its start stamp with the new file's fingerprint, no error, still alive after 10 s) → only then re-import the pages if the layout changed (key notes alone never trigger a re-import; the page refuses to overwrite a key someone added by hand in Companion and names its position) → recolour the page-number buttons if pages changed → rebuild "What each key does". If the watchdog does not come back, the previous version (and switcher file) is restored automatically, once, and Overview shows a red note until the next good Apply.
  5. While a HyperDeck is recording (that is what "live" means at NA; a campus may add clock windows) Apply is refused with the reason and when it ends; the draft stays saved. The same goes for Run this fix now, Restart the watchdog, re-imports, the switcher check and program installs. An Emergency button states the consequence, asks you to type LIVE and a reason, and is logged. Starting a watchdog that is down is always allowed. Silencing alarms is never blocked.
  6. Going back = History → Go back to this (or Undo the last change) through the same steps.

8. Safety

  • The page answers only on the church network; everything is readable, nothing changes without the editing code; every change is logged with name and address.
  • No passwords are stored or typed: the login key stays a file on the Ingest Mac; the Netgear login stays in the keychain (the page shows the one line to type in Terminal); the alert hook is masked everywhere; the editing code is a setting in the repo's config (whoever has the repo has it) and is masked for anyone who is not editing.
  • The page never runs a command before Apply. Fixes and checks are built from fields and run only by the watchdog, which applies its usual guards (cooldown, a recording deck is left alone, one MIDI fix at a time). The only raw command field is under Advanced, shown in red, and asks for the code again.
  • Never automated: the setup scripts on other computers, firewall or system changes, BIOS, macOS permission prompts, creating Companion's custom variables (unless a safe way is proven first), rebooting a device, power-cycling a PoE port or pushing a switcher file from a Run button, restarting the Resi bridge by itself, anything during a live service without the Emergency button.
  • Deleting a computer, key, fix or check shows everything that refers to it and asks. One confirmation style everywhere: a dialog that states the consequence; a typed word only for Emergency and for Stop the watchdog.
  • A watchdog restart never cuts a fix in half (it finishes the fix first; a HyperDeck switched off is always switched back on) and never loses acknowledged alarms (they are remembered across the restart).
  • The panel guidelines hold by construction: no per-key colour options exist (the one legacy "only during a service" flag sits under Advanced with a warning, and has no effect while alarms are armed all day); the schedule only governs auto-fix and the change guard, never alarms; a key with nothing to hold shows "pick a fix" in its editor; restart keys always have a fix; the gentle-fix rule for auto-fix is enforced.

9. Teaching other people

Help › four cards, then What each key does (regenerated on every Apply, so it is never stale), the glossary grouped by action (hold the key fixes it / check the device or cable / ask Chris), the printable cheat sheet (both grids, the colour legend, press = acknowledge / hold 2 s = fix, purple = restart the watchdog on Overview, the computer map, the page address, your contacts), and a ten-minute first-day walkthrough that needs no code: see the live deck, click a red key and read what it checks and what holding does, find the hold in Logs, the Restart page, ALARMS and auto-fix, which computer a key talks to, then watch a Review & Apply and History. Wording rule, enforced by a test: no file names, variable names, flags or Companion internals outside Advanced; the same four words everywhere. A newcomer explaining Overview, Computers and Help back in their own words in 20 minutes is the exit test of the first build step.

10. How it is built (short)

  • schema.py: the registry of every setting (type, default, range, help, example, which screen owns it, advanced or not). Tests keep it honest: every key the watchdog reads must be declared; every default in code must equal the schema's; every word a key can show must be in the glossary; today's config must still build today's pages exactly (apart from the key notes, which gain the page address and the markers); every one of today's 27 fixes must regenerate from its builder exactly.
  • settings/: the server (routes for the draft, validate, apply, history, live lists, logs, probes), the probes, the apply pipeline, the script generator, the key-guide generator, and one HTML/JS page with no framework.
  • Watchdog changes are additive: a start stamp, a restart that finishes the running fix, remembered acknowledgements, a "run this fix" verb, new settings read with today's values as defaults, Windows program checks that actually work (cmd.exe needs && echo pairs, not %ERRORLEVEL%).
  • install.sh validates the settings with the new code before touching anything, keeps the previous code for rollback, installs both programs, and never overwrites the campus's own files once the page exists.
  • Full detail: settings-plan-details.md.

11. Build order

Each step is deployed on its own, outside a service, with tests green, a live check on the deck, README/Help updated, committed. About three weeks of work in all.

Step What you get What you can try Size
0 Groundwork The registry and its tests; the watchdog's start stamp, safe restart, remembered acks, "run this fix" verb; install.sh changes. No page yet. Nothing changes on the deck. Hold SPOTIFY still works. 1.5 days
1 The page, read-only Overview with the live deck, Keys viewer, Computers Map/cards/Gear with live looks, Logs, History list, Help with the key guide and cheat sheet. Also the small Companion experiments (can it create variables safely, which OBS variable says "streaming"). Open it from your phone; see every computer and what runs on it; print the cheat sheet; a newcomer reads it back to you. 3 days
2 Editing + Apply Drafts, Review, Apply with rollback and the live-service guard; Site setup editors; key editor with check and fix builders; Run this fix now. Moving keys is refused until step 3. Change HD2 "may have no disk" and Apply; paste a new playlist link; add a Dante device; Go back to yesterday; try an Apply during a pretend service and see it refused. 4 days
3 Layout Drag keys, add/delete keys, the Restart page, page numbers; Apply re-imports pages and recolours page-number buttons. Move LED, add HD7, delete HD5, Apply, watch the deck change. 2 days
4 Jobs Change the playlist, Add or remove a HyperDeck, Add a MIDI link, Add a computer, Make a PC program startable; "Add a key for it" on unwatched connections. Untick HD1/3/5/6 and run on 2 and 4; add a MIDI link to a Mac that is off. 2.5 days
5 Setup + teaching The Setup tab with lights and generated scripts, Where things are, Things only a person can do, Install the staged folder from the page. Add a new PC, generate its script, run it, paste the result, watch the lights go green. 2 days
6 Other campuses Site folders, the template, the bundle export, New campus from this one. Build a demo campus on the MacBook with a Saturday night service and no OBS. 1.5 days

Later, if wanted: a Training copy of the page where nothing is real; an "OBS is streaming" live signal (if the experiment in step 1 finds the variable).

12. What you still do by hand

  • A new Ingest Mac: install Companion, xcode-select --install, Remote Login on, copy the folder over, run install.sh --site <name> once.
  • Companion, per campus: create the custom variables sp_state, sp_hb, sp_cmd, flash_tick and the blink trigger (the page gives you the file to import, or a button if step 1 proves it safe); add pages up to the Status and Restart numbers; install the ATEM module; import the quiet Tascam module where there is a DA-6400; name the Stream Decks. Why: Companion only allows these in its own UI; a full import would wipe the variables.
  • Every other Mac: Remote Login on; paste the generated authorise script (and the DVS helper where DVS runs) via ARD "Send UNIX Command as root"; make the Audio MIDI Setup sessions the page names; on Studio B run the generated solo-mode install and allow Accessibility on that screen. Why: root rights and permission prompts must come from a person at that Mac.
  • Every Windows PC: run the generated setup script as administrator, paste its RESULT block into the page; BIOS wake-on-LAN; keep the Lighting PC on Public; Vista autoload; the Bible TV Wi-Fi power settings (or Ethernet). Why: system and firewall changes need your OK; BIOS has no remote path.
  • Ingest Mac: type the Netgear login into the keychain yourself (the page shows the line); click Allow once on the Spotify prompt; keep Google Drive signed in for the switcher files.
  • ATEM saved file: save it from ATEM Software Control when the show changes, then "Pick the newest file" on the ATEM section, outside a service.
  • Code updates (you): scp the folder to the Ingest Mac as today, then Site setup → Install the staged folder. Drop the exported site bundle into sites/<name>/ when the repo should hold the latest snapshot. The repo stays private.

13. Answers so far

  1. Who can edit: the editing code lives in config.json in the private repo, so everyone with the repo has it (answered 2026-10-13).
  2. When changes must wait: only while a HyperDeck is recording (answered 2026-10-13). No clock windows at NA; the Sunday 6:30–13:30 window is for auto-fix only.
  3. The other campuses: Apollo Beach, Woonsocket and Southcoast, each with a Mac Studio already running Companion (answered 2026-10-13).
  4. Unwatched Companion connections (7 Govee lights, DiGiCo_OSC, m32, AbleSet, tcp-HyperDeck-1..6): stay unwatched (answered 2026-10-13).

14. How this plan was audited

Four readers inventoried everything configurable (544 items, one of them checking the Ingest Mac live, read-only). Three designs were written from different angles, scored by three judges, and merged. Four critics (completeness, simplicity, safety, feasibility) then audited the merged plan three times, finding 47, 59 and 51 gaps; the gap count never fell because each revision added machinery to satisfy the previous round. The result was a correct but heavy design (two access codes, a queue of pending changes, partial reloads, ~25 screens). This plan keeps its strong core (the live deck, the key editor's two preview lines, the fix builders, the computer map, the apply-then-prove pipeline, the live-service guard, the schema registry with sync tests, the multi-site model) and cuts the rest in favour of "simple and obvious": always restart on Apply instead of partial reloads; refuse during a service instead of queueing; one editing code; no training copy for now. Every finding and what became of it is in settings-plan-audit.md; every inventory item and where the plan handles it is in the coverage table.