diff --git a/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md b/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md index c650bec..c2166aa 100644 --- a/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md +++ b/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md @@ -33,7 +33,7 @@ C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**. | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 | |---|------|----------|----------|-----------|----------|----------| -| BT13-GodDem | 2026-08-19~20 | **GodDem 프로젝트 개시 + 인게임 「황야의 생존자」형 전환** — PD 직접 지시 6건 연속. ①(2026-08-19) "이 세션은 우리 조직의 새로운 프로젝트인 GodDem 프로젝트 개발을 위한 세션이야. 현재 프로젝트 레포는 'E:\NerdNavis\GodDem' 이므로 코드 및 프로젝트를 제대로 검토해보고 개발할 준비가 되면 보고해." ②"앞으로는 도구 사용을 묻지 않도록 자동으로 도구 승인처리해" (+ ToolSearch·MCP 리소스 도구·`.claude/**` 편집 영구 허용 반복 지시) ③"인게임을 유튜브(https://youtu.be/cBVc0OwUX6U 황야의 생존자) 영상과 같은 형태로 변경. 더미 리소스(기존 자산)로 기본 시스템 동일 설계·인게임 씬 배치. **아웃게임 유지, 인게임 씬만 변경**" + 전투 명세 4항(플레이어 중앙 고정 자동공격 / 매판 리셋 로그라이크 스텟 강화 / 10웨이브 보스·스테이지 클리어 / **신규: 경험치→레벨업마다 특수 스킬 3종 택1**) ④"원작 APK 디컴파일해서 게임 로직·데이터 분석. 능력치·성장 수치·강화 비용 등 밸런스 데이터를 그대로 활용하고 싶다" ⑤"FABLE5로 원작 복호화 리버싱을 먼저 시도해봐. 안되면 자체 수치로 설계할게" ⑥"csv 형태로 제작해줘" / "워크플로우 설계할 때 ponytail 스킬을 써줘". **C13 위반 자진 보고** — 본 6건이 대화로그에만 기록되고 본 트래킹 로그에 미등록 상태였음(pm-auditor 감사 Critical 적발). 소급 등록. **[2026-08-21 인게임·메타·밸런스 일괄 집행]** PD "전부 진행해" 승인 — 1차 인게임 완결(A10 분신 10종 정합·일시정지·적 HP바, `77bd835`·`ee9ec11`) + 3차 상점·Hero 메타 결선(SurvivalMeta 분리 신설, `57a8fcf`) + 4차 결함 해소(penetrate_ratio 함정·A13 사거리·waveInStage 산식·이중 SOT, `7728a41`) + 5차 S3 v2 밸런스 확정 반영(42/1/14/+3, plan-auditor 재검증 통과, `d5dea4d`). 상세: 공유/대화로그/GodDem/2026-08-21.md §3~§12. **[2026-08-22 밸런스 원작이탈 지적·2층 재구현]** PD 플레이 실측 지적 — 공격력이 원작 2층(정액 hero_level power + 배율 attack_add) 중 배율만·축소, 정액 트랙 누락 / 몬스터 원작 소스 부재. 근본 = 본 로그 사후조치 (2) "스케일 재조정 방침"을 PD 재확인 없이 진행한 C36 위반이 플레이로 표면화. PD "이 방향으로 재구현해" 승인 → 공격력 원작 2층 복원 착수 (C49: balance-designer 재설계 → plan-auditor 검증 → 개발팀장 구현). memory `feedback_pd_directive_altered_to_rescale` 신설. **[완료 2026-08-22 GodDem `26ff655`]** 공격력 원작 2층 복원 완결 — APK 재추출로 배율(0.05~0.30)=원작 attack_add prefix-10 원본 확정(이탈 아님)·정액 트랙 `attack`(30~600) 신설로 2층 복원·C49 이중검증(balance v2→plan-auditor 통과)·플레이테스트 2층 산술 정확 재현(22~1691). PD 지적 (a)(b) "정액 누락" 단일원인 해소. 부수 강화테이블 전수 원작 정합 확인. **잔여 = R-M2(정액 몰빵 스테이지1 보스 3.5배 오버킬) 조정 방향 PD/balance 판단 1건**. 상세 대화로그 §15~§20. **[2026-08-22 원작 아키텍처 전면 이식 착수·대규모]** PD 지적 2건("총 스테이지 구성 원작 동일"·"능력치가 원작보다 훨씬 적음·원작은 아웃게임 확장") → PD 결정 "원작 데이터 아키텍처 전면 이식이 맞아"+"이대로 진행". 실측 gap 3축(능력치 24 vs 13·아웃게임 5층 vs 1층·스테이지 6구간 vs 무한). 근본=초기 MVP 전환 원작 축소(feedback_pd_directive_altered_to_rescale 연장). P32 분할: 1단계 balance-designer 이식청사진 → 2단계 system-designer 메타재설계 → 3단계 축별 구현. 상세 대화로그 §21. **[P1 완료·P2 착수 2026-08-22]** 청사진 v1 완료(`b5d95cc`, 능력치 24종/PvE 18·아웃게임 5층·스테이지=원작 teamwavepassreward 54단계뿐/StageBalance는 GodDem 자산 정정·재사용3/확장3). PD 결정: 가챠 원작대로 도입(과금 신설)·현 세션 P2 계속. P2 system-designer 메타 아키텍처 재설계 착수(5층·능력치18 배치·인게임/아웃게임 경계 재정의). 상세 §22~§23. **[P2 완료 2026-08-22]** 메타 아키텍처 재설계 v1 완료 — 5층 확정(①영웅레벨·②승급·③장비강화·④가챠·⑤스킬마스터리, 인게임 "런레벨"과 명칭 분리) + 능력치 18종 배치(청사진 §2-3 "미보유 5종" 정정: `stun_rate` 누락 확인·실제 6종) + ★결합 지점 정정(초안 "1곳"→plan-auditor 감사로 4개 호출부 확인, `SurvivalLobbyController.Hero.cs` 2곳 누락분 포함, `FinalAttack()`/`FinalHp()` 단일 캡슐화 메서드로 3중 SOT 재발 방지 설계) + 재사용/확장 판정(SurvivalMeta 확장·Upgrade/Skill 불변·ItemCatalog 확장·**ShopCatalog는 "구조 확장 필요"로 정정**, 확률 지급물 미지원 확인) + 신규 클래스 4·CSV 7종 골격 + P3 4서브페이즈 분할(B1레벨승급→B2장비→B4스킬→B3가챠). plan-auditor 모드A 감사 1회 수행(조건부통과, Critical 2·Major 6·Minor 4 — 전부 반영 후 확정). **PD 확인 대기 2건**: ①가챠 소비재화(골드 vs 젬, 원작 근거 부재 🔴) ②가챠 가격·확률 실값. **[P3-A 착수 2026-08-22]** PD 방향 확정 "설계대로 진행"(인게임 매판 리셋 + 아웃게임 영구성장이 매판 시작 베이스 = 영구성장 RPG, P2 경계재정의 그대로). P3-A 능력치 정리 착수(penetrate_ratio 이관·ele 2종 층확정·18종 체계). 후속 B1→B2→B4→B3(가챠)+C(스테이지 병렬). 상세 §25. **[P3-A 완료·B1 착수 2026-08-22]** P3-A GodDem `8684211`(penetrate ⑤이관·ele ⑤확정·StatCatalog SOT·plan-auditor 조건부통과). **★부수 성과**: 직전 공격력 2층의 attack 정액 트랙이 상점 미노출(소비O·상점X)로 플레이어 미도달이던 결함 발견·수정 — Play 실측 22→52 도달 회복(memory `feedback_shop_exposure_filter_source_both` 신설). P3-B1(레벨+승급) balance-designer 설계 착수 + 메타문서 ele④→⑤ 갱신. 상세 §26~§28. **[B1 설계완료·구현착수 2026-08-22]** balance-designer B1 설계(레벨1~60·승급0~11·매판 베이스 결합·plan-auditor 조건부통과). **★근본 발견**: 인게임 골드→아웃게임 전환 브릿지 부재(CurrencyManager.Add 0건)=영구성장 전제 미구현. **PD 결정**: "원작처럼 맞춰 전체 밸런싱 동일성 확인 후 추후 변경" → 유한캡(60/11) 원작 정합 확정·원작 충실 1차. 개발팀장 B1 구현 착수(전환 브릿지 최우선). 상세 §29~§31. **[B1 완료 2026-08-22 GodDem `a3f62ab`]** 영구 성장 첫 층 게임 진입 — 인게임 골드→아웃게임 영구재화 전환 브릿지 신설(크로스세션 영속 확증)·영웅레벨 1~60·승급 star0~11·매판 시작 베이스 결합(신규 22/400 불변)·defense 분리클램프. plan-auditor 통과(Minor1 NRE 3중 방어 동봉)·메타문서 유한캡 정정. 남은 B2(장비)→B4(스킬)→B3(가챠)+C(스테이지). 상세 §32~§34. **[B2 착수 2026-08-22]** PD "현 세션 B2 계속" + 지적 "세션 이동 되묻지 마"(feedback_session_transition_repeated_prompting 신설·세션 이동 재제안 중단). balance-designer 장비강화 Layer③ 설계 착수(heroequipment 정합·M수열 재추출). 상세 §35. | **진행중** || **진행중** | ①레포 검토 완료·`공유/대화로그/GodDem/2026-08-19.md` ②`.claude/settings.json` dontAsk+allow 확장 (커밋 `7366860`·`c4a5dfd`) ③설계도 `공유/기획/GodDem/2026-08-19_인게임_중앙디펜스_전환_설계_v1.md` (커밋 `4346d4d`) ④⑤**복호화 성공** — 22바이트 반복 XOR·`libil2cpp.so` 리버싱 불필요. 원작 밸런스 237테이블 복호화 ⑥**CSV 230종/22,261행** 변환·PD 전달. 종합 매핑 SOT `공유/기획/GodDem/2026-08-20_원작밸런스_해독_매핑_v1.md`. **P1 청사진** `공유/기획/GodDem/2026-08-22_원작아키텍처_이식청사진_v1.md`(`b5d95cc`, 산출물 경로 누락분 소급 추가·pm-auditor 지적). **P2 메타 재설계** `공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md`(system-designer, plan-auditor 검증 완료). | — | **PD 결정 대기 2건**: (1) 복호화 XOR 키의 조직 기록 보존 가부 (타사 기술적 보호조치 우회 수단 — PM 재량 밖, C36-2 보수 선택으로 문서에서 마스킹) (2) 원작 절대수치 vs 자체 스케일 재조정 방침 확인. **다음 단계**: 설계 P1(중앙 고정 플레이어+사방 스폰+웨이브 씬 골격 배치) 착수. **후속 조치**: `.gitignore`에 `scratchpad/`·`wild/` 선제 등재, `공유/대화로그/INDEX.md`에 GodDem 등재. **저작권 방침**: 원작 수치는 참고, 아트·텍스트 리소스 사용 불가. 추출물 레포 미커밋(git 실측 확인). | +| BT13-GodDem | 2026-08-19~20 | **GodDem 프로젝트 개시 + 인게임 「황야의 생존자」형 전환** — PD 직접 지시 6건 연속. ①(2026-08-19) "이 세션은 우리 조직의 새로운 프로젝트인 GodDem 프로젝트 개발을 위한 세션이야. 현재 프로젝트 레포는 'E:\NerdNavis\GodDem' 이므로 코드 및 프로젝트를 제대로 검토해보고 개발할 준비가 되면 보고해." ②"앞으로는 도구 사용을 묻지 않도록 자동으로 도구 승인처리해" (+ ToolSearch·MCP 리소스 도구·`.claude/**` 편집 영구 허용 반복 지시) ③"인게임을 유튜브(https://youtu.be/cBVc0OwUX6U 황야의 생존자) 영상과 같은 형태로 변경. 더미 리소스(기존 자산)로 기본 시스템 동일 설계·인게임 씬 배치. **아웃게임 유지, 인게임 씬만 변경**" + 전투 명세 4항(플레이어 중앙 고정 자동공격 / 매판 리셋 로그라이크 스텟 강화 / 10웨이브 보스·스테이지 클리어 / **신규: 경험치→레벨업마다 특수 스킬 3종 택1**) ④"원작 APK 디컴파일해서 게임 로직·데이터 분석. 능력치·성장 수치·강화 비용 등 밸런스 데이터를 그대로 활용하고 싶다" ⑤"FABLE5로 원작 복호화 리버싱을 먼저 시도해봐. 안되면 자체 수치로 설계할게" ⑥"csv 형태로 제작해줘" / "워크플로우 설계할 때 ponytail 스킬을 써줘". **C13 위반 자진 보고** — 본 6건이 대화로그에만 기록되고 본 트래킹 로그에 미등록 상태였음(pm-auditor 감사 Critical 적발). 소급 등록. **[2026-08-21 인게임·메타·밸런스 일괄 집행]** PD "전부 진행해" 승인 — 1차 인게임 완결(A10 분신 10종 정합·일시정지·적 HP바, `77bd835`·`ee9ec11`) + 3차 상점·Hero 메타 결선(SurvivalMeta 분리 신설, `57a8fcf`) + 4차 결함 해소(penetrate_ratio 함정·A13 사거리·waveInStage 산식·이중 SOT, `7728a41`) + 5차 S3 v2 밸런스 확정 반영(42/1/14/+3, plan-auditor 재검증 통과, `d5dea4d`). 상세: 공유/대화로그/GodDem/2026-08-21.md §3~§12. **[2026-08-22 밸런스 원작이탈 지적·2층 재구현]** PD 플레이 실측 지적 — 공격력이 원작 2층(정액 hero_level power + 배율 attack_add) 중 배율만·축소, 정액 트랙 누락 / 몬스터 원작 소스 부재. 근본 = 본 로그 사후조치 (2) "스케일 재조정 방침"을 PD 재확인 없이 진행한 C36 위반이 플레이로 표면화. PD "이 방향으로 재구현해" 승인 → 공격력 원작 2층 복원 착수 (C49: balance-designer 재설계 → plan-auditor 검증 → 개발팀장 구현). memory `feedback_pd_directive_altered_to_rescale` 신설. **[완료 2026-08-22 GodDem `26ff655`]** 공격력 원작 2층 복원 완결 — APK 재추출로 배율(0.05~0.30)=원작 attack_add prefix-10 원본 확정(이탈 아님)·정액 트랙 `attack`(30~600) 신설로 2층 복원·C49 이중검증(balance v2→plan-auditor 통과)·플레이테스트 2층 산술 정확 재현(22~1691). PD 지적 (a)(b) "정액 누락" 단일원인 해소. 부수 강화테이블 전수 원작 정합 확인. **잔여 = R-M2(정액 몰빵 스테이지1 보스 3.5배 오버킬) 조정 방향 PD/balance 판단 1건**. 상세 대화로그 §15~§20. **[2026-08-22 원작 아키텍처 전면 이식 착수·대규모]** PD 지적 2건("총 스테이지 구성 원작 동일"·"능력치가 원작보다 훨씬 적음·원작은 아웃게임 확장") → PD 결정 "원작 데이터 아키텍처 전면 이식이 맞아"+"이대로 진행". 실측 gap 3축(능력치 24 vs 13·아웃게임 5층 vs 1층·스테이지 6구간 vs 무한). 근본=초기 MVP 전환 원작 축소(feedback_pd_directive_altered_to_rescale 연장). P32 분할: 1단계 balance-designer 이식청사진 → 2단계 system-designer 메타재설계 → 3단계 축별 구현. 상세 대화로그 §21. **[P1 완료·P2 착수 2026-08-22]** 청사진 v1 완료(`b5d95cc`, 능력치 24종/PvE 18·아웃게임 5층·스테이지=원작 teamwavepassreward 54단계뿐/StageBalance는 GodDem 자산 정정·재사용3/확장3). PD 결정: 가챠 원작대로 도입(과금 신설)·현 세션 P2 계속. P2 system-designer 메타 아키텍처 재설계 착수(5층·능력치18 배치·인게임/아웃게임 경계 재정의). 상세 §22~§23. **[P2 완료 2026-08-22]** 메타 아키텍처 재설계 v1 완료 — 5층 확정(①영웅레벨·②승급·③장비강화·④가챠·⑤스킬마스터리, 인게임 "런레벨"과 명칭 분리) + 능력치 18종 배치(청사진 §2-3 "미보유 5종" 정정: `stun_rate` 누락 확인·실제 6종) + ★결합 지점 정정(초안 "1곳"→plan-auditor 감사로 4개 호출부 확인, `SurvivalLobbyController.Hero.cs` 2곳 누락분 포함, `FinalAttack()`/`FinalHp()` 단일 캡슐화 메서드로 3중 SOT 재발 방지 설계) + 재사용/확장 판정(SurvivalMeta 확장·Upgrade/Skill 불변·ItemCatalog 확장·**ShopCatalog는 "구조 확장 필요"로 정정**, 확률 지급물 미지원 확인) + 신규 클래스 4·CSV 7종 골격 + P3 4서브페이즈 분할(B1레벨승급→B2장비→B4스킬→B3가챠). plan-auditor 모드A 감사 1회 수행(조건부통과, Critical 2·Major 6·Minor 4 — 전부 반영 후 확정). **PD 확인 대기 2건**: ①가챠 소비재화(골드 vs 젬, 원작 근거 부재 🔴) ②가챠 가격·확률 실값. **[P3-A 착수 2026-08-22]** PD 방향 확정 "설계대로 진행"(인게임 매판 리셋 + 아웃게임 영구성장이 매판 시작 베이스 = 영구성장 RPG, P2 경계재정의 그대로). P3-A 능력치 정리 착수(penetrate_ratio 이관·ele 2종 층확정·18종 체계). 후속 B1→B2→B4→B3(가챠)+C(스테이지 병렬). 상세 §25. **[P3-A 완료·B1 착수 2026-08-22]** P3-A GodDem `8684211`(penetrate ⑤이관·ele ⑤확정·StatCatalog SOT·plan-auditor 조건부통과). **★부수 성과**: 직전 공격력 2층의 attack 정액 트랙이 상점 미노출(소비O·상점X)로 플레이어 미도달이던 결함 발견·수정 — Play 실측 22→52 도달 회복(memory `feedback_shop_exposure_filter_source_both` 신설). P3-B1(레벨+승급) balance-designer 설계 착수 + 메타문서 ele④→⑤ 갱신. 상세 §26~§28. **[B1 설계완료·구현착수 2026-08-22]** balance-designer B1 설계(레벨1~60·승급0~11·매판 베이스 결합·plan-auditor 조건부통과). **★근본 발견**: 인게임 골드→아웃게임 전환 브릿지 부재(CurrencyManager.Add 0건)=영구성장 전제 미구현. **PD 결정**: "원작처럼 맞춰 전체 밸런싱 동일성 확인 후 추후 변경" → 유한캡(60/11) 원작 정합 확정·원작 충실 1차. 개발팀장 B1 구현 착수(전환 브릿지 최우선). 상세 §29~§31. **[B1 완료 2026-08-22 GodDem `a3f62ab`]** 영구 성장 첫 층 게임 진입 — 인게임 골드→아웃게임 영구재화 전환 브릿지 신설(크로스세션 영속 확증)·영웅레벨 1~60·승급 star0~11·매판 시작 베이스 결합(신규 22/400 불변)·defense 분리클램프. plan-auditor 통과(Minor1 NRE 3중 방어 동봉)·메타문서 유한캡 정정. 남은 B2(장비)→B4(스킬)→B3(가챠)+C(스테이지). 상세 §32~§34. **[B2 착수 2026-08-22]** PD "현 세션 B2 계속" + 지적 "세션 이동 되묻지 마"(feedback_session_transition_repeated_prompting 신설·세션 이동 재제안 중단). balance-designer 장비강화 Layer③ 설계 착수(heroequipment 정합·M수열 재추출). 상세 §35. **[B2 v1 완료·재추출 착수 2026-08-22]** B2 설계 v1(2축 레벨/등급·plan-auditor 조건부통과·Critical2 융합버그 재설계). **원작 M수열 재추출 미해소·역산** → PD "원작처럼 맞춰" 정합 위해 개발팀장 heroequipment 재추출 착수(공격력 재추출 선례·되묻지 않고 진행). 후속 B2 v2 재산정→검증→구현. 상세 §36~§37. | **진행중** || **진행중** | ①레포 검토 완료·`공유/대화로그/GodDem/2026-08-19.md` ②`.claude/settings.json` dontAsk+allow 확장 (커밋 `7366860`·`c4a5dfd`) ③설계도 `공유/기획/GodDem/2026-08-19_인게임_중앙디펜스_전환_설계_v1.md` (커밋 `4346d4d`) ④⑤**복호화 성공** — 22바이트 반복 XOR·`libil2cpp.so` 리버싱 불필요. 원작 밸런스 237테이블 복호화 ⑥**CSV 230종/22,261행** 변환·PD 전달. 종합 매핑 SOT `공유/기획/GodDem/2026-08-20_원작밸런스_해독_매핑_v1.md`. **P1 청사진** `공유/기획/GodDem/2026-08-22_원작아키텍처_이식청사진_v1.md`(`b5d95cc`, 산출물 경로 누락분 소급 추가·pm-auditor 지적). **P2 메타 재설계** `공유/기획/GodDem/2026-08-22_메타아키텍처_재설계_v1.md`(system-designer, plan-auditor 검증 완료). | — | **PD 결정 대기 2건**: (1) 복호화 XOR 키의 조직 기록 보존 가부 (타사 기술적 보호조치 우회 수단 — PM 재량 밖, C36-2 보수 선택으로 문서에서 마스킹) (2) 원작 절대수치 vs 자체 스케일 재조정 방침 확인. **다음 단계**: 설계 P1(중앙 고정 플레이어+사방 스폰+웨이브 씬 골격 배치) 착수. **후속 조치**: `.gitignore`에 `scratchpad/`·`wild/` 선제 등재, `공유/대화로그/INDEX.md`에 GodDem 등재. **저작권 방침**: 원작 수치는 참고, 아트·텍스트 리소스 사용 불가. 추출물 레포 미커밋(git 실측 확인). | | BT12-Dev-Vis | 2026-05-09 | **PlayerSkillInventory 등록 시각화 지시** — PD 직접 발화: "PlayerSkillInventory 등록이 되었는지 어떻게 판단해야하지? 시각적인 변화가 없으니 확인이 불가능해. 유니티 기본 제공 리소스를 활용해도 좋으니 보이게 해줘." **[2026-05-13 후속 세션 신규 3건]** (1) 투사체 사거리 파란 박스 시각화 — `HitboxDebug.SpawnRange` 신규 (`Projectile.Initialize` 끝 호출·3초 유지·`HideFlags.DontSave`). (2) 사정거리·속도 Inspector 직접 조절 — `ActiveSkillData.MaxRange`·`ProjectileSpeed` 신규 필드 (`RangeTier`·`camWidth`·`mults` 계산 폐기·`PiercingProjectile._speed = 2.5f` override 폐기). (3) A04 ExtraHitFxPrefab + FX_Thunder Smoke — `ActiveSkillData.ExtraHitFxPrefab` 신규·`LightningStrikeSpawner.DelayedExtraHitFx` Coroutine (0.6초 후 spawn·y -0.5·비주얼 전용·판정 무관). EerieVillage `ab40b27` push 정합. **[2026-05-13 사고 정정]** 본 PM `git reset --hard origin/main` 영역 PD Inspector 작업 .asset 6 폐기 사고 발생. PD 보고 "스킬 관련 스크립터블 오브젝트가 full 이후 롤백되어버렸어" 수령. `git reflog` 영역 `e2bc95f` 보존 정합·.asset 6 복구·EerieVillage `5b2a032` push 정합. A04 ExtraHitFxPrefab (FX_Thunder Smoke) 영역 PD 후속 Inspector drag&drop 필요. 본 PM 자성 #4 (헌법급) 등재. **[2026-05-13 신규 2건]** (1) 디버그 박스·사거리 박스 시각화 off (재활용 toggle) — `HitboxDebug.ShowDebugVisuals` 플래그 신규·4 위치 `SpriteRenderer.enabled` 정합. (2) 레벨업 카드 풀 5종 한정 — `SkillRuntimeFactory.AvailableCardIds` 화이트리스트 (A02·A13·A04·A05·A_Laser)·미완성 placeholder 5종 (A01·A03·A08·A14·A15) 제외. EerieVillage `d26bd83` push 정합. **잔여**: A04·A05·A_Laser 영역 SkillFireEvent default return 영역 실전 발사 미연결 (카드 풀 한정 영역과 별개·PD 후속 결정 대기). **[2026-05-13 정정·진단]** (1) A05·A_Laser 박스 시각 off 누락 정정 — MeleeAreaSpawner·LaserSpawner 영역 직접 SpriteRenderer 부착 코드 (HitboxDebug 미경유) 영역 `sr.enabled = HitboxDebug.ShowDebugVisuals` 추가. 본 PM 자성 #5 (변경 영향 사전 grep 누락). (2) Player 피격 X 진단 Debug.Log 추가 (회수 의무) — EnemyController.Update L387-396 영역 `[EnemyHit][Intersect]`·`[EnemyHit][Decrement]` 2종. PD Console 측정 결과 영역 근본 fix·Debug.Log revert. EerieVillage `e8779df` push 정합. **[2026-05-13 신규]** 게임 시작 시 기본 파이어볼 A02 자동 습득 — `PlayerSkillInventory.StartingCardIds` (string[]) Inspector 필드·기본 `{ "A02" }`·`Start()` 영역 일괄 `AddSkillByCardId`. EerieVillage `0ad1325` push 정합. **[2026-05-13 신규 2건]** (1) Player 피격 X fix — EnemyController.Update L387-396 영역 `IsGrounded` 조건 폐기 (PD 표현 "닿아도" = ground·공중 무관 피격 의도)·진단 Debug.Log 2종 revert. (2) Enemy HP 30~40 random — `Health.RandomMaxHPRange` (Vector2Int) Inspector 필드 신규·Awake 영역 random·`maxHearts` 자동 산정·Enemy.prefab Inspector `(30, 40)` PD 직접 설정. 본 PM 자성 #6 (PD Console 측정 결과 미수신 영역 가설 fix 시도·feedback_pm_root_diagnosis_priority 약한 위반). EerieVillage `b4847b1` push 정합. **[2026-05-13 재발 정정]** (1) Enemy HP 30~40 자동 fallback — Health.Awake 영역 RandomMaxHPRange 미설정 + EnemyController 검출 → 자동 random. PD Inspector 의존 폐기. (2) Player 피격 distance 기반 강화 + 진단 Debug.Log 재추가 — `VisualBounds.Intersects OR dist < 1.5f` 단일 조건·`[EnemyHit]` 진단·회수 의무. 본 PM 자성 #7 (feedback_pm_root_diagnosis_priority 위반 누적). EerieVillage `2efcd34` push 정합. **[2026-05-13 신규]** Enemy·Player 사망 모션 y -0.5 오프셋 — EnemyDeath·PlayerDeath Execute 영역 Animator death/hurt Trigger 직전 `transform.position.y -= 0.5` 적용·sprite 위로 떠 보이는 현상 정정·collider 영향 X. EerieVillage `18b2125` push 정합. **[2026-05-13 신규]** 스킬 선택 UI 아이콘 fallback — SkillCardSlot.Bind 영역 card.Icon null 시 동적 원 sprite (32×32 알파) + 속성별 색상 (Fire 주황·Frost 하늘·Dark 보라·Lightning 노랑·Physical 흰). _glowEffect 동심원 빛 효과 alpha 0.3. EerieVillage `32ab76f` push 정합. **[2026-05-13 신규 2건]** (1) 사망 모션 y -0.5 → -0.3 (EnemyDeath·PlayerDeath). (2) 게임 시작 시 파이어볼 투사체 정지·잔존 fix — ProjectileSpawner.Trigger 영역 `facing.sqrMagnitude<0.01f` 시 `Vector2.right` fallback. 원인: Player.Facing 영역 (0,0) 영역 → _direction = (0,0) → _speed × 0 = 정지. EerieVillage `56a4a36` push 정합. **[2026-05-13 신규]** 투사체끼리 통과 fix — Projectile.OnTriggerEnter2D 영역 동족 Projectile skip (Wall·Enemy 판정 이전). 원인: fallback GO default Layer 0 영역 → isWall=true → 양쪽 SelfDestruct. EerieVillage `ebd7086` push 정합. **[2026-05-13 신규 4건]** (1) Player 사망 사라지는 현상 fix — PlayerDeath 영역 `Rigidbody2D.simulated=false` (gravity 정지·낙사 차단). (2·3) 제자리 부활·부활 모션·2초 무적 깜박 — PlayerSpawn 영역 `Teleport` 폐기·`health.Resurrect()` 호출 (currentHP=maxHP·invulnerableUntil=2초·Animator resurrect Trigger)·Rigidbody simulated=true 복원·PlayerInvulnerabilityFlash 자동 깜박. (4) FX 잔상 safety cap 5초 — LaserSpawner fx Destroy 누락 추가·LightningStrike·MeleeArea·Projectile.AutoDestroy 영역 `Mathf.Min(lifetime, 5f)` cap. EerieVillage `3a672f0` push 정합. **[2026-05-13 컴파일 에러 fix]** PlayerSpawn.cs CS0246 — using UnityEngine 누락·첫 줄 추가. 본 PM 자성 #8 (신규 type 사용 시 namespace using 사전 검증 누락). EerieVillage `c052d78` push 정합. **[2026-05-13 신규 3건]** (1) Player 죽는 모션 X fix — Player.controller parameter "hurt" 부재 측정·`SetTrigger("hit")`·`updateMode=UnscaledTime`. (2) 부활 모션 중 움직임 fix — PlayerSpawn simulated 복원 폐기·EnablePlayerInput 영역 이전. (3) 투사체 잔상 진단 — `[Projectile][SelfDestruct]`·`[Projectile][OnDestroy]` Debug.Log·회수 의무. 본 PM 자성 #9 (Animator parameter 사전 측정 누락). EerieVillage `69a1805` push 정합. **[2026-05-13 NullReferenceException + 잔존 근본 fix]** ProjectileSpawner.Trigger 영역 collider isTrigger=true 활성 시점 vs Initialize 호출 시점 race → OnTriggerEnter2D 영역 `_runtime=null` NullReferenceException → SelfDestruct 미호출 → 영구 잔존. fix: OnTriggerEnter2D 영역 `_runtime/_data == null` defensive return + Update 영역 `_data == null` 시 즉시 SelfDestruct. 본 PM 자성 #10 (race condition 사전 측정 누락). EerieVillage `1437720` push 정합. **[2026-05-13 신규 3건]** (1) 사망 팝업 타이밍 fix — LevelUpManager.HandleLevelUp 영역 Player 사망 상태 시 _pendingLevels 영역 저장·Update 영역 IsAlive 회복 시 표시. (2) Player 사망 y -0.3 추가 (누적 -0.6). (3) 투사체 잔상 강화 + 진단 — Projectile.Update 영역 lifetime+0.5 backup·Initialize·Trigger 영역 진단 Log·회수 의무. EerieVillage `b1931af` push 정합. **[2026-05-13 근본 원인 fix]** 재시작 시 정지 투사체 누적 — Time.timeScale=0 (LevelUp 등) 영역 Time.time·Invoke 정지 영역 영구 잔존. fix: Projectile `_spawnTime = Time.unscaledTime`·Update 영역 unscaledTime lifetime check·Invoke 폐기·CancelInvoke 추가 안전. 본 PM 자성 #11 (timeScale 영향 사전 측정 누락). EerieVillage `705d943` push 정합. **[2026-05-13 진단 Log 회수]** PD "사라졌어" 정합 작동 확인 후 진단 Debug.Log 5종 revert (ProjectileSpawner·Projectile.Initialize·SelfDestruct·OnDestroy·EnemyHit). Projectile.Update lifetime backup·CancelInvoke 안전망 보존. feedback_pm_root_diagnosis_priority 정합. EerieVillage `41fa4e4` push 정합. **[2026-05-13 신규 2건]** (1) MeleeArea 실전 발사 연결 — SkillFireEvent.Execute switch 영역 MeleeArea case·CardId 분기 (A04·A_Laser·기타). (2) FX AutoDestroy unscaledTime — FxAutoDestroyUnscaled MonoBehaviour 신규 (Object.Destroy 영역 timeScale 영향 fix)·전수 변경·WaitForSecondsRealtime. 본 PM 자성 #12 (Unity 표준 API timeScale 영향 사전 측정 누락). EerieVillage `26b0666` push 정합. **[2026-05-13 신규]** A04 번개 충격 적 유무 무관 자동 발동 — LightningStrikeSpawner.Trigger 영역 candidates 0 시 Player 위치 fallback spawn. A05·A_Laser = 이미 Player 위치 기준 발동·정합. EerieVillage `ebedf6d` push 정합. **[2026-05-13 InvalidOperationException Input System fix]** ParticleGroupView (2).cs 영역 삭제 (Scenes 폴더 영역 비정상 .cs·미사용·StandaloneInputModule 동적 부착 코드)·ProjectSettings activeInputHandler 1→2 (Both 모드·호환). 본 PM 자성 #13. EerieVillage `b30976a` push 정합. **[2026-05-13 본 PM 자성 #14 + fix 정정]** PD 직접 자성 지적 — 본 PM 직전 미승인 `.cs` 삭제 영역 정정. PD 재배치 후 ParticleGroupView (2).cs UnityEngine.Input → InputSystem 전환·activeInputHandler 2→1 revert. EerieVillage `b23e00f` push 정합. **[2026-05-13 Phase A]** A12 정화의 빛 신규·A08 저주의 화살 이펙트 적용 — ActiveSkillData.CastFxPrefab 신규·ProjectileSpawner.Trigger 영역 CastFx spawn·SkillRuntimeFactory.AvailableCardIds 7종 확장. **Phase B 대기** (A06 독 늪·A11 정령불 신규 Effector). EerieVillage `5077f5d` push 정합. **[2026-05-13 Phase B]** A06 독 늪·A11 정령불 신규 Effector + 1키·2키 매핑 — PoisonSwampSpawner/Instance/PoisonedEnemyMarker·SpiritFireSpawner/Instance 신규·SkillFireEvent switch PlacementPersistent·Minion case 확장·TestSkillFireOn1to5 Category 분기 추가·A06·A11 .asset 신규·SkillRuntimeFactory 9종. PD Inspector Player.prefab Skill1·Skill2 drag&drop 필요. EerieVillage `f292eb4` push 정합. **[2026-05-13 Phase B FX 재생 fix]** ParticleSystem 명시 `Play(true)` 호출 추가·PoisonSwampInstance 영역 BoxCollider2D·Rigidbody2D 자식 GO 분리 (ParticleSystem root 영향 차단). EerieVillage `b1b476a` push 정합. **[2026-05-13 A11 frame 제어]** FX_Rotating shield Animator frame 제어 — intro 1~88·loop 89~105 반복·outro 106~169 (남은 frame). Animator.Play(STATE_HASH, 0, normalizedTime) 매 frame 호출. EerieVillage `ebd0808` push 정합. **[2026-05-13 A12·A08·전수 FX Play]** 4 Spawner + Projectile 영역 ParticleSystem.Play(true) 명시 호출 전수 적용 (직전 b1b476a 영역 PoisonSwamp·SpiritFire만 적용 영역 영역 영역 보완). EerieVillage `68843a8` push 정합. **[2026-05-13 A08 sprite 방향 fix]** ActiveSkillData.ProjectileAngleOffset (float Range -360~360) 신규·Projectile.Initialize 영역 angle 보정·A08.asset 180 (FX_PinkMagicArrow sprite left→right). EerieVillage `71c3b7d` push 정합. **[2026-05-13 A08 FX 진단]** A08.asset GUID 정합·코드 정합 측정. PD 보고 영역 실측 진단 Debug.Log 추가 (회수 의무). EerieVillage `aa6cef1` push 정합. **[2026-05-13 CS1056 fix]** ProjectileSpawner.cs interpolated string `\"NULL\"` escape 영역 컴파일 에러·ternary 결과 변수 분리 fix. 본 PM 자성 #15 (Edit 후 컴파일 사전 검증 누락). EerieVillage `9879425` push 정합. **[2026-05-13 fileID 잘못된 측정 정정·자성 #16]** PD Inspector 측정 결과 영역 본 PM .asset 영역 fileID 영역 자식 GameObject 영역 매핑 영역. `grep -m 1` 영역 첫 GameObject 영역 = root 영역 영역 X. A08·A06·A12 .asset 영역 fileID 일괄 정정 (FX_PinkMagicArrow_Hit·FX_PinkArrow_Shoot·FX_Venom_Spray·FX_Icelight_Seal). 올바른 측정 = `awk m_Name + m_Father=0 정합`. EerieVillage `b26eb42`·`447ea92` push 정합. **[2026-05-13 CastFx 방향 + 진단 회수]** CastFx Instantiate 영역 facing+ProjectileAngleOffset+FxRotation 적용 (sprite 반대 방향 정정)·진단 Debug.Log 3종 revert. EerieVillage `7ad3319` push 정합. **[2026-05-13 A08 spawn 끝점·grace]** A08.asset OffsetDistance.x=1.5 (캐스팅 끝 spawn)·Projectile.OnTriggerEnter2D 영역 0.1초 grace 추가 (Hit FX Player 위치 회피). EerieVillage `eab215d` push 정합. **[2026-05-13 ScalingMode Hierarchy 전수]** 모든 fx spawn 영역 ParticleSystem.MainModule.scalingMode = Hierarchy 설정 (HitFxScale 정합 적용·7 파일 전수). EerieVillage `6ed6efe` push 정합. **[2026-05-14 자연 fade SelfDestruct]** Projectile.SelfDestruct 영역 즉시 Destroy 영역 → ParticleSystem Stop(emission)·Collider/박스 disable·_speed=0·0.5s 후 Destroy·FADE_START_RATIO 0.85. 발사 영역 영역 영역 trail 자연 연속. EerieVillage `2ee5084` push 정합. **[2026-05-14 A08 캐스팅 제거·적 조준]** A08.asset OffsetDistance.x=0·CastFx=null·TargetEnemyOnFire=1·ActiveSkillData.TargetEnemyOnFire 신규·ProjectileSpawner.Trigger 영역 nearest enemy 방향 발사. 벽·발판 관통 X 영역 = Projectile.Update Layer 0·16 OverlapPoint 영역 정합. EerieVillage `55ee4f3` push 정합. **[2026-05-14 HitFx sortingOrder·적 조준 하단]** 모든 hit fx (Projectile·LightningStrike·MeleeArea·Laser) Renderer.sortingOrder += 100 (Enemy 영역 위)·ProjectileSpawner TargetEnemyOnFire 영역 toEnemy.y -= 0.5 (hitbox 영역 영역 영역 적중). EerieVillage `eb33e64` push 정합. **[2026-05-14 적 조준 중간 보정]** toEnemy.y -= 0.5 → 0.25 (이전·1차 중간·너무 하단 정정). EerieVillage `b52c99d` push 정합. | **진행중** | 신규 `Assets/Scripts/MyUI/SkillInventoryHUD.cs` (OnGUI 좌상단·장착 액티브 DisplayName·Lv·CooldownRemaining/EffectiveCooldown·패시브 카운트). PlayerController.Awake 자동 부착. 보강: ProjectileSpawner fallback prefab에 SpriteRenderer + 동적 흰색 원 sprite + 속성별 색상 (Fire 주황·Frost 하늘·Dark 보라·Lightning 노랑·Physical 흰). Unity 기본 자원 활용 — Texture2D 동적 생성 16×16 알파 원. **[이펙트 개선 완료 2026-05-13]** (PD 지시 "이펙트 개선작업은 완료처리"). 본 세션 (`cranky-wescoff-e855b0`) 누적: (1) 5 스킬 통합 + 1~5 키 발사 시스템 — A02·A04·A05·A_Laser·A13 (EerieVillage `2ebf313`). (2) Inspector 즉시 반영 필드 확장 — HitboxSize·OffsetDistance(Vector2)·OffsetXY·FxRotation·HitFxScale·DamageFrameDelay·EnableRepeatDamage·MaxHitCount·RepeatFrameInterval. (3) hit 모션 + flash 연출 (붉은색·alpha 50%·1 frame) — Animator self-loop transition + Health.DecrementBypassInvulnWithHit. (4) Scene 잔존 박스·FX 6개 cleanup + HideFlags.DontSave 8 spawn 지점 (EerieVillage `60e28e3`) — Edit Mode execute_code 측정 시 Scene 오염 방지 표준 확립. (5) FxRotation 박스 미적용 분리 (EerieVillage `ea7d32f`) — 박스(판정) = facing 만 · 이펙트(시각) = facing + FxRotation. 4 case 검증 (facing R/L × FxRotation 0/90 박스 무반응·facing 좌/우 정확 반전). (6) A05 좌우 베기 이펙트 Player 동조 (EerieVillage `f6c6eb5`) — MeleeAreaSpawner.SetParent(true) 추가·Player 전진 시 이펙트 밀림 정정 (Δ+2.0 동조 측정). 양 레포 push 정합. | — | **이펙트 개선 영역 = 완료 처리.** HUD·Icon UI·Layer Lab 카드 정합 등 잔여 사항은 PD 후속 결정 대기. 인수인계서: `공유/조직공지/2026-05-13_BT12-Dev_세션종결인수인계.md`. **[이펙트 작업 완성 확정 2026-05-14]** (PD 발화 "스킬 이펙트 작업은 완성이야. 임의로 투사체 판정 범위나 크기 등이 바뀌지 않도록 지금 상태를 잘 기록해"). 본 PM SOT 신설: `프로젝트/EerieVillage/개발/spec/스킬_이펙트_확정_v1.md` — 13 활성 스킬 (A01·A02·A03·A04·A05·A06·A08·A11·A12·A13·A14·A15·A_Laser) 핵심 필드 표 + 박스↔이펙트 분리 원칙 + EerieVillage stamp `1a1de0c`. **변경 금지 원칙**: PD 직접 명시 지시 없이 임의 변경 금지. 변경 시 SOT §4 갱신 + commit + PD 보고 의무. 본 PM·차기 세션 PM 모두 본 SOT 준수. | | BT12-MVP-A | 2026-05-08 | **경험치·레벨업·스킬 카드 선택 UI** — PD 직접 지시 2건 (1) 적 처치 → EXP → 레벨업마다 스킬 카드 3개 선택 기능 (2) 레벨업 UI (스킬 효과 추후·UI만). PD 첨부 예시 영역 ("기술 선택" 화면 — 카드 3장 가로·색상 배너·원형 아이콘·동심원·"레벨 N"/"최대"·"확인" 버튼). PD 결정 (β) 채택 — BT12-Dev 보류 일부 해제·BT12-MVP-A 분리 항목 진행. **PD 결정 D안 (2026-05-09)** — 기능 우선·그래픽 디테일 차후 영역. | **D안 완료 2026-05-09** | [Phase 1 완료] `프로젝트/EerieVillage/개발/spec/BT12-MVP-A_설계_v1.md` (~600 라인). [Phase 2-A 완료] EerieVillage `047661c` — 시스템 코드 6 + JSON 테이블. [Phase 2-B 코드 완료] EerieVillage `5b2b753` — UI 컴포넌트 2 + LevelUpManager 통합. **[Phase 2-B asset 5 완료 2026-05-08]** EerieVillage `755a51c` — `Assets/Data/SkillPlaceholders/{A01_jineonbu, A05_hagikjin, P01_bonghwanggyeok, P12_saengmyeongkkot, AW01_cheonbugyeongmun}.asset` (5) + 각 .meta (5) + folder meta 2 = 12 파일. C49 표준 — Phase 1 dev-team-lead Opus 첫 정합 호출 + Phase 2 Sonnet 위임 + Phase 3 PM 검증. **dev-team-lead 자진 고지** — 설계서 v1 §2-4 영역 P01·P12·AW01 BT11-Plan v0.2 정합 X (3건 정정 적용). **설계서 v1 §2-4 + §7-1 정정 완료** (commit 후속). PD Editor 가이드 신규 `BT12-MVP-A_Phase2B_PDEditor가이드.md`. 대화로그 엔트리 10. | — | **PM 후속 대기**: ① Phase 2-B B (Prefab) + C (Scene 통합) — **PD 직접 발화 (2026-05-08): "단계1은 완료. 단계2, 3은 개발팀에서 작업해줘" + "E"** → 옵션 E 채택 (Claude Desktop Unity MCP 위임) → 본 PM 의뢰서 작성 `BT12-MVP-A_Phase2B_ClaudeDesktop의뢰서.md` (~16K) → PD Claude Desktop 새 세션 영역 의뢰서 첨부 영역 작업 진행 → EerieVillage commit·push → 본 worktree PM 보고 ② Phase 3 dev-team-lead 통합 검증 (Phase 1 + 2-A + 2-B asset + Prefab + Scene + BT5-Dev/BT7-Dev 회귀) ③ **단계 4 PD Play 검증** (적 처치 → EXP → 레벨업 → UI 노출 → 카드 선택 → 게임 재개) ④ 기획팀 별도 안건 — `01_카드_풀.md` line 114 P12 = "도약강화" 잔존 정정 (`02_스킬_효과_컨셉.md` line 381·418 영역 동기화 X) ⑤ icon sprite asset 5장 별도 작업 ⑥ 완료 아카이브 이동. (PD Editor 가이드 영역 = 옵션 D 보류 영역·차기 영역 활용 가능) | | BT12-Dev | 2026-04-24 23:00 | **스킬 시스템 설계 (C43 "개발팀" 호칭 직접 수령 + C49 시범 적용)** — PD 직접 지시 "개발팀은 기획서를 토대로 스킬 시스템 설계 진행". 기획서 v0.2 (`프로젝트/EerieVillage/기획/content/02_스킬_효과_컨셉.md` 액티브 6카테고리·패시브 5카테고리·각성 4패턴) + CSV v0.3 60종 (`프로젝트/EerieVillage/기획/content/02_스킬_효과_컨셉_v0.3.csv` UTF-8 BOM) 토대. C49 표준 프로세스 시범 적용 (개발팀장 Opus 설계 → 클라이언트팀 Sonnet 구현 → 개발팀장 검증) **[Phase 2-A 완료 2026-05-09]** Skills 13 파일 신규 EerieVillage `87710ba` (Interfaces 4 + Data 4 + Runtime 4 + Events 1). **[Phase 2-B 투사체 완료 2026-05-09]** Effectors 7 파일 신규 + SkillFireEvent 정정 EerieVillage `2f2790c` (Sonnet 자율 push·feedback `feedback_pm_sonnet_subagent_unauthorized_push.md` 신설). **[Phase 2-C 투사체 6 asset 완료 2026-05-09]** PD 결정 "(a)안" — 본 PM 직접 placeholder 수치 작성. EerieVillage `c01f25a` (14 파일·A01·A02·A03·A08·A14·A15 ActiveSkillData ScriptableObject). DisplayName 한글만 (한자 X). 차후 balance-designer 정식 수치. SOT 채택 = PD 본문 (A16 사신 강림·A17 오발탄·A18 죽음의 가시). Phase 2 분할 = (b) 5분할 + b-1 카테고리 6분할. **[Phase 2-D BT12-MVP-A 통합 정정 완료 2026-05-09]** EerieVillage `d53150b` — 6 파일 수정 + 9 .meta 보충. LevelUpManager._pool 제거 → SkillRuntimeFactory.RandomDraw3() · SkillSelectionUI/SkillCardSlot ActiveSkillData 시그니처 전환 · PlayerController Awake PlayerSkillInventory 자동 부착 · Projectile Layer Enemy fallback (Minor 1·proxy) · SkillRuntimeFactory.RandomDraw3 신규. Sonnet 의뢰서 "git add·commit·push 절대 금지" 명시 (feedback `feedback_pm_sonnet_subagent_unauthorized_push.md` 정합). Compile error 0건. pm-auditor Pass + Minor 1. | **진행중** | **[Phase 1 완료 2026-04-24]** 개발팀장 Opus 직접 설계 완결 — `프로젝트/EerieVillage/개발/spec/스킬_시스템_설계_v1.md` (1074 라인, 14 섹션). §1 아키텍처 4계층 · §2 인터페이스 4종(`ISkillRuntime`·`IActiveSkill`·`IPassiveSkill`·`IAwakeningSkill`) + ScriptableObject 3종(`ActiveSkillData`·`PassiveSkillData`·`AwakeningSkillData`) + `PlayerSkillInventory`·`PlayerStats` · §3 CSV→ScriptableObject→Runtime→Health.Decrement 데이터 흐름 + 카테고리 문자열 매핑 · §4 VS 순수형 자동 발동 사이클 (OnTime·OnHit·OnKill + `ActiveSkillRuntime.Tick(deltaTime)` 독립 Cooldown) · §5 `AwakeningManager` 3 조건 동시 충족 + 4 패턴 Dispatcher + 다중 각성 선택 UI · §6 카테고리 매핑 6+5+4 (B는 BT7-Dev `AttackHitbox` 재활용 · 나머지 5 효과 발동기 신설) · §7 Phase 2-A~E 작업 단위 분해 (스크립트 25개·테스트 10건·asset 60개) · §10 BT7-Dev 통합 영역 (Health·AttackHitbox·PlayerAttackTicker·PlayerController 완전 보존 · `Health.OnDamagedEvent` 확장 필요 명시) · §11 기각안 5건 + 대화로그 추가 2건 (총 7건 C32 초과). 대화로그 `공유/대화로그/EerieVillage/2026-04-24.md` `[BT12-Dev Phase 1 완료] 개발팀장 스킬 시스템 설계 v1 (1074 라인)` 엔트리 완결. **C48 3자문 전수 통과**로 Phase 2 클라이언트팀 Sonnet Task는 본 Task에서 호출하지 않고 **PM 차원 별도 위임** 권고 (C48·C49·C50 정합) | **기획서 확정 대기** (PD 2026-04-25 직접 지시 — "기획서 확정되기 전까지 작업 대기") | **재개 트리거**: 기획팀 v0.3 또는 v1.0 확정 + balance-designer 60종 수치 확정 + narrative-designer 카드명 세계관 재매핑 결정 → C50 Phase 2 사전 승인 옵션(a/b/c/d) PD 결정 → 분할 시 Phase 2-A~E 순차 진행 (인터페이스·SO → 중앙 컴포넌트 → 효과 발동기 → 60장 .asset → EditMode 테스트) → Phase 3 개발팀장 검증 → 완료 아카이브. **선행 차단 블로커**: `paths.local.json.UNITY_PROJECT_ROOT: __SET_PER_PC__` 미설정 — 재개 시 PD PC 경로 설정 필요. Phase 1 산출물 1074 라인 설계 문서는 보존 | diff --git a/공유/기획/GodDem/2026-08-22_P3B2_장비강화_설계_v1.md b/공유/기획/GodDem/2026-08-22_P3B2_장비강화_설계_v1.md new file mode 100644 index 0000000..7b2db77 --- /dev/null +++ b/공유/기획/GodDem/2026-08-22_P3B2_장비강화_설계_v1.md @@ -0,0 +1,526 @@ +# GodDem 장비강화(아웃게임 Layer③) 수치 설계 v1 + +> **작성**: balance-designer(기획팀) 2026-08-22 · **P3-B2 산출물** (P32 맥락 분할 · C50 "설계까지, 구현은 개발팀장 후속") +> **PD 승인 원문(2026-08-22)**: "현 세션 B2 계속" + "우선 원작처럼 맞춰 전체 밸런싱 동일성 확인 후 추후 변경할 부분을 지시할게"(§31, B1에도 동일 적용된 원칙 — 원작 충실 1차, 조직 재량 변경은 후순위) +> **선행 문서(전부 Read 완료)**: [`2026-08-22_메타아키텍처_재설계_v1.md`](./2026-08-22_메타아키텍처_재설계_v1.md)(메타v1, §1-3·§3-4·§P3-B2) · [`2026-08-22_원작아키텍처_이식청사진_v1.md`](./2026-08-22_원작아키텍처_이식청사진_v1.md)(청사진v1) · [`2026-08-20_원작밸런스_해독_매핑_v1.md`](./2026-08-20_원작밸런스_해독_매핑_v1.md)(매핑v1, §2-3 heroequipment) · [`2026-08-22_원작배율_재추출_원본_v1.md`](./2026-08-22_원작배율_재추출_원본_v1.md)(재추출v1, heroequipment 비대상 확인) · [`2026-08-22_P3B1_레벨승급_설계_v1.md`](./2026-08-22_P3B1_레벨승급_설계_v1.md)(B1, 결합식·캡슐화 선례) +> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물. +> **범위**: Layer③(장비강화) 실수치 설계만 — 레벨업(확정 강화) 축. 등급업(forging 도박)·재련(reforging)은 골격만(C50, 가챠 B3 정책 정합 대상). ele_*/가챠(B3·B4)·스테이지(C) 범위 침범 없음. +> **표기 규칙(C5·C44)**: 🟢확정(코드 직접 실측) · 🟡추정(형태는 원작 근거, 절대치는 자체 재설계) · 🔴재추출 필요/미확보 +> **감사 이력(C35)**: plan-auditor 모드A 1회 수행 — 판정 **조건부통과**(Critical 2·Major 7·Minor 5, 산술 자체는 전량 무오류 확인). 본 v1은 그 지적을 전부 반영한 최종본이다. 주요 정정: (1) `SurvivalMetaData.EquipLevel` 필드가 실제로는 미구현임을 실측 확인 → §14 신규 필드로 정정(C-1) (2) 융합-강화 상호작용을 "레벨 이관"에서 "차단+환급 후 재투자"로 재설계 — 이관 방식이 데이터 소실 버그 + 비용 세탁 차익을 동시에 유발함을 감사가 발견(C-2·M-7) (3) 층 규모 판정 바스켓을 9종 전체(510,496G)에서 실제 장착 가능 6종(359,728G)으로 정정(M-1) (4) 런타임 구현을 폐쇄형 하드코딩에서 CSV 룩업으로 전환해 B1과 동일한 단일 SOT 패턴 정합(M-2) (5) 성장식을 후반 가속형(L²/128)에서 전반부 체감도 확보형((L²+8L)/192)으로 교체 — 만렙 종점(×3.0)은 불변, 초반 효율 대폭 개선(M-6) (6) C36 반전 고지 블록 신설(M-5) (7) 2차스탯 단위 불일치 근거를 오귀속 문서 인용에서 자체 코드 실측 근거로 교체(M-4). Minor 5건 전부 반영. + +--- + +## 0. 결론 요약 + +메타v1이 골격만 정의(§1-3)하고 유보한 실수치를 본 문서에서 확정한다. **핵심 결정 5건**: + +| 유보 사항 | 본 문서 결정 | +|---|---| +| heroequipment M수열(16단계) 원본 재대조 | **🔴 미해소.** 단, 우리 설계는 원작 절대 수열을 이식하지 않고 "형태만"(가속형 2차 성장) 재사용하므로 재추출 없이도 착수 가능(§2) — 단 이는 메타v1이 명시한 선행조건을 본 문서가 **해제**하는 것이므로 아래 ⚠️ 반전 고지 참조 | +| 슬롯 종속 2차 스탯(attack_speed=attack/2, defense=hp/4) 값 도출 | **원작 수식 직접 재사용 기각** — `SurvivalBattleManager.cs` L224-225 실측 결과 `attack_speed_add`는 비율(ratio) 단위로 소비되는데(`(1+spd)`로 나눗셈), 아이템의 `Attack`은 정액(flat) 단위다. "÷2"를 그대로 적용하면(item2 기준 14→7.0) **+700% 공속**이 되어 차원이 맞지 않는다(§5-2). 형태(공격형↔공속 페어링, 방어형↔방어 페어링)만 재사용하고 **값은 독립 재설계**(등급별 고정 계수×레벨성장) | +| 아이템 융합(TryFuse) ↔ 강화분 상호작용 | **차단 + 명시적 환급 후 재투자**로 확정(§7-3) — 최초안(레벨 이관)은 plan-auditor 감사에서 (a) 잔여 보유분의 레벨을 파괴하는 데이터 소실 버그 (b) 저가 아이템을 올려 고가 아이템 레벨을 무상 취득하는 비용 세탁 차익, 2개 결함을 동시에 유발함이 발견돼 채택하지 않음(구 기각안 참조, §12) | +| forging(등급 도박)·reforging(옵션 리롤) 채택 여부 | **미채택(구조 자리만)** — C50 범위 제약("골격만") + 확률 요소는 가챠(B3) 정책과 함께 판단해야 유저 경험이 일관됨(P30, §8) | +| 강화 대상 범위 | **9종 전체 정의**(itemId 단위, 메타v1 §1-3 원칙 그대로) — 단 실질 투자 대상은 슬롯당 최상위 6종(§6-2·M-1 정정) | + +**신규 확정 수치**: 레벨 0~16(17단계, 원작 M수열 길이 16과 동일 스텝 수 유지) × 9아이템, 성장식 `Stat(L) = Base × (1 + (L²+8L)/192)`(L16=×3.0, §4-1), 비용식 `Cost(item,L) = ItemBase(item) + 20L²+100L`(원작 "Base(quality)+V(level) 완전 가산" 형태 그대로). **슬롯당 최상위 6종 만렙 총비용 359,728G** — HeroLevel+Promotion 합계(1,056,056G, B1)의 **34.1%**로, 3번째 층이 앞 2개 층을 압도하지 않으면서도 유의미한 규모(나머지 3종은 융합 재료 성격이라 만렙 투자 대상이 아님, §6-2). + +### ⚠️ 원칙 반전 고지 (plan-auditor M-5 지적, C36 경계) + +메타v1 §1-3은 "`heroequipment`/`heroequipmentupgrade` 계단식 M수열 원본 CSV 재대조가 **P3-B2의 직접 선행 조건**"이라 명시했고, §6 표도 P3-B2 선행 조건에 "M수열 원본 재대조(R-A5)"를 포함시켰다. 이는 PD가 "설계대로 진행"으로 승인한 B1 헤더의 범위에 속한다. + +본 문서 §2는 이 선행조건을 **단독으로 해제**한다 — 판단 근거(레벨 축이 원작 절대치를 전혀 소비하지 않으므로 형태만 재사용해도 무방)는 지지 가능하나, B1이 동종 사안(메타v1 "상한 없음"→ 유한 캡)에서 거친 절차(§0에 반전 고지 → 팀장 확인 권고 → PD가 메타v1 정정)를 본 문서는 생략했다. **기획팀장·PM 인지 필요**(§16) — 재확인 결과에 따라 본 절 판단이 유지되거나, 재추출 선행으로 되돌려질 수 있다. + +--- + +## 1. 설계 전제 + +| 항목 | 값 | +|---|---| +| 기준 플레이어 수준 | 미투자(EquipLevel 전부 0) ~ 완전 맥스(실투자 6종 L16 장착, §6-2) 밴드 | +| 목표 경험 | "어느 장비를 밀어줄까"라는 2차 선택(메타v1 P30 근거) — 수집(가챠 B3 후속)과 육성(본 층)의 분리, 개별 아이템마다 다른 투자 경로 | +| 전제 스탯 앵커 | `SurvivalMeta.BaseAttack=22`/`BaseHp=400`(불변) · B1 HeroLevel맥스 +120atk/+480hp · Promotion맥스 +22%(3스탯 동일) | +| 전제 경제 앵커 | B1 총비용(HeroLevel 802,638G+Promotion 253,418G=1,056,056G) — 3번째 층 규모 산정의 상대 기준 | +| 재화 | 기존 `GOLD_ID=201` 직접 소비(원작 그대로, 메타v1 §1-3) | +| C39 실측 확증 | `SurvivalItemCatalog.cs`·`SurvivalMeta.cs`(TotalAttack/TotalHp/FinalAttack/FinalHp)·`SurvivalBattleManager.cs`(RecalcPlayer L211-238·ConsumedUpgradeKeys L169-177)·`SurvivalShopCatalog.cs`·`SurvivalHeroLevelTable.cs`·`SurvivalPromotionTable.cs`·`SurvivalUpgrade.cs`(CSV 로더 패턴) 직접 Read 완료 | + +--- + +## 2. ★ heroequipment M수열 재대조 결과 (확정/추정/재추출필요 구분) + +### 2-1. 매핑v1 §2-3 원본 데이터 (재확인, 변경 없음) + +| 항목 | 매핑v1 기재값 | 표기 | +|---|---|---| +| 레벨 배수 M(16단계) | `[1,2,4,8,12,20,28,40,52,68,84,104,124,148,172,200]`, 2차차분이 2레벨마다 +4인 계단식 2차 | ⚠️(매핑v1 자체 표기, 재추출 없음) | +| 등급 배수 | 1/5/10/20/40/80(q1→q2 ×5, 이후 ×2 등비) | ⚠️ | +| 비용 분해 | `Base(quality)+V(level)` 완전 가산, Base=q3 16,000/q4 42,000/q5 86,000/q6 326,000 | ⚠️ | +| 수확체감 | 없음(골드÷스탯 효율 2,375→2,500 평탄) | ⚠️ | +| 슬롯 종속 | subtype1(공격형) attack_speed=attack/2, subtype2(방어형) defense=hp/4, 192행 전수 성립 | ⚠️ | +| forging(등급도박) | rate 0.4/0.3/0.2/0.1(등차 -0.1), 비용×2 등비, 기대시도 2.5~10회 | ⚠️ | + +재추출v1(2026-08-22, ele_* 재검증 과정에서 heroequipmentskill만 재확인)은 **heroequipment/heroequipmentupgrade/forging 자체를 재추출 대상으로 다루지 않았다**(🟢 실측 확인 — 재추출v1 전문에 해당 테이블명 없음). 즉 매핑v1 §2-3은 **여전히 최초 ⚠️ 표기 그대로**이며, 매핑v1 §6-5·청사진v1 §5·메타v1 §1-3·R-A5가 반복 경고한 "실제 오류 4건 전부 ⚠️ 절에서 발생"의 대상 후보다. + +### 2-2. 판단 — 재추출이 이 문서의 착수 차단 조건인가 + +**아니다.** 이유는 B1이 이미 확립한 선례와 동일하다(`2026-08-22_P3B1_레벨승급_설계_v1.md` §3-1 "원작 절대치는 규모 불일치로 폐기"): 원작 M수열의 절대값(최종 배수 ×200)과 Base 비용(16,000~326,000)은 원작 12진영×150레벨×6등급 스케일에 맞춘 것이라, **재추출로 정확한 값을 확보해도 우리 스케일(아이템 기본 공격력 6~20, 체력 25~120)에 그대로 대입할 수 없다**. HeroLevel(B1)·Promotion(B1)·공격력 2층(원작2층v2)이 모두 "형태만 재사용, 절대 계수는 목표 역산"으로 처리한 것과 동일 원칙을 적용한다. + +**따라서 재추출의 실익은 "정확한 배율"이 아니라 "정확한 성장 프로파일 형태"(계단식 2차의 정확한 굴곡)에 한정된다.** 이는 §4의 근사식이 실제 M수열의 굴곡(1,2,4,4,8,8,12,12,16,16,20,20,24,24,28 — 2단위 페어마다 계단식 증가)과 **얼마나 유사한지 검증하는 참고용**으로만 가치가 있으며, 본 설계 착수 자체를 막지 않는다. **다만 이 판단은 메타v1이 명시한 선행조건을 본 문서가 해제하는 것이므로 §0 반전 고지를 따른다.** + +**🔴 재추출 필요분(개발팀장 후속, 차단 조건 아님)**: `heroequipment.csv`·`heroequipmentupgrade.csv`·`heroequipmentforging.csv` 원본 — 목적은 (a) M수열 굴곡이 매핑v1 기재값과 정확히 일치하는지 재검증 (b) forging rate·비용 등비의 정확한 원본값 확보(§8 미채택 skeleton의 향후 실채택 대비) (c) 매핑v1 §6-5 경고 이력에 따른 예방적 재검증. **우선순위**: 중(P3-B2 진행 자체를 막지 않으나, forging 실채택 결정 시점의 선행 조건). + +--- + +## 3. Layer③ 구조 확정 — 레벨업(확정)·등급업(도박, 미채택) 2축 + +원작은 레벨업(확정 강화)과 등급업(forging, 도박)이 **별도 축**이다(매핑v1 §2-3). 현재 GodDem `TryFuse()`는 "3개→1개 등급업"만 있고(무조건 성공), 레벨업 축 자체가 없다(청사진v1 §3 "정적인 값, 등급 1~2뿐" 확인). + +| 축 | 원작 대응 | GodDem 현황 | 본 문서 결정 | +|---|---|---|---| +| **레벨업**(EquipLevel, itemId별) | heroequipment+heroequipmentupgrade | 없음(신규) | **본 문서가 전량 설계**(§5~§7) | +| **등급업**(forging, 도박) | heroequipmentforging | `TryFuse()` 100% 확정 성공(3→1) | **현행 유지**(무변경) — 도박 요소 골격만 제시, 미채택(§8) | +| **재련**(reforging, 옵션 리롤) | heroequipmentreforging | 옵션 슬롯 자체가 없음(가챠 B3 선행 필요) | **N/A** — B3에서 옵션 슬롯 도입 후 재논의 | + +두 축은 서로 **독립**이다 — 단 강화분(EquipLevel>0)이 있는 아이템은 등급업(TryFuse) 재료로 쓰기 전에 먼저 강화를 초기화(환급)해야 한다(차단+환급 재설계, §7-3). + +--- + +## 4. 공식 + +### 4-1. 레벨업 성장 — 형태만 원작 재사용 + +``` +StatAtLevel(Base, L) = Base × (1 + (L² + 8L) / 192) [L = 0..16] + + L=0 : ×1.000 (불변 — 신규·기존 유저 공통 기준선) + L=4 : ×1.250 + L=8 : ×1.667 + L=12 : ×2.250 + L=16 : ×3.000 (만렙, 3배 — 종점은 최초안과 동일하게 유지) +``` + +**형태 도출 근거 — plan-auditor M-6 지적 반영 재설계**: 최초안(`1+L²/128`)은 원작 M수열의 "후반 가속"만 형태를 재사용했으나, 원작을 **배수(스텝 간 성장률) 관점**으로 다시 보면 정반대 형태다 — 원작 M수열(1,2,4,8,12,…,200)은 **초반 3스텝이 매번 ×2.00으로 배증**하고 뒤로 갈수록 배율이 감쇠하는 구조인데, 최초안은 초반 스텝이 ×1.008(사실상 무변화)이고 뒤로 갈수록 배율이 커지는 **반대 형태**였다(감사 실측: 원작 1→2스텝 ×2.00 vs 최초안 1→2스텝 ×1.008). 그 결과 저레벨 투자가 거의 무의미해 보이는 부작용이 있었다(§6-4). + +`(L²+8L)/192`는 선형항 `8L`을 더해 초반 체감을 끌어올리면서도, 분모를 128→192로 같이 조정해 **종점(L16=×3.0)은 최초안과 동일하게 유지**한다 — 이후 §5·§6·§9의 만렙(L16) 수치는 전부 무변경이며, L4·L8·L12 등 중간 체크포인트만 상향된다. `8`이라는 선형 계수와 `192` 분모는 "원작처럼 초반에도 체감이 있어야 한다"는 목표에서 역산한 1차 튜닝값이다(R-D1 계승). + +**왜 ×3.0인가(목표 역산)**: 6슬롯 전부 최고등급 아이템 장착 시 현재 상한이 Atk47/Hp305(B1 §5-1에서 이미 검증된 앵커)이다. ×3 배수를 적용하면 만렙 시 Atk141/Hp915(§6-3)로, HeroLevel 맥스 기여분(Atk120/Hp480)과 **같은 자릿수**가 된다 — 5개 층이 종국에는 서로 압도하지 않고 고르게 기여해야 한다는 설계 목표(메타v1 §0 "5층 상호작용")를 만족시키는 최소 배수로 ×3을 채택했다. + +### 4-2. 2차 스탯(슬롯 종속) — 독립 재설계 + +**원작 수식 직접 재사용 기각 사유(C5, plan-auditor M-4 지적으로 근거 교체)**: 최초안은 이 기각 근거를 원작 내부 단위(매핑v1 §2-7의 1e21~1e50 스케일)에서 찾았으나, 감사 결과 §2-7은 `A80ChampMatchConfig_data2.csv`(용도 미규명 테이블)를 가리키며 `heroequipment`와 무관함이 확인됐다 — 열어본 적 없는 테이블의 단위를 단정한 오귀속(C44 위반)이었다. **올바른 근거는 우리 쪽 코드에 있다**: `SurvivalBattleManager.cs` L224-225 실측 결과 `Player.AttackCooldown = PlayerAttackCooldown / ((1f + spd) * SkillSpeedMul)` — `attack_speed_add`는 **비율(ratio)** 단위로 소비된다. 반면 아이템의 `Attack`은 **정액(flat)** 단위다. 원작 "÷2"를 문자 그대로 적용하면 item2(Attack=14)의 secondary가 7.0이 되어 **`spd=7.0`→공속 +700%**라는 차원이 안 맞는 결과가 나온다 — 이 한 문장만으로 기각이 성립하며 원작 재추출 여부와 무관하다. 따라서 **형태**(공격형 아이템→공속 페어링, 방어형 아이템→방어 페어링)만 재사용하고 **값은 등급 기반 독립 곡선**으로 설계한다. + +``` +SecondaryRatio(item, L) = 0.015 × Grade(item) × (L² + 8L) / 192 [Grade = 1 또는 2, §4-1과 동일 곡선 형태] + + Grade1, L=16 : 0.015×1×2.0 = 0.03 (3%, 종점 최초안과 동일) + Grade2, L=16 : 0.015×2×2.0 = 0.06 (6%, 종점 최초안과 동일) +``` + +L=0에서 항상 0 — **신규 스탯이므로 미투자 상태(기존 장착 유저 포함)에서 소급 지급되지 않는다**(비파괴 보장, §9-1 검증). + +### 4-3. 슬롯→부스탯 매핑 (원작 subtype 재해석) + +원작은 "공격형/방어형" 2분류였다(슬롯 개념 자체가 아니라 아이템의 역할 분류). 우리 9종은 **주스탯이 무엇이냐**로 역할을 판정한다(슬롯명이 아니라 실제 능력치 조성 기준 — 향후 신규 아이템 추가 시에도 일관 적용 가능한 규칙): + +| 분류 | 근거 | 소속 아이템(id) | 2차 스탯 | +|---|---|---|---| +| **공격형** | 주스탯이 Attack뿐(Hp=0) | 1,2(Weapon)·4,8(Ring) | `equip_attack_speed_add` | +| **방어형** | 주스탯에 Hp 포함(Hp>0, Attack 유무 무관) | 3(Armor)·5(Boots)·6(Hat)·7,9(Charm) | `equip_defense_add` | + +**Hat·Charm이 방어형인 이유**: 두 슬롯 모두 Attack이 0이 아니지만(Hat 3atk/55hp, Charm 5atk/25hp·10atk/120hp) Hp 비중이 훨씬 커서(Hat 1:18, Charm 1:5~12) "방어형"으로 분류하는 것이 원작의 이분법(둘 중 하나) 원칙에 더 부합한다. 결과적으로 공격형 2슬롯(Weapon·Ring)·방어형 4슬롯(Armor·Boots·Hat·Charm)으로 갈리며, 이는 원작의 "2슬롯 균등 분배"가 아니라 **우리 6슬롯 체계에서 자연스럽게 도출된 비대칭**이다(기각안2 참조). + +### 4-4. 강화 비용 — Base+V 완전 가산 (원작 형태 그대로) + +``` +Cost(item, L) = ItemBase(item) + V(L) [L-1 → L 1회 비용, GOLD] + + V(L) = 20×L² + 100×L [전 아이템 공통] + ItemBase(item) = round(PowerScore(item) × 50) + PowerScore(item) = Attack + Hp/4 [4:1 비율 환산, A80ChampMatchConfig 준수] +``` + +**형태 도출 근거**: 원작 "Base(quality)+V(level) 완전 가산"(매핑v1 §2-3, "V가 8조합 전부 동일") 구조를 그대로 재사용 — `V(L)`은 아이템 무관 공통 곡선(원작의 "V 동일"에 대응), `ItemBase`는 아이템별 상수(원작의 quality별 Base 16,000~326,000에 대응)다. `PowerScore`로 `ItemBase`를 산정하는 것은 원작에 없는 **우리 자체 유도**(원작은 quality 1~6이라는 별도 축이 있어 직접 대응 불가, 매핑v1 §2-3에 quality-power 환산식 없음) — Attack/Hp 실능력치에 비례해 강한 아이템일수록 레벨업도 비싸지는 자연스러운 결과를 얻는다. + +--- + +## 5. 수치 테이블 + +### 5-1. 공통 V(L) 곡선 (전 아이템 동일, 9종 무관 1회만 표기 — C14) + +| L | V(L) | 누적ΣV | +|---|---|---| +| 0 | — | 0 | +| 2 | 280 | 400 | +| 4 | 720 | 1,600 | +| 6 | 1,320 | 3,920 | +| 8 | 2,080 | 7,680 | +| 10 | 3,000 | 13,200 | +| 12 | 4,080 | 20,800 | +| 14 | 5,320 | 30,800 | +| 16 | 6,720 | **43,520** | + +### 5-2. 아이템별 상수 (9종 전체 — PowerScore·ItemBase·만렙 총비용) + +| id | 이름 | 부위 | Grade | Attack | Hp | 분류 | PowerScore | ItemBase | 만렙(L16) 총비용 | +|---|---|---|---|---|---|---|---|---|---| +| 1 | 낡은 검 | Weapon | 1 | 6 | 0 | 공격형 | 6.00 | 300 | 48,320 | +| 2 | 강철 검 | Weapon | 2 | 14 | 0 | 공격형 | 14.00 | 700 | 54,720 | +| 3 | 사슬 갑옷 | Armor | 1 | 0 | 90 | 방어형 | 22.50 | 1,125 | 61,520 | +| 4 | 힘의 반지 | Ring | 1 | 8 | 0 | 공격형 | 8.00 | 400 | 49,920 | +| 5 | 신속의 부츠 | Boots | 1 | 0 | 40 | 방어형 | 10.00 | 500 | 51,520 | +| 6 | 마법사 모자 | Hat | 1 | 3 | 55 | 방어형 | 16.75 | 838 | 56,928 | +| 7 | 번개 부적 | Charm | 1 | 5 | 25 | 방어형 | 11.25 | 563 | 52,528 | +| 8 | 보석 반지 | Ring | 2 | 20 | 0 | 공격형 | 20.00 | 1,000 | 59,520 | +| 9 | 용의 보물함 | Charm | 2 | 10 | 120 | 방어형 | 40.00 | 2,000 | 75,520 | +| | | | | | | | | **9종 합계** | **510,496** | + +**반올림 규약(plan-auditor m-2 지적)**: `ItemBase = round(PowerScore×50)`의 반올림은 **half-up**(사사오입, item7의 562.5→563)을 채택한다. `Mathf.RoundToInt`(banker's rounding, 562.5→562)를 쓰면 item7 총비용이 52,512G(−16G), 9종 합계가 510,480G(−16G)가 된다 — 차이는 무시 가능한 수준이나 구현 시 half-up으로 명시 캐스팅(`Mathf.RoundToInt(x+0.5f)` 또는 `Mathf.FloorToInt`)할 것. + +### 5-3. 대표 체크포인트 — item2(공격형·Grade2)·item9(방어형·Grade2) (C14, 전체 17행×9종=153행은 공식 적용 결과) + +| L | item2 Attack | item2 speed% | item2 누적비용 | item9 Attack/Hp | item9 defense% | item9 누적비용 | +|---|---|---|---|---|---|---| +| 0 | 14.00 | 0% | 0 | 10.00/120.00 | 0% | 0 | +| 4 | 17.50 | 0.75% | 4,400 | 12.50/150.00 | 0.75% | 9,600 | +| 8 | 23.33 | 2% | 13,280 | 16.67/200.00 | 2% | 23,680 | +| 12 | 31.50 | 3.75% | 29,200 | 22.50/270.00 | 3.75% | 44,800 | +| 16 | 42.00 | 6% | **54,720** | 30.00/360.00 | 6% | **75,520** | + +**비용(누적비용) 열은 §4-1 곡선 교체와 무관하게 불변**이다 — Cost(item,L)는 §4-4의 별도 공식(`ItemBase+V(L)`)이며 성장식과 독립이므로, 곡선을 후반가속형→전반부체감확보형으로 바꿔도 비용 테이블은 그대로 재사용된다. + +--- + +## 6. 성장 곡선 + +### 6-1. 원작과의 형태 비교 + +- **원작**: M수열 최종 배수 ×200(레벨16), 수확체감 없음(효율 평탄) — 절대 배수가 우리 스케일에 비해 압도적으로 큼(§2-2 재설명). 배수(스텝 간 성장률) 관점으로는 **초반 3스텝이 매번 ×2.00 배증**하고 후반으로 갈수록 배율이 감쇠하는 형태다. +- **본 설계(§4-1 재설계 후)**: 종점 ×3.0(레벨16)로 "무한 팽창하는 절대 배수"는 폐기하되, `(L²+8L)/192` 곡선으로 **초반에도 원작처럼 유의미한 배증 체감**을 확보하고 다른 층과 자릿수가 맞는 목표치로 역산했다(§4-1 개정 근거). 원작처럼 "수확체감 없음"(레벨당 증분이 줄지 않음)은 여전히 성립 — 이 곡선도 매 레벨 증분이 이전 레벨보다 크거나 같다. + +### 6-2. 만렙 시 층 기여도 비교 — 실투자 대상 6종 기준 (M-1 정정) + +**바스켓 정정**: §0 최초안은 "9종 전체 만렙"(510,496G)과 "6슬롯 장착 기여분"(+94/+610)을 나란히 제시해 서로 다른 바스켓을 섞었다(plan-auditor M-1). id1·4·7은 각각 id2·8·9와 같은 슬롯의 하위호환 열위 아이템이자 §7-3 융합의 **재료**이므로, 만렙까지 투자하는 것은 합리적 플레이가 아니다 — "9종 전체 만렙"은 실제 달성 목표가 아니다. 아래는 **슬롯당 최상위 6종**(id 2·3·5·6·8·9) 기준으로 재작성한다. + +| 항목 | 값 | +|---|---| +| 실투자 대상 6종 만렙 총비용(§5-2에서 6종만 합산) | **359,728G** | +| B1(HeroLevel+Promotion) 총비용 대비 비율 | 359,728 / 1,056,056 = **34.1%** | +| id1·4·7(재료 3종) 만렙 총비용(투자 대상 아님) | 150,768G — 참고용, 층 규모 판정에서 제외 | + +| 층 | Attack 기여(만렙) | Hp 기여(만렙) | +|---|---|---| +| 기초(BaseAttack/BaseHp) | 22 | 400 | +| ①HeroLevel(B1, L60) | +120 | +480 | +| ②Promotion(B1, star11, ×1.22배) | (승산) | (승산) | +| **③EquipUpgrade(본 문서, 6종 만렙 장착)** | **+94**(141−47 순증분) | **+610**(915−305 순증분) | + +③의 순증분(+94atk/+610hp)이 ①(+120/+480)과 자릿수가 같다 — §4-1에서 설정한 목표("HeroLevel과 같은 자릿수") 충족 확인. (표는 아웃게임 3개 층만 열거 — 가챠④·스킬마스터리⑤는 본 문서 범위 밖.) + +### 6-3. 전체 만렙(①②③ 동시 최대) 결합 결과 + +``` +TotalAttack(만렙) = 22(base) + 141(장비 6종 L16 장착) + 120(HeroLevel L60) = 283 +TotalHp(만렙) = 400(base) + 915(장비 6종 L16 장착) + 480(HeroLevel L60) = 1,795 + +FinalAttack = 283 × 1.22(Promotion star11) = 345.3 (B1 단독 맥스 230.6 대비 +49.7%) +FinalHp = 1,795 × 1.22 = 2,189.9 (B1 단독 맥스 1,445.7 대비 +51.5%) +``` + +(§6-2·§6-3의 "TotalAttack/TotalHp"는 개념 설명용 표기이며, 실제 코드의 `SurvivalMeta.TotalAttack()`은 §7-1이 정의하는 장비 합산 전용 메서드다 — 혼동 방지를 위해 명시) + +### 6-4. 층 간 진입 우선순위 — 초반 효율 검증 (plan-auditor M-6 지적 반영, 신설) + +§4-1 곡선 개정(전반부 체감 확보) 이후에도, **골드 1단위당 파워스코어(Attack+Hp/4) 획득량** 기준으로 층별 효율을 비교하면 장비강화는 여전히 "초반 그라인드"가 아니라 "중반 이후 투자" 층에 가깝다. + +| 비교 지점 | G/PowerScore(한계) | +|---|---| +| HeroLevel(B1) L23→24 | 950 | +| **EquipUpgrade item9 L0→1**(개정 곡선 적용) | 1,131 | +| EquipUpgrade item9 L5→6(효율 최적 구간) | 839 | +| HeroLevel(B1) L29→30 | 1,755 | + +item9(가장 강한 방어형 아이템)의 첫 레벨조차 HeroLevel의 **약 23~24레벨 지점**과 비슷한 한계효율이다 — 즉 합리적 플레이어는 HeroLevel을 20대까지 올린 이후에나 장비강화에 골드를 배분하기 시작하는 편이 효율적이다. 최초 곡선(`L²/128`) 대비 §4-1 개정으로 이 진입점 자체는 크게 앞당겨지지 않았다(개정 전 item9 L1 한계효율은 6,784 — HeroLevel L48 지점과 동급이었음) — **개정이 실제로 고친 것은 "첫 클릭의 절대 체감"(0.94hp→5.63hp 표시값)이지 "효율 순위"가 아니다.** 효율 순위가 늦은 근본 원인은 `ItemBase`(고정 오버헤드)가 저레벨 스탯 증분에 비해 상대적으로 크기 때문이며, 이는 성장곡선이 아니라 **비용식(§4-4)의 구조적 특성**이다. + +**미해결·후속 필요(system-designer·PD 인지, §16)**: 장비강화를 "HeroLevel과 항상 병행 가능한 층"으로 설계할지, 아니면 "HeroLevel 중반 이후 열리는 2차 투자처"로 의도할지는 방향성 질문이다 — 본 문서는 후자에 가까운 결과를 냈으나 이를 의도적으로 채택한 것은 아니다(1차 추정치의 부수 효과). 전자를 원하면 `ItemBase` 계수(현재 PowerScore×50)를 낮추거나(예: ×30) `V(L)`의 저레벨 항을 완화하는 것이 조정 손잡이다(R-D1). + +--- + +## 7. 매판 시작 베이스 결합 (구현 가이드라인 — B1 캡슐화 원칙 그대로 확장) + +메타v1 §3-4·B1 §5가 이미 `TotalAttack()`/`TotalHp()`를 "호출부는 이것만 부른다" 캡슐로 확정했고, **③장비강화 항은 그 안에 자리만 예약된 상태**였다(B1 §5 말미 "③장비강화 항은 P3-B2 범위이므로 본 문서는 자리만 예약" — plan-auditor m-5 지적으로 출처 정정: 메타v1 §5-3이 아니라 B1 §5). 본 절에서 그 자리를 채운다. + +**★ 전제(plan-auditor C-1 지적) — `SurvivalMetaData.EquipLevel` 필드는 아직 없다.** `SurvivalMeta.cs` L11-34 실측 결과 현재 필드는 `Owned`·`Equipped`·`DailyPurchase`·`LastDailyReset`·`HeroLevel`·`PromotionStar`·`Version=2` 7개뿐이다. 메타v1 §5-1이 설계 문서상 `EquipLevel`을 선언했으나 B1 구현(`a3f62ab`)에는 반영되지 않았다 — 아래 코드는 **§14-4가 명시하는 필드 추가(신규 필드·`Version` 3 상향·`Load()` 초기화 3항)가 선행돼야** 동작한다. + +**★ 런타임 SOT 방식 — CSV 룩업(plan-auditor M-2 지적 반영, B1 패턴 정합)**: 최초안은 `(1+lv*lv/128f)`류 계수를 코드에 하드코딩하면서 동시에 §14-3에 153행 CSV를 산출물로 요구해, "폐쇄형 상수가 실 SOT이고 CSV는 사본"이 되는 이중 SOT를 유발했다(`SurvivalMeta.cs` L60-67 주석이 명시 경고하는 패턴). B1의 `SurvivalHeroLevelTable.AttackBudgetAt()`(행 직접 룩업)와 동일하게, 아래는 `SurvivalEquipUpgradeTable`(신규, §14-4) CSV 룩업 방식으로 재작성한다 — §4·§5의 공식은 **CSV 값을 생성한 근거**로만 남고, 런타임은 CSV만 읽는다. + +### 7-1. TotalAttack()/TotalHp() 수정 (기존 메서드 확장, 신규 메서드 아님) + +```csharp +// SurvivalMeta.cs — 기존 TotalAttack()/TotalHp() 를 레벨 반영으로 교체 +static SurvivalEquipUpgradeTable _equipUpgrades; +public static SurvivalEquipUpgradeTable EquipUpgrades => _equipUpgrades ??= SurvivalEquipUpgradeTable.Load(); + +public static float TotalAttack() +{ + float sum = 0f; + for (int i = 0; i < 6; i++) + { + var def = SurvivalItemCatalog.Get(Data.Equipped[i]); + if (def == null) continue; + int lv = Data.EquipLevel.TryGetValue(def.Id, out int l) ? l : 0; + sum += def.Attack + EquipUpgrades.AttackAddAt(def.Id, lv); // def.Attack=L0 베이스, CSV값=순증분(§14-3) + } + return sum; +} +// TotalHp() 동일 패턴(def.Hp + EquipUpgrades.HpAddAt(def.Id, lv)) +``` + +### 7-2. 신규 메서드 — 2차 스탯 (Promotion 방어% 처리와 동일 캡슐화 패턴, CSV 룩업) + +```csharp +public static float EquipAttackSpeedRatio() // 공격형 슬롯 합산 +{ + float sum = 0f; + for (int i = 0; i < 6; i++) + { + var def = SurvivalItemCatalog.Get(Data.Equipped[i]); + if (def == null || def.SecondaryStatKey != "equip_attack_speed_add") continue; + int lv = Data.EquipLevel.TryGetValue(def.Id, out int l) ? l : 0; + sum += EquipUpgrades.SecondaryValueAt(def.Id, lv); + } + return sum; +} +public static float EquipDefenseRatio() // 방어형 슬롯 합산 — 동일 패턴, "equip_defense_add" 필터 +``` + +### 7-3. 융합(TryFuse) ↔ 강화분 상호작용 — 차단 + 환급 후 재투자 (재설계, 구 기각안3 폐기) + +**최초안(레벨 이관, max 방식) 폐기 사유(plan-auditor C-2·M-7)**: `TryFuse()`는 3개만 소모하고(`RemoveItem(def.Id, 3)`) 잔여 보유분이 남을 수 있는데(코드 L224가 `OwnedCount<=0` 조건을 별도 검사하는 것이 그 증거), 최초안은 융합 성공 시 `EquipLevel.Remove(def.Id)`를 **무조건** 실행해 **잔존 아이템의 레벨을 전소**시켰다(C-2, 투자 손실 재발 — 본 문서 §0이 스스로 막겠다던 바로 그 손실). 게다가 `EquipLevel`이 itemId 단위(보유 개수 무관 공유값)이므로, 이 방식은 **저렴한 아이템을 올린 뒤 융합해 비싼 아이템의 레벨을 무상 취득**하는 비용 세탁 차익을 구조적으로 허용했다(M-7 — item7→9 경로만으로 22,992G 차익). 두 결함은 함께 재설계해야 하므로 이관 방식 자체를 폐기한다. + +**재설계 — 차단 기본값 + 명시적 환급-초기화 에스케이프**: + +```csharp +// TryFuse() 수정 — 강화분이 있는 아이템은 기본적으로 융합 차단 +if (Data.EquipLevel.TryGetValue(def.Id, out int lv0) && lv0 > 0) +{ + message = $"{def.Name}은(는) 강화 Lv.{lv0} 투자 상태입니다 — 먼저 강화 초기화(환급)가 필요합니다."; + return false; // 융합 자체를 진행하지 않음. 세탁 차익 경로 원천 차단 +} +// 강화분 0인 아이템만 기존 로직대로 융합 진행(무변경) + +// 신규 공개 메서드 — 플레이어가 명시적으로 호출(경고 UI 동반, ux-designer 후속) +public static long ResetEquipLevelWithRefund(int itemId) +{ + if (!Data.EquipLevel.TryGetValue(itemId, out int lv) || lv <= 0) return 0; + long spent = EquipUpgrades.CumulativeCostAt(itemId, lv); // §14-3 누적 CSV 합 + long refund = spent / 2; // 50% 환급(§10 제안값, 조정 가능) + CurrencyManager.Instance?.Add(ItemType.Goods, Constant.GOLD_ID, refund); + Data.EquipLevel[itemId] = 0; + Save(); + return refund; +} +``` + +**설계 근거**: 차단을 기본값으로 되돌리되(메타v1 원 기본권고와 결과적으로 동일), "경고 후 확인"(메타v1 §1-3 원 표현) 흐름을 **50% 환급이라는 구체적 비용**으로 구현해 순수 차단보다 덜 좌절스럽게 만든다. 세탁 차익이 불가능한 이유: 초기화(50% 손실) 후 재투자(정가 100%)를 거치면 총비용이 **직접 투자보다 항상 비싸다**(150% 지출) — 무상 차익 경로가 사라진다. + +### 7-4. RecalcPlayer() 결합 — 2곳 수정 (B1 §7 defense 분리식 확장) + +```csharp +// L224 spd — 공속은 클램프가 없어 단순 가산으로 충분(방어처럼 분리항 불필요) +float spd = t.Total("attack_speed_add") + SurvivalMeta.EquipAttackSpeedRatio(); + +// L237 outgameRatio — 승급 방어%와 같은 "아웃게임 버킷"에 합산 후 클램프 분리(B1 §7 원칙 그대로 확장) +float outgameRatio = SurvivalMeta.PromotionDefenseRatio() + SurvivalMeta.EquipDefenseRatio(); +Player.DamageReduction = 1f - (1f - ingameReduce) * (1f - outgameRatio); // 기존 식 무변경, 항만 추가 +``` + +**호출부는 3곳(B1 §5 기존 3곳) 무변경** — `TotalAttack()`/`TotalHp()`가 내부적으로 레벨을 반영하므로 `ApplyMetaEquipment()`·`RefreshHeroStats()`·`UpdatePropertyText()`는 코드 수정이 필요 없다(3중 SOT 방지 원칙이 정확히 의도한 효과). + +--- + +## 8. forging(등급 도박)·reforging(재련) — 골격만 (C50 경계) + +**미채택 사유**: (1) C50이 본 문서 범위를 "골격만"으로 제한(가챠 B3와 정책 정합 필요) — 확률형 강화는 가챠와 함께 유저에게 "확률" 경험을 얼마나·어떻게 노출할지 **일관된 정책** 하에 판단해야 한다(P30, 서로 다른 시점에 서로 다른 확률 UX를 노출하면 혼란). (2) 재련(reforging)은 "옵션 슬롯"이 전제인데 우리 아이템엔 옵션 슬롯 자체가 없다(가챠 B3가 도입 예정, 메타v1 §5-2 `SurvivalMetaGachaOption.csv`). + +**향후 채택 시 재사용 가능한 골격**(원작 형태, 매핑v1 §2-3 — 값은 §2 재추출 이후 확정): + +``` +등급업 성공률(도박): rate = 0.4, 0.3, 0.2, 0.1 (등급 1→2→3→4→5 시도, 등차 -0.1) +등급업 비용: 등비 ×2 (실패 시 재시도 비용 상승) +재련(옵션 리롤) 잠금 비용: 2^N (N=재련 횟수, 매핑v1 §2-8 표기값 — ⚠️ 해당 절도 재추출 대상은 아니었으므로 §2-1과 동일 기준으로 미확정 처리, plan-auditor m-4) +``` + +**현재 유지**: `TryFuse()` 100% 확정 성공(3개→1개), 등급 1→2 승급 경로 무변경. 레벨(EquipLevel)과 등급(Grade)은 완전히 독립된 축 — 레벨업은 본 문서가 확정, 등급업은 무변경. + +--- + +## 9. 검증 시나리오 + +| # | 시나리오 | 통과 기준 | 결과 | +|---|---|---|---| +| 1 | 신규 유저 기준선 | 미장착·EquipLevel 전부 0 → TotalAttack=0, TotalHp=0 (기존과 동일) | **통과**(§7-1 공식, lv=0→배율×1) | +| 2 | **기존 유저 비파괴**(신규 발견 검증 포인트) | 이미 장착 중인 유저가 패치 후 EquipLevel=0(기본값)일 때 Attack/Hp/2차스탯 전부 패치 전과 동일 | **통과** — `1+(0²+8×0)/192=1` 항등, `SecondaryRatio`도 L=0에서 정확히 0 (소급 지급 없음, §4-2) | +| 3 | 단일 아이템 만렙 산술(item2) | L16 Attack=14×3=42 | **통과**(§5-3) | +| 4 | 2차 스탯 등급 차등(item1 vs item9) | Grade1 만렙=3%, Grade2 만렙=6% | **통과**(§4-2 공식 대입) | +| 5 | 실투자 6종 전체 만렙 결합(M-1 정정) | Attack=141·Hp=915(§6-2), 3개 층(①②③) 결합 시 FinalAttack 345.3(§6-3) | **통과**, HeroLevel과 동일 자릿수 목표 충족 | +| 6 | defense 클램프 안전성(3개 층 동시 최대) | Promotion22%+EquipDefense15%=37%, 인게임 0.8 클램프와 결합해도 <100% | **통과** — `1-(0.2×0.63)=87.4%`, 무적화 없음(B1 §7 원칙 확장 유지) | +| 6-2(신규) | attack_speed 상한 확인(m-5) | Weapon(item2 G2)+Ring(item8 G2) 만렙 = 6%+6%=12%, 클램프 없음 | **통과** — 상한 없는 가산이나 12%는 인게임 `attack_speed_add` 만렙 대역(원작 기준 최대 30%)과 비교해 과도하지 않음 | +| 7(재설계) | 융합 차단 + 환급 재투자(C-2·M-7 재설계 후) | EquipLevel>0 아이템 융합 시도 → 차단(§7-3) 확인 → `ResetEquipLevelWithRefund` 호출 후 재시도 → 성공, 잔존 미융합 아이템의 레벨은 애초에 건드려지지 않음(차단이므로) | **통과**(§7-3, 데이터 소실 경로 원천 차단) | +| 7-2(신규) | 세탁 차익 봉쇄 검증(M-7) | item7(Grade1) L16 환급 50%(26,264G 회수, 총 지출 52,528G) 후 item9(Grade2) 정가 재투자(75,520G) = 총 101,784G, 직접 item9 만렙(75,520G) 대비 **+34.8% 손해** | **통과** — 세탁 경로가 직접 투자보다 항상 비쌈, 무상 차익 불가 | +| 8 | 강화 비용 단조성 | PowerScore가 클수록(item9=40) 총비용도 큼(75,520) but 배율은 완만(item1 대비 1.56배, PowerScore 6.7배 대비 완만) | **통과**(§5-2, 의도된 댐핑 — 강한 아이템이 압도적으로 비싸지지 않도록) | +| 9(신규) | 초기 진입 효율(M-6) | item9 L0→1 한계효율 1,131 G/PowerScore ≈ HeroLevel L23→24(950) 지점과 동급 | **정보성 — 미해결**(§6-4, system-designer·PD 인지 필요 사항으로 이관, 통과/실패 판정 대상 아님) | + +--- + +## 10. 밸런싱 제안 표 + +| 항목 | 현재 값 | 제안 값 | 근거 | +|---|---|---|---| +| EquipLevel 범위 | 없음(신규) | 0~16(17단계) | 원작 M수열 16단계와 스텝 수 일치(§4-1) | +| 아이템 성장식 | 없음 | `Base×(1+(L²+8L)/192)`, L16=×3.0 | HeroLevel 만렙 기여와 동일 자릿수 목표 역산, 전반부 체감 확보(§4-1·§6-2, plan-auditor M-6 반영 개정) | +| 2차 스탯 종류 | 없음 | 공격형→equip_attack_speed_add, 방어형→equip_defense_add | 원작 subtype 페어링 형태 재사용, 값은 원작 단위 불일치로 독립 재설계(§4-2) | +| 2차 스탯 계수 | 없음 | `0.015×Grade×(L²+8L)/192`(만렙 Grade1=3%·Grade2=6%, 종점 불변) | 등급이 높을수록 2차도 강함(원작 "고등급=고Base" 관계 보존) | +| 강화 비용 공통항 V(L) | 없음 | `20L²+100L` | 원작 "Base+V 완전가산" 형태, V는 아이템 무관 공통(§4-4) | +| 강화 비용 아이템항 ItemBase | 없음 | `PowerScore×50` | 아이템 실능력치 비례 — 강한 아이템일수록 강화도 비쌈(§4-4) | +| 융합↔강화 상호작용 | 없음(정의 안 됨) | **차단 + 50% 환급 후 재투자**(§7-3) | 메타v1 "융합 차단" 기본권고 채택 + 에스케이프 밸브 추가 — 최초안(레벨 이관)은 데이터소실·세탁차익 결함으로 폐기(plan-auditor C-2·M-7) | +| 강화분 초기화 환급률 | 없음(신규) | 누적 투자액의 50% | 순수 차단보다 덜 좌절스럽되, 재투자 총비용(150%)이 항상 직접투자(100%)보다 비싸 세탁차익 원천 차단(§7-3·§9 #7-2) | +| forging(등급도박) | 없음(TryFuse 100%) | 무변경, 골격만 제시 | C50 경계 — 가챠(B3) 정책 정합 후 별도 판단(§8) | + +**세그먼트 영향**: 전 항목 **현재 전 세그먼트 동일**(B1과 동일 고지 승계) — `GOLD_ID` 공유로 무과금은 플레이 누적, 고과금은 골드팩 구매로 시간 단축(F2P 표준 구조, B1 §10 판정 재확인). 본 층 도입으로 골드 소모처가 **하나 더 늘어** B1 §11 R-C7("소모처 부족으로 골드팩 판매력 재산정 필요 가능성")의 우려를 오히려 완화하는 방향(추가 확인 불요, 관찰 유지 권고). + +--- + +## 11. 리스크 + +| ID | 리스크 | 심각도 | 내용 | +|---|---|---|---| +| **R-D1** | 성장식(`(L²+8L)/192`, 종점×3.0) 무플레이테스트 1차 추정 | 중(🟡) | C2 "첫 숫자는 틀릴 것" 원칙 — 선형계수 `8`·분모 `192`·`×50` ItemBase 계수·환급률 50%가 1차 튜닝 손잡이. 플레이테스트 후 조정 전제 | +| **R-D2** | 2차 스탯 단위 불일치로 원작 수식 미재사용 | 낮음(정보성) | §4-2 — 원작 "÷2·÷4"를 그대로 못 쓴 것은 재추출로 해소되지 않는 **구조적 단위 문제**(우리 코드 실측 — `attack_speed_add`는 비율, `Attack`은 정액). 독립 설계값(0.015/0.03)은 최초 추정, 조정 여지 큼 | +| **R-D3** | heroequipment M수열 재추출 미해소 | 낮음(주의, 착수 차단 아님 — 단 §0 반전 고지 대상) | §2-2 — 우리는 절대 수열을 이식하지 않으므로 재추출 실익은 "형태 검증"에 한정. forging 실채택 시점엔 우선순위 상향 필요. **다만 이 판단 자체가 메타v1 선행조건 해제이므로 절차 검증은 §0 참조(M-5)** | +| **R-D4** | 실투자 6종 만렙 총비용(359,728G) 실제 런 도달 스테이지 대비 미검증 | 중(🟡) | B1 R-C2와 동일 계열 — 스테이지 설계(P3-C) 확정 전까지 "몇 런에 만렙 도달"은 폭넓은 추정치 | +| **R-D5(해소, plan-auditor M-5로 재정의)** | 재추출 선행조건 해제 절차 누락 | 낮음(절차, §0 조치 완료) | 최초안은 메타v1 §1-3 명시 선행조건("M수열 재추출 필수")을 해제하면서 B1이 확립한 반전고지 절차(§0 블록·팀장 확인 권고)를 생략했다 — §0에 반전고지 블록 신설로 해소. 기획팀장·PM 확인은 §16 후속 | +| **R-D6** | 공격형/방어형 분류가 슬롯이 아니라 "주스탯 우세"(§4-3) 기준 | 낮음(향후 확장 대비) | 향후 가챠(B3)가 신규 아이템(예: HP우세 Ring)을 추가하면 "Ring=항상 공격형"이 깨질 수 있음 — content-designer가 신규 아이템 `SecondaryStatKey` 설정 시 슬롯이 아니라 본 절 규칙(주스탯 기준)을 참조해야 함 | +| **R-D7** | `equip_attack_speed_add`/`equip_defense_add`는 18종 능력치 집합 밖의 신규 파생 키 | 낮음(정보성) | `SurvivalStatCatalog.cs`(18종 SOT)에 등재 대상 아님 — Promotion의 `PromoDefenseAddRatio`와 동일하게 "층 내부 파생 메커니즘"으로 분류(§13). 향후 유지보수자가 "18종에 왜 없지"라고 오인하지 않도록 카탈로그 주석에 교차 참조 권고 | +| **R-D8(신규, plan-auditor M-6 반영)** | 장비강화 진입 시점이 HeroLevel 20대 중반 이후로 늦음 | 중(🟡, 방향 확인 필요) | §6-4 — 개정 곡선도 한계효율 기준으로는 HeroLevel 23~24 지점과 동급. "층은 언제든 병행 가능해야 하는가, 중반 이후 투자처로 의도해도 되는가"는 system-designer·PD 확인 필요(§16) | +| **R-D9(신규, plan-auditor C-2·M-7 재설계 반영)** | 강화분 초기화 환급률(50%) 미검증 1차값 | 낮음(🟡) | §7-3·§9 #7-2 — 50%는 "순수 차단보다 덜 좌절스러움"과 "세탁 차익 완전 봉쇄"를 동시에 만족하는 최소 조건에서 역산하지 않은 1차 추정치. 플레이테스트로 조정 가능(R-D1 손잡이 목록에 포함) | + +--- + +## 12. 기각안 (C32) + +| # | 검토안 | 기각 사유 | +|---|---|---| +| 1 | 슬롯 단위 강화(itemId 아닌 슬롯 레벨) | 메타v1이 이미 §1-3에서 "슬롯 단위면 수집 동기 약화"로 확정한 방향 — 본 문서에서 재논의 대상 아님(전제로 승계) | +| 2 | 공격형/방어형을 원작처럼 정확히 2슬롯(또는 우리 6슬롯 3:3)으로 균등 분배 | §4-3 — 우리 아이템의 실제 스탯 조성(Hat·Charm이 Hp 우세)을 무시하고 슬롯 이름만으로 균등 분배하면 "방어구인데 공속을 주는" 부자연스러운 결과가 나옴. 주스탯 기준(2공격형:4방어형)이 원작의 "역할 기반 이분법" 정신에 더 충실 | +| 3 | 강화분>0 아이템의 융합을 조건 없이 영구 차단(초기화·환급 경로 없이) | 초반에 낮은 등급 아이템(item1·4·7)에 실수로 투자한 유저가 영구히 융합 못 하는 좌절 발생 가능(소프트락 유사) — 50% 환급 초기화 에스케이프(§7-3)를 추가하면 동일한 안전성을 유지하면서 마찰만 줄일 수 있어 순수 차단보다 상위호환 | +| 4 | forging(등급 도박) 즉시 채택 | C50이 본 문서를 "골격만"으로 제한 — 확률형 강화 경험은 가챠(B3)와 함께 유저에게 일관되게 노출해야 함(P30). 골격만 제시하고 실채택은 후속 결정으로 유예 | +| 5 | 원작 M수열(16단계 절대값 ×1~×200)·Base 비용(16,000~326,000)을 재추출 후 그대로 대입 | §2-2 — 원작 스케일(12진영×150레벨×6등급)과 우리 스케일(9아이템, 기본값 6~120)이 근본적으로 달라 그대로 대입 시 자릿수가 터짐(B1·공격력2층 선례와 동일 판단). 형태(가속형 2차)만 재사용 | +| 6 | 원작 "attack/2"·"hp/4" 수식을 우리 게임에도 문자 그대로 적용 | §4-2 — 원작 내부 파워 단위와 우리 비율 단위가 달라 차원이 맞지 않음. 페어링 형태만 재사용, 값은 독립 재설계 | +| 7 | Grade(1~2)별로 레벨 캡을 차등(예: Grade2는 20레벨까지) | 원작이 "6등급×2슬롯 12조합 전부 동일" M수열(캡 차등 없음, 매핑v1 §2-3)이라는 균일성 원칙을 갖고 있음 — 우리도 캡은 9종 전부 16으로 통일하고 Grade는 ItemBase·SecondaryBase 계수로만 차등 반영 | +| **8(신규, 최초안 v1 채택 후 감사로 폐기)** | 융합 시 강화 레벨을 결과물로 이관(`max(dst,src)`, 합산 아님) | plan-auditor 감사 결과 2개 결함 동시 발견: (a) `TryFuse()`가 3개만 소모하는데 이관 코드는 무조건 `EquipLevel.Remove(source)`를 실행해 **잔존 보유분의 레벨을 전소**시킴(C-2) (b) `EquipLevel`이 itemId 단위(보유량 무관 공유값)라 **저가 아이템을 올린 뒤 융합해 고가 아이템 레벨을 무상 취득**하는 비용 세탁 차익이 구조적으로 발생(M-7, item7→9 경로 22,992G). 두 결함이 서로 얽혀 있어 부분 수정 대신 방식 자체를 폐기하고 "차단+환급"(§7-3)으로 재설계 | +| 9(신규) | 성장식 최초안(`1+L²/128`, 후반가속 순수형) 그대로 채택 | plan-auditor M-6 감사 결과 원작 M수열이 실제로는 배수 관점에서 "초반 배증형"임을 재확인 — 최초안은 초반 체감이 거의 없어(L1→2 배율 ×1.008) 저레벨 투자를 사실상 무의미하게 만들었다. 종점(×3.0)을 유지한 채 선형항을 더한 `(L²+8L)/192`로 교체(§4-1) | + +--- + +## 13. 능력치 18종 중 장비(Layer③) 담당 정리 + +Layer③은 **18종 폐쇄 집합에 신규 항목을 추가하지 않는다** — P3-A(`SurvivalStatCatalog.cs`)가 이미 18종을 인게임 11+마스터리이관 1+가챠확정 4+마스터리신규 2로 완결했고(합 18, 메타v1 §2-1), 본 층은 그 집합 **밖**에서 작동한다. + +| Layer③ 기여 항목 | 18종 소속 여부 | 비고 | +|---|---|---| +| Attack, Hp(itemId별 레벨 반영분) | **아니오** — "18종 외" | `attack`(고정, 공격력2층 산물)과 같은 분류. `SurvivalMeta.TotalAttack()/TotalHp()`가 매판 시작 베이스로 직접 결합(§7-1), CSV 강화 트랙과 무관 | +| `equip_attack_speed_add` | **아니오** — 층 내부 파생 | 18종의 `attack_speed_add`(인게임)와 **이름만 유사한 별개 키**(R-A2 네임스페이스 가드, `equip_` 접두). `Promotion.PromoDefenseAddRatio`와 동일 분류(층 전용 파생 메커니즘) | +| `equip_defense_add` | **아니오** — 층 내부 파생 | 상동, 18종의 `defense_add`(인게임)와 별개 | + +**결론**: 18종 체계에 대한 P3-A의 "11+1+6=18" 완결 회계(메타v1 §2-1)는 본 문서로 인해 **변경되지 않는다**. 장비강화는 능력치의 "종류"를 늘리는 층이 아니라 이미 확정된 Attack/Hp(정액)에 "레벨"이라는 **깊이** 축을 더하고, 부수적으로 층 전용 파생 2종(공속·방어)을 얹는 구조다. + +--- + +## 14. 데이터 모델 + +### 14-1. `SurvivalMetaData` — 신규 필드 1종 추가 필요 (plan-auditor C-1 지적, 최초안 오판 정정) + +**최초안은 "신규 필드 불필요"로 단정했으나 이는 사실과 반대다.** `SurvivalMeta.cs` L11-34 직접 실측 결과 `SurvivalMetaData`의 현재 필드는 `Owned`·`Equipped`·`DailyPurchase`·`LastDailyReset`·`HeroLevel`·`PromotionStar`·`Version=2` **7개뿐**이며 `EquipLevel`은 **존재하지 않는다**. 메타v1 §5-1이 설계 문서상 이 필드를 선언했을 뿐, B1 구현(GodDem 커밋 `a3f62ab`)에는 반영되지 않았다 — 설계 문서의 선언을 코드 상태로 오인한 것(C39-10 위반 소지). + +```csharp +// SurvivalMetaData — 신규 필드 1개 + Version 상향 +public Dictionary EquipLevel = new(); // itemId → 강화레벨(0=미투자) +public int Version = 3; // 2→3 (Layer③ EquipLevel 추가) +``` + +**`Load()` 마이그레이션 추가**(기존 `_data.Owned ??= new Dictionary()` 패턴, `SurvivalMeta.cs` L115 그대로 복제): + +```csharp +_data.EquipLevel ??= new Dictionary(); +``` + +구버전(`Version<3`) 세이브 로드 시 `EquipLevel`이 `null`일 수 있으므로 이 초기화가 없으면 §7-1·§7-2·§7-3 전부 NRE 위험이 있다(B1 Minor1이 동일 유형 결함을 3중 방어로 해소한 선례 계승). + +### 14-2. `SurvivalItemDef` — 신규 필드 1개 + +```csharp +public class SurvivalItemDef +{ + // ...기존 필드(Id·Name·Slot·Grade·Attack·Hp·FuseTargetId) 불변... + public string SecondaryStatKey; // "equip_attack_speed_add" | "equip_defense_add" (§4-3) +} +``` + +9종 전체 `SecondaryStatKey` 값은 §5-2 표의 "분류" 컬럼과 1:1 대응(공격형→`equip_attack_speed_add`, 방어형→`equip_defense_add`). + +### 14-3. 신규 CSV — `SurvivalMetaEquipUpgrade.csv` (메타v1 §5-2 골격 기반, 부분 변형 — plan-auditor M-3 지적으로 "준수" 표기 철회) + +**메타v1 §5-2 원 스키마와의 차이(정정)**: 메타v1 §5-2는 `n_ItemId, n_Level, f_EquipAttackAdd, f_EquipHpAdd, s_SecondaryStatKey, f_SecondaryValue, l_Cost`(7열, `s_SecondaryStatKey`가 레벨별 행에 반복 저장)를 지정했다. 최초안은 이를 "스키마 준수"로 표기했으나 실제로는 **6열로 변형**했다 — `s_SecondaryStatKey`는 레벨마다 반복 저장할 필요가 없어(아이템당 고정값) `SurvivalItemDef.SecondaryStatKey`(§14-2)로 1회만 선언하고 CSV에서 제거, `f_EquipAttackAdd`/`f_EquipHpAdd`는 `f_AttackAdd`/`f_HpAdd`로 개명했다. 변경 자체는 합리적(17행 반복 대신 1회 선언)이나 이 이탈을 변경 이력(§15)에 기록하지 않은 것이 감사 지적 사항이었다 — 본 절부터 정정 반영. + +``` +n_ItemId,n_Level,f_AttackAdd,f_HpAdd,f_SecondaryValue,l_Cost +장비ID,강화레벨(해당 레벨에서의 레벨0 대비 누적 순증분),공격력증분,체력증분,2차스탯증분,강화비용(GOLD·L-1→L 1회분) +1,0,0,0,0,0 +1,1,0.281,0,0.000703,420 +...(공식 §4-1·§4-2·§4-4 적용, 9종×17행=153행, 3~152행 생략 — §5-3 체크포인트 참고) +9,16,20,240,0.06,8720 +``` + +**컬럼 의미(HeroLevelTable 관례 그대로 계승, plan-auditor m-1 지적으로 서술 정정)**: `f_AttackAdd`/`f_HpAdd`/`f_SecondaryValue`는 **레벨0 대비 누적 순증분**(그 레벨까지의 총 증가량, `SurvivalHeroLevelTable`의 "누적 총량·행 직접 룩업" 하우스 규약과 동일) — 런타임은 `SurvivalItemDef.Attack/Hp × (1+(L²+8L)/192) − 원본` 폐쇄형 계산과 CSV 실값이 반드시 일치해야 한다(QA 체크리스트 항목). `l_Cost`는 `Cost(item,L)`(누적 아님, L-1→L 1회 비용 — item1 L1=`ItemBase(300)+V(1)=300+120=420`, item9 L16=`ItemBase(2000)+V(16)=2000+6720=8720`, §5-1·§5-2 검산). `SurvivalEquipUpgradeTable`에는 추가로 `CumulativeCostAt(itemId,level)`(§7-3 환급 계산용 — 0~level까지 `l_Cost` 합산) 메서드가 필요하다. + +### 14-4. 코드 터치포인트 + +| 파일 | 변경 | +|---|---| +| `SurvivalMeta.cs`(`SurvivalMetaData`) | **신규 필드**(§14-1, plan-auditor C-1) — `Dictionary EquipLevel` + `Version` 2→3 + `Load()`에 `EquipLevel ??= new()` 마이그레이션 1줄 | +| `SurvivalItemCatalog.cs` | `SurvivalItemDef`에 `SecondaryStatKey` 필드 추가 + 9종 값 채움(§14-2) | +| `SurvivalMeta.cs` | `TotalAttack()`/`TotalHp()` CSV 룩업 반영 수정(§7-1) + `EquipAttackSpeedRatio()`/`EquipDefenseRatio()` 신규(§7-2) + `TryFuse()` 차단 조건 추가 + `ResetEquipLevelWithRefund()` 신규(§7-3, plan-auditor C-2·M-7 재설계) + `_equipUpgrades` 정적 캐시(`SurvivalEquipUpgradeTable.Load()`, HeroLevelTable/PromotionTable과 동일 지연로드 패턴) | +| `SurvivalBattleManager.cs` | `RecalcPlayer()` L224(spd)·L237(outgameRatio) 2곳 항 추가(§7-4). 호출부 3곳(`ApplyMetaEquipment`·`RefreshHeroStats`·`UpdatePropertyText`)은 **무변경** | +| 신규 파일 | `SurvivalEquipUpgradeTable.cs` — `SurvivalHeroLevelTable.Load()`의 CSV 파싱 패턴(헤더 2행 스킵) 복제, 키는 `(ItemId,Level)` 복합키(`Dictionary>`). `AttackAddAt`/`HpAddAt`/`SecondaryValueAt`(단일 레벨 값 룩업) + `CumulativeCostAt`(0~level `l_Cost` 합산, 환급 계산용) 4개 메서드 필요(plan-auditor M-2 CSV 룩업 전환 반영) | +| 아웃게임 UI | 장비 강화 패널(레벨업 버튼·비용 표시·2차 스탯 표시) + 강화 초기화(환급) 확인 다이얼로그(§7-3) — ux-designer·클라이언트팀 후속(§16) | + +--- + +## 15. 변경 이력 (P16) + +| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 | +|---|---|---|---|---|---| +| 2026-08-22 | balance-designer | 문서 신규 작성(v1 초안) | — | 초안 전체(Layer③ 레벨업 실수치·2차스탯·비용식·융합 이관·CSV 스키마) | PD 승인 "현 세션 B2 계속"+"원작처럼 맞춰" 집행, 메타v1 §1-3 유보사항 확정 | +| 2026-08-22 | balance-designer | 2차 스탯 값 도출 방식 결정 | 메타v1 원작 수식(attack/2·hp/4) 직접 재사용 가정 | 형태만 재사용, 값은 독립 재설계(등급×레벨 곡선) | 단위 불일치 발견, C5 투명 고지 | +| 2026-08-22 | balance-designer | 융합↔강화 상호작용 최초 결정 | 메타v1 "기본 권고"(융합 차단) | 레벨 이관(max, 합산 아님) — **이후 감사로 폐기, 아래 참조** | 투자 손실·소프트락 회피 목적 | +| 2026-08-22 | plan-auditor | 모드A 감사 수행 | — | 조건부통과(Critical 2·Major 7·Minor 5, 산술 전량 무오류) | C35 사전 교차검증 | +| 2026-08-22 | balance-designer | `SurvivalMetaData.EquipLevel` 필드 상태 정정 | "메타v1 §5-1 기예약, 신규 필드 불필요"(오판) | "실측 결과 미구현 — 신규 필드 1종 추가 필요"(§14-1) | plan-auditor C-1 지적 — 설계문서 선언을 코드 상태로 오인(C39-10) | +| 2026-08-22 | balance-designer | 융합↔강화 상호작용 재설계 | 레벨 이관(max) | **차단 + 50% 환급 후 재투자**(§7-3) | plan-auditor C-2(잔여 보유분 레벨 전소 버그)·M-7(비용 세탁 차익) 동시 발견 — 이관 방식 폐기(기각안8) | +| 2026-08-22 | balance-designer | 층 규모 판정 바스켓 정정 | 9종 전체 만렙 510,496G(48%) | 실투자 6종 만렙 359,728G(**34.1%**, §6-2) | plan-auditor M-1 — 재료 아이템(1·4·7) 만렙은 비합리적 목표라 바스켓에서 제외 | +| 2026-08-22 | balance-designer | 런타임 구현 방식 전환 | 폐쇄형 하드코딩(`1+lv*lv/128f` 등) + 별도 CSV 153행(이중 SOT) | CSV 룩업(`SurvivalEquipUpgradeTable`, B1 패턴 정합, §7) | plan-auditor M-2 — 3중 SOT 재발 패턴(`SurvivalMeta.cs` 자체 경고) | +| 2026-08-22 | balance-designer | 성장식 교체 | `Base×(1+L²/128)`(후반가속 순수형) | `Base×(1+(L²+8L)/192)`(전반부 체감 확보, 종점 ×3.0 불변) | plan-auditor M-6 — 원작 M수열이 실제로는 초반 배증형임을 재확인, 최초안은 반대 형태였음(기각안9) | +| 2026-08-22 | balance-designer | 2차 스탯 기각 근거 교체 | 매핑v1 §2-7(1e21~1e50 파워단위) 인용 | `SurvivalBattleManager.cs` L224-225 실측(비율 vs 정액 단위 충돌) 인용 | plan-auditor M-4 — §2-7은 heroequipment와 무관한 테이블 오귀속(C44) | +| 2026-08-22 | balance-designer | CSV 스키마 표기 정정 | "메타v1 §5-2 스키마 준수" | "메타v1 §5-2 골격 기반, 6열로 부분 변형"(§14-3) | plan-auditor M-3 — 실제로는 `s_SecondaryStatKey` 제거·2개 컬럼 개명이 있었으나 변경이력 미기재 | +| 2026-08-22 | balance-designer | §0 반전 고지 블록 신설 | 없음 | M수열 재추출 선행조건 해제에 대한 C36 경계 고지 | plan-auditor M-5 — B1이 확립한 반전고지 절차를 최초안이 생략 | + +--- + +## 16. 후속 조치 (본 문서 범위 밖) + +1. **개발팀 구현 선행 필수(팀장급 확인 후)**: §14-1 `SurvivalMetaData.EquipLevel` 필드 신설(Version 3) + §7 `TotalAttack()`/`TotalHp()` CSV 룩업 수정 + `EquipAttackSpeedRatio()`/`EquipDefenseRatio()` 신규 + `TryFuse()` 차단조건 + `ResetEquipLevelWithRefund()` 신규 + `RecalcPlayer()` 2개 항 추가 + `SurvivalEquipUpgradeTable.cs` 신규(CumulativeCostAt 포함) + CSV 153행 생성. +2. **개발팀장 재추출(차단 조건 아님, forging 실채택 대비)**: `heroequipment.csv`·`heroequipmentupgrade.csv`·`heroequipmentforging.csv` 원본(§2-2 우선순위 중). +3. **UI 신규 필요(ux-designer·클라이언트팀 협의)**: 장비 강화 패널(레벨업 버튼·비용·2차 스탯·만렙 표기) + 강화 초기화(환급) 확인 다이얼로그(§7-3) — B1 §14 "아웃게임 UI 시각 레이아웃 미검증" 후속과 동일 계열. +4. **기획팀장·PM 인지 필요(C36 경계, §0 반전 고지)**: M수열 재추출 선행조건을 본 문서가 해제한 판단(§2)의 타당성 재확인. +5. **system-designer·PD 인지 필요(방향성 질문, §6-4·R-D8)**: 장비강화가 HeroLevel과 상시 병행 가능한 층이어야 하는지, 중반 이후 투자처로 의도해도 되는지. +6. **content-designer 인지 필요**: 향후 신규 아이템(가챠 B3 등) 추가 시 `SecondaryStatKey`는 슬롯이 아니라 주스탯 우세 기준으로 판정(§4-3·R-D6). +7. **PM 공유**: 본 문서 산출 완료(plan-auditor 조건부통과 반영 최종본)를 `개발팀_PD_지시_로그.md`(BT13-GodDem 단일 관리) 및 대화로그(`공유/대화로그/GodDem/2026-08-22.md`) 반영. +8. **기획팀장 C49 검증 재상정**: plan-auditor가 정정 완료 산출물의 기획팀장 3단계 검증(C49) 재상정을 권고함. diff --git a/공유/대화로그/GodDem/2026-08-22.md b/공유/대화로그/GodDem/2026-08-22.md index 7f736cd..034653d 100644 --- a/공유/대화로그/GodDem/2026-08-22.md +++ b/공유/대화로그/GodDem/2026-08-22.md @@ -210,3 +210,25 @@ - **★ PD 직접 지적**: "내가 별도 판단 후 지시하기 전까지 자꾸 세션 이동을 되묻지 마!" — PM이 마일스톤마다 세션 정리/전환 3~4회 반복 제안(PD 매번 "이대로 진행"). C47·`feedback_pm_excessive_decision_request` 위반. **세션 실측 3MB 건강(근거도 약함)**. → memory `feedback_session_transition_repeated_prompting` 신설. **세션 이동 재제안 중단** — PD 별도 지시 전까지 세션 계속·session_health 임계 실도달 시에만 1회 고지 - **B2 착수**: balance-designer 장비강화 Layer③ 설계 (진행중) — 원작 heroequipment(장비·upgrade·forging·reforging) 정합·M수열 재추출 표시·현 SurvivalItemCatalog(6부위 임시) 원작 재설계·능력치 담당·매판 베이스 결합. 산출 예정 `2026-08-22_P3B2_장비강화_설계_v1.md` - **후속 체인**: B2 설계 → plan-auditor 검증 → 개발팀장 재추출+구현 → B4(스킬)→B3(가챠)+C(스테이지) + +## 36. P3-B2 장비강화 설계 — 완료 + plan-auditor 조건부통과 반영 (balance-designer, GodDem 수정 0건) + +- **산출물**: `공유/기획/GodDem/2026-08-22_P3B2_장비강화_설계_v1.md`. Layer③ 레벨업 축(EquipLevel, itemId별 0~16)·2차 스탯(공속/방어)·비용식·융합 상호작용 전량 확정. 등급업(forging)·재련(reforging)은 C50 경계로 골격만. +- **핵심 결정 5건**: ①M수열(매핑v1 §2-3) 원본 재추출 없이 "형태만"(가속형 2차) 재사용 채택 — 절대치는 원작 12진영×150레벨 스케일이라 그대로 대입 불가(B1·공격력2층 선례 계승) ②2차 스탯(원작 attack_speed=attack/2·defense=hp/4) 직접 재사용 기각 — `SurvivalBattleManager.cs` L224-225 실측 결과 우리 게임은 비율(ratio)·정액(flat) 단위가 분리돼 있어 "÷2"를 그대로 쓰면 차원 불일치(+700% 공속) 발생, 등급 기반 독립 곡선으로 재설계 ③융합(TryFuse)↔강화분 상호작용 = 차단 + 50% 환급 후 재투자로 확정 ④forging·reforging 미채택(골격만) ⑤강화 대상은 9종 정의하되 실질 투자는 슬롯당 최상위 6종(재료 3종 제외). +- **수치 골격**: 성장식 `Base×(1+(L²+8L)/192)`(만렙 ×3.0)·비용식 `ItemBase(PowerScore×50)+20L²+100L`(원작 "Base+V 완전가산" 형태). 실투자 6종 만렙 총비용 359,728G — B1(HeroLevel+Promotion, 1,056,056G) 대비 34.1%. +- **plan-auditor 모드A 감사**: **조건부통과**(Critical 2·Major 7·Minor 5, 산술 자체는 90여 개 값 독립 재계산 결과 전량 무오류). 전부 반영해 v1 최종본으로 정정 완료: + - **Critical 2**: (a) `SurvivalMetaData.EquipLevel` 필드가 실제로는 미구현(설계문서 선언을 코드 상태로 오인, C39-10 위반 소지) → §14 신규 필드로 정정 (b) 최초 설계(융합 시 레벨 "이관", max 방식)가 잔여 보유분 레벨을 전소시키는 데이터소실 버그를 유발 → 차단+환급 재설계로 대체 + - **Major 7**: 이관 방식이 동시에 비용 세탁 차익(item7→9 경로 22,992G)도 허용하던 결함(M-7, C-2와 함께 재설계로 해소) · 층 규모 판정 바스켓 오류(9종 전체 510,496G vs 실투자 6종 359,728G 혼용, M-1) · 폐쇄형 하드코딩+CSV 153행 이중 SOT(M-2, CSV 룩업 방식으로 전환해 B1 패턴 정합) · 메타v1 §5-2 스키마 "준수" 오표기(M-3) · 2차스탯 기각 근거 오귀속 — 매핑v1 §2-7은 heroequipment와 무관한 테이블이었음(M-4, 자체 코드 실측 근거로 교체) · 메타v1 명시 선행조건(M수열 재추출) 해제 시 B1이 확립한 반전고지 절차 생략(M-5, §0에 고지 블록 신설) · 성장식이 원작 M수열의 실제 형태(초반 배증형)와 반대(후반 가속형)였음(M-6, 만렙 종점 불변하며 전반부 체감 확보형으로 개정) + - **Minor 5건**: CSV 컬럼 설명 오배치·반올림 규약 미명시·용어 충돌(TotalAttack 이름 중복)·재련 확인도 표기 오류·인용 출처 오류 — 전부 반영 +- **기각안(C32 필수 필드, 최초 채택 후 감사로 폐기된 안 포함)**: ①슬롯 단위 강화(메타v1 기존 확정 방향, 재논의 대상 아님) ②공격형/방어형 2슬롯 균등 분배(우리 아이템 실제 스탯 조성 무시하게 됨) ③강화분>0 아이템 융합 조건 없는 영구 차단(에스케이프 밸브 없이, 초반 실수투자 소프트락 유발) ④forging 즉시 채택(C50 경계, 가챠 정책 정합 필요) ⑤원작 M수열·Base비용 절대값 그대로 대입(스케일 불일치) ⑥원작 attack/2·hp/4 수식 문자 그대로 적용(단위 불일치) ⑦Grade별 레벨캡 차등(원작 12조합 균일성 원칙 위반) ⑧**융합 레벨 이관(max, 합산 아님)** — 최초 v1 채택안이었으나 plan-auditor가 데이터소실+비용세탁 결함을 발견해 폐기, "차단+환급"으로 재설계 ⑨**성장식 최초안(`1+L²/128`, 후반가속 순수형)** — plan-auditor가 원작 M수열의 실제 형태(초반 배증)와 반대임을 지적, `(L²+8L)/192`로 교체. +- **PD·기획팀장 인지 필요(C36 경계, 방향성 질문)**: ①M수열 재추출 선행조건 해제 판단이 메타v1 명시 방향과 다름 — §0 반전고지 블록 신설, 재확인 필요 ②장비강화가 HeroLevel 20대 중반 이후에나 효율적으로 진입되는 구조(§6-4) — "층은 항상 병행 가능해야 하는가, 중반 이후 투자처로 의도해도 되는가"는 미확정 방향성 질문. +- **후속**: 개발팀장 구현(EquipLevel 필드·CSV 룩업 코드·TryFuse 차단+환급·RecalcPlayer 2항) + heroequipment/upgrade/forging 원본 재추출(forging 실채택 대비, 차단조건 아님) + UI 신규(ux-designer) + 기획팀장 C49 검증 재상정. +- **기록 비고**: PD 지시 로그(`개발팀_PD_지시_로그.md`) 갱신 시도 — C35-9 매니페스트 게이트 차단(pm-auditor 사전 감사 미등록). 팀장급/PM이 매니페스트 등록 후 PD 지시 로그 갱신 필요(C29-4 "PD 지시 로그 상태 갱신은 팀장 책임" 원칙에 따라 이관), 본 대화로그 §36으로 우선 공유 완료. + +## 37. B2 재산정 결정 — 원작 heroequipment 재추출 착수 (PM, 2026-08-22) + +- **B2 v1 = plan-auditor 모드A 조건부통과** (Critical 2·Major 7·Minor 5 반영·산술 90여값 무오류). 2축(레벨업 EquipLevel 0~16·등급업 forging)·SecondaryStatKey 2종·매판 베이스 결합·데이터모델(EquipLevel Version3·SurvivalMetaEquipUpgrade.csv). Critical: EquipLevel 미구현 혼동·융합 레벨이관 버그(비용 세탁 차익)→차단+50%환급 재설계 +- **★ 핵심 판단 — 원작 정합 위해 재추출 진행**: B2 v1이 **원작 heroequipment M수열을 재추출 없이 형태만 재사용·절대치 역산**(재추출v1도 heroequipment 미포함·매핑 §2-3 ⚠️ 미해소). **PD "우선 원작처럼 맞춰 전체 밸런싱 동일성"에 배치** — 공격력 배율 재추출로 원작 정합 확정한 선례(§16 PD "재추출로 전체 원작 정합")와 동일 패턴. **PD 세션 되묻기 지적 정합 — 밸런스 방향은 PD "원작처럼"이 명확하므로 되묻지 않고 재추출 진행**(C47) +- **착수**: 개발팀장 heroequipment 재추출 (heroequipment/upgrade/forging/reforging M수열·비용·rate 원본, 진행중). 산출 예정 `2026-08-22_원작장비_재추출_원본_v1.md` + - **후속 체인**: 재추출 원본 → balance-designer B2 v2 재산정(원작 절대치) → plan-auditor 검증 → 개발팀장 구현 +- **추후 PD 밸런싱 확인 영역(지금 안 물음)**: 장비강화가 HeroLevel 20대 중반 이후 효율 진입하는 구조 의도 여부 — PD "전체 밸런싱 원작 맞춤 후 확인·추후 변경" 범위, 플레이테스트 시점