# Phase B 통합 항목 (Phase A 본문 비변경, B에서 통합)

작성: 2026-05-07
근거: 회장 명시 ("Phase A 정책 파일 자체를 지금 즉시 크게 흔들지는 말고, Phase B 통합 항목에 종료 분류 체계를 명시적으로 추가한다")

## 1. 종료 분류 체계 (★ 8종)

### 분류 enum

| 분류 | merge 상태 | 차단 위치 | 정의 | 적용 예시 |
|---|---|---|---|---|
| `DONE` | MERGED | 없음 | 본질 PASS + merge + lifecycle close 모두 완료 | task-2466, task-2479 |
| `ESCALATED` | OPEN/MERGED | 본질 단계 | 본질 결함, retry로 본질 재작업 필요 | 본질 결함 케이스 |
| `DOGFOODING_PENDING` | MERGED 또는 머지 후 | dogfooding layer | 자기검증 layer 외부 의존 (BOT 토큰, ruleset, approval) | task-2481 |
| `MERGE_PENDING_DEPENDENCY` | **OPEN** | merge 자체 | 후속 task 머지 의존 | task-2472+1 (→ task-2472+2 의존) |
| **`MERGED_CLOSE_BLOCKED_EXTERNAL`** | **MERGED** | post-merge close | 외부 workspace dirty로 close lifecycle 실패 | task-2483 (→ task-2484 의존) |
| `BLOCKED_BY_EXTERNAL_DEPENDENCY` | OPEN/시작 X | 본질 진행 | 외부 시스템(API/infra/ruleset) 차단 | API 다운, infra 장애 |
| `FAILED_PREEXISTING` | OPEN | 본질 진행 | 기존 결함이 본 task 진행 차단 (본 task 책임 아님) | main lint/test 기존 실패 |
| `WAITING_FOR_CHAIR_DECISION` | 다양 | 정책 결정 | 방향성/우선순위/예외 승인 회장 대기 | 정책 충돌, 사용자 영향 큰 변경 |

### 5개 분류의 본질적 차이

- DONE: 끝 (성공)
- ESCALATED: 끝 (실패) — retry 의미 있음
- 나머지 5개: **끝이 아님 (조건부 대기)** — retry 의미 없음, 외부 조건 충족 필요

> 핵심: retry_count 초과 시 무조건 ESCALATED 보내면 안 된다. 차단 사유 분석 후 적절한 PENDING/BLOCKED/WAITING 분류 필요.

## 2. 시스템 통합 사항 (필수 구현)

### 2.1. dispatch.py / lifecycle classifier 자동 분류

```
입력: task_id, retry_count, .escalate 발생 여부, PR state, CI rollup, followup.txt
출력: 종료 분류 enum 1종 + 후속 조건 list
```

분류 결정 로직 (순서대로 매칭):
1. PR MERGED + close lifecycle clean → `DONE`
2. **PR MERGED + close lifecycle 실패 + 차단 사유 외부 workspace dirty** → `MERGED_CLOSE_BLOCKED_EXTERNAL`
3. PR MERGED + dogfooding layer 외부 의존 → `DOGFOODING_PENDING`
4. PR OPEN + 본질 PASS 명시 + CI 외부 의존 + 의존 task id 명시 → `MERGE_PENDING_DEPENDENCY`
5. 본질 시작 차단 + 외부 시스템(API/infra/ruleset) 사유 → `BLOCKED_BY_EXTERNAL_DEPENDENCY`
6. 실패 원인이 본 task 이전 commit/state → `FAILED_PREEXISTING`
7. 방향성/예외/승인 회장 대기 → `WAITING_FOR_CHAIR_DECISION`
8. retry_count 초과 + 본질 결함 + 본질 재작업 필요 → `ESCALATED`
9. 위 미해당 → 분류 보류, 회장 알림

### 2.2. task-timer.py 보강

```
python3 memory/task-timer.py end <task_id> [--reason <classification>]
```

분류별 동작:
- `--reason done` (default 후순위): `.done` 자동 생성
- `--reason escalated`: `.escalated` 발행 (`.done` 미발행)
- `--reason dogfooding_pending`: `.dogfooding-pending` 발행 (`.done` 미발행)
- `--reason merge_pending_dependency`: `.merge-pending` 발행 (`.done` 미발행)
- `--reason blocked_external`: `.blocked-external` 발행 (`.done` 미발행)
- `--reason failed_preexisting`: `.failed-preexisting` 발행 (`.done` 미발행)
- `--reason waiting_chair`: `.waiting-chair` 발행 (`.done` 미발행)

