feat(ui): session board grid engine and board view

[steipete]

What Problem This Solves

First UI piece of the session-dashboard program (design: docs/web/dashboard-architecture.md): the board rendering core. Sessions are getting a second "board" face where agents pin live widgets; this PR delivers the fluid grid engine and the <openclaw-board-view> element that later PRs (chat dock/face host, gateway domain wiring) plug into. No user-visible surface changes yet — nothing instantiates the element outside the mock fixture page.

Why This Change Was Made

Board rendering is self-contained against a frozen contract (types local in ui/src/lib/board/view-types.ts until the protocol package lands), so it can build and test independently: pure DOM-free 12-column auto-compacting layout engine (gravity-up, push-aside, first-fit), tab strip, widget cells with sandboxed iframes, grant placeholder/rejected/error states, pointer drag + resize, keyboard nudge with aria announcements.

User Impact

None yet (dead code until the host lands; mock dev page at /__fixtures/board/ for development). Follow-up PRs wire it to the session view and gateway.

Evidence

• Engine invariant suite: deterministic first-fit, no overlaps, no compactable holes, stable order, drag preview, resize clamps 1-12 x 1-20, stable cell/iframe identity across reorder — 42 unit/component tests green post-rebase; 9 Chromium layout tests (skipped headless in CI lane, green locally in browser mode).
• check-changed --staged green pre-rebase (format, i18n, typechecks, lint); i18n verify green post-rebase (en.ts keys only; locale bundles left to refresh workflow).
• Autoreview clean.
• Mock-page browser proof: tab switching, pending→granted transition, sandboxed frames render, zero page errors.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 12:32 PM ET / 16:32 UTC.

Summary
The branch adds a session-board grid layout engine, Lit board/widget components, fixture support, styling, translations, and focused UI tests.

PR surface: Source +1963, Tests +1040, Other +69. Total +3072 across 12 files.

Reproducibility: unclear. the supplied inline review gives a concrete source-level MCP-app loading path, but no inspectable final-head browser artifact demonstrates that the path now succeeds.

Review metrics: 1 noteworthy metric.

• Temporary integration contract: 1 new local board view-contract module. A protocol-shaped UI contract is being introduced before the stated gateway-protocol follow-up, so its ownership and migration path need confirmation.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Result: blocked until 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] Resolve the parent iframe sandbox for mcp-app widgets and add focused coverage.
• Publish redacted final-head browser evidence for the fixture and MCP-app path, without private endpoints, IP addresses, or tokens.
• Get an owner decision on whether the temporary board contract can land before the host and gateway protocol wiring.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body reports a mock-page browser run, but no inspectable final-head screenshot, recording, terminal output, linked artifact, or redacted runtime log is supplied. Add redacted real-browser evidence, including an MCP-app widget path if applicable; updating the PR body should trigger a fresh review, or a maintainer can comment @clawsweeper re-review. 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] MCP-app widgets may fail to load because the existing standalone host requires a same-origin authenticated fetch path that a strict opaque-origin parent sandbox can break.
• [P1] The branch introduces a temporary local board-view contract ahead of the stated gateway-protocol follow-up, so maintainers need to confirm that this staging boundary is intentional.
• [P1] The PR body reports fixture testing but provides no inspectable after-fix browser artifact for the final head.

Maintainer options:

1. Fix the MCP-app sandbox contract (recommended)
   Make the mcp-app embed path retain the origin required by the existing standalone host, then add focused regression coverage or a direct browser proof.
2. Pause for contract sequencing
   Hold the branch until an owner confirms that this temporary local board contract is the intended pre-protocol integration boundary.

Next step before merge

• [P1] The sandbox repair is concrete, but the protected maintainer label and temporary contract sequencing require owner review; contributor-supplied real browser proof cannot be generated by an automated repair worker.

Maintainer decision needed

• Question: Should the temporary local board-view contract and uninstantiated board component land before the dashboard host and gateway protocol wiring are ready?
• Rationale: The branch intentionally creates a protocol-shaped UI contract for later PRs; whether that disconnected staging surface belongs on main is a product and ownership sequencing choice.
• Likely owner: steipete — This contributor owns both adjacent dashboard implementation slices described in the supplied PR context.
• Options:
  • Sequence with host and protocol work (recommended): Hold the board foundation until its dashboard host and gateway contract have an explicitly agreed landing path.
  • Land a staged foundation: Allow the local contract to land first after the MCP embed path and final-head browser evidence are verified.

