@peektravel/app-utilities 0.7.1 → 0.7.2

package/dist/ui/odyssey.css

@@ -10,13 +10,13 @@
  */
 
 /* ---- base ---------------------------------------------------------------- */
-ody-icon, ody-button, ody-tag, ody-alert, ody-card, ody-divider,
+ody-icon, ody-button, ody-tag, ody-alert, ody-card, ody-divider, ody-horizontal-divider,
 ody-status-dot, ody-message, ody-loading-spinner, ody-loading-bar {
   font-family: var(--ody-font-family);
   box-sizing: border-box;
 }
 ody-button, ody-tag, ody-status-dot, ody-message, ody-loading-spinner { display: inline-block; }
-ody-alert, ody-card, ody-divider, ody-loading-bar { display: block; }
+ody-alert, ody-card, ody-divider, ody-horizontal-divider, ody-loading-bar { display: block; }
 
 @keyframes ody-spin { from { transform: rotate(0); } to { transform: rotate(360deg); } }
 .ody-spin { animation: ody-spin 1s linear infinite; }
@@ -183,6 +183,10 @@ ody-alert, ody-card, ody-divider, ody-loading-bar { display: block; }
 
 /* ---- divider ------------------------------------------------------------- */
 .ody-divider { display: block; width: 100%; height: 1px; background-color: var(--color-neutral-200); }
+/* horizontal-divider — padded successor to divider; carries its own rhythm. */
+.ody-horizontal-divider { display: block; width: 100%; height: 1px; background-color: var(--color-neutral-200); margin-block: var(--gap16); }
+.ody-horizontal-divider--tight { margin-block: var(--gap8); }
+.ody-horizontal-divider--none { margin-block: 0; }
 
 /* ---- status-dot ---------------------------------------------------------- */
 .status-dot-container { color: var(--color-neutral-350); font-size: 14px; display: inline-flex; align-items: center; }
@@ -385,6 +389,24 @@ ody-percentage-input, ody-checkbox, ody-radio-button-group, ody-checkbox-group {
 ody-page-container { display: block; width: 100%; }
 .ody-page-container { width: 100%; max-width: 1310px; margin: 0 auto; container-type: inline-size; container-name: ody-page; }
 
+/* ===== app-page-container (padded successor to page-container) ===== */
+/* The container context is on the host so the padded inner div is a descendant
+   of the `ody-page` container and its gutter can respond to the container's own
+   width (an element cannot query the container it establishes). */
+ody-app-page-container {
+  display: block;
+  width: 100%;
+  max-width: var(--layout-page-width-wide);
+  margin: 0 auto;
+  container-type: inline-size;
+  container-name: ody-page;
+}
+.ody-app-page-container { box-sizing: border-box; width: 100%; padding: var(--gap24); }
+@container ody-page (max-width: 868px) {
+  .ody-app-page-container { padding: var(--gap16); }
+}
+.ody-app-page-container--flush { padding: 0; }
+
 /* ===== collapsible-section ===== */
 .ody-collapsible-section .ody-collapsible-container .ody-collapsible { margin: 0; }
 .ody-collapsible-section .ody-collapsible__header { display: flex; flex-wrap: wrap; justify-content: space-between; align-items: center; width: 100%; background: none; border: none; padding: 0; cursor: pointer; text-align: left; }

package/dist/ui/tokens.css

@@ -98,7 +98,16 @@
   --ody-z-wormhole: 2002;
   --ody-z-tooltip: 2004;
 
-  /* layout */
+  /* spacing scale — the canonical gaps used across the design system. Prefer
+     these over raw px so spacing stays consistent across apps. */
+  --gap8: 8px;
+  --gap16: 16px;
+  --gap24: 24px;
+  --gap32: 32px;
+
+  /* layout — the two canonical settings-iframe widths the host renders at. */
+  --layout-page-width-narrow: 868px;
+  --layout-page-width-wide: 1310px;
   --layout-breadcrumb-height: 26px;
   --layout-top-bar-height: 56px;
 }

package/docs/ui.md

