Add a bottom-origin virtualizing chat layout

[karkarl]

Problem

The current Reactor ItemsView uses WinUI StackLayout, which has no supported reverse or bottom-origin mode. Initial chat positioning relies on a one-time StartBringItemIntoView request and can race the virtualized layout lifecycle. In-place streaming follow also needs stronger user-intent and operation-correlation handling.

Proposed work

• Implement a custom bottom-origin VirtualizingLayout compatible with ItemsView and the AnnotatedScrollBar controller binding.
• Preserve stable keyed item virtualization, historical prepend behavior, and user scroll-away intent.
• Harden initial and streaming tail-follow behavior using supported WinUI completion/lifecycle signals.
• Avoid height/extent calculations, ChangeView, UpdateLayout, VerticalAnchorRatio, and timer-based settling.

Acceptance criteria

• Chat opens at the latest history item in every host.
• Streaming stays at the tail only while the user remains in follow mode.
• Scrolling away or using the annotated scrollbar never freezes the UI or is overridden.
• Annotated scrollbar remains full-height and controller-bound.
• Automated direct-Reactor UI coverage validates initial positioning, streaming follow, scroll-away, and annotated scrollbar navigation.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 24, 2026, 8:01 PM ET / July 25, 2026, 00:01 UTC.

Summary
Keep open. This is a new, detailed Reactor chat-layout proposal, and the available evidence does not establish that current main already provides bottom-origin virtualization, reliable tail follow, and non-overriding user scroll intent. The referenced merged PR is about browser-control ports and is unrelated. Likely related people: karkarl is the reporter and detailed Reactor-domain proposer (low confidence); current-main feature ownership could not be established in this read-only environment.

Reproducibility: not applicable. as written: this issue requests a new bottom-origin virtualized layout and does not provide a failing current-main reproduction. The detailed acceptance criteria are useful, but direct Reactor UI characterization is still needed.

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
Should Reactor adopt a custom bottom-origin virtualizing layout as the supported cross-host chat foundation, rather than first narrowing the existing layout and follow-policy behavior?	Authorize a focused layout investigation: Create a small design and characterization effort that compares the existing Reactor path with a custom bottom-origin layout before committing to the replacement.

Why: The request introduces a new low-level rendering architecture and strict implementation constraints across hosts; source-level confirmation of the existing supported path and maintainer intent are needed before selecting the permanent design.

Next step
A maintainer must choose the permanent Reactor layout direction before a safe, bounded implementation task can be formed.

Review details

Best possible solution:

First characterize current Reactor chat behavior in each host, then implement the smallest supported layout and follow-policy seam that preserves virtualization and user scroll intent, adding direct UI coverage for all four stated navigation scenarios.

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

Not applicable as written: this issue requests a new bottom-origin virtualized layout and does not provide a failing current-main reproduction. The detailed acceptance criteria are useful, but direct Reactor UI characterization is still needed.

Is this the best way to solve the issue?

Unclear. A custom layout is plausible because ItemsView supports replacement layouts, but the request should first prove that a smaller supported layout or follow-policy change cannot preserve the required behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A custom bottom-origin VirtualizingLayout changes a foundational chat rendering and navigation path, so it needs characterization coverage across initial load, prepend, streaming, user scroll-away, and annotated scrollbar interaction before implementation is accepted.
• The requested prohibition on extent calculations, view changes, lifecycle forcing, and timers may rule out existing supported recovery mechanisms; a maintainer should validate the exact WinUI lifecycle contract before committing to that design boundary.

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

Label changes

Label changes:

• add P3: This is a speculative but potentially valuable chat-layout architecture improvement, with no demonstrated current user-facing regression in the report.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative but potentially valuable chat-layout architecture improvement, with no demonstrated current user-facing regression in the report.

Evidence reviewed

What I checked:

• Issue scope: The report identifies a specific missing behavior set: bottom-origin initial positioning, keyed virtualization, prepend preservation, streaming tail follow, scroll-away intent, and annotated-scrollbar compatibility.
• WinUI capability boundary: Microsoft's ItemsView guidance states that ItemsView defaults to StackLayout and can use a replacement custom layout, so the proposed direction is technically plausible but remains a substantial product and architecture choice rather than an already-defined bug fix.
• Referenced merged PR is unrelated: The supplied related merged pull request changes browser-control port routing for split gateways, not Reactor, ItemsView, virtualized chat layout, or chat scrolling.
• Repository inspection limitation: A read-only shell inspection was attempted, but the execution sandbox failed before repository files or git history could be read. That prevents high-confidence current-main implementation or ownership claims and rules out a closure.

Likely related people:

• karkarl: The issue supplies concrete Reactor, ItemsView, scrolling, virtualization, and test acceptance criteria, indicating relevant knowledge of the affected surface; current-main ownership could not be traced because repository inspection was unavailable. (role: reporter and domain proposer; confidence: low)

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.