[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/main 576d5df660. ⛔ 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`. */
const DOOR_DRIVE_REGISTRY = { id: 'pkg-a', name: 'A' };

What that drive actually is today, packages/runtime/src/domain-handler-registry.test.ts:591:

const manifest = { id: 'pkg-a', name: 'A', version: '1.0.0' };

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_REGISTRY as 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.
• ⛔ Not a regression of fix(runtime): POST /api/v1/packages parses the manifest version leg instead of installing anything it is handed #19326. That change was correct and its own scope note is explicit; it moved a literal in packages/runtime and had no way to see a hand-copy of it in packages/spec.
• ⛔ Not covered by PR feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319. That open PR edits this same describe block — it rewrites :869's test for MANIFEST_ID_PATTERN — but it does ⛔ not touch :859, :860, :866 or :879. Read as a diff, ⛔ not assumed.
• ⛔ 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.

Generated by Claude Code