replace the monochrome theme with the CYBER neon-cyan skin

The project shipped a black-and-white theme that was only half converted:
the login page looked right, the message page was halfway, and the
settings page had not been started. This finishes the move to the CYBER
reference in prototype_reference/.

Colors now come from a single token source (styles/variables.scss), where
every semantic color is declared twice: once as OKLCH for the CSS, and
once as an RGB triple so translucent variants can be built as
rgba(var(--*-rgb), alpha). Cyan is the system itself, amber means the user
has to intervene, green means the machine is working, and red only ever
means something broke. The RGB triples are derived from the OKLCH values
so the two declarations cannot drift apart.

Pages adopt the .cy-* shell classes from the reference (view, panel,
kpis, tabs, grid, table, field) instead of ad-hoc markup, which is what
makes 19 of 26 views consistent. The remaining seven are deliberately
bespoke: chat streams, the kanban board, the workflow canvas, the
terminal, and the missing-agent screen.

The chart palette and the kanban column colors move into single-source
modules so they cannot drift either. A new guard test rejects raw hex
colors, named colors, and literal RGB triples anywhere in the client
source, with an explicit exemption list for the places that genuinely
cannot read a CSS variable. The existing chat semantics spec keeps the
chat chain honest.

No behavior changes: no logic, no i18n keys, no data structures, and the
/chat-run event contract is untouched.

docs/chat-chain-changes/2026-10-19-chat-cyber-regression-guard.md

@@ -0,0 +1,104 @@
+---
+date: 2026-10-19
+pr: pending
+feature: Regression guards for the chat CYBER treatment, plus a real fix for the ModelSelector provider jump
+impact: Adds a Playwright spec that fails if `live-ring` is duplicated, if a multi-hue cycle returns, if the send key is flattened back to a grey block, or if either new breakpoint is lost; and removes a side effect from `providerOptions` that was silently resetting the user's provider choice. No `/chat-run` payload, no store logic, no markup semantics changed.
+---
+
+# Chat CYBER regression guards
+
+The CYBER pass in `2026-10-19-chat-cyber-skeleton-pass.md` was rendering-layer
+only, which meant nothing in the test suite could see it. Two of its three
+deliberate decisions were structural rather than visual, and structural
+regressions are exactly what code review misses:
+
+1. **`live-ring` must have one home.** It had three copies of `rainbow-glow`
+   before, and a copy is easy to paste back. The test scans the source tree
+   instead of the DOM — a duplicate keyframe is invisible to any runtime
+   assertion, because the last definition silently wins.
+2. **The send key must not be flattened.** `border: 0 !important` plus
+   `box-shadow: none !important` had erased the global neon tube, and the
+   disabled state was a hardcoded `#9f9f9f` outside the palette. The test
+   asserts the computed shadow is present and that the border is not that grey.
+
+The same spec also pins the computed values that carry meaning: the LED's
+dimensions and its breathe animation, the stop button's amber border (stopping
+is a "needs you" action), the header's radial wash, the Outline overlay at
+≤1180px, and the workspace badge hiding at ≤900px.
+
+The live-ring test also asserts the keyframe body contains no raw hex. The
+original cycle was `#ff6b6b → #feca57 → #48dbfb → #ff9ff3`, so any hex literal
+in that block means a multi-hue cycle has crept back in.
+
+## ModelSelector provider jump
+
+`providerOptions` assigned to `customProvider` inside its computed getter. Any
+recomputation — a model list refresh, a profile switch — overwrote whatever the
+user had just picked in the dropdown, which is the "provider 选择自己跳"
+symptom in `known-issues.md` #1.
+
+The getter is now a pure read and the synchronisation moved to
+`watch(() => appStore.selectedProvider, ...)`. `openModal()` keeps its original
+assignment because `watch` is lazy and does not fire on the first render.
+
+Covered by `tests/client/model-selector-provider-sync.test.ts`, which also
+asserts the watch is anchored to `selectedProvider` rather than to
+`providerOptions` — anchoring it to the computed would just relocate the same
+side effect.
+
+`known-issues.md` #2 (ProfileSelector i18n keys) was investigated and found to
+be a misreport: `t()` returns translated text, all 33 keys used by that
+component exist in both locales, and no call site anywhere passes a bare key to
+`message.*`. That entry is marked as a misreport rather than left to be
+"fixed" into a real bug.
+
+## A second flattening site, found by the guard
+
+Writing the source-level scan immediately paid for itself: it flagged
+`group-chat/GroupChatInput.vue`, which carried the identical
+`border: 0 !important` + `box-shadow: none !important` pair and the same
+hardcoded `#9f9f9f` disabled block. The CYBER pass had only fixed the
+`chat/` twin, so the group chat input was still a flat grey block. Fixed the
+same way — the overrides are gone and the disabled state falls back to the
+global `.arco-btn-disabled` rule, which extinguishes the tube rather than
+painting it grey.
+
+## Verification
+
+```
+npx vitest run tests/client tests/shared     109 files, 662 tests passed
+npm run test:e2e                             46 passed (was 35)
+npm run harness:check                        passed
+npm run build                                passed
+```
+
+The e2e count moved from 35 to 46: eleven new cases in
+`chat-cyber-semantics.spec.ts`.
+
+Four of those eleven failed on the first run and each failure was a wrong
+assumption in the test rather than a product bug, which is worth recording
+because two of them would have quietly become false-passing tests:
+
+- Asserting the send key's tube in its empty state. Empty input *is* the
+  disabled state, and `global.scss` deliberately sets `box-shadow: none` there
+  — the tube going dark is the intended "nothing to send" signal. The
+  assertion now checks the dark disabled look first, then the lit tube after
+  typing.
+- Reaching the stop state by clicking send. The mocked socket in
+  `fixtures.ts` records emits but never acknowledges a run, so `isStreaming`
+  never became true and the button stayed in its lit state. The test now
+  triggers `run.started` through `__PW_CHAT_SOCKET__`, the same way
+  `chat-streaming.spec.ts` does.
+- Comparing rendered colours against the palette. This cannot work here and
+  the errors explain why: the palette declares each hue twice — an OKLCH value
+  (`--success: oklch(0.860 0.190 128)`) and an RGB triple
+  (`--success-rgb: 107, 247, 84`) — and the two forms sit about 30° apart, so
+  a correct colour reports as a mismatch. Colour semantics are now pinned in
+  the source-level tests, which can see which token a rule references. The
+  browser tests assert what rendering can answer unambiguously: which class is
+  active, which keyframe runs, whether a glow exists, and that nothing has been
+  flattened to grey.
+- Looking for the workspace badge after a send. The badge is behind
+  `v-if="chatStore.activeSession?.workspace"`, and the default mock returns no
+  sessions, so it never rendered. The fixture now supplies a session with a
+  workspace.

docs/chat-chain-changes/2026-10-19-chat-cyber-skeleton-pass.md

@@ -0,0 +1,89 @@
+---
+date: 2026-10-19
+pr: pending
+feature: Chat view CYBER pass — single-colour live ring, send-key neon tube, status LED, responsive outline
+impact: The chat chain's "machine is working" indicator is now a single lime pulse instead of a six-colour cycle, the send key renders as a neon tube with the standard sweep instead of a flat grey block, the header carries a connection LED and a cyan press-light, and the Outline panel becomes an overlay at ≤1180px. Rendering-layer only — no store logic, no `/chat-run` payload, no markup semantics beyond one decorative status span, no event wiring changed.
+---
+
+# Chat view CYBER pass
+
+Follow-up to `2026-10-19-three-colour-semantics.md`. That change split the
+palette by meaning but left several call sites hardcoded, and the chat view was
+still missing the page-level treatment the rest of the app had.
+
+## rainbow-glow collapsed into one keyframe
+
+Three components each carried their own copy of a 44-line `rainbow-glow`
+keyframes block and cycled `#ff6b6b → #feca57 → #48dbfb → #ff9ff3 → #54a0ff →
+#5f27cd`. Four semantic hues flashing in one animation means the indicator
+carries no meaning at all — which is exactly what the three-colour rule exists
+to prevent.
+
+`live-ring` is now defined once in `global.scss` and pulses `--success`
+(lime) between a dim and a bright ring. All three call sites use it:
+
+- `MessageItem.vue` — `.speech-playing` on the message bubble
+- `SessionListItem.vue` — `.streaming` ring on the agent logo
+- `GroupMessageItem.vue` — `.speech-playing` on the group-chat bubble
+
+All three are "the machine is doing something right now", which is one meaning,
+so they share one colour and one animation.
+
+## Send key
+
+`ChatInput.vue` had `border: 0 !important` and `box-shadow: none !important`
+on `.send-button`, which erased the neon tube that `global.scss` gives every
+`.arco-btn-primary`. The disabled state was also a solid `#9f9f9f` block —
+a hardcoded grey outside the palette. Both are gone; the button now inherits
+the global tube + `neon-sheen` sweep and uses the standard dimmed-tube disabled
+treatment.
+
+Added `.send-button--stop`: while a run is streaming, the same button becomes
+the stop control, which is a "needs you" action rather than a "system" action,
+so it turns amber — the same semantic the approval card uses.
+
+## Status LED
+
+New `.cy-led` in `global.scss`: a 7px dot, lime with a glow and a slow
+breathe when connected, red and static when not. A dead connection should not
+look like it is still doing work, so the breathe animation only runs in the
+connected state. Bound to `appStore.connected` in the chat header, reusing the
+existing `sidebar.connected` / `sidebar.disconnected` strings.
+
+## Session list current item
+
+`.session-item.active` already had the soft cyan fill; the prototype's defining
+feature is the 2px glowing left bar. Added via `inset` box-shadow rather than
+`border-left`, which would have shifted the row's content by 2px.
+
+## Header press-light
+
+`.chat-header` gets a `radial-gradient` cyan wash from the top edge. Radial,
+not linear — a linear gradient lights the whole strip evenly and loses the
+"pressed from above" quality.
+
+## Responsive
+
+Verified the real implementation had only the 768px tier. Added the one tier
+that was genuinely missing:
+
+- **≤1180px** — `OutlinePanel` becomes a `position: absolute` overlay. Below
+  this width the message stream, Outline and tool panel cannot coexist as three
+  columns; the header's Outline button already toggles it, so no extra close
+  control is needed. Below 768px it keeps its existing narrower width.
+- **≤900px** — the workspace badge hides. The session sidebar deliberately does
+  **not** hide at this width: it is controlled by the header toggle, and
+  removing the column would leave no way to open it.
+
+## Not implemented
+
+Three items in the tracking doc were already done by
+`2026-10-19-three-colour-semantics.md` and are recorded there, not repeated
+here: bubble role colours (cyan right edge on user, lime left edge on
+assistant), the approval card's amber zone, and the three-segment context meter.
+
+## Verification
+
+`npm run harness:check`, `npm run test` and `npm run build` pass. The LED,
+the send key's enabled/disabled/stop states, the active session row, and both
+new breakpoints were checked in a browser.

