@zigrivers/scaffold 3.5.0 → 3.5.1

package/content/knowledge/game/game-ai-patterns.md

@@ -14,7 +14,7 @@ Game AI systems exist on a spectrum from simple to complex:
 
 - **Finite State Machines (FSM)**: States with explicit transitions. Simple, predictable, easy to debug. Falls apart when state count grows large. Best for simple enemies, UI, and game state management.
 - **Behavior Trees (BT)**: Hierarchical task decomposition. Moderate complexity, highly readable, industry standard for action game AI. Used in Halo, Unreal Engine's default AI, most AAA combat AI.
-- **Goal-Oriented Action Planning (GOAP)**: Agents define goals, planner finds action sequences to achieve them. More autonomous, harder to control. Used in F.E.A.R., Shadow of Mordor.
+- **Goal-Oriented Action Planning (GOAP)**: Agents define goals, planner finds action sequences to achieve them. More autonomous, harder to control. Used in F.E.A.R., Tomb Raider (2013 reboot).
 - **Utility AI**: Score every possible action and pick the highest-scoring one. Extremely flexible, non-linear priority. Used in The Sims, Infinite Axis Utility System. Harder to predict and debug.
 
 Each system has a sweet spot. Do not use GOAP for a platformer enemy that runs left and right. Do not use an FSM for an open-world companion that must react to hundreds of situations.
@@ -540,3 +540,28 @@ AI bugs are hard to reproduce because they depend on runtime state. Build debugg
 - **Freeze and inspect**: Ability to pause the game and inspect any NPC's full AI state (current BT node, GOAP plan, utility scores, perception targets)
 - **Record and replay**: Capture AI inputs (world state each frame) and replay to reproduce bugs deterministically
 - **Slow motion**: Run the game at 0.25x speed to observe AI decision-making in real time
+
+## Genre-Specific AI Patterns
+
+### Strategy Game AI
+
+Strategy AI operates on longer time horizons than action AI. Key patterns:
+
+- **Influence Maps**: 2D grid overlays tracking resource density, threat level, territory control. Update per turn or every N seconds. Used for build placement decisions, army movement, and resource prioritization.
+- **Build Order Planning**: Decision trees or scripted sequences for early-game economy. At higher difficulty, use Monte Carlo Tree Search (MCTS) to evaluate build paths 10-20 turns ahead.
+- **Opponent Modeling**: Track player tendencies (aggressive/defensive/economic) and adapt strategy. Simple approach: weighted counter-strategy table. Advanced: maintain belief state of opponent's hidden information.
+
+### Turn-Based AI
+
+- **Minimax with Alpha-Beta Pruning**: Standard for two-player zero-sum games (chess, checkers). Search depth 4-8 plies for real-time-constrained turns. Evaluation function must be fast (<1ms per position).
+- **Monte Carlo Tree Search (MCTS)**: Preferred for games with large branching factors (Go, complex card games). Run 1,000-10,000 simulations per decision within the time budget. UCB1 exploration constant: typically 1.0-1.4.
+
+### Racing AI
+
+- **Racing Line Following**: Precompute optimal racing line as spline control points. AI follows line with rubber-banding: if too far ahead, reduce throttle by 5-15%; if behind, increase by 10-20%. Expose difficulty parameter controlling how closely AI follows the optimal line.
+- **Overtaking Decision**: Distance-to-corner, speed differential, and track width determine whether to attempt pass. Use simple cost function: `overtake_score = speed_advantage * track_width / distance_to_corner`.
+
+### Simulation/Management AI
+
+- **Need-Based Scheduling**: NPCs maintain need queues (hunger, rest, social). Highest-urgency need drives behavior selection. Satisfaction decay rates define personality: fast hunger decay = always eating. Based on Sims-style utility curves.
+- **Agent Scheduling**: For city-builder NPCs: pathfind to workplace at shift start, return home at shift end. Use job queue with priority: emergency > assigned work > idle tasks. Budget 0.5-1ms per agent per tick for 100+ simultaneous agents.

package/content/knowledge/game/game-asset-pipeline.md

@@ -55,7 +55,7 @@ The pipeline typically involves multiple DCC tools in sequence:
 
 - **3D Modeling**: Maya (industry standard, USD support), Blender (free, growing adoption), 3ds Max (legacy, architectural viz)
 - **Sculpting**: ZBrush (high-poly sculpting, retopo), Blender (integrated sculpt mode)
-- **Texturing**: Substance 3D Painter (PBR texturing standard), Substance Designer (procedural materials), Quixel Mixer (free with Unreal)
+- **Texturing**: Substance 3D Painter (PBR texturing standard), Substance Designer (procedural materials), Quixel Bridge (Mixer was discontinued in 2024; the Megascans library and Bridge integration remain active in Unreal)
 - **VFX/Procedural**: Houdini (procedural generation, destruction, terrain), EmberGen (real-time fluid sim for VFX textures)
 - **2D Art**: Photoshop, Aseprite (pixel art), Krita (free painting)
 - **Audio**: FMOD Studio / Wwise (integration middleware), Audacity (editing), Reaper (DAW)
@@ -256,7 +256,11 @@ Each DCC tool in the pipeline needs documented export settings to ensure consist
 
 **Blender to FBX export settings:**
 - Scale: 1.0 (ensure Blender scene scale matches engine units — 1 unit = 1 meter for Unreal, 1 unit = 1 meter for Unity)
-- Forward axis: -Y Forward, Z Up (Unreal default) or varies by engine
+- Forward axis per engine:
+  - Unreal: -Y Forward, Z Up
+  - Unity: use FBX exporter 'Z Forward' setting — Unity converts to Y-Up left-handed on import
+  - Godot: -Z Forward, Y Up (right-handed)
+Verify axis settings with a test cube export before committing to a convention. A single wrong axis setting affects every asset in the pipeline.
 - Apply Modifiers: Yes
 - Mesh: Triangulate Faces enabled for guaranteed triangle counts
 - Armature: only include deform bones (exclude IK targets, helper bones)
@@ -288,7 +292,7 @@ Channel packing stores multiple grayscale maps in the RGBA channels of a single
 **Compression formats by platform:**
 - **PC/Console**: BC7 (high quality, 8 bpp) for albedo/normal, BC5 for 2-channel normals, BC4 for grayscale masks
 - **Android**: ASTC (adaptive block sizes: 4x4 for high quality, 8x8 for lower quality/smaller size), ETC2 for broad compatibility
-- **iOS**: ASTC (preferred) or PVRTC (legacy)
+- **iOS**: ASTC (required for all Metal-capable devices, iPhone 6 and later). PVRTC is deprecated — Apple dropped dedicated PVRTC hardware decompression in recent GPU generations. Do not use PVRTC for new projects.
 - **Nintendo Switch**: ASTC is the primary format
 
 **MIP map policy:**

package/content/knowledge/game/game-audio-design.md

