stylegallery 0.1.0

package/guides/webpage-generation-workflow.md

@@ -0,0 +1,185 @@
+---
+type: Planning Guide
+title: Webpage Generation Workflow
+description: Intake-to-implementation workflow for turning raw content into a homepage or ordinary webpage layout.
+---
+
+# Webpage Generation Workflow
+
+Use this workflow when the request is broad: "make a webpage," "make a homepage," "turn this content into a landing page," or any similar brief where the content exists before the layout model is clear.
+
+The workflow keeps two responsibilities separate:
+
+- The StyleGallery Layout domain chooses semantic structure, spatial model, constraints, pattern stack, scroll ownership, and verification.
+- The consuming product owns brand, typography, color, images, shadows, motion, generated visuals, and final styling.
+
+## Use Cases
+
+Start by naming the page use case, because the same content can imply different spatial models.
+
+- Homepage: introduce the offer, route visitors, prove credibility, and convert or continue exploration.
+- Campaign page: keep one narrative path and one primary conversion.
+- Product page: explain the product through feature, proof, comparison, and action sections.
+- Article or editorial page: preserve reading order and place supporting material near the relevant prose.
+- Portfolio or profile page: balance identity, selected work, proof, and contact routes.
+- Documentation or support page: prioritize wayfinding, search, stable navigation, and readable task content.
+
+If the use case is a homepage or marketing-style page, start from the [Homepage recipe](../recipes/homepage.md). If the content is mostly prose, compare it with [Article page](../recipes/article-page.md). If the content is task-heavy, compare it with [Command surface](../recipes/command-surface.md), [Form flow](../recipes/form-flow.md), or [List detail](../recipes/list-detail.md).
+
+## Content-to-Layout Match
+
+Translate content into section jobs before choosing CSS.
+
+1. Inventory the supplied content as blocks: headline, proof, features, media, pricing, FAQ, contact, navigation, legal, or support.
+2. Assign each block a job: hook, explain, prove, compare, convert, navigate, or retain.
+3. Choose the closest recipe by spatial model, not by product category.
+4. Check the [primitive-to-recipe matrix](../recipes/primitive-to-recipe-matrix.md), then map each section job to reusable patterns: `cover` for first-viewport framing, `content-limiter` for readable copy, `stack` for vertical rhythm, `cluster` or `wrap-row` for actions, `ram-grid` or `card-grid` for repeated proof, `sidebar` or `sticky-aside` for nearby support.
+5. Reject patterns that only make the page look fashionable while weakening source order, focus order, scroll ownership, or content stress behavior.
+
+The output of this step is a candidate pattern stack with rejected alternatives named in the [Layout brief](layout-brief.md).
+
+## Workflow Route Examples
+
+Use these routes as trace examples before generating a GPT Image reference. Each route must preserve this order: content blocks become section jobs, section jobs choose a recipe, the recipe yields a pattern stack, scroll owner and constraints are named, harmony evaluation approves the contract, and only then can a GPT Image reference be generated.
+
+### Homepage Route
+
+Path: Content blocks -> Section jobs -> Recipe -> Pattern stack -> Scroll owner -> Constraints -> Harmony evaluation -> GPT Image reference -> Implementation handoff
+
+- Content blocks: headline, offer explanation, proof, feature groups, comparison, CTA, footer navigation.
+- Section jobs: hook, explain, prove, compare, convert, navigate.
+- Recipe: [Homepage](../recipes/homepage.md).
+- Pattern stack: `cover`, `content-limiter`, `stack`, `cluster`, `ram-grid`, `frame`.
+- Scroll owner: normal document scroll; no nested scroll region unless a media reel has an explicit independent task.
+- Constraints: content measure, page gutters, section gaps, repeat-grid minimums, media ratios, and CTA wrapping thresholds.
+- Rejected alternatives: dashboard, article, form, command surface, or list-detail recipes when the content is primarily promotional and decision-path based.
+
+### Dashboard Route
+
+Path: Content blocks -> Section jobs -> Recipe -> Pattern stack -> Scroll owner -> Constraints -> Harmony evaluation -> GPT Image reference -> Implementation handoff
+
+- Content blocks: page title, filters, status panels, metrics, repeated workflow cards, primary actions.
+- Section jobs: orient, filter, scan, compare, act.
+- Recipe: [Dashboard](../recipes/dashboard.md).
+- Pattern stack: `page-grid`, `card-grid`, `cluster`, with `ram-grid` or `dense-grid` only when repeated panels need them.
+- Scroll owner: normal document scroll unless a declared panel has independent scroll state.
+- Constraints: page gutters, panel gaps, minimum panel widths, action wrapping, and any fixed panel block size.
+- Rejected alternatives: homepage framing when the primary task is repeated scan-and-compare work, or form flow when panels must remain comparable.
+
+### Article Route
+
+Path: Content blocks -> Section jobs -> Recipe -> Pattern stack -> Scroll owner -> Constraints -> Harmony evaluation -> GPT Image reference -> Implementation handoff
+
+- Content blocks: title, deck, prose sections, figures, references, supplemental aside, related links.
+- Section jobs: orient, read, reference, retain.
+- Recipe: [Article page](../recipes/article-page.md).
+- Pattern stack: `content-limiter`, `sticky-aside`, `stack`, with `sidebar` only when support content must sit near prose.
+- Scroll owner: document scroll; aside stickiness cannot create an unnamed nested scroll region.
+- Constraints: readable measure, section gaps, local prose gaps, figure ratios, and aside width or collapse point.
+- Rejected alternatives: homepage or dashboard recipes when the primary task is sequential reading.
+
+### Form Route
+
+Path: Content blocks -> Section jobs -> Recipe -> Pattern stack -> Scroll owner -> Constraints -> Harmony evaluation -> GPT Image reference -> Implementation handoff
+
+- Content blocks: form title, instructions, field groups, validation messages, primary and secondary actions, help text.
+- Section jobs: orient, collect, validate, submit, recover.
+- Recipe: [Form flow](../recipes/form-flow.md).
+- Pattern stack: `content-limiter`, `stack`, `cluster`, with `sticky-footer` only when persistent actions do not hide errors or focus targets.
+- Scroll owner: document scroll unless a shell owns a named body scroll area.
+- Constraints: form measure, field gaps, group gaps, action gaps, wrapping thresholds, and validation-message space.
+- Rejected alternatives: dashboard or command-surface layouts when the task is a sequential input flow.
+
+### Command Surface Route
+
+Path: Content blocks -> Section jobs -> Recipe -> Pattern stack -> Scroll owner -> Constraints -> Harmony evaluation -> GPT Image reference -> Implementation handoff
+
+- Content blocks: command bar, navigation or mode switcher, primary work area, inspector or supporting pane, status feedback.
+- Section jobs: orient, command, inspect, edit, confirm.
+- Recipe: [Command surface](../recipes/command-surface.md).
+- Pattern stack: `scroll-body-shell`, `split-nav`, `wrap-row`, with `reel` only when horizontal command scanning is intentional.
+- Scroll owner: shell body owns content scrolling; fixed command regions stay outside the body scroll container.
+- Constraints: shell height, command gaps, command wrapping behavior, pane widths, and overflow responsibilities.
+- Rejected alternatives: homepage, article, or form flow recipes when stable commands and controlled regions define the task.
+
+## Harmony Evaluation
+
+Run harmony evaluation before generating images or writing implementation CSS. Use the [Harmony evaluation gate](../quality/gates/harmony-evaluation.md) for the claim shape.
+
+Check:
+
+- Content hierarchy: the section order follows the visitor's decision path.
+- Spatial rhythm: repeated sections share a rhythm, while sections with different jobs have distinct scale or grouping.
+- Weight balance: primary content receives visual weight before supporting content and decoration.
+- Constraint fit: gutters, section gaps, readable measures, media ratios, and grid minimums support real content.
+- Accessibility precedence: semantic order, focus order, keyboard routes, reduced-motion needs, and readable text override visual novelty.
+- Pattern boundary: reusable pattern CSS remains layout-only; brand and generated-image styling stay in the consuming product.
+
+If the harmony claim fails, revise the content map or pattern stack before generating the visual reference.
+
+## GPT Image Reference
+
+Generate the GPT Image reference only after the use case, section jobs, semantic skeleton, pattern stack, and harmony notes are approved.
+
+Required preconditions before prompt:
+
+- use case, audience, content blocks, and section jobs are recorded;
+- recipe, semantic skeleton, pattern stack, scroll owner, constraints, and harmony notes are approved.
+
+The image prompt should include:
+
+- page use case and audience;
+- section list with each section job;
+- approved semantic order and pattern stack;
+- required hierarchy, spacing, media ratio, CTA priority, and scroll behavior;
+- accessibility constraints that the image must respect;
+- instruction to keep the render implementation-friendly and readable;
+- instruction that decorative styling is product-level and not part of reusable pattern CSS.
+
+Generate one clear homepage or section reference image when the page is short. For a larger homepage, generate section-level references so text, spacing, and hierarchy remain inspectable.
+
+After generation, review the image with this extract-vs-ignore split:
+
+Extract from image:
+
+- section rhythm, hierarchy, approximate spacing, media treatment, and CTA priority;
+- unclear areas that need another image or a written decision;
+
+Ignore from image:
+
+- decorative choices that belong to the consuming product, not this pattern library.
+- claims about source order, focus order, accessibility, usability, brand correctness, or implementation correctness.
+
+Do not treat a generated image as proof of usability, accessibility, or brand fit. It is a visual reference that still needs quality gates and real implementation verification.
+
+## Implementation Handoff
+
+Before implementation, hand off a compact contract:
+
+```txt
+Use case:
+Primary task:
+Audience:
+Section jobs:
+Semantic HTML skeleton:
+Pattern stack:
+Scroll owner:
+Constraints and change points:
+Harmony evaluation:
+GPT Image reference:
+Image observations to implement:
+Image observations to ignore:
+Consumer reference: not_applicable
+Consumer reference reason: This generic workflow declares no consumer-specific reference record.
+Accessibility checks:
+Viewport/content stress checks:
+Implementation debt:
+Final implementation proof:
+Accepted debt:
+```
+
+Every handoff keeps the consumer-reference field. Replace the default `not_applicable` pair only when the consuming repository has one canonical record; then use `Consumer reference: declared` and a normalized repository-relative `.json` path under that repository root. See the [Consumer Reference Receiver Contract](../consumer-reference/contract.md).
+
+Do not add a migration-conformance field to ordinary webpage work. When an existing consumer is explicitly being migrated, add `Consumer migration conformance: declared` and a normalized consumer-local JSON path, then follow [Consumer Migration Readiness](../design-engineering/consumer-migration-readiness.md). This extension does not change the ordinary `not_applicable` default.
+
+The implementer builds from semantic HTML and layout patterns first, then applies product-level visual styling from the image reference outside reusable pattern CSS. The final page must still pass layout stress checks, accessibility evidence, and any visual-evidence protocol declared by the consuming product.

package/index.md

@@ -0,0 +1,36 @@
+---
+okf_version: "0.1"
+---
+
+# StyleGallery
+
+StyleGallery is an OKF-style knowledge bundle organized into governed interface-knowledge domains. Existing Layout paths remain canonical while Motion, Design Engineering, Game UI, and Platform Guides own separate product and reference boundaries.
+
+Primary role: OKF bundle map.
+
+## Concepts
+
+- [StyleGallery domain manifest](DOMAINS.md) - Domain ownership, scope, lifecycle, page membership, and provenance policy.
+- [Layout](layout/index.md) - Existing spatial patterns, recipes, planning guides, and layout quality routes.
+- [Motion](motion/index.md) - Motion terminology, review workflow, and evidence-bounded practice reference.
+- [Design Engineering](design-engineering/index.md) - Product-layer interface-craft decisions and verification questions.
+- [Game UI](game-ui/index.md) - Game-interface classification, hierarchy, reference records, and named engine implementation guides.
+- [Platform Guides](platform-guides/index.md) - Bounded comparative references for named platforms.
+- [Consumer reference](consumer-reference/index.md) - Shared non-domain receiver contract for declared repository-local JSON records or reasoned non-applicability.
+- [Agent-Native StyleGallery](consumer-reference/agent-native/README.md) - Machine-facing identity, retrieval, operation, CLI, read-only MCP, task projection, and governed-learning contracts.
+- [Consumer migration readiness](design-engineering/consumer-migration-readiness.md) - Experimental Design Engineering method for consumer-owned conformance, runtime proof, and source-bound page evidence.
+- [Repository guide](README.md) - StyleGallery domain routes, shared policy, and Layout authoring principles.
+- [Layout planning guide](GUIDE.md) - Pre-design entry point for choosing and composing StyleGallery Layout patterns.
+- [Webpage generation workflow](guides/webpage-generation-workflow.md) - Intake-to-implementation workflow for homepage and webpage creation.
+- [Documentation mode taxonomy](guides/documentation-mode-taxonomy.md) - Primary documentation modes, hybrid decisions, and task routing.
+- [Controlled vocabulary](guides/vocabulary.md) - Canonical terminology, aliases, deprecated terms, and scannability rules.
+- [Decision tree](guides/decision-tree.md) - Question-driven route from screen constraints to StyleGallery Layout patterns and recipes.
+- [Layout brief](guides/layout-brief.md) - Questions to answer before selecting a layout pattern stack.
+- [Layout recipes](recipes/index.md) - Screen-level compositions built from reusable patterns.
+- [Agent instructions](AGENTS.md) - Shared domain-classification rules plus domain-specific editing constraints for StyleGallery.
+- [Governance, lifecycle, and docs-as-code](GOVERNANCE.md) - Source-of-truth, generated artifact, lifecycle, ownership, and stale-content policy.
+- [Layout pattern catalog](CATALOG.md) - Generated index of Layout-domain patterns.
+- [Pattern categories](patterns/index.md) - Category index for generated layout patterns.
+- [Quality gates](quality/index.md) - Principle-backed gates for admissible layout and design evidence claims.
+- [Consumer migration evidence gate](quality/gates/consumer-migration-evidence.md) - Blocking contract for declared migration evidence.
+- [Update log](log.md) - Bundle update history.

package/layout/index.md

@@ -0,0 +1,26 @@
+# Layout
+
+The Layout domain owns minimal, portable CSS layout patterns and their planning, composition, constraint, scroll-ownership, and verification contracts. Its canonical content remains at the existing repository paths.
+
+## Scope Boundary
+
+In scope: semantic spatial structure, flow, sizing, alignment, containment, scrolling, ratios, and layout composition.
+
+Out of scope: product motion, brand, typography, color, shadow, decorative treatment, and platform imitation.
+
+## Routes
+
+- Start with the [Layout Planning Guide](../GUIDE.md) when the spatial problem is not yet clear.
+- Use the [Layout Decision Tree](../guides/decision-tree.md) when the pattern name is unknown.
+- Browse the [Layout Pattern Catalog](../CATALOG.md) when the problem or name is known.
+- Compose full screens with [Layout Recipes](../recipes/index.md).
+- Review claims through [Quality Gates](../quality/index.md).
+
+## Stable Path Contract
+
+`GUIDE.md`, `guides/*.md`, `recipes/*.md`, `patterns/**/*.md`, `CATALOG.md`, and `quality/**/*.md` remain at their existing paths. This hub is a domain-local route, not a migration or duplicate source of truth.
+
+## IA Navigation
+
+Parent: [StyleGallery](../index.md).
+Next: [Motion](../motion/index.md).

