records: register #639's exact sides (T-193) and #640's Lean proof of s(19) (T-194), with #639's replay (think-mdnn) - #651

Review A (senior engineering review with a correctness pass, round 1) · head ef43dd0 · base claude/ecstatic-edison-8en33t-intake-1016 (#642) at 71f6a41
Reviewer: strong tier, requested claude-opus-5-5 at xhigh · Channel: formal review
Coverage: all 40 changed files outside the evand packet. I read the record, code and test changes in full: results.yaml T-193/T-194, evidence.yaml, verifiers.yaml, source-coverage.yaml, bibliography.yaml, result-requests.yaml, n-019.md, the deferral, the ceremony allowlist, overview_sections.py, the ledger directory, both tests and release.py. I skimmed the generated views (RESULTS, INVENTORY, VERIFIERS, SYNOPSIS, site URLs, the n = 11 claim documents' link revisions, the T-007 audit). Of the packet's 37 files I read the README, acquisition record, receipt, review README and replay_verify_exact.py in full, and spot-checked verify_exact.py and data/verify.txt; the other retained upstream files were skipped, since acquire_source --check covers them. The issue-search part of the discovery sweep is refused in this session (403); the PR's reviews, review comments and issue comments were swept, and there are none.
Tests run (all at ef43dd0):

• acquire_source evand-exact-cur-2026-10-16 --check: PACKET_MATCHES_ITS_CONTRACT.
• intake_ledger render --check: up to date. intake_ledger check: OK.
• intake_ledger check --tree: 16 drifts, all T-193 itself (not a gate).
• check_results: pass, with V3/C3 derived for T-193. check_standing: OK.
• check_requests --report: #639 is 4 of 4 settled, reply due, closeable yes.
• pytest tests/test_evand_exact_cur.py tests/test_intake_ledger.py: 65 passed.
• Scratch check of T-193's bounds: each of the 16 bounds check_standing.stated_bounds reads from the claim is the 40-place truncation of exact-sides.json's 120-place cut, with slack 1e-40 (16 of 16).
• Scratch check of the polynomials: gcd(p, p′) = 1 for the 19 retained polynomials (19 of 19), and each file lists exactly n squares.
• GET repos/jlevy/squares/stacks?pull_request=651: [], and the same for 642.

Summary and Verdict

The records work is careful, and most of it checks out:

• Ledger verdicts. They follow "Several Reports at One Count": 16 counts recorded, ties at 51, 70, 153 and 207 kept by the earlier holder, and 172, 263 and 297 not recorded.
• T-174's unprinted rationals. These were handled correctly: PR #574 is walked again at the 15 counts where the start omits them, with exact sides from the merged claim record. The ledger notes and the owner list both say so.
• T-193's claim. It prints every bound in a form check_standing reads, closed forms included, and each bound is a correct truncation.
• The replay. It is complete over all 23 forms. The receipt is committed. The 76 controls were refused, and a test holds two of them. The checker and the driver are registered, with relationship_to_generator: same-implementation. "Confirmed" is qualified as reproduced with the producer's code everywhere I looked.
• T-194. Its kind is right: optimality, not formalization, since the record held no value of s(19) (epistemics.md, Result Kinds, first and fifth rules). It sits at V0/C0 with an honest composition. n-019.md links the proof without moving a lane.
• The S5 label. It meets the rubric's anchor ("establishing an important previously open case"). The rubric scores importance independently of verification, and the label follows the T-153 and T-154 precedent; read conservatively, I would keep it. Like T-154's, T-194's score should be put to the owner for confirmation; at present it is left only to the review lane.
• The announcement block. It is accurate and hedged ("reports", "(reported)"), and leaves T-193 (S2) out.

Two things should change before merge:

• A2: T-193's raise to V3/C3 is a stage 4 exit with only one of its two lanes run. Under the runbook, a review lane's read of this replay is still owed before that exit.
• A1: the chain to #642 is not a formal stack.

Verdict: changes requested (published as a comment; see A1 and A2).

Findings

A1 (High): an informal PR chain. This PR's base is #642's branch, and gh api "repos/jlevy/squares/stacks?pull_request=651" returns [] (as it does for 642), so the two PRs are chained only by branch base. tbd shortcut stacked-prs says chained bases alone do not count.

Fix: link #642 and #651 as a formal stack (gh stack link) and verify both through the stacks API, or fold this layer into #642 if it fails the review-unit test. Do not add more layers.

A2 (High): T-193 reaches V3/C3 before the stage 4 review lane has run. The register entry is packing/frontier/results.yaml T-193, the evidence is E-evand-639-verify-exact-replay, and the description lists "a review lane for #639's replay (V4/C4)" as a deferred candidate with no bead.

What the runbook requires. result-import.md, Stage 4:

• It "is one W2 phase with two lanes ... a replay of the certificate and a review of its mathematics".
• "Every proof an import registers gets a mathematical review ... it starts at intake: once the source is retained, in parallel with stage 3".
• "The exit follows both lanes. It adds the replay evidence, moves the verified lane if the review has no blocking defect open, rewrites the entry's claim, notes and next_rung together".

This PR performs that exit after the replay lane alone. It cites the replay evidence, which makes T-193 V3/C3, and it rewrites the claim, notes and next_rung. No review lane has been started and no bead owns one.

Precedent. Every comparable upper-bound import at V3/C3 has its stage 4 (W2) review lane on file:

• T-146 (review-2026-10-10-evand-regularized-certificates.md)
• T-158 (review-2026-10-12-upper-bound-imports-528-529.md)
• T-174 (review-2026-10-14-upper-bound-imports-574.md)
• T-181 and 15 others (review-2026-10-14-upper-bound-imports-561-593.md)

On main, fd717f2b2 is the commit in which "the 14 October reviews raise T-161 to T-175 and T-181 to T-183 to V3/C3". Those lanes also did what is still open here:

• the checker's trust boundary;
• each form measured pose by pose against the packing its regularizations item names (T-193 leaves identity.basis: source-claim everywhere);
• every print held to its exact side.

What the epistemics ladder alone allows. epistemics.md defines C3 as "Machine-replayed here or by a third party; review record not yet retained", so the rung is derivable without the review, and check_results accepts it. It is the runbook's sequencing that is not met.

Why it matters now. check_requests --report already reports #639 as "4 of 4 settled ... closeable: yes", so the drafted reply would tell the author the result is confirmed, and the issue could close, with no review ever run. The review owed is the stage 4 mathematical lane, one of the reviews C4 later counts; V4/C4 is a separate matter, and calling this lane "(V4/C4)" misframes it.

Fix:

1. Open the stage 4 review-lane bead for T-193 under think-phyb: strong tier, its own worktree, run as the 14 October lanes were. It should re-derive what verify_exact.py's VALID implies (identities mod f, interval-separated pairs, the disc test, containment, the side's root), measure each form against the packing its regularization names, and hold the prints to the exact sides.
2. Name that bead in T-193's next_rung, or in unfinished_confirmations if your schema allows it at this rung.
3. Then do one of two things:
   • hold the exit (keep the receipt, the verifiers and the evidence entry, but leave T-193 at V0/C0, not citing the replay evidence, until the lane returns, as T-161 to T-175 waited); or
   • record the owner's explicit word that this replay may raise T-193 ahead of its review, and say so in the entry's notes and in the #639 reply draft.
4. Correct the description's "the runbook was followed as written" and its "(V4/C4)".

A3 (Medium): T-193's claim misstates its margins. results.yaml T-193 claim reads: "below PR 574's rational certificates (T-174) by 7.8e-35 at 126 to 3.7e-88 or less elsewhere". The ledger gives #639 below PR #574 by at least 1.18e-64 at 267 and 1.66e-79 at 292, both well above 3.7e-88. The bounds themselves are right; the sentence is not.

Fix: state the range as the significance rationale does ("1.5e-99 to 7.8e-35"), or list 126, 267 and 292 separately. The description has a similar slip: it gives "by at least 7.8e-35 (126) to 1.6e-99 (232)", but the smallest margin is 1.48e-99, at 204.

A4 (Low): T-193's credit sentence disagrees with the record. results.yaml T-193 claim, last paragraph:

• "at every count but 266 by way of PingYou Ltd's or Polkovskyi's refinement" contradicts the entry's own regularizations, where n = 266 is of: T-174, PingYou's refinement of Daniel's T-119.
• It credits improvers "as the case records credit it" (Gupta at 88 and 199, Couzo at 267 and 302), but omits Polkovskyi at 258, where the ledger's start reads "Nate Chaoweeraprasit (itsnaka), improved by Mishapolk, Evan Daniel".

Fix: drop "but 266" and add Polkovskyi's improvement at 258, or name the improvers nowhere and leave the credit chain to regularizations.

A5 (Low): the irreducibility test accepts a perfect power. packing/resources/web/evand-exact-cur-2026-10-16/review/replay_verify_exact.py, factored().

• degrees = sorted(deg(factor) * power ...) and irreducible = degrees == [deg p], so p = q^k with q irreducible is reported irreducible.
• For the 19 retained polynomials I checked gcd(p, p′) = 1, so the conclusion holds there.
• At 204, 263, 267 and 297, two of them T-193 counts, the claim's "SymPy ... found every one irreducible" rests on this test alone. The side is unaffected; only the stated degree is.

Fix: require exactly one factor of multiplicity 1 (or use Poly.is_irreducible), re-run the four pinned-only forms, and refresh the receipt.

A6 (Low): the replay cache is keyed by count alone. Same file, cached(cache, f"n-{n}", ...), and the control keys likewise. A resumed invocation reuses an earlier record without checking that the input's or the checker's digest is unchanged. This receipt merges two invocations: 68.7 s of wall time against 1,306 CPU s.

Fix: key each cache entry on the input SHA-256, the checker SHA-256 and the control kind, or store them in the record and compare them on reuse.

A7 (Low): the ledger-start defect is untracked. The ledger README notes, and owner item 5, say that intake_ledger (via check_standing.improvements) reads a pending entry's bound from its claim text, so T-174's unprinted rationals are missing from every start. This ledger works around it by hand, and the description says "(no bead)". Every later ledger at T-174's counts will need the same workaround, or will record wrongly.

Fix: open a bead, either for the tool or for printing T-174's rationals in its claim. The #622 note already earmarks the next change to T-174.

A8 (Low): several description details are inaccurate.

• intake_ledger check --tree is reported as "0 counts where today's records give another start". At ef43dd0 it reports 16, which is T-193 itself, pending adoption: expected, and not a gate.
• think-nqnl is given as "about 285 to 420 CPU-h". The basis is 190 to 380 CPU-h plus at most 40; 285 is the midpoint stored as cpu_hours.
• The Announcement block is headed "16 October 2026", while the News entry is "dated by the merge". Regenerate the block if this merges on a later day.

Fix: correct these three lines.

Suggestions

A9: host the four pinned-only forms ourselves. The C3 at 204 and 267 rests on forms hosted only in evand/square-packing@7d1407a. Consider publishing the four forms (20.75 MB) as a project data release under development.md's "Publishing Hosted Data". The rung would then not depend on the source repository keeping the commit, and the controls could run at those counts too, with --controls-at all.

False Positives / Do Not Fix

• verify_exact.py does not compare len(squares) with n. Its range(n) loops fail closed on too few squares, and the driver holds each statement ("n = 88: s(88) <= S*") to verify.txt. exact_sides.py's explicit count check is a second guard, not a missing premise of the replay.
• V-evand-639-replay-driver has no versions digest. Only 6 of 112 first-party verifiers carry one, and the receipt records the driver's SHA-256 (c509a238…), which matches the file.
• The n = 11 claim documents' links move to 46ae34f9, a branch commit. Merges here use merge commits (development.md), so it stays reachable.
• The deferral names think-phyb, as PR 574's deferral names its import bead think-9v2k.

Dedicated Reviews

• Correctness: yes, because the PR adds register entries, raises a rung and makes exact comparisons. This review includes a correctness pass: the ledger walk, the claim prints against the exact sides, the rung derivation and the replay's controls.
• The dedicated mathematical reviews still owed are the stage 4 lane for T-193 (A2) and think-o40t for T-194.
• Security: no. Third-party Python runs only as a read-first python -I child on retained or digest-checked inputs.
• Performance: no.

CI Status

Every hosted job is green at ef43dd0, including packing-required and pages-required.

🤖 Generated with Claude Code

Generated by Claude Code

Dispositions for review A at 3a230d3

• A1 (High): deferred: tracked as think-e1u5 (child of think-phyb), waiting on gh stack tooling this session cannot install (its download is refused by the session proxy, checked at about 08:00Z). Meanwhile both descriptions declare the chain and the merge order (new "Chain and Merge Order" section): #642 first, then retarget #651 to main. No layers were added; the stage 4 review lane think-7qxm stacks on this branch as a separate PR. The coordinator decided this disposition.
• A2 (High): fixed in c86682367 (paragraphs split in 312dca416): the exit is held. T-193 is back at V0/C0 and cites only E-evand-639-exact-sides-report. The replay is kept in the packet: its receipt (refreshed, see A5 and A6), its driver, the README's account of it and both verifiers stay, and T-193's notes and artifacts point to them. The verified evidence entry E-evand-639-verify-exact-replay, and with it the case-citation deferral that named T-193 as citing it, are removed. check_certificate_citations refuses verified evidence that nothing cites unless a deferral names a result citing it, so the entry cannot stay uncited. This is how the 14 October imports were held: at #602 their replays were retained in the packets with no confirming evidence entry, and fd717f2b2 added those entries at the exit. T-186 to T-190 stand the same way on main today. The entry's text at ef43dd0 (in packing/frontier/evidence.yaml) is the draft the exit can restore with the refreshed receipt's numbers. T-193 now carries activity (in-analysis, think-7qxm, since 16 October), a next_rung naming the review lane and what it reads, and an unfinished_confirmations item (C3, link think-7qxm). Its notes say why the entry is held. The description's "(V4/C4)" framing and "followed as written" are corrected. Confirmed by check_results (passes, V0/C0 derived for T-193), check_certificate_citations (passes; 3 recorded deferrals) and by check_requests --report: #639 is now 3 of 4 settled and not closeable. The drafted #639 reply in think-phyb is superseded by a note: reported and replayed, review pending, not confirmed.
• A3 (Medium): fixed in c86682367 (paragraphs split in 312dca416): the claim now gives the range as 1.48e-99 (204) to 7.77e-35 (126). Against T-174 it lists 7.77e-35 at 126, 1.18e-64 at 267, 1.66e-79 at 292 and 5.92e-95 to 4.48e-88 at the other nine; against T-186 it gives 1.48e-99 (204) to 1.79e-39 (302), each a lower bound as the ledger states it. The description's "7.8e-35 (126) to 1.6e-99 (232)" now reads "1.48e-99 (204) to 7.77e-35 (126)". The printed bounds are unchanged, and check_results and check_standing pass.
• A4 (Low): fixed in c86682367 (paragraphs split in 312dca416): "but 266" is dropped. The sentence now says every count goes by way of PingYou Ltd's refinement (T-174) or Polkovskyi's (T-186), as the regularizations list, and 266 is a regularization of T-174's packing of Daniel's T-119. It also adds "258 (as Mykhailo Polkovskyi improved it)".
• A5 (Low): fixed in 2bcd0a7c8: factored() now records each factor's degree and multiplicity and squarefreeness (gcd(p, p′) = 1). It reports a polynomial irreducible only when it is squarefree and is one factor of multiplicity 1 at full degree, so a perfect power is refused. Confirmed by test_the_irreducibility_test_refuses_a_perfect_power, which fails on the old driver and passes now. The replay was re-run on all 23 forms, the four pinned-only ones (204, 263, 267, 297) fetched from 7d1407a and held to the manifest's digests: 23 of 23 VALID as data/verify.txt prints, 76 of 76 controls refused, and all 23 polynomials squarefree and irreducible, the four pinned-only ones included, so they are no longer unproven. The receipt is refreshed.
• A6 (Low): fixed in 2bcd0a7c8: each cached record is now keyed by the input's SHA-256, the checker's SHA-256 and the control kind, and reused only when all three match. Confirmed by test_the_resume_cache_reuses_only_the_same_run (fails before, passes after). The refreshed receipt again spans two invocations: the session's background limit stopped the first after four positives, and the second (631 s wall) resumed from the keyed cache, now reusing only records of the same input, checker and control (1,484.5 CPU s counted in all).
• A7 (Low): deferred: tracked as think-v860 (child of think-mdnn), waiting on a fix to intake_ledger/check_standing, or on printing T-174's rationals in its claim at the next change to T-174. The description's owner item 5 names it.
• A8 (Low): fixed in the description: check --tree now reads "16 drifts, all T-193 itself, pending adoption: expected, not a gate". think-nqnl now reads "about 190 to 380 CPU-h plus at most about 40, 285 stored as the central estimate". The Announcement block is marked as dated 16 October, to be regenerated with the same command if this merges on a later day.
• A9 (suggestion): declined for tonight: publishing the four pinned-only forms (20.75 MB) as a project data release is the owner's call under development.md's "Publishing Hosted Data". It is listed among the description's deferred candidates for the owner.

Validation at 3a230d3: packing-validate --records --jobs 2 exits 0 (52 of 110 steps, 193 s). check_results, check_standing, check_certificate_citations, check_prose_ceremony, site_urls --check and the view renders pass. check_requests exits 0, with #639 at 3 of 4 settled and closeable no. release_pin --check passes (pin 312dca41), as do check_release_impact --baseline-ref origin/main and acquire_source evand-exact-cur-2026-10-16 --check. Focused pytest over 8 files: 260 passed. Hosted CI at 3a230d3 is all green (30 succeeded, 29 skipped): Packing validation run 38895014466 (packing-required), Certificate page run 38895014273 (pages-required), Branch mergeability run 38895006417. This merges #642's head ae64ab461 (1f954b060). No hook was skipped.

Generated by Claude Code

Review B (follow-up review of review A, round 2) · head 3a230d3 · base claude/ecstatic-edison-8en33t-intake-1016 (#642) at ae64ab4
Reviewer: strong tier, requested claude-opus-5-5 at xhigh · Channel: formal review
Coverage: the fix commits since ef43dd0 (1f954b0, 2bcd0a7, c866823, e458835, 312dca4, 3a230d3), 17 files. I read the record, driver and test diffs in full and checked the refreshed receipt's rows and totals. I skimmed the regenerated views (INVENTORY.md, RESULTS.md, VERIFIERS.md, site-urls.yaml) and the re-pins. I re-checked the dispositions of A2 (High) and A3 to A6. A1 (High, deferred to think-e1u5) is unchanged: the PR is still chained by branch base, and the description now gives the merge order.
Tests run, from packing/ with the project interpreter: pytest tests/test_evand_exact_cur.py gave 6 passed at head. With the driver swapped back to ef43dd0 it gave 2 failed and 4 passed: the two new tests fail. check_results and check_certificate_citations exit 0, with 3 deferrals. check_requests --report exits 0 and shows #639 at 3 of 4 settled, "Closeable: no; exact-sides-below-record is open". I also ran an independent SymPy Poly.is_irreducible check and a gcd(p, p′) check on all 23 polynomials. The 4 pinned-only forms were fetched from evand/square-packing@7d1407a, and each matched its acquisition/upstream-subtree.sha256 digest. All 23 are irreducible, squarefree and primitive, at the degrees in the receipt.

Summary and Verdict

The fixes do what the dispositions say. A2 is resolved correctly. The runbook's stage 4 exit is the step that "adds the replay evidence" (result-import.md → Stage 4, "The exit"). So holding T-193 at V0/C0, with the replay retained and no verified entry, matches the runbook. It also matches the 14 October precedent: fd717f2b2 added the *-exact-feasibility entries for T-161 to T-175 and T-181 to T-183 at their exit. T-186 to T-190 stand on main at V0/C0, each citing only its report. The replay's provenance is retained: the receipt, the driver (receipt driver.sha256 f949158… equals the committed file), both verifiers (now "No evidence entry names it yet"), the packet and review READMEs, and T-193's artifacts and controls. Nothing in the tree still names E-evand-639-verify-exact-replay. A3 to A6 are fixed. I found two Low findings, both about what the exit and a later re-run will rely on. Neither blocks this round.

Findings

B1 (Low): the resume cache key leaves out the driver and the interpreter. In packing/resources/web/evand-exact-cur-2026-10-16/review/replay_verify_exact.py, run_key() (l. 151) keys a cached record by input SHA-256, checker SHA-256 and control kind. For those three, A6 is fixed. main() checks the checker's digest at startup (l. 225) and located() checks each input's, so no record can be reused against a different input or checker. But a control's record also carries what the driver computed: mutation and refused are set inside control() (l. 193–194) and stored with the record. The positive run's interpreter is sys.executable, which is not in the key either. So a resumed invocation after an edit to mutate() or control(), or under another Python, reuses the earlier records. The receipt's driver.sha256 (l. 310) and environment describe only the final invocation, so the mix would not show. The current receipt is not affected: its first invocation stopped after four positives, before any control ran, and positives depend only on the input, the checker and the interpreter. Suggested fix: add sha256(Path(__file__)) and platform.python_version() to the key (at least for controls), or store them in each cached record and in the receipt per record.

B2 (Low): the held exit's inputs are recorded only in the disposition reply. The disposition says the evidence entry's text at ef43dd0 is "the draft the exit can restore with the refreshed receipt's numbers". That pointer is not in T-193's next_rung, in think-7qxm or in think-g59l. The draft's numbers are now stale. Its limitations give 1254 CPU s, 492 and 308 s for 263 and 297, and 52 CPU s for the controls, and say only "factors each … as irreducible". The refreshed receipt gives 1,426.5 + 58.0 = 1,484.5 CPU s, 568 and 351 s, and 23 of 23 squarefree. Separately, think-7qxm's description still names "evidence E-evand-639-verify-exact-replay" as existing. Its log shows the lane started at ef43dd02f and pushed 6f6acc6ea at 11:20Z, before the driver fix and the refreshed receipt (2bcd0a7, 11:27Z). Suggested fix: record in think-7qxm that the lane must read the receipt and driver at 3a230d3 (driver f949158…). Also record where the draft entry is and which numbers and sentences the exit must refresh. Then the review and the restored entry will both describe the receipt that is on the branch.

Dispositions Re-checked

• A2 (High), fixed. T-193 is V0/C0 and cites only E-evand-639-exact-sides-report. It now has activity (in-analysis, think-7qxm, which is in progress), a next_rung naming the lane and what it reads, and an unfinished_confirmations item at C3 that links think-7qxm. The verified entry, its case-citation deferral, the request mapping and the site-urls.yaml reference are all removed. check_certificate_citations refuses verified evidence that nothing cites, and the runbook says the exit adds the evidence, so removing the entry is the right way to hold it rather than a workaround. The claim says "a reproduction with the producer's code", which meets the runbook's rule on the word "confirmed". The description's rung framing is corrected.
• A3 (Medium), fixed. I checked each margin against campaign/issue-intake/upper-bounds-20261016/README.md. Against T-174: 126 at 7.77e-35, 267 at 1.18e-64, 292 at 1.66e-79, and the other nine (88, 102, 123, 199, 258, 259, 266, 295, 301) from 5.92e-95 (88) to 4.48e-88 (199). Against T-186: 175, 204, 232 and 302, from 1.48e-99 (204) to 1.79e-39 (302). The overall range is 1.48e-99 to 7.77e-35. All correct.
• A4 (Low), fixed. T-193's regularizations give of: T-174 at 12 counts and of: T-186 at 175, 204, 232 and 302, so "at every count by way of … (T-174) or … (T-186)" holds. The ledger records 258 as "Nate Chaoweeraprasit (itsnaka), improved by Mishapolk, Evan Daniel", which supports "(as Mykhailo Polkovskyi improved it)".
• A5 (Low), fixed. irreducible requires squarefree and factors == [[degree, 1]]. The test covers x²−2, (x²−2)² and (x²−3)(x²−2). The old driver returned irreducible: True for (x²−2)². On the old code the new test fails first on the missing squarefree key, but its perfect-power assertion would also fail there. The receipt's rows all read [[d, 1]], squarefree and irreducible, and the four pinned-only forms were factored in the final invocation from digest-checked files (factored() is not cached). My independent check above agrees.
• A6 (Low), fixed for the input and the checker. See B1 for the remaining gap. Records in the earlier unkeyed format have no key field, so they are re-run, not reused. The receipt's totals match its rows: positives 1,426.5 CPU s, controls 58.0, total 1,484.5. The README and the description give the same figures.

Dedicated Reviews

None recommended. Security: no. The driver runs a digest-pinned checker on digest-checked inputs in python -I children. Performance: no. Correctness: no further review beyond the stage 4 review lane think-7qxm, which is already the correctness review of the replay's mathematics and is what holds the exit.

CI Status

Hosted check runs at 3a230d3: 30 succeeded, 29 skipped, none failed.

Generated by Claude Code

Dispositions for review B at b33ce8f

• B1: fixed in b33ce8ffd. run_key() now also keys each cached record by the driver's SHA-256 (driver_digest()) and the interpreter (interpreter(), implementation and version), so a record is reused only when all five fields match. Confirmed by test_the_resume_cache_misses_on_another_driver_or_interpreter (tests/test_evand_exact_cur.py: 7 passed). It fails on the previous driver, which has neither function. The review README states the new key and why the receipt stands. That receipt records driver f949158c, and no control was cached across its two invocations, so it is not re-run.
• B2: handled by the coordinator, on think-7qxm: the receipt and driver the lane must read, where the draft evidence entry is, and which numbers and sentences the exit must refresh.

Validation: focused pytest tests/test_evand_exact_cur.py gives 7 passed. ruff, ruff format and basedpyright are clean on the test. release_pin --check passes with the pin unchanged at 312dca41 (no data path changed). acquire_source evand-exact-cur-2026-10-16 --check prints PACKET_MATCHES_ITS_CONTRACT. Hosted CI at b33ce8f is running.

Generated by Claude Code