Skip to content

Windows Home Bootstrap

Idempotent Windows onboarding for the Jones-Gaffney fleet. The canonical library exposes Invoke-Bootstrap -Role main|gaming|streaming|generic|arm; small entry scripts select a role. No passwords, private keys, registration tokens, or fleet-dispatch keys live in this repository.

The arm role is intentionally separate from generic. A Microsoft SQ1 Surface with about 8 gigabytes of memory is a light dispatch worker, not a continuous-integration runner or a local model host. A distinct role makes every heavy omission visible as SKIP and prevents a future generic-role expansion from silently loading the tablet with runner, Docker, screen-reader, audio, Ollama, or council-host work.

Windows ARM64 quick start

  1. At the Surface, install Tailscale, sign in through the browser, and confirm the device appears in the tailnet. Identity consent and multifactor authentication require a human and cannot be automated safely.
  2. Copy the deployed PC-Bootstrap\WIN-ARM64 folder to the Surface, or use this repository's WIN-ARM64 folder directly.
  3. Double-click Fleet-Setup.cmd, approve the Windows elevation prompt, and wait for the final pause. Do not type a bootstrap command.
  4. The launcher opens GitHub and Claude browser authorization when needed, then automatically reruns the elevated dependent sections. Complete the browser prompts; do not transcribe a terminal command.
  5. Read Fleet-Setup.log beside the launcher. Any warning makes the launcher exit nonzero. The dispatch-key step can require another double-click after greatroom imports the Surface's public Secure Shell key through the OneDrive public-key mesh.

The architecture-role folder is reusable because FLT-222 did not provide the Surface's final COMPUTERNAME. The script uses the real name at runtime rather than inventing one.

See the standalone onboarding handoff for the exact order, platform matrix, failure signatures, and stage-by-stage probes.

Existing Windows computers

Run deploy-to-onedrive.ps1 when refreshing the OneDrive copy. Existing per-computer entry points remain under:

  • ANDYGREATROOMPC — main host
  • DESKTOP-D249KD4 — gaming council host
  • DESKTOP-SCDT9HI — streaming council host
  • BEDROOM-PC — generic worker

Those entry scripts may still be run with PowerShell. New machines must receive a double-click artifact like the Windows ARM64 one so Andrew is not handed a command to type.

Section order

Every run reports OK, SKIP, or WARN and continues where safe:

  1. elevation;
  2. Secure Shell aliases, before any network call;
  3. portable power, network-adapter power, and unattended Tailscale policy;
  4. OpenSSH Server and the public-key mesh;
  5. native prerequisites, with post-install version and architecture probes;
  6. GitHub authentication and the canonical repository manifest;
  7. Claude Code; the ARM role explicitly skips the current x64-only usage-governor installer;
  8. GitHub Actions runner policy;
  9. Claude memory client and Fleet Dispatch;
  10. Docker/Semgrep and council-host policy;
  11. summary plus local and shared logs.

The repository set is read from fleet-repo-sync/manifest.json; it is never copied into this bootstrap. The current canonical manifest contains 39 flat repositories.

Security and reliability boundaries

  • The private Fleet Dispatch key is copied with Secure Copy from the greatroom Secure Shell alias to ~/.claude/fleet-dispatch.key. It never enters OneDrive. Listener registration is blocked until a fresh pinned-host transfer yields valid Base64 with at least 32 decoded bytes and owner/System-only file permissions. Greatroom's verified Ed25519 host key is shipped in a dedicated known-hosts file; accept-on-first-use is disabled.
  • Public Secure Shell keys may use the OneDrive public-key mesh.
  • The canonical fleet-dispatch/setup-urlacl.ps1 owns the two HTTP URL reservations. Bootstrap proves their exact owner before repair-fleet-listener.ps1 handles account selection, firewall rules, scheduled-task registration, and two same-process health probes.
  • The Windows ARM64 listener runs through a C# Windows executable with no console and a kill-on-close Job Object; its engine starts suspended and joins that job before executing. Its scheduled task must have exactly one action and probe as hidden, limited-rights, interactive-logon, battery-safe, and bound to that exact executable.
  • Windows ARM64 package installation is forced to --architecture arm64. Package-manager output never counts as success; a fresh binary, version, and architecture probe decides the result.