방이 아니라 이름이었다 — 쓰기 v7 + 읽기 v8 전량: routine .319→.513 비오라클 1위

TL;DR

🔴 routine "방 오류" 8행 중 6행은 방이 아니라 수납처 이름 문제. 오라클 "knife를 bedroom의 side table에" ↔ DB 같은 시각 "placed the pencil on the white nightstand in the bedroom". 사건도 방도 기록됐는데 surf=side table 검색이 0히트 → 모델이 사전지식(거실)으로 답함.
전수 100편: GT 수납처 743건 중 side table 178/178 · laundry basket 141/141이 surf 태그 0회(43%). vocab_v1.json(type1 153편)에 없는 클래스라 routine 어댑터가 SURFACES_ROUTINE을 만들었지만 reader·채점에만 쓰이고 tagmem writer는 type1 어휘 17개만 받았다 — 하네스 결함. writer의 방 인식 자체는 84%(276/330).
resume 횟수: 발생 건당 "놓았다" 사건 entry는 55~69%뿐, 놓기의 21~35%는 도착지에 물체가 보이는 이미지만 있다(30초 4프레임 사이 행동은 상태 변화로만 보임). writer가 보는 이전 맥락은 최근 5 entry라 n=을 셀 근거가 없고 인스턴스 번호로 오용. press 45%는 매체 한계(전 비오라클 0/4).
쓰기 v7 구현(기본 off): type2/3 편 정식 수납처 어휘 + 별칭 정규화 · 결정론 회차 장부 · 발생당 1 entry + 상태차 추론 프롬프트 · 발화 entry 저장. find/restore(type1) 바이트 불변. 테스트 26 passed. 파일럿(§5·§6): 쓰기 v7 단독 routine .483 · resume 반증(.062) → 쓰기 v7 × 읽기 v7 조합 routine .333→.533(16/4 p=.012) · resume .094→.188. 둘은 같이 써야 효과.

6/8

routine 실패 = 이름 없음

43%

GT 수납처 태그 0회

84%

writer 방 정확도

55~69%

resume 사건 포착/발생

11/32

DB 횟수 == GT

분석 비용

1routine — 실패 8행 전수 대조

Q: Put the fork on the dining table away. 규칙(발화, DB에 검색됨): "Put the kitchen utensils from the dining table on the side table." GT: fork → bedroom / side table v7 답: living room / side table ✗ 오라클 [319–424s] I picked up the knife from the dining table in the bedroom and placed it on the side table in the bedroom. DB [390s] act=place room=bedroom surf=dresser | "Robot placed the pencil on the white nightstand in the bedroom" DB [630s] act=place room=bedroom surf=dresser | "Robot placed the spoon onto the white nightstand." → DB 78항목 중 "side table" 0회. 검색 surf=side table 0히트, 묶음도 못 가져옴. 모델: "the side table is located in the living room".

실패 행	GT (방/수납처)	답	DB에 GT 수납처 이름	DB가 부른 이름 / room
1161__7339 R2	bedroom / side table	living room	0	nightstand·dresser / bedroom ✓
1691__6765 R1	kitchen / side table	living room	0	dresser / living room ✗ · kitchen ✓
1691__6764 R2	kitchen / side table	living room	0	dresser / kitchen ✓
173__7305 R1	kitchen / laundry basket	living room	0	(basket 8건 floor) / bedroom·living room ✗
1748__6947 R2	kitchen / laundry basket	bathroom	0	laundry hamper / bathroom ✗
173__7304 R2	kitchen / laundry basket	bedroom	0	trash can / living room ✗
1205__8010 R2	living room / dining table	kitchen	10	dining table / kitchen 4 · living room 6
1815__8424 R1	living room / dining table	kitchen	12	dining table / kitchen 7 · living room 5

전수 100편: GT 수납처 이름이 DB에 있는가

