test_no_new_torch_before_dotenv_vm_entrypoints red on main: 4 scripts missing load_dotenv, reds Step 9c gates fleet-wide
Highlight text on any card (body, plan, or an event) to anchor a comment, or leave a whole-task comment here. Mention @claude to summon a reply.
No comments yet.
Goal
Restore tests/test_shared_vm_thread_caps.py::test_no_new_torch_before_dotenv_vm_entrypoints to green on main by adding the missing load_dotenv calls to the four violating entrypoints, so the Step 9c test gate stops reporting a pre-existing fleet red as if it were the task's own payload failure.
Evidence — reproduced on clean main by the orchestrator, not inherited from a report
$ git rev-parse --abbrev-ref HEAD
main
$ uv run pytest tests/test_shared_vm_thread_caps.py::test_no_new_torch_before_dotenv_vm_entrypoints -q
rc=1
FAILED tests/test_shared_vm_thread_caps.py::test_no_new_torch_before_dotenv_vm_entrypoints
Violators named by the failure, four scripts, all missing a load_dotenv before their torch import:
scripts/issue1901_mlpdense_fold_analysis.pyscripts/issue1901_mlpdense_fold_figures.pyscripts/issue2254_firstk_ctxext_sensitivity.pyscripts/issue2378_lenmatch_fig.py
The test is on main and so are the violators, so this is not a feature-branch artifact.
Why it matters beyond one task
The Step 9c test-verdict gate selects tests by changed-file mapping, so any task whose payload maps onto test_shared_vm_thread_caps.py inherits a red that has nothing to do with its own diff. That forces every affected session to spend a review round establishing "pre-existing, payload-external" attribution — which is exactly the verification the gate exists to make unnecessary. Task #2546 paid that cost across four consecutive review rounds (rounds 9-12), each one re-deriving the same attribution: the round-9 breadcrumb, round 10's re-fenced 1500 s lint run, round 11's branch-vs-main skew check, and round 12's independent re-confirmation.
Two failure modes it creates, both worse than the red itself:
- Attribution work repeated per session — every affected task re-establishes the same fact, and a reviewer who skips that step either blocks a clean payload or waves through a genuine failure.
- Desensitization — a standing red in a gate trains sessions to treat that gate's failures as background noise, which is how a real regression in the same file would ship. This is the same dynamic the
.claude/rules/repo-root-uncommitted-state.md§ watcher-pass note warns about for recurring alerts.
Scope
- Add the missing
load_dotenv(orchestrate.env.load_dotenv, per the lint rule--check-dotenv-before-hf-importand CLAUDE.md § Upload Policy: "New direct-upload scripts useorchestrate.env.load_dotenv, never baredotenv") to each of the four scripts, placed before the torch/HF import the test checks. - Re-run the test to green on
main. - Confirm the four scripts still run (or at minimum still import) after the insertion — a
load_dotenvat the wrong position can shadow an intentional env override.
Do NOT weaken, skip, or xfail the test — it guards a real property (env must load before torch so thread caps and HF cache redirects apply on the shared VM). The fix is the four missing calls.
Provenance
Surfaced by the /issue 2546 round-12 implementer while attributing its own lint/pin-sweep results, and then independently reproduced on clean main by the orchestrator before filing (rc=1, same four scripts). Related standing rule: .claude/rules/gotchas.md § dotenv-before-torch; lint twin workflow_lint.py --check-dotenv-before-hf-import.