# MERGE_PENDING_DEPENDENCY 분류 룰 (영구 박제)

작성: 2026-05-07
근거: 회장 명시 (B안 채택, task-2472+1 사례 후속 정정)

## 1. 문제 배경

- **task-2472+1** (taskctl reconcile 명령 신설)에서 본질 PASS + PR OPEN + 후속 task 의존 상태가 발생
- 기존 종료 상태 체계(DONE / ESCALATED / DOGFOODING_PENDING)에 정확한 분류명이 없어 `.escalate` stale 상태로 4시간 방치됨
- retry_count 4회 초과로 봇이 ESCALATED 처리했으나, 실제로는 본질 결함이 아니라 task-N+M workflow regex 미지원(task-2472+2 의존)이 원인
- timer running 상태로 4시간 stale, lifecycle close 트리거 부재

## 2. 신규 분류

**MERGE_PENDING_DEPENDENCY**

> 본질 작업은 PASS 판정을 받았으나, 해당 PR이 외부/후속 task의 완료를 선행 조건으로 요구하여 아직 merge/done lifecycle을 닫을 수 없는 상태.

## 3. DOGFOODING_PENDING과의 차이

- **DOGFOODING_PENDING**
  - 자기검증/dogfooding layer가 아직 완료되지 않아 본질 PASS를 유보하는 상태
  - 차단 사유: 인프라(BOT 토큰, ruleset, approval) 외부 의존
  - 해소 단위: 인프라 복구 (토큰 갱신 등)
  - 예시: task-2481 (bot-authored merge flow + dogfooding layer 5)

- **MERGE_PENDING_DEPENDENCY**
  - 본질 PASS는 인정되었으나, merge 가능 조건이 외부/후속 task에 의해 막힌 상태
  - 차단 사유: 별도 후속 task의 코드/머지 의존
  - 해소 단위: 후속 task 머지 → CI rerun → 본 PR 머지
  - 예시: task-2472+1 (workflow regex → task-2472+2 의존)

## 4. ESCALATED와의 차이

- **ESCALATED**
  - 회장 판단 또는 추가 조치가 필요한 **실패/위험** 상태
  - 본질 결함 또는 본질 재작업이 필요한 케이스
  - retry 룰이 본질 재작업 시도해야 함

- **MERGE_PENDING_DEPENDENCY**
  - **실패가 아니라 조건부 대기 상태**이며, 명확한 unblock 조건이 존재함
  - 본질 결함 0, 외부 의존 해소만 기다림
  - retry 룰을 적용하면 안 됨 (재작업 무의미)

## 5. 자동 감지 조건 (6항목)

다음 6가지 모두 만족 시 MERGE_PENDING_DEPENDENCY 자동 분류:

1. ✅ 본질 PASS 문구 존재 (followup.txt 또는 회장 발화에 명시)
2. ✅ PR OPEN (`gh pr view <#> --json state,mergedAt` → state=OPEN, mergedAt=null)
3. ✅ CI fail 원인이 외부 dependency로 식별됨 (본 task 본질 결함 0)
4. ✅ 후속 task id가 명시됨 (대상 task 명확히 추적 가능)
5. ✅ `.done` 없음
6. ⚠️ retry_count 초과 또는 stale timer 발생 가능 (보조 신호)

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

```
1. timer end
   - python3 memory/task-timer.py end <task_id>
   - 자동 생성된 .done 즉시 제거 (★ 필수, 회장 금지 #1)

2. .merge-pending event 발행
   - JSON 페이로드: classification, essence_verdict, pr, block_reason, dependency, lifecycle, rules

3. .merge-pending.conditions 작성
   - 후속 6조건 표준 형식 (의존 task DONE → CI rerun → guard PASS → PR MERGED → close → .done 변환)

4. followup.txt에 unblock 조건 기록
   - MERGE_PENDING_DEPENDENCY 판정 + 후속 조건 + 금지 5건 명시

5. dispatch.py 또는 lifecycle classifier가 상태를 인식하도록 Phase B 통합
   - 자동 트리거: 의존 task .done 감지 → 본 task .merge-pending → .done 자동 변환
```

## 7. task-2472+1 사례 박제

- **PR**: #42 (https://github.com/Jeon-Jonghyuk/dev_workspace/pull/42)
- **본질 작업**: taskctl reconcile 명령 신설 (state-orphaned 사후 정합화, layer 4)
- **본질 verdict**: PASS (회장 인정, 2026-05-07T22:25)
- **CI 차단**: taskctl-state-guard 2건 FAIL
- **차단 원인**: workflow regex `task-[0-9]+`가 task-N+M 형식 미지원 → task-2472+1을 task-2472로 잘라 검증 → "task scope 밖 파일" 오인식
- **의존 task**: task-2472+2 (`.github/workflows/{guard,ci}.yml` regex `task-[0-9]+(\+[0-9]+)?` fix)
- **의존 team**: dev1-team (헤르메스), 2026-05-07T22:43~ running
- **lifecycle 정리**: timer end (4시간 5분) / `.escalate` → `.escalate.reclassified` / `.merge-pending` 박제 / `.merge-pending.conditions` 작성

## 8. 금지 (회장 명시 5건)

- ❌ 후속 6조건 미충족 상태에서 `.done` 발행
- ❌ 실패로 close (`.escalated`, `.failed` 등)
- ❌ admin override 사용한 PR 머지
- ❌ 강제 머지 (force merge, --admin)
- ❌ 본질 코드 추가 수정 (이미 PASS, surface 침범 우려)

## 9. 시스템 결함 (Phase B 통합 항목으로 격상)

`task-timer.py end`가 모든 종료에 `.done`을 자동 생성 → MERGE_PENDING_DEPENDENCY 케이스에 회장 금지 #1 위반.

**Phase B 수정안**:
- `task-timer.py end --reason <classification>` 옵션 추가
- 분류별 `.done` 자동 생성 skip 또는 적절한 event 파일 발행
- 상세: `memory/orchestration/phase_b_integration_items_260507.md`