policy_harness v7(scripts/policy_harness_v7)의 stool 코드 정책 개발 루프는 라운드마다 IK/자세 후보를 수정하며 dev seed(3101, 3102) 2개에 대해 반복 평가해왔다. 개발 예산(round 0–8)이 소진될 때까지 어느 라운드도 "dev 2/2 동시 성공" 기준을 만족하지 못했고, 프로토콜상 예산 소진 시 best round를 동결해 unseen heldout으로 최종 검증하도록 되어 있다. 이번 turn에서 그 heldout 평가가 실제로 완료됐다.
동결된 v7 stool 정책(policy SHA b71ed823…, round00 계열)을 evaluation_job_id 128492 등 개별 Slurm extra job으로 heldout seed 10개 각각 독립 평가. step 예산 5000, 성공 판정 기준은 dev와 동일(공식 전체 조립 3/3 + 최종 동시 pose 일치).
| Seed | 성공 | Assembled | 동시일치 |
|---|---|---|---|
| 9101 | ✗ | 2/3 | ✗ |
| 9102 | ✗ | 1/3 | ✗ |
| 9103 | ✗ | 1/3 | ✗ |
| 9104 | ✗ | 1/3 | ✗ |
| 9105 | ✗ | 1/3 | ✗ |
| 9106 | ✗ | 2/3 | ✗ |
| 9107 | ✗ | 1/3 | ✗ |
| 9108 | ✗ | 1/3 | ✗ |
| 9109 | ✗ | 1/3 | ✗ |
| 9110 | ✗ | 2/3 | ✗ |
10/10 실패, 3/10만 2legs 도달, 나머지 7/10은 1leg에서 정체. 어떤 seed도 3legs 동시 조립에 도달하지 못했다 — dev seed(3101, 3102)에서 관측했던 "2/3, 3/3" 수준의 진전과 뚜렷한 격차.
v6→v7으로 이어진 "코드를 반복 수정해 IK/자세 후보를 개선"하는 접근은 stool에서 dev seed 과적합 신호가 뚜렷하다. 정책 로직 자체의 정교화만으로는 3-leg 나사삽입을 안정적으로 풀지 못했고, 이는 stool 트랙을 이 상태로 더 밀어붙이기보다 근본 원인(OSC 목표 전달)을 먼저 검증해야 한다는 근거가 된다.
왜 dev seed에서만 2~3legs가 나왔는지 원인 미확인 — 좌표계/초기화 우연 일치인지, 나사삽입 단계의 근본적 정밀도 부족인지 구분 안 됨. heldout 결과는 이 정책을 더 튜닝하는 데 사용하지 않는다(프로토콜상 금지).
v8의 OSC 목표 전달 버그 수정(다음 카드)이 게이트를 통과하면, 같은 v7 round_02 정책을 목표 전달이 교정된 v8 브리지로 재평가해 이번 0/10 결과가 목표 전달 버그 때문이었는지 분리 검증할 예정.