Twinned from https://github.com/cfsh/ninefold/issues/671 by tools/beads/import_github.py's reconcile pass.
Filed unclaimed, from a strategic-uplift window. Not my chunk; I hit it while pulling a verdict on #654.
./tools/pr/review_now.py 654 returned:
```
#654: FAILED — see /root/.ninefold-reviewer/logs/pr-654.20260806-162917.log (backoff 45m; rev:pending stays on; --force retries)
⚠ the review spawn FAILED — see the log path above. --force retries.
```
The log is 31 KB of JSONL, almost all of it thinking_tokens heartbeat records. The actual cause is one field on the final result record:
```json {"is_error": true, "subtype": "success", "stop_reason": "stop_sequence", "num_turns": 43, "total_cost_usd": 3.62, "result": "You've hit your session limit · resets 5pm (UTC)"} ```
The account hit its usage limit. Nothing was wrong with the PR, the dispatcher, the lock, or the reviewer prompt.
dispatch.log shows #645 failed the same way at 16:35Z, six minutes after #654 at 16:29Z. One shared limit, two PRs, two opaque failures. Anything reviewed in that window fails identically.--force. The real gate is a wall-clock reset the log already names (*"resets 5pm (UTC)"*). --force before that burns another spawn to fail the same way; after it, waiting the full 45m is pointless. The tool has the reset time and doesn't surface it.is_error: true sits alongside subtype: "success", so anything keying on subtype reads this as a completed review.Have the spawn wrapper read the final result record and put its result string in the failure line:
``` #654: FAILED — session limit, resets 5pm (UTC) (log: …; --force retries after that) ```
Two smaller things in the same area:
is_error, not subtype.STALE-DISPATCH family (#352, #462, #476): this is the same *"a scheduled thing failed and the reason is hard to see"* shape, one level down — the dispatcher is alive and ticking, the individual spawn is what died.The same run recorded four permission_denials, all Bash: gh api …pulls/654 (patch), gh issue view over the five referenced issues, gh api …/contents/…?ref=<head>, and nproc; grep -c ^processor /proc/cpuinfo.
If those denials are expected, the reviewer was reviewing without the issue bodies it itemizes asks from — which would matter for an ask ledger. If they are not expected, the sandbox is tighter than intended. I could not tell which from the outside, and earlier verdicts on the same PR clearly *did* quote issue bodies, so it may be intermittent or may be a fallback path. Recording the observation rather than a diagnosis; whoever owns the reviewer can tell in a minute.
None.
No comments.