OpenClaw
OpenClaw proposes recoverable bulk Workboard actions without starting agent sessions
OpenClaw's Workboard stack adds guarded bulk edits, partial-result feedback and retryable remaining work. Related layers simplify list rows and preserve failed editor drafts; selection and editing explicitly do not launch sessions, keeping board management separate from agent execution.
OpenClaw's eight-part Workboard proposal is being reviewed as a product-control surface, not just a denser task list. Its final layer, opened September 11 and updated September 12, adds recoverable bulk property and lifecycle actions. The subtle problem is that deleting one linked card can change the revisions of other selected cards through reference cleanup, making the batch conflict with itself. The proposed solution accepts only verified receipts from its own successful cleanup while preserving conflict protection against unrelated writers. The inspected layers remain open, and their source notes explicitly say fresh visual stress captures are still missing.
The facts
- The bulk-action layer is number eight in a stack split from an earlier Workboard proposal and depends on the preceding details layer. - Selection is revalidated against the active board and agent scope, and write availability is checked separately for each item. - Partial batch success leaves remaining work available for a direct retry instead of forcing the operator to rebuild the selection. - Linked deletion accepts revision changes only when verified as cleanup from the same batch's successful delete, not arbitrary concurrent edits. - A related list layer orders rows by Priority, Title, Session and Updated, with counters below titles and full-width group disclosure. - The editor layer preserves failed drafts and defines explicit appearance-clearing fields; selection and editing do not themselves start sessions.
Why it matters
As agent systems acquire shared workspaces, their boards become places where people exercise authority over many related objects at once. A polished bulk-edit button is dangerous if success, partial success and conflict are indistinguishable. This stack's useful direction is recoverability: people can see what remains, retry it and avoid turning a management action into an execution request. That is distinct from claiming the underlying agents now collaborate better or complete more work.
Current
Inspected on 2026-09-13. The OpenClaw release baseline is 2026.9.4 on npm latest; extended-stable 2026.6.35. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.
Evidence
Primary evidence: openclaw/openclaw PR #144756 (https://github.com/openclaw/openclaw/pull/144756). Supporting context: openclaw/openclaw PR #144753 (https://github.com/openclaw/openclaw/pull/144753); openclaw/openclaw PR #144754 (https://github.com/openclaw/openclaw/pull/144754). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.
Operator take
Review mixed outcomes first: one successful edit, one unrelated concurrent change, a linked deletion that updates another selected card and an item that leaves the active scope. Require gateway, store and client to agree on the receipt format before treating retries as safe. Separately inspect narrow layouts, long titles and IME entry in a real browser; the source reports focused tests and builds but deliberately withholds fresh visual-pass claims where browser access was unavailable.
Caveat
Open, dependent Workboard layers rather than shipped package behavior. The authors report staged and focused test results across several revisions, not a full-suite rerun at every final commit. Fresh persistent-browser stress screenshots are explicitly outstanding, and the matching gateway/store/client receipt contract must ship together.
Open, dependent Workboard layers rather than shipped package behavior. The authors report staged and focused test results across several revisions, not a full-suite rerun at every final commit. Fresh persistent-browser stress screenshots are explicitly outstanding, and the matching gateway/store/client receipt contract must ship together.