Runtime: frame scheduler, event system, subsystem manager; ties every other crate into the main loop.
[SubsystemManager] is the one place in the workspace allowed to know
about every *-core at once (see docs/dependency-rules.md rule 7) — it
owns real instances of the driver-independent subsystems that exist
today: an ecs-core [World], physics-core's body list and
pipeline, and audio-core's listener/mixer. graphics-core isn't
wired into [Runtime::tick] yet: graphics-driver has a real
windowed wgpu device now (see docs/roadmap.md's winit/windowing
entry), but graphics-core itself has no scene/material vocabulary or
GPU-submission bridge yet to turn its RenderGraph into actual draw
calls, so there's no frame in the render sense for Runtime::tick to
schedule. This crate deliberately doesn't depend on graphics-driver
directly (see docs/dependency-rules.md: engine-core depends on
graphics-core, not drivers) — a windowed app composes
platform_core::run_windowed_app
with its own graphics-driver::Device/Surface and reuses
[Runtime::tick]'s [Time] for animation/physics timing (see the
spinning_cube example), rather than Runtime gaining rendering
awareness before graphics-core has anything to submit. Real audio
output follows the same composition pattern: the app owns an
audio-core::AudioOutput (the core→own-driver bridge over
audio-driver) and feeds it Mixer::render_interleaved blocks each
tick — see the audible_scene example; Runtime itself stays
driver-free on the audio side too.
[Runtime::tick] advances physics, then recomputes audio gains from
the physics-updated emitter frames, in that order — not through
[FrameScheduler]/task-core's JobGraph, deliberately: physics and
audio are the only two real per-frame systems today, and they have a
genuine sequential data dependency (audio reads positions physics just
wrote), not two independent branches. Wrapping a strictly sequential
two-step in a job graph would be decorative, not functional — the same
reason compute-runtime's task-core dependency isn't wired in yet
(see that crate's module doc). [FrameScheduler] is real and tested on
its own terms; it becomes load-bearing once a second real per-frame
system exists that's genuinely independent of physics (animation,
particles, ...) to run alongside it.