Greptile raised these on this branch, the fidelity branch and the list-lines branch; five follow from the previous
round's changes.
- An entity field whose name looks like a pointer is matched by name; only a document's pointers cover the members under them.
- A failed read contradicts each exercised write that no unmodelled write came after, instead of skipping them all when the oldest pending write preceded one; the shared pending `since` time goes.
- An item read, update or delete names its entity as serving's namedEntity does: held collections its path matches, verbatim spellings first, the id decoded once, then as written; `book%2531` no longer reaches `book1`.
- A plan whose calls use a member both as the identity and as a fixed member, or fix it at different values, is refused, as serving could not take every recorded call.
- A size of zero bounds nothing only on a line whose recording listed items under it (pageBound), in serving and in the gate.
- An update whose observation drops a field the entity held is refused, as serving keeps every field it does not write.
- A later create whose clock takes another format, or whose unique value is not a UUID, is refused.
- A derived state data/get would write past the 32 MiB intake limit is not served (admitServedState); the environment serves replay.
The verdicts over the 50 captures are unchanged plan by plan, and the smoke applies all 31 served write tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Greptile raised these on the list-queries branch against this branch's code.
- An update's identity member never takes a rule. Sent as the path's id it is the identity member; sent as another value the application ignored it is accepted with that value and stores nothing, so the exemplar's id is no longer written into the entity another call names; a stored id that changed is unexplained.
- A page size of zero bounds nothing, so a whole line recorded with `limit=0` answers from the state instead of replaying stale members.
The verdicts over the 50 captures are unchanged plan by plan, and the smoke applies all 31 served write tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Greptile raised these on this branch, the fidelity branch and the list-lines branch.
- A passing read that shows nothing of a write leaves it pending for a later check instead of clearing it, so a summary list no longer hides a description PATCH a later item read shows.
- A read begun while a modelled write to an unknown entity still ran neither checks nor resynchronises the entity.
- A later create whose sequence fields hold another value than serving would generate (one past the largest held or started-with value, and past the plan's last) refuses the plan.
- A document replacement below the root overwrites only the claims under its object, and a built document plan writes later calls at its own object, even one sharing no member with the document.
- An update or delete finds its entity as an item read does, so a plain spelling of a percent-encoded held collection no longer leaves the tool without an observation.
- A `_start`-`_end` range bounds a page as `limit` does, in serving and in the gate.
The document write moves to environmentStateWriteDocument.ts, the pending-write bookkeeping and the gate's input type move beside the code that uses them, and the item-read field check takes the list-lines branch's shape, keeping files under the line limit. The verdicts over the 50 captures are unchanged plan by plan, and the smoke applies all 31 served write tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Greptile raised these on the list-lines branch against this branch's code.
- A create that answers with its id alone (a scalar, the identity field or one member) is observed only through a read of that id. A read of another, unlisted book can no longer supply the created entity. Lists may supply it when they show that id.
- A later update call that is the first to send the path's id in its body adds the identity member to the plan, instead of making the tool unexplained.
- The copy search walks a request body with an index rather than shifting it. 500,000 zeros took 63 s before and 74 ms after.
- The sent values of fixed members a plan keeps are counted against the view's memory allowance, on the first call and when a later call adds more.
The verdicts over the 50 captures are unchanged plan by plan, and the smoke applies all 31 served write tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A passing read confirms only the writes it shows something of: a create's or delete's membership, or a changed field its view shows and does not treat as volatile. A list without `description` no longer confirms a description PATCH.
- Document writes join the effect tracking, a merge by the members it sent and a replacement as the whole document. A PATCH a later PUT replaced is no longer confirmed by the final read.
- A read a write's effect was learned from still contradicts the other writes it exercises, though it checks nothing of the borrowing write.
- An item read names its entity as serving does: the collection and id as written, else a held collection that matches once percent-decoded. A `200 null` read spelled plainly now contradicts an update made under the encoded spelling.
- A line repeating a query name with one value stays checkable, since a call naming it matches both pairs; only repeats with different values are skipped.
- A call naming a page of a whole list the collection has outgrown answers from its recording (`page-exceeded`) instead of returning more items than it asked for, and the gate does not check such a read against the state.
The write verdict moves to environmentStateWriteVerdict.ts (as on the list-lines branch) and the plan-conflict check to environmentStateWriteExplain.ts, keeping files under the line limit. Also merges main d8a9673f. The verdicts over the 50 captures are unchanged plan by plan, and the smoke applies all 31 served write tools.
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>
A refused call no longer advances the served clock, the write counter or a
sequence: values are reserved while a call is answered and committed with its
mutation, and deletes and document writes advance the clock like the others.
Updated entities cite no records, so data/get output loads back unchanged.
The gate withholds an update or delete that answers with the entity when no
initial entity holds every field its recorded answer shows, which would
answer only for entities the environment created (incomplete-entities). A
create whose template keeps a path value is tied to its collection like a
constant, and a delimited token is found after an overlapping undelimited one.
Documents write plans, the gate and served writes in the environment-state
and serving guides, the CLI help, the analysis-view contract and the bundle
README, and records the replay card the response summaries now produce.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The environment-state view now builds a write plan for every tool whose
method may change state (create, update, delete or document, by the state
type or document its path names) from its first successful recorded call:
the request body members the application stored as sent, values it generated
(identities, sequences, UUIDs, clock values in their recorded format), values
derived from the call (copies, path values, slugs, strings around a generated
id) and the recorded response's shape. It replays the capture's timeline on a
copy of the initial state, applying each modelled write and checking every
later read the served state would answer; a plan is served only when a later
read confirms it and none contradicts it. Writes it does not model leave the
entities and collections below their paths unknown until a read shows them
again, and failures they may explain are checked only on the members a write
sent. Unserved plans carry their reason.
Served from the state, the catalog adds the confirmed write tools, described
by their effect and body members. A call applies its effect atomically to the
live store and answers with a recorded status and a rendered body; refused
calls leave the state unchanged. Generated values are deterministic per state
Evidence and write count, sequences never reuse a value, and the clock starts
at the capture's end: data/reset and data/add restart them. Reads of an
entity the state does not hold answer the recorded 400, 404 or 410, and a
list line that only pages its collection and listed all of it answers calls
without query arguments from the state.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>