# Permission & CI Integrity Diagnosis Playbook

> 작업: task-2497 (운영 문서 / 감사 방법론) — Lv.1 read-only
> 목적: admin override / CI bypass / stale evidence / manual .done 위반을 진단하는 운영 플레이북
> 작성일: 2026-05-08
> 작성자: 비슈누 (개발4팀장, dev4-team)
> 회장 명시 본질: "운영 문서 / 감사 방법론만 허용. 코드 / 테스트 / PR / branch 변경 0건"

## 0. 본 플레이북의 전제 — 회장 명시 17 공통 금지

본 플레이북은 다음 행위를 **명시적으로 금지**한다 (실행 가이드가 아니라 진단 가이드):

- ❌ admin_override
- ❌ required_ci_bypass
- ❌ manual_done_creation
- ❌ stale_evidence_merge
- ❌ task-2487+1 / 오딘 세션 비개입 침범
- ❌ 코드 / 테스트 / PR / branch 수정 (read-only audit only)
- ❌ `.secrets/**`, `.github/workflows/**` 접근

본 플레이북은 위 위반을 **탐지**하고 **escalation 기준**을 제공한다. 실제 위반 해소 절차는 별도 task로 분리한다.

---

## 1. admin override 탐지 방법

### 1.1 정의

`admin override`는 GitHub branch protection / required checks / required reviews를 admin 권한으로 우회하여 PR을 머지한 행위.

### 1.2 탐지 신호 (모두 read-only API)

| 신호 | 확인 위치 | 위반 판정 |
|---|---|---|
| `merged_by` 가 admin user 본인 | `gh api repos/{owner}/{repo}/pulls/{pr}` 응답의 `merged_by.login` | bot 또는 reviewer 와 동일하지 않으면 의심 |
| `auto_merge` 부재 + admin 직접 merge | PR timeline `merged` 이벤트의 actor | bot이 아닌 admin이 머지한 경우 |
| `enforce_admins=false` | `gh api repos/{owner}/{repo}/branches/main/protection` | admin이 보호규칙을 우회 가능한 상태 자체가 위험 신호 |
| audit log `protected_branch.policy_override` | GitHub Audit log (Org/Enterprise) | 명시적 override 발생 |

### 1.3 read-only 확인 명령

```bash
# PR 머지 메타데이터
gh api repos/{owner}/{repo}/pulls/{pr_number} --jq '{merged_by: .merged_by.login, auto_merge: .auto_merge, merge_commit_sha: .merge_commit_sha}'

# branch protection 설정 (admin 우회 허용 여부)
gh api repos/{owner}/{repo}/branches/main/protection --jq '{enforce_admins: .enforce_admins.enabled, required_status_checks: .required_status_checks.contexts}'

# PR timeline에서 force / admin merge 이벤트 확인
gh api repos/{owner}/{repo}/issues/{pr_number}/events --jq '.[] | select(.event=="merged") | {actor: .actor.login, created_at: .created_at}'
```

### 1.4 사례 (PASS evidence — task-2485+1)

```json
{
  "merge_evidence": {
    "pr_number": 47,
    "merge_commit": "be8dcd21b04098832515fc949e902e93b53172da",
    "merge_method": "squash",
    "admin_override": false,
    "ci_bypass": false
  }
}
```

→ `admin_override: false` 가 명시적으로 박제된 경우 PASS.

### 1.5 자동화 가능성

- ✅ 자동화: `gh api` 호출 + jq 필터로 admin override 신호 자동 추출 가능
- ❗ 수동 판단 필요: admin이 의도적으로 override 했는지(예: 비상시 회장 승인) vs 우회인지의 의도 판정

---

## 2. CI bypass 탐지 방법

### 2.1 정의

`CI bypass`는 required checks (예: 11/11) 가 SUCCESS 상태가 아닌데도 PR을 머지한 행위.

### 2.2 탐지 신호

| 신호 | 확인 위치 | 위반 판정 |
|---|---|---|
| 머지 시점 required checks 불완전 | `commits/{merge_commit_sha}/check-runs` | 11/11 SUCCESS 미달 시 위반 |
| `mergeable_state=blocked` 인데 머지됨 | PR API `mergeable_state` (머지 직전 시점) | blocked 상태에서 머지 = bypass |
| required_status_checks 누락 | branch protection vs 실제 checks 비교 | required로 등록되지 않은 checks가 SUCCESS인 경우 |
| skip 키워드로 워크플로우 우회 | commit message `[skip ci]`, `[ci skip]` 등 | required 워크플로우가 실행되지 않으면 위반 |

