fix: reduce redundant apply continuation runs

[brokemac79]

What Problem This Solves

Default cursor-based apply runs can queue redundant continuations while another default apply run for the same repository is already active. That adds Actions noise and competes with useful apply-health signals. A custom or exact-item apply run must not suppress the default cursor lane because it does not advance the same work.

Why This Change Was Made

This PR makes continuation ownership explicit:

• Default and custom apply runs now have distinct, target-specific Actions titles.
• Only a live same-target default apply run can cover a default cursor continuation.
• Custom-input and exact-item continuations keep their exact dispatch inputs.
• The blocker lookup paginates active statuses, de-duplicates run IDs, ignores the current run, matches the stable workflow path, and ignores queued runs stale for more than six hours.
• Blocker selection moved from embedded workflow JavaScript into the tested repair workflow utility CLI.
• Workflow output parsing accepts only the three known continuation fields instead of sourcing a generated shell file.
• Scheduler documentation describes the two lanes and their continuation behavior.

User Impact

Maintainers get fewer redundant default apply runs and clearer run titles without delaying custom or exact-item work. If no matching live default run exists, the workflow keeps the existing continuation dispatch behavior.

Evidence

Maintainer proof at head c1150ec26b461907f7bc3d4a1443130b902bd22e:

node --test test/repair/workflow-utils.test.ts test/sweep-workflow.test.ts
# 67 passed, 0 failed

pnpm run build
pnpm run build:repair
pnpm run lint
pnpm exec oxfmt --check .github/workflows/sweep.yml docs/scheduler.md src/repair/workflow-utils.ts test/repair/workflow-utils.test.ts test/sweep-workflow.test.ts
git diff --check
# passed

pnpm run check
# passed: build, lint, 565 unit tests, 586 repair tests,
# changed/full coverage (1151 tests), and formatting

actionlint accepts the new continuation path and run-title expression. Its only findings are two pre-existing shellcheck warnings elsewhere in sweep.yml.

GitHub's workflow-runs API documents all queried active statuses (in_progress, queued, requested, waiting, and pending) and exposes path plus display_title: https://docs.github.com/en/rest/actions/workflow-runs#list-workflow-runs-for-a-repository. Live ClawSweeper run 28695873174 returned .github/workflows/sweep.yml as the path and a target-specific display title.

Fresh whole-branch autoreview returned no actionable findings and rated the patch correct at 0.86 confidence.

Exact-head hosted proof is green:

• CI (pnpm check and Windows launcher): https://github.com/openclaw/clawsweeper/actions/runs/28696138014
• CodeQL (Actions and JavaScript/TypeScript): https://github.com/openclaw/clawsweeper/actions/runs/28696138025

Live Validation Plan

After merge, observe the natural scheduled apply cadence rather than dispatching a destructive apply run manually. Verify target-specific default titles, continuation logs, and absence of overlapping same-target default continuations. Custom and exact-item behavior is covered deterministically by the focused tests.

Risk

Moderate workflow risk, bounded to continuation admission and run titles. On lookup or parse failure the continuation step fails visibly; it does not silently suppress work. No close, label, review, or repair policy changes are included.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 3, 2026, 9:23 PM ET / 01:23 UTC.

Summary
The PR adds target-specific apply/comment-sync run titles, skips default cursor apply continuation dispatch when an active same-target apply run is already present, and updates scheduler docs plus workflow assertions.

Reproducibility: no. high-confidence live reproduction was established because running apply continuations could mutate GitHub state. Source inspection shows current main queues a fresh apply workflow whenever APPLY_CONTINUE is true, while this PR adds a same-target active-run sharing guard.

Review metrics: 2 noteworthy metrics.

• Changed Surface: 3 files changed, +103/-1. The diff is now narrow after the merged fix: surface apply health on dashboard #391 prerequisite, which makes review focus mostly on workflow dispatch behavior.
• Workflow Surface: 1 workflow changed. The PR changes live apply continuation dispatch, which unit tests do not fully prove in production.

