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>
The write gate confirmed effects the served environment would not show:
- a list check let a member the state no longer holds pass, so a
filtered list still showing a deleted entity confirmed the delete; it
now compares the whole list serving would return;
- item and list checks compared only the entity, so a wrapper member
that changed after the write (a revision, say) went unnoticed while
serving kept the base recording's; reads are now compared as the full
response rendered into the item view's or the line's base envelope;
- a later update's constant rule kept no value, so serving stored the
first observation's; each constant rule now carries the value the
call that showed it recorded, and the gate and serving read it alike;
- a redirected or unanswered write could become the example or a
modelled effect; only a 2xx write is modelled, others taint as
unmodelled writes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
