fix(deploy): serve fresh dashboard on hosted deploys + staleness guardrail

[aterrylu]

Problem

Hosted (make deploy) deployments were silently serving a stale dashboard. The server prefers packages/server/src/_embedded_dashboard/ over packages/dashboard/dist/ (run.ts resolution order), but _embedded_dashboard is a binary-build artifact — and the deploy pipeline mishandled it two ways:

• make deploy's rsync shipped a stale local _embedded_dashboard to the remote (it lives under src/, not excluded alongside dist/node_modules).
• make prod rebuilt dashboard/dist but never refreshed the embedded copy.

Net: the freshly-built dist sat unused while the server served a months-old embedded bundle — it caused an actual regression on forge and needed manual patching multiple times.

flowchart LR
    subgraph before["Before"]
      L["local stale<br/>_embedded_dashboard"] -->|rsync ships it| R1["remote _embedded_dashboard (stale)"]
      MP1["make prod → dist (fresh)"] --> D1["dist (fresh, unused)"]
      R1 -->|server prefers #1| S1["serves STALE ❌"]
    end
    subgraph after["After"]
      MP2["make prod: rm -rf _embedded_dashboard<br/>then build dist"] --> D2["dist (fresh)"]
      D2 -->|"no embedded → fallback #2"| S2["serves FRESH ✅"]
    end
    style S1 fill:#fdd
    style S2 fill:#dfd

Loading

Fix — keep embedded a binary-only concern; hosted serves dist

• make prod: rm -rf packages/server/src/_embedded_dashboard before the vite build → the hosted/tsx server falls through to the fresh dist. (Runs on the remote during make deploy, so it also self-heals any pre-existing stale copy there.)
• make deploy: --exclude _embedded_dashboard from the rsync → the local binary artifact is never shipped.

Guardrail — make staleness observable, not silent

The recurring pain was diagnosing stale serves. Now:

• Server (dashboardBuild.ts + run.ts): reads the served bundle id (hashed index-*.js) + index.html mtime; logs them at startup and exposes them on /api/host as dashboard: { build, builtAt }. The best-effort reader now logs on failure (it's only called after existsSync confirmed index.html, so a throw is a real read/permission problem — not a benign null).
• Dashboard (dashboardFreshness.ts + StatusBar.tsx): reads its own loaded bundle id and console.warns when the server is serving a newer one (deploy-while-open, or a stale serve). Unknown ids (dev server / older server) never warn.

Testing

• make check green: biome, tsc, server tests (incl. extractDashboardBuildId + the readDashboardBuild failure-logs-and-doesn't-throw case), 246 dashboard tests (incl. isDashboardStale truth table + getLoadedDashboardBuildId DOM reads).
• /polish (code-reviewer + simplifier + silent-failure-hunter): reviewer ship-ready (verified Makefile flow, non-breaking /api/host, no new leak on the unauthenticated endpoint); simplifier no-change; silent-failure-hunter's one MEDIUM (bare catch swallowing the reason) applied.
• Will verify on forge: no _embedded_dashboard present, startup log shows today's build mtime, /api/host carries dashboard.

Operational note

forge's duplicate install was cleaned up out-of-band as part of this work: a crash-looping systemd-user autonomos.service (running a stale ~/.local/share/autonomos CLI install) was fighting pm2 for :3100; it's been stopped/disabled/removed so a single mechanism (pm2) owns the port. ~/.autonomos config/data preserved.

ADR

This encodes a deploy-contract decision (the embedded dashboard belongs to the binary distribution; the hosted server serves dist). An ADR draft is being surfaced to TeamLead.

🤖 Generated with Claude Code

[nox-0x]

Approving — fix correctly attacks both legs of the stale-serve bug (rsync exclude on the source side, rm -rf on the build side) and the staleness guardrail is well-bounded: isDashboardStale only fires when both ids are known, the /api/host payload addition is non-breaking for existing consumers (CLI status, ConnectionStatusBarItem), and the unauthenticated endpoint only leaks a bundle hash + build mtime. Tests cover the truth table and the failure-logs-not-throws case.

A couple of follow-up observations (non-blocking):

• The staleness check in StatusBar runs once on mount; the PR description says it catches "deploy-while-open" but in practice it only catches "reload-after-stale-deploy". Worth either qualifying the claim or piggy-backing on ConnectionStatusBarItem's existing /api/host poll if you want true mid-session detection.
• extractDashboardBuildId's regex relies on the entry script being the first /assets/index-*.js reference in the HTML, which holds for current Vite output but would silently drift if Vite ever reorders modulepreload links before the entry. The DOM-side selector is already more precise (script[type="module"]); tightening the server regex similarly (e.g. requiring <script type="module"[^>]*src="...") would make the two readers agree by construction. Not urgent.