fix(running-in-ci): fetch a review's inline comments as part of reading context

[tend-agent]

A maintainer's inline review comment told the bot not to do a thing; seven minutes later the bot published that exact thing on the same thread, because the review body it read gave no sign the inline comment existed.

What happened

On PRQL/prql#6181, kgutwin submitted review 4911815208 (COMMENTED, 00:07:20Z). Its body is one line — "Closing this in favor of #6020 which is a superset of this PR and is more likely to be merged." The substance was in the review's single inline comment, discussion_r3762633057 on prqlc/prqlc/tests/integration/sql.rs:

Do not create a test that has TODO: this is wrong as its description. Tests that encode current, incorrect behavior are never appropriate.

tend-mention run 31549073589 handled the review event and replied at 00:12:37Z — agreeing with the close, then pasting both of the PR's tests so they could be lifted into #6020. One of the two pasted tests is test_aggregate_matching_group_key, carrying the literal // TODO: this is wrong comment the maintainer had just rejected, offered for adoption into another PR. The inline comment itself was never answered.

Root cause

The session log shows the agent read the review and stopped at its body. The prompt named the review ID but not its contents:

A review was submitted on a PR where you previously participated (PR #6181, …, review ID 4911815208). Read the review and full context.

The agent's two context reads were gh pr view 6181 --json title,body,author,state,headRefName,comments,reviews,url and gh api repos/PRQL/prql/pulls/6181/reviews/4911815208. Neither returns inline comments. The second returned exactly the one-line body, which reads as a complete review. There is no call to reviews/4911815208/comments, pulls/6181/comments, or the comment ID anywhere in the log, and no assistant text mentions the objection.

That is the structural part: both obvious ways to read a review omit its inline comments and give no signal that anything is missing. running-in-ci does carry the correct fetch, but only under "Replying to Comments" — framed as how to reply inline. An agent that reads the body, concludes a top-level comment is the right response, and never intends an inline reply has no reason to reach that section. The recipe sits behind the decision it was supposed to inform.

Fix

One subsection in "Read Context", where the agent learns what to read, stating that the inline comments are a separate fetch and giving the command. It duplicates the gh api …/reviews/<id>/comments call already in "Replying to Comments"; that is deliberate — the two are reached at different moments, and the read-time moment is the one that failed here.

Gate assessment

• Evidence level: Critical — the bot's public output on the maintainer's own thread directly contradicted an explicit instruction contained in the triggering event, and left that instruction unacknowledged. Critical acts on 1 occurrence. Under a conservative High grade this would wait for a second case; the reason it shouldn't is the next line.
• Structural or stochastic: structural. The failure isn't the model forgetting a rule — it's that the review body is a complete-looking read. Replay the scenario and any agent that doesn't independently decide to reply inline misses the comment every time.
• Occurrences: 1 this run; 0 historical. Searched the PRQL/prql evidence gists for 2026-07 and 2026-08 for reviews/<id>/comments, unanswered-inline, and contradicted-maintainer shapes — no prior match. This is the first recorded instance, which is consistent with it needing a review that puts its substance inline rather than in the body.
• Change type: targeted fix (one subsection + one command in an existing section), Normal bar — passes.
• Dedup: no open issue or PR covers it. The neighbouring inline-review work (tend-mention: an inline reply's synthetic review container starts a full session — the empty-body skip only covers APPROVED #866, tend-mention: bot's own non-empty-body review on someone else's PR starts a guaranteed no-op session (#747's sibling leg) #915, review: LAST_REVIEW_SHA anchors on the empty review container GitHub creates for an inline reply, so the next run skips a real commit #828, fix(mention): skip the synthetic reply container the bot's own inline reply creates #849) is all about synthetic review containers and whether a session should start at all, not about what a started session reads.

Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab

Detected by review-reviewers run https://github.com/max-sixty/tend/actions/runs/31552948925.