[rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0-fix] test(fixtures): 표 키의 경로 구분자를 두 곳에서 정규화한다

윈도우에서 to_string_lossy() 가 indy\StringConcat.class 를 만드는데 표는 indy/… 를 담는다. 하위
36개가 「미기록」과 「유령 기록」에 동시에 걸리고 루트 114개는 통과하므로 mac/linux 로는 보이지 않는다.

같은 결함이 기록기에도 있었다. Rust 만 고치면 윈도우에서 기록한 표가 이번엔 mac/linux 를 red 로
만들고, CI 가 기록기를 안 돌려 그 축은 영영 조용하다. 그래서 둘을 함께 고쳤다.

개악이 mac 에서도 잡히도록 components() 대신 문자열 치환으로 구현했다 — 전자는 Unix 에서
역슬래시 입력을 그대로 통과시킨다.

형제 #55 가 먼저 착지해 순서 문제는 해소된 형태로 나타났다: base 를 당기니 픽스처 3개가 정확히
red 로 잡혔고 고친 기록기로 재기록하니 150 → 153, diff 가 정확히 3줄이다.

STATE.md 의 「#55 는 원장 3파일만 만진다」는 거짓이었고 그 오기 때문에 그 상호작용이 보이지
않았다 — 정정했다. 설계의 본래 대가(픽스처를 더하면 표도 함께)는 AGENTS.md 에 한 줄로 남겼다.

Author: jun0

AGENTS.md

@@ -138,6 +138,7 @@ done | /usr/bin/grep -c .
 - Keep `rustjava-runtime/tests/classes` limited to Java standard library class and API behavior.
 - Test JVM and interpreter semantics, including class initialization, bytecode execution, and monitor behavior, with compiled Java fixtures under `test-data/src` and expected output under `test-data`, executed by `tests/test_class.rs`.
 - Do not place JVM core behavior tests in the `rustjava-runtime` standard library test tree.
+- **Adding or recompiling a fixture means editing `test-data/class-file-versions.txt` in the same commit.** Every committed `.class` has its version frozen there, and a fixture that is not listed fails the pin — deliberately, since a pin that only covers what it already knows about stops covering anything added later. Run `python3 test-data/src/record-class-file-versions.py` and commit the row next to the fixture; a moved version means look at why before re-recording.
 
 ## Compatibility Sources
 - Implement Java compatibility from public specifications, Javadocs, and observable behavior tests. Do not consult or reproduce OpenJDK or other Java runtime implementation source code; keep the implementation independent to avoid licensing and provenance concerns.

REPORT.md

@@ -1,5 +1,25 @@
 # REPORT
