You are responsible for a comprehensive **game release-readiness, production-hardening, and shipping pass**.

Your job is to take the existing project from:

> **development-complete enough to play**

to:

> **safe, coherent, reproducible, professional, and technically ready to ship.**

The primary question throughout this task is:

> **What could prevent this game from building, packaging, installing, launching, running, saving, connecting, updating, or presenting itself correctly when released to real players?**

Then fix those problems.

This is an **implementation task**, not merely a release checklist.

Do not stop after:

- creating a shipping checklist;
- listing launch blockers;
- identifying build problems;
- recommending platform configuration;
- producing a risk report;
- saying something should be tested before release.

Inspect the actual project and release pipeline.

Build the project.

Package or export it where the available environment permits.

Run realistic release-oriented validation.

Identify concrete blockers and production risks.

Implement worthwhile corrections.

Rebuild.

Retest.

Reinspect.

Continue until no clear, material, safely actionable repository-controlled shipping issue remains.

The goal is:

> **Leave behind a project that is substantially safer to build, package, distribute, install, launch, play, save, reconnect, update, and support as a real released product.**

---

# Shipping Is the Priority

Prioritize approximately:

1. release-blocking build failures;
2. packaging or installation failures;
3. launch/runtime failures;
4. production configuration mistakes;
5. persistence and player-data risks;
6. platform integration failures;
7. release-only bugs;
8. missing or incorrect production resources;
9. build and deployment reproducibility;
10. versioning and migration safety;
11. supported-platform compatibility;
12. crash/error handling at release boundaries;
13. release metadata correctness;
14. update and upgrade behavior;
15. supportability and diagnostics;
16. final launch-polish blockers.

This is not rigid.

Prioritize the highest-risk release problems actually present.

---

# Core Scope

This pass owns **release readiness**.

Only inspect systems and release targets that actually exist.

## Build

Relevant areas may include:

- clean builds;
- release builds;
- production builds;
- exports;
- platform-specific builds;
- build scripts;
- build configuration;
- compilation;
- release defines;
- environment configuration;
- asset inclusion;
- generated files;
- build reproducibility.

## Packaging

Relevant areas may include:

- packaged game contents;
- missing resources;
- accidental development files;
- installer or package structure;
- executable placement;
- dependencies;
- runtime libraries;
- permissions;
- archives;
- manifests;
- platform-required files.

## Launch

Relevant areas may include:

- startup;
- first-run behavior;
- missing configuration;
- missing directories;
- filesystem permissions;
- initialization;
- platform APIs;
- network bootstrap;
- service startup where applicable;
- crash behavior;
- graphics/audio initialization.

## Platform Integration

Where applicable:

- Steam;
- Epic;
- console platforms;
- mobile platforms;
- web deployment;
- itch.io;
- standalone distribution;
- launchers;
- platform authentication;
- achievements;
- cloud saves;
- overlays;
- entitlements;
- DLC;
- rich presence;
- platform-specific storage.

Do not implement integrations the project has never intended to support.

Validate what already exists or is clearly part of the intended release target.

## Persistence

Relevant areas may include:

- save creation;
- save loading;
- save upgrade;
- migrations;
- corruption handling;
- file paths;
- permissions;
- cloud/local interaction;
- server persistence;
- database migrations.

## Production Configuration

Relevant areas may include:

- development versus production endpoints;
- API URLs;
- credentials handling;
- environment variables;
- debug flags;
- logging;
- feature flags;
- test services;
- sandbox services;
- development cheats;
- developer consoles;
- debug UI;
- staging configuration.

## Release Metadata

Where maintained in the project:

- application name;
- version;
- build number;
- executable metadata;
- icons;
- package identifiers;
- application IDs;
- copyright strings;
- legal files;
- credits;
- license notices;
- platform metadata.

## Update Safety

Relevant areas may include:

- version compatibility;
- save migrations;
- configuration compatibility;
- schema changes;
- patch behavior;
- rollback assumptions;
- client/server compatibility.

## Final Production Quality

Look for:

- obvious placeholders;
- debug leftovers;
- test data;
- unfinished production messages;
- release-only warnings;
- broken external links;
- development references visible to players;
- obvious engine-default metadata.

---

# Explicitly Out of Scope

This is **not primarily**:

- a major feature sprint;
- gameplay redesign;
- balance overhaul;
- visual-art overhaul;
- world-building pass;
- deep architecture refactor;
- general technical-debt cleanup;
- repository-hygiene cleanup;
- marketing work;
- store-page copywriting;
- content expansion;
- broad optimization without release impact.

Small fixes in these areas are allowed when they directly remove a shipping blocker or material launch risk.

Do not delay release readiness by starting unrelated improvement campaigns.

Record worthwhile out-of-scope findings separately.

---

# Preserve the Existing Product

This is a stabilization pass.

Except when correcting a confirmed release problem, preserve:

- gameplay rules;
- visual identity;
- progression;
- balance;
- network protocols;
- persistence semantics;
- player-facing behavior;
- existing supported-platform behavior.

A last-minute release pass that introduces unnecessary product changes creates additional launch risk.

Favor:

> **small, high-confidence, easy-to-validate fixes**

over:

> **ambitious pre-release redesign**

---

# Release Risk Over Refactor Elegance

When two fixes solve the same release problem, prefer the one with:

- lower regression risk;
- simpler implementation;
- easier validation;
- smaller dependency surface;
- easier rollback.

This is not the stage to demonstrate architectural sophistication.

Do not introduce major foundational abstractions merely to make release code look cleaner.

---

