@oxy.so/bloom 3.6.0 → 4.1.0

package/docs/motion.mdx

@@ -81,3 +81,25 @@ Jest and `tsc` catch none of these. Verify in a real **foregrounded** tab — a
 hidden tab freezes plain CSS transitions too, which mimics "the class didn't
 apply". Read the class attribute, or set `transitionProperty: 'none'` before
 reading computed styles.
+
+### Static Storybook and Reanimated's CommonJS bridge
+
+A live Vite preview can animate correctly while its static build crashes in
+Reanimated's DOM updater at `Object.keys(node.props)`. Measured here: the static
+bundle left the optional `require('react-native-web/dist/exports/StyleSheet/compiler/createReactDOMStyle')`
+in Reanimated's ESM `webUtils.web` module. The browser's missing `require` was
+swallowed by its `try/catch`, leaving the DOM compiler undefined; a DOM element
+then reached the legacy component-props branch. Dev `optimizeDeps` had converted
+the same call successfully. Storybook's `build.commonjsOptions` now enables
+`transformMixedEsModules` and converts `try/catch` requires only for installed
+`react-native-web/dist/*` modules. Other optional-peer boundaries remain intact.
+The source gate guards that wiring; emitted bundle inspection and a real static
+open-overlay check are required to verify it. Reanimated remains the real package.
+
+The same static audit exposed a separate Expo bootstrap omission: `expo-image`
+read `globalThis.expo.NativeModule` after tree shaking discarded the empty web
+`ensureNativeModulesAreInstalled` bridge and its polyfill import. Expo marks the
+polyfill as side-effectful but not that bridge. Storybook narrowly marks the real
+`expo-modules-core/src/ensureNativeModulesAreInstalled.ts` module as side-effectful;
+it neither mocks Expo nor creates a replacement global. A minimal production
+bundle confirmed the installer precedes the first NativeModule read.

package/docs/navigation-banner.mdx

