mid-run-course-correct

name	mid-run-course-correct
description	Run WHILE a long GPU/train/eval/cert run is in flight and its intermediate signals are in — a first checkpoint's eval, a first-seed passAt1, a live reward/VSC/loss curve, a cert top1/KL, or the moment a number lands that "looks wrong" or "too clean". This repo shares ONE 128 GB Spark GPU across 5+ concurrent sessions, so a run that is already floored, mis-metriced, or measuring a harness artifact is burning a slot every other agent needs. Use to score the trajectory mid-flight, tell a HARNESS ARTIFACT (0/0-both, broken verifier, floored metric) from a real capability failure, and STOP a floor-determined NULL early — without p-hacking it green. Also fires on "should I keep this run going", "the first eval looks off", "is this worth the GPU", "kill it or let it ride".
metadata	{"short-description":"Process-reward trajectory gate for long GPU runs: score intermediate signals, catch harness artifacts, stop a floored NULL before spending more"}

mid-run-course-correct

A process-reward gate for the trajectory, not just the final number. A long run on this cluster is an ongoing spend on a shared, one-at-a-time GPU. This skill is the mid-flight checkpoint: at the first real signal, decide keep / re-run-clean / STOP — and never convert an honest floor into a false GO by moving the goalposts.

Companion skills — load them, don't re-derive: rlvr-harness-traps (the artifact taxonomy this gate leans on), spark-cluster-ops §1-2 (the one-GPU-job invariant, SESSION-COORDINATION.md), ci-artifact-drift (make claim-check, never lower a gate), session-handover (the failure ledger). This skill makes NO capability/uplift/AGI claim; canClaimAGI stays false regardless of what you decide.

When this fires

You have a run in flight (RLVR train, adapter eval, low-RAM cert, judge sweep) AND at least one intermediate signal is available: a checkpoint eval, a first seed, a live curve on TrainWatch, or a partial cert. Do NOT wait for the full run to burn down before applying it.

0. Situational awareness first (read-only, seconds)

• Confirm you actually own the GPU slot and the run is yours to touch — check SESSION-COORDINATION.md (live CLAIM/OWNS ledger) before you kill or restart anything another agent launched.
• Pull the live curve instead of guessing: the trainwatch skill / dashboard at spark-2f2d:8420 (funnel :8455) gives elapsed + ETA + progress + loss. Report KTA (elapsed / ETA / progress) proactively — that framing is what makes "is it worth continuing" answerable.

1. Artifact-vs-failure triage — DO THIS BEFORE any keep/stop call

The core question: is the disappointing number a measurement artifact (fix the harness, the idea is untested) or a real floor (the model genuinely can't; stopping is correct)? Walk the rlvr-harness-traps checklist against the live signal:

• 0/N on BOTH base AND adapter (passAt1 0/0, or a "broken verifier"/VSC=0) → suspect the HARNESS first, per rlvr-harness-traps §A. Most common cause: a chat/instruct base fed RAW prompts on a code task → no fenced python block → code_reward scores 0 for everything. Verify base passAt1 ≫ 0 BEFORE reading any uplift. If base==adapter==0 on a chat model's code task, it's the template (chat_wrap), not the model — this is a re-run-clean, not a NULL.
• passAt1 0/0 but the verifier DID engage (VSC non-zero, e.g. step-RLVR 0.158→0.138) → this is a GENUINE FLOOR, not a broken verifier (§D). The model can't produce fully machine-verified derivations on unseen families. Stopping is correct; recording NO-GO is the honest result.
• A number that reconciles only if the metric changed mid-run → comparability break (§C): a pod on a pre-change main fell through to meanReward while another reports passAt1. Not difficulty/noise — a metric mismatch. STOP and re-run pinned to ONE commit; don't average them.
• meanReward moved but passAt1/VSC didn't (or moved down) → abstention artifact (§D). Never quote meanReward as the capability number. A +0.024 meanReward with VSC falling is not progress.
• Target modules {...} not found (chars of "all-linear") → §E config footgun, not a capability result. Fix --target-modules attn-mlp and re-run; the trajectory so far measured nothing.

If it's an artifact: the run measured the harness, not the idea → fix + re-run-clean (the harness is the deliverable). If it's a real floor: go to §2.

2. Score the trajectory — keep / re-run-clean / STOP

Once you've ruled artifacts in or out, grade the load-bearing metric (passAt1 / VSC for RLVR; top1 + KL for cert) — NOT the vanity curve (loss down, meanReward up):

• KEEP — the load-bearing metric is moving the right way with headroom, and ETA is affordable given who else needs the GPU. Let it ride; keep reporting KTA.
• RE-RUN CLEAN — an artifact/comparability break was found (§1). Kill now, fix the harness/config/pin, relaunch. Killing early here SAVES the slot; finishing a mis-metriced run wastes it. Prefer re-run clean over "clearing a candidate" on mixed metrics.
• STOP (floor-determined NULL) — the verifier engaged, the metric is floored, and more steps won't change a real capability limit. Stopping now is the win. Record it honestly.

3. Do NOT p-hack the stop

When you STOP on a floored NULL, the failure mode is manufacturing a GO instead of banking the NULL:

• Never lower a gate threshold to force a pass (ci-artifact-drift) — if the gate flips NO-GO, that IS the result. Don't swap passAt1→meanReward, cherry-pick the best seed, re-roll temperature, or trim the eval set to clear it.
• A real, powered, CI-excludes-0 uplift is STILL NO-GO if it trips an integrity gate (e.g. a nonzero reward-hack rate). Uplift that learned to game the grader is correctly failed (rlvr-harness-traps §F).
• Temp=0 for any headline judging; keep the registered metric as the arbiter, not the artifact.

4. Land the decision so it isn't relitigated

• Run make claim-check before committing any result doc so the no-overclaim gates + lint_claims.py stay green and no capability claim slips in.
• Log the NULL (or the artifact + re-run) to agi-proof/failure-ledger.md — a floor is a finding; the ledger is what stops the next session re-launching the same doomed run.
• Note the decision in SESSION-COORDINATION.md / the session handover, freeing the GPU slot and telling the next agent what NOT to re-run. canClaimAGI stays false.

Bottom line

A clean harness that produces an honest, floor-determined NULL — caught early — is a SUCCESS: it saves a shared-GPU slot and adds a real finding to the ledger. A green number bought by finishing a mis-metriced run, a gamed reward, or a lowered gate is not.