GT 수납처	n	surf 태그에 없음	본문에도 없음
side table	178	178 (100%)	92
laundry basket	141	141 (100%)	96
coffee table	7	7	7
dining table / shelf	108 / 51	14 / 13	4 / 9
sofa / armchair / desk / countertop / tv stand	128 / 68 / 48 / 10 / 4	4 / 4 / 0 / 0 / 0	0

원인 = 하네스 어휘 결함. vocab_v1.json surfaces에 SideTable·LaundryHamper 클래스가 없다(type1 153편에서 생성). routine 어댑터가 SURFACES_ROUTINE(+side table, laundry basket)을 만들어 reader 프롬프트(prompt.py)와 채점(answer.canon_surface_routine)엔 썼지만, tagmem writer(ingest_tagmem)는 SURFACES 17개만 받았다. rf-v3·frames-uniform은 발화 원문을 그대로 들고 가므로 영향이 없고, 태그로 검색하는 tagmem만 맞는다.

writer의 방 인식은 괜찮다. 오라클 배치 355건 중 같은 시간창에 place entry 330건(93%), room 태그 정답 276/330 = 84%. 오류 53건은 living room→bedroom 23 · kitchen→living room 14 · bedroom→living room 8(오픈플랜·집 구조 특이). 이름만 맞으면 84%의 방 정보가 검색에 걸린다.

2resume — 횟수가 틀리는 두 층

GT done_units(프레임) 239건을 해당 30초 청크의 v5 DB와 대조(동의어 egg↔irish potato, mug↔cup 반영):

과제	발생	사건 entry 있음	상태 이미지만	아무것도 없음
put_in_container	108	75 (69%)	25 (23%)	8
move_objects	69	45 (65%)	24 (35%)	0
press_button	62	34 (55%)	—	28 (45%)

resume:train_2978__2000 egg(=irish potato) 청크 실물 — 사건은 "drop"으로, 상태는 캡션 개수로 남아 있다: [text drop] Robot dropped the second irish potato into the trash can [image look] Light wood dining table with two remaining irish potatoes 그러나 다른 청크는 [image look] "Living room view showing open hamper on floor, sofa, tv stand…" 뿐 → 놓기 사건 없음(상태만). 1843 세탁기: 3회 누름 → "Robot finishes interacting with the black washing machine" 1줄(n 없음).

층 1 (포착): 30초 청크에 균등 4프레임 — 프레임 사이 행동은 상태 변화로만 보이는데 v5 프롬프트는 "본 행동"만 적게 한다 → 놓기의 21~35%가 사건 없이 이미지만 남음. 캡션에 물체+개수가 있는 이미지는 4,023장 중 657장(16%).
층 2 (회차): writer가 보는 이전 맥락 = "최근 5 entry" → n=을 셀 근거가 없고 실측 n=은 인스턴스 번호로 오용(사과 3개 → n 합 14). 같은 청크에 여러 회가 한 줄로 뭉개진 것 12건(누름).
press 45%는 매체 한계(다른 누름 픽셀차 12.5 < 같은 누름 내부 19.8; 전 비오라클 0/4) — 쓰기로 못 고침. 사전등록에서 제외.
부수: 시뮬 egg 에셋을 "irish potato"로 부름(12/51편에 egg 0회) — 어휘가 아니라 지각 문제.

3쓰기 v7 — 구현 (기본 off, `SBENCH_TAGMEM_WRITE=v7` / `--tagmem-write v7`)

요소	내용	겨냥
어휘	`writer_system()`: type2/type3 편은 `SURFACES_ROUTINE`, type1은 `SURFACES`(find/restore 바이트 불변). 태그 정규화 `canon_surface_v7`: nightstand/end table/bedside → side table, hamper/basket → laundry basket (채점 쪽은 미변경)	routine 검색 0히트
회차 장부	`action_ledger()`: 저장된 text entry에서 (act, obj\|surf)별 회차·시각을 결정론 집계 → 매 청크 writer 입력. 규칙 "다음 반복은 n=장부+1"	resume n= 오용
프롬프트 v7	발생당 1 entry(요약 금지) · n=은 회차(인스턴스 번호 금지) · 상태차 추론(이전 노트보다 도착지 개수가 늘었으면 그 사이 놓기 사건을 물체당 1개 저장, 현재 개수 명시) · 캡션에 개수 · 수납처 명명 지침	resume 포착 21~35%
발화 저장	ingest 끝에 `augment_heard`(결정론, act=instruct; 읽기 v7 augment와 멱등)	routine self 규칙 채널

Action ledger (from your own notes so far — the next repeat of any of these gets n=count+1): ← v5 DB(1843, 컷 330s)로 만든 실물 - open washing machine ×1 (t=60) - press washing machine ×1 (t=90) - pick soapdispenser ×2 (t=90,120) - place soapdispenser ×1 (t=150)

테스트 tests/eval/test_tagmem.py +4(장부 결정론 · 별칭은 v7 정규화에서만 · 편 종류별 어휘와 v5 바이트 불변 · 발화 멱등) → 26 passed. 파일: src/sbench_eval/tagmem.py, prompts/tagmem_v7.txt, run_eval_v1.py(선택지).

4사전등록 — 파일럿(승인 대기, ≈$5)

flash-3.7 · 쓰기 v7(+uncapped) · 읽기는 현 final과 동일(resume v5, routine v6) · writer v2 · 읽기 v7 파일럿과 같은 20편 · own QOS gpu:0. 비용 resume 20편 $2.3 + routine 20편 $2.6. 전량(100편×2) ≈ $25. find/restore는 type1 바이트 불변이라 재측정 불필요.

지표 (같은 행 v5 대비)	v5	예측	반증선
routine side table·laundry basket surf 태그 존재율(편)	0%	≥70%
routine loc 전체 / self (60행)	.333 / .409	≥.47 / ≥.60	self <.50
routine place	.183	≥.35
resume 발생당 사건 포착	55~69%	≥80%
resume DB 항목 수 == GT 수행 횟수	11/32	≥20/32
resume_ok / remaining_ok (32행)	.094 / .094	≥.20 / ≥.25	resume_ok <.15
press_button	0/4	≤.10 (매체 한계)

열린 판단

채점 canon_surface_routine에 nightstand 별칭을 넣을지 — 전 전략 답에 영향(별도 결정).
resume writer에 지시문(heard)을 들은 시점에 주입할지 — ep.heard가 type3 전용이라 지금은 어떤 writer도 못 듣는다; 넣으려면 rf-v3·vis-pure도 같이 재ingest해야 공정.

원천: 로그 claude/260914/analysis-routine_room_resume_write.md · 데이터 tmp/tagmemv5_{routine_flash37,resume}_merged.json · 오라클 final_results/routine_v1.2_dc1c8144/models/gemini-3.7-flash/merged.json.

5파일럿 결과 — 같은 20편 재ingest (125493 resume · 125494 routine, $5.05)

읽기는 현 final과 동일(resume v5 · routine v6). 짝비교는 같은 행의 final v5 결과와.

가족	쓰기 지표 v5 → w7	읽기 v5 → w7	승/패	기권	사전등록
routine (60행)	side table 태그 0/7편 → 7/7 · laundry basket 0/7 → 7/7 · place room 정답 87% → 87% · 발화 entry 1.7/편	loc .333 → .483 · place .183 → .433 · self .409 → .545 · observed .250 → .500 · direct .500 → .675	13/4 p=.049	.28 → .08	전체 ≥.47 ✅ · place ≥.35 ✅ · 태그 ≥70% ✅ · self ≥.60 ❌(.545)
resume (32행)	발생 포착 put 72→68% · move 78→72% · press 60→50% · DB 항목 수==GT 15/32 → 15/32 · n= 최대==GT 10 → 16	resume_ok .094 → .062 · slot .125 → .188 · remaining_ok .094 → .156	0/1	.50 → .44	반증선(<.15) 도달 → 폐기

같은 60행 순위(loc): textlog .533 > frames .517 > rf-v3 .483 = tagmem w7 .483 > vis .350 > tagmem v5 .333.

