npm - @flowstack-ui/agent-tools - Versions diffs - 0.1.0-bootstrap.0 - Mend

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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (239) hide show

package/public/packages/colors/0.1.1/operations/palette-candidate.txt ADDED Viewed

@@ -0,0 +1,37 @@
+# Palette candidate generation and review
+Source: @flowstack-ui/colors@0.1.1
+Kind: operation
+ID: palette-candidate
+Guide: [colors-system](/packages/colors/0.1.1/guides/colors-system.txt)
+## Covered public surfaces
+- `.#BrandSeedInput`
+- `.#CandidateAppearance`
+- `.#CandidateColorValue`
+- `.#CandidateMeasurement`
+- `.#CandidateReview`
+- `.#CandidateReviewDecision`
+- `.#CandidateReviewStatus`
+- `.#CandidateStatus`
+- `.#ColorGenerationRequest`
+- `.#ColorsCandidateEnvelope`
+- `.#DecorativeCandidateAppearance`
+- `.#DecorativeCandidateFamily`
+- `.#DecorativeSeedInput`
+- `.#GenerationDiagnostic`
+- `.#GenerationDiagnosticCode`
+- `.#InterfaceCandidateFamily`
+- `.#InterfaceRole`
+- `.#InterfaceSeedInput`
+- `.#NeutralCandidateFamily`
+- `.#NeutralRole`
+- `.#NeutralSeedInput`
+- `.#PaletteAppearance`
+- `.#PaletteCandidateFamily`
+- `.#PaletteProfile`
+- `.#PaletteSeedBase`
+- `.#defineColorGenerationRequest`
+- `.#generatePaletteCandidate`
+- `.#reviewPaletteCandidate`

package/public/packages/theme/0.1.1/docs/agent-knowledge.txt ADDED Viewed

@@ -0,0 +1,44 @@
+# Public document: agent-knowledge
+Source: @flowstack-ui/theme@0.1.1
+# Agent Knowledge
+Theme publishes the same ownership and validation guidance for humans and
+coding agents.
+```js
+import manifest from "@flowstack-ui/theme/agents/manifest.json" with { type: "json" };
+```
+The manifest points to:
+- `@flowstack-ui/theme/agents/theme-system.json` for structured decisions,
+  rules, ownership, and validation checks; and
+- `@flowstack-ui/theme/agents/theme-system.md` for the equivalent readable
+  guide.
+It also links `@flowstack-ui/theme/agents/coverage.json`. The deterministic
+`flowstack.agent-coverage.v1` report reconciles every public root and schema
+symbol plus the `flowstack-theme` CLI with seven selectable operation owners:
+definition, validation, installed Brick contract compatibility, Colors file
+interchange, compilation, artifact writing, and CLI automation. Release checks
+require all seven operations and every public surface to be classified, routed,
+and failure-free.
+`agents/theme-system.json` is the structured authority and its Markdown is
+generated from that file. `npm run agents:build` regenerates the source
+Markdown and complete `dist/agents` directory. `npm run agents:check` rejects
+source/Markdown drift and missing, stale, or extra generated artifacts.
+Agents should read this package guide together with Brick's package and
+component Agent Knowledge. Brick teaches component selection and semantic
+consumption; Theme teaches project value mapping and compilation. Neither
+artifact grants an agent permission to invent brand direction. Creative input
+and application product intent remain explicit inputs.
+Theme reads the contract belonging to the exact installed Brick build input;
+it does not copy Brick's token inventory or depend on Brick at runtime. Colors
+is an optional reviewed serialized handoff and is likewise not a Theme runtime
+dependency. Applications continue to own activation, persistence, first paint,
+fonts, assets, portals, routes, and delivery of the compiled CSS.

package/public/packages/theme/0.1.1/docs/appearances-and-portals.txt ADDED Viewed

@@ -0,0 +1,41 @@
+# Public document: appearances-and-portals
+Source: @flowstack-ui/theme@0.1.1
+# Appearances and portals
+Light and dark are appearances inside one brand theme. A definition may be
+fixed light, fixed dark, or dual appearance with a fixed or `system` default.
+The theme identity uses `data-flowstack-theme`. Brick continues to own
+appearance boundaries through `data-brick-appearance="light|dark"` and its
+server-safe `Appearance` component. Generated CSS emits a complete token map
+at every explicit boundary, so light → dark → light re-entry works without a
+provider.
+```html
+<body data-flowstack-theme="acme">
+  <main data-brick-appearance="light">
+    <aside data-brick-appearance="dark">
+      <section data-brick-appearance="light"></section>
+    </aside>
+  </main>
+</body>
+```
+The application owns root preference, persistence, and the earliest safe
+pre-paint attribute setup. Theme does not read `localStorage`, inspect media
+queries, or mutate the document.
+## Portals
+A portal inherits React context but not the trigger's CSS ancestry. Content
+rendered under `document.body` therefore inherits the document theme and
+appearance, not a locally themed trigger subtree.
+When a portal must retain a local appearance, render it into a container under
+that visual boundary or apply an explicit theme/appearance boundary to the
+portal root. Do not copy computed CSS variables in JavaScript.
+Nested different-brand themes remain structurally possible, but complete
+multi-brand nesting is not a Theme `0.1` qualification claim.

package/public/packages/theme/0.1.1/docs/architecture.txt ADDED Viewed

@@ -0,0 +1,121 @@
+# Public document: architecture
+Source: @flowstack-ui/theme@0.1.1
+# Architecture
+## Package purpose
+`@flowstack-ui/theme` is build-time infrastructure for serializable FLOWSTACK
+theme definitions. Brick owns components and its default semantic contract. A
+theme maps project visual decisions into that contract and may also retain
+additional project roles that Brick does not consume.
+## Definition and compiler boundary
+The definition envelope is `flowstack.theme.v1`. Compilable token leaves are
+strings or finite numbers. Exact `{path.to.token}` aliases may cross palettes,
+roles, Brick mappings, foundations, component inputs, and extensions. Unknown
+or circular aliases fail compilation.
+The first schema identifier is `flowstack.theme.v1`. Additive optional fields
+may remain within version 1. Removing a field, changing existing meaning, or
+making previously valid data invalid requires a new schema identifier or a
+documented compatibility migration.
+## Contract mapping
+The compiler receives Brick's generated
+`flowstack.brick-theme-contract.v1` as data; it does not import Brick source or
+carry a copied token list. Theme `brick.light` and `brick.dark` objects address
+required semantic paths after the contract's `semantic.<appearance>` prefix.
+Compilation requires contract revision 2 or newer so contrast declarations
+cannot be absent silently. Revision 3 contracts may additionally declare
+closed `allowedValues` for categorical component inputs and a `when` condition
+on contrast pairs. These fields remain optional so revision 2 contracts stay
+compatible.
+Theme `foundations` addresses derived semantic paths. Theme `components`
+addresses only declared inherited component inputs, for example
+`components.drawer.radius`.
+Sparse authoring is safe at the family level. A completely omitted atomic
+family inherits Brick defaults, but a partially overridden family is rejected.
+Every emitted appearance contains the complete required Brick map.
+Compatibility accepts exact semantic versions, caret or tilde ranges,
+comparator sets, and `||` alternatives.
+Brick also owns a versioned list of maintained semantic contrast pairs. Theme
+evaluates those pairs for every supported appearance with WCAG 2 relative
+luminance in sRGB. Text pairs require at least 4.5:1 and non-text or
+text-distinction pairs require at least 3:1; the unrounded ratio decides
+success. A conditional pair runs only when its declared categorical
+component-input value is active, using either the authored value or Brick
+fallback. A participating token must resolve to an opaque sRGB hex or `rgb()`
+value. Compilation fails when a pair is insufficient or cannot be proved. This
+contract deliberately excludes disabled presentation and does not claim to
+model gradients, transparency, images, consumer overrides, or the final
+browser composition.
+Project `palettes`, `roles`, and `extensions` are open vocabularies. They emit
+under `--flowstack-theme-*`, never create new `--brick-*` meanings, and are
+also retained in the token artifact. Extension top-level keys are the
+discoverable namespaces recorded by the manifest.
+Project meanings that vary by appearance belong in `appearanceRoles`. Each
+logical path must provide every supported appearance and emits one stable
+`--flowstack-theme-roles-*` variable through the same default, system,
+explicit, and nested appearance selectors used by Brick mappings. An
+appearance role cannot collide with an invariant `roles` path.
+Themes may declare contrast relationships between appearance roles. Theme
+evaluates these separately from Brick-owned pairs and records both groups in
+the report. This proves only the resolved opaque foreground and background;
+images, gradients, transparency, and the final browser composition remain
+consumer qualification responsibilities.
+## Colors interchange
+Theme may read a reviewed serialized `flowstack.colors-candidate.v1` document
+as optional build input. It never imports Colors code and has no Colors runtime
+dependency. An explicit scaffold mapping assigns selected candidate families
+to project palette names and, separately, assigns compatible interface or
+neutral families to semantic Brick jobs.
+The scaffold writes exact candidate hex values beneath the reserved
+`palettes.colors` namespace and generates aliases for complete atomic families
+from the installed Brick contract. Decorative and otherwise extra families
+remain project palettes without being forced into Brick meaning. The result is
+an ordinary editable `flowstack.theme.v1` definition; compilation remains the
+authority for exact Brick compatibility and contrast.
+## Generated artifacts
+- `theme.css` contains the static `flowstack.theme` layer and activation
+  selectors taken from the Brick contract.
+- `theme.tokens.json` contains resolved DTCG-compatible `$value` leaves.
+- `theme.manifest.json` records identity, compatibility, activation,
+  extensions, requirements, and artifact names.
+- `theme.report.json` records deterministic compilation counts, every declared
+  contrast result at 12 significant digits, and warnings. Validation compares
+  the unrounded ratio before this serialization boundary.
+Fixed-light and fixed-dark definitions emit one complete appearance. Dual
+definitions may select a fixed default or `system`; the latter adds a static
+`prefers-color-scheme` rule. Explicit nearest Brick appearance boundaries
+always receive a complete map.
+## Runtime boundary
+The core package has no runtime dependencies and no React provider. It produces
+deterministic static CSS and machine-readable artifacts at build time.
+Optional future framework integration may coordinate selection and first paint
+without resolving component styles during React rendering.
+## Dependency direction
+- Brick never depends on Theme.
+- Theme does not import Brick component source.
+- Theme builds read a versioned contract exposed by the installed Brick
+  package.
+- Colors remains optional build-time tooling after its algorithms qualify.
+- Applications own preference, persistence, fonts, assets, and routes.

package/public/packages/theme/0.1.1/docs/authoring.txt ADDED Viewed

@@ -0,0 +1,141 @@
+# Public document: authoring
+Source: @flowstack-ui/theme@0.1.1
+# Authoring
+A theme definition is serializable project data. JSON is the CLI boundary;
+TypeScript may use `defineTheme` for typing as long as the resulting object
+remains JSON-compatible.
+## Start with project meaning
+Define any number of raw palettes, then name the roles your product needs:
+```json
+{
+  "$schema": "flowstack.theme.v1",
+  "metadata": { "id": "acme", "name": "Acme" },
+  "compatibility": { "brick": "^0.1.11" },
+  "appearances": {
+    "supported": ["light", "dark"],
+    "default": "system"
+  },
+  "palettes": {
+    "brand": {
+      "blue": "#2457c5",
+      "orange": "#c44d18",
+      "magenta": "#a53c8e"
+    }
+  },
+  "roles": {
+    "brandPrimary": "{palettes.brand.blue}",
+    "promotion": "{palettes.brand.magenta}"
+  }
+}
+```
+Extra colors are not forced into Brick's smaller vocabulary. Charts,
+campaigns, syntax, editorial colors, maps, and future Block roles remain in
+`roles` or a namespaced `extensions` object and emit as
+`--flowstack-theme-*` variables.
+## Appearance-aware project roles
+Use `appearanceRoles` when one project meaning must adapt with light and dark
+appearance without becoming a required Brick semantic:
+```json
+{
+  "appearanceRoles": {
+    "light": {
+      "blocks": {
+        "expressiveSurface": {
+          "surface": "#4a2f00",
+          "foreground": "#ffffff"
+        }
+      }
+    },
+    "dark": {
+      "blocks": {
+        "expressiveSurface": {
+          "surface": "#2f2108",
+          "foreground": "#ffffff"
+        }
+      }
+    }
+  },
+  "relationships": {
+    "contrast": [
+      {
+        "id": "blocks-expressive-surface-content",
+        "kind": "text",
+        "foreground": "blocks.expressiveSurface.foreground",
+        "background": "blocks.expressiveSurface.surface",
+        "minimumRatio": 4.5
+      }
+    ]
+  }
+}
+```
+The compiler emits stable
+`--flowstack-theme-roles-blocks-expressive-surface-*` variables under the
+active appearance selectors. Every logical role must exist in every supported
+appearance. Declared project contrast relationships must resolve to opaque
+sRGB colors and meet the same unrounded WCAG 2 floors used for Brick pairs.
+Keep media-composition and transparency checks in the consuming product.
+## Map Brick semantics
+The `brick` section changes stable UI meanings. Map by purpose, not merely by
+hue: a promotional orange is not a warning unless it communicates warning.
+```json
+{
+  "brick": {
+    "light": {
+      "color": {
+        "accent": {
+          "border": "#829fe0",
+          "on-soft": "#173b86",
+          "on-solid": "#ffffff",
+          "soft": "#e8efff",
+          "soft-hover": "#d9e5ff",
+          "soft-pressed": "#c6d7ff",
+          "solid": "{roles.brandPrimary}",
+          "solid-hover": "#1c489f",
+          "solid-pressed": "#173d88",
+          "text": "#214b9e"
+        }
+      }
+    }
+  }
+}
+```
+Brick publishes atomic families. Changing one member requires every member of
+that family for the same appearance; omitting the entire family safely
+inherits Brick's defaults. This prevents a new rest color from accidentally
+keeping unrelated hover, pressed, or foreground values.
+## Other sections
+- `foundations` accepts contract-declared appearance-invariant typography,
+  radius, density, and motion paths. Appearance-dependent semantic shadows are
+  mapped under `brick.light.shadow` and `brick.dark.shadow`.
+- `components` accepts only Brick's audited inherited component inputs. It is
+  not a selector or arbitrary-recipe registry. For example,
+  `components.link.decoration` accepts the intent values `"always"` or
+  `"interaction"`; the latter emits interaction-only decoration and compiles
+  only when the theme's accent link text remains at least `3:1` distinct from
+  adjacent primary text. A single Link can still override the theme with
+  `variant="underline"` or `variant="plain"`.
+- `requirements` records application work such as font and asset loading.
+- `guidance` records intent and review notes for people and agents.
+- `relationships.contrast` validates explicit foreground/background pairs
+  from `appearanceRoles`; it does not expand Brick's semantic vocabulary.
+Aliases must occupy the complete value, for example
+`"{roles.brandPrimary}"`. Unknown aliases, cycles, unsupported values,
+incomplete families, and unknown Brick paths fail compilation.

package/public/packages/theme/0.1.1/docs/colors-interchange.txt ADDED Viewed

@@ -0,0 +1,82 @@
+# Public document: colors-interchange
+Source: @flowstack-ui/theme@0.1.1
+# Colors candidate interchange
+Theme can turn a reviewed Colors candidate into a normal editable Theme. This
+is a file contract between two independent tools, not a package dependency.
+## The three inputs
+1. A serialized `flowstack.colors-candidate.v1` document whose generator
+   result is accepted and whose explicit review is `accepted` or `edited`.
+2. A `flowstack.colors-theme-scaffold.v1` mapping that contains the base Theme,
+   selected project palette names, and optional semantic assignments.
+3. The exact `theme-contract.json` from the installed Brick package.
+Example mapping:
+```json
+{
+  "$schema": "flowstack.colors-theme-scaffold.v1",
+  "theme": {
+    "$schema": "flowstack.theme.v1",
+    "metadata": { "id": "acme", "name": "Acme" },
+    "compatibility": { "brick": "^0.1.0" },
+    "appearances": {
+      "supported": ["light", "dark"],
+      "default": "system"
+    }
+  },
+  "palettes": {
+    "neutral": "neutral-source",
+    "brand": "primary-brand",
+    "campaign": "campaign-source"
+  },
+  "semantics": {
+    "neutral": "neutral",
+    "accent": "brand",
+    "focus": "brand"
+  }
+}
+```
+`palettes` maps the name wanted in the Theme to a candidate family ID. Every
+selected light/dark value is preserved under
+`palettes.colors.<name>.<appearance>`. This is where extra brand, campaign,
+chart, or editorial colors can live even when Brick has no matching role.
+`semantics` maps a UI job to one of those selected palette names:
+- `neutral` requires a neutral family and fills Brick surface, border, and
+  text families;
+- `accent`, `danger`, `info`, `success`, and `warning` require interface
+  families; and
+- `focus` requires an interface family and maps its focus-ring role.
+Theme reads the installed Brick contract and expands each selection to the
+complete atomic family. Developers choose the family and job; they do not copy
+Brick's token inventory or configure every hex line manually.
+## Output and safety
+Run:
+```bash
+flowstack-theme scaffold-colors ./colors.candidate.json \
+  --mapping ./colors.theme-scaffold.json \
+  --contract ./node_modules/@flowstack-ui/brick/dist/theme-contract.json \
+  --out-dir ./theme
+```
+The command writes:
+- `flowstack.theme.json`, the ordinary editable Theme definition; and
+- `theme.scaffold.report.json`, the source-family, mapping, and count record.
+The scaffold fails on unreviewed or rejected candidates, rejected selected
+families, incompatible profiles, missing appearances or roles, unknown
+contract families, and naming collisions. It does not declare accessibility
+success. Compile the generated Theme against the same Brick contract; the
+compiler remeasures every Brick-declared contrast pair in every appearance.

package/public/packages/theme/0.1.1/docs/fonts.txt ADDED Viewed

@@ -0,0 +1,40 @@
+# Public document: fonts
+Source: @flowstack-ui/theme@0.1.1
+# Fonts
+Theme chooses semantic font-family values but does not download, bundle, or
+preload font files. The application owns that work because frameworks have
+different optimization, licensing, privacy, and first-paint behavior.
+Record the expected integration in `requirements`:
+```json
+{
+  "foundations": {
+    "font": {
+      "family": {
+        "body": "var(--font-acme), ui-sans-serif, system-ui, sans-serif",
+        "heading": "var(--font-acme-display), ui-sans-serif, system-ui, sans-serif"
+      }
+    }
+  },
+  "requirements": {
+    "fonts": [
+      { "family": "Acme Sans", "variable": "--font-acme", "source": "application" },
+      { "family": "Acme Display", "variable": "--font-acme-display", "source": "application" }
+    ]
+  }
+}
+```
+In Next.js, load the files with the project's supported `next/font` workflow
+and place its generated variables on the same document boundary as
+`data-flowstack-theme`. In Vite or another bundler, import licensed font CSS or
+local `@font-face` declarations through the application entrypoint and expose
+the declared variables there.
+Always provide fallback families. Validate the production build with fonts
+loaded, blocked, and slow; the manifest records requirements but cannot prove
+that the application fulfilled them.

package/public/packages/theme/0.1.1/docs/installation.txt ADDED Viewed

@@ -0,0 +1,45 @@
+# Public document: installation
+Source: @flowstack-ui/theme@0.1.1
+# Installation
+Install Brick as the application UI package and Theme as development-only
+build tooling:
+```bash
+npm install @flowstack-ui/brick
+npm install --save-dev @flowstack-ui/theme
+```
+Theme `0.1` requires a Brick package whose exported theme contract has
+`contractVersion: 2` or newer. Compile a JSON definition against the installed
+artifact:
+```bash
+npx flowstack-theme compile ./theme/app.theme.json \
+  --contract ./node_modules/@flowstack-ui/brick/dist/theme-contract.json \
+  --out-dir ./src/theme/generated
+```
+Import Brick CSS and the generated Theme CSS once at the application root.
+Brick must load first so the `flowstack.theme` cascade layer can override its
+defaults and still precede Brick foundations:
+```ts
+import "@flowstack-ui/brick/styles.css";
+import "./theme/generated/theme.css";
+```
+Activate the compiled theme on the document or a subtree:
+```html
+<html data-flowstack-theme="acme">
+```
+Only the generated CSS is needed in the browser. Keep the compiler in
+`devDependencies`; do not import it from client or server rendering code.
+For deterministic builds, run compilation in a checked build step and either
+commit the generated artifacts or generate them in CI. Do not mix both models
+without a drift check.

package/public/packages/theme/0.1.1/docs/migration.txt ADDED Viewed

