l-domain-vocabulary

Look up the canonical zudo-text domain vocabulary before writing any user-visible wording — command palette labels, settings headings and field labels, button/menu text, aria-labels, tooltips, disable...

Domain Vocabulary

The words this app shows the user. Code identifiers are deliberately NOT governed by this skill — see Identifiers are not in scope.

Sources of truth for the shipped strings:

• Command palette — tauri-app/renderer/data/app-commands.tsx

• Shortcut group labels — tauri-app/renderer/components/settings/sections/shortcut-groups.ts

• Settings labels — packages/settings-sections/src/sections/general-settings.tsx, settings-search-metadata.ts

• Frame titles / provider display names — tauri-app/renderer/view-providers/*.tsx

• User docs — doc/src/content/docs/{manual,guide,overview}/**, manual/src/content/docs/** (the Japanese end-user manual)

The core rule

A control is never named after the frame it lives in.

If a command moves, toggles, or configures a part of a frame, its label must name that part, qualified by the frame — not the frame alone. Move Note Tray: Top is wrong because it reads as "move the whole Note Tray frame"; the command actually moves the toolbar inside that frame. The correct shape is Move Note Tray Toolbar: Top.

The same rule applies to aria-label, tooltips, disabledReason text, and settings headings. When in doubt, read the label out loud with no UI in front of you and ask: what exactly would I expect to move?

Canonical terms — Note Tray area

Short forms. Once "Note Tray toolbar" has been established in the same paragraph or dialog section, plain "the toolbar" is fine. Never shorten to "the tray" (that means the frame) or "the bar" in a new context (ambiguous with the app toolbar and the EFE tab bar).

Retired spellings — never reintroduce

Casing

Note Tray is always Title Case in every surface — it is the provider's display name. Only the qualifier varies:

• The Note Tray toolbar's own command-palette labels are Title Case, because their neighbours already are: Move Note Tray Toolbar: Bottom, Cycle Note Tray Toolbar Position, Tidy Up Notes, Timeline View, Switch to Nth Note.

• Everywhere else — settings headings, field labels, aria-label, tooltips, disabledReason, docs prose — the qualifier is lowercase: Note Tray toolbar, Note Tray toolbar position, Note Tray layout.

This is not a claim that the whole palette is Title Case. app-commands.tsx also holds plenty of sentence-case labels (Check diff, Slide settings, Toggle scroll sync, Toggle minimap). Match the casing of the entries a new command sits among; do not retitle unrelated commands to "fix" them.

Identifiers are not in scope

This skill governs strings the user reads. It does not govern:

• Component / prop / hook / constant names — DraftBar, draftBarPosition, draftBarOrder, draftBarExpanded, DRAFT_BAR_POSITIONS, setDraftBarPosition

• Settings keys — AppSettings.layout.draftBarPosition, draftBarOrder, draftBarExpanded

• Command ids — set-draft-bar-position-top, cycle-draft-bar-position, toggle-draft-bar-expanded

• Shortcut keys — cycleDraftBarPosition, toggleDraftBarExpanded

• Event names — draft-bar:set-position, draft-bar:cycle-position, draft-bar:toggle-expanded

• data-testid values, e2e spec filenames and describe() titles, file paths (draft-bar.tsx)

• Settings-search keyword aliases (keywords: ["draft bar"]) — those exist precisely so a user who remembers the old name still finds the control

Command ids key persisted user settings (shortcut bindings, palette ordering). Renaming them is a breaking change to user data for zero user benefit, and the repo's pre-release "no migration code" rule makes such a rename possible but not valuable. A string/identifier mismatch is normal and expected here.

Corollary: a legacy identifier is never evidence that the legacy word is still acceptable in a label.

Before you write a user-facing string — checklist

1. Does the string name a part of a frame? Then qualify it with the frame's name; do not use the frame's name alone.

2. Is the noun in the retired list? Replace it.

3. Does the same control already have a name somewhere else (settings heading, aria-label, settings-search label, docs)? Reuse the same words. One control, one name across the palette, Settings, a11y, and the manual. Casing follows the destination surface, per Casing — Move Note Tray Toolbar: Top in the palette and Note Tray toolbar position in Settings are the same name correctly cased, not a mismatch to reconcile.

4. If you changed a label, did you change it in both commandMetadata and buildAppCommands()? The repo's Feature Implementation Checklist requires both; a mismatch silently desyncs the settings UI from the runtime palette.

5. Did you update the user manual to the same words? doc/src/content/docs/manual/command-palette.mdx lists palette entries verbatim.

6. Does any unit test or e2e spec assert the old string? grep the exact literal before you finish.

Worked example — #4095 → #4099 → #4100

One surface answered to three names at once:

The user's report (#4095 topic 4) was not "the words Note Tray are wrong" — it was that the palette used the frame's name for a control that moves something inside the frame:

"the UI says 'Note Tray' here, but 'Note Tray' is a word that points the frame type. so maybe about this case, Move Note Tray utilbar to... might be proper."

So the fix was to add the qualifier, not to replace the noun: Move Note Tray Toolbar: Top. "Note Tray toolbar" won over "Note Tray utilbar" and "Draft Bar" on precedent — it was already the settings key (AppSettings.layout.noteTrayToolbar), the Settings → General heading, every settings-search id (note-tray-toolbar-*), the provider description, the e2e spec name (note-tray-toolbar-controls.spec.ts), and the epic title itself.

Decision record: #4099. Mechanical application: #4100.

Vocabulary outside the Note Tray area

Documented here for reference; renaming these is out of scope for the Note Tray toolbar epic. File a follow-up issue (label agent-found) rather than renaming opportunistically.