nx_inc_compile.nx

nx_inc_compile.nx -- LN10: THE PER-MODULE INCREMENTAL BUILD CACHE. CONTRACT (buildroot/knowledge/compare/lang.plan, rung LN10, verbatim): "Per-module cache keyed by the closure sha the build door already computes (the B2 cache keys whole targets); gate proves a one-file edit rebuilds only its dependents and the output equals a full build" WHAT ALREADY EXISTED, AND WHAT WAS MISSING ------------------------------------------ B2 (nx_sov_build_run's bld_cache_cas) is a WHOLE-TARGET content-addressed cache: key = sha256 over the EXPANDED closure text plus the compiler and assembler shas, value = the finished elf. It is excellent and it is not this rung. Its unit is ONE target and its key costs a full closure EXPANSION (a 32 MiB buffer, every byte of every dependency) paid once PER TARGET -- so it can answer "rebuild this target?" only after doing most of the work of deciding. The question a multi-target session actually asks is the DEPENDENTS question: "I edited one file -- which targets must rebuild, and which must not?" Nothing in the estate could answer that without re-walking every closure. THE KEY WAS ALREADY SOLVED AND IS NOT RE-INVENTED HERE. nx_closurehash is the estate's ONE closure ruler; /api/build forks it on every build and records `closure_sha256` into <target>.provenance. This organ NEVER computes a closure sha. It parses the ruler's own per-file listing -- which is already a per-MODULE manifest, one `<sha256> <bytes> <name>` row per source -- stores those rows as the per-module cache, and REPLAYS the ruler's own key on a hit. There is exactly one closure-sha implementation in the estate and this is not a second one. WHY PER-MODULE SHAS ARE SUFFICIENT -- stated because a cache that returns a stale object is a silent miscompile, the worst class this estate tracks: closure_sha = sha256 over the rows "<name> <sha>" in discovery order. It therefore changes iff the member SET changes or some member's SHA changes. The member set can change only because some module's import list changed, or because a name started resolving to a different file -- and BOTH of those change that module's bytes, hence its sha. So: every recorded module still hashes to its recorded sha <=> closure_sha unchanged. The gate proves the forward direction against the LIVE ruler on every subject it touches, and the neg-control proves the converse (a one-byte edit MISSES). The one assumption is that resolution is the SAME resolution the ruler performed -- which is why the resolver lives in nx_incclosure_lib and both organs call it. A private copy here would be the exact defect that produces a false HIT. THE INVARIANT THAT MAKES A SHARED MODULE TABLE SOUND (and the dependents mechanism itself): for every target record T and every module M in T's member list, icm_rsha[M] is the sha that was used when T's key was recorded. It is maintained by ic_record(): writing a NEW sha for M INVALIDATES every other target whose member list contains M (announced, one INC-INVALIDATE line each). Without that,