@@ -0,0 +1,40 @@
+# Public document: migration
+Source: @flowstack-ui/theme@0.1.1
+# Migration
+## From handwritten Brick variables
+1. Inventory application CSS variables and separate Brick semantic values
+   from application colors, fonts, assets, and layout policy.
+2. Move raw colors into `palettes`; give product meanings to reusable values in
+   `roles`.
+3. Map only actual Brick UI meanings under `brick.light` and `brick.dark`.
+4. Move supported foundations and audited global component inputs into their
+   closed sections.
+5. Keep charts, syntax, campaigns, and product-specific colors in namespaced
+   extensions.
+6. Compile against the installed Brick contract, compare generated CSS with
+   the old application values, then remove the handwritten Brick assignments.
+7. Build and qualify appearance re-entry, portals, first paint, contrast, and
+   representative application compositions.
+Do not copy Brick's complete token contract into the application. Sparse
+families inherit Brick safely; the generated result is complete.
+## Compatibility and diagnostics
+`compatibility.brick` describes the Brick package versions the theme accepts.
+The compiler separately requires theme contract revision 2 or newer. These
+checks distinguish “wrong Brick release” from a malformed contract.
+Compilation diagnostics include stable codes for incompatible Brick versions,
+unknown paths, incomplete atomic families, invalid aliases, alias cycles,
+unsupported component inputs, insufficient contrast, and contrast values the
+compiler cannot prove. Treat them as migration instructions rather than
+silencing them with application CSS.
+Brick contract deprecations, when introduced, include a replacement. Theme
+rejects authored deprecated semantic paths with a migration diagnostic instead
+of emitting an obsolete variable silently.

package/public/packages/theme/0.1.1/docs/testing.txt ADDED Viewed

@@ -0,0 +1,64 @@
+# Public document: testing
+Source: @flowstack-ui/theme@0.1.1
+# Testing
+This repository implements focused, repository, and release verification.
+```bash
+npm run check:focused -- definition
+npm run check:focused -- validation
+npm run check:focused -- compiler
+npm run check:focused -- interchange
+npm run check:focused -- cli
+npm run check:repository
+npm run check:release
+```
+## Focused owners
+- `definition` builds the package and compiles public type fixtures.
+- `validation` builds the package and runs structural validation tests.
+- `compiler` covers aliases, defaults, atomic families, fixed and dual
+  appearances, component inputs, project roles, artifact writes, deterministic
+  output, declared semantic contrast pairs, categorical component inputs,
+  conditional contrast activation, appearance-aware project roles, project
+  contrast relationships, and failure diagnostics.
+- `interchange` covers reviewed Colors candidate ingestion, project palette
+  preservation, semantic-profile compatibility, complete Brick-family
+  expansion, ordinary Theme compilation, and fail-closed diagnostics.
+- `cli` builds the package and runs CLI process tests.
+- `all` runs every focused package test.
+## Repository gate
+The repository gate verifies routing and workflows, rejects runtime
+dependencies and private imports, typechecks source, runs unit and type tests,
+builds the package, inspects the publishable archive, installs that exact
+archive into a temporary clean consumer, executes public imports, and checks
+that no automated-test port is registered or occupied. Archive qualification
+also traverses the complete Agent Knowledge manifest and coverage report,
+imports every public runtime value from its classified root or schema subpath,
+compiles against the exact installed Brick contract, exercises the serialized
+Colors handoff, runs CLI help, and bundles Brick with only the generated Theme
+CSS to prove the Theme compiler stays outside browser delivery.
+Before an exact Brick candidate is published, coordinated local qualification
+passes `FLOWSTACK_BRICK_ARCHIVE` and `FLOWSTACK_ATOM_ARCHIVE` to the same gate.
+The verifier reads both archive manifests, requires the Brick version to equal
+Theme's exact devDependency, requires Atom to equal Brick's exact dependency,
+and installs those archives into the isolated consumer. These variables are
+archive inputs only; no machine path is recorded in package source or output.
+## Release boundary
+The release gate equals the repository gate because the compiler has no browser
+or server surface. Browser qualification of Brick appearance boundaries belongs
+to the cross-repository Theme qualification batch and does not weaken this
+package's exact-archive consumer.
+Human review remains responsible for deciding whether public schema meaning is
+appropriately stable. Automated structural success cannot approve product
+semantics. Compiler contrast results cover declared opaque color pairs; browser
+qualification remains responsible for rendered states and composition.