⚠️ 현재 결함: `--reason` 미지정 시 모든 종료에 `.done` 자동 생성 → MERGE_PENDING_DEPENDENCY 케이스에 회장 금지 #1 위반. Phase B 진입 시 default 동작도 안전하게 변경 필요.

### 2.3. .conditions 파일 자동 생성

분류별 후속 조건 표준 템플릿:
- `MERGE_PENDING_DEPENDENCY` → 후속 6조건 (의존 task DONE → CI rerun → guard PASS → PR MERGED → close → .done 변환)
- `DOGFOODING_PENDING` → 후속 4조건 (외부 의존 복구 → bot-authored PR 재발행 → no-admin merge → layer 5 evidence)
- `BLOCKED_BY_EXTERNAL_DEPENDENCY` → 후속 3조건 (외부 시스템 복구 확인 → 재시도 가능 검증 → lifecycle 진입)
- `FAILED_PREEXISTING` → 후속 2조건 (기존 결함 별도 task 발행 → 본 task 영향 확인 후 재시도)
- `WAITING_FOR_CHAIR_DECISION` → 후속 1조건 (회장 결정 명시)

### 2.4. timer stale 방지

- 자동 분류기가 retry_count 초과 또는 일정 시간(예: 2h) 무진척 감지 → 분류 트리거
- 분류 결정 후 timer 자동 end + 적절한 event 발행
- 봇이 `.escalate` 박제 후 그대로 멈추는 stale 패턴 차단

### 2.5. dispatch.py 후속 트리거

- `MERGE_PENDING_DEPENDENCY` 상태 task의 의존 task `.done` 감지 → 본 task PR CI rerun 자동 발행 → CI PASS 감지 → `.merge-pending` → `.done` 변환
- `DOGFOODING_PENDING` 상태 task의 인프라 복구 task `.done` 감지 → 후속 dogfooding 재시도 propose
- `WAITING_FOR_CHAIR_DECISION` → 회장 결정 발화 감지 시 분류 재산정

### 2.6. 대시보드 통합

- 결정 큐 외에 "종료 분류별 보드" 7섹션 (DONE 외 6종 별도)
- 각 분류별 카드에 후속 조건 진척도 표시
- `MERGE_PENDING_DEPENDENCY` / `DOGFOODING_PENDING`은 의존 task와 시각적 연결 (화살표/lineage)

## 3. orchestrator_subagent_prompt 보강 항목 (Phase B)

- 입력 task 분석 시 사전 위험 감지 (audit_event에 추가 정보)
  - `MERGE_PENDING_DEPENDENCY 위험`: workflow/CI/guard surface 변경 + main 후속 의존
  - `DOGFOODING_PENDING 위험`: bot-authored merge flow / self-approval 정책 의존
  - `BLOCKED_BY_EXTERNAL_DEPENDENCY 위험`: 3rd party API / 외부 service 의존
- audit_event 필드 후보: `expected_terminal_classification`, `unblock_dependencies`

## 4. 회귀 사례 (Phase B 진입 시 자동화 검증 케이스)

| task | 분류 | 사유 |
|---|---|---|
| task-2481 | DOGFOODING_PENDING | bot-authored merge flow + BOT 토큰 401 |
| task-2472+1 | MERGE_PENDING_DEPENDENCY | taskctl reconcile + task-2472+2 workflow regex 의존 |
| task-2483 | MERGED_CLOSE_BLOCKED_EXTERNAL | refresh_bot_token PR #45 머지 완료 + 외부 workspace dirty (→ task-2484) |

## 5. Phase A 본문 비변경 원칙

- v2 6파일 (`orchestrator_subagent_prompt_260506_v2.md` 등) 본문은 **그대로 유지**
- 본 문서는 Phase B 진입 시 변경 범위 명세만 담음
- 즉시 적용은 회장 별도 승인 시까지 보류

## 6. Phase B 진입 체크리스트 (회장 결정 대기)

