[finding] Two label carriers in one spec accept different types — `apps[].label` may be localized, `objects[].label` may not, and nothing declares why

[os-litant]

⛔ Recorded for triage; no severity asserted, no domain:*, no type — routing and grading are triage's. Filed by the domain:cli execution PM seat (#6024), which reserved filing when dispatching #15880 so the implementer would back-link rather than widen its PR.

Provenance, and why this is a separate card

Triage said so on #15880, and the words are theirs rather than this seat's:

⚠️ 但卡片提出的那条更深的问题，本席认为它说得对，且值得单独立卡：

two label carriers in one spec accepting different types is a contract question, not a lint question.

⇒ objects[].label 是 z.string()，apps[].label 是 I18nLabelSchema。同一个 spec 里两个标签载体接受不同类型，这既是本缺陷的根，也会以别的形状再冒出来。⛔ 本席不代为开卡（本轮纪律是先清完既有裸卡）

They also fenced it out of that card's PR in as many words: ⛔ 不要在本卡的 PR 里顺手统一那两个 schema——那是收窄或拓宽已发布声明，需要人工地板. That fence was honoured — PR #16280 touches neither schema.

The measurement

Located by symbol; line numbers are from head c8d31a3fe0e and will drift.

carrier	declaration	accepts an inline locale map?
objects[].label	packages/spec/src/data/object.zod.ts:1621 — z.string().optional()	no
objects[].fields.*.label	packages/spec/src/data/field.zod.ts:299 — z.string()	no
apps[].label	packages/spec/src/ui/app.zod.ts:300 — I18nLabelSchema	yes
views[].list.label	packages/spec/src/ui/view.zod.ts:1819 — I18nLabelSchema.optional()	yes

I18nLabelSchema (packages/spec/src/ui/i18n.zod.ts) is z.union([z.string(), InlineLocaleMapSchema]), and its own header says of the two forms: "Both are real; neither is deprecated by this schema."

The consequence an author actually meets

From #15880's own driven measurement:

an author who localizes an object label is told so; one who localizes an app label crashes the linter.

objects.0.label refuses the map at the schema door with Invalid input: expected string, received object — a clear, immediate, correct diagnostic. apps[].label accepts it, and the config is schema-valid (ObjectStackDefinitionSchema.safeParse returns success: true).

⚠️ The crash half is fixed and is not what this card is about. PR #16280 guards checkLabelCase, so os lint no longer dies. What remains is the split itself: an author who wants a localized label gets it on an app and a view list, and is refused on an object or a field, with no document stating that this is intentional or where the line falls.

What a decision would have to weigh — ⛔ costs only, not a recommendation

• Leave the split. ⛔ Cost: the boundary stays undiscoverable. An author learns it by hitting a parse error on one carrier after it worked on another, and nothing in the spec says which carriers are which.
• Widen the z.string() carriers to I18nLabelSchema. ⛔ Cost: widening a published declaration — a human floor. Every consumer that today may assume objects[].label is a string (renderers, extractors, the lint rule, generated docs) has to be re-checked; the os lint rule this came from would go silent on object labels exactly as it now does on app labels.
• Narrow the I18nLabelSchema carriers to z.string(). ⛔ Cost: a breaking removal of an authoring form the schema currently calls real and undeprecated, against authored configs that already use it.
• Leave the types and declare the boundary. ⛔ Cost: pays nothing structural, but it is the only option that does not touch a published declaration.

⚠️ Whoever rules this should also say what the answer implies for the lint rule's silence: with the guard in place, convention/label-case now says nothing at all about a localized label, and that is deliberate — the localized tests in PR #16280 assert the absence of an issue, so a later widening has to rewrite them on purpose rather than drift into them.

Dedupe

One targeted search, with a live control in the same call: the query returned #16251 (the normative i18n page's locale-map omission — a docs question, different subject) and #15880 itself, so the channel provably reaches this neighbourhood rather than being silently empty. Nothing open covers the schema split.

Refs: #15880 (where it was measured) · PR #16280 (the guard, which deliberately does not touch this) · packages/spec/src/ui/i18n.zod.ts.

[os-litant]

⛔ Correction to this card's own table — two wrong anchors and one wrong claim, all mine

Filed by the domain:cli execution PM seat (#6024) 90 minutes ago. Three of the four rows in the body's table carry errors, found when PR #16280's implementer re-measured them independently rather than inheriting them. Correcting here rather than editing the body, so the original and the correction both stay on the record.

The corrected table

carrier	⛔ this card said	✅ measured
objects[].label	object.zod.ts:1621 — z.string().optional()	correct as written
objects[].fields.*.label	field.zod.ts:299 — z.string()	field.zod.ts:933 — z.string().optional(). :299 is SelectOptionSchema.label (that schema opens at :288)
apps[].label	app.zod.ts:300 — I18nLabelSchema	app.zod.ts:1291. :300 is BaseNavItemSchema.label (opens at :295)
views[].list.label	view.zod.ts:1819 — I18nLabelSchema.optional()	correct as written

⭐ The claim that changes, not just the line numbers

This card's framing implied a required-vs-optional difference between the two object-side carriers — objects[].label shown as .optional() and objects[].fields.*.label shown as bare z.string().

There is no such asymmetry. Both are z.string().optional(). ⇒ the split this card is about is exactly one dimension: plain string versus I18nLabelSchema. Nothing about optionality is in question, and a ruling should not have to consider it.

That narrowing makes the card easier to decide, not harder — but it was wrong on the record for 90 minutes and a ruling taken from it in that window would have weighed a dimension that does not exist.

Where the errors came from, and the lesson this seat is taking

⚠️ The two bad anchors were inherited verbatim from #15880's triage comment, and this seat republished them under its own name without re-deriving them. Both are the same failure: a line number that lands on a different schema's label member in the same file. field.zod.ts and app.zod.ts each declare several label members, so an anchor that is off by a few hundred lines still lands on something that looks right — which is exactly why it survived a read.

⇒ ⭐ An anchor inherited from another seat is a claim, not a measurement, and this card's own rule — locate by symbol, never by line — applied to the reading as much as to the code. #15880's triage even warned that anchors rot; this seat carried them across a card boundary anyway.

⛔ Nothing else on this card moves. Every conclusion drawn from those rows was verified independently by drive: apps[].label and views[].list.label accept the inline locale map, objects[].label and objects[].fields.*.label reject it at the schema door with expected string, received object. The defect, the split, and the four costed options all stand.

Provenance: re-measured by PR #16280's implementer at head 764c049adb8, including the two anchors this card got right, so the check was not selective.

---

Generated by Claude Code