[jdatcmd]

Fixes the #1339 entry for test_latest_reading.py:96 [weak], in the High section, with the same fix in the shell twin.

The defect

docs/how-to.md says the GROUP BY recipe "reads the table once". Both twins checked only that it returns the rows DISTINCT ON returns. A per-device subquery returns the same rows and reads the table once per device, and every arm stayed green.

The fix

New arm in both twins: the GROUP BY form reads the table once. The form must read at least one block (a query that reads nothing is refused, as for the LATERAL arm) and no more than the table's pages.

PG17 run	table pages	GROUP BY blocks
shell	922	772
pytest	812	677

Evidence

Mutation. I replaced the document's GROUP BY recipe with SELECT d.device, (SELECT max(ts) FROM readings r WHERE r.device = d.device) FROM devices d ORDER BY 1.

major	shell	pytest
15, 16, 17, 18, 19	red: read 30695 blocks, got [-29772] want [1]	red: read 16815 blocks, got -16002, wanted at least 1

"The GROUP BY form returns what DISTINCT ON returns" stayed PASS on every major under the mutant. That proves the defect: the rows-only arm cannot see it.

Clean matrix. Shell 9/9 and pytest 9/9 on each of 15–19. harness_selftest 1246/1246. Collection 750 (unchanged). Guards 439 passed with PGC_REQUIRE=pyarrow. docs_style.sh rc=0.

Ledger. The new row arrives dated by the mutation above, majors 15–19. The census goes from 4396 to 4397 rows: 3055 never (unchanged) and 1342 dated. The gate has rc=0 and finds 0 orphans.

This conflicts with #1490 and #1501 in check_ledger_budget.txt only. Whichever lands later restates.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd approve, at d256a33.

Measured

	shell latest_reading.sh	twin test_latest_reading.py
PG17	9/9	9 of 9 checks
PG18	9/9	9 of 9 checks

• Reads: the shell's table is 922 pages and the GROUP BY read 772 blocks; the twin's is 812 pages and the GROUP BY read 677 blocks.
• Guards: 439 passed. docs_style.sh rc 0.

Red-first

I mutated the recipe in docs/how-to.md and ran main's suite and twin (old) against this PR's (new):

recipe	old	new shell	new twin
your per-device subquery	green on both, PG17 and PG18	read 30695 blocks … got [-29772]	read 16815 … got -16002
reads the readings twice (UNION ALL with itself)	green on both	read 1542 … got [-619]	read 1356 … got -543

A reading of zero or nothing is refused on both sides: if grp else 0 makes at_least(0, 1) fail, and a non-numeric value fails check_num.

Ledger

• 4396 → 4397, with dated +1 and never unchanged at 3055.
• The gate is rc 0 against origin/main with both logs. Main's ledger with the new log reports "new this run=1", so the row is needed.

Non-blocking

The ceiling is "no more than the table's pages", and a clean run reads 84% of them. A recipe reading up to about 1.19× the table would still pass. That is fine for the claim "reads the table once".

Merge order

This changes the budget paragraph, as #1490, #1501, #1513 and #1517 do, so whichever lands later restates its counts. I'll restate mine.

🤖 Generated with Claude Code