fix(reboot): add windows99 vmx source locate check

docs/runbooks/FULL-STACK-COLD-START-SOP.md

@@ -1,6 +1,6 @@
 # AWOOOI 全棧冷啟動與主機重啟 SOP
 
-> Version: v1.114
+> Version: v1.115
 > Last updated: 2026-07-03 Asia/Taipei
 > Scope: 99 / 110 / 111 / 112 / 120 / 121 / 188 全棧重啟恢復。112 仍是 Kali / VM guest 訊號，但 2026-06-30 全主機重啟後已納入 10 分鐘 SLO 的必要 boot / power signal；此納入不代表授權任何破壞性 runtime apply。
 
@@ -60,6 +60,8 @@ v1.113 Windows99 VMX source repair package API rule：production `/api/v1/agents
 
 v1.114 Windows99 VMX package public redaction boundary rule：public `/api/v1/agents/reboot-auto-recovery-slo-scorecard` 與 `/api/v1/agents/windows99-vmx-source-repair-package` 會先套用 LAN topology redaction，因此 VMX path 內的 `192.168.0.111` 可能在 public JSON 變成 `host:dev-a` 類 display alias。public response 必須同步輸出 `public_lan_topology_redacted=true`、`redacted_public_display_only=true`、`check_mode_probe_commands_executable=false` 與 `internal_console_package_required_for_execution=true`；所有 `vm_rows[]` 也必須帶相同 executable=false 邊界。任何 `host:...` VMX path 只能供瀏覽器 / Telegram / UI 顯示，不得作為 Windows console 可執行命令。要跑 `Test-Path` 時只能使用授權內部 console / no-secret package 保留的原始 Windows path；仍不得讀密碼、啟動 VM、重啟 service / host 或套用 registry。
 
+v1.115 Windows99 VMX source locate check-mode rule：2026-07-03 12:00 production readback 已更新為 `status=blocked_reboot_auto_recovery_slo_not_ready`、`active_blocker_count=8`、`readiness_percent=60`、`primary_blocker=fresh_all_host_reboot_event_missing`、`can_claim_all_services_recovered_within_target=false`，priority readback 同步顯示 `windows99_vmx_source_repair_action_stage=source_repair_check_mode_ready` 與 `windows99_vmx_source_repair_next_executable_step=locate_or_relink_missing_vmx_source_check_mode`。定位 111 VMX source 時固定使用 `scripts/reboot-recovery/collect-windows99-vmx-source-locate-check.sh --via-host wooo@192.168.0.110 --include-identity-metadata`；此 collector 只用 BatchMode public-key SSH、stdin PowerShell bootstrap 與 bounded VMX identity keys，不讀 secret、不寫遠端檔、不啟動 / 關閉 VM、不重啟 Windows service / host、不套 registry。live 結果：expected 111 VMX path `exists=0`、`candidate_vmx_count=6`、`alias_hint_candidate_count=0`、`identity_target_hint_count=0`、`identity_unassigned_ubuntu_candidate_count=1`、`locate_status=single_identity_unassigned_ubuntu_candidate_requires_confirmation`。該 generic Ubuntu candidate 不能直接 relink；先前 MAC / neighbor evidence 未證明它是 111，且 99 local named backup roots 與 110 bounded backup roots 未找到 111 VMX artifact。下一步只能是取得外部 verified backup artifact 或更強身份證據後建立 scoped relink / restore dry-run，再跑 post-verifier；不得用猜測候選直接 relink、power on 或宣稱 SLA 完成。
+
 2026-07-02 110 control-path / Harbor recovery receipt rule：若 Gitea Harbor repair queue 仍保留 `harbor_110_remote_ssh_publickey_auth_stalled`、remote-control unavailable、jobs stale 或 historical failure，但同一輪本地證據同時證明 `wooo` command path ready、110 local Harbor `/v2/` ready、public/internal registry `/v2/` 回 `401`，則該 Gitea Harbor repair 失敗只能列為 historical queue metadata，不得再當成 current SSH blocker。必須用 `/api/v1/agents/harbor-registry-controlled-recovery-receipt` 或同等 validator 合併 `diagnose-110-ssh-publickey-auth.sh`、`recover-110-control-path-and-harbor-local.sh --check`、public Gitea queue readback 與 registry `/v2/` verifier，並把機器可讀結果寫入 `docs/operations/harbor-110-control-path-recovery-readback-2026-07-02.snapshot.json` 類型的 snapshot。2026-07-02 live receipt 顯示：public/internal registry `/v2/` 均為 `401`、latest visible CD `#4335` 為 `Success`、Gitea Harbor repair failure 已是 `historical_after_latest_cd_success=true`；active blockers 收斂為 110 controlled CD lane config / binary / registration / service guardrail、active action container pressure，以及 Gitea CD jobs head-SHA / stale readback mismatch。若 local-console output 只有 `AWOOOI_110_CONTROLLED_CD_LANE_READY` marker，non110 runner parser 不得從 110 `BLOCKER` 行推導 non110 blocker；non110 只有看到 `AWOOOI_NON110_RUNNER_READY` marker 才能列入 active blocker。
 
 2026-07-02 110 controlled CD lane fail-closed enforcer staging rule：110 runner 壓力事故後，legacy / generic runner 仍必須 fail-closed；但 `awoooi-cd-lane-drain.service` 的非 secret staging artifact 不得再被 enforcer 無差別封回 stub。`scripts/reboot-recovery/enforce-110-runner-failclosed.sh` 只有在 `config.yaml` 符合 `capacity <= 1`、只含 `awoooi-host:host` 與 `awoooi-ubuntu:docker://192.168.0.110:5000/awoooi/ci-runner:act-22.04`、binary 是 executable ELF、systemd unit 具備 `ConditionPathExists=/home/wooo/awoooi-cd-lane-drain/data/.runner`、`CPUAccounting` / `MemoryAccounting` / `TasksAccounting` / `NoNewPrivileges` 等 guardrail，且 service `inactive`、`MainPID=0`、未 enabled / 未 masked 時，才可保留 drain config / binary / unit，並輸出 `CONTROLLED_DRAIN_STAGING_ALLOWED=1` 與 textfile metric。此 staging 規則不得讀 token、不得讀 `.runner` 內容、不得註冊 runner、不得啟動 service；若 registration 缺失，readiness verifier 仍必須只留下 `controlled_cd_lane_registration_missing` / `controlled_cd_lane_service_not_active` 類 blocker。若 `CONTROLLED_DRAIN_STAGING_ALLOWED=0` 且 config / binary 又被搬走，優先修 source enforcer / unit guardrail，不要手工反覆補同一組 artifact。

