[OffgridwithJD]

@jdatcmd The next twin-less suite, stacked on #1485 (merge that first; this PR's own commits are the top two).

A source arm that passed on a comment

native_fetch_projection.sh checked "index deletion asks whether the row is live" by finding PgColumnarRowIsLive in pgcolumnar_index_delete_tuples. The function stopped asking any row: it vouches for nothing, because an answer from this backend's snapshot erased index entries of rows that are live to everyone else. The only PgColumnarRowIsLive left in it is in the comment explaining that removal, so the arm was green on prose.

• Fix: every source arm now reads the file through code_of, which blanks C comments and keeps string literals (checked on a "x\"/*y" literal). The stale arm asserts what's true now: "index deletion asks no row whether it is live: it vouches for nothing", with a premise that the function was extracted. Only this arm's counts changed under comment-stripping; the rest are the same with or without comments.
• Red first: with the per-row liveness check put back in index deletion, the old suite passes 17/17. The new arm is red in both twins.

The twin, name for name

All 18 checks by the shell's name, in four tests. Under each mutation, the twin reddens exactly the shell's set (measured with a soft-expect runner):

mutation	reds, shell = twin
reconstruct's uncovered set misses the last column	2
read_projection ignores liveness	1
reconstruct ignores the projected fetch's liveness	1
a full decode planted beside the liveness check (#157)	1
index deletion asks each row whether it is live	1
index deletion decodes each row	1
one needed-set test unguarded	1
an empty needed set read as "every column" (the old convention)	0, as the suite's own comment predicts: decoding everything still answers right

"the wide fixture has 41 columns" is now a literal name, because the grader can't read $((NCOLS + 1)). The all-covering projection already names c1..c40.

Five-major runs at head: 18/18 for the shell and 18/18 for the twin, on each of 15–19.

Ledger

Census 4189 / 2990 never / 1199 dated (on #1485's 4171 / 2980 / 1191), with suites_not_covered 200 → 199. 8 of the 18 checks are dated. The gate gives rc 0, and orphan-scan finds 0. 10 arrive never:

• seven premises;
• the fixture's column count and the opening row count;
• the two all-covering-projection arms (the last row of the table).

Collection gives cluster_tests 718 -> 722, and TESTS.md gets §166. The guards pass 438/438 and the grader 40/40.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 53543d7 (its own commits: dd6cfe1, 53543d7, on #1485).

My own mutant, different from your eight: in reconstruct_via_projection, the covered-column copy (columnar_projection.c, isnull = rnulls[covered[i]]) also reports NULL for the first projected column on every 50th row number. PG17:

• shell: every reconstructed row matches the base table: got [400] want [0];
• pytest: the same, got 400 want 0.

So the reconstruct arm catches a covered value going wrong, not only a missing uncovered column.

Note, not blocking: "and its values are right with nothing decoded from the base" (the all-covering projection) stayed green under that mutant, and it's one of the rows you enter as never. I didn't dig into whether its fixture just has no row number divisible by 50, or whether it compares something narrower than the values. Worth a look when you next touch it.

Also checked:

• The code_of comment-blanking fix is the right direction, and "asks no row whether it is live" now states the current design.
• This PR's own diff is the 7 files over #1485.

Merge order: I'll merge #1485 first, then this.

[jdatcmd]

@OffgridwithJD, merging #1487 now: approved at 53543d7, 15/15 green, CLEAN.