Build a better game with the right AI prompts.

# Task: Design and implement a safe deployment pipeline for my game

You are a senior platform engineer, DevOps engineer, and game release manager.

## Project context

- Repositories: [FRONTEND / BACKEND / SDK / MONOREPO PATHS]
- Hosting provider: [CURRENT PROVIDER OR ASK FOR A RECOMMENDATION]
- Database: [TYPE AND HOSTING]
- Target environments: [LOCAL / TEST / STAGING / PRODUCTION]
- Expected player traffic: [DESCRIBE OR UNKNOWN]
- Current deployment process: [DESCRIBE IT]

## Audit first

Inspect the repositories, tests, build commands, Docker configuration, environment variables, secrets, database migrations, hosting setup, domains, monitoring, and current documentation. Identify anything that could cause downtime, data loss, security exposure, or an untested release.

## Pipeline requirements

1. Use the project's existing CI/CD and hosting conventions when they are sound.
2. Run formatting, linting, unit, integration, end-to-end, security, and build checks appropriate to each repository.
3. Stop the deployment when required tests fail.
4. Build reproducible artifacts or Docker images and verify them before release.
5. Keep secrets in the hosting or CI secret manager, never in source control or frontend bundles.
6. Validate database migrations, backups, compatibility, and rollback before production changes.
7. Use a low-downtime release strategy appropriate to the provider, such as rolling, blue-green, or canary deployment.
8. Add health checks, smoke tests, logs, metrics, alerts, error tracking, and post-deployment verification.
9. Define an automatic or clearly documented rollback path for failed application and database releases.
10. Separate development, test, staging, and production configuration.
11. Account for frontend hosting, backend services, databases, static assets, caches, queues, multiplayer services, and CDN delivery that this game actually uses.
12. Document ownership, recurring costs, scaling limits, incident steps, and how a new developer performs a release.

## Required output

- Current-state audit.
- Proposed architecture and deployment flow.
- Cost and complexity tradeoffs.
- Implementation plan.
- Pipeline configuration and infrastructure changes.
- Test and verification results.
- Rollback drill results or a safe procedure for running one.
- Complete release and troubleshooting documentation.

## Player-readable output requirement

Everything shown to a player must be written and presented for a human player, not for a developer or debugger. This includes menus, HUD labels, buttons, prompts, tutorials, objectives, dialogue, tooltips, loading and save states, empty states, confirmations, warnings, errors, rewards, notifications, accessibility messages, and connection or recovery states.

Use concise plain language, the game's established terminology and tone, recognizable icons with text where meaning could be ambiguous, and a clear next action. A player-facing error should explain what happened in useful terms, whether progress is safe, and what the player can do next.

Never expose raw exceptions, stack traces, JSON, database IDs, internal event names, enum or variable names, file paths, debug coordinates, HTTP status codes without explanation, server implementation details, developer TODOs, placeholder text, or raw telemetry on a player-facing surface. Send technical details to development-only logs, diagnostics, telemetry, or an authenticated support view. A short support reference code may be shown to the player only when it helps support locate the private diagnostic record.

Verify representative success, failure, offline, loading, empty, permission, validation, timeout, save, reconnect, and recovery states from the player's perspective. Developer documentation and final engineering reports may remain technical; this requirement applies to anything the game presents to players.

## Required game documentation

Documentation is part of the definition of done for this task.

Before finishing:

1. Read the existing README, docs directory, architecture notes, decision records, and AI instructions that apply to this system.
2. Update the existing relevant documentation instead of creating a competing document or a second source of truth.
3. If no relevant document exists, create a clearly named Markdown document in the game's established documentation directory. Use docs/ when the project has no existing convention.
4. Document the current system, the decisions made, ownership and lifecycle rules, configuration, files or assets changed, commands and tests run, known limitations, and how another developer should extend or troubleshoot the work.
5. Update AI_INSTRUCTIONS.md or the project's equivalent when this task changes architectural boundaries, required workflows, naming rules, or validation commands.
6. Keep documentation accurate to the implementation. Do not claim support, measurements, or test coverage that was not verified.
7. In the final report, list every documentation file created or updated.