[Decision] Do docs-site breadcrumb labels follow the console-navigation convention or the page titles? Three spellings currently point at the same page

Raised by the repo:hotcrm PM seat, off an observation from #1125's R32 run. ⛔ Not dispatchable as filed — no convention exists to enforce, and inventing one is not a dev's call.

The observation

Docs-site breadcrumb link labels — the [Section › Page](/zh-Hant/docs/…) form used to cross-reference one docs page from another — are spelled inconsistently across zh-Hant pages while pointing at the identical target:

target	spellings in use
`/zh-Hant/docs/administration/automation`	`[管理 › 自動化]` ×5 · `[Administration › Automation]` ×4
the Extending Objects page	`[Customization › Extending Objects]` ×5 · `[自訂 › 擴充物件]` ×4 · `[定制 › 擴展物件]` ×3

⭐ Note the third row: 定制 › 擴展物件 is Simplified vocabulary in Traditional script — 定制 and 擴展 are the mainland word choices, where Taiwanese usage is 自訂 and 擴充. So one page's breadcrumb is neither the English form nor the Traditional form.

Why this is a ruling and not a cleanup

#1113 and #1368 settled that console navigation is labelled in English on zh-Hant pages, for a measured reason: the platform ships no Traditional pack, so the console falls back to Simplified, and a Traditional page names console paths in English rather than mix Simplified glyphs into Traditional prose.

⛔ That reason does not transfer. A docs-site breadcrumb does not name a console screen — it names another page of this documentation, which does exist in Traditional and whose own title: frontmatter is written in Traditional. The argument from "no Traditional pack" is silent here, and applying the console convention by analogy would mean a zh-Hant page linking to a zh-Hant page under an English label.

So there are two defensible conventions and the repo is currently running all three:

A — breadcrumbs follow the linked page's own title. [管理 › 自動化]. Internally consistent: the reader clicks through and sees that title. ⚠️ Means two different conventions live in adjacent sentences on the same page — English for console paths, Traditional for docs paths — which is exactly the "spelled two ways" complaint #1125 was filed about.

B — breadcrumbs follow the console convention, i.e. English. [Administration › Automation]. One rule for every X › Y form on the page, nothing to remember. ⚠️ Labels a Traditional page in English for a reader who is about to land on Traditional prose, and the measured reason for the console rule does not support it.

C — something narrower, e.g. English for sections that mirror console apps, Traditional for the rest. ⛔ The seat does not recommend this; a rule keyed on a distinction readers cannot see is how the current three-way split happened.

⚠️ Whichever is ruled, 定制 › 擴展物件 is wrong under all three — Simplified vocabulary in a Traditional page is not an option any convention endorses. That much can be fixed without a ruling if the maintainer prefers to split it out.

What is deliberately not being done

#1125's dev left guides/import-and-export.zh-Hant.mdx:163 [管理 › 設定] untouched on purpose, despite it being on a page that claim held exclusively and despite containing 設定. ⭐ That was the right call and the seat is recording it: it is a docs breadcrumb, not a console path, so #1368's ruling does not reach it and fixing it would have quietly established convention B by fait accompli.

If ruled

Scope is a sweep of every [… › …](…) breadcrumb across content/docs/**/*.zh-Hant.mdx (and ⚠️ the question applies to .zh-Hans.mdx too — the seat has not measured whether the same three-way split exists there, and whoever takes it must, rather than assuming symmetry). ⚠️ A guard is worth considering so the answer does not drift back, but ⛔ do not build one in the same PR as the sweep — the ledger-and-prose coupling on #1544 shows why that pairing wants its own round.

⚠️ A landed ruling bears on this card and was not cited when it was filed — the seat found it while selecting the next dispatch batch.

#1329 was ruled A on 2026-08-31 (maintainer, verbatim 「其他同意」, via the director seat): Chinese docs pages spell the view-name column in zh-CN locale-pack translations, and zh-Hant follows the existing script-conversion convention. Option C — keeping the split — was excluded outright, with the reason stated as 「分裂本身即缺陷:语料教 AI「这列随便写」,守卫永久残废」.

What that does and does not settle here

⛔ It does not decide this card. #1329's subject is view names — labels the console renders through the locale pack. This card's subject is docs-site breadcrumbs — cross-references to other documentation pages. Different objects, and the seat is not treating a ruling on one as a ruling on the other.

⭐ But it establishes a principle that points at option A, and that principle is worth putting in front of whoever rules here:

Spell it the way the thing actually renders to that reader.

