stylegallery 0.1.4 → 0.1.6

package/design-terminology/index.md

@@ -18,22 +18,22 @@ Representative questions this domain answers: are Figma's variable, the DTCG des
 
 ## Promotion To Stable
 
-Promotion beyond `experimental` requires all of the following, each pass/fail checkable:
+Domain lifecycle decisions follow the [repository-owner policy](../DOMAINS.md#lifecycle-and-staleness). The following source, ownership, and machine-contract checks inform a proposed transition beyond `experimental`:
 
 - A named review owner, secondary reviewer, freshness owner, and dispute resolver are recorded.
 - A machine-readable registry with schema exists for terms, concepts, sources, and relations; until then `scripts/validate-design-terminology.mjs` enforces record consistency on the Markdown tables.
 - A relation invariant validator derived from the forbidden error states in [Design Term Relations](relation-types.md) passes.
 - Every term carries a direct source locator.
 - Every relation names both sources and a non-trivial boundary.
-- At least three representative user tasks are verified: judging same-label different-meaning, judging a cross-system relation, and separating a historical term from a current one.
 - Representative findability queries return a target document or record.
 - Unresolved semantic disputes: zero.
 - Stale sources beyond their re-review trigger: zero.
-- Usage evidence from at least one real human or agent consumer exists.
+
+Reader tasks, user studies, adoption counts, and attestations are neither required nor sufficient for a domain lifecycle change. Reader-task observations may support a separately scoped findability claim.
 
 ## Content Review Contract
 
-Record consistency is enforced mechanically from v0.1 by `scripts/validate-design-terminology.mjs`, which parses the term and relation tables and rejects unknown types, unrecorded terms, empty boundaries, contradiction pairs, malformed dates, and orphan terms. Human semantic review is a **stable-promotion gate only**, not a merge gate for `experimental` content; it covers every term and relation (not a sample) against this checklist:
+Record consistency is enforced mechanically from v0.1 by `scripts/validate-design-terminology.mjs`, which parses the term and relation tables and rejects unknown types, duplicate or unrecorded terms, missing source locators, empty boundaries/scopes, conflicting directions, containment cycles, impossible calendar dates, invalid temporal relations, label mismatches, and orphan terms. Source meaning and authority remain review judgments. Human semantic review is a **stable-promotion gate only**, not a merge gate for `experimental` content; it covers every term and relation (not a sample) against this checklist:
 
 - Is the source kind correct for each cited source?
 - Does each term description match what its source actually supports?
@@ -47,6 +47,14 @@ The review result is recorded as: terms reviewed, relations reviewed, counts of
 
 This domain is a working method template: consumers may fork it and re-record their own sources, terms, and relations. Forked records are consumer-owned and never feed values back into StyleGallery.
 
+## Start Here
+
+| Task | Route |
+| --- | --- |
+| Resolve a source-specific question and produce a scoped handoff. | [Design Term Comparison Workflow](comparison-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
 
 - [Design Source Kinds](source-kinds.md) classifies what kind of thing a vocabulary source is before its terms are read.
@@ -62,4 +70,4 @@ This domain is a working method template: consumers may fork it and re-record th
 ## IA Navigation
 
 Parent: [StyleGallery](../index.md).
-Next: [Design Source Kinds](source-kinds.md).
+Next: [Design Term Comparison Workflow](comparison-workflow.md).

package/design-terminology/relation-types.md

@@ -47,7 +47,9 @@ A relation record is invalid when any of the following holds:
 - Either term lacks an official, named source.
 - The boundary field is empty or restates the type without adding scope.
 
-These rules are the human contract for v0.1; when the structured registry lands, they become validator rules unchanged.
+The Markdown validator enforces unique source-qualified term IDs, direct source locators, actual calendar dates, explicit scope and direction, identical labels for `same_label_different_meaning`, temporal status/event requirements, inverse consistency, and acyclic containment within each scope. It ignores fenced examples and HTML comments. Locators must be HTTPS or existing repository documents; the validator does not authenticate source ownership or evaluate semantic truth.
+
+The term table has seven columns: identifier, label, source/kind with direct locator, concept, status, scope, and reviewed date. The relation table has seven: from, to, type, scope, direction, boundary, and reviewed date. Scope is a non-empty kebab-case comparison identifier. One directed pair has one relation per scope; a separately recorded inverse must agree. Symmetric types use `symmetric`; representation, containment, and temporal relations use `directional`; `near_equivalent` declares either explicitly. Self-relations are invalid. Boundaries must contain a substantive sentence; a length check can reject blanks but cannot establish semantic adequacy.
 
 ## Term Record Shape
 
@@ -55,18 +57,22 @@ These rules are the human contract for v0.1; when the structured registry lands,
 term_id: figma.variable
 label: Variable
 source: figma            # named source from source-vocabularies
+source_url: https://help.figma.com/hc/en-us/articles/14506821864087-Overview-of-variables-collections-and-modes
 source_kind: design-tool # from source-kinds
 concept: named-design-value
 status: current          # current | deprecated | historical | unknown
 scope: file-or-collection-bound
-reviewed_on: 2026-08-18
+reviewed_on: 2026-09-08
 relations:
   - target: dtcg.token
     type: partial_overlap
+    scope: value-interchange
+    direction: symmetric
+    reviewed_on: 2026-09-08
     boundary: >
-      Some tool variables export as interchange tokens, but tool features
-      such as modes exceed the format, and not every variable is a
-      portable design token.
+      Exportable design values overlap; prototype values need not be
+      tokens, and one scalar variable does not provide every composite
+      structure in the 2025.10 format.
 ```
 
 In v0.1 this shape is authored as the Markdown tables in [Cross-System Term Cases](conflict-cases.md). A machine-readable registry holding terms, concepts, sources, and relations is a prerequisite for promoting this domain beyond `experimental`; until then Material v2 answers document search only, not structured crosswalk queries.
@@ -95,7 +101,7 @@ Every recorded relation names two term records, one type from the closed set, a
 
 ## Source, License, And Attribution
 
-This page is a locally authored model. Cited sources remain authoritative for their own definitions; no upstream prose is reproduced.
+This page is a locally authored model. The illustrative `figma.variable` and `dtcg.token` relation uses `partial_overlap`; its named sources were rechecked on 2026-09-08 as recorded in [Term Cases](conflict-cases.md). No upstream prose is reproduced.
 
 ## IA Navigation
 

package/design-terminology/source-vocabularies.md

@@ -31,10 +31,24 @@ This page inventories the named sources whose terms this domain records, with th
 | [Fluent 2](https://fluent2.microsoft.design/) | Microsoft | `design-system` | `foundations`, `components`, `patterns`, tokens | Living site; reviewed page set | current | 2026-08-18 |
 | [Carbon](https://carbondesignsystem.com/) | IBM | `design-system` | `foundations` including tokens, `components`, `patterns` | Living site; reviewed page set | current | 2026-08-18 |
 | [Polaris](https://polaris.shopify.com/) | Shopify | `design-system` | `foundations` including design tokens, `components`, `patterns`, `icons` | Living site; package versions for code | current | 2026-08-18 |
-| [Design Tokens Format](https://tr.designtokens.org/) | W3C Design Tokens Community Group | `specification` | `token`, `group`, `alias` data model | Specification draft version | current | 2026-08-18 |
+| [Design Tokens Format](https://www.w3.org/community/reports/design-tokens/CG-FINAL-format-20251028/) | Design Tokens Community Group | `specification` | `token`, `group`, `alias` data model | Format Module 2025.10; Community Group report, not a W3C Recommendation | current | 2026-09-08 |
 | [Figma](https://help.figma.com/hc/en-us) | Figma | `design-tool` | `variables`, `modes`, `components` as tool constructs | Product and help-center version | current | 2026-08-18 |
 
-All entries cite official first-party URLs (`authority: official`); `retrieved_on` equals `reviewed_on` for this revision.
+All entries cite official first-party URLs (`authority: official`); `retrieved_on` equals the corresponding `reviewed_on`. Entries retaining 2026-08-18 are prior bounded readings, not rechecked claims for the current session.
+
+## Direct Sources For Current Term Records
+
+The [Term Cases](conflict-cases.md) use this narrower source set, rechecked 2026-09-08. Locators in the term table point to the exact document or section, not a general vendor home page.
+
+| Named source | Source kind | Reviewed surface and version | Re-review trigger |
+| --- | --- | --- | --- |
+| Figma | `design-tool` | [Variables, collections, modes](https://help.figma.com/hc/en-us/articles/14506821864087-Overview-of-variables-collections-and-modes) and [components](https://help.figma.com/hc/en-us/articles/360038662654-Guide-to-components-in-Figma); dated help pages | Tool data model or cited help meaning changes |
+| DTCG | `specification` | [2025.10 Format](https://www.w3.org/community/reports/design-tokens/CG-FINAL-format-20251028/) and [Second Editors' Draft, 2022-06-14](https://www.designtokens.org/tr/second-editors-draft/format/) | A comparison changes version; retain the historical scope |
+| CSSWG | `web-platform` | [CSS Custom Properties Level 1](https://www.w3.org/TR/css-variables-1/#defining-variables) | The cited runtime-value definition changes |
+| Carbon | `design-system` | [What is Carbon](https://carbondesignsystem.com/all-about-carbon/what-is-carbon/) and [patterns overview](https://carbondesignsystem.com/patterns/overview/) | Component or pattern scope changes |
+| StyleGallery | `pattern-library` | Local [Layout hub](../layout/index.md) and its repository contract | Layout ownership or pattern contract changes |
+
+The DTCG 2022 reading is historical evidence of a draft, not an implementation recommendation. A direct locator and a recorded reading establish provenance for the local summary; independent semantic approval remains separate.
 
 ## Freshness Policy
 
@@ -42,7 +56,7 @@ Every recorded source carries: `source_url`, `source_kind`, a version boundary (
 
 ## Reading The Inventory
 
-- Four of the seven sources are design systems; HIG is a platform guideline, DTCG is a specification, Figma is a tool. Horizontal comparison is valid only within a kind, or through typed relations with boundaries.
+- Four of the seven broad browse sources are design systems; HIG is a platform guideline, DTCG is a specification, Figma is a tool. Horizontal comparison is valid only within a kind, or through typed relations with boundaries.
 - `foundations` labels are near-equivalent as layer names, but each system decides what the layer contains.
 - The DTCG row records an interchange format, not a published token set.
 - Dates above are the reading bound; any later restructure is new evidence, not a back-fill.

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,43 @@
 # StyleGallery Log
 
+## 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.

package/motion/decision-tree.md

@@ -0,0 +1,70 @@
+---
+type: Domain Guide
+title: Motion Decision Tree
+description: Choose a motion responsibility from a user task, state change, and failure case.
+domain: motion
+lifecycle: experimental
+provenance_kind: local
+---
+
+# Motion Decision Tree
+
+Primary role: motion selection workflow.
+
+## Repository Boundary
+
+Use this route to decide whether a product interaction needs motion and which behavior contract to write. Layout continues to own final geometry, semantic order, and scrolling. This route selects a responsibility, not a timing preset.
+
+## Reusable Method
+
+1. Write the before and after state without animation. If either is unusable, fix that state first.
+2. Name the information motion would add: acknowledgement, continuity, progress, or guidance. If none is needed, use an immediate update.
+3. Choose the first matching responsibility below; compose only when one transition has multiple explicit jobs.
+4. Complete the [Motion Brief](motion-brief.md), including interruption and a reduced-motion path.
+5. Use an [Interaction Recipe](interaction-recipes.md) and verify through the [Review Workflow](review-workflow.md).
+
+## Selection Table
+
+| Observed task | Choose | Failure to prevent | First verification |
+| --- | --- | --- | --- |
+| Explain an already rendered effect | [Vocabulary](vocabulary.md) | Inferring an API from appearance | Exact, ambiguous, and unknown observations |
+| Acknowledge a command | [Action feedback](interaction-recipes.md#action-feedback) | Decorative feedback mistaken for successful completion | Pending, success, failure, repeated activation |
+| Show or hide supporting content | [Disclosure](interaction-recipes.md#disclosure) | Hidden content retaining focus or delayed access to content | Keyboard activation and reversal |
+| Enter or dismiss a modal task | [Modal transition](interaction-recipes.md#modal-transition) | Focus or input blocking tied to an animation timer | Focus entry, cancellation, return |
+| Preserve identity when items move | [Reorder and filter](interaction-recipes.md#reorder-and-filter) | Visual movement changing logical reading order | Stable identity and focused-item removal |
+| Explain an operation that takes time | [Progress and completion](interaction-recipes.md#progress-and-completion) | An invented percentage or success before confirmation | Delayed result, cancellation, failure |
+| Follow direct manipulation | [Drag and settle](interaction-recipes.md#drag-and-settle) | A cancelled gesture committing data | Release, reversal, cancellation, alternative input |
+| Explore a product through scroll-controlled chapters | [Scroll-driven story](interaction-recipes.md#scroll-driven-story) | Entry callbacks mistaken for continuous progress; inaccessible pinned content | Reverse, jump, middle reload, static reading |
+| Navigate a whole page as fixed-viewport scenes | [Full-viewport scene navigation](interaction-recipes.md#full-viewport-scene-navigation) | Gesture bursts skipping chapters; trapped input or lost history | Burst, boundary, direct link, Back, Escape, native copy scroll |
+| Decorate an idle surface | [Practice Reference](practice-reference.md) | Repetition competing with the user's task | Compare against removal and reduced motion |
+
+## Worked Selection
+
+A search result list changes after a filter selection. The task is to understand which results remain; it is not to watch every row arrive. Choose reorder/filter only if stable result identities can be preserved. Keep the filter control focused. Announce the resulting count separately from any visual interpolation. When no results remain, present an actionable empty state immediately. If identity cannot be mapped reliably, replace the list without implying continuity.
+
+The decision record is a proposal until tested on the consuming product. It does not establish that motion improves search comprehension.
+
+## Opinionated Guidance
+
+Prefer one explanatory event over a sequence of unrelated effects. Evaluate high-frequency interactions with realistic repetition; a first-use recording can hide accumulated cost.
+
+## Platform-Specific Guidance
+
+Choose implementation APIs only after the behavior contract. Native gestures, browser navigation, scroll timelines, and animation libraries have different cancellation and lifetime behavior. Platform adaptation starts at [Platform Guides](../platform-guides/index.md).
+
+## Unsupported Absolutes
+
+An immediate update is a valid outcome. A recipe name does not imply a spring, compositor execution, fixed duration, or proven usability improvement.
+
+## Verification Contract
+
+For the selected row, verify normal completion, interruption, repeated input, the reduced-motion path, and a failed or empty result where relevant. Record the actual outcome separately from the expected outcome. Revisit this route when a task cannot find a suitable contract or two recipes imply conflicting ownership.
+
+## Source, License, And Attribution
+
+Locally authored selection workflow based on this domain's existing vocabulary and review contracts. No external code or expressive examples are adapted.
+
+## IA Navigation
+
+Parent: [Motion](index.md).
+Next: [Motion Brief](motion-brief.md).

package/motion/index.md

@@ -8,6 +8,18 @@ In scope: naming observable motion, reviewing declared behavior, distinguishing
 
 Out of scope: universal timing or easing rules, unmeasured performance claims, and permission to add animation or decorative properties to reusable Layout pattern CSS.
 
+## Start Here
+
+| Task | Route |
+| --- | --- |
+| Choose a behavior from the user task. | [Motion Decision Tree](decision-tree.md) |
+| Record states, owners, interruption, and evidence. | [Motion Brief](motion-brief.md) |
+| Build a scroll-driven product story and inspect runnable examples. | [Scroll-driven Story](interaction-recipes.md#scroll-driven-story) and [Scroll Story Lab](../examples/scroll-story/README.md) |
+| Keep the page fixed while navigating between full-screen chapters. | [Full-viewport Scene Navigation](interaction-recipes.md#full-viewport-scene-navigation) and [runnable example](../examples/scene-navigation/README.md) |
+| Apply feedback, disclosure, modal, reorder, progress, and drag contracts. | [Motion Interaction Recipes](interaction-recipes.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.
+
 ## Documents
 
 - [Motion Vocabulary](vocabulary.md) maps observed behavior to implementation-neutral terms while preserving ambiguity.
@@ -16,9 +28,9 @@ Out of scope: universal timing or easing rules, unmeasured performance claims, a
 
 ## Domain Contract
 
-See [StyleGallery Domains](../DOMAINS.md) for lifecycle, provenance, page membership, and promotion rules.
+See [StyleGallery Domains](../DOMAINS.md) for lifecycle, provenance, page membership, and staleness rules.
 
 ## IA Navigation
 
 Parent: [StyleGallery](../index.md).
-Next: [Motion Vocabulary](vocabulary.md).
+Next: [Motion Decision Tree](decision-tree.md).