Uh oh!
There was an error while loading. Please reload this page.
fix(approvals): render the step progress bar as a vertical stepper in both occurrences - #5570
Merged
os-sales merged 1 commit intoAug 21, 2026
Merged
Conversation
…bjectui#5554) Both the Approvals Inbox drawer and the record page's approvals panel laid the flow step strip out as a single non-wrapping flex row of `shrink-0` steps, so its min-content width was the sum of every step and grew without bound with step count and label length. A real 6-step flow with ordinary CJK step names measured 1070px inside a 527px container on a live 17.1.0 project: the drawer's bar was not scrollable at all (only the drawer panel was, so reaching steps 4-6 pushed the rest of the drawer off-screen), and the record panel's scrolled itself but still parked the tail steps behind a gesture with no affordance. Both now stack: one row per step, a badge-and-rail gutter, a wrapping label. Width is capped by the container at every step count and label length. Always vertical, with no count or measured-width threshold — the overflow is driven by intrinsic content width, so any threshold picks a cutoff that is wrong for some real flow and a measured one reintroduces a viewport-dependent branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012u2pRjcqAYtoEjgr3wwhnK
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-sales
marked this pull request as ready for review
August 21, 2026 13:49
Uh oh!
There was an error while loading. Please reload this page.
os-sales
deleted the
claude/issue-5554-approvals-step-progress-overflow
branch
August 21, 2026 13:49
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#5554
What was wrong
Both occurrences laid the approval step strip out as a single non-wrapping flex row whose steps were each
shrink-0. A flex row's min-content width is the sum of its non-shrinkable items, so the strip's intrinsic width grew without bound with step count x label length. On a live 17.1.0 project a real 6-step flow with ordinary CJK step names measured 1070px inside a 527px container.The two hosts failed differently, and neither failure was recoverable by the reader:
ApprovalsInboxPage(inbox drawer)RecordApprovalsPanel(record page)overflow-x-autoon the stripIn both, readers took the clipped strip for the end of the data; the reporting customer acceptance tester said so verbatim. Widening the window does not help — the drawer is fixed-width, and clipping was identical at 1440x900 and 1920x1000.
The fix, and why always vertical
Both now render as a column: one row per step, a badge-and-rail gutter, a wrapping label. Width is capped by the container at every step count and every label length, which also suits both hosts' tall-and-narrow aspect ratio.
The card left the layout choice open between always-vertical and vertical-past-a-threshold. Always vertical, with no step-count and no measured-width threshold, because:
flow_steps.length > 1, and label length is unbounded and unowned by us.ResizeObserver/layout-effect that no unit test in this repo can exercise.Horizontal-with-scroll was rejected for both occurrences per the card: it leaves steps behind a gesture.
The rail segment below each step keeps the tint rule the horizontal connector used — it is coloured by the step it leads into — so the "how far has this flow got" reading is unchanged.
Verification
pnpm exec vitest runfrom the repo root (per AGENTS.md; never--filter, never paths after--)."The stepper renders" is green against the broken code, so that is not what is asserted — and this was measured, not assumed. A throwaway presence-only probe (finds the stepper by its accessible name, finds all six labels) run against the reverted
RecordApprovalsPanelpassed 1/1. The committed suites, run against the same reverted components, failed 8/8.The suites assert the property the defect names — no element may pin intrinsic width and none may be a horizontal scroller:
flex-col), and each step owns a row (listitem);shrink-0— the class that made min-content width the sum of every step;min-w-0(a flex item defaults tomin-width:auto= min-content, which is how a long label pushes a row past its container) and none iswhitespace-nowrap;overflow-x-auto/-scrollscroller;Regimes exercised. The reported failing regime directly — 6 steps, the reporter's own CJK labels verbatim (they are the regime: 8-16 CJK characters is an ordinary business step name and roughly double the width of the same character count in English, so English fixtures would quietly leave the failing regime). Plus the guard boundary (2 steps) and well past the report (12). A 2/5/6/12 sweep pins that the root and row layout classes are byte-identical across all four, so no count threshold can put some other flow length back on the old path.
Viewports. No browser is available in this container (
chromiumis not installed), so there is no real-layout measurement here and none is claimed. Instead of sampling widths, the suites pin the fact that makes sampling unnecessary: the stepper carries no breakpoint-prefixed axis/overflow/width class and no measurement, so its layout is the same at every viewport by construction.Gates run — all against
cc07ae9af, this PR's headTest Files 2 passed (2)/Tests 8 passed (8)apps/consoleproject plus every approvals-surface suite inapp-shellandplugin-detailTest Files 71 passed (71)/Tests 772 passed (772)turbo run type-check(@object-ui/console,@object-ui/app-shell, incl.tsconfig.test.json)Tasks: 37 successful, 37 totalpnpm lint— full farm, uncachedTasks: 47 successful, 47 total·Cached: 0 cached, 47 total· 0 errors repo-widepnpm check:control-bytesOK (scanned 4626 tracked text file(s); skipped 85 binary)check-changeset-presence.mjs4 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)check-changeset-no-major.mjsNo changeset declares a major bump.check-changeset-fixed.mjsAll workspace packages are in the changeset fixed group.pnpm check:i18n-keysEvery in-scope call-site key resolves against the en pack (2918 keys)pnpm check:i18n-driftNo en value changed in this range.pnpm check:i18n-dead-keyspnpm check:skills-pathsOK (95/96 stated path(s) resolve across 18 guide file(s); 1 baselined)pnpm check:doc-typesEvery documented component type is registered.pnpm check:doc-snippetsEvery covered documentation snippet compiles against the built types.Exit codes were captured before any pipe (
cmd > log 2>&1; EXIT=$?), and each row quotes the gate's own verdict line rather than$?.check:doc-snippetsfirst refused to run with@object-ui/cli declares types at packages/cli/dist/index.d.ts and it is not on disk— an unbuilt-workspace precondition, unrelated to this diff. Building that one package turned it green; recorded so the red is not mistaken for a finding.No new i18n keys: both steppers keep the existing
approvalsInbox.stepProgresscall site, which is already present in all ten locale packs.Not run locally, left to CI: Test shards 1-4/4 (the console project and the entire approvals surface were run; the rest of the farm is CI's), Build & E2E (
@object-ui/app-shell:builddid run and pass, as a turbo dependency of type-check), and Bundle Analysis. This is a declared narrowing, not a skip.Scope
Exactly the declared file surface — the two components, their tests, and a changeset. No breach.
packages/app-shell/src/hooks/useRecordApprovals.tswas read (it owns theflow_stepstype) and not modified; the fix needs no data-shape change.The two steppers are kept identical by hand rather than extracted to a shared component: they live in different packages and deduplicating them is a refactor with its own surface, outside this fence. Filed separately as #5569.
Generated by Claude Code