ccch1mneyyy/dsh-TUI

> 支持「tui 做基础设施、增强功能走插件」的分层，补几个来自 Windows 重度使用者的具体观察：
>
> 1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
> 2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
> 3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
> 4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。
>
> 需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。

感谢认领，考虑到向后兼容，生产稳定，以及dsh本身接口多变的特点，profile export/import + git 依赖固定要尽可能的谨慎和前瞻性

支持「tui 做基础设施、增强功能走插件」的分层，补几个来自 Windows 重度使用者的具体观察：

1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。

需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。

这个概念的终极成果是类似conda之于python。dsh生态是一直更新的个不稳定的混乱状态，而workplace，workflow，prompt迁移本身需要依赖链可追溯，从而形成稳定生态

ssh远端部署本就依托tui进行，此issue是希望依托tui形成一个远端部署，插件克隆，工作区迁移的生态链，而非把tui本身做的臃肿，生态链的插件挂在在组织仓库

@ccch1mneyyy @CikeSeven @makoMakoGo @TYCT-0926 @FUSU123fusu @Hariketsu @ybh618618 你们怎么看

分开回一下这两个问题：

**问题 2（模型解析不一致）**：`~/.dsh-cc/model.json` 存的是你在 TUI 里用 `/model` 做的选择，属于 cc-tui 自己的持久化偏好，设计上优先级高于 harness 的默认配置——这个分层本身是合理的。但它有个真实 bug：重启后路由会被「半覆盖」，拼出 `deepseek-official + 自定义模型` 的错配路由（详见 #67 的根因分析）。这个已在 #76 修复：(provider, model) 改为整体原子解析，重启后完整沿用 `/model` 的选择。至于「直接读 `~/.dsh/settings.yaml` 的默认模型作为 fallback」，是个合理的 feature 方向，可以在 #76 落地后单独开 issue 讨论。

**问题 1（终端输出格式）**：截图里的现象如果表现是「每轮回复后启动画面/历史内容重复刷出来」，那是 inline 渲染收缩时全量重置导致的 scrollback 污染，已在 #79 修复；如果是流式残影/错位，#59 正在处理同类问题。如果都不是，麻烦把终端里的原始输出以文本形式贴一段（截图里的文字不方便检索和比对），再帮你看。

我用的是Macos 的iterm

Macos 的iterm 和 ghotty 中都遇到这个问题

用的"dsh-cc-tui": "^0.4.1"