kaafil-react-uikit 0.11.4 → 0.11.6

package/CHANGELOG.md

@@ -6,6 +6,54 @@ 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.6] — 2026-09-18
+
+### Fixed
+
+- **The pickup board's counter never caught up with the rows.** Tapping the
+  tick patched the traveller's own row instantly and correctly, and the write
+  reached the engine correctly — but the stop's `0 / 12 boarded` summary sat
+  unchanged until the manager left the stop and came back. `patchManifestTraveller`
+  deliberately does not reproduce the stop-level aggregate client-side, and
+  this file's own header says that aggregate "is left to a follow-up background
+  refetch"; nothing ever fired one. It now refetches on the edge where the
+  outbox goes from having work to having none. `handleBoard`'s reasoning for
+  NOT refetching on tap is untouched and still right: `mutate()` resolving
+  means the write is durably enqueued, not processed, so a refetch fired then
+  races the drain and can replace a correct optimistic row with the
+  still-`PENDING` truth. The optimistic patch and its rollback-on-failure are
+  unchanged — this only adds the reconciliation step after the server has
+  caught up.
+
+- **The board button was a step larger than its own documentation.**
+  `TravellerBoardRow.tsx` described a `--kf-space-9` circular control and the
+  CSS built it at `--kf-space-10`, which made the ring read as a large empty
+  circle with the tick at under a third of it. Sized down to the documented
+  step — still clear of the `--kf-target-min` floor — with the tick grown to
+  match.
+
+## [0.11.5] — 2026-09-18
+
+### Fixed
+
+- **The trip picker counted a leader's whole history, not their live trips.**
+  `KaafilManagerApp` skipped the picker only when `trips.length === 1`, while
+  the comment beside it already claimed "2+ live trips". So a leader who had
+  run eight departures this year and was standing on their ninth got a list of
+  finished trips as the first screen of an offline-first field app, with the
+  one that mattered somewhere down it. The rule now counts trips that are
+  `IN_PROGRESS`: exactly one live trip opens directly, however much history
+  sits behind it. Zero live trips keeps the old behaviour, so a leader whose
+  only assignment has not started yet still opens straight into it; two or more
+  live trips is a real question and still gets the picker.
+
+- **The picker listed trips in the server's order.** A February departure that
+  finished could sit above the two a leader is actually running. Rows are now
+  ordered by what the reader is looking for — under way, then confirmed, then
+  postponed, then completed, then cancelled — and within a status by start
+  date. The array is copied before sorting, so `useManagerMe()`'s own `trips[]`
+  is not reordered for other consumers.
+
 ## [0.11.4] — 2026-09-15
 
 ### Changed