docs(guides): bring the seven setup guides in line with the practitioner skill

The guides were written before the skill existed and a scored audit found
three gaps. Fixed by a subagent running under the skill, with measured
values, versions, IPs and quoted output declared off limits.

The big one: every step showed a command and its output, and almost none
said which line to look at or what it meant. 64 interpretation pairs added
across the seven files, weighted where the reading is hardest — 20 in the
Keycloak stage, where a Secret existing and a pod having received it are
different facts.

Only the extracting form of curl appeared. Where the reader meets a response
for the first time the guides now open with curl -I or curl -v and name the
lines worth reading; -w '%{http_code}' survives only where the code is a
value being compared — two upstream nodes against each other, or the 900-run
control loop.

Listing Secret keys went from a three-stage pipe to kubectl describe secret,
which prints the key names and their byte counts in one native command
without exposing a value.

And a tool assumption: jq and yamllint are installed on neither the lab host
nor the guests. The guides now say so where JSON is read by eye, rather than
sending the reader to install something mid-diagnosis. cloud-init schema is
on the guests and is now the guest-side check.

Also removes a stray Playwright screenshot committed at the repository root
in 919547a; the evidence copy under docs/evidence/b7a-orphan-session/ is the
one the document references.

Four things the audit left standing are recorded in the agent's report rather
than papered over — notably that 04's reload measurements are stated without
a reproduction procedure, and that 05 and 06 reference each other as
prerequisites.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/guides/01-vms/README.md

@@ -29,11 +29,20 @@ sudo curl -LO https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-ge
 sudo mv debian-12-genericcloud-amd64.qcow2 base.qcow2
 ```
 
-**확인**
+**확인** — 받은 파일이 온전한 qcow2 인가
 ```bash
 qemu-img info /var/lib/libvirt/images/base.qcow2
 ```
 
+**어디를 봐야 하는가** — 세 줄이다. `file format:` 이 `qcow2` 인가(`raw` 로
+읽히면 내려받기가 중간에 끊겨 HTML 오류 페이지를 저장한 것이다),
+`virtual size:` 가 `disk size:` 보다 훨씬 큰가(qcow2 는 희소 파일이라 이게
+정상이다), `backing file:` 줄이 **없는가**. base 는 아무것도 뒤에 두지 않는다.
+
+**이 결과가 의미하는 것** — 셋이 맞으면 이 파일을 4번에서 오버레이의 바닥으로
+쓸 수 있다. 여기서 형식이 틀린 채로 진행하면 증상이 `virt-install` 이 아니라
+**게스트가 부팅을 못 하는 것**으로 나타나 원인을 찾기 어려워진다.
+
 ## 2. cloud-init 을 쓴다
 
 게스트마다 하나씩 만든다. 템플릿은
@@ -93,8 +102,41 @@ grep -c 'ssh-ed25519\|ssh-rsa' kc-lab-1.yaml   # 2 여야 한다
 python3 -c 'import yaml,sys; yaml.safe_load(open("kc-lab-1.yaml")); print("YAML OK")'
 ```
 