- [ ] 종료 분류 7종 enum을 `gate_policy_260506_v2.yaml`에 통합할 것인가?
- [ ] `task-timer.py end --reason` 옵션 추가 시 default 동작 변경 범위
- [ ] dispatch.py 자동 트리거 도입 범위 (어디까지 자동화, 어디부터 회장 개입?)
- [ ] 대시보드 7섹션 보드 디자인 (어느 분류를 메인에, 어느 분류를 탭으로?)
- [ ] orchestrator_subagent_prompt 보강 시점 (Phase B 시작 vs Phase B 중간)
- [ ] task-2472+1 / task-2481 자동 lifecycle close 검증 시점 (Phase B 중간 회귀 테스트)

---

## 7. 회장 결정 박제 (2026-05-08T01:50, task-2489 essence PASS 후)

### 7.1. Phase B production 반영 = 3단계 분리 (회장 명시)

한 번에 전부 반영 금지. 다음 순서로 분리:

**1단계**: `task-timer.py end --reason` 옵션 추가
- `--reason done|escalated|dogfooding_pending|merge_pending_dependency|merged_close_blocked_external|blocked_by_external_dependency|failed_preexisting|waiting_for_chair_decision|unclassified`
- default 동작: `.done` 자동 발행 (legacy)
- `--reason` 명시 시 분류별 적절한 marker 발행, `.done` skip 가능

**2단계**: finish-task / dispatch marker 변환 연결
- finish-task.sh에 분류 결정 로직 통합
- dispatch.py가 분류 변경 신호 자동 trigger

**3단계**: dashboard 7섹션 보드 반영
- 종료 분류별 보드 (DONE 외 7종 별도)
- 의존 task lineage 시각화

→ 1단계 완료 후 회장 재결정 후 2단계 진입.

### 7.2. UNCLASSIFIED 별도 보존 (회장 명시)

UNCLASSIFIED는 `WAITING_FOR_CHAIR_DECISION`에 **흡수하지 않는다**.

- `WAITING_FOR_CHAIR_DECISION`: 회장 판단 *대기 중* (정책/방향성/예외 승인)
- `UNCLASSIFIED`: classifier 자체가 분류 미정의 상태 (alert 대상)

→ 8종 + UNCLASSIFIED = 실제로 9종 enum. classifier가 9번째로 UNCLASSIFIED 출력 시 회장 알림 트리거.

### 7.3. task-2485 fixture 정책 (회장 명시)

- 현재 가정 시나리오 유지
- PR #47 fresh evidence 처리 후 실제 로그 기반 fixture로 교체
- 교체 시점: PR #47 MERGED + task-2485 MERGED_DONE 전환 후

### 7.4. task-2489 분류 박제 (회장 명시)

- task-2489: ESSENCE_PASS / MERGED_CLOSE_BLOCKED_EXTERNAL
- 외부 dirty는 task-2489 책임 아님
- 본 task 산출물 자체 재작업 금지
- 외부 dirty 정리는 별도 cleanup task 또는 critical chain 정리 후
- evidence: `memory/events/task-2489.essence-pass-merged-close-blocked-external`

### 7.5. 금지 (회장 명시 4건)

- ❌ `task-timer.py` 즉시 production 수정 금지
- ❌ `dispatch.py` 즉시 production 수정 금지
- ❌ marker 파일 수동 생성 금지
- ❌ 외부 dirty를 task-2489 책임으로 오분류 금지

---

## 8. 회장 결정 박제 (2026-05-08T02:00, task-2488 essence PASS 후)

### 8.1. task-2488 분류 박제

- task-2488: ESSENCE_PASS / POC_ISOLATED
- production 통합 전 검증 자료로만 사용
- 즉시 dispatch 자동화나 실제 task 발행 자동화에 연결 X
- evidence: `memory/events/task-2488.essence-pass-poc-isolated`

### 8.2. cycle_advancer.py 후속 보강 항목 (회장 명시 6건)

production 통합 전 적용:

1. **output_dir 가드** — `_validate_output_dir()` 추가, `memory/poc/cycle_advancer/**` 하위로 강제
2. **필드 명명 정정** — `affected_files` → `proposed_affected_files` 또는 `simulated_affected_files` (실제 변경과 구분)
3. **chairman_required=True 분기 fixture 추가** — 합의 미달 시나리오
4. **classification enum 단일 source** — task-2489의 `TerminationClassification` enum과 연결, drift 방지
5. **worktree/branch isolation 미작동** — 별도 hardening 후보 (시스템 개선 backlog 8.3 참조)
6. **allowed_resources glob 미스매치 사전 감지** — lint 또는 자동 생성 로직 검토 (시스템 개선 backlog 8.3 참조)

### 8.3. 시스템 개선 backlog (환경 이슈)

회장 판정: 다음 2건은 task-2488 본질 실패가 아니나 병렬 운영 안정성 직접 영향. **별도 hardening task로 박제**:

| # | 이슈 | 영향 | 후속 task 후보 |
|---|---|---|---|
| 1 | **worktree/branch isolation 미작동** | 병렬 task 간 격리 깨짐, surface 침범 위험 | task-N (별도 hardening) |
| 2 | **allowed_resources glob 미스매치** | task 발행 시 의도와 실제 매칭 영역 차이, scope 검증 false alert | task-N (lint/자동 생성 로직) |

→ task-2486 → task-2485 critical chain 정리 후 backlog 처리 우선순위 재산정.

### 8.4. cycle_advancer 금지 (회장 명시 4건)

- ❌ cycle_advancer를 즉시 production dispatch에 연결 금지
- ❌ 외부 AI 실호출 연결 금지
- ❌ 실제 `.done` / `.escalate` / `.fail` 생성 금지
- ❌ `output_dir` 가드 전 production 경로 지정 허용 금지

---

## 9. 회장 결정 박제 (2026-05-08T02:10, task-2493 CONDITIONAL GO 후)

### 9.1. task-2493 분류 박제

- task-2493: ESSENCE_PASS / CONDITIONAL_GO
- 본질 read-only audit으로 PASS
- 기존 NO-GO 근거 (x-accepted-github-permissions 헤더 해석, repositories.permissions.push:false 해석) **방법론 오류로 폐기**
- R+1 진행 허용
- evidence: `memory/events/task-2493.essence-pass-conditional-go`

### 9.2. task-2481R+1 발행 조건 (회장 명시)

**선행 조건 (모두 충족 시 발행)**:
- task-2486 머지 완료
- task-2485 머지 완료
- R suffix 호환이 main에 반영
- 정상 task_id `task-2481R+1`로 발행 (alias `task-2491` 금지)

**R+1 본질 7개 조건**:
1. bot token으로 **branch push를 첫 번째 실증 관문**으로 둠
2. branch push 성공 → contents:write 실증 PASS 기록
3. branch push **실패 → 즉시 중단**, 권한 보강 task로 전환
4. 사람 author PR 직접 머지 금지
5. admin override 금지
6. dry_run evidence ≠ 실 실행 evidence
7. bot-authored **replacement PR** 또는 **handoff PR**만 인정

### 9.3. 권한 진단 방법론 오류 박제

향후 audit 작업에 동일 오류 재발 방지:

| 오류 패턴 | 폐기 사유 | 대안 |
|---|---|---|
| `x-accepted-github-permissions` 헤더로 부족 권한 단정 | 헤더는 *수용 가능* 권한 목록일 뿐, 실제 보유 권한 아님 | 실제 API 호출 시도로 검증 (read-only는 GET, write는 dry-run 또는 첫 실증 관문) |
| `repositories.permissions.push:false`로 push 권한 부재 단정 | 이 필드는 collaborator 권한 model이지 GitHub App permissions 아님 | `gh api /installation` 또는 `/installations/{id}` 응답의 permissions 필드 사용 |

### 9.4. 추가 시스템 개선 backlog (회장 명시 + 2026-05-08T08:30 격상)

**★ 우선순위 격상 (2026-05-08T08:30 회장 명시 §6)**: branch/worktree isolation hardening을 **즉시 최우선 hardening 후보로 격상**한다.

**격상 사유**:
- task-2498이 문서상 식별한 패턴이 6팀 finish-task에서 즉시 재현됨 (실시간 dogfooding)
- main에는 필요한 함수가 있으나 local workspace에는 없어 ImportError 발생 (또는 그 역의 분기 상태)
- 안전 병행 문서 작업조차 finish-task 단계에서 차단됨
- 향후 모든 병렬 작업 lifecycle 신뢰성을 훼손할 수 있음

**즉시 최우선 hardening 후보**:
- **task-2500-candidate — workspace sync preflight and isolation hardening** (신규, 회장 명시 §7 spec 박제 완료 → `memory/events/task-2500-candidate.workspace-sync-preflight-spec`)

**기존 backlog (전체 9건) — 우선순위 재산정 필요**:

§8.3 backlog에 추가:

