Skip to content

Windows — Install / Switch / Uninstall End-to-End Test Prompt

A ready-to-run prompt for a freshly installed Claude Code with Administrator privileges on a clean Windows machine. It dog-foods the full AIOS lifecycle — install → create a brain → create a second AIOS → switch between them → back up → delete — and reports PASS/FAIL per step.

Generated by /pre-flight-tooling-validation after its Windows agent confirmed the repo ships interface-complete tooling for all five lifecycle capabilities. Re-run that skill to regenerate this prompt if the tooling changes.

Do not run this on a primary/owner machinebootstrap rewrites the live ~/.claude (skills + memory redirect) and local security policy (ACLs / logon rights). Use a dedicated, resettable test box. See getting_started/lifecycle_test.md (operator runbook) and system/uninstall.md (authoritative teardown + verification) for the human-facing versions.


The prompt

Paste everything in the fenced block below into a fresh, elevated Claude Code session on the target machine.

You are validating the Horizon AIOS full lifecycle on a FRESH, CLEAN Windows machine where
you have Administrator privileges. Prereqs already installed: Git, Python, Claude Code.
Work in an ELEVATED PowerShell. Rules:
- Report PASS/FAIL after each numbered step, with the command output that proves it.
- STOP immediately on the first FAIL and report exactly what broke.
- Always run the `--dry-run` variant before any destructive step.
- Never push user data to the public upstream; back up only to the operator's own remote.
- This must NOT be run on a primary/owner machine — bootstrap rewrites ~/.claude and local
  security policy.

0. CONFIGURE — ASK THE OPERATOR FIRST (do not assume any paths)
   Before setting variables or running anything, ASK the operator these questions and
   wait for answers. Do NOT prescribe or default the install locations:
     - Which directory should hold AIOS install #1 (the primary AIOS)?      -> $Root1
     - Which directory should hold AIOS install #2 (the second AIOS)?       -> $Root2
     - What clone URL should be used?                                       -> $Remote
     - What scratch remote should user-data backup push to?                 -> $BackupRemote
   Validate the two install directories before proceeding:
     - $Root1 and $Root2 MUST be different paths.
     - Neither may be an existing Horizon AIOS root or a primary/owner checkout
       (refuse C:\devroot or any directory that already contains horizon_system\).
     - Their parent directories must exist and be writable; the leaf dirs should not
       already exist (git clone will create them).
   Then set the variables from the operator's answers:
     $Remote       = "<operator-provided clone URL>"
     $Root1        = "<operator-provided dir for AIOS #1>"
     $Root2        = "<operator-provided dir for AIOS #2>"
     $Brain        = "testbrain"
     $BackupRemote = "<operator-provided scratch remote>"
   Echo the final values back and get the operator's confirmation before step 1.

1. INSTALL (capability 1)
   git clone $Remote $Root1 ; cd $Root1
   .\horizon_system\sbin\uninstall.ps1 --dry-run        # baseline: expect ~nothing to remove
   .\horizon_system\sbin\bootstrap.ps1 --yes
   python .\horizon_system\sbin\horizon_aios_doctor.py               # PASS = all checks healthy
   aios list ; aios current                              # note the auto-registered name + (*) = $Root1

1A. LEAKAGE / HARDCODED-PATH SCAN (dev-environment leakage)
   This prompt is run by a development tool, so it must validate that NO path or
   identifier from the AIOS build/development environment leaked into the install.
   Because this box installed to $Root1 (NOT C:\devroot), any occurrence of the dev
   root in a GENERATED artifact is a hardcoded-path leak.
     $LeakPatterns = @('C:\devroot','C:/devroot')   # extend with any owner dev path/username you know
   Scan the runtime artifacts bootstrap/switch generate OUTSIDE the repo (highest risk):
     $Scan = @("$HOME\.horizon", "$HOME\.claude\settings.json")   # active_env.ps1, AIOS registry, harness wrapper
     foreach ($p in $Scan) { if (Test-Path $p) {
       Get-ChildItem $p -Recurse -File -ErrorAction SilentlyContinue |
         Select-String -SimpleMatch -Pattern $LeakPatterns } }
   Scan generated INSTANCE config under the install (instance .conf is generated, not shipped):
     Get-ChildItem "$Root1" -Recurse -Include *.conf -ErrorAction SilentlyContinue |
       Select-String -SimpleMatch -Pattern $LeakPatterns
   Confirm active_env resolves only to $Root1 (and $Root2 after switch), never a dev path:
     Get-Content "$HOME\.horizon\active_env.ps1" | Select-String 'HORIZON_'
   NOTE: documentation that intentionally cites C:\devroot as the canonical dev root is
   EXPECTED and is not a leak — scope this scan to generated artifacts/instance config, not docs.
   PASS = ZERO leak hits in generated artifacts/config; active_env points only at $Root1/$Root2.
   FAIL = any dev-env path/identifier present -> report file + line verbatim; this is a
          framework hardcoded-path bug to fix, NOT a test-box issue. (Re-run after step 4.)

