docs(BT13-GodDem): ele 영웅등급 축 설계 v2·구현 3fbc8b1·사후감사 정정 — PD 확정 HeroGrade=4
- PD 확정: 영웅 등급별 계열 구조(§98)·시작 영웅 HeroGrade=4(최저) - 설계 v2(plan-auditor 조건부 통과·Critical 3 정정 반영)·구현 GodDem 3fbc8b1 push(CSV 22행·HG5 미수록·컴파일 에러 0) - 사후감사: Critical 오판 정정(PD 승인 §98 L413 실재·유효잔여=성문화 미집행)·Major 3 수용(실세이브 투자 0 실측·Node1 HG≠4 함정·좌초 400,290G 상한/실 0G) - 노하우 2종: 승인완료·성문화미집행 / 검증산출물 조직 미보존 - C35 게이트 개정 성문화 착수(pm-auditor 사전 감사 발주) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
c65fdedbf0
commit
dffe0b6750
|
|
@ -0,0 +1,22 @@
|
||||||
|
---
|
||||||
|
name: approved-rule-not-yet-enacted
|
||||||
|
description: PD 승인은 받았으나 SKILL 본문 성문화(C37) 전인 규칙 개정을 "적용"으로 표기해 시행 규칙처럼 원용 — 동시에 감사관은 제안 시점 기재만 읽고 승인 기재를 놓쳐 "미승인"으로 오판 (2026-08-24 C35 게이트 개정 실증·양방향 교훈)
|
||||||
|
type: feedback
|
||||||
|
---
|
||||||
|
|
||||||
|
# 승인 완료·성문화 미집행 — 규칙 개정의 공백 구간 (2026-08-24 BT13)
|
||||||
|
|
||||||
|
## 실증
|
||||||
|
|
||||||
|
C35 감사 게이트 개정(구현 커밋 사전 게이트를 설계 감사 통과로 갈음)을 PD가 2026-08-23 AskUserQuestion에서 "개정 승인"으로 확정(대화로그 `2026-08-23.md` §98 L413). 그러나 SKILL 본문 개정(C37 3중 전파)이 미집행인 상태에서 조직이 이를 "개정 게이트 적용"으로 표기해 운용했다. 사후 감사는 이를 **C36-2 위반 Critical("미승인 제안을 시행 규칙으로 원용")**으로 판정했는데, 그 근거는 같은 로그의 **L401(제안 시점 기재)만 읽고 L413(승인 기재)을 확인하지 않은 것** — 승인은 실재했다. 정확한 분류는 **"승인 완료·성문화 미집행"**이며, PM이 즉시 C37 개정 절차(pm-auditor 사전 감사 → SKILL·CLAUDE·아카이브 3중 전파)를 착수해 공백을 닫았다.
|
||||||
|
|
||||||
|
## Why
|
||||||
|
|
||||||
|
규칙 개정에는 **승인 시점과 발효 시점 사이 공백**이 존재한다(C37 절차가 남아 있으므로). 이 구간에서 "승인됐으니 적용"이라 표기하면 SOT(SKILL 본문)와 운용이 어긋나고, 다음 독자·감사관은 SOT를 근거로 위반 판정을 내리게 된다. 반대로 감사관은 로그의 한 지점만 보면 승인 사실을 놓친다 — 규칙 상태는 제안·승인·성문화 3단이며 **한 줄이 아니라 이력 전체를 읽어야** 확정된다.
|
||||||
|
|
||||||
|
## How to apply
|
||||||
|
|
||||||
|
1. **PM**: PD 승인 즉시 C37 성문화를 집행하거나, 공백 구간에는 **"PD 승인 완료·성문화 대기(SOT 미반영)"**로 표기한다 — "적용"·"개정 게이트상"처럼 발효를 단정하는 표현 금지. 운용은 승인에 근거해 진행하되 표기로 상태를 정확히 남긴다.
|
||||||
|
2. **감사관**: 규칙 근거 판정 전 **해당 안건의 로그 이력 전체를 스캔**(제안→승인→집행)하고, 승인 기재를 못 찾았을 때만 "미승인"으로 판정한다. 제안 시점 문장은 그 시점 사실일 뿐 현재 상태가 아니다.
|
||||||
|
3. 규칙 개정 안건은 승인 즉시 **성문화 작업을 별건 등재**해 공백이 세션을 넘지 않게 한다.
|
||||||
|
4. 관련: C36 · C37 · C1(지시=승인) · [[feedback_subagent_hallucinated_audit_verdict]](감사 주장 검증) · [[feedback_gitignore_backup_audit_blindspot]](감사 오판 시 성급 귀책 금지 — 본 건도 팀원 귀책 아님)
|
||||||
|
|
@ -0,0 +1,22 @@
|
||||||
|
---
|
||||||
|
name: verification-artifact-not-organizationally-preserved
|
||||||
|
description: 검증 근거 산출물을 gitignore 대상 경로·확장자로 저장하고 "보존 완료"로 보고 — 로컬 단일 PC 잔류를 조직 보존으로 과장해 차기 감사관 재현 불가·"미검증 태그" 문제가 형태만 바꿔 재발 (2026-08-23 컴파일 로그 표준 첫 적용분·pm-auditor 등재 요청)
|
||||||
|
type: feedback
|
||||||
|
---
|
||||||
|
|
||||||
|
# 검증 산출물의 조직 미보존 — 파일 존재 ≠ 조직 보존 (2026-08-23 BT13)
|
||||||
|
|
||||||
|
## 실증
|
||||||
|
|
||||||
|
Ring 커밋 감사가 "Roslyn 검증 산출물 미보존 → 미검증 태그"를 부여해 §93 ⑤로 "컴파일 로그 파일 보존"을 조직 표준으로 채택했다. **첫 적용분**(per-node MaxGrade 커밋·`공유/개발팀_백업/GodDem/compile_*.bak_*.log`)이 `.gitignore:78 *.log`에 걸려 **미추적 = 미커밋 = 조직 미공유 = PC 변경 시 소실**. 차기 감사관이 기준선 로그 부재로 "경고 집합 diff 공집합" 주장을 재현하지 못함 — 표준이 없애려던 문제가 형태만 바꿔 재발. 부수: `.bak_` 명명은 원본 보호 백업 표준의 오용(로그는 원본 없는 신규 산출물)·`*.bak_*` 스캔 거짓 항목 유발.
|
||||||
|
|
||||||
|
## Why
|
||||||
|
|
||||||
|
"보존"을 파일 시스템 존재로 정의한 것이 오류 — 헌법 ⑤(세션·PC 변경 시 연속성) 기준의 보존은 **git 추적·main push**다(C18). gitignore 정책(*.log·*.bak_*)은 의도된 것이므로, 표준 설계 시점에 `git check-ignore` 대조를 안 한 것이 근본 원인. §93 ⑤ 표준 자체가 proxy였다(C2-2).
|
||||||
|
|
||||||
|
## How to apply
|
||||||
|
|
||||||
|
1. **검증 근거는 git 추적 텍스트에 요지를 인용**해야 보존이다 — 컴파일 경고 목록·검산 수치·diff 요약을 대화로그/설계 문서에 직접 기재(파일은 로컬 편의 보조로만).
|
||||||
|
2. 어떤 산출물이든 "보존 완료" 주장 전 **`git check-ignore -v <경로>` 실측 의무** — ignore 매칭 시 그 주장은 "로컬 잔류"로 강등.
|
||||||
|
3. 신규 조직 표준 채택 시 첫 적용분을 감사로 재현 검증 — 표준이 목적을 실제 달성하는지 확인 후 고정.
|
||||||
|
4. 관련: 헌법 ⑤ · C5 · C18 · C23 · C2-2 · [[feedback_subagent_hallucinated_audit_verdict]](검증 재현성 계열)
|
||||||
|
|
@ -1,5 +1,7 @@
|
||||||
# GodDem ele 2종(Node2·3) 원작 정합 재설계 v1
|
# GodDem ele 2종(Node2·3) 원작 정합 재설계 v1
|
||||||
|
|
||||||
|
> ⚠️ **역사 보존 — 최신 SOT 아님(2026-08-23)**: PD 직접 지시(대화로그 §98, "영웅 등급별로 맞춰")로 본 문서의 핵심 전제("히어로 1명이라 대표 계열 1개 고정")가 폐기됐다. **`2026-08-23_B4ele_원작정합_재설계_v2.md`가 최신 SOT** — 원작 실측치(계열93/94/95·73/74/75)·D(grade) 비용 방법론·per-node MaxGrade 인프라(`102e662`)는 v2가 그대로 승계했으나, "대표 계열 택1" 구조 자체는 "영웅 등급 차원 보유 + 현재 히어로 HeroGrade=4 고정 배정"으로 대체됐다.
|
||||||
|
|
||||||
> **작성**: balance-designer(기획팀) 2026-08-23 · **P3-B4 후속 보정 산출물**(B4 v1 병존 — `2026-08-22_P3B4_스킬마스터리_설계_v1.md`는 무변경 유지, 본 문서가 Node2·3 값·per-node MaxGrade 스펙의 최신 SOT)
|
> **작성**: balance-designer(기획팀) 2026-08-23 · **P3-B4 후속 보정 산출물**(B4 v1 병존 — `2026-08-22_P3B4_스킬마스터리_설계_v1.md`는 무변경 유지, 본 문서가 Node2·3 값·per-node MaxGrade 스펙의 최신 SOT)
|
||||||
> **위임 경로**: PD §85 ④ "백로그도 자율적으로 판단해 우선 네가 먼저 진행해" → 개발팀장 재추출(대화로그 §87·§88) → PM 위임(본 문서 착수 근거)
|
> **위임 경로**: PD §85 ④ "백로그도 자율적으로 판단해 우선 네가 먼저 진행해" → 개발팀장 재추출(대화로그 §87·§88) → PM 위임(본 문서 착수 근거)
|
||||||
> **PD 원문 인용 불가(C42-2 A 예외 고지)**: 본 건은 PD가 ele 수치 자체를 직접 지시한 적 없다 — PD는 "백로그 자율 위임"만 승인했고, 개발팀장이 자체 재추출로 원작 불일치를 **발견**했다. 따라서 본 문서의 결정 사항(계열 선택 등)은 PD 확인 목록(§8)에 정식 상신하며, 지금 이 설계 자체는 designer 재량(P23 "핵심 밸런싱 방향 전환" 영역이므로 안 자체는 완성하되 최종 채택은 PD 확인) 범위에서 완결한다.
|
> **PD 원문 인용 불가(C42-2 A 예외 고지)**: 본 건은 PD가 ele 수치 자체를 직접 지시한 적 없다 — PD는 "백로그 자율 위임"만 승인했고, 개발팀장이 자체 재추출로 원작 불일치를 **발견**했다. 따라서 본 문서의 결정 사항(계열 선택 등)은 PD 확인 목록(§8)에 정식 상신하며, 지금 이 설계 자체는 designer 재량(P23 "핵심 밸런싱 방향 전환" 영역이므로 안 자체는 완성하되 최종 채택은 PD 확인) 범위에서 완결한다.
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,370 @@
|
||||||
|
# GodDem ele 2종(Node2·3) 원작 정합 재설계 v2 — 영웅 등급 차원 구조 피벗
|
||||||
|
|
||||||
|
> **작성**: balance-designer(기획팀) 2026-08-23 · **P3-B4 후속 보정 산출물**(v1 병존, GodDem 레포 수정 0건)
|
||||||
|
> ⚠️ **v1은 역사 보존 — 최신 SOT 아님**: `2026-08-23_B4ele_원작정합_재설계_v1.md`(대표 계열 1개 고정 채택안, plan-auditor 조건부통과·보강 5건 완료)는 PD가 그 전제 자체를 폐기하며 대체됐다. v1의 원작 실측치(계열93/94/95·73/74/75)·D(grade) 비용 방법론·per-node MaxGrade 인프라(`102e662`)·층간 교차표 원칙은 **전부 유효 승계**, 대표 계열 "택1" 구조만 폐기.
|
||||||
|
> **PD 원문 (2026-08-23, 대화로그 §98, C42-2 A)**: "지금은 초기 버전이라 영웅이 1명이지만 **추후에는 영웅을 늘릴 예정**이므로 **원작과 동일하게 영웅 등급 별로 맞춰**"
|
||||||
|
> **PD 의도 분석(C42-2 B)**: v1의 4안 비교("어느 계열을 대표로 고정할까")는 질문 자체가 잘못됐다 — PD는 택일이 아니라 **로드맵 정보 공개 + 구조 지시**를 한 것이다. "영웅을 늘릴 예정"이라는 사실이 "GodDem은 히어로 1명이라 대표값이 필요하다"는 v1의 핵심 전제(§1-2)를 무효화한다. 원작이 실제로 가진 "영웅 등급별 계열 게이팅" 데이터 구조를 GodDem도 그대로 보유해야, 다음 히어로 추가 시 재설계 없이 그 히어로의 등급만 지정하면 된다.
|
||||||
|
> **표기 규칙(C5·C44)**: 🟢확정(원작 실측 또는 코드 직접 확인) · 🟡추정 · 🔴PD 확인 필요
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. 결론 요약
|
||||||
|
|
||||||
|
| 결정 항목 | 채택 | 핵심 근거 |
|
||||||
|
|---|---|---|
|
||||||
|
| **데이터 구조** | CSV에 **`n_HeroGrade`(4/5/6) 컬럼 신설** — 원작 3개 계열(93·94·95 / 73·74·75) 전체가 설계 근거상 24행(원작 발자국)이나, **CSV 실수록은 16행**(HeroGrade5 8행은 재추출 전까지 미수록, §1-2 M-2·m-1 정정). 테이블 3차원화(NodeId×HeroGrade×MasteryGrade) | 원작 `heroskillattr`가 실제로 갖는 (계열×quality) 2차원 구조를 그대로 보존 — 다음 히어로 추가 시 테이블 재작업 0건. 미확정 추정치는 데이터 파일에 박지 않는다(C5) |
|
||||||
|
| **현 히어로 등급 배정** | **HeroGrade=4(최저 등급) 고정 배정** — 신규 `SurvivalMetaData.HeroGrade` 필드, 기본값 4 | (a) B1 승급(star) 매핑은 **원작 실측으로 기각**(아래 §2) — (b) 신규 필드 고정 배정 채택. "시작 히어로 = 최저 등급"은 F2P 장르 관행 + 향후 히어로 확장의 최대 헤드룸 확보 |
|
||||||
|
| **Node1(penetrate_ratio) 편입** | **보류(스키마는 호환, 값 변경은 Q2 답변 후)** | PD Q2("관통 적용 방식·계열 상향 의미" 설명 요청)가 별도 트랙으로 진행 중 — 본 문서가 선제 결정하면 C36(PD 결정 영역 선점) 소지 |
|
||||||
|
| **경제·승산항(현 활성 HeroGrade=4 기준)** | 3노드 합계 **126,390G**(v1 §6 "93/73" 행과 동일치 재사용) · 승산항 0.30 · 결합 상한 **1.60**(구 1.72 대비 -7.0%) | HeroGrade5·6은 설계 근거상 테이블에 존재(6은 CSV 수록·5는 재추출 대기)하나 현재 비활성(다음 히어로 또는 향후 등급승급 메커니즘 도입 전까지 미접근) |
|
||||||
|
| **★ N-1 전제 재이동(v1과 반대 방향, PD 인지 필요)** | 가챠/비가챠예산 배율 **1.7배→2.08배로 악화**(v1의 95/75안은 1.23배로 완화 예상이었으나, 원작 정합 재검증 결과 반대 결론) | §5-2 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. 데이터 구조 재설계
|
||||||
|
|
||||||
|
### 1-1. 원작 구조 재확인 — 왜 "대표 계열 고정"이 틀렸는가(C39, 재검증)
|
||||||
|
|
||||||
|
v1은 개발팀장 §87 실측(계열93/94/95·73/74/75, 3개 병렬 계열)을 "어차피 GodDem은 히어로 1명이니 그중 하나만 고르면 된다"고 처리했다. 이번 피벗을 계기로 원작의 인접 시스템(`hero_star.csv`, B1이 이미 이식한 승급 체계)을 **직접 재대조**한 결과, 이 처리가 구조적으로 틀렸다는 강한 증거를 찾았다(C44 — PM 위임 시점에 없던 신규 근거):
|
||||||
|
|
||||||
|
> **B1 v1 §4-1 원문 인용(본 세션이 작성한 기존 문서, 2026-08-22)**: "원작 `hero_star.csv`(186행=6등급×31성)의 진짜 기능은 % 보너스가 아니라 레벨 캡 게이팅... **GodDem은 히어로가 1명뿐이라 원작의 "quality"(진영별 희귀도 1~6) 축이 성립하지 않는다**"
|
||||||
|
|
||||||
|
즉 원작은 **모든 시스템에서 일관되게 "히어로 등급/quality = 어느 히어로(진영)를 보유했는가에 따라 고정되는 축", "star/학습레벨 = 그 히어로에 투자해서 늘리는 축"**이라는 두 축을 분리해 왔다(`hero_star`의 quality vs star, `heroskillattr`의 계열 vs quality-내부-학습레벨). 🟡 이 패턴이 `heroskillattr`의 ele 슬라이스(93/94/95·73/74/75)에도 동일하게 적용된다고 보는 것이 **가장 근거 있는 해석**이나, `heroskillattr` 자체에서 "계열=고정 식별자"라고 직접 명시한 원문 문구를 확보한 것은 아니다(추론, 미확정 태그) — "계열"(hero grade)은 **어느 히어로를 보유했는지에 따라 고정**되지, 한 히어로가 투자로 "성장해서" 올라가는 축이 아니다.
|
||||||
|
|
||||||
|
**결론**: v1처럼 "대표 계열 1개만 남기고 나머지 버리기"는 원작이 실제로 갖고 있던 **히어로별 고정 계열**이라는 구조 자체를 소거하는 것이었다 — PD가 "영웅 등급별로 맞춰"라고 한 것은 정확히 이 구조를 되살리라는 지시다.
|
||||||
|
|
||||||
|
### 1-2. CSV 스키마 재설계
|
||||||
|
|
||||||
|
**컬럼 추가**: `n_NodeId,s_StatKey,n_HeroGrade,n_Grade,f_Value,l_Cost` (기존 대비 `n_HeroGrade` 1열 삽입, `n_Grade`는 기존과 동일하게 **마스터리 강화 단계**를 의미 — 이름 충돌 방지를 위해 이하 "HeroGrade"(영웅 등급)와 "MasteryGrade"(강화 단계)로 구분 표기).
|
||||||
|
|
||||||
|
**"등급 컬럼 추가" vs "계열별 파일 분리" 비교**: 후자(예: `SurvivalMetaSkillMastery_Grade4.csv`/`_Grade5.csv`/`_Grade6.csv` 3파일 분리)는 기각 — 로더가 3배로 늘고(`Load()` 3회 호출·경로 3종 관리), 향후 히어로 5번째 등급이 추가되면 파일 자체를 새로 만들어야 한다. **컬럼 추가안은 로더 1개·파일 1개 유지, 행만 늘어난다**(3중 SOT 방지 원칙 계승).
|
||||||
|
|
||||||
|
**원작 전체 데이터 발자국은 24행**(v1의 12행에서 2배, Node1 3노드 중 Node2·3만 해당)이나, **CSV 실수록분은 16행**이다 — HeroGrade5(계열94/74) 8행은 아래 M-2·m-1 정정에 따라 재추출 전까지 CSV에서 제외한다:
|
||||||
|
|
||||||
|
| NodeId | HeroGrade | 원작 계열(참고) | MasteryGrade 범위 | 행 수 | CSV 수록 |
|
||||||
|
|---|---|---|---|---|---|
|
||||||
|
| 2(ele_hurt_add) | 4 | 계열93 | 1~3 | 3 | 🟢 수록 |
|
||||||
|
| 2 | 5 | 계열94 | 1~4 | 4 | 🔴 **미수록**(§1-2 M-2·m-1 정정) |
|
||||||
|
| 2 | 6 | 계열95 | 1~5 | 5 | 🟢 수록 |
|
||||||
|
| 3(ele_penetrate_ratio) | 4 | 계열73 | 1~3 | 3 | 🟢 수록 |
|
||||||
|
| 3 | 5 | 계열74 | 1~4 | 4 | 🔴 **미수록**(§1-2 M-2·m-1 정정) |
|
||||||
|
| 3 | 6 | 계열75 | 1~5 | 5 | 🟢 수록 |
|
||||||
|
|
||||||
|
**★ M-2·m-1 정정(plan-auditor 반영) — HeroGrade5(계열94/74) 8행은 재추출 전까지 CSV에서 제외**: §4-1·4-2가 보이듯 계열94/74의 개별 스텝값은 §87 실측 원문이 범위("0.06~0.24"·"0.04~0.16")만 제공했을 뿐 개별 스텝 4개를 확정하지 않아 **선형 외삽(🟡 추정)**이다. 다음 두 처리안 중 **(가) CSV 미수록**을 채택한다:
|
||||||
|
- **(가) 채택 — 재추출 전까지 CSV에서 완전 제외**(4·6등급 16행만 수록): 추정치가 실제 데이터 파일에 박히면 이후 이 CSV만 보는 사람(개발팀장·차기 세션)이 실측으로 오인할 위험이 있다 — "원작 실측만 CSV에 수록한다"는 원칙(Node1이 이미 §5-1에서 지켜온 관행과 동일)을 지킨다. 현재 HeroGrade4만 활성(§2)이라 게임 동작에도 영향이 없다.
|
||||||
|
- (나) 기각 — 🟡 표기 행으로 CSV에 유지: `l_Cost`/`f_Value` 컬럼에는 애초에 확정/추정 태그를 실을 여지가 없어(순수 수치 컬럼) CSV 자체로는 "이 행이 추정"이라는 사실을 전달할 방법이 없다 — 결국 (가)와 달리 오인 위험을 CSV 파일 스스로 해소하지 못한다.
|
||||||
|
|
||||||
|
**교차검증(C44)**: B4 v1 §4-1이 인용한 매핑v1 원본 엔트리 수("ele_hurt_add 12"·"ele_penetrate_ratio 12")와 3+4+5=12가 정확히 일치 — **원작 전체 24행 구조**가 `heroskillattr`의 ele 슬라이스 전체(88엔트리 중 12+12=24개)를 빠짐없이 담고 있음을 재확인했다(이 24행은 설계 근거로서 유효, CSV 실수록 16행과는 별개 개념).
|
||||||
|
|
||||||
|
### 1-3. 로더·소비 코드 파급 명세(개발팀장 구현 스펙 — plan-auditor 정정 5건 반영, 실제 GodDem 소스 재대조 완료)
|
||||||
|
|
||||||
|
> **정정 고지(C23 자진 정정)**: 아래는 v2 최초본의 §1-3 전사 오류를 실제 코드(`SurvivalSkillMasteryTable.cs`·`SurvivalMeta.cs:484-522`·`SurvivalLobbyController.SkillMastery.cs:142-158`, 2026-08-23 재실측)와 다시 대조해 **전면 재작성**한 것이다. 최초본은 "설계는 정확하나 코드 조각 전사에서 5건의 실수"(plan-auditor 평가)가 있었다 — 로더 인덱스가 실제 CSV 순서와 어긋나 `int.Parse`가 문자열(`s_StatKey`)을 파싱해 즉시 `FormatException`을 던지는 등, 그대로 구현하면 마스터리 시스템이 전면 정지했을 것이다.
|
||||||
|
|
||||||
|
**`SurvivalSkillMasteryTable.cs`**(v1 §3의 per-node MaxGrade 인프라〔`102e662`〕 위에 **추가 확장** — 재작성 아님. 아래 실제 현재 코드 기준 diff):
|
||||||
|
```diff
|
||||||
|
public class Row
|
||||||
|
{
|
||||||
|
public int NodeId;
|
||||||
|
+ public int HeroGrade; // 신규 — 영웅 등급(4/5/6). Node1 등 미편입 노드는 단일값 고정 사용
|
||||||
|
public int Grade; // 기존 의미 그대로: 마스터리 강화 단계
|
||||||
|
public float Value;
|
||||||
|
public long StepCost;
|
||||||
|
}
|
||||||
|
|
||||||
|
- readonly Dictionary<(int nodeId, int grade), Row> _rows = new();
|
||||||
|
+ readonly Dictionary<(int nodeId, int heroGrade, int grade), Row> _rows = new();
|
||||||
|
- readonly Dictionary<int, int> _maxGradeByNode = new();
|
||||||
|
+ readonly Dictionary<(int nodeId, int heroGrade), int> _maxGradeByNode = new();
|
||||||
|
|
||||||
|
- public int MaxGradeOf(int nodeId) => _maxGradeByNode.TryGetValue(nodeId, out int g) ? g : 0;
|
||||||
|
+ public int MaxGradeOf(int nodeId, int heroGrade) =>
|
||||||
|
+ _maxGradeByNode.TryGetValue((nodeId, heroGrade), out int g) ? g : 0;
|
||||||
|
```
|
||||||
|
|
||||||
|
**로더(C-1 정정)** — 신 CSV 헤더 `n_NodeId,s_StatKey,n_HeroGrade,n_Grade,f_Value,l_Cost`(§1-2)의 **실제 순서 그대로**(최초본은 c[1]에 문자열 컬럼 `s_StatKey`를 건너뛴다고 주석에 적어놓고 실제로는 `HeroGrade = int.Parse(c[1])`로 그 문자열을 파싱해버리는 자기모순이 있었다 — 아래는 실제 인덱스로 재작성):
|
||||||
|
```diff
|
||||||
|
- if (c.Length < 5) continue;
|
||||||
|
+ if (c.Length < 6) continue; // 컬럼 1개 추가(n_HeroGrade)
|
||||||
|
|
||||||
|
var row = new Row
|
||||||
|
{
|
||||||
|
NodeId = int.Parse(c[0]),
|
||||||
|
// c[1] = s_StatKey — 스킵(기존과 동일 관례, 변경 없음)
|
||||||
|
+ HeroGrade = int.Parse(c[2]), // 신규 컬럼(CSV 3번째 필드)
|
||||||
|
- Grade = int.Parse(c[2]),
|
||||||
|
+ Grade = int.Parse(c[3]), // 기존 c[2]→c[3]
|
||||||
|
- Value = float.Parse(c[3], inv),
|
||||||
|
+ Value = float.Parse(c[4], inv), // 기존 c[3]→c[4]
|
||||||
|
- StepCost = long.Parse(c[4]),
|
||||||
|
+ StepCost = long.Parse(c[5]), // 기존 c[4]→c[5]
|
||||||
|
};
|
||||||
|
- table._rows[(row.NodeId, row.Grade)] = row;
|
||||||
|
+ table._rows[(row.NodeId, row.HeroGrade, row.Grade)] = row;
|
||||||
|
- if (!table._maxGradeByNode.TryGetValue(row.NodeId, out int cur) || row.Grade > cur)
|
||||||
|
- table._maxGradeByNode[row.NodeId] = row.Grade;
|
||||||
|
+ var key = (row.NodeId, row.HeroGrade);
|
||||||
|
+ if (!table._maxGradeByNode.TryGetValue(key, out int cur) || row.Grade > cur)
|
||||||
|
+ table._maxGradeByNode[key] = row.Grade;
|
||||||
|
```
|
||||||
|
|
||||||
|
**`ValueAt`**:
|
||||||
|
```diff
|
||||||
|
- public float ValueAt(int nodeId, int grade)
|
||||||
|
+ public float ValueAt(int nodeId, int heroGrade, int grade)
|
||||||
|
{
|
||||||
|
if (grade <= 0) return 0f;
|
||||||
|
- if (grade > MaxGradeOf(nodeId)) grade = MaxGradeOf(nodeId);
|
||||||
|
+ if (grade > MaxGradeOf(nodeId, heroGrade)) grade = MaxGradeOf(nodeId, heroGrade);
|
||||||
|
- return _rows.TryGetValue((nodeId, grade), out var r) ? r.Value : 0f;
|
||||||
|
+ return _rows.TryGetValue((nodeId, heroGrade, grade), out var r) ? r.Value : 0f;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**`CumulativeCostAt`**(M-1 정정 — "동일 패턴" 뭉개지 않고 루프 내부까지 전부 명시):
|
||||||
|
```diff
|
||||||
|
- public long CumulativeCostAt(int nodeId, int grade)
|
||||||
|
+ public long CumulativeCostAt(int nodeId, int heroGrade, int grade)
|
||||||
|
{
|
||||||
|
if (grade < 0) grade = 0;
|
||||||
|
- if (grade > MaxGradeOf(nodeId)) grade = MaxGradeOf(nodeId);
|
||||||
|
+ if (grade > MaxGradeOf(nodeId, heroGrade)) grade = MaxGradeOf(nodeId, heroGrade);
|
||||||
|
long sum = 0L;
|
||||||
|
for (int g = 1; g <= grade; g++)
|
||||||
|
- if (_rows.TryGetValue((nodeId, g), out var r)) sum += r.StepCost;
|
||||||
|
+ if (_rows.TryGetValue((nodeId, heroGrade, g), out var r)) sum += r.StepCost;
|
||||||
|
return sum;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Node1(penetrate_ratio) 호환성**: 아직 단일 계열(10)만 쓰므로 CSV에 `n_HeroGrade` 컬럼을 추가하되 **6행 전부 같은 값(예: 편의상 4)을 채워** 스키마만 맞춘다 — Q2 답변 후 Node1도 다중 계열로 전환되면 이 자리에 실제 등급별 행을 추가하기만 하면 된다(현재는 값 변경 없음, 스키마 호환만).
|
||||||
|
|
||||||
|
**`SurvivalMeta.cs`**(C-2 정정 — 실제로는 신규 필드 1개 + **메서드 4개**〔최초본은 3개만 나열〕 내부 로직 수정, 시그니처는 기존과 동일 유지. 실제 소스 라인 484-522 재대조):
|
||||||
|
```diff
|
||||||
|
// SurvivalMetaData
|
||||||
|
+ /// <summary>현재 히어로의 고정 등급(4/5/6, 원작 heroskillattr 계열 대응). 다영웅 확장 시
|
||||||
|
+ /// 히어로별로 이 필드가 각각 다른 고정값을 가지게 된다(원작 hero_star.csv quality축과 동일 성격).
|
||||||
|
+ /// 본 필드는 성장/승급으로 변하지 않는다 — B1 PromotionStar와는 독립인 축(§2 근거).</summary>
|
||||||
|
+ public int HeroGrade = 4;
|
||||||
|
```
|
||||||
|
```diff
|
||||||
|
// ★ C-2 정정 — 최초본이 누락했던 4번째 메서드(MasteryAttackRatio, L494-497 실측)
|
||||||
|
public static float MasteryAttackRatio() =>
|
||||||
|
- SkillMastery.ValueAt(1, MasteryGradeOf(1)) // mastery_penetrate_ratio
|
||||||
|
- + SkillMastery.ValueAt(2, MasteryGradeOf(2)) // mastery_ele_hurt_add
|
||||||
|
- + SkillMastery.ValueAt(3, MasteryGradeOf(3)); // mastery_ele_penetrate_ratio
|
||||||
|
+ SkillMastery.ValueAt(1, Data.HeroGrade, MasteryGradeOf(1)) // mastery_penetrate_ratio
|
||||||
|
+ + SkillMastery.ValueAt(2, Data.HeroGrade, MasteryGradeOf(2)) // mastery_ele_hurt_add
|
||||||
|
+ + SkillMastery.ValueAt(3, Data.HeroGrade, MasteryGradeOf(3)); // mastery_ele_penetrate_ratio
|
||||||
|
|
||||||
|
public static int MasteryMaxGradeOf(int nodeId) =>
|
||||||
|
- SkillMastery.MaxGradeOf(nodeId);
|
||||||
|
+ SkillMastery.MaxGradeOf(nodeId, Data.HeroGrade);
|
||||||
|
|
||||||
|
public static bool CanUpgradeMastery(int nodeId) =>
|
||||||
|
- MasteryGradeOf(nodeId) < SkillMastery.MaxGradeOf(nodeId);
|
||||||
|
+ MasteryGradeOf(nodeId) < SkillMastery.MaxGradeOf(nodeId, Data.HeroGrade);
|
||||||
|
|
||||||
|
public static long MasteryUpgradeCost(int nodeId)
|
||||||
|
{
|
||||||
|
int cur = MasteryGradeOf(nodeId);
|
||||||
|
- if (cur >= SkillMastery.MaxGradeOf(nodeId)) return -1;
|
||||||
|
- return SkillMastery.CumulativeCostAt(nodeId, cur + 1) - SkillMastery.CumulativeCostAt(nodeId, cur);
|
||||||
|
+ if (cur >= SkillMastery.MaxGradeOf(nodeId, Data.HeroGrade)) return -1;
|
||||||
|
+ return SkillMastery.CumulativeCostAt(nodeId, Data.HeroGrade, cur + 1)
|
||||||
|
+ - SkillMastery.CumulativeCostAt(nodeId, Data.HeroGrade, cur);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
`GachaAttackRatio()`류처럼 `Data.*`를 내부에서 읽는 기존 관행 그대로 — **`HeroGrade`는 암묵적 컨텍스트로 흡수**된다.
|
||||||
|
|
||||||
|
**`SurvivalLobbyController.SkillMastery.cs`**(C-3 정정 — "UI 레이어 변경 0" 주장은 실측으로 반증됨. `RefreshMasteryPanel()` L156이 `SurvivalMeta`의 래퍼 메서드를 거치지 않고 `SurvivalMeta.SkillMastery.ValueAt(nodeId, g)`를 **직통 호출**하는 지점이 실제로 존재했다):
|
||||||
|
```diff
|
||||||
|
int max = SurvivalMeta.MasteryMaxGradeOf(nodeId); // 시그니처 불변 — 무변경
|
||||||
|
int g = SurvivalMeta.MasteryGradeOf(nodeId); // 시그니처 불변 — 무변경
|
||||||
|
- float val = SurvivalMeta.SkillMastery.ValueAt(nodeId, g);
|
||||||
|
+ float val = SurvivalMeta.SkillMastery.ValueAt(nodeId, SurvivalMeta.Data.HeroGrade, g);
|
||||||
|
```
|
||||||
|
**정정된 실제 파급 범위**: "UI 레이어 변경 0건"이 아니라 **"`SurvivalMeta`의 3개 래퍼 메서드(`MasteryMaxGradeOf`·`CanUpgradeMastery`·`MasteryUpgradeCost`)는 시그니처 불변, `ValueAt` 직통 호출 1줄만 수정"**이다 — `SurvivalMeta.Data`는 `public static SurvivalMetaData Data`(L122 실측)로 이미 공개 프로<ED9484>터티라 UI에서 직접 참조 가능.
|
||||||
|
|
||||||
|
**마이그레이션**: `SurvivalMetaData.Version`(현재 5) → **6**. `Load()`에 `if (_data.HeroGrade <= 0) _data.HeroGrade = 4;` 1줄 추가(기존 세이브 파일 호환, 신규 필드 기본값 보장).
|
||||||
|
|
||||||
|
### 1-4. 시그니처 변경 시 전 호출부 재확인 원칙(plan-auditor 권고 수용, 신규 — 차기 계승)
|
||||||
|
|
||||||
|
본 정정 5건은 전부 "시그니처를 바꾸는 diff를 작성하면서 그 심볼의 기존 호출부를 전수 grep하지 않은" 동일 원인에서 비롯됐다(`ValueAt`·`CumulativeCostAt`·`MaxGradeOf`가 몇 곳에서 불리는지 재확인 없이 "설계상 이래야 한다"만으로 작성). **원칙화**: 이후 balance-designer가 기존 메서드의 시그니처를 바꾸는 diff를 작성할 때는, 반드시 그 심볼명으로 GodDem 전체를 grep해 호출부 전수를 확인한 뒤 각 호출부의 diff를 명시한다 — 층간 교차표 필수화(v1 §6-1 원칙) 옆에 나란히 두는 상시 체크리스트 항목으로 삼는다.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. ★ 현 히어로 등급 배정 — 핵심 결정
|
||||||
|
|
||||||
|
### 2-1. 후보 평가
|
||||||
|
|
||||||
|
| 안 | 내용 | 원작 구조 정합 | 다영웅 확장 재작업 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| **(a) B1 승급(star) 매핑** | star 구간별로 HeroGrade 4→5→6 승격(예: star0~3=4·4~7=5·8~11=6) | **기각** — §1-1 실측: 원작에서 quality(등급)와 star는 **서로 다른 원작 파일의 직교 축**(`hero_star.csv` 자체가 quality×star 2차원이며 quality="진영별 희귀도"라고 B1 v1이 명시). star를 grade의 대용으로 쓰면 원작에 없는 인위적 결합을 만드는 것 — "원작과 동일하게 맞춰"라는 PD 지시와 정면 배치 | 신규 히어로마다 "이 히어로는 star 몇부터 시작하는가"라는 원작에 없는 규칙을 새로 발명해야 함 — 확장할수록 재작업 증가 |
|
||||||
|
| **(b) 히어로 등급 필드 신설 + 고정 배정 — 채택** | `SurvivalMetaData.HeroGrade` 신규(기본 4), 승급과 완전 독립 | **정합** — `hero_star.csv`의 quality축과 동일한 "히어로 정체성에 고정된 값" 패턴 그대로 재현 | 신규 히어로 추가 = 그 히어로의 `HeroGrade` 값 지정 1줄. 테이블 데이터는 이미 4/5/6 전부 있어 **재작업 0건** |
|
||||||
|
| (c) 기타(HeroLevel 구간 매핑 등) | HeroLevel(0~60) 구간별 등급 승격 | 기각 — HeroLevel도 원작의 별도 파일(`hero_level.csv`, B1 §1-2가 이미 이식)이 원본이라 (a)와 동일한 "서로 다른 원작 축 강제 결합" 오류 반복 | (a)와 동일한 확장 부담 |
|
||||||
|
|
||||||
|
### 2-2. 현 히어로 등급 값 — HeroGrade=4(최저) 배정 근거
|
||||||
|
|
||||||
|
1. **원작 데이터 가용 범위**: ele 2종은 원작에서 애초에 등급4 미만(1~3)에는 데이터 자체가 없다(§87 실측) — 4가 ele 접근의 최저 문턱이며, 현재 GodDem 히어로가 이미 Node2·3에 접근 가능한 상태(B4 설계 전제)와 정합하는 **가장 낮은 유효값**이다.
|
||||||
|
2. **F2P 장르 관행**: 최초 플레이어블 캐릭터를 최고 희귀도로 배정하는 상용 서비스는 드물다 — "시작 캐릭터=최저~중간 등급, 이후 뽑기/이벤트로 상위 등급 획득"이 표준 온보딩 곡선이며, GodDem 자체도 B3(가챠)에서 이미 이 원칙(신규유저는 낮은 확률로만 고등급 도달)을 채택 중이다.
|
||||||
|
3. **다영웅 확장 헤드룸 최대화**: 현재 히어로를 4로 시작하면, 이후 5·6등급 히어로를 "상위호환 신규 캐릭터"로 자연스럽게 배치할 수 있다 — 반대로 지금 6(최고)으로 배정하면 향후 히어로는 전부 "동급 이하"가 되어 신규 캐릭터의 성장 서사(더 강한 캐릭터를 얻는 재미)를 설계할 여지가 사라진다.
|
||||||
|
4. **Node1과의 정합**: Node1(penetrate_ratio, 계열10)도 "7개 동등 계열 중 최저"를 이미 선택해 둔 전례(B4 v1 §5-1)가 있다 — 최저값 우선이라는 이 세션의 일관된 재량 기준과 부합한다.
|
||||||
|
|
||||||
|
### 2-3. 기각안(C32)
|
||||||
|
|
||||||
|
| # | 검토안 | 기각 사유 |
|
||||||
|
|---|---|---|
|
||||||
|
| 1 | HeroGrade=6(v1의 최종 채택안 계승, 최고등급) | §2-2 — 다영웅 확장 헤드룸을 스스로 없애는 선택. v1의 "완전 맥스 표현"이라는 근거는 "히어로 1명이 영원히 유일하다"는 전제 위에서만 성립했는데 그 전제 자체가 PD 지시로 폐기됨 |
|
||||||
|
| 2 | HeroGrade=5(중간값) | 4·6 사이 절충 외에 별도 근거 없음 — 원작에서 5가 "표준/기본" 등급이라는 근거를 원작 데이터 어디에서도 찾지 못함(v1 §1-5의 94/74 기각 사유와 동일 성격 재확인) |
|
||||||
|
| 3 | (a) B1 승급 매핑 | §2-1 표 — 원작의 두 직교 축(quality 대 star)을 인위적으로 결합하는 구조적 오류 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Node1(penetrate_ratio) 편입 — 보류(스키마 호환만)
|
||||||
|
|
||||||
|
PD Q2("관통이 어떻게 적용되고 있고, 최저→최고 계열이 무슨 의미인지 설명해")는 **아직 답변만 발신된 상태**(PM, 대화로그 §98)이며 결정은 그 이후다. 본 문서는 Q2의 답을 선점하지 않는다(C36) — 다만 §1-2에서 이미 밝혔듯 CSV 스키마(`n_HeroGrade` 컬럼)는 Node1도 즉시 수용 가능한 형태로 설계했다.
|
||||||
|
|
||||||
|
**개발팀장 재추출 필요 항목(PM 상신 요청)**: penetrate_ratio의 원작 7개 계열(10~16)이 ele처럼 "영웅 등급별 계열"인지, 아니면 다른 축(예: 순수 품질 티어)인지 미확인 상태다 — Node1이 이번 구조에 편입될 경우 이 대응 관계의 실측이 선행돼야 한다. 현재 이 정보 없이 Node1을 무리하게 편입시키면 v1이 저질렀던 것과 같은 종류의 미검증 가정(그때는 "형제 스탯 패턴 유추", 이번엔 "7계열=등급"이라는 미확인 가정)을 반복하게 된다 — **PM 경유 개발팀장 재추출 요청을 상신 권고**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. 수치 테이블 — 3개 HeroGrade 전체 (설계 근거 24행·CSV 실수록 16행, v1 §4-2·4-3 산출치 재구성)
|
||||||
|
|
||||||
|
**방법론(v1 §4-1 D(grade) 그대로 승계 — 재계산 불요, 이미 산출된 값 재구성만)**: `StepCost(MasteryGrade) = D(MasteryGrade) × 고정Δ`, D(1~6)=550/2,310/5,445/10,120/16,555/24,970 무변경.
|
||||||
|
|
||||||
|
### 4-1. Node2(mastery_ele_hurt_add) — 3개 HeroGrade
|
||||||
|
|
||||||
|
| HeroGrade | MasteryGrade | f_Value | StepCost | 누적 |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| **4(현재 활성, CSV 수록)** | 1 | 0.05 | 550×5=2,750 | 2,750 |
|
||||||
|
| 4 | 2 | 0.10 | 2,310×5=11,550 | 14,300 |
|
||||||
|
| 4 | 3 | 0.15 | 5,445×5=27,225 | **41,525** |
|
||||||
|
| 5(예비, 🔴**CSV 미수록** — 참고치) | 1 | 0.06🟡 | 550×6=3,300 | 3,300 |
|
||||||
|
| 5 | 2 | 0.12🟡 | 2,310×6=13,860 | 17,160 |
|
||||||
|
| 5 | 3 | 0.18🟡 | 5,445×6=32,670 | 49,830 |
|
||||||
|
| 5 | 4 | 0.24🟡 | 10,120×6=60,720 | **110,550** |
|
||||||
|
| 6(예비, CSV 수록) | 1 | 0.07 | 550×7=3,850 | 3,850 |
|
||||||
|
| 6 | 2 | 0.14 | 2,310×7=16,170 | 20,020 |
|
||||||
|
| 6 | 3 | 0.21 | 5,445×7=38,115 | 58,135 |
|
||||||
|
| 6 | 4 | 0.28 | 10,120×7=70,840 | 128,975 |
|
||||||
|
| 6 | 5 | 0.35 | 16,555×7=115,885 | **244,860** |
|
||||||
|
|
||||||
|
🟡 **HeroGrade5 값 표기 유의(§1-2 M-2·m-1 정정 반영)**: 원작 계열94는 §87 실측 원문이 "0.06~0.24" 범위만 제공했고 개별 스텝 4개 전부를 명시하지 않았다 — 위 표는 계열93·95가 공통으로 보이는 "엄격 선형(base×level)" 패턴을 계열94에도 적용한 **추정치**다(🟡, v1 §1-1과 동일 근거). **이 4행은 CSV에는 수록하지 않는다**(§1-2) — 본 표는 설계 근거·향후 재추출 대조용 참고치로만 보존한다. 계열4(HeroGrade5)는 현재 비활성이라 실제 게임에 영향이 없다 — 활성화 전 개발팀장 재추출로 🟢 격상 권고.
|
||||||
|
|
||||||
|
### 4-2. Node3(mastery_ele_penetrate_ratio) — 3개 HeroGrade
|
||||||
|
|
||||||
|
| HeroGrade | MasteryGrade | f_Value | StepCost | 누적 |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| **4(현재 활성, CSV 수록)** | 1 | 0.03 | 550×3=1,650 | 1,650 |
|
||||||
|
| 4 | 2 | 0.06 | 2,310×3=6,930 | 8,580 |
|
||||||
|
| 4 | 3 | 0.09 | 5,445×3=16,335 | **24,915** |
|
||||||
|
| 5(예비, 🔴**CSV 미수록** — 참고치) | 1 | 0.04🟡 | 550×4=2,200 | 2,200 |
|
||||||
|
| 5 | 2 | 0.08🟡 | 2,310×4=9,240 | 11,440 |
|
||||||
|
| 5 | 3 | 0.12🟡 | 5,445×4=21,780 | 33,220 |
|
||||||
|
| 5 | 4 | 0.16🟡 | 10,120×4=40,480 | **73,700** |
|
||||||
|
| 6(예비, CSV 수록) | 1 | 0.05 | 550×5=2,750 | 2,750 |
|
||||||
|
| 6 | 2 | 0.10 | 2,310×5=11,550 | 14,300 |
|
||||||
|
| 6 | 3 | 0.15 | 5,445×5=27,225 | 41,525 |
|
||||||
|
| 6 | 4 | 0.20 | 10,120×5=50,600 | 92,125 |
|
||||||
|
| 6 | 5 | 0.25 | 16,555×5=82,775 | **174,900** |
|
||||||
|
|
||||||
|
🟡 HeroGrade5(계열74, "0.04~0.16") 동일 유의사항 — **CSV 미수록**(§1-2 M-2·m-1 정정), 참고치로만 보존.
|
||||||
|
|
||||||
|
### 4-3. 밸런싱 제안 표준 포맷(현재 활성 HeroGrade4 기준)
|
||||||
|
|
||||||
|
| 항목 | 현재 값(v1 실질 반영분) | 제안 값(v2) | 근거 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| CSV 스키마 | `n_NodeId,s_StatKey,n_Grade,f_Value,l_Cost`(단일 계열) | **`n_NodeId,s_StatKey,n_HeroGrade,n_Grade,f_Value,l_Cost`**(HeroGrade4·6 16행 수록, HeroGrade5 8행은 재추출 전까지 보류) | §1-2 — 원작 구조 보존, PD 지시 |
|
||||||
|
| Node2 활성 최댓값/총액 | (v1 5단 계획) 0.35 / 244,860G | **0.15 / 41,525G**(HeroGrade4 활성 슬라이스) | §2 — 현 히어로 등급4 배정 |
|
||||||
|
| Node3 활성 최댓값/총액 | (v1 5단 계획) 0.25 / 174,900G | **0.09 / 24,915G** | §2 |
|
||||||
|
| 3노드 합계(HeroGrade4 활성) | v1 479,710G(HeroGrade6 가정) | **126,390G**(Node1 59,950+Node2 41,525+Node3 24,915) | §2 — B2(510,496G) 대비 24.8%, 구B4(526,680G) 대비 -76.0% |
|
||||||
|
|
||||||
|
**세그먼트 영향**: v1과 동일 판정 — 전 세그먼트 동일(IAP 미연동).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. 층간 결합 최종 수치 — "현재 도달 가능한 최고 등급" 기준 재산출
|
||||||
|
|
||||||
|
### 5-1. 승산항 상한(HeroGrade4 활성 기준)
|
||||||
|
|
||||||
|
| 구성 | 값 |
|
||||||
|
|---|---|
|
||||||
|
| 승급(B1) | 0~0.22 |
|
||||||
|
| 마스터리(HeroGrade4 활성, Node1+2+3) | 0~0.30(=0.06+0.15+0.09) |
|
||||||
|
| 가챠옵션(B3, N-1 확정) | 0~1.08 |
|
||||||
|
| **결합 상한** | **1+0.22+0.30+1.08 = 1.60**(구 1.72 대비 **-7.0%**) |
|
||||||
|
|
||||||
|
### 5-2. ★★ N-1 확정의 전제 재이동(v1과 반대 방향, PD 인지 필요·최우선 고지)
|
||||||
|
|
||||||
|
**정직 고지(C5·C44 — 이전 회차 보고와의 방향 불일치를 숨기지 않음)**: v1(HeroGrade6 가정)에서는 "가챠/비가챠예산 배율이 1.7배→1.23배로 완화된다"고 보고했다. **본 v2(구조 정합 재검증 결과 HeroGrade4가 맞다는 결론)에서는 정반대 방향이 나온다**:
|
||||||
|
|
||||||
|
- 비가챠 예산(승급+마스터리) = 0.22+0.30 = **0.52**(구 0.64보다 오히려 **축소** — v1의 0.88과는 반대 방향)
|
||||||
|
- 가챠 기여(1.08) ÷ 신규 비가챠 예산(0.52) = **2.08배**(구 1.7배 대비 **악화**, v1이 예상했던 1.23배 완화와는 정반대)
|
||||||
|
|
||||||
|
**원인**: v1은 "히어로가 영원히 1명이니 최댓값(HeroGrade6)을 목표로 삼아야 한다"는 잘못된 전제 위에서 마스터리 총량을 크게 잡았다. 구조가 정정되며 "현재 활성 마스터리 총량"이 실제로는 더 작아졌고(0.42→0.30, 원래 잘못 이식된 값보다도 작음), 그 결과 가챠의 상대적 비중이 더 커졌다. **PD는 N-1(가챠 raw값 유지) 확정 당시의 "1.7배 초과 감수"라는 판단이, 이번 구조 정정으로 실제로는 2.08배까지 벌어진 상태에서 여전히 유효한지 재확인이 필요하다** — N-1 재론을 요구하는 것은 아니나(C36), 이 사실을 인지하지 못한 채 다음 판단을 내리시게 할 수 없어 최우선으로 고지한다.
|
||||||
|
|
||||||
|
### 5-3. 예비 등급(HeroGrade5·6) 활성화 시 참고치(승계, 재계산 불요)
|
||||||
|
|
||||||
|
향후 히어로 확장 또는 등급승급 메커니즘 도입 시 그 히어로가 HeroGrade5·6이라면 승산항이 각각 1.76(HeroGrade5, +2.3%)·1.96(HeroGrade6, +14.0%)까지 오른다 — v1 §6-1 표 값 그대로 유효(구조만 "다음 히어로의 잠재치"로 재해석).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. 검증 시나리오
|
||||||
|
|
||||||
|
| # | 시나리오 | 기대 결과 |
|
||||||
|
|---|---|---|
|
||||||
|
| 1 | 신규유저 기준선 무결성 | `Data.HeroGrade` 기본값 4, `MasteryAttackRatio()=0`(미투자) — `FinalAttack()` 불변 |
|
||||||
|
| 2 | 현재 히어로로 Node2 MasteryGrade3(만렙) 도달 | `MaxGradeOf(2,4)=3` — 이후 강화 버튼 "MAX", `ValueAt(2,4,3)=0.15` 정상 반환(HeroGrade4 슬라이스만 조회, 5·6 슬라이스 오염 없음) |
|
||||||
|
| 3 | 기존 세이브 마이그레이션(v1 배포 이후 유저 가정) | `Load()`가 `HeroGrade<=0`이면 4로 채움 — 기존 진행도(MasteryGrade 값) 무손실 |
|
||||||
|
| 4 | (미래 대비) HeroGrade=6인 신규 히어로 슬롯 시뮬 | `ValueAt(2,6,5)=0.35`·`MaxGradeOf(2,6)=5` 정상 반환 — 코드 변경 없이 테이블 조회만으로 성립 |
|
||||||
|
| 5 | Node1 스키마 호환 확인 | `n_HeroGrade` 컬럼 추가 후 기존 6행 전부 조회 결과 무변화(모든 행 동일 HeroGrade 값이라 실질적으로 단일 슬라이스와 동치) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. PD 확인 항목
|
||||||
|
|
||||||
|
1. **🔴 현 히어로 HeroGrade 배정값**: **4(최저) 채택 권고** — 최고등급 접근 최저 문턱·F2P 장르 관행·다영웅 확장 헤드룸(§2). 대안 5·6은 §2-3 기각.
|
||||||
|
2. **🔴★ N-1 재확인(최우선 고지, §5-2)**: 가챠/비가챠 예산 배율이 구조 정합 재검증 결과 1.7배→**2.08배로 악화**한다는 사실 인지 필요(v1의 "1.23배 완화" 보고와 정반대 방향 — 정직 정정).
|
||||||
|
3. (Q2 연계, 결정 아님) **Node1 편입 여부**는 PD Q2 답변 이후 별도 처리 — 편입 시 개발팀장의 계열10~16 등급 대응 재추출이 선행 필요(§3).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. 리스크
|
||||||
|
|
||||||
|
| ID | 리스크 | 심각도 | 내용 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| R-E4(신규) | HeroGrade5(계열94/74) 값이 🟡 추정(선형 외삽) | 낮음(현재 비활성) | §4-1·4-2 — 실제 게임에 영향 없음(HeroGrade4만 활성), 활성화 전 재추출 권고 |
|
||||||
|
| R-E5(신규) | v1 배포 이후 세이브 마이그레이션 누락 시 `HeroGrade=0` 잔존 | 중(구현 주의) | §1-3 — `Load()` 기본값 채움 로직 누락 시 `MaxGradeOf(node,0)`가 항상 0을 반환해 마스터리 전체가 잠기는 회귀. 검증 시나리오3 필수 |
|
||||||
|
| R-E6(신규, 승계) | 승산항 하락(0.42→0.30)으로 가챠 상대 비중 심화(§5-2) | 정보성(PD 확인 항목 2로 격상 처리) | N-1 재검토 필요성 자체가 리스크로 등재되기보다 PD확인으로 직행 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. 기각안 (C32 — v1 전체 승계 + 신규 3건)
|
||||||
|
|
||||||
|
**v1 기각안 전체 무변경 승계**(v1 §1-5·§2-3·§10 참조 — M-1~M-3·m-3 보강분 포함).
|
||||||
|
|
||||||
|
**v2 신규 기각안**: §2-3 표 3건(HeroGrade6·5·(a)B1승급매핑) — 상술.
|
||||||
|
|
||||||
|
**v2 보강분 신규 기각안(plan-auditor M-2·m-1 반영)**: HeroGrade5(계열94/74) 8행을 🟡 추정 표기 유지한 채 CSV에 수록 — 기각(§1-2). `f_Value`/`l_Cost`는 순수 수치 컬럼이라 CSV 자체로는 "추정"이라는 사실을 전달할 방법이 없어, 실측으로 오인될 위험이 표기 유지만으로는 해소되지 않는다 — 재추출 전까지 CSV에서 완전 제외하는 편이 "원작 실측만 CSV에 수록"이라는 기존 관행(Node1)과 정합.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. 변경 이력 (P16)
|
||||||
|
|
||||||
|
| 일시 | 작성 | 변경 | 근거 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 2026-08-23 | balance-designer | v1 완료 + 보강 5건(대표 계열 95/75 고정 채택) | plan-auditor 조건부통과 |
|
||||||
|
| **2026-08-23** | **balance-designer** | **v2 신규 — 구조 피벗**(대표 계열 고정 전제 폐기). ①CSV `n_HeroGrade` 컬럼 신설·HeroGrade4·6 16행 수록(HeroGrade5 8행은 재추출 전까지 보류, §1) ②(a)B1승급매핑을 원작 실측(hero_star.csv quality≠star 직교 축)으로 기각·현 히어로 HeroGrade=4 고정 배정 채택(§2) ③Node1 편입 보류·스키마만 호환(§3) ④N-1 전제 재이동 발견 — v1의 "1.23배 완화" 예상이 구조 정정 후 "2.08배 악화"로 반전, 최우선 고지(§5-2) | PD 직접 지시(대화로그 §98) — "영웅 등급별로 맞춰"(다영웅 로드맵 근거) |
|
||||||
|
| 2026-08-23 | plan-auditor | 모드A 감사 수행(트랙 분리) | — | **PD 상신 트랙**(구조·수치·기각근거·N-1반전 고지) 조건부 즉시 적격 통과. **구현 인계 트랙**은 §1-3 코드 diff 전사 오류 정정 후 적격(Critical 3·Major 1·Minor 2 — "설계는 정확·grep 한 번으로 걸러졌을 항목") |
|
||||||
|
| 2026-08-23 | balance-designer | plan-auditor 지적 5건 반영(같은 v2 내 확정, §1-3 전면 재작성) | 초안 | **C-1**(로더 인덱스 실제 CSV 순서로 정정 — 최초본은 `HeroGrade=int.Parse(c[1])`가 문자열 `s_StatKey`를 파싱해 즉시 FormatException)·**C-2**(`MasteryAttackRatio()` 누락분 추가 — "메서드 4개" 선언에 3개만 나열했던 오류)·**C-3**(`SurvivalLobbyController.SkillMastery.cs:156` `ValueAt` 직통 호출 1줄 diff 추가 + "UI 변경 0" 주장을 실측 반증 결과로 정정)·**M-1**(`CumulativeCostAt` 3곳 전체 명시 diff + `c.Length<5→<6` 가드)·**M-2·m-1**(HeroGrade5 8행 CSV 제외 결정 — §1-2·§4에 반영, §1-1 유추에 🟡 태그) | plan-auditor 조건부통과 회송 — 구현 인계 전 필수 정정 |
|
||||||
|
| — | 원칙 | **시그니처 변경 diff 작성 시 해당 심볼 전 호출부 grep 재확인 절차**(감사 권고 수용) | 층간 교차표 필수화(v1 §6-1 원칙) 옆에 나란히 두는 상시 체크리스트 항목(§1-4, 차기 계승) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. 후속 조치 (본 v2 범위 밖)
|
||||||
|
|
||||||
|
1. **PD 확인 2건 상신**(§7) — HeroGrade 배정값·N-1 재확인. 최우선(§5-2 악화 방향 고지 포함).
|
||||||
|
2. **개발팀 구현**: §1-3 코드 diff(v1 §3 per-node MaxGrade 인프라 위 확장) + CSV 갱신(16행, `n_HeroGrade` 컬럼 — HeroGrade5는 재추출 후 별도 추가). C6-1 백업 필수(v1 R-E2 승계).
|
||||||
|
3. **Node1 재추출 요청 상신**(§3, PM 경유) — 계열10~16의 등급 대응 여부, Q2 답변과 병행 처리 권고.
|
||||||
|
4. **HeroGrade5(계열94/74) 정밀 재추출**(R-E4) — 현재 🟡 추정치, 비활성 상태라 낮은 우선순위.
|
||||||
|
5. **v1 문서 배너 갱신**: 이미 본 문서 상단에 반영 완료.
|
||||||
|
6. **B3 본체 v3 §8-4 갱신 필요**(§5-2 연계) — v1 후속조치#6이 "3.06배(HeroGrade6 가정)"로 예고했던 것을 "2.08배(HeroGrade4 확정)"로 대체 갱신.
|
||||||
|
|
@ -399,3 +399,31 @@
|
||||||
- **PM push**: GodDem `53da915..102e662` origin 반영 — 전역 MaxGrade→노드별 전환(3파일·참조처 전환 9→0/8·등가성 전수 불일치 0·CSV 무변경 = 현 동작 완전 동일). **컴파일 로그 보존 표준 첫 적용**(`공유/개발팀_백업/GodDem/compile_*.log`·§93 ⑤ 이행). 부수: 미등록 노드 골드 증발 분기(설계 미기재 잠재 버그) 동시 차단
|
- **PM push**: GodDem `53da915..102e662` origin 반영 — 전역 MaxGrade→노드별 전환(3파일·참조처 전환 9→0/8·등가성 전수 불일치 0·CSV 무변경 = 현 동작 완전 동일). **컴파일 로그 보존 표준 첫 적용**(`공유/개발팀_백업/GodDem/compile_*.log`·§93 ⑤ 이행). 부수: 미등록 노드 골드 증발 분기(설계 미기재 잠재 버그) 동시 차단
|
||||||
- **효과**: PD 계열 택일 후 CSV에서 Node2·3 grade6 행 삭제만으로 5단 축소 안전 성립 — 수치 적용 선행 조건 완결
|
- **효과**: PD 계열 택일 후 CSV에서 Node2·3 grade6 행 삭제만으로 5단 축소 안전 성립 — 수치 적용 선행 조건 완결
|
||||||
- **★ 운영 안건 등재 (개발팀장 요청·PM 수용)**: 서브에이전트 발주 pm-auditor **3건 연속 판정 지연**(2건 사후 반환·1건 미수령) — C35-1 #2 "커밋 직전 사전 감사"가 반환 후행 구조에서 실효 상실. **개정 제안(PD 승인 영역)**: 구현 커밋의 사전 감사 = 설계 계층 plan-auditor 통과로 갈음·하위 pm-auditor = 사후 검증으로 공식화(본 세션 실운용 방식의 성문화). 차기 PD 상신 배치에 포함
|
- **★ 운영 안건 등재 (개발팀장 요청·PM 수용)**: 서브에이전트 발주 pm-auditor **3건 연속 판정 지연**(2건 사후 반환·1건 미수령) — C35-1 #2 "커밋 직전 사전 감사"가 반환 후행 구조에서 실효 상실. **개정 제안(PD 승인 영역)**: 구현 커밋의 사전 감사 = 설계 계층 plan-auditor 통과로 갈음·하위 pm-auditor = 사후 검증으로 공식화(본 세션 실운용 방식의 성문화). 차기 PD 상신 배치에 포함
|
||||||
|
|
||||||
|
## 97. §94 정정 append (per-node 커밋 사후 감사 지적 반영·PM 대행 집행)
|
||||||
|
|
||||||
|
- §94 정정 4건(감사 조건부 통과 지적): ①컴파일 로그 미추적 매칭 주체 = `.gitignore:78 *.log`(*.bak_* 아님) — **"BT 미추적 = 조직 미공유 = PC 변경 시 소실·§93 ⑤ 표준 목적 미달"** ②경고 6종 전체 목록(재현 근거): Singleton.cs L52·L54·L10 / UGUIBattleSceneUIController L112 / UGUILobbySceneUIController L152 / SurvivalLobbyController L95 — 전부 CS0618·CS0414 ③"설계 문서에 없던 잠재 버그" → **"설계 스펙(미등록 노드 0)의 기계적 귀결 — 설계가 명시 논하지 않았을 뿐"** 정정(커밋 메시지·§94·§95 전파분 포함) ④기각안 ③ 사유 보정 — 호출 경로에 매판 시작 1회(`SurvivalBattleManager.cs:147`) 포함(결론 유지)
|
||||||
|
- **표준 교정(C2 근본)**: 검증 근거 = git 추적 텍스트에 요지 인용 원칙 채택(파일 존재 ≠ 조직 보존·보존 주장 전 `git check-ignore -v` 실측 의무). 노하우 `feedback_verification_artifact_not_organizationally_preserved.md` 신설
|
||||||
|
- 코드·범위·백업(C6-1 완전 준수)·§3-2 충실도는 감사 통과 — 정정 대상은 보고 표현 계층뿐
|
||||||
|
|
||||||
|
## 98. PD 답변 3건 수령 — ele 구조 피벗·관통 설명 요청·감사 절차 개정 승인 (2026-08-23)
|
||||||
|
|
||||||
|
- **Q1 (ele 계열)**: PD 원문 "지금은 초기 버전이라 영웅이 1명이지만 **추후에는 영웅을 늘릴 예정**이므로 **원작과 동일하게 영웅 등급 별로 맞춰**" — 4안 택일이 아니라 **구조 지시 + 로드맵 공개**(다영웅 확장 예정). 단일 대표 계열 고정 전제 폐기 → **등급별 계열 데이터 구조 유지 이식**으로 재설계 피벗(balance-designer 위임). B1 승급(star0~11) 체계와 원작 영웅 등급(4/5/6) 매핑 가능성 검토 포함
|
||||||
|
- **Q2 (관통 Node1)**: PD "관통 스탯이 어떻게 적용되고 있고, 최저→최고 계열이 무슨 의미인지 먼저 설명해" — PM 설명 보고 발신(결정은 설명 후)
|
||||||
|
- **Q3 (감사 절차)**: PD **개정 승인** — C35 해당 조항 개정(구현 커밋 사전 게이트 = 설계 plan-auditor 통과 갈음·하위 pm-auditor = 사후 검증 공식화). C37 절차(SKILL 개정·아카이브·전파)로 차기 배치 집행 예정
|
||||||
|
|
||||||
|
## 99. ele 재설계 v2 완료 — 구조 피벗(대표 계열 고정→영웅 등급 차원 보유) + HeroGrade=4 배정 권고 (balance-designer, GodDem 수정 0건)
|
||||||
|
|
||||||
|
- **PD 원문(§98 Q1) 재인용**: "지금은 초기 버전이라 영웅이 1명이지만 추후에는 영웅을 늘릴 예정이므로 원작과 동일하게 영웅 등급 별로 맞춰."
|
||||||
|
- **결정·근거·영향(C32)**: v1의 "대표 계열 1개 고정"(95/75 채택) 전제를 폐기하고 **CSV `n_HeroGrade`(4/5/6) 컬럼을 신설해 원작 3개 계열(93·94·95/73·74·75) 전체를 24행으로 전량 수록**하는 구조로 재설계. **현 히어로 등급 배정 = HeroGrade4(최저) 고정 권고** — B1 v1 §4-1을 직접 재인용해 원작 `hero_star.csv`의 quality(진영별 희귀도, 고정)와 star(투자 성장)가 **서로 다른 직교 축**임을 재확인했고, 이 패턴이 heroskillattr의 계열(hero grade, 고정)에도 동일 적용된다고 판단 — PM이 제시한 (a) B1 승급(star) 매핑안은 이 실측 근거로 **기각**, (b) 신규 필드 고정 배정을 채택. 코드 파급: `SurvivalSkillMasteryTable.cs`(v1 §3 per-node MaxGrade 인프라를 3차원(NodeId×HeroGrade×MasteryGrade)으로 확장 — 재작성 아닌 추가 확장) + `SurvivalMeta.cs`(`Data.HeroGrade` 신규 필드, 기존 메서드 4종 시그니처 불변·내부만 `Data.HeroGrade` 경유) — **`SurvivalLobbyController.SkillMastery.cs`(UI)는 변경 0건**(HeroGrade를 명시 매개변수 대신 암묵 컨텍스트로 흡수한 설계 이익). 경제: 현재 활성(HeroGrade4) 3노드 합계 **126,390G**(v1 §6의 "93/73 참고행"과 동일치 재사용, 신규 산출 아님), 승산항 0.30, 결합상한 **1.60**(구1.72 대비 -7.0%). **★ N-1 전제 재이동 — v1과 반대 방향**: v1(HeroGrade6 가정)은 "가챠/비가챠 예산 배율 1.7배→1.23배 완화"로 보고했으나, 구조 정정 후(HeroGrade4) 정반대로 **1.7배→2.08배 악화**로 재계산됨 — 이전 회차 보고 방향과 정면 배치되는 사실을 은폐하지 않고 최우선 고지(§5-2, C5·C44).
|
||||||
|
- **기각안(C32)**: (1) HeroGrade=6(v1 채택안 그대로 계승) — 다영웅 확장 헤드룸을 스스로 소거하는 선택이라 기각(로드맵 지시와 배치). (2) HeroGrade=5(중간 절충) — 원작에 "5가 표준"이라는 근거 부재로 기각. (3) PM 제시 (a) B1 승급(star) 매핑 — `hero_star.csv` 실측(quality≠star 직교 축)으로 원작 이질적 구조 강제 결합이라 기각. (4) CSV 3계열 파일 분리안(단일 컬럼 추가 대신) — 로더 3배·확장 시 파일 신설 필요라 기각, 컬럼 추가가 3중 SOT 방지 원칙에 부합.
|
||||||
|
- **보류(C36 — PD 결정 영역 선점 회피)**: Node1(penetrate_ratio) 편입은 PD Q2 답변 이후로 유보 — 스키마만 호환되게 설계(6행 전부 동일 HeroGrade 값). 편입 시 계열10~16의 등급 대응 여부 개발팀장 재추출이 선행 필요 — PM 상신 요청.
|
||||||
|
- **산출물**: `공유/기획/GodDem/2026-08-23_B4ele_원작정합_재설계_v2.md`(신규, 최신 SOT) · v1에 역사보존 배너 추가.
|
||||||
|
|
||||||
|
## 100. ele v2 정정 5건 완료 — §1-3 코드 명세 전사 오류 전면 재작성 (balance-designer, GodDem 수정 0건)
|
||||||
|
|
||||||
|
- **감사 요지**: v2는 트랙 분리 조건부 통과 — **PD 상신 트랙**(구조·수치·기각근거·N-1반전 고지)은 즉시 적격, **구현 인계 트랙**은 §1-3 코드 명세 전사 오류 정정 후 적격("설계는 정확·grep 한 번으로 걸러졌을 항목"). 전부 실제 GodDem 소스(`SurvivalSkillMasteryTable.cs`·`SurvivalMeta.cs:484-522`·`SurvivalLobbyController.SkillMastery.cs:142-158`) 재대조로 정정.
|
||||||
|
- **결정·근거·영향(C32)**: **C-1**(런타임 예외) — 로더가 신 CSV 헤더(`n_NodeId,s_StatKey,n_HeroGrade,n_Grade,f_Value,l_Cost`) 실제 순서와 어긋나 `HeroGrade=int.Parse(c[1])`이 문자열 `s_StatKey`를 파싱 시도해 즉시 FormatException — 마스터리 전면 정지 위험이었다. c[0]NodeId·c[1]StatKey스킵·c[2]HeroGrade·c[3]Grade·c[4]Value·c[5]StepCost로 정정. **C-2**(컴파일 에러) — `MasteryAttackRatio()`(실제 라인 494-497) 3줄에 `Data.HeroGrade` 인자 누락분 추가, "메서드 4개" 선언에 3개만 나열했던 누락 시정. **C-3**(컴파일 에러) — `SurvivalLobbyController.SkillMastery.cs:156`의 `SurvivalMeta.SkillMastery.ValueAt(nodeId, g)` **직통 호출**(래퍼 미경유) 1줄을 실측으로 발견, diff 추가 + "UI 레이어 변경 0" 주장을 "래퍼 3종 시그니처 불변·ValueAt 직통 1줄만 수정"으로 정정(최초 주장은 실측 반증됨). **M-1** — `CumulativeCostAt` 3곳(시그니처·클램프·**루프 내부 `_rows.TryGetValue` 3-tuple 키 전환**)을 "동일 패턴" 뭉개지 않고 전부 명시 + `c.Length<5→<6` 가드. **M-2·m-1** — HeroGrade5(계열94/74) 8행을 재추출 전까지 **CSV에서 완전 제외**(4·6등급 16행만 수록) 채택 — `f_Value`/`l_Cost`는 순수 수치 컬럼이라 🟡 표기를 CSV 자체에 실을 수 없어 실측 오인 위험이 표기 유지만으로는 해소 안 됨. §1-1 "hero_star 패턴의 ele 적용" 유추에도 🟡 태그 명시.
|
||||||
|
- **기각안(C32)**: HeroGrade5를 🟡 표기 유지한 채 CSV 수록 — 기각(순수 수치 컬럼이라 표기 자체가 오인 방지 효과 없음, §1-2·§9).
|
||||||
|
- **감사 권고 수용**: 시그니처 변경 diff 작성 시 해당 심볼 전 호출부 grep 재확인 절차를 문서 원칙(층간 교차표 옆)에 명기 — §1-4 신설, 차기 계승.
|
||||||
|
- **산출물**: `2026-08-23_B4ele_원작정합_재설계_v2.md`(동일 파일 5건 정정, §1-3 전면 재작성 + §0·§1-1·§1-2·§4-1·§4-2·§9·§10 연동 정정, v3 미생성).
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,38 @@
|
||||||
|
# GodDem 대화로그 — 2026-08-24
|
||||||
|
|
||||||
|
> §번호는 프로젝트 누적 연속 (2026-08-23.md §100에서 이어짐)
|
||||||
|
|
||||||
|
## 101. B4 ele HeroGrade 축 구현 완료 — 원작 2차원 구조 이식 (개발팀장, GodDem 로컬 커밋 3fbc8b1)
|
||||||
|
|
||||||
|
§99·§100 설계 v2(정정 반영본)의 구현. PD 확정 2건 반영 — ①구조 = 원작과 동일하게 영웅 등급별 계열 ②시작 영웅 HeroGrade = 4(최저).
|
||||||
|
|
||||||
|
- **근본 구조**: 원작 `heroskillattr` 은 **(영웅 등급 × 강화 단계) 2차원**이고, 같은 스탯이라도 영웅 등급이 높을수록 단계값이 크고 단수도 깊다(등급4=3단·5=4단·6=5단). GodDem 은 이를 단일 축으로 눌러 담아 왔고, 그 결과 §87 재추출이 드러낸 "어느 계열을 이식할 것인가"가 **구조적으로 표현 불가능**했다. 축을 세워 해소한다 — 조회는 항상 현 히어로 등급의 슬라이스만 본다.
|
||||||
|
- **CSV 재구성(신 스키마 6컬럼 · 데이터 22행 · 파일 24줄)**: `n_NodeId,s_StatKey,n_HeroGrade,n_Grade,f_Value,l_Cost`
|
||||||
|
- Node1(`penetrate_ratio`) 6행 — HeroGrade 축 **미편입**, 전 행 HG4 고정(스키마 호환만·값 비용 무변경). 편입 여부는 PD Q2 이후 별도(설계 v2 §3).
|
||||||
|
- Node2(`ele_hurt_add`) HG4 3행(0.05/0.10/0.15) + HG6 5행(0.07~0.35)
|
||||||
|
- Node3(`ele_penetrate_ratio`) HG4 3행(0.03/0.06/0.09) + HG6 5행(0.05~0.25)
|
||||||
|
- **HeroGrade5 8행 미수록**(설계 v2 §1-2 M-2) — 원작 개별 스텝값이 범위로만 실측돼, 추정치가 데이터 파일에 박히면 이후 이 CSV 만 보는 사람이 실측으로 오인한다. 재추출 후 수록.
|
||||||
|
- **코드(3파일)**: `SurvivalSkillMasteryTable` — `Row.HeroGrade` 신설·`_rows` 3차원 키·`_maxGradeByNode` (node,heroGrade) 키·로더 인덱스 `c[2]`HeroGrade/`c[3]`Grade/`c[4]`Value/`c[5]`StepCost + `c.Length<6` 가드·`MaxGradeOf`/`ValueAt`/`CumulativeCostAt` 에 heroGrade 인자 / `SurvivalMeta` — `Data.HeroGrade=4` 신설·세이브 **v5→v6**·`Load()` 에 `if (_data.HeroGrade <= 0) _data.HeroGrade = 4;`·소비 메서드 4종 내부 전환(**시그니처 유지** — HeroGrade 는 `GachaAttackRatio` 류 관행대로 암묵 컨텍스트로 흡수) / UI `ValueAt` 직통 1줄.
|
||||||
|
- **§1-4 원칙 이행**: 시그니처를 바꾼 3심볼(`ValueAt`·`CumulativeCostAt`·`MaxGradeOf`) 전 호출부를 **착수 전 grep 전수 확인** → 설계 스펙이 전량 커버함을 확인 후 착수. 변경 후 재grep 결과 **구 2인자 호출 0건**.
|
||||||
|
- **★ 마이그레이션 방침(설계 명세 공백 구간 — 개발팀장 판단·PM 보고 대상)**: 구 세이브가 Node2·3 를 구 6단 기준으로 신 캡(HG4=3) 초과 보유한 경우 → **저장값 보존 + 조회 시 캡 클램프** 채택. `ValueAt` 이 캡 단계값(0.15)으로 수렴해 값 증발이 없고 `CanUpgrade=false`·`UpCost=-1` 로 추가 구매가 막힌다. **저장값을 지우지 않는 이유**: HeroGrade 는 향후 상승 가능한 축이라(설계 v2 §5-3 등급승급 도입 시), 지금 파괴하면 등급 상승 시 되살아났을 진행도를 영구 손실시킨다 — 보존이 유일하게 가역적이다.
|
||||||
|
- **⚠ 부작용 보고(미구현·보고만)**: 위 경우 UI 가 **`Grade 6/3`** 으로 분모 초과 표기된다. 저장값을 정직하게 보이는 표기이나 PD 플레이테스트에서 버그로 보일 수 있다. **표기 변경은 설계 미명세라 임의 구현하지 않았다** — PM·designer 판단 영역.
|
||||||
|
- **기각안(C32)**: ①**세이브 클램프**(초과 grade 를 캡으로 덮어쓰기) — 기각: 비가역이고 설계 §6-3 "기존 진행도 무손실" 문언에 정면 위배. ②**초과 투자분 골드 환불** — 기각: 설계 미명세이며 B2 환불 체계와 별개인 신규 정책 신설 = C36 영역. ③**HeroGrade5 8행을 🟡 표기로 CSV 수록** — 기각(설계 v2 §1-2 (나) 승계): `f_Value`/`l_Cost` 는 순수 수치 컬럼이라 CSV 자체로 "추정" 사실을 전달할 방법이 없다. ④**계열별 CSV 파일 3분리** — 기각(설계 v2 §1-2 승계): 로더 3배·등급 추가 시 파일 신설 필요. 컬럼 추가는 로더 1개·파일 1개 유지.
|
||||||
|
- **검증(신 표준 — 컴파일 결과 요지 직접 인용)**: Roslyn 실컴파일 **에러 0 · 경고 6**, 6건 전부 기존 파일 — `Singleton.cs(52,40)` CS0618 · `Singleton.cs(54,29)` CS0618 · `Singleton.cs(10,29)` CS0414 · `UGUIBattleSceneUIController.cs(112,17)` CS0618 · `UGUILobbySceneUIController.cs(152,17)` CS0618 · `SurvivalLobbyController.cs(95,17)` CS0618. **본 4파일発 경고 0**.
|
||||||
|
- **데스크 체크(CSV 를 로더 로직 그대로 재현·전 항목 통과)**: 데이터 22행 / 슬라이스 5개(node1 HG4=6단 · node2 HG4=3·HG6=5 · node3 HG4=3·HG6=5) / **설계 §4 표 대조 불일치 0건**(누적 Node2 HG4 41,525G·HG6 244,860G · Node3 HG4 24,915G·HG6 174,900G · Node1 59,950G) / HeroGrade5 행 **0건**(M-2 준수) / §6 시나리오 — #1 신규유저 ratio **0** · #2 `MaxGradeOf(2,4)=3`·`ValueAt(2,4,3)=0.15`·`CanUpgrade=false`·`UpCost=-1` · #4 `ValueAt(2,6,5)=0.35`·`MaxGradeOf(2,6)=5` · #5 Node1 6단 값 무변화 / **§4-3 결합 — 승산항 상한 0.30**(0.06+0.15+0.09) · **3노드 총액 126,390G** 설계치 정확 일치.
|
||||||
|
- **회귀**: 변경 4파일뿐 — 가챠·기절·합성·장비강화·카탈로그 **무접촉**(grep 확인). 신규유저 마스터리 ratio 0 이라 **22/400 불변**. B2 강화 경로 무접촉.
|
||||||
|
- **pm-auditor**: 개정 게이트(설계 plan-auditor 통과 = 사전 감사·pm-auditor 사후) 적용 — 호출 완료·판정 대기 없이 커밋. 매니페스트 `2026-08-24_014511` 등록. 판정 도착 시 PM 중계.
|
||||||
|
- **C6 백업**: `공유/개발팀_백업/GodDem/{SurvivalMetaSkillMastery.csv,SurvivalSkillMasteryTable.cs,SurvivalMeta.cs,SurvivalLobbyController.SkillMastery.cs}.bak_20260824_0141.{csv,cs}` (표준 파일명·확장자 포함).
|
||||||
|
- **한계**: **Unity 미기동 — 실플레이 미검증**(마스터리 패널 3노드 분모 표시·강화 버튼 반응·구 세이브 실제 로드 미확인). 코드·데이터 레벨까지. CSV 스키마 변경은 에디터 기동 시 재임포트 필요.
|
||||||
|
- **산출물**: GodDem 로컬 커밋 `3fbc8b1`(4 파일·88 insertions/58 deletions). **push 미실시(PM 영역)**. BT 레포 커밋 없음. 씬·프리팹·에셋 무접촉.
|
||||||
|
- **후속(PM 인계)**: ①`Grade 6/3` 표기 처리 방침 결정 ②설계 v2 §5-2 N-1 재확인(가챠/비가챠 배율 2.08배) PD 상신 ③Node1 편입 시 `penetrate_ratio` 계열10~16 등급 대응 재추출 선행(설계 v2 §3) ④HeroGrade5 계열94/74 개별 스텝 재추출 시 CSV 8행 추가.
|
||||||
|
|
||||||
|
## 102. HeroGrade 구현 사후 감사 — Critical 오판 정정·Major 3건 수용 (PM·2026-08-24)
|
||||||
|
|
||||||
|
- **감사 판정: 조건부 통과**(코드·CSV·diff 충실도·범위·C6 백업 전항 실측 통과·plan-auditor 정정 5건 반영 확인·구 2인자 호출 0건)
|
||||||
|
- **★ Critical "미승인 게이트 적용" = 오판 정정**: 감사관이 `2026-08-23.md` L401(제안 시점)만 읽고 **L413 §98 PD 승인 기재를 미확인**. **PD 개정 승인은 실재**(AskUserQuestion "개정 승인(권장)"). 단 **유효 잔여 = 성문화(SKILL 본문) 미집행 상태에서 "게이트 적용" 표기** → 정확한 분류 **"승인 완료·성문화 미집행"**. PM 조치: C37 절차로 **개정 즉시 집행 착수**(pm-auditor 사전 감사 발주 — 규칙 개정은 #1 사전 감사 유지). L23 표기는 본 정정으로 승계
|
||||||
|
- **Major 1 수용 (실측 우위)**: 감사관이 실세이브(`survival_meta.json` 96B·Version 1) 직접 실측 — **`SkillMasteryLevel` 키 부재 = 마스터리 투자 0**. 마이그레이션 3근거·부작용(`Grade 6/3` 표기)이 **현 세이브에서 발생 불가**. 방침(저장값 보존+조회 캡 클램프)은 유지·**"장래 대비 선제 정책"으로 격하 표기**·PD 보고 시 실좌초 0G 병기
|
||||||
|
- **Major 2 수용 (신규 결함 등재)**: **Node1 HeroGrade≠4 함정** — `_maxGradeByNode`가 Node1에 (1,4)만 보유 → 장래 HG5·6 히어로에서 `MaxGradeOf(1,6)=0`·`ValueAt=0f`·구매 차단 = **Node1 마스터리 통째 소멸**(`102e662`가 제거한 실패 양식의 HeroGrade 축 재발). 설계 §6 #4 "테이블 재작업 0건" 반증 — Node1 행 추가 선행 필수. 구현은 §1-3 "편의상 4" 합치라 구현 결함 아님·**설계 정정+가드 신설 후속 등재**
|
||||||
|
- **Major 3 수용**: 좌초 골드 규모 명시 — 구 CSV 기준 Node2 406,780G→41,525G·Node3 59,950G→24,915G = **최대 400,290G 좌초**(신 3노드 총액의 3.2배)·**단 현 세이브 실좌초 0G**(Major 1 결합)
|
||||||
|
- **Minor 수용 3**: ①`HeroGrade<=0` 가드 근거 오류 — Newtonsoft+필드 초기자(`= 4`)로 **미존재 키는 4로 남음·0 안 됨**(가드는 무해·근거 문장/설계 R-E5 심각도 하향) ②매니페스트 target 파일명 불일치(08-23→08-24) ③백업 경로 미표기(실재 확인 `공유/개발팀_백업/GodDem/` 4종·표준 포맷)
|
||||||
|
- **과장 1건 정정 수용**: "§6-3 무손실 문언 직접 부합" → **"저장 정수 보존·실효값은 캡 반감(0.30→0.15)"**이 정확. 근거③("HeroGrade 향후 상승 축")은 설계 내부 모순 인용이라 삭제·근거①②로 충분
|
||||||
|
- **push 전 필수 반영**: 커밋이 SOT로 인용한 설계 v2 등 BT untracked 4종 동반 커밋(본 배치에서 집행)
|
||||||
Loading…
Reference in New Issue