# 수상한 잡화점 — ★ 조건 12개 풀 상세 명세서 v1

> 작성일: 2026-04-14 / 최신화: 2026-04-18
> 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
> 위임 근거: 2026-04-14 PD님 지시 "Phase 3 작업 전 진행 가능한 작업을 기획팀장이 판단하에 진행"
> 문서 성격: **P18 설계 문서화 의무** 이행 (Phase 2 §5 PD님 3차 승인의 조건 풀 12개에 대한 본문 작성)
> HOLD 준수: 본 문서는 **판정 로직·측정 변수·UI 표시·개발팀 구현 요청**까지만 다룸. 구체적 수치 최종 확정은 Phase 3 재개 후 시뮬 검증으로 수행

---

## 0. 본 문서의 목적·범위

### 목적
Phase 2 §5에서 PD님 3차 승인으로 확정된 **★ 조건 풀 12개**(+N7 보류)에 대해, 각 조건별:
1. 정의 (기본 의미)
2. 달성 판정 로직 의사코드
3. 측정 변수 (게임 런타임 중 추적해야 할 값)
4. UI 표시 방식
5. 개발팀 구현 요청 포인트
6. 엣지 케이스 및 주의 사항

를 한 곳에 정리한다. 개발팀이 **Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`)에서 구현해야 할 조건 판정 코드**의 설계 기반 자료.

### 범위 외 (HOLD 준수)
- **조건별 구체적 수치 최종 확정 금지** — 수치는 Phase 3 재개 후 시뮬 결과로만 산출
- **조건 풀 12개 추가·삭제 금지** — PD님 3차 승인으로 확정된 풀 유지
- **스테이지별 슬롯 배치 확정 금지** — 맵 패턴 사전분석 v1 §3-3 검증틀을 실제로 적용하는 것은 Phase 3 재개 후
- **카드 수치 조정 제안 금지** — 이슈 1·3 재논의 영역

### P18 준수 (설계 문서 필수 포함 사항)
| 항목 | 본 문서 위치 |
|------|------------|
| 결정의 배경 | §1 (Prove-2-of-3 체계 도입 배경) |
| 선택된 방향과 대안 | §2 (조건 풀 12개 선정 경위) |
| 구현 가이드라인 | §3~§5 (조건별 명세) |
| 검증 방법 | §6 (조건 판정 검증 체크리스트) |
| 변경 이력 | §8 |

---

## 1. Prove-2-of-3 체계 개요 (결정 배경)

### 1-1. 체계 구조

수상한 잡화점 스테이지의 3성(★★★) 클리어는 **Prove-2-of-3** 체계로 판정:

| 별 | 충족 조건 |
|----|----------|
| ★1 | 스테이지 클리어 (기본) |
| ★2 | 스테이지 클리어 + **슬롯2 조건 1개** 달성 |
| ★3 | 스테이지 클리어 + **슬롯2·슬롯3 조건 2개** 동시 달성 |

- **스테이지별 슬롯2·슬롯3은 사전 지정** (고정). 런타임 랜덤 없음
- 슬롯 지정은 스테이지 특성(노드 수·몬스터 배치 패턴·등장 몬스터 수)과 연동
- PD님 2차 승인 (2026-04-14)으로 대방향 확정

### 1-2. 조건 설계 원칙 (PD님 3차 승인 기준)

1. **유저가 확실히 컨트롤할 수 있는 조건**: 누적형·운 의존·빌드 의존 조건 부적합
2. **재도전 유도 방향성**: "무난하게 모든 조건을 완성"이 아니라 "특정 조건을 만족하기 위해 여러 번 재도전"을 유발하도록 다소 난해한 수준
3. **완화 방향 금지**: 조건 수치는 "완화"가 아닌 "재도전 유도" 방향 튜닝
4. **P17 배타 배치 규칙 준수**: 동시 배치 금지 조합 7종 회피

### 1-3. 조건 분류

Phase 2 §5 용어 기준:
- **C 계열** (Clear 조건): 스테이지 진행 과정 전체 관점 6종 — C1·C2·C3·C6·C9·C12
- **N 계열** (Node 조건 또는 Numeric 조건): 서브맵 단위 또는 특정 행동 기반 6종 — N1·N2·N3·N4·N5·N6
- **합계**: 12종 (C10 "성장의 증거" 보류, N7 "방어 성공" 보류, N8 "저 HP 완주" 변형 채택)

---

## 2. 조건 풀 12개 요약 테이블

| ID | 명칭 | 계열 | 수치 방식 | 유저 컨트롤 난이도 | 재도전 유도 강도 |
|----|------|------|---------|-----------------|---------------|
| C1 | 신속 | 시간 | 스테이지 총 소요 시간 ≤ 임계값 | 중 | 중 |
| C2 | 완벽 클리어 | HP | 스테이지 종료 시 PC HP = MaxHP | 중 | 고 |
| C3 | 고 HP 완주 | HP | 스테이지 종료 시 PC HP ≥ MaxHP × 70% | 저 | 저~중 |
| C6 | 포션 절제 | 카운트 | 스테이지 내 포션 사용 횟수 ≤ 임계값 | 저 | 중 |
| C9 | 보스 집중 | 카운트 | 보스 대상 유효 공격 ≥ 임계값 | 중 | 중 |
| C12 | 회피 주도 | 카운트 | 회피 발생 횟수 ≥ **서브맵수 × 3 이상** (유지 이상) | 고 | 고 |
| N1 | 빗맞힘 절제 | 카운트 | 빗맞힘 횟수 ≤ 임계값 | 중 | 중 |
| N2 | 피격 제한 | 카운트 | 피격 횟수 ≤ **서브맵수 × 1 이하** | 고 | 고 |
| N3 | 치명타 처치 | 카운트 | 치명타로 몬스터 처치 ≥ 임계값 | 중~고 | 고 |
| N4 | 쉴드 보존 | 비율 | 스테이지 종료 시 Shield ≥ **MaxShield × 30% 이상** | 중 | 중 |
| N5 | 후열 선공 | 순서 | 서브맵마다 최초 공격 대상이 후열 | 저~중 | 중 |
| N6 | 전열 선공 | 순서 | 서브맵마다 최초 공격 대상이 전열 | 저~중 | 중 |

> **주의**: 임계값 "이상/이하"의 구체적 숫자는 **본 문서에서 확정하지 않는다** (HOLD 범위). Unity MCP 시뮬로 재도전 유도 강도와 밸런스를 검증한 후 Phase 3 재개 시점에 PD님 승인으로 확정.

---

## 3. C 계열 조건 상세 명세 (6종)

### 3-1. C1 — 신속 (스테이지 총 소요 시간)

#### 정의
스테이지 시작부터 최종 보스 처치(또는 스테이지 종료)까지의 **총 경과 시간이 임계값 이하**.

#### 달성 판정 로직 (의사코드)
```
OnStageStart:
    stageTimer.start()

