docs(runtime,spec): the install door's comment states the wrapped top level is closed, and item 2 cites its ruling record

The install branch comment in packages/runtime/src/domains/packages.ts said
PackageInstallRequestSchema was strip mode and forbidden to close; since the
wrapped branch became a strictObject that is false. It now states the close,
the door's 400 VALIDATION_ERROR with nothing installed, and cites ruling record
5856869656. The residual item-2 clause in package-api.zod.ts gains the same
record id inline. Comments only; no code token moves.

Claude-Session: https://claude.ai/code/session_01CiCTczDo7tGhafXjf61dUJ
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

packages/runtime/src/domains/packages.ts

@@ -1000,14 +1000,17 @@ export async function handlePackagesRequest(deps: DomainHandlerDeps, path: strin
             // declaration's own docblock forbids it («a caller that needs an
             // option sends the wrapped form»).
             //
-            // ⚠️ What the union does NOT refuse, deliberately: an unknown key at
-            // the TOP LEVEL of the wrapped form. `PackageInstallRequestSchema`
-            // is a plain `z.object` (strip mode) and its docblock forbids
-            // closing it, so `{ manifest, bogus }` parses green with `bogus`
-            // dropped — and this door, reading only parsed keys, now does
-            // exactly what the declaration says. Refusing it here without the
-            // declaration would make the published contract admit a body the
-            // door refuses; that is the declaration's decision to make.
+            // ⭐ The TOP LEVEL of the wrapped form is closed too — by the
+            // declaration, not by this door. `PackageInstallRequestSchema` is a
+            // `strictObject` (ruling record `5856869656`, decision batch #227
+            // item 3, letter A), so an unknown top-level key such as
+            // `{ manifest, enabledOnInstall: false }` fails the union by name,
+            // and this door answers `400` / `VALIDATION_ERROR` and installs
+            // nothing — with no line of its own for it: reading only parsed
+            // keys, it does exactly what the declaration says. ⛔ Never refuse or
+            // admit a key here that the declaration decides the other way: the
+            // published contract and this door would then answer differently,
+            // and which keys the body may carry is the declaration's decision.
             //
             // The verdict is answered after the `id` and `version` legs below,
             // which keep their own published sentences; every later read (the

packages/spec/src/api/package-api.zod.ts

@@ -423,7 +423,8 @@ export type PackageInstallRequestParsed = z.infer<typeof PackageInstallRequestSc
  *    - 1b. missing `type` — still OPEN, answered `201` (both door drives
  *      above);
  * 2. unknown keys on either form — refused by name on the bare branch and,
- *    since decision batch #227 item 3, on the wrapped one too, `201` either way;
+ *    since ruling record `5856869656` (decision batch #227 item 3), on the
+ *    wrapped one too, `201` either way;
  * 3. a string-typed `enableOnInstall` / `overwrite` — the door compares
  *    against `true`/`false` and `'true'`, so `'false'` installs ENABLED and a
  *    body-side `'true'` overwrite is treated as ABSENT;