@@ -22,7 +22,7 @@ Both Wwise and FMOD are professional audio middleware that replace the engine's
 
 **Wwise:**
 - Steeper learning curve; full productivity takes weeks of training
-- More complex licensing (free under $150K budget with limited sound count; tiered pricing above)
+- More complex licensing (free for non-commercial use and projects under revenue thresholds set by Audiokinetic; commercial pricing based on project budget tier — verify current thresholds at audiokinetic.com as these shift periodically)
 - Industry standard for AAA — most senior audio programmers have Wwise experience
 - Superior spatial audio with Wwise Spatial Audio including room/portal modeling
 - More powerful interactive music system (Music Segments, Stingers, Transitions)
@@ -108,6 +108,8 @@ Adaptive music responds to gameplay state in real-time, creating a dynamic sound
 
 **Implementation pattern:**
 
+The following example uses Unity + FMOD, but the pattern is engine-agnostic: create a persistent music event, drive parameters (intensity, danger) from gameplay state, and smooth parameter transitions. In Unreal, use FMOD or Wwise UE plugin with Blueprint-exposed parameters. In Godot, use AudioStreamPlayer with custom properties driven by game state, or integrate FMOD via GDNative. The core pattern — a persistent music controller receiving gameplay state updates — is identical across engines.
+
 ```csharp
 // Adaptive music controller — vertical layering with FMOD parameters
 // Attach to a persistent game object that survives scene loads

package/content/knowledge/game/game-design-document.md

@@ -39,6 +39,15 @@ The core loop is the fundamental cycle of actions the player repeats most freque
 
 A core loop is healthy when: every action has visible feedback within 200ms, outcomes feel proportional to skill/effort, and the loop itself is satisfying even without meta-progression.
 
+### Genre-Specific Loop Patterns
+
+The Input → Rules → Outcome → Feedback model applies universally, but timing and metrics vary by genre:
+
+- **Turn-based loop**: Observe → Plan → Commit → Resolve → Evaluate. Feedback latency is irrelevant; decision quality and information clarity are the metrics. Each turn should present a meaningful choice with visible consequences.
+- **Narrative loop**: Read/Watch → Choice → Consequence → Reveal → React. Pacing metric: decision points every 5-10 minutes of content. Consequence visibility: player should understand within 1-2 scenes how their choice affected the narrative.
+- **Management loop**: Monitor → Prioritize → Allocate → Wait → Evaluate. Session metric: one complete evaluate cycle per 15-30 minutes. Feedback: dashboard showing resource trends, not just current values.
+- **Puzzle loop**: Observe state → Hypothesize → Test → Success/Adjust. 'Aha moment' density: 1-2 per puzzle. Difficulty curve: each puzzle should be solvable in 1-5 minutes at target difficulty.
+
 ### Mechanics Documentation
 
 Every mechanic in the GDD must be documented with four components: inputs (what the player controls), rules (how the system resolves actions), outputs (what changes), and feedback (how the player perceives the change). Mechanics without all four components are incomplete and will be implemented inconsistently.

package/content/knowledge/game/game-domain-patterns.md

@@ -28,6 +28,8 @@ Games are split into two architectural layers that demand different modeling app
 
 **Do NOT mix these within a layer.** ECS in the meta-game layer creates anemic data bags with scattered business logic. DDD in the simulation layer creates cache-hostile object graphs that kill frame rates. Each paradigm is correct for its layer and wrong for the other.
 
+**Engine architecture note:** The pure ECS pattern (entities as IDs, components as data bags, systems as external functions) applies directly to ECS-first frameworks: Unity DOTS, Bevy, Flecs, and custom engines. Unreal Engine uses an Actor-Component model where Actors own Components with behavior — this is closer to OOP with composition than data-oriented ECS. Do not force pure ECS onto Unreal; instead, use Unreal's native Actor-Component model for gameplay systems and apply DDD patterns to meta-game layers (GameInstance, subsystems, save state). Godot uses a Node/Scene composition model with signals — apply the simulation/meta-game separation principle using Godot's native patterns rather than importing ECS concepts.
+
 ### Game State Machines
 
 State machines are the universal pattern in game development. They appear at every scale:

package/content/knowledge/game/game-engine-selection.md

@@ -106,7 +106,7 @@ criteria:
 
   - name: "License Cost"
     weight: 2
-    unity: 3       # Free tier, then subscription; runtime fee (post-2024)
+    unity: 3       # Free tier (Unity Personal), then subscription (Plus/Pro); runtime fee rescinded September 2024, reverted to seat-based licensing
     unreal: 4      # Free until $1M revenue, then 5% royalty
     godot: 5       # MIT license, completely free forever
     custom: 5      # No license cost (but massive dev cost)
@@ -126,7 +126,7 @@ criteria:
 
 **Weaknesses:**
 - Rendering quality historically trails Unreal for AAA-grade visuals (HDRP narrows this gap)
-- Runtime fee model introduced uncertainty (Unity responded to backlash but trust was damaged)
+- Runtime fee was announced September 2023, rescinded September 2024 under new leadership with return to seat-based licensing — but the episode damaged developer trust and prompted some studios to migrate to other engines
 - Legacy code and architectural debt in some subsystems (old Input System, UI systems, networking)
 - DOTS/ECS is powerful but has had a long and unstable development path
 

package/content/knowledge/game/game-input-systems.md

@@ -355,3 +355,25 @@ Input latency is the time from the player pressing a button to the corresponding
 - Use "late latch" techniques: update camera/aim after the final input poll, just before GPU submission
 - On PC, support NVIDIA Reflex / AMD Anti-Lag for driver-level latency reduction
 - Measure with a high-speed camera (240+ fps) pointed at the display while pressing a button connected to an LED — count frames between LED and screen change
+
+## Genre-Specific Input Patterns
+
+### Touch and Mobile Input
+
+Beyond minimum target sizes (44x44pt iOS, 48x48dp Android), mobile games need:
+
+- **Virtual joystick**: Floating (appears at touch point) preferred over fixed. Dead zone: 10-15% of joystick radius. Visual feedback: thumb indicator follows touch position.
+- **Gesture recognition**: Swipe threshold 50-100px to distinguish from taps. Multi-touch: track up to 5 simultaneous touches for action games, 2 for casual.
+- **Auto-play patterns**: Common in mobile RPGs — tap to toggle auto-battle with manual override for skills. Implement as a state machine: Manual → Auto → Manual on any input.
+- **Portrait vs landscape**: Design thumb-zone heat maps for each orientation. Critical actions within 60px of bottom corners.
+
+### Strategy and Management Input
+
+- **Box-select**: Click-drag rectangle, select all units inside. Add to selection with Shift+click. Deselect with right-click on empty space.
+- **Command queuing**: Shift+right-click appends to command queue. Display queue as waypoint markers. Max queue depth: 10-20 commands.
+- **Camera controls**: Edge scroll (mouse at screen edge), WASD pan, middle-mouse drag. Zoom: scroll wheel with min/max zoom limits. Minimap click-to-jump.
+
+### Turn-Based Input
+
+- **Select-confirm pattern**: Click to select, click again to confirm. Show preview of action result before confirmation. Undo: allow undo of last action if turn is not yet submitted.
+- **Hover-preview**: On hover, show range/area-of-effect highlight. On select, show detailed outcome prediction.

package/content/knowledge/game/game-level-content-design.md

@@ -453,3 +453,31 @@ Every level should have a design document before construction begins.
 - **Audio direction notes**: Ambient soundscape, music transitions, key audio events
 - **Unique mechanics**: Any level-specific mechanics (vehicles, zero-gravity, underwater) with design notes
 - **Dependencies**: What player abilities are required? What story prerequisites must be met?
+
+## 2D and Non-3D Level Design
+
+### 2D Platformer Metrics
+
+The design unit for 2D platformers is the screen or screen segment, not 3D meters:
+
+- **Screen dimensions**: Design at target resolution (e.g., 1920x1080). One screen = one design unit.
+- **Tile grid**: Standard tile size 16x16, 32x32, or 64x64 pixels. Character occupies 1-2 tiles wide, 2-3 tiles tall.
+- **Jump arc**: Defined by initial velocity and gravity. Standard platformer: peak height = 3-5 tiles, horizontal distance = 4-8 tiles. Coyote time: 6-10 frames (100-167ms at 60fps).
+- **Platform spacing**: Safe gap = 60-80% of max jump distance. Challenge gap = 85-95%. Death gap = 100%+.
+- **Enemy placement**: One new mechanic or enemy per 3-5 screens. Tutorial screens introduce mechanics in isolation before combining.
+
+### Tile-Based Level Design
+
+For grid-based games (roguelikes, tactics, puzzle games):
+
+- **Room generation**: Define room templates as rectangles with connection points. Minimum room size: 5x5 tiles. Maximum: 15x15 for tactical games. Connect rooms via corridors 1-3 tiles wide.
+- **Difficulty distribution**: In procedural dungeon generation, difficulty increases with distance from start. Use weighted room selection: rooms with harder enemies have higher weight at greater distances.
+- **Puzzle stage design**: Each stage introduces one new mechanic. Progression: tutorial (1 mechanic, 1 solution), practice (1 mechanic, multiple applications), combination (2+ mechanics together), mastery (all mechanics under constraint).
+
+### Non-Spatial Content Design
+
+For games without spatial levels (card games, visual novels, management sims):
+
+- **Card game stage progression**: Introduce card types gradually. New card pool expansion every 3-5 encounters. Total card pool at launch: 100-300 for competitive, 50-100 for single-player.
+- **Visual novel branching**: Key decision points every 5-10 minutes of reading. Total playthrough length: 2-4 hours per route. Route count: 3-5 for manageable scope. Flag variable tracking: use boolean flags + integer counters, avoid floating-point relationship values.
+- **Management sim progression**: Unlock new building/unit types every 15-30 minutes of play. Each unlock should enable at least one new strategy the player couldn't execute before.

package/content/knowledge/game/game-networking.md

@@ -313,6 +313,8 @@ Lockstep is an alternative to client-server prediction that is deterministic: al
 **Requirements:**
 - The simulation must be perfectly deterministic: same inputs must produce bit-identical outputs on all platforms
 - Floating-point determinism is extremely hard across different CPUs and compilers — many lockstep games use fixed-point math
+
+**Fixed-point math implementation:** Use a Q16.16 or Q32.32 fixed-point representation for all game state calculations in lockstep systems. Libraries: libfixmath (C), FixedMath.Net (C#). All trigonometric functions must use lookup tables or polynomial approximations — never call platform math libraries (sin, cos, sqrt) as these are not deterministic across platforms. Performance cost: fixed-point is typically 2-5x slower than hardware float but eliminates desync bugs entirely.
 - A single desync (one client computes a different result) is catastrophic — desyncs must be detected (via state hash comparison) and recovered from (resync or disconnect)
 
 **Rollback networking (GGPO):**

package/content/knowledge/game/game-performance-budgeting.md

@@ -52,6 +52,15 @@ Memory budgets must be subdivided by subsystem: textures (typically 40–60% of
 - **Shader complexity**: Measure in GPU ms per material; flag any material exceeding 0.5 ms in isolation
 - **Post-processing**: Budget 2–4 ms total for all post-process effects combined
 
+### 2D and Non-3D Performance Budgets
+
+2D games have different bottlenecks than 3D:
+
+- **Sprite batch count**: Target 50-200 draw calls. Each atlas page = 1 batch. Minimize atlas count by grouping co-rendered sprites.
+- **Fill rate**: Overdraw from layered sprites is the primary 2D GPU cost. Target < 4x overdraw. Transparent sprites are expensive — use opaque where possible.
+- **Particle count (2D VFX)**: Budget 200-500 active particles for mobile, 1,000-2,000 for PC.
+- **UI-heavy games** (visual novels, card games): UI element count < 500 visible, text rendering budget < 2ms, animation/tween count < 100 simultaneous.
+
 ### Loading Time Targets
 
 - **Initial boot to menu**: Under 10 seconds on console (platform certification requirement areas)
@@ -68,6 +77,8 @@ Mobile devices throttle CPU and GPU when they overheat. A game that runs at 60 f
 - Budget power draw to allow 2–3 hours of gameplay per charge
 - Reduce target frame rate to 30 fps on mobile unless the game genre demands 60 fps
 
+**Concrete mobile thermal targets:** Typical thermal throttle onset at 40-42°C skin temperature (varies by device). Sustainable GPU utilization: 50-60% of peak — not 100%. Power draw targets: 3W sustained for phone games (~3hr on 4000mAh battery), 5W for tablet. Monitor with Android `dumpsys thermalservice` or iOS `ProcessInfo.ThermalState`. At `.serious` thermal state, reduce render resolution by 25% and particle count by 50%.
+
 ## Deep Guidance
 
 ### Frame Budget Allocation Template

package/content/knowledge/game/game-save-systems.md

@@ -325,7 +325,7 @@ Each platform has unique requirements that affect save system design:
 
 **Nintendo Switch:**
 - Save data uses the Nintendo save data API
-- Strict save data size limits (varies by title approval, typically 32 MB–256 MB)
+- Strict save data size limits: Default allocation for most titles is 32 MB total (all save slots combined). Larger allocations (up to 256 MB) require explicit approval from Nintendo during title registration and must be justified. Design for 32 MB as the baseline constraint.
 - No cloud save backup for non-Nintendo Switch Online subscribers
 - Save data is bound to the console, not the user (complicates console transfer scenarios)
 - The game must implement its own backup strategy since the platform provides limited protection

package/content/knowledge/game/game-ui-patterns.md

@@ -64,6 +64,8 @@ Controller navigation requires explicit focus management — there is no cursor
 
 Controller navigation requires a focus system that tracks which UI element is currently selected and handles directional input to move focus.
 
+**Engine-native support:** Unreal's UMG provides focus navigation through the CommonUI plugin with built-in gamepad navigation, focus flow, and input routing. Godot's Control nodes have built-in `focus_neighbor` properties for D-pad navigation. Unity requires explicit focus management through EventSystem or custom solutions. Use engine-native solutions where available, falling back to custom implementation only for complex navigation flows. The pattern below demonstrates manual focus management for reference.
+
 ```csharp
 // FocusManager.cs — Controller-first UI focus management
 // Attach to a root UI canvas; manages focus across all child elements

