@trinityui/design-system 2.13.0 → 2.13.1

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # @trinityui/design-system
 
+## 2.13.1
+
+### Patch Changes
+
+- **Behavior correction (a, b, c)**: LandingPage's built-in hero gradient passes text contrast, and the client selector follows `clientName` on every render. ([`cc88eff`](https://github.com/Trinity-UI-Components/trinity-design-system/commit/cc88eff6bf51572a3ab1d1effbac196e96301076))
+
+  These corrections ship in a patch (2.13.1) by owner decision of 2026-10-11, as PR #10's AITextBlock correction did.
+
+  LandingPage without `backgroundImage` or `backgroundGradient` drew a navy, purple and coral gradient that left the white subtitle at 3.4:1 towards the coral end (WCAG 1.4.3 asks for 4.5:1). The built-in gradient is now navy, indigo and purple: 6.8:1 or more across the hero, the same in light and dark mode. The LandingPage stories follow the owner's review: the Default story uses Smooth Abstract 13, Hero Tones uses light gradient 2 and dark gradient 4, and the Background Gallery story is gone (the Assets pages keep the images).
+
+  TopNavHeader and TopNavWithSidebar copied `clientName` into their own state on the first render and ignored every later value, so an app that switched clients elsewhere kept showing the old name. `clientName` now controls the selector (MUI `useControlled`, as `selectedNavItem` does since 2.13.0), and the new `defaultClientName` (default `'Long Client Name 1'`, as before) seeds an uncontrolled selector that a pick changes. AppLayout passes both through.
+
+  Also in this pull request, release tooling only: the publish workflows wait up to 2 minutes for npm to show a just-published version before tagging (known issue 1.19), and the GitHub release links to release notes longer than its 125,000-character limit instead of failing (1.20).
+
+  Visual review: https://github.com/Trinity-UI-Components/trinity-design-system/pull/43
+
 ## 2.13.0
 
 ### Minor Changes

package/MIGRATION.md

@@ -22,6 +22,9 @@ This file is written in release PRs. A feature PR describes its correction in it
 
 | Version | Component | Change | ADR-23 test | Opt-out | Consumer action |
 |---|---|---|---|---|---|
+| 2.13.1 | `LandingPage` with neither `backgroundImage` nor `backgroundGradient` | **Before:** Navy, purple and coral hero gradient; the white subtitle fell to 3.4:1 towards the coral end. **After:** Navy, indigo and purple; the subtitle stays at 6.8:1 or more. **Verified by:** `landing-page-hero-tone.test.tsx` "LandingPage built-in hero gradient (known issue 3.1)" | a, b, c | LandingPage: pass the old gradient as `backgroundGradient` (fails WCAG 1.4.3). TopNavHeader, TopNavWithSidebar and AppLayout: pass `defaultClientName` instead of `clientName` to let the selector keep the user's pick | Nothing. For the old look, pass it as `backgroundGradient` (fails WCAG 1.4.3). |
+| 2.13.1 | `TopNavHeader` / `TopNavWithSidebar` / `AppLayout` `clientName` changed after the first render | **Before:** Ignored: the selector kept the first name. **After:** The selector shows the prop on every render. **Verified by:** `TopNavHeader.test.tsx` "follows clientName on every render, not only the first" | a, b, c | LandingPage: pass the old gradient as `backgroundGradient` (fails WCAG 1.4.3). TopNavHeader, TopNavWithSidebar and AppLayout: pass `defaultClientName` instead of `clientName` to let the selector keep the user's pick | Nothing. |
+| 2.13.1 | `TopNavHeader` / `TopNavWithSidebar` / `AppLayout` with a constant `clientName` and a pick in the selector | **Before:** The pick changed the name, whatever the prop said. **After:** The pick fires `onClientChange`; the name changes when you pass the new one. **Verified by:** `TopNavHeader.test.tsx` "a pick fires onClientChange and leaves the name to the prop" | a, b, c | LandingPage: pass the old gradient as `backgroundGradient` (fails WCAG 1.4.3). TopNavHeader, TopNavWithSidebar and AppLayout: pass `defaultClientName` instead of `clientName` to let the selector keep the user's pick | Update `clientName` from `onClientChange`, or pass `defaultClientName` instead. |
 | 2.13.0 | `FileUpload` `onFilesChange` and `files` | **Before:** With `onFilesChange` but without `files`, each call carried only the latest selection and the file list never rendered. With `files` plus `onUpload`, every upload transition was computed from a stale list and emitted `[]`, so the file disappeared after selection. A failed upload, or an unmount mid-upload, left the progress interval running every 200 ms (calling `onFilesChange` when set). **After:** `onFilesChange` receives the complete accumulated list on every change in both modes, and the uncontrolled list renders. Every transition keeps the file (`pending` → `uploading` → progress → `complete` or `error`). The progress timer stops when an upload settles or FileUpload unmounts, and `onFilesChange` is not called after unmount. **Verified by:** `FileUpload.test.tsx` ([STEP3-03](docs/remediation/STEP3-03-file-upload-lifecycle.md)) | a, e | None | If you appended each `onFilesChange` payload to your own list (treating it as a delta), use it as the whole list instead (`onFilesChange={setFiles}`). If FileUpload can unmount mid-upload while your state lives on, that file stays `uploading` in your state, so take the final outcome from your `onUpload` promise. |
 | 2.13.0 | `FileUpload` image `preview` | **Before:** The object URL created for an image preview was revoked only when the user removed the file. Replaced files (single-file mode) and unmounted components leaked it. **After:** FileUpload revokes each object URL it created once the file has left the rendered list (a removal the parent declines keeps the URL) or when FileUpload unmounts. A `preview` you pass in through `files` is not revoked on replacement or unmount; as before, it is revoked when the user presses that file's remove control, even if you decline the removal. **Verified by:** `FileUpload.test.tsx` "image preview object URLs" and "preview of a declined removal (FILEUPLOAD-REG-03)" | a | None | To show a preview after that point, create your own URL from `file` (`URL.createObjectURL(file)`) and revoke it yourself. |
 | 2.13.0 | `FileUpload` upload progress bar | **Before:** The progress bar had no accessible name (axe `aria-progressbar-name`). **After:** Each progress bar is named "Uploading {file name}". **Verified by:** `FileUpload.test.tsx` "Accessibility" | b | None | Nothing. Tests can query it with `getByRole('progressbar', { name: 'Uploading report.pdf' })`. |