That is the stated basis for #1329 — 「屏幕上渲染的正是它,文档字符串可直接在界面搜到」 (it is exactly what renders on screen, so the doc string can be searched for directly in the UI). Applied to a docs breadcrumb, the thing being named is another documentation page, and that page's title does render in Traditional to a zh-Hant reader. ⇒ option A (breadcrumbs follow the linked page's own title) is the reading consistent with #1329; option B would name a Traditional page in English on the grounds that a different surface — the console — falls back to Simplified.

⇒ the apparent inconsistency the card describes ("two conventions in adjacent sentences on the same page") is not incoherence once #1329 and #1368 are read together. They partition cleanly:

what is being named	convention	why	ruled by
a console navigation path	English	no Traditional pack; console falls back to Simplified, so English avoids mixing scripts	#1368
a view name	zh-CN translation (zh-Hant: script-converted)	it is what the console renders, and the reader can search for it	#1329
a docs-site breadcrumb	⚠️ unruled — this card	the linked page renders in Traditional	—

⚠️ This does not shrink the card to a formality. A maintainer may well hold that one page should not carry two spelling conventions at all regardless of which surface each names, which is an argument for B that #1329 does not touch. The seat is recording the pull toward A, not asserting it.

One thing the card said that is now sharper: 定制 › 擴展物件 — Simplified vocabulary in Traditional script — is wrong under #1329 as well, since item 2 requires zh-Hant to be produced by script conversion of the zh-CN form, and 定制/擴展 are not the conversion of 自訂/擴充. ⇒ that one spelling is fixable under a landed ruling and does not need this card. ⛔ Still not a rider: #1329 is now in flight and holds content/docs/service/cases.*, marketing/campaigns.* and revenue/products.*, which is not where the breadcrumb sits.

Generated by Claude Code

A third face of this question, measured during #1538 (PR #1560). ⛔ Not folded into this card's options — recorded because a ruling here will probably be read as covering it, and it should be ruled deliberately rather than by implication.

The zh-Hans surface contradicts itself about console paths

administration/sandbox-and-releases.zh-Hans.mdx:44   「**设置 → 云连接**」        fully localised
reference/performance-and-limits.zh-Hans.mdx:297     「设置里真正提供的是 **Setup → System Overview**」
                                                      Chinese prose, English path

⚠️ Note the second is the mirror image of the defect #1538 just fixed on the Traditional side — and on the Simplified side it may well be the wrong half that got fixed, because the reasoning differs:

zh-Hant has no pack, the console falls back to Simplified, so English avoids mixing scripts (The zh-Hant navigation convention rests on a false reason: the console falls back to Simplified, not English #1368). Settled.
zh-Hans has a pack. The console renders 设置 to that reader. So the [Decision] Should a Chinese docs page spell a view name in English or in its zh-CN translation? Five pages split two ways today, and no guard can be written until this is settled #1329 principle — 「屏幕上渲染的正是它，文档字符串可直接在界面搜到」, spell it the way it renders, so the reader can search for it — points at the localised form, i.e. sandbox-and-releases is right and performance-and-limits is wrong.

⭐ #1538's dev declined to file this, in its own words, because it "had no evidence that lets me call it either way" and would not file "a card on a coin flip." ⛔ The seat agrees it is not the dev's call, and is not making it either. Deriving a third surface's convention from two rulings that each addressed a different one is exactly the elaboration-is-not-the-ruling trap this lane has already paid for twice.

⚠️ But it is not quite a coin flip: rule 2 of the navigation guard resolves 设置 through APP_WORDS, so a fully localised zh-Hans path is checked today while an English path on a zh-Hans page is not. Whichever way this is ruled, one of those two lines is currently unguarded.

What the seat is asking for

⛔ Nothing added to this card's option list. Just: if the ruling here is meant to reach the zh-Hans console-path form, say so explicitly, because the three surfaces now in play are genuinely distinct —

surface	what is named	status
zh-Hant console navigation	a console path	ruled (#1368) — English
Chinese docs view-name column	a view label	ruled (#1329) — pack value
docs-site breadcrumbs	another docs page	this card
zh-Hans console navigation	a console path	⚠️ unruled, and self-contradictory today

Generated by Claude Code

More measured data for the zh-Hans surface, from #1559's run (PR #1563). ⛔ No verdict offered — the dev declined one and the seat is not supplying one.

#1559 checked whether the zh-Hans siblings of the two pages it fixed carry the same shape. They do:

content/docs/administration/index.zh-Hans.mdx:40   - **设置 UI** —— 在齿轮图标下（右上角）找到它。…
content/docs/guides/integrations.zh-Hans.mdx:33    …另外八个是*概览*、*应用*、*人员与组织*、*访问控制*、*审批*、*配置*、*诊断*与*高级*…

⚠️ Reported, not fixed — on a Simplified page the console really does render Simplified, so this may be the convention working, which is exactly the question this card holds.

⭐ Three facts that sharpen the question, and one of them is a different defect

The zh-Hans roster does NOT carry the Traditional page's mistranslation. Its entry six is 配置, correctly distinct from 设置. So whatever is decided here, the zh-Hans roster is at least internally right in a way the zh-Hant one was not.
⚠️ Its entry one is 概览, where the shipped zh-CN pack label is 总览.
⚠️ The app label the zh-CN pack ships is 系统设置, not 设置.

⇒ items 2 and 3 are not the convention question this card asks. They are a pack mismatch: the zh-Hans page uses Chinese, which may well be right, but it uses the wrong Chinese — a term the pack does not ship. ⛔ That is a different defect class, and it would still be a defect under either answer to this card.

⭐ Worth noting because it changes what a "leave zh-Hans alone" ruling would mean: leaving the convention alone does not make those two strings correct.

Where the roster's nine labels actually come from — now measured at the source

#1559 reached the platform rather than inferring:

node_modules/@objectstack/platform-objects/dist/apps → SETUP_APP
  exactly nine type:'group' entries:
  group_overview · group_apps · group_people_org · group_access_control · group_approvals
  group_configuration · group_diagnostics · group_integrations · group_advanced

Four independent sources agreed on the same nine in the same order (the platform, the English twin, and the two landed zh-Hant rosters). ⭐ And the platform's own zh-CN pack labels group_configuration as 配置 and the Setup app as 系统设置 — which is what proves the Traditional 設定 at position six was never Configuration's name and never the app's. That is the trap PR #1537 flagged, now confirmed against the package rather than against a sibling page.

Generated by Claude Code

Ruling recorded — option A, plus the adjacent zh-Hans console-path face (director seat, decision batch #75, 2026-09-07)

Maintainer reply, verbatim: 「同意」 — presented with A recommended, together with the zh-Hans console-path ruling.

One principle, four faces — 「照它实际渲染给读者的样子写」 (spell it the way it renders to that reader):

what is being named	convention	ruled by
zh-Hant console navigation path	English (no Traditional pack; console falls back to Simplified)	#1368
zh-Hans console navigation path	the zh-CN pack's label — e.g. 系统设置 (⛔ not 设置), 总览 (⛔ not 概览), 配置	this ruling
Chinese docs view-name column	the owning package's zh-CN pack value	#1329, #1552
docs-site breadcrumb `[Section › Page](/…/docs/…)`	the linked page's own title in that locale (zh-Hant: 管理 › 自動化; zh-Hans: 管理 › 自动化)	this ruling

⛔ Option B (breadcrumbs in English) refused: #1368's reason does not transfer to a page that exists in Traditional. ⛔ Option C refused: a distinction the reader cannot see.

Measured by this seat: the split exists on both scripts — zh-Hans breadcrumbs 25 Chinese-labelled / 18 English-labelled, zh-Hant 43 total — so the sweep covers content/docs/**/*.zh-Hant.mdx and *.zh-Hans.mdx.

What lands:

Every breadcrumb's label = the target page's title: frontmatter in the same locale. 定制 › 擴展物件 (Simplified vocabulary in Traditional script) disappears under this rule as under every other.
zh-Hans console paths (reference/performance-and-limits.zh-Hans.mdx:297 and any sibling) use the zh-CN pack labels, read from @objectstack/platform-objects's zh-CN bundle — the two pack mismatches Two more zh-Hant sites name platform navigation in Chinese — 「**設定 UI**」 on administration/index, and the Setup group roster on guides/integrations #1559 found (概览 vs 总览, 设置 vs 系统设置) are fixed in the same pass because they are the same rule.
⛔ No guard in the sweep PR (the #1368 is decided, so the navigation guard's five quarantined zh-Hant sidebar pairs are now a live worklist — and the prose and the ledger must land in one commit #1544 coupling lesson); a follow-up card builds the two-direction guard for breadcrumbs and for zh-Hans console paths (the navigation guard's rule 2 resolves 设置 via APP_WORDS today, so the English-path-on-zh-Hans line is the unguarded one).

needs-user-decision → pm:queue.

Generated by Claude Code

Ruled state restored — this card was ruled A on 2026-09-07 (batch #75, maintainer 「同意」, comment 5566184081) and transitioned to pm:queue in that act; it is back on needs-user-decision with no audited label event · 2026-09-16T11:35Z

Director seat, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL. Found while assembling batch #142: this card sat in the decision inbox, but its thread already carries a recorded ruling and the timeline's last label events are unlabeled needs-user-decision / labeled pm:queue by os-zhuang at 2026-09-07T06:43Z. The issue's updated_at is 2026-09-10T08:48Z and its labels now read documentation + needs-user-decision; no labeled/unlabeled event exists after 2026-09-07 on either the events or the timeline endpoint (read twice, two pages). Whatever wrote the label back did so without an audit trail this seat can read.

⛔ Not re-presented. A recorded ruling is not re-ruled (summon #17 discipline: 「已录裁的卡 ⛔ 不再呈」). The ruling stands exactly as written in 5566184081 — breadcrumbs take the linked page's own title: in that locale, sweep covers both zh-Hant and zh-Hans, no guard in the sweep PR — and the state is restored to what that ruling set: needs-user-decision → pm:queue, read back.

The unaudited relabel is recorded on the director seat post as a platform reading for the next seat that meets it.

Generated by Claude Code

Claim: PM loop round R64 (serial dispatch, maintainer instruction verbatim: 「串行派发」) · 2026-09-28T06:28Z
Session: session_01X8U3asekbiC7yWoEPWR4Dg
Branch: claude/issue-1545-docs-breadcrumb-labels
Worktree: hotcrm-issue-1545
Domain: repo:hotcrm (single-lane repo — no domain:* taxonomy)
Seat: repo:hotcrm#1
File surface: content/docs/**/*.zh-Hant.mdx and content/docs/**/*.zh-Hans.mdx lines carrying a docs-site breadcrumb [Section › Page](/…/docs/…), and zh-Hans console-path lines (reference/performance-and-limits.zh-Hans.mdx:297 and siblings), one empty-frontmatter .changeset/ (docs only). ⛔ No guard (ruling item 3). Stop on breach and explain in the report.
Container & model: M, mode:subagent, model: opus — default judgement tier, hand-picked (dispatch-gates --tier refuses hotcrm paths from the objectstack checkout)
Clause-②: no
Thread-read: 5696777598
Serial constraints cleared: PR #1966 (#1359, CI converging, about to land) edits 18 zh docs pages (anchor ids/links). ⇒ merge main before opening the PR. PR #1956 (#549, held) edits content/docs/administration/{sharing-and-security,profiles}* and revenue/contracts*; this is ordinary shared-path concurrency, and the later lander resolves any conflict. #1552 (queued) shares revenue/approvals.zh-* with this card and is held behind it: ⛔ not the same batch.

docs(zh): breadcrumb labels take the linked page's own title

docs(zh-Hans): console paths take the zh-CN pack labels

chore(changeset): empty-frontmatter changeset for the #1545 docs sweep

test(docs-nav): retire the 设置 quarantine now that #1545 rewrote its c…

Closed 2026-09-30T07:31Z as completed.

Delivered by #1967, merged as 4ca8e2d4 on main at 2026-09-30T07:28Z. The ruling (option A) landed in full:

Every zh-Hant and zh-Hans breadcrumb, 48 per locale, now takes the linked page's own title: in that locale.
The zh-Hans console paths take the zh-CN pack labels from @objectstack/platform-objects (系统设置, 总览, …).
The 设置 quarantine in test/docs-setup-navigation-names.test.ts is retired; the maintainer widened the surface for it: 「1967 可以改测试」.
No guard was added.

The PR body's Fixes #1545 did not auto-close this card, so it is closed here as completed.

Generated by Claude Code

Navigation Menu

Repository navigation

[Decision] Do docs-site breadcrumb labels follow the console-navigation convention or the page titles? Three spellings currently point at the same page #1545

The observation

Why this is a ruling and not a cleanup

What is deliberately not being done

If ruled

What that does and does not settle here

The zh-Hans surface contradicts itself about console paths

What the seat is asking for

⭐ Three facts that sharpen the question, and one of them is a different defect

Where the roster's nine labels actually come from — now measured at the source

Ruling recorded — option A, plus the adjacent zh-Hans console-path face (director seat, decision batch #75, 2026-09-07)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Decision] Do docs-site breadcrumb labels follow the console-navigation convention or the page titles? Three spellings currently point at the same page #1545

Description

The observation

Why this is a ruling and not a cleanup

What is deliberately not being done

If ruled

Activity

os-sales commented on Sep 3, 2026

What that does and does not settle here

os-sales commented on Sep 3, 2026

The zh-Hans surface contradicts itself about console paths

What the seat is asking for

os-sales commented on Sep 3, 2026

⭐ Three facts that sharpen the question, and one of them is a different defect

Where the roster's nine labels actually come from — now measured at the source

os-zhuang commented on Sep 7, 2026

Ruling recorded — option A, plus the adjacent zh-Hans console-path face (director seat, decision batch #75, 2026-09-07)

hotlong commented on Sep 16, 2026

objectstack-fleet commented on Sep 28, 2026

objectstack-fleet commented on Sep 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions