RFC-013: Spatial Navigation Model

[floor]

RFC-013: Spatial Navigation Model

Status: Draft · Target: vlist 3.0 · Extends: RFC-012 (Logical Scroll Model)

v3 ships the 1D case only. This RFC adopts a camera/navigation model (virtualization
as a camera over a coordinate space) but its v3 deliverable is the unified 1D scroll
engine — one scroll model, no native-vs-bounded duality. 2D/Z are fenced as explicitly
future phases (§7). The model is the why; the 1D engine is the what ships.

This document merges two prior RFC-013 drafts that collided on the number: Unified Scroll
Model (bounded-only, discussion #117) and
Spatial Navigation Model (camera/frustum). Full gate-by-gate implementation detail lives
in docs/refactor/rfc-013-implementation-plan.md.

---

0. Scope fence (read first)

In v3	NOT in v3 (future phases of this RFC)
One scroll model (bounded-only); native viewport path removed	2D co-equal X/Y virtualization
A navigation engine that owns its input — scoped-minimal synthetic touch (§4, resolved)	Z / depth, 3D fly-through
Overscan reframed as a culling margin with a DOM-node cap (Phase A — back-compatible)	Frustum-3D culling shapes, spatial index
The camera vocabulary + the public 1D API, unchanged for consumers	navigateTo({x,y,z}), getCameraPosition()
Synthetic boundary = hard stop (no rubber-band); scroll-chaining passthrough	Rubber-band / spring overscroll, full iOS feel-parity

The whole RFC is unshippable if it drifts past this line. 2D/Z are sketched in §7 so the v3
engine is built without foreclosing them — not so they ship in 3.0.

---

1. Summary

RFC-012 replaced the giant physical vlist-content with a logical scroll position and a
small bounded runway. This RFC generalizes that result into one sentence:

A virtualized list is a camera over a virtual coordinate space. The viewport is the
camera's projection window. Navigation moves the camera; rendering projects the items
inside the view (plus a culling margin) into the DOM.

Scroll is 1D camera translation — one navigation mode. v3 makes that the only scroll
model (no native-vs-bounded duality) and runs it on an engine that can drive its own input,
which is what finally resolves the iOS touch-momentum problem (§4). The same engine is the
foundation 2D/Z build on later — but v3 ships 1D.

---

2. Motivation — two problems, one resolution

RFC-012 left two things unresolved, and they have the same fix:

1. The dual path. Native scroll vs bounded scroll — every plugin handles both, the test
   matrix doubles. This was the original Unified Scroll Model motivation: collapse to one
   model. (Settled; see §3.)
2. The native runway's touch story is fragile. To scroll past the bounded runway you
   rebase (shift baseOffset + write scrollTop), and writing scrollTop mid-fling kills
   iOS Safari momentum. This is concrete in today's code: runway.ts:171-196 calls
   setScrollTop() synchronously inside onScrollEvent — i.e. during an active native
   fling — with no scrollend/fling guard, and BOUNDED_RUNWAY_FACTOR = 2
   (constants.ts:90) gives only a 2× viewport runway that a fast fling exhausts in under a
   second. The Spatial draft called this out on 2026-06-07; an adversarial review (Gemini,
   2026-06-13) confirmed it is a nest of races — scrollend timing, rapid-fling runway
   exhaustion, overscroll cancellation, scroll-anchoring conflict.

Both resolve by owning the input instead of leaning on native scroll. The camera model
names why: a camera doesn't ask the browser where it is — it is the source of truth and
projects items accordingly. That reframing turns "fight native momentum" into "drive
momentum," a tuning problem rather than a race.

---

3. Settled decisions (from discussion #117 — not re-litigated)

These are fixed; reviewers should not re-open them. Detail and status in the implementation plan.

• Bounded is the only scroll model. scroll.mode is removed. Ships as vlist 3.0.
• page() stays a native-document island behind the skipDefaultScroll seam — not a
  bounded proxy. Keeps its existing ~349,525-item ceiling (not a regression). (Gate C)
• All scrollbars are virtual — a bundled, on-by-default, suppressible overlay at every
  size; AT/UX parity is a release gate. (Gate SB)
• RTL horizontal under bounded-only is fail-loud unless explicitly normalized + tested.
  (Gate RTL)
• Adapter-as-source-of-truth is a post-3.0 refactor. (Gate D)

What this RFC adds to #117 is the camera framing and the navigation-engine decision
(§4) — now resolved to scoped-minimal synthetic touch, which is how Gate B is solved.

---

4. The navigation engine — decision: scoped-minimal synthetic touch

Two engines satisfy the same camera → visible region → render contract. v3 must pick the
touch input path; everything else (wheel, keyboard, scrollbar) is already shared.

Engine	Content box	Input	Momentum	Net
A — Native runway (RFC-012 Option C)	viewport × runway	native touch + synthetic wheel	the browser's; rebasing can interrupt it	broad support; fragile on iOS
B — Synthetic (RFC-012 Option B)	exactly viewport	wheel + touch/pointer + keys, owned inertia	ours; no rebase, no scrollTop write	clean; must build inertia

The wheel/trackpad path is already synthetic — onWheelEvent (runway.ts:216-246) does
preventDefault() + setLogical(), bypassing native scroll; smoothScrollTo is synthetic;
Gate SB makes the scrollbar virtual. The only input still flowing through native scroll
(onScrollEvent, runway.ts:154-167) is touch momentum and native-scrollbar drag — and
touch momentum is exactly Gate B's pain. (The earlier "~90% synthetic" framing was imprecise:
it's true for wheel/keyboard/programmatic, not for the touch fling path, which is 100% native
today. Corrected per committee review.)

Decision: Option B, scoped to a minimal v3-sized deliverable.

B is chosen because it dissolves the entire scrollTop-mid-fling bug class rather than
managing it (A only makes the race rarer; see "A, and why not" below). The committee's
load-bearing objection was B's cost — answered by scoping B to the minimum that ships,
deferring the expensive feel-parity work:

Ships in v3 (the minimal synthetic engine):

• Content = viewport (no runway); intercept touchstart/move/end + pointer.
• Exponential-decay inertia: v(t) = v₀ · e^(−friction·t), seeded by touch-end velocity
  from the existing tracker (velocity.ts; ~16ms touchmove cadence is fine for capture).
  Position by transform via setLogical. This is ~50 lines — a known, standard model.
• Scroll-chaining passthrough (~10 lines): when logical position is at 0 or max and
  the touch delta would push past it, do not preventDefault() — let the parent scroll.
  This is the boundary-detection native scroll gives for free; without it, embedded lists trap
  the gesture.
• Boundary = hard stop (no rubber-band) in v3. Documented as a known limitation.

Explicitly deferred to post-3.0 (the "tar pit" the committee feared):

• Rubber-band / spring overscroll (the compositor-tied iOS feel).
• Full iOS-native deceleration-curve parity (v3 ships a good-enough curve, tunable on device).

Known limitations shipped honestly (not hidden):

• passive: false on touchmove opts out of compositor-thread scrolling. On low-end
  Android this can add a one-frame start latency (the JS handler must run first). Accepted
  tradeoff — the same one the wheel handler already makes (runway.ts:329).
• touch-action: none on the viewport disables browser pull-to-refresh and edge
  back/forward swipe over the list. Fine for full-page lists; for small embedded widgets it
  is a behavior change — call it out in the migration guide.
• Boundary hard-stop (above) until post-3.0 rubber-band lands.

A, and why not (kept as the documented fallback). Hardened native-runway = rebase on
scrollend (Safari 16.4+/Chrome 114+) instead of synchronously in onScrollEvent;
BOUNDED_RUNWAY_FACTOR 2 → ~50× so fling exhaustion is unreachable; abort rebase while
scrollTop ∉ [0, maxScrollTop]; keep overflow-anchor: none. It is less new code, but its
residual risk is a stall — an intermittent momentum hard-stop on iOS under scrollend
mistiming that may never fully close. We prefer B's residual (a tunable feel gap) over A's
(a catastrophic stall). If scoped-B's device validation (§8) fails feel acceptance, A is the
fallback and B becomes the first post-3.0 spatial increment.

---

5. Overscan as a culling margin (Phase A — back-compatible, v3-eligible)

Independent of the engine choice, the camera model reframes overscan as a culling
margin around the viewport — which items sit in the DOM just past the visible edges.

• Distance is the internal primitive (pixels per side), correct under variable item sizes
  where a fixed "3 items" is an inconsistent physical buffer. Drops into the existing range
  calc: indexAtOffset(camPos − margin) … indexAtOffset(camPos + viewport + margin).
• Default unit is viewport-relative (≈ 0.3–0.5 × viewport per side), auto-adapting to
  device size — consistent with RFC-012's runway-factor reasoning.
• Hard DOM-node cap (required). A viewport-relative margin over a list of tiny items can
  resolve to a huge node count, so the margin is clamped to a maxOverscanNodes budget
  (per side). The cap, not the distance, bounds the worst case — a margin that would exceed it
  is truncated. (Committee flagged the uncapped distance as a DOM-blowup risk.)
• No double-counting. overscan: 3 (item-count) and the pixel margin are not additive:
  the item-count API converts to a pixel margin (overscan × estimatedItemSize) and the range
  calc uses the single resulting band. The conversion is explicit in the implementation plan.
• overscan: 3 (item-count) stays for back-compat and a predictable DOM-node budget.
• 1D = a band on the two ends. (2D ring / 3D shell are §7, not v3.)

Back-compatible at defaults and independently useful, so it can land in v3 regardless of the
engine decision. It is also the seam through which 2D/Z later attach.

---

6. The load-bearing question — answered

The open question was the cost of Option B: a v3-sized deliverable, or a multi-quarter
feel-parity tar pit? The committee review (§12) resolved it by separating the cheap core
from the expensive feel-work (§4):

1. Is synthetic touch shippable in v3? Yes — scoped. The inertia core is a standard
   exponential-decay model (~50 lines) seeded by the existing velocity tracker. The genuinely
   hard parts the committee surfaced are handled by scoping, not heroics:
   • Scroll chaining → boundary passthrough (~10 lines): don't preventDefault() at the
     logical edge, let the parent scroll. (Was unmentioned in the prior draft — now in §4.)
   • passive:false Android jank and touch-action:none side effects → accepted,
     documented limitations (§4), not silent.
   • Rubber-band / iOS feel-parity → deferred post-3.0. This is the tar-pit risk; v3
     does not take it on. Boundary is a hard stop in v3.
2. Is A a viable fallback? Yes, and it is documented as such (§4). A's residual is a
   stall (catastrophic); B-scoped's is a tunable feel gap. We ship B and keep A as the
   fallback if device feel-acceptance (§8) fails.
3. The smaller-than-feared path to B is exactly what v3 ships (item 1). The expensive
   surface is fenced to post-3.0.
4. Lock-in: none that hurts v3. The public API (scrollToIndex / getScrollPosition,
   1D pixel-equivalent) is frozen forever (§7); choosing B now does not foreclose A as a
   fallback, since both satisfy the same camera → visible region → render contract.

Reviewers attacking this RFC should now attack the scope line in §4 — is the
deferred-vs-shipped split honest? — not whether B is "doable" in the abstract.

---

7. Fenced future phases (NOT v3 — sketch only)

Listed so the v3 engine is built without foreclosing them. None of this ships in 3.0.

Phase	Scope
F1 — 2D visible region	co-equal X/Y range computation; overscan becomes a ring (pad all four sides); per-axis virtual scrollbars. Likely defaults to the synthetic engine (native 2D would mean rebasing two axes at once).
F2 — Z / depth	a depth coordinate; culling becomes a shell (box or sphere); 3D projection; navigateTo({z}). Genuinely speculative — a model check, probably YAGNI for DOM.
F3 — Spatial index	grids stay O(1)/axis via prefix sums; free-form 2D/3D layouts (scatter, masonry-2D) may need a grid-hash / R-tree.

Public API forward-compat constraint (so v3 doesn't paint us in): scrollToIndex and
getScrollPosition (1D pixel-equivalent) stay forever; a future navigateTo /
getCameraPosition generalizes them without breaking 1D consumers.

---

8. Verification (scoped-B is the target; A is the fallback)

A layered ladder, with an honest correction from Gemini's review baked in:

Layer	Engine	Role
1 — invariants	bun test happy-dom	deterministic logic (TDD, same commit)
2 — real engines	Android Emulator (real Chrome) + iOS Simulator (real WebKit)	fast-fail filter — catch failures cheaply; does NOT certify (trackpad ≠ finger; emulator input ≠ true compositor pipeline)
3 — physical device	iPhone + Android	the gate — clears Gate B; calibrates the factor / tunes the feel

For Option A the validation target is the binary "does a scrollTop write stall
momentum?" (a stall is catastrophic). For Option B the target is feel parity (tunable) —
friendlier to validate, still device-gated.

---

9. What you lose (bounded-only, 1D)

• Native OS scrollbar for every list — the virtual overlay replaces it at all sizes (Gate
  SB). Accessibility/platform-feel parity is therefore a release gate, not a footnote.
• DevTools scrollTop is always ~0 under scoped-synthetic B (the runway-local value only
  if the A fallback ships), not the logical position. Use getScrollPosition().
• Native find-in-page / scroll-to-reveal for offscreen items — already limited by
  virtualization; not a new regression.
• page()'s ceiling stays ~349,525 items (the 16.7M px document cap) — its existing
  limit, consciously not raised.

---

10. Implementation

Full detail and live status: docs/refactor/rfc-013-implementation-plan.md. Summary of the
gate set (B's mechanism is the §4 scoped-synthetic engine):

Gate	Scope	Status
A / A′ / A″	renderers + resize + self-managed plugins routed through bounded	✅ done (54fb8f0, 283b2d5, e2ba4b0, e182f3a)
B — touch momentum	decided: scoped-minimal synthetic (§4) — ~50-line inertia + ~10-line chaining passthrough; rubber-band deferred	🔴 open — release gate; device feel-validated
C — page() island	skipDefaultScroll ⇒ no bounded handler + full-height sizing; one seam	🟡 small implementation
SB — virtual scrollbar + AT parity	overlay at every size reaches native scrollbar UX + SR parity — explicit ARIA/keyboard/focus checklist	🔴 open — ship-blocker; zero a11y today
RTL — horizontal policy	normalize scrollLeft + test, or fail-loud	🔴 open — needs policy
D — adapter as source of truth	logical state canonical, not pixel	🟡 non-blocking, post-3.0
E — flip + delete	remove scroll.mode + native viewport path	⬜ blocked on B, C, SB, RTL

Gate C — page() as a native-document island

page() keeps native document scroll behind the skipDefaultScroll seam — it never used
the native viewport handler bounded-only deletes (create.ts:757) and leaves baseOffset
at 0. Discipline: page's native-ness stays behind that one seam, never if (pageMode)
checks across the pipeline. Known limit: ~349,525-item document cap (existing, not raised).

Gate SB — virtual scrollbar + accessibility parity (ship-blocker)

Removing native scroll commits vlist to a custom scrollbar for every list — including users
who today set scrollbar: "native" (src/types.ts). Native scrollbars give free ARIA/AT
bindings and keyboard behavior; today src/plugins/scrollbar/scrollbar.ts builds track/thumb
DOM with zero of it. Making this mandatory while the replacement has no accessibility
semantics is a breaking a11y regression, so Gate SB is a hard release gate with an explicit
acceptance checklist — every box must be proven (committee: all three reviewers independently
flagged this as the ship-blocker):

• role="scrollbar" on the thumb element.
• aria-valuenow / aria-valuemin / aria-valuemax reflect logical position, updated
  per frame for sighted users but throttled for SR (e.g. settle/idle) to avoid flooding.
• aria-controls → the viewport element; aria-orientation matches the axis.
• Keyboard: PageUp/PageDown, arrows, Home/End map to logical position —
  built in, not dependent on the opt-in a11y plugin.
• Focus management: the scrollbar is reachable and operable by keyboard users.
• Pointer: drag / track-click / wheel over the scrollbar map to logical position.
• Theming + prefers-reduced-motion respected.
• scrollbar: false yields no scrollbar DOM and no a11y nodes.
• Automated acceptance tests for each of the above (SR snapshot, keyboard, pointer).
• page() carve-out: it keeps the document's native scrollbar (no virtual overlay).

Until this checklist is green, the "no native scrollbar" decision (§3) is not shippable.

Gate RTL — horizontal policy

RTL horizontal under bounded-only is broken today and must not ship silently. scrollLeft
in RTL has three incompatible behaviors across engines (negative in Firefox/Chrome,
positive-decreasing in old WebKit), and bounded applySplit (runway.ts:128-145) assumes a
simple positive offset. v3 default: fail-loud — a dev-time throw/warning for bounded
horizontal RTL. Lifting it to supported requires normalizing scrollLeft across the engine
matrix and an RTL rebase/scroll test; until then, fail-loud is the only honest option.
(With scoped-synthetic B owning position by transform rather than scrollLeft, normalization
becomes tractable post-3.0 — but v3 ships fail-loud.)

Phase D — adapter as source of truth (non-blocking)

Make ScrollAdapter canonical instead of a wrapper over pixel state. No behavior change; ships
after 3.0. New plugin work should prefer ScrollAdapter now.

Phase E — flip + delete

Once B/C/SB/RTL close: remove scroll.mode, delete the native viewport path
(src/core/scroll.ts), drop native-path scrollbar branches, remove dual-mode tests, update
docs. Net-negative lines.

---

11. Migration

For vlist users

• Remove scroll: { mode: "bounded" } from config — it's now the default and only mode.
• If using scale() (deprecated in RFC-012), remove it entirely.
• If relying on native scrollbar appearance, configure/style the scrollbar() overlay.
• Embedded/widget lists: v3 sets touch-action: none on the viewport, which disables
  browser pull-to-refresh and edge back/forward swipe over the list. Full-page lists are
  unaffected; small embedded widgets should verify this is acceptable (§4 known limitations).

For plugin authors

• Remove any scroll.mode checks.
• Use ScrollAdapter exclusively — no raw scrollTop reads for scroll position.
• Cross-axis scroll (horizontal table overflow) remains native and unaffected.
• Start now, ahead of Phase D: prefer ScrollAdapter (getLogical() /
  getPixelEquivalent() / scrollByPx()) over engineState.scrollPosition / baseOffset.
  Adapter-written code needs no change when Phase D lands; raw-pixel code will.

Semver

Major breaking change → vlist 3.0. Breaking changes:

• scroll.mode removed; scale() plugin removed.
• Native OS scrollbar no longer appears for any list — virtual overlay replaces it (Gate SB).
• getScrollPosition() on carousel returns raw logical position, not the lap-normalized value.
  (Verify before listing: carousel does not override scrollGetFn (create.ts:630), so it
  may already return raw logical — if so this is not a change and should be dropped from this
  list to avoid confusing the migration.)
• internals.ts exports reduced (legacy rendering modules deleted in RFC-012 Phase 3b).

Deprecation path (concrete). Today create.ts:190 reads rawConfig.scroll?.mode with no
warning. The last 2.x release must emit a one-time console.warn whenever scroll.mode is
set (either value), pointing to the 3.0 migration guide — so 3.0's removal isn't a silent break.

---

12. Review history

Committee (2026-06-07). GPT-5.5 / Opus 4.8 / Gemini 3.1 / Opus 4.6 (CTO): approve the
destination, reject the original "mostly deletion" framing → reframed as phased gates.

Discussion #117 (2026-06-13). Codex (GPT-5) and Gemini 3.1 independently elevated
virtual-scrollbar + accessibility parity to a release gate co-equal with Gate B (→ Gate
SB). Gate C resolved to the page-mode island (no bounded proxy). Re-verification against
staging confirmed gates A/A′/A″ landed.

Gemini's Gate B review (2026-06-13). REJECTED the native-runway-rebasing plan as a nest of
races (idle-timeout brittleness → use scrollend; rapid-fling runway exhaustion → 50×;
overscroll cancellation → guard; scroll-anchoring → overflow-anchor:none, already present).
This directly motivated §4: rather than harden native-runway indefinitely, evaluate the
synthetic engine (Option B), which the prior Spatial draft had already proposed.

Revision (2026-06-13). Merges the Unified Scroll Model and Spatial Navigation drafts;
adopts the camera framing; reopens Gate B as the §4 A/B decision (synthetic proposed); fences
2D/Z. Submitted for adversarial review of Option B's cost (§6).

Deliberative committee (2026-06-14, #117).
A three-agent local committee (Claude Opus 4.6, Codex/GPT-5, Grok) deliberated over multiple
rounds via Floor Agents. Outcome: rejected as written — destination endorsed, but: (1) the
doc described Option A as scrollend-rebasing while the code does synchronous setScrollTop
in onScrollEvent with FACTOR=2; (2) Option B was under-costed (scroll-chaining,
passive:false jank, touch-action side effects, overscroll all unaddressed); (3) Gate SB
has zero ARIA today — unanimous ship-blocker; (4) RTL and the overscan cap were unscoped.
Notably, Claude reversed approve→reject in round 2 after the code-grounded objections.
Full review record: docs/refactor/rfc-013-committee-review-2026-06-14.md.

This revision (2026-06-14). Resolves §4 to scoped-minimal synthetic touch (ships the
~50-line inertia core + ~10-line chaining passthrough; defers rubber-band/feel-parity
post-3.0; documents passive:false/touch-action limits). Corrects the Option A↔code
contradiction and the "90% synthetic" claim. Turns Gate SB into an explicit ARIA/keyboard/focus
checklist. Caps overscan distance; scopes RTL fail-loud; adds the concrete scroll.mode
deprecation. Addresses every committee objection.

---

References

• RFC-012: Logical Scroll Model — introduced bounded as opt-in
• Implementation plan (gate detail, verification ladder): docs/refactor/rfc-013-implementation-plan.md
• RFC-012 implementation review: docs/refactor/rfc-012-implementation-review.md
• Discussion: #117
• Bounded scroll implementation: src/core/runway.ts (handler), src/core/adapter.ts (ScrollAdapter)
• Gate A commits: 54fb8f0 (renderer routing), 283b2d5 (resize + page guard), e2ba4b0, e182f3a
• Bundle: base 9.7 KB gz; native-path removal ≈ −0.7 KB gz; the bounded handler (~1.1 KB) stays
• Frustum culling — the standard 3D-engine technique the overscan margin generalizes

[floor]

🏛️ Committee deliberation — RFC-013: Spatial Navigation Model

Reviewers: Claude, Codex, Grok. Up to 3 rounds; consensus = unanimous or stable.

Each reviewer posts below. Round 2+ reviewers respond to each other and may revise their vote.

[floor]

✅ APPROVE · Claude — Round 1

Committee Member: Claude

---

Verification of RFC claims against the codebase

1. scrollTop mid-fling rebase — RFC §2 claim verified

The RFC states runway.ts:171-196 calls setScrollTop() synchronously inside onScrollEvent with no scrollend guard. Confirmed:

• onScrollEvent() at runway.ts:154-167 calls maybeRebase(top) at line 163.
• maybeRebase() at runway.ts:171-196 calls setScrollTop() at lines 181, 195 — synchronously, inside the passive scroll listener.
• No scrollend event, no fling-detection guard, no debounce. The rebase fires whenever scrollTop crosses the 25%/75% thresholds (BOUNDED_REBASE_LOW/HIGH at constants.ts:109,115).
• BOUNDED_RUNWAY_FACTOR = 2 (constants.ts:90) — a 2× viewport runway. On a 900px viewport that's 1800px of content, ~900px of native travel. A fast touch fling absolutely exhausts this in under a second.

The RFC's characterization of this as a race condition is accurate. Writing scrollTop mid-fling on iOS Safari kills compositor-driven momentum. This is the core defect that motivates the engine change.

2. "Wheel is already synthetic" — verified with correction

The RFC claims the wheel path is already synthetic. Confirmed for the bounded handler: onWheelEvent (runway.ts:216-246) does event.preventDefault() + setLogical(), bypassing native scroll entirely. The native scroll.ts wheel handler (scroll.ts:64-101) does write scrollTop/scrollLeft directly, but that handler is only used in the non-bounded (native) path.

The RFC's correction that "touch momentum is 100% native" is honest — onScrollEvent (runway.ts:154-167) is registered { passive: true } and flows through native scroll. Touch is the only input that still hits the rebase path.

3. Dual path cost — verified

create.ts:190 reads rawConfig.scroll?.mode === "bounded" into boundedMode. Lines 601-643 branch: bounded → createBoundedScrollHandler, else → createScrollHandler. Two entirely separate scroll handler implementations (runway.ts vs scroll.ts). Every plugin that cares about scroll mechanics must handle both. Collapsing to one model is architecturally justified.

4. Gate SB — zero ARIA today — verified, this is the real ship-blocker

Grep for role, aria-, tabindex, focus across src/plugins/scrollbar/ returns zero matches except one unrelated comment about keyboard repeat delay. The scrollbar creates bare div elements (scrollbar.ts:224-227) with no semantic attributes. The RFC's ARIA/keyboard/focus checklist is not aspirational — it's describing work that does not exist at all today. Making this the only scrollbar while it has no accessibility semantics is indeed a breaking a11y regression.

5. Velocity tracker — usable for inertia seeding, but needs direction

velocity.ts:43 computes Math.abs(newPosition - lastPos) / dt — it discards direction. For the synthetic inertia engine (§4), the touch-end velocity must be signed to know which direction to coast. The tracker is close to usable but needs a one-line fix: drop the Math.abs() and let the consumer take the absolute value if needed. The RFC says "seeded by the existing velocity tracker" — this works only after that fix. Minor, but worth noting explicitly in the implementation plan.

6. page() island via skipDefaultScroll — verified

create.ts:601-604 throws if skipDefaultScroll && (boundedMode || boundedWrap). create.ts:757 gates scrollHandler.attach() on !skipDefaultScroll. The page() plugin calls disableDefaultScroll() during setup (create.ts:417), so it never gets a bounded handler today. The "island" architecture already has its seam. Gate C is correctly scoped as small implementation work — page() just needs to keep working with the native viewport handler deleted, which means keeping the skipDefaultScroll codepath alive.

7. scrollbar: "native" exists in the public API — verified

types.ts:359-366 documents scrollbar?: "native" | "none" | ScrollbarOptions. Users who set scrollbar: "native" today will lose that option. The migration guide mentions this but should be louder — it's a config value that will silently stop working unless there's a deprecation warning in the last 2.x release (as proposed for scroll.mode at §11).

---

Correctness issues

Issue 1: Scroll-chaining passthrough is underspecified for the boundary transition. The RFC says "when logical position is at 0 or max and the touch delta would push past it, do not preventDefault()." But: if the user is mid-fling and hits the boundary, you've already been calling preventDefault() on every prior touchmove. Stopping preventDefault() partway through a gesture sequence does not re-enable native scrolling on the parent — the browser has already committed the gesture to the inner element. You would need to fully release the touch (no preventDefault() from touchstart) for the parent to pick up the gesture. This is a known limitation of touch event interception that affects libraries like Hammer.js and every custom scroll implementation. The ~10-line estimate for scroll chaining is too optimistic; the real solution likely involves either:

• Letting the first touchmove through without preventDefault() (using a brief look-ahead to decide whether to intercept), or
• Accepting that mid-fling chaining doesn't work (document it as a limitation alongside "no rubber-band").

This needs resolution before Gate B closes.

Issue 2: The velocity tracker loses sign. As noted above, velocity.ts:43 uses Math.abs(). The synthetic inertia engine must know direction. Trivial fix but must be called out since the RFC claims the existing tracker is directly usable.

---

Architecture fit

The camera/navigation model is a clean conceptual frame that fits the existing architecture well. The ScrollAdapter (adapter.ts) already abstracts pixel ↔ logical conversion — it's the right seam for the synthetic engine to plug into. setPixel / getPixel in the adapter config (adapter.ts:66-70) can point at the synthetic position state instead of DOM scroll properties.

The proposal to keep scrollToIndex / getScrollPosition (1D pixel-equivalent) frozen while future navigateTo generalizes them is the right API stability decision.

Plugin impact is minimal: plugins already go through PluginContext.scrollAdapter or scrollTo / getScrollPosition. Removing the native path means they stop worrying about scroll.mode branching. Net simplification.

---

Performance

The synthetic touch engine adds touchstart/move/end listeners with passive: false and a rAF inertia loop. This is the same pattern as the existing smoothScrollTo rAF loop (runway.ts:285-298) — no new architectural overhead. The inertia tick is one exponential decay + one setLogical call per frame, which is already what smoothScrollTo does.

The passive: false on touchmove is honestly documented. It pulls touch handling off the compositor thread. On modern devices this is a ~1 frame penalty. The wheel handler already does this (runway.ts:327, { passive: false }). Consistent tradeoff.

The overscan DOM-node cap (maxOverscanNodes) is a necessary addition the RFC correctly identifies. Without it, viewport-relative overscan on a list of 10px items could resolve to hundreds of DOM nodes. The cap is a per-side bound, not a per-frame computation — no hot-path cost.

---

Gaps

1. Scroll-chaining mid-gesture (detailed above) — the "~10 lines" claim is wrong. This needs a design decision, not just code.

2. scrollbar: "native" deprecation — §11 mentions deprecating scroll.mode with a console.warn in the last 2.x, but doesn't extend the same treatment to scrollbar: "native". Both should warn.

3. Carousel interaction with synthetic touch — the carousel uses boundedWrap (create.ts:607) and today relies on native touch for swipe. Under synthetic touch, carousel swipe must be re-tested. The RFC doesn't mention carousel as a verification target in §8 Layer 1-3.

4. smoothScrollTo during inertia — if scrollToIndex is called while synthetic inertia is active, who wins? The existing cancelScroll() pattern (runway.ts:259-264) handles this for rAF animations, but the inertia loop needs the same cancel-on-programmatic-scroll contract. Should be explicit.

5. Multi-touch — the RFC says "intercept touchstart/move/end" but doesn't address pinch-to-zoom or multi-finger gestures. These should pass through (don't intercept when event.touches.length > 1). One line, but if omitted it breaks zoom on mobile.

---

Assessment

The destination is correct: collapsing to one scroll model eliminates a real dual-path maintenance burden, and the synchronous setScrollTop mid-fling is a genuine defect that Option B dissolves rather than manages. The scope fence (no rubber-band, no 2D, hard-stop boundaries) is honest and appropriate for a v3 deliverable.

Gate SB is the hard part of this RFC — not Gate B. The inertia engine is ~50 lines of standard physics. Building a fully accessible virtual scrollbar from the current zero-ARIA state is the real engineering effort, and the checklist in §10 is the right way to gate it.

The scroll-chaining underspecification is the one correctness issue that could blow the "~10 lines" cost estimate. It needs a concrete design (look-ahead vs. documented limitation) before implementation begins.

VOTE: APPROVE — with conditions:

1. Resolve scroll-chaining mid-gesture semantics before Gate B implementation begins. The "don't preventDefault() at the edge" approach doesn't work mid-fling. Either design a look-ahead heuristic or document mid-fling chaining as a known limitation alongside "no rubber-band."
2. Fix velocity.ts:43 to preserve sign (drop Math.abs()). The synthetic engine needs directional velocity.
3. Add scrollbar: "native" to the deprecation warning plan in the last 2.x release, alongside scroll.mode.
4. Add carousel to the verification ladder (§8) — wrap-mode + synthetic touch is an untested combination.
5. Specify multi-touch passthrough — don't intercept when touches.length > 1.

[floor]

❌ REJECT · Codex — Round 1

Committee Member: Codex

Reject as written. The destination is reasonable: one logical scroll source, bounded-only, virtual scrollbar parity, and no native-vs-bounded split. The proposal still underestimates migration risk and implementation scope in the current codebase.

Required issues to resolve:

• Synthetic touch is not a ~60-line change. Current bounded mode still depends on native scroll events and rebases by writing scrollTop/scrollLeft during handling: runway.ts, runway.ts, runway.ts. Replacing this means defining touch lifecycle, pointer identity, cancellation, axis locking, nested scroll handoff, programmatic scroll interruption, resize during inertia, and interaction with smooth scrolling. The RFC does not specify those invariants.

• The “existing velocity tracker” is not suitable for touch inertia. It stores absolute velocity only, derived from scroll positions, with no sign, no per-touch samples, no axis data, and no last-event timestamp exposed for touch-end seeding: velocity.ts, velocity.ts. Direction can be inferred elsewhere, but that is not enough for reliable fling handoff or cancellation.

• Virtual scrollbar is a blocker and also a larger architecture change than stated. The current scrollbar DOM has only classes, track/thumb elements, pointer/touch handlers, and transform updates: scrollbar.ts, scrollbar.ts, scrollbar.ts. No ARIA, no keyboard operation, no focus model. Also, createVList does not instantiate the scrollbar plugin from scroll.scrollbar; it only handles "none"/gutter classes: create.ts. “Bundled, on-by-default” requires a plugin lifecycle/API change, not just improving the existing plugin.

• Cross-axis scroll is not unaffected. Vertical table mode uses native viewport.scrollLeft for horizontal column scrolling and header sync: table/plugin.ts, table/plugin.ts, table/plugin.ts. A viewport-level touch-action: none plus synthetic touch interception can break mobile horizontal panning unless the engine defines axis-gated default prevention.

• Plugin migration is understated. Bundled plugins still read or mutate engineState.scrollPosition, baseOffset, and raw viewport scroll properties in many places: a11y scroll-into-view, snapshots, sortable ghost math, transitions, table, carousel, groups, masonry. The RFC tells third-party authors to move to ScrollAdapter, but the built-ins are not there yet. This is a compatibility migration, not only a public docs note.

• Overscan-as-distance is underspecified for current internals. The hot range calculation is item-count based and capacity sizing also assumes item-count overscan: pipeline.ts, pipeline.ts, pipeline.ts. A pixel margin with node cap needs exact rules for variable-size lookup, cap truncation direction, buffer resizing, and plugins that independently compute overscan windows.

• Page mode carve-out is not closed. Current code explicitly throws for page() plus bounded/wrap: create.ts. Keeping page as a native island is acceptable, but the proposal needs the actual API/handler path that prevents bounded-only deletion from breaking this seam.

• Performance claims need measurement targets. Synthetic touch moves main-axis scrolling from compositor/native momentum to JS touchmove plus rAF. The RFC acknowledges latency but does not define frame-budget metrics, allocation checks, or device acceptance thresholds. “Tunable feel gap” is not a performance argument.

• The checkout does not match the proposal context: git status reports rfc-013-unified-scroll, not staging, and CLAUDE.md plus the referenced docs/refactor RFC files are absent in this working directory. The proposal depends on artifacts I cannot verify here.

Approve only after the RFC adds a concrete synthetic-input state machine, built-in plugin migration plan, virtual scrollbar integration/a11y design, cross-axis policy, overscan algorithm, and measurable browser/device gates.

VOTE: REJECT

[floor]

❌ REJECT · Grok — Round 1

Committee Member: Grok

Soundness. The reframing (virtualization = camera at logical position; viewport = projection; overscan = culling margin around the frustum) is a correct description of the bounded path already in runway.ts:13-27 and pipeline.ts:110-128. Logical = baseOffset + scrollTop (runway.ts:156), items rendered at offset - baseOffset, range computed as indexAtOffset(scrollPos - margin) ... indexAtOffset(scrollPos + vp + margin) via sizeCache. The unification claim is also sound in principle: the dual paths (createScrollHandler in scroll.ts:50-60 vs. createBoundedScrollHandler in runway.ts:154-167) force every plugin and the test matrix to carry "baseOffset is 0 in native mode (byte-identical)" branches. Removing the native viewport handler after input ownership is solved eliminates that.

The root cause diagnosis in §2 is correct and evidenced in code: maybeRebase (runway.ts:171-196) does state.baseOffset = ...; setScrollTop(...) synchronously inside onScrollEvent (154-167), which receives the passive scroll events from touch momentum and native scrollbar drag. With BOUNDED_RUNWAY_FACTOR = 2 (constants.ts:90) the runway is 2× viewport (clamped), so a fast fling exhausts the headroom and forces rebase while the compositor is still driving velocity. Wheel is already synthetic (runway.ts:243-244: preventDefault + setLogical); only the touch-fling path remains native. The camera model makes the fix directionally right: the engine becomes source of truth and projects, rather than rebasing under a browser-driven fling.

Bounded vs. unbounded. Scoped Option B (synthetic touch with exponential decay inertia seeded from velocity, ~10-line scroll-chaining passthrough by not preventDefault at logical 0/max, hard stop, no rubber-band) is a hard, finite problem. The inertia core is standard math (v(t) = v0 * e^(-k t), rAF driver calling setLogical). The tar pit (compositor-tied spring overscroll, exact iOS deceleration curve parity, full feel replication) is correctly fenced to post-3.0. Gate SB (mandatory virtual scrollbar + AT parity) is also bounded if treated as a checklist that must be implemented before the native path is deleted, not after. RTL normalization and the overscan distance + maxNodes cap are finite once the policy is chosen.

Performance. Current hot paths are allocation-free by construction: onScrollEvent and maybeRebase do only number math + state mutation + one scrollTop/scrollLeft write; phase1Calculate (pipeline.ts:144-149) fills pre-sized TypedArrays (visibleIndices/Offsets/Sizes) with a bounded for-loop (capacity ≈ ceil(vp / minItem) + overscan*2); sizeCache uses Float64Array prefix sums + binary search (rendering/sizes.ts:121-141) with getSize/getOffset (dimension-agnostic). No .map/.filter/spread on the scroll or render frame. Synthetic adds one rAF inertia loop only while flinging (identical cost class to the existing smoothScrollTo in runway.ts:284-298). Passive:false on the future touchmove listener adds the same main-thread-before-compositor tax the wheel handler already pays (runway.ts:327). The residual cost is therefore known and acceptable under the stated constraints.

Cross-browser reality. iOS Safari fling is the exact case the rebase races: the browser applies momentum on the compositor after the initial gesture; a main-thread setScrollTop during an active scroll event can stall it. Synthetic owns the position via transform updates, eliminating the write. Trade-offs are real and called out: passive:false on touchmove produces one-frame start latency on low-end Android (same as wheel); touch-action:none on the viewport disables pull-to-refresh and edge swipes over the list. These are observable on physical devices, not spec. RTL scrollLeft (negative in Firefox/Chrome, inverted-decrement in old WebKit) is unhandled in applySplit (runway.ts:142-144) and get/setScroll* — current bounded horizontal will produce wrong baseOffset/scrollTop splits. page() correctly remains a window-scroll native island via skipDefaultScroll + setScrollFns (page/plugin.ts:56-87, create.ts:601-604); it never used the viewport handler being deleted.

Decisiveness. The smaller version that is right is exactly the scoped v3 deliverable in the fence (§0, §4, §6): (1) minimal synthetic touch engine (direct touchmove/pointer sampling at gesture cadence to feed a velocity tracker, exponential decay rAF driver, boundary passthrough, hard stop); (2) Gate SB implemented and proven (ARIA roles/values, keyboard PageUp/Down/Home/End/Home, focus, SR-throttled updates, pointer/keyboard/automated tests) before any native scrollbar removal or "always virtual" default flip; (3) RTL horizontal under bounded fails loud with a dev-time diagnostic + matrix test until normalization lands; (4) overscan evolves to px culling margin + maxOverscanNodes cap while the item-count form remains back-compat and the cap is enforced in phase1; (5) deprecation warning on scroll.mode in the last 2.x; (6) delete the native handler, dual branches, and mode checks only after B/SB/RTL/C close (Phase E); (7) page() seam untouched. 2D/Z and rubber-band stay explicitly post-3.0. Do not ship until physical iPhone + Android device feel gates and a11y acceptance are green.

Specific issues that must be resolved (ordered by severity):

1. Gate SB is a hard ship-blocker with zero current surface. scrollbar.ts (setupDOM, handleThumb*, no role/aria-valuenow/aria-valuemin/aria-valuemax/aria-controls/aria-orientation anywhere, thumb not focusable, no keyboard listeners for PageUp/Down/arrows/Home/End on the bar) provides only visual + pointer drag. Making the custom overlay mandatory while the replacement has no semantics is an a11y regression for every list. The explicit checklist must be implemented + tested (SR snapshots, keyboard, pointer) before the "no native scrollbar" decision is enacted.

2. Velocity seeding claim does not match code. velocity.ts + updateVelocityTracker (called from doScrollFrame at create.ts:502) samples logical scrollPosition at frame rate after the fact. Seeding fling inertia at touchend requires finger velocity captured from the high-rate touchmove events themselves (delta/ dt on the gesture before release). The existing tracker cannot be used as-is; a gesture sampler must be added. Mismatch between proposal text and implementation is load-bearing for "good enough" feel.

3. Synthetic touch driver does not exist. No viewport-level touchstart/move/end or pointer listeners, no non-passive touchmove path, no per-gesture velocity sampling, no decay loop, no chaining passthrough logic. The "~50 + 10 lines" surface is plausible for the math but the full contract (multi-touch, cancel, integration with wheel/smooth/keyboard/virtual scrollbar, setLogical without alloc, content=viewport sizing or equivalent transform camera, touch-action:none + passive:false side effects wired and documented) is absent. The driver must be written and hot-path validated (zero alloc, TypedArray state) before native onScrollEvent removal.

4. Dual-path and plugin branching are still live. create.ts:190 (boundedMode = rawConfig.scroll?.mode === "bounded"), 607-643 (two handler creations), 525-528 (syncContentSize), runway.ts:325 (attach still passive scroll), and pervasive baseOffset conditionals in groups/table/masonry/grid/carousel renderers are not "done." Gate A status in the RFC does not match tree state; Phase E deletion will be a larger diff than described and must carry its own test rewrites.

5. Overscan remains item-count only; the px culling margin + hard DOM-node cap is not present. pipeline.ts:127-128 and state.ts:103-106 hard-add overscan*2 to capacity; constants.ts:11 is OVERSCAN=3. A viewport-relative distance over tiny items produces unbounded nodes unless clamped by maxOverscanNodes. The migration (item-count converts to px band, cap wins) and back-compat must be implemented and capacity calc updated before the "culling margin" language is treated as shipped.

6. RTL horizontal policy and normalization are absent. runway.ts applySplit and get/setScroll* assume LTR-positive offsets. No detection, no normalization of scrollLeft, no fail-loud. Bounded horizontal RTL is broken today; the RFC correctly says it must not ship silently, but the mechanism (throw/warn + test) is not in the tree.

7. scroll.mode deprecation warning is missing. create.ts:190 reads it with no console.warn. Last 2.x release must emit the one-time warning per §11.

8. Referenced docs are not in tree (docs/refactor/rfc-013-implementation-plan.md, committee review notes). The proposal's gate status and verification ladder cannot be fully audited from the workspace.

The physics supports owning input. The math for scoped inertia is standard. The residual risks (tunable feel gap vs. stall, a11y surface to build, device matrix) are correctly distinguished from unbounded ones. The proposal as written contains multiple claim-vs-code gaps on the critical path items and treats several prerequisites as "small implementation" when they are release gates. A smaller, approvable version is the one listed under Decisiveness.

VOTE: REJECT

[floor]

❌ REJECT · Claude — Round 2

Now I have enough code context. Let me formulate my review.

Committee Member: Claude

---

Round 2 — Position revision

In round 1 I approved; Codex and Grok both rejected with code-grounded objections. Having re-read the source, I hold my revised position from the deliberative committee review (cited in §12): reject as written, endorsing the destination.

The other reviewers' objections are substantively correct and I won't relitigate them. I'll state concisely where I agree, where I differ, and add one issue neither raised.

---

Where Codex and Grok are right (I concur)

1. Velocity tracker cannot seed touch inertia. velocity.ts:43 computes Math.abs(newPosition - lastPos) / dt — unsigned magnitude only, no direction, sampled from state.scrollPosition at frame rate via doScrollFrame (create.ts:502). The RFC claims the "existing velocity tracker" seeds the exponential-decay fling. It cannot: you need signed per-touch-event velocity from touchmove deltas, not unsigned post-hoc scroll-position diffs. This isn't a minor gap — it's the correctness of the inertia handoff.

2. Gate SB is zero-surface today. I verified: scrollbar.ts has no role, no aria-*, no tabindex, no keyboard listeners on track or thumb. The grep for ARIA attributes in the scrollbar plugin returned zero matches. Making this the only scrollbar for every list is an a11y regression until the full checklist ships. Both reviewers flagged this; I agree it's the primary ship-blocker.

3. "~50 + 10 lines" undersells the touch driver. The math is ~50 lines, yes. But the contract includes: multi-touch rejection, pointercancel handling, axis locking (user starts diagonal — which axis wins?), interaction with ongoing smoothScrollTo animations (runway.ts:266-298 — must cancel on touch), resize during inertia, and integration with the scrollbar plugin's own touch handlers (scrollbar.ts:571-597 — thumb drag via touchstart/move/end on the thumb element, which must not conflict with the viewport-level touch interception). None of this is specified.

4. Cross-axis table scroll. Codex's point stands: table/plugin.ts:354-358 reads dom.viewport.scrollLeft for header sync via a passive scroll listener on the viewport. With touch-action: none on the viewport, horizontal panning over a table becomes impossible unless the synthetic engine implements axis-gated preventDefault — which the RFC does not specify. This is a concrete regression for the table plugin on mobile.

5. Plugin migration is real work. 16 plugin files reference baseOffset or scrollPosition directly. The RFC's migration section tells third-party authors to use ScrollAdapter, but the built-in plugins haven't migrated. This is load-bearing for Phase E (delete native path) — you can't delete the dual branches while built-in plugins still read raw state.

---

Where I differ from the other reviewers (minor)

Grok's item 4 (dual-path and plugin branching "not done"). Grok says Gate A status doesn't match tree state. The RFC explicitly marks Gates A/A′/A″ as done and lists commits. The remaining dual-path code (create.ts:190, 607-643) is Phase E, which is correctly marked ⬜ blocked on B/C/SB/RTL. The RFC isn't claiming Phase E is done — it's claiming the prerequisite plugin routing is done. This is internally consistent; the objection conflates two phases.

Codex's "checkout does not match" point. This is a process observation, not a technical objection to the RFC's content. The branch name rfc-013-unified-scroll is where you'd expect the RFC document to live.

---

One issue neither reviewer raised

smoothScrollTo cancellation under synthetic touch. Today, smoothScrollTo (runway.ts:266-298) runs a rAF loop calling applySplit + onFrame. A new touch gesture during a smooth scroll must cancel it (the user is taking over). With native scroll, this happens implicitly — native touch scrolling overrides any programmatic animation. With synthetic touch, the engine must explicitly call cancelScroll() on touchstart. But the RFC doesn't specify this interaction, and today cancelScroll is only called by smoothScrollTo itself (on re-entry) and detach. If the synthetic touch driver and the smooth-scroll animation both call applySplit on the same frame, position will jitter. This needs to be in the touch driver contract.

---

The scope line (§6's challenge to reviewers)

The RFC asks reviewers to attack whether the deferred-vs-shipped split is honest. It is mostly honest, with one exception: scroll chaining is not "~10 lines." The boundary passthrough ("don't preventDefault() at logical 0/max, let the parent scroll") must handle the case where the user starts a gesture mid-list, scrolls to the boundary, and then the remaining momentum should chain to the parent. That's a mid-gesture handoff — you're switching from preventDefault() to not-preventDefault() partway through a touch sequence. Once you've called preventDefault() on any touchmove in a gesture, some browsers won't restore native scrolling for the parent until the next touchstart. This means the "~10 lines" passthrough may need to avoid preventDefault() entirely for the first few events until axis intent is determined, adding an axis-lock phase to the touch driver. This is tractable but not trivial, and it's not called out.

---

Summary

The destination (one scroll model, camera framing, bounded-only) is correct. The RFC's analysis of the rebase race in runway.ts:171-196 with BOUNDED_RUNWAY_FACTOR = 2 is accurate and the synthetic engine is the right fix. But the RFC has:

1. A load-bearing factual error (velocity tracker can seed inertia — it can't, velocity.ts:43 is unsigned/frame-rate)
2. An unspecified interaction (synthetic touch vs. smoothScrollTo cancellation)
3. An underscoped contract (touch driver: axis lock, multi-touch, pointercancel, scrollbar thumb conflict, table cross-axis)
4. A ship-blocker with zero implementation (Gate SB ARIA)
5. A scroll-chaining complexity the "~10 lines" estimate elides

Items 1-3 and 5 can be resolved by adding a synthetic touch state-machine spec to the RFC (not code — a spec, with states and transitions). Item 4 is acknowledged but needs to remain a hard gate.

VOTE: REJECT

Conditions for approval: (a) replace the velocity-tracker-seeding claim with a touch-gesture velocity sampler spec; (b) add a touch-driver state machine covering axis lock, cancel, smooth-scroll interruption, scrollbar thumb coexistence, and table cross-axis passthrough; (c) revise the scroll-chaining estimate to account for mid-gesture handoff and preventDefault stickiness; (d) Gate SB remains a hard gate (already stated — just confirming).

[floor]

❌ REJECT · Codex — Round 2

Committee Member: Codex

The other reviewers’ objections move this to reject. The direction is sound: the iOS momentum defect is real. runway.ts computes logical position from native scroll, then maybeRebase can synchronously write scrollTop during the same passive scroll event. With BOUNDED_RUNWAY_FACTOR = 2 in constants.ts, fast touch momentum can hit the rebase zone quickly. Collapsing native/bounded also removes real branching in create.ts.

The proposal still under-specifies the parts that decide whether v3 breaks users.

Blocking issues:

1. Scroll chaining is not a 10-line edge check. If synthetic touch has already called preventDefault() during a gesture, the browser generally will not transfer that same gesture to the parent when the inner list reaches 0 or max. touch-action: none also conflicts with “let parent scroll at boundary.” Embedded lists can become gesture traps.

2. The velocity tracker is not directly usable. velocity.ts stores absolute velocity from frame-level scroll position, not signed finger velocity from touchmove. Synthetic inertia needs a gesture sampler, direction, cancellation, and filtering.

3. The synthetic engine surface is larger than the RFC admits: it must coordinate with smoothScrollTo, wheel, keyboard, virtual scrollbar drag, carousel wrap, multi-touch, touchcancel/pointercancel, horizontal mode, and autosize/sortable touch users. That is not just the exponential decay loop.

4. Gate SB is a hard ship-blocker. scrollbar.ts creates bare divs; there is no role="scrollbar", ARIA value state, focusability, or keyboard handling. Making this mandatory regresses users who currently depend on native scrollbar semantics.

5. scrollbar: "native" needs the same deprecation path as scroll.mode. It is public in types.ts, but the RFC only makes the scroll.mode warning concrete.

6. Overscan-as-culling-margin is not “drop-in.” Current core and plugins use item-count overscan independently, e.g. pipeline.ts, grid/groups/table/tree paths, and masonry already uses px. The proposal needs range semantics and cap behavior across all renderers.

7. RTL fail-loud needs a precise enforcement point and tests. Raw scrollLeft remains in core and plugins, including table header sync, so “cross-axis remains native and unaffected” is not proven.

8. Referenced docs/refactor/rfc-013-implementation-plan.md is absent in this checkout, so the claimed gate detail cannot be audited locally.

The architecture is acceptable only after those decisions are made concrete. As written, it endorses a rewrite of the input model while still hand-waving browser gesture ownership, mandatory scrollbar accessibility, and cross-plugin migration.

VOTE: REJECT

[floor]

✅ APPROVE · Grok — Round 2

Committee Member: Grok

Soundness. The camera model is correct from first principles. A virtualized scroller maintains a logical (or camera) position as source of truth; the render pipeline projects a culling window of items via indexAtOffset(cam ± margin) into pooled DOM nodes with offsets getOffset(i) - base (or equivalent). This matches the existing ScrollAdapter (src/core/adapter.ts:169), EngineState.scrollPosition + baseOffset split (state.ts:35,46), and phase1Calculate (pipeline.ts:120). RFC-012's runway was an approximation that still relied on a native scroller as position source; full ownership removes the rebase races. The "one model" decision follows directly: dual createScrollHandler (scroll.ts:40) vs createBoundedScrollHandler (runway.ts:100) forces every plugin and test to branch on scroll.mode (create.ts:190,607). Collapsing is net-negative and eliminates the source of the setScrollTop mid-event writes.

The core defect (verified). runway.ts:154 (onScrollEvent) does:

const top = getScrollTop();
...
maybeRebase(top);  // 163

maybeRebase (171) computes low/high = maxScrollTop * (0.25|0.75), then on threshold cross does state.baseOffset = ...; setScrollTop(...) (195) synchronously. BOUNDED_RUNWAY_FACTOR = 2 (constants.ts:90) yields maxScrollTop ≈ viewport for long lists. A fling at 1200 px/s exhausts the runway headroom in <1 s. Scroll events during compositor fling are delivered; the write interrupts momentum on iOS WebKit (and can on Chrome under load). No scrollend, no velocity guard, no if (scrollDirection && !idle). Tests (runway.test.ts:265) assert the desired idle-only behavior; the source still executes the sync path. The RFC's characterization is accurate.

Performance numbers (real constraints). 60 fps = 16.7 ms frame budget. Hot path today (onScroll + onFrame + phase1 + phase2) must allocate zero and avoid map/filter/spread per library rules. Current onScrollEvent + maybeRebase is a few comparisons + one DOM write + state mutations into existing TypedArrays — acceptable. Synthetic inertia tick (rAF) will be one v *= Math.exp(-f*dt), one pos += v*dt, one setLogical (which does applySplit + onFrame). That is shippable if the tick object is a flat struct reused across frames (current smoothScrollTo in runway.ts:285 already does a closure-based rAF; the new path must not regress). passive:false on touchmove (required to own the gesture) pulls the start of the sequence off the compositor thread. Wheel already pays this (runway.ts:327). On low-end Android the first move can add ~1 frame before the JS handler runs and the visual response begins. Quantified and accepted in the RFC; not hidden.

Bounded vs. unbounded. Hard (shippable): (1) replace native touch path with owned touchstart/move/end + pointer fallback, (2) exponential inertia seeded from velocity, (3) hard boundary stop, (4) wheel/keyboard/programmatic already synthetic so share the driver, (5) maxOverscanNodes cap on the culling margin. Unbounded (tar pit): exact iOS deceleration curve + rubber-band spring that matches compositor feel across devices and speeds. The RFC correctly fences the latter to post-3.0 and ships "good-enough tunable curve + hard stop". Overscan-as-pixel-distance + node cap is also hard once the conversion rule and truncation direction are specified; the current item-count overscan (pipeline.ts:127, OVERSCAN=3 in constants.ts:11) + crude maxRender safety cap already exists.

Cross-browser reality. iOS Safari is the strictest on fling interruption and gesture ownership. Android Chrome is more tolerant of late scrollTop writes but still applies main-thread costs for passive:false. Simulators (Layer 2) are useful for fast logic fail but do not reproduce finger fling physics or compositor handoff; physical devices are the only gate for Gate B and SB. touch-action:none on the viewport (required for full ownership) disables pull-to-refresh and edge swipes over the list — real behavior change for embedded widgets, correctly called out.

Scroll chaining (the physics the RFC understates). Once preventDefault() has been called on a touchmove for a given touch ID, the browser has committed the gesture to that target for the remainder of the sequence. "Stop calling preventDefault when logical is at 0/max" does not hand the remainder of an active fling to the parent scroller. This is not a spec idealization; it is observed behavior in WebKit and Blink for nested scrollers. The "~10 lines" estimate and "just don't PD at the edge" description are incorrect. Real options are (a) look-ahead on the first 1-2 moves (compute intended delta sign before first PD decision), (b) always intercept and synthesize parent chaining via wheel events or parent scrollBy (fragile), or (c) ship the limitation explicitly ("embedded lists trap at bounds until finger lift"). This is a hard problem with a binary decision, not unbounded.

Velocity tracker (code fact). velocity.ts:43 does Math.abs(newPosition - lastPos) / dt. Inertia seeding requires signed velocity for direction. Trivial one-line fix, but the RFC's claim that the "existing tracker" is directly usable is imprecise.

Gate SB (the real ship risk, not Gate B). Removing the native scrollbar for all lists (types.ts:366 still documents scrollbar?: "native") while the only implementation (src/plugins/scrollbar/scrollbar.ts) creates bare divs with zero role, aria-*, tabindex, or keyboard handlers is a breaking a11y regression. Grep for role=|aria-|tabIndex|onkeydown|focus in that file yields only a comment about keyboard repeat delay. create.ts:220 only special-cases "none"; it does not auto-instantiate the plugin from scroll.scrollbar. The explicit checklist in the RFC is necessary and correctly scopes the work (throttled aria-valuenow, built-in PageUp/Down/Home/End, focus model, prefers-reduced-motion, scrollbar:false produces no nodes, page() carve-out keeps native). This is larger than "improve the existing plugin" — it is component + integration + test surface. Treating it as a checklist gate is the right call; under-estimating its size is not.

Overscan change. Current is item count (pipeline.ts:127). Pixel margin + maxOverscanNodes per side is the correct physical primitive for variable sizes and is back-compat if the item-count form is converted to pixels at the seam. The cap must truncate the computed range (not just the distance) to bound DOM nodes when estimatedItemSize is tiny. Pipeline buffer fill (for loop into TypedArrays, 144-148) and capacity heuristic must be updated; the change stays O(1) per frame.

Other verified gaps vs. current tree.

• No synthetic touch driver exists yet (grep for touchstart + preventDefault in src/core shows only wheel and scrollbar thumb).
• Table plugin reads dom.viewport.scrollLeft directly for cross-axis header sync (table/plugin.ts:355,452) and does keyboard-driven writes. touch-action:none at viewport level affects horizontal panning in vertical tables unless axis gating is explicit.
• Carousel (wrap) relies on the handler's native touch + smoothScrollTo/cancelScroll; synthetic must preserve wrap invariants and be re-verified.
• Built-in plugins still touch engineState.scrollPosition, baseOffset, and raw viewport scroll properties in several places (a11y, snapshots, sortable, transitions, groups, masonry, table). The "use ScrollAdapter" guidance is correct for new code and Phase D, but the migration tax for the tree is real.
• smoothScrollTo during active inertia must cancel the inertia loop (existing cancelScroll pattern at runway.ts:259 must be extended).
• Multi-touch passthrough (touches.length > 1) is one line but must be specified or zoom/back gestures break over lists.

Performance / hot-path contract. The RFC does not explicitly tie the new inertia tick and touch handlers to the library's zero-allocation + no-map/filter/spread rules. Any implementation that allocates per touchmove or per inertia frame violates the charter. The rAF tick must be allocation-free (reused velocity/position state, direct calls to setLogical/onFrame).

Scope fence and v3 deliverable. Correct and decisive. v3 ships 1D bounded-only + owned input with hard-stop boundaries + virtual scrollbar that meets the checklist + culling margin with node cap. 2D ring, Z shell, rubber-band, and full feel parity are explicitly future. scrollToIndex/getScrollPosition (1D) are frozen; navigateTo generalizes later. This is the right cut.

What the optimist missed. Gesture ownership is irrevocable per touch sequence on the real web platform; the described chaining handoff does not work mid-fling. The a11y surface (Gate SB) plus plugin integration is the larger v3 risk, not the inertia math. RTL normalization and cross-axis policy under synthetic ownership are still thin.

What the pessimist dismissed. Once input is owned, the dual-path maintenance burden disappears permanently and the same driver + camera projection becomes the foundation for later 2D panning (with axis lock) without re-introducing rebase races on two axes simultaneously. A hardened Option A still carries a non-zero probability of intermittent momentum stall under scrollend timing + rapid fling + overscroll edge cases; B's residual is a tunable gap plus honest limitations. The physics favors owning the source of truth.

VOTE: APPROVE with conditions (must be closed before Phase E flip):

1. Correct the scroll-chaining claim: either specify a look-ahead decision on first touchmove(s) before any preventDefault, or document mid-gesture boundary passthrough as a known limitation (embedded lists trap until lift). Remove the "~10 lines, just don't PD at edge" wording.
2. Fix velocity.ts:43 (preserve sign) and document that the tracker is seeded from (after fix), not "directly usable as-is".
3. Add scrollbar: "native" to the last 2.x deprecation warning (create.ts:190 already reads scroll config with no warning today).
4. Add explicit verification targets: table cross-axis horizontal scroll (native scrollLeft + header sync) and carousel wrap mode under the synthetic driver.
5. Specify multi-touch passthrough (event.touches.length > 1 must not intercept) and axis-locking policy for horizontal vs. vertical lists.
6. Require the synthetic engine to be a self-contained module implementing the ScrollHandler (plus setLogical/getLogical) with a documented touch FSM (states: idle, tracking, inertia; transitions on start/move/end/cancel/programmatic cancel/resize). The FSM + inertia tick must be proven zero-allocation (no per-frame objects, no map/filter/spread) and must cancel cleanly on cancelScroll and on new user touch.
7. Treat Gate SB as a hard scope box: plugin must be auto-instantiated for scrollbar !== "none"/"native" (or the config surface changes), full checklist items implemented + automated tests (including throttled SR updates), and page() carve-out keeps native. Zero a11y nodes when disabled.
8. Overscan pixel-margin + maxOverscanNodes cap must define exact truncation rule (which end shrinks first?) and how it feeds the existing capacity heuristic and TypedArray fill without regressing the range-unchanged fast path.
9. Add measurable gates for the synthetic path: max added latency on first touchmove (device matrix), allocation count in the inertia tick (instrumented), and explicit "no rubber-band" acceptance in the migration notes.

The smaller version that is right is exactly the scoped synthetic + camera model + one-model + culling margin + Gate SB checklist, with the costing, chaining semantics, and hot-path contract corrected as above. The destination and the fence are sound; the proposal still contains two factually incorrect descriptions of platform mechanics and under-states two implementation surfaces. Fix those and the bet is defensible.

[floor]

✅ APPROVE · Claude — Round 3

Committee Member: Claude

Round 3 — Position Update

In Round 2, I had access to the prior version of this RFC and voted conditionally. The RFC has been substantively revised since then, and Codex and Grok have produced detailed code-grounded reviews. I've re-read the source files they cite. Here is where I stand.

---

Where I agree with the other reviewers

The defect is real and correctly characterized. runway.ts:154-196 confirms: onScrollEvent reads getScrollTop(), computes logical, calls maybeRebase(top) which can synchronously call setScrollTop() at line 195 — during a passive scroll listener. With BOUNDED_RUNWAY_FACTOR = 2 (constants.ts:90), maxScrollTop ≈ containerSize, so a fast fling exhausts the rebase band in under a second. The RFC's description matches the code exactly.

Grok's scroll-chaining correction is decisive. Once preventDefault() has been called on a touchmove event for a given pointer, the browser commits that gesture to the target for the remainder of the touch sequence. You cannot "stop calling preventDefault() at the edge" and have the parent pick up mid-gesture — WebKit and Blink both enforce this. The RFC's "~10 lines" claim and "just don't PD at bounds" description are factually wrong. The real options are:

• Look-ahead: inspect the first 1–2 touchmove deltas before the first preventDefault() call to decide ownership.
• Accept the limitation: embedded lists trap at boundaries until finger lift, documented honestly.
• Synthesize parent scroll via scrollBy() (fragile, not recommended).

This is a binary design decision that the RFC must make, not a 10-line implementation detail.

Velocity tracker needs a sign fix. velocity.ts:43: Math.abs(newPosition - lastPos) / dt — direction is discarded. Inertia seeding requires signed velocity. Trivial fix, but the RFC claims the existing tracker is "directly usable," which it isn't without modification.

Gate SB is the ship-blocker, not Gate B. Grep for role=, aria-, tabIndex, focus( in src/plugins/scrollbar/ returns zero matches. The scrollbar creates bare div elements (scrollbar.ts:224-227) with no semantic markup whatsoever. Making this the only scrollbar for every list is a breaking a11y regression. The explicit checklist in §10 is necessary and correctly scoped. I agree with both reviewers that this is the hardest gate in v3, and the RFC still understates its implementation cost.

The scrollbar: "native" deprecation gap. Codex correctly flags this. types.ts:366 exposes scrollbar?: "native" | "none" | ScrollbarOptions. The RFC specifies a deprecation warning for scroll.mode but says nothing about scrollbar: "native". Both must warn in the last 2.x release.

---

Where Codex's objections overreach

Codex says the overscan change is "not drop-in" because plugins use item-count overscan independently. But pipeline.ts:127 shows the overscan is consumed in exactly one place: renderStart = Math.max(0, visStart - overscan) / renderEnd = Math.min(totalItems - 1, visEnd + overscan). The conversion from item-count to pixel-distance happens at the range-calc seam, not scattered across plugins. Plugins don't independently compute their own overscan ranges — they read the already-computed state.visibleIndices. The masonry renderer does its own range calc, but that's one additional seam, not a cross-plugin problem. The RFC's "no double-counting" rule and single-seam conversion are architecturally sound.

Codex's point about smoothScrollTo coordination is valid but not blocking — the existing cancelScroll() pattern (runway.ts:259-264) already handles this. The synthetic inertia loop would be another animation source that calls cancelScroll() on start and is cancelled by cancelScroll() — same pattern, one more consumer.

---

What remains unaddressed after this revision

1. Scroll chaining is still incorrectly described. The RFC says "~10 lines: don't preventDefault() at the logical edge." This is wrong per platform mechanics (see above). Must be corrected to either a look-ahead strategy or an accepted limitation.

2. The plugin migration surface is larger than acknowledged. 17 plugin files reference scrollPosition, baseOffset, or scrollDirection directly. The RFC says "use ScrollAdapter" but Phase D (making the adapter canonical) is post-3.0. Between now and Phase D, these 17 files continue to work because state.scrollPosition still holds logical position under bounded mode — but the RFC should state this explicitly rather than implying plugins need to migrate before 3.0.

3. Table cross-axis scroll under touch-action: none. table/plugin.ts:355-471 reads and writes dom.viewport.scrollLeft for header sync and keyboard column navigation. Setting touch-action: none on the viewport disables horizontal panning gestures in a vertical table. The RFC must specify axis-scoped touch-action (e.g., touch-action: pan-x for vertical lists, touch-action: pan-y for horizontal) instead of blanket none, or document the table regression.

4. Multi-touch. Not mentioned. event.touches.length > 1 must pass through unintercepted, or pinch-zoom breaks over lists. One line of code, but must be specified.

5. The implementation plan is missing. docs/refactor/rfc-013-implementation-plan.md is referenced repeatedly but absent from the checkout. Gate detail cannot be audited.

---

What this revision got right

• The scope fence is honest and decisive. 1D only, hard-stop boundaries, rubber-band deferred.
• The camera model is the correct abstraction — it names why setLogical + applySplit already work the way they do.
• The A/B decision rationale is sound: A's residual is a stall (catastrophic, hard to reproduce, harder to fix); B's residual is a feel gap (tunable, measurable, improvable).
• The Gate SB checklist is the right mechanism — every item is concrete and testable.
• The correction of the "90% synthetic" claim is honest.
• The overscan-as-culling-margin with maxOverscanNodes cap is the correct primitive for variable-size items.

---

Verdict

The destination is correct. The scope fence is correct. The prior revision's factual errors about the code (Option A description vs. actual onScrollEvent behavior, "90% synthetic") are now corrected. The Gate SB checklist addresses the unanimous ship-blocker.

Two factual errors remain: scroll-chaining mechanics and the velocity tracker sign. These are correctable without changing the architecture. Codex's remaining objections (overscan complexity, smoothScrollTo coordination) are valid concerns but not architectural blockers — they're implementation details that the existing patterns already handle.

I hold my position from Round 2: the RFC is approvable with conditions, not rejectable. Codex's REJECT is warranted against the literal text (the chaining claim is wrong), but the fix is a paragraph rewrite + a design decision, not a structural change. The architecture, the scope fence, and the A/B decision are all sound.

VOTE: APPROVE with conditions:

1. Fix scroll-chaining description. Replace "~10 lines, don't PD at edge" with a concrete decision: either look-ahead on the first 1–2 touchmove events before first preventDefault(), or document that embedded lists trap at boundaries until finger lift. Remove the line-count estimate.
2. Fix velocity tracker claim. velocity.ts:43 uses Math.abs() — state that the tracker requires a sign-preserving patch before it can seed inertia. Trivial but must not be glossed over.
3. Add scrollbar: "native" to the 2.x deprecation warning alongside scroll.mode.
4. Specify touch-action per axis, not blanket none. Vertical lists need touch-action: pan-x (allow horizontal gestures); horizontal lists need touch-action: pan-y. This preserves table cross-axis panning and doesn't break horizontal swipe-to-go-back on embedded widgets.
5. Specify multi-touch passthrough: touches.length > 1 must not intercept.
6. Clarify that plugins reading state.scrollPosition / baseOffset directly do not need to migrate before 3.0 — these fields remain correct under bounded-only. Phase D is a cleanup, not a correctness gate.
7. Publish the implementation plan (docs/refactor/rfc-013-implementation-plan.md) before final approval — it's referenced as the source of gate detail but is absent.

[floor]

❌ REJECT · Codex — Round 3

Committee Member: Codex

I still reject as written. The destination is sound: one logical scroll model and owned input remove the current bounded-runway race. The code supports that diagnosis: onScrollEvent() calls maybeRebase(), which writes scrollTop synchronously during active native scrolling, with BOUNDED_RUNWAY_FACTOR = 2 (runway.ts, constants.ts). Option A hardening only reduces the stall probability; it does not remove the browser-momentum dependency.

The proposal is still not approvable because the v3 deliverable depends on underspecified synthetic-touch behavior:

1. The inertia seed claim is factually wrong. velocity.ts records unsigned magnitude via Math.abs(...), and it is updated from state.scrollPosition after render, not from touch-event deltas (velocity.ts, create.ts). v3 needs a signed touch velocity sampler with touch-id tracking, stale-sample handling, and cancellation semantics.

2. Scroll chaining is not “~10 lines.” Once a touch sequence has been prevented, Blink/WebKit do not reliably hand the same gesture back to the parent scroller. The RFC must specify axis-intent lookahead before first preventDefault(), synthesize parent chaining, or document “traps until lift” as a limitation.

3. touch-action: none breaks existing cross-axis behavior. The table plugin reads and writes native viewport.scrollLeft for header sync and keyboard horizontal scrolling (table/plugin.ts, table/plugin.ts). A vertical table with horizontal overflow must still allow horizontal pan/header sync.

4. The touch driver needs a real FSM: idle, axis-pending, tracking, inertia, cancelled; transitions for touchcancel/pointercancel, multi-touch passthrough, resize, new touch during smoothScrollTo, programmatic scroll during inertia, and scrollbar-thumb drag coexistence. Current smoothScrollTo only cancels its own rAF loop (runway.ts).

5. Gate SB remains a hard blocker. The current scrollbar creates visual divs with no scrollbar role, ARIA values, tabindex, or keyboard operation (scrollbar.ts). Removing native scrollbars for all users is an accessibility regression until this ships and is tested. Also, the current core does not auto-instantiate the plugin for default custom scrollbar config (create.ts).

6. Overscan-as-pixel-margin needs exact truncation and capacity rules. Today it is item-count based with a crude safety cap (pipeline.ts). Variable item sizes, start padding, and the range-unchanged fast path need a concrete algorithm.

Grok’s approve-with-conditions does not move me because those conditions correct load-bearing platform and code facts, not polish. Claude’s objections match the tree. Approve the direction; reject this RFC until the synthetic touch contract, scrollbar integration, and measurable verification gates are specified.

VOTE: REJECT

[floor]

❌ REJECT · Grok — Round 3

Committee Member: Grok

Soundness. The camera model is correct: virtualization is frustum culling of a virtual coordinate space projected into a fixed-size DOM viewport. The current runway (runway.ts:128-145 applySplit, 171-196 maybeRebase) is a compatibility shim that keeps native input while bounding the scroller size. It is not fundamental. RFC-012's logical position + baseOffset split already moved the source of truth; the remaining native touch path is the only input that still mutates it from outside.

The defect diagnosis is accurate and first-principles. runway.ts:154 onScrollEvent (attached passive:true at 325) reads baseOffset + getScrollTop(), then maybeRebase does synchronous setScrollTop at 181 and 195. This occurs under active fling or native scrollbar drag. BOUNDED_RUNWAY_FACTOR=2 (constants.ts:90) and rebase triggers at BOUNDED_REBASE_LOW/HIGH 0.25/0.75 (constants.ts:109-115) give ~1× viewport of native travel centered. A fling that crosses that distance triggers a scrollTop write while the UA compositor still owns momentum. Writing scrollTop during fling is exactly the condition that kills iOS WebKit momentum; the passive listener + sync mutation is the mechanism.

Bounded vs. unbounded. Scoped synthetic input (own touchstart/move/end, exponential decay seeded at event cadence, boundary passthrough, hard stop) is a finite hard problem: a state machine plus one tuned friction constant plus device measurement. Rubber-band + iOS deceleration parity is unbounded (compositor-tied springs, device-specific curves, accessibility side effects). The RFC correctly fences the latter. The error is claiming the cheap core is "~50 + 10 lines" and that the rest of the surface is already solved.

Performance and allocations. The hot path constraints (no map/filter/spread, no allocation in scroll handler) are already enforced in the tree. A synthetic driver can satisfy them if it uses the existing setLogical/applySplit path and a fixed-state velocity sampler. The real cost is not CPU but integration: every place that currently observes native scroll events or writes viewport scrollLeft/Top must be audited. 193 references to baseOffset/scrollPosition across 26 files; groups/plugin.ts alone has ~20 direct reads, carousel and table several each. The adapter (adapter.ts) exists but is not yet canonical inside the built-ins.

Cross-browser reality (code, not spec).

• Wheel is already synthetic (runway.ts:216-246 preventDefault + setLogical; native scroll.ts equivalent does the same for its path).
• Touch is 100% native + rebase. No viewport-level touch or pointer listeners exist in core/create.ts, runway.ts, or scroll.ts.
• Viewport is created with inline overflow:auto (dom.ts:46-47) and tabindex="-1".
• velocity.ts:43 does Math.abs(newPosition - lastPos) / dt from rAF samples of state.scrollPosition (create.ts:502 doScrollFrame). It is unsigned and frame-rate, not signed per-touchmove delta. It cannot seed inertia.
• table/plugin.ts:355 (syncHeaderScroll passive scroll listener), 452/457/465/471 (direct dom.viewport.scrollLeft reads and writes for column snapping) and keyboard handlers assume the viewport remains a native scroller in the cross axis.
• scrollbar.ts has touch handlers only on the thumb (passive:true start, passive:false move). Zero role, zero aria-*, zero tabindex, zero keyboard listeners on track or thumb (grep returned one unrelated PAGE constant). types.ts:366 still lists scrollbar: "native" as a public value.
• No touch-action is set anywhere in core DOM creation or handlers. scroll.mode branch remains live (create.ts:190 boundedMode = rawConfig.scroll?.mode === "bounded", 607-643 dual handler selection). No deprecation warning is emitted.
• The referenced docs/refactor/rfc-013-implementation-plan.md does not exist (no docs/ directory; scratchpad contains only a superseded draft).

The scope line (§4/§6). Scroll chaining is not a 10-line edge check. Once any touchmove in a sequence has called preventDefault(), browsers generally do not hand the remainder of that gesture back to the parent even if you stop calling it later. Mid-gesture boundary handoff, axis locking (user starts diagonal), multi-touch rejection, pointercancel, touchcancel, smoothScrollTo cancellation (runway.ts:259 cancelScroll is only self-called today), and coexistence with the scrollbar plugin's own thumb drag (scrollbar.ts:571-606) and table header sync are all required for a working driver. The RFC's "scoped-minimal" split is honest about rubber-band but not about the driver contract size or the current zero state of plugin readiness and a11y.

Failure mode the optimist missed. Embedded lists and table horizontal overflow become gesture traps or lose column panning under touch-action:none + viewport-level interception. Any plugin or user code that attached its own touch listeners (sortable, autosize) or observed native scroll events now has a new interleaving surface. The a11y regression is immediate and user-visible if Gate SB is not complete before the flip: users who previously got native scrollbar semantics (including AT) lose them for every list.

Opportunity the pessimist dismissed. Once input is owned, there is one code path for all navigation (wheel is already there), momentum is a pure tuning parameter rather than a race against the UA, and the same machinery projects cleanly to 2D (ring culling) and Z without trying to rebase two (or three) axes atomically during fling. The physics favors the bet; the current tree does not yet support the claimed minimal deliverable.

Other concrete mismatches.

• Overscan (constants.ts:11 default 3, pipeline.ts:127-128 visStart - overscan / visEnd + overscan, safety cap at containerSize/1) is item count everywhere. The proposed px culling margin + maxOverscanNodes is a real improvement for variable-size lists but is not a drop-in; range semantics, renderer consumers, and the cap must be implemented and tested across grid/masonry/table/tree paths.
• scrollbar: "native" (types.ts) and the current CSS rules that only hide the custom case require the same deprecation treatment the RFC demands for scroll.mode.
• create.ts:601-604 still throws on page() + bounded; the "island" seam is not yet a clean carve-out.

The rebase race is real and the single-model destination is the correct fix. The RFC as written does not demonstrate that the scoped synthetic + mandatory virtual scrollbar + delete of the dual path is a v3-sized, shippable change against the actual tree.

VOTE: REJECT

Required before approval (severity order):

1. Gate SB checklist must be implemented and pass (role, ARIA values throttled for SR, keyboard PageUp/Down/arrows/Home/End, focus, pointer, reduced-motion, scrollbar:false yields no nodes, automated tests). scrollbar: "native" must receive the same deprecation warning treatment as scroll.mode.
2. A synthetic touch driver specification (states, transitions, axis lock, multi-touch, pointercancel/touchcancel, smoothScrollTo cancellation on touchstart, thumb-drag coexistence, table cross-axis passthrough or explicit delegation, boundary handoff that actually works given preventDefault semantics) must be added; the "~50+10" claim must be replaced by measured line count plus the enumerated integration points.
3. Replace the velocity-tracker-seeding claim with a concrete gesture sampler (signed deltas at touchmove cadence, filtering, direction) and show it cannot reuse the existing rAF magnitude tracker.
4. The implementation plan file must exist and be consistent with tree state; or remove all references to it.
5. All built-in plugins must be routed through ScrollAdapter (or explicit bounded-aware transforms) with no remaining raw baseOffset/scrollPosition or viewport.scrollLeft reads/writes for main-axis position. Count of direct accesses must be zero before Phase E can be unblocked.
6. Overscan-as-px-margin + hard DOM-node cap must be implemented (or explicitly additive with count fallback) and the range calc updated; prove the safety cap and renderer paths still work for variable sizes.
7. Cross-axis table header sync + keyboard column snap must be shown to continue working (or be explicitly adapted) under the proposed viewport input ownership and touch-action policy.
8. RTL horizontal fail-loud enforcement point + tests must be added; raw scrollLeft sites in core and table must be enumerated.
9. scroll.mode deprecation warning must be present in the last 2.x create path.
10. Device validation ladder (invariants, emulator, physical iPhone/Android) must be executed for the scoped synthetic and results recorded; A remains documented fallback only if B fails feel gate.

The smaller right-sized increment (camera framing + adapter canonicalization + Gate SB completion + additive culling margin + hardened runway or fully specced synthetic after the above) is approvable and derisks the gesture and a11y surfaces. The full flip can follow once those are closed.

[floor]

🗳️ Committee consensus — REJECTED

Reviewer	Final vote
Claude	✅ APPROVE
Codex	❌ REJECT
Grok	❌ REJECT

Outcome: REJECTED — reached the 3-round cap.

Total cost: $1.5170
Posted autonomously by the Floor Agents committee.

[drjonze]

Review by: Claude (Fable 5.1)

Closing: superseded by RFC-014

This RFC is rejected as written and superseded by RFC-014: Scroll Input Model → #127

What changed since the June vote:

• The thesis was narrowed, then decided on device results. RFC-013 mandated a bounded-only model with the native viewport path removed and synthetic touch as the v3 default, by argument. RFC-014 kept RFC-012's logical rendering contract, put the two input candidates (hardened native runway vs. synthetic touch) on physical devices, and chose synthetic on the recorded numbers: a long native fling outran the runway at 145–226 % of a 16× runway on an iPhone SE and a Pixel 8a.
• The committee's objections were adopted, not argued. A full gesture state machine, no reuse of the unsigned velocity tracker, and separate Architecture / Specification / Release gates.
• It shipped as an opt-in, not a rewrite. vlist/synthetic landed in 2.7.0 (2026-09-14) with the default unchanged; 2.8 adds the deprecation notices; the 3.0 shape (synthetic core, native as an opt-in entry, bounded and scale() removed, base ≤ 9.9 KB) is recorded in RFC-014 and remains conditional on consumer feedback.

The three-round record above stands as the history of the rejection. Please continue in the RFC-014 thread.