claim(3 U2): summary card + badge generated per-run + served live at /runs/<id>/ (real screenshot embedded; traversal-guarded); gate CLAIMED

machine-docs/DECISIONS.md

@@ -1206,3 +1206,37 @@ Per-test rows come from per-tier pytest `--junitxml` (stdlib XML parse — no ne
 when present (what the PR comment + dashboard link to), else the unique run domain. The dashboard
 service will serve this dir read-only at `/runs/<run_id>/...` (wired in U2/U4 via a host bind-mount on
 the dashboard swarm service). Decided here; serving deferred to U2/U4 where the card/screenshot need it.
+
+---
+
+## Phase 3 / U2 — artifact serving + the dashboard deploy mechanism (SETTLED, 2026-05-31)
+
+**Serving (U2.3, R3/R6).** The dashboard (`dashboard/dashboard.py`) now serves per-run artifacts at
+the stable URL **`/runs/<run_id>/<file>`** for a strict allow-list of filenames
+(`results.json`, `summary.png`, `screenshot.png`, `badge.svg`, `summary.html`). Path traversal is
+blocked three ways: filename must be in the allow-list, `run_id` must match
+`^[A-Za-z0-9][A-Za-z0-9._-]*$` (no `/`, no `..`), and the resolved realpath must stay inside
+`CCCI_RUNS_DIR`. The run artifact dir `/var/lib/cc-ci-runs` is bind-mounted **read-only** into the
+dashboard swarm service (`nix/modules/dashboard.nix`, `CCCI_RUNS_DIR` env). Live + verified over
+HTTPS at `https://ci.commoninternet.net/runs/...` (200 for the four artifact types; 404 for
+traversal / non-whitelisted / nonexistent).
+
+**Dashboard deploy mechanism on the LIVE host (important, migration-era).** The flake's
+**`#cc-ci` nixosConfiguration currently targets the `cc-ci-hetzner` MIGRATION host** (cloud-init /
+dhcpcd / gptfdisk / bootspec hardware — confirmed via `nix store diff-closures` of a
+`nixos-rebuild build` against the running system: a large hardware-level delta, NOT just the
+dashboard). The **live running host is a different machine** (`cc-nix-test`, 100.90.116.4). Therefore a
+full `nixos-rebuild switch --flake …#cc-ci` against the live host is **WRONG** — it would
+mis-reconfigure the live host's hardware/networking. **Do not run it on the live host** until the
+migration settles the host↔config mapping (operator territory).
+- To roll a **swarm service** (dashboard/bridge/etc.) on the live host, run the module's own
+  idempotent **reconcile** (it only does `docker load` + `docker stack deploy` for that one service —
+  zero host-config impact, reversible). U2.3's dashboard roll was applied exactly this way: built the
+  new image via `nixos-rebuild build` (non-activating), then ran the produced
+  `cc-ci-reconcile-dashboard` (image `cc-ci-dashboard:466582e0aae0`). The change is fully
+  Nix-declared (committed `dashboard.nix` + `dashboard.py`), so any correct rebuild reproduces it.
+- **Caveat / operator finding:** because the live host's current system generation still embeds the
+  OLD `deploy-dashboard` reconcile, a re-activation of *that* generation (e.g. a reboot before the
+  host is rebuilt from current `main`) would roll the dashboard back to the pre-U2.3 image. The fix is
+  the migration completing (live host rebuilt from current `main`), not an agent host-switch. Filed so
+  it isn't lost; surfaced to the Adversary via inbox.