@zigrivers/scaffold 3.4.1 → 3.5.0

package/content/knowledge/review/review-netcode.md

@@ -0,0 +1,280 @@
+---
+name: review-netcode
+description: Failure modes and review passes specific to netcode design — latency analysis, bandwidth ceilings, cheat surfaces, and disconnect handling
+topics: [game-dev, review, networking, latency, bandwidth, anticheat]
+---
+
+# Review: Netcode Design
+
+Netcode design documents must specify how the game handles the physical reality of network latency, limited bandwidth, and untrusted clients. A netcode design that works under ideal conditions (20ms ping, no packet loss, no cheaters) is not a design — it is a fantasy. This review uses 7 passes targeting the specific ways netcode designs fail under real-world conditions.
+
+Follows the review process defined in `review-methodology.md`.
+
+## Summary
+
+- **Pass 1 — Worst-Case Latency Analysis**: The design handles 200ms+ latency gracefully; player-facing impact at each latency tier is documented; no mechanic requires sub-frame synchronization over the network.
+- **Pass 2 — Bandwidth Ceiling Calculation**: Per-player and per-match bandwidth budgets are calculated; entity count × update rate × payload size does not exceed typical residential upstream limits.
+- **Pass 3 — Cheat Surface Audit**: Every piece of data sent to the client is evaluated for cheat potential; server-authoritative validation exists for every game-state-changing action.
+- **Pass 4 — Determinism Verification**: For lockstep and rollback architectures, determinism requirements are identified and verified; floating-point divergence, platform differences, and desync detection are addressed. (NOT applicable to pure client-server designs.)
+- **Pass 5 — Disconnect/Reconnect Handling**: Graceful handling for every disconnect scenario: mid-match, mid-transaction, mid-save; reconnection restores state without exploits or data loss.
+- **Pass 6 — Matchmaking Fairness Assessment**: Matchmaking considers latency, skill, party size, and region; no systematic advantage for players in specific network conditions.
+- **Pass 7 — Bandwidth Spike Resilience**: The design handles transient bandwidth spikes (ability usage, explosions, mass entity spawns) without degrading below playable quality.
+
+## Deep Guidance
+
+---
+
+## Pass 1: Worst-Case Latency Analysis
+
+### What to Check
+
+The netcode design documents player experience at every latency tier: ideal (< 50ms), acceptable (50-100ms), degraded (100-200ms), and poor (200-500ms). Every gameplay mechanic is evaluated for its latency tolerance. No mechanic assumes LAN-quality latency.
+
+### Why This Matters
+
+Most netcode designs are tested and tuned on local networks or same-region servers. In production, 10-20% of players experience 100ms+ latency and 5% experience 200ms+. A mechanic that feels great at 30ms but breaks at 150ms will generate complaints from millions of players. The design must define what "graceful degradation" means for each latency tier — not "it still works" but specifically what the player experiences.
+
+### How to Check
+
+1. List every gameplay mechanic that involves networked state: movement, combat, trading, inventory, chat, matchmaking
+2. For each mechanic, evaluate at four latency tiers: < 50ms, 50-100ms, 100-200ms, 200ms+
+3. Identify mechanics with strict timing requirements: fighting game frame data, rhythm game hit windows, reaction-based combat
+4. Verify that client-side prediction is specified for latency-sensitive mechanics (movement, shooting)
+5. Check for latency compensation on hit detection: is the system using client-side hit detection with server validation, server-side hit detection with lag compensation, or something else?
+6. Verify that the design specifies what happens at extreme latency (> 500ms): timeout? Disconnect? Graceful degradation?
+7. Check for latency hiding techniques: animations that mask delay, local prediction for responsiveness, rollback for correction
+
+```markdown
+## Latency Impact Matrix
+
+| Mechanic            | < 50ms        | 50-100ms      | 100-200ms      | 200ms+         |
+|---------------------|---------------|---------------|----------------|----------------|
+| Player movement     | [experience]  | [experience]  | [experience]   | [experience]   |
+| Combat hit reg      | [experience]  | [experience]  | [experience]   | [experience]   |
+| Ability activation  | [experience]  | [experience]  | [experience]   | [experience]   |
+| Item pickup         | [experience]  | [experience]  | [experience]   | [experience]   |
+| Chat/emotes         | [experience]  | [experience]  | [experience]   | [experience]   |
+| Trading             | [experience]  | [experience]  | [experience]   | [experience]   |
+
+Acceptable threshold: [Define which cells are acceptable, degraded, or unplayable]
+```
+
+### What a Finding Looks Like
+
+- P0: "Combat uses server-authoritative hit detection with no lag compensation. At 150ms, players must lead targets by 300ms (round trip) — making fast-paced combat unplayable for 15% of the player base."
+- P0: "The design specifies 16ms tick rate for combat resolution but does not address how clients at 100ms+ latency interact with this tick rate. Inputs will consistently arrive 6+ ticks late."
+- P1: "Movement prediction exists but no reconciliation strategy is specified. When the server corrects a misprediction, what does the player see? Rubber-banding? Snap? Smooth interpolation?"
+- P2: "Latency tolerance for the trading system is not specified. Trades at 200ms latency may show stale inventory or allow double-spend if not handled."
+
+---
+
+## Pass 2: Bandwidth Ceiling Calculation
+
+### What to Check
+
+Total bandwidth consumption is calculated for worst-case scenarios: maximum players, maximum entities, maximum action density. Per-player upstream and downstream bandwidth stay within residential internet limits. Bandwidth is budgeted across entity types, not just estimated in aggregate.
+
+### Why This Matters
+
+Bandwidth overruns cause packet loss, which causes desync, rubber-banding, and hit registration failures. Unlike latency (which is physics), bandwidth is design-controllable — the team chooses how much data to send. A 64-player battle royale where each player sends full state at 60Hz consumes more bandwidth than most residential connections provide. The design must calculate this before implementation, not discover it in the first 64-player playtest.
+
+### How to Check
+
+1. Calculate per-entity update size: how many bytes does one entity state update require? (Position: 12 bytes, rotation: 4-16 bytes, velocity: 12 bytes, state flags: varies)
+2. Calculate entity count × update rate = updates per second
+3. Calculate total downstream: (entity count × update size × update rate) + overhead (packet headers, reliability layer)
+4. Verify downstream stays under 1 Mbps for residential players (conservative) or document the minimum connection requirement
+5. Calculate upstream: (local entity updates × update size × update rate) + input data
+6. Verify upstream stays under 256 Kbps (many residential connections have asymmetric upload)
+7. Check for bandwidth scaling: does bandwidth grow linearly with player count? Are there diminishing returns from interest management?
+
+### What a Finding Looks Like
+
+- P0: "64-player match with 30Hz updates at 64 bytes per entity = 64 × 64 × 30 = 122,880 bytes/sec (983 Kbps) downstream for entities alone. With packet overhead and game events, this exceeds 1.5 Mbps — above many residential connections."
+- P1: "Bandwidth calculation exists but does not account for game events (ability effects, explosions, chat). Events can spike bandwidth 3-5x above entity-update baseline."
+- P1: "No interest management (relevancy filtering) is specified. Every player receives updates for all 64 players regardless of distance, even if most are not visible."
+- P2: "Upstream bandwidth is not calculated. If the game sends input + local entity state at 60Hz, upstream may exceed residential upload limits."
+
+---
+
+## Pass 3: Cheat Surface Audit
+
+### What to Check
+
+Every piece of data sent to the client is evaluated for cheat potential. The server validates every game-state-changing action. The client is treated as untrusted — it is a rendering terminal, not an authority. Anti-cheat measures are proportional to the competitive stakes.
+
+### Why This Matters
+
+Any data the client possesses can be read by a cheater. Any action the client is authoritative on can be forged by a cheater. In competitive games, cheating drives away legitimate players — a single aimbotter in a lobby causes 63 other players to have a bad experience. Anti-cheat is not a post-launch bolt-on; the netcode architecture must be designed with cheat resistance as a core constraint.
+
+### How to Check
+
+1. List every data type sent to the client: player positions, health values, inventory contents, map data, enemy positions, loot tables
+2. For each, evaluate: what can a cheater do with this data? (Wallhacks from enemy positions, ESP from health values, loot sniping from loot table data)
+3. Verify server authority: for every game-state-changing action (damage, movement, item acquisition, currency change), does the server validate the action or trust the client?
+4. Check for speed hacks: does the server validate movement speed, or does it trust client-reported position?
+5. Check for teleport prevention: does the server verify position continuity (no instant jumps)?
+6. Verify that hit detection is server-validated: even if the client reports a hit, does the server verify line-of-sight, range, cooldowns, and ammunition?
+7. Check for economy cheats: can the client modify currency, item counts, or transaction outcomes?
+
+```markdown
+## Cheat Surface Audit Template
+
+| Data Sent to Client     | Cheat Vector          | Impact    | Mitigation         |
+|-------------------------|-----------------------|-----------|--------------------|
+| All player positions    | Wallhack/ESP          | High      | [Fog of war / culling] |
+| Player health values    | Health ESP            | Medium    | [Send only for visible] |
+| Loot table / drop data  | Loot prediction       | Medium    | [Server-side only]  |
+| Full map data           | Map reveal            | Low-High  | [Stream on demand]  |
+| Hit registration        | Aimbot + client auth  | Critical  | [Server validation] |
+| Movement authority      | Speed/teleport hack   | Critical  | [Server validation] |
+| Inventory/currency      | Item duplication      | Critical  | [Server-authoritative] |
+
+Unmitigated critical vectors: [COUNT — must be 0]
+```
+
+### What a Finding Looks Like
+
+- P0: "Client is authoritative for hit detection. A cheater can send 'I hit every player for maximum damage every frame' and the server will accept it."
+- P0: "All player positions are sent to every client regardless of visibility. This enables trivial wallhacks — the cheat client simply renders hidden players."
+- P1: "Server validates movement speed but not acceleration. A speed hack that gradually increases speed from 100% to 200% over 10 seconds would bypass the speed check."
+- P2: "Inventory changes are server-authoritative but the client caches inventory locally. A cheater could display spoofed items to other players in social contexts."
+
+---
+
+## Pass 4: Determinism Verification
+
+### What to Check
+
+**CONDITIONAL: This pass applies only to lockstep or rollback netcode architectures.** For client-server authority models, skip this pass entirely.
+
+For deterministic architectures, every operation that affects game state must produce identical results on every machine given the same inputs. Floating-point operations, random number generation, physics simulation, and platform-specific behavior are all sources of non-determinism that cause desync.
+
+### Why This Matters
+
+Lockstep and rollback architectures rely on all clients simulating identically. A single non-deterministic operation causes the simulations to diverge — desync — which manifests as teleporting players, phantom hits, and corrupted game state. Desync is catastrophic because it is cumulative: once simulations diverge, they never re-converge without correction. Determinism is an all-or-nothing requirement.
+
+### How to Check
+
+1. Verify that the architecture is actually lockstep or rollback — if it is client-server with authoritative server, skip this pass
+2. Check floating-point handling: are fixed-point math libraries used? If IEEE 754 floating-point is used, are platform-specific differences (x86 vs. ARM) addressed?
+3. Verify RNG determinism: all random number generation uses a shared seed with a deterministic algorithm (no system RNG)
+4. Check physics engine determinism: is the physics engine guaranteed deterministic? (Most are NOT across platforms)
+5. Verify iteration order: hash maps, sets, and any unordered data structures must use deterministic iteration
+6. Check that desync detection exists: periodic state hash comparison between clients to detect divergence early
+7. Verify desync recovery: when detected, how is desync resolved? Full state resync? Rollback to last known good state?
+
+### What a Finding Looks Like
+
+- P0: "Rollback architecture uses Unity's built-in physics engine, which is not deterministic across platforms. PC and console clients will desync within minutes."
+- P0: "Floating-point arithmetic is used for all game state calculations with no fixed-point alternative. x86 and ARM produce different results for the same operations."
+- P1: "RNG uses a shared seed but the document does not specify which PRNG algorithm. Different implementations of 'random' produce different sequences."
+- P2: "Desync detection is mentioned but no detection mechanism is specified. Without periodic state hashing, desync goes undetected until it becomes visible to players."
+
+---
+
+## Pass 5: Disconnect/Reconnect Handling
+
+### What to Check
+
+Every disconnect scenario is handled: mid-match, mid-transaction, mid-save, mid-trade. Reconnection restores the player to their correct state without data loss, exploits, or unfair advantage. Timeout thresholds and abandon penalties are specified.
+
+### Why This Matters
+
+Disconnects are not edge cases — they are guaranteed. On mobile, network transitions (Wi-Fi to cellular) cause momentary disconnects. On any platform, ISP issues, router restarts, and game crashes cause unexpected disconnects. A game that loses player progress, duplicates items, or awards undeserved wins/losses on disconnect will hemorrhage players. Disconnect handling is a core system, not an afterthought.
+
+### How to Check
+
+1. For each game mode, specify what happens when a player disconnects: is their character removed instantly? After a timeout? Does an AI take over?
+2. Check for mid-transaction disconnect: if a player disconnects while buying/selling/trading, what is the transaction state? Is it rolled back? Completed? Left in limbo?
+3. Verify reconnection flow: can a player rejoin an in-progress match? Within what time window? Is their state preserved?
+4. Check for exploit potential: can a player disconnect to avoid a loss? To duplicate items? To undo a bad trade?
+5. Verify timeout thresholds: how long does the server wait before treating a disconnect as an abandon?
+6. Check for abandon penalties: are players who intentionally disconnect punished? How are intentional disconnects distinguished from network issues?
+7. Verify save state consistency: if the player disconnects between a game state change and a save, which state wins?
+
+### What a Finding Looks Like
+
+- P0: "No reconnection mechanism exists. A player who disconnects from a 45-minute match must start over. This is unacceptable for competitive modes."
+- P0: "Mid-trade disconnect handling is not specified. If player A sends an item and disconnects before receiving player B's item, the trade state is undefined — potential item duplication or loss."
+- P1: "Disconnect during a ranked match counts as an automatic loss. No grace period exists for reconnection. A 2-second ISP hiccup causes a full loss of ranked points."
+- P2: "AI takeover is specified for disconnected players but the AI difficulty level is not defined. An overpowered AI substitute could be more effective than the disconnected player, creating a perverse incentive to disconnect."
+
+---
+
+## Pass 6: Matchmaking Fairness Assessment
+
+### What to Check
+
+Matchmaking considers latency (players are matched within acceptable ping ranges), skill (players face opponents of similar ability), party size (solo players are not matched against coordinated groups), and region (geographic proximity for latency). No systematic advantage exists for players in specific network conditions or regions.
+
+### Why This Matters
+
+Unfair matchmaking drives player churn faster than any other factor. A new player matched against a veteran quits in frustration. A player with 30ms ping matched against a player with 200ms ping has a structural advantage in any real-time combat. A solo player matched against a coordinated 4-stack loses due to communication, not skill. Matchmaking fairness is the foundation of competitive game health.
+
+### How to Check
+
+1. Verify that ping-based matchmaking exists: players within the same match should have comparable latency (< 50ms difference ideal, < 100ms acceptable)
+2. Check for skill-based matchmaking (SBMM): is there a rating system? How does it handle new players (placement matches)? How quickly does it converge?
+3. Verify party-size matching: solo players vs. solo players, groups vs. groups — or at minimum, compensation for size imbalance
+4. Check for region selection: can players choose their region? Is the choice locked or advisory?
+5. Verify that matchmaking queue times are bounded: what happens when the pool is too small for fair matches? (Wider skill range? Cross-region? Bot backfill?)
+6. Check for smurf prevention: can experienced players create new accounts to stomp new players?
+7. Verify that matchmaking data is used for balance analysis: is win rate by skill bracket tracked?
+
+### What a Finding Looks Like
+
+- P0: "No ping-based matchmaking exists. A player in Tokyo can be matched against a player in New York, producing 200ms+ latency in a competitive shooter."
+- P1: "SBMM exists but no placement system is defined. New players start at median rating and are immediately matched against average players, producing 30-50 matches of stomps before the rating converges."
+- P1: "Solo players and 5-stacks are in the same matchmaking pool with no compensation. Coordinated groups have a 15-20% win rate advantage over equivalent-skill solo players."
+- P2: "Queue time bounds are not specified. In low-population regions, players may wait indefinitely or receive wildly unfair matches."
+
+---
+
+## Pass 7: Bandwidth Spike Resilience
+
+### What to Check
+
+The design handles transient bandwidth spikes caused by gameplay events: ability usage, explosions, mass entity spawns, zone transitions, and player clustering. Spike mitigation strategies (priority queuing, delta compression, update rate reduction) are specified.
+
+### Why This Matters
+
+Steady-state bandwidth may be well within limits, but a single moment — 10 players using abilities simultaneously in a team fight — can spike bandwidth 5-10x above baseline. Without spike mitigation, this causes packet loss during the most important gameplay moments, precisely when network quality matters most. Players remember "the game lagged during the final team fight" more than any other quality issue.
+
+### How to Check
+
+1. Identify spike scenarios: large battles, ability clusters, zone transitions, mass spawns, world events
+2. For each scenario, calculate peak bandwidth: (entities changed × update size) for that frame/tick
+3. Verify that peak bandwidth does not exceed steady-state by more than 3x without mitigation
+4. Check for priority queuing: are critical updates (player position, health) prioritized over cosmetic updates (emotes, particle effects)?
+5. Verify delta compression: are only changed fields sent, or full entity state on every update?
+6. Check for adaptive update rates: does the server reduce update frequency under load? Which entities are downgraded first?
+7. Verify that spike mitigation degrades gracefully: cosmetic quality drops before gameplay accuracy
+
+### What a Finding Looks Like
+
+- P0: "10v10 team fight with all abilities active produces 15x baseline bandwidth. No spike mitigation is specified. This will cause packet loss and desync during the most critical gameplay moments."
+- P1: "Delta compression is specified for entity position but not for game events. A single explosion event sends full effect data (particle count, damage list, audio trigger) to all 64 players simultaneously."
+- P2: "Adaptive update rate is mentioned but priority order is not defined. Without explicit priority (gameplay > VFX > audio > cosmetic), the system may downgrade gameplay updates to preserve cosmetic fidelity."
+
+---
+
+## Common Review Anti-Patterns
+
+### 1. LAN-Optimized Netcode
+
+The netcode design was tested and tuned on a local network. All latency budgets assume < 20ms. Bandwidth calculations assume gigabit LAN speeds. The design feels great in the studio and breaks for every player outside the same city as the data center.
+
+**How to spot it:** Latency analysis mentions only one tier (e.g., "at 20ms latency"). No latency degradation table exists. Bandwidth calculations do not reference residential internet speeds or upstream limits.
+
+### 2. "Anti-Cheat Will Handle It"
+
+The netcode design defers all cheat prevention to a third-party anti-cheat solution (EasyAntiCheat, BattlEye, Vanguard). These tools detect cheat software but cannot fix architectural flaws. If the client is authoritative for hit detection, no anti-cheat tool can prevent a modified client from reporting false hits. Architectural cheat resistance and software-based anti-cheat are complementary, not substitutes.
+
+**How to spot it:** The cheat prevention section names an anti-cheat product but does not analyze the server-authority model. No discussion of what data the client receives or what actions the client is authoritative for.
+
+### 3. Determinism Assumed, Not Verified
+
+For lockstep/rollback designs, the document states "the simulation is deterministic" without analyzing sources of non-determinism. Floating-point operations, hash map iteration order, physics engine behavior, and platform-specific math libraries are all sources of non-determinism that must be explicitly addressed.
+
+**How to spot it:** The word "deterministic" appears without any discussion of fixed-point math, PRNG seeding, physics engine guarantees, or cross-platform verification.

