# ADR 0001: Roadmap Architecture

## Status

Accepted

## Context

The project is a Bevy FPS foundation with a runtime game, shared authoring data, and an in-process editor. The long-term goal is a server-authoritative multiplayer FPS that can also serve as a reusable Bevy engine/editor toolkit.

The architecture needs to keep early editor work productive while avoiding choices that would make later deterministic simulation, networking, and web support expensive.

## Decision

Keep the current `game`, `shared`, and `editor` crates for M0/M1, but treat them as stepping stones toward a stricter split:

- `shared` owns reflectable authoring types and scene hydration until it can be renamed or split into a scene-focused crate.
- `game` owns native client presentation, player input, rendering, audio, UI, and glue.
- `editor` owns native editor tooling and editor-only dependencies.
- Future deterministic gameplay moves out of `game` into a simulation crate that can be reused by the native client, a headless server, and tests.
- Future network protocol types move into a protocol crate shared by client and server.
- Runtime app startup/windowing stays narrow and reusable so both the game and editor launch consistently.

## Consequences

This preserves the current M1 editor velocity while setting boundaries for later milestones. Gameplay code should avoid depending on editor systems, and reusable authoring/simulation code should avoid native-only editor dependencies.

The project will add CI and focused local verification now, then expand tests around determinism, scene migration, and networking as those crates appear.

## Follow-Ups

- M2 extracts deterministic simulation and input-as-intent systems.
- M3 adds the server-authoritative networking spike and chooses the production netcode stack.
- M5 formalizes scene schema versioning and migrations.