Noticed while adding content/docs/permissions/capabilities.mdx for #10216 (PR #10335). Out of that card's scope, filed rather than fixed.
The observation
content/docs/permissions/meta.json ships 21 pages. The "What's in this module" list in content/docs/permissions/index.mdx names 14 of them. Six pages exist, are routed, appear in the sidebar, and are absent from the landing page's own list:
system-context — System Context (isSystem)delegated-administration — Delegated Administrationrls — Row-Level Securityattachments-access — Attachments Accessaccess-matrix — Access Matrixexplain — Explain
Two of them are named in the overview prose without a link (row-level security is described in the five-concepts paragraph; the business-unit/delegation model is described in the Best Practices section), so the omission is not "these pages are unreachable" — it is that the one list on the page which presents itself as the module's index is a partial one, with nothing marking it partial.
Same class as #9604 (runtime-services/index.mdx's chapter list omitting services.sms), a section over. Distinct from #10209, which is about the root meta.json omitting the whole references tree — this one is a hand-written list inside a section, not a nav config.
Why it is worth a card rather than a silent fix
The list is hand-kept next to a meta.json that is the real routing source, so it can drift in both directions and nothing checks it. check:docs-audit-scope keeps the audit scope derived from the filesystem for exactly this reason; there is no equivalent for a section landing page's own index list. Whoever picks this up should decide between (a) topping the list up by hand once, and (b) asking whether the two lists should be related mechanically at all — meta.json already carries the ordering, so a landing list that disagrees with it is a second hand-kept copy of one fact.
Not investigated here
Whether other section index.mdx files have the same gap. A sweep would answer it; this card records only the permissions/ instance actually observed.
Noticed while adding
content/docs/permissions/capabilities.mdxfor #10216 (PR #10335). Out of that card's scope, filed rather than fixed.The observation
content/docs/permissions/meta.jsonships 21 pages. The "What's in this module" list incontent/docs/permissions/index.mdxnames 14 of them. Six pages exist, are routed, appear in the sidebar, and are absent from the landing page's own list:system-context— System Context (isSystem)delegated-administration— Delegated Administrationrls— Row-Level Securityattachments-access— Attachments Accessaccess-matrix— Access Matrixexplain— ExplainTwo of them are named in the overview prose without a link (
row-level securityis described in the five-concepts paragraph; the business-unit/delegation model is described in the Best Practices section), so the omission is not "these pages are unreachable" — it is that the one list on the page which presents itself as the module's index is a partial one, with nothing marking it partial.Same class as #9604 (
runtime-services/index.mdx's chapter list omittingservices.sms), a section over. Distinct from #10209, which is about the rootmeta.jsonomitting the wholereferencestree — this one is a hand-written list inside a section, not a nav config.Why it is worth a card rather than a silent fix
The list is hand-kept next to a
meta.jsonthat is the real routing source, so it can drift in both directions and nothing checks it.check:docs-audit-scopekeeps the audit scope derived from the filesystem for exactly this reason; there is no equivalent for a section landing page's own index list. Whoever picks this up should decide between (a) topping the list up by hand once, and (b) asking whether the two lists should be related mechanically at all —meta.jsonalready carries the ordering, so a landing list that disagrees with it is a second hand-kept copy of one fact.Not investigated here
Whether other section
index.mdxfiles have the same gap. A sweep would answer it; this card records only thepermissions/instance actually observed.