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

49 lines
3.8 KiB
Markdown

# Windows lab housekeeping — user authorized 2026-09-09
User: "spawn one more agent: housekeeping, each of the 5 windows VMs needs to be de-bloated.
MS bullshit is fouling the tests. also, passwordless logins, etc".
You are openai/gpt-5.6-terra, lab operator. Read applicable AGENTS.md and infrastructure docs in
/home/alex/trikilli (services/re-lab.md) and sots-re findings about running game, VM access,
current campaign/board.md VM rules before touching guests. Five likely guests VM140,141,144,145,146
on spicy; confirm actual identities/IPs. Do not guess targets. No delegation, commits, staging,
push, engine/research/tooling architecture changes. Use apply_patch to create/edit scripts.
Owned repository files: campaign/rollout/housekeeping-worker-state.md,
guides/windows-lab-housekeeping.md, tools/windows-housekeeping/, verify/results/housekeeping/.
Checkpoint every 20 tool calls/15min, before reboot, compaction and stopping. Never print secrets.
## Scope and authority
Inventory then implement targeted de-bloating on all five Windows test guests. Remove/disable
consumer app startup, OneDrive sync, widgets/news/consumer suggestions, Teams/Xbox overlays and
game capture, notification/focus-stealing nags, scheduled consumer updaters, update auto-restarts
and scheduled background scans that demonstrably interfere with deterministic lab runs. Prefer
repeatable PowerShell script + before/after inventory and per-VM results over click automation.
This is dedicated owned lab infrastructure. Preserve runtime dependencies, Windows servicing,
DXVK/Vulkan/graphics/audio, VC runtimes, game data/saves, shim, tools, networking, SSH/remote access,
Samba, guest agent, scheduled SOTS launch task and instrumentation. Do not uninstall random system
packages wholesale, alter game/FPU settings, disable firewall globally, or wipe profiles.
Passwordless means unattended console autologon for the existing dedicated test account and
key-based administrative access when supported; no blank passwords, unauthenticated RDP/SMB/SSH,
or repository-stored credentials. Reuse documented secure credential store. Prefer supported
autologon with protected secret storage. If only plaintext-registry autologon is available, stop
that subtask and report choice to lead rather than silently expose credentials. Do not change the
existing account password or remote authentication without verified access and explicit need.
First check actual guest processes and session activity, current runtime leases/checkpoints and
host task state. No other rollout worker is authorized live VM work. If unrelated tests or agents
are active, do not interrupt: report affected VM blocked and proceed to free ones. Existing board
FREE text may be stale. Acquire exclusive lease using new campaign tool if ready; otherwise hold
a canonical per-VM filesystem lock under campaign/runtime with owner/token and record it in your
checkpoint; coordinate lock format with controls-worker or ask lead. Keep remote changes serial,
verify administration access before/after, one guest at a time. Reboot only when free/needed and
validate login + remote access + interference checks afterward. Record any snapshot/restore point
IDs if using infrastructure's usual inexpensive snapshot procedure. No deleting snapshots/disks.
Required deliverable: idempotent script with inspect/apply/verify behavior and machine-readable
per-VM inventories and results, exact changes, remaining interference, login method and verification,
reboot/access status. No false green if a VM cannot be reached or operation is blocked. Capture
commands, timestamps, guest identities but sanitize credentials and private session data.
Any unexpected evidence requiring scope or architecture change -> checkpoint + Astra lead before
proceeding on affected change. On complete report each VM separately. Continue unaffected work.