docs(BT13-GodDem): P3-B3-2 완결 — 기절·합성 게임 진입 7fe15ff+bfe738a·PD 로그 배치·.live 복원

- PD 지시 5건 전건 처리(IAP 보류·기절·합성 구현·설명 2건)·술어 2분 근본 해결
- PD 로그: 완결 마일스톤(기각안 명시)·대기 재구성(가챠 5건 잔여·신규 확인 2분류)·백로그 현행화
- .live/ P25 채널 복원(조직 생존급 2회 지적 해소)·노하우 3종(술어 분열·백업 변종·브리핑 staleness)
- 설계 v2 보강(§1-9-A 포화·§2-5 수집 판정)·대화로그 §79~§84

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.live/README.md

@@ -0,0 +1,14 @@
+# .live/ — P25 Live 증분 동기화 채널
+
+> **복원**: 2026-08-23 총괄PM (pm-auditor "조직 생존급" 지적 2회 — 디렉토리 부재로 `live_inject.sh` no-op·P25 비가동 상태 해소)
+> **구조**: plain 디렉토리 — C34(junction 체계) 폐기(2026-04-26) 이후 junction 비사용. 본 README는 `live_inject.sh`가 명시 스킵.
+
+## 용도 (P25)
+
+세션 중 반영 불가 파일의 변경분을 실시간 주입하는 채널. `.live/*.md`·`.live/*.json`에 줄이 추가되면 `live_inject.sh`(UserPromptSubmit hook)가 **증분(마지막 읽은 줄 이후)만** 다음 프롬프트에 주입한다 (한도 8,000자·파일별 커서는 `~/.claude/.burningtimes_throttle/`).
+
+## 규약
+
+- 파일 형식: append-only (줄 추가만 — 수정·삭제는 커서 어긋남)
+- README.md는 주입 제외 (본 파일)
+- 대용량 금지 (한도 초과 시 "Read 직접 확인" 안내로 대체됨)

memory/org/feedback_auditor_briefing_staleness.md

@@ -0,0 +1,22 @@
+---
+name: auditor-briefing-staleness
+description: PM이 감사관에게 전달한 경과 요약(브리핑)이 실측보다 뒤처져 감사 대상 자체가 어긋나는 패턴 — 병렬 진행 중 브리핑 작성 시점과 감사 착수 시점 사이 상태 드리프트 (2026-08-23 P3-B3-2 완결 감사 실증·pm-auditor 등재 요청)
+type: feedback
+---
+
+# 감사 브리핑 staleness — 병렬 진행 중 감사 요청문이 실측을 뒤처지는 패턴 (2026-08-23 BT13)
+
+## 실증
+
+P3-B3-2 완결 PD 로그 갱신 감사에서, PM 브리핑은 대화로그 §80 시점("사후 검토 대기·§74~§81") 기준으로 작성됐으나 감사 착수 시점에는 §83까지 2사이클(사후 감사 도착·술어 2분 후속 커밋 `bfe738a`)이 이미 진행돼 있었다. 감사관이 브리핑을 신뢰하지 않고 실측했기에 stale 문안의 SOT 고착을 차단했지만, 실측 생략 감사였다면 "3엔트리·1커밋 뒤처진" 마일스톤이 통과됐을 것이다.
+
+## Why
+
+C41 병렬 진행 체계에서 PM이 감사를 background로 발주하면, 발주~착수~완료 사이에 다른 에이전트(designer·dev)의 산출이 계속 도착한다. 브리핑은 발주 시점 스냅샷이라 구조적으로 낡는다. 감사관은 브리핑을 사실로 전제하면 안 되고, PM은 브리핑이 낡을 수 있음을 전제로 발주해야 한다.
+
+## How to apply
+
+1. **PM**: 감사 호출 프롬프트 발신 **직전** 대화로그 tail·`git log -1`(관련 레포 전부)을 재확인하고 브리핑에 "본 브리핑 기준 시점 = §N·커밋 X" 스탬프를 명기한다. 병렬 작업이 진행 중이면 "감사 중 후속 도착 가능 — 실측 우선" 문구를 넣는다.
+2. **감사관**: 브리핑은 감사 대상이지 근거가 아니다 — 대화로그 말미·HEAD·origin을 먼저 실측하고 브리핑과의 차이를 지적 항목으로 보고한다(본 건 감사관이 정확히 수행).
+3. 갱신 대상 문서(PD 로그 등)에 마일스톤을 쓸 때는 브리핑이 아니라 **집행 직전 재실측 상태**를 기준으로 문안을 확정한다.
+4. 관련: [[feedback_pm_context_restoration_failure]] (복원 누락)·C5·C13·C41

memory/org/feedback_backup_filename_format_violation.md

@@ -63,6 +63,10 @@ PD님 질문 "C34 확장 집행 완료 과정에 C6-1 원본 보호 규칙을
 - `feedback_pm_over_conservative_interpretation.md` (관성적 답습은 과도 보수의 변종)
 - `feedback_memory_junction_repo_root_misdirect.md` (C34 확장 세션 동반 집행)
 
+## 변종 6항 — .cs 백업의 원본 확장자 탈락 (2026-08-23 보강)
+
+GodDem P3-B3-2 구현 백업(`공유/개발팀_백업/GodDem/`)에서 **확장자별 분기 오염** 신변종: 동일 디렉토리에서 `.csv`(`SurvivalUpgrade.csv.bak_..csv`)·`.unity`·`.asset`은 표준 준수하나 **`.cs` 계열만** `SurvivalUnit.bak_20260823_0329.cs`로 **원본 확장자 탈락**(정답: `SurvivalUnit.cs.bak_20260823_0329.cs` — `{원본명}`에 확장자 포함). 최초 1건이 이후 .cs 전건 오염(관성 답습 재현). 데이터 손실 0·복구성 정상·`grep .bak_2026` 탐지성만 저하 — 소급 개명 불요·**차기 백업부터 표준 적용**. 백업 생성 시 "원본 파일명 전체(확장자 포함) + `.bak_{일시}` + 원 확장자 재부착" 템플릿 재확인 의무.
+
 ## 교훈
 
 **"기존 코드 답습 ≠ 조직 표준 준수"**. 신규 스크립트 작성 시 가장 가까운 기존 코드를 참조하는 건 생산성 측면에서 자연스러우나, **해당 기존 코드 자체가 이미 조직 표준 위반일 가능성**을 전제로 규약 대조가 필수. C34 Live junction 스크립트가 2026-04-18에 이미 비표준 포맷으로 도입되어 그 후 모든 파생 스크립트 오염 — 최초 위반이 길게 연쇄되는 전형 사례.

