尧图网页设计 
last30days-skill 首次配置向导中 Digg CLI 的安装路径对齐与 Agent 子进程 PATH 实践【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill本篇指南基于仓库内的集成问题解决方案文档 digg-cli-agent-path-setup-wizard.md讲解 last30days-skill 首次运行NUX自动安装digg-pp-cli时遇到的一个典型集成缺陷安装器报告成功、引擎却因 Agent 子进程 PATH 缺失而静默丢弃 Digg 源。读完本篇你能理解已安装与引擎可激活两个概念的差异、shutil.which作为唯一激活门控的机制以及配置向导如何通过对齐 printing-press-library 的默认安装目录、细分安装结果分类和 OpenClaw 服务端对等支持实现诚实、可验证的 CLI 源引导流程。问题背景为什么安装成功不等于数据源激活last30days-skill 的引擎通过外部 shell out 到digg-pp-cli二进制只读、无需鉴权来接入 Digg AI 1000 聚类源。该源是否可用取决于一个非常朴素的判定引擎子进程能否在 PATH 上按名字解析到这个二进制。问题出在首次运行的自动安装环节setup_wizard.py 的run_auto_setup()在 Hermes / OpenClaw 这类 Agent 网关中引擎子进程的 PATH 往往不包含$HOME/.local/bin而 printing-press-library npm 0.1.16 起正是把二进制默认装到该目录早期实现使用了已弃用的mvanhorn/printing-press包并且探测的是遗留的~/go/bin回退目录而非当前的默认安装目录OpenClaw 的setup --openclaw路径完全没有尝试安装 Digg只覆盖桌面 NUX 场景。由此产生的用户可见症状见 解决方案文档 的 Symptoms 一节--diagnose输出的available_sources中没有digg即使pp-digg或 setup 已经安装了 CLI之前跑过npx mvanhorn/printing-press-library install digg --cli-only的 Hermes/OpenClaw 用户会因为探测逻辑不一致而收到虚假的失败或虚假的now active提示OpenClaw 服务端 setup 从不安装 Digg。引擎侧的激活门控shutil.which 是唯一标准理解修复方案之前先确认引擎侧的判定逻辑。在 digg.py 中CLI_BIN digg-pp-cli def _is_available() - bool: True when the digg-pp-cli binary is on PATH. return shutil.which(CLI_BIN) is not None而 pipeline.py 的available_sources()中Digg 的可用性判定同样是if which(digg-pp-cli): available.append(digg)也就是说引擎从不读取pp-digg skill 是否已安装这类状态每一次研究运行都是按名字在 PATH 上 shell out 到digg-pp-cli。这就是解决方案文档中Why This Works一节的核心结论setup 向导必须镜像引擎自身的判定谓词而不是发明另一套成功定义。如果 setup 用某处存在二进制文件当作成功而引擎用shutil.which判定两者就会漂移——用户在向导里看到已激活--diagnose却显示源缺席。修复要点一固定Pin目录安装器与安装命令setup_wizard.py 中固化了安装器版本与命令# Generous timeout: the install shells out to npx, which may download the # Printing Press package and build the Go binary over the network. DIGG_INSTALL_TIMEOUT 300 DIGG_CLI_BIN digg-pp-cli # Pin the catalog installer; matches printing-press-library npm 0.1.16 default # ($HOME/.local/bin on macOS/Linux). PRINTING_PRESS_NPM mvanhorn/printing-press-library0.1.16 DIGG_INSTALL_CMD fnpx -y {PRINTING_PRESS_NPM} install digg --cli-only三个设计决策值得注意npm 包名固定到 semver 0.1.16该版本的目录安装器默认安装目录从$GOPATH/bin迁移到了$HOME/.local/bin。固定版本号保证 setup 向导与 CONFIGURATION.md 中给用户的命令、以及引擎的 PATH 门控三者始终指向同一安装位置只装 CLI--cli-onlylast30days 把 Digg 内嵌为引擎数据源而不是引入 pp-digg skill所以不需要 skill 接线Hermes/OpenClaw 上差异的只是 focused skill 的接线方式二进制位置两者完全相同都是$HOME/.local/bin300 秒超时安装过程可能涉及 npm 下载与 Go 二进制构建超时预算按最坏网络条件给足。CONFIGURATION.md的数据源表格中对此有明确约定Digg 的激活条件是digg-pp-clion PATH首次运行 setup 时通过npx -y mvanhorn/printing-press-library0.1.16 install digg --cli-only自动安装二进制默认落在$HOME/.local/binHermes/OpenClaw 的 Agent 子进程必须继承该目录的 PATHDigg 才能激活。修复要点二安装结果五分类杜绝虚假成功修复后的_install_digg_cli()setup_wizard.py返回四元组(engine_active, action, stderr, off_path_binary)其中action是一个五值分类action触发条件引擎是否激活状态文案行为already_installedshutil.which(digg-pp-cli)一开始就解析成功是Digg CLI already installed (AI-news clusters active)installednpx 安装后shutil.which解析成功是Installed Digg CLI (... now active)installed_off_path二进制在已知安装目录存在且可执行但不在 PATH 上否给出具体路径与可复制粘贴的 PATH 目录提示重启 Agent 会话/网关install_failednpx 退出码非零或安装后两处探测均未找到否附digg_stderr提示手动执行DIGG_INSTALL_CMDno_npx系统上找不到npx否提示先安装 Node/npx 再执行安装命令关键约束是already_installed/installed只在shutil.which解析成功时才允许出现——与pipeline.available_sources()的门控完全同谓词。而installed_off_path是专门为磁盘上存在但 PATH 不可见这种 Hermes/OpenClaw 常见失败模式准备的诚实出口。候选目录探测与安装器共享单一来源探测 off-path 二进制的目录列表没有另起炉灶而是从health模块的共享清单派生setup_wizard.pydef _digg_bin_candidate_paths() - list[Path]: Known install locations for digg-pp-cli (Printing Press library defaults). Order: current installer default (~/.local/bin), legacy Go bins, Windows managed dir. ... from . import health win_dir health.windows_printing_press_bin_dir() candidates: list[Path] [] for directory in health.installer_bin_dirs(): if win_dir is not None and directory win_dir: candidates.append(directory / f{DIGG_CLI_BIN}.exe) else: candidates.append(directory / DIGG_CLI_BIN) return candidates而 health.py 中这个清单的定义是~/.local/bin当前安装器默认macOS/Linux$GOPATH/bin若设置了GOPATH遗留 Go 目录~/go/bin遗留 Go 目录Windows%LOCALAPPDATA%/Programs/PrintingPress/bin且该目录下的候选名带.exe后缀windows_printing_press_bin_dir()在非 Windows 上返回None。两个探测函数的分工在源码中写得很清楚def _digg_on_path() - Optional[str]: Return digg-pp-cli when the engine would activate Digg (PATH-resolvable). return shutil.which(DIGG_CLI_BIN) def _digg_off_path_binary() - Optional[str]: Return digg-pp-cli path from known install dirs when not on PATH. for candidate in _digg_bin_candidate_paths(): if candidate.is_file() and os.access(candidate, os.X_OK): return str(candidate) return None注意注释里的一句话探测这些目录只用于 setup 验证与诚实的 off-PATH 消息不用于引擎激活。这正是What Didnt Work第一条的教训——旧逻辑把某处存在二进制当作已安装探测~/go/bin但没有 PATH 可见性造成假阳性引擎门控与 setup 验证必须各守其位。安装流程的状态机_install_digg_cli()的完整判定顺序setup_wizard.py_digg_on_path()命中 →already_installed直接返回未命中则查_digg_off_path_binary()命中 →installed_off_path复用之前 pp-digg 的安装不重复装、也不谎称已激活都未命中才调用_run_npx_install(digg)执行npx -y mvanhorn/printing-press-library0.1.16 install digg --cli-only该子过程setup_wizard.py用shutil.which(npx)解析出 npx 的绝对路径再作为 argv[0] 传入——这是为了修复 Windows 上 PATHEXT 不匹配的问题裸字符串npx不会触发.CMD解析会以WinError 2失败npx 返回非零或异常 →install_failed并携带 stderrnpx 返回 0 后重新执行双探测PATH 上出现 →installed只出现在候选目录 →installed_off_path把 npx 的非致命 stderr 一并记录两处都没有 →install_failedinstall completed but digg-pp-cli was not found。第 5 步的安装后复验是整个修复的关键安装器进程退出码为 0 不代表二进制对当前进程可见必须以引擎自己的门控再做一次判定。状态文案off-path 时给出可操作的 PATH 提示get_setup_status_text()setup_wizard.py把五分类渲染成用户可读的文案。installed_off_path分支会调用_digg_bin_dir_hint()把二进制路径折算成可复制粘贴的 PATH 目录$HOME/.local/bin形式Windows 用绝对路径并明确提示add ... to PATH and restart your agent session/gateway for Digg to activate——重启 Agent 会话是必要步骤因为子进程 PATH 在会话启动时继承。修复要点三OpenClaw 服务端对等支持旧实现中setup --openclaw完全跳过 Digg 安装只覆盖桌面 NUX。修复后的run_openclaw_setup()setup_wizard.py在服务端 JSON 探针中执行同一套_install_digg_cli()digg_installed, digg_action, digg_stderr, digg_path _install_digg_cli() ... payload: Dict[str, Any] { yt_dlp: yt_dlp, node: node, python3: python3, digg_cli: digg_installed, digg_action: digg_action, keys: keys, x_method: x_method, } if digg_path: payload[digg_path] digg_path if digg_action install_failed and digg_stderr: payload[digg_stderr] digg_stderrJSON 输出字段digg_cli引擎是否激活、digg_action五分类之一、可选的digg_pathoff-path 二进制路径与可选的digg_stderr安装失败详情让 SKILL.md 驱动的模型在服务器场景下也能呈现与桌面 NUX 一致的、诚实的 Digg 状态。这套模式如何推广到其他 Printing Press 源同一套固定安装器 双探测 五分类模式在 setup_wizard.py 中被参数化复用到了其他默认开启的 Printing Press 源上PP_DEFAULT_SOURCES [(arxiv, arxiv, arxiv-pp-cli), (techmeme, techmeme, techmeme-pp-cli)]由_install_pp_cli()/install_default_pp_sources()执行返回结构与 Digg 完全一致。Trustpilot 则被有意排除在自动安装之外它默认关闭属于INCLUDE_SOURCESopt-in 源且使用无头 Chrome 收割 cookie为默认关闭的源预装二进制是浪费Bright Data 同样是只报告、不安装它消耗用户自己的计费额度获取与否由用户决定。这些例外与 Digg 的主路径共同构成 setup_wizard.py 中统一的 action 分类学。测试覆盖与验证修复的关键行为都有对应测试用例集中在 tests/test_setup_wizard.pyoff-path 检测路径digg-pp-cli位于~/.local/bin但不在 PATH 上 → 期望digg_action installed_off_path且不触发 npx约 L384-L398npx 安装 rc0 但二进制落在$HOME/.local/bin且不可见 → 同样判定installed_off_path约 L405-L424状态文案路径installed_off_path的各种情形含遗留~/go/bin位置、digg_path缺失或为空在get_setup_status_text()下均生成带 PATH 修复指引的文案约 L771-L805Bright Data 的三态报告already_installed/installed_off_path/not_installed也验证了引擎门控原样透传、从不夸大 active的同一原则约 L892、L931。这与解决方案文档 Prevention 一节的测试要求一致Hermes/OpenClaw 场景要用重定向的HOME与 mock 的 PATH 覆盖OpenClaw 服务端镜像桌面 NUX 时要在 JSON 中加入对应字段。可复用的预防规则解决方案文档最后沉淀了四条预防规则适用于任何新增CLI 门控数据源的引导逻辑对齐上游安装器的默认 bin 目录并固定 npm semver——安装位置是契约不是假设成功消息必须使用与available_sources()相同的探测谓词shutil.which磁盘上存在但 PATH 不可见的情况走独立的 off-PATH 结果分支测试用重定向HOME mock PATH 覆盖 Agent 网关场景服务端 setup 镜像桌面 NUX 时同步扩展 JSON 字段改动可选源引导前先在docs/solutions/下检索digg、setup-wizard、agent-path等关键词——本方案文档docs/solutions/integration-issues/digg-cli-agent-path-setup-wizard.md即为此类集成问题的登记入口。关键文件索引文件作用setup_wizard.py首次运行向导Digg 安装器常量、候选目录探测、五分类安装流程、OpenClaw JSON 探针digg.pyDigg 源适配器shutil.which可用性门控、search/postsCLI 调用pipeline.pyavailable_sources()引擎侧按which(digg-pp-cli)激活 Digghealth.pyinstaller_bin_dirs()/windows_printing_press_bin_dir()安装器目录单一来源test_setup_wizard.pyoff-path 检测、状态文案与 OpenClaw 输出的测试覆盖CONFIGURATION.md数据源表格Digg/arXiv 的 PATH 激活条件与安装命令SKILL.md、AGENTS.md、HERMES_SETUP.mdStep 0 引导与 CLI 门控源的文档约束【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 last30days-skill 首次配置向导中 Digg CLI 的安装路径对齐与 Agent 子进程 PATH 实践
last30days-skill 首次配置向导中 Digg CLI 的安装路径对齐与 Agent 子进程 PATH 实践【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill本篇指南基于仓库内的集成问题解决方案文档 digg-cli-agent-path-setup-wizard.md讲解 last30days-skill 首次运行NUX自动安装digg-pp-cli时遇到的一个典型集成缺陷安装器报告成功、引擎却因 Agent 子进程 PATH 缺失而静默丢弃 Digg 源。读完本篇你能理解已安装与引擎可激活两个概念的差异、shutil.which作为唯一激活门控的机制以及配置向导如何通过对齐 printing-press-library 的默认安装目录、细分安装结果分类和 OpenClaw 服务端对等支持实现诚实、可验证的 CLI 源引导流程。问题背景为什么安装成功不等于数据源激活last30days-skill 的引擎通过外部 shell out 到digg-pp-cli二进制只读、无需鉴权来接入 Digg AI 1000 聚类源。该源是否可用取决于一个非常朴素的判定引擎子进程能否在 PATH 上按名字解析到这个二进制。问题出在首次运行的自动安装环节setup_wizard.py 的run_auto_setup()在 Hermes / OpenClaw 这类 Agent 网关中引擎子进程的 PATH 往往不包含$HOME/.local/bin而 printing-press-library npm 0.1.16 起正是把二进制默认装到该目录早期实现使用了已弃用的mvanhorn/printing-press包并且探测的是遗留的~/go/bin回退目录而非当前的默认安装目录OpenClaw 的setup --openclaw路径完全没有尝试安装 Digg只覆盖桌面 NUX 场景。由此产生的用户可见症状见 解决方案文档 的 Symptoms 一节--diagnose输出的available_sources中没有digg即使pp-digg或 setup 已经安装了 CLI之前跑过npx mvanhorn/printing-press-library install digg --cli-only的 Hermes/OpenClaw 用户会因为探测逻辑不一致而收到虚假的失败或虚假的now active提示OpenClaw 服务端 setup 从不安装 Digg。引擎侧的激活门控shutil.which 是唯一标准理解修复方案之前先确认引擎侧的判定逻辑。在 digg.py 中CLI_BIN digg-pp-cli def _is_available() - bool: True when the digg-pp-cli binary is on PATH. return shutil.which(CLI_BIN) is not None而 pipeline.py 的available_sources()中Digg 的可用性判定同样是if which(digg-pp-cli): available.append(digg)也就是说引擎从不读取pp-digg skill 是否已安装这类状态每一次研究运行都是按名字在 PATH 上 shell out 到digg-pp-cli。这就是解决方案文档中Why This Works一节的核心结论setup 向导必须镜像引擎自身的判定谓词而不是发明另一套成功定义。如果 setup 用某处存在二进制文件当作成功而引擎用shutil.which判定两者就会漂移——用户在向导里看到已激活--diagnose却显示源缺席。修复要点一固定Pin目录安装器与安装命令setup_wizard.py 中固化了安装器版本与命令# Generous timeout: the install shells out to npx, which may download the # Printing Press package and build the Go binary over the network. DIGG_INSTALL_TIMEOUT 300 DIGG_CLI_BIN digg-pp-cli # Pin the catalog installer; matches printing-press-library npm 0.1.16 default # ($HOME/.local/bin on macOS/Linux). PRINTING_PRESS_NPM mvanhorn/printing-press-library0.1.16 DIGG_INSTALL_CMD fnpx -y {PRINTING_PRESS_NPM} install digg --cli-only三个设计决策值得注意npm 包名固定到 semver 0.1.16该版本的目录安装器默认安装目录从$GOPATH/bin迁移到了$HOME/.local/bin。固定版本号保证 setup 向导与 CONFIGURATION.md 中给用户的命令、以及引擎的 PATH 门控三者始终指向同一安装位置只装 CLI--cli-onlylast30days 把 Digg 内嵌为引擎数据源而不是引入 pp-digg skill所以不需要 skill 接线Hermes/OpenClaw 上差异的只是 focused skill 的接线方式二进制位置两者完全相同都是$HOME/.local/bin300 秒超时安装过程可能涉及 npm 下载与 Go 二进制构建超时预算按最坏网络条件给足。CONFIGURATION.md的数据源表格中对此有明确约定Digg 的激活条件是digg-pp-clion PATH首次运行 setup 时通过npx -y mvanhorn/printing-press-library0.1.16 install digg --cli-only自动安装二进制默认落在$HOME/.local/binHermes/OpenClaw 的 Agent 子进程必须继承该目录的 PATHDigg 才能激活。修复要点二安装结果五分类杜绝虚假成功修复后的_install_digg_cli()setup_wizard.py返回四元组(engine_active, action, stderr, off_path_binary)其中action是一个五值分类action触发条件引擎是否激活状态文案行为already_installedshutil.which(digg-pp-cli)一开始就解析成功是Digg CLI already installed (AI-news clusters active)installednpx 安装后shutil.which解析成功是Installed Digg CLI (... now active)installed_off_path二进制在已知安装目录存在且可执行但不在 PATH 上否给出具体路径与可复制粘贴的 PATH 目录提示重启 Agent 会话/网关install_failednpx 退出码非零或安装后两处探测均未找到否附digg_stderr提示手动执行DIGG_INSTALL_CMDno_npx系统上找不到npx否提示先安装 Node/npx 再执行安装命令关键约束是already_installed/installed只在shutil.which解析成功时才允许出现——与pipeline.available_sources()的门控完全同谓词。而installed_off_path是专门为磁盘上存在但 PATH 不可见这种 Hermes/OpenClaw 常见失败模式准备的诚实出口。候选目录探测与安装器共享单一来源探测 off-path 二进制的目录列表没有另起炉灶而是从health模块的共享清单派生setup_wizard.pydef _digg_bin_candidate_paths() - list[Path]: Known install locations for digg-pp-cli (Printing Press library defaults). Order: current installer default (~/.local/bin), legacy Go bins, Windows managed dir. ... from . import health win_dir health.windows_printing_press_bin_dir() candidates: list[Path] [] for directory in health.installer_bin_dirs(): if win_dir is not None and directory win_dir: candidates.append(directory / f{DIGG_CLI_BIN}.exe) else: candidates.append(directory / DIGG_CLI_BIN) return candidates而 health.py 中这个清单的定义是~/.local/bin当前安装器默认macOS/Linux$GOPATH/bin若设置了GOPATH遗留 Go 目录~/go/bin遗留 Go 目录Windows%LOCALAPPDATA%/Programs/PrintingPress/bin且该目录下的候选名带.exe后缀windows_printing_press_bin_dir()在非 Windows 上返回None。两个探测函数的分工在源码中写得很清楚def _digg_on_path() - Optional[str]: Return digg-pp-cli when the engine would activate Digg (PATH-resolvable). return shutil.which(DIGG_CLI_BIN) def _digg_off_path_binary() - Optional[str]: Return digg-pp-cli path from known install dirs when not on PATH. for candidate in _digg_bin_candidate_paths(): if candidate.is_file() and os.access(candidate, os.X_OK): return str(candidate) return None注意注释里的一句话探测这些目录只用于 setup 验证与诚实的 off-PATH 消息不用于引擎激活。这正是What Didnt Work第一条的教训——旧逻辑把某处存在二进制当作已安装探测~/go/bin但没有 PATH 可见性造成假阳性引擎门控与 setup 验证必须各守其位。安装流程的状态机_install_digg_cli()的完整判定顺序setup_wizard.py_digg_on_path()命中 →already_installed直接返回未命中则查_digg_off_path_binary()命中 →installed_off_path复用之前 pp-digg 的安装不重复装、也不谎称已激活都未命中才调用_run_npx_install(digg)执行npx -y mvanhorn/printing-press-library0.1.16 install digg --cli-only该子过程setup_wizard.py用shutil.which(npx)解析出 npx 的绝对路径再作为 argv[0] 传入——这是为了修复 Windows 上 PATHEXT 不匹配的问题裸字符串npx不会触发.CMD解析会以WinError 2失败npx 返回非零或异常 →install_failed并携带 stderrnpx 返回 0 后重新执行双探测PATH 上出现 →installed只出现在候选目录 →installed_off_path把 npx 的非致命 stderr 一并记录两处都没有 →install_failedinstall completed but digg-pp-cli was not found。第 5 步的安装后复验是整个修复的关键安装器进程退出码为 0 不代表二进制对当前进程可见必须以引擎自己的门控再做一次判定。状态文案off-path 时给出可操作的 PATH 提示get_setup_status_text()setup_wizard.py把五分类渲染成用户可读的文案。installed_off_path分支会调用_digg_bin_dir_hint()把二进制路径折算成可复制粘贴的 PATH 目录$HOME/.local/bin形式Windows 用绝对路径并明确提示add ... to PATH and restart your agent session/gateway for Digg to activate——重启 Agent 会话是必要步骤因为子进程 PATH 在会话启动时继承。修复要点三OpenClaw 服务端对等支持旧实现中setup --openclaw完全跳过 Digg 安装只覆盖桌面 NUX。修复后的run_openclaw_setup()setup_wizard.py在服务端 JSON 探针中执行同一套_install_digg_cli()digg_installed, digg_action, digg_stderr, digg_path _install_digg_cli() ... payload: Dict[str, Any] { yt_dlp: yt_dlp, node: node, python3: python3, digg_cli: digg_installed, digg_action: digg_action, keys: keys, x_method: x_method, } if digg_path: payload[digg_path] digg_path if digg_action install_failed and digg_stderr: payload[digg_stderr] digg_stderrJSON 输出字段digg_cli引擎是否激活、digg_action五分类之一、可选的digg_pathoff-path 二进制路径与可选的digg_stderr安装失败详情让 SKILL.md 驱动的模型在服务器场景下也能呈现与桌面 NUX 一致的、诚实的 Digg 状态。这套模式如何推广到其他 Printing Press 源同一套固定安装器 双探测 五分类模式在 setup_wizard.py 中被参数化复用到了其他默认开启的 Printing Press 源上PP_DEFAULT_SOURCES [(arxiv, arxiv, arxiv-pp-cli), (techmeme, techmeme, techmeme-pp-cli)]由_install_pp_cli()/install_default_pp_sources()执行返回结构与 Digg 完全一致。Trustpilot 则被有意排除在自动安装之外它默认关闭属于INCLUDE_SOURCESopt-in 源且使用无头 Chrome 收割 cookie为默认关闭的源预装二进制是浪费Bright Data 同样是只报告、不安装它消耗用户自己的计费额度获取与否由用户决定。这些例外与 Digg 的主路径共同构成 setup_wizard.py 中统一的 action 分类学。测试覆盖与验证修复的关键行为都有对应测试用例集中在 tests/test_setup_wizard.pyoff-path 检测路径digg-pp-cli位于~/.local/bin但不在 PATH 上 → 期望digg_action installed_off_path且不触发 npx约 L384-L398npx 安装 rc0 但二进制落在$HOME/.local/bin且不可见 → 同样判定installed_off_path约 L405-L424状态文案路径installed_off_path的各种情形含遗留~/go/bin位置、digg_path缺失或为空在get_setup_status_text()下均生成带 PATH 修复指引的文案约 L771-L805Bright Data 的三态报告already_installed/installed_off_path/not_installed也验证了引擎门控原样透传、从不夸大 active的同一原则约 L892、L931。这与解决方案文档 Prevention 一节的测试要求一致Hermes/OpenClaw 场景要用重定向的HOME与 mock 的 PATH 覆盖OpenClaw 服务端镜像桌面 NUX 时要在 JSON 中加入对应字段。可复用的预防规则解决方案文档最后沉淀了四条预防规则适用于任何新增CLI 门控数据源的引导逻辑对齐上游安装器的默认 bin 目录并固定 npm semver——安装位置是契约不是假设成功消息必须使用与available_sources()相同的探测谓词shutil.which磁盘上存在但 PATH 不可见的情况走独立的 off-PATH 结果分支测试用重定向HOME mock PATH 覆盖 Agent 网关场景服务端 setup 镜像桌面 NUX 时同步扩展 JSON 字段改动可选源引导前先在docs/solutions/下检索digg、setup-wizard、agent-path等关键词——本方案文档docs/solutions/integration-issues/digg-cli-agent-path-setup-wizard.md即为此类集成问题的登记入口。关键文件索引文件作用setup_wizard.py首次运行向导Digg 安装器常量、候选目录探测、五分类安装流程、OpenClaw JSON 探针digg.pyDigg 源适配器shutil.which可用性门控、search/postsCLI 调用pipeline.pyavailable_sources()引擎侧按which(digg-pp-cli)激活 Digghealth.pyinstaller_bin_dirs()/windows_printing_press_bin_dir()安装器目录单一来源test_setup_wizard.pyoff-path 检测、状态文案与 OpenClaw 输出的测试覆盖CONFIGURATION.md数据源表格Digg/arXiv 的 PATH 激活条件与安装命令SKILL.md、AGENTS.md、HERMES_SETUP.mdStep 0 引导与 CLI 门控源的文档约束【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考