-## [2026-09-17] `test-data` 전체의 클래스 파일 버전을 «동결»했다 — 통일이 아니라 (rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0)
+## [2026-09-17] 표 키의 경로 구분자를 «두 곳에서» 정규화한다 — 윈도우 CI red 를 고친다 (rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0-fix)
+- 무엇을: 표 키를 만드는 **두 곳**(Rust 테스트 · Python 기록기)을 **슬래시**로 맞췄다. ★**제품 코드 무접촉 · 설계 무변경.**
+- 왜: 게이트② **request-changes**(PR #57 · 핀 `3061edb7`) — ★**윈도우 CI 가 red 였다**(`ci-presence` → `CI_RED` rc=1).
+- 사용자 영향: 없다(시험 위생). ★바뀐 것은 **표 핀이 «모든 OS 에서» 같은 키를 쓴다**는 것이다.
+- ★★**결함의 모양**: `to_string_lossy()` 가 윈도우에서 `indy\StringConcat.class` 를 만드는데 표는 `indy/…` 를 담는다 ⇒
+  ★**하위 36개가 «미기록»과 «유령 기록» 양쪽에 «동시에» 걸린다.** ★**루트 114개는 통과**하므로 ★**mac/linux 로는 절대 안 보인다**
+  (모수 실측: **150 = 114 + 36**).
+- ★★**「두 곳」이 급소다** — ★**같은 결함이 기록기에도 있었고**, Rust 만 고치면 ★**윈도우에서 기록한 표가 이번엔 mac/linux 를 red** 로 만든다.
+  ★**그 축은 CI 가 기록기를 안 돌려서 «영영 조용하다»** ⇒ 둘을 함께 고쳤다(`as_posix()`).
+- ★**형제 상호작용(②)은 «코드»가 아니라 «순서»였고, 그 사이 `#55` 가 먼저 착지해 해소된 형태로 나타났다**:
+  base 를 당기니 그 3개가 **정확히 red 로 잡혔고**, 고친 기록기로 재기록하니 **150 → 153**(diff 정확히 3줄).
+  ⇒ ★**기계가 설계대로 잡고 처방이 한 명령이었다는 실증.**
+- ★**정정 하나 더(③)**: `STATE.md` 에 착지해 있던 「#55 는 원장 3파일만 만진다」가 **거짓**이었고,
+  ★**그 오기 때문에 ②가 보이지 않았다** ⇒ 그 자리에서 반증을 붙였다.
+- ★**이 설계의 «본래 대가»를 이제 «적어 뒀다»**: 「기록에 없는 픽스처 = red」는 의도된 엄격함이고,
+  그 비용(픽스처를 더하는 회차가 표를 함께 만진다)이 **어디에도 없었다** ⇒ **`AGENTS.md` §Testing Boundaries 에 한 줄**.
+- 검증: ⒞ 정규화를 되돌리면 ★**mac 에서도** 단위 시험이 진다(그래서 `components()` 대신 **문자열 치환**으로 구현했다 —
+  전자는 Unix 에서 역슬래시 입력을 그냥 통과시켜 ★개악이 안 잡힌다) · Python 축은 `PureWindowsPath` 로 **윈도우 없이** 실증 ·
+  `cargo test --all` **0 failed** · DoD 7명령 rc=0.
+
+## [2026-09-17] `test-data` 전체의 클래스 파일 버전을 «동결»했다 — 통일이 아니라 ★**[위 `-fix` 가 윈도우 경로 축을 정정]** (rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0)
 - 무엇을: 커밋된 픽스처 **150개**의 `<major>.<minor>` 를 표에 기록하고, ★**혼자 움직이면 red** 가 되게 했다.
 - 왜: 채택 제안 `2026-09-16-indy-fixture-jdk-pin-and-slot-accounting#p0`.
 - 사용자 영향: 없다(시험 위생). ★바뀐 것은 **「다른 JDK 로 재생성했는데 아무도 모르는」 경로가 닫힌 것**이다.
@@ -20,6 +40,46 @@
   `cargo test --all` **572 → 573 / 0 failed / 1 ignored** · DoD 7명령 rc=0.
 - 후속 추천: 루트 픽스처를 **하나의 타깃으로 재컴파일할지 «판정»**(L) — ★동결은 「움직였나」를 답하지 「우리가 원하는 값인가」를 답하지 않는다.
   상세 = `docs/worklog/2026-09-17-test-data-version-freeze.md`.
+## [2026-09-17] 신원 4축을 «각각» 관측 가능하게 했다 — 감사의 「고칠 것이 없다」를 정정한다 (rustjava-adopt-cp-tag-passthrough-detectable-p0-fix)
+- 무엇을: `string_concat.rs` 의 부트스트랩 신원 **4축**(kind·class·name·descriptor) 중 ★**3축이 «관측되지 않고» 있었다** —
+  근접 실패 픽스처가 **class 축 하나**뿐이었기 때문이다. 나머지 3축의 픽스처를 만들었다. ★**제품 코드 무접촉.**
+- 왜: 게이트② **request-changes**(PR #55 · 핀 `ab13a3c7`). 검수자가 **축을 하나씩** 지워 ★**kind·name·descriptor 개악이
+  «전 스위트 green 인 채로» 살아남는 것**을 찾았다(직전 감사 회차의 굵은 개악 M7 은 4축을 한꺼번에 지워 그것을 못 봤다).
+- 사용자 영향: 없다(테스트 픽스처). ★바뀐 것은 ★**「아무것이나 링크해도 테스트가 green」인 상태가 사라진 것**이다.
+- ★★**전/후**: kind·name·descriptor 축 단독 삭제 → **SURVIVED**(`--all` 570/0/1 green) ⇒ ★**KILLED**
+  (신규 `test_each_axis_of_the_factory_identity_is_observable`) · class 축은 **여전히 KILLED**(이제 2개를 죽인다 — 옛 커버리지 유지).
+- ★**픽스처는 «적법한 파일»이어야 값한다**: `NotMakeConcatWithConstants`(name · `makeConcat` 은 실재 부트스트랩) ·
+  `NotFactoryDescriptor`(descriptor · 여전히 적법한 서술자) · `NotInvokeStaticFactory`(kind **7** · JVMS 4.4.8 상 Methodref 와 적법).
+  ⇒ 넷 다 **신원 검사까지 도달**해 `UnsupportedOperationException` 로 거부된다(상류가 먼저 거부하면 «다른 이유»로 통과하는 것이다).
+- ★★**감사 방법론에 «역»을 남겼다**: 원 회신은 「죽지 않았다 ≠ 테스트가 약하다」를 적었는데 그 역이 빠져 있었다 ⇒
+  ★**「죽었다 ≠ 그 가지가 «전부» 덮였다」 — 다축 술어를 통째로 지우는 굵은 개악은 «어느 한 축이 덮였다»만 증명한다.**
+- ★**하네스가 실제로 트리를 오염시켰다**(러너 SIGKILL → `finally` 미실행) — ★계약 ⒡ 의 **「치환 1건 단언」이 그것을 잡았다**.
+  복원 후 4축 전부 재측했고, 이 사건이 「하네스를 커밋하지 않는다」 결정의 **실증**이다.
+- 검증: 회귀 표본 2종(BSM 경계 off-by-one · `Ldc2W` arm 제거) **여전히 KILLED** ·
+  `test_class_format` **11 → 12** · `cargo test --all --no-fail-fast` **570 → 571 / 0 failed** · 픽스처 재생성 **멱등** · DoD 7명령 rc=0.
+
+## [2026-09-16] `test_class_format.rs` 변이 저항 감사 — ★**«고칠 것이 없다»는 «한 자리에서» 거짓이었다**(위 `-fix` 가 정정) (rustjava-adopt-cp-tag-passthrough-detectable-p0)
+- 무엇을: 이 스위트의 단언 **11개**가 「자기가 이름 붙인 가지」의 개악에 **실제로 죽는지** 쟀다. ★**코드 변경 0**(감사 회차).
+- 왜: 채택 제안 `2026-09-16-cp-tag-passthrough-detectable#p0` — 「통과하지만 아무것도 재지 않는 단언이 더 있는지 보라」.
+- 사용자 영향: 없다(측정). 바뀐 것은 ★**「없다」를 «추측»에서 «실측»으로 옮긴 것**이다.
+- ★★**결과: 11/11 이 «적어도 하나»의 개악에 죽는다** — 개악 **10종**(매직 검사 해제 · 태그 pass-through 수용 ·
+  `ldc2_w` 폭 제한 제거 · 버전 하한 `true` · BSM 인덱스 `true` · indy 를 「파손」으로 · 신원 4축 제거 ·
+  ldc 미지원 arm 을 「파손」으로 · 파스 실패를 「미지원」으로 · not-found 를 「파손」으로). 표는 worklog 에.
+- ★★**중간 함정을 기록한다** — 1차 목록(M1~M7)에서는 **3개가 살아남았다.** 그때 「약한 단언 3건」이라 적었으면 **거짓**이다:
+  실제로는 ★**내 개악 목록에 그 가지들이 빠져 있었다**(ldc 미지원 arm · 파스 실패 매핑 · not-found 경로).
+  M8·M9·M10 을 더하자 **전부 죽었다**. ⇒ ★**「죽지 않았다」는 «테스트가 약하다»와 «내가 그 가지를 안 건드렸다»를 구별하지 못한다.**
+- ★★**ⓒ 제안의 전제는 쓰인 시점에 이미 거짓이었다**: 원문은 「several of which **also rely on corrupting a
+  referenced slot of `Hello.class`**」라고 했으나, 제안이 실린 커밋(`eb8b4eb` = PR #49)의 같은 파일에서
+  `Hello.class` 파생은 **3곳**뿐이고 ★**«참조 슬롯»을 덮는 것은 «0»** 이다(절단 · 매직 바이트 · 무손상 들러리).
+  ⇒ 「several」은 ★**그 회차가 «방금 고친 그 하나»의 일반화**였다. ★그렇다고 감사가 헛되지 않다 — 「없다」를
+  **재서** 아는 것과 **추측**하는 것은 다르다.
+- ★**도구를 «남기지 않았다»**: 개악 하네스는 제품 **소스 문자열**을 매칭하므로 리팩터 뒤 ★**조용히 개악을 건너뛴다** —
+  ★**하네스 자체가 「통과하지만 아무것도 재지 않는」 산출물**이 된다(이 제안이 사냥하는 그 형태). ⇒ **표를 문서로** 남겼다.
+  ※`scripts/survey-ldc-constant-tags.py` 를 남긴 판단과 다른 이유: 그쪽은 **클래스 파일(데이터)** 을 읽어 낡지 않는다.
+- 검증: 개악 10종 적용·복원 후 워킹트리 청결 · `cargo test --all` **570 / 0 failed / 1 ignored**(27 스위트 전건 합산) · DoD 7명령 rc=0.
+- ★**감사의 경계**: 답한 질문은 「각 테스트가 «자기 가지»의 개악에 죽는가」이지 「어떤 구멍도 없다」가 아니다 ·
+  **픽스처의 «유일 결함성»은 별도 축**(후속 추천) · 진행 중 PR #53·#54 의 새 테스트 2개는 범위 밖(각자 라운드에서 개악 대조 완료).
+- 후속 추천: **픽스처**의 유일 결함성을 같은 방식으로 감사(M) — 상세 = `docs/worklog/2026-09-16-class-format-mutation-audit.md`.
 ## [2026-09-16] 부트스트랩 메서드의 «정적 인자» 인덱스를 경계 검사한다 (rustjava-adopt-bound-bootstrap-method-attr-index-p1)
 - 무엇을: JVMS 4.7.23 의 `bootstrap_arguments` 는 상수 풀 인덱스인데 ★**아무도 그것이 실재하는지 보지 않았다.**
   이제 풀에 «없는» 인덱스를 가리키면 **거부**한다.