phronomy 0.25.0 → 0.27.0

data/docs/migrations/storage-backend-composition.md

@@ -0,0 +1,117 @@
+# Storage Backend composition migration
+
+Historical migration step. Its old raw SPI surface is superseded by the
+[neutral Storage SPI 2 migration](neutral-storage-spi.md); use that guide for the
+current backend contract.
+
+
+This change targets the `refactor/architecture` branch after `1b481f6`, with
+shared value operations already owned by `Values::Immutable`.
+It replaces the Beta Backend SPI; the gem version and persisted record formats
+are not changed by this branch-only refactoring package.
+
+## Application construction
+
+An isolated in-memory domain is now constructed with:
+
+```ruby
+require "phronomy"
+
+persistence = Phronomy::Persistence.in_memory
+Phronomy.configure { |config| config.persistence = persistence }
+```
+
+An explicitly selected raw backend is composed once:
+
+```ruby
+require "phronomy"
+
+backend = Phronomy::Storage::Backends::InMemory.new
+persistence = Phronomy::Persistence.new(backend: backend)
+Phronomy.configure { |config| config.persistence = persistence }
+```
+
+Use the same `persistence` instance wherever one storage/ownership domain is
+required. Constructing several facades over one physical backend does not create
+independent data, and their object identities are distinct for callers that use
+Persistence identity to determine a domain. `persistence.backend` exposes the
+selected raw backend for backend-specific administration such as accessing its
+connection pool. Ordinary domain reads and writes still use `persistence`.
+
+## Replaced API
+
+| Previous API | Replacement |
+|---|---|
+| `Persistence::InMemory.new` | `Persistence.in_memory` |
+| Backend subclass of `Persistence` | Backend subclass of `Storage::Backend`, or the same raw protocol |
+| `Persistence.new` with eight raw repository keyword arguments | `Persistence.new(backend: raw_backend)` |
+| Backend `super` with eight repositories | The same arguments passed to `Storage::Backend#initialize` |
+| `Persistence#build_transaction_view` | A raw `Storage::Repositories` view yielded by the backend |
+| `Persistence::DurableRecord` | `Storage::DurableRecord` |
+| `Persistence::ConflictError` / `NotFoundError` / `SerializationError` / `UnsupportedBackendError` | The same names under `Storage` |
+| `Persistence::REQUIRED_CAPABILITIES` | `Storage::Backend::REQUIRED_CAPABILITIES` |
+
+The previous constants/helper/constructor are removed. Rescue the new storage
+error constants. The public `Phronomy::AgentBusyError` admission exception remains.
+This is a source/API migration, not a persisted payload migration.
+
+## SQL implementation changes
+
+A raw SQL backend implements `capabilities`, `transaction`, and
+`assert_agent_watermark!`, and supplies all eight raw repositories to the common
+Backend constructor. It exchanges `Storage::DurableRecord` and explicit ID,
+revision, position, and admission metadata. It does not decode domain types.
+
+In its transaction implementation:
+
+1. Check out a connection and open the database transaction as before.
+2. Bind contents, agents, journals, executions, workflow_states, handoff_states,
+   teams, team_executions, and the watermark object to that same connection.
+3. Construct `Storage::Repositories` with those eight keyword arguments and
+   `watermark:`; yield this raw view inside the database transaction block.
+4. Return the block result; propagate failures through the existing transaction
+   rollback path. Keep the existing handling of indeterminate commit outcomes.
+
+`Persistence#transaction` constructs the corresponding domain facades inside
+that block. SQL code no longer calls `build_transaction_view` or private
+`PersistenceComposition::Repositories` or domain repository wrappers. Application/bootstrap code creates the raw SQL backend,
+then passes it to `Persistence.new(backend:)`.
+
+The SQLite and PostgreSQL implementations in `phronomy-examples` at `231d253`
+use the previous SPI and require this migration. Do not use their unchanged
+sources with the new core. Keep this branch's API change separate from a release
+until the applications/backends to be shipped with it have also migrated.
+
+## Validation
+
+Use the existing explicitly loaded shared contract suite with a composed
+`persistence` value. All eight repositories must still commit or roll back
+together. Validate root and transaction repository binding, CAS/admission and
+watermark checks, record round trips, and codec failure rollback. Perform actual
+SQL tests with the backend's supported database and driver versions; an
+in-memory success does not prove SQL transaction/concurrency behavior.
+
+## Execution constraint errors (ADR-043)
+
+Raw `Storage::Backend` execution repositories must report
+`Storage::ActiveExecutionConflictError`, a `Storage::ConflictError` subtype, when
+an existing nonterminal execution prevents another admission or an idle-only
+operation for that owner. Update the same constraint branches in `save` if the
+backend already checks them. Do not convert unrelated identity/revision failures.
+
+The Agent and Team repository facades translate this subtype into the existing
+`Phronomy::AgentBusyError` while preserving its message and cause. A transaction
+still sees the exception before commit. Public Persistence/Agent/Team callers
+keep their previous busy exception; raw backend callers must update their rescue.
+
+Apply the new core before the migrated SQLite/PostgreSQL sources. Both examples
+require the new storage constant; for coordinated source development set
+`PHRONOMY_PATH` to the updated core checkout before resolving/running their
+bundles. An unchanged legacy backend remains usable through the domain facade
+because its old `AgentBusyError` is passed through, but it does not satisfy the
+new raw conformance checks. No fallback constant aliases are supplied.
+
+Run `a Persistence backend` from `phronomy/testing/persistence_contract`; it now
+includes `storage execution constraint notifications` for both raw execution
+repositories. Keep running the domain repository suites and backend concurrency
+and rollback tests. No schema or serialized data migration is required.