1. **branch/worktree isolation hardening** (8.3에 이미 등록됨, 우선순위 ↑)
2. **bot-token-refresh.jsonl logging gap 보강** — 토큰 갱신 audit 누락 항목 식별 + 보강
3. **권한 진단 방법론 문서화** — §9.3 오류 패턴 + 대안 패턴을 별도 문서로 박제 (memory/specs 또는 feedback)
4. **auto-merge.yml main 부재 audit** (2026-05-08 추가) — green path auto-approve가 시스템 차원에서 끊긴 결함. main 브랜치에 `.github/workflows/auto-merge.yml` 파일 부재 (`git/trees/main?recursive=1` 조회 결과). 마지막 실행 2026-05-04 PR #17 (task-2444) 이후 0건. 별도 audit task에서 git history/blame으로 제거 시점·PR·commit 식별 후 복구 필요 시 별도 인프라 task로 발행. **현재 #49/#50/#51 머지의 직접 선결은 아니므로 backlog 등록만**
13. **★★ Merge Topology Gate 구현 (dispatch.py)** (2026-05-08T11:30 추가, 회장 정식 정책) — dispatch 시점 7 metadata 검증 + serial/limited/parallel 분류 + 충돌 자동 차단. 정책 본체: `memory/feedback/feedback_merge_topology_gate_260508.md`. 구현 후 task-2487+1 / task-2502 같은 SCOPE-GUARD / lifecycle 충돌 사고 재발 방지

11. **codegraph-anu dirty state hardening** (2026-05-08T11:11 추가, 회장 §6 명시) — task-2502 작업 중 codegraph-anu 관련 dirty state 발견. 본 task 영역 외 분리. 별도 hardening task 후보로 정밀 진단 + 정리 절차 명세 필요
12. **git_evidence false-positive hardening** (2026-05-08T11:11 추가, 회장 §6 명시) — git_evidence verifier가 변경 파일 / scope를 잘못 분류하여 false-positive 발생 사례 보고됨. 별도 hardening task 후보로 git_evidence 룰 정밀화 + 회귀 케이스 추가 필요

10. **qc_verify scope hardening** (2026-05-08T10:50 추가, 회장 결정) — qc_verify.py가 변경 범위와 무관하게 `pytest /home/jay/workspace/tests` 전체 슈트를 실행하는 정책 → G3 retry 시 시간 가중. SCQA 형식 검증 같은 본질 외 결함으로도 전체 재실행. 변경 영향 범위 기반 scope 정밀화 필요. **트리거 사례**: task-2502 G3 fail (SCQA 패턴 부족 1개) → retry 진입 → tests/ 전체 pytest 재실행 (CPU 60%, RSS 767MB). evidence: `memory/events/task-2502.g3-fail-evidence-archive`