@@ -0,0 +1,184 @@
+---
+title: NavigationBanner
+description: Guidance while it is happening — the next maneuver, the lanes, the posted limit, and the strip that ends it.
+order: 138
+---
+
+# NavigationBanner
+
+`@oxy.so/bloom/navigation-banner`
+
+`directions` is the route BEFORE you set off: the alternatives, the summary, the
+step list. This is the route while you are on it — one maneuver at a time, over
+a map, at arm's length.
+
+```tsx
+import {
+  ArrivalBar,
+  LaneGuidance,
+  NavigationBanner,
+  SpeedLimitPill,
+} from '@oxy.so/bloom/navigation-banner';
+
+<NavigationBanner
+  maneuver="right"
+  distance="400 m"
+  instruction="Carrer del Roure"
+  thenManeuver="left"
+  then="onto Passatge de l'Om"
+>
+  <LaneGuidance lanes={lanes} />
+</NavigationBanner>
+```
+
+## It reuses `directions`' maneuvers, it does not restate them
+
+`maneuver` is `DirectionsManeuver` and the glyph comes from
+`DIRECTIONS_MANEUVER_ICON`. A banner with its own arrow set would be a second
+opinion about what "slight right" looks like, drawn next to a step list that
+already had one — and the two would drift at the first icon change. The
+announcement uses `DIRECTIONS_MANEUVER_LABELS` for the same reason.
+
+`LaneDirection` is a SUBSET of the same vocabulary: a lane arrow is a maneuver
+drawn small, with the members that make no sense painted on tarmac (`depart`,
+`arrive`, `board`, …) left out.
+
+## The pane is a `GlassIsland`, at a surface radius
+
+Guidance is drawn over tiles Bloom does not own, and the island is the one
+material in the library priced for that — a translucent pane that takes its fill
+from a surface Bloom DOES own, so the text on it is legible whether the map
+underneath is a night satellite tile or a white street map.
+
+It is asked for `radius: 16` rather than its default capsule. A banner is a
+surface; the pill rung belongs to button-like controls.
+
+The island also mounts the `ControlSurface` the controls inside it read, which
+is why nothing here writes `variant="glass"` on anything.
+
+## The row
+
+| part | rung |
+| --- | --- |
+| tile | 56 square, 12 radius, the state's tone as a tint, the glyph at 40 in that tone's accent |
+| headline | `title-2-semibold`, TABULAR — the distance |
+| instruction | `headline-medium`, up to two lines — the street |
+| then | `body-2-medium` behind a full-bleed rule |
+| children | behind a second rule |
+
+The distance is the figure and the street is under it, because a driver reads
+"how far" first and "onto what" second. Without a distance the street is
+promoted to the figure rung rather than sitting small under an empty line —
+which is what an arrival banner ("Arriving at Plaça de les Bruixes") looks like.
+
+Tabular numerals matter more here than anywhere else in Bloom: the distance
+counts down continuously, and proportional digits make the street name under it
+shuffle sideways several times a second.
+
+## `off-route` and `rerouting` are this component
+
+Not a second surface. They take the same strip, in the same place, at the same
+moment — a different pane appearing where this one was is a jump, and the driver
+has to re-find the thing they were already reading.
+
+What the state changes:
+
+| state | glyph | tone | headline |
+| --- | --- | --- | --- |
+| `guiding` | the maneuver | `primary` | the distance |
+| `off-route` | a warning | `error` | "Off route" |
+| `rerouting` | a loop | `warning` | "Finding a new route" |
+
+`rerouting` is deliberately NOT the error tone. Nothing is wrong yet, the app is
+working, and a red banner at that moment tells a driver to act when the only
+correct action is to keep driving.
+
+In both states the maneuver stops being announced. A reader told to turn right
+while the car is off the route has been told the one thing that is no longer
+true.
+
+## It is one utterance
+
+The glyph is the only thing on screen that says which way to turn, and a glyph
+says nothing aloud. So the maneuver row is a single `img` named by
+`describeNavigationBanner` — "400 m, Turn right, Carrer del Roure, then turn
+left onto Passatge de l'Om" — with its drawn text hidden from assistive
+technology so the distance is not read twice.
+
+`children` sit OUTSIDE that name. A lane row and a speed sign each announce
+themselves, and folding them into the banner's sentence would make one
+four-clause utterance that changes every few seconds.
+
+## LaneGuidance
+
+Lanes left to right as the driver sees them, numbered from 1 in the
+announcement, because that is how you count them through a windscreen.
+
+- A lane you may use takes the accent's tint; one you may not takes no fill at
+  all. Two levels, not three: the question is binary.
+- `preferred` picks the one arrow to take from an allowed lane and leaves its
+  siblings at the quiet rung — a lane that also goes straight on is still the
+  lane you want.
+- A quiet arrow sits at the GRAPHICAL contrast rung (3:1), not a text one. It is
+  a glyph, and flooring it at text contrast would make the lanes shout over the
+  maneuver above them.
+- A lane with several arrows grows sideways rather than stacking them. A cell
+  taller than its neighbours breaks the count.
+
+The row announces "Lane guidance, 4 lanes, use lane 3 and lane 4", and still
+announces the count when none of them is yours.
+
+## SpeedLimitPill
+
+A 48 circle with a 4 ring, on the same chrome surface every floating map piece
+paints, with `shadow-s`. It is a CIRCLE because it is a sign, not a capsule of
+text.
+
+`exceeded` FILLS the sign with its tone and takes that fill's own on-colour for
+the number. A sign that merely got brighter is a sign a driver reads as the same
+sign; the change has to survive a glance, in daylight, at an angle. Nothing
+animates: a warning that flashes in a car asks for attention the road needs.
+
+`tone` defaults to `error` and exists because not every jurisdiction posts a red
+ring.
+
+## ArrivalBar
+
+The bottom strip: when you get there, how long is left, how far is left, and the
+way out.
+
+Three readings of EQUAL weight, each `title-3-semibold` and tabular over its own
+caption. Peers because the driver is asking a different question of each one and
+none of them is the answer to the other two.
+
+The ending action is `Button` in `destructive` **at the 44 rung** — larger than
+looks right in a screenshot, because it is pressed by a thumb, in a moving car,
+at the bottom of the screen. It keeps its own chrome inside the island on
+purpose: a control painted flush with the pane would be the quietest thing on a
+strip whose only action stops the navigation.
+
+### Why this is not `OrderStatusBar`
+
+They look alike and they answer differently shaped questions, and the shape is
+the whole component.
+
+`OrderStatusBar` has ONE headline with an arrival reading beside it, a glyph
+tile, a quiet second line and a progress meter. It says "here is what is
+happening, and here is how far along it is" — it is for a journey you are
+WAITING for. `ArrivalBar` has three readings of equal weight, no state and no
+meter: the journey is happening, you are on it, and you pick whichever of the
+three you wanted.
+
+Giving `OrderStatusBar` a three-figure mode would be a second layout behind a
+prop; giving `ArrivalBar` a status line and a meter would be a tracker for a
+trip the user is driving.
+
+What they do share is written down rather than duplicated: the same surface
+rung, the same tabular figures, and the same refusal to compute anything —
+neither reads a clock, formats a duration or knows what a kilometre is.
+
+## Nothing here computes
+
+Every string is pre-formatted by the app: the distance, the ETA, the remaining
+time, the limit. There is no clock, no unit conversion and no route state
+machine in this family.