### 2.3 read-only 확인 명령

```bash
# 머지 commit 의 check-runs 전체 상태 (11/11 검증)
gh api repos/{owner}/{repo}/commits/{merge_commit_sha}/check-runs --jq '{total: .total_count, runs: [.check_runs[] | {name, conclusion, status}]}'

# required checks 정의 vs 실제 conclusion 매핑
gh api repos/{owner}/{repo}/branches/main/protection/required_status_checks --jq '.contexts'

# PR 머지 직전 mergeable_state 박제 확인 (followup.txt 또는 .codex-gate 이벤트)
ls memory/events/{task_id}.codex-gate
```

### 2.4 자동화 가능성

- ✅ 자동화: required_status_checks 목록 추출 + check-runs conclusion 비교 → 11/11 자동 검증
- ❗ 수동 판단 필요: "11/11" 의 정확한 항목 정의 (프로젝트별로 다름) — branch protection 변경 이력 추적

---

## 3. stale evidence 탐지 방법

### 3.1 정의

`stale evidence`는 PR 머지 시점 기준으로 이미 outdated 된 commit/CI/리뷰를 evidence로 사용한 경우. 머지 후 main에 반영된 SHA와 evidence SHA가 불일치하면 stale.

### 3.2 탐지 신호

| 신호 | 확인 위치 | 위반 판정 |
|---|---|---|
| evidence SHA ≠ merge_commit_sha 의 fresh source | `fresh_evidence_sha` vs `merge_commit_sha` | 두 SHA의 시점 차이가 커지면 의심 |
| Gemini 리뷰 commit ≠ 최종 머지 head | `pulls/{pr}/reviews` 의 `commit_id` vs `pulls/{pr}.head.sha` | 리뷰 후 추가 commit 발생 시 stale |
| 머지 후 main HEAD가 evidence와 불일치 | `git ls-tree origin/main:path` vs evidence file | SSOT가 main에 미반영 |
| evidence 발행 시각이 머지 후 | `.essence-pass-*` 발행 timestamp > merged_at | 사후 evidence 의심 (단, ESCALATE 후 회장 결정에 의한 정당화는 예외) |

### 3.3 read-only 확인 명령

```bash
# evidence SHA가 main HEAD에 반영되었는지
gh api repos/{owner}/{repo}/contents/{path}?ref=main --jq '{sha, size, name}'

# 리뷰 commit_id vs 최종 head 비교
gh api repos/{owner}/{repo}/pulls/{pr}/reviews --jq '[.[] | {user: .user.login, commit_id, state}]'
gh api repos/{owner}/{repo}/pulls/{pr} --jq '.head.sha'

# evidence 파일 timestamp vs merge timestamp
stat -c '%y %n' memory/events/{task_id}.essence-pass-*
gh api repos/{owner}/{repo}/pulls/{pr} --jq '.merged_at'
```

### 3.4 사례 (PASS evidence — task-2485+1)

```json
{
  "fresh_evidence_sha": "359dd902",
  "ssot_main_reflected": {
    "file": "utils/task_id_parser.py",
    "size_bytes": 6394,
    "verified_against": "origin/main:HEAD"
  },
  "stale_evidence_merge": false
}
```

→ `verified_against: origin/main:HEAD` + `stale_evidence_merge: false` 가 명시되면 PASS.

### 3.5 자동화 가능성

- ✅ 자동화: SHA 비교, timestamp 비교는 스크립트화 가능
- ❗ 수동 판단 필요: ESCALATE 후 회장 결정에 의해 사후 evidence가 정당화된 경우 (예: ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION)

---

## 4. manual .done 탐지 방법

### 4.1 정의

`manual .done`은 finish-task.sh를 거치지 않고 사람/봇이 수동으로 `memory/events/{task_id}.done` 파일을 생성한 행위. QC + merge + timer end + notify 절차를 우회한다.

### 4.2 탐지 신호

| 신호 | 확인 위치 | 위반 판정 |
|---|---|---|
| `.qc-done` 마커 부재인데 `.done` 존재 | `memory/events/{task_id}.qc-done` vs `.done` | finish-task.sh 미통과 |
| `.merge-done` 마커 부재인데 `.done` 존재 | `memory/events/{task_id}.merge-done` | 머지 단계 누락 |
| `.done` 생성 시각이 보고서 작성 직후 (수초 내) | `stat .done` vs 보고서 mtime | 자동 워크플로우 흔적 부재 |
| `task-timer.py` end 호출 없이 `.done` 발행 | `memory/task-timers.json` 의 task end 기록 | timer 미종료 + .done 동시 = 수동 흔적 |
| git log 에 `[task-id] finish` 커밋 부재 | `git log --grep="{task_id}"` | finish-task.sh 가 자동 커밋 안 했음 |

### 4.3 read-only 확인 명령

```bash
# 마커 일치성 검사
ls memory/events/{task_id}.qc-done memory/events/{task_id}.merge-done memory/events/{task_id}.done 2>/dev/null

# 마커 생성 시각 비교
stat -c '%y %n' memory/events/{task_id}.{qc-done,merge-done,done,anu-notified} 2>/dev/null

# task-timer end 기록 확인
python3 -c "import json; d=json.load(open('memory/task-timers.json')); print(d.get('{task_id}', 'not found'))"

# 보고서 mtime vs .done mtime 차이
stat -c '%Y' memory/reports/{task_id}.md memory/events/{task_id}.done
```

### 4.4 PASS 패턴 (정상 finish-task.sh 통과)

정상 시퀀스:
1. `.qc-done` 생성 (QC 통과)
2. `.merge-done` 생성 (머지 또는 worktree 정리 완료)
3. `.done` 생성 (lifecycle close)
4. `.anu-notified` 생성 (아누 알림 발송)

→ 4 마커가 시간순으로 모두 존재하면 PASS. 일부 누락 + `.done` 단독 존재는 manual 의심.

### 4.5 자동화 가능성

- ✅ 자동화: 마커 존재 + 시각 순서 자동 검증 가능
- ❗ 수동 판단 필요: 회장이 의도적으로 수동 .done을 허용한 예외 케이스 (followup.txt 명시)

---

## 5. GitHub PR evidence 확인 절차

### 5.1 evidence 4종 (task-2485+1 표준)

| 항목 | 필드 | read-only API |
|---|---|---|
| pr_number | int | `pulls?head=...` 검색 |
| merge_commit | full SHA | `pulls/{pr}.merge_commit_sha` |
| merged_at | ISO 8601 | `pulls/{pr}.merged_at` |
| merge_method | merge / squash / rebase | `pulls/{pr}.merge_commit_title` 패턴 + `repos/{repo}.allow_squash_merge` |

### 5.2 절차

1. PR 번호 식별: 보고서 또는 `.followup.txt` 에서 추출
2. `gh api repos/{owner}/{repo}/pulls/{pr}` 호출 → 4종 evidence 추출
3. `merge_commit_sha` 가 main HEAD 또는 main history에 존재하는지 확인:
   ```bash
   git log origin/main --oneline | grep {merge_commit_sha:0:8}
   ```
4. `merged_at` 시각이 task lifecycle (timer start ~ end) 범위 내인지 확인
5. `merge_method` 가 프로젝트 정책(예: squash only)을 준수하는지 확인

### 5.3 누락 시 escalation

- PR 번호 없는 보고서 → `MERGE_PENDING_DEPENDENCY` / `DOGFOODING_PENDING` 분류 후보
- merge_commit_sha 없음 → 본질 미완료, ESCALATED 또는 OPEN
- `merged_at` ↔ timer 불일치 → manual .done 의심 → §4 절차로 검증

### 5.4 자동화 가능성

- ✅ 자동화: 4종 evidence 추출 + main reflection 검증 자동화 가능
- ❗ 수동 판단 필요: PR이 fork 또는 별도 repo에서 머지된 경우 (예: dev_workspace vs 운영 repo)

---

## 6. Gemini fresh evidence 확인 절차

### 6.1 정의

Gemini PR 리뷰가 **머지 head commit** 기준으로 발행되었음을 확인하는 절차. fresh = 머지 시점 commit과 일치, stale = 이전 commit 기반 리뷰.

### 6.2 절차