docs/runbooks/REBOOT-RECOVERY-SOP.md

@@ -1,9 +1,9 @@
 # AWOOOI 重開機恢復 SOP
 
-> **版本**: v5.7
+> **版本**: v5.8
 > **最後更新**: 2026-07-03 (台北時間)
 > **更新者**: Codex
-> **觸發事件**: 2026-07-03 11:35 production SLO scorecard：Windows99 VMX source repair public endpoint 已補 redaction execution boundary，10 分鐘 SLO 仍 blocked
+> **觸發事件**: 2026-07-03 12:00 production SLO scorecard + Windows99 VMX source locate check-mode：111 VMX source 尚未找到，10 分鐘 SLO 仍 blocked
 
 ---
 
@@ -21,9 +21,9 @@
 
 ## 架構概覽與依賴圖
 
-### 2026-07-03 10:50 P0 現況覆蓋
+### 2026-07-03 12:00 P0 現況覆蓋
 
-目前不得宣稱「全主機重啟後 10 分鐘內全部恢復」。production SLO scorecard 仍為 `blocked_reboot_auto_recovery_slo_not_ready`，`active_blocker_count=10`、`readiness_percent=60`、primary blocker `reboot_event_required_host_unreachable`，`can_claim_all_services_recovered_within_target=false`。10 個 active blockers 固定為：
+目前不得宣稱「全主機重啟後 10 分鐘內全部恢復」。production SLO scorecard 仍為 `blocked_reboot_auto_recovery_slo_not_ready`，`active_blocker_count=8`、`readiness_percent=60`、primary blocker `fresh_all_host_reboot_event_missing`，`can_claim_all_services_recovered_within_target=false`。8 個 active blockers 固定為：
 
 - `all_required_hosts_not_in_10_minute_reboot_window`
 - `fresh_all_host_reboot_event_missing`
@@ -33,18 +33,18 @@
 - `reboot_event_required_host_unreachable`
 - `windows99_vmware_guest_power_not_ready`
 - `windows99_vmware_vmx_missing`
-- `windows99_vmware_autostart_config_not_ready`
-- `windows99_update_no_auto_reboot_policy_not_ready`
 
-最新 no-write artifact 仍以 `/tmp/awoooi-reboot-verify-only-20260703-082310` 與後續 Windows99 management / collector readback 為來源：
+最新 no-write artifact 以 production API readback、110 上最新 Windows99 collector readback 與本輪 VMX locate collector 為來源：
 
-- 99 可 ping / RDP / Hyper-V VMConnect，但 uptime unknown；SSH BatchMode 與 WinRM 仍不可用。
-- 111 仍 unreachable。
+- 99 no-secret VMware verify stdout 已能透過 110 / public-key SSH 收集；`VMAuthdService`、`VMnetDHCP`、`AWOOOI-Start-VMware-VMs` 與 Windows Update no-auto-reboot policy 讀回為 ok。
+- 111 VMX expected path 不存在；`windows99_vmware_vmx_missing` 仍是 Windows99 主要 source blocker。
+- 111 / 188 / 120 / 121 / 112 VM power readback 仍為 not running；`windows99_vmware_guest_power_not_ready` 仍 blocked，且此 SOP 不授權直接 power change。
+- 111 host 仍 unreachable。
 - 112 / 120 / 121 可達，但 uptime 已超過 10 分鐘目標窗口。
 - 188 可達，但 `systemd_state=degraded` 且 `awoooi-startup.service failed`。
-- `reboot_detected=false`、`fresh_boot_hosts=[]`，因此 10 分鐘 SLO 尚未證明。
+- `fresh_all_host_reboot_event_missing` 仍為 primary blocker，因此 10 分鐘 SLO 尚未證明。
 
-固定下一步：`restore_windows99_missing_vmx_source_for_aliases_then_rerun_no_secret_collector_and_scorecard_no_vm_power_change`。先讀 production scorecard 的 `windows99_vmx_source_repair_package`，確認 111 expected VMX path 與 `Test-Path -LiteralPath ...` check-mode probe；再恢復 111 VMX source 與 99 no-secret management / console Verify stdout，使 `windows99-vmware-autostart.ps1 -Mode Verify` 產生 normalized artifact；同時補 111 reachability，再重跑 host probe、reboot-event detector、SLO scorecard。若 public API response 顯示 `public_lan_topology_redacted=true` 或 `check_mode_probe_commands_executable=false`，其中 `host:...` VMX path 只能當 public display evidence，不得直接貼到 Windows console 執行；要執行 probe 時必須使用授權內部 console / no-secret package 保留的原始 Windows path。禁止讀 Windows 密碼、啟動 / 關閉 VM、host reboot、service restart、Docker / Nginx / K3s / DB / firewall restart、restore、prune、delete。
+固定下一步：`locate_or_relink_missing_vmx_source_check_mode`。執行 `scripts/reboot-recovery/collect-windows99-vmx-source-locate-check.sh --via-host wooo@192.168.0.110 --include-identity-metadata`；本輪 live 結果為 expected 111 VMX path `exists=0`、`candidate_vmx_count=6`、`alias_hint_candidate_count=0`、`identity_target_hint_count=0`、`identity_unassigned_ubuntu_candidate_count=1`、`locate_status=single_identity_unassigned_ubuntu_candidate_requires_confirmation`。唯一 generic Ubuntu candidate 還不能安全 relink，因為 display name / alias 沒有 111 identity hint，先前 MAC / neighbor evidence 也未證明它是 111，且 99 local named backup roots 與 110 bounded backup roots 尚未找到 111 VMX artifact。下一步只能取得外部 verified backup artifact 或更強 identity evidence，再產生 scoped relink / restore dry-run 與 post-verifier。若 public API response 顯示 `public_lan_topology_redacted=true` 或 `check_mode_probe_commands_executable=false`，其中 `host:...` VMX path 只能當 public display evidence，不得直接貼到 Windows console 執行；要執行 probe 時必須使用授權內部 console / no-secret package 保留的原始 Windows path。禁止讀 Windows 密碼、啟動 / 關閉 VM、host reboot、service restart、Docker / Nginx / K3s / DB / firewall restart、restore、prune、delete。
 
 ### 五主機全貌