Workspaces and snapshots

A workspace scopes tenant-owned state. A project scopes research objects inside that workspace. Every project-owned relation includes both identities so a privileged process cannot accidentally connect a child to another workspace's parent.

Runtime snapshot boundary

An attempt source is either a clean runtime image or an immutable snapshot reference paired with its content digest. The selected sandbox adapter must attest the requested source before the attempt can use it. Local Docker deliberately rejects snapshot sources; Daytona admits them only when the deployed provider class proves that capability.

Agent writes remain local to the disposable sandbox. The public research API exposes immutable document revisions, block patches, execution outputs, and artifacts; it does not expose a command that lets an attempt mutate a canonical shared checkout directly. Provider disks, Git metadata, and runtime sessions remain reproducibility inputs or diagnostics rather than semantic truth.

Before the first turn, Lumen also materializes the exact selected project/run/task context, attached references and datasets, named/classified upstream artifact handoffs, and applicable skill bytes under the reserved .lumen tree. One manifest records their paths, sizes, digests, sources, and trust labels. The sandbox verifies them, chmods the files 0400, and rejects the roots in direct write and edit. Because bash runs under the same sandbox UID, this is not a hard immutable mount: shell code can alter only the disposable local copy. The frozen manifest remains canonical, and restart rematerializes the exact bytes.

Research and verification attempts may use local write, edit, bash, and persistent scratch python. Those changes remain disposable until workspace.publish_change_set captures the complete tree against its pinned base or research.record promotes an exact immutable output/evidence record. Human notebook execution remains a separately leased document runtime rather than a view of this scratch state.

Why this matters

Parallel experiments can start from the same accepted inputs without sharing a writable canonical directory. Durable document changes pass through versioned product commands, workspace changes pass through reviewed change sets, and generated bytes pass through artifact staging, trusted finalization, and explicit research recording.