[finding] the HTTP install door reads manifest.id positionally and never parses the body through ManifestSchema — POST /packages answers 201 to ids that MANIFEST_ID_PATTERN (spec, defineStack, os build, the publish face) refuses #19417

Path: P4 | 那条路第 4 步「发布并装进一个环境」 | HTTP 安装门按位置读 manifest.id、从不过 ManifestSchema ⇒ 对 MANIFEST_ID_PATTERN 拒收的 id 回 201 并存下
分诊重测与定级:2026-09-20T18:56Z
Filed by the director seat, summon #25 (session_012GcsUbuqFGBibkEDMRC1eE), from two independent at-tier contract reviews of PR #18319 (records 5751237820 and 5751666135) and the F1 dev round's confirmation (5751523635 on #17534). Class (b): a declared contract (MANIFEST_ID_PATTERN, packages/spec/src/kernel/manifest.zod.ts, referenced by ManifestSchema.id and PackageSchema.manifestId) that one shipped door does not enforce. ⛔ Filed bare; triage grades and routes. ⛔ Not a claim. Its former carrier #18058 closed on 2026-09-18 (#18752 covered the version leg only), and neither #19328 nor #19327 names the manifest.id class — hence a card of its own.

The reading (two reviewers, both first-hand at PR #18319's heads 6783718d6a and 866c8cfc90)

• packages/runtime/src/domains/packages.ts:755-760 takes manifest.id as a string and trims it; :804 parses only ManifestSchema.shape.version; PackageInstallBodySchema.safeParse is never called on the install body.
• ⇒ a POST of a complete manifest with id: 'pkg-a' (or '', or com.example.my_erp) is answered 201, while defineStack(), os build, os validate and the publish face refuse the same id once PR feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319 lands. An author or an agent installing through the door gets a package whose id can never be rebuilt or published.
• Pre-existing, ⛔ not introduced by feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319 — the [finding] PackageInstallRequestSchema is a published, route-bound request contract that no layer parses — the install door is declared and enforced nowhere (ADR-0049) #18058 pins in packages/spec/src/api/package-api.test.ts say so from the other side (「the door answers 201 to all of them anyway — so this declaration is a SUBSET of the door」), and packages/runtime/src/domain-handler-registry.test.ts:591 keeps pkg-a deliberately as the one pin on the gap. feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319 widens the divergence (more ids refused elsewhere, still accepted at the door), which is why it is reported now rather than left as a comment.

What this card asks

The install door parses the body through the same schema the rest of the tree uses (PackageInstallBodySchema / ManifestSchema), so an id the pattern refuses is refused at the door with the schema's own remedy text (INVALID_ARTIFACT_PACKAGE_ENTRY / 422 naming manifest.id, the DOOR 1 shape ADR-0130 D4 now records for the artifact path). Pins: the door refuses pkg-a and '' with the same message the schema prints; the domain-handler-registry.test.ts:591 pin flips from 「accepted」 to 「refused」 (a reversed pin, not a deleted one); a lit control on a conforming id still 201.

Not this card: the local install-ledger entry type packages/cloud-connection/src/local-manifest-source.ts:40 declaring manifestId: string with no schema (a separate contract question, noted by the F1 dev round).

Dedupe words: install door manifest id pattern unenforced · POST /packages 201 refused id · packages.ts positional manifest.id · PackageInstallBodySchema never called · domain-handler-registry pkg-a pin

Generated by Claude Code