claim(M1): per-recipe history sourced from local /var/lib/cc-ci-runs artifacts (full history, not Drone 100-build slice)

history_for() now enumerates run dirs' results.json, groups by recipe, sorts
newest-first by finished timestamp (mixed numeric+named ids — timestamp is the
only correct key), caps at HISTORY_CAP=30, skips malformed/empty/no-recipe dirs.
Overview + badges + /runs + security guards + stdlib-only unchanged.
Local verify: 13/13 unit tests; full-fixture vs 308 real results.json →
bluesky-pds=8 in exact ts order, plausible capped 30 newest, edge dirs skipped.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

machine-docs/DECISIONS.md

@@ -1566,3 +1566,16 @@ so the fallback (decouple version-record from retained volume) is NOT needed. Me
   at the full 20-enrolled set. WC8 disk-hygiene (`ci-docker-prune`) keeps residue bounded.
 Conclusion: keep all-enrolled with retained volumes; revisit only if `/` free drops below a single
 recipe's largest restore (~1–2G working set). No recipe dropped for disk.
+
+## phase dash — per-recipe history sourced from local run artifacts (2026-06-17)
+The dashboard's per-recipe history page (`/recipe/<recipe>`) sources its run list from the local
+`/var/lib/cc-ci-runs/*/results.json` artifacts (complete: 308 finished runs; durable; already
+bind-mounted read-only), NOT the Drone `…/builds?per_page=100` slice (root cause: that 100-build
+window dropped each recipe's older runs out of view after the regall sweep → most recipes showed 1
+run). Newest-first by the `results.json` `finished` timestamp (run ids are MIXED numeric + named, so
+only a timestamp sort is correct — `int(run_id)` would crash on `m2r-*`/`ab-*`); display-capped at
+`HISTORY_CAP=30`. Status derived from the per-stage `results` map (no top-level status field). The
+OVERVIEW (`/`) and badges keep their Drone latest-per-recipe source unchanged. Deliberately did NOT
+merge Drone live "running" status into history (optional per plan; re-adds the network dependency the
+local source removes; overview already shows live status). Retention: 308 parseable runs present, no
+trim job observed → adequate; revisit only if a cap is ever needed.