From Local Project to Live Draft

For Pascal Editor, “saved,” “live,” and “local” describe different transitions in the life of a scene. This chapter follows a graph from an in-memory MCP session to durable SQLite data, a browser-visible draft, and a local editor process, while showing where version conflicts and security checks stop the flow. The reader should leave able to tell what another client can actually see, what survives a restart, and what a failed handoff means.

That distinction matters after an agent creates a room. The agent may have a valid graph in memory, but the browser will not see it if no scene is bound. A draft save may update the browser-visible model without being a meaningful checkpoint. A browser may receive a newer snapshot while a second writer is still holding an older one. Pascal's operational architecture is built around making those states explicit rather than collapsing them into one word: done.

stateDiagram-v2 [*] --> InMemoryScene InMemoryScene --> BoundScene: load or bind saved project BoundScene --> DraftSaved: mutation plus draft save DraftSaved --> BrowserEvent: append scene snapshot event DraftSaved --> Checkpoint: explicit meaningful save DraftSaved --> VersionConflict: expected version is stale VersionConflict --> BoundScene: reload current graph BoundScene --> LocalMCPService: connect local agent LocalMCPService --> BoundScene: load and mutate scene LocalMCPService --> [*]: works without web runtime WebEditorRuntime --> BoundScene: open current draft WebEditorRuntime --> [*]: separate install lifecycle

The scene transitions and the runtime transitions are related but not identical. A local MCP service can be running before the web runtime is installed. A graph can be persisted before a browser opens it. A conflict can stop publication even though the local graph is syntactically valid. Keeping those paths separate is the key to understanding Pascal's “live draft” behavior.

A scene can be changed without being saved

The MCP bridge begins as an in-memory session. It can create a default site, read or mutate nodes, and use the core store's undo and redo. That is enough to construct a graph, but it does not by itself bind the graph to a saved project. Live-sync logic reports this condition explicitly: if there is no active scene, a mutation remains in memory and returns a warning that nothing was persisted or sent to browser subscribers.

Binding gives the graph a durable destination. An agent can create a project, load an existing scene, or save the current graph. Once the bridge knows the scene identity and current version, later semantic mutations can publish the updated graph against that destination. This is why an agent workflow begins with project or scene binding rather than assuming that a default in-memory scene is already visible to a person.

Pascal distinguishes a draft from a checkpoint. A draft is the browser-visible working model that can be updated repeatedly while an agent or person iterates. A checkpoint records a meaningful saved revision rather than turning every small adjustment into a milestone. The distinction is useful for both users and storage: frequent iteration should not be confused with a series of deliberate versions.

The distinction also clarifies what is lost. An unbound in-memory change can be undone during the process, but another process cannot load it from the local database. A draft can survive a process boundary if it was saved, but it may not represent a deliberate release point. A checkpoint can be used as a durable milestone, but it still describes the graph and its stored metadata, not a guarantee that every browser projection or real-world building requirement has been checked.