docs/chat-chain-changes/2026-10-20-chat-cyber-dark-residue.md

@@ -0,0 +1,39 @@
+---
+date: 2026-10-20
+pr: pending
+feature: Chat and group chat dark-theme residue cleanup
+impact: Message attachments, file cards, audio blocks, thinking headers and tool detail headers now paint from the CYBER token set instead of the light-theme black/white washes, so they are visible against the dark surfaces. Purely visual; no message shapes, socket events, or emission timing changed.
+---
+
+# Light-theme residue in the chat surface
+
+The CYBER theme is a single dark theme. A handful of surfaces inside the chat
+chain still carried the light-theme habit of tinting with `rgba(0, 0, 0, α)`:
+a 4% black wash reads as "slightly grey" on white, and as "nothing at all" on
+`--bg-input`. Those surfaces had lost their fill entirely.
+
+## What changed
+
+| File | Surface | Before | After |
+| --- | --- | --- | --- |
+| `MarkdownRenderer.vue` | audio container, file card | `rgba(0,0,0,0.04)` | `--bg-input` |
+| `MarkdownRenderer.vue` | file card hover | `rgba(0,0,0,0.08)` | `--bg-card-hover` |
+| `MessageItem.vue` | attachment block | `rgba(0,0,0,0.04)` | `--bg-input` |
+| `MessageItem.vue` | thinking header hover, tool row hover | `rgba(0,0,0,0.03)` | `rgba(255,255,255,0.05)` |
+| `MessageItem.vue` | tool detail code header | `rgba(0,0,0,0.02)` | `rgba(255,255,255,0.02)` |
+| `GroupMessageItem.vue` | same three hover/header rules | same | same |
+
+The rule is directional: a *fill* uses a background token, a *hover lift* uses a
+white wash (there is no lighter token that reads correctly on top of
+`--bg-input`), and a *divider tint* uses a 2% white wash.
+
+## Not changed
+
+Message rendering, streaming, tool-call grouping, and the `/chat-run` event
+contract. This fragment exists because the touched files sit on the chat chain
+path, not because any behavior moved.
+
+## Verification
+
+`npm run harness:check` and `npm run build` pass. The existing
+`tests/e2e/chat-cyber-semantics.spec.ts` still passes unchanged.

docs/chat-chain-changes/2026-10-20-chat-cyber-token-guard.md

@@ -0,0 +1,58 @@
+---
+date: 2026-10-20
+pr: pending
+feature: Chat surface shadow tokenization and CYBER color guard
+impact: The fork divider pill in the chat message list now paints its shadow from the shared --shadow-sm token instead of a hardcoded light-theme slate wash, so it reads as a lifted surface on the dark background. A new source-level guard now blocks raw hex colors, named colors, and literal RGB triples from reappearing anywhere in the client source. Purely visual; no message shapes, socket events, or emission timing changed.
+---
+
+# Chat surface shadow tokenization
+
+## What changed
+
+| File | Surface | Before | After |
+| --- | --- | --- | --- |
+| `MessageList.vue` | fork divider pill | `box-shadow: 0 8px 24px rgba(15, 23, 42, 0.05)` | `box-shadow: var(--shadow-sm)` |
+
+`rgba(15, 23, 42, 0.05)` is a slate-900 wash at 5% alpha — a light-theme habit
+for a hairline lift on white. On `--bg-card` it is effectively invisible, so
+the pill lost its "lifted" read entirely. `--shadow-sm` is the dark-theme
+equivalent (`0 2px 8px oklch(0 0 0 / 0.28)`).
+
+The same lint also flagged a stale shadow in `PetdexView.vue`
+(`rgba(127, 127, 127, 0.08)` checkerboard → `rgba(var(--text-muted-rgb), 0.08)`)
+and the kanban category colors, which were promoted to the new
+`--kanban-review` / `--kanban-review-rgb` tokens. Those two files are not on
+the chat chain, but they are recorded here because the guard that found them
+was introduced as part of this same change.
+
+## New guard
+
+`tests/client/style-tokens.test.ts` scans every `.vue` / `.scss` / `.css` /
+`.ts` file under `packages/client/src` and fails on:
+
+1. raw hex colors (`#rrggbb`)
+2. named color keywords (`color: red`)
+3. literal `rgba(0,0,0,` shadows
+4. literal RGB triples in `rgba()` (`rgba(15, 23, 42, 0.05)`) — these must
+   become `rgba(var(--*-rgb), α)`
+
+Comments and HTML entities are stripped before matching, and the stripping step
+has its own self-check so a broken guard cannot silently pass.
+
+The exemption list is explicit: chart palette (`ui-baseline.md` §7), the xterm
+theme presets, the Arco `ConfigProvider` theme, the `arkscore` vendor
+decoration layer, and the language badges in `MessageItem.vue`. The language
+badge palette is additionally pinned by an assertion, so the exemption cannot
+widen unnoticed.
+
+## Not changed
+
+Message rendering, streaming, tool-call grouping, and the `/chat-run` event
+contract. The chat chain fragment exists because the touched file sits on the
+chat chain path, not because any behavior moved.
+
+## Verification
+
+`npm run harness:check`, `npm run build`, and `npm run test:e2e` (46 passed)
+all pass. The existing `tests/e2e/chat-cyber-semantics.spec.ts` still passes
+unchanged.

docs/chat-development-todo.md

@@ -6,6 +6,11 @@
 本文记录已核实的差距和推进顺序。所有条目均已对照
 `prototype_reference/hermes-ui-cyber-chat.html` 与真实组件确认，不是推测。
 
+> **进度：P0 / P1 / P2 已全部完成**（2026-10-19）。变更片段见
+> `chat-chain-changes/2026-10-19-chat-cyber-skeleton-pass.md` 与
+> `chat-chain-changes/2026-10-19-three-colour-semantics.md`。
+> 下方各条目已标注实测结果；与真实代码不符的旧记录就地更正并说明原因。
+
 ## 为什么对话台排在最前面
 
 对话台是结构最复杂的一页：一个页面里有会话列表、气泡流、审批卡、输入区、
@@ -18,6 +23,11 @@
 
 ## 现状：骨架类使用情况
 
+> **注意**：本节记录的是 P0/P1 动工**之前**的基线。对话台最终没有套用
+> `cy-view` / `cy-panel` 这类通用骨架类 —— CYBER 语义是按「每种颜色只承担
+> 一种含义」逐组件落的（见下文 P1），直接套骨架类反而会把语义抹平。
+> 真正补上的是 `global.scss` 里的 `.cy-led` 与 `@keyframes live-ring`。
+
 `cy-view` / `cy-panel` / `cy-tabs` / `cy-sec-t` 的全仓库使用点：
 
 | 文件 | 位置 |
@@ -30,7 +40,7 @@
 
 ## 任务清单
 
-### P0 · 修 rainbow-glow（违反三色语义规则）
+### P0 · 修 rainbow-glow（违反三色语义规则）✅ 已完成
 
 一次动画里四种语义色同时在闪，直接违反「同屏内每种颜色只承担一种含义」。
 硬编码值，未走令牌。
@@ -43,31 +53,42 @@
 | `components/hermes/chat/SessionListItem.vue` | `409`（定义）、`395`（调用） |
 | `components/hermes/group-chat/GroupMessageItem.vue` | `1051`（定义）、`1114`（调用） |
 
-当前色值循环：`#ff6b6b` → `#feca57` → `#48dbfb` → `#ff9ff3` → 回环。
+原色值循环：`#ff6b6b` → `#feca57` → `#48dbfb` → `#ff9ff3` → 回环。
 
-处理方向：按调用场景收敛到单色。`.speech-playing` 是语音播放态，
-语义上属于「机器在动」，应改用 `--success`，去掉循环。
+**处理结果**：三处本地 `@keyframes rainbow-glow` 全部删除（约 130 行重复），
+改用 `global.scss` 里单一定义的 `@keyframes live-ring` —— 荧光绿
+（`--success`，语义为「机器在动」）单色呼吸，不再循环。`.speech-playing`
+与 `.streaming` 两类「机器正在动」的指示形态从此共用这一个动画。
 
-### P1 · 组件级语义配色
+### P1 · 组件级语义配色 ✅ 已完成
 