-마지막 줄이 중요하다. **cloud-init 은 파싱에 실패해도 아무 오류를 남기지
-않으므로**, 넣기 전에 여기서 걸러야 한다.
+**어디를 봐야 하는가** — 숫자 두 개와 낱말 하나. 첫 줄이 `0` 이 아니면
+`__LAB_HOST_KEY__` 같은 문자열이 남아 있는 것이고, 둘째 줄이 `2` 가 아니면
+`sed` 치환 중 하나가 안 먹은 것이다. 셋째 줄은 `YAML OK` 가 찍히는가만 본다 —
+찍히지 않으면 대신 파이썬 예외 줄이 나오고, 거기 적힌 `line N` 이 문제의
+줄 번호다. 이 셋은 값을 뽑는 것이 아니라 **찍힌 숫자를 눈으로 비교하는**
+용도라 이 형태가 맞다.
+
+**이 결과가 의미하는 것** — `0` / `2` / `YAML OK` 셋이 다 맞아야 시드를 만든다.
+어긋난 채로 3번을 진행하면 **cloud-init 은 파싱에 실패해도 아무 오류를 남기지
+않으므로**, 증상이 「SSH 가 안 붙는다」로만 나타나고 원인이 이 파일에 있다는
+사실이 드러나지 않는다. 여기서 거르는 것이 뒤에서 30분 걸릴 일을 없앤다.
+
+> **`yamllint` 는 이 실험대에 없다.** 있으면 좋지만 없다고 설치하러 가지
+> 않는다 — 위 세 줄로 충분하다.
+
+**게스트가 한 대라도 떠 있으면 한 단계 더 볼 수 있다.** YAML 로 파싱된다는
+것과 **cloud-config 로 유효하다**는 것은 다르다. 키 이름 오타(`user` vs
+`users`)는 위 검사를 그냥 통과한다. cloud-init 자신의 스키마 검사기가
+게스트에 들어 있다 — `kc-lab-2` 용 파일은 `kc-lab-1` 에서 검사할 수 있다.
+
+```bash
+# 이 파일에는 콘솔 비밀번호가 평문으로 들어 있다 — /tmp 가 아니라
+# 자기 홈에 600 으로 두고, 검사가 끝나면 바로 지운다
+ssh donghyeon@192.168.122.11 'umask 077; cat > ~/kc-lab-2.yaml'  < kc-lab-2.yaml
+ssh donghyeon@192.168.122.11 'cloud-init schema -c ~/kc-lab-2.yaml; rm -f ~/kc-lab-2.yaml'
+```
+
+**어디를 봐야 하는가** — 마지막 한 줄. 통과하면 유효하다는 한 줄만 나오고,
+아니면 `Invalid cloud-config` 아래에 **어느 키가 왜 틀렸는지**가 나열된다.
+경고(`deprecated`)와 오류(`error`)는 다르다 — 경고는 지금 동작한다.
+
+**이 결과가 의미하는 것** — 오류가 나면 그 키는 **조용히 무시된다.**
+`users` 를 `user` 로 잘못 쓰면 계정이 안 생기고, 증상은 역시 「SSH 가 안
+붙는다」 하나뿐이다. 첫 게스트(`kc-lab-1`)를 만들 때는 검사할 게스트가 아직
+없으니 위 세 줄로 가고, 둘째부터는 이 검사를 거친다.
 
 세 가지가 의도적이다.
 
@@ -124,6 +166,26 @@ virsh vol-create-as default seed-kc-lab-1.iso "$(stat -c%s seed-kc-lab-1.iso)" -
 virsh vol-upload --pool default seed-kc-lab-1.iso seed-kc-lab-1.iso
 ```
 
+**확인** — 볼륨이 풀에 올라갔고 비어 있지 않은가
+```bash
+virsh vol-list default
+```
+
+**어디를 봐야 하는가** — `seed-kc-lab-1.iso` 행이 목록에 있는가. 있으면
+크기까지 본다.
+
+```bash
+virsh vol-info --pool default seed-kc-lab-1.iso
+```
+
+**Capacity** 가 방금 만든 로컬 파일 크기(`stat -c%s seed-kc-lab-1.iso`)와
+같아야 한다.
+
+**이 결과가 의미하는 것** — `vol-create-as` 는 **빈 볼륨을 만들 뿐**이고
+내용은 `vol-upload` 가 채운다. 두 명령 중 뒤엣것을 빠뜨리면 목록에는 이름이
+보이지만 안이 0 으로 채워져 있고, cloud-init 은 `cidata` 라벨을 못 찾아
+조용히 끝난다 — 증상은 또 「SSH 가 안 붙는다」다. 크기가 맞으면 4번으로 간다.
+
 `instance-id` 에 타임스탬프를 넣는 이유가 있다. cloud-init 은 **인스턴스마다
 한 번만** 초기화 모듈을 돌린다. id 가 같으면 이미 한 것으로 보고 건너뛰므로,
 user-data 를 고쳐도 반영되지 않는다.
@@ -164,7 +226,7 @@ virsh net-update default add ip-dhcp-host \
 `--live --config` 둘 다 준다. `--live` 만 주면 재부팅에 사라지고, `--config`
 만 주면 지금 반영되지 않는다.
 
-**확인**
+**확인** — 예약이 실제로 들어갔는가
 ```bash
 virsh net-dumpxml default | grep ip-dhcp-host -A3
 ```
@@ -176,9 +238,20 @@ virsh net-dumpxml default | grep ip-dhcp-host -A3
 <host mac='52:54:00:aa:bb:12' name='kc-lab-2' ip='192.168.122.12'/>
 ```
 
