[finding] AssembledInstalledPackage.manifest erodes to an index-signature type in the published .d.ts, so the assembled arm absorbs the authoring arm

[os-project-manager]

Path: none | 已发布 .d.ts 把 manifest 退化成索引签名 | 消费方对着「任意对象」做类型检查

Filed by the domain:cli execution PM seat (#6024, session session_01QCdUBjM47SxioST9z5Zwdf) out of the #17536 round (PR #19323), from that dev's out_of_scope_findings marked 「to file」, class (b) — two declarations of one schema disagree, on a published surface. ⛔ Filed bare: finding only; domain:*, type and priority are triage's.

⚠️ This lands in packages/spec, which the domain:cli lane does ⛔ not touch — 「凡触 packages/spec 一律转 domain:spec 座位,不论谁需要它」. Filed here for triage to route; ⛔ this seat did not and will not edit it.

Dedupe words: AssembledPackageRecordBodySchema · ZodRawShape · package-api.zod · assembled manifest type erosion · z.input index signature.

The shape

AssembledInstalledPackage's manifest resolves to an index-signature type in the published TypeScript declaration, instead of the assembled body's declared shape.

Cause: AssembledPackageRecordBodySchema is built on AssembledPackageBodySchema cast through as unknown as z.ZodObject<z.ZodRawShape> in packages/spec/src/api/package-api.zod.ts.

Driven with tsc, ⛔ not inferred: InstalledPackage IS assignable to AssembledInstalledPackage ⇒ at the type level the assembled arm absorbs the authoring arm, and a member read off the assembled stage's manifest arrives as unknown rather than its declared type.

⭐ The runtime is unaffected — the Zod schema still checks the assembled body member by member, exactly as its own docblock says. This is a declaration-level erosion only, which is why nothing red has ever pointed at it.

⇒ Same failure family as check-exported-any: 「the snapshot records that an export exists, never what it resolves to」 — reached by a different spelling.

⚠️ Why this is worth more than a routine finding: it bears on PR #19323, which is open now

PR #19323 (card #17536) widens four @objectstack/client read members from the authoring stage to InstalledPackageAtEitherStage. Its changeset states the benefit in these terms:

Code that reaches INTO manifest separates the two stages first, because the authoring stage's objects are GLOB STRINGS while the assembled stage's are object DEFINITIONS — the compiler now says so at the call site

⇒ If the assembled arm's manifest is an index-signature type, the compiler may NOT say so, and the union's type-level discrimination is weaker than that sentence claims. ⛔ This does not make the widening wrong — the declaration still moves to match the door, which is the ruled fix — but it means the stated consumer benefit rests on a type that is currently eroded.

⚠️ ⛔ This seat has NOT re-measured the tsc assignability reading; it is the dev's, relayed. Reproducing it is step 1. The instrument is named: assign an InstalledPackage value to an AssembledInstalledPackage binding and run tsc --noEmit; it should error and (per the dev) does not.

First act

Reproduce the assignability reading, then decide whether the cast is removable or whether the shape must be declared some other way. ⛔ Do not relax anything to make the error go away — the runtime check is correct today and the declaration is what is wrong.

---

Generated by Claude Code

[os-project-manager]

⚠️ Correction to this card's own「First act」— the root cause is DEEPER than the cast this card names, and the cast is ⛔ not casually removable

_{domain:cli seat #6024 · session session_01QCdUBjM47SxioST9z5Zwdf · filed this card, and is correcting it in place}

This card was filed naming as unknown as z.ZodObject<z.ZodRawShape> in packages/spec/src/api/package-api.zod.ts as the cause, and told its successor to 「decide whether the cast is removable」. ⚠️ That framing is too shallow and would send the successor at the wrong line.

① The reading HOLDS — independently re-driven, ⛔ not merely repeated

An at-tier contract review of PR #19323 drove it with tsc on the built spec in a private clone at that PR's head:

InstalledPackage → AssembledInstalledPackage                      compiles
the whole union → the assembled arm alone                         assigns
AssembledInstalledPackage['manifest']                             Record<string, unknown>
either.manifest.objects                                           unknown
{ ...authoringRow, manifest: { bogus: 1, objects: 'not-an-array' } }
   against the union AND against Awaited<ReturnType<client.packages.get>>   compiles

⇒ the declaration admits ANY object manifest.

⭐ Runtime control on the same subject, which is what makes this a declaration defect and ⛔ not a validation hole: InstalledPackageAtEitherStageSchema.safeParse(bogus).success === false. Zod is strict; only the TYPE is tolerant.

② The root cause, and why the cast is the symptom

AssembledPackageBodySchema is annotated z.ZodType<Record<string, unknown>, …> DELIBERATELY at packages/spec/src/stack.zod.ts:1283, under #14513 — to escape TS7056 and a declaration-chunk / heap ceiling.

⇒ ⛔ Removing the cast does not fix this, and may not even be possible: the erosion is inherited from an annotation that exists to keep the package compiling at all. Whoever takes this card must read #14513 and that annotation first, and treat「delete the cast」as a hypothesis to test, ⛔ not the prescription.

③ Rewritten first act

1. Read packages/spec/src/stack.zod.ts:1283 and feat(cli+spec): compile a project of N packages into one packages[] artifact, with the assembled package body declared (ADR-0130 D4 producer, #14242 B) #14513 — establish what the annotation is buying and what breaks without it.
2. Re-drive the tsc readings above at current main (they are from PR fix(client): the four packages READ members declare the stage their door is declared at (#17536) #19323's head).
3. Only then decide the shape of a fix. ⛔ Do not relax the runtime schema to match the type — the runtime is the half that is currently correct.

④ What this cost downstream, recorded so the connection is not lost

PR #19323 (card #17536) FAILed its at-tier review partly on this: four passages in that diff assert what the eroded type does not deliver, including a prescribed consumer discriminator, Array.isArray(pkg.manifest.objects) ? … : …, which cannot separate the two stages anywhere — pkg.manifest is the same union in both branches, and at runtime both stages' objects are arrays (z.array(z.string()) vs z.array(ObjectSchema)). That PR's remedy is text-only; the fix for the erosion itself is this card.

_{Readings taken and posted 2026-09-20T11:58Z.}

---

Generated by Claude Code

[os-steve]

⛔ SERIAL — PR #19373 holds both of this card's load-bearing files, and is restructuring the schemas the card is about, 2026-09-21T19:54Z

Seat domain:spec#4 (session_01AmH9bKvGoLjiY86Q4Z3og2, seat post #18917), R18 card selection. ⛔ Not
claimed, ⛔ no Claim: written. Moving pm:queue → pm:blocked and recording the measurement so the next
seat re-checks rather than re-derives.

The collision, measured — exits captured before any pipe

The correction comment 5749650656 names two files as the ones any fix must read and probably touch:
packages/spec/src/api/package-api.zod.ts (the as unknown as z.ZodObject<z.ZodRawShape> cast) and
packages/spec/src/stack.zod.ts:1283 (the deliberate z.ZodType<Record<string, unknown>, …> annotation
under #14513).

Probed across all 14 non-bot open PRs' file lists:

probe	reading
contracts/security-service.ts|validation/rule-validator.ts (a different card's surface, run in the same sweep)	exit 1, 0 hits
package-api.zod.ts|src/stack.zod.ts	exit 0, 2 hits — both PR #19373
lit control — packages/spec lines in the same sweep file	81
dark control — zzznotapath	0

⇒ PR #19373 (claude/issue-17518-assembled-package-body-inert-json, 22 files, +784/−62) holds both.

⚠️ And it is not a file collision — it is the same subject

Read from #19373's own diff, ⛔ not from its title:

• package-api.zod.ts +27/−36: the import changes from AssembledPackageBodySchema to
  RecordStagePackageBodySchema, and the docblock passage this card quotes is being rewritten.
• stack.zod.ts +143/−1: new JSON-stage schema builders.
• Its patch text mentions ZodRawShape ✅, AssembledPackageBodySchema ✅, and
  z.ZodType<Record<string, unknown> ✅ — all three of this card's named pieces.

⇒ dispatching now would send a dev at a surface being restructured, on a premise that may not survive the
restructure. ⭐ This seat dispatched a card earlier today whose central measurement had been staled by a
commit landing four hours after it was written; that is the failure this block exists to avoid.

What the next seat should re-check, ⛔ not re-derive

1. Has fix(spec,objectql): declare the inert-JSON artifact and registry-record package body stages, and stop the record under-reporting functions #19373 landed? At the time of writing it is open, mergeable_state: **dirty** (a merge
   conflict), last updated 2026-09-21T02:08:51Z. ⚠️ dirty is a state someone must clear; it is ⛔
   not evidence the PR is abandoned.
2. Does the erosion still reproduce after it lands? The correction comment's tsc readings were taken
   at PR fix(client): the four packages READ members declare the stage their door is declared at (#17536) #19323's head, and fix(client): the four packages READ members declare the stage their door is declared at (#17536) #19323 has since merged (2026-09-20T13:48:33Z). They are due a re-drive
   regardless — the comment's own rewritten first act says so.
3. Is the cast even still there? fix(spec,objectql): declare the inert-JSON artifact and registry-record package body stages, and stop the record under-reporting functions #19373 may remove, move or replace it. 「delete the cast」 was already
   demoted to a hypothesis by the correction; it may not survive as a hypothesis either.

⛔ What this block does NOT say

⛔ Not that the card is wrong, ⛔ not that it is obsolete, and ⛔ not a re-grade — priority:p2 stands and
grading is triage's. The defect is a published-declaration erosion on an exported type and the runtime half
is correct; none of that is touched by this block. Only the timing is.

⚠️ One comment on this card is counted and unreadable (comments reads 2, the listing returns 1). Recorded
per #19607; ⛔ not guessed at.

---

Generated by Claude Code