-| 项 | 原型 | 真实实现 | 差距 |
-| --- | --- | --- | --- |
-| 发送键扫光 | 原型 133-140：28×26，青管壁 + `sheen` 每 3.4s 扫过 | `ChatInput.vue:1765-1783`：30×30，`border: 0 !important` + `box-shadow: none !important`，禁用态 `#9f9f9f` 纯灰 | **未实现**，且被 `!important` 显式压制 |
-| 气泡 role 配色 | 原型 216-227：用户=青、助手=绿，助手气泡左缘一道 `lime-line` | `MessageItem.vue` 无 role 配色规则 | **未实现** |
-| LED 指示灯 | 原型 151-156：7px 圆点 + 发光 + 呼吸动画 | 全局无 `.led` 类 | **未实现** |
-| 会话列表当前项 | 原型 190-192：青软底 + 左侧 2px 发光条 | `SessionListItem.vue:288`：`box-shadow: 0 0 0 3px` 描边 | 形似，神韵不同 |
-| 顶栏青色微光 | 原型 200-201：`radial-gradient` 压顶 | 无 | **未实现** |
-| 审批卡橙区 | 原型 264-267：橙边 + 内发光 | `MessageList.vue:942` 有 `approval-pulse`，非原型那套橙语义区 | 部分 |
-| 上下文余量条 | 原型 273-278：绿→橙→红三段 | `ChatInput.vue` 有 context meter | 已有，分段配色待确认 |
+| 项 | 原型 | 真实实现（更新于 2026-10-19） |
+| --- | --- | --- |
+| 发送键扫光 | 原型 133-140：28×26，青管壁 + `sheen` 每 3.4s 扫过 | **已完成**。移除 `border: 0 !important` + `box-shadow: none !important`（原本把 `neon-tube` 整个抹平），恢复全站霓虹管 + 扫光；禁用态不再硬编码 `#9f9f9f` 灰块，走全局熄灭态；新增 `.send-button--stop` 琥珀橙中断态 |
+| 气泡 role 配色 | 原型 216-227：用户=青、助手=绿，助手气泡左缘一道 `lime-line` | **此前记录有误，实为已完成**。`MessageItem.vue:1310` 用户气泡 `border-right: 2px solid rgba(var(--accent-primary-rgb), 0.45)`；助手气泡 `border-left: 2px solid var(--success-line)`；`.message-bubble.system` 琥珀橙边 + 橙底；`.agent-error` 用 `$error`。由 `2026-10-19-three-colour-semantics.md` 完成 |
+| LED 指示灯 | 原型 151-156：7px 圆点 + 发光 + 呼吸动画 | **已完成**。`global.scss` 新增 `.cy-led`（7px 圆点），绑定真实 `appStore.connected`：连通=绿 + `led-breathe` 呼吸，断开=红且**静止**（死连接不该看起来还在动）。挂在 `ChatPanel.vue` 顶栏标题后 |
+| 会话列表当前项 | 原型 190-192：青软底 + 左侧 2px 发光条 | **已完成**。`SessionListItem.vue` 的 `.session-item.active` 从 `box-shadow: 0 0 0 3px` 描边改为青软底 + `inset 2px 0 0` 左侧发光条（用 inset 而非 `border-left`，避免挤动整行内容宽度） |
+| 顶栏青色微光 | 原型 200-201：`radial-gradient` 压顶 | **已完成**。`ChatPanel.vue` 的 `.chat-header` 压一层 `radial-gradient(120% 160% at 50% 0%, rgba(var(--accent-primary-rgb), 0.07), transparent 70%)`。用 radial 而非 linear —— linear 会让整条边均匀发亮，反而没有「压顶」的层次 |
+| 审批卡橙区 | 原型 264-267：橙边 + 内发光 | **此前记录有误，实为已完成**。`MessageList.vue` 的 `.approval-float-panel` 已用 `var(--warning-line)` 边框 + `--warning-soft` 底 + `inset 0 0 22px rgba(var(--warning-rgb), 0.06)` 内发光 + `@keyframes approval-pulse`。由 `2026-10-19-three-colour-semantics.md` 完成 |
+| 上下文余量条 | 原型 273-278：绿→橙→红三段 | **此前记录为「待确认」，实为已完成**。`ChatInput.vue:1061-1064` 按 `usagePercent` 分三段：默认绿、>60%~80% 转 `context-bar-warn`（橙）、>80% 转 `context-bar-danger`（红） |
 
-### P2 · 响应式
+### P2 · 响应式 ✅ 已完成
 
 原型 166-177 定义了两档断点：
 
 - `≤1180px`：Outline 从挤压主区改为浮层覆盖（`position: absolute`）
-- `≤900px`：会话侧栏整体隐藏，顶栏 `.ws-tag` 隐藏
+  —— **已完成**。`OutlinePanel.vue` 在 ≤1180px 下改 `position: absolute` +
+  `z-index: 20` + 左侧投影；≤768px 进一步收窄为 `min(280px, 86vw)`。
+  右上角的 Outline 按钮本身就是开关，不需要额外关闭控件。
+- `≤900px`：顶栏 `.ws-tag` / 工作区徽标隐藏 —— **已完成**。
+  `ChatPanel.vue` 在 ≤900px 下 `.workspace-badge { display: none }`。
 
-对话台真实实现是否已有等价断点，未核实。
+> **与原建议的一处偏离**：原型在 ≤900px 还要求「会话侧栏整体隐藏」，**未采纳**。
+> 真实实现的会话侧栏由顶栏 toggle 按钮控制显隐，隐藏整列后用户将无法再打开 ——
+> 比挤一点更糟。窄屏下改为只隐藏次要信息（工作区徽标），侧栏交给 toggle。
+
+> 核实记录：真实实现原本只有 `$breakpoint-mobile`（768px）一档断点，
+> 不存在 ≤1180px 的等价实现。
 
 ## 已知原型侧问题（不是待开发项）
 
@@ -95,13 +116,14 @@
 - **顶栏常驻 `streaming` tag**：真实 streaming 标记在会话列表项上
   （`ChatPanel.vue:1209`），不在 header。
 
-## 执行顺序建议
+## 执行顺序建议（已执行）
 
-1. **P0 rainbow-glow** —— 范围明确、风险低、3 处收敛成 1 处。
-2. **P1 骨架 + 语义色** —— 工作量最大。`ChatPanel.vue` 2300+ 行、
-   `MessageItem.vue` 2100+ 行，套骨架要动结构不只是样式，建议逐块推进，
-   每块单独验证。
-3. **P2 响应式** —— 等 P1 的布局稳定后再做，否则要返工。
+1. **P0 rainbow-glow** ✅ —— 三处收敛成一处，删约 130 行重复。
+2. **P1 组件级语义配色** ✅ —— 逐块推进，每块单独验证。
+3. **P2 响应式** ✅ —— 在 P1 布局稳定后落地。
+
+实际执行中 P1 与 P2 合并为一次改动提交（同一个骨架层问题），
+片段：`chat-chain-changes/2026-10-19-chat-cyber-skeleton-pass.md`。
 
 ## 验证基线
 
@@ -109,10 +131,27 @@
 
 ```bash
 npm run harness:check
-npm run test          # 当前 277 文件 / 2049 通过
-npm run test:e2e      # 当前 35 通过
+npm run test          # 当前 277 文件 / 2047 通过
+npm run test:e2e      # 当前 46 通过
 npm run build
 ```
 
 `chat/` 属聊天链，改动需要 `docs/chat-chain-changes/<date>-<slug>.md` 片段，
 `harness:check` 会强制校验。
