docs(decisions)+rig: #708 이 되돌린 문서 4개·README·bootstrap 토큰 주석 복구 (#813)

docs/decisions/ai-receive-path-scaling.md

@@ -1,10 +1,13 @@
 # AI 수신 경로 — 「16코어 중 9.5만 쓰는」 마지막 후보를 어떻게 확인하고, 고칠 것인가
 
-작성일: 2026-08-17
-상태: 🟢 **잤다 — 從 R10-a 완료 (2026-08-23).** 「16 중 9.5」의 답은 **«한 프로세스라서»** 다
-([결과](../../loadtest/results/frame-path-r10a-2026-08-23/README.md)) — 프로세스를 둘로 쪼개니 CPU 9.5 → **14.5 vCPU**, 처리량 **1.30배**.
-🔴 **그 안에서 원인 셋이 아직 안 갈렸다** — GIL · 단일 이벤트 루프 · 프로세스 내부 락.
-프로세스 분리는 셋을 **한꺼번에** 우회한다. §10 이 그 자리다.
+작성일: 2026-08-17 · 갱신: 2026-09-02 (R10-b — handler_concurrency 도 반증)
+상태: 🟢 **잤다 — 從 R10-a·R10-b 완료.** 「16 중 9.5」의 답은 **«한 프로세스라서»** 다
+([R10-a 결과](../../loadtest/results/frame-path-r10a-2026-08-23/README.md)) — 프로세스를 둘로 쪼개니 CPU 9.5 → **14.5 vCPU**, 처리량 **1.30배**.
+🟢 **R10-b(2026-09-02)가 `GRPC_MAX_WORKERS`(핸들러 동시성, 기본 10)도 반증했다** — 5·20으로
+흔들어도 처리량·지연이 2% 안에서 그대로다([결과](../../loadtest/results/frame-path-r10b-2026-09-02/README.md)).
+🔴 **그래도 그 안에서 원인 셋이 아직 안 갈렸다** — GIL · 단일 이벤트 루프 · 프로세스 내부 락.
+프로세스 분리는 셋을 **한꺼번에** 우회하고, 핸들러 동시성 반증도 이 셋을 못 가른다(그 슬롯
+수가 문제가 아니라는 것만 확인). §10 이 그 자리다.
 대상: ~~후보 일곱을 지우고 하나 남은 것의 확인 방법~~ → **확인은 끝났다.** 남은 것은
 **원인 분리**와 **선택지**다
 연관: [`../../loadtest/results/ai-scaling-aws-2026-08-17/README.md`](../../loadtest/results/ai-scaling-aws-2026-08-17/README.md)(R6·프로파일·부하기 재확인) ·

docs/decisions/r10-loadgen-topology.md

@@ -1,9 +1,12 @@
 # R10 의 무대 — 부하기를 대상 박스에 둘 것인가
 
-작성일: 2026-08-23
-상태: 🟢 **결정 완료 (2026-08-23 사용자 confirm) — 쪼갠다. R10-a(1대 동거)를 먼저 돌린다.**
-R10-b(2대)는 `handler_concurrency` 를 기준 조건에서 재는 판으로 미룬다 — 착수는 R10-a 를
-보고 다시 정한다. 상세는 §7.
+작성일: 2026-08-23 · 갱신: 2026-09-02 (R10-b 회수 — §9)
+상태: ✅ **R10-a·R10-b 둘 다 완료.** R10-a(2026-08-23)가 GIL 스위치 간격을 반증하고
+「16 중 9.5」를 프로세스당 천장으로 답했다. R10-b(2026-09-02)는 남은 후보
+`handler_concurrency`(`GRPC_MAX_WORKERS`)도 반증했다 — 5·10·20 을 흔들어도 처리량·지연이
+2% 안에서 그대로다. 두 후보가 다 지워져서 **천장의 원인은 프로세스당(GIL 또는 이벤트루프)
+쪽으로 좁혀진 채 남는다** — «어느 쪽인지」는 여전히 미확정([`ai-receive-path-scaling.md`](ai-receive-path-scaling.md)
+자체의 캐비어트). 상세는 §7·§9.
 연관: [`ai-receive-path-scaling.md`](ai-receive-path-scaling.md) §10·§12 ·
 [`AWS-RIDE-ALONG.md`](../../loadtest/AWS-RIDE-ALONG.md) §1 從 R10 ·
 [rig](../../loadtest/results/frame-path-overhead-2026-08-23/README.md) §7-2 ·
@@ -204,6 +207,41 @@ R10-b 의 격자가 줄어든다.** 2대 배선을 만들기 전에 그 답이 
 
 ---
 
+## 9. ✅ R10-b 회수 (2026-09-02) — `handler_concurrency` 도 반증됐다
+
+원본: [`../../loadtest/results/frame-path-r10b-2026-09-02/`](../../loadtest/results/frame-path-r10b-2026-09-02/README.md)
+무대: 대상 `c7i.4xlarge` + 부하기(러너) `c7i.xlarge` · 160세션·90초·풀201 · 버림1+본판9(라틴방격)
+
+| | 결과 |
+|---|---|
+| `GRPC_MAX_WORKERS`(5·10·20)가 천장을 움직이나 | 🔴 **반증** — 팔간 차이 2% 안, R10-a의 자체 산포와 같은 급 |
+| §2의 「부하기 오염」 우려(0.5~1.4 vCPU) | ✅ **이번엔 원리적으로 안 걸린다** — 2대 진짜 분리라 부하기가 대상 CPU를 안 먹는다 |
+| 원격 CPU 계측 | 🔴 **전 판 실패**([#647](https://github.com/Shadowfit/init/issues/647)) — 처리량·지연 판정에는 영향 없음 |
+
+**최소 격자로 좁힌 것이 값을 했다.** 원래 §7 추천(ㄱ. 2대 완전 분리)의 배선을 그대로 쓰되,
+A/B(계측 on/off) 대조는 R10-a가 이미 닫아서 빼고 `GRPC_MAX_WORKERS` 하나만 흔들었다 — 판
+10개로 끝났다(§7 원 견적 대비 훨씬 쌈).
+
+**부수 소득 — 2대 배선 버그 셋을 실전에서 처음 걸렀다**(§8의 "2대 배선의 소요를 안 재봤다"가
+실제로 그 자리였다): `bootstrap.sh`의 `.env` heredoc 오염, SSH `nohup` 응답 미분리, `--bind`가
+원격 모드에서도 로컬 기본값을 안 바꾸던 것. 전부 로컬 문법 검증(컴파일·`--help`·단위테스트)
+으로는 못 잡는 종류였다 — **실제로 SSH 왕복을 태워봐야만 나오는 결함**이었다는 뜻이고, §8이
+"소요를 안 재봤다"로 남겨둔 리드타임 위험이 실제로 발생했다(리허설 재시도 1회, 코드 수정 후
+재개).
+
+**부수 사고** — 리허설도 `run_all.sh`를 그대로 태워 AUTO_SHUTDOWN 대상이 됐는데, 취소용
+root SSH가 러너(부하기)에는 안 열려 있었다(P4류 절차는 대상에만 열길 가정했었다). `stop`으로
+세이브·재기동해 회수는 했지만 부하기 가동시간 기록이 두 세그먼트로 쪼개졌다
+([#648](https://github.com/Shadowfit/init/issues/648)).
+
+### 남는 것
+
+「16 중 9.5」를 만드는 것이 GIL 인지 단일 이벤트 루프인지 내부 락인지는 **R10-a도 R10-b도
+안 갈랐다** — 둘 다 프로세스 분리가 셋을 한꺼번에 우회하기 때문이다(R10-a §6 자체 캐비어트).
+이 구분은 이번 라운드의 범위 밖으로 남긴다 — 필요해지면 별도 설계가 있어야 한다.
+
+---
+
 ## 결정 로그
 
 - 2026-08-23: 문서 초안 — 갈래 셋(ㄱ 2대 / ㄴ 1대 동거 / ㄷ 코어 격리) · 판정선 넷에

docs/decisions/replication-lag-and-semisync.md

@@ -1,14 +1,16 @@
 # 복제 — 「한 대가 죽어도 된다」를 지연과 대가로 바꾼다
 
-작성일: 2026-08-13 · 갱신: 2026-08-23 (2대 라운드 회수 — §0-3)
-상태: ✅ **2대 라운드 완료 (2026-08-22 측정 · 2026-08-23 회수).** Q1·Q2 에 값이 붙었다 —
-**반동기의 대가는 처리량 −5.9% · 커밋 p95 +13.0%** 이고, 부하가 단일 핫세션으로 몰리면
-**−10.3% 로 거의 두 배**가 된다(H3). 리플리카는 이 부하(초당 약 5만 행)에서 **분 단위로
-밀린다**(약 60초). Q4·Q5 는 로컬 라운드(2026-08-17)가 닫았고, **Q3 은 「이 계측으로는 못
+작성일: 2026-08-13 · 갱신: 2026-09-02 (cross-AZ 대조 라운드 회수 — §0-5)
+상태: ✅ **같은 AZ·다른 AZ 두 라운드 모두 완료.** Q1·Q2 에 값이 붙었다 —
+**같은 AZ(08-22)** 는 반동기의 대가 처리량 −5.9% · 커밋 p95 +13.0%, 단일 핫세션이면
+−10.3% 로 거의 두 배(H3). **다른 AZ(09-02, §0-5)** 는 같은 대가가 **처리량 −17.2% ·
+커밋 p50 +23.1%(약 3~4배)로 커진다** — 단 자릿수까지는 안 벌어졌다(§9-1 ②의 "자릿수
+단위" 예견은 반증됨). 리플리카는 이 부하(초당 약 5만 행)에서 **분 단위로 밀린다**(약 60초,
+AZ 무관). Q4·Q5 는 로컬 라운드(2026-08-17)가 닫았고, **Q3 은 「이 계측으로는 못
 잰다」로 닫힌 채**다 — 값이 아니라 한계가 답이었다.
-🔴 **인용 전에 §0-3 의 조건 넷을 볼 것** — 같은 AZ · 앱 경로가 아닌 SQL writer · 계측 바닥
-~1초 · `main` 이 아닌 커밋. 특히 **다른 AZ 는 안 쟀다.** §9-1 ② 가 그 선택을 「Q2 의 답을
-자릿수 단위로 바꾼다」고 적어뒀으므로 «반동기의 대가는 N» 을 조건 없이 인용하면 안 된다.
+🔴 **인용 전에 §0-3 의 조건을 볼 것** — 앱 경로가 아닌 SQL writer · 계측 바닥 ~1초 ·
+같은 AZ 조건은 이제 §0-5 로 좁혀졌으니 **"반동기의 대가는 N"을 인용할 땐 AZ 조건을 반드시
+같이 적을 것.**
 대상: DBA 축 결손 3개 중 **3번, 마지막**([[user_career_target]]). 백엔드 축에서는 「읽기를 어디로 보낼 것인가」의 전제가 된다.
 연관: [`./backup-restore-rto-rpo.md`](./backup-restore-rto-rpo.md), [`./online-ddl-vs-blocking-alter.md`](./online-ddl-vs-blocking-alter.md), [`./commit-count-and-mysql-metrics.md`](./commit-count-and-mysql-metrics.md), [`./report-read-path.md`](./report-read-path.md), [`../../loadtest/AWS-RIDE-ALONG.md`](../../loadtest/AWS-RIDE-ALONG.md) 主-P4
 
@@ -163,6 +165,127 @@ Q3 의 창 길이, Q5 의 지연 크기 모두 계측 오버헤드와 하트비
 
 ---
 
+## 0-4. 🆕 설계 — 다른 AZ 대조 라운드 (2026-09-01 설계 · 2026-09-02 판 설계 확정 · 실행 미착수)
+
+**목적**: §0-3 조건 1(「같은 AZ 에서만 성립한다」)을 좁힌다. §9-1 ②가 예견한 대로 반동기의
+대가가 다른 AZ 에서 **자릿수 단위로** 달라지는지 실측한다.
+
+**무대 — 새로 만들 것이 없다.** `repl2_rig.sh`/`repl2_probe.sh`/`repl2_sweep.sh`는 `REPL_AZ_MODE`를
+이미 **라벨로만** 받는다(§10-2-1 예시에 `"cross-az(2a→2c)"`가 이미 있었다) — AZ 배치는 rig 이
+정하는 게 아니라 **인스턴스를 어느 서브넷에 띄우는지**가 정한다. rig 코드 변경 없음.
+
+**인프라 확인 (읽기전용, 2026-09-01 aws cli 조회)**:
+
+| 확인 | 결과 |
+|---|---|
+| 서브넷 | 기본 VPC(`vpc-0cf624ff85806b815`)에 **4개 AZ(2a·2b·2c·2d) 전부 기본 서브넷이 이미 있다** — 새 서브넷/VPC 작업 불필요 |
+| 보안그룹 | `shadowfit-measure-sg`(`sg-0382132d2f8b5f6ce`)가 **자기 참조 규칙**(전체 포트, 소스=자기 자신)이라 AZ 와 무관하게 그대로 재사용된다 — 08-22 라운드가 쓴 SG 그대로 두 대에 물리면 된다 |
+
+**소스는 관례대로 `ap-northeast-2a`, 리플리카만 다른 AZ 서브넷에 띄운다.**
+
+### 결정 — 넷은 확정, 착수는 별도 (2026-09-02 사용자 confirm)
+
+- [x] **AZ 쌍** → 🟢 **소스 `2a` · 리플리카 `2c`**(08-22 라운드와 그대로 비교 가능한 쪽 채택)
+- [x] **판 설계** → 🟢 **옵션 C** — 버림 1 + 본판 4, `REPS=2`(`repl2_sweep.sh`의 `gen_arm_order`가
+      블록마다 팔 순서를 뒤집어 **`A B B A`**를 만든다 — REPS=3의 `A B B A A B`와 같은 규칙,
+      위치 합이 맞는 배열이다). 완전반복(옵션 B, `REPS=3`) 비용은 안 치른다 — 「자릿수 단위로
+      달라지는가」는 2판씩으로도 방향이 잡힌다는 판단. 🔴 **정정(09-02 코드 확인)**: 애초
+      적었던 「A A B B」는 틀린 표기였다 — 그 배열은 팔과 판 순서가 교락돼 이 라운드가
+      막으려는 문제([[feedback_measure_design_needs_repeats]])를 그대로 재현했을 것이다.
+      `REPS` 손잡이가 실제로 이미 위치균형 배열을 만들어주므로 그대로 쓴다
+- [x] **H3(핫세션) 대조** → 🟢 **이번 라운드는 다세션만.** 핫세션 교차는 범위 밖, 필요하면 후속
+- [x] **비용** → 🟢 **승인.** 2대(`c7i.2xlarge`) + 이번엔 **AZ 간 데이터 전송 요금**이 실제로
+      붙는다(08-22 는 같은 AZ 라 0 이었다). 옵션 C 기준 예상 가동시간은 08-22 라운드의 절반
+      남짓(러너 대략 0.7h) — **추정이지 실측 아니다**, 실행 후 `MANIFEST.txt` 에 실제값을 채운다
+- [x] **착수 여부(실행)** → 🟢 **실행됨 (2026-09-01~02).** 단 🔴 **이 확인은 사후 재구성이다**
+      — 실행이 이 설계 확인과 별도 경로로 일어났고(§0-5 머리말), 실행 당시 누가 "지금
+      띄우자"를 확정했는지의 대화 로그는 없다. 산출물(§0-5)로 「이 설계대로 돌았다」는
+      확인되지만, 「실행 confirm 이 실제로 있었는가」는 이 문서로는 답할 수 없다.
+
+### 실행 절차 (확정 — §10-2-1 과 동일 구조, AZ·판 설계만 다르다)
+
+```bash
+# 소스: 2a 기본 서브넷(subnet-0f22e466008d27262), 리플리카: 2c 기본 서브넷(subnet-0d7f507333c66b23d)
+# 둘 다 sg-0382132d2f8b5f6ce 물림 — 자기참조 SG 라 서브넷이 달라도 규칙 변경 불필요,
+# 실행 직전 두 인스턴스 SG 재확인만 할 것
+
+export REPLICA_HOST=<리플리카 사설 IP — 2c 서브넷>
+export REPLICA_SSH="ssh -i /root/.ssh/measure.pem -o StrictHostKeyChecking=no root@$REPLICA_HOST"
+export REPL_AZ_MODE="cross-az(2a→2c)"
+export REPS=2   # 옵션 C — 본판 4, gen_arm_order(2) = "A B B A" (repl2_sweep.sh 로 확인됨, 09-02)
+export HOT_ARMS=""   # 확정: 이번 라운드는 H3(핫세션) 제외 — 비우면 for 루프가 안 돈다(repl2_sweep.sh:187)
+
+PHASES="repl_preflight repl_gate repl ridealong collect" \
+  nohup bash loadtest/aws/run_all.sh > /root/run_all.log 2>&1 &
+```
+
+✅ **`REPS=2` 가 「A B B A」(위치균형 4판)를 만드는 것을 `repl2_sweep.sh:37-44`(`gen_arm_order`)
+로 확인했다** (2026-09-02) — 검증된 명령이다.
+
+---
+
+## 0-5. ✅ cross-AZ(2a→2c) 라운드 회수 (2026-09-01~02 측정) — §0-3 조건 1이 좁혀졌다
+
+원본: [`../../loadtest/results/replication-aws-cross-az-2026-09-02/`](../../loadtest/results/replication-aws-cross-az-2026-09-02/README.md)
+(`MANIFEST.txt` · `phases.tsv` · `repl/`)
+무대: **`c7i.2xlarge` 2대** · 소스 `ap-northeast-2a` · 리플리카 `ap-northeast-2c` ·
+`pose_data_scale` 1,000만 행 · 옵션 C(버림2 + 본판4, `REPS=2`) · **6판 전부 유효 · 결함 0**
+
+> ⚠️ **실행 경위가 불완전하다.** 이 라운드는 §0-4 설계·착수 확인을 마친 뒤, 이 저장소에
+> 세션이 둘 이상 동시에 붙는 알려진 조건([[project_concurrent_sessions]])에서 **사용자가
+> 이 대화에서 확인한 세션이 아닌 다른 경로로 실행됐다.** 재기동을 시도하던 세션이 S3 에서
+> 이미 완주된 결과(`ec2-20260901-184855`)를 발견해 회수했다 — 실행 당시의 의사결정 로그는
+> 없고, 있는 것은 산출물뿐이다. 상세: 결과 README 머리말.
+
+| | 결과 |
+|---|---|
+| **Q1** 몇 초 뒤처지는가 (다른 AZ) | ✅ **팔 A 약 60초 · 팔 B 약 52초** — 같은 AZ(60.5s·57.5s)와 **거의 같거나 더 작다.** 🔴 예상과 반대 방향 |
+| **Q2** 반동기가 무는 값 (다른 AZ) | ✅ **처리량 −17.2% · 커밋 p50 +23.1% · p95 +18.1%** — 같은 AZ 대비 **최대 약 3.8배** |
+| **§9-1 ② 의 "자릿수 단위" 예견** | 🔴 **반증됐다** — 자릿수(10배 이상)까지는 안 벌어졌다. "여전히 한 자릿수 %대이되 방향이 뚜렷한, 최대 3~4배" 가 실측값이다 |
+| H3(핫세션) | ⬜ **이 라운드는 범위 밖** — 다세션만 쟀다(설계 §0-4 결정) |
+
+### 조건 — 08-22 라운드와 같이 인용할 때 볼 것
+
+같은 AZ 라운드의 조건 넷(§0-3) 중 **1번(같은 AZ)만 이 라운드로 갈린다.** 나머지 셋
+(앱 경로 아닌 SQL writer · 계측 바닥 ~1초 · `main` 커밋)은 이 라운드도 그대로 적용된다.
+추가로: 🔴 **REPS=2(4판)라 08-22(REPS=3, 6판)보다 반복이 적다** — 산포 자체는 비슷한
+자릿수(A 0.27%·B 0.65%)로 나왔지만 표본이 더 적다는 점은 남는다.
+
+### 🔴 Q1 이 예상과 반대로 갈렸다 — 반동기 쪽이 오히려 덜 밀린다
+
+cross-AZ 에서 팔 B(반동기)의 지연이 같은 AZ 대비 **9.3% 더 작게** 나왔다. RTT 가 커지면
+지연도 커질 것이라는 순진한 예상과 반대다. 읽는 방식은 08-22 라운드 §2-1 과 같은 결이다 —
+**반동기가 지연을 줄이는 게 아니라, cross-AZ 에서 팔 B 의 처리량이 더 크게 깎이니
+(Q2) 리플리카가 따라잡을 절대량 자체가 줄어든다.** ⚠️ 이 인과는 08-22·09-02 두 라운드
+연속으로 관측만 됐고 **아직 한 번도 직접 검증되지 않았다** — 소스를 인위로 같은 만큼
+늦춘 비동기 대조판이 있어야 갈린다.
+
+### Q2 — 방향은 맞았고 크기는 예상보다 작았다
+
+§9-1 ②가 "자릿수 단위로 달라진다"고 예견했던 것은 **틀렸다.** 실측은 처리량 기준
+2.9배(−5.9%→−17.2%), 커밋 p50 기준 3.8배(+6.1%→+23.1%) — **방향은 예견대로(더 커진다)
+지만 크기는 자릿수가 아니라 배수 몇 개 선에서 멈췄다.** 왕복(RTT) p50 이 1.3배만 늘고
+p95·max 가 3.6배 늘어난 것(§1-1)과 겹쳐 보면, **커밋 p50 대가가 왕복 p50 상승을 거의
+그대로 반영**하고 **커밋 p99 대가(1.2배)는 왕복 꼬리(3.6배)만큼은 안 벌어진** 모양이다 —
+같은 AZ 라운드가 "대가가 평균보다 꼬리에 크다"고 적었던 것과 **반대 패턴**이다.
+⚠️ 이것도 관측된 패턴 기술이지 원인 검증이 아니다.
+
+### 새로 열린 것 (버그 2건)
+
+이 라운드를 발견하는 과정에서, 같은 실험을 모르고 재기동하려던 시도가 실패하며 rig 자체의
+결함 둘을 걸렀다:
+
+- **`run_all.sh` 의 `FINAL_OK` 판정 결함** — `repl_preflight` 가 FAIL 이어도 S3 업로드
+  자체는 성공하므로 `FINAL_OK=1` 이 되고, `AUTO_SHUTDOWN=1` 이 두 인스턴스를 곧바로
+  꺼버린다. 진단 로그가 볼륨과 함께 사라진다. [#641](https://github.com/Shadowfit/init/issues/641)
+- **P4 절차 문서 공백** — AL2023 AMI 는 기본 root SSH 가 막혀 있는데, `aws/README.md` 의
+  P4 절차는 `REPLICA_SSH` 가 root 로그인을 전제한다. 이 단계가 문서 어디에도 없다.
+  [#642](https://github.com/Shadowfit/init/issues/642)
+
+상세: [결과 README §4·§5](../../loadtest/results/replication-aws-cross-az-2026-09-02/README.md)
+
+---
+
 ## 0. 이 문서가 여는 것
 
 경력기술서 §6「비어 있는 것」의 마지막 칸이다.
@@ -698,6 +821,20 @@ Q1 은 통째로 인위 지연이다.
 
 ## 결정 로그
 
+- 2026-09-02: **§0-4 의 판단 넷을 사용자가 그대로 확정** — AZ 쌍(소스 2a·리플리카 2c) ·
+  판 설계(옵션 C, 버림 1 + 본판 4) · H3 미포함(다세션만) · 비용 승인. 실행 절차에 AZ 쌍을
+  구체 서브넷 ID 로 못박았다. 🔴 **`REPS` 가 옵션 C 의 배열을 실제로 만드는지는 아직 안 봤다**
+  — 실행 직전 `repl2_rig.sh` 로 재검증 필요, 문서엔 「의도」로만 남긴다. **착수(EC2 기동) 자체는
+  이번 confirm 의 범위 밖**이고 여전히 별도 확인이 필요하다.
+
+- 2026-09-01: **다른 AZ 대조 라운드 설계 착수** (사용자 결정 — 재고표 후보 중 P4 를 확정하고
+  설계를 요청). rig 은 이미 AZ 와 무관하게 완비돼 있음을 재확인했다 — `REPL_AZ_MODE` 는
+  라벨일 뿐이고 `cross-az(2a→2c)` 예시가 §10-2-1 에 이미 있었다. 인프라도 읽기전용 aws cli
+  조회로 확인 — 기본 VPC 에 4개 AZ 전부 서브넷이 있고 보안그룹이 자기참조 규칙이라 **새
+  프로비저닝이 필요 없다.** 남은 것은 판단 넷(AZ 쌍 · 판 설계 · H3 포함 여부 · 비용 승인)이고
+  §0-4 에 트레이드오프와 추천을 남겼다. **착수(실행)는 아직 안 함** — 설계 confirm 과 실행
+  confirm 을 분리한다([[feedback_user_decides_not_claude]]).
+
 - 2026-08-13: 설계 초안. 질문 5개(**Q3·Q4 가 급소**) · 팔 3개(C 는 양성 대조군) ·
   read-after-write 시나리오 · 가설 6개와 반증 조건. 무대는 DDL·백업 rig 부품 재사용이고,
   **리플리카 초기화는 08-13 백업 라운드에서 G5 로 검증된 XtraBackup 사본을 쓴다.**