Project layout
All project state lives under projects/<project-id>/ in the checkout (lib/paths.py defines PROJECTS_DIR, overridable with OPENMONTAGE_PROJECTS_DIR). Upstream layout, created by lib.checkpoint.init_project:
projects/<id>/
project.json marker: id, title, pipeline_type, created_at
checkpoint_<stage>.json
history/ archived checkpoint versions
events.jsonl tool events written by BaseTool instrumentation
artifacts/ script.json, scene_plan.json, asset_manifest.json ...
assets/{images,video,audio,music}/
renders/*.mp4projects/ is git-ignored upstream, so it is host-local by design. Local and hosted checkouts are independent: nothing is synchronised between machines. The hosted checkout currently includes demos, the official studio-hyperframes-demo example served by HyperFrames Studio, and flowmaster-isms; see Zero-key render walkthrough for the preserved render evidence.
What the hosted surfaces can write
| Surface | State |
|---|---|
| Backlot unit | ProtectSystem=strict, ProtectHome=read-only; only .backlot/ is writable |
Backlot projects/ view | read-only; the watcher only reads |
| Remotion Studio | writable editor for the served remotion-composer checkout |
| HyperFrames Studio | writable editor for the served projects/studio-hyperframes-demo example |
| Renders shown in Backlot | produced outside Backlot, never by that service |
The public login gate controls access; it does not make the Studio editors read-only.
Provider keys
Upstream reads credentials from .env (see .env.example) and config.yaml. Deployment record: at deployment the hosted checkout had no .env and no keys — image, video, voice, music and LLM providers all unconfigured. This is a record of how the host was set up, not a fresh check. Consequently, as deployed:
- only the Remotion zero-key path can produce output on this host;
make setupwas deliberately not run: it copies.env.exampleto.env, attempts an optionalpiper-ttsinstall and warms an unpinnednpx hyperframescache;- no cloud fallback is substituted for a missing offline dependency, and no paid generation occurs.
Introducing a provider later means a root-owned, mode 0640 env file outside the checkout, referenced from the unit with EnvironmentFile=, following the neighbouring chat service pattern — and only after the key’s spend policy is agreed.
Wiki content rule
This wiki publishes operating knowledge only: commands, checkout-relative paths, observed versions and behaviour. Project media, prompts, key values, bearer tokens and private receipts stay in the checkout and the operator’s local notes.