【Bug】live 重载 profile 补丁后，在途会话工具目录静默塌缩（47 → 14），模型陷入幽灵工具调用循环

[pear-studio]

Summary

在一个 standard preset 会话进行期间，向 profile 的补丁层（$DSH_HOME/profiles/web/cordis.patch.yml）追加了一段 agent-presets 的 roots 登记补丁（整体替换该插件 config）。补丁层 patchReload: 'live' 立即热重载后，该会话的工具目录从 47 个静默塌缩到 14 个：preset 挂载的全部内置工具（edit / read / write / grep / glob / pwsh / todo_write / ask_user_question / skill / workflow / web_search 等 33 个）消失，只剩第三方插件注册到宿主平面的工具（platform_search、config_*、palimpsest_*、checkpoint、sidebar_open、subagent）。会话没有任何报错或中断提示，模型在残缺目录下继续空转了 21 轮。

Reproduction

1. dsh web 启动，开一个 standard preset 会话，让 agent 正常工作（edit / grep 等工具可用，目录 47 个）
2. 保持会话不关闭，向 profile 的 cordis.patch.yml 追加一段修改 agent-presets config 的补丁（live reload 立即生效）
3. 观察该会话后续请求的 tools 列表

Current behavior

会话日志（session.v3.jsonl）证据：

• 热重载后第一个请求起，request/header 的 tools 从 47 项变为 14 项，preset 工具全部消失
• 同轮注入的 system message 从 22.3KB 缩至 5.7KB（preset 贡献的提示词段落一并丢失）
• 模型尝试调用已不在目录中的 edit / grep，退化为反复调用幸存的 platform_search（固定参数 {"platform":"github","query":"unused"}），连续 21 次；loop-guard 的 "Repeated tool call detected" 警告进入上下文但无法打破循环
• 分发链路无错：assistant/message 与 tool/call 记录逐字节一致，问题在目录塌缩本身
• 补救实测：fork 出的新会话工具目录恢复正常（47 个）；只有在途原会话保持塌缩——说明重载破坏的是在途会话的挂载绑定，而非 preset 本身损坏

补充背景：热重载时，一个正在开发的自定义 preset 目录里存在尚未完成的插件文件（缺 inject 声明）。不确定 roster 重建失败是否与之相关；但无论何种原因，在途会话都不应被静默留在半残状态。

Expected behavior

1. roster 重建时，对受影响的在途会话 fail-loud：中断当前 turn 并注入系统消息（如"工具目录已变更，请 fork 或新开会话"），而不是让模型对着残缺目录继续生成
2. 或重建成功时将 standing mounts 无缝恢复（recompose 的注释表明 standing mounts 设计上是 shared and permanent 的）
3. 或在文档明确 live reload 补丁会影响在途会话，给出安全操作指引

Environment

• dsh 0.1.5-rc.2（npm latest 稳定渠道；源码构建，checkout tag dsh-v0.1.5-rc.2）
• Windows 11，Node v24.14.0，pnpm 12.5.1
• 模型：自定义 provider（Anthropic Messages 协议）；模型侧已排除——幽灵调用是目录塌缩的下游症状
• 可应要求提供完整会话日志（解压后约 4.3MB JSONL）与当时的补丁内容

[nanami-0713]

补充一个排查侧的视角(未复现,以下是基于你日志证据的收窄建议):

你「补充背景」里的变量其实是最可疑的触发器:热重载时 roster 里存在缺 inject 声明的半成品插件文件。如果 roster 重建对坏条目的处理是「整轮放弃」而不是「跳过坏项」,一次重建失败把 preset 的 standing mounts 一起带走的路径就成立,也能解释为什么只有 in-flight 会话受损、fork 出的新会话目录完整(47 个)。

两个能把「补丁语义」和「坏文件」分开的二分实验:

1. 先把半成品文件补完整(或临时移出 roster 扫描范围),再重放同一段补丁 + live reload——若在途会话不再塌缩,trigger 就是 roster 重建遇错,而不是 agent-presets 补丁本身;
2. 反过来:保留坏文件,只 touch 一下 patch 文件触发一次内容不变的 reload——若这样也塌缩,说明阈值极低,roster 里有坏条目时任何 live reload 都不安全。

在官方给出 fail-loud 之前,建议把 live reload 当成「只对之后的新会话生效」来操作:reload 后立即 fork 或新开会话,不要让在途长任务跨过一次 reload。你抓到的 21 轮空转也说明 loop-guard 只警告不拦截——残缺目录下的空转是按轮计费的。这也让预期 1(fail-loud)比预期 2(静默恢复)更值得优先:静默恢复掩盖问题,fail-loud 才能把损失停在第一轮。