# ★★ 위협도 등급 구분 doctrine — hygiene ≠ 보안사고 (회장 2026-06-09 verbatim)

## 핵심
**hygiene 이슈와 실제 보안사고를 동일 등급으로 취급하지 말 것.** 발견 즉시 최상위 blocker 로 격상하기 전에, **먼저 위협모델과 실제 영향 범위를 정량화**한다.

## 판단 순서 (회장 선호)
**위협도 → 영향 범위 → 수정 범위** 순서로 판단. (역순 금지: "발견 → 즉시 최상위 blocker → 과투자")

## 3등급 구분 (이번 raw key 사례 실증)
1. **로컬 operational log hygiene** (예: `/home/jay/.cokacdir/schedule_history`, `system_prompt_*` 의 owner_key literal)
   - git 추적 0·workspace 밖·로컬 단일사용자 머신. 외부 직접 경로 없음. **회장 머신 선침해 후 2차 발견** 모델.
   - 키 성격 = 로컬 cokacdir 봇 토큰(외부 클라우드 자격증명 아님). 침해 영향 = 회장 텔레그램 봇 인프라 한정.
   - → **심각 보안사고 아님. backlog 강등 가능.** (OPERATIONAL_LOG_KEY_LITERAL_HYGIENE_BACKLOG)
2. **private repo 노출** (PR diff raw key, private GitHub)
   - 공개 아님. **GitHub 계정/이메일 선침해 후 2차 발견** 모델. 단 협업자·조직·GitHub 인프라 제3자 신뢰경계 존재.
   - → **저비용 hard gate 유지**(마스킹/denylist 한 줄). 싼 보험.
3. **production credential 노출** (외부 공개 경로 / 권한 확장 / credential 재사용 / production activation 영향)
   - → **지금처럼 보수적 대응**(외부 공개 경로·권한확장·재사용·activation 영향 시).

## 적용 규칙
- 1·2·3 등급을 동일 취급 금지. 1은 강등, 2는 저비용 게이트, 3은 보수적.
- 보수적 대응 trigger: **외부 공개 경로 / 권한 확장 / credential 재사용 가능성 / production activation 영향** 중 하나라도 있으면.
- 그 외(로컬 단일사용자 hygiene)는 정량화 후 backlog 가능.

## 이번 사례 = 좋은 수렴 (회장 긍정 평가)
- raw key hygiene 이 production blocker 까지 확대됐다가, **위협도 재평가로 실제 리스크·투자 규모를 다시 맞춤**.
- "canary 조건 위반 → preflight HOLD" 판단 = 맞음(lock 준수).
- 이후 "실제 위협도 재평가 → 최소 hygiene patch(owner_key 1줄 제거)" 수렴 = 적절.
- 교훈: lock 위반 시 멈추는 건 옳되, **그 lock 의 엄격도 자체를 위협모델에 맞게 재산정**하는 것도 ANU 역할.

## 단일소스
이 doctrine. 실증: task-2729+24(PR #196 owner_key 1줄 제거) + canary preflight HOLD → 위협도 강등 흐름.