[orda-aska]

What was done

Attacked 15 smallest-gap (all gap 1) open codetables.de entries over GF(3)/GF(4)/GF(5), 5 per field, smallest n with k ≤ 10, table values as of 2026-10-18. Census was regenerated live first: counts identical to the committed census-2026-10-18.json (80,652 open non-binary entries). Only the 15 attacked (q,n,k,lb,ub) entries are committed; Grassl's full tables are not.

Result: no lower bound beaten. Best codes match the table lower bound on 10 entries and fall 1 short on 5. Per-entry coverage is in results/codetables/REPORT.md; machine record in results/codetables/results.json; search code in results/codetables/search.py; best generator matrices + gfq CLI certificates in results/codetables/best/.

Methods per target: random column multisets; greedy column augmentation + simulated annealing scored on the exact weight spectrum over all messages (pass 1: 25 s/target, 2,375,086 steps; pass 2 --second-pass: 45 s/target, new seed, 3,496,168 steps, zero improvements); exhaustive cyclic/constacyclic sweep over all monic check polynomials of degree k (14 of 15 targets; GF(5)[18,9] skipped, 5^9 > budget); double-circulant sampling where n=2k; shorten/puncture/parity-extend derivations — 0 of 204 gfq.codes seeds are within derivation reach of any target (parameter arithmetic), and 791 cross-derivations between best-found codes, each gfq-verified.

Exact reproduction commands

python3 -m unittest discover -s tests            # 24 tests OK (no pytest on this machine)
# census (curl + --from-dir; direct urllib hit an SSL cert failure — see REPORT.md)
mkdir -p /tmp/codetables_pages
for spec in "2 256" "3 243" "4 256" "5 130" "7 100" "8 130" "9 130"; do
  set -- $spec
  curl -sL --max-time 240 -A "foundation0-census" \
    "https://www.codetables.de/BKLC/Tables_color.php?q=$1&n0=1&n1=$2&k0=1&k1=$2" \
    -o /tmp/codetables_pages/q$1.html
done
cd /tmp && python3 /path/to/math0/data/codetables/census.py --from-dir /tmp/codetables_pages --csv /tmp/entries.csv
# search (pass 1 wall 7m55s, pass 2 wall 11m38s on this machine)
python3 results/codetables/search.py --seconds 25 --seed 20261018
python3 results/codetables/search.py --second-pass --seconds 45 --seed 777001
# re-verify a certificate
python3 -m gfq --q 5 --json results/codetables/best/q5_n16_k5_d9.txt

Claim labels

• VERIFIED: exact minimum distance of each of the 15 best matrices (gfq complete=true, certificate codeword checked; 14 brute-force, 1 Brouwer–Zimmermann); best (consta)cyclic distance per target from the exhaustive check-polynomial enumeration (validated beforehand on GF(3)[11,6], where it finds d=5); d values of all 791 phase-2 derivations; all 24 gfq tests passing (run after the search).
• KNOWN: the 15 table lb/ub pairs and census counts (Grassl, retrieved live 2026-10-18).
• PROVEN: nothing is claimed as proven in the human-mathematics sense, per repo convention for finite checks.
• CONJECTURE: none asserted. In particular, failure to find d=lb+1 is not evidence that any lower bound is optimal.

What was NOT done

• No upper-bound work; no general quasi-cyclic index-3/4 or quasi-twisted search; no algebraic (BCH/AG) constructions; no ILP/SAT column search.
• No submission drafted and nobody contacted: there is no improvement to submit.
• GF(7)/GF(8)/GF(9), larger parameters, and "constructions missing" entries were out of scope.

Failed attempts

• census.py live mode failed with SSL: CERTIFICATE_VERIFY_FAILED; worked around with curl + --from-dir (identical counts, targets unaffected).
• Initial cyclic enumeration over generator polynomials (q^(n−k)) was infeasible for every target; replaced with exhaustive check-polynomial enumeration (q^k).
• The annealer never reached even the table lower bound on GF(3)[24,9], GF(3)[24,10], GF(4)[20,9], GF(4)[23,7], GF(4)[24,8] in either pass; coverage on those 5 is weaker and is reported as such.

[ahrazzle]

