feat(dashboard): split OpenClaw Bay publishing lane

[brokemac79]

Summary

• Align OpenClaw Bay with the current exact-review journey: Arriving -> Setting up -> Reviewing -> Publishing -> Applying -> Completed. Repair Cove remains the exception path.
• Recognise both older per-item publishers and the current durable batch publisher without counting publisher jobs as Codex capacity.
• Add compact State writer telemetry alongside review admission, result publication, and handoff health, using the dashboard's existing cached data.
• Update the Bay projection for the latest recovery controls: items deliberately parked after a permanent dispatch rejection, bounded review-retry exhaustion, or publication dead-letter capacity now appear in Repair Cove, rather than looking like normal setup/publishing work.

Current-main alignment

This branch was rebased onto current main at 3cb93c6a16bf1209835942083ae9dd0ee8753184 after the recent exact-review and publication recovery fixes (#827, #836-#839).

• The fresh-authority publication path remains Publishing while a durable result waits to be delivered.
• A live publisher batch becomes Applying only while its bounded durable membership is under active ownership and the publisher is doing deterministic close/routing/final-confirmation work.
• Review retries now have an eight-attempt ceiling and permanent per-item dispatch failures park rather than looping forever. Bay exposes these bounded recovery items in Repair Cove.
• A global dispatcher outage remains in the normal admission path; its blocked/backoff state stays visible in the Overview telemetry rather than being misrepresented as an item-specific repair.

Implementation

• Detect the dedicated batch publisher from immutable workflow metadata and canonical steps, including while queued before GitHub supplies step history.
• Use the durable batch's known item keys to render real batch-owned items in Applying; a targetless GitHub batch job never invents an item identity.
• Keep publisher jobs in the active-worker feed but out of the Overview hero and Codex-capacity counts.
• Keep older five-stage queue snapshots compatible by normalising their former applying records into Publishing. This avoids duplicate Applying cards during a rolling deploy.
• Add State writer freshness/status copy for current data, stale history, and failed collection.
• Stack the six-stage layout safely at constrained landscape widths and keep the control board one-column on phones.

Data and API boundary

Bay reuses the dashboard's existing /api/status, cached /api/health-history, and durable exact-review queue state. It adds no direct GitHub API calls, repository scans, polling loop, or mutation. The browser proof recorded 0 direct GitHub API requests and 0 mutation requests.

Validation

• node --test --test-concurrency=1 test/dashboard-worker.test.ts - 190 passed.
• pnpm run build:dashboard
• pnpm run lint:dashboard
• pnpm run lint:scripts
• node --check docs/proof/openclaw-bay/run-proof.mjs
• git diff --check
• Local Docker-backed Crabbox browser proof (cbx_6023bb65dc75, mcr.microsoft.com/playwright:v1.60.0-noble) - 48 assertions, 23 evidence frames, real local /bay-demo rendering and artwork; it covered the six-stage layout, Publishing/Applying projection, Repair Cove state, State writer card, range controls, portrait/constrained layouts, and tide behaviour.
• The proof replaces only /api/status and /api/health-history with checked-in redacted fixtures. It is browser evidence for the page, not a claim of live production queue data.

Review closeout

• Dirty-patch Codex review: codex review --uncommitted - clean; no accepted/actionable findings.
• Branch Codex review: codex review --base origin/main - clean; no actionable correctness issues.
• Local read-only ClawSweeper range review: pnpm run review -- --local-range --target-repo openclaw/clawsweeper --base origin/main - keep_open / medium confidence, no correctness or security finding; reviewed main 3cb93c6a16bf1209835942083ae9dd0ee8753184 through head 0d24884fe8bc6b7fb46f114530d3acc7074f50f4. No GitHub comment, label, merge, or hosted workflow was triggered.

Risks / rollout

• Publisher classification intentionally relies on canonical workflow metadata and immutable batch steps. Focused tests cover queued/active batch work and parked recovery work.
• Bay is deliberately bounded: it exposes a scrubbed public queue sample and accurate aggregate counts, not a broad GitHub inspection surface.
• The current local browser proof is deterministic and privacy-safe. A normal hosted workflow naturally exercising all publisher variants remains useful operational follow-up evidence, but is not manufactured by this PR.

User-facing note

OpenClaw Bay separates the result-publication queue from deterministic follow-up and makes bounded recovery visible without making the dashboard heavier on the GitHub API.

[brokemac79]

@clawsweeper 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: Review in progress
• Detail: The exact-review queue leased this run; Codex is reviewing the item.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29799686347
• Updated: 2026-07-21T03:53:13.502Z

[clawsweeper]

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

Summary
The PR separates OpenClaw Bay’s combined Applying stage into Publishing for queued exact-review artifact publication and Applying for deterministic post-publication follow-up work.

Reproducibility: not applicable. This PR refines the visual representation of existing dashboard workflow states rather than fixing a reported failing behavior.

Review metrics: 2 noteworthy metrics.

• Patch scope: 6 files affected; 180 additions, 34 deletions. The change is focused on dashboard rendering, queue projection, worker classification, proof fixtures, and focused tests.
• Validation surface: 8 reported successful GitHub checks; 156 focused tests reported. The branch has broad automated validation for a small operational-dashboard behavior change.

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:

• Attach a redacted screenshot, short recording, terminal transcript, or linked artifact showing all six Bay lanes and the non-duplicated Publishing/Applying counts.
• After adding proof, update the PR body to trigger a fresh review; if that does not occur, ask a maintainer to comment @clawsweeper re-review.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR describes an after-fix local browser run, but it provides no inspectable visual, terminal, log, live-output, or linked-artifact evidence that directly demonstrates the Publishing/Applying split and non-duplicated counts. 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.

Risk before merge

• [P1] The PR body describes successful local browser behavior, but no inspectable artifact shows the rendered lane order and absence of duplicate queued counts; this leaves the user-visible dashboard result unverified before merge.

Maintainer options:

1. Decide the mitigation before merge
   Retain the narrow publishing/applying split, preserve the legacy-projection fallback during rollout, and attach redacted after-fix browser or terminal evidence showing all six lane headers plus Publishing and Applying counts without duplication.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] No automated repair is appropriate because the remaining merge gate is contributor-supplied real-behavior proof, not a concrete code or test defect.

