board: D-LGJ-FOLD-5 done, the stale owed-clause struck, and the gap that hid a red main

Hygiene for the two commits before it. LATEST_STATE gains the dated section
(the measured table, the group-count arm's reason, the four disable arms);
STATUS_BOARD moves D-LGJ-FOLD-5 off Queued with its numbers.

The minor-12 section's "Still owed" clause said the bricks consumer still
runs the 32-crossing path. It no longer does, so it is struck IN PLACE with
the discharge date rather than deleted -- it was true when written, and this
board is append-only. Its second clause (`lgj_hop` holding mask-sized Vecs)
stands and is still owed.

ISS-LGJ-CONSUMERS-HAVE-NO-CI-LINE is the real finding. `main` was red on a
consumer check and nothing reported it: the one workflow gates `lgj-abi`
only, so no Java compiles in CI at all, and the 612-check core suite plus the
three consumer suites are local gates run by whoever remembers. Same shape as
the r2il probe step that sat absent from lance-graph CI -- a gate that is
never dispatched is indistinguishable from no gate; there the absence was
deliberate and documented, here it is neither. The entry names why it is not
merely "add a job" (JDK 28 is preview-gated and an EA build apt does not
carry, obtained here from a GitHub release download path because the
distribution hosts are gateway-blocked -- a runner's network posture is its
own question), and carries a falsifier: re-introduce the stale pin and the
job must go red, since a job that builds the consumers without running their
mains would pass and be no-gate-with-extra-steps.

Per the board's own termination clause this commit is hygiene-only and
generates no further obligations.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GXUahz73MZxtxWcfpHp9dG

Author: claude

.claude/board/ISSUES.md

@@ -1,3 +1,43 @@
+## ISS-LGJ-CONSUMERS-HAVE-NO-CI-LINE (2026-09-22) — OPEN
+
+`main` was RED and nothing said so. `GraphHopTest` reported 1 FAILED / 65
+passed at `bb81d80`, established by running it from a clean worktree, not
+inferred. The defect itself was small — a pin asserting a second
+`materializeRows()` costs zero crossings, written before `Mask.words()` began
+re-validating its cached window per facade call — and is fixed
+(D-LGJ-FOLD-5's second commit). **The issue is that it survived a merge.**
+
+`.github/workflows/` contains exactly one workflow and it gates `lgj-abi`
+only: `cargo fmt --check`, `cargo clippy -D warnings`, `cargo test`. Nothing
+compiles a single line of Java. The **612-check core suite and all three
+consumer suites are LOCAL gates**, run by whoever remembers to run them, which
+root `CLAUDE.md` states plainly (*"the merge gate is the Rust suite plus the
+409-check Java run"*). A consumer is one step further out still: even a
+session that runs `AllTests` religiously never touches `consumers/`.
+
+This is the **same shape** as the r2il probe step that sat absent from
+lance-graph CI until its OGAR dependency reached main — a gate that exists
+and is simply never dispatched is indistinguishable from no gate. There the
+absence was deliberate and documented; here it is neither.
+
+**Why it is not just "add a job":** a Java job needs JDK 28 with
+`--enable-preview` (JEP 401 is preview-gated, per
+`ISS-LGJ-TOOLCHAIN-MUST-BE-JDK28-VALHALLA-PANAMA`) and JDK 28 is an EA build
+that apt does not carry — the container obtains it from a GitHub release
+download path because the distribution hosts are gateway-blocked. A CI runner
+has its own network posture, so the acquisition ladder that works here is not
+evidence it works there. Scoping that is this issue's first task, not an
+assumption to build on.
+
+**Minimum that would have caught this one:** a job that builds
+`java/src/{main,test}` plus `consumers/*/src` and runs `AllTests` and the
+three consumer mains. No new test, no new assertion — only dispatch.
+
+**Falsifier for any fix:** re-introduce the stale `0` pin on a branch and
+confirm the job goes red. A job that builds the consumers but never runs
+their mains would pass, and would be the no-gate-with-extra-steps outcome
+this entry exists to name.
+
 ## ISS-LGJ-TOOLCHAIN-MUST-BE-JDK28-VALHALLA-PANAMA — UNBLOCKED; JDK 28 installed and the flip proven (2026-09-19)
 
 ⊘ The entry below says the migration is blocked because no JDK 28 can be

.claude/board/LATEST_STATE.md

@@ -1,3 +1,76 @@
+## 2026-09-22 — D-LGJ-FOLD-5: the consumer stops asking sixteen times, and a red pin on `main` gets root-caused
+
+The consumer half of minor 12. `BricksQuery.sumBy()` was sixteen queries —
+one `sumOf` over `where(REGION.eq(v))` per region, each paying plan evaluation
+into a selection mask plus the reduction over it — and is now one fused
+`sumByGroup`. No selection mask is built at any point.
+
+- **Measured through the consumer, not inherited from the core suite:** 1
+  crossing at 1,000 and 64,000 rows, and — new — at 1, 16 and 64 groups.
+  The old path was already invariant in ROWS, which is why its literal was
+  asserted at both row counts; this one is invariant in GROUPS as well, a
+  strictly stronger claim, so it gets its own arm instead of riding on the
+  row-count one.
+- **The group-count arm needed a seam, and the seam is the honest kind.** The
+  public `sumBy()` always asks for exactly `Orders.REGIONS` groups, so nothing
+  the test could previously reach varied the group count and *"one crossing
+  whatever the group count"* was a doc comment no input could falsify. A
+  package-private `sumByGroupCount` serves that arm alone; `getMethods()` does
+  not see it, so the aggregate-only-egress guard still audits exactly the
+  public surface the guarantee is about.
+- **Disable arm A recovered the old cost formula exactly:** reverting to the
+  per-group loop measured **2 / 32 / 128 at 1 / 16 / 64 groups**, identical at
+  both row counts — `2 × groups` — with **parity GREEN throughout**. The two
+  paths agree on the answer and differ only in cost, which is what makes this a
+  migration rather than a behaviour change. Note even the degenerate case
+  discriminates: 1 group costs 2 on the old path, 1 on the new.
+- **`Orders.REGIONS` is a mirror, so it is pinned to the fixture and not to a
+  copied number.** It replaces three literal 16s with one named source for the
+  native generator's classid cardinality, which the ABI manifest does not
+  report. A comparison against a second Java literal would drift in lockstep
+  with whatever edited it and prove nothing; instead every id below REGIONS
+  must carry rows and id REGIONS itself must carry none. Two-sided for a
+  reason: arm B (REGIONS = 20) fires the first half only, arm C (REGIONS = 8)
+  the second only — at 3,960 rows on id 8 — so neither half alone catches
+  both directions.
+- **Return type stays `Map<Integer, Long>`:** sized by the question, one entry
+  per group, never by the data. Handing back `GroupTotals` would leak a facade
+  type into a consumer's public surface for nothing.
+
+**And a separate finding, which is the part worth remembering:
+`GraphHopTest` was RED on `main`.** 1 FAILED / 65 passed at `bb81d80`,
+established by running it from a clean worktree rather than inferred from the
+diff's shape. Consumers have **no CI line** — the only workflow gates
+`lgj-abi` (fmt, clippy, test) — so nothing reported it, the same
+no-CI-line shape that hid the r2il probe step upstream. Filed as
+`ISS-LGJ-CONSUMERS-HAVE-NO-CI-LINE`.
+
+Root cause, and it is the design rather than a regression: `Mask.words()` no
+longer returns its cached window directly — it re-describes through
+`lgj_mask_describe` and compares the returned epoch against its stamp, so a
+cached address is never read after the substrate moved under it. Root
+`CLAUDE.md` names that as shipped. The pin asserting a second
+`materializeRows()` costs **zero** was written against the pure-cache
+behaviour that preceded it, so the test moved, not the code; reverting the
+number would mean deleting the re-validation. The plan's §3.5 *"describe
+cached per Mask; zero crossings steady-state"* is superseded for `Mask`: the
+words are still not re-fetched and the population is still never re-scanned,
+but the describe is no longer free. Steady-state is **constant per call**.
+
+The re-pin asserts that rather than flipping a literal: a THIRD call is
+measured and required to equal the second. A one-off extra describe would
+satisfy a bare `== 1` on the second call; only a per-call cost satisfies
+second == third. **Disable arm D proves the two arms are independent** —
+restoring the pure cache kills the magnitude arm (expected 1, was 0) and
+leaves the constancy arm GREEN at 0, because it tests a different property.
+
+- **Gates:** core **612/612**, bricks **70/70** (was 62; the six group-count
+  arms and two cardinality checks are the +8), graph **68/68** (was 65 + 1
+  failed; the third-call cost and its content check are the +2), trades
+  **12/12 + 3/3** — **765 checks**, JDK 28 `--release 28 --enable-preview`
+  against a freshly built `abi 0.12, ndarray::simd avx512, release`. Four
+  disable arms, each red-then-green.
+
 ## 2026-09-22 — minor 12: `lgj_plan_group_sum_i32`, the grouped sum that never builds a selection (fold-distillation wave 4)
 
 Upstream first (lance-graph #1256 merged `99cdca38`: the tiled executor,
@@ -26,9 +99,12 @@ selection exists at any point.
 - **The eighth named materialisation site:** `Engine.groupSumI32`'s
   `toArray`, sized by `groups` (the question), pinned in `DoctrineFenceTest`
   and listed in root `CLAUDE.md`. `GroupTotals` exposes no array.
-- **Still owed:** the `bricks` consumer's `sumBy()` still runs the 32-crossing
-  path; migrating it to `sumByGroup` is a consumer-wave change, not this
-  one. `lgj_hop` still holds mask-sized Vecs (pre-existing, unrelated).
+- **Still owed:** ⊘ the first clause is DISCHARGED (2026-09-22, D-LGJ-FOLD-5,
+  see the section above) — struck in place, not deleted: it was true when
+  written. It read *"the `bricks` consumer's `sumBy()` still runs the
+  32-crossing path; migrating it to `sumByGroup` is a consumer-wave change,
+  not this one."* That consumer wave has now run. `lgj_hop` still holds
+  mask-sized Vecs (pre-existing, unrelated) and remains owed.
 
 ## 2026-09-19 — PR #81 merged (`07aa441`): production IS the Valhalla arm; Panama × Valhalla is one membrane
 

.claude/board/STATUS_BOARD.md

@@ -131,5 +131,5 @@ same lowering: lance-graph #1257 (SAP CATS, merged).
 | D-id | Deliverable | Status |
 |---|---|---|
 | D-LGJ-FOLD-4 | ABI minor 12 `lgj_plan_group_sum_i32` + `View.sumByGroup` / `sumByGroupVia` + `GroupTotals`: a `GROUP BY … SUM` as ONE program, one crossing, no selection (`docs/abi.md` §20) | **DONE 2026-09-22** — native 191 tests, Java 612 checks (JDK 28), 1 crossing measured beside the 32-crossing path, six disable arms red-then-green |
-| D-LGJ-FOLD-5 | Migrate `consumers/bricks` `sumBy()` from the 32-crossing per-group path onto `sumByGroup` (re-pin BricksAuthTest's crossing arithmetic 32 → 1) | Queued |
+| D-LGJ-FOLD-5 | Migrate `consumers/bricks` `sumBy()` from the 32-crossing per-group path onto `sumByGroup` (re-pin BricksAuthTest's crossing arithmetic 32 → 1) | **DONE 2026-09-22** — one fused call; **1 crossing at 1,000 and 64,000 rows AND at 1, 16 and 64 groups**. The group-count arm is new and load-bearing: the public `sumBy()` always asks for `Orders.REGIONS` groups, so nothing previously reachable varied the group count and "one crossing whatever the group count" was unfalsifiable; a package-private `sumByGroupCount` exists for that arm alone (invisible to `getMethods()`, so the aggregate-egress guard still audits exactly the public surface). Disable arm A (revert to the per-group loop) measured the old cost formula exactly — **2 / 32 / 128 at 1 / 16 / 64 groups, identical at both row counts, i.e. `2 × groups`** — with parity GREEN throughout, so the two paths agree on the answer and differ only in cost. `Orders.REGIONS` replaces three literal 16s with one named source, a MIRROR of the native generator's classid cardinality (the manifest does not report it) pinned two-sided against the fixture rather than against a copied literal; arms B (20) and C (8) each fire a DIFFERENT half, so neither half alone catches both directions. BricksAuthTest **70/70** (was 62) |