[cixzhang]

People who swipe a list row on a phone stop losing messages and pages by accident. A quick flick only opens or closes the row and never fires Delete. A tap on an open row closes it instead of opening the item. A long swipe shows which action will run before the finger lifts, and backing out cancels it. Mouse, keyboard and screen-reader paths are unchanged.

Exact decision needed

How a swipe-action row (Item, ListItem) settles a release, and what closes an open row: spec:AST-057 FR4, FR5, FR7 and AR3.

Existing authority searched

• spec:AST-057 (current): FR5 fires the outermost entry on a fling or past the commit point, with nothing showing beforehand. FR7 closes only a resting row, and only on a pointer outside it, Escape, firing an entry or unmount. AR3 keeps the primary's activation unchanged in every state.
• spec:AST-094 (current): FR11 press profiles (a list row is a cell), FR17 thresholds, FR19 touch ownership (the row swipe keeps its per-event pointer read), FR37 moving back cancels. AST-094 already leaves the row's release rule to AST-057.
• component:Item, component:ListItem, component:List: each defers swipe behaviour to AST-057; no edit needed.
• Open work that depends on this decision: fix(Item): swipe actions move on the compositor with UIKit springs #8097 (flick), fix(Item): an open swipe row closes on a tap on its content or a scroll #8132 (tap and scroll close), fix(Item): a swipe row's full swipe confirms, runs ahead and fires like UIKit's #8134 (full swipe). This PR carries none of their code, and does not include fix(Item): swipe actions move on the compositor with UIKit springs #8097's separate FR2/DEC-5 question (the row moving by compositor translate).

Decision

• FR5: under reveal, a release goes by its speed first: a fast one goes the way the row is moving; a slower one opens past half the panel's width. Speed alone never fires an entry. Dragged past the confirm point, the row runs ahead and the outermost entry covers it while the finger is down. A lift there fires that entry. Coming back short of the confirm point closes the row and fires nothing. A disabled outermost entry never confirms. Under commit, only a lift past the confirm point fires. onActivate fires once the row's content has left its box.
• FR4: while a full swipe is confirmed, the outermost entry alone covers the uncovered space.
• FR7: an open row closes when a pointer lands outside it, on a touch tap on its own content, on a scroll while focus is outside its open panel, on Escape, on firing an entry, and on unmount. Rows settling open count as open. The tap activates nothing and paints no press, an exception to spec:AST-094 FR11's cell profile.
• AR3: the primary's activation is unchanged while the row is closed. While it is open, a touch tap closes it; keyboard activation is unchanged.
• Full swipe stays on by default under reveal, as before. No public API changes.
• The two Public API rows that restated the old timing and fling rule (onActivate, Item.swipeBehavior) now point at FR5. The verification rows for FR4–FR6, FR7 and AR1–AR3 name the new states and failures.

Rejected alternatives

• A confirmation dialog on a destructive full swipe: the covering entry already shows what a lift will do and backing out cancels; a caller that wants a dialog opens one from onActivate.

Claim scope and non-goals

• Only FR4, FR5, FR7 and AR3 change, plus the matching verification rows and two Public API rows that restated FR5.
• Not covered: how the row moves (FR2, DEC-5), and gesture constants (confirm point, release speed), which stay behaviour constants in source.

Evidence and implementation relationship

• Parity reference: native iOS list rows. A flick opens or closes and never fires; a tap on an open row closes it without selecting; a scroll closes it; a full swipe stretches the action over the row and fires on lift; backing out cancels.
• Implementation lives in fix(Item): swipe actions move on the compositor with UIKit springs #8097, fix(Item): an open swipe row closes on a tap on its content or a scroll #8132 and fix(Item): a swipe row's full swipe confirms, runs ahead and fires like UIKit's #8134, which conform to this text once it lands. Each still owes physical-device evidence for FR5 and FR6.

Writing rubric results

• R1 narration: none in the changed text; every new sentence states behaviour in the present tense. One pre-existing stale statement remains outside this decision: the Verification section's "Known verification gap" still calls the record draft.
• R2 research in the record: none; the iOS parity comparison lives in this description.
• R3 evidence naming a change: none; the FR5 basis stays UIKit performsFirstActionWithFullSwipe.
• R4 rejected alternatives over one line or outside a decision: none added.
• R5 pull request or issue references remaining: one pre-existing reference in DEC-2's "Rejected" line, untouched by this change; none added.
• R6 ruled open questions still listing options: none; Open questions reads "None."

Scope

• This PR contains specification records only.
• It records observable behavior and preserves equivalent internal implementations.
• Any named internal mechanism is intentionally public, names its dependent caller/system, and explains why an equivalent implementation would not satisfy the contract.
• Verification states the evidence layer and failure signal without prescribing CI job/workflow topology.
• It records one intentional durable decision, not a rescue for a separable tagalong.
• The canonical knowledge owner, affected current claims, and overlapping open work are named; any ownership collision is resolved or called out for human decision.
• Adjacent API, visual, accessibility, composition, and implementation facts remain outside scope unless this exact decision depends on them.
• Public text and artifacts contain no internal Meta context.

Validation

• pnpm check:knowledge: "Knowledge templates and records are aligned."
• Prettier: applied to the record.
• git diff --check: clean.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Building	Preview	Oct 31, 2026 4:15pm UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🔄 In progress (for maintainers only)	Oct 31, 2026, 4:15 PM UTC

[cixzhang]

/approve-spec 3dc4e01