package/motion/index.md

@@ -0,0 +1,24 @@
+# Motion
+
+The Motion domain owns terminology, review procedure, and evidence-bounded practice guidance for product-layer motion.
+
+## Scope Boundary
+
+In scope: naming observable motion, reviewing declared behavior, distinguishing heuristics from measured contracts, and identifying evidence needs.
+
+Out of scope: universal timing or easing rules, unmeasured performance claims, and permission to add animation or decorative properties to reusable Layout pattern CSS.
+
+## Documents
+
+- [Motion Vocabulary](vocabulary.md) maps observed behavior to implementation-neutral terms while preserving ambiguity.
+- [Motion Review Workflow](review-workflow.md) structures evidence-first review and remediation.
+- [Motion Practice Reference](practice-reference.md) classifies mechanics, heuristics, platform notes, and unsupported claims.
+
+## Domain Contract
+
+See [StyleGallery Domains](../DOMAINS.md) for lifecycle, provenance, page membership, and promotion rules.
+
+## IA Navigation
+
+Parent: [StyleGallery](../index.md).
+Next: [Motion Vocabulary](vocabulary.md).

package/motion/practice-reference.md

@@ -0,0 +1,145 @@
+---
+type: Domain Guide
+title: Motion Practice Reference
+description: Bounded motion mechanics, heuristics, platform notes, and verification requirements.
+domain: motion
+lifecycle: experimental
+source_repository: https://github.com/emilkowalski/skills
+source_path: skills/review-animations/STANDARDS.md
+source_revision: 220e8607c90b17337d210125777b7b695f26c221
+---
+
+# Motion Practice Reference
+
+Primary role: motion evidence reference.
+
+## Repository Boundary
+
+This is a practice reference, not a standards document. Each item states what kind of claim it is and how to verify it before use.
+
+## Reusable Method
+
+For every proposed rule, record:
+
+```text
+Guidance:
+Classification: reusable mechanic | opinionated heuristic | platform-specific | unsupported
+Context:
+Warrant:
+Evidence:
+Verification:
+Boundary:
+```
+
+The classification controls authority. A reusable mechanic may explain a causal relationship; a heuristic proposes a starting question; a platform note is valid only for its named source/version; an unsupported claim cannot become a blocker.
+
+## Practice Map
+
+### Purpose And Frequency
+
+Guidance: State why a transition exists and how often the user encounters it.
+
+Classification: opinionated heuristic.
+
+Verification: compare task completion and state comprehension with the behavior present, reduced, and removed.
+
+Boundary: frequency alone does not dictate a universal duration or deletion rule.
+
+### Spatial Continuity
+
+Guidance: Preserve understandable relationships between trigger, moving representation, destination, and dismissal path.
+
+Classification: reusable mechanic.
+
+Verification: inspect before, intermediate, interrupted, and after states together with DOM and focus order.
+
+Boundary: visual continuity cannot override semantic order or accessibility.
+
+### Interruption
+
+Guidance: A repeatedly triggered or directly manipulated transition should respond to new input without visible jumps or input lockout.
+
+Classification: reusable mechanic.
+
+Verification: reverse and retarget the interaction at multiple points while recording the presented state.
+
+Boundary: no specific animation API is required.
+
+### Timing, Easing, And Springs
+
+Guidance: Treat timing curves and dynamic parameters as context-dependent starting hypotheses.
+
+Classification: opinionated heuristic.
+
+Verification: compare variants on the target device and task; record response latency, interruption, overshoot, and completion cues.
+
+Boundary: fixed duration, easing, damping, bounce, or velocity values are not cross-product standards.
+
+### Performance
+
+Guidance: Prefer changes that avoid unnecessary repeated layout and paint work when measurements show they are material.
+
+Classification: reusable mechanic.
+
+Verification: use browser performance traces, frame evidence, target hardware, and representative concurrent work.
+
+Boundary: `transform`, `opacity`, CSS, JavaScript, or Web Animations do not guarantee compositor/GPU execution or superior performance.
+
+### Preferences And Input Capabilities
+
+Guidance: Provide an equivalent state and feedback path for relevant user preferences and input capabilities.
+
+Classification: reusable mechanic.
+
+Verification: inspect the actual reduced-motion behavior, keyboard/pointer/touch flows, focus visibility, and state announcement.
+
+Boundary: reduced motion may mean removal, substitution, or reduction; hover/pointer media features do not identify a universal device class.
+
+### Product Cohesion
+
+Guidance: Evaluate whether motion supports the product's declared task and tone.
+
+Classification: opinionated heuristic.
+
+Verification: use comparative review with named criteria and representative users when the claim concerns human perception.
+
+Boundary: cohesion and delight are not mechanically provable from source code.
+
+## Opinionated Guidance
+
+Shorter, smaller, and less frequent motion is often a useful remediation direction for high-frequency interfaces, but it is not automatically correct. Source-anchored paths and asymmetry may improve comprehension when they correspond to real state relationships; they require rendered evidence.
+
+## Platform-Specific Guidance
+
+Browser compositor behavior, framework shorthands, native springs, pointer models, and operating-system preferences must be sourced and versioned independently. A native-platform value does not automatically translate to CSS or a JavaScript animation library.
+
+## Unsupported Absolutes
+
+- Only transform and opacity may be animated.
+- Transform and opacity always run on the GPU.
+- CSS animations categorically outperform JavaScript.
+- Web Animations is universally hardware accelerated.
+- Parent custom-property updates always cause unacceptable recalculation.
+- A framework shorthand necessarily drops frames.
+- Reduced motion always means crossfade rather than removal.
+- Hover and pointer queries identify a touch-device class.
+- All interface motion must remain under one fixed duration.
+
+These statements may become scoped hypotheses only after the context, source, and verification protocol are named.
+
+## Verification Contract
+
+Use slow-motion or frame-by-frame inspection for discontinuity, browser traces for delivery claims, keyboard and assistive-technology checks for interaction/accessibility claims, and real-device or user evidence for perceptual quality. State what the selected evidence cannot prove.
+
+## Source, License, And Attribution
+
+- Upstream inspiration: [review-animations/STANDARDS.md](https://github.com/emilkowalski/skills/blob/220e8607c90b17337d210125777b7b695f26c221/skills/review-animations/STANDARDS.md)
+- Snapshot: `220e8607c90b17337d210125777b7b695f26c221`
+- Upstream license: MIT, Copyright (c) 2026 Emil Kowalski.
+- Reuse form: independent method rewrite; upstream prose, tables, code, examples, and distinctive ordering were not retained.
+- Evidence boundary: the upstream practice source can suggest questions but cannot prove local performance, accessibility, usability, or quality.
+
+## IA Navigation
+
+Parent: [Motion](index.md).
+Next: [Design Engineering](../design-engineering/index.md).

package/motion/review-workflow.md

@@ -0,0 +1,86 @@
+---
+type: Domain Guide
+title: Motion Review Workflow
+description: Evidence-first workflow for reviewing product-layer motion without changing Layout policy.
+domain: motion
+lifecycle: experimental
+source_repository: https://github.com/emilkowalski/skills
+source_path: skills/review-animations/SKILL.md
+source_revision: 220e8607c90b17337d210125777b7b695f26c221
+---
+
+# Motion Review Workflow
+
+Primary role: motion review procedure.
+
+## Repository Boundary
+
+This workflow reviews declared product-layer motion. It does not review unrelated code, create feature requirements, or turn preferences into blockers. Shared accessibility and evidence gates take precedence; Layout source order, constraints, and scroll ownership remain authoritative for reusable patterns.
+
+## Reusable Method
+
+### Intake
+
+Name the interaction, trigger, frequency, affected state, expected purpose, supported input modes, reduced-motion behavior, and verification surface. If the purpose or observable is absent, record an evidence gap before discussing polish.
+
+### Inspect
+
+Review four boundaries in order:
+
+1. State and source continuity: the before/after states, DOM order, focus, and recoverability remain coherent.
+2. Interaction continuity: repeated input, interruption, reversal, cancellation, and rapid state changes do not jump or lock input.
+3. Accessibility: motion alternatives and input-capability assumptions match the actual user preference and interaction contract.
+4. Delivery evidence: rendered frames, performance traces, and real-device behavior support claims that source inspection cannot prove.
+
+### Finding Record
+
+| Impact | Location | Observed behavior | Proposed change | Warrant | Evidence | Boundary |
+| --- | --- | --- | --- | --- | --- | --- |
+| What fails for the task | `file:line` or rendered state | Reproducible observation | Smallest corrective direction | Why the evidence supports it | Trace, recording, test, or source | What remains unproven |
+
+### Decision
+
+- `blocked`: a declared local contract, accessibility requirement, or required evidence gate fails.
+- `review_required`: the decision depends on missing rendered, device, user, or performance evidence.
+- `approve_with_debt`: behavior is acceptable for the declared scope and the remaining bounded debt has an owner and trigger.
+- `pass`: all declared motion contracts and required evidence are satisfied.
+
+## Remediation Order
+
+1. Confirm the motion has a task or state purpose.
+2. Remove motion that has no necessary job.
+3. Reduce frequency, distance, scope, or affected elements.
+4. Preserve spatial, semantic, and focus relationships.
+5. Make repeated and interrupted state changes continuous.
+6. Measure the performance claim on the target surface.
+7. Provide an evidence-based alternative for relevant preferences and inputs.
+8. Tune product-specific character only after the contracts above pass.
+
+## Opinionated Guidance
+
+Frequency, duration, easing, physicality, and cohesion can be useful review prompts. They remain context-dependent heuristics. “Feels right,” popularity, or a practitioner's preference is not a sufficient warrant for blocking a change.
+
+## Platform-Specific Guidance
+
+CSS transitions, Web Animations, Motion/Framer Motion, pointer events, and component-library transform origins are implementation examples. A review may recommend one only after verifying browser support, current implementation constraints, and the behavior that must change.
+
+## Unsupported Absolutes
+
+Do not automatically block `ease-in`, a particular scale value, motion longer than a fixed threshold, a keyboard-triggered transition, a non-transform property, or a particular stagger interval. Do not claim GPU execution, hardware acceleration, or accessibility from a property name or API choice alone.
+
+## Verification Contract
+
+Exercise the actual interaction in its default, repeated, interrupted, reversed, and reduced-motion states. Record the exact environment and observable. Source review may establish declared code paths; rendered and human outcomes require corresponding evidence families.
+
+## Source, License, And Attribution
+
+- Upstream inspiration: [review-animations/SKILL.md](https://github.com/emilkowalski/skills/blob/220e8607c90b17337d210125777b7b695f26c221/skills/review-animations/SKILL.md)
+- Snapshot: `220e8607c90b17337d210125777b7b695f26c221`
+- Upstream license: MIT, Copyright (c) 2026 Emil Kowalski.
+- Reuse form: independent method rewrite; upstream prose, tables, code, examples, and distinctive ordering were not retained.
+- Evidence boundary: this procedure adapts a review shape, not its categorical practitioner judgments.
+
+## IA Navigation
+
+Parent: [Motion](index.md).
+Next: [Motion Practice Reference](practice-reference.md).

package/motion/vocabulary.md

@@ -0,0 +1,82 @@
+---
+type: Domain Guide
+title: Motion Vocabulary
+description: Evidence-bounded method and reference for naming observable interface motion.
+domain: motion
+lifecycle: experimental
+source_repository: https://github.com/emilkowalski/skills
+source_path: skills/animation-vocabulary/SKILL.md
+source_revision: 220e8607c90b17337d210125777b7b695f26c221
+---
+
+# Motion Vocabulary
+
+Primary role: motion terminology reference.
+
+## Repository Boundary
+
+This page helps a reader name observed motion. It does not prescribe implementation, authorize motion in reusable Layout CSS, or make a product-quality judgment.
+
+The terms are implementation-neutral. A framework, operating-system behavior, or branded example may illustrate a term only when clearly labeled and separately verified.
+
+## Reusable Method
+
+1. Record what changes: presence, position, scale, shape, state, scroll relationship, or feedback.
+2. Record what coordinates the change: time, sequence, input, velocity, or viewport progress.
+3. Compare the observation with the closest term families below.
+4. Return one exact term only when the observed cues distinguish it.
+5. When multiple terms remain plausible, return ordered candidates and state the missing observation.
+6. When nothing matches, return `unknown`; do not invent a canonical winner.
+
+## Term Families
+
+| Term | Observed cues | Distinguish from | Implementation-neutral meaning | Evidence boundary |
+| --- | --- | --- | --- | --- |
+| Fade | Visibility changes without a necessary spatial path. | Reveal | A gradual visibility change. | Does not imply opacity is the implementation. |
+| Slide | The element follows a directional path into, out of, or within a region. | Shared-element transition | A positional transition without necessarily preserving identity across views. | Direction and clipping must be observed. |
+| Scale transition | Apparent size changes around an origin. | Morph | Size changes while the element's basic identity remains stable. | Does not establish the correct origin or amount. |
+| Reveal | A boundary progressively exposes content. | Fade | Visibility is controlled by an advancing edge, mask, or equivalent boundary. | The masking mechanism may be unknown. |
+| Stagger | Similar elements begin related changes at distinct offsets. | Orchestration | A repeated sequence pattern, usually across peers. | The offset value is product-specific. |
+| Orchestration | Several motion events form one coordinated sequence. | Stagger | Coordination may include different elements, jobs, and timings. | Intent must be documented, not inferred from timing alone. |
+| Crossfade | One state loses visibility while another gains it in the same region. | Morph | Identity is exchanged rather than geometrically transformed. | Overlap and source order need inspection. |
+| Shared-element transition | A recognizable element appears to retain identity between states or views. | Layout animation | Continuity connects a source representation with a destination representation. | Identity continuity is a perception claim requiring rendered evidence. |
+| Layout animation | A spatial change is visually interpolated instead of appearing instantly. | Shared-element transition | Position or size changes within the layout state of an element. | Does not endorse animating layout-triggering CSS properties. |
+| Scroll-driven motion | Progress corresponds to scroll progress. | Scroll reveal | The scroll position continuously controls progress rather than merely triggering entry. | Browser and input behavior require local testing. |
+| Parallax | Layers appear to travel at different rates during a shared movement. | Ordinary scroll | Relative speed creates a depth cue. | Depth, comfort, and reduced-motion outcomes are not guaranteed. |
+| Spring motion | Response is modeled as a target-seeking dynamic system rather than a fixed timeline. | Bounce | A spring may settle without visible overshoot. | Parameters and perceived duration remain implementation-specific. |
+| Bounce | Motion overshoots or reverses before settling. | Spring motion | Visible overshoot is the defining cue, regardless of implementation. | Playfulness and appropriateness are product judgments. |
+| Interruptible motion | New input redirects a change from its current presented state. | Restarted animation | Continuity is maintained when the target changes mid-flight. | Requires interaction evidence, not source inspection alone. |
+| Rubber-band response | Movement continues beyond a boundary with increasing resistance, then returns. | Bounce | Resistance is tied to boundary overshoot and direct manipulation. | Platform examples are not a universal physics contract. |
+| Jank | Motion visibly misses expected visual continuity. | Intentional stepped motion | The discontinuity is unintended and associated with delivery or computation limits. | Frame or performance evidence is needed to attribute cause. |
+
+## Opinionated Guidance
+
+The family ordering favors what a reader can observe before implementation details. It is useful for retrieval, but it is not a complete ontology. Add a term only after a reader task demonstrates that existing terms and aliases cannot express the distinction.
+
+## Platform-Specific Guidance
+
+Names tied to iOS, macOS, a browser API, Motion, Framer Motion, React, or a component library are examples or implementation facets. Keep the cross-platform term primary and label the platform context separately.
+
+## Unsupported Absolutes
+
+- Do not call this vocabulary authoritative outside StyleGallery.
+- Do not force the nearest term when the observation is incomplete.
+- Do not attach universal FPS, GPU, duration, easing, or reduced-motion rules to a definition.
+- Do not infer implementation technology from rendered appearance alone.
+
+## Verification Contract
+
+A vocabulary lookup should exercise exact, ambiguous, and unknown cases. Pass requires one justified term, an ordered candidate set with a stated distinction, or `unknown`; invented winners fail. A new term also requires a findability task showing the current route cannot reach an adequate term within two hops.
+
+## Source, License, And Attribution
+
+- Upstream inspiration: [animation-vocabulary/SKILL.md](https://github.com/emilkowalski/skills/blob/220e8607c90b17337d210125777b7b695f26c221/skills/animation-vocabulary/SKILL.md)
+- Snapshot: `220e8607c90b17337d210125777b7b695f26c221`
+- Upstream license: MIT, Copyright (c) 2026 Emil Kowalski.
+- Reuse form: independent method rewrite; upstream prose, tables, code, examples, and distinctive ordering were not retained.
+- Evidence boundary: the upstream artifact records practitioner terminology; it does not prove local performance, accessibility, usability, or quality.
+
+## IA Navigation
+
+Parent: [Motion](index.md).
+Next: [Motion Review Workflow](review-workflow.md).