OnStageClear:
    totalTime = stageTimer.elapsed()
    if totalTime <= C1_threshold_of_stage(stageID):
        condition_C1_satisfied = true
    else:
        condition_C1_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|-------|------|------|---------|
| `stageTimer_elapsedSec` | float | 스테이지 시작부터 누적 시간(초) | 스테이지 시작 시 0으로 |

#### UI 표시
- **스테이지 진입 시**: 상단 또는 슬롯 표시 영역에 "목표: XX초 이내 클리어" (임계값 명시)
- **플레이 중**: HUD에 경과 타이머 실시간 표시 (기존 시스템 활용 여지 확인 필요)
- **스테이지 종료 시**: 결과창에 실제 소요 시간 vs 임계값 병기 + ✓/✗ 표시

#### 개발팀 구현 요청 포인트
1. 스테이지 경과 시간이 이미 측정되고 있는지 확인 (`StageManager` 또는 유사 클래스)
2. 포즈·메뉴 오픈 시간 제외 여부 결정 필요 — **기획팀장 초안**: 실제 전투 시간만 카운트, UI 포즈 중 시간 제외
3. 임계값은 **스테이지별 고정 테이블**로 관리 (예: `StageClearCondition.json` 또는 기존 테이블 확장)

#### 엣지 케이스
- **사망 후 재시작**: 재시작 시 타이머 0 리셋 (같은 스테이지 내 이어하기 없음 가정)
- **일시정지**: 포즈 시간 제외 여부는 구현 방식에 따름
- **매우 짧은 스테이지 (Stage 1~2)**: 임계값이 너무 타이트하면 첫 플레이에서는 거의 불가능 — 재도전 유도 목적에는 적합하나 Stage 1·2의 입문 부담 고려 필요

#### P17 배타 조합
- **(입문 1~6) C1 ∧ C3 동시 배치 금지** — 입문 구간 이중 부담
- 중반·후반은 허용

---

### 3-2. C2 — 완벽 클리어 (HP = MaxHP)

#### 정의
스테이지 **종료 시점에 PC의 HP가 MaxHP와 같음** (피격 후 회복도 인정).