# Preserve Existing Work

Inspect version-control state before substantive modification.

Identify relevant:

- modified files;
- staged work;
- untracked source;
- pending migrations;
- release configuration changes already in progress.

Do not:

- overwrite unrelated development work;
- revert unfamiliar changes;
- delete ambiguous files;
- use destructive version-control commands merely to create a clean worktree.

When existing changes overlap release work:

1. inspect them;
2. determine their apparent purpose;
3. preserve that intent;
4. integrate carefully;
5. avoid broad rewrites where a bounded change will work.

A shipping pass that destroys legitimate development work is a failure.

---

# Capability-Aware Execution

Use whatever release capabilities are actually available.

If the environment provides access to:

- project files;
- build tools;
- compilers;
- game engine;
- package tooling;
- tests;
- runtime execution;
- platform SDKs;
- CI;
- server infrastructure;

use them directly where appropriate.

If only part of the release path is available:

- complete everything that can be verified;
- distinguish tested facts from inference;
- identify what could not be verified.

If direct implementation is impossible:

- do not pretend changes were made;
- provide precise, actionable patches or configuration changes;
- identify the access required to finish validation.

Do not assume:

- a particular engine;
- operating system;
- repository structure;
- platform;
- build tool;
- distribution service;
- CI provider;
- deployment model.

Infer these from the project.

---

# Shipping Means the Built Product, Not Just Development Mode

Do not treat:

> **works in development**

as equivalent to:

> **works when shipped**

Many release failures exist only in:

- exports;
- release-mode builds;
- clean environments;
- machines without development tools;
- production configuration;
- packaged resources;
- first-run state;
- upgraded installations.

Test the closest available equivalent of the actual release artifact.

If a packaged build can be created:

> **test the packaged build.**

Do not rely exclusively on:

- editor play mode;
- IDE execution;
- hot reload;
- local development servers;
- development databases;
- accumulated developer-machine state.

---

# Clean-Environment Thinking

Repeatedly ask:

> **What assumption is the developer machine satisfying that a player's machine will not?**

Examples:

- pre-existing directories;
- installed SDKs;
- environment variables;
- writable project directory;
- development certificates;
- cached assets;
- local-only configuration files;
- services already running;
- absolute filesystem paths;
- symlinks;
- package-manager caches;
- developer authentication;
- previous build output.

Hunt these assumptions aggressively.

---

# Investigate Before Asking Questions

Use project evidence before asking for clarification.

Inspect relevant:

- build scripts;
- export settings;
- release presets;
- CI workflows;
- deployment scripts;
- package definitions;
- platform configuration;
- version files;
- environment configuration;
- documentation;
- runtime behavior;
- tests;
- package contents;
- save formats;
- migrations;
- production service configuration.

Ask for clarification only when:

- release intent genuinely cannot be established;
- a production credential or external decision is required;
- multiple incompatible release targets are equally plausible;
- a risky player-data migration requires approval;
- legal or ownership information cannot be inferred safely;
- external platform configuration is required but unavailable.

Do not ask questions merely because release investigation takes effort.

---

# Implementation Over Checklist Production

The checklist exists to generate an **implementation queue**.

Do not spend most of the task:

- creating spreadsheets;
- writing hypothetical launch plans;
- cataloguing every possible platform requirement;
- generating risk prose without acting.

Once an actionable shipping problem is understood:

> **fix it.**

Use:

> **inspect → build → package → test → diagnose → fix → rebuild → retest**

repeatedly.

---

# Establish the Release Target

Determine intended release platforms from project evidence.

Look for:

- engine export presets;
- CI matrices;
- build scripts;
- platform SDKs;
- application IDs;
- package identifiers;
- platform-specific code;
- deployment scripts;
- documentation;
- release configuration.

Do not invent platform requirements.

If the project targets only one platform, do not spend this pass adding unrelated platforms.

If multiple intended platforms exist, validate all reasonably available ones.

---

# Establish the Release Path

Map how source becomes the player-facing artifact.

Conceptually:

> **source → dependencies → generated resources → compile/export → package → distribute → install/extract → first launch → runtime services → persistence**

Determine the project's actual steps.

Identify every point where release failure can occur.

---

# Establish Baseline Release Validation

Before broad modifications, attempt relevant existing validation.

Possible checks include:

- clean build;
- release-mode build;
- production export;
- package generation;
- automated tests;
- smoke launch;
- platform validation;
- installer validation;
- resource-reference validation;
- schema validation;
- release-script dry run.

Record pre-existing failures.

Do not automatically attribute them to later modifications.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports independent workers, agents, subprocesses, or parallel contexts, use them where they materially improve coverage.

Do not require delegation.

A single capable session must still be able to perform the work sequentially.

Good independent release workstreams may include:

- one target platform build;
- package-content audit;
- metadata audit;
- debug-residue audit;
- persistence review;
- production-configuration review;
- dependency/runtime review;
- first-run review.

Serialize work involving shared:

- build scripts;
- version infrastructure;
- persistence schemas;
- production endpoints;
- platform authentication;
- shared packaging;
- migration logic.

Do not allow parallel workstreams to create conflicting release configurations.

---

# Shipping Priority Queue

## P0 — Hard Release Blocker

Examples:

- release build does not compile;
- package cannot be generated;
- packaged executable crashes;
- required resources are missing;
- production authentication is unusable;
- saves corrupt;
- required migration destroys data;
- production server cannot start.

Fix immediately.

## P1 — Serious Launch Risk

Examples:

