Sprimo/docs/ARCHITECTURE.md

Sprimo Frontend Architecture

Workspace Layout

• crates/sprimo-app: process entrypoint and runtime wiring.
• crates/sprimo-api: axum-based localhost control server.
• crates/sprimo-config: config schema, path resolution, persistence.
• crates/sprimo-platform: platform abstraction for overlay operations.
• crates/sprimo-protocol: shared API/state/command protocol types.
• crates/sprimo-sprite: sprite pack manifest loading and fallback logic.

Runtime Data Flow

1. sprimo-app loads or creates config.toml.
2. App builds initial FrontendStateSnapshot.
3. App starts sprimo-api on a Tokio runtime.
4. API authenticates commands and deduplicates IDs.
5. Commands are bridged from Tokio channel to Bevy main-thread systems.
6. Bevy systems apply commands to sprite state, window/platform operations, and config persistence.
7. Shared snapshot is exposed by API via /v1/state and /v1/health.

Sprite Reload Semantics

• SetSpritePack uses a two-phase flow:

1. Validate and build candidate pack runtime (manifest + clips + atlas layout + texture handle).
2. Commit atomically only on success.

• On reload failure, current pack remains active and snapshot last_error is updated.

Threading Model

• Main task: startup + shutdown signal.
• API task: axum server.
• Bridge task: forwards API commands into Bevy ingest channel.
• Bevy main thread: rendering, animation, command application, and window behavior.
• Optional hotkey thread (Windows): registers global hotkey and pushes recovery events.
• Snapshot is shared via Arc<RwLock<_>>.

Design Constraints

• Bind API to localhost only.
• Token auth by default for mutating and state endpoints.
• Keep protocol crate renderer-agnostic for future backend/frontend reuse.
• Keep platform crate isolated for per-OS implementations.