Noticed while rewriting four other entries in this file for #70. Unrelated to that card's defect class, so filed rather than folded in.
content/docs/resources/glossary.mdx has two ### Console headings. On origin/main they are at lines 53 and 192:
Console
The system UI at /_console/ — manages users, roles, permission sets, audit log, sessions, API keys, system settings. Distinct from Console (business UI).
Console
The business UI at /_console/ — browse, create, edit records, configure views, install apps from the marketplace. Distinct from Console (system UI).
Three things are wrong at once:
- The page's own promise is "A single canonical definition for each term used in this documentation" — one term now has two.
- Each entry disambiguates itself against a name identical to its own, so neither sentence can be acted on. This reads like a rename that replaced both halves of a pair with the same word.
- Both give the same URL,
/_console/, for two surfaces described as distinct. At most one of those can be right, and the glossary does not say which.
There is a fourth, smaller one in the neighbourhood — ### Surface names "the four HTTP entry points" and then lists /_console/ twice:
/ (REST API), /_console/, /_account/, /_console/.
Same shape of damage, almost certainly the same cause.
Do not fix this in isolation
#79 is the decision that governs this vocabulary: the end-user surface gets no name and the admin surface becomes Setup, docs and UI copy only, with the /_console URL explicitly untouched. Under that decision the two entries collapse to roughly one Setup entry plus no entry at all for the end-user surface — so a fix landing before #79 would be rewritten by it.
Filing it separately anyway because #79 is a naming card. A mechanical rename applied to the text above produces "Setup … Distinct from Setup" and leaves the duplicate /_console/ in the Surface entry untouched; the duplication and the wrong URL are a separate defect that a rename will not notice. Whoever executes #79 should be handed this so both are closed together, and the correct URL for each surface has to come from somewhere authoritative rather than from either of these two sentences.
Related: #79, #70.
Generated by Claude Code
Noticed while rewriting four other entries in this file for #70. Unrelated to that card's defect class, so filed rather than folded in.
content/docs/resources/glossary.mdxhas two### Consoleheadings. Onorigin/mainthey are at lines 53 and 192:Three things are wrong at once:
/_console/, for two surfaces described as distinct. At most one of those can be right, and the glossary does not say which.There is a fourth, smaller one in the neighbourhood —
### Surfacenames "the four HTTP entry points" and then lists/_console/twice:Same shape of damage, almost certainly the same cause.
Do not fix this in isolation
#79 is the decision that governs this vocabulary: the end-user surface gets no name and the admin surface becomes Setup, docs and UI copy only, with the
/_consoleURL explicitly untouched. Under that decision the two entries collapse to roughly oneSetupentry plus no entry at all for the end-user surface — so a fix landing before #79 would be rewritten by it.Filing it separately anyway because #79 is a naming card. A mechanical rename applied to the text above produces "Setup … Distinct from Setup" and leaves the duplicate
/_console/in theSurfaceentry untouched; the duplication and the wrong URL are a separate defect that a rename will not notice. Whoever executes #79 should be handed this so both are closed together, and the correct URL for each surface has to come from somewhere authoritative rather than from either of these two sentences.Related: #79, #70.
Generated by Claude Code