Use the workspace store for loading, atomic saves, and operation history #9

New issue

Closed

opened 2026-07-30 04:05:44 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-30 04:05:44 +00:00

(Migrated from github.com)

Problem

PR #3 defines load-workspace, save-workspace, and append-operation, but the control plane bypasses them.

workspace-for creates workspaces directly in an in-memory hash table. Successful mutations increment revision and broadcast events without saving through the store or appending an operation record. The workspace journal is therefore not authoritative, replayable, or durable.

Found during review of PR #3.

Required changes

Resolve a workspace by calling load-workspace before creating a new one.
Define a consistent unit-of-work/commit API for workspace state and journal entries.
Save successful single mutations through the store before acknowledging or broadcasting.
Save successful transactions atomically and append a complete transaction record.
Populate operation history with:
- operation/transaction ID
- workspace ID
- base and committed revision
- command(s)
- authoritative result(s)
- timestamp
- client/principal metadata
Do not emit events or acknowledge success if persistence fails.
Ensure memory-store uses the same behavior and semantics as future CouchDB implementations.
Add store failure injection tests.

Acceptance criteria

Restarting/recreating the control plane with the same store restores the workspace.
Every successful mutation has a corresponding journal entry.
Failed persistence leaves authoritative in-memory state unchanged and emits no success event.
Transactions persist state and journal atomically from the caller's perspective.
Tests verify load, save, append, failure, and replay behavior.

Related PR: #3

## Problem PR #3 defines `load-workspace`, `save-workspace`, and `append-operation`, but the control plane bypasses them. `workspace-for` creates workspaces directly in an in-memory hash table. Successful mutations increment revision and broadcast events without saving through the store or appending an operation record. The workspace journal is therefore not authoritative, replayable, or durable. Found during review of PR #3. ## Required changes - Resolve a workspace by calling `load-workspace` before creating a new one. - Define a consistent unit-of-work/commit API for workspace state and journal entries. - Save successful single mutations through the store before acknowledging or broadcasting. - Save successful transactions atomically and append a complete transaction record. - Populate operation history with: - operation/transaction ID - workspace ID - base and committed revision - command(s) - authoritative result(s) - timestamp - client/principal metadata - Do not emit events or acknowledge success if persistence fails. - Ensure memory-store uses the same behavior and semantics as future CouchDB implementations. - Add store failure injection tests. ## Acceptance criteria - Restarting/recreating the control plane with the same store restores the workspace. - Every successful mutation has a corresponding journal entry. - Failed persistence leaves authoritative in-memory state unchanged and emits no success event. - Transactions persist state and journal atomically from the caller's perspective. - Tests verify load, save, append, failure, and replay behavior. Related PR: #3