Fix: Guard superseded PR closes against unsafe replacements (#198)

Summary:
- The branch adds safe-canonical validation for duplicate/superseded PR closes, updates review policy docs, and expands apply-decision regression tests.
- Reproducibility: yes. Current main's linked PR supersession path is source-reproducible as accepting an open ... nd the PR proof exercises the apply-decisions dry-run path for proof-positive versus no-proof replacements.

Automerge notes:
- PR branch already contained follow-up commit before automerge: Require proof-positive superseded PR targets
- PR branch already contained follow-up commit before automerge: Fix: Guard superseded PR closes against unsafe replacements

Validation:
- ClawSweeper review passed for head 433e985.
- Required merge gates passed before the squash merge.

Prepared head SHA: 433e985
Review: #198 (comment)

Co-authored-by: brokemac79 <martin_cleary@yahoo.co.uk>
Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com>
Approved-by: takhoffman
Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com>

Author: 3 people

README.md

@@ -147,6 +147,10 @@ Issues with an open PR that references them using GitHub closing syntax such as
 that high-confidence PR candidate earlier in the same apply run.
 Open issue/PR pairs from the same author stay open together unless the paired
 item is already resolved or a maintainer explicitly asks to close one side.
+PR-to-PR duplicate/superseded closes also require a safe canonical target:
+ClawSweeper refuses to close one PR as replaced by another PR that is closed
+unmerged, missing positive real behavior proof, F-rated, already proposed for
+close, not cleanly mergeable, or otherwise not a viable landing path.
 
 Repository profiles can further narrow apply. ClawHub and ClawSweeper self-review
 are intentionally stricter: they review issues and PRs, but apply may close only

prompts/review-item.md

@@ -367,7 +367,7 @@ Use reason-specific anchors:
   the decision. Keep the PR open when a meaningful unique fix, feature,
   security hardening, test, doc, migration, or product decision remains.
 - For `clawhub`, inspect `VISION.md` and the relevant plugin/skill/MCP/channel/provider docs or APIs, then confirm the request can be satisfied outside core without a missing extension API.
-- For `duplicate_or_superseded`, read the canonical related report/PR from the provided context or `gh`, and explain whether it is open, closed, merged, or already shipped.
+- For `duplicate_or_superseded`, read the canonical related report/PR from the provided context or `gh`, and explain whether it is open, closed, merged, or already shipped. For pull requests, do not close a PR as superseded by another PR unless the replacement is merged, or it is still open and appears to be a safe landing path with positive real behavior proof. Keep the source PR open when the proposed replacement PR is closed unmerged, missing positive real behavior proof, F-rated, proposed for close, not cleanly mergeable, or otherwise not a safe canonical target.
 - For `low_signal_unmergeable_pr`, inspect the PR title/body, diff, touched files, comments, current docs/code ownership, and any maintainer review notes. Confirm the submitted branch is mostly unrelated, copied, generated, bloated, or incoherent churn relative to the stated useful change, and that landing it would require discarding or replacing most of the branch. Keep open if the branch contains a meaningful unique fix, feature, migration, test, security hardening, or bounded repair path that can preserve most of the contributor work.
 - For `not_actionable_in_repo`, read enough discussion/context to confirm the action belongs to repo/project administration, third-party setup, external ownership, or historical cleanup rather than OpenClaw code/docs.
 - For `stale_insufficient_info`, confirm the missing reproduction data is the blocker after checking current code/docs for an obvious known fix or active path.
@@ -384,7 +384,7 @@ Close only when the evidence is strong and the repository policy allows it. Allo
 - `mostly_implemented_on_main`: an older PR is more than 60 days old, current `main` already implements the central useful part of the PR, and no meaningful unique remainder should be merged from the branch. Use only for pull requests, not issues. The close comment must say what part is already on `main`, what leftover part is minor/obsolete/superseded or separately tracked, and why keeping the stale branch open is not useful.
 - `cannot_reproduce`: you tried a reasonable reproduction path against current `main` and it does not reproduce, or the report is obsolete and no longer matches current behavior.
 - `clawhub`: useful idea, but it belongs as a ClawHub skill/plugin rather than OpenClaw core. Use `VISION.md` as the scope anchor. Prefer this when the requested capability is optional integration/provider/channel/skill/bundle/MCP work, can be built with current skill/MCP/plugin surfaces, has no concrete missing core extension API, and has no protected maintainer signal. This includes service-specific channels, providers, optional skills, and plugin-discovery/publishing ideas when the current plugin or bundle-style interface is sufficient. For OpenClaw PRs that only add bundled skills under paths like `skills/<vendor>/**`, set `itemCategory: "skill"` and prefer `closeReason: "clawhub"` with high confidence; the close comment should ask the contributor to upload or publish it through ClawHub.com instead of bundling it in OpenClaw core. Keep open when the item reports a regression in bundled core behavior, identifies a missing plugin API needed before external implementation is possible, involves security/core hardening, or clearly needs explicit maintainer product judgment.
-- `duplicate_or_superseded`: another issue/PR already tracks the same remaining work, or the linked discussion/PR clearly supersedes this item. Link the canonical item and explain whether it is open or closed/merged. For clusters with the same root cause, keep one canonical issue open and close satellites when their unique logs, platforms, or context can be preserved by linking them in the close comment. Unique evidence blocks duplicate close only when it implies a distinct root cause, platform-specific fix, or separate remaining product behavior.
+- `duplicate_or_superseded`: another issue/PR already tracks the same remaining work, or the linked discussion/PR clearly supersedes this item. Link the canonical item and explain whether it is open or closed/merged. For clusters with the same root cause, keep one canonical issue open and close satellites when their unique logs, platforms, or context can be preserved by linking them in the close comment. For PR-to-PR supersession, the canonical PR must be merged or still open, proof-positive, and viable; do not treat a closed-unmerged, F/no-proof, proposed-close, not-cleanly-mergeable, or otherwise unsafe PR as a reason to close another PR. Unique evidence blocks duplicate close only when it implies a distinct root cause, platform-specific fix, or separate remaining product behavior.
 - `low_signal_unmergeable_pr`: a pull request may contain a small useful idea, but the submitted branch is net-negative and should not stay open as a landing candidate because most of the diff is unrelated, copied, generated, bloated, internally incoherent, or conflicts with the repository's existing structure. Use this for PRs like a narrow docs title that inserts a large unrelated reference block, a tiny bug fix mixed with broad unrelated rewrites, or generated/vendor/config churn unrelated to the stated purpose. The close comment must acknowledge any useful part, explain the concrete unmergeable diff, and invite a new narrow PR for the useful change. Do not use this when the PR has meaningful unique work that can be repaired without throwing away most of the branch, when maintainers asked to preserve/adopt the branch, when a protected label or maintainer author requires human judgment, or when the only issue is ordinary missing proof, test coverage, style, or review follow-up.
 - `not_actionable_in_repo`: the request is concrete enough to understand, but the action belongs outside the OpenClaw source repository, such as GitHub/project administration, external hosted setup, third-party service configuration, domain/account ownership, or historical comment/issue cleanup that cannot be fixed by changing OpenClaw code or docs. Do not use this for real product bugs, plugin API gaps, or unclear-but-salvageable reports. Use this for setup/support reports, one-line reports, screenshot-only reports, or credential-redaction incidents only when current code/docs show the behavior is expected or externally configured and the item lacks a concrete source-level reproduction. Do not keep these open only to collect support logs; the close comment should ask for credential rotation/redaction when relevant and point to the exact diagnostic command or docs page needed for a new actionable report.
 - `incoherent`: the item is too unclear or internally contradictory after reading the title/body/comments.