[Frontier] [SETUP15-01] Create the working computer automatically during S15 setup on KVM hosts

Parent

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

Model tier

Frontier: setup starts protected infrastructure (a nested VM) on the owner's behalf, needs durable, restart-safe provisioning state and honest capability reporting, and includes UI that must be authored by Claude Opus 5.5 at effort high (AGENTS.md).

Context to read

AGENTS.md; CONTEXT.md; the owner "just works" principle (no config files, never ask for values the system can infer, one click in the Web UI with an honest explanation of what is missing); docs/design/S15-conversational-experience.md (F1 step 3 "Working computer", F7, the i18n key table, and the F1/F7 handoff note added by VM15-02); docs/contracts/s15-working-vm-v1.md; src/s15/main.ts (runS15 setup/init), src/s15/composition.ts, src/s15/web/setup.ts (computerCard), src/s15/web/handler.ts (setup forms), src/i18n/th.ts and en.ts; the VM15-02 local nested-VM manager and local enrollment entry point.

Deliverable

On a Linux controller with usable /dev/kvm, S15 setup creates, starts and enrolls the default working computer without owner input, shows visible progress and honest errors, and survives restart mid-provisioning. Without KVM, setup offers the existing owner-supplied VM enrollment as the fallback, with a plain explanation.

Implementation steps

1. Host capability detection (protected): detect /dev/kvm access for the service identity, the QEMU binaries VM15-02 needs, CPU virtualization, free disk and RAM. Produce one typed result: ready, or a specific missing item with a stable code (e.g. vm_kvm_unavailable, vm_qemu_missing, vm_disk_insufficient, vm_host_too_small). Never infer readiness from configuration.
2. Durable provisioning job: a protected, idempotent job in the S15 journal with steps (verify host → download image → verify checksum → create disk → first boot → connect → checks → enrolled). Each step records progress and a stable error code. A controller restart resumes or safely restarts the current step; a partially created VM/disk is either reused after re-verification or removed by exact path. Only one provisioning job per default computer.
3. Triggering: setup --s15 and the Web first-run setup start the job automatically when the host is ready; the Web computer card shows the job instead of the paste-one-line form. Re-running setup never creates a second default computer. A failed job offers "Try again" (re-run from the failed step) and, for no-KVM hosts, the existing enrollment form.
4. Progress and errors in the UI (Claude Opus 5.5, effort high, authors this UI and copy): F1 step 3 and /resources/computer show the current step, elapsed time and the honest result. Capability rows (commands, sudo, Docker, network isolation, snapshot recovery, hypervisor stop) keep the existing proven/reported/missing/unproven/unavailable semantics: rows become proven only from observed evidence. Add th and en keys for every new string. The CLI setup --s15 prints concise progress lines and the final state as JSON, like the existing commands.
5. Defaults: working computer sizing comes from VM15-02's default sizing rule; the owner may edit CPU/RAM/disk later in settings (applies at next VM start). No value is asked during setup.
6. Docs: update docs/runbooks/s15-working-vm.md and the F1/F7 notes for the automatic path and the fallback.

Acceptance criteria

• On a KVM host, a fresh setup --s15 plus the owner's first Web visit results in an enrolled, ready working computer with no typed VM values.
• Progress is visible in the Web UI and CLI; every failure shows a specific, honest reason and a next step.
• Restarting the controller during provisioning neither duplicates the VM nor leaves an unusable half-created one.
• Without KVM, the owner sees why and is offered the existing enrollment form; nothing claims the computer is ready.
• Capability rows are never marked proven from configuration; Docker shows as reported only if the guest inventory found it.
• UI and copy are authored by Claude Opus 5.5 at effort high; th and en keys exist for every new string.

Tests and evidence

1. Host detection fixtures: /dev/kvm readable → ready; missing → vm_kvm_unavailable; QEMU missing → vm_qemu_missing; low disk → vm_disk_insufficient.
2. Provisioning job with fake manager/fake clock: happy path reaches enrolled; checksum failure stops at verify with its code; failure at boot → retry from boot.
3. Restart during each step → resumes without a second VM; leftover disk is re-verified or removed by exact path.
4. Re-running setup with an existing default computer → no new job.
5. Web rendering tests (th and en) for progress, error and no-KVM fallback states; no-script form posts still work.
6. Live: on jit-vm during the CUT15-01 install, setup creates the working computer automatically (recorded on [Frontier] [CUT15-01] Install S15 fresh on jit-vm with owner acceptance and a recoverable install #341).

Requirements

FR-18/23/35/36; NFR-04/10/12/14. Acceptance: S15-AC03 (setup), 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 (local nested-VM manager and local enrollment entry point must be merged).

Contracts used/delivered

Uses VM15-02 exports, VmEnrollment, VmStatus/VmCapability, computerCard. Delivers a host-capability probe, a durable provisioning job API with progress projection, and the updated computer card. Do not rename existing exported APIs.

Out of scope

Several computers and placement (POOL15-01 #370, bundled in the same PR); the production installer (CUT15-01); Telegram.

Do not

Do not ask the owner for values the system can infer; do not mark capabilities proven from configuration; do not run QEMU as root or give the guest any protected path; do not let model output or conversation trigger provisioning; do not add AI attribution; do not merge the PR yourself.

Definition of done

bun install --frozen-lockfile, bun run typecheck, bun run test, git diff --check pass on the final HEAD. PR body: Closes #369 and Closes #370 (bundled POOL15-01), tested SHA, screenshots or rendered HTML excerpts of the new states, not-run limits. No merge by the implementer.