fix(b0): 주입 1~2 절을 실제로 밟고 ⑤ 의 점검이 언제 성립하는지 적는다

B-0 의 주입 1 절(파일 넷 편집)과 2 절의 이미지 빌드를 2026-09-17 에 밟았다.
두 노드에 이미지를 밀어 넣는 단계부터는 안 밟았고 그대로 unknown 으로 적었다.

- ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다. 그 줄은
  덜 지운 것을 잡으려는 것인데, keycloak-pattern 에 이 실험과 무관한 변경이
  39개(미추적 3개 더) 있으면 아무것도 못 가린다. 따로 떼어낸 작업 트리에서
  고치면 점검이 다시 살아난다 — git worktree 한 줄을 적었다
- 넷을 다 뺀 뒤 무엇이 남는지를 숫자로 확인해 적었다. pom.xml 은 XML 로
  유효하고, SecurityConfig 에는 bffSecurity 하나만 남고, application.yml 의
  spring 아래는 둘뿐이며, 매니페스트의 Redis Deployment·Service·PVC 는 남는다
- 빌드는 한 번에 통과했다. 이 편이 적어 둔 processDuplicateKeys 실패는
  재현되지 않았다 — Tests run: 4, Failures: 0 · exit=0
- 앞서 「남은 걸림돌은 인증서 하나」라고 적힌 것을 해결됨으로 고쳤다.
  인증서는 엣지로 옮기고 강제 갱신까지 끝났다

관문: check_body PASS · check_prose error 0 · check_evidence 문제 없음 ·
verify-tech-log-tree error 0 · verify-project-layout error 0 · 코드펜스 전수 0건

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/keycloak-session-store/final/document.md

@@ -13729,12 +13729,38 @@ code=200 size=155395
 설정이 바뀌면 다시 막힐 수 있다. 다만 `Bad Gateway` 를 「이 주소는 원래 밖에서 안 된다」로
 읽지는 않는다.
 
-**그리고 B-0 의 주입은 2026-09-17 에도 밟지 않았다.** 막은 것이 인증서가 아니라 소스다 —
+**B-0 의 주입은 2026-09-17 에 1 절(파일 넷 편집)과 2 절의 빌드까지 밟았다**
-주입 1 절이 `keycloak-pattern` 의 파일 넷을 고치라고 하는데 그 저장소에 이 작업과 무관한
+(observed). 두 노드에 이미지를 밀어 넣는 단계부터는 안 밟았다(unknown).
-커밋 안 된 변경이 여럿 있어 손대지 않았다. 지금 실험대의 BFF 는 B-0 이 아니라 B-1·B-2
+
-상태이고(빈 목록에 `RedisSessionRepository` 와 `JdbcOAuth2AuthorizedClientService` 가 다
+**★ ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다**(2026-09-17,
-있다), 그 상태에서 replica 2 로 로그인하면 **성공한다.** B-0 은 같은 조건에서 실패한다고
+observed). 그 줄은 「네 파일만 나오는가」로 덜 지운 것을 잡으려는 것인데,
-적으므로, 두 편을 가르는 것이 세션 저장소 하나임이 반대편에서 확인된다.
+`keycloak-pattern` 에 이 실험과 무관한 변경이 39개 있어(미추적 3개 더) 그 점검이
+무의미해졌다. 따로 떼어낸 작업 트리에서 고치면 그 점검이 다시 살아난다.
+
+```bash
+git worktree add --detach /tmp/kp-b0 HEAD
+```
+
+넷을 다 뺀 뒤에 무엇이 남는지도 숫자로 확인했다(observed). `pom.xml` 은 XML 로
+유효하고 starter 셋과 시험 의존 둘만 남는다. `SecurityConfig.java` 에는 `bffSecurity`
+하나만 남고 import 일곱이 같이 빠진다. `application.yml` 의 `spring` 아래는
+`application` 과 `security` 둘뿐이고 `server.servlet.session` 은 손대지 않는다 — 그것은 쿠키
+이름 설정이라 저장소 선택과 무관하다. 매니페스트에서는 env 여섯만 빠지고 Redis
+Deployment · Service · PVC 는 남는다.
+
+빌드는 한 번에 통과했고, 앞서 적은 `processDuplicateKeys` 실패는 다시 나오지
+않았다(observed).
+
+```text
+[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
+naming to docker.io/library/keycloak-pattern-bff:lab done
+exit=0
+```
+
+배포를 안 했으므로 지금 실험대의 BFF 는 여전히 B-1·B-2 상태이고(빈 목록에
+`RedisSessionRepository` 와 `JdbcOAuth2AuthorizedClientService` 가 다 있다), 그 상태에서
+replica 2 로 로그인하면 **성공한다.** B-0 은 같은 조건에서 실패한다고 적으므로,
+두 편을 가르는 것이 세션 저장소 하나임이 반대편에서 확인된다.
 
 그래서 파드 안에서 직접 받는다. **alpine 기반 JRE 이미지에는 `wget` 이 있다** —
 Keycloak 이미지와 다른 점이다.