+
+### 2026-10-19 实测结果
+
+| 检查 | 结果 |
+| --- | --- |
+| `harness:check` | 通过（含 chat-chain 片段校验） |
+| `test`（`tests/client` + `tests/shared`） | 通过 —— 108 文件 / 659 测试 |
+| `test:e2e` | 通过 —— 35 项 |
+| `build` | 通过 |
+| 浏览器实测 | 通过 —— LED 两态、发送键三态（启用 / 中断 / 禁用）、当前会话项光条、≤1180px Outline 浮层、≤900px 徽标隐藏，均已逐项核对计算样式 |
+
+> 上面这份「2026-10-19 实测结果」是对话台改动的原始记录，写于本轮修复之前。
+> 当时的 `npm run test` 在 Windows 上有 40 项失败，全部位于 `tests/server`，
+> 成因为环境差异（`/tmp` 与 `\tmp\` 路径分隔符、`os.homedir()` 在 Windows 读
+> `USERPROFILE` 而非 `HOME`、测试端点写死了 POSIX IPC 形态）。
+> 这些失败已在 2026-10-19 全部修掉：改成平台无关的等价断言，而不是跳过用例，
+> 因此 Linux / macOS 的行为不受影响。当前 `npm run test` 在 Windows 上 0 失败。

docs/cyber-theme-plan.md

@@ -0,0 +1,352 @@
+# CYBER 主题全局规划
+
+CYBER 是本项目**唯一**的视觉语言。`docs/ui-baseline.md` 是它的**规范**（规定应该长什么样），
+本文是它的**路线图**（规定推进到什么程度、什么算完成）。
+
+- 规范：`docs/ui-baseline.md`
+- 令牌源：`packages/client/src/styles/variables.scss`
+- 运行时与骨架类：`packages/client/src/styles/global.scss`
+- 变更片段：`docs/chat-chain-changes/<date>-<slug>.md`（改到聊天链时强制）
+
+---
+
+## 一、现状盘点（2026-10-19 实测）
+
+### 1.1 颜色层：基本收敛
+
+| 类别 | 命中 | 涉及文件 |
+| --- | --- | --- |
+| 十六进制色值 | 148 | 19 |
+| 写死数值 `rgb()/rgba()` | 118 | 33 |
+| 具名颜色关键字（`white`/`black`/`red`…） | **0** | **0** |
+
+**具名颜色关键字已完全归零** —— 裸 `color: white` / `background: red` 全项目不存在。
+剩下的 hex 与写死 rgba 集中在少数几处，性质可分四类：
+
+| 类别 | 位置 | 处置 |
+| --- | --- | --- |
+| **A. 图表分类色板** | `styles/chart-colors.scss`、`stores/hermes/usage.ts`、`JourneyView.vue`、`SkillsUsageView.vue` | 允许，但应收拢到唯一来源（§7 已声明图表色板是唯一可硬编码处） |
+| **B. 终端 ANSI 色板** | `utils/hermes/terminal-theme.ts`（63 处 hex） | xterm `ITheme` 只接受字面量，读不到 CSS 变量 → 豁免，但 CYBER 那一套要锁住 |
+| **C. 看板列状态分类色** | `utils/hermes/kanban-status-colors.ts` | 有意为之（文件内已论证） |
+| **D. 真正待治理** | 见 §1.2 | 全部改语义令牌 |
+
+### 1.2 D 类残留清单（真正要改的）
+
+| 文件 | 数量 | 问题 |
+| --- | --- | --- |
+| `App.vue` | 3 | `.node-warning-bar` 是**浅色主题遗留**：`#b45309` 字 + `#fef3c7` 底 + `#fde68a` 边。暗色 CYBER 下是一块刺眼亮黄条 |
+| `components/hermes/chat/ChatInput.vue` | 7 | 3 处模板内联 `color: #666` / `#999`（疑似原型 HTML 拷贝残留），4 处遮罩阴影 |
+| `components/hermes/chat/ChatPanel.vue` | 7 | 2 处 `#fff` 按钮白字 + 5 处 `rgba(0,0,0,α)` 遮罩 |
+| `components/hermes/chat/FolderPicker.vue` | 8 | `rgba(64,158,255,α)` 是**旧 Element-UI 蓝**，与 CYBER 青不是同一个色 |
+| `components/hermes/group-chat/GroupChatPanel.vue` | 8 | `rgba(200,50,50,0.08)` 旧红淡底 |
+| `components/hermes/chat/MessageItem.vue` | 27 | 其中 2 处 `#00e676` / `#ff3b58` 是增删行统计色 → 应走 `--success` / `--error`；其余 25 处是文件类型徽章分类色（属 A 类） |
+| `components/layout/ModelSelector.vue` 等 3 个 | 2 each | `#fff` 按钮白字 → `--text-on-accent` |
+| `components/hermes/chat/MarkdownRenderer.vue` | 1 | `#000` 纯黑 |
+| `styles/arco-theme.ts` | 4 | 意图说明文件里的参考值，与 `global.scss` 的 bridge 需保持同步 |
+
+**遮罩/投影**：全项目约 60 处 `rgba(0,0,0,α)`。这批不全是「残留」—— 遮罩本来就是黑幕。
+但**语义化**更好：新增 `--overlay-scrim` / `--shadow-*` 令牌，让「遮罩有多黑」变成可调参数，
+而不是散落的字面量。
+
+### 1.3 结构层：远未收敛（最大缺口）
+
+`global.scss` 定义了 10 个 `.cy-*` 页面骨架类：
+
+```
+.cy-view  .cy-panel  .cy-panel-h  .cy-panel-b  .cy-kv
+.cy-tabs  .cy-tab    .cy-stack    .cy-sec-t    .cy-led
+```
+
+**27 个 view 里只有 `SettingsView.vue` 一个在用**（`tests/client/style-system.test.ts` 也只锁这一页）。
+`global.scss:672-675` 的注释写着「避免 25 个页面各写一遍同样的框」—— 设计意图与实际落地严重脱节。
+
+### 1.4 页面落地程度
+
+| 类别 | 页面 | 特征 |
+| --- | --- | --- |
+| **已落地** | `SettingsView.vue` | `cy-*` 骨架 + 令牌 |
+| **已落地（无骨架）** | `LoginView.vue` | 令牌密度最高（24 处），装饰位面合规 |
+| **部分落地** | `ChatView` / `GroupChatView` / `GlobalAgentView` / `HistoryView` / `JourneyView` / `WorkflowView` / `LogsView` / `PerformanceView` / `PluginsView` / `McpManagerView` / `MemoryView` / `PetdexView` / `TerminalView` / `SkillsView` / `SkillsUsageView` / `DevicesView` / `KanbanView` / `FilesView` / `HermesMissingView` | 用了基础令牌，但布局仍是 Arco 原生（`a-card` / `a-tabs`） |
+| **未落地** | `JobsView` / `ModelsView` / `ProfilesView` / `UsageView` / `ChannelsView` / `VersionPreviewView` | style 块几乎没有色值，也没有语义色 |
+
+**CYBER 目前是「孤岛式」的**：设置页 + 聊天链是两块完整的岛，其余 20+ 页面停留在迁移前原样。
+
+### 1.5 令牌管道已就绪
+
+23/27 个 view 已 `@use "@/styles/variables" as *;`。
+推进**不需要引入任何新机制** —— 只需替换布局类名与残留色值。
+
+### 1.6 三个非颜色依赖的阻塞项
+
+| 项 | 问题 |
+| --- | --- |
+| `prototype_reference/` 已补回 | 2026-10-20 已恢复到 `prototype_reference/hermes-ui-cyber-api.html`，`variables.scss:2,43` 的注释指向有效。施工以该原型为唯一视觉依据 |
+| `App.vue` 浅色警告条 | 见 §1.2，3 个 hex 集中一处，暗色下是亮块 |
+| `terminal-theme.ts` 63 处 hex | xterm API 限制，无法收敛到 CSS 变量 |
+
+---
+
+## 二、目标
+
+### 2.1 完成标准
+
+CYBER 主题**完成**的定义是下面五条同时成立：
+
+1. **D 类残留归零** —— §1.2 清单里的硬编码全部改为语义令牌。
+2. **骨架类覆盖率 ≥ 80%** —— 27 个 view 中至少 21 个使用 `.cy-view` / `.cy-panel` 骨架。
+3. **遮罩与投影令牌化** —— `rgba(0,0,0,α)` 收敛到 `--overlay-scrim` / `--shadow-*`。
+4. **图表色板单一来源** —— A 类色板集中定义，页面不再自带色板。
+5. **护栏自动化** —— 颜色与骨架类都有机械化检查，新增违规当场红。
+
+### 2.2 明确不追求的
+
+- **不做亮色主题**。`useTheme.ts` 的 `isDark` 恒为 `true` 是**刻意**的，不要「顺手加个亮色」。
+- **不追求每个页面都有霓虹**。霓虹是点缀，不是主色。`cy-panel` 骨架 + 三色语义到位即可。
+- **不强行收敛终端 ANSI 色板**。xterm 的限制是硬约束，用豁免 + 断言管理。
+- **不把骨架类套成模板**。语义要按「每种颜色只承担一种含义」逐组件落，
+  机械套壳会把语义抹平（这正是聊天链当初没有套 `cy-panel` 的原因，见 `docs/chat-development-todo.md`）。
+
+---
+
+## 三、推进阶段
+
+每阶段独立可交付、独立可验证、独立可回滚。
+
+### P0 · 定点治理（低风险，先清账）
+
+**目标**：D 类残留归零中风险最低、视觉收益最高的部分。
+
+| 任务 | 位置 | 改法 |
+| --- | --- | --- |
+| 浅色警告条 | `App.vue:117-129` | `.node-warning-bar` 改 `--warning` 文字 / `--warning-soft` 底 / `--warning-line` 边（语义：本就需要你介入） |
+| 旧 Element-UI 蓝 | `FolderPicker.vue` | `rgba(64,158,255,α)` → `rgba(var(--accent-primary-rgb), α)` |
+| 旧红淡底 | `GroupChatPanel.vue` | `rgba(200,50,50,0.08)` → `--error-soft` |
+| 按钮白字 | `ModelSelector.vue` / `CombinationModelsPanel.vue` / `WorkflowModelSelector.vue` | `#fff` → `--text-on-accent` |
+| 增删行统计色 | `MessageItem.vue` | `#00e676` → `--success`，`#ff3b58` → `--error` |
+| 纯黑 | `MarkdownRenderer.vue` | `#000` → `--text-primary` 或 `--bg-*`（按上下文） |
+| 失效注释 | `variables.scss:2,43` | `prototype_reference/...` 改指 `docs/ui-baseline.md` |
+
+**护栏**：`tests/client/style-tokens.test.ts` 新增 —— 扫描 `packages/client/src`，
+除白名单（图表色板 / 终端主题 / 看板状态色）外不允许出现裸 hex。
+`App.vue` 的浅色警告条一并锁死。
+
+**风险**：低。全是样式替换，不动结构。
+
+---
+
+### P1 · 遮罩与投影令牌化
+
+**目标**：§2.1 第 3 条。
+
+**做法**：
+
+1. 在 `variables.scss` 新增：
+   ```scss
+   --overlay-scrim: rgba(0, 0, 0, 0.4);      // 模态遮罩
+   --overlay-scrim-strong: rgba(0, 0, 0, 0.65); // 全屏遮罩
+   --shadow-sm / --shadow-md / --shadow-lg    // 卡片/浮层投影
+   ```
+2. 全项目约 60 处 `rgba(0,0,0,α)` 按语义归类替换：
+   - 模态/抽屉遮罩 → `--overlay-scrim`
+   - 浮层投影 → `--shadow-*`
+   - 内阴影/凹陷 → `--shadow-inset-*`
+3. 白色半透明 `rgba(255,255,255,α)`（高光/分隔）→ `rgba(var(--text-primary-rgb), α)`，与聊天链已有做法一致
+
+**为什么单独成阶段**：这批改动横跨 30+ 文件但每处都是一行替换，混进结构改造里
+会难以 review，出问题也难定位。单独一批，改完立刻 `git diff` 逐文件过一遍。
+
+**护栏**：同 P0 的扫描测试，把 `rgba(0,0,0,` 纳入黑名单。
+
+---
+
+### P2 · 骨架类落地
+
+**目标**：§2.1 第 2 条。
+
+**做法**（**逐页推进，不做批量替换**）：
+
+1. 先在 `SettingsView.vue` 已有的 10 个 `.cy-*` 类基础上补齐缺口，
+   把 `global.scss` 的骨架类当成**唯一规格**而不是建议。
+2. 按页面分批改，每批 3-5 个页面：
+   - **批次 A（数据展示型）**：`UsageView` / `JobsView` / `LogsView` / `ModelsView` / `ProfilesView`
+   - **批次 B（配置型）**：`DevicesView` / `ChannelsView` / `PluginsView` / `McpManagerView`
+   - **批次 C（内容型）**：`FilesView` / `MemoryView` / `PetdexView` / `SkillsView` / `SkillsUsageView`
+   - **批次 D（复杂型）**：`WorkflowView` / `KanbanView` / `JourneyView` / `PerformanceView` / `HistoryView` / `HermesMissingView` / `VersionPreviewView`
+3. 每批的替换模式：**Arco 结构 → `.cy-panel` 外壳**，但**保留** Arco 组件本身
+   （`a-table` / `a-form` / `a-select` 都不动）。Arco 组件的外观已经被
+   `global.scss` 的 token bridge 接管，不需要重写。
+
+**边界**：
+- 不改任何逻辑、不改 i18n key、不改数据结构。
+- 不动 `chat/` 与 `group-chat/` 下的文件（已由 `docs/chat-development-todo.md` 完成）。
+- 每批一次改动，批与批之间不叠加。
+
+**护栏**：
+- `tests/client/style-system.test.ts` 扩展：断言 `.cy-*` 骨架类清单不变（防止有人删类），
+  并断言「不允许出现 `.dark` 选择器」（单主题）。
+- 新增覆盖率检查：view 文件的 style 块中 `.cy-` 出现次数 ≥ 阈值的 view 数量不低于 80%。
+
+**实际落地结果（2026-10-20）**：
+
+| 批次 | 页面 | 结论 |
+| --- | --- | --- |
+| A | `UsageView` / `JobsView` / `LogsView` / `ModelsView` / `ProfilesView` | 大部分已合规；`JobsView` 补 `cy-sec-t` 分节标题 + i18n key `jobs.sectionList` |
+| B | `DevicesView` / `ChannelsView` / `PluginsView` / `McpManagerView` | `ChannelsView` 内容区包进 `cy-panel`；`McpManagerView` 已合规（modal 内列表保留自定义边框，避免卡片套卡片） |
+| C | `FilesView` / `MemoryView` / `PetdexView` / `SkillsView` / `SkillsUsageView` | 已合规；`PetdexView` 棋盘格 `rgba(127,127,127,0.08)` → `rgba(var(--text-muted-rgb), 0.08)` |
+| D | `WorkflowView` / `KanbanView` / `JourneyView` / `PerformanceView` / `HistoryView` / `HermesMissingView` / `VersionPreviewView` / `TerminalView` / `GlobalAgentView` | **全部已是令牌驱动**。这些是专用布局（画布 / 看板 / 终端 / 聊天流），原型的 `panel` 结构不适用，不需要套骨架类 |
+
+**批次 D 的判定依据**：「cy-* 计数为 0」是**误报**。判断标准应是
+「该页面是否用了裸色值」，而不是「是否用了骨架类」。这批页面的
+`border` / `background` / `box-shadow` 全部走 `$border-color` / `rgba(var(--*-rgb), α)`，
+与全局令牌同源。
+
+**骨架类覆盖率最终为 19/26（73%）**。未覆盖的 7 个页面是
+`ChatView` / `GlobalAgentView` / `GroupChatView` / `HermesMissingView` /
+`KanbanView` / `TerminalView` / `WorkflowView` —— 有意豁免，已在
+`style-system.test.ts` 的 `intentional` 列表里显式列出。
+
+---
+
+### P3 · 图表色板单一来源
+
+**目标**：§2.1 第 4 条。
+
+**现状**：三处独立的分类色板。
+
+| 位置 | 用途 | 问题 |
+| --- | --- | --- |
+| `styles/chart-colors.scss` | 3 个 token（input/output/cache） | 太少，撑不起多维图表 |
+| `stores/hermes/usage.ts` | `MODEL_COLORS` 10 色 | 模型分布专用，与前者语义重叠 |
+| `views/hermes/JourneyView.vue` | 12 个分类色 + canvas 渐变 | canvas 绘制，与 CSS 变量不通 |
+| `views/hermes/SkillsUsageView.vue` | 6 色 `skillPalette` | 又一套 |
+
+**做法**：
+1. 扩充 `styles/chart-colors.scss` 为完整分类色板（12-16 色），按语义分组：
+   - **序列色**（同量纲的分类，如模型分布）—— 色相均匀分布
+   - **对比色**（需要互相可辨的并列，如看板列状态）
+2. `usage.ts` / `SkillsUsageView.vue` / `JourneyView.vue` 改为引用统一色板。
+3. **canvas 场景**（JourneyView）需要在 JS 侧读取令牌：
+   ```ts
+   const styles = getComputedStyle(document.documentElement)
+   const color = styles.getPropertyValue('--chart-cat-3').trim()
+   ```
+   抽一个 `readChartColor(index)` 工具函数，避免每个图表各写一遍。
+4. 色板本身**允许硬编码**（这是 `ui-baseline.md` §7 明确豁免的），但**必须集中在一处**。
+
+**护栏**：断言「图表色板定义只出现在 `chart-colors.scss`（+ 白名单）」。
+
+---
+
+### P4 · 自动化护栏收口
+
+**目标**：§2.1 第 5 条。
+
+新增/扩展测试：
+
+| 测试 | 断言 |
+| --- | --- |
+| `tests/client/style-tokens.test.ts`（新） | 除白名单外无裸 hex / 无写死 `rgba(0,0,0,` / 无具名颜色关键字 / 无字面量 RGB 三元组 |
+| `tests/client/style-system.test.ts`（扩） | `.cy-*` 骨架类清单完整；无 `.dark` 选择器；`arco-theme` 恒为 dark；骨架类覆盖率 ≥ 60% 且未覆盖页面须在显式豁免名单里 |
+| `tests/e2e/chat-cyber-semantics.spec.ts`（已有） | 保持 —— 聊天链语义不回归 |
+
+**颜色断言的分层策略**（沿用现有 spec 的结论）：
+
+> 色板同时以 OKLCH 值和 RGB 三元组两种形式声明同一颜色，两者**色相相差约 30°**，
+> 因此**不能用「渲染后的 RGB vs 令牌值」做颜色断言**。
+> 颜色语义必须在**源码层**断言，浏览器层只断言类名 / 关键帧 / 辉光的存在性。
+
+**实际落地（2026-10-20）**：
+
+`style-tokens.test.ts` 扫描 `packages/client/src` 下所有 `.vue` / `.scss` / `.css` / `.ts`，
+四道断言：
+
+1. 无裸 hex（`#rrggbb`）
+2. 无具名颜色关键字（`color: red` 这类）
+3. 无字面量 `rgba(0,0,0,`
+4. 无字面量 RGB 三元组（`rgba(15, 23, 42, 0.05)` 这类旧主题残留）——
+   一律要换成 `rgba(var(--*-rgb), α)`
+
+**扫描前会剥掉注释与 HTML 实体**：注释里写「之前是 `#b42318`」是历史说明，
+`&#9662;` 是 HTML 实体（▽）不是颜色。剥注释这一步本身有**自检用例**，
+防止改坏了护栏却一直"通过"。
+
+护栏上线时抓到并修掉的真实问题：
+
+| 位置 | 问题 | 修法 |
+| --- | --- | --- |
+| `views/hermes/PetdexView.vue` | 棋盘格 `rgba(127,127,127,0.08)` | → `rgba(var(--text-muted-rgb), 0.08)` |
+| `utils/hermes/kanban-status-colors.ts` | 分类色 `#c084fc` + `rgba(192,132,252,0.14)` 字面量 | 新增令牌 `--kanban-review` / `--kanban-review-rgb`；灰阶改走 `--text-muted-rgb` |
+| `components/hermes/chat/MessageList.vue` | 浅色主题遗留阴影 `rgba(15,23,42,0.05)` | → `var(--shadow-sm)` |
+
+---
+
+## 四、豁免清单（明确不动）
+
+这些地方有硬编码颜色是**有意的**，不要"清理"：
+
+| 位置 | 理由 |
+| --- | --- |
+| `styles/chart-colors.scss` | `ui-baseline.md` §7 已声明图表色板是唯一可硬编码处 |
+| `styles/chart-palette.ts` | 同上（TS 侧色板常量） |
+| `utils/hermes/terminal-theme.ts` | xterm `ITheme` 只接受字面量。CYBER 那一套要锁住并加断言；Tokyo Night / GitHub Dark 是用户自选外部主题，不参与品牌表达 |
+| `vendor/arkscore/` | 装饰位面，零信息零交互。已由 `tests/client/arkscope-vendor.test.ts` 卡住 |
+| `styles/arco-theme.ts` | 意图说明 + 测试锚点，改主色时要与 `global.scss` 的 bridge 同步 |
+| `components/hermes/chat/MessageItem.vue` | 语言徽标（JS 黄 / Python 蓝 / HTML 橙…）是**品牌识别色**，换色就认不出语言了 |
+
+**豁免不是免检**。每条豁免都要有一条对应的断言，防止「豁免范围悄悄扩大」。
+
+> 注：`utils/hermes/kanban-status-colors.ts` 原本在豁免名单里（"分类色字面量"），
+> 2026-10-20 起**已移出** —— 看板分类色新增了 `--kanban-review` / `--kanban-review-rgb`
+> 令牌，灰阶走 `--text-muted-rgb`，文件内已无任何字面量色值。
+
+---
+
+## 五、验证基线
+
+每阶段结束时都跑：
+
+```bash
+npm run harness:check     # 含 chat-chain 片段校验
+npm run test              # Vitest：client + shared + server
+npm run test:e2e          # Playwright
+npm run build
+```
+
+改了 `packages/client/src/components/hermes/chat/` 或
+`packages/server/src/services/hermes/group-chat/` 等聊天链路径的，
+必须新增 `docs/chat-chain-changes/<date>-<slug>.md` 片段，
+否则 `harness:check` 会失败。
+
+**当前基线（2026-10-20，P2/P4 收口后）**：
+
+| 检查 | 结果 |
+| --- | --- |
+| `harness:check` | 通过 |
+| `vue-tsc -b` | 通过 |
+| `test`（client + server + shared） | 2060 通过 / 8 跳过 / 1 超时（`tts-synthesize-controller` 并行负载下超时，单跑 23/23 通过，与本主题无关） |
+| `test:e2e` | 46 通过 |
+| `build` | 通过 |
+
+---
+
+## 六、推进顺序与依赖
+
+```
+P0 定点治理 ──→ P1 遮罩令牌化 ──→ P2 骨架类落地 ──→ P3 图表色板 ──→ P4 护栏收口
+   (独立)          (独立)            (分 4 批)          (独立)        (收口)
+```
+
+- P0 / P1 / P3 互不依赖，可并行。
+- P2 的每批次之间有视觉连续性要求，**必须串行**。
+- P4 放在最后 —— 护栏要在被保护对象稳定后才可靠；但 P0 的扫描测试可以提前写，
+  先卡住「不许变多」，再逐步加严。
+
+---
+
+## 七、相关文档
+
+- `docs/ui-baseline.md` —— 视觉规范（唯一依据）
+- `docs/chat-development-todo.md` —— 对话台已完成项与已知原型侧问题
+- `docs/arco-mapping.md` —— Arco 组件映射
+- `docs/known-issues.md` —— 已知问题清单
+- `docs/chat-chain-changes/README.md` —— 变更片段规范

