DSH市场与管理 · v0.5.16
dsh-project-memory
如果这个插件帮你省下 1 小时 Debug 时间，请点个 Star。
作者原文（英文）
Persistent project memory for dsh agents: index docs (PDF/Markdown/text) and code symbols into a searchable per-workspace store, recall them with cited sources, and keep experience entries (problems -> solutions) searchable on demand.
简介取自插件自己的 README 原文。
安装命令
dsh plugin --profile web add @yolk_vat-y/dsh-project-memory@0.5.16
已试装 · 层已挂载
已在一个隔离的 profile 里真装过：包能装上，并且插件层挂载成功。这一条是实测结果，不是作者的声明。
检测报告
能力清单
- 可执行外部程序
spawns-processes高关注2 处命中scripts/bench.mjs:20import { execFileSync } from 'node:child_process'scripts/file-peak.mjs:22import { spawnSync } from 'node:child_process'- 看它调用哪些程序。调用本机已有的工具是常见做法。
- 以 shell 执行命令
shell-exec高关注1 处命中scripts/bench.mjs:222const out = execFileSync(process.execPath, ['--expose-gc', loadScript, coldDir], { encoding: 'utf8' })- 看命令字符串是拼出来的还是写死的。拼接用户输入才是真正的风险。
- 写入文件
writes-files需留意38 处命中src/audit.js:157mkdirSync(memoryDir, { recursive: true })src/audit.js:160appendFileSync(file, `${JSON.stringify(record)}\n`)src/audit.js:216mkdirSync(memoryDir, { recursive: true })src/audit.js:219appendFileSync(file, `${JSON.stringify(record)}\n`)- 看写入位置。写自己的配置目录是正常的，写系统目录不是。
- R011 客户端可疑脚本
client-side-risk需留意2 处命中- client.js: postMessage 无 origin 校验; task-data-store.ts: postMessage 无 origin 校验
- 浏览器侧代码能改你看到的界面。确认改动范围符合插件用途。
- 含混淆或编码代码
obfuscated-code需留意1 处命中scripts/file-peak.mjs:212push('%PDF-1.4\n%\xE2\xE3\xCF\xD3\n')- 混淆本身不是恶意，但公开源码里出现大段混淆值得问一句为什么。
- 读取文件
reads-files一般52 处命中src/audit.js:147if (existsSync(memoryDir)) return truesrc/audit.js:229if (statSync(file).size < maxBytes) returnsrc/enhancer.js:374content = readFileSync(filePath, 'utf8')src/enhancer.js:455content = readFileSync(task.filePath, 'utf8')- 读文件是绝大多数插件的正常工作方式，本身不构成顾虑。
- 动态加载模块
dynamic-import一般18 处命中src/parsers/pdfjs-parser.js:8pdfjsPromise = import('pdfjs-dist/legacy/build/pdf.mjs')scripts/bench-store.mjs:107const { spawnSync } = await import('node:child_process')scripts/bench.mjs:425const { readFile } = await import('node:fs/promises')scripts/file-peak.mjs:93const { readFileForIndex } = await import('../src/util/fs.js')- 动态导入本身无害，但会让依赖关系难以静态审阅。
- 读取环境变量
reads-env一般1 处命中src/util/fs.js:411env = process.env,- 环境变量里常混有密钥。看它是否把整个 env 都读走。
- 接触凭据或密钥
credentials一般1 处命中CHANGELOG.md:81宿主自己读子命名空间用的正是整名写法（`ctx.get('remote.probe')` / `ctx.get('remote.credentials')`）。- 看它读取哪些凭据、发往哪里。用于登录自己的服务是正常的。
逐条扫描明细
| 能力 | 标识 | 关注度 | 命中次数 |
|---|---|---|---|
| 可执行外部程序 | spawns-processes | 高关注 | 2 |
| 以 shell 执行命令 | shell-exec | 高关注 | 1 |
| 写入文件 | writes-files | 需留意 | 38 |
| R011 客户端可疑脚本 | client-side-risk | 需留意 | 2 |
| 含混淆或编码代码 | obfuscated-code | 需留意 | 1 |
| 读取文件 | reads-files | 一般 | 52 |
| 动态加载模块 | dynamic-import | 一般 | 18 |
| 读取环境变量 | reads-env | 一般 | 1 |
| 接触凭据或密钥 | credentials | 一般 | 1 |
这份报告的口径
扫描读的是包里的源码，全程不执行第三方代码。 本次读了 70 个文件，扫描于 2026-10-15。 命中次数只说明源码里出现过这类调用，不说明行为好坏——一个插件读写文件 500 次和 1 次 都会被记为「读取文件」。这是能力清单，不是信任评分，也不是安全结论： 没扫出来的能力可能只是写法没被规则覆盖。
可信度
- -5cordis entry id「project-memory」被 2 个包共用，同时安装会互相替换warn：dsh-project-memory
认证等级 未评级
- L0静态结构与契约—没有取到 npm 官方哈希
- L1配置组合与依赖图—entry id project-memory 被 2 个包共用
- L2隔离沙箱冒烟✓隔离 profile 安装成功，9.5s，层已挂载；宿主带它启动（booted）（前一级未通过，本项不计入等级）前一级未通过，不计入等级
- L3运行时健康监控✓抽样会话内未观测到外部进程 / 越界写 / 外连（2 个事件）（前一级未通过，本项不计入等级）前一级未通过，不计入等级
评分口径与作者信息
从 100 分开始按规则扣减：fail −20 / major −10 / warn −5 / minor −2；star 数、下载量、LLM 输出都不参与评分
- 维护者
- yolk_vat-y
- 仓库
- https://github.com/00080000/dsh-project-memory
- 许可
- MIT
- 最后发布
- 2026-10-10
- 周下载
- 978
- star
- 17
扫描状态：已扫描。能力是事实，不是缺陷； 周下载与 star 只作参考，不参与评分。
认证等级只回答四件事：包本身是否完整可解析（L0）、能不能与别的插件组合（L1）、隔离环境里装不装得上并起得来（L2）、抽样运行时有没有异常（L3）。依赖漏洞、仓库存活、下载量都不参与评级，只作为独立信号标注。可信 ≠ 无漏洞，上架 ≠ 推荐。
| DSH peer 依赖 | 3 个cordisdsh-llmdsh-tools均为 @deepseek-ai/ 下的包 |
|---|---|
| Node 要求 | >=18 |
| 第三方依赖 | 1 个 |
| bundle patch | ./cordis.patch.yml |
| 依赖安全公告 | 已查询全部依赖，没有匹配到已公开的安全公告（含 DSH 框架包在内的 @deepseek-ai/* 不作查询——那是运行时自己的问题，不是插件的。） |
元数据
| 主页 | https://github.com/00080000/dsh-project-memory#readme |
|---|---|
| 仓库最近提交 | 2026-10-13 |
| 仓库创建 | 2026-08-19 |