routine: 어휘 수정이 그대로 먹혔다. 남은 self 실패 20/44 = multi 11(all-or-nothing, 전 전략 ≈0) + direct 9 = writer 방 오기 5(laundry basket→bathroom, side table→bedroom; writer 방 인식 13% 오류) + 정답 entry가 DB에 있는데 검색 안 됨 4(1691__6765 kitchen/side table 4건 등 — 읽기 v6은 수납처로 묶음 검색을 안 함; 읽기 v7 bundle이 정확히 이 경우를 가져온다).

resume: 프롬프트 규칙은 writer 행동을 못 바꿨다. 20편 writer 출력: text entry 445 → 374(오히려 감소), place 72 → 75, press 8 → 8. "발생당 1 entry·상태차 추론"은 260910 v6 파일럿과 같은 결론(프롬프트 단독 변경은 writer 잡음 이하). 결정론 장부는 작동(n= 회차 일치 10→16)했지만 항목이 없으니 횟수는 그대로. 남은 길은 writer 입력 구조(청크당 프레임 4→8, 직전 청크 마지막 프레임 동봉) — rf-v3·vis-pure에도 같이 적용해야 공정하므로 전 전략 재ingest 사안. press는 매체 한계.

결정 필요

routine 쓰기 v7 전량(100편 재ingest + 읽기 v6, ≈$13): 유의·사전등록 3/4. final_results routine tagmem .319 → 예상 ≈.45~.48(rf-v3 .442 동급).
routine 읽기 v7 bundle × 쓰기 v7 읽기 전용(60행 ≈$0.65): 사전등록 self ≥.60 · 전체 ≥.52.
resume 쓰기 v7 폐기(final v5 유지). 구조 변경은 별도 판단.

원천: tmp/tagmemw7_{routine,resume}_flash37_s?/results.json · 쓰기 지표 tmp/w7_write_diag.py(--v5 대조군) · 짝비교 tmp/pilot_w7_compare.py.

6조합 — 쓰기 v7 DB 위에 읽기 v7(묶음) (125850 routine · 125851 resume, $0.97)

사용자 "왜 쓰기 v7 위에 읽기 v7을 안 했어" → 읽기 전용 재실행. 사전등록: routine self ≥.60·전체 ≥.52, resume ≥.15.

routine 60행 (loc/place)	전체	self	observed	direct	multi	기권
w5+r6 (현 final)	.333/.183	.409/.205	.250/.250	.500	.000	.28
w5+r7 (읽기만)	.433/.383	.545/.477	.250/.250	.650	.000	.08
w7+r6 (쓰기만)	.483/.433	.545/.523	.500/.375	.675	.100	.08
w7+r7	.533/.483	.614/.591	.500/.375	.750	.100	.07
rf-v3	.483/.467	.591/.591	.375/.250	.725	.000	.07
frames-uniform	.517/.500	.636/.636	.250/.250	.750	.050	.10
vis-pure	.350/.250	.341/.250	.625/.500	.500	.050	.20
textlog (oracle)	.533/.533	.727/.727	.000	.800	.000	.15

routine: 사전등록 통과(self .614 ≥.60 · 전체 .533 ≥.52). v5 대비 +.200(16/4 p=.012; self +.205 p=.049, direct +.250 p=.031). 같은 행 짝비교 vs frames 6/5(동률, place 3/4) · vs rf-v3 5/2 · vs vis 17/6(p=.035) · vs 오라클 6/6. 기여 분해: 쓰기 단독 +.15, 읽기 단독 +.10, 합 +.20 — 읽기 v7이 겨냥한 '정답 entry 미검색' 행이 쓰기 v7 DB에서만 생기므로 둘 다 필요.

resume 32행	resume_ok	tasks_ok	remaining_ok	slot	기권	other(23)
w5+r5 (현 final)	.094	.312	.094	.125	.50	.130
w5+r7	.156	.500	.188	.281	.16	.174
w7+r5	.062	.312	.156	.188	.44	.087
w7+r7	.188	.500	.281	.359	.12	.261
rf-v3 / frames / vis-pure / textlog	.156 / .219 / .312 / .875		.219 / .250 / .312 / .875			.217 / .174 / .435 / .913

resume: 이득의 원천은 횟수. remaining_ok .094→.281 — 장부로 번호 붙은 항목(n= 일치 10→16)을 읽기 v7 묶음이 reader에 가져온다. v5 대비 4/1(p=.375), rf-v3·frames 급, vis-pure(.312) 아래, press 0/4 불변. 쓰기만(w7+r5)은 오히려 −.03: 항목이 늘지 않은 DB에서 v5 읽기는 여전히 헤더 기권.

전량 제안 (승인 대기) — 사전등록

routine 100편: 쓰기 v7 재ingest ≈$9.7 + 읽기 v7 314행 ≈$3.3 → ≈$13. 예측 loc ≥.45(현 .319, rf-v3 .442, frames .432) = 비오라클 최고 또는 동률, place ≥.40, 반증 <.40.
resume 100편: ≈$9.8 + ≈$1.9 → ≈$12. 예측 resume_ok ≥.15(현 .075, rf-v3 .143), press ≤.10, 반증 <.10.
find/restore: 쓰기 v7은 type1 바이트 불변. 읽기 v7은 find −.038(폴백 헤더 삭제) → 단일 읽기 판을 유지하려면 v7b(폴백 헤더 복원) 후 find·restore 20편 재확인 ≈$2.6; 대안은 가족별 읽기 판 표기.

오늘 파일럿 누계 $8.17(읽기 v7 $2.15 · 쓰기 v7 $5.05 · 조합 $0.97). 원천 tmp/routine_4cond.py · tmp/pilot_w7r7_compare.py · tmp/tagmemw7r7_{routine,resume}_flash37_s?/.

7읽기 v8 — 장부·상태 이미지·폴백 헤더 (125910 resume · 125911 routine · 125912 find, $2.26)

사용자 "resume·routine 둘 다 1등". vis-pure에 지는 행을 대조하니 reader가 번호 붙은 항목을 보고도 산술을 안 했다(항목 n=1,2 → "1개 놓음") → v8 = v7 + 인덱스 전체 결정론 장부(place irish potato → laundry basket [kitchen]: ×3 (n=1,2,3 · t=…) + 본 방 목록, 평균 177자) + 질의 수납처의 최신 이미지 보장(82개 중 75개 포함) + 폴백 헤더 복원 + 질의 태그 routine 어휘(basket). 사전등록: resume ≥.25 · routine ≥.53 · find ≥.60.

가족 (같은 행)	현 final	w7+r7	w7+r8	비오라클 베이스라인	사전등록
resume 32행 resume_ok / remaining_ok / slot / 기권	.094 / .094 / .125 / .50	.188 / .281 / .359 / .12	.219 / .312 / .406 / .00 (5/1)	vis .312/.312/.391 · frames .219 · rf-v3 .156	≥.25 ❌ (반증선 .19 위)
routine 60행 loc/place · self	.333/.183 · .409	.533/.483 · .614	.517/.483 · .591 (15/4 p=.019)	frames .517/.500 · rf-v3 .483 · vis .350	≥.53 ❌ (1행 차)
find 104행 loc/place · 기권 (v5 DB)	.615/.481 · .04	(r7) .577/.462 · .08	.615/.471 · .05 (2/2)	vis .615/.519 · frames .558	≥.60 ✅

resume에서 vis-pure에 남은 .09의 정체. vis만 맞힌 7행 중 6행은 횟수 오류인데, 원인은 reader가 아니라 DB 사건 수 자체(1588 바구니 항목 0개, 1639 놓기 3항목/실제 2회, 2877 1항목/2회). 장부는 DB 수를 정확히 전달했고 상태 이미지도 있었지만 reader는 장부를 택했다. 캡션 개수는 6행 중 1~2행만 도움. → 읽기로는 더 못 올린다. writer 포착률(68~72%)은 프롬프트로 안 움직였고(§5), 구조 변경(청크당 프레임 4→8)은 rf-v3·vis-pure에도 같이 적용해야 공정 = 전 전략 재ingest.

