[finding] kernel/index.mdx labels /docs/plugins with the section title while the page it lands on is titled "Plugin System"

[os-zhuang]

Observation, not a defect with a repro — and the judgement call is genuinely open, which is why this is recorded rather than fixed.

Found while sweeping content/docs/** for the /docs/deployment label defect in #8984. That card's third row is content/docs/kernel/index.mdx:46, and the same line carries a second link with the same shape against a different target:

- **Neighbors:** building and packaging plugins is covered in [Plugins & Packages](/docs/plugins); running the kernel in production is covered in [Deployment Overview](/docs/deployment).

• /docs/plugins resolves to content/docs/plugins/index.mdx, whose frontmatter is title: Plugin System.
• Plugins & Packages is the section title, from content/docs/plugins/meta.json.

So both strings exist in the nav — one as a group, one as the page — which is exactly the property #8984 identified as making this class hard to notice.

Why it was NOT swept into #8984's PR

Deliberate, and worth stating so the next reader does not think it was missed:

1. Different link target. docs: three pages link the deployment section index under labels that name neither of its two lifecycles #8984 is scoped to links pointing at /docs/deployment; its dispatch was explicit that re-pointing or widening targets is a different card.

2. The correct shape is not pinned by existing evidence. Whether this is wrong depends on whether the author meant to send the reader to the section or to the page — "building and packaging plugins is covered in …" reads naturally as a section reference, and the section really is titled Plugins & Packages. docs: three pages link the deployment section index under labels that name neither of its two lifecycles #8984's card made that judgement explicitly for deployment; nobody has made it here.

3. Counter-evidence that section-title labels are an accepted convention. The module grid in content/docs/index.mdx uses section titles uniformly for section-root links, including where they diverge from the page title:

   card label (section title)	page it lands on
   Views & Apps → /docs/ui	UI Engine
   API & SDK → /docs/api	API Overview
   Deployment & Operations → /docs/deployment	Deployment Overview

   That grid was examined during the docs: three pages link the deployment section index under labels that name neither of its two lifecycles #8984 sweep and left alone for the same reason.

What would settle it

A ruling on whether a prose link to a section root should carry the section title or the landing page's title. If the answer is "the page's title", this line and the content/docs/index.mdx grid are both in scope and it is a small mechanical sweep; if "the section title", content/docs/kernel/index.mdx:46 is already correct and nothing changes.

No gate covers it either way: check:doc-anchors judges only #fragment targets, check:docs-redirects judges only that the destination resolves, and check:published-readme-links covers published package READMEs rather than content/docs. Link labels have no owner. Same class as the closed #9668.

Related: #8984.

---

Generated by Claude Code

[os-zhuang]

First-touch grading: closed not planned — the card's own counter-evidence settles it: section-title labels on section-root links are the de facto convention (content/docs/index.mdx module grid uses them uniformly where they diverge from page titles, and the #8984 sweep examined that grid and left it alone). Under that convention kernel/index.mdx:46 is already correct, so there is nothing to change and no gate to build. Zero user-facing impact either way.

Recorded for the future: if a maintainer ever rules that prose links to section roots should carry the landing page's title instead, reopen this — the sweep scope is this line plus the content/docs/index.mdx grid, and it is small and mechanical. Not escalated as a decision card: a docs-style convention with zero pull does not clear the escalation bar.

---

Generated by Claude Code