#### 달성 판정 로직 (의사코드)
```
OnStageClear:
    if pc.currentHP == pc.maxHP:
        condition_C2_satisfied = true
    else:
        condition_C2_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|-------|------|------|---------|
| `pc.currentHP` | int/float | PC 현재 HP | 실시간 갱신 |
| `pc.maxHP` | int/float | PC 최대 HP (성장·카드 효과 반영) | 성장·버프 적용 시 갱신 |

#### UI 표시
- **스테이지 진입 시**: "HP Full 유지 필요" 뱃지
- **플레이 중**: HP 바가 100% 미만으로 떨어지면 해당 조건 위반 예고 상태 (아이콘 흐려짐 등)
- **스테이지 종료 시**: 결과창 ✓/✗

#### 개발팀 구현 요청 포인트
1. `pc.maxHP`가 카드·각성·장비 효과로 실시간 변하는 경우의 처리 필요
2. 스테이지 종료 시점 정의 명확화: 최종 보스 처치 직후 프레임 vs 결과창 오픈 시점
3. **중요**: 피격 후 회복하여 HP=MaxHP 도달해도 인정 (PD님 해석 확인 필요 시 문의)

#### 엣지 케이스
- **MaxHP 증가 효과 (G3 "MaxHP 2배" 등) 중 HP도 2배로 회복되는가?** — 개발팀 코드 확인 필요
- **종료 시점 판정 프레임**: 결과창 오픈 시점 HP 기준으로 통일 권장

#### P17 배타 조합
- **C2 ∧ N2 동시 배치 금지** — 피격 최소화 축 이중 부담

---

### 3-3. C3 — 고 HP 완주 (HP ≥ MaxHP × 70%)

#### 정의
스테이지 **종료 시점에 PC의 HP가 MaxHP의 70% 이상**.

> ※ 임계값 "70%"는 Phase 2 §5 원안 기반 초안. Phase 3 재개 후 시뮬 결과로 재튜닝 가능.

#### 달성 판정 로직 (의사코드)
```
OnStageClear:
    hpRatio = pc.currentHP / pc.maxHP
    if hpRatio >= C3_threshold:  // 초안 0.7
        condition_C3_satisfied = true
    else:
        condition_C3_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `pc.currentHP / pc.maxHP` | float | HP 비율 (0.0~1.0) |

#### UI 표시
- **스테이지 진입 시**: "HP 70% 이상 유지" 뱃지
- **플레이 중**: HP 바에 "70% 마커" 표시
- **스테이지 종료 시**: 결과창에 최종 HP 비율 + ✓/✗

#### 개발팀 구현 요청 포인트
- C2와 동일 구조. 임계값만 다름
- **임계값 상수화** 필수 (스테이지별 개별 튜닝 가능성 대비)

#### 엣지 케이스
- C2 충족 시 C3도 자동 충족 (HP=MaxHP는 ≥70% 만족). **논리상 문제 없음**, 같은 슬롯에 중복 배치만 피하면 됨

#### P17 배타 조합
- **(입문 1~6) C1 ∧ C3 동시 배치 금지**

---

### 3-4. C6 — 포션 절제 (포션 사용 ≤ N)

#### 정의
스테이지 내 **포션(회복 아이템) 사용 횟수가 임계값 이하**. "미사용"은 N=0 케이스.

#### 달성 판정 로직 (의사코드)
```
OnPotionUsed(potionType):
    potionUseCount += 1

OnStageClear:
    if potionUseCount <= C6_threshold:
        condition_C6_satisfied = true
    else:
        condition_C6_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 | 리셋 시점 |
|-------|------|------|---------|
| `potionUseCount` | int | 스테이지 내 포션 사용 누적 | 스테이지 시작 시 0 |

#### UI 표시
- **스테이지 진입 시**: "포션 사용 N회 이하" 뱃지
- **플레이 중**: 포션 슬롯 UI에 남은 허용 횟수 표시
- **스테이지 종료 시**: 실제 사용 vs 임계값 + ✓/✗

#### 개발팀 구현 요청 포인트
1. "포션"의 정의 명확화: HP 포션·MP 포션·기타 소모품 중 어느 것을 카운트할지
2. **기획팀장 초안**: HP 회복계 물약만 카운트 (메테오·전체 기절 같은 전투용 물약은 별도 조건으로 다룰지 추후 논의)
3. 패시브로 발동되는 회복 효과는 카운트 제외

#### 엣지 케이스
- **물약 빌드와의 충돌**: 물약 사용 시 추가 효과가 있는 카드(메테오·7.5초 무적·전체 기절)를 플레이하면 C6 달성 불가 → P17-2 배타 "C6 ∧ 물약 사용 유도 조건"으로 방지
- **회복 빌드와의 충돌**: 힐 카드 패시브 회복은 포션 사용이 아니므로 영향 없음

#### P17 배타 조합
- **C6 ∧ 물약 사용 유도 조건 동시 배치 금지**
- **C6 ∧ N4(쉴드 하한) 동시 배치 금지** — 회복 빌드 외 빌드 배제

---

### 3-5. C9 — 보스 집중 (보스 대상 유효 공격 ≥ N)

#### 정의
스테이지 내 **보스 몬스터를 대상으로 한 유효 공격 횟수가 임계값 이상**. "처치 우선순위를 보스에 둔 플레이"를 유도.

> ※ "유효 공격"의 정의·임계값은 Phase 3 재개 후 시뮬로 확정. 본 문서는 판정 틀만 제시.

#### 달성 판정 로직 (의사코드)
```
OnAttackLanded(attacker, target, damage):
    if attacker == pc and target.type == MonsterType.Boss and damage > 0:
        bossHitCount += 1

