nx_gatelib_walkparity_gate.nx

nx_gatelib_walkparity_gate.nx -- PROOF THAT THE SHARED WALK IS THE SAME WALK. ★★★THE ANSWER: THEY ARE IDENTICAL, AND THREE DIAGNOSES SAID OTHERWISE. ===== WHY THIS EXISTS ============================================ Wave 29 extracted a shared tree walk (gl_walk) and wave 30 tried to adopt it in nx_eco_graph_build, which had its own copy. Run back to back on the same tree the two walks scanned an IDENTICAL number of files (6368) but produced 7077 vs 7080 nodes and 14498 vs 14502 edges. Three names and four edges, about 0.04%, reproducible and unexplained -- so the adoption was reverted rather than shipped. Counts established THAT they differ. Only the NAME SETS can say WHAT differs, and that is the entire point of this organ. ===== THE CONCURRENCY PROBLEM, SOLVED PROPERLY =================== Two earlier diagnoses were wrecked by the same thing: this tree is edited by other sessions while a scan runs, so a sequential before/after diffs the clock rather than the code. The obvious fix is to freeze a copy of the subtree, which for 6000+ files is slow and itself racy. ★THE CHEAPER AND STRICTER FIX: run BOTH walks inside ONE PROCESS, back to back, then REFUSE TO REPORT unless both saw the same file count. The window shrinks from minutes to microseconds, and the file-count equality is a checkable precondition rather than an assumption -- if the tree moved mid-run the organ says so instead of blaming the code. Named for nx_gatelib because the invariant it protects is gl_walk's: if anyone changes the shared walk, this fails and names the drifted files. [root-dir] default runtime/_hdl_build expect_exit: 0 license_tier: ORIGINAL