data/docs/migrations/storage-transaction-boundaries.md

@@ -0,0 +1,74 @@
+# Storage transaction boundaries (Refactor 34)
+
+Historical migration step. Its old raw SPI surface is superseded by the
+[neutral Storage SPI 2 migration](neutral-storage-spi.md); use that guide for the
+current backend contract.
+
+
+Update core and the SQLite/PostgreSQL reference adapters together. No data
+migration is required. The public method signatures, eight repository accessors,
+required capability keys and stored record formats are unchanged.
+
+## Explicit nested calls
+
+Nested `Backend#transaction` and `Persistence#transaction` calls on the same
+backend and synchronous execution context now have savepoint semantics.
+
+```ruby
+persistence.transaction do |outer|
+  outer.contents.put_text("keep if outer succeeds")
+  begin
+    persistence.transaction do |inner|
+      inner.contents.put_text("discard on inner failure")
+      raise "inner failure"
+    end
+  rescue RuntimeError
+    # Inner changes have already been rolled back. Re-read conditions needed
+    # for subsequent work through the valid outer scope.
+    outer.contents.put_text("outer may continue")
+  end
+end
+```
+
+Earlier SQL reference versions joined the outer scope. Catching the inner error
+could preserve inner writes. Such writes are now rolled back. A successful inner
+call does not commit independently; failure of the outer call rolls back both.
+The same exception object is propagated after rollback, including
+`ActiveRecord::Rollback`, which ActiveRecord itself normally consumes. Catch
+that exception outside the Storage/Persistence block if continued execution is
+intended. No separate database connection is introduced.
+
+## Invalid Journal batches and database failures
+
+The SQL references now validate and serialize every record and normalize the
+expected position before the first write. An invalid second record cannot leave
+the first inserted with an unchanged Journal head. Record IDs from a rejected
+input batch can be retried with valid data.
+
+This is an input-validation guarantee. A database failure after writing must
+escape the current transaction scope. To continue outer work, establish an
+explicit inner scope before the operation, and catch outside that inner scope.
+Do not catch and ignore database errors inside the failed scope. Unknown commit
+outcomes still require existing reconciliation rules, not blind retries.
+
+## Active Agent execution updates
+
+InMemory now enforces the same active-owner exclusion during update as SQL.
+Trying to reactivate an Agent execution while a different execution for that
+Agent is active raises `Storage::ActiveExecutionConflictError` at the raw boundary
+and does not advance the revision or replace the record. The domain-facing
+repository retains its existing error translation. Team terminal execution
+reactivation remains forbidden.
+
+## Backend authors and remaining migration
+
+Run `phronomy/testing/persistence_contract`, including `a Persistence backend`,
+against each real backend. Explicit nested calls must preserve block results,
+exception identity, inner rollback and outer atomicity across repositories.
+SQL integrations additionally exercise physical constraints, concurrent writers,
+connection failure and durable reload; mocked connection responses do not cover
+those guarantees.
+
+Records/Streams/Blobs, failed-view enforcement and explicit non-local block-exit
+handling are later S2b work. Do not use `return` / `break` / `throw` as portable
+commit controls in the current SPI. See [ADR-057](../decisions/057-storage-transaction-boundaries.md).

