@vtex/faststore 0.0.1

package/dist/docs/document-field.md

@@ -0,0 +1,97 @@
+# DocumentField
+
+**Category:** content
+**Purpose:** A presentational tax-document input that composes the `Field` particle (label + native `<input>` + inline error). It applies a locale-specific mask on every change (e.g. CPF `###.###.###-##`) and runs check-digit validation on blur/submit. It is data-agnostic — value flows through props; it consumes no GraphQL and no domain context.
+
+---
+
+## Visual cues (how to identify in an image)
+
+- A single-line text input labelled **"CPF"** (or another tax-document name), usually on a checkout identification step, near the email/phone fields.
+- Shows a masked placeholder like `000.000.000-00` and formats digits as they are typed.
+- When invalid, an inline error below the input (e.g. *"Enter a valid CPF."*).
+
+If the image shows a checkout identification step with a tax-document field, use `DocumentField`.
+
+---
+
+## When to use
+
+- A standalone, presentational tax-document input where the host owns the value and the persistence.
+- As the document field inside a profile/identification form that batches the write (the host wires value + persistence).
+
+## When NOT to use
+
+- For a generic non-document text field → use the `Field` particle directly.
+
+---
+
+## Composition
+
+`DocumentField` is a single leaf particle. Internally it renders:
+
+```
+DocumentField              (data-fs-document-field + inherited data-fs-field-root)
+├── Field.Label            (data-fs-field-label; the `label` prop)
+├── Field.Control          (data-fs-field-control; native <input inputmode="numeric">)
+└── Field.Error            (data-fs-field-error; the `errorMessage`, shown when invalid)
+```
+
+---
+
+## Props
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `value` | string | — | Controlled value. Omit for uncontrolled use. Displayed masked. |
+| `defaultValue` | string | `''` | Uncontrolled initial value (pre-fill); masked on display. |
+| `onValueChange` | `(value: string) => void` | — | Fires on every change with the **masked** value (no validation on change). |
+| `onBlur` | `(event) => void` | — | Fires on blur, after check-digit validation runs. |
+| `invalid` | boolean | `false` | Host-forced invalid state (e.g. a server error). Combined with the internal check-digit state. |
+| `errorMessage` | string | — | Inline error text, shown when the field is invalid. |
+| `label` | string | — | Accessible label. |
+| `placeholder` | string | — | Input placeholder. |
+| `disabled` | boolean | `false` | Disables the input (e.g. while a write is in flight). |
+| `required` | boolean | `false` | CPF is Optional by Recommendation — default false (unlike email). |
+| `name` | string | `'document'` | Field/input name. |
+| `documentType` | `'CPF'` | `'CPF'` | Selects the mask + validator + digit-only input mode. |
+
+**Masking:** applied progressively on every change; input is never blocked. Digit-only masks (CPF) strip non-digits and hint `inputMode="numeric"`.
+
+**Validation:** the check digit is checked on blur/submit only — never per keystroke. An **empty** value is valid (the field is optional). A prior error clears while the shopper edits and is re-evaluated on the next blur.
+
+---
+
+## Accessibility
+
+The label is associated with the input and the error is linked via `aria-describedby` automatically by the Base UI `Field` primitive (WCAG 2.1 AA). Standard text-input keyboard editing; masking/validation never blocks typing.
+
+---
+
+## Styling
+
+`DocumentField` owns no CSS. Style it via compound swatches / Tailwind targeting the `data-fs-*` attributes:
+
+| Target | What you style |
+|---|---|
+| `data-fs-document-field` | The field container (stack the label, input, error). |
+| `data-fs-field-label` | The label typography. |
+| `data-fs-field-control` | The input box; use `data-invalid:` for the error border. |
+| `data-fs-field-error` | The inline error text (small, red). |
+
+---
+
+## Common mistakes
+
+- **Validating on every keystroke.** Check-digit validation runs on blur/submit only.
+- **Blocking input during masking.** The mask is applied progressively and never rejects a keystroke.
+- **Treating an empty value as invalid.** The document is optional — blank is valid.
+- **Wiring GraphQL into this particle.** It is data-agnostic; the host form owns the profile read/write.
+- **Localizing via a message id.** There is no `react-intl`; pass `label` / `placeholder` / `errorMessage` as strings.
+
+---
+
+## Related
+
+- [[email-field]] — the sibling identity field this mirrors in structure.
+- [[field]] — the underlying form-field particle this composes.

package/dist/docs/email-field.md

@@ -0,0 +1,93 @@
+# EmailField
+
+**Category:** content
+**Purpose:** A presentational email input that composes the `Field` particle (label + native `<input type="email">` + inline error) and validates the email **format** on blur/submit. It is data-agnostic — value flows through props; it consumes no GraphQL and no domain context.
+
+---
+
+## Visual cues (how to identify in an image)
+
+- A single-line text input labelled **"Email"**, **"E-mail"**, or **"Email address"**, usually the **first field** of a checkout identification / sign-in step.
+- Often shows a placeholder like `you@example.com`.
+- When invalid, an inline error message below the input (e.g. *"Enter a valid email address."*).
+
+If the image shows a checkout identification step whose first field is an email, use `EmailField` — or, for a checkout-bound field wired to the shopper profile, wrap it in `EmailIdentificationControl`.
+
+---
+
+## When to use
+
+- A standalone, presentational email input where the host owns the value and the persistence.
+- As the field rendered by `EmailIdentificationControl` (the checkout-bound wrapper).
+
+## When NOT to use
+
+- When the field must read/write the shopper profile → use `EmailIdentificationControl`, which wraps this particle.
+- For a generic non-email text field → use the `Field` particle directly.
+
+---
+
+## Composition
+
+`EmailField` is a single leaf particle. Internally it renders:
+
+```
+EmailField                 (data-fs-email-field + inherited data-fs-field-root)
+├── Field.Label            (data-fs-field-label; the `label` prop)
+├── Field.Control          (data-fs-field-control; native <input type="email">)
+└── Field.Error            (data-fs-field-error; the `errorMessage`, shown when invalid)
+```
+
+---
+
+## Props
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `value` | string | — | Controlled value. Omit for uncontrolled use. |
+| `defaultValue` | string | `''` | Uncontrolled initial value (pre-fill). |
+| `onValueChange` | `(value: string) => void` | — | Fires on every input change (no validation on change). |
+| `onBlur` | `(event) => void` | — | Fires on blur, after format validation runs. |
+| `invalid` | boolean | `false` | Host-forced invalid state (e.g. a server error). Combined with the internal format-invalid state. |
+| `errorMessage` | string | — | Inline error text, shown when the field is invalid. |
+| `label` | string | — | Accessible label. |
+| `placeholder` | string | — | Input placeholder. |
+| `disabled` | boolean | `false` | Disables the input (e.g. while a write is in flight). |
+| `required` | boolean | `true` | Email is Always Mandatory at the identity step. |
+| `name` | string | `'email'` | Field/input name. |
+
+**Validation:** format is checked on blur/submit only — never per keystroke. A prior format error clears while the shopper edits and is re-evaluated on the next blur.
+
+---
+
+## Accessibility
+
+The label is associated with the input and the error is linked via `aria-describedby` automatically by the Base UI `Field` primitive (WCAG 2.1 AA). Standard text-input keyboard editing; validation never blocks typing.
+
+---
+
+## Styling
+
+`EmailField` owns no CSS. Style it via compound swatches / Tailwind targeting the `data-fs-*` attributes:
+
+| Target | What you style |
+|---|---|
+| `data-fs-email-field` | The field container (stack the label, input, error). |
+| `data-fs-field-label` | The label typography. |
+| `data-fs-field-control` | The input box; use `data-invalid:` for the error border. |
+| `data-fs-field-error` | The inline error text (small, red). |
+
+---
+
+## Common mistakes
+
+- **Validating on every keystroke.** Format validation runs on blur/submit only.
+- **Wiring GraphQL into this particle.** It is data-agnostic; use `EmailIdentificationControl` for the checkout-bound binding.
+- **Localizing via a message id.** There is no `react-intl`; pass `label` / `placeholder` / `errorMessage` as strings.
+
+---
+
+## Related
+
+- [[email-identification]] — the checkout-bound matter that binds this particle to the shopper `ClientProfile` and persists the email.
+- [[field]] — the underlying form-field particle this composes.

package/dist/docs/email-identification.md

@@ -0,0 +1,102 @@
+# EmailIdentificationControl
+
+**Category:** identity
+**Purpose:** Binds an `EmailField` to the shopper `ClientProfile`. It pre-fills from `clientProfile.email`, and on a **valid, changed** email persists only the `email` via `$actions.identity.clientProfileUpdate`, moving the session `anonymous → identified`. It reads identification state from `useSession()` and must sit inside a `SessionRoot`.
+
+---
+
+## Visual cues (how to identify in an image)
+
+- The **email field of a checkout User Identity / sign-in step** — the first identification input.
+- Same surface as `EmailField`, but in a real checkout page (not a standalone form): the value is pre-filled for a returning/identified shopper and editing it re-identifies the session.
+
+Use `EmailIdentificationControl` (not bare `EmailField`) whenever the email must read from and write to the shopper profile.
+
+---
+
+## When to use
+
+- The email step of the checkout User Identity flow.
+- Anywhere the shopper's profile email must be read (pre-fill) and written (identification).
+
+## When NOT to use
+
+- A purely presentational email input with host-owned state → use `EmailField`.
+- Name / phone / document / opt-in fields → out of scope (F5–F8, separate components).
+- Existing-account detection or login-vs-guest routing → decided downstream from the session state (`Signin`, FSPG-865), never here.
+
+---
+
+## Composition
+
+```
+SessionRoot                          (provides the session tri-state; required ancestor)
+└── EmailIdentificationControl       (data-fs-email-identification-control)
+    └── EmailField                   (the presentational field; value/disabled/invalid bound)
+```
+
+`EmailIdentificationControl` **must** have a `SessionRoot` ancestor — `useSession()` throws otherwise.
+
+---
+
+## Props
+
+| Prop | Type | Default | Notes |
+|------|------|---------|-------|
+| `label` | string | — | Passed to `EmailField`. |
+| `placeholder` | string | — | Passed to `EmailField`. |
+| `invalidEmailMessage` | string | — | Inline error text for an invalid email format. |
+| `$data` | `{ email?: string \| null } \| null` | injected | `clientProfile` slice from the reactive runtime. Not authored in schema. |
+| `$actions` | injected | — | Carries `identity.clientProfileUpdate` (compiler-injected). |
+
+**Data:** declares a colocated `fragment EmailIdentificationData on Query { clientProfile { email } }` with `fetchStrategy: 'reactive'`. The compiler merges it into the page query — no explicit `dataSources` entry needed.
+
+**Write:** declares `actions: { identity: ['clientProfileUpdate'] }`. The write is **pessimistic/async** — it awaits the persisted result. While in flight the field is disabled and the root carries `data-fs-email-identification-pending`, so a `CartCheckoutGuard`-style guard can block the checkout CTA.
+
+---
+
+## Behavior
+
+- **Pre-fill:** the field shows `clientProfile.email` and remains editable.
+- **Valid + changed email → persist:** dispatches `$actions.identity.clientProfileUpdate({ email })`; the server-derived `isIdentified` flips true (`anonymous → identified`).
+- **Unchanged email:** no write.
+- **Invalid format:** the field shows its inline error; no write, no step advance.
+- **Cleared field:** blurring an emptied field re-fills the saved email; no write. Clearing must not visually "un-identify" — changing email (= switching user) is a deliberate act done by typing a new one.
+- **`canEditData: false`:** the field renders **disabled** and the root carries `data-fs-email-identification-readonly`. VTEX refuses profile edits for an identified-but-unauthenticated claimed profile, so the control never offers a write that is doomed server-side.
+- **Server `userErrors`:** surfaced inline; the session is left unchanged.
+
+---
+
+## Canonical schema example
+
+```json
+{
+  "type": "SessionRoot",
+  "children": [
+    {
+      "type": "EmailIdentificationControl",
+      "props": {
+        "label": "Email",
+        "placeholder": "you@example.com",
+        "invalidEmailMessage": "Enter a valid email address."
+      }
+    }
+  ]
+}
+```
+
+---
+
+## Common mistakes
+
+- **Rendering it outside `SessionRoot`.** `useSession()` throws; every identity page must host a `SessionRoot`.
+- **Computing identification locally.** Read it from `useSession()`; the server derives `isIdentified` from a non-empty profile email.
+- **Writing more than `email`.** This control persists only the email; other profile fields are out of scope.
+- **Doing an email-existence pre-check.** No lookup at entry — routing is decided downstream from the session state.
+
+---
+
+## Related
+
+- [[email-field]] — the presentational particle this wraps.
+- [[session]] — provides the identification tri-state and the required `SessionRoot` ancestor.

package/dist/docs/footer-copyright.md

@@ -0,0 +1,112 @@
+# FooterCopyright
+
+**Category:** content
+**Purpose:** The store's legal notice at the bottom of the footer — a single line of plain text, editable in the CMS. The copy arrives through the compiler-injected `$content` prop, backed by the `footer-copyright` content model declared next to the component; the `text` prop is the authored fallback for stores with no CMS binding.
+
+---
+
+## Visual cues (how to identify in an image)
+
+The image is the source of truth for layout. A FooterCopyright line is present when you see:
+
+- A **single line of fine print at the very bottom** of the page, usually centered or left-aligned in the last footer band.
+- Copy that names **ownership or rights** — a `©` symbol, a year, a company or store name, *"Todos os direitos reservados"*, *"All rights reserved"*, a CNPJ or registration number.
+- Smaller, lighter type than the surrounding footer content, and **no link, icon, or heading** of its own.
+
+---
+
+## When to use
+
+- The legal or copyright line at the bottom of a footer layout.
+- Any single-line legal notice a content editor owns rather than the page schema.
+
+## When NOT to use
+
+- A static heading or paragraph authored in the schema → use `Text`.
+- Institutional links (*Sobre nós*, *Política de privacidade*) that happen to sit on the same line → use `NavigationLink`, one per link.
+- Multi-paragraph terms, or a notice that needs bold, links, or line breaks. `FooterCopyright` renders plain text only; markup in the value appears as literal characters.
+
+---
+
+## Composition
+
+`FooterCopyright` is a standalone leaf — no sub-components, no children.
+
+```
+FooterRoot
+└─ FooterCopyright
+```
+
+It renders one `<p data-fs-text data-fs-footer-copyright>` holding the notice. It expects to sit inside `FooterRoot`, but imposes no parent: it renders anywhere it is placed.
+
+**Content, then prop.** The notice resolves from the CMS entry first and the `text` prop second, so a store with no CMS binding still renders its authored value and a CMS save overrides it with no deployment. When neither supplies a non-blank notice the component renders `null` (self-hide) — the page omits only this line. Non-compiler hosts (Storybook, tests) pass a typed `$content` fixture directly.
+
+---
+
+## Components
+
+### FooterCopyright
+
+| Prop | Type | Required | Notes |
+|-------|------|----------|-------|
+| `text` | string | no | Authored fallback. Ignored when a CMS entry supplies the notice |
+
+Content model (`footer-copyright`) fields, edited in the CMS:
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `text` | string | yes | The notice, rendered verbatim |
+
+---
+
+## Canonical schema example
+
+```json
+{
+  "footer-copyright": {
+    "type": "FooterCopyright",
+    "style": ["text-[12px]", "text-[#666666]"]
+  }
+}
+```
+
+The element id is the content key, so name it for the section rather than its styling. Renaming it orphans the merchant's entry: the copy stays in the Content Platform while the component reads a key nobody writes.
+
+---
+
+## Common mistakes
+
+- **Authoring the notice only as a prop when a CMS is bound.** The prop is the fallback; content editors expect the entry to win.
+- **Putting markup in the notice.** `<b>`, `<a>`, and `<br>` render as literal characters — the notice is plain text by contract.
+- **Expecting the year to update itself.** The notice is a merchant-authored string, not a template; nothing interpolates into it.
+- **Expecting an empty placeholder without content.** A missing, malformed, or blank notice renders nothing at all.
+- **Giving `FooterCopyright` children.** It is a leaf; it renders its own text node.
+
+---
+
+## Styling
+
+`FooterCopyright` renders one DOM node you style directly. It also carries `data-fs-text`, so project-level `Text` typography cascades to it — set only what should differ from body copy, typically a smaller size and a muted color.
+
+| Component | What you style | Plausible classes |
+|---|---|---|
+| `FooterCopyright` | The legal notice line | `text-[12px] leading-[1.5] text-[#666666] text-center py-[16px]` |
+
+Styled example:
+
+```json
+{
+  "footer-copyright": {
+    "type": "FooterCopyright",
+    "style": ["text-[12px]", "leading-[1.5]", "text-[#666666]", "text-center", "py-[16px]"]
+  }
+}
+```
+
+---
+
+## Related
+
+- [[footer-root]] — the `<footer>` landmark this line sits inside.
+- [[promotion]] — the other CMS content-driven particle; same `$content` mechanics, editorial copy instead of a legal notice.
+- `Text` — plain schema-authored typography, the identity this line layers so project typography cascades. It carries no `.md` of its own; read its schema from `catalog.json`.

