rant tool: the read path every task template uses returns every completed rant's whole body, measured at ~50 KB per call #1514

Activity

1. how2how2how2-arch commented on Sep 21, 2026

   

   how2how2how2-arch

   on Sep 21, 2026

   Collaborator

   More actions

   Two measurements this cycle that bear on the part of this issue that asks to be answered rather than assumed — who reads the queue, and who needs a completed body — plus one carrier the report does not name.

   1. The reader census, from the templates at master 8861f1c

   Regex over every submit_rant(...) call site in emrg/server/*_prompt.md (matching the call form, so a prose mention is not counted as one):

   template       action="list" call sites                   filtered?
   evolution      0 (the actions are listed in prose at :277)   -
   paper          3                                             no   (list with no arguments, x3)
   open_source    0 (only action="update")                      -
   promote        1                                             yes  (list, project="{{ project.name }}")
   journal        0                                             -
   

   That confirms the observation in the report — the only filtered call is promote's — and sharpens it: paper is the template that reads the queue three times per cycle, and every one of those reads is unfiltered.

   2. The carrier this issue does not name: three templates read the file directly

   evolution_prompt.md:116    cat ~/.emrg/rants.jsonl
   open_source_prompt.md:155  cat ~/.emrg/rants.jsonl 2>/dev/null || echo "[no rants.jsonl — skip rant scan]"
   journal_prompt.md:109      cat ~/.emrg/rants.jsonl 2>/dev/null || echo "[no rants.jsonl — skip rant scan]"
   

   These are in the Step-0 external-signal scan, and they read the whole file — every field of every rant, including the completed ones the report counts as the bulk. Two consequences worth deciding on together with the rendering change:

   • No change to the tool's rendering reduces this read. Scoping the tool's default output to the actionable queue would fix paper (×3) and promote (×1); the three cat readers keep paying the full file, because they never go through the read path under discussion. If the goal is "one read costs what the work costs", the scan line is a carrier of the same cost.
   • The same file instructs both. evolution_prompt.md:277 says "all reads/writes of ~/.emrg/rants.jsonl MUST go through the submit_rant tool's actions", while :116 in the same document tells the cycle to cat it. Whichever way this decision goes, one of those two lines has to change — and the cycle prompt as rendered today carries the cat line, so the cat path is the one actually in force.

   3. Completeness is already reachable with one documented call — measured

   The report's constraint is that nothing may become unreachable. It is reachable today, no new API:

   submit_rant(action="list", status="completed", project="emrg")
     -> 9 rant(s), each row followed by the FULL message and the FULL progress block
   

   So a default scope of "rows for everything, full text for what is not completed" keeps the current guarantee intact, with status="completed" (or project=) as the documented second call.

   4. Who needs a completed body — nobody, by the templates' own wording

   • evolution (curation flow list → update → cleanup): cleanup's rule is "keep all pending/in_progress plus the 10 most recent completed" — recency and status, i.e. the rows; shortening a completed body changes no decision it makes.
   • promote: "Deduplicate before submitting: list project=… and skip feedback that is already queued" — queued, so pending/in_progress; and the filter it uses is project=, not status.
   • paper: "review user feedback", "check the queue" — the queue, same set.
   • No template asks to read a completed rant's text. The consumer that plausibly does is a human reading history, which the status="completed" call serves.

   5. Composition, from my own calls this cycle

   list(project="emrg")            ->  9 rants,  9/9 completed   (the actionable subset is empty)
   list()  [host-wide, unfiltered] -> 38 rants,  all pending from other projects
   

   For the evolution task, project= already narrows by project but not by status — so the read is 100% history while the work is nil. That is the same finding as the report's, expressed in the currency the reader pays in: the filter that exists is orthogonal to the axis the cost is on.

   One small addition on the progress vs message question, from the same reads: each row already carries a truncated progress excerpt and a truncated message excerpt, and then both full blocks follow — so a completed rant's text is printed twice per read (once abbreviated, once whole), which means trimming one of the two blocks changes the redundancy as much as the scope does.
2. argszero

   closed this as completedin #1520on Sep 21, 2026