feat: schedule observable cluster repair intake

[RomneyDa]

Summary

• Migrate the Clownfish-style cluster repair lane into ClawSweeper using gitcrawl/gitcrawl-store cluster data.
• Add repair-cluster-intake.yml, a scheduled intake that runs hourly, reads openclaw/gitcrawl-store, imports at most one eligible cluster by default, publishes generated jobs and the intake ledger through openclaw/clawsweeper-state, and dispatches through the one-worker cluster_repair lane.
• Gate only scheduled intake behind the repo variable CLAWSWEEPER_FEATURE_CLUSTER_REPAIR_ENABLED=1; direct/manual gitcrawl import and repair dispatch are not blocked by that variable, preserving compatibility for existing repair tooling.
• Put the scheduled gate on the intake job before App-token creation, checkout, setup, or dispatch, so default-off cron ticks skip before privileged setup.
• Add a responsive Cluster Intake dashboard section so maintainers can see the last processed gitcrawl-store marker, generated job count/path, recent intake workflow runs, and active cluster worker counts from /api/status.
• Keep cluster repair separate from the existing issue implementation solver: issue implementation handles individually triaged strict reproducible bugs, while cluster repair handles imported issue/PR clusters.
• Drip-feed imported gitcrawl cluster work by default: cluster import skips already-imported, security-sensitive, feature-request, and 75%+ closed clusters unless --skip-closed-percent is explicitly overridden.
• Preserve the existing repair/automerge/issue-implementation/low-signal cleanup 40%-of-workers.max capacity derivation; only imported gitcrawl cluster jobs use the new one-worker cluster_repair default lane.
• Prefer portable gitcrawl-store SQLite state before the legacy local gitcrawl DB.

Duplicate Protection

• openclaw/gitcrawl-store refreshes openclaw/openclaw every 15 minutes; this intake runs hourly.
• The workflow records a small processed-store marker in openclaw/clawsweeper-state at results/cluster-repair-intake/<repo>.json with the last portable DB SHA, generated count, run URL, and update time.
• That marker prevents delayed or repeated ClawSweeper ticks against the same store snapshot from re-processing the same snapshot. It is intentionally earlier than the existing worker duplicate checks, which only skip active runs for an already-created job path.
• The importer also skips already-imported cluster IDs and overlapping member refs, so the marker is a cadence/load guard rather than the only duplicate-safety mechanism.
• Manual dispatch can override the processed-store skip with force_store=true for debugging.

Maintainer Visibility

• The live dashboard now renders a Cluster Intake section below Active Pipeline on wide screens and at the bottom after recent activity on narrow screens.
• The section shows the marker status for each configured target repo, the gitcrawl-store short SHA, exported time, generated job count, generated job filename, marker run link, latest intake workflow runs, and current active intake/worker counts.
• Active cluster worker runs also continue to appear in the existing Active Pipeline list as repair work.

Enablement

To enable automatic cluster intake in a target repo, add the Actions repository variable CLAWSWEEPER_FEATURE_CLUSTER_REPAIR_ENABLED=1.

Live mutation still also requires the existing gates, mainly CLAWSWEEPER_ALLOW_EXECUTE=1 and CLAWSWEEPER_ALLOW_FIX_PR=1. Merge behavior remains separately gated by CLAWSWEEPER_ALLOW_MERGE=1 where applicable.

The optional CLAWSWEEPER_CLUSTER_REPAIR_IMPORT_LIMIT variable controls scheduled intake volume; default is 1 cluster per hourly run. Manual dispatch remains available for debugging and can be disabled per run with enabled=0.

Audit Notes

• Removed stale/self-contradicting docs that showed ordinary repair self-heal at the cluster one-worker limit; normal repair examples stay at the current 22-worker derived default and imported cluster examples use the 1-worker cluster default.
• Removed whitespace-only source churn from the PR diff. The remaining incidental source formatting in execute-fix-artifact.ts is required by oxfmt.
• scripts/check-limits.ts verifies both ordinary repair and imported-cluster examples, so the cluster docs check complements rather than replaces the normal repair docs check.
• README.md and docs/limits.md describe existing repair capacity as 40% of workers.max, not a fixed checked-in 22.
• Older or custom automation-limits configs that omit lanes.repair.cluster_max_live_runs now keep loading; cluster repair capacity defaults to 1 when that optional key is absent.