package/dist/docs/footer-link-group.md

@@ -0,0 +1,162 @@
+# FooterLinkGroup
+
+**Category:** navigation
+**Purpose:** One group of institutional links in the footer — a heading and its ordered list of links, both editable in the CMS. The content arrives through the compiler-injected `$content` prop, backed by the `footer-link-group` content model declared next to the component; the `heading` and `links` props are the authored fallback for stores with no CMS binding. One element renders one group, so a footer with three groups places three elements.
+
+---
+
+## Visual cues (how to identify in an image)
+
+The image is the source of truth for layout. A FooterLinkGroup is present when you see:
+
+- A **short bold or uppercase heading** — *Ajuda*, *Institucional*, *Minha conta*, *Help*, *Company*, *Legal* — with a **vertical list of text links** under it.
+- Usually **two to five such headed lists side by side** in a footer band. Each one is its own element, not one component holding all of them.
+- On a narrow screen, the same headings as **collapsed rows with a chevron or plus sign**, one link list hidden behind each.
+- Links that are **plain text, no icons** — that distinguishes it from a payment-method or social-icon row.
+
+---
+
+## When to use
+
+- Any headed list of institutional or editorial links in a footer: help, company, legal, account.
+- One instance per group. Three headings in the image means three `FooterLinkGroup` elements.
+
+## When NOT to use
+
+- A **single** link that belongs to no group → use `NavigationLink`.
+- A row of **social network icons** → use [[footer-social]]; those links carry glyphs and a different content model.
+- A row of **payment-method icons** → use `PaymentMethods`; those are brand flags, not links.
+- The **legal line** at the very bottom (`© 2026 …`) → use `FooterCopyright`.
+- Main-navigation menus in the header → use `NavigationMenu`, which is a hover/focus menu rather than a static list.
+
+---
+
+## Composition
+
+`FooterLinkGroup` is a leaf in the schema — it has no sub-components and takes no children. The links come from content, not from child elements.
+
+```
+FooterRoot
+├─ FooterLinkGroup      ← "Ajuda"        (siblings, one per group; order is visual order)
+├─ FooterLinkGroup      ← "Institucional"
+├─ FooterLinkGroup      ← "Minha conta"
+└─ FooterCopyright
+```
+
+It renders **both responsive forms at once**, each under its own hook: an accordion (`AccordionRoot` → `AccordionItem` → `AccordionHeader` → `AccordionTrigger` + `AccordionPanel`) and a column (`<h3>` + `<ul>`). Which one a viewport shows is the store's styling decision, never a prop — see [Styling](#styling). Every link therefore appears twice in the DOM; the collapsed copy stays findable by browser find-in-page.
+
+**Content, then prop, per field.** The heading resolves from the CMS entry first and the `heading` prop second; the list resolves the same way, independently. An entry supplying an empty list wins over an authored list — a merchant who cleared the links cleared them. When no non-blank heading or no renderable link survives, the component renders `null` (self-hide) and the footer omits just this group. Non-compiler hosts (Storybook, tests) pass a typed `$content` fixture directly.
+
+**A malformed link still costs the whole group.** Each link's `label` and `href` are required, so the content runtime omits this component — before any prop is consulted — when the entry holds a link missing either field. One malformed link takes the group with it, which is worth knowing when a group disappears right after a CMS save. Neither top-level field is required, exactly so a half-filled entry survives in either direction: a heading with no links yet renders the authored list under the merchant's heading, and links with no heading yet render under the authored one.
+
+---
+
+## Components
+
+### FooterLinkGroup
+
+| Prop | Type | Required | Notes |
+|-------|------|----------|-------|
+| `heading` | string | no | Authored fallback. Ignored when a CMS entry supplies a heading |
+| `links` | array | no | Authored fallback list of `{ label, href, target? }`. Ignored when a CMS entry supplies `links` |
+
+Content model (`footer-link-group`) fields, edited in the CMS:
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `heading` | string | no | The group heading and the accordion trigger's accessible name. Optional so a links-only entry falls back to the authored heading instead of omitting the group. A group with no heading resolved from either channel renders nothing |
+| `links` | array | no | Ordered links. Reordering here reorders the rendered list with no deployment. Optional so a heading-only entry falls back to the authored list instead of omitting the group |
+| `links[].label` | string | yes | Link text. A blank label drops that link — an anchor with no name is unusable |
+| `links[].href` | string | yes | Destination. `http:`, `https:`, `mailto:`, `tel:`, or a path starting with a single `/` |
+| `links[].target` | `_self` \| `_blank` | no | `_blank` opens a new tab and adds `rel="noopener noreferrer"` automatically |
+
+---
+
+## Canonical schema example
+
+```json
+{
+  "footer-links-help": {
+    "type": "FooterLinkGroup",
+    "style": ["flex", "flex-col", "gap-[12px]"]
+  },
+  "footer-links-institutional": {
+    "type": "FooterLinkGroup",
+    "style": ["flex", "flex-col", "gap-[12px]"]
+  }
+}
+```
+
+The element id is the content key, so name it for the section rather than its styling. Renaming it orphans the merchant's entry: the links stay in the Content Platform while the component reads a key nobody writes.
+
+---
+
+## Common mistakes
+
+- **One `FooterLinkGroup` for the whole footer.** One element renders one group. Three headings means three elements, each with its own content key.
+- **`FooterLinks`, `FooterLinkList`, `FooterNav`.** The correct name is `FooterLinkGroup`.
+- **Giving it children, or one child element per link.** It is a leaf; the links are content, which is what makes adding one a CMS save instead of a deployment.
+- **Looking for a `variant` or `isMobile` prop to pick the accordion.** There is none. Both forms always render and the swatch pair below decides.
+- **Shipping without that swatch pair.** Every link then appears twice on screen and twice to a screen reader.
+- **Expecting a bare `#anchor`, a query-only `?q=1`, or a relative `faq` to link.** Only the four schemes and single-slash paths above become anchors; anything else keeps its label and renders as plain text.
+- **Passing `rel` yourself for a new-tab link.** `target: "_blank"` already adds `rel="noopener noreferrer"`.
+
+---
+
+## Styling
+
+`FooterLinkGroup` renders one root you style directly, plus per-part hooks for the two forms. The heading hook is on both `<h3>`s, so typography is authored once for either form.
+
+**The breakpoint switch is required, not optional.** Both forms are in the DOM, so the hidden one has to be hidden with `display:none` to leave the accessibility tree:
+
+| Hook | Class | Effect |
+|---|---|---|
+| `data-fs-footer-link-group-accordion` | `md:hidden` | The collapsible form, mobile only |
+| `data-fs-footer-link-group-column` | `max-md:hidden` | The column form, desktop only |
+
+Without that pair both forms are visible at once and every link is announced twice.
+
+| Component | What you style | Plausible classes |
+|---|---|---|
+| `FooterLinkGroup` | Stacks the group's forms | `flex flex-col gap-[12px]` |
+| `data-fs-footer-link-group-heading` | Both headings | `text-[14px] font-bold uppercase text-[#1a1a1a]` |
+| `data-fs-footer-link-group-trigger` | The mobile toggle row | `flex w-full items-center justify-between py-[12px]` |
+| `data-fs-footer-link-group-panel` | The region the accordion collapses | `pb-[12px]`, scoped to `[data-open]` |
+| `data-fs-footer-link-group-list` | The link stack in either form | `flex flex-col gap-[8px]` |
+| `data-fs-footer-link-group-item` | The row one link occupies | `py-[2px]` |
+| `data-fs-footer-link-group-link` | A link | `text-[14px] text-[#666666] hover:underline` |
+| `data-fs-footer-link-group-text` | A refused destination, rendered as text | `text-[14px] text-[#999999]` |
+
+**The collapsed panel keeps its padding.** Collapsing takes the panel's content out of layout, not its box, so `pb-[12px]` on the bare hook is dead space under every closed row. Scope it to the open state, which Base UI marks with `data-open` on the panel:
+
+```json
+"[&_[data-fs-footer-link-group-panel][data-open]]:pb-[12px]"
+```
+
+**No indicator glyph is rendered.** The trigger holds the heading and nothing else, so the chevron or plus sign in the reference image is the store's to supply — which is also what `justify-between` above separates the heading from. Base UI marks the expanded trigger with `data-panel-open`, so one pseudo-element covers both states:
+
+```json
+"[&_[data-fs-footer-link-group-trigger]]:after:content-['+']",
+"[&_[data-fs-footer-link-group-trigger][data-panel-open]]:after:content-['-']"
+```
+
+Styled example:
+
+```json
+{
+  "footer-links-help": {
+    "type": "FooterLinkGroup",
+    "style": ["flex", "flex-col", "gap-[12px]"]
+  }
+}
+```
+
+---
+
+## Related
+
+- [[footer-root]] — the `<footer>` landmark these groups sit inside.
+- [[footer-copyright]] — the legal line below them; same `$content` mechanics, plain text and no links.
+- [[footer-social]] — the profile-icon row; same `$content` mechanics and the same link check, one glyph per link instead of a text label.
+- `Accordion` — the primitive this composes for the collapsible form; use it directly for a general-purpose disclosure. It carries no `.md` of its own; read its schema from `catalog.json`.
+- `NavigationLink` — one link on its own, and the particle each link here renders. It carries no `.md` of its own; read its schema from `catalog.json`.