@flowstack-ui/agent-tools 0.1.0-bootstrap.0

package/public/packages/brick/0.1.11/components/z-stack.txt

@@ -0,0 +1,143 @@
+# ZStack
+
+Source: @flowstack-ui/brick@0.1.11
+Kind: component
+ID: z-stack
+
+# ZStack agent guide
+
+## Purpose
+
+Overlap authored children in one depth-aware layout while preserving source, reading, and focus order.
+
+## Use when
+
+- Two or more visual layers intentionally share the same region.
+
+## Choose something else when
+
+- Content follows one row or column. Use Stack.
+- Content is an ordinary image-backed card or hero. Use Surface.Media, Surface.Scrim, and Surface.Content.
+
+## Required composition
+
+- Place natural-size layers directly in ZStack.Root and use ZStack.Item only when one layer needs its own nine-position alignment.
+- For a corner action over media, use ZStack.Root isolation="open" and ZStack.Item layer="action" with edgeSpacing instead of recreating stacking, z-index, and inset margins in local CSS.
+
+## Rules
+
+- **MUST:** Keep DOM order meaningful because later children paint above earlier children.
+- **MUST:** Keep media before its overlay in source; ZStack preserves that order even when the media establishes a positioned layer.
+- **MUST:** Keep decorative layers from intercepting input intended for interactive content.
+- **MUST:** Use responsive logical alignment only to move the same authored layer; never change source order, depth order, or focus order at a breakpoint.
+- **MUST:** Use the closed content and action layers only for authored overlay participation; do not invent arbitrary z-index values or use layer to reorder meaning.
+- **MUST:** Use edgeSpacing for a positioned layer that needs theme-space inset from its aligned edges; it supports the same responsive spacing vocabulary as Stack.
+- **MUST:** Load styles.css or core.css plus z-stack.css.
+
+## Common mistakes
+
+- **Avoid:** Replacing ordinary linear layout with overlap. **Instead:** Use Stack or Grid unless layers intentionally share space.
+- **Avoid:** Rebuilding Surface media anatomy. **Instead:** Prefer Surface for standard media-backed content.
+- **Avoid:** Adding inline isolation, z-index, or margin styles to make an overlay action clickable and inset. **Instead:** Use isolation="open", layer="action", and edgeSpacing on ZStack's public composition API.
+
+## Validation checklist
+
+- Check natural sizing, responsive logical placement, focus order, zoom, RTL, and pointer access.
+
+## Related guidance
+
+- `stack`
+- `grid`
+- `surface`
+- `image`
+
+## Machine record
+
+```json
+{
+  "schema": "flowstack.agent-component.v1",
+  "id": "z-stack",
+  "name": "ZStack",
+  "package": "@flowstack-ui/brick",
+  "layer": "brick",
+  "kind": "component",
+  "purpose": "Overlap authored children in one depth-aware layout while preserving source, reading, and focus order.",
+  "useWhen": [
+    "Two or more visual layers intentionally share the same region."
+  ],
+  "avoidWhen": [
+    {
+      "condition": "Content follows one row or column.",
+      "useInstead": "Stack"
+    },
+    {
+      "condition": "Content is an ordinary image-backed card or hero.",
+      "useInstead": "Surface.Media, Surface.Scrim, and Surface.Content"
+    }
+  ],
+  "composition": [
+    "Place natural-size layers directly in ZStack.Root and use ZStack.Item only when one layer needs its own nine-position alignment.",
+    "For a corner action over media, use ZStack.Root isolation=\"open\" and ZStack.Item layer=\"action\" with edgeSpacing instead of recreating stacking, z-index, and inset margins in local CSS."
+  ],
+  "rules": [
+    {
+      "id": "z-stack-source-order",
+      "level": "must",
+      "statement": "Keep DOM order meaningful because later children paint above earlier children."
+    },
+    {
+      "id": "z-stack-positioned-media-order",
+      "level": "must",
+      "statement": "Keep media before its overlay in source; ZStack preserves that order even when the media establishes a positioned layer."
+    },
+    {
+      "id": "z-stack-input",
+      "level": "must",
+      "statement": "Keep decorative layers from intercepting input intended for interactive content."
+    },
+    {
+      "id": "z-stack-responsive-placement",
+      "level": "must",
+      "statement": "Use responsive logical alignment only to move the same authored layer; never change source order, depth order, or focus order at a breakpoint."
+    },
+    {
+      "id": "z-stack-named-depth",
+      "level": "must",
+      "statement": "Use the closed content and action layers only for authored overlay participation; do not invent arbitrary z-index values or use layer to reorder meaning."
+    },
+    {
+      "id": "z-stack-edge-spacing",
+      "level": "must",
+      "statement": "Use edgeSpacing for a positioned layer that needs theme-space inset from its aligned edges; it supports the same responsive spacing vocabulary as Stack."
+    },
+    {
+      "id": "z-stack-css",
+      "level": "must",
+      "statement": "Load styles.css or core.css plus z-stack.css."
+    }
+  ],
+  "commonMistakes": [
+    {
+      "mistake": "Replacing ordinary linear layout with overlap.",
+      "correction": "Use Stack or Grid unless layers intentionally share space."
+    },
+    {
+      "mistake": "Rebuilding Surface media anatomy.",
+      "correction": "Prefer Surface for standard media-backed content."
+    },
+    {
+      "mistake": "Adding inline isolation, z-index, or margin styles to make an overlay action clickable and inset.",
+      "correction": "Use isolation=\"open\", layer=\"action\", and edgeSpacing on ZStack's public composition API."
+    }
+  ],
+  "validation": [
+    "Check natural sizing, responsive logical placement, focus order, zoom, RTL, and pointer access."
+  ],
+  "related": [
+    "stack",
+    "grid",
+    "surface",
+    "image"
+  ]
+}
+```

package/public/packages/brick/0.1.11/docs/guides/agent-knowledge.txt

@@ -0,0 +1,67 @@
+# Public document: guides/agent-knowledge
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Agent Knowledge
+
+Brick ships public component and cross-component guidance for coding agents
+alongside its runtime and CSS artifacts. Component guidance explains local
+selection, composition, CSS delivery, recurring mistakes, and validation.
+Package guides first explain layer selection and complete-interface
+composition. Neither artifact adds a runtime dependency.
+
+Use `@flowstack-ui/brick/agents/manifest.json` to discover guidance. Its
+separate `guides` and `components` collections point to machine-readable JSON
+and human-readable Markdown. Read `layer-selection` and
+`interface-composition` before choosing individual components, for example:
+
+```text
+@flowstack-ui/brick/agents/field.json
+@flowstack-ui/brick/agents/field.md
+@flowstack-ui/brick/agents/layer-selection.json
+@flowstack-ui/brick/agents/interface-composition.md
+```
+
+Use `@flowstack-ui/brick/agents/coverage.json` to inspect the exact released
+catalog behind that manifest. The `flowstack.agent-coverage.v1` report lists
+every public component owner and surface, its documentation and Agent
+Knowledge ownership, explicit source-only exclusions, and structured package
+guide destinations. Its package version matches the installed Brick version.
+Complete releases have equal `componentOwners` and `guidedComponentOwners`,
+100 percent classified public surfaces, and no invalid exclusion or unresolved
+selection destination.
+
+Structured external references use `versionPolicy: "installed-exact"`. Release
+verification resolves the installed dependency's Agent Knowledge manifest and
+checks that the referenced JSON artifact declares the expected ID, package,
+and layer. Build, check, pack, consumer, and publication verification reject a
+missing or mismatched installed external artifact.
+
+The source pair lives beside the component it describes. `agent.json` is the
+structured authority and `agent.md` is generated from it. Brick guidance adds
+finished visual and CSS decisions while referring behavioral ownership to
+Atom. Source, types, public component docs, and tests remain authoritative when
+a guide is incomplete.
+
+Package-level guide sources live under `agents/guides/`. They use
+`flowstack.agent-guide.v1`; component sources continue to use
+`flowstack.agent-component.v1`. Manifest `guides` is additive, so consumers
+that already read only `components` remain compatible.
+
+Package guide selection entries also include structured component, guide,
+package, or native/application destinations. Agents should resolve those IDs
+instead of treating the human-readable `use` sentence as a foreign key.
+
+For a finished Brick interface, search Brick before writing native layout,
+typography, media, navigation, visibility, or control replacements. Ordinary
+Brick applications do not import Atom directly. When no Brick component owns
+the job, record the native or framework fallback and its missing capability.
+
+After selecting a component, read `interface-composition` and follow its
+customization order: supported props, semantic theme tokens, documented
+component tokens, public compound parts, and only then a narrow `className` or
+stable-hook escape hatch. The JSON artifact defines a structured gap report
+for every fallback or direct Brick declaration that remains after this search.
+
+Agent Knowledge is public usage guidance. It does not contain private prompts,
+ranking policy, customer information, or application workflows.

package/public/packages/brick/0.1.11/docs/guides/appearance-and-tokens.txt

@@ -0,0 +1,179 @@
+# Public document: guides/appearance-and-tokens
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Appearance and tokens
+
+Brick ships complete light and dark semantic tokens. With no explicit setting,
+the default follows `prefers-color-scheme`.
+
+Set an appearance on the document or any subtree with the DOM contract:
+
+```html
+<html data-brick-appearance="dark">
+```
+
+```html
+<section data-brick-appearance="light">
+  <!-- This region uses light semantic values. -->
+</section>
+```
+
+Remove the attribute to return to the system preference.
+
+Brick also exports a typed, server-safe composition utility for local scopes:
+
+```tsx
+import { Appearance } from "@flowstack-ui/brick/appearance";
+
+<Appearance value="dark">
+  <section>Dark region</section>
+</Appearance>
+```
+
+Appearance always decorates exactly one existing host without an extra
+wrapper. Its existing component slot remains unchanged:
+
+```tsx
+<Appearance value="dark">
+  <AppBar.Root>...</AppBar.Root>
+</Appearance>
+```
+
+`value="inherit"` is the default and omits the explicit appearance attribute.
+Appearance adds no background, spacing, state, persistence, toggle, or React
+provider. Use Surface when the region also needs neutral paint; use Appearance
+when only the semantic-token boundary is needed or when another component
+already owns the visual region.
+
+The complete stylesheet and modular `core.css` apply the active semantic
+canvas, primary text color, body family, body size, and body line height to the
+document body through a low-specificity foundation rule. Themes normally
+change those semantic values rather than adding another body rule. Consumer
+CSS in a later layer can deliberately replace the document treatment.
+
+The optional reset stylesheet also maps native text selection to the active
+accent solid/on-solid pair, with system `Highlight` colors in forced-colors mode.
+This makes drag selection follow the compiled theme without requiring
+application CSS.
+
+## Custom themes
+
+Override public semantic variables through ordinary CSS:
+
+```css
+.brand-theme {
+  --brick-color-accent-solid: #5b5bd6;
+  --brick-color-accent-on-solid: #ffffff;
+  --brick-radius-control: 0.75rem;
+}
+```
+
+```tsx
+<section className="brand-theme">...</section>
+```
+
+Override foreground and background roles together, then verify contrast and
+all supported states. Arbitrary consumer overrides are outside Brick's visual
+accessibility guarantee.
+
+### Complete appearance maps
+
+A theme that supports both light and dark must assign its complete
+appearance-dependent color and shadow contract at every explicit re-entry
+boundary. Do not define light only at the outer theme root and assume it will
+return after a dark nested scope.
+
+```css
+@layer flowstack.theme {
+:where([data-flowstack-theme="ocean"]),
+:where([data-flowstack-theme="ocean"][data-brick-appearance="light"]),
+:where([data-flowstack-theme="ocean"] [data-brick-appearance="light"]) {
+  color-scheme: light;
+  /* Complete Ocean light semantic color assignments. */
+}
+
+:where([data-flowstack-theme="ocean"][data-brick-appearance="dark"]),
+:where([data-flowstack-theme="ocean"] [data-brick-appearance="dark"]) {
+  color-scheme: dark;
+  /* Complete Ocean dark semantic color assignments. */
+}
+}
+```
+
+Appearance-independent typography, radius, density, and motion values may
+remain on the outer theme root. Every color role claimed by an appearance must
+be complete, including surfaces, text, borders, focus, interaction states,
+status colors, scrim, and shadow.
+
+Brick reserves `flowstack.theme` between its token and foundation layers. The
+generated theme contract [source reference: theme-contract.md] publishes the exact semantic and
+approved component-input boundary for theme tooling.
+
+### Portalled content
+
+A portal rendered under `body` cannot inherit a local scope from its trigger.
+Use one of two deterministic strategies.
+
+Portal into an element inside the desired scope:
+
+```tsx
+<Dialog.Portal container={scopedLayerElement}>...</Dialog.Portal>
+```
+
+Or apply the appearance to the portalled visual roots:
+
+```tsx
+<Drawer.Portal>
+  <Appearance value="dark">
+    <Drawer.Overlay />
+  </Appearance>
+  <Appearance value="dark">
+    <Drawer.Content>...</Drawer.Content>
+  </Appearance>
+</Drawer.Portal>
+```
+
+Brick does not inspect the trigger, copy computed CSS variables, or add a
+client context. This preserves server rendering and Atom's portal ownership.
+
+## Qualification checklist
+
+- Test the theme's document default and every supported explicit appearance.
+- Test light -> dark -> light and dark -> light -> dark nesting.
+- Test hover, pressed, selected, disabled, focus, and status treatments.
+- Test Drawer, Dialog, Menu, Popover, Tooltip, Select, and other portals used
+  by the product.
+- Test native form controls, forced colors, reduced motion, and contrast.
+- If a saved preference exists, apply the document attribute before paint in
+  the framework or application layer; Brick does not own persistence.
+
+## Typography recipes
+
+Brick exposes complete semantic typography tuples instead of asking each
+component to independently choose a font size, weight, line height, and letter
+spacing. Every recipe has these five variables:
+
+```text
+--brick-typography-<recipe>-font-family
+--brick-typography-<recipe>-font-size
+--brick-typography-<recipe>-font-weight
+--brick-typography-<recipe>-line-height
+--brick-typography-<recipe>-letter-spacing
+```
+
+The public recipe names are:
+
+- authored content: `display`, `title-lg`, `title-md`, `title-sm`, `body-lg`,
+  `body-md`, `body-sm`, and `caption`;
+- component anatomy: `label-md`, `label-strong`, `supporting-sm`,
+  `validation-sm`, `overlay-title`, `compact-title`, `compact-title-lg`,
+  `surface-title-sm`, `surface-title-md`, `surface-title-lg`,
+  `field-value-md`, and `field-value-lg`;
+- controls: `control-xs`, `control-sm`, `control-md`, `control-lg`, and
+  `control-xl`.
+
+Component anatomy owns its semantic element and styling contract. It does not
+nest `Text`; its local variables alias the same semantic recipes that `Text`
+uses. Override a semantic recipe to change a role across Brick, or a documented
+component variable for one component only.

package/public/packages/brick/0.1.11/docs/guides/browser-support.txt

@@ -0,0 +1,25 @@
+# Public document: guides/browser-support
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Browser support
+
+Brick declares the pinned Browserslist query
+`baseline 2023 with downstream`. Its JavaScript is compiled to ES2020, and its
+published CSS is built against that query with Lightning CSS.
+
+Author component CSS with standard syntax. The package compiler owns generated
+vendor prefixes required by the declared target; do not add prefixes by visual
+guess. Optional effects must retain a usable baseline presentation, while
+required layout, state, focus, and accessibility relationships must work at
+the floor.
+
+Portable component behavior is release-qualified in current Chromium,
+Firefox, and Playwright WebKit. Mobile emulation is additional engine evidence,
+not proof of physical Safari, iOS, Android, browser chrome, permissions, or
+assistive technology. Those claims require the component's named platform
+evidence.
+
+An application remains responsible for its own authored code, dependencies,
+build target, content, and complete journeys. Installing Brick does not make an
+application compatible by itself.

package/public/packages/brick/0.1.11/docs/guides/control-sizing.txt

@@ -0,0 +1,59 @@
+# Public document: guides/control-sizing
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Control sizing
+
+Brick uses one shared size vocabulary for controls that commonly appear in the
+same row. A matching `size` should produce a shared outer rhythm rather than a
+collection of unrelated component scales.
+
+## Shared contract
+
+| Size | Minimum block size | Control text | Typical use |
+| --- | ---: | ---: | --- |
+| `sm` | 36px | `control-sm` | Compact application toolbars and page headers |
+| `md` | 44px | `control-md` | General application controls |
+| `lg` | 52px | `control-lg` | Comfortable or prominent controls |
+
+Button, IconButton, Select, MultiSelect, Toggle, ToggleGroup, and comparable
+button-like controls consume these shared geometry and control-typography
+recipes. Their internal padding may differ when required by their anatomy, but
+their outer height, icon scale, radius family, and baseline must align when the
+same size is used.
+
+Tabs uses the same control typography and target scale. A line tab may keep a
+44px target while a nested `body-sm` label creates a deliberately quieter page
+header; the target must not be reduced just to make the text look smaller.
+
+## Editable-control exception
+
+Input, Textarea, and editable Combobox content retain at least 16px text even
+at `sm` to avoid avoidable mobile focus zoom. They still consume the shared
+36/44/52px geometry and `--brick-radius-control`, so they align with adjacent
+button-like controls without pretending that editable and action typography
+have identical constraints.
+
+## Composition
+
+Use the same named size on controls that share a row. Let Stack own row gap and
+alignment, and let Theme own `--brick-radius-control`, control typography, and
+control height tokens. Do not repair a mismatched row with per-component
+heights, transforms, margins, or literal radii.
+
+When a control is intentionally more prominent, change its supported size and
+document that hierarchy. Do not silently customize one component so that the
+same size means something different.
+
+## Verification
+
+- Compare Button, Select, Toggle, ToggleGroup, and other button-like peers in
+  one row at `sm`, `md`, and `lg`.
+- Confirm matching minimum block size, vertical center, radius family, icon
+  scale, and control typography.
+- Confirm editable controls remain at least 16px while preserving the same
+  outer geometry.
+- Change the active Theme radius and typography inputs and confirm every peer
+  updates together.
+- Check long labels, zoom, narrow widths, RTL, focus rings, and light/dark
+  appearance without introducing one-off CSS.

package/public/packages/brick/0.1.11/docs/guides/installation.txt

@@ -0,0 +1,79 @@
+# Public document: guides/installation
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Installation
+
+Install Brick in an existing React application:
+
+```bash
+npm install @flowstack-ui/brick
+```
+
+Brick installs its compatible `@flowstack-ui/atom` version automatically; do
+not install Atom separately. React and React DOM 18 or newer are peer
+dependencies and must be provided by the consuming application.
+
+Import the complete stylesheet once from the application root:
+
+```ts
+import "@flowstack-ui/brick/styles.css";
+```
+
+This stylesheet contains default tokens, foundations, released component CSS,
+and required keyframes. Its low-specificity document foundation applies the
+canvas, primary foreground, body family, body size, and body line height from
+Brick's semantic tokens. A theme changes those tokens instead of repeating a
+separate `body` rule. Importing JavaScript does not import CSS automatically.
+
+## Optional reset
+
+New applications may opt into Brick's small page-level reset:
+
+```ts
+import "@flowstack-ui/brick/reset.css";
+import "@flowstack-ui/brick/styles.css";
+```
+
+The reset is never included by `styles.css`. It owns neutral normalization such
+as page sizing, body margin removal, and native `figure` and `blockquote`
+margin removal; it does not paint the document. Existing applications can omit
+it and keep their own reset or browser defaults. Higher-level FLOWSTACK packs,
+including Blocks, may require this complete two-import setup so copied
+compositions begin from the same neutral browser foundation.
+
+## Tokens without components
+
+Applications and custom components can load only the public visual tokens:
+
+```ts
+import "@flowstack-ui/brick/tokens.css";
+```
+
+Do not import both `tokens.css` and `styles.css`; the complete stylesheet
+already contains the tokens.
+
+## Optional route-aware CSS
+
+Applications with measured all-component CSS cost may load the shared visual
+foundation once and select component styles by the same names as Brick's
+JavaScript subpaths:
+
+```ts
+import "@flowstack-ui/brick/styles/core.css";
+import "@flowstack-ui/brick/styles/button.css";
+import "@flowstack-ui/brick/styles/card.css";
+```
+
+`core.css` contains Brick's layer order, default tokens, and foundations,
+including the same token-driven document canvas and body typography as the
+complete stylesheet. Import it before component styles. Each component
+stylesheet owns that component's rules and every shared visual recipe it renders internally;
+for example, `checkbox-group.css` already includes the Checkbox artwork and
+`toggle-group.css` already includes the Toggle item recipe. Component styles do
+not repeat tokens or foundations.
+
+Do not combine modular component styles with `styles.css` or `tokens.css`.
+Choose the complete stylesheet for the simplest and safest installation.
+Choose modular styles only when the application can reliably own every style
+import and production measurement shows that route-level selection matters.

package/public/packages/brick/0.1.11/docs/guides/theme-contract.txt

@@ -0,0 +1,90 @@
+# Public document: guides/theme-contract
+
+Source: @flowstack-ui/brick@0.1.11
+
+# Theme contract
+
+Brick publishes a generated, machine-readable description of the values that
+a FLOWSTACK theme may provide:
+
+```js
+import contract from "@flowstack-ui/brick/theme-contract.json" with { type: "json" };
+```
+
+The artifact uses the `flowstack.brick-theme-contract.v1` schema identifier.
+It is generated from Brick's token source, component documentation contracts,
+and cascade declaration, so theme tooling does not need a copied token list.
+Contract revision 2 added the required contrast declaration. Revision 3 adds
+closed categorical component inputs and conditional contrast pairs. The
+schema identifier remains version 1 because both revisions are additive for
+existing contract readers. Theme accepts revision 2 and newer, while tooling
+that needs categorical inputs and conditional validation must feature-detect
+the revision 3 fields.
+
+The contract records:
+
+- every semantic variable, type, light and dark default, and appearance
+  behavior;
+- atomic color families that must be reviewed together;
+- semantic foreground/background pairs, their text, text-distinction, or
+  non-text kind, optional component-input condition, and minimum contrast
+  ratio Theme must validate without rounding;
+- approved inherited component inputs, their semantic fallbacks, and any
+  closed `allowedValues` vocabulary;
+- local component extension variables and implementation-only variables;
+- component recipes, defaults, and state attributes used by qualification;
+- the reserved theme and appearance attributes; and
+- the exact cascade position for compiled theme CSS.
+
+## Token classifications
+
+`required` values are appearance-dependent semantic colors and shadows that a
+complete compiled appearance must contain. `derived` values are stable
+semantic foundations that can inherit Brick defaults. `component-input`
+values are the small audited set that may inherit from a theme scope.
+`optional-extension` values are public component-instance escape hatches, not
+global theme controls. `internal` values belong to Brick implementation.
+Deprecated values, when introduced, include their replacements.
+
+## Contrast pairs
+
+Brick publishes only adjacencies promised by maintained component recipes. It
+does not ask Theme to test every theoretical combination of semantic colors.
+Normal authored text pairs require `4.5:1`; meaningful non-text indicators
+require `3:1`. A conditional text-distinction pair requires `3:1` when a
+categorical theme decision removes the non-color cue that normally identifies
+an element. Disabled text and arbitrary local component overrides remain
+outside this static contract, while browser qualification covers opacity,
+gradients, images, and composition-specific adjacency.
+
+The public contract uses `wcag2-relative-luminance` over opaque sRGB values.
+Theme owns the calculation and generated report; Brick owns the declared pair
+semantics and thresholds.
+
+Brick currently approves Drawer background and radius plus Link resting
+decoration as inherited component inputs. `components.link.decoration` accepts
+only `"underline"` or `"none"`. When `"none"` is active, Theme validates the
+accent Link text against adjacent primary text at `3:1`; Link restores its
+underline on hover, focus, and active interaction. An explicit
+`variant="underline"` or `variant="plain"` remains a local exception.
+
+Other documented component variables remain available for local instance
+customization but are intentionally not accepted as global Theme inputs until
+a real product proves that scope safe. Shared appearance-dependent elevation
+uses semantic `--brick-shadow-floating` and `--brick-shadow-modal` tokens,
+which themes may map through `brick.light.shadow` and `brick.dark.shadow`.
+
+## Cascade and scopes
+
+Compiled theme variables belong in `flowstack.theme`, after `brick.tokens` and
+before `brick.foundations`. Unlayered application CSS can still deliberately
+override the result.
+
+Use `data-flowstack-theme` to select a named theme and
+`data-brick-appearance="light|dark"` for the nearest appearance boundary. A
+dual-appearance theme must re-emit its complete required map at nested light
+and dark boundaries. See Appearance and tokens [source reference: appearance-and-tokens.md] for
+scope and portal rules.
+
+This artifact describes Brick's consumption boundary. Theme authoring,
+validation, and CSS generation belong to the separate FLOWSTACK Theme package.