docs/keycloak-session-store/tech-log-studio/tech-log-tree.json

@@ -7,7 +7,7 @@
     "revision": "9465582b5d1630eb4ae7c4e078021486919bf6b6",
     "verified": "반입할 때 적어 둔 source/.source-revision 이 이 커밋이고 저장소에 실재한다 — 「chore: 실행 환경 구성 문서 추가 및 수정」, 2026-09-10. **전에 이 칸은 cdac9b81 이었고 그것은 틀렸다** (2026-09-17 대조) — 그 커밋은 2026-09-04 이고 반입본 306개 가운데 docs/guides/** 28개가 거기에 아예 없다. 가이드는 그 엿새 뒤 6f6ab86 에서 들어왔다. **그런데 반입한 바이트는 이 커밋과도 같지 않다** — 9465582b 와 같은 것은 276개이고 29개가 다르다. 같은 306개를 저장소의 **작업 트리**와 견주면 297개가 같다. HEAD 에서 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 6f6ab86 도 28개가 어긋났다. **맞는 커밋은 없다** — 반입은 커밋이 아니라 **그 시점의 작업 트리**(미커밋 수정이 있던 상태)에서 떠 온 것이다. 지금도 저장소는 그 파일들을 M 으로 낸다. 작업 트리와 남은 차이 8개 가운데 5개가 그 M 목록에 있고(반입 뒤 저장소가 더 고쳤다), deploy/lab/host/nginx-keycloak-lab.conf 는 저장소에서 deploy/lab/edge/ 로 옮겨져 반입본에만 남았다. **이 커밋은 「반입 시점의 HEAD」라는 뜻이지 「반입한 바이트가 이것이다」가 아니다**"
   },
