@volter/world-core
v2.0.35
Published
The kernel of Volter World: one log per twin, branches as pointers, checkpoints, the fold that keeps a twin current, the head that performs a write against the vendor, references, and the git plane. A twin package builds on it; the runtime serves it.
Readme
@volter/world-core
The shared state kernel and vendor-independent runtime libraries used by @volter/twin-<vendor>.
The product CLI and SDK are in @volter/world.
State and branching
The model is the canonical explanation: one logical log, checkpoints, a branch's parent position and its own entries, and simulated or real execution at the head. Push lands entries in a parent; deploy performs them against the vendor and records receipts. The Git-inspired verbs do not imply staging, commits or a Git object database.
The file store has inherited entries (events.jsonl), branch entries (actions.jsonl),
branch.json, a fetched URL-parent cache (origin.jsonl) and checkpoints. These are storage
segments of that model, not independent observed-state and local-action truth systems.
See log.ts for the format and state-system.ts for
execution. Payloads use the blob storage contract.
Building a twin
A protocol-2 twin implements its vendor's request/response semantics while the shared kernel
owns log ordering, checkpoints, branching and the head's state system. Use the tree readers and
write path exported by src/index.ts; do not reconstruct a serve-time view by
folding the log or use removed v1 confirmation/suppression APIs.
Architecture owns the boundaries and
adding a twin owns the implementation and verification
process. Package protocol standing is recorded in the generated index.
Conformance tooling is a development dependency in @volter/world-tooling.
