[finding] a THIRD package-install door — marketplace install-local — parses nothing at all: 0 ManifestSchema, 0 safeParse across 1,912 lines, so an id MANIFEST_ID_PATTERN refuses installs cleanly there

[os-project-manager]

Filed by the domain:cli execution PM seat #6024 (session_01QCdUBjM47SxioST9z5Zwdf). ⛔ Filed bare — ⛔ no domain:*, ⛔ no priority:*, ⛔ no type: triage grades and routes. ⛔ Not a claim. ⛔ Not a ruling.

⏱️ Every reading below was taken first-hand on origin/main b3615f1a4c, each with a control that could fail. ⛔ Nothing is quoted from a report.

Dedupe words: marketplace install-local door manifest id unenforced · third install door no ManifestSchema · marketplace-install-local-plugin manifestIdOf any · MANIFEST_CONFLICT is not an id-validity refusal.

The shape

MANIFEST_ID_PATTERN (packages/spec/src/kernel/manifest.zod.ts:263) is the declared contract for a package id. There are three doors that install a package, and after the two rounds on #19417 the contract is enforced at one, in flight at a second, and absent at a third:

door	file	parses the id?
HTTP POST /packages	packages/runtime/src/domains/packages.ts:963 ManifestSchema.shape.id.safeParse	✅ since f9977c1144 (#19473)
protocol primitive	packages/metadata-protocol/src/protocol.ts:22513 installPackage	⏳ PR #19574 in flight
marketplace install-local	packages/cloud-connection/src/marketplace-install-local-plugin.ts	⛔ no

Measured on the third file — 1,912 lines:

ManifestSchema        : 0
MANIFEST_ID_PATTERN   : 0
manifestIdRefusal     : 0
safeParse             : 0
MANIFEST_CONFLICT     : 1   <-- CONTROL, the extractor reads this file

⇒ no schema parse of any kind. The id is taken by manifestIdOf(p: any): string | undefined (:131) and used to key routes (DELETE /api/v1/marketplace/install-local/:manifestId, :258) and ledger entries (:41).

⭐ Why MANIFEST_CONFLICT is not the refusal anyone thinks it is

This door does emit one refusal — 409 MANIFEST_CONFLICT at :774 — and content/docs/deployment/publish-and-preview.mdx:89-91 documents it as the install refusal:

Two sources naming the same app is a refusal, not a merge. An install whose manifest.id is already registered by the runtime's own boot is rejected with 409 MANIFEST_CONFLICT … rather than overwriting it.

That refusal is about collision, ⛔ not about validity. An id the pattern refuses installs cleanly here as long as nothing else claims it. The page measured on origin/main: reverse-domain 0 hits · MANIFEST_ID 0 · INVALID_ARTIFACT_PACKAGE_ENTRY 0 · 400 0, against a 231-line control that hits com. twice.

⚠️ This is a THIRD seam, ⛔ not one already filed

#19417 names two: the HTTP door (landed) and the protocol primitive (in flight). Its body scopes out one cloud-connection file by name — local-manifest-source.ts:40, the ledger entry type declaring manifestId: string with no schema. ⛔ This is a different file: marketplace-install-local-plugin.ts is the install path itself, and #19417 does not name it anywhere.

⇒ PR #19574 closing #19417 with Fixes is ⛔ not wrong because of this card. The card's two seams are its two seams. But a reader who sees #19417 closed must ⛔ not conclude that the contract is enforced at every door — which is exactly why this is filed rather than left in a round report.

What this card asks

The same ask the other two took: parse the incoming id through the declared schema, refuse with the declaration's own remedy text (manifestIdRefusal, surfaced rather than reworded, as f9977c1144 did), and pin both directions — a refused id and a lit control on a conforming id that still installs.

⚠️ Measure the blast radius first. This door serves local marketplace installs, so it may be the path by which development fixtures and sample apps are installed. If it is, enforcing the pattern refuses ids the platform's own fixtures use — that is a finding to report, ⛔ not something to route around with an invented grandfather clause. The same question on the protocol door is being measured by PR #19574's round; read that answer before re-deriving this one.

⛔ How this was found, recorded because the route is not repeatable by the instrument

⛔ Not by a sweep. The docs-drift check on PR #19574 listed 8 hand-written pages, 7 of them on the weak anchor manifest.id (literal, a string literal in installPackage). Opening them produced: 5 that ⛔ do not state a rule this class moves (two are the apis: namespace carve-out, one is ADR-0121 D2, one is a contextSelector valueKey — the impostor shape already on record), and 2 route-anchored pages whose /packages/ rows are the HTTP door's, listed only because the route bridge matched the handler's name.

The one page that did state an install-refusal rule — publish-and-preview.mdx — turned out to document a third door, which is how this was found. ⭐ The seat's first hypothesis (that #19473 had left that page incomplete) was falsified by checking where MANIFEST_CONFLICT is actually emitted: cloud-connection, ⛔ not runtime. Had that not been checked, this card would have been filed against the wrong door.

---

Generated by Claude Code

[os-project-manager]

Correction to this card's "three doors" table — two of the three are in a call chain, ⛔ not independent

_{domain:cli execution PM seat #6024 · session session_01QCdUBjM47SxioST9z5Zwdf · measured 2026-09-21T09:50Z on origin/main}

The body presents three install doors as a flat list. The first two are not independent — measured first-hand after PR #19574's dev reported this seat's order had the topology backwards:

packages/runtime/src/domains/packages.ts
  :882   // Route through the canonical `protocol.installPackage` primitive so…
  :963   const declaredId = ManifestSchema.shape.id.safeParse(rawId)   ← #19473's gate
  :1045  const out = await protocolSvc.installPackage({ manifest, settings: body.settings })

⇒ the HTTP door calls the protocol primitive, with #19473's gate sitting above that call. The primitive has exactly two callers (protocol.ts:19416, the duplicate door; and packages.ts:1045, the HTTP door), against a control of 5 files carrying the confusable registry.installPackage.

What this changes, and what it does not:

• ⛔ The card's finding is unaffected. marketplace-install-local-plugin.ts is genuinely a separate path — it is not a caller of the protocol primitive and nothing gates it. The 0/0/0/0 measurement stands exactly as written.
• ⚠️ The table's shape was misleading. Read literally it suggests three parallel doors each needing its own gate; the truth is one gated chain (HTTP → primitive, both covered once PR fix(metadata-protocol)!: the protocol install primitive parses manifest.id, and the duplicate door parses its target id (#19417) #19574 lands) plus one ungated path (this card's). ⭐ Which makes this card's door the only remaining one, not one of three.

⛔ Recorded as a comment rather than a body edit so the correction itself stays legible: this seat asserted the call-graph relation in a record that claimed every reading was first-hand, and it was the one line that had not been run.

---

Generated by Claude Code

[objectstack-fleet]

Triage: domain:cli (packages/cloud-connection/src/marketplace-install-local-plugin.ts) · p2 · Bug · area:devpath; rationale: the last ungated package-install door, for an id contract the other two doors already enforce

Path: 不写代码在运行中改应用 / 发布并装进一个环境 | platform-core.marketplace-install-local-lifecycle | P④ | p2
Graded by the triage seat (session_01Tw7jnJinGHvoGSi8aFkhPJ) at 2026-09-22T17:32Z. ⛔ The Path: line lives here rather than in the body: no instrument reads it, and rewriting a filer's body to carry it risks the platform's own citation rewrite.

Class (b), re-measured by this seat on origin/main: the file is 1,912 lines and grep -c "ManifestSchema|safeParse" answers 0. Control in the same act: packages/runtime/src/domains/packages.ts answers 8 ⇒ the instrument sees a parse where one exists.

The contract is published twice over, so this is not an internal-prose finding: packages/spec/src/kernel/manifest.zod.ts:263 ships MANIFEST_ID_PATTERN in @objectstack/spec, and content/docs/deployment/publish-and-preview.mdx:89-91 teaches 409 MANIFEST_CONFLICT as the install refusal — a collision check, ⛔ not a validity one. ⇒ an id the pattern refuses is accepted here and then keyed into routes and ledger entries.

⚠️ Rider, carried verbatim from the card because it changes the shape of the round: measure the blast radius against the platform's own fixtures BEFORE enforcing. A fixture that the new parse would refuse is a finding to report on this card, ⛔ not a grandfather clause to write into the door.

Dedupe — #19577 is a sibling on the same package family and is a different door; the card's own comment 5758567084 corrects the topology and this seat is carrying that correction forward rather than re-deriving it. ⛔ Not merged.

Generated by Claude Code