[RCmerci]

Acceptance blocker: visible stepping remains during long-list return-to-top. This PR does not yet meet the user's Simulator smoothness requirement.

Reselecting Journals on the active Timeline emits an OCaml-owned, token-scoped request to the existing mounted native List. SwiftUI ScrollViewReader targets a zero-height top anchor with native animation and Reduce Motion support. Scroll-only updates retain row content/identities, demand and navigation state without re-projecting every Timeline row. Favorites switching and Detail Back retain their existing behavior.

Independent review found that a future date before Today incorrectly rejected Top. The new legal future+Today native UI case reproduces the failure before the minimal guard removal, then passes after it; Capture row-target validation remains unchanged. No additional protected interface, Dune or spec changes were made beyond the already approved three-interface diff.

Validation:

• Final-head CI 39007100959 passed on 9d99fee7c16034d4f92869b87fb7a736f45e401e.
• Final @all/native build and full tests: 900 Alcotest cases plus 87 custom checks, including source boundaries. Initial sandboxed loopback-fixture failure was rerun with authorized local fixture ports; complete rerun exits 0.
• Final Release UI: three cases, zero failures (86.890s): future dates, long image attachments/repeated/already-top taps, Favorites and Detail retention. Future regression RED 28.413s; GREEN 24.355s.
• Final Reduce Motion getter fixture: one case, zero failures (17.136s); no system setting changed. Earlier independent normal UI taps began during native deceleration and retained the same collection at true top.
• Separate independent review completed; its future-date P2 was fixed. The follow-up confirms the minimal code/test fix, with the previously stale validation wording now corrected.

Performance remains failed: chronological inspection of every original animation frame in new short recordings shows intermediate positions held across multiple frames before large jumps. The no-AX-during-animation recording has major glyph-position changes separated by up to 98.334ms; display-link click-window median/p95/max are 16.666/19.338/389.937ms. The earlier 505.367ms callback gap is inside return (+0.153 to +0.658s), not a navigation boundary. These are recorded-picture and callback-delivery observations, not rendered FPS/frame time or compositor hitches. The 60Hz Simulator reports hitches unsupported. A standard SwiftUI equatable-content experiment still stepped and was reverted. Aggregated native cell sizing/SwiftUI layout/AX stacks do not establish the exact root cause; no custom scrolling coordinator has been implemented without the AGENTS-required approval.

Source/provenance: final Release executable SHA-256 426e8f8f188f1b35e91a5ecdf934a21bd93d4c491907ad82c4e69de0d18b0d45; build manifest and final source verification match all 30 shared production Swift files and 318 native sources, locked LUI 4fdb9136 and verified borrowed dependency hashes. Synthetic experimental host-restamped probe only (cross_abi_validated=false); not a full iOS cross-compilation proof. Evidence and next diagnostic/approval scope are saved outside the repository under task-9/evidence/future-fix. No real graphs, other owners' devices, phone installation or merge.

Additional timed diagnosis (production unchanged): Top signposts align a429.188ms callback gap with429ms of sampled Running main-thread time. Time Profiler Hangs independently records a396.485ms main-thread Microhang at Top+14.892ms. Proxy scrollTo itself takes0.72ms;294 rowBody calls total2.48ms and300 childContent calls1.05ms (nested timings). No Snapshot replacement occurs. Inclusive framework samples concentrate in dynamic list identity traversal and cell/layout sizing; their weights overlap. The standard concrete-row-container candidate has now been tested and discarded: it still records a343.804ms main-thread Microhang,371ms of sampled Running main-thread time inside a372.707ms callback gap, and a378.694ms callback gap in a separate no-profiler run. The same eight swipes reached different starting rows (baseline82/candidate59), so no matched-distance speedup is claimed. The companion recording has PTS regressions and is excluded from whole-movie FPS/chronological acceptance. This does not establish that a custom scrolling adapter is necessary. Production remains unchanged; the final normal Release binary and exact production source staging were restored and reverified, and the test app was terminated.

The user subsequently approved a minimal UIKit coordination trial. A weak ancestor-only UICollectionView binding did dispatch native scrollToItem (0.190ms call), but the timed return still has a366.245ms main-thread Microhang and388.092ms callback gap (381ms Running main-thread sample weight inside it). Combining the same adapter with the prior equatable content boundary reduces rowBody calls to66 but still has a344.251ms Microhang and370.431ms callback gap. An independent no-profiler/no-AX companion has a328.805ms callback gap;80 original pictures have strictly increasing decoded PTS and visible intermediate-position holds (one66.667ms hold). These do not measure rendered FPS or prove an equal-length freeze. Starting rows differ despite the same eight-swipe workflow, so no equal-distance speedup is claimed. Two component cases pass in14.397s (17 actual UIKit weak-binding/lifecycle/repeated/empty/inset checks plus Capture center/missing-target checks). The complete candidate navigation/momentum/Reduce Motion suite was not rerun after the performance gate failed. Both native candidates were discarded; no custom coordination is retained in production, and the original normal Release package/source staging were restored without launch. PR code remains9d99fee7 with its existing green CI; this trial produces no accepted code change.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-17T04:59:04.282363Z	a9c0b54	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.