# GEMINI_EVIDENCE_BASED_RESOLVE_RUNNER — 자동화 후보 (2026-06-01)

> 회장 지시(2026-06-01): PR #166 P0-a 수렴 과정에서 ANU 가 high/medium finding 을 **severity 가 아니라 evidence 기반**으로 판정해 resolve/dismiss/중단한 사례를 자동화 후보로 기록.
> ★ **구현은 PR #166 에 섞지 말 것.** PR #166 = P0-a 수렴만. 본 resolver 자동화는 **별도 후속 task 후보**(회장 인가 전 구현/PR/push 0).
> 배경: PR #163/#164/#165/#166 에서 반복된 패턴 — Gemini stale 재코멘트 / 회장 설계 방향과 반대 제안(design-intent) / style-only / over-engineering 을 ANU 가 수동 판별. 이를 deterministic runner 로 코드화.

## 목표
Gemini unresolved finding 을 **evidence 기반 deterministic 판정** → AUTO_RESOLVE 가능분만 GitHub/Gemini thread resolve, 코드 변경 필요분은 즉시 중단 보고. "Gemini suggestion 맹목 추종" 방지.

## 초안 요구사항 (회장 verbatim)
1. unresolved thread 수집 + `finding_key` 정규화 (path+normalized-semantic, 라인이동·중복 흡수).
2. **Critical7 우선 판정** (security/credential/forbidden 등 → HOLD_CRITICAL7, resolve 금지).
3. **회장 decision registry 조회** — 이미 내린 설계 결정(예: lock 단순화 ②)과 반대되는 finding = design-intent dismiss.
4. **deterministic probe 실행** — finding 별 실증(예: 타임존 파싱 PASS / lock 로직 grep 0 / regression PASS).
5. 판정 enum:
   - `AUTO_RESOLVE_STALE` (코드가 이미 해소, probe PASS — 예: 타임존 fromisoformat fix 후 +09:00 파싱 PASS)
   - `AUTO_RESOLVE_DESIGN_INTENT` (회장 결정과 반대 제안 — 예: lock 단순화 결정 후 token 검증 재도입 제안)
   - `AUTO_RESOLVE_STYLE_ONLY` (style/over-engineering/perf, 동작 영향 0)
   - `NEEDS_CODE_FIX` (실 결함 — 예: 209 liveness. 즉시 중단)
   - `LOOP_BOUNDARY` (bounded fix 소진 후 새 high 반복)
   - `HOLD_CRITICAL7`
6. **evidence 없이 dismiss 금지** — 각 AUTO_RESOLVE 는 probe/registry 근거 첨부 필수.
7. **AUTO_RESOLVE_* 만 GitHub/Gemini resolve** (NEEDS_CODE_FIX/LOOP/HOLD 는 resolve 0).
8. **코드 변경 필요 finding 발견 시 즉시 중단** (RESOLVE_FAILED_NO_CODE_CHANGE).
9. **최종 상태 MERGE_READY_CANDIDATE 까지만 보고**. merge 회장 승인 전 금지.

## 구현 후보 (별도 task 인가 시)
- `anu_v3/gemini_evidence_resolve_runner.py` (또는 anu_v2/) — read-only finding 수집 + 판정 + (인가 시) OWNER resolve.
- decision registry: `memory/state/chair_design_decisions.jsonl` (회장 설계 결정 누적 — lock 단순화/result-JSON-only 등).
- probe registry: finding_key → deterministic check 매핑.
- regression: 6 enum 각 fixture + evidence 없는 dismiss reject + Critical7 우선 + 코드변경필요 시 중단.

## 실증 사례 (PR #166, 박제)
- `484` 타임존 high → `AUTO_RESOLVE_STALE` (fromisoformat fix + `+09:00` 파싱 PASS 직접검증, regression 32)
- `381` lock token high → `AUTO_RESOLVE_DESIGN_INTENT` (회장 ② lock 단순화 결정과 반대 제안)
- `1560/229/242/354/333` medium → `AUTO_RESOLVE_STYLE_ONLY` (observability/perf/style/edge, 동작 영향 0)
- `209` medium → `NEEDS_CODE_FIX` (lock 누수→pickup 영구차단 liveness 결함 → 즉시 중단 → task-2720+3 lock 완전제거)

## 분리 원칙
PR #166 = P0-a callback wake 수렴만(expected_files 5). resolver runner 구현은 본 후보 인가 후 별도 task(예: task-272X) — 회장 승인 전 구현/PR/push 0. capability matrix 후보로 등재(현재 = MISSING / 후보).