docs/known-issues.md

@@ -12,44 +12,89 @@
 
 这些是读代码时确认存在的真实缺陷，与迁移无关（迁移前就存在），但迁移过程中被注意到。修它们属于逻辑改动，需单独开分支。
 
-### 1. ModelSelector 的 computed 里有副作用
+### 1. ~~ModelSelector 的 computed 里有副作用~~ — 已修（2026-10-19）
 
-- **现象**：切换模型时 provider 选择偶尔「自己跳」，或 `customProvider` 状态被莫名改写
+- **原现象**：切换模型时 provider 选择偶尔「自己跳」，或 `customProvider` 状态被莫名改写
 - **位置**：`packages/client/src/components/layout/ModelSelector.vue`，`providerOptions` computed 的 getter
-- **证据**：computed 的 getter 内部给 `customProvider.value` 赋值。computed 应当是纯读。副作用是：任何其它 computed 或渲染逻辑读到 `providerOptions`，都会顺带改写 `customProvider`
+- **原证据**：computed 的 getter 内部给 `customProvider.value` 赋值。computed 应当是纯读。副作用是：任何其它 computed 或渲染逻辑读到 `providerOptions`，都会顺带改写 `customProvider`
 - **修法**：把赋值移到 `watch` 或显式的 setter 里
