ui tests: stop pinning the exact ObjectSchema key count in app-shell corpus guards, since every additive spec key turns Test UI red for all ui PRs #26239

Filed by seat domain:ui#1 (seat post #25966) · os-steve · session session_017iXjUm1rujwDk7f3KT1Pkk, at the maintainer's request in the project for a structural fix after #26218. ⛔ Not a claim.

What was measured

• ui/packages/app-shell/src/services/MetadataService.retiredObjectEnabled.test.ts:161 and MetadataService.specKeyObjectPayload.test.ts:175 each assert expect(Object.keys(ObjectSchema.shape).length).toBe(N) ("corpus guard"). The comments above the first one record six re-points: 42→43 (editMode), 44 (imageField), 45 (attachedOnRead), 46 (defaultRowScope), 47 (membershipKeys), and now 48 (sharing, feat(spec,plugin-security,lint): sharing.controlledByParent.ownerMayEdit — a detail row's owner updates it with read on the master #26005 → app-shell: MetadataService.retiredObjectEnabled corpus guard expects 47 ObjectSchema keys, main now has 48 after #26005 added sharing, so Test UI is red for every ui PR #26218 / test(app-shell): re-point the ObjectSchema corpus guards to 48 after sharing was adopted #26231).
• Each time, an additive spec key that these files do not read turned Test UI red on every ui PR's merge ref. feat(spec,plugin-security,lint): sharing.controlledByParent.ownerMayEdit — a detail row's owner updates it with read on the master #26005 merged on 2026-10-26 with Test UI skipped by its path filter (closing that gap is tooling: the root tsconfig.json is both the shared base for 72 packages and the scripts/ program (the one DEBT entry, 26 errors); 14 packages re-set module resolution three ways; 18 vitest configs are byte-identical; three debt ledgers are empty #26092), and the ui merge queue then stalled until test(app-shell): re-point the ObjectSchema corpus guards to 48 after sharing was adopted #26231.
• The comment itself says that the spec-adoption fact belongs to packages/types/src/__tests__/object-schema-metadata-spec-derivation.test.ts, and that the count only rides along as a guard for the membership assertions below it (enable present, enabled / _deleted / soft-delete aliases absent).

Ask

Make these guards independent of how many keys ObjectSchema has. Measure first which of these holds, then do one:

• Assert only the membership claims the files are about, and drop the exact count. The types-package derivation test already pins adoption.
• Or derive the expected set from the spec's own authorable-surface/data.json instead of a literal.

⛔ Do not weaken any membership assertion. Also sweep ui/ for other exact-count pins on spec-owned shapes (e.g. Object.keys(<Spec>Schema.shape) with toBe(<n>) or toHaveLength(<n>)), list them in the PR, and convert those of the same kind.

Business reason

Who benefits: every ui PR. An additive change in another lane, which by definition breaks no ui behaviour, should not stop the ui merge queue. Today it costs a p1 card and a full queue round for both ui seats each time.

Who acts on it

The domain:ui seat that owns app-shell services (seat 1). Test-only and app-shell, so no sdui record moves. It lands after #26231, which edits the same two files.

Duplicate check

search_issues on objectstack-ai/objectstack, open, "ObjectSchema shape count pin accept.size ui test": only #26218, the one-time re-point. #26092 covers the CI filter half, not this test design.