chore: finish the pytest-boundary rename, correct CLAUDE.md against measurement, and fix #89's fresh-clone build

[JC-000]

Two deferred follow-ups, each left behind by an earlier lane with its reason recorded. Plus one Makefile fix that fell out of Job 2 and is arguably the most useful thing here.

Rebased onto merged master (a6cf205, #113). One conflict — README's USE_X25519_SIBLING known-issue bullet — resolved in favour of #113's version, which is measured at the new pins and belongs to that lane.

Job 1 — finish the pytest-boundary rename

PR #111 renamed tests/test_*.py -> tests/rig_*.py and explicitly deferred the identical problem in tools/uci/: rig scripts wearing pytest's discovery convention while collecting zero tests. norecursedirs closed the default-invocation path; the rename is the honest fix, because testpaths only applies at the rootdir while a rename holds from any working directory.

Six files renamed with git mv (rename detection intact):

tools/uci/test_http_live.py -> rig_http_live.py
tools/uci/test_http_local.py -> rig_http_local.py
tools/uci/test_https_bad_finished.py -> rig_https_bad_finished.py
tools/uci/test_https_local.py -> rig_https_local.py
tools/uci/test_https_local_p384.py -> rig_https_local_p384.py
tools/uci/test_https_print_body.py -> rig_https_print_body.py

boot_check.py, phase2_check.py, phase3_tcp_echo.py and bench_ecdsa_u64e.py never carried the prefix and were not renamed.

Guard extended, and probed in both directions

tools/test_pytest_boundary.py gains a RIG_DIRS = ("tests", "tools/uci") tuple and a new fourth invariant. The rename and the config entry are both load-bearing, so both are now pinned — previously only one was.

$ python3 tools/test_pytest_boundary.py
ok test_every_testpath_exists
ok test_norecursedirs_covers_every_rig_dir
ok test_rig_dirs_hold_no_pytest_named_files
ok test_testpaths_lists_every_runnable_tools_module
ok test_testpaths_lists_nothing_pytest_cannot_run
PASSED: 0 failure(s)

Probe A — a test_*.py reappears in tools/uci/:

$ printf 'x = 1\n' > tools/uci/test_bogus_guard_probe.py; python3 tools/test_pytest_boundary.py
FAIL test_rig_dirs_hold_no_pytest_named_files
rig directories contain pytest-named files ['tools/uci/test_bogus_guard_probe.py'] ...
exit=1

Probe B — tools/uci drops out of norecursedirs:

$ perl -pi -e 's{^norecursedirs = .*$}{norecursedirs = .git libs ip65 ip65-build build dist tests}' pytest.ini
$ python3 tools/test_pytest_boundary.py
FAIL test_norecursedirs_covers_every_rig_dir
pytest.ini norecursedirs omits rig directories: ['tools/uci'] ...
exit=1

Both probes reverted afterwards.

Measured before/after

Invocation	Before	After
pytest (repo root)	30 passed, exit 0	31 passed, exit 0
pytest tests/	exit 5, explained	exit 5, explanation names both rig dirs
pytest tools/uci/	exit 5, unexplained	exit 5, explained
pytest tools	30 passed + 74 errors, exit 1	31 passed + 74 errors, exit 1

Reference sweep

grep -rn for the six stems over the tree (excluding .git, libs, ip65, build) returns onlydocs/library-ingestion-architecture.md:354 and :445, which the contract lane owns and has confirmed it is taking. Everything else updated here: CLAUDE.md, README.md, conftest.py, pytest.ini, tests/README.md, both docs/phase_f_part1_*.md, tools/https_e2e/{ensure_certs.py,certs/README}, tools/package/listener/{listener.py,README.md}, tools/uci/{_memory_policy.py,bench_ecdsa_u64e.py} and six in-script self-references.

Delegation checked live rather than assumed — both wrappers still resolve after the rename:

rig_https_local_p384 -> IMPORT OK -> .../tools/uci/rig_https_local.py
rig_https_print_body -> IMPORT OK -> .../tools/uci/rig_https_local.py

Sibling repos:#111 checked only for tests/. Checked here across the whole c64-test-harness tree and all five other sibling c64-* repos: zero hits. No open issue or PR in the org names any of the six.

New tools/uci/README.md mirrors tests/README.md.

The Makefile fix — issue #89's fresh-clone failure, fixed at the source

This started as a documentation correction and turned into a real defect, so it is worth reading even if you skip the rest.

src/net/ip65/ip65_blob.s pulls the prebuilt ip65 image in with a ca65 .incbin, which make's dependency graph cannot see. $(IP65_BIN) was a prerequisite of the PRG, but nothing ordered it before the object that consumes it — so from a clean build/ make assembled ip65_blob.o first and died. From a genuinely fresh clone, after make ip65-libs:

ca65 ... -o build/net/ip65/ip65_blob.o src/net/ip65/ip65_blob.s
src/net/ip65/ip65_blob.s(22): Error: Cannot open include file
'../../../ip65-build/ip65-c64.bin': No such file or directory
make: *** [build/net/ip65/ip65_blob.o] Error 1

One line states the missing edge:

build/net/ip65/ip65_blob.o: $(IP65_BIN)

Same fresh clone, same commands, with the fix:

$ git clone https://github.com/JC-000/c64-https /tmp/c64-fresh && cd /tmp/c64-fresh
$ git submodule update --init --recursive
$ make ip65-libs # exit 0
$ make # exit 0
$ shasum -a 256 ip65-build/ip65-c64.bin build/c64-https.prg
cf1a5ff7809af4e4655e385b378b936054f41046ff2b7604828af3240c2d90dd ip65-build/ip65-c64.bin
d522e68469b8fc09709f34e64fd5573a0a72465349374a26257194bd5ed96cca build/c64-https.prg

47,105 B, no intermediate step. The fix changes no output bytes — the ip65 PRG hashes d522e684… with and without it, and the hash reproduces across the fresh clone and this worktree.

How I got this wrong first, and the trap that did it

My first pass claimed plain make already rebuilt the blob correctly and that make ip65-blob was never needed. I had measured it — deleting the blob, make clean, make, and watching it rebuild byte-identically. The measurement was real and the conclusion was wrong.

ca65 does not resolve .incbin only relative to the including source file, whatever the comment in ip65_blob.s said. It also tries the path relative to the current directory, and ../../../ from a repo root escapes three levels above the checkout. A git worktree lives at <repo>/.claude/worktrees/<name>/ — exactly three levels down. So my worktree, with its own blob deleted, silently assembled the parent checkout's blob and reported success.

Reproduced deliberately in a scratch tree to be sure it was the mechanism and not a coincidence:

$ mkdir -p /tmp/esc/ip65-build /tmp/esc/x/y/z/src/net/ip65
$ printf 'PARENTBLOB' > /tmp/esc/ip65-build/ip65-c64.bin
$ # x/y/z has NO ip65-build of its own
$ cd /tmp/esc/x/y/z && ca65 -I src -I src/net/ip65 -I build -o /tmp/esc/out.o src/net/ip65/ip65_blob.s
ca65 EXIT=0

The coordinator caught the wrong conclusion before it merged. Both the CLAUDE.md and README wording and the source comment now state the real mechanism and warn not to measure blob behaviour in a nested worktree.

Job 2 — CLAUDE.md staleness sweep

README was audited claim-by-claim in #104; CLAUDE.md never was. Every item below was confirmed by running a command.

Claim	Was	Is	Check
fence macro size	14 bytes	17 bytes	counted the macro body in uci_regs.inc
fence sites	24 (11w + 13r)	26 (11w + 14r + 1 settle at net.s:199)	grep -n uci_fence src/net/uci/*.s
drain call sites	13	22	grep -c 'jsr uci_drain_resp|jsr uci_drain_status' src/net/uci/net.s (all 22 still bcs out)
CIA1 TOD read order	HOUR→MIN→SEC→TENTHS	HOUR→TENTHS	uci_cmd.s defines no $DC09/$DC0A equate at all
NET_CODE	$2000-$3B25	$2000-$3B65	cfg: start = $2000, size = $1B66
NET_BSS_TAIL	$3B26-$3FFF	$3B66-$41FF	cfg: start = $3B66, size = $069A
UCI_BSS_REGION	$4000-$41FF "zero-size"	$4000 (size 0)	cfg: size = $0000 — the span contradicted its own label
src/exports.s exports	ip65_init, ip65_process	backend-agnostic set only	those moved to src/net/ip65/exports.s
debug-artifact env var	UCI_DEBUG_KEEP_ON_PASS	KEEP_DEBUG_ON_PASS	os.environ.get("KEEP_DEBUG_ON_PASS", "0") — the documented spelling did nothing
P-384 rig budget	30 min (1800)	90 min (5400)	os.environ.setdefault at rig_https_local_p384.py:73-74
C64_SKIP_BUILD scripts	14	15	ran the recipe the file itself quotes
DEBUG_CAPTURE	reads as opt-in	on by default, =0 disables	os.environ.get("DEBUG_CAPTURE", "1")
EMBED_P256_OVERLAY exclusions	"mutually exclusive"	no $(error) guard: one silent auto-disable, one unguarded	the only $(error)s are Makefile:91/94/97/245
default_vice_config() uptake	"All in-tree VICE-driven tests"	8 suites; 15 files still build ViceConfig directly, incl. run_all_tests.py	grep -ln both ways
smoke-test list	"All 7 pass (97/97)"	list is 8; the total predates test_finished_verify.py	counted; run_all_tests.py dispatches 11 and includes neither it nor test_chained_hmac
bare pytest	30 passed	31 passed	ran it
src/boot.s:107-114		110-117	grep -n '^\s*\.import net_' src/boot.s

Plus the ip65-blob section above, and the stale touch ip65-build/ip65-c64.bin "committed blob is reused" advice — there is no committed blob, so on a fresh clone there is nothing to touch.

Wall-clock: labelled, plus the one point that has been re-measured

No benchmark was re-run by me and no hardware was touched. Every figure now states its pin:

• A pin-vs-commit table added, because a c64-https commit hash is not a pin. Resolved with git ls-tree <sha> libs/nistcurves + git tag --points-at: 2ceb5b1, f0127a0 and cb6eab4 are all v0.6.0; 3a43f61 is v0.9.1/v0.10.0; a6cf205 (chore(libs): nistcurves v0.9.1 -> v0.10.1, x25519 v0.10.0 -> v0.11.0 (lib-contract phase-3 wave) #113, current master) is v0.10.1 / v0.11.0.
• Rows previously labelled only @ 2ceb5b1 now say v0.6.0. The ip65/VICE table, the post-fix(tls): per-backend post-ServerHello drain budget — restores UCI handshake wall-clock #74 table and the packaging validation record all state their pin. "all three v0.6.0 profiles at HEAD" no longer claims HEAD.
• The 81.9 s Phase C.4 figure is marked as an unresolvable pin (cc182f1 is unreachable after the 2026-05 upstream history rebuild).

The v0.9.1 datapoint I originally declined to write in now exists in the file. I could not corroborate it from the repo because it lives in the release-prep session's logs, not the tree — which is why grepping was never going to find it. Supplied with per-row provenance and recorded as a clearly-bounded subsection, 48 MHz UCI REU profile, U64E, handshake + GET measured C64-side from run_prg, all PASS with server-side evidence:

libs/nistcurves	c64-side	vs v0.6.0
v0.6.0	80.8 s	—
v0.9.1	82.1 s	+1.6%
v0.10.1	82.4 s	+2.0%

Carried with the two caveats that matter more than the numbers, since three fresh rows in a file full of v0.6.0 tables invite exactly the wrong reading:

• n=1 per row. The +0.4% v0.9.1 → v0.10.1 step is indistinguishable from run-to-run variation and is explicitly not presented as a measured effect.
• One point of the sweep, not a refresh of it. Every other clock (1/8/16/20 MHz), every onchip and comb row, and every ip65 and C64U figure is still v0.6.0-era — stated in the section header, at the U64E sweep table, and at the packaging validation record.

The +1.6% at v0.9.1 matches the FIPS 186-5 public-key validation gate v0.7.0 added — an on-curve check on a point taken from an attacker-supplied certificate, so a regression worth paying. Provenance (bench/summary.txt, rel_e2e_uci48.log, e2e_wave.log) is named inline along with the fact that those logs are not in this repo, so nobody mistakes the rows for something reproducible from a clean checkout.

Independent corroboration of the "no timing change expected at v0.10.1" reasoning: rebasing onto #113 moved the pins, and both PRGs hash exactly as they did at v0.9.1 — ip65 d522e684…, UCI 66e37037….

Found and deliberately left alone

• The x25519 sibling failure. Measured: at 3a43f61 both backends exit 2 with ld65: Error: Duplicate external identifier: 'reu_mul_tables_init' — not the overflow CLAUDE.md records. PR chore(libs): nistcurves v0.9.1 -> v0.10.1, x25519 v0.10.0 -> v0.11.0 (lib-contract phase-3 wave) #113 rewrites the same CLAUDE.md and README spans and fixes the underlying collision, so I backed my prose out entirely to avoid a conflict and handed that lane the derivation. Their measurement supersedes mine: at the wave pins UCI links, and of the three recorded overflows two vanish and ip65's X25519_RODATA grows.

  One clause of my handoff was too strong and chore(libs): nistcurves v0.9.1 -> v0.10.1, x25519 v0.10.0 -> v0.11.0 (lib-contract phase-3 wave) #113 corrected it before pasting: I wrote that nistcurves v0.6.0 "does not export reu_mul_tables_init at all", generalising from a grep of one file. It does export it, at src/main.s:254. The load-bearing fact is one step further in — main.o is deliberately excluded from every lib-* archive target, and c64-https links archives only, so no archive carried the symbol at v0.6.0. Same conclusion (libs/x25519 v0.6.0 -> v0.10.0, and USE_X25519_SIBLING=1 links + verifies for the first time #102's evidence was honest on its own branch), sturdier mechanism. Recorded here because it is the same single-file-grep overreach this PR fixes elsewhere.

• docs/library-ingestion-architecture.md — two stale script references; owned and taken by the contract lane.

• src/net/uci/uci_regs.inc's own "~14 bytes" comment — same error as the CLAUDE.md one fixed here, but out of this lane's scope. (ip65_blob.s's comment was fixed, because this PR proves it wrong and changes the adjacent build rule.)

• unknown_policy=WARN in the MemoryPolicy migration — a code change, not a doc one.

Evidence

The Makefile change puts this over the build-evidence bar:

Re-run at the post-rebase pins (nistcurves v0.10.1 / x25519 v0.11.0), not carried over from the earlier run:

make clean && make -> exit 0, 47,105 B, d522e684…
make clean && make BACKEND=uci -> exit 0, 62,977 B, 66e37037…
python3 tools/test_ecdsa_kat_oracle.py -> 6/6 (3 valid accepted, 3 invalid CAVP rejected)
python3 tools/test_x509.py -> 11/11

Both PRG hashes are unchanged by this branch and unchanged across the wave bump; the Makefile edge is an ordering constraint and the ip65_blob.s change is comment-only. Boundary guard: 5 checks pass, bare pytest 31 passed exit 0.

🤖 Generated with Claude Code