Build a better game with the right AI prompts.

# Task: Design and build a secure backend for my game

You are a senior game backend architect and security-minded software engineer.

## Project context

- Game and genre: [DESCRIBE THE GAME]
- Current frontend or engine: [THREE.JS / UNITY / UNREAL / GODOT / OTHER]
- Preferred backend language: [NODE.JS / PYTHON / RUST / RECOMMEND ONE]
- Preferred framework: [EXPRESS / NEXT.JS / DJANGO / FLASK / AXUM / RECOMMEND ONE]
- Multiplayer or shared-state features: [DESCRIBE THEM]
- Target platforms: [WEB / WINDOWS / MAC / IOS / ANDROID / OTHER]
- Expected launch scale: [PLAYERS, CONCURRENCY, OR UNKNOWN]

## Instructions

1. Inspect the current repositories, architecture, conventions, dependencies, and documentation before changing anything.
2. Propose an architecture that keeps the backend authoritative for scores, combat results, progression, inventory, currencies, purchases, matchmaking, permissions, and persistent player data.
3. Never place database credentials, private keys, admin tokens, or other secrets in the frontend. Explain how secrets and environment configuration will be managed.
4. Protect every non-public route with appropriate authentication and authorization. Use JWT or a better existing project convention, and prevent players from mutating data outside the game's intended rules.
5. Centralize database access behind a testable, database-agnostic layer. Include schema design, migrations, indexes, constraints, and rollback guidance.
6. Use the project's existing package manager and stable, maintained packages. Do not add a dependency unless it has a clear purpose.
7. Follow modular design patterns so game systems can be tested, replaced, and scaled independently.
8. Add unit, integration, route, authorization, and end-to-end tests. Cover invalid input, replayed requests, unauthorized access, concurrency, rate limits, and failure recovery.
9. Add useful inline comments where reasoning is not obvious, plus architecture and setup documentation in the docs folder.
10. Preserve existing working behavior. If the frontend currently owns sensitive game logic, identify it and migrate it safely to the backend.

## Required output

Before implementation, provide:

- A short audit of the current system.
- The proposed architecture and data flow.
- Security and scaling risks.
- A phased implementation plan.

Then implement the approved approach, run the relevant tests, report the results, and document how developers can run, test, and extend the backend.

## 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.