improve(chat): remove an unnecessary wait when opening chat history

[dotMorten]

What Problem This Solves

Opening or switching chat histories can leave the initial scroll request waiting for layout event causing the view to not consistently scroll to the most recent message.

User Impact

User impact: initial scrolling toward the latest message no longer requires an additional layout event after the view loads.

Why This Change Was Made

The native bring-into-view request handles target realization and layout. Waiting for an unrelated future LayoutUpdated notification adds an unnecessary prerequisite and make the behavior unpredictable.

InitialTailPositioner remains the owner. It waits for the ItemsView and ScrollView to load, then retains the existing dispatcher handoff so navigation runs outside Reactor reconciliation. Request-generation and tail-identity checks, unload/disposal cleanup, and streaming follow behavior remain in place. The source-contract tests now guard the load-only flow and prohibit reintroducing the layout-event subscription.

Evidence

Historical diagnostic below: the 77-message experiment used the explicitly documented compatibility overlay. It is separate from the September 23 current-head, committed-dependency results under Validation and Real Behavior Proof. The author's latest clarification reports successful local x64 and ARM64 testing and distinguishes the scroll-restore change from the separate Reactor anchor crash.

Actual OpenClaw was exercised with two synthetic 77-message histories. That experiment reproduced the original invalid-anchor crash on the first session switch, rather than proving this change fixes it. The full native dump resolved to:

ItemsView::OnScrollViewAnchorRequested (ItemsView.cpp:972)
  -> ScrollingAnchorRequestedEventArgs::AnchorElement
     (ScrollingAnchorRequestedEventArgs.cpp:43)
  -> E_INVALIDARG (0x80070057), surfaced as 0xC000027B

Pre-publication rubber-duck review of the committed two-file change found no actionable issues. The bundled Codex autoreview command was also attempted but could not run because the Codex CLI is not installed; that tool is not being reported as passed.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• windows-winui-interactive: initial chat-history scrolling, session switching, and native ItemsView behavior require an interactive Windows app.
• windows-11-arm64: native ARM64 build and runtime crash investigation were performed.

Validation

Current-head maintainer run, September 23

Tested head: 113416a4fbb6d26bd3db37b065c9c0d905d52aae. This is an ordinary merge of exact main fb8b9e736f7473705ea14d8e97f6117bcbaddf68 into original head f683edcae3b4405316149980b78a28ea5f49291f, pushed to the existing contributor branch. No manual source changes, dependency upgrades, compatibility overlay, rebase, or force push. The contributor's two-file delta remains +72/-54, with the identical stable patch ID 5cd326a09541ad704bc754f2a7ccdf3aa1e49c33.

Command	Result at current head
.\build.ps1	Passed, native ARM64 Debug
dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore	4,093 passed, 35 skipped, 0 failed
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore --filter FullyQualifiedName~ChatTimelinePresentationTests	25 passed, 0 skipped, 0 failed; source-contract/presentation checks, not native proof
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore	3,070 passed, 0 skipped, 0 failed
.\build.ps1 -Project WinUI -Configuration Release	Passed, non-Dev ARM64 Release
.\scripts\test-gateway-fixture.ps1 -AppPath <Debug app> -Configuration Debug -ArtifactsDirectory <Debug artifacts>	Failed: fixture profile/polling/MCP 30 passed; native UI 2 passed, 2 failed, 0 skipped
.\scripts\test-gateway-fixture.ps1 -AppPath <Release app> -Configuration Release -ArtifactsDirectory <Release artifacts>	Failed: fixture profile/polling/MCP 30 passed; native UI 3 passed, 1 failed, 0 skipped

The app paths were the current worktree's src\OpenClaw.Tray.WinUI\bin\<Debug or Release>\net10.0-windows10.0.22621.0\win-arm64\OpenClaw.Tray.WinUI.exe. Tests used the private native .NET SDK 10.0.400, isolated unit-test settings and the repository's explicit GatewayFixtureIsolation harness. Each fixture invocation received a fresh owned MXC ledger override. No real chats, provider accounts, normal Gateway, WSL, or uninstall path was used.

