Touch controller

Touch controller 表示仓库主要维护触摸控制器 IC 的驱动边界，把触点采集、事件语义和总线交互当成独立可复用模式来处理。这里的重点不是“有输入设备”，而是触摸控制器的读数和事件模型本身。

它通常会和 Async embedded、Embedded Rust、I2C 一起出现，但不替代这些 Topic：Touch controller 解释的是触点读取、事件表示、sync/async 边界和与 UI/firmware 的接缝，其他 Topic 才解释总线和运行时（projects/ft6336u-async.md）。

当 README、crate 描述、project snapshot 或接口设计明确表明仓库围绕触摸控制器 IC 维护驱动时使用。若只是更大 UI/firmware 系统里的一个附属输入通道、且没有独立驱动边界，则不应强行命中。

如果一个改动会影响触点读取、坐标/状态表示、interrupt/polling、sync/async 用法、I2C 交互或下游 UI 如何消费触摸事件，就应该命中本 Topic。

• Small, trait-driven design so the driver can slot into larger UI stacks (projects/ft6336u-async.md)
• 触摸驱动默认应保持小而 trait-driven，方便被更大的 UI stack 或设备固件接入，而不是把整个手势/页面逻辑塞进驱动层。
• sync/async 双模式若共存，应共享同一份触点/事件语义，而不是复制两套读取逻辑。
• 回答此 Topic 时，要写清它输出的是原始寄存器值、触点结构、坐标事件还是更高层语义；否则后续维护者不知道哪些改动会影响下游 UI 行为。
• 触摸控制器虽是窄主题，但它直接连接人机交互；Topic 里应保留“驱动层负责到哪、UI 层负责到哪”的分界。

• projects/ft6336u-async.md：触摸控制器 driver 的直接样本，适合说明事件读取、sync/async 共存和嵌入式 UI 接缝，也能提醒维护者驱动层应负责触点与状态语义，而不是越界承担页面手势或业务交互逻辑。

• 只因为系统“有触摸屏”就打 Touch controller，却没有独立控制器驱动证据，会让 Topic 失去判别力。
• 把 Touch controller 当成整个仓库的总括标签，忽略 Async embedded、Embedded Rust、I2C 等相邻 Topic，会让后续 Agent 无法判断真正该看的是事件语义、总线读取还是运行时模型。
• 不写驱动层与 UI/gesture 层的边界，会让后续维护者在错误层级改动交互逻辑。

• projects/ft6336u-async.md
• skills/style-playbook/references/data/topics/touch-controller.json