docs: remeasure S5~S7 conflicts on the restored basis; lock "always label the base"

S5~S7 새 충돌을 PR #18(--merge) 착지 뒤 기준으로 재측정하고 세 base 를 병기했다.
같은 컷 ba5797b 가 base 에 따라 19(계획 03438b0) · 112(복원 전 3a59776) · 4(복원 후
8c1238b)로 갈린다 ⇒ 「충돌 수에 base 병기」를 §5 상시 규칙으로 채택.

- 새 충돌(복원 후): S5 +3 · S6 +0 · S7 +1. S5 는 「충돌 0 물량」이 아니다.
- 그 +3 은 upstream 이 아니라 우리가 앞 회차에 남긴 로컬 분기가 만든다
  (string.rs = 설계 판단 · test_timer.rs = S4 가 넣은 2000ms 여백 · Cargo.lock).
- 「예측은 하한」이 S7 에서 처음 깨졌다(+3 예측 ↔ ⓐ+2 · ⓒ+1) — Cargo.lock 이중 계상 ·
  class_format_error.rs 경로 오기 · throwable.rs 는 S3 가 수렴시켜 충돌이 사라졌다.
- 부수 발견: 「7회차」는 헤드에 닿지 않는다. ba5797b..upstream/main 12커밋 ·
  누적 11 · java_runtime→rustjava-runtime · test_data→test-data 개명이 우리 픽스처에 꽂힌다.

사료 보존: 7회차 표는 취소선 + 정정 표지, 2026-08-27 블록은 무접촉.
코드(.rs) 변경 0 · 문서 전용.

Author: jun0

REPORT.md

@@ -1,5 +1,34 @@
 # REPORT
 
+## [2026-09-03] S5~S7 「새 충돌」 재측정 + 「base 병기」를 §5 상시 규칙으로 채택 (rustjava-upstream-sync-remeasure-s5-s7-and-lock-restore-basis)
+- 무엇을: PR #18 이 `--merge` 로 착지해 `merge-base origin/main upstream/main` 이 **`3296139c`** 로
+  전진한 «뒤» 기준으로 S5~S7 을 다시 쟀고, ★**세 base 를 «병기»** 했다(계획 기준 `03438b0` · 복원 전
+  `3a59776` · 복원 후 `8c1238b`). 같은 컷 `ba5797b` 가 base 에 따라 ★**19 · 112 · 4**(28배 차)로 갈린다.
+  ⇒ 그래서 「**충돌 수를 적을 때 base 를 반드시 병기한다**」를 `docs/upstream-sync-approach.md` §5 의
+  **상시 규칙으로 채택**했다(문안 신설). ★**직전 반려의 근인이 정확히 이 병기 누락**이고, S2·S4 회신은
+  각자는 정확했는데 «한 표»로 모으는 순간 기준이 섞였다 — **개별 회신의 정확성으로는 막히지 않는다.**
+- 왜: §5 표의 S5~S7 「0·0·+3」은 **계보가 전진한다는 전제** 위의 수인데 그 전제가 S1~S4 내내 깨져 있었다.
+  이제 처음으로 참이 됐으므로 그 위에서 다시 재야 티켓 size/timeout 이 맞는다.
+  ★**재측정 결과 «새 충돌»(복원 후)**: **S5 +3** · **S6 +0** · **S7 +1**. S5 는 「충돌 0 물량」이 **아니다**.
+  ★★**그 +3 을 만든 것은 upstream 이 아니라 «우리가 앞 회차에 남긴 로컬 분기»다** —
+  `string.rs`(우리 +28/−8) · `test_timer.rs`(**S4 가 넣은 500→2000ms 여백**) · `Cargo.lock`(재생성).
+  ★**S7 은 diff 32만 줄대인데 새 충돌 1건**(`thread.rs`) ⇒ 「물량이 크면 충돌도 크다」는 성립하지 않는다.
+- 사용자 영향: ★**코드 변경 0 · 문서 전용**(런타임 동작 무변경). 얻는 것은 **남은 회차의 크기를 실제 수로**
+  잡는 것과, 다음 회차가 같은 «기준 혼합» 반려를 반복하지 않는 것이다.
+- 검증: `git merge-tree --write-tree --name-only <base> <cut>` 의 2번째 줄~첫 빈 줄. ★**이 파싱으로 §5 첫 표
+  `0·1·2·2·7·16·17·17·17·19` 가 그대로 재현된다**(= 방법 자체의 검증). ★**ⓑ↔ⓒ 차이가 «계보뿐»임을 통제**:
+  ⓒ 트리를 ⓑ 계보에 얹은 합성 커밋(`git commit-tree 4788ef2f -p 3a59776`)이 **45·61·112 로 동일**.
+- ★**「예측은 하한」은 «절대적이지 않다» — S7 에서 처음 깨졌다**(예측 +3 ↔ 실측 ⓐ+2 · ⓒ+1).
+  원인 3건 전부 실측: ⑴`Cargo.lock` **이중 계상**(S5 에서 이미 충돌) ⑵`class_format_error.rs` 는 표의 **경로가 틀렸고**
+  `3296139..ba5797b` upstream 변경 **0** ⑶`throwable.rs` 는 우리 쪽이 `3296139` 와 **바이트 동일**이라 +81/−29 가 깨끗이 적용
+  ⇒ ★**S3 의 설계 판단(upstream 오류 분류 채택)이 뒤 회차의 충돌을 «지웠다».**
+- ★**후속 (1) — S8 이 필요하다. 그리고 남은 회차 중 제일 크다.** 「7회차」는 더 이상 upstream 헤드에 닿지 않는다:
+  `ba5797b..upstream/main` **12커밋** · ⓒ 누적 충돌 ★**11**(S7 의 4 대비 +7). 성격이 다르다 —
+  `java_runtime/` → **`rustjava-runtime/`** · `test_data/` → **`test-data/`** **개명 스윕**이라
+  새 7건이 ★**우리 고유 산출물에 꽂힌다**(`charset.rs` · `UnsupportedCharset` 3픽스처 · `TimeApi` 2픽스처 · `test_string.rs`).
+  ★개명 충돌은 3-way 가 rename 을 놓치면 픽스처가 «삭제 대 수정»으로 **조용히 사라진다** ⇒ **별도 판정 회차**로 잡아라.
+- ★**후속 (2)** — S5 티켓의 성격을 「물량」 → **「설계 판단 1건 포함」**으로 바꿔 발권하라(`string.rs`).
+
 ## [2026-08-27] upstream 동기 근인 확정 — 게이트③ `--squash` 가 계보를 버린다 (rustjava-upstream-sync-squash-defeats-convergence)
 - 무엇을: S1~S4(PR #11·#13·#16·#17)가 **전건 `merged=true`** 인데도 `merge-base origin/main upstream/main`
   이 fork 시점 **`62cf0c6a`** 그대로이고 behind **33** 이 줄지 않던 근인을 확정했다. 근인은 게이트③

STATE.md

@@ -1,6 +1,18 @@
 # STATE
 
 ## 진행중
+- [rustjava-upstream-sync-remeasure-s5-s7-and-lock-restore-basis] ★**PR #18 착지 «뒤» 기준으로 S5~S7 재측정
+  + 「충돌 수에 base 병기」를 §5 상시 규칙으로 채택.** ★**코드 변경 0 · 문서 전용.**
+  세 base 병기: 같은 컷 `ba5797b` 가 **19**(계획 `03438b0`) · **112**(복원 전 `3a59776`) · **4**(복원 후 `8c1238b`) —
+  ★**28배 차이. base 없는 충돌 수는 검증 불가다.**
+  ★**새 충돌(복원 후)**: **S5 +3** · **S6 +0** · **S7 +1**. ★**S5 는 「충돌 0 물량」이 아니다** —
+  그 3건은 `Cargo.lock`(재생성) · `string.rs`(★**설계 판단**) · `test_timer.rs`(**S4 가 넣은 2000ms 여백**)이고
+  ★★**전부 upstream 이 아니라 «우리가 앞 회차에 남긴 로컬 분기»가 만든다.**
+  ★**「예측은 하한」이 S7 에서 처음 깨졌다**(예측 +3 ↔ ⓐ+2 · ⓒ+1) — `Cargo.lock` 이중 계상 ·
+  `class_format_error.rs` 경로 오기 · `throwable.rs` 는 우리 쪽이 `3296139` 와 **바이트 동일**(S3 가 수렴시켰다).
+  ★**부수 발견 — S8 이 필요하고 남은 것 중 제일 크다**: `ba5797b..upstream/main` **12커밋** · ⓒ 누적 **11**(+7) ·
+  `java_runtime/`→`rustjava-runtime/` · `test_data/`→`test-data/` **개명 스윕**이라 우리 픽스처에 꽂힌다.
+  **PR 대기 — 게이트③ 미착지.**
 - [rustjava-upstream-sync-squash-defeats-convergence] ★**S1~S4 가 착지하고도 fork 가 upstream 에
   한 걸음도 가까워지지 않은 근인을 확정하고 계보를 기록했다.** 근인 = 게이트③ 제품 repo **`--squash`**.
   증명은 **머지커밋 부모 수**다 — `6bfe97c4`·`11ef5010`·`4bb796de`·`3a597768` **전건 1개**(커밋 7·10·15·21이
@@ -70,9 +82,18 @@
 
 ## 다음
 
-### ①(최우선) upstream 동기화 — ★**S4 착지 대기(2026-08-27)**. 정본 = `docs/upstream-sync-approach.md`
+### ①(최우선) upstream 동기화 — ★**S1~S4 착지 완료 · 계보 복원 완료(2026-09-03)**. 정본 = `docs/upstream-sync-approach.md`
 
-★**S4(`3296139` · 물량 회차)까지 머지 완료 · PR 대기 중이다. 다음은 S5(`c4665b0` · Java 1.2 API 확장).**
+★★**[2026-09-03 갱신] 구판 「S4 착지 대기」는 낡았다** — PR #17(S4)·#18(계보 기록)이 **전건 머지**됐고
+★**#18 은 `--merge` 로 착지해** `merge-base origin/main upstream/main` = **`3296139c`** · behind **30** ·
+열린 PR **0**. ⇒ ★**「앞 회차가 착지하면 뒤 회차의 기준선이 바뀐다」가 이제 처음으로 참이다.**
+
+★**다음은 S5(`c4665b0` · Java 1.2 API 확장). 단 「충돌 0 물량」이 «아니다»** — 2026-09-03 재측정(base = 현 `main`
+`8c1238b` · `merge-base 3296139c`)으로 **새 충돌 3건**: `Cargo.lock`(재생성) ·
+`java_runtime/src/classes/java/lang/string.rs`(★**설계 판단** · upstream +285/−31 ↔ 우리 +28/−8) ·
+`java_runtime/tests/classes/java/util/test_timer.rs`(**S4 가 넣은 500→2000ms 여백을 다시 얹는 기계 작업**).
+**S6 새 충돌 0 · S7 새 충돌 1**(`thread.rs`). ★상세·근거·세 base 대조표 = `docs/upstream-sync-approach.md` §5 「[2026-09-03 재측정]」.
+★★**충돌 수를 적을 때는 base 를 반드시 병기하라 — §5 상시 규칙이다.**
 
 **S4 실측(2026-08-27)**: 착수 시 `merge-base origin/main upstream/main` = ★**`62cf0c6`**(최초 공통조상) ·
 `1f356ae`·`af4f6f8`·`822504b` 가 `origin/main` 의 조상 **전건 NO** — ★**스쿼시 3회가 족보를 원점으로 되돌렸다.**
@@ -101,9 +122,13 @@ green 전건 rc=0 · `cargo test --all` **261 passed / 0 failed / 1 ignored**(S3
 ★**대가**: 감도가 내려간다 — red 문턱 1회전 **~167ms → ~667ms**(약 4배 둔화). 「5.6배 저하」는 여전히 red,
 「2.4배 저하」는 이제 통과한다. 그 상한을 테스트 주석에 박았다.
 
-★**「예측은 하한」이 이제 3회 연속 실측됐다**: S3 +9 예측 ↔ 11 · S4 **0 예측 ↔ 2**.
+★~~**「예측은 하한」이 이제 3회 연속 실측됐다**~~ → ★★**[2026-09-03 정정] 하한은 «절대적이지 않다» — S7 에서 처음 깨졌다**
+(예측 `+3` ↔ 실측 계획기준 **+2** · 복원 후 **+1**). 초과는 «우리 로컬 분기»가 만들고(S5 `0↔+3`),
+미달은 «앞 회차가 수렴시켜서» 난다(S3 가 upstream 오류 분류를 채택해 `throwable.rs` 충돌이 사라졌다).
+⇒ ★**티켓 size/timeout 은 여전히 하한 쪽으로 잡되, 「하한이다」를 근거로 쓰지 마라.**
 ★**`thread.rs` 는 S1·S3·S4 «세 회차 연속» 충돌**한다 — upstream 이 `ThreadStartProxy::call` 을 반복 재작성하기 때문이다.
-⇒ **S5~S7 도 그 파일은 「또 충돌한다」를 기본값으로 잡아라.** 해소 전략은 불변이다:
+★★**[2026-09-03 정정] 「S5~S7 도 기본값으로 잡아라」는 «절반» 맞았다** — 실측상 **S5·S6 은 충돌하지 않고 S7 에서만** 다시 열린다.
+해소 전략은 불변이다:
 **upstream 본문을 뼈대로 취하고 `#[tracing::instrument]` 한 줄만 PR #4 의 수동 span 으로 치환**한다.
 
 ### ②`wie-ktf-hardening` 잔존분 — 2026-08-15 재판정으로 **4건 → 2건**
@@ -242,8 +267,10 @@ green 전건 rc=0 · `cargo test --all` **261 passed / 0 failed / 1 ignored**(S3
 | `feat/rustjava-upstream-sync-s3` | PR #16 의 head — 게이트③ 집행 중 | 머지와 함께 자동 삭제(`deleteBranchOnMerge`) |
 | `wie-ktf-hardening` | 보존 판정(2026-07-25) | 위 ②로 **잔존 가치가 2건까지 줄었다** — 브리프 ③-2 가 그 2건을 새 브랜치로 옮겨 심으면 ★**보존 근거가 소멸**한다 |
 
-⇒ ★**다음은 S4(`3296139`)** — 남은 upstream 커밋 **26**. 계획서 예측 **새 충돌 0**이나
-★**예측은 하한이다**(S3 가 +9 예측에 11 이었다).
+⇒ ~~★**다음은 S4(`3296139`)** — 남은 upstream 커밋 **26**~~ → ★★**[2026-09-03 갱신] 다음은 S5(`c4665b0`)** —
+남은 upstream 커밋 **30**(`ba5797b` 뒤로 **12** 가 더 붙었다 · 헤드 `bd42427`). 열린 PR **0** · 원격 브랜치 = `main` · `wie-ktf-hardening`.
+★**「7회차」로는 헤드에 닿지 않는다 — S8 발권이 필요하고, 그것이 남은 회차 중 제일 크다**
+(ⓒ 누적 충돌 **11** · `java_runtime/`→`rustjava-runtime/` · `test_data/`→`test-data/` **개명 스윕**이 우리 픽스처에 꽂힌다).
 
 - ★PR 발권 시 `--repo Jun025/RustJava` 명시(2026-07-22 upstream 오발행 사고 재발 방지).
 - ★upstream 발신(PR·이슈·코멘트·push)은 **티켓이 명시 허가할 때만**. 기본은 조회뿐.