- fresh machine cannot launch;
- package is missing a dependency;
- development endpoint ships;
- dangerous debug functionality is exposed;
- first-run path fails;
- upgrade breaks valid saves;
- major platform integration fails;
- serious release-only errors occur;
- packaged behavior materially differs from development behavior.

Prioritize heavily.

## P2 — Production Quality Risk

Examples:

- incorrect metadata;
- broken external links;
- placeholder application information;
- excessive production logging;
- incomplete error presentation;
- package clutter;
- inconsistent release configuration.

Fix where worthwhile.

## P3 — Final Shipping Cleanup

Examples:

- small metadata inconsistency;
- minor log cleanup;
- minor package cleanup;
- low-impact release-document mismatch.

Address after blockers.

---

# Clean Build Test

One of the most important questions is:

> **Can this project build correctly from a clean state?**

Where practical:

1. preserve legitimate work;
2. remove or isolate generated build output safely;
3. perform documented bootstrap/dependency steps;
4. run the release build.

Look for hidden dependence on:

- stale generated output;
- developer caches;
- untracked files;
- local configuration;
- previous builds.

A release that only works incrementally is a shipping risk.

---

# Reproducible Build Review

Compare multiple clean builds where practical.

Look for:

- nondeterministic missing assets;
- race-sensitive generation;
- build-order dependencies;
- machine-sensitive paths;
- timestamp-sensitive failures;
- environment-sensitive output.

Perfect byte-for-byte reproducibility is not required unless the project demands it.

The release process should, however, be dependable.

---

# Build-Flag Review

Inspect release-specific conditionals.

Examples:

- debug/release;
- development/production;
- editor/runtime;
- client/server;
- platform-specific flags.

Look for:

- inverted conditions;
- release-only code that has never been exercised;
- production accidentally depending on debug initialization;
- production functionality hidden behind development conditions.

Release-only code paths require direct validation.

---

# Release Configuration Audit

Search for development configuration accidentally active in production.

Examples:

- debug mode;
- verbose logging;
- developer console;
- cheats;
- test servers;
- staging APIs;
- localhost;
- mock data;
- fake purchases;
- artificial latency;
- profiler overlays;
- collision visualization;
- development authentication bypass;
- test accounts.

Classify carefully.

Debug infrastructure may be intentionally retained but disabled.

Do not delete useful diagnostics simply because they exist.

Ensure production defaults are intentional.

---

# Localhost and Development Endpoint Hunt

Search source and configuration for:

- `localhost`;
- `127.0.0.1`;
- local ports;
- development domains;
- staging hosts;
- local database addresses;
- test API URLs.

Determine whether each can reach the release artifact.

Fix unsafe production configuration.

Do not blindly replace strings without understanding environment selection.

---

# Secrets and Credentials Review

Inspect whether source or release artifacts expose:

- private API secrets;
- signing credentials;
- database passwords;
- service credentials;
- private keys;
- administrator tokens.

Do not print secret contents.

If legitimate secrets are discovered:

- preserve confidentiality;
- remove unsafe embedding where practical;
- use the project's existing secret/configuration mechanism;
- identify rotation requirements if exposure already occurred.

Do not invent unnecessary secret-management architecture.

---

# Package Content Audit

Inspect the actual final package or export.

Look for required:

- executable;
- runtime libraries;
- configuration;
- assets;
- shaders;
- localization;
- fonts;
- save templates;
- license files;
- platform SDK files where required.

Also look for accidental inclusion of:

- source code;
- credentials;
- development databases;
- debug dumps;
- logs;
- huge unused assets;
- editor metadata;
- internal notes;
- test fixtures;
- old package output.

The package should include what players need and exclude obvious development debris.

---

# Resource Inclusion Test

Development environments may automatically expose resources that packaged builds omit.

Inspect dynamically loaded or indirectly referenced:

- assets;
- scenes;
- shaders;
- fonts;
- localization;
- configuration;
- data files;
- plugins.

Explicitly exercise content loaded through:

- strings;
- reflection;
- runtime registries;
- dynamic manifests;
- optional scenes.

---

# Asset Reference Validation

Where tooling permits, check for:

- missing textures;
- missing models;
- missing sounds;
- missing scenes;
- broken resource paths;
- deleted resources still referenced;
- invalid dynamically loaded paths.

Packaging often exposes issues hidden in the editor.

---

# Case-Sensitivity Test

Different target platforms may expose filename errors hidden by case-insensitive filesystems.

Look for mismatches such as:

- `Player.png` versus `player.png`;
- `Assets/` versus `assets/`.

Use platform-appropriate validation only where relevant.

---

# Filesystem Path Review

Search for assumptions involving:

- project-relative paths;
- executable directory;
- current working directory;
- user documents;
- application-data directories;
- temporary directories;
- writable installation directories.

Released games should normally write user state to appropriate writable locations.

Do not assume the installation directory is writable.

---

# Build-Then-Install Test

Where practical:

1. build the release artifact;
2. package it;
3. install or extract it into a fresh location;
4. launch from that location;
5. run representative gameplay.

Do not test only from a developer-oriented build directory when players receive a different package layout.

---

# Read-Only Installation Test

Where relevant, assume the installation directory is not writable.

Check whether the game attempts to write:

- saves;
- settings;
- caches;
- logs;
- generated runtime files;

into the installation directory.

Use the intended user-data path instead.

---

# First-Run Test

Test from a state resembling a new player's machine.

Remove or isolate existing user-specific state safely.

Check:

- startup;
- directory creation;
- default configuration;
- save initialization;
- account/session initialization;
- platform initialization;
- graphics/audio defaults;
- permissions;
- required network behavior.

