[stevenjj33]

What this changes

The settings page's 快捷键 tab was a label with disabled: true behind it, and the composer decided in code what Enter meant. This PR makes the tab a real page:

• 快捷键 is enabled and opens a page that lists the composer's keyboard actions, the key each one is bound to, and a control that captures a new binding.
• 发送消息 (send the message, built-in Enter) and 换行 (break the line, built-in Shift+Enter) are rebindable.
• 停止生成 is listed as 仅按钮，无快捷键. It is a button and nothing else: Escape is already claimed by the mention menu, the slash menu, the permission menu, goal mode and plan mode, so a shortcut for it would fight them. No Esc binding was added, per the task book.
• The binding is stored under webui-shortcuts.v1 — a key of its own, so it cannot collide with feat(webui): let the settings page switch between Chinese and English #250's mavis-locale.
• The composer reads the stored binding when a key is pressed, not when it renders, so a rebinding takes effect at once and survives a reload.
• A capture refuses a bare modifier (a binding is a combination) and a combination another action already holds — and the message names the action that holds it.
• 恢复默认 puts the built-in bindings back, and the composer follows them back.

The built-in behaviour is unchanged: with nothing stored, Enter sends and Shift+Enter breaks the line.

How it is put together

Piece	Where
The notation, the matching, the conflict rule	packages/webui/src/client/projection/common/shortcuts.ts — one canonical string (Control+Shift+Enter) that the page stores, shows and the composer matches against
The page's own model (which actions, their names, which are bindable)	packages/webui/src/client/features/settings/projection/settings-shortcuts.ts
The page	packages/webui/src/client/features/settings/ui/ShortcutsSettings.tsx
The rule the composer follows	resolveWebuiComposerShortcutAction in packages/webui/src/client/features/composer/projection/composer-state.ts

resolveWebuiComposerEnterAction is retired: the rule it encoded is the default configuration, expressed as the values the page shows. The three-valued answer (submit / newline / ignore) is what lets a press that names no binding fall through to the browser's own behaviour — which is how a key the user unbound stops doing the composer's business.

ADR packages/webui/docs/adr/0026-the-composer-follows-the-bindings-the-settings-page-stores.md records the decision.

Evidence

Check	Result
pnpm --filter @mavis/webui typecheck:client / pnpm typecheck:webui	pass
pnpm exec vitest run … settings-shortcuts.test.ts composer-intent.test.ts settings-modal.test.tsx browser-settings-page.test.tsx	103 passed
pnpm exec playwright test … settings-shortcuts.spec.mjs	7 passed
pnpm exec playwright test packages/webui/test/browser	165 passed; 19 failed, every failure environmental (a real Chrome this machine does not have, a PTY its node-pty cannot spawn, and the Linux-only visual baselines)
pnpm exec playwright test … settings-account-tab.spec.mjs settings-theme.spec.mjs composer.spec.mjs	25 passed
pnpm build:webui	pass
node scripts/source-inventory.mjs --write + pnpm check:source	pass (5456 files)
pnpm check:webui-dependency	0 direction / 0 cycle / 0 role / 0 publication violations

The browser suite covers the six acceptance points one by one: the tab opens and lists the actions with their current keys; a captured combination becomes the binding the page shows; the binding survives closing the settings and coming back; the binding survives a reload; the composer sends on the new key and no longer on the old one (the draft keeps the text and the line break, and nothing was sent for it); 恢复默认 returns to Enter and the behaviour follows it back. A seventh case covers a newline bound to a key the browser does not break the line on (Control+J), which the composer breaks itself.

Negative controls (mutation, then restore)

Mutation	What failed
The composer ignores the stored binding and always uses the defaults	exactly the two cases that depend on the composer following the stored binding — "the composer sends on the new binding" and "a newline bound to Control+J"
The page stops writing webui-shortcuts.v1	exactly the four cases that depend on persistence — close-and-reopen, reload, the composer's new binding, and the Control+J newline

Both mutations were reverted and the suite was re-run green.

CI

Check	Result	Notes
changes	pass
verify (windows-latest, 24)	pass
verify (ubuntu-latest, 24)	pass	the whole full profile, including the real-browser suite
verify (macos-latest, 24)	pass	the platform profile
verification	pass	the aggregate gate: every planned check is success
source-history-artifact (Release audit)	pass	no leaks found on all three gitleaks steps
performance	pass
docs	skipped	not a docs-only change