@@ -50,6 +50,29 @@ import {
 } from '@peektravel/app-utilities/ui';
 ```
 
+### 2.1 Spacing & layout tokens
+
+`tokens.css` publishes the canonical spacing scale and the two page widths.
+Reach for these instead of magic numbers so spacing stays consistent across
+apps even for one-off gaps:
+
+| Token | Value | Use for |
+| --- | --- | --- |
+| `--gap8` | `8px` | tight gaps |
+| `--gap16` | `16px` | the default gap between elements |
+| `--gap24` | `24px` | section-level spacing / page gutters |
+| `--gap32` | `32px` | large section spacing |
+| `--layout-page-width-narrow` | `868px` | the narrow settings-iframe width (design for this first) |
+| `--layout-page-width-wide` | `1310px` | the wide settings-iframe width |
+
+```css
+.my-card { padding: var(--gap24); gap: var(--gap16); }
+```
+
+The layout primitives already bake these in: `ody-app-page-container` uses the
+gap tokens for its responsive gutter, and `ody-section-*` / `ody-horizontal-divider`
+expose them through `gap-size` / `spacing` attributes.
+
 ---
 
 ## 3. Core conventions (read this — it is how all components work)
@@ -208,7 +231,7 @@ flagged — assign only via JSX props / refs as above.
 | Empty / error / no-results view | `ody-empty-state` |
 | KPI figures | `ody-stat-summary` + `ody-stat` |
 | Expand/collapse | `ody-accordion`, `ody-collapsible`, `ody-collapsible-section` |
-| Full-page wrapper for an **app settings UI** | `ody-page-container` (required — see below) |
+| Full-page wrapper for an **app settings UI** | `ody-app-page-container` (required — see below; `ody-page-container` is the deprecated full-bleed predecessor) |
 | Master/detail page layout | `ody-two-column` |
 | Row/column section layout | `ody-section-rows` / `ody-section-columns` |
 | Progress | `ody-loading-bar`, `ody-loading-spinner` |
@@ -299,8 +322,21 @@ carries meaning (e.g. status).
 <ody-card bar-color="var(--color-interaction-300)"><p>Card body</p></ody-card>
 ```
 
-#### `<ody-divider>`
+#### `<ody-horizontal-divider>`
+**Use when** you need a 1px horizontal rule that separates content. Unlike the
+deprecated `<ody-divider>`, it carries its own vertical rhythm
+(`margin-block: var(--gap16)`) so you don't have to add spacing around it.
+**Attributes**
+- `spacing` — `tight` (`--gap8`) | `none` (`0`); default is the normal `--gap16`.
+```html
+<ody-horizontal-divider></ody-horizontal-divider>
+<ody-horizontal-divider spacing="tight"></ody-horizontal-divider>
+```
+
+#### `<ody-divider>` _(deprecated — use `<ody-horizontal-divider>`)_
 **Use when** you need a 1px horizontal rule. No attributes, no content.
+**Deprecated:** renders with **zero** margin, so every caller has to add its own
+spacing. Prefer `<ody-horizontal-divider>`. Still works and unchanged.
 ```html
 <ody-divider></ody-divider>
 ```
@@ -497,11 +533,11 @@ Extra content (e.g. a tag) is the child content.
 </ody-two-column>
 ```
 
-#### `<ody-page-container>`
+#### `<ody-app-page-container>`
 > [!IMPORTANT]
-> **Every app settings UI must wrap its content in `<ody-page-container>`.** It is
-> the standard responsive page wrapper that keeps the settings page sized to the
-> two widths the settings host iframe renders at — **868px** (narrow) and
+> **Every app settings UI must wrap its content in `<ody-app-page-container>`.**
+> It is the standard responsive page wrapper that keeps the settings page sized
+> to the two widths the settings host iframe renders at — **868px** (narrow) and
 > **1310px** (wide).
 >
 > **Design for 868px first — it is the default.** Optimise every settings layout
@@ -514,20 +550,24 @@ Extra content (e.g. a tag) is the child content.
 full-page UI embedded in the settings host).
 The container is `width: 100%`, so it fills whichever of the two widths the
 parent iframe gives it; a `max-width` of `1310px` caps and centres it if it is
-ever embedded somewhere wider. Content is **full-bleed** (edge-to-edge, no side
-gutters). It also establishes a CSS **container context** named `ody-page`, so
-the content inside can adapt between the two widths with container queries
-instead of viewport media queries — treat 868px as the base styles and use a
-container query to *enhance* for the wider view.
-**Attributes** — none; the width is driven entirely by the parent.
+ever embedded somewhere wider. Unlike the deprecated `<ody-page-container>`, it
+ships a **default responsive gutter** — `var(--gap24)` at the wide width,
+tightening to `var(--gap16)` at/below 868px — so you no longer wrap the page in
+a padded `<div>`. It also establishes a CSS **container context** named
+`ody-page`, so the content inside can adapt between the two widths with container
+queries instead of viewport media queries — treat 868px as the base styles and
+use a container query to *enhance* for the wider view.
+**Attributes**
+- `flush` — drop the default gutter and render edge-to-edge, for the rare layout
+  that truly wants full-bleed content.
 **Slots / content** — child nodes are the page content.
 **Example**
 ```html
