Skip to content

fix: reviews whose repository inspection failed still publish a rating and close items - #988

Open
masatohoshino wants to merge 1 commit into
openclaw:mainfrom
masatohoshino:fix/blocked-local-checkout-not-verified
Open

fix: reviews whose repository inspection failed still publish a rating and close items#988
masatohoshino wants to merge 1 commit into
openclaw:mainfrom
masatohoshino:fix/blocked-local-checkout-not-verified

Conversation

@masatohoshino

@masatohoshino masatohoshino commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

What Problem This Solves

When ClawSweeper's read-only repository inspection fails to start, the review it publishes still
carries a Patch quality tier and a merge-readiness verdict, and the item stays eligible for the
apply lane to close. The review text says the opposite in the same comment — for example:

Inspection infrastructure failure: The only permitted local read command failed before opening
repository files: bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted. Consequently,
current-main source, scoped AGENTS guidance, history, and dependency contracts were not
independently inspected.

while the scores table in the same comment reports:

| Patch quality | 🦐 gold shrimp (3/6) | No actionable review findings were identified. |

Maintainers and contributors read a rating and a "no findings" rationale produced by an inspection
that provably did not run, and the item can be closed on that basis.

This is not rare. Of the ClawSweeper comment bodies on openclaw/openclaw last updated between
2026-07-27 and 07-31T12:00Z, 203 of 8,515 currently match bwrap/RTM_NEWADDR — a steady
2.4% share on each of those days. Among bodies last updated during 2026-07-31T14:00Z and
15:00Z that share was 37.2% and 49.3%. Because reviews land as in-place comment edits these
are lower bounds, and they count comment bodies rather than review runs; the exact collection method
and what it does and does not prove are in Real Behavior Proof below.

Why This Change Was Made

The repository already has the guard for this case. hasBlockedLocalCheckoutAccess detects a review
that reports its inspection never ran, and three apply-lane call sites gate on
hasVerifiedLocalCheckoutAccess: the guard whose skip reason is literally
review lacks verified local checkout access, the comment-sync guard, and the counterpart check in
the same-author PR+issue pair close.

Those guards could not distinguish this case. local_checkout_access: verified is emitted as a
literal by the review-record writer, so for every record that writer produces
hasVerifiedLocalCheckoutAccess was true regardless of what the review reported. The blocked
predicate's only consumer was effectiveReviewStatus, which classifies the record
stale_local_checkout_blocked — that affects re-review scheduling, not publication or close.

The change requires both signals, so the existing guards apply to reviews that already report a
blocked inspection. No new configuration, no new state, no change to how ratings are rendered.

effectiveReviewStatus is unchanged for every input: it tests the blocked predicate first, so
blocked records still return stale_local_checkout_blocked, and non-blocked records fall through to
the same front-matter check as before. That is an invariant by construction in a four-line function,
not something a new test asserts.

Non-goals.

  • bubblewrap, the runner image, and network-namespace permissions — the sandbox failure originates
    in the review runtime, not here.
  • src/repair/workflow-utils.ts reads local_checkout_access from the front matter directly and is
    built as a separate module that does not import this predicate. It is unchanged: blocked
    records remain selectable there. That site produces close candidates for the apply lane rather
    than closing anything itself, so the apply guard above is still what withholds the close — but the
    selection is wasted work and making that module agree is left for a separate change.
  • widening which phrasings count as a blocked inspection (see Limits).
  • the rendered scores table; withholding or marking the patch-quality axis for a blocked review is a
    separate question.

User Impact

On the ordinary apply path, a review whose report matches the existing blocked-inspection predicate
no longer syncs its comment and is not eligible to close. Such a record is already classified
stale_local_checkout_blocked, so it stays due for re-review. This change does not remove or edit a
blocked comment that was already published, and it does not make the scheduled re-review succeed; it
stops the lane from publishing a new one or closing on it.

A matching record also no longer qualifies as the counterpart in a same-author PR+issue pair close,
so that pair is kept open instead. Same fail-safe direction, and no focused test covers that path.

The withholding is bounded in two ways, both deliberate:

  • It applies to reports the existing predicate recognises, not to every failed inspection. The
    promisor/DNS variant in Limits below is a counterexample that this change does not catch.
  • Two pre-existing bypasses are unchanged: shouldProbeClosedState skips the apply guard, and
    staleCanonicalCommentSyncPending skips the comment-sync guard. Both are narrow recovery states,
    and this change does not alter either condition.