Every green run is on this branch's final head 9daf9cf8:
Source verification,
Release audit,
Performance.

The baseline's own gates were red, and are fixed separately

This branch inherited a baseline that failed on its own. Two pull requests, both
merged into webui before this one, carry the repair:

• fix(webui): make the webui baseline's own gates pass again #266 — check:webui-dependency reached for document directly
  (WorkspacePanels.tsx:528 and :573); the wait moved behind the browser
  platform seam. The same pull request brought the stale expectations back in
  line with the terminal and browser work (six test files, the fixture's
  terminal bridge, and one recorded Linux screenshot).
• test(webui): select the tab's current identity in the two-page row #267 — the two-page isolated-Chromium row selected a tab identity that the
  provider had already replaced, and the service refused it.

Neither pull request touches a file this pull request changes, so the diff here
is still only the shortcut page.

The gitleaks failure was mine, and it is fixed

The first run of the Release audit failed with leaks found: 1. It was this
branch's commit, not somebody else's:

rule=generic-api-key  file=packages/webui/src/client/projection/common/shortcuts.ts  line=44
match=SHORTCUT_STORAGE_KEY = "webui-shortcuts.v1"

webui-shortcuts.v1 is a localStorage key name, but it is high-entropy enough
(generic-api-key wants entropy > 3.5; this one is 3.84) to read as a
credential to gitleaks' generic-api-key rule. The fix is the one this
repository already uses for exactly this class of false positive: a documented
entry in .gitleaks.toml, next to the other "not a credential" entries:

[[rules.allowlists]]
description = "WebUI shortcut storage key name, not a credential"
condition = "AND"
paths = ['''(^|/)packages/webui/src/client/projection/common/shortcuts\.ts$''']
regexTarget = "match"
regexes = ['''^SHORTCUT_STORAGE_KEY = "webui-shortcuts\.v1"$''']

The release audit scans the history of every branch, so the entry has to be on
the baseline as well as here — which is why #266 carries the same entry. A
re-run of the official gitleaks v8.24.3 (the version the release audit pins)
against this branch's history and against the whole origin ref set:
no leaks found.

Pre-existing failures on the baseline (not this PR)

pnpm test:webui on this branch, locally: 6 failed / 3340 passed / 34
skipped. Every failure is No Chrome executable was found
(browser-core-agent-actions ×5, agent-transcript ×1): this machine has no
system Chrome, and the CI runners do. The same suite is green on the runners.

Two assertions that said 快捷键 was still disabled were updated, because it no
longer is: packages/webui/test/unit/settings-modal.test.tsx and
packages/webui/test/browser/settings-account-tab.spec.mjs.

Scope, and the boundary with #250

• No server or runtime change. Nothing outside packages/webui is touched, no new dependency, no i18n framework. The one file outside packages/webui is .gitleaks.toml, which only gains an allowlist entry (above).
• feat(webui): let the settings page switch between Chinese and English #250 (settings page language switch) is not touched. This branch does not contain feat(webui): let the settings page switch between Chinese and English #250, and this PR does not add, change or read any language pack: the page's strings are hard-coded Chinese, like the rest of the settings page on this baseline. The two PRs share exactly two files — settings-view.ts (the tab table, one disabled: true removed) and SettingsModal.public.tsx (the page mount, the state and the storage write) — and both changes are mechanical to reconcile.
• ADR numbering: this PR uses 0026, leaving 0025 to feat(webui): let the settings page switch between Chinese and English #250's language-pack ADR, which was claimed first.
• Out of scope, deliberately: the 语音 / 连接 / 个性化 tabs stay disabled, and voice input is not part of this.

The one visual baseline this PR changes

settings-dialog-linux.png is re-recorded here. The shortcuts tab is enabled,
so the settings dialog's nav renders that row in the active colour instead of
the greyed-out one — the picture changes, the code does not.

The recording was done on Linux, on the gate's own image, the same way the
other nine baselines in that folder were. Re-recording all ten produced nine
files that are byte-identical to the ones already in the repository and one
that is not, so the difference is this PR's change and not a drifted
environment.

The launcher's baseline also changed, but that was #266's doing, and it landed
on the baseline before this branch was updated with it.

Not verified here

• The browser suite was run locally on macOS only; the CI runners ran the gates on Linux and Windows as well.
• The local browser run cannot run the visual baselines at all (the repository tracks *-linux.png only), so the re-recorded picture was verified on the gate's Linux environment, not locally.