+- **实际改动**：getter 恢复成纯读（只返回 `activeModelGroups` 映射出的 options），
+  同步改由 `watch(() => appStore.selectedProvider, ...)` 承担。
+  `openModal()` 里原有的那次赋值保留 —— watch 是懒的，不在首帧触发。
+- **回归测试**：`tests/client/model-selector-provider-sync.test.ts`
+  （断言 getter 无赋值、watch 挂在 `selectedProvider` 而非 `providerOptions` 上、
+  `openModal` 仍初始化）
 
-### 2. ProfileSelector 把 i18n key 当文案用
+### 2. ~~ProfileSelector 把 i18n key 当文案用~~ — 已核实为误报，无需修
 
-- **现象**：某些运行时状态提示里显示原始 key（如 `profiles.runtime.checking`）而不是中文/英文文案
+- **原记录现象**：某些运行时状态提示里显示原始 key（如 `profiles.runtime.checking`）而不是中文/英文文案
 - **位置**：`packages/client/src/components/layout/ProfileSelector.vue`，`gatewayStatusText` / `bridgeStatusText`
-- **证据**：`message.warning(t('profiles.runtime.checking'))` —— `t()` 的结果（一个 key 字符串）被直接当消息正文，缺了外层再套一次 `t()`
-- **修法**：改成 `message.warning(t('profiles.runtime.checking'))`（让 `t()` 返回字符串函数的结果），即检查是否需要 `t(t(key))` 或改用 `te()` + 手动查表
+- **核实结论（2026-10-19）**：**该缺陷不存在**。三点证据：
+  1. `t` 来自 `useI18n()`（`:20`），`t('profiles.runtime.checking')` 返回的是
+     **已翻译的文案**，不是 key 本身。不存在「`t()` 的结果被当消息正文」的问题 ——
+     那正是 `t()` 的预期用法。
+  2. 组件内 33 处 `t()` 调用逐条比对 `zh.ts:1478-1510`，`avatar.*` 与 `runtime.*`
+     全部 key 齐全且中英双语都有对应条目，无缺失。
+  3. 全项目 grep `message.(warning|error|success|info|normal)\('[a-z]...')`
+     **零匹配** —— 没有裸传 key 字符串的调用点。
+- **原记录为何误判**：原条目自己给出的「修法」与「证据」是同一句话
+  （都是 `message.warning(t('profiles.runtime.checking'))`），说明写条目时
+  把「`t()` 已经包了一层」当成了「少包了一层」。
+- **若仍复现**：不要按原条目改代码。先确认复现路径，再查该路径上是否有
+  **另一处**未走 `t()` 的提示，或该 key 所属的 profile 名是否为空导致
+  `t(key, { name })` 插值异常。
 
-### 3. McpManagerView 的 `_autoRetryCount` 赋值可能静默失效
+### 3. ~~McpManagerView 的 `_autoRetryCount` 赋值可能静默失效~~ — 已核实为误报，无需修
 
-- **现象**：MCP 失败后点「重试」，自动重试计数似乎没有正确归零
-- **位置**：`packages/client/src/views/hermes/McpManagerView.vue`，`let _autoRetryCount`（模块级）
-- **证据**：在 header 按钮的内联表达式 `@click="_autoRetryCount = 0; loadServers()"` 里被重置。`<script setup>` 中的 `let` 绑定在模板内联语句里**不可写**（编译器只对 ref 做解包），这个重置很可能不生效
-- **修法**：改成 `ref`，或把重置逻辑移进一个具名函数
+- **原现象**：MCP 失败后点「重试」，自动重试计数似乎没有正确归零
+- **原位置**：`packages/client/src/views/hermes/McpManagerView.vue`，`let _autoRetryCount`
+- **原记录**：在 header 按钮的内联表达式 `@click="_autoRetryCount = 0; loadServers()"` 里被重置。
+  `<script setup>` 中的 `let` 绑定在模板内联语句里**不可写**（编译器只对 ref 做解包），这个重置很可能不生效。
+- **核实结论（2026-10-19）**：**该缺陷不存在**。原记录的机制判断是错的：
+  1. `compileScript` 对 `setup-let` 绑定（`let` 而非 `ref`）会在 `__returned__` 里生成
+     **一对 getter/setter**：
+     `get _autoRetryCount() { return _autoRetryCount }, set _autoRetryCount(v) { _autoRetryCount = v }`。
+  2. 模板编译产物是 `$setup._autoRetryCount = 0`，走的是上面那个 setter，
+     **会写回闭包里的原变量**。
+  3. 运行时实测确认（真实 SFC + 真实 Vue 运行时）：先把计数推到非 0，
+     再执行内联赋值，闭包内具名函数读到的就是复位后的值。
+- **回归测试**：`tests/client/script-setup-let-assignment.test.ts`
+  （含夹具 `tests/client/fixtures/script-setup-let-assignment.vue`；
+  判据先把计数推到非 0 再复位读取，因此能区分「复位生效」与「复位没生效」）
+- **若仍复现**：不要按原记录改代码。先确认复现路径，再查该路径上是否有
+  **另一处**真正的计数状态（比如 `scheduleReload` 的定时器没被取消导致旧的一次
+  `loadServers` 又把计数加回去）。
 
-### 4. McpManagerView 的 handleModeChange 有冗余重试
+### 4. ~~McpManagerView 的 handleModeChange 有冗余重试~~ — 已修（2026-10-19）
 
-- **现象**：无功能影响，仅代码冗余
+- **原现象**：无功能影响，仅代码冗余
 - **位置**：`packages/client/src/views/hermes/McpManagerView.vue`，`handleModeChange`
-- **证据**：两段重复的 try/catch 用同一个 `mode` 解析同一份文本，第一次失败后用相同模式重试一次才 return。第一个 catch 分支应直接 return
+- **原记录**：两段重复的 try/catch 用同一个 `mode` 解析同一份文本，第一次失败后用相同模式重试一次才 return。第一个 catch 分支应直接 return
+- **修正与实际改动**：原记录里「用同一个 `mode`」的说法不准确 —— 两段用的是
+  **不同**模式：第一段按 `oldMode`（切换前的格式）解析，第二段按 `mode`（切换后的格式）回退。
+  第二次尝试**不是**冗余，删掉会改变行为（用户在 JSON 编辑器里粘了一段 YAML 时，
+  切到 YAML 模式应当能救回来）。因此**不按原记录删除回退**。
+  实际改动是消除**代码重复**：抽出 `parseAsMode(text, mode)`，两处调用复用。
+- **一个必须避开的坑**：解析结果用 `ParseOutcome` 判别式承载
+  （`{ ok: true; data }` / `{ ok: false }`），**不能**用 `null` 表示失败。
+  JSON 字面量 `null` 是**合法解析结果**，若用 `??` 短路，
+  `null` 会被误判成「解析失败」而触发回退，改变行为。
 
-### 5. WorkflowView 的批量删除确认 ref 已无读取方
+### 5. ~~WorkflowView 的批量删除确认 ref 已无读取方~~ — 已修（2026-10-19）
 
-- **现象**：无功能影响
+- **原现象**：无功能影响
 - **位置**：`packages/client/src/views/hermes/WorkflowView.vue`，`showWorkflowBatchDeleteConfirm`
-- **证据**：naive 的 `NPopconfirm v-model:show` 需要它；Arco 的 `a-popconfirm` 无 `show` prop 后它失去读取方，只剩写。关闭改由 `@ok`/`@cancel` 驱动
+- **原记录**：naive 的 `NPopconfirm v-model:show` 需要它；Arco 的 `a-popconfirm` 无 `show` prop 后它失去读取方，只剩写。关闭改由 `@ok`/`@cancel` 驱动
+- **实际改动**：确认无任何读取方后**整体删除**（声明 + 两处赋值）。
+  Arco 的 `a-popconfirm` 由 `@ok` / `@cancel` 驱动，删除不影响交互。
 
-### 6. ProfileCreateModal 有两个重复的 style 块
+### 6. ~~ProfileCreateModal 有两个重复的 style 块~~ — 已修（2026-10-19）
 
