tiguclaw-bug-report

티구클로 버그 신고 정리본

결과물은 정리본 하나다 — 개발자가 읽고 바로 재현·판단할 수 있는 글. GitHub 이슈 제출은 사용자가 원할 때만, 6의 확인을 거쳐 한다. 수정은 이 스킬의 일이 아니다.

1. 언제 쓰나

• 명시 요청(«버그 리포트로 정리해 줘» 등) → 요청이 곧 동의다. 다시 묻지 말고 2로 간다. «이슈로 올려 줘» 처럼 제출까지 청했으면 그것이 제출 절차 시작 동의다 — 5의 제출 질문 없이 6으로 간다(공개 쓰기 승인은 6.4 에서 따로). «버그면 정리해 줘» 처럼 조건이 붙었으면 바로 할 수 있는 확인만 하고 — 사용자 설정·오해로 확인되면 그렇게 말하고 쓰지 않는다, 그 밖(결함이거나 아직 갈리지 않음)은 쓴다(갈리지 않은 가능성은 «원인 추정» 에 함께 적는다).
• 사용자가 이상을 말했다(«이상해»·«안 돼»·«왜 이래») → 먼저 평소대로 확인·해결을 돕는다. 그러다 티구클로 자체 결함의 근거가 생기면 답 끝에 한 번 제안한다: «티구클로 결함으로 보입니다 — 개발자에게 전달할 버그 신고 정리본으로 만들어 드릴까요?» 동의하면 작성한다.
  • 근거의 예: 설명·설정과 다른 동작이 다시 일어난다 · 티구클로가 낸 오류·스택이 있다 · 같은 입력에 같은 오작동 · 화면·채널끼리 상태가 어긋난다.
  • 원인이 사용자 설정·오해·외부 서비스(모델 제공자 장애·한도, 메신저 장애, 네트워크)로 확인되면 제안하지 않는다 — 원인과 해결만 말한다. 단 티구클로(비서 자신 포함)가 잘못 다뤘다면(오류를 숨김·엉뚱한 안내·사용자가 말하지 않은 값을 멋대로 정함) 그 부분은 근거가 된다.
• 쓰지 않는다: 사용자의 문제 제기 없이 내가(점검·스케줄·백그라운드 작업에서) 발견한 것 — 평소처럼 결과만 보고하고 신고를 권하거나 정리본을 만들지 않는다. 사용자 자신의 프로젝트 코드 버그. 사용자가 없는 턴.
• 같은 문제의 제안은 한 번이다. 거절하거나 답이 없으면 그 문제로 다시 권하지 않는다(사용자가 나중에 직접 요청하면 그때 쓴다). 제안만으로 파일을 만들지 않는다.

2. 모은다 — 사용자에게 묻기 전에

재료는 이미 대부분 있다: 이 대화(사용자 말·내 확인 결과·오류 문구), 환경, 관련 로그 몇 줄. 양식을 사용자에게 내밀지 않는다.

• 조사는 평소 경계 그대로다. 재현에 외부 전송·삭제·설정 변경·재시작 같은 부작용이 필요하면 하지 말고 «재현 시도 안 함(이유)» 로 적는다.
• 원인 규명이 정리본을 막지 않는다. 재현이 안 되거나 원인이 안 잡혀도 지금까지로 쓴다 — 모르는 것은 «미확인» 칸에 둔다.
• 사용자에게 묻는 것은 대화로 못 메우고, 없으면 신고가 성립하지 않는 것뿐이다(예: 무엇을 기대했는지가 전혀 안 드러남). 한두 가지만 묻고, 나머지는 «미확인» 으로 두고 진행한다. 꼭 필요하면 /status 결과의 버전·이번 대화 줄만 부탁할 수 있다.