@vtex/faststore 0.0.4 → 0.0.5

package/dist/docs/account-access-gate.md

@@ -0,0 +1,153 @@
+# AccountAccessGate
+
+**Category:** identity
+**Purpose:** The account's single access decision — renders the account only for a signed-in shopper, and decides what happens to everyone else.
+
+---
+
+## Visual cues (how to identify in an image)
+
+**None, deliberately.** This component has no visual identity of its own and must never be selected from a screenshot. It is a rule about who may read a page, not a block on one. What it draws — a waiting message, or a short notice saying the session ended — replaces the account rather than sitting beside it, so neither appears in a design of the account itself.
+
+A screenshot of an account page shows the components the account is made of. This one is the wrapper around them, and it is authored in the layout rather than in the page.
+
+The image is the source of truth for layout, and this component is not in any layout an image can show.
+
+## When to use
+
+- Once, in the account layout, wrapping the account body — so every page declaring that layout inherits the decision.
+
+## When NOT to use
+
+- On an individual account section, to repeat the rule → the layout already made it. A second gate is a second decision to keep in agreement with the first.
+- To show or hide a subtree by session state, with nothing else riding on it → use `SessionGuard`, which is the declarative show/hide. This component navigates, remembers, and is meant to own a whole page.
+- On the `/login` route → that route is [[sign-in-redirect]], and this component redirects *to* it. Gating it closes a loop the shopper cannot leave.
+- To decide whether a shopper may read *this particular order* or *that address* → the gate answers "is anyone signed in", never "is this record theirs". Record-level authorization belongs to the resolver.
+
+---
+
+## Composition
+
+`AccountAccessGate` is the account body's parent in the PageSchema: everything it should protect is in its `children` array, in visual order.
+
+```text
+AccountAccessGate
+├── AccountMenu          ← the account's own composition, in visual order
+└── OrderList
+```
+
+It declares `requiresContext: 'session'` and must be a descendant of `SessionRoot`, which the same layout hosts.
+
+`AccountAccessGateLoading` and `AccountAccessGateNotice` are the parts it renders in place of the account. They are exported so a store can style and demonstrate them, and they are never authored in a schema.
+
+## Components
+
+### AccountAccessGate
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `loadingLabel` | string | — | Announced politely while the session resolves. Absent renders the waiting element with no text. |
+| `expiredMessage` | string | — | What a shopper whose session ended mid-visit reads. Also what a session the gate could not re-read resolves to. |
+| `signInIncompleteMessage` | string | — | What a shopper who came back from sign-in still signed out reads. |
+| `signInLabel` | string | — | Label of the link out of either notice. Absent renders no link at all. |
+
+Content model (`account-access-gate`) fields, edited in the CMS — the same four, each winning over the authored prop when published:
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `loadingLabel` | string | no | Cleared or absent keeps the authored prop |
+| `expiredMessage` | string | no | Cleared or absent keeps the authored prop |
+| `signInIncompleteMessage` | string | no | Cleared or absent keeps the authored prop |
+| `signInLabel` | string | no | Cleared or absent keeps the authored prop |
+
+**Five outcomes, decided in order.** A shopper who asked to sign out sees nothing while the sign-out navigates. An unresolved session — including one being re-read — shows the waiting part. A signed-in shopper gets the children. A shopper who *was* signed in and no longer is gets the expired notice. Everyone else is sent to sign in.
+
+**`identified` counts as signed out.** A shopper the platform recognizes but has not authenticated cannot reach their account, which is the same reading [[account-entry-point]] applies to its own label.
+
+**A visitor who arrived signed out is sent, not told.** The redirect replaces the history entry rather than pushing one, carrying the page they were trying to reach as the return, query string included — so back from the platform's login reaches the page they were reading rather than the first page of it, and never bounces off the gate again.
+
+**A session that ended mid-visit is told, not sent.** Past a redirect there is no surface left to say anything on, so the gate keeps the page and renders the notice with a sign-in link the shopper may take. This is a deliberate departure from "redirect whenever signed out", and it applies only when the gate has already rendered the account for this shopper.
+
+**One automatic hop, then the shopper's choice.** The gate records the hop before redirecting and does not redirect a second time: a shopper who comes back from sign-in still signed out reads the `signInIncompleteMessage` and a link rather than bouncing again. Every other outcome returns the hop, so a shopper who signs in, browses, and comes back later is an arrival again.
+
+**A restored document re-decides.** Coming back with the browser's back button can restore a page whose heap already holds an answer — including a painted account. The gate takes the account down on the way into the cache, so the document the browser stores does not hold it, and on the way back it discards the session it was restored with and re-reads it. A re-read that cannot answer resolves to a notice, keeping the reason the gate had already earned; the gate never sits in a wait nothing is coming to end.
+
+### AccountAccessGateLoading
+
+The waiting look. Renders an `output` announcing its label politely.
+
+### AccountAccessGateNotice
+
+What renders in the account's place when it will not open: the message for this reason, and the sign-in link.
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `reason` | `'expired' \| 'sign-in-incomplete'` | — | Exposed as a data attribute, so a store can style the two cases apart |
+| `message` | string | — | Absent renders nothing in its place |
+| `signInHref` | string | — | Built by the gate from the page the shopper is on |
+| `signInLabel` | string | — | No label, no link |
+
+---
+
+## Canonical schema example
+
+```json
+{
+  "account-gate": {
+    "type": "AccountAccessGate",
+    "props": {
+      "loadingLabel": "Carregando sua conta…",
+      "expiredMessage": "Sua sessão expirou. Entre novamente para ver seus pedidos.",
+      "signInIncompleteMessage": "Não conseguimos entrar na sua conta.",
+      "signInLabel": "Entrar"
+    },
+    "style": ["$account-access-gate"],
+    "children": ["account-orders"]
+  }
+}
+```
+
+Bound to a CMS entry, the element authors no messages at all — the entry supplies them.
+
+## Common mistakes
+
+- **`AccountGate`, `AuthGuard`, `RequireLogin`, `ProtectedRoute`.** The correct name is `AccountAccessGate`.
+- **Repeating it per account section.** It belongs once in the layout, wrapping the body. Two gates are two decisions that can disagree.
+- **Putting [[sign-in-redirect]] under it.** The gate redirects to `/login`; a gated `/login` redirects to itself.
+- **Placing it outside `SessionRoot`.** It declares `requiresContext: 'session'` and has nothing to read without one.
+- **Reaching for `SessionGuard when={['loggedIn']}` instead.** That expresses one of the five outcomes. It cannot redirect, cannot carry a return, cannot tell an arrival from an expiry, and renders nothing while the session is still resolving.
+- **Expecting it to redirect an expired session.** It renders a notice on purpose — see above.
+- **Authoring `$content` in the schema.** `$content` is compiler-injected from the layout's content entry; naming it in `props` fails the build.
+- **Selecting it from a screenshot.** It has no visual identity; the account page in the image is its children.
+
+---
+
+## Styling
+
+| Component | What you style | Plausible classes |
+|---|---|---|
+| `AccountAccessGateLoading` | The waiting message that stands in for the whole account. Style it as a centered page state rather than an inline label | `flex min-h-[420px] items-center justify-center text-[14px] font-medium text-[#6B7280]` |
+| `AccountAccessGateNotice` | The message and its link, stacked and centered in the account's place | `flex min-h-[420px] flex-col items-center justify-center gap-[12px] text-[14px] text-[#374151]` |
+
+The gate itself renders no element of its own: whichever part it renders carries `data-fs-account-access-gate` alongside its own hook, so `[data-fs-account-access-gate]` reaches the current state and the part hooks reach one state each. `data-fs-account-access-gate-notice-reason` separates the two notices, and `data-fs-account-access-gate-notice-action` is the link inside one.
+
+```json
+{
+  "AccountAccessGate": {
+    "base": ["flex", "min-h-[420px]", "flex-col", "items-center", "justify-center", "gap-[12px]"],
+    "parts": {
+      "notice-action": ["rounded-[6px]", "bg-[#111827]", "px-[16px]", "py-[8px]", "font-medium", "text-[#FFFFFF]"]
+    }
+  }
+}
+```
+
+Styling the gate's swatch reaches the loading part and both notices, which is usually what a store wants: they are the same page state wearing different text. Target `data-fs-account-access-gate-notice-reason="expired"` when the two notices need to read differently.
+
+---
+
+## Related
+
+- [[sign-in-redirect]] — the `/login` route this component sends a signed-out visitor to, and which reads back the return this one encoded. Never place it under the gate.
+- [[account-entry-point]] — the header control that offers sign-in to a shopper who chose to go there. It asks; this one insists.
+- [[session]] — the context both read. `SessionGuard`, in the same group, is the declarative show/hide for a subtree with no navigation, no memory, and no loading state of its own.