OnStageClear:
    if bossHitCount >= C9_threshold_of_stage(stageID):
        condition_C9_satisfied = true
    else:
        condition_C9_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `bossHitCount` | int | 스테이지 내 보스 피격(플레이어→보스) 누적 |

#### UI 표시
- **스테이지 진입 시**: "보스에 N회 이상 공격" 뱃지
- **플레이 중**: 카운터 표시 (권장)
- **스테이지 종료 시**: 실제 vs 임계값 + ✓/✗

#### 개발팀 구현 요청 포인트
1. **"유효 공격" 정의**:
   - **기획팀장 초안**: 데미지 > 0인 공격만 카운트 (빗맞힘·회피된 공격 제외)
   - 무적·반사 상태 몬스터 대상 공격의 카운트 여부 결정 필요
2. **Shield 흡수된 공격**: HP에 들어간 데미지가 0이라도 Shield에 데미지가 들어갔다면 카운트해야 함 (개발팀 판단 필요)
3. **DOT (도트 데미지) 처리**: 독·화상·처형 같은 지속 데미지 틱을 카운트할지 여부

#### 엣지 케이스
- **보스가 여러 체인 경우 (Stage 20 등 3체)**: 각 보스별 카운트를 합산
- **보스 미등장 서브맵 + 보스 등장 서브맵 혼재**: 전체 스테이지 합산이므로 문제 없음. 단, 보스 미등장 서브맵 비율이 너무 높으면 임계값 달성 불가
- **단독 보스 스테이지 (Stage 7·10·13)**: P17-5로 C9 배치 금지

#### P17 배타 조합
- **C9 ∧ 단독 보스·보스 미등장 스테이지 동시 배치 금지**
- 맵 패턴 재검증 필요 (맵패턴_사전분석_v1 §1·§2 참조)

#### 연동 작업
- 보스 혼용 등장 패턴 설계 (맵패턴_사전분석_v1 §2) 완료 후 임계값 재튜닝

---

### 3-6. C12 — 회피 주도 (회피 횟수 ≥ 서브맵수 × 3 이상)

#### 정의
스테이지 내 **PC의 회피 발생 횟수가 (해당 스테이지 서브맵 수 × 3) 이상**. PD님 지침 "유지 이상"으로 재도전 유도 강도 고수위.

#### 달성 판정 로직 (의사코드)
```
OnAttackMissed(attacker, target):
    if target == pc and miss_reason == "Avoid":
        avoidCount += 1

OnStageClear:
    requiredAvoid = submap_count_of_stage(stageID) * 3
    if avoidCount >= requiredAvoid:
        condition_C12_satisfied = true
    else:
        condition_C12_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `avoidCount` | int | 스테이지 내 회피 발생 누적 |
| `submap_count_of_stage(stageID)` | int | 해당 스테이지 서브맵 총 수 (고정 데이터) |

#### UI 표시
- **스테이지 진입 시**: "회피 X회 이상" (X = 서브맵수 × 3) 뱃지
- **플레이 중**: 카운터 표시 권장
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. **"회피"의 정의**: `Avoid_M` / `Avoid_R` 스탯에 의한 미스만 포함. 빗맞힘(`Miss`)과 구분 필요
2. 몬스터 공격에 대한 PC 회피만 카운트. PC 공격이 몬스터에게 회피된 것은 N1(빗맞힘 절제)의 "빗맞힘"에 해당 (별도 조건)
3. 서브맵 수는 스테이지별 고정 데이터 (`CreateMapConfig.json` 또는 유사)에서 조회

#### 엣지 케이스
- **서브맵 수 이상 스테이지 (Stage 7=4, 13=4, 16=3 등)**: 임계값이 낮아져 달성이 쉬워질 수 있음 — PD님 지침 "유지 이상"에 따라 스테이지별 추가 상향 검토 여지
- **회피율 극대화 빌드**: 회피 빌드와 시너지가 극도로 강함. P17에 "회피 빌드 유도 조건"과의 배타 조합이 필요한지는 추후 판단 (현재 미등재)

#### P17 배타 조합
- **현재 P17 7종 배타 조합에 C12는 포함되지 않음**
- 단, N1(빗맞힘 절제)과 구조 유사점 있음. 동시 배치 시 혼동 가능성 UI 점검 필요

---

## 4. N 계열 조건 상세 명세 (6종)

### 4-1. N1 — 빗맞힘 절제 (빗맞힘 ≤ N)

#### 정의
스테이지 내 **PC의 공격 빗맞힘(`Miss`) 횟수가 임계값 이하**. "정확도 플레이"를 유도.

#### 달성 판정 로직 (의사코드)
```
OnAttackMissed(attacker, target):
    if attacker == pc and miss_reason == "Miss":  // Hit 판정 실패
        missCount += 1