For records that do not match the predicate, nothing changes.

Evidence

src/clawsweeper.ts +7/−1, plus one focused test in the narrowest matching file
(test/apply-blocked-local-checkout.test.ts, alongside the existing apply-* policy tests).

Real Behavior Proof

Claim. A review record whose body reports that its read-only inspection never ran is admitted
past the apply lane's local-checkout guard on main, and is withheld after this change with the skip
reason the guard already defines. The claim is scoped to the ordinary apply path — the exception
branches above and src/repair/workflow-utils.ts are not exercised.

Environment. Node v24.18.0, Linux. Base 0ee212e35. Branch head 69926bd38.

1. Non-mocked dry-run against a live GitHub item

Real gh at /usr/bin/gh, no GH_BIN / GH_BIN_ARGS override (env | grep -c '^GH_BIN'0).
--dry-run short-circuits before the comment upsert (src/clawsweeper.ts:29492) and before the close
(src/clawsweeper.ts:29827), so every path below is read-only. Following the apply-repro guidance in
AGENTS.md, one record for the real open issue openclaw/clawsweeper#951 was copied into a temp
items/ dir with a temp --record-root, --closed-dir, and --plans-dir. The record declares
local_checkout_access: verified and labels: [], and its body carries the sandbox-failure sentence.

$ node dist/clawsweeper.js apply-decisions --target-repo openclaw/clawsweeper \
    --record-root $R --items-dir $R/items --closed-dir $R/closed --plans-dir $R/plans \
    --report-path $R/apply-report.json --item-numbers 951 --dry-run \
    --limit 1 --processed-limit 2 --close-delay-ms 0

With this change (head 69926bd38):

[apply] 2026-07-31T23:50:41.883Z starting apply: files=1 dry_run=true apply_kind=issue ... item_numbers=951 ... counts={}
[apply] 2026-07-31T23:50:43.350Z finished apply closed=0/1 processed=1/2 counts={"kept_open":1}

$ cat $R/apply-report.json
[
  {
    "number": 951,
    "action": "kept_open",
    "reason": "review lacks verified local checkout access"
  }
]

Same record, same command, unmodified base 0ee212e35:

[apply] 2026-07-31T23:51:21.636Z starting apply: files=1 dry_run=true ... item_numbers=951 ... counts={}
[apply] 2026-07-31T23:51:27.937Z finished apply closed=0/1 processed=1/2 counts={"skipped_protected_label":1}

$ cat $R/apply-report.json
[
  {
    "number": 951,
    "action": "skipped_protected_label",
    "reason": "protected label: clawsweeper:needs-maintainer-review, clawsweeper:needs-product-decision, clawsweeper:needs-security-review"
  }
]

On base the record is admitted past the local-checkout guard and evaluated further, reaching the live
protected-label check. That check reports labels the record never declared, so the run genuinely
queried GitHub — gh was not mocked. With the change the same record stops at the guard.

This particular item carries protected labels, so on base it stops there rather than at
would close; the admitted-through-to-close path is what the harness test below shows.

2. Focused harness test (before / after)

Exercised surface. The same apply entry point, node dist/clawsweeper.js apply-decisions, driven
end to end through runApplyDecisionsForTest, with gh mocked at the process boundary via
withMockGh so the close proposal can be carried to completion deterministically.

Scenario / fixture. One review record in a temp items/ dir, carrying the front-matter value the
review writer emits (local_checkout_access: verified, asserted in the test) and, in the body, the
sandbox-failure sentence quoted above. Decision close / implemented_on_main, with the durable
review comment already synced.

Command.

./node_modules/.bin/tsc -p tsconfig.json
node --test test/apply-blocked-local-checkout.test.ts

Observed result — on main (fix reverted, test kept):

✖ apply withholds close when the review reports a blocked local checkout
  AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
  + actual - expected

    [
      {
  +     action: 'review_comment_synced',
  -     action: 'kept_open',
        number: 10,
  +     reason: 'would update durable Codex review comment'
  -     reason: 'review lacks verified local checkout access'
      },
  +   {
  +     action: 'closed',
  +     number: 10,
  +     reason: 'dry-run: would close as already implemented on main'
  +   }
    ]

The item is comment-synced and closed. The guard never fires.

Observed result — with this change:

✔ apply withholds close when the review reports a blocked local checkout (155.679ms)
ℹ tests 1
ℹ pass 1
ℹ fail 0

Reverting only src/clawsweeper.ts to 0ee212e35 and rebuilding reproduces the failure above, so the
test has teeth.

3. Public measurement

Reproducible from the GitHub API. For every clawsweeper[bot] issue comment on openclaw/openclaw
whose body was last updated in the window, the current body was matched against /bwrap|RTM_NEWADDR/
and bucketed by updated_at.

## Bodies last updated 2026-07-27 -> 07-31T12:00Z
2026-07-27  bodies= 973  matching= 18  share=  1.8%
2026-07-28  bodies= 915  matching= 24  share=  2.6%
2026-07-29  bodies=1121  matching= 27  share=  2.4%
2026-07-30  bodies=3148  matching= 74  share=  2.4%
2026-07-31  bodies=2358  matching= 60  share=  2.5%
TOTAL       bodies=8515  matching=203  share=  2.4%

## Bodies last updated 2026-07-31T12:00Z -> 16:51Z (hour buckets, UTC)
2026-07-31T12  bodies= 290  matching=  5  share=  1.7%
2026-07-31T13  bodies= 228  matching=  5  share=  2.2%
2026-07-31T14  bodies= 129  matching= 48  share= 37.2%
2026-07-31T15  bodies= 150  matching= 74  share= 49.3%
2026-07-31T16  bodies= 330  matching= 32  share=  9.7%
TOTAL          bodies=1127  matching=164  share= 14.6%

What this is and is not: matching counts bodies matching /bwrap|RTM_NEWADDR/, which is a
narrower query than hasBlockedLocalCheckoutAccess — the predicate also recognises five other
sandbox phrasings, so the true share is at least this. Buckets are comment bodies last updated in
that bucket
, not publication events and not per-day review incidence. Reviews land as in-place
edits, so a body written during an outage and re-reviewed afterwards now reads clean and is counted
clean. A match shows the published text reports a failed inspection; it is not by itself evidence
that any apply action ran on that item.

4. Suite and static checks

node scripts/run-node-tests.mjs all → 2851 tests, 2845 pass, 6 fail. The same 6 fail on
unmodified 0ee212e35 in this environment (test/repair/target-validation.test.ts — detached-process
reaping and git branch plumbing, both needing a real pnpm install and worktree setup this checkout does
not have). oxfmt --check, oxlint (src / scripts+test), check:active-surface, check:limits,
check:dashboard-queue-boundary all pass.

Limits — what this proof does not cover

  • Coverage is one path. Both runs exercise the ordinary apply path only. The same-author
    pair-close counterpart check, the shouldProbeClosedState and staleCanonicalCommentSyncPending
    bypasses, and the close-promotion selector in src/repair/workflow-utils.ts are untested here.
    The effectiveReviewStatus invariant is argued by construction, not asserted by a new test.
  • The non-mocked run stops earlier on base than the harness run does. openclaw/clawsweeper#951
    carries protected labels, so on base it reaches skipped_protected_label rather than a close. The
    non-mocked run therefore demonstrates that the checkout guard does not fire on base and does fire
    after the change; the close consequence itself is shown only under the mocked harness.
  • No auto-close on a blocked review was observed in production. The close path is reachable —
    clawsweeper[bot] closed 10 openclaw/openclaw items in the last 7 days — but none of the items
    closed during the sampled window carried a matching review. The 39 matching items closed between
    14:00Z and 16:51Z were all closed by humans. The close behaviour above is demonstrated on the real
    apply path, not observed in the wild; the published-rating harm is what is observed.
  • The measurement counts comment bodies, not review runs, and is a lower bound. See the method
    note above it.
  • The claim about the writer is scoped to the writer. hasVerifiedLocalCheckoutAccess was true for
    every record the current review-record writer produces, because that writer emits the literal. It says
    nothing about hand-edited, malformed, or pre-existing records that lack the key; those already
    resolved to unverified and still do.
  • Detection coverage is unchanged and is known to be incomplete. A re-review of one affected PR
    replaced the bwrap failure with promisor objects; Git attempted to fetch them and failed because github.com could not resolve — plausibly the same root, but hasBlockedLocalCheckoutAccess does not
    match that phrasing, so such a review is not even classified stale. Widening the predicate from one
    observed sample seemed worse than leaving it to a decision about how the reviewer should report
    inspection failure structurally; the review prompt currently asks for prose only.
  • False-positive direction. The predicate matches the whole record, so a review of a PR that
    legitimately discusses bwrap: loopback would be treated as blocked. That already causes permanent
    staleness on main; with this change it would also withhold the comment on the ordinary path. The
    direction is fail-safe — the lane declines to act rather than acting on a review it cannot trust — but
    it is a real behaviour change for that case.

