# ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION — Incident Taxonomy

작성: 2026-05-08
작업: task-2496 (dev3-team / 다그다)
근거: 회장 명시 (2026-05-08T04:10), task-2485+1 박제 사례

---

## 1. 분류명

**ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**

---

## 2. 정의

task 본질 합격 조건을 100% 충족하고 PR 머지까지 완료됐으나, 자동화 verifier가 SSOT(단일 진실 공급원)를 참조하지 않는 자기참조 결함 또는 작업 유형 부적합 적용으로 인해 task_id 자체를 거부함으로써 ESCALATE 마커가 발행된 상태. 본질 평가 surface와 verifier 결함 surface를 분리하여, 본질은 PASS 인정하고 verifier 결함 해소는 후속 task로 이관한다.

---

## 3. 적용 조건 (When to apply — 5항목 AND)

다음 **모든** 조건을 충족할 때만 적용한다:

1. ✅ **본질 합격 100%** — 회장 명시 합격 조건 전체 PASS (8/8 등 명시된 기준 전부)
2. ✅ **회장 명시 금지 위반 0건** — non_minimal_code_change, admin_override, ci_bypass 등 회장 명시 금지 사항 위반 없음
3. ✅ **CI / 머지 / fresh evidence / 핵심 산출물 모두 PASS** — CI 전체 SUCCESS, PR squash merge 완료, fresh evidence sha 갱신, SSOT 메인 반영 확인, L1 smoke PASS
4. ❗ **ESCALATE 사유가 verifier 자체 결함** — task 본질 실패가 아닌 verifier 내부의 SSOT 미참조, 자기참조 regex, 작업 유형 부적합 적용 중 하나
5. ❗ **verifier 결함 해소가 본 task 작업 영역 외** — allowed_resources 범위 밖이거나 non_minimal_code_change 룰 등 회장 명시 제약으로 인해 본 task 내에서 수정 불가

---

## 4. 비적용 조건 (When NOT to apply)

다음 중 하나라도 해당하면 본 분류를 적용하지 않는다:

- 본질 합격 조건 미달 (회장 명시 기준 중 하나 이상 불충족)
- CI 결함 또는 fresh evidence 미갱신 등 본질 단계 자체 문제
- PR 머지 미완료 (OPEN 또는 CLOSED without merge)
- admin_override=true 또는 ci_bypass=true 사용
- verifier 결함 해소가 본 task allowed_resources 범위 내인 경우 (scope 내 수정 가능하면 수정하고 재검증 후 DONE 처리)
- ESCALATE 원인이 verifier 이외의 본질 결함 (코드 오류, 산출물 누락, 회장 조건 미달 등)
- verifier 결함을 본 task에서 수정 시 회장 금지 위반이 발생하지 않는 경우

---

## 5. verifier 자체 결함 정의

다음 중 하나에 해당하면 verifier 자체 결함으로 분류한다:

- **자기참조 결함**: verifier가 SSOT(단일 진실 공급원, 예: `utils/task_id_parser.py`)를 import하지 않고 자체 regex/로직을 보유하여 SSOT와 불일치 발생
- **task_id 형식 거부**: verifier의 자체 regex가 특정 task_id 형식(예: `+` suffix)을 지원하지 않아 task_id 자체를 거부 (예: `r'^task-\d[\w.\-]*$'`가 `task-2485+1` 거부)
- **작업 유형 부적합 강제 적용**: verifier가 본 task의 실제 작업 유형(예: lifecycle 처리, 코드 변경 0)에 적합하지 않은데도 강제 적용됨 (예: 브라우저 작업이 없는 task에 browser_verify 적용)
- **scope 위반 없이는 수정 불가**: verifier 결함 수정이 allowed_resources 범위 밖이거나 non_minimal_code_change 등 회장 명시 룰 위반 없이는 본 task 내 수정 불가

---

## 6. task 본질 PASS와 verifier FAIL의 분리 기준

**평가 surface 분리 원칙**:

- **본질 합격 surface**: 회장 명시 합격 조건의 충족 여부. 산출물, 코드 변경, CI 결과, PR 머지, SSOT 메인 반영, L1 smoke 등 task 명세에 직접 명시된 기준
- **verifier FAIL surface**: 자동화 verifier 자체의 결함 신호. SSOT 미참조, 자체 regex 오류, 작업 유형 부적합 적용으로 인한 거부

**분리 기준**:

- 본질 합격 = 회장 명시 조건을 만족했는가의 독립 판단
- verifier FAIL = verifier 내부 결함에서 비롯된 신호이며, 본질 합격 판단에 영향을 주지 않음
- verifier가 task_id를 거부했다는 사실이 task 본질 실패를 의미하지 않는다
- 헤르메스가 `non_minimal_code_change` 금지를 준수하여 verifier를 수정하지 않은 판단은 타당하며, 이를 본질 실패로 재분류하면 안전한 작업 패턴이 잘못 학습됨

---

## 7. 기존 분류와의 차이

### 7.1. FAILED_PREEXISTING과의 차이

- **FAILED_PREEXISTING**: 본 task와 무관한 기존 결함(main branch의 lint/test 실패 등)이 본 task 진행 자체를 차단하는 경우. 본 task 작업 이전부터 존재하던 외부 결함
- **ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**: 본 task의 task_id(`task-2485+1`)가 verifier에 의해 거부된 자기참조 결함. 결함 자체가 본 task를 대상으로 발생하며, 본 task의 작업 완료 이후 verifier가 task_id를 인식 못 하는 형태

핵심 차이: FAILED_PREEXISTING은 본 task 작업과 독립적으로 존재하는 사전 결함이고, 본 분류는 verifier가 본 task의 task_id 형식 자체를 거부하는 자기참조 구조 결함이다.

### 7.2. BLOCKED_BY_EXTERNAL_DEPENDENCY와의 차이

- **BLOCKED_BY_EXTERNAL_DEPENDENCY**: 외부 시스템(API, infra, 3rd party service, ruleset)의 불가용 상태가 본 task 진행을 차단. 외부 서비스 복구 시 차단 해소
- **ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**: verifier 자체 결함 — 외부 서비스 장애가 아닌 *내부* tooling(verifier 코드)의 구조 결함. 외부 서비스와 무관하며, verifier SSOT 위임 hardening으로만 해소 가능

핵심 차이: BLOCKED_BY_EXTERNAL_DEPENDENCY는 외부 인프라/서비스 의존이고, 본 분류는 내부 verifier 코드 자체의 self-reference 구조 결함이다.

### 7.3. DOGFOODING_PENDING과의 차이

- **DOGFOODING_PENDING**: 자기검증(dogfooding) layer의 외부 인프라 의존(BOT 토큰 갱신, ruleset 미적용, approval 부재 등)으로 인해 본질 PASS 판정을 유보하는 상태. 아직 머지가 완료되지 않은 경우 포함
- **ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**: 본질 PASS + PR 머지까지 완료된 상태에서 verifier 자체 코드 결함(SSOT 미참조 regex)만 남은 케이스. 인프라 의존 문제가 아닌 verifier 코드 내부 결함

핵심 차이: DOGFOODING_PENDING은 자기검증 layer의 외부 인프라 의존으로 PASS 판정 유보 중이고, 본 분류는 이미 본질 PASS + 머지 완료 후 verifier 코드 결함 신호만 남은 상태이다.

### 7.4. STUCK_AFTER_PR_OPEN과의 차이 (Incident Type 구분, §9.6)

| 항목 | STUCK_AFTER_PR_OPEN | ESCALATED_VERIFIER_LIMITATION |
|---|---|---|
| PR 상태 | OPEN (머지 미완료) | MERGED (머지 완료) |
| 본질 판정 | 불명확 또는 PENDING | PASS 확정 |
| lifecycle marker | 부재 (idle 상태) | .escalate 마커 존재 |
| 차단 원인 | 봇 idle + lifecycle marker 부재 + CI 완료 후 무반응 | verifier 자체 결함 (SSOT 미참조 regex) |
| 트리거 사례 | task-2487 (오딘) — PR 발행 후 1시간 무반응 | task-2485+1 (헤르메스) — verifier regex가 task_id 거부 |
| detection signal | 봇 idle + lifecycle marker 부재 + PR open + CI 완료 | PR 머지 완료 + 본질 합격 조건 100% PASS + verifier .escalate 마커 존재 |

두 incident type은 절대 혼동 금지. 자동 분류기는 별도 detection signal로 분리 처리.

### 7.5. ESCALATED와의 차이

- **ESCALATED**: 본질 결함이 존재하거나 본질 재작업이 필요한 실패 상태. retry 룰이 본질 재작업 시도를 해야 하며 의미 있음
- **ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**: 본질은 PASS이고 retry는 무의미. ESCALATE 마커는 verifier 결함의 신호이며, 본질 재작업 없이 verifier 결함 해소만 후속 task로 이관

핵심 차이: ESCALATED는 본질 재작업 필요 + retry 의미 있음. 본 분류는 본질 재작업 불필요 + retry 무의미 + verifier 결함 해소만 후속 task 이관.

---

## 8. Evidence 요구사항 (필수 7항목)

본 분류 적용 시 다음 7항목이 모두 evidence에 명시되어야 한다:

1. **본질 합격 기준 전체 PASS** — 회장 명시 합격 조건 점수 (예: 8/8) 명시
2. **CI 전체 SUCCESS** — CI 결과 (예: 11/11 SUCCESS) 명시
3. **PR 머지 metadata** — commit hash, merged_at, merge_method(squash 등), admin_override=false, ci_bypass=false 전부 명시
4. **fresh evidence sha** — 최신 evidence 커밋 sha (예: 359dd902) 명시
5. **SSOT 메인 반영 확인** — 핵심 산출물의 파일 경로, 크기, verified_against (예: `utils/task_id_parser.py`, 6394 bytes vs origin/main:HEAD) 명시
6. **L1 smoke PASS** — L1 smoke 테스트 통과 여부 명시
7. **verifier 결함 진단** — failed_verifier 파일 경로, 문제 regex, ssot_import_missing 여부, self_reference_defect 여부, task_type_misapplication 여부 명시 (예: `teams/dev1/qc/verifiers/browser_verify.py:11`, `r'^task-\d[\w.\-]*$'`, ssot_import_missing=true, self_reference_defect=true)

---

## 9. 회장 승인 필요 조건 (3항목)

다음 경우에는 반드시 회장 발화 또는 evidence 박제가 필요하다:

1. **본 분류 적용 결정** — ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 분류를 적용하려면 회장 발화(명시 결정) 또는 회장 인정 evidence 박제가 선행되어야 함
2. **ESCALATE를 본질 실패로 재분류할 경우** — verifier ESCALATE를 task 본질 실패로 재분류하거나 ESCALATED 분류로 변경하는 행위는 회장 명시 없이 불가
3. **본 task 재오픈 또는 task_id 재사용** — 이미 ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 으로 종결된 task를 재오픈하거나 동일 task_id로 새 작업을 발행하는 경우 회장 결정 필요

---

## 10. 후속 hardening 연결 기준 (자동화 연결안)

본 분류가 적용된 task는 다음 4단계 자동화 연결이 권장된다:

1. **detection signal** — PR 머지 완료 + 본질 합격 조건 100% PASS + `.escalate` 마커 존재 + verifier 자체 결함 패턴 (SSOT 미참조 / regex 형식 거부 / 작업 유형 부적합)이 동시 확인될 때 ESCALATED_VERIFIER_LIMITATION으로 자동 분류
2. **자동 분류기 출력** — 분류 결정 시 `ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION` enum 출력 + 결함 verifier 경로 + 결함 유형 (self_reference / task_id_rejection / task_type_misapplication) 포함
3. **후속 task 자동 발행 트리거** — verifier SSOT 위임 hardening task 발행 제안. 결함 verifier 파일 경로, SSOT 파일 경로, 수정 scope를 payload에 포함하여 후속 task 명세 자동 생성 (예: task-2487+1 — verifier 계층 전수검색 + SSOT 위임)
4. **회귀 테스트 케이스 추가** — ESCALATE를 유발한 task_id로 verifier 재검증 PASS를 확인하는 회귀 테스트 케이스를 후속 hardening task에 큐잉 (예: `task-2485+1` task_id로 browser_verify PASS 확인)

