4.7 KiB
Agent Note: TUI 启动横幅品牌渐变
Status: implemented
English | 中文
问题
TUI 启动横幅原本用调色板的扁平强调色渲染产品名 DEEPSEEK，它不承载任何品牌标识，也不像 deepseek.com 上的字标。需求明确是让横幅匹配站点 logo 的蓝色渐变——而不是给整个 coding harness 重新上色。
横幅是唯一在意这件事的界面，而它与一条承重不变量冲突：TUI 调色板刻意做到主题无关。它只使用标准 16 色 ANSI（SGR）代码与属性，好让用户的终端配色方案能够重映射每一种颜色；themeViolations() 快照门禁会拒绝任何 RGB、扩展调色板或显式背景色的单元格。用 16 种调色板颜色无法拼出平滑的、与 logo 一致的渐变，因此复现它需要 24 位真彩色（truecolor），而门禁按设计会将其标记出来。
决策
横幅用逐字母的 24 位真彩色前景色渲染 DEEPSEEK，沿 deepseek.com 品牌渐变——#4D6BFE → #3982FF → #2498FF——在这三个色标之间做分段线性插值；HARNESS 保持加粗并使用默认前景色。渐变仅作用于前景色，因此在任何终端背景上都保持可读，并且被限制在横幅的产品名内。这是主题无关调色板唯一获准的例外；其余每个界面都保持标准 ANSI 且随主题自适应。
渐变以 resolved.color && resolved.truecolor 为开关。当真彩色不可用时，横幅回退到既有的扁平亮蓝强调色，因此除非显式启用真彩色，主题无关保证与已录制的快照都不会改变。
truecolor 是一个经校验的 Config 字段，schema 不设默认值。当它未设置时，apply() 会在进程边界从 COLORTERM（truecolor 或 24bit）自动探测；显式的配置值始终优先。探测只在 apply() 中读取 process.env——绝不在纯粹的 resolveTuiConfig 解析器中——从而让解析器保持为其输入的纯函数。
渐变色标是固定的品牌标识，被当作协议常量对待，因此硬编码在插件里，而不作为可调项暴露。是否启用真彩色则随终端与部署而变，所以那才是经校验的 Config 字段。横幅文本仅面向界面，永不进入任何模型请求，因此不需要会话事件。
测试
一个专门的 banner-gradient 终端快照在 xterm 模拟器中固定了真实的逐字母 RGB 输出（fg=#4d6bfe…#2498ff，每个字母加粗）。共享的 checkpoint() 辅助函数接受一个 bannerGradient 标志：仅对该 checkpoint，它断言主题违规项非空，且每一项都以 rgb-fg 结尾——即真彩色确实存在，但被限制在横幅前景色，没有背景色或扩展调色板的泄漏。其余每个 checkpoint 都保持严格的 themeViolations() .toEqual([]) 断言，因此这道围栏是机械强制的。一个 tui.spec.ts 单元测试在同时启用 color 与 truecolor 时挂载，以覆盖 header 的渐变分支以及 gradientText/brandColorAt 辅助函数。
曾考虑的替代方案
用 16 色调色板拼出的主题安全阶梯渐变。 用亮蓝的调色板变体近似这段渐变可以让横幅完全保持主题无关，并避免触碰门禁。它被需求方否决了：16 种固定颜色无法复现平滑的 logo 渐变，而需求明确是匹配站点字标。
给整个 harness 调色板重新上蓝色。 最初的说法是"把 harness 颜色改成蓝色"。它被收窄到只改横幅；全局蓝色调色板会在各处而非仅一个品牌界面上破坏主题无关性。
始终发射真彩色。 许多终端不支持 24 位，会渲染出原始或降级的代码。以探测为开关并配以 ANSI 回退，能让横幅在各处都正确，同时仍在支持的地方展示渐变。
在 resolveTuiConfig 内探测真彩色。 该解析器是纯粹的默认值填充步骤，绝不能读取 process.env。环境探测属于 apply() 中的进程边界，从而让 mountTui/createTuiChat 完全由其配置输入驱动，并在使用假终端时保持完全可测。
后果
现在横幅会在真彩色终端上承载 DeepSeek 品牌标识，而主题无关保证在其余各处依然成立——甚至当真彩色不可用时在横幅自身上也成立。代价是主题无关不变量上一道狭窄且有记录的裂缝：一个不会随用户终端配色方案自适应的固定颜色界面，之所以接受，是因为它是品牌标识且仅作用于前景色，从而在浅色与深色背景上都保持可读。这道裂缝由 banner-gradient 快照断言把守，它将真彩色限制在横幅前景色，一旦其他任何 RGB、扩展调色板或背景色出现就会失败。