Candidate Bar

Accept only when all are true:

• bug or paper cut, not feature/product/support/docs-only
• root cause is proven in current code
• dependency behavior checked via upstream docs/source/types when relevant
• production/runtime diff is small, ideally much smaller than 500 LOC and always below 500 LOC
• tests may be larger, but focused
• no new dependency
• no new config option
• no backward-incompatible behavior
• no security/product/owner-boundary decision needed
• no plugin SDK, public plugin API, or src/plugin-sdk/** boundary change
• no broad refactor smell
• focused proof is feasible
• branch can be rebased/refreshed and pushed, or a replacement PR can be created

Good examples:

• provider parameter mismatch proven against dependency/API contract
• CLI command diverges from adjacent command behavior
• narrow runtime state/serialization bug with failing test
• issue already fixed on current main, with proof and closeable duplicates

Reject:

• feature requests, new knobs, migrations, release work, workflow policy, support
• plugin SDK/API boundary changes, including compatibility shims, new SDK methods, SDK exports, or plugin-facing channel/provider seams
• auth/security boundary changes unless explicitly assigned
• bugs needing live credentials that are unavailable
• PRs with red CI unless you fix, rebase, push, and recheck them green
• PRs you only reviewed locally but did not refresh/push/check live
• PRs whose final head has not passed $autoreview
• fixes whose clean shape is a larger architecture move
• speculative reports without reproducible/provable cause
• UI/UX changes requiring product judgment

Sweep Loop

1. Start clean:
   • git status -sb
   • git pull --ff-only
   • verify branch is expected, usually main
2. Build candidate clusters:
   • gitcrawl open issues/PRs, neighbors, and search
   • live gh issue/pr view
   • include PRs linked from issues and duplicates
3. For each cluster:
   • read issue/PR body, comments, labels, linked refs, current source, adjacent tests
   • suppress maintainer-owned queue noise unless it is the best fix path
   • identify opener/author and preserve credit
   • decide: repair-existing-pr, create-new-pr, close-fixed-on-main, close-duplicate, or reject
4. Prove before patching:
   • failing test, focused repro, log/source proof, or dependency contract proof
   • if already fixed on main, prove with current source/test/commit and close kindly
5. Patch:
   • prefer existing PR when good and writable
   • if unwritable or wrong shape, create own PR and preserve useful contributor credit
   • if no PR exists, create one
   • add regression test when it fits

…

tag-duplicate-prs-issues

帮助团队检索重复的 PR 与问题单，并自动分组同步重复状态。