---

## 11. lifecycle 마커 보존 규칙

ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 분류 시 다음 4종 마커를 동시 보존한다:

- `.done` — 본질 작업 + merge 완료 evidence
- `.escalate` — verifier ESCALATE 발생 evidence (보존 필수, 삭제 금지)
- `.done.escalated` — .done과 .escalate 병존 상태 마커
- `.essence-pass-escalated-verifier-limitation` — 분류 evidence (JSON 페이로드: classification, verdict_source, merge_evidence, chairman_acceptance_criteria_score, ci_status, fresh_evidence_sha, ssot_main_reflected, l1_smoke_pass, escalate_diagnosis, follow_up_task)

4종 마커는 모두 삭제 금지. lifecycle close 후에도 영구 보존.

---

## 12. 자동 조치 (5단계)

본 분류 확정 시 다음 순서로 처리한다:

1. **timer end** — `python3 memory/task-timer.py end <task_id>` 실행. 자동 `.done` 생성 현재 결함(timer end가 모든 종료에 `.done` 자동 생성) — Phase B 1단계(`--reason` 옵션 추가) 완료 후 해소 예정. 현재는 자동 생성된 `.done`을 보존(본 분류에서는 `.done`이 올바른 마커이므로 제거 불필요)
2. **`.essence-pass-escalated-verifier-limitation` 박제** — JSON 페이로드로 분류명, verdict_source, merge_evidence, 본질 합격 점수, CI 결과, fresh_evidence_sha, SSOT 반영 확인, verifier 결함 진단을 포함하여 박제
3. **followup.txt에 분류 기록** — ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 판정 + verifier 결함 내용 + 후속 hardening task 연결 방향 + 금지 사항 명시
4. **후속 hardening task 발행 제안 (실행 X)** — verifier SSOT 위임 hardening task 명세 작성 및 제안. 실제 발행은 회장 승인 후 또는 다그다(팀장) 지시에 따름
5. **회귀 테스트 케이스 큐잉** — ESCALATE를 유발한 task_id로 verifier 재검증 PASS를 확인하는 케이스를 후속 hardening task의 테스트 요구사항에 큐잉

---

## 13. 박제 사례 — task-2485+1

**분류**: ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION  
**verdict_source**: 회장 (2026-05-08T04:10 확정)  
**evidence file**: `memory/events/task-2485+1.essence-pass-escalated-verifier-limitation`

### JSON evidence 요약

```json
{
  "task_id": "task-2485+1",
  "team_id": "dev1-team",
  "lead": "헤르메스",
  "classification": "ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION",
  "essence_verdict": "PASS",
  "merge_evidence": {
    "pr_number": 47,
    "merge_commit": "be8dcd21b04098832515fc949e902e93b53172da",
    "merged_at": "2026-05-08T02:55:05+09:00",
    "merge_method": "squash",
    "admin_override": false,
    "ci_bypass": false
  },
  "chairman_acceptance_criteria_score": "8/8",
  "ci_status": "11/11 SUCCESS",
  "fresh_evidence_sha": "359dd902",
  "ssot_main_reflected": {
    "file": "utils/task_id_parser.py",
    "size_bytes": 6394,
    "verified_against": "origin/main:HEAD"
  },
  "l1_smoke_pass": true,
  "escalate_diagnosis": {
    "verdict": "verifier 자체 한계 — task-2485+1 본질 실패 아님",
    "failed_verifier": "browser_verify",
    "verifier_path": "teams/dev1/qc/verifiers/browser_verify.py:11",
    "regex_current": "r'^task-\\d[\\w.\\-]*$'",
    "ssot_import_missing": true,
    "self_reference_defect": true,
    "task_type_misapplication": "lifecycle 처리 작업 + 브라우저 작업 부재 → browser verifier 적용 부적합",
    "hermes_decision_validity": "non_minimal_code_change 금지 준수 위해 본 task에서 verifier 미수정 — 회장 인정"
  }
}
```

### 핵심 사실 요약

