02-구조

02. 구조 — 권한·hook·CI의 3층

1층: 권한 (settings.json)

{
  "allowedTools": [
    "Bash(git status)", "Bash(git diff*)", "Bash(git log*)",
    "Bash(git add*)", "Bash(git commit*)",
    "Bash(git push origin HEAD*)",
    "Bash(gh pr create*)", "Bash(gh pr view*)", "Bash(gh issue list*)"
  ]
}

• Bash(git push *) 와일드카드는 위험 — --force나 다른 브랜치에 푸시 가능. Bash(git push origin HEAD*)로 좁힌다.
• 머지 명령(gh pr merge)은 화이트리스트에 넣지 않는다.

2층: hook

PreToolUse Bash hook이 다음을 차단:

• git push --force, git push -f
• git push origin main, git push origin master (보호 브랜치 직접 푸시)
• git reset --hard origin/main (덮어쓰기 실수)

PostToolUse (Edit/Write) hook이 자동 lint·포맷.

Stop hook이 변경된 파일에 대해 테스트 실행 (07장 run-tests.sh).

3층: CI (GitHub Actions)

claude-code-action 같은 액션을 쓰면 PR 코멘트나 라벨로 Claude를 트리거할 수 있다. 전형적 흐름:

1. PR 라벨 claude:fix 부여.
2. Action이 헤드리스 Claude 실행.
3. 새 커밋을 PR에 푸시.
4. CI 다시 돌아가고 상태 갱신.

이 흐름의 핵심:

• 로컬 권한과 별도의 CI 권한 프로파일 (03장 패턴 3).
• CI에서는 사람 승인 불가 → --max-turns, --permission-mode auto, 좁은 화이트리스트.

슬래시 명령으로서의 PR 워크플로우

/pr (04장 examples/pr.md)이 PR 본문을 생성한다. 본문은 Why → What → Test plan 3섹션이 표준. 에어비앤비식 대규모 마이그레이션의 경우 검증 단계가 PR 본문에 명시되어 있어야 리뷰어가 안심한다.