Repository navigation
Description
Problem
Review Readiness fails a ready PR when its labels are wrong. Of 171 failed runs, 89 had more than one `area:` label and 41 had an unknown area/topic label. Both are labeling defects, not review problems. The PR author sees a red check for something the labeling agent (#5406, #5407) is built to correct.
Proposal
Once the labeling agent can classify and apply labels, Review Readiness would not fail on a label defect that the agent could fix. The check would either:
- wait for, or trigger, a labeling pass and re-evaluate with the corrected labels; or
- fail only after a labeling pass has run and could not resolve the defect (for example, the agent held the item or reported a prerequisite).
The failure message from #5573 and #5575 would remain as the backstop for those residual cases.
Open questions
- Ordering: the readiness check would need to run after, or be re-triggered by, the label write. A `GITHUB_TOKEN` label write does not trigger another workflow (see feat(review): add labeling agent in Claude Managed Agents #5407).
- Which defects count as repairable: multiple areas, unknown or retired labels, and a missing area are the candidates. A roster entry that is not in the label taxonomy is probably not.
- Accepted-work eligibility still applies; the agent would not label items the helper holds.
Dependencies
Depends on #5407 and the dispatch and runner work (#5414, #5439). Part of #5276. Related to #5573.
Cleanup when this lands
#5575 adds author-facing guidance to the label failures in select_reviewers (tasks/scripts/check_review_readiness.py). Once the agent repairs these defects, that guidance should go away:
- More than one area label ("A ready PR needs exactly one; remove the others."): the agent picks the area, so authors should never see this.
- Invalid area or topic labels ("Remove them."): the agent removes invalid labels automatically, so authors should never see this either.
Any remaining failure would report only what the agent could not resolve.
Activity