stylegallery 0.1.7 → 0.1.9

package/game-ui/classification.md

@@ -1,82 +0,0 @@
----
-type: Domain Guide
-title: Game UI Classification
-description: Engine-neutral method for classifying game interfaces by player task, presentation, input, state, and motion.
-domain: game-ui
-lifecycle: experimental
----
-
-# Game UI Classification
-
-Primary role: game-interface classification guide.
-
-## Repository Boundary
-
-This guide proposes a local, project-neutral taxonomy for classifying observable game-interface behavior without assuming a specific engine or art direction. Its player-task classes and classification axes are review tools, not a universal ontology. It does not turn a visual genre into a functional category or authorize decorative properties in reusable Layout patterns.
-
-## Reusable Method
-
-1. Capture the rendered screen or interaction in context.
-2. Assign one primary player-task class.
-3. Add secondary classes only when the same surface genuinely composes responsibilities.
-4. Record visual language, input, state, motion, and implementation as separate axes.
-5. Attach evidence for default, exceptional, and transitional states.
-6. State what is observed, inferred, and still unverified.
-
-## Player-Task Classes
-
-| Primary class | Player question | Typical examples |
-| --- | --- | --- |
-| `hud` | What is happening during play right now? | Health, ammo, objective, marker, cooldown |
-| `navigation` | Where can I go next? | Main menu, pause menu, chapter or mode selection |
-| `dialog` | What decision or interruption needs attention? | Confirmation, reconnect, privacy, system notice |
-| `inventory` | What do I own, equip, compare, or improve? | Loadout, stash, equipment, crafting, upgrade |
-| `progression` | What did I unlock or how am I advancing? | Results, level up, rewards, rank change |
-| `commerce` | What can I acquire and at what cost? | Shop, offer, product detail, currency shortage |
-| `tutorial` | What action should I learn or perform? | Coach mark, forced step, contextual hint |
-| `narrative` | What story or authored event is being presented? | Dialogue, boss intro, cinematic overlay |
-| `system-status` | Is the application ready and connected? | Splash, loading, sign-in, reconnect, patch status |
-| `input-surface` | How do I directly control the game? | Virtual stick, action button, key binding |
-
-## Classification Axes
-
-| Axis | Example values | Evidence requirement |
-| --- | --- | --- |
-| World relationship | `diegetic`, `spatial`, `overlay`, `full-screen` | Capture placement relative to play space |
-| Material character | `flat-graphic`, `framed`, `skeuomorphic`, `translucent`, `textural` | Capture repeated surface treatment |
-| Genre signal | `tactical`, `industrial`, `fantasy-ornamental`, `arcade`, `horror`, `casual` | Show repeated shape, type, icon, and material cues |
-| Information density | `sparse`, `standard`, `dense` | Count simultaneous choices and information groups |
-| Emphasis model | `typographic`, `icon-led`, `character-led`, `item-led`, `effect-led` | Identify first and second attention targets |
-| Input | pointer, keyboard, gamepad, touch, gaze, mixed | Exercise every declared input mode |
-| Motion role | affordance, activation, state change, transition, value change, reward, guidance, ambient | Record trigger, properties, timing, and interruption |
-
-## Opinionated Guidance
-
-- Organize the gallery first by player task, then filter by presentation and implementation axes.
-- Use two or three visual tags supported by repeated evidence.
-- Classify independent player-task regions separately when a screen composes them.
-- Do not infer style or behavior from project, prefab, widget, scene, or class names alone.
-
-## Platform-Specific Guidance
-
-Record engine, UI framework, render space, scaling policy, navigation system, text system, and motion system as implementation evidence. Route detailed engine hierarchy and API guidance to the matching engine-specific Game UI guide.
-
-## Unsupported Absolutes
-
-- A genre label does not establish a visual style.
-- A screenshot does not prove responsive behavior, focus behavior, or motion interruption.
-- A production project's folder structure is not a universal architecture.
-- Similar appearance does not prove equivalent accessibility, performance, or interaction behavior.
-
-## Verification Contract
-
-Verify narrow and wide surfaces, every declared input mode, long localized text, empty and loading states, disabled and error states, repeated open and close, rapid selection changes, and interrupted motion where relevant.
-
-## Source, License, And Attribution
-
-This page is a locally authored, project-neutral proposed taxonomy. It reproduces no game assets, project-specific hierarchy, or upstream implementation samples.
-
-## IA Navigation
-
-Parent: [Game UI](index.md).
-Next: [Game UI Screen Hierarchy](screen-hierarchy.md).

package/game-ui/decision-tree.md

@@ -1,81 +0,0 @@
----
-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

@@ -1,45 +0,0 @@
-# Game UI
-
-Game UI owns engine-neutral guidance for game-interface purpose, presentation, screen hierarchy, and evidence records, plus named engine implementation guides.
-
-## Scope Boundary
-
-In scope: player-task classification, screen and overlay hierarchy, reusable reference metadata, state coverage, cross-engine comparison vocabulary, and engine-specific implementation guidance.
-
-Out of scope: reusable Layout CSS, universal visual prescriptions, and treating one engine's scene graph or API as a cross-engine requirement.
-
-## Evidence And Research Boundary
-
-The player-task classes and classification axes are a local taxonomy proposed for StyleGallery review, not Interface In Game's universal ontology.
-
-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.
-- [Game UI Screen Hierarchy](screen-hierarchy.md) defines engine-neutral layers from application shell to atomic control.
-- [Game UI Reference Record](reference-record.md) provides the minimum evidence schema for gallery entries.
-- [Unity UI Architecture](unity/architecture.md) maps the hierarchy roles to Unity Scenes, Canvas layers, prefabs, runtime instances, input, and motion ownership.
-- [Unity UI Systems](unity/ui-systems.md) compares uGUI, UI Toolkit, and NGUI ownership and capability shapes at pinned sources.
-- [Unity CLI Loop](unity/cli-loop.md) defines a source-pinned command loop for Unity UI inspection and stack-specific interaction evidence.
-- [Unity Repository Map](unity/repository-map.md) maps the public Unity-Technologies repository snapshot by UI relevance, authority, and lifecycle.
-- [Unity Organization Compressed Wiki](unity/org-wiki.md) routes all 804 captured public repositories through a tracked inventory and bounded exclusive clusters.
-
-## Domain Contract
-
-Game UI describes interface purpose, screen composition, and how named engines can realize that model. Platform Guides cover non-game platform conventions; Layout owns portable spatial patterns.
-
-## IA Navigation
-
-Parent: [StyleGallery](../index.md).
-Next: [Game UI Decision Tree](decision-tree.md).

package/game-ui/reference-record.md

@@ -1,62 +0,0 @@
----
-type: Domain Guide
-title: Game UI Reference Record
-description: Minimum evidence record for adding a game-interface reference to StyleGallery.
-domain: game-ui
-lifecycle: experimental
----
-
-# Game UI Reference Record
-
-Primary role: gallery evidence template.
-
-## Repository Boundary
-
-This record captures enough context to compare a game UI reference without importing its assets, source hierarchy, or implementation assumptions as gallery policy.
-
-## Reusable Method
-
-Complete the record from rendered evidence first, then add hierarchy and implementation facts. Mark unknown fields instead of guessing from names.
-
-## Minimum Record
-
-| Field | Required content |
-| --- | --- |
-| Identity | Entry name, source, capture date, source revision or version |
-| Player task | One primary class and justified secondary classes |
-| Presentation | Two or three visual-language tags with rendered evidence |
-| Hierarchy | Root, layer, screen, region, component, and control ownership |
-| Platform | Engine, UI framework, relevant package or runtime versions |
-| Surface | Render space, aspect ratios, safe area, scaling policy |
-| Input | Supported modes, initial focus, navigation, cancellation, focus return |
-| States | Default, selected, disabled, loading, error, empty, modal |
-| Motion | Role, trigger, properties, timing, interruption, completion |
-| Evidence | Screen capture, recording, hierarchy capture, relevant source paths |
-| Boundary | Observed facts, inferences, unknowns, and reuse restrictions |
-
-## Opinionated Guidance
-
-Prefer a complete record to a large screenshot collection missing state, hierarchy, or input evidence. It must explain the classification and what remains unproven.
-
-## Platform-Specific Guidance
-
-Use the matching engine-specific Game UI guide to fill implementation fields. Engine terms supplement this record; they do not replace the engine-neutral player-task and hierarchy roles.
-
-## Unsupported Absolutes
-
-- A source path is not rendered evidence.
-- A polished capture is not proof of edge-state behavior.
-- A single aspect ratio or input mode is not broad platform coverage.
-
-## Verification Contract
-
-Reject an entry if its primary player task, rendered state, source identity, or evidence boundary is unknown. Keep incomplete entries in draft; do not infer missing facts.
-
-## Source, License, And Attribution
-
-Record source licensing and reuse restrictions per entry. Do not copy protected game assets into the repository merely to make the record self-contained.
-
-## IA Navigation
-
-Parent: [Game UI](index.md).
-Next: [Unity UI Architecture](unity/architecture.md).