단일 방법 = 쓰기 v7 + 읽기 v8. find 불변(.615), resume +.125, routine +.183. 20편 순위: routine tagmem = frames(.517) > rf-v3 · resume tagmem = frames(.219) < vis(.312). r8 ≈ r7(routine 1행 차)이되 find 하락이 없으므로 4가족 공통 읽기 판으로 r8.

전량 제안 (승인 대기) ≈$38

routine 100편 재ingest + r8 ≈$13 — 예측 loc ≥.45(현 .319, rf-v3 .442, frames .432), 반증 <.40.
resume 100편 재ingest + r8 ≈$12 — 예측 resume_ok ≥.15(현 .075, rf-v3 .143), 반증 <.10.
find r8 재읽기 589행 ≈$6.5 — 예측 .653±.02. restore r8 재읽기 575행 ≈$6.5 — 예측 .368±.02(r8 미파일럿; −.03이면 r6 유지).

파일럿 누계 $10.43(r7 2.15 · w7 5.05 · w7+r7 0.97 · r8 2.26). 원천 tmp/pilot_w7r8_compare.py · tmp/routine_4cond.py · tmp/tagmem{w7r8_routine,w7r8_resume,v8_find}_flash37_s?/.

8전량 결과 — flash-3.7, resume 제외 (125967 routine · 125968 find · 125969 restore, $26.1)

사용자 결정: resume은 type2 writer 샘플링 변경 시 어차피 재측정이므로 제외. 채택 판정은 사전등록 규칙 스크립트(tmp/v8_adopt.py, tmp/w7r8_adopt_routine.py)가 병합 파일·마커를 만들 때만 빌더가 새 행을 쓴다.

가족 (flash-3.7, 본표 행)	현 final → 새 방법	짝비교 vs final	같은 행 비오라클 베이스라인	사전등록
routine 310행 loc/place (쓰기 v7 + 읽기 v8, 재ingest $8.73 + 읽기 $3.26)	.319/.168 → .513/.494 · self .346→.603 · observed .474 · 기권 .28→.06	77/17 p<.001	frames .432 (43/18 p=.002) · rf-v3 .442 (35/13 p=.002) · vis .381 (64/23) · 오라클 .565 (17/33 p=.033)	≥.45 ✅ → 채택
restore 519행 (읽기 v8, v5 그래프, $7.63)	.368/.164 → .389/.170 · loc_f1 .620→.636 · 기권 .069→.066 · D② .332→.357 · S① .216→.275	29/18 p=.14	vis .328 · rf-v3 .233 · frames .225 (힌트 v2 통일)	±.02 ✅ → 채택
find 526행 (읽기 v8, v5 그래프, $6.48)	.650/.519 → .641/.511 · loc_f1 .687→.679 · 기권 .051→.057	13/18 p=.47	vis .613 · frames .571 · rf-v3 .5x	±.02 ✅ → 채택(단일 읽기 판)

routine에서 tagmem이 비오라클 1위가 됐고 유의하다. 원인 수정이 그대로 전량에 옮겨졌다: 100편 DB에서 side table 태그 48/48편, laundry basket 37/37편(v5는 0), 발화 entry 178개. self .603은 frames .547·rf-v3 .551 위, observed .474는 vis-pure와 동률, multi는 전 전략 0.

resume은 그대로(v5 .075). writer 입력이 30초 청크당 4프레임(≈10초 간격)이라 누름·놓기 순간 ±1초 안에 프레임이 있는 비율이 16~25%. 프레임을 16장으로 늘리면 100%지만 rf-v3·vis-pure에도 같이 적용해야 공정해 resume 3전략 재ingest ≈$150(4가족이면 ≈$500). 보류. press_button은 프레임을 늘려도 픽셀상 구분이 안 돼 매체 한계로 명시.

