Follow up Workspace file rail parity gaps

[bkudiess]

The initial Windows Workspace file rail adds the core session files experience: session-touched files, read/edited/missing state, metadata, path-driven folder browsing, server-side search/truncation messaging, copy-path actions, browser-only preview guards, and safe preview via the typed sessions.files.list / sessions.files.get APIs.

Remaining follow-up gaps to close against the main Control UI experience:

• Show artifacts in the workspace rail when available.
• Consider refresh/collapse affordances if they fit the Windows Workspace page layout.
• Further polish visual sectioning if the page later moves closer to the chat-side rail presentation.

This should build on the existing WorkspaceFilesModel projection layer and canonical typed gateway APIs rather than duplicating protocol DTOs or parsing raw gateway payloads.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 26, 2026, 10:16 PM ET / 02:16 UTC.

Summary
Keep open: current main still has the typed sessions.files foundation, but the Windows Workspace page is not yet wired to the requested projection/browser/search/artifact parity path, and no canonical replacement issue or viable open PR now owns the remaining work.

Reproducibility: yes. from source inspection: the current Workspace page lacks the requested artifact display, path browser/search controls, and copy-path affordances, and it still uses raw agents.files payloads. No live UI session was run because this review is read-only.

Next step
The work is valid and bounded, but the existing no-new-fix-pr/product-decision signals and missing projection-layer symbol make maintainer direction the next step.

Review details

Best possible solution:

Implement a focused Workspace projection/UI follow-up that wires the page to typed sessions.files list/get, adds artifact display when available, preserves path/search/truncation/copy behavior, and covers the UI mapping with targeted tests.

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

Yes, from source inspection: the current Workspace page lacks the requested artifact display, path browser/search controls, and copy-path affordances, and it still uses raw agents.files payloads. No live UI session was run because this review is read-only.

Is this the best way to solve the issue?

Yes in direction, but not yet automation-ready: building on typed sessions.files is the maintainable path, while extending the raw JsonElement Workspace parser would create protocol drift. The missing projection-layer and artifact/layout decisions need maintainer confirmation first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live UI reproduction was run in this read-only review; the gap is source-reproducible but still carries the issue's live-repro label.
• The issue names WorkspaceFilesModel, but that symbol is absent on current main, so maintainers should confirm whether to introduce it or use a differently named projection layer.
• Artifact display may need a gateway response-shape or UI mapping decision beyond the currently tested SessionFileList files/browser model.

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

Label changes

Label changes:

• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• remove issue-rating: 🐚 platinum hermit: Current issue advisory state no longer selects this label.
• remove clawsweeper:needs-live-repro: Current issue advisory state no longer selects this label.

Label justifications:

• P2: This is a concrete normal-priority Workspace UX parity improvement with limited blast radius, not an urgent regression.
• impact:other: The affected area is the maintainer-visible Windows Workspace file browsing and artifact/preview experience, which does not fit the more specific impact labels.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its validation requirements shape any future fix path, while this review stayed read-only. (AGENTS.md:1, acfbf62b4c45)
• VISION.md absent: No VISION.md exists in this checkout, so product fit cannot be anchored to a repository vision document. (acfbf62b4c45)
• Maturity shortlist unavailable: The maturity helper could not find qa/maturity-scores.yaml, so no M4/M5 maturity match was established. (acfbf62b4c45)
• Current Workspace UI lacks requested parity controls: WorkspacePage.xaml exposes a refresh button, workspace path text, file list, selected-file title, and rendered/raw selector, but not artifact display, search input, path browser controls, or copy-path actions. (src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml:86, acfbf62b4c45)
• Current Workspace code still uses raw agent-file events: WorkspacePage.xaml.cs calls RequestAgentFilesListAsync and parses JsonElement file payloads directly, rather than using the typed sessions.files API path requested by the issue. (src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs:72, acfbf62b4c45)
• Legacy agent files transport remains wired: OpenClawGatewayClient.RequestAgentFilesListAsync and RequestAgentFileGetAsync still send agents.files.list/get, confirming the Workspace page is not yet on sessions.files.list/get. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:970, acfbf62b4c45)

Likely related people:

• bkudiess: Git blame and the merged protocol foundation pull request tie the sessions.files typed client/models to this person, and prior Workspace master-detail work also appears in the area history. (role: typed protocol contributor and workspace redesign contributor; confidence: high; commits: 2cae69ba6ca4, 3179090b0adb; files: src/OpenClaw.Shared/OpenClawGatewayClient.Protocol.cs, src/OpenClaw.Shared/GatewayProtocolModels.cs, src/OpenClaw.Shared/IOperatorGatewayClient.cs)
• christineyan4: GitHub pull request metadata and local git history show prior WorkspacePage caching/loading changes in the current page area. (role: workspace-adjacent contributor; confidence: medium; commits: 94ff2f449433; files: src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml, src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs)
• Scott Hanselman: History shows scoped Workspace cache work and merges of earlier Workspace page changes, making this a plausible routing candidate for page integration decisions. (role: workspace integration merger and adjacent contributor; confidence: medium; commits: 9724eea243b1, 9dd8045d935e, e33d51a53241; files: src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml, src/OpenClaw.Tray.WinUI/Pages/WorkspacePage.xaml.cs, src/OpenClaw.Tray.WinUI/Services/AppState.cs)

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.