package/game-ui/screen-hierarchy.md

@@ -1,107 +0,0 @@
----
-type: Domain Guide
-title: Game UI Screen Hierarchy
-description: Engine-neutral ownership model for composing game-interface shells, screens, layers, regions, components, and controls.
-domain: game-ui
-lifecycle: experimental
----
-
-# Game UI Screen Hierarchy
-
-Primary role: engine-neutral hierarchy guide.
-
-## Repository Boundary
-
-This hierarchy describes interface responsibility, not a required scene graph or prefab tree. Engines may realize the same roles through scenes, widgets, documents, entities, prefabs, or runtime objects.
-
-## Reusable Method
-
-Read a game UI hierarchy from ownership outward:
-
-1. Identify the lifetime owner.
-2. Identify the active player task.
-3. Separate persistent, replaceable, modal, transient, and world-linked layers.
-4. Name screen regions by responsibility.
-5. Find repeated components and atomic controls.
-6. Record navigation, input blocking, sorting, focus, and teardown ownership.
-
-## Reference Hierarchy
-
-```text
-Application UI Root
-├── Persistent Services
-│   ├── Input and Focus Routing
-│   ├── Loading and Blocking
-│   ├── Notifications
-│   └── Accessibility and Localization
-├── Screen Host
-│   └── Active Screen
-│       ├── Screen Header
-│       ├── Primary Region
-│       ├── Supporting Region
-│       └── Screen Actions
-├── HUD Layer
-│   ├── Player Status
-│   ├── World Status
-│   ├── Objectives
-│   └── Context Actions
-├── Modal Layer
-│   ├── Blocker
-│   └── Dialog or Popup Stack
-├── Transient Layer
-│   ├── Toasts
-│   ├── Tooltips
-│   └── Reward and Feedback Effects
-└── World-Linked UI
-    ├── Markers
-    ├── Labels
-    └── Interaction Prompts
-```
-
-## Hierarchy Roles
-
-| Level | Owns | Must not silently own |
-| --- | --- | --- |
-| Application root | Cross-screen lifetime, global routing, top-level sorting | Screen-specific business state |
-| Layer host | Ordering, visibility policy, input blocking | Individual component presentation |
-| Screen | One primary player task and its navigation boundary | Unrelated global services |
-| Region | A stable information or action responsibility | Whole-screen lifecycle |
-| Component | Reusable stateful presentation unit | Global navigation policy |
-| Control | One direct interaction or value presentation | Hidden cross-screen side effects |
-
-## Composition Rules
-
-- Keep persistent services independent from replaceable screen content.
-- Assign explicit ownership for modal blocking and modal content.
-- Separate popup stacks, notifications, tooltips, and reward effects when their lifetime, input, sorting, or interruption responsibilities differ.
-- Distinguish world-linked UI from screen-space HUD by camera, target, and lifetime ownership, not shared visual tokens.
-- Prefer explicit data and state inputs for repeated list cells, slots, tabs, meters, and buttons over implicit global-state access.
-- Preserve logical navigation order when visual sorting or animation changes.
-
-## Opinionated Guidance
-
-A shallow tree is not automatically better than a deep tree. Prefer boundaries that make lifetime, input, sorting, and reuse obvious. Undocumented nodes used only to offset animation, scaling, or masking side effects are a fragility signal.
-
-## Platform-Specific Guidance
-
-Map these roles to the target engine without copying the hierarchy literally. See [Unity UI Architecture](unity/architecture.md) for Unity Scene, Canvas, prefab, and runtime mapping.
-
-## Unsupported Absolutes
-
-- Do not require one root Canvas, widget tree, or scene for every game.
-- Do not equate folder nesting with runtime ownership.
-- Do not assume a prefab, widget, or component boundary is also a navigation boundary.
-- Do not infer input blocking or render order from hierarchy position alone.
-
-## Verification Contract
-
-Trace one screen from creation through teardown. Record its creator, sorting layer, input blocker, focus entry and return, what survives screen changes, and modal or transition interruption behavior.
-
-## Source, License, And Attribution
-
-This page synthesizes recurring hierarchy responsibilities observed across game UI implementations without reproducing any project-specific object tree.
-
-## IA Navigation
-
-Parent: [Game UI](index.md).
-Next: [Game UI Reference Record](reference-record.md).

package/game-ui/screen-recipes.md

@@ -1,101 +0,0 @@
----
-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).