[max-sixty]

When tend-review reviews a PR this bot authored, it posts its findings and a separate tend-mention session is dispatched to act on them as the author. That session starts cold — it has no memory of authoring — so it re-reads everything the reviewer already had in context, applies the fixes, and pushes, which fires another review. On max-sixty/leaf that hop costs ~$3.55 per boot at list price plus the re-review it triggers, for no independent judgment: it is the same model, told what to fix, starting over.

This makes the review session apply its own findings on PRs with no human author. Step 9 of the review skill already said that for third-party bot PRs (Dependabot, renovate); the bot's own PRs now follow the same rule, and the paragraph that told the reviewer to leave the work to an author session is gone. The order on a bot-authored PR: run the review, submit it against the head reviewed, resolve threads, then apply the findings in one batched push and poll CI to green. The review stays pinned to the head it reviewed — re-targeting onto the pushed head would make the queued synchronize run read it as already reviewed and exit without looking at the fix. Convergence is that run's job: it reviews the pushed head, resolves the threads the fix addressed, and fixes anything new, until a pass finds nothing. Human-authored PRs are unchanged: suggestions first, push only after the author accepts.

The mention verify script no longer dispatches on a review the bot wrote (fresh_inline and the bot-review-on-bot-PR branch are deleted; a human review on a bot PR still dispatches the author session). The dispatched prompt's "including when you authored the review" clause, the system prompt's self-loop exception, and the running-in-ci passages that narrated the old hand-off are cut over with it. Generated workflows in this repo are untouched per the pinned-release rule.

The gate's pre-existing mention-wins order stands: a bot review that names @<bot> still dispatches, and the weekly integration test's §6 relies on that to drive review → relay → dispatch → verify → handle with the single bot identity. The session it boots now exits silently per the self-loop guard, so §6 asserts the session ran (session-log artifact on the dispatch run, as §5 does for review) rather than a reply; outbound posting is already §4's assertion.

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

https://claude.ai/code/session_01BA3Qoj4SjTrvdPJp6eaNLf

[tend-agent]

mention_verify.py still dispatches a bot-authored review that names @<bot> — test_a_mention_wins_over_the_bot_review_gate locks that order — and the weekly integration test's §6 depends on it: it seeds @tend-agent … quoting this token verbatim: $NONCE from the bot account and asserts a reply carrying the nonce. The session that dispatch boots now reads two unconditional exits, though: the system prompt's self-loop guard and running-in-ci's Self-conversation Guard both lost the role-boundary carve-out that used to authorize it. What §6 asserts is the reply, not the dispatch, so it would fail as "mention path broken" with the gate working exactly as this PR intends. Suggestions inline keep the new exit rule and re-carve only the explicit summons.

[tend-agent]

§6's new shape closes out last round's finding: the artifact assertion tests a session the guard now tells to exit silently, where the reply assertion tested behaviour the guard forbids. One inline suggestion below, plus two notes.

The registration cap now measures a different thing. Separate from the run-selection race open on this thread: before this change the seq 1 24 loop watched for any tend-mention run — the relay run, which registers within seconds of the review — so 120s was ample. --event repository_dispatch moves the target past a whole job, since the dispatch registers only once relay has been allocated a runner and has executed its POST. That hop has taken 8–31s on this repo with runners free and 8–12 minutes without (this pull_request_review run started at 07:56:19; its dispatch registered at 08:06:53). The fixture repo is idle, so the fast case should be the norm there — but a slow one exits "dispatch run never registered" and §8 files an issue for a path that was working. The scanning rewrite proposed on that thread absorbs this; a narrower fix to run selection would not.

Outside this diff. running-in-ci's "Investigating Other CI Runs" still says runs triggered by pull_request_review or pull_request_review_comment "sometimes produce no artifact when the session is very short". Under the relay those events only ever run relay — verify and handle skip, as they did on this PR's own review run — so they never produce one at all, and the session-bearing run is the repository_dispatch one §6 now keys on. Happy to push the correction.

[tend-agent]

The two failure messages don't stay separate the way §6's comment promises: REGISTERED is set inside the loop over $NEW, and the --jq narrows that to runs already at status == "completed". A dispatch run that registered and is still executing when the 60×10s budget expires therefore exits dispatch run never registered, and §8 files an issue here blaming the relay leg for a hop that fired — the slow week the split exists to describe. (The snippet I suggested last round carried the same filter; for the tracking to mean "registered" it has to sit on the unfiltered listing.) Dropping the status filter costs nothing: the loop only ever concludes positively per run, so an in-progress run is one extra artifact query that the next iteration re-scans, and an artifact that lands before its run completes is still proof a session ran. Suggestion inline.

[tend-agent]

SEEDED is now the cutoff everything downstream keys on, but nothing asserts the seeding review was actually submitted. If the POST fails (a 422 on the body, a transient 5xx), SEEDED is empty and gh run list --created '>=' returns [] at exit 0 rather than erroring — so the loop burns its full 600s and exits dispatch run never registered, pointing §8 at the relay leg for a failure that happened before any dispatch could exist. That is the same wrong-diagnosis shape the two separate messages exist to prevent. Every other seed in the file is guarded the same way ([ -n "$PR" ] || { … }); suggestion inline.

Superseded by the review on a later commit.