package/dist/docs/account-entry-point.md

@@ -68,7 +68,7 @@ Content model (`account-entry-point`) fields, edited in the CMS:
 
 The placeholder does not know which state is coming, so it renders for the whole wait either way. A control that authors only `signedOutLabel` therefore shows the placeholder to a logged-in shopper and then removes it, reflowing the header once. Author both labels to avoid it — the half-authored control is supported, not recommended.
 
-**The resolving state is announced, not hidden.** The component renders a polite live region that stays mounted through the whole exchange: it is empty on the first pass, receives `loadingLabel` once mounted, and is cleared again when the session resolves. The order matters and is the entire reason the region is not part of the placeholder. Assistive technology reports changes *within* a region already in the tree, so a region that appears with its text already inside says nothing, and one that is removed along with the placeholder can never report that the wait ended. The visible bar beside it is `aria-hidden`, so the wait is spoken once rather than twice. All of this only pays off with a layout-hosted `SessionRoot` — a page-hosted one is seeded server-side without the shopper cookie, never reports loading, and sticks on the signed-out label.
+**The resolving state is announced, not hidden.** The component renders a polite live region that stays mounted through the whole exchange: it is empty on the first pass, receives `loadingLabel` once mounted, and is cleared again when the session resolves. The order matters and is the entire reason the region is not part of the placeholder. Assistive technology reports changes *within* a region already in the tree, so a region that appears with its text already inside says nothing, and one that is removed along with the placeholder can never report that the wait ended. The visible bar beside it is `aria-hidden`, so the wait is spoken once rather than twice. A page-hosted `SessionRoot` is seeded server-side with the shopper cookie, so it resolves on the first paint and may skip the loading state.
 
 ---
 
@@ -100,7 +100,6 @@ Bound to a CMS entry, the element authors no content props at all — the entry
 - **Expecting a default glyph.** The base icon dialect has no account icon, so a store that authors no `icon` gets a label-only link. Author one from the store's own collection.
 - **Letting a merchant pick the icon without declaring it.** An `icon` supplied by a CMS entry renders nothing at all unless the store lists the name in `global.json → icons.include`: the compiler builds each route's sprite from the schemas, and a runtime value never reaches that pass.
 - **Hiding the announced text with `display:none`.** That removes it from the accessibility tree and defeats the announcement; use a clipping technique instead.
-- **Hosting the `SessionRoot` on the page.** The session then resolves server-side without the shopper cookie, and every shopper sees the signed-out label.
 
 ---
 

package/dist/docs/account-menu.md

@@ -0,0 +1,164 @@
+# AccountMenu
+
+**Category:** navigation
+**Purpose:** The account's section list — a navigation landmark listing the sections a merchant configured, with the one the shopper is reading announced.
+
+---
+
+## Visual cues (how to identify in an image)
+
+- A column of text links down the left of an account page, beside the section's own content.
+- One entry stands out — heavier weight, a filled row, a rule down one edge — and it is the section the page is showing.
+- On a narrow screen the same entries read as a single horizontal row of pills above the content, scrolling sideways rather than collapsing behind a control.
+- Five entries is the untouched default; a different count or a different order is the merchant's configuration, not a different component.
+
+The image is the source of truth for layout.
+
+## When to use
+
+- For the account's persistent section navigation, composed once in the `my-account` layout.
+
+## When NOT to use
+
+- For a general navigation list with no current-section marking → use [[navigation-link-list]].
+- For the trail down to a deep page → use `BreadcrumbRoot`, which keeps the "current page" claim.
+- For the header's sign-in / account control → use [[account-entry-point]].
+
+---
+
+## Composition
+
+Two parts, and the split is the point. `AccountMenuRoot` is the provider and `AccountMenuList` is the landmark.
+
+```text
+AccountMenuRoot
+├── AccountMenuList
+└── Slot                 ← the section's own page
+```
+
+**The Root wraps the section's content; the landmark does not.** The Root's context has to reach consumers that live inside the slot — the account root's redirect, the sibling breadcrumb — and a context reaches only its descendants. A `<nav>` stretched that far would put every section's content inside a navigation region: a screen reader would announce the page as navigation and "skip to navigation" would skip nothing. So the Root wraps, and the `<nav>` stays around the items alone.
+
+The sidebar still renders visually beside the section. That is the swatches' business, not the tree's.
+
+## Components
+
+### AccountMenuRoot
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `items` | `{ label, href, external? }[]` | the library's five | Authored fallback, used when no CMS entry supplies a list. |
+| `children` | ReactNode | — | The landmark and the section's slot. |
+
+Content model (`account-menu`) fields, edited in the CMS:
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `items` | array | no | One entry per section, in the order they should appear |
+| `items[].label` | string | yes | The section's name |
+| `items[].href` | string | yes | Its destination; `http(s)`, `mailto:`, `tel:`, or a site-relative path |
+| `items[].external` | boolean | no | The entry leaves the account; it is never marked current |
+
+**The list comes from three channels, in order: a published entry, the authored `items` prop, then the library's five.** The default is Profile, Orders, Address, Payments, and Security, at `/account/profile` and its siblings — the set the PRD names. Presence decides, not emptiness: a channel supplying an empty list resolves to empty rather than falling through, because a merchant who cleared the list cleared it and the defaults must not override a deliberate publication.
+
+**The current section is derived, never authored.** The component reads the current path and matches each entry's destination on segment boundaries. At most one entry is current: among the matches, the one with the longest destination wins, which makes an exact match beat every ancestor without a second rule. `/account/order` is not a match for `/account/orders` — a prefix that does not land on a segment boundary is not a match at all.
+
+**An exact match announces `aria-current="page"`; an ancestor match announces `aria-current="true"`.** Inside `/account/orders/123`, Orders is the current item of its set but not the current page. That claim belongs to the breadcrumb's deep entry, and two surfaces announcing "current page" for two different things is worse than the menu claiming only its set.
+
+Two kinds of entry are excluded from the match entirely: one marked `external`, and one whose destination is not site-relative. A destination of `/` is excluded from ancestor matching alone — a root destination is an ancestor of every account path, so a merchant listing the storefront's home beside the sections would otherwise see it current on every page. It still matches the path `/` exactly.
+
+**V0 assumes the store's public paths carry no binding prefix.** The generated tree lives under a binding segment and a rewrite carries the unprefixed path inward, so the path the component reads matches the destination the merchant published. A store whose public base path *is* its binding id makes the prefixed URL canonical, and then no entry meets a segment boundary and nothing is current. The shipped `AccountEntryPoint` has the same exposure, so this is pre-existing rather than introduced here.
+
+### AccountMenuList
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `label` | string | `'Account'` | Accessible name of the navigation landmark. |
+
+It takes no children: one `<li>` per resolved section is what it renders. With no sections to render it renders nothing at all, rather than an empty landmark for a screen-reader user to land in.
+
+**The current item is brought into view when the list scrolls.** A horizontally scrolling row can start with the current item outside the viewport — the fifth section of five leaves the shopper opening the page with no idea which one they are in. So on mount and on every route change, a current item in an overflowing list is scrolled into view. It is a no-op when the item is already visible, and it does not run at all when the list fits, since an unconditional scroll would move the page instead.
+
+A refused destination keeps its label and loses its anchor, rendering as text under `data-fs-account-menu-text`. A blank label drops the entry outright: an anchor with no accessible name is a WCAG failure.
+
+### useAccountMenu()
+
+Returns `{ items, current }` — the resolved sections and the current one as `{ index, match }`. It throws outside an `AccountMenuRoot`. This is the contract the account root's redirect and the sibling breadcrumb read, so the two surfaces cannot disagree about which section is current.
+
+---
+
+## Canonical schema example
+
+```json
+{
+  "account-menu": {
+    "type": "AccountMenuRoot",
+    "children": ["account-menu-list", "account-slot"],
+    "style": ["$account-menu"]
+  },
+  "account-menu-list": {
+    "type": "AccountMenuList",
+    "props": { "label": "Minha conta" },
+    "style": ["$account-menu-list"]
+  }
+}
+```
+
+Bound to a CMS entry, the Root authors no `items` at all — the entry supplies the whole list.
+
+## Common mistakes
+
+- **Placing the Root beside the slot instead of around it.** The layout's own consumers would be satisfied and the page's would not: a context reaches only descendants. Context-constraint validation reports it as a build error rather than as an empty menu at runtime.
+- **Putting the `<nav>` around the section's content.** That is what the two-part split exists to prevent; do not wrap the slot in `AccountMenuList`.
+- **Leaving `label` unauthored.** The default is `Account`; a store with its own wording should say so, because a landmark's name is how a screen-reader user tells it from every other one.
+- **Styling the current item and nothing else.** The hook exists beside `aria-current`, never instead of it. Removing the programmatic signal leaves position conveyed by appearance alone.
+- **Publishing an empty list and expecting the defaults.** Empty is a configuration, not an absence. The account's root then has no section to open.
+- **Authoring `$content` in the schema.** `$content` is compiler-injected from the page's or layout's content entry; naming it in `props` fails the build.
+- **Expecting the default five to resolve.** Their routes exist only in a store that authored the account's route family; until then the default is correct in the example store alone.
+
+---
+
+## Styling
+
+| Component | What you style | Plausible classes |
+|---|---|---|
+| `AccountMenuRoot` | `data-fs-account-menu` is the wrapper holding the sidebar and the section side by side | `flex gap-8 md:flex-row flex-col` |
+| `AccountMenuList` | `data-fs-account-menu-list` is the landmark; size the sidebar here | `w-56 shrink-0` |
+| Items | `data-fs-account-menu-items` is the `<ul>`, and the scroll container at narrow viewports | `flex flex-col gap-1` |
+| Item | `data-fs-account-menu-item` is one row | `list-none` |
+| Current item | `data-fs-account-menu-item-current` marks the current row | `font-semibold` |
+| Link | `data-fs-account-menu-link` is the anchor | `block rounded-md px-3 py-2 text-sm` |
+| Refused text | `data-fs-account-menu-text` replaces the anchor for a refused destination | `block px-3 py-2 text-gray-400` |
+
+The vertical-to-horizontal switch and the scroll affordance are one DOM styled two ways, authored as the `AccountMenu` swatch set in `global.json → styles`:
+
+```json
+{
+  "AccountMenuRoot": {
+    "account-menu": [
+      "flex",
+      "flex-col",
+      "gap-6",
+      "md:flex-row",
+      "md:gap-8",
+      "[&_[data-fs-account-menu-items]]:flex",
+      "[&_[data-fs-account-menu-items]]:gap-2",
+      "[&_[data-fs-account-menu-items]]:overflow-x-auto",
+      "md:[&_[data-fs-account-menu-items]]:flex-col",
+      "md:[&_[data-fs-account-menu-items]]:overflow-visible",
+      "[&_[data-fs-account-menu-item-current]_[data-fs-account-menu-link]]:bg-gray-100",
+      "[&_[data-fs-account-menu-item-current]_[data-fs-account-menu-link]]:font-semibold"
+    ]
+  }
+}
+```
+
+The current-item look reaches the anchor through the row, since the hook is on the `<li>` and the anchor is its child.
+
+---
+
+## Related
+
+- [[account-entry-point]] — the header control that links into the account.
+- [[navigation-link]] — the client-side link each item composes.
+- [[navigation-link-list]] — the general-purpose CMS-driven list this one is patterned on.
+- `BreadcrumbRoot` — the sibling trail that keeps the "current page" claim for the deep page.

package/dist/docs/buy-button.md

@@ -35,7 +35,7 @@ BuyButtonRoot
 └── BuyButtonButton
 ```
 
-`BuyButtonButton` dispatches the cart `addItem` action through the compiler-injected `$actions.cart.addItem` prop. The add-to-cart write is **context-free** — it reads and writes the Apollo cache directly — so `BuyButton` needs **no `CartRoot` ancestor** (specs/actions.md, ADR-0010). Drop it on a PDP, a product card, a shelf, or the header alike.
+`BuyButtonButton` dispatches the cart `addItem` action through the compiler-injected `$actions.cart.addItem` prop. The add-to-cart write is **context-free** — it reads and writes the Apollo cache directly — so `BuyButton` needs **no `CartRoot` ancestor** (docs/storefront-core/reference-free-particle-model.md § Write side — actions, ADR-0010). Drop it on a PDP, a product card, a shelf, or the header alike.
 
 Child order reflects visual order.
 

package/dist/docs/cart.md

@@ -3,7 +3,7 @@
 **Category:** commerce
 **Purpose:** Cart **read** layer for the store. `CartRoot` loads the active cart and exposes it (and the cart query error) to descendants, keeping them in sync as the cart changes. It is **hosted by the layout** (shared shell), wrapping the page slot — so every page, including PDPs, consumes its context without declaring it.
 
-Cart **writes** (add / remove / quantity) no longer flow through `CartRoot`. A component declares the cart methods it needs as an `actions: { cart: [...] }` selector on its definition and dispatches through the compiler-injected `$actions.cart.*` prop — the write-side mirror of `fragment` → `$data`. Cart writes are **context-free**: an add-to-cart button works on a PDP, a product card, a search result, or the header with **no `CartRoot` ancestor** (specs/actions.md, ADR-0010).
+Cart **writes** (add / remove / quantity) no longer flow through `CartRoot`. A component declares the cart methods it needs as an `actions: { cart: [...] }` selector on its definition and dispatches through the compiler-injected `$actions.cart.*` prop — the write-side mirror of `fragment` → `$data`. Cart writes are **context-free**: an add-to-cart button works on a PDP, a product card, a search result, or the header with **no `CartRoot` ancestor** (docs/storefront-core/reference-free-particle-model.md § Write side — actions, ADR-0010).
 
 This doc covers `CartRoot` — hosted in the layout, never emitted in page schemas — plus the **mini-cart footer checkout CTA** ([below](#mini-cart-footer-checkout-cta)), the composition of `CartCheckoutGuard` → (`CartTotal` + `CartGoCheckout`). The remaining cart line-item and summary particles (`CartList`, `CartItem*`, `CartCount`, `CartError`) exist in the catalog and will be documented when the full cart page enters scope.
 

package/dist/docs/session.md

@@ -34,7 +34,7 @@ Exactly one `SessionRoot` per rendered tree. A layout-hosted provider already co
 ## Layout hosting vs. page hosting
 
 Layout and page scope still fetch differently, even though both now see the shopper's cookie
-([`specs/ssr-cookie-forwarding-fetch.md`](../../../../../specs/ssr-cookie-forwarding-fetch.md)):
+([SSR session cookie forwarding](../../../../../docs/storefront-core/reference-ssr-session-cookie-forwarding.md)):
 
 - **Layout scope** emits `LAYOUT_QUERY` inside a client component with no SSR seed — no `serverVariables`, no
   `initialData`. The read happens once in the browser and is reused from cache across client-side navigation.

package/dist/docs/sign-in-redirect.md

@@ -134,4 +134,4 @@ A spinner beside the text is a decoration the component does not render. Draw it
 
 - [[account-entry-point]] — the header control that produces one of this route's inbound URLs, encoding the `returnUrl` this component revalidates. It is what a design showing a "Sign In" control actually calls for.
 - [[navigation-link]] — an ordinary link the shopper chooses to follow, for any destination they read on arrival. This route is passed through, never read.
-- `AccountAccessGate` — the other producer of inbound URLs, redirecting an unauthenticated visitor here. Not in the library yet; until it ships, the header control is this route's only sender.
+- [[account-access-gate]] — the other producer of inbound URLs, redirecting an unauthenticated visitor here with the account page they were trying to reach as the return. Never place this route under it.

package/dist/matter/account-access-gate/account-access-gate.d.ts

@@ -0,0 +1,86 @@
+import { ContentValue } from "../../core/dist/define-content-type.js";
+import { ComponentDefinition } from "../../core/dist/define-component.js";
+import "../../core/dist/index.js";
+import { ComponentPropsWithRef, ReactNode } from "react";
+//#region src/matter/account-access-gate/account-access-gate.d.ts
+export declare const AccountAccessGateContent: {
+  readonly id: "account-access-gate";
+  readonly title: "Account Access Gate";
+  readonly description: "What the shopper is told while the account resolves and when it will not open for them.";
+  readonly schema: {
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly properties: {
+      readonly loadingLabel: {
+        readonly type: "string";
+        readonly minLength: 1;
+        readonly title: "Loading announcement";
+      };
+      readonly expiredMessage: {
+        readonly type: "string";
+        readonly minLength: 1;
+        readonly title: "Session ended message";
+      };
+      readonly signInIncompleteMessage: {
+        readonly type: "string";
+        readonly minLength: 1;
+        readonly title: "Sign-in did not complete message";
+      };
+      readonly signInLabel: {
+        readonly type: "string";
+        readonly minLength: 1;
+        readonly title: "Sign-in link label";
+      };
+    };
+  };
+};
+/** Why the account will not open, as a bounded value: a style target and the choice of message. */
+export type AccountAccessGateNoticeReason = 'expired' | 'sign-in-incomplete';
+/** Props for {@link AccountAccessGate}. It renders a different element per outcome and forwards no
+ *  element props of its own; each rendered part carries its own. */
+export type AccountAccessGateProps = {
+  /** Text announced while the session resolves. */
+  loadingLabel?: string;
+  /** What a shopper whose session ended mid-visit is told. */
+  expiredMessage?: string;
+  /** What a shopper who came back from sign-in still signed out is told. */
+  signInIncompleteMessage?: string;
+  /** Label of the link out of either notice. Without it no link renders — a focusable link a screen
+   *  reader announces as its bare URL is worse than no control at all. */
+  signInLabel?: string;
+  /** Merchant-authored fields, sliced from the layout content entry; win over the props field by field
+   *  when present. Absent in a non-CMS store — the props are the fallback. */
+  $content?: ContentValue<typeof AccountAccessGateContent>;
+  /** The account. Rendered only for a signed-in shopper. */
+  children?: ReactNode;
+};
+/** Props for {@link AccountAccessGateLoading}. Extends native `<output>` attributes. */
+export type AccountAccessGateLoadingProps = ComponentPropsWithRef<'output'>;
+/** Props for {@link AccountAccessGateNotice}. Extends native `<output>` attributes. */
+export type AccountAccessGateNoticeProps = Omit<ComponentPropsWithRef<'output'>, 'children'> & {
+  reason: AccountAccessGateNoticeReason;
+  /** The message for this reason. Nothing renders in its place when unauthored. */
+  message?: string;
+  /** Where the link out leads, built by the gate from the page the shopper is on. */
+  signInHref: string;
+  /** Label of the link out. No label, no link. */
+  signInLabel?: string;
+};
+export declare const AccountAccessGateDefinition: ComponentDefinition<AccountAccessGateProps>;
+export declare function AccountAccessGate({ loadingLabel, expiredMessage, signInIncompleteMessage, signInLabel, $content, children }: Readonly<AccountAccessGateProps>): import("react/jsx-runtime").JSX.Element | null;
+/**
+ * The look of a session that has not answered yet. A real part with its own hook rather than an ad hoc
+ * spinner, so a store can style it and a story can render it.
+ */
+export declare function AccountAccessGateLoading({ className, children, ...props }: AccountAccessGateLoadingProps): import("react/jsx-runtime").JSX.Element;
+/**
+ * What renders in the account's place when it will not open: the message for this reason, and a link
+ * the shopper may take back into sign-in.
+ *
+ * The link is the whole of the escape from a sign-in loop. The gate stops redirecting after one
+ * automatic hop, so the next attempt is a click rather than a bounce — and a shopper who keeps landing
+ * here at least lands on a page that says so.
+ */
+export declare function AccountAccessGateNotice({ reason, message, signInHref, signInLabel, className, ...props }: AccountAccessGateNoticeProps): import("react/jsx-runtime").JSX.Element;
+//#endregion
+//# sourceMappingURL=account-access-gate.d.ts.map