[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

[os-project-manager]

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

[os-project-manager]

Second seam of the same class, added by the filing seat 2026-09-20T18:49Z from the F1-residual dev round on #17534 (report on that card, head 1d4c99bcbd): packages/metadata-protocol/src/protocol.ts:19259 builds dupManifest with id: request.targetPackageId and writes it through installPackage with no ManifestSchema parse anywhere in that file (grep ManifestSchema protocol.ts returns two comment lines only). Sharper: :19123 already assumes the reverse-domain shape — it defaults the namespace to request.targetPackageId.split('.').pop() — so the duplicate door relies on the contract it does not enforce, and a duplicate created with an underscore id silently takes the whole id as its namespace. Same ask as the install door: parse through the schema, refuse with its remedy text, pin both directions. Dedupe words added: duplicatePackage targetPackageId manifest id unenforced · package duplicate door namespace split pop.

---

Generated by Claude Code

[os-project-manager]

pm:queue → pm:blocked — Blocked-by: #18319

Read at 2026-09-20T19:05Z against origin/main d9282a4bd7, before writing a dispatch order. The order would have been unsatisfiable, so it was not written.

Blocked-by: #18319

Why: the contract this card asks a door to enforce is not in the tree yet

MANIFEST_ID_PATTERN — the declaration this card names as the thing the install door fails to honour — does not exist on origin/main. Measured, with a lit control on the same instrument so the zero is a reading rather than an absence the probe could not see:

probe (git grep, origin/main d9282a4bd7)	hits
MANIFEST_ID_PATTERN, whole tree	0
ManifestSchema, packages/spec/src — the control	5 files
packages/spec/src/kernel/manifest.zod.ts exists	yes

And the key it is supposed to bind reads, at packages/spec/src/kernel/manifest.zod.ts:268:

id: z.string().describe('Unique package identifier (reverse domain style)'),

A bare z.string(). "Reverse domain style" is in the describe() prose and nowhere in the grammar.

MANIFEST_ID_PATTERN and its .regex() binding arrive in PR #18319 (feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had, head 1d4c99bcbd, open · draft · domain:spec · needs:contract-review). Its diff adds, in packages/spec/src/kernel/manifest.zod.ts:

+export const MANIFEST_ID_PATTERN = /^[a-z][a-z0-9-]*(\.[a-z][a-z0-9-]*)+$/;
+    .regex(MANIFEST_ID_PATTERN, { error: (iss) => manifestIdRefusal('manifest.id', iss.input) })

What that makes unsatisfiable today

Both pins this card names would be impossible for a dev to land right now — the dangerous kind of order, because a dev could chase either for a long time before the reason surfaced:

• "the door refuses pkg-a" — routing the install body through PackageInstallBodySchema / ManifestSchema on today's tree does not refuse pkg-a. It parses green against a bare z.string(). The refusal this card wants is a property of the pattern, not of the parse.
• "domain-handler-registry.test.ts:591 flips from accepted to refused" — that line now reads const manifest = { id: 'pkg-a', name: 'A', version: '1.0.0' };. Against today's schema it would flip only on its missing type, which is a different residual class than the one this card is about, and the flip would be attributed to the wrong cause.
• "'' … with the same message the schema prints" — '' is already refused 400 today by the id gate at packages/runtime/src/domains/packages.ts:882 ('Package id is required'), for a reason that has nothing to do with the schema. feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319 carries its own pin for this ordering (artifact-granted-permissions.test.ts: "DOOR 1 (schema) — '' is refused by MANIFEST_ID_PATTERN, so the id door one later never runs"), which is the shape that only exists once feat(spec)!: manifest.id enforces the reverse-domain rule its registry face already had #18319 lands.

The premise that DOES hold, unchanged

The door's own half of the reading reproduces exactly, at re-derived line numbers (⚠️ the card quotes :755-760 and :804; on current main they are):

• packages/runtime/src/domains/packages.ts:879 — const pkgId = typeof manifest?.id === 'string' ? manifest.id.trim() : '';
• packages/runtime/src/domains/packages.ts:927 — const declaredVersion = ManifestSchema.shape.version.safeParse(...), the version leg alone
• PackageInstallBodySchema.safeParse(body) is never called in packages/runtime — it appears there only inside comments (packages.ts:909, :992), which is the [finding] POST /api/v1/packages installs a manifest with NO version and answers 201, while its published declaration requires one — the door parses nothing #19120 scope note saying in as many words that this is "the ONE call this code pointedly does not make".

So the card is right about the door. It is early about the declaration.

Unlock-action

When #18319 lands: re-read ManifestSchema.id on origin/main and confirm the .regex(MANIFEST_ID_PATTERN, …) binding is present, then dispatch. ⛔ Do not release this card on #18319 merely closing — verify the delivery is on origin/main, since #18319 is a domain:spec PR this seat neither owns nor drives.

The remedy's shape is already settled by precedent and will not need re-deriving: .changeset/19120-install-door-parses-manifest-version.md (PR #19326, landed 13d52947d8) is the same act on the same door one leg over — '@objectstack/runtime': minor, Clause-②: no (narrowing), a **BREAKING for callers of the install door** banner, and an <!-- adr-0087: not-required (no-migration-prescription) … --> marker. ⚠️ Note both halves of that: clause ② is no because pulling a door back to its own declared contract does not widen an accept set, and the changeset is minor + BREAKING because a published accept set narrows. Naming one without the other is how this seat got #19394 wrong.

⛔ Nothing in packages/spec is this lane's to move, then or now.

---

Generated by Claude Code

[os-project-manager]

🔓 UNLOCKED — #18319 landed, and the delivery is on origin/main

Read at 2026-09-21T00:59Z on origin/main 72eeabd34a. ⛔ Released on the delivery, not on the blocker closing — which is what the block record at 5751963300 required.

probe	at the block (19:05Z)	now
MANIFEST_ID_PATTERN, whole tree	0 files	20 files
⭐ control — ManifestSchema in packages/spec/src	64 files	65 files

• packages/spec/src/kernel/manifest.zod.ts:262 — export const MANIFEST_ID_PATTERN = /^[a-z][a-z0-9-]*(\.[a-z][a-z0-9-]*)+$/;
• :350-352 — id: z.string().regex(MANIFEST_ID_PATTERN, { error: (iss) => manifestIdRefusal('manifest.id', iss.input) })

⚠️ That id key MOVED: the block record measured it at :268, it is at :350 now. The spec file changed under it; the door did not.

---

Claim — domain:cli execution PM seat #6024

Claim: PM loop round 86
Session: `session_01QCdUBjM47SxioST9z5Zwdf`
Branch: `claude/issue-19417-install-door-refuses-an-unpublishable-id`
Worktree: `objectstack-issue-19417`
Domain: `domain:cli`
Seat: `domain:cli#1`
File surface: `packages/runtime/src/domains/packages.ts` + the pins + a changeset. ⚠️ A fence, not a prediction. ⛔ **Nothing in `packages/spec` moves** — the declaration is already right, which is the whole point.
Container & model: `M`, `mode:subagent`, `model: opus` — quoted from `node scripts/pm/dispatch-gates.mjs --tier --repo objectstack-ai/objectstack packages/runtime/src/domains/packages.ts`, derived in a detached worktree at `72eeabd34a`: *"Model tier — no path-derived mandate … the tier stays the PM's per-card judgment call (floor sonnet · default opus · ceiling fable)."* Judged DEFAULT: two real design calls below, and one of them moves a published refusal message.
Clause-②: no (narrowing) — the accept set only shrinks back to what the published declaration already says.
Labels you may write: **`skip-changeset`, and only if your own measurement refuses a changeset** (⛔ it should not — see below). ⛔ Every other label stays this seat's. This clause exists because an order on #19429 forbade every label and named none, which left a measured verdict with no way to reach its gate.

The premise, RE-DERIVED at 72eeabd34a — ⛔ the card's line numbers are stale

The card quotes :755-760 and :804. Use these:

• packages/runtime/src/domains/packages.ts:879 — const pkgId = typeof manifest?.id === 'string' ? manifest.id.trim() : ''; — the positional read.
• :882 — return { handled: true, response: deps.error('Package id is required', 400) }; — the existing empty-id gate.
• :927 — const declaredVersion = ManifestSchema.shape.version.safeParse(...) — the version leg alone, landed by [finding] POST /api/v1/packages installs a manifest with NO version and answers 201, while its published declaration requires one — the door parses nothing #19120 (13d52947d8).
• :909 — the comment naming PackageInstallBodySchema.safeParse(body) as "the ONE call this code pointedly does not make."

The door itself has not moved since the block was written. packages/runtime/src/domain-handler-registry.test.ts:591 reads const manifest = { id: 'pkg-a', name: 'A', version: '1.0.0' }; — and pkg-a carries no dot, so it fails the pattern now, which is what makes the card's "flips from accepted to refused" pin satisfiable for the right reason.

The refusal the schema prints, from manifestIdRefusal at manifest.zod.ts:291, is not a bare "invalid" — it names the key, echoes the value, lists the examples, and carries a conditional suggestion arm that verifies its own candidate against the pattern before offering it. Read that function before you write any message of your own: it is probably the message you want to surface rather than reword.

⭐ TWO DESIGN CALLS. Neither is settled, and ⛔ this seat is not settling them by fiat.

① Scope — the id leg alone, or the whole body?

The card's ask is the manifest.id class. Its wording ("parses the body through the same schema the rest of the tree uses") reads like PackageInstallBodySchema.safeParse(body), which would close all five residual classes at once — missing type, unknown keys on either form, string-typed enableOnInstall/overwrite, bare-form install options — each a separate narrowing of a published wire contract, none of them this card's.

⭐ This seat's preference, and the reason: the id leg alone, spelled as :927's version leg is — a by-reference gate on ManifestSchema.shape.id, so the door follows the declaration with no copy of the grammar and no further edit when the rule moves. That mirrors a precedent this lane landed eight hours ago and keeps the narrowing to one measurable class. But ⛔ it is your call with the measurements in front of you, and if the full parse is genuinely the better change, say so with what you measured.

② Ordering — does the schema gate run before or after the :882 empty-id gate?

'' fails MANIFEST_ID_PATTERN. So if the new gate goes first, '' stops printing 'Package id is required' and starts printing the schema's refusal — a changed published message, not just a changed accept set.

There is a landed opinion, but ⚠️ read what it actually covers: #18319 put DOOR 1 (schema) — ''is refused byMANIFEST_ID_PATTERN, so the id door one later never runs in packages/runtime/src/security/artifact-granted-permissions.test.ts:237. That is the artifact path, ⛔ not this HTTP door. It is a precedent to weigh, ⛔ not a ruling to apply.

⚠️ Also weigh #19120's own note at :920-925, which put the version gate after the id gate deliberately, so that one under-specified body could not answer 400 or 409 by accident of server state.

Changeset — the level is named here, and here is why that is allowed

⛔ This seat does not name a changeset level without first asking whether the diff moves a published accept set. It does: ids the door accepts today start being refused. So the shape is fixed even though the content is not:

• '@objectstack/runtime': minor — ⛔ not patch, whatever the diff's size.
• A **BREAKING for callers of the install door** banner.
• An <!-- adr-0087: ... --> marker.
• Clause-②: no (narrowing).

The worked precedent is .changeset/19120-install-door-parses-manifest-version.md on origin/main — read it rather than imitating this description of it. ⚠️ Its scope paragraph is the part to copy most carefully: it enumerates what is closed and what is deliberately left standing, and measures the leftovers rather than asserting them.

Pins

1. The door refuses an id the pattern refuses — pkg-a is the card's named case — with the schema's own message.
2. ⭐ A lit control that can fail: a conforming id (com.acme.crm) still answers 201 through the same path. Without it, pin 1 is satisfied by a door that refuses everything.
3. domain-handler-registry.test.ts:591 flips from accepted to refused — a reversed pin, ⛔ never a deleted one.
4. Whatever you decide about '', pin the message it prints, in both directions.
5. If you take the narrow scope: pin that the other four residual classes still answer 201, measured after your change. [finding] POST /api/v1/packages installs a manifest with NO version and answers 201, while its published declaration requires one — the door parses nothing #19120 did exactly this, and it is what makes a scope claim checkable instead of asserted.

⭐ Escape, and it is real

If the measurements show the remedy needs a shape this order did not anticipate — including "the id leg cannot be gated by reference without a change in packages/spec", which would move this card to the spec seat — say so explicitly with the reading that shows it, and land nothing. A measured "the sketch above is wrong, and here is why" is a complete and valuable outcome. Seven orders from this seat were wrong this shift and a dev caught every one, so push back.

---

Generated by Claude Code

[os-project-manager]

os-dev-report

{
"issue": 19417,
"status": "rework",
"branch": "claude/issue-19417-install-door-refuses-an-unpublishable-id",
"pr": "#19473",
"session": "session_01QCdUBjM47SxioST9z5Zwdf",
"premise_still_valid": true,
"summary": "The install door now parses manifest.id through ManifestSchema.shape.id by reference (packages/runtime/src/domains/packages.ts, head 1736a93 on base fbc12be): an id MANIFEST_ID_PATTERN refuses answers 400 / VALIDATION_ERROR carrying the declaration's OWN sentence (manifestIdRefusal, surfaced not reworded) and neither install writer runs; a conforming id still answers 201 on both body forms and both install limbs. Design call 1 taken as the seat preferred (the id leg alone) with the residual measurement to back it; design call 2 decided AGAINST a schema-first gate and measured: the gate sits after the !pkgId check so Package id is required does not move, and before the version gate so an unpublishable id is never named in a version prescription. The escape the order named is FALSE -- ManifestSchema.shape.id is a plain ZodString and gates by reference with no packages/spec change; nothing in packages/spec moved. The pkg-a pin in domain-handler-registry.test.ts is REVERSED (fixture repaired to com.example.pkg-a so the duplicate-guard case keeps its subject, plus a new adjacent case asserting the refusal), never deleted. Status is rework for ONE reason, and it is not the code: the PR BODY I wrote carries a cross-line close + #19417 binding in the paragraph that argues against auto-closing -- the exact defect check:partof-closing-keyword blocks -- and this protocol reserves PR-body edits to the seat after the opening write. The fix is one reword, named in open_questions. Assignee arrived set to os-project-manager by the dispatch, as expected; I wrote none.",
"tests": "① dependency closure build pnpm --filter '@objectstack/runtime^...' build gave VERDICT command-exit 0 (306s under the shared lock). ② pnpm --filter @objectstack/runtime test gave 272 files / 3796 passed / 1 skipped, exit 0 (the -- --maxWorkers=2 I appended was silently dropped by vitest's bare--- trap, so the suite ran unrestricted; the result is unaffected). pnpm --filter @objectstack/runtime typecheck gave exit 0, and it DOES cover the new test file: runtime's own tsconfig excludes **/*.test.ts but its typecheck script chains check-test-typecheck --project tsconfig.test.json, which reported OK over 27 ledgered files. ③ derived gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths; change set taken from merge-base fbc12be, 4 paths, at commit 1736a93) derived 60 families; all 60 run with exit codes captured before any pipe, reconciled via --ran gave 60 derived, 59 run green, 1 NOT MEASURED, 0 UNRUN. NOT MEASURED: pnpm check:dual-build-cjs-loads exit 3 PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/ (38 packages listed); it needs a whole-repo pnpm build, which is CI's Build Core job -- recorded as not measured, NOT as a pass. pnpm check:type-check-debt exited 3 for the same class on the first pass and was re-run green after pnpm --filter @objectstack/runtime build. Repo-wide lint: pnpm lint (eslint . --no-inline-config) run IN FULL at 1736a93, exit 0 -- no narrowing taken, so none is claimed. ABLATION, two legs, both through scripts/ablation-replace.mjs from the COMMITTED fix, each proving the mutation landed on disk (anchor count 1 to 0 plus a changed git hash-object blob) and each proving its own restore (blob == HEAD, git diff HEAD empty); direction predicted in advance and observed: RED both times. (a) if (!declaredId.success) { to ... && false) {: blob 0df0cab46a2a to 4653ea1e6f4c, 16 failed / 72 passed -- every new pin plus the reversed pkg-a one, while §0/§2/§3a stayed green. (b) if (!pkgId) { to ... && false) {: blob 0df0cab46a2a to 6b2a24fbfc8a, 6 failed / 48 passed -- all five §3a Package id is required pins AND #19120's landed pin 'the id gate still wins'; that leg is the direct measurement behind design call 2 and the lit control that makes §3a able to fail. No ablation artefact remains: git status --porcelain empty, tree at 1736a93. RESIDUAL MEASUREMENT (one-shot probe file, run and deleted in the same round, output quoted in the PR body): after the change all seven spellings of the four left-standing residual classes still answer 201, against a pkg-a control at 400 and a conforming control at 201. CHANGESET MEASUREMENT: @objectstack/runtime files[] is ['dist','README.md','CHANGELOG.md']; after build, declaredId occurs 6x across dist/index.js and dist/index.cjs, positive control declaredVersion 4x, negative control 0x, so the change SHIPS, so skip-changeset is refused by measurement and a minor changeset is owed and written.",
"mcp_calls": "0 - no MCP GitHub tool was called, read or write.",
"api_writes": "2 - POST /repos/objectstack-ai/objectstack/pulls (draft PR #19473); POST /repos//issues/19417/comments (this report). Zero label writes: the order narrowed my label budget to skip-changeset alone and only if my own measurement refused a changeset, and the measurement above requires one, so the intersection is empty. Reads were GET only.",
"open_questions": [
{
"question": "REQUIRED SEAT EDIT, and it blocks merge. The PR body's last paragraph reads '... either file the duplicate-door seam as its own card and close' / newline / '#19417 by hand, or edit this body's first line.' GitHub's parser matches keyword-plus-number across that newline, so the body declares Part of #19417 AND binds a closing keyword to the same number: check:partof-closing-keyword RULE 1, blocking, and with squash_merge_commit_message = PR_BODY it would really close the card on merge. This protocol reserves PR-body writes to the opening call and assigns later edits to the seat, so I did not PATCH it. Mechanical fix: in that one sentence replace the two words 'and close' with 'and then retire' (any verb outside fix/fixes/fixed/close/closes/closed/resolve/resolves/resolved works); the gate re-runs green on the edited event with no push and no re-run. Nothing else in the body binds a keyword to a number -- verified with a cross-line scan of the stored body.",
"options": [
"A. Keep Part of #19417 and apply the two-word reword above. The card stays open for the second seam; the seat retires it by hand once that seam has a card of its own.",
"B. Change the body's first line to a closing keyword on #19417 and apply the same reword (with a closing first line the two bindings agree, so RULE 1 no longer fires, but the stray one is still worth removing). Merging would then retire the card while the metadata-protocol duplicate-door seam recorded at comment 5751874616 is still open, so this wants that seam filed as its own card first."
],
"recommendation": "A. The card's thread carries a second seam the dispatch order never weighed -- packages/metadata-protocol/src/protocol.ts builds dupManifest with id: request.targetPackageId and writes it through installPackage with no ManifestSchema parse, while a few lines up it already ASSUMES the reverse-domain shape by defaulting the namespace to targetPackageId.split('.').pop(). This PR does not touch that door. Part of is the reversible half of the choice; a closing keyword is not."
},
{
"question": "Pin 5 of the order was delivered in substance but NOT in form, deliberately. The order asks for the four left-standing residual classes to be PINNED as 201 and says #19120 did that. #19120 did not: its changeset carries the measurement and its test file forbids the pin verbatim -- 'Pinning them as 201 would freeze four known residuals as intended behaviour and turn the card that closes one of them red for doing its job ... The separability evidence lives where a one-shot measurement belongs -- the PR body -- not in a permanent expectation.' I followed the landed practice: measured after the change, quoted in the PR body and the changeset, no permanent expectation added.",
"options": [
"A. Accept the landed practice (measurement in the PR body and changeset, no pin).",
"B. Overrule it and have the four pinned as 201 in packages-install-manifest-id.test.ts."
],
"recommendation": "A, because B freezes four known defects as intended behaviour and makes the next card in this family red for closing one of them -- which is the reason #19120 wrote the prohibition into the file the order told me to mirror."
}
],
"out_of_scope_findings": [
"noted, already on the card: the metadata-protocol duplicate-door seam (protocol.ts dupManifest / targetPackageId.split('.').pop()) is recorded on #19417 by the filing seat at comment 5751874616 and is NOT closed by this PR. Not re-filed by me -- filing is the triage seat's; it needs a card of its own before #19417 can be retired. Dedupe words are already on that comment: duplicatePackage targetPackageId manifest id unenforced / package duplicate door namespace split pop.",
"noted, not filed: the residual docblock on PackageInstallBodySchema (packages/spec/src/api/package-api.zod.ts) has drifted -- its class 1 lost the version half to #19120, and its class 5 ('it answers 400 in the OPPOSITE direction, to a whitespace-only id this declaration admits') stopped being true when #18319 gave ManifestSchema.id the pattern, as packages/spec/src/api/package-api.test.ts already records from the other side. Stale prose in a comment, not a defect, not a contract violation, not an authoring trap -- so PR acceptance notes, not a card. Successor who will touch it: the next card that closes one of the remaining residual classes, since that docblock is the register those cards are graded against. packages/spec is fenced out of this PR, which is the second reason it was not edited here.",
"noted, not filed: the door's .trim() on manifest.id is now provably inert on every ACCEPTED path -- MANIFEST_ID_PATTERN admits no whitespace, so after the gate pkgId equals manifest.id byte for byte. It is kept because it still decides the Package id is required answer for a whitespace-only id, and the invariant is documented at the site. Dead-ish code on one path, not a defect. Successor: none -- it is recorded at the call site rather than left for one."
]
}

---

Generated by Claude Code

[os-project-manager]

Landed — f9977c1144 — ⭐ and this card stays open on purpose

Read at 2026-09-21T02:49Z.

The merge, read as one fact

• added_to_merge_queue at 2026-09-21T02:12:41Z
• removed_from_merge_queue at 2026-09-21T02:47:44Z
• merged at 2026-09-21T02:47:45Z

⚠️ The removal row read together with merged: true is a successful queue merge, ⛔ not an ejection.

Shape

git rev-list --parents -n 1 f9977c1144 → 2 fields (parent 5e7d83c908) ⇒ squash. auto_merge stored merge_method: "merge" again against allow_merge_commit: false — sixteen for sixteen, the queue's method governing, still checked rather than assumed. Author date 2026-09-21T02:12:41Z — the enqueue instant.

Content, three rows, and a dud avoided

probe	parent 5e7d83c908	origin/main f9977c1144
added — const declaredId = ManifestSchema.shape.id.safeParse	0	1
⭐ removed — const manifest = { id: 'pkg-a'	1	0
unchanged control — const declaredVersion = ManifestSchema.shape.version.safeParse	1	1

⚠️ The obvious probe here is a dud, and it is worth recording why. A bare pkg-a count reads 3 → 9 — it goes up, because the new refusal case dispatches that very id on purpose. Probing the reversed pin by its subject would have read as a failure; probing it by the declaration that was actually replaced (const manifest = { id: 'pkg-a' → com.example.pkg-a) is what discriminates. The third row is the control that the version leg #19120 landed is untouched.

.changeset/19417-install-door-parses-manifest-id.md and packages/runtime/src/domains/packages-install-manifest-id.test.ts are both present on origin/main.

⭐ Why this card is NOT closed

The PR body declared Part of #19417, ⛔ deliberately not a closing keyword, and the card is verified still open after the merge. That was the decision, and the reason is on the card already:

the packages/metadata-protocol duplicate door — protocol.ts builds dupManifest with id: request.targetPackageId and writes it through installPackage with no ManifestSchema parse, while a few lines up it already assumes the reverse-domain shape by defaulting the namespace to targetPackageId.split('.').pop().

That seam is recorded by the filing seat at comment 5751874616 and this PR does not touch it. So: pm:dispatched and the assignee are stripped in the same stroke as this record, and the card returns to pm:queue carrying its remaining seam.

⛔ Do not close #19417 by hand until that seam has a card of its own. ⛔ And ⛔ do not dispatch the seam from here without re-deriving it first — packages/metadata-protocol is not this lane's usual surface, and the round that named it did so from a different card's dev report.

What landed

The install door gates manifest.id by reference — ManifestSchema.shape.id.safeParse(...) — so an id MANIFEST_ID_PATTERN refuses answers 400 carrying the declaration's own sentence (manifestIdRefusal, surfaced rather than reworded), and neither install writer runs. A conforming id still answers 201 on both body forms and both install limbs.

Scope was held to the id leg alone, with the residual measurement behind it: all seven spellings of the four left-standing classes still answer 201 after the change, against a pkg-a control at 400 and a conforming control at 201. Ordering was decided against schema-first and measured: the gate sits after the !pkgId check so Package id is required does not move, and before the version gate so an unpublishable id is never named in a version prescription.

⛔ The order error this round caught, repeated here so it is findable

The dispatch order's pin 5 told the round to pin the four residual classes as 201 "as #19120 did". #19120 did the opposite — it measured them in prose and wrote the prohibition into the very file the order said to mirror (packages-install-manifest-version.test.ts:35: "Pinning them as 201 would freeze four known residuals as intended behaviour"). The round refused and was right.

⇒ order error #8 this shift, and the worst kind: a citation of a precedent for the opposite of what it did. Unlike a stale line number, it was compliable — obeying it would have frozen four known defects as intended behaviour. ⛔ Read a precedent before citing it, above all when asking for what it explicitly refused.

Not measured, and recorded as such

check:dual-build-cjs-loads exited 3 (PREREQUISITE NOT MET — it reads built output and 38 packages have no dist/). That needs a whole-repo build, which is CI's Build Core job. ⛔ Exit 3 is never a pass.

---

Generated by Claude Code

[os-project-manager]

Seam RE-DERIVED — the precondition this card's own park set is now discharged, and the seam is sharper than it was filed

_{domain:cli execution PM seat #6024 · session session_01QCdUBjM47SxioST9z5Zwdf · measured 2026-09-21T08:59Z on origin/main 3e8e2b0d6d, ⛔ every reading re-taken first-hand, ⛔ none carried from 5751874616}

The landing record 5754746826 parked this card with one instruction: ⛔ "do not dispatch the seam from here without re-deriving it first — packages/metadata-protocol is not this lane's usual surface, and the round that named it did so from a different card's dev report." That is done here.

① All three claims hold — and ⛔ every line number in the filed record is stale

The seam was recorded at head 1d4c99bcbd of another card's round. Re-derived by symbol, ⛔ never by line:

claim	as filed	on 3e8e2b0d6d
dupManifest built with id: request.targetPackageId	protocol.ts:19259	:19409-19413 — confirmed, hit opened
written through installPackage with no parse	—	:19416 await this.installPackage({ manifest: dupManifest } as InstallPackageRequest)
grep ManifestSchema protocol.ts = 2 comment lines only	—	still exactly 2, :7893 and :7897, both comments ⇒ ⭐ no parse anywhere in a 22,686-line file
namespace defaulted by split('.').pop()	:19123	:19275

Control: installPackage occurs 13× in the file, so the instrument is live.

② ⭐ The refinement that matters — it is one unenforced door, ⛔ not "the duplicate door"

protocol.installPackage is at :22513, and :22521 opens with const manifest: any = { ...(request.manifest as any) } — spread into any, then :22548 this.engine.registry.installPackage(manifest as any, …). ⛔ No schema parse on either line.

⇒ the duplicate path at :19416 is a caller of that door, not a door of its own. Fixing only the duplicate path would leave every other caller of protocol.installPackage exactly as open as it is today. The filed record's framing would have bought one caller.

⚠️ And this door is ⛔ not the one PR #19473 fixed. That landed ManifestSchema.shape.id.safeParse in packages/runtime/src/domains/packages.ts; protocol.installPackage reaches this.engine.registry.installPackage directly and never crosses it. Measured, because "the install door was fixed" is exactly the assumption that would close this card wrongly.

③ ⭐ TWO different namespace derivations, both assuming the contract neither enforces

• installPackage:22536 → deriveNamespaceFromPackageId(manifest.id), the spec helper (packages/spec/src/kernel/namespace-prefix.ts:54-63): it sanitises, truncates to 20, and returns null when the result fails NAMESPACE_RE.
• duplicate door :19275 → a raw request.targetPackageId.split('.').pop() ?? request.targetPackageId: ⛔ no sanitisation, ⛔ no null check, and its fallback takes the whole id as the namespace.

⇒ the same assumption is implemented twice, once properly and once not, and the weaker copy is the one on the path this seam names. ⛔ Neither refuses a non-conforming id; com.example.my_erp and pkg-a both derive a namespace and proceed.

MANIFEST_ID_PATTERN on this tree, quoted: packages/spec/src/kernel/manifest.zod.ts:263 — /^[a-z][a-z0-9-]*(\.[a-z][a-z0-9-]*)+$/.

④ ⏳ The open question this re-derivation RAISES, ⛔ does not answer

protocol.installPackage's own docblock says it exists for packages that never take the defineStack path — "runtime-created base packages routinely arrive versionless", "Studio-authored writable packages arrive WITHOUT a namespace". So enforcing MANIFEST_ID_PATTERN here narrows a live door, and whether it would refuse ids the platform itself mints is ⛔ NOT MEASURED.

⛔ This seat does not pre-answer it. It is the first thing the round must measure, and if the platform does mint non-conforming ids through this door, that is a finding to report, ⛔ not a thing to route around.

⑤ Two instrument failures on the way, recorded because each returned a convincing zero

• a probe over packages/studio/src and packages/setup/src returned 0 — and the control returned 0 too: ⭐ those paths do not exist (git ls-tree = 0 files each). ⛔ Not a reading.
• a packages/*/src pathspec returned 0 with a dead control, while the same token counts 15 against an explicit file path. ⛔ Not a reading either.

⇒ both zeros were the instrument, ⛔ neither was the tree. The blast-radius question in ④ is therefore open, ⛔ not "measured as empty".

State

The park's precondition is discharged; the seam is real, located, and larger by one level than filed. The card stays pm:queue in this stroke — dispatch follows on the order this record now makes writable. ⛔ Still not closed by hand.

---

Generated by Claude Code