Add checkboxes to procedural sections

suse-autoyast-deploy-phase1.md

@@ -0,0 +1,322 @@
+# suse-autoyast-deploy-phase1.md
+
+REFER TO ALL RELEVANT OFFICIAL SOFTWARE MANUALS
+
+Orchestrator workflow for the VM-based test cycle: derive a VM spec,
+build the VM, run an AutoYaST deploy against it, verify the result.
+Phase 1 of the initial deploy workflow — see Section: Relationship to
+bare-metal deployment. Calls into separate documents for input and
+subprocess steps, same pattern as a bash orchestrator calling libraries
+and subscripts.
+
+---
+
+## SECTION: Scope
+<!-- source: ce-authored -->
+
+Assumes `tinkerpad13-tooling-workflow-proposed.md` is already applied.
+Assumes `opensuse-deploy-workflow-proposed.md` for version selection,
+media policy, and sudo/targetpw background.
+
+| Referenced document | Called between |
+|---|---|
+| `device-profile.md` | Start of workflow |
+| `autoyast-crafting-workflow.md` | VM creation and install pass |
+| `autoyast-error-debugging-workflow.md` | Install pass and recording |
+| `suse-deploy-post-install-testing-workflow.md` | Install pass and recording |
+
+None of these four are written yet. This workflow holds the sequence
+and handoff points; each can be authored independently without changing
+this document.
+
+[NOTE] Deployment planning — confirming a client's proposed use cases
+are actually achievable on the hardware/spec being deployed, and making
+pre-deployment recommendations — is a separate service, not part of
+this workflow. This workflow tests whether a base install completes and
+verifies correctly; it does not evaluate whether the deployment is the
+right fit for the client's goals.
+
+---
+
+## SECTION: Relationship to bare-metal deployment
+<!-- source: ce-authored -->
+
+This document is `suse-autoyast-deploy-phase1.md` — workbench VM testing
+on tinkerpad13. Once a pass is clean, proceed to
+`suse-autoyast-deploy-phase2.md` (not yet written) — same DVD image,
+same verified profile, same verification checklist, executed on the
+real device at the client site.
+
+Phase 2 doesn't re-decide anything Phase 1 already settled. It adds what
+only exists on real hardware: the literal physical-presence requirement,
+any hardware-specific manual checks flagged in Section: Device spec
+gathering, and live deploy mods if the real device deviates from what
+the VM predicted.
+
+The retained VM, snapshot, and clone mechanics in this document exist
+because of this relationship — the retained VM is kept specifically so
+Phase 2's real-world proving period has something faithful to check
+itself against.
+
+---
+
+## SECTION: Device spec gathering — via device-profile.md
+<!-- source: ce-authored -->
+
+Refer to `device-profile.md` to set VM specifications matching the
+client device. Not yet designed. Required variable categories: technical
+specs, connectivity state, device purpose/role. Covers base OS install
+only — GPU driver stack, services, and applications are out of scope,
+handled by separate provisioning later.
+
+- [ ] Apply CE's 25% headroom rule against tinkerpad13's total capacity,
+      not the VM spec in isolation.
+- [ ] Confirm one VM at a time — series before parallel.
+
+---
+
+## SECTION: VM creation — TUI, scripted
+<!-- source: ce-authored -->
+
+- [ ] Build the VM:
+
+```sh
+virt-install \
+  --name CLIENT-PROFILE-NAME \
+  --memory 2048 \
+  --vcpus 2 \
+  --disk size=20 \
+  --cdrom /path/to/downloaded.iso \
+  --os-variant opensuse-leap16.0 \
+  --network network=default \
+  --graphics spice
+```
+
+Adjust `--memory`, `--vcpus`, `--disk`, `--os-variant` per
+`device-profile.md` and target SUSE version.
+
+- [ ] Confirm the VM exists and is in the expected state:
+
+```sh
+virsh list --all
+```
+
+---
+
+## SECTION: Profile crafting — referenced
+<!-- source: ce-authored -->
+
+See `autoyast-crafting-workflow.md` (not yet written) for authoring or
+selecting the `autoinst.xml` profile before proceeding.
+
+---
+
+## SECTION: Install pass — GUI, attended
+<!-- source: ce-authored -->
+
+- [ ] Confirm DVD image version/date and profile version are recorded.
+- [ ] Check whether `sudo-policy-wheel-auth-self` ships on the DVD or
+      requires a mid-install network pull (see
+      `opensuse-deploy-workflow-proposed.md`, Section: Sudo / targetpw
+      fix).
+- [ ] Watch the install:
+
+```sh
+virt-viewer CLIENT-PROFILE-NAME
+```
+
+---
+
+## SECTION: Post-install verification — referenced
+<!-- source: ce-authored -->
+
+- [ ] Run the verification checklist from
+      `opensuse-deploy-workflow-proposed.md`.
+
+See `autoyast-error-debugging-workflow.md` (not yet written) for
+diagnosing a failed check to root cause.
+
+---
+
+## SECTION: Post-install debugging and inspection — referenced
+<!-- source: ce-authored -->
+
+See `suse-deploy-post-install-testing-workflow.md` (not yet written) for
+inspection beyond pass/fail verification.
+
+---
+
+## SECTION: Post-install — VM lifecycle, TUI
+<!-- source: ce-authored -->
+
+- [ ] Shut down or start the VM as needed:
+
+```sh
+virsh shutdown CLIENT-PROFILE-NAME
+virsh start CLIENT-PROFILE-NAME
+```
+
+[WARNING] Do not `undefine --remove-all-storage` on a successful pass —
+see Section: VM retention below.
+
+---
+
+## SECTION: VM retention — 90-day proving period
+<!-- source: ce-authored -->
+
+Retain the VM 90 days past physical deployment rather than deleting
+immediately — the exact VM that produced a working install is the first
+diagnostic step if an issue surfaces on the client's real hardware
+within that window.
+
+- [ ] Shut down, don't undefine, on a successful pass.
+- [ ] Record retention start date and client/device in the pass's
+      handoff record.
+- [ ] Budget total retained-VM storage against tinkerpad13's capacity,
+      25% headroom rule applied cumulatively, not per-VM.
+- [ ] At 90 days with no traceable issues, remove:
+
+```sh
+virsh undefine CLIENT-PROFILE-NAME --remove-all-storage
+```
+
+- [ ] If an issue surfaces within the window, reproduce against the
+      retained VM first — confirms whether it's profile-level or
+      hardware-specific to the physical device.
+
+---
+
+## SECTION: Live deploy mods vs. post-deploy additions — which tool applies
+<!-- source: ce-authored -->
+
+These are two different kinds of change to the retained VM, and they
+call for different tools because they sit at different distances from
+this workflow's own scope:
+
+**Live deploy mods** — corrections discovered during the actual physical
+deployment that deviate from what the tested profile/VM produced (a
+hardware quirk forced a different config, a manual fix was needed
+on-site). These stay *within* this workflow's scope — they're base
+install corrections, the same category of thing this whole workflow
+tests for. Use **snapshot**: checkpoint at base-install-verified, apply
+the deviation directly to the retained VM, and the snapshot remains
+available as a return point if the deviation itself turns out wrong.
+
+**Post-deploy additions** — a server stack, an AI stack, applications,
+anything from the config/services layer this workflow explicitly
+excludes (Section: Device spec gathering). These are a large leap in
+scope, not a correction to the base install — a genuinely separate
+workflow's work, even if it happens to start from this VM. Use
+**clone**: fork the VM first, do all of that work in the fork, leave the
+retained original as the untouched base-install artifact.
+
+Rule of thumb: if the change is something `autoyast-crafting-workflow.md`
+or `autoyast-error-debugging-workflow.md` would recognize as their own
+territory, it's a live deploy mod — snapshot. If it's something a future
+Ansible playbook or application-layer workflow would own instead, it's a
+post-deploy addition — clone.
+
+### Clone — post-deploy additions
+
+- [ ] Fork the VM before starting any config/services-layer work:
+
+```sh
+virt-clone --original CLIENT-PROFILE-NAME --name CLIENT-PROFILE-NAME-clone --auto-clone
+```
+
+- [ ] Do all further exploration in the clone. The retained original
+      stays untouched until either its 90 days elapse or it's needed to
+      reproduce an actual reported issue.
+
+### Snapshot — live deploy mods
+
+- [ ] Confirm the disk is qcow2 — snapshots require it:
+
+```sh
+virsh domblklist CLIENT-PROFILE-NAME --details
+```
+
+- [ ] Checkpoint immediately after verification passes, before any
+      deviation is applied:
+
+```sh
+virsh snapshot-create-as \
+  --domain CLIENT-PROFILE-NAME \
+  --name base-install-verified \
+  --description "Base install complete, verification checklist passed" \
+  --disk-only \
+  --atomic
+```
+
+- [ ] Apply the live deploy mod to the retained VM directly after the
+      checkpoint.
+- [ ] If the mod turns out problematic later, revert:
+
+```sh
+virsh snapshot-revert CLIENT-PROFILE-NAME base-install-verified
+```
+
+[WARNING] Internal snapshots require qcow2 and are not supported on VMs
+using pflash-based (OVMF/UEFI) firmware. Use external snapshots
+(`--diskspec ...,snapshot=external`) for those instead, or rely on clone
+and 90-day retention alone.
+
+[NOTE] A snapshot is not a substitute for the 90-day retention policy —
+it depends on the same base disk image it was taken from. It's a
+finer-grained checkpoint within the retention period, not a replacement
+for keeping the VM itself.
+
+- [ ] Limit snapshot chains to a small number — one checkpoint at
+      base-install-verified is normally sufficient.
+
+### Recording a live deploy mod
+
+- [ ] Record the deviation in the pass's handoff record — what changed,
+      why it deviated from the tested profile, and that the
+      snapshot/checkpoint exists.
+- [ ] If a deviation depends on physical hardware the VM never modeled
+      and can't be fully reproduced, note that gap explicitly rather
+      than implying parity that doesn't exist.
+
+[NOTE] Same honesty standard as tinkerpad's "13b" — an unrecorded
+deviation is worse than one that never happened.
+
+---
+
+## SECTION: Test pass — recording
+<!-- source: ce-authored -->
+
+- [ ] Write a named, dated handoff record for the pass. Include:
+  - [ ] VM spec used (CPU, RAM, disk)
+  - [ ] DVD image version/date
+  - [ ] Profile version
+  - [ ] Verification checklist results
+  - [ ] Retention start date
+  - [ ] Any manual correction made outside the documented flow — named
+        honestly, per tinkerpad's "13b" precedent
+- [ ] Clean pass → proceed to physical deployment
+      (`suse-autoyast-deploy-phase2.md`), same DVD image and profile,
+      no changes.
+- [ ] Failed pass → new pass, one issue at a time, own handoff record.
+
+---
+
+## SECTION: Known unknowns going into the first Leap/SLES test
+<!-- source: ce-authored -->
+
+- Whether `sudo-policy-wheel-auth-self` behaves identically on Leap/SLES
+  as on Tumbleweed
+- Whether it ships on the Leap/SLES DVD or needs a mid-install network
+  pull
+- The `<name>` vs `<n>` AutoYaST tag inconsistency, unresolved since
+  tinkerpad
+- Whether firewall zone rules apply correctly post-install — never
+  verified on tinkerpad
+
+---
+**Source:** CE OS — automation testing process, developed 2026-07-25
+**Source-type:** `ce-authored`
+**Licence:** John A. Hoeven with the ethical assistance of Claude AI — Public Domain (CE FFM)
+**Verified-on:** unverified — proposed, pending first real Leap/SLES VM test pass
+**Session:** 2026-07-25
+**Filename:** suse-autoyast-deploy-phase1.md