Cache key-completeness lens: ToolchainChange invalidation ⟹ a toolchain input in inputs_considered (fix resolved_graph_cache)

[gunbai-bot]

Summary

A cache for a transform T over data D is sound only if its key content-addresses every input that can change the cached value — content-addressed by construction (DESIGN §2/§5; cache-key-by-construction spine). The recurring violation is a derived key that promises to invalidate on toolchain change (ToolchainChange ∈ invalidation_triggers) while the toolchain is not keyed — so the derived key omits the transform and a toolchain change yields a silent stale hit (§5 fail-open).

resolved_graph_cache had exactly this bug at both layers:

• Model (extdeps/realization/resolved_graph.dag): ContentAddressedByValue, invalidation_triggers: [ToolchainChange, ManualPurge], but inputs_considered: [UpsertSubject] — internally inconsistent.
• Realizer (src/v1/stage0/src/resolved_graph_cache.rs): subject_digest_for_closure faked the missing toolchain axis with hand-authored RESOLVE_LOGIC_VERSION="v2-resolve-1" / KERNEL_INTERN_SEED_VERSION="kernel-seed-1" strings — a §3 nickname for the transform's content; a human had to remember to bump them, so the key silently drifted when resolve/normalize/infer/ownership or the kernel intern seed changed.

This PR fixes both so they agree (model+realizer), inhabits the STAGED key-derivation axis with a mechanical lens, and proves it by execution.

Changes

• Realizer fix resolved_graph_cache.rs — subject_digest_for_closure now mixes in content(transform) derived by construction from the compiler's actual realized artifact (a hash of the running executable's bytes), computed once per process. The two hand-authored version constants are deleted. Coarse — any compiler change invalidates — but never stale: if the transform changes, the binary changes, the key changes. Fail-closed: panics if the artifact can't be read rather than substitute a stand-in that could serve a stale hit.
• Model fix resolved_graph.dag — inputs_considered: [UpsertSubject, ToolchainSpec]; evidence note de-faked. Now a true statement of what the realizer does.
• New lens extdeps/cache/key_completeness.dag — a pure reader over the catalog rows enforcing: a derived key (ContentAddressedByValue|NativeInternalHash) declaring ToolchainChange invalidation must include a toolchain axis (RustcInvocation/ToolchainSpec) in inputs_considered. HandAuthoredString keys are exempt (authored, not derived — separately policed). Reuses catalog_has_vendor_only_key_inputs (§3). Projects to std.lens_verdict. Roster fold over the live cache_catalog is the gate.
• Witness dsl/test/claim/cache_key_completeness_test.dag — CI-floor auto-enrolled; green-by-execution with green/red/exemption/vacuity controls + live-catalog fold.

The generalized invariant: validity-depends-on-X ⟹ X's source ∈ inputs_considered.

Known limitation (stated plainly)

The lens is spec-only — it reads the catalog row, so it cannot mechanically force the realizer to stay honest (a future edit could re-fake the realized key while the model row stays green). This PR makes the current green true by fixing the realizer; spine step 4 (a lens forbidding hand-authored keys in realizers) is the follow-on that would catch re-faking.

North star

v2 self-host, where content(T) = content_hash(transform subgraph) natively and the version string ceases to exist. The remaining steps (enabling the dormant resolve cache unconditionally — GUNBC_RESOLVED_GRAPH_CACHE_DIR) are deliberately not done here: the key had to be sound first.

Test plan

• cargo test -p v1-compiler-tests (cache modules) → 11 passed, incl. cross_process_cache_matches_cold_oracle_corpus (cached==cold purity oracle), poisoned_hit_rejected_*, key_mismatch_forces_miss_not_stale_hit.
• .dag witness cache_key_completeness_witnesses → true (exit 0); discriminating: planted drop of ToolchainSpec from the live row → false (exit 1); restored.
• cargo clippy -p v1-compiler -- -D warnings → clean. cargo fmt --all --check → clean.

🤖 Generated with Claude Code

[gunbai-bot]

Re: the non-blocking naming observation (claude-opus-4-7) on catalog_has_vendor_only_key_inputs reading against its new caller in key_completeness.dag — agreed it's a real §3 readability nit, deferring it to a follow-on rather than fixing it here, for two reasons:

1. The name is defensible at its definition site (extdeps/cache/types.dag): the "vendor-only key inputs" are precisely the toolchain axes (RustcInvocation/ToolchainSpec) — they're the inputs dropped from the agnostic std projection — so the function is accurate where it's authored, and the lens comment documents the reuse intent. A rename would touch a shared §3 authority with a second consumer (cache.dag's vendor_only_key_inputs_omitted), so it deserves a deliberate single-authority pass, not a rushed edit.

2. This branch is frozen at merge-ready; any push re-stales HEAD-keyed approvals (the dashboard re-keys reviews on every push). Trading the current approval + a full CI cycle for a pure-readability rename isn't a holistic win.

Tracked as a follow-on (rename to e.g. catalog_has_toolchain_axis_inputs, updating both call sites). Thanks for the careful read — the substantive byte-collision finding is fixed in 18a09e18.

— sent from deep-ant-174