Filed by the PM session (session_01H9StxQgG2DPA26XzZZqnJB) on behalf of the #12196 (D4) dev, whose seat could not run the pre-file dedup (REST channel 403). Dedup performed before filing: open-issue searches for ViewItemNameSchema and for metadata-service view-name teaching both return zero. Unassigned — recording, not claiming; grading is triage's.
The observation (measured on the post-D3 ref by the D4 sweep)
content/docs/kernel/contracts/metadata-service.mdx:315 and :349 teach a flat view item name:
metadataService.get('view', 'account_list')
getEffective('view', 'account_list', ...)while packages/spec/src/ui/view.zod.ts's ViewItemNameSchema pins view item identity on QUALIFIED_ITEM_NAME_PATTERN, which requires at least one dot (<object>.<viewKey>, e.g. crm_lead.pipeline — the exemplar D1/PR #12244 single-sourced and D4/PR #12381 now teaches in client-sdk.mdx).
Not slash-bearing, so outside #12196's ruled scope — the D4 sweep deliberately left it and handed the evidence over rather than filing blind.
The question this card holds
Which grammar governs a stored view row's sys_metadata name?
- If
ViewItemNameSchema (dot-required) is the identity for every view item, the two doc lines teach a spelling the contract refuses, and the fix is a docs respelling to the qualified form.
- If a stored view row only has to satisfy the general
METADATA_ITEM_NAME_PATTERN (which accepts a flat name — D1's grammar allows dotless segments), the docs are legal and the tension is between the UI-layer identity schema and the storage-layer grammar — which may be intended (the dotted requirement binding only where a view is addressed as a view of an object), but then the boundary deserves a sentence somewhere a reader can find.
Whether this is a docs fix, a contract clarification, or intended layering is a triage/spec call — the measurement is only that the two surfaces currently disagree in what they teach.
Refs: #12196 / PR #12381 (the D4 sweep that surfaced it) · #12194 / PR #12244 (D1 — METADATA_ITEM_NAME_PATTERN, ViewItemNameSchema re-derivation) · #12176 (the program)
Filed by the PM session (
session_01H9StxQgG2DPA26XzZZqnJB) on behalf of the #12196 (D4) dev, whose seat could not run the pre-file dedup (REST channel 403). Dedup performed before filing: open-issue searches forViewItemNameSchemaand for metadata-service view-name teaching both return zero. Unassigned — recording, not claiming; grading is triage's.The observation (measured on the post-D3 ref by the D4 sweep)
content/docs/kernel/contracts/metadata-service.mdx:315and:349teach a flat view item name:while
packages/spec/src/ui/view.zod.ts'sViewItemNameSchemapins view item identity onQUALIFIED_ITEM_NAME_PATTERN, which requires at least one dot (<object>.<viewKey>, e.g.crm_lead.pipeline— the exemplar D1/PR #12244 single-sourced and D4/PR #12381 now teaches inclient-sdk.mdx).Not slash-bearing, so outside #12196's ruled scope — the D4 sweep deliberately left it and handed the evidence over rather than filing blind.
The question this card holds
Which grammar governs a stored view row's
sys_metadataname?ViewItemNameSchema(dot-required) is the identity for every view item, the two doc lines teach a spelling the contract refuses, and the fix is a docs respelling to the qualified form.METADATA_ITEM_NAME_PATTERN(which accepts a flat name — D1's grammar allows dotless segments), the docs are legal and the tension is between the UI-layer identity schema and the storage-layer grammar — which may be intended (the dotted requirement binding only where a view is addressed as a view of an object), but then the boundary deserves a sentence somewhere a reader can find.Whether this is a docs fix, a contract clarification, or intended layering is a triage/spec call — the measurement is only that the two surfaces currently disagree in what they teach.
Refs: #12196 / PR #12381 (the D4 sweep that surfaced it) · #12194 / PR #12244 (D1 —
METADATA_ITEM_NAME_PATTERN,ViewItemNameSchemare-derivation) · #12176 (the program)