Runtime and Data Flow

Six-file boundary

File	Ownership
index.html	DOM shell, accessible controls, generated icon sprite, runtime entrypoint
studio.css	Committed generated runtime styling
studio.js	Commands, editor rendering, transport, persistence, import/export, audio orchestration
engine.js	Schema migration, normalization, compilation, evaluation, rendering, export
project-history.js	Bounded immutable undo/redo revisions
asset-cache.js	IndexedDB-backed image/audio cache, keys, quotas, eviction

(README.md:19-33, SVG-Animator-BIBLE.md:95-106)

Canonical flow

project text
  -> parseProjectFile
  -> compileRuntimeProject
  -> evaluateProjectAt
  -> renderScene / renderSceneContent / exportProjectSvg

parseProjectFile bounds and parses imported text, returning a canonical project plus warnings. compileRuntimeProject is the single normalization owner: it validates, migrates, clamps, supplies defaults, repairs references, resolves parameters, and produces an immutable runtime representation. evaluateProjectAt applies global timeline time. Interactive rendering and export consume that same normalized truth. (docs/ARCHITECTURE.md:13-26, SVG-Animator-BIBLE.md:131-146)

Studio caches the compiled runtime and recompiles when the history revision changes, so stage, transport, and export do not normalize independently. (docs/ARCHITECTURE.md:24-26)

Static delivery

Document-relative stylesheet, module, asset, and audio API references allow root-domain static hosting without a base-path shim. Runtime assets are deployed beside the six manifest files; no SPA fallback is required because routes are files, not client-side pages. (index.html:11-13, studio.js:1-17, README.md:5-16)