Golden-master zero-dep/full fixtures already drifted ~8480 diffs from a clean corpus scan, unrelated to any pending PR #3005

Found while working on #2990 (COBOL/JCL semantic-coverage assessment)

Blessing the golden master for #2990's cobol.py changes, I diffed an unmodified engine (origin/main, no edits) against the committed tests/golden_master_zero_dep_audit.json, scanning the exact pinned corpus (language-crucible tag v1.2.0 = commit 77bc85e, confirmed via git cat-file -p v1.2.0 — it's an annotated tag pointing at that commit, matching _crucible_pin.py's PINNED_TAG). Result: 8478 pre-existing differences, entirely unrelated to any code change.

What the diffs look like

Almost all are git-history-derived signals for files utterly unrelated to any recent engine work — e.g.:

MISMATCH .../css/threejs_app_ui/.../editor_main.css/.../Architect: Expected "Unknown Architect", Got "squid-protocol"
MISMATCH .../css/threejs_app_ui/.../editor_main.css/.../Authorship Centralization: Expected 0.0, Got 100.0
MISMATCH .../sqlite/flask_tutorial_sqlite/.../schema.sql/.../Raw Churn Frequency: Expected 0.0, Got 1.0

Plus corpus-wide ranking/percentile shifts in "Global Ecosystem Summary" (cumulative_risk/stability/churn highest/lowest lists) that follow from those per-file changes. I ruled out the two obvious causes:

• Not a stale local tag: git rev-parse v1.2.0 returns the annotated tag object's own SHA (a real gotcha — don't confuse it with the tagged commit); git rev-parse v1.2.0^{commit} correctly resolves to 77bc85e, matching GitHub's /repos/.../tags list endpoint. The pin is not stale.
• Not shallow-vs-full clone: re-scanning a fresh --depth 1 clone of the exact pinned tag (matching CI's own git clone --branch "$ref" --depth 1) produced a larger diff (10271), not a smaller one — so this isn't purely a full-clone-vs-CI-shallow-clone artifact either, though it's clearly git-history-sensitive (Architect/Churn/Centralization are all blame/log-derived).

Why this matters

Any contributor who runs crucible_check.py --update --yes and commits the result without independently isolating "what did MY change actually move" (the way I did for #2990, diffing two same-corpus scans against each other rather than trusting the raw regenerated fixture) will silently bake ~8500 unrelated lines of drift into their PR's "bless." That's a real risk given CLAUDE.md's standing authorization to bless without asking.

Ask

Investigate what's actually producing this drift (my best guess, unconfirmed: something about how the last legitimate bless's environment computed git-log/blame history differs from a plain git clone/worktree checkout of the same commit — possibly --single-branch, a .git/shallow artifact, or a difference in git log --follow behavior across git versions) and either fix it or re-bless deliberately with a documented reason. Until then, anyone blessing should follow #2990's approach: diff an unmodified-engine scan against a your-branch scan of the identical corpus checkout, and patch only the leaves that differ between those two — never trust a full crucible_check.py --update diff at face value when the baseline might already be stale for unrelated reasons.

Not fixed as part of #2990 — it's unrelated to that PR's scope and both fixtures there were blessed via the scoped-diff method described above, confirmed to move only cobol-attributable leaves.