2. CREATE A BRAIN (capability 2)
   python .\horizon_system\sbin\horizon_aios_create_brain.py $Brain --automation scheduled --dry-run
   python .\horizon_system\sbin\horizon_aios_create_brain.py $Brain --automation scheduled
   python .\horizon_system\sbin\horizon_aios_brain_logon_rights.py check $Brain   # expect SeBatchLogonRight held
   # Verify: OS user $Brain exists, 'brains' group exists, brains\$Brain workspace created.
   # PASS = brain provisioned and the batch-logon right is verified.

2A. BRAIN FILESYSTEM ISOLATION (security invariant / criterion #5)
   # The safe (non-destructive) check should already have passed as part of step 1
   # install verification:
   #   python .\horizon_system\sbin\horizon_aios_verify_isolation.py
   # Now run the empirical live probe against the just-created brain. Because the
   # brain already exists we pass --use-existing so the script probes it in place
   # without creating or removing any OS account.
   python .\horizon_system\sbin\horizon_aios_verify_isolation.py --live --use-existing --brain-name $Brain --yes
   # PASS criterion: BIN=READABLE and SBIN=DENIED -> [PASS].
   # A clear SKIP (keyring absent, or the Start-Process -Credential launch refused)
   # is NOT a FAIL — it is a harness / logon-right limitation, not an isolation
   # breach. --automation scheduled grants only the BATCH right, not the
   # interactive right that CreateProcessWithLogonW requires. The static ACL
   # posture is still proven by the default (non-live) safe check above.

3. CREATE A SECOND AIOS IN ANOTHER DIRECTORY (capability 3)
   git clone $Remote $Root2
   aios register home $Root2                              # register validates it's a real AIOS root
   aios list                                              # expect BOTH roots; $Root1 still (*)
   # (optional, to prove a full 2nd install) cd $Root2 ; .\horizon_system\sbin\bootstrap.ps1 --yes ; cd $Root1
   # PASS = second AIOS registered (and, if bootstrapped, doctor-healthy).

4. SWITCH BACK AND FORTH (capability 4)
   aios switch home --dry-run                             # preview pointer rewrites, no change
   aios switch home ; aios current                       # root now $Root2
   Get-Content $HOME\.horizon\active_env.ps1 | Select-String HORIZON_ROOT   # regenerated to $Root2
   # Open a NEW elevated shell; confirm $env:HORIZON_ROOT == $Root2. Confirm ~/.claude/settings.json
   # is UNCHANGED (points at the ~/.horizon\bin\aios-exec.ps1 wrapper — the indirection layer).
   aios switch <name-from-step-1> ; aios current         # back to $Root1
   # PASS = switch repoints active_env + `aios current` both ways; settings.json untouched.
   # RE-RUN the step 1A leakage scan now: switch regenerated active_env — confirm it
   # resolves to $Root2/$Root1 only, with ZERO dev-environment (C:\devroot) leakage.

5. BACK UP USER DATA (distribution model)
   python .\horizon_system\sbin\horizon_aios_backup_user_data.py      # to $BackupRemote
   # PASS = pushes memory/handoffs/objectives to YOUR remote AND refuses the public upstream.

6. DELETE / RESET (capability 5)
   python .\horizon_system\sbin\horizon_aios_remove_brain.py $Brain --yes    # tear down the brain first
   .\horizon_system\sbin\uninstall.ps1 --dry-run
   .\horizon_system\sbin\uninstall.ps1 --yes
   # Run the post-uninstall VERIFICATION CHECKLIST in
   #   horizon_system\documentation\system\uninstall.md
   # (horizon_aios_doctor.py failures = success; ~/.horizon gone; ~/.claude/projects + skills symlinks gone
   #  with targets intact; horizon_system\bin out of Machine PATH; brains ACEs fully stripped —
   #  no residual grant OR DENY ACE, since uninstall uses icacls /remove not /remove:g).
   # settings.json: removed ONLY if it byte-matches the bootstrap default; if you customized it,
   #  PASS = it is preserved with a [MANUAL] advisory (not deleted).
   aios unregister home 2>$null                            # if registry survived; usually removed with ~/.horizon
   # (optional) if you bootstrapped $Root2: cd $Root2 ; .\horizon_system\sbin\uninstall.ps1 --yes

7. IDEMPOTENCY
   .\horizon_system\sbin\uninstall.ps1 --yes              # second run: expect all [SKIP], no changes
   # PASS = idempotent reset; the machine is clean and re-usable as a test rig.
   # Also confirm: icacls on $HORIZON_SYSTEM subtrees shows NO residual brains-group DENY ACEs.

Finish with a per-step PASS/FAIL table. Call out the step 1A leakage result explicitly
(PASS = no dev-environment paths/identifiers in any generated artifact or instance config).
Report any residue, surprise, leak hit, or manual step needed, verbatim.

See also

  • getting_started/lifecycle_test.md — the operator runbook this prompt automates.
  • system/uninstall.md — authoritative teardown + post-uninstall verification.
  • system/aios_switching.md — the switcher and the indirection layer.
  • development_tools/consistency_checks.md — the project's consistency standard.