package/content/knowledge/game/game-vr-ar-design.md

@@ -12,7 +12,7 @@ VR and AR development is fundamentally constrained by human physiology in ways t
 
 VR has the most demanding performance requirements in real-time rendering because dropped frames directly cause motion sickness:
 
-- **Quest 3 / Quest Pro**: 72 Hz or 90 Hz (90 Hz strongly recommended). Per-eye resolution: 2064x2208. Total pixels per frame: ~9.1 million (both eyes). GPU: Mobile Adreno, roughly equivalent to a 2018 mid-range phone GPU.
+- **Quest 3 / Quest Pro**: 72 Hz or 90 Hz (90 Hz strongly recommended). Per-eye resolution: 2064x2208. Total pixels per frame: ~9.1 million (both eyes). GPU: Qualcomm Adreno 740 (Snapdragon XR2 Gen 2), roughly equivalent to a 2022 flagship phone GPU (Snapdragon 8 Gen 1 class). Significantly more capable than Quest 2's XR2 Gen 1 but still mobile-tier — expect 10-20% of a current desktop GPU's fill rate.
 - **PlayStation VR2**: 90 Hz or 120 Hz. Per-eye resolution: 2000x2040. Total pixels: ~8.2 million. GPU: PS5 AMD RDNA2 — much more capable than Quest but still must hit 90+ Hz.
 - **PC VR (Valve Index, Pimax)**: 90 Hz, 120 Hz, or 144 Hz. Per-eye resolution varies (Index: 1440x1600). GPU: Desktop RTX-class, but driving high refresh rates at high resolution is still demanding.
 - **Apple Vision Pro**: 90 Hz with dynamic foveated rendering. Per-eye resolution: ~3660x3200. GPU: M2+R1 chip with dedicated real-time sensor processing.

package/content/knowledge/review/review-game-ui.md

@@ -0,0 +1,293 @@
+---
+name: review-game-ui
+description: Failure modes and review passes specific to game UI specifications — HUD hierarchy, menu navigation, controller accessibility, settings coverage, FTUE effectiveness, state machine completeness, and platform shell compliance
+topics: [game-dev, review, ui, hud, menus, controller, accessibility, ftue]
+---
+
+# Review: Game UI Specification
+
+A game UI specification must translate game mechanics into clear, navigable, accessible interfaces. It must be hierarchical (HUD elements prioritized by gameplay criticality), complete (every menu has a path back, no dead ends), accessible (every screen reachable with controller), configurable (settings cover graphics, audio, controls, accessibility), and platform-compliant (system UI respects console certification requirements). This review uses 7 passes targeting the specific ways game UI specifications fail.
+
+Follows the review process defined in `review-methodology.md`.
+
+## Summary
+
+- **Pass 1 — HUD Information Hierarchy**: HUD elements are prioritized by gameplay criticality; health, ammo, and objective markers are visible at a glance; non-critical information is layered or hidden behind contextual triggers.
+- **Pass 2 — Menu Completeness & Navigation**: Every menu has a path back, no dead ends exist, breadcrumb trail is clear, and the menu tree covers all player-facing systems without orphaned screens.
+- **Pass 3 — Controller Accessibility**: Every screen is reachable with D-pad, focus order follows spatial layout, shoulder buttons switch tabs, and no interaction requires mouse/touch to complete.
+- **Pass 4 — Settings Coverage**: Graphics, audio, controls, and accessibility settings are present with appropriate ranges; no critical setting is missing; defaults are sensible for target hardware.
+- **Pass 5 — FTUE Effectiveness**: Tutorial teaches core mechanics without blocking progress; skip option is available; re-access to tutorial information exists; no mechanic requires undocumented player discovery.
+- **Pass 6 — UI State Machine Completeness**: Every UI state has defined entry and exit conditions; no orphan states exist; all transitions are handled including error, disconnect, and loading states.
+- **Pass 7 — Platform Shell Compliance**: System UI respects platform conventions (PS button, Xbox guide, Switch home); notification handling is specified; console certification UI requirements are addressed.
+
+## Deep Guidance
+
+---
+
+## Pass 1: HUD Information Hierarchy
+
+### What to Check
+
+HUD elements are prioritized by gameplay criticality. Health, ammo, objective markers, and minimap are visible at a glance without eye movement from the center of the screen. Non-critical information (XP progress, currency, social notifications) is layered — hidden by default and surfaced contextually. The HUD does not present more than 5-7 simultaneous elements during active gameplay.
+
+### Why This Matters
+
+HUD overload causes players to miss critical gameplay information. When health, ammo, minimap, quest tracker, XP bar, currency, social notifications, buff timers, and cooldown indicators all compete for attention simultaneously, players die because they did not notice their health was low — the information was there, but buried in noise. Conversely, a HUD that hides too much forces players to open menus mid-combat. The hierarchy must match gameplay criticality.
+
+### How to Check
+
+1. List every HUD element and classify as critical (player dies without it), important (gameplay quality degrades without it), or contextual (useful but not time-sensitive)
+2. Verify critical elements are visible without eye movement from screen center — use screen quadrant analysis
+3. Check that contextual elements have defined show/hide triggers (e.g., XP bar appears for 3 seconds after earning XP, then fades)
+4. Count simultaneous elements during peak gameplay — more than 7 concurrent elements indicates overload
+5. Cross-reference with GDD mechanics: every mechanic with player-visible feedback must have a corresponding HUD element
+6. Verify HUD scales with resolution — elements positioned by percentage, not fixed pixels
+7. Check for HUD customization: can the player move, resize, or hide HUD elements?
+
+### What a Finding Looks Like
+
+- P0: "Health indicator is positioned in the bottom-left corner, 800+ pixels from screen center. In fast-paced combat, players must look away from the action to check health. Health must be near the reticle or use screen-edge vignette effects."
+- P1: "14 HUD elements are visible simultaneously during combat. This exceeds cognitive load limits. Non-critical elements (XP bar, currency, social notifications) should be contextual, not persistent."
+- P2: "HUD layout is specified in fixed pixel coordinates (health at 50,720). This will break at non-1080p resolutions. Use percentage-based or anchor-based positioning."
+- P3: "HUD element for combo counter exists but no fade timing is specified. Define how long the counter persists after the last hit (recommended: 3-5 seconds)."
+
+---
+
+## Pass 2: Menu Completeness & Navigation
+
+### What to Check
+
+Every menu screen has a clear path back to the parent screen. No dead-end screens exist (screens with no exit path). The breadcrumb trail is visible at all times. The menu tree covers all player-facing systems (inventory, settings, social, store, leaderboards, achievements) without orphaned screens that are reachable only through obscure paths.
+
+### Why This Matters
+
+Incomplete menu trees strand players. A settings screen with no back button forces the player to restart the game. A crafting menu reachable only through a specific NPC but not from the inventory screen creates confusion. Players who cannot find a feature assume it does not exist — a hidden feature is a missing feature. Menu navigation should be exhaustively mapped, not discovered through play.
+
+### How to Check
+
+1. Build a complete menu tree from the UI spec — every screen, every transition, every button
+2. Verify every screen has a back/escape path — no leaf node should be inescapable
+3. Check for orphaned screens: screens not reachable from the main menu or hub screen through documented navigation
+4. Verify breadcrumb visibility: does the player always know where they are in the menu hierarchy?
+5. Check for consistent navigation patterns: does "B button" always mean "back"? Does "Start" always open the pause menu?
+6. Verify that all player-facing systems appear in the menu tree: inventory, settings, social, store, map, journal, achievements, leaderboards, help
+7. Check menu depth: menus deeper than 3 levels should be reconsidered — deep menus hide features
+
+### What a Finding Looks Like
+
+- P0: "The crafting submenu has no back button or escape path. Once entered through the NPC dialog, the only exit is closing the game. The screen is inescapable."
+- P1: "Accessibility settings are nested under Gameplay > Advanced > Accessibility — 3 levels deep. Players who need these settings most are least likely to find them. Move to a top-level settings tab."
+- P2: "Leaderboard screen is reachable from the post-match screen but not from the main menu. Players cannot browse leaderboards outside of match flow."
+- P3: "Menu transition animations are not specified. Define whether transitions are instant, slide, or fade and their duration (recommended: 150-250ms)."
+
+---
+
+## Pass 3: Controller Accessibility
+
+### What to Check
+
+Every screen is fully navigable with a gamepad D-pad. Focus order follows spatial layout (left-to-right, top-to-bottom). Shoulder buttons switch between tabs. No interaction requires a mouse pointer, touch input, or keyboard to complete. Focus indicators are clearly visible with sufficient contrast.
+
+### Why This Matters
+
+Console games and PC games with controller support must be fully navigable without a mouse. A single screen that requires mouse input breaks the controller experience entirely — the player must put down their controller, find their mouse, click, and pick the controller back up. This is a console certification failure for PlayStation, Xbox, and Nintendo platforms. Even on PC, controller users expect full navigation support.
+
+### How to Check
+
+1. For every screen, verify that all interactive elements are reachable via D-pad navigation
+2. Check focus order: does it follow spatial layout? (Left-to-right, top-to-bottom, matching visual hierarchy)
+3. Verify tab switching: shoulder buttons (L1/R1 or LB/RB) switch between tabs in tabbed interfaces
+4. Check that focus indicator is clearly visible: minimum 3px border or highlight with 4.5:1 contrast ratio
+5. Verify that no interaction requires a cursor: dropdowns, sliders, text input, scrolling all work with D-pad
+6. Check for focus traps: UI elements that capture focus and prevent D-pad navigation away (common with custom widgets)
+7. Verify that wrapping behavior is consistent: does D-pad right on the last column wrap to the first column of the next row, or stop?
+
+### What a Finding Looks Like
+
+- P0: "The server browser uses a mouse-driven scrollable list with no D-pad navigation. Controller users cannot select a server. This is a console certification blocker."
+- P0: "Text input for player name uses a mouse-clickable keyboard with no controller support. Console players cannot complete account creation."
+- P1: "Focus order in the inventory grid goes left-to-right then jumps to a panel on the right, skipping the second row. Focus order does not match spatial layout."
+- P2: "Focus indicator is a 1px white border on a light gray background. Contrast ratio is approximately 1.5:1 — below the 4.5:1 minimum for visibility."
+
+---
+
+## Pass 4: Settings Coverage
+
+### What to Check
+
+Settings screen covers all five minimum categories: graphics/video, audio, controls/input, gameplay, and accessibility. Each category has appropriate settings with sensible ranges. No critical setting is missing (resolution, volume, subtitle toggle, colorblind mode, control remapping). Default values are appropriate for target hardware.
+
+### Why This Matters
+
+Missing settings force players to accept defaults that may not suit their hardware, preferences, or needs. A game without a resolution setting alienates players with non-standard monitors. A game without subtitle options excludes deaf and hard-of-hearing players. A game without control remapping fails accessibility standards (and Xbox/PS certification). Settings are not optional features — they are baseline requirements.
+
+### How to Check
+
+1. Verify graphics settings: resolution, display mode (fullscreen/windowed/borderless), frame rate cap, V-sync, quality presets, individual quality settings (textures, shadows, anti-aliasing, draw distance)
+2. Verify audio settings: master volume, music volume, SFX volume, voice volume, subtitle toggle, subtitle size, audio output selection
+3. Verify control settings: control remapping, sensitivity sliders (camera, aim), invert Y-axis, vibration toggle, dead zone adjustment
+4. Verify accessibility settings: colorblind mode (protanopia, deuteranopia, tritanopia), font scaling, screen reader support, reduced motion, high contrast mode
+5. Verify gameplay settings: difficulty selection (if applicable), HUD customization, language selection, camera distance
+6. Check setting ranges: sensitivity sliders should have wide enough ranges (not just 1-10 but 0.1-5.0 or similar), resolution should include common values
+7. Verify that changed settings are previewed in real-time where possible (audio slider plays a sample, graphics changes show before confirm)
+
+### What a Finding Looks Like
+
+- P0: "No control remapping exists. Players who cannot use the default layout due to physical disabilities are locked out. This is an accessibility requirement and a platform certification blocker."
+- P0: "No subtitle toggle exists. Deaf and hard-of-hearing players cannot follow narrative content. This is an accessibility baseline."
+- P1: "Colorblind mode is listed as 'colorblind: on/off' without specifying which type. Protanopia, deuteranopia, and tritanopia require different palette adjustments — a single toggle is insufficient."
+- P2: "Graphics quality has 3 presets (Low, Medium, High) but no individual settings. Players with specific hardware constraints cannot optimize (e.g., low shadows but high textures)."
+- P3: "Audio settings do not include a 'dialogue boost' option. While not required, this is a common accessibility feature that improves clarity for hearing-impaired players."
+
+---
+
+## Pass 5: FTUE Effectiveness
+
+### What to Check
+
+The First Time User Experience (FTUE) teaches all core loop mechanics without blocking player progress. A skip option is available for returning players or replays. Tutorial information is re-accessible after completion (help menu, practice mode, or tooltip system). No core mechanic requires the player to discover it without guidance.
+
+### Why This Matters
+
+A bad FTUE either overwhelms (teaching every system in the first 10 minutes) or under-teaches (leaving players to discover critical mechanics by accident). Both cause churn: overwhelmed players quit because the game feels complex, under-taught players quit because they feel lost. The FTUE must pace instruction to match the player's cognitive load, teach mechanics in context (during gameplay, not via text walls), and provide an escape hatch for experienced players who do not need hand-holding.
+
+### How to Check
+
+1. List every core loop mechanic — movement, combat, inventory, crafting, social, economy
+2. Verify each mechanic has a tutorial moment: in-context prompt, guided task, or practice scenario
+3. Check tutorial pacing: no more than 2-3 new mechanics introduced per tutorial segment
+4. Verify skip option: can the player skip the entire tutorial? Individual tutorial steps? Is the skip accessible from the first prompt?
+5. Check for re-access: after completing the tutorial, can the player re-read instructions? Is there a help menu, codex, or practice mode?
+6. Verify that the tutorial does not block progress: can the player proceed if they fail a tutorial challenge? Is there a retry with hints?
+7. Check for advanced mechanics: are they taught later in gameplay (progressive disclosure) or dumped in the opening tutorial?
+
+### What a Finding Looks Like
+
+- P0: "Combat tutorial requires the player to defeat a training dummy to proceed, but no hint system exists if the player fails 3+ times. A player who cannot complete the tutorial is permanently stuck."
+- P1: "Crafting system is never taught. The player must discover it by opening the inventory and finding a 'Craft' tab. 60% of players may never discover this core system."
+- P1: "All 8 core mechanics are taught in a single 25-minute unskippable tutorial. Player drop-off during tutorials longer than 10 minutes exceeds 40%."
+- P2: "Tutorial is skippable but no help menu or re-access exists. A player who skips the tutorial and later needs guidance has no recourse."
+
+---
+
+## Pass 6: UI State Machine Completeness
+
+### What to Check
+
+Every UI state has defined entry conditions, exit conditions, and transitions to other states. No orphan states exist (states with no entry path). No terminal states exist except intentional ones (quit game). Error states, disconnect states, and loading states are explicitly handled. State transitions are deterministic — no ambiguous transitions where two states compete.
+
+### Why This Matters
+
+Incomplete UI state machines are the primary source of UI softlocks — states the player enters but cannot exit. When the game shows a loading screen but the load fails silently, the player is stuck forever. When a disconnect occurs during a menu transition, the UI may be in an undefined state. When a modal dialog opens on top of another modal, focus may be lost. Every state transition must be mapped, including the error and edge-case transitions that are easy to forget.
+
+### How to Check
+
+1. List every UI state: main menu, loading, in-game HUD, pause menu, inventory, settings, store, matchmaking, post-match, error dialog, disconnect overlay
+2. For each state, define: what triggers entry? What triggers exit? What are all possible transitions?
+3. Check for orphan states: states that exist in the design but have no defined entry path
+4. Check for softlock potential: states that can be entered but have no exit transition (especially error states)
+5. Verify loading states: every loading screen has a timeout and error fallback (not infinite spin)
+6. Check disconnect handling: every state has a defined behavior when network connectivity is lost
+7. Verify modal stacking: what happens when a system notification triggers while a game dialog is open? Is there a priority queue?
+
+### What a Finding Looks Like
+
+- P0: "Loading screen has no timeout. If asset loading fails silently, the player is stuck on the loading screen indefinitely with no error message and no exit path."
+- P0: "Matchmaking state has no cancel button. Once matchmaking begins, the player cannot return to the main menu without force-quitting the application."
+- P1: "Disconnect during inventory management is not specified. If the server connection drops while the player has the inventory open, the UI state is undefined — does it close the inventory? Show an error? Return to main menu?"
+- P2: "No modal priority system is defined. If a system notification, a party invite, and a trade request arrive simultaneously, the stacking behavior is unspecified."
+
+---
+
+## Pass 7: Platform Shell Compliance
+
+### What to Check
+
+System UI respects platform conventions for PlayStation (PS button returns to system menu), Xbox (Guide button returns to dashboard), and Nintendo Switch (Home button returns to system). Notification handling is specified — game does not block or interfere with system notifications. Console certification UI requirements (save icon display, mandatory legal notices, suspend/resume behavior) are addressed.
+
+### Why This Matters
+
+Platform shell compliance is a hard certification requirement. A game that does not properly handle the PS button, fails to display the mandated save icon, or interferes with system notifications will fail certification and cannot ship on that platform. These requirements are non-negotiable and documented in each platform's Technical Requirements Checklist (TRC for PlayStation, Xbox Requirements for Xbox, Lotcheck for Nintendo). Failing certification delays launch by weeks to months.
+
+### How to Check
+
+1. Verify system button handling: PS button, Xbox Guide button, Switch Home button all behave per platform spec
+2. Check suspend/resume: game correctly saves state and resumes when the player leaves and returns
+3. Verify save icon display: a save icon is displayed whenever the game writes to persistent storage (platform requirement)
+4. Check mandatory legal notices: EULA, privacy policy, and age rating screens appear per platform requirements
+5. Verify notification handling: system notifications (friend online, message received, download complete) display correctly over the game UI
+6. Check for account switching: what happens if the user switches accounts mid-game? (Platform-specific requirements)
+7. Verify that game UI does not render in platform-reserved screen areas (safe zone compliance)
+
+### What a Finding Looks Like
+
+- P0: "No suspend/resume handling is specified. On PS5, pressing the PS button and returning to the game may result in a broken state. Suspend/resume is a mandatory TRC requirement."
+- P0: "Save icon display is not specified. PlayStation TRC requires a visible save indicator whenever writing to storage. Failure is an automatic certification rejection."
+- P1: "System notification handling is not addressed. If a friend-request notification appears during a full-screen cinematic, the behavior is undefined. Specify whether the game pauses, overlays, or queues."
+- P2: "Safe zone compliance is not documented. UI elements placed within 5% of screen edges may be clipped on some displays. Platform safe zone guidelines require all critical UI within the 90% safe area."
+
+---
+
+## Finding Template
+
+Use this template for all game UI review findings:
+
+```markdown
+### Finding: [Short description of the issue]
+
+**Pass:** [Pass number] — [Pass name]
+**Priority:** P0 | P1 | P2 | P3
+**Location:** [UI spec section and screen/element]
+
+**Issue:** [Specific description of what is wrong, with references to the UI spec text.
+Avoid subjective language — state the structural problem.]
+
+**Evidence:** [Quote or reference the specific UI spec content that demonstrates the issue.
+For navigation findings, show the broken path. For accessibility findings, show the
+non-compliant element. For state machine findings, show the missing transition.]
+
+**Impact:** [What goes wrong during implementation or certification if this is not fixed.
+Be specific: "controller users cannot reach this screen" or "certification will fail on
+PlayStation" or "players will softlock on this screen."]
+
+**Recommendation:** [Concrete action to resolve the finding. Not "improve navigation" but
+"add D-pad focus support to the server browser list — each row is a focusable element,
+D-pad up/down moves between rows, A/X button selects."]
+
+**Trace:** [Which downstream artifacts, screens, or certification requirements are affected]
+```
+
+### Example Finding
+
+```markdown
+### Finding: Server browser has no controller navigation — console certification blocker
+
+**Pass:** 3 — Controller Accessibility
+**Priority:** P0
+**Location:** UI Spec Section 5.2 "Server Browser"
+
+**Issue:** The server browser screen uses a mouse-driven scrollable list with
+hover-to-select interaction. No D-pad navigation, focus indicators, or
+controller bindings are specified. Controller users cannot select a server,
+making the multiplayer flow inaccessible on gamepad.
+
+**Evidence:** UI Spec Section 5.2: "Server list displays available servers in a
+scrollable table. Player clicks a row to select, double-clicks to join."
+No controller input is mentioned. No focus indicator design is shown.
+
+**Impact:** Console certification will fail — every screen must be fully navigable
+with a gamepad. PC controller users cannot access multiplayer. This blocks the
+entire online flow for controller input.
+
+**Recommendation:** Add D-pad navigation to the server list:
+  - Each server row is a focusable element
+  - D-pad up/down moves focus between rows
+  - A button (Xbox) / X button (PS) selects the focused row
+  - X button (Xbox) / Square button (PS) opens server details
+  - Focus indicator: 3px highlight border with team accent color
+  - L1/R1 switch between server list tabs (All, Favorites, Recent)
+
+**Trace:** UI Spec 5.2 → blocks multiplayer-flow.md controller path,
+console-certification.md TRC 3.12 (controller navigation), QA test plan
+controller coverage
+```

package/content/pipeline/architecture/netcode-spec.md

@@ -7,7 +7,7 @@ order: 715
 dependencies: [system-architecture]
 outputs: [docs/netcode-spec.md]
 conditional: "if-needed"
-reads: [tech-stack, performance-budgets]
+reads: [tech-stack, performance-budgets, game-design-document]
 knowledge-base: [game-networking]
 ---
 

package/content/pipeline/architecture/review-netcode.md

@@ -7,7 +7,7 @@ order: 716
 dependencies: [netcode-spec]
 outputs: [docs/reviews/architecture-review-netcode.md]
 conditional: "if-needed"
-reads: []
+reads: [performance-budgets, system-architecture, game-design-document]
 knowledge-base: [review-netcode, review-step-template, multi-model-review-dispatch]
 ---
 
@@ -54,8 +54,8 @@ Skip when: netcode-spec is skipped (i.e., `multiplayerMode` is `none` or
 
 ## Methodology Scaling
 - **deep**: All 7 review passes (Latency Tolerance, Bandwidth Compliance,
-  Cheat Surface Audit, Determinism Verification, Connection Edge Cases,
-  Serialization Size Audit, Architecture Cross-Reference). Multi-model
+  Cheat Surface Audit, Determinism Verification, Disconnect/Reconnect Handling,
+  Matchmaking Fairness Assessment, Bandwidth Spike Resilience). Multi-model
   review dispatched to Codex and Gemini if available, with graceful fallback
   to Claude-only enhanced review.
 - **mvp**: Three passes — Latency Tolerance, Bandwidth Compliance, and Cheat

package/content/pipeline/foundation/performance-budgets.md

@@ -22,7 +22,7 @@ the system, its allocation, rationale, measurement method, and alert threshold
 so that performance regressions are caught automatically.
 
 ## Inputs
-- docs/game-design-document.md (required) — core systems, target platforms,
+- docs/game-design.md (required) — core systems, target platforms,
   visual fidelity targets, multiplayer scope
 - docs/tech-stack.md (required) — engine, renderer, target hardware, platform
   SDK constraints

package/content/pipeline/pre/game-design-document.md

@@ -38,6 +38,7 @@ narrative detail are covered by separate downstream steps.
 - (deep) Progression systems define XP/level curves or equivalent with explicit formulas
 - (deep) Achievements/trophies schema is present with unlock conditions
 - (deep) Competitive analysis references specific titles and structural differentiation
+- (deep) Feature priority matrix included (must-have, should-have, nice-to-have per milestone) and top-5 risk register with likelihood, impact, and mitigation strategies
 
 ## Methodology Scaling
 - **deep**: Full GDD bible. Design pillars with exclusion rationale, multi-tier

package/content/pipeline/quality/playtest-plan.md

@@ -7,7 +7,7 @@ order: 961
 dependencies: [game-design-document, user-stories]
 outputs: [docs/playtest-plan.md]
 conditional: null
