[now] · KEEP 타일 저장done 턴 — 기록은 되지만 읽을 턴이 없다. 유효 KEEP 은 0.092/턴(0.237 아님) → 측정 무대는 find(평균 4.8턴)가 아니라 restore(20턴+).[now](갱신, 항상 표시) + KEEP 프레임을 모델이 본 exo‖wrist 타일로 저장.images=keep 인 vis-pure·tagmem 뿐. blind·textlog·frames-uniform·rf-v3 프롬프트는 src_w1 과 바이트 동일(해시 확인) → 4전략 restore 95행·find 821행 유지.이 벤치마크 온라인 트랙이 재려는 것은 execute-state memory — 실행 중 바뀐 세계 상태를 자기 메모리 구조에 반영하고 다시 꺼내 "2개 중 1개는 끝냈다"를 아는 능력이다. 사용자 지적(260920): vis-pure 는 온라인 프레임을 KEEP 해서, tagmem 은 "이 액션을 했다"를 저장해서, 텍스트 노트는 한 일을 기록해서 각자 상태를 남겨야 한다.
앞선 감사(260920-online_plan_find_main §9)에서 find 본 런 6 arm 중 execute-state 채널이 실제로 작동한 것은 tagmem 하나뿐이었다. 이 카드는 그 뒤 후속 조치 — 원인 진단과 채널 개조 — 를 다룬다.
| 전략 | 채널 실태 (감사 결과) | 조치 |
|---|---|---|
| blind | 대조군, 시드 1줄 불변 | 유지 |
| textlog | note: null 강제 — 채널 원천 차단(260909 사용자 결정) | 결정 A: 보류 — "execute-state 채널 없음" arm 으로 명시 |
| frames-uniform | 온라인 프레임 정확히 1장(235/235칸) = 현재 뷰 중복, 순증 0 | 방법의 성질, 기록만 |
| rf-v3 | 88% 칸 재작성, 100%가 [plan] 줄 삭제, done 체크 1% | 모델 지시 미준수, 기록만 |
| vis-pure | KEEP 계약은 tagmem 과 글자 그대로 동일한데 keep 0.12/칸 · 89% 칸 0장 | 결정 B: 원인 진단 |
| tagmem-r3 | 온라인 노트 6.6줄/칸 · 77% 칸 완료 문장 · 프레임 87% 칸 ≥1장 — 단 태그화·재검색은 안 함(평문 append) | 결정 D: 태그화+재검색 |
vis-pure 의 KEEP 미사용이 능력 문제인지 계약 프레이밍 문제인지 가른다. 유력 가설: 메모리가 시드 8장으로 꽉 차 시작해서 KEEP 이 "내가 고른 읽기 프레임을 버리는 것"으로 읽힌다.
예산·규칙은 그대로이고 이미 참인 사실을 명시할 뿐이다. GT 누출 여부: KEEP 규칙 1번이 이미 "집히는 물체·놓인 물체를 남겨라"라고 말하고 있어 목적을 새로 알려주지 않고 비용 인식만 바꾼다. 진단이지 arm 개조가 아니므로 채택은 결과를 보고 사용자가 결정.
8e5a35a)3432dee)사용자 260920 "execute-state 를 재는 거야, 이게 젤 중요해" 에 따라 축출 문장을 기본 켬으로 전환(SBENCH_KEEP_EVICTION_NOTE=0 이면 260920 이전 프롬프트 바이트 재현). 근거는 성능 부스팅이 아니라 하네스가 만든 조건(읽기 단계가 8슬롯을 다 써 메모리가 꽉 찬 채 시작)을 명시하는 공정성 수정 — 이 문장이 없으면 "채널이 있으나 안 쓴다"를 보고할 수는 있어도 채널 효과를 잴 수는 없다. 이어 사용자 설계로:
| 지표 | A(현행) | B(축출 정상화 문장 1줄) |
|---|---|---|
| 턴 합 | 103 | 76 |
| KEEP 결정 합 | 0 | 18 |
| 온라인 프레임 보관 합 | 0 | 14 |
| ≥1장 보관 칸 | 0/16 | 13/16 |
| 턴당 KEEP 율 | 0.000 | 0.237 |
| seed_left 평균 | 8.00 (손 안 댐) | 7.12 |
부수 지표는 n=16 에서 전부 비유의(Δ턴 −1.69±1.23 · Δpick −2.00±1.33 · Δ성공 −0.06±0.11). 방향은 B가 효율적이지만 효율 효과는 본 재측정이 잴 것이다.
| 값 | |
|---|---|
B팔 KEEP 18건 중 마지막 done 턴 | 11건 (61%) |
| 턴당 전체 KEEP | 0.237 |
| 턴당 유효 KEEP (이후 턴에서 읽힘) | 0.092 |
| 유효 KEEP 중 직전 턴이 '성공한 pick' | 2건 |
0 → 0.092 는 여전히 실질 변화(A팔 0/103턴)지만 find 는 평균 4.8턴이라 채널을 열어도 쓸 기회가 적다.
| 대상 | 칸 | 처리 |
|---|---|---|
| restore 4전략(blind·textlog·frames·rf-v3) | 69행 완료(이후 95행) | 유지 — 프롬프트 바이트 동일 |
| restore vis-pure | 17행 완료(이후 23행) | 폐기·재측정 (백업 tmp/plan_main/rows_oldprompt/) |
| restore 잔여 | 395 | 새 스냅샷 src_w2 로 이어서 |
| find 4전략 | 821행 | 유지 |
| find vis-pure | 287 | 재측정 (2샤드) |
| find tagmem | 302 (옛 124행 폐기) | 재측정 (D + 축출 문장 + [now]) |
비용: restore 잔여 $73(그중 vis-pure 재지출 순증 ≈$5) · find vis-pure $21 · find tagmem $26 = $120, 이 결정으로 추가되는 돈은 ≈$36. Letsur 일일 캡 $100 이라 이틀에 나눠 쓴다. 발동 범위(결정 D 선택기): 예산(12줄)을 넘는 칸 = find 13%(124칸 중 16) · restore 46%(52칸 중 24) — find 의 87% 는 프롬프트가 종전과 같다. 단위 테스트 1088 passed(integration 제외).
1) "vis-pure 는 execute-state 채널이 있으나 안 쓴다"는 모델 능력이 아니라 프롬프트 프레이밍 하나의 결과였다. 문장 1줄로 0/16→13/16칸이 바뀌므로 개조 전 표의 vis-pure 는 "채널 없는 arm"으로만 읽어야 한다.
2) 채널을 열어도 find 는 턴이 짧아(4.8턴) 유효 KEEP 이 0.092/턴에 그친다. execute-state 효과는 사슬이 2단계 이상인 restore(pick→carry→place)에서 재야 한다 — 그래서 restore 본 런을 새 스냅샷으로 재시작했다.
3) 이 개조로 arm 축이 정리된다: blind·textlog=없음, frames-uniform=현재 뷰 중복, rf-v3=텍스트 상태(재작성), vis-pure=이미지 누적(KEEP), tagmem=태그 DB+텍스트·이미지 상태 슬롯. 방법론상 [now] 상태 슬롯은 읽기 writer 규칙(STORE 누적뿐)에 없는 온라인 전용 기제지만, 읽기 트랙엔 온라인 구간이 없어 "실행 상태를 무엇으로 표현할 것인가"는 어차피 온라인 전용 설계 결정이다.
진단 n=16 이라 효율 지표(턴·pick·SR)는 검정력이 없다. 개조 후 vis-pure·tagmem 이 실제로 restore 에서 turn/pick 을 줄이는지는 본 재측정 결과가 필요하다. textlog 는 oracle 로그 복원(결정 A)을 보류해 "execute-state 없음" arm 으로 남는다 — 논문 서술에서 blind 와 같은 지위로 명시해야 한다.
재측정 12잡(restore 8샤드 · tagmem find 2샤드 141430/141431 · vis-pure find 2샤드 141432/141433, 전부 tmp/plan_main/src_w2) 완주 후 scan_online_turns.py --family restore → aggregate_online_efficiency.py --family restore 로 같은 LOO 효율 분석을 restore 에 적용. 가설: 상태 채널을 쓰는 vis-pure·tagmem 이 restore 에서 든 채 재-pick 과 낭비 턴을 blind·textlog 대비 줄인다(현재 find 에서는 차이 없음).