Skip to content

spec: PackageInstallRequestSchema's wrapped branch refuses top-level unknown keys by name — ruling A on #19328 #20249

Description

@objectstack-fleet

Filed by the director seat (summon #30 续, session_01AsCNgFBs8HCjwhyHQsFbx3) from the maintainer's ruling on #19328 (batch #227 item 3, letter A, maintainer 「开始总监决裁」). Reader who acts: the domain:spec execution seat. ⛔ Not a claim. Grading beyond what is written here is triage's.

What the ruling settles

POST /api/v1/packages answers exactly what PackageInstallBodySchema declares since PR #20218 (packages/runtime/src/domains/packages.ts: const declaredBody = PackageInstallBodySchema.safeParse(body), one hit on origin/main ab820016b3). Three of the four residual classes on #19328 are closed by that landing. The last one is the wrapped form's top level: PackageInstallRequestSchema's wrapped branch (packages/spec/src/api/package-api.zod.ts, docblock at :381 「⛔ Do NOT close the wrapped branch with .strict() … (ruling A)」) is declared strip-mode, so a caller who writes { manifest, enabledOnInstall: false } (a misspelling of enableOnInstall) has the key dropped silently and the package installs enabled.

The docblock's ruling A (5716042643, #18058, batch #148 item 4) rested on 「the declaration must not refuse a body the door answers 201 to」 at a time when the door did not parse the body at all. Since PR #20218 the door answers what the declaration says, so that premise is circular and no longer constrains the choice. The manifest and the bare form are already strict; the maintainer ruled the wrapped top level joins them: one rule for the whole install contract (the Kubernetes fieldValidation=Strict / Terraform provider-schema idiom).

Work

  1. PackageInstallRequestSchema, wrapped branch: strip → strict. An unknown top-level key is refused by name, with the same envelope the manifest's and the bare form's unknown keys already get (400 VALIDATION_ERROR, the key named, the remedy: remove it or spell the declared option). ⛔ No alias, no grace window.
  2. The docblock at package-api.zod.ts:381: replace the ruling-A sentence with this ruling's citation ([finding] four residual classes the package install door still answers 201 to, measured unchanged by #19326 (triage: likely four cards) #19328 batch 🔗 Broken links detected in documentation #227 item 3, letter A) and the reason above; do not leave the retired reasoning in place.
  3. Pins: package-api.test.ts's wrapped-branch rows assert the refusal (a misspelled option, a private key) and the controls (manifest alone; manifest + the four declared options round-trip). PR fix(runtime): the package install door parses its whole body through PackageInstallBodySchema #20218's §5 alignment pin (「the door answers what the declaration says」) flips from strip to refusal on its own: re-read its expectation and correct it in the same PR if it asserted the strip.
  4. Changeset: @objectstack/spec minor, **BREAKING** banner, Clause-②: no (narrowing), ADR-0087 registered disposition (the wording of [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 / [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). Reach measured first-party by the [finding] four residual classes the package install door still answers 201 to, measured unchanged by #19326 (triage: likely four cards) #19328 dev: the SDK sends only manifest / settings / enableOnInstall / overwrite; the objectui package dialog sends { manifest }. Out-of-repo callers are NOT MEASURED; say so in the changeset.
  5. [finding] once PR #20218 lands, PackageInstallBodySchema's published docblock still says the install door answers 201 to residual classes 1b, 2, 3 and 4, which it then refuses 400 #20219 (the spec docblocks PR fix(runtime): the package install door parses its whole body through PackageInstallBodySchema #20218 made false) touches the same docblock region; the two may land as one PR if the same dev holds both. Neither is a claim on the other.

Acceptance

Clause-②: no (narrowing)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions