plan_texts 의 resume·routine 분기와 press 프롬프트가 이미 구현돼 있고, scene card 방 이름은 159집 결손 0.budget_steps 가 314행 전부 null(SR@예산 규칙 불성립) · answers[].scoring=="result" 가 미지 값이라 pick 으로 떨어짐(place_on 이어야 함).answers[] 가 아예 없어 _plans_for_query 가 KeyError. visit_rooms(62엔트리)는 verb도 채점도 없음.온라인 컨트롤을 GT 계획이 아니라 VLM 읽기 답으로 돌린다는 방침(실험 2 조건) 아래, 4가족 중 아직 한 행도 못 돈 resume(type2)·routine(type3)을 착수한다. 핸드오프 문서는 “씬 재구성 3일 + 사용자 결정 3건”이라고만 적혀 있어, 무엇이 이미 되어 있고 무엇이 진짜 없는지를 파일 단위로 확인하지 않으면 계획을 세울 수 없었다.
t2a0_Apple_13, h1_Tomato_10 …)라, 하네스 씬에 없어 복원 게이트가 1/9 · 0/11 로 실패한다.두 갈래 탐색(온라인 파이프라인 전수 맵 / 읽기 결과 스키마)을 병렬로 돌리고, 그 위에 데이터셋 원본과 실행 중인 restore 본 런의 실측 행을 직접 대조했다. 견적을 문헌값이 아니라 지금 돌고 있는 잡의 실측에서 뽑은 것이 핵심이다.
| 항목 | 근거 |
|---|---|
plan_texts 에 resume·routine 분기가 이미 있다 | online_plan.py:110(resume: unfinished[]→r개 unit 줄), :131(routine) |
press 프롬프트가 resume press_button 용으로 이미 작성됨 | online_planner.py:263-266 (260915) |
| 방 이름 = scene card, 159집 결손 0 | resume 100집 + routine 59집 전수 확인 |
read_answer_key 가 resume 만 컷 프레임을 키에 넣음 | online_plan.py:60 |
resume 질의에 budget_steps·start_state: cut_NN.npz·pending[] | 실측 1771 / 7818 |
| 제출·샤딩·babysitter·COST_CAP 이 가족 파라미터화 | tmp/plan_main/submit_shard.sh |
budget_steps 가 314행 전부 null → dataset_step_budget 이 None 을 돌려주어 SR@예산 규칙이 성립하지 않고 턴 상한이 고정값(20/30)으로 폴백. ② answers[].scoring == "result" 는 answer_scoring 의 알려진 값이 아니라 pick 으로 떨어진다 — routine 성공은 surface_uid 위 place_on 이어야 한다.answers[] 자체가 없어 _plans_for_query(online.py:277)가 KeyError로 죽는다. pending[]→GT 답 어댑터를 새로 써야 하고, visit_rooms(62엔트리, resume_ok 칸의 19.5%)는 verb도 채점도 없다.--v1-families choices · V1_FAMILIES · build_online_system_prompt 의 ValueError · task_family = "find" if auto_release else "restore"(불리언 역추론이라 3번째 가족을 표현 못 함) · restore/else 2분기 · _gt_answer_loc · press 미배선.칸당 1답 $0.184 / 1300 s, 2답 $0.251 / 2107 s, 3답 $0.315 / 2678 s → 한계 단가 답 1개당 +$0.066 / +690 s.
| 가족 | 칸 | 편 | 질의 | 평균 답/단위 | API | GPU-시간 |
|---|---|---|---|---|---|---|
| routine (place_set=1, 누출 제외) | 863 | 100 | 261 | 1.94 | ≈$212 | ≈467 |
| ├ routine_direct | 696 | 1.00 | ≈$128 | ≈251 | ||
| └ routine_multi (3~11답) | 167 | 5.9 | ≈$84 | ≈216 | ||
resume resume_ok | 256 | 87 | 127 | 2.45 | ≈$72 | ≈164 |
resume tasks_ok | 497 | 93 | 142 | 2.57 | ≈$143 | ≈329 |
전략별 routine 칸: textlog 235 · tagmem-r3 188 · rf-v3 168 · frames 160 · vis-pure 89 · blind 23.
전략별 resume(resume_ok): textlog 127 · tagmem-r3 34 · vis-pure 32 · rf-v3 28 · frames 25 · blind 10.
① 핸드오프의 “3일”은 씬 재구성에만 해당한다. 그 위에 routine 은 플러밍 ~1.5일, resume 은 새 설계(GT 어댑터 + visit_rooms 채점 + press 배선 + data_rev 분리)로 +2∼3일이 더 붙는다.
② “routine 먼저”는 맞다 — 근거가 더 강해졌다. routine 은 상태 파일이 final.npz 하나라 컷 일반화가 아예 불필요하고, 답 형식·verb·채점이 restore 와 같다. 즉 routine = restore + 씬 재구성.
③ 그런데 비용은 routine 이 3배다(≈$212/467h vs ≈$72/164h). 비용 축은 routine_multi 167칸 하나가 지배한다(전체의 40%).
tmp/plan_main/src_w1·src_w2 는 심볼릭 링크가 아닌 동결 실사본이고 이미 라이브 src/ 와 다르다 → 라이브 src/ 편집은 실행 중 find·restore 잡(11잡)에 영향이 없다. 스냅샷 디렉토리만 불가침.| # | 항목 | 결정 |
|---|---|---|
| D1 | 범위·순서 | routine 먼저, resume 은 그 다음 |
| D2 | routine 스텝 예산 | restore 식 오라클 재계산 (데이터셋 null) |
| D3 | routine_multi | 포함하되 per-answer GC 로 판정 |
| D4 | 헤드라인 지표 | SR → per-answer GC + execute-state 전환, SR@예산은 병기 |
| 단계 | 내용 | 기간 | GPU | API |
|---|---|---|---|---|
| P0 | 셀 파일 863칸 · 예산 계산기 · 채점 분기 · GC 정의 · plan dry-run 게이트 | 0.5일 | 0 | $0 |
| P1 | 씬 편집 매니페스트 100 컨텍스트 (sbatch 배열, --qos=extra) | 1일 | 100잡 | $0 |
| P2 | src 통합 — scene_edit 훅 · 임의 state/frame · synth_meta · 가족 플러밍 | 1일 | 0 | $0 |
| P3 | 전수 검증 — 복원 게이트 + 안착 drift(≤1 cm) + freeze keep/freeze A/B | 0.5일 | 200잡 | $0 |
| P4 | 파일럿 10칸 (direct 7 + multi 3) | 0.5일 | ~4h | ≈$3 |
| P5 | 본 런 863칸 (8샤드, --qos=own, 일일 ≤$80) | 3~4일 | ≈467h | ≈$212 |
resume_ok(256) / remaining_ok(298) / tasks_ok(497)visit_rooms 온라인 성공 판정 — verb·채점 모두 신규 (resume_ok 칸의 19.5%)data_rev 분리 — 누름 34편 55행은 fd856246(컷 프레임 이동) 루트 분리 or 제외기술 결정 freeze 정책(keep vs freeze) 은 사용자에게 묻지 않고 P3 에서 측정으로 결정한다 — 스파이크가 미검증으로 남긴 항목이라 안착 drift 와 PickAndPlace 샘플러 가용성을 A/B 로 잰다.