A maintainer approved PR #7620 three minutes before re-triggering
`@qwen-code /triage`. The run reviewed the PR, scored it 5/5, and then
reported "✅ Approved (5/5) — existing approval from prior run still
valid, head SHA unchanged" without ever calling the approve API. The
approval it read was the maintainer's, on the same head commit; the
bot's own latest review there was a `/review` downgrade to COMMENTED,
and its earlier approval had been dismissed by a push. The PR sat at 1
of the 2 required approvals with nothing in the run log marked wrong.
The skill documents an "already exists, skip re-submitting" rule for
CHANGES_REQUESTED only, and that snippet filters on the bot's login.
Nothing covered approvals, so the rule was generalized to them with the
author filter dropped. Since the maintainer's habit is to approve and
then ask triage for the second vote, this reproduces on every re-run.
Spell the approval check out instead of leaving it to inference: the
skip applies only to the bot's own APPROVED review pinned to the exact
reviewed commit — another account's approval is a different vote, a
DISMISSED review is not an approval, and an approval on an earlier
commit was already voided by the push. Keep the skip itself, so three
re-runs still don't stack three approvals.
Back it with a workflow check, since the failure is silent by nature.
"Notify silent triage re-run" already detected that no review was added;
it just said so in wording that read as a normal ending. It now reports
whether the bot has a review of its own on the head commit, and warns
when it does not.
Also paginate the CHANGES_REQUESTED probe. An unpaginated read sees only
the first page, and re-runs happen on exactly the heavily-reviewed PRs
where the gating review has scrolled past it.
Co-authored-by: verify <verify@local>
3d395606ae