Recording an observation surfaced while measuring #9612 (PR #10058). Not fixed there — it is pre-existing and unrelated to that card's scope.
The observation
Object-door authoring findings locate themselves with an index into the gate's per-write snapshot array: path: 'objects[417].sharingModel'. That index is assigned by buildRuntimeWriteSnapshots, which appends the written item to the end of the live objects collection. It is an offset into an in-memory array the caller has never seen and cannot enumerate — a Studio client, an MCP author, or a REST consumer receiving the 422 has nothing to resolve 417 against.
The information the reader actually needs is already present and correct: where carries object "acme_invoice".
How it surfaced
#9612 narrows what the gate hands the rules, which moves the written item's index. Comparing full-stack and narrowed verdicts on the object door therefore reports a +1 / -1 difference on the raw (rule, where, path, message) tuple at every N where narrowing occurs, while the semantic verdict — same rule, same object, same message — is identical.
That is benign here and #10058's bench prints both readings rather than hiding the raw one. It is recorded because the failure mode generalises: any future change to what the snapshot contains renumbers these paths, and a differential comparison keyed on path reads that renumbering as a changed verdict. A reviewer who trusted the raw comparison would conclude a safe change manufactured phantoms.
Why it may matter beyond the comparison
Findings for other write types are unambiguous by construction — the written item is the sole member of its own collection, so index 0 is always this write. Only the collection-resident types (object, permission, book) get a meaningful, and meaninglessly large, index. So the same finding vocabulary means two different things depending on write type, and only one of them is useful to the receiver.
Not proposing the fix here
Whether to key these paths on the object NAME instead (objects.acme_invoice.sharingModel), or to normalise the written item to a stable index, is a wire-shape question about RuntimeAuthoringIssue.path — a packages/spec surface consumed by Studio. It needs a decision, not a patch.
Re-check
node scripts/bench/runtime-publish-gate.bench.mts --type object --mode package --objects 420
Read the raw incl. array index half of the differential-verdict line against the semantic half.
Unassigned, observation class, awaiting first-touch grading.
Recording an observation surfaced while measuring #9612 (PR #10058). Not fixed there — it is pre-existing and unrelated to that card's scope.
The observation
Object-door authoring findings locate themselves with an index into the gate's per-write snapshot array:
path: 'objects[417].sharingModel'. That index is assigned bybuildRuntimeWriteSnapshots, which appends the written item to the end of the liveobjectscollection. It is an offset into an in-memory array the caller has never seen and cannot enumerate — a Studio client, an MCP author, or a REST consumer receiving the 422 has nothing to resolve417against.The information the reader actually needs is already present and correct:
wherecarriesobject "acme_invoice".How it surfaced
#9612 narrows what the gate hands the rules, which moves the written item's index. Comparing full-stack and narrowed verdicts on the object door therefore reports a
+1 / -1difference on the raw(rule, where, path, message)tuple at every N where narrowing occurs, while the semantic verdict — same rule, same object, same message — is identical.That is benign here and #10058's bench prints both readings rather than hiding the raw one. It is recorded because the failure mode generalises: any future change to what the snapshot contains renumbers these paths, and a differential comparison keyed on
pathreads that renumbering as a changed verdict. A reviewer who trusted the raw comparison would conclude a safe change manufactured phantoms.Why it may matter beyond the comparison
Findings for other write types are unambiguous by construction — the written item is the sole member of its own collection, so index 0 is always this write. Only the collection-resident types (
object,permission,book) get a meaningful, and meaninglessly large, index. So the same finding vocabulary means two different things depending on write type, and only one of them is useful to the receiver.Not proposing the fix here
Whether to key these paths on the object NAME instead (
objects.acme_invoice.sharingModel), or to normalise the written item to a stable index, is a wire-shape question aboutRuntimeAuthoringIssue.path— apackages/specsurface consumed by Studio. It needs a decision, not a patch.Re-check
Read the
raw incl. array indexhalf of the differential-verdict line against thesemantichalf.Unassigned, observation class, awaiting first-touch grading.