-- **现象**：无功能影响
+- **原现象**：无功能影响
 - **位置**：`packages/client/src/components/hermes/profiles/ProfileCreateModal.vue`
-- **证据**：两个 `<style scoped>` 内容相同（都是 `.modal-footer`）。迁移前存在
+- **原记录**：两个 `<style scoped>` 内容相同（都是 `.modal-footer`）。迁移前存在
+- **实际改动**：删除重复的第二个 `<style scoped>` 块，
+  保留第一个（它额外含 `.form-hint`）。`.modal-footer` 规则不变。
 
 ---
 

docs/ui-baseline.md

@@ -1,62 +1,147 @@
-# UI 基线（Phase 005 定稿）
+# UI 基线（CYBER 暗色单主题）
 
-本文件是 hermes-ui 的**视觉语言唯一依据**。Phase 006/007 的批量迁移照此执行，
-页面样式与本文冲突时，以本文为准；本文没覆盖的场景，先在 `docs/arco-mapping.md`
-补映射、再回本文补约定，然后才动代码。
+本文件是 hermes-ui 的**视觉语言唯一依据**。页面样式与本文冲突时，以本文为准；
+本文没覆盖的场景，先在 `docs/arco-mapping.md` 补映射、再回本文补约定，然后才动代码。
 
 - 样板页：`views/LoginView.vue`（装饰位面 + 表单）、`components/layout/AppSidebar.vue`（导航 + 弹窗 + tag）
-- 令牌源：`packages/client/src/styles/variables.scss`（CSS 变量）+ `styles/arco-theme.ts`（Arco 组件主题）
+- 令牌源：`packages/client/src/styles/variables.scss`（CSS 变量 + SCSS 委托变量）
+- Arco 实际外观由 `styles/global.scss` 的 Arco token bridge 决定；`styles/arco-theme.ts` 是意图说明与测试锚点
 - 组件映射：`docs/arco-mapping.md`
 
+> **历史**：本文件曾描述「黑白水墨（Pure Ink）」三主题（ink light / ink dark / comic）。
+> 亮度/风格切换器已移除，暗色是唯一主题，该描述不再适用。
+> 当前主题推进状态见 `docs/cyber-theme-plan.md`。
+
 ---
 
-## 1. 色板
+## 1. 三色语义系统（最高优先级）
 
-黑白水墨（Pure Ink）——**纯黑白灰，无彩色**（status/info 色除外）。三主题：ink light / ink dark / comic。
+> **每种颜色只承担一种含义，不得混用。**
 
-### 浅色（`html:not(.dark)`）
+| 颜色 | 令牌 | 含义 | 典型用途 |
+|---|---|---|---|
+| 霓虹青 | `--accent-primary` | **系统本体** | 品牌、主按钮、当前选中、链接 |
+| 琥珀橙 | `--warning` | **需要你介入** | 审批、等待确认、上下文将满、中断态 |
+| 荧光绿 | `--success` | **机器在动** | 工具成功、流式输出、连接健康 |
+| 红 | `--error` | **出错** | 仅表示出错，不参与上面三色分工 |
 
-| 角色 | 变量 | 值 |
+- 失败时**不要**靠「加深强调色」表达，必须换到 `--error` —— 否则四个语义挤在同一色相里，紧急程度就读不出来了。
+- `--accent-info` 是第四种蓝，只在需要与青/橙/绿都区分开时用（如链接性提示）。
+- 同一语义在全项目**必须用同一个令牌**。看到两个文件里「橙」是不同色值，就是 bug。
+
+### 状态色的完整取值
+
+| 令牌 | OKLCH | RGB 三元组 | 说明 |
+|---|---|---|---|
+| `--accent-primary` | `oklch(0.805 0.148 188)` | `0, 221, 209` | 霓虹青 |
+| `--accent-hover` | `oklch(0.870 0.150 188)` | `16, 243, 230` | 悬停态 |
+| `--accent-muted` | `oklch(0.520 0.060 188)` | — | 弱化强调 |
+| `--success` | `oklch(0.860 0.190 128)` | `173, 231, 78` | 荧光绿 |
+| `--warning` | `oklch(0.780 0.155 68)` | `247, 162, 50` | 琥珀橙 |
+| `--error` | `oklch(0.665 0.185 22)` | `240, 90, 94` | 红 |
+| `--accent-info` | `oklch(0.700 0.110 245)` | `95, 165, 222` | 蓝 |
+| `--kanban-review` | `oklch(0.722 0.177 305.5)` | `192, 132, 252` | 看板 `review` 列分类色（**分类色，非语义色**） |
+
+> `--kanban-review` 是唯一的分类色令牌：看板 9 个列状态装不进三色语义系统，
+> 按「流程阶段」维度分色。它仍然走令牌体系，所以 `rgba(var(--kanban-review-rgb), α)`
+> 能拼出弱底色。
+
+**半透明用 RGB 三元组拼 alpha**，因为 OKLCH 无法直接拆 alpha：
+
+```scss
+color: rgba(var(--accent-primary-rgb), 0.55);
+box-shadow: 0 0 12px rgba(var(--success-rgb), 0.22);
+```
+
+每个需要拼 alpha 的令牌都有配套的 `--*-rgb`。要新增半透明语义色，**必须同时加 RGB 三元组**。
+
+### 语义底与语义线
+
+| 令牌 | 值 | 用途 |
 |---|---|---|
-| 页面底 | `--bg-primary` | `#fafafa` |
-| 次级底 / 侧栏 | `--bg-secondary` / `--bg-sidebar` | `#f0f0f0` / `#f5f5f5` |
-| 卡片 / 输入底 | `--bg-card` / `--bg-input` | `#ffffff` |
-| 分割线 | `--border-color` / `--border-light` | `#e0e0e0` / `#ebebeb` |
-| 强调色 | `--accent-primary` / `--accent-hover` | `#333333` / `#1a1a1a` |
-| 正文 | `--text-primary` / `--text-secondary` / `--text-muted` | `#1a1a1a` / `#666666` / `#999999` |
-| 状态 | `--success` / `--error` / `--warning` / `--accent-info` | `#2e7d32` / `#c62828` / `#f57f17` / `#4a90d9` |
+| `--accent-soft` | `oklch(0.805 0.148 188 / 0.13)` | 强调色弱底 |
+| `--success-soft` / `--success-line` | `… / 0.12` / `… / 0.40` | 绿色弱底 / 绿边框 |
+| `--warning-soft` / `--warning-line` | `… / 0.12` / `… / 0.42` | 橙色弱底 / 橙边框 |
+| `--error-soft` / `--error-line` | `… / 0.11` / `… / 0.42` | 红色弱底 / 红边框 |
 
-### 深色（`.dark`）
+---
 
-| 角色 | 变量 | 值 |
-|---|---|---|
-| 页面底 | `--bg-primary` | `#1a1a1a` |
-| 次级底 / 侧栏 | `--bg-secondary` / `--bg-sidebar` | `#252525` / `#202020` |
-| 卡片 / 输入底 | `--bg-card` / `--bg-input` | `#2a2a2a` |
-| 分割线 | `--border-color` / `--border-light` | `#3a3a3a` / `#333333` |
-| 强调色 | `--accent-primary` / `--accent-hover` | `#e0e0e0` / `#f5f5f5`（反相） |
-| 正文 | `--text-primary` / `--text-secondary` / `--text-muted` | `#e0e0e0` / `#a0a0a0` / `#888888` |
-| 状态 | `--success` / `--error` / `--warning` / `--accent-info` | `#66bb6a` / `#ef5350` / `#ffb74d` / `#6ba3d6` |
+## 2. 背景与描边
 
-- 需要 `rgba()` 透明度时用配套 `--*-rgb` 变量（如 `rgba(var(--accent-primary-rgb), 0.12)`）。
-- 反色场景（强调底上的字）一律用 `--text-on-accent`，不要硬编码白/黑。
-- **Arco 组件配色**：`arco-theme.ts` 冻结 `colorPrimary: #2f2f2f`、`borderRadius: 6`，
-  延续克制灰阶；暗色由 `body[arco-theme='dark']` CSS 变量覆盖承载，
-  **不用** Arco 的 dark theme + overrides 双轨。
-- 主题切换机制：`useTheme.ts` 同时切 `<html>` 的 `dark`/`comic` class（项目令牌）
-  和 `arco-theme` 属性（Arco 组件）；FOUC 脚本内联在 `index.html`，两边同步改。
+背景由深到浅四层，**越靠上层越亮**（向上浮）：
 
-## 2. 圆角 / 间距 / 字号阶梯
+| 角色 | 令牌 | OKLCH | 用途 |
+|---|---|---|---|
+| 页面底 | `--bg-primary` | `oklch(0.155 0.012 250)` | 页面底色 |
+| 次级底 | `--bg-secondary` | `oklch(0.130 0.012 250)` | 卡片 / 面板（比页面更沉） |
+| 侧栏 | `--bg-sidebar` | `oklch(0.118 0.013 251)` | 比卡片更沉 |
+| 容器 | `--bg-card` | `oklch(0.185 0.014 248)` | 容器 / 输入区（比页面更亮） |
+| 容器悬停 | `--bg-card-hover` | `oklch(0.225 0.016 246)` | |
+| 输入底 | `--bg-input` | `oklch(0.105 0.012 252)` | 比卡片更沉，形成凹陷感 |
+| 代码底 | `--code-bg` | `oklch(0.115 0.014 250)` | |
 