Exact-base control used a separate clean checkout of fb8b9e736f7473705ea14d8e97f6117bcbaddf68, unchanged committed dependencies and identical GatewayFixtureUiTests.cs. Only the failed native cases were selected, once per relevant configuration: Debug 2/2 passed; production-shaped Release 1/1 passed. The command was dotnet test .\tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj -c <Debug or Release> -r win-arm64 -p:Platform=ARM64 -p:DevBuild=false --filter <selected cases>, with the explicit freshly built baseline app and fixture opt-in environment. No broad baseline unit suite or blind current-head retry was run.

At the September 23 initial closeout read, current-head Build and Test and CodeQL required approval (action_required). That is a historical CI snapshot, not a claim about their subsequent state. Old-head green checks are not current-head CI evidence.

Supplemental split-predicate diagnostic, September 24

Exactly one existing Release PopulatedPagesPreserveSelectionAndPreferencesStayInDisposableProfile case was run against the retained, hash-identical 113416a4 product. Only temporary test-harness instrumentation was compiled, with BuildProjectReferences=false; no product binary was rebuilt or modified. The existing navigation sequence, final conjunction and timeout were retained, with independent UI Automation observations added for picker selection and tail visibility. Result: 0 passed, 1 failed, 0 skipped, with the failed condition now identified as natural-tail visibility rather than session selection.

Command: dotnet test .\tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj -c Release -r win-arm64 -p:Platform=ARM64 -p:DevBuild=false --no-build --no-restore --filter FullyQualifiedName=OpenClaw.Tray.UITests.GatewayFixtureUiTests.PopulatedPagesPreserveSelectionAndPreferencesStayInDisposableProfile --logger trx;LogFileName=sessions-composite-diagnostic.trx, with the explicit retained Release app and a dedicated results/artifacts directory. A one-use invocation marker and exact product/test assembly hash checks guarded the command. No baseline, width or stress replay was performed.

The diagnostic profile explicitly set SystemRunSandboxEnabled=false, NodeSystemRunEnabled=false and EnableNodeMode=false. The test-only launcher used an OS environment allowlist and private HOME/USERPROFILE/APPDATA/LOCALAPPDATA/TEMP/TMP/MXC ledger roots. The app log confirmed Windows auto-start reconciliation and WSL keepalive/startup cleanup were skipped, and the MXC availability probe remained deferred with sandboxEnabled=False. No normal user state or unknown process was changed. Temporary test-source changes were restored exactly after retaining the patch and reports; production source and the contributor's committed delta remain unchanged.

Historical validation at original head

Command	Result
.\build.ps1 -Configuration Release	Passed, including the WinUI ARM64 build
dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj	3,983 passed, 33 skipped, 0 failed
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj	2,980 passed, 0 failed

The first test runs restored packages because this was a fresh worktree. Repository-root discovery and tray settings were isolated. The tests include ReactorTimeline_UsesStableBottomAnchoringAndDiscreteTailRequests and ReactorTimeline_InitialTailWaitsForLoadWithoutLayoutSubscription; these are source-contract checks, not proof that native scrolling always completes.

Real Behavior Proof

Current-head native fixture evidence

Recommendation: HOLD pending the differential native failures, not a claim that the separate anchor crash was introduced by this patch. The full Debug and Release fixture commands failed overall. Exact-base controls passed the corresponding selected cases, so the failures are not demonstrated to be inherited. One pass per configuration raises a regression concern but does not prove a deterministic cause or exclude timing sensitivity. The September 24 diagnostic resolves the Sessions-case predicate ambiguity: selection succeeds, but natural-tail visibility fails. It does not establish the causal scheduling or realization branch.

Existing native test / observation	PR Debug	PR non-Dev Release	Exact-base control
SessionPickerSwitchesRealHistoriesAndShowsMessage240AtBothWidths	Failed at the wide-width marker check, after three A/B natural-tail checks and narrow-width marker visibility had completed	Passed, including initial/repeated natural-tail checks before manual scrolling and final-marker bounds at both widths	Debug passed; Release not selected because that PR case passed
PopulatedPagesPreserveSelectionAndPreferencesStayInDisposableProfile	Failed at Sessions-page action routes to long chat	Failed at the same assertion; supplemental diagnostic identifies missing natural-tail visibility with correct selection	Passed in Debug and Release
EmptySessionRendersConnectedComposerWithoutPreviousHistory	Passed	Passed	Not selected
LateHistoryForPreviousSessionCannotReplaceSelectedTranscript	Passed	Passed	Not selected

The Sessions assertion is the conjunction PickerShows(long title) && IsVisibleInTimeline(final marker). The supplemental Release diagnostic recorded 86 observations over approximately 20 seconds. The expected picker title matched in 85/86, and the final native picker ItemStatus reported selectedThreadId=agent:main:fixture-long with that same key in loadedThreadIds. Its name was Session: Fixture: 240-message conversation, and the synthetic Gateway returned the target chat.history with outcome=ok. The first selection boolean raced initial navigation because the UIA reads are not atomic; all later matching-selection observations still failed the tail check.

Natural-tail visibility was false in 86/86 observations: 0/86 visible. The expected marker FIXTURE LONG END 240 was absent from the accessible app tree, with markerBounds=null. Vertical scroll percentage remained 0. Final timeline bounds were [1268,702,1105,660] (x,y,width,height) and scroll view size was 0.9893865803202015. This is direct evidence of correct native session selection with unsuccessful natural-tail positioning, not a routing failure. The app remained responsive and produced no crash-log artifact. No speculative production fix was made; the author retains ownership of the fix.

The successful September 23 Release long-history run records FIXTURE LONG END 240 at physical window sizes 1500x720 and 1900x950. Those initial/A-B/width positives and the exact-base controls remain preserved alongside the failed case. All bounded fixture reports show the app responding; no crash-log artifact or native anchor crash was observed in these runs. This is not a general crash-freedom claim. All owned app processes and synthetic profiles were disposed, including diagnostic PID 25916 and its private profile.

Application DLL SHA256 identities:

Source/configuration	SHA256
PR Debug	B5B34C5E2F1E981BCCD96CD6595D406F33E1BA91A5521F05B3A47AD2F7D73467
PR Release, including the September 24 diagnostic	9A75549272672873C4E60419A091DA30DF7AD331769788982B52E650278CBE7D
Exact-base Debug	DD8F16A3E6C08D48948984AB8C63D05DF622A951DE841874A82A9255ACA07C05
Exact-base Release	BE382F6352D3BF0B5DA6081E1456C9ED690A1E9F87274AB86C8FB0CEED0C8B02

Both Release runtime configurations have System.Diagnostics.Debugger.IsSupported=false; neither used DevBuild or an attached debugger. The diagnostic product EXE SHA256 was unchanged at FDFC60C5CE567EFBA364760894BD6035360EB5FED2C5E047A9E1042935043CA0. The current-head scroll-controller SHA256 is 3D004E6B23EFF60D1ECB9261FB4037E0D08A90C728DD18FFAAAAD9D488D81EE5 and remains byte-identical to the contributor's original controller.

Local TRX/report artifacts are retained as pr1449-integrated, pr1449-baseline and pr1449-diagnostic in the maintainer session, not publicly uploaded. PR Debug result directory: ab4f64cd97c04b07afc829158654cffb; PR Release: cb00170fbe0144179f7f19e7b882ba0e. Failure run IDs: Debug wide-width 4459a796fab240a7b9cf96d65015c513, Debug Sessions f653bcb1da9c4354a70606261b52dfda, Release Sessions 67e9f2baf73840e3a7bdaf6a43dd7582. The successful Release layout report is in run a3247f38e3b04d4b91b1f45419fb56ef. Supplemental diagnostic run e014901c2d724a689ad373aca3259774 retains sessions-composite-diagnostic.json with the separate UIA observations, run.json, and the synthetic Gateway request trace; its TRX, restored test-only instrumentation patch and sanitized summary are retained in pr1449-diagnostic.

Not verified / blocked: the causal scheduling/realization mechanism behind the missed natural tail, screenshots and visual acceptance (winapp was unavailable; no optional installation or ad-hoc GUI driver), and streaming follow/non-stealing while scrolled up (the committed fixture is browse-only). Selection-versus-tail ambiguity is now resolved by the supplemental diagnostic. Current-head CI status remains a separate gate and cannot replace native behavior proof. No new review was represented as passed: the previously reviewed contributor patch is unchanged, and this closeout made no semantic patch.

Historical 77-message diagnostic at original head

