스팀 심사 큐에 올라가 있는 상태에서, MJ 님이 실기에서 신고하신 결함을 잡고 도착한 에셋을 반영하고 있습니다. 지금 붙어 있는 일과 남은 일이 앞 탭에, 끝난 일은 뒤 탭에 있습니다.
features/garden-ui · 마지막 커밋 1d24f0e · origin 동기오늘(2026-08-25) MJ 님이 주신 것들입니다. 창 던지기와 봉고 비상 분리는 끝나서 뒤 탭으로 옮겼습니다.
MJ 신고(18:22 스크린샷). 「루미가 사라지고, 트레이의 루미 아이콘도 사라지는 경우가 있어. 가든은 남아 있는 걸 보면 프로그램이 꺼진 건 아닌 것 같은데.」
가든이 남은 것은 앱이 살아 있다는 증거가 아닙니다. 가든은 별도의 Electron 프로세스라 앱이 강제로 끝나면 정리 훅이 안 돌아 가든만 남습니다. 실제로 다음 판이 「이전 세션이 남긴 가든 pid 24096 을 정리한다」고 적었습니다.
앱이 스스로 캐릭터를 치우는 길은 셋뿐이고 셋 다 로그를 남깁니다 — 전체화면 자동 숨김 · 트레이의 숨기기와 해산 · 종료. 그 자국이 하나도 없습니다. 윈도우 이벤트 로그에도 오류가 없고, JVM 충돌 덤프도 없고, 다른 루미 설치본이 오늘 돈 자국도 없습니다 (넷 다 로그가 8월 17~18 에 멈춰 있습니다).
지금 단계 — 근본 원인은 못 짚었습니다. 그리고 못 짚은 이유가 분명합니다 — 앱이 갈 때 아무 자국도 안 남겼습니다. 밖에서 끝난 것인지 스스로 나간 것인지조차 가릴 수 없었습니다. 그래서 다음 판이 스스로 답하게 만들어 두었습니다(아래 「끝난 것」). 다음에 같은 일이 나면 로그 맨 앞이 어느 쪽인지 이름을 댑니다.
MJ 지시대로 우클릭 메뉴에서 「봉고 큰 루미 ↔ 봉고 작은 루미」를 오갈 수 있게 했고, 비상도 넣었습니다. 두 모습 모두 3초에 30타(분당 600타)를 넘기면 빨간 불이 들어옵니다.
처음 만들 때 방아쇠를 두 군데 틀렸다가 MJ 정정으로 바로잡았습니다 — 「봉고 루미」가 두 모습을 아우르는 통칭인데 큰 쪽만으로 읽었고, 알람 훅을 봉고에 붙였습니다. 알람의 주인은 돌아다니는 루미이고 그쪽 비상은 아직 없습니다(아래 남은 일).
그리고 MJ 께서 정훈님 원본과 대조해 잡아 주신 것 하나를 고쳤습니다 — 배포본 12장이 책상을 몸 아래에 깔고 있었습니다. 루미의 상의가 드러나고 키캡이 몸 위에 겹쳐 있었는데, 순서만 바로잡으니 원본과 첫 시도에 일치했습니다. 다시는 방법을 잃지 않도록 합성 순서를 스크립트로 남겼습니다.
MJ 님 손이 필요 없는 것들입니다. 위에서부터 순서대로 갑니다.
지금은 없습니다. 오늘 저녁에 넷을 전부 닫았습니다 — 정원 한국어 · 섬 모드 B안 · S8-1 · T8-1. 남은 것은 아래 중간·낮음과, 원인을 못 짚은 「루미가 사라진다」 하나입니다.
logging.properties 의 append ·
호감도 「오늘 남은 것」 등.제가 대신 할 수 없는 것들입니다. 하신 것은 눌러서 지워 두시면 됩니다.
체크는 이 브라우저에만 남습니다.
⚠️ 또 루미들이 다 같이 멎으면 앱을 끄지 마시고 알려 주세요. 그 상태 그대로여야 스레드 덤프를 떠서 원인을 잡을 수 있습니다. 오늘 교착을 잡은 것이 정확히 그 방법이었습니다.
MJ 님이 실기에서 확인해 주신 것과, 검사로 증명된 것만 여기에 둡니다.
b216307
MJ 지시(21:00): 「루미를 클릭한 상태로 가만히 있으면 쓰다듬기가 발동되어 고개를 좌우로 까딱까딱 해야 해.
요건 일반적인 쓰다듬기와 별도 조건.」 0.7초 가만히 쥐면 시작되고, 손을 안 움직여도 루미가
0.5초마다 스스로 고개를 좌우로 넘깁니다.
1d24f0e
앞서 비GUI 러너에 가드를 넣었는데 그 뒤 실행에서도 또 바뀌어 있었습니다.
남은 자리가 GUI 스윕이었고 같은 가드를 넣었습니다. 넣은 뒤 스윕을 한 번 돌려 전후를 견줬고 값이 그대로입니다.
오늘 하루에 다섯 번 손으로 되붙인 것이 이걸로 끝납니다.272d340
정원의 번역표는 한국어가 키이고 다른 언어가 값입니다. 그런데 「영어가 아닌 모든 언어」에
영어를 바탕으로 깔게 돼 있었고, 한국어 파일은 항목이 0개라 바탕만 남아 전부 영어로 떨어졌습니다.
조건에서 한국어만 뺐습니다 — 일본어·중국어에 영어를 까는 것은 의도된 폴백이라 그대로 둡니다.
MJ 님이 신고하신 세 문장이 한국어로 남고 일·중·번체에서는 번역되는 것을 검사가 못박습니다.272d340
정원을 한 번도 안 켜고도 모드가 만든 지형 위를 루미가 걷습니다.
conf/garden.properties 에 한 줄이면 되고, 파일 모양은 정원이 쓰는 것과 똑같습니다.
Electron 을 안 띄우므로 메모리·GPU 비용이 0 이고, 정원을 못 돌리는 사양에서도 지형을 봅니다.
garden.path 와 같은 자리를 지납니다 — 따로 만들면 한쪽만 새는 구멍이 생깁니다.
272d340
첫 섬의 중심이 「창 한가운데」였는데 창은 기본값에서 가상 데스크톱 전체입니다.
같은 크기 모니터 두 장이면 창 한가운데가 정확히 두 화면의 경계선이라,
아무것도 안 한 사용자의 섬이 「올릴 수 없는」 모양으로 놓였습니다.
이제 주 모니터 한가운데에 놓습니다. 실측으로 옛 규칙은 화면 x −360~360(경계선),
새 규칙은 920~1640(주 모니터 안)입니다. 화면을 고르신 분은 예전 그대로입니다.272d340
모니터가 잠깐 빠진 사이에 [완료] 를 누르면 「이 모니터에만 머무르기」가 꺼진 것으로 기록돼,
모니터가 돌아와도 자동 복구가 영영 안 돌았습니다. 짝인 「끄기」는 처음부터 뜻을 저장했으니
한쪽만 뜻을 잃고 있었습니다. 이제 파일에는 뜻을 쓰고, 런타임 값만 지금 화면 구성으로 맞춥니다.272d340
검사 몇몇이 저장소에서 돌며 설정 파일에 실제로 쓰고, 엔진은 그 파일을 통째로 다시 씁니다.
그래서 검사를 한 번 돌 때마다 봉고 모습·창 자리·알람 시각이 검사가 남긴 값으로 바뀌어 있었습니다 —
오늘 하루에 세 번 손으로 되붙였습니다. 이제 러너가 로그와 똑같이 떠 두고 끝나면 되돌립니다.
8eb8e79
MJ 신고: 「쓰다듬는 손이 적용이 안 되었어.」 정훈님 그림은 낮 12시 커밋에 이미 들어와 있었고 판정도 그때 맞췄는데,
칠하는 자리가 둘이었습니다. 저희는 마스코트 창에 칠했고, 엔진은 그 창 안의 컴포넌트에 칠했습니다.
스윙은 마우스 아래 컴포넌트가 정한 커서를 먼저 쓰므로 저희가 칠한 자리는 아무도 보지 않았습니다.
게다가 엔진은 마우스가 움직일 때마다 칠해서 언제나 마지막이었고, 그때 부르던 그림이
전부 투명한 빈 그림이라 운영체제 손 포인터로 떨어졌습니다.
481b4f4·6d4b69f
위 ①의 절반입니다. 원인은 못 짚었지만, 다음에는 앱이 스스로 답합니다.
뜰 때 「돌고 있다」를 적고 내려갈 때 「내려갔다」로 덮습니다. 강제로 끝나면 정리 훅이 안 돌아
「돌고 있다」인 채로 남고, 다음 판이 그것을 읽어 로그 맨 앞에 적습니다.
실기에서 확인했습니다 — 일부러 강제 종료한 뒤 다시 띄우니
「지난 판은 스스로 내려가지 않았다 — running pid=29188 at=19:36:31」이 그대로 찍혔습니다.
2b43e75
MJ 지시(18:45): 「알람이 울릴 때 루미가 텍스트로 알람이라고만 말하고 지나가버려.
비상 모션을 1분 동안 틀어주고, 알람 효과음도 추가해줘.」
alarm.wav 입니다. 8월 20일부터 들어 있었지만 conf 의 어떤 자세에도
붙어 있지 않아 아무도 부르지 않고 있었습니다. 음량과 「하나씩 끄기」는 엔진이 자세 소리에 쓰는
관문을 그대로 지납니다 — 따로 만들면 「설정에서 껐는데 이것만 난다」가 생깁니다.
2b43e75
MJ 스크린샷(18:20)의 그 말풍선입니다. 혼잣말 한 줄이 제 수명 3.6초를 96초까지 넘겨 남았고,
루미에게서 1,600픽셀 떨어진 자리에 굳어 있었습니다 — 자리도 안 옮겼다는 뜻입니다.
javaw 로 뜨는데 콘솔이 없어, 화면 스레드의 예외가 찍히는 곳이 어디에도 닿지 않습니다.
c449875
MJ 지시(18:05)대로 넣었습니다. 왼쪽(마우스 쪽) 아이는 커서가 바쁘면,
오른쪽(키보드 쪽) 아이는 3초에 30타를 넘기면 각각 따로 빨개집니다.
큰 봉고는 아이가 하나뿐이라 지금대로 비상도 하나입니다.
echo rc=$? 인데, WSL 을 넘어온 종료코드는 언제나 0 입니다.
실제로 검사 둘이 빨간불인데 rc=0 으로 읽혔습니다. 러너의 자기 보고 줄을 읽어야 합니다.
다음 인수 문서와 자동 메모리에 적었습니다 — 「검사가 무력하다」와 같은 종류라 그냥 두면 다음 세션이 그대로 속습니다.shows=true 입니다. 거부되는 판이 없으니 이 의심은 접습니다.sit_down 이 0.46초로 규격(0.25초)을 넘습니다. 2차 납품 때 함께 부탁드릴 참입니다.전부 origin/features/garden-ui 에 올라가 있습니다.
4649dc0
우클릭 메뉴에서 「봉고 루미 ↔ 작은 루미」를 오갑니다. 비상의 방아쇠가 모습마다 다릅니다 —
봉고 루미는 3초에 30타(분당 600타), 작은 루미는 알람입니다.
만드는 길도 갈렸습니다: 큰 봉고는 비상머리 두 장을 프레임 위에 덧그려 열두 장 전부를 처리하고,
작은 루미는 자세마다 구워진 프레임을 씁니다 — 키보드 쪽 아이의 비상이 머리가 아니라 전신 교체본이라
덧그리기로는 안 되기 때문입니다. 검사 일곱을 더했고(봉고 블록 88 → 95),
규칙대로 프레임 한 장을 치워 빨간불을 먼저 본 뒤 되돌렸습니다.c005b14
MJ 께서 정훈님 원본과 대조해 잡아 주신 것입니다 — 배포본 12장이 책상을 몸 아래에 깔고 있어서
루미의 상의가 드러나고 키캡이 몸 위에 겹쳐 있었습니다. 순서만 바로잡으니 원본과 첫 시도에 일치했습니다.
원본은 남아 있었는데 합성 방법이 남아 있지 않아 아무도 다시 확인할 수 없었던 것이 진짜 문제라,
이번엔 순서를 build/build_bongo_frames.py 에 코드로 적었습니다.fa00267
MJ 확인 완료 — 알람 창과 「할 수 있는 것」 둘 다 바로 열립니다.
가려진 것이 아니라 윈도우가 창을 화면에 올린 적이 없었습니다. 창의 진짜 핸들로 재니
22초 내내 WS_VISIBLE=false 였고 앞창은 한 번도 우리 것이 아니었습니다.
이 창들은 모달이라 뜨면서 입력 초점을 가져와야 하는데, 윈도우는 앞자리를 가진 프로세스가 아니면
내주지 않습니다. 지금은 700ms 에 true 이고 그 비트가 곧 합격 판정입니다.6e10413 · 1cd00a9
앞 세션이 같은 문제를 두 번 놓친 이유가 여기서 드러났습니다. 진단이 「화면 안에 있고 활성이면
조용히 빠져나가게」 돼 있어서, MJ 가 20초를 기다린 바로 그때 로그가 비어 있었습니다.
이상해 보일 때만 남긴다는 판단을 진단이 미리 하면, 그 판단이 틀린 경우에 증거가 사라집니다.
지금은 조건 없이, 다섯 시점에, 창의 진짜 핸들로 남깁니다.5afac9a
MJ 확인 완료 — 「지금은 창던지기 명령으로 교착이 일어나지 않아」.
jstack 이 Found one Java-level deadlock 을 찍어 원인을 직접 지목했습니다.
Ticker 는 「Manager 잠금 → 행동객체 자물쇠」 순으로 잡고, 메뉴를 누른 화면 스레드는 그 반대 순으로 잡아
서로를 영원히 기다렸습니다. 화면 스레드가 Manager 잠금을 요구한 이유는 행동 조건식 열다섯 개가 읽는
mascot.totalCount 였습니다.
고른 행동은 원인이 아니었습니다 — 무엇을 골라도 같은 경로였고 창 던지기는 마침 타이밍이 겹쳤을 뿐입니다.
이제 그 값을 잠금 없이 읽습니다. 새로 기다릴 자리는 한 곳도 만들지 않았습니다.6c06859
새로 설치하는 사람에게 적용됩니다(-6.02 dB). 격리 환경에서 새 설치를 흉내내 확인했습니다.
출하 시드는 건드리지 않았습니다 — 검사가 「시드에 lumi.* 키가 하나도 없다」를 못박고 있어
기본값의 정본은 코드입니다.743097b
걷기 ①② · 달리기 ①② · 도약 · 사뿐한 착지 · 앉기 · 집힘.
배선이 이미 돼 있어 파일 여덟 개를 덮는 것으로 끝났고 빌드도 필요 없었습니다.
자리채움 원본은 되돌릴 수 있게 떠 두었습니다.TotalCountLockFreeTest
고치기 전에 일부러 빨간불을 확인했습니다(4개 중 1개 실패 → 수리 후 전부 통과).
날 것의 잠금이 같은 상황에서 정말 막히는지 재는 대조군을 함께 넣어,
언젠가 잠금 구조가 바뀌면 검사가 아무것도 안 지키면서 초록이 되는 것을 막았습니다.MJ 님이 결정 게이트에서 「8라운드 수정만 하고 종료」를 고르셔서 9·10은 돌지 않습니다.
이 페이지의 원래 목적이었습니다. 답이 모두 모여 결정 단계는 끝났습니다.
이 페이지는 결정 게이트에서 작업 현황판으로 바뀌었습니다 — 결정 여덟은 모두 답을 받아 끝났고,
지금 필요한 것은 남은 일의 상태이기 때문입니다. 사실관계의 정본은 저장소의 커밋 메시지와
docs/handoff/ 의 인수 문서이며, 이 페이지는 그것을 MJ 님이 보시기 좋게 추린 것입니다.