Security
Cleared: The supplied diff changes dashboard projection/rendering logic, deterministic proof fixtures, and tests; it shows no dependency, workflow-permission, secret-handling, or supply-chain change.

Review details

Best possible solution:

Retain the narrow publishing/applying split, preserve the legacy-projection fallback during rollout, and attach redacted after-fix browser or terminal evidence showing all six lane headers plus Publishing and Applying counts without duplication.

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

Not applicable: this PR refines the visual representation of existing dashboard workflow states rather than fixing a reported failing behavior.

Is this the best way to solve the issue?

Yes, conditionally. Separating the durable publication queue from live deterministic follow-up work is a narrow model change, but the rendered result still needs inspectable after-fix proof before merge.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P3: This is a low-risk dashboard workflow-clarity improvement rather than a user-facing outage or broken core runtime.
• 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 describes an after-fix local browser run, but it provides no inspectable visual, terminal, log, live-output, or linked-artifact evidence that directly demonstrates the Publishing/Applying split and non-duplicated counts. 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

What I checked:

• Queue projection change: The branch adds a distinct publishing Bay stage and routes publication-state exact-review queue items to it instead of applying. (dashboard/exact-review-queue.ts:4194, 1719660ea590)
• Capacity accounting boundary: The active-worker snapshot includes dashboard worker jobs in the detail feed while retaining a separate Codex-worker count, matching the stated intent not to count publisher jobs against Codex capacity. (dashboard/worker.ts:2935, 1719660ea590)
• Regression coverage: The PR updates dashboard-worker coverage for the publishing projection, legacy Applying fallback, queued publisher classification, and capacity accounting. (test/dashboard-worker.test.ts:845, 1719660ea590)
• Submitted validation: The PR reports successful dashboard build, lint, focused worker tests (156 passing), and a local browser smoke run; GitHub context also reports all listed checks successful. (1719660ea590)

Likely related people:

• unknown: The supplied context identifies the affected dashboard files but does not provide prior current-main authorship, and the read-only local shell could not initialize to complete the required git-history pass. (role: dashboard-area history unavailable; confidence: low; files: dashboard/bay-page.ts, dashboard/exact-review-queue.ts, 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.

Review history (1 earlier review cycle)

• reviewed 2026-07-21T03:12:22.593Z sha 1719660 :: needs real behavior proof before merge. :: none

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: feat(dashboard): split OpenClaw Bay publishing lane This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.