data/docs/persistence-backends.md

@@ -1,179 +1,150 @@
-# Persistence backend contract
+# Persistence and neutral Storage SPI 2
 
-`Phronomy::Persistence` is the single durable-state backend abstraction used by
-stateful Agents and durable Workflows. This document is the normative contract
-for authors of custom Persistence backends.
+[ADR-058](decisions/058-neutral-storage-primitives.md) defines the current
+extension contract. This is an intentional breaking replacement of the old
+fixed-repository Backend SPI. Application code keeps `Persistence.new(backend:)`,
+`Persistence.in_memory`, its eight domain repositories and result queries.
 
-The Backend SPI is **Beta**. It may evolve in a minor pre-1.0 release, but a
-backend should not depend on Phronomy private APIs or Runtime internals.
+## Ownership and composition
 
-## Architecture boundary
+Storage owns `Resource`, `Backend`, `View`, `Records`, `Streams`, `Blobs`, immutable
+`Entry` values, guards, conditions and neutral exceptions. It has no Agent/Team
+record types, active-execution policy, content digest algorithm or watermark API.
 
-A backend implements durable storage only:
+Agent, Team, Workflow and ContentStore declare their own resource schemas.
+`PersistenceComposition::StorageSchema` gathers those declarations and
+`PersistenceComposition::Repositories` assembles domain wrappers over a View.
+The Team and Workflow schema files live beside their features in nested loader
+roots; loading metadata does not load their runtime implementations.
+`ContentStore::StoredContents` owns SHA-256 identity and digest verification.
+The Agent-owned `Watermark` composes guarded revision and stream-head conditions.
 
-```text
-Application
-    ↓
-Agent / Workflow
-    ↓
-Runtime / EventLoop / ExecutionCoordinator
-    ↓
-Phronomy::Persistence synchronous Backend SPI
-    ↓
-Database / durable storage
-```
-
-Persistence does not own live Agent identity, top-level Runtime admission, or
-live execution state. In particular, a backend must not persist or reconstruct
-the following as part of this SPI:
-
-- Runtime Agent ownership-registry entries;
-- EventLoop Agent top-level admission entries;
-- EventLoop Agent execution-directory entries;
-- `AgentInvocation`;
-- `FSMSession`;
-- `Task` or callbacks;
-- EventLoop queue contents;
-- Runtime Workflow admission entries;
-- in-flight provider operations.
-
-Persistence operations are synchronous. Framework-owned blocking Persistence I/O
-is submitted to the Runtime OffloadPool by Phronomy; a backend must not post
-EventLoop events or introduce `load_async` / `save_async` variants into this
-contract.
-
-## Required root surface
+InMemory receives `resources:` and supplies one Monitor/snapshot transaction
+across the catalog. SQL reference composition supplies the same catalog and a
+separate physical table/column mapping to the neutral driver in examples
+`shared/storage`. Table names, columns, indexes, DurableRecord envelopes, payloads,
+format versions and content identities remain unchanged.
 
-A Persistence backend exposes eight durable repositories:
+The [S3 closure review](architecture/refactoring-closure.md) records why these
+names and placements remain and separates applied evidence from the candidate.
 
-```text
-contents
-agents
-journals
-executions
-workflow_states
-handoff_states
-teams
-team_executions
-```
-
-and two root operations:
+## Backend and View
 
 ```ruby
-persistence.transaction { |tx| ... }
-persistence.assert_agent_watermark!(
-  agent_id:,
-  agent_revision:,
-  journal_position:
-)
-```
-
-The object yielded by `transaction` is a transaction-scoped Persistence view. It
-must respond to all eight repository accessors and
-`assert_agent_watermark!`. It may be the Persistence instance itself, but SQL
-backends may instead yield an object bound to a checked-out connection or
-transaction session.
-
-## Required capabilities
-
-Every backend must advertise:
-
-```ruby
-{
-  atomic_all: true,
-  atomic_admission: true,
-  optimistic_revision: true
-}
-```
-
-`Phronomy::Persistence::REQUIRED_CAPABILITIES` is the executable definition of
-this requirement.
-
-### `atomic_all`
-
-All durable repositories must be able to participate in one atomic transaction
-domain. A transaction may change `contents`, `agents`, `journals`, `executions`,
-`workflow_states`, `handoff_states`, `teams`, and `team_executions`, and then either commit all changes or roll them all back.
-
-This requirement deliberately does not claim exactly-once semantics after an
-indeterminate database/network failure. If the underlying database cannot tell
-the caller whether a commit happened, the backend should surface the storage
-failure rather than pretending the outcome is known.
-
-### `atomic_admission`
-
-This capability is a **durable Agent execution integrity defense**. It is not the
-primary same-process Agent ownership/admission mechanism and it is not Workflow
-distributed locking.
-
-For one Agent, `executions.create_active` must atomically guarantee both:
-
-```text
-execution_id is unique
-AND
-no active/suspended execution already exists for agent_id
+backend = Phronomy::Storage::Backends::InMemory.new(resources: resources)
+backend.view.records(resource)
+backend.view.streams(resource)
+backend.view.blobs(resource)
+backend.transaction { |view| ... }
+view.check!(guards: guards, conditions: conditions)
 ```
 
