Observation-class, filed unassigned per Prime Directive #10. Tripped over while tracing the real app-list endpoint for #4887 (PR #4937); not fixed there — out of that card's scope, which was six comments only.
Measurement (worktree off objectui origin/main @ 25c8007, framework origin/main @ 49a49a739)
packages/data-objectstack/src/index.ts has 14 client.meta.* call sites. Twelve pass the metadata type in the singular, one passes a caller-supplied category variable, and two pass a plural collection spelling:
| line | method | type argument |
|---|
| 3258, 3421 | getItems | 'view' |
| 3298, 3633 | getItem | 'view' |
| 3378, 3556, 3655 | saveItem | 'view' |
| 3506 | getItems | 'mapping' |
| 3846 | getItem | 'app' — probeAppAccess |
| 3891 | saveItem | 'dashboard' |
| 4272 | getItem | category (dynamic) |
| 3786 | getItem | 'apps' — getApp |
| 3864 | getItem | 'pages' — getPage |
The two plural sites resolve today only because the server normalizes: RestServer.metaTypeSingular (packages/rest/src/rest-server.ts:1500-1503) maps through PLURAL_TO_SINGULAR from @objectstack/spec/shared, pinned in packages/spec/src/shared/metadata-collection.test.ts:283 (expect(PLURAL_TO_SINGULAR['apps']).toBe('app')). So nothing a user hits is broken.
Why it is still worth a row
getApp (:3786, plural) and probeAppAccess (:3846, singular) address the same metadata type sixty lines apart, and probeAppAccess's own comment argues the singular spelling is deliberate ("the address objectstack#8013 pinned its cases against, and the same one MetadataProvider reads items by"). MetadataProvider does read the singular (TYPE_BY_STATE_KEY = { apps: 'app', … }, providers/MetadataProvider.tsx:72). One file, one type, two spellings, and the reasoning for one of them is written down while the other is silent — which is how #4887's six comments came to name a spelling nothing calls.
The drift is unexercised rather than latent-broken, but it is load-bearing on a server-side fold, so it is only as durable as that fold: the two sites are the ones that would fail if the normalization were ever narrowed, and nothing in this repo asserts either spelling for them (appAccessProbe.test.ts:94 pins the singular for probeAppAccess only).
Not proposing a direction here — canonicalizing to the singular is the obvious cheap move, but whether the adapter should also grow a pin (so a new call site cannot pick the plural) is a maintainer call about gate strength, same family as #4894 / #4902.
Observation-class, filed unassigned per Prime Directive #10. Tripped over while tracing the real app-list endpoint for #4887 (PR #4937); not fixed there — out of that card's scope, which was six comments only.
Measurement (worktree off objectui
origin/main@ 25c8007, frameworkorigin/main@ 49a49a739)packages/data-objectstack/src/index.tshas 14client.meta.*call sites. Twelve pass the metadata type in the singular, one passes a caller-suppliedcategoryvariable, and two pass a plural collection spelling:getItems'view'getItem'view'saveItem'view'getItems'mapping'getItem'app'—probeAppAccesssaveItem'dashboard'getItemcategory(dynamic)getItem'apps'—getAppgetItem'pages'—getPageThe two plural sites resolve today only because the server normalizes:
RestServer.metaTypeSingular(packages/rest/src/rest-server.ts:1500-1503) maps throughPLURAL_TO_SINGULARfrom@objectstack/spec/shared, pinned inpackages/spec/src/shared/metadata-collection.test.ts:283(expect(PLURAL_TO_SINGULAR['apps']).toBe('app')). So nothing a user hits is broken.Why it is still worth a row
getApp(:3786, plural) andprobeAppAccess(:3846, singular) address the same metadata type sixty lines apart, andprobeAppAccess's own comment argues the singular spelling is deliberate ("the address objectstack#8013 pinned its cases against, and the same oneMetadataProviderreads items by").MetadataProviderdoes read the singular (TYPE_BY_STATE_KEY = { apps: 'app', … },providers/MetadataProvider.tsx:72). One file, one type, two spellings, and the reasoning for one of them is written down while the other is silent — which is how #4887's six comments came to name a spelling nothing calls.The drift is unexercised rather than latent-broken, but it is load-bearing on a server-side fold, so it is only as durable as that fold: the two sites are the ones that would fail if the normalization were ever narrowed, and nothing in this repo asserts either spelling for them (
appAccessProbe.test.ts:94pins the singular forprobeAppAccessonly).Not proposing a direction here — canonicalizing to the singular is the obvious cheap move, but whether the adapter should also grow a pin (so a new call site cannot pick the plural) is a maintainer call about gate strength, same family as #4894 / #4902.