여러 LLM에게 버그 위치를 찾아달라고 요청해 봤음

누가 헛다리 짚었나?

Muse Spark는 답을 내놓긴 했는데 원인을 잘못 짚었음. 얘가 관찰한 내용들은 확실히 비효율적인 작업이긴 한데, 버튼 호버랑 클릭 상태가 풀리는 직접적인 이유는 아니었음.

GLM 5.3 Flash는 원인은 제대로 찾았는데, 뇌피셜을 좀 섞었음. 특히 패널 전체가 다시 빌드된다거나, 장비 행(gear-row)이 다시 생성되는 게 주민 버튼 호버가 풀리는 직접적인 원인이라는 식으로 말했는데 이건 좀 부정확함.

평가 기준 (우선순위 순)

1. 정확한 근본 원인

   • 무조건적인 ApplyShell(Hidden(kind)) 호출
   • _preparation.Visible이 새로고침할 때마다 true -> false -> true로 바뀌는 문제

2. 정확한 인과 관계

   • 숨김 처리가 하위 버튼들한테까지 가시성 알림을 전파함
   • Godot의 BaseButton이 호버 상태랑 진행 중이던 클릭 상태를 초기화해버림
   • 마우스 누르기(mouse-down)와 떼기(mouse-up) 사이에 새로고침이 끼어들어서 Pressed가 안 먹힘

3. 보고된 모든 증상 설명 가능 여부

   • 호버 깜빡임 현상
   • 주민 선택이랑 파견 버튼 클릭이 가끔 씹히는 문제
   • Preparation 바깥에 있는 닫기 버튼은 잘 작동하는 이유

4. 원인과 부수적인 활동 구분

   • 장비 행 재빌드나 레이아웃 재계산이 일어나는 건 맞음
   • 하지만 이게 버튼 상태가 풀리는 결정적인 원인은 아님

5. 사실 관계의 정확성

   • 패널 전체나 주민 버튼이 새로 생성된다는 식의 헛소리는 없어야 함
   • 속성 할당이 마우스 제스처를 초기화한다는 식의 근거 없는 주장 금지

6. 유용한 보조 증거

   • 새로고침 체인이랑 틱 주기
   • Godot 엔진 동작 방식
   • 회귀(Regression) 이력

글자 수는 사실 별 의미 없음. 레이아웃 탓만 주구장창 늘어놓는 긴 답변보다는, 정확히 어떤 가시성 토글이 문제고 BaseButton 상태가 왜 초기화되는지 딱 짚어주는 간결한 답변이 점수가 훨씬 높음.

DS4.1 High가 제일 높은 점수를 받은 이유는 Godot 엔진의 세부 상태 필드까지 파고들어서 버그를 제일 정확하게 찾아냈기 때문임. Muse Spark 1.3은 주변에서 얼쩡거리기만 하고 결정적인 false -> true 가시성 전환을 놓쳐서 점수가 낮음. 다시 생각해보니 Terra 답변은 간결하면서도 버그를 정확히 짚어냈길래 점수를 조금 더 줬어도 됐을 것 같음.

내 기억이 맞다면 구독하는 것보다 openroute에서 luna 하나 쓰는 게 더 쌀걸