---
name: ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 분류 룰
description: 본질 PASS 인정되나 verifier 자체 결함(SSOT 미적용 자기참조 등)으로 ESCALATE된 경우의 분류 룰. task-2485+1 사례 박제.
type: feedback
---

# ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 분류 룰

> 회장 결정 (2026-05-08T04:10) — task-2485+1 통합 결과 확정 시 신규 분류 신설.

## 분류명

**ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION**

## When to apply

본 분류는 다음 **모든** 조건을 충족할 때 적용한다:

1. ✅ task 본질 합격 조건 100% 충족 (회장 명시 합격 조건 전체 PASS)
2. ✅ 회장 명시 금지 위반 0건
3. ✅ CI / 머지 / fresh evidence / 핵심 산출물 모두 PASS
4. ❗ ESCALATE 사유가 task 본질 실패가 아니라 **verifier 자체 결함**
5. ❗ verifier 결함 해소가 본 task의 작업 영역 외 (allowed_resources / non_minimal_change 룰 등으로 차단)

## verifier 자체 결함의 정의

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

- verifier가 SSOT(단일 진실 공급원)를 import하지 않고 자체 regex/로직을 보유 (자기참조)
- verifier가 검증 대상의 task_id 형식 자체를 거부 (예: `+` suffix 미지원)
- verifier가 본 task의 작업 유형(예: lifecycle 처리, 코드 변경 0)에 적용 부적합한데도 강제 적용
- verifier 적용 부적합이 본 task에서 수정 시 **non_minimal_code_change** 또는 다른 회장 명시 룰 위반

## How to apply

1. 본 task의 본질 완료를 인정하고 종결
2. ESCALATE evidence는 보존 (`.escalate`, `.done.escalated` 마커 보존)
3. verifier 결함 해소는 **후속 task로 이관**
4. 후속 task에서 SSOT 적용 + 회귀 테스트 추가 + ESCALATE 재현/해소 검증
5. 기존 evidence를 삭제하지 않고 후속 task가 자연스럽게 해소

## Why

verifier 자체 결함이 task 본질 평가를 오염시키지 않도록 분류 분리. 헤르메스가 task-2485+1에서 `non_minimal_code_change` 금지를 지키며 verifier를 수정하지 않은 판단은 타당하므로, 본 task를 본질 실패로 잘못 분류하면 안전한 작업 패턴이 잘못 학습된다.

## How to apply (ESCALATE 처리)

- 본 분류는 `FAILED_PREEXISTING` / `BLOCKED_BY_EXTERNAL_DEPENDENCY` 와 다르다
- `FAILED_PREEXISTING`은 본 task와 무관한 기존 결함, 본 분류는 본 task의 task_id가 verifier에 의해 거부된 자기참조 결함
- `BLOCKED_BY_EXTERNAL_DEPENDENCY`는 외부 의존이지만, 본 분류는 verifier 자체 결함
- 8종 종료 분류 enum (task-2489 spec)에 추가 검토 필요

## 박제 사례

- **task-2485+1** (2026-05-08): browser_verify.py의 `TASK_ID_PATTERN = re.compile(r'^task-\d[\w.\-]*$')`가 `+` 미지원으로 task_id `task-2485+1` 자체를 거부 → 3회 연속 fail로 ESCALATE → verifier가 SSOT(utils/task_id_parser.py)를 import하지 않은 자기참조 결함 → 본질 PASS 인정, task-2487+1로 이관