Daily Progress

어제 한 일 — A. 실험 3 Oracle-plan 온라인 (설계 확정 → P1 스모크 → 본 런 제출 → 사고 3건)

• 설계 확정(사용자 결정 9건): 계획을 정답(GT)으로 고정하고 시드 메모리를 전 arm에서 제거 → 남는 변수 = 에이전트가 도는 동안 스스로 쌓은 실행 상태 기억. arm 5개(blind·frames-uniform·rf-v3·vis-pure·tagmem-r3; textlog은 시드를 빼면 blind와 프롬프트가 같아 제외) × 298질의(find v1.2 150 + restore v1.1 148, 하위유형당 k=30, seed 20260921) = 1,490칸(find 750 · restore 740). 주지표는 SR이 아니라 M1 held_repick_rate · M2 false_done · M3 wasted_turn_share · M4 gc — 실험 2 restore multi SR이 0/47이라 SR로는 신호가 안 나오기 때문. 독립 실험으로 확정(논문 별도 표, 실험 2 수치와 나란히 놓지 않음).
• 하네스: --plan gt · --seed none · --plan-slot instruction · frames-uniform 온라인 타임라인 표집. 기본값은 실험 2와 바이트 동일(회귀 테스트로 고정).
• P1 스모크(잡 144442, 6칸, 1h43m, $0.719 / $2 캡): v1.2 cross_multi가 온라인에서 돎(2답 칸이 done 도달) · 예산 이중계산 수정 라이브 확인(3답 예산 5,500 vs 버그 시 16,500) · 시드 제거 확인(전 칸 seed_lines=0) · M2 발화(2답 blind가 1/2만 든 채 6턴에 done). 단 pick 턴 82회 중 파지 성공 1회 → M1은 이 스모크로 검증되지 않았다(M1 근거는 실험 2 find 6,237턴 실측 0.171, 본 런 표본의 84%가 1답 칸).
• 본 런 전 수정: M4 gc 술어가 pick 답을 “도달만으로” 충족 처리(집기 못 하고 돌아다니기만 하는 팔이 유리) → 답별 술어로 수정(37bf6fd) · 샤드 COST_CAP 재산정(find 8→15, restore 14→24; 옛 값은 샤드당 견적 $11.1·$18.3 미만이라 완주 전 정지) · P5 게이트가 낡아 restore가 n_contexts 77 != spec 79로 죽던 것 수정. nav 조건은 옛 조건 유지 — 프로브 224시행은 자세오차 중앙값 23.7°→0.0°이나 짝지은 A/B 8칸은 파지 9/91(9.9%)→7/89(7.9%)로 이득 미실측(“없음”이 아니라 “이 표본으로는 안 보임”).
• 본 런 사고 3건(전부 API $0): ① GT 계획 문장이 uid 접두사로 만든 이름(stand_→“tv stand”)이라 씬에 없는 가구를 지시 — 1,490칸 중 170칸(11.4%) 접지 불가, 5 arm 전부 같은 칸에서 막히므로 메모리와 무관한 손실 ② ③ “원칙: 한 번에 하나만 바꾼다”로 뜬 부분 스냅샷(src_main3 = 5파일 추가)이 호출 시점 키워드 인자(restore_final_state(state=) · run_episode(track_rooms=))에서 연달아 사망 — 잡 26개·GPU 44분 + 1잡 3분. babysitter가 3분 주기로 재제출해 증폭.
• 대응: scripts/check_snapshot_consistency.py 신규(AST 호출부 ↔ inspect.signature 대조, 함수 지역 import까지 훑음 — 처음엔 전역만 봐서 사고 3을 놓쳤다) · 부분 스냅샷 포기, 워킹트리 전량 + nav0.py 핀(src_main4) · 게이트 4종(정합성 exit 0 · 패리티 384개 바이트 동일 · tests/exec 367 · preflight 양쪽 OK) · 1샤드 선행 확인 후 나머지 11잡 제출(145075 + 145193~145205). 사슬 길이 층화(b96193c)를 본 런 9행 시점에, D1 gt_instance_rate를 0행 시점에 사전 선언.
• 현재: find 88행/750, $5.52. 이름 치환은 25/88행에서 발동. raw 성공 35/88이나 arm별 셀·에피소드가 초기 샤드에 편중돼 해석하지 않는다(restore는 0행 — 1샤드 기동).

어제 한 일 — B. 두 트랙 가구 이름 정합 + R2 구제의 구멍 (코드 변경, API $0)

