cabinet closed임을 아는데도 A2 후 cabinet door step 완전 소멸(baseline/v3b_tree 대비 회귀). 사용자가 영상에서 본 버그 flagship에서 재발_try_build TARGET pre-check의 target_doors 면제 비일관 적용. A2는 잘못된 레이어 수정commit e226113 V3B가 80-scenario acceptance gate를 전 항목 PASS했다(kept 80/80, door step spot-check 3/3, baseline byte-불변). 이후 §9 Step1 = 858 full build into data/scene_mem_v2_oracle(job 5317, memer, CPU-only)를 실행했다.
orchestrator 모니터가 완주 시 SCENARIO ACCOUNTING 재카운트 + baseline byte-guard + before→after 정량화를 자동 수행했고, 심각한 회귀가 발견됐다.
diff_scene_mem_trees.py: AssertionError train: row count differs base=2604 oracle=1680 → before→after 비교 불가(scenario set 불일치).task_subtasks_oracle.json: FoodCleanup rds=[{fixture:"cabinet", before_step_idx:2, open}, {cabinet, after_all, closed}], SortingCleanup 동형. 둘 다 fixture:"cabinet" 요구.target_doors는 eval_spec TARGET test fixture만 커버 — non-target composite 세그먼트의 cabinet은 비커버.DoorStateMachine.transition raise → resolver RuntimeError → scenario-skip. §7 verbatim fallback으로 안 빠지고 raise가 핵심 결함.conditional_steps(260516 prose-conditional, env grounding 불요 → 항상 resolve) → 858/858 kept. Task 5a(commit 6ad0343)가 FoodCleanup의 conditional_steps를 rds로 교체 + SortingCleanup에 rds 신규 추가 → 이 교체가 회귀 트리거.e226113은 target-test 경로만 target_doors로 고쳤다. non-target composite rds 경로는 미커버 + raise.| 전략 | 설명 | 판단 |
|---|---|---|
| A (권장) | non-target ungroundable rds → §7 verbatim fallback. baseline parity + no-silent-wrong + §7 일치 | 사용자 채택 → A2로 구현 |
| B | 577/858 수용 | B1 무효 — 거부 |
| C | non-target cabinet grounding 시도 | eval_spec joint 부재 → A로 귀결 |
30 rds task 정밀 열거 → 13 ungroundable(cabinet×12 + drawer×1) vs 17 groundable(singleton). Ungroundable 중 baseline에 conditional_steps 있던 건 FoodCleanup + ReturnWashingSupplies 2개, 나머지 11개는 baseline에 door 처리 없음(그래도 858/858).
추가 발견: 7개 task(CandleCleanup/CerealAndBowl/MakeFruitBowl/OrganizeCleaningSupplies/RestockBowls/SortingCleanup/SpicyMarinade)는 oracle vs baseline subtask_templates도 다름 → rds 회귀와 무관, A2 범위 밖 → clobber 금지, 별도 관찰로 보고.
task_subtasks_oracle.json 변환: 13 ungroundable rds 제거, FoodCleanup/ReturnWashingSupplies baseline conditional_steps deepcopy 복원, 17 groundable rds 유지.
validate_task_subtasks.py: VALID 162 tasks, exit 0test_decomposition_regrounding: 15 passedtest_manual_subtasks_v2: 148 passed (conditional_steps 복원·rds 제거가 manual faithfulness 골든 무파괴)combo_005_L42_S17_0113 RestockBowls_obj1 — manifest target_doors=cabinet/closed (eval_spec joint byte-일치 hingecabinet_2_right_group_1), 세그먼트 instr "Open the cabinet… close the cabinet".
파이프라인은 instruction-baked door step을 strip(emit_door_annotations)하고 rds/door-machine이 grounded로 재emit하도록 설계되어 있다. A2가 13 task rds 제거 → RestockBowls/FoodCleanup이 TARGET이고 target_doors로 grounding 가능한데도 재emit 주체 소멸 → door step 증발 = defect-10.
즉 defect-9(281 skip)의 진짜 원인은 "rds가 나쁨"이 아니라 _try_build TARGET pre-check가 target_doors 면제(_target_covers_noun/line 1055 exemption)를 일관 적용 안 함 — 동반 cabinet-rds 세그먼트가 있는 multi-task scenario에서 RuntimeError-skip. RestockBowls-only 단순 scenario(combo_002/005)는 통과, FoodCleanup/SortingCleanup multi-task는 skip했다.
A2는 잘못된 레이어 수정 = 정상 작동하던 target grounding까지 파괴.
no-silent-wrong 원칙이 데이터 오염을 막았다: defect-9는 loud RuntimeError → clean skip으로 나타나 측정됐고, defect-10은 ground-truth spot-check가 즉시 잡아냈다. 858/858 + baseline byte-불변이 정확성을 보장하지 않는다 — row count 일치는 필요조건이지 충분조건이 아니다.
데이터(rds) 자체는 정확하다. e226113(V3B)의 target_doors grounding도 옳고 작동한다(RestockBowls combo_002/005 입증). 문제는 resolver 라우팅 로직이다.
올바른 fix = A2 revert + resolver/_try_build 수정:
_try_build TARGET pre-check: target_doors 면제(_target_covers_noun) 일관 적용 → target FoodCleanup/SortingCleanup도 RestockBowls처럼 grounding미커밋 working-tree: scripts/run_build_oracle_tree.sh(경로정정 유지), data/task_subtasks_oracle.json(A2 — revert 대상), 분석/context 로그. baseline/HF byte-불변 유지.
별도 후속 관찰(A2 밖, 사용자 결정 필요): 7개 task의 oracle subtask_templates ≠ baseline. defect-9 무관·미차단이나, B1 비교 유효성에 영향 가능(door-grounding 순효과 외 분해 차이 혼입). 올바른 fix 합격 후 B1 전 faithfulness 검토 여부 결정.
task_subtasks_oracle.json은 A2(revert 대상). data/scene_mem_v2_oracle은 job 5340(A2, defect-10 포함) 결과 → 학습 진행 절대 금지. 올바른 fix + 전 게이트 재통과 후에만 GPU 학습 허용.