Root-cause cluster
Relationship: canonical
Canonical: #400
Summary: This PR is the active continuation-noise cleanup; the related items are merged prerequisite or adjacent scheduler/apply automation work rather than replacements.

Members:

• partial_overlap: fix: surface apply health on dashboard #391 - Merged apply-health/dashboard prerequisite now in main; it overlaps the automation area but does not implement default cursor continuation sharing.
• adjacent_distinct: fix(scheduler): count active runs by workflow path #393 - Merged workflow-path matching fix supplied the Actions API identity pattern reused here, but it addressed scheduler capacity accounting rather than apply continuation sharing.
• adjacent_distinct: fix: rotate apply queue batches #375 - Merged apply queue rotation created the cursor-window continuation context this PR refines, but it did not suppress redundant continuation runs.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted live Actions output, copied runtime output, a linked artifact, or a maintainer proof override for the default cursor continuation guard.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body shows tests, local output, a stubbed guard harness, and read-only API contract proof, but not after-fix live continuation behavior or a maintainer override; contributors should redact private details and update the PR body so ClawSweeper re-reviews automatically, or ask for @clawsweeper re-review if it does not.

Risk before merge

• [P1] The continuation guard changes live GitHub Actions dispatch behavior; local tests and a stubbed harness do not prove the production same-target suppression path after merge.
• [P1] The blocker identity is workflow path plus display title, so maintainers should explicitly accept that another same-target apply run with different inputs could delay default cursor continuation until the scheduled cadence catches up.

Maintainer options:

1. Require Production Proof Or Override (recommended)
   Before merge, obtain redacted Actions log output, copied runtime output, a linked artifact, or explicit maintainer override showing a default cursor apply continuation is safely covered by an active same-target run.
2. Narrow The Blocker Identity
   If maintainers want stronger safety, revise the run title or predicate so explicit and non-default apply runs cannot satisfy the default cursor blocker.
3. Accept Scheduled Fallback Risk
   Maintainers can intentionally merge with local and stubbed proof only, relying on the scheduled apply cadence if the live sharing predicate is too broad.

Next step before merge

• [P1] Human follow-up is needed for live proof or maintainer override of the automation behavior; there is no narrow code repair to queue from this review.

Security
Cleared: No concrete security or supply-chain concern was found; the diff does not add dependencies, action refs, permissions, or secret-handling paths.

Review details

Best possible solution:

Merge the narrow continuation guard only after redacted live Actions/runtime proof or an explicit maintainer override confirms default cursor sharing works while explicit and non-default apply dispatches remain exact.

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

No high-confidence live reproduction was established because running apply continuations could mutate GitHub state. Source inspection shows current main queues a fresh apply workflow whenever APPLY_CONTINUE is true, while this PR adds a same-target active-run sharing guard.

Is this the best way to solve the issue?

Yes, the implementation direction is narrow and keeps explicit/non-default continuations dispatching with their exact inputs. It still needs live proof or maintainer override because the active-run predicate controls production Actions dispatch.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: This is a normal-priority ClawSweeper automation improvement with limited blast radius but meaningful workflow-review requirements.
• merge-risk: 🚨 automation: The diff changes GitHub Actions run titles and default apply continuation dispatch suppression, so a live mismatch could affect automation behavior after merge.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body shows tests, local output, a stubbed guard harness, and read-only API contract proof, but not after-fix live continuation behavior or a maintainer override; contributors should redact private details and update the PR body so ClawSweeper re-reviews automatically, or ask for @clawsweeper re-review if it does not.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its automation-safety guidance is relevant because this PR changes sweep workflow behavior. (AGENTS.md:1, ead7d6461a6c)
• Current main still queues continuations directly: Current main's Continue apply sweep step queues another sweep workflow whenever APPLY_CONTINUE is true, without checking active same-target apply runs first. (.github/workflows/sweep.yml:2654, ead7d6461a6c)
• Proposed default-only sharing predicate: The PR only attempts sharing when the current continuation is an auto-selected batch with empty item numbers and default apply inputs. (.github/workflows/sweep.yml:2672, 98294247b885)
• Proposed active-run identity: The blocker lookup de-duplicates active Actions runs, ignores the current run, and matches by .github/workflows/sweep.yml plus the target-specific display title. (.github/workflows/sweep.yml:2690, 98294247b885)
• Explicit dispatch path remains: When no blocker is found, the PR still dispatches sweep.yml with the existing apply inputs, including apply_item_numbers and non-default values. (.github/workflows/sweep.yml:2739, 98294247b885)
• Regression assertions added: The proposed workflow test asserts target-specific titles, workflow-path matching, de-duplication, current-run exclusion, and explicit-input preservation around the continuation guard. (test/sweep-workflow.test.ts:139, 98294247b885)

