Five places where the gate approved a write serving would answer
differently:
- list and document reads are matched to checked lines as serving
matches calls (path and query values decoded, the query in any
order), so a reordered query no longer hides a contradiction;
- an increment or slug applies to every call, so a plan is
unexplained-change when one call changes such a field and another
leaves it as it was, in either order;
- an item read confirming a create no longer stops a later list from
choosing another insert candidate; only a list check fixes the rule;
- the gate runs serving's document body check (accepted members, JSON
types from the held and initial document), so a recorded write that
serving would refuse leaves the plan unserved;
- a served create decodes its path values from the collection the call
names, as the gate decoded the recorded path, whichever spelling the
call used.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Served writes now refuse, before changing the state:
- a document write with members or JSON types its plan did not accept
(the same body check entity writes use), or at a path other than the
one the state holds the document at;
- a body or resulting value data/add would refuse (a number inexact as
data/get writes it, a __proto__ member, nesting past the limit), so
data/get output always loads back, increments included;
- a create, update or document write that would take the state past the
32 MiB data/add intake limit (resource_constraint), with the state's
serialized size kept incrementally rather than reserialized.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Unit tests for clock, UUID, token, slug and delimited-token values, the field
rules that explain created and updated entities, response shapes, insert
rules and the shared apply functions; view tests for every plan reason, delete
confirmation by a 400, 404 or null read, learned insert rules, unmodelled
writes and observations from later reads; services tests for served creates,
updates and deletes, refusals that leave the state unchanged, deterministic
values across reset and load, missing entities, the catalog and paging-only
list lines; and an MCP boundary test that serves a capture through the built
CLI, applies a create and resets it. The capture fixture records request
bodies.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