-A conflict with an existing active/suspended execution raises
-`Phronomy::AgentBusyError`.
-
-Within one process, Runtime/EventLoop admission is acquired before the initial
-Persistence operation and is the primary competing-execution exclusion
-mechanism. `atomic_admission` remains required as the durable second line of
-defense against stale paths, durable conflicts, and unsupported cross-process
-races. It must not be removed merely because Runtime admission exists.
-
-Workflow admission remains Runtime/process-local. Cross-process Agent or
-Workflow ownership/lease/fencing is a separate distributed-coordination concern
-and is not part of this Backend SPI.
-
-### `optimistic_revision`
-
-The backend must implement compare-and-swap semantics used by Agent roots,
-Agent executions, Journals, Workflow snapshots, and the durable Agent watermark.
-Stale writers must receive `Phronomy::Persistence::ConflictError`; they must not
-silently overwrite newer durable state.
-
-## Error contract
-
-Backends should translate backend-specific constraint errors into the following
-portable Phronomy errors when the meaning matches.
-
-### `Phronomy::Persistence::NotFoundError`
-
-A requested durable record does not exist.
-
-### `Phronomy::Persistence::ConflictError`
-
-A persistence precondition failed, including revision, Journal position,
-identity, duplicate-ID, or compare-and-swap conflicts.
-
-### `Phronomy::AgentBusyError`
-
-A durable nonterminal Agent execution already exists and another durable
-execution record cannot be established. Phronomy also uses the same public error
-for a competing process-local top-level request rejected by Runtime/EventLoop
-before the backend is called.
-
-### `Phronomy::Persistence::SerializationError`
-
-The backend cannot encode a value into its supported durable representation.
-This is intended primarily for durable backends whose Workflow state domain is
-narrower than the InMemory backend's Ruby-object domain.
-
-### `Phronomy::Persistence::UnsupportedBackendError`
-
-The backend does not provide a required structural or capability contract.
-
-Database availability, connection loss, and other transport/storage failures
-must not be misreported as ordinary optimistic conflicts merely to fit this
-error taxonomy.
+The backend declares `spi_version: 2` and true values for `atomic_resources`,
+`record_cas`, `stream_cas`, `conditional_unique`, `guarded_checks` and
+`nested_savepoints`. Persistence validates these capabilities and the required
+resource declarations before exposing repositories. Old duck-typed backends are
+rejected with `UnsupportedBackendError`; there is no eight-slot compatibility
+adapter. Public Persistence capabilities retain `atomic_all`, `atomic_admission`
+and `optimistic_revision`, derived by composition from these primitives.
+
+A root handle routes to the current transaction on the same backend/thread.
+A bound view and all its handles expire on commit or rollback and reject use from
+another thread. Explicit nested transactions use savepoints on the same SQL
+connection, or nested InMemory snapshots. Inner success depends on outer commit;
+an inner exception is re-raised after rollback and can be caught by the outer
+scope. `ActiveRecord::Rollback` also propagates.
+
+A failure during physical work marks the scope failed. Catching it inside that
+same scope does not permit further operations or successful commit. Establish an
+explicit inner transaction before a recoverable operation and catch outside it.
+Input validation occurs before physical work. A successful optional read returning
+nil is not a failed physical operation; domain required-load errors may be raised
+after that read. Domain decode/returned-metadata failures stay inside the atomic
+boundary so a corrupt response after a write causes rollback.
+
+Transaction blocks must finish normally. `return`, `break` and `throw` escaping
+them cause rollback and `TransactionError`. These exits are not commit controls.
+Commit/rollback transport failures remain database failures; this contract does
+not promise exactly-once external effects or infer commit certainty.
+
+## Resource declarations
+
+A `Resource` is an immutable value with `id`, `kind`, `attributes`,
+`immutable_attributes`, `indexes`, `unique` and optional `guard`. Attributes use
+`:string`, `:integer`, `:boolean` and their explicit `:nullable_*` forms. Keys and
+text attributes use valid UTF-8 without NUL; keys are nonempty. Binary data belongs
+to Blobs. No Proc, SQL expression or payload predicate is accepted.
+
+Named equality indexes specify exact fields. Records may declare conditional
+unique constraints with a symbol name, fields and equality `where` values. Null
+unique-key fields are distinct, matching the default SQL unique-index semantics.
+Streams have no indexed attributes; Blobs have attributes but no indexes/guards.
+A record guard uses its key or an immutable non-null string attribute. A stream
+guard uses its stream ID. Its anchor must be a registered Records resource.
+Required anchors must exist; missing parents raise `NotFoundError` in all drivers.
+
+## Records
+
+| Operation | Contract |
+|---|---|
+| `insert(key:, revision:, attributes:, record:)` | Insert only when absent; return an independent immutable `Entry::Record`. Primary duplicates and named unique failures differ. |
+| `read(key)` / `fetch(key)` | Optional nil / required `NotFoundError`. |
+| `replace(key:, expected_revision:, next_revision:, attributes:, record:, expected_attributes: {})` | Check existence, revision, expected attributes, immutable fields and uniqueness atomically; next revision must equal expected + 1. Replace all attributes. |
+| `delete(key:, expected_revision: Records::UNCHECKED)` | Unchecked deletion is idempotent. A supplied revision requires existence and equality. Return nil. |
+| `scan(index:, equals:, after: nil, limit: nil)` | Exact named-index fields, UTF-8 byte order, exclusive key cursor, positive limit or nil for all. |
+| `delete_matching(index:, equals:)` | Delete equality matches atomically; a parent-guarded resource must constrain the guard attribute. Return nil. |
+
+An Entry carries key, revision, attributes and an opaque `DurableRecord`.
+The driver does not reconstruct metadata from payload. Domain wrappers verify
+that returned identity, revision and attributes agree with decoded domain data.
+Workflow/Handoff choose initial revision 1 and route nil expected revision to
+insert; nil is never an unchecked update. Team terminal-to-active rejection is a
+domain `expected_attributes: {active: true}` precondition when saving active state.
+
+## Streams and Blobs
+
+Streams expose `append(stream:, expected_head:, entries:)`,
+`read(stream:, after: 0, limit: nil)`, `head(stream:)`, and `delete(stream:)`.
+Append takes `Entry::Append(id:, record:)`, validates the entire batch before any
+write, enforces unique entry IDs within a stream, assigns contiguous positions
+and updates the head atomically. Empty append still checks the expected head.
+Reads return immutable `Entry::Stream(position:, id:, record:)` values in position
+order. Delete removes head and entries together. The domain Journal wrapper
+preserves its existing `limit: 0` empty-result behavior without a raw zero-limit
+operation.
+
+Blobs expose `put_if_absent(key:, bytes:, attributes:)`, `fetch(key)` and
+`exist?(key)`. Same bytes retain the first attributes; different bytes for an
+existing key raise `BlobConflictError`. Entry bytes are independent immutable
+binary strings. Blob keys are arbitrary storage keys; ContentStore adds the
+`sha256:<digest>` contract and maps integrity failures to its own `IntegrityError`.
+
+## Guards, conditions and errors
+
+`GuardRef(resource:, key:)` names a stable existing parent record. `View#check!`
+acquires guards in resource/key byte order before evaluating the closed condition
+set: `RevisionIs`, `StreamHeadIs`, `NoRows`. A condition must include the guard
+required by its resource and scope. PostgreSQL locks parents before child heads
+or records; SQLite relies on the transaction/CAS/unique constraints and must not
+claim a SELECT alone reserves a writer. Transactions spanning multiple owners
+must establish a consistent owner lock order; database deadlocks remain database
+errors, never optimistic conflicts.
+
+`UniqueConstraintError < ConflictError` carries the resource ID and constraint
+name. Agent/Team translate only their exact `one_active_owner` constraint to
+`AgentBusyError`. Their idle checks translate their own `NoRows` condition failure.
+`ConditionFailedError` carries the failed condition. Duplicate identities,
+stale revisions and ordinary constraint conflicts remain `ConflictError`.
+`NotFoundError`, `SerializationError`, `UnsupportedBackendError` retain their
+meanings; `TransactionError` identifies invalid scope use. The removed
+`ActiveExecutionConflictError` and `Storage::Repositories` have no aliases.
+
+The following sections describe the retained **domain Persistence** surface.
 
 ## Contents repository
 
