# 이슈 기반 개발 흐름

## 흐름 한눈에

```
이슈 등록 → 브랜치 생성 → 개발(커밋에 이슈 번호) → 검증 → 결과 코멘트 → 이슈 닫기
```

| 단계 | 할 일 | 왜 |
|---|---|---|
| 1. 이슈 등록 | **개발 전에** 무엇을·왜 하는지 적는다 | 나중에 "이 코드는 왜 이렇게 됐나"를 찾을 출발점 |
| 2. 브랜치 | 이슈 단위로 기능 브랜치를 만든다 | 작업 범위를 분리 |
| 3. 커밋 | 커밋 메시지에 이슈 번호(`#123`)를 적는다 | 이슈 ↔ 코드 변경을 양방향으로 추적 |
| 4. 검증 | 성공 기준을 확인한다 | "된 것 같다"와 "확인했다"를 구분 |
| 5. 결과 코멘트 | 무엇을 바꿨고 어떻게 확인했는지 이슈에 적는다 | 리뷰어·후임자가 근거를 바로 확인 |
| 6. 닫기 | 검증이 끝난 뒤에 닫는다 | 열린 이슈 = 남은 일 |

## 이슈 작성 요령

```markdown
## 현상
예약세척 취소 직후 로봇 우유밀기 요청이 계속 거부됨.

## 근거
- 2026-09-29 22:12 취소 → 22:26 까지 거부 응답 57회 (로그 원문 첨부)

## 기대 동작
시작 전 취소(진행 시간 0)는 잔류수가 없으므로 밀기를 막지 않는다.

## 성공 기준
- 시작 전 취소 시 차단 상태가 걸리지 않는다
- 기존 진행 중 취소는 그대로 차단된다
```

- **사실과 추정을 분리**합니다. 추정은 "~로 보입니다"로 표시합니다.
- 로그 근거는 **시각과 원문**을 인용합니다.
- 비밀값·개인 연락처·고객 식별 정보는 적지 않습니다.

## 성공 기준을 먼저 정한다

"고쳐 줘"는 확인할 방법이 없습니다. 확인 가능한 목표로 바꿔서 시작합니다.

| 막연한 요청 | 확인 가능한 목표 |
|---|---|
| 입력 검증 추가 | 잘못된 입력에 대한 테스트를 쓰고, 그 테스트가 통과하게 한다 |
| 버그 수정 | 버그를 재현하는 테스트를 쓰고, 통과하게 한다 |
| 리팩터링 | 변경 전후로 같은 테스트가 통과한다 |

## 결과 코멘트 예

```markdown
## 결과
- 시작 전 취소(진행 시간 0)는 차단을 걸지 않도록 판정 수정 (커밋 abc1234)
- 진행 중 취소는 기존대로 차단

## 확인
- 재현 시나리오 2종 실측: 시작 전 취소 → 밀기 허용 / 진행 중 취소 → 차단 유지
- 미확인: 실제 현장 장비에서의 장시간 동작 (다음 방문 시 확인)
```

- **확인하지 않은 범위는 "미확인"으로 적습니다.** 확인하지 않은 것을 확인했다고 쓰지 않습니다.

## 남은 일 목록 (TODO)

여러 단계로 나뉘는 작업은 저장소의 남은 일 목록(예: `TODO.md`)에 항목을 적어 두고, 끝나면 지웁니다. 이력은 이력 파일에 남기고, 목록에는 **지금 남은 일만** 둡니다.

| 표기 | 뜻 |
|---|---|
| `[ ]` | 미착수 |
| `[~]` | 진행 중 |
| `[?]` | 확인·회신 대기 |

> 왜 — 작업이 중간에 끊겨도, 다른 사람이 이 목록만 보고 이어받을 수 있어야 합니다.