OnStageClear:
    if missCount <= N1_threshold:
        condition_N1_satisfied = true
    else:
        condition_N1_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `missCount` | int | 스테이지 내 PC 공격이 빗맞은 횟수 |

#### UI 표시
- **스테이지 진입 시**: "빗맞힘 N회 이하" 뱃지
- **플레이 중**: 카운터 (권장, 선택적)
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. `Miss` 스탯 vs `Avoid` 스탯을 **명확히 구분**해 판정 (공격자 Hit 실패 = Miss, 수비자 회피 성공 = Avoid)
2. 몬스터의 회피 성공(Avoid_M/R) 때문에 PC 공격이 빗나간 경우 — 이것은 "Miss"가 아니라 "Avoided"로 구분해야 함. **구분 불가능한 경우는 C9·C12와 상호 모순 발생 가능성** → 개발팀 점검 필요

#### 엣지 케이스
- **빗맞힘이 극히 드문 빌드 (높은 명중률 빌드)**: N1 달성이 거의 자동 → 임계값을 낮춰 난이도 확보 필요
- **C12와의 구분 UI**: "회피"와 "빗맞힘" 용어 혼동을 방지하는 UI 문구 필요

#### P17 배타 조합
- 현재 없음

---

### 4-2. N2 — 피격 제한 (피격 ≤ 서브맵수 × 1 이하)

#### 정의
스테이지 내 **PC가 피격받은 횟수가 (서브맵수 × 1) 이하**. Shield·HP에 데미지가 들어간 모든 피격 카운트.

#### 달성 판정 로직 (의사코드)
```
OnDamageReceived(target, damage):
    if target == pc and damage > 0:
        hitCount += 1

OnStageClear:
    maxHits = submap_count_of_stage(stageID) * 1
    if hitCount <= maxHits:
        condition_N2_satisfied = true
    else:
        condition_N2_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `hitCount` | int | 스테이지 내 PC 피격 누적 |

#### UI 표시
- **스테이지 진입 시**: "피격 X회 이하" (X = 서브맵수 × 1) 뱃지
- **플레이 중**: 카운터 표시 필수 — 피격 1회마다 긴장감 고조
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. **"피격"의 정의**:
   - **기획팀장 초안**: Shield 흡수 피격 + HP 데미지 피격 모두 카운트 (의도된 방어가 있었든 없었든 "맞았다"는 사실만)
   - Avoid된 공격은 카운트 제외
   - 반사·무적으로 무효화된 공격: **카운트 제외** (피해 발생 없음)
2. DOT는 데미지 틱마다 카운트하지 않고 "최초 부착 시 1회"만 카운트 (초안). 대안: 틱마다 카운트. 개발팀과 협의 필요

#### 엣지 케이스
- **서브맵 수 이상 스테이지**: C12와 동일. 임계값 재튜닝 여지
- **최종 보스 단 1체 스테이지**: 피격이 집중되므로 N2 달성 난이도 급증

#### P17 배타 조합
- **C2 ∧ N2 동시 배치 금지**

---

### 4-3. N3 — 치명타 처치 (치명타로 처치 ≥ N)

#### 정의
스테이지 내 **치명타 공격으로 몬스터를 처치한 횟수가 임계값 이상**. 치명타 빌드와 시너지.

#### 달성 판정 로직 (의사코드)
```
OnMonsterKilled(killer, target, killBlow):
    if killer == pc and killBlow.isCritical == true:
        critKillCount += 1

OnStageClear:
    if critKillCount >= N3_threshold:
        condition_N3_satisfied = true
    else:
        condition_N3_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `critKillCount` | int | 치명타로 처치한 몬스터 수 |

#### UI 표시
- **스테이지 진입 시**: "치명타 처치 N회 이상" 뱃지
- **플레이 중**: 카운터 + 치명타 발생 시 시각·음향 강화 (기존 크리 연출 활용)
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. "처치 타격" 판정: 몬스터 HP를 0으로 만든 **최종 타격이 치명타였는지** 확인. 중간 치명타는 카운트 안 됨
2. DOT로 처치 시: 최종 틱이 치명타 판정을 가지는 경우 처리 방법 결정
3. 처형·관통 같은 특수 스킬의 치명타 판정 여부 확인

