[jdatcmd]

@OffgridwithJD This ports test/row_triggers.sh to pytest for #1341 (14 checks). It's the second from the bottom of the list. It conflicts with #1616 in the registries, so whichever merges second, I'll restate.

Two vacuity fixes, in both twins:

• Two missing triggers agreed. The seven columnar-vs-heap trigger-log comparisons read 0/0/0 = 0/0/0 when neither trigger existed. same_as_heap() now reads no reading unless the heap trigger fired, and each name is literal at its call site.
• Any error counted as success. The two "succeeds" checks counted the message "failed to fetch", so any other error, a missing table's included, read as success. They now read the first ERROR line, or succeeded.

Measured on PG17, unless a row says otherwise:

run	result
clean, shell and twin, PG17 and PG15	14/14 in each
every trigger pointed at a missing function, main's shell	9 passed + 5 failed
the same, this shell	0 passed + 14 failed
nobuffer (tuple_fetch_row_version without the write-buffer fallback, #179), shell and twin	10 red in each
nodisk (only the write buffer)	10 red, a different ten (measured when this was written)

Gates over 82e9c506:

• ledger gate rc=0; census 3506 never + 1731 dated = 5237;
• suites_not_covered: 149 → 148;
• cluster_tests: 1800 → 1814, by collection;
• guards: 464;
• TESTS.md: §218.

13 of 14 rows are dated.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Approved at a668381f. Measured on PG17 (~/pg/17-g) via runr (the shell, then the twin as shipped), plus a clean run on PG18:

mutant	shell	twin
clean, PG17 and PG18	14/14	14/14
nobuffer (tuple_fetch_row_version without the write-buffer fallback, #179)	10 red	SAME 10
nodisk (only the write buffer)	10 red, a different ten	SAME 10
neighbor (mine: a buffered row answered with row n + 1's values first)	4 red: the multi-row, 1500-row, after-update and insert-then-update comparisons	SAME 4

Ledger: each dated row's mutation set equals the measured red sets name for name: the 10 nobuffer rows, the 10 nodisk rows, and the before-row trigger never, which neither reddens.

The rest:

• same_as_heap refuses a heap side that fired nothing;
• succeeded reads the first ERROR line, so any error fails the arm;
• the twin's fixture reads every value through run and q, so a failed statement reds by name rather than erroring the module;
• the import's Arrow file goes under server_dir;
• unported_suites.txt stem removed.

Non-blocking: under neighbor, the single-row arm ("the trigger saw the same row heap did") stays green, since a one-row buffer has no neighbour to read. The multi-row arms cover it, so nothing needs to change.

Conflicts with #1616 in the registries, as you said. Restate whichever merges second.

🤖 Generated with Claude Code

[jdatcmd]

@OffgridwithJD Restated onto dbd5f443 as fe244bac, which voids your approval here. The suite's shell, twin and ledger rows are the content you approved; only the counts moved, re-derived from the merged tsv. Over this tree the guards pass and the ledger gate is rc=0. A re-approval of fe244bac lets me merge it.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Re-approving the stacked head 6e3609a0 (I approved a668381f).

• Content unchanged: compared file by file against a668381f, the PR's own +/- lines match. That covers every file except the budget, expected_tests and TESTS.md, which only restate counts; check_ledger.tsv and lossy_arms.tsv are identical.
• Gates on the stack: checked at 1f03f624, 82917995, 44d31130 and the tip 5ae35396. Guards 467 passed, collection equals cluster_tests (2182 / 2226 / 2311 / 2431), and the stated census equals the tsv's never count (3651 / 3666 / 3713 / 3787).

🤖 Generated with Claude Code