[Frontier] [CUT15-01] Install S15 fresh on jit-vm with owner acceptance and a recoverable install

Body revised on 2026-11-03 for the owner's final decisions; the previous body (Pi-era target, Proxmox jit-work VM) remains in the issue edit history.

Parent

S15 — #316. Canonical spec: docs/specs/S15-conversational-autonomy.md.

Model tier

Frontier: production installer, service identity, host prerequisites for a protected nested VM, rollback of a failed install and owner acceptance of an exact build/policy.

Owner decisions (2026-11-03, final)

1. Retire the Pi. Jit runs on the Proxmox VM jit-vm only. Start fresh: no Pi data (legacy or S14) is migrated. The Pi is not changed by this work; the owner retires it after cutover.
2. Single-host topology: the S15 controller runs on jit-vm, and the working VM is a nested KVM guest that Jit creates and manages there (VM15-02 [Frontier] [VM15-02] Run the working VM as a Jit-managed nested KVM guest on the controller host #366, SETUP15-01 [Frontier] [SETUP15-01] Create the working computer automatically during S15 setup on KVM hosts #369). Owner-supplied VMs stay optional for extra compute (POOL15-01 [Frontier] [POOL15-01] Place work across several enrolled working computers in one team pool #370).
3. Telegram bot removed 2026-11-06 (ADR 0085); no channel setup is needed.
4. jit-vm has 10 vCPU / 20 GB (verified 2026-11-03: 10 CPUs, 19 GiB usable, vmx/AVX, no AVX2, /dev/kvm usable, 195 GB root with ~152 GB free).
5. The old S14 test installs on jit-vm (service users jit/jit-s14, units, subuid ranges, Podman storage, 16 loop disks, evidence files) are test-only and are removed before the production install (authorized).

Context to read

AGENTS.md; CONTEXT.md; docs/agents/workflow.md; docs/specs/S15-conversational-autonomy.md; docs/adr/0064, 0067; install.sh; ops/package/installer/**; ops/evidence/s15-install-service.ts (the arm64 staging installer to generalize); src/s15/main.ts (S15RuntimeConfig, runS15); docs/runbooks/s14-default-cutover.md; tests/runtime-selection.test.ts.

Deliverable

1. Installer (code, Refs #341): install.sh --s15 explicitly selects the S15 runtime as a separate installation (service identity, state, unit, journald namespace), never reinterpreting legacy/S14 configs or touching their data. It installs the host prerequisites the nested working VM needs (QEMU packages, kvm group for the service identity, lingering user manager), installs the exact release, generates the credential-free S15 runtime config without owner input, runs init, enables the service and lets setup create the working computer automatically. A failed install leaves a recoverable state: the new unit is stopped/removed, the prior release (if any) stays active, other installations are untouched, and re-running repairs idempotently. --s15 --uninstall stops/removes the service and retains data like the other runtimes. Upgrade switches the release atomically with a health check and rolls back to the previous release on failure.
2. Live install on jit-vm (orchestrator): remove the old S14 test installs, install the exact final reviewed build, verify health and the automatically created working computer, and record exact SHA/hashes in .local.
3. Owner acceptance (owner steps, last): owner password, Codex device login for the S15 service identity, the GitHub sandbox token, optional Google consent, review of the exact build/policy/rollback evidence, explicit acceptance, first ordinary conversation in the Web/PWA, then retiring the Pi.

Implementation steps

1. Extend install.sh/installer with --s15 (mutually exclusive with --s14/--legacy), the S15 plan lines, prerequisites and dry-run coverage.
2. Generate the S15 runtime config from detected facts (installation id, directories, origin/access model consistent with the S14 installer, the approved Codex subscription route catalog, no policy, no budget, no personal GitHub rule, local working-computer pool).
3. Install a hardened system unit for the controller; the nested VM runs outside the controller cgroup per VM15-02 so restarts/upgrades do not kill it.
4. Transactional install/upgrade with rollback of the release symlink and unit on failure; never delete another installation's data.
5. Runbook docs/runbooks/s15-install.md: install, upgrade, rollback, uninstall, owner steps.

Acceptance criteria

• install.sh --s15 on a fresh host yields a running S15 controller with a ready working computer and no hand-edited files.
• Legacy/S14 selection and omitted-runtime configs are never reinterpreted; other installations are untouched (fixtures).
• An injected failure at each install/upgrade step leaves the prior state recoverable and a re-run repairs it.
• The live install on jit-vm runs the exact reviewed build with fresh state; old S14 test installs are gone; the Pi is unchanged.
• Owner acceptance binds the exact build, host, policy revision and activation time; the first Web conversation performs real approved work and human-required gates behave as proved on [Frontier] [EVID15-01] Prove the protected boundaries and the GitHub scenario on the tested build #340.

Tests and evidence

1. Installer/runtime-selection fixtures (--dry-run --root) for --s15, conflicts with --s14/--legacy, prerequisites, generated config shape and no-secret config.
2. Failure-injection fixtures for each step → recoverable state; upgrade health-check failure → previous release restored.
3. Live install log and service/working-computer health on jit-vm in .local, summarized here.
4. Owner acceptance record (owner step).

Requirements

FR-18/23/35/36/37/38; NFR-04/07/08/10/12/14. Acceptance: S15-AC16.

Blocked by

• [Frontier] [VM15-02] Run the working VM as a Jit-managed nested KVM guest on the controller host #366 VM15-02, [Frontier] [SETUP15-01] Create the working computer automatically during S15 setup on KVM hosts #369 SETUP15-01 / [Frontier] [POOL15-01] Place work across several enrolled working computers in one team pool #370 POOL15-01, [Frontier] [CHAN15-01] Talk to S15 Jit through a bound Telegram bot #368 CHAN15-01 / [Frontier] [WORK15-02] Keep owner stall replies that wait to resume a duty durable across restart #367 WORK15-02 (code the installer composes).
• [Frontier] [POLICY15-02] Install the first standing policy from the Web UI on a fresh install #384 POLICY15-02 and [Frontier] [GIT15-04] Connect GitHub repositories from the Web UI on a fresh install #385 GIT15-04 (first standing policy and GitHub connection from the Web UI; without them a fresh install cannot do work without a config edit), [Frontier] [BROW15-02] Enable the protected browser on a fresh install without config edits #380 BROW15-02, [Frontier] [MODEL15-03] Renew route credentials before listing so a fresh process survives token expiry #381 MODEL15-03.
• [Frontier] [EVID15-01] Prove the protected boundaries and the GitHub scenario on the tested build #340 EVID15-01 for live acceptance evidence. Owner steps are last.

Contracts used/delivered

Uses S15RuntimeConfig, runS15, VM15-02/SETUP15-01/CHAN15-01 setup paths. Delivers the --s15 installer selection, generated config, unit and runbook.

Out of scope

Migrating Pi or S14 data; changing the Pi; deleting the owner's Lima VMs on the Mac without asking.

Do not

Do not touch the Pi; do not import legacy/S14 state; do not put credentials in config, logs or the repo; do not install a policy, budget or personal GitHub rule on the owner's behalf; do not add AI attribution; do not merge the implementation PR yourself.

Definition of done

Installer PR: bun install --frozen-lockfile, bun run typecheck, bun run test, git diff --check pass; PR body Refs #341 (owner steps remain). This issue closes only after the live install and explicit owner acceptance are recorded.

Owner revision 2026-11-06

Telegram was removed from Jit (ADR 0085, #441) and the default authority became Grok-style (ADR 0084, #442). Telegram steps and evidence in this issue no longer apply; the first conversation and notifications use the Web/PWA.