fix: surface apply health on dashboard

[brokemac79]

What Problem This Solves

ClawSweeper now rotates apply batches after #375, but operators still had weak visibility into whether apply was actually progressing or silently stuck on skip-heavy/blocked windows. The live dashboard showed broad fleet health, but not a focused signal for apply lanes that hit the 300-record window, failed live fetches, exhausted runtime budget, or otherwise made no useful pruning progress.

Why This Change Was Made

• Adds a deterministic summarize-apply-report workflow utility that turns apply reports into compact health JSON with processed counts, close/comment-sync counts, skip buckets, cursor state, and low-noise attention reasons.
• Publishes apply-health JSON from apply checkpoints and final apply status updates, using pnpm run --silent workflow -- so captured files remain valid JSON.
• Preserves apply-health through non-apply status updates, preserves it through direct throttle heartbeats, and clears stale health when a fresh Apply ... status has no health payload.
• Adds a problem-focused dashboard alert sourced from openclaw/clawsweeper-state sweep-status files without scanning the open issue/PR universe.
• Renames the alert from the vague apply-health wording to maintainer-facing pruning status, adds hover guidance for the actual blocker buckets, and shows a safe next action for maintainers.
• Keeps healthy/idle apply health quiet in the UI so the dashboard only gets louder when there is something operators need to inspect.

User Impact

Maintainers get a visible, targeted alert when pruning progress is blocked or degraded, while normal/idle apply runs remain silent. The alert now says what is blocked, why it matters, and what a maintainer should inspect or run next without turning the dashboard into a noisy metrics dump.

Evidence

• git diff --check passed.
• node --test test\dashboard-worker.test.ts passed: 51 passed, 0 failed.
• pnpm run codex:local:check passed after the Codex account reset: local Codex binary found and the gpt-5.5 smoke test passed.
• PNPM_BIN=$env:LOCALAPPDATA\Corepack\shims\pnpm.CMD; pnpm run check passed on Windows: 1134 passed, 1 skipped, coverage lane 100%, format:check all matched files.
• Direct JSON capture proof for the reviewed failure mode passed: pnpm run --silent workflow -- summarize-apply-report ... > health.json, then ConvertFrom-Json parsed status=ok, processed=1, closed=1.
• Visual dashboard proof used the real dashboard/worker.ts HTML with only /api/status stubbed: cursor-missing health renders a Pruning sweep blocked alert with reason tooltips and a maintainer action to inspect cursor/state publishing; ok health renders zero alerts and leaves #apply-health empty.
• Codex review: codex.cmd -c service_tier='"fast"' review --uncommitted completed with no actionable correctness issues after addressing accepted review findings for silent JSON capture, heartbeat preservation, stale apply-health clearing, cursor-missing guidance, and duplicated skip-count preservation.

Screenshot Proof

Problem-focused pruning alert with maintainer action:

Healthy/idle pruning health stays quiet:

Maintainer Rewrite And Live Proof

The contributor design was retained, then rebased onto the current scheduler/apply baseline and repaired across the full apply-result state model.

• A full cursor-backed close window now requires its cursor even when one or more closes succeeded.
• Scheduled cursor-backed comment sync uses its own batch threshold and cursor; explicit non-cursor lanes no longer produce false cursor alerts.
• Apply health treats closes, durable comment updates, and successful label sync as progress. All other blocked or nonproductive outcomes request attention unless the whole window contains only terminal benign skips such as already-closed or not-open items.
• Blocked closes that still updated the durable review comment preserve that observable progress without hiding the blocked close.
• The dashboard only renders a cursor pill when that lane actually requires or publishes a cursor.

Exact reviewed head: b42a805d7c7e312863ac37089309537380b832c2, rebased onto 1343d8ec0cef4a5088be01084937fe4396cf9571.

Maintainer proof:

• Focused apply-health and dashboard tests: 112 passed.
• Unit tests: 561 passed. Repair tests: 580 passed.
• Changed coverage: 100% lines/functions and 89.17% branches.
• Full coverage: 1,141 passed. Formatting: 289 files checked.
• Structured AutoReview: clean, with no accepted or actionable findings.
• Production Worker deployment and smoke test: https://github.com/openclaw/clawsweeper/actions/runs/28690094533
• Live custom-domain and workers.dev validation both rendered fresh nonzero fleet telemetry, preserved the 128-worker budget, refreshed as activity changed, and emitted no browser console errors. Current production apply health is quiet, so no alert is expected; no real apply failure was manufactured for proof.
• The release-owned changelog now credits @brokemac79 for the user-visible telemetry and alert.

[clawsweeper]

Codex review: needs changes before merge. Reviewed July 3, 2026, 9:05 PM ET / 01:05 UTC.

Summary
The branch adds apply-health report summarization, sweep-status persistence, apply workflow publishing, a quiet dashboard pruning alert, docs, proof images, tests, and a CHANGELOG entry.

Reproducibility: not applicable. as a feature/operations PR. The branch demonstrates the changed behavior with direct JSON proof, inspected dashboard screenshots, and a successful production Worker smoke run; the only source-level concern is visible in CHANGELOG.md.

Review metrics: 3 noteworthy metrics.

• Changed surface: 12 files, +1025/-7. The PR spans workflow, CLI utility, dashboard, docs, images, and tests, so maintainers should review it as an automation surface change.
• Workflow surface: 1 workflow changed. The modified sweep workflow publishes apply-health JSON during live apply checkpoints and final status updates.
• Release-owned file: 1 CHANGELOG.md line added. Repository policy keeps CHANGELOG.md release-owned during normal PR work.

Root-cause cluster
Relationship: canonical
Canonical: #391
Summary: This PR is the base apply-health dashboard/status change; the other open related PRs are stacked follow-ups that depend on it rather than replacements.

Members:

• adjacent_distinct: fix: rotate apply queue batches #375 - This merged predecessor added apply queue rotation and cursor persistence that the current apply-health telemetry observes.
• adjacent_distinct: feat: classify apply skip next actions #395 - This open follow-up adds next-action classification on top of this PR's apply-health summary surface.
• adjacent_distinct: feat: split apply health lane reporting #397 - This open follow-up splits lane reporting and explicitly depends on this PR landing first.
• adjacent_distinct: feat: report apply cycle estimates #398 - This open follow-up adds cycle estimates to the apply-health surface introduced here.
• adjacent_distinct: fix: reduce redundant apply continuation runs #400 - This open follow-up reduces continuation noise and references this PR as the stacked base.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

• Remove the added CHANGELOG.md entry and keep the release-note context in the PR body or commit message.
• [P2] Let the current CI and CodeQL checks finish before merge.

Risk before merge

• [P1] This changes live sweep.yml apply status publication; a summarizer or status write failure could leave apply telemetry stale or interrupt status/continuation visibility after apply has already processed records.
• [P1] The branch currently includes a release-owned CHANGELOG.md entry that should be removed before normal merge automation.

Maintainer options:

1. Remove release-owned changelog before merge (recommended)
   Drop only the added CHANGELOG.md line and leave the already-present release-note context in the PR body or commit message.
2. Accept the telemetry workflow risk
   After the changelog cleanup and required checks, maintainers can intentionally accept that apply status publication now depends on the new summarizer/dashboard health path.
3. Pause if live apply reporting is not ready
   If maintainers are not ready to add health publication to live apply runs, hold this base PR and keep the stacked follow-ups dependent on the settled telemetry direction.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Remove only the added CHANGELOG.md apply-health entry from this PR because CHANGELOG.md is release-owned. Preserve release-note context in the PR body or commit message, and do not change the apply-health implementation, proof images, docs, workflow logic, or tests.

Next step before merge

• [P2] A narrow automated repair can remove the release-owned CHANGELOG.md line; maintainers still need to accept the live apply telemetry risk after that cleanup.

Security
Cleared: No concrete security or supply-chain regression was found; the PR adds no dependencies or secret/permission broadening, and dashboard command text is rendered escaped rather than executed.

Review findings

• [P3] Remove the release-owned changelog entry — CHANGELOG.md:12

Review details

Best possible solution:

Remove the CHANGELOG.md entry, keep release-note context in the PR body or commit message, then merge if maintainers accept the apply telemetry workflow risk after required checks finish.

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

Not applicable as a feature/operations PR. The branch demonstrates the changed behavior with direct JSON proof, inspected dashboard screenshots, and a successful production Worker smoke run; the only source-level concern is visible in CHANGELOG.md.

