[cixzhang]

Maintainer impact

People who hold a finger on a ContextMenu trigger on a phone get a menu that feels native: the trigger lifts above a page tinted with the theme's overlay color (no blur), the menu grows out of the finger and shrinks back into it, and the motion plays on three named springs. People who open a menu with a mouse or keyboard see no change. The look and motion are unbuilt, so the records mark them as implementation gaps. No prop, export or theme token changes.

Decision

The owner's two lines, 2026-11-01:

"context menu appearance on ios seems really touch specific. I don't feel like desktop should have it."

"I think context menu proposal A, we skip the blur"

Proposal A covers all three open points: lift A (tint only, no blur), glass A (the menu grows as its own surface, with no glass blob), and springs A (three ContextMenu spring roles).

Changed records

• component:ContextMenu
  • FR5: one scope sentence. The lift, the grow and their springs apply only to a menu opened by touch (a touch-initiated open on a coarse pointer); mouse and keyboard opens keep their released look and motion.
  • FR5: one clause. A touch-opened menu grows out of the finger's point and shrinks back into it as its own surface, by transform and opacity only, with no second element.
  • FR5: the three springs it plays, plus implementation gaps (no page tint; roles not registered).
  • New Design decisions DD1: the page behind the lifted trigger is tinted with the theme's overlay color and is not blurred.
  • New DEC-2: while the lifted menu is open the page has four more elements than under a fine pointer, each with one job, within the spec:AST-017 FR60 open-layer allowance.
  • Four verification rows: touch-opened vs mouse- and keyboard-opened menus; Reduce Motion; the motion roles; element counts. Each one names its evidence gap.
  • Family relationships and Current-state impact updated to match.
• spec:AST-094
  • FR4 role table: springs.contextMenuLift (0.8, 0.32 s), springs.contextMenuDismiss (0.85, 0.35 s) and springs.contextMenuMorph (0.8, 0.3 s), owned by component:ContextMenu (DEC-5) and played only in a touch-opened ContextMenu.
  • FR31: one clause. A lifted ContextMenu's menu grows on springs.contextMenuMorph.
  • Current-state impact: an implementation gap for the unregistered roles.
• spec:AST-108 is unchanged. Its FR3 already covers every role in spec:AST-094 FR4, so the new rows follow tempo and character with no edit there.

Unblocks

• feat(ContextMenu): a held finger lifts the trigger as iOS 26 does, with the menu beside it #8201: the lift
• feat(ContextMenu): the menu's glass grows out of the finger as iOS 26's does #8213: the grow-out
• feat(ContextMenu): closing shrinks the menu back into the finger as iOS 26 does #8228: the shrink back
• spec(ContextMenu): the context menu's three springs as motion roles, and the lift's four elements #8830: the springs record. This PR carries its three FR4 rows and its DEC-2.

Writing rubric results

R1 narration: none; every added sentence states behavior, an owner or an implementation gap in the present tense.
R2 research: none in the record; the iOS comparison and the options stay in the decision brief outside the repo.
R3 evidence: the spring sources cite measurements, not changes. The DEC-2 element counts measured on unmerged code were left out, and the verification rows name evidence gaps instead.
R4 rejected alternatives: one, DEC-2 (a copy of the trigger), one line.
R5 change references: none in the records.
R6 open questions: none.

Checks: pnpm install --frozen-lockfile, pnpm check:knowledge ("Knowledge templates and records are aligned."), and prettier on both records.

[vercel]

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

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 2, 2026 1:42am UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🔄 In progress (for maintainers only)	Nov 2, 2026, 1:34 AM UTC

[cixzhang]

/approve-spec 41af8fb