Verification

• pnpm run build:repair && node --test test/clawsweeper.test.ts
• pnpm run check
• pnpm run build:dashboard && node --test test/dashboard-worker.test.ts
• pnpm run check:limits

[clawsweeper]

Codex review: found issues before merge. Reviewed May 25, 2026, 10:40 PM ET / 02:40 UTC.

Summary
Adds a default-off hourly gitcrawl-store cluster repair intake workflow, one-worker imported cluster repair lane, state ledger publishing, dashboard telemetry, docs, and regression tests.

Reproducibility: not applicable. this is a new scheduled automation and dashboard feature, not a bug report with a failing current-main path.

Review metrics: 2 noteworthy metrics.

• Changed surface: 24 files, +992/-65. The PR spans workflow, repair dispatch, config limits, dashboard, docs, and tests, so maintainer review should cover the whole automation path.
• Workflow surface: 1 scheduled workflow added. The new workflow can publish state and dispatch repair work once the repo variable is enabled.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
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:

• Fix the dashboard cadence label from 30m to hourly or derive it from the cron.
• For extra confidence before enabling the schedule, link one controlled manual intake run that publishes the ledger and dispatches through the one-worker lane.

Risk before merge

• Merging adds a new scheduled workflow with actions/write and contents/write permissions; although default-off, enabling it can publish jobs/results to openclaw/clawsweeper-state and dispatch repair workers hourly.
• The new lanes.repair.cluster_max_live_runs config schema and imported-cluster lane cap can change custom/local automation configs or gitcrawl cluster dispatch throughput.
• The dashboard currently shows a 30m tick for an hourly cron, which can mislead operators watching cluster intake cadence.

Maintainer options:

1. Land default-off, enable later
   Maintainers can merge the workflow with the schedule gate off and enable CLAWSWEEPER_FEATURE_CLUSTER_REPAIR_ENABLED=1 only after a controlled manual run proves the state ledger and dispatch path.
2. Prove the live intake path first
   Ask for a linked manual repair-cluster-intake.yml run showing a ledger publish to state and a one-worker dispatch before enabling the schedule.
3. Pause if cluster policy is unsettled
   If maintainers are not ready to operate scheduled gitcrawl cluster repair, leave the PR open or pause it rather than merging dormant automation with unclear ownership.

Next step before merge
Maintainer review should decide whether to accept the new scheduled state-mutating lane and the operational proof level before merge.

Security
Cleared: No concrete security or supply-chain regression found; the new privileged workflow uses pinned actions and keeps scheduled runs gated before token creation.

Review findings

• [P3] Show the hourly intake cadence — dashboard/worker.ts:4171

Review details

Best possible solution:

Land the default-off intake only after maintainer acceptance of the live automation path and after the dashboard cadence text matches the hourly schedule.

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

Not applicable; this is a new scheduled automation and dashboard feature, not a bug report with a failing current-main path.

Is this the best way to solve the issue?

Mostly yes: it reuses the existing state repo, publish-main, and repair dispatch patterns while keeping scheduled intake default-off. The dashboard cadence label should be corrected so operators do not see conflicting timing.

Full review comments:

• [P3] Show the hourly intake cadence — dashboard/worker.ts:4171
  The new workflow runs at 8 * * * *, and the dashboard also renders that cron, but each marker row still displays 30m as the tick interval. That makes the cluster intake section report a cadence the workflow will not actually use; change this to hourly/60m or derive it from the cron constant.
  Confidence: 0.89

Overall correctness: patch is correct
Overall confidence: 0.82

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 3f970f0fb25e.

Label changes

Label changes:

• add P2: This is a normal-priority internal automation feature with meaningful review surface but default-off runtime blast radius.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The PR author is a repository member, so the external-contributor real behavior proof gate does not apply; the body lists verification commands but not a live intake run.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
• remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.
• remove P1: Current review triage priority is P2, so this older priority label is no longer current.

Label justifications:

• P2: This is a normal-priority internal automation feature with meaningful review surface but default-off runtime blast radius.
• merge-risk: 🚨 compatibility: The PR adds a required repair-lane config key and changes gitcrawl cluster jobs to use a separate one-worker dispatch lane.
• merge-risk: 🚨 automation: The PR adds an hourly state-publishing and repair-dispatch workflow whose live behavior is not fully settled by unit tests.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The PR author is a repository member, so the external-contributor real behavior proof gate does not apply; the body lists verification commands but not a live intake run.

Evidence reviewed

What I checked:

• Repository policy read: Read the full target AGENTS.md; its generated-state and conservative workflow guidance shaped the review. (AGENTS.md:1, 3f970f0fb25e)
• Scheduled gate and state publish wiring: The new intake job gates scheduled runs before privileged setup, then creates the state token, runs setup-state, records the ledger, and publishes jobs plus results/cluster-repair-intake. (.github/workflows/repair-cluster-intake.yml:65, 8bb44924bb4c)
• State repo publish path: Current publish-main publishes to the configured CLAWSWEEPER_STATE_DIR and defaults that publish root to the state branch, so the workflow's setup-state wiring is the right state-repo path. (src/repair/git-publish.ts:195, 3f970f0fb25e)
• Cluster lane capacity: Imported gitcrawl cluster jobs are detected from repair job frontmatter and routed to the new cluster_repair worker lane, whose default is capped from lanes.repair.cluster_max_live_runs. (src/repair/dispatch-jobs.ts:177, 8bb44924bb4c)
• Dashboard cadence mismatch: The dashboard renders the cluster intake schedule from the cron but still hardcodes the per-marker timebox as 30m even though the workflow cron is hourly. (dashboard/worker.ts:4171, 8bb44924bb4c)
• Feature history: Current repair intent, dispatch, state publishing, and dashboard foundations trace mainly to the initial repair-lane commit and recent workflow/dashboard maintenance commits. (src/repair/job-intent.ts:1, b08d09badf8b)

Likely related people:

• Tak Hoffman: Blame shows the current repair job intent, dispatch, state publishing, and dashboard baseline were introduced in the repair-lane foundation commit. (role: feature-history owner; confidence: high; commits: b08d09badf8b; files: src/repair/job-intent.ts, src/repair/dispatch-jobs.ts, src/repair/git-publish.ts)
• Peter Steinberger: Recent history shows workflow, setup-state, dashboard, and workflow-storm maintenance adjacent to the new scheduled automation path. (role: recent area contributor; confidence: medium; commits: 7b51459462f1, c028d7905c2a, 8482e5071867; files: .github/actions/setup-state/action.yml, .github/workflows/repair-cluster-worker.yml, dashboard/worker.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.

[clawsweeper]

ClawSweeper PR egg

✨ Hatched: 🥚 common Sunspot Proofling

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: stacks clean commits.
Image traits: location flaky test forest; accessory shell-shaped keyboard; palette plum, gold, and soft gray; mood focused; pose leaning over a miniature review desk; shell soft speckled shell; lighting soft studio lighting; background tiny shells and proof notes.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Sunspot Proofling in ClawSweeper.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

[RomneyDa]

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

Re-review progress:

• State: Superseded
• Detail: A newer re-review for this item started before this run finished, so GitHub cancelled this older run. Check the latest ClawSweeper run for the current result.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26421535037
• Updated: 2026-05-25T22:05:33.129Z

[RomneyDa]

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

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26423339220
• Updated: 2026-05-25T23:17:26.561Z

[RomneyDa]

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

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26423855642
• Updated: 2026-05-25T23:37:05.463Z

[RomneyDa]

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

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26424337232
• Updated: 2026-05-25T23:55:26.311Z

[RomneyDa]

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

Re-review progress:

• State: Failed
• Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26427228312
• Updated: 2026-05-26T01:39:09.341Z

[RomneyDa]

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

Re-review progress:

• State: Superseded
• Detail: A newer re-review for this item started before this run finished, so GitHub cancelled this older run. Check the latest ClawSweeper run for the current result.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26428200826
• Updated: 2026-05-26T02:10:38.717Z

[RomneyDa]

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

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26428547947
• Updated: 2026-05-26T02:29:37.607Z

[RomneyDa]

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

Re-review progress:

• State: Failed
• Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26429024664
• Updated: 2026-05-26T02:52:24.192Z

[RomneyDa]

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

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26429522157
• Updated: 2026-05-26T02:58:21.755Z