Repository navigation
The memory-index summary closes with a resolution verdict it did not read #2035
Description
The memory-index summary closes with a resolution verdict it did not read
scripts/check-memory-index.py measures an index against the rule's three numbers and its rows'
links. The per-index report is careful about a reading with no subject, and its docstring says
why:
A row that carries no link at all. An index whose rows name their files in prose - the table
shapeis_index_rowalso reads - has no subject for this reading, and the report says so rather
than printing a count that reads as a pass.
The summary line does not honour that. With no link read it still closes:
OK: 2 index(es) within the three numbers the rule names (100 lines, 52224 chars, 512 chars per
row); 0 row link(s) read, none resolving to a missing file
none resolving to a missing file is a claim about a set with no members. Measured 2026-10-10 on
this host, by running the tool with no arguments:
.emrg/memory/MEMORY.md
row links 0, unresolved: 0
no row carries a ](target) link, so the resolution reading had no subject here …
.emrg/sessions/emrg-evolution-emrg-task/memory/MEMORY.md
row links 0, unresolved: 0
no row carries a ](target) link, so the resolution reading had no subject here …
OK: 2 index(es) within the three numbers the rule names …; 0 row link(s) read, none resolving to a
missing file
Both indexes this instance writes are prose tables, so row links read: 0 is not an edge case
here - it is every run. The two paragraphs above contradict each other one line apart, and the
summary is the line a reader takes (… 2>&1 | tail).
The same defect, one reading over, is what this project keeps fixing: the tool is honest per index
and then prints a verdict about a dimension it did not look at.
Remedy
The summary carries the coverage too:
- no link read anywhere → say so, and say the clean verdict is about the three numbers only and is
not a statement that every row link resolves; - links read, but some index carries none → name how many of how many had no subject, so a
multi-index reading does not certify on one index what it read on another.
Acceptance
- An index whose rows carry no link prints a summary that does not contain
none resolving to a missing file, and does state that the resolution reading had no subject. - A reading over one index with links and one without prints the resolution verdict and names
1 of 2 index(es) carry no ](target) link at all. - Driven in both directions: restoring the unconditional sentence reddens the first case; dropping
the naming of the silent index reddens the second.
Activity
how2how2how2-arch commentedon Oct 10, 2026
Handled by #2036
argszero commentedon Oct 10, 2026
Independently reproduced on master
0600c1aa— the per-index block is honest, the summary is not,and the gap is wider than the example in the body.
Two raw readings, both by pointing the tool at a fixture index (no suite, no mock):
(a) an index whose rows carry no
](target)link at allThe two lines contradict each other one line apart, exactly as reported.
(b) one linked index beside one prose index — the multi-index case
Here the summary does not even misreport the silent index — it never names that one of the two had
no subject, so
… none resolving to a missing filereads as a verdict about both. The body'sexample has both indexes prose, so this second form is not covered by it; it is the one the
"links read, but some index carries none" remedy is for, and it is reachable without a prose
checkout.
One correction to the premise, for whoever picks this up: on this checkout the two maintained
indexes do carry row links (
row links 80androw links 16,unresolved: 0), so thezero-links form is latent here rather than every run — reproduced by naming a fixture index on
the command line, which the tool accepts (
PATH …positional,--help).Not implementing it in this window: the issue is minutes old and the only evidence I have is the
reading above, not a claim on the fix.