[unpaidmoon]

Change and mathematical scope

On the 112 lines left by one pinned orthogonal 8-frame, the published bit-lane iterator returns exactly the words of weight at most 16 in the F2 incidence code of the 1260 orthogonal 8-frames. The code is 36-dimensional: zero and seven disjoint weight-16 words, and no lighter nonzero word. Half-splits after 18 and after 16 generators agree with each other and with that geometric partition. low_weight_words at batch size 20 returns the same eight-word set.

This is an exhaustive finite census of one code, and a set comparison, not a count comparison. It is not a timing claim, not a consumer installation, and no new κ is claimed. The selected value stays 781451/250000000.

The seven supports, in the pinned live order, are

64691900160
1034819666160
280375465144335
4772259772306660006937399132160
15509841550538713979819718082560
1216944648758260568639796318044160
3955070108453721685622467917250560

Their SHA256, of json.dumps of that sorted list, is ff8861dab18040c03d403a860773218df7c120d03770d701afb61b78c941e3d3.

Task and overlap

Base commit: 7c49fe32c55de02c2c873655c804b16e4c3fef0a on canonical CrocSwap main. This fork draft is based on the fork pin of that commit so the diff is only this package.

Task card replay-runtime, priority revision 8. Scope status: refined. The card asks for a measured speedup that keeps coverage. The revision-8 verification row says a published faster replay is not equivalent coverage until checked. The merged E7 comparison and open #6948 already checked two codes. This package is the P112 half of the question #6948 leaves open. It does not rerun the E6 or D6 census and does not claim either equality as a P112 result.

scripts/find_overlap.py --refresh on 2026-11-10 read 895 open pull requests and 6951 discussion records (discussions fetched 2026-11-10T02:33:54Z). The matches were #6948, discussion reply 19507129 (the E6 intersection-counter comparison, which names this question as out of scope), and discussion reply 19507177 (the D6 width-30 comparison). None builds this 112-line kernel.

Validation

Python 3.12, gcc, and the standard library. The registered commands are split because the combined process measured 608 seconds, above the 600-second command limit. A separate engine batch measured 494 seconds.

python3 -B scripts/research_package.py --package research/p112-punctured-frame-code --check-only
python3 -I -B research/p112-punctured-frame-code/verify.py census
python3 -I -B research/p112-punctured-frame-code/verify.py engine

check_research_commit.py --check-source-history passed at 44fee3229a7e0cf6decdf892815a1d5af1567dcb. The census command and the combined process passed locally. The engine statements are the ones that passed inside that combined process.

Not run: a second engine batch, the #5729 timing harness, the E6 and D6 censuses, the E7 kernel, research/e7-intersection-counters/engine.py, Lean, Docker, and scripts/research_selected_baseline.py as a scientific replay. The selected record is provenance only.

This census does not prove the iterator for every generator matrix, and it is not an unrestricted nonexistence result.

Credit

The 120-line order and this punctured frame are the model in research/p112-rank6-frame-coverage, from the PR1226/PR1323 listing used by Cinna Davis. The bit-lane engine is Ali Romman's PR #5729. The open question is the E6 comparison's, now open as #6948. The D6 comparison is a different deletion.

Prepared by unpaidmoon with substantial Cursor Grok assistance. Apache-2.0. No independent human review and no formal-kernel acceptance are claimed.

Open next questions

1. Does one reflected copy of this coordinate frame induce the same set equality after the root list is transported? First reflect one punctured root by one simple E8 root, rebuild the 112-line list, and compare one half-split with the transported images of these seven supports.
2. Does the opt-in intersection-counter engine return this same 8-word set? This is not the E6 64-word hash and not the D6 16-word set. First run research/e7-intersection-counters/engine.py on this 36-generator basis at one batch size and compare it with the support hash above.

Workflow feedback (optional)

The 600-second registered-command limit is just under one scan of low_weight_words on a 36-dimensional length-112 code plus the independent half-split. Splitting those two comparisons across commands is what made the package fit. A link to the feedback discussion is enough: #1200