`local_checkout_access: verified` is written as a literal in the review-record
template, so `hasVerifiedLocalCheckoutAccess` was true for every record. The
three guards that consult it could not fire, including the apply guard whose
skip reason is "review lacks verified local checkout access".

`hasBlockedLocalCheckoutAccess` already detects a review that reports its
read-only inspection never ran, but its only consumer was
`effectiveReviewStatus`, which affects re-review scheduling and not publication
or close. A review that recorded a sandbox startup failure was therefore still
comment-synced and still eligible to close.

Require both signals so the existing guards apply. `effectiveReviewStatus` is
unchanged: it tests the blocked predicate first, so the
`stale_local_checkout_unverified` branch stays unreachable for blocked records.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@masatohoshino
masatohoshino marked this pull request as ready for review July 31, 2026 23:33
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P1 Urgent regression or broken agent/channel workflow affecting real users now. merge-risk: 🚨 automation 🚨 Merging this PR could break CI, automerge, proof capture, label sync, or automation. labels Jul 31, 2026
@clawsweeper

clawsweeper Bot commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed August 3, 2026, 5:05 AM ET / 09:05 UTC.

ClawSweeper review

What this changes

The branch changes local-checkout verification so a review record that reports blocked repository inspection cannot be comment-synced or automatically closed, and adds a focused apply dry-run test.

Merge readiness

Blocked until stronger real behavior proof is added - 9 items remain

This PR addresses a real fail-safe gap, but its single production edit targets the pre-refactor monolith while current main evaluates the same decision in src/clawsweeper-record-metadata.ts. The branch is currently dirty against main, and its focused test and terminal proof cover the historical entry point rather than the active refactored path, so it should remain open only for a narrow rebase-and-port repair.

Priority: P1
Reviewed head: 69926bd38453b88313352d6f2504ea527abd3dee

Review scores

Measure Result What it means
Overall readiness 🦪 silver shellfish (2/6) The safety intent and historical evidence are useful, but the current patch does not reach the active implementation and cannot merge cleanly.
Proof confidence 🦐 gold shrimp (3/6) Needs stronger real behavior proof before merge: The PR body contains strong redacted terminal and harness evidence for its July 31 predecessor path, but the branch is now dirty and current main moved the active predicate to record metadata; add redacted post-rebase output that proves a blocked record cannot sync a durable comment or close an item through the current path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality 🦪 silver shellfish (2/6) 1 actionable review finding remain.

Verification

Check Result Evidence
Real behavior Needs proof Needs stronger real behavior proof before merge: The PR body contains strong redacted terminal and harness evidence for its July 31 predecessor path, but the branch is now dirty and current main moved the active predicate to record metadata; add redacted post-rebase output that proves a blocked record cannot sync a durable comment or close an item through the current path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed 6 items Active current-main implementation: Current main keeps the blocked-inspection detector in the record-metadata module, but hasVerifiedLocalCheckoutAccess still accepts any record whose front matter says verified; the report writer still writes that value unconditionally.
Active apply guards consume the metadata result: The current apply workflow uses verifiedLocalCheckout to withhold ordinary apply and close-proposal comment sync with the existing reason review lacks verified local checkout access; therefore the correction must reach the active metadata factory.
Writer makes the front-matter value non-discriminating: The review document template emits local_checkout_access: verified directly, which means current verification needs to incorporate the blocked-inspection evidence as the PR proposes.
Findings 1 actionable finding [P1] Port the checkout gate to the active metadata module
Security None None.

How this fits together

ClawSweeper’s review lane emits durable Markdown records; the apply lane reads their metadata before synchronizing a review comment or closing an eligible GitHub item. The local-checkout gate is the safety boundary that prevents automation from acting on a review whose source inspection did not run.

flowchart LR
  A[Codex review record] --> B[Inspection evidence]
  B --> C[Record metadata gate]
  C --> D[Apply decision workflow]
  D --> E[Durable review comment]
  D --> F[Automatic item close]
Loading

Before merge

  • Add real behavior proof - Needs stronger real behavior proof before merge: The PR body contains strong redacted terminal and harness evidence for its July 31 predecessor path, but the branch is now dirty and current main moved the active predicate to record metadata; add redacted post-rebase output that proves a blocked record cannot sync a durable comment or close an item through the current path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
  • Port the checkout gate to the active metadata module (P1) - hasVerifiedLocalCheckoutAccess was moved to src/clawsweeper-record-metadata.ts on current main, where it still accepts the unconditionally written front matter. This edit only changes the retired monolithic copy, so rebasing will either conflict or leave the active apply path unchanged; move the !hasBlockedLocalCheckoutAccess(markdown) condition and its coverage to the current module. This is the unresolved blocker from the prior review cycle.
  • Resolve merge risk (P1) - Merging the branch as submitted is not viable: GitHub reports a dirty merge state, and the changed helper no longer owns current-main apply eligibility after the automation split.
  • Resolve merge risk (P1) - The supplied dry-run and harness proof demonstrate the predecessor path, not a rebased head that exercises current src/clawsweeper-record-metadata.ts and src/clawsweeper-apply-decision-workflow.ts.
  • Resolve merge risk (P1) - src/repair/workflow-utils.ts still selects promotion candidates directly from local_checkout_access; determine during the rebased repair whether its candidate-selection semantics require the same blocked-inspection condition or are intentionally deferred behind apply-lane safety.
  • Complete next step (P2) - A narrow mechanical rebase can transfer the already-proposed fail-safe condition and regression coverage to the active record-metadata/apply boundary; the contributor’s branch itself should not merge before that repair and proof refresh.
  • Improve patch quality - Rebase onto current main and move the predicate change to src/clawsweeper-record-metadata.ts.
  • Improve patch quality - Add focused current-path coverage for blocked records, including the close-proposal comment-sync guard.
  • Improve patch quality - Post redacted current-head dry-run output; after updating the PR body, request a fresh ClawSweeper review if one does not start automatically.

Findings

  • [P1] Port the checkout gate to the active metadata module — src/clawsweeper.ts:8039-8046
Agent review details

Security

None.

Review metrics

Metric Value Why it matters
Patch scope production +7/-1, tests +102 The intended repair is narrow, but all production edits currently land in a superseded ownership location.
Current-path gap 2 active apply guard sites; 1 retired helper changed Both current close and comment-sync paths rely on the metadata result, so the active metadata predicate is the required repair boundary.

Merge-risk options

Maintainer options:

  1. Port the guard after rebasing (recommended)
    Move the blocked-inspection condition into the active record-metadata path, retain the existing apply skip reason, and prove the rebased head with focused tests and a redacted dry-run.
  2. Pause the obsolete branch
    Close this branch if the contributor does not want to rebase it, because its only production change belongs to superseded pre-refactor ownership.
Copy recommended automerge instruction
@clawsweeper automerge

Special instructions:
Rebase onto current main, port the blocked-inspection guard into the active record-metadata/apply path, add focused regression coverage for comment sync and closure withholding, and include redacted current-head dry-run proof.

Technical review

Best possible solution:

Rebase onto current main, make the active record-metadata verification predicate reject records whose body matches the existing blocked-inspection detector, add focused coverage through the current apply workflow for both comment-sync and close withholding, and publish redacted current-head dry-run output before merge.

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

Yes, for current main by source: the record writer emits local_checkout_access: verified, while the active metadata predicate treats that field alone as verified even when the same Markdown matches the blocked-inspection detector. The contributor’s supplied dry-run establishes the historical symptom, but a fresh current-head run is still required as merge proof.

Is this the best way to solve the issue?

No, not as submitted: the fail-safe rule is appropriate, but the branch changes a pre-refactor monolithic helper rather than the active record-metadata implementation that feeds current apply guards.

Full review comments:

  • [P1] Port the checkout gate to the active metadata module — src/clawsweeper.ts:8039-8046
    hasVerifiedLocalCheckoutAccess was moved to src/clawsweeper-record-metadata.ts on current main, where it still accepts the unconditionally written front matter. This edit only changes the retired monolithic copy, so rebasing will either conflict or leave the active apply path unchanged; move the !hasBlockedLocalCheckoutAccess(markdown) condition and its coverage to the current module. This is the unresolved blocker from the prior review cycle.
    Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 2d1a40bfa643.

Labels

Label justifications:

  • P1: A blocked repository inspection can otherwise allow apply automation to publish a review comment or close an item without the required source evidence.
  • merge-risk: 🚨 automation: The PR changes the gate controlling automated durable-comment synchronization and item closure.
  • rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦐 gold shrimp and patch quality is 🦪 silver shellfish.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body contains strong redacted terminal and harness evidence for its July 31 predecessor path, but the branch is now dirty and current main moved the active predicate to record metadata; add redacted post-rebase output that proves a blocked record cannot sync a durable comment or close an item through the current path. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

Acceptance criteria:

  • [P1] node --test .
  • [P1] pnpm run check.
  • [P1] Redacted apply-decisions --dry-run against a temporary record whose body contains a recognized blocked-inspection message, demonstrating kept_open and no comment-sync/close action.

What I checked:

  • Active current-main implementation: Current main keeps the blocked-inspection detector in the record-metadata module, but hasVerifiedLocalCheckoutAccess still accepts any record whose front matter says verified; the report writer still writes that value unconditionally. (src/clawsweeper-record-metadata.ts:472, 2d1a40bfa643)
  • Active apply guards consume the metadata result: The current apply workflow uses verifiedLocalCheckout to withhold ordinary apply and close-proposal comment sync with the existing reason review lacks verified local checkout access; therefore the correction must reach the active metadata factory. (src/clawsweeper-apply-decision-workflow.ts:637, 2d1a40bfa643)
  • Writer makes the front-matter value non-discriminating: The review document template emits local_checkout_access: verified directly, which means current verification needs to incorporate the blocked-inspection evidence as the PR proposes. (src/clawsweeper-report-document.ts:557, 2d1a40bfa643)
  • Current-main provenance: The active ownership boundary was introduced by the current-main refactor refactor: split review rendering and automation into cohesive modules (#1019), which added the record-metadata and apply-review-guard modules after this PR’s base. (src/clawsweeper-record-metadata.ts:53, 2d1a40bfa643)
  • Recent area history: Recent commits on the active record/apply files include the split of apply phases and a durable-comment synchronization fix, identifying the current ownership trail rather than the PR author’s historical branch. (src/clawsweeper-record-metadata.ts:53, e55de43cfc03)
  • Branch integration state: The PR base is an ancestor of current main, but current main added the active record-metadata and apply-review-guard files while the PR changes the retired monolithic implementation; GitHub reports the PR merge state as dirty. (src/clawsweeper.ts:8037, 2d1a40bfa643)

Likely related people:

  • Peter Steinberger: Peter authored the current-main automation split and the recent record/apply history that now owns the behavior this PR must modify. (role: recent area contributor; confidence: high; commits: 2d1a40bfa643, e55de43cfc03, 8a31b9f89386; files: src/clawsweeper-record-metadata.ts, src/clawsweeper-apply-decision-workflow.ts, src/clawsweeper-apply-review-guards.ts)

Rating scale

Score Internal tier Crab rank Meaning
6/6 S 🦀 challenger crab Exceptional readiness
5/6 A 🦞 diamond lobster Very strong readiness
4/6 B 🐚 platinum hermit Good normal PR; ordinary maintainer review
3/6 C 🦐 gold shrimp Useful, but confidence is limited
2/6 D 🦪 silver shellfish Proof or implementation needs work
1/6 F 🧂 unranked krab Not merge-ready
N/A NA 🌊 off-meta tidepool Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

  • 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.

History

Review history (16 earlier review cycles; latest 8 shown)
  • reviewed 2026-08-02T10:22:02.478Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-02T11:55:19.262Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-02T15:25:59.910Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-02T17:34:54.960Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-02T21:04:54.114Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-03T01:07:46.980Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-03T02:51:22.058Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module
  • reviewed 2026-08-03T06:41:22.105Z sha 69926bd :: needs real behavior proof before merge. :: [P1] Port the checkout gate to the active metadata module

@clawsweeper clawsweeper Bot added proof: sufficient Contributor real behavior proof is sufficient. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. proof: sufficient Contributor real behavior proof is sufficient. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels Jul 31, 2026
@clawsweeper clawsweeper Bot added the rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. label Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 automation 🚨 Merging this PR could break CI, automerge, proof capture, label sync, or automation. P1 Urgent regression or broken agent/channel workflow affecting real users now. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant