feat: report apply cycle estimates

[brokemac79]

What Problem This Solves

After #375, ClawSweeper rotates close-apply candidates, but maintainers still cannot quickly tell how long it may take to revisit the current apply-ready close queue. A cursor can be advancing correctly while the open issue/PR count still rises, and without a cycle estimate that looks too similar to being stuck.

Why This Change Was Made

• Adds a compact cycle object to apply-health JSON for scheduled close cursor windows.
• Records the current apply-ready close candidate count from the same selector used by the apply workflow.
• Estimates cycle windows from the actual number of records processed in the latest cursor advance, not the configured 300-record budget, so close-limited runs do not understate the cycle.
• Keeps comment-sync and explicit item runs separate by reporting basis: not_close_cursor instead of mixing them into close-cycle estimates.
• Preserves nullable/unknown cycle fields as null in the dashboard API instead of normalizing them to zero.
• Adds a quiet cycle ~... pill only on the existing problem-focused pruning alert when a scheduled close-cycle estimate exists.
• Rebased onto main after fix: surface apply health on dashboard #391, feat: split apply health lane reporting #397, and feat: classify apply skip next actions #395 merged, preserving lane-level health and skip next-action reporting alongside the cycle estimate.

User Impact

Maintainers get an operational estimate for the close-apply rotation without adding a noisy always-on dashboard metric. When pruning needs attention, the alert can show whether the current queue looks like a few cursor windows or many, while normal/healthy dashboard states remain quiet.

Evidence

Rebase proof on current main:

pnpm run build:all
node --test test\repair\workflow-utils.test.ts test\dashboard-worker.test.ts
pnpm run format:check

Result: passed. The focused test run reported 77 tests, all passing.

Codex review after rebase:

codex review -c service_tier='fast' --base origin/main

Result: no actionable correctness issues found. The review specifically checked that the cycle telemetry remains wired through the workflow, summary generation, dashboard API, and UI after merging the lane and skip-action changes.

Prior full local check before the rebase:

$env:PNPM_BIN='C:\Users\marti\AppData\Local\Corepack\shims\pnpm.cmd'
pnpm run check

Result: passed. The full check reported 1134 passing tests, 1 skipped, coverage lane 100%, and format clean. After the rebase, the focused proof above was rerun against the combined code.

Direct CLI proof used pnpm run --silent workflow -- summarize-apply-report ... with --candidate-count 1200 --scheduled-interval-minutes 15:

• Close-limited proof: 5 processed records produced window_size=5, estimated_full_cycle_windows=240, estimated_full_cycle_minutes=3600, label roughly 60h.
• Full-window proof: 300 processed records produced window_size=300, estimated_full_cycle_windows=4, estimated_full_cycle_minutes=60, label roughly 1h.

Screenshot Proof

No new dashboard card or warning state is added. The existing pruning alert is the visual surface; this PR only adds a small cycle ~... detail pill when that alert is already visible and a scheduled close-cycle estimate exists.

Risk Notes

• This does not loosen close/apply gates.
• This does not dispatch repair, review, close, or comment actions by itself.
• Estimates are based on the latest cursor advance and current apply-ready candidate count; immediate continuations can make wall-clock time shorter than the scheduled-cadence label.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 3, 2026, 11:22 PM ET / 03:22 UTC.

Summary
The PR adds scheduled close-cycle telemetry to apply-health generation, workflow wiring, dashboard API/UI rendering, docs, and focused tests.

Reproducibility: not applicable. this is a feature PR rather than a bug report. The changed behavior is source-reviewable and partially shown by PR-body CLI output, but dashboard proof remains incomplete.

Review metrics: 2 noteworthy metrics.

• Changed surface: 7 files: 1 workflow, 1 dashboard worker, 1 workflow utility, 1 docs page, 3 test files. This is live automation telemetry plus UI, not only local helper code.
• Cadence assumption: 15 minutes hard-coded for scheduled close-cycle estimates. Maintainers should confirm that the operator-facing minutes match the intended scheduled apply cadence.

Root-cause cluster
Relationship: canonical
Canonical: #398
Summary: This PR is the canonical open follow-up for scheduled apply close-cycle estimates; the related merged PRs are prerequisites or adjacent telemetry work, not replacements.

Members:

• partial_overlap: fix: surface apply health on dashboard #391 - Merged prerequisite that created the apply-health dashboard/status surface extended by this PR.
• partial_overlap: feat: split apply health lane reporting #397 - Merged lane-reporting follow-up that this PR preserves while adding cycle telemetry.
• partial_overlap: feat: classify apply skip next actions #395 - Merged next-action classification follow-up that shares the apply-health JSON/dashboard path.
• adjacent_distinct: fix: rotate apply queue batches #375 - Merged apply queue rotation created the need for a cycle estimate but did not implement this telemetry.

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

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof 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 after-fix proof from the latest head showing cycle JSON output and the dashboard alert cycle pill.
• Confirm the 15-minute scheduled cadence wording is intentional for operator-facing cycle estimates.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR has copied CLI proof, but needs latest-head after-fix proof that also shows the dashboard/status telemetry path; redact private details and update the PR body to trigger rereview or ask a maintainer to comment @clawsweeper re-review.

Mantis proof suggestion
A visual proof pass would materially help verify that the dashboard renders the cycle pill only on the intended pruning alert. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify a pruning alert with scheduled close-cycle health shows the cycle revisit pill and healthy health stays quiet.

Risk before merge

• [P1] The PR changes live sweep workflow status publishing, so incorrect arguments or counts could mislead maintainers about apply progress even if unit tests pass.
• [P1] The current proof is strongest for CLI summary output and does not yet show the dashboard alert rendering the new cycle pill at the latest head.
• [P1] The scheduled-time label assumes a 15-minute close-apply cadence; maintainers should confirm that is the intended operator-facing estimate for all scheduled close lanes.

Maintainer options:

1. Require latest-head telemetry proof (recommended)
   Ask for redacted terminal output or a screenshot/recording showing the latest head producing cycle JSON and rendering the dashboard cycle pill before merge.
2. Accept additive telemetry rollout risk
   Maintainers can merge with the current tests and CLI proof if they are comfortable validating the live dashboard/status path after deployment.

Next step before merge

• [P1] Needs human merge handling because proof for the live workflow/dashboard telemetry path is incomplete and there is no narrow automated code repair to request.

Security
Cleared: Security review cleared: the diff adds workflow/status/dashboard telemetry and tests/docs without new dependencies, permissions, secret handling, or third-party code execution.

Review details

Best possible solution:

Land the additive telemetry after maintainer acceptance and after-fix proof shows both the JSON cycle fields and the dashboard alert pill for a scheduled close cursor window.

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

Not applicable; this is a feature PR rather than a bug report. The changed behavior is source-reviewable and partially shown by PR-body CLI output, but dashboard proof remains incomplete.

Is this the best way to solve the issue?

Yes, subject to proof and maintainer acceptance. Reusing the existing proposed-item selector, cursor advance accounting, and apply-health marker is a narrow maintainable path, and current main has no duplicate supported cycle-estimate path.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: This is a normal operational telemetry improvement with limited blast radius but real workflow/dashboard impact.
• merge-risk: 🚨 automation: The diff changes the scheduled apply workflow, status JSON, and dashboard interpretation for live automation health.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• 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 has copied CLI proof, but needs latest-head after-fix proof that also shows the dashboard/status telemetry path; redact private details and update the PR body to trigger rereview or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: Read the full target AGENTS.md and applied the automation-safety guidance for workflow/dashboard changes. (AGENTS.md:1, baf9ddb48ab1)
• Current main lacks the requested telemetry: A current-main search found no apply cycle, apply-cursor-advance-count, proposed-item-count, apply_ready_count, or estimated_full_cycle implementation in the workflow, helper, dashboard, docs, or tests. (baf9ddb48ab1)
• Workflow diff wires cycle inputs: The PR adds apply-ready candidate count, scheduled interval, and cursor-advance count arguments when publishing apply health for scheduled close cursor runs. (.github/workflows/sweep.yml:2335, e0283a8657c1)
• Workflow utility diff computes cycle estimates: The PR adds a cycle summary with scheduled_close_cursor and non-estimable basis values, plus CLI helpers for proposed-item-count and apply-cursor-advance-count. (src/repair/workflow-utils.ts:88, e0283a8657c1)
• Dashboard diff exposes and renders cycle data: The PR parses the cycle object through the dashboard status endpoint and renders a revisit-window pill only for scheduled close cursor health. (dashboard/worker.ts:3702, e0283a8657c1)
• Proof state: The PR body includes copied CLI output for summarize-apply-report, but the current PR label and body do not show after-fix dashboard rendering of the new cycle pill at the latest head. (e0283a8657c1)

Likely related people:

• brokemac79: Current-main history shows this contributor introduced the apply queue rotation, apply-health dashboard/status layer, lane reporting, and skip next-action classification that this PR extends. (role: feature-history owner; confidence: high; commits: 5bdf6f31c904, ead7d6461a6c, 5f4af592da57; files: .github/workflows/sweep.yml, src/repair/workflow-utils.ts, dashboard/worker.ts)
• steipete: Blame ties earlier apply workflow scaffolding to this contributor, and the latest PR head includes a maintainer-authored test commit for the same telemetry wiring. (role: adjacent automation contributor; confidence: medium; commits: 39239e718f9d, e0283a8657c1; files: .github/workflows/sweep.yml, test/dashboard-worker.test.ts, test/repair/workflow-utils.test.ts)
• vincentkoc: Blame shows recent work in the apply checkpoint and processed-limit workflow path that this PR extends with cycle telemetry. (role: recent apply workflow contributor; confidence: medium; commits: f94588d89c2f; files: .github/workflows/sweep.yml)

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.

[steipete]

Land-ready proof for exact head e0283a8657c118f9b96855950bd6a280d29e096e:

• Rebased onto current main after feat: split apply health lane reporting #397 and feat: classify apply skip next actions #395.
• Corrected the estimate to use actual cursor advance through the selected batch, not report-action count. This covers duplicate actions for one record and empty-result batches that still advance.
• Changed the visible detail to revisit ~N windows; cadence time is tooltip context and explicitly notes that immediate continuations can be faster.
• Local: pnpm run build:all passed.
• Local: node --test test/repair/workflow-utils.test.ts test/dashboard-worker.test.ts test/sweep-workflow.test.ts passed, 115/115.
• Whole-branch Codex autoreview against origin/main: no actionable findings, confidence 0.85.
• Exact-head CI: pnpm check and Windows Codex launcher passed in run https://github.com/openclaw/clawsweeper/actions/runs/28693255578.
• Exact-head CodeQL passed in run https://github.com/openclaw/clawsweeper/actions/runs/28693255588.

Known proof gap: the alert-only dashboard pill still needs a post-deploy live visual check. Parser, render, workflow wiring, and cursor behavior are covered before merge; I will verify the deployed system after landing.