stylegallery 0.1.4 → 0.1.7

package/design-terminology/token-semantics.md

@@ -0,0 +1,90 @@
+---
+type: Domain Guide
+title: Token Semantics And Resolution
+description: Compare semantic roles, references, groups, resolver contexts, and runtime values without treating their names as interchangeable.
+domain: design-terminology
+lifecycle: experimental
+provenance_kind: local
+reviewed_on: 2026-09-21
+---
+
+# Token Semantics And Resolution
+
+Primary role: source-specific token terminology comparison.
+
+## Repository Boundary
+
+This page compares vocabulary and the decisions obscured by ambiguous token names. It imports no token values, themes, or compiler behavior. [Consumer Reference](../consumer-reference/index.md) owns interchange/evidence infrastructure; consumer profiles own their values and implementation. Layout's token boundary remains unchanged.
+
+Canonical term and relation records live in [Cross-System Term Cases](conflict-cases.md). This guide explains their use; it does not establish a second term registry.
+
+## Reusable Method
+
+When a handoff says “alias,” “semantic,” or “theme,” identify whether it refers to design intent, a reference edge, organization, context selection, or a runtime representation. Record the named source before choosing an equivalence relation. Inspect the exported structure separately from the visual result.
+
+### Sources And Distinctions
+
+| Source | Source-backed distinction | Question for a handoff |
+| --- | --- | --- |
+| [Fluent 2 tokens](https://fluent2.microsoft.design/design-tokens) | Global tokens hold context-independent values; alias tokens add semantic meaning. | Does “alias” name a semantic layer in this system? |
+| [DTCG Format 2025.10](https://www.designtokens.org/tr/2025.10/format/) | A token value may reference another token; groups organize records. | Does “alias” name a reference relationship in an interchange document? |
+| [Carbon color overview](https://carbondesignsystem.com/elements/color/overview/) | Color tokens preserve roles across themes while assigned values can change. | Is the role stable across every theme being compared? |
+| [Carbon color usage](https://carbondesignsystem.com/elements/color/usage/) | Contextual color tokens depend on the layer where they are used. | Is the surrounding layer part of value resolution? |
+| [DTCG Resolver 2025.10](https://www.designtokens.org/tr/2025.10/resolver/) | Modifiers conditionally select sources through contexts; ordered resolution determines the resulting token set. | Where are the selected contexts and conflict order recorded? |
+| [CSS Custom Properties Level 1](https://www.w3.org/TR/css-variables-1/) | Custom properties participate in CSS runtime value substitution and the cascade. | Which original semantics and metadata remain after translation? |
+
+All six source surfaces were inspected on 2026-09-21. DTCG 2025.10 modules are Community Group reports, not W3C Recommendations. The Fluent and Carbon pages are dated system documentation, not guarantees about every package release.
+
+### Alias Is Not One Decision
+
+The recorded `fluent.alias-token` / `dtcg.alias` relation is `partial_overlap`. A semantic token may use a reference, but a reference edge does not itself prove a semantic role. A reference between two raw values illustrates the non-semantic region; a consumer's exported semantic value may be flattened and no longer retain its reference edge.
+
+The `fluent.alias-token` / `carbon.color-token` relation is also scoped overlap. Both can express role-oriented color decisions, but their vocabularies and non-color coverage differ. This is not permission to rename one system's tokens after another's or assert that their role sets are identical.
+
+### Grouping Is Not Context Selection
+
+The recorded `dtcg.resolver-modifier` / `dtcg.group` relation is `not_comparable` for organization-versus-resolution. Ask where a context is selected, where sources are ordered, and where a group is merely a path. A directory or group named `dark` does not independently explain how a consumer chooses dark appearance.
+
+This distinction also prevents confusing a token system's theme with a user's complete preference state. A selected theme does not determine text scaling, reduced motion, or every platform accessibility preference; those adaptation decisions belong to [Platform Guides](../platform-guides/preferences-and-accessibility.md).
+
+### Worked Handoff: Same Color, Different Meaning
+
+Two consumer roles happen to resolve to the same displayed color in one theme. Preserve the roles separately when their purposes differ. Equality of an output value is evidence of that output only; it does not justify merging source concepts.
+
+| Handoff field | Proposed content | Why it matters |
+| --- | --- | --- |
+| Source term | Source-qualified identifier and locator | Keeps a role name attached to its own vocabulary. |
+| Comparison scope | The particular translation being considered | Prevents a local mapping from becoming universal equivalence. |
+| Context | Theme, layer, or resolver inputs actually selected | Makes value resolution reproducible. |
+| Output representation | Target format and adapter version | Separates serialization from semantic intent. |
+| Retained/lost information | Role, reference edges, metadata, and unsupported structures | Exposes lossy translation. |
+| Verification | Structural check plus rendered state evidence if appearance is claimed | Avoids treating a valid file as a usable component. |
+
+The fields are a local analysis aid. They do not expand this repository's closed token adapter or admit arbitrary DTCG features into existing schemas.
+
+## Opinionated Guidance
+
+Prefer source-qualified names in cross-system discussions. Before merging tokens, compare responsibilities across contexts, not just matching values in a screenshot. Keep compiler inputs explicit enough that another consumer can explain how an output was obtained.
+
+## Platform-Specific Guidance
+
+An exported custom property, native resource, or tool variable can consume translated design information without preserving the full source contract. The concrete adapter owns unit conversion, missing features, and runtime context. Comparative vocabulary cannot certify that adapter.
+
+## Unsupported Absolutes
+
+A reference is not proof of semantic intent. A group is not automatically a theme selector. The same value is not the same role. A valid DTCG document is not a declaration that StyleGallery supports every feature in that document.
+
+## Verification Contract
+
+Recheck both source locators for each relied-on relation and record the scope and direction. Probe a matching value with different roles, a changed theme, a contextual layer change, and a flattened export. Inspect the actual adapter if making a round-trip or runtime claim.
+
+These are proposed checks. Only source readings and Markdown record consistency are claimed here; no token pipeline or product rendering was executed. Re-review when a vocabulary, module version, or adapter contract changes.
+
+## Source, License, And Attribution
+
+Locally authored synthesis; no source token values or upstream expression are copied. Terminology reliance: `fluent.alias-token`, `fluent.global-token`, `carbon.color-token`, `dtcg.alias`, `dtcg.token`, `dtcg.group`, `dtcg.resolver-modifier`, and `css.custom-property`. Relations used: `partial_overlap`, `implementation_representation`, and `not_comparable`. Named sources were rechecked 2026-09-21; local relations remain author judgments, not independent semantic approval. `consumer_reference: not_applicable` because no consumer profile or adapter record is selected.
+
+## IA Navigation
+
+Parent: [Design Terminology](index.md).
+Next: [Typography Semantics](typography-semantics.md).

package/design-terminology/typography-semantics.md

@@ -0,0 +1,86 @@
+---
+type: Domain Guide
+title: Typography Roles, Styles, And Representations
+description: Compare named type roles, native scaling behavior, composite token records, and CSS output without inventing universal size mappings.
+domain: design-terminology
+lifecycle: experimental
+provenance_kind: local
+reviewed_on: 2026-09-21
+---
+
+# Typography Roles, Styles, And Representations
+
+Primary role: typography vocabulary comparison.
+
+## Repository Boundary
+
+This guide compares source-specific meanings. It defines no StyleGallery type scale, font choice, size, density, or visual token. Product typography belongs to its consumer; Layout owns spatial behavior. [Term Cases](conflict-cases.md) is the canonical record for the term identifiers and relations used here.
+
+## Reusable Method
+
+Identify whether “style” means a semantic role, a bundle of values, a collection of role slots, a native scaling behavior, or a runtime declaration. Compare sources at that level. Then record what information is lost when the result is serialized or rendered elsewhere.
+
+### Source Findings
+
+| Source | Bounded meaning | Boundary to retain |
+| --- | --- | --- |
+| [Apple HIG typography](https://developer.apple.com/design/human-interface-guidelines/typography) | Text styles combine typographic attributes into a hierarchy and participate in system text-size adaptation. | A single exported size does not encode the complete native scaling behavior. |
+| [Fluent 2 typography](https://fluent2.microsoft.design/typography) | The type ramp supplies named styles and roles for a selected target platform. | A role label does not specify one universal font or numeric size across platforms. |
+| [Material 3 in Compose](https://developer.android.com/develop/ui/compose/designsystems/material3#typography) | The `Typography` class models the Material 3 type scale using named style slots. | This is the system's Compose implementation surface, not an interchange specification. |
+| [DTCG typography type](https://www.designtokens.org/tr/2025.10/format/#typography) | The composite record includes family, size, weight, letter spacing, and line height. | The record does not itself implement platform text scaling. |
+| [CSS font shorthand](https://www.w3.org/TR/css-fonts-4/#font-prop) | `font` is a runtime shorthand over defined font properties and line height. | It does not encode every typographic property or the original role metadata. |
+
+Read on 2026-09-21. Apple content was inspected through the official documentation JSON. Material and Fluent references are dated product documentation. DTCG Format 2025.10 is a Community Group report; CSS Fonts Level 4 is a standards-track publication. Actual font availability and rendering require target evidence.
+
+### Comparing A Style With A Record
+
+`apple.text-style` and `dtcg.typography` have `partial_overlap` for exchanging typographic attributes. Some attributes can be represented in both. Apple's style is also connected to native text-size behavior, while an interchange record can describe styles outside Apple's system. An exporter must explain the scope of a match.
+
+`css.font` → `dtcg.typography` is an `implementation_representation` relation scoped to partial typography output. A consumer must emit additional properties such as letter spacing separately when needed and retain provenance outside the shorthand. This relation does not promise a reversible conversion.
+
+### Comparing Role Collections
+
+`material3.typography` and `fluent.type-ramp` have `partial_overlap` for named typography roles. Both help organize hierarchy, but the role inventories, defaults, and implementation surfaces differ. Matching two names containing “body” does not prove equivalent intended use or visual results.
+
+A collection of styles and one style are different abstraction levels. Before declaring `broader_than`, demonstrate proper set containment with comparable instances; a class that contains fields is not automatically a broader semantic concept than those fields.
+
+### Worked Handoff: Dense Review Surface
+
+A consumer wants more records visible while retaining readable annotations and controls. Separate the density decision from typography translation. Density might change spacing, optional detail, or command presentation; it need not mean scaling every font down.
+
+| Decision | Evidence to request | Translation failure |
+| --- | --- | --- |
+| Role mapping | Task purpose and named source roles | Similar labels map headings to ordinary labels. |
+| Value representation | Output properties and units | A composite style loses a required property. |
+| Scaling | Target user setting and the resulting style behavior | A static export ignores larger-text settings. |
+| Font fallback | Actual fonts and representative scripts | A role looks acceptable only with a locally installed font. |
+| Reading hierarchy | Long and localized content on the target surface | Compact labels obscure the main task. |
+
+This is a proposed consumer investigation, not evidence that a particular type scale improves reading speed. For product adaptation, use [Preferences And Accessibility](../platform-guides/preferences-and-accessibility.md); for editing behavior, use [Text Input And Internationalization](../design-engineering/text-input-and-internationalization.md).
+
+## Opinionated Guidance
+
+Preserve semantic roles even when two styles currently share values. Judge a translation by the declared task, retained attributes, and target scaling behavior. Treat a visual match at one size as a narrow observation.
+
+## Platform-Specific Guidance
+
+Points, CSS pixels, and scale-aware native units must be interpreted by the selected runtime. Native text-style names do not become CSS breakpoints or shared Layout tokens. Font fallback and script shaping require actual rendering; a vocabulary comparison cannot establish them.
+
+## Unsupported Absolutes
+
+A type ramp is not a universal accessibility standard. A typography token is not a complete native text-style behavior. CSS `font` is not a lossless export of all typography information. More visible rows do not prove higher task efficiency.
+
+## Verification Contract
+
+Record source roles, relation scope, output representation, scaling inputs, and any omitted information. Probe default and enlarged text, missing fonts, long labels, multiple scripts, and the actual target's line metrics. Keep file validation separate from visual and user-task evidence.
+
+These probes are unexecuted. Source meaning was reviewed; runtime rendering and reading performance were not measured. Re-review when role definitions, format versions, platform scaling, or adapter behavior changes.
+
+## Source, License, And Attribution
+
+Locally authored synthesis without imported type values or source examples. Terminology reliance: `apple.text-style`, `fluent.type-ramp`, `material3.typography`, `dtcg.typography`, and `css.font`; relation types: `partial_overlap` and `implementation_representation`. Named sources were rechecked 2026-09-21; this is author review, not independent semantic approval. `consumer_reference: not_applicable` because no consumer typography record is selected.
+
+## IA Navigation
+
+Parent: [Design Terminology](index.md).
+Next: [Token Semantics And Resolution](token-semantics.md).

package/game-ui/decision-tree.md

@@ -0,0 +1,81 @@
+---
+type: Domain Guide
+title: Game UI Decision Tree
+description: Select player-task recipes, ownership boundaries, and engine routes from the screen's purpose.
+domain: game-ui
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Game UI Decision Tree
+
+Primary role: game screen planning route.
+
+## Repository Boundary
+
+This route selects game-interface responsibilities independently of engine and art direction. The [Classification](classification.md) remains the local taxonomy; the [Screen Hierarchy](screen-hierarchy.md) defines ownership roles.
+
+## Reusable Method
+
+1. Write the player's question while the interface is visible.
+2. Choose one primary task class from the table below.
+3. Decide whether play continues and which input actions must be blocked.
+4. Assign lifetime, focus, sorting, and state ownership.
+5. Adapt a [Screen Recipe](screen-recipes.md), then run the [Verification Workflow](verification-workflow.md).
+
+## Player Task Route
+
+| Player question | Primary class | Recipe |
+| --- | --- | --- |
+| What is happening during play? | `hud` | [Play status and input](screen-recipes.md#play-status-and-input) |
+| How do I perform an action? | `input-surface` | [Play status and input](screen-recipes.md#play-status-and-input) |
+| Where can I go, pause, or leave? | `navigation` | [Pause and navigation](screen-recipes.md#pause-and-navigation) |
+| What decision requires attention? | `dialog` | [Blocking decisions and connection](screen-recipes.md#blocking-decisions-and-connection) |
+| Is the game ready or connected? | `system-status` | [Blocking decisions and connection](screen-recipes.md#blocking-decisions-and-connection) |
+| What can I equip or compare? | `inventory` | [Inventory and comparison](screen-recipes.md#inventory-and-comparison) |
+| What have I earned or unlocked? | `progression` | [Results and progression](screen-recipes.md#results-and-progression) |
+| What can I obtain, and at what cost? | `commerce` | [Offers and acquisition](screen-recipes.md#offers-and-acquisition) |
+| What should I learn next? | `tutorial` | [Teaching and narrative](screen-recipes.md#teaching-and-narrative) |
+| What story is being presented? | `narrative` | [Teaching and narrative](screen-recipes.md#teaching-and-narrative) |
+
+If a screen contains several tasks, classify regions independently. A purchase confirmation inside an inventory screen is a dialog owned by a commerce operation; it is not another inventory slot.
+
+## Ownership Decisions
+
+| Decision | Record before implementing |
+| --- | --- |
+| Lifetime | Application, session, scene, screen, entity, or one operation |
+| Play relationship | Continues, pauses locally, or requests a networked pause; identify authority |
+| Input | Active action map, focus owner, pointer/gamepad coexistence, cancellation |
+| Ordering | Screen, HUD, world-linked, modal, or transient host; name competing hosts |
+| Data | Authoritative state versus preview, selection, pending operation and stale data |
+| Exit | What is restored, destroyed, retained, or reconciled |
+
+## Worked Selection
+
+A loadout screen shows owned equipment, character attributes, and a purchase button for an unavailable slot. Inventory is primary; comparison is a supporting region. The purchase flow is commerce and any confirmation is a modal decision. Closing the modal returns to the same slot. Losing connection updates operation status without clearing the loadout selection. A server response after the screen closes belongs to the operation owner, not a destroyed view.
+
+## Opinionated Guidance
+
+Separate the player's task from visual genre. Assign one cancellation owner for each active layer so the same Back/Cancel input does not dismiss a dialog and its parent screen together.
+
+## Platform-Specific Guidance
+
+For Unity, select the [UI System](unity/ui-systems.md), map [Architecture](unity/architecture.md), then use the [CLI Loop](unity/cli-loop.md) for the declared stack. Other engines retain these role contracts but require their own verified API mapping; no cross-engine runtime equivalence is claimed.
+
+## Unsupported Absolutes
+
+A pause menu does not imply multiplayer simulation can pause. Hierarchy order does not prove input blocking, focus, or sorting. A taxonomy label does not establish rendered behavior.
+
+## Verification Contract
+
+Check one ordinary screen, one overlay composition, and one unexpected interruption such as disconnection or scene teardown. Every active layer needs a named lifetime, input, sorting, and exit owner. Revisit the route if a real player task cannot be classified without forcing unrelated responsibilities together.
+
+## Source, License, And Attribution
+
+Locally authored route and fictional loadout case. It imports no game assets, third-party hierarchy, or engine code.
+
+## IA Navigation
+
+Parent: [Game UI](index.md).
+Next: [Game UI Screen Recipes](screen-recipes.md).

package/game-ui/index.md

@@ -14,6 +14,16 @@ The player-task classes and classification axes are a local taxonomy proposed fo
 
 Interface In Game was reviewed on 2026-07-14 through its [home page](https://interfaceingame.com/), [games index](https://interfaceingame.com/games/), and representative records for [Team Fortress 2](https://interfaceingame.com/games/team-fortress-2/), [Genshin Impact (Mobile)](https://interfaceingame.com/games/genshin-impact-mobile/), and [Gris](https://interfaceingame.com/games/gris/). In this bounded sample, the site exposed site-local facets such as Genres, Themes, and Platforms, while screenshots used Elements. The sample informs the local separation of player task from other axes; it does not cover the archive or establish the site's full information model.
 
+## Start Here
+
+| Task | Route |
+| --- | --- |
+| Choose by player task and ownership. | [Game UI Decision Tree](decision-tree.md) |
+| Compose all ten player-task classes with failure cases. | [Game UI Screen Recipes](screen-recipes.md) |
+| Record input, state, hierarchy, and teardown evidence. | [Game UI Verification Workflow](verification-workflow.md) |
+
+These workflows and worked cases are usable experimental guidance. Expected-result tables are test designs; actual product, engine, and reader evidence must be recorded separately. Review on a failed task, a source change, or a changed ownership contract.
+
 ## Available Guides
 
 - [Game UI Classification](classification.md) separates player purpose from visual language, input, state, and motion.
@@ -32,4 +42,4 @@ Game UI describes interface purpose, screen composition, and how named engines c
 ## IA Navigation
 
 Parent: [StyleGallery](../index.md).
-Next: [Game UI Classification](classification.md).
+Next: [Game UI Decision Tree](decision-tree.md).

package/game-ui/screen-recipes.md

@@ -0,0 +1,101 @@
+---
+type: Domain Guide
+title: Game UI Screen Recipes
+description: Engine-neutral screen compositions with player task, lifetime, input, state, recovery, and acceptance cases.
+domain: game-ui
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Game UI Screen Recipes
+
+Primary role: game screen composition catalog.
+
+## Repository Boundary
+
+These are fictional compositions of [Screen Hierarchy](screen-hierarchy.md) roles. They prescribe no engine tree, artwork, or reusable Layout CSS. Use the [Decision Tree](decision-tree.md) to select by player task; record real references with the [Reference Record](reference-record.md).
+
+## Reusable Method
+
+For the selected recipe, name the persistent owner, screen or entity owner, active input recipient, exceptional states, and exit behavior. Each acceptance case below is an expected result awaiting consumer execution.
+
+## Play Status And Input
+
+Primary classes: `hud` and separately classified `input-surface` regions. A session-owned HUD presents player status, objectives, and contextual prompts. Entity-linked markers follow entity lifetime; virtual controls own their active press/drag state. HUD data observes gameplay authority rather than predicting confirmed rewards or inventory changes.
+
+Keep critical state understandable when an effect is absent. Distinguish zero value from unavailable data. Record how spectator, respawn, controller disconnection, and menus change visibility and input routing.
+
+Acceptance case: open a blocking menu while an action is held; release the action, close the menu, and confirm no stuck input remains. Destroy a marked entity and confirm its marker and subscriptions are removed.
+
+## Pause And Navigation
+
+Primary class: `navigation`. A screen host owns destinations; a pause overlay owns its focus scope and return target. The simulation/session owner decides whether play pauses. Audio, background input, and timers have explicit policies.
+
+Preserve navigation selection when opening settings and returning. Loading a new destination invalidates old screen callbacks. Cancel should consume one active layer at a time.
+
+Acceptance case: pause → settings → confirmation → cancel three times. Verify each step closes only the intended layer and restores the previous selection. For network play, verify the UI does not claim the world is paused when it continues.
+
+## Blocking Decisions And Connection
+
+Primary classes: `dialog` or `system-status`. A modal host owns blocking and focus; a connection service owns retry state. Keep message, available actions, retry state, and outcome distinct. Only block input that conflicts with the required decision.
+
+Reconnection success must reconcile the current screen, which may differ from the screen present at failure. A retry response from an earlier attempt cannot dismiss a newer failure. Define whether a system notice supersedes, queues behind, or composes with an existing modal.
+
+Acceptance case: lose connection during an inventory operation, open a system notice, then receive an old retry response. The current error/operation state remains authoritative and dismissal leaves no invisible blocker.
+
+## Inventory And Comparison
+
+Primary class: `inventory`. A screen owns filters, selection, and focus history. The data service owns item identity and confirmed equipment; a detail region owns the selected item's presentation. List/grid cells receive explicit data and selection state.
+
+Compare by stable item identity, not cell position. Separate selected, equipped, unavailable, pending, and failed states. Preserve selection where possible after filtering or sorting; document a fallback when the item disappears.
+
+Acceptance case: select item A, request equip, select B, then resolve A. A's result updates inventory truth while detail remains on B. Test empty inventory, maximum content, long localized attributes, and a disabled first item.
+
+## Results And Progression
+
+Primary class: `progression`. The completed-match/session record owns final values; presentation may stage reveal of those values. Reveal completion does not grant rewards. Skip reveals the confirmed final state once; replaying a presentation cannot duplicate a grant.
+
+Distinguish provisional, confirmed, and unavailable results. Preserve a readable result summary after a flourish. A disconnected client must not present an unconfirmed reward as owned.
+
+Acceptance case: skip twice, navigate away, and reopen results. The grant count stays unchanged, and the same authoritative result is shown. Test zero rewards and a reward list longer than the visible region.
+
+## Offers And Acquisition
+
+Primary class: `commerce`. The catalog owns offer identity, the purchase service owns transaction outcome, and the UI owns selection and acknowledgement. Show the item, total cost, currency, and eligibility before commitment. Pending, rejected, cancelled, expired, and fulfilled are different states.
+
+Do not derive success from a button effect or optimistic currency subtraction. Reconcile price/availability changes before accepting a commitment. Duplicate input must follow the transaction contract.
+
+Acceptance case: change availability between selection and submission, fail a request, and retry. The UI explains the current offer and never reports an unconfirmed acquisition. Actual payments and platform purchasing rules require consumer-specific verification.
+
+## Teaching And Narrative
+
+Primary classes: `tutorial` or `narrative`. A step/story controller owns progress; presentation owns text, highlight, voice/subtitle synchronization, and skip controls. Identify whether gameplay continues and whether a teaching step intentionally restricts input.
+
+A tutorial must explain a usable alternative when the expected device is absent. Narrative skip semantics distinguish advancing one line, finishing a scene, and suppressing future presentation. Progress must not depend only on a reveal animation finishing.
+
+Acceptance case: switch input mode midway through a tutorial, interrupt dialogue with a system modal, and return. Prompts match the current input, the story/step index remains correct, and required instructions can still be read.
+
+## Opinionated Guidance
+
+Keep screens thin enough that authoritative data survives their teardown when needed. Give each modal, transient effect, and world marker an explicit owner even when they share visual treatment.
+
+## Platform-Specific Guidance
+
+Map roles through the engine-specific guides. Safe areas, scaling, text shaping, controller focus, and accessibility capabilities require the actual engine, version, and target platform. A browser prototype is not evidence of console or engine behavior.
+
+## Unsupported Absolutes
+
+These recipes are not a universal game UX taxonomy, tested architecture, or proof of accessibility. A successful screenshot cannot prove operation integrity, input isolation, or teardown.
+
+## Verification Contract
+
+Run the chosen acceptance case with every declared input, target aspect ratios/safe areas, long localization, error/empty states, and interruptions. Record observed results in the [Verification Workflow](verification-workflow.md). `consumer_reference: not_applicable` applies here because these fictional compositions select no consumer record. Review when a runtime observation contradicts an ownership or recovery rule.
+
+## Source, License, And Attribution
+
+Locally authored fictional recipes with no copied game assets or implementation. Player classes and hierarchy roles come from this domain's local contracts.
+
+## IA Navigation
+
+Parent: [Game UI](index.md).
+Next: [Game UI Verification Workflow](verification-workflow.md).

package/game-ui/verification-workflow.md

@@ -0,0 +1,100 @@
+---
+type: Domain Guide
+title: Game UI Verification Workflow
+description: Convert a screen recipe into repeatable input, state, hierarchy, and teardown evidence.
+domain: game-ui
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Game UI Verification Workflow
+
+Primary role: game-interface acceptance and evidence procedure.
+
+## Repository Boundary
+
+This workflow verifies a declared game-interface contract on a named runtime. It does not authenticate third-party captures or convert a hypothetical recipe into a real gallery reference. Shared [Quality Gates](../quality/index.md) determine what a claim's evidence can support.
+
+## Reusable Method
+
+1. Select a [Screen Recipe](screen-recipes.md), build/version, scene, starting data, and supported inputs.
+2. Record the active hierarchy's lifetime, input, sorting, focus, and teardown owners.
+3. Reset to known state before each scenario. Name any non-resettable external dependency.
+4. Execute actions in order, including an exception or interruption.
+5. Compare expected and actual state, selection, input recipient, and surviving objects.
+6. Save artifacts with source/build identity; classify pass, fail, not-run, or not-applicable with a reason.
+
+## Minimum Scenario Matrix
+
+| Dimension | Scenario | Inspect |
+| --- | --- | --- |
+| Entry | Open by each supported input | Correct screen and initial focus/selection |
+| Navigation | Visit first, middle, last, and unavailable actions | Predictable order, visible target, no unreachable required action |
+| Modality | Open overlay above a screen, then another interruption | Exactly the intended input recipient; world input policy |
+| Cancellation | Back/Cancel during entry, request, and exit | One-layer dismissal; no click-through or stale blocker |
+| Content | Empty, long localized text, unbroken identifiers, many rows | Readable critical information and reachable actions |
+| Surface | Target aspect ratios, safe areas, scaled UI, constrained window | No obscured controls or accidental scroll ownership |
+| Data | Delay, fail, supersede, and complete requests out of order | Current identities and truthful operation status |
+| Device | Switch/disconnect a claimed input device | Updated prompts and a viable recovery action |
+| Lifetime | Reopen repeatedly and change scene/session | No duplicate handlers, surviving blockers, or stale view updates |
+
+This is a selection matrix. A title that supports no touch input records touch as not applicable; it does not claim a touch pass.
+
+## Worked Scenario: Inventory With Confirmation
+
+Precondition: local fictional test data has two items, A and B. The inventory is open with A selected; no real commerce operation is involved.
+
+| Step | Action | Expected observation |
+| --- | --- | --- |
+| 1 | Navigate to B and open its action dialog | B remains selected beneath the dialog; focus enters the dialog |
+| 2 | Press Cancel once | Only the dialog closes; focus/selection returns to B |
+| 3 | Reopen and trigger a delayed operation | Dialog exposes pending state and the declared duplicate-input behavior |
+| 4 | Close/change the screen, then resolve the operation | Data owner reconciles the result; destroyed views do not update |
+| 5 | Reopen inventory | Confirmed data appears; selection follows the documented restore policy |
+
+Actual result: `not_run`. This procedure is a test design, not engine execution evidence.
+
+A separate [web inventory adaptation](../examples/domain-interactions/README.md) exercises nested dismissal, delayed equipment responses after view closure, selection restoration, and reward reveal. Its [local browser results](../examples/domain-interactions/verification.md) are browser evidence only. The native-engine scenario above remains `not_run`.
+
+## Evidence Record Template
+
+```yaml
+scenario: inventory-dialog-return
+build_revision: # immutable source/build identity
+runtime: # engine, UI stack, packages, OS, device
+surface: # resolution, aspect ratio, safe area, UI scale, locale
+input: # exercised mode and device
+precondition: # scene, data, selection, connectivity
+actions: # ordered, reproducible steps
+expected: # visible state plus hierarchy/input assertions
+actual: not_run
+artifacts: # capture, recording, hierarchy trace, operation log
+limitations: # missing channels, device scope, mocked dependencies
+consumer_reference: not_applicable
+consumer_reference_reason: This blank procedure selects no consumer-owned reference record.
+```
+
+## Opinionated Guidance
+
+Capture hierarchy and input evidence together when a screenshot could hide the failure. A visually dismissed overlay with an active blocker is a failed dismissal, regardless of its appearance.
+
+## Platform-Specific Guidance
+
+For Unity use the source-pinned [CLI Loop](unity/cli-loop.md) and its UI-stack-specific capabilities. If a runner cannot inspect focus or controller routing, mark those checks not-run and collect them on the real engine surface.
+
+## Unsupported Absolutes
+
+A successful editor inspection does not prove player-build behavior. Mocked operation responses do not prove a live service works. Device and accessibility coverage must be named explicitly.
+
+## Verification Contract
+
+A completed record binds actions and actual outcomes to a build and runtime, includes exceptional-state evidence, and lists missing coverage. Failed required cases need remediation and rerun. A real gallery entry must also satisfy the [Reference Record](reference-record.md). Review when input routing, engine version, hierarchy ownership, or the recipe changes.
+
+## Source, License, And Attribution
+
+Locally authored test procedure and fictional inventory scenario. No real game reference, asset license, or runtime result is implied.
+
+## IA Navigation
+
+Parent: [Game UI](index.md).
+Next: [Game UI Reference Record](reference-record.md).

package/index.md

@@ -35,3 +35,11 @@ Primary role: OKF bundle map.
 - [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.
+
+## Applied Workflows
+
+- [Motion Decision Tree](motion/decision-tree.md) - Choose a behavior from the user task.
+- [Design Engineering Decision Tree](design-engineering/decision-tree.md) - Route the uncertain product decision.
+- [Game UI Decision Tree](game-ui/decision-tree.md) - Choose by player task and ownership.
+- [Platform Adaptation Workflow](platform-guides/adaptation-workflow.md) - Record native facts, target decisions, and fallbacks.
+- [Design Term Comparison Workflow](design-terminology/comparison-workflow.md) - Resolve a source-specific question and produce a scoped handoff.

package/log.md

@@ -1,5 +1,72 @@
 # StyleGallery Log
 
+## 2026-09-22
+
+- Prepared `stylegallery@0.1.7` with direct website capture, transcription, and workflow commands in the SG CLI and MCP. The compiler remains a separately installed checkout; frozen v1 knowledge entrypoints remain available.
+- Routed faithful reconstruction, adaptation, and sale-package work through the compiler's task-aware workflow. Reconstruction prioritizes usable original media, additional observation, explicit replacement decisions, and visual QA. The automatic sale-edition builder is labeled as a package preview.
+- Added compiler transport, cancellation, packaged-install, and local real-capture checks. These verify the integration; they do not establish an improvement in clone quality.
+
+Implementation handoff: `consumer_reference: consumer-reference/agent-native/registry.json`.
+
+Consumer reference: declared
+Consumer reference record: consumer-reference/agent-native/registry.json
+
+## 2026-09-21
+
+Understood as: substantially enrich Motion, Design Engineering, Platform Guides, and Design Terminology with primary-source research integrated into governed local documents. The user excluded Layout and Game UI from this work.
+
+- Added twelve local research guides: motion accessibility/interruption/rendering; native interaction contracts, multilingual input, and asynchronous feedback; platform adaptation/preferences/input; and token, interaction, and typography semantics. Each separates source-backed findings, local proposals, failure cases, and unexecuted verification scenarios.
+- Inspected 66 cited official source pages on 2026-09-21. Recorded source status and target-version limits; read Apple page bodies through official documentation JSON when the HTML reader exposed a JavaScript shell. Preserved prior source-review dates for unrelated term records.
+- Added fourteen source-qualified terms and nine scoped relations, bringing the terminology tables to twenty-five terms and seventeen relations. These are author-reviewed experimental judgments, not independent semantic approval.
+- Registered the twelve leaves in domain membership, local navigation, the closed Material v2 admission set, and npm packaging. The admitted corpus has 181 documents. New guidance remains experimental and does not add profile values, native implementations, or a domain.
+- Verified Markdown structure, links, IA, governance, domain membership, terminology, consumer handoffs, and material admission in an isolated checkout of the research changes. Domain/terminology/governance, consumer/evidence, and frozen-v1 regression suites passed; package installation and CLI/MCP retrieval passed. Fixed the package inventory test's omission of the three existing license/notice files while preserving its exact allow-list assertion.
+- Checked every cited URL and fragment. Applied two fresh-reader corrections to the term-comparison method and contributor verification route. Eight author-selected search probes retrieved the intended guide within the first two results; these are retrieval smoke checks, not an independent usability evaluation. No browser, native IME, assistive-technology, or product performance execution is claimed.
+
+Implementation handoff: `consumer_reference: consumer-reference/agent-native/registry.json`.
+
+Consumer reference: declared
+Consumer reference record: consumer-reference/agent-native/registry.json
+
+Terminology reliance: `dtcg.alias`, `fluent.alias-token`, `fluent.global-token`, `carbon.color-token`, `dtcg.resolver-modifier`, `html.popover`, `apple.popover`, `html.dialog`, `aria.dialog`, `apple.text-style`, `fluent.type-ramp`, `material3.typography`, `dtcg.typography`, `css.font`, `dtcg.token`, `dtcg.group`, and `css.custom-property`. Relation types used: `partial_overlap`, `implementation_representation`, and `not_comparable`. Named sources for these terms were rechecked on 2026-09-21; the older Figma, historical-format, component/pattern, and Layout relations retain their original review scope. Direct locators and boundaries are in [Term Cases](design-terminology/conflict-cases.md).
+
+## 2026-09-09
+
+- Added a full-page fixed-viewport scene-navigation example with chapter hashes/history, wheel-burst gating, keyboard and art-surface swipe navigation, native copy overflow, immediate reduced-motion transitions, and a complete reading escape.
+- Extended Motion, Design Engineering, Platform Guides, and the Homepage composition route for this distinct navigation model. Kept visual values and controllers in the example layer.
+- Preserved one device shell across Flow's scroll-controlled scenes and linked the new page through the Scroll Story Lab. Historical verification remains bound to its original source; follow-up checks have separate records.
+- Prepared npm 0.1.6 with the cumulative governed-document updates. Runnable examples remain repository-only and are not added to the material admission or npm file inventory.
+
+- Added scroll-story contracts to Motion, a product media handoff to Design Engineering, and browser target cases to Platform Guides. Linked the existing Homepage recipe without adding a new Layout pattern or changing domain lifecycle.
+- Replaced the Flow transfer scene with three reversible scroll-controlled chapters and added a second product example, native CSS scrubbing, bounded image decoding, static reading, and deterministic/runtime checks in the Scroll Story Lab.
+
+- Added an independent Toss-inspired homepage study that composes the existing Homepage recipe and Layout patterns inside a standalone product layer.
+- Added original generated hero and travel imagery, responsive navigation, keyboard-operated asset tabs, section progress, reduced-motion behavior, and explicit horizontal service-rail ownership.
+- Recorded real Chrome verification at desktop, tablet, and mobile viewport sizes with retained desktop and mobile screenshots. No reusable Layout CSS or consumer-reference profile values were changed.
+
+Implementation handoff: `consumer_reference: not_applicable`.
+
+Consumer reference: not_applicable
+Consumer reference reason: This standalone visual study selects no consumer-reference profile or record.
+
+## 2026-09-08
+
+- Prepared npm release `stylegallery@0.1.5` with the complete six-domain, 147-document Material v2 corpus and the README compatibility repair.
+- Added fourteen local guides across the five non-Layout domains: task selection, motion briefs and recipes, component contracts and worked examples, game screen recipes and verification, Apple/Android/Windows adaptation, and terminology comparison.
+- Connected the guides through domain hubs and root routes, declared their membership/provenance, and included them in the closed 147-document material index and npm package. Layout retains its existing 46 patterns and spatial boundaries.
+- Replaced unsupported aggregate term records with directly sourced records; corrected representation direction and the confusion between composition and set containment. The Markdown validator now checks dates, source locators, labels, scoped direction, temporal relations, inverse consistency, and containment cycles with negative fixtures.
+- Examples remain expected behavior rather than claimed runtime evidence. Domain leaves remain `experimental`; no lifecycle promotion or consumer adoption is claimed.
+
+- Follow-up runtime work added the [Interaction Lab](examples/domain-interactions/README.md), a standalone web adaptation with explicit mock responses. Its [verification notes](examples/domain-interactions/verification.md) bind actual browser observations to local source hashes and separate desktop execution from simulated viewport sizes, untested mobile devices, and untested native engines. Fixed the lab's modal Tab boundary after observing focus escape in the real browser.
+- Fixed the v1 compatibility suite's stale README digest. Commit `d8bdf0bd5b5aec2fbc38e322a9ac7a1d31fd1332` had added material-v2 guidance and corrected the domain count without updating the test. The exact reviewed documentation digest is now checked separately; all 21 original core/source pins and six CLI output goldens remain unchanged. `npm run test:agent-native` passes.
+- Integrated the current domain lifecycle policy from `main`: reader tasks and adoption counts do not authorize or block domain promotion. Refreshed active workflow/document seals and source-generated protocol inventories for the added validation and documentation; preserved job bytes, lifecycle decisions, external caller status, deadlines, and immutable archive bindings.
+
+Implementation handoff: `consumer_reference: consumer-reference/agent-native/registry.json`.
+
+Consumer reference: declared
+Consumer reference record: consumer-reference/agent-native/registry.json
+
+Terminology reliance: `figma.variable`, `figma.mode`, `figma.collection`, `figma.component`, `dtcg.token`, `dtcg.group`, `dtcg.token.draft2`, `css.custom-property`, `carbon.component`, `carbon.pattern`, and `stylegallery.pattern`. Relation types used in the records: `partial_overlap`, `implementation_representation`, `not_comparable`, `same_label_different_meaning`, and `near_equivalent`. Their named Figma, DTCG, CSSWG, Carbon, and local Layout sources were rechecked on 2026-09-08; this is an author review, not independent semantic approval. Direct locators and comparison boundaries are in [Term Cases](design-terminology/conflict-cases.md).
+
 ## 2026-08-18
 
 - Added Design Terminology as the sixth governed domain: source-kind and concept-family classification separated as distinct axes, a typed term relation model, freshness-bounded source vocabularies, and cross-system conflict cases with three representative scenarios.