# task-1968: Gemini PR 리뷰 피드백이 자동 적용/강제되지 않는 원인 심층 분석

## 문제 현상
- task-1964에서 Gemini가 CRITICAL 1건 + HIGH 3건 + MEDIUM 3건을 지적
- 그러나 팀장(헤르메스)이 "High 0건, 기존 코드 개선 제안"으로 분류하고 전부 무시
- PR은 그대로 머지됨
- **시스템이 Gemini의 CRITICAL/HIGH를 자동으로 차단하지 못함**

## 핵심 질문
**왜 우리 시스템에서 Gemini PR 리뷰 결과를 자동으로 확인/체크해서 강제 수정 또는 머지 차단을 하지 않는가?**

## ★★★ 이 작업은 분석/리서치만. 코드 수정 없음. ★★★

## 분석 대상 파일 (전수 확인 필수)

### 1. Gemini 리뷰 파싱 로직
- `/home/jay/workspace/scripts/worktree_manager.py`
  - `_parse_gemini_comments()` 함수: severity 어떻게 파싱하는지
  - `finish()` 함수: Gemini 리뷰 결과를 어떻게 사용하는지
  - `gemini_timeout`, `collect_mode` 파라미터 동작
  - "High 0건 시 자동 머지" 로직이 실제로 어떻게 동작하는지

### 2. G3 머지 게이트
- `/home/jay/workspace/scripts/g3_independent_verifier.py`
  - Gemini 리뷰 결과를 확인하는 로직이 있는지
  - 없다면 왜 없는지

### 3. 팀장 워크플로우
- `/home/jay/workspace/prompts/DIRECT-WORKFLOW.md`
  - Gemini 리뷰 후 수정 의무가 명시되어 있는지
  - HIGH/CRITICAL 시 머지 차단 규칙이 있는지
  - 팀장이 severity를 재분류할 수 있는 허점이 있는지

### 4. QC 파이프라인
- `/home/jay/workspace/teams/shared/qc_verify.py`
  - Gemini 리뷰 결과를 검증하는 체크가 있는지
- `/home/jay/workspace/teams/shared/QC-RULES.md`
  - Gemini 리뷰 관련 규칙

### 5. 실제 사례 분석
- task-1964 보고서: `/home/jay/workspace/memory/reports/task-1964.md`
  - "High 0건"이라고 보고한 근거는 무엇인지
  - _parse_gemini_comments의 파싱 결과와 실제 Gemini 리뷰의 괴리
- InsuRo PR #1의 실제 Gemini 코멘트: `gh pr view 1 --repo JonghyukJeon/InsuRo` 확인

## 분석 항목

### A. 파싱 정확도
- `_parse_gemini_comments()`가 "security-critical", "high", "medium"을 정확히 감지하는가?
- Gemini의 실제 코멘트 포맷과 파서의 기대 포맷이 일치하는가?
- 파싱 실패 시 기본값이 "low"로 떨어지는지 (false negative)

### B. 강제 메커니즘 부재
- Gemini High가 감지되었을 때 머지를 실제로 차단하는 코드가 있는가?
- `collect_mode=True`일 때 수정 루프가 동작하는가? 아니면 수집만 하고 무시하는가?
- 팀장이 Gemini 결과를 override할 수 있는 경로가 있는가?

### C. 보고서 거짓말 방지
- 팀장이 "High 0건"이라고 보고하면 시스템이 실제 Gemini 코멘트와 교차 검증하는가?
- qc_verify.py에 Gemini severity 교차 검증 체크가 있는가?

### D. 자동 수정 루프
- Gemini가 Suggested Change를 제시한 경우, 자동 적용하는 메커니즘이 있는가?
- 없다면, 왜 없는지 (설계 의도 vs 구현 누락)

### E. 다른 프로젝트(워크스페이스)에서는 어떻게 동작하는지
- 워크스페이스 repo의 PR들에서 Gemini 리뷰가 어떻게 처리되었는지 사례 확인

## 산출물
보고서: `memory/reports/task-1968.md`

### 보고서 형식
1. **근본 원인 분석** (Root Cause Analysis)
   - 1차 원인: [파싱 실패 / 강제 미구현 / 워크플로우 허점 / 기타]
   - 2차 원인: ...
   - 근본 원인: ...
2. **현재 시스템의 Gemini 리뷰 처리 흐름도** (단계별)
3. **허점 목록** (exploit 가능한 경로)
4. **개선 방안 제안** (코드 수정 없이 분석만)
   - 단기: 즉시 적용 가능한 규칙/설정 변경
   - 중기: 코드 수정이 필요한 개선
   - 장기: 아키텍처 변경이 필요한 개선

## 검증 시나리오
1. _parse_gemini_comments()에 실제 Gemini 코멘트를 입력했을 때 올바른 severity 반환하는지 로직 트레이싱
2. finish() 함수에서 High 감지 시 실제 차단되는지 코드 흐름 추적
3. task-1964 사례에서 정확히 어느 지점에서 "High 0건"으로 잘못 판정되었는지 특정

## 레벨
- critical (시스템 안전성)

## 프로젝트
- dev-system