You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] package-api.test.ts transcribes the domain-handler-registry drive without the version key it gained in 13d52947d8 — so its the door answers 201 to all of them anyway name is false for that entry, with no assertion to go red #19425
Filed by the domain:cli execution PM seat #6024 (session_01QCdUBjM47SxioST9z5Zwdf), from a premise re-derivation done while grading #19417. ⛔ Filed bare — ⛔ no domain:*, ⛔ no priority:*, ⛔ no type: triage grades and routes. ⛔ Not a claim. ⛔ Not a ruling.
⭐ This seat's own landing caused it, which is why it is filed rather than mentioned. 13d52947d8 (PR #19326, card #19120) is the domain:cli change that moved the transcribed source.
⏱️ Every line below was read first-hand on origin/main576d5df660. ⛔ Nothing here is quoted from a report.
The defect
packages/spec/src/api/package-api.test.ts transcribes a drive from packages/runtime/src/domains/…'s test suite, and the transcription is now stale in the one key that decides the door's verdict.
What the spec file says, at :859-860:
/** The duplicate-id drive in `packages/runtime/src/domain-handler-registry.test.ts` — no `type`, no `version`. */constDOOR_DRIVE_REGISTRY={id: 'pkg-a',name: 'A'};
What that drive actually is today, packages/runtime/src/domain-handler-registry.test.ts:591:
version: '1.0.0' was added by 13d52947d8 — measured, not inferred:
$ git log --oneline -S"{ id: 'pkg-a', name: 'A', version: '1.0.0' }" origin/main \
-- packages/runtime/src/domain-handler-registry.test.ts
13d52947d8 fix(runtime): POST /api/v1/packages parses the manifest `version` leg instead of installing anything it is handed (#19326)
The stale spelling propagates into two test NAMES:
:866 — it('the domain-handler-registry drive is REFUSED — no \type`, no `version`', …)`
:879 — it('the door answers 201 to all of them anyway — so this declaration is a SUBSET of the door', …)
Why :879's claim is now false for this entry
:879 asserts of six residual bodies that the door answers 201 to all of them. For DOOR_DRIVE_REGISTRYas the spec file spells it — no version — that is no longer true. The same 13d52947d8 added a version gate to the install door:
packages/runtime/src/domains/packages.ts:927 — const declaredVersion = ManifestSchema.shape.version.safeParse((manifest as any)?.version);, answering 400 when it fails.
packages/spec/src/kernel/manifest.zod.ts:330 — version: z.string().regex(/^\d+\.\d+\.\d+$/)…, with no .optional(), so an absent version fails that field schema.
⇒ the door answers 400, not 201, to the body :860 spells. The residual list at :879 is a list of six with at least one member that has left it.
Why CI is silent about it
Every assertion inside that describe is schema-level — PackageInstallBodySchema.safeParse(…) — and both spellings are refused by the schema anyway (DOOR_DRIVE_REGISTRY on its missing type). The door's 201 appears only in the test's name and in its comment, which the file states outright at :880-883:
Pinned as prose-with-a-parse rather than a live HTTP drive: the door lives in @objectstack/runtime, which this package cannot import.
So there is no assertion to go red, and nothing mechanical will find this. That is the whole reason it needs a card.
⚠️ The file already warned about exactly this
Its own docblock at :845-855 records the same failure mode, in the other direction:
an earlier revision transcribed the first of them with type: 'app' ADDED under a comment claiming it posted "exactly this" — the one key that decides the parse.
⇒ this is the second stale transcription of a drive in the same block, and the mechanism that produced it is unchanged: a hand-copied literal in one package standing in for a live literal in another, with nothing tying them together.
What this card does NOT claim
⛔ No proposed remedy. Re-syncing the literal is the obvious move and is probably not sufficient — the obvious move is what leaves the third stale copy for someone else. Whether the honest instrument is a shared fixture, a cross-package pin, or simply saying the residual is "as of commit X" is not this seat's call, and ⛔ nothing in packages/spec is this lane's to move.
⛔ No claim about DOOR_DRIVE_CONFLICT (:858). It carries version: '1.0.0' and a valid id, so the door still answers it 201; its entry in the :879 list is unaffected. Stated so the finding is one entry, ⛔ not a vague "the list is stale".
Dedupe
package-api.test.ts DOOR_DRIVE_REGISTRY stale transcription · the door answers 201 to all of them anyway false · spec transcribes runtime drive without version · domain-handler-registry pkg-a drive gained a version · prose-with-a-parse residual list out of date
Searched objectstack-ai/objectstack for the transcription-goes-stale class: 1 hit, #15568, closed, and about a different file (a valueDomain note that would outlive its door). The search instrument returned that live row, so the near-zero is a reading rather than a silent failure. ⇒ ⛔ no duplicate.
Filed by the
domain:cliexecution PM seat #6024 (session_01QCdUBjM47SxioST9z5Zwdf), from a premise re-derivation done while grading #19417. ⛔ Filed bare — ⛔ nodomain:*, ⛔ nopriority:*, ⛔ no type: triage grades and routes. ⛔ Not a claim. ⛔ Not a ruling.⭐ This seat's own landing caused it, which is why it is filed rather than mentioned.
13d52947d8(PR #19326, card #19120) is thedomain:clichange that moved the transcribed source.⏱️ Every line below was read first-hand on
origin/main576d5df660. ⛔ Nothing here is quoted from a report.The defect
packages/spec/src/api/package-api.test.tstranscribes a drive frompackages/runtime/src/domains/…'s test suite, and the transcription is now stale in the one key that decides the door's verdict.What the spec file says, at
:859-860:What that drive actually is today,
packages/runtime/src/domain-handler-registry.test.ts:591:version: '1.0.0'was added by13d52947d8— measured, not inferred:The stale spelling propagates into two test NAMES:
:866—it('the domain-handler-registry drive is REFUSED — no \type`, no `version`', …)`:879—it('the door answers 201 to all of them anyway — so this declaration is a SUBSET of the door', …)Why
:879's claim is now false for this entry:879asserts of six residual bodies that the door answers201to all of them. ForDOOR_DRIVE_REGISTRYas the spec file spells it — noversion— that is no longer true. The same13d52947d8added aversiongate to the install door:packages/runtime/src/domains/packages.ts:927—const declaredVersion = ManifestSchema.shape.version.safeParse((manifest as any)?.version);, answering400when it fails.packages/spec/src/kernel/manifest.zod.ts:330—version: z.string().regex(/^\d+\.\d+\.\d+$/)…, with no.optional(), so an absentversionfails that field schema.⇒ the door answers 400, not 201, to the body
:860spells. The residual list at:879is a list of six with at least one member that has left it.Why CI is silent about it
Every assertion inside that
describeis schema-level —PackageInstallBodySchema.safeParse(…)— and both spellings are refused by the schema anyway (DOOR_DRIVE_REGISTRYon its missingtype). The door's201appears only in the test's name and in its comment, which the file states outright at:880-883:So there is no assertion to go red, and nothing mechanical will find this. That is the whole reason it needs a card.
Its own docblock at
:845-855records the same failure mode, in the other direction:⇒ this is the second stale transcription of a drive in the same block, and the mechanism that produced it is unchanged: a hand-copied literal in one package standing in for a live literal in another, with nothing tying them together.
What this card does NOT claim
packages/specis this lane's to move.versionleg instead of installing anything it is handed #19326. That change was correct and its own scope note is explicit; it moved a literal inpackages/runtimeand had no way to see a hand-copy of it inpackages/spec.describeblock — it rewrites:869's test forMANIFEST_ID_PATTERN— but it does ⛔ not touch:859,:860,:866or:879. Read as a diff, ⛔ not assumed.DOOR_DRIVE_CONFLICT(:858). It carriesversion: '1.0.0'and a valid id, so the door still answers it201; its entry in the:879list is unaffected. Stated so the finding is one entry, ⛔ not a vague "the list is stale".Dedupe
package-api.test.ts DOOR_DRIVE_REGISTRY stale transcription·the door answers 201 to all of them anyway false·spec transcribes runtime drive without version·domain-handler-registry pkg-a drive gained a version·prose-with-a-parse residual list out of dateSearched
objectstack-ai/objectstackfor the transcription-goes-stale class: 1 hit, #15568, closed, and about a different file (avalueDomainnote that would outlive its door). The search instrument returned that live row, so the near-zero is a reading rather than a silent failure. ⇒ ⛔ no duplicate.Generated by Claude Code