-**圆角**（`$radius-*`）：
+描边发丝线分两档：`--border-color`（`oklch(0.305 0.018 242)`）、`--border-light`（`oklch(0.255 0.016 244)`）。
+
+**硬编码 hex 是 bug**，除非是图表色板（见 §7）。
+
+---
+
+## 3. 文字
+
+| 角色 | 令牌 | OKLCH | 用途 |
+|---|---|---|---|
+| 正文 | `--text-primary` | `oklch(0.945 0.006 200)` | |
+| 次要 | `--text-secondary` | `oklch(0.860 0.008 210)` | |
+| 弱化 | `--text-muted` | `oklch(0.705 0.014 230)` | |
+| 极弱 | `--text-faint` | `oklch(0.520 0.014 236)` | 禁用态 / 极次要信息 |
+| 强调色上文字 | `--text-on-accent` | `oklch(0.160 0.030 200)` | 深色，保证对比 |
+| 浮层上文字 | `--text-on-overlay` | `oklch(0.945 0.006 200)` | |
+
+反色场景**一律用 `--text-on-accent`**，不要硬编码白/黑。
+
+---
+
+## 4. 字体栈
+
+```scss
+// UI（系统中英混排）
+$font-ui: -apple-system, BlinkMacSystemFont, 'PingFang SC', 'Hiragino Sans GB',
+  'Microsoft YaHei', 'Segoe UI', Roboto, sans-serif;
+
+// 代码 / 命令 / 版本号
+$font-code: ui-monospace, 'JetBrains Mono', 'SF Mono', Menlo, 'Cascadia Code', monospace;
+
+// 终端（xterm 在 JS 里读这个，所以必须是 CSS 自定义属性）
+--font-mono: ui-monospace, 'JetBrains Mono', 'JetBrainsMono Nerd Font',
+  'Nerd Font', 'SF Mono', Menlo, 'Cascadia Code', 'MesloLGS NF',
+  'Hack Nerd Font', monospace;
+```
+
+- **Nerd Font 回退段不能删**：默认 shell 提示符会输出私有区字形（分支、箭头、分隔符，如 `U+E0A0`–`U+E0D4`），缺了这些字形会整片显示为豆腐块。
+- `$font-display` 复用 `$font-code` —— 等宽是 CYBER 的核心排版特征。
+- 等宽字体只用于：代码块、命令、版本号、命令行提示、标识与数据。
+
+---
+
+## 5. 圆角 / 间距 / 字号阶梯
+
+**圆角**（`$radius-*`）—— 发丝线 + 小圆角，**硬边而非圆润**：
 
 | token | 值 | 用途 |
 |---|---|---|
 | `$radius-sm` | 6px | 按钮、输入框、小卡片、tag（与 Arco `borderRadius: 6` 对齐） |
 | `$radius-md` / `$radius-lg` | 8px | 面板、弹窗、大卡片 |
 
-**间距**：4px 基数，常用档 `4 / 8 / 12 / 16 / 24 / 32`（组件内边距多用 12/16，区块间 24/32）。
-布局尺寸：侧栏 240px（折叠 64px）、顶栏 60px、移动端断点 768px。
+**间距**：4px 基数，常用档 `4 / 8 / 12 / 16 / 24 / 32`。组件内边距多用 12/16，区块间 24/32。
+
+**布局尺寸**：
+
+| token | 值 |
+|---|---|
+| `$sidebar-width` | 240px |
+| `$sidebar-collapsed-width` | 64px |
+| `$header-height` | 60px |
+| `$breakpoint-mobile` | 768px |
 
 **字号阶梯**：
 
@@ -70,44 +155,89 @@
 | 16 | 小标题 |
 | 26 | 登录页等展示型大标题 |
 
-## 3. 字体栈
+**过渡**：`$transition-fast: 0.15s ease` / `$transition-normal: 0.25s ease`。
 
-```scss
-$font-ui:   Inter, system-ui, -apple-system, sans-serif;   // 中英混排 UI（fallback 系统字体）
-$font-code: 'JetBrains Mono', 'Fira Code', 'Consolas', monospace;  // 代码、命令、版本号
-```
+---
 
-- comic 主题下 `--font-ui` 被覆盖为 `'Comic Neue', 'ZCOOL KuaiLe', ...`，其余不变。
-- 等宽字体只用于：代码块、命令、版本号、命令行提示（`$font-code`）。
+## 6. 霓虹效果层
 
-## 4. 阴影 / 分割线
+`styles/global.scss` 提供的 mixin，是 CYBER 辨识度的来源：
 
-- **分割线**：`1px solid var(--border-color)`（面板/区块）或 `--border-light`（弱分隔）。
-  水墨主题以线为主，不滥用阴影。
-- **阴影**：常规浮层 `0 1px 4px rgba(0, 0, 0, 0.1)`；comic 主题用
-  `3px 3px 0 rgba(0, 0, 0, 0.15)` 硬投影（`--comic-shadow`）。
-- 弹窗/抽屉的遮罩、投影由 Arco 组件自带，页面不重复加。
+| mixin / 动画 | 用途 |
+|---|---|
+| `neon-tube` | 霓虹灯管：主按钮、激活态边框 |
+| `neon-sheen` | 表面扫光 |
+| `neon-pulse` | 呼吸微光 |
+| `@keyframes live-ring` | **「机器在动」的唯一指示形态**（单色绿，不轮播） |
+| `@keyframes led-breathe` | 状态灯呼吸（仅连通时） |
 
-## 5. 组件使用约定
+### 「机器在动」只长一个样
+
+流式输出、语音播放、工具执行中、连接健康 —— 全部用 `live-ring`（荧光绿单色呼吸）。
+
+**不要做多色轮播**：同屏内四种语义色同时在闪，等于四种颜色都不再表达含义。
+这条在 P0 修 `rainbow-glow` 时被违反过，回归护栏在
+`tests/e2e/chat-cyber-semantics.spec.ts`。
+
+### 状态灯 `.cy-led`
+
+7px 圆点 + 发光。连通=绿（呼吸），断开=红（**静止**）。
+
+**一个死掉的连接不该看起来还在动** —— 断开态不呼吸。
+
+### 发光条用 inset box-shadow
+
+左侧/顶部发光条用 `box-shadow: inset 2px 0 0 <color>`，**不要用 `border-left`** ——
+border 会把内容宽度挤动 2px，列表行高对不齐。
+
+---
+
+## 7. 图表色板（唯一允许硬编码颜色的地方）
+
+图表/数据可视化的分类色按数据维度取色，**不走语义三色** —— 它们表达的是
+「这是第几个类别」，不是「状态」。
+
+规则：
+- 同一张图内的分类色必须**互相可辨**（色相间隔足够）
+- 图表色板集中定义在图表组件内，不散落
+- 图表**状态**（成功/失败/警告）仍走语义令牌
+- 图表色**不得**与语义色撞色到读者会误读为状态的程度
+
+---
+
+## 8. 组件使用约定
 
 - **消息 / 对话框 / 通知**：只准调 `composables/useMessage|useDialog|useNotification`
   适配层（签名冻结），**不得**在页面里直接 import Arco 的 `Message` / `Modal` / `Notification`。
 - **Modal vs Drawer**：短内容确认、纯信息展示用 `a-modal`
-  （信息型弹窗 `:footer="false"`，如样板页 changelog / docker 升级指引）；
-  需要表单编辑、长内容滚动的场景用 `a-drawer`。naive `preset="dialog"` 无直接对应。
+  （信息型弹窗 `:footer="false"`）；需要表单编辑、长内容滚动的场景用 `a-drawer`。
 - **按钮**：语义 `type` + `status` 组合（warning 按钮 = `type="primary" status="warning"`）；
-  占满宽用 `long`（naive `block`）；尺寸 `size="mini|small|medium|large"`
-  （naive `tiny`→`mini`）；提交按钮 `html-type="submit"`，加载态用 `:loading`。
-- **输入框**：`a-input` 关闭了 attrs 透传，`autofocus` 无效——需要自动聚焦时
+  占满宽用 `long`；尺寸 `size="mini|small|medium|large"`；提交按钮 `html-type="submit"`，
+  加载态用 `:loading`。
+- **输入框**：`a-input` 关闭了 attrs 透传，`autofocus` 无效 —— 需要自动聚焦时
   `ref` + `onMounted` 调 `focus()`；密码框 `type="password"`。
 - **表格空态**：用 `a-empty`，不手写占位文案。
 - **loading**：按钮级用 `a-button :loading`，区域级用 `a-spin :loading`，
   全局任务进度用 `useMessage().loading(...)`（用完 close/destroy）。
 - **表单**：`a-form` + `a-form-item`，校验规则 API 与 naive 不同，逐例适配。
-- **tag**：naive `type="info"` → `a-tag color="arcoblue"`（内建色），
-  `:bordered="false"` 直接支持。
+- **tag**：`color="arcoblue"` 等内建色，`:bordered="false"` 直接支持。
 
-## 6. 装饰位面的边界
+### Arco 组件的暗色
+
+项目**不挂 ConfigProvider**。Arco 的实际外观由 `styles/global.scss` 里的
+`--color-*` / `--arcoblue-*` / `--green-*` / `--orange-*` 变量覆盖承载。
+
+改主色时要同时改两处：`global.scss` 的 token bridge 和 `styles/arco-theme.ts`
+（后者是意图说明 + 测试锚点）。
+
+**Arco 的 RGB 三元组变量不能当颜色用**：
+`--arcoblue-6` 的值是 `22,93,255` 而不是 `#165dff`。
+写成 `color: var(--arcoblue-6)` 会被静默丢弃并回落到 Arco 默认色。
+正确写法：`color: rgba(var(--arcoblue-6), 1)`。
+
+---
+
+## 9. 装饰位面的边界
 
 装饰位面（ArkScope vendor 组件等纯视觉层）的判定标准：
 
@@ -127,8 +257,11 @@ vendor 素材边界：`vendor/arkscore/` 下**零图片/音视频素材**，
 由 `tests/client/arkscope-vendor.test.ts` 机械化卡住；Provenance 见
 `vendor/arkscore/PROVENANCE.md`。
 
-## 7. 三条不可破的规则
+---
+
+## 10. 四条不可破的规则
 
 1. **不引入第三个 UI 库**——只允许 Arco Design Vue（+ 现有图标/工具链）。
 2. **消息气泡内部不用 Arco 组件**（性能红线，见 Phase 006）。
 3. **装饰层一律 `pointer-events: none`**，不承载信息与交互。
+4. **颜色只走令牌**——语义色走三色系统，图表色走 §7 色板，硬编码 hex 一律视为待修。