First-run bugs frequently remain invisible on a developer machine with years of accumulated state.

---

# Fresh User Profile Test

Where practical, launch without prior:

- save data;
- settings;
- caches;
- authentication session;
- generated local state.

This exposes hidden dependencies on prior development runs.

---

# Returning Player Test

Also test using valid existing player state.

Shipping must support both:

> **new player**

and:

> **returning player**

where applicable.

---

# Existing-User Upgrade Test

If the product can update existing installations, test representative prior valid state where available.

Inspect:

- saves;
- settings;
- caches;
- database state;
- account profiles;
- local configuration.

Ask:

> **What happens when an existing player installs this release over a previous version?**

Do not assume every installation is clean.

---

# Save Compatibility Pass

If local saves exist, test:

- new save;
- save → exit → reload;
- repeated save/load cycles;
- representative prior valid saves;
- optional or missing fields;
- version upgrades;
- invalid/corrupt data handling.

Ensure current release code:

- recognizes supported prior data;
- handles unsupported data intentionally;
- does not silently erase recoverable state.

Treat destructive migration as high risk.

---

# Save Path Review

Ensure saves use a reliable location.

Check:

- permissions;
- platform conventions;
- multiple profiles;
- development-path leakage;
- current-working-directory assumptions.

Do not relocate existing save paths casually when released users already depend on them.

A migration may be required.

---

# Save Corruption Handling

Where appropriate, inspect behavior with:

- malformed save;
- partially written save;
- interrupted write;
- unsupported version.

The game does not need to recover every corrupt file.

It should avoid:

- endless startup crash loops;
- silently overwriting recoverable data;
- ambiguous data loss;
- repeated failed migrations without explanation.

---

# Atomic Persistence Review

For important player data, determine whether interruption during save can produce dangerous partial state.

Possible established approaches may include:

- temporary file then replace;
- transactional database update;
- versioned write;
- backup/previous-valid-state preservation.

Do not impose elaborate persistence architecture without evidence.

Address obvious corruption risk.

---

# Upgrade and Migration Test

If migration exists:

1. create or obtain representative previous state;
2. launch the upgraded version;
3. allow migration;
4. verify the resulting state;
5. relaunch;
6. confirm migration does not repeat incorrectly.

Migration should be:

- version-aware;
- safe;
- idempotent where appropriate;
- resistant to partial completion.

---

# Failed Migration Behavior

Where practical, inspect what occurs if migration cannot complete.

Avoid leaving data silently half-upgraded.

Do not run destructive migration testing against real production data.

Use isolated test state.

---

# Database Migration Review

If schema changes are included:

1. inspect the intended migration path;
2. validate migration order;
3. validate existing-data compatibility;
4. validate application behavior before/after migration;
5. validate partial-failure behavior;
6. inspect rollback assumptions where applicable.

Do not rewrite already-applied migration history casually.

Treat production-data changes as high-risk work.

---

# Production Database Safety

Where server-side persistence exists, inspect release-relevant:

- required columns;
- type compatibility;
- migration order;
- application startup against expected schema;
- transaction boundaries;
- required indexes for newly introduced release-critical queries.

Do not perform destructive testing against real production data without explicit authorization.

---

# Multiplayer Release Pass

If multiplayer exists, test release-oriented scenarios:

- server startup;
- client connection;
- authentication;
- session join;
- representative gameplay;
- disconnect;
- reconnect;
- server restart;
- version mismatch;
- persistence across reconnect where applicable.

Inspect where production differs from development assumptions.

---

# Client/Server Version Compatibility

Determine whether mismatched versions can occur.

Where relevant, handle incompatibility intentionally.

Avoid:

- mysterious crashes;
- corrupted state;
- undefined network behavior.

A clear rejection of an unsupported version is often safer than attempting incompatible communication.

---

# Production Server Configuration

Where applicable inspect:

- bind addresses;
- ports;
- public/service endpoints;
- database connection;
- logging;
- worker configuration;
- environment selection;
- TLS/proxy expectations;
- startup order;
- required services.

Do not turn this into broad infrastructure optimization.

Focus on launch correctness.

---

# Platform Integration Pass

For every platform clearly part of the intended release, inspect the integration that actually exists.

Potential areas include:

- correct application ID;
- SDK initialization;
- account identity;
- authentication;
- achievements;
- cloud saves;
- overlays;
- rich presence;
- ownership/entitlements;
- lobby/session APIs;
- platform storage;
- platform-specific build settings.

Do not implement unrelated platform features merely because the SDK supports them.

Validate the intended integration.

---

# Development Platform IDs

Search for:

- test app IDs;
- sandbox identifiers;
- sample IDs;
- development environments;
- fake ownership configuration.

Ensure production does not accidentally use development identifiers.

Preserve separate development configuration where useful.

---

# Offline / Platform Failure Behavior

Where platform services can be unavailable, test behavior appropriately.

The game may legitimately require an online platform.

But service failure should not unintentionally produce:

- unexplained infinite loading;
- crashes;
- corrupted sessions;
- permanent broken state.

Follow existing product intent.

---

# Web Release Pass

If the game targets the web, inspect relevant:

- production build;
- asset paths;
- base URL;
- server MIME requirements;
- caching;
- service-worker behavior where present;
- websocket/API URLs;
- HTTPS/mixed-content problems;
- browser console errors.

Do not add web support unless it is an intended platform.

---

# Executable and Application Metadata

Inspect release-facing metadata where available:

- application title;
- version;
- developer/company where already known;
- icon;
- executable name;
- bundle/package identifier;
- application ID.