memory/org/feedback_predicate_semantic_split_fanout.md

@@ -0,0 +1,31 @@
+---
+name: predicate-semantic-split-fanout
+description: 데이터 집합 확장 시 기존 술어(predicate)가 겸직하던 두 개념이 분열 — 수치 호출부만 발견·수정되고 레이블·안내문 호출부는 술어가 여전히 true라 통과 (2026-08-23 GodDem P3-B3-2 IsGachaItem 실증·pm-auditor 등재 요청)
+type: feedback
+---
+
+# 술어 의미 분열 팬아웃 — 집합 확장 시 겸직 술어의 잔여 호출부 누락 (2026-08-23 BT13)
+
+## 패턴
+
+데이터 집합(카탈로그·풀·테이블)을 확장하면, 기존 술어가 겸직하던 두 개념이 갈라진다. 구현자는 **수치가 눈에 띄게 틀어진 호출부만** 발견·수정하고, **레이블·안내문만 틀어진 호출부는 통과**시킨다.
+
+## 실증 (2026-08-23 GodDem P3-B3-2)
+
+카탈로그 15→26종 확장(합성 전용 11종 추가)으로 `IsGachaItem(Grade≥3)`이 "가챠 풀 등재(6종)"과 "강화 제외 대상(17종)"으로 분열. 개발팀장이 `GachaCollectedCount/GachaTotalCount`(수집 목표 6→17 부풀림 = 도달 불가 진행도)는 자력 발견·해소했으나, `Hero.cs:485` 토스트(합성 전용품에 "뽑기에서 획득" **거짓 안내**)를 포함한 6개 호출부는 미처리 — 커밋 후 pm-auditor 사후 감사로 적발·후속 커밋 정정.
+
+## 왜 놓치는가
+
+숫자 오류는 즉시 눈에 띄고, 문자열 오류는 술어가 여전히 `true`를 반환하므로 컴파일·정적 검증 어디에도 걸리지 않는다.
+
+## 차단 절차 (How to apply)
+
+1. 카탈로그·풀·테이블에 항목을 추가하는 작업에서, 그 집합을 판정하는 **모든 술어를 grep으로 전수 열거**하고 호출부별로 "이 호출부가 원하는 개념이 무엇인가"를 1줄씩 답한다.
+2. 호출부 개별 패치는 proxy(C2-2) — **근본 해결은 술어를 개념 수로 쪼개는 것**(예: `IsGachaPoolItem`〔CSV 등재〕 신설 + `IsGachaItem`〔Grade≥3 = 강화 제외〕 의미 명문화). 각 호출부가 어느 개념을 원하는지 컴파일 시점에 드러난다.
+3. **감사관 체크 편입**: 커밋 전 감사 시 `git diff --cached`에 컬렉션 확장이 있으면 해당 컬렉션 술어의 전 호출부를 강제 열거한다.
+
+## 연관
+
+- C2-2 (proxy 개선 표시 의무) · C3 (자진 보고 — count 2곳 해소는 정확 이행·잔여 6곳이 미보고 리스크였음)
+- `feedback_shop_exposure_filter_source_both.md` (노출 소스·소비 목록 양쪽 검증 — 동일 계열: 한쪽 축만 보고 완료 판정 금지)
+- `feedback_scriptable_object_field_blanket_fill.md`

공유/기획/GodDem/2026-08-23_P3B3-2_스턴_합성_설계_v2.md

@@ -135,6 +135,18 @@ void Awake()
 
 **m-3 정정**: "완주 유저는 평균 초당 0.12회 기절 트리거 가능" 서술에 **전제를 명시**한다 — 이 수치는 **공격 쿨다운 약 3초**(`AttackCooldown` 저투자 초반 기준, 초당 1/3회 공격) 가정 시 0.36(36%)×(1/3)=0.12회/초로 산출된 것이다. `attack_speed_add` 투자로 쿨다운이 짧아지면 초당 프록 시도 자체는 늘어나 이 0.12 수치는 커지지만, **§1-5의 3초 면역 상한이 발동 "빈도"의 실질 상한이므로 공격속도가 얼마나 빨라지든 최종 결론("최소 3초당 1회 상한")은 변하지 않는다** — 이 강건성(robustness)이 시간 기반 상한 설계(§1-5)를 확률 기반 캡보다 우선한 핵심 근거임을 재확인한다.
 
+## 1-9-A. 합성 완주 구간 StunChance 포화 — 후속 튜닝 관찰 (신규, 개발팀장 구현 관측 반영)
+
+**관측(개발팀장, GodDem `7fe15ff` 구현 중 — PM 상신)**: §1-9의 36% 기대 발동률은 **가챠 6종 완주**(각 슬롯 가챠 배출 등급 그대로, id10~15) 기준이다. **2부 합성까지 완주**(6슬롯 전부 G6 도달)하면 기대 StunChance는 **약 1.20(하한 0.96)**으로 크게 뛴다.
+
+**독립 재계산(C44)**: G6 등급 옵션 슬롯은 5개(§2부 무변경 전제) — 4종(hit/stun/retaliate/combo)이 먼저 1슬롯씩 확정 배정되고(스턴 슬롯 1개 확정) 5번째 슬롯만 4종 중 재추첨(1/4 확률로 스턴 중복). 아이템 1개당 기대 스턴 슬롯 수 = 1 + 0.25 = 1.25, 값 16% 적용 시 아이템당 기대 기여 = 1.25×0.16 = **20.0%**. 6슬롯 전부(Hat·Boots·Weapon·Armor·Charm·Ring) G6 도달 시 총합 = 6×20.0% = **120.0%(=1.20)** — 관측치와 일치. 하한(5번째 슬롯이 전부 스턴 미중복인 최악 경우) = 6×16.0% = **96.0%(=0.96)** — 이 역시 일치.
+
+**게임이 깨지지 않는 이유(§1-5 시간 상한이 실질 지배)**: `SurvivalStunEffect`는 확률과 무관하게 **지속시간(일반 1.0초·보스 0.3초) + 면역창(그 2배)**의 순환 구조다. StunChance가 100%를 넘어도 "다음 공격에서 또 기절시킬 수 있는가"는 면역창이 끝났는지에만 좌우되므로, 무력화 지속률은 **지속시간÷(지속시간+면역시간) = 지속시간÷(지속시간×3) = 1/3 = 33.3%로 일반·보스 동일하게 고정**된다(보스 지속시간 축소 제안·확정 여부(§4 PD확인 1번)와 무관하게 이 비율 자체는 불변 — 분자·분모가 같은 배수로 줄기 때문). 즉 StunChance가 36%든 120%든 300%든 **무력화 지속률 상한은 항상 33.3%**이며, 이 상한을 설계한 §1-5의 "확률 캡이 아니라 시간 캡" 결정(v1 원 설계 의도)이 정확히 이런 포화 상황에 대한 방어선으로 기능하고 있음이 실제 구현·관측으로 재확인됐다.
+
+**정직 기재(해소책 설계 안 함, PM 지시)**: 결과적으로 **가챠 완주(36%)를 넘어 2부 합성까지 투자하는 구간에서는 stun_rate 옵션의 한계 가치가 소멸**한다 — 이미 6슬롯을 G6까지 합성한 플레이어에게는 스턴 관련 옵션 롤이 더 나와도 무력화 지속률(33.3%)이 조금도 개선되지 않는다(반면 retaliate/combo/hit 3종은 §8-4 승산항에 계속 선형 가산되므로 이런 포화가 없다 — stun_rate만의 고유한 특성). 이는 **버그가 아니라 확률형 스탯과 시간 기반 상한이 만나는 지점의 자연스러운 수학적 결과**이며, 본 절은 이 사실을 기록하는 데 그친다 — 완화책(예: 등급별 지속시간 체증, 스턴 상한 완화 등)은 설계하지 않는다. 플레이테스트로 실제 체감(33.3% 무력화가 실제로 얼마나 강력한지)을 관찰한 뒤 튜닝 여부를 판단하는 것이 순서에 맞다(§8 후속조치).
+
+**분류**: PD 확인 목록(§4)에는 추가하지 않는다 — PD의 택일이 필요한 결정 사안이 아니라(현재 수치 그대로도 게임이 깨지지 않음, C1 "구현해" 지시가 이미 이행 완료 상태), 플레이테스트 데이터가 쌓인 뒤 밸런스 조정 필요성을 재판단할 **후속 튜닝 관찰 항목**의 성격이라고 판단했다. §5(리스크) R-S3으로 등재해 추적한다.
+
 ## 1-10. 코드 터치포인트 — M-3·M-4 반영 갱신
 
 | 파일 | 변경 |
