fx_pairs/07_gbm passes a supersedes hash a first run cannot use, so a clean clone fails before any fit

[stefan-jansen]

case_studies/fx_pairs/07_gbm.py:102 declares SUPERSEDES_POPULATION: str = "06e9ea03f2f2" and line 258 passes it through unchanged:

execution, population = run_model_population(
    study, resolved, population_name=population_name, supersedes=SUPERSEDES_POPULATION or None
)

OfficialPopulation.create (case_studies/research/population.py:135) raises first population version cannot supersede another snapshot whenever the name has no earlier generation. run_log/ is gitignored (.gitignore:173), so a reader on a clean clone starts with an empty registry: the notebook fails at the population write, before any fit, on the path it defaults to. The same refusal fires on the narrowed-run path the notebook documents, because a caller-chosen POPULATION_NAME has no prior generation either.

supersedes_for_run (population.py:245) was written for exactly this and returns None when no generation exists. case_studies/cme_futures/06_linear.py:305 and case_studies/cme_futures/07_gbm.py:288 route through it. Every other SUPERSEDES_POPULATION in case_studies/ defaults to "" or None, where or None already covers the case; fx_pairs/07_gbm is the only non-empty default that bypasses the helper.

The suite cannot catch it: tests/pm_helpers.py:951 clears SUPERSEDES_POPULATION on the preview path, and fx_pairs/07_gbm runs preview by default.

Fix

supersedes = supersedes_for_run(
    study, population_name=population_name,
    declared=SUPERSEDES_POPULATION, execution_tier=EXECUTION_TIER,
)

plus supersedes_for_run in the import block.

This changes the .py blob, so 07_gbm.ipynb goes stale against its provenance stamp (source_py_blob 8a4786da2108) and guards fails until the notebook is re-run canonically. On the canonical path the helper returns the declared hash unchanged, so the outputs are expected to reproduce, but that has not been run.

Introduced by #590. Found by the RoboRev push gate (job 15511), not by inspection.

[stefan-jansen]

Correction, so the fix suggestion above does not mislead a later reader: supersedes_for_run and the two call sites I cited (cme_futures/06_linear.py:305, cme_futures/07_gbm.py:288) are on the cs6/cme_futures branch, not on main. The helper is not in the shared view yet, so the suggested fix could not be applied as written.

Fixed on main by #615, which resolves the generation from the registry inline instead.

Two things that report got wrong, both surfaced by the fx_pairs session:

The declared literal 06e9ea03f2f2 is not stale and should not be replaced. fx_pairs-gbm-validation-v1 carries two generations, and supersedes is hashed into the snapshot, so passing that hash is exactly what recomputes the published tip. Passing the tip's own hash would write a third generation. The literal is right; it needed a condition, not a new value.

Asking whether the name has any generation - which is what supersedes_for_run did - fixes the first run on a clean clone and breaks the second. Run 1 writes a generation whose own supersedes is None; run 2 sees a generation, offers the hash again, and create refuses because the snapshot it requires is what run 1 wrote. The same defect was in the branch helper and is fixed there too, with one condition added beyond #615's: the hash also resolves when the tip is it, which is how an author refitting under a corrected parameter publishes the next generation. cme_futures-gbm-validation-v1 was written that way three times, so a rule keyed only on "the tip already supersedes it" would fix the reader by making that publication impossible.