package/content/knowledge/review/review-platform-cert.md

@@ -0,0 +1,341 @@
+---
+name: review-platform-cert
+description: Failure modes and review passes specific to platform certification — TRC/TCR compliance, save data, suspend/resume, controller disconnect, and content ratings
+topics: [game-dev, review, certification, trc, tcr, compliance]
+---
+
+# Review: Platform Certification
+
+Platform certification documents must demonstrate compliance with each target platform's Technical Requirements Checklist (TRC for PlayStation, TCR for Xbox, Lotcheck for Nintendo, platform guidelines for mobile stores). Certification failures cause submission rejections that cost weeks of schedule and tens of thousands of dollars in resubmission fees. This review uses 7 passes targeting the common certification failure points that can be caught at design time.
+
+Follows the review process defined in `review-methodology.md`.
+
+## Summary
+
+- **Pass 1 — Common TRC/TCR Failure Points**: Known high-failure-rate requirements are addressed per platform; no reliance on "we will fix it during cert prep."
+- **Pass 2 — Save Data Compliance**: Save data size limits, save/load timing, corruption recovery, and platform-mandated save behaviors are specified.
+- **Pass 3 — Suspend/Resume Handling**: Application correctly handles OS-level suspend and resume events on every target platform without data loss or state corruption.
+- **Pass 4 — Controller Disconnect Behavior**: Every controller disconnect scenario has a defined UI response and game state handling; no scenario leaves the player stuck.
+- **Pass 5 — Error Message Requirements**: Error messages meet platform-specific wording, formatting, and localization requirements; no generic or developer-facing error text.
+- **Pass 6 — Trophy/Achievement Compliance**: Trophy/achievement design meets platform rules for count, point totals, descriptions, difficulty distribution, and unlock conditions.
+- **Pass 7 — Content Rating Alignment**: Game content aligns with submitted content rating questionnaires; no undisclosed content triggers a rating change post-submission.
+
+## Deep Guidance
+
+---
+
+## Pass 1: Common TRC/TCR Failure Points
+
+### What to Check
+
+Each target platform has a published Technical Requirements Checklist (or equivalent) with hundreds of requirements. Certain requirements have historically high failure rates because they are non-obvious, require specific implementation, or are commonly overlooked. This pass focuses on those high-failure-rate requirements.
+
+### Why This Matters
+
+A certification failure costs 2-6 weeks of schedule (resubmission queue times) and potentially $10,000-$50,000 in fees, QA costs, and delayed revenue. Most failures are preventable — they are caused by requirements that the team did not know about until the certification report arrived. Catching these at design time costs hours; catching them at certification costs weeks.
+
+### How to Check
+
+Use this per-platform checklist for common failure points:
+
+```markdown
+## PlayStation TRC — Common Failure Points
+
+- [ ] Title does not exceed 128 character limit for save data descriptions
+- [ ] System software version check on boot (display update prompt if outdated)
+- [ ] PS button behavior: single press returns to system menu, hold opens quick menu
+- [ ] All mandatory terminology used correctly (e.g., "PS5" not "PlayStation 5" in certain contexts)
+- [ ] User account switching handled (user signs in with different PSN account mid-session)
+- [ ] Network connectivity loss displays correct system dialog (not custom error)
+- [ ] Background download/install does not interfere with gameplay
+- [ ] HDR output handled correctly when TV does not support HDR
+- [ ] Activity cards populated correctly for PS5
+- [ ] Game help content provided for PS5 (if applicable)
+- [ ] Haptic feedback and adaptive trigger usage follows platform guidelines
+- [ ] 4K and Performance mode options available on PS5
+
+## Xbox TCR — Common Failure Points
+
+- [ ] Title must function on all Xbox console SKUs (Series X, Series S, One)
+- [ ] Quick Resume must not corrupt game state or lose progress
+- [ ] Xbox network connectivity requirements: graceful offline mode or clear messaging
+- [ ] Gamertag display uses correct formatting (no truncation of long Gamertags)
+- [ ] Smart Delivery configured correctly (correct build for each SKU)
+- [ ] Suspend/resume does not desync multiplayer session
+- [ ] Accessibility: text-to-speech and speech-to-text for chat (XR-015)
+- [ ] Energy efficiency: game must reduce power consumption during idle
+- [ ] Cross-generation save data compatibility (if applicable)
+- [ ] Game Pass integration: trial/demo behavior if accessed via subscription
+
+## Nintendo Lotcheck — Common Failure Points
+
+- [ ] Controller grip change handling: game pauses when grip changes
+- [ ] Handheld vs. docked display adapts correctly (resolution, UI scaling)
+- [ ] Joy-Con detachment pauses game and prompts reconnection
+- [ ] Touch screen functionality in handheld mode (if applicable)
+- [ ] Sleep mode does not corrupt save data
+- [ ] Nintendo Account and online service integration follows guidelines
+- [ ] Age-gated content handled per Nintendo requirements
+- [ ] Home button behavior: game suspends cleanly
+- [ ] Screenshot and video capture do not include restricted content
+- [ ] NFC (amiibo) integration follows guidelines (if applicable)
+
+## Mobile (iOS App Store / Google Play) — Common Failure Points
+
+- [ ] No external payment links (iOS) or compliant alternative payment (where permitted)
+- [ ] App Tracking Transparency (ATT) prompt before any tracking (iOS 14.5+)
+- [ ] Background audio handling: music apps continue when game is not in focus
+- [ ] Push notification permissions requested at appropriate time (not on first launch)
+- [ ] Data deletion capability per Apple/Google requirements
+- [ ] Subscription management deep links provided
+- [ ] Minimum OS version support matches store requirements
+- [ ] App size within store limits (or uses on-demand resources)
+- [ ] Accessibility: VoiceOver/TalkBack support for critical UI flows
+- [ ] Privacy nutrition label / Data Safety section accurate and complete
+```
+
+### What a Finding Looks Like
+
+- P0: "Game targets Xbox but Quick Resume handling is not documented. Quick Resume is a mandatory TCR — the game must restore correctly from a suspended state hours or days later."
+- P0: "Game targets iOS but no App Tracking Transparency implementation is documented. Missing ATT will cause App Store rejection."
+- P1: "PlayStation TRC requires specific system dialogs for network errors, but the design uses custom error dialogs. Custom dialogs will fail certification."
+- P2: "Nintendo Lotcheck requires pause on Joy-Con detachment, but the design does not mention Joy-Con-specific controller handling."
+
+---
+
+## Pass 2: Save Data Compliance
+
+### What to Check
+
+Save data implementation meets platform-specific requirements for size limits, save timing, corruption detection and recovery, user-facing save indicators, and platform-mandated save behaviors (cloud sync, account-specific save isolation).
+
+### Why This Matters
+
+Save data certification failures are among the most costly because they often require architectural changes. A save system that exceeds the platform's size limit cannot be fixed with a tweak — it requires save data restructuring, migration planning, and backward compatibility testing. Save corruption that loses player progress generates more support tickets and refund requests than almost any other bug.
+
+### How to Check
+
+1. Verify save data size against platform limits: PlayStation has per-title limits, Nintendo Switch has strict per-title allocation, mobile platforms have iCloud/Google Play limits
+2. Check save timing: does the game save at appropriate points? Is there a visible save indicator during all save operations? (Most platforms require this)
+3. Verify corruption detection: does the save system detect corrupted data? Is there a recovery mechanism (backup save, previous version rollback)?
+4. Check for platform-mandated save behaviors: cloud save sync, account-specific save isolation, save data portability between console generations
+5. Verify that the save indicator is never hidden or obscured during save operations
+6. Check for save data migration: if the game updates change the save format, is there a migration path from old saves?
+7. Verify that save/load operations do not block the main thread (certification requirement on most platforms)
+
+### What a Finding Looks Like
+
+- P0: "Save data size is estimated at 50MB per slot but Nintendo Switch allocates a maximum of 32MB per title. The save system exceeds the platform limit."
+- P0: "No save corruption detection exists. A power loss during save produces a corrupted file with no recovery — the player loses all progress."
+- P1: "Save indicator is shown during manual saves but not during autosaves. Platform certification requires the save indicator during ALL save operations."
+- P2: "Save data migration strategy is not documented. A future update that changes save format will either break old saves or require emergency migration code."
+
+---
+
+## Pass 3: Suspend/Resume Handling
+
+### What to Check
+
+The application correctly handles OS-level suspend and resume events on every target platform. Suspend can happen at any time — during loading, during cutscenes, during multiplayer matches, during transactions. Resume must restore the game to a usable state without data loss, state corruption, or stale connections.
+
+### Why This Matters
+
+Players suspend games constantly — answering phone calls, switching apps, putting the console to sleep. On Xbox, Quick Resume can suspend a game for days. On mobile, any incoming call or notification can trigger a suspend. A game that crashes on resume, loses unsaved progress, or shows a black screen after resume will fail certification on every platform.
+
+### How to Check
+
+1. List all game states where suspend can occur: main menu, loading screen, gameplay, cutscene, multiplayer match, store transaction, save in progress, download in progress
+2. For each state, verify the resume behavior: does the game return to the correct state? Are network connections re-established? Are time-sensitive elements (timers, cooldowns, server sessions) handled?
+3. Check for stale connection handling: after a 4-hour suspend, network connections are dead — does the game detect this and reconnect or show an appropriate error?
+4. Verify that suspend during save does not corrupt data (save must be atomic or recoverable)
+5. Check for time-sensitive resume: if the game has daily resets, seasonal events, or time-limited offers, what happens when the player resumes after the reset time?
+6. Verify audio resume: does audio restart correctly? Are audio handles stale after resume?
+7. Check for authentication token expiry: OAuth tokens, session tokens, and platform authentication may expire during long suspends
+
+### What a Finding Looks Like
+
+- P0: "No suspend/resume handling is documented. The game will crash on resume when attempting to use stale network connections."
+- P0: "Xbox Quick Resume is not addressed. A game suspended for 48 hours will resume with expired authentication tokens, stale multiplayer sessions, and incorrect daily reset states."
+- P1: "Resume after network-based suspend (multiplayer match) attempts to continue the match without checking if the session still exists. This will produce a desync or crash."
+- P2: "Audio resume is not specified. Some platforms require explicit audio session reactivation after resume — without it, the game is silent."
+
+---
+
+## Pass 4: Controller Disconnect Behavior
+
+### What to Check
+
+Every controller disconnect scenario has a defined game response: which player is affected, what UI is shown, how gameplay is affected, and how reconnection is handled. No scenario leaves the player in an unrecoverable state.
+
+### Why This Matters
+
+Controller disconnect is a certification-tested scenario on every console platform. The platform holder will disconnect controllers at every possible moment during certification testing — during gameplay, during menus, during saving, during loading. Every disconnect must produce a clear, user-recoverable response. A game that freezes, crashes, or continues playing without input on controller disconnect will fail certification.
+
+### How to Check
+
+1. Verify that controller disconnect shows a system-appropriate dialog: "Controller disconnected. Please reconnect controller to continue."
+2. Check that gameplay pauses on disconnect (except in multiplayer where pausing is not possible)
+3. Verify that the correct player is identified in split-screen/local multiplayer — disconnecting Player 2's controller should not pause Player 1
+4. Check for wireless controller battery death: same as disconnect but may occur gradually (low battery warning first)
+5. Verify reconnection behavior: does the game resume automatically, or does the player press a button to continue?
+6. Check for controller reassignment: if the player reconnects a different controller, is it accepted?
+7. Verify behavior during critical moments: what happens if the controller disconnects during a save? During a purchase? During a cutscene?
+
+```markdown
+## Controller Disconnect Scenario Matrix
+
+| Game State          | Disconnect Response       | Gameplay Impact    | Reconnect Behavior    |
+|---------------------|---------------------------|--------------------|-----------------------|
+| Main menu           | [Dialog shown]            | [Menu navigation paused] | [Resume on reconnect] |
+| Single-player       | [Dialog + pause]          | [Game paused]      | [Resume on button press] |
+| Local multiplayer   | [Dialog for affected player] | [Affected player paused] | [Resume on reconnect] |
+| Online multiplayer  | [Dialog shown, no pause]  | [Player input stops] | [Resume on reconnect] |
+| Loading screen      | [Dialog shown]            | [Loading continues] | [Resume on reconnect] |
+| Cutscene            | [Dialog + pause cutscene] | [Cutscene paused]  | [Resume cutscene]     |
+| Save in progress    | [Dialog after save completes] | [Save completes first] | [Resume on reconnect] |
+| Store/purchase      | [Dialog + cancel transaction] | [Transaction rolled back] | [Restart transaction] |
+```
+
+### What a Finding Looks Like
+
+- P0: "Controller disconnect during gameplay is not documented. No pause dialog, no input handling, no reconnection flow — this is a guaranteed certification failure."
+- P1: "Controller disconnect in multiplayer is handled (toast notification) but in single-player there is no pause. Single-player must pause on disconnect per TRC/TCR."
+- P1: "Low battery warning is not mentioned. Platforms require a low battery notification before the controller dies — this is separate from the disconnect dialog."
+- P2: "Controller disconnect during save shows the disconnect dialog immediately. If the save has not completed, this could cause the player to pull the power cord, corrupting the save. Show the dialog only after the save completes."
+
+---
+
+## Pass 5: Error Message Requirements
+
+### What to Check
+
+Error messages meet platform-specific requirements for wording, formatting, button prompts, and localization. No error message contains developer-facing text (error codes without explanation, stack traces, debug information). Error messages use platform-standard terminology.
+
+### Why This Matters
+
+Platform holders test every error state during certification. An error message that says "Error 0x80070005" or "null reference exception" will fail certification. An error message that says "Press A to continue" on PlayStation (where the button is "Cross" or a symbol) will fail certification. Error messages must use the platform's mandated terminology, button iconography, and localization for every supported language.
+
+### How to Check
+
+1. List every error state: network failure, save failure, authentication failure, matchmaking failure, content download failure, server maintenance, account restriction
+2. For each error state, verify the message explains what happened and what the player can do
+3. Check button prompt correctness per platform: PlayStation uses symbols (Cross, Circle, Triangle, Square), Xbox uses letters (A, B, X, Y), Nintendo Switch uses letters in different positions
+4. Verify that error messages do not contain: error codes without explanation, technical jargon, developer-facing debug information, profanity, or blame-the-user language
+5. Check localization: are all error messages localized into every supported language?
+6. Verify that platform-specific terminology is used: "PlayStation Network" not "PSN," "Xbox network" not "Xbox Live" (terminology changes over time)
+7. Check that network error messages use platform-mandated dialogs where required (some platforms require system-level network error dialogs, not custom ones)
+
+### What a Finding Looks Like
+
+- P0: "Network error message says 'Connection failed (errno: 110).' This developer-facing message will fail certification on every platform."
+- P0: "Error messages reference 'Press A' on all platforms. PlayStation requires Cross symbol, not 'A.' Nintendo Switch 'A' button is in a different position than Xbox 'A'."
+- P1: "Error messages are in English only but the game supports 12 languages. Every user-facing string must be localized."
+- P2: "Server maintenance message says 'Server is down, try again later.' This does not tell the player why (maintenance) or when (estimated return time). Improve to 'Server maintenance in progress. Expected to return at [TIME].'"
+
+---
+
+## Pass 6: Trophy/Achievement Compliance
+
+### What to Check
+
+Trophy/achievement design meets platform rules for total count, point totals (Gamerscore, trophy distribution), description formatting, difficulty distribution, secret/hidden achievement handling, and unlock conditions.
+
+### Why This Matters
+
+Trophy and achievement systems have strict platform rules that vary between PlayStation, Xbox, and Steam. PlayStation mandates a Platinum trophy, a specific distribution of Gold/Silver/Bronze trophies, and exact description formatting. Xbox mandates a base Gamerscore of 1000 and specific rules for DLC Gamerscore additions. Violating these rules causes certification failure — and the fix requires redesigning the achievement list, which is a design task, not an engineering task.
+
+### How to Check
+
+1. Verify trophy/achievement count meets platform requirements:
+   - **PlayStation**: Must include 1 Platinum (unlock all others), appropriate Gold/Silver/Bronze distribution
+   - **Xbox**: Base game must total exactly 1000 Gamerscore; DLC adds up to 250 per release
+   - **Nintendo/Steam**: More flexible but verify platform-specific guidelines
+2. Check descriptions: no spoilers in visible descriptions (use hidden/secret for story spoilers), no profanity, correct platform terminology
+3. Verify difficulty distribution: not all trophies should be trivially easy (cheapens the system) or brutally hard (frustrates completionists)
+4. Check for unobtainable achievements: can every achievement actually be earned? Multiplayer achievements in games that may lose their servers are a known issue
+5. Verify that no achievement requires luck-based conditions that a player cannot influence through skill
+6. Check DLC achievement rules: DLC achievements must not be required for the base game Platinum/100%
+7. Verify that achievement unlock conditions are testable by QA and certifiable by the platform
+
+```markdown
+## Achievement Compliance Matrix
+
+| Requirement                        | PlayStation | Xbox    | Steam   | Status  |
+|------------------------------------|-------------|---------|---------|---------|
+| Total count within limits          | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| Point/tier distribution correct    | [✅/❌]     | [✅/❌] | N/A     | [Done]  |
+| Platinum/100% achievable           | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| No unobtainable achievements      | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| Descriptions spoiler-free          | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| Difficulty distribution reasonable | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| DLC achievements separate from base| [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+| Hidden achievements used correctly | [✅/❌]     | [✅/❌] | [✅/❌] | [Done]  |
+```
+
+### What a Finding Looks Like
+
+- P0: "Xbox base game Gamerscore totals 750, not 1000. Xbox certification requires exactly 1000 base Gamerscore."
+- P0: "PlayStation trophy list has no Platinum trophy. A Platinum trophy is mandatory for all PlayStation games."
+- P1: "Achievement 'Win 1000 Online Matches' requires approximately 500 hours of multiplayer. If the game's servers are shut down in 3 years, this achievement becomes permanently unobtainable."
+- P2: "Achievement description 'Defeat the final boss' spoils the story. Mark as a hidden/secret achievement to hide the description until earned."
+
+---
+
+## Pass 7: Content Rating Alignment
+
+### What to Check
+
+Game content aligns with the content rating submitted to rating boards (ESRB, PEGI, CERO, USK, GRAC, ACB). No in-game content exceeds the submitted rating. User-generated content (chat, custom names, shared creations) has moderation to prevent rating-exceeding content.
+
+### Why This Matters
+
+A content rating mismatch — submitting for Teen/PEGI 12 but shipping Mature/PEGI 18 content — results in the game being pulled from stores until the rating is corrected. This is a commercial disaster: lost sales during delisting, re-rating fees, potential fines, and reputational damage. Rating boards test the game independently and will find content that the developer's questionnaire did not disclose.
+
+### How to Check
+
+1. List all content that could affect ratings: violence level (depiction, blood, gore), language (profanity, slurs), sexual content, drug/alcohol references, gambling mechanics, horror/fear themes
+2. Cross-reference content with the intended rating per rating board:
+   - **ESRB** (North America): E, E10+, T, M, AO
+   - **PEGI** (Europe): 3, 7, 12, 16, 18
+   - **CERO** (Japan): A, B, C, D, Z
+   - **USK** (Germany): 0, 6, 12, 16, 18
+3. Verify that user-generated content has moderation: text chat filters, image moderation, name filters
+4. Check that in-game purchases are disclosed in the rating (most boards now require "In-Game Purchases" or "In-Game Purchases (Includes Random Items)" descriptors)
+5. Verify that DLC and updates do not introduce content that exceeds the base game's rating
+6. Check for simulated gambling: loot boxes, slot machines, card packs — these may trigger gambling descriptors in some markets
+7. Verify that content differs by market where required: some content acceptable in one market may be banned in another (Germany has specific rules about symbols, Australia about drug references)
+
+### What a Finding Looks Like
+
+- P0: "Game is rated ESRB Teen but includes decapitation animations in combat. Dismemberment/decapitation typically triggers Mature rating."
+- P0: "Loot boxes with real-money purchase are present but 'In-Game Purchases (Includes Random Items)' descriptor was not submitted. This will be flagged by every rating board."
+- P1: "Text chat exists with no profanity filter. Unmoderated text chat allows players to share content that exceeds the game's rating."
+- P2: "The Australian market is targeted but drug references in a side quest may trigger ACB refusal of classification. Review the specific content against ACB guidelines."
+
+---
+
+## Common Review Anti-Patterns
+
+### 1. "We Will Handle Cert During Cert Prep"
+
+The certification compliance section of the design document says "TRC/TCR compliance will be addressed during the certification preparation phase" — 6-8 weeks before submission. Requirements that affect architecture (save system, suspend/resume, controller handling) cannot be retrofitted in 6 weeks. By design time, these requirements must be baked into the architecture.
+
+**How to spot it:** The design document has no section for platform certification requirements. Or it has a section that says "see certification preparation milestone." No platform-specific technical requirements are mentioned in the technical design.
+
+### 2. Single-Platform Certification Focus
+
+The document addresses one platform's certification requirements thoroughly (usually the platform the team is most familiar with) and ignores or hand-waves the others. Each platform has unique requirements — Xbox Quick Resume, PlayStation Activity Cards, Nintendo Switch handheld/docked modes — that require distinct implementation.
+
+**How to spot it:** One platform has a detailed checklist; other platforms have "similar requirements apply" or "to be determined." The unique requirements of each platform are not enumerated.
+
+### 3. Outdated Certification Requirements
+
+The certification requirements referenced in the document are from a previous console generation or an outdated version of the TRC/TCR. Platform requirements change with every SDK update — new requirements are added, old ones are modified. A document referencing PS4-era TRC for a PS5 game will miss Activity Cards, Haptic Feedback guidelines, and Game Help requirements.
+
+**How to spot it:** The document references a specific TRC/TCR version number that does not match the current SDK. Or it does not reference any version at all, making it impossible to verify currency. Requirements like "Activity Cards" or "Quick Resume" are absent despite targeting current-gen platforms.
+
+### 4. Content Rating as Afterthought
+
+The content rating questionnaire is treated as a bureaucratic checkbox rather than a design input. The team fills out the rating questionnaire based on the current build without verifying that planned future content (DLC, seasonal content, user-generated content) will not exceed the submitted rating. A Mature rating on a Teen-targeted game means rebuilding the marketing strategy, store page, and potentially removing content.
+
+**How to spot it:** The rating section references only current content, not planned content. No mention of DLC or live-service content in the rating analysis. User-generated content moderation is not connected to rating compliance.