dxlisted

# dx — 원인 미상 버그 진단 루프 증상은 있는데 **원인을 모르는** 버그를 다룬다. `/dev`처럼 spec/plan을 먼저 만들지 않는다. 원인을 모르는 상태에서 spec을 쓰는 건 추측을 문서화하는 것일 뿐이다. 대신 **증거 → 가설 → 결정적 단서 → 확정 → 최소 수정** 순으로 좁혀간다. 핵심 효율 동작 하나: **모든 가설을 다 고치지 말고, 가설을 가르는 질문 1개를 사용자에게 먼저 던져라.** 헛다리 수정이 가장 큰 낭비다. ## 핵심 규칙 (어기지 말 것) 1. **추측을 사실처럼 말하지 않는다.** 모르면 모른다고 하고, 증거로 좁힌다. 2. **가설은 2~3개를 동시에 세운다.** 단, 서로 **다른 수정**으로 이어지는 것들만. 같은 수정으로 수렴하면 굳이 나누지 않는다. 3. **가설을 가르는 질문은 1개.** 여러 개 묶지 말 것. 사용자의 답이 다음 행동을 바꾸는 질문만. 4. **확정 전엔 고치지 않는다.** 원인을 한 개로 좁히기 전에 코드를 건드리지 않는다. 5. **수정은 surgical.** 확정된 원인에 직접 닿는 라인만. 인접 코드 정리·리팩터 금지. 6. **검증 한계를 정직하게.** 재현 못 한 부분(슬립·레이스·실기기 의존)은 green이라고 말하지 말고 "직접 확인 못 함 + 수동 확인 레시피"를 같이 준다. ## 루프 ### 0. 증상 고정 `pw set-status phase "DIAGNOSE" --icon "🔬" --color "#A855F7"` (워크스페이스 있으면) 증상을 관찰 가능한 형태로 다시 적는다 — "안 됨"이 아니라 **무엇이 / 언제 / 어떻게 보이는가**. - 무엇이 깨지나 (입력? 출력? 크래시? 멈춤?) - 트리거 (슬립 후 / 특정 조작 / 시간 경과 / 무작위?) - 빈도와 회복 (항상? 가끔? 저절로 풀림? 재시작만 풀림?) ### 1. 코드 지도 (증거 수집) 직접 답한다 — 탐색을 서브에이전트에 위임하지 말 것. codegraph가 이미 인덱스다. - `codegraph_context` / `codegraph_trace`로 관련 경로(입력→처리→출력)를 1~2콜로 파악. - **그 영역의 최근 커밋을 반드시 읽는다**: `git log --oneline -20`, 의심 파일은 `git log -p -3 -- <file>`. **최근 커밋 메시지의 "가정"이 범인인 경우가 많다.** (예: "입력은 별도 연결이라 멀쩡" 같은 주장 → 그 가정이 깨지는 케이스가 바로 이 버그.) - literal 문자열·로그 메시지 검색만 grep. 구조 질문은 codegraph. ### 2. 가설 분기 서로 다른 수정으로 이어지는 후보 2~3개를 적고, 각각이 맞다면 **어떤 관찰로 확인되는지**를 명시. 예: "focus 상실이면 클릭으로 복구 / 스트림 단절이면 클릭해도 안 되고 리로드만 복구." ### 3. 결정적 질문 (AskUserQuestion) 가설을 가장 잘 가르는 질문 1개(필요시 트리거 좁히기 1개 추가)를 `