-<ody-page-container>
+<ody-app-page-container>
   <ody-section-rows gap-size="24">
     …settings UI…
   </ody-section-rows>
-</ody-page-container>
+</ody-app-page-container>
 ```
 ```css
 /* Base styles target the default 868px width… */
@@ -538,6 +578,15 @@ container query to *enhance* for the wider view.
 }
 ```
 
+#### `<ody-page-container>` _(deprecated — use `<ody-app-page-container>`)_
+**Deprecated:** the original page wrapper is **full-bleed** (edge-to-edge, no
+side gutters), so every settings UI had to add its own edge padding. Prefer
+`<ody-app-page-container>`, which bakes in a responsive gutter (with a `flush`
+opt-out) while keeping the same widths and `ody-page` container context. This
+element still works and is unchanged; migrate by renaming the tag (add `flush`
+if you genuinely relied on the full-bleed behaviour).
+**Attributes** — none; the width is driven entirely by the parent.
+
 #### `<ody-collapsible-section>` + `<ody-collapsible-collapsed>` + `<ody-collapsible-content>`
 **Use when** a titled section that expands/collapses on header click.
 - `ody-collapsible-section` **Attributes**: `header-text`, `secondary-header-text`, `icon` (icon name), `expanded` (boolean; reflected). **Events**: `expanded` → `{ expanded }`.

package/docs/webhooks.md

@@ -22,13 +22,12 @@ install webhook is different: it carries a signed JWT, so `parseInstallWebhook`
 checks the signature for you before returning the merged event.
 
 **The install webhook delivers two payloads at once.** A signed
-`app_registry_v2` JWT authenticates the notification and carries the account
-**id**, install id, status, version, and the acting `user`; a plain JSON body
-alongside it adds the account's **name**, **platform**, and **test** flag.
-`parseInstallWebhook` verifies the token and merges both into one flat
-`InstallWebhook`, so you make a single call. The verified token is authoritative
-for the fields it carries; the unsigned body is trusted only for name/platform/
-test.
+`app_registry_v2` JWT authenticates the notification; a plain JSON body alongside
+it carries the **event data** — the full account block (name, platform,
+timezone, test flag), the per-install `api.url`, the acting user, and the install
+id / status / version. `parseInstallWebhook` verifies the token and reads the
+event from the body — falling back to the token for the fields it also carries —
+merging both into one flat `InstallWebhook`, so you make a single call.
 
 # Booking webhooks
 
@@ -173,10 +172,11 @@ a **signed `app_registry_v2` JWT** and a plain **JSON body**.
 
 - The **JWT** is the security boundary. Verifying its signature proves the
   notification really came from Peek before your app acts on it (for example,
-  de-provisioning an uninstall). It carries the install id, account **id**,
-  status, version, and the acting `user`.
-- The **JSON body** is the enrichment channel. It adds the account's **name**,
-  **platform**, and **test** flag — the fields the token does not carry.
+  de-provisioning an uninstall) — it authenticates the whole delivery, body
+  included.
+- The **JSON body** is the event payload. It carries the full account block
+  (name, platform, timezone, test flag), the per-install `api.url`, the acting
+  user, and the install id / status / version.
 
 This webhook is also where an app first learns **who the install belongs to** —
 and the only place it ever learns it: no GraphQL read returns the account id, so
@@ -184,9 +184,9 @@ whatever you persist from this delivery is all you will ever have.
 
 `parseInstallWebhook(token, body, secret)` verifies the token (issuer, audience,
 expiry, HMAC — the security-critical boilerplate you'd otherwise hand-roll) and
-merges both payloads into one flat, JSON-safe `InstallWebhook` you store as a
-unit. The **verified token** is authoritative for the fields it carries; the
-unsigned body is trusted only for name/platform/test.
+reads the event from the body, **falling back to the token** for the fields it
+also carries (`installId`, `accountId`, `status`, `displayVersion`, `user`),
+returning one flat, JSON-safe `InstallWebhook` you store as a unit.
 
 ## Step 1 — subscribe to the event (external, one-time)
 
@@ -249,21 +249,25 @@ The resulting `InstallWebhook` is flat:
 
 | Field | Type | Source | From | Notes |
 | --- | --- | --- | --- | --- |
-| `installId` | `string` | token | `sub` | Peek-assigned install UUID |
-| `accountId` | `string` | token | `account.id` | **also called the partner ID** |
+| `installId` | `string` | body → token | `install_id` / `sub` | Peek-assigned install UUID |
+| `accountId` | `string` | body → token | `account.id` | **also called the partner ID** |
 | `accountName` | `string` | body | `account.name` | partner display name; `""` when absent |
 | `platform` | `PeekPlatform \| null` | body | `account.platform` | **persist per install** — see below; `null` when unrecognised |
 | `isTest` | `boolean` | body | `account.is_test` | defaults to `false` |
-| `status` | `InstallStatus \| null` | token | `status` | `null` when unrecognised — see below |
-| `rawStatus` | `string` | token | `status` | always the wire value, for logging |
-| `displayVersion` | `string` | token | `display_version` | `""` when absent |
-| `user` | `PeekAuthTokenUser \| null` | token | `user` | `null` for system-initiated events |
-
-Because the four fields present in **both** payloads (`installId`, `accountId`,
-`status`, `displayVersion`) are read from the **verified token**, a mismatched or
-forged body can never override an authenticated identity. Unlike
-`verifyPeekAuthToken`, `user` is nullable: install lifecycle events are often
-system-initiated (no acting user), so the parser tolerates `user: null`.
+| `timezone` | `string` | body | `account.timezone` | IANA zone (e.g. `America/New_York`); **persist per install**; `""` when absent |
+| `apiUrl` | `string` | body | `api.url` | per-install backoffice API base URL; **persist per install**; `""` when absent |
+| `status` | `InstallStatus \| null` | body → token | `status` | `null` when unrecognised — see below |
+| `rawStatus` | `string` | body → token | `status` | always the wire value, for logging |
+| `displayVersion` | `string` | body → token | `display_version` | `""` when absent |
+| `user` | `PeekAuthTokenUser \| null` | body → token | `modified_by` / `user` | `null` for system-initiated events |
+
+The **JSON body is the source of the event data**; the fields it shares with the
+token (`installId`, `accountId`, `status`, `displayVersion`, `user`) fall back to
+the **verified token** when the body omits them. The token authenticates the
+whole delivery — only Peek can mint a valid one — so the body is trusted within a
+verified request. Unlike `verifyPeekAuthToken`, `user` is nullable: install
+lifecycle events are often system-initiated (no acting user), so the parser
+tolerates a missing `modified_by`/`user`.
 
 > **Migrating from `verifyInstallWebhook` / `parseInstallEvent`?**
 > `verifyInstallWebhook(token, secret)` still works but is `@deprecated` — it
@@ -288,6 +292,85 @@ Two installs of the same app can sit on different platforms, so this cannot be
 inferred from app-level config — it is per install, it has no source other than
 this event, and it must be stored alongside `installId` and `accountId`.
 
+## Also persist `timezone` and `apiUrl` per install
+
+Like `platform`, these are per-install facts with **no source other than this
+event**, so persist them alongside `installId`/`accountId`:
+
+- **`timezone`** — the account's IANA zone (e.g. `America/New_York`). Downstream
+  date/time handling for the install (scheduling, day boundaries, display) needs
+  the account's own zone, not the server's.
+- **`apiUrl`** — the **app endpoint URL** the registry serves this install from.
+  Use it **as given** for this install's API calls: hit it unmodified, do not
+  decompose it or append your own app id. If the registry tags traffic with an
+  app id in the path, that is the registry's concern and opaque to you. Store it
+  and pass it as the access service's **`apiUrl`** (for Peek it is the sole
+  request URL; for CNG/ACME it is the base and the REST path is appended) — or
+  hand the whole install to `createAccessServiceForInstall` (below), which wires
+  it for you.
+
+Both default to `""` when a delivery omits them, so treat empty as "not
+reported" and keep any value you previously stored.
+
+## Every install event is a full snapshot — upsert by `installId`
+
+An install webhook is not just a one-time "who is this install" signal. **Every
+event carries the complete, current record**, and an `update_installed` event
+delivers the *same fields* as the original `installed` event. So the registry
+uses the webhook to push changes: a new `apiUrl`, a renamed account, a new
+`displayVersion`, a platform move.
+
+Treat each delivery as an **upsert keyed by `installId`** and overwrite your
+stored fields with the incoming ones:
+
+```ts
+const event = parseInstallWebhook(token, req.body, secret);
+await installs.upsert(event.installId, {
+  accountId: event.accountId,
+  accountName: event.accountName,
+  platform: event.platform,
+  isTest: event.isTest,
+  timezone: event.timezone,
+  apiUrl: event.apiUrl, // may change between events — always take the latest
+  displayVersion: event.displayVersion,
+});
+```
+
+A consumer that reads only the first `installed` event and ignores later
+`update_installed` deliveries will keep stale data — most importantly a stale
+`apiUrl`, which would send its API calls to the wrong endpoint.
+
+## Build the install's access service from `platform` + `apiUrl`
+
+A persisted install carries the two facts needed to reach it: `platform` picks
+the access service class, and `apiUrl` is its endpoint. `createAccessServiceForInstall`
+encodes that mapping, so you go from a stored install to the right client in one
+call — no `switch` on platform, no URL wiring:
+
+```ts
+import { createAccessServiceForInstall } from "@peektravel/app-utilities";
+
+const install = await installs.get(installId); // { platform, apiUrl, installId, … }
+
+const service = createAccessServiceForInstall(install, {
+  jwtSecret: process.env.PEEK_INTERNAL_SECRET!,
+  issuer: process.env.APP_NAME!,
+  // gatewayKey?, logger?, fetch?, accessOptions?, … (per-app, not per-install)
+});
+// → PeekAccessService | CngAccessService | AcmeAccessService, wired to install.apiUrl.
+// Narrow by install.platform (or `instanceof`) to reach a platform-specific surface.
+```
+
+It throws if `install.platform` is `null` or unrecognised — an install with an
+unknown platform has no service to route to, and silently defaulting would point
+it at the wrong gateway.
+
+Prefer this (or the config's `apiUrl` field) over `baseUrl`/`appId`, which are
+deprecated: they reconstruct the URL with a hardcoded gateway default that cannot
+be correct for every install. **The hardcoded base-URL fallbacks will be removed
+and a URL will become required in a future release** — source it from the install
+webhook's `apiUrl` now.
+
 ## Why `status` and `platform` can be `null`
 
 `parseInstallWebhook` never throws on the *body* (only token verification can

package/llms.txt

@@ -22,14 +22,24 @@ const peek = new PeekAccessService({
   installId,   // JWT subject
   jwtSecret,   // HMAC secret signing the JWT
   issuer,      // app name (JWT issuer)
-  appId,       // gateway path segment
-  gatewayKey,  // pk-api-key header
-  // optional: baseUrl, tokenTtlSeconds, tokenRefreshLeewaySeconds,
+  apiUrl,      // the install webhook's apiUrl — the app endpoint, used as given
+  // optional: gatewayKey, tokenTtlSeconds, tokenRefreshLeewaySeconds,
   // retryDelaysMs, logger, fetch, itemOptionsPageSize,
   // accessOptions: { fullCustomerAccess: false }  // default — see "Access options / PII"
 });
 ```
 