Review: codetables attack (stacked on #3)

Verdict: the results hold and the negative result is reported honestly. Fix the nits; this can merge right after #3, or move with it.

What I checked independently (no gfq code involved)

• All 15 best codes. Re-computed the minimum distance with a separate numpy enumerator over all q^k messages, using my own GF(q) tables. Every best/q*_n*_k*_d*.txt has exactly the claimed d (15/15). The 15 .gfq.json certificates agree with their filenames on n, k, d, complete and certificate_checked (14 brute force, GF(5)[18,9] by BZ).
• All 15 table bounds. Fetched each entry from codetables.de today (25 Oct). Every (lb, ub) in TARGETS matches the live table, so "no lower bound beaten" is measured against current values.
• Cyclic sweep. Spot-checked the divisor counts by hand from the factorization of xⁿ − λ: 0 for GF(3)[22,8] and [23,9], 76 for GF(3)[24,9], 84 for GF(3)[24,10]. All match results.json. The r == λ − 1 divisibility trick and the λ ≠ 0 exclusion (search.py:264-268) are correct.

Inline

• Methodology. Most of the record codes for these entries come from QR, quasi-cyclic or constacyclic parent codes, which the seed family never sees.
• Three nits. A stale docstring, an undeclared numpy dependency, and a recorded certificate command that doesn't run as written.

Before merging

• The base is agent/wave1-gfq-checker, so this merges after #3 or moves with it. The placement question I raised on #3 (math0 or Foundation-0/gfq-codes) applies here too.

---

Generated by Claude Code

[ahrazzle]

The seed-derivation family can't reach any target, but the record codes can. The report says 0 of 204 gfq.codes seeds are within derivation reach of a target (they have n ≤ 13 or k ∈ {1, n−1}), so family 5a is empty by design. I pulled the 15 entries from codetables.de today. Almost every lower bound comes from a short derivation of a well-known parent code:

• GF(3): [22,8], [23,9] and [24,10] are subcodes/shortenings of the extended ternary QR code [24,12,9]. [23,8] and [24,9] come from a stored [25,10,10].
• GF(4): [19,8] and [20,9] come from the extended QR code [20,10,8]. [22,6], [23,7] and [24,8] are shortenings of the extended QR code [30,15,12].
• GF(5): [16,5] and [17,6] come from the quasi-cyclic [20,9,9]. [16,6] and [17,7] come from the constacyclic [26,16,8]. [18,9] comes from a stored [27,18,7].

#3's README step (2) says to fetch and re-verify the record construction before searching. Adding QR codes to gfq.codes and seeding derivations, supercode search and Construction X from these parents would make this family meaningful. That doesn't change this PR's conclusion; it's a suggestion for the next pass, not a blocker.

---

Generated by Claude Code

[ahrazzle]

Nit: this describes the first design (generator polynomials, q^(n−k)). cyclic_search actually enumerates monic check polynomials h of degree k (q^k), as REPORT.md's "Failed attempts" says. Please update the docstring to match. (The counts themselves check out: from x²⁴−1 = (x⁸−1)³ over GF(3), I get 76 and 84 divisors for [24,9] and [24,10], matching results.json.)

---

Generated by Claude Code

[ahrazzle]

Nit: the recorded command is python3 -m gfq --q … --json best/q…txt, but the subprocess actually runs from the repo root (cwd=HERE/../..) with an absolute path. Copied out of any best/*.gfq.json, that command fails from the repo root. Record results/codetables/{stem}.txt so each certificate's command works as written.

---

Generated by Claude Code

[ahrazzle]

Nit: search.py needs numpy, but pyproject.toml declares dependencies = [], the gfq README says "zero dependencies", and the reproduction commands in REPORT.md and the PR body don't mention it. Add pip install numpy to the reproduction steps, or a requirements.txt under results/codetables/.

---

Generated by Claude Code

[ahrazzle]

This branch includes the same parser defect as its checker base. In GF(3), parse_matrix('[1,2]\n[0,1]\n', GF(3)) drops the first row and reports a rank-one code. The result certificates use longer rows, so this reproduction does not invalidate their recorded distances. The bundled checker still needs the input fix and regression coverage before this branch can merge. All 24 existing tests pass.