bug(dashboard): first launch dies silently when the global npm prefix is root-owned (EACCES on on-demand npm install)

[Fmarzochi]

Summary

On a root-owned global npm install (distro Node, sudo npm install -g @egchq/egc), the dashboard dies silently on first launch: egc init prints EGC Dashboard starting at http://localhost:7890, the detached process exits immediately, and the port refuses connections. No error is shown anywhere.

Root cause (confirmed in the field)

Two stacked problems:

1. Silent by design on the init/install path: scripts/lib/dashboard-launch.js spawns scripts/dashboard.js detached with stdio: 'ignore' and prints the success line before knowing whether the server survived, so any startup failure is invisible. The CLI path (scripts/dashboard.js start) does have a 3 second readiness check; the init/install path has none.
2. First-launch dependency install inside a root-owned directory: scripts/dashboard.js start runs npm install inside the installed package's dashboard/ directory when dashboard/node_modules is missing. On a root-owned prefix that fails with EACCES: permission denied, mkdir '/usr/local/lib/node_modules/@egchq/egc/dashboard/node_modules'.

Same class of problem as the npm link note fixed in #1231: a step that assumes the package directory is writable.

Evidence

Reported and reproduced by @rathaur-ankit in #1218 (Ubuntu 26.04 LTS, distro Node 22 with npm 9, zsh, sudo npm install -g): initial report, follow-up after egc init, and a foreground run confirming the EACCES with a screenshot. See the thread from #1218 (comment) onward.

Scope note

The dashboard component is under an active architecture decision (rework vs replace), so the fix direction for problem 2 is intentionally left open here. Problem 1 (announcing success with no readiness check on the init/install path) is worth fixing regardless of that decision.

Credit

Found, reproduced and diagnosed in the field by @rathaur-ankit.

[Fmarzochi]

This issue turned into the right place to talk about the dashboard's future, so here is the plan, and it is open to the community.

The vision: two doors, one core

The current dashboard is a read-only panel. What EGC needs is a working tool: one core of operations with two doors, the CLI and the panel, where you pick the door you prefer. Everything the panel can do, the CLI can do, and the other way around, by construction. That includes installation: the doctor screen becomes buttons that run the exact same operation as the command, with the equivalent command displayed next to each button, so every click teaches the terminal (and the CLI can point back at the panel).

Architecture, non-negotiables included

1. Operations library first. A single registry of named operations (name, params, JSON result) wrapping what already exists. The CLI keeps calling the library directly and never depends on a running server.
2. The server exposes the same operations over HTTP for the panel (POST /ops/<operation>).
3. Security from slice one. The server keeps its strict 127.0.0.1 bind, and operation routes require a local token (file under ~/.egc/, handed to the panel on load, same mechanism as the port injection). Today the server has no auth and permissive localhost CORS; that is acceptable for read-only telemetry, not for buttons that execute.
4. Parity is enforced by a test, in the same spirit as our install.sh/install.ps1 parity tests: every operation in the registry must be reachable from both doors, and CI fails when one door drifts.

What already exists (start here, do not rewrite)

• scripts/lib/install-lifecycle.js: buildDoctorReport, repairInstalledStates, uninstallInstalledStates (structured reports; the CLI on top is just formatting)
• scripts/lib/install-executor.js + scripts/lib/install/apply.js: applyInstallPlan; scripts/lib/install-targets/registry.js: 31 target adapters with a uniform contract
• scripts/lib/crusher/metrics.js: the whole egc gain ledger (aggregateBreakdown)
• scripts/lib/state-store/: the SQLite layer with a complete query API
• dashboard/server.js: plain node:http (no framework) plus ws for the live feed; today it shares no code with scripts/lib, and slice 1 fixes that

The slices

Each slice is a separate help-wanted issue, opened right after this comment: (1) core operations library, no UI; (2) operable doctor/targets in the panel; (3) egc gain in the panel; (4) session bus in the panel, advanced. Slice 1 comes first; 2 and 3 build on it; 4 is the most ambitious and the most unique, because nobody else has a session bus.

@rathaur-ankit found the bugs that pushed this forward (#1218) and is warmly invited to take any slice, and so is everyone else reading this. Standard flow: comment on the slice issue to claim it, fork, DCO sign-off, the CLA bot greets your first PR, I review and mentor, credit on merge, green CI required.