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/*.mp4

projects/ 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

SurfaceState
Backlot unitProtectSystem=strict, ProtectHome=read-only; only .backlot/ is writable
Backlot projects/ viewread-only; the watcher only reads
Remotion Studiowritable editor for the served remotion-composer checkout
HyperFrames Studiowritable editor for the served projects/studio-hyperframes-demo example
Renders shown in Backlotproduced 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 setup was deliberately not run: it copies .env.example to .env, attempts an optional piper-tts install and warms an unpinned npx hyperframes cache;
  • 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.