Likely related people:

• steipete: Authored the merged workflow-path active-run matching fix in fix(scheduler): count active runs by workflow path #393, which is the identity pattern reused by this PR. (role: recent scheduler contributor; confidence: high; commits: 1343d8ec0cef; files: .github/workflows/sweep.yml, test/sweep-workflow.test.ts)
• brokemac79: Authored merged apply queue rotation and apply-health work that created the cursor-window and status context refined here. (role: recent apply automation contributor; confidence: high; commits: 5bdf6f31c904, ead7d6461a6c; files: .github/workflows/sweep.yml, docs/scheduler.md, src/clawsweeper.ts)
• Vincent Koc: Blame and history show prior work on the fresh-token apply checkpoint continuation path that this PR gates more narrowly. (role: adjacent continuation contributor; confidence: medium; commits: f94588d89c2f, bff8bf992f29; files: .github/workflows/sweep.yml)
• Dallin Romney: Blame ties the surrounding sweep workflow test scaffold to this author, including the test this PR extends. (role: workflow test scaffold contributor; confidence: medium; commits: f337079999cc; files: test/sweep-workflow.test.ts)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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.

[brokemac79]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[brokemac79]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[steipete]

Land-ready at exact head c1150ec26b461907f7bc3d4a1443130b902bd22e.

Maintainer fixups on top of the contributor work:

• separated default and custom apply run titles so targeted/manual work cannot suppress the default cursor lane;
• moved blocker selection into the tested workflow utility CLI;
• matched only same-target default runs on the stable workflow path;
• ignored current, completed, duplicate, and stale queued runs;
• parsed only the three known CLI output fields rather than sourcing generated shell;
• updated focused tests and scheduler docs.

Local proof:

pnpm run check
# green: build, lint, 565 unit tests, 586 repair tests,
# changed/full coverage (1151 tests), repository-wide format

pnpm run build:repair
pnpm run lint:repair
node --test test/repair/workflow-utils.test.ts test/sweep-workflow.test.ts
# 67 passed, 0 failed

pnpm exec oxfmt --check .github/workflows/sweep.yml docs/scheduler.md src/repair/workflow-utils.ts test/repair/workflow-utils.test.ts test/sweep-workflow.test.ts
git diff --check
# green

Fresh whole-branch autoreview: no actionable findings; patch correct at 0.86 confidence.

Hosted exact-head proof:

• CI (pnpm check and Windows launcher): https://github.com/openclaw/clawsweeper/actions/runs/28696138014
• CodeQL (Actions and JavaScript/TypeScript): https://github.com/openclaw/clawsweeper/actions/runs/28696138025

GitHub's documented workflow-run status filters and a live ClawSweeper API response confirm the queried active statuses plus .github/workflows/sweep.yml path and target-specific display_title contract.

Known proof gap: the natural scheduled cadence must run from main before the new titles and same-target default suppression can be observed in production. I will monitor that after merge; no destructive apply run was dispatched for proof.