Security
Cleared: The diff adds an iframe sandboxed by default and no new dependency, workflow, permission, or supply-chain execution path is evident; the MCP issue is a functional embed-contract defect rather than a demonstrated security weakening.

Review findings

• [P2] Preserve the MCP app host's required origin — ui/src/components/board/board-widget-cell.ts:279-283

Review details

Best possible solution:

Preserve a single supported MCP-app embed boundary, add redacted final-head browser proof that exercises it, and land the temporary board contract only with explicit owner agreement on its host and protocol migration path.

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

Unclear: the supplied inline review gives a concrete source-level MCP-app loading path, but no inspectable final-head browser artifact demonstrates that the path now succeeds.

Is this the best way to solve the issue?

No: the staged board implementation is plausible, but it must either use the existing MCP-app embed contract correctly or prove an equivalent supported path before it is the best maintainable solution.

Full review comments:

• [P2] Preserve the MCP app host's required origin — ui/src/components/board/board-widget-cell.ts:279-283
  For mcp-app widgets, the existing standalone host performs an authenticated same-origin fetch before it renders its inner sandbox. A parent sandbox with only allow-scripts gives that host an opaque origin, so the fetch becomes cross-origin and the MCP widget cannot load. Select the sandbox by content kind or reuse the supported MCP-app embed path.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.72

AGENTS.md: unclear because the file could not be read completely.

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

Label changes

Label justifications:

• P2: This is a substantial but not yet user-facing UI feature with a concrete merge blocker and no reported production outage.
• merge-risk: 🚨 compatibility: The new local snapshot, operation, callback, and frame-URL contract will be consumed by the linked dashboard work before its final protocol owner exists.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports a mock-page browser run, but no inspectable final-head screenshot, recording, terminal output, linked artifact, or redacted runtime log is supplied. Add redacted real-browser evidence, including an MCP-app widget path if applicable; updating the PR body should trigger a fresh review, or a maintainer can comment @clawsweeper re-review. 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

PR surface:

Source +1963, Tests +1040, Other +69. Total +3072 across 12 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	8	1963	0	+1963
Tests	3	1040	0	+1040
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	1	72	3	+69
Total	12	3075	3	+3072

What I checked:

• Unresolved MCP-app embedding concern: The supplied inline review identifies that a parent iframe sandbox limited to allow-scripts makes the MCP standalone host opaque-origin, preventing its authenticated same-origin fetch path from loading the widget. (ui/src/components/board/board-widget-cell.ts, e879133dc576)
• Prior-review continuity: The latest completed ClawSweeper review at commit 228a839 required real behavior proof; the supplied final PR body still describes a browser run without an inspectable screenshot, recording, terminal output, artifact, or redacted runtime log. (228a839afa58)
• Related implementation boundary: The open dashboard-shell PR explicitly describes this branch as the source of <openclaw-board-view>, making the two PRs adjacent implementation slices rather than duplicate work. (ui/src/components/board/board-view.ts, e879133dc576)

Likely related people:

• steipete: The contributor authored this board implementation and the linked dashboard-shell PR, whose description identifies this component as its board-view dependency. (role: linked-feature contributor; confidence: medium; commits: c8e4678d0586, e879133dc576; files: ui/src/components/board/board-view.ts, ui/src/lib/board/grid.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 (2 earlier review cycles)

• reviewed 2026-07-18T11:12:25.669Z sha c8e4678 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-18T14:57:37.359Z sha 228a839 :: needs real behavior proof before merge. :: none

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c8e4678d05

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Allow MCP app widget hosts to retain same-origin

For widgets whose contentKind is mcp-app, this iframe will commonly be pointed at the existing MCP standalone URL (/__openclaw__/mcp-app#...). That host immediately fetches /__openclaw__/mcp-app/view with an Authorization header and then creates its own inner sandbox with allow-same-origin allow-forms (src/gateway/mcp-app-standalone.ts:310-320); placing the host in a parent iframe with only allow-scripts gives it an opaque origin, so that same-origin ticket fetch becomes cross-origin/preflighted and the MCP app never loads. Please select the sandbox based on widget.contentKind (or route MCP apps through the existing MCP app embed path) rather than using the strict HTML sandbox for all widgets.

Useful? React with 👍 / 👎.