PDCA U/D/R 三段式核验模式
> 一句话：把「这条标准/知识还有效吗？」变成可量化、可追溯、可闭环的动作。
> AI 辅助声明：本技能输出由 AI 辅助生成，核验结论（现行 / 被替代 / 已废止）仅供参考。AI 不背书任何外部标准的真实有效性；联网核验结果取决于你配置的端点/门户，本技能不对其真伪负责。正式合规场景（标书、竣工资料、审计、合规签字）须以官方发布或人工核对为准，本技能不对任何结论承担法律责任。
本技能提供一套离线优先的核验方法论 + 可直接运行的引擎（scripts/pdca_runner.py）：
Update（知识更新）→ Detect（问题检测）→ Resolve（治理执行）。
默认用本地缓存（references/standard-database.json）即可跑通；配置 --endpoint 后自动叠加联网核验，断网/超时优雅降级，绝不崩。
① 30 秒上手（Quick Start）
| 你想做什么 | 怎么做 | 你会得到 |
|---|---|---|
| 跑通看看 | python scripts/pdca_runner.py --self-test |
端到端自检通过提示 |
| 核验几个标准 | python scripts/pdca_runner.py --refs "YD/T 5187-2018,GB 50312-2016" |
JSON 核验报告 |
| 从文件读引用 | python scripts/pdca_runner.py --refs-file refs.txt |
同上（每行一个编号） |
| 纯离线不出网 | 加 --no-network |
仅用本地缓存，结果带 cached 标记 |
| 联网核验 | 加 --endpoint "https://你的源?q={ref}" |
叠加 TIER 1 官方源，超时自动重试+降级 |
> 预期输出（节选）：
> json
> {
> "verify_time": "2026-07-26 20:30",
> "mode": "离线优先",
> "results": [ { "ref": "YD/T 5187-2018", "status": "现行", "staleness": { "score": 0.9, "level": "🟢 当前有效" } } ],
> "summary": { "total": 1, "current": 1, "superseded": 0, "abolished": 0, "not_found": 0 },
> "resolve_actions": [ "无需治理：全部引用当前有效" ]
> }
>
② 标准用法（手把手）
第 1 步：准备引用清单
新建 refs.txt，每行一个标准/知识编号（# 开头为注释）：
通信工程常用标准
YD/T 5187-2018
GB 50312-2016
第 2 步：运行核验
- 不加 --no-network 也不会主动出网，除非你给了 --endpoint。
- --output 把报告写成文件，省略则打印到终端。
第 3 步：读报告，做治理
看每条的 staleness.level：
- 🟢 当前有效 → 不用管
- 🟡 建议更新 → 排期复核
- 🔴 已过时 → 立即更新
- ⚪ 未命中-待补充 → 核对编号或补来源
报告的 resolve_actions 已按上述规则自动生成待办清单。
③ 进阶（联网核验 / 多源配置 / 自定义缓存）
3.1 单源快捷方式
--endpoint "https://std.example.com/lookup?q={ref}"：引擎对该 URL 做 HTTP GET，期望返回 {"status":"现行|被替代|已废止"} 的 JSON（支持 status_path 点分路径，如 result.status）。
3.2 多源配置（A）—— endpoints.json
把多个 TIER-1 源写进 references/endpoints.json，引擎自动全部加载并参与共识判定（一致率 ≥2/3 可信）。模板见该文件，每条结构：
- type=json：端点返回 {"status":"..."}（或 status_path 指定的字段）。
- type=html：见 3.3。
- 常用参数：--endpoints-file /path/to/other.json 换配置；--source 源名称 只启用指定源（可多次）。
- 所有源不可达时自动降级本地缓存，绝不崩。
3.3 HTML 适配器（B）—— 直接吃官方门户
没有标准 JSON API？把官方门户 URL 配成 type=html，引擎自己抽页面文本扫状态关键词：
- 引擎用标准库 html.parser 抽可见文本，扫描 keywords（默认 ["现行","被替代","已废止"]）。
- region：可选正则，限定只在该区域文本内扫描（门户结构复杂时提高精度）。
- ⚠️ 标准库无 CSS 选择器引擎，采用「全文关键词」策略；页面未直接出现状态词时会判为「未含有效 status」并降级，不会误报。对精度要求高请改用 type=json 自建代理。
3.4 其他
- 强制刷新：
--force-refresh忽略本地缓存，重新走全部可用源。 - 换缓存：
--cache /path/to/your.json指定自己的标准库（schema 见references/standard-database.json）。
> ⚠️ 联网核验需要你提供可信的官方端点/门户。技能本身不内置任何硬编码外网地址，避免「假联网」误导结论；HTML 适配器仅做文本匹配，正式合规场景仍须人工核对官方发布。
知识陈旧度评分（0-10 分）
| 维度 | 权重 | 评分规则 |
|---|---|---|
| 标准/政策时效 | 40% | 现行=0，被替代/已废止=10，待确认/未知=5 |
| 更新时间 | 30% | <30天=0，30-180=3，180-365=5，>365或缺失=8 |
| 来源一致性 | 20% | 多源一致=0，部分一致=5，无法确认=10 |
| 引用格式规范 | 10% | 规范=0，不规整=5 |
| 等级 | 分数 | 行动 |
|---|---|---|
| 🟢 当前有效 | 0-3 | 无需处理 |
| 🟡 建议更新 | 4-6 | 定期复核 |
| 🔴 已过时 | 7-10 | 立即更新 |
| ⚪ 未命中-待补充 | 评分 NA | 人工核实编号或补充来源 |
缓存与性能策略（与引擎一致）
输出规范（完整字段）
⑤ 闭环配方扩展：代码 Bug 修复闭环（v1.3.1 新增）
PDCA 原本聚焦标准时效闭环（编号变红 → 派单 → 复跑变绿）。但「验证改对没」的闭环纪律同样适用于代码 Bug 修复。以下配方补上这一类：
- D（Detect 检测）：只读诊断，先确认「坏在哪、影响面多大」，不动手。
- R（Resolve 治理）：改代码/配置。
- 回归探针（新增环节）：针对原失败模式写/跑一个最小探针，证明同样输入下不再复现。例：原 Bug 是路径截断误删 → 探针喂带空格引号路径，断言不再误删。
- Check（门禁复跑）：重跑发布/一致性门禁（如
five_source_check、技能自检self_test.py/run_regression.py），变绿才闭环；任一仍红则回到 R。 - Act（发布/生效）：门禁全绿后发布或落地。
> 实例：系统修复模块 3 个灾难级 Bug——只读诊断出 6–7 个悬空右键菜单 → 修 Resolve-TargetPath/catch{continue}/正则 → 重跑 five_source_check 一致1/0 → 发布 SkillHub，验证 live 才关。
> 关键纪律：Check 步骤必须有牙齿（门禁抓出 _meta.json 漏改正是例子），且修完必须针对原失败模式跑回归探针，不能只靠「看起来改了」。
⑥ 代码改动验收闭环：反轻信核验 + 门禁集 + 再触发条件（v1.3.3 新增）
PDCA 不只用于「修自己的 bug」，也适用于验收别人 / 别的会话声称「改完了」的改动。这类场景的最大陷阱是轻信声明——对方说"跑通了"就信，结果门禁早被破、回归已发生。本节纪律专治这个。
6.1 反轻信核验法（Check 阶段核心）
> 规则：「做完了 / 跑通了」不是证据，是待验证的声明。 任何闭环前必须独立取证，不依赖当事人描述。
取证两件套（对任何有 git 的 web 项目通用）：
1. git 核对代替凭消息判断：git status + git log <上次基线>..HEAD + git diff --stat HEAD。看清「到底改了哪些文件、哪些 commit、是否夹带破坏门禁的改动」。
2. 隔离端口启动冒烟：另起一个隔离端口（如 PORT=3140，绝不动正在跑的生产/预览实例 3137），拉关键路由确认服务真能起、资源真能载：
- 关键：隔离端口 + 验完 kill，避免污染正在使用的实例。
- 语法快检先排低级错：node --check server.js / node --check 关键脚本.js，再做冒烟。
6.2 门禁集（把「验收标准」固化成可复跑清单）
闭环前先定义硬门禁（以「负向断言」为主，守住即绿）：
- 示例（前端 / 多端改造）：① 页面零平台硬编码（业务页不得直接 wx./dd. JSBridge，只允许在 bridge 适配层）；② 375px 无横滚（overflow-x:clip）+ 安全区 env() 留白；③ 依赖零外部化（图表/组件不得引 CDN/外部库，守住离线/PWA）；④ 启动冒烟全 200。
- 每次复跑只 grep / curl 这些断言，不重新读整份代码——把"验收"降维成"跑门禁"。
6.3 闭环后的「再触发条件」（避免无脑重跑 / 漏掉真回归）
闭环 ≠ 以后永不验。定义明确的再开门信号：
- 出现以下任一 → 立即重跑门禁：新增平台硬编码（wx./dd. 裸露业务页）/ 横滚回归 / 删除 safe-area / 图表改引外部 CDN / 他人声称「又改一波」。
- 否则维持「已完工 + 已闭环」，不再重做整套诊断。
- 纪律：再触发条件要写进交付物（报告 / 日志），让后续会话一眼知道"何时该验"。
6.4 实例（某 web-app 多端会诊）
- 基线
<commitA>，对方声称"改完" → 反轻信核验发现 7 commit，其中<commitB>多端增强、charts.js零依赖、门禁①②仍 PASS。 - 门禁集复跑全绿 + 隔离端口 3140 冒烟全 200 → 闭环。
- 再触发条件写入会诊报告；后续企微接入只做真机验收，不重做会诊。
> 关键纪律：Check 必须独立取证，不能只信「改完了」；门禁集让复跑可机械化，再触发条件防止无脑重跑。
④ 通用整改追踪模式（v1.3.2 新增）
「标准时效核验」之外，PDCA 现在也是通用整改追踪器：任何无编号的问题（缺字段、坏脚本、依赖漂移、文档短板……）都能进闭环，且 Check 门禁由你提供的外部命令判定「改对没」。
核心契约
- 输入：--issue "描述"（可多次）或 --issue-file（JSON 列表 / 纯文本每行一个）。
- Check 门禁：--verify-cmd "命令"，支持 {target} / {id} 占位符。强制门禁——不传则只产出计划、标记 not_closed_no_verify_cmd（不闭环）。
- 闭环判定：--verify-cmd 返回 0 → 该项 closed（变绿）；非 0 → reopened（回到 R）；全部变绿 → closed_loop=true、退出码 0；否则退出码 3（可被编排器当作 Check 门禁）。
- 与标准模式互斥：一次运行要么 --refs、要么 --issue，不能混用。
示例：把质量检查的发现接成闭环
{target} 会被替换成 zfl-foo / zfl-bar，quality_checker 复跑若零相关 flag → 该项闭环。
> 提示：这正是 zfl-skill-governance 编排器「plan 阶段」的底层引擎——通用问题不再由编排器原产计划，而是统一交给 PDCA 跑真实 Check 门禁。
⑦ 现场隐患整改闭环五要素（v1.3.6 新增）
PDCA 的 --issue 通用轴可直接承载现场安全隐患整改闭环——但这类闭环最容易"假闭环"：通知单发了、回复单收了，却缺字段、缺时序、缺复查结论，看似闭环实为断链。本节把"五个必填字段"固化成可机检断言。
闭环五要素（缺一即未闭环）
| 要素 | 含义 | 缺失后果 |
|---|---|---|
| ① 问题描述 | 部位 + 时间 + 数据 + 依据（禁"现场混乱"式主观表述） | 施工方可否认、无法定位 |
| ② 通知单编号 | 唯一编号，与回复单/复查记录一一对应 | 无法追溯，可伪造补录 |
| ③ 整改时限 | 明确到日的截止时间（禁"立即 / 限期 / 尽快"模糊词） | 施工方拖到完工后辩称已整改 |
| ④ 复查日期 | 监理复查的实际日期，须晚于整改时限 | 缺复查 = 指令成一纸空文 |
| ⑤ 复查结论 | 明确"合格 / 不合格 + 依据"，不合格须重新签发 | 无结论 = 闭环悬空 |
机检用法（挂 --issue + --verify-cmd，零新架构）
- 把每条隐患整改记录转成一条
--issue；--verify-cmd指向配套校验器scripts/check_closure_fields.py作为 Check 门禁：
python scripts/pdca_runner.py --issue-file issues.json --verify-cmd "python scripts/check_closure_fields.py --file records.json" - 判定：五要素齐全 + 描述无主观评价词 + 时限无模糊词 +
复查日期 ≥ 整改时限→ 返回 0 → 该项closed；任一不合规 → 返回 3 → 该项reopened（回到 R），不得闭环。 - 附加时序断言（可选）：
签发时间 − 隐患发现时间 ≤ 阈值，>4h 标「疑似补录，需人工核实实时性」——与zfl-supervision-notice的「线上履职合规衔接」同源。 - 校验器自带自检：
python scripts/check_closure_fields.py --selftest。
> 与 zfl-supervision-notice 的分工：通知单技能管单份文书写得对不对（措辞 / 依据 / 闭环要素落字）；PDCA 管一批隐患台账的闭环状态（五要素齐不齐、时序对不对）。两者共用同一套「五要素」字段定义，互为校对——通知单正文的字段 = PDCA 台账的字段，任一缺失即在对侧暴露。
能力的边界（何时不要用）
- ✅ 适合：有明确编号的标准/规范/政策时效性核验；多来源结论一致性比对；知识库陈旧度巡检与整改闭环。
- ❌ 不适合：
1. 单轮一次性问题（PDCA 是闭环迭代，单次问答用不上三段式）。
2. 纯主观质量判断（如文案优劣、设计美感）——评分维度是客观时效/一致性，不覆盖主观评价。
3. 要求 100% 权威结论的合规签字场景——本地缓存为示例数据，正式交付须接官方源或人工核对。 - ✅ 新增（v1.3.2）通用整改追踪：无编号的泛化问题现在支持——用
--issue/--issue-file派单，--verify-cmd提供 Check 门禁，按返回码判定「变绿闭环 / 未闭环回到 R」。详见下节。 - ✅ 新增（v1.3.3）改动验收闭环：验收他人 / 别的会话声称「改完了」的改动——反轻信核验（git 核对 + 隔离端口冒烟）+ 门禁集（可机械复跑的负向断言）+ 再触发条件（防无脑重跑 / 漏真回归）。详见 ⑥。
- ⚠️ 数值上限与精度：评分为启发式加权，用于排序与提醒，不是法律/认证结论；
cached_days基于last_verify字段，缺失时按「缺失」计（更新维度取 8 分）。标准库_meta.last_verified为全局最近核验日期，条目级last_verify驱动「更新时间」维度评分；距上次核验超过cache_valid_days（默认 30 天）会提示刷新缓存（见 P2 说明）。
使用场景与避坑指南
典型场景
- 竣工资料/标书里引用了一堆标准号，先批量核验哪些已作废。
- 知识库定期巡检：把条目编号导出成 refs.txt，每月跑一次看哪些变红。
- 整改闭环：D 阶段打分 → R 阶段按 resolve_actions 派单 → 下次跑验证变绿即闭环。
- 代码 Bug 修复闭环：D 只读诊断 → R 改脚本 → 回归探针验证原失败模式不复现 → Check 重跑发布门禁变绿 → Act 发布（见 ⑤）。
- 改动验收闭环：他人声称「改完了」→ 反轻信核验（git 核对 + 隔离端口冒烟）取证 → 门禁集复跑全绿 → 写再触发条件 → 闭环（见 ⑥）。
- 现场隐患整改闭环：每条隐患转 --issue，--verify-cmd 挂 scripts/check_closure_fields.py → 五要素齐 + 时序对才变绿（见 ⑦）。
避坑
- 坑1：缓存太久不更新 → 加 --force-refresh 或缩短 last_verify 周期。
- 坑2：编号写错导致全「未命中」→ 先小批量试跑，确认编号格式与缓存一致。
- 坑3：联网源返回非预期结构 → 引擎会优雅降级并标注「降级」，不会崩；检查端点是否返回 {"status":...}。
- 坑4：把示例缓存当权威 → references/standard-database.json 顶部已声明为示例数据，正式用请自建或接官方源。
FAQ（常见问题）
Q1：必须联网才能用吗？
不需要。默认纯离线，只用本地缓存即可完成核验与评分。联网是可选的增强能力。
Q2：为什么我的引用显示「未命中」？
本地缓存没有该编号，且未配置联网源（或联网也未命中）。请核对编号，或往 standard-database.json 补充条目，或接 --endpoint 官方源。
Q3：评分准吗？能当合规结论吗？
评分是启发式加权，用于排序与提醒，不是权威认证。正式合规场景请用官方源或人工核对。
Q4：怎么加自己的标准库？
复制 references/standard-database.json，按相同 schema 增删 standards 条目，运行时用 --cache 指定即可。
Q5：支持哪些标准类型？
不限定行业。引擎只认「编号 + status(effective/last_verify/format_ok)」结构，通信、建筑、IT 等任何带编号的规范都行。
Q6：多源结论冲突怎么办？
按「一致率」判定：≥2/3 可信，=1/2 部分一致，其余待确认；confidence 字段直接给出高/中/低，供你决策。
来源文件（本技能实际包含）
scripts/pdca_runner.py—— U/D/R 核验引擎（CLI + 自检，零外部依赖）references/standard-database.json—— 本地标准缓存（TIER 2，示例数据）references/endpoints.json—— 联网核验源配置模板（多 TIER-1 源，JSON/HTML 两种类型）tests/regression.json—— 固定回归用例集（现行/被替代/未命中/联网降级）tests/run_regression.py—— 回归测试 runner（stdlib-only，python tests/run_regression.py）scripts/check_closure_fields.py—— 闭环五要素齐全性校验器（⑦ 配方配套，--selftest自检）SKILL.md—— 本文档
触发关键词
PDCA核验 三段式核验 多源比对模式 知识陈旧度评分 TIER分级核验 标准时效性核验 闭环检查 改动验收 反轻信核验 门禁复跑 再触发条件 现场隐患整改闭环 闭环五要素
