Doc Consumption

Leading word: the consumption matrix — per-target READ / WRITE / MENTION counts over all session logs (nested included), plus escape-rate and echo verification. Answers "is this doc load-bearing or sediment" with session-log evidence, not with the read-tool call count.

Why read-call counting is wrong (proven pitfalls)

Every one of these was measured in a real 127-session project:

1. bash cat/grep outnumbers the read tool ~40:1 (bash 6413 vs read 170). Counting read calls misses ~97% of consumption.
2. Write ≠ read. A doc written 30× and read 0× is maintenance sediment. Both sides must be counted and compared.
3. Agents fall back to python one-liners to edit files when edit fails (python3 -c "...open('f','w').write(src.replace(...))"), and write via heredocs (cat > f <<EOF) / sed -i. These are WRITE-like. Python with only read markers (open().read(), json.load) is READ-like.
4. Nested session files hold sub-agent populations: <session>/forks/*.jsonl, <session>/<uuid>/run-0/session.jsonl. A top-level *.jsonl glob misses them; discovery must be recursive.
5. A read call is weak evidence. The strong evidence is that the agent's own later reasoning echoes the doc's content.

Process

1. Build the target list

Collect candidate docs/mechanisms from the project: AGENTS.md pointers, ledgers, status files, meta-docs, scripts referenced by rules. Two input forms: