[rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0] test(fixtures): test-data 전체의 클래스 파일 버전을 「동결」한다 [rustjava-adopt-indy-fixture-jdk-pin-and-slot-accounting-p0-fix2]

[Jun025]

채택 제안 2026-09-16-indy-fixture-jdk-pin-and-slot-accounting#p0.
커밋된 픽스처 150개의 <major>.<minor> 를 표에 기록하고 ★혼자 움직이면 red 가 되게 했다.

★★제안의 «비용 산정»을 바꿨다 — 기각이 아니라 «설계 교체»

제안 tradeoff: 「pinning means first deciding the intended target … any fixture recompiled to match would change bytes …
★The decision is the work」 — 즉 통일을 전제한다.
그런데 제안이 산 것으로 적은 이득은 「a regenerated fixture cannot quietly start testing a different Java version's shapes」
= ★**«드리프트 탐지»**이지 «통일»이 아니다.

⇒ ★목표를 «동결»로 바꾸면 그 「work」가 통째로 사라진다: 지금 값을 기록하고 혼자 움직이면 red.
★재컴파일 0 · 바이트 변경 0 · 「어느 타깃이 옳은가」 결정 불요.

★대가를 숨기지 않는다: 이 축은 ★섞임을 «고치지» 않고 «굳힌다». 통일하려면 재컴파일해야 하고
★재컴파일은 바이트를 바꿔 그 픽스처가 «무엇을 시험하는지»를 바꾼다(제안 자신의 경고) ⇒ 별 축(후속 L)으로 넘겼다.

ⓐ·ⓑ 재측 — 그리고 «누가 이미 덮고 있나»

디렉터리	지금(재측)
루트	52×40 · 65×62 · 66×8 · 68×1 · 70×3
ldc / indy / cp / 기타	52×7·55×6 / 52×1·65×6 / 52×3 / 52×12·65×1

총 150. 제안의 수(65×61 등)는 그 사이 픽스처가 늘어 65 가 62 로 움직였다 — 형태는 그대로.
★이미 핀하는 축이 둘: test_fixture_pins.rs(indy 만) · 생성기 코드(자기 산출물 16개의 버전을 소스에 박는다).
⇒ ★남는 132개 = 「.java 소스가 있어 손수 재컴파일 가능한 것」이고, ★루트의 66·68·70 이 그 사고가 «이미 일어난» 지문이다.

★세 방향을 «전부» 검사한다 — 급소

방향	없으면
기록과 다름	드리프트를 못 잡는다(본래 목적)
★기록에 없는 픽스처	★핀이 «옵트인»이 되어 내일 추가분이 조용히 미보호
파일 없는 유령 기록	표가 썩어 「무엇이 보호되는지」를 못 믿는다

개악 3종 전건 red · 복원 green:
M1 Hello.class 버전 바이트 65→70(다른 JDK 재생성과 같은 형상) → Hello.class: recorded 65.0, found 70.0 ·
M2 미기록 .class 투입 · M3 유령 행. ★실패 문면이 파일·두 버전·해소 명령을 함께 말한다.

검증

기록기 멱등(재실행 시 표 바이트 동일) · cargo test --all --no-fail-fast 572 → 573 passed / 0 failed / 1 ignored
(27 스위트 전건 합산) · test_fixture_pins 소요 0.04s(파일당 8바이트만 읽는다) · DoD 7명령 rc=0.

★알고 남긴 값: 생성기 산출물 16개는 이중 잠금(생성기 + 표)이다 —
★예외 목록을 두는 규칙보다 «전건 단일 규칙»이 덜 썩는다.