-reads: []
+reads: [analytics-telemetry]
 knowledge-base: [game-testing-strategy, game-milestone-definitions]
 ---
 
@@ -47,6 +47,7 @@ design decisions rather than anecdotal impressions.
 - (deep) Playtest environment specification: hardware requirements, network conditions to simulate, build distribution method (Steam playtest, TestFlight, side-loading), telemetry collection during sessions
 - (deep) Playtest-to-design feedback loop: how findings are triaged (critical/major/minor), who owns resolution, turnaround time targets between playtest and design response
 - (deep) Accessibility playtest sessions: dedicated sessions with players using assistive technologies to validate accessibility features from game-accessibility spec
+- (deep) Telemetry integration specified: which analytics events are collected during playtest sessions, how automated metrics complement observer notes
 
 ## Methodology Scaling
 - **deep**: Full playtest plan covering all three tiers with detailed schedules,

package/content/pipeline/specification/art-bible.md

@@ -28,7 +28,7 @@ failures, performance regressions, and visual incoherence.
 ## Inputs
 - docs/game-design.md (required) — art style direction, world setting, character roster, environment types
 - docs/performance-budgets.md (required) — polygon budgets, texture memory budgets, draw call limits per platform
-- docs/content-structure-design.md (required) — content organization, asset directory structure, naming taxonomy
+- docs/content-structure/ (required) — content organization, asset directory structure, naming taxonomy
 - docs/plan.md (required) — target platforms informing quality tiers and LOD requirements
 
 ## Expected Outputs
@@ -36,7 +36,7 @@ failures, performance regressions, and visual incoherence.
   DCC pipeline, LOD strategy, Git LFS mapping, and collision layer definitions
 
 ## Quality Criteria
-- (mvp) Art style pillars defined with visual reference descriptions (mood, color palette, silhouette language, rendering style)
+- (mvp) Art style pillars defined with concrete specifications: color palette as hex/RGB ranges, character proportion ratios, material property ranges (roughness, metallic), and reference images or "do/don't" visual descriptions per asset category
 - (mvp) Per-type asset specs documented: 3D models (poly budget, texture resolution, material slots), 2D sprites (resolution, atlas packing, animation frames), VFX (particle count, draw call budget, shader complexity), animation (bone count, clip length, blend tree structure)
 - (mvp) Naming conventions defined per asset type following content-structure-design taxonomy
 - (mvp) DCC pipeline documented: source tool → export format → engine import → validation

package/content/pipeline/specification/audio-design.md

@@ -36,7 +36,7 @@ update mode.
 ## Inputs
 - docs/game-design.md (required) — mechanics, core loop, world setting, emotional tone informing audio direction
 - docs/performance-budgets.md (required) — audio memory budget, CPU budget for audio processing, streaming constraints
-- docs/content-structure-design.md (required) — audio asset directory structure, naming taxonomy
+- docs/content-structure/ (required) — audio asset directory structure, naming taxonomy
 - docs/plan.md (required) — target platforms informing loudness targets and format requirements
 - docs/narrative-bible.md (optional, forward-read) — character roster, dialogue structure, VO volume and language requirements
 
@@ -56,6 +56,7 @@ update mode.
 - (deep) Audio format matrix per platform: codec (Vorbis, Opus, ADPCM, platform-native), quality settings, streaming chunk size
 - (deep) Dynamic range management: compressor/limiter settings per bus, ducking rules (VO ducks music, gameplay SFX ducks ambient)
 - (deep) Accessibility audio: audio descriptions, mono downmix option, visual indicators for critical audio cues
+- (deep) SFX variation strategy documented: minimum variant count per sound event category, randomization rules (no-repeat, round-robin, weighted random), pitch and volume variation ranges
 
 ## Methodology Scaling
 - **deep**: Full audio design with style guide, complete SFX taxonomy with

package/content/pipeline/specification/content-structure-design.md

@@ -104,6 +104,7 @@ loop, and mechanics catalog.
 - (deep) Replayability analysis: what drives repeat engagement (procedural variety, optional objectives, difficulty modes)
 - (deep) Content pipeline documented: authoring workflow from design to engine-ready format
 - (deep) Pacing analysis with annotated intensity curves showing moment-to-moment and session-level rhythm
+- (mvp) Type-specific deliverable produced matching the identified content structure trait: level-designs.md (discrete), world-regions.md (open-world), generation-rulesets.md (procedural), escalation-bands.md (endless), or mission-templates.md (mission-based)
 
 ## Methodology Scaling
 - **deep**: Full content structure specification with all trait-specific

package/content/pipeline/specification/economy-design.md

@@ -66,6 +66,7 @@ content (no spending decisions) do not require a full economy design.
 - (deep) Legal compliance checklist per target market: probability disclosure requirements, age-gating, spending limits, loot box classification
 - (deep) Economy simulation spreadsheet or formula reference with tunable parameters for balance testing
 - (deep) Seasonal/live-service economy plan: event currencies, battle pass reward tracks, limited-time offers, FOMO management
+- (mvp) If the economy involves online transactions: server-authoritative transaction model specified — client cannot dictate transaction outcomes
 
 ## Methodology Scaling
 - **deep**: Full economy design with multi-currency architecture, faucet/sink

package/content/pipeline/specification/review-economy.md

@@ -7,7 +7,7 @@ order: 869
 dependencies: [economy-design]
 outputs: [docs/reviews/specification-review-economy.md]
 conditional: "if-needed"
-reads: []
+reads: [game-design-document]
 knowledge-base: [review-game-economy, review-step-template, multi-model-review-dispatch]
 ---
 
@@ -64,7 +64,7 @@ No economy design means no economy review.
 ## Methodology Scaling
 - **deep**: All 7 review passes (Inflation Trajectory, Exploit Vectors,
   Ethical Monetization, Pay-to-Win Detection, Legal Compliance,
-  Progression-Monetization Separation, Live-Service Sustainability).
+  Earn Rate vs Engagement Projection, Sink Effectiveness Analysis).
   Multi-model review dispatched to Codex and Gemini if available, with
   graceful fallback to Claude-only enhanced review.
 - **mvp**: Three passes — Inflation Trajectory, Exploit Vectors, and Ethical

package/content/pipeline/specification/review-game-ui.md

@@ -7,8 +7,8 @@ order: 864
 dependencies: [game-ui-spec]
 outputs: [docs/reviews/specification-review-game-ui.md]
 conditional: null
-reads: []
-knowledge-base: [review-game-design, game-accessibility, review-step-template, multi-model-review-dispatch]
+reads: [game-design-document, game-accessibility, input-controls-spec]
+knowledge-base: [review-game-ui, game-accessibility, review-step-template, multi-model-review-dispatch]
 ---
 
 ## Purpose
@@ -56,11 +56,11 @@ independent review validation.
   dispatched if available.
 - **mvp**: HUD coverage and controller navigation pass only.
 - **custom:depth(1-5)**:
-  - Depth 1: HUD-to-mechanic coverage and basic controller navigation pass (1 review pass)
-  - Depth 2: add settings completeness and accessibility compliance passes (2 review passes)
-  - Depth 3: add FTUE effectiveness and UI state machine passes (4 review passes)
-  - Depth 4: add external model review of UI completeness (4 review passes + external dispatch)
-  - Depth 5: multi-model review with reconciliation (4 review passes + multi-model synthesis)
+  - Depth 1: two passes — HUD-to-mechanic coverage and controller navigation reachability.
+  - Depth 2: four passes — add settings completeness and accessibility compliance.
+  - Depth 3: six passes — add FTUE effectiveness and UI state machine completeness.
+  - Depth 4: all 7 passes (add platform shell compliance) + one external model (if CLI available).
+  - Depth 5: all 7 passes + multi-model review with reconciliation.
 
 ## Mode Detection
 Re-review mode if previous review exists. If multi-model review artifacts exist

package/content/pipeline/specification/save-system-spec.md

@@ -54,7 +54,7 @@ authoritative state (no client save) do not need a save system specification.
 
 ## Inputs
 - docs/system-architecture.md (required) — data flow, storage layer, serialization strategy, platform abstraction
-- docs/domain-model.md (required) — entity definitions, relationships, and state that must be persisted
+- docs/domain-models/ (required) — entity definitions, relationships, and state that must be persisted
 - docs/plan.md (required) — target platforms informing cloud save APIs and storage quotas
 - docs/economy-design.md (optional, forward-read) — currency balances, inventory, transaction history requiring tamper-resistant persistence
 - docs/narrative-bible.md (optional, forward-read) — narrative state, branching flags, relationship values, quest progress requiring persistence

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zigrivers/scaffold",
-  "version": "3.5.0",
+  "version": "3.5.1",
   "description": "AI-powered software project scaffolding pipeline",
   "type": "module",
   "workspaces": ["packages/*"],