• Environment tested: native Windows ARM64, Release/non-DevBuild OpenClaw, isolated tray data, synthetic loopback WebSocket gateway. Loaded DLL hashes matched the restored packages; no locally patched Reactor was used.
• PR head or commit tested: f683edcae3b4405316149980b78a28ea5f49291f, with the explicitly noted temporary package/Markdown compatibility overlay. The committed scroll controller was unchanged.
• Exact steps or command run: launch the actual OpenClaw chat window, load a synthetic 77-message mixed-height history, then use Sessions > Open in chat to switch from "Workaround two" to "Workaround one". The UI driver requested 20 switches and stopped on the first crash; it did not repair the scroll position.
• Evidence after fix: the initial chat viewport was blank with the final marker offscreen. The second history request was received, followed by the native exception shown above. The driver recorded completedSwitches: 0, processAlive: false, and two history responses.
• Observed result: the original invalid-anchor crash still reproduces. Removing the layout wait is not sufficient to prevent it. This is a negative diagnostic result, not successful tail-positioning or crash-free runtime proof.
• Screenshot or artifact links verified? N/A. The relevant native diagnostic output is copied above; the local screenshot and full dump are not publicly uploaded.

Security Impact

• New permissions or capabilities? No
• Secrets or tokens handling changed? No
• New or changed network calls? No
• Command or tool execution surface changed? No
• Data access scope changed? No
• If any answer is Yes, explain the risk and mitigation: N/A.

Compatibility and Migration

• Backward compatible? Yes
• Config or environment changes? No
• Migration needed? No
• If yes, list the exact upgrade steps: N/A.

Review Conversations

• I replied to or resolved every bot review conversation addressed by this PR.
• I left unresolved only conversations that still need maintainer judgment.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed September 24, 2026, 1:30 AM ET / 05:30 UTC (Revision 7).

ClawSweeper review

What this changes

The branch makes the Windows chat timeline request the latest message after its views load without waiting for another layout event, and updates source-contract tests.

Regression provenance

Possible regression — probable (reviewed change; failure trace). No predecessor PR is attributed.

Merge readiness

⛔ Blocked before merge - 4 items remain

The scroll-timing change is still unique to this PR, but a source-level retry gap and differential native failures block merge. Current main still uses the layout-event path. The separate anchor-crash work does not resolve this tail-positioning review.

Priority: P2
Reviewed head: 113416a4fbb6d26bd3db37b065c9c0d905d52aae

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The focused patch and real native observations provide useful review signal, but the retry gap and failed tail checks leave it short of merge readiness.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: The current-head ARM64 native app exercised chat-history selection through the Gateway fixture and showed some successful tail checks, but Debug and Release also missed the final row where selected base controls passed. The later Release diagnostic confirms selection succeeded while the tail stayed out of view; repaired-head proof is still needed. Redact private endpoints and other sensitive details in any shared output; updating the PR body should trigger re-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.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: The current-head ARM64 native app exercised chat-history selection through the Gateway fixture and showed some successful tail checks, but Debug and Release also missed the final row where selected base controls passed. The later Release diagnostic confirms selection succeeded while the tail stayed out of view; repaired-head proof is still needed. Redact private endpoints and other sensitive details in any shared output; updating the PR body should trigger re-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	6 items	Introduced retry gap: The introduced method returns when ItemsView has no ScrollView, with no event subscription or scheduled retry for a ScrollView assigned later. Current-main behavior: Current main still subscribes to LayoutUpdated and retries when ScrollView is unavailable; the latest release has that path too. The proposed timing change is not already implemented. Native fixture contract: The existing UI fixture checks natural visibility of message 240 before manual scrolling and checks the final marker after opening a long chat from Sessions.
Findings	1 actionable finding	[P2] Retry when ScrollView appears after ItemsView loads
Security	None	None.

How this fits together

Chat history from the Gateway becomes rows in the Windows tray timeline. The scroll controller uses the selected history and loaded native views to bring the latest row into view.

flowchart LR
  A[Gateway chat history] --> B[Timeline rows]
  B --> C[Selected history and tail]
  C --> D[Scroll controller]
  E[Loaded native views] --> D
  D --> F[Latest row visible]