-  "ssotSha256": "fdb69c6e6e80bb74ee1e066523a799be7c8a0320f81f3d3799a12909762d6387",
+  "ssotSha256": "2ef1b420217e7a949917f13c6ffcb672516433b99d53dfd761f4f1f662653e55",
   "sourceRevision": "keycloak-session-lab@2026-09",
   "generatedAt": "2026-09-17",
   "candidateScope": {

docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b0-default-session-store.md

@@ -825,15 +825,38 @@ authorization-uri: ${KC_ISSUER_EXTERNAL}/protocol/openid-connect/auth
 authorization-uri: ${KC_ISSUER_EXTERNAL:http://localhost:8080/realms/keycloak-patterns}/protocol/openid-connect/auth
 ```
 
-## 이 실험대에서 아직 못 밟은 단계
+## 이 실험대에서 어디까지 밟았나
 
-2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈쮘는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+**주입 1 절(파일 넷 편집)과 2 절의 빌드까지 밟았다**(observed). 두 노드에 이미지를 밀어 넣는 데부터는 안 밟았다.
+
+**★ ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다**(2026-09-17, observed). 그 줄은 「네 파일만 나오는가」로 덜 지운 것을 잡으려는 것인데, `keycloak-pattern` 에 이 실험과 무관한 변경이 39개 있어(미추적 3개 더) 그 점검이 무의미해졌다. 따로 떼어낸 작업 트리에서 고치면 그 점검이 다시 살아난다.
+
+```bash label="[워크스테이션] 다른 작업이 섞여 있을 때"
+git worktree add --detach /tmp/kp-b0 HEAD
+```
+
+그 폴더에서 파일 넷을 고치고 빌드하면 원래 작업 트리는 한 글자도 안 바뀜다. 끝나면 `git worktree remove /tmp/kp-b0` 로 지운다.
+
+**넷을 다 뺀 뒤에 무엇이 남는지를 숫자로 확인했다**(observed). `pom.xml` 은 XML 로 유효하고 starter 셋(actuator · oauth2-client · web)과 시험 의존 둘만 남는다. `SecurityConfig.java` 에는 `bffSecurity` 하나만 남고 import 일곱이 같이 빠진다. `application.yml` 의 `spring` 아래는 `application` 과 `security` 둘뿐이고, `server.servlet.session` 은 손대지 않는다 — 그것은 쿠키 이름 설정이라 저장소 선택과 무관하다. 매니페스트에서는 env 여섯만 빠지고 Redis Deployment · Service · PVC 는 남는다.
+
+**빌드는 한 번에 통과했다**(observed). 이 편이 앞에 적어 둔 `processDuplicateKeys` 빌드 실패는 다시 나오지 않았다.
+
+```text label="docker build 의 끝"
+[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
+naming to docker.io/library/keycloak-pattern-bff:lab done
+exit=0
+```
+
+**안 밟은 것** — `k3s ctr images import` 로 두 노드에 넣는 단계부터다(unknown). 따라서 3 절 배포, 주입 검증, 관찰 3·4 절, 복구 절은 이번에도 원래 실행의 값이다.
+
+**그래서 지금 실험대의 BFF 는 여전히 B-1·B-2 상태다**(observed). 빈 목록에 `RedisSessionRepository` · `RedisHttpSessionConfiguration` · `JdbcOAuth2AuthorizedClientService` 가 다 있다. 이 상태에서 replica 2 로 로그인하면 **성공한다** — B-0 은 같은 조건에서 실패한다고 적는다. 두 편을 가르는 것이 세션 저장소 하나임을 반대편에서 확인한 셈이다.
+
+**밟은 관찰** — 관찰 1·2(파드 안에서 빈 목록 받기, 저장소 계열 빈 뽑기)와 5 절의 토큰 경계. `bff/token-boundary` 가 `accessTokenStoredOnServer=true` · `refreshTokenStoredOnServer=true` · `browserTokenCount=0` 을 내는 것은 이 상태에서도 같다(observed).
+
+**앞서 적어 둔 「남은 것은 인증서 하나」는 해결됐다**(2026-09-17, observed). 호스트에 있던 인증서를 엣지 게스트로 옮기고 강제 갱신까지 치면서 `https://auth.hyeonworks.com` 은 선다. 지금 남은 걸림돌은 소스 쪽 하나다.
 
-- **이 편의 주입은 2026-09-17 에도 밟지 않았다.** 막은 것이 인증서가 아니라 **소스**다 — 주입 1 절이 `keycloak-pattern` 의 파일 넷을 고치라고 하는데, 그 저장소에 이 작업과 무관한 커밋 안 된 변경이 이미 여러 개 있어 손대지 않았다. 이미지를 다시 만들지 않으면 3~5 절의 판정이 성립하지 않는다.
-- **그래서 지금 실험대의 BFF 는 B-0 이 아니라 B-1·B-2 상태다**(observed). 빈 목록에 `RedisSessionRepository` · `RedisHttpSessionConfiguration` · `JdbcOAuth2AuthorizedClientService` 가 다 있다. 이 상태에서 replica 2 로 로그인하면 **성공한다** — B-0 은 같은 조건에서 실패한다고 적는다. 두 편을 가르는 것이 세션 저장소 하나임을 반대편에서 확인한 셈이다.
-- **밟은 것** — 관찰 1·2(파드 안에서 빈 목록 받기, 저장소 계열 빈 뽑기)와 5 절의 토큰 경계. `bff/token-boundary` 가 `accessTokenStoredOnServer=true` · `refreshTokenStoredOnServer=true` · `browserTokenCount=0` 을 내는 것은 이 상태에서도 같다(observed).
-- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. **남은 것은 인증서 하나다**(2026-09-17 기준). 같이 적어 두었던 다른 둘은 그날 해결됐다 — 밖에서 닿는 길은 호스트의 libvirt `guest_input` 구멍과 유닛의 `ExecStartPost` 가 들어가면서 열렸고(`http` 가 밖에서 `200`), 클러스터 안에서 그 이름이 엣지를 안 가리키던 것은 기반 가이드 03 의 CoreDNS 한 단계로 놓았다. 인증서는 Cloudflare API 토큰이 필요한 DNS-01 로만 받을 수 있다 — 이름 셋이 tailnet 주소로 풀려 HTTP-01 은 성립하지 않는다.
-- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
 
 ## 무엇이 관측이고 무엇이 아닌가