[vjeux]

Stacks on #8225; only the last commit is new here.

User impact

With reduced motion on, an indeterminate ProgressBar still slides a 40% segment across the track, slowed to 3 s a pass. design:reduced-motion DR1 says nothing should travel there, so the bar now stays put: on every pointer its fill spans the whole track and only its opacity pulses, from full down to 0.84 and back, 2 s each way.

Options and tradeoffs:

• Keep the slower slide: it still travels.
• A still bar: nothing tells the user work is happening.
• iOS Safari's pulse (1 s between 0.30 and 0.60): below 0.84, some tones drop under 3:1 against the track.
• A slow pulse with a 0.84 floor (this PR): every tone that reaches 3:1 against the track at full opacity still does at the floor.

Visual authority

• Existing component/module DD row reused or amended.
• Durable component-local intent added to the optional Design decisions table by a team design owner.
• Correction already settled by current family, design, theme, or objective accessibility authority.
• New shared or cross-component direction settled in docs/design/.

Settled by component:ProgressBar FR6, AR4 and DEC-2: the pulse plays the progress.reducedMotionPulseMs role on timing.curves.move, which tempo does not scale.

Before and after

Reduced motion, Chromium, one bar seeked through a cycle; before (main) then after:

State matrix

• Reduced motion, a mouse or a finger: full width, pulsing; nothing moves.
• No reduced motion: the 40% slide, unchanged.
• A theme tempo of 1.5: still 2 s each way.
• Light and dark default themes, body and surface: accent, success and error keep 3:1 at the floor (lowest: success in dark on the surface, 3.007:1); warning and neutral in light are under 3:1 even at full opacity.

Writing rubric results

component:ProgressBar (FR6's gap lines, the FR6 and AR4 verification rows) and the generated role table: R1–R6 none; the rows name the new tests.

Scope

• Appearance is the primary intent.
• Behavior, API, interaction model, and unrelated layout changes were removed or split.
• The evidence shows the changed pixels actively running, not only source or computed styles.
• Public text and artifacts contain no internal Meta context.

Testing

Local gates at 396791a: ProgressBar and motion units 920/920; ProgressBar browser specs 43/43, and ×3 on two pinned cores 129/129; typecheck, lint, the changeset, knowledge and role-table checks pass.

[vercel]

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

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 2, 2026 8:29am UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Nov 2, 2026, 8:42 AM UTC

[github-actions]

PR Analysis Report

Current run: The current CI run concluded skipped. Current analysis is unavailable.

---

_{Generated by PR Enrichment workflow | View current CI run}

[astracat-bot]

This ProgressBar touch change needs an engineering-owner decision before it can be approved: it rests only on the draft spec:AST-094, so an engineering owner, the author included, can record approval of that direction (the touch indeterminate sweep, its Reduce Motion pulse and its timing outside the theme's motion tokens) by commenting /approve-spec <full head SHA>, or point to another governing spec. Whatever that decision, two changes are needed:

• Land the stacked predecessors first (or retarget) so this pull request carries only its own 461-line commit instead of 16,939 authored lines.
• Under a coarse pointer, a value that reverses to the one it just left animates in half the stated time (400 ms instead of 800 ms), because CSS shortens reversed transitions.

[Automated review]

[astracat-bot]

Under a coarse pointer, a change that reverses to the value it just left runs at half the duration written here. CSS shortens a transition that reverses to its own start value, so 10 → 90 paused at 50% and sent back to 10 runs 400 ms although --_progress-bar-duration is 800 ms (433 ms when reversed live at 52%); a retarget to any other value keeps its full duration. Keep reversals off the browser's reversing path, or document that they follow the drawn distance, and add the case to ProgressBarTouch.a11y.chromium.spec.ts.

[astracat-bot]

spec:AST-090 is not in this head or on main (it is proposed in open #8003), so FR7 asks owners to amend text that is not in the repository. Land AST-090 first, or restate FR7 against records present at the head.

[astracat-bot]

This ProgressBar touch change needs an engineering-owner decision before it can be approved: it rests only on the draft spec:AST-094, so an engineering owner (the author included, if they are one) can record approval of that direction (the touch sweep, its trackless Reduce Motion pulse and its timing outside the theme's motion tokens) by commenting /approve-spec <full head SHA>, or point to another governing spec. Whatever that decision, these changes are needed:

• trackIndeterminate sets default: null, which removes the grey track from every indeterminate ProgressBar, with a mouse too; keep the default colour in the override and test the mouse path.
• Land the stacked predecessors first (or retarget) so this pull request carries only its own 500-line commit instead of 16,976 authored lines.
• Under a coarse pointer, a value that reverses to the one it just left animates in half the stated time (400 ms instead of 800 ms).
• AST-094 FR7 amends spec:AST-090, which is not in the repository.

[Automated review]

[astracat-bot]

stylex.props() merges by property, so this backgroundColor (a null default plus one media key) replaces track.backgroundColor whole: every indeterminate track loses --color-background-muted, with a mouse and with a finger, not only under coarse pointer plus Reduce Motion. On CI's static Storybook build of this head the Indeterminate story's track computes to rgba(0, 0, 0, 0) with a mouse, against rgb(212, 212, 212) on the base. Keeping the default in the override (default: colorVars['--color-background-muted']) and asserting the track colour on the mouse and touch-sweep paths would fix and guard it.

[astracat-bot]

This ProgressBar change needs an engineering-owner decision before it can be approved: it rests only on the draft spec:AST-094, so an engineering owner (the author included, if they are one) can record approval of that direction for the iOS bar (the quarter-track sweep, the trackless Reduce Motion pulse and its theme-retunable timing) by commenting /approve-spec <full head SHA>, or point to another governing spec. Whatever that decision, these changes are needed:

• trackIndeterminate keeps default: null, which removes the grey track from every indeterminate ProgressBar, with a mouse and on Android too; keep the track colour as the default and test those paths.
• Land the stacked predecessors first (or retarget) so this pull request carries only its own two commits instead of 19,658 authored lines.
• The iOS gate infers the engine from -webkit-touch-callout, which spec:AST-013 FR6 does not allow, and the theme platform condition is outside spec:AST-012 FR2's closed vocabulary, so each needs its record amended first or has to go.
• AST-094 FR4 and DEC-1 say touch motion is not themable while the new theme motion roles retune it, the motion docs advertise roles no component reads, and FR7 amends spec:AST-090, which is not in the repository.
• On iOS a fill that reverses to its previous value runs at half its written duration, lint and test-node (1/4) fail on a missing @astryxdesign/cli changeset and a stale docs golden, and the description needs AST-094's writing-rubric results.

[Automated review]

[astracat-bot]

On iOS a value that reverses to the one it just left runs at half this duration: CSS shortens a transition that reverses to its own start value. With the iOS gate emulated in Chromium, 10 → 90 held halfway and sent back to 10 runs 400 ms while this computes 0.8 s; a retarget to 30 keeps its 600 ms. Keep reversals off the browser's reversing path, or document that they follow the drawn distance, and add the case to ProgressBarTouch.a11y.chromium.spec.ts.

[astracat-bot]

spec:AST-012 FR2 closes the when vocabulary to width, pointer, contrast and motion: "Future environment fields require explicit additions to this closed vocabulary." platform needs that amendment first (architecture:theme-authoring-contract also says an adaptation change preserves the fixed condition vocabulary), so it would be easier to split it out with the amendment.

[astracat-bot]

spec:AST-013 FR6: "Components detect the API or CSS capability they use rather than inferring it from a browser name. A narrow engine workaround is allowed only for a reproduced defect with a regression fixture and a review or removal condition." This query is read only to tell iOS WebKit from every other engine, so the iOS idiom built on it needs FR6's owner to rule before it ships.

[astracat-bot]

FR4, and DEC-1's "Rejected: tuning touch motion per theme", say touch motion is not themable, but this pull request adds defineTheme({motion: {springs, durations, curves}}) and ProgressBar and Spinner read --motion-* role variables a theme can set. Bring FR4 and DEC-1 in line with the roles, or drop the roles, before owners rule on this record.

[astracat-bot]

This says sheets, alerts, menus, navigation and scrolling play these roles, but at this head only four roles have a consumer (the three progress.* durations in ProgressBar and progress.activityIndicator.cycleMs in Spinner), so the springs.sheetPresent example below changes nothing. Document only roles a component reads, and reject role ids no table registers instead of accepting them silently.

[astracat-bot]

Approval waits on an engineering owner's decision on draft spec:AST-094 for the iOS indeterminate bar, including its iOS engine gate, which spec:AST-013 FR6 does not allow today, and its theme-retunable timing, which the draft's own FR4 rules out. An engineering owner records that decision by commenting /approve-spec b7432c040517a75d25a5827fb880aecf97c2425b on this pull request, and the author may do so as an engineering owner.

• Restore the indeterminate track, which the null default at ProgressBar.tsx:281-290 removes with a mouse and on Android too.
• Rebase onto the stacked predecessors so this pull request carries only its own commits, drop when.platform or amend spec:AST-012 FR2, fix the halved iOS reversal, and keep the motion docs to roles that have a reader.

[Automated review]

[astracat-bot]

This null default replaces the track's --color-background-muted on every indeterminate bar, so the track renders transparent with a mouse, on Android and on iOS without Reduce Motion (the base paints rgb(212, 212, 212)). Give both defaults the track colour and keep transparent only under the gated Reduce Motion branch, then assert the track colour on the mouse and Android paths.

[astracat-bot]

A move reversed halfway (10 to 90, back to 10 when drawn at 50%) is specified as 0.8 s here, but CSS Transitions shortens a transition that reverses to its start, so Chromium runs it in 400 ms, half what progressView.wholeTrackMs documents. Start the reversal as a fresh transition or restate the table, and add the case to the touch spec.

[astracat-bot]

spec:AST-012 FR2 closes the when vocabulary to width, pointer, contrast and motion and says future fields need explicit additions to it; no theme in the repository sets platform, only the motion doc's example. Remove it, or amend AST-012 FR2 in its own pull request.

[astracat-bot]

This query identifies the engine to choose a presentation; spec:AST-013 FR6 allows an engine test only as a workaround for a reproduced defect with a regression fixture and a removal condition, so it needs an owner decision: amend FR6, or key the presentation on a capability.

[astracat-bot]

At this head only the three ProgressBar durations and Spinner's cycle read a motion role, so sheets, alerts, menus, navigation and scrolling do not follow these roles yet, and the example's springs.sheetPresent and springs.navigationPush change nothing. Document only roles that have a reader, or mark the rest as not yet in use.

[astracat-bot]

Approval waits on an engineering owner's decision about draft AST-094. That decision covers the iOS-only engine gate (current AST-013 FR6 does not allow it), the trackless Reduce Motion pulse, and theme-retunable touch roles, which AST-094 FR4 and DEC-1 forbid as written. An engineering owner records it by commenting /approve-spec <full head SHA> on this pull request, and you may do so yourself if you are an engineering owner. Whatever the decision, these still need changes:

• With Reduce Motion on iOS the pulsing bar reaches only 1.52:1 to 2.42:1 against the page, below the 3:1 non-text contrast AST-020 requires.
• Rebase onto the stacked predecessors so the pull request carries only its own four commits, about 640 of its 19,658 authored lines.
• Drop when.platform or amend AST-012 FR2 first, derive the Spinner spoke delays from the cycle role, keep a reversed iOS move at its documented duration, document only motion roles something reads, and fix the citation of the missing AST-090.

[Automated review]

[astracat-bot]

With Reduce Motion on iOS this removes the track, so the pulsing fill (accent at 0.3 to 0.6 opacity) reaches only 1.52:1 to 2.42:1 against the light page, below the 3:1 non-text contrast that AST-020 requires for a meaningful state graphic. Pulsing at 0.74 opacity or more, or keeping the track and the 3 s slide that a mouse and Android keep, would hold 3:1.

[astracat-bot]

A move sent back to its starting value runs at half this duration, because CSS shortens a transition that reverses to its start. With the iOS gate emulated, 10 → 90 takes 800 ms; sent back to 10 halfway, it takes 400 ms, while 90 → 30 from the same point takes the documented 600 ms. A reversal test, plus a path the reversing rule does not shorten (or a documented exception in progress.ts), would close this.

[astracat-bot]

These delays are sized for the 800 ms default, but the duration reads --motion-progress-activity-indicator-cycle-ms, which themes are invited to retune. At 1600 ms the bright head sits on one spoke for 800 ms and then steps 0, 7, 0, 1…. Deriving each delay from the same variable, for example calc(var(--motion-progress-activity-indicator-cycle-ms, 800ms) * -6 / 8) here, keeps the order at any cycle.

[astracat-bot]

AST-012 FR2 closes the condition vocabulary to width, pointer, contrast and motion, and says future environment fields need an explicit addition to it. This adds platform without amending FR2, and nothing in this pull request reads it. Dropping it here, or amending AST-012 first, resolves the contradiction.

[astracat-bot]

AST-013 FR6 asks components to detect the capability they use rather than infer the engine, and allows an engine workaround only for a reproduced defect with a regression fixture and a removal condition. Here the property identifies iOS WebKit in order to choose a presentation, so it needs an engineering owner's decision (AST-094 approved together with an FR6 amendment) before it can land.

[astracat-bot]

A well-formed id that names no registered role passes this check and writes a variable nothing reads; the error text even suggests sheet.present, which no table registers. Rejecting unregistered ids would catch a theme author's typo.

[astracat-bot]

Only four of the 50 roles have a reader in this pull request: three in ProgressBar and one in Spinner. Sheets, alerts, menus, navigation and scrolling do not play these roles yet, so this sentence and the example's springs.sheetPresent and springs.navigationPush promise effects a theme will not see.

[cixzhang]

Posted by Cindy's agent on her behalf.

Parts of this PR re-implement behavior that already exists, or is being specified, as a shared part of core. Converging keeps one implementation per behavior:

• Touch gating. core/src/ProgressBar/ProgressBar.tsx:287 writes its own (pointer: coarse) check. This conflicts with AST-012 FR2 (touch is resolved once, through the closed adaptation vocabulary) and public-component-api INV16. Resolve through the shared touch resolver key so behavior matches the spec. If this behavior genuinely can't be expressed through the resolver, please raise it here as a spec question instead of shipping a separate check.
• Reduced motion. core/src/ProgressBar/ProgressBar.tsx:290 handles reduced motion locally. Per design:reduced-motion (DR1–DR4), the animator is the one place that resolves it (touch cross-fades in 200 ms or less with no travel, a fine pointer changes at once), and core has no opt-out, so reducedMotion: 'keep' should be removed.

This is about where the behavior lives, not about the PR's intent.

[vjeux]

Agreed: one implementation.

• Touch gating: the sweep, the pulse and the track rules move onto the shared resolver's touch key (TOUCH_QUERY, with no engine gate), in the one-touch-model restack onto feat(core): the internal touch foundation: press tracking and the animator #8076.
• Reduced motion: the reduced-motion branches move onto the shared reduced-motion queries from feat(core): the internal touch foundation: press tracking and the animator #8076 (REDUCED_MOTION_FADE_QUERY and REDUCED_MOTION_INSTANT_QUERY, the keys reducedMotion.test.ts checks), in the same restack. Nothing in this branch passes reducedMotion.

[astracat-bot]

Approval needs an engineering owner to approve or identify the governing spec for the iOS Safari look of ProgressBar's indeterminate bar, which today rests only on draft spec:AST-094: a 25% linear sweep, a Reduce Motion pulse with no track, whether it applies on iOS only or on every touch screen, and whether themes may retune its timing. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision, please rebase onto the landed stack so this diff is the ProgressBar change alone, and fix these:

• Use the shared compact definition from spec:AST-012 FR9 instead of 744 px, which opens adaptive menus as popovers on 744–767 px touch screens.
• Key the touch styles on the shared touch resolver instead of -webkit-touch-callout, as spec:AST-013 FR6 and the owner comment ask.
• Drop when.platform, the theme-settable reduced-motion fade and reducedMotion: 'keep', which spec:AST-012 FR2 and the reduced-motion design record rule out.
• Make the motion docs describe only roles a component reads, reject unknown role ids, and fix AST-094's citation of the missing AST-090.

[Automated review]

[astracat-bot]

spec:AST-012 FR9 makes a screen compact below the effective md point (768 px by default) and says no resolver keeps size numbers of its own; on a 750 px touch screen this opens adaptive menus as popovers. main exports compactDefinition() / DEFAULT_COMPACT_DEFINITION for this.

[astracat-bot]

-webkit-touch-callout stands in for "iOS" here, which spec:AST-013 FR6 allows only for a reproduced engine defect with a fixture and a removal condition; the engineering owner asked for the shared touch key instead.

[astracat-bot]

platform is not in spec:AST-012 FR2's closed when vocabulary (width, height, pointer, contrast, motion), which requires an explicit addition to the record first.

[astracat-bot]

As a theme role this lets a theme lengthen the reduced-motion fade, and its 500 ms default exceeds the 200 ms design:reduced-motion DR2 allows on touch; DR4 says theme values offer no way to keep a longer animation under reduced motion.

[astracat-bot]

An id the registry does not know passes through and emits a variable nothing reads (the test expects 'sheet.present' to become --motion-sheet-present), so a typo in a theme fails silently.

[astracat-bot]

At this head only ProgressBar and Spinner read a --motion-* variable and no component calls the animator, so retuning springs.sheetPresent or springs.navigationPush as the example shows changes nothing.

[astracat-bot]

spec:AST-090 is not on main or in this pull request, so this amendment cannot be checked.

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's touch presentation, which no current record states: the 25% linear sweep, the trackless 0.74–1 Reduce Motion pulse and its departure from Safari's measured 0.3–0.6 (spec:AST-094 leaves each component's presentation to its own record, and component:ProgressBar is still a draft). An engineering owner records that decision by commenting /approve-spec 64f26c11fb5cfc53c09a38dd751b0fccdfff0de1 on this pull request, and the author may do so if they are an engineering owner. Whatever the decision, these changes are still needed:

• Rebase onto main once #8076, #8177, #8211, #8196 and #8225 land, so the diff (23,602 authored lines today) holds only this branch's commits.
• Read the sweep, pulse and fill timing through motion roles, since spec:AST-094 FR4 says a component “MUST NOT play a literal”.
• Mirror the sweep on :dir(rtl), as the determinate fill already does, so the segment stays on the track in a left-to-right region of a right-to-left page.
• Keep the Spinner ring (it contradicts component:Spinner FR3) and the gesture host (it contradicts spec:AST-094 FR18 and FR20) in their own pull requests, and add real-device iOS Safari and Android Chrome recordings for the touch claims.

[Automated review]

[astracat-bot]

These constants are literals played in place of motion roles. spec:AST-094 FR4 says every duration and curve a touch presentation plays “MUST be a motion role named for its use” and that a component “MUST NOT play a literal”. Naming them as roles in ProgressBar's record, so they join the generated role table (DEC-5), and reading them through the roles would conform; otherwise FR4 needs amending.

[astracat-bot]

This mirrors on any RTL ancestor, while the segment sits at its own region's start. In a left-to-right region of a right-to-left page the sweep starts at the left end and moves left, so the segment is off the track from about 333 ms to each turn. Keying the mirror on :dir(rtl), as the determinate fill does at line 342, keeps it on the track.

[astracat-bot]

The rotating span around the arc's own <svg> no longer matches component:Spinner FR3 (“an aria-hidden SVG of two concentric circles … The arc's dash moves around the stationary circle”). This belongs in its own pull request that conforms to FR3 or amends it.

[astracat-bot]

applyStyle writes the derived touch-action over the element's own value and saves that only to restore it later. spec:AST-094 FR18 requires the derived value to be intersected with the author's touch-action and never be wider than it.

[astracat-bot]

Any scroll event hands every unclaimed touch inside the scroller to the browser, with no travel check. spec:AST-094 FR20 counts a native scroll only once the finger has moved the 10 px scroll take distance, so sub-pixel drift under a still finger does not cancel a tap.

[vjeux]

Rebuilt on the new #8225 head. The Spinner ring is #8177's change and is no longer in this branch, and its own change is one commit: vjeux/astryx@d8e4dab...1907505

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's touch presentation, which no current record states: the 25% linear sweep, the trackless 0.74–1 Reduce Motion pulse and its departure from Safari's measured 0.3–0.6 (spec:AST-094 leaves each component's presentation to its own record, and component:ProgressBar is still a draft). An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever the decision, these changes are still needed:

• Rebase onto main once #8076, #8196 and #8225 land, so the diff (21,897 authored lines today) holds only this branch's commits.
• Mirror the touch sweep on :dir(rtl), as the determinate fill already does, so the segment stays on the track in a left-to-right region of a right-to-left page.
• Read the sweep, pulse and fill timing through motion roles, since spec:AST-094 FR4 says a component “MUST NOT play a literal”.
• In the carried code, stop the forced-colors fill animating width under a finger (FR5), bring the gesture host to FR18 and FR20, and add real-device iOS Safari and Android Chrome recordings for the touch claims.

[Automated review]

[astracat-bot]

Under forced colors with a coarse pointer this switches the fill's transition to width, while the touch key still gives it calc(var(--_progress-bar-change, 0) * 1000ms), linear (lines 387-398). On a touch screen with a contrast theme, a value change then lays out every frame and stalls with the main thread. spec:AST-094 FR5 says a touch presentation's animation “MUST NOT animate layout properties”. Landing the value at once under forced colors (transitionDuration: '0s' there) would conform; this arrives with #8196's fix, so it belongs there.

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's touch indeterminate bar, which no current record states: Safari's 25% linear sweep, the trackless 0.74–1 Reduce Motion pulse (Safari measures 0.30–0.60), and whether its timing must be AST-094 FR4 motion roles rather than StyleX constants. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, or by naming the record that should state it, and the author may do so as an engineering owner. Either way, please:

• Rebase or retarget onto #8225 so this pull request carries its own 699 changed lines instead of 19,100.
• Key the touch sweep's RTL keyframes on :dir(rtl), because ProgressBar.tsx:438 runs the segment off the track in a left-to-right region of a right-to-left page.
• Add real-device recordings for the iOS Safari and Android Chrome claims, as AST-094's platform support section requires.

[Automated review]

[astracat-bot]

This key matches any RTL ancestor, so a bar in a left-to-right region of a right-to-left page plays the right-to-left sweep from the left edge and leaves the track: 89.5, 55.9, 22.4 and 0 px stay visible at 0, 125, 250 and 500 ms, and the bar is empty from 333 to 1,667 ms of each cycle. Keying it on :dir(rtl), as the determinate fill does at line 356, follows the bar's own direction (design:bidirectionality DR3).

[astracat-bot]

spec:AST-094 FR4 says every duration and curve a touch presentation plays MUST be a motion role named for its use, and a component MUST NOT play a literal. These four values are literals, and the progress table registers no role (motion/uikit/progressBar.ts:121-123); registering them as named roles of that table and reading them through the role path would conform, unless an engineering owner exempts them.

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's indeterminate bar under a finger: no current record states Safari's 25% linear sweep, the 0.74 to 1.0 Reduce Motion pulse with no track, or whether spec:AST-094 FR4 needs motion roles for their timing. An engineering owner records that decision by commenting /approve-spec 2ea5d4697c0f4ec635fba15af6ca4709215e4931 on this pull request, and the author may do so as an engineering owner. Whatever that decision, please key the touch sweep on :dir(rtl) (ProgressBar.tsx:438), because a left-to-right bar inside a right-to-left page is empty for two thirds of each cycle, land #8225 and its parents first so this diff is its own 699 lines, and attach real iOS Safari and Android Chrome recordings.

[Automated review]

[astracat-bot]

This key matches any right-to-left ancestor, while the 25% segment sits at the start of its own region, so a left-to-right bar inside a right-to-left page sweeps left off the track. On a 370 px track, 92.5, 57.8, 23.1 and 0 px are visible at 0, 125, 250 and 500 ms, and the bar is empty from 333 to 1,667 ms of each 2 s cycle. design:bidirectionality DR3 asks ordered progression to follow the containing region's direction. Keying the sweep on ':dir(rtl)', as the determinate fill does at lines 356 and 369, fixes it; a left-to-right-inside-right-to-left test like the one in ProgressBarMotion.a11y.chromium.spec.ts would keep it fixed.

[astracat-bot]

These are literals played in place of motion roles. spec:AST-094 FR4 says every duration and curve a touch presentation plays MUST be a motion role named for its use and that a component MUST NOT play a literal, and registerProgressBarTable() registers progress with no roles. Unless an engineering owner rules otherwise on the open question, name the sweep, the pulse and the linear curve as roles in the generated table (DEC-5) and read them here.

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's indeterminate bar under a finger: no current record states Safari's 25% linear sweep, the trackless 0.74 to 1.0 Reduce Motion pulse, or whether spec:AST-094 FR4 needs motion roles for their timing. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision, these changes are still needed:

• Land #8225 and its parents first, or retarget onto #8225, so this diff is its own 699 lines rather than 18,847.
• Key the touch sweep on :dir(rtl) (ProgressBar.tsx:438), because a left-to-right bar inside a right-to-left page is empty for two thirds of each cycle.
• Attach real-device iOS Safari and Android Chrome recordings for the touch claims.

[Automated review]

[astracat-bot]

This key matches any right-to-left ancestor, while the 25% segment sits at the start of its own region, so a left-to-right bar inside a right-to-left page sweeps left off the track: on a 370 px track 92.5, 57.8, 23.1 and 0 px are visible at 0, 125, 250 and 500 ms, and the bar is empty from 333 to 1,667 ms of each 2 s cycle. design:bidirectionality DR3 asks ordered progression to follow the containing region's direction. Keying the sweep on ':dir(rtl)', as the determinate fill does at lines 356 and 369, fixes it; a left-to-right-inside-right-to-left case like the one in ProgressBarMotion.a11y.chromium.spec.ts would keep it fixed.

[astracat-bot]

These are literals played in place of motion roles. spec:AST-094 FR4 says every duration and curve a touch presentation plays MUST be a motion role named for its use and that a component MUST NOT play a literal, and registerProgressBarTable() registers progress with no roles. Unless an engineering owner rules otherwise on the open question, name the sweep, the pulse and the linear curve as roles in the generated table (DEC-5) and read them here.

[astracat-bot]

Approval is on hold until an engineering owner settles the governing spec for ProgressBar's indeterminate bar under a finger: no current record states Safari's 25% linear sweep or the trackless 0.74 to 1.0 Reduce Motion pulse (spec:AST-094 leaves each component's touch presentation to its own record, and the ProgressBar record is still a draft), and the owners also need to say whether AST-094 FR4's motion roles apply to that timing. An engineering owner can record the decision by commenting /approve-spec <full head SHA> on this pull request (the author may do so as an engineering owner), name the record that should state it, or keep today's slide on touch. Whatever that decision, these changes are needed:

• Land #8225 and its parents first, or retarget onto #8225, so this diff is its own 702 lines rather than 17,109.
• Key the touch sweep on :dir(rtl) instead of :is([dir="rtl"] *) (ProgressBar.tsx:438), because a left-to-right bar inside a right-to-left page is empty for two thirds of every cycle.
• Attach recordings from a real iPhone in Safari and a real Android phone in Chrome for the touch claims, as AST-094's platform support requires.

[Automated review]

[astracat-bot]

This key matches any right-to-left ancestor, while the 25% segment sits at the start of its own region, so a left-to-right bar inside a right-to-left page plays the right-to-left sweep from the left end and leaves the track: on a 370 px track 92.5, 57.8, 23.1 and 0 px of it are visible at 0, 125, 250 and 500 ms, and the track is empty from 333 to 1,667 ms of every 2 s cycle. design:bidirectionality DR3 asks ordered progression to follow the containing region's direction. Keying the sweep on ':dir(rtl)', as the determinate fill does at lines 356 and 369, fixes it; a left-to-right-inside-right-to-left case in ProgressBarTouch.a11y.chromium.spec.ts would keep it fixed.

[astracat-bot]

Changes requested: the touch timing and the reduced-motion pulse match the ProgressBar record and their tests pass, but three small fixes are needed first.

• With forced colors under a coarse pointer, the new timing drives the fill's width transition (800 ms, linear), which AST-094 FR5 rules out; land the sized fill at once there and add a forced-colors test.
• Remove the dependency-free useEffect that calls registerProgressBarTable() in ProgressBarTouch.ts, since nothing reads the registry at runtime.
• Scope the reduced-motion changeset's 3:1 promise to the built-in tokens: in the Neutral, Butter and Matcha themes, some tones fall below 3:1 at the 0.84 floor.

[Automated review]

[astracat-bot]

Under forced colors this fill transitions width (line 333), and this coarse key has no forced-colors exception, so on a touch screen with a contrast theme a value change animates layout for 800 ms, linearly (10% → 90%), instead of landing. AST-094 FR5 says a touch presentation's animation MUST NOT animate layout properties. Nesting '@media (forced-colors: active)': '0s' under this key would land the sized fill at once there; a forced-colors case asserting no running width transition would keep it fixed.

[astracat-bot]

This Effect names no external system and depends on nothing (react-component-runtime INV3), and nothing in ProgressBar reads the role registry at runtime: resolveMotion returns the value it is handed, and the role-table generator and roles tests register every table themselves. Deleting it (and the note in motion/uikit/progressBar.ts that the touch layer calls it) keeps behaviour the same; if a runtime entry is wanted, register at the read site as motion/coast.ts does.

[astracat-bot]

The 3:1 promise holds for the built-in light and dark tokens (AR4 and the pulse-floor test), but not in every theme: at the 0.84 floor, Neutral light success goes from 3.39:1 to 2.79:1, Butter dark success from 3.12 to 2.64, Matcha light success from 3.11 to 2.56 and Matcha dark error from 3.23 to 2.66. Scoping it, for example to "in the built-in light and dark tokens", or dropping the clause, would keep the release note accurate.

[astracat-bot]

Ready to approve: the touch timing and the reduced-motion pulse match the ProgressBar record, and the forced-colors fill, the extra Effect and the changeset wording from the last review are all fixed. The new Chromium specs and the unit tests pass. The inline notes are optional comment cleanups (a FillStyle comment that drifted onto PulseStyle, one long comment and one long file header).

[Automated review]

[astracat-bot]

Optional: the three comment lines just above (517-519) explain FillStyle, but this new type now sits between them and type FillStyle. Move them down to sit directly above type FillStyle.

[astracat-bot]

Optional: this states a real quirk, but the first sentence runs to about 55 words. A shorter form that keeps only the reason:

// CSS shortens a transition that reverses to its own start value, so a
// return mid-flight (10 → 90 → 10) would run at half length.
// `--_progress-bar-flip` steps 0, 1, 2 on each change and shifts the fill by
// that many hundredths of a pixel. Two steps would repeat on a return.

[astracat-bot]

Optional: this header runs to 21 lines, past the roughly 12-line limit for file headers. @output can name the hook and its three variables, with the detail left to the hook's own comments.