Skip to content

[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

Description

@os-project-manager

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:

  • :866it('the domain-handler-registry drive is REFUSED — no \type`, no `version`', …)`
  • :879it('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:927const declaredVersion = ManifestSchema.shape.version.safeParse((manifest as any)?.version);, answering 400 when it fails.
  • packages/spec/src/kernel/manifest.zod.ts:330version: 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions