Skip to content

📦 WP-154c — fix(goldens): freeze-goldens stops re-copying what it cannot re-freeze

Engineering log · Phase 14 — Augmentation upstreaming to fuse, v0.7.0

🔗 Depends on WP-154 · Needed by none

⬅️ WP-154 · Roadmap · WP-154b ➡️

WP-154c — the mechanism stops reintroducing what it was already told to remove

WP-154 closed by naming why WP-132's wall came back: make freeze-goldens was a blind cp goldens/*.json goldens/frozen/$(MINOR)/, with no notion that fixture_checksums.json and data_checksums.json are generator-derived — their producers render synthetic images through fuse-augmentations, so once that package's generator moves, no future code change can satisfy "the frozen copy still holds". WP-132 removed the two files that wall produced; WP-140 and WP-153 each re-froze them anyway, because a copy of a green golden is green until the generator moves, and nothing in the copy path could tell the two categories apart. Removing the files a third time at WP-159 would only restart the same clock.

The fix is a schema field rather than a human checklist item. fixture_checksums.json and data_checksums.json now carry "freezable": false; every other live golden is freezable by omission, which keeps the six pure-code goldens' files untouched and states the rule as "false is the exception, not true". scripts/freeze_goldens.py replaces the Makefile's inline cp: it reads each live golden's freezable field and copies only the eligible ones, reporting what it skipped rather than skipping silently. Makefile's freeze-goldens target calls it. scripts/check_goldens.py's _parse_golden reads the same field, and check_golden rejects — with a named error, not a silent skip — any golden it finds under goldens/frozen/ whose freezable is false; this should never happen once the freeze path is fixed, but a manual copy or a retroactively-flagged old snapshot must still be caught by the gate that reads the frozen tree, not assumed away.

Two things this row does not do. It does not touch either goldens/frozen/ directory — WP-154 already removed what needed removing, and this row's job is only to stop the mechanism, not to re-litigate the removal. And it does not re-freeze anything: no live golden's values changed, so goldens/fixture_checksums.json and goldens/data_checksums.json gain one field and nothing else.