Skip to content

仓库地志功能的提示优化 #607

Closed

Description

@NaughtDZ

要解决的问题 / Problem

仓库地志 界面显示 还没有登记的仓库。先在仓库目录里跑 dsh-mneme-choro <仓库路径> --apply 生成骨架页并登记,然后回到这里。
完全是不存在的,dsh-mneme-choro 没注册到path里,用户怎么可能手动跑起来这个命令,完全就是AI自己编的。Readme.md也是纯AI写的,鲸言鲸语,人类看不到,只能发给AI研究。

期望的方案 / Proposed solution

AI分析的结果:
一、为什么 cmd 里提示“无效命令”
dsh-mneme-choro 确实在这个包里(package.json 的 bin 字段声明了它 → bin/dsh-mneme-choro.mjs)。但包不是全局安装,而是装在 DSH 的 profile 依赖里:

代码块

C:\Users\Naught.dsh\profiles\web\node_modules@modusensus\dsh-mneme
npm 只为全局包在 PATH 中放 shim。这个包的 shim 只在 ...\profiles\web\node_modules.bin\ 里,不在 PATH。cmd 找不到它。

二、可以直接复制的命令(我实测跑通了)
代码块

"C:\Users\Naught.dsh\profiles\web\node_modules.bin\dsh-mneme-choro.CMD" "D:\你的仓库" --apply
等价写法:

代码块

node "C:\Users\Naught.dsh\profiles\web\node_modules@modusensus\dsh-mneme\bin\dsh-mneme-choro.mjs" "D:\你的仓库" --apply
如果想以后直接敲 dsh-mneme-choro,就把 C:\Users\Naught.dsh\profiles\web\node_modules.bin 加进系统 PATH。

三、那句提示文案是错的,不怪你看不懂
面板写“在仓库目录里跑 dsh-mneme-choro <仓库路径> --apply”。我实测了两件事:

cd 进仓库、不带参数跑 → 只打印帮助,什么都不做
参数是必须的,而且它跟“当前目录”无关
所以正确姿势是传路径,不是 cd 进去裸跑。这条文案把“cd 进去”和“传路径参数”混在一起,是插件自己的 bug。

另外提醒:你当前目录 H:\doc_research 不是 git 仓库,实测会被直接拒绝:

代码块

拒绝运行(not-git):... chorography 的每条出处锚点都要能对着提交核验,非 git 目录拒绝生成。
四、完整流程(4 步,顺序不能乱)
开开关:设置 → 记忆(mneme)→ 功能 → 「仓库地志(chorography)」→ 重启 DSH。不开这个,跑完命令面板照样是空态。
先 dry-run(不加 --apply,零写入,只看数字):
代码块

"...\dsh-mneme-choro.CMD" "D:\你的仓库"
确认数字合理再加 --apply,写入 <仓库>.chorography\ 并登记进 memory.db。
回面板看「仓库地志」页。
补一句现状:你的 memory.db 里 choro_repos 是 0 行,所以面板显示空态完全正常——确实一次都没登记过。

考虑过的替代方案 / Alternatives considered

说人话就是这功能默认不开,开关也不是在dsh设置里而是在这个插件的设置里,但是左边栏单独的 ”仓库地志“(也不知道哪个天才AI想出来的怪名字) 根本没说明自己是哪个插件来的功能。刚更新一头雾水。跑插件设置里还找不到,这玩意开关藏在二级菜单里。
开了也用不了,给的提示毫无意义。
我说,虽然插件AI写、UI也是AI写,活人总是要参与一下测试吧?

实现口径确认 / Implementation gates (维护者会逐项核对)

  • 新行为开关应 opt-in 默认关,注册进 settings 白名单 / new toggles opt-in by default + settings whitelist
  • 涉及 schema 变更时需配幂等迁移 / idempotent migration for schema changes
  • 接受带回归测试的验收线 / acceptance includes regression tests

披露 / Disclosure

  • 本提案由 AI 辅助整理(人工审核后提交)/ Drafted with AI assistance, reviewed by a human

Activity

  1. modusensus commented on Nov 8, 2026

    @modusensus
    Member

    修好了,本地提交在分支 fix/607-choro-hints(commit 6026e85,未 push)。谢谢 @NaughtDZ ——你把这四条列出来的方式帮了大忙,尤其是「完全就是 AI 自己编的」这句,问题定性得很准。

    改了什么

    根因:提示让人「在仓库目录里跑 dsh-mneme-choro <仓库路径> --apply」,这句话两处都不成立。插件装在 profile 依赖里,npm 只为全局安装把 shim 放进 PATH,<profile>/node_modules/.bin 不在 PATH 上;而参数与 cwd 无关,cd 进仓库裸跑只打印帮助、什么都不做。所以不是文案不好看,是给出了一条照着抄必然失败的命令。

    文件 为什么改
    dsh-mneme/src/wiki/cli-hint.js(新增 90 行) 命令串从插件自身位置推导:从调用方的 import.meta.url 逐级上溯(上限 6 层)找「同时存在 bin/dsh-mneme-choro.mjs 与 package.json」的目录,产出 node "<entry>" <repo> --apply。刻意不按固定 dirname 次数推导——src/ 与 lib/ 同层、src/wiki/ 在第二层、bin/ 在第一层,写死层数只要有一处调用方挪位置就悄悄算错,而算错的表现正是又给一条跑不起来的命令(与本 issue 同源)。也只给 node <entry> 一种形态:.bin 的 shim 在 hoisted 与 pnpm isolated 两种 linker 下位置不同,猜错就是再给一条错的。找不到入口返回 null,调用方退回通用文案,不硬编假路径。
    dsh-mneme/src/choro-command.js /choro 命令的「仓库没登记」文案接上真实入口。
    dsh-mneme/src/api.js GET /choro/repos 响应新增 cliCommand 字段;/choro/page 的 409 hint 同样接上。面板 bundle 拿不到 CLI 路径,所以命令串由服务端算好下发。
    dsh-mneme/src/tools.js 三个 choro 工具的 repo 解析失败与 page-missing 接上(它们走 DSH 工具错误路径)。
    dsh-mneme/src/wiki/t1.js T1 的 not-registered 拒绝原因接上。
    dsh-mneme/src/lang.js noRepo / stale 两条文案加一个可选命令参数,缺省时回落原文案(中英两段都成对)。
    dsh-mneme/lib/client.js 面板三件事:①无仓库空态加复制命令按钮;②where 文案点名开关位置「设置 → 记忆库设置 → 功能开关 → 它什么时候写进去 → 仓库地志(chorography)」并说明要重启 DSH 才生效;③pageMissing 从「重跑 CLI」改成「点顶部『重建骨架』即可」——面板里本来就有那个按钮,让人离开面板去跑命令是多余的一步。

    关于你说的第 4 条(开关藏在「它什么时候写进去」组里、左边栏又没标明属于哪个插件):空态与禁用态现在都直接写出这条路径,并说明它属于本插件(记忆库)。没做的是给左边栏的「仓库地志」入口加来源标注——那要动宿主的 panel 注册结构,超出这条 issue 的范围,需要的话单开一条我再做。

    复制按钮的一个细节:剪贴板在非安全上下文里不存在,所以失败分支必须说话(announce「复制失败,请手动选中命令文本」),不能静默——静默失败就又是一次「点了没反应」。

    怎么验证的

    新增 dsh-mneme/test/wiki-cli-hint.test.js,5 例:

    1. 四个不同深度的真实模块位置必须收敛到同一个入口(test/ / src/ / src/wiki/ / bin/)——写死层数的实现在这里必然红;
    2. 推导出的入口真实存在,且包根同时有 bin/ 与 package.json;
    3. 裁剪树(只有 bin/ 或只有 package.json)返回 null,不硬编假路径;
    4. Windows 双引号 / POSIX 单引号 / POSIX 路径含单引号时转成 '\'',逐字比对;
    5. 真的用推导出的入口 spawn 一次 --help,断言退出码 0 且输出含 --apply——你这条 issue 的验收标准就是「用户照着能跑起来」,字符串断言证明不了这件事。
    ℹ tests 5 / pass 5 / fail 0
    

    变异自证(各改一处、跑、还原):

    变异 结果
    上溯上限从 6 层改成 1 层(模拟「按 src/ 同层写死」) 3 红
    去掉引号逻辑(直接输出裸路径) 1 红
    还原 5/5 绿

    其余验证:

    node --test test/choro-command.test.js test/wiki-api.test.js test/wiki-tools.test.js test/client.test.js test/wiki-cli-hint.test.js
    ℹ tests 135 / pass 135 / fail 0
    
    npm run sync                → Synced 96 file(s);lib/wiki/cli-hint.js 同步产出
    node scripts/check-sync.js  → ✓ src/ 与 lib/ 一致(96 个文件)
    node --test test/*.test.js  → 2907 tests / 2906 pass / 0 fail / 1 skipped
    

    (本仓库 src/ 与 lib/ 是同步产物,两边都改了;lib/client.js 是手写面板 bundle,没有 src/ 对应物。)

    现状

    • 分支 fix/607-choro-hints,commit 6026e85,只本地提交,未 push、未开 PR(维护者合并流程)。
    • 主树未触碰。
    • 合并后老用户看到的就是自己机器上的真实入口路径,而不是一个只对全局安装成立的裸命令名。
  2. modusensus commented on Nov 11, 2026

    @modusensus
    Member

    修在 #627:报告的四条同源于「提示里的命令照着抄必然失败」——插件 shim 不在 PATH 上(npm 只为全局安装写 shim)、参数又与 cwd 无关(cd 进仓库裸跑只打印帮助)。现在命令串从插件自身位置推导(src/wiki/cli-hint.js),产出 node "<entry>" <repo> --apply 这样能直接粘贴就跑的一条。

    随后地志侧又落了一串改进:#608(对齐 Qoder + 知识库第二层)、#615(知识库面板改仓库卡片)、#631(侧栏入口旗标门控)、#638(扩展子系统总闸提到设置页首屏)。均已随 v0.14.0-beta.1 / beta.2 发布。

    谢谢 @NaughtDZ 的报告——四条列得很准。若还有提示不准或照抄失败的地方,欢迎另开新 issue。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions