"""THE CV (user directive 2026-08-22 v5): building-GroupKFold, deployment-faithful. ONE protocol lives here, deliberately. Buildings are assigned to K folds, stratified on battery-failure count and location (travel centrality). For each fold: ONE fit on the TRAIN buildings' full closed-pair history (that is exactly what the deployed held-out path does - a foreign fleet's labels were all known when the submission was built, so "before and after" is deployment-legal, not a leak), then for each of the 48 scenario times the TEST buildings are planned as a STANDALONE fleet with the DEPLOYMENT-EXACT planner state (submit.py's static-path knobs, including the cold-start floor gate, which is structurally inert here because every fold trains on 60+ unique deaths vs the gate's 20) and costed by the real evaluator. THE SCORE: per scenario, the fold costs are SUMMED - every building sits in exactly one test fold, so the sum is the out-of-fold cost of ALL 24 buildings for that scenario - and THE SCORE is the mean of those 48 all-building totals. Same information as the fold-mean average (x5), but in the familiar full-fleet-per-scenario magnitude. Fidelity pass (v5): this harness is the closest possible local twin of the held-out deployment path - both public and private splits are ~2x unseen fleets served by that path (Docker dress rehearsal, phase 27). Coherence with the public board is CHECKED against recorded public deltas, never fitted (a calibrated pricing layer was explicitly rejected). The in-fold purge (v4) was dropped: it made the CV stricter than the deployment it represents and bought no public coherence (identical sign flips). Why this protocol (2026-08-22, the day the temporal purge fell): * It simulates the HELD-OUT deployment path: the competition's private split contains fleets not in the packaged train table (submit.py's static foreign-fit branch exists for exactly this). Train-on-some-buildings / plan-the-others-as-a-fleet is that path, measured. * The test group is planned as a COMPLETE fleet, so there is no per-building cost-attribution problem (the old LOBO objection) and no partial-fleet count bias (phase 26): the count rule operates on the test fleet's own sum(p42), exactly as deployment does on a held-out fleet. * Instrument history: the pure temporal purge (fleet-wide) fell to three public refutations in one day (phase 56: count-coupling, label-process ghosts, era-calibration leak - its fits saw the future of the same fleet). The pure building split (v3) fell the same evening: it still sign-flipped all three public killers (phase 57 alignment check) because its fits saw the scenario's own era through other buildings. v4 removes both channels structurally. What NO local split can price (public-measured, 4x): the public fleet's uncatchable tail and its train-absent ghost devices - count-coupled and label-process candidates stay report-only regardless of what this harness says. * Diagnostics are PLAN-DERIVED only (cost blocks + in-window swap count), so ANY method that yields a plan can be scored. Candidates must win at ~flat swaps; count-coupled wins are untrustworthy (public evidence, 4x). Superseded protocols live in git: the temporal-purge harness (sole validator 2026-08-22, retired same day) at f5f3fda; the earlier walk-forward/static/ screen/LOBO family at 2000281. Usage venv/bin/python -m batteryswap_example.cv bgkf # THE SCORE venv/bin/python -m batteryswap_example.cv cand