• 발견: 읽기 GT는 uid 접두사로 두 category를 한 이름으로 접는데(stand_=TVStand|SideTable→“tv stand”, shelf_=Shelf|ShelvingUnit→“shelf”) 온라인은 sim category로 접지한다. 본 런 표면 627바디 중 불일치 3종 — stand→SideTable 180칸 · shelf→ShelvingUnit 35칸 · refrigerator→Fridge(잠복 0). shelf도 같은 결함이었다는 것은 이번에 처음 드러났다.
• 수정: naming.COARSE_ALIASES(한 방향 — 정밀 이름 side table은 자기 category만) + GT 계획 문장을 씬 이름으로 치환. 오라클-플랜 1,490칸 기준 ungroundable 17+17→0·0(170칸→0) · misrouted 1+5→0·0(30칸→0) · ok find 117→126 / restore 84→97. 테스트 131개·프롬프트 패리티 통과(VLM이 받는 프롬프트 불변).
• 결정 C(사용자, 전 가족 균일): 답이 가리키는 가구가 여럿이면 하네스가 GT 인스턴스로 접지. 근거 — 답 계약이 (방, 가구 이름)까지라 “어느 의자인가”는 어떤 전략도 표현할 수 없음. 채점 술어 불변(routine A6 유지). 폴백(uid 오름차순 1등)은 GT를 find 7/20 · restore 6/29 면만 맞혔다.
• R2 구멍: 읽기 R2 구제의 side_pass가 원문에 “side table”이 있으면 답 값을 안 보고 통과 → dresser 기각을 우회. 구제 473행 중 130행(27%; dresser 84)이 “그 방에 진짜 있는 다른 가구”를 답함. 읽기 본표에서 oracle(textlog)만 −0.7~−2.6pp 부풀고 tagmem-r3은 −0.2~−0.5pp → 천장을 부풀리는 방향이라 “ours 대비 oracle 격차”를 인용하면 과장. 조임(제외 121행: dresser 82·desk 19·dining table 11): 전체 top 6 하락이 전부 textlog(Gemma4 −2.6 · sonnet −1.8 · Qwen3.8 −1.8pp), ours 최대 −0.5pp, blind ±0.0. 채택 여부 사용자 결정 대기(채택 시 “유리한 방향의 사후 규칙 변경”으로 보일 수 있음).
• 구제 행 온라인 편입은 사용자 결정으로 진행(계획은 GT 바디로 치환, 위양성 가드로 22칸 제외) — rescue_* 5유형 제출(현재 17행 기록, $1.94). 읽기 트랙→온라인 핸드오프 문서에는 이 외에 textlog 시드가 실패 조작의 최종 위치를 안 적는 문제(실패 67건 중 failed_dropped 16/16이 바닥, failed_no_place는 출발지 — 읽기 오라클 D1 오답 30행 중 29행이 실패 이벤트)와, Letsur 키 3개가 사실 같은 키였던 문제(수정)가 정리됐다.

어제 한 일 — C. routine(type3) 온라인 (P0~P4 구현 → 씬 재구성 전수 검증 → 파일럿 → 본 런)

• 견적 정정: restore 본 런 372행에서 턴을 다시 뽑아보니 턴당 $0.0068·55.6초가 답 개수와 무관(편차 2% 이내)하고 턴은 상한 60에서 포화 → 답 수로 선형 외삽한 이전 $212는 과대. 결정 A1(multi n≤4)·헤드라인 per-answer GC. 확정 셀 726 → 씬 재구성 게이트 통과 95편으로 재필터해 682칸(main 534 + tagmem 148) ≈ $117 / 264 GPU-h.
• 씬 재구성 전수 검증 100편(생성기 주입 바디를 하네스 씬에 재구성): 복원 match 1.0 · pose err 0.0 m (99/99) · 목적지 결손 0 · still 54 / settle 41 / fall 4(전부 칼) / build_failed 1 → 95편 채택. 초기 안착 게이트(10 mm)는 “놓은 직후” 과제 배우(13 mm 부근 군집)를 절반 가까이 떨어뜨리는 오보정이라 dz·dxy 분해로 재정의. 검증 중 결함 3건: 매니페스트 경로 규약 충돌(잡 4개 1초 사망) · 한 편의 빌드 실패가 샤드를 죽임(HouseInvalidForTask, 단독 프로세스에선 PASS인 프로세스 내 누적 상태 플레이크) · 모니터 오탐.
• 파일럿 결함 6건(누적 API $0.06): ① 주입물 메타를 init_scene 뒤에 주입(매니페스트 4샤드 중 3 즉사; 스파이크가 고른 편만 우연히 통과) ② multi 질의문이 읽기 트랙과 다름 ③ room_name_map이 type1 전용 slots 직접 접근 ④ textlog 빌더 type1 고정 ⑤ 보관소 모델 라벨 flash-3.7(시드 전량 소실) ⑥ 주입물 카테고리가 전부 injected — 씬 복원은 완벽(match 1.0)한데 프롬프트의 “Object names” 목록에 tomato가 없어 “no tomato within reach”가 6턴 반복. 죽지 않고 조용히 0점을 받는 형태라 682칸 전부 0점에 $117을 태울 뻔했다 → GT 물체가 인벤토리에 없으면 즉시 실패시키는 런타임 가드 추가.
• 조건 동일성: 공식 패리티 게이트 통과 — 공유 프롬프트 48개 바이트 동일, 수정 마커 4개 동일. 본 런 제출 후 현재 62/682행($14.07), 초기 raw 성공 15/62.

