Oolong 品牌
语言：English | 简体中文
状态：品牌基础与命名指南。本文记录这个名字意味着什么、Oolong 如何描述自己，以及品牌语言必须止步于哪里。技术契约仍以架构文档为准。
1. 品牌核心
Oolong 是为持续有输出到来的界面准备的安静基础设施。
它的核心承诺是：
流可以很长，活动界面始终有界。
已完成的输出向前流动，进入终端拥有的历史。只有仍然开放、仍在变化或刻意需要交互的工作保持活动。品牌应当让这种流动显得自然，但不能把实现变成隐喻。
Oolong 应当让人感到：
- 流动，因为数据增量到来；
- 有界，因为会话年龄不会变成活动 UI 成本；
- 安静，因为空闲界面不做工作，也不写字节；
- 温暖，因为它服务于真正使用终端的人，而不是一个渲染演示；
- 精确，因为所有权、顺序、失败和依赖方向都很明确；
- 可组合，因为应用组合行为，而不是进入一个封闭框架。
2. 名字
2.1 正式拼写
在正文里，产品名写作 Oolong；在仓库名、模块路径、命令以及采用小写的文字标识中写作 oolong。
ooloog 不是另一种拼写。连续的圆形确实更有视觉动势，但它看起来像错别字，会失去真实单词的联想，也让发音、搜索和记忆更困难。文字标识可以让字母彼此流动，但 n 必须仍然能被明确识别为 n。
2.2 从左向右的流
小写单词可以这样阅读：
oo l o ng
上游流动 -> 处理与所有权边界 -> 有界活动界面 -> 终端与历史- 开头的
oo像上游连续到来的 chunk； - 竖直的
l像一条窄的处理与所有权边界； - 后面的
o像唯一那份有界、仍然活动的呈现； - 结尾的
ng把单词继续带向终端表面，g的下伸部分还可以让人联想到输出越过视口，继续进入 scrollback。
这是一个视觉故事，不是首字母缩略词，也不是技术状态机。它可以指导文字标识或一段小型动效，但不应当被强塞进项目的每一次介绍里。
2.3 oo + long
这个单词还可以自然地读成 oo 加 long：一条流可以运行很久，却不需要让活动界面同样长久地增长。这是名字与流式优先架构之间最强的联系。
这是一项架构主张，不是装饰。只有当已交付载荷离开组件图、增量变换只保留短小的开放尾部、工作量由活动界面而不是会话年龄决定时，Oolong 才配得上这句话。
2.4 茶的联想
乌龙茶让这个名字温暖而容易记住。水流经过茶叶，内容随时间逐渐释放，可以作为增量变换的一幅温和次要意象。它不是主要的技术解释，也绝不能成为代码库的分类体系。
3. 定位
3.1 正式描述
完整的技术描述使用：
Oolong 是面向 Go 的流式优先终端 UI 底座。
空间有限时使用：
面向 Go 的流式优先终端 UI。
“底座”是刻意选择的词。Oolong 提供终端、发布、交互、布局、文本、headless 行为与精致组件这些基础，但不要求每个应用采用同一种产品语法或同一种声明式撰写模型。
3.2 信息顺序
介绍 Oolong 时，按照这个顺序说明：
- 输出可以持续增量到来。
- 已完成的输出成为终端 scrollback，而不是永久的活动 UI 状态。
- 一个 goroutine 拥有普通的可变领域对象。
- Headless 行为与精致外观在不同层中组合。
- 下层包保持通用，依赖保持单向。
不要从 widget 目录、与另一个框架的比较或内部渲染技术讲起。那些是后果和实现选择。输出的生命期才是差异所在。
3.3 主张及其证明
| 品牌主张 | 所需的技术事实 |
|---|---|
| 流式优先 | 增量摄入与变换；顺序、批量、背压、取消和收尾都明确 |
| 有界 | 已交付载荷与逐项放置状态离开活动图；内存与尺寸变化成本不跟随会话年龄 |
| 终端原生 | 已完成输出发布进 scrollback，不会仅仅为了让程序能够重画而继续保留 |
| 可组合 | headless 行为、精致的 kit 组件和产品语法保持分离并且单向依赖 |
| Go 原生 | 具体领域对象、消费方定义的接口、可用的零值、显式错误，并且没有框架式服务定位器 |
| 安静 | 没有无条件帧时钟，没有重复的空闲字节，定时器生命期明确 |
品牌宣传不得跑在这些可执行事实前面。如果其中一项暂时不成立，就修复实现或收窄主张，不要靠解释把矛盾抹掉。
4. 组件叙事
面向应用的公开组件叙事分为三层：
headless 行为 -> 精致的 kit 组件 -> 应用产品语法- Headless 意味着完整的交互行为和带类型的语义状态，但不强制外观。Base UI 与 Radix UI 是有价值的参考。
- Kit 意味着在 headless 部件之上提供易用、好看、可主题化的组合。这是 Oolong 吸收的 shadcn 经验：优秀的默认值，以及通向成品界面的更短路径。
- 应用意味着共享库不得吸收的产品专用流程和语言。
Oolong 不采用源码复制作为组件分发模型。kit 是正常 import、正常版本化的 Go 代码。精致的默认组件仍然对组合保持开放：当调用方需要不同结构时，可以取得底层控制器和语义部件。
5. 语气与写作
Oolong 应当像一个经过深思熟虑的基础设施库那样写作：直接、平静、具体，并带一点温度。
5.1 优先
- 先说一个类型或决定能带来什么；
- 解释一条边界为什么存在，尤其是签名本身无法说明的时候；
- 先用普通词，再使用架构术语；
- 明确说出所有权、生命期、顺序和失败；
- 区分当前行为、必需方向和可选的未来工作；
- 用小型示例线性展示正常路径；
- 用复杂度或测量结果表达性能主张。
5.2 避免
- “极速”“革命性”“魔法”之类的炒作；
- 主要通过贬低另一个项目来定义 Oolong；
- 不说明实际数据流就使用“响应式”或“声明式”；
- 在无法描述失败与执行方式时，把一项政策叫作不变式；
- 在严肃 API 文档中使用茶的双关语；
- 把可选的未来层说成已经存在。
温度应当来自行文节奏、示例、插图和名字本身。当读者需要做技术决定时，精确仍然优先。
6. 视觉方向
Oolong 有两种正式标志。当空间足够、名称能够清晰阅读时使用字母标；在导航、 favicon、应用启动器和其他小型方形界面中使用紧凑图标。
6.1 文字标识
首选文字标识是小写的 oolong。它在终端字号下必须仍然一眼可读。
最值得使用的视觉特征是：
- 圆润的
o，像流里连续的单元； - 清晰竖直的
l，可以作为处理或所有权边界； - 从左向右连续的间距，而不是封闭徽章；
- 不会认错的
n，保住正确拼写； - 下伸的
g，可以暗示内容继续进入历史。
字母故事应当可以被发现，而不是直接画成 Logo 里的架构图。可读性优先于巧思。
6.2 动效
如果品牌需要动效，运动应当表达架构：
- 小单元从左侧到来；
- 它们越过一条窄边界；
- 一个活动单元发生变化；
- 已稳定的单元继续进入安静的历史。
转移完成后，运动应当停止。一个永远运动的空闲 Logo 会与产品安静、事件驱动的性格相抵触。动效还必须有 reduced-motion 或静态版本。
6.3 颜色与对比度
温暖的茶色或琥珀色强调色，可以让 Oolong 区别于偏冷的终端工具配色。中性的墨色、炭色、米白，以及终端原生前景与背景应当承担界面的大部分内容。
任何含义都不得只依赖颜色。文字标识和图表必须能在单色下工作，组件主题也必须在真实终端色深中保持可读对比度。具体色板数值属于未来的视觉资产规格，不属于架构或核心包。
7. 隐喻的边界
品牌可以使用流动和茶的意象。公开 Go API 使用领域语言。
优先使用这样的名字：
Stream、Decoder、Transcript、Commit、Frame、Runtime和Dispatcher；Editor、Dialog、List，以及其他直接描述用户所需行为的名字。
不要仅仅为了呼应产品名，就引入 Brew、Steep、Cup、Leaf 或 Infusion。一个让用户必须先翻译隐喻才能理解操作的名字，就是抽象泄漏。
同一条规则也适用于字母的视觉故事。oo、l、o 和 ng 不会成为包名、协议阶段或导出状态常量。品牌含义可以解释系统；它不能用上层词汇指导下层。
8. 标准文案
仓库描述
面向 Go 的流式优先终端 UI 底座。
简短介绍
Oolong 围绕输出的生命期构建终端界面。开放内容保持活动和可交互；已完成内容流入终端 scrollback，让长时间运行的会话保持增量和有界。
组件介绍
把完整的 headless 行为与精致、可主题化的组件组合起来，再把产品专用流程留在应用里。
辅助短句
流可以很长，活动界面始终有界。
这些句子可以为了版面缩短，但不能被“构建漂亮的 TUI”之类的通用主张取代。外观很重要；生命期模型才让 Oolong 与众不同。
9. 品牌评审清单
发布 README、网站、release 页面、示例、Logo 或演讲之前，检查：
- 名字是否写作
Oolong或oolong，而不是ooloog？ - 第一条技术描述是否包含流式优先和面向 Go 的终端 UI？
- “流式”是否意味着增量生命期与发布，而不只是文字动画？
- 有界性是否被表达成经过测试的架构属性，而不是一种氛围？
- headless 行为、精致的
kit组件和应用语法是否清楚分离？ - 视觉流动是否从左向右，并在完成之后静止？
n是否清楚可辨，并且标识能否在没有颜色或动效时工作？- 性能和兼容性主张是否由仓库实际存在的关卡支撑？
- 茶和字母隐喻是否留在了包与 API 命名之外？
- 文案听起来是否平静而精确，而不是夸张或防御？