id: design: Bevy incorporation — ID worlds as Bevy applications (ECS mapping of the entity/triple model) #5781

Summary

Design the incorporation of ID worlds into Bevy: how a world's entity/triple state maps onto Bevy's ECS, how journal events drive a Bevy application, and what it means for a Bevy app to host or join a world — as Bevy's own design line.

Motivation

Bevy currently appears only as a name inside other designs: #788 lists "Bevy or Qt" as candidate frameworks for the reference native shell (a conformance question), and #5686 lists "a game engine integration (Bevy named)" as one of five capability-provider targets (a provider-model question). Neither designs the incorporation itself — the state mapping, the event flow, the authority model. Drew's 2026-11-04 instruction is explicit: each platform thing gets its own design issue rather than riding inside a bundle. A game engine is also the stress case for the whole client story: tick-driven, frame-budgeted, and stateful in ways a terminal never is — if the shell contract and the triple model survive Bevy, they survive anything.

Sketch

• State mapping: ID entities ↔ Bevy Entity; triples/components ↔ Bevy Components; the mapping's ownership rules (which side is authoritative for what) stated per data class — world state, presentation state, purely local state.
• Event flow: journal appends and state deltas in; shell-contract input events out. How journal positions map to Bevy schedules/ticks, and what a frame is allowed to not apply yet (interpolation, prediction) without violating the presenter contract.
• Authority postures: Bevy app as presenter-client; as world host (an embedded server); as both (id: Phase 13 F13.8 multi-server, multi-client topology; client-only mode always supported #790's simultaneity) — and which posture the design blesses first.
• Determinism: the game loop against the deterministic replay infrastructure (its own design issue) — a recorded world stream replayed through Bevy must land on identical state; the soak/replay oracles are how engine integration bugs get caught.
• Provider face: what the engine offers as a design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 capability provider — render surfaces, audio, input devices — under the same grant model as every other provider.

Open questions

• Where the bridge lives: inside id-worlds, as a separate bridge crate on the pkgs/id: split the monolith crate into sub-crates along module seams (prioritized by Drew 2026-11-01) #3447 seams, or as a Bevy plugin crate owned outside the workspace?
• Bevy version policy: Bevy's release cadence vs the workspace's — pin, track, or abstract behind the mapping?
• Does the WIT/component-model decision in id: Phase 13 F13.6 native client shells on the shell contract #788 change the bridge's shape, or is the bridge contract-level only?
• 2D-first, 3D-first, or headless-logic-first as the proving target?

Relations

Parent: epic #2056. Relations: #788 (shell contract + framework decision record — this design consumes it), #5686 (capability providers — Bevy as one provider class, designed there in the abstract, here concretely), #790 (client/server simultaneity), #3447 (crate seams). Filed in the 2026-11-04 gap pass (WS-F) per Drew's order that Bevy gets its own design issue.