# 레벨 0~4 병행 시 머지 안전성 크로스체크 (심층 분석)

상태명: `LEVEL0_4_PARALLEL_MERGE_SAFETY_CROSSCHECK_ACTIVE_FALSE`
작성: ANU 직접 (2026-07-05 KST). 자료: doctrine `ANU_v3_v2_16_status_integrated_master_doctrine_260629` §35.4(레벨 2축) + GPT 2링크(G3/사업복귀 · 병렬 머지 규칙) + 이번 세션 머지 머신러리 실측(PR#263~266). **분석 문서 — 코드 0.**

## 결론 (한 줄)
**레벨 0~4를 병행하는 것 자체는 머지에 문제 없다.** 레벨(depth)은 머지 안전성과 **직교**한다(§35.4). 머지 위험은 레벨이 아니라 **①파일/자원 중첩 ②stale base ③동시 머지**에서 나오며, **"병렬 작업 허용 / 머지는 순차" + expected_files 무중첩 + serial_only 자원규칙 + 매 PR 현재 main 재검증**으로 전부 통제 가능하다.

## 1. 개념 정렬 — 레벨 = "품질 게이트 깊이", 머지와 직교 (doctrine §35.4)
- doctrine §35.4 **2축 분리**: 축①Depth(Lv0~4)=자동 품질게이트 깊이(전 레벨 자동), 축②Risk(비가역/credential/production/real fire/외부송신)=회장 escalate. **자동 vs 회장은 레벨이 아니라 위험이 가른다.**
- 따라서 "Lv4를 병렬로 돌린다"는 것 = 그 task에 자동 미팅/codex/gemini/3docs를 **더 깊게** 돌린다는 뜻일 뿐, 산출물은 여전히 **expected_files에 갇힌 코드 diff**다. **레벨이 머지 diff의 성격을 바꾸지 않는다.**
- 단 **간접 영향 1개**: 고depth(Lv3-4)는 자동 게이트가 많아 **PR 준비가 길어짐 → 브랜치 수명↑ → stale base 노출↑**. 위험 자체가 아니라 **stale base 관리 부담**이 커진다(§3-③에서 통제).

## 2. 현재 머지 머신러리 실측 (이번 세션 PR#263~266에서 검증된 사실)
- **expected_files scope-guard**: per-task diff가 expected_files에 갇혔는지 강제. 병렬 격리 1차 방어. ✓
- **worktree 격리 + lock 게이트**: 각 task 별도 worktree/branch, canonical 무접촉. pre-push는 `.tasks/locks/<id>.lock` 요구.
- **ruleset `required_review_thread_resolution=true`**: 모든 review thread(MED 포함) resolve해야 merge. → 병렬 PR마다 thread 정리 부담.
- **gemini-review-gate**: evidence 기반, 리뷰 posting 전 실행되면 stale-fail("no evidence yet") → `/gemini review` 트리거 + failed gate 1회 re-run으로 해소(PR#265/266 실증).
- **ff-only local sync**: merge 후 local main을 ff-only로만 전진(foreign dirty와 안 겹치면 통과·강제 0).
- **★ merge_group evidence auditor(task-2781/PR#265) = code-only, ACTIVE=false**. **Merge Queue 미활성** → **GitHub이 병렬 PR을 자동 정렬/직렬화하지 않는다.** = 자동 merge train 없음. 순차 머지를 운영이 직접 관리해야 함.
- **canonical truncate**: PR#263 P1(safe repo_dir invariant)로 구조 차단됨. 병렬이어도 canonical write fail-closed. ✓ 해소.

## 3. 병렬 시 실제 위험 시나리오 (cross-check)
**① 파일 중첩(같은 파일 2 task 병렬)** → 둘 다 머지 시 2번째 conflict 또는 1번째 덮어씀. → **expected_files 중첩 = 병렬 금지(serial_only)**. (GPT 링크2 일치)
**② 공유 자원(파일 달라도 의미 충돌)** → 같은 DB schema/migration · 같은 API contract · 같은 상태기계 · 같은 설정파일 · 같은 인프라 공통부. 파일명이 달라도 런타임 충돌. → **serial_only(한 번에 한 팀).** (GPT 링크2 일치)
**③ stale base cascade** → task A 머지 → main 전진 → task B가 옛 base라 vs-main diff에 A의 변경이 "삭제"처럼 보이는 **base-divergence false-positive**(이번 세션 task-2781/2782 실증). → **각 PR merge 전 현재 main 기준 rebase/clean cherry-pick + diff 재확인** 필수.
**④ 동시 머지** → Merge Queue 미활성이라 자동 직렬화 없음. 두 PR 거의 동시 merge하면 2번째가 stale base로 CI 깨지거나 충돌. → **머지는 한 번에 하나씩 순차 + 머지 후 다음 PR 새 main 재검증.**
**⑤ canonical truncate** → PR#263으로 해소(fail-closed). 병렬 무해. ✓
**⑥ duplicate dispatch(ANU 실수축)** → 병렬 dispatch 多 시 재발 위험↑. → dispatch.py **1회만·출력 파일캡처**(박제됨).
**⑦ G3 stale marker** → 병렬 task 각 finish-task closeout에서 stale g3-fail 마커가 `.done` 차단 → 수동 개입. **병렬에서 빈도↑**. → **G3 hygiene 닫으면 병렬 closeout 잡음 제거**(GPT 링크2 일치 — merge conflict 자체는 안 풀지만 closeout 대기열 꼬임 감소).

## 4. 병렬 사업개발 안전 운영 규칙 (판정)
**핵심 원칙: 병렬 작업 허용 / 머지는 순차.**
- **병렬 가능**: 파일/모듈 분리(예: InsuRo 프론트 특정 화면 · InsuRo API 특정 endpoint · InsuWiki 검색/문서 파트). **expected_files 무중첩**.
- **serial_only**: 같은 파일 · 같은 schema/migration · 같은 API contract · 같은 상태기계 · 같은 설정파일 · 같은 인프라 공통부.
- **task 착수 시**: expected_files 선언 → 다른 진행 task와 중첩 검사 → 무중첩만 병렬 배정. 중첩=serial. `parallel_policy: serial_only` 마커 활용.
- **PR 단계(순차)**: ①현재 main 기준 stale base 확인 → ②rebase/clean cherry-pick → ③diff가 expected_files에 갇혔는지 재확인 → ④CI green + Gemini HIGH0/CRITICAL0 + unresolved 0 → ⑤merge packet → ⑥**한 번에 하나 merge** → ⑦다음 PR 새 main 기준 재검증.
- **규모**: 병렬 task 3~5개 권장, 머지는 세션/일 단위 순차.
- ★ **Merge Queue 미활성 = 자동 정렬 없음** → 위 순차 게이트를 ANU/운영이 직접 관리(이게 유일한 "손 가는" 부분).

## 5. 레벨별 특이사항 (depth의 간접 영향)
- **Lv0(micro)**: 게이트 0, 즉시. merge 위험 최소. 단 여러 Lv0가 같은 파일이면 여전히 충돌 → expected_files 규칙 동일 적용.
- **Lv1-2**: CI/Gemini 기본 게이트. 표준 순차 머지.
- **Lv3-4**: 자동 미팅/codex/gemini/3docs 더 깊음 → 준비 길어짐 → **브랜치 장수명 → stale base 노출↑**. → Lv3-4 병렬은 **PR 직전 stale base 재검증을 더 자주**. (depth 자체는 무해, 수명이 부담.)

## 6. G3 hygiene를 먼저 닫는 실익 (①안이 병렬 사업개발에 유리한 이유)
- 병렬 task가 늘수록 각 finish-task closeout에서 stale g3-fail이 `.done`을 막을 확률↑ → 매번 사람이 마커 제거. **사업 개발 병렬 시 closeout 잡음이 계속 발목**. G3 hygiene 닫으면 이 병목 제거 → **병렬 closeout 안정**. (단 merge conflict/정렬은 §4 운영규칙이 담당.)

## 7. 최종 판정
1. **레벨 0~4 병행 = 머지 안전. 문제 없음.** (레벨은 depth=품질게이트 깊이, 머지와 직교.)
2. 위험은 **파일/자원 중첩·stale base·동시 머지** → **"병렬 허용/머지 순차" + expected_files 무중첩 + serial_only 자원규칙 + 매 PR 현재 main 재검증**으로 통제.
3. **Merge Queue 미활성**이라 자동 정렬은 없다 → 순차 머지 게이트를 운영이 직접 관리(활성화는 별도 대형 안건, 지금 아님).
4. **①(G3 hygiene → 사업복귀)이 병렬 사업개발에 유리** — G3 hygiene가 병렬 closeout 병목을 줄인다.
5. 다음 실행: GPT 링크1 승인대로 **G3 hygiene 착수 packet(코드 0)** → bounded task → merge → 인프라 closeout → 사업 복귀. Stage2/Merge Queue/required check는 진행 안 함.