#### 엣지 케이스
- **치명타율이 매우 낮은 빌드 (치명타 빌드 아닌 경우)**: 임계값 달성이 거의 불가능 → 입문 구간 배치 부적합
- **P17-6 "(입문 1~6) N3 단독 배치 금지"** — 치명타 빌드 미형성 구간이라 달성 곤란

#### P17 배타 조합
- **(입문 1~6) N3 단독 배치 금지**

---

### 4-4. N4 — 쉴드 보존 (Shield ≥ MaxShield × 30%)

#### 정의
스테이지 **종료 시점에 PC의 Shield가 MaxShield의 30% 이상**. "쉴드 관리 플레이"를 유도.

#### 달성 판정 로직 (의사코드)
```
OnStageClear:
    shieldRatio = pc.currentShield / pc.maxShield
    if shieldRatio >= N4_threshold:  // 초안 0.3
        condition_N4_satisfied = true
    else:
        condition_N4_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `pc.currentShield / pc.maxShield` | float | Shield 비율 |

#### UI 표시
- **스테이지 진입 시**: "Shield 30% 이상 유지" 뱃지
- **플레이 중**: Shield 바에 30% 마커
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. **Shield 시스템 구조 확인**: 재생 Shield / 1회성 Shield / 성소 Shield의 구분과 `pc.currentShield` / `pc.maxShield` 계산 방식
2. **MaxShield가 동적인가**: 카드·장비·각성으로 MaxShield가 변하는지 확인
3. **Shield 보유 불가능 빌드**: PC나 빌드에 따라 MaxShield=0인 경우 본 조건 배치 금지 (단독 스테이지 특성 필요)

#### 엣지 케이스
- **MaxShield = 0**: 판정 시 0으로 나누기 방지. 해당 상황은 N4 배치가 부적절한 스테이지
- **Shield 회복 카드 있는 경우**: Shield 회복계 카드가 자연 배치되면 N4 달성 쉬워짐

#### P17 배타 조합
- **C6 ∧ N4 동시 배치 금지** — 회복 빌드 외 배제

---

### 4-5. N5 — 후열 선공 (서브맵마다 최초 공격 대상이 후열)

#### 정의
**각 서브맵마다 PC가 처음 가하는 공격의 대상이 '후열 몬스터'**. 스테이지 내 모든 서브맵에서 성공해야 충족.

#### 달성 판정 로직 (의사코드)
```
OnSubmapStart(submapID):
    firstAttack_submapID = submapID
    firstAttack_registered = false

OnAttackLanded(attacker, target, damage):
    if attacker == pc and damage > 0 and firstAttack_registered == false:
        if target.position == Position.Rear:
            firstAttack_N5_success[submapID] = true
        else:
            firstAttack_N5_success[submapID] = false
        firstAttack_registered = true

OnStageClear:
    if all firstAttack_N5_success[submap] == true for all submaps:
        condition_N5_satisfied = true
    else:
        condition_N5_satisfied = false
```

#### 측정 변수
| 변수명 | 타입 | 설명 |
|-------|------|------|
| `firstAttack_N5_success[submapID]` | bool | 서브맵별 성공 여부 |
| `firstAttack_registered` | bool | 서브맵 내 최초 공격 확정 여부 |

#### UI 표시
- **스테이지 진입 시**: "모든 서브맵에서 후열부터 공격" 뱃지
- **서브맵 시작 시**: "후열 선공" 힌트 표시
- **최초 공격 후**: 성공/실패 즉시 피드백 아이콘
- **스테이지 종료 시**: ✓/✗

#### 개발팀 구현 요청 포인트
1. **몬스터의 전열/후열 판정**: `MonsterPatternList.json` / `ApprearMonsterPattern.json`의 배치 정보 또는 런타임 위치로 판정
2. **서브맵에 후열 몬스터가 없는 경우**: N5 달성 불가 → 해당 스테이지·서브맵에 N5 배치 금지
3. **"공격"의 정의**: 자동 공격만 카운트? 스킬 공격도 포함? — 기획팀장 초안: **모든 데미지 발생 공격**

#### 엣지 케이스
- **후열 몬스터 미등장 서브맵**: 해당 서브맵 때문에 스테이지 전체 실패 → 배치 전 서브맵별 몬스터 구성 점검 필수
- **정합성 검증**: 기획팀 CLAUDE.md "등장 패턴과 3성 조건의 정합성" 항목과 직결. 맵 패턴 확정 후 N5 배치 가능 스테이지 재식별 필요

#### P17 배타 조합
- **N5 ∧ N6 동시 배치 금지** — 타겟팅 자유도 박탈·논리 모순

---

### 4-6. N6 — 전열 선공 (서브맵마다 최초 공격 대상이 전열)

#### 정의
**각 서브맵마다 PC가 처음 가하는 공격의 대상이 '전열 몬스터'**. N5의 거울상.

#### 달성 판정 로직 (의사코드)
```
(N5의 후열 → 전열 치환. 나머지 동일)
if target.position == Position.Front:
    firstAttack_N6_success[submapID] = true
