图谱监听守护 joslynSmall/dsh-plugin-graphify-watch

dsh-plugin-graphify-watch

为每个配置的根目录保持一个 graphify watch 进程常驻，代码一改就自动重建 graphify 知识图谱——不管改动是谁做的：DSH 文件工具、外部编辑器、shell 命令，还是 git checkout。

为什么要托管进程，而不是自己检测

graphify watch 本身已经管住了整套判断逻辑：扩展名过滤、.graphifyignore、跳过点目录和 graphify-out/、批量防抖、代码与文档的分流、删除驱逐，以及 needs_update 标记。而且只有盯着真实文件系统，才能看到 DSH 自己没做的改动——harness 的 workspace/changes 信号来自 git 快照加文件工具捕获，纯 shell 编辑它根本看不见。

所以这个插件不做任何检测。它只管生命周期：启动、记日志、崩溃后重启、卸载时杀掉整棵进程树。

每个根目录的行为

| 根目录状态 | 插件行为 |
| 有 graphify-out/graph.json | 启动 graphify watch <root> |
| 没有 graphify-out/graph.json | 跳过，并打一行日志提醒你先在那里跑 /graphify |
| 本进程已在监听 | 跳过（this process already watches it） |
| 别的进程已在监听 | 跳过（already watched by process <pid>） |

改代码会重建 graph.json + GRAPH_REPORT.md，不调用 LLM。改文档、PDF、图片不动图谱，只写 graphify-out/needs_update；插件会把这一行显示出来，并提醒你跑 /graphify --update。

配置

| key | 默认值 | 含义 |
| enabled | true | 设为 false 保留该行但不启动任何东西 |
| roots | [] | 要监听的绝对项目路径。留空表示「用宿主工作目录，且仅当它已被索引」——实际使用中请显式设置 |
| exePath | "" | graphify 的显式路径；留空则搜索 PATH |
| maxRestarts | 3 | 放弃前的连续重启次数（指数退避，上限 60 s） |
| restartBackoffMs | 2000 | 首次退避延迟 |
| logRebuilds | true | 记录 watcher 的每一行输出；一次性的就绪横幅始终记录 |

在 ~/.dsh/profiles/desktop/cordis.patch.yml 里覆盖这一行，指向你的项目。覆盖会替换该行整个 config，所以想保留的字段都要重新写一遍：

- id: graphify-watch
name: dsh-plugin-graphify-watch
config:
enabled: true
roots:
- C:\Users\Administrator\Documents\my-project
exePath: ""
maxRestarts: 3
restartBackoffMs: 2000
logRebuilds: true

安装

desktop 配置档留给 Electron 外壳，所以普通的 npm dsh 命令行拒绝管理它。请用应用。

1. 打开侧边栏的 Plugins 页面。
2. Add plugin → C:\documents\dsh\dsh-plugin-graphify-watch（接受绝对本地路径）。
3. 启用 dsh-plugin-graphify-watch 包。
4. 重启 DSH。 添加 file: 依赖链接需要重启进程—— Node 会缓存真实路径。

如果 UI 路径不可用，可以手动操作（在配置档目录下运行，也就是 pnpm 项目）：

cd ~\.dsh\profiles\desktop
add to dependencies: "dsh-plugin-graphify-watch": "file:C:/documents/dsh/dsh-plugin-graphify-watch"
append to dsh.profile.bundles: "dsh-plugin-graphify-watch"
node "C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness\resources\runtime\pnpm\bin\pnpm.cjs" install
then restart DSH

验证

the watcher should be running (a graphify.exe plus its Python child)
Get-CimInstance Win32_Process -Filter "Name='graphify.exe'" | Select-Object ProcessId,CommandLine

touching a real symbol must rewrite the graph
Add-Content <root>\src\thing.py "ndef probe():n return 1n"
(Get-Item <root>\graphify-out\graph.json).LastWriteTime

只改注释不算：graphify 会如实报告 No code-graph topology changes detected; outputs left untouched。

值得了解的行为

- 防抖用的是 graphify 自带的 3 秒。 --debounce 只存在于模块入口点（python -m graphify.watch），graphify 命令行上没有，所以这个插件不假装能配置它。
- 文档层仍然手动。 刷新文档、PDF 和图片需要跑一遍 LLM，所以它仍然是显式的 /graphify --update。自动化是可行的（用无头 graphify extract --backend 对接本地 OpenAI 兼容端点），但无人值守时会消耗 token，所以这里刻意不做。
- 一个根目录只有一个属主。 %TEMP%\dsh-graphify-watch 下的锁文件记录属主 pid，所以两个 DSH 窗口不能同时改写同一个 graph.json —— graphify 写入是原子的，但不持有跨进程锁，而且它的收缩保护会拒绝失败一方的写入。
- 清理会杀掉整棵进程树。 uv tool install 装出来的 graphify.exe 是个启动器，会把 venv 里的 Python 作为子进程拉起，所以插件在 Windows 上用 taskkill /T /F，而不是只杀启动器。
- 无依赖，无构建步骤。 插件刻意不用 @deepseek-ai/schemastery，所以它不声明 peer 范围，也不会被 DSH 的版本兼容门拦下。

测试

两个测试都独立运行，针对真实的临时项目，不需要 DSH。

node test/smoke.mjs <root> # start, code rebuild, doc flag, teardown
node test/resilience.mjs <root> # crash restart, duplicate-root refusal, lock

卸载

在 Plugins 页面禁用 bundle（或删掉那一行），然后重启 DSH。插件的 ctx.effect 清理器会停掉它启动的每个 watcher，不会留下任何 graphify 进程。