🦞 Tracking: Chat & everyday UX feel great

[samanthamsong]

🦞 Tracking issue (epic) — this rolls up the scenario below. It holds no code itself; the work
lives in the child issues in the checklist below. Triage here, build there.

Outcome

Chat and the everyday UX feel great.

Definition of done

Chat is performant and selectable, long-running agent tasks are visible, agent creation is smooth, and notifications work.

Child issues

• Notifications tab never shows notifications despite Windows Notification Center having them #820 — Notifications tab never shows notifications
• Improve chat experience #859 — Improve chat experience
• Chat UI virtualization (perf on large conversations) #860 — Chat UI virtualization (perf on large conversations)
• Markdown viewer — full fidelity + text selection #861 — Markdown viewer — full fidelity + text selection
• Long-running tasks UX (taskbar Tasks UI) #862 — Long-running tasks UX (taskbar Tasks UI)
• Agent creation UX + syncing #863 — Agent creation UX + syncing
• UX testing coverage #864 — UX testing coverage

Backlog: One-pagers/FY27-Windows-Node-work-items.md • Narrative: User-scenarios/scenario-s6-chat-and-ux.md

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 4, 2026, 6:04 PM ET / 22:04 UTC.

Summary
Keep open. This collaborator-owned epic remains the canonical rollup for five distinct open UX scopes; notifications and chat virtualization are completed child slices, not completion of the overall outcome.

Reproducibility: not applicable. this is a planning epic, not one reportable failure with a single current-main reproduction path.

Root-cause cluster
Relationship: canonical
Canonical: #839
Summary: This is the canonical rollup for five open UX workstreams; notification mirroring and chat virtualization are completed partial slices.

Members:

• partial_overlap: Notifications tab never shows notifications despite Windows Notification Center having them #820 - Completed the notifications slice only.
• partial_overlap: Chat UI virtualization (perf on large conversations) #860 - Completed the large-conversation virtualization slice only.
• partial_overlap: Improve chat experience #859 - Open child scope for general chat improvements.
• partial_overlap: Markdown viewer — full fidelity + text selection #861 - Open child scope for markdown fidelity and text selection.
• partial_overlap: Long-running tasks UX (taskbar Tasks UI) #862 - Open child scope for long-running task visibility.
• 2 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Which remaining child scope should be prioritized next, and should this epic remain the canonical rollup until all five are resolved?	Keep the epic and sequence child issues: Retain this rollup while selecting one independently scoped child issue at a time for delivery.

Why: The remaining work spans independent UX capabilities and needs product sequencing rather than a single technical repair.

Next step
A maintainer product-sequencing decision is required because the remaining child issues do not share one safe implementation boundary.

Review details

Best possible solution:

Keep this issue as the rollup, prioritize and deliver each remaining child issue independently, then update the checklist as those slices land.

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

Not applicable: this is a planning epic, not one reportable failure with a single current-main reproduction path.

Is this the best way to solve the issue?

Yes. Keeping a canonical rollup while delivering its independent child scopes separately is the narrowest maintainable path.

AGENTS.md: found, but no applicable review policy affected this item.

Remaining risk / open question:

• The remaining five child scopes have different product boundaries and acceptance criteria, so treating the epic as one repair would obscure sequencing and validation needs.

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

Label changes

Label justifications:

• P2: This is a normal-priority UX planning epic with completed slices and several remaining bounded improvements.
• impact:ux-friction: The stated outcome is smoother chat and everyday interactions rather than a service outage or data-loss incident.

Evidence reviewed

What I checked:

• Open child scopes: The issue body and timeline identify five still-open child scopes: chat improvements, markdown selection/fidelity, taskbar task status, agent creation/sync, and UX coverage. These are distinct product workstreams rather than one repair.
• Notification slice remains implemented: The current shared publisher independently sends a Windows toast and an in-app notification, preserving the completed notification-mirroring child slice. (src/OpenClaw.Tray.WinUI/Services/AppNotificationPublisher.cs:43, 6e225e4758e1)
• Virtualization slice remains implemented: Current contract coverage requires the production chat timeline to use virtualized ItemsRepeater rows and protects follow-to-bottom behavior. (tests/OpenClaw.Tray.Tests/ChatTimelineVirtualizationContractTests.cs:6, 6e225e4758e1)
• Merged child-slice provenance: Merged commits 8b5ea32 and fcc7477 correspond to the notification-mirroring and chat-virtualization work referenced by the epic. (fcc74778a35c)
• Maturity classification: No maturity label is applied: this broad epic has no single primary owner surface, and the required maturity helper could not find qa/maturity-scores.yaml in this checkout.

Likely related people:

• samanthamsong: Created this epic and the open child issues that define its remaining scope. (role: tracking-scope author; confidence: high)
• RBrid: Authored the merged notification-mirroring work represented by the current notification publisher path. (role: implemented notification slice; confidence: high; commits: 8b5ea3294b33; files: src/OpenClaw.Tray.WinUI/Services/AppNotificationPublisher.cs, src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs)
• Andy Ye: Authored the merged virtualized chat-timeline work whose contract and UI proof remain on current main. (role: implemented chat virtualization slice; confidence: high; commits: fcc74778a35c; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, tests/OpenClaw.Tray.Tests/ChatTimelineVirtualizationContractTests.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.