1. 재현: 어떤 입력·명령·환경에서 실패하는지 먼저 고정한다.
2. 수정: 바꿀 파일과 금지할 변경을 정해 최소 변경을 만든다.
3. 검증: 관련 test·lint·type check를 실행하고 실패 원인을 분리한다.
4. 범위 확인: git diff와 Git status로 의도하지 않은 파일을 찾는다.
5. review: 필요한 범위만 /review 또는 codex review에 맡기고 finding의 근거를 확인한다.

# CLI에서 변경하지 않는 review를 실행한다.
codex review

# 현재 작업 트리의 변경 범위를 직접 확인한다.
git status --short
git diff --check
git diff -- Web/components/checkout

재현과 검증을 분리하는 이유

재현은 “무엇이 실패했는가”를 고정하고, test는 “수정 뒤에도 그 조건이 만족되는가”를 확인합니다. 둘을 하나로 뭉뚱그리면 특정 test가 통과했어도 실제 사용자 증상이 사라졌는지 알 수 없습니다. 버그 수정 요청에는 입력, 기대 결과, 실제 결과, 실행 명령 또는 화면 경로를 남깁니다.

검증은 가장 관련된 명령부터 시작합니다. feature test 또는 type check가 실패하면 전체 suite 결과보다 먼저 그 오류를 이해합니다. 관련 검증이 통과한 뒤에는 build, integration test, lint처럼 회귀를 찾는 넓은 검증으로 확장합니다. 기존 실패가 섞인 repository에서는 “이번 변경 전에도 실패했는가”를 분리해 보고해야 합니다.

diff와 review의 범위

git diff는 test가 다루지 못하는 변경 범위를 보여 줍니다. renamed file, 설정 파일, generated output, lockfile, secret처럼 요청과 직접 관련 없는 파일이 섞였는지 확인합니다. working tree가 이미 dirty라면 Codex가 만들지 않은 변경도 review pane과 uncommitted review 범위에 같이 나타날 수 있으므로, review 전에 baseline과 책임 범위를 기록합니다.

Git repository 안에서 /review를 실행하면 app, interactive CLI, IDE extension에서 base branch, uncommitted changes, commit 등의 scope를 고를 수 있습니다. app의 review pane은 unstaged, staged, selected commit, base branch diff, last turn처럼 Git 상태 전체를 보여 줄 수 있습니다. 특정 assistant turn만 믿지 말고, 어떤 Git scope를 읽는지 명시해야 합니다.

review 요청 예시
"현재 branch를 main과 비교해 review해 주세요.
특히 timeout 오류 처리와 public API 변경만 보고,
findings에는 파일·라인·재현 근거를 포함해 주세요.
working tree는 수정하지 마세요."

finding을 수정하기 전 확인할 것

review finding은 즉시 수정 목록이 아닙니다. 먼저 해당 파일과 line context, 재현 가능성, 기존 설계 의도를 확인합니다. finding이 맞으면 관련 test를 추가하거나 넓히고, 맞지 않으면 근거와 함께 제외합니다. review 후 후속 수정은 새 diff가 되므로, 마지막 diff 검사와 관련 검증을 다시 실행합니다.