我理解清理未交付代码、收缩维护面有其必要性。但在 dsh 这里，删除 TUI 的理由和代价并不对称，值得重新讨论。
先澄清一点：TUI 不是底层调用接口，真正应稳定的是 CLI/API、会话和工具协议。问题在于，TUI 是一个完整的交互式宿主，也是对这些“渲染器无关”接口最重要的第二个消费者。
现在官方只剩 Web 交互入口
我查了三条非 Web 路径：
dsh --profile headless "task"是真正的 CLI，但它是批处理 runner。packages/bundle/headless/README.zh.md明确说明不挂载 Host、HTTP server、Web runtime 或浏览器插件，不监听端口，只经由 stdout/stderr 和退出码工作。
它的限制也很明确：只输出最后一条非空 assistant 文本；工具活动、中间过程和审批流都不可见；并且只能提交单个任务，不能在任务后继续交互。它适合 CI 和脚本，不是终端里的交互式 agent。
- ACP 也不是终端替代品。
packages/acp/acp/README.zh.md将它定义为“仅面向自动化的 ACP 服务器”，并明确说它是传输适配器，不是 UI 集成。编辑器导航、transcript 回放、命令、模式、配置选择、信息征集、计划、标题和工具展示都不在其范围内。
因此，当前唯一的官方交互式表层就是 Web。packages/client/ 下的 UI 包也基本是 React 方向。对于想在 SSH、tmux、容器或远程开发机里直接驱动 agent 的用户，官方答案实际上是：没有交互式终端入口。
“没有消费方”是被决策制造出来的
删除记录的逻辑值得追问：
- 先删除隐式的 dsh 终端应用组合。
- 再以 TUI “不再拥有任何已交付的组合”为由删除 TUI 包。
这不能证明 TUI 没有需求，只能证明它先被移出了默认组合。正常的替代方案应当是保留一个明确的 profile、示例或独立发行物，而不是拿“没有示例消费它”作为删除理由。
尤其当项目仍强调插件化时，终端交互本应是最应该保留的宿主类型之一。
最大的架构损失：接口只剩一个实现
删除笔记中提到，命令、用户交互、审批、工具呈现、PTY、会话投影等接口仍然可以被其他宿主使用。从类型设计上说，它们确实应当与渲染器无关。
但删掉 TUI 后，官方能证明这些边界确实独立的实现只剩 Web 一个。
一个接口只有一个消费者时，很难区分它究竟是通用边界，还是恰好被 Web 的内部需求塑形的抽象。没有第二个实现去施压，接口漂移通常不会立刻失败，只会逐渐向唯一宿主耦合。
TUI 原本正是这个第二实现。它不只是终端用户功能，也是在验证“人如何驱动 agent”这一层是否真的可插件化。一个自称“一切皆插件”的 harness，在最关键的人机交互层只剩 React/Web 一个官方实现，这个说服力是明显下降的。
被删掉的不是一个随手原型
归档记录显示，TUI 在 7 月 17 日到 8 月 3 日间已经完成了大量产品化工作，包括：
- 会话身份、耗时和阶段状态
- 工具展示、折叠模式和 verbose 状态
- 审批与多行提问
- workspace、分支和 tmux 上下文
- 文件引用补全、shell 风格提示词编辑
/details、/resume、/reload、skill 命令- Windows 支持、终端状态快照测试和长会话渲染优化
这意味着“未来有需要再做一个”并不便宜。删除节省的是未来的边际维护，但失去的是已经沉淀的交互经验、兼容性修复和机构知识。
社区已经在补这个缺口
删除后不久，社区已有 ccch1mneyyy/dsh-TUI 这类项目，明确定位为补齐官方缺少的终端 TUI，并提供 npm 安装。与此同时还有桌面端和 Web UI 的外部实现。
这至少说明需求并未消失。问题变成了：官方是否愿意把客户端插件 API 当作可依赖的契约，而不只是 Web 客户端的内部实现细节？
如果第三方必须顶着“开发者预览 API 可能破坏兼容”的风险，从零重建 TUI，而官方保留随时破坏它的权力，那么所谓插件生态的成本和风险就被完全转移给了社区。
反正用到现在，我是不会继续使用DSH了，希望等社区发展成熟吧