검토 순서
1. Git status와 scope를 확인한다.
2. diff에서 요청 범위 밖 파일, secret, lockfile, generated output을 찾는다.
3. line comment 또는 follow-up으로 수정 근거를 묻는다.
4. 관련 검증을 통과한 chunk만 stage·commit 대상으로 판단한다.

review pane이 읽는 Git 상태

desktop app의 review pane은 working tree 전체의 Git 상태를 반영합니다. Unstaged는 기본 화면이고, Staged, Commit, Branch, Last turn으로 범위를 좁힐 수 있습니다. 여러 Git repository가 붙은 local project라면 repository selector에서 어느 repository를 검토할지 선택해야 합니다.

/review는 base branch 비교나 uncommitted changes 검토를 시작하고 prioritized finding을 보고합니다. review는 working tree를 고치지 않습니다. finding을 실제로 적용해 달라고 요청하면 일반적인 sandbox와 approval policy가 다시 적용되므로, review가 읽기 전용이었다고 수정도 무조건 안전한 것은 아닙니다.

"main과 현재 branch를 비교해 review해 주세요.
API response 형식과 error handling만 검토하고,
기존 dirty file은 이번 변경으로 취급하지 마세요."

stage·revert·commit의 판단

review pane에서 stage나 revert를 할 수 있어도, 먼저 변경 ownership과 test evidence를 확인합니다. 한 파일에 의도한 수정과 임시 debug code가 섞였다면 전체 파일을 stage하지 않고, 무엇을 남길지 분리한 뒤 관련 test를 다시 실행합니다. revert는 작업을 되돌릴 수 있으므로 assistant가 만든 변경인지, 사용자가 진행 중인 변경인지 확인하지 않은 채 사용하면 안 됩니다.

commit과 push는 같은 검토 단계가 아닙니다. commit은 local history를 만드는 행위이고, push는 remote branch를 변경합니다. review pane에서 둘 다 다룰 수 있더라도, push와 pull request 생성은 repository 권한·remote 상태·팀 절차에 따라 달라지므로 사용자의 명시적 요청과 확인이 필요합니다.

terminal로 넘길 작업

rebase, reflog 조사, 복잡한 cherry-pick, conflict resolution처럼 Git history 자체를 조작하는 작업은 통합 terminal에서 명령과 현재 branch를 명확히 보며 처리하는 편이 낫습니다. app의 review pane은 변경을 읽고 선택하는 데 강하고, 복잡한 이력 수술의 안전성을 대신 보장하지 않습니다.