+**어디를 봐야 하는가** — `<host>` 두 줄의 **MAC 끝 두 자리와 IP 끝 숫자가
+짝이 맞는가**(`:11` ↔ `.11`, `:12` ↔ `.12`). MAC 은 4번의 `virt-install
+--network mac=` 에 쓴 값과 한 글자도 다르면 안 된다. `<range>` 줄은 예약이
+아니라 동적 대역이라, 예약 IP 가 이 안에 들어 있어도 상관없다.
+
+**이 결과가 의미하는 것** — 두 줄이 다 보이면 게스트는 재부팅해도 같은 IP 를
+받는다. 한 줄만 보이면 `--live --config` 중 하나를 빠뜨린 것이다.
+`net-dumpxml` 은 **지금 돌고 있는 정의**를 보여 주므로 여기 보이는 것은
+`--live` 가 먹었다는 뜻이고, 재부팅 뒤에도 남는지는
+`virsh net-dumpxml --inactive default` 로 따로 본다.
+
 ## 6. 붙어 본다
 
-**확인**
+**확인** — 떴는가, 그리고 cloud-init 이 제 일을 했는가
 ```bash
 virsh list --all
 ssh donghyeon@192.168.122.11 'hostname; cat /etc/os-release | head -1'
@@ -195,6 +268,17 @@ kc-lab-1
 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
 ```
 
+**어디를 봐야 하는가** — 세 가지다. ① State 가 두 대 다 `running` 인가
+(`shut off` 면 아직 안 뜬 것이고, Id 칸이 `-` 로 비어 있다). ② SSH 가
+**비밀번호를 묻지 않고** 통과했는가. ③ `hostname` 이 `kc-lab-1` 인가
+`localhost` 인가.
+
+**이 결과가 의미하는 것** — 이 세 줄이 cloud-init 성공의 판정 기준 전부다.
+호스트명이 바뀌어 있다는 것은 시드가 읽혔다는 뜻이고, 시드가 읽혔으면
+같은 파일에 있던 SSH 키도 들어갔다는 뜻이다. **`localhost` 가 나오면 SSH
+설정을 고치지 말고 시드부터 의심한다** — 아래 「막히면」의 화면 캡처로 간다.
+Id 번호가 2 보다 큰 것은 아무 뜻도 없다(만들고 지운 이력일 뿐이다).
+
 ---
 
 ## 막히면
@@ -214,8 +298,23 @@ PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
 virsh screenshot kc-lab-1 /tmp/kc1.ppm    # 확장자와 무관하게 PNG 로 저장된다
 ```
 
-`localhost login:` 이면 cloud-init 미실행, `kc-lab-1 login:` 이면 실행된 것이다.
-이 한 장이 「SSH 가 안 되는 이유」를 절반으로 줄인다.
+**어디를 봐야 하는가** — 이미지를 열어 **로그인 프롬프트 앞의 호스트명 한
+낱말**만 본다. `localhost login:` 인가 `kc-lab-1 login:` 인가.
+
+**이 결과가 의미하는 것** — `localhost` 면 cloud-init 이 아예 안 돌았다.
+시드를 못 찾은 것(4번의 `bus=virtio`)이거나 YAML 파싱 실패(2번)이므로 SSH
+쪽은 볼 필요가 없다. `kc-lab-1` 이면 cloud-init 은 돌았고 **그 안의 사용자·키
+단계에서 틀린** 것이라, 이제 콘솔로 들어가 게스트 안의 로그를 본다.
+
+```bash
+virsh console kc-lab-1        # 빠져나오려면 Ctrl+]
+# 게스트 안에서
+sudo cloud-init status --long
+sudo journalctl -u cloud-init -n 50
+```
+
+콘솔 로그인에 쓸 비밀번호가 2번의 `plain_text_passwd` 다. **이 한 장과 이 두
+줄이 「SSH 가 안 되는 이유」를 절반으로 줄인다.**
 
 ---