Building the target environment from scratch consumes the whole wall clock

[lorenzoliuzzo]

Follow-up to #15, measured on the real run described in #18/#19.

#15 gave the session permission to install the target repo's dependencies, which was necessary — without it the suite is unrunnable. But a fresh worktree means a cold environment on every attempt, and for this target the dependency is torch. The transcript shows the session spending roughly 20 of its 25 minutes on it: uv sync --extra dev, a retry under UV_HTTP_TIMEOUT=120, backgrounding the install and polling it, then falling back to .venv/bin/pip install --index-url https://download.pytorch.org/whl/cpu torch torchvision. It was killed mid-install.

So the fix for #15 traded "cannot verify at all" for "spends its entire budget preparing to verify". For any repo with a heavy dependency, the worker is dominated by environment build time rather than by the work.

Note the second-order cost: this is precisely the shape that meters as $0.00 (#18), so the most wasteful runs are also the least visible to the spend caps.

Acceptance criteria

• The environment build is amortised across runs rather than repeated cold — e.g. a shared package cache mounted into the worktree, or a reusable per-target environment my-coder prepares once outside the session's clock.
• Time spent preparing the environment is not charged against the same budget as the work, or the wall-clock cap accounts for it explicitly.
• Documented guidance for pointing a heavy target at a prepared environment (--test-command already exists for my-coder's own verification; the session needs the equivalent).

[lorenzoliuzzo]

Measured both sides of this on the same host, which narrows the fix considerably:

Scenario	real
uv pip install torch, cold cache	35m 49s (user 0m6s — essentially all download)
same install, warm cache	1.5s

So the cost is not "building an environment" per se — with a populated ~/.cache/uv it is free. The cost is that the first run pays for the download, and it pays out of the session's wall clock, where it is indistinguishable from the session being slow.

That suggests the fix is smaller than this issue originally framed it. Rather than a prepared per-target environment, my-coder needs to:

• keep the package cache warm across runs (it already survives — the worktree is throwaway, ~/.cache/uv is not), and
• not charge a cold download against the session budget: warm the cache outside the session (a deterministic pre-step, which is the shape everything else in my-coder already has) so the session only ever sees the 1.5s path.

The follow-on effect is worth stating: a cold-cache run reliably exhausts its clock, and per #18 that is exactly the shape that meters as $0.00. The first run against any new heavy target is therefore both the most expensive and the most invisible.

[lorenzoliuzzo]

Confirmed by re-running the same target with the cache now warm:

{"outcome": "success", "detail": "opened draft PR #7", "issue": 1,
 "files_touched": ["model.py", "tests/test_model.py"],
 "tests_passed": true, "cost_usd": 0.67, "attempts": 1}

Same repo, same issue, same caps as the run that timed out — the only difference is that ~/.cache/uv was populated. 25 minutes and a total loss became 0.67 USD and a green draft PR. The diff was independently verified afterwards: the depthwise-separable block is correct, the model is 6,813,563 parameters against its 10M budget, and CI passed on the PR.

So the cold download really is the entire problem, and warming the cache outside the session is the whole fix.