add-the-baseline-back-on-the-split-you-cannot-score

# 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 ...