package/docs/note-card.mdx

@@ -0,0 +1,131 @@
+---
+title: NoteCard
+description: One note as a preview — two densities, a tinted wash, a checklist body and the bulk-selection state a notes app lives in.
+order: 106
+---
+
+# NoteCard
+
+A note, previewed. It is the cell of a board, the row of a list, and the thing a
+bulk action is applied to — one component, because those are the same note.
+
+```tsx
+import { NoteCard } from '@oxy.so/bloom';
+
+<NoteCard
+  title="Harbour walk — what to bring"
+  excerpt="Slack water is at 06:40, which gives us about forty minutes…"
+  tags={['field notes', 'tide']}
+  meta={{ edited: '2 min ago', notebook: 'Field notes', attachments: 2 }}
+  pinned
+  onPress={open}
+/>
+```
+
+## The two densities are one component
+
+|  | `grid` | `row` |
+| --- | --- | --- |
+| padding | 16 | 12 |
+| radius | `radius-12` | `radius-8` |
+| title | 2 lines | 1 line |
+| excerpt | 4 lines | 1 line |
+| checklist preview | 4 items | 2 items |
+| tags | their own row | folded into the metadata line |
+| metadata | last line | inline after the excerpt |
+| min height | — | 72 |
+
+`grid` is the board: a masonry cell where the body is what you are scanning.
+`row` is the list: the title is what you are scanning and everything else is a
+trail after it.
+
+They are a `density` prop rather than two components on purpose. Everything but
+the arrangement — which fields are drawn, how the tone is composited, what
+selection means — is the same decision, and two components is where two answers
+to one of those grow.
+
+## Selection is two different things, so it has two spellings
+
+`selected` on its own means **this is the note you are reading**: the card takes
+the tone's edge and announces `aria-current`. The reader did not choose it out of
+a set; they are at it.
+
+`selectable` turns the list into **bulk selection**: the card IS a checkbox —
+`role="checkbox"`, both spellings of `checked`, a box in the leading slot, and a
+press toggles instead of opening. `onPress` is not called while `selectable` is
+set, which is the whole point of the mode.
+
+**A card with no handler and no `selectable` is not a control at all** — it
+renders as a plain `View` with the composed name and no role. A `Pressable` with
+its handlers left off still lands in the tab order and still announces "button",
+and neither is true of the thing on screen.
+
+The box in the leading slot is `checkbox/shared`'s own `CheckboxGlyph`, hidden
+from assistive technology and non-interactive: the CARD carries the role and the
+press, so the box is the drawing of that state rather than a second control to
+tab to.
+
+## A checklist note previews as a checklist
+
+Pass `checklist` and it replaces `excerpt`. Flattened into text, a checklist
+reads as a paragraph of fragments — "Finish part two Borrow the essays Return the
+overdue ones" — which is worse than no preview.
+
+The rows are read-only. Each announces its own state (`role="checkbox"`,
+`aria-checked`, `aria-disabled`) and is named by its text, because a tick with no
+name is a decoration. `checklistTotal` is what the "+N more" line counts against,
+so a card can be handed the first four items of nine.
+
+## The tone is composited, never appended
+
+`tone` is one of Bloom's accent tones and there is no hex here on purpose: a note
+colour picked by eye is the one that disappears in dark mode.
+
+The mechanism is the part worth knowing. `resolveAccentColors(colors, tone,
+'subtle')` returns a **translucent** tint (`rgba(…, 0.13)` light, `0.24` dark).
+Measuring a quiet text rung against that string reads the channels and ignores
+the alpha, so the contrast you compute is not the contrast the reader gets. So
+`shared.ts` flattens the tint over the surface the card actually landed on
+(`useSurfaceFill()`), and every rung — title, excerpt, metadata — is measured
+against the **composite**. `resolveNoteCardPaint` is pure, so the suite walks it
+over both modes.
+
+The same trap catches the TAG PILLS one component down, which is why
+`noteTagVariant()` exists: the neutral tone's tint IS `contrast50`, the colour a
+`tone="default"` card already painted, so a `subtle` pill on one is a label
+floating on nothing at contrast 1.00. Those pills are drawn `outlined` instead —
+the edge does what the fill cannot.
+
+The same flattening does selection: the selected card is its own tone laid on
+once more, which is why selection reads on a tinted card and on an untinted one
+with one rule rather than two.
+
+## What it owns, and what it does not
+
+**Owns:** its geometry, its wash, which quiet rung each line sits at, the
+composed accessible name, and the fact that a press in selection mode toggles.
+
+**Does not own:** the layout of the board (give the cell a width — `grid` fills
+it), the relative-time vocabulary (`meta.edited` is drawn as given), what a
+notebook is, or whether a locked note's excerpt should be hidden. That last one
+is the app's: `meta.locked` draws the marker and hides nothing, because Bloom
+cannot know whether the excerpt it was handed is already redacted.
+
+**The notebook TREE is not here either.** It already exists as `Sidebar`'s `tree`
+prop and `SidebarFolder`; a second one would be a second answer.
+
+## Traps
+
+- **A 2px selected border must not move the content.** It does not: the padding
+  gives the pixel back. If you restyle the card, keep that — a border that grows
+  the box reflows the whole board on selection.
+- **`tone` and `selected` compose.** A selected `error` note keeps its own edge
+  colour and deepens by one surface step rather than by the tone laid twice —
+  laying an OPAQUE tint over itself is a no-op, which is exactly what `default`
+  did. Check both in dark mode if you add a tone.
+- **The card publishes its surface.** Anything you put inside it through a
+  slot will step off the card's real fill, tint included, because the card mounts
+  `SurfaceLevelProvider` with the composited colour.
+- **`loading` renders `NoteCardSkeleton`**, which is also exported on its own —
+  a list that knows it is fetching ten notes should render ten skeletons rather
+  than construct ten empty note objects to satisfy a required `title`.

