stylegallery 0.1.0

package/game-ui/screen-hierarchy.md

@@ -0,0 +1,107 @@
+---
+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/unity/architecture.md

@@ -0,0 +1,166 @@
+---
+type: Domain Guide
+title: Unity UI Architecture
+description: Unity-specific mapping from engine-neutral game UI hierarchy to Scenes, Canvas layers, prefabs, runtime instances, and motion ownership.
+domain: game-ui
+lifecycle: experimental
+source_repository: https://github.com/annulusgames/UGUIAnimationSamples
+source_path: README.md
+source_revision: 343c8110e5683be209cc01ccb4cb986175e61643
+platform: Unity uGUI and legacy Unity UI stacks
+platform_version: Unity 2022.3.7f1 sample evidence; Unity 6.3 LTS and uGUI 2.0 guidance
+reviewed_on: 2026-07-14
+---
+
+# Unity UI Architecture
+
+Primary role: Unity hierarchy and implementation guide.
+
+## Repository Boundary
+
+This page maps the engine-neutral [Game UI Screen Hierarchy](../screen-hierarchy.md) to Unity concepts. It does not define game UI classification, require one universal Scene or Canvas structure, or treat a sample repository as a complete production architecture.
+
+## Version Boundary
+
+Two evidence contexts are intentionally separate:
+
+- **Pinned sample evidence:** the UGUI Animation Samples revision `343c8110e5683be209cc01ccb4cb986175e61643` records Unity `2022.3.7f1`, uGUI `1.0.0`, and TextMesh Pro `3.0.7`. Claims about its files apply only to that immutable snapshot.
+- **Current implementation guidance:** Unity Manual `6000.3` (Unity 6.3 LTS) and uGUI package `2.0` documentation were reviewed on 2026-07-14. Use those versioned documents for the concepts linked below, then verify the exact Unity and package versions recorded by each gallery entry.
+
+The pinned project is evidence about a small animation sample, not proof that its serialized hierarchy, packages, or lifecycle choices are appropriate for production or current Unity versions.
+
+## Reusable Method
+
+Inspect a Unity UI reference in this order:
+
+1. Record the Unity editor and UI package versions.
+2. Identify the Scene or persistent bootstrap object that owns UI lifetime.
+3. Locate root Canvas, UIDocument, or legacy NGUI panel boundaries.
+4. Identify screen, HUD, modal, transient, and world-space hosts.
+5. Trace prefab assets, nested prefabs, variants, scene instances, and runtime-created instances.
+6. Record sorting, input routing, focus, scaling, animation, and teardown ownership.
+7. Compare the rendered result with the engine-neutral Game UI record.
+
+## Scene And Runtime Hierarchy
+
+Unity's Hierarchy window shows GameObjects in the loaded Scene, including prefab instances. It does not by itself reveal asset ownership, runtime-created objects, persistent objects from another Scene, or the complete navigation policy.
+
+```text
+Bootstrap or Loaded Scene
+├── Persistent UI Services
+│   ├── EventSystem or Input Router
+│   ├── Loading and Blocking Host
+│   └── Notification Host
+├── Screen-Space UI Root
+│   ├── Screen Canvas or UIDocument
+│   ├── HUD Canvas
+│   ├── Modal Canvas
+│   └── Transient Effects Canvas
+└── World-Space UI Roots
+    ├── Markers
+    ├── Labels
+    └── Interaction Prompts
+```
+
+Treat this as a responsibility map. A project may combine or split these roots according to rebuild cost, sorting, camera setup, lifetime, input, and team ownership.
+
+## Prefab Hierarchy
+
+| Unity concept | What it represents | Review question |
+| --- | --- | --- |
+| Prefab asset | Reusable serialized GameObject hierarchy | What stable responsibility does the asset own? |
+| Prefab instance | Scene or runtime occurrence linked to an asset | Which properties are overrides, and who owns its lifetime? |
+| Nested prefab | Prefab instance preserved inside another prefab | Does nesting express reuse or hide cross-component coupling? |
+| Prefab variant | Asset inheriting from another prefab | Are differences intentional variants or accumulated overrides? |
+| Unpacked object | Hierarchy no longer linked as an instance | Was the loss of inheritance deliberate and recorded? |
+| Runtime instance | Object created during play | Where is it parented, initialized, focused, pooled, and destroyed? |
+
+Use prefab boundaries for stable ownership and reuse. Do not create a prefab for every visual node, and do not let a large screen prefab silently own global routing, data services, or unrelated modal layers.
+
+## Canvas And Layer Ownership
+
+| Layer responsibility | Typical Unity realization | Evidence to capture |
+| --- | --- | --- |
+| Persistent services | DontDestroyOnLoad root or bootstrap Scene | Creation order, duplicate prevention, teardown policy |
+| Active screen | Screen prefab under a screen host | Navigation boundary, initial focus, close behavior |
+| HUD | Dedicated Canvas or stable subtree | Camera relationship, update ownership, visibility policy |
+| Modal | Sorting layer with blocker and popup stack | Raycast blocking, stacking, cancellation, focus return |
+| Transient feedback | Pooled toast, tooltip, reward, or effect host | Sorting, pooling, interruption, time source |
+| World-linked UI | World Space Canvas or camera-projected element | Target loss, occlusion, distance, camera switching |
+
+Canvas boundaries create ownership, sorting, and configuration decisions. Measure batching and rebuild behavior with the actual content and update pattern, and profile representative target-device workloads before attributing a performance benefit to nested Canvases.
+
+## Component Hierarchy
+
+A reusable Unity UI component commonly separates these roles:
+
+```text
+Component Prefab Root
+├── Layout Root
+├── Visual States
+├── Content Bindings
+├── Interaction Target
+├── Optional Feedback Effects
+└── Component Controller
+```
+
+- `RectTransform` hierarchy expresses layout and parenting, not business ownership by itself.
+- `CanvasGroup` may coordinate visibility, interaction, and raycast blocking; verify all three properties.
+- `Selectable` navigation and EventSystem state require keyboard and gamepad evidence, not only pointer behavior.
+- ScrollRect structures should make viewport, content, scrollbar, cell reuse, and scroll ownership explicit.
+- Text components require localization, fallback, wrapping, material, and dynamic-size evidence.
+
+## Motion Ownership
+
+The pinned snapshot contains four serialized Scene YAML files and scripts for hover, button, text, and toggle examples. The scripts use LitMotion; `TextAnimation.cs` and the pinned package files contain text evidence of UniTask use for button-click subscriptions. Text and YAML inspection does not prove compilation, rendering, or runtime behavior, although the YAML records Screen Space Overlay Canvas, Canvas Scaler, and EventSystem components.
+
+Use the snapshot only as serialized evidence for component interaction motion. It does not establish a production Scene or prefab architecture, keyboard or gamepad coverage, responsive behavior, multi-Scene lifetime, successful runtime execution, or teardown policy. The inspected hover and button scripts contain `OnDestroy` cancellation paths; the two toggle scripts do not contain `OnDestroy`, but that absence alone is not proof of a leak or other runtime defect.
+
+Record whether motion is owned by Animator, a tween library, Timeline, a custom update loop, or a mixed system. For every transition, identify the trigger, animated properties, time source, cancellation behavior, disabled-object behavior, completion callback, and final state. A parent screen transition must not leave child controls focused, interactive, or visually stale.
+
+## Opinionated Guidance
+
+- Separate Scene lifetime, layer lifetime, screen lifetime, and component lifetime.
+- Prefer a small number of named layer hosts over ad hoc sorting overrides across unrelated prefabs.
+- Keep screen prefabs focused on one primary player task; route global blockers and notifications through explicit hosts.
+- Use nested prefabs and variants when inheritance is intentional and reviewable, not merely to reduce duplication at any cost.
+
+## Platform-Specific Guidance
+
+- Record whether the entry uses uGUI, UI Toolkit, legacy NGUI, or a mixed stack.
+- For uGUI, capture Canvas render mode, Canvas Scaler settings, sorting configuration, Graphic Raycaster, EventSystem, and relevant input module.
+- For UI Toolkit, capture Panel Settings, UIDocument ownership, visual tree source, style-sheet sources, focus behavior, and runtime document lifecycle.
+- For legacy or mixed stacks, name the bridge points, camera and sorting relationships, input ownership, and migration limits.
+
+## Unsupported Absolutes
+
+- Do not require one Canvas for an entire application or one Canvas per screen.
+- Do not equate Scene hierarchy order with render order, input priority, or lifetime ownership.
+- Do not assume a prefab instance is unchanged; inspect overrides and variants.
+- Do not call a UI responsive because Canvas Scaler is present.
+- Do not infer runtime behavior from YAML, asset paths, or prefab names alone.
+- Do not claim one animation system is faster or easier to maintain without measurements and project constraints.
+
+## Verification Contract
+
+Open the target Scene and Prefab Mode, then enter Play Mode. Capture the loaded Scene hierarchy, persistent objects, root UI hosts, prefab instance links and overrides, Canvas settings, sorting, EventSystem selection, and runtime-created objects. Exercise scene changes, repeated screen open and close, nested modals, focus return, safe areas, long localized text, paused or scaled time, and interrupted transitions.
+
+Repository YAML and metadata can establish hierarchy leads, but rendered appearance and runtime ownership remain unverified until Editor and Play Mode evidence is attached.
+
+## Source, License, And Attribution
+
+- Public sample snapshot: [annulusgames/UGUIAnimationSamples at `343c8110e5683be209cc01ccb4cb986175e61643`](https://github.com/annulusgames/UGUIAnimationSamples/tree/343c8110e5683be209cc01ccb4cb986175e61643) and its pinned [README.md](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/README.md)
+- Pinned version and dependency evidence: [ProjectVersion.txt](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/ProjectSettings/ProjectVersion.txt), [manifest.json](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Packages/manifest.json), and [packages-lock.json](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Packages/packages-lock.json)
+- Pinned serialized Scene evidence: [1_Hover.unity](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/1_Hover.unity), [2_Button.unity](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/2_Button/2_Button.unity), [3_Text.unity](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/3_Text/3_Text.unity), and [4_Toggle.unity](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/4_Toggle/4_Toggle.unity)
+- Pinned hover script evidence: [Hover1.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover1.cs), [Hover2.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover2.cs), [Hover3.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover3.cs), [Hover4.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover4.cs), [Hover5.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover5.cs), and [Hover6.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/1_Hover/Scripts/Hover6.cs)
+- Pinned button, text, and toggle script evidence: [Button1.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/2_Button/Scripts/Button1.cs), [Button2.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/2_Button/Scripts/Button2.cs), [TextAnimation.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/3_Text/Scripts/TextAnimation.cs), [Toggle1.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/4_Toggle/Scripts/Toggle1.cs), and [Toggle2.cs](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/Assets/Samples/4_Toggle/Scripts/Toggle2.cs)
+- Snapshot license: [The Unlicense](https://github.com/annulusgames/UGUIAnimationSamples/blob/343c8110e5683be209cc01ccb4cb986175e61643/LICENSE)
+- Unity 6.3 LTS Manual: [UI system comparison](https://docs.unity3d.com/6000.3/Documentation/Manual/UI-system-compare.html), [Hierarchy window](https://docs.unity3d.com/6000.3/Documentation/Manual/Hierarchy.html), [Prefabs](https://docs.unity3d.com/6000.3/Documentation/Manual/Prefabs.html), [creating Prefabs](https://docs.unity3d.com/6000.3/Documentation/Manual/CreatingPrefabs.html), [nested Prefabs](https://docs.unity3d.com/6000.3/Documentation/Manual/NestedPrefabs.html), [Prefab variants](https://docs.unity3d.com/6000.3/Documentation/Manual/PrefabVariants.html), [unpacking Prefab instances](https://docs.unity3d.com/6000.3/Documentation/Manual/UnpackingPrefabInstances.html), [`Object.Instantiate`](https://docs.unity3d.com/6000.3/Documentation/ScriptReference/Object.Instantiate.html), and [`Object.DontDestroyOnLoad`](https://docs.unity3d.com/6000.3/Documentation/ScriptReference/Object.DontDestroyOnLoad.html)
+- uGUI 2.0 Manual: [Canvas](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/UICanvas.html), [Rect Transform](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/class-RectTransform.html), [Canvas Group](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/class-CanvasGroup.html), [Canvas Scaler](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-CanvasScaler.html), [navigation options](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-SelectableNavigation.html), [Event System](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/EventSystem.html), [Graphic Raycaster](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-GraphicRaycaster.html), and [Scroll Rect](https://docs.unity3d.com/Packages/com.unity.ugui@2.0/manual/script-ScrollRect.html)
+- Unity 6.3 LTS UI Toolkit Manual: [create a UI Document component](https://docs.unity3d.com/6000.3/Documentation/Manual/UIE-create-ui-document-component.html) and [focus order](https://docs.unity3d.com/6000.3/Documentation/Manual/UIE-focus-order.html)
+- Reuse form: independent, project-neutral architecture and review method; no game assets or upstream implementation samples are reproduced.
+
+## IA Navigation
+
+Parent: [Game UI](../index.md).
+Next: [Unity UI Systems](ui-systems.md).

package/game-ui/unity/cli-loop.md

@@ -0,0 +1,84 @@
+---
+type: Domain Guide
+title: Unity CLI Loop
+description: Source-pinned workflow for inspecting and exercising Unity Game UI with unity-cli-loop while preserving UI-stack boundaries.
+domain: game-ui
+lifecycle: experimental
+source_repository: https://github.com/hatayama/unity-cli-loop
+source_path: README.md
+source_revision: 61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0
+platform: Unity 2022.3 or later as stated by the pinned source
+platform_version: unity-cli-loop source snapshot 61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0
+reviewed_on: 2026-07-14
+---
+
+# Unity CLI Loop
+
+Primary role: Unity command-loop verification guide.
+
+## Repository Boundary
+
+This guide adapts the pinned unity-cli-loop command surface into a bounded Game UI inspection workflow. It documents what the audited source exposes for Editor control, hierarchy inspection, screenshots, uGUI interaction, input injection, and dynamic C# execution. No live Unity project was executed during this source review, so project compatibility and observed runtime results must be supplied by the user of the guide.
+
+## Reusable Method
+
+Use the loop in this order and preserve the evidence from each stage.
+
+1. **Launch the matching Editor.** Run the launch workflow from the Unity project so its recorded Editor version is selected. The pinned README exposes `uloop launch`, project-path selection, build-target selection, and restart behavior in its [direct CLI section](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/README.md#direct-cli-usage-advanced).
+2. **Compile from a clean console.** Clear stale console entries when appropriate, run `compile`, wait for domain reload when the task requires it, then collect logs. Do not proceed to UI interaction while compile errors make the runtime state ambiguous.
+3. **Inspect hierarchy and find objects.** Record the loaded Scene context, then use the hierarchy and GameObject search workflows to locate Transforms, `Canvas`, `EventSystem`, `UIDocument`, `UIRoot`, `UIPanel`, and other serialized components. The hierarchy service traverses GameObjects and Transforms in [`HierarchyService.cs`](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/Packages/src/Editor/Core/CoreTools/HierarchyAnalyzer/HierarchyService.cs#L338-L379). A UI Toolkit VisualElement child is not a Transform child, so finding a `UIDocument` does not enumerate its runtime visual tree.
+4. **Enter Play Mode when runtime evidence is required.** Use the Play Mode control workflow before Game View rendering capture and annotations, pointer simulation, Input System injection, input recording or replay, and inspection of runtime-created objects. Window screenshots may work outside Play Mode, but `CaptureMode: rendering` requires Play Mode at the pinned revision. Capture logs immediately after state changes.
+5. **Capture the correct screenshot.** An Editor-window screenshot can show editor chrome outside Play Mode. In Play Mode, use the Game View rendering capture and its annotations when coordinates or runtime UI evidence are needed. Keep the pre-action image.
+6. **Simulate through the stack-appropriate route.** Use the dedicated uGUI pointer workflow for EventSystem-handled UI. Use Input System mouse or keyboard injection only when the project actually reads that input path. For UI Toolkit or NGUI, combine rendering, component inspection, and narrowly scoped project code while keeping their distinct event routes explicit.
+7. **Use dynamic code for targeted inspection or mutation.** Query project state, inspect `UIDocument.rootVisualElement`, or make bounded editor changes with `execute-dynamic-code`. Treat the result as evidence of the code that ran, not as proof that a player-input path was exercised.
+
+   > [!IMPORTANT]
+   > **Dynamic-code security boundary:** Use the lowest sufficient security level and keep **Restricted** unless the task specifically requires an operation it blocks. Restricted is defense-in-depth, not a trust boundary or a Unity-only sandbox. At the pinned revision, submitted code can read arbitrary files available to the Editor process, can create files and write through permitted stream APIs, can call Unity APIs and .NET standard libraries, and can invoke user-defined project assemblies; those assemblies may expose additional capabilities. Selected deletion, direct file-writing helpers, network, process, dynamic-loading, thread, and registry operations are blocked, and the compiled assembly is validated before and after load, but these checks do not make untrusted code safe. **Review and trust submitted code in both Restricted and FullAccess modes. FullAccess removes the Restricted-mode checks and should be exceptional.** Run AI-generated or otherwise untrusted dynamic code only inside a disposable, least-privilege VM or container with no host credentials, personal files, production tokens, or writable host mounts. Before either mode, review the submitted code and the target Unity project, including project assemblies it can call. Turn off `execute-dynamic-code` in the tool settings when it is unnecessary. The security level is persisted in `.uloop/settings.permissions.json`; although the upstream README permits optional team sharing, keep permission and related local configuration out of commits or published artifacts when it would reveal the project's security policy. See the pinned [security policy](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/SECURITY.md#security-best-practices-for-users), [README security levels](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/README.md#10-execute-dynamic-code---dynamic-c-code-execution), and [settings file guidance](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/README.md#unity-cli-loop-files).
+8. **Capture the result and save intentionally.** Collect the post-action screenshot and logs, compare the expected state, and explicitly save Scene or prefab changes when the task changed serialized content.
+
+## Stack-Specific Interaction Boundary
+
+| Stack | What the pinned workflow exposes | Required caution |
+| --- | --- | --- |
+| uGUI | Dedicated annotation scans uGUI `Selectable` and EventSystem handler targets. `simulate-mouse-ui` constructs pointer/drag events and requires Play Mode plus an EventSystem; ordinary Canvas interaction also needs the project's raycast path, commonly an active Graphic Raycaster. See [`UIElementAnnotator.cs`](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/Packages/src/Editor/Utils/UIElementAnnotator.cs#L145-L215) and [`SimulateMouseUiTool.cs`](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/Packages/src/Editor/Api/McpTools/SimulateMouseUi/SimulateMouseUiTool.cs#L31-L49). | Confirm the active EventSystem, input module, raycaster, blockers, selected object, and target Scene before interpreting a click or drag. |
+| UI Toolkit | Rendering capture can show the Game View, and generic hierarchy inspection can find a `UIDocument` component. Dynamic C# can query its runtime `rootVisualElement`. | The VisualElement tree is Panel-owned rather than Transform-owned. At the pinned snapshot, the audited dedicated UI annotations and pointer tool are uGUI/EventSystem-oriented, so VisualElement lookup and manipulation remain project-specific work. |
+| NGUI | Rendering capture and generic GameObject/component inspection can locate `UIRoot`, `UIPanel`, widgets, and `UICamera`. Dynamic C# can read or set component state. | NGUI's pinned [`UICamera`](https://github.com/tasharen/ngui/blob/9bbc56f11e0e25b89fd55b9b9bc67ddf1f182fe2/Assets/NGUI/Scripts/UI/UICamera.cs#L13-L43) performs its own raycasts and message dispatch with legacy `UnityEngine.Input` defaults. EventSystem dispatch or New Input System injection does not by itself demonstrate that UICamera processed the same pointer route. |
+
+## Coordinate Contract
+
+Use the `SimX` and `SimY` values returned by the rendering annotation directly with the matching simulation call. They are caller-facing Game View input coordinates with a top-left origin. Do not substitute Transform positions, RectTransform positions, or Editor-window pixels, and do not apply an extra Y-axis flip. Keep the screenshot resolution and Game View state with the coordinate evidence.
+
+## Dynamic-Code Proof Boundary
+
+The pinned dynamic-code skill describes a generic Editor execution mechanism and compilation/error reporting in [`uloop-execute-dynamic-code/SKILL.md`](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/.agents/skills/uloop-execute-dynamic-code/SKILL.md#L22-L56). A direct property assignment or callback invocation can prove that the submitted code completed and that the inspected state changed. By itself it does not prove raycast blockers, hover and press transitions, drag thresholds, focus movement, cancellation, pointer capture, or the player's real input path.
+
+## Opinionated Guidance
+
+- Keep command outputs as separate evidence until the verification contract ties them to one claim.
+- Prefer the stack's input route for behavior verification. Use direct code for inspection or bounded setup, and reinspect after entering Play Mode when runtime-created or persistent objects matter.
+
+## Platform-Specific Guidance
+
+- For uGUI, confirm the Canvas, Graphic Raycaster, EventSystem, active input module, handler, and current selection before simulation.
+- For UI Toolkit, record the runtime Panel and focus owner. For NGUI, record its collider or raycast configuration and legacy-input delegates.
+- In mixed projects, label each action with the input and hierarchy system it targets.
+
+## Unsupported Absolutes
+
+No single command result proves end-to-end interaction: a screenshot does not prove dispatch; finding a component does not enumerate its non-Transform descendants; direct code does not prove the player's input path or that serialized changes were saved. Tool availability also does not prove that a project's packages and configuration meet its prerequisites.
+
+## Verification Contract
+
+For a complete UI loop, retain launch/version evidence, clean compile output, relevant logs, pre-action hierarchy, pre-action rendering screenshot, exact `SimX`/`SimY` or input parameters, the stack-specific input route, post-action screenshot, post-action logs, focus or selected-state evidence, and save confirmation for serialized edits. Repeat the critical interaction after a fresh Play Mode entry when persistence or initialization is part of the claim.
+
+## Source, License, And Attribution
+
+- Adapted source: [hatayama/unity-cli-loop README at `61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0`](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/README.md)
+- Source license: [MIT](https://github.com/hatayama/unity-cli-loop/blob/61a0fe6d7da0aa9d0bcbc6d95944dd069c483ff0/LICENSE.md)
+- Reuse form: independently authored Game UI verification workflow based on the pinned command documentation and implementation paths; no upstream command output or project asset is reproduced.
+- Review boundary: source inspection only; no live Unity project was run for this page.
+
+## IA Navigation
+
+Parent: [Game UI](../index.md).
+Next: [Unity Repository Map](repository-map.md).