+Targeting an install by URL: pass the install webhook's `apiUrl` as the config
+`apiUrl` — for Peek it is the **sole** request URL (every call POSTs to it,
+unmodified); for CNG/ACME it is the base and the REST path is appended. No
+app-id/gateway segment is inserted (`appId` is unused). Any app id in the path is
+the registry's own traffic tag, opaque to callers. `createAccessServiceForInstall(install, config)`
+builds the right service for `install.platform` (`peek`/`cng`/`acme`) wired to
+`install.apiUrl` in one call (throws on unknown/`null` platform). `appId` +
+`baseUrl` (and the hardcoded gateway default) are **`@deprecated`** — they
+reconstruct the URL with a compiled-in default that can't be right for every
+install; the fallbacks will be removed and a URL will become **required**.
+
 ## Access options / PII — `fullCustomerAccess`
 
 **The most commonly-misunderstood option in this package. Read this before
@@ -124,8 +134,10 @@ final authority and may still reject the request.
 Two brand-parallel accessors sit alongside `PeekAccessService` and share the same
 auth/transport/UI plumbing. Both are **REST** and deliberately minimal today
 (products only). Construct one per install, same config shape **minus `gatewayKey`**
-(`installId`, `jwtSecret`, `issuer`, `appId`); both default the base URL to the
-app-registry installations API.
+(`installId`, `jwtSecret`, `issuer`, `apiUrl`). With `apiUrl` set, it is the REST
+base and only the path is appended; the deprecated `baseUrl`/`appId` fall back to
+the app-registry installations API default. `createAccessServiceForInstall` routes
+`platform` `"cng"`/`"acme"` to these.
 
 - `CngAccessService` — `getProductService().getAllActivities()` (short-form
   `getAllActivities()`) → `Activity[]` (`Activity`/`ActivityTicket` models).
