spec(package-lifecycle): the customizations read's docblock says a disabled package's contributions are never listed, but its fields are listed and served #30086

domain:skills#1 · huangyiirene · session_01J8VVAnMUWA9rufXzFaEh4J

Filing gate: ① a named-location disagreement between the spec text and its one producer. It is an out-of-scope finding of the contract review on PR #30071 (#29411, review comment 6631015666, ③). ⛔ Not a claim. Suggested-grade: p3 (teaching text; no wrong data reaches a user beyond what the served object already shows).

reach: a named real producer, readBaseContributions in packages/runtime/src/domains/packages.ts, which answers GET /api/v1/packages/<base>/customizations.

What disagrees (at origin/main)

• Spec docblock, packages/spec/src/api/package-lifecycle.zod.ts L512–516: "a disabled package's contributions MUST NOT be listed, as the fold drops them". The nav arm's describe at L597 says the same. Both read as covering every kind.
• Spec array describe, the same file L600–605, excludes only a disabled package's flows and navigation items.
• Runtime:
  • The field loop in packages.ts L3347–3356 reads getObjectContributors with no isPackageDisabled check, so it lists a disabled package's extension fields.
  • The object fold (packages/objectql/src/registry.ts L4723–4760) also keeps them on the served object.
  • The flow loop (listItems('flow'), registry.ts L7729–7731) and the nav loop (packages.ts L3380) do filter disabled packages.
• So the list, the served object and the array describe agree with each other, and the docblock sentence is the odd one out.

Wanted

• domain:spec decides which reading governs:
  • (a) Narrow the docblock and the nav describe to flows and navigation, matching the array describe and the runtime.
  • (b) Keep the general rule, and hand domain:server the field filter plus a test. That also means deciding whether the served object should drop a disabled package's extension fields.
• skills/objectstack-platform/SKILL.md (PR docs(skills): the platform skill teaches the package customizations read's contributions #30071) says nothing about disabled packages, so it owes no change either way.

Business reason: Studio draws a base's contributions greyed with their source (#29786). An author or agent reading the spec would expect a disabled package's fields to be gone from that list, and they are not. The docblock is the contract text, so it should match the runtime.

Reader who acts: the domain:spec seat for the decision; domain:server only under (b).

Dedupe: searched contributions disabled package (39 hits) and isPackageDisabled (13 hits). The nearest are #29786 (closed, the Studio drawing), #24097 (closed, a disabled package's object read) and #29851 (open, a nav label in Studio). None covers this. New.