Durable files, independent writers
The public vstd engine owns the presentation file format, player, editing HUD, and semantic reconciliation. The private Cloud service owns identity, tenant authorization, durable revisions, hosted execution, billing, and publication. GitHub distributes application source and releases; it is not Cloud presentation storage.
vstd CLIBuilds, serves, validates, exports, and watchesWhere content lives
| Location | Responsibility |
|---|---|
| Cloud Postgres | Revision heads, immutable source manifests, writer checkpoints, replayable save operations, and attribution |
| Cloud object storage | Immutable, content-addressed source bytes, media, and publication artifacts |
| Sandbox working directories | Replaceable browser or agent working copies, restored from durable snapshots |
| Local filesystem | Ordinary HTML/Markdown files, worktrees, and .vstd recovery checkpoints |
| Browser device storage | Pending save requests retained across reloads and retried after reconnecting |
A studio contains studio.yaml, deck metadata, shared assets, and paired decks/<deck>/slides/<id>.html and <id>.md files. HTML holds one root <section class="slide">; Markdown records evidence, intent, talk track, sources, and edit history. deck.yaml stores slide_order, so rearranging slides does not rename their identities. Persistent data-vstd-id attributes identify editable objects.
Saving and reconciliation
The browser records outgoing edits on the device, then sends them with stable operation IDs. Cloud acknowledges a save only after retaining the response and complete writer snapshot in Postgres. Background integration creates an attributable canonical revision; retrying the same operation does not repeat an insertion or create another version.
Each agent edits an isolated worktree based on a known revision. Integration compares the base, writer changes, and current presentation. Independent files, object properties, companion sections, and slide moves merge automatically. If an agent and a person change the same property, the person’s concurrent edit takes priority. Both original inputs remain available in checkpoints; preserving edits does not mean incompatible values can both occupy the same property.
The canvas refreshes from the integrated version without requiring a conflict/reload workflow. Saving never publishes: audience releases remain explicit, immutable, and read-only.
Local synchronization
For a connected studio, vstd cloud sync reconciles in both directions directly through the Cloud API. vstd serve synchronizes automatically while running. There is no background filesystem update when neither the server nor a sync command is running.
The plugin synchronizes before reading or editing connected content. vstd worktree begin --root STUDIO creates an isolated agent directory; vstd worktree finish --root WORKTREE reconciles its delta into the parent and synchronizes the result. Local-only studios use the same worktree mechanism without a Cloud account or network connection.
Trust boundaries
The editor HUD lives in internal/studio/templates/player.html, shared by local and Cloud editing. Themes supply styling, not another player. Cloud navigation, teams, templates, analytics, billing, and authorization stay in the private service.
Sandboxes receive bounded content and scoped execution capabilities, not database or storage credentials. Source reads and writes require current tenant authorization. Audience delivery uses separate origins and read-only publication capabilities. Verified audience identity remains tenant-scoped; anonymous views remain anonymous.
Cloud-owned storage starts with vstd 0.6.0. This is a clean cutover, not a migration of legacy GitHub-backed presentations. Optional Git in a local studio remains a user choice, not a Cloud synchronization dependency.