feat: testgraph registers itself, so the ledger has something to record

[inth3shadows]

Closes the reason the results ledger from #57 has held zero rows since it merged.

Why there were no rows

Not a bug — an absence of opportunity. hooks/install.sh installs only into repos with an approved registry, and the only two were honeyslate (last pushed 2026-07-17) and signedintake (2026-07-19). Both dormant. Meanwhile testgraph is the most actively pushed repo on this machine and was the one repo the hook did not cover.

What's here

• journeys/testgraph.json — hand-authored, approved: true, 6 journeys (J1 hook, J2 select, J3 propose, J4 export, J5 record, J6 harness), 19 entry nodes, all resolving, no approval or drift warning.

  propose --repo . correctly wrote nothing: found 0 route handler(s), and it named the reason from its own blind-spot list — CLI entry points and management commands. A proposer that had invented six journeys from nothing would have been the silent-confidence failure this codebase keeps designing against.

• tests/test_registries.py — 5 tests over every shipped registry. Closes a gap nothing covered.

• TECHNICAL.md Update 5 — the measurement and its caveats.

Selectivity

harness/selectivity.py, fresh per-commit index, last 20 commits of main. Update 3's methodology correction applied from the start rather than retrofitted:

	all 20 commits	15 touching product code
mean selected	1.55 / 6 (25.8%)	2.07 / 6 (34.4%)
journey-runs avoided	74.2%	65.6%
<= 2 journeys	17 of 20	12 of 15
recall_degraded	1 of 20	1 of 15

Histogram over all 20: {0: 5, 1: 8, 2: 4, 3: 1, 6: 2}.

All five zero-selections are exactly the five non-product commits, and every one of the fifteen that touches product code selected at least one journey.

A wrong call, corrected mid-task

I first generalised from two hand-picked ranges that each named 6/6 journeys and concluded selectivity had collapsed on a small tightly-coupled codebase. The sweep says otherwise — 34.4% sits beside signedintake's 27.7%, not below it. The two ranges were unrepresentative: one a cross-cutting ledger commit, one containing a file with no indexed symbols. The registry note briefly carried the wrong claim and was rewritten. The harness exists precisely because that intuition is unreliable.

The populated middle is not a counter-example

testgraph's histogram occupies 1, 2 and 3 where mealie's was {0: 38, 23: 2}. That is not evidence against Update 3's bimodality finding: with six journeys the "middle" is only 1–5 wide, so a registry this small cannot exhibit the shape either way. Noted in TECHNICAL.md so it isn't later mistaken for one.

What this is not evidence for

The instrument and the target are the same repo. Selectivity survives that better than recall — harness/selectivity.py checks each commit into its own worktree, builds its own index, and never sees who wrote the registry — but observed_recall from the ledger will be testgraph scoring testgraph against a registry authored while reading testgraph's source.

Treat the ledger's testgraph rows as a liveness test of the selection → outcome join, not as an accuracy claim. The accuracy claims in TECHNICAL.md still come from honeyslate's hand labels and the outside repos in Update 3, and nothing here changes them.

The registry test closes a real gap

Nothing validated any shipped registry. That is exactly the ae128bb finding-8 defect: a trailing comma makes json.load raise, reg.resolve_for_repo swallows the ValueError and returns None, the hook logs NO_REGISTRY and exits 0, and record tells you to draft a file you already have. A typo silently disables the tool for that repo until somebody notices it stopped talking.

Index-free by design — honeyslate's and signedintake's codegraph databases are not present in every checkout, so asserting their entries resolve would fail for reasons unrelated to the registry.

Both guards mutation-tested rather than assumed green (the repo's own standard, after five of seven skill-contract guards once passed against the defect they named):

mutation	result
unparseable registry added to journeys/	FAILED (failures=1, errors=1)
second file claiming target testgraph	FAILED (failures=2)
restored	OK

Operational finding: codegraph cannot find a bare-worktree repo root

This blocked the work entirely and is worth knowing beyond this repo.

In the claudew layout a worktree's .git is a file (gitdir: .../.bare/worktrees/main), not a directory. codegraph 1.5.0's root detection wants a directory, so from any worktree it walks up past the repo. codegraph index <path> then rebuilds whichever ancestor index it finds rather than creating a local one — or refuses at $HOME when there is none.

A 279 MB ~/personal_projects/.codegraph (11,141 files, 55 repos, truncated mid-run with 880,880 unresolved references) had been sitting there answering every query from any un-indexed repo under that root. It had to be removed before testgraph could be indexed at all.

Use codegraph init <path> for a first index, never codegraph index <path> — init creates in the directory named, index resolves an ancestor.

Not in this PR

Success criteria 3 and 4 are gated on merge: hooks/install.sh bakes TESTGRAPH_HOME=.../testgraph/main, so the registry has to be on main before the hook can see it — the installer's own note says to install after merging. Once merged: install the hook, push, and confirm a status: OK selection row lands in the ledger.

Verification

243 tests green, was 238.