Reviewed the diff + tests. The implementation is correct (I traced each test's arithmetic against computeTaskStripScrollLeft and they all hold), well-commented, and nicely covered. One thing worth discussing before merge, plus a couple of polish notes.

Worth discussing: could the platform do this for us?

The core behavior — keep a 64px clickable preview of neighbors and snap first/last tasks flush to the edge so the chevron affordance disappears — looks reproducible with native scrolling:

.tiling-layout-strip { scroll-padding-inline: 64px; }

el.scrollIntoView({ inline: 'nearest', behavior });

Tracing the cases:

• Middle, fully visible → nearest no-ops (= your return null)
• Middle, clipped → scrolls so the edge lands at the 64px padding boundary (= both branches)
• First task → left edge aligns to padding, target clamps to 0 → left affordance hidden (= return 0)
• Last task → right edge aligns to padding, clamps to max → right affordance hidden (= scrollWidth - clientWidth)

The natural scroll clamping reproduces the edge-snap requirement for free, which would remove most of the ~90 lines of math + ~150 lines of tests.

Two fair reasons you might keep the explicit version:

• scrollTo touches only the strip; scrollIntoView walks all scrollable ancestors.
• Your explicit tie-break for a task wider than clientWidth - 128px is more predictable than native nearest.

Not a blocker — just worth a deliberate "we chose explicit scrollTo because X" rather than defaulting to manual math.

Minor

• focused-panel.ts (first/last branches) — these return 0 / scrollWidth - clientWidth without the Math.min(max, Math.max(0, …)) clamp the middle branch uses. When the strip doesn't overflow, the last-task branch returns a negative target. The browser clamps it so it's harmless, but it's inconsistent with the middle path — consider clamping or short-circuiting when scrollWidth <= clientWidth.
• TASK_CLICKABLE_PREVIEW_PX = 64 — not tied to the 26px .tiling-layout-scroll-affordance width or a shared token, so it can silently drift if the affordance changes. A one-line comment relating the two would help.
• (note, not a regression) the store layer (focused-panel.ts) reaches into the DOM here. Already true of the pre-existing scrollTaskIntoView, just expanded — flagging for awareness.

Nice touches

The data-tiling-strip marker to avoid grabbing nested scrollers, the instant-first/smooth-after closure, and the precise geometry tests are all well done.

Using the native approach is fine, but I ended up combining native scrollIntoView with a small amount of manual scrolling, keeping the benefits of the manual calculation. As you noted, the second reason to keep the manual version — your explicit tie-break for a task wider than clientWidth - 128px is more predictable than native nearest — is handled by the manual path. I also kept the manual handling for snapping the last panel flush to the right edge. These two edge cases add a small amount of extra calculation, but the overall code volume is much smaller than the previous fully-manual implementation.

Regarding the concern that scrollIntoView traverses all scrollable ancestors: in practice the task panel only has one scrollable parent, .tiling-layout-strip (data-tiling-strip). I added block: 'nearest', so scrollIntoView won't move any outer container vertically; horizontally, since only .tiling-layout-strip is scrollable, inline: 'nearest' naturally aligns the task inside that single strip and won't walk up into non-scrollable ancestors.

For the three minor points:

1. The first issue you mentioned is resolved now that we use the native implementation.
2. Added sync comments at src/styles.css:995 and src/store/focused-panel.ts:3 noting that scroll-padding-inline: 64px must stay in sync with TASK_CLICKABLE_PREVIEW_PX.
3. Added a TODO at src/store/focused-panel.ts:150 flagging that this DOM side effect should eventually move out of the store layer and into the view layer (TilingLayout.tsx).

One extra note on the trade-off: normal tasks still use native scrollIntoView, relying on scroll-padding-inline to preserve the preview margins. Only very wide tasks and the last task take the manual scrollTo path — the former avoids the unpredictable edge jumping of inline: 'nearest', and the latter ensures the right edge snaps flush. This keeps the manual code limited to edge cases while letting the browser handle the common case.

Thank you very much! <3