stylegallery 0.1.7 → 0.1.8

package/platform-guides/compatibility-matrix.md

@@ -75,7 +75,7 @@ Test fallback paths deliberately rather than waiting for accidental unsupported
 
 ## Platform-Specific Guidance
 
-Apple, Android, and Windows guide pages own their dated official-source sets. Recheck them for native claims and separately verify the target runtime. Game-engine adaptation routes to [Game UI](../game-ui/index.md).
+Apple, Android, and Windows guide pages own their dated official-source sets. Recheck them for native claims and separately verify the target runtime.
 
 ## Unsupported Absolutes
 

package/quality/claim-records/stylegallery-multidomain-scope.md

@@ -8,11 +8,11 @@ description: Decision to supersede the layout-only repository identity with a go
 
 ## Decision
 
-StyleGallery supersedes the repository-wide `layout-gallery` identity with five explicit domains: Layout, Motion, Design Engineering, Game UI, and Platform Guides. The prior layout-only rules remain authoritative inside Layout instead of being deleted or silently weakened.
+StyleGallery supersedes the repository-wide `layout-gallery` identity with six explicit domains: Layout, Motion, Design Engineering, Platform Guides, Design Terminology, and Expression. The prior layout-only rules remain authoritative inside Layout instead of being deleted or silently weakened.
 
 ## Context
 
-The repository name and intended collection now exceed a single spatial corpus. Treating motion, interface craft, game-interface knowledge, engine-specific Game UI implementation, or platform comparison as Layout patterns would violate the existing pattern boundary, while leaving them ungoverned would bypass source-of-truth, ownership, lifecycle, and evidence rules.
+The repository name and intended collection now exceed a single spatial corpus. Treating motion, interface craft, art direction, terminology comparison, or platform comparison as Layout patterns would violate the existing pattern boundary, while leaving them ungoverned would bypass source-of-truth, ownership, lifecycle, and evidence rules.
 
 ## Warrant
 

package/quality/evidence/executable-evidence.md

@@ -37,7 +37,7 @@ Executable evidence identifies which claims are machine-enforced, which are only
 | Promotion governance remains a closed JSON-only, invariant-scoped, deferred example contract. | `scripts/validate-promotion-rfc.mjs` and `scripts/test-validate-promotion-rfc.mjs` | `node scripts/validate-promotion-rfc.mjs --json`; `node scripts/test-validate-promotion-rfc.mjs --json` | The manifest-declared policy and two canonical examples pass with deferred decisions, zero attestations, exact support commitment, and no promotion claim. | Manifest-declared invalid fixtures plus forged, unregistered, duplicate, path, extension, support, evidence, canonical-drift, and lifecycle mutations exit non-zero with named findings. | Synthetic validation does not authenticate adoption, organizations, owners, support capacity, provenance, or a promotion decision; the current canonical inventory supplies no real independent consumers. |
 | Portable token source and generated CSS agree through the pinned restricted adapter. | `scripts/build-reference-artifacts.mjs`, `scripts/validate-reference-artifacts.mjs`, and `scripts/test-reference-adapters.mjs` | Build with `--fail-on-warning`, validate the generated manifest, then run the adapter fixture harness. | Dimension, color, duration, tested border values, and whole-token curly aliases emit nonzero CSS declarations with matching counts and hashes; output references remain CSS variable references. | `$extends`, JSON Pointer, resolver/modifier/theme documents, unknown reserved fields, non-string descriptions, adapter-unsafe path segments, untested type/unit, partial/dangling/cyclic/type-mismatched aliases, missing output, zero count, warning, scaffold/unknown manifest fields, missing/duplicate declaration, object sentinel, unresolved or forged value, and count drift must fail with named findings and non-zero child exit. | Proves the pinned adapter preserves this tested subset and that committed artifacts independently rebuild from their canonical source, not that tokens are product defaults, portable beyond the tested adapters, visually suitable, or adopted by a consumer. |
 | The proposed Chromium sentinel preserves canonical card-grid geometry and truth-derived calibration evidence. | `tests/consumer-reference-sentinels.spec.mjs`, `scripts/test-consumer-reference-sentinel.mjs`, `scripts/validate-baseline-manifest.mjs`, and strict raw calibration harnesses. | Run the ordinary sentinel and semantic negatives in the digest-pinned nonblocking Chromium job; validate manifest/raw evidence in the contract job. | Computed visibility/cardinality/grid/gap/geometry/overflow checks precede a locator screenshot; raw DOM and AX bytes are recorded and hash-checked across runs; completion and zero diff derive only from a zero child exit, the exact passing Playwright identity, verified raw hashes, and post-assertion comparison proof. | Hidden layout, long-content overflow, fake/malformed Playwright, missing or nonzero exit, absent comparison/artifact, tampered hash, duplicate/unknown metadata, malformed recursive records, and incomplete run sets must fail without writing a completed aggregate. | Local DOM/AX/rendered evidence does not prove semantic DOM/AX conformance, product suitability, accessibility, or owner approval. Completed-CI repository, workflow, run ID and attempt, SHA, and artifact-name fields are workflow-recorded, self-asserted metadata, not an external attestation. The self-asserted repository field names the canonical upstream changeroa/StyleGallery; the self-asserted execution_repository field names the actual GitHub Actions repository and is limited to changeroa/StyleGallery or ark-jo/StyleGallery. The committed calibration's external_verification object records an independently checked GitHub Actions run and artifact API identity; artifact.api_digest is distinct from committed_ci.raw_evidence_sha256. Future CI aggregates remain awaiting_external_verification until their uploaded artifact API identity is independently checked. Linux/amd64 repeatability is externally verified only for committed run 29260372260; it does not establish baseline-owner approval or product suitability. Baseline-owner approval remains unclaimed until the named owner explicitly approves it. Synthetic fixtures validate rejection and acceptance behavior only; they are not authenticated provenance. Both Chromium jobs are nonblocking and CI never updates snapshots. |
-| Governed-local button states retain source-bound visual, DOM, and accessibility-tree evidence across both example profiles. | `scripts/create-component-state-session.mjs`, `scripts/finalize-component-state-evidence.mjs`, `scripts/validate-component-state.mjs`, and the component-state source, contract, artifact, generator, and sentinel harnesses. | `npm run test:component-state`; `npm run validate:component-state`; run the digest-pinned component-state browser capture and `npm run test:component-state:runtime-negative`. | Editorial and terminal each declare the five compound scenarios `action-disabled-busy`, `action-focused`, `action-loading-busy`, `disclosure-expanded-loading`, and `toggle-focused-pressed`; their environment-scoped approved PNG hashes and dimensions are canonical pre-capture inputs; the generated state, keyboard, and evidence matrices match their records; one clean capture session binds the browser artifacts to the governed source inventory. | Missing or altered source bindings, missing executable source manifests, invalid state/profile records, scenario drift, coordinated PNG/manifest/sidecar substitution, unapproved environment-specific raster identity, malformed or replayed runtime artifacts, hash/count mismatch, insufficient focus clearance, and sentinel mutations must exit non-zero with named findings. | Proves the declared examples and captured channels agree for an explicitly approved browser environment. Legacy source-less receipts are intentionally rejected by the capture receipt, `session_link`, and `completed_session` schemas and by executable finalization and validation. Environment-scoped PNG identity does not imply cross-platform pixel equivalence. It does not prove product suitability, independent adoption, full accessibility, cross-browser behavior, or owner approval; synthetic negative fixtures are not authenticated provenance. |
+| Governed-local button states retain source-bound visual, DOM, and accessibility-tree evidence across both example profiles. | `scripts/create-component-state-session.mjs`, `scripts/finalize-component-state-evidence.mjs`, `scripts/validate-component-state.mjs`, and the component-state source, contract, artifact, generator, and sentinel harnesses. | `bun run test:component-state`; `bun run validate:component-state`; run the digest-pinned component-state browser capture and `bun run test:component-state:runtime-negative`. | Editorial and terminal each declare the five compound scenarios `action-disabled-busy`, `action-focused`, `action-loading-busy`, `disclosure-expanded-loading`, and `toggle-focused-pressed`; their environment-scoped approved PNG hashes and dimensions are canonical pre-capture inputs; the generated state, keyboard, and evidence matrices match their records; one clean capture session binds the browser artifacts to the governed source inventory. | Missing or altered source bindings, missing executable source manifests, invalid state/profile records, scenario drift, coordinated PNG/manifest/sidecar substitution, unapproved environment-specific raster identity, malformed or replayed runtime artifacts, hash/count mismatch, insufficient focus clearance, and sentinel mutations must exit non-zero with named findings. | Proves the declared examples and captured channels agree for an explicitly approved browser environment. Legacy source-less receipts are intentionally rejected by the capture receipt, `session_link`, and `completed_session` schemas and by executable finalization and validation. Environment-scoped PNG identity does not imply cross-platform pixel equivalence. It does not prove product suitability, independent adoption, full accessibility, cross-browser behavior, or owner approval; synthetic negative fixtures are not authenticated provenance. |
 
 ## Validator Severity Contract
 