Loading

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: The current-head ARM64 native app exercised chat-history selection through the Gateway fixture and showed some successful tail checks, but Debug and Release also missed the final row where selected base controls passed. The later Release diagnostic confirms selection succeeded while the tail stayed out of view; repaired-head proof is still needed. Redact private endpoints and other sensitive details in any shared output; updating the PR body should trigger re-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.
• Retry when ScrollView appears after ItemsView loads (P2) - If ItemsView loads before its ScrollView is assigned, this new early return subscribes to no event and never retries the initial tail request. The prior layout handler could revisit that state. Restore a bounded trigger for late ScrollView availability without depending on an unrelated layout event.
• Resolve merge risk (P1) - The current-head native fixture did not reliably show the final long-history row after Sessions navigation, while selected exact-base controls passed; the remaining timing or realization cause needs isolation before merge.
• Complete next step (P2) - Repair late ScrollView retry and provide redacted repaired-head native evidence resolving the differential final-row failures before merge.

Findings

• [P2] Retry when ScrollView appears after ItemsView loads — src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:155-157

Agent review details

Security

None.

Review metrics

None.

Merge-risk options

Maintainer options:

1. Repair and recheck native positioning (recommended)
   Restore a retry for late ScrollView availability and show the existing long-history native cases positioning the final row reliably on the repaired head.
2. Pause the timing change
   Keep the existing layout-event path until the native failure has a bounded explanation and a proven replacement.

Technical review

Best possible solution:

Keep load-only navigation if it can retry when ScrollView appears late, then establish reliable natural-tail placement through the existing native fixture on the repaired head.

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

Yes for the retry gap: source inspection shows that an ItemsView loaded before its ScrollView is assigned has no later trigger. The recorded native fixture reproduces missed tail visibility, but does not isolate that source path as its cause.

Is this the best way to solve the issue?

Not yet. Removing the layout wait is a reasonable narrow direction, but it needs a late-ScrollView retry and a repaired-head native result showing that the final row becomes visible.

Full review comments:

• [P2] Retry when ScrollView appears after ItemsView loads — src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:155-157
  If ItemsView loads before its ScrollView is assigned, this new early return subscribes to no event and never retries the initial tail request. The prior layout handler could revisit that state. Restore a bounded trigger for late ScrollView availability without depending on an unrelated layout event.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.89

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 0e45bb673025.

Labels

Label changes:

No label changes.

Label justifications:

• P2: The regression concern affects chat-history positioning, with a bounded UI impact and no observed process outage in the current-head fixture.
• merge-risk: 🚨 other: Merging the changed scroll timing could leave the latest chat row out of view after a session transition despite passing ordinary tests.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The current-head ARM64 native app exercised chat-history selection through the Gateway fixture and showed some successful tail checks, but Debug and Release also missed the final row where selected base controls passed. The later Release diagnostic confirms selection succeeded while the tail stayed out of view; repaired-head proof is still needed. Redact private endpoints and other sensitive details in any shared output; updating the PR body should trigger re-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

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.
• [P1] ./scripts/test-gateway-fixture.ps1 with a freshly built native app, covering long-history selection and Sessions-to-chat navigation.

What I checked:

• Introduced retry gap: The introduced method returns when ItemsView has no ScrollView, with no event subscription or scheduled retry for a ScrollView assigned later. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:155, 113416a4fbb6)
• Current-main behavior: Current main still subscribes to LayoutUpdated and retries when ScrollView is unavailable; the latest release has that path too. The proposed timing change is not already implemented. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:169, 0e45bb673025)
• Native fixture contract: The existing UI fixture checks natural visibility of message 240 before manual scrolling and checks the final marker after opening a long chat from Sessions. (tests/OpenClaw.Tray.UITests/GatewayFixtureUiTests.cs:35, 113416a4fbb6)
• Current-head native observations: The PR body reports positive ARM64 tail checks, but Debug and Release fixture runs also failed cases whose selected exact-base controls passed. A supplemental Release diagnostic recorded correct long-session selection while natural-tail visibility was false in 86 of 86 observations; the body does not establish the causal scheduling branch. (113416a4fbb6)
• Feature history: Merged PR fix(chat): stabilize bottom anchoring #1089 is the bottom-anchoring feature history; merged PR feat(chat): migrate chat surface to Reactor #1055 migrated the chat surface to Reactor. The local partial clone could not supply a reliable line-introduction comparison against raw parents. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs, ca8fb4a404ad)
• Related work boundary: The discussion distinguishes this scroll-restore change from the open anchor-crash workaround fix(chat): work around WinUI session-switch crash #1407; [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 reports a sustained history-render hang rather than this retry gap.

