mirror of
https://github.com/we-promise/sure.git
synced 2026-09-09 08:34:26 +00:00
210de793c4eacd7f9d8d33664a191ed330c2eb7f
13
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Brandon
|
fe0d27471d |
feat(bills): the bills pages, calendar feed and in-page AI helpers (#3202)
* feat(bills): the bills pages, calendar feed and in-page AI helpers Second of three chunks carved out of #3083, stacked on the schema and domain core. This is everything a user sees and clicks. The whole surface sits behind the preview flag, so it is unreachable until someone opts in. Pages, all under one nav entry: - the pay run, a month calendar, the full bills table, and the paycheck planner - a detail drawer per bill, with payment history, price changes and cost analytics - create and edit flows for bills, subscriptions, installment plans and income The overview marks pay periods inside the month, so a weekly paycheck no longer reads as one undifferentiated month of bills. Markers appear only when income actually subdivides the month, which means monthly and undeclared income render exactly as before and there is no new setting to configure. Navigation and design system: - one preview-gated nav item shared by the desktop rail and the mobile bar - DS::Sparkline for payment-history charts, replacing raw SVG in views - status badges render through DS::Pill rather than hand-rolled spans - the suggestions panel is a disclosure that remembers being collapsed, per device, the way privacy mode and the sidebar width already do - every surface reflows to phone widths without horizontal scroll Calendar feed: a signed ICS feed per family, served sessionless by token, with a reset that revokes previously shared URLs. In-page AI helpers: smart fill on the bill form and a smart configuration proposal on an existing bill, each reading a bounded slice of charge history. Provider-side prompt assembly sits behind the existing LlmConcept interface, with an implementation for each of the two providers. These belong here rather than with the assistant tools because they are buttons on these pages and lean on the provider suggester, not on the tool registry. Suite 7,776 runs green apart from the pre-existing passkey-session flake, which passes standalone. Rubocop clean, eager loading verified. The hosting guide for the feature ships here rather than with the schema, since its instructions walk pages this PR introduces. * Render the suggested strip through DS::Disclosure The hand-rolled details pair predates the component. The card_inset variant is the same shape, so the strip now inherits the design system chrome, and the persisted-disclosure controller rides along unchanged. * Route the remaining hand-rolled chips through the design system The subscription-state chips, rule-match chips and match-reason chips become DS::Pill, with the state chips extracted to one shared partial so the drawer and the summary tab stop carrying copy-pasted markup. The AI prompt chips become DS::Button and the bills-index filter becomes DS::SearchInput, both of which this PR already uses elsewhere for the same shapes. * Fix erb_lint whitespace offenses in bills views * Address the post-ready review round * Require a writable destination account and gate the feed on preview * Reject an unresolvable declared account out loud |
||
|
Guillem Arias Fauste
|
77dda53ffb |
feat(ds): one canonical focus ring across primitives (#2140)
* feat(ds): one canonical focus ring across primitives (#2136) Replaces the grab-bag of per-primitive focus indicators (neutral ring-alpha-black/white, outline-gray-900/white, faint form-field ring-4) with a single recipe — the #1737 accessibility follow-up. - New --color-focus-ring token: blue-600 (light) / blue-500 (dark), >=4:1 against both surfaces. - Canonical .focus-ring / .focus-ring-within in components.css: a 2px outline + 2px offset on :focus-visible only. Outline (not a box-shadow ring) so the offset gap is transparent on any surface with no layout shift; :focus-visible so it never shows for mouse/touch. - Applied to every focusable DS primitive: Button (had none), Link, Disclosure summary, Tabs nav, MenuItem (replaces the browser-default box), SearchInput, Tooltip trigger, Popover trigger, Select panel (focus-within), Toggle (peer-driven outline-focus-ring). .form-field adopts it via :focus-within, replacing the ~1:1 ring-4. - Dialog close button is a DS::Button icon variant, so it inherits the focus-visible-only ring and keeps no resting border (fixes "stuck ring"). Verified in-browser, light+dark: focus-visible ring on button, input, and full-width menu row — consistent blue 2px+offset, legible on both surfaces. Remaining follow-up: >=44px touch targets (disclosure trigger, composer send); bespoke notification / account-new close buttons that still carry a permanent border. * fix(ds): #2136 interactive-state follow-ups — touch target + close-button chrome - Disclosure default trigger: add min-h-11 (44px) so the standalone disclosure summary clears the touch-target minimum (was px-3 py-2 ~36px). Composer send + the coming-soon icons are already DS::Button icon/md (w-11 h-11). - Notification close buttons (sync_toast, notice): drop the resting border-alpha-black-50 box ("frame shouts, glyph muted"); keep a bg-container + shadow-xs chip so the corner control stays visible over the page, and brighten the muted glyph on hover (text-subdued -> hover:text-primary). * refactor(ds): focus ring -> neutral hugging box-shadow (was blue outline) Per design feedback: the blue 2px outline + 2px offset read as a loud, detached frame on the otherwise-neutral UI. Switch the canonical .focus-ring to a soft box-shadow ring that hugs the control (follows border-radius, no gap), in the theme-aware neutral focus-ring token (alpha-black/white-400). Transparent outline kept as a forced-colors fallback; toggle peer-driver switched from outline-* to ring-* to match. Still one token, :focus-visible only. Strength is tunable (currently subtle ~1.5:1). * fix(ds): focus ring vanished on shadowed controls — outline, not box-shadow The neutral box-shadow ring lived in the components layer, so any utility-layer shadow-* (or .form-field's focus-within:shadow-none) on the same element overrode it and the ring silently disappeared on shadowed buttons/inputs. Draw the same subtle neutral ring with a hugging `outline` (outline-offset: 0) instead — a separate property with no box-shadow conflict, and it doubles as the forced-colors indicator. Toggle peer-driver switched ring-* -> outline-* to match. Look is unchanged (neutral, hugging, subtle); it just no longer vanishes. * fix(a11y): enlarge sync-toast close-button touch target (p-0.5 -> p-1.5) The hover-revealed close button had ~2px padding around a 20px icon (~24px total), at the WCAG 2.5.8 AAA boundary. p-1.5 brings the interactive area to ~32px. Addresses CodeRabbit review on #2140. * fix(ds): keep form-field's resting halo; stop the outline color flash Two testing findings: - .form-field reverts to its original always-on soft ring (focus-within ring-4 at low alpha, theme-aware) instead of adopting the keyboard-only outline. It's a resting decoration, not a focus indicator, and the lower-opacity halo was the better look. The canonical block's comment documents the deliberate opt-out. - .focus-ring/.focus-ring-within now carry a base transparent 2px outline so consumers with transition-all (form-field had it) animate transparent -> token on focus instead of passing through currentColor, which flashed as a black border appearing and then fading out. * feat(ds): focus-ring token clears WCAG 3:1 non-text contrast alpha-black-400 (20%) measured ~1.6:1 against white — visible but below the AA bar for focus indicators. Bump to the 700 stop (50%): ~3.95:1 on light containers, ~4.6:1 on dark. Recipe unchanged; one token edit via tokens:build. * fix(ds): ring the hand-rolled privacy toggle too The header pair showed two different focus treatments: panel-right (a DS::Button) got the new token ring while the hand-rolled privacy toggle next to it fell back to the browser-default ring — the sweep covered DS primitives but not bespoke buttons. Both privacy toggles (mobile + desktop) now carry .focus-ring. Also documents the transition interplay on the focused-state rule: consumers with transition-colors fade the ring in over 150ms because Tailwind v4's color transition list includes outline-color. Verified settled value at the intended 50% alpha via Playwright. * fix(ds): ring the sidebar and settings nav links The reshoot caught both nav species falling back to the browser's blue default ring — main sidebar items and settings nav items are bespoke link_to markup the primitive sweep missed, and they're the primary keyboard path in the app. Both adopt .focus-ring (main nav adds rounded-lg so the outline follows a shape). * fix(ds): retire the legacy base-layer button ring for the canonical outline The @layer base button rule still painted a ring-2 ring-offset-2 box-shadow on :focus-visible. Box-shadow and outline are independent properties, so .focus-ring (an outline) could never clear it and every button-tag primitive double-painted both indicators on keyboard focus. Apply the canonical recipe to the base button rule itself: every <button> now gets the transparent resting outline + focus-ring token on :focus-visible by default. Two bespoke buttons suppressed the outline with focus:outline-none and relied on the base ring for their keyboard indicator (category dropdown rows, the sign-up password toggle). Drop the suppression so they pick up the canonical outline — :focus-visible keeps it keyboard-only, which is what the suppression was protecting against anyway. * fix(ds): segmented control adopts the canonical focus recipe The segment rule inlined its own focus-visible outline (offset 2, alpha-400 colors) with a comment noting it was temporary until the canonical token landed — this branch is that token. Drop the inlined utilities: button segments get the outline from the base button rule, and link segments now carry .focus-ring. |
||
|
Guillem Arias Fauste
|
c05a64ee9b |
fix(ds): canonical destructive red → red-500 (token + button) (#2245)
* fix(ds): canonical destructive red → red-500 (token + button) Per the resolved color decision, --color-destructive moves from red-600 (#EC2222) to red-500 (#F13636), aligning the destructive token with the red-500 already used app-wide for negative amounts and error text. - design/tokens/sure.tokens.json: destructive, border-destructive and button-bg-destructive (red-600→red-500) + button-bg-destructive-hover (red-700→red-600); dark values unchanged (red-400 base / red-500 hover). - Regenerate _generated.css. - buttonish.rb: the destructive button now uses the theme-aware button-bg-destructive / -hover utilities instead of hardcoded bg-red-600/700, removing the last raw-palette destructive bypass. Part of #2134. * fix(ds): keep destructive button fill at red-600 for white-label contrast Addresses review (Codex P2): the canonical-destructive flip to red-500 also lowered the solid destructive button fill to red-500, dropping white-on-red label contrast to ~3.95:1 at text-sm. Keep button-bg-destructive at red-600 / hover red-700 (white-on-red ~4.36:1 — the prior level, no regression). --color-destructive and border-destructive stay red-500: those are red-on- white text/border usages where red-500 is the chosen canonical hue. Solid white-on-red fills legitimately use a darker shade. |
||
|
Guillem Arias Fauste
|
7a0665a8f6 |
fix(ds): one height rail for icon and text buttons (#2202)
* fix(ds): put icon buttons on the text-button height rail Icon-only DS::Button containers were 32/44/48px squares while text buttons of the same nominal size render ~28/36/48px tall, so every mixed header row (icon menu trigger next to text buttons — the transactions index, account pages, the app header) sat misaligned. - buttonish SIZES: icon containers now share the text rail (sm w-7, md w-9, lg w-12 unchanged). - DS::Popover's hand-rolled w-11 trigger joins the rail at w-9. - The layout's hand-rolled privacy toggle (mobile + desktop) matches the md icon-button chrome: w-9, rounded-lg, container-inset hover — it sat at w-8 with a different hover next to a DS icon button. - DS::Select's panel adopts shadow-border-lg, the elevation Menu and Popover already use, replacing the weaker shadow-lg+border-xs combo. Measured on the transactions header after the change: 36/38/36px. * fix(ds): keep the 44px touch target on coarse pointers The height rail trades icon-button size for row alignment, which is a pointer-precision tradeoff: WCAG 2.5.5's 44x44 minimum is about fingers, not mice. sm/md icon containers (and the two off-rail consumers: the popover trigger and the layout privacy toggles) gain pointer-coarse:w-11/h-11, so touch devices keep the full target while fine-pointer layouts get the aligned 36px row. Measured via Playwright: desktop 36x36, iPhone emulation 44x44 on both the menu trigger and the privacy toggle. |
||
|
Guillem Arias Fauste
|
5d0eb7f445 |
fix(goals): UI polish — submit validation, container-responsive cards, picker & filter fixes (#2160)
* fix(ds): disabled buttons use not-allowed cursor
Tailwind v4 preflight sets cursor:pointer on every <button>, including
disabled ones. Add disabled:cursor-not-allowed to the DS button base so
disabled buttons read as non-interactive.
* fix(goals): disable new-goal submit until required fields valid
The submit button was always enabled, and the funding-accounts checkbox
group has no native 'required', so a goal with no linked account could be
submitted and only fail server-side (422). Disable the submit until name,
a positive target amount, and >=1 account are present, and add a
submit-time guard that surfaces inline errors and focuses the first
offending field as a backstop.
* fix(goals): keep color/icon picker from shifting the form
DS::Disclosure wraps its body in an mt-2 div that sits in normal flow, so
opening the absolutely-positioned picker popover nudged the form down ~8px.
Use a raw <details> for the picker so the popover overlays without
reflowing the content beneath it.
* fix(goals): container-responsive cards, meta-line status, scrollable tabs
- Card grids + KPI strip switch from viewport breakpoints to container
queries (@container), so columns track the actual content width when the
account/AI sidebars are open instead of crushing three columns into a
narrow center.
- Move the status pill from the title row to the meta line; the title now
gets the full header width (no more 'Hou...' truncation at 3-up). Drop
the secondary line when the pill already states it (completed / open).
- Card internals harden for narrow widths (ring shrink-0, footer wrap,
shorter 'N days left' secondary).
- Filter tabs scroll horizontally instead of wrapping 'On track' mid-label
or forcing the row wider than the viewport.
* fix(goals): only require a funding account on the create form
GoalsController#edit renders account checkboxes from visible accounts only,
so a goal backed solely by a now-hidden (disabled / pending_deletion)
account renders none checked. The submit-validation then wedged the edit
form — a name/notes change couldn't be saved even though #update preserves
existing links when account_ids is omitted. Gate the account requirement on
a require-account Stimulus value that is true only for the create form.
* fix(goals): give the color/icon picker trigger an accessible name
The hand-rolled <summary> is icon-only (pen), so screen readers announced an
unlabeled control. Add a localized aria-label.
* fix(goals): render form validation errors inline on server re-render
The client-side controller already surfaces name / amount / account errors
inline and disables submit, but a server 422 (JS disabled, or a race that
lets an invalid submit through) fell back to the top run-on banner
("X must be filled and Y and Z."). Make the existing inline error hints
server-aware so a failed submit shows the same per-field red text the
client path does, and drop the base-error banner — base only ever carries
the account requirement, which now renders beside the funding-accounts
list.
* fix(goals): blur projection chart under privacy mode
The projection chart's SVG axis labels and annotations (target, "$X short",
$200K/$400K ticks) rendered in cleartext while privacy mode blurred every
other number on the page. Tag the chart container `privacy-sensitive`, the
same wrapper-level treatment the net-worth and cashflow-sankey charts
already use, so it blurs with the rest.
* fix(goals): stop target-date input stretching when amount error shows
The target-amount / target-date row is a two-column grid. The amount
column carries its inline error <p> underneath, so when that error
appears the column grows and the default `items-stretch` makes the
sibling date input stretch to match — the date box visibly grew taller
than the amount box. Anchor the row with `items-start` so each input
keeps its natural height and the error just extends below its own column.
* fix(goals): make invalid submit announce errors instead of dead-ending
Review follow-ups:
- Swap the submit gate from the disabled attribute to aria-disabled: a
truly disabled default submit also blocks Enter-key implicit
submission, so an invalid form was a dead button with every inline
error still hidden. The button now stays clickable and lets
validateOnSubmit surface the errors; DS buttonish styles the
aria-disabled state (cursor-not-allowed + opacity-50). Side effect:
loading_button_controller submits also dim while busy, which reads as
an upgrade.
- Focus the first funding-account checkbox when accounts are the only
missing field (focus previously went nowhere).
- Drop the now-orphaned goals.goal_card.days_left_by locale key.
|
||
|
Guillem Arias Fauste
|
5abf9cb537 |
fix(ds): dark-mode token parity — contrast & state fixes (#2139)
* fix(ds): dark-mode token parity — text, borders, checkbox, toggle, over-budget badge Dark-mode contrast/parity pass (design-review epic #2134, follow-up to #1736): - text-subdued (dark): gray-500 -> gray-400; faint/eyebrow text ~3.6:1 -> ~6.7:1 (clears AA), staying below text-secondary so hierarchy holds. - border-primary/secondary/subdued (dark): +1 alpha-white step each; restores group-card edges and in-card row hairlines (border-primary 1.86:1 -> 2.8:1). Alpha keeps them surface-relative across any dark bg. - Dark checkbox: unchecked was a solid white square (read as already-selected) — now a transparent outlined box; checked/indeterminate use a white fill with a #171717 glyph (was #808080, ~2:1); added an explicit indeterminate dash; disabled muted to gray-700. - Toggle (light off-state): track gray-100 -> gray-300 plus a thumb shadow; the white-thumb-on-white-track invisible off-state now reads (dark off-track was already hardened to gray-700). - Over-budget badge: text-red-500 -> text-destructive (theme-aware, matching the on-track/near-limit siblings); in-situ dark contrast 4.18:1 -> 4.55:1 (AA). - Correct invalid icon color keys (red/yellow/green -> destructive/warning/success) on the three budget status badges. Verified in-browser, light+dark: isolated checkbox states, /accounts card borders, /reports muted text, toggle off-state, /budgets over-budget badge (in-situ 4.55:1). * fix(ds): reconcile destructive color + fix filled-pill contrast Continues the dark-parity pass (#2134): - Reconcile destructive: border-destructive and button-bg-destructive were red-500 while the destructive text/icon token was red-600. Unify on red-600 (light) / red-400 (dark) across text, border, and button — the text token can't drop to red-500 (3.96:1 on white, fails AA), so border/button move up instead. White-on-destructive-button 3.96:1 -> 4.36:1 (AA-large); hover red-600 -> red-700. - DS::Pill filled style: deepen the fill tone-500 -> tone-700. White label text on tone-500 failed AA on nearly every tone (amber 2.35:1, green 2.62:1, red 3.95:1); tone-700 clears it (amber 5.43, green 4.30, red 5.86, others 6.4-12) in both themes and removes the dark-surface glare. Date-input calendar glyph in dark verified already-correct (existing invert(1) rules; color-scheme is normal, so no conflict) — no change needed. Verified in-browser: real .button-bg-destructive (red-600) + filled pills, all tones, light and dark. * fix(ds): destructive button consumes the reconciled red-600 Follow-up to the destructive reconcile in this branch: DS::Buttonish's destructive variant still used raw bg-red-500 / hover:bg-red-600, so destructive *buttons* didn't match the reconciled destructive text/border (red-600). Align to red-600 / hover red-700 (light); dark unchanged (red-400 / red-500). White-on-red-600 = 4.37:1 (AA-large), consistent with the rest of the destructive family. * refactor(ds): tokenize budget-category badge + bar backgrounds Status-badge foregrounds already used semantic tokens (text-destructive/ warning/success) but backgrounds + progress-bar fills stayed on the raw palette (bg-red-500/10, bg-yellow-500, ...). Switch to the matching semantic tokens (bg-destructive/10, bg-warning, bg-success) — same value in light, now theme-aware in dark. Mirrors DS::Alert. Addresses CodeRabbit/Codex on #2139. |
||
|
Guillem Arias Fauste
|
2051c74559 |
fix(ds): unify SSO sign-in buttons on DS::Button; drop bespoke Google CSS (#2152)
The Google button used Google's prebuilt `gsi-material-button` (its own CSS file + hardcoded hex colors), leaving it the odd one out: capped at 400px (its `max-width` overrode `w-full`) so it sat narrower than the OpenID/GitHub buttons, and rendered as a glaring white block in dark mode with no theming. Render every SSO provider through one `DS::Button(variant: :outline, full_width: true)` so the stack is consistent and reads as secondary to the primary email "Log in" CTA. Google keeps its official multi-color "G" mark and "Sign in with Google" wording (brand-compliant) via a new `google-icon.svg` asset and an additive `icon_custom:` flag on the button (defaults false — no change to any existing button). Delete `google-sign-in.css` and its import. |
||
|
Guillem Arias Fauste
|
e07d641ead |
fix(design-system): DS::Button a11y audit — focus ring, touch target, type default, icon-only label (#1840)
* fix(design-system): DS::Button a11y audit Closes #1738. Four concrete fixes surfaced by the savings-goals audit + #1737 universal checklist: 1. Focus ring (WCAG 2.4.7). `base.css` had `focus-visible:outline-gray-900` which is **1.07:1** against the primary button's gray-900 background — invisible. Widen to `outline-2 outline-offset-2`, place outline outside the button via offset, and add a dark-mode `outline-white` so the ring is always visible against the page chrome regardless of the button surface. 2. Touch target (WCAG 2.5.5). Icon-only buttons at the default `:md` size were `w-9 h-9` = 36×36, below the 44×44 enhanced target. Bump `md.icon_container_classes` to `w-11 h-11` and `lg.icon_container_classes` to `w-12 h-12` to keep the size scale intact. `sm` stays at 32×32 (already passes WCAG 2.5.8 AA's 24×24 minimum; intentional compact-density variant). 3. Default button type. `content_tag(:button, ...)` inherits the HTML default `type="submit"`, so a DS::Button rendered inside a form steals Enter-key submission from the first text input (reproducible in the form stepper). Default to `type="button"` in the non-`href` branch; existing form submitters pass `type: "submit"` explicitly and continue to work. The `button_to` (href) branch keeps the submit default because button_to wraps its own form. 4. Icon-only accessible name. Icon-only buttons render no text node, so AT users hear "button" with no name. Derive a humanized aria-label from the icon key (e.g. `icon: "more-horizontal"` → `aria-label="More horizontal"`); explicit `aria: { label: }` on the caller still wins. Soft fallback — callers should still pass meaningful labels for richer copy. Plus: replace the stale `fg-white` icon class on the destructive variant with `text-inverse` (the `fg-*` namespace was deprecated in #1626 so `fg-white` resolved to nothing; the icon was using its helper-default color rather than the white the design intended). Out of scope: - Menu avatar trigger (custom 36×36 button bypassing DS::Button) — belongs to #1743 DS::Menu audit. - DS::FilledIcon `lg` size container (decorative, not interactive) — belongs to #1742. * fix(design-system): force type=submit on StyledFormBuilder#submit The DS::Button default-type-button change in the previous commit broke every `form.submit "Log in"` callsite because `StyledFormBuilder#submit` (app/helpers/styled_form_builder.rb) renders a DS::Button under the hood with no explicit `type:`. After the default flip, those submit buttons rendered as `type="button"`, so submitting forms (login, password reset, every form using `form.submit`) silently no-ops. CI surfaced this via ~30 system tests failing in the `sign_in` helper, which couldn't get past the login page. Pin `type: "submit"` on the DS::Button rendered by `StyledFormBuilder#submit`. The 22 view-level `f.submit` / `render DS::Button.new(type: :submit, ...)` callers already pass type explicitly and are unaffected. * fix(review): href-branch type-button bug + focus-ring tokens + profile Save submit CodeRabbit P1+P2 review on #1840: 1. button.rb: `merged_opts.delete(:href)` always returned nil because Buttonish#initialize strips :href from opts into @href, so the `if href.blank?` guard was ALWAYS true. Every DS::Button rendered via button_to (the href branch) got `type="button"` on the inner button, breaking submission of those button_to-generated forms (e.g. imports/_ready.html.erb publish button, imports/_failure.html.erb try-again button). Drop the local `href = merged_opts.delete(:href)` so the guard now reads the @href reader, leaving the href branch's HTML default intact. 2. settings/profiles/show.html.erb: the Save button is rendered with `render DS::Button.new(...)` inside `styled_form_with` (not via form.submit), so the StyledFormBuilder#submit type-pin from |
||
|
Guillem Arias Fauste
|
0d32bb70ec |
chore(design-system): swap raw gray classes for semantic tokens across remaining views (#1655)
* chore(design-system): swap raw gray classes for semantic tokens across remaining views Finalizes the raw-color sweep started in #1652 (settings) and continued in #1654 (holdings). Covers accounts, budgets, chats, pages, imports, provider integrations (mercury, lunchflow, sophtron, enable_banking, coinstats), auth flows (password reset, MFA, registrations), shared layouts, and selected DS component hover states. 35 files, ~56 line changes. Mappings (matching the patterns established in the prior sweeps): - text-white bg-gray-900 hover:bg-gray-800 (with optional focus:ring-gray-900) -> text-inverse button-bg-primary hover:button-bg-primary-hover -> focus:ring-button-bg-primary - text-gray-500 / 600 / 700 -> text-secondary - text-gray-800 -> text-primary - text-gray-400 -> text-subdued - hover:text-gray-700 / hover:text-gray-100 -> hover:text-primary - bg-gray-50 / 100 / 200 (standalone) -> bg-surface-inset - bg-gray-500/5 -> bg-gray-tint-5 - bg-gray-500/10 -> bg-gray-tint-10 - bg-gray-900 (decorative active states) -> bg-inverse - hover:bg-gray-50 / 100 (standalone) -> hover:bg-surface-inset - hover:bg-gray-300 -> hover:bg-surface-inset-hover - bg-white hover:bg-gray-100 -> bg-container hover:bg-container-hover - border-gray-300 -> border-secondary - focus:border-gray-200 -> focus:border-secondary - focus-within:border-gray-900 -> focus-within:border-primary - DS::Buttonish outline / ghost / icon hover: hover:bg-gray-100 theme-dark:hover:bg-gray-700 -> hover:bg-container-inset-hover Left intentionally raw, with rationale: - bg-gray-300 / bg-gray-400 decorative dots and avatar circles. The raw value reads OK against both bg-container variants; no semantic "neutral indicator" token exists. Same pattern as #1652 / #1654. - bg-gray-400/20 theme-dark:bg-gray-500/20 (onboardings/trial). Custom alpha tint with no equivalent token. - bg-white theme-dark:bg-gray-700 (DS::Tabs active pill, budgets tabs). Custom tab-pill pattern; gray-700 in dark mode (one shade lighter than page bg-gray-900) is intentional for visibility. - bg-gray-100 theme-dark:bg-gray-700 (DS::Toggle base bg). Closest match (bg-container-inset-hover) is semantically a hover state. - DS::Buttonish secondary variant gray-200/300/700/600 pattern. Same pattern as #1654 holdings; needs button-bg-secondary-strong from that PR. Will swap in a follow-up after #1654 merges. - disabled:bg-gray-500 theme-dark:disabled:bg-gray-400 on inverse buttons (DS::Buttonish primary, enable_banking, coinstats). Custom disabled state for the inverse pair; no token. - text-gray-300 SVG stroke (shared/_progress_circle). - bg-white text-gray-900 (layouts/print). Print contexts intentionally light regardless of theme. - bg-gray-800 / border-gray-700 / text-white / hover:text-gray-100 (impersonation_sessions/_super_admin_bar). Admin overlay styled to remain dark in both modes; not a theme-aware component. Files covered by other in-flight PRs were skipped to avoid rebase conflicts: chats/_ai_consent's fg-inverse swap (#1626), shared/_text_tooltip and shared/_money_field tooltip pills (#1626), investments/_value_tooltip (#1626), components/DS/tooltip (#1626). * fix(design-system): keep changelog avatar text raw to preserve dark-mode contrast The changelog avatar fallback (when @release_notes[:avatar] is missing) sits inside the "decorative + raw" exception list — bg-gray-300 stays fixed across themes since no semantic neutral-indicator token exists. The earlier sweep partially themed the pair: bg-gray-300 stayed raw but text-gray-600 became text-secondary. text-secondary resolves to gray-300 in dark mode, which matches the bg → text became invisible against its own background. Reverting only the text class to text-gray-600 restores the original fixed-light placeholder behavior. Both classes raw, both themes readable. * fix(design-system): address review feedback on raw-color-sweep-finalize Six issues caught by CodeRabbit + Codex review: 1. focus:ring-button-bg-primary silently emits no CSS (×6 files). button-bg-primary is a custom @utility, not a theme color, so Tailwind's ring-{name} resolution finds no --color-button-bg-primary. Replaces with focus:ring-gray-900 theme-dark:focus:ring-white — same color flip as the button bg, but resolved through theme colors so the ring actually renders. Files: lunchflow/mercury/sophtron _api_error + _setup_required, coinstats_items/new. 2. accounts/show/_activity.html.erb: focus-within:ring-gray-100 was dead (no ring-width on the parent). Removed. 3. import/confirms/show.html.erb: uniform hover:bg-surface-inset-hover applied to both active and inactive step indicators created a jarring dark-to-light flip on the active step (bg-inverse → bg-surface-inset-hover). Now hover follows the resting state: active uses hover:bg-inverse-hover, inactive uses hover:bg-surface-inset-hover. 4. password_resets/new.html.erb: bg-white left raw alongside the migrated hover:bg-surface-inset. Swapped to bg-container so dark mode flips properly. 5. registrations/new.html.erb + password_validator_controller.js: view now uses bg-surface-inset on password strength block lines, but the Stimulus controller still toggled bg-gray-200 on validate. Updated controller to add/remove bg-surface-inset matching the view, so unmet states reset to the tokenized class instead of leaving raw gray-200 stuck on the element. |
||
|
Guillem Arias Fauste
|
0fe1e06645 |
refactor(design-system): migrate fg-* utilities to text-* and remove namespace (#1626)
* refactor(design-system): migrate fg-* utilities to text-* and remove namespace The design system carried two parallel namespaces for foreground colors: text-* (canonical, ~2,000 uses) and fg-* (32 uses). Most fg-* tokens were 1:1 duplicates of a text-* counterpart. fg-gray was nearly identical to text-secondary, with a one-step shade difference in dark mode. This PR migrates all 32 usages to their text-* equivalents and removes the fg-* block from the design tokens. Closes #1606. Mapping: - fg-inverse -> text-inverse (20 usages, identical light/dark values) - fg-gray -> text-secondary (7 usages; light values match, dark is one step lighter: gray-300 vs gray-400) - fg-primary -> text-primary (3 usages, identical values) - fg-subdued -> text-subdued (2 usages, identical values) The four other fg-* tokens (fg-contrast, fg-primary-variant, fg-secondary, fg-secondary-variant) had zero usages despite being defined; they are removed without replacement. JSON / build: - design/tokens/sure.tokens.json: $version 1.0.0 -> 2.0.0 (breaking schema change per the policy added in #1620). 8 fg-* token definitions removed. - button-bg-ghost-hover's dark value still references "fg-inverse" internally; rewritten to "bg-gray-800 text-inverse" so the cleanup doesn't break that utility. - _generated.css regenerated. 42 utility blocks now (was 50). Lookbook tokens preview: - The Text & foregrounds section dropped its split between text-* (canonical) and fg-* (legacy). Now a single section listing the five text-* utilities. The "(legacy)" framing is gone since there's no legacy left. README: - design/tokens/README.md's button-bg-ghost-hover edge-case example updated to reflect the new "bg-gray-800 text-inverse" dark value. Visual review needed in dark mode: - Anywhere icons use the application_helper#icon helper with color: "default" (most icons in the app). The default class moved from fg-gray (gray-400 dark) to text-secondary (gray-300 dark), so default-color icons render slightly lighter in dark mode. - DS::Buttonish icons in secondary buttons (same shade shift). - DS::Link icons (same). - Time series chart axes (same). - All tooltips, account add flow, settings hostings buttons, invitations, AI consent, family export, danger-zone buttons -- these used fg-inverse, which is identical to text-inverse, so no visual change expected. * fix(design-system): use inverse pair on tooltips for readable dark mode * fix(lookbook): use semantic tokens in menu preview header text * fix(lookbook): set text-primary on layout body so previews inherit theme * fix(design-system): keep shadows dark-toned in dark mode Inverting shadows to white|8% on dark surfaces produces a halo effect rather than an elevation cue, and stacks redundantly with the alpha-white 1px ring already in shadow-border-*. Switch dark-mode shadows to black at progressively higher alpha (25%/30%/35%/40%/50% for xs..xl) so they read as actual cast shadows on near-black surfaces. Surface-tint differences and the existing alpha-white border ring continue to handle elevation hierarchy and edge definition. Approach matches Material 3, Apple HIG, IBM Carbon, Refactoring UI, and the dark-mode shadows used in Linear/Vercel/Stripe. * fix(design-system): set text-primary on DS::Dialog element Browser UA stylesheets apply color: black directly to <dialog>, which overrides ancestor inheritance even when a body or html ancestor sets a theme-aware color. Unstyled child content then renders black regardless of theme. Setting text-primary on the dialog element itself defeats the UA override and lets descendants inherit the semantic token. * fix(lookbook): use shadow css vars in effects preview so dark theme renders * Revert "fix(design-system): keep shadows dark-toned in dark mode" This reverts commit 3e9d76ed0beb5ac5f2acbad61e4d1c39eadc9ac2. * fix(design-system): use opacity-70 instead of text-inverse/70 in value tooltip The custom @utility text-inverse expands to @apply text-white and isn't modifier-aware, so text-inverse/70 produced no CSS at all and the muted labels fell through to inherited color (invisible on the white pill in dark mode). Replace with text-inverse + opacity-70. Same visual effect, works with the existing utility definition. |
||
|
Ellion BlessanandJuan José Mata
|
98ae6782dc |
feat(transaction): add support for file attachments using Active Storage (#713)
* feat(transaction): add support for file attachments using Active Storage * feat(attachments): implement transaction attachments with upload, show, and delete functionality * feat(attachments): enhance attachment upload functionality to support multiple files and improved error handling * feat(attachments): add attachment upload form and display functionality in transaction views * feat(attachments): implement attachment validation for count, size, and content type; enhance upload form with validation hints * fix(attachments): use correct UI components * feat(attachments): Implement Turbo Stream responses for creating and deleting transaction attachments. * fix(attachments): include auth in activestorage controller * test(attachments): add test coverage for turbostream and auth * feat(attachments): extract strings to i18n * fix(attachments): ensure only newly added attachments are purged when transaction validation fails. * fix(attachments): validate attachment params * refactor(attachments): use stimulus declarative actions * fix(attachments): add auth for other representations * refactor(attachments): use Browse component for attachment uploads * fix(attachments): reject empty values on attachment upload * fix(attachments): hide the upload form if reached max uploads * fix(attachments): correctly purge only newly added attachments on upload failure * fix(attachments): ensure attachment count limit is respected within a transaction lock * fix(attachments): update attachment parameter handling to avoid `ParameterMissing` errors. * fix(components): adjust icon_only logic for buttonish --------- Signed-off-by: Juan José Mata <juanjo.mata@gmail.com> Co-authored-by: Juan José Mata <juanjo.mata@gmail.com> |
||
|
soky srm
|
91a91c3834 |
Improvements (#379)
* Improvements - Fix button visibility in reports on light theme - Unify logic for provider syncs - Add default option is to skip accounts linking ( no op default ) * Stability fixes and UX improvements * FIX add unlinking when deleting lunch flow connection as well * Wrap updates in transaction * Some more improvements * FIX proper provider setup check * Make provider section collapsible * Fix balance calculation * Restore focus ring * Use browser default focus * Fix lunch flow balance for credit cards |
||
|
Zach Gollwitzer
|
ab6fdbbb68 |
Component namespacing (#2463)
* [claudesquad] update from 'component-namespacing' on 18 Jul 25 07:23 EDT * [claudesquad] update from 'component-namespacing' on 18 Jul 25 07:30 EDT * Update stimulus controller references to use namespace * Fix remaining tests |