package/quality/index.md

@@ -1,6 +1,6 @@
 # Quality Gates
 
-`quality/` is shared StyleGallery infrastructure for deciding whether Layout, Motion, Design Engineering, Game UI, Platform Guides, and Design Terminology claims are admissible.
+`quality/` is shared StyleGallery infrastructure for deciding whether Layout, Motion, Design Engineering, Platform Guides, Design Terminology, and Expression claims are admissible.
 
 This shared layer does not make the repository a visual design system. Layout pattern files still own spatial structure only; domain guidance cannot bypass these gates. Quality gates explain how claims are framed, what evidence can support them, and when review or debt is required.
 
@@ -50,6 +50,5 @@ Use this script for lightweight tree tests:
 | Compare an Apple interaction convention. | [README](../README.md) | [Apple Interaction](../platform-guides/apple-interaction.md) | The first selected route is Platform Guides and source/version limits are reached within two hops. |
 | Declare whether a consumer reference applies. | [README](../README.md) | [Consumer Reference](../consumer-reference/index.md) | The handoff reaches the shared contract without classifying it as a seventh domain. |
 | Prove a consumer migration preserves declared behavior. | [README](../README.md) | [Consumer Migration Readiness](../design-engineering/consumer-migration-readiness.md) | The reader reaches the Design Engineering method and its evidence gate within two hops. |
-| Find the authority route for uGUI, UI Toolkit, or NGUI. | [README](../README.md) | [Unity UI Systems](../game-ui/unity/ui-systems.md) | The first selected route is Game UI, and the system-specific source and version boundary is reached within three hops. |
 
 Record `PASS` only when the expected primary route is the first route selected. A link resolving successfully is not enough; the selected route must match the task intent.

package/scripts/agent-native/v2/material-admission.mjs

@@ -17,7 +17,7 @@ const MANIFEST_REF = "sg:manifest/material-admission-v2";
 const MATERIAL_REF_PATTERN = /^sg:material\/path-sha256-[a-f0-9]{64}$/;
 const MATERIAL_VERSION_PATTERN = /^sg:material\/path-sha256-[a-f0-9]{64}@sha256:[a-f0-9]{64}$/;
 const HASH_PATTERN = /^[a-f0-9]{64}$/;
-const DOMAINS = new Set(["layout", "motion", "design-engineering", "game-ui", "platform-guides", "design-terminology", "shared"]);
+const DOMAINS = new Set(["layout", "motion", "design-engineering", "platform-guides", "design-terminology", "expression", "shared"]);
 const LIFECYCLES = new Set(["draft", "stable", "deprecated", "experimental", "generated"]);
 const RECORD_KEYS = new Set(["schema_version", "record_kind", "stable_ref", "version_id", "repository_path", "media_type", "source_sha256", "byte_length", "lifecycle", "domain"]);
 const MANIFEST_KEYS = new Set(["schema_version", "record_kind", "stable_ref", "version_id", "admission_policy_ref", "admission_policy_version_id", "materials"]);