어제 한 일 — D. resume(type2) 온라인 배선 (마지막 남은 가족, API $0 · GPU 4분)

• 매니페스트 87/87(61871a3e 53 + fd856246 34). 컷이 씬 구조를 안 바꾼다는 것을 12편·125컷 파일의 model_body_mass|pos|check_names 대조(불일치 0)로 증명 → 검증 빌드 127→87회(≈2.8 GPU-h 절감). 임의 컷 복원(restore_final_state(state=)) · GT 어댑터(pending[] → 개수 GT) · visit_rooms 방 폴리곤·턴 누적 채점(셀 44질의, 방 이름 미유도 0) · press_horizon=300. 프리플라이트 159+97 = 256칸 전부 통과, 스모크(train_308__2000) PASS(match 1.000, drift 0.0 m).
• $0 게이트로 결함 3건 적발(전부 조용히 다른 조건으로 돌았을 것): ① 메모리 미래 누출 — ingest가 편당 1개(마지막 컷까지)인데 컷으로 안 잘라 cut_05 칸이 cut_06까지의 기억을 수령(점수를 올리는 방향). load_ingest가 chunk_ends·history를 버려 rf-v3 memory가 빈 문자열이기도 했음. 수정 후 컷별 시드가 실제로 갈림(rf-v3 454→612자, tagmem 엔트리 12→26) ② 놓기 과제가 없는 질의 38/127(30%)가 all({})==True → 아무것도 안 해도 성공 → resume 성공을 gc == 1.0으로 재정의 ③ 읽기 행 조회 키에 컷 프레임 누락.
• 채점 단위 판단 변경: place_count를 n(끝 상태)이 아니라 r(증분)로 — 누름·방문은 사건이라 끝 상태 흔적이 없어 한 분모에 못 넣고, n은 컷 전에 이미 놓인 물체를 공짜 점수로 준다. 증분은 시작 시점 실측(placed_start)을 빼서 구함(GT 미참조). 프롬프트 패리티 통과(48개 바이트 동일).

어제 한 일 — E. 메모리 계약 패리티 게이트 + restore tagmem 재측정

• 게이트 신설 scripts/check_online_prompt_parity.py: 온라인 런은 동결 스냅샷에서 돌아 세션 간 계약 드리프트가 안 보인다. 판정을 파일 diff가 아니라 모델이 받는 바이트로 — src_w2↔src는 15파일이 달랐지만 프롬프트 48개 전부 바이트 동일. 역방향 검증(노트 규칙 한 단어 uncertain:→maybe:)에서 rf-v3·tagmem 16개만 정확히 적발(exit 1).
• 온라인 갱신 실측(v1.2 진행 런 10:40 UTC): rf-v3 노트 +2.82줄(11/11칸) · tagmem +7.11줄(125/125) + 프레임 2.13(98% 칸) · vis-pure 프레임 0.91(81% 칸; 축출 문장 전 11%에서 뒤집힘). textlog은 온라인에서 줄이 한 번도 안 쌓임(0/21) — blind와 프롬프트 md5 동일(7a5678ecfd79), 260920 결정(A 보류)대로. 남은 문제: rf-v3는 계획 줄을 여전히 지움(생존 1/11, 지운 미완 항목 16 vs 체크 2 — 11칸이라 잠정).
• restore tagmem 구 런 2건 무효: 9/19 goal-off · 9/20 goal-on(각 107칸)이 tmp/tagmem_online/src_w1 하네스에서 돌았고, 그 트리는 memory_block이 notes에서 곧바로 return하던 260919 이전 코드라 Visual memory(KEEP/DROP) 블록이 통째로 없었다(출력 스키마엔 keep 필드가 있는데 설명이 0줄; KEEP 턴당 0.001 · 온라인 프레임 보유 2/107 vs 현행 vis-pure 0.306 / 96%). 시드도 장부 전량 덤프라 “검색하는 메모리”가 아니라 “전부 기억하는 메모리”를 재고 있었다 → 앞서 낸 LOO 행 tagmem Δ=+0.047 철회.
• 재측정 완료(tagmem_restore_off_s0~s3, 144105~144108, src_w2, own): 107/107행, raw 성공 29 (27.1%), API $30.07, 32.4 GPU-h. 구 런 goal-off 23/107(21.5%)은 무효라 직접 대조 대상이 아님. LOO 재계산과 restore 헤드라인 표 반영은 아직(문서 미기록). 프레임 엔트리 버전(KEEP 프레임을 type="image" 엔트리로 장부에 편입)은 헤드라인은 현행 설계 확정·추가 표로 나중에 A/B(≈$31).

어제 한 일 — F. Sol/Astra 자립 파일럿 · 지시문 쓰기 주입 A/B

• gpt-5.6-sol · gpt-6-astra restore 10편 자립(B) 파일럿(모델이 직접 쓰고 직접 읽음; 쓰기 v11 · 읽기 v8 · cap 8): Sol $20.64·3.7h, Astra $42.65·3.0h. 공통 64질의 place_set — Sol tagmem .078 = vis-pure .078(McNemar p=1.00), Astra tagmem .141 < vis-pure .188(p=.58), flash-3.7 tagmem .172 > vis-pure .156. “더 똑똑한 writer면 tagmem이 이긴다”는 이 표본에서 확인되지 않았다(1~3문제 차, 셋 다 결론 아님). Astra는 blind 기권 94% · oracle 기권 52% — 기권 0점 채점이 능력이 아니라 신중함을 재는 confound. 쓰기가 비용의 64~70%(초기 견적 $91/$248이 2배 이상 빗나간 원인). 100편 확장은 $633(Sol $206 + Astra $427, 3키 2~3일) — 결정 대기.
• 지시문 쓰기 주입 A/B(task_rst_q32 143679 · task_rst_gemma4 143680, restore 100편, SBENCH_WRITER_TASK=1, $0): 두 잡 모두 COMPLETED(3.3h·3.2h). 묻는 것 = 지시문을 쓰기에 주면 (a) D1 변별력이 사라지나 (b) 텍스트 채널 없는 vis-pure는 얼마나 손해인가 (c) D2는 불변인가. 결과 문서화는 확인하지 못함.

캠페인 현황 (tmp/exec_online/*.jsonl 실행 시점 집계 · 성공은 raw)

오늘 할 일 / 미해결

• own 8 GPU 배분 결정 — oracle 본 런 4 + rtmain_main 4 = 8/8이 점유해 oracle_restore 7샤드 · rtmain_tagmem · rescue_* · v12_delta4 등 own 대기 19건이 QOSMaxGRESPerUser. 실험 3은 GPU 369h라 슬롯 수에 선형(1슬롯 15일 / 8슬롯 2일). 우선순위를 정하지 않으면 restore 본 런은 find 샤드가 끝나 나는 슬롯에만 의존한다(현재 1/8샤드 기동).
• resume 전수 검증(4단계) 제출 → 파일럿 10칸 → 본 런 견적 재계산(공급 후보 최대 18개를 답 수로 오인하는 프리플라이트 모형 수정).
• restore tagmem 재측정 반영: LOO 재계산 → 헤드라인 표에 tagmem 행 추가, 구 런 2건 superseded/ 이동 + PROVENANCE에 무효 사유. 지시문 쓰기 주입 A/B(143679·143680) 결과 기록.
• 사용자 결정 대기: R2 원문 분기 조임(130행) · Sol/Astra 100편 $633 · 온라인 런 간 비교 가능성(하네스가 바뀌어 혼재) · tagmem 프레임 엔트리 A/B.
• 정리: 큐에 대응 잡이 없는데 살아 있는 babysitter 3개 — babysit_main_v2.sh restore 3260823(09-21 14:59 기동; restore 본 런 464/464 완료) · babysit_tagmem.sh restore 1325964(09-21 20:50; tagmem 재측정 107/107 완료) · babysit_run.sh tagmemled_restore_off_pilot 176301(09-22 02:24 기동; 대응 잡 4개는 전부 CANCELLED, 재제출 이력 없음). 의도된 대기인지 확인하고 아니면 종료. 라이브 src/ 테스트 실패: test_nav0_physics 2건(다른 세션의 미커밋 nav0.py 변경, git archive HEAD에서는 통과) · test_online_pure 3건(스냅샷은 통과).
• 문서 정합: 구제 행 수 “106칸”(표의 find 45 + restore 46 = 91과 불일치, 실제 투입 셀 85)을 analysis-naming_two_track_grounding.md/context.md에서 확인.