Add autopilot-safe close policy for uncalibrated feature-like PRs

[Takhoffman]

Problem

ClawSweeper currently has strong merge-readiness checks: code quality, review findings, bot comments, security status, validation proof, and merge preflight. Those checks answer whether a PR is safe enough to merge, but they do not always answer whether the repository should carry the change.

That leaves a churn failure mode: a non-maintainer PR can be technically clean, low risk, and well-proven while still adding optional product surface, a new config path, a parallel workflow, or a policy choice that has not been accepted by maintainers. If that PR stays open and appears merge-ready, an automated or low-context maintainer pass may merge it because the issue exists and the code looks good.

A related failure mode is that features often arrive disguised as bugfixes. A PR can say it fixes an issue, but the issue may not identify broken existing behavior. It may instead request new behavior, a different default, a new option, or a product judgment. ClawSweeper should not treat "issue exists" as proof that the PR is a bug repair.

Proposal

Add an autopilot-safe close policy for non-maintainer, uncalibrated PRs that are feature-like, product-directional, or bugfix-shaped without a real bug contract.

The policy should use existing ClawSweeper concepts rather than adding new labels or categories:

• item_category
• requires_new_feature
• requires_new_config_option
• requires_product_decision
• work_candidate: manual_review
• existing maintainer/protected-item exemptions
• existing close actions such as low-signal or unsupported closeout

Suggested rule shape:

If a PR is not maintainer-authored, has no maintainer calibration, and requires a new feature, new config option, or product decision, ClawSweeper should close it instead of leaving it open as mergeable work.

For bugfix-shaped PRs, require an existing expected-behavior anchor before treating the work as a bot-landable bug repair:

A bug classification requires a current behavior contract, such as docs, tests, CLI/API behavior, prior behavior, or an explicit maintainer statement. If the linked issue only requests new behavior or a preference change, route it as feature/product work instead of a bugfix.

Maintainer-authored PRs, maintainer-calibrated PRs, protected-label items, security-sensitive items, and active maintainer discussions should remain exempt and route to manual review.

Autoclose exemption guidance

ClawSweeper should give maintainers an explicit, valid way to prevent autoclose when a PR is feature-like but should stay open for maintainer review.

Use existing labels and commands only:

• clawsweeper:human-review: maintainer-applied autoclose exemption. ClawSweeper must not close the PR while this label is present.
• /clawsweeper stop: maintainer command that should apply or preserve the same human-review pause and prevent further close/repair automation until a maintainer asks again.
• /clawsweeper automerge or /clawsweeper autofix: maintainer explicitly opts the PR into the existing bounded ClawSweeper repair loop, so it should not be closed by the low-signal feature-like policy while that opted-in lane is active.
• enhancement: useful supporting signal that the PR is feature/product work, but it should not by itself be the autoclose exemption unless the event is verified as maintainer-authored and ClawSweeper records it as maintainer calibration.

Suggested policy:

If `clawsweeper:human-review` is present, ClawSweeper must skip autoclose for this PR and treat the remaining decision as maintainer-owned.

If `/clawsweeper stop` was issued by a maintainer, ClawSweeper must pause close/repair automation and leave the PR open for maintainer handling.

If a maintainer explicitly opts the PR into `/clawsweeper automerge` or `/clawsweeper autofix`, the PR is calibrated for that bounded lane and must not be closed by the uncalibrated churn policy.

Contributor-applied labels or comments must not count as calibration unless GitHub permissions prove they came from a maintainer.

This keeps the close policy aggressive for accidental merge risk while preserving a clear maintainer override path. The important behavior is not just "keep reviewing"; it is "do not autoclose this PR while the maintainer-owned exemption is present."

Author guidance

The close comment should be direct but reversible. It should explain that the implementation may be reasonable, but passing tests and proof do not establish product acceptance. The author should be routed to Discord or another maintainer-owned discussion path for sponsorship. A maintainer can then reopen the PR, request a narrower version, or confirm the direction is accepted.

Example tone:

Thanks for the PR. Closing this because it adds or changes product surface without maintainer-confirmed direction yet. The implementation may be reasonable, but passing tests and proof are not enough for ClawSweeper to keep feature-like work mergeable by default.

If you want to pursue this, please bring the proposal to the maintainer discussion channel and ask for sponsorship. A maintainer can reopen this PR, request a narrower version, or apply `clawsweeper:human-review` to keep it open for maintainer review.

For bugfix-shaped PRs without a bug contract:

Thanks for the PR. Closing this because the linked issue does not establish a broken existing behavior that ClawSweeper can treat as a bug repair. This may still be a useful product change, but it needs maintainer sponsorship before it should remain open as mergeable work.

Acceptance criteria

• ClawSweeper treats proof of behavior as separate from permission to merge.
• Non-maintainer PRs that require new feature/config/product direction are closed unless maintainer calibration exists.
• Bugfix-shaped PRs require an existing expected-behavior contract before ClawSweeper treats them as bot-landable bug repairs.
• Maintainer-authored and maintainer-calibrated PRs are exempt.
• clawsweeper:human-review prevents autoclose while present.
• Maintainer /clawsweeper stop prevents autoclose/repair automation until a maintainer asks again.
• Maintainer /clawsweeper automerge or /clawsweeper autofix counts as calibration for the bounded repair lane and bypasses the uncalibrated churn close policy.
• enhancement can support feature classification, but does not bypass autoclose unless verified as maintainer-authored calibration.
• Contributor-applied labels or comments do not bypass the close policy unless they are verified as maintainer-authored.
• Closure comments explain how to get the PR reconsidered by a maintainer.
• The implementation reuses existing fields and close mechanics; it does not require new public labels or categories.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 28, 2026, 1:49 AM ET / 05:49 UTC.

Summary
Keep open: current main has adjacent safeguards for bug classification, low-signal PR cleanup, and maintainer pause labels, but it does not implement the requested autopilot-safe close policy for technically clean feature-like or product-directional PRs.

Reproducibility: not applicable. this is a requested automation policy change, not a bug with runtime reproduction steps. Source inspection shows adjacent safeguards exist but the requested close policy is not implemented.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Maintainers need to decide the product-policy boundary before ClawSweeper should automatically close technically clean feature-like PRs.

Review details

Best possible solution:

Codify a maintainer-approved calibration policy that closes uncalibrated feature-like PRs only after live-state checks and explicit exemptions for human-review, stop, automerge/autofix, protected labels, and maintainer signals.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a requested automation policy change, not a bug with runtime reproduction steps. Source inspection shows adjacent safeguards exist but the requested close policy is not implemented.

Is this the best way to solve the issue?

Unclear until maintainers approve the policy direction. The proposal is coherent, but the best implementation should be decided around exact calibration signals and reversible close-comment behavior before code changes.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• An aggressive autoclose policy could close reasonable feature work unless maintainer-calibration and exemption signals are specified very carefully.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 666e707a8288.

Label changes

Label changes:

• add P2: This is a normal-priority automation policy improvement with real merge-churn impact but no immediate outage or security regression.
• add impact:other: The issue affects ClawSweeper's PR queue safety and product-direction routing, which is meaningful maintainer-visible automation behavior outside the specific owned impact categories.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority automation policy improvement with real merge-churn impact but no immediate outage or security regression.
• impact:other: The issue affects ClawSweeper's PR queue safety and product-direction routing, which is meaningful maintainer-visible automation behavior outside the specific owned impact categories.

Evidence reviewed

What I checked:

• Current prompt classifies feature-like work but does not close it: The review prompt already says new capability, config, workflow, or policy-choice requests are not bugs, and that those fields exclude strict bug-fix automation; this covers classification but not the requested PR autoclose behavior. (prompts/review-item.md:98, 666e707a8288)
• Keep-open routing still sends product decisions to manual review: The same prompt routes work needing human/product judgment to manual_review or none, which is safer than merge automation but does not close uncalibrated feature-like PRs by default. (prompts/review-item.md:433, 666e707a8288)
• Low-signal PR policy is narrower than the requested rule: The low-signal instructions are explicitly for manual backlog cleanup and tell reviewers to preserve green checks, focused fixes, or PRs with sufficient real behavior proof; that conflicts with the requested ability to close technically clean but uncalibrated feature-like work. (instructions/low-signal-prs.md:3, 666e707a8288)
• Human-review is a pause label, not a general close-protection label: Current protected labels are security, beta-blocker, release-blocker, and maintainer; clawsweeper:human-review is documented and applied by stop flows, but it is not currently part of the generic close-protection set requested by this issue. (src/clawsweeper.ts:1214, 666e707a8288)
• History points to existing adjacent policy work, not a completed fix: git blame shows the classification/work-lane prompt text came from 6eed37e and the low-signal apply guard from a564e53; neither adds an uncalibrated feature-like PR autoclose policy. (prompts/review-item.md:98, 6eed37e5bfc8)
• No direct implementation found by local search: A source search for uncalibrated, feature-like, product-directional, bugfix-shaped, and bug contract terms found no matching implementation or tests beyond the provided issue language.

Likely related people:

• Peter Steinberger: Git blame and log show the current review prompt, low-signal PR policy, human-review labels, and adjacent issue-implementation lanes were introduced or recently maintained by Peter in the central files for this policy area. (role: recent area contributor; confidence: high; commits: 6eed37e5bfc8, a564e53e7ca3, 82841a028f0f; files: prompts/review-item.md, instructions/low-signal-prs.md, src/clawsweeper.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.