Repository navigation
Conversation
Signed-off-by: BigDataDZ <76271875+BigDataDZ@users.noreply.github.com>
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent | gpt-6.1-sol | OpenAI | runtime_reported | reasoning_effort=max
结论：REQUEST_CHANGES。发现一个 [P2] 所选宿主被后续验证和卸载绕过 的回归。当前提交：fd7511cae3247a4638311b21b500e7f4bb3662c0。
动机
使用指定 DSH 宿主从源码安装插件的用户，以及为支持的宿主版本做安装资格验证的维护者，需要可信的安装、版本读回和卸载结果。
原安装器把多行 JavaScript 交给 DSH 执行，作者报告它在 Windows 注册成功后仍无法完成版本读回；本次将校验改成单行，但新增测试随后绕开了 DSH_BIN 指定的宿主。
独立真实 DSH 对照中，两版普通安装均通过；让所选宿主拒绝卸载时，基线冒烟失败，当前提交却报告通过，且所选宿主完全没有收到卸载调用。
当前范围是源码安装器和已有安装资格测试；修复应保留同一宿主的校验链，既有权限、激活条件及发布边界继续有效。
改动思路
单行校验继续使用现有安装器和 DSH 执行接口，保持包名与版本的严格条件；为 Windows 直接调用已发布 JS 入口的方向合理，但入口必须仍属于已经选定的宿主。
保留此次可逆的命令格式修复和已有冒烟；修复 DSH_BIN 与后续 JS 入口的绑定，使版本检查、读回和卸载始终针对同一个已选安装。
安装器的权威输入仍是既有包名、版本、支持范围和真实 profile；SHA 输出只是诊断。沿用 registry smoke 的 JS 调用模式可以解决 Windows 不能直接启动 shell shim 的问题，但那个模式没有本测试已有的 DSH_BIN 覆盖契约，不能把它独立的默认选择一起搬过来。这里需要修的是已知宿主的传递，不需要第二个选择流程或新的状态 owner。
具体改动
完整 diff 是 3 文件、+47/-13：install.sh 将同一个严格版本校验压成一行；现有安装冒烟增加正确／过期版本、profile 不变和直接 JS 调用；Ubuntu/Windows 分发 job 各复用已有 smoke:install 入口。没有更改依赖或插件激活逻辑。
先读取改动前的 packages/dsh-loopx-plugin/README.md，spec_revision=4f6e20a13b090318e14efeb20b91790e33fe694b。这是实际 merge base；其相关 README 与最初目标分支版本逐字节相同。对无编号条款使用对应内容索引：
| 原合同内容索引 | 当前提交的处置 |
|---|---|
| Install / source entry | implemented：实际冻结安装、构建、打包和 profile 注册通过。 |
| Installation and upgrade recovery / version readback | implemented：单行表达式保持包名／版本拒绝，当前真实 DSH 正确和过期版本检查通过；Windows 实机结果保留为作者报告。 |
| Installation and upgrade recovery / selected host | not_met：后半程切换到包内 CLI，绕过已选宿主的失败。 |
关键代码讲解
install.sh的版本读回 保持manifest.name和manifest.version严格比较，仍通过dsh_bin执行；格式修复本身不应弱化拒绝条件。dshScript选择 只看额外的DSH_CLI_JS或包内require.resolve，没有沿用已解析的DSH_BIN。runDsh被后续正确／过期版本、profile 读回和卸载调用使用。因此安装和资格验证可以落到两套 CLI；DSH_BIN=<某个支持版本> pnpm smoke:install不再验证完整的那个版本。
对主干的风险
[P2] 反例已通过真实公开入口验证。 选择器包装器将命令转发给真实 DSH 0.2.0-rc.2，并记录实际参数。两版普通源码安装都成功；仅让这个已选宿主对 plugin --profile web remove dsh-loopx-plugin 返回 37 时，结果如下。profile、包安装和其余 DSH 操作均真实执行；注入边界只有所选宿主的卸载失败。
| 同一受控输入 | 基线 | 当前提交 |
|---|---|---|
| 所选宿主收到卸载 | 是 | 否 |
| 所选宿主拒绝卸载后，完整冒烟退出 | 1，正确失败 | 0，错误地报告通过 |
让 runDsh 的所有操作继续服从 DSH_BIN；若需要 JS 入口，从所选安装解析并校验同一宿主，或明确拒绝不匹配。已知宿主路径不应变成需要用户再提供第二套选择信息。
修复后保留默认安装、严格版本拒绝、profile 不变、不兼容宿主在副作用前拒绝和真实移除，再加入上述“所选宿主失败必须使整体失败”的反例。不要只验证包内默认宿主。实际执行入口就是现有 DSH_BIN=<selected-supported-host> pnpm smoke:install；无需新 runner 或额外用户确认。
语义与 CI 对齐
这是既有可执行文件选择合同的退化，没有新建共享词汇或权限协议。600 秒为公开说明的测试子进程上限，分发 job 仍为 20 分钟；本机缓存热环境样本不能复核作者的冷安装测量或宣称加速。相关主干的 pnpm 冻结配置与 Node 下限修复是独立相邻改动，不应转成这项 PR 的额外实现范围。
本地标准 premerge 4 项直接检查通过；13 项选中检查执行，12 通过，根目录 examples/install-local-smoke.py 在原 120 秒上限无输出超时。其中 DSH 的 quality/package/runtime 检查全部通过。该根目录安装检查与这里的 DSH 安装器不同；相同 120 秒预算下，基线与当前提交都停在首轮 install-smoke-initial；检查脚本和根安装器的 SHA 均相同。该对照及最初无输出超时全部保留，内部等待原因仍未定，不把它归为本 PR 引入，也不通过放宽上限抹掉失败。未查询或等待远端 CI，Windows 实机结果不冒领为本次独立验证。
我的整体评价
生产端的一行格式修复与复用现有冒烟的范围合理，所需修复也很小；没有理由追加框架、迁移或服务。但整体资格结论被已复现的宿主选择回归阻断，测试绿色不能覆盖这个反例。现有 Goal/Driver 的长期续做边界保持；安装资格操作的用户体验则退化为“指定一个宿主、实际验证另一个宿主”。先恢复一个已知宿主贯穿安装、验证和移除，再按同样反例复审即可。
English verdict: REQUEST_CHANGES — fd7511cae3247a4638311b21b500e7f4bb3662c0. Preserve DSH_BIN for the complete qualification: the new local-JS fallback bypasses a selected-host removal failure and falsely reports success. Real base/head source installs and the controlled removal counterexample were executed; the separate root installer timeout and native-Windows limits remain disclosed.
| const require = createRequire(import.meta.url) | ||
| // Windows cannot spawn the .bin shell shim directly. Match the registry smoke | ||
| // for direct DSH operations; the shipped installer still runs through Bash. | ||
| const dshScript = process.env.DSH_CLI_JS |
There was a problem hiding this comment.
[P2] Keep the selected DSH host for all qualification operations
When DSH_BIN selects another supported installation, install.sh uses it but runDsh() now invokes the package-local lib/bin.js unless a second DSH_CLI_JS is supplied. The documented DSH_BIN=... pnpm smoke:install path therefore no longer checks that selected CLI's later readback, stale-version rejection or removal. A forwarding wrapper around real DSH that rejects only plugin --profile web remove dsh-loopx-plugin makes the base smoke fail; this head still reports success and never sends removal to the selected CLI. Preserve the already-selected executable, or derive and validate its matching JS entrypoint, and cover that selected-host failure.
This branch has not been deployed
2 participants
Problem and result
On native Windows, the source installer builds and registers the plugin successfully, then fails its final version readback: DSH's execa transport rejects the multiline
node -eargument. Pass the same verifier as a single-line argument so the actual installed package name and version remain checked before reporting success.Extend the existing installer smoke to invoke DSH's published JavaScript entrypoint for direct Windows calls and exercise the exact shipped version verifier against both the correct and a stale version. Run that full source-installer journey in the existing Ubuntu/Windows distribution jobs. Its subprocess budget is now 600 seconds because an observed cold frozen installation alone took four minutes; the job budget remains 20 minutes.
Validation
installed and verifiedresult, matching package version, exact four rows, real correct/stale-version checks, incompatible-host rejection and real removal.All local profile/state writes were disposable; no provider/model turn, real Goal, global software upgrade or publication occurred. The full plugin distribution jobs, including the new source-installer and stale-version check, passed on both Ubuntu and Windows. Other repository checks and maintainer review remain unresolved. pnpm 12 frozen-configuration compatibility is independently proposed in #6861; this PR uses the existing CI-pinned pnpm 10 and does not change dependencies.