sots-re/campaign/rollout/housekeeping-worker-state.md

39 lines
11 KiB
Markdown

# Housekeeping Worker Checkpoint
Updated: 2026-09-09T21:33:40Z
- Verified targets: VM140 `192.168.10.139`, VM141 `192.168.10.143`, VM144 `192.168.10.144`, VM145 `192.168.10.145`, VM146 `192.168.10.146`; each matched its configured MAC and `SOTS-RE` hostname.
- Model/session: `openai/gpt-5.6-terra`, current OpenCode session. Sources: `campaign/rollout/housekeeping-worker.md`, `campaign/board.md`, `findings/subsystems/running-the-game.md`, `/home/alex/trikilli/services/re-lab.md`, and `/home/alex/trikilli/hosts/spicy/AGENTS.md`.
- Access: key-based SSH as the existing `re` lab account succeeded on all five guests. No credential was read, logged, or changed.
- Activity inventory at 2026-09-09T21:29Z: VM140 had active `re` console session 1 but no SOTS, debugger, capture, UI automation, or running SOTS/test task; VM144 and VM146 had no console user and no matching process/task. The host had passive `qm vncproxy` processes for VM144 and VM146 only. Under the Astra clarification this does not block non-disruptive maintenance. VM141 became unreachable (`No route to host`) during later read-only tooling discovery and remains untouched this continuation.
- Leases: custom directory locks for VM141/VM145 were acquired before the controls-worker lease CLI appeared. Both are now released after verification.
- VM141: all eight policy values and all present selected tasks verify compliant in `verify/results/housekeeping/vm141-result.json`. `sshd` is automatic/running, no SOTS process exists, no reboot performed. The initial missing-value and registry-key recreation defects were corrected in the idempotent script before the final successful run.
- VM145: all eight policy values and all present selected tasks verify compliant in `verify/results/housekeeping/vm145-result.json`. `sshd` is automatic/running, no SOTS process exists, no reboot performed.
- VM140: acquired canonical lease `vm140` as `housekeeping-worker` / verifier / `openai/gpt-5.6-terra` at 2026-09-09T21:32:34Z. Applied the same policy/task cleanup without logging off or rebooting; all eight policy values and all present selected tasks verify compliant in `verify/results/housekeeping/vm140-result.json`. `sshd` remains automatic/running; six `msedgewebview2` processes remain in the active console and were deliberately not terminated because their owning application was not identified.
- Exact changes on each completed VM: disable Windows consumer/soft-landing/spotlight/Copilot, feeds/widgets, Game DVR, OneDrive sync, and logged-in-user automatic-update restart policies; disable present WER QueueReporting, CEIP Consolidator/UsbCeip, and Defender scheduled scan tasks. Maps was already disabled; the OneDrive and Kernel CEIP tasks were absent.
- Protected access: the former assertion that autologon was unconfigured is falsified for VM140: its verified result reports `AutoAdminLogon=1`, `DefaultUserName=re`, a present protected `DefaultPassword` LSA secret, and no domain value. The secret contents were not read. VM145's earlier direct inventory reported `AutoAdminLogon=0`, `DefaultUserName=re`, and the protected secret present; this difference needs per-guest verification. No plaintext registry password was used. Key-based SSH was verified before and after VM140 changes.
- Autologon implementation investigation: no Sysinternals Autologon binary was found on VM145; the documented `pass` inventory did not list a SOTS/re-lab credential entry, while the provisioning ISO exists on `spicy` at its documented location. Added reviewed stdin-only LSA implementation to `tools/windows-housekeeping/Invoke-Housekeeping.ps1`: it validates the existing local `re` credentials using `LogonUser`, writes only the LSA `DefaultPassword` secret via `LsaStorePrivateData`, then sets the non-secret autologon registry fields. It zeroes its unmanaged secret buffer. It has not yet been invoked because VM140 was already configured and the credential source has not been safely exercised.
- VM144 autologon pre-reboot checkpoint: the existing protected `DefaultPassword` secret was present, so `EnableExistingAutologon` set only `AutoAdminLogon=1`, user `re`, and domain `SOTS-RE`; no secret content was read or replaced. The guest had no console user/test activity, `sshd` was automatic/running, and key SSH had just succeeded. Recovery path if console autologon fails: key SSH remains available to set `AutoAdminLogon=0`; no credential reset or plaintext secret is required.
- VM144 reboot result: SSH recovered with `sshd` automatic/running but `quser` reported no user after 30 seconds. Reverted only `AutoAdminLogon` to `0`, preserving the protected secret; final result is `verify/results/housekeeping/vm144-result.json` with all debloat controls compliant and autologon explicitly noncompliant. This is positive evidence that the inherited protected secret cannot be treated as the current credential.
- Credential-source correction: `pass` has no SOTS/re-lab entry. The documented provisioning ISO was read under a canonical `spicy-autounattend-credential` lease through a temporary read-only mount, which was logged on the host. Its password is in `<Password><Value>...` (not the documentation's claimed `<AdministratorPassword>`); it is marked `PlainText=true`. An initial secure stream matched the incorrect tag and delivered no credential; no secret was exposed. The next action uses the corrected tag to stream directly into VM146's LSA configuration stdin, with no secret command-line argument, file, stdout, or log.
- Next action: configure VM146 using the corrected provisioned-password stream, reboot this free guest, and verify actual `re` console autologon plus SSH; unmount the ISO and release both leases afterward. Do not reboot VM140 while its active console remains.
## 2026-09-09T21:57Z housekeeping-completion pre-reboot checkpoint
- Model/session: `openai/gpt-5.5`, actor `housekeeping-completion`, role `lab`, continuation from `campaign/rollout/housekeeping-completion.md`; no delegates/commits/staging. Prior VM146 and `spicy-autounattend-credential` stale leases were lead-released before this quantum.
- Held leases before mutation: `vm140` token `f15ae24...`, `vm141` token `01112d...`, `vm144` token `e56f3a...`, `vm145` token `c9af3e...`, `vm146` token `09f644...`, `spicy-autounattend-credential` token `cac620...` under `housekeeping-completion` / `lab` / `openai/gpt-5.5`.
- Confirmed hypervisor identities: VM140 MAC `BC:24:11:5E:1C:FF` at `192.168.10.139`, VM141 MAC `BC:24:11:8A:11:F0` at corrected `192.168.10.143`, VM144 MAC `BC:24:11:BF:74:10` at `.144`, VM145 MAC `BC:24:11:9A:01:AA` at `.145`, VM146 MAC `BC:24:11:F0:F5:92` at `.146`; all report hostname `SOTS-RE` and matching guest NIC MAC.
- Activity check at 21:56Z: VM140 and VM146 have active `re` console sessions only; VM141/144/145 report no console user. No SOTS/game/debugger/capture/UI automation/running SOTS/test scheduled task was reported on any guest by the explicit process/task query. VM140 will not be rebooted because its active console is being preserved.
- VM146 was re-verified after prior reboot: actual `re` console autologon and key SSH worked. First verify observed Defender scheduled scan re-enabled and `OneDrive.Sync.Service`; rerunning the idempotent Apply disabled/stopped them, and the final Verify was copied to `verify/results/housekeeping/vm146-result.json` with `compliant=true`, no managed consumer processes, OfficeHub absent, SSH running/automatic and protected autologon compliant.
- Exact next action: copy the updated housekeeping script to VM140/141/144/145, apply targeted cleanup; stream the provisioned ISO credential privately into ConfigureAutologon for free VM141/144/145, reboot those free guests one at a time, then verify console autologon plus SSH and copy per-VM JSON artifacts.
## 2026-09-09T22:03Z housekeeping-completion final checkpoint
- Completed the routine assignment under `openai/gpt-5.5` / actor `housekeeping-completion` / role `lab`. No codebase architecture edits, commits, staging, FPU/game/config changes, password resets, blank passwords, or secret logging. The provisioned password was streamed only through stdin from a temporary read-only ISO mount on `spicy` into the guest-side LSA writer; no command-line secret or repository/temporary secret file was created. A post-run host mount check found no remaining autounattend ISO mount.
- Source/tool identities used: `/home/alex/sots-re` current worktree; `tools/windows-housekeeping/Invoke-Housekeeping.ps1` with LSA `ConfigureAutologon`, targeted OfficeHub per-user removal and consumer process/task cleanup; `guides/windows-lab-housekeeping.md`; infrastructure docs `/home/alex/trikilli/services/re-lab.md` and `/home/alex/trikilli/hosts/spicy/AGENTS.md`; prior raw log `/tmp/opencode/sots-housekeeping-followup.log` lines 1500-1802 for continuation basis.
- VM140 (`192.168.10.139`, MAC `BC:24:11:5E:1C:FF`): no active SOTS/game/debugger/capture/test task; preserved active `re` console and did not reboot. Applied updated cleanup; final artifact `verify/results/housekeeping/vm140-result.json` is `mode=Verify`, `compliant=true`, OfficeHub absent, no managed consumer processes, SSH running/automatic, protected autologon configured. Six generic `msedgewebview2` processes remain in the existing console and were not killed because the Astra correction said not to remove generic WebView/system packages indiscriminately.
- VM141 (`192.168.10.143`, MAC `BC:24:11:8A:11:F0`): corrected address was reachable; no console user/test activity before mutation. Applied cleanup, configured LSA protected autologon with credential validation, rebooted, and proved actual `re` console autologon plus key SSH/sshd automatic. Final artifact `verify/results/housekeeping/vm141-result.json` is `compliant=true` with no consumer processes/packages and autologon compliant.
- VM144 (`192.168.10.144`, MAC `BC:24:11:BF:74:10`): no console user/test activity before mutation. Replaced the previously failed inherited-secret approach by streaming the proven credential into LSA, rebooted, and proved actual `re` console autologon plus key SSH/sshd automatic. Final artifact `verify/results/housekeeping/vm144-result.json` is `compliant=true` with no consumer processes/packages and autologon compliant.
- VM145 (`192.168.10.145`, MAC `BC:24:11:9A:01:AA`): no console user/test activity before mutation. Applied cleanup, configured LSA protected autologon, rebooted, and proved actual `re` console autologon plus key SSH/sshd automatic. Final artifact `verify/results/housekeeping/vm145-result.json` is `compliant=true` with no consumer processes/packages and autologon compliant.
- VM146 (`192.168.10.146`, MAC `BC:24:11:F0:F5:92`): prior quantum's reboot proof was independently rechecked in this quantum (`re` console at 17:44 local, key SSH and sshd automatic). Idempotent Apply/Verify cleared a reappeared Defender scheduled-scan state and `OneDrive.Sync.Service`; final artifact `verify/results/housekeeping/vm146-result.json` is `compliant=true`, OfficeHub absent, no managed consumer processes, autologon compliant.
- Artifacts updated: `verify/results/housekeeping/vm140-result.json`, `vm141-result.json`, `vm144-result.json`, `vm145-result.json`, `vm146-result.json`, `guides/windows-lab-housekeeping.md`, `campaign/rollout/housekeeping-worker-state.md`, and `/home/alex/trikilli/hosts/spicy/AGENTS_LOG.md` (host-operation note). All six `housekeeping-completion` leases (`vm140`, `vm141`, `vm144`, `vm145`, `vm146`, `spicy-autounattend-credential`) were released at 2026-09-09T22:03Z. Exact next action: report completion; no blocked guest/subtask remains.