One transaction, one store, one door.

One command, one transaction

An authoritative mutation performs one transaction. Design §12.2 sets the requirement plainly:

"If the process dies after commit and before reply, replay returns the stored result. If it dies before commit, none of state, event, outbox, budget, or idempotency result exists."

"Normalized state is the query model, and the immutable ledger is the audit/attention record. They commit together and recovery tests prove they cannot diverge."

The implementation puts every one of those things inside the same IMMEDIATE transaction, so a check-and-act is a real compare-and-swap rather than a hopeful read followed by a write:

Two details matter more than they look. The §11.8 result-size bound is judged inside the transaction, so an over-large result is refused rather than committed and then found unreturnable. And the event append enqueues its own outbox notification, so there is no window where an event exists with nobody told about it.

Replay and refusal

The dedup key is a triple — (actor_scope, operation, idempotency_key) — and actor_scope encodes the surface, the actor and the realm. A worker's key is scoped to its invocation; an owner's to its realm. Two actors cannot collide, and neither can two surfaces.

What is compared on a repeat is not the raw bytes but a canonical request digest over version, surface, operation, realm, project, expected revision, arguments and extensions — deliberately excluding the request id and trace headers, so a genuine retry of the same intent matches even though its envelope differs. Three outcomes:

Crash-honesty

The interesting claim is not that the transaction is atomic — SQLite gives you that — but that the daemon around it does not leak or duplicate at the two moments that matter. That is tested by killing the real process, not by mocking a failure.

The store carries two crash hooks, armed from the environment as KOVEED_ABORT=<phase>:<operation>. The phase names a point — immediately before commit(), or after commit but before the reply is written — and at that point the process calls std::process::abort(). No unwinding, no destructors, no flushing: the same thing a power cut does.

The crash matrix spawns the actual koveed binary armed this way, fires the target command, asserts the daemon dies before replying, then restarts on the same database and checks:

• before commit — the committed event count is exactly what it was. Nothing survives.
• after commit — the count is exactly one higher. The transaction survived exactly once.
• project sequences are still dense, 1..n with no gaps, in both cases;
• the client's idempotent retry produces exactly one committed effect;
• a second retry is byte-identical to the first and commits nothing new.

Twenty such matrices cover project, space, contribution, relation, frontier, assembly and invocation creation, artifact upload and finalize, lifecycle changes, prepared widening, participants, grants, dispositions, lenses, reactions, aliases and application events — each at both phases. One further test crashes after an artifact finalize commits, confirms the plaintext staging copy really does survive the crash, and then that the startup sweep removes it and that replaying the cleanup is idempotent.

The acceptance test goes further and cuts the worst possible moment in a live agent loop: a real Python assistant, over the worker socket, with the daemon armed to die after its synthesis contribution commits but before the reply reaches the SDK. On restart the SDK's bounded retries replay, and the ledger is asserted to hold exactly one synthesis, exactly one addresses relation, one succeeded invocation, and a context assembly holding exactly the question with zero omissions. Re-running a completed invocation is refused as stale rather than handed its old receipts.

The store

One SQLite database, <data-dir>/kovee.db, opened with:

Schema changes are numbered migrations keyed to SQLite's own user_version; there are 10 of them today. The DDL and the version bump commit together, so a crash between them cannot strand the database half-migrated.

First start bootstraps the installation identity, the personal realm, and the key material the rest depends on — the cursor secret, the privacy chain key, the governance scope key and the realm object key. Bootstrap is idempotent, and an older database missing a key mints it at open rather than failing.

The ledger and its cursors

Events carry two dense sequences — one per stream, one per project — both allocated inside the transaction, so an aborted transaction consumes no number and a gap in the sequence is a real anomaly rather than routine. Uniqueness is a database constraint on both pairs, not a check in Rust.

Clients never see a raw sequence. A cursor is kc1.<hex payload>.<hex HMAC>, minted under the installation's cursor secret and bound to the source it was minted for. A cursor from another installation, another source, or a truncated paste is indistinguishable from a forgery and returns invalid. Possession still grants nothing: authorization is rechecked at read time, every time.

events_read pages forward from a cursor with a limit capped at 512. events_wait long-polls from one — and it takes the store lock only while it looks, releasing it between polls, so a waiting reader never blocks a writer. Replies are capped at 1 MiB and requests at 256 KiB.

The audit chain

Alongside the ledger there is an append-only audit log, hash-linked: each entry's hash covers the previous hash, the sequence, the timestamp and the length-framed event and detail, starting from a genesis of thirty-two zero bytes. It is body-free — it records that a command happened and under what authority, not what was said — and it is written inside the command transaction, so there is no committed command without a matching audit row. A verifier walks the chain and re-derives it.

The sealed consumption authority

Model egress is gated by one type. The rule it enforces: no byte leaves without a valid byom execution-consumption receipt for this exact execution key.

Four operations exist on that authority, and each verifies the previous one's keyed tag rather than assuming it, so the chain is authenticated end to end under a single secret the call site never supplies:

Every property in that diagram is a compile error to violate, not a convention:

• every field is private; no type has a public constructor;
• no type implements Deserialize, so no permit can be conjured from JSON;
• ExecutionPermit is not Clone, and dispatch takes it by value — using one twice is a use-of-moved-value error;
• the spent ledger is a sealed trait: its supertrait lives in a private module, so no outside crate can implement it and no call site can supply a ledger that forgets;
• the transport trait and the live HTTPS wire are crate-private, so nobody hands the broker their own wire.

One door per process

In a build with the daemon feature — only koveed enables it — there is exactly one public function that yields the authority. It answers once: a process-wide atomic flag is swapped on the first call, and every later call returns nothing, including one made with different key material. koveed takes it behind a lock so two threads racing cannot burn the grant, and if it ever comes back empty the daemon refuses the model call rather than proceeding under an authority it did not make.

The durable single-use claim is one conditional UPDATE that moves a consumption row from unspent to spent, and it happens before the socket opens. If the update moves no row — because the consumption never existed, or was already spent — dispatch terminalizes without sending anything. A ledger error is a refusal too: a use that cannot be recorded is a use that does not happen.

Proved against rustc

Those refusals are checked by a test that shells out to rustc directly. For each case it compiles a control snippet that must succeed and a denied snippet that must fail, and asserts that rustc's own stderr contains the expected error code and wording. There are 24 such cases in a build without the daemon feature, and the count itself is asserted, so deleting a case fails the test.

Why not a compile_fail doctest: one of those passes when the snippet fails to compile for any reason, including a typo, and rustdoc does not enforce the error code even when you write one. The gate also refuses to guess which build artifact it is testing — it compiles a fingerprint witness against every candidate library and demands exactly one survivor, because an earlier mtime-based pick once read a stale artifact and reported a mutant as green.

What is not closed

The crate map

15 crates in one workspace.

unsafe_code is denied across the workspace; the one documented exception is a geteuid call in the CLI. Everything canonicalized or digested lands with golden vectors that two independent re-derivers — one Python, one TypeScript, sharing no code with the Rust — check in CI: 415 vectors against 197 schemas.