Likely related people:

• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Restore a retry for a ScrollView that becomes available after ItemsView loads.
• Provide redacted repaired-head native evidence that resolves the differential tail failures.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.

History

Review history (6 earlier review cycles)

• reviewed 2026-09-19T00:35:17.884Z sha f683edc :: needs real behavior proof before merge. :: none
• reviewed 2026-09-19T00:42:49.426Z sha f683edc :: needs real behavior proof before merge. :: none
• reviewed 2026-09-21T22:05:34.413Z sha f683edc :: needs real behavior proof before merge. :: none
• reviewed 2026-09-23T20:57:31.173Z sha 113416a :: needs real behavior proof before merge. :: none
• reviewed 2026-09-23T21:16:03.287Z sha 113416a :: needs real behavior proof before merge. :: [P2] Retry when ScrollView appears after ItemsView loads
• reviewed 2026-09-23T21:38:02.984Z sha 113416a :: needs real behavior proof before merge. :: [P2] Retry when the ScrollView appears after ItemsView loads

[karkarl]

Global repo triage reviewed exact head f683edcae3b4405316149980b78a28ea5f49291f.

Decision: HOLD_FOR_AUTHOR. Take confidence: 25%. Recommendation confidence: 98%. Risk: High.

I found no separate static defect in the load-only refactor, but current-head native proof is negative, and this head still relies on StartBringItemIntoView, the API #1407 removes for the confirmed anchor crash. The proof reports a blank viewport, E_INVALIDARG, zero completed switches, and process termination. Hosted Build/Test checks are also absent.

Resolve #1407 first, then rebase or redesign this timing change against the selected navigation mechanism. Add ordinary hosted CI and successful windows-winui-interactive plus windows-11-arm64 proof showing final-row visibility, repeated switching, and crash-free behavior.

[dotMorten]

Clarification: #1407 is unrelated and will be fixed by upgrading to the latest reactor version. This scroll restore issue is separate and caused by relying on LayoutUpdated delays that are unnecessary and have unpredictable timing. It is not clear from history why the LayoutUpdated code was there, but it's typically used as a "hack" to work around timing issues equivalent to using Thread.Sleep to solve threading issues. This PR cleans up the code, and I was not able to observe any regression caused by this, but it resolved the scroll restore so it now consistently scrolls to the bottom.

I tested locally on both x64 and Arm64

[shanselman]

Thanks for the clarification, Morten. I kept the scroll timing change separate from the older anchor-crash workaround and tested committed dependencies without the compatibility overlay.

Your branch was refreshed with current main by a clean ordinary merge to 113416a4fbb6d26bd3db37b065c9c0d905d52aae. The scroll controller bytes and stable author patch ID are unchanged; no semantic fix or dependency upgrade was added.

There is positive evidence: natural initial tail placement and three A/B history switches passed, and the production-shaped Release run passed both narrow and wide viewport checks. No anchor crash was observed in these bounded runs.

One result needs investigation before merge:

Existing native fixture case	PR Debug	PR Release	Exact fb8b9e7 base control
SessionPickerSwitchesRealHistoriesAndShowsMessage240AtBothWidths	Fails the final wide-width marker check	Passes	Debug passes
PopulatedPagesPreserveSelectionAndPreferencesStayInDisposableProfile	Fails “Sessions-page action routes to long chat”	Same failure	Debug and Release pass

The base controls used the same native test source and committed dependency manifests, once per configuration. The second assertion is a conjunction of the expected picker selection and final-marker viewport bounds. The Gateway successfully returned the requested long history, but the retained diagnostics do not separate the two UI predicates, so I am not claiming this is specifically a routing defect rather than tail positioning or timing.

Reproduction uses the existing scripts\test-gateway-fixture.ps1 with the actual native ARM64 Debug and non-Dev Release app paths. The focused native methods are in GatewayFixtureUiTests; Release has System.Diagnostics.Debugger.IsSupported=false. Full build, Shared (4,093 passed / 35 skipped), Tray (3,070 passed), and 25 focused presentation cases passed.

Could you look at the Sessions-page transition and the dropped/retried initial-tail request lifecycle with this differential? I am holding the merge for this current-head native result, not treating the historical overlay crash as a blocker or asserting a deterministic root cause from one run per case. The fuller commands, identities, and limitations are preserved in the updated PR body.