package/docs/note-editor.mdx

@@ -0,0 +1,115 @@
+---
+title: NoteEditor
+description: The chrome around a writing surface — the title and its quiet state line, and a formatting row that collapses into a menu.
+order: 107
+---
+
+# NoteEditor
+
+Everything around the writing surface, and nothing of the writing surface
+itself. Bloom does not ship a rich-text engine and this family does not pretend
+to: the editable node is the app's — a `Textarea`, a web contenteditable, a
+native rich-text view — and these two components are the chrome it sits between.
+
+```tsx
+import { NoteEditorHeader, NoteEditorToolbar, Textarea } from '@oxy.so/bloom';
+
+<NoteEditorHeader
+  title={title}
+  onTitleChange={setTitle}
+  saveState="saved"
+  edited="Edited 2 min ago"
+  wordCount={words}
+/>
+<NoteEditorToolbar actions={actions} accessibilityLabel="Formatting" />
+<Textarea label="Note body" value={body} onChangeText={setBody} rows={10} />
+```
+
+## NoteEditorHeader
+
+|  |  |
+| --- | --- |
+| title | `title-1-semibold` (24/34), borderless, multiline |
+| status line | `caption-1-regular`, 6px under the title |
+| separator | a middle dot between readings |
+
+**The title is not a `TextField`.** A form field is a box you fill in; a document
+title *is* the document. So it draws no chrome at all — no border, no fill, no
+inset — and the caret is the only thing that says it is editable. Bloom has no
+borderless large input for this, which is why the `TextInput` is written out in
+the component rather than composed.
+
+**The status line is three readings, not one string.** Save state, last edit,
+word count: each is drawn only if the app passed it, so a header with nothing to
+say about saving is one line shorter rather than one empty line taller.
+
+`saveState` has four values and two of them are the same colour as the rest of
+the line (`saved`, `saving` — a document doing what it is supposed to should not
+shout). `offline` and `error` take the tone's **text** member, via
+`resolveAccentColors(…, 'outlined').foreground` — never the fill token, which is
+sized to carry white and measures 3.6:1 as a label in dark mode. They are two
+states rather than one because they ask for different things: *keep typing* and
+*stop and look*.
+
+`disabled` dims the title; `readOnly` does not. Nothing is broken about a
+published or shared note, so it is not drawn as if it were.
+
+## NoteEditorToolbar
+
+One `ButtonGroup` of icon-only items, and — the moment they stop fitting — a `…`
+item **fused onto the end of the same group** that opens the rest as a
+`DropdownMenu`. The overflow is not a second control beside the row; it is the
+row's last item, so the toolbar stays one object at every width.
+
+**It measures itself, not the window.** `useContainerWidth` on the row, so a
+toolbar in a 420px side panel of a 1440px desktop collapses exactly as it does on
+a phone. A window-width breakpoint leaves that panel overflowing with no error.
+
+The arithmetic is `toolbarCapacity(width, size)`, exported and pure: a solid
+`ButtonGroup` is `1px border + n items + (n-1) hairlines + 1px border`, so every
+item after the first costs `item + 1`. `splitToolbarActions` then applies the two
+rules that are the whole design:
+
+- **`alwaysVisible` never collapses.** Pinned actions are drawn first and are
+  never candidates for the menu, so a toolbar whose author pinned six of them at
+  360px overflows rather than quietly hiding one. It cannot collapse what it was
+  told to keep, and pretending otherwise is worse than the overflow.
+- **The overflow button costs a slot.** As soon as anything moves to the menu,
+  one item's width goes to the `…`, so the remaining actions are measured against
+  a capacity one lower. Forgetting this is how an adaptive row ends up exactly
+  one item too wide at the width where it starts collapsing.
+
+**The first frame is un-measured and draws everything inline** — one frame, and
+the row clips rather than pushing the page. The alternative (start collapsed,
+expand) flashes a menu button on every desktop mount, which is the more visible
+wrong. `splitToolbarActions(actions, null)` is that state, spelled out.
+
+### A toggle is `active`; an action is not
+
+Setting `active` — even to `false` — makes an action a **toggle**: the item
+announces both spellings of pressed (web reads only `aria-pressed`, native only
+`accessibilityState`), and its overflow row becomes a checkable one. Leaving
+`active` undefined keeps a one-shot action (attach, link) a plain button and a
+plain menu row.
+
+## What neither of them does
+
+**Sticky.** Neither component reads scroll, and a header that measured it itself
+would follow the wrong scroller in a split view with no error. The app owns the
+sticky behaviour, and chrome that follows a scroller does it through
+`ScrollOffsetProvider` — see [Composition](/docs/composition).
+
+**Formatting.** `onPress` runs whatever the app's editor does. This family knows
+the label, the glyph and whether the state is on.
+
+## Traps
+
+- **Toolbar items are 34px tall (`medium`) or 30 (`small`)**, which is below the
+  44 a touch target wants. That is `ButtonGroup`'s scale, not this family's;
+  `hitSlop` is not the answer for adjacent items, because slop on one overlaps
+  its neighbour and the press lands on whichever the platform hit-tests first.
+- **`ButtonGroupItem` writes `aria-pressed` on every item**, including one with
+  no `active`. A non-toggle in the row therefore announces "not pressed". It is
+  the base layer's spelling and this family does not work around it.
+- **`accessibilityLabel` on the toolbar is required in substance.** A row of
+  glyphs has no name of its own, and each item is named by its `label`.