final_results: find_v1.0_e987b40f·restore_v1.1_609076c0·routine_v1.2_dc1c8144 재생성, README 각주(읽기 v8 채택 규칙·routine 쓰기 v7·resume 미갱신 사유). 현재 flash tagmem = find/restore 쓰기 v5+읽기 v8 · routine 쓰기 v7+읽기 v8 · resume 쓰기 v5+읽기 v5. 오늘 API 합계 $36.5. 다음(승인 대기): luna ≈$12 · 오픈 3종 GPU ≈10 h/모델로 같은 방법 확장.

9다른 모델 확장 — luna · qwen3vl-8b · cosmos-r2-8b · molmo2-8b (API luna $4.86, 오픈 GPU)

표의 tagmem 열을 모델 간 같은 방법으로 맞추는 게 목적이라 점수와 무관하게 교체했고, 수치는 그대로 보고한다. 사전등록: luna routine ≥ frames − .05, find/restore ±.02, 8B 는 frames 미달(P7) 유지.

final_results loc	flash-3.7	luna	qwen3vl-8b	cosmos-r2-8b	molmo2-8b
routine tagmem (v5 → w7+r8)	.319 → .513	.245 → .306	.158 → .190	.161 → .197	.110 → .142
routine frames-uniform	.432	.355	.290	.258	.177
find tagmem (r6 → r8)	.650 → .643	.384 → .378	.228 → .218	.186 → .156	.205 → .191
find frames / vis-pure	.571 / .613	.405 / .437	.351 / .286	.393 / .328	.365 / .365
restore tagmem (r6 → r8)	.368 → .394	.125 → .133	.052 → .055	.042 → .035	.040 → .047
restore frames / vis-pure	.228 / .331	.154 / .144	.066 / .097	.096 / .078	.068 / .060

tagmem 이 비오라클 1위인 건 flash 뿐. 어휘 수정은 모든 모델에서 먹혀 side table·laundry basket 태그가 ≈100% 편에 붙었지만(luna 5/48 → 48/48), 8B 는 frames-uniform 을 못 넘는다(P7). ±.02 를 벗어난 칸은 cosmos find 하나 — 잃은 47행이 기권 17 · 형식 오류 17 · 오답 13 으로 고르게 퍼진 약한 모델의 행 교체.

8B writer 는 '발생당 1 entry' 규칙에 과잉 반응. 편당 entry: qwen 99 → 197 · molmo2 191 → 423 · cosmos 609 → 2,266(최대 6,371). flash 는 같은 규칙에 무반응이었으니, 프롬프트 규칙은 강한 모델에선 안 먹고 약한 모델에선 폭주한다. molmo2 는 v8 가이드로 기권이 절반이 됐지만 어휘 밖 답('dining room')으로 옮겨 점수는 그대로.

cosmos routine 샤드 사망 → 장부 크기 가드. 반복 붕괴 writer(한 행동 ×761, 전부 t=0)의 v7 장부가 시각을 모두 나열해 입력 49k 토큰 초과(400). LEDGER_GUARD_CHARS = 16000 을 넘을 때만 시각 목록을 요약하도록 writer·read 장부 모두 수정. 임계는 끝난 모든 런의 최대(writer 11,542 · read 9,271자)보다 커서 기존 호출은 바이트 동일, 재제출 126675 에서 실제 발동은 1/100편(6,369 entry). 테스트 32 passed.

resume 은 전 모델 v5 유지 — writer 가 30 s 청크당 4프레임이라 누름·놓기 순간 ±1 s 안 프레임이 16~25%. 해상도 축소는 Gemini 3(이미지당 1,120 토큰 고정)에 효과가 없을 가능성이 커, 청크당 16프레임을 2×2 모자이크 4장으로 보내는 안(3전략 공통 ≈$47)을 검토 중 — 과금 확인 프로브(<$0.02) 승인 대기.

방이 아니라 이름이었다 — routine 수납처 어휘 결함과 resume 횟수 미기록