Conversation
openpyxl fills every position of a merged range with a MergedCell placeholder. The IRS's TY2023 23in54us.xlsx merges its footnote row A179:XFD179, so sheet.max_column became 16,384 and xlsx_used_range would have built about 70 million empty cells (a probe hit 17.9 GB). Placeholders of a merged range that runs to the worksheet edge (column XFD or the last row) no longer widen the bounds; the anchor cell and every other cell still do, and sheets without such a range keep openpyxl's bounds exactly. Scanned every committed workbook (212 files, 2,014 sheets): only 23in54us.xlsx changes, from 4264 x 16384 to 4264 x 143, which is the sheet's own <dimension> (A1:EM4264). A broader rule that ignored every merged placeholder would have moved 309 sheets and was rejected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
soi-state-2023 (23in54us.xlsx, 4 facts) and
soi-ira-{traditional,roth}-contributions-2023 (23in05ira.xlsx and
23in06ira.xlsx from the June 2026 IRA study, 2 facts each) mirror their
TY2022 twins with literal TY2023 labels, so the ty2023 ids now carry
TY2023 data. They follow each workbook's moved layout: the state workbook's
geography label (A8 -> B3), column header (row 3 -> 4) and EITC block
(two rows down), and the IRA tables' Estimates sheet with All taxpayers
on row 7. The raw files were registered with fetch-artifact --upload-r2 and
hash-verified in ledger-raw and chronicle-raw.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…match Addresses the #296 judge review: the max_row edge branch had no test, and a spot-value check could have passed without checking anything. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
ledger-source-fidelity: PASS Recommendation: APPROVE, on three conditions: #292 merges first, the default-bundle snapshot is re-pinned, and a maintainer runs the two checks under "Not verified" before the PR leaves draft. I found no fidelity or boundary defects. How I checked: I only had file-read, search and web tools here. I could not run The review prompt mixes in PR-A items. Several verdict checks describe PR-A, not #296: CSV column letters, the two columns inserted at DP, "interest measures", "four packages" and Findings, by severity1. Medium, blocks merge (disclosed in the PR body): the default-bundle snapshot is not re-pinned.
2. Low: the only check that doesn't depend on the declared cell addresses is skipped in CI.
3. Low: parser test coverage.
4. Low: a test assertion could pass without checking anything.
5. Low / informational: nothing ties the file's own contents to the year 2023.
6. Informational (disclosed): the series now mixes release vintages.
7. Informational: the snapshot script's candidate filter is a text match.
What I checked directlyTY2023 packages against their TY2022 twins. I compared each file line by line and ran
The EITC two-row shift has independent support. Comparing Manifests. Paths, Registration. The aliases (
Not verified
The build still gives good protection here: it checks the row headers, column headers and guards against the bytes, and it fails if any of them doesn't match. Before the PR leaves draft, a maintainer should run:
BoundaryThe PR adds three source-package declarations, their manifests and fixture bytes, a parser bounds fix, alias and coverage registrations, and tests. It adds no reconciliation, aging, imputation, support-aware activation or solver construction. |
|
Main session's response to the judge review above (independent Opus 5.5 via Subfleet; that lane had no shell):
🤖 Generated with Claude Code |
Summary
Adds the TY2023 IRS SOI state-data United States totals and IRA Tables 5/6. They mirror the TY2022 packages that main currently builds at 2023 and stamps as ty2023 (#117). After #292 pins those TY2022 packages to ty2022, these packages supply the real ty2023 facts:
soi-state-202323in54us.xlsx(state-data page, 21 Aug 2026)soi-ira-traditional-contributions-202323in05ira.xlsx(IRA study, June 2026)soi-ira-roth-contributions-202323in06ira.xlsxStacked on #292. Merge after it. Before #292, the TY2022 IRA packages built at 2023 emit the same
irs_soi.ty2023.*_ira_contributions…ids with TY2022 values.What changes
chronicle/sources/cells.py(commit 1).23in54us.xlsxmerges its footnote rowA179:XFD179. openpyxl fills every merged position with aMergedCell, sosheet.max_columnbecame 16,384 andxlsx_used_rangewould have built about 70 million empty cells. A probe reached 17.9 GB before I killed it. Now the placeholders of a merged range that runs to the worksheet edge (column XFD or the last row) do not widen the bounds.(max_row, max_column)exactly.23in54us.xlsxchanges. It goes from 4,264 x 16,384 to 4,264 x 143, which is the file's own<dimension ref="A1:EM4264">.23in54us.xlsx: the geography label moved from A8 to B3 (merged B3:L3), the "All returns" header from row 3 to row 4, and the EITC block two rows down (EITC 3+ rows 146/147, guards on rows 138 and 146).Estimates(wasSheet1), "All taxpayers" is row 7 (was 8), and the header readsNumber of taxpayerswithout the line break.record_set_spec_idis kept, as in the Historic Table 2 and Table 2.5 vintage pairs, so each TY2023 package continues its twin's source series.chronicle fetch-artifact --upload-r2, which writesstorage.r2only after a successful upload. I then mirrored them tochronicle-rawand read all three back from both buckets, hash-verified. The IRA manifests sit beside the TY2022 ones asmanifest_{traditional,roth}_2023_source_package.yaml.SOURCE_PACKAGE_ALIASES;soi-state-2023is also in the SOI filer coverage family anddocs/pe-calibration-targets.md.Chronicle governance
ledger-source-ingestor.build-bundle --year 2023over the three packages is valid: 8 facts, 0 errors, 0 warnings, lineage coverage 1.0 and 0 agent-acceptance errors.N1,A00100,N59664,A59664), 4 of 4. This executes against the CSV from Add IRS SOI Historic Table 2 TY2023 state AGI-band facts #291; in this branch the test skips until Add IRS SOI Historic Table 2 TY2023 state AGI-band facts #291 is on main.ruff checkpasses.ledger-source-fidelity: PASS. An independent Opus 5.5 review via Subfleet, posted as a comment below, re-read every declaration against its TY2022 twin, the layout moves, the manifests, the parser change and the corpus scan. It also hand-checked the cross-file identity (4 of 4).ledger-contract: no schema or consumer-contract change.ledger-boundary: PASS (same review).Invariants (tested)
tax_year_2023and the registered sha.Default-bundle snapshot
The re-pin is computed from in-memory builds of these packages plus every package declaring one of their concepts. Relative to #292's tree it adds +8 facts (US,
tax_year:2023,tax_unit), +3 packages and 0 new semantic-duplicate keys. The absolute values currently sit on #292's un-re-pinned numbers, so this PR stays draft until #292 re-pins, then gets rebased and re-pinned.Note: TY2022 IRA restatement
The June 2026 IRA study that published TY2023 also restated TY2022. The live
22in05ira.xlsxreports 5,900,726 traditional contributors, and Chronicle pins the February 2025 release's 5,101,648. For Roth the figures are 9,170,792 live against 10,036,960 pinned. TY2023 compares cleanly only with the restated TY2022. That re-registration (#225 item 2) is a separate follow-up.🤖 Generated with Claude Code