1. PR head SHA 추출:
   ```bash
   gh api repos/{owner}/{repo}/pulls/{pr} --jq '.head.sha'
   ```
2. Gemini 리뷰 목록 + 각 리뷰의 `commit_id` 추출:
   ```bash
   gh api repos/{owner}/{repo}/pulls/{pr}/reviews --jq '[.[] | select(.user.login | startswith("gemini")) | {commit_id, submitted_at, state}]'
   ```
3. 가장 최근 Gemini 리뷰의 `commit_id` 가 PR head SHA와 일치하는지 확인
4. 일치하면 fresh, 불일치 시:
   - 추가 commit이 리뷰 후 발생했는지 확인
   - 추가 commit이 trivial (포맷, 주석) 인지 substantive 인지 판단 → substantive 시 stale

### 6.3 fresh 판정 추가 조건

- 리뷰 state = `APPROVED` 또는 `COMMENTED` (CHANGES_REQUESTED 미해소 시 PASS 불가)
- High severity 코멘트 미수정 0건 (이미 워크플로우 4.7 룰)
- 리뷰 발행 시각이 PR 마지막 commit 시각 이후

### 6.4 사례 박제

- task-2485+1: `fresh_evidence_sha: "359dd902"` 명시 → fresh 인정
- task-2487 (REVIEW_OR_APPROVAL_PENDING_WITH_REGRESSION): `required_review_thread_resolution=true` 차단 → unresolved thread → fresh 미충족 → 머지 차단 (정상 동작)

### 6.5 자동화 가능성

- ✅ 자동화: commit_id 일치 검사, 시각 비교 자동화 가능
- ❗ 수동 판단 필요: 리뷰 후 추가 commit이 trivial vs substantive (코드 의미 변경 여부) 판단

---

## 7. merge commit / squash commit 검증 절차

### 7.1 merge_method 식별

| method | merge_commit_title 패턴 | parents 수 |
|---|---|---|
| `merge` | `Merge pull request #N from ...` | 2 |
| `squash` | PR 제목 또는 첫 commit 제목 | 1 |
| `rebase` | (없음) | 1 |

```bash
git cat-file -p {merge_commit_sha} | grep '^parent' | wc -l
```

### 7.2 정책 준수 검증

- 프로젝트 정책이 squash only인 경우:
  ```bash
  gh api repos/{owner}/{repo} --jq '{allow_merge: .allow_merge_commit, allow_squash: .allow_squash_merge, allow_rebase: .allow_rebase_merge}'
  ```
- `allow_merge_commit=false` 인 repo에서 merge commit이 발견되면 admin override 의심

### 7.3 squash commit 본질 검증

- squash merge는 `commit.message` 에 PR description이 포함됨
- 다음 항목이 commit message 또는 PR body에 포함되어야 audit 가능:
  - task_id (`[task-N]` 형식)
  - 본질 작업 요약
  - 테스트/CI 통과 표기

### 7.4 사례 (task-2485+1)

```json
{
  "merge_method": "squash",
  "merge_commit": "be8dcd21b04098832515fc949e902e93b53172da"
}
```

→ squash + 단일 parent 확인 + commit message에 task_id 포함 시 PASS.

### 7.5 자동화 가능성

- ✅ 자동화: parents 수 + 정책 매칭 자동화 가능
- ❗ 수동 판단 필요: squash commit message 가 본질 작업을 정확히 요약했는지 (의미 평가)

---

## 8. bot author 검증 절차

### 8.1 정의

