Proposal: expose ClawSweeper issue triage decisions as GitHub labels for maintainer routing

[brokemac79]

Summary - If you agree, I'm happy to take this on and do PR for the phase 1 as a starting point

ClawSweeper already leaves useful review comments on issues, including reproducibility, current-main status, linked PR status, likely fix shape, security/product concerns, and recommended next action.

This proposal is to turn the most important parts of those comments into GitHub labels, so maintainers and future workflows can filter, route, and act on ClawSweeper output without needing to manually read every full comment.

The guiding rule would be:

Comments explain. Labels route.

Clarification

After looking more closely, this is not intended to replace the existing work_candidate, reproduction_status, dashboard, repair intake, or automerge machinery.

ClawSweeper already has structured review data and some label-sync precedent, for example action labels like clawsweeper:autofix / clawsweeper:automerge and proof-related labels such as proof: sufficient.

This proposal is specifically about exposing a small subset of existing issue-review conclusions as GitHub-native advisory labels, so maintainers can see and filter the routing state directly in GitHub.

Phase 1 could be deliberately small: project only a few high-signal labels from existing review output, with no new repair, merge, or close behavior.

Motivation

On issues such as #79735, ClawSweeper already says things like:

• current main still has a source-reproducible path
• there is already an open linked fix PR
• no separate repair lane should be queued
• maintainer follow-up is needed

That information is very useful, but it is currently trapped inside a Markdown comment. Labels would make the same decision visible in issue lists, GitHub search, project boards, and later GitHub Actions workflows.

For example, maintainers could quickly find:

• issues reproduced on current main
• issues needing more reporter info
• issues where a linked PR already exists
• issues that should not get a duplicate autofix PR
• issues that need product/security review before work starts
• narrow bugs that may be safe candidates for a fix PR

Proposed approach

ClawSweeper could apply a small set of advisory labels based on its existing review decision.

These labels should not replace the detailed comment. The comment remains the source of explanation and evidence. The labels only expose the routing state.

Suggested labels

Existing / base label

Label	Meaning
clawsweeper	Indicates the issue has been reviewed or tracked by ClawSweeper.

Reproducibility labels

Label	Meaning
clawsweeper:current-main-repro	ClawSweeper believes the issue reproduces on current main.
clawsweeper:source-repro	ClawSweeper found a high-confidence source-level reproduction path, but may not have run a live/manual repro.
clawsweeper:not-repro-on-main	ClawSweeper checked current main and believes the issue no longer reproduces.
clawsweeper:needs-live-repro	Source evidence is not enough; live local/crabbox/manual validation would materially improve confidence.
clawsweeper:needs-info	The issue lacks enough information to verify current behavior, such as version, logs, screenshots, environment, or reproduction steps.

Work routing labels

Label	Meaning
clawsweeper:linked-pr-open	A PR already appears to target or close this issue.
clawsweeper:no-new-fix-pr	ClawSweeper believes a new automated fix PR should not be queued, usually because an open linked PR already exists or the issue needs a human decision first.
clawsweeper:queueable-fix	Corresponds to the existing work_candidate: queue_fix_pr decision, but exposed as a GitHub label for filtering and project views.
clawsweeper:fix-shape-clear	ClawSweeper has identified a likely implementation direction, but the issue may still require human approval before work starts.

Human decision labels

Label	Meaning
clawsweeper:needs-maintainer-review	Human maintainer review is the next meaningful step.
clawsweeper:needs-product-decision	The fix depends on behavior/API/UX policy, not just implementation.
clawsweeper:needs-security-review	The issue touches security-sensitive behavior or hardening decisions.

Advisory labels vs action labels

These labels should be advisory by default.

ClawSweeper can apply advisory labels such as:

• clawsweeper:source-repro
• clawsweeper:linked-pr-open
• clawsweeper:needs-info
• clawsweeper:queueable-fix

But action labels should remain maintainer-controlled, for example:

• clawsweeper:autofix
• clawsweeper:automerge

That keeps the workflow safe: ClawSweeper can suggest routing, but a maintainer still decides when automation should actually create or merge code.

Examples

For #79735, ClawSweeper’s current comment might translate into labels like:

• clawsweeper
• clawsweeper:source-repro
• clawsweeper:linked-pr-open
• clawsweeper:no-new-fix-pr
• clawsweeper:needs-maintainer-review
• gateway
• app: web-ui
• bug:behavior

For a narrow issue like an edit-tool behavior bug with clear tests and no product/security decision, labels might be:

• clawsweeper
• clawsweeper:current-main-repro
• clawsweeper:fix-shape-clear
• clawsweeper:queueable-fix
• agents
• bug:behavior

Possible phased rollout

Phase 1: label-only, no new automation

Have ClawSweeper apply advisory labels based on the same decision data it already uses for comments.

No workflows act on the labels yet.

Phase 2: maintainer filtering and project views

Use labels to build saved searches or project board views, for example:

• queueable fixes
• needs maintainer decision
• reproduced on main
• linked PR already open
• needs info from reporter
• security/product review needed

Phase 3: optional workflows

Later, workflows could use these labels as inputs.

For example:

• only consider issues with clawsweeper:queueable-fix
• do not act when clawsweeper:no-new-fix-pr is present
• require maintainer-applied clawsweeper:autofix before opening a repair PR

Acceptance criteria

• ClawSweeper applies a small stable set of advisory labels to reviewed issues.
• Labels are derived from existing review output rather than a separate duplicated decision process.
• Existing detailed comments remain unchanged or mostly unchanged.
• Labels are updated or removed when ClawSweeper reruns and reaches a different conclusion.
• Action labels remain maintainer-controlled.
• The label set stays intentionally small enough to be useful in issue lists and project boards.

Non-goals

• This is not a request to immediately automate fixing or merging issues.
• This is not a request to replace ClawSweeper’s review comments.
• This is not a request to label every detail from the comment.
• This should not let advisory labels alone trigger code changes without maintainer intent.

Why this seems useful

ClawSweeper is already doing meaningful triage work. Labels would make that work easier for maintainers to consume at scale, and would create a safer foundation for future workflows because downstream automation could rely on explicit, reviewable routing signals rather than scraping long comments.