-The content repository should normally inherit from
-`Phronomy::ContentStore::Base`, which supplies text/JSON helpers and the canonical
-content-ID calculation.
+`ContentStore::StoredContents < ContentStore::Base` supplies this domain surface
+over neutral Blobs, with text/JSON helpers and canonical content-ID calculation.
 
 Required primitive surface:
 
@@ -188,7 +159,7 @@ Required semantics:
 - content is immutable and content-addressed;
 - writing identical bytes is idempotent and returns the same content ID;
 - `fetch` returns a binary `String` isolated from caller mutation;
-- a missing content ID raises `Persistence::NotFoundError`;
+- a missing content ID raises `Storage::NotFoundError`;
 - one content ID must never resolve to different bytes; a digest-integrity
   violation raises `ContentStore::IntegrityError`.
 
@@ -374,10 +345,9 @@ honestly rather than converting them into `ConflictError`.
 
 ### Workflow value serialization
 
-`WorkflowContext#to_h` may contain ordinary Ruby application values. The
-InMemory backend can preserve a broader set of Ruby values than a JSON database.
-A durable backend is not required to serialize arbitrary Ruby objects such as
-`Proc`, IO objects, sockets, or runtime callbacks.
+The Workflow domain codec accepts canonical JSON-compatible snapshot values in
+all drivers, including InMemory. Proc, IO, sockets and runtime callbacks are not
+durable snapshot values.
 
 A JSON/JSONB backend should document its supported value domain. A recommended
 domain is:
@@ -391,7 +361,7 @@ Array of supported values
 Hash with String/Symbol keys and supported values
 ```
 
-If a value cannot be represented, raise `Persistence::SerializationError` rather
+If a value cannot be represented, raise `Storage::SerializationError` rather
 than silently converting it into a lossy form. JSON backends may return String
 keys after decoding; `WorkflowRunner` deliberately accepts String and Symbol keys
 and normalizes them when comparing durable snapshots.
@@ -401,8 +371,8 @@ particular database backend accept arbitrary Workflow values.
 
 ## Durable Agent watermark
 
-`assert_agent_watermark!` is a public **Backend SPI** operation. It is not an
-ordinary application API.
+`assert_agent_watermark!` is a domain Persistence operation. Agent-owned
+`Watermark` composes a parent guard, root revision and Journal head conditions.
 
 Phronomy uses it at durable barriers because a hydrated live Agent owns the
 current logical state and Phronomy deliberately does not reload mutable Agent
@@ -482,9 +452,9 @@ This is a targeted migration rule for the removed generic identity field. It doe
 not establish a general unknown-field or long-term codec/schema-versioning
 policy.
 
-The canonical Hash representation is the Phronomy/domain boundary. A backend is
-free to map that representation to normalized SQL columns, JSON, or another
-storage format internally.
+Domain codecs own canonical Hash representation. The raw driver stores the
+DurableRecord envelope and separately supplied metadata without interpreting
+domain payload fields.
 
 ## Conformance tests
 
@@ -508,6 +478,11 @@ an Agent repository
 a Journal repository
 an Execution repository
 a workflow state repository
+a Handoff state repository
+a Team repository
+a Team execution repository
+neutral storage primitives
+storage transaction boundaries
 a Persistence backend
 ```
 
