add-the-baseline-back-on-the-split-you-cannot-scorelisted
Install: claude install-skill tangxiangru/AutoR
# Add the baseline back on the split you cannot score
When the prediction is `base + residual`, it gets assembled twice: once on your
validation split, where you immediately compare it to labels, and once on the
graded split, where you compare it to nothing. Only the first is checked. Every
diagnostic runs on the first. Every selection decision is made on the first. The
file that is scored comes from the second.
Drop the `base` term on the graded path and not the validation path and you get
a submission that passes every check a run normally has - right row count, right
header, all finite, correct dtype - behind a validation number that is not
merely plausible but *better than the incumbent*, because that number was
computed from the correctly assembled validation array. The file is wrong by a
multiplicative constant. Under an error metric with no upper bound that is not a
regression; it is near the worst score the task can produce.
This is the specific failure that the standard advice cannot reach. A brief that
warns you a malformed file scores nothing, and a helper that enforces shape and
finiteness, are both correct and both silent here.
`select-on-the-file-you-would-ship` says the selection number must come out of
the writer's code path; that is necessary and not sufficient, because it is
satisfiable on the split you can score while the split you ship is assembled by
a different call.
## Rule 1 - one assembler, mapped over the splits
Do not write two branches. Write