Snapshots and branches
Explore independent branches while sharing unchanged state and preserving current authority.
Status: Development. Recursive data forks, retained immutable snapshots, durable lineage and bounded three-way document merges are implemented. Complete workspace and Git coordination remains later work; full prototype acceptance is open.
A world is a working context
A workspace can bring together a repository reference, a database branch and the project context for the work. A child workspace can branch again and expose the same kinds of operations as its parent.
This recursive model is useful for a proposed release, an alternate plan, a data correction or a research path. Each world should remain understandable through its lineage and explicit scope.
Keep five things separate
| Layer | What it records |
|---|---|
| Logical lineage | Which workspace a new workspace came from. |
| Git history | Repository identity and the chosen commit/ref. |
| Database state | The captured immutable root and the branch's later head. |
| Working copy | Materialized files and explicitly captured uncommitted changes. |
| Runtime | Processes, credentials, ports and permission to cause effects. |
Logical children do not require physically nested checkout directories. Git linked worktrees share a repository while providing separate working copies. The intended coordinator places materialized worktrees in controlled sibling locations and records their relationship in the workspace manifest.
Share the past, own the next change
The current state engine can fork a live branch at an expected head. Its child initially retains the same data root. Later parent writes do not appear in that child; child writes do not mutate the parent. Grandchildren follow the same rule.
Deleting a parent branch does not invalidate retained descendants. Branch identities remain tombstoned, and retained snapshots own their data independently. Data-root retention is constant work, while catalog/receipt updates still have costs.
Merge deliberately
The intended merge compares a retained common base, a source snapshot and a target snapshot. Conflicting records, schema changes, uniqueness rules and graph endpoints must be checked. Applying a prepared merge must reject a moved target head.
Git and RURAL are separate durable resources. The future coordinator needs recorded steps and restartable reconciliation; it cannot promise one atomic transaction spanning a Git checkout and a database commit.
Opening a branch must not restart copied jobs, duplicate business effects or restore revoked access. Historical governance content is context; current authority still controls execution.
See the state engine for the implemented boundary and security model for the authority requirements.