@@ -518,7 +493,7 @@ require "phronomy"
 require "phronomy/testing/persistence_contract"
 
 RSpec.describe MyPersistenceBackend do
-  let(:persistence) { described_class.new(...) }
+  let(:persistence) { Phronomy::Persistence.new(backend: described_class.new(...)) }
 
   it_behaves_like "a persistence content store"
   it_behaves_like "an Agent repository"
@@ -532,7 +507,7 @@ RSpec.describe MyPersistenceBackend do
 end
 ```
 
-`Persistence::InMemory` is run through the same shipped contract source in
+`Persistence.in_memory` is run through the same shipped contract source in
 Phronomy CI. The files under `spec/support/shared_examples/` are compatibility
 require wrappers only; the authoritative shared-example implementations live
 under `lib/phronomy/testing/persistence_contract/` so the core suite and external
@@ -560,34 +535,17 @@ may use combinations of:
 Backend-specific database exceptions should be translated to the Phronomy error
 contract where their meaning is known.
 
-## V2 coordination Backend SPI (clean break)
+## Coordination domain repositories
 
-Both `Persistence.new` and `build_transaction_view` require all eight raw
-repositories. Five-repository fallback is removed. Existing record formats remain
-`0.1`; three additional record types are `phronomy.handoff_state`,
-`phronomy.team_root`, and `phronomy.team_execution`. Backend index metadata is
-explicit and MUST NOT be reconstructed by parsing DurableRecord payloads.
+Handoff starts at revision 1 with expected revision nil; later saves advance one
+revision. Team roots and executions begin at revision 0. Team admission retains
+`AgentBusyError`; stale CAS and duplicate identities use `ConflictError`.
+Missing Team/execution loads raise `NotFoundError`; absent Handoff state returns
+nil. The unchanged record types are `phronomy.handoff_state`, `phronomy.team_root`
+and `phronomy.team_execution`, all version `0.1`.
 
-| Raw repository | Required operations and explicit metadata |
-|---|---|
-| `handoff_states` | `load(main_agent_id)`; `save(main_agent_id, expected_revision:, next_revision:, active_agent_id:, record:)`; `delete(main_agent_id, expected_revision:)` |
-| `teams` | `create(team_id:, team_revision:, record:)`; `load(team_id)`; `save(team_id, expected_revision:, next_revision:, record:)`; `delete(team_id)` |
-| `team_executions` | `create_active(team_execution_id:, team_id:, execution_revision:, record:)`; `load(id)`; `save(id, expected_revision:, next_revision:, team_id:, active:, record:)`; `list_active(team_id)`; `list(team_id, after: nil, limit: 100)`; `delete(id)`; `delete_for_team(team_id)`; `assert_idle!(team_id)` |
-| `executions` extension | `list(agent_id, after: nil, limit: 100)` for retained active and terminal records |
-
-Handoff starts at revision 1 with expected revision nil; later saves advance
-exactly one revision. Team roots and executions begin at revision 0. Team
-admission has the existing `AgentBusyError` contract for an already active owner;
-stale CAS/duplicate identity uses `ConflictError`. Missing Team/execution loads
-raise `NotFoundError`; absent Handoff state returns nil. Unavailable reads and
-codec errors must propagate separately.
-
-Lists sort IDs lexically, use an exclusive ID cursor, return at most the positive
-integer limit, include only the requested owner, and return immutable copies.
-Backends define retention; enumeration does not implement input correlation or
-request deduplication. Terminal-to-active rewrites are invalid.
-
-For F1, atomic commit does not imply a known response. Phronomy reads back the
-same intended ID/fact before advancing. A backend must provide authoritative
-reads/CAS; failure of readback is returned without new semantic work. No callback
-ACK/index is part of the SPI. Existing cross-process exclusion limitations remain.
+Backend authors should also read the [SPI 2 migration guide](migrations/neutral-storage-spi.md).
+The Stable/Beta product API snapshot and the explicit Storage SPI 2 signature
+snapshot are separate gates. Live PostgreSQL locking and failure tests must run
+against the candidate core and examples revisions; earlier SPI results do not
+satisfy this gate.