5. **task-2494 후보 — PR open 후 stuck/zombie detection hardening** (2026-05-08 추가, 회장 명시) — PR 발행 후 일정 시간 동안 후속 lifecycle marker(merged / .done / .followup / .escalate / BLOCKED 사유 보고 / timer 종료) 중 하나도 발생하지 않으면 STUCK_AFTER_PR_OPEN으로 자동 분류. 상세 spec: `memory/events/task-2494-candidate.stuck-detection-spec`. **운영 원칙: stuck/zombie detection은 계속 Phase 0 문서화/감사 범위로 유지. 즉시 production 통합 X**
> Phase 0 spec 완료: `memory/orchestration/task-2494-phase0-stuck-zombie-detection.md` (2026-05-08, 페룬/dev6-team)
6. **browser_verify SSOT adoption gap** (2026-05-08 추가, 회장 명시) — task-2487+1 필수 범위에 포함. verifier 계층 자기참조 regex 제거 + utils/task_id_parser.py SSOT 위임
7. **verifier self-reference regex 제거 (계층 전수검색)** (2026-05-08 추가, 회장 명시) — teams/*/qc/verifiers/* 전수 audit. 중복 regex 제거 + SSOT 단일화
8. **ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION 분류 신설** (2026-05-08 회장 결정, 박제 완료) — `memory/feedback/feedback_escalated_verifier_limitation_classification_260508.md` + task-2489 8종 enum spec에 추가 검토 필요
9. **PR #42 BEHIND recovery 별도 분석** (2026-05-08 추가, 회장 명시) — task-2495-candidate spec: `memory/events/task-2495-candidate.pr42-recovery-analysis-spec`. 읽기 전용 분석만 허용

### 9.7. ★★ Merge Topology Gate 정책 (회장 명시 2026-05-08T11:30)

**발효 즉시.** 모든 신규 dispatch 의무 적용.

**핵심 룰**:
1. dispatch 시점 7 metadata 명시 필수: `expected_files`, `risk_area`, `dependency`, `parallel_policy`, `merge_queue_position`, `stale_recheck_required`, `cherry_pick_allowed`
2. 병렬 금지 5종: 동일 파일 / 동일 함수 / 동일 verifier / 동일 lifecycle state machine / 동일 migration·schema
3. limited_parallel: 다른 파일이지만 같은 QC/merge lifecycle → merge queue 순서 강제
4. 의존성: 선행 task 산출물 사용 시 → 후행은 선행 PR 머지 후 dispatch (premature dispatch 금지)
5. 체리픽: 정상 경로 X, 복구 경로만 + 자동 금지 + replacement PR + 회장 승인 필수

**상세**: `memory/feedback/feedback_merge_topology_gate_260508.md`
**구현 backlog**: §9.4 #13

**위반 사례 evidence (정책 도입 트리거)**:
- task-2487+1 SCOPE-GUARD violation (SSOT 함수 main 부재 상태 verifier 수정 시도)
- 6팀 batch ESCALATED_VERIFIER_LIMITATION (동일 verifier import error 동시 발생)
- task-2487 STUCK_AFTER_PR_OPEN

### 9.6. Incident Type 구분 (회장 명시 2026-05-08T04:10)

task-2494 stuck/zombie detection 문서화 시 두 incident type을 **별도로** 구분:

| incident type | 트리거 사례 | 본질 분류 |
|---|---|---|
| STUCK_AFTER_PR_OPEN | task-2487 (오딘) — PR 발행 후 1시간 무반응, 회장 강제 stop | REVIEW_OR_APPROVAL_PENDING_WITH_REGRESSION |
| ESCALATED_VERIFIER_LIMITATION | task-2485+1 (헤르메스) — verifier 자체 결함으로 ESCALATE, 본질은 PASS | ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION |

→ 두 incident type 혼동 금지. 자동화 분류 룰 작성 시 별도 detection signal로 분리:
- STUCK_AFTER_PR_OPEN: 봇 idle + lifecycle marker 부재 + PR open + CI 완료
- ESCALATED_VERIFIER_LIMITATION: PR 머지 완료 + 본질 합격 조건 100% PASS + verifier .escalate 마커 존재

→ critical chain (task-2486 ✅ 머지 → task-2485+1 ✅ ESSENCE_PASS / ESCALATED_VERIFIER_LIMITATION → task-2487+1 발행 → PR #49/#50/#51 후속 정상 PR → task-2472+1 별도 task-2495 분석 → task-2483 → task-2484) 정리 후 backlog 재산정.
> Phase 0 spec 산출: `memory/orchestration/task-2494-phase0-stuck-zombie-detection.md` (incident type 구분 룰 §1~§10 박제 완료)

### 9.5. task-2487 분류 박제 — REVIEW_OR_APPROVAL_PENDING_WITH_REGRESSION

**회장 명시 (2026-05-08T02:30)**: task-2487 PR #49/#50/#51은 단순 approval pending이 아니라, `required_review_thread_resolution=true`에 의해 Gemini unresolved review thread가 막고 있는 상태. Gemini thread는 단순 코멘트가 아니라 task-2487의 본질인 legacy task ID compatibility와 정면 충돌하는 **실제 회귀**.

**금지**:
- PR #49/#50/#51 수동 approve 금지
- thread 단순 resolve 금지
- 강제 머지 금지

**3-lane 작업 흐름** (회장 명시):
- **Lane A (1순위)**: PR #47 / task-2485 선결 처리 (task-2485+1, 헤르메스)
- **Lane B (2순위 ~ 3순위)**: task-2487+1 회귀 픽스 (오딘, PR #47 머지 후) → PR #49 → #50 → #51 순차 머지
- **Lane C**: PR #42 / task-2472+1 차단 해소 가능성 모니터링 (task-2485+1 머지 후 자동 확인)

**상세 evidence**: `memory/events/task-2487.review-or-approval-pending`
**1순위 task 파일**: `memory/tasks/task-2485+1.md`