본 시스템은 PR 발행자가 봇(bot)이어야 함을 원칙으로 한다. 사람 author PR 직접 머지 금지(회장 명시 task-2481R+1 본질 7개 조건 #4).

### 8.2 탐지 신호

| 신호 | 확인 위치 | 판정 |
|---|---|---|
| `pr.user.type == "Bot"` | `pulls/{pr}.user.type` | bot 인증 |
| `pr.user.login` 이 등록 봇 ID와 일치 | 봇 ID 화이트리스트 | bot 인증 |
| commits author email = bot service account | `pulls/{pr}/commits` 의 `author.email` | bot 인증 (verified=true 필수) |
| `merged_by` 가 bot 또는 auto_merge | `pulls/{pr}.merged_by`, `auto_merge` | merge actor 검증 |

### 8.3 read-only 확인 명령

```bash
# PR author + merge actor
gh api repos/{owner}/{repo}/pulls/{pr} --jq '{user: {login: .user.login, type: .user.type}, merged_by: {login: .merged_by.login, type: .merged_by.type}, auto_merge: .auto_merge}'

# 각 commit의 author/committer (verified signature 포함)
gh api repos/{owner}/{repo}/pulls/{pr}/commits --jq '[.[] | {sha: .sha[0:8], author: .commit.author.email, committer: .commit.committer.email, verified: .commit.verification.verified}]'
```

### 8.4 task-2483 사례 (참고)

```json
{
  "merged_by": "JonghyukJeon",
  "admin_override": false,
  "ruleset_bypass": false
}
```

→ `merged_by` 가 사람이지만 `admin_override=false` + `ruleset_bypass=false` 인 경우는 **bot author + 사람 merge actor** 케이스. task-2481R+1 본질 7개 조건 #4 ("사람 author PR 직접 머지 금지") 위반 여부는 **PR author** 기준으로 판단해야 함. merge actor가 사람인 것 자체는 위반이 아님.

### 8.5 자동화 가능성

- ✅ 자동화: user.type == "Bot" 검증, 화이트리스트 매칭 자동화 가능
- ❗ 수동 판단 필요: bot ID가 화이트리스트에 미등록인 경우 신규 봇인지 위장인지 판정 (token audit 별도 필요, `.secrets/**` 접근 금지로 본 플레이북 범위 외)

---

## 9. required checks 11/11 확인 절차

### 9.1 절차

1. branch protection 의 required check context 목록 추출:
   ```bash
   gh api repos/{owner}/{repo}/branches/main/protection/required_status_checks --jq '.contexts'
   ```
2. 머지 commit 기준 check-runs 전체 conclusion 추출:
   ```bash
   gh api repos/{owner}/{repo}/commits/{merge_commit_sha}/check-runs --jq '[.check_runs[] | {name, conclusion, status}]'
   ```
3. (1)의 모든 context 가 (2)에 존재 + conclusion = `success` 인지 매핑
4. 매핑 결과를 다음 표로 정리:

| required context | 실제 conclusion | PASS/FAIL |
|---|---|---|
| (예시) test-suite | success | ✅ |
| (예시) lint | success | ✅ |
| ... 11종 | ... | ... |

5. 11/11 SUCCESS 시 PASS, 미달 시 FAIL → §2 (CI bypass) 의심

### 9.2 사례 (task-2485+1)

```json
{
  "ci_status": "11/11 SUCCESS"
}
```

→ 필드 자체가 박제되어 있어 PASS. 단, "11" 의 정확한 항목 enum이 본 플레이북에서는 명시되지 않으므로, 실제 audit 시 (1)→(3) 매핑을 수행해야 함.

### 9.3 자동화 가능성

- ✅ 자동화: API 호출 + 매핑 자동화 가능
- ❗ 수동 판단 필요: required_status_checks 정의가 시간에 따라 변동된 경우(audit 시점 vs 머지 시점) 시점 기준 정합성 판단

---

## 10. 위반 발견 시 escalation 기준

### 10.1 4종 위반별 분류 매핑

| 위반 | 자동 분류 후보 | 회장 보고 필수 여부 |
|---|---|---|
| admin override | `WAITING_FOR_CHAIR_DECISION` | ✅ 필수 (정책 위반) |
| CI bypass | `WAITING_FOR_CHAIR_DECISION` 또는 `ESCALATED` | ✅ 필수 |
| stale evidence | `ESCALATED` (verifier 한계 시 `ESCALATED_VERIFIER_LIMITATION`) | 분류 결과에 따라 |
| manual .done | `ESCALATED` + manual creation 위반 박제 | ✅ 필수 (시스템 신뢰도 위반) |

### 10.2 escalation 트리거 임계값

다음 조건 중 **하나라도** 충족되면 즉시 escalation:

1. admin_override 신호 발견 + 회장 사전 승인 evidence 부재
2. required checks SUCCESS < 11/11 (또는 프로젝트별 합의 N/N)
3. evidence SHA ≠ main HEAD reflection (substantive 변경)
4. `.done` 존재 + (`.qc-done` 또는 `.merge-done`) 부재
5. PR author 가 사람이고 admin override 동시 발견 (이중 위반)

### 10.3 escalation 절차 (read-only)

본 플레이북은 read-only이므로 escalation은 다음 산출물로 종료:

1. 위반 사실 박제 evidence 파일 작성:
   ```
   memory/events/{task_id}.permission-ci-integrity-violation
   ```
   포맷:
   ```json
   {
     "task_id": "...",
     "violation_types": ["admin_override", "ci_bypass", "stale_evidence", "manual_done"],
     "evidence_sources": [...],
     "auto_detected": true|false,
     "manual_judgement_pending": [...],
     "next_action": "WAITING_FOR_CHAIR_DECISION"
   }
   ```
2. followup.txt 에 위반 요약 + 회장 결정 요청 명시
3. 후속 task 발행은 **회장 결정 후**에만 수행 (본 플레이북 단독으로 후속 task 자동 발행 금지)

### 10.4 escalation 금지 사항 (회장 명시)

- ❌ 위반 발견 시 자동 .done 변환 금지
- ❌ 위반 evidence 삭제 금지 (`.escalate`, `.done.escalated`, `.close-blocked-external` 등 모두 보존)
- ❌ 본 플레이북 내에서 코드 수정 / PR 발행 / branch 변경 금지
- ❌ task-2487+1 / 오딘 세션 영역 침범 금지

### 10.5 자동화 가능성

- ✅ 자동화: §1~§9 의 신호 자동 추출 → violation evidence 파일 자동 생성
- ❗ 수동 판단 필요:
  - admin override 의 의도 (예: 비상시 회장 승인) 판별
  - stale evidence 의 substantive vs trivial 판단
  - manual .done 의 회장 사전 허가 여부

---

## 11. 진단 항목 수 요약

| § | 항목 | 자동화 | 수동 판단 |
|---|---|---|---|
| 1 | admin override 탐지 | ✅ 부분 | 의도 판별 |
| 2 | CI bypass 탐지 | ✅ | 11/11 정의 시점 |
| 3 | stale evidence 탐지 | ✅ 부분 | substantive 판별 |
| 4 | manual .done 탐지 | ✅ | 회장 예외 판별 |
| 5 | GitHub PR evidence | ✅ | fork/별도 repo 케이스 |
| 6 | Gemini fresh evidence | ✅ 부분 | trivial vs substantive |
| 7 | merge / squash 검증 | ✅ | commit message 의미 |
| 8 | bot author 검증 | ✅ | 신규 bot ID 화이트리스트 |
| 9 | required checks 11/11 | ✅ | 시점 정합성 |
| 10 | escalation 기준 | ✅ | 회장 결정 |

**총 진단 항목 수**: 10개 (§1~§10)

---

## 12. evidence source 목록 (read-only paths)

본 플레이북이 참조하는 evidence source:

### 12.1 시스템 evidence (memory/events/)

- `memory/events/task-2485+1.essence-pass-escalated-verifier-limitation`
  → admin override 0 / CI bypass 0 / stale evidence 0 / manual .done 0 PASS 사례
- `memory/events/task-2483.close-blocked-external`
  → BOT token / merged_close_blocked 사례
- `memory/events/task-2486.*` (task-2486 lifecycle markers)
- `memory/events/task-248*.{qc-done,merge-done,done,anu-notified}`
  → finish-task.sh 정상 시퀀스 박제

### 12.2 분류 룰 (memory/feedback/)

- `memory/feedback/feedback_escalated_verifier_limitation_classification_260508.md`
- `memory/feedback/feedback_merged_close_blocked_external_classification_260507.md`
- `memory/feedback/feedback_merge_pending_dependency_classification_260507.md`

### 12.3 통합 항목 (memory/orchestration/)

- `memory/orchestration/phase_b_integration_items_260507.md`
  → 종료 분류 8종 + UNCLASSIFIED enum, classifier 룰

### 12.4 시스템 청사진

- `/home/jay/.claude/projects/-home-jay--cokacdir-workspace-autoset/memory/system_bot_orchestration_blueprint_260506.md`
  → 시스템 전체 봇 오케스트레이션 청사진

### 12.5 보고서 (memory/reports/)

- `memory/reports/task-2480.md` ~ `task-2489.md`
  → 머지 / lifecycle close / escalation 사례

### 12.6 GitHub API (read-only)

- `gh api repos/{owner}/{repo}/pulls/{pr}` — PR 메타
- `gh api repos/{owner}/{repo}/pulls/{pr}/reviews` — Gemini 리뷰
- `gh api repos/{owner}/{repo}/pulls/{pr}/commits` — commit author
- `gh api repos/{owner}/{repo}/commits/{sha}/check-runs` — CI 결과
- `gh api repos/{owner}/{repo}/branches/main/protection` — protection 정책

---

## 13. 자동화 가능 항목 / 수동 판단 필요 항목 요약

### 13.1 자동화 가능 (스크립트 또는 jq 필터로 처리 가능)

1. PR 메타데이터 추출 (`gh api` + jq)
2. merge_commit_sha vs main HEAD 매핑
3. check-runs conclusion 11/11 매핑
4. 마커 파일 존재 + 시각 순서 검증
5. evidence file mtime vs merged_at 비교
6. Gemini commit_id vs head.sha 일치 검사
7. user.type == "Bot" 검증
8. parents 수 (merge vs squash) 식별
9. required_status_checks contexts 매핑
10. violation evidence 파일 자동 생성 (회장 결정 전 read-only)

### 13.2 수동 판단 필요 (사람/회장 개입 필수)

1. admin override 의 비상 승인 여부 (예: 회장 명시 예외)
2. CI bypass 의 required checks 11/11 정의 시점 정합성
3. stale evidence 가 substantive vs trivial 판단
4. manual .done 의 회장 사전 허가 여부
5. fork 또는 별도 repo 케이스의 PR evidence 확장
6. Gemini 리뷰 후 추가 commit 의 의미 평가
7. squash commit message 의 본질 작업 요약 정확성
8. 신규 bot ID 의 화이트리스트 등록 판단
9. branch protection 변경 이력에 따른 시점별 11/11 재계산
10. 위반 발견 시 분류 결정 (`ESCALATED` vs `WAITING_FOR_CHAIR_DECISION` 등)

---

## 14. 사용 가이드

### 14.1 본 플레이북의 사용 시점

- PR 머지 후 lifecycle close 절차 audit 시
- task `.escalate` 발행 시 verifier 한계인지 본질 결함인지 분류 결정 시
- ROllup 보고 또는 회장 결정 요청 시 evidence 정리

### 14.2 본 플레이북이 다루지 않는 항목

- `.secrets/**` / `.github/workflows/**` 영역 — 별도 권한 필요
- 코드 수정 / 테스트 수정 / PR 변경 — 본 플레이북은 read-only
- task-2487+1 / 오딘 세션 영역 — 비개입
- 후속 task 자동 발행 — 회장 결정 후 별도 task

### 14.3 후속 작업 제안 (실행 금지, 제안만)

본 플레이북 정착 후 검토 가능:

1. §1~§9 의 자동화 항목을 통합한 `permission_ci_integrity_check.py` 자동 audit 스크립트 개발
2. dispatch.py / lifecycle classifier 와 연결 (Phase B 통합 항목 §2.1)
3. 위반 evidence → `WAITING_FOR_CHAIR_DECISION` 자동 분류 trigger
4. 대시보드 7섹션 보드 (Phase B §2.6) 와 연결한 위반 알림 패널

→ 위 4건은 **제안**일 뿐, 본 task에서 실행하지 않는다 (회장 명시 7 공통 완료 조건 #7).

---

## 15. 회장 명시 본질 5항목 (완료 보고용)

| 항목 | 값 |
|---|---|
| 문서 경로 | `memory/orchestration/playbooks/permission-ci-integrity-diagnosis.md` |
| 진단 항목 수 | 10개 (§1~§10) |
| evidence source 목록 | §12 (총 6 카테고리) |
| 자동화 가능 항목 | §13.1 (10건) |
| 수동 판단 필요 항목 | §13.2 (10건) |

---

## 16. 회장 명시 7 공통 완료 조건 (자체 검증)

- ✅ 코드 변경 0건 (마크다운 1개 파일만 생성)
- ✅ 테스트 변경 0건
- ✅ PR 변경 0건
- ✅ branch 변경 0건
- ✅ 오딘 task-2487+1 비개입 (참조도 안 함)
- ✅ 산출물 문서 경로 제출 (§15 명시)
- ✅ 후속 작업 제안만 (§14.3) — 실행 금지 준수

---

> 끝.