用途
该技能用于排查和验证一类“配置失败开放”的缺陷：许多配置格式会接受它们不理解的键，例如 HOCON、无 schema 的 JSON、大多数 YAML 消费者、.desktop 文件、property list、manifest 方言等。拼写错误的键、放在错误嵌套层级的键，或在工具版本之间迁移的键，不会产生错误、警告或提示。
这使一整类缺陷变得不可见：失败状态与工作状态在仓库内部看起来完全相同——同一个文件、同样绿色的构建、同样的沉默。唯一不同之处在于生成的产物。
主要能力
- 识别“配置失败开放”的陷阱：重新读取配置不能证明任何事；审查者检查“键拼写是否正确 / 是否在文件中”无法发现层级错误；跨版本 diff 配置也无法发现。
- 将配置驱动的功能分为三种状态：已观察到工作、已观察到损坏、从未被观察。第三类正是此类缺陷所在，且在仪表盘上不可见，因为没有任何红色告警。
- 提供决定性实验：两次构建仅键位置不同，对两棵输出树做
diff -r，再对每个产物 grep 该功能的指纹。 - 提供指纹表：自定义 URL scheme（macOS 为
CFBundleURLTypes/CFBundleURLSchemes，Linux 为MimeType=...x-scheme-handler/<scheme>，Windows 为每用户Software\Classes\<scheme>键及URL Protocol）、Linux 启动器元数据（[Desktop Entry]组内的键）、运行时标志（启动脚本 / Info.plist 环境字典 / 生成的 .cfg）。 - 强调检查用户实际获得的产物，而非工具输出的产物：若后续层重新包装输出（例如目录树打包为便携单文件包，其启动脚本安装自己的启动器元数据），则那个后续文件才是操作系统读取的文件。
- 通过下载最近几个已发布产物并运行相同 grep，确定实际回归窗口和需要在发布公告中注明的版本列表。
- 一旦证明，就加入断言：对构建树做 grep 并在失败时以非零退出，作为 CI 步骤紧挨打包步骤，而不是放在单独的测试套件中。
- 指出同一形态在其他场景中的出现：对可空列的查询过滤器静默匹配空并报告成功；在多个触发路径之一添加的守卫，其他路径提前返回；从加载器从不查看的键读取的功能标志，默认为“off”。
使用方式
技能给出可运行的验证命令（均从仓库根目录运行，conveyor.conf 为相对路径）：
检查历史性错位是否回归：
CONF=conveyor.conf # your packaging config
grep -n '^\s*url-schemes\s*=' "$CONF"
grep -nE '^\s*(mac|windows|linux)\.url-schemes\s*=' "$CONF"
awk '/^(app|mac|windows|linux) *\{/{blk=$1} /url-schemes *=/{print blk}' "$CONF"
通过条件：第一条找到赋值；第二条不输出任何内容（没有点号形式的按 OS 写法）；awk 行输出 app，绝不输出 mac/windows/linux。
检查同一文件中第二种静默错位形态——条目位于 "Desktop Entry" 组内，而非旁边：
grep -n 'desktop-file\."Desktop Entry"' "$CONF"
grep -nE '^\s*desktop-file\.[A-Za-z]+\s*=' "$CONF"
通过条件：第一条找到组开启符；第二条（该文件注释中描述要替换掉的损坏兄弟形式）找不到任何内容。
对照机器上任何已构建的 .app 检查指纹表命名的是真实键而非猜测（多数现代 Info.plist 是二进制，需用 -a 匹配）：
APP=$(find /Applications -maxdepth 3 -iname "Info.plist" -exec grep -la "CFBundleURLTypes" {} \; 2>/dev/null | head -1)
plutil -p "$APP" | grep -A3 "CFBundleURLTypes"
通过条件：$APP 非空，且打印的块显示 CFBundleURLSchemes 嵌套在 CFBundleURLTypes 内。
手动步骤（需要全新打包构建，不在上述命令中运行）：将 macOS 打包两次，一次把 url-schemes 放在 app 层级（当前做法），一次移回 mac { } 下（历史缺陷），然后 diff 两个 Contents/Info.plist。可观察结果：CFBundleURLTypes 恰好出现在两个构建之一中，证明哪个位置合法绑定。
产物指纹 grep 示例：
# adapted — run against the built tree, not the source tree
grep -R 'CFBundleURLSchemes' -A6 output/*.app/Contents/Info.plist || echo 'NOT REGISTERED'
grep -R 'x-scheme-handler' output/*.desktop || echo 'NOT REGISTERED'
CI 断言示例：
# adapted — CI step, right after packaging
for f in output/*.app/Contents/Info.plist; do
grep -q 'CFBundleURLSchemes' "$f" || { echo "::error::URL schemes missing from $f"; exit 1; }
done
适用场景
- 打包与发布流程中，配置键只影响已安装产物（如 URL scheme 注册、启动器元数据、运行时标志）。
- 使用会忽略未知键的配置格式（HOCON、无 schema JSON、多数 YAML、.desktop、plist、manifest 方言）的项目。
- 需要确定某个键在哪个层级合法绑定、或需要确定回归窗口与受影响版本列表时。
- 更广泛地，任何“无法失败的操作”连接到“无人观察的功能”的场景：可空列查询过滤器、多触发路径中的守卫、加载器不读取的功能标志。
限制
- 资料未提供该技能的安装命令、平台支持范围、收费或价格信息。
- 手动步骤需要全新打包构建，无法在普通检查中运行。
- 指纹表针对特定功能与平台，其他功能需自行确定对应指纹。
- 缺失指纹只能说明当前产物未注册，无法直接说明缺失持续了多久，需下载历史发布产物逐一 grep。