[pm25coder]

Closes #2601

What changed

scripts/check-memory-index.py gains a fifth reading: a table body row's cell count against its header's. The cells are split by a new emrg.memory.index_row_cells, in the module that already owns what a row is — so "which lines are rows" and "how many cells does this row carry" are one definition rather than two that can drift, the same reason is_index_row is shared with the daemon's compaction trigger.

Both directions fault, and each carries its own remedy:

row at line 10: cells 7, header 5 - a bare pipe splits a cell, and a literal one is written \|
row at line 5: cells 1, header 2 - a cell is missing, and a table row carries every column its header does

\| is content and does not split — without that direction the reading would fault the very repair it prescribes. A line that is not a table row is not a cell subject, the delimiter row is excluded, and when no index read carries a table the per-index report and the summary say the reading had no subject, instead of printing a number that reads like a pass. That is the discipline the row-link clause already follows, and it is why the summary now states which indexes a cell reading actually covered.

The measurement that produced it

On master a2909b4, the index this agent embeds verbatim into every prompt — .emrg/memory/MEMORY.md — declares 5 cells in its header at line 5, and its sandbox-shell row at line 10 carries 7. That row quotes || inside a code span, and GitHub's table syntax splits a line on every unescaped pipe before it renders any span, so the rest of the line is pushed into columns the header never declared.

Before this change the guard printed rows 10, longest 511 chars, over 512: 0 and OK, exit 0: line count, character count, per-row length and row links cannot see a cell boundary.

After it, the same file:

table cells: header at line 5 has 5, rows mismatched: 1
row at line 10: cells 7, header 5 - a bare pipe splits a cell, and a literal one is written \|

exit 1.

The repair to that file

The row is repaired as well, so the guard's own subject is green:

table cells: header at line 5 has 5, rows mismatched: 0
OK: ...

That file sits under .emrg/, which .gitignore excludes, so the repair is host state and is not in this diff — it is reported with its before/after reading rather than carried. Byte level: 8,096 → 8,098 (the two backslashes added), UTF-8 without BOM, line endings unchanged, all other rows untouched.

Tests

Five in tests/test_check_memory_index.py, one per claim above:

• a pipe inside a code span still splits the row → red, naming the line and both counts;
• an escaped pipe is content and does not split → green, the counter-arm differing by exactly two backslashes;
• a row with a cell too few is a fault too → red, and the well-formed row beside it is not named;
• a line with no pipe is not a cell subject → green;
• a list index says the cell reading had no subject → green, asserted in the summary line a reader takes.

Three mutation arms, each restored byte-identical (the file's blob hash compared against the index, so "restored" is a reading and not a claim). Each arm's first reading was whether the mutation landed — the first run of all three reported appears 0 times and measured the unmutated tree, which is why the mutator now normalises newlines before searching:

• the escape branch never runs → test_an_escaped_pipe_is_content_and_does_not_split fails, 5 pass;
• != narrowed to > → test_a_row_with_a_cell_too_few_is_a_fault_too fails, 5 pass;
• the cell reading never reaches the verdict → the code-span test and the too-few test fail, 4 pass.

Full suite on the tree this lands (a53338e8a79ac23db3840bf356c1bfbda8fa96af, with emrg.__file__ confirmed at the checkout rather than the install tree): 5467 passed, 514 skipped, 957.02s.

CI on this head is pending at submission — not green, not read.