交互表面与通道
X-Hub 把远程通道和语音视为受控操作者表面，而不是影子控制平面。外部事件应先进入 Hub，再投影到 X-Terminal 语音、移动端或 runner 这类更高信任表面。
公开交互视图 这一页关注的是产品方向和边界原则，不展开尚未稳定的具体交互流程、设备接法和更细的授权状态机细节。
基本规则
所有外部世界事件都先进入 Hub。
Hub 持有的是：
- ingress 授权
- 重放防护
- 授权处理
- 审计
- 记忆真相
- 路由
- 面向 Supervisor 的状态投影
远程通道
当前方向覆盖的是常见操作者通道，例如：
- Slack
- Telegram
- Feishu
- 以及其他可逐步接入的远程表面
关键不只是“支持多少通道”，而是这些通道始终留在 Hub 治理之下，而不是直接变成 live command runtime。
更安全的接入方式
新的远程 ingress 更合理的默认姿态是：
- 未知入口先进入发现或隔离状态
- 本地可信管理表面做一次审批
- Hub 写入身份与绑定关系
- Hub 跑一次低风险首检
- 之后才进入正常受控通道
这比“任何新聊天表面一接上就获得可信控制能力”安全得多。
语音不是听写，而是配对表面
X-Terminal 语音的目标不是单纯语音输入，而是把 Hub 的受控状态变成“能听、能确认、能继续执行”的高信任交互面。
公开方向已经很明确：
- Supervisor 主动播报
- 由 Hub 发起的语音挑战状态
- repeat 与 cancel 这类基础控制语义
- 远程来源感知的待授权定位
- 动作完成后的统一回报路径
为什么来源感知重要
如果同时有多个待授权请求，语音不应该靠猜测去匹配。
因此语音与通道体验应该朝这几个方向收敛：
- 对待授权来源有感知
- 对远程通道上下文有感知
- 在目标不明确时 fail-closed
这正是“可用性”和“治理边界”必须一起成立的地方。
产品形态
理想的操作者体验应该像这样：
- 远程通道触发一个受控请求
- Hub 负责分类、持有和约束决策路径
- X-Terminal 语音负责汇报给操作者
- 操作者在受控流程中批准或拒绝
- 系统再通过同一条 Hub 真相路径做回报
这样语音和远程通道才会成为同一条治理交互链，而不是零散拼接的临时表面。