Three ERPs run side-by-side from the same codebase. Each is a different CATALYST_MODULES bundle on the same app.py, with its own data directory and URL.
Shared instrumentation, sample requests, approval chains, grant-linked finance, role-scoped queue visibility.
instruments finance queue calendar stats attendance inbox notifications admin
Staff, vehicles, receipts, payroll, task coordination — the Ravikiran-style ops bundle.
finance personnel vehicles attendance receipts todos inbox notifications admin
HPC queue, notifications, admin for a compute cluster. Narrowest bundle — proves the propagation rule lights up correctly even at minimum.
compute notifications inbox admin
cd ~/Documents/Scheduler/Main ./scripts/start_erp_triad.sh # start ./scripts/start_erp_triad.sh --status # show PIDs + ports ./scripts/start_erp_triad.sh --stop # stop all three
Each instance gets its own data/demo_triad/<variant>/ directory, its own port, its own DB. Stopping one does not affect the others. The launcher kills any process holding the port before re-binding, so re-runs are safe.
The launcher reads app.py three times with three different env-var bundles. Same bytes. Different behaviour. That is the propagation rule, made tangible:
templates/attendance.html shows up next deploy in Lab and Operations (both have attendance in their bundle), not in Compute (which doesn't).Architecture detail in MODULE_PROPAGATION.md. Per-variant module bundles defined canonically in lab-scheduler/docs/ERP_DEMO_VARIANTS.md (both source in private repo).
The launcher works; the seed data does not yet, for two of the three variants. Lab is fully seeded; Operations and Compute boot into empty DBs (their seeders are TODO stubs). Day-2 of the 7-day fire plan is implementing those bodies.