Tab 计划模式切换 sujalmandal/dsh-tab-plan-toggle

dsh-tab-plan-toggle

在 composer 文本域获得焦点时，用 Tab 切换 DeepSeek Harness 的计划模式。

| 按键 | 结果 |
| Tab（composer 聚焦，计划模式关闭） | 计划模式开启 |
| Tab（composer 聚焦，计划模式开启） | 计划模式关闭 |

安装

dsh plugin --profile web add dsh-tab-plan-toggle
dsh web

直接从仓库安装，在（或代替）注册表发布之前：

dsh plugin --profile web add git+https://github.com/sujalmandal/dsh-tab-plan-toggle.git

重启前确认该行已被组合：

dsh --profile web --dump-config # look for "# == dsh-tab-plan-toggle"

工作原理

composer Tab keydown ──rpc /dsh-tab-plan-toggle──▶ host half
│
ctx.get('agentPresets').serviceFor(agent,'planMode')
│
target = !(pending ?? active) ─────────────────┘
planMode.set(agent, target)

- host 半边会调用计划模式服务，因此进入和退出产生的叙述通知与 /plan 相同——且不会向对话中添加 command/run 行。
- 在 dsh web 上，计划模式位于 agent 预设的 isolate 领域内，因此 host 行只能通过 agentPresets.serviceFor(agent, 'planMode') 访问它。当该服务不可用时，插件会回退为向会话日志追加 plan/mode。
- 来自 planMode.get() 的 pending 是服务排队的目标，因此它被视为有效状态：第二次按下会反转已排队的更改，而不是变成空操作。
- 每个条目只对其挂载所在的 composer 生效：守卫会解析持有该条目标记的 composer，并要求聚焦的编辑器位于其中。
- 0.1.0 的守卫只检查聚焦元素是否位于某个 [data-input-scroll] 中，因此当另一个对话的条目仍处于挂载状态时，一次按下会同时切换两个对话。

守卫条件

仅当以下所有条件都成立时，Tab 才会被拦截：

- 没有 ⌘/Ctrl/Alt/Shift，且没有正在进行的输入法组合；
- 聚焦元素是 composer 的编辑器——其 Lexical contenteditable 宿主，或一个 TEXTAREA——且它位于 [data-input-scroll] 内；
- 该编辑器与本条目的标记属于同一个 composer，因此其他对话的 composer 无法匹配；
- 没有打开建议菜单（[data-trigger-menu] 不存在）：在 / 或 @ 菜单内，Tab 表示 Browse folder。

在其他任何地方，Tab 都保持其正常行为。

故障排除

| 症状 | 检查 |
| Tab 无任何反应 | composer 的编辑器是 Lexical 的 contenteditable 宿主，不是 TEXTAREA——要求 TEXTAREA 的守卫永远无法匹配。验证编辑器报告 isContentEditable。同时确认该条目的标记与编辑器位于同一个 composer 卡片内。 |
| Tab 会切换另一个对话 | 已在 0.1.1 中修复。在 0.1.0 中，每个挂载的 composer 都会添加自己的 document keydown 监听器，而任何获得焦点的 composer 都会满足所有这些监听器，因此按一次 Tab 就会切换所有打开的对话。 |
| 升级后 Tab 仍然失效 | --dump-config 中只有一行 dsh-tab-plan-toggle。两次挂载意味着两个处理器，Tab 会切换两次——净效果相当于无操作。 |
| 浏览器控制台中出现 … is not iterable | 较旧的构建读取的是 session.events；Session API 暴露的是 snapshotEvents()。请升级。 |
| Tab 劫持了其他编辑器 | 该防护要求编辑器位于 [data-input-scroll] 内；如果不是，请报告应用界面。 |

许可证

MIT