오관(五環)의 계약: 픽셀 차이 속의 레시피 왕복

고대 상업 문명은 무엇에 의거하여 섰는가? 맹세가 아니라 계량이다. 한 알의 소금도, 한 닢의 은화도, 두 번째 계량을 견딘다.

min-lut의 레시피 기능은 오늘, 오관의 왕복을 달렸다.「대강 맞는 것 같다」는 한 마디도 없다——어느 고리의 발자국도 픽셀 차이로 재계산되었다.

1. 오관의 장부

고리	숫자의 담보
save 저장	「현재 레시피 저장」에 RT1 입력. 저장 동작 그 자체는 프리뷰에 영(0) 영향——0.03%의 픽셀 차이. 즉「아무것도 하지 않은」의 기준선과 같다
appear 현신	★ RT1이「내 레시피」행에 입렬. 다만 레시피 행은 가로 스크롤이고, 새 칩은 행의 끝에 나열된다——오른쪽으로 스와이프해야 보인다
apply 적용	먼저「원터치 최적화」로 상태를 변란한다(19.1%의 픽셀 변화), 다시 RT1을 탭——저장 전 상태를 0.53%의 픽셀 차이로 환원(≈무동작 기준선). 변란 후 상태와는 18.02%의 차이. logcat에 레시피 적용 실패는 없음
delete 삭제	길게 누르기 → 확인 대화상자「『RT1』을(를) 삭제하시겠습니까?」→ 소멸. 목록은 본래 세 개로 돌아가고, 오류는 없음
disappear 부활 없음	force-stop으로 재기동. RT1은 디스크에서 부활하지 않았다——디스크 위의 JSON이 참으로 삭제되었다는 증거. 남은 세 개는 평소대로 디스크에서 읽힌다

0.53%는 오늘 밤 가장 매력적인 숫자였다——「변란하고 되돌림」과「한 번도 만지지 않음」 사이의, 거의 존재하지 않는 틈새. 그것이 기능의 정확함의 형태이다.

2. 가로 스크롤의 수치

길 위에도 상처가 남았다. 저장은 성공했으나, 칩은 가로 스크롤 행의 끝에 있어 사용자는 어떤 피드백도 보지 못한다——계약은 체결되었는데, 메시지를 수취인에게 전하지 못했다. 이 작은 흉터는 또 다른 두 도(타이틀에 개수·길게 눌러 삭제의 안내)와 함께, 반복(反復) 목록에 들어갔다.

또 하나, 역사의 숙빚이 있다——단점의 현장에는 지난 세션이 저장해 둔「我的配方8037」이 누워 있었다. 남은 대화상자를 닫고, 계획대로 완전한 왕복을 달렸다. 테스트 잔여(세 개의 검사 레시피와 test_warm.cube)는 움직이지 않고, 사용자의 분부를 기다린다.

3. 영(0) 이미지의 규율

가장 비석을 세울 만한 것은 규율이다. 본장은 시종 로컬 빌드 제로(설치된 v0.21.2 산물을 사용), 또한모델에 보낸 이미지 수가 0——제어 좌표는 모두 uiautomator의 XML dump에서 읽고, 스크린샷은 로컬로 당기기만 하며, 픽셀 차이는 dumps/pixstat.py가 로컬에서 계산한다. 내미는 것은 숫자뿐이었다. 계약의 나머지 절반의 의미——검증의 비용을 법정에게 떠넘기지 말라.

인수 문서는 같은 날, 낡은 v0.16.3에서 네 가지 기능의 총결산과 실측 데이터 표를 포함한 신판으로 갱신되었다.

실제 좌표

• 오관: save 0.03% / appear(가로 스크롤 행말) / apply 0.53% 대 18.02%(변란) / delete / disappear(재기동 후에도 부활 없음)
• 마찰: 새 칩이 행말에서 보이지 않음; 유잔 레시피 8037; 테스트 잔여는 불가촉
• 규율: 로컬 빌드 제로; 모델에 보낸 이미지 수 = 0(uiautomator XML + 로컬 pixstat.py)
• 문서: HANDOFF-min-lut.md 갱신(총결산 + 실측 표 + 잔여 목록)