@@ -187,12 +199,14 @@ an external system** (App Store config), not from code.
   `verifyPeekAuthToken`, throwing the underlying `jsonwebtoken` error on failure,
   one `try/catch` → `401`) and merges both into one flat, JSON-safe
   `InstallWebhook`: `installId`, `accountId` (**also called the partner ID**),
-  `accountName`, `platform`, `isTest`, `status`, `rawStatus`, `displayVersion`,
-  `user` (nullable, for system-initiated events). The **verified token** is
-  authoritative for `installId`/`accountId`/`status`/`displayVersion`/`user`; the
-  unsigned body supplies only `accountName`/`platform`/`isTest`, so a forged body
-  can't override an authenticated field. This webhook is the **only** source of
-  `accountId` in the package — no GraphQL read returns it. `status` and `platform`
+  `accountName`, `platform`, `isTest`, `timezone`, `apiUrl`, `status`,
+  `rawStatus`, `displayVersion`, `user` (nullable, for system-initiated events).
+  The **JSON body is the source of the event data**; the fields it shares with
+  the token (`installId`/`accountId`/`status`/`displayVersion`/`user`) fall back
+  to the **verified token** when the body omits them. The token authenticates the
+  whole delivery, so the body is trusted within a verified request. This webhook
+  is the **only** source of `accountId`, `timezone`, and `apiUrl` in the package
+  — no GraphQL read returns them; **persist them per install**. `status` and `platform`
   are **nullable**: a value this version does not recognise maps to `null` (wire
   value kept on `rawStatus`) rather than being coerced, because Peek does not
   redeliver a 2xx and a coerced status silently drops a lifecycle transition. Give
