[brentvatne]

Why

Two gaps left after #96 and #97:

• resolveOwnLogin asks gh api user, which an installation token can't read (403), and then, under Actions, assumes github-actions[bot]. With a GitHub App token that guess is wrong, so the reviewer never recognises its own review comment (it posts a new one each run) and never removes the ready label it added.
• The ready label isn't tied to the reviewed head. After a push it keeps saying "ready" for unreviewed commits until the next review posts, or for good if that run is cancelled or hits timeout-minutes.

Change

• resolveOwnLogin asks GraphQL viewer { login __typename } when /user fails. GitHub documents that query for installation tokens. Only a Bot is accepted, since only an installation token gets that far, and viewerRestLogin adds the [bot] suffix REST uses for comment authors and event actors when GraphQL leaves it off. When both fail, the github-actions[bot] fallback under Actions is unchanged.
• ecr ci removes the bot's ready label before it reviews a pull_request / pull_request_target synchronize event (isNewCommitsEvent, GitHubReporter.removeReadyLabel), in both the single-config and routed paths. The review adds the label back if the new head is ready. A person's label is left alone, as before.
• With a personal or App token, that removal is an unlabeled event that starts another run; under the scaffolded workflow's cancel-in-progress it cancels this run and reviews the same head. That run isn't a synchronize, so it doesn't remove the label again. The default GITHUB_TOKEN starts no runs. The README says so.
• README and LLP 0008 describe both.

Test Plan

bun test (923 pass), typecheck, lint, fmt:check and llp:check pass. New tests:

• viewerRestLogin: a Bot gets the [bot] suffix once; a User or a missing type is rejected
• through a fake gh: with /user failing under Actions, an App's viewer login is used and its label is removed; without a viewer, the github-actions[bot] fallback still removes its label
• isNewCommitsEvent: true only for a synchronize pull_request/pull_request_target event, false for other actions, other events, and a missing or unreadable payload
• removeReadyLabel removes the bot's label and leaves a person's

Not verified live: what GraphQL viewer returns for the default GITHUB_TOKEN. If it isn't a Bot, the existing fallback applies, so the default setup can't regress. This repo's CI runs the engine from the base commit, so this PR's own run doesn't exercise it.

[github-actions]

🤖 AI code review

Decision: Ready for human review

Overall PR risk: Medium. The change modifies how installation tokens resolve their login through GraphQL before falling back to github-actions[bot], and removes ready labels on new commits. Existing behavior is modified for token ownership and label lifecycle. Most plausible issues are incorrect viewer login detection causing duplicate comments, or extra workflow runs from label removal. The impact is bounded to App-token users with direct rollback available.

🔎 Reviewer summaries (3)

• consistency: Checked the new removeReadyLabel call sites in ecr ci, the GraphQL viewer login path, and the new tests against sibling patterns. The changes match the existing reporter, fail-soft, and test conventions. No findings.
• correctness: I reviewed the GraphQL viewer login fallback, the new removeReadyLabel method, and the synchronize-event removal in both CI paths. Label failures stay fail-soft, and a cache hit still reports, so the label comes back. I found no defects.
• security: I reviewed the GraphQL viewer login fallback and the ready-label removal on synchronize events. The GraphQL query is a constant, args go through execFile, the viewer login comes from GitHub, and label errors stay caught. I found no security defect.

🔗 Review setup:

• This PR changes code the reviewer prompts cite (src/tests). Check that the guidance quoting it is still correct.

No findings.

---

This review is advisory — it never blocks a merge and never auto-approves.