EPS Dashboard

What happened

PM session triage + dispatch. Archived #655, restarted the stalled #651 session by hand, and spawned autonomous --auto sessions for #657, #559, #642, #641 — the strongest follow-ups off the 52-deep awaiting-promotion pile, anchored on extending #623's alignment-direction predictor (ρ=0.73 for base sycophancy) across more behaviors and to leakage. All five (657 / 559 / 642 / 641 / 651) ran to completion and are now parked at awaiting_promotion.
#653 → followups_running. User launched a same-issue follow-up ("install-validated-reladder") to fix the install / saturation problems in the rank-1 read/write LoRA-geometry experiment.
Research-discussion sessions. Formalized the "context C induces a behavioral profile $p_\theta(C)$ " framework; read + summarized the rank-1 read/write weight-geometry cluster (#604, #621, #650, #653, #568, #637) and grouped the related clean-results.
Removed a CLAUDE.md rule that forced anchoring theory math to Dan's Slack message (the rule was only ever in the working tree, never committed; removal brought CLAUDE.md back to HEAD).

Applied workflow improvements

no workflow-fixable problems found today

Other problems & notes

#651 did not auto-restart (HELD — architectural / behavior-contract judgment call). #651 blocked with failure_class: infra but reason: HF Hub 504, not no_compute_available; the watcher's capacity-retry pass deliberately only re-drives the no_compute_available subclass, so a cap-exhausted transient-HF block parks for a human. Thomas had to restart it manually and asked why it didn't self-heal (session 730d8e82). Whether to widen the auto-retry whitelist to transient-HF (and other non-compute transient-infra) reasons with backoff is a real design call — it changes which blocked reasons self-heal (a watcher behavior contract) and risks masking genuine HF-side failures. Suggested action: Thomas decides whether to add a bounded transient-HF auto-redrive rung to autonomous_session_watch.py's capacity-retry pass; not auto-applied because it's a self-healing-policy / public-predicate change.
GPU-backed follow-up expectation gap on #653 (HELD — spends compute / working-as-designed). Thomas expected an automatic follow-up to have fixed the experiment's problems (session 33364133). What actually happened: the 0-GPU epm:free-analysis-followup-run DID fire (re-restricted the read/write verdict to the 3 installed cells); the GPU-backed follow-up machinery lives at Step 10 and only fires after task.py promote, and #653 is still parked at awaiting_promotion. Working as designed, but the recurring confusion is a real signal. Suggested action: none auto-applied — making GPU follow-ups auto-run before promotion spends compute on un-reviewed results (a cost/judgment call); the alternative is a docs/UX clarification, but Step 10's post-promotion gate is already documented in CLAUDE.md.
"Remove that rule" commit confusion (RESOLVED in-session, no bug). When removing the uncommitted CLAUDE.md rule, git add CLAUDE.md && git commit reported nothing staged (exit 1); the session briefly suspected a concurrent session had swept the edit. Actual cause: removing an uncommitted working-tree addition leaves the file identical to HEAD, so there is nothing to stage. No fix needed — flagged only so the "concurrent-committer swept my edit" reflex doesn't get over-generalized to the no-op-after-revert case.

My thoughts

Highlighted results

no results promoted today