Is this the best way to solve the issue?

Mostly yes. Using sweep-status apply_health and a quiet dashboard alert is a narrow, maintainable solution for operator visibility, but the release-owned changelog edit should be removed before merge.

Full review comments:

• [P3] Remove the release-owned changelog entry — CHANGELOG.md:12
  AGENTS.md marks OpenClaw CHANGELOG.md as release-owned and says normal PR work should preserve release-note context in PR bodies and commits instead. This PR body already contains that context, so this added line should be dropped before merge.
  Confidence: 0.92

Overall correctness: patch is correct
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• remove proof: 📸 screenshot: Current real behavior proof evidence kind is linked_artifact.

Label justifications:

• P2: This is a normal-priority operations/dashboard improvement with limited user blast radius but meaningful maintainer automation impact.
• merge-risk: 🚨 automation: The diff changes sweep workflow status publication, apply report summarization, and dashboard status ingestion, so a merge could affect automation visibility or apply-lane status updates.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (linked_artifact): The PR body includes after-fix terminal/check output, direct JSON capture proof, inspected screenshots for blocked and quiet dashboard states, and a successful linked production Worker smoke run.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal/check output, direct JSON capture proof, inspected screenshots for blocked and quiet dashboard states, and a successful linked production Worker smoke run.

Evidence reviewed

Acceptance criteria:

• [P1] git diff --check.
• [P1] pnpm run format:check -- CHANGELOG.md.

What I checked:

• Repository policy applied: AGENTS.md marks CHANGELOG.md as release-owned and says normal PR work should preserve release-note context in PR bodies and commit messages instead. (AGENTS.md:41, 1343d8ec0cef)
• Current main lacks the requested surface: Current main has no applyHealth/apply_health/summarize-apply-report/renderApplyHealth matches in the searched source, workflow, docs, tests, or changelog, so this PR still contains unique work not implemented on main or the latest release. (1343d8ec0cef)
• Workflow publication path: The PR head adds write_apply_health and passes generated apply-health JSON into checkpoint and final Apply status updates. (.github/workflows/sweep.yml:2329, b42a805d7c7e)
• Apply-health summarizer: The branch summarizes apply reports into processed, closed, comment-sync, skip, attention, and cursor fields and flags missing cursors or all-blocked windows. (src/repair/workflow-utils.ts:282, b42a805d7c7e)
• Status persistence and stale clearing: The status command accepts apply-health JSON, clears stale health for fresh Apply states without payloads, and otherwise preserves existing health through non-apply status writes. (src/clawsweeper.ts:20404, b42a805d7c7e)
• Dashboard status and rendering: The dashboard reads apply_health from state-repo sweep-status files, exposes attention counts, and renders the alert only for attention statuses. (dashboard/worker.ts:3539, b42a805d7c7e)

Likely related people:

• steipete: Peter Steinberger authored the current main scheduler path fix and most later commits on this branch, including cursor telemetry corrections and the latest changelog commit. (role: recent area contributor and branch rewriter; confidence: high; commits: 1343d8ec0cef, 267f98d19728, b42a805d7c7e; files: .github/workflows/sweep.yml, dashboard/worker.ts, src/repair/workflow-utils.ts)
• brokemac79: The behavior builds directly on brokemac79's merged apply queue rotation work in fix: rotate apply queue batches #375 and their first three commits on this branch. (role: apply cursor feature contributor; confidence: high; commits: 5bdf6f31c904, 867131b51d5d, 26573326ee5e; files: .github/workflows/sweep.yml, src/repair/workflow-utils.ts, dashboard/worker.ts)
• Dallin Romney: Blame on the central apply workflow block points much of the existing scaffold to commit a811372. (role: original workflow/apply surface contributor; confidence: medium; commits: a811372b8fd0; files: .github/workflows/sweep.yml, src/repair/workflow-utils.ts, CHANGELOG.md)
• Vincent Koc: Recent main history includes apply checkpoint/token work in the same live apply lane that this PR now reports through dashboard health. (role: adjacent apply workflow contributor; confidence: medium; commits: f94588d89c2f; files: .github/workflows/sweep.yml, CHANGELOG.md)

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.