Concepts

Transactions and sync

Copy Markdown

How Inkfinite validates edits, records history, and merges peer changes.

Inkfinite groups related operations into transactions, validates them against the current document, and records accepted changes in Automerge history.

Transactions

A transaction has an ID, an actor, optional preconditions, and one or more operations. Operations create, patch, move, or delete records. Grouping a coherent edit in one transaction keeps validation, history, and review tied to the user’s request.

Preconditions can require specific document heads or record versions. Inkfinite rejects the whole transaction when those expectations are stale, when a selector is ambiguous, or when an operation would cross a shape or layer lock. A rejected transaction does not partially modify the canonical file. Permissioned integrations can apply caller policy before submitting a valid transaction. agent_editable is not a document-engine lock.

Undo and redo

The editor records transactions in its history. Undo applies the inverse of an accepted local edit. Redo reapplies an edit that was undone. Because history belongs to the document model, both the web and desktop editors use the same behavior.

An edit may become impossible to undo after later changes remove or replace the records it depended on. Inkfinite reports the conflict instead of reconstructing an uncertain result.

Proposal review

A desktop session can hold an agent transaction as a proposal against known document heads. The review panel lists affected objects, metadata, and relationships, while the canvas previews added, changed, moved, and removed content. Reviewers can accept all or part of a proposal or reject it. Accepting and rejecting both clear the preview. Stale proposals must be refreshed against the current document before acceptance.

Synchronization

Automerge assigns document heads to the current causal state. Two peers can make changes from a shared base and merge them without choosing one entire file over the other.

The CLI includes the heads returned by inspect and query as transaction preconditions. If a human or another agent edits the document first, the stale transaction fails. Inspect the new heads, query the affected records again, and rebuild the intended change from current state.

The current local file and desktop proposal workflows provide this concurrency model without claiming a hosted synchronization service. A live desktop proposal can also become stale while it waits for review. Review the refreshed preview before accepting it.