계획을 먼저 작성한다.

1. 인증 모듈에서 바꿀 파일과 public API 영향을 나눈다.
   검증: 현재 API contract와 실패 재현을 기록한다.
2. 내부 구현을 바꾸고 관련 test를 통과시킨다.
   검증: auth test와 type check가 통과한다.
3. 호출부와 문서를 정리한다.
   검증: build, git diff, public API 비교를 끝낸다.

완료: 세 단계의 검증 evidence가 있고, 배포 전 review에서 범위 밖 변경이 없다.

계획에서 먼저 닫을 것

먼저 결과를 한 문장으로 적고, 포함·제외 범위를 파일, API, data, environment 단위로 나눕니다. 그다음 제약을 적습니다. 예를 들어 migration을 하지 않음, public API를 유지함, production credential을 쓰지 않음, push하지 않음은 구현 방법보다 먼저 확정해야 하는 조건입니다.

완료 기준은 마지막에만 쓰는 build 성공 한 줄이 아닙니다. 각 단계가 성공했음을 보여 줄 검증 명령이나 검토 대상을 붙입니다. 관련 test는 통과했지만 public API가 달라졌다면 그 milestone은 완료가 아닙니다. 반대로 모든 test가 오래 걸리는 repository라면 관련 test부터 실행하고, 마지막 단계에서 넓은 build·회귀 test를 수행하도록 순서를 명확히 합니다.

milestone을 실행 단위로 만들기

milestone 하나는 독자가 review할 수 있을 만큼 작고, 결과를 증명할 수 있을 만큼 커야 합니다. "인증 전체를 리팩터링"은 너무 넓고, "함수 한 줄의 공백을 수정"은 계획 단위가 되기 어렵습니다. interface 정리, 내부 구현 변경, 호출부 전환처럼 실패해도 경계가 남는 단위가 좋습니다.

각 milestone에는 수정 책임과 확인 책임을 짝으로 둡니다. 여러 task를 병렬로 돌릴 때는 같은 파일·lockfile·migration을 둘 이상에게 맡기지 않습니다. 안전한 checkpoint가 필요하면 commit 자체를 성공 조건으로 넣을 수 있지만, commit과 push는 별도 동작이므로 사용자의 승인 없이 push까지 포함하지 않습니다.

Definition of Done으로 종료를 막기

Definition of Done은 산출물 개수 대신 확인 가능한 상태로 씁니다. “문서 보강 완료”보다 “각 카드의 Quick surface가 독립적으로 판단 가능하고, 공식 reference·content check·build가 통과함”이 종료를 판정하기 쉽습니다. 작업 중 범위가 바뀌면 새 조건을 follow-up message로 추가하고, 기존 DoD 중 더 이상 성립하지 않는 항목은 명시적으로 바꿉니다.