@@ -208,6 +220,8 @@ Survivor.io 검색 결과(출처 3건)·B2 v2 §8 forging 골격·`TryFuse()`/`O
 
 **가챠 풀 영향 — 없음**(무변경, v1과 동일 원칙): 신규 11종은 가챠 확률 테이블(v3 §10-1)에 편입하지 않는다. 합성 전용 획득.
 
+**수집 진행도·획득 안내 판정 기준 — 구현 정정 반영(P18·C39 SOT 정합)**: 신규 11종도 전부 Grade≥3이라, "Grade≥3 카탈로그 아이템 수"를 기준으로 삼는 낡은 판정으로는 가챠 수집 목표가 6종(실제 뽑을 수 있는 대상)이 아니라 17종(6기존+11신규)으로 부풀어 "6/17" 형태의 영구 미완 표시가 발생한다 — **합성 전용 11종은 가챠 수집 진행도·뽑기 획득 안내 대상이 아니다**(가챠 풀 미등재이므로 애초에 뽑을 수 없다). 구현 단계에서 판정 기준을 "Grade" 대신 **가챠 풀 CSV 등재 여부**(`SurvivalGachaTable.AllItemIds()`, 기존 6종만 포함)로 교정했다 — 화면 표시(6/6) 자체는 v3 설계 그대로 무변경, 판정 근거만 정정. 미보유 안내 문구도 술어 2분(`IsGachaPoolItem` 신설)으로 갈라 합성 전용품은 "뽑기 대상"이 아니라 **"합성으로 획득"**으로 안내한다. 본 SOT(설계 문서)와 구현 판정 근거를 일치시켜, 이후 이 문서만 읽는 독자도 "왜 17종이 아니라 6종 기준인지"를 알 수 있게 명시한다.
+
 ## 2-6. PowerScore 단조성·슬롯 플로어 검증 — 각 행 배수 직접 기재(C-2 재발 방지)
 
 **C-1 채택의 자동 부수 효과**: 도달 불가 7종(구 id25·28·29·31·32·33 및 Weapon 구 G3)을 제거한 결과, **잔존 11종은 전부 기존 6종(v3 감사 통과본) 위에 쌓이는 상위 등급뿐**이다 — 각 슬롯의 "최하 진입 등급"(플로어 대비 마진을 검증해야 하는 유일한 병목 지점)은 v3에서 **이미 검증 통과한 6종 그대로**이므로, 신규 11종은 전부 그보다 PowerScore가 크다는 사실 하나로 마진도 자동으로 더 크다. 아래 표는 이를 "선언"이 아니라 **각 행 직접 계산**으로 증명한다(감사 재발 지적 반영):
@@ -437,6 +451,7 @@ void OnClickForge(SurvivalSlot slot, int grade)
 | ID | 리스크 | 심각도 | 내용 |
 |---|---|---|---|
 | R-S1·R-S2 | (v1과 동일) | — | 무변경 |
+| **R-S3(신규)** | 합성 완주 구간 StunChance 포화·stun_rate 한계 가치 소멸 | 낮음(정보성, 게임 붕괴 없음) | §1-9-A — 가챠 완주 36%→2부 합성 완주 시 기대 1.20(하한 0.96), §1-5 시간 상한(무력화 지속률 33.3% 고정)이 실질 지배해 100% 초과분은 체감 개선 없음. 해소책 미설계(정직 기재만, 후속 튜닝 관찰) |
 | **R-F1(갱신)** | 합성 완주선(2,140,000G 상한~2,011,900G 정밀치) 근사치 오차 | 중(🟡, v1 대비 하향 — 골드 부분은 감사 실측치라 정밀도 상승, 뽑기 부분만 상한/정밀 병기) | §2-8 I-A 정밀치(max 방식, 96.3회)와 상한(합산 방식, 415.4회) 사이의 진짜 값은 몬테카를로 미실행으로 미확정 |
 | R-F2·R-F3 | (v1과 동일) | — | 무변경. R-F3(Twinborn 미이식)은 §2-4 Ring 처리(PD확인 6번)와 연계 가능성 인지 |
 
@@ -463,12 +478,13 @@ void OnClickForge(SurvivalSlot slot, int grade)
 | 2026-08-23 | balance-designer | v1 신규 | PD 직접 지시 2건 |
 | 2026-08-23 | balance-designer | **v2 신규 — plan-auditor 차단 반영**. 1부: M-3(레지스트리 누수, 사망 시 명시 제거 채택)·M-4(ClearAll을 Awake 병치로 이동)·m1~3(표기·전제 정정). 2부: C-1((다) 등급사다리 비대칭 채택, 24→17종)·C-2(자동 해소, 배수 직접 기재)·C-3/M-1/M-2(TryForge 재화무접촉 재작성)·M-5(경제 재산출, 1,973,400G 감사치 정합) | PM 회송 — `_v1_감사결과.md` 전문 |
 | 2026-08-23 | balance-designer | **v2 정정 5건(2차 편집, v3 생성 아님) — plan-auditor 재검증 조건부 통과 반영**(개발팀장 구현 병행 착수 상태). Major-1(`RerollOneGachaOption` 컴파일 오류 — 기본 인자 `=null`+null 가드로 해소, §2-11#6 검증기준을 "컴파일 성공"으로 정정)·m-A(§2-6 max값 100.0→109.0 오기 정정+헷지 문장 삭제)·m-B(§2-8 Ring 첫 카피 획득비용 66.7회/26,700G 반영)·m-C(§0·§2-7 "4개소"→"5개소"+정확한 라인 인용)·I-A(§2-8 정밀치 96.3회/38,520G 병기, 상한 415.4회와 병행 표기) | PM 재검증 회송 — 조건부 통과(기절 즉시 적격·합성 Major-1 해소 후 적격) |
+| 2026-08-23 | balance-designer | **v2 구현완결 후 보강 2건(3차 편집, GodDem `7fe15ff` 게임 진입·push 완료 반영)**. ①§1-9-A 신규(StunChance 포화 — 가챠완주 36%→합성완주 기대1.20/하한0.96 독립검산 일치, §1-5 시간상한이 무력화지속률 33.3% 고정으로 실질지배·게임 붕괴 없음·정직기재만·해소책 미설계, §5 R-S3 신규 등재, PD확인 목록 비등재·"후속 튜닝 관찰" 분류) ②§2-5 신규 문단(합성 전용 11종의 가챠 수집진행도·획득안내 대상 제외 — 구현이 판정기준을 Grade에서 가챠풀 CSV 등재여부로 교정한 사실을 SOT에 정합 반영, P18·C39) | PM 상신 — 개발팀장 구현 관측 2건(StunChance 포화·수집진행도 판정기준 교정) |
 
 ---
 
 ## 8. 후속 조치 (본 v2 범위 밖)
 
-1. **plan-auditor 모드A 재검증 — 조건부 통과(Major-1 해소로 최종 적격)**. 개발팀장이 동일 해소안으로 구현 병행 착수한 상태(PM 확인).
-2. **PD 확인 6건**(§4) — 보스 기절·지속시간 수치·확정형/확률형 상충·합성 비용·UI 배치·Ring 포함 여부.
+1. **구현 완료 — GodDem `7fe15ff` 게임 진입·push 완료**(plan-auditor 조건부 통과 후 Major-1 PM 지정안으로 구현·C49 체인 완결). 본 문서가 그 확정 사양 SOT.
+2. **PD 확인 6건**(§4) — 보스 기절·지속시간 수치·확정형/확률형 상충·합성 비용·UI 배치·Ring 포함 여부. PM 취합 후 상신 필요.
 3. **합성 완주선 정밀 시뮬레이션**(R-F1) — 몬테카를로, 슬롯 간 뽑기 공유 효율 반영.
-4. **개발팀장 구현 착수** — C49 표준(설계→plan-auditor 검증→구현→PM 커밋).
+4. **StunChance 포화 플레이테스트 관찰**(R-S3, §1-9-A) — 33.3% 무력화 지속률의 실제 체감 확인 후 튜닝 필요성 재판단.

공유/대화로그/GodDem/2026-08-23.md

@@ -171,3 +171,78 @@
 - **연쇄 정합성**: §2-8 갱신으로 총액이 2,113,000G→2,140,000G(상한)/2,011,900G(정밀치)로 바뀌어, §3(층간교차영향)·§5(R-F1 리스크)의 구 수치 참조 2곳도 함께 갱신해 문서 전체 정합성 확보(grep 재확인 완료).
 - **산출물**: `공유/기획/GodDem/2026-08-23_P3B3-2_스턴_합성_설계_v2.md`(같은 경로, 424→474줄)
 - **후속**: plan-auditor 재검증에서 조건부 통과 판정을 이미 받았고(§77-B, PM 기록) 개발팀장이 동일 해소안으로 구현을 병행 착수한 상태 — 본 문서 정정은 그 구현과 별도 트랙으로 완결. PD 확인 6건(§4)은 PM 취합 후 상신 필요.
+
+## 79. P3-B3-2 구현 완료 — 기절 전투 로직 + 장비 합성 (개발팀장, GodDem 로컬 커밋 7fe15ff)
+
+- **선행 실측(C39·C39-10)**: 설계 v2 전문 + v1 승계 절(§1-1~1-4·§1-6·§1-8·§2-9) Read. GodDem 코드 직접 Read — `SurvivalUnit.cs` 전문·`SurvivalMeta.cs` 전문·`SurvivalItemCatalog.cs`·`SurvivalGachaTable.cs`·`SurvivalDebuffStack.cs`·`SurvivalActiveSkillRunner.cs`·`SurvivalBattleManager.cs`(RecalcPlayer/SpawnWave/Restart/ExitToLobby)·`SurvivalLobbyController.cs`/`.Gacha.cs`/`.Growth.cs`(TrySpendGold)/`.Hero.cs`/`.EquipUpgrade.cs` · CSV 3종. **C6 백업 6종** `공유/개발팀_백업/GodDem/*.bak_20260823_0329.cs`(`.gitignore:66 *.bak_*` 추적 제외 확증).
+- **1부 기절**: `SurvivalStunEffect.cs` 신규(DebuffStack 정적 레지스트리 패턴 재사용) — 지속 1.0초·면역창 ×2·보스 0.3초. `GachaStunChance()` 신설(`GachaAttackRatio` 동형 순회·`KeyStun` 상수 사용, 매직스트링 회피). `DoAttack` 프록(CriticalRate 굴림 동형)·`FixedUpdate` 조기반환 동결(`_timer` 증가 이전 = 쿨다운 동반 정지). **M-3** `IsDead=true` 단일 지점(`SurvivalUnit.cs:163`)에 `Remove(this)` 배선. **M-4** `SurvivalActiveSkillRunner.Awake()`에 `ClearAll()` 병치 — `Restart()`·`ExitToLobby()` 양쪽이 `LoadScene`임을 실측 확인해 3경로 커버 검증. 시각 피드백은 `skeleton.SetColor` 틴트(SetHit 과 동일 경로 = 공유 머티리얼 무오염).
+- **2부 합성**: 카탈로그 11종 신규(id16~26). `CanForge`(순수 판정)/`TryForge`(재화 무접촉)/`ForgeCostAt` 분리 — **SurvivalMeta 실행 코드 재화 참조 0건**(잔존 5건 전부 주석). **M-1** `RerollOneGachaOption(int,int,GachaPullResult result = null)` 기본 인자 + L787-788 앞 null 가드(PM 지정 해소안 그대로). **M-2** `targetWasNew` 소비 전 판정. 장착 해제 블록 `TryFuse` L298-300 동형·`Save()` 배선. UI `SurvivalLobbyController.Forge.cs` 신규 — 가챠 패널 제목 자리를 탭 바(뽑기\|합성)로 교체, 부위 선택 + 전이 행 최대 3단, `TrySpendGold` 선차감 후 `TryForge`.
+- **설계 재량 판단(구현 계층)**: 사다리를 코드에 박지 않고 `ForgeSourceGrades(slot)`가 카탈로그에서 유도하도록 구성 — Ring 제외가 예외 분기가 아니라 "위 등급 부재 → 빈 목록"의 자연 결과가 된다(§2-4 의도를 데이터 주도로 표현). 조회 중복 제거용 `SurvivalItemCatalog.GetBySlotGrade` 신설.
+- **구현 중 발견·해소(C3 자진 보고 — 설계 v2 미기재)**: 신규 11종이 전부 Grade≥3이라 `GachaCollectedCount`/`GachaTotalCount`(판정 기준 = "Grade≥3 카탈로그 수")의 **수집 목표가 6 → 17로 부풀 뻔했다** — 가챠를 완주해도 영영 "6/17"이 뜨는 도달 불가 진행도. 판정 기준을 **가챠 풀(CSV) 등재 여부**로 교정하고, 이 용도로 이미 존재하나 미소비였던 `SurvivalGachaTable.AllItemIds()`("풀에 등장하는 전체 아이템 ID(수집 목표 산출용)")를 소비처로 연결. 현 CSV에서 6을 돌려주므로 **표시 무변경**(회귀 없음).
+- **밸런스 관측 보고(구현 산물 아님·후속 판단 필요)**: 합성 완주(6슬롯 전부 G6) 시 기대 `StunChance` ≈ **1.20(하한 0.96)** — 사실상 매 타격 확정 발동이다. 설계 §1-9의 36%는 **가챠 6종 완주** 기준이라 합성 완주 구간을 다루지 않았다. 다만 §1-5 시간 상한이 실질 상한이라 무력화 지속률은 **일반·보스 모두 정확히 33.3%**로 고정된다(면역창 = 지속 ×2 이므로 보스 축소가 지속률을 바꾸지 않는다). 즉 확률 폭주가 상한을 무너뜨리지는 않으나, 확률 축이 완주 구간에서 의미를 잃으므로 **stun_rate 투자 가치의 완주 후 소멸**을 balance-designer 재검토 대상으로 상신.
+- **검증**: Roslyn 실컴파일(Assembly-CSharp 전체·신규 2파일 rsp 추가) **에러 0·신규 경고 0**(기저선 사전 측정 후 대조). 카탈로그 26종 소스 파싱 대조 — 신규 11종 스탯·PowerScore §2-5 전량 일치, 기존 id1~15 무변경, (부위,등급) 유일, 부위 내 PS 단조, 6슬롯 합성 총액 **1,973,400G** §2-8 일치, Ring 사다리 0. 가챠 회귀: `SurvivalMeta.cs` **삭제 라인 전수 확인** — 수집 카운트 2종·`RerollOneGachaOption` 시그니처 외 삭제 0(`PullGachaOnce`·`RollGachaOptions`·천장·`Draw` 무변경), CSV 3종 무변경(`git diff --name-only -- '*.csv'` 공집합), Pool2 가중치 산술 재확인(28.05/28.05/18.70/18.70/5.00/1.50%). 신규 유저 22/400 불변(카탈로그 추가는 `Equipped` 경유만 소비).
+- **미검증(C5 정직 고지)**: Unity 미가동 — **런타임 실행·플레이 검증 없음**. §1-11·§2-11 시나리오는 실제 코드 텍스트 대조 데스크 체크까지이며 실행 확인이 아니다. 신규 `.meta` 2종은 Unity 미가동으로 수기 작성(GUID 중복 없음 전수 확인) — Unity 최초 기동 시 임포트 정상 여부 확인 필요.
+- **기각안(C32)**: ①합성 결과물을 가챠 풀에 편입 — v3 §6-1 확률표 재감사를 부르고 "합성 전용 획득"이라는 설계 근간을 무너뜨림. ②`TryForge` 내부 골드 차감 — C-3이 지적한 계층 규약 위반의 재도입. ③`StunChance` 확률 캡 도입 — §1-5가 확률 캡 대신 시간 상한을 택한 근거(공격속도 무관 강건성)를 훼손. ④사다리 하드코딩 — 카탈로그 유도 방식 대비 SOT 이중화.
+- **산출물**: GodDem 로컬 커밋 `7fe15ff`(10 파일 — 수정 6·신규 4). **push 미실시**(PM 영역). BT 레포 커밋 없음.
+- **후속**: PD 확인 6건(§4) 미해소 상태 — 보스 기절 처리·지속시간 수치·확정형/확률형 상충·합성 골드 비용·UI 배치·Ring 포함 여부. 위 밸런스 관측(완주 구간 stun 확률 포화) 1건 신규 상신. Unity 기동 후 임포트·플레이 검증 필요.
+
+## 80. P3-B3-2 구현 완결 — GodDem push·PD 지시 2건 게임 진입 (PM·2026-08-23)
+
+- **PM push**: GodDem `4a8fe30..7fe15ff` master→origin. **기절 전투 로직 + 장비 합성 게임 진입 — 가챠 옵션 4종 전량 소비처 확보**(stun_rate 배선 완결로 v3 §13-3 해소)
+- 개발팀장 검증 인수: Roslyn 실컴파일 에러 0·신규 경고 0(기저선 대조)·카탈로그 26종 소스 파싱 v2 전량 일치·회귀 무결(가챠 경로·CSV 3종 무변경·Pool2 가중치·B2 9종·신규유저 22/400)·Major-1 PM 지정안 그대로·C6 백업 6종(`*.bak_20260823_0329`) 확증
+- **신규 발견 2건**: ①수집 카운터 6/17 결함 선제 해소(판정 기준을 Grade≥3→가챠 풀 등재로 교정·미소비였던 `SurvivalGachaTable.AllItemIds()` 연결·표시 무변경) ②StunChance 포화 관측(합성 완주 시 기대 1.20·시간 상한이 실질 지배라 무력화 지속률 33.3% 고정·완주 구간 stun 투자 가치 소멸 — balance-designer 상신·v2 문서 보강 지시)
+- **한계**: 런타임 미검증(Unity 미가동·데스크 체크까지·.meta 수기 2종 임포트 확인 필요)·개발팀장 C35 하위 pm-auditor 회신 전 PM 승인 커밋(사후 검토 대기)·PD 확인 6건은 설계 기본안 구현(보스 완전 면역 = 상수 1개 전환 가능)
+- 잔여: PD 플레이 검증(가챠 해금→뽑기→합성 탭→기절 발동)·PD 로그 P3-B3-2 완결 배치 갱신(pm-auditor 사전 감사 착수)
+
+## 81. P3-B3-2 사후 감사 도착 — 술어 분열 잔여 6곳·근본 해결 후속 착수 (PM·2026-08-23)
+
+- **개발팀장 C35 사전 감사(커밋 후 도착·조건부 통과·비차단)**: 백업 6종·스테이징 범위·설계 조건 해소 전항·참조 API 전수 실측 통과. **Major-A**: `IsGachaItem`(Grade≥3) 술어가 "가챠 풀 등재(6종)"·"강화 제외(17종)" 겸직 분열 — 개발팀장이 count 2곳은 해소했으나 **잔여 6곳 미처리**·핵심 = Hero.cs:485 토스트가 합성 전용 11종 미보유에 "뽑기에서 획득" **거짓 안내**(뽑기로 영원히 안 나옴). Major-B: PD 로그 stale(별도 pm-auditor 감사 진행 중인 완결 갱신이 커버). Minor: .cs 백업 원본 확장자 탈락(표준 이탈 변종)·워킹트리 잔존 2건(ONEMobilePOP_TMP.asset -4145행 churn = PM 보고 대상·Captures/ gitignore 미등재)
+- **PM 후속 집행**: ①개발팀장 근본 해결 재위임 — 술어 2분(`IsGachaPoolItem` CSV 기준 신설+`IsGachaItem` 의미 명문화)·토스트 3분기·라벨 2곳·주석 stale 2곳·전 호출부 판정표·Captures/ gitignore·백업 파일명 표준(호출부 개별 패치 금지·기각안 필수) ②balance-designer v2 §2-5 정정 노트 추가 지시(수집 판정 기준 = 풀 등재 — SOT·구현 일치) ③노하우 등재 — `feedback_predicate_semantic_split_fanout.md` 신설(감사관 요청 수용)·`feedback_backup_filename_format_violation.md` 변종 6항 보강 ④ONEMobilePOP_TMP.asset churn 불가침 유지·PD 보고
+
+## 82. 스턴·합성 v2 보강 2건 완료 — 구현완결 후 문서-구현 정합 (balance-designer, GodDem 수정 0건)
+
+- **①§1-9-A 신규 — StunChance 포화 정직 기재**: 개발팀장 구현 관측(PM 상신) 수치를 독립 재계산으로 검증 — G6 옵션 5슬롯(4종 확정+5번째 1/4 재추첨) 기준 아이템당 기대 기여 1.25×16%=20.0%, **6슬롯 합성완주 시 6×20.0%=1.20(하한 6×16.0%=0.96)** — 관측치와 정확히 일치. §1-5 시간상한(지속시간÷(지속시간+면역2배)=1/3) 구조상 StunChance가 100%를 넘어도 무력화 지속률은 일반·보스 동일하게 **33.3%로 고정**됨을 재확인 — 게임 붕괴 없음, 대신 완주 구간에서 stun_rate 옵션의 한계 가치가 소멸(retaliate/combo/hit 3종과 달리 stun만의 특성). PM 지시대로 해소책은 설계하지 않고 사실만 기재. **분류 판단 = "후속 튜닝 관찰"**(PD 확인 목록 비등재) — PD 택일이 필요한 결정이 아니라 플레이테스트 데이터 축적 후 재판단할 사안이라 판단. §5에 R-S3 신규 리스크(정보성) 등재.
+- **②§2-5 신규 문단 — 수집 판정 기준 SOT 정합**: 합성 전용 11종(전부 Grade≥3)이 낡은 "Grade≥3 카탈로그 수" 기준으로는 가챠 수집 목표를 6→17로 부풀려 "6/17" 영구 미완 표시를 유발한다는 사실과, 개발팀장이 판정 기준을 "가챠 풀 CSV 등재 여부"(`SurvivalGachaTable.AllItemIds()`, 6종만 포함)로 교정했다는 사실을 문서에 반영 — 합성 전용품 미보유 안내는 "합성으로 획득"이 되어야 함을 명시. 설계 SOT와 구현 판정 근거가 어긋나지 않도록 정합(P18·C39).
+- **§7·§8 연쇄 갱신**: 변경이력에 3차 편집 행 추가, §8 후속조치를 "구현 완료(GodDem `7fe15ff`)" 상태로 갱신 + R-S3 플레이테스트 관찰 항목 추가.
+- **산출물**: `공유/기획/GodDem/2026-08-23_P3B3-2_스턴_합성_설계_v2.md`(같은 경로, 474→490줄)
+- **후속**: PD 확인 6건(§4)은 PM 취합 후 상신. R-S3(StunChance 포화)·R-F1(합성 완주선 근사)은 플레이테스트 관찰 대상으로 잔존.
+
+## 83. P3-B3-2 후속 — IsGachaItem 술어 2분·획득처 거짓 안내 해소 (개발팀장, GodDem 로컬 커밋 bfe738a)
+
+- **계기**: pm-auditor 사후 감사(커밋 후 도착·PM 중계). 판정은 조건부 통과·로컬 커밋 비차단이었으나 실질 결함 1건 + 정리 5건이 후속 대상으로 지적됨.
+- **근본 원인(결정 근거)**: `IsGachaItem(def) => def.Grade >= 3`이 **두 개념을 겸직**하고 있었다 — (가) 강화(Layer③) 제외·굴림 옵션 보유 = Grade 축 = 17종 / (나) 뽑기로 획득 가능 = 풀 CSV 등재 축 = 6종. P3-B3-2 이전엔 우연히 일치했으나(Grade≥3 = 가챠 6종 = 풀 전체) 합성 전용 11종 추가로 갈라졌다. §79에서 내가 잡은 수집 카운터 2곳은 **숫자라 6→17로 티가 났고**, 문자열 호출부는 **술어가 여전히 true라 컴파일·실행 어디에도 안 걸리고 통과**했다(감사관 지적: "숫자 오류는 눈에 띄고 문자열 오류는 컴파일에 안 걸린다"). §79의 count 수정은 증상 2곳 대응이었고 본 건이 술어 자체를 나눈 근본 해결이다(C2).
+- **해결 — 술어 2분(SOT 확립)**: `SurvivalGachaTable.ContainsItem(itemId)` 신설(풀 등재 O(1)·`AllItemIds()`와 달리 호출당 할당 없음 → 항목별 UI 루프 안전) → `SurvivalItemCatalog.IsGachaPoolItem(def)`가 이를 감쌈. 기존 `IsGachaItem`은 "성장 계열(Grade≥3) = 강화 제외 대상" 의미로 주석 명문화 + **획득처 안내 금지 경고** 명시.
+- **전 호출부 판정표(감사 차단 절차 — 누락 방지 전수 열거)**:
+
+| # | 위치 | 원하는 개념 | 조치 |
+|---|---|---|---|
+| 1 | `SurvivalGachaTable.cs:247` | 천장 보장 등급 하한(풀 내부) | 무관 — 무변경 |
+| 2 | `SurvivalItemCatalog.cs:132` `GachaGradeFloor` | 성장 계열 등급 하한 상수 | 무변경 |
+| 3 | `SurvivalItemCatalog.cs:155` `IsGachaItem` | 강화 제외축 정의 | 주석 명문화 |
+| 4 | `SurvivalItemCatalog.cs:164` `IsGachaPoolItem` | 풀 등재축 정의 | **신설** |
+| 5 | `SurvivalMeta.cs:446` `CanUpgradeEquip` | 강화 제외 | 무변경 ✓ |
+| 6 | `SurvivalMeta.cs:747` `ForgeSourceGrades` | 사다리 최저 등급 | 무변경 ✓ |
+| 7 | `EquipUpgrade.cs:205` 라벨 | 강화 제외 ✓ | 술어 유지·**문구 정정** |
+| 8 | `EquipUpgrade.cs:273` 토스트 | 강화 제외 ✓ | 술어 유지·**문구 정정** |
+| 9 | `Hero.cs:165` 아이콘 앨리어싱 | 전용 아트 부재(17종) ✓ | 무변경 ✓ |
+| 10 | `Hero.cs:170` 앨리어싱 소스 | 상점품(자체 아이콘 보유) ✓ | 무변경 ✓ |
+| 11 | `Hero.cs:464` 옵션 표기 | 굴림 옵션 보유(17종) ✓ | 무변경 ✓ — 합성품도 `GachaRolledOptions`를 갖는다 |
+| 12 | `Hero.cs:490` 미보유 안내 | **획득처 = 풀 등재축** ✗ | **3분기 교체(실질 결함)** |
+
+- **실질 결함(영향)**: `Hero.cs` 미보유 토스트가 합성 전용 11종에 "뽑기에서 획득"이라는 **거짓 안내**를 냈다 — 뽑아도 영원히 안 나오는 아이템을 뽑으라고 안내하는 상태. 3분기(풀 등재→뽑기 / Grade≥3 & 풀 미등재→합성 / 그 외→상점)로 교체. 바로 위 기존 주석 "잘못된 안내를 하지 않는다"의 의도 위반 상태였다.
+- **라벨 정정 2곳**: "가챠 전용 — 강화 대상 아님"→"성장 장비 — 강화 대상 아님" · "가챠 아이템은 강화되지 않습니다"→"성장 장비는 강화되지 않습니다"(합성품 포함이므로 획득처 미특정 문구로 일반화). **술어는 유지** — 묻는 개념이 획득처가 아니라 강화 제외라 `IsGachaItem`이 정답.
+- **stale 주석 3곳**: `Hero.cs` "가챠 6종"→성장 계열 17종 · "카탈로그는 15종"→26종 · `SurvivalItemCatalog` 클래스 doc "총 15종"→26종 + 두 축 구분 명시.
+- **부수**: GodDem `.gitignore`에 `/[Cc]aptures/` 추가(인수인계 §5 잔여 해소) — 등록 후 미추적 파일 0 확인.
+- **기각안(C32)**: ①**count만 고치고 문자열 방치** — §79 상태 그대로 두는 안. 기각: 거짓 안내가 남고 동일 원인이 차기 호출부에서 재발한다(증상 대응 = C2 위반). ②**신규 11종을 가챠 풀에 편입해 두 개념을 재일치** — 기각: v3 §6-1 확률표 전면 재감사를 부르고(스코프 초과) "합성 전용 획득"이라는 설계 근간(§2-4)을 무너뜨린다. ③**`SurvivalItemDef`에 `IsForgeOnly` 플래그 필드 신설** — 검토 후 기각: 풀 등재 여부는 이미 CSV가 SOT인데 플래그를 두면 CSV와 코드가 갈라지는 3중 SOT가 된다(카탈로그 주석의 "매직넘버 하드코딩 금지" 원칙과 동형). 파생 판정(`ContainsItem`)이 SOT 단일성을 지킨다. ④**호출부 11곳 개별 패치** — 기각: 술어가 그대로면 다음 호출부가 또 틀린다.
+- **검증**: Roslyn 실컴파일 **에러 0·신규 경고 0**. 카탈로그 26종 × 풀 CSV 교차 대조 — 3분기가 **완전분할(exhaustive·disjoint)** 확인: 뽑기 6(id10~15)·합성 11(id16~26)·상점 9(id1~9). 전 호출부 grep 전수 재확인(위 판정표 12행).
+- **C6 백업**: `공유/개발팀_백업/GodDem/{원본명.cs}.bak_20260823_0352.cs` 4종 + `.gitignore.bak_20260823_0352`. 감사 지적(구 .cs 백업이 원본 확장자 탈락)을 반영해 **표준 `{원본명 확장자 포함}.bak_{일시}.{확장자}`** 준수. 기존 백업은 역사 보존 목적으로 개명하지 않았다.
+- **금지 준수**: `Assets/UGUI/Fonts/ONEMobilePOP_TMP.asset` 워킹트리 churn은 **무접촉**(스테이징 제외 확인 — PD Unity 산출 추정·C19-2, PM이 PD 보고 예정).
+- **산출물**: GodDem 로컬 커밋 `bfe738a`(5 파일·69 insertions/15 deletions). **push 미실시**(PM 영역). BT 레포 커밋 없음.
+- **후속**: Unity 기동 후 임포트·플레이 검증 필요. PD 확인 6건(§4)·§79 밸런스 관측(합성 완주 시 StunChance 포화) 미해소 유지.
+
+## 84. P3-B3-2 완결 배치 — pm-auditor 조건부 반영·PD 로그 갱신·.live 복원 (PM·2026-08-23)
+
+- **pm-auditor 완결 감사 조건부 판정 반영**: C-1/M-2 브리핑 staleness(§80 기준 발주·감사 중 §83·`bfe738a` 진행) → 마일스톤을 집행 직전 재실측 기준으로 확정(`7fe15ff`+`bfe738a` 병기·§74~§84) / C-2 `bfe738a` push는 감사 중 기완료 / M-1 BT 미커밋분 본 배치 전량 포함 / M-3 매니페스트 신규 등록 / m-1~m-4 대기 카운트 재구성(가챠 5건 잔여·해소 2·보류 1〔IAP 재개 트리거 = PD 과금 착수 결정〕·신규 확인 PD 판정 3 vs 플레이테스트 재판단 4 분류) / m-5~m-7(v2 재검증 전재 없음 명시·전체 파일명·기각안 명시) / m-8(백업 "확증"→표준 위반 자진 등재 정확 표기) / m-9(asset churn 6건 별건 등재·PD 보고 완료)
+- **C-3 `.live/` 복원 집행**: 3회 이월 금지 판정 수용 — `.live/README.md` 생성(plain 디렉토리·C34 junction 비사용·live_inject.sh README 스킵 실측 확인 후 안전 복원). P25 채널 재가동
+- **노하우 신설**: `feedback_auditor_briefing_staleness.md`(감사 브리핑 staleness — 발주 직전 재실측 스탬프 의무·감사관 실측 우선) — 감사관 등재 요청 수용
+- C13 정정: PD 지시 5건 중 ④⑤ 설명 2건 = 발신 완료 표기(수령→완료 전환)