# virtualization 7단계 하네스 리뷰

- 검토일: 2026-09-20
- 대상: 91 Record / 10 TechViz SVG / 92 historical run ledger
- 판정: **아직 더 봐야댐**

## 결론

전면 재작성 대상은 아니다. prose/voice 91/91 PASS, 기존 TechViz 10/10은 Text/Overlap/Provenance PASS이며 모두 실제 Record에서 사용된다.

완료 차단은 여섯 축이다.

1. 2026-09-17에 관측해 닫힌 DNS-01 사실이 SSOT·Question·Setup·Decision에 끝까지 전파되지 않았다.
2. certificate lineage가 현재 raw evidence와 정반대로 적힌 Record가 여러 편 있다.
3. raw evidence가 65개 생겼지만 Record와 SSOT 일부는 아직 증거가 없다고 적고 evidence가 claim에 연결되지 않았다.
4. Setup의 pinned version 표기와 mutable installer/image가 충돌한다.
5. SSOT+Record 685 shell block의 current project command audit이 없다.
6. 현재 TechViz 문법으로 S4를 다시 판단해야 할 Concept이 최소 네 편 있다.

## 1. DNS-01 current truth

`final/evidence/raw/lab-state-before-rebuild/58-authenticator-and-token.txt`는 `authenticator = dns-cloudflare`를 실제로 기록한다. SSOT도 DNS-01 관측 완료라고 적는다.

하지만 `setup-wildcard-certificate-with-dns-01-and-a-deploy-hook.md` 앞부분은 아직 unknown이고 끝부분은 observed DNS-01이다. `question-is-this-lab-issuing-certificates-with-http-01-or-dns-01.md`도 `questionStatus: OPEN`이다. teardown Setup과 no-public-tunnel Decision도 같은 열린 Question을 정책 근거로 사용한다.

Question을 현재 canonical 종료 상태로 닫고, stale unknown/relation을 현재 사실에 맞춘다. historical run은 수정하지 않는다.

## 2. certificate lineage 정반대 설명

`60-doc04-step5-path-defect.txt`의 현재 관측은 `live/auth.hyeonworks.com/`이 실제 lineage이고 `live/hyeonworks.com/`으로 `nginx -t`를 하면 실패한다.

그런데 다음은 반대로 적는다.
- `reference-verify-a-build-guide-in-execution-order.md`
- `decision-dns-01-because-the-lab-is-not-on-the-public-internet.md`
- `case-renewal-succeeded-while-the-old-certificate-kept-serving.md`
- `question-is-this-lab-issuing-certificates-with-http-01-or-dns-01.md`

또 TLS Setup main path가 먼저 known-wrong `live/hyeonworks.com/`을 실행하게 하고 뒤에서 정정한다. canonical Setup main path에는 현재 정답만 두고 historical wrong command는 Case/Reference 또는 reference-mode block으로 분리한다.

## 3. evidence reconciliation

현재 evidence는 raw 67 files / non-README 65다. SSOT 머리표는 아직 raw 43이라고 적는다.

중요한 후속 raw:
- `14-cloudinit-schema-check.txt`
- `15-k3s-precheck.txt`
- `21-k3s-token.txt`
- `22-k3s-agent-install.txt`
- `58-authenticator-and-token.txt`
- `60-doc04-step5-path-defect.txt`

raw 65개 중 Record에서 exact filename으로 연결된 것은 0개이며 layout도 65개를 unreferenced로 센다. 동일 사건 재현 / 동일 원인의 follow-up / 단순 snapshot으로 분류해 claim에 연결한다. 삭제부터 하지 않는다.

## 4. Setup version contract

`setup-install-k3s-server-and-agent.md`는 k3s `v1.36.4+k3s1`을 pinned라고 적지만 실제 설치는 `https://get.k3s.io` stable을 사용한다. 2026-09-17에는 우연히 그 버전이 stable이었을 뿐 재실행 계약은 아니다.

`setup-create-three-guests-with-cloud-init.md`도 cloud-init 22.4.2를 고정한 것처럼 보이지만 Debian image URL은 `bookworm/latest`다. Arch host package도 `pacman -S --needed`라 설치 버전이 고정되지 않는다.

정확 재현을 원하면 실제 installer/image까지 pin하고, 아니라면 `pinnedVersions`를 observed/tested 의미로 분리한다.

## 5. command pedagogy

Record: 22 command-bearing docs / 289 shell blocks / 25 findings / major 2. SSOT: 396 shell blocks / 40 findings / major 1. 전체 shell block은 685다.

대표 major는 `cloud-init schema ...; rm -f ...`처럼 검증과 삭제를 묶은 historical command다. Setup에서는 이미 안전한 split flow가 있으므로 historical block을 삭제하지 말고 reference disposition을 명시한다. Case에서도 historical/reference 성격을 분명히 한다.

SETUP 9편 250 block은 tutorial/operator 관점으로 별도 검토한다. historical schema 1/2 run을 소급 수정하지 말고 project-level current command audit을 만든다.

## 6. S4

기존 10장은 그대로 유지한다. 새로 재판정할 우선 후보:
- `concept-two-l7-hops-and-the-entry-point-recursion.md`
- `concept-inside-a-qcow2-file-the-mapping-table-and-its-clusters.md`
- `concept-memory-pressure-reclaim-swap-oom.md`
- `concept-qemu-block-backend-forms.md`

특히 memory-pressure Concept의 그림 생략 이유인 도구가 sequence 하나만 지원한다는 설명은 현재 하네스 기준으로 stale이다. 현재 visualizer는 component-flow, two-zone-pipeline 등도 지원한다.

## 7. provenance

Tree는 `9465582...`가 exact snapshot commit이 아니라 반입 당시 HEAD라고 명시한다. 반입 14개 중 commit과 같은 것은 3개뿐이고 11개가 다르며 exact snapshot commit은 찾지 못했다.

그런데 34개 Record가 `sourceRevision: 9465582...`만 적어 exact commit provenance처럼 보인다. import-head와 snapshot을 분리해 의미를 약화해야 한다.

`README.md`는 `source/`를 final에 반영하면 지우라고 하지만 현재 source는 exact commit이 없는 uncommitted working-tree 상태의 provenance snapshot 역할을 한다. 지금 삭제하지 말고 durable snapshot으로 둘지 정책부터 통일한다.

## 8. 수정 순서

1. DNS-01 / lineage current truth 통일
2. evidence 65개 분류와 stale 증거 문장 갱신
3. Setup 버전 계약 정리
4. 685 shell block current audit
5. 네 Concept S4 재판정
6. sourceRevision / source snapshot provenance 통일
7. 실제 수정분만 current remediation run
8. project gates → whole pipeline → unittest 순차 검증

> **virtualization = 아직 더 봐야댐**