治理编排器

它解决什么问题

技能库规模上来后，治理工具往往是散装的：zfl-skill-quality-checker 管质量分、面板噪声和触发词各有脚本、PDCA 验证器又另一套。把它们手动串成一次完整巡检，需要记住每个脚本的参数、解析各自的 JSON 输出、再汇总成报告——这在多台机器、部分技能缺失的现实里很容易半途而废。更麻烦的是「这次修完了，下次会不会悄悄回退」没有答案。

它如何工作

编排器把六个子技能串成 discover → cleanup → trigger → privacy → rate → plan → execute 的管线，外加可选的 render 看板、Stage 6 修复和 Stage 7 回归门禁。核心机制有三个：

• 优雅降级契约：每个阶段先探测目标技能可用性——目录不存在、frontmatter 禁用、脚本缺失或执行超时，一律记入 degradations[] 并继续；即使六个技能全缺，也产出合法空报告并 exit 0。
• PDCA 统一整改入口：plan 阶段把全部问题交给 zfl-pdca-verification-pattern，由它自判走标准编号核验还是通用整改追踪；闭环门禁读 verify-cmd 的真实退出码，有 flag 即判 reopened，绝不假闭环。
• 安全修复边界：--improve 只出 dry-run 计划；--apply 仅执行白名单安全子集（补 BOM、五源版本对齐、剥 G1 水印），全部先备份可回退；G7 乱码、写死机器路径等高危项只列人工命令，永不自动。

此外，--save-baseline 建立全量分数快照（含健康技能），配合棘轮护栏让回退可见：分数降 ≥10 或新增 P0 flag 即触发红字告警，基线守底不下移。严重度感知路由保证只有 P0 问题进入整改管线，软性建议不会误拦发布。

适用边界

它只做编排与降级，不替代六个技能本身；默认只读，升级/发布只产出 handoff 命令；多角色 LLM 评审与工厂实际执行仍需在对应技能里独立触发。--skills-dir 只决定审计范围，探测始终基于本机，不跨机器同步。