docs(registry): the fabricated-edge blind spot is cross-language, not Python

journeys/testgraph.json

@@ -1,6 +1,6 @@
 {
   "target": "testgraph",
-  "note": "Hand-authored 2026-08-06, NOT drafted by testgraph.propose — `propose --repo .` found 0 route handlers and said so, correctly: testgraph is a CLI, and CLI entry points are the first item on its own declared blind-spot list. One journey per CLI surface, entries being each module's `main` plus the one function that carries the surface's real work (so a change to that function is named even if `main` is untouched).\n\nWHY THIS REGISTRY EXISTS, AND WHAT IT IS NOT EVIDENCE FOR: the ledger held zero rows because the only two repos with approved registries — honeyslate and signedintake — have not been pushed to since 2026-07-19, and hooks/install.sh only installs into repos that have one. testgraph is the most actively pushed repo on this box and was the one repo the hook did not cover. This registry closes that: it makes the selection -> outcome pipeline produce joinable rows at all. It is a LIVENESS test, not an accuracy test. Do not quote testgraph's observed_recall as the tool's accuracy figure: the instrument and the target are the same repo, so a good number here is not independent evidence the way honeyslate and signedintake are. Selectivity, unlike recall, IS reportable — `harness/selectivity.py` builds a fresh per-commit index and never sees this registry's authorship — and it was measured on 2026-08-06 over the last 20 commits of main: mean 2.07/6 (34.4%) over the 15 commits that touch product code, 65.6% of journey-runs avoided; 1.55/6 (25.8%) over all 20. That sits beside signedintake's 2.21/8 and honeyslate's 3.4/8 rather than above them, so the earlier guess that a small stdlib codebase would be a trivially easier target was wrong and is not the caveat to carry. The caveat to carry is self-reference.\n\nKNOWN BLIND SPOT, AND IT IS A REAL ONE: `testgraph/db.py` and `testgraph/registry.py` are reachable from NO journey. Seeding every node in either file and running the full impacted closure intersects the entry map in zero nodes — a commit rewriting the whole of db.py, which is the graph traversal this tool IS, answers `journeys to test: NONE` with `status: OK` and `recall_degraded: false`. Measured, not suspected: closure of all 14 db.py nodes = 14 nodes (it never leaves the file) and all 24 registry.py nodes = 24, against ledger.py's 257 -> all six journeys. Cause is not the registry and cannot be fixed here: codegraph does not resolve calls through a module bound under an ALIAS. `from . import ledger` then `ledger.append(...)` links; `from . import db as dbmod` then `dbmod.connect(...)` does not, because the local name no longer matches the module name. Measured across all five same-package modules called as `module.attr()`: registry.py 38 call sites -> 0 cross-file inbound edges, db.py 18 -> 0, select.py 6 -> 1, against ledger.py 10 -> 44 and integrity.py 3 -> 15. Not strictly all-or-nothing (select.py keeps one edge) but the same collapse. Checked separately and worth recording: honeyslate is NOT exposed to this — its 9 aliased imports all alias a symbol (`Session as DbSession`), never a module, so the `alias.attr()` form never arises and the accuracy figures measured there stand. Adding these files' symbols as journey `entries` would manufacture the right answer out of a false claim about what an entry is, so it is deliberately not done. Until the indexer links aliased imports, treat a NONE that follows a db.py or registry.py change as UNKNOWN, and note that the selectivity figures in TECHNICAL.md's Update 5 do not cover this case: no commit in that 20-commit window touched either file alone.\n\nSECOND KNOWN BLIND SPOT, FOUND BY #12's TRACE-DERIVED GROUND TRUTH RUN AGAINST TESTGRAPH ITSELF (issue #66): this registry's own `spot_checks.append` (testgraph/ledger.py) passes today, but not for the reason it claims to check. `testgraph/record.py:add_outcome`'s `ledger.append(row)` and `testgraph/hook.py:log_invocation`'s twin call are BOTH silently dropped by codegraph's Python resolver — `isBuiltInOrExternal` treats any `x.method()` as `list.append`/`dict.update`/etc. whenever `method` is a common collection-method name, unless the capitalized receiver matches a known CLASS; it never checks whether the receiver is a known MODULE, so a real call through an imported module with a same-named top-level function is misclassified as a builtin and never reaches resolution. Separately, six unrelated `.append()` calls on local collections through a non-identifier receiver (`rows_by_file.setdefault(path, []).append(...)` in `export.py:build_map` and six more in `db.py`/`propose.py`/`select.py`) degrade at extraction time to a bare `append` ref, which then exact-matches `ledger.py:append` as the only same-named symbol project-wide — 7 fabricated edges, measured, none from a real caller. The spot-check counts edges, not their identity: `min_caller_edges: 5` passes on these 7 fabricated edges exactly as it would on real ones, so a commit that actually breaks `ledger.append` — the sole write path for J1 and J5 — would not be caught by this guard. Root cause is not the registry and cannot be fixed here; same class of gap as the alias blind spot above but a different part of the resolver. A fix is written and verified (colbymchenry/codegraph fork, branch `fix/python-module-member-builtin-collision`, commit `7ecf6dc`) but not deployed to the `codegraph` build this machine runs, so treat `append`'s spot-check as unreliable until a release picks the fix up.\n\nKnowingly uncovered, and each for a reason that has no fix in this file: (1) hooks/install.sh and hooks/pre-push are shell entry points with no symbols in the index — the same class as signedintake's scripts/pg-backup.sh; the pre-push template's behaviour is pinned by tests/test_hook.py instead. (2) skills/testgraph-verify/SKILL.md is the skill contract, markdown with no symbols; tests/test_skill_contract.py pins it. (3) harness/plugin/tgtrace.py is a pytest plugin loaded by name via `-p`, reached by pytest's plugin loader rather than by any call edge, so no entry symbol registers it; it is reached indirectly through J6's trace.run, which passes it. (4) harness/fixtures/dyndemo/ is a fixture repo, deliberately not product.",
+  "note": "Hand-authored 2026-08-06, NOT drafted by testgraph.propose — `propose --repo .` found 0 route handlers and said so, correctly: testgraph is a CLI, and CLI entry points are the first item on its own declared blind-spot list. One journey per CLI surface, entries being each module's `main` plus the one function that carries the surface's real work (so a change to that function is named even if `main` is untouched).\n\nWHY THIS REGISTRY EXISTS, AND WHAT IT IS NOT EVIDENCE FOR: the ledger held zero rows because the only two repos with approved registries — honeyslate and signedintake — have not been pushed to since 2026-07-19, and hooks/install.sh only installs into repos that have one. testgraph is the most actively pushed repo on this box and was the one repo the hook did not cover. This registry closes that: it makes the selection -> outcome pipeline produce joinable rows at all. It is a LIVENESS test, not an accuracy test. Do not quote testgraph's observed_recall as the tool's accuracy figure: the instrument and the target are the same repo, so a good number here is not independent evidence the way honeyslate and signedintake are. Selectivity, unlike recall, IS reportable — `harness/selectivity.py` builds a fresh per-commit index and never sees this registry's authorship — and it was measured on 2026-08-06 over the last 20 commits of main: mean 2.07/6 (34.4%) over the 15 commits that touch product code, 65.6% of journey-runs avoided; 1.55/6 (25.8%) over all 20. That sits beside signedintake's 2.21/8 and honeyslate's 3.4/8 rather than above them, so the earlier guess that a small stdlib codebase would be a trivially easier target was wrong and is not the caveat to carry. The caveat to carry is self-reference.\n\nKNOWN BLIND SPOT, AND IT IS A REAL ONE: `testgraph/db.py` and `testgraph/registry.py` are reachable from NO journey. Seeding every node in either file and running the full impacted closure intersects the entry map in zero nodes — a commit rewriting the whole of db.py, which is the graph traversal this tool IS, answers `journeys to test: NONE` with `status: OK` and `recall_degraded: false`. Measured, not suspected: closure of all 14 db.py nodes = 14 nodes (it never leaves the file) and all 24 registry.py nodes = 24, against ledger.py's 257 -> all six journeys. Cause is not the registry and cannot be fixed here: codegraph does not resolve calls through a module bound under an ALIAS. `from . import ledger` then `ledger.append(...)` links; `from . import db as dbmod` then `dbmod.connect(...)` does not, because the local name no longer matches the module name. Measured across all five same-package modules called as `module.attr()`: registry.py 38 call sites -> 0 cross-file inbound edges, db.py 18 -> 0, select.py 6 -> 1, against ledger.py 10 -> 44 and integrity.py 3 -> 15. Not strictly all-or-nothing (select.py keeps one edge) but the same collapse. Checked separately and worth recording: honeyslate is NOT exposed to this — its 9 aliased imports all alias a symbol (`Session as DbSession`), never a module, so the `alias.attr()` form never arises and the accuracy figures measured there stand. Adding these files' symbols as journey `entries` would manufacture the right answer out of a false claim about what an entry is, so it is deliberately not done. Until the indexer links aliased imports, treat a NONE that follows a db.py or registry.py change as UNKNOWN, and note that the selectivity figures in TECHNICAL.md's Update 5 do not cover this case: no commit in that 20-commit window touched either file alone.\n\nSECOND KNOWN BLIND SPOT, FOUND BY #12's TRACE-DERIVED GROUND TRUTH RUN AGAINST TESTGRAPH ITSELF (issue #66): this registry's own `spot_checks.append` (testgraph/ledger.py) passes today, but not for the reason it claims to check. `testgraph/record.py:add_outcome`'s `ledger.append(row)` and `testgraph/hook.py:log_invocation`'s twin call are BOTH silently dropped by codegraph's Python resolver — `isBuiltInOrExternal` treats any `x.method()` as `list.append`/`dict.update`/etc. whenever `method` is a common collection-method name, unless the capitalized receiver matches a known CLASS; it never checks whether the receiver is a known MODULE, so a real call through an imported module with a same-named top-level function is misclassified as a builtin and never reaches resolution. Separately, six unrelated `.append()` calls on local collections through a non-identifier receiver (`rows_by_file.setdefault(path, []).append(...)` in `export.py:build_map` and six more in `db.py`/`propose.py`/`select.py`) degrade at extraction time to a bare `append` ref, which then exact-matches `ledger.py:append` as the only same-named symbol project-wide — 7 fabricated edges, measured, none from a real caller. The spot-check counts edges, not their identity: `min_caller_edges: 5` passes on these 7 fabricated edges exactly as it would on real ones, so a commit that actually breaks `ledger.append` — the sole write path for J1 and J5 — would not be caught by this guard. Root cause is not the registry and cannot be fixed here; same class of gap as the alias blind spot above but a different part of the resolver. SCOPE CORRECTED 2026-09-03: this was first written as a Python-resolver defect, which understates it. The fabrication half is CROSS-LANGUAGE \u2014 reproduced on 1.5.0 and 1.6.0 in Python (`d.setdefault(k,[]).append(v)`), JavaScript (`m.getOrInit(k,[]).push(v)`) and Go (`r.lookup(k).Get(v)` binding to a package-level `Get` instead of the method on the returned type), each time with the same `exact-match` signature and each time with a plain-identifier control resolving correctly. So it is the shared extractor dropping any non-identifier receiver, not a Python heuristic, and it is not limited to collection-method names: Go's `Get` collides with an ordinary package-level function. Filed upstream as colbymchenry/codegraph#1683 (fabrication, patch posted) and #1681 (the module-member false negative, patch posted). A fix is written and verified (colbymchenry/codegraph fork, branch `fix/python-module-member-builtin-collision`, commit `7ecf6dc`) but not deployed to the `codegraph` build this machine runs, so treat `append`'s spot-check as unreliable until a release picks the fix up.\n\nKnowingly uncovered, and each for a reason that has no fix in this file: (1) hooks/install.sh and hooks/pre-push are shell entry points with no symbols in the index — the same class as signedintake's scripts/pg-backup.sh; the pre-push template's behaviour is pinned by tests/test_hook.py instead. (2) skills/testgraph-verify/SKILL.md is the skill contract, markdown with no symbols; tests/test_skill_contract.py pins it. (3) harness/plugin/tgtrace.py is a pytest plugin loaded by name via `-p`, reached by pytest's plugin loader rather than by any call edge, so no entry symbol registers it; it is reached indirectly through J6's trace.run, which passes it. (4) harness/fixtures/dyndemo/ is a fixture repo, deliberately not product.",
   "approved": true,
   "proposed_by": "hand-authored",
   "codegraph_schema_version": 8,