[chalfontchubby]

Opened by Claude on behalf of @chalfontchubby.

Problem

A PR opened by the BOT_PR flow is always authored by springfall2008, because that's the bot's credential, and /issue-pr assigns it to springfall2008 as well. So nothing on the PR itself says it's a bot PR, or who pressed BOT_PR for it. That's recorded only in the issue's label history. You can't list bot PRs by label, and the person who asked for one can't find it under their assigned PRs.

Change

When process_bot_pr_issue() has just opened the PR (the same condition that already queues BOT_CLEANUP), the daemon now:

• labels the PR BOT_PR_OPENED, the label the issue already gets. It goes in the same gh pr edit as BOT_REVIEW/BOT_CLEANUP, so it costs no extra call. gh pr list --label BOT_PR_OPENED then lists every bot PR.
• assigns the PR to whoever last added BOT_PR to the issue. The login is read from the issue's events (labeled events for BOT_PR; the latest wins, null actors are skipped). springfall2008 stays assigned too, so gh pr list --assignee @me now shows the requester their bot PRs.

The marking has its own opened_by_bot flag rather than reusing cleanup. A PR found already open on entry may be someone's own, so it is neither labelled nor reassigned.

The assignee step is best effort, because by then the PR is already open and labelled. A failed lookup, an unassignable login, or gh erroring or hanging (120 s timeout) is logged and the flow carries on.

Nothing queries BOT_PR_OPENED on PRs today. Every daemon label query is either gh issue list (issues only) or gh pr list --label BOT_REVIEW|BOT_CLEANUP, so the new label on PRs can't trigger anything.

Already backfilled

I've already applied this by hand to the 79 existing bot PRs, found by the fixed opening line of /issue-pr's PR body ("This is an automated draft PR generated from issue #N"). All 79 now carry BOT_PR_OPENED. The 56 whose issue has a BOT_PR label event are assigned to that person. The other 23 have no such event (opened outside the label flow), so they got the label only.

Tests

python3 tools/test_triage_daemon.py: 339 pass. The new tests cover:

• labelling and assigning a PR the bot opened
• not claiming a PR found already open
• a failed lookup
• a failed assignee edit
• a hung gh
• taking the latest of several label events
• the orchestrator passing opened_by_bot=True

Before the change, the new tests fail. Pre-commit is clean.

The daemon needs a restart after merge to pick this up.

🤖 Generated with Claude Code

[springfall2008]

Automated comment from the triage bot.

Review at commit 61c6c33: 1 low finding, posted inline; no correctness bugs found, nothing body-level.

What I checked beyond the diff. The requester lookup's exact gh call shape runs cleanly against the live API, and on a real BOT_PR issue (#5732) it returns the right login (chalfontchubby); issue events are returned oldest-first, so the 'last line is the latest request' assumption holds; the .actor != null filter correctly skips ghost actors. subprocess.TimeoutExpired subclasses SubprocessError, so the single except in assign_bot_pr_requester() covers both a hung lookup and a hung assignee edit. opened_by_bot=True is passed only at the one 'this run just opened it' call site (triage_daemon.py:1558); the PR-found-already-open path stays unclaimed, matching the PR body's stated trade-off. --add-assignee is additive, so the --assignee springfall2008 that /issue-pr's template always sets survives as assignee; and a BOT_PR labeled event authored by the bot's own credential does occur in this repo's history (#5569) - in that case the assign step targets the already-assigned PR author, a harmless no-op. Nothing in the daemon or the skills queries BOT_PR_OPENED on pull requests (the design docs mention only the issue-side label), so the new PR label cannot trigger any other flow. All new tests pin the new behaviour (they fail if the feature is reverted) and the pre-commit triage-daemon-tests hook runs them.