所有位置方案共用这一套状态语言和 icon 注册表。这一页是它的规格书——落地时按这里 实现；决策 1 / 决策 2 只决定「列表挂在哪」，不重新定义状态。决策 5 决定用点还是文字。
四种状态占同一个 14×14 盒子，点态在盒子里居中缩小——否则列表 行会随状态变化左右抖动。形态而非只有颜色承担区分（色盲可用）： 快转缺口环 = 机器在忙、慢转虚线圈 = 等你动手、实心点 = 静态结论。
error > todo > running > unread：需要你动手的信号 永远盖过机器自己在忙。主行是对话标题，副行是 subject（页面 icon + 标题，弱化）。进行中时副行文字换成实时说明、icon 保留——"在跑什么"比"几分钟前" 有用得多，而 icon 保证页面身份不丢。
这就是「subject card 很多页面没做 icon」的解法：不要每个页面各自决定画 什么，由 kind 决定。有头像用头像，没有就回落到 kind 的 icon，永远有东西 可画。注册表是 Record<SubjectKind, …>，没有 default 分支—— 新增 kind 时 TypeScript 会报错，逼着补齐。
channel内容grain页面page搜索search用户user连接器connector创建creation生产记录run发消息 / 触发任务
│
▼
┌────────┐ 需要用户提交卡片 ┌────────┐ 用户提交 ┌────────┐
│running │ ─────────────────► │ todo │ ──────────► │running │
└────────┘ └────────┘ └────────┘
│ 跑完 │
▼ ▼
┌────────┐ 用户打开看过 ┌────────┐ （回到上面）
│ unread │ ────────────────► │ none │
└────────┘ └────────┘
▲
│ 失败
┌────────┐ 重试
│ error │ ──────► running
└────────┘running。这是整套方案里最大的一处简化， 也是它能让"对话和任务管理不协调"这件事消失的根本原因。同一批对话，三种表达。取舍很实在：点省空间、文字有信息量。 我的结论是分场景混用——频道未读用文字（可数事实），对话状态用点 （会变的过程）。
最省空间，形态承担区分
待办带数字，唯一卡流程的态加重
信息量最大，246px 侧栏里会挤
左边是今天的形态（蓝点，只能表达"有"），右边是抖音关注列表的形态 （「3 条未看」，把可数的事实说出来）。未读本质是可数的，右边更对。这条与位置无关——即使不采用方案 D，也应该把频道未读换成计数。