debugger

debugger 에이전트는 증상을 덮는 대신 실패를 root cause까지 추적합니다. 조사 전에 재현 가능성을 먼저 확보하고, 에러 메시지와 stack trace를 전부 읽고, 한 번에 하나의 가설만 세워 검증합니다. 같은 접근이 세 번 실패하면 변형을 반복하지 않고 상위 레인으로 에스컬레이션합니다.

언제 호출되는가

사용 예시

"이 에러가 왜 나는지 root cause를 찾아줘"
"이 테스트가 왜 갑자기 깨졌는지 추적해줘"
"빌드 에러를 증상 말고 원인 기준으로 좁혀줘"

런타임 버그 조사 프로토콜

1. 실패를 안정적으로 재현합니다.
2. stack trace, 에러 메시지, 최근 변경 이력을 모읍니다.
3. 한 번에 하나의 가설만 세웁니다.
4. 가장 작은 수정으로 그 가설을 검증합니다.
5. 맞지 않으면 다음 가설로 넘어갑니다.

여러 수정안을 한꺼번에 넣지 않습니다. 한 가설, 한 변경 원칙을 유지합니다.

빌드 / 컴파일 에러 해결 프로토콜

• 에러 종류를 먼저 분류합니다.
• import/export 문제, 타입 추론 문제, 설정 문제를 구분합니다.
• 가장 작은 수정으로 하나씩 줄입니다.
• 수정 후에는 diagnostics / build를 다시 돌려서 실제로 해결됐는지 확인합니다.

에러 메시지를 읽는 데서 멈추지 않고, 분류 → 가설 → 최소 수정 → 재검증 루프를 반복합니다.

입력

• 에러 메시지, stack trace, 실패한 테스트 출력
• Grep, Read, git log/blame으로 접근한 전체 코드베이스
• 선택적으로 재현 절차, 환경 정보, 이전 가설 메모

출력

• root cause, file:line 근거, 최소 재현 절차, 최소 수정 권고, 검증 방법을 포함한 bug report
• 같은 패턴이 있을 수 있는 다른 코드 위치 목록

제한 사항

• 세 번의 가설 실패 후에는 circuit breaker를 적용해 evidence와 함께 에스컬레이션합니다.
• 여러 수정안을 한 번에 묶지 않습니다.
• probably, seems like 같은 표현으로 진단을 마무리하지 않습니다. file:line 근거가 있어야 합니다.

관련 에이전트

• explore — 버그 위치를 아직 모를 때 가벼운 read-only lookup을 수행합니다.
• verifier — 수정이 실제로 문제를 해결했는지 전체 증거로 확인합니다.
• test-engineer — root cause가 확인된 뒤 regression test를 설계합니다.
• explore-harness — 다중 가설 인과 조사에 사용됩니다.