Remove obvious placeholders such as:

- `MyGame`;
- `TestProject`;
- engine-default names;

when the project clearly establishes the intended value.

Do not invent unknown legal or company information.

---

# Versioning Pass

Determine where project version information is defined.

Look for multiple conflicting sources.

Where appropriate establish clear authority for:

- player-facing version;
- package version;
- internal build number;
- network protocol version;
- save schema version.

Do not merge semantically different version concepts unnecessarily.

Ensure the release artifact exposes the intended version consistently where relevant.

---

# Build Number Review

If public version and internal build number both exist, ensure their relationship is intentional.

Avoid accidental reuse where target platforms require unique build identifiers.

Do not invent additional version infrastructure without need.

---

# Release Asset Pass

Inspect production-facing assets such as:

- application icon;
- splash;
- loading visuals;
- cursor;
- window title;
- crash/error branding.

Look for:

- engine defaults;
- placeholders;
- missing assets;
- broken sizes/resolutions;
- obviously temporary presentation.

This is not a broad visual-polish pass.

Fix obvious release-level omissions only.

---

# Legal and Dependency Notice Review

Where the project already maintains third-party notices, licenses, or attribution files, confirm required release files are included appropriately.

Do not perform speculative legal analysis.

If requirements cannot be established from project evidence, report the ambiguity.

---

# Credits Review

If credits exist, verify they:

- load;
- display;
- do not contain obvious placeholders;
- use intended existing names/data.

Do not invent missing personal credits.

---

# External Link Review

Inspect existing player-facing links such as:

- support;
- website;
- privacy;
- community;
- patch notes;
- account management.

Look for:

- localhost;
- staging destinations;
- placeholder domains;
- malformed links;
- obviously obsolete paths.

Do not invent new destinations.

---

# Crash-on-Launch Hunt

Explicitly inspect startup assumptions involving:

- configuration parsing;
- save initialization;
- platform SDKs;
- graphics initialization;
- audio initialization;
- networking;
- directories;
- dynamically loaded resources;
- service availability.

Launch should either:

- succeed;

or:

- fail intentionally and diagnostically.

---

# Missing Dependency Test

Determine whether the release artifact assumes software installed only on development machines.

Examples:

- runtime redistributables;
- external libraries;
- system packages;
- runtime frameworks;
- command-line utilities;
- locally linked dependencies.

Follow the project's established deployment method.

Do not redistribute third-party software based on guesswork.

---

# Dependency Release Review

Inspect required third-party dependencies for release-blocking problems.

Look for:

- missing runtime packages;
- development-only local paths;
- local or Git dependencies unavailable during clean builds;
- unstable development snapshots causing concrete release problems.

Do not run a broad dependency-upgrade campaign.

Change dependencies only when an actual release issue warrants it.

---

# Production Logging Pass

Production logs should be useful without becoming:

- enormous;
- spammy;
- secret-bearing;
- performance-heavy;
- confusing.

Inspect high-frequency:

- debug output;
- stack dumps;
- network payload logging;
- player-data output.

Remove inappropriate development noise.

Preserve useful diagnostics.

---

# Sensitive Data in Logs

Where applicable, ensure logs do not unnecessarily expose:

- authentication tokens;
- private messages;
- passwords;
- credentials;
- sensitive account information.

Fix obvious unsafe logging.

Do not turn this task into a broad compliance program.

---

# Error Presentation

Inspect player-visible release failures such as:

- server unavailable;
- login failure;
- save-load failure;
- unsupported version;
- connection failure;
- platform initialization failure.

Avoid exposing:

- stack traces;
- internal file paths;
- raw database errors;
- secret configuration;
- implementation-only identifiers.

Use existing product-appropriate failure handling.

---

# Assertions and Development Crashes

Inspect assertions or development-only fatal behavior that may execute in release.

Determine whether each:

- represents a truly impossible state;
- is omitted appropriately from release;
- should instead degrade gracefully;
- could cause an avoidable player-facing crash.

Do not blanket-remove assertions.

They can be valuable development safeguards.

---

# Cheat and Debug Feature Review

Search for:

- noclip;
- invulnerability;
- item spawning;
- level manipulation;
- teleport tools;
- admin UI;
- debug hotkeys;
- developer consoles;
- profiling overlays.

Determine intended release behavior.

Appropriate outcomes may include:

- disabled in production;
- development-only compilation;
- authentication or permission gating.

Do not delete legitimate administrator/moderation functionality merely because it is powerful.

Ensure ordinary players cannot access development cheats unintentionally.

---

# Test Data Hunt

Search release-reachable content for:

- dummy accounts;
- fake NPCs;
- test items;
- test levels;
- debug scenes;
- sample saves;
- placeholder text;
- test configuration.

Do not delete something merely because its filename contains `test`.

Determine whether it can actually reach players.

---

# TODO / FIXME Release Hunt

Search TODO/FIXME markers for shipping-relevant unfinished work.

Classify each as:

- genuine release blocker;
- technical note;
- future enhancement;
- obsolete comment.

Do not treat every TODO as a blocker.

Implement only release-relevant unfinished work.

---

# Placeholder Hunt

Search player-visible content for obvious placeholders:

- `TODO`;
- `TBD`;
- `Lorem ipsum`;
- `Placeholder`;
- unintended `Coming soon`;
- temporary icons;
- engine-default names;
- internal labels.

Do not invent missing content when intended wording cannot be established.

Remove clear accidental development residue.

---

# Localization Packaging

If localization exists, verify:

- intended locale files are packaged;
- fallback language works;
- the release build can find translations;
- paths are not development-only.

Do not perform translation-quality review here.

---

# Settings Persistence

Test representative settings such as:

- graphics;
- audio;
- controls;
- UI scale;
- account or server selection where applicable.

Check:

> **change → exit → relaunch**

Ensure behavior matches intended persistence.

---

# Graphics Defaults

Inspect first-run graphics configuration.

Avoid defaults that are obviously:

- unsupported;
- catastrophically expensive;
- broken;
- invisible;
- incompatible with intended minimum hardware where known.

Do not broadly rebalance graphical quality.

Focus on safe startup.

---

# Window / Display Release Test

Where relevant test:

- fullscreen;
- windowed mode;
- resolution changes;
- restart;
- monitor/display assumptions;
- persisted window state.

Look for:

- invisible window;
- off-screen startup;
- invalid saved resolution;
- crashes caused by display configuration.

---

# Audio Release Test

Check that packaged builds include and initialize required audio resources.

Look for:

- missing audio banks/assets;
- release-only path failures;
- startup crashes;
- absent required runtime libraries.

Do not turn this into an audio-polish pass.

---

# Input Release Test

Verify intended release input methods still work in the packaged artifact.

Examples may include:

- mouse;
- keyboard;
- controller;
- touch.

Look for:

- editor-only bindings;
- missing configuration;
- development-only input maps.

Do not add input schemes the product does not intend to support.

---

# Packaging Size Review

Inspect package size for obvious mistakes.

Examples:

- raw source archives;
- duplicate build output;
- enormous debug dumps;
- embedded test data;
- multiple copies of the same generated content.

Do not perform aggressive asset compression merely to reduce package size.

Fix clear accidental bloat.

---

# Generated File Review

Determine which generated artifacts are required for the release.

Ensure the release pipeline:

- generates required files reliably;
- does not depend on stale local output;
- includes required generated runtime resources;
- does not require forgotten manual generation.

This is closely related to clean-build reliability.

---

# CI / Release Automation Review

If release workflows already exist, inspect:

- triggers;
- environment assumptions;
- artifact generation;
- version injection;
- platform matrices;
- secret references;
- failure handling;
- package publication steps.

Fix clear defects.

Do not build an enterprise-scale CI system if the project releases manually and does not need one.

---

# Manual Release Path Review

If releases are manual, determine whether existing scripts/documentation make the process reliable enough.

If a repeated manual step is:

- fragile;
- easy to forget;
- objectively automatable;
- directly relevant to shipping;

small automation may be justified.

Avoid unnecessary release infrastructure.

---

# Platform-Specific Path Review

Inspect path behavior only for platforms the project actually targets.

Be cautious about assumptions involving:

- path separators;
- executable extensions;
- home directories;
- application-data directories;
- filesystem case sensitivity;
- permissions.

---

# Time / Locale / Region Sanity

Where actual systems depend on:

- date/time;
- locale;
- number formatting;
- region;
- timezone;

inspect release-breaking assumptions.

Do not start a broad internationalization project.

Fix concrete launch or persistence problems.

---

# Time Zone / Wall-Clock Dependence

If game systems rely on wall-clock time, inspect:

- timezone assumptions;
- daylight-saving transitions;
- offline clock changes;
- server/client clock disagreement.

Only address this when actual project systems depend on these concepts.

---

# Version Display

Where players can view version information, ensure it corresponds to the actual artifact.

Possible locations:

- main menu;
- settings;
- logs;
- crash output;
- support diagnostics.

This can significantly improve supportability.

Do not add unnecessary visual clutter.

---

# Supportability Pass

Released games eventually generate support requests.

Ensure obvious failures can be diagnosed reasonably.

Useful existing mechanisms may include:

- version in logs;
- meaningful error messages;
- build identification;
- server version;
- crash output.

Do not create a massive telemetry system as part of this pass.

---

# Crash Diagnostics

If crash reporting already exists, verify production configuration.

If none exists, do not automatically integrate a new third-party platform.

Use existing project tooling unless lightweight diagnostic improvement is clearly justified.

---

# Release Security Sanity Pass

This is not a penetration test.

Perform a basic shipping-level review for:

- credentials in artifacts;
- test authentication bypass;
- development admin routes;
- dangerous debug commands;
- security-sensitive decisions accidentally made client-authoritative in production.

Treat serious findings appropriately.

Do not perform offensive security work outside authorized project scope.

---

# Release Notes / Changelog Inputs

If release mechanics depend on existing changelog/version files, verify they are coherent.

Do not write marketing release notes unless requested.

---

# Final Player-Facing Development Residue Hunt

Inspect the actual release artifact for accidental:

- debug overlays;
- coordinates;
- FPS counters;
- entity IDs;
- raw enum values;
- stack traces;
- developer-only buttons;
- test menu entries;
- temporary messages;
- staging references;
- engine defaults.

Remove worthwhile release-visible residue.

---

# Release-Only Code Paths

Search specifically for production-only or release-only branches.

These are often less tested than development behavior.

Exercise relevant:

- production authentication;
- production endpoints;
- release logging;
- platform SDK initialization;
- packaging/resource lookup;
- environment selection;
- server production startup.

---

# Network Failure During First Launch

If online services are required, test representative:

- service unavailable;
- timeout;
- DNS/network failure;
- rejected authentication;
- maintenance/unreachable server state.

Expected behavior might be:

- retry;
- offline mode;
- clear failure;
- exit.

Follow product intent.

Avoid unintended:

- infinite spinners;
- crashes;
- corrupt sessions.

---

# Server Restart Behavior

For multiplayer products, inspect:

- client behavior during restart;
- reconnect;
- persistence;
- stale sessions;
- invalid post-restart authority.

Do not redesign the entire reconnect architecture.

Fix obvious launch-dangerous behavior.

---

# Production Feature Flags

Inventory important release flags.

Ensure:

- experimental features are intentionally enabled or disabled;
- obsolete flags do not create contradictory configuration;
- required production functionality is enabled.

Remove obsolete flags only when confidently unused.

---

# Work in Shipping Waves

Do not attempt everything at once.

## Wave A — Build and Package

Get:

- clean release build;
- export;
- package;

working reliably.

Fix hard blockers.

Validate.

## Wave B — Launch and First Run

Test:

- fresh environment;
- startup;
- configuration;
- runtime assets;
- platform initialization;
- first save.

Fix blockers.

Validate.

## Wave C — Production Integration

Test relevant:

- platform SDK;
- authentication;
- networking;
- production services;
- server startup;
- database migrations.

Treat high-risk systems carefully.

Validate.

## Wave D — Upgrade and Returning Player

Test:

- existing saves;
- settings;
- migrations;
- reconnect;
- version compatibility.

Validate.

## Wave E — Release Residue

Search for:

- placeholders;
- debug flags;
- test endpoints;
- incorrect metadata;
- missing icons;
- development logging;
- packaging clutter.

Fix worthwhile findings.

## Wave F — Final Release Candidate

Create the closest possible equivalent to the actual release candidate.

Treat it as:

> **the exact artifact that will be sent to players**

Then validate it accordingly.

---

# Reassess After Every Wave

Ask:

- What could still prevent shipping?
- What still requires a developer machine?
- What release-only code has not been exercised?
- What could destroy existing player data?
- What could cause a first-run crash?
- What could fail after an update?
- What production configuration remains suspicious?
- What player-visible development residue remains?
- What platform-specific requirement remains unverified?
- What recently changed area now has the highest launch risk?

Reprioritize.

---

# Productive Shipping Loop

Do not stop after one successful build.

Release defects often appear in layers.

Examples:

- clean build reveals package failure;
- package fix reveals missing runtime resource;
- launch fix reveals incorrect production endpoint;
- production endpoint reveals authentication failure;
- update test reveals migration problem;
- final package exposes debug content.

Continue:

> **build → package → launch → test → diagnose → fix → rebuild → retest**

while clear, material, safely actionable shipping risk remains.

Do not manufacture work merely to continue.

Stop when remaining concerns are:

- dependent on unavailable credentials or hardware;
- external platform-dashboard tasks;
- external approvals;
- unsupported platforms;
- speculative;
- low impact;
- outside scope.

---

# Fresh-Machine Review

Review the release with no assumptions about the development environment.

Ask:

> **What would fail if this artifact were placed on a machine that had never seen this repository before?**

Look for:

- missing directories;
- absolute paths;
- missing dependencies;
- stale generated files;
- required development services;
- untracked configuration;
- cached resources;
- developer-only authentication.

Fix supported findings.

---

# Returning-Player Review

Ask:

> **What could break for a player who already has saves, settings, account state, cached data, or an older installation?**

Prioritize:

- data preservation;
- compatibility;
- migration;
- stale-cache handling;
- server/client version compatibility.

---

# "What Still Looks Like a Development Build?" Review

Inspect the release artifact for:

- debug tools;
- engine defaults;
- placeholder metadata;
- console spam;
- temporary text;
- staging URLs;
- test data;
- profiler overlays;
- internal names.

Remove worthwhile residue.

Do not turn this into a broad visual-polish task.

---

# Commercial Release Risk Review

For commercial releases, perform a final technical review focused on:

> **What could cause this build to fail launch, violate basic player expectations, create immediate support problems, or appear obviously unfinished?**

Do not drift into:

- marketing strategy;
- subjective gameplay critique;
- store copy;
- content evaluation.

For each meaningful finding establish:

## Release Area

Build / Package / Launch / Platform / Persistence / Production / Player-Facing.

## Problem

What is wrong?

## Evidence

What proves or strongly supports it?

## Impact

What could happen during release or to players?

## Fix

What should change?

## Scope

Tiny / Small / Medium / Large.

Implement justified findings.

---

# Independent Review of High-Risk Changes

Where practical, review dangerous fixes with fresh context.

This is especially important for:

- save migrations;
- database migrations;
- cloud-save conflicts;
- authentication;
- ownership/entitlement logic;
- networking authority;
- production data changes;
- signing architecture;
- update compatibility;
- irreversible deployment changes.

The purpose is not approval.

Ask:

> **How could this fix still destroy data, fail only in production, repeat incorrectly, break compatibility, or become difficult to roll back?**

Repair justified findings.

---

# Anti-Last-Minute-Refactor Review

Before completion, inspect what this shipping pass itself changed.

Ask:

- Did we rewrite more than necessary?
- Did we introduce new architecture?
- Did we modify unrelated gameplay?
- Did we add unnecessary dependencies?
- Did we increase migration risk?
- Did we create avoidable platform-specific complexity?
- Can any risky fix be simplified?
- Did a release fix create a new source of truth?

Release candidates should converge toward stability.

Undo unjustified complexity.

---

# Final Release Candidate Validation

When worthwhile fixes are exhausted:

