test(e2e): lifecycle #시나리오 2 를 Playwright 매칭 단위로 이관한다 (유예 34→33 · 매칭 파일 0→1)

[dlddu-k3s-homelab-k3s-mcp]

정합성 task rct_20260912-0005 (tbm_session-platform-scenario-e2e, 3라운드 — 재계획).

이 PR 은 반려된 슬라이스가 아니다

직전 라운드(PR #130, 시나리오 6 에 공유 볼륨 왕복 대체 검증)는 범위 를 이유로 반려됐고, 그 반려는
「(c)·(d) 의 선행인 AC-F5 아카이브 전략이 착지한 뒤에 저작하라, 그 전에는 다시 승인에 올리지 마라」는
게이트를 걸었다. 계획 시점에 그 게이트를 다시 쟀고 닫혀 있다:

• control-plane/internal/service/manager.go 가 approval-gated 에 대해 여전히 session.ErrCheckpointDisabled
  를 내고 internal/api/api.go 가 503 으로 매핑한다.
• 그 선행을 들고 있는 자매 PR feat(approval-gated): AC-F5 후반 — 공유 볼륨을 파일시스템 아카이브에 실어 동결·복원을 건너 나른다 #127 은 아직 OPEN(미착지). 소유 task 는 rct_20260912-0007 이고
  awaiting_review — 미점유 인수인계 지점이라 건드리지 않았다.

⇒ PR #130 과 그 브랜치는 한 글자도 건드리지 않았다. 반려가 적은 그대로 살려 두고, AC-F5 착지 후
같은 브랜치에서 케이스를 더하는 것이 그 슬라이스의 몫으로 남는다.

대신 유예 표가 스스로 지목하는 행을 집었다

유예 표 머리말이 읽는 법을 정한다 — 「해제 조건이 「지금 바로 할 수 있는 일」인 행부터 집는다」.
축 개정 #132 이후 유예 34 는 이관 27 + 미저작 7 이고, 이관 27 행은 전부 소관: 이 모델 · 선행 없음이다.

반려의 핵심 반대에 이 선택이 직접 답한다. 반려가 거부한 것은 「측정 gap(유예 34)이 한 칸도 줄지
않은 채 그 행만 정의상 『커버리지 구멍이 아님』이 되는 것」이었다. 이관은 정반대다 —
유예 34 → 33, 시나리오 매칭 파일 0 → 1. 눈금을 옮기지 않고 눈금 위에서 한 칸 간다.
축 개정 이후 이 레포에 매칭 파일이 0 이 아니게 되는 첫 순간이기도 하다.

무엇을 했나

lifecycle.md#시나리오 2(스냅샷 세션 접근 시 복원)를 Go 스위트에서 Playwright 매칭 단위로 이관했다.

신설	web/e2e/lifecycle-2-snapshot-restore.spec.ts (// 검증 시나리오: lifecycle.md#시나리오 2 1개)
제거	control-plane/test/e2e_b2_snapshot_restore_test.go (유예 행의 해제 조건이 요구하는 동시 제거 — 두 스위트가 같은 시나리오를 동시에 들고 있는 창을 남기지 않는다)
등재	docs/test/e2e.md — 매핑 표 +1행 · 유예 표 −1행 · 집계 유예 34→33·매칭 파일 0→1 · 분해 문단 이관 27→26 · 매칭 단위 밖 29파일→28파일 · Playwright 파일명 규약 한 문단
산문 수선	docs/criu-verification.md 2곳, docs/test/e2e.md 2곳 — 지운 파일명을 인용하던 곳 전부
원장	docs/comment-policy/ledger.md — 2026-09-07 행에서 그 경로 제거 + 줄수 441→438 + 지문 + 합계 마커 3054→3051

제품 코드·매니페스트·하네스·대역 0줄.

27 행 중 이 행을 고른 이유 (전부 실측)

1. 순수 control-plane HTTP API 4콜 — kube 클라이언트 참조 0. 이 시나리오의 핵심 단언인
   「복원은 새 pod 를 쓴다」가 wire DTO 의 pod 필드로 그대로 살아, 이관이 관측 층을 내리지 않는다.
2. 남은 미검증 분기 표가 이 파일을 소유하지 않는다(c2·c3·c4·state_api_5/6·f4·f6 등은 소유한다).
3. 열린 PR 넷 중 어느 것도 이 파일을 만지지 않는다.
4. 여정 spec 승격 재료가 얽혀 있지 않아 한 파일 신설 / 한 파일 제거로 끝난다 — 남은 26 행의 선례로 삼기 좋다.

대안 shell-workload.md#시나리오 5(d5)도 저울질했다. 산문 수선은 더 싸지만 4초 sleep + 백그라운드 셸 잡 +
음성 단언이라 플레이크 표면이 넓고, 첫 이관이 플레이크로 빨개지면 축 자체가 의심받는다.

단언 파리티 — 약화한 것이 없다

Go 원본	이관본
생성 세션에 pod 가 있다	expect(created.pod).not.toBe("")
snapshot 200 · state=snapshot	같음 (아래 참고)
switch 200 · state=active	같음
복원 pod 가 비어 있지 않다	expect(restored.pod).not.toBe("")
복원 pod ≠ 동결 전 pod	expect(restored.pod).not.toBe(created.pod)
뒤이은 GET 이 active + 같은 pod	같음

한 군데는 강해졌다. Go 원본은 snapshot 이 404 면 t.Skip 했다(제품 endpoint 이전의 SUT 를 가리킬 수
있어서다). 배포 SUT 는 그 endpoint 를 항상 갖고 deploy/ 오버레이가 CRIU 게이트를 켜므로, 이관하면서
그 분기를 단언으로 바꿨다 — skip 은 초록으로 보이지만 아무것도 사지 않는다.
타임아웃은 Go 하네스의 http.Client{Timeout: 90s} 와 같은 예산으로 맞췄다(생성·복원이 실 pod
프로비저닝에 블록된다).

실측

• 게이트 전수 rc=0 — check-scenario-mapping.sh(시나리오 37개 = 매칭 파일 1 + 예외 3 + 유예 33 + 공백 0) ·
  check_comment_policy.py(판정 완료 3051줄) · check-fidelity-allowlist.py · check-render-fidelity.py ·
  control-plane gofmt -l 무출력 / go vet ./... / go vet -tags=e2e ./... / go test ./... ·
  web tsc --noEmit.
• npx playwright test --list 이 새 spec 을 잡는다 — Total: 24 tests in 11 files(직전 23).
• 게이트 음성 대조군 3종을 직접 쟀다: ⑴ 새 spec 의 검증 시나리오: 선언을 지우면 규칙 2 로 rc=1
  ⑵ 유예 행을 되돌리면 규칙 4(등재와 선언 동시)로 rc=1 ⑶ 집계를 그대로 두면 규칙 6 으로
  '유예' = 34, 실제 = 33 · '시나리오 매칭 파일' = 0, 실제 = 1 로 rc=1. 셋 다 복원하면 rc=0 이고
  git diff 무출력 — 이 등재 이동은 장식이 아니라 기계가 집행하는 쌍이다.
• git grep e2e_b2_snapshot_restore 는 이제 이 변경 자신을 과거형으로 서술하는 두 곳에서만 걸린다.

⚠️ 경합면 — 이 PR 이 새로 만드는 충돌은 #130 하나

열린 PR 넷을 각각 main 단독과 main + 이 브랜치 로 두 번 시험 병합해 충돌 파일 집합을 비교했다.

PR	main 단독	main + 이 브랜치	이 PR 이 더한 것
#127	ledger.md · doc-tracker.md · e2e.md	같음	없음
#140	ledger.md	같음	없음
#106	8파일	같음	없음
#130	없음	docs/test/e2e.md	1

#130 은 이 PR 이 착지하면 리베이스가 필요하다. 둘 다 scenario-summary 블록과 유예 표를 만지기
때문이고, 이것은 사고가 아니라 예상된 결과다 — #130 이 본문에 적은 숫자(유예 34 · 매칭 파일 0)는
어차피 낡는다. #130 은 AC-F5 착지 전까지 승인에 올라가지 않으므로 그 리베이스는 그 슬라이스가 재개될 때
같이 한다.

검증 방법

1. e2e (kind + API + browser) 잡에서 Playwright 스위트가 새 spec 을 skip 이 아니라 pass 로 찍는지
   이름으로 확인한다 — accessing a snapshot session restores it into a new pod.
   skip 이면 머지하지 말 것: 이관이 단언을 옮긴 것이 아니라 잃은 것이 된다.
2. 같은 잡의 Go 스위트가 b2 제거만큼만 줄고 FAIL 0 인지 확인한다.
3. 시나리오 ↔ e2e 1:1 mapping 잡이 매칭 파일 1 + 예외 3 + 유예 33 + 공백 0 을 찍는지.
4. comment policy ledger 잡이 초록인지(합계 마커 3051).

범위 밖 (후속)

• 남은 이관 26 행과 미저작 7 행 — 각자 다음 슬라이스. 이관 26 은 전부 이 PR 과 같은 모양이다.
• 시나리오 6 전체 — PR test(e2e): approval-gated #시나리오 6 에 공유 볼륨 왕복 대체 검증을 세운다 (미저작 7→6) #130 에 파킹. 해제 조건 = AC-F5(feat(approval-gated): AC-F5 후반 — 공유 볼륨을 파일시스템 아카이브에 실어 동결·복원을 건너 나른다 #127) 착지.
• (a) 가 요구하는 대용량 본문 origin — test(e2e): 승인 후 아웃바운드 호출의 원본을 실물로 세워 차단 요인 FETCH-ORIGIN 을 닫는다 (차단 요인 1→0) #139 가 세운 deploy/fetch-origin.yaml 은 226 바이트 문서를
  내는데 spillBody 는 maxInlineBodyBytes(100,000)를 넘을 때만 볼륨에 파일을 떨군다. 즉 시나리오 6
  (a) 를 막는 것은 이제 origin 의 부재가 아니라 본문의 크기이고, 그것은 하네스 확장이다. 이 사실을
  여기 적어 다음 감지가 잇게 한다.