```

#### 측정 변수
N5와 동일 구조 (변수명만 N6).

#### UI 표시
- N5와 동일 구조 (문구만 "전열 선공")

#### 개발팀 구현 요청 포인트
- N5와 동일. 단 **전열 몬스터 부재 서브맵 없음**이 일반적이나 확인 필요 (보스 전용 서브맵 등 예외)

#### 엣지 케이스
- 후열만 등장하는 서브맵이 있다면 N6 배치 불가 — 흔치 않으나 확인 필요

#### P17 배타 조합
- **N5 ∧ N6 동시 배치 금지**

---

## 5. 공통 설계 원칙·횡단 이슈

### 5-1. 임계값 관리 원칙

1. **조건별 임계값은 스테이지 단위로 테이블화**: `StageStarCondition.json` (가칭) 또는 기존 스테이지 테이블 확장
2. **기본값 + 스테이지별 오버라이드 체계**: 전역 기본값을 두고 특정 스테이지만 덮어쓰기 가능
3. **임계값 튜닝은 Unity MCP 시뮬 실측 결과 기반** (Phase 3 재개 후)

### 5-2. 달성 판정의 공통 요구사항

- 모든 조건 판정은 **스테이지 종료 시점에 최종 결정**
- 중간 실패 확정 조건(C2·C3·N4 등 HP/Shield 기준)도 **UI는 실시간 경고**, 최종 판정은 종료 시점
- **중간 포기 (방 나가기·재시작) 시**: 해당 런의 조건 기록 모두 폐기

### 5-3. 측정 변수의 저장 구조

재개 시점에 개발팀이 구현해야 할 **런타임 상태 컨테이너**:

```csharp
class StageConditionTracker {
    // 시간
    float stageTimer_elapsedSec;
    // HP / Shield
    // (실시간 pc 객체 참조로 충분)
    // 카운터
    int potionUseCount;
    int bossHitCount;
    int avoidCount;
    int missCount;
    int hitCount;
    int critKillCount;
    // 서브맵 단위 bool
    Dict<submapID, bool> firstAttack_N5_success;
    Dict<submapID, bool> firstAttack_N6_success;
    bool firstAttack_registered_current;
    // ... 등
}
```

### 5-4. Unity MCP 시뮬 실측 검증 시 확인 항목

개발팀의 Unity MCP EditMode 시뮬 환경(`Assets/Sim/`) 구축 이후, 각 조건에 대해:
1. 동일 입력으로 Unity MCP 시뮬과 Unity 실 빌드의 조건 판정 결과가 일치하는가
2. 측정 변수의 스테이지 종료 시점 값이 일치하는가
3. 엣지 케이스 (Shield 흡수, DOT, 동시 처치 등)에서 판정 기준이 일치하는가

---

## 6. 조건 판정 검증 체크리스트 (Phase 3 재개 시 활용)

### 6-1. 조건별 단위 테스트 매트릭스

| 조건 | 테스트 1 (명확 통과) | 테스트 2 (명확 실패) | 테스트 3 (경계값) | 테스트 4 (엣지) |
|-----|------------------|------------------|----------------|----------------|
| C1 | 임계값 - 1초 완주 | 임계값 + 1초 완주 | 임계값 정확히 | 포즈 시간 제외 검증 |
| C2 | HP=MaxHP | HP=MaxHP-1 | HP=MaxHP(회복 후) | MaxHP 동적 변화 중 |
| C3 | HP=MaxHP×1.0 | HP=MaxHP×0.69 | HP=MaxHP×0.70 | MaxHP 동적 변화 |
| C6 | 포션 0 사용 | 포션 임계값+1 | 임계값 정확히 | 비 HP 포션 구분 |
| C9 | 임계값+1 공격 | 임계값-1 | 정확히 | Shield 흡수 공격 |
| C12 | 서브맵수×3+1 | 서브맵수×3-1 | 정확히 | Avoid와 Miss 구분 |
| N1 | 0 빗맞힘 | 임계값+1 | 정확히 | 몬스터 Avoid 제외 |
| N2 | 서브맵수-1 피격 | 서브맵수+1 | 정확히 | 반사 무효화 피격 |
| N3 | N+1 치명타 처치 | N-1 | 정확히 | DOT 처치 |
| N4 | 30%+1 Shield | 30%-1 | 정확히 | MaxShield=0 가드 |
| N5 | 모든 서브맵 후열 선공 | 1개 서브맵 실패 | - | 후열 부재 서브맵 |
| N6 | 모든 서브맵 전열 선공 | 1개 서브맵 실패 | - | 전열 부재 서브맵 |

### 6-2. 통합 검증

- **21개 스테이지 × 슬롯2·슬롯3 가상 배치**로 조건 판정이 오류 없이 작동하는지 전수 실측
- **맵 패턴 사전분석 v1 §3-3 체크리스트**를 이 단계에서 실제 적용 (현재는 틀만 준비됨)

---

## 7. 개발팀 요청서 초안 (구조만)

> ※ 정식 요청서는 `공유/기획팀→개발팀/` 폴더에 날짜·REQ번호 부여하여 생성. 본 문서는 **내용 초안**만 제공.

### 요청 개요
- **제목**: 수상한 잡화점 ★ 조건 12개 판정 로직 구현 요청
- **배경**: Phase 2 §5 PD님 3차 승인으로 조건 풀 12개 확정. Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`) 기반 구현
- **선행 조건**: 본 설계 문서(`3성조건_12개_상세명세_v1.md`) 개발팀 리뷰 완료

### 요청 내용 (요약)
1. §3·§4의 조건별 판정 로직을 C# 런타임에 구현
2. §5-3의 `StageConditionTracker`(또는 상응 구조) 설계
3. Unity MCP 시뮬 어셈블리와 실 빌드 간 공통 코드 경로 확보 (동일 판정기 사용)
4. §6-1의 단위 테스트 매트릭스를 자동 테스트로 구축
5. **임계값은 테이블 구동** — 코드 내 하드코딩 금지 (스테이지별 튜닝 가능성 대비)

### 우려 사항·문의
- §3·§4 각 조건의 "엣지 케이스"에 대한 개발팀 판단 필요
- **N7 방어 성공 조건**이 추후 13번째 조건으로 추가될 가능성 — `StageConditionTracker`를 확장 가능한 구조로 설계 권장

---

## 8. 변경 이력 (P18 요구 사항)

| 일자 | 변경 | 근거 |
|------|------|------|
| 2026-04-14 | 초안 작성 (v1) | PD님 재량 위임 지시 (Phase 3 HOLD 중 가능 작업) + Phase 2 §5 PD님 3차 승인 조건 풀 12개 |

**향후 예정 변경**:
- Phase 3 재개 후 시뮬 기반 임계값 확정 → v2
- N7 방어 성공 조건 추가 결정 시 → §4에 추가 + v2
- 개발팀 리뷰 피드백 수령 후 반영 → v1.1 or v2

---

## 9. HOLD 준수 확인

### 본 문서가 Phase 3 HOLD 영역을 침범하지 않음

| 체크 항목 | 상태 |
|---------|------|
| 성장 요소(각성·진화·장비·인장) 기여도 측정 | **미수행** ✓ |
| 시뮬레이션 실행 | **미수행** ✓ |
| 카드 수치 조정 제안 | **미수행** ✓ |
| 조건별 구체적 임계값 수치 확정 | **미수행** (초안 값은 Phase 2 §5 원안 인용에 한정) ✓ |
| 데이터 테이블 변경 | **미수행** ✓ |
| 스테이지별 슬롯 배치 확정 | **미수행** ✓ |

### 본 문서가 수행한 것
- 기존 PD님 3차 승인 **조건 풀 12개의 설계 명문화** (P18 의무 이행)
- 조건별 판정 로직 **의사코드 수준**의 구현 요구 정의
- 개발팀과의 **협업 문서 초안** (Phase 3 재개 시 즉시 활용)

---

## 10. 참조 문서

- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 (조건 풀 12개 PD님 3차 승인)
- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` §1·§2 (C9·N5·N6 배치 제약)
- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` §2-5 (조건 판정 재검증 항목 22~25)
- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` §4 (N7 보류·N8 변형 채택)
- `.claude/skills/너드나비스-코어룰/SKILL.md` P17 (배타 배치 규칙 7종) + P18 (설계 문서화 의무)
- `공유/조직공지/` Phase 3 HOLD 공지 (HOLD 범위 준수)
- 방향 전환 이력: [방향전환 히스토리 아카이브 §3성조건_12개_상세명세](../../../공유/조직공지/방향전환_히스토리_아카이브.md#2-프로젝트수상한잡화점기획3성조건_12개_상세명세_v1md-방향-전환)

---

*작성 완료: 2026-04-14*
*상태: P18 설계 문서화 의무 이행용 초안 / Phase 3 재개 후 임계값 확정 및 v2 전환 예정*