1. perform a clean release build;
2. generate the intended package/export;
3. inspect package contents;
4. install or extract into a release-like location;
5. launch from the release artifact;
6. test first-run behavior;
7. test representative gameplay;
8. save and reload;
9. test returning-player state where applicable;
10. test migrations where applicable;
11. test networking/platform integration where available;
12. inspect production logs;
13. verify version and metadata;
14. confirm no new regression was introduced.

Treat failures at this stage seriously.

---

# External and Unverifiable Requirements

Some release requirements cannot be validated from source or the current environment.

Examples:

- store approval;
- platform dashboard configuration;
- unavailable signing certificates;
- production credentials;
- external legal approval;
- console hardware;
- external production deployment access;
- platform-specific certification.

Do not pretend these were validated.

Report them explicitly as:

> **Not verifiable in the current environment.**

Continue completing all repository-controlled work that can still be verified.

---

# Release Blocker Classification

At the end, classify unresolved release concerns.

## BLOCKER

Release should not proceed until resolved.

Examples:

- crash;
- corruption;
- unusable release build;
- broken authentication;
- broken persistence;
- packaging failure;
- required migration failure.

## HIGH RISK

Release may technically function, but the problem could seriously harm players or operations.

## ACCEPTABLE FOLLOW-UP

Does not justify delaying release based on available evidence.

Do not inflate cosmetic issues into blockers.

---

# Completion Standard

The shipping pass is complete when, to the degree the available environment can establish:

1. the intended release build can be produced;
2. clean-build behavior has been validated where practical;
3. required runtime resources are present in packaged artifacts;
4. obvious development-only files are not accidentally shipped;
5. the release artifact launches successfully;
6. first-run behavior works;
7. representative gameplay works from the release artifact;
8. saving/loading works where applicable;
9. representative returning-player state works where applicable;
10. required migrations work where applicable;
11. production configuration is correct to the extent verifiable;
12. development endpoints are not accidentally active;
13. dangerous debug/cheat functionality is not unintentionally exposed;
14. major intended platform integration works to the extent available for testing;
15. multiplayer production paths work where applicable;
16. release metadata is coherent;
17. obvious placeholders and development residue are reduced;
18. major release-only errors and warnings are addressed;
19. no known repository-controlled P0 blocker remains unresolved;
20. high-risk fixes received appropriate additional scrutiny;
21. no known regressions introduced by the shipping work remain;
22. remaining concerns require external credentials, platform approval, unavailable hardware, external decisions, or low-value follow-up.

The objective is not:

> **prove launch can never fail**

The objective is:

> **eliminate all clearly identifiable repository-controlled reasons this game is not ready to be shipped to real players.**

---

# Final Report

When complete, provide a concise release-readiness report.

## 1. Release Status

Choose exactly one:

- **READY**
- **READY WITH EXTERNAL / DOCUMENTED RISKS**
- **NOT READY**

Explain briefly.

Do not declare **READY** while a known repository-controlled blocker remains.

## 2. Target Platforms

State which intended release targets were identified.

Distinguish:

- validated;
- partially validated;
- unavailable for validation.

## 3. Build Status

Report:

- clean build;
- release build;
- export;
- package;

as applicable.

## 4. Major Shipping Problems Fixed

Summarize important:

- build;
- packaging;
- launch;
- production configuration;
- release-only;

fixes.

## 5. First-Run Validation

State what was actually tested.

## 6. Persistence / Upgrade

Summarize relevant:

- saves;
- migration;
- returning-player state;
- compatibility.

## 7. Platform / Multiplayer

Summarize only integrations that actually exist.

## 8. Production Configuration

Describe meaningful production configuration corrections.

## 9. Development Residue Removed

Summarize significant:

- debug;
- placeholder;
- staging;
- test;

content removed, corrected, or disabled.

## 10. Validation Performed

State exactly which:

- builds;
- packages;
- installs/extractions;
- launches;
- save/load cycles;
- migrations;
- platform checks;
- networking checks;
- smoke tests;

were actually performed.

Do not imply tests occurred when they did not.

## 11. External / Unverifiable Requirements

List anything that could not be validated because of:

- credentials;
- external services;
- hardware;
- store dashboards;
- approval;
- production access.

## 12. Remaining Risks

For each meaningful unresolved risk include:

- **Risk**
- **Severity**
- **Why unresolved**
- **Release impact**
- **Recommended next action**

Do not pad this section with low-value speculation.

## 13. Final Shipping Recommendation

State clearly:

- whether any known repository-controlled blocker remains;
- whether the artifact is technically ready to release based on the validation actually completed.

---

# Final Directive

**Think like the person responsible for pressing the release button and answering for what happens afterward.**

Do not trust:

> **it works on my machine**

Do not trust:

> **it works in the editor**

Do not trust:

> **the build worked last week**

Do not trust:

> **the migration looks simple**

Do not trust:

> **players probably already have that directory**

Do not perform speculative refactors immediately before release.

Do not add new features merely because release testing exposed an opportunity.

Do not ship development configuration accidentally.

Do not assume clean installs and upgrades behave the same.

Do not risk player data for architectural cleanliness.

Do not report external validation as complete when access is unavailable.

Repeatedly ask:

> **Can we build it cleanly?**

> **Can we package it correctly?**

> **Can a fresh player launch it?**

> **Can a returning player update safely?**

> **Are production services and configuration actually production-ready?**

> **What assumptions are being satisfied only because this is a developer machine?**

> **What could still turn launch day into an emergency?**

Continue:

> **inspect → build → package → launch → test → fix → rebuild → retest**

while meaningful repository-controlled shipping risk remains.

Leave behind the **same game**, but make the project substantially safer, more reproducible, more production-ready, and more defensible to actually release.