test(chat): add Reactor runtime coverage for timeline behavior

[calebeden]

Context

PR #1110 removes the retired FunctionalUI chat root, timeline, composer, virtualization infrastructure, resources, and tests that exercised that unreachable implementation. Production ChatPage and ChatWindow already mount the Reactor chat surface.

That cleanup intentionally does not add a new Reactor test suite. Mixing a large legacy-code deletion with new Reactor runtime-test design would broaden the PR beyond its purpose, make review harder, and couple removal of unreachable code to separate decisions about supported Reactor behavior.

Problem

Reactor has unit and source-contract coverage for timeline composition, stable keys, tail-navigation policy, resource usage, and selectable text. It also has a runtime proof for grouped tool activity. It does not yet have equivalent live WinUI coverage for several user-facing timeline behaviors formerly exercised through the FunctionalUI host.

The deleted tests cannot be ported mechanically. Many assertions were specific to VirtualStack, ItemsRepeater, FunctionalUI control caches and reconciliation, deleted XAML style keys, or legacy settle-timer behavior. Reactor uses ItemsView, ReactorHostControl, and a different scroll controller and rendering model.

Proposed Reactor Runtime Coverage

Add focused tests that mount ReactorChatTimeline or OpenClawReactorChatRoot through ReactorHostControl on the real UI thread and verify supported user-facing invariants:

1. A large timeline is scrollable and ItemsView realizes only a bounded subset of rows.
2. Initial display starts at the newest message.
3. Appended messages and in-place thinking or streaming growth remain bottom-followed when the user is already near the bottom.
4. A user who scrolls up is not repinned while content continues streaming, and their reading position remains stable within a reasonable tolerance.
5. Prepending older history preserves the reader's position; an explicit scroll-to-bottom request resumes following the newest message.
6. Define the intended Reactor selection contract, then verify selectable message text and the boundaries around code and table content.
7. Verify tool and compaction cards resolve current Reactor/Fluent theme resources at runtime without depending on removed FunctionalUI style keys.

Non-Goals

• Recreate FunctionalUI VirtualStack cache-count assertions.
• Test FunctionalUI reconciler effect pruning through deleted chat components.
• Restore assertions for removed ChatToolCardBorderStyle or ChatCompactionCardStyle resources.
• Preserve legacy settle-timer implementation details that Reactor does not use.
• Make these tests a prerequisite for the focused dead-code removal in PR refactor(chat): remove the retired FunctionalUI chat surface #1110.

Acceptance Criteria

• Tests exercise the real Reactor host and WinUI controls rather than inspecting source text.
• Assertions describe observable behavior, not private implementation structure unless required to prove platform virtualization.
• Timing and layout waits are bounded and deterministic enough to avoid recreating the legacy virtualization test flake.
• Tests cover both bottom-follow and scrolled-up reading modes.
• Tests run in an isolated UI-test environment and do not read or modify real user settings.
• Documentation identifies the new Reactor proofs as the runtime coverage owner for these invariants.

Related: #1110

[clawsweeper]

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

Summary
Keep open. Current main’s live timeline proofs still mount the retired FunctionalUI host, while the only Reactor-host proof covers tool activity rather than timeline behavior; the architecture ledger expressly defers this replacement coverage. Likely related people: Caleb Eden for the Reactor timeline, Scott Hanselman and Karen for legacy timeline proof and scroll behavior.

Reproducibility: not applicable. this requests new runtime coverage, and source inspection confirms the production and legacy test hosts differ.

Root-cause cluster
Relationship: canonical
Canonical: #1115
Summary: This issue is the dedicated tracker for replacement Reactor timeline proof coverage; the linked refactor deliberately excludes that separate test-design work.

Members:

• adjacent_distinct: refactor(chat): remove the retired FunctionalUI chat surface #1110 - The open refactor removes the retired FunctionalUI chat surface and explicitly leaves Reactor runtime-test design to this issue.
• adjacent_distinct: refactor(ui): replace Cron response rendering and remove FunctionalUI #1118 - It concerns the separate remaining FunctionalUI dependency in Cron response rendering, not chat timeline proof coverage.

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.

Maintainer decision needed

Question	Recommendation
Which Reactor timeline behaviors should become mandatory runtime contracts before the linked FunctionalUI cleanup can retire the legacy timeline proofs?	Approve a focused replacement suite: Define an initial Reactor-host suite for large-list realization, initial tail, bottom-follow, and scrolled-up stability, with selection and history-prepend coverage added after their contracts are agreed.

Why: The source and architecture ledger intentionally defer this test design, and choices such as selection boundaries and prepend-position guarantees determine the durable contract rather than a mechanical port.

Next step
A maintainer must choose the durable Reactor interaction contracts before a focused test implementation can proceed.

Review details

Best possible solution:

Approve a small Reactor-hosted UI-test seam for retained user-facing scroll and selection contracts, then retire only the legacy proofs that no longer describe production behavior.

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

Not applicable: this requests new runtime coverage, and source inspection confirms the production and legacy test hosts differ.

Is this the best way to solve the issue?

Yes in direction: Reactor-hosted behavioral tests are the right replacement, but maintainers must select the supported contracts instead of porting FunctionalUI implementation assertions.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Porting legacy assertions mechanically would test FunctionalUI-only controls and timing rather than the Reactor ItemsView behavior users receive.
• Selection boundaries and prepended-history position guarantees need an explicit supported Reactor contract before a stable UI-test suite can be designed.

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

Label changes

Label justifications:

• P3: This is a low-urgency test-coverage and maintenance proposal, not a reported user-facing failure.

Evidence reviewed

What I checked:

• Deferred runtime-proof owner: The architecture ledger assigns production timeline virtualization to Reactor and expressly defers replacement runtime proof coverage until it supersedes legacy focused UI host coverage. (docs/ARCHITECTURE.md:142, 582a44713860)
• Current production path: The Reactor timeline renders a keyed ItemsView and binds a vertical scroll controller, confirming the requested proof must exercise Reactor rather than the legacy host. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:120, 582a44713860)
• Legacy proof mismatch: The existing runtime virtualization suite mounts FunctionalHostControl and OpenClawChatTimeline, including large-timeline, streaming, scrolled-up-reading, and prepended-history tests; it does not mount the Reactor root. (tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs:34, 582a44713860)
• Existing limited Reactor runtime proof: The existing Reactor-host runtime proof exercises grouped tool-card expansion and selectable output directly, not timeline ItemsView realization or scrolling. (tests/OpenClaw.Tray.UITests/ReactorToolActivityProofTests.cs:16, 582a44713860)
• Feature history: Reactor timeline work appears in Caleb Eden’s aac07ab; legacy proof and scroll work was recently updated by Scott Hanselman and Karen. (tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs:34, aac07abb1fbd)

Likely related people:

• Caleb Eden: Authored the locally available commit introducing the current Reactor timeline surface and its existing Reactor tool-activity proof. (role: recent Reactor timeline contributor; confidence: high; commits: aac07abb1fbd; files: src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs, tests/OpenClaw.Tray.UITests/ReactorToolActivityProofTests.cs)
• Scott Hanselman: Authored the latest locally available update to the legacy timeline runtime proof suite. (role: recent legacy timeline-proof contributor; confidence: high; commits: c03d4da474b4; files: tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs)
• Karen: Authored the available Reactor scroll-controller stabilization commit. (role: scroll-behavior contributor; confidence: high; commits: ca8fb4a404ad; files: src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.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.