@@ -236,12 +250,18 @@ via a `ref`'s imperative methods). No `only a getter` crash. TS still types them
 read-only — the setters are a runtime safety net.
 
 Tags by tier (see `docs/ui.md` for attributes/events/examples per component):
-- display: `ody-button`, `ody-tag`, `ody-alert`, `ody-card`, `ody-divider`,
+- display: `ody-button`, `ody-tag`, `ody-alert`, `ody-card`, `ody-horizontal-divider`
+  (1px rule with a default `margin-block: var(--gap16)`; `spacing="tight"|"none"`),
   `ody-status-dot`, `ody-message`, `ody-icon`, `ody-loading-spinner`, `ody-loading-bar`
 - layout: `ody-empty-state`, `ody-breadcrumb`(+`-item`), `ody-stat-summary`(+`ody-stat`),
   `ody-inline-list`(+`-item`), `ody-list-item`, `ody-product-indicator`,
   `ody-toggle-button`, `ody-section-rows`/`-columns`(+items), `ody-two-column`(+parts),
-  `ody-collapsible-section`
+  `ody-collapsible-section`, `ody-app-page-container` (required page wrapper for a
+  settings UI — 868/1310px widths, `ody-page` container context, default responsive
+  gutter; `flush` opts out)
+- deprecated (kept, unchanged): `ody-divider` → use `ody-horizontal-divider` (the old
+  one has zero margin); `ody-page-container` → use `ody-app-page-container` (the old
+  one is full-bleed with no gutter). Migrate by renaming the tag.
 - form: `ody-input`, `ody-inline-input`, `ody-search-input`, `ody-money-input`,
   `ody-percentage-input`, `ody-checkbox`, `ody-radio-button-group`, `ody-checkbox-group`
 - interactive: `ody-accordion`, `ody-collapsible`, `ody-tabs`, `ody-copy-button`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@peektravel/app-utilities",
-  "version": "0.7.1",
+  "version": "0.7.2",
   "description": "GraphQL JS mapping utilities extracted from the Peek Pro Autopilot connector.",
   "license": "MIT",
   "repository": {