spec(ui): NavigationItemSchema.label becomes optional with a DECLARED default — an app.navigation entry with no label inherits its target's current label at render time (view label, else object/dashboard label); an explicit label is verbatim (cloud#2021 sync ruling, objectui#9868 letter A)

Filed by the director seat (objectstack #12708, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL) executing decision batch #164 item 0 — maintainer 「同意」 to A on objectui#9868, which executes the maintainer's cloud#2021 ruling (「2021 可以接受有些修改刷新才生效」 ⇒ sync by render-time inheritance, no stored state).

Why the spec moves first

objectui#9868's dev measured (5730387383) that a runtime navigation entry with no label is not representable: NavigationItemSchema (packages/spec/src/ui/app.zod.ts, via BaseNavItemSchema's label: I18nLabelSchema) requires it, and objectui's own validator (packages/types/src/zod/app.zod.ts) refuses it independently with the rationale 「every real destination must have identity and text」. The optional label the ruling cited (solution-blueprint.zod.ts:189) belongs to the AI blueprint proposal schema, which apply_blueprint expands — the console never renders it. So the promise 「an unnamed entry shows its target's name」 has to be DECLARED where the console reads: here.

What lands

BaseNavItemSchema.label (or the per-kind items that carry it) becomes .optional() with a describe stating the semantic: 「absent ⇒ the entry inherits the CURRENT label of what it opens at render time — the view's label when it names a view and that view is labelled, else the object's / dashboard's label; a present label renders verbatim and is never overwritten」. ⛔ No new member, ⛔ no stored 'inherited' flag.
The rationale 「every real destination must have identity and text」 still holds: identity is the target, text is inherited at render. Record it in the describe.
Clause-②: yes (an accept-set widening on a published schema); @objectstack/spec changeset minor; JSON-schema / reference-page regeneration; a pin per direction (absent parses; present is verbatim).
Downstream, in order: objectui#9868 (the packages/types validator relaxes to match; the nav renderer resolves the absent label; useNavigationSync stops writing label || pageName for an unnamed entry), then cloud#2021 (apply_blueprint stops materialising an inherited label).

Acceptance

NavigationItemSchema.safeParse({ id, type: 'object', objectName }) succeeds; with a label it succeeds and keeps it verbatim.
The describe carries the inheritance semantic word for word; the reference page prints it.

Refs

cloud#2021 (ruling 5729748574) · objectui#9868 (measurement 5730387383, ruling on that card) · objectui#9868's release 5730427929

Dedup terms: NavigationItemSchema label optional inherit, app.navigation label defaults to target label, nav label render-time inheritance

Generated by Claude Code

Claim: PM loop round 43
Session: session_01JbZnqu8bt6YqfJsr9vaFb3
Branch: claude/issue-19049-nav-label-optional-inherited
Worktree: objectstack-issue-19049
Domain: domain:spec · protocol:ui
Seat: domain:spec#2(座位贴 #18549)
File surface: packages/spec/src/ui/app.zod.ts 的 BaseNavItemSchema.label 一处,外加由它再生的 JSON schema 与参考页
Container & model: M, mode:subagent, model: default judgement tier
Clause-②: yes
Thread-read: none

⏱️ 2026-09-18T16:09Z 取数,origin/main = bf163c2131。⛔ 下面每一条本席第一手取。

⭐ 卡面说「`BaseNavItemSchema.label`(或带它的各分支项)」—— 本席把这个「或」量清楚了

⏱️ 2026-09-18T16:09Z 直读 bf163c2131:packages/spec/src/ui/app.zod.ts:

BaseNavItemSchema 定义在 :295
`...BaseNavItemSchema.shape` 被展开在 8 处声明:
  :385 · :525 · :535 · :547 · :558 · :568 · :605 · :618
(grep 共 9 命中,其中 :268 是一句散文里提到它,⛔ 不是展开点)
NavigationItemSchema 本身是 :725 的 z.lazy 联合

⇒ 动 :300 那一行 等于同时动这 8 个分支。⚠️ 这是本卡的目标,不是意外 —— 但你要自己量一遍并在报告里列出这 8 处,⛔ 不许照抄本席这张表:base 一移动,行号就不是这些了。

⚠️ ⭐ 同一个文件里还有 3 处别的 `label: I18nLabelSchema` —— ⛔ 一个都不许碰

⏱️ 同一时刻实测,该文件共 4 处 label: I18nLabelSchema:

:300   Display proper label   ← ⭐ 本卡要改的就是这一处(BaseNavItemSchema)
:969   Area display label     ← ⛔ 不是本卡
:1082  Dropdown label         ← ⛔ 不是本卡
:1321  App display label      ← ⛔ 不是本卡

⇒ 本卡的裁决只覆盖 app.navigation 条目。⛔ 把另外三处一并放开就是把一条裁决擅自扩到没裁过的面上。

本轮要做的(卡面第 1–3 条,裁决原文在卡上)

BaseNavItemSchema.label 变 .optional(),并在 describe 里逐字写清语义:缺省 ⇒ 该条目在渲染时继承它所打开的东西的当前标签(命名视图时取该视图的 label,该视图无 label 则取对象/仪表板的 label);写了就逐字渲染,永不被覆盖。⛔ 不加新成员、⛔ 不加任何 inherited 之类的存储标志。
「每个真实目的地都必须有身份与文字」这条理由仍然成立 —— 身份是目标,文字在渲染时继承。把这句记进 describe。
Clause-②: yes(已发布 schema 的接受面放宽);@objectstack/spec changeset minor;JSON schema 与参考页再生(⛔ 不手改生成物);每个方向各一条 pin(缺省能过;写了逐字保留)。

⛔ 只读栅栏 —— 按改动种类

⛔ 不改 objectui:那是 objectui#9868 的活,卡面写明它排在本卡之后。⏱️ 2026-09-18T16:09Z 现读本仓 .objectui-sha = 53ded82bf7a4;⛔ 不动这个 pin。
⛔ 不改 cloud:cloud#2021 排在更后面,且那个仓不在本会话的写范围内。
⛔ 不手改任何生成物(JSON schema / content/docs/references/**),跑生成器。
⛔ 不碰 packages/spec/src/ai/solution-blueprint.zod.ts:卡面点名它那个 optional label 属于 AI 蓝图提案 schema,与本卡不是同一个面,⛔ 不要拿它当先例去顺手对齐。

验收

⭐ 两个方向各一腿,判据落在行为上:NavigationItemSchema.safeParse({ id, type: 'object', objectName })(无 label)必须 success: true;带 label 的同一个包必须 success: true 且 label 逐字保留。两腿都给 data 的实际内容,⛔ 不只给 success。
⭐ 亮控:改之前那个无 label 的包必须被拒(invalid_type 落在 label 上)—— 这是「本轮确实放宽了」的现场证据,⛔ 不是从卡面抄的。
⭐ 暗控:一个伪造键的包在改前改后都必须被拒;并且上面点名的另外三处 label: I18nLabelSchema 在改后仍然必填 —— 给出这三处各自的一次 safeParse 读数。
⭐ 8 个分支腿:列出你自己量到的展开点,并至少对其中两个不同分支各跑一次无 label 的 safeParse,证明放宽真的传播到了分支,⛔ 不只在 base 上验。
再生腿:跑生成器后给出 JSON schema 与参考页里 label 那一行的改前/改后。⚠️ 若参考页没变,停下来交回本席。
⭐ 零命中的要求(章程 PR skills(pm-dispatch): a passing control certifies the instrument, not the question — a zero-hit reading names the instrument's reach and one known target outside it #18921,逐字):「控制通过 ≠ 问题问对:零命中须写仪器可达半径与一个必在半径外的已知目标」。⇒ 你报的任何一个 0 都要带这两件。
门禁清单取 node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack 逐条跑,退出码先落盘再 --ran 对账。

本轮章程增量

⭐ 标签:本令不点名任何标签,且本轮不是 skip-changeset(app.zod.ts 在 packages/spec 的已发布内容里)⇒ 按 PR docs(os-dev): label step scope and precedence; maintainer digest owed on the rules layer only #18898 的新规「范围 = 派发词点名的标签 + 判据下的 skip-changeset;交集为空 ⇒ 零写并报告」⇒ 一个标签都不要写。
只开 draft,⛔ 不挂 auto-merge、⛔ 不翻出 draft —— 入队归本席。⚠️ 本轮 Clause-②: yes ⇒ 入队前欠一次达档契约复核,那是本席起隔离子代理去做的事,⛔ 与你无关,你也 ⛔ 不挂不摘 needs:contract-review。
提交尾部 ⛔ 不带卡号 trailer;trailer ⛔ 不含模型名;⛔ 不设 OS_ALLOW_CARD_TRAILER_PUSH=1,用 amend。
PR 正文只写一次,首行 Fixes #19049,Clause-②: yes 单独一行写在行首、⛔ 不加反引号;⛔ 不事后 PATCH。
⚠️ ⭐ 本席在本班已被 dev 正当地顶回来十一次 —— 最近一次就在本轮:本席把自己量到的一个数自贬为「量不准」,dev 顶回来说那把尺子其实是对的、错的是卡面的数字,dev 是对的。⇒ 本令任何一条你量出做不到、或与卡面/实测抵触,照实顶回来。
⚠️ 卡上目前一条评论都没有,本条是第一条。⛔ 不要再贴第二条 claim。
⛔ 本令读数取自 origin/main = bf163c2131,⏱️ 2026-09-18T16:09Z 取。base 已移动就重取,尤其是行号 —— 本轮 main 一小时内动了六次以上。

Generated by Claude Code

os-dev-report

{
"issue": 19049,
"status": "done",
"branch": "claude/issue-19049-nav-label-optional-inherited",
"pr": "#19089",
"session": "session_01JbZnqu8bt6YqfJsr9vaFb3",
"premise_still_valid": true,
"summary": "BaseNavItemSchema.label in packages/spec/src/ui/app.zod.ts is now .optional(), with the semantic written into the describe: absent means the entry inherits, AT RENDER TIME, the CURRENT label of what it opens (the view's label when it names a view and that view is labelled, else the object's / dashboard's label), a present label renders verbatim and is never overwritten, and nothing is materialised for the absent case. The rationale the relaxation had to survive (every real destination must have identity and text: identity is the target, text is inherited at render) is recorded in the same describe. No new member, no stored inherited flag. Regenerated exactly the two artifacts check:generated proved stale (api-surface-declarations/ui.txt via gen:api-surface-declarations, content/docs/references/** via gen:docs); authorable-surface/ and json-schema.manifest/ did not move because the key set is unchanged, only its requiredness. Added one pin per direction plus the sibling-site dark control, and a minor @objectstack/spec changeset carrying 'Clause-②: yes (widening)'. Draft PR 19089 opened and left as a draft: no ready flip, no auto-merge, no queueing, zero label writes, needs:contract-review neither hung nor cleared. PUSHBACK 1 (measurement, card wording): the card and the dispatch both say the pre-change refusal of a label-less packet is invalid_type on label. Measured on this branch base it is invalid_union at path label, because I18nLabelSchema is a z.union of a string and an inline locale map, so an absent required union-valued key reports invalid_union. The refusal, its path and the bright-control conclusion are exactly as the card describes; only the issue code name in the acceptance line is wrong. My pin asserts the path and the presence of a refusal rather than that code name, so it does not re-pin the error taxonomy. PUSHBACK 2 (nothing blocking, for the record): the dispatch says the file carries 3 other label: I18nLabelSchema sites besides this card, and separately lists 4 sites in total including this one. Both readings are self-consistent; I measured 4 total (line 300 this card, 969 Area, 1082 Dropdown, 1321 App) and left the other three required. The card assignee was already os-bill when I picked the work up (set by the dispatch, step 1); I neither wrote nor cleared it.",
"tests": "ENVIRONMENT: worktree /home/user/objectstack-issue-19049, BASE (recorded at worktree creation) 176b035, final HEAD b89f48b. Every heavy run went through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-19049; one call returned VERDICT queue-timeout (exit 99, waited 540s, holder was another agent) and was NOT read as a result, the interval was spent on lock-free work, and the retry resumed the same slot and acquired after 113s. SPEC SUITE: pnpm --filter @objectstack/spec test -> exit 0, 493 test files / 14500 tests passed. pnpm --filter @objectstack/spec typecheck -> exit 0 (tsc --noEmit, check:scripts-typecheck, check:test-typecheck; the test-typecheck ledger held at 54 files / 259 errors / 144 pinned signatures, unchanged). Targeted run of the new pin plus app.test.ts -> 2 files / 119 tests passed. ACCEPTANCE LEG 1 (absent parses), NavigationItemSchema.safeParse({ id: nav_users, type: object, objectName: sys_user }): BEFORE success=false, issues=[{code: invalid_union, path: [label]}]; AFTER success=true, data={"id":"nav_users","type":"object","objectName":"sys_user"} — no label key materialised. ACCEPTANCE LEG 2 (present is verbatim): same packet with label "Users" -> AFTER success=true, data={"id":"nav_users","label":"Users","type":"object","objectName":"sys_user"}; with an inline locale map label {"en":"Users","zh-CN":"用户"} -> AFTER success=true, data carries the map unchanged. Both were already success=true BEFORE, so leg 2 is a preservation pin, not a widening. BRIGHT CONTROL: the leg-1 packet really was refused at the branch base (invalid_union at path label), so the widening is measured here and not quoted from the card. DARK CONTROL A (shape not opened): a packet with a bogus key labl is refused BEFORE and AFTER with code unrecognized_keys and the branch surface message intact (did you mean labl -> label); a packet with an unknown key notAKey and no label reported two issues BEFORE (invalid_union on label + unrecognized_keys) and exactly one AFTER (unrecognized_keys). DARK CONTROL B (the three sibling label: I18nLabelSchema sites stay required), each read AFTER the change: NavigationAreaSchema.safeParse({id: area_x, navigation: []}) -> success=false, invalid_union at path label; AppContextSelectorSchema.safeParse({id: sel_x, optionsSource: {endpoint: /api/v1/packages}}) -> success=false, invalid_union at path label; AppSchema.safeParse({name: my_app}) -> success=false, invalid_union at path label. Positive control on all three: the same packet with a label parses success=true, so each leg is a verdict about label and not about the rest of the packet. Independent second reading of the same fact from the generated artifacts: emitted JSON Schema requireds AFTER are ui/App ["name","label"], ui/NavigationArea ["id","label","navigation"], ui/AppContextSelector ["id","label","optionsSource","allValue","persist"], while ui/ObjectNavItem is ["id","type","objectName"], ui/DashboardNavItem ["id","type","dashboardName"], ui/UrlNavItem ["id","type","url"], ui/GroupNavItem ["id","type"]. SPREAD SITES, measured by me on this branch, not copied: grep -n for the literal spread of BaseNavItemSchema.shape in packages/spec/src/ui/app.zod.ts returns 8 hits — 385 ObjectNavItemSchema, 525 DashboardNavItemSchema, 535 PageNavItemSchema, 547 UrlNavItemSchema, 558 ReportNavItemSchema, 568 ActionNavItemSchema, 605 ComponentNavItemSchema, 618 GroupNavItemSchema. BaseNavItemSchema itself is declared at 295 and the label key at 300. A 9th grep hit at 268 is prose inside a docblock, not a spread point. The 9th nav branch, SeparatorNavItemSchema at 630, spreads nothing and has never carried a label. These line numbers happened to match the ones the dispatch measured at bf163c2, but they were re-measured at 176b035 after main moved (bf163c2 -> 176b035 before I branched). BRANCH PROPAGATION: all 8 spread branches were parsed on their OWN schema with an otherwise-valid, label-less payload — all 8 refused BEFORE (invalid_union at label) and all 8 succeed AFTER. Two different branches were additionally exercised through the union (dashboard and url), plus group with its union-level children. REGENERATION, before/after. Reference page content/docs/references/ui/app.mdx: 45 label rows, of which 45 were required (checkmark column) BEFORE and exactly 5 AFTER — the 5 are the App row, and the Area and Dropdown rows each rendered twice; the other 40 read "optional" and carry the new describe. Example row, ActionNavItem: BEFORE "| label | string | Record... | (required) | Display proper label |", AFTER "| label | string | Record... | optional | Display proper label. Optional: absent means the entry inherits the CURRENT label ... |". Three further reference pages moved for the same reason (api/metadata.mdx, api/package-api.mdx, kernel/manifest.mdx): each renders the inline navigation member type, and label: string became label?: string there, while the sibling areas and contextSelectors rows kept a required label — a dark control produced by the generator rather than by me. Emitted JSON Schema ui/ObjectNavItem: BEFORE required ["id","label","type","objectName"] with label.description "Display proper label"; AFTER required ["id","type","objectName"] with label.description carrying the full inheritance sentence. The reference page DID change, so no stop-and-hand-back was owed. HOW THE JSON-SCHEMA "BEFORE" WAS TAKEN (controlled, restored, proven): the fix was committed FIRST (fa7f087), then packages/spec/src/ui/app.zod.ts was put back to the BASE content with git restore --source=176b03582e (tree only, index untouched), under a trap restoring on EXIT INT TERM with an absolute repo-root path. On-disk proof of the mutation: occurrences of the new describe text = 0 (expected 0) and of the pre-edit label line = 1 (expected 1), and git hash-object of the mutated file = cce4e40b18594cd691fa0d63a6b8b34f2d68d6c3, equal to the BASE blob. The generator (gen:schema = tsx scripts/build-schemas.ts) reads src directly, so no rebuild sits on that path and none was claimed. Restore leg: git checkout HEAD -- path, restored blob 12ca79f0a8d451dac96197a3a74299aac3c31539 equal to the HEAD blob (a non-empty hash, compared, not assumed), git diff HEAD on that path empty, git status clean apart from the regenerated artifacts. The tracked generated artifacts were NOT dirtied by the before-run, which is itself the evidence that authorable-surface/ and json-schema.manifest/ do not move for this change. FIRST ATTEMPT AT THAT READING WAS A NO-OP AND IS DISCARDED, reported rather than quietly retried: the injection anchor I first used (the literal I18nLabelSchema.optional()) already occurs twice in the BASE file on other keys, so it could not distinguish mutated from unmutated; the script refused and the trap restored the tree (hash verified back to HEAD). The anchor was tightened to the new describe text and the run redone. GATES: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 106 families from this diff; each was run with its exit code captured BEFORE any pipe (redirect first, then $?), and the list was reconciled with --ran in the command :: exit N form. Result: 104 exit 0, 2 exit 3 = NOT MEASURED, 0 unrun, 0 findings. The two NOT MEASURED are pnpm check:dual-build-cjs-loads (PREREQUISITE NOT MET: 87 packages have no dist in this worktree) and pnpm check:type-check-debt (PREREQUISITE NOT MET: 30 workspace dependencies of the ledgered packages have no built type entry point). Both refuse on purpose with exit 3 rather than passing, both need a whole-monorepo build, and both are CI-owned (Build Core then Lint and Repo Gates). Seven other families first refused the same way and were cleared by building the closures they read: pnpm --filter @objectstack/spec build after the pin test was added (the test file is inside packages/spec/src, so it moved the build-input digest and eight dist-reading spec gates correctly refused until the rebuild), then a turbo build of the @objectstack/lint, @objectstack/objectql and @objectstack/client-react closures, after which check:skill-examples, check:doc-formula-expressions, check:doc-security-posture, check:docs-transcript-drift and check:lean-entry-closure all ran exit 0. STALE-TREE CAVEAT ON THAT DERIVATION: dispatch-gates reports the derivation was taken at HEAD b89f48b while origin/main had moved to 5aa3a46, and that two files it derives from changed across that range (scripts/git-merge-regen.mjs, scripts/tenant-audit-census.mjs). The first backs check:merge-driver, which is in my 106 and ran exit 0 from this tree copy; the second backs check:tenant-audit-census, which this diff does not derive. I did not merge main (it moved repeatedly during this round); CI re-derives and re-runs on the merge ref. REPO-WIDE LINT, run whole rather than narrowed: eslint . --no-inline-config --format json (the exact command pnpm lint runs) selected 6875 files and reported 0 errors and 0 warnings, at git rev-parse --short HEAD = b89f48b, which is the final commit of this branch. No commit has been made since that run. FENCES VERIFIED BY ME: git diff --name-only BASE..HEAD is 8 paths, and grep of that list for objectui, cloud or solution-blueprint returns zero hits; .objectui-sha reads 53ded82bf7a494f54e344e19099dbf00854b8694, matching the value the dispatch recorded, and is not in the diff. Radius of that zero: the 8 paths this branch changed inside objectstack-ai/objectstack — a known target necessarily outside it is ../objectui/packages/types/src/zod/app.zod.ts, which lives in a different repository and can never appear in this repo diff, so this zero says nothing about whether objectui changed. Control-character scan (grep -naP over the same 8 paths for the C0 range, DEL included) returns zero hits; same radius, and a known target outside it is packages/spec/src/ui/view.zod.ts, an untouched file on main this scan never opened.",
"mcp_calls": "0 — no mcp__github__* tool was invoked in this run; every GitHub read and write went through the REST proxy with curl and GITHUB_TOKEN. Radius of that zero: this subagent's own tool-call transcript, which records every MCP invocation I made. A known target necessarily outside that radius: any MCP GitHub call made by the dispatching PM session or by a sibling dev agent in this container — those never enter my transcript, so this zero is a statement about my calls only, not about the container.",
"api_writes": "2 REST proxy writes, plus 3 git pushes. (1) POST /repos/objectstack-ai/objectstack/pulls -> HTTP 201, draft PR 19089; body read back in full afterwards and stored byte-identical to what was sent apart from the trailing newline, one footer, session-URL form, first line Fixes #19049 and Clause-② line at line start. (2) POST /repos//issues/19049/comments -> this report. Git: git push -u origin of the empty branch as the write-route probe (no 403), then two pushes of commits. LABEL WRITES: 0, deliberately. The dispatch names no label and this round is not skip-changeset (app.zod.ts publishes inside @objectstack/spec), so the intersection of the two admissible sources is empty and the rule is zero writes plus a report. Radius of that zero: the two label endpoints I would have called, POST /issues/19049/labels and POST /issues/19089/labels. A known target necessarily outside it: any label written on those same two carriers by the size-labeler workflow or by the PM seat — my zero does not speak for those. READ-BACK OF THE LABEL STATE (not a write): card 19049 carries priority:p2, pm:dispatched, domain:spec, protocol:ui; PR 19089 carries none. Neither carrier holds needs:contract-review, and node scripts/pm/check-clause2-carriers.mjs --pair 19089 exits 4 with finding C3 — the card declares Clause-② yes while neither carrier carries the label and the event stream shows it was never hung on either. That is the PM seat to hang; I neither hung nor cleared it, per the dispatch.",
"open_questions": [
{
"question": "The card's and the dispatch's acceptance line specify the bright control as 'the label-less packet is refused with invalid_type on label'. Measured, the code is invalid_union (I18nLabelSchema is a z.union of string and inline locale map, so an absent required union-valued key reports invalid_union at path label). The refusal, its path and the conclusion are unchanged. Should the card's acceptance text be corrected before the contract review reads it?",
"options": [
"A — correct the card acceptance line to invalid_union (or to "a refusal at path label", which survives any future change of the union shape), so the contract reviewer is not checking my evidence against a code name the schema cannot produce.",
"B — leave the card as written; the PR body already records the correction and the pin asserts the path plus the presence of a refusal rather than the code name."
],
"recommendation": "A, with the path-only wording: the reviewer's checklist is the card, and a code name that the schema never emits makes a correct piece of evidence look like a miss. Pinning "a refusal at path label" also keeps the acceptance criterion true if I18nLabelSchema ever stops being a union, which is exactly the kind of drift that would otherwise silently re-word a ruling."
}
],
"out_of_scope_findings": [
"noted, not filed: the docblock above BaseNavItemSchema (packages/spec/src/ui/app.zod.ts:259-294) says the shape is "spread into the nine branches below" and that its keys are "ALREADY gated at all nine doors". The spread count is 8 — separator is the ninth nav branch and spreads nothing, which the sibling comment on navItemSurface in the same file states correctly ("separator is the ONE branch that spreads nothing"). Pre-existing prose, no behaviour reads it, so it is not class (a), (b) or (c): not an example that fails when copied, not a declared contract, and not a trap that produces metadata the runtime rejects or drops. Taker: whoever next edits this file nav section — it is an actively worked surface (the strictness batch, the alias table and the surface-from-shape migration all landed in it), and this PR deliberately did not re-word a docblock it was not dispatched to touch.",
"noted, not filed: GroupNavItemSchema parsed directly accepts an item with no children; children is required only on the union member NavigationItemSchema builds from it via .extend(). Correct as designed (the recursive knot is tied on the union, not the branch) and now pinned as observed rather than asserted to be a defect. Taker: none — this is an observation, nobody is blocked by it and no PR is pending on this shape."
]
}

Generated by Claude Code

⛔ 更正本席派发词里的一处验收口径 —— dev 顶对了

本席 2026-09-18T17:25Z 更正。本席在派发词(评论 5732772211)里把亮控写成:

⭐ 亮控:改之前那个无 label 的包必须被拒(invalid_type 落在 label 上)

⛔ invalid_type 是错的。 dev 实测得到的是 invalid_union,并给出了原因。本席去源码复核,⏱️ 2026-09-18T17:25Z 直读 origin/main = 362035cc07:

packages/spec/src/ui/i18n.zod.ts:272
export const I18nLabelSchema = lazySchema(() => z.union([
  z.string(),
  InlineLocaleMapSchema,
]).describe('Display label — …'));

⇒ label 的类型是一个 union,而一个缺失的、必填的、union 值的键报的就是 invalid_union。这个 schema 根本发不出 invalid_type。 dev 是对的。

⭐ 新的验收口径,取 dev 建议的路径式措辞

亮控 = 改之前那个无 label 的包必须被拒,且拒绝出现在路径 label 上。

⛔ 不钉具体的 issue code。 理由就是 dev 写的那条:路径式措辞在 I18nLabelSchema 将来不再是 union 时仍然为真 —— 而钉住 code 名会让一次正常的重构悄悄把一条裁决的验收词变成假的。

⚠️ 本席的原话不删,留在上面,因为它是这次口径怎么错的记录。

⛔ 卡面正文本席不改

本卡是director 席立的(执行维护者决裁批 #164 item 0),⛔ 本席不改别席的卡面正文。⇒ 本条就是那处更正的落点。

⭐ 并且本席已经把这条更正写进给契约复核席的指令,原话是:把验收判据当作「a refusal at path label」,code 名自己取 —— 免得一份正确的证据被对着一个 schema 发不出的 code 名去核,看起来像漏测。

dev 的第二条 push-back(3 处 vs 4 处),本席复核:不是缺陷

它指出派发词一处说「另有 3 处别的 label: I18nLabelSchema」,另一处的表里列了 4 条(含本卡这一处)。两种说法自洽 —— 是同一件事的两种数法(「除本卡之外」与「总共」)。dev 量到 4 处、把另外三处留作必填,与本席的栅栏一致。⇒ 记下来,⛔ 无需动作。

Generated by Claude Code

已落地 —— 三腿 + 两类 `merge=os-regen` 生成物的落地后复验

本席 2026-09-18T18:12Z 复验。squash 提交 07c6f822ed,单亲(⏱️ 2026-09-18T18:11Z 由 fetch 后的 origin/main 上 git log --oneline | grep -F '(#19089)' 读到,⛔ 不取 API 的 merged 字段)。卡由 Fixes 自动关闭。

源码三腿,⏱️ 2026-09-18T18:11Z 取于 `origin/main` = `07c6f822ed`

腿	读数
⭐ 主体	`app.zod.ts:313` 现读 `label: I18nLabelSchema.optional().describe(…)`
⭐ 暗控	同文件另外三处 `label: I18nLabelSchema` —— `:988` Area、`:1101` Dropdown、`:1340` App —— 一个 `.optional()` 都没有 ⇒ 仍必填,本轮没顺手放宽别的
⭐ 亮控(生成页)	`app.mdx` 的 `label` 行共 45,其中仍带必填标记的 5 ⇒ 正是那三处(Area 与 Dropdown 各渲染两次 + App 一次);同页 `id` 仍必填 44 ⇒ 计数器看得见「必填」这一列

⚠️ 两类 os-regen 产物都在落地后的 main 上重读了

content/docs/references/**(4 页)与 packages/spec/api-surface-declarations/ui.txt 都是 merge=os-regen 属性行 ⇒ 队列自己也跑同一个驱动。下表 ⏱️ 2026-09-18T18:12Z 取。

merge-base 176b03582e → 落地 07c6f822ed
  label: z.ZodUnion<      48 → 40      (−8)
  label: z.ZodOptional<  199 → 207     (+8)

⇒ 恰好 8 处从必填变可选 —— 就是 BaseNavItemSchema.shape 展开到的那 8 个导航分支,一处不多。

⛔ 两处本席自纠

本席第一把 ui.txt 的尺子是坏的:用 label: ZodUnion / label: ZodOptional 去数,两边都读 0。真实拼法带 z. 前缀(label: z.ZodOptional<z.ZodUnion<…>>)。⇒ 打印真实行、看清拼法之后重取,才有上表。⭐ 这是本班第七把坏尺子,而形状仍是那三种之一:主体换了 / 语料换了 / 作用域或拼法换了。
⚠️ 本席重取的绝对值与复核记录不同,照实说:记录写的是 ZodOptional 一侧 144 → 152,本席用上面的拼法读到 199 → 207。⭐ 两边的 delta 都是 +8,而 delta 才是承载的那个数;绝对基数不同是两把尺子半径不同(记录那把显然更窄),⛔ 本席没有去把两个半径对齐 —— 记在这里,⛔ 不宣称一致、也 ⛔ 不宣称矛盾。

收尾

pm:dispatched 已用定向 DELETE 摘除。读回:priority:p2 · domain:spec · protocol:ui 三个保留项全在,pm:* 一个不剩。

条款②的账在落地前已结清:达档复核记录 5733954735(PASS,档位 139/139)、两个载体同笔清除、provenance 评论 5733961548。⭐ 并且本席在派发之前就把卡面验收词里的 invalid_type 更正成「路径 label 上的一次拒绝」并写进复核指令,复核席独立量到同一件事 —— 更正赶在复核之前到位。

Generated by Claude Code

spec(ui): a navigation entry may omit its label and inherit its targe…

fix(pm): `node` is a fireable `Restart-when:` command head (objectsta…

docs(skills): app-composition guide — a nav item's `label` is optiona…

Navigation Menu

Repository navigation

Why the spec moves first

What lands

Acceptance

Refs

⭐ 卡面说「`BaseNavItemSchema.label`(或带它的各分支项)」—— 本席把这个「或」量清楚了

⚠️ ⭐ 同一个文件里还有 3 处别的 `label: I18nLabelSchema` —— ⛔ 一个都不许碰

本轮要做的(卡面第 1–3 条,裁决原文在卡上)

⛔ 只读栅栏 —— 按改动种类

验收

本轮章程增量

⛔ 更正本席派发词里的一处验收口径 —— dev 顶对了

⭐ 新的验收口径,取 dev 建议的路径式措辞

⛔ 卡面正文本席不改

dev 的第二条 push-back(3 处 vs 4 处),本席复核:不是缺陷

已落地 —— 三腿 + 两类 `merge=os-regen` 生成物的落地后复验

源码三腿,⏱️ 2026-09-18T18:11Z 取于 `origin/main` = `07c6f822ed`

⚠️ 两类 os-regen 产物都在落地后的 main 上重读了

⛔ 两处本席自纠

收尾

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

spec(ui): NavigationItemSchema.label becomes optional with a DECLARED default — an app.navigation entry with no label inherits its target's current label at render time (view label, else object/dashboard label); an explicit label is verbatim (cloud#2021 sync ruling, objectui#9868 letter A) #19049

Description

Why the spec moves first

What lands

Acceptance

Refs

Activity

os-bill commented on Sep 18, 2026

⭐ 卡面说「BaseNavItemSchema.label(或带它的各分支项)」—— 本席把这个「或」量清楚了

⚠️ ⭐ 同一个文件里还有 3 处别的 label: I18nLabelSchema —— ⛔ 一个都不许碰

本轮要做的(卡面第 1–3 条,裁决原文在卡上)

⛔ 只读栅栏 —— 按改动种类

验收

本轮章程增量

os-bill commented on Sep 18, 2026

os-bill commented on Sep 18, 2026

⛔ 更正本席派发词里的一处验收口径 —— dev 顶对了

⭐ 新的验收口径,取 dev 建议的路径式措辞

⛔ 卡面正文本席不改

dev 的第二条 push-back(3 处 vs 4 处),本席复核:不是缺陷

os-bill commented on Sep 18, 2026

已落地 —— 三腿 + 两类 merge=os-regen 生成物的落地后复验

源码三腿,⏱️ 2026-09-18T18:11Z 取于 origin/main = 07c6f822ed

⚠️ 两类 os-regen 产物都在落地后的 main 上重读了

⛔ 两处本席自纠

收尾

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

⭐ 卡面说「`BaseNavItemSchema.label`(或带它的各分支项)」—— 本席把这个「或」量清楚了

⚠️ ⭐ 同一个文件里还有 3 处别的 `label: I18nLabelSchema` —— ⛔ 一个都不许碰

已落地 —— 三腿 + 两类 `merge=os-regen` 生成物的落地后复验

源码三腿,⏱️ 2026-09-18T18:11Z 取于 `origin/main` = `07c6f822ed`