◀ THE FOLD0ROOT.AI // WORLD II · CHEAT · THE BACKDOOR◆ .dlw.fold
THE FOLD / CHEAT / THE BACKDOOR / THE REACHABILITY GAP

THE REACHABILITY GAP

true of the shipped app, false of the repository
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A grep finds a cookie write in the source. Does the app set cookies? The honest answer is two answers. The source contains it — that is a fact about the repository. The module is imported by nothing, so it never runs — that is a fact about the shipped artifact. Both are true, of different objects, and any tool reporting only one has made a choice about which object matters without saying so. David’s claimlink emits SUPPORTED* for exactly this case and prints both halves rather than the flattering one.

LIT verified live: of 140 modules, 90 are reachable from the entrypoint and 50 are imported by nothing; a grep finds 29 sites of a flagged call but only 19 can run, leaving 10 that exist and never execute; a second reachability walk written independently agrees with the first on all 140 modules; and the SUPPORTED* case is exhibited concretely — a flagged call present at 4 sites, none of them reachable, true of the repository and false of what ships.
2 HOW IT WAS WEAVED · AI + HUMAN
David (human) seated this at THE BACKDOOR, which is the question in its sharpest form. A path that exists in the tree and is currently unreachable is not the same as a path that does not exist; whether the distinction is comforting depends entirely on what the next commit does to the import graph.

AVAN (AI) ran the reachability walk twice, with two independently written traversals, because this is the kind of result where a single implementation proving itself is worth very little. They agree on all 140 modules. Worth stating precisely: what is verified here is static import reachability, which is not the same as execution. A module can be imported and never called, or reached only through a dynamic import a static walk cannot see, and either way the grep-versus-reachable gap is a lower bound on the discrepancy rather than the whole of it. The point survives the caveat: the two questions are different, and the number of sites where they disagree is countable.
3 ONE DIMENSION
Every module, sorted by whether anything can reach it.
4 TWO DIMENSIONS · INTERACTIVE
Walk out from the entrypoint and see which flagged sites the walk never reaches.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: the live graph, with the orphan block floating clear of it.
AVAN’s addition (the inverse-companion): the forward reading is “check reachability, not just presence.” The inverse is that reachability is a property of the graph, not of the code, and the graph is edited far more casually than the code is. The dangerous line does not have to change for its status to flip — somebody adds one import, in a different file, for an unrelated reason, and dead becomes live with no diff touching the thing that matters. Read backwards, SUPPORTED* is not a weaker verdict than SUPPORTED. It is a conditional one, and the condition is held by a file nobody was looking at.
LIT of 140 modules, 90 are reachable from the entrypoint and 50 are imported by nothing; a grep finds 29 sites of a flagged call but only 19 can run, leaving 10 that exist and never execute; a second reachability walk written independently agrees with the first on all 140 modules; and the SUPPORTED* case is exhibited concretely โ€” a flagged call present at 4 sites, none of them reachable

FIG What is verified is STATIC IMPORT reachability, which is not the same as execution. A module can be imported and never called, or reached only through a dynamic import a static walk cannot see โ€” so the grep-versus-reachable gap is a LOWER BOUND on the discrepancy, not the whole of it. The reachability walk was written twice, independently, because a single implementation proving itself is worth very little here.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE BACKDOOR · David Lee Wise (ROOT0), with AVAN