Twinned from https://github.com/cfsh/ninefold/issues/491 by tools/beads/import_github.py's reconcile pass.
Filed unclaimed and unlabelled from ninefold-a. Backlog, for a future triage round.
Raised by aedanpope in chat, after being briefly confused by the name while reviewing the design-001 stack:
> "code often references dispatch.log , as do bugs and issues - I wonder if we should rename to reviewer-dispatch.log to avoid the confusion I had above (and prob saves some agent brainpower too)"
He then considered going further:
> "or should dispatch.py be called review.py" … "and review.log"
This issue proposes the first and argues against the second, with the reasoning below so a future triage round does not have to re-derive it. If that reasoning is wrong, the rename is easy either way — the point is that it should be a decision rather than a drift.
The confusion is real and structural: dispatch.log is the one name that routinely appears without its directory. It shows up bare in issues, bug reports, chat, and tail commands, and nothing in the token dispatch says *reviewer*. The repo also has merge_pr, probe_gate, poll and release — "dispatch" reads as generic infrastructure until you know better.
reviewer-dispatch.log is unambiguous on its own, which is the property that matters for a filename that travels.
Surface: 34 references, plus 8 in tests:
| area | refs |
|---|---|
| tools/pr (poll.py — the reader) | 22 |
| tools/reviewer (dispatch.py, README) | 10 |
| tools/tests | 8 |
| CLAUDE.md | 2 |
| design_docs/001 | 2 |
The two design-doc references are a historical record and should probably keep the old name with a note, per #459's amendment convention — the doc describes what was true when written.
Three reasons, in order of weight:
dispatch is the accurate word. That file decides *who needs review* and spawns a reviewer; it does not review. The reviewing is done by the claude -p child it launches. review.py would name it after its subprocess.tools/reviewer/dispatch.py says "reviewer" in the path, and unlike the log, the script is essentially never referenced without it.So the asymmetry is the point: rename the thing that travels alone, keep the thing that travels with its directory.
The path appears in two places that must move together, and one of them is not in the repo:
``` poll.py:127,169 log = path.parent / "dispatch.log" <- the READER README.md:167 ... >> ~/.ninefold-reviewer/dispatch.log <- the deployed schtasks job ```
If the code renames and the registered schtasks job is not re-registered, then:
dispatch.log;poll.py looks for reviewer-dispatch.log, does not find it, and reports logage = -1;Same class as the dispatch.sh/app_token.sh shim retirement: a merge is not a deploy for a scheduled job. Whoever does this must re-register the task in the same session, and should git mv the existing log on disk so its mtime history survives (the mtime *is* the liveness signal).
Doing the rename and the re-registration together, and then watching one poll tick print silence rather than ⚠, is the whole verification.
A one-line fallback in log_age_minutes — check reviewer-dispatch.log, then dispatch.log — would make the transition survivable if the job is re-registered late. Worth it or not depending on how the doer feels about carrying a compatibility shim for a filename; noting it rather than recommending it.
Related: #483 (log growth, deferred to ~Nov — same file, and the deferral there does not defer this rename's constraint), #484 (the broader naming/simplification pass).
None.
No comments.