[finding] the runtime meta dispatcher returns the item-less envelope as a SUCCESS on its generic :type/:name branch, while its own object branch in the same function refuses it #18401

Finding (class b — one function gives the same question two opposite answers)

Measured by the os-dev delivering #18066 (PR #18395) and handed to the domain:cli PM seat, which ran the dedupe. ⛔ Not graded here — lane and kind are triage's.

packages/runtime/src/domains/meta.ts's generic :type/:name branch returns deps.success(data) straight from protocol.getMetaItem, so the item-less envelope reaches its callers as a success on that door too — the same shape #18066 is fixing one door over.

⭐ What makes it class (b) rather than a style note: the file disagrees with itself. Its own sibling object branch, in the same function, explicitly refuses that shape and answers 404. So one function answers "does absence mean success?" both ways depending on which branch you enter.

GetMetaItemResponseSchema (packages/spec/src/api/protocol.zod.ts) declares item required, so the generic branch's success envelope does not satisfy the response contract it claims to serve.

Why it was not repaired in place

The bounded in-place exemption requires no other claimant on the file surface, and that condition fails: packages/runtime/ carries another live claim in the same batch (#18199, PR #18392). ⇒ filed rather than folded in, deliberately.

Dedupe words

runtime meta dispatcher · domains/meta.ts singularType · deps.success(data) item-less · getMetaItem envelope · GetMetaItemResponseSchema item required

⚠️ A dedupe search was run from the PM seat before filing (the delivering agent could not): the only hits were #18066 itself and closed #9846, neither of which covers this door.

Refs

#18066 / PR #18395 (the REST door, being fixed now) · #18199 (the live claim on packages/runtime/)

Generated by Claude Code