records(#763): T-240 reviewed at V3/C3, adopted at 268 and 303 and regularized - #794

Review A (senior engineering review, round 1) · head 7b6410d · base main at 2ec489d
Reviewer: strong tier, requested claude-opus-5-5 at xhigh · Channel: PR comment
Coverage: all 88 changed files. Read in full: the code changes (adopt_houses.py, upper_bound_houses.py, upper_bound_reports.py, default_drawings.py, cli/validate.py, release.py, the workflow line and the three test files), the register, evidence, verifier, coverage and requests changes, both case records, the packet README, the run README, the atlas README and the stage 4 review document. Checked by tool or spot-read: the generated views (RESULTS, INVENTORY, VERIFIERS, STATUS, CERTIFICATE-REACH, SYNOPSIS, site-urls), the censuses, the custody receipt, the screen and the review's JSON outputs. Not inspected visually: the four SVG renderings, because no rasterizer or browser is available here.
Tests run (from packing/, under nice, Python 3.14.7 via uv run --frozen --all-extras --group dev): packing-validate --records --jobs 2 --inner-jobs 1, 53 of 53 tier steps passed (408 s wall at load 13 to 23); select_houses --check, adopt_houses --check (70 at their houses), default_drawings --check-state --base-ref origin/main (0 pending), regularized_drawings --check and check_results (240 results) all pass; default_drawings --compare against main's record; pytest tests/test_house_adoption.py tests/test_check_requests.py -n 2, 185 passed; stamp_landed dry runs and release_pin --check (the pin is ff9e896e1, the last data commit); and two scratch scripts of the reviewer's own (results below).

Summary and Verdict

The science checks out. T-240's two certificates are smaller than the houses they replace, by exact arithmetic. The witnesses are the retained certificates, square for square. The regularized views are valid packings at exactly T-240's side. check_results derives V3/C3. Every house and drawing gate passes, and CI is green at the head. The rule that dates this pass 25 October exists in code and is applied correctly.

There are no Blocker or High findings. Two Medium findings remain. A1: the record, the atlas README and the drafted reply call the regularizer's 303 solve a KKT local minimum, but the driver's own receipt marks that certificate invalid. A2: nothing stops a merge before 00:00Z on 25 October.

Verdict: approve once A1 is fixed, and merge only on 25 October 2026 UTC or later, by the merge-day steps below. A3 to A7 are Low.

Findings

A1 (Medium): the record calls the regularizer's 303 solve a KKT local minimum, which its own receipt does not certify.

• packing/frontier/results.yaml:33774-33777 (T-240's notes) says "Evan Daniel's regularizer solves each witness to a KKT local minimum below its side".
• packing/atlas/known-best/README.md:820-825 says "solves both witnesses to KKT local minima below their sides".
• The drafted 268–9802: registration request #763 reply in think-ptkk's notes says "this project's run of Evan Daniel's regularizer also finds KKT local minima below both sides, which wait to be registered".
• The driver's report at cases/regularized_drawings/think-bk9r-2026-10-24/adopt-2026-10-25-n268-303-evand/n-303/report.json.gz gives status: "certificate invalid", cert_valid: false, gate: "relaxed" on the first-pass rung, and vv_milp_dS: 9.82e-10. Only 268's solve is KKT local min with gate: certified. The run README (row 303 of its table) states this correctly, and the summaries drop the qualification.
• The reply has a second error: "wait to be registered" is wrong at 268. That view is exactly the side of Daniel's earlier-reported certificate (T-242), so it proves no new bound, and think-20oj covers 303 only.

Fix:

• In T-240's notes and the atlas README, write: "at 268 a certified KKT local minimum at exactly the side of Daniel's later certificate; at 303, on its first-pass rung, a solve whose KKT certificate fails at the relaxed gate, giving a view 3.63e-12 below that all three exact routes here accept".
• In the reply, say that the 303 view waits to be registered (think-20oj) and that the 268 view reaches Daniel's side.
• Run render_results --update if the notes render.

A2 (Medium): nothing enforces the 25 October merge date that the pass's dating depends on.

• packing/frontier/landings.yaml dates 268 and 303 to '2026-10-25'.
• Both case records carry source_reviewed: '2026-10-25' and "House adoption, 25 October 2026".
• upper_bound_houses.LATER_PASSES says the pass "is dated by the day its pull request merges".
• No gate compares any of these with the clock. CI is green, GitHub reports the PR CLEAN, and github-merge is autonomous, so the PR could be merged today, 24 October, and would then publish a future date. stamp_landed --audit would only catch it at the next sweep.
• I confirmed the hazard. The dry run stamp_landed (today, 2026-10-24) prints n=268 T-240 -> 2026-10-24 and n=303 T-240 -> 2026-10-24. With --date 2026-10-25 it prints no change.

Fix: keep the PR in draft until 2026-10-25T00:00Z, and merge by the merge-day steps below.

A3 (Low): the durable record does not say why the review's proposal at 268 was not followed.

• The review proposes "adoption at 303 now; at 268 after think-l49q decides Daniel's certificate" (docs/project/reviews/review-2026-10-24-couzo-n268-n303.md, Rungs and Proposed Record Changes). The PR adopts 268 now.
• That is right under the house rule. select_houses --check fails wherever a validated smaller packing is not the house, and none of select_houses.STAGING_REASONS covers waiting for an unvalidated later report.
• Only the PR body explains the departure, and it cites "No adoption waits for the owner's word", which is about the owner's word, not about another candidate.

Fix: add one sentence to the packet README's Stage 4 Review section (packing/resources/web/couzo-issue763-2026-10-23/README.md, after the paragraph on T-240's houses), and optionally to T-240's notes. It should say that the house rule adopts the smallest validated packing in the pass that validates it, that no staging reason covers waiting for Daniel's unvalidated 268, and that 268 therefore moves now and re-houses once T-242 is validated (think-hx0e).

A4 (Low): the 268 register candidate has no bead.

• The guide's Register Candidates says a view below U "is registered as a result (row 3), however it was made". Where an earlier certificate states the same side, the result names it as first_certified_in, as T-155 did for 33 counts with T-101.
• The run README (cases/regularized_drawings/think-bk9r-2026-10-24/README.md:67-75) says "Registering either needs a register id". think-20oj covers only the 303 view.

Fix: widen think-20oj to include the 268 view, with first_certified_in: T-242 once T-242 is on main, or record in the run README why the 268 view will not be registered. Name think-20oj in that README and in T-240's notes where they say a register id is needed.

A5 (Low): the S3 News draft overstates at 268 and in its review wording.

• The title "Couzo's Packings Become the Best Known at 268 and 303" conflicts with the body's own "Daniel's later 268, 4.48e-12 lower". A smaller 268 is known and will be in the record as T-242.
• "pass an independent clean-room review" goes beyond the record's words: "clean-room, by a Claude agent, a system family the producer also used". The independence the record claims is of the code ("independently re-implemented"), not of the reviewer.
• No direct public link is given, although the runbook's Label the PR and Prepare News asks for one where available.

Fix: retitle it "Couzo's Packings Become the House Best Packings at 268 and 303" (or "Best Verified"). Write "pass a clean-room review here" and keep "confirmed, independently re-implemented, by a Claude agent" in Details. Link https://squaremath.org/results.html#t-240 and the two case pages.

A6 (Low): the before-merge visual check of stage 5 is not recorded.

• Verify the Published Result asks, before merge, to "inspect representative desktop and mobile views for cropped drawings, missing source credit or unreadable labels".
• Neither the PR body nor think-bk9r records that inspection of the 268 and 303 case pages, the regularized renderings or the results row. The hosted Certificate page jobs (screen, geometry, print-layout) pass, and I could not render the pages here.

Fix: record that inspection, or that the hosted jobs stand in for it, in think-bk9r before the merge.

A7 (Low): a merge of #792 will conflict at T-240's tail.

• records: Couzo's 304 at fa6237e and Daniel's Kaggle descents at 268 and 304, as T-241 and T-242, reported #792 (head c30dd33b) inserts T-241 and T-242 directly after T-240 in results.yaml and edits 268–9802: registration request #763's requests entry. This PR rewrites T-240's next_rung and adds its reviews, at the same boundary.
• records: Couzo's 304 at fa6237e and Daniel's Kaggle descents at 268 and 304, as T-241 and T-242, reported #792's own T-242 text calls T-174 "the case's house best packing" at 268, which is stale once this PR lands.
• The PR body names the rename to T-242 but not these conflicts.

Fix: whichever PR merges second resolves results.yaml and result-requests.yaml by hand, keeping both blocks. If #792 is first, rename Daniel's 268 to T-242 in T-240's notes and next_rung, in the packet README and in the reply. If this PR is first, #792 updates T-242's "house best packing" wording to T-240.

Suggestions

A8 (optional): the house writer's sentence "The review of 24 October 2026 accepted the replay for finite feasibility" (frontier/n-268.md:414 and frontier/n-303.md:673, from adopt_houses.py:2553 and :2602) is slightly loose for this review. The review decided the certificates on its own checker and held that checker to the replay's receipt, 24 of 24 numbers equal; it did not run the replay. A writer variant such as "accepted the certificates, holding its checker to the replay's receipt" would be exact. The template is shared by every house, so declined is reasonable here.

Merge-Day Steps

The rule exists and is applied correctly:

• adopt_houses.retain_history keeps each count's first-read text per day's archive.
• house-adoption-prior-state-2026-10-24.json.xz already holds 204 and 303 (unchanged here).
• A pass dated 24 October would therefore have kept 303's pre-T-239 text, and before_last_pass would have replayed the wrong record.
• The new house-adoption-prior-state-2026-10-25.json.xz holds exactly 268 and 303, each byte-identical to main's n-268.md and n-303.md.

The merge step must:

1. Not mark the PR ready, and not merge, before 2026-10-25T00:00Z (date -u +%F ≥ 2026-10-25).
2. If main has moved (for example records: Couzo's 304 at fa6237e and Daniel's Kaggle descents at 268 and 304, as T-241 and T-242, reported #792): merge origin/main with a merge commit and resolve A7. Then, from packing/, run stamp_landed --apply with no --date (today in UTC) and release_pin --update as the last two commits. Re-run check_release_impact --baseline-ref origin/main, and add a fourth papers no-change record if it asks for one. Run the records tier, push, and wait for packing-required and pages-required to pass on the new head.
3. If main has not moved: run stamp_landed (dry) on the day. It must print only "nothing to stamp", with no n=268 or n=303 line. release_pin --check must pass. Then merge with a merge commit.
4. If the merge slips to 26 October or later: the stamp re-dates both houses in landings.yaml to the merge day, with a re-pin. Keep the pass dated 25 October: it only has to differ from 24 October. Pass day and landing day already differ at 207 (pass 23, landed 24) and at 268's T-174 (pass 17, landed 19). Amend the LATER_PASSES comment ("dated by the day its pull request merges") to name the actual merge day. Re-dating the pass instead would mean renaming the archive and the LATER_PASSES key and running adopt_houses --refresh --n 268 303 with the views rebuilt; I do not recommend it.
5. Later adoptions: any later adoption at 268 or 303, such as think-hx0e re-housing 268 to T-242, needs a pass day after 25 October, since that day's archive holds both counts.
6. After the merge: stage 5's deploy check, the 268–9802: registration request #763 reply (with A1 fixed) and the News entry (with A5 fixed).

What I Verified

• Exact sides (devtools.exact_sides.compare against main's case-record ceilings): T-240 is below the house at both counts, by 4.453105e-3 at 268 against T-174 and 2.784094e-3 at 303 against T-239. Against the later counts, the least gaps are 2.7152e-2 at 269 and 2.2450e-2 at 304, both from the reported lanes.
• Witnesses and views, with a standalone Fraction checker of my own: it checks unit bases, containment by support, and a separating axis over the four edge normals for every pair closer than √2.
  • witnesses/known-best/n-268.yaml and n-303.yaml equal source/certificates/best/n268.cert and n303.cert square for square, with each basis compared modulo quarter turns.
  • Both witnesses are valid: 668 and 701 close pairs, least gaps 2.0963e-13 and 2.0718e-13, and wall clearance 1e-15.
  • Both regularized views are valid at exactly T-240's side, which is at or below the house: 386 and 226 exact contacts, with touching allowed, and no overlap or escape.
• Rungs: derive_verification and derive_confirmation give V3/C3. They give V3/C3 even with only the replay entry and no reviews, as epistemics.md's C3 (machine-replayed here) allows. The review is what verified_lane_review_problems requires, and what earns "independently re-implemented".
• Drawings: default_drawings --compare against main gives these changes:
  • 268: from decided-no-better, the house drawing (0 uneven, 838 sides), to regularized, the grid-slack view (19 uneven, 0 near-axis, 751 sides).
  • 303: from the grid-slack view of T-239 (37 uneven, 760 sides) to the grid-slack view of T-240 (0 uneven, 848 sides).
  • It reports "0 still pending … and 0 in another state". No strong view gave way.
• Register candidates: the 268 view's side is 8437180857934672912242411148233/(5·10²⁹) = 16.874361715869345824484822296466, exactly T-242's claim at records: Couzo's 304 at fa6237e and Daniel's Kaggle descents at 268 and 304, as T-241 and T-242, reported #792's head, so it adds no bound. The 303 view is 3.633178e-12 below T-240. That value appears only in the run README; it is not registered here, and think-20oj is open for it.
• Credits: the credits match the manifest's lines. At 268 the credit reads "Francisco Couzo (square-packing live search); refines the packing of Kirill Tymchishin". At 303 it reads "refines the packing of Vladislav Lavrentev … v11", with source provenance "own refinement", "browser search". They also match the review's identity table: 0 squares beyond 0.1 of the v4 parent at 268, and 3 beyond 0.1 of the push parent at 303.
• Screen totals: SCREEN_FINDINGS n=1..324 moves from (124, 1184, 302, 5110) to (124, 1247, 302, 5243). That equals +18/+78 at 268 and +45/+55 at 303, as validate.py's comment states.
• Reply draft: apart from A1, the reply's figures, rungs, prints (16.874361715874 and 17.906978233799 round up correctly), confirmation wording, question list and RF-7 to RF-12 coverage agree with the review and the record.

False Positives / Do Not Fix

• Adopting at 268 without waiting for think-l49q is required by the house rule (see A3); it is not a defect.
• 268 drawn less regular than on main: the witness is new; main drew T-174's house, not a strong view; the grid view beats the axis tool's view of the new witness on every goal; and the house rule says a less regular drawing is no reason to wait.
• shares: [] on V-couzo-763-review-check: shares lists the producer's components only (epistemics.md). The shared Fraction and separating-axis method are stated in the limitations, as in the model V-amundsk-755-review-check.
• "Couzo's browser search" at 303: the manifest credits the 303 live record to Couzo as "own refinement" from a "browser search".
• "4.4e-12" in the reply's question 1: this is Lavrentev's float side, as in the review's table, not Daniel's certificate (4.48e-12).
• No digest field on the new verifier: it follows the model entry; the four programs match out/program-digests.sha256, which I re-hashed.

CI Status

At 7b6410d83: 31 checks pass, 28 are skipped and none fail. packing-required and pages-required pass, and Branch mergeability passes. The PR is a draft, labelled intake and S3 (exactly one S label). Its base is main; it is not stacked. main is still 2ec489d1e. The PR changes no policy block in AGENTS.md.

Dedicated reviews: none recommended. The code changes are data tables and prose (ADOPTED, LATER_PASSES, CREDITS, RESULTS, a reader registration, SCREEN_FINDINGS), with no new logic. The correctness that matters, the exact feasibility, is covered by the stage 4 review and by the exact recheck above.

Could Not Check

• The four SVG renderings and the published pages, visually.
• That the committed review is byte for byte the reviewer's draft: /home/user/wt-rev240 no longer exists. The program digests do match.

Generated by Claude Code

Dispositions for Review A (round 1) · head d000419bd: the fixes in 9ebc1357b, then the merge of main 3480b5fd3 (#792), which landed during the round, in 180587e48

Validation at d000419bd:

• Local checks:
  • packing-validate --records --jobs 2 --inner-jobs 1: 53 of 53 passed, both before the merge and after it.
  • check_results (242 results), select_houses --check, adopt_houses --check, upper_bound_houses check, default_drawings --check-state --base-ref origin/main, regularized_drawings --check, build_bound_citations --check, contributor_census, check_prose_ceremony, site_urls --check --history-ref origin/main, check_synopsis, check_documentation and check_release_impact all pass.
  • 20 affected test modules after the merge (records: Couzo's 304 at fa6237e and Daniel's Kaggle descents at 268 and 304, as T-241 and T-242, reported #792's test_upper_bound_reports_l49q.py among them): 1,081 passed; the atlas credit and print tests: 10 passed.
• The papers' no-change record was measured against the new main at link revision 180587e4, with its nine candidate inputs swapped in: 69 files, byte-identical across all three renders. The explainer keeps main's v0.4.27, since both sides count 242 results. DATA_REVISION is re-pinned to 180587e48.
• stamp_landed --date 2026-10-25 (dry run): nothing to stamp. The landings stay dated 25 October.
• Hosted: at d000419bd Packing validation run 40118613910 passes on every job that ran and packing-required passes; Certificate page run 40118613915 passes (pages-required). At 89451b01c (review A's fixes, before the merge), Packing validation 40115251173 passed; Certificate page 40115251126 failed once on browser-geometry (firefox), where setup-uv could not fetch its manifest ("fetch failed"), and passed on the re-run of the failed jobs.

Merge-day sync

Main 2ed0ea7 (#793, #796, #795) is merged in as 5adbe80. The head is now 16f136c.

• Conflicts. Seven files conflicted, and both sides were kept in each.
  • bibliography.yaml, the packet README, release.py's no-change records and resources/README.md were resolved by hand.
  • occurrences.yaml was reconciled with contributor_census; nothing was dropped.
  • INVENTORY.md and VERIFIERS.md were rebuilt by their renderers.
• Two failures from the merge, both fixed.
  • fc05198: records(think-lyf9): the push of 23:38:42Z at the 99 Kaggle-notebook counts, commit by commit, 185 rows #795 widened the issue-763 packet, so the house custody receipt was regenerated with upper_bound_houses custody. It covers 70 houses and 200 inputs, and all 44 mutations were refused.
  • 7149db7: the identity test for T-230 against T-239 read the 303 house witness, which is T-240 from today. It now reads T-239 from its own packet. Every figure from the review reproduces unchanged.
• RF-2 wording narrowed (be46a31). previous_source names the record the source held before. It is the retained parent only at 268 and 303. The stage 4 review of T-241 and T-242 found that it is not the seed in general.
• Release. The papers' no-change record was re-measured at be46a31, giving 69 files, byte-identical across three renders. The pin was moved to be46a31. stamp_landed --apply on 25 October writes nothing, because the 268 and 303 landings are already dated 2026-10-25.
• Checks. The records tier passed 53 of 53, and the 26 affected modules ran 1,469 tests with all passing. Hosted CI is green: Packing validation 40146808562 and Certificate page 40146808543.

Generated by Claude Code

PR Summary by Qodo

Confirm T-240 and adopt Couzo’s packings at 268 and 303

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 40+ Minutes

Code Review by Qodo

View medium (2)

3. Reruns lose the former house packings 🐞

Description

identity.py loads the supposed T-174 and T-239 comparators from the mutable known-best witnesses,
and sides.py uses those same paths for its former-house side comparisons. This PR replaces those
witnesses with the newly adopted packings, so rerunning either program now compares against T-240
rather than reproducing the retained T-174 and T-239 results.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The review programs read former house packings from known-best witness paths that this PR replaces, so their historical identity and side comparisons cannot be rerun from the merged tree.
## Fix Focus Areas
- packing/resources/web/couzo-issue763-2026-10-23/review/review-2026-10-24/identity.py[308-355]
- packing/resources/web/couzo-issue763-2026-10-23/review/review-2026-10-24/sides.py[126-139]
## Recommended Fix
Retain or reference immutable copies of the former T-174 and T-239 witnesses and read those in both programs. Verify reruns reproduce the recorded former-house comparisons.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

4. Replay agreement passes with no checks 🐞

Description

agree.py iterates the stored checker's results without requiring the expected two certificates
or checking their verdicts, then treats equality across an empty check list as success. If that
receipt is truncated to an empty results list or omits one count, the comparison exits successfully
while performing none or only half of its claimed cross-route checks.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The agreement program accepts an empty or incomplete checker receipt as a successful comparison.
## Fix Focus Areas
- packing/resources/web/couzo-issue763-2026-10-23/review/review-2026-10-24/agree.py[57-66]
- packing/resources/web/couzo-issue763-2026-10-23/review/review-2026-10-24/agree.py[100-106]
## Recommended Fix
Validate that the loaded checker receipt contains exactly one successful result for each expected count, and reject incomplete or unsuccessful receipts before comparing metrics. Require the expected number of agreement checks before returning success.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

View low (1)

5. Credits name a finder the source disputes 🐞

Description

The new 303 entry in CREDITS sets found_by to Vladislav Lavrentev, but the source manifest only
names Couzo's own Kaggle push packing as the parent. The review leaves the origin as an open
question to the author, and the packing also pairs one to one with a public packing by Chris Deotte.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The 303 credit asserts Lavrentev as finder although the review leaves this to the author.

## Fix Focus Areas
- packing/devtools/adopt_houses.py[1754-1759]

## Recommended Fix
Name the push packing as the start until the author answers, then update the structured fields and downstream records together.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