package/docs/notification.mdx

@@ -39,30 +39,26 @@ import { Notification } from '@oxy.so/bloom/notification';
 
 | Part | Value |
 |---|---|
-| card | radius 16, 1px border/button/default, card surface (dark `neutral-800`), `shadow-dropdown`, padding 16 / right 44, gap 12 |
+| card | radius 16, 1px border/button/default, canonical `card` surface in both modes, `shadow-dropdown`, padding 16 / right 44, gap 12 |
 | visual | 40px full-round disc, 20px Remix fill glyph — or a 40px `Avatar` with a 12px presence dot (2px card-coloured ring) |
 | header | wraps; title body-medium text/primary, timestamp body-regular text/tertiary, gap 8 × 2 |
 | description | body-regular text/secondary; content column gap 4 |
-| actions | margin-top 6, gap 8, `Button size="small"` — first `secondary`, the rest `primary` unless `variant` is set |
+| actions | margin-top 6, gap 8, `Button size="sm"` — first `appearance="subtle" tone="neutral"`, the rest `appearance="solid" tone="accent"`, unless action props override them |
 | close | `CloseButton` xs (20px disc) at top 12 / right 12 |
-| countdown | 3px accent-600 bar along the bottom edge, shrinking linearly over `autoDismissDuration` |
+| countdown | 3px primary-colour bar along the bottom edge, shrinking linearly over `autoDismissDuration` |
 
 Buttons are full pills (Bloom's rule for button-like controls); everything else
 keeps the radii listed above.
 
 ## Status colours
 
-| `status` | disc | glyph |
-|---|---|---|
-| `neutral` (default) | background/tertiary | text/secondary, `RiNotification3Fill` |
-| `information` | `info` 100 / dark 800 @ 50% | `info` 600 / dark 300, `RiInformationFill` |
-| `success` | `success` ramp, same stops | `RiCheckboxCircleFill` |
-| `warning` (Bloom addition) | `warning` ramp, same stops | `RiAlertFill` |
-| `error` | `error` on the red ramp, same stops | `RiErrorWarningFill` |
-
-Hues are Bloom's STATUS roles through the shared ramp recipe (`button/shared.ts`),
-never a brand pair. Presence: `online` success-500, `busy` error-500, `offline`
-neutral-400 (dark 600).
+Status discs use the canonical subtle/foreground pairs through
+`resolveAccentColors`: information → info, success → success, warning → warning,
+error → error. Neutral uses the muted surface/text pair. These retain status
+meaning independently of the identity and action colours.
+
+Presence reads success for online, error for busy, and tertiary text for offline.
+The card, description and timestamp use the shared card and text roles.
 
 ## Props
 

package/docs/order-confirmation.mdx

@@ -0,0 +1,66 @@
+---
+title: Order confirmation
+description: It is placed — the mark, the reference, the tracking strip from order-status, where it goes, what was charged, what was ordered, and the two things you do next.
+order: 139
+---
+
+# Order confirmation
+
+```tsx
+import { OrderConfirmation } from '@oxy.so/bloom/order-confirmation';
+
+<OrderConfirmation
+  description="We have sent the receipt to your inbox."
+  reference="A-4821"
+  status={{ status: 'Being prepared', eta: 'Arrives 17:35', icon: RiBikeLine, progress }}
+  address={{ title: 'Home', subtitle: 'Carrer de l’Om 14, 2nd floor', kind: 'saved' }}
+  facts={[
+    { label: 'Arrives', value: 'Friday 24, 17:00 – 19:00' },
+    { label: 'Paid with', value: 'Card ending 4417' },
+    { label: 'Total', value: '€49.62' },
+  ]}
+  items={<OrderLines lines={lines} />}
+  action={{ label: 'Track order', onPress: track }}
+  secondaryAction={{ label: 'Get help', onPress: help }}
+/>;
+```
+
+## It IS an `EmptyState`
+
+Not "looks like one". A mark, a heading, a line of explanation, a block of content and up
+to two actions is exactly that family's shape, and a "done" screen is the same object as a
+"nothing here" screen with a different reason for existing. Building it a second time is
+how two centred columns with different paddings ship inside one library.
+
+That also means `variant="compact"` works here for the same reason it works there: the
+panel rung, for a confirmation inside a card rather than as the whole screen.
+
+## The mark is static, and that is a decision
+
+`AnimatedCheck` draws its ring and its check on only when a caller kicks it through its
+ref — at rest it is invisible. A mark nobody can see until a method runs is not a mark,
+and a user with reduce-motion would never see it at all. So the default is a check on a
+success-tinted disc: `IconCircle` with its own primary pair overridden TOGETHER (the one
+way its docs allow), from `resolveAccentColors(colors, 'success', 'subtle')` — a resolved
+pair, never a token with alpha appended.
+
+An app that wants the draw-on passes `<AnimatedCheck>` as `mark` and plays it itself.
+`mark={null}` draws none, for a surface that already carries a brand header.
+
+## The tracking strip is `order-status`'s
+
+`status` is `OrderStatusBarProps`, passed straight through. "Where it is right now" has
+one component in this library; this is a place that shows it, not a second one. The
+address row is `address`'s `AddressRow` and the fact box is the label/value box Bloom's
+action cards already draw.
+
+## `items` is a slot
+
+A line of an order is a dish, a parcel or a seat depending on the app, and each already
+has a row family of its own. The family draws the caption above whatever comes and stays
+out of the way.
+
+## It computes nothing
+
+Every amount, every time and every reading is a string the app formatted — including the
+reference, prefix and all.