- **PR #47** squash 머지 완료 (commit be8dcd21, 2026-05-08T02:55:05+09:00, admin_override=false, ci_bypass=false)
- **회장 합격 조건 8/8**, **CI 11/11 SUCCESS**, fresh evidence sha=359dd902
- **SSOT 메인 반영 확인**: `utils/task_id_parser.py` (6394 bytes vs origin/main:HEAD)
- **L1 smoke PASS**
- **ESCALATE 원인**: `teams/dev1/qc/verifiers/browser_verify.py:11`의 `TASK_ID_PATTERN = re.compile(r'^task-\d[\w.\-]*$')`가 `+` suffix 미지원으로 `task-2485+1` task_id 자체를 거부
- **자기참조 결함**: verifier가 SSOT(`utils/task_id_parser.py`)를 import하지 않고 자체 regex를 보유
- **헤르메스 판단 타당성**: `non_minimal_code_change` 금지 준수를 위해 본 task에서 verifier 미수정 → 회장 인정
- **후속 task**: task-2487+1 (verifier 계층 전수검색 + SSOT 위임 hardening)

---

## 14. 금지 (회장 명시)

- ❌ task-2485+1 재오픈 금지
- ❌ verifier 결함을 task 본질 실패로 분류 금지
- ❌ 본 task에서 verifier 직접 수정 금지 (non_minimal_code_change 위반)
- ❌ STUCK_AFTER_PR_OPEN과 혼동 금지
- ❌ 수동 `.done` 생성 금지

---

## 15. 회장 명시 완료 보고 5항목 요약

- **분류명**: ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION
- **적용 조건**: §3 5항목 AND 충족 — (1) 본질 합격 100%, (2) 회장 명시 금지 위반 0건, (3) CI/머지/fresh evidence/핵심 산출물 모두 PASS, (4) ESCALATE 사유가 verifier 자체 결함, (5) verifier 결함 해소가 본 task 작업 영역 외
- **오분류 방지 기준**: §4 비적용 조건(본질 결함 존재 / 합격 조건 미달 / verifier 결함이 scope 내 수정 가능 등) + §7 기존 분류 5종과의 차이 + §6 본질/verifier 평가 surface 분리 원칙
- **기존 분류와의 차이**: §7.1 FAILED_PREEXISTING(사전 외부 결함 vs 자기참조 구조 결함) / §7.2 BLOCKED_BY_EXTERNAL_DEPENDENCY(외부 서비스 vs 내부 tooling 결함) / §7.3 DOGFOODING_PENDING(인프라 의존 + PASS 유보 vs 머지 완료 + verifier 코드 결함) / §7.4 STUCK_AFTER_PR_OPEN(PR OPEN + idle vs PR MERGED + PASS + .escalate) / §7.5 ESCALATED(본질 재작업 필요 vs 본질 PASS + retry 무의미)
- **후속 자동화 연결안**: §10 — (1) detection signal(PR 머지 + 본질 PASS + .escalate + verifier 결함 패턴) → (2) 분류기 출력(ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION) → (3) hardening task 발행 제안(verifier SSOT 위임) → (4) 회귀 테스트 케이스 큐잉(거부된 task_id로 재검증 PASS 확인)

---

## 16. 참조 (read-only)

- **분류 룰 선결**: `memory/feedback/feedback_escalated_verifier_limitation_classification_260508.md`
- **박제 evidence**: `memory/events/task-2485+1.essence-pass-escalated-verifier-limitation`
- **Phase B 통합**: `memory/orchestration/phase_b_integration_items_260507.md` (§1 8종 enum, §9.6 Incident Type 구분)
- **형식 참조 (MERGE_PENDING_DEPENDENCY)**: `memory/feedback/feedback_merge_pending_dependency_classification_260507.md`
- **형식 참조 (MERGED_CLOSE_BLOCKED_EXTERNAL)**: `memory/feedback/feedback_merged_close_blocked_external_classification_260507.md`
- **시스템 청사진**: `/home/jay/.claude/projects/-home-jay--cokacdir-workspace-autoset/memory/system_bot_orchestration_blueprint_260506.md`