package/scripts/agent-native/v2/material-identity.mjs

@@ -6,7 +6,7 @@ export const MATERIAL_STABLE_REF_KINDS = Object.freeze(["domain", "page", "patte
 const KIND_SET = new Set(MATERIAL_STABLE_REF_KINDS);
 const KEBAB = /^[a-z0-9]+(?:-[a-z0-9]+)*$/;
 const PATH_ID = /^path-sha256-[a-f0-9]{64}$/;
-const DOMAIN_IDS = new Set(["layout", "motion", "design-engineering", "game-ui", "platform-guides", "design-terminology"]);
+const DOMAIN_IDS = new Set(["layout", "motion", "design-engineering", "platform-guides", "design-terminology", "expression"]);
 const MATERIAL_ID = PATH_ID;
 
 export class MaterialIdentityError extends TypeError {
@@ -56,7 +56,7 @@ export function materialIdentityForRecord(record) {
   if (typeof repositoryPath !== "string") fail("material_record_identity_invalid", "record has no bound source path");
   let kind = "page";
   let id = `path-sha256-${sha256(Buffer.from(repositoryPath, "utf8"))}`;
-  const domainMatch = /^(layout|motion|design-engineering|game-ui|platform-guides|design-terminology)\/index\.md$/.exec(repositoryPath);
+  const domainMatch = /^(layout|motion|design-engineering|platform-guides|design-terminology|expression)\/index\.md$/.exec(repositoryPath);
   if (domainMatch) { kind = "domain"; id = domainMatch[1]; }
   else if (/^patterns\/[^/]+\/[^/]+\.md$/.test(repositoryPath)) kind = "pattern";
   return deepFreeze({

package/scripts/compiler/README.md

@@ -12,13 +12,13 @@ Use `sg compile`, `sg timeline`, and the other commands below directly. The `sty
 
 ## Setup
 
-Install StyleGallery with Node.js 22 or newer using `npm install --global stylegallery`. For an unreleased StyleGallery checkout, run commands from that checkout as `npm run sg -- <command>` instead. If another program already owns the `sg` command, use the equivalent `stylegallery` executable or the npm script. The compiler is a [separate private repository](https://github.com/changeroa/site-compiler); an account with access must install it once:
+Install StyleGallery with Node.js 22 or newer using `npm install --global stylegallery`. For an unreleased StyleGallery checkout, run commands from that checkout as `bun run sg -- <command>` instead. If another program already owns the `sg` command, use the equivalent `stylegallery` executable or the npm script. The compiler is a [separate private repository](https://github.com/changeroa/site-compiler); an account with access must install it once:
 
 ```sh
 gh repo clone changeroa/site-compiler /absolute/path/to/site-compiler
 cd /absolute/path/to/site-compiler
-npm ci --ignore-scripts --no-audit --no-fund
-npx playwright install chromium
+bun install --frozen-lockfile --ignore-scripts
+bunx playwright install chromium
 export SG_COMPILER_ROOT=/absolute/path/to/site-compiler
 sg discover --format json
 ```
@@ -90,13 +90,13 @@ Use `sg discover` or `sg ops` for the full input schemas. CLI options use hyphen
 
 Call `compile` with `{"url":"https://example.com","out":"/absolute/path/to/captures/example"}` or `gate` with `{"in":"/absolute/path/to/captures/example"}`. Prefer absolute paths because the MCP client's launch directory may differ from your terminal. Long captures require a client request timeout longer than the capture; the runner's timeout does not change client settings. `workflow` and the knowledge tools are read-only; execution tools are marked as potentially destructive and non-idempotent because existing artifacts may be replaced.
 
-From the StyleGallery checkout, use `npm run sg -- compile ...` and `npm run sg:mcp` for local development. To connect an MCP client to that unreleased checkout, use `"command": "node"` and `"args": ["/absolute/path/to/StyleGallery/scripts/sg-server.mjs"]` with the same environment settings. The frozen six-tool v1 server is `npm run sg:mcp:v1`, and its CLI is `npm run sg:v1 -- ...`.
+From the StyleGallery checkout, use `bun run sg -- compile ...` and `bun run sg:mcp` for local development. To connect an MCP client to that unreleased checkout, use `"command": "node"` and `"args": ["/absolute/path/to/StyleGallery/scripts/sg-server.mjs"]` with the same environment settings. The frozen six-tool v1 server is `bun run sg:mcp:v1`, and its CLI is `bun run sg:v1 -- ...`.
 
 ## Contracts And Verification
 
 The adapter follows the handoff fields in [Component Contract](../../design-engineering/component-contract.md): explicit inputs, outputs, process ownership, cancellation, and observable failure. Motion transcription remains governed by [Observed Choreography](../../motion/observed-choreography.md). These are routes into the existing domains; the transport creates no new domain or reusable Layout styling.
 
-From the StyleGallery checkout, run `npm run test:compiler` for subprocess, argument, cancellation, JSON, and MCP transport checks. With a compiler installation and Chromium available, run `SG_COMPILER_INTEGRATION_ROOT=/absolute/path/to/site-compiler npm run test:compiler` to also capture a local fixture with the real upstream scripts. Model transcription, model builds, and product release packaging are separate upstream operations and are not exercised by that smoke test.
+From the StyleGallery checkout, run `bun run test:compiler` for subprocess, argument, cancellation, JSON, and MCP transport checks. With a compiler installation and Chromium available, run `SG_COMPILER_INTEGRATION_ROOT=/absolute/path/to/site-compiler bun run test:compiler` to also capture a local fixture with the real upstream scripts. Model transcription, model builds, and product release packaging are separate upstream operations and are not exercised by that smoke test.
 
 Implementation handoff:
 

package/showcase/README.md

@@ -0,0 +1,113 @@
+---
+type: Showcase Guide
+title: Showcase
+description: Free-form, single-page expressive works checked by outcome instead of authoring rules.
+lifecycle: experimental
+---
+
+# Showcase
+
+Primary role: expressive work area.
+
+`showcase/` holds complete, expressive pages: brand studies, landing pages, and art-directed experiments. The Layout authoring rules do not apply here. A work may use any CSS property, any selector, gradients, blend modes, WebGL, GSAP, Lenis, or its own fonts. Layout still sets the floor: a work has to pass the outcome checks below. It does not have to follow the pattern CSS style guide.
+
+## Why It Exists
+
+Reusable Layout patterns exclude decorative styling so they stay portable. That rule is correct for `patterns/**`, but it made the repository unable to express a finished product page. Showcase is the product layer where the finished page lives. It depends on Layout and Expression. Nothing depends on it.
+
+## Work Contract
+
+Each work is one directory, `showcase/<slug>/`, containing:
+
+- `index.html`: the entry page. It may load local files or pinned CDN libraries.
+- `brief.md`: the direction, frontmatter with `type: Showcase Brief`, `title`, `description`, and `brand_study: true|false`.
+- Any other local assets the page needs.
+
+A brand study (`brand_study: true`) reinterprets a named real brand. It additionally requires:
+
+- `subject:` in the brief frontmatter, naming the brand being studied.
+- `<meta name="robots" content="noindex, nofollow">` in `index.html`.
+- Visible text containing "Unofficial" on the page.
+- No copied logos, trademarks as artwork, or verbatim marketing copy. Write original copy in the brand's register instead.
+
+See [Brand Studies](../expression/brand-studies.md) for the reasoning and limits.
+
+## Brief Template
+
+```md
+---
+type: Showcase Brief
+title: <Work name>
+description: <One sentence: what the page is and what it should feel like.>
+brand_study: false
+---
+
+# <Work name>
+
+## Direction
+Reference, mood, and the one thing a visitor should remember.
+
+## System
+Type pairing, palette, texture, and motion density, with actual values or a link to an Expression direction.
+
+## Techniques
+Expression and Motion technique pages the work uses.
+
+## Layout Floor
+Scroll owner, pinned or sticky regions, and how the page collapses at 320px.
+```
+
+## Preview
+
+```sh
+bun run showcase:serve              # http://localhost:4180/ (hub) and one URL per work
+bun run showcase:serve -- --port 4190
+```
+
+Working on a remote machine over SSH? Run this on your own machine, then open `http://localhost:4180/` in your local browser:
+
+```sh
+ssh -N -L 4180:127.0.0.1:4180 <user>@<remote-host>
+```
+
+The serve command prints this line with the right user and host filled in. Fonts and libraries load from CDNs in the visitor's browser, so the local machine needs internet access.
+
+Once any work exists, `showcase/index.html` is the hub that lists every work: the first work creates it, every later work adds a card, and each work's footer links back to `../`.
+
+## Outcome Checks
+
+`bun run test:showcase` (or `node scripts/check-showcase.mjs --work <slug>`) runs the hub and every work in headless Chromium. Each check maps to a scenario in the [QA contract](QA.md):
+
+| Check | Failure |
+| --- | --- |
+| Brief contract | Missing brief fields, or a brand study without `subject`, `noindex`, or visible "Unofficial" text. |
+| Runtime and assets | Any uncaught page error, or any same-origin request answered with 4xx. Failed CDN requests alone are tolerated. |
+| Horizontal overflow | Document wider than the viewport at 320, 768, or 1440 CSS pixels, at the top, middle, or bottom. |
+| Focus | A tabbable element with no box, outside the viewport, covered by another element (such as a sticky header), or reached out of DOM order. |
+| Reduced motion | With `prefers-reduced-motion: reduce`, a heading or paragraph invisible on arrival, or an infinite animation running. |
+| Contrast | Text over a solid background below WCAG AA: 4.5:1, or 3:1 for large text. |
+| Links and actions | A link to raw Markdown, an empty `#`, a missing `#id`, or `#top` outside the header; a `[data-demo]` action that is not a button, shows no visible `role="status"` message, or moves the page. |
+| Identity | No title or no favicon. |
+| Hash navigation | Clicking the first header nav link does not update the URL hash or lands its heading under the header or below the top half; Back does not return near the top; opening the last nav target's URL directly does not land on it. |
+| Short viewport | At 1280x620, a fixed or pinned element that contains text is taller than the viewport. |
+| Offscreen ambient | At 1440 wide, an infinite CSS animation or repeating GSAP tween still running on an element entirely offscreen. Mark ambient containers `data-ambient` and pause them with an IntersectionObserver. |
+| Offline | With every non-local request blocked: page errors, hidden text, or overflow at 390 wide. |
+| No script | With every script blocked: hidden text or overflow at 390 wide. |
+| Hub | Works exist but `showcase/index.html` is missing, or a work directory it does not link. With no works, the check passes and reports that there is nothing to check. |
+
+Fictional actions (subscribe, book, get a key) must be `<button type="button" data-demo="...">` elements that show an honest message in a `role="status"` region, never links that jump to the top.
+
+Screenshots are taken after entrance tweens and CSS transitions settle and are written to `.tmp/showcase/<slug>/`. The checks do not judge taste: review the screenshots. `bun run test:showcase:self` proves each check can fail by running the checker against fixtures built to violate it.
+
+## Works
+
+The repository ships the contract, the checker, and the guidance, but no committed works. Works are built per project in `showcase/<slug>/` and must pass the checks above before they are shared.
+
+## Starting A Work Fast
+
+Read this page, one [Expression direction](../expression/index.md), and the [Motion techniques](../motion/techniques/scroll-choreography.md) you need. Skip governance, provenance, and consumer-reference documents: a showcase work creates no governed record. Build, add a hub card, run `bun run showcase:serve` and `node scripts/check-showcase.mjs --work <slug>`, look at the screenshots, and iterate.
+
+## IA Navigation
+
+Parent: [StyleGallery](../index.md).
+Next: [Expression](../expression/index.md).

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).