用途与实际影响
这项功能怎样使用
为什么需要它
运行时路径会变，环境变量可能同时出现在两个作用域，登录启动和计划任务又不是一套机制。只看文件存在，会漏掉执行命令错误、运行身份不对、任务被禁用或最近结果非零；只看任务显示 Ready（就绪），也证明不了微信、远控或消息接口真的可用。
举个实际例子
比如我问“台式机重启后停在登录界面，我还能用 ToDesk 连回来吗？”系统会检查开机即运行的 SYSTEM 服务、独立看门狗和本次启动回执，并且不会为了试错去结束 ToDesk。即使机器侧链路都正常，也只说明本机准备好了；真正的登录前接入仍要在自然重启后由另一台设备实际连一次才能确认。
最后我会得到什么
拿到这个程序现在装在哪里、开机或登录后是否会启动、最近一次是否完成，以及真正的远控或消息功能是否可用。读不到现场时写明无法判断，不把“任务就绪”当成已经连上。
正常时
启动设置与程序运行一致时，再看这项服务是否真的完成本来要做的事。
发现问题时
文件还在但任务已停、身份或命令不对，或服务没有完成工作时，分别指出是哪一层。
入口不可用或证据不足时
计划任务或程序状态读不到时说无法判断，不把它写成不存在或成功。
从哪里开始
在已接入 PCConfig 的 AI 对话中点名软件、启动项或计划任务及当前电脑。
需要准备什么
- 软件或任务名称
- 开机、登录或手动启动场景
- 期望服务实际完成的事
从开始到拿到结果
- 1
区分启动发生在哪一段
系统查看问题出在开机服务、登录后任务还是手动打开的程序，不用“任务就绪”概括三种情况。
- 2
查配置和真实运行
AI 分开核对路径、任务身份、最近结果、服务状态及所属项目回执。
- 3
修复并验使用
有权限且目标清楚时由对应安装器修复；最后报告程序是否真实可用，任务显示就绪不足以证明远控或消息链成功。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
2026-09-09管理员完整现场与正式账本94/94项，任务定义差异0；MCP及维护和两项独立保护已登记。重建计划57项通过，Ollama历史失败与随后同入口成功、当前接口可达分别保留关键规则与设计选择
运行时当前值只信 Get-RuntimeInventory；冻结 Registry（登记清单） 只用于 drift 比较。
受管软件只有 behind 才更新，equal 不重装，ahead 不降级，unknown（未验证） 和 channel_mismatch 停止。
登录启动快照差异默认 informational（仅供参考），不会自动关闭或修复应用。
Task Scheduler 是任务运行权威，瞬时 Ready/Running 不进入稳定 drift。
无交互任务必须由验证过的父级 hidden launcher 创建无可见控制台的子进程。
ToDesk 的事故是服务重启后从 Auto（自动）退回 Demand（按需），让无人登录的主机失联；开机 SYSTEM 看门狗只恢复已签名的既定服务，返回 healthy/repaired（健康/已修复）元数据，不读取远控账号或密码，也不结束 ToDesk 来做验证。
微信双开在用户登录后触发，只补足两个健康顶层实例；已有两个时不再启动。冲突任务不覆盖、旧快捷方式可回退；两个进程只证明启动成功，扫码和两个账号登录仍需微信自身确认。
WeFlow 第二实例的可用性依赖持久 profile（配置目录），不能放在重启会丢失的缓存盘；看门狗只重连既定实例。目录缺失就停止而不是生成空库，接口能读只证明连续性，按账号名读消息还要单独确认 active-library（当前资料库身份）。
LocalGpuBroker（本地 GPU 调度器） 统一拥有客户端 32100 与内部 Ollama backend（后端）32101；OCR（文字识别）与 ASR（语音识别）可各持一份租约并行，避免语音输入无故等待 OCR（光学字符识别）。两份同类任务仍互斥，Ollama 会话/请求与任一外部租约也互斥；不是所有 GPU 工作全面放开并行。
TURZX看护曾因RTSS的帧率挂钩进入Windows PowerShell而崩溃。恢复RTSS时只恢复powershell.exe的应用排除，保留其他程序配置；若发送仍中断，继续由TURZX检查发送和自动恢复，不把排除文件存在当作实体小屏已经正常。
任务存在、exit 0 或 receipt（执行回执） 文件存在都不能单独证明业务成功。
计划任务重建清单只是恢复数据。旧 authorization（用户授权） 字段不再签发或阻断授权；每项仍按当前用户目标、依赖和原生入口执行。ChineseASR Dictation 的 Install 会注册并启动托盘，Status 才是只读核对，恢复时不能混用。
电脑日常小故障沿现有精确入口处理：微信只补健康实例，音频只选择已登记目标，卡住的修饰键只释放按键；鼠标主题被系统悄悄重置时自动恢复，守护进程退出后原任务补启；本人改选主题或恢复Windows原生方案时退出。显示拓扑恢复和 Xiaomi Share 看门狗各保留独立开关与回读。主屏 OLED 黑屏工具只是等待稳定版的历史恢复点，来源Owner于9月12日回传本人确认：修复后指针、HS2与白窗相关症状未再出现，机器记录也有KB5124008等更新和后续多次重启；这不是长期不复发保证，不能据旧源码重新安装或覆盖已退役补偿。
音响突然没声时，默认音频入口把Console（系统）、Multimedia（媒体）、Communications（通话）三个角色切到脚本选定的Realtek HD Audio 2nd output，再逐角色回读；设置调用成功但回读不一致仍报postcondition_failed。Ctrl/Alt/Shift/Win像卡住时，按键工具只发送这五类修饰键的松开事件，不重启应用。
主题切换、登录或睡眠回来后鼠标样式丢失，CursorSchemeGuard会核对受管方案再修复；本人改选另一方案时它自动退出，原生路径重新稳定时也会退役补偿入口，不要求人记得长期清理。显示拓扑恢复则只处理已证的单活屏NVIDIA/IDD竞态；它可能重启精确GPU并请各显示Owner恢复窗口，条件不匹配只等待，不能当通用黑屏按钮。
FlyingBird登录前由隐藏S4U任务启动GUI控制进程，Helper服务提供SYSTEM网络Core；用户登录后只交接GUI、保留Core网络，首次交互启动静默到托盘。本人主动关闭后不自动重试拉起，开始菜单仍用厂商原生单实例入口；自然冷启动仍待独立验收。
Xiaomi Share入口在MiService正常时只补一个签名有效的交互界面；服务不运行留给厂商恢复，多个界面或身份不符就停止。可选每次启动只展示一次，并等三屏布局健康后放到主屏；界面活着不证明手机文件已经传完。
本机主Python可在原有每周治理中自动更新同一3.14系列的稳定补丁；正在被应用或MCP使用就等空闲，不终止程序，不跨次版本，也不顺带升级所有pip包。
本模块用到的名词
- Runtime（运行时）
- 真正执行脚本或程序的本机环境，包括 executable 路径、版本、架构和编码通道。
- Relation（版本关系）
- installed 与 target 的 behind、equal、ahead、unknown（未验证） 或 channel_mismatch；它直接决定是否允许更新。
- Startup surface（启动来源面）
- Run 注册表或 Startup 文件夹中的一个独立来源；跨来源同名项不会被错误去重。
- Task signature（任务稳定签名）
- 恢复所需的 enabled、Action、trigger、重试和执行限制等配置，不包含 Ready/Running 瞬时状态。
- LastTaskResult（最近运行结果）
- Scheduler 的最近返回码；信息码与真实失败要分类，非零也要结合业务 Owner 回读。
- Hidden launcher（无窗口父启动器）
- 从最外层就不创建可见控制台的启动链；Task Scheduler 的 Hidden 复选框不能单独证明这一点。
- LocalGpuBroker（本地 GPU 调度代理）
- 统一仲裁 Ollama、OCR（光学字符识别）、ASR（自动语音识别） 与模型资源；只允许一份 OCR（光学字符识别） 和一份 ASR（自动语音识别） 并行，同类任务及 Ollama/外部任务保持互斥。
专业定义
理清工具版本、环境和开机任务，并说清台式机未登录时的 ToDesk、登录后的微信双开与 WeFlow 各自怎样检查和恢复。
解决什么
版本、路径、权限、环境、启动面和任务结果经常被压成一个“环境是否正常”的问题，导致自动重装、误删启动项或用旧任务结果猜当前状态。PCConfig 必须把每个运行面分开，并只让真实 Owner 解释业务结果。
当前怎样实现
- 一次性等待入口为E:\PCConfig\tools\Invoke-CodexTaskWakeup.ps1 -JobPath <明确job.json>，由codex_task_wakeup.py的Tkinter（Python图形界面）窗口执行；共用层归PCConfig，probe（只读条件检查）及上传、备份等业务仍归所属项目。
- 窗口可见后才开始监测，显示条件、运行状态、最近/下次检查、目标任务与结果；立即检查只执行一次probe，停止或关闭只停止监测，不停止底层上传、备份或业务。取消不排队，已提交消息不能撤回。
- Job（任务记录） JSON绑定job_id/title/condition/thread_id/interval_seconds/deadline_utc/probe_command/message；probe_command使用绝对argv数组，返回waiting/ready/failed/cancelled之一。每次probe和queue均限60秒；waiting继续，ready/failed/超时最多尝试一次官方codex queue。
- 同名.runtime.json仅存本次状态与投递结果；Windows内核生存期锁只允许一个活动窗口，退出自动释放。已终结、投递失败或回执不明均不自动重试，避免重复通知；业务evidence不复制进共用状态。
- 官方queue命令只把说明排入原任务，通知声明它不是新用户指令或授权。排队成功、引导接受、模型收到和业务完成分别判断；当前未接通直接引导，用户已取消该接入建设，不把它列为待做功能。
- LocalToolbox当前将该入口登记为受管指针，代码仍由PCConfig保存，不另建工具项目、服务、端口或定时任务。恢复按原项目入口和清单备份找回；再次启动先读原运行记录，不自动重投已尝试通知。
- 运行时 Provider 返回 Windows、PowerShell Core（跨平台 PowerShell）和 Windows PowerShell 的路径、版本、架构与编码事实；路径多候选时使用当前 PSHOME 的唯一 executable（可执行文件）。
- managed_software_catalog 当前登记 11 个组件，每个条目只给 status/update Adapter（执行适配器），不允许自由命令字符串或缓存 last_observed。
- Invoke-ManagedSoftware 只接受本轮 Adapter（执行适配器） 的 JSON；空输出返回 invalid_receipt，不再从已有 ResultPath 文件拾取旧成功回执。ResultPath 只是输出镜像，不能证明本次更新发生。
- local_gpu_broker/broker.py 按 localocr/localocr-cli 与 chineseasr/chineseasr-cli 两个闭集分组，跨组可并行、组内互斥；公开 leases 分列租约，旧 lease 在并行时返回 shared（共享忙碌）以兼容旧消费者。Ollama session 或活跃请求仍阻断外部租约，其他外部工作继续要求清理资源。
- Windows 入口集中在 PCConfig/tools：Invoke-WeChatDualLaunch.ps1、Set-DefaultAudio.ps1、Release-StuckModifierKeys.ps1、Install-CursorSchemeGuard.ps1、Invoke-DisplayTopologyRecovery.ps1、Invoke-XiaomiShareWatchdog.ps1；Documents/Downloads 与软件清单热备也由各自既有任务调用本目录脚本。恢复先找对应入口和任务，不能重建一个独立脚本项目。
- 音频脚本对三种Windows音频角色执行后置核验；按键脚本只调用keybd_event KEYUP释放Ctrl、Alt、Shift、左右Win。CursorSchemeGuard监听设置/恢复/会话返回，并每2秒核对静态指针图像以发现无通知重置；每6小时维护、默认168小时探测原生路径。唯一PCConfig Cursor Scheme Guard任务使用Interactive/Limited、登录加1分钟重复触发、IgnoreNew，仅缺进程时补启；用户改选或原生恢复后自行退役。
- FlyingBird-PreLogon-Autostart为开机15秒S4U/Limited隐藏任务；FlyingBird-Interactive-Handoff为登录5秒Interactive/Limited隐藏任务。后者只等待仍有线程的Session 0 GUI退出，不停止Core，再启动交互GUI；厂商Run项去重，autoLaunch=false/silentLaunch=true。2026-09-10已有手工预登录、登录交接、原生快捷方式唤醒同PID验收；这不替代自然AtStartup。
- Invoke-DisplayTopologyRecovery默认Inspect；Repair才可能处理精确GPU、PHLC34B、MTT1337、TUR0000与联力设备的已证单活屏竞态，并分开报告拓扑、RTSS配置和壁纸FPS回读。Xiaomi入口也默认Inspect，Repair/Install/Uninstall分别拥有具体效果和同名任务所有权检查。这轮仅读取这些已发布源码，没有调用任何修复、安装、声音、按键或显示动作。
- RTSS恢复来源是tools/rtss-powershell.cfg：[Hooking]下EnableHooking=0，只对应Profiles/powershell.exe.cfg。安装前保存该单文件前像，安装后核对bytes/hash（内容指纹），并用RTSS接口回读AppDetectionLevel=0；实际挂钩驻留、异常退出与TURZX持续发送仍各自验证。需要重载时只处理既定RTSS入口，不调用整个显示恢复链，也不结束ToDesk。
- PrimaryOledBlackout 的 Ctrl+Win+R/开始菜单切换只针对 PHLC34B 实体主屏，本地遮罩与捕获光标副本保留远控；登录 --listen 只监听，--restore/--quit 都会改变现场。9 月 5 日登记明确有输入法及屏保闪烁、等待业务稳定版，本轮不触显示、ToDesk、Sunshine 或全局光标。
- 更新流程固定为 Resolve → Status → Backup → Preflight → Update → Wait → Verify；目标版本在安装前 pin（精确固定），安装后强制相等。
- 环境变量索引当前记录 89 个变量元数据和 64 个 PATH（可执行搜索路径）条目，与概览同口径；Probe-EnvVar 只返回存在性、作用域和差异，不返回任何值。
- runtimes.json 原观察于 2026-08-30T04:15:42.320175-07:00：PowerShell Core 7.6.4 位于 C:\Program Files\PowerShell\7\pwsh.exe，Windows PowerShell 5.1.26100.9278 位于 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe。前者 console/pipeline/default code page 均为 65001；后者 console 为 65001、pipeline 为 20127、.NET default 为 936，Windows ANSI/OEM 为 936。编码差异必须由相应通道处理，不能因为都叫 PowerShell 就假设一致。
- 启动快照只覆盖当前用户/机器 Run 与用户/公共 Startup 文件夹五个 surface，不复制 Task Scheduler，也不覆盖服务、驱动和 packaged app。
- 2026-09-08历史Get-StartupInventory live回读23个启动项，其中22 enabled、1 disabled；版本化 startup_snapshot 仍是维护基线，不能覆盖当前现场。
- 2026-09-01 原快照的 tasks Registry（登记清单） 有 87 项；10 个核心恢复任务当时均为 Ready、最近结果 0，并由 CoreRecovery 3/3 验收分层回读。
- 正式task-scan已发布94项，generation_id=task-scan-20260909t221121454-e3f172644f2143e0；管理员现场94项、增删改差异0，MCP、两维护和两独立保护及真实Governance触发器已收敛。9阶段57项恢复用途计划已更新并验证current（当前状态），不能与全部现场任务混算。ChineseASR Dictation仍先恢复环境/麦克风，再由项目Install重建；Status不启动听写。
- 主工作站 ToDesk 链为官方 ToDesk.exe -autostart on → ToDesk_Service → ToDesk PreLogin Watchdog。任务使用 AtStartup（系统启动）、SYSTEM/ServiceAccount/Highest，每 2 分钟兜底；wscript.exe 以窗口样式 0 拉起 PowerShell，安装根是 C:\ProgramData\PCConfig\ToDeskPreLoginWatchdog。只在 C:\Program Files\ToDesk\ToDesk.exe 路径和官方签名都匹配时修复 Auto、非延迟与 Running；服务自身崩溃优先由 SCM（服务控制管理器）恢复。
- WeChat AutoStart 以当前交互用户 / Limited（受限权限）在登录后延迟 30 秒，经 wscript.exe → Invoke-PowerShellHidden.vbs → E:\PCConfig\tools\Invoke-WeChatDualLaunch.ps1；只启动官方 Weixin.exe，忽略子进程与零线程/零句柄幽灵，补到两个顶层实例后连续稳定 15 秒。桌面与开始菜单沿用同一幂等入口。
- wechat_dual_autostart.json 的 2026-08-08 升级记录为腾讯签名 WeChat 4.1.12.26，零实例起步到 2 个、已有 2 个时 launched_count=0；同时记录 5031/16000 的 health、sessions、contacts 为 200 且既有数据库密钥指纹未变。这里只复述无秘密连续性结论，不保存指纹值，也不宣称今日重测或以后所有版本兼容。
- WeFlow Secondary Watchdog 在登录后延迟 60 秒、每 15 分钟检查第二实例；端口 16000 固定绑定 C:\Users\10979\AppData\Local\WeFlowProfiles\primary-16000，与默认 5031 分开。heartbeat 只对该实例使用 -NoProxyServer/-HiddenLaunch，不依赖固定代理端口、不改变系统代理；显式目录不存在即返回失败，不让 Electron 新建空 profile。
- WeFlow 登记证据来自 2026-08-06 的 current-session（当次会话）观察：持久目录进程绑定、16000 health/sessions/contacts、任务受控重启与 LastTaskResult=0 已记录；WeFlow 26.7.3 没有外部 metadata-only（仅元数据）当前账号接口，所以人类可读账号标签仍未知。旧 Z 缓存路径已不再是活动绑定，也不是灾难恢复副本。
- OllamaStable32100 与 SelfHeal 任务负责 Broker（代理服务）/内部 backend（模型后端） 的登录启动和幂等恢复；启动前先验当前宿主内存、NVIDIA GPU/显存、命令和模型路径，失败时不创建日志目录或进程。
- governance check 只调用登记的 zero-write Provider 和稳定 publisher；同一非 current（当前状态） fingerprint 只有首次或变化时产生 attention。
- 现有Show-StreamingMaintenance窗口联合查看Sunshine与RamdiskGuardian的健康、新鲜度、最近/下次检查及活动消费者/冷却；控制原有循环或未来触发，不新增后台服务。打开不改电源、网络、显示或驱动，关闭窗口不停止已登记任务。
- 主Python由registries/host_python.json登记，python/python3/py是Invoke-ManagedSoftware的同一目标别名，不改系统PATH。仅python获无人值守更新例外且automatic_patch_updates=true时生效；原PCConfig Governance Check独立执行Invoke-HostPythonGovernance.ps1。升级前核对进程使用并保留解释器副本，固定版本交WinGet，完成后检查版本、标准库和第三方包指纹；失败或中断留下python-update-hold.json，停止后续自动重试，不声称已自动回滚。不改Codex自带运行时或重建项目venv，但依赖主解释器的venv下次启动会消费兼容补丁。
执行流程
- 1
用别名或任务名定位受管条目和业务 Owner
- 2
读取 live runtime（运行环境）、startup 或 Scheduler 现场
- 3
把配置签名、瞬时状态、LastTaskResult 和 Owner receipt（执行回执） 分开
- 4
需要更新时先固定 current（当前状态）/target/relation 和回滚材料
- 5
GPU 请求先取得 Broker（代理服务） lease（租约）并通过当前宿主能力门；OCR（光学字符识别） 与 ASR（自动语音识别） 可跨家族并行，同家族和 Ollama 仍互斥；结束或失败后各自释放，不影响另一份合法租约
- 6
需要注册任务时保存 exact XML preimage 或 absent
- 7
重装主工作站时先恢复 PCConfig、PowerShell 和厂商签名 ToDesk，再按专属安装器重建并只读 Verify；不能把副驾驶笔记本的远控账本当成这条 SYSTEM 登录前链的证据
- 8
恢复微信官方客户端和 PCConfig 的 Invoke-WeChatDualLaunch.ps1 后，按双开安装器回读任务与快捷方式；账号由用户重新确认。恢复 WeFlowBridge 与原持久 profile 后，再验证 16000 绑定、health/sessions/contacts 和资料库身份
- 9
执行后回读路径、版本、Principal（受验证的执行主体）、trigger、Settings 和业务 receipt（执行回执）
- 10
将确定故障、提醒和 unknown（未验证） 分别收口
边界
- 环境变量、PATH、任务 Action、参数、XML 和日志按实际值判断：普通名称、路径、结构、状态和失败事实可以公开；只省略其中确含 L3+ 私人正文或可复用凭据的具体值
- 不自动建立无人值守软件更新任务
- 不因为 startup 新增、删除或启停变化就生成故障或待办
- 不从 provider 名称猜管理员需求；安装范围由本次 status Adapter（执行适配器） 回读
- 不重装 equal 但 degraded 的组件，只报告健康缺口
- 不在宿主能力门失败时启动 Broker（代理服务）、Ollama 或重型项目，也不把临时宿主观察写回主工作站基线
- 不结束 ToDesk 做看门狗验收，不读取或展示远控密码，不以用户登录后手工触发替代登录前异机接入
- 微信双开不注入、不修改客户端、不坐标点击；双实例、接口健康、命名账号身份与自然重启四种证据分别保留
- WeFlow profile 恢复由账号与内容 Owner 负责；PCConfig 只管理任务和路径，不把持久目录或旧缓存当作已验证加密备份
- 具体任务为何成功仍由所属项目定义
失败与恢复
- 完整权限现场与 Registry（登记清单） 不同
- 保留精确差异并标明观察时间；不把历史 task-scan 冒充当前闭合，也不把 runtime（运行环境） health PASS 反推成定义一致。
- 2026-08-28 的历史 LastTaskResult=4
- 保留为带日期的旧回执；2026-09-03的rev68自然启动记录在61718 ms内返回deadline_met=true，不再把历史失败算进当前健康。
- 启动快照比现场少 3 项
- 当前归类为 informational_only；无需自动刷新、关闭应用或要求用户确认，下次真实维护可吸收为新基线。
- 环境变量 registry（登记清单）/process 读取失败
- 对应项 exists=null、diff_status=unknown（未验证）；不把读取失败写成 absent。
- 组件 status 为 unknown（未验证） 或通道不匹配
- 不备份、不安装、不降级，返回稳定错误码和 Owner 入口。
- LocalGpuBroker（本地 GPU 调度器） backend（模型后端） 已活动或 lease 被占用
- 组件更新和新的重型任务等待或停止，不终止现有 Owner；读取 Broker（代理服务） 状态后从原 lease 恢复，不另开直接 backend（模型后端）。
- 任务注册 read-back（正式回读） 不一致
- 自动恢复 exact XML preimage 并再次核对；回滚失败单独 fail closed（失败关闭）。
- ToDesk SYSTEM 任务普通权限不可见
- 返回 task_read_permission_required、task.exists=null；只读升级到完整权限核验，不据此重装、删任务或停止服务。同次启动的任务结果和新鲜回执缺一不可。
- ToDesk 服务路径或签名不匹配
- 看门狗停止修复并返回精确异常，不接管未知程序；保留现有远控和账号配置。
- 微信只剩一个健康实例或存在幽灵进程
- 启动器仅补足缺口，等待稳定后才报成功；零线程/零句柄进程不计数，扫码或登录失败交回微信，不反复启动凑数量。
- WeFlow 持久目录缺失、接口不可读或命名账号未知
- 缺目录时不启动空库；接口异常与资料库身份未知分别报告。只恢复经 Owner 确认的原 profile，不能从端口或 profile 文件名猜账号。
真实入口
E:\PCConfig\registries\runtimes.json冻结运行时投影
E:\PCConfig\docs\runtime\codex-task-wakeup.md可见一次性等待、停止、通知与恢复语义
E:\PCConfig\tools\codex_task_wakeup.py窗口、只读probe、单实例状态、一次官方queue投递
E:\PCConfig\registries\managed_software_catalog.json11 个受管组件与 Adapter（执行适配器） 路由
E:\PCConfig\registries\env_var_index.json变量名称、作用域和 PATH 顺序元数据
E:\PCConfig\registries\startup_snapshot.json五个登录启动来源面的维护快照
E:\PCConfig\registries\tasks.json计划任务稳定恢复投影
E:\PCConfig\registries\task_purpose_catalog.json任务用途、Owner 和验证入口
E:\PCConfig\registries\scheduled_task_rebuild_plan.json分阶段任务重建计划
E:\PCConfig\docs\contracts\pcconfig.managed-software-routing.md受控更新状态机
E:\PCConfig\docs\contracts\pcconfig.scheduled-tasks.mdScheduler 权威、无窗口和事务回滚合同
E:\PCConfig\docs\recovery\todesk_prelogin_watchdog.md主工作站登录前远控、SYSTEM 看门狗、恢复入口与自然重启验收边界
E:\PCConfig\tools\Install-ToDeskPreLoginWatchdog.ps1ToDesk Install/Verify/Remove（安装/只读验证/移除）、固定安装根和精确回滚
E:\PCConfig\registries\wechat_dual_autostart.json官方客户端、双开启动器、快捷方式、升级与未重启证据
E:\PCConfig\docs\recovery\wechat_dual_autostart.md登录延迟、健康实例计数、账号边界和旧快捷方式恢复
E:\PCConfig\tools\Install-WeChatDualAutostart.ps1微信双开专属安装/验证/移除入口
E:\PCConfig\registries\weflow_secondary_watchdog.json16000 持久配置、任务、当次会话连续性与账号未知
E:\PCConfig\docs\recovery\weflow_secondary_watchdog.mdprofile 缺失拒绝、静默启动、接口验证与灾备区别
E:\PCConfig\tools\Install-WeFlowSecondaryWatchdog.ps1第二实例专属安装/只读验证/移除入口
E:\PCConfig\tools\local_gpu_broker\broker.py32100/32101 入口、OCR（光学字符识别）/ASR（自动语音识别） 跨组并行与同组/Ollama 互斥
E:\PCConfig\tools\local_gpu_broker\Test-HeavyRuntimeHostCapability.ps1重型运行前的当前宿主能力门
E:\PCConfig\docs\contracts\pcconfig.managed-software-routing.md主Python同系列稳定补丁、空闲窗口、失败暂停和原任务管理边界
如何验证
- 2026-09-14只读核对任务等待源码、说明及LocalToolbox入口；清单记有可见窗口、停止和官方排队实测，本网页未重新启动检查器或发送消息。投递回执不能证明模型接收；直接引导未实现。
- 2026-09-01 Get-StartupInventory.ps1 -Json 同次回读 21 个启动项：20 enabled、1 disabled；当时配置 Registry（登记清单） 登记 87 个任务，不能与 2026-09-02 后续 89 项来源投影混成同一观察。
- 2026-09-01 原快照：10 个核心恢复任务当时均为 Ready、最近结果 0；CoreRecovery 3/3 验收通过。最新备份范围与任务计数见换机与恢复模块，不把旧观察当今日状态。
- 本轮读到的P0记录仍绑定2026-09-03：rev68为normal、active=LKG、trusted=true、recovery_status=null；该次自然启动61718 ms、deadline_met=true
- 2026-09-08T08:12:34Z的Get-StartupInventory.ps1 -Json覆盖23个启动项
- Invoke-StartupSnapshotMaintenance.ps1 -Action Inspect -Json 当前返回 changes_observed，但 action_required=false、confirmation_required=false
- 本次完整性补写只读取 ToDesk/微信/WeFlow 的当前合同、登记与安装器源码，没有触发安装、重启、任务运行或真实登录；ToDesk 的登录前异机接入、微信 AtLogOn 和 WeFlow 自然重启不新增 E2E（端到端）通过声明。
- 微信 2026-08-08 的双实例与两路 API 升级证据、WeFlow 2026-08-06 的持久 profile 与当前会话证据按原时间保留；自然重启字段仍为未验收，不能用旧会话结果补齐。
- 2026-08-31 Test-LocalGpuBroker.ps1 返回 ok=true、lease=null、active_ollama_requests=0、ollama_version=0.33.1；这是当前 Broker（代理服务） 状态，不证明每个重型项目已运行
- validate_managed_software_catalog.mjs、validate_env_var_index.mjs 与对应回归覆盖 catalog（目录）、环境元数据和闭合状态机
- 2026-09-19T15:05:13Z正式只读Status返回主Python3.14.7、目标3.14.7、stable/equal、healthy、automatic_patch_updates=true；14:33Z原维护结果current（当前状态），update_attempted=false。本网页未运行更新、安装或升级第三方包；需要空闲的更新分支没有在此轮重放。
与其他模块的关系
机器事实模块告诉它们在哪里；本模块证明怎样启动和运行；恢复模块在系统重建后按顺序重新接上这些运行链；漂移结果又成为整体验收的输入。