kaafil-react-uikit 0.11.1 → 0.11.3

package/CHANGELOG.md

@@ -6,6 +6,61 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this package uses [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 While on `0.x` a minor bump may carry a breaking change; the entry will say so.
 
+## [0.11.3] — 2026-09-15
+
+### Fixed
+
+- **The manager's Now tab asked the same question four times.** A hook is an
+  implementation shared by its callers, not an instance shared by them: every
+  component calling a read hook gets its own state, its own effect and its own
+  request. Four components on that tab each needed `journey/capabilities`, so
+  four identical requests went out together.
+
+  `core/internal/coalesceRead.ts` is now the one place this package collapses
+  identical concurrent reads into one. Whoever asks first issues the request,
+  anyone asking while it is in flight awaits the same promise, and the entry is
+  dropped the moment it settles — success or failure, so a rejection is never
+  replayed to a caller who would have retried.
+
+  It is deliberately NOT a result cache: nothing survives the promise settling,
+  so this changes only how many requests a single moment produces, never how
+  fresh an answer is or when a refetch happens. Caching results would move
+  staleness decisions out of the hooks that own them.
+
+  Measured against a live engine, the tab's opening burst: **10 requests →
+  7, wall 2213–3552ms → 1845–2027ms**. The saving is larger than three
+  requests' worth because they were also competing with each other.
+
+- **Two more empty time columns.** `ManagerNowSection`'s timeline and
+  `ManagerOverviewSection`'s itinerary preview both reserved a fixed,
+  non-shrinking time column and rendered it empty when no block carried a
+  `startTime` — the same defect 0.10.2 fixed on the traveller surface, which
+  that release's note predicted might exist elsewhere. It did, twice. A sweep
+  of every fixed-width non-shrinking column in the package found no others.
+
+## [0.11.2] — 2026-09-15
+
+Needs an engine build carrying the widened `deleteFile` rule; against an older
+one an unconfirmed non-document answers `422`.
+
+### Fixed
+
+- **An abandoned upload can now be cleared.** Withdraw was offered only on a
+  `trip_document`, so a `booking_voucher` or `expense_receipt` whose upload
+  failed halfway sat in the list permanently — `PENDING`, no bytes, no control
+  on the row, nothing that could remove it.
+
+  Nothing can depend on a file that was never confirmed: every path that links
+  one to a parent checks `READY` first. So the purpose restriction now applies
+  only to CONFIRMED files, and a `pending`/`orphaned` row can go whatever its
+  purpose.
+
+  The dialog says something different for those, because the consequences
+  differ: an upload that never completed has no bytes and nothing on anybody's
+  share link, so the confirmed copy — "anyone holding a link loses access
+  immediately" — would be both alarming and false. It reads "Discard this
+  upload?" instead.
+
 ## [0.11.1] — 2026-09-15
 
 ### Changed