用途与实际影响
这项功能怎样使用
为什么需要它
登记可能陈旧，现场读取也可能因为权限、设备离线或 Provider（现场读取器）失败而不完整。把“看不全”都写成故障会诱发误修，把未知写成通过又会埋雷；每次把所有验收从头跑到底，也会浪费时间并触发无关依赖。这里把处置级别和证据结论拆开，还允许精确点名检查区域。
举个实际例子
比如账本记着 87 个计划任务，而当前普通用户视角只看到 84 个。系统不会马上喊“丢了 3 个任务”，而是告诉我这次视野不完整、任务定义差异仍待确认，同时把已经看见的任务运行结果单独检查。只有取得完整的只读现场后，才会把定义差异判成一致或不一致。
最后我会得到什么
得到一张可行动的检查单：哪些和登记一致、哪些确实不符、哪些因为权限或设备不在线还看不全，以及应由哪个项目修。这个检查本身不擅自改配置。
正常时
只对这次点名并完整检查的机器部分说已证一致，附上实际看到的范围。
发现问题时
看见具体差异时指出影响和处理入口，修好后再查同一项。
入口不可用或证据不足时
权限不足、设备离线或读取超时时标成无法确认，不算通过，也不拿空结果说设备不存在。
从哪里开始
在已接入 PCConfig 的 AI 对话中说“只检查”并点名机器事实区域；需修复时另说明具体目标。
需要准备什么
- 检查区域，例如任务、运行时或恢复
- 当前机器
- 是否只读
从开始到拿到结果
- 1
选最小检查
AI 先确定本次决定依赖哪类机器事实，不为一个小问题全机扫描。
- 2
分开状态与证据
读取登记、现场可见范围及检查结果，明确差异、证据不足和未检查。
- 3
交回下一步
具体差异交相应负责人修；看不全时提供重查入口，不把未知写成故障或通过。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
2026-09-09 22:12 UTC管理员完整现场7pass、0warn、1block；94任务对94账本、定义差异0，运行时/重建计划/核心恢复通过；仅Ollama历史失败保留，同入口随后结果0且当前接口可达关键规则与设计选择
status=pass|warn|block 表示当前处置级别，evidence_status=pass|fail|unknown（未验证） 表示证据结论；两条轴必须同时读。
真实不匹配是 fail；完整性不足是 unknown（未验证）；已证明但只需提醒的陈旧证据可以是 warn/fail，不能靠一个颜色覆盖语义。
任务定义 tasks.live_match 与任务运行结果 tasks.runtime_health 独立；定义可见性不足不等于任务业务失败，LastTaskResult 信息码也不自动算失败。
Test-PCConfigDrift -NoWrite 与 Get-DevStorageHealth 是 zero-write（零写入）；acceptance 的 NoWrite 不改 PCConfig 报告/Registry（登记清单），但被选 Owner check 可能创建并删除有界临时产物。
acceptance selector 采用 area 与 check ID 的精确交集；任一不存在或交集为空时，在启动任何检查前返回 selection error。
只运行会改变本次决定的 area/check；未选项不进入 selected_items 或 results，也不能被写成通过。
任务差异只返回有界 task key、计数和 changed_fields 字段名，不返回完整 Action、参数、trigger 或旧/新值。
验收结论只证明机器事实证据，不反向拥有 Git admission（仓库准入检查）、Skill 供应、项目业务状态或公开发布。
本模块用到的名词
- Drift（漂移）
- 登记、合同或稳定投影与当前现场不一致；它可能是需修故障，也可能只是快照尚未刷新。
- Status（处置状态）
- pass、warn、block 表示当前应继续、关注或停止的策略结论，不等于证据真假本身。
- Evidence status（证据状态）
- pass、fail、unknown（未验证） 表示当前证明满足、证明不满足或无法证明；unknown（未验证） 永远不是 pass。
- Stable check ID（稳定检查标识）
- 跨版本保持含义的检查名，用于定向选择、Owner 交接和修复后重验。
- Area selector（区域选择器）
- 只运行某一产品区域的检查；与 check ID 同时给出时取精确交集。
- Complete visibility（完整可见性）
- 当前身份能看到足够完整的系统对象；普通用户的部分任务列表不能证明定义一致或缺失。
- Bounded evidence（有界证据）
- 只返回会改变判断的计数、稳定字段和有限差异，避免泄露完整参数或淹没注意力。
- NoWrite（不改权威状态）
- 不改 PCConfig Registry（登记清单）/报告；acceptance 中的 Owner check 仍可能按合同创建并删除有界临时验证产物。
专业定义
回答“账本和电脑现场到底对不对得上、证据够不够、真有问题该找谁修”，并支持只查眼前关心的一项。
解决什么
旧式健康检查容易把命令 exit 0 当全局 PASS、把权限不足当对象不存在、把任务定义和业务结果混在一起，或者为了“完整”每次运行全套脚本。这样既会误修，又无法从结果恢复。漂移与验收层必须保留稳定 ID、双状态、精确选择、超时和有界证据，才能在现场变化时仍给出同一种可理解答案。
当前怎样实现
- Test-PCConfigDrift.ps1 -NoWrite 输出 pcconfig.drift.v2：每个 check 有稳定 id、domain、status、evidence_status、message 与有界 evidence，summary 分别汇总策略计数和证据计数。
- 当前检查集包括 registry.schema、tasks.live_match、tasks.runtime_health、tasks.path_integrity、runtimes.live_match、drives.dev_storage 与 recovery.core_contract；新增检查必须保留 owner、状态域和输出边界。
- tasks.live_match 在完整可见时比较 registry_count、observed_count、added/removed/changed；最多返回 20 条清理后的 task key 和 changed_fields 名称，超出以 *_truncated 标记。
- tasks.runtime_health 只评估 managed-core 的 LastTaskResult 与可选结构化 Owner receipt（执行回执）；Scheduler 状态码、真实失败、历史已恢复结果和外部 Owner unknown（未验证） 分开计数。
- runtimes.live_match 调当前运行时 Provider；drives.dev_storage 调 V/Z 健康 Provider；recovery.core_contract 同时核对 manifest（清单）、任务 Inspect 与维护 Inspect，不用一个文件代替整条合同。
- acceptance_checklist.json 登记 area、check ID、blocking、命令、超时、隐私边界、trigger 和 acceptance；Invoke-PCConfigAcceptance 只执行 selector 交集并返回 selected_items。
- selector 支持数组或逗号分隔、大小写不敏感但必须精确匹配；未知 area/check、空交集或 checklist schema（数据结构） 错误都 selection.status=error、exit 1、零检查启动。
- 每个 owner check 的 stdout、stderr、超时和 exit code 被转换为 pass/fail/unknown 与简短 output_excerpt；原始大日志、秘密和完整任务定义不进入公共结果。
- 按需排障先消费结构化摘要；只有一个 check fail/unknown（未验证） 时才读取它指向的 owner 证据，避免加载整份历史报告或无关机器状态。
- 验收器不自动修复：Registry（登记清单） 漂移交 Registry（登记清单） Owner，任务交任务/项目 Owner（项目责任方），运行时交 PCConfig/组件 Adapter（执行适配器），恢复数据与秘密继续走各自专用入口。
执行流程
- 1
先写清当前决定依赖哪类机器事实：任务、运行时、开发盘、恢复、秘密入口或完整收尾。
- 2
选择最小入口：快速 drift 摘要、单个 live Provider，或 acceptance 的精确 area/check；不为普通项目收尾机械全跑。
- 3
读取 execution_status 与 selection；selector 错误时确认零检查已启动，再修正名称而不是解释空结果。
- 4
逐项同时读 status 和 evidence_status：pass/pass 是已证，warn/fail 是已证但只需关注，warn/unknown（未验证） 是证据不足，block/unknown（未验证） 是关键证据无法成立。
- 5
核对 evidence 的观察范围、complete_visibility、计数、截断和时间；不拿旧 Registry（登记清单） 或旧报告补现场缺口。
- 6
把 tasks.live_match、runtime_health、path_integrity 等相邻但不同结论分开，不用一个通过项覆盖另一个未知。
- 7
明确差异时转给对应 Owner，带上稳定 check ID、最小 evidence 和重新验证入口；验收器不直接修改真实配置。
- 8
修复后重新运行同一精确 check/area；只有当前证据转为 pass 才收口，未选择或无法运行的项继续保持未知。
边界
- 不把 schema（数据结构） 正确、命令 exit 0、文件存在或一个 check PASS 推成全机健康
- 不把权限不足、Provider 超时、设备离线或上游未执行写成 absent 或 fail
- 不把 unknown（未验证） 折算为 pass，也不因 status=warn 就隐去 evidence_status=fail/unknown（未验证）
- 不把任务定义漂移、任务运行结果、业务 Owner 回执和历史结果混成一个状态
- 不在 selector 无效时启动任何检查，不把未选择项放进结果或总数
- 不输出完整任务 XML、Action、路径参数、旧/新敏感值、原始日志或秘密
- 不让验收器自动修改 Registry（登记清单）、注册任务、迁移路径、恢复秘密、推送 Git 或执行外部写入
- 不周期性全扫；只有机器事实或恢复状态会改变当前决定时才触发对应检查
失败与恢复
- tasks.live_match complete_visibility=false
- 保持 warn/unknown（未验证），显示 registry（登记清单）/observed 计数和有界候选；只有提升后的完整只读扫描能判定真实漂移。
- Provider、Registry（登记清单） 或 owner validator（校验器） 超时/失败
- 对应 check 保持 unknown（未验证） 并列出依赖与重试入口；其他已完成检查仍保留自身结论。
- Registry（登记清单） 与完整现场明确不同
- 标记 fail，并按风险选择 warn/block；修复真实来源或刷新 owning snapshot 后重跑同一 check。
- 任务非零结果是 Scheduler 状态码
- 按分类保留为运行状态，不自动算业务失败；有 Owner receipt（执行回执） 时再判断业务结论。
- area/check selector 拼错或交集为空
- selection error、exit 1、selected_items=[]，不执行 fallback（后备路线） 全套验收。
- 检查输出超过边界或含不允许字段
- 截断或拒绝该证据并保持 unknown（未验证）；不能为了给结论公开完整任务参数或日志。
- 修复后只看到旧报告变绿
- 重新调用当前 Provider/同一 check；旧报告只能解释历史，不能关闭当前漂移。
真实入口
E:\PCConfig\docs\contracts\pcconfig.drift-acceptance.md双状态、稳定 ID、选择器、有界证据与 Owner 边界合同
E:\PCConfig\tools\Test-PCConfigDrift.ps1机器事实与恢复合同的现场只读 drift 汇总
E:\PCConfig\registries\acceptance_checklist.jsonarea、check、blocking、超时、隐私与验收登记
E:\PCConfig\tools\Invoke-PCConfigAcceptance.ps1精确 selector、超时和有界结果的 acceptance runner
E:\PCConfig\tools\Get-DevStorageHealth.ps1V/Z 开发存储 zero-write Provider
E:\PCConfig\tools\Get-RuntimeInventory.ps1当前运行时事实 Provider
E:\PCConfig\tools\invoke_acceptance_checks.test.ps1selector、超时、unknown（未验证）、未启动项和输出边界回归
E:\PCConfig\tools\test_pcconfig_drift.test.ps1drift 双状态、任务差异、历史结果和零写入回归
如何验证
- 2026-08-31T17:49:27Z Test-PCConfigDrift.ps1 -NoWrite -Json 返回 schema（数据结构）=pcconfig.drift.v2、execution_status=completed、summary=6 pass/1 warn/0 block，证据为 6 pass/0 fail/1 unknown（未验证）
- 同次唯一 attention 是 tasks.live_match=warn/unknown（未验证）：registry_count=87、observed_count=84、complete_visibility=false；它是部分可见性，不是已证明任务丢失
- 同次 tasks.runtime_health、tasks.path_integrity、runtimes.live_match、drives.dev_storage 与 recovery.core_contract 均 pass/pass；两条 Scheduler 状态码未被误分类成失败
- drives.dev_storage 回读 5 pass、0 warn、0 block；CoreRecovery 维护状态 ready、warnings=0、当时Cold=additive_no_mirror、Git/云payload写入禁止；这是旧观察，当前Cold已按登记有效保留集验真后清理H旧副本
- 先前精确 core_recovery area 验收返回 manifest_contract、maintenance_inspect、task_contract 三项 PASS；只证明该 area，不代表未选择区域
- invoke_acceptance_checks.test.ps1 与 test_pcconfig_drift.test.ps1 分别覆盖 selector 零启动、超时/unknown（未验证）、有界输出和 drift 双状态；测试证据不替代当前 live Provider
与其他模块的关系
机器事实、运行时、恢复、副驾驶、秘密和受保护数据模块各自产生 Owner 证据；本模块只负责把这些证据按稳定 ID、双状态和精确选择组合成可行动结论。它不接管修复，也不把项目/Git/Skill 的上游验收吞进 PCConfig。