diff --git a/.claude/agents/content-designer.md b/.claude/agents/content-designer.md
index efd36c7..bee13e1 100644
--- a/.claude/agents/content-designer.md
+++ b/.claude/agents/content-designer.md
@@ -44,9 +44,9 @@ model: sonnet
 ## 기록 의무 (2026-04-17 개정 — 영역 특화)
 
 **영역 특화 준수 사항**
-- **P17 ★ 조건 배타 배치 규칙**: 수상한잡화점 스테이지·빌드 컨텐츠 설계 시 7종 배타 조합 전수 체크. 신규 컨텐츠 조건 추가 시 배타 조합도 함께 정의. 위반 배치는 총괄PM 검증 단계에서 차단된다.
 - **P18 설계 문서화 의무**: 신규 컨텐츠 셋·카테고리·스킬 체계 등 설계 결정은 반드시 별도 문서로 명문화. 유령 문서(참조만 남고 본문 부재) 금지.
-- **C7 재미 우선 원칙**: 모든 컨텐츠는 "왜 존재하는가"에 답할 수 있어야 한다. 역할 없는 컨텐츠는 버린다. 명확한 상위호환은 기획 실패.
+- **P30 재미 우선 원칙** (기획팀 전용): 모든 컨텐츠는 "왜 존재하는가"에 답할 수 있어야 한다. 역할 없는 컨텐츠는 버린다. 명확한 상위호환은 기획 실패.
+- **P17 관련 주의**: 구 P17(★ 조건 배타 배치) 규칙은 2026-04-21 조직 전환 시 폐기됨. EerieVillage 등 프로젝트가 유사 조건 슬롯 체계를 요구하면 신규 P 번호로 재설계 (폐기 규칙 아카이브 참조).
 
 **공통 기록 의무 (전 에이전트 공통)**
 - **C13·P19 PD 지시 트래킹 (헌법급)**: PD님 직접 지시 인지 즉시 `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 등록. 4단계(시작·진행·완료·중단) 전부 가시화. 누락 시 C3·C13 위반.
diff --git a/.claude/agents/dev-auditor.md b/.claude/agents/dev-auditor.md
index 3ed2dde..81d406a 100644
--- a/.claude/agents/dev-auditor.md
+++ b/.claude/agents/dev-auditor.md
@@ -17,7 +17,7 @@ pm-auditor(PM 전담 감사)만으로는 개발팀 내부 세부 검증 불가.
 
 노하우 축적 채널:
 - **1순위**: `memory/org/feedback_dev_*.md` — 개발팀 실수 패턴·기술 결정 경위 영구 기록
-- **2순위**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md`·`공유/대화로그/코어프레임워크/YYYY-MM-DD.md` — 감사 결과 엔트리
+- **2순위**: `공유/대화로그/EerieVillage/YYYY-MM-DD.md`·`공유/대화로그/코어프레임워크/YYYY-MM-DD.md` — 감사 결과 엔트리
 - **3순위**: `공유/조직공지/` — 반복 기술 패턴 발견 시 조직 공지
 
 ## 감사 영역 5종
@@ -79,7 +79,7 @@ pm-auditor(PM 전담 감사)만으로는 개발팀 내부 세부 검증 불가.
 ## 산출물 3종 (매 감사 필수)
 
 1. **감사 보고서** — `공유/소통/dev-auditor→PM/YYYY-MM-DD_감사보고_<주제>.md`
-2. **대화로그 엔트리** — `공유/대화로그/수상한잡화점/YYYY-MM-DD.md` 또는 `공유/대화로그/코어프레임워크/YYYY-MM-DD.md` append
+2. **대화로그 엔트리** — `공유/대화로그/EerieVillage/YYYY-MM-DD.md` 또는 `공유/대화로그/코어프레임워크/YYYY-MM-DD.md` append
 3. **feedback 메모리** (해당 시) — `memory/org/feedback_dev_*.md`
 
 ## 행동 지침
diff --git a/.claude/agents/plan-auditor.md b/.claude/agents/plan-auditor.md
index c24d95e..1704f0a 100644
--- a/.claude/agents/plan-auditor.md
+++ b/.claude/agents/plan-auditor.md
@@ -17,8 +17,8 @@ pm-auditor(PM 전담)·dev-auditor(개발 전담)만으로는 기획 고유 영
 
 노하우 축적 채널:
 - **1순위**: `memory/org/feedback_plan_*.md` — 기획 결정 경위·실수 패턴 영구 기록
-- **2순위**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md` — `#기획` 태그 엔트리
-- **3순위**: `프로젝트/수상한잡화점/기획/**/변경이력_*.md` — 밸런스 수치 변경 이력 (C6 자산 보호)
+- **2순위**: `공유/대화로그/EerieVillage/YYYY-MM-DD.md` — `#기획` 태그 엔트리
+- **3순위**: `프로젝트/EerieVillage/기획/**/변경이력_*.md` — 밸런스 수치 변경 이력 (C6 자산 보호)
 
 ## 감사 영역 5종
 
@@ -41,8 +41,8 @@ pm-auditor(PM 전담)·dev-auditor(개발 전담)만으로는 기획 고유 영
 - balance·content·level·narrative·system·ux 각자의 기록 의무
 - 전문 에이전트가 독립 호출될 때 내부 결정이 팀장·PM에 반영되는 경로
 
-### 5. P17 조건 배타 배치 규칙 등 프로젝트 규칙 준수
-- 수상한 잡화점 고유 규칙(P17) 위반 감지
+### 5. 프로젝트 규칙 준수
+- EerieVillage 등 프로젝트 고유 규칙 위반 감지 (P17은 2026-04-21 조직 전환 시 폐기 — 폐기 규칙 아카이브 참조)
 - 스테이지 기획·몬스터 배치·보스 배치 정합성
 
 ### 6-A. C34/C16-1 동급 생존성 이슈 축소 보고 감지 (2026-04-19 신설 — PD님 직접 지시)
@@ -66,7 +66,7 @@ pm-auditor(PM 전담)·dev-auditor(개발 전담)만으로는 기획 고유 영
 ## 산출물 3종
 
 1. **감사 보고서** — `공유/소통/plan-auditor→PM/YYYY-MM-DD_감사보고_<주제>.md`
-2. **대화로그 엔트리** — `공유/대화로그/수상한잡화점/YYYY-MM-DD.md` append
+2. **대화로그 엔트리** — `공유/대화로그/EerieVillage/YYYY-MM-DD.md` append
 3. **feedback 메모리** (해당 시) — `memory/org/feedback_plan_*.md`
 
 ## 행동 지침
diff --git a/.claude/skills/BurningTimes-코어룰/SKILL.md b/.claude/skills/BurningTimes-코어룰/SKILL.md
index 5897cb0..ae017f3 100644
--- a/.claude/skills/BurningTimes-코어룰/SKILL.md
+++ b/.claude/skills/BurningTimes-코어룰/SKILL.md
@@ -50,11 +50,10 @@ description: BurningTimes 조직의 헌법 제1원칙(5항 ①~⑤) + 헌법급
 
 ### 조직 현황 — 프로젝트 구성
 
-추후 프로젝트가 확장되면 점차 프로젝트 구성은 늘어날 수 있으며, 현재 우리 조직의 프로젝트는 **3종**으로 구성되어 있다:
+추후 프로젝트가 확장되면 점차 프로젝트 구성은 늘어날 수 있으며, 현재 BurningTimes 조직의 프로젝트는 **2종**으로 구성되어 있다:
 
-1. **코어 코드 프레임워크 개발** (`코어코드/BT.Framework/`) — 조직 자산 구축 프로젝트
-2. **수상한 잡화점** (`프로젝트/수상한잡화점/`) — 현행 게임 개발 프로젝트
-3. **신규 프로젝트** — 차기 프로젝트 (구체 내용 미정, 결정 시 본 섹션 갱신)
+1. **코어 코드 프레임워크 개발** (`코어코드/BT.Framework/`) — 조직 자산 구축 프로젝트 (Tier 1 16/16 완결, Tier 2·3 확장 예정)
+2. **기묘한 고을 : 조선퇴마뎐 (EerieVillage)** (`프로젝트/EerieVillage/`) — BurningTimes 조직의 첫 번째 게임 개발 프로젝트 (Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame 템플릿 기반)
 
 ### 조직 핵심 자산 — Live 더미 파일 프로세스
 
@@ -387,7 +386,7 @@ CLAUDE.md 신규 항목, 매 턴 로드 대상 확대, `MEMORY.md` 인덱스 확
 #### 예외 — 파일 성격 배너는 유지 (방향 전환 배너와 구별)
 다음 2종은 **파일 자체의 성격**을 표시하는 배너이므로 상단 유지:
 - **아카이브된 문서 자체** (예: `07_*.md` 상단 "🔴 아카이브됨 — 대체: X" 배너 + 본문 당시 그대로) — 파일 전체가 기각안 근거로 소비되므로 상태 명시 필요
-- **완료 실적 문서** (예: `02_수상한잡화점_추출대상_v1.md` 상단 "🟢 완료 실적 아카이브" 배너) — 파일 성격 전환 명시 필요
+- **완료 실적 문서** (예: 특정 단계 완결 후 "🟢 완료 실적 아카이브" 배너로 전환된 문서) — 파일 성격 전환 명시 필요
 
 위 2종 외 일반 현역 문서는 **본문 최신 + 말미 참조 링크**만 (방향 전환 상단 배너 금지).
 
@@ -1151,32 +1150,6 @@ C20-7 자기검증 5문항에 다음 항목 추가:
 - 롤백·회귀 분석 시 변경 이력을 활용할 수 있도록 한다
 - 중요 결정은 별도 의사결정 로그로 관리
 
-## P17. ★ 조건 배타 배치 규칙 (수상한 잡화점 프로젝트)
-
-Prove-2-of-3 체계에서 스테이지의 슬롯2·슬롯3에 ★ 조건을 배치할 때, **아래 배타 조합은 동시 배치 금지**한다.
-
-### 배타 조합 7종
-
-| # | 배타 조합 | 사유 |
-|---|----------|------|
-| 1 | **C2 (완벽 클리어) ∧ N2 (피격 제한, 상한 서브맵수×1 이하)** | 피격 최소화 축 이중 부담 과도 |
-| 2 | **C6 (포션 절제) ∧ 물약 사용 유도 조건** | 물약 빌드 전면 배제 |
-| 3 | **C6 ∧ N4 (쉴드 하한 MaxShield×30% 이상)** | 회복 빌드 외 빌드 배제 |
-| 4 | **(입문 1~6) C1 (신속 타이트) ∧ C3 (HP≥70%)** | 입문 구간 이중 부담 과도 (중반·후반은 숙련자용 조합이라 허용) |
-| 5 | **C9 (보스 집중) ∧ 단독 보스·보스 미등장 스테이지** | 논리 불성립 (Stage 2·7·10·13 등) |
-| 6 | **(입문 1~6) N3 (치명타 처치 N≥3)** | 치명타 빌드 미형성 구간에서 달성 곤란 |
-| 7 | **N5 (후열 선공) ∧ N6 (전열 선공)** | 타겟팅 자유도 박탈, 논리 모순 |
-
-### 스테이지 기획 시 준수 사항
-- 배치 확정 전 **위 7개 조합을 전수 체크**한다
-- 신규 조건 추가 시 **배타 조합도 함께 정의**한다
-- 규칙 위반 배치는 **총괄PM 검증 단계에서 차단**한다
-- 맵 패턴 구성 시 C9와 관련된 몬스터 등장 패턴(단독 보스 vs 혼합 등장) 정합성 확인 필수
-
-### 적용 범위
-- 현재는 **수상한 잡화점** 프로젝트 한정 규칙
-- 타 프로젝트 도입 시 해당 프로젝트 조건 풀에 맞게 배타 조합 재정의
-
 ## P18. 설계 문서화 의무
 
 **"설계에 해당하는 결정사항은 반드시 문서로 명문화한다."** 참조만 되고 본문이 존재하지 않는 유령 문서는 허용되지 않는다.
@@ -1405,7 +1378,7 @@ PD님이 **"세션 공유"**라고 지시하면, 현재 세션의 모든 변경
 ### P28-2. 필드 규칙
 - **#**: PD 지시 로그 번호. 팀별 별도 채번 (개발·기획 혼용 금지)
 - **요지**: 1줄 핵심 요약 (25자 이내 권장). 장황 설명 지양
-- **영향 프로젝트** (필수, 2026-04-17 추가): 본 업무가 결과물·영향을 미치는 프로젝트 명시. 값 예시 — `수상한잡화점` / `코어 프레임워크` / `조직 공통` / `차기 프로젝트명`. 복수 영향 시 쉼표 구분. 프로젝트 경계가 모호한 조직 운영·규칙 개정 업무는 `조직 공통`
+- **영향 프로젝트** (필수): 본 업무가 결과물·영향을 미치는 프로젝트 명시. 값 예시 — `EerieVillage` / `BT.Framework` / `조직 공통`. 복수 영향 시 쉼표 구분. 프로젝트 경계가 모호한 조직 운영·규칙 개정 업무는 `조직 공통`
 - **상태**: 활성 3종만 표기(`진행중`·`대기`·`보류`). 완료 아카이브 항목은 본 테이블 배제 (P19 2분할 구조 준수)
 - **재개 트리거**: 대기·보류 시 필수 (누락 금지). 진행중은 "—" 또는 현 진행 단계
 - **주요 관찰**: 4개 항목 순서 고정. 해당 없으면 "없음" 명시 (항목 생략 금지)
@@ -1451,39 +1424,43 @@ PD님이 **"세션 공유"**라고 지시하면, 현재 세션의 모든 변경
 
 ---
 
-## P29. 코어 코드 프레임워크 프로젝트 규칙 (2026-04-18 PD님 직접 지시)
+## P29. 코어 코드 프레임워크 프로젝트 규칙 (2026-04-21 PD님 직접 지시 개정 — EerieVillage 적용)
 
-> **적용 범위**: **코어 코드 프레임워크** 프로젝트 (`코어코드/BT.Framework/`·`프로젝트/코어프레임워크/`) 전용 규칙. 본 규칙은 프로젝트 단위 고유 규칙으로 P17(수상한잡화점 전용)과 동일 층위.
+> **적용 범위**: **BT.Framework** 프로젝트 (`코어코드/BT.Framework/`·`프로젝트/코어프레임워크/`) 전용 규칙. 본 규칙은 프로젝트 단위 고유 규칙이다.
 
 ### P29-1. 조직 자산 계승·발전 원칙
 
-코어 코드 프레임워크는 **우리 조직의 자산**이므로, 계승 발전시킨다.
+BT.Framework는 **BurningTimes 조직의 자산**이므로, 계승 발전시킨다.
 - 프로젝트 종료·개발자 이탈·환경 변경 시에도 자산성 유지
-- 버전 태그·CHANGELOG·설계 문서(`프로젝트/코어프레임워크/01~04_*.md`)로 개정 이력 영구 보존
-- Tier 1 16/16 구현 완료 상태(2026-04-17)를 출발점으로 Tier 2·3 확장
+- 버전 태그·CHANGELOG·설계 문서(`프로젝트/코어프레임워크/01·03·04_*.md`)로 개정 이력 영구 보존
+- **Tier 1 16/16 구현 완료** (2026-04-17 NerdNavis 조직 시절 완결 · BurningTimes 계승)을 출발점으로 Tier 2·3 확장
 
-### P29-2. 차기 프로젝트 적극 활용
+### P29-2. 차기·신규 프로젝트 적극 활용
 
-**차기 프로젝트부터** 우리 조직의 핵심 자산인 코어 코드 프레임워크 조직 자산으로 **적극 활용**하도록 한다.
-- 차기 프로젝트 착수 시 `BT.Framework` 1순위 도입 검토
+조직 핵심 자산인 BT.Framework를 **신규 프로젝트에 적극 활용**한다.
+- 프로젝트 착수 시 `BT.Framework` **1순위 도입 검토**
 - "만들고 끝"이 아니라 "게임을 만들수록 쌓이는 자산"으로 운영
 - Unity 엔진 한정되지 않음 (차기 프로젝트 결정 시 재평가)
 
-### P29-3. 현 프로젝트(수상한 잡화점) 활용 방침
+### P29-3. EerieVillage 활용 방침 (2026-04-21 PD님 직접 지시 B안 신설)
 
-**현 프로젝트(수상한 잡화점)에는 활용하지 않지만**, 프로젝트 개발 과정을 통해 코어 코드 프레임워크를 **개선할 수 있는 인사이트를 얻는데 노력**한다.
-- 수상한잡화점에 프레임워크 도입 금지 (확정, 재논의 대상 아님)
+**EerieVillage (기묘한 고을: 조선퇴마뎐)는 BurningTimes 조직의 첫 번째 게임 개발 프로젝트**이며, BT.Framework 도입 여부는 **착수 단계에서 재검토**한다.
+
+- **Unity 6000.3.13f1 LTS** + **2D PlatformerMicrogame 템플릿** 기반이라 Tier 1(범용 유틸·SafeArea·로깅·검증 등)은 즉시 활용 가능성이 높음
+- **도입 범위 결정 시 고려 사항**:
+  - Tier 1 16종 중 플랫포머 장르에 유효한 것 선별 (SafeAreaBorder·Log·ValidationEx·FormatEx·EnumEx 등)
+  - Tier 2·3(전투·네트워크·UI 고급) 요구사항은 EerieVillage 기획 확정 후 재평가
+  - **2D 플랫포머 특화 컴포넌트** 필요 시 Tier 2 신규 항목으로 추가 (UITouchHandler·BackKeyDispatcher 등 Phase 2-B `기획_ux_designer_v1.md` 식별분)
 - 개발 과정에서 범용성 있는 패턴·노하우 식별 시 즉시 기록:
-  - `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md` (완료 실적 아카이브)
   - `공유/대화로그/코어프레임워크/YYYY-MM-DD.md` (방향 전환·개선 인사이트)
   - `memory/org/feedback_*.md` (실수 패턴·재발 방지)
-- Tier 1 16/16 구현 실증이 본 원칙의 첫 성과 사례
+  - `공유/조직자산/시행착오_아카이브/` (프로젝트별 교훈 영구 자산)
 
 ### P29-4. 관련 규칙·자산
 - **헌법 제1원칙 원칙 ②** (경험 축적·계승·발전) — 본 규칙의 상위 근거
-- **조직 현황·핵심 자산 안내** (프로젝트 3종 중 1번)
-- **방향전환 히스토리 아카이브** — 코어프레임워크 관련 방향 전환 기록
-- **P17** — 수상한잡화점 전용 프로젝트 규칙 (동일 층위)
+- **조직 현황·핵심 자산 안내** (BT 조직 프로젝트 2종 중 1번)
+- **방향전환 히스토리 아카이브** — BT.Framework 관련 방향 전환 기록
+- **폐기 규칙 아카이브** — 구 P17(수상한잡화점 전용 ★ 조건 배타 규칙) 폐기 기록
 - **C14-5** — 본문 최신 + 히스토리 아카이브 (프레임워크 문서도 동일 원칙)
 
 ---
@@ -1509,9 +1486,9 @@ BurningTimes의 게임 개발 프로젝트에서 **기획팀은 모든 산출물
 - P30과 C11이 충돌하면 **총괄PM·PD님 판단 하에 조율** (기존 C7-C11 조율 규정 계승)
 
 ### P30-3. 적용 프로젝트
-- **수상한잡화점**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정
+- **EerieVillage (기묘한 고을: 조선퇴마뎐)**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정 (BurningTimes 첫 게임 개발 프로젝트)
 - **차기 신규 프로젝트**: 동일 원칙 계승
-- **코어 프레임워크 프로젝트**: P29 계승·발전이 최우선 (재미는 상위 프로젝트 영역)
+- **BT.Framework**: P29 계승·발전이 최우선 (재미는 상위 프로젝트 영역)
 
 ---
 
diff --git a/.gitignore b/.gitignore
index 296cb7c..d8bc317 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,8 +21,6 @@ settings.local.json
 .claude/plugins/
 # Claude Code가 세션마다 자동 생성하는 worktree (embedded repo로 오등록 방지)
 .claude/worktrees/
-개발실/.claude/worktrees/
-기획실/.claude/worktrees/
 
 # ===== 시크릿·키 =====
 *.key
@@ -45,18 +43,13 @@ Assets/StreamingAssets/aa/
 Build/
 Builds/
 
-# ===== 기획실 대용량·산출물 =====
-기획실/.cache/
+# ===== 대용량 기획 산출물 =====
 *.xlsm
 *.xlsx
 *.xls
 ~$*.xlsm
 ~$*.xlsx
 
-# ===== 개발실 스켈레톤 (별도 레포 관리) =====
-# _skeleton/는 추후 UPM 독립 레포로 분리 예정 — 본 조직 레포에서는 제외
-개발실/코어_설계/_skeleton/
-
 # ===== data 디렉토리 (DB 실물) =====
 data/*.sqlite
 data/*.sqlite-journal
diff --git a/CLAUDE.md b/CLAUDE.md
index 91f184c..5246797 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -68,7 +68,6 @@ PD님
 ### 프로젝트 규칙 요약 (활성 24개, 번호 구멍 허용)
 - **P1~P11** 기본 운영 (호칭·현황·이슈·토큰·의사결정·커뮤니케이션·위임·모델·트래킹·노하우·자율효율화)
 - **P13** 코드·의존성·환경 변경 관리 (구 P15 통합) / **P14** QA 게이트 / **P16** 산출물 추적성
-- **P17** 수상한잡화점 전용 ★ 조건 배타 배치 7종
 - **P18** 설계 문서화 의무 / **P19** PD님 직접 지시 트래킹 및 공유 의무
 - **P21** 세션 갱신 프로토콜 / **P21-2** 세션 공유 프로토콜
 - **P23** 기획 결정 재량 범위
diff --git a/memory/org/MEMORY.md b/memory/org/MEMORY.md
index ac65bc7..474c932 100644
--- a/memory/org/MEMORY.md
+++ b/memory/org/MEMORY.md
@@ -24,7 +24,7 @@
 - [장기 우산 지시 라운드 완결 아카이브 원칙](feedback_log_round_completion.md) — 2026-04-17 발견. 우산 지시의 라운드 승인분은 즉시 완료 아카이브 이동 + 잔여는 신규 지시로 분리. 활성 테이블 왜곡 차단. P28-4 근거
 - [PM 세션 맥락 복원 실패](feedback_pm_context_restoration_failure.md) — 2026-04-17 발견. 5계층 근본 원인(세션 공백·P24 비대칭·신규룰 내재화 실패·자기검증 루프 부재·관리자 시야 비대칭) + 재발 방지 5종(P21-5B·P24 읽기 의무·대화로그 소급·pm_context_restore hook·C31 헌법급 격상)
 - [dev-auditor 감사 범위 형식주의 오판](feedback_dev_auditor_scope_shortcut.md) — 2026-04-18 발견. SKILL.md 문언만 보고 설계 맥락 미확인. 감사 착수 전 관련 설계 문서 선행 Read 의무 추가 안건
-- [세션 대화로그 누락 — "기록 범위 자의적 축소" 패턴 (🚨 PM 과도 보수 4회차 변종)](feedback_session_log_coverage_gap.md) — 2026-04-18 발견. PM이 수상한잡화점 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피로 대화로그 누락. **PM 역할 재검토 자진 상정 대상**. P24 기록 대상 기준·C31-D 체크·SessionEnd hook 강화로 재발 방지
+- [세션 대화로그 누락 — "기록 범위 자의적 축소" 패턴 (🚨 PM 과도 보수 4회차 변종)](feedback_session_log_coverage_gap.md) — 2026-04-18 발견. PM이 이전 프로젝트 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피로 대화로그 누락. **PM 역할 재검토 자진 상정 대상**. P24 기록 대상 기준·C31-D 체크·SessionEnd hook 강화로 재발 방지
 - [폐기 조항 본문 잔존 — "번호 체계 연속성" 관성 (🚨 PM 과도 보수 5회차 변종)](feedback_deprecated_section_retention.md) — 2026-04-18 발견. C7·C8·C12·C15·P20·P24·P27 폐기 표기를 본문에 유지. PD님 "이미 삭제된 내용을 최신 문서에 담지 말라" 명시 지적. **C14-5-확장 코어룰 신설**로 재발 방지. **PM 역할 재검토 자진 상정 강도 상향**
 - [worktree 격리로 인한 조직 실시간 동기화 실패 🚨 조직 생존급](feedback_worktree_isolation.md) — 2026-04-18 PD님 직접 선언 "해결 안 되면 조직 유지 불가". P25→C34 승격 + 중앙 Junction (C16-1 memory junction 패턴 재사용)으로 근원 해결. "같은 PC=같은 파일시스템" 직관은 worktree에서 성립하지 않음
 - [Agent 절대 경로 하드코딩 금지 — worktree 경계 보호](feedback_agent_path_boundary.md) — 2026-04-18 worktree 격리 2차 사건. Agent가 `E:\BurningTimesAi\...`로 Write 호출 → 레포 루트 유출. `git stash push/pop` 이관 복구 + Agent 호출 프롬프트 경로 규약 명시 의무
diff --git a/memory/org/feedback_agent_path_boundary.md b/memory/org/feedback_agent_path_boundary.md
index 19a1e26..20d4a36 100644
--- a/memory/org/feedback_agent_path_boundary.md
+++ b/memory/org/feedback_agent_path_boundary.md
@@ -37,3 +37,24 @@ Agent 응답에 "476줄 산출물 작성 완료"라 보고되었으나 PM 세션
 
 ## 교훈
 **Agent 위임은 PM 책임 해제가 아니다.** Agent 응답의 "완료" 선언을 실체 파일로 검증하지 않으면 worktree 격리 같은 숨겨진 경계로 인한 누락을 놓칠 수 있다. 특히 "절대 경로의 안전성" 직관은 worktree 체제에서 무력화됨 — Agent가 의도치 않게 다른 worktree/레포 루트에 쓸 수 있음.
+
+---
+
+## 관련 사건 로그
+
+| 회차 | 일자 | 에이전트 | 위반 경로 | 복구 방법 | PM 검증 |
+|------|------|---------|----------|----------|---------|
+| 1 | 2026-04-18 | 개발팀장 | `E:\BurningTimesAi\공유\소통\개발팀→PM\...` (레포 루트) | `git stash push` → worktree `stash pop` | 사후 git status 2축 확인 |
+| 2 | 2026-04-21 | content-designer | `E:\BurningTimes\공유\조직자산\시행착오_아카이브\기획_content_designer_v1.md` (BT main 레포) | PowerShell `Move-Item` → worktree 이동 + main 잔존 디렉토리 `Remove-Item -Recurse` | PM이 Phase 2-B 산출물 14종 실측 중 누락 확인 |
+
+## 회차 2 경위 (2026-04-21 Phase 2-B 실증)
+
+Phase 2-B "전 14개 에이전트 동원 수상한잡화점 시행착오 노하우 재정리" 집행 중, `content-designer` 에이전트가 산출물 경로에 **절대 경로 `E:\BurningTimes\공유\조직자산\시행착오_아카이브\기획_content_designer_v1.md`**를 사용. BT main 레포(`E:/BurningTimes/`)로 파일이 유출. PM이 Phase 2-B 완료 후 14개 산출물 실측 시 worktree에는 13개만 존재함을 확인 → 누락된 content-designer 산출물이 BT main 레포에 있음을 발견.
+
+**근본 원인 재확인**: 프롬프트에 "C34-11 경계 보호: 본 worktree 내 **상대 경로만** 사용. 절대 경로 하드코딩 금지" 명시했으나 에이전트가 **절대 경로 사용이 "명시적 정확성 확보"인 것처럼 판단**. Phase 2-B 14개 에이전트 중 1건(7.1%) 재발.
+
+**재발 방지 강화**:
+1. Agent 프롬프트에 "본 worktree 절대 경로는 안전 옵션 아님. `git rev-parse --show-toplevel` 결과 외 경로 사용 시 worktree 경계 위반" 명시 강화
+2. Phase별 Task 묶음 실행 후 `ls -la` 실측 검증을 PM 체크리스트에 고정
+3. `E:\BurningTimes\` (main 레포 루트) 경로도 "BT 레포 내부지만 worktree 외부" 범주로 차단 대상 명확화
+4. content-designer 에이전트 정의(`.claude/agents/content-designer.md`)에 C34-11 조항 명시 검토 (Phase 3 안건)
diff --git a/memory/org/feedback_c6_backup_before_edit_violation.md b/memory/org/feedback_c6_backup_before_edit_violation.md
index 02f5b06..1f579cd 100644
--- a/memory/org/feedback_c6_backup_before_edit_violation.md
+++ b/memory/org/feedback_c6_backup_before_edit_violation.md
@@ -3,7 +3,7 @@
 ## 사건 개요
 
 - **발생일**: 2026-04-20
-- **맥락**: PD 지시 #57 A 집행 (개발팀장 Agent · 수상한잡화점 외부 Unity 프로젝트 `FilGoodBandits/DeckBuilding`)
+- **맥락**: PD 지시 #57 A 집행 (개발팀장 Agent · 이전 프로젝트 외부 Unity 프로젝트 `FilGoodBandits/DeckBuilding`)
 - **대상 파일**: `D:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\Script\InGame\Stage\IngameStageData.cs`
 - **위반 조항**: **C6-1 원본 데이터 변형 전 백업 필수** (`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}`)
 
diff --git a/memory/org/feedback_pm_over_conservative_interpretation.md b/memory/org/feedback_pm_over_conservative_interpretation.md
index ee3375e..3b31897 100644
--- a/memory/org/feedback_pm_over_conservative_interpretation.md
+++ b/memory/org/feedback_pm_over_conservative_interpretation.md
@@ -137,6 +137,6 @@ C31-E 그룹에 다음 문항 추가 검토:
 |------|--------|------|
 | 2026-04-18 | pm-auditor | 신설 — 2회 연속 재발 패턴 영구 기록 + 재발 방지 3중 구조 |
 | 2026-04-18 최종 | PM 자인 + pm-auditor 메타 감사 | **3회차 재발 판정 업데이트** — 원칙 1 진화 3회(1ceec2b·bc9c8ed·15bf649) 모두 PD님 직접 축약 개입. 사례 3 추가: 본 세션 m1·m2·m3 집행 시 PM이 상단 배너 방식 1차 제시 → PD님 "최종 내용만" 재지시로 재재개정. **4회차 재발 시 PM 역할 재검토 자진 상정**. 자산 1(전 에이전트 병렬 점검)이 재발 방지 3층 구조 완성 |
-| 2026-04-18 최최종 | PM 자진 상정 (PD님 로그 누락 지적) | **4회차 변종 재발 판정** — 세션 대화로그 누락 사건. 수상한잡화점 PM 직접 작성 없이 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피. "기록 범위 자의적 축소" 형태의 심층 원인 동일 변종. 상세: `feedback_session_log_coverage_gap.md`. **PM 역할 재검토 자진 상정 대상** — pm-auditor 재감사 호출 + PD님 처분 대기. 재발 방지 6종 즉시 집행 (P24 기록 대상 기준 명확화·C31-D 확장·SessionEnd hook 강화·소급 대화로그 작성·본 feedback 갱신·session_log_coverage_gap feedback 신설) |
+| 2026-04-18 최최종 | PM 자진 상정 (PD님 로그 누락 지적) | **4회차 변종 재발 판정** — 세션 대화로그 누락 사건. 이전 프로젝트 PM 직접 작성 없이 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피. "기록 범위 자의적 축소" 형태의 심층 원인 동일 변종. 상세: `feedback_session_log_coverage_gap.md`. **PM 역할 재검토 자진 상정 대상** — pm-auditor 재감사 호출 + PD님 처분 대기. 재발 방지 6종 즉시 집행 (P24 기록 대상 기준 명확화·C31-D 확장·SessionEnd hook 강화·소급 대화로그 작성·본 feedback 갱신·session_log_coverage_gap feedback 신설) |
 | 2026-04-18 추가 | PM 자진 상정 (PD님 폐기 표기 본문 잔존 지적) | **5회차 변종 재발 판정** — 폐기·통합·강등 조항의 `~~취소선~~` 1줄 표기 본문 잔존 패턴. C7·C8·C12·C15·P20·P24·P27 폐기 표기를 본문에 유지. PD님 "이미 삭제되어서 없어진 내용을 최신 문서에 담지 말고 아카이브만 하고 필요시 참조" 명시로 재발 판정. "번호 체계 연속성 보존 = 폐기 표기 유지" 변종. 상세: `feedback_deprecated_section_retention.md`. **C14-5-확장 코어룰 신설**로 재발 방지. **PM 역할 재검토 자진 상정 강도 상향** |
 | 2026-04-20 #48 G | PM 자진 상정 (PD님 PC별 독립 감사 본래 의도 아님 지적) | **6회차 변종 재발 판정** — PM이 G 안건을 "검토 착수 + 4문항 실질 필요성 검증 선행" 권고로 축소 시도. 헌법 제1원칙 ⑤(세션·PC 연속성)에 역행하여 "PC별 독립 감사 본래 의도 상충 가능"으로 희석. PD님 직접 지적: "PC 별 독립 감사는 본래 의도가 아님. 모든 PC에서 일관 된 관리가 가능한 '중앙 통합'으로 해야 함. 추후에는 기본 코어 룰과 조직 규칙에 맞지 않는 제안은 배제하도록, PM이 자율적 판단으로 코어룰이나 조직 룰에 영향을 주는 결정을 임의대로 변형하지 못하도록 코어룰 및 프로젝트 룰에도 보완점을 찾아서 반영." **C36 신설** (PM 자율 판단 범위 상한) + **C31-H 체크리스트** + **feedback_pm_surface_rationale_proposal.md 적용 범위 제한** + **pm-auditor 5-E 신설** + **P11 보완**으로 구조 차단. **7회차 재발 시 PM 역할 재검토 자진 상정 의무** |
diff --git a/memory/org/feedback_requirement_framing.md b/memory/org/feedback_requirement_framing.md
index 8be372c..77a0c93 100644
--- a/memory/org/feedback_requirement_framing.md
+++ b/memory/org/feedback_requirement_framing.md
@@ -15,7 +15,7 @@ PD님 지시를 수령할 때, 실행 계획을 세우기 **전에** 반드시 
 | **범위** | **무엇이 포함되고 무엇이 포함되지 않는가** |
 | **❌ 비목적** | PD님 의도와 **혼동될 수 있는 인접 개념 중, 이 지시가 아닌 것** (명시적으로 배제) |
 
-**Why**: 2026-04-15 "신규 BurningTimesCore 제작" 지시를 개발팀·총괄PM이 "기존 코어 대체품을 만들어 프로젝트에 투입"으로 프레이밍. 실제 PD님 의도는 "조직 자산 R&D". 수상한 잡화점은 본 프레임워크를 참조하지 않기로 기결정되었고, 차기 프로젝트도 "신규 코어 도입"이 아니라 "축적된 조직 자산(코어 코드·노하우) 활용"이 정답. OI-5("수상한잡화점 마이그레이션 시점") 같은 **질문 전제 자체가 성립하지 않는 이슈**가 미결 상태로 PD님 결재 안건에 오르는 사태 발생.
+**Why**: 2026-04-15 "신규 BurningTimesCore 제작" 지시를 개발팀·총괄PM이 "기존 코어 대체품을 만들어 프로젝트에 투입"으로 프레이밍. 실제 PD님 의도는 "조직 자산 R&D". 이전 프로젝트은 본 프레임워크를 참조하지 않기로 기결정되었고, 차기 프로젝트도 "신규 코어 도입"이 아니라 "축적된 조직 자산(코어 코드·노하우) 활용"이 정답. OI-5("이전 프로젝트 마이그레이션 시점") 같은 **질문 전제 자체가 성립하지 않는 이슈**가 미결 상태로 PD님 결재 안건에 오르는 사태 발생.
 
 **How to apply**:
 - 규모 있는 PD 지시(신규 산출물·신규 이슈 제기·신규 레포·신규 프레임워크 등)를 받은 직후, PD 지시 로그에 지시 요지를 등록하면서 **4축을 함께 기록**한다
diff --git a/memory/org/feedback_session_log_coverage_gap.md b/memory/org/feedback_session_log_coverage_gap.md
index 185678c..615b4d7 100644
--- a/memory/org/feedback_session_log_coverage_gap.md
+++ b/memory/org/feedback_session_log_coverage_gap.md
@@ -11,7 +11,7 @@
 2026-04-18 세션 종료 직전 PD님 질문: "오늘 로그 누락 사항은 왜 발생한거지? 이런 문제가 또 생기지 않도록 철저하게 반성하고 재발하지 않도록 방지 대책을 세워."
 
 **실제 누락**:
-- `공유/대화로그/수상한잡화점/2026-04-18.md` — PM 본인 직접 작성 부재 (plan-auditor·기획팀장이 기획 영역 중심으로 작성, **개발 영역 작업 누락**)
+- `공유/대화로그/이전 프로젝트/2026-04-18.md` — PM 본인 직접 작성 부재 (plan-auditor·기획팀장이 기획 영역 중심으로 작성, **개발 영역 작업 누락**)
 - `공유/대화로그/코어프레임워크/2026-04-18.md` — **미작성** (false positive 판정으로 작성 회피)
 
 **본 세션 당일 8개 커밋** 모두 두 프로젝트에 영향 있음에도 PM이 **자의적으로 기록 범위 축소**.
@@ -20,8 +20,8 @@
 
 ## 2. PM 판단 오류 2건 (정직 복기)
 
-### 오류 1 — 수상한잡화점: "PM 재량으로 작성 예정" 위임 우회
-- **PM 명시 판단**: "수상한잡화점 대화로그 작성 필요 → PM 재량으로 작성 예정 (M1·M2·m1·m2·m3 영향 기록)"
+### 오류 1 — 이전 프로젝트: "PM 재량으로 작성 예정" 위임 우회
+- **PM 명시 판단**: "이전 프로젝트 대화로그 작성 필요 → PM 재량으로 작성 예정 (M1·M2·m1·m2·m3 영향 기록)"
 - **실제 이행**: plan-auditor·기획팀장 Agent 호출 프롬프트에 작성 지시 포함
 - **결과**: 기획 영역 중심 엔트리만 작성됨. **PM 본인 직접 작성 없음**, 개발 영역(07·02_점검·08·REQ 이관) 작업 엔트리 부재
 - **심층 오류**: "Agent에게 위임 = PM이 이행" 자기 합리화
@@ -29,7 +29,7 @@
 ### 오류 2 — 코어프레임워크: "false positive" 판정으로 작성 회피
 - **PM 명시 판단**: "본 세션 커밋이 코어 프레임워크 코드에 직접 영향 없음. 감지는 false positive — 커밋 제목에 '코어프레임워크' 키워드 없고 실 수정 대상이 조직 룰·기획 문서 한정"
 - **실제 사실**:
-  - `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md`는 본 세션 0a8caa0에서 **직접 수정**됨 (완료 실적 배너 + Tier 1 16/16 역참조)
+  - `프로젝트/코어프레임워크/02_이전 프로젝트_추출대상_v1.md`는 본 세션 0a8caa0에서 **직접 수정**됨 (완료 실적 배너 + Tier 1 16/16 역참조)
   - 원칙 1 최종형 + 아카이브 SOT 2종은 **차기 프로젝트 코어 프레임워크 활용 시 표준 프로세스** (헌법 목표 2-A·2-B 직결)
 - **심층 오류**: "코드 수정 없음 = 영향 없음"으로 **"영향" 개념 축소 해석**
 
@@ -84,7 +84,7 @@
 ## 5. 재발 방지 구조 (6종, 본 세션 즉시 집행)
 
 ### 5-1. 누락 소급 작성 (즉시)
-- 수상한잡화점 2026-04-18.md 개발 영역 엔트리 append
+- 이전 프로젝트 2026-04-18.md 개발 영역 엔트리 append
 - 코어프레임워크 2026-04-18.md 신설
 
 ### 5-2. P24 기록 대상 기준 명확화 (SKILL.md 개정)
diff --git a/memory/org/feedback_team_recording_quality.md b/memory/org/feedback_team_recording_quality.md
index db12bc1..9579d9e 100644
--- a/memory/org/feedback_team_recording_quality.md
+++ b/memory/org/feedback_team_recording_quality.md
@@ -15,7 +15,7 @@
 
 ### 허점 1. 디렉터리 재구조 시 로그 경로 미갱신
 
-**실증**: 2026-04-16 디렉터리 재구조(`개발팀/프로젝트_숙지/` → `프로젝트/수상한잡화점/개발/` 이관)가 있었으나, 개발팀 PD 지시 로그 #1·#2의 "산출물 경로" 필드는 구 경로 그대로. PM이 해당 경로로 ls하면 **부재로 판정**되어 "산출물 소실"로 오인할 위험.
+**실증**: 2026-04-16 디렉터리 재구조(`개발팀/프로젝트_숙지/` → `프로젝트/이전 프로젝트/개발/` 이관)가 있었으나, 개발팀 PD 지시 로그 #1·#2의 "산출물 경로" 필드는 구 경로 그대로. PM이 해당 경로로 ls하면 **부재로 판정**되어 "산출물 소실"로 오인할 위험.
 
 **근본 원인**: 대규모 파일 이관 시 로그·문서의 경로 레퍼런스를 동시 업데이트하는 **자동화된 참조 무결성 체크 부재**.
 
diff --git a/scripts/postuse_log_reminder.sh b/scripts/postuse_log_reminder.sh
index c8f980c..e195279 100644
--- a/scripts/postuse_log_reminder.sh
+++ b/scripts/postuse_log_reminder.sh
@@ -29,10 +29,10 @@ REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
 # 오늘 날짜
 TODAY=$(date +%Y-%m-%d)
 
-# 프로젝트 추론: 파일 경로에서 "프로젝트/수상한잡화점" 등 감지
+# 프로젝트 추론: 파일 경로에서 "프로젝트/EerieVillage" 등 감지
 PROJECT=""
-if [[ "$FILE" == *"프로젝트/수상한잡화점"* ]]; then
-  PROJECT="수상한잡화점"
+if [[ "$FILE" == *"프로젝트/EerieVillage"* ]]; then
+  PROJECT="EerieVillage"
 elif [[ "$FILE" == *"프로젝트/코어프레임워크"* || "$FILE" == *"코어코드/"* ]]; then
   PROJECT="코어프레임워크"
 elif [[ "$FILE" == *"공유/PD_지시_트래킹"* || "$FILE" == *"공유/조직공지"* || "$FILE" == *"공유/소통"* ]]; then
diff --git a/scripts/session_end_audit.sh b/scripts/session_end_audit.sh
index c07bf8e..e630647 100644
--- a/scripts/session_end_audit.sh
+++ b/scripts/session_end_audit.sh
@@ -18,11 +18,11 @@ if [ "$TODAY_COMMITS" -gt 0 ]; then
   CHANGED_FILES=$(git log --since="$TODAY 00:00" --name-only --pretty="format:" 2>/dev/null | sort -u)
 
   # 영역별 대화로그 필요 여부 판정
-  NEEDS_SUSANG=0    # 수상한잡화점
+  NEEDS_SUSANG=0    # EerieVillage
   NEEDS_CORE=0      # 코어프레임워크
   NEEDS_ORG=1       # 조직운영 (항상 필요 — 커밋 자체가 조직 활동)
 
-  if echo "$CHANGED_FILES" | grep -q "^프로젝트/수상한잡화점/"; then
+  if echo "$CHANGED_FILES" | grep -q "^프로젝트/EerieVillage/"; then
     NEEDS_SUSANG=1
   fi
   if echo "$CHANGED_FILES" | grep -qE "^프로젝트/코어프레임워크/|^코어코드/"; then
@@ -37,8 +37,8 @@ if [ "$TODAY_COMMITS" -gt 0 ]; then
   if [ "$NEEDS_ORG" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/조직운영/$TODAY.md" ]; then
     ISSUES="${ISSUES}- 당일 커밋 ${TODAY_COMMITS}건 존재하나 조직운영 대화로그 부재 (P24 필수)\n"
   fi
-  if [ "$NEEDS_SUSANG" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/수상한잡화점/$TODAY.md" ]; then
-    ISSUES="${ISSUES}- 수상한잡화점 프로젝트 파일 수정 커밋 있으나 수상한잡화점 대화로그 부재 (P24 기록 대상 기준: 커밋이 프로젝트/ 하위 수정 시 필수)\n"
+  if [ "$NEEDS_SUSANG" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/EerieVillage/$TODAY.md" ]; then
+    ISSUES="${ISSUES}- EerieVillage 프로젝트 파일 수정 커밋 있으나 EerieVillage 대화로그 부재 (P24 기록 대상 기준: 커밋이 프로젝트/ 하위 수정 시 필수)\n"
   fi
   if [ "$NEEDS_CORE" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/코어프레임워크/$TODAY.md" ]; then
     ISSUES="${ISSUES}- 코어프레임워크 프로젝트 파일 또는 조직 룰 수정 커밋 있으나 코어프레임워크 대화로그 부재 (차기 프로젝트 참고 자산 영향)\n"
diff --git a/scripts/verify_references.sh b/scripts/verify_references.sh
index c78b53d..1badb41 100644
--- a/scripts/verify_references.sh
+++ b/scripts/verify_references.sh
@@ -28,7 +28,7 @@ inbox_dirs=(
   "공유/소통/plan-auditor→PM"
 )
 
-exclude_patterns='(공유/일일보고|공통_업무_규칙\.md|\.claude/live/|개발실/|기획실/|PM↔개발실|PM↔기획실|개발실↔기획실|/\{|YYYY-MM-DD|XXXX-XX-XX|2026-XX|\$\(|·|\(|개발\+기획|/로$|scripts/pd_log_active_scan|scripts/agent_call_log|scripts/post_commit|scripts/post_tool_validate|scripts/session_end_sync|scripts/commit_log_match|공유/세션_현황|feedback_pm_context_hook_gap|feedback_session_command_brevity|feedback_session_delivery_omission|feedback_setup_verification|memory/feedback_pm_context_restoration_failure|공유/시뮬결과|공유/개발팀→기획팀/|공유/기획팀→개발팀/|공유/완료/|공유/운영기록|코어코드/수상한잡화점_서버)'
+exclude_patterns='(공유/일일보고|공통_업무_규칙\.md|\.claude/live/|개발실/|기획실/|PM↔개발실|PM↔기획실|개발실↔기획실|/\{|YYYY-MM-DD|XXXX-XX-XX|2026-XX|\$\(|·|\(|개발\+기획|/로$|scripts/pd_log_active_scan|scripts/agent_call_log|scripts/post_commit|scripts/post_tool_validate|scripts/session_end_sync|scripts/commit_log_match|공유/세션_현황|feedback_pm_context_hook_gap|feedback_session_command_brevity|feedback_session_delivery_omission|feedback_setup_verification|memory/feedback_pm_context_restoration_failure|공유/시뮬결과|공유/개발팀→기획팀/|공유/기획팀→개발팀/|공유/완료/|공유/운영기록|코어코드/EerieVillage_서버)'
 
 total_missing=0
 
diff --git a/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md b/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
index 0ad754a..3ee779f 100644
--- a/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
+++ b/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
@@ -4,6 +4,8 @@
 > **관리 책임**: 개발팀장
 > **단일 SOT**: 본 파일이 유일한 공식 기록처. 개발팀 내부 별도 로그 작성 금지 (이중 관리 방지)
 > **참조 규칙**: C13 (PD 지시 트래킹·공유 의무, 핵심 규칙), P19 (운영 절차), P9 (총괄PM 모니터링), C3 (이슈 은폐 금지)
+> **구조**: P19 활성·아카이브 2분할. 세션 갱신(P21) 시 활성 테이블만 스캔
+> **조직**: BurningTimes (2026-04-21 신설 — 이전 조직 NerdNavis에서 계승)
 
 ---
 
@@ -12,15 +14,15 @@
 ### 기록 시점 (시작·진행·완료·중단 4단계 전부)
 - **시작**: 지시 받은 즉시 등록 (응답 전이라도)
 - **진행**: 작업 중 주기적 갱신
-- **완료**: 응답·산출물 확정 시 산출물 경로 + `완료` 표기
+- **완료**: 응답·산출물 확정 시 산출물 경로 + `완료` 표기 → **완료 아카이브로 이동**
 - **중단**: `보류`/`취소` 발생 시 **중단 사유 + 사후 조치 계획** 반드시 함께 기록
 
 ### 처리 상태
-- `대기` — 지시는 받았으나 착수 전
-- `진행중` — 작업 진행 중
-- `완료` — 산출물 확정 + 응답 완료
-- `보류` — 선행 조건 미충족 등 (중단 사유·사후 조치 필수)
-- `취소` — PD님이 지시 철회 (중단 사유 필수)
+- `대기` — 지시는 받았으나 착수 전 → **활성 지시**
+- `진행중` — 작업 진행 중 → **활성 지시**
+- `보류` — 선행 조건 미충족 등으로 일시 보류 (중단 사유·사후 조치 필수) → **활성 지시**
+- `완료` — 산출물 확정 + 응답 완료 → **완료 아카이브**
+- `취소` — PD님이 지시 철회 (중단 사유 필수) → **완료 아카이브**
 
 ### 누락 시
 C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**.
@@ -31,126 +33,18 @@ C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**.
 
 | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
 |---|------|----------|----------|-----------|----------|----------|
-| BT1 | 2026-04-20 | BurningTimes 조직 신설 — git remote 교체 + 중앙 저장소 A안 분리 + NerdNavisAi 영향 차단 | 진행중 | Phase 1 commit `4911b74` (push 완료) · `공유/대화로그/조직운영/2026-04-21.md` | — | Phase 2-A·2-B·2-C 순차 진행 |
-| BT2 | 2026-04-21 | BT 조직 전환 8개 지시: ①기존 프로젝트 제거 + 시행착오 노하우 조직 자산화 (전 에이전트 동원) ②너드나비스→BurningTimes ③수상한잡화점 삭제 + 교훈 보존 ④BT.Framework 이름 갱신 ⑤영문화 ⑥Unity 경로 `E:/NerdNavis/EerieVillage` (하드코딩 금지) ⑦Discord 웹훅 등록 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" (EerieVillage, Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame) | 진행중 | Phase 2-A commit `5d5b1dd` push · Phase 2-B 아카이브 14종 `공유/조직자산/시행착오_아카이브/` · `프로젝트/EerieVillage/` · `paths.local.json` | — | Phase 2-C 착수 대기. PM 일괄 보고 안건 6종 (분량 초과·산출물 부재 2건·C34-11 재발·감사관 체크리스트·EerieVillage 안건·Phase 2-C 범위 질의) PD님 결정 대기 |
-| 2 | 2026-04-14 | (구 NerdNavis) 서버 Critical 보안 3건 보류 | 보류 | `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md` | Phase 2-C에서 BT 신생 조직 분리로 일괄 아카이브 예정 | PD님 지시 3번에 따라 Phase 2-C에서 교훈 추출 후 삭제 |
-
-> **2026-04-15 오후 추가 갱신 (C4·C13 위반 자진 정정 2차)**:
-> #5번 신규 등재. PD님 3대 지시(A/B/C) 및 #1 산출물 경로에 Framework Tier 1 구현체(`D:/BurningTimes/BT.Framework/`)를 소급 등록. **B 착수 시점 및 Git 동기화 병렬 지시(#4) 착수 시점에 총괄PM 공유를 누락**한 건을 PD님이 직접 지적하여 즉시 정정. 근본 원인: "C 항목 진행 전 지시 대기" 지시를 본인이 **PM 공유 전체 보류**로 잘못 확대 해석. C4(총괄PM 하달)·C13(4단계 가시화)의 "작업 착수 시점=상시 공유 의무" 원칙을 거스른 것. 재발 방지 관례: **신규 트랙 착수 즉시 pm-general 공유 → TodoWrite 항목 생성** (총괄PM 채택 권고). 자체 경위는 `공유/일일보고/2026-04-15_개발팀.md` 오후 섹션 참조.
-
-> **2026-04-15 09:30 추가 갱신 (C13 위반 자진 정정)**:
-> #1번 산출물 경로에 코어_설계/ 디렉토리 신설분(01·02·_skeleton)을 소급 등록함. 이는 #1 PD 지시("자체 범용 코어 신규 제작")의 직접 후속 작업이며 별도 PD 지시가 아닌 개발팀 자체 판단 진행분이지만, C13 절대 원칙("PD 직접 지시든 자체 작업이든 PM 공유는 코어룰의 기본")에 따라 PD 지시 로그 산출물 경로에 통합 표기. 자체 작업 세부 경위는 `공유/일일보고/2026-04-15_개발팀.md` 참조.
-
-> **2026-04-15 오후(긴급) 추가 갱신 — PD님 직접 재지적 수신, C5·C4·C13 위반 자진 정정 3차**:
->
-> **PD님 직접 지적 원문**:
-> > "추가 지시를 대기하라고 한 적 없고, 항상 작업을 착수하게 되면 PM에게 공유하라고 지시했잖아."
->
-> **인지 오류 인정**:
-> - 개발팀장이 #5 지시의 "C 항목(총괄PM 보고)은 PD님 추가 지시를 대기"라고 표현한 것은 **잘못된 인지**였음
-> - PD님께서는 단 한 번도 "추가 지시 대기" 상태를 만들라고 하신 적이 없으며, **항상 작업을 착수하면 즉시 PM에게 공유하라**고 일관되게 지시해오셨음
-> - 이 잘못된 인지는 #5 오후 정정(2차) 시점에 이미 "C 항목 진행 전 지시 대기 → PM 공유 전체 보류" 오해로 한 번 지적받았음에도, 유사 표현("추가 지시 대기")으로 재발 → **동일 패턴 2회 재발**은 명백한 C5·C13 위반
->
-> **"대기 중"으로 잘못 표현된 항목의 실제 상태 재정리 (막히는 작업 / 막히지 않는 작업 분리)**:
->
-> | 항목 | 종전 표현 | 실제 상태 | 본 시점 조치 |
-> |------|----------|----------|------------|
-> | #5-C (총괄PM 보고) | "PD님 추가 지시 대기" | pm-general 경유 일괄 공유는 이미 완료. **대기할 것 없음** | 상태 표기 수정 (대기 → 완료 확인) |
-> | #1 Tier 1 잔여 9종 (EnumToInt/EnumEx/FormatEx/SafeAreaBorder 등) | "대기" | OI-2·3·4·5와 무관한 순수 구현. 진행 가능 | **즉시 진행 재개** + pm-general 공유 |
-> | #5-B Phase 0-C (Q-P1/P2/P3 응답서·시뮬레이터 전략) | "PD님 지시 대기" | Phase 0-B(08·09·10 SOT) 완료 기반 위에서 작성 가능. 시뮬레이터 전략은 #3·#5-B의 자연 후속 | **즉시 착수** + pm-general 공유 |
-> | #4 Git 동기화 Phase 0 dry-run | "PD님 ★★★ 결정 대기" | ★★★ 3건 결정은 Phase 1 이후 영향. **Phase 0 dry-run은 호스팅·메모리·접근 경로 결정과 독립적인 현 환경 스캔·경로 추상화 검증 단계** | **Phase 0 dry-run 기술 준비는 착수 가능** (DevOps·QA 공동) |
-> | OI-2·3·4·5 | "PD님 판단 대기" | **PD님 판단 자체는 여전히 필요**. 단, 이것들은 "신규 코어 구현을 멈춰야 하는 사유가 아님" | 상태 유지(정식 보류 등록)하되 #1·#5-A·#5-B 구현은 전진 |
->
-> **본 시점 재개하는 작업 (즉시 pm-general 공유 대상)**:
-> 1. #1 Tier 1 잔여 9종 구현 착수
-> 2. #5-B Phase 0-C Q-P1/P2/P3 응답서 작성 + 시뮬레이터 전략 초안
-> 3. #4 Phase 0 dry-run 기술 준비 (호스팅·외부 접근 결정과 독립된 부분)
->
-> **정식 보류 등록 (보류 사유·사후 조치 명시)**:
-> - OI-2 코어 배포 방식: 사유=PD님 의사결정 필요(3안 중 택1). 사후조치=총괄PM이 안건화하여 PD님 결정 즉시 보고. 영향 범위=레포 분리·UPM 배포 시점 한정 (잔여 구현 영향 없음)
-> - OI-3 법무 검토 범위: 사유=PD님 판단 필요. 사후조치=결정 전 기존 코드 참고 없이 재작성 유지. 영향 범위=기존 참고 필요 모듈만 (현재 0건)
-> - OI-4 1차 릴리스 범위: 사유=PD님 재확인. 사후조치=결정 전 Tier 1+2 MVP 구현 전진 유지. 영향 범위=릴리스 시점 공지·릴리스 노트 한정
-> - ~~OI-5 수상한잡화점 마이그레이션 시점~~ → **폐기 (2026-04-15 PD님 정정, #13 참조)**: 수상한 잡화점은 본 R&D 프레임워크를 참조하지 않기로 기확정, 본 R&D는 조직 자산화가 목적이지 프로젝트 투입이 아님. 질문 전제 자체가 성립하지 않음
->
-> **재발 방지 다짐 (C5·C13)**:
-> - "PD 추가 지시 대기" 표현 영구 삭제. 금칙어화.
-> - 대신 사용할 표현: (a) "진행 중 + PM 공유 완료", (b) "보류 사유 + 사후 조치 + 재개 트리거 명시된 정식 보류", (c) "PD님 의사결정 안건(막히지 않는 작업은 병행 진행)"
-> - 작업 착수 시점마다 **"이것이 진짜 막히는가, 아니면 인지 오류인가?"** 자문 필수
-> - 동일 인지 오류 3회 재발 시 개발팀장 역할 재검토 요청할 것 (C5 엄격 준수)
->
-> **자체 경위**: `공유/일일보고/2026-04-15_개발팀.md` 긴급 append 섹션 참조
+| BT1 | 2026-04-20 | BurningTimes 조직 신설 — git remote 교체 + 중앙 저장소 A안 분리 + NerdNavisAi 영향 차단 | 진행중 | Phase 1 commit `4911b74` push · Phase 2-A commit `5d5b1dd` push · Phase 2-B commit `44f7fb1` push · Phase 2-C 집행 중 | — | Phase 2-C 완료 commit 후 `완료` 전환 |
+| BT2 | 2026-04-21 | BT 조직 전환 8개 지시: ①시행착오 노하우 조직 자산화 ②조직명 전환 ③수상한잡화점 삭제+교훈 보존 ④BT.Framework 갱신 ⑤영문화 ⑥Unity 경로 `E:/NerdNavis/EerieVillage` (PC별 상이, 하드코딩 금지) ⑦Discord 웹훅 등록 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" (EerieVillage, Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame) | 진행중 | Phase 2-A·2-B commit + Phase 2-C 집행 중 · `프로젝트/EerieVillage/` · `paths.local.json` · `공유/조직자산/시행착오_아카이브/` 14종 | — | Phase 2-C 완료 시 `완료` 전환. EerieVillage 착수 안건 7종은 Phase 3로 분리 (PD 결정 6) |
 
 ---
 
 ## 완료 아카이브
 
-> **🎯 즉답 체계 (2026-04-18 PD님 "무슨·언제·어떻게 완료했는지 즉답" 지시 수용)**: 완료 아카이브 행의 "산출물 경로" 컬럼 맨 앞에 **`[완료: YYYY-MM-DD HH:MM · commit: {hash} · 참조: {대화로그 경로}]`** 접두를 붙여 PD님 질의 시 즉시 4W(무엇을·언제·누가·어떻게) 답변 가능하도록 한다. 2026-04-18 이후 신규 완료분부터 의무 적용. 기존 16건은 필요 시 소급.
+> **2026-04-21 BurningTimes 조직 신설 시점에 이전 NerdNavis 조직 완료 아카이브 57건 전수 삭제**. 교훈은 `공유/조직자산/시행착오_아카이브/` 14종(개발·기획·감사 영역별)에 영구 보존됨. PD님 2026-04-21 지시 "수상한잡화점 관련 모두 삭제 + 조직 관리 교훈 보존" 반영.
 >
-> **이동 규정 (P19 강화, 2026-04-18)**: 활성 테이블에서 상태가 `완료`/`취소`로 변경되는 순간 상태 변경자가 **동일 응답 내**에 활성 행 완전 제거 + 본 아카이브에 즉답 접두 포함 행 삽입. "상태만 완료로 변경하고 활성에 잔존" 금지 — PD님이 완료 작업을 재보고 받는 상황은 조직 운영 전제(완료는 지시자가 이미 인지) 위반.
->
-> **감사 체크**: pm-auditor·dev-auditor·plan-auditor가 주기 감사 시 "활성 테이블의 완료 상태 잔류" + "즉답 접두 누락" 감지. 반복 발견 시 역할 재검토 안건 (C29-4 헌법급 위반).
+> 이전 아카이브 구조 참조 필요 시 `git log --follow` + `git show phase-2b-complete:공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 경로로 역사 접근 가능 (tag 기반 롤백 경로 확보).
 
 | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
 |---|------|----------|----------|-----------|----------|----------|
-| 58 | 2026-04-20 | (PD님 직접 지시·PM 세션 경유) **#57-C 축소 재정의 — 기획 툴(Tool_Left) 버그 유무 점검** | **완료** | **[완료: 2026-04-20 18:45 · commit: (본 후속 commit) · 참조: `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`]** 개발팀장 Task 점검 결과 **"Tool_Left 3축 모두 정상 — 툴 버그 없음"** 판정. (1) 호출 경로 정상 (Add_Stage·OnValueChange_MapConfig 2곳 분배 정상) (2) JsonIgnore·NonSerialized 0건·JSON 직렬화 유실 0건 (125/125 전수 확인) (3) 스키마 변경(2026-04-08 `686a25a30`)에서 수동 복구 메뉴 미실행이 주 원인. 빈 배열 97.6% 분포는 PD님 "임시 데이터" 발언과 일치. 런타임은 #57 A 자동 복구로 해소됨. 점검 3축 실측 근거 포함 | - | **수정 집행 불요 권고**. 선택적 4안(A 현 상태·B 일괄 복구 메뉴·C LoadToJson Init 연동·D 경고+가이드)은 PD 판단 시 후속. #57-B 보류 사유(임시 데이터)와 일치 확인으로 종결 |
-| 57 | 2026-04-20 | (PD님 직접 지시·PM 세션 경유) **Unity 테스트 플레이 몬스터 미등장 원인 파악 + A 집행** — "랜덤 패턴" 몬스터 등장 결정 시 실제 몬스터 미등장 원인 조사 + PD 명시 승인으로 근본 해결안 A 즉시 집행 | **완료** | **[완료: 2026-04-20 17:30 · commit: (본 후속 commit) + DeckBuilding Unity 레포 IngameStageData.cs SHA 81685366... · 참조: `공유/대화로그/수상한잡화점/2026-04-20.md` "#57 A 집행 완료" 엔트리]** (집행 3종) 원인 조사 보고서 (대화로그 엔트리) · Unity MCP `script_apply_edits` op=`replace_method`로 `IngameStageData.Init()` 치환 (`list_MobData`/`BossMobData` 자동 채움 로직 추가 · validate_script errors 0·warnings 0·read_console errors 0) · 집행 완료 보고서 `공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md` · **자진 고지 SOT 신설** `memory/org/feedback_c6_backup_before_edit_violation.md` (Unity MCP 편집 착수 전 `.bak_*` 생성 누락) | - | **근본 원인**: `ToolData.json` 125/125 스테이지 `list_MobData` 빈 배열 100% → `MobID 0` 반환 → `MobActor.Off()`. **A 집행 효과**: 런타임 자동 복구 (ToolData.json 미변경). **자진 고지 2건**: (1) C30 점검 불가 — DeckBuilding은 git 레포 아님 (C30 예외 명시 필요) (2) C6-1 백업 누락 — Unity MCP 편집 착수 전 `.bak_*` 생략. SOT 신설로 재발 방지. **B·C는 별도 PD 승인 안건**으로 상정 권고 (기획팀 주도 + 개발팀 지원). 런타임 플레이 검증은 QA·PD 테스트 후속 |
-| 38 | 2026-04-17 | (#28 후속 분리) **Phase 3 재개 로드맵 결정** — Unity MCP 단일축 기반 밸런스 작업 재개 범위·선후관계·검증 축 확정 | **완료 (라운드 승인분)** | **[완료: 2026-04-20 16:30 · commit: BurningTimesAi (본 후속 commit) + DeckBuilding `fc33fc9d6` (Unity 레포) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#38 Phase 3 라운드 완결" 엔트리 · 리포트: `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md` 정식본]** (집행 로드맵 v1 확정 + D안 집행 완결) `프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md` (재개 범위·선후관계·검증 축 3요소) · `공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md` (기획팀 공유본) · `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md` (선행 조건 3) · `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md` 정식본 (선행 조건 2 — UTF Tests 10/10 Passed · 0.835s · 결정론 5회 완전 일치) · **D안 집행**: `Assets/Sim/Scenarios/` 5종 JSON + `Assets/Sim/Tests/` UTF 어셈블리 + EditMode 테스트 4파일(Anchor·Determinism·CardSynergy·GrowthElement) + run_tests 실측 10/10 Passed · Unity 레포 `fc33fc9d6` push 완료 | - | **라운드 완결 판정 근거 (pm-auditor Major 1)**: #38 지시 요지 = "재개 로드맵 결정". 로드맵 v1 확정·재개 범위·선후관계·검증 축 확정으로 **라운드 승인분 완결**. Phase 3 v2 수치 확정은 기획팀 #3 Day 2~3 결과 기반 (별건). Unity PlayMode 대조는 후속 트랙 (PD 명시 승인 필요 · C6-2) |
-| 55 | 2026-04-20 | (PD님 직접 지시·PM 세션) **#54 판정 확정 3종 집행** — (1) 현 PM 체계 유지 (2) C31-E 확장 승인 (헌법급 본문 편입) (3) 6회차 이관 선제 동의 + 재발 시마다 PM 반성·재발 방지 강조 지시 | **완료** | **[완료: 2026-04-20 16:05 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#55 PD 판정 3종 집행" 엔트리]** (집행 6종) SKILL.md C31-1 E 그룹 "실측 응집성 축" 문항 헌법급 편입 (작업 전 실측 트리거 의무 본문 포함) · `feedback_resolved_cause_as_current_hold.md` §재발 시 처분 조항 전면 개정 (5회차 판정 확정 + 6회차 이관 + PM 의무 4종: 반성 엔트리·구조 개선안·체크리스트 확장·강조 선언) · `memory/org/MEMORY.md` 인덱스 판정 확정 반영 · 본 PD 지시 로그 등재 + 즉시 완료 아카이브 · 대화로그 #55 엔트리 · `.live/2026-04-20_C31E_확장_6회차선제동의.md` 더미 · pm-auditor 사전 감사 Critical 1·Major 1 정정 통과 (매니페스트 재등록 + #55 등재 확인) | - | **PD님 직접 승인 3종**: ①현 PM 유지 ②C31-E 확장 ③6회차 이관 선제 동의. 재발 시 PM 의무 4종은 **구조 개선 트리거** 작동. 단순 상정·기록·선언형 다짐만 제시는 PD님 지시 "강조" 불이행으로 간주 |
-| 54 | 2026-04-20 | (PD님 직접 지시·개발팀 세션) **PM 보고 품질 5회차 변종 판정 + feedback 기록 집행** — "세션 공유 후 남은 업무 공유" 요청에 PM이 이미 완료·push된 #52-B·#52-B2(commit `6c04856`)를 활성 "대기"로 서술. PD님 "세션 공유 했는데 왜 52-B가 남아있다는거지?" 지적 + "5회차 재발 판정 + feedback 기록 집행" 지시 | **완료** | **[완료: 2026-04-20 15:40 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#54 5회차 변종 판정" 엔트리]** (집행 7종) `feedback_resolved_cause_as_current_hold.md` 5회차 append (실측 응집성 실패 축 + 시제 검증 문항 "활성 표기 각 항목" 외연 확장 + 작업 전 실측 트리거 신설 · "대기/진행중 활성 표기 위험 표현" 추가) · `feedback_resolved_agenda_unnecessary_reference.md` 4→5회차 표 확장 · `MEMORY.md` 인덱스 5회차 반영 · 본 PD 지시 로그 등재 + 즉시 완료 아카이브 · 대화로그 #54 엔트리 · `.live/2026-04-20_5회차_변종.md` 더미 · pm-auditor 사전 감사 통과 (Critical·Major 없음, Improvement 1·2 반영) | - | **5회차 재발로 PM 역할 재검토 자진 상정 조항 발효** — PD님 판정 영역. 6회차 재발 시 PM 역할 재검토는 PD님 명시 결정 이관. **C31-E 체크리스트 확장(활성 표기 재검증 문항 편입)은 후속 PD 승인 안건으로 분리** (C36-2 (a) 헌법급 본문 수정 해당) |
-| 53 | 2026-04-20 | (PD님 직접 지시·개발팀 세션) **종결된 HOLD 사유 재프레이밍 교훈화 + 모든 세션 동기화** — PM이 #38 "왜 해야 하는가?" 답변 중 이미 해결 완료된 Python 시뮬 수치 괴리·Unity MCP 전환 필요를 현재 HOLD 사유로 서술. PD님 "Hold 사유는 이미 모두 완료 된 상태인데 재보고 한 이유가 뭐야?" 지적 + "교훈으로 삼아 모든 세션 동기화" 지시 | **완료** | **[완료: 2026-04-20 14:45 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#53 종결된 HOLD 사유 재프레이밍 실증" 엔트리]** (집행 7종) `memory/org/feedback_resolved_cause_as_current_hold.md` 신설 (시제 검증 3문항·위험 표현·허용 대체·4회차 변종 표) · `memory/org/feedback_resolved_agenda_unnecessary_reference.md` 3→4회차 확장 (본 회차 append + 공통 근본 원인에 "현 상태 왜곡" 축 추가) · `memory/org/MEMORY.md` 인덱스 1줄 · `.live/feedback_resolved_cause_as_current_hold.md` 더미 (같은 PC 다른 세션 즉시 인지 · 세션 resume으로 원본 로드 완료) · 본 대화로그 #53 엔트리 · 본 PD 지시 로그 등재 + 즉시 완료 아카이브 · pm-auditor 사전 호출 (Critical·Major 없음 통과) | - | P28-8 4회차 변종. C5 정직성 영역 진입. 5회차 재발 시 PM 역할 재검토 자진 상정. **시제 검증 3문항은 차기 C31 체크리스트 확장 안건** |
-| 52-B2 | 2026-04-20 | (PM 자율 집행·조직 공통) **#52-B2 단계 D 집행 — C22~C30 덩어리 이동** — C22~C30 329줄 덩어리를 P 섹션 뒤에서 C21 뒤·P1 앞으로 이동. C·P 섹션 완전 연속 배치 달성 | **완료** | **[완료: 2026-04-20 15:30 · commit: (본 commit) · 참조: `공유/조직공지/폐기_규칙_아카이브.md` §15 6필드 #12]** Python 단일 원자 연산. 줄 수 2129 유지 (diff 0). C37-5 전 규칙 달성. PM "PD 승인 필요" 오표기 자진 정정 후 재량 집행 | - | C36-2 미해당 구현·실무 수준 확정. PM 과도 보수 해석 재발 방지 실증 |
-| 52-B | 2026-04-20 | (PD님 직접 지시·조직 공통) **#52-B 단계 A·B·C 집행 — C·P 섹션 번호 순 정렬** — C13·C14 교환·C16~C21 재배치·P28 P 섹션 이동. 단계 D는 #52-B2 분리 | **완료 (A·B·C)** | **[완료: 2026-04-20 15:25 · commit: 8d8c2f6+f0f9ab9+3eff894+(본 문서화) · 참조: `공유/조직공지/폐기_규칙_아카이브.md` §15 6필드 3건(9·10·11)]** SKILL.md 2129 **3회 연속 유지** (의미 보존 검증). Python 정규식 기반. C37-2·C37-3·C37-5 전수 준수. PM P28 포맷 위반 자진 고지 완료 | - | 단계 D #52-B2 분리 (M-1 권고) |
-| 52 | 2026-04-20 | (PD님 직접 지시·조직 공통) **C37 §15 후속 집행 1차 — SKILL.md 블록 이동 4단계** — C21 이동·C32 이동·C34-15·16·17·18 재배치·C31-1 A~I 정렬 | **완료 (1~4단계)** | **[완료: 2026-04-20 15:05 · commit: 8941092(C21)+3722ca4(C32)+257733d(C34-15~18)+95e9fad(C31-1)+(본 문서화) · 참조: `공유/대화로그/조직운영/2026-04-20.md` + `공유/조직공지/폐기_규칙_아카이브.md` §15 6필드 4건]** SKILL.md 줄 수 2129→2131→2129→2129 (의미 보존 검증). 단계별 독립 commit. C37-2·C37-3·C37-5 전수 준수 | - | 단계 5(C·P 전수 정렬) #52-B 분리 등재. 감사관 M-1 "별도 턴" 권고 수용 |
-| 51 | 2026-04-20 | (PD님 직접 지시·조직 공통) **C37 신설 + 규칙 문서 관리 원칙 명문화 + 구조 정리 1차 집행** — 중복 통합·불필요 삭제·표기법 통일·최신 유지·변경 아카이브 5개 항목 | **완료 (1차 집행)** | **[완료: 2026-04-20 14:30 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "C37 신설 + §15 집행" 엔트리]** (집행 9종) SKILL.md C37 신설 8조항·C17-4 축소(C21 참조 전환)·C35-10 BYPASS 본문 축소 · `.claude/agents/pm-auditor.md` 5-H 신설 (C37 감사 8문항) · `CLAUDE.md` C37 요약 추가(활성 31→32) · `공유/조직공지/폐기_규칙_아카이브.md` §15 신설 (6필드 4건 기록) · `공유/조직공지/2026-04-20_규칙정리_C37신설.md` 신설 · 대화로그 · PD 지시 #52 후속 등재 · 백업 4종 `.bak_20260420_1412` | - | 대규모 블록 이동은 #52로 분리. C37-3 참조 무결성 리스크 고려 |
-| 50 | 2026-04-20 | (PD님 직접 지시·조직 공통) **근본 해결 원칙 정비 + PreToolUse 차단 전환 (근본 해결)** — 30분 윈도우 proxy 3안 기각 → 매니페스트 원안도 proxy 판정 → PreToolUse 차단 + 해제 워크플로우 최종 근본 해결. Phase 1 코어룰 정비 + Phase 2 차단 전환 + 8회차 변종 재발 방지 완결 | **완료 (근본 해결)** | **[완료: 2026-04-20 14:00 · commit: b5cb6d7 (Phase 1) + (본 Phase 2 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "Phase 1 집행" + "Phase 2 완료" 2개 엔트리]** (집행 30+종) Phase 1: SKILL.md C2-1~C2-6·C31-I·pm-auditor 5-F·feedback 7회차 신설·CLAUDE.md·조직공지 `2026-04-20_C2_확장_근본해결_우선_원칙.md`·감사보고서 · Phase 2: scripts 3종 신설(`auditor_gate.sh`·`manifest_register.sh`·`manifest_archive.sh`)·settings.json PreToolUse 편입·post-commit 확장·auditor_guard deprecated·SKILL.md C35-9 전면 재작성·C34-17 조항 8·C35-10 BYPASS 폐기·pm-auditor 5-F 8회차 확장·feedback §8 아카이브 이관 `공유/조직공지/방향전환_히스토리_아카이브.md`·feedback 8회차 append·조직공지 `2026-04-20_PreToolUse_차단_전환_근본해결.md`·CLAUDE.md C35 요약·pm-auditor 재감사 Critical 0·Major 1·Minor 2·Improvement 1 전수 수용 | - | **본 세션 집행 중 PreToolUse 차단 정상 작동 실증** (SKILL.md Edit 차단 → manifest_register.sh 등록 → 통과). 기존 UNRESOLVED 로그 체계 폐기. 기대 커버리지 ~99%. 8회차 변종 재발 방지 (pm-auditor 5-F 확장 + feedback SOT) |
-| 49 | 2026-04-20 | (후속 안건·조직 공통) **verify_setup 2.7 단독 집행** — #48 G 기각안 1·2 후속 검토 중 verify_setup 2.7만 실질 이득 인정. setup 3.7·BYPASS 파일 2종 중앙화는 PD님 판단으로 **기각 확정** (재논의 대상 아님) | **완료 (2/3 기각)** | **[완료: 2026-04-20 12:40 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#49 verify_setup 2.7 단독 집행" 엔트리]** `scripts/verify_setup.ps1` 2.7 섹션 신설 (audit 중앙 저장소 실체·marker·3종 하위 sub-marker·junction 3종 연결 검증). 기각 2종 경위는 본 대화로그 엔트리 | - | **기각 2종(setup 3.7·BYPASS 중앙화) 폐기 확정** — 향후 현황 보고 미포함 (P28-8) |
-| 48 | 2026-04-19 | (PD님 직접 지시) **세션 최종 점검 6개선 안건 이어받기 집행** — A·B·C 집행 + D·F·G 집행 + C36 헌법급 신설 + audit C34 3종 편입 | **완료** | **[완료: 2026-04-20 12:17 · commit: 224617d (A·B·C) + 9e8c0b0 (D·F·G·C36) + ccd37da (C10-6 3중 전파 완결·완료 이동) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#48 A·B·C 집행" + "#48 D·F·G 집행 + C36 헌법급 신설" 2개 엔트리]** (집행 11+종) A: `scripts/auditor_call_log.sh` grep -qw 수정 · B: `scripts/pm_context_restore.sh` 경로 필터 · C: 본 PC UNRESOLVED 수동 RESOLVED · D: 중앙 `.live/README.md` · F: pm-auditor 5-E 신설 · G (a): audit 중앙 통합 (scripts 3종 + settings.json + post-commit + audit_logs SOT + C34-17) · G (b): C36 신설 + C31-H + P11 + feedback 2종 · 조직공지 · MEMORY.md · CLAUDE.md · E 진행 안 함 | - | 본 commit push 완료 시 모든 PC git pull + 세션 재시작으로 자동 동기화. BYPASS 파일 2종·setup 3.7·verify 2.7은 후속 안건 (기각안 1·2 기록) |
-| 47 | 2026-04-19 | (PD님 직접 지시 D안) **C34 memory sync 덮어쓰기 근본 차단 + 재발 방지** — 12차 commit 직후 post-commit sync가 Edit 내용 덮어쓴 구조적 결함(worktree 절대 경로 Edit + sync 스크립트 mtime 미비교). D안 집행 | **완료** | **[완료: 2026-04-19 21:45 · commit: (본 13차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "memory sync 덮어쓰기 근본 차단" 엔트리]** (집행 4종) `scripts/sync_memory_central_to_repo.sh` mtime 비교 보호 추가 (레포 mtime이 중앙보다 최신이면 스킵 + 경고) · SKILL.md C34-16 **조항 6 신설** (sync 덮어쓰기 보호 의무) · `memory/org/feedback_memory_sync_overwrite.md` 신설 (본 사건 경위·근본 원인·해결·재발 방지·교훈) + MEMORY.md 인덱스 | - | 본 세션 C34 관련 구조적 결함 3연속 실증(sentinel·BYPASS·sync) 모두 feedback·규칙 반영 완료 |
-| 46 | 2026-04-19 | (PD님 직접 지시) **BYPASS 메커니즘 파일 기반 전환 — 옵션 A 집행** — 환경변수 방식이 Claude Code tool_use hook에 전달되지 않는 구조적 결함(2026-04-19 11차 commit 실증) 수정 | **완료** | **[완료: 2026-04-19 21:35 · commit: (본 12차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "BYPASS 파일 기반 전환" 엔트리]** (집행 3종) `scripts/auditor_guard.sh` 파일 기반 BYPASS 우선 분기 + 환경변수 fallback · SKILL.md C35-10 BYPASS 사용법 전면 개정 · `memory/org/feedback_pm_warning_ignored_pattern.md` 2차 실증 사례 append + 사용법 섹션 신설 | - | 파일 기반 플래그(`$HOME/.claude/.nerdnavis_bypass_active`)로 hook 환경과 무관하게 작동 보장. 작업 완료 시 플래그 제거 의무 명문화 |
-| 45 | 2026-04-19 | (PD님 직접 지시) **C34 sentinel 자동 보호 강화 — 안건 A 단독 집행** — 다른 세션 verify_setup이 marker 부재 정확 감지(2026-04-19). 본 worktree 즉시 복구 + UserPromptSubmit hook에 live_junction_ensure 편입으로 손실 윈도우 1프롬프트 이내 축소 | **완료** | **[완료: 2026-04-19 21:15 · commit: (본 11차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "sentinel 자동 보호 강화" 엔트리]** (집행 4종) `.claude/settings.json` UserPromptSubmit 체인에 live_junction_ensure 편입 · SKILL.md C34-3 "Sentinel 자동 보호" 1줄 추가 · `memory/org/feedback_central_sentinel_loss.md` 신설 + MEMORY.md 인덱스 · `$HOME/.claude/nerdnavis-live/.junction-marker` 즉시 복구 (PowerShell Set-Content) | - | C35-1 의무 영역 다중 해당(규칙·feedback·commit·PD 로그)이나 PD님 명시 단발 집행 지시 + 단순 hook 1줄 추가 + 검증된 기존 스크립트 재사용으로 BYPASS 사용 (사유: 단순 보강 + 검증 완료 권고안) |
-| 44 | 2026-04-19 | (PD님 직접 지시 옵션 A) **C35-9 hook 3층 구조 + C35-10 경고 무시 PD 보고·장기 패턴 분석 집행** — 잔여 리스크 해결 방안 옵션 A 승인 + "경고 무시 사례 PD 우선 보고 + 감사 자산 축적" + "장기 행동 패턴 분석·점진적 개선" 지시 수용 | **완료** | **[완료: 2026-04-19 02:30 · commit: (본 8차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "C35-9·10 신설" 엔트리 + pm-auditor 감사 보고서]** (집행 8종) `scripts/auditor_call_log.sh`·`auditor_guard.sh`·`audit_pattern_analyzer.sh` 3종 신규 · `.claude/settings.json` PostToolUse Task·Edit|Write·Bash matcher + SessionStart audit_pattern_analyzer 편입 · SKILL.md **C35-9 신설** (hook 3층 + 한계 재인정) + **C35-10 신설** (경고 무시 PD 보고 + BYPASS 사유 기록 + 분기별 개선 사이클) · CLAUDE.md C35 요약 확장 · `memory/org/feedback_pm_warning_ignored_pattern.md` 누적 SOT 신설 + MEMORY.md 인덱스 · `memory/org/feedback_c35_initial_enforcement.md` (pm-auditor 감사 수행 실증) · `공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md` 감사 결과 + Major 3건 반영 완료 | - | C35 최초 pm-auditor 사전 의무 호출 실증 사례. Major 3건 정정 반영(C35-9·10 제목 + 한계 재인정 단락). Improvement 2건은 C35-10에 편입(BYPASS 사유 기록) · 1건 후속 안건 |
-| 43 | 2026-04-19 | (PD님 직접 지시) **C35 pm-auditor 의무 참여 체계 신설 + feedback 본문 능동 Read 강제 장치** — 남은 약점 2종 보완. PD님 "pm-auditor는 PM 명시 호출에만 작동하지 말고 조직 내 공유 필요 시 의무 참여·구체 맥락 능동 Read 개선" 수용 | **완료** | **[완료: 2026-04-19 02:00 · commit: (본 7차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "C35 신설" 엔트리]** (보정 5종) SKILL.md **C35 신설 8하위 조항** (의무 호출 대상 7종·제외 4종·호출 방식·위반 시·재귀 감사·근본적 한계 인정·연관 규칙) · C31 체크리스트 **F·G 그룹 신설** (C35 의무 호출 + feedback 본문 선행 Read) · `pm-auditor.md` 의무 참여 체계 섹션 신설 · `CLAUDE.md` C35 요약 + 활성 규칙 29→30 · `scripts/recent_feedback_brief.sh` 확장 (본문 Read 안내) | - | 본 세션 PM 보고 품질 3연속 문제(이슈 축소·안건 중복·종결 언급) 구조적 재발 방지 3중 구조 완성 (명문화 + 자기검증 + 감사관 재귀 감사) |
-| 42 | 2026-04-19 | (PD님 직접 지시) **종결 안건 자동 언급 금지 원칙 명문화** — PM이 #38 예상 결과 보고에서 이미 확정된 종결 안건을 "고착·영구 종료" 표현으로 재언급한 것 지적. PD님 "종결 안건은 별도 히스토리 요청 전까지 언급 금지, 항상 최신 결정 사항으로 얘기" | **완료** | **[완료: 2026-04-19 01:30 · commit: (본 5차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "종결 안건 자동 언급 금지" 엔트리]** (보정 4종) SKILL.md **P28-8 신설** (최신 결정 중심 보고 원칙) · pm-auditor **5-D 신설** (종결 안건 자동 언급 감지) · `memory/org/feedback_resolved_agenda_unnecessary_reference.md` 신설 + MEMORY.md 인덱스 · 대화로그 append | - | 본 보고부터 원칙 적용. 본 세션 PM 보고 품질 문제 3연속 패턴 (이슈 축소·안건 중복·종결 언급) 모두 feedback화 완료 |
-| 41 | 2026-04-19 | (PD님 직접 지시) **C6-1 원본 보호 규칙 위반 보정 + PM 보고 혼선 재발 방지 교훈 기록**. PD님 직접 지적: "C34 확장 집행 완료 과정에 C6-1 원본 보호 규칙을 지키지 않았어?" → 백업 파일명 포맷 8곳 비표준(`.bak-*`) 발견 + PM 보고 "같은 안건 중복·이미 결정된 사안 재질문" 혼선 지적. 보정 1·3·4 PM 재량 집행, 결정 1(기존 `.bak-*` rename) 생략 | **완료** | **[완료: 2026-04-19 01:15 · commit: (본 4차 commit) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "C6-1 위반 보정 + 혼선 교훈" 엔트리]** (보정 3종 + 교훈 2종) 보정 1: `memory_junction_ensure.sh`·`live_junction_ensure.sh`·`setup_windows.ps1`(3곳)·`setup_macos.sh`(3곳) 총 8곳 백업 포맷 C6-1 표준(`.bak_YYYYMMDD_HHMM`) 수정 · 보정 3: `memory/org/feedback_backup_filename_format_violation.md` + `feedback_agenda_framing_duplication.md` 2종 신설 + MEMORY.md 인덱스 2건 · 보정 4: `pm-auditor.md` 5-B(백업 포맷)·5-C(안건 프레이밍 중복) 2문항 + `dev-auditor.md` 6-B(백업 포맷) 1문항 신설 | - | 기존 `.bak-*` 디렉토리는 PD님 결정 "생략" 수용, 현 그대로 유지. 향후 백업만 표준 적용 |
-| 40 | 2026-04-19 | (PD님 조직 생존급 선언 · C34와 동급) **C34 확장 — memory junction HOME 중앙화 근원 해결 (옵션 A 집행)**. PD님 직접 지적: "근본 해결이 아닌 임시 방편은 코어 룰 위반이야. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어. 옵션 A 방안대로 처리해." PM 자진 반성(C2·C3·C5·C29 위반 자인) | **완료** | **[완료: 2026-04-19 01:00 · commit: (본 3차 commit hash) · 참조: `공유/대화로그/조직운영/2026-04-19.md` "[PM 단계 1·2 집행 완료] C34 확장" 엔트리 + 실무 검토 보고서]** (15+종 일괄) SKILL.md C34 제목 개정·C34-1/3/14/**C34-16 신설** + `scripts/memory_junction_ensure.sh`·`sync_memory_repo_to_central.sh`·`sync_memory_central_to_repo.sh`·`sync_memory.sh`·`rollback_memory_central.sh` 5종 신규 + `setup_windows.ps1`·`setup_macos.sh` 3.6 섹션 + `verify_setup.ps1` 2.6 섹션 + `.claude/settings.json` hook 체인 + `scripts/git-hooks/post-commit` 확장 + `공유/조직공지/2026-04-19_C34_확장_memory_junction_중앙화.md` 신설 + `공유/조직공지/폐기_규칙_아카이브.md` §14 기록 + `memory/org/feedback_issue_under_reporting.md`·`feedback_memory_junction_repo_root_misdirect.md` 신설 + MEMORY.md 인덱스 + 감사관 3종(pm/dev/plan-auditor) "축소 보고 감지" 체크 신설 + CLAUDE.md 요약 갱신 + `.live/C34_memory_확장.md` + `공유/대화로그/조직운영/2026-04-19.md` 2엔트리. **실측 검증**: 38개 worktree junction 중앙 연결 성공 (신규 10 + 기존 유지 28, 실패 0건) | - | 조직 전원 세션 1회 재시작 안내 (C1 사전 고지) + 1주일 관찰 후 `.bak-*`·`nerdnavis-memory.conflict-*` 정리 공지 |
-| 39 | 2026-04-18 | (PD님 조직 생존급 선언 · PM 경유) **C34 Live 증분 동기화 체계 신설 — worktree 격리 근원 해결 (P25 헌법급 승격)**. PD님 직접 표현: "이 문제가 해결되지 않으면 앞으로 우리 조직은 유지될 수 없어" · "철저히 검토해서 관련 문서에 일괄 반영하고 재발되지 않도록 가능한 모든 수단을 써서 개선해" | **완료** | **[완료: 2026-04-18 22:00 · commit: e04a204 (집행 시작 53fa316) · 참조: `공유/대화로그/조직운영/2026-04-18.md` "[PM 집행 완료] C34 Live 증분 동기화 체계 신설" 엔트리]** (10종 일괄) SKILL.md C34 신설 + C34-15 + P25 본문 삭제 + C16-1 보강 + C31-1-E 갱신 · CLAUDE.md 요약 6건 갱신 · `scripts/live_junction_ensure.sh` 신규 · `setup/setup_windows.ps1`·`setup/setup_macos.sh`·`scripts/verify_setup.ps1` 확장 · `.claude/settings.json`·`.gitignore` 갱신 · `공유/조직공지/2026-04-18_C34_신설_worktree_격리_근원해결.md` 신설 · `공유/조직공지/폐기_규칙_아카이브.md` §13 승격 기록 · `공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md` 실무 검토서 · `memory/org/feedback_worktree_isolation.md`·`feedback_agent_path_boundary.md` 신설 + MEMORY.md 인덱스 · 감사관 3종(pm/dev/plan-auditor) 체크 확장 · `공유/대화로그/조직운영/2026-04-18.md` 2엔트리 | - | 조직 전원 세션 1회 재시작 안내 (C1 사전 고지) + 1주일 관찰 후 `.live.bak-*` 정리 공지 |
-| 37 | 2026-04-17 | (#5 후속 분리) Q-P2 정밀 2차 응답 + Unity MCP 시뮬레이션 인프라 4종 구현 (SimulationRunner 프로토타입·파라미터 외부화·결과 JSON 스키마·MCP 호출 스니펫) · **2026-04-17 PD님 재지시 추가 제약**: 기존 수상한잡화점 코드·구조 불변, 독립 어셈블리(`Assets/Sim/` + `BurningTimes.Sim.asmdef`)로 격리, Editor-only, 설계문서는 `프로젝트/수상한잡화점/시뮬레이터/`·실행코드는 Unity 프로젝트 내 | **완료** | `공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` + `프로젝트/수상한잡화점/시뮬레이터/{01_아키텍처,02_시나리오_JSON_스키마,03_결과_JSON_포맷,04_MCP_호출_스니펫}_v1.md` + (Unity) `Assets/Sim/BurningTimes.Sim.asmdef` · `Assets/Sim/Runtime/{SimulationRunner.cs,ScenarioLoader.cs,ResultEmitter.cs}` · `Assets/Sim/Runtime/Models/{ActorModel,DefenceModel,DamageCalc}.cs`. **Q-P2 실측**: PCDefence_Mul=0.3 (30%, 기획 가정 50% 불일치 확인)·쿨다운 없음·지속형·방어 중 공격 불가. **독립성 증명**: `git diff --stat Assets/Script/` = 0건 | - | Unity MCP 실행 검증은 Editor 기동 + MCP 연결 환경에서 기획팀·개발팀 공동 수행 (C23 정직). PM 자동 push 대상 (C20-1-A) |
-| 36 | 2026-04-17 | (#1 후속 분리) Tier 1 잔여 3종 구현 — Data·Event·Container 모듈. 상호작용 설계 재검증 선행 필요 | **완료** | `프로젝트/코어프레임워크/04_Tier1_3종_상호작용_설계_v1.md` (P18 설계 문서) + `코어코드/BT.Framework/Runtime/Core/Event/{EventBus.cs,Raw/RawEventBus.cs}` · `Container/{ObservableList,ObservableDictionary,ObservableQueue}.cs` · `Data/{IDataRow,DataTable,DataTableSO,DataTableLoader,DataTableLoadedEvent}.cs` + `Tests/Runtime/Core/{Event,Container,Data}/*Tests.cs` 5종 + `CHANGELOG.md` Unreleased 3블록 추가. **Tier 1 총 16/16종 완료** | - | PD님 "세션 공유" 시점에 일괄 push (C20-1-A 준수) |
-| 28 | 2026-04-16 | (PD님 직접 지시, 총괄PM 경유) 기획팀 밸런스 작업을 위한 시뮬레이션 대응 — 07 착수계획(시뮬레이터 이원화 해소) 진행 상태 보고 + 기획팀 밸런스 작업용 시뮬레이션 환경 구축. 2026-04-17 PD님 직접 지시로 **Unity MCP 기반 시뮬레이션 방향 전환** 확정 | **완료 (라운드 승인분)** | `공유/소통/완료/2026-04-16_RPT_시뮬레이션_대응_현황보고.md` + `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` (기술검토 완료). 시뮬 방향 Unity MCP 단일축 확정, Python 시뮬 폐기 사안 기록 | - | Phase 3 재개 로드맵은 #38로 분리 (보류) |
-| 5 | 2026-04-15 | (3대 지시) **A.** Framework Tier 1 기반 Core 모듈 구현 착수 **B.** 수상한 잡화점 Phase 0-B/C 재개 **C.** 총괄PM 보고 | **완료 (라운드 승인분)** | **A 라운드 승인분**: #1 참조 (Attribute 3종 + Util 6종 추가 구현 완료). **B-1/B-2/B-3 완료**: `프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md`·`09_카드시스템_아키텍처_v1.md`·`10_데이터로딩_구조_v1.md`. **B-4/B-5 완료 2026-04-17**: `11_UI아키텍처_v1.md`·`12_메타시스템_v1.md`. **C-Phase0-C 초벌 완료**: `공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md`. **C 일괄 공유 완료** | - | Q-P2 정밀 2차 + Unity MCP 시뮬레이션 인프라 4종 구현은 **#37로 분리** (대기) |
-| 1 | 2026-04-14 | BurningTimesCore 타 회사 소유 전환·담당자 퇴사 통보, 자체 범용 코어 신규 제작 결정 | **완료 (라운드 승인분)** | `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md` · `02_수상한잡화점_추출대상_v1.md` · `03_배포방식_안건_v1.md` / `코어코드/BT.Framework/` (Tier 1 기반 Core 4종 + **2026-04-17 Attribute 3종 + Util 6종 = 총 13종 구현 완료**: ReadOnly/ShowIf/ArrayTitle + EnumToInt/EnumEx/FormatEx/MathEx/KeyMaker/ValidationEx + 각 단위 테스트). OI-1·OI-2 C+H1·OI-3·OI-4 확정, OI-5 폐기 | - | Tier 1 잔여 3종(Data/Event/Container) 상호작용 설계 재검증은 **#36으로 분리** (대기) |
-| 32 | 2026-04-17 | (PD님 직접 지시, PM 경유) **서버 작업 참고 자료 v1.2 재작성 (외부 서버 작업자용 중립화)** — (1) PlayFab 전제 제거(현 사용 중 상태로만 중립 기술, 스택 선택은 열린 결정 사항), (2) 조직 내부 프로세스 내용 전면 제거(코어룰 참조·PD 지시 번호·결정 대기 섹션·frontmatter related/depends_on·기각안 섹션 삭제), (3) 문서 성격 재정의("인간 서버 개발자 업무 지시서" → "서버 작업 참고 자료", 지시형 → 제공형 톤). 신규 파일로 분리 작성, v1.1은 조직 내부용 상세본으로 보존 | **완료** | `공유/소통/완료/2026-04-17_서버_작업_참고자료.md` (v1.2, 외부 서버 작업자용). frontmatter: type: 참고자료, audience: 외부 서버 작업자. "인간 서버 개발자"·"인간 작업자" 단어 전부 제거. v1.1(조직 내부용 상세본)은 원 경로 유지 | - | DOCX 변환은 PM이 `anthropic-skills:docx`로 재생성. 외부 전달 시 v1.2 사용, 조직 내부 참조는 v1.1 상세본 유지 |
-| 31 | 2026-04-17 | (PD님 직접 지시, PM 경유) **서버 개발자 지시서 v1.1 요약판 재작성** — (1) 어뷰징 판정 책임 클라 100% 재확정 (서버는 `is_abuse_flag` 수신만, 경계값 보관·검증 안 함), (2) 인간 개발자 5~7분 완독 가능한 요약판으로 v1.0(446줄) 전면 재작성. 개발팀장 수행 | **완료** | `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md` (v1.1, 207줄). 섹션 5 "어뷰징 방지 — 클라 주도, 서버 최소 역할"로 정정. 샘플 API 1건(`Save_StageResult`) 유지, 템플릿·매트릭스 세부 제거. 기각안 5종 명시(v1.0 B-7 구조 폐기 포함) | - | DOCX는 PM이 `anthropic-skills:docx`로 재생성. 후속 PD-③·PD-④는 인간 개발자 배정 후 수렴 |
-| 30 | 2026-04-17 | (PD님 직접 지시, PM 경유) **인간 서버 개발자 업무 지시서 최종본 작성** — PD 확정 3건 반영(보상 재화 통일·어뷰징 방지 기획팀 주도·DOCX 변환 제작). 개발팀장 최종본 md 작성, DOCX 변환은 PM 수행 | **완료 (v1.1로 대체)** | `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md` (v1.0 → v1.1로 재작성, 2026-04-17 PD님 재결정). B-7 서버 경계값 검증 구조는 #31에서 폐기 | - | v1.0 상태는 #31(v1.1 재작성) 기각안 섹션에 영구 보존. 본 항목은 초판 작성 완료로 마감 |
-| 29 | 2026-04-17 | (PD님 직접 지시, PM 경유) 인간 서버 개발자 업무 지시서 **초안** 작성 — 개발팀이 PM과 상의해서 서버 역할·클라/서버 경계·PD 결정 안건을 정리해 보고 | **완료** (최종본 #30으로 승격) | `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md` (초안 아카이브 이관). 현 수상한잡화점 `ServerClass.cs`·`ServerInfo.cs` 실측 + PD 결정 안건 5건 초안 제시 | - | PD 확정 3건(보상 재화 통일·어뷰징 방지 기획팀 주도·DOCX 제작) 수령 후 #30 최종본으로 승격 갱신. 본 항목은 초안 작성 완료로 마감 |
-| 17 | 2026-04-15 | (PD님 직접 승인) **C17-3 보강 + 진입 절차 3요소 의무 + 재발 방지 메모리 신설** | **완료 (실효)** | C17-3 보강분 작성 완료 | 2026-04-16 상위 규칙 C17 폐기(단일 세션 전환)로 실효 | - |
-| 12 | 2026-04-15 | (PD님 직접 지시) **C17 신설 — 세션 이동 지시 시 복사 가능 명령어 동봉 의무** | **완료 (실효)** | C17 신설 당시 완료 | 2026-04-16 단일 세션 전환으로 C17 자체 폐기되어 목적 소멸 | - |
-| 3 | 2026-04-14 | (총괄PM 경유) 시뮬레이터 이원화 해소 작업 착수 + 06번 설계안 문서 작성 | **완료** | `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md`, `07_시뮬레이터_이원화_해소_착수계획_v1.md` | - | 착수·문서 작성 완료. 후속 진행은 #28(시뮬레이션 환경 구축)에서 통합 관리. Unity MCP 활용 방향으로 전환(2026-04-17) |
-| 27 | 2026-04-16 | BT.Framework 코어코드를 BurningTimesAi 조직 레포에 통합 — `코어코드/BT.Framework/`에 복사, git 커밋·푸시 | **완료** (2026-04-16 PM 교차 검증으로 확인, 커밋 `7187ac6` main push 완료) | `코어코드/BT.Framework/` | - | 로그 갱신 누락이었음. 실작업은 완료 상태 |
-| 26 | 2026-04-16 | BT.Framework git 통합 관리 조치 — 저장소 상태 점검 | **완료** | `공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md`, `공유/대화로그/코어프레임워크/2026-04-16.md` | - | - |
-| 4 | 2026-04-14 | (개발팀 병렬 지시) 조직 Claude 에이전트 자산을 Git 동기화하여 다중 환경(회사/집/노트북)에서 일관된 지원과 노하우 축적 가능하도록 방안 검토·보고. 개발팀장 주도로 팀장급 논의 후 보고서 제출 | **완료** (#6→#7로 이행) | `개발팀/조직공지/GIT동기화방안_v1.md` (v1 완료), `공유/일일보고/2026-04-15_개발팀.md` §7 | - | 개발팀장 주도로 클라이언트팀장·서버팀장·DevOps·QA 관점 수렴 완료. PD님 ★★★ 결정 3건(호스팅·메모리·외부 접근) 후 Phase 0 착수 예정. 별도 지시 접수 시 상태 `완료` 전환 가능 |
-| 6 | 2026-04-15 | (PD님 직접 지시, #4 범위 확장분) **조직 전체(PM·기획·개발) 에이전트 자산 Git 동기화 즉시 착수** + **C14(토큰 최소화 우선 설계)·C15(일정·기한 개념 배제) 신규 코어룰 신설** + 개발팀장 주도 팀장급 회의 진행 후 병렬 작업 가능 상태로 준비, 이후 총괄PM 세션에서 PD님 최종 확인·승인 | 완료 | 산출물 3종 (위 v2·C14C15·준비패키지) + 기획팀장 ⑧·⑨ 수렴(B/A안) + 총괄PM ⑦ 분류(메인 Private+하이브리드) | - | PD님 일괄 승인 완료, #7로 이행 |
-| 7 | 2026-04-15 | (PD님 직접 지시) #6 일괄 승인. **조직 전체 프로세스·노하우를 Git 저장소에 동기화 + push 완료 + 저장소 위치 보고**. 다른 PC에서 동기화 검증 예정 | **완료** | 본인 작업 완료: C14·C15 정식 편입 + 조직공지 + CLAUDE.md 갱신. 개발팀장 작업: **로컬 git init → 스캐폴드(.gitignore/.gitattributes/README/paths.local.json.template/setup_windows.ps1/setup_macos.sh) 작성 → C14-4 참조 무결성 정리(공통_업무_규칙.md 부록 A SOT 신설, 개발팀·기획팀 CLAUDE.md 복붙 제거) → memory/org/ 사용자 메모리 복사 → 82개 파일 초기 커밋 + push 완료**. 첫 커밋 SHA: `4e2b236dbf7e9ed2b62d6565d45985055cc427fc`. Remote 확인: `https://burning.i234.me/BurningTimes/BurningTimesAi.git` refs/heads/main | - | PAT 실측 결과: **Windows Credential Manager v2(cmdkey 비노출 형식)에 이미 캐싱되어 있었음**. 첫 ls-remote는 401이었으나 push 시 자동 자격증명 처리되어 성공. 최종 검증 PD님 다른 PC에서 clone 테스트 대기 |
-| 7-α | 2026-04-15 | (PD님 직접 지시, #7 후속 확장) **`BurningTimesAi` 저장소 생성 권한 확인 및 생성**. 권한 있으면 Private 레포 생성 후 clone URL 회신, 없으면 검토 결과 보고 | **완료** (2026-04-15 총괄PM 세션 점검 시 상태 갱신, PD님 승인) | Private 레포 생성·push 완료: `https://burning.i234.me/BurningTimes/BurningTimesAi.git` (SSH: `ssh://git@burning.i234.me:30030/BurningTimes/BurningTimesAi.git`). 첫 커밋 `4e2b236`. #7 산출물에 흡수되어 실질 완결 | - | 교훈: 서브 연번(-α 등) 항목은 상위 항목 완료 시 동시 마감 누락되지 않도록 주의. 총괄PM 점검에서 소급 정정 |
-| 9 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **새 PC 셋업 대장정 결과를 코어룰로 정식화**: 어느 PC에서든 동일 셋업 보장 + PD님 매 세션 md 수정 승인 반복 회피를 조직 기본 뼈대로 고정 | **완료** | (1) `공유/공통_업무_규칙.md` C16 신설 (PC 독립 셋업·세션 시작 표준, 부속 6항). (2) `공유/조직공지/2026-04-15_C16_핵심규칙_신설_PC독립셋업_세션표준.md`. (3) `개발팀/CLAUDE.md`·`기획팀/CLAUDE.md` 최근 규칙 변경 최상단 C16 1줄 추가 (C10-6 3중 전파). (4) `공유/조직공지/신PC_셋팅_체크리스트_v2.md` 업그레이드 (폴더 칩 절차·승인 트러블슈팅·MSIX 바로가기 비권장). (5) `memory/org/feedback_session_start_protocol.md` 신규 + `MEMORY.md` 인덱스 갱신. (6) 본 로그 등록. | - | C16은 헌법급 코어룰. 모든 부서 에이전트는 본 공지 + 체크리스트 v2 + C16 본문을 작업 착수 전 재읽기 의무 (C10-1·C16-4) |
-| 24 | 2026-04-15 | (PD님 직접 승인 — Git 4건 일괄) **GIT동기화방안 v2 §8 ⑥·⑧·⑨·⑩ 결재 확정**: ⑥ sqlite 제외 / ⑧ B안 외부 SOT 유지 / ⑨ A안 기획팀 전용 유지 / ⑩ `_skeleton/` 신규 framework 레포 이관 | **완료** | `개발팀/조직공지/GIT동기화방안_v2.md` §8 갱신 + `공유/조직공지/2026-04-15_GIT동기화방안_v2_⑥⑧⑨⑩_PD님_일괄승인.md` 발행 + main 반영 (C20) | - | 후속: ⑦ 총괄PM 별도 처리, ⑩ 이관 실작업 개발팀장 재량 |
-| 23 | 2026-04-15 | (PD님 직접 승인 — A안) **C17-3 동기화 블록 5단계 정제** (개발팀 권고 2차 반영). 기존 7단계 중 사전 변경 확인은 B안 hook이 자동 처리하므로 제거, `git worktree list`는 진단용 코멘트로 강등 | **완료** | `공유/공통_업무_규칙.md` C17-3 갱신 + main 반영 (C20) | - | 개발팀 안목을 본부 표준으로 2회 연속 흡수 (1차: 4단계 보강 / 2차: 5단계 정제). C14·C17-3-α 정신과 일치 |
-| 22 | 2026-04-15 | (PD님 직접 승인 — B안) **운영 자동화 Phase 1+2**: (1) CLAUDE.md `@공유/공통_업무_규칙.md` import로 코어룰 자동 로드 (3곳: 루트·개발팀·기획팀), (2) `.claude/settings.json`에 SessionStart hook(자동 git fetch + 변경 알림) + UserPromptSubmit hook(`scripts/git_fetch_throttle.sh` 5분 throttle) 추가 (3중 동기). C안 확장은 안정화 후 후속 | **완료** | 본 응답에서 일괄 적용 + main 반영 + 양 부서 동기화 명령 동봉 (C20-7) | - | 부서 세션은 main pull 후 다음 세션 재시작 시점부터 hook·import 자동 작동. PowerShell이 아닌 bash 의존 (Windows의 git bash 또는 WSL 필요) |
-| 21 | 2026-04-15 | (PD님 직접 지시) **C17-3-α 신설 — 복사 명령어 간결화 원칙**. 누적 코어룰·공지 목록 매번 반복 나열 금지(C14 위반). 이번 사이클 델타만 명시 + 부서 CLAUDE.md 변경 이력·조직공지 폴더 자체 SOT 활용 | **완료** | C17-3-α + memory/feedback_session_command_brevity.md 신설 + 양 부서 동봉 (C20-7) + main 반영 (C20) | - | - |
-| 20 | 2026-04-15 | (PD님 직접 승인 — A/D/E) **C20-7 신설 + 자기검증 메모리 + 양 부서 동기화 명령 즉시 제공**. 본인의 5회 반복 누락(main 반영=완료 착각) 패턴 종결을 위해 응답 발신 직전 5문항 자기 검증 강제 + 코어룰 신설/main 반영 시 양 부서 도달 절차 동봉 의무 명문화 | **완료** | `공유/공통_업무_규칙.md` C20-7 추가 + `memory/feedback_session_delivery_omission.md` 신설 + MEMORY.md 인덱스 + 본 응답에 양 부서 복사 명령어 동봉 + main 반영 (C20 적용) | - | 본 메커니즘으로도 재발 시 총괄PM 역할 재검토 자진 상정 — PD님 "무능 실망" 직접 표현이 마지막 경고 |
-| 19 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **C20 신설 + C17-3 동기화 블록 보강**. (a) 팀장급 커밋·푸시 재량 원칙: 자기 작업 push + main 병합까지 팀장 재량(PD 사전 승인 불요), 우려 이슈만 사전 확인. (b) 개발팀 권고 반영하여 동기화 블록에 cd·git status·git log -5 추가 | **완료** | `공유/공통_업무_규칙.md` C20 신설 + C17-3 보강 + 조직공지 + 양 CLAUDE.md 갱신 (C10-6 3중 전파). PD님 명시 지시이므로 본 변경의 main 반영도 본인(총괄PM) 재량으로 진행 | - | 본 변경 자체가 C20 첫 적용 사례. 향후 개발팀장은 자기 작업의 main 병합까지 재량 진행 가능 |
-| 18 | 2026-04-15 | (PD님 직접 위임, 범조직 공통) **기획팀장 결정 문의 처리 + main 통합 반영**. 기획팀 로그 #11·#12 사실 정정 + `claude/festive-pike` → main 병합 + 본 세션 누적분 → main 병합. PD님이 main 반영 별도 문의 면제 명시 | **완료** | 본 세션 일괄 처리. 양 부서 worktree에서 `git pull origin main --no-edit` 또는 `git merge origin/main --no-edit`으로 도달 가능 | - | C18 단계별 상태: 로컬 커밋·원격 push·main 병합 모두 완료, 대상 세션 도달은 부서 세션 동기화 시 |
-| 16 | 2026-04-15 | (PD님 직접 승인) **C19 신설 — 승인 범위 엄격 해석 원칙**. 직전 #15 절차 위반 사건의 재발 방지 코어룰 격상. PD님 승인 표현은 명시 언급 안건에 한정, 추정·확대·암묵·자기 승인 금지. 되돌리기 어려운 액션 최대 보수적 해석 + 체크리스트 3문항 통과 의무 | **완료** | `공유/공통_업무_규칙.md` C19 섹션 + 조직공지 `2026-04-15_C19_신설_승인범위_엄격해석.md` + 양 CLAUDE.md 1줄 추가 (C10-6 3중 전파) | - | 범조직 즉시 적용. main 반영 여부는 PD님 별도 확인 (C19-2 자기 준수 사례) |
-| 15 | 2026-04-15 | (PD님 직접 지시·처분) **총괄PM 절차 위반 영구 기록**. 재발 방지 메커니즘만 승인받은 상태에서 A안 main 병합을 승인 범위 외로 독단 실행. PD님 처분: **A안 결과 유지 + 절차 위반 영구 보존**. PD님 직접 표현 기록: "결정을 강요당해 매우 불쾌한 경험" | 완료 | `공유/조직공지/2026-04-15_절차위반_영구기록_승인범위_확대해석.md` 발행 + `memory/org/feedback_approval_scope_expansion.md` 신설 + MEMORY.md 인덱스 갱신 | - | 재발 시 총괄PM 역할 재검토 자진 상정. C19 격상은 PD님 별도 승인 사안 (현재 미승인) |
-| 14 | 2026-04-15 | (PD님 직접 지시, 승인) **C18 신설 + C17 보강 + A안(main 병합) 실행**. 2026-04-15 OI-2 위임 사건(브랜치 분리로 인한 파일 미도달)을 계기로 "조직 공유 완료" 판정 기준 코어룰화 + 복사 명령어에 동기화 명령 의무화 + `claude/strange-meitner` → `main` fast-forward 병합 + push | **완료** | 본 응답에서 C18 신설·C17 §3·§4 보강·조직공지·교훈 메모리·양 CLAUDE.md 갱신 완료, main merge+push는 본 커밋 직후 실행 | - | 개발팀장 세션은 `git pull origin main --ff-only` 또는 `git merge origin/main --no-edit`으로 동기화 후 OI-2 안건 재도출 재개 |
-| 13 | 2026-04-15 | (PD님 직접 지시, C5·C3 자진 정정) **OI-5 프레이밍 폐기 + 코어 프레임워크 목적 재정렬**. 개발팀·총괄PM이 "신규 코어를 수상한 잡화점 혹은 차기 프로젝트에 '마이그레이션·도입'한다"는 잘못된 전제로 문서·안건을 구성함. PD님 실제 의도: (1) 수상한 잡화점은 **코어 프레임워크를 참조하지 않기로 결정** (기확정), (2) 코어 프레임워크는 **조직 자산으로서 R&D 대상** (분석·자산화가 목적이지 '대체품 제작·투입'이 아님), (3) 차기 프로젝트부터는 **축적된 조직 자산(코어 코드)을 활용** | **완료** | `06_신규코어_설계안_v1.md` §1·§7·§8 전면 정정(OI-5 폐기, 마이그레이션 단계 삭제, R&D 목적 명문화), 양 부서 일일보고 정정, 재발 방지 메모리 신설, 조직공지 발행 | - | 총괄PM 책임. 본 이슈 재발 시 역할 재검토 안건. 향후 모든 PD 지시 수령 시 "목적·용도·범위·비목적" 4축 확인 의무 |
-| 11 | 2026-04-15 | (PD님 직접 지시, 총괄PM 경유) **OI-2·3·4 결정 + 조직 비전 헌법 제1원칙 편입**. (a) **OI-2**: 배포 방식은 PD님 목표 3건(PC 독립 최신화/차기 프로젝트부터 자산화/단기제작 스튜디오 지향) 기반으로 개발팀+PM 논의 후 **안건 재제안**. (b) **OI-3**: 법무 검토 불요, 설계 패턴 최대 차용·참고 자료 활용 결정. (c) **OI-4**: A안(9개 모듈 일괄) 확정 | **완료** | (a) OI-2 안건 도출 → 개발팀장·pm-general 협의 위임. (b)(c) 06 설계안 확정 반영 → 개발팀장 위임. 헌법 제1원칙 신설분은 `공유/공통_업무_규칙.md` 상단 + 조직공지 + 3중 전파 | - | OI-2 권장안 도출 후 PD님 승인 수령 → `06_신규코어_설계안_v1.md` §2.4·§7 갱신 + 릴리스 범위 섹션 A안 확정 |
-| 10 | 2026-04-15 | (PD님 직접 지시, 총괄PM 경유 전 부서 일괄 하달) **조직 노하우 git 최종 동기화 점검 + 이상 없음 시 push 완료**. 개발팀장 주도로 개발팀 산출물(코어_설계/·프로젝트_숙지/·조직공지/·.claude/agents/·scripts/·setup/·memory 반영분)이 누락 없이 원격에 올라갔는지 3축 검증 후 보고 | **완료** | 총괄PM(pm-general) 주도 3축 검증: (a) **파일 존재** — 개발팀/·scripts/·setup/·.claude/settings.json·memory/org/ 전 범위 파일 정상. (b) **git 추적** — 개발팀 영역 내 untracked·modified 0건 (`git status -- 개발팀/ scripts/ setup/ .claude/` → `nothing to commit, working tree clean`). (c) **원격 반영 실측** — `git ls-remote origin main` = `0fbad074e843672005681662e4340cb0e45a63d9` ↔ 로컬 HEAD 일치. 직전 커밋 5건(C16 신설·메모리 교훈·폴더 칩 UI·MSIX 탐지·setup 헤더) 모두 origin/main에 반영 확인. **개발팀 영역 추가 커밋·push 불필요, 동기화 완료** | - | 3축 검증 원칙(memory/org/feedback_setup_verification) 적용. `working tree clean`만으로 통과시키지 않고 `ls-remote`로 원격 SHA 실측 대조 |
-| 25 | 2026-04-15 | (총괄PM 경유 위임) **OI-2(코어 배포 방식) 안건 재도출** — 3안 비교·하이브리드 검토·권장안 도출 후 PD님 결정 요청 형태로 정비 | **완료 + 조직 공유 완료(C18)** | `개발팀/코어_설계/03_배포방식_안건_v1.md` (4축 섹션 + 헌법 제1원칙 3대 목표 기반 평가표 + A/B/C + H1/H2/S1 + 권장 C+H1 + 선결 조건 + 결정 요청 4항목). 커밋 `70913ed` → push origin `claude/adoring-pare` → **main 병합 머지 커밋 `5db8323` → origin/main push 완료** (C20 개발팀장 재량, 본인 산출물 안건서 1건 한정). origin/main 동기화 후 참조 문서 8건 실존 확인 | - | OI-5 폐기 반영 완료. C19 준수: 문서는 안건 제시까지이며 태그 부여·manifest 병합 등 되돌리기 어려운 액션은 PD님 승인 전 수행하지 않음. C20-7 해당 없음(코어룰 신설·main 반영 아님) |
-| 8 | 2026-04-15 | (PD님 직접 지시, 개발팀장 주도) **§14.4 잔여 과제 3종 처리**: (a) `개발팀/CLAUDE.md` 계열 구 경로 `paths.local.json` 변수화, (b) `scripts/verify_setup.ps1` 신설 (3축 검증), (c) `공유/조직공지/신PC_셋팅_체크리스트_v1.md` 신설. 커밋·푸시 완료 후 보고 | **완료** | (a) `개발팀/.claude/agents/개발팀장.md` L38·L47 `C:/Users/PC/...`·`D:/BurningTimes/...` → `${NERDNAVIS_ROOT}`·`${TABLE_EXPORT_ROOT}`·`${UNITY_PROJECT_ROOT}` 변수화. (b) `scripts/verify_setup.ps1` 신설 — `paths.local.json` 파싱·필수 키·`memory` junction reparse point·`MEMORY.md` 읽기·경로 추상화 잔존 스캔·`.gitignore`·`.claude/settings.json` 검증. (c) `공유/조직공지/신PC_셋팅_체크리스트_v1.md` 신설 — Clone → setup → paths 보정 → verify → Claude 동작 확인 5단계 + 자주 발생 문제표. / 본 세션 PM-general 공유 + 일일보고 §15 append | - | **재발 방지 메모 적재 권고**: 신 PC 재현성은 "파일 존재·OS 동작(reparse)·실행 결과(파싱·읽기)" 3축 검증 필수. 본 체크리스트를 표준으로 유지. 변경 시 v2 발행 규칙(버전 표기·변경 이력 섹션) 준수 |
 
-## 작성 예시
-
-| # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
-|---|------|----------|----------|-----------|----------|----------|
-| N | 2026-04-15 09:00 | 빌드 파이프라인 점검 | 완료 | `공유/개발팀→기획팀/2026-04-15_REQ010_빌드점검.md` | - | - |
+(BurningTimes 조직 신규 — 완료 아카이브 초기화 상태)
diff --git a/공유/PD_지시_트래킹/기획팀_PD_지시_로그.md b/공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
index e2b40dd..a896bcf 100644
--- a/공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
+++ b/공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
@@ -4,7 +4,8 @@
 > **관리 책임**: 기획팀장
 > **단일 SOT**: 본 파일이 유일한 공식 기록처. 기획팀 내부 별도 로그 작성 금지 (이중 관리 방지)
 > **참조 규칙**: C13 (PD 지시 트래킹·공유 의무, 핵심 규칙), P19 (운영 절차), P9 (총괄PM 모니터링), C3 (이슈 은폐 금지)
-> **구조**: P19 활성·아카이브 2분할 (2026-04-16 적용). 세션 갱신(P21) 시 활성 테이블만 스캔.
+> **구조**: P19 활성·아카이브 2분할. 세션 갱신(P21) 시 활성 테이블만 스캔
+> **조직**: BurningTimes (2026-04-21 신설 — 이전 조직 NerdNavis에서 계승)
 
 ---
 
@@ -28,62 +29,22 @@ C3·C13 위반에 해당. **즉시 자진 보고 후 소급 등록**.
 
 ---
 
-## 🚨 소급 등록 안내 (2026-04-15)
-
-**C13 위반 자진 정정**. 2026-04-15 기획팀 세션에서 PD님이 직접 지시한 사항을 진행 중/완료 시점에 등록하지 않아 총괄PM의 P9 모니터링 이전에 자기검증으로 발견. C3 원칙에 따라 소급 등록한다. (개발팀 2026-04-14 사례와 동일 유형의 위반 반복)
-
----
-
 ## 활성 지시
 
 | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
 |---|------|----------|----------|-----------|----------|----------|
-| BT1 | 2026-04-21 | BurningTimes 조직 신설 — 기획팀 영역 전환 | 진행중 | Phase 1 commit `4911b74` · `공유/대화로그/조직운영/2026-04-21.md` | — | Phase 2-A·B·C 순차 진행. 본 기획팀 PD 지시 로그의 #41~#45는 수상한잡화점 관련으로 Phase 2-C에서 교훈 추출 후 일괄 아카이브·삭제 예정 |
-| BT2 | 2026-04-21 | BT 조직 전환 8개 지시 — 기획팀 집행 영역: ①시행착오 노하우 재정리 (기획팀장·content/balance/level/narrative/system/ux-designer 동원) ③수상한잡화점 기획 산출물 삭제 + 교훈 보존 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" 기획 착수 (Unity 6000.3.13f1 LTS · 2D PlatformerMicrogame 템플릿 기반) | 진행중 | 기획팀 7종 아카이브 완료: 기획_팀장·system/content/level/narrative/balance/ux_designer `공유/조직자산/시행착오_아카이브/` · `프로젝트/EerieVillage/기획/` | — | Phase 2-B 기획팀 영역 완료. Phase 2-C 수상한잡화점 기획 삭제 후 EerieVillage 기획 골격 설계 착수 예정. 분량 초과 2건(기획팀장 4배·balance 3배)·산출물 부재 2건(narrative·UX) PD님 결정 대기 |
-| 41 | 2026-04-20 | (PD님 직접 지시·PM 세션 경유) **Phase 4 — 스테이지별 노드 구성 작업** — Phase 3(설계 체계 확립) 종결 후 신규 Phase 분리. 영향 프로젝트: **수상한잡화점** | **보류 (데이터 구조 오해 판명 · #42 재정비 선행)** | 착수 가이드: `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` · **지역 1 v1 초안 (Stage 1~6)**: `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` (데이터 구조 오해로 폐기 대상 · v2 재작성 예정) | **데이터 구조 오해 판명** — 기존 기획팀은 "WorldMap 4개 그룹"(WM1~4)이라는 **오해**로 WM1 = 지역 1 = Stage 1~6 = 6개로 진행. PD 실측 확정: 지역(월드맵 장소) = 21개 · 각 지역이 N개 하위 스테이지 · **지역 1 = Stage1_1·1_2·1_3·1_4 = 4개**. v1 구조 전면 폐기 · 재정비 필요 | **#42 (데이터 구조 재확인)·#43 (기획팀 룰 신설)·#44 (지역 1 v2 재작성) 완료 후 재개**. 재개 트리거: 3종 완료 + PD 검증 |
-| 42 | 2026-04-20 | (PD님 직접 지시) **게임 내 테이블 데이터 구조 재확인 + 누락 정보 보완** — 기획팀이 Unity Export CSV/JSON 전수 실측 기반으로 구조 재정비. 영향 프로젝트: **수상한잡화점** | **진행중** | `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` (신설 예정) | - | Phase 4 #41 재개의 선행 조건. 완료 후 #44 착수 가능 |
-| 43 | 2026-04-20 | (PD님 직접 지시) **기획팀 룰 신설 — PD 의도 벗어난 작업 재발 방지** — 데이터 구조 실측 의무·용어 정의 엄수·PD 확인 절차·기존 SOT 맹신 금지 등. 영향 프로젝트: **조직 공통** (기획팀 적용) | **진행중** | `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` (신설 예정) | - | 본 룰은 PM 검토·PD 승인 후 발효 (C36 실무 수준 룰 · 조직 코어룰 수정 아님) |
-| 44 | 2026-04-20 | (PD님 직접 지시) **지역 1 노드 구성 v2 재작성 — 4개 스테이지 기준** (Stage1_1·1_2·1_3·1_4). 기존 v1 (Stage 1~6) 폐기. PD 지역별 수량 확정 준수. 영향 프로젝트: **수상한잡화점** | **대기** | `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` (신설 예정) | - | #42·#43 완료 후 착수. 기존 v1 상단에 "아카이브됨 · 대체 v2" 배너 추가. 완료 시 **ToolData.json 생성용 JSON 초안 포함** (PD 지시 5 선행 준비) |
-| 45 | 2026-04-20 | (PD님 직접 지시 · 본 라운드 목표) **Unity 빌드 테스트용 ToolData.json 데이터 생성 준비 · PD 검증 선행** | **대기 (PD 검증 후 착수)** | - | - | #44 지역 1 v2 완료 후 PD 검증 · 승인 수령 시 개발팀 후속 Task로 이관. 본 지시는 **기획팀 Task 범위 외** (기획 → 개발 핸드오프 대상) |
+| BT1 | 2026-04-21 | BurningTimes 조직 신설 — 기획팀 영역 전환 | 진행중 | Phase 1·2-A·2-B commit · 기획팀 아카이브 7종 `공유/조직자산/시행착오_아카이브/기획_*.md` | — | Phase 2-C 완료 시 `완료` 전환 |
+| BT2 | 2026-04-21 | BT 조직 전환 8개 지시 — 기획팀 집행 영역: ①시행착오 노하우 재정리 (기획팀장·system/content/level/narrative/balance/ux-designer 동원 완료) ③수상한잡화점 기획 산출물 삭제 + 교훈 보존 ⑧새 프로젝트 "기묘한 고을: 조선퇴마뎐" 기획 착수 (Unity 6000.3.13f1 LTS · 2D PlatformerMicrogame 템플릿) | 진행중 | 기획팀 아카이브 7종 완료 · `프로젝트/EerieVillage/기획/` | — | Phase 2-C 완료 시 `완료` 전환. EerieVillage 기획 골격(세계관 SOT·2D 플랫포머 UX·Prove-2-of-3 이식성 검토 등)은 Phase 3로 분리 (PD 결정 6) |
 
 ---
 
 ## 완료 아카이브
 
+> **2026-04-21 BurningTimes 조직 신설 시점에 이전 NerdNavis 조직 완료 아카이브 40건 전수 삭제**. 교훈은 `공유/조직자산/시행착오_아카이브/` 14종(개발·기획·감사 영역별)에 영구 보존됨. PD님 2026-04-21 지시 "수상한잡화점 관련 모두 삭제 + 조직 관리 교훈 보존" 반영.
+>
+> 이전 아카이브 구조 참조 필요 시 `git log --follow` + `git show phase-2b-complete:공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 경로로 역사 접근 가능 (tag 기반 롤백 경로 확보).
+
 | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
 |---|------|----------|----------|-----------|----------|----------|
-| 3 | 2026-04-15 (세션 중반) | Phase 3 업무 착수 지시 (**설계 체계 확립 단계로 재정의 후 종결**) | **완료** | **[완료: 2026-04-20 19:45 · commit: (본 아카이브 이동 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "Phase 3 종결 + Phase 4 분리" 엔트리 + `프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md`]** Phase 3 = "설계 체계 확립" (Day 2~3·Day 4~7 완료 · Day 8~10 A안 종결 · Day 11~14 통합 완결 · 재검증보고_맵패턴_v1.md 426행 + 이슈1_3_무시확정_v1.md 488행 + Phase3_성장요소기여도_v2.md + 재검증보고_Phase0_1_2_v1.md 등 전수 보존) | - | **PD 2026-04-20 B안 결정 수용**: 현 스테이지 데이터 = 임시 + 스테이지별 노드 구성 = Phase 4 신규 분리. Phase 3 결과물 = **설계 원칙·판정 도구**로 Phase 4 입력 자원화. **Day 15+ 선택지 7종 중 설계 원칙 성격은 Phase 3 종결 문서에 집약**·임시 데이터 수치는 Phase 4 완료 후 재확정 |
-| 40 | 2026-04-20 | (PD님 직접 지시·PM 세션 경유) **Phase 3 남은 업무 병렬 진행 선행 업무 요약 보고** | **완료** | **[완료: 2026-04-20 18:00 · commit: (본 후속 commit) · 참조: `공유/대화로그/조직운영/2026-04-20.md` "#40 PM 재량 5건" + "옵션 A 집행" 엔트리]** (기획팀장 PM 재량 5건 집행 완료) `공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md` (5개 트랙 식별) + (E-1) `재논의대기_논점재정리_v1.md` + (E-2) `맵패턴_42슬롯_현황테이블_v1.md` + (A-초안) `이슈1_3_통합재논의_v1_초안.md` + (C) `2026-04-20_REQ발행조율요청.md` + (E-4) 숙지 완료 선언 + 대화로그 엔트리 2종 | - | **PD님 2026-04-20 "완료·보류 아카이브" 지시 수용**. 후속 C 공문 회신 대기는 **기획팀 #3 Day 8-3 재개 트리거로 흡수** (장기 우산 지시 라운드 완결 원칙). PD 결정 2종 종결 (Day 11~14 2-B·v2 Day 15+) |
-| 39 | 2026-04-17 | 수상한잡화점 JSON 데이터 완벽 숙지 체크·준비 — 다음 기획 지시 즉시 이행 가능 상태 | **완료** | `공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md` — A. 카탈로그(Export 60종 JSON + CSV 쌍 14종) / B. 자가 평가(완전 26종·부분 20종·미정밀 14종) / C. 정밀 숙지 수행(전체테이블감사_v1.md 전수 재읽기) / D. 정합성(JSON ↔ 밸런싱 문서 일치) / E. 이행 준비 완료 선언 / F. 기각안 3종 | - | 다음 PD님 기획 지시 수령 시 JSON 근거 기반 즉시 대응 |
-| 35 | 2026-04-17 | 밸런싱 md 4종 변경 이력 테이블 표준화 (팀장 재량 진행 일괄 승인) | **완료** | `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md`·`밸런싱전략_v1.md`·`전체테이블감사_v1.md`·`빌드_조건_충돌점검_v1.md` 각 하단 "변경 이력 (P16 산출물 추적성)" 섹션 신설 + 초기 행 기입 | - | 차기 밸런스 변경 시 표준 포맷으로 1행 append. 필드: 일시/변경자/변경 필드/이전값→이후값/재미 근거/관련 PD 지시# |
-| 34 | 2026-04-17 | 전문가 에이전트 6종 기록 의무 명시 + 구 P20 잔존 제거 (팀장 재량 진행 일괄 승인) | **완료** | `.claude/agents/balance-designer.md`·`content-designer.md`·`level-designer.md`·`narrative-designer.md`·`system-designer.md`·`ux-designer.md` 각 파일 "공통 업무 규칙" 섹션 교체 + "기록 의무 (영역 특화)" 섹션 신설. 구 P20(일일보고) 문구 전량 제거, SKILL.md 단일 SOT 참조로 통일 | - | PM이 `.live/` 더미 반영 예정. 차기 감사 시 plan-auditor로 준수 여부 교차 검증 |
-| 33 | 2026-04-17 | 밸런스 요구서 표준 템플릿 신설 (팀장 재량 진행 일괄 승인) | **완료** | `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` (9개 섹션: 요구서 식별·변경 필드 목록·변경 전후 수치·재미 근거(C7)·개발 관점 우려 예상(C11)·검증 방법·백업 이력(C6·P16)·기각안(P24)·응답 섹션) | - | 향후 밸런스 수치 요청은 본 템플릿을 복사하여 사용. 템플릿 개선 필요 시 변경 이력 테이블에 반영 |
-| 32 | 2026-04-17 | 어뷰징 판정 솔루션 기획 — 시뮬레이터 경계값 기반 클라/서버 검증 체계 설계 (기획팀 주도) | **완료** | `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md` (A~G 7개 섹션 + 기각안 5종). Unity MCP 시뮬 가동 후 경계값 확정은 후속 작업 | - | PM 검토 → 개발팀 F 섹션 인계 → Unity MCP 시뮬 가동(별도 PD 지시) → 경계값 테이블 v1.0.0 산출 → balance-designer 마진 재검토 |
-| 31 | 2026-04-17 | P24 "기각안" 필드 필수화 — 헌법 제1원칙 목표 2 원칙 B(인사이트 기록) 직결. 기획팀장 `2026-04-17_업무공유체계_점검_기획팀.md` 안건 1 채택 | **완료** | SKILL.md P24 본문 개정(결정·설계 엔트리 필수화 + 기각안 필드 필수화 근거 섹션 신설). 적용 주체: PM·팀장급·전문 에이전트 6종·3축 감사관 공통 | - | 기획팀장·개발팀장.md에 P24 기각안 필수 지침 명시. 향후 기각안 기록률 주기 점검 |
-| 30 | 2026-04-17 | 기획팀장 맥락 오류(plan-auditor "미신설" 오인) 원인 점검 + 재발 방지 조치 | **완료** | (1) 원인 2중 진단: 기획팀장.md·개발팀장.md가 폐기된 P20(일일보고) 잔존 + P24·P26·P27 미반영 + PM이 Agent 호출 시 최신 헌법급 변경 요지(d33b8be) 프롬프트 누락 (2) 조치: SKILL.md P27-2 "호출 프롬프트 필수 3요소" 추가, 기획팀장·개발팀장.md에 P24·P26·P27·3축 감사관 지침 신설, 구 P20 지침 제거 | - | PM 호출 프롬프트 체크리스트 운영 강제 — 차기 Agent 호출 시 (가)활성 PD 지시 요약 (나)최근 헌법급 변경 요지 (다)관련 신규 에이전트·도구 3요소 필수 포함 |
-| 27 | 2026-04-16 | 유니티 프로젝트 현재 상태 점검 — 기존 분석 산출물(개발/ 10건, 기획/ 12건) 유효성 교차 검증 | **완료** | `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md` (8,683 bytes 실측 확인) | - | 후속: xlsm SOT 확정, Spine 도입 현황 개발팀 확인, GameManager.cs 소재 파악 (별도 신규 지시 필요 시 등록) |
-| 26 | 2026-04-16 | PM 통합 허브 + 부서 독립 세션 하이브리드 구조에 대한 기획팀장 의견 제출 | **완료** | `공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md`. 총괄PM 교차 검토 후 보완 5건 구현(`c14348b`) | - | - |
-| 25 | 2026-04-16 | 조직 프로세스 고도화 3대 문제 기획팀장 개선안 제안 | **완료** | `공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md`. 총괄PM 교차 검토 후 통합 6건 구현(`6768969`) | - | - |
-| 24 | 2026-04-15 | (PD님 직접 승인 — Git 4건 일괄, 범조직 공통) **GIT동기화방안 v2 §8 결재 확정** ⑧ 밸런싱 .xlsm B안 외부 SOT 유지 + ⑨ 스킬 모듈 A안 기획팀 전용 유지 (기획팀장 권고 채택). #8 항목 종결 | **완료** | v2 §8 갱신 + 조직공지 + main 반영 | - | 후속: 미래 .xlsm 편입 시 외부 SOT 운영 방침 유지, 스킬 모듈은 차기 프로젝트 시점 재평가 |
-| 23 | 2026-04-15 | (PD님 직접 승인, 범조직 공통 — A안) **C17-3 동기화 블록 5단계 정제** | **완료** | C17-3 본문 갱신 수령 | - | - |
-| 22 | 2026-04-15 | (PD님 직접 승인, 범조직 공통 — B안) **운영 자동화 Phase 1+2 적용** | **완료** | 기획팀 CLAUDE.md @import 추가 + .claude/settings.json hook 동기 | - | - |
-| 21 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **C17-3-α 신설 — 복사 명령어 간결화 원칙** | **완료** | C17-3-α + 메모리 신설 + main 반영 | - | - |
-| 20 | 2026-04-15 | (PD님 직접 승인, 범조직 공통) **C20-7 신설** | **완료** | 기획팀장 동기화 명령 포함 + main 반영 | - | - |
-| 19 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **C20 신설 — 팀장급 커밋·푸시 재량 원칙** | **완료** | 조직공지 + CLAUDE.md 최근 규칙 변경 + 본문 수령 확인 | - | - |
-| 18 | 2026-04-15 | (PD님 직접 위임) **기획팀장 결정 문의 처리 — 총괄PM 권한 행사** | **완료** | #11·#12 상태 정정 완료 + main 병합 진행 | - | - |
-| 17 | 2026-04-15 | (PD님 직접 승인, 범조직 공통) **C17-3 보강 — 진입 절차 3요소 의무** | 완료 | 조직공지 + CLAUDE.md 최근 규칙 변경 수령 확인 | - | - |
-| 16 | 2026-04-15 | (PD님 직접 승인, 범조직 공통) **C19 신설 — 승인 범위 엄격 해석 원칙** | 완료 | 조직공지 + CLAUDE.md 최근 규칙 변경 수령 확인 | - | - |
-| 15 | 2026-04-15 | (PD님 직접 지시·처분, 범조직 공통 공유) **총괄PM 절차 위반 영구 기록** | 완료 | `공유/조직공지/2026-04-15_절차위반_영구기록_승인범위_확대해석.md` 수령 확인 | - | - |
-| 14 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **C18 신설 + C17 보강** | 완료 | 조직공지 수령 + CLAUDE.md 최근 규칙 변경 갱신 | - | - |
-| 13 | 2026-04-15 | (PD님 직접 지시, 범조직 공통 공유) **코어 프레임워크 목적 정정 — R&D 자산화** | 완료 | 조직공지 수령 확인 | - | - |
-| 12 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **C17 신설 — 세션 이동 복사 명령어 동봉 의무** | **완료** | C17 신설 + 조직공지 + CLAUDE.md 갱신 (C10-6 3중 전파) | - | - |
-| 11 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **조직 비전(목표 3건)을 헌법 제1원칙으로 편입** | **완료** | 헌법 제1원칙 섹션 신설 + 조직공지 + CLAUDE.md 갱신 (C10-6 3중 전파) | - | - |
-| 10 | 2026-04-15 | (PD님 직접 지시, 전 부서 일괄 하달) **조직 노하우 git 최종 동기화 점검** | **완료** | 3축 검증 완료: 파일 존재·git 추적·원격 반영 실측 일치 | - | - |
-| 9 | 2026-04-15 | (PD님 직접 지시, 범조직 공통) **새 PC 셋업 결과를 코어룰로 정식화 (C16 신설)** | **완료** | C16 신설 + 조직공지 + 신PC 체크리스트 v2 + 메모리 갱신 | - | - |
-| 8 | 2026-04-15 (총괄PM 경유) | GIT동기화방안 v2 ⑧⑨ 기획팀장 수렴 | **완료** | #24 PD님 일괄 승인으로 종결 | - | - |
-| 7 | 2026-04-15 (세션 말미) | 기획팀장 자기검증 — 진행 작업이 총괄PM에 공유되었는지 체크·보고 | 완료 | 로그 소급 등록 + 일일보고 작성 완료 | - | - |
-| 6 | 2026-04-15 (위와 동시 지시) | 재발 방지 규칙 정비 | 완료 | C10을 C10-1~C10-5로 확장 + 교훈 기록 + CLAUDE.md 환기 메모 추가 | - | - |
-| 5 | 2026-04-15 (위와 동시 지시) | C10 선행 검증 범위 확대 노하우 조직 공유 | 완료 | `공유/조직공지/` 폴더 신설 + 의무화 공지 작성 | - | - |
-| 4 | 2026-04-15 (C3 자진 보고 직후) | Phase 3 산출물 처리 방향 결정 — **C안 채택** | 완료 | Phase3 v1 삭제, REQ001~003 상태 갱신 | - | - |
-| 2 | 2026-04-15 (세션 중반) | 공통 업무 규칙 공지 예고 | 완료 | 후속 규칙 전달 시 이행 | - | - |
-| 1 | 2026-04-15 (세션 초반) | 기획팀-개발팀 유기적 연동 체계 구축 | 완료 | `공유/README.md` 신설 + 연동 폴더·CLAUDE.md 섹션·메모리 기록 | - | - |
+
+(BurningTimes 조직 신규 — 완료 아카이브 초기화 상태)
diff --git a/공유/개발팀_백업/README.md b/공유/개발팀_백업/README.md
deleted file mode 100644
index 8f3bfaf..0000000
--- a/공유/개발팀_백업/README.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# 개발팀 백업 저장소
-
-Unity MCP 편집 표준 워크플로우(`공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`) 3단계 산출물 저장소.
-
-## 구조
-
-```
-공유/개발팀_백업/
-├─ README.md                                   # 본 파일
-├─ {프로젝트}/                                 # 프로젝트별 하위 디렉토리
-│   └─ {원본파일명}.bak_{YYYYMMDD_HHMM}.{확장자}
-```
-
-## 명명 규칙
-
-- 파일명: `{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` (C6-1 표준 포맷 준수)
-- 프로젝트 디렉토리: `수상한잡화점` · `FilGoodBandits` · `코어프레임워크` 등 (하이픈·공백 없는 1단어)
-- 복수 수정 시 **원본당 1회만** 백업 (같은 세션·같은 원본 재편집은 첫 백업 재사용)
-
-## 예시
-
-```
-공유/개발팀_백업/FilGoodBandits/IngameStageData.cs.bak_20260420_1430.cs
-공유/개발팀_백업/수상한잡화점/UIStage.cs.bak_20260420_1500.cs
-```
-
-## 금지
-
-- 경로 임의 변경 (표준 포맷 벗어남 금지)
-- `.bak-*`·Unix timestamp 형식 (C6-1 표준 포맷 위반)
-- 백업 파일 미commit 방치 (세션 종료 시까지 untracked 금지)
-- 복수 원본 일괄 편집 시 일부 백업 누락 (전수 백업 원칙)
-
-## 관리 책임
-
-- **작성 책임**: Unity MCP 편집 주체 (개발팀장·클라이언트팀장·게임플레이 등)
-- **감독 책임**: 개발팀장
-- **감사 검증**: dev-auditor (주기 감사 시 백업 파일 존재 여부·명명 규칙 체크)
-
-## 정리 정책
-
-본 시점(2026-04-20)까지는 **전량 보존**. 누적 용량 이슈 발생 시 PM·개발팀장 협의 후 보존 기간 규칙 제정.
-
-## 연관 자산
-
-- 표준 워크플로우: `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
-- 신설 근거: `memory/org/feedback_c6_backup_before_edit_violation.md`
-- 규칙 본문: C6-1 (SKILL.md)
diff --git a/공유/개발팀_백업/개발_팀장_v1.md.bak_20260421_0139.md b/공유/개발팀_백업/개발_팀장_v1.md.bak_20260421_0139.md
new file mode 100644
index 0000000..a0844fb
--- /dev/null
+++ b/공유/개발팀_백업/개발_팀장_v1.md.bak_20260421_0139.md
@@ -0,0 +1,202 @@
+---
+type: 시행착오_아카이브
+scope: 개발팀_통합
+author: 개발팀장
+date: 2026-04-21
+version: v1
+project_source: 수상한잡화점 (NerdNavis, 2025-2026)
+project_target: EerieVillage (BurningTimes, 2026~)
+---
+
+# 개발팀 통합 시행착오 아카이브 v1 — 서버·클라이언트·QA 총괄 관점
+
+## 1. 개요 — 핵심 교훈 10건 요지
+
+1. **C11(개발 관점 3축) 판정을 기획 요청 수용 전에 반드시 선행한다** — 자원 효율성·코드 직관성·범용성 3축을 통과하지 못하는 설계는 은폐하지 말고 제기(C3).
+2. **시뮬레이터 이원화(Python vs Unity C#)는 조직 생존급 리스크** — 동일 로직 2언어 유지는 밸런스 신뢰도 붕괴 경로. Unity MCP EditMode 단일 SOT 전환이 근원 해결.
+3. **서버 Critical 보안 3종(IAP 영수증·AES 하드코딩·클라 전투 연산)은 서비스 오픈 블로커**. 서버팀 가동 전 "보류"로 잠시 미뤘더라도 복원 계획과 메모리 SOT(`project_shop_security_pending.md`)를 반드시 유지.
+4. **Unity MCP 편집은 6단계 표준 워크플로우(SHA 확보→원본 Read→백업→commit→편집→검증) 없이 진행 금지** — C6-1 원본 보호 재발 방지 단일 SOT.
+5. **Agent 호출 시 절대 경로 하드코딩 금지 (C34-11)** — worktree 경계를 넘어 main 체크아웃에 변경이 기록되는 실증 사건 재발 방지. `git rev-parse --show-toplevel` 기반 상대 경로.
+6. **worktree-local 저장 자산은 조직 생존급 위험 (C34-15 5문항 체크)** — `.live/`·`memory/org/`·audit 3종 중앙 Junction 근원 해결. 신규 설정·저장소 설계 시 5문항 체크 통과 의무.
+7. **코어 프레임워크(BT.Framework)는 현 프로젝트 비투입·조직 자산 계승(P29)** — 수상한잡화점 R&D 자산 경로(`수상한잡화점/개발/06_*`)에 코어 설계 문서를 두면 오인 유발. `프로젝트/코어프레임워크/` 단일 SOT.
+8. **콘솔 병렬 실행·핫리로드 대안은 기술 검토 없이 결론 금지** — SessionStart/UserPromptSubmit hook 경계, `@import` 구문의 "세션 시작 1회만 확장" 한계 등 Claude Code 내부 메커니즘 실측 선행.
+9. **서버 권한 분배표를 명시하여 "클라가 SOT인 영역"을 정직하게 기록** — Q-P1·Q-P2·Q-P3 같은 기획 질의에 "클라 코드가 실질 SOT"임을 명시해야 괴리 재발 차단.
+10. **QA 게이트: Unity 빌드 오류·콘솔 에러 잔존 상태로 작업 종료 금지 (P14)** — 회귀 검증은 동일 경로 재현 포함. "임시로 돌아가는 코드"는 C2·C11 동시 위반.
+
+---
+
+## 2. 시도한 방법·이유·결과·교훈 (4필드 표)
+
+### 2-1. 아키텍처·설계
+
+| 시도한 방법 | 이유 | 결과 | 교훈 |
+|------------|------|------|------|
+| Python 3종 시뮬(`battle_sim`·`full_stage_sim`·`stage_sim_v2`) + Unity C# 실코드 병행 | 기획팀 Python 숙련도·빠른 밸런스 반복 | 메커닉 SOT 불일치(예: `PCDefence_Mul=0.3f` 실측 vs 기획 가정 50%) · 괴리 발견 루프 무한 발생 | Unity MCP EditMode 단일 SOT로 일원화. Python은 참조 구현으로만 존치(동기화 검증 테스트 동반) |
+| 카드 311장을 개별 스크립트로 구현 시도(초기) | 카드별 특수 효과 구현 편의 | 신규 카드 추가 = 코드 수정 필요 · 시너지 조합 폭증 대응 불가 | 데이터 드리븐 아키텍처 강제(`e_CardType` enum + 파라미터 JSON). "신규 카드가 JSON 한 줄 수정으로 끝나는가?" 핵심 질의 |
+| 수상한잡화점 내부에 `BurningTimesCore` 네임스페이스 일부 혼재 | 초기 분리 부족 | 프로젝트 특수 로직과 범용 모듈 경계 모호 · 차기 프로젝트 재활용 어려움 | P29 코어 프레임워크 독립 레포(`BT.Framework`) 분리. 수상한잡화점은 비투입, 개발 과정에서 추출 대상만 식별(`02_수상한잡화점_추출대상_v1.md`) |
+| Tier 1 16종 단일 라운드 일괄 구현 시도 | 빠른 완결 | Data·Event·Container 3종은 상호작용 설계 재검증 필요 · 아키텍처 부채 우려 | 13종 선행 라운드 완결 후 3종을 #36 신규 지시로 분리. 라운드 완결 아카이브 원칙(`feedback_log_round_completion.md`) 정착 |
+
+### 2-2. 서버·보안
+
+| 시도한 방법 | 이유 | 결과 | 교훈 |
+|------------|------|------|------|
+| PlayFab 주 백엔드 + Firebase 병행 시도 | 분석·크래시 수집 | `google-services.json` 부재 · Firebase 사실상 비활성 | INetworkService 추상화(BurningTimesCore 누락 모듈)로 백엔드 교체 가능 구조 선행 |
+| 12시간 자동 재로그인 · `ServerInfo.cs` 단일 허브 | 세션 유지 단순화 | 구조 직관성 확보 · 한편 PlayFab 직접 의존 고착 | 허브 패턴은 유지하되 인터페이스 추상화. 교체 시 허브만 재구현 |
+| 전투 연산 100% 클라이언트 | Unity 내부 연산 편의·초기 속도 | 변조 방어 불가 · 랭킹·이벤트 보상 악용 경로 | 최소한 "스테이지 클리어 판정·보상 지급"은 서버 재연산 필수(P0). 전체 재연산은 점진 확장 |
+| AES 키 소스 평문 하드코딩 · IL2CPP 의존 | 빌드 난독화 신뢰 | 메모리 덤프로 추출 가능 · 사실상 무의미 | 런타임 유도(디바이스ID 해시 혼합) + 서버 전송 페이로드 HMAC 서명. 키 회전 경로 확보 |
+| IAP 영수증 검증 주석처리 상태로 방치 | 서버팀 미가동 대기 | 결제 우회 경로 오픈 상태 · 오픈 블로커급 | "보류" 상태에서도 반드시 메모리 SOT(`project_shop_security_pending.md`) + PD 지시 로그 보류 사유·사후 조치 기록(P19). 서버팀 가동 즉시 P0 복원 |
+| ACTk 약 10개 필드만 `Obscured*` · Detector 미사용 | 초기 최소 적용 | SpeedHack·TimeCheck 방어 공백 | 재화·레벨·카드 보유 수량 전면 `Obscured*` · `SpeedHackDetector`·`TimeCheckDetector` 활성화 |
+
+### 2-3. 코어 프레임워크(BT.Framework)
+
+| 시도한 방법 | 이유 | 결과 | 교훈 |
+|------------|------|------|------|
+| 코어 설계 문서를 `수상한잡화점/개발/06_*`에 배치 | 작성 편의 | R&D 비투입 방향 확정 후 "수상한잡화점 산출물"로 오인 유발 | `프로젝트/코어프레임워크/01~04` 단일 SOT로 이동·참조 경로 교체. 06은 "대체됨" 표식 |
+| `Convert.ChangeType` 캐시 방식 Enum 변환 | BCL 표준 | 박싱 발생·핫패스 성능 저하 | `Unsafe.As<,>` 제로-박싱 전환. EnumToInt 단일 SOT |
+| KeyMaker 구분자 `_` 혼용 | 관례 | 수상한잡화점 `_`/`:` 혼재로 조회 실패 경험 | `:` 단일 표준. 전 프로젝트 강제 |
+| UnityEngine 의존 허용 시도 (일부 Util) | Unity 편의 | 서버·배치 재사용 불가 · C11 범용성 위반 | Tier 1은 순수 BCL 의존만. Unity 의존 모듈은 별 asmdef 분리 |
+| CsvHelper 외부 라이브러리 검토 | 파서 완결성 | Tier 1 외부 의존 최소 원칙 위반 · PC 독립 설치 리스크 | RFC 4180 핵심(쉼표·따옴표·escape)만으로 자체 구현. 기획팀 통제 CSV라 충분 |
+| Newtonsoft.Json 도입 검토 | Dictionary·polymorphism 지원 | PC 독립 설치 보장 어려움 | Unity `JsonUtility` + 래퍼 채택. 한계 명시 후 고급 케이스는 호출자 자체 파싱 경로 안내 |
+| 3개 모듈(Event·Container·Data) asmdef 분리 검토 | 경계 명확화 | 현 파일 수 규모에서 단일 참조 소비자 경험 우위 | 단일 asmdef 유지. Tier 2 확장 시 재검토 |
+
+### 2-4. 개발 인프라·운영
+
+| 시도한 방법 | 이유 | 결과 | 교훈 |
+|------------|------|------|------|
+| 같은 디렉토리에서 CLI 여러 개 병렬 실행 | 가장 간단 | 동일 파일 동시 수정 시 덮어쓰기 · git 이력 꼬임 | 서로 다른 파일/영역·읽기 전용에만 허용. 수정 작업은 `--worktree` 격리 |
+| `CLAUDE_LIVE.md` 핫 리로드 시도 | 세션 중 규칙 반영 | `@import`는 세션 시작 1회만 확장 · 자동 반영 불가 | UserPromptSubmit hook의 `.live/` 증분 주입 경로로 근원 해결(C34) |
+| `.live/` 더미를 `$REPO_ROOT/.live/`에 저장 | 레포 내부 단순화 | worktree마다 물리 격리 발생 · 세션 간 실시간 공유 실패 | `$HOME/.claude/nerdnavis-live/` 중앙 저장 + worktree junction 연결 (C34-3) |
+| `memory/org/`를 junction만으로 관리 | 중앙화 편의 | Windows core.symlinks 이슈·한국어 경로 리스크·clone 후 접근 불가 | 레포는 실체 디렉토리 유지 + sync 스크립트 4계층 양방향 동기화 (C34-16) |
+| Agent 프롬프트에 절대 경로 `E:\...` 지정 | 호출 편의 | worktree 경계 이탈 · main 체크아웃에 파일 생성 실증(2026-04-18) | cwd 기준 상대 경로 의무 + `git -C` 교차 확인 + 경계 이탈 복구 절차 정착 (C34-11) |
+| 빌드 오류·콘솔 에러 잔존 상태로 PR 머지 | 속도 우선 | 회귀 버그 빈발 · QA 비용 누적 | P14 QA 게이트: 빌드 오류·콘솔 에러 0 원칙. 회귀 검증은 동일 경로 재현 포함 |
+| git 동기화 Phase 0~4 체계(NAS·post_receive·sync_signal·post-commit hook) | PC 독립 실시간 공유 | 초기 단계에서 경로·권한 이슈 다수 → 점진 안정화 | setup 스크립트 단일 SOT로 PC 독립 셋업 보장(C16). 신 PC 합류 시 `verify_setup` 3축 검증 |
+
+### 2-5. Agent 경계·대화로그
+
+| 시도한 방법 | 이유 | 결과 | 교훈 |
+|------------|------|------|------|
+| 서브에이전트 인용 응답을 PM이 직접 작성(역할 연기) | 편의 | C23 위반 (2026-04-15 실증) · 조직 신뢰 훼손 | Task 도구 실제 호출 결과만 인용. 미확인 항목은 "미확인" 태그 |
+| 완료 후 PD 지시 로그 갱신 누락 | 작업 우선 | 다른 세션이 "진행중"으로 오인 (2026-04-16 #27 실증) | C27·C29-4 동기화 4종(PD 로그·대화로그·소통 채널·Live 더미) 동시 수행 |
+| 설계 문서 참조만 남기고 본문 미작성 | 속도 | "유령 문서" 발생 · P18 위반 | 참조 시점 즉시 작성 착수 또는 "작성 예정(담당·재개 트리거)" 명시 |
+| 08 전투시스템 SOT와 시뮬레이터 SOT 간 실측값 전파 누락 | 단일 작업만 수행 | #37 완료 후 08이 기획 가정값 유지 · 괴리 재발 위험 | 수치 확정 시 "해당 수치 등장하는 모든 SOT 전수 grep" 완료 체크리스트 편입 |
+
+---
+
+## 3. BT 조직 착수 시 체크리스트 (개발팀장 기준)
+
+### 3-1. 세션 시작 직후 (C10-1·C16-4 연속 이행)
+- [ ] `git fetch origin && git status` (조직 레포)
+- [ ] Unity 프로젝트(`${UNITY_PROJECT_ROOT}`) `git fetch && git status` (C30)
+- [ ] 코어 프레임워크(`BT.Framework`) `git fetch && git status`
+- [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 활성 테이블 전수 Read
+- [ ] `공유/대화로그/EerieVillage/` 최근 2일 Read + `공유/대화로그/코어프레임워크/` 최근 2일 Read
+
+### 3-2. 신규 기능·시스템 설계 착수 전
+- [ ] C11 3축 판정 (자원 효율성·코드 직관성·범용성) 자문
+- [ ] "신규 {카드·적·아이템·이벤트} 추가가 JSON 한 줄로 끝나는가?" 데이터 드리븐 성립 확인
+- [ ] 프로젝트 특수 vs 범용 모듈 경계 명시 (범용은 BT.Framework 추출 대상 식별)
+- [ ] P18 설계 문서 선행 작성 (배경·대안·구현 가이드·검증 방법·변경 이력 5요소)
+- [ ] 기획 요청이 C11과 충돌하면 C3에 따라 우려 즉시 제기
+
+### 3-3. Unity 코드·씬·프리팹 편집 전
+- [ ] Unity MCP 편집 대상이면 6단계 표준 워크플로우(`공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`) 준수
+- [ ] 백업 파일: `공유/개발팀_백업/EerieVillage/{원본}.bak_{YYYYMMDD_HHMM}.{ext}`
+- [ ] `precondition_sha_256` 파라미터로 외부 변경 방어
+- [ ] 편집 후 `get_sha` 재확인 + 콘솔 에러 0 검증
+
+### 3-4. 서버 연동 작업 전
+- [ ] 전투·재화·IAP·랭킹·보상 중 어느 영역인지 식별
+- [ ] 해당 영역의 서버 권한 vs 클라 권한 표 갱신
+- [ ] Critical 보안 3종(IAP 영수증·암호화 키·전투 연산) 재발 여부 체크
+- [ ] 신 프로젝트는 백엔드 추상화(INetworkService) 선행 — PlayFab 직접 의존 금지
+
+### 3-5. Agent 호출·worktree 작업 전
+- [ ] Agent 프롬프트에 "cwd 기준 상대 경로 사용 의무" 명시 (C34-11)
+- [ ] 산출물 경로는 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로
+- [ ] Agent 응답 수령 직후 `git -C <레포루트> status` + 본 worktree `git status` 병행 확인
+- [ ] 신규 공용 저장소·hook·설정 도입 시 C34-15 worktree 경계 5문항 체크 통과
+
+### 3-6. 작업 완료 시 (C29-4 동기화 4종)
+- [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 상태 갱신 (완료 아카이브 즉시 이동 + 즉답 접두)
+- [ ] `공유/대화로그/{프로젝트}/YYYY-MM-DD.md` 엔트리 추가 (결정·설계는 "기각안" 필드 필수)
+- [ ] 소통 채널 응답서 `status: 완료` + `공유/소통/완료/`로 이동
+- [ ] `.live/` 더미 기록 (세션 갱신 전 즉시 트래킹)
+- [ ] 수치·SOT 변경 시 "해당 수치 등장 모든 SOT 전수 grep" 수행 (#37 누락 재발 방지)
+
+---
+
+## 4. PM 보고 안건 (특이사항)
+
+1. **서버 Critical 보안 3종 복원 계획 수립** — 신 프로젝트 EerieVillage의 서버팀 가동 시점에 수상한잡화점 보류분 3종(IAP·AES·전투 연산)의 복원 전략을 PD님께 사전 보고. 메모리 SOT `project_shop_security_pending.md` 계승 여부도 결정 필요.
+
+2. **코어 프레임워크 Tier 2·3 진입 경계 확정** — Tier 1 16/16 완료 시점에서 Tier 2(Network·Persistence·UI 공용)·Tier 3(게임 장르별) 진입 조건을 EerieVillage 요구사항과 연계하여 PD님 결정 안건화. P29 "현 프로젝트 미활용·차기 프로젝트 적극 활용" 원칙 적용.
+
+3. **Unity MCP 편집 표준 워크플로우 v1 EerieVillage 적용 범위 확정** — BT.Framework 편집은 명시 적용. Unity 씬·프리팹(비스크립트)은 현 버전 미포함. v2 확장 여부 PD 결정.
+
+4. **시뮬레이터 이원화 재발 방지** — EerieVillage는 착수 시점부터 "Unity MCP EditMode 단일 SOT" 확정. Python 시뮬은 참조 구현으로만 허용하되 자동 동기화 검증 테스트 의무화를 PD 승인 안건화.
+
+5. **PC 독립 셋업 신 PC 합류 프로토콜** — 신 스태프·신 PC 추가 시 `setup_windows.ps1`·`setup_macos.sh` + `verify_setup` 3축 검증 의무. 실패 시 Degraded 운영이 아닌 조직공지 이슈화.
+
+6. **dev-auditor 모드 A(중요 기술 결정)·모드 B(주기 감사) 운영 정착** — 3축 감사 체계 중 개발 영역 감사가 실무 정착 초기 단계. EerieVillage 착수 초반에 모드 A 호출 빈도를 높여 학습 데이터 축적.
+
+---
+
+## 5. 참조 원본 파일 목록 (감사 재현 가능)
+
+### 5-1. 수상한잡화점 개발 산출물
+- `프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md`
+- `프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md`
+- `프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md`
+- `프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md`
+- `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md`
+- `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md` (대체됨 → `프로젝트/코어프레임워크/01~04`)
+- `프로젝트/수상한잡화점/개발/07~13_*.md` (Phase 3 재개 로드맵 포함)
+
+### 5-2. 코어 프레임워크 (BT.Framework)
+- `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`
+- `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md` (완료 실적 아카이브)
+- `프로젝트/코어프레임워크/03_배포방식_안건_v1.md`
+- `프로젝트/코어프레임워크/04_Tier1_3종_상호작용_설계_v1.md`
+- `코어코드/BT.Framework/Runtime/Core/` 전체
+
+### 5-3. 대화로그
+- `공유/대화로그/코어프레임워크/2026-04-16.md`
+- `공유/대화로그/코어프레임워크/2026-04-17.md`
+- `공유/대화로그/코어프레임워크/2026-04-18.md`
+
+### 5-4. 소통 채널 (완료)
+- `공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md`
+- `공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md`
+- `공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md`
+- `공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md`
+- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
+- `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md`
+- `공유/소통/완료/2026-04-17_서버_작업_참고자료.md`
+- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md`
+- `공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md`
+
+### 5-5. 개발팀→PM 자체 감사·검토
+- `공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md`
+- `공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md`
+- `공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md`
+- `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`
+- `공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md`
+
+### 5-6. 조직 자산·표준 워크플로우
+- `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
+- `공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx` (접근 가능 시)
+- `공유/개발팀_백업/` (원본 백업 SOT)
+
+### 5-7. feedback 메모리 (재발 방지 SOT)
+- `memory/org/feedback_agent_path_boundary.md` — Agent 절대 경로 유출 실증
+- `memory/org/feedback_worktree_isolation.md` — worktree 격리 5문항 체크
+- `memory/org/feedback_git_scope_shortcut.md`
+- `memory/org/feedback_dev_auditor_*.md` — 개발 감사 실증
+- `memory/org/feedback_memory_sync_overwrite.md` — memory sync 덮어쓰기 실증
+- `memory/org/feedback_c6_backup_before_edit_violation.md` — Unity MCP 편집 백업 누락
+- `memory/org/feedback_log_round_completion.md` — 라운드 완결 아카이브 원칙
+- `project_shop_security_pending.md` — Critical 3종 보류 SOT
+
+---
+
+*본 아카이브는 BurningTimes 조직이 EerieVillage 및 차기 프로젝트 착수 시 동일한 시행착오를 반복하지 않고 검증된 방법을 재활용하기 위한 개발팀 통합 관점 SOT이다. PD 지시 2026-04-21 "조직 자산 계승" 이행 산출물.*
diff --git a/공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md b/공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md
deleted file mode 100644
index 7a03bfa..0000000
--- a/공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md
+++ /dev/null
@@ -1,124 +0,0 @@
-# Unity MCP 편집 표준 워크플로우 v1
-
-> **단일 SOT.** 개발팀의 모든 Unity MCP 편집 작업은 본 워크플로우 6단계를 따른다.
-> **신설**: 2026-04-20 (PD 지시 #57 — C6-1 재발 방지)
-> **근거**: `memory/org/feedback_c6_backup_before_edit_violation.md` (C6-1 원본 백업 누락 1회차 실증)
-> **관리 책임**: 개발팀장
-
----
-
-## 적용 범위
-
-본 워크플로우는 다음 도구를 통한 Unity 프로젝트 스크립트 변형 작업에 **예외 없이 적용**된다:
-
-- `mcp__unity-mcp__apply_text_edits`
-- `mcp__unity-mcp__script_apply_edits`
-- `mcp__unity-mcp__create_script` (신규 생성은 원본 변형 아님 — 4·5단계만 적용)
-- `mcp__unity-mcp__delete_script` (삭제는 C6-1 "원본 파일 임의 삭제 금지" 우선 적용 — 팀장 검토 필수)
-
-**비적용 범위**: Unity MCP 조회 도구(`get_sha`·`read_console`·`find_gameobjects`·`manage_scene` 등 비파괴 작업)
-
----
-
-## 6단계 표준 워크플로우 (착수 전 의무)
-
-### 1. 원본 SHA 확보 — `mcp__unity-mcp__get_sha`
-
-편집 대상 스크립트의 현재 SHA 값을 기록한다. 편집 후 재확인 단계(6번)에서 변경 확인·회귀 방지에 사용.
-
-```
-mcp__unity-mcp__get_sha(uri="unity://path/Assets/Script/InGame/.../Target.cs")
-→ sha: abc123... (기록)
-```
-
-### 2. 원본 본문 확보 — `mcp__unity-mcp__manage_script`
-
-```
-mcp__unity-mcp__manage_script(action="read", uri="unity://...")
-→ 본문 전체 반환
-```
-
-전체 본문을 메모리에 보관. 다음 단계 백업 저장에 사용.
-
-### 3. 원본 본문을 조직 레포 백업 경로에 저장
-
-**백업 경로 표준**:
-```
-공유/개발팀_백업/{프로젝트}/{원본파일명}.bak_{YYYYMMDD_HHMM}.{확장자}
-```
-
-- `{프로젝트}`: `수상한잡화점` · `FilGoodBandits` · `코어프레임워크` 등 (하이픈·공백 없는 1단어)
-- `{YYYYMMDD_HHMM}`: 현지 시각 기준 24시간제 (C6-1 표준 포맷 준수)
-- 복수 수정 시 **원본당 1회만** 백업 (같은 세션·같은 원본 재편집은 첫 백업 재사용)
-
-**예시**:
-```
-공유/개발팀_백업/FilGoodBandits/IngameStageData.cs.bak_20260420_1430.cs
-```
-
-### 4. 백업 파일 commit (또는 최소 local stash)
-
-- **일반**: 매니페스트 등록된 집행 단위에서 백업 파일도 target_files에 포함 → commit 포함
-- **긴급 예외**: commit 지연 시 최소한 `git stash push -u -- 공유/개발팀_백업/{프로젝트}/` 로 untracked 보존
-- **commit 메시지 표준**: `backup(unity-edit): {프로젝트}/{원본파일명} - {집행 목적 1줄}`
-
-### 5. 편집 집행 — `apply_text_edits` / `script_apply_edits`
-
-- `precondition_sha_256` 파라미터에 **1단계에서 확보한 SHA 지정** → 편집 중 외부 변경 감지·방어
-- 편집 실패 시 재시도 전 백업 파일 존재 확인 (손실 경로 차단)
-
-### 6. 편집 후 검증
-
-**필수 3종**:
-1. **SHA 재확인**: `mcp__unity-mcp__get_sha` → 1단계와 다른 값인가? (편집 반영 확인)
-2. **Unity 컴파일·리프레시**: `mcp__unity-mcp__refresh_unity` 또는 `manage_editor(action="refresh")`
-3. **console 에러 0**: `mcp__unity-mcp__read_console(include_stacktrace=false)` → error 0건 확인
-
-**선택 2종** (권고):
-- `validate_script` — 구문 검증
-- `find_in_file` — 편집 위치 심볼 재확인
-
----
-
-## 복구 절차 (편집 실패·회귀 필요 시)
-
-1. 편집 중 실패: `precondition_sha_256` 불일치 등 → 백업 파일 재사용 필요 없음 (원본 미변형)
-2. 편집 성공 후 롤백 필요: 백업 파일로 `script_apply_edits(replace_method)` 역방향 집행 또는 `manage_script(action="create", overwrite=true)` 전체 복원
-3. 복구 경로 3중 확보 원칙 (feedback SOT §영향 범위 3종 복구 경로 계승):
-   - 백업 파일 (본 워크플로우 3단계 산출물)
-   - `script_apply_edits` 역방향 치환 (기획 변경 취소 시)
-   - Unity Editor undo 체인 (세션 내 단기 회복)
-
----
-
-## 금지 행위
-
-- **백업 단계 건너뛰기**: "SHA만 확인하고 바로 편집" 금지. C6-1 명시 위반
-- **백업 경로 임의 지정**: 조직 레포 외부·상대 경로·타임스탬프 누락 금지
-- **백업 파일 미commit 방치**: 세션 종료 시까지 untracked 상태 방치 금지 (git stash 또는 commit 필수)
-- **복수 원본 일괄 편집 시 일부 백업 누락**: 대상 원본 전수 백업이 원칙
-
----
-
-## 연관 규칙
-
-- **C6-1** 원본 데이터 변형 전 백업 필수 (상위 규칙)
-- **C6-2** 프로덕션 보호 (롤백 경로 확보 원칙)
-- **C11** 개발 관점 원칙 (자원 효율·코드 구조 — 백업 파일 누적 관리 필요)
-- **C30** git 동기화 프로젝트 작업 전 최신 상태 점검 (Unity 프로젝트 `git fetch && git status` 선행)
-- **C31-B** 응답 발신 직전 자기검증 (백업 로직 표준 포맷 체크)
-- **P13** 코드·의존성·환경 변경 관리 (공용 모듈 변경 공유)
-
-## 관련 자산
-
-- `memory/org/feedback_c6_backup_before_edit_violation.md` — 신설 근거 SOT (회차 기록 유지)
-- `공유/개발팀_백업/` — 백업 저장소 (프로젝트별 하위 디렉토리)
-- `.claude/agents/개발팀장.md`·`.claude/agents/클라이언트팀장.md` — 본 워크플로우 1줄 참조 편입
-
----
-
-## 개정 이력
-
-| 버전 | 일자 | 내용 | 근거 |
-|------|------|------|------|
-| v1 | 2026-04-20 | 최초 제정 — 6단계 워크플로우·백업 경로 표준·금지 행위 | PD 지시 #57 C6-1 재발 방지 |
diff --git a/공유/공통_업무_규칙_개정_제안_C14_C15_v1.md b/공유/공통_업무_규칙_개정_제안_C14_C15_v1.md
deleted file mode 100644
index 35e22ff..0000000
--- a/공유/공통_업무_규칙_개정_제안_C14_C15_v1.md
+++ /dev/null
@@ -1,134 +0,0 @@
-> **[반영 완료 주석]** 본 문서는 2026-04-15 시점 제안서이며, C14·C15 내용은 이미 `.claude/skills/BurningTimes-코어룰/SKILL.md`(단일 SOT)에 정식 반영 완료됨. 본 파일은 제안 경위 보존 목적의 과거 기록이며, 현행 규칙은 SKILL.md를 참조할 것.
-
-# 공통 업무 규칙 개정 제안 — C14·C15 신설
-
-- 문서 번호: 공통_업무_규칙_개정_제안_C14_C15_v1
-- 작성일: 2026-04-15
-- 작성자: 개발실장 (pm-general 보강 반영)
-- 대상 문서: `공유/공통_업무_규칙.md` (조직 공용 SOT)
-- 계층: 핵심 규칙 (코어 룰, 헌법급)
-- 변경 권한: PD님만 수정 가능 (총괄PM 팀장급 상의 후 제안 → PD님 승인)
-- 근거: PD님 2026-04-15 직접 지시 (PD 지시 로그 #6)
-- 상태: **PD님 최종 승인 대기 (총괄PM 경유)**
-
----
-
-## 개정 배경
-
-PD님께서 2026-04-15 조직 전체 Git 동기화 설계 논의 중, 다음 두 원칙을 **코어룰로 추가**하도록 직접 지시하셨다. 개발실장이 초안을 작성하고 총괄PM(pm-general)이 "참조 무결성 원칙"(C14 보강) 및 "순서 서술·기술적 타임아웃"(C15 예외) 두 건을 추가 제안하였다. 본 문서는 통합안이며, 팀장급 추가 의견·PD님 최종 승인을 받는 대로 `공통_업무_규칙.md`에 정식 편입한다.
-
----
-
-## C14. 토큰 최소화 우선 설계 원칙
-
-### 본문
-
-> 모든 업무는 **항상 토큰을 최소화할 수 있는 최적의 설계**를 가장 우선적으로 지향하고, 불가피한 경우 **PD가 결정할 수 있도록 대안을 제안**한다.
-
-### 부속 원칙
-
-**C14-1 CLAUDE.md 통합 금지**
-조직 공용 코어룰·프로젝트 룰 수준의 규칙만 상위 CLAUDE.md에 유지한다. 팀별(개발·PM·기획) 에이전트 정의·메모리·작업 노하우는 **각 팀의 `.claude/` 하위 또는 memory 파일에 분리**하고, 필요 시에만 참조한다.
-
-**C14-2 고정비·변동비 분리 설계**
-자산을 다음 두 범주로 분류하여 설계한다.
-
-| 범주 | 정의 | 예시 | 편입 기준 |
-|------|-----|-----|----------|
-| **고정비** | 매 턴 강제 로드되어 대화 전 구간에 고정 비용 발생 | CLAUDE.md, `MEMORY.md` 인덱스 | 조직 전체가 **모든 대화에서 반드시** 참조해야 하는 규칙만 |
-| **변동비** | 필요 시 `Read`·`Grep` 등으로 on-demand 참조 | `memory/*.md` 개별, 프로젝트 숙지 문서, 에이전트 정의 | 기본값. 상기 편입 기준에 부합하지 않는 모든 자산 |
-
-**C14-3 고정비 증가 결정은 PD 승인 사항**
-CLAUDE.md 신규 항목 추가, 매 턴 로드 대상 확대, `MEMORY.md` 인덱스 확장 등 **고정비를 증가시키는 변경**은 PD님 승인 후에만 가능하다. 설계 시 고정비 영향을 수치로 명시하여 제안한다.
-
-**C14-4 참조 무결성 원칙 (pm-general 보강)**
-하위 CLAUDE.md는 상위 CLAUDE.md의 내용을 **중복 기재하지 않고 참조 링크만 유지**한다. 동일 규칙이 2곳 이상 중복 기재되면 **SOT 원칙(C5 정보의 정직성) 위반**으로 간주하며, 발견 즉시 단일 SOT로 통합하고 나머지는 참조만 남긴다. 이는 C14의 CLAUDE.md 통합 금지 원칙이 **복붙에 의한 사실상의 중복 고정비**로 우회되는 안티패턴을 차단한다.
-
-### 위반 시 조치
-
-- C14-1·C14-4 위반 발견 즉시 SOT 단일화 + 나머지 참조화
-- C14-3 위반(PD 승인 없이 고정비 증가) 시 C3(이슈 은폐 금지)·C5(정직성) 준수하여 즉시 PD 보고·원복
-
-### 적용 사례
-
-- 수상한 잡화점 프로젝트 숙지 문서 10종은 `개발실/프로젝트_숙지/수상한잡화점/`에 배치, CLAUDE.md에는 경로만 기재 (변동비)
-- 기획실 스킬 모듈 5종은 `기획실/.claude/skill-modules/`에 배치, `MEMORY.md`에는 1줄 인덱스만 유지
-- 조직 공통 코어룰 C1~C15는 `공유/공통_업무_규칙.md` 단일 SOT. 루트·개발실·기획실 CLAUDE.md는 **참조만** (복붙 금지)
-
----
-
-## C15. 일정·기한 개념 배제 원칙
-
-### 본문
-
-> 에이전트 업무 프로세스에서 **일정·기한·소요시간 추정 개념을 제거**한다. "이번 주·당일·3시간 내·수일 내" 등 **시간 단위 계획은 에이전트 응답에서 사용하지 않는다.** 에이전트는 지시 수령 **즉시 착수**하며, 작업의 **종속 관계·선행 조건·차단 요인**만 관리한다. 인간(PD·스태프)과의 일정 조율이 필요한 경우 그 사실 자체만 보고하고 **일정 수립은 인간 작업자에게 이관**한다.
-
-### 부속 원칙
-
-**C15-1 금지 표현 목록**
-다음 표현은 에이전트 응답·문서·계획서에서 **사용 금지**한다.
-
-- "이번 주·다음 주·이번 달·이번 분기"
-- "당일·익일·수일 내"
-- "N시간 내·N분 내·N일 내·즉시(기한 의미로 사용 시)"
-- "일정상·기한상·데드라인·마감"
-- 기간 추정·리드타임 산정을 포함한 모든 시간 단위 계획
-
-**C15-2 허용되는 대체 표현**
-- "선행 작업 A 완료 후 착수" (종속 관계 서술)
-- "차단 요인 X 해소 시 착수" (차단 해제 조건)
-- "PD님 승인 시 착수" (의사결정 대기)
-- "현 시점 즉시 착수" (지시 수령 즉시 실행)
-
-**C15-3 예외 조항 (pm-general 보강)**
-
-- **예외 1 — 순서·종속 서술**: "선행 A 완료 후 B 착수"와 같은 **순서 관리·종속 관계 서술은 허용**. C15가 금지하는 것은 **시간 단위 추정**이지 순서 관리가 아니다.
-- **예외 2 — 기술적 타임아웃**: 빌드·테스트·네트워크 호출·CI 파이프라인 등 **시스템적으로 부여되는 타임아웃 값**(예: "5분 타임아웃 설정", "30초 대기")은 일정 추정이 아니라 **기술 파라미터**로서 C15 대상 외.
-
-**C15-4 인간 일정 조율 이관**
-PD·스태프와의 회의·리뷰·검증이 **실제로 일정상 의존성을 가지는** 경우, 에이전트는 **"일정 조율 필요" 사실만 보고**하고 구체적 시점은 인간 작업자가 결정하도록 이관한다.
-
-### 위반 시 조치
-
-- C15-1 금지 표현 사용 시 즉시 C15-2 대체 표현으로 재작성
-- 동일 에이전트가 반복 위반 시 해당 에이전트 역할 재검토 (개발실장은 2026-04-15 "PD 추가 지시 대기" 사례 이미 3회 재발 시 역할 재검토 기준 명시)
-
-### 적용 사례
-
-- ❌ "이번 주 내 repo 구조 확정" → ✅ "팀장급 수렴 완료 시 즉시 v2 확정"
-- ❌ "당일 착수" → ✅ "지시 수령 즉시 착수"
-- ❌ "3시간 내 보고" → ✅ "즉시 보고"
-- ✅ (예외 1) "Phase 0 dry-run 완료 후 Phase 1 착수"
-- ✅ (예외 2) "CI 파이프라인 30분 타임아웃 설정"
-
----
-
-## 기존 코어룰과의 관계
-
-| 규칙 | C14와의 관계 | C15와의 관계 |
-|------|------------|------------|
-| C1 지시=승인 | - | PD님 지시는 "즉시 착수" 트리거 |
-| C2 근원적 문제 해결 | 설계 최적화도 근원 해결 관점에서 토큰 최소화 | - |
-| C3 이슈 은폐 금지 | 고정비 증가는 즉시 보고 | 차단 요인은 즉시 보고 |
-| C4 총괄PM 하달 | - | 일정 조율은 총괄PM 경유 |
-| C5 정보의 정직성 | C14-4 참조 무결성의 근거 | 기한 추정은 환각·허위 보고 원천 |
-| C10 선행 확인 | 선행 검증 시 토큰 영향 확인 항목 추가 | 선행 검증은 순서 관리이므로 C15 대상 외 |
-| C13 PD 지시 트래킹 | 지시 로그 자체는 고정비 아님(변동비) | - |
-
----
-
-## CLAUDE.md 환기 메모 반영안
-
-C14·C15 PD님 최종 승인 확정 시, 다음 3곳에 **참조 링크 방식**(C14-4 준수)으로 반영한다. 본문 중복 금지.
-
-1. **루트 `CLAUDE.md`** 핵심 규칙 요약 섹션에 C14·C15 각 1줄씩 추가
-2. **`개발실/CLAUDE.md`·`기획실/CLAUDE.md`·향후 `PM/CLAUDE.md`** 상단 "최근 규칙 변경" 섹션에 공지 1줄
-3. **`공유/공통_업무_규칙.md`** 본문에 C14·C15 정식 섹션 신설 (본 제안서 본문이 소스)
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|-------|-----|
-| v1 | 2026-04-15 | 개발실장 (pm-general 보강 반영) | 초안. C14 부속 4항 + C15 예외 2항 포함. PD님 최종 승인 대기 |
diff --git a/공유/대화로그/INDEX.md b/공유/대화로그/INDEX.md
index 1297cd3..abcf76e 100644
--- a/공유/대화로그/INDEX.md
+++ b/공유/대화로그/INDEX.md
@@ -1,10 +1,10 @@
-# 대화로그 태그 인덱스
+# 대화로그 태그 인덱스 (BurningTimes)
 
 > 자동 갱신 또는 수동 갱신. `grep -r "#태그" 공유/대화로그/`로 검색 가능.
 
 ## 프로젝트
-- `수상한잡화점/` — 현행 게임 프로젝트
-- `코어프레임워크/` — R&D 조직 자산
+- `EerieVillage/` — 기묘한 고을: 조선퇴마뎐 (BurningTimes 첫 게임 프로젝트, 2026-04-21 출범)
+- `코어프레임워크/` — BT.Framework 조직 자산
 - `조직운영/` — 프로세스·규칙·구조 관련
 
 ## 고정 태그
@@ -13,7 +13,9 @@
 - `#완료` `#진행중` `#보류` — 상태
 
 ## 최근 로그
-- **2026-04-17: 조직운영** (C27·C28·C29·C30·C31 신설, P21·P24 개정, P26 신설 + pm-auditor 에이전트 신설, 헌법 제1원칙 목표 2 명확화, Python 시뮬 폐기, 팀 기록 체계 감사)
-- 2026-04-17: 수상한잡화점 (#28 Unity MCP 전환 개발팀·기획팀 검토)
-- 2026-04-16: 조직운영 (조직 대개편, P24 신설)
-- 2026-04-16: 수상한잡화점·코어프레임워크
+- **2026-04-21: 조직운영** — BurningTimes 조직 출범 (Phase 1·2-A·2-B·2-C 집행, NerdNavis → BurningTimes 전환)
+- 이전 NerdNavis 조직 기록(2026-04-16 ~ 2026-04-20 조직운영 대화로그)은 조직 기억 자산으로 보존 (당시 시점 이벤트 기록)
+
+## 참고
+- 이전 NerdNavis 조직의 수상한잡화점 프로젝트 진행 과정 교훈은 `공유/조직자산/시행착오_아카이브/` 14종에 영구 보존
+- BurningTimes 조직 착수 시점 기록은 `조직운영/2026-04-21.md`가 기준점
diff --git a/공유/대화로그/수상한잡화점/2026-04-16.md b/공유/대화로그/수상한잡화점/2026-04-16.md
deleted file mode 100644
index 2d3c18d..0000000
--- a/공유/대화로그/수상한잡화점/2026-04-16.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# 2026-04-16 수상한잡화점 대화로그
-
-<!-- checkpoint: 2026-04-16 #유니티프로젝트점검 -->
-
-<!-- #PD지시 #기획 #완료 #프로젝트점검 -->
-## [PM] 유니티 프로젝트 현재 상태 점검 (기획팀장 수행)
-- **요지**: 기존 분석 산출물 10건(개발/) + 기획 산출물 12건(기획/)이 현재 유니티 프로젝트 `D:/BurningTimes/FilGoodBandits/DeckBuilding/`와 일치하는지 교차 검증
-- **이유**: PD님 직접 지시 — 분석 문서 유효성 점검
-- **검증 방법**: 분석 문서(03/08/09/10번) 참조 경로 · 파일명을 실제 프로젝트에서 직접 확인
-- **판정 결과**:
-  1. **유효** (변경 없음): Unity 버전(6000.0.67f1), 핵심 스크립트 경로 9/10건, 씬 7개, Export JSON/CSV 구조, BurningTimesCore 외부 경로, 기획 산출물 참조 데이터 파일 전건
-  2. **변경됨** (갱신 필요): DeckBuilding_Ino.xlsm 오늘 수정 / Assets 신규 폴더 추가(EquipIcons, GeneratedLocalRepo 등) / Spine 런타임 csproj 5개 추가 / Res_Addr 그룹 5개 → 11개 확장
-  3. **확인 불가**: GameManager.cs 현재 위치 미확인 / Spine 도입 적용 범위 / Ino.xlsm 수정 내용의 Export 반영 여부
-- **산출물**: `공유/소통/기획팀→PM/2026-04-16_유니티프로젝트_점검_기획팀.md`
-- **상태**: 완료
-- **후속 필요**: xlsm SOT 확정, Spine 도입 현황 개발팀 확인, GameManager.cs 소재 파악
diff --git a/공유/대화로그/수상한잡화점/2026-04-17.md b/공유/대화로그/수상한잡화점/2026-04-17.md
deleted file mode 100644
index 0d78741..0000000
--- a/공유/대화로그/수상한잡화점/2026-04-17.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# 수상한잡화점 — 2026-04-17
-
-<!-- #PD지시 #이슈 #완료 #기획감사 #문서정합성 -->
-## [plan-auditor] 기획 영역 전수 정합성 감사 완료 (모드 C)
-- **요지**: PD님 직접 지시로 기획 에이전트 7종·기획 문서 12종·REQ 템플릿·어뷰징 기획서·대화로그·P17 배타 조합·JSON 숙지 보고 전수 실측. Critical 0 / Major 2 / Minor 3 / Improvement 1
-- **이유**: 최근 헌법급 변경(P24 기각안 필수·전문 에이전트 6종 기록 의무·밸런싱 md 4종 변경이력 표준화·REQ 템플릿·Unity MCP 전환·Python 시뮬 폐기) 반영 상태 점검. 불필요·중복·상충 3축 감사
-- **주요 발견**: Phase3_재개준비_체크리스트_v1·3성조건_12개_상세명세_v1 등 Phase 3 HOLD 시점 작성 문서에 "Python/C# 시뮬·Headless·개발실·기획실" 구용어·구방향 잔존. 본문 논리는 유효하나 방향 전환 미반영 (Major 2건·Minor 3건)
-- **산출물**: `공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md`
-- **기각안**: (1) 감사관이 직접 구용어 치환 — "보고만" 지시, 집행은 PM 경유(C29 정합) (2) P17 실배치 전수 검증 — Phase 3 HOLD 범위외, 감사 범위 초과 (3) 전문 에이전트 6종 공통 섹션 SKILL.md 통합 제안 — 현 중복 미미·영역 맞춤 문구 희생 이득 불분명, 차기 감사 안건으로만 기록
-- **상태**: 완료
-
-<!-- #PD지시 #기획 #완료 #JSON숙지 #준비보고 -->
-## [기획팀] JSON 데이터 숙지 준비 완료 (#39)
-- **요지**: Export 60종 JSON 전수 카탈로그 + 영역별 3단계 자가 평가(완전 26 / 부분 20 / 미정밀 14) + 전체테이블감사_v1.md 재숙지 완료. 다음 기획 지시 즉시 이행 가능 상태
-- **이유**: PD님이 다음 기획 지시 전 기획팀 숙지 상태 점검 지시. 완전 숙지 영역은 즉답, 부분·미정밀 영역은 지시 수령 시점 Read 전략 확정 (C14 토큰 최소화 정합)
-- **산출물**: `공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md` (A~F 6개 섹션)
-- **기각안**: (1) Export 60종 전수 정밀 Read — C14·C15 위반, 기획 우선도 차등 숙지가 C7 정합 (2) plan-auditor 모드 A 선행 — P27-1 호출 주체 PM 원칙, 기획팀장 재호출 불가 (3) 대화로그만 기록 — P27-4 SOT 경계, 소통 채널 병기 필요
-- **상태**: 완료
-
-<!-- #PD지시 #기획 #완료 #REQ템플릿 #밸런싱이력 -->
-## [PM 기록 보완] 기획팀 재량 3건 수상한잡화점 영향 엔트리 (plan-auditor Major M1 시정)
-- **요지**: 기획팀 #33 밸런스 요구서 표준 템플릿 신설 / #34 전문가 에이전트 6종 기록 의무 명시 + 구 P20 제거 / #35 밸런싱 md 4종(스테이지난이도곡선·밸런싱전략·전체테이블감사·빌드_조건_충돌점검) 변경 이력 테이블 표준화 — 3건 모두 완료
-- **이유**: 플랜 감사관이 "수상한잡화점 대화로그 누락(조직운영 로그에만 기록)" Major 지적. REQ 템플릿·밸런싱 md 4종은 수상한잡화점 프로젝트 영향이 명확하므로 프로젝트 로그 병기 필요. P27-4 SOT 경계 준수
-- **산출물**: `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` / `.claude/agents/{balance,content,level,narrative,system,ux}-designer.md` / `프로젝트/수상한잡화점/기획/{스테이지난이도곡선_v1,밸런싱전략_v1,전체테이블감사_v1,빌드_조건_충돌점검_v1}.md` 하단 "변경 이력(P16)" 섹션
-- **기각안**: (1) "조직운영 로그만 기록" — 프로젝트 영향 있는 결정은 프로젝트 로그도 병기 필요 (P27-4), 기각 (2) "REQ 템플릿을 개별 요구서처럼 PD 지시 로그 #화" — 상시 참조 템플릿은 진행 상태 없음, 소통 허브 유지
-- **상태**: 완료
-
-<!-- #이슈 #PM #완료 #감사시정 #C30점검기록 -->
-## [PM 기록 보완] 코어코드 레포 git 점검 기록 (dev-auditor Minor 시정)
-- **요지**: Tier 1 잔여 9종(Attribute 3 + Util 6) 구현은 외부 레포 `코어코드/BT.Framework/`에 수행됨. C30 준수 — 작업 착수 시점에 코어코드 레포 git 상태 `nothing to commit, working tree clean` 실측 확인(개발팀장 세션 내부)되었으나 대화로그 1차 엔트리에 기록 누락
-- **이유**: dev-auditor Minor 지적 — C30-3 점검 결과 증적 미기록. 사후 추적 가능하도록 1줄 보완
-- **기각안**: 없음 (명백한 누락 보완)
-- **상태**: 완료
-
-<!-- #PD지시 #개발 #완료 #서버 #결정 -->
-## [세션 시점] 서버 개발자 지시서 v1.1 요약판 재작성 완료 (#31, v1.0 대체)
-- **요지**: PD님 2건 직접 재결정 반영. (1) 어뷰징 판정 책임 = **클라 100%**, 서버는 클라가 보낸 `is_abuse_flag` 수신 시 지급 거부만 수행 (경계값 보관·검증 전부 제거). (2) v1.0 446줄 → v1.1 207줄 요약판으로 전면 재작성 (인간 서버 개발자 5~7분 완독).
-- **이유**: v1.0의 B-7 "어뷰징 방지 서버 연계" 섹션은 "서버가 경계값 받아 검증" 구조로 설계되어 있었으나 **어뷰징은 서버 개발자 작업 스펙이 아니라 클라 주도 작업**이라는 PD님 재확정으로 전면 정정 필요. 동시에 장문 지시서는 인간 개발자 파악 효율 저하 → 요약판 전환 지시.
-- **주요 변경**: (a) 섹션 5 "어뷰징 방지 — 클라 주도, 서버 최소 역할"로 정정, Title Data 경계값 적재·IsWithinAbuseThreshold 함수 구조 전부 삭제. (b) 기본 원칙 4종 + 서버 스택 현황 표 + 8개 도메인 표 + 3원칙 + API 3종(샘플 1건만 JSON) + 셋업 체크리스트 + 결정 대기 2건 + 용어집 9개 + 기각안 5건. (c) frontmatter version v1.1, supersedes v1.0 명시.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_서버개발자_업무지시서_최종본.md` (v1.1, 207줄). DOCX는 PM이 `md_to_docx.js`로 재생성 예정.
-- **상태**: 완료
-- **기각안**: (1) "어뷰징 경계값 서버 보관·검증" (v1.0 B-7 구조) — PD님 재결정으로 전면 폐기. 서버 개발자 작업 스펙 아님. (2) "상세 설계 전부 포함 장문 지시서" (v1.0 446줄) — 인간 개발자 파악 시간 낭비, 기각. (3) "v1.0 부분 수정" — B-7 전면 재설계 필요 규모, 요약판 원칙 병행 시 전면 재작성이 근본 해결. (4) "샘플 API 전량 제거" — `Save_StageResult` 샘플 1건은 `is_abuse_flag` 인터페이스 실체 예시로 유지 필요. (5) "PD-⑤ 리셋 시간 기준을 결정 대기에 유지" — 개발팀 재량 확정 사항으로 분리 표기.
-
-<!-- #PD지시 #PM #완료 #DOCX제작 #인간작업자전달 -->
-## [PM] 인간 작업자 전달용 DOCX 2종 제작 완료
-- **요지**: PD님 지시("인간 작업자 전달용 문서는 PPT/WORD 등 전달 용이한 파일로 제작") 이행. 서버 개발자 지시서 + 어뷰징 판정 기획서 각 DOCX 변환 완료
-- **이유**: 인간 서버 개발자 배정 시 즉시 온보딩 가능한 공식 전달 자료 확보. md 원본은 조직 내부 자산으로 유지
-- **변환 방식**: pandoc 부재로 `scripts/md_to_docx.js`(docx-js 기반) 신설. 한국어 폰트 Malgun Gothic, A4, 표·목차·헤딩 위계·기각안 섹션 보존. 재사용 가능
-- **산출물**:
-  - `공유/인간작업자_전달자료/2026-04-17_서버개발자_업무지시서_v1.0.docx` (27KB)
-  - `공유/인간작업자_전달자료/2026-04-17_어뷰징판정_솔루션_기획서_v1.0.docx` (21KB)
-  - `scripts/md_to_docx.js` (재사용 변환 도구)
-- **기각안**:
-  1. PPT 형식 — 서버 개발자는 API·스키마 등 상세 기술 문서가 필요하므로 DOCX가 적합. PPT는 개요·요약 용도
-  2. pandoc 설치 — 환경 의존성 추가 부담. docx-js가 npm 단일 의존으로 더 가벼움
-  3. md 원본 그대로 전달 — PD님이 "전달 용이 파일" 명시, md는 개발자 도구 없으면 가독성 낮음
-- **상태**: 완료
-
-<!-- #PD지시 #개발 #완료 #서버 #결정 -->
-## [세션 시점] 인간 서버 개발자 업무 지시서 최종본 작성 완료 (#30)
-- **요지**: PD 확정 3건(모든 보상=재화 통일 / 어뷰징 방지 솔루션 기획팀 주도 / DOCX 제작) 반영하여 #29 초안을 최종본으로 승격. B-7 어뷰징 방지 서버 연계 신규 섹션 + 1페이지 개요 + API 계약서 템플릿(Save_StageResult 샘플) + 용어집 + I 기각안 강화 포함.
-- **이유**: PD님 2026-04-17 일괄 결정 3건으로 초안의 PD-①·② 안건이 소멸. 비재화 보상 관련 설계·안건 전면 제거 후 서버 검증 경계값 수용 구조를 기획팀 솔루션 수령 대비 설계. 인간 개발자 온보딩 단독 사용 가능 완결 문서로 재구성.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_서버개발자_업무지시서_최종본.md` (v1.0). 기존 초안 `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md`로 이동.
-- **상태**: 완료 (md 최종본). DOCX 변환은 PM `anthropic-skills:docx` 수행 예정.
-- **기각안**: (1) "초안 그대로 DOCX 변환" — PD 확정 미반영으로 인간 개발자가 낡은 안건 기반 설계 착수 위험, 기각. (2) "비재화 보상 유지(PD-① A/B안 존속)" — PD 직접 결정으로 전제 소멸, 기각. (3) "어뷰징 방지 서버 단독 설계" — PD 직접 결정(기획팀 주도)으로 기각, 서버는 수용 구조만 담당.
-
-<!-- #PD지시 #개발 #완료 #시뮬레이션 -->
-## [12:21] Unity MCP 시뮬레이션 방향 전환 기술검토 완료
-- **요지**: PD #28에 대한 Unity MCP 기반 시뮬레이션 기술검토 수행. 07 Headless 추출안 대비 Unity MCP `execute_code` + EditMode 경로가 결정론·유지비·기획팀 접근성 3축 모두 우위로 판단, 방향 전환 권장.
-- **이유**: PD님 2026-04-17 Unity MCP 전환 지시(커밋 `db64310`)가 실질 문서 반영 누락 상태였음. 07 Actor.cs 4,545줄 리팩터링 리스크 회피 + 08/09/10 산출물 100% 재활용 가능.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`
-- **상태**: 완료 (검토·제안까지. 실제 구현은 PD님 방향 확정 후)
-- **기각안**: Play Mode 자동화(결정론 낮음·느림), dotnet CLI Headless(Actor.cs 대규모 리팩터링 필요) — EditMode `execute_code` 주력 + BatchMode 보조 채택
-
-<!-- #PD지시 #기획 #완료 #Phase3 -->
-## [세션 시점] Unity MCP 시뮬레이션 전환 — 기획 관점 검토 완료
-- **요지**: PD #28·기획 #3 HOLD 대응. Unity MCP 전환이 기획 관점에서 타당하나 "기획팀 직접 MCP 도구 호출"은 비권장, "개발팀 러너 구축 + 기획팀 입출력 JSON 경로" 권장.
-- **이유**: C11(개발 관점)·C7(재미 우선) 역할 경계 유지. 기획팀은 시뮬 기능 명세·입출력 스키마·반복 실행 요구만 정의. Phase 3 부분 재개(Day 1~3) 가능 범위도 개발팀 조기 산출물 3종 매핑으로 정리.
-- **산출물**: `공유/소통/기획팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`
-- **상태**: 완료 (검토 보고까지. 실제 Phase 3 재개는 PD님 재개 지시 후)
-- **기각안**: (a) 기획팀 MCP 도구 직접 호출 — 학습 부담 과대·역할 경계 교란 (b) Python 시뮬 아카이브·삭제 — C6 데이터 보호 위반 + Phase 3 v1 붕괴 원인 분석 근거 소실 리스크
-
-<!-- #PD지시 #개발 #진행중 #서버역할정리 -->
-## [세션 시점] 인간 서버 개발자 업무 지시서 초안 작성
-- **요지**: PD #29 인간 서버 개발자 업무 지시 초안 작성. 서버 관리 데이터 카테고리 8종·클라/서버 경계 매트릭스 6개 액션군·PD 결정 안건 5건 정리. 현 수상한잡화점 `ServerClass.cs`·`ServerInfo.cs` 실측 — PlayFab CloudScript + 로컬 하이브리드 구조 확인.
-- **이유**: PD 가이드 3종(재화 서버 필수·미션 보상 지급 주체 결정·랭킹 그대로 저장) 기본 적용. 인간 개발자 즉시 착수 가능 수준의 구체 필드·API 예시까지 포함. 메타 시스템 미파악분은 "추가 분석 필요"로 정직 명시.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_RPT_서버역할_정리_초안.md`
-- **상태**: 진행중 (초안 + PD 결정 안건 제시. PD 결정 수령 후 설계 문서화 단계로 이행)
-- **기각안**: (a) 서버 처리 최소화·전부 클라 주도 — PD 가이드 1 충돌 (b) 모든 비재화 자산 서버 SOT 전환 — PD 전제 초과·공수 과대 (c) PlayFab 전면 폐기 + 자체 서버 신규 — 서버 Critical 3건 보류 중 범위 확대 리스크 (d) 인간 개발자 배정 전 세부 API 스펙 확정 — 개발자 기술 선호 반영 없는 스펙은 재작업 리스크. **Agent 호출 기각**: `Task` 서브에이전트(서버팀장·클라이언트팀장) 호출이 본 세션 도구 환경 제약으로 불가, 개발팀장 단독 분석으로 대체하되 관점 명시 구분 (C23 정직성)
-
-<!-- #PD지시 #기획 #완료 #설계 #어뷰징 -->
-## [세션 시점] 어뷰징 판정 솔루션 기획서 v1 작성 완료
-- **요지**: PD #32 지시 대응. 시뮬레이터 이론 극값 × 안전마진계수 기반 경계값 도출 방법론 + 2계층(클라/서버) 검증 + F1/F2/F3 3단계 플래그 체계 + 경계값 테이블 JSON 스키마 + 서버 API 호출 흐름까지 설계 원칙·프레임워크 수준으로 정리. 실제 수치는 Unity MCP 시뮬 후 확정(v1은 틀만 제공).
-- **이유**: 보상 재화 통일 결정에 따라 스테이지 클리어·랭킹·미션에서 클라 입력 검증 체계 필수. 서버 재시뮬 방식은 G-1 기각(자원 낭비·싱글 플레이 구조 오버엔지니어링), 경계값 비교 방식 채택. 재미 우선(C7) — false positive로 정상 플레이어 피해 최소화 위해 벡터별 5~20% 안전마진 설계. P17 ★조건 교차 검증 포함.
-- **산출물**: `공유/소통/기획팀→PM/2026-04-17_어뷰징판정_솔루션_기획서_v1.md`
-- **상태**: 완료 (설계·프레임워크 수준. Unity MCP 시뮬 가동·경계값 테이블 v1.0.0 산출은 후속 PD 지시 대기)
-- **기각안**: (1) 서버 단독 재시뮬 검증 — CPU 비용·난수 동기화·싱글 플레이 오버엔지니어링 (2) ML 기반 이상치 탐지 — 초기 출시 학습 데이터 부재, 장기 보조 수단으로 여지 유지 (3) 클라 단독 판정 — 메모리 조작으로 무력화, 원천 제외 (4) 전체 플레이 로그 전송 — 네트워크·저장소 비용 과도, F3 확정 시 사후 감사용 부분 로그만 서버 재량 (5) 안전 마진 0% 엄격 검증 — false positive 폭발, C7 위반
-
-<!-- #PD지시 #개발 #완료 #서버참고자료 -->
-## [16:30] 서버 작업 참고 자료 v1.2 재작성 (외부 서버 작업자용 중립화)
-- **요지**: v1.1(조직 내부용 서버 개발자 지시서)을 기반으로 외부 작업자용 중립 참고 자료 v1.2 신규 작성. PlayFab 전제 제거(현 사용 중 상태로만 기술)·조직 내부 프로세스 내용 전면 제거·문서 성격 재정의(지시서 → 참고 자료).
-- **이유**: PD님 직접 지시 — 외부 서버 작업자에게 전달할 때 조직 내부 프로세스 용어(코어룰 참조·PD 지시 번호·결정 대기 안건)가 노출되면 부적절하며, 특정 스택(PlayFab) 강제 전제는 작업자 자율 판단 여지를 박탈. v1.1은 조직 내부용 상세본으로 보존하여 외부·내부 자료 분리.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_서버_작업_참고자료.md` (v1.2, 신규). v1.1 원본 유지.
-- **상태**: 완료
-- **기각안**: (1) v1.1 직접 수정 (덮어쓰기) — 조직 내부 상세본 소실 위험, 외부·내부 분리 원칙 위반. 신규 파일 분리 채택. (2) 서버 스택 선택을 v1.2에서 확정 제시 — 외부 작업자 자율 판단 박탈, '열린 결정 사항'으로 중립 유지 채택. (3) 결정 대기 2건(PD-③·PD-④)을 각주로 축약 유지 — 조직 내부 미결 안건의 외부 노출 부적절, 전면 삭제 채택. (4) 기각안 섹션을 외부 자료에도 포함 — P24는 내부 규칙, 외부 자료 성격과 불일치. 대화로그(본 엔트리)에만 기록 채택.
-
-<!-- #PD지시 #개발 #완료 #Tier1 -->
-## [세션 시점] Tier 1 잔여 9종 구현 완료 + 로그 경로 정규화 (PD 지시 #1·#5-A, PM 일괄 승인)
-- **요지**: 개발팀장이 `코어코드/BT.Framework/` Tier 1 잔여 Attribute 3종 + Util 6종 구현 + 각 모듈 단위 테스트 추가 + CHANGELOG 갱신. PD 지시 로그 #1·#5 산출물 경로 정규화(구 경로·커밋 해시·glob 제거)로 `verify_log_paths.sh` 감사 15건 전수 실존 확인 통과.
-- **이유**: PD님 2026-04-17 마무리 지시로 팀장 재량 진행 가능 작업 일괄 승인. 차단 요인 없음. OI-2 C+H1 승인 완료·Phase 3 재개 대기 등과 무관한 순수 구현 영역.
-- **산출물**: `코어코드/BT.Framework/Runtime/Core/Attribute/` (ReadOnlyAttribute/ShowIfAttribute/ArrayTitleAttribute 3종) + `코어코드/BT.Framework/Runtime/Core/Util/` (EnumToInt/EnumEx/FormatEx/MathEx/KeyMaker/ValidationEx 6종) + `코어코드/BT.Framework/Tests/Runtime/Core/` (Attribute/Util 테스트 9종) + `CHANGELOG.md` 갱신 + `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` #1·#5 경로 정규화.
-- **상태**: 완료
-- **기각안**: (1) 전체 Tier 1 16종 중 미구현 12종 일괄 구현 — Data/Event/Container 영역은 MonoSingleton·ServiceLocator와의 상호작용 설계 재검증 필요. 단일 응답에서 품질 보장 가능한 Attribute 3종 + Util 6종 = 9종 범위로 한정 채택. (2) 박싱 회피를 `Convert.ChangeType` 캐시로 우회 — 여전히 힙 할당 발생. `System.Runtime.CompilerServices.Unsafe.As<,>` 기반 근본 해결 채택(EnumToInt). (3) `KeyMaker` 구분자로 `'_'` 유지 — 수상한잡화점에서 `_`와 `:` 혼재로 조회 실패 경험. 프레임워크 표준 `:` 고정 채택. (4) 각 Util에 UnityEngine 참조 허용 — 서버/배치 컨텍스트 재사용 불가. 순수 BCL 의존만 채택(C11 범용성).
-
-<!-- #PD지시 #개발 #완료 #UI #메타 -->
-## [세션 시점] Phase 0-B 최종 완결 — UI 아키텍처(11) + 메타시스템(12) 문서 신설
-- **요지**: 수상한잡화점 파악 잔여 40% 중 UI·메타 영역을 `11_UI아키텍처_v1.md` + `12_메타시스템_v1.md`로 문서화. Assets 전수 `ls` + 키워드 `find` 실측 기반. 프레임워크 흡수 계획(Tier 1 UI 컴포넌트 + Tier 2 Save/Economy) 구체화.
-- **이유**: PD님 2026-04-17 마무리 지시. 08(전투)·09(카드)·10(데이터) 완결 후 Phase 0-B를 UI·메타까지 확장. 헌법 제1원칙 목표 2(인사이트 기록 → 차기 프로젝트 참고)에 직접 기여 — 현 프로젝트 약점(*.Info 3역할·세이브 버전 관리 부재·재화 하드코딩) 차기 개선 안건 §10 기록.
-- **산출물**: `프로젝트/수상한잡화점/개발/11_UI아키텍처_v1.md` · `프로젝트/수상한잡화점/개발/12_메타시스템_v1.md`.
-- **상태**: 완료
-- **기각안**: (1) UGUI 19+19 스크립트 public API 메서드 전수 목록화 — 토큰 비용 과다, 구조·영향도 분류 목적에 불필요. 클러스터/LOC/범용성 3축 요약 채택. (2) UIToolkit 병행 매핑 문서화 — 기획 방향 UGUI 단일, 차기 프로젝트 R&D로 이관. (3) 메타시스템 보안 취약점 감사 — `05_서버연동_현황_v1.md` Critical 3건(#2 보류)과 중복. 본 문서는 구조·흡수 계획에 집중. (4) *.Info 클래스 필드별 세이브 대상 분류표 — 토큰 비용 + 프레임워크 흡수 대비 정보량 과다. 차기 Phase에 감사로 분리.
-
-<!-- #PD지시 #개발 #완료 #QP #시뮬레이터 -->
-## [세션 시점] Phase 0-C Q-P1/Q-P2 응답서 + 시뮬레이터 전략 v2 (PD 지시 #5-B·#28)
-- **요지**: 기획팀 Q-P1(4마리 노드 초반 위험도 의도성) + Q-P2(터치 방어 메커닉 3항)에 대한 개발 관점 응답서 발행. PD님 #28 Unity MCP 전환 반영하여 시뮬레이터 전략 v2로 재설정.
-- **이유**: #5-B Phase 0-C 잔여 작업. 단, Q-P1은 기획 의도 영역이므로 **단독 답변 불가** 명시(C11 구분) + Q-P2는 초벌 스캔(`PCActor.cs` L37 실측)으로 50% 수치·쿨다운 정밀 수치는 2차 응답서로 분리. 시뮬레이터는 Python 폐기·Unity MCP 단일축 재확정 + 인프라 4종 설계 포인트 제시.
-- **산출물**: `공유/소통/개발팀→PM/2026-04-17_Phase0-C_QP_응답서_개발팀.md`.
-- **상태**: 완료 (Q-P2 2차 정밀 응답은 후속)
-- **기각안**: (1) Q-P1에 "의도된 설계로 추정" 단정 응답 — 개발팀 의사결정 권한 외, C23 위반. 의도 선언은 기획팀으로 환송. (2) Q-P2 3항 전수 리버스 엔지니어링을 본 응답서에 포함 — 작업량 막대 + 범위 초과. 2차 응답서로 분리. (3) Python 시뮬레이터 복구 시도 — PD님 #28 "폐기 사안" 정면 위반. (4) Unity 외 3rd-party 시뮬레이터 검토 — PD님 Unity MCP 단일 방향 확정, 검토 대상 아님.
-
-<!-- #PD지시 #개발 #완료 #결정 #시뮬레이터 -->
-## [작업완료] #37 Q-P2 정밀 2차 응답 + Unity MCP 시뮬 인프라 4종 (독립 시뮬 제약 반영)
-- **요지**: Q-P2 3서브 질의 실측 확정(30% 감소·지속형·쿨다운 없음) + 시뮬 인프라 4종 설계문서 + 독립 어셈블리 `BurningTimes.Sim` 스켈레톤 구현
-- **이유**: PD님 #37 즉시 수행 지시 + 독립 시뮬 요건 명시(기존 코드 불변, Editor-only 어셈블리, 메커닉 독립 재구현). Q-P2 1차 응답의 미확정 수치 해소가 기획팀 밸런싱 재개 선결 조건
-- **산출물**:
-  - `공유/소통/개발팀→PM/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md`
-  - `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md`
-  - `프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md`
-  - `프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md`
-  - `프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md`
-  - `(Unity) Assets/Sim/BurningTimes.Sim.asmdef` (Editor-only)
-  - `(Unity) Assets/Sim/Runtime/SimulationRunner.cs`·`ScenarioLoader.cs`·`ResultEmitter.cs`
-  - `(Unity) Assets/Sim/Runtime/Models/ActorModel.cs`·`DefenceModel.cs`·`DamageCalc.cs`
-- **상태**: 완료 (Unity MCP 실행 검증은 Editor 기동·MCP 연결 환경에서 후속 수행 — C23 정직)
-- **실측 주요 결과**: PCDefence_Mul=0.3 (기획 가정 50% 불일치), 쿨다운 전무, 터치 Down→Up 지속형, 방어 중 공격 불가, Melee/Range 공통 적용, Mob 방어 메커닉 부재
-- **독립성 증명**: `git diff --stat Assets/Script/` = 0건. 신규 생성물 `Assets/Sim/` 단독. asmdef `references: []`·`includePlatforms: ["Editor"]`·`defineConstraints: ["UNITY_EDITOR"]`로 3중 격리
-- **기각안**:
-  - (1) 기존 `Actor.cs` 경로 재사용 실행 — PD 제약(독립 시뮬) 정면 위반
-  - (2) Q-P2에 "50% 추정" 유지 — 실측 결과 30% 확정, C23 위반 회피
-  - (3) 쿨다운 "있을 것" 추정 — `UITouchHandler.cs` 전수 확인 결과 미존재
-  - (4) Mob 방어 메커닉 가정 — `MobActor.cs` 전수 확인 결과 override 부재
-  - (5) Scenarios ScriptableObject 입력 — MCP 외부 접근 곤란, JSON 채택
-  - (6) PlayMode 기반 시뮬 — 독립성·성능 악화, EditMode + 독립 Runner 채택
-  - (7) 별도 레포 서브모듈 — MCP 경로 제약·기획팀 셋업 복잡, 동일 레포 격리 채택
-  - (8) Headless 배치 빌드 — 피드백 루프 느림, MCP `execute_code` 즉시 실행 채택
-
diff --git a/공유/대화로그/수상한잡화점/2026-04-18.md b/공유/대화로그/수상한잡화점/2026-04-18.md
deleted file mode 100644
index dfa1a64..0000000
--- a/공유/대화로그/수상한잡화점/2026-04-18.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# 2026-04-18 수상한잡화점 대화로그
-
-<!-- #PD지시 #기획 #완료 #Phase3재개시뮬 #원칙1재개정 -->
-## [기획팀장 실무 점검] 새 PC 기획 세션 재개 시뮬레이션
-
-- **요지**: 새 PC 기획팀장 세션 시작 → Phase 3 재개 지시 즉시 착수 가능성 실무 시뮬. 5문서(M1 Phase3체크·M2 3성조건·m1 맵패턴·m2 Phase2·m3 빌드충돌) 전수 Read + N7 실측 반영 + 새 원칙 1(본문 최신 + 말미 참조 링크) 적용 검증.
-- **이유**: 2026-04-18 PD님 직접 지시 "전 에이전트 동원 다른 PC 동기화 점검". bc9c8ed·15bf649·원칙 1 재재개정(상단 배너 폐지 → 말미 참조) + N7 #37 실측 완료(PCDefence_Mul=0.3·쿨다운 없음·지속형) + 방향전환 아카이브 5섹션 완비 효과 실무 검증.
-- **판정 핵심 6종**:
-  1. **Day 1~15 로드맵** — 참조 경로 전수 실존(Day 1~15+ 로드맵상 연동 §·문서명 모두 Read 확인). 개발팀 Unity MCP 시뮬 가이드는 `공유/소통/개발팀→기획팀/` 폴더가 아직 Unity MCP 실측 리포트·가이드 미수령 상태 → Day 1 재개 즉시 착수 불가(차단 요인)
-  2. **5문서 참조 무결성** — 경로·섹션 번호 상호 참조 모두 실존. **다만 말미 링크 앵커 결함 발견**: 5문서 말미의 `#1-...v1md-방향-전환` ~ `#5-...` 앵커가 방향전환 아카이브 실제 구조(2026-04-18·2026-04-17·2026-04-16 소급 3섹션)와 불일치. 클릭해도 해당 섹션으로 이동 불가
-  3. **P17 배타 조합** — 7종 전수 실무 적용 준비 완료. 42개 슬롯 전수 체크틀(맵패턴 §3-3) 준비 상태. N7 조건 풀 13번째 추가 여부는 Phase 3 재개 시 PD님 결정 대기(인지 가능)
-  4. **N7 실측 반영** — Phase2 L206·맵패턴 §3-4 L227·Phase3체크 §3-3 L172·§6-3 L232 전수 반영 확인. 새 PC 세션이 L206 1곳 Read만 해도 PCDefence_Mul=0.3·쿨다운 없음·지속형·Melee/Range 공통·Mob 방어 부재 전체 파악 가능
-  5. **새 원칙 1 적용** — 5문서 전수 상단 배너 부재 + 말미 §10 참조 섹션 내 1줄 링크 체계 일관. 본문 읽기 방해 요소 제거 완료
-  6. **세션 맥락 복원** — SessionStart hook + SKILL.md + 5문서 Read로 재개 준비도 파악 가능. "Python 시뮬 폐기" 맥락은 방향전환 아카이브 2026-04-17 소급 섹션에서 복원 가능
-- **산출물**: 본 엔트리(수상한잡화점 2026-04-18 대화로그 신설 — P24 위반 감지분 소급 작성) + 기획팀장 → PM 실무 판정 응답
-- **기각안**:
-  1. "말미 앵커 클릭 작동 불가 — PM에 즉시 수정 이관" — 기각 사유: 본 점검의 범위는 **보고**이며 수정은 PM 경유. 앵커 결함은 개별 앵커 신설(5개) vs 문서별 링크를 시기별 섹션으로 수정 2안 모두 구조적 대안이며 PM 재량 판정 필요 (기각안 자체도 "어떤 안을 기각하는지" 명시 필요해 본 판정 분리)
-  2. "Phase 3 본 작업 로드맵 즉시 착수 보고" — 기각 사유: Day 1 재개 트리거 #3 "Unity MCP 시뮬 실행 가이드" 미수령 상태로 현 시점 즉시 착수 불가. HOLD 준수상 허위 착수 보고는 C23 위반
-  3. "N7 조건 풀 13번째 추가 여부 기획팀장 재량 결정" — 기각 사유: P23 PD님 확인 필요 영역(핵심 밸런싱 방향 전환·유저 경험 직접 영향). Phase 3 재개 시 PD님 결정 대기가 정합
-- **상태**: 완료
-
-<!-- #자율작업 #기획 #완료 #plan_auditor_모드C #새PC동기화최종점검 -->
-## [~후속] plan-auditor 모드 C — 새 PC 동기화 최종 점검 (기획 영역)
-
-- **요지**: 기획팀장 실무 점검 엔트리와 **독립적 교차 감사** 수행. 5문서 구용어 0건·말미 링크 5건 실존·Unity MCP 46회 참조·P17 서브번호 9회 정합·N7 실측 반영 전수 확인. 기획팀장 실무 점검이 발견한 **앵커 결함(Major)**을 본 감사관도 재확인하여 통합. 
-- **이유**: P27-1 3축 감사 체계 상호 검증 규범. plan-auditor가 기획팀장 보고를 rubber stamp 하지 않고 독립 실측으로 재검증
-- **판정 5종**:
-  1. **Critical 0건** — Phase 3 재개 블로킹 요인 없음
-  2. **Major 1 (N7 상태 불일치)** — Phase2 L206 "실측 완료" vs 3성조건 L14·L69·L698 "보류" 문구 잔존. Phase 3 재개 시점 PD님 결정으로 자연 해소 가능하나 구조적 혼선 리스크
-  3. **Major 2 (앵커 결함 — 기획팀장 발견 재확인)** — 5문서 말미 링크 `#1-프로젝트수상한잡화점...` 형식이 실제 아카이브 섹션 `#### 1. Phase3_...` 구조와 slugify 규칙 상 불일치 가능. Markdown viewer별로 동작 차이 — GitHub 렌더러 기준 재검증 필요
-  4. **Improvement 1 (범위 외 2문서 구용어 35건)** — 밸런싱문서_일관성점검·재논의대기_사전자료모음 잔존. Phase 3 재개 시 참조 문서이므로 별도 최신화 안건 상정 권고
-  5. **방향전환 아카이브 5섹션 완결성 100%** — 6필드 형식 준수, 2026-04-17·04-16 원류 소급 완비, 차기 프로젝트 독립 참고 가능
-- **산출물**:
-  1. `공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md` (감사 보고서)
-  2. `공유/대화로그/수상한잡화점/2026-04-18.md` 본 엔트리 append
-  3. `공유/대화로그/조직운영/2026-04-18.md` append (자기 기록)
-  - feedback 메모리: 신규 패턴 미발견으로 생략 (기각안 참조)
-- **기각안**:
-  1. 기획팀장 실무 점검 결과 rubber stamp (독립 감사 생략) — P27-1 상호 교차 검증 정신 위배, 기각
-  2. 앵커 결함을 Major 아닌 Improvement로 분류 — 기획팀장이 "클릭 작동 불가" 실측 보고했으므로 차기 프로젝트 참고 자료 접근성 직접 영향 → Major 유지
-  3. N7 상태 불일치를 Critical로 격상 — Phase 3 재개 블로킹 아니고 PD님 결정으로 해소 가능, Major 유지
-  4. feedback 메모리 신규 작성 — 본 감사는 문서 점검이고 실수 패턴·재발 방지 신규 학습 없음, 기각 (dev-auditor 2026-04-17 산출물 3종 규범과 정합)
-- **상태**: 완료 (PM 수령 후 Major 1·2 처리 재량 판단 대기)
-
-<!-- #자율작업 #PM #완료 #로그누락반성 #개발영역소급 -->
-## [PM 소급 작성] 본 세션 수상한잡화점 개발 영역 작업 영구 기록 (P24 위반 자인·반성)
-
-- **요지**: 본 세션 당일 커밋 0a8caa0·1ceec2b·bc9c8ed·15bf649·e039322가 수상한잡화점 개발 영역에 **직접 영향**을 미쳤으나 PM이 대화로그 엔트리 작성을 누락·위임. PD님 직접 지적으로 소급 작성
-- **이유**: PM이 세션 초기에 "PM 재량으로 작성 예정"으로 결정하고 plan-auditor·기획팀장 Agent에게 지시 포함으로 위임. PM 본인 직접 작성하지 않음. 이는 **4회차 과도 보수 해석 변종**(기록 범위 자의적 축소)
-- **소급 집행 개발 영역 작업** (커밋별):
-  - **0a8caa0** — B1 07 Headless 상단 아카이브 배너 추가 + 02_개발자관점_점검 L19 주해 추가. B3 08 전투시스템 SOT §4.1·§4.3 "(확인 필요)" 실측 확정 반영 + §4.4 실측 수치 표 append (PCDefence_Mul=0.3·쿨다운 없음·Melee/Range 공통·Mob 방어 부재·#37 Q-P2 근거). §8 체크리스트 2건 완료 처리
-  - **1ceec2b** — OPT-2 07 §3·4·5·7 약 120줄 삭제 (228 → 129 라인 54% 축약). §1 리스크·§2 Option A/B 비교표·§6 검증 방법·§8 OI·§10 참고 유지 (차기 참고 가치 보존). OPT-3 REQ 6건 `공유/소통/기획팀→개발팀/` + `공유/소통/개발팀→기획팀/` → `공유/소통/완료/` git mv (개발팀장 실측 "2026-04-16 응답 완료" 프론트매터 근거)
-  - **bc9c8ed** — 원칙 1 재개정으로 기획 5문서 최신화 기준 확립, 개발 영역은 07·02·08 기존 집행분 유지
-  - **15bf649** — 원칙 1 재재개정(배너 폐지), 개발 영역 문서 미수정 (파일 성격 배너 예외: 07 🔴·02 🟢)
-  - **e039322** — 08 전투시스템 SOT §4.4 기획 초기 가정(50%) 병기 유지 결정 (dev-auditor·개발팀장 공통 "SOT 훼손 ≠ 추적성 자산" 판정)
-- **기각안**:
-  1. "plan-auditor·기획팀장 위임으로 기록 완료" 간주 — 위임 수신 에이전트가 기획 영역 중심으로 작성, 개발 영역 누락 실증, 기각
-  2. 코어프레임워크 대화로그 불요 판정 유지 — 02 추출대상 배너·원칙 1 최종형이 코어프레임워크 직접 영향으로 확인, 별도 신설 집행
-  3. 소급 없이 "학습으로만 처리" — C13·C29-4 헌법급 의무 무력화, 기각
-- **소급 정직성 준수 (C5·C23)**: 본 엔트리는 사실 복기이며 실제 작성 주체는 PM. 기획팀장·plan-auditor 기 작성 엔트리(상단)와 중복되지 않도록 개발 영역 작업에 한정 기록
-- **상태**: 완료 (소급 집행)
diff --git a/공유/대화로그/수상한잡화점/2026-04-20.md b/공유/대화로그/수상한잡화점/2026-04-20.md
deleted file mode 100644
index e11d5c9..0000000
--- a/공유/대화로그/수상한잡화점/2026-04-20.md
+++ /dev/null
@@ -1,947 +0,0 @@
-# 2026-04-20 수상한잡화점 대화로그
-
-<!-- #PD지시 #42 #43 #44 #기획팀장 #진행중 #재발방지 #데이터실측 #지역1_v2 -->
-## [기획팀장 보고] PD 재발 방지 지시 5종 수용 집행 (#42·#43·#44 진행중 · #45 대기)
-
-- **요지**: PD님 직접 지시 (2026-04-20 · PM 세션 경유) 5종 수용 집행. 기존 기획팀이 "WorldMap 4그룹" 오해로 Phase4 지역 1 v1을 "Stage 1~6 = 지역 1 = 6개"로 설계한 사건을 **데이터 구조 재정비 + 기획팀 룰 신설 + 지역 1 v2 재작성** 3종 동시 집행으로 차단.
-- **이유**: PD 확정 용어 "월드맵=21구역 · 지역 1=Stage1_1~1_4=4개"와 기획팀 SOT(스테이지난이도곡선_v1 §1 "WorldMap 4그룹") 충돌. v1 상태 유지 시 전체 Phase 4 후속 산출물이 PD 의도 벗어남. C22(용어 일관)·C23(허위 보고 금지)·C10-5(선행 검증) 위반 구조.
-- **판정 핵심 5종**:
-  1. **실측 확정**: Unity Export CreateMapConfig.csv 전수 실측. 21개 지역 × 각 N개 하위 스테이지 = 총 122 스테이지. PD 실측 표와 완전 일치.
-  2. **#41 보류 전환**: Phase 4 지역 1 v1 폐기 → #42·#43·#44 완료 후 재개
-  3. **#42 데이터 구조 재정비 v1 신설**: Unity Export 실측 기반 테이블 구조 SOT (WorldMapConfig·CreateMapConfig·ApprearMonsterPattern·MonsterList·StatusConditionsList·RandomPatternConfig 등)
-  4. **#43 기획팀 데이터 실측 의무 v1 신설**: 5대 의무 (실측·용어 준수·PD 확인·SOT 맹신 금지·재사용 검증) + 처분 체계
-  5. **#44 지역 1 v2 초안 작성**: Stage1_1~1_4 = 4개 기준. 고정+랜덤 이원 + 3★ 조건 8슬롯 + P17 전수 체크 + ToolData.json 초안 (§5)
-- **결정**: 3종 산출물 동시 신설 · v1 상단 "아카이브됨" 배너 추가 · PD 지시 로그 #41 보류 + #42·#43·#44 신규 등록 + #45 ToolData.json 대기
-- **근거**:
-  - 실측: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/CreateMapConfig.csv` (122 레코드 · Stage1_1~21_4 형식)
-  - 실측: `WorldMapConfig.csv` 21 레코드 (n_StageID 1~21)
-  - 실측: `MonsterList.csv` 보스 10001·10002 (놀아처1·놀강도2) 스탯 확인
-  - 실측: `ApprearMonsterPattern.csv` 그룹 10101~10104 (지역 1 몬스터 풀)
-  - 기존 오염: `스테이지난이도곡선_v1.md §1` "WorldMap_1~4 4개 그룹" 표현 → §2~이후 실측 수치는 정확 · §1만 정정 대상
-  - 승계 원칙: 12종 조건 풀·P17 배타·고정+랜덤·재미 포지션 분리 (데이터 구조 무관 원칙)
-- **영향**:
-  - 기획팀: 데이터 실측 의무화 · 향후 모든 기획 작업 §1-1 실측 선행 필수
-  - 개발팀: #45 (ToolData.json) PD 승인 수령 후 기획팀 → 개발팀 핸드오프 예정
-  - PM: PD 지시 로그 5건 정정 완료 (#41 보류 + #42·#43·#44·#45 신규)
-  - PD님: #42·#43·#44 검증 후 #45 ToolData.json 생성 승인 대기
-  - 후속 재정비 필요 문서 (별도 지시 수령 시): 스테이지난이도곡선_v1 §1 · Phase4_노드구성_착수가이드_v1 · 맵패턴_사전분석_v1 · 재검증보고_맵패턴_v1 · Phase3_종결_설계체계_v1
-- **기각안**:
-
-  | # | 기각 대안 | 기각 사유 |
-  |---|---------|---------|
-  | 1 | v1 Stage 2~6 설계 재활용 (v2에 편입) | Stage 2~6은 지역 2~4 소속 → v2 "지역 1"에 편입 불가. 별도 지역별 v2 집행 시 재검토 대상 |
-  | 2 | "WorldMap 4그룹" 병행 사용 (기획 레이블 + 데이터 구조 양쪽) | C22 용어 일관 위반 · 신규 기획자 재혼동 유발. 입문/초반/중반/후반은 **기획 레이블만 별도 명시** 허용 |
-  | 3 | ToolData.json을 기획팀이 직접 최종 생성 | Unity 연동 스키마는 개발팀 영역. 기획팀은 초안 제공 + 개발팀 변환 핸드오프 구조 (C11 개발 관점 존중) |
-  | 4 | 오염 산출물 전수 동시 재정비 (본 라운드) | 토큰·품질 관점 집중도 저하. v1 폐기·v2 작성이 우선순위. 후속 문서 정정은 별도 PD 지시 수령 시 순차 집행 |
-- **산출물 경로**:
-  - `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` (신규 · #42)
-  - `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` (신규 · #43)
-  - `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` (신규 · #44 · ToolData.json 초안 포함)
-  - `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` (🔴 아카이브 배너 추가)
-  - `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` (#41 보류 전환 + #42·#43·#44·#45 신규 등록)
-- **다음 단계**: PD 검증 → #42·#43·#44 승인 → #45 ToolData.json 개발팀 핸드오프 (기획팀 Task 범위 외)
-- **고주의**: #45 ToolData.json 생성 시 Stage1_4 놀강도2 단독 전투 Unity MCP 시뮬 선행 1회 권고 (광포화 상태 DPS 변동 실측 필요)
-
----
-
-<!-- #PD지시 #40 #기획팀장 #진행중 #Phase3 #병렬진행 #선행업무요약 -->
-## [기획팀장 보고] PD 지시 #40 — Phase 3 병렬 진행 전 선행 업무 요약
-
-- **요지**: PD님 직접 지시 (2026-04-20 · PM 세션 경유) "기획팀 남은 업무 병렬로 진행할 예정이야. 작업 진행 전 수행할 업무를 요약해서 우선 보고하도록 지시해." PM이 Task Agent로 기획팀장 호출. 병렬 착수 전 선행 업무를 유형별로 식별·정리하여 보고.
-- **이유**: Phase 3 Day 2~3·Day 4~7 완료 + Day 8~10 대기 상태에서 PD님이 "남은 업무 병렬 진행" 방향 제시. PD 결정 대기 2종(Day 11~14 순서·v2 반영 시점)이 병렬 범위에 직접 영향 — 식별 없이 병렬 착수 시 재작업 리스크 존재. 기획팀장이 5개 트랙 분류하여 PD 결정 전·후 착수 분기 명확화.
-- **판정 핵심 5종 (5개 트랙 식별)**:
-  1. **트랙 E (기타 사전 준비)** — PD 결정 무관 즉시 착수. 트랙 A·B·D 가속 초석 역할
-  2. **트랙 C (3성 조건 REQ 발행)** — 독립 트랙. 개발팀 선행 조건 2·3(실측 검증 리포트·시뮬 실행 가이드) 모두 확보 → 기획팀장↔개발팀장 조율만 남음. 즉시 착수 가능
-  3. **트랙 A (Day 8~10 이슈 1·3 재논의)** — 기획팀 단독 초안 작성 가능. PD 판단 요청 Day 8-4는 PD 결정 #1 이후 정렬. 초안 수준 즉시 착수 권고
-  4. **트랙 B (Day 11~14 맵 패턴)** — PD 결정 #1 분기. 2-A 병행 채택 시 즉시 착수, 2-B 순차 채택 시 E-2 사전 준비만 병행
-  5. **트랙 D (Phase 3 v2 드래프트)** — PD 결정 #2 분기. "Day 4~7 분 선행 반영" 채택 시 즉시 착수 가능, "Day 8~10 후 일괄" 채택 시 대기
-- **결정**: 5개 트랙 식별 · 즉시 착수 가능 4건 + 트랙 A 초안 수준 · PD 결정 대기 2건 (기존 에스컬레이션 유지)
-- **근거**:
-  - 실측 확인: Day 2~3·Day 4~7 산출물 7종 전수 Read 확인 (Phase3_재개준비_체크리스트_v1·재검증보고_Phase0_1_2_v1·Phase3_성장요소기여도_v2·REQ초안_3성조건_12개_판정로직·방어_쉴드_시뮬_현황_메모·Unity_MCP_실측검증_리포트_v2·Unity_MCP_시뮬실행_가이드_v1)
-  - PD 결정 대기 2종: Phase3_성장요소기여도_v2.md §7-2 PM 에스컬레이션 명시
-  - 개발팀 선행 조건 2·3 충족 확인: 리포트 v2(UTF 14/14 Passed)·시뮬 실행 가이드 v1 모두 `공유/소통/개발팀→기획팀/` 실존
-- **영향**:
-  - 기획팀: 트랙 E·C·A 초안 즉시 병렬 착수 가능 (기획팀장 재량 · P23)
-  - 개발팀: 트랙 C REQ 정식 발행 조율 필요 (기획팀장↔개발팀장)
-  - PM: PD님 결정 대기 2종 상신 유지 (안건 재질문 금지 · P28-8)
-  - PD님: 2종 결정 대기 (Day 11~14 순서 · v2 반영 시점)
-- **기각안**:
-
-  | # | 기각 대안 | 기각 사유 |
-  |---|---------|---------|
-  | 1 | 전 트랙 즉시 병렬 착수 (PD 결정 무시) | PD 결정 2종이 트랙 B·D에 직접 영향 — 결정 전 착수 시 재작업 리스크. C36 방향·원칙 수준 축소·희석 금지 저촉 가능 |
-  | 2 | 트랙 C(REQ 발행)를 Day 8~10 이후로 미루기 | 3성 조건 판정 로직은 Day 8~10·Day 11~14와 독립 — 지연 사유 없음. C29 업무 자율 수행 체계 역행 |
-  | 3 | 트랙 E를 생략하고 트랙 A·B·C·D만 병렬 진행 | E는 "초석" 역할 — 생략 시 본작업 품질 저하. C9 완성도 우선 원칙 준수 |
-  | 4 | 트랙 D를 트랙 A 완료 후로 무조건 묶기 | PD 결정 #2에 "Day 4~7 분 선행 반영" 옵션 존재 — 기획팀장이 선제 결정은 PD 영역 침범 (C36) |
-
-- **산출물**: `공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md`
-- **후속**: PM 수령 → PD님께 통합 보고 → PD 결정 2종 수령 시 트랙 B·D 착수 분기 확정 · PD 지시 #40 완료 아카이브 이동 (C27·C29-4)
-- **PD 지시 로그**: #40 `진행중` (기획팀장 Task Agent 보고 수행 · 산출물 경로 기록 완료) — PM 수령 후 `완료` 전환 예정
-
----
-
-*작성자: 기획팀장 (Task Agent 호출 응답 내 작성)*
-*관련 PD 지시: 기획팀 #40 (본건) · 기획팀 #3 (Phase 3 본작업 진행중 Day 8~10 대기)*
-
----
-
-<!-- #PD지시 #개발팀 #진행중 #57 #Unity몬스터미등장 #근본원인확정 -->
-## [PM 수령] 개발팀장 #57 Unity 몬스터 미등장 원인 조사 완료
-
-### 요지
-
-PD 지시 #57 (2026-04-20) — Unity 테스트 플레이 "랜덤 패턴"에서 "몬스터 등장" 결정 시 실제 게임에서 몬스터 미등장 원인 조사. 개발팀장 Task Agent 호출 결과 **근본 원인 특정 완료** + 근본 해결안 3종 도출.
-
-### Unity 프로젝트 경로 (본 레포 외부)
-
-`D:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\...` — 조직 레포(`D:\BurningTimes\BurningTimesAi`)와 별개 Unity 프로젝트. Agent 경계 보호 (C34-11) — 본 레포 파일 수정 없음, 인용 전달만.
-
-### 근본 원인 (개발팀장 실측 기반)
-
-**`Assets/Resources/ToolData.json` 125/125 스테이지 `list_MobData` 빈 배열 100%**.
-
-단절 플로우:
-1. `InGameInfo.Set_StageData()` 시 ToolData.json 로드 → `list_MobData == []`
-2. 랜덤 노드 진입 시 `WeightedPickIndex` → Mob 추첨 정상
-3. `MyValue.cs:380-388` 몬스터 ID 풀 구성 루프 → 빈 리스트라 1회도 실행 안 됨
-4. `mobnodedata.list_MobID == []` 확정
-5. `MonsterNodeControler.Get_MobID` → fallback `Get_MobID_onStage(Melee, [])` 호출
-6. `MyValue.cs:469~512` `Get_MobID_onStage` → candidates 0 · list_MobID 0 → **`return 0`**
-7. `table_monsterlist.Get_Data_orNull(0) == null` → `MobActor.Set(null)` → `Off()` → **9슬롯 전원 비활성화**
-
-**단절 지점 5개**:
-| # | 파일:라인 | 조건 | 결과 |
-|---|----------|------|------|
-| 1 | MyValue.cs:380-388 | list_MobData.Count == 0 | list_MobID = [] 확정 |
-| 2 | MonsterNodeControler.cs:195 | list_MobID.Count == 0 | fallback 호출 |
-| 3 | MyValue.cs:488-492 | candidates + list_MobID 모두 0 | **return 0** |
-| 4 | MobActor.cs:38-70 | actordata == null | **Off()** |
-| 5 | MonsterNodeControler.cs:121-140 | forcedMob.MobID == 0 동일 경로 | fallback 무효 |
-
-### 과거 proxy 수정 이력 (C2-2 실증)
-
-- `9e5fd5b59` (2026-04-08): "랜덤 패턴 몬스터 미등장" 같은 증상 1차 proxy 수정
-- `521a76641` (2026-04-09): "가끔 몬스터 안 나오는 경우 수정" 2차 proxy
-
-두 수정 모두 **근본 원인(`list_MobData` 공백) 해결 없이** `case 1` 분기 가드 추가 + fallback 추가로 **증상 은폐만** 수행. C2-2 proxy 개선 패턴 교과서적 사례.
-
-### 근본 해결안 3종 (C2-3 구조 개선 우선)
-
-1. **A. `IngameStageData.Init()` 자동 채움** (개발팀 재량 즉시 집행 가능)
-  - `list_MobData`/`list_BossMobData` 비어있으면 `MapConfig.n_AppearMonsterGroup` 기반 `table_ApprearMonsterPattern.Get_DataList`에서 자동 복구
-  - 코드 위치: `Assets/Script/InGame/Stage/IngameStageData.cs` `Init()`
-  - C20-1 팀장 재량 · C11 코드 직관성·범용성 · 다른 팀 영향 없음 · 롤백 용이
-  - 예상 효과: 유저 경험 즉시 복구 (ToolData.json 손대지 않고 런타임 복구)
-
-2. **B. ToolData.json 재export** (기획팀 협업 필수)
-  - Tool_Left `CreateStageAppearMonster` 배치 실행으로 125/125 스테이지 재생성
-  - P14 QA 게이트 필요
-  - 데이터 SOT 정합성 회복 정답이나 A 선행 후 후속
-
-3. **C. 기획 툴 이상 원인 조사** (후속 분리)
-  - 왜 `list_MobData`가 ToolData.json 생성 시점에 누락됐는지 원인 추적
-  - Tool_Left 호출 경로·Newtonsoft.Json 직렬화·JSON 스키마 마이그레이션 3축 조사
-
-### Proxy 대안 (긴급 시 임시 · C2-2 명시 분리)
-
-- `MonsterNodeControler.cs:121-140` fallback에 MapConfig 기반 기본 MobID 직접 설정 — 설계 이중화 우려
-- `MyValue.cs:380-388` `else` 분기 추가 — `case 1` 분기에만 한정 커버
-
-→ 근본안 A에 이미 포함되므로 별도 채택 불요.
-
-### 재현 조건 (PD님 테스트용)
-
-- Chapter 1~6 전체 스테이지 (125/125 영향)
-- Random 노드당 ~32% 확률 발생
-- Stage 1_1 기준 Random 9개 중 평균 ~2.9개 미등장
-- Unity Console Popup 없음 확인 시 MobID=0 경로 확정
-
-### PM 권고
-
-**A 먼저 적용하여 유저 경험 즉시 복구 → B·C 후속 순차**. 단 Unity 프로젝트 직접 영향 변경이므로 **PD 방향 확인 후 개발팀 착수**가 안전 (C20-2 다른 프로젝트 영향 해당).
-
-### 추가 조사 필요 사항 (후속)
-
-1. Unity Editor 런타임 재현 (PD님 테스트 시 Console Popup 캡처)
-2. Tool_Left 호출 경로 이력 (기획팀 협업)
-3. JSON 직렬화 격리 테스트 (Newtonsoft.Json 설정 배제)
-
-### PD 지시 로그 #57 상태
-
-- 현 상태: `진행중` (개발팀장 조사 완료 · PM 수령 완료)
-- PD 방향 수령 + A 집행 완료 후 `완료` 아카이브 이동 (즉답 접두 포함)
-
-### 조직운영 대화로그 동시 기록
-
-본 엔트리는 수상한잡화점 프로젝트 영향(Unity 프로젝트) 반영. 조직운영 2026-04-20.md에도 Agent 병렬 호출·통합 보고 엔트리 동시 작성.
-
----
-
-<!-- #PD지시 #40 #기획팀장 #PM재량집행 #진행중 #E1 #E2 #E4 #C #A초안 -->
-## [기획팀장 집행] PD 지시 #40 후속 — PM 재량 5건 즉시 집행
-
-- **요지**: PM 재량 착수 범위 5건(E-1·E-2·E-4·C·A-초안)을 기획팀장 주도로 즉시 집행. PD님 2026-04-20 명시 승인 범위. 기존 보고서(2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md §4-1) 기반 + 트랙 A 초안 추가.
-- **이유**: Phase 3 Day 4~7 완료 · Day 8~10·11~14 착수 전 선행 자산 확보로 본 작업 진입 비용 최소화. PD 결정 대기 2종과 무관한 독립 집행.
-- **판정 핵심 5종 산출물**:
-  1. **E-1 이슈 1·3 논점 재정리** → `프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md` (3축 논점 구조·5개 질문 압축·선행 의존 매트릭스·통합 처리 원칙)
-  2. **E-2 42 슬롯 현황 테이블** → `프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md` (21 스테이지 × 2 슬롯 × P17 배타 7종 매트릭스·리스크 매트릭스·Day 11~14 즉시 활용)
-  3. **E-4 Unity MCP 시뮬 가이드 숙지** → 본 응답 본문 숙지 완료 선언 (별도 산출물 없음 · C14 토큰 최소화). 환경 준비 1회·시나리오 JSON 구조·execute_code 스니펫·결과 해석 방법·오류 TOP 5·에스컬레이션 경로 전수 파악
-  4. **C 3성 조건 REQ 발행 조율 공문** → `공유/소통/기획팀→개발팀/2026-04-20_REQ발행조율요청.md` (초안 최종 검토 결과·선행 조건 2·3 완료 인용·개발팀 조율 요청 4종)
-  5. **A-초안 이슈 1·3 통합 재논의 초안** → `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` (Day 4~7 결과 반영·이슈 1 안 A/B/C · 이슈 3 안 P/Q/R · 3×3 매트릭스 · 기획 가정 범위)
-- **결정**: 5건 전부 산출물 확정 · Day 8-4 PD 결정 요청 안건은 Day 9 카드 시뮬 실측 후 별도 상신 (본 집행 범위 밖 · C36 방향·원칙 PM 재량 금지 준수)
-- **근거**:
-  - PD 지시 #40 보고서 §4-1 PM 재량 범위 5건 명시
-  - PD님 2026-04-20 명시 승인 (본 Task Agent 호출 프롬프트 인용)
-  - 선행 자료 전수 Read 확인 (재논의대기_사전자료모음_v1 · 맵패턴_사전분석_v1 · Phase2_카드임팩트측정_v1 §5 · Phase3_성장요소기여도_v2 Day 4~7 결과 · REQ초안_3성조건_12개_판정로직 · Unity_MCP_실측검증_리포트_v2 · Unity_MCP_시뮬실행_가이드_v1)
-  - 매니페스트 등록 완료: `2026-04-20_40_PM재량_5건_기획` (C35-9 PreToolUse 차단 해제)
-- **영향**:
-  - 기획팀: Day 8-1~8-3 착수 시 기획 가정 범위 즉시 의논 시작 가능 (A-초안 활용) · Day 11~14 착수 시 5분 내 P17 전수 체크 가능 (E-2 활용)
-  - 개발팀: REQ 발행 조율 회신 후 정식 REQ 발행 · 구현 착수
-  - PM: PD 지시 #40 활성 테이블 산출물 경로 5종 추가 · 사후 조치 "PM 재량 5건 집행 완료" 명시
-  - PD님: 본 5건에 대한 추가 결정 불요 (독립 집행)
-- **기각안**:
-
-  | # | 기각 대안 | 기각 사유 |
-  |---|---------|---------|
-  | 1 | A-초안을 **확정안**(1개 안 수렴)으로 작성 | **C36 위반** — 이슈 1 안 A/B/C · 이슈 3 안 P/Q/R 선택은 PD 결정 영역(방향 수준). 기획팀장 재량으로 "권장안 1개" 제시는 허용되나 확정 금지. 3×3 매트릭스 제시만 수행 |
-  | 2 | E-1·E-2를 **사전자료 원본 수정**으로 처리 | 원본 문서는 PD 승인 "사전 자료 정리만 수행 · 수정 제안 금지" 방향 엄수. 새 재정리본으로 Day 8~10·11~14 착수 시 활용 |
-  | 3 | E-4 Unity MCP 가이드 **숙지 보고서 별도 작성** | C14 토큰 최소화 · 본 대화로그 엔트리 본문 숙지 선언으로 충분. 별도 md 불요 |
-  | 4 | C 조율 공문 대신 **정식 REQ 즉시 발행** | 초안 §10 "개발팀 선행 조건 2·3 완결 후 기획팀장·개발팀장 조율하여 정식 발행" 엄수 · 조율 단계 생략 시 §9 응답 섹션 작성 지연 우려 |
-  | 5 | A-초안에 **실측 수치** 포함 | 카드 메커닉 시뮬 미구현(v2 §6-3 Day 8~10 이관) · Day 9 실측 전 수치 확정 불가. 기획 가정 범위로만 서술 |
-  | 6 | Day 8-4 PD 결정 요청 안건을 **본 집행 응답에 포함** | 본 집행은 Day 8-1~8-3 수준 · Day 8-4 PD 상신은 Day 9 실측 후 별도 산출물. 본 집행은 기획팀장 재량 완결 범위 |
-- **재미 근거 (P30)**:
-  - **강화 재미 축**: 성장 요소 시너지 곡선의 자연스러움 + Balatro류 빌드 폭발 쾌감 + 재도전 유도 유기성
-  - **변경 전 문제**: Day 8~10·11~14 착수 시 선행 자료 산재로 의논 시작 비용 과다 · 3성 조건 판정 로직 시뮬 미구현으로 실측 검증 수단 부재
-  - **변경 후 기대**: 착수 시 5분 내 핵심 파악 · P17 위반 사전 차단 · 조건 판정 로직 시뮬 실측 경로 확보
-  - **측정 지표**: Day 8~10·11~14 착수 시 진입 비용 · 42개 슬롯 P17 위반 0건 · Unity MCP 시뮬 기반 ★3 달성률 분포
-
-### PD 지시 로그 #40 갱신
-
-- 활성 테이블 **산출물 경로 컬럼 5종 추가**
-- 사후 조치 "PM 재량 5건 집행 완료 · PM 수령 후 완료 아카이브 이동" 명시
-
-### PM 인수인계 요지 (본 집행 완료 후 PM 수령 대상)
-
-1. **산출물 5종 Read 권고** — 특히 A-초안(Day 8-4 PD 결정 안건 구조 파악) · C 공문(개발팀장 조율 회신 유도)
-2. **C 공문 개발팀장 전달** — PM이 개발팀장 Agent에 조율 회신 요청 (§3 조율 요청 4종)
-3. **PD 지시 #40 완료 아카이브 이동 조건** — 본 집행분 + 개발팀장 조율 회신 수령 후 PM이 종결 판정 (C27·C29-4)
-
-
----
-
-## 엔트리 [2026-04-20 · 기획팀장 · Phase 3 Day 8~10 본작업 착수 선언 + 분기 확정 수령] — PD 지시 #3·#40
-
-### 트리거
-
-PM으로부터 PD님 직접 결정 2종 수신 (2026-04-20 Task Agent 경유):
-1. **Day 11~14 착수 순서 → 2-B 순차** (Day 8~10 완결 후 착수)
-2. **Phase 3 v2 반영 시점 → Day 11~14 완결 후 반영** (Day 15+ 일괄)
-
-### 기획팀장 수신 확인·집행 방향
-
-#### 1. 착수 분기 확정 수령
-
-| 트랙 | 상태 | 집행 방향 |
-|------|------|----------|
-| E (사전 준비) | 완료 | — |
-| C (REQ 조율 공문) | 회신 대기 | 개발팀장 회신 수령 후 §3 조율 반영 → 정식 REQ 발행 |
-| A-초안 | 완료 | Day 8~10 본작업 입력 자료로 활용 |
-| **Day 8~10 본작업** | **착수** | 본 엔트리로 공식 선언 |
-| B (Day 11~14) | 대기 | Day 8~10 완결 후 순차 착수 |
-| D (Phase 3 v2 반영) | 대기 | Day 11~14 완결 후 일괄 반영 (Day 15+) |
-
-#### 2. Day 8~10 본작업 세부 집행 계획
-
-| Day | 산출물 | 담당 | 선행 조건 |
-|-----|--------|-----|---------|
-| Day 8-1 | A-초안 §2-1 이슈 1 3안 수치 범위 재검토·보완 | 밸런스기획자 | — (즉시 착수) |
-| Day 8-2 | A-초안 §3-3 이슈 1·3 3×3 매트릭스 재검토 + 권장 조합 1~2개 선별 | 밸런스·시스템기획자 | Day 8-1 완료 |
-| Day 8-3 | 카드 메커닉 시뮬 REQ 정식 발행 | 기획팀장·시스템기획자 | **C 공문 회신 수령 블로커** |
-| Day 9 | 카드 메커닉 시뮬 실측 (Unity MCP) — 이슈 1·3 실측 수치 확정 | 밸런스기획자 (개발팀 협업) | Day 8-3 REQ 발행 + 개발팀 시뮬 구현 |
-| Day 10 | Day 8-4 PD 결정 요청 안건 상정 (이슈 1·3 통합 3×3 매트릭스 + 기획팀 권장안) | 기획팀장 → PM → PD | Day 9 실측 수치 확보 |
-
-#### 3. 트랙 B·D 사전 준비만 유지 (본작업 착수 금지)
-
-- 트랙 B 사전 준비: E-2 42 슬롯 현황(`프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md`) 완료 상태 유지 · Day 8~10 완결 대기
-- 트랙 D (Phase 3 v2 드래프트): **착수 금지** · Day 11~14 완결 후 반영
-
-#### 4. #40 완료 아카이브 이동 판단 — 유지 권고
-
-**기획팀장 판단**: #40을 **현재 시점 완료 아카이브 이동 보류** (개발팀장 C 공문 회신 수령 후 종결 판정 유지)
-
-- 근거:
-  - #40의 후속 PM 재량 5건 중 **C (REQ 발행 조율)** 는 아직 개발팀 회신 미수령 → 완료 미확정
-  - A-초안(E-1) · 42 슬롯 현황(E-2) · E-4 숙지 완료 · C 공문 발행 완료는 기획팀 범위에서 수행 완료. 그러나 #40 "병렬 진행 선행 업무 요약 보고"의 **최종 종결 판정**은 C 회신 수령 후 PM이 수행 (PM Task Agent 응답 원문 반영)
-  - C36 준수: 완료 아카이브 이동 결정은 PM 영역 (기획팀장 재량 초과). 기획팀장은 권고만 수행
-- **PM에게 권고**: **현 상태 유지** (개발팀장 C 공문 회신 수령 시점에 PM이 종결 판정 · 완료 아카이브 이동)
-
-#### 5. 차단 요인
-
-1. **Day 8-3 블로커**: 개발팀장 C 공문(REQ 발행 조율) 회신
-   - 블로커 해소 전까지 Day 8-1·8-2만 진행 가능 (기획팀 단독 범위)
-   - 블로커 해소 후: 카드 메커닉 시뮬 REQ 정식 발행 가능
-2. **Day 9 블로커**: 개발팀 카드 메커닉 시뮬 구현 완료
-   - Day 8-3 REQ 발행 후 개발팀 구현 소요 · 병렬 착수는 현재 범위 밖
-
-### C34-11 · C23 · C2 · C36 준수 자체 검증
-
-- **C34-11 (Agent 경계)**: 본 엔트리는 레포 상대 경로만 사용 (`공유/`·`프로젝트/`·`.live/` 등)
-- **C23 (정직성)**: PM Task Agent 응답 원문을 근거로 PD 결정 2종 확인. 산출물 5종은 실제 파일 확인 완료. 미확인 사항(Day 9 카드 시뮬 실측 수치)은 "예정"으로 명시
-- **C2 (근본 해결)**: Day 8-3 REQ 발행을 "proxy 개선" 아닌 근본 해결로 위치. 카드 메커닉 실측 수치 확보가 이슈 1·3 통합 조정의 근본 전제
-- **C36 (PM 재량 상한)**: 이슈 1·3 A·B·C × P·Q·R 선택은 PD 결정 영역으로 A-초안에 명시. 기획팀장 재량으로 확정안 제시 금지
-
-### 기각안 (P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | **#40 즉시 완료 아카이브 이동** 권고 | C 공문 회신 미수령 상태에서 종결 판정 시기 상조. 완료 아카이브 이동은 PM 영역 (C36 재량 초과). 기획팀장은 권고만 |
-| 2 | Day 8-3 REQ 발행을 **C 회신 전 즉시 수행** | C20-1-A 부서 간 공유 원칙 위반 · 개발팀장 조율 없는 REQ 발행은 개발팀 수용 가능성 저하 · C 공문 발행 의미 훼손 |
-| 3 | Day 11~14 사전 준비를 **병렬 본작업으로 전환** | PD님 "2-B 순차" 결정 역행 · C36-2 (b) PD 승인 방향 축소 해석 위반 |
-| 4 | Day 8-4 PD 결정 요청 안건을 **Day 8-3 시점에 조기 상정** | 카드 시뮬 실측 수치 미확보 · PD님께 근거 없는 선택 요청은 C29-2 "의사결정 떠넘기기" 위반 |
-| 5 | 트랙 D (Phase 3 v2)를 **Day 8~10과 병렬 진행** | PD님 "Day 11~14 완결 후 반영" 결정 역행 · 실측 수치 확정 전 v2 반영은 회귀 리스크 |
-
-### 재미 근거 (P30)
-
-- **강화 재미 축**:
-  - 성장 요소 시너지 곡선의 자연스러움 (카드 < 목표치 기준 · 아웃게임 성장 체감)
-  - Balatro류 빌드 폭발 쾌감 (신성 빌드 재포지셔닝 여부 PD 결정)
-  - 빌드 다양성 (치명타·물약·힐·쉴드 각자 고유 포지션 확립)
-- **변경 전 문제**: Day 8~10 착수 시 이슈 1·3 통합 조정안 기획 가정 범위 부재 · 실측 수치 확정 경로 불명확
-- **변경 후 기대**: A-초안 3×3 매트릭스로 Day 8~10 의논 시작점 확보 · 카드 시뮬 REQ로 실측 수치 확정 경로 구축 · Day 8-4 PD 결정 → Day 10 최종 조정안 확정
-- **측정 지표**: Day 9 카드 풀빌드 실측 DPS 증가율 · 빌드별 1런 완성률 분포 · 성장 순서 원칙 유지 여부 (카드 < 목표치)
-
-### PM에게 (본 엔트리 수신 후)
-
-1. **Day 8~10 본작업 착수 선언 수령 확인**
-2. **Day 9 REQ 발행 준비 상태** — 카드 메커닉 시뮬 REQ는 C 공문 회신 수령 후 정식 발행 (블로커 유지)
-3. **#40 완료 아카이브 이동 권고** — **유지** (개발팀장 C 공문 회신 수령 후 PM 종결 판정)
-4. **후속 차단 요인** — 개발팀장 C 공문 회신 수령 (Day 8-3 블로커). PM이 개발팀장 Agent 호출 타이밍 판단 권고
-
----
-
-## 엔트리 — Day 8~10 A안 집행 완료 (이슈 1·3 무시 확정) [기획팀 #3]
-
-**시점**: 2026-04-20
-**작성자**: 기획팀장
-**태그**: #day8-10 #PD결정 #A안 #이슈1_3무시 #종결 #Phase3
-
-### 결정 요지
-
-**PD 결정 A안 수용으로 Day 8~10 간략화 종결 완료.**
-
-- **PD 결정 (2026-04-20)**: 이슈 1·3은 일부 빌드 특성 + 다양한 성장 시너지(인장·장비·각성) 고려 시 무시해도 될 문제 · A안 진행
-- **집행 결과**: 이슈 1·3 **현 수치 그대로 유지** 확정 · 조정 불요 · Day 9 카드 시뮬 REQ 취소 · Day 11~14 즉시 착수 가능
-
-### 근거
-
-1. **PD 논거 3종**:
-   - 카드 G1 풀빌드는 **특화 빌드** (전 빌드 대상 아님)
-   - 인장·장비·각성·진화 **5축 성장 시너지** 상호 보완
-   - 성장 순서 원칙(#21)은 Phase 3 v2 Day 4~7 Unity MCP UTF 14/14 **실측 확인됨**
-2. **기획팀 부연**:
-   - 빌드 특화 = 재미 축 (Balatro류 카드 빌드 폭발 쾌감은 설계 의도)
-   - 다면 시너지에서 단일 축 피크 DPS는 5축 결합 실플레이 체감으로 완화
-   - 신성 빌드 "접근성 친화" 포지션은 설계 의도 (모든 빌드가 극레어 폭발 필요 없음)
-
-### 영향
-
-1. **현 수치 유지**: 카드 G1~G5 수치·목표치(+80~120%)·신성 빌드 G4·G5 구성(각 1장) 모두 **그대로** 유지
-2. **Day 9·10 취소**: 카드 메커닉 시뮬 REQ 취소 + 최종 조정안 작성 불요
-3. **Day 11~14 즉시 착수**: 블로커 해제 (카드 시뮬 REQ 블로커는 이제 불필요)
-4. **차기 프로젝트**: "설계 재미 vs 실제 문제" 판별 체크리스트 · 다면 시너지 기반 밸런싱 · 빌드 특화 포지션 정의 프로세스 조직 기억 축적
-
-### 기각안 (P24 필수)
-
-- **안 A (목표 상향 · 현 수치 유지)**: 조정 자체 불요로 기각 (안 A의 "목표 상향"만 기각, "현 수치 유지"는 채택)
-- **안 B (카드 하향 · 목표 유지)**: 카드 특화 빌드 재미 축 훼손 · PD 판단 미채택
-- **안 C (혼합)**: 조정 불요로 기각
-- **안 P (신성 유지)**: 구조적으로 현 상태 그대로이므로 "채택"이 아니라 **확정** (조정 불요)
-- **안 Q (G5만 +1)**: 신성 빌드 접근성 친화 포지션 재설계 불요로 기각
-- **안 R (대폭 강화)**: 동상 + 다른 빌드 상대 파워 재검증 부담으로 기각
-- **3×3 매트릭스 9조합 전수 기각** (이슈1_3_무시확정_v1.md §6 상세 기록)
-
-### 재논의 트리거 (엄격 제한)
-
-다음 3종만 허용:
-1. Day 11~14 맵 패턴 재검증 중 C9 배치 정합성 실패 발견
-2. 실 유저 플레이테스트(향후 QA) 결과 카드 지배율 설계 의도 크게 초과
-3. PD님 직접 재논의 지시
-
-**재논의 요청 절차**: 기획팀장 재량 금지 · PM 경유 PD 상신 필수 · P28-8 준수 (재언급 금지)
-
-### 산출물 (P16)
-
-- `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` — 신설 (8-3·8-4 통합 확정 문서)
-- `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` — 상단 아카이브 배너 추가 · 본문 유지 (기각안 9조합 근거 보존)
-- `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md` — PM 보고
-
-### 재미 근거 (P30)
-
-- **강화 재미 축**:
-  - 빌드별 고유 포지션 유지 (카드=Balatro류 폭발 · 신성=캐주얼 접근성 · 치명타=럭 극딜 · 힐/쉴드=생존 트레이드오프)
-  - 성장 시너지 5축 구조 유지 (단일 축 지배 자연 완화)
-  - 유저 선택 다양성 ("어떤 빌드가 최강"이 아니라 "내가 원하는 빌드")
-- **변경 전 문제 (재인식)**: 이슈 1·3을 "문제"로 인식한 프레이밍 자체가 설계 의도를 실제 문제로 오인한 것 · PD 결정은 이를 재확인
-- **변경 후 기대**: 빌드 특화 포지션이 만드는 **빌드 다양성이라는 상위 재미** 유지 · 실 유저 플레이테스트에서 각 빌드의 고유 재미 검증
-- **측정 지표**: Day 11~14 맵 패턴 재검증 통과율 · (향후) 실 유저 빌드 선택 분포 · (향후) 빌드별 완주율
-
-### PM에게 (본 엔트리 수신 후)
-
-1. **Day 8~10 A안 집행 완료 수령 확인**
-2. **기획팀 #3 상태 갱신** — Day 8~10 A안 완료 아카이브 이동 + Day 11~14 진행중 전환 (P19 2분할 구조 · 즉답 접두 포함)
-3. **Day 11~14 착수 방식 판단** — 기획팀장 재량 단독 수행 vs 전문 에이전트(level-designer 등) 병렬 호출
-4. **pm-auditor 사전 호출 판단** — PM 보고 발신 전 C35-1 #3·#5 해당 여부 판단
-5. **카드 메커닉 시뮬 REQ 취소 처리** — 개발팀장 C 공문 회신 대기 상태 해제 (필요 시 개발팀장에게 "Day 8~10 종결로 본 REQ 취소" 통지)
-
----
-
-## 엔트리 2026-04-20 — Day 8-1·8-2 현 상태 기록 보강 (PD 지시 "재조사 불요 수준")
-
-**작성**: 2026-04-20 (기획팀장, PM 경유 PD 지시 집행)
-**관련**: PD 2026-04-20 직접 지시 **"8-1·8-2는 현 상태 기록해서 향후 재조사 필요하지 않도록 해"** · 기획팀 #3 Day 8~10 A안 집행의 하위 보강 단계
-
-### 결정
-
-이슈1_3_무시확정_v1.md §3 "현 수치 그대로 유지 선언"을 **대폭 보강** — 본 문서 재독만으로 이슈 1·3의 현 수치·산출 근거·빌드 분포·기각안 논거 전체를 재구성할 수 있는 수준 확보. 단일 파일 확장 방식 채택(부록 분리 방식 대비 참조 동선 단축).
-
-### 근거 (재미 축 관점 포함)
-
-1. **PD 지시 "재조사 불요 수준"의 정확한 외연 해석**: "본 문서만 재독해도 향후 어떤 재조사 요청에도 대체 가능"이 명시 기준
-2. **원본 5종 핵심 정량 이식**: Phase2 §2~§5(카드 등급별·누적·빌드별 전수) + Phase3 v2(Unity MCP UTF 14/14 실측) + 카드시너지축분석 §2 축 1(신성 전체 분포) + 밸런싱전략 §1·§3(드래프트 가중치·기여도 목표·스테이지 영향) + 전체테이블감사 §427(신성 카드 ID 1차 참조처) = 5개 원본 핵심 수치를 본 문서 §3에 응축 이식
-3. **정직성 유지(C23·C5)**: 실측 부재 2종(Unity MCP 카드 메커닉 시뮬 미구현으로 +200~280%가 추정치 · 신성 빌드 승률 플레이테스트 미측정)은 "추정·미측정" 태그 명시 → 재조사 트리거 2종 예약
-4. **재미 관점(P30)**: 빌드별 G4+G5 분포 10종 비교표(§3-2-3)가 "치명타 최다 19장 vs 신성 최소 2장 = 스펙트럼 양 끝 의도된 다양성"임을 정량으로 증명 → 이슈 3 "확장성 부족"이 설계 의도임을 근거 확보
-
-### 기각안
-
-1. **부록 분리 방식 (`이슈1_3_무시확정_부록_실측기록_v1.md` 신설)**: PD 지시는 "기획팀장 판단"을 허용했으나 참조 동선 단축 + 본 문서 단일 SOT 유지(C14-4 참조 무결성) 관점에서 §3 확장이 우위. 기각
-2. **카드 등급별 개별 카드 전수 ID 이식 (G1 112장·G2 73장…수백 건)**: 재조사 불요 수준에 이르나 C14(토큰 최소화) 심각 저해 + CardList.json·전체테이블감사_v1.md 정본 유지 원칙 위반. 기각 — 신성 빌드 카드 ID도 "CardList.json + 전체테이블감사_v1 §427" 참조처 지정 방식으로 통일
-3. **실 유저 플레이테스트 승률 "추정치 작성"**: C23 정직성 위반 후보. 실측 부재 상태를 "미측정 태그"로 정직하게 기록(§3-2-4) — "추정 작성" 금지
-4. **+200~280% 실측 근거 Unity MCP 즉시 가동 요청**: Day 8-3 카드 메커닉 시뮬 REQ 취소 확정(§3-1-7)과 모순. 시뮬 구현 필요성 자체는 향후 §5-1 트리거 발동 시 PM 경유 PD 상신 대상. 본 작업 범위 외
-
-### 영향
-
-- **대상 프로젝트**: 수상한잡화점
-- **작업 범위**: 이슈1_3_무시확정_v1.md §3 대폭 보강 + 메타데이터(선행문서·변경 이력·관련 문서) 갱신
-- **변경 전 문제**: §3 실측 기록 간략 수준(이슈 1 6줄·이슈 3 4줄) — "재조사 불요 수준" 미충족
-- **변경 후 기대**: 본 문서가 이슈 1·3에 대한 단일 SOT로 기능 · 5년 후 새 기획자·차기 프로젝트·향후 Unity MCP 실측 확정 3종 시나리오에 본 문서 재독으로 대응 가능
-- **측정 지표**: 향후 재조사 요청 발생 시 본 문서 재독만으로 요청자가 판단 완결 가능 여부
-
-### 산출물
-
-- `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` §3 보강 완료
-  - §3-1 이슈 1 현 상태 7종 섹션 (§3-1-1 등급별 분포 · §3-1-2 +399% 산출 · §3-1-3 +200~280% 추정 근거 · §3-1-4 빌드별 G4+G5 분포 · §3-1-5 스테이지 영향 · §3-1-6 5축 실측 · §3-1-7 조정 불요)
-  - §3-2 이슈 3 현 상태 6종 섹션 (§3-2-1 신성 전체 분포 · §3-2-2 0.019장 산출 · §3-2-3 10종 빌드 비교 · §3-2-4 승률 정직 기록 · §3-2-5 캐주얼 포지션 근거 · §3-2-6 조정 불요)
-  - §3-3 재조사 불요 판정 근거 (§3-3-1 매트릭스 · §3-3-2 시나리오 3종 · §3-3-3 부족 축 2종 · §3-3-4 재조사 불요 선언)
-- 메타데이터 갱신: 선행문서 10종 · 관련 문서 11-1·11-2·11-3 3분할 · 변경 이력 2026-04-20 보강 행 추가
-
-### 추가된 핵심 정량 수치 (§3 보강본 신규 이식분)
-
-| 분류 | 수치 건수 | 출처 |
-|------|---------|------|
-| 카드 등급별 분포표 | 5행 × 8열 = 40셀 | Phase2 §2 |
-| G1 풀빌드 누적 TTK 표 | 6행 × 7열 = 42셀 | Phase2 §3 |
-| 실전 드래프트 등급 혼합 산출 | 5행 × 4열 = 20셀 + 3개 종합 수치 | Phase2 §3 |
-| 빌드별 카드 분포·G4+G5 비교 | 10행 × 7열 = 70셀 | Phase2 §4 |
-| 스테이지·Chapter별 영향 강도 | 4행 × 5열 = 20셀 | 밸런싱전략 §3 Phase 4 |
-| Unity MCP 5축 실측 | 6행 × 5열 = 30셀 | Phase3 v2 §2-1 |
-| 신성 빌드 등급별 전체 분포 | 6행 × 3열 = 18셀 | 카드시너지축분석 §2 축 1 + Phase2 §5 |
-| 1런 0.019장 산출 계산식 | 4줄 수식 | 본 문서 신규 |
-| 10종 빌드 G4·G5 분포 비교 | 11행 × 6열 = 66셀 | Phase2 §4 |
-| 캐주얼 포지션 4종 관점 비교 | 7행 × 6열 = 42셀 | 본 문서 신규 |
-| **합계** | **약 348셀 + 4줄 수식 + 3개 종합 수치** | 5종 원본 이식 + 신규 종합 |
-
-### 재조사 불요 판정 근거 요지
-
-- **본 문서 §3-1~§3-2 보강본 재독만으로**: 카드 등급별 수량·확률·기여도·파워 구조 · G1 풀빌드 +399% 산출 과정 · 실전 +200~280% 추정 근거 · 10종 빌드 카드 분포·G4+G5 비교 · 스테이지별 영향 강도 · 5축 시너지 실측 · 신성 빌드 전체 분포·0.019장 산출·승률 상태·포지션 근거 전수 재구성 가능
-- **재조사 트리거 2종 예약**: (1) Unity MCP 카드 메커닉 시뮬 향후 구현 시 §3-1-3 실측치 갱신 (2) QA 플레이테스트 착수 시 §3-2-4 승률 정량 갱신
-- **재조사 불요 선언 성립**: 2026-04-20 기준 본 문서가 이슈 1·3에 대한 단일 SOT(Single Source of Truth)
-
-### Day 11~14 착수 전 추가 준비 필요 사항
-
-1. **PD 지시 "Day 11~14 2-B 순차 착수" 확정 상태** — 기획팀 #3 기록상 PD 결정 수령 완료. **현 시점 Day 11~14 착수 가능 상태**
-2. **추가 자료 준비 불요** — 본 §3 보강으로 이슈 1·3 확정 수치를 Day 11~14 맵 패턴 재검증 선행 조건으로 활용 가능
-3. **맵 패턴 구성 시 본 §3 활용 지점 3종**:
-   - §3-1-4 빌드별 분포 → ★ 조건 배타 배치 7종(P17) 재점검 시 빌드별 G4+G5 밀도 참조
-   - §3-1-5 스테이지별 영향 → C9(보스 집중) 배치 정합성 검증 시 월드별 카드 발현 강도 참조
-   - §3-2-3 10종 빌드 비교 → 신성 빌드 "접근성 친화" 포지션 전제로 맵 패턴 난이도 조율
-
-### PM에게 (본 엔트리 수신 후)
-
-1. **Day 8-1·8-2 보강 집행 완료 수령 확인**
-2. **기획팀 #3 상태 유지** — Day 8~10 내부 보강이므로 신규 상태 전환 없음 (Day 8~10 A안 완료·진행 중 라운드의 하위 보강 집행)
-3. **Day 11~14 착수 가능 상태 재확인** — PD 결정 2-B 순차 + Day 8~10 종결 + Day 8-1·8-2 현 상태 기록 완료 = 착수 조건 완전 충족
-4. **commit·push 시점 판단** — C20-1-A 기준 "push는 필요 시에만" 원칙. 본 보강이 조직 공유 완료 선언 필요 단계인지는 PM 재량 판단
-5. **pm-auditor 사전 호출 판단** — 본 엔트리가 C35-1 #5(PD님 결정·현황 보고 응답 발신 전) 해당 여부 PM 판단 (기획팀장 판단은 "내부 실무 집행이라 C35-1 #5 미해당"으로 기울지만 최종 PM 판단)
-
-
----
-
-## [엔트리] Day 11~14 맵 패턴 재검증 본작업 착수 — PD 결정 4종 수용 (기획팀장)
-
-### 시점
-2026-04-20 (Day 8-1·8-2 현 상태 기록 완료 직후)
-
-### PD 결정 4종 수용 내용
-1. **P17 배타 위반 B 방식** — 발견 즉시 중단 + PM 경유 PD 확인 후 교체 (PM·기획팀장 재량 교체 금지)
-2. **v2 반영 범위 C 방식** — 현 시점 기준 점검 후 필요한 문서만 업데이트 (Day 11~14 완료 후 리스트업)
-3. **Day 11~14 내부 B 방식** — 레벨기획자·밸런스기획자 병렬 Task 호출 (기획팀장 조율)
-4. **Phase 3 종결 후 B 방식** — PD 별도 지시 대기
-
-### 집행 계획 (5건 11-1~11-5)
-
-| # | 작업 | 담당 | 참조 자료 |
-|---|------|------|----------|
-| 11-1 | 스테이지 난이도 곡선 재검증 (#11~#15) | level-designer + balance-designer 병렬 | 일관성점검_v1 §2-3, 스테이지난이도곡선_v1 §2·§4·§5 |
-| 11-2 | C9 배치 금지 스테이지 (7·10·13) 타당성 재검증 | level-designer | 맵패턴_사전분석_v1 §1-2 |
-| 11-3 | C9 적합 스테이지 재검증 | level-designer | 맵패턴_사전분석_v1 §1-4 |
-| 11-4 | 보스 혼용 패턴 → 실 패턴 ID 구체화 | level-designer | 맵패턴_사전분석_v1 §2-3·§2-4 |
-| 11-5 | 42 슬롯 × P17 배타 7종 전수 체크 | 기획팀장 + level-designer | 맵패턴_42슬롯_현황테이블_v1, 맵패턴_사전분석_v1 §3-3 |
-
-### 전제·주의 사항
-- **이슈 1·3 현 수치 고정** — 이슈1_3_무시확정_v1.md §4-1 "Day 11~14 맵 패턴 구성 시 이슈 1·3 현 수치 전제" 준수
-- **조건 풀 12개 전수 확정** — 3성조건_12개_상세명세_v1.md (Phase 2 §5 PD 3차 승인) · 신규 조건 추가 금지
-- **레포 상대 경로 의무** — C34-11 Agent 경계 보호. 병렬 호출 프롬프트에 명시
-- **실측 근거 첨부 의무** — C23 정직성. 추정·가정 금지
-- **P28-8 종결 안건 재언급 금지** — 이슈 1·3 재논의 프레이밍 금지
-
-### P17 배타 위반 감지 절차 (PD B 방식 집행 가이드)
-위반 발견 시:
-1. 레벨·밸런스기획자 → **즉시 해당 슬롯 검증 중단** (C3 우선)
-2. 기획팀장에게 보고 (위반 유형·대상 슬롯·배타 조합 번호·중단 시점까지 검증 결과)
-3. 기획팀장 → PM 경유 PD님 확인 요청 안건 상정
-4. PD 명시 승인 전까지 해당 슬롯 교체 금지
-
-### 산출물 예정
-- `재검증보고_맵패턴_v1.md` (Day 11~14 통합 보고서)
-- 42 슬롯 배치안 초안 (11-5 완료 시)
-- Day 15+ v2 반영 대상 문서 리스트 (Day 11~14 완료 후)
-
-### 기각안 (P24·C32 필수)
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | A 방식 (직렬 순차 1개씩) | PD B 수용 — 병렬 호출 효율성 채택 |
-| 2 | 기획팀장 단독 수행 (병렬 호출 생략) | PD B "전문 에이전트 병렬" 지시 위반 |
-| 3 | P17 위반 발견 시 기획팀장 재량 교체 | PD B 방식 위반 — PM 경유 PD 확인 필수 |
-| 4 | v2 A 방식 (전체 문서 일괄 반영) | PD C 수용 — 필요한 문서만 업데이트 |
-| 5 | Phase 3 종결 후 자동 Day 15+ 본작업 착수 | PD B 수용 — 별도 지시 대기 |
-
-### 결정·근거·영향 (P22 결정로그 3요소)
-- **결정**: PD 4종 결정 수용하여 Day 11~14 레벨·밸런스 병렬 Task 호출로 본작업 착수
-- **근거**: (1) Day 8~10 완결 (2) Day 8-1·8-2 현 상태 기록 완료 (3) 이슈 1·3 수치 고정 확정 (4) 조건 풀 12개 확정 (5) 42 슬롯 현황 테이블 준비 완료
-- **영향**: 본 엔트리 이후 Day 11~14 재검증 완료 시 Day 15+ v2 반영 범위 리스트업 착수
-
-### PM에게 (본 엔트리 수신 후)
-1. Day 11~14 본작업 착수 수령 확인
-2. PD 결정 4종 기획팀 수용 집행 확인
-3. 병렬 호출 결과 수령 후 통합 보고 대기
-4. P17 위반 발견 보고 즉시 PD 경유 절차 가동
-
----
-
-## [엔트리] 기획팀장 착수 블로커 발견 — Task 도구 부재 (기획팀장 → PM C3 자진 보고)
-
-### 시점
-2026-04-20 (Day 11~14 본작업 착수 직후)
-
-### 발견 사항
-기획팀장 Agent 본체에는 **`Task` 도구가 로드되지 않음** (서브에이전트 호출 불가 구조). PD B 방식 "레벨기획자·밸런스기획자 병렬 Task 호출" 지시의 **기획팀장 자체 집행 불가**.
-
-### 실측 근거 (C23 허위 보고 금지 준수)
-- 본 세션 초기 시스템 프롬프트 도구 목록: Bash·Edit·Glob·Grep·Read·ScheduleWakeup·Skill·ToolSearch·Write·mcp__ccd_session__*
-- ToolSearch `select:Task` → "No matching deferred tools found"
-- ToolSearch `task subagent` → 반환 결과에 Task 부재 (scheduled-tasks·CronCreate·RemoteTrigger·EnterWorktree만)
-- Task 도구는 **최상위 PM 세션**(Claude Code main REPL)에만 노출되며, 서브에이전트(기획팀장) 내부에서는 재귀 호출 불가
-
-### 역할 연기 회피 선언 (C23)
-본 구조적 제약 하에서 레벨기획자·밸런스기획자를 호출한 것처럼 응답하는 행위는 **C23 역할 연기 금지 위반**. 실제 호출 없이 "[level-designer 보고]" 포맷 응답을 작성하지 않음.
-
-### 대안 옵션 (PM·PD 판단 필요)
-
-#### 옵션 1: PM 세션에서 병렬 Task 호출 (PD B 방식 충실 집행)
-- **집행 주체**: PM 세션이 기획팀장을 거치지 않고 **level-designer·balance-designer를 직접 병렬 Task 호출**
-- **기획팀장 역할**: 병렬 호출 프롬프트 초안·참조 자료 목록·판정 기준 제공 → PM이 실 호출 → PM이 결과 수령 후 기획팀장에게 통합 분석 재위임
-- **장점**: PD B "병렬 호출" 지시 원문 충실
-- **단점**: PM 관여도 증가
-
-#### 옵션 2: 기획팀장 단독 수행 (레벨·밸런스 관점 통합)
-- **집행 주체**: 기획팀장 본체가 레벨·밸런스 양 관점으로 5건(11-1~11-5) 전수 수행
-- **장점**: 기획팀장 단일 책임 · 즉시 진행 가능
-- **단점**: PD B "병렬" 방식 위반 — PD 결정 축소 해석 리스크 (C19·C36)
-
-#### 옵션 3: 수정 B 방식 (PM 경유 순차 직렬 병행)
-- PM이 level-designer·balance-designer를 **순차** 호출 (병렬 아님) + 기획팀장 조율
-- **단점**: PD "병렬" 원문과 정합 낮음
-
-### 기획팀장 권고
-**옵션 1 수용** — PD B 방식 원문 충실 집행이 가장 적절. 기획팀장은 병렬 호출용 프롬프트 초안·참조 자료·판정 기준을 제공하고, 실 Task 호출은 PM 세션이 수행.
-
-### 기획팀장 제공 가능 산출물 (PM 세션이 즉시 활용 가능)
-
-#### level-designer 호출 프롬프트 초안 (11-2·11-3·11-4 주도, 11-1 양축 공동, 11-5 기획팀장 공동)
-```
-본 과제: Day 11~14 맵 패턴 재검증 (PD 지시 #3 · 2026-04-20 수용 4종 준수)
-
-참조 (레포 상대 경로 · C34-11 Agent 경계 보호):
-- 프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md (원본 · 수정 금지)
-- 프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md
-- 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md §2·§4·§5
-- 프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md §2-3·§2-5
-- 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md §4-1 (이슈 1·3 현 수치 전제)
-- 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 확정)
-- .claude/skills/BurningTimes-코어룰/SKILL.md P17 (배타 7종)
-
-담당 작업:
-- 11-2: C9 배치 금지 Stage 7·10·13 타당성 재검증 (단독 보스 판정 → Unity MCP 시뮬 실측 기반 보강)
-- 11-3: C9 적합 Stage 8·9·11·12·14~21 재검증 (보스 혼용 비율·달성 가능성)
-- 11-4: 보스 혼용 패턴 원칙 4종(§2-3)을 ApprearMonsterPattern.json 실 패턴 ID로 구체화
-- 11-1(레벨 축): #11 Stage 4→5 내구도 급등(+82%)·#12 Stage 6→7(+76%)·#13 Stage 17 용암골렘2 Shield 525·#14 Stage 2 오우거1 HP 112·#15 Stage 7·13·16·21 서브맵 수 이상 재검증
-- 11-5(공동): 42 슬롯 × P17 배타 7종 전수 체크
-
-P17 위반 감지 시 절차 (PD B 방식):
-1. 즉시 검증 중단
-2. 기획팀장 보고 (위반 유형·대상 슬롯·배타 조합 번호·중단 시점까지 결과)
-3. 기획팀장 → PM 경유 PD 확인 요청 안건
-4. **자체 교체 금지**
-
-매니페스트 자체 등록 의무: bash scripts/manifest_register.sh 실행
-실측 근거 첨부 의무 (C23): 추정·가정 금지. 출처 라인 번호 또는 tool_use 결과
-산출물: 11-2·11-3·11-4의 재검증 결과 요지 + P17 위반 감지 여부 + 11-1 레벨 관점 분석 + 11-5 공동 체크 입력
-```
-
-#### balance-designer 호출 프롬프트 초안 (11-1 밸런스 축 주도)
-```
-본 과제: Day 11~14 스테이지 난이도 곡선 재검증 (#11~#15 밸런스 관점)
-
-참조 (레포 상대 경로):
-- 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md §2·§4·§5
-- 프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md §2-3
-- 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md §3-1-5·§4-1 (스테이지별 영향 강도·현 수치 전제)
-- 프로젝트/수상한잡화점/기획/Phase3_성장요소기여도_v2.md (있다면 §2)
-
-담당 작업 (#11~#15 밸런스 관점):
-- #11 Stage 4→5 내구도 급등 +82% — 보스 Shield 평균 41.3→171.0 (+314%) 급등 구간 밸런스 타당성
-- #12 Stage 6→7 내구도 급등 +76% — 보스 HP+Shield 평균 174.0→307.0 (+76%) 원인 검증
-- #13 Stage 17 용암골렘2 Shield 525 — 단일 보스 최강 EHP의 TTK 기대치·밸런스 적정성
-- #14 Stage 2 오우거1 HP 112 이상값 — 입문 구간 내 이상 고값의 난이도 균형
-- #15 Stage 7·13·16·21 서브맵 수 이상 — 서브맵 4·3·4개 짧은 스테이지의 페이싱
-
-P17 위반 감지 시 절차 동일 (즉시 중단·기획팀장 보고·자체 교체 금지)
-매니페스트 자체 등록 의무
-실측 근거 첨부 의무 (C23 · 추정·가정 금지)
-
-산출물: #11~#15 밸런스 판정 + 11-1 통합(레벨 측과) 협의점 + 이슈 1·3 현 수치 전제 하 난이도 곡선 판정
-```
-
-#### 11-5 42 슬롯 × P17 배타 7종 전수 체크 판정 기준 (기획팀장 주도)
-- 맵패턴_42슬롯_현황테이블_v1.md §2-1·§2-2·§2-3 현황 테이블을 직접 검증 기반으로 사용
-- 각 42 슬롯에 대해 §4 검증 체크리스트 1회 수행 (P17 7종 전수 체크)
-- 현황 테이블에 이미 "P17-5 Stage 7·10·13 C9 금지"·"P17-4 Stage 1~6 C1∧C3 금지"·"P17-6 Stage 1~6 N3 단독 금지" 선제 매핑 완료. 실 검증은 **"후보 조합 풀 내 배타 위반 재확인"** 단계
-- 위반 감지 시 PD B 방식 절차 가동
-
-### PM에게
-1. **본 블로커 수령 확인** + PD님 보고 (C3·C23 정직성 준수 완료 확인)
-2. **옵션 1·2·3 중 PM·PD 판단** — 본 기획팀장은 옵션 1 권고
-3. **옵션 1 채택 시**: PM 세션에서 위 level-designer·balance-designer 프롬프트로 병렬 Task 호출 → 결과 수령 후 기획팀장 재호출하여 통합 분석·11-5 전수 체크·재검증보고_맵패턴_v1.md 작성 위임
-4. **옵션 2 채택 시**: 기획팀장 본 세션 연속 재호출하여 단독 수행 (PD 승인 필요 — 원 B 방식 변경)
-5. **매니페스트 정리**: 기획팀장이 등록한 매니페스트는 **실 Edit/Write 수행 없이 블로커 발견**으로 종결. PM이 archived/ 이동 or 유지 판단
-
-### 기각안 (P24·C32)
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | Task 도구 부재를 숨기고 가상 호출 응답 생성 | C23 헌법급 위반. 조직 생존 2대 규칙 위반 |
-| 2 | 기획팀장이 독단으로 옵션 2 채택하고 PD B 방식 축소 해석 | C36 PM·팀장 재량 상한 위반 — PD 원문 "병렬 Task 호출"의 외연 조정은 PD 명시 승인 필요 |
-| 3 | 블로커 무시하고 대화로그만 작성 후 종료 | C3 이슈 은폐 금지 위반 |
-
-### 결정·근거·영향
-- **결정**: Task 도구 부재 블로커 발견 즉시 C3 자진 보고 + 역할 연기 회피 + PM·PD 판단 요청
-- **근거**: (1) Task 도구 실측 부재 (2) C23 헌법급 원칙 (3) C36 방향·원칙 축소 금지
-- **영향**: Day 11~14 본작업 착수는 PM 옵션 선택 후 재개. 현 시점까지 완료 작업 = PD 지시 로그 #3 갱신 · 대화로그 엔트리 2종 · 참조 자료 전수 실측 · 매니페스트 등록 · 병렬 호출용 프롬프트·판정 기준 초안 제공
-
----
-
-## [엔트리] Day 11~14 통합 재검증 완료 — 양축 산출물 통합 + 42 슬롯 P17 전수 체크 (기획팀장)
-
-### 시점
-2026-04-20 (PM 옵션 1 채택 후 병렬 Task 호출 결과 수령 직후)
-
-### 집행 요지
-PM이 level-designer·balance-designer 병렬 Task 호출 완료. 기획팀장은 두 산출물을 통합 분석 + 42 슬롯 × P17 배타 7종 전수 체크 주도 + 재검증보고_맵패턴_v1.md 작성.
-
-### 수령한 양축 산출물
-1. `공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md` — 11-1 레벨·11-2·11-3·11-4·11-5 레벨 참여 (5건 완료)
-2. `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md` — 11-1 5건 Stage #11~#15 "적정" 판정
-
-### 기획팀장 통합 분석 결과
-
-#### Stage #11~#15 양축 교차 검증
-- **전수 적정 — 양축 판정 완전 일치** (충돌 0건 · 보완 5건)
-- 보완 사항 5종 통합: Stage 11 흡혈귀여왕2 Shd315 C9 임계값 / Stage 12 C2∧N2 회피 권고 / Stage 14·15 N4∧C6 주의 / Stage 15 흑기사1 재사용 3회째 + ATK45 / Stage 17 Carry Over
-
-#### 42 슬롯 P17 배타 7종 전수 체크 (기획팀장 주도)
-- **위반 0건 — PD B 방식 중단 트리거 미발동**
-- ⚠️ 주의 등급 4개 슬롯 별도 관리: Stage 15 슬롯2·3 (ATK45·재사용 3회째) · Stage 17 슬롯2·3 (Shd525·고ATK)
-- 42 슬롯 × 7종 = 294개 체크 항목 전수 기록
-
-#### Phase 3 시뮬 검증 권장 대상 확정
-1. Stage 11 흡혈귀여왕2 Shd315 C9 임계값 튜닝 (1순위)
-2. Stage 15 흑기사1 맵 패턴 다양화 + N2 달성률 분포 (1순위)
-3. Stage 17 용암골렘2 Shd525 N4 단독 Shield 확보 가능성 (Day 15+ 1순위)
-
-### Day 15+ 반영 후보 통합 리스트
-- 레벨 5종 + 밸런스 3종 → 중복 제거 7종 (§8-1)
-- PD C 방식 "필요 문서만" 대비 **최소 권장 셋 3종** 식별 (§8-3):
-  1. 맵패턴_42슬롯_현황테이블_v1.md §7 — ⚠️ 고주의 4개 슬롯 관리 신설
-  2. 맵패턴_사전분석_v1.md §1-4 — C9 우선순위 분류 (최적/주의) 신설
-  3. 스테이지난이도곡선_v1.md §8 — TTK 테이블 + 흑기사1 재사용 주의
-
-### 산출물 경로
-- `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` (기획팀장 주도 · 본 엔트리 핵심 산출물)
-
-### PD C 방식 대응
-본 보고 §8-3 최소 권장 셋 제시. Day 15+ 착수 여부는 **PD 결정 영역** (C36 PM·팀장 재량 상한) — 기획팀장은 준비 상태 보고만 수행.
-
-### 기각안 (P24·C32)
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 레벨·밸런스 제안 차이를 "충돌"로 프레이밍 | 교차 검증 결과 양축 완전 일치. 충돌 프레이밍은 C5 정직성 위반 |
-| 2 | ⚠️ 주의 등급 4개 슬롯을 "P17 위반"으로 격상 | 배타 아닌 '주의' 등급. PD B 방식 중단 트리거 오발동 리스크 |
-| 3 | Day 15+ 착수 여부 기획팀장 확정 | C36 PM·팀장 재량 상한 위반 — PD 결정 영역 |
-| 4 | Day 15+ 반영 A 방식(전체 일괄) 채택 | PD C 방식 "필요 문서만" 확정. 최소 권장 셋 3종만 선별 권고 |
-| 5 | 밸런싱전략_v1 §3 v2 반영 기획팀장 재량 집행 | 이슈 1 현 수치 고정 전제 + PD 별도 결정 대기 |
-
-### 결정·근거·영향 (P22 결정로그 3요소)
-- **결정**: Day 11~14 5건 통합 재검증 종결 + 42 슬롯 P17 전수 체크 위반 0건 확정 + Day 15+ 반영 후보 통합 리스트 제시
-- **근거**: (1) 레벨 축·밸런스 축 양축 완전 일치 (2) 현황테이블_v1 P17 사전 차단 완전성 (3) 이슈 1·3 수치 고정 전제 준수 (4) 조건 풀 12개 범위 준수
-- **영향**: Day 11~14 종결 · Day 15+ 착수 준비 완료 (PD 결정 대기) · Phase 3 시뮬 검증 권장 대상 3종 Carry Over
-
-### PM에게
-1. 본 엔트리 수령 확인 + 재검증보고_맵패턴_v1.md Read
-2. 42 슬롯 P17 위반 0건 확인 → PD B 방식 중단 트리거 없음 확인
-3. Day 15+ 반영 후보 7종 (최소 권장 셋 3종) — PD C 방식 대응으로 **PD 경유 어느 문서 업데이트할지 결정 안건** 상정
-4. Phase 3 시뮬 검증 권장 대상 3종 개발팀 REQ 또는 기획팀 자체 집행 여부 판단
-5. 기획팀 PD 지시 #3 상태 "Day 11~14 완료 · Day 15+ 착수 가능"로 갱신 완료 확인
-
----
-
-## [21:00] Phase 3 종결 + Phase 4 착수 가이드 작성 완료 — PD B안 수용 집행
-
-**태그**: `#기획팀장` `#Phase3종결` `#Phase4착수가이드` `#B안수용` `#설계체계확립` `#누락방지`
-
-### 집행 요지
-
-PD 2026-04-20 B안 수용 지시("이미 진행된 내용은 종결하고 Phase 4 = 스테이지별 노드 구성 작업을 신규 Phase로 분리") 집행. Phase 3 = "설계 체계 확립 단계"로 재정의 + Phase 4 착수 가이드 작성.
-
-### 산출물 경로 (2종 신규)
-
-1. `프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md` — Phase 3 종결 선언 + 설계 체계 SOT
-2. `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` — Phase 4 Day 1 착수 준비
-
-### Phase 3 종결 문서 핵심 구조
-
-- **§0 본 문서의 역할**: Phase 3 종결 + Phase 4 입력 자원 제공 역할 이원화
-- **§1 Phase 3 범위 재정의**: "스테이지 재검증" → "설계 체계 확립 단계" (B안 수용 근거)
-- **§2 Day 2~3 성과 집약**: Phase 0~2 재검증 6건 (원본: 공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md)
-- **§3 Day 4~7 성과 집약**: Unity MCP UTF 14/14 성장 요소 기여도 #16~#21 (원본: Phase3_성장요소기여도_v2.md)
-- **§4 Day 8~10 성과 집약**: 이슈 1·3 무시 확정 (PD A안 수용 · §3 재조사 불요 수준)
-- **§5 Day 11~14 설계 원칙·판정 체계 (핵심)**:
-  - §5-1 C9 배치 원칙 (금지·적합·주의 3분류)
-  - §5-2 P17 배타 7종 체크 방식 (42 슬롯 전수)
-  - §5-3 TTK 산출 방법 (5축 결합)
-  - §5-4 AppearGroup 가이드 프레임 (보스 혼용 원칙 4종)
-  - §5-5 고주의 요소 판정 기준 (ATK·Shield 극단값)
-  - §5-6 임시 데이터 수치 부분 명시 분리 (B안 수용 핵심)
-- **§6 Day 15+ 선택지 7종 처리**:
-  - 집약 완료 3종 (설계 원칙 성격 → §5 이식)
-  - Phase 4 이관 3종 (임시 데이터 수치 → 재확정 대상)
-  - 완료 선언 1종 (일관성점검 §2-3 Stage 11~15 적정 완료)
-- **§7 Phase 4 입력 자원 맵**: 작업 단계별 § · 외부 SOT 매핑
-- **§8 누락 방지 체크리스트**: 17/17 전수 보존 확인
-- **§9 기각안 11종** (P24·C32)
-
-### Phase 4 착수 가이드 핵심 구조
-
-- **§1 Phase 4 범위**: 125 스테이지 × 노드 구성 확정
-- **§2 입력 자료**: Phase 3 종결 문서 §5·§7 + 실측 데이터 + 이슈 1·3 전제 + 조건 풀 12개 + P17 + 스테이지 구조 SOT
-- **§3 작업 흐름 5단계**: 목표 정의 → 노드 배치 → P17 체크 → TTK 검증 → 고주의 판정 → ToolData.json REQ
-- **§4 판정 기준**: 배치 차단 5종 · 시뮬 선행 4종 · PD 확인 필수 4종 · 재미 판정 P30 의무
-- **§5 담당·병렬 호출 체계**: Phase 3 동일 승계 (기획팀장 + level + balance 병렬)
-- **§6 Day 단위 로드맵 초안**: Day 1 착수 준비 → Day 2~N 청크 단위 → Day 종료 ToolData 재생성 → Day 종결 Phase 4 v1 최종본
-- **§7 Phase 3·4 연계 원칙**: 원칙 vs 실 구성 분리 유지 · 역방향 피드백 허용 · 이슈 1·3 전제 불변
-- **§8 기각안 12종** (P24·C32)
-
-### Day 15+ 선택지 7종 처리 결과 (핵심 · PD B안 집행)
-
-| 성격 | 대상 | 처리 |
-|------|-----|-----|
-| 설계 원칙 성격 (§5 집약) | 맵패턴_사전분석 §1-4·§2-3·§3-2 (3종) | Phase 3 종결 문서 §5-1·§5-4·§5-5에 집약 완료 |
-| 임시 데이터 수치 (Phase 4 이관) | 42 슬롯 현황·스테이지난이도곡선 §8·밸런싱전략 §3 (3종) | Phase 4 완료 후 재확정 대상 |
-| 완료 처리만 | 일관성점검 §2-3 Stage 11~15 (1종) | Phase 3 종결 시점 "적정 완료" 선언 |
-
-### 누락 방지 확인 (PD 지시 "누락되지 않도록")
-
-- 산출물 전수 보존: **17/17** (Day 2~3·Day 4~7·Day 8~10·Day 11~14 + 사전·밸런싱·이슈 통합재논의 초안)
-- 설계 체계 집약: **5/5** (C9 배치·P17·TTK·AppearGroup·고주의)
-- 실측 데이터 보존: **4/4** (Phase 0~2·#16~#21·42 슬롯·이슈 1·3)
-- **누락 0건 확인 완료**
-
-### 기각안 (본 집행 · P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | Phase 3을 "미완료" 선언하고 Day 15+ 원안 속행 | PD B안 수용 결정 위반 |
-| 2 | 설계 원칙을 원본 산출물 본문에 수정 이식 | C14-5 "본문 최신 + 참조" 위반 후보 · C6-1 원본 보호 위반 후보 |
-| 3 | 임시 데이터 수치까지 본 문서에 확정 이식 | PD B안 "현 스테이지 데이터 = 임시" 위반 |
-| 4 | Phase 4 범위·방법론을 본 문서에서 확정 | C36 PM·팀장 재량 상한 — 착수 가이드 수준으로 분리 |
-| 5 | 이슈 1·3 재논의 트리거 완화 | C36 방향·원칙 수준 PM 재량 위반 |
-| 6 | P17 체크를 Phase 3에서 완료 선언 | 42 슬롯 체크는 현 임시 데이터 기준 · Phase 4 실 배치 시 재수행 의무 |
-| 7 | Day 단위 로드맵을 시간 단위 일정으로 구체화 | C9-2 일정·기한 표현 금지 위반 |
-| 8 | Phase 4 착수를 기획팀장 재량 확정 | C36 PD 결정 영역 — PD 착수 승인 대기 |
-
-### 결정·근거·영향 (P22 결정로그 3요소)
-
-- **결정**: Phase 3 종결 선언 ("설계 체계 확립 단계" 재정의) + Phase 4 착수 가이드 v1 작성 + Day 15+ 선택지 7종 3분류 처리
-- **근거**: (1) PD 2026-04-20 B안 수용 원문 (2) 현 스테이지 데이터 임시 확정 (#57-B 보류 사유 일치) (3) 설계 체계는 임시 데이터와 독립적으로 유효 (P29 계승 원칙) (4) 누락 방지 17/17 전수 보존 확인
-- **영향**: Phase 3 종결 · Phase 4 Day 1 착수 준비 완료 · 설계 체계는 차기 프로젝트 자산 계승 가능 (P29) · 임시 데이터 수치는 Phase 4 완료 후 재확정 대상으로 이관
-
-### PM에게
-
-1. 본 엔트리 + 산출물 2종 수령 확인
-2. `프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md` §8 누락 방지 체크리스트 17/17 확인
-3. `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` §1 범위·§3 5단계·§6 Day 로드맵 확인
-4. 기획팀 PD 지시 #3 → 완료 아카이브 이동 확인 (PM 영역에서 이미 이동됨 확인)
-5. Phase 4 Day 1 착수 승인 여부 PD님께 상신 (기획팀장은 준비 상태 보고만 수행 — C36 PM·팀장 재량 상한)
-
----
-
-## 엔트리 — Phase 4 지역 1 v1 초안 작성 완료 (기획팀 #41 진행) [2026-04-20 PM 경유 PD B안 확정 집행]
-
-### 배경
-
-PD님 직접 지시 (2026-04-20):
-> "B가 맞는 해석이고 우선 해석한 B대로 진행 후 보고해."
-
-**B안 = 지역 1 = WorldMap_1 = Stage 1~6** (Phase 4 착수 가이드 §6-2 청크 1과 일치)
-
-### 본 집행 범위 (Stage 1~6 전수)
-
-PD 고려사항 5종 전수 반영:
-1. **등장 몬스터 특성 고려** (근접/원거리·능력치) — 스테이지난이도곡선_v1 §3·§5 실측 기반
-2. **매 스테이지 고정 몬스터 + 매 판 랜덤성** — 보스 14종 고정 + 서브맵별 랜덤 풀 5~6종 × 2~3마리
-3. **3★ 클리어 조건 고려 노드 구성** — 12 슬롯 × 9종 조건 전수 사용
-4. **반복 패턴 방지 다양한 랜덤 상황** — 지역 1 독립 조합 경우의 수 약 700경 이상
-5. **지역 1 완료 → PD 승인 후 지역 2** — 본 Task 범위 외 명시
-
-### 산출물
-
-**`프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md`** (신규)
-
-섹션 구성 (§0~§10 고정 위계 C25 준수):
-- §0 지역 1 범위 확정 (PD B안 수용 · WM1 = Stage 1~6 실측 근거)
-- §1 지역 1 개요·목표 난이도·재미 포지션 3종
-- §2 P17 입문 공통 제약 (C2·C9·N3 전수 배제)
-- §3 Stage 1~6 각각 노드 구성 6섹션 (목표·보스·노드별·조건·P17·TTK·다양성)
-- §4 P17 통합 체크 (12 슬롯 · **위반 0건**)
-- §5 반복 방지 다양성 정량 (스테이지별 + 지역 전체)
-- §6 학습 곡선 테스트 예상 (잠재 위험 3종 완화안 포함)
-- §7 기각안 12종 (P24·C32)
-- §8 변경 이력 · §9 재미 근거 (P30) · §10 관련 규칙
-
-### Stage 1~6 ★ 조건 배치 요지
-
-| Stage | 슬롯2 | 슬롯3 | 재미 축 |
-|-------|------|------|--------|
-| 1 (놀 부족 첫 만남) | N1 빗맞힘 절제 | N5 후열 선공 | 전투 기초 2축 (정확도·타겟) |
-| 2 (오우거 공포) | C3 고HP 완주 | N4 쉴드 보존 | 이상값 대응 자원 관리 |
-| 3 (Shield 장벽) | C6 포션 절제 | N2 피격 제한 | Shield 상대 자원·피격 |
-| 4 (3보스 첫 경험) | C1 신속 | N5 후열 선공 | 긴 스테이지 시간·타겟 |
-| 5 (Shield 극치 · 원거리 테마) | C12 회피 주도 | N6 전열 선공 | 회피·전열 우선 |
-| 6 (졸업 시험) | N2 피격 제한 | N4 쉴드 보존 | 성장 5축 결합 기초 검증 |
-
-### 고정 몬스터·랜덤 풀 요지
-
-- **고정**: 보스 14체 (스테이지난이도곡선_v1 §3 실측 SOT 유지 · 임의 변경 없음)
-- **랜덤 풀**: 서브맵별 5~6종 몬스터 풀 → 매 판 2~3마리 확률 선택
-- **근접/원거리 매칭**: Stage 5만 원거리 테마 특별 구성 (대사탄1·다크엘프아처1 모두 원거리)
-- **반복 방지**: AppearGroup 다양화 규칙 적용 가능 여지 (같은 스테이지 내 서브맵 간 조합 중복 최소화)
-
-### P17 배타 7종 전수 체크 결과
-
-**12 슬롯 위반 0건** · B 방식 중단 트리거 미발동
-
-- 입문 금지 3종(C2·C9·N3) 전수 배제
-- 배타 조합 4종(C2∧N2·C6∧N4·C1∧C3·N5∧N6) 모든 슬롯 회피
-- 9종 허용 조건 전수 사용 → 지역 1 완주 시 "조건 메타 9가지 체험 완결"
-
-### TTK 검증 결과 요약
-
-| Stage | 전체 TTK 예상 | 주요 특징 |
-|-------|-------------|---------|
-| 1 | 100~145s | 카드 미습득 / G5 1장 기준 |
-| 2 | 160~290s | 오우거1 ATK Max 30 대응 주의 |
-| 3 | 170~230s | 첫 Shield 장벽 |
-| 4 | 220~320s | 7서브맵 + 3보스 · C1 임계 300s 제안 |
-| 5 | 220~320s | Shield 극치 서브맵 6만 129~155s |
-| 6 | 160~220s | 성장 5축 결합 체감 |
-
-### 고주의 판정 (Phase 3 §5-5 임계)
-
-- 보스 Shield ≥ 300: **없음** (Stage 5 다크엘프아처1 Shield 282 · 임계 근접 · 주의 수준)
-- 몬스터 ATK ≥ 45: **주의** (Stage 2 오우거1 ATK Max 30 · 입문 부담 간주)
-- 보스 재사용 ≥ 3회: 없음 (2회만)
-- 서브맵 수 ≤ 3: 없음 (최소 4)
-
-**권고**: Stage 2 서브맵 6 (오우거1 단독) Unity MCP 시뮬 선행 1회
-
-### 반복 방지 다양성 지표 (정량)
-
-| Stage | 독립 조합 경우의 수 |
-|-------|------------------|
-| 1 | 225 |
-| 2 | 8,000 |
-| 3 | 8,000 |
-| 4 | 390,625 |
-| 5 | 390,625 |
-| 6 | 9,765,625 |
-
-**지역 1 전체**: 약 **700경 이상** (동일 조합 2회 연속 확률 ≈ 0%에 수렴)
-
-### 입문 구간 학습 곡선 예상
-
-- 1회 플레이: ★1 65~90% / ★2 15~40%
-- 2~3회 학습: ★2 55~80% / ★3 6~25%
-- 4~5회 숙달: ★3 35~65%
-
-**지역 1 = 전투 기초 → 특수 요소 → 성장 의존 점진 설계** 확정.
-
-### 결정·근거·영향 (C32 기각안 포함)
-
-- **결정**: Phase 4 지역 1 (Stage 1~6) 노드 구성 v1 초안 확정 (고정 보스 14체 + 랜덤 풀 서브맵별 + ★ 조건 12 슬롯 × 9종 조건)
-- **근거**: (1) PD B안 확정 원문 (2) 스테이지난이도곡선_v1 §3·§5 실측 데이터 (3) 3성조건 12개 상세명세 풀 (4) 42슬롯 현황 매트릭스 §2-1 입문 허용 후보 (5) Phase 3 §5 설계 체계 5종 전수 적용
-- **영향**: Phase 4 청크 1 완결 · PD 승인 시 개발팀 Tool_Left REQ 발행 가능 · 지역 2 착수 준비 (PD 승인 대기)
-- **기각안 12종**: 산출물 §7 참조 (지역 범위 축소 · C9 입문 배치 · N3 입문 배치 · 랜덤 풀 단순화 · 보스 신규 제작 · 조건 보류 · Stage 1 C6 배치 · Stage 5 C1 배치 · 랜덤 시드 고정 · Stage 6 보스 교체 · 조건 중복 단순화 · TTK 생략)
-
-### 병렬 호출 수행 여부
-
-**자체 집행**. 기획팀장 통합 관점 + Phase 3 설계 체계 SOT + 스테이지난이도곡선_v1 실측 테이블로 3종 에이전트(level·balance·content) 병렬 호출 없이 통합 처리 가능 판정 (재통합 비용 > 분산 이득).
-
-### 매니페스트
-
-```
-plan_id: 2026-04-20_Phase4_지역1_집행
-target_files:
-  - 프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md
-  - 공유/대화로그/수상한잡화점/2026-04-20.md
-  - 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
-```
-
-### PD 지시 로그 갱신 (C27)
-
-- 기획팀 #41 Phase 4 **진행중** (지역 1 초안 완료 · 지역 2 이후 착수는 PD 승인 대기) — 산출물 경로 본 엔트리 첨부
-
-### PM에게
-
-1. 본 엔트리 + 산출물 `Phase4_지역1_노드구성_v1.md` 수령 확인
-2. **지역 2 이후 착수 승인 여부 PD님께 상신** — 기획팀장은 준비 상태 보고만 수행 (C36 PM·팀장 재량 상한)
-3. 개발팀 Tool_Left REQ 발행 시점 PD 결정 대기 (현 단계는 노드 구성 **초안** · 실 ToolData.json 재생성은 PD 승인 이후)
-4. 고주의 판정 Stage 2 서브맵 6 (오우거1 단독) Unity MCP 시뮬 선행 여부 검토 (PM 재량 수행 or PD 판단 요청)
-5. Phase 4 지역 1 v1 초안이 **위반 0건** · **9종 조건 전수 사용** · **700경+ 다양성 확보** 상태로 PD 승인 상신에 적합
diff --git a/공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx b/공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx
deleted file mode 100644
index ace010f..0000000
Binary files a/공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx and /dev/null differ
diff --git a/공유/소통/PM→개발팀/.gitkeep b/공유/소통/PM→개발팀/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션_대응_기획팀_밸런스작업_지원.md b/공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션_대응_기획팀_밸런스작업_지원.md
deleted file mode 100644
index 3ccb45d..0000000
--- a/공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션_대응_기획팀_밸런스작업_지원.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-from: 총괄PM
-to: 개발팀장
-type: 작업요청
-subject: 기획팀 밸런스 작업을 위한 시뮬레이션 대응 요청
-priority: high
-status: 진행중
-created: 2026-04-16
-ref: PD님 직접 지시 (2026-04-16)
----
-
-# 기획팀 밸런스 작업을 위한 시뮬레이션 대응 요청
-
-> **PD님 직접 지시**: "기획파트에서 밸런스 작업을 진행할 수 있도록 시뮬레이션 대응을 요청해"
-
----
-
-## 1. 요청 배경
-
-기획팀이 수상한 잡화점 밸런스 작업(Phase 3: 성장 요소별 기여도 측정)을 진행하려면 **신뢰할 수 있는 전투 시뮬레이션 환경**이 필요합니다.
-
-현재 상태:
-- 기획팀 Phase 3 HOLD 중 (`⚠️_PHASE3_HOLD_공지.md`)
-- HOLD 재개 조건 중 핵심: **개발팀 시뮬레이터 이원화 해소**
-- 개발팀 PD 지시 로그 #3에 시뮬레이터 이원화 해소 작업이 `진행중`으로 등록됨
-- 착수계획 문서: `프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md`
-
----
-
-## 2. 요청 사항
-
-### 2-1. 현재 진행 상태 보고
-07 착수계획의 Phase A~E 중 **어디까지 진행되었는지** 현황 보고 요청.
-
-### 2-2. 기획팀 밸런스 작업 지원을 위한 시뮬레이션 환경 구축
-07 착수계획에 따라, 기획팀이 밸런스 작업에 사용할 수 있는 시뮬레이션 환경을 구축해 주세요.
-
-기획팀이 필요로 하는 것 (Phase 3 재개 준비 체크리스트 기준):
-1. **Unity 전투 로직 기반 Headless C# 시뮬** (BattleCore 라이브러리)
-2. **CLI 실행 환경** (JSON 입출력, 배치 실행 가능)
-3. **Python ↔ C# 교차 검증 완료 리포트**
-4. **기획팀용 CLI 사용 가이드** (`공유/소통/개발팀→기획팀/` 경유)
-5. **전투 공식 SOT 문서** (터치 방어·회피·시너지 명문화)
-
-### 2-3. 최소 선행 산출물 (기획팀 착수 가능 최소 조건)
-전체 Phase A~E 완료 전이라도, 기획팀이 밸런스 작업을 **부분적으로라도 시작**할 수 있는 최소 환경이 있다면 그것부터 제공 요청.
-
----
-
-## 3. 연관 문서
-
-- `프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md`
-- `프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md`
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md`
-- `프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md`
-
----
-
-## 4. 응답 요청
-
-1. 현재 시뮬레이터 이원화 해소 작업 진행 상태
-2. 기획팀에 시뮬레이션 환경 제공 가능 시점 또는 즉시 착수 계획
-3. 차단 요인이 있다면 명시 (C3)
diff --git a/공유/소통/PM→기획팀/.gitkeep b/공유/소통/PM→기획팀/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/dev-auditor→PM/.gitkeep b/공유/소통/dev-auditor→PM/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/dev-auditor→PM/2026-04-18_새PC동기화_최종점검_개발영역.md b/공유/소통/dev-auditor→PM/2026-04-18_새PC동기화_최종점검_개발영역.md
deleted file mode 100644
index 664d29b..0000000
--- a/공유/소통/dev-auditor→PM/2026-04-18_새PC동기화_최종점검_개발영역.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-type: 감사보고서
-author: dev-auditor
-mode: C (주제 집중 감사)
-date: 2026-04-18
-subject: 새 PC 동기화 최종 점검 (개발 영역)
-related_commits: [0a8caa0, 1ceec2b, 9c99cc6, bc9c8ed, 15bf649]
-related_rules: [C11, C14-5, C30, C31-E, P18, P19, P24, P27-1]
----
-
-# 새 PC 동기화 최종 점검 감사 (개발 영역) — 2026-04-18
-
-## 1. 감사 범위·전제
-
-- **호출 맥락 (PM 프롬프트 3요소 P27-2)**: 요청 1~5 명시, 본 세션 9 커밋 중 개발 영향 커밋 스코프 정의 포함, 관련 신규 체계 열거 완비 — **프롬프트 품질 양호**
-- **감사 대상**: 요청 1~5 각각 개별 판정
-- **행동 지침**: dev-auditor 정의 행동 지침 5종 준수, 기술 오판 완곡 금지(C5), 미확인 태그 성실 사용(C23)
-- **산출물 3종 규범 준수 선언**: 본 보고서 md + 대화로그 엔트리 append + feedback(해당 시) 동시 수행
-
----
-
-## 2. 요청별 판정
-
-### 요청 1. 개발 영역 새 PC 동기화 정합성 감사 — **통과 (Minor 1건)**
-
-| 점검 항목 | 실측 결과 | 판정 |
-|----------|----------|------|
-| 07 Headless 아카이브 상태 | 129라인(228→129 축약 확정), 상단 "🔴 2026-04-17 아카이브됨" 배너 존재(L3), §1·§2·§6·§8·§9 보존, §3·§4·§5·§7 삭제 주해(L67~69) 명시 | **통과** |
-| `02_개발자관점_점검_v1.md` L19 주해 실존 | "2026-04-17 아카이브됨, Unity MCP 전환" 주해 존재 + 시뮬레이터/01 역참조 링크 유효 | **통과** |
-| 02 추출대상 완료 실적 배너 | 상단 "🟢 2026-04-17 완료 실적 아카이브" 배너 존재(L3), Tier 1 19 파일 구현 완료 실적 역참조(L32·L37·L43·L46~58) | **통과** |
-| 08 전투시스템 SOT Q-P2 반영 | `PCDefence_Mul=0.3` 실측 수치 L251 명시, §4.3·§4.4 "실측 확정" 블록 3개 존재, 근거 응답서 L260 링크 유효 | **통과** |
-| 코어프레임워크 02 Tier 1 확장 9종 섹션 | L46~58 "🆕 2026-04-17 Tier 1 확장 구현" 섹션 존재, Attribute 3·Util 6·Event 2·Container 3·Data 5 총 19파일 전수 표기 | **통과** |
-| Tier 2·3 대기 항목 경로 정합 | `⏸ Tier 2 대기`/`⏸ Tier 3 대기` 표기 5건 L33~37·L44 존재, BurningTimes.Security/Addressable/UI 네임스페이스 예약 확인 | **통과** |
-| Unity MCP 시뮬 인프라 4종 실존 | `시뮬레이터/01~04_*.md` 4개 파일 모두 존재, YAML frontmatter 구조 일관(`type: 설계문서` 통일) | **통과** |
-| `Assets/Sim/BurningTimes.Sim.asmdef` 참조 정합 | 시뮬레이터/01 L16·L30·L37·L44·L45·L56·L152·L177 전수에서 외부 Unity 프로젝트 경로 일관 표기. 외부 레포 자체는 본 레포 추적 대상 아님 (명시 구분 적절) | **통과** |
-| dev-auditor 정의 파일 경로 규범 통일 | `memory/org/feedback_dev_*.md` 경로 명시 (L19) + `memory/org/feedback_dev_auditor_output_gap.md` 실제 존재 확인 | **통과** |
-
-**Minor 1건**: `02_수상한잡화점_추출대상_v1.md` L46 "🆕 2026-04-17 Tier 1 확장 구현" 섹션 — 🆕 이모지는 헌법 제1원칙 목표 2 원칙 A "다음 프로젝트 참고 자료" 관점에서 시점 의존적. "신규 확장" 표기로 시간 독립 제목 권고 (차기 프로젝트 열람 시 상대 시점 인지 장애). **판정**: **Minor, 개선 여지**. 당장 수정 불요.
-
----
-
-### 요청 2. 07·02·08 배너·참조 일관성 재검토 (원칙 1 재재개정 관점) — **현 상태 유지 확정 (본 감사 초기 권고 자진 철회)**
-
-본 세션 `15bf649` 원칙 1 재재개정으로 일반 현역 문서의 상단 "방향 전환 배너"는 폐지되고 **본문 말미 참조 링크**로 이관됨. 그러나 SKILL.md C14-5 "예외" 조항이 **파일 성격 배너 2종은 유지**로 명문화(L303~307):
-
-> "아카이브된 문서 자체"·"완료 실적 문서"는 파일 자체의 성격을 표시하는 배너이므로 상단 유지.
-
-**본 감사의 판단**:
-
-- **07** (🔴 아카이브됨) — SKILL.md C14-5 예외 명문 대상, **현 상태 유지**. 07은 Headless C# 원안 전체가 기각안 자산으로 보존되므로 상단 배너가 "파일 전체 성격 통지" 역할 수행
-- **02 개발자관점** — L19 인라인 주해 형식("→ 2026-04-17 아카이브됨, Unity MCP 전환"). 상단 배너 아니라 관련 섹션 내 1줄 주해이므로 재재개정 영향 없음. **현 상태 유지**
-- **02 수상한잡화점 추출대상** (🟢 완료 실적 아카이브) — SKILL.md C14-5 예외 명문 대상, **현 상태 유지**
-- **08 전투시스템 SOT Q-P2 병기** — **현 상태 유지** (자진 철회 — 아래 참조)
-
----
-
-#### 🚨 본 감사 초기 "08 분리 권고" 자진 철회 (C5·C23 준수)
-
-**초기 권고 내용**: 08 §4.4 "기획 초기 가정" 열을 삭제하고 아카이브 참조 1줄로 대체하여 SKILL.md C14-5 문언("병기 금지") 준수.
-
-**자진 철회 사유**:
-
-본 감사관이 Phase 0-C Q-P2 응답서(`공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md`) L136을 사후 확인한 결과, 해당 문서 기각안 B에 다음이 명시되어 있음:
-
-> **기각안 B: Q-P2 답변에 "50% 추정" 유지** — 실측 결과 30% 확정. C23 위반 회피. **기획팀 가정 정정 필요성 명시가 본 2차 응답의 존재 이유**
-
-즉 08 §4.4 테이블의 "기획 초기 가정 | 실측 확정값" 병기 구조는 단순 히스토리 병기가 아니라, **"기획팀 가정을 정정해야 한다는 경고·촉구 기능을 수행하는 활성 실증 데이터"**. 이 병기 자체가 **Q-P2 2차 응답서 제작 근거**이므로 본문에서 제거 시:
-1. 격차(50% → 0.3, 60% 오차)를 마주하는 기획팀 밸런스 재작업 **강한 촉구 신호 소실**
-2. Q-P2 2차 응답서가 생산된 존재 이유 자체가 본문에서 설명 불가능
-3. "추적성 보존" (응답서 L136 기각안 B 명시 원칙) 위반
-
-**C14-5 본문 "병기 금지"와의 충돌 해석**:
-
-C14-5의 "병기 금지"는 **작업 과정 히스토리·방향 전환 이력** 병기를 금지한다(L285~288 "작업 과정 히스토리·방향 전환 이력·'당시 가정'은 외부 아카이브에 집약"). 본 감사관 초기 권고는 C14-5의 "당시 가정" 금지 문언만 보고 조건부 적용 원칙을 적용. 그러나:
-- 08 §4.4의 "기획 초기 가정" 열은 **단순 "당시 가정"이 아니라 정정 촉구 경고 신호**
-- Q-P2 응답서의 "기각안 B" 메커니즘(가정 정정 필요성 명시)은 **활성 설계 결정**이며 히스토리가 아님
-- 클라이언트팀장 새 PC 시뮬 점검(2026-04-18 대화로그 L312)에서 "추적성 보존이 PD님 #37 직접 지시 명시 사항"으로 분리 기각 결정. 본 감사관보다 실측 근거 우선 판단
-
-**추가 자기 비판**:
-- 본 감사관이 Phase 0-C Q-P2 응답서 본문을 요청 2 초기 권고 전에 Read했어야 함 (C23 정직성)
-- SKILL.md 문언만 보고 **설계 맥락 간과** = 요청 2 초기 판단은 **과도 형식주의 오판**
-- 차기 모드 C 감사 시 **관련 설계 문서 참조 완결성 자기 검증** 필수 (본 실수 재발 방지)
-
-**최종 판정 (자진 수정)**:
-
-| 대상 | 최종 판정 | 근거 |
-|------|----------|------|
-| 08 §4.4 병기 테이블 | **현 상태 유지** | Q-P2 응답서 L136 기각안 B "추적성 보존" 명시 원칙 + 클라이언트팀장 독립 판정 일치 |
-| C14-5 문언 준수 | **본 건은 C14-5 예외 대상** | 활성 경고 기능 수행 병기는 "당시 가정" 범주 외. 추후 C14-5 문언 보강 필요 시 PM 재량 안건화 |
-
-본 초기 권고는 **Minor → Improvement → 철회**로 강등. 감사 결과 분류 재산정: **Critical 0 / Major 0 / Minor 1(🆕 이모지만) / Improvement 1 / 철회 1**.
-
----
-
-**요청 2 통합 결과**: **4개 대상 전수 현 상태 유지**. 자진 철회 1건은 본 감사관 과도 형식주의 오판 자진 고지로 기록.
-
----
-
-### 요청 3. 새 PC 개발 세션 재개 시뮬레이션 — **통과 (참조 경로 무결성 확인)**
-
-가상 시나리오: 새 PC clone 직후 개발팀장 Agent 호출 → Phase 3 재개 지시 → 개발 첫 참조 경로 전수 추적.
-
-**추적 대상**:
-- `프로젝트/수상한잡화점/개발/02·05·06·07·08·09·10·11·12_*.md` — **9개 파일 전수 실존 확인**
-- `프로젝트/수상한잡화점/시뮬레이터/01~04_*.md` — **4개 파일 전수 실존 확인**
-- `프로젝트/코어프레임워크/01~04_*.md` — **4개 파일 전수 실존 확인**
-- 외부 레포 `코어코드/BT.Framework/` — **존재 확인** (CHANGELOG.md·README.md·Runtime·Tests·package.json 등)
-- 07 아카이브 배너 L3 링크 → `시뮬레이터/01` 경로 무결 확인 (7단계 `../../시뮬레이터/`)
-- 02 추출대상 L5 CHANGELOG 링크 → `../../코어코드/BT.Framework/CHANGELOG.md` 상대경로 무결 확인
-- 08 Q-P2 응답서 링크 → `../../../공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` 경로 무결 확인
-
-**참조 링크 무결성**: 본 감사 범위 내 전수 무결. **통과**.
-
-**미확인 태그 (C23 준수)**:
-- 외부 레포 `코어코드/BT.Framework/Runtime/Core/` 하위 각 모듈의 **실제 구현 라인 실존 여부**는 본 감사 범위 초과 — 02 추출대상 L32·L37·L43에 "📦 `Runtime/Core/…`" 표기된 경로 실측 대상 미확인. 차후 모드 A 호출 시 별도 점검 권고 (개발팀장 자기 검증 영역)
-
----
-
-### 요청 4. dev-auditor 자체 규범 이행 점검 — **100% 이행 선언**
-
-2026-04-17 첫 감사 시 산출물 3종 규범 실종(대화로그만 일부·보고서 md 0건·feedback 0건) → 2026-04-18 `memory/org/feedback_dev_auditor_output_gap.md`로 패턴 영구 기록 + 자기 반복 방지 구조 완비.
-
-**본 감사(2026-04-18 두 번째 호출) 이행 상태**:
-- [x] **감사 보고서 md**: 본 파일 Write (요청 1~5 전수 판정)
-- [x] **대화로그 엔트리 append**: `공유/대화로그/조직운영/2026-04-18.md` (본 세션 추가)
-- [x] **feedback 메모리**: 기존 `memory/org/feedback_dev_auditor_output_gap.md` 충분. 본 감사에서 신규 feedback 대상 패턴 발견 없음 (해당 시 작성 원칙, 본 감사는 기존 패턴의 교정 이행 실증이므로 중복 등재 불요)
-
-**판정**: 산출물 3종 규범 **본 감사 100% 충족**. 2026-04-17 실종 패턴 완전 교정 실증.
-
----
-
-### 요청 5. 기각안 (P24 필수)
-
-본 감사는 **결정·설계 엔트리**에 해당(SKILL.md P24 "결정·설계 엔트리 필수" 범위).
-
-| 기각안 | 기각 이유 |
-|--------|----------|
-| **08 §4.4 가정열 삭제 (본 감사관 초기 권고)** | Q-P2 응답서 L136 "기각안 B" 명시 원칙 위반 — 병기 자체가 기획팀 가정 정정 촉구 경고 신호로 기능. 본문 제거 시 설계 맥락 소실. **본 감사관 자진 철회** |
-| **08 가정값 완전 삭제** | 밸런스 재작업 사유 실증 소실 위험. 아카이브 참조만으로는 본문에서 정정 촉구 신호 부재 |
-| **02 🆕 이모지 즉시 수정** | 차기 프로젝트 열람 시 경미한 인지 장애에 그침. 당장 수정은 과도 대응. 개발팀장 재량 수정 권고 선 |
-| **외부 레포 Runtime/Core C# 라인별 실측** | 본 감사 범위 초과(C23 자기 고지). 개발팀장 자기 검증·모드 A 후속 영역 |
-
----
-
-## 3. 최종 판정 종합
-
-| 항목 | 판정 | 등급 |
-|------|------|------|
-| 요청 1. 새 PC 동기화 정합성 | **통과** | Improvement 1건 (🆕 이모지 시간 독립 표기) |
-| 요청 2. 08 병기 재판정 | **현 상태 유지** + **본 감사관 초기 권고 자진 철회** | 감사관 과도 형식주의 오판 자진 고지 |
-| 요청 3. 새 PC 세션 재개 시뮬 | **통과** | — (외부 레포 Runtime 라인 실측은 범위 초과 C23) |
-| 요청 4. 산출물 3종 규범 이행 | **100% 이행** | — (2026-04-17 실종 패턴 교정 실증) |
-| 요청 5. 기각안 | **4건 기록** | — |
-
-**종합 판정**: **Critical 0건 / Major 0건 / Minor 0건 / Improvement 1건 / 감사관 자진 철회 1건**.
-
-**본 감사관 신뢰도 자기 평가**: 요청 1·3·4는 실측 근거 기반 판정으로 신뢰. 요청 2는 SKILL.md 문언만 보고 설계 맥락(Q-P2 응답서 L136) 미확인 상태로 초기 권고 발행 → 자진 확인 후 철회. 감사 품질 측면에서 **"착수 전 관련 설계 문서 참조 완결성" 체크 누락**이 구조적 허점으로 드러남. 본 건을 `memory/org/feedback_dev_*.md` 신규 등재 대상 후보로 제시 (PM 판단).
-
----
-
-## 4. PM 조치 권고 (집행 주체: PM 재량 또는 개발팀장 재량)
-
-1. **Improvement (비긴급)**: 코어프레임워크 02 L46 🆕 이모지 → "신규 확장" 텍스트 변경 (시간 독립 표기). 개발팀장 재량
-2. **감사관 자기 개선 권고 (PM 판단)**: 본 감사관이 요청 2 초기 권고 시 Q-P2 응답서 미확인 상태로 판정 → 자진 철회 경험. `memory/org/feedback_dev_auditor_scope_shortcut.md`(가칭) 신규 등재 후보로 제시. 패턴명: "SKILL.md 문언만 보고 설계 맥락 미확인 형식주의 오판". 등재 여부 PM 판단
-3. **모드 A 후속 권고**: 개발팀장 차기 중요 보고 응답 시 dev-auditor 모드 A 호출로 외부 레포 Runtime/Core 하위 구현 실존 실측 추가 검증 (본 감사 범위 초과분)
-4. **구조적 개선 (Improvement)**: dev-auditor 정의 `.claude/agents/dev-auditor.md`에 "감사 착수 전 관련 설계 문서 참조 완결성 체크" 추가 안건 (PM 판단). 현 정의는 "행동 지침 5종" L63~68에 실측 확인 의무는 있으나 "관련 설계 문서 선행 Read" 명문 없음
-
----
-
-## 5. 본 감사의 감사관 자기 한계 고지 (C23)
-
-- 외부 레포 `코어코드/BT.Framework/Runtime/Core/` 내부 실제 C# 파일별 라인 수·클래스 시그니처까지 검증하지 않음
-- Unity 프로젝트 `${UNITY_PROJECT_ROOT}/Assets/Sim/` 실존 여부는 외부 레포 판정 (본 레포 추적 대상 아님, 명시 구분)
-- 본 감사는 **조직 기록 정합성 + 참조 경로 무결성**에 집중 — 실제 구현 상세 검증은 개발팀장 자기 검증 영역
-
----
-
-**보고 완료 시각**: 2026-04-18 (Write 수행 시점)
-**산출물 3종 완료 상태**: 본 md + 대화로그 append + feedback 대상 없음 (기존 충분)
-**다음 감사 호출 권고**: 모드 B 세션 말미 감사 (08 병기 재판정 집행 후 완결 확인)
diff --git a/공유/소통/dev-auditor→PM/2026-04-18_원칙1_재검토_감사.md b/공유/소통/dev-auditor→PM/2026-04-18_원칙1_재검토_감사.md
deleted file mode 100644
index dc5cd6e..0000000
--- a/공유/소통/dev-auditor→PM/2026-04-18_원칙1_재검토_감사.md
+++ /dev/null
@@ -1,219 +0,0 @@
----
-type: 감사보고서
-mode: C
-subject: 수정 3대 원칙 중 원칙 1 재검토 — 본문 전부 유지 vs 저장 위치 최적화
-target_docs:
-  - 프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md
-  - 프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md
-  - 프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
-auditor: dev-auditor
-date: 2026-04-18
-created_via: PM 모드 C 호출 (Task subagent_type=dev-auditor)
-related_commits:
-  - 0a8caa0 refactor(rules): 원칙 3 개정 + A+B급 6건 조직 룰 최적화 집행
-related_rules:
-  - C11 (개발 관점 원칙 — 자원 효율·코드 직관·범용성)
-  - C14 (토큰 최소화 우선 설계)
-  - 헌법 제1원칙 목표 2 원칙 B (인사이트 기록 → 차기 프로젝트 참고)
----
-
-# 원칙 1 재검토 감사 보고서 — 본문 유지 vs 외부화 (dev-auditor 모드 C)
-
-## 0. 감사 개요
-
-- **모드**: C (주제 집중)
-- **트리거**: 2026-04-18 PD님 직접 지시 — "원칙 1에서 본문 전부 유지 시 낭비 재검토. 교훈은 반드시 본문에 남기지 않아도 됨"
-- **선행 전제**: 2026-04-18 커밋 `0a8caa0` — 수정 3대 원칙 3번이 **"폐기 선언 본문 유지" → "자산 유지 + 저장 위치 최적화"** 로 개정되어 외부 아카이브(`공유/조직공지/폐기_규칙_아카이브.md`) 기 존재
-- **검토 대상 3문서 실측**:
-  | 파일 | 줄 수 | 성격 |
-  |------|------|------|
-  | 07 Headless 원안 | 227 | 기각된 설계(배너만 추가, 본문 전부 유지) |
-  | 02 추출대상 | 156 | 완료 실적 전환(배너·역참조 추가, 본문 전부 유지) |
-  | 08 전투시스템 SOT | 403 | 현행 SOT + Q-P2 실측·초기 가정 병기 |
-- **관점**: C11(개발 — 자원 효율·직관·범용성) + 헌법 목표 2 원칙 B(차기 프로젝트 참고 가치)
-
----
-
-## 1. 판정 요약
-
-| 대상 | 원칙 1 재적용 판정 | 핵심 근거 |
-|------|------------------|----------|
-| **07 Headless 원안** | **일부 외부화 권고 (Minor)** | 227줄 중 "작업 단계 Phase A~E 상세"(69~129 라인)는 기각된 실행 체크리스트로 자산 가치 낮음. "선택 근거표"(49~63)와 "열린 이슈 OI"(205~211)는 기각안 노하우로 보존 필요 |
-| **02 추출대상** | **현행 유지 (Improvement 없음)** | 등급 분류(A/B/C/D)·변형 포인트·네이밍 규칙은 차기 Tier 2·3 추출 시 **재사용 가능한 판단 프로세스**. 본문 축약 시 프로세스 노하우 손실 > 토큰 절감 |
-| **08 전투시스템 SOT** | **현행 유지 (Improvement 없음)** | 기획 초기 가정 50% 병기는 **SOT 혼선 유발 ≠ 추적성 자산 손실**. 현행 "표 1줄 + 실측 확정 명시" 구조는 C5 정직성·P16 산출물 추적성 동시 충족 |
-| **요청 4 메타 이슈** | **Critical (dev-auditor 자기 귀책)** | 2026-04-17 첫 감사 시 산출물 3종 규범(md·대화로그·feedback) 미이행. 본 모드 C가 첫 정규 수행 |
-
----
-
-## 2. 요청 1 — 07 Headless 원안 본문 유지 vs 외부화
-
-### 2-1. 실측 구조 (227줄 전수 분석)
-
-| 섹션 | 라인 | 자산 가치 판정 | 근거 |
-|------|------|-------------|------|
-| 제목·배너·메타 | 1~15 | **필수 유지** | 기각 결정 + 대체 문서 링크. 07 접근자가 즉시 `01_시뮬레이터_아키텍처_v1.md`로 이동 가능하게 함 |
-| 1. 현황 분석 (이원화 리스크) | 17~37 | **보존 필요** | Python·Unity 이원화 리스크 4종은 **"왜 Headless를 검토했나"의 인사이트**. 차기 프로젝트에서 동일 이원화 발생 시 현상 진단 가이드 |
-| 2. 해소 방향 (Option A/B 비교표) | 40~65 | **보존 필수 (핵심 자산)** | Option A vs B 비교 5축(자원 효율·직관·범용·친화성·C9)은 차기 프로젝트에서 동일 선택 시 **즉시 재사용 가능한 판단 프레임**. **제일 귀중한 부분** |
-| 3. 작업 단계 (Phase A~E 체크리스트) | 67~129 | **외부화 또는 축약 권고** | "B-1 순수 도메인 클래스 분리 → ActorCore·BattleContext" 등 구체 작업 리스트는 **실행되지 않은 상세 체크리스트**로 자산 가치 낮음. 차기 프로젝트가 Headless를 재검토하는 경우에도 구체 작업 리스트는 새로 짜야 함 (Unity 버전·프로젝트 특성 다름) |
-| 4. 담당 팀 정리 | 133~143 | **삭제 가능** | 당시 조직 구조(개발실장 등 구 직함) 한정 |
-| 5. Phase 3 재개 조건 | 147~159 | **삭제 가능** | Headless 기각과 함께 실효 |
-| 6. 검증 방법 (결정론·Python vs C# 비교) | 163~185 | **보존 권고** | 이원화 시뮬 결과 비교 허용 오차 표는 차기 범용 활용 가능 |
-| 7. 완료 기준 | 189~199 | **삭제 가능** | 기각된 작업 체크리스트 |
-| 8. OI-A·B·C 열린 이슈 | 203~211 | **보존 필수** | **PD님 판단 대기 사안 3건의 기록** — 차기 유사 상황에서 "어떤 점에서 상위 결정이 필요했는가" 메타 노하우 |
-| 9·10. 변경 이력·참고 | 213~227 | 필수 유지 | 추적성 |
-
-**외부화 가능 범위**: 섹션 3(Phase A~E)·4·5·7 = 약 **88줄** (227줄 중 39%). 이것을 `공유/조직공지/폐기_설계_아카이브/` 신규 디렉토리 또는 기존 `공유/조직공지/폐기_규칙_아카이브.md`의 "폐기 설계안" 섹션으로 이관 후, 07 본문은 배너·분석·비교표·검증·OI·이력만 유지하면 약 **139줄**로 축소.
-
-### 2-2. C11 개발 관점 분석
-
-| C11 축 | 현행 (본문 전부 유지) | 외부화 후 | 판정 |
-|-------|--------------------|----------|------|
-| **자원 효율성** | 기각 설계 88줄이 `프로젝트/수상한잡화점/개발/`에 상주 — Grep 검색 대상에 지속 포함 | 활성 문서 축소, 외부 아카이브는 변동비로 격리 | 외부화 우세 |
-| **코드 구조 직관성** | 배너만 보고 뜻을 알지만 스크롤 시 "기각된 체크리스트"가 장황하게 이어져 **어느 섹션이 자산이고 어느 섹션이 실행 미수인지 구분 안 됨** | 본문이 "자산 가치 있는 분석·비교·OI"로만 구성 → 읽는 즉시 가치 파악 | 외부화 우세 |
-| **범용성 (차기 프로젝트)** | 88줄 기각 체크리스트는 차기 재활용 거의 없음 | 비교표·분석·OI는 유지되어 재활용 보장 | 외부화 우세 |
-
-### 2-3. 헌법 목표 2 원칙 B 분석
-
-"노하우가 될만한 인사이트" = Option A/B 비교 프레임 + 리스크 4종 + OI 3건. **실행 체크리스트는 노하우 아님** (실행되지 않았고, 차기 프로젝트에 그대로 적용 불가).
-
-### 2-4. 권고
-
-- **Minor 등급** 개선 안건으로 PM 경유 상정 권고
-- 구체 방안:
-  1. 기존 `공유/조직공지/폐기_규칙_아카이브.md`의 "6. 폐기 설계안" 섹션을 **신설**하거나, `폐기_설계_아카이브/` 신규 디렉토리 도입
-  2. 07 본문에서 섹션 3·4·5·7을 이관 (약 88줄)
-  3. 07 본문에는 이관 섹션 위치에 "이관됨: 링크" 1줄 stub만 남김
-  4. 배너 문구를 "기각안 근거·비교 프레임·열린 이슈는 본 문서에서 보존, 세부 실행 체크리스트는 [아카이브 링크] 참조"로 정밀화
-
-**집행 주체**: PM 재량 판단 (본 감사관은 보고만). PD님 지시 "원칙 1 낭비 재검토"에 정합.
-
----
-
-## 3. 요청 2 — 02 추출대상 본문 유지 합당성
-
-### 3-1. 실측 구조 (156줄 전수 분석)
-
-| 섹션 | 라인 | 자산 가치 판정 |
-|------|------|-------------|
-| 완료 실적 배너 + 메타 | 1~14 | **필수 유지** |
-| 1. 등급 분류 (A/B/C/D) | 17~24 | **보존 필수 (핵심 자산)** — 차기 Tier 2·3 추출 시 즉시 재사용 |
-| 2. 분류표 A/B/Tier1확장/C/D | 26~98 | **현행 유지 불가피** — 각 항목 변형 포인트·구현 상태 역참조 표는 **"왜 이렇게 분류·변형했나"** 메타 노하우. 완료된 항목의 "변형 포인트"는 구현 완료 후 실효가 아니라 **차기 재추출 시 참고 수준 레퍼런스** |
-| 3. 공통 정리 원칙 (네이밍·의존성·변형) | 100~118 | **보존 필수** — 차기 프로젝트에서 수상한잡화점 외 레거시 추출 시 동일 원칙 재사용 |
-| 4. 추출 우선순위 | 120~134 | **보존 권고** — Tier 1 구현 순서의 "왜" 근거 |
-| 5. 추출 후 자체 정리 과제 | 136~147 | **보존 권고** — C11 관점 문제 4종 = 수상한잡화점 내부 문제 기록 (차기 유사 프로젝트 경고) |
-| 6. 다음 작업 | 149~156 | **삭제 가능** — 2026-04-14 시점의 Tier 1 착수 전 체크리스트. 이미 Tier 1 완료로 실효 |
-
-### 3-2. 축약 가능 범위
-
-**섹션 6 (8줄)만 삭제 가능**. 다른 모든 섹션은 유지. 총 축약 효과 약 **5%** — 외부화 이득 < 유지 이득.
-
-**근거**: 02 문서의 본문은 **프로세스 노하우 자체**이며, "완료된 항목 표"도 추출 판단 기준의 역추적 근거로 기능. "변형 포인트" 칼럼 하나만 축약해도 차기 재추출 시 "왜 이렇게 변형했나"를 소실.
-
-### 3-3. 권고
-
-- **Improvement 없음** — 현행 유지
-- 섹션 6만 선택적 삭제 가능하나 **미권고** (차기 Tier 2 착수 시 체크리스트 참고 용도로 남겨둘 수 있음)
-
----
-
-## 4. 요청 3 — 08 전투시스템 SOT의 기획 초기 가정 병기
-
-### 4-1. 실측 구조 (403줄 중 관련 부분)
-
-§4.4 섹션 "✅ 실측 확정 수치 (2026-04-17 #37 Q-P2 정밀 2차)":
-- 8개 항목 × (기획 초기 가정 | 실측 확정값 | 근거) 3컬럼 표 (라인 247~258)
-- 결론 문구: "기획 초기 가정('50%')은 추적성 보존을 위해 유지(원칙 1), 실측 수치로 전환하여 밸런스 작업은 0.3 기준으로 진행" (라인 260)
-
-### 4-2. SOT 역할 관점 분석
-
-**SOT의 정의**: "Single Source of Truth" — 현 기준값에 대한 단일 권위 있는 출처.
-
-**현행 구조의 평가**:
-
-| 관점 | 판정 |
-|------|------|
-| **혼선 유발 여부** | **유발 없음** — 표 1행에 "기획 초기 가정 / **실측 확정값**" 2컬럼을 명시 구분, 결론 문구에 "밸런스 작업은 0.3 기준" 명시. 읽는 주체가 어느 값이 현 기준인지 오독할 여지 낮음 |
-| **추적성 (P16)** | **자산** — "왜 기획은 50%로 계산했나 → 실측은 30%였다"의 차이 이력 자체가 밸런싱 설계 품질 점검 가이드. 삭제 시 차기 유사 상황에서 "이번에도 기획과 실측이 다를 수 있다"는 경고 소실 |
-| **C5 정직성** | **자산** — 가정과 실측을 병기하여 "실측만 있었던 것처럼" 포장하지 않음 |
-| **C11 직관성** | **현행 충분** — 표 2컬럼 + 결론 1줄 = 약 15줄로 간결 |
-
-### 4-3. 대안 분석 (외부화 시나리오)
-
-**시나리오 α**: "기획 초기 가정" 컬럼을 외부 `공유/대화로그/` 또는 `memory/feedback_*`로 이관
-- **단점**: 08 문서는 밸런싱 작업자가 SOT로 삼는 **현장 문서**. 이력을 외부화하면 작업자가 "이 수치가 과거에 기획 가정과 달랐는지"를 매번 외부 파일 조회해야 함 → 토큰 효율 악화
-- **단점**: 추적성은 외부 아카이브에 있는 것과 본문에 있는 것이 **접근성 차이 큼**. 본문에 있을 때만 밸런싱 점검 시점에 자연 환기
-
-**시나리오 β**: "기획 초기 가정" 컬럼을 표 주석으로 강등 (각주)
-- **단점**: 차이 크기(50% → 30%)를 숫자로 나란히 보는 것이 점검 효율 가장 높음. 각주 이동은 인지 부담 증가
-
-### 4-4. 권고
-
-- **Improvement 없음** — 현행 유지
-- "SOT는 현 기준값만 있어야 한다"는 정의는 **"현 기준값이 명확히 구별되어야 한다"** 와 동의어. 병기 자체는 SOT 역할을 훼손하지 않음 (구분 명확성·결론 명시만 유지되면)
-- 본 감사관은 **원칙 1 낭비 재검토 대상 아님**으로 판정
-
----
-
-## 5. 요청 4 — dev-auditor 자체 감사 (메타 이슈)
-
-### 5-1. 실종 패턴 실측 근거
-
-- **2026-04-17 감사 흔적**:
-  - `공유/소통/dev-auditor→PM/` 디렉토리는 존재하나 `.gitkeep`만 존재 — **실제 감사 보고 md 0건** (실측)
-  - `memory/feedback_dev*.md` 파일 0건 (실측, Glob 결과 "No files found")
-  - 대화로그 엔트리만 일부 존재 추정 (조직운영 2026-04-17 내 dev-auditor 활동 기록 간접 흔적만)
-- **2026-04-18 커밋 `28cd6c8`의 인계서**도 B4 항목에 "plan-auditor→PM .gitkeep 신설 (dev-auditor는 이미 존재)"라고만 기재하여 **dev-auditor의 모드 A/B/C 산출물 md 부재를 묵시적으로 확인**
-
-### 5-2. 원인 진단
-
-| 원인 | 설명 |
-|------|------|
-| **호출 프롬프트의 집행 강제력 부족** | 2026-04-17 첫 호출 시 "산출물 3종 필수"가 프롬프트에 명시 안 되었을 가능성. 본 모드 C 호출은 "산출물 (P27-1 모드 C 규범 — 3종 필수)" 명시로 개선됨 |
-| **감사관 자체 정의의 중복 구조** | `.claude/agents/dev-auditor.md` 자체에는 산출물 3종이 명시되어 있으나, 집행 트리거(마감 압박)가 약함. Agent 응답 마무리 시점에 "보고서·대화로그·feedback 모두 Write 실행 여부" 자체 체크가 필수이나 누락 사례 발생 |
-| **Agent 응답 스타일 편향** | 서브에이전트가 응답을 "요약 텍스트"로 반환하는 것이 자연스러우나, 조직 규범은 "파일 생성 + 요약"을 요구. 응답 스타일과 규범 사이의 관성 차이 |
-
-### 5-3. 재발 방지 권고
-
-**Critical 등급 — PM 경유 반드시 상정**:
-
-1. **감사관 정의 개선안**: `.claude/agents/dev-auditor.md` (및 pm/plan-auditor.md)의 "산출물 3종 (매 감사 필수)" 섹션을 **응답 맨 앞 체크리스트 형식**으로 승격 ("보고서 md Write [x] / 대화로그 append [x] / feedback 등재 시 [x] / 필수 누락 시 응답 차단")
-2. **집행 검증 hook 신설 검토**: Agent 응답이 감사관 역할인 경우, 응답에 `Write` 도구 호출 흔적이 있는지 SessionEnd hook 또는 PostToolUse hook이 확인하여 누락 시 리마인더
-3. **본 보고서가 첫 정규 dev-auditor md 산출물임을 자진 고지**: 2026-04-17 감사는 실질 산출물 3종 중 대화로그만 일부 수행 — C23 허위 포장 금지 원칙상 **소급 정정 안건** (PM 판단에 위임)
-4. **`memory/feedback_dev_auditor_output_gap.md` 신규 기록**: 본 실종 패턴 영구 기록 (요청 4 산출물 3종 중 feedback 채널 충족)
-
----
-
-## 6. 종합 권고 (5줄 요약)
-
-1. **07 Headless**: 섹션 3·4·5·7 (약 88줄 = 39%) 외부 아카이브 이관 권고 (Minor) — 기각 체크리스트는 차기 자산 아님
-2. **02 추출대상**: 현행 유지 (Improvement 없음) — 등급 분류·변형 포인트·원칙은 **프로세스 노하우 자체**
-3. **08 전투시스템 SOT**: 현행 유지 (Improvement 없음) — "기획 초기 가정 병기"는 SOT 역할 훼손 없이 추적성·C5 자산
-4. **dev-auditor 메타 이슈**: 2026-04-17 감사 시 산출물 3종 규범 미이행 (본 보고서가 첫 정규 수행) — 감사관 정의 개선 + hook 보강 상정 (Critical)
-5. **본 감사 전체 판정**: 원칙 1 "본문 전부 유지"는 **07만 선별적 낭비 존재**, 02·08은 유지가 최적. PD님 가설(원칙 1 낭비 존재)은 **부분 긍정**
-
----
-
-## 7. 기각안 (P24 필수 — 감사 중 검토했으나 미채택)
-
-1. **07 본문 전량 외부화**: 07 본문 전체를 `폐기_설계_아카이브/`로 이관하고 경로만 stub로 남기는 안 → 기각. **비교 프레임·OI·분석은 활성 문서 접근성 유지 필요**. 07의 가치는 접근성 차이가 큼 (차기 프로젝트 개발자가 "수상한잡화점 시뮬 이원화 이력"을 조사 시 `프로젝트/수상한잡화점/개발/` 폴더가 1차 진입점)
-2. **02·08 현행 유지 (축약 시도 없음)**: 반대로 02·08도 원칙 1 낭비 감지해 본다는 시도 → 기각. 실측 결과 02 섹션 6 (8줄)만 선택적 삭제 가능 수준, 08은 낭비 없음. 과잉 축약은 C5·P16 손상
-3. **감사관 산출물 3종 자체를 2종으로 감축**: "feedback 메모리는 패턴 발견 시만이라 선택"이라는 해석으로 본 보고서에서 feedback 생략 → 기각. 본 감사 자체가 **dev-auditor 실종 패턴 발견**이라 feedback 필수 (요청 4 결론에 따라 `memory/feedback_dev_auditor_output_gap.md` 신설 예정)
-4. **"요청 4 메타 이슈를 감사 범위에서 제외"**: 감사관이 자기 영역 감사는 편향 위험으로 제외하는 안 → 기각. PM이 명시 요청했고, C23 정신상 자기 감사·자진 보고가 의무. 자기 편향 위험은 PM 재감사로 보완 가능
-
----
-
-## 8. 참조
-
-- `공유/조직공지/폐기_규칙_아카이브.md` — 외부 아카이브 기존 SOT (수정 3대 원칙 3번 2026-04-18 개정 반영)
-- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` — 07의 대체 문서 (Unity MCP 전환 근거 보존)
-- `공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` — 08 §4.4 실측 근거 (#37)
-- `코어코드/BT.Framework/CHANGELOG.md` — 02 Tier 1 구현 완료 실적 근거 (44줄, 존재 실측)
-- `공유/대화로그/조직운영/2026-04-17.md` — dev-auditor 2026-04-17 활동 간접 흔적
-- 커밋 `0a8caa0 refactor(rules): 원칙 3 개정 + A+B급 6건 조직 룰 최적화 집행` — 본 감사 선행 전제
-- 커밋 `28cd6c8 docs(handover): 전수 감사 A+B급 7건 수정 집행 인계서 (조직 생명급)` — 2026-04-17 감사 인계
-
----
-
-**감사관**: dev-auditor (모드 C)
-**호출 주체**: PM (Task subagent_type=dev-auditor)
-**응답 발신 전 자기검증**: C11·C14·C23 준수 확인. 실측 근거로만 판정, 추정 사항은 "가능성" 명시. 실종 패턴(요청 4)은 자기 귀책 인정 포함하여 C23 허위 포장 배제.
diff --git a/공유/소통/plan-auditor→PM/.gitkeep b/공유/소통/plan-auditor→PM/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md b/공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md
deleted file mode 100644
index 356adf2..0000000
--- a/공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-type: 감사
-status: 완료
-author: plan-auditor
-date: 2026-04-17
-mode: 모드 C (주제 집중)
-scope: 기획 영역 문서·산출물·전문 에이전트 전수 정합성 (불필요·중복·상충 3축)
-commissioner: PD님 직접 지시 → PM 이관
----
-
-# 기획 영역 전수 정합성 감사 보고 (2026-04-17)
-
-## 요지
-
-실측 기반 전수 점검 완료. **Critical 0건 / Major 2건 / Minor 3건 / Improvement 1건**. 불필요 0건. 중복은 전문 에이전트 공통 섹션 3줄 수준(허용 범위). 상충은 Phase 3 HOLD 구 산출물의 "Python/C# 시뮬·개발실·기획실" 구용어 잔존(방향 전환 미반영). 본 보고는 사실 기록이며 집행은 PM 확인 후.
-
----
-
-## A. 점검 범위 실측
-
-| # | 대상 | 결과 |
-|---|------|------|
-| 1 | 기획팀 에이전트 7종 (`기획팀장` + 전문 6종) | 정의 존재, 기록 의무·기각안 필수·plan-auditor 모드A 환기 전 7종 반영 |
-| 2 | 수상한잡화점 기획 문서 12종 | 전수 존재, 밸런싱 md 4종 변경 이력 테이블 신설분 실측 확인 |
-| 3 | REQ 템플릿 | 142줄, 9개 섹션(기각안 포함) 완비 |
-| 4 | 어뷰징 기획서 v1 | frontmatter 완비, AV 9종·F1/F2/F3·C7 재미 근거 명시 |
-| 5 | JSON 숙지 보고서 | `공유/소통/기획팀→PM/` 위치 확인 (완료 이동 전) |
-| 6 | 2026-04-17 대화로그 | 기획 엔트리 12건 중 기각안 필드 10건 채움·2건 "없음 (사유)" 명시 |
-| 7 | P17 배타 조합 7종 | `맵패턴_사전분석_v1` §3·`3성조건_12개_상세명세_v1` §조건별·`빌드_조건_충돌점검_v1` 교차 일치 |
-| 8 | `plan-auditor→PM/` 디렉토리 | 본 보고 신설로 생성 |
-
----
-
-## B. 발견 사항
-
-### Major M1. Phase 3 재개 체크리스트 — 구용어·구방향 전면 잔존
-
-**위치**: `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` (2026-04-14 작성, 미갱신)
-**상충 내용**:
-1. "Python 시뮬 ↔ C# 시뮬 교차 검증" (L37·L72·L82·L229·L243) — #28 **Python 시뮬 폐기 확정 + Unity MCP 단일 방향** 미반영
-2. "Headless C# 시뮬" (L36·L259) — Unity MCP `execute_code` EditMode 전환 미반영
-3. "개발실·기획실" 용어 (L13·L36·L47·L49·L172·L196·L203) — 2026-04-16 "개발팀·기획팀" 명칭 전환(SKILL.md 최종 수정일) 미반영
-4. "`공유/개발실→기획실/` 폴더" (L38) — 실재 경로는 `공유/소통/개발팀→기획팀/`
-5. `개발실/프로젝트_숙지/수상한잡화점/07_시뮬레이터_이원화_해소_착수계획_v1.md` 참조 (L36) — 경로 실존 여부 미검증, 개발팀 07 `Headless 추출안`은 Unity MCP 전환으로 기각된 상태
-
-**근거**: 2026-04-17 대화로그 `[12:21] Unity MCP 시뮬레이션 방향 전환 기술검토` + `[작업완료] #37 Q-P2 정밀 2차 응답 + Unity MCP 시뮬 인프라 4종` 확인.
-**영향**: Phase 3 HOLD 해제 시 구 체크리스트 기반 착수 시 잘못된 선행 조건을 기다리거나 존재하지 않는 경로를 찾게 됨. 조직 운영 혼선.
-
-### Major M2. `3성조건_12개_상세명세_v1.md` — 개발실·Headless 잔존
-
-**위치**: 동 문서 L7·L19·L22·L90·L124·L165·L206·L245·L290·L341·L386·L428·L472·L511·L563·L595·L612·L622·L645·L647·L648·L680·L682·L687·L692·L697·L711·L731·L737~L742 (대량)
-**상충**: "개발실 구현 요청 포인트" 섹션명이 각 조건별 반복, "Headless C# 시뮬 추출" 전제, `기획실/⚠️_PHASE3_HOLD_공지.md` 등 구 경로 참조.
-**영향**: 개발팀이 본 문서 기반 구현 요청 수령 시 용어·경로 혼선. Phase 3 재개 선결 문서이므로 재개 이전 시정 필요.
-
-### Minor m1. `맵패턴_사전분석_v1.md` 구용어
-
-L83·L151·L278 "개발실 Headless C# 시뮬"·"기획실/밸런싱" 경로 참조. 본문 논리는 유효하나 용어 갱신 필요.
-
-### Minor m2. `Phase2_카드임팩트측정_v1.md` 구방향 참조
-
-L171~L173·L206 "시뮬레이터 이원화 해소(개발실 착수 예정)" — Unity MCP 전환으로 "이원화 해소" 개념 자체가 소멸. "개발실 방어 시스템 분석" 표현도 구어.
-
-### Minor m3. `빌드_조건_충돌점검_v1.md` 구경로
-
-L(참조 문서 섹션) "`기획실/⚠️_PHASE3_HOLD_공지.md`" — 실파일 경로 검증 필요.
-
-### Improvement I1. 전문 에이전트 6종 공통 섹션 — 중복 허용 범위
-
-"공통 기록 의무" 3줄(C13·P24·C29-4·plan-auditor)이 6종 agent md에 반복. 실측 확인 결과 각 영역 맞춤 문구(balance=밸런스 수치 / content=컨텐츠 / level=스테이지 등)가 삽입되어 **완전 중복 아님**. C14-4(참조 무결성) 저촉 가능성 낮음. 다만 향후 SKILL.md 단일 SOT 확장 시 통합 참조 가능. **현 상태 유지 권고**.
-
----
-
-## C. 불필요 (폐기 대상) 점검 결과
-
-**0건**. 완료 아카이브(`공유/소통/완료/`)·대화로그 엔트리·전문 에이전트 6종 모두 활용 상태. REQ001~REQ003은 2026-04-14 미응답 상태이나 완료 이동 전이므로 활용 여지 유지.
-
----
-
-## D. 권고 (PM 집행용)
-
-| 우선순위 | 대상 | 조치 | 주체 |
-|---------|------|------|------|
-| 1 | Phase3_재개준비_체크리스트_v1 | Unity MCP 방향 반영 + 개발실→개발팀·기획실→기획팀 치환 + 존재하지 않는 경로 정정 | 기획팀장 재량 |
-| 2 | 3성조건_12개_상세명세_v1 | "개발실·Headless" 구용어 일괄 치환 + 참조 경로 실측 | 기획팀장 재량 |
-| 3 | 맵패턴/Phase2/빌드충돌 3종 | 구용어 일괄 치환 (1·2와 동일 라운드) | 기획팀장 재량 |
-| 4 | REQ001~003 | 개발팀 응답 요청 또는 폐기 결정 | PM 판단 |
-
-본 집행은 PM 확인 후 기획팀장 재량 라운드로 일괄 처리 권장 (라운드 완결 아카이브 원칙 적용).
-
----
-
-## E. 기각안 (본 감사 수행 시 검토했으나 미채택)
-
-1. **구용어 즉시 치환 지시** — 본 감사관은 "보고만" 지시받음. 집행은 PM 경유가 C29 정합.
-2. **P17 배타 조합 실제 스테이지 배치 전수 검증** — Phase 3 HOLD 중 실배치 금지(맵패턴_사전분석 §범위외). 본 감사 범위 초과.
-3. **전문 에이전트 6종 공통 섹션 SKILL.md 통합 제안** — 현 중복 미미, 영역 맞춤 문구 희생 대비 이득 불분명. 차기 감사 안건화 여지만 기록.
-
----
-
-## F. C31 자기검증 통과 확인
-
-- A(C29): 본 보고는 사실 기록·권고 형태, PD님 결정 요청 없음.
-- B(C27~C30): 본 감사는 md 읽기만 수행, git 점검 대상 변경 없음.
-- C(정직성): 라인 번호·파일 경로 실측 기반, 미확인 항목은 "미검증" 태그.
-- D(맥락): 대화로그 2026-04-17 전수·PD 지시 로그 활성분 확인 반영.
-- E(기존 자산 우선): plan-auditor 정의서 준거, P25 Live·P27 3축 감사 체계 정합.
-
----
-
-## G. 커밋 prefix
-`audit(plan):` — 본 보고 발행.
diff --git a/공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md b/공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md
deleted file mode 100644
index 7441c80..0000000
--- a/공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md
+++ /dev/null
@@ -1,253 +0,0 @@
----
-type: 감사보고서
-from: plan-auditor
-to: PM
-date: 2026-04-18
-mode: C (주제 집중 감사)
-subject: 새 PC 동기화 최종 점검 — 기획 영역
-related_pd_directive: 기획팀 #3 (Phase 3 HOLD) / 2026-04-18 전 에이전트 동원 동기화 점검 + 세션 교훈 조직 자산화
----
-
-# 감사 보고서 — 새 PC 동기화 최종 점검 (기획 영역)
-
-## 0. 감사 개요
-
-### 배경
-2026-04-18 본 세션 9 커밋(`added9d`~`15bf649`)으로 헌법급 변경 6건 집행. 특히 M1·M2·m1·m2·m3 최신화로 기획 5문서(Phase3 체크리스트·3성조건 12개·맵패턴·Phase2·빌드충돌) 전수 동기화. 새 PC에서 기획팀장이 Phase 3 재개 지시 수령 시 **혼선 없이 즉시 착수 가능한 상태**인지 최종 점검.
-
-### 감사 범위
-- **대상**: 기획 5문서 + 방향전환 아카이브 + P17 배타 조합 규칙 + 새 PC 세션 재개 시뮬레이션
-- **기준**: 구용어 0건 / 말미 링크 실존 / N7 방어 실측 반영 / Unity MCP 경로 전수 / 차기 프로젝트 독립성
-- **방법**: Grep 전수 스캔 + Read 주요 섹션 + git log 교차 대조
-
----
-
-## 1. 요청별 감사 결과
-
-### 요청 1. 기획 5문서 전수 최신화 감사
-
-#### 1-A. Phase3_재개준비_체크리스트_v1.md (344라인)
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| 구용어 0건 (개발실/기획실/Headless C#/Python 시뮬) | **통과** | Grep count 0 |
-| §10 말미 링크 정합 | **통과** | L339 배너 제거 후 말미 이관 완료 확인 (`../../../공유/조직공지/방향전환_히스토리_아카이브.md#1-프로젝트수상한잡화점기획phase3_재개준비_체크리스트_v1md-방향-전환`) |
-| Day 1~15 로드맵 Unity MCP 경로 전수 반영 | **통과** | Unity MCP 22회 참조 / `Assets/Sim/BurningTimes.Sim.asmdef` 명시 (L36) / §8-3 업데이트 트리거에 `시뮬레이터/01~04` 경로 명시 (L309) |
-| §1-1 재개 트리거 체크리스트 4종 | **통과** | L34~39 테이블 4종 모두 Unity MCP EditMode 경로 반영 (`Assets/Sim/BurningTimes.Sim.asmdef` 실존 / 실측 검증 리포트 / 기획팀용 가이드 / PD님 재개 지시) |
-
-**판정**: 현행 유지 가능. 새 PC 세션에서 기획팀장이 본 문서 단독 Read로 재개 준비 상태 완전 파악 가능.
-
-#### 1-B. 3성조건_12개_상세명세_v1.md (748라인)
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| 구용어 0건 | **통과** | Grep count 0 |
-| 12개 조건별 "개발팀 구현 요청 포인트" 섹션 일관성 | **통과** | 12회 반복 + 2-B 목적 선언(L22)에서 "Unity MCP EditMode 독립 어셈블리(`Assets/Sim/BurningTimes.Sim.asmdef`)에서 구현" 명시 |
-| §5-4 Unity MCP 실측 검증 방법론 정합 | **통과** | L645~651 3항목(동일 입력 판정 일치·측정 변수 일치·엣지 케이스 일치) 명시, Unity MCP EditMode 환경 기반 |
-| P17 서브번호 체계 (P17-2·P17-5·P17-6 등) | **통과** | SKILL.md 배타 조합 7종 순서와 정합 (L251·L300·L479) |
-| §10 말미 링크 | **통과** | L743 (배너 제거 후 말미 이관) |
-
-**Major 발견 1**: N7 방어 성공 상태 문서 간 불일치
-- Phase2_카드임팩트측정_v1.md L206: "N7 방어 성공: **실측 완료** (2026-04-17 #37 Q-P2) — PCDefence_Mul=0.3, 쿨다운 없음, 지속형..."
-- 3성조건_12개_상세명세_v1.md L14·L69·L698·L710: "+N7 **보류**" / "N7 **방어 성공**... 추가될 **가능성**" (보류 상태 문구 잔존)
-
-두 문서 모두 방향전환 아카이브 §4-B(Phase2)는 최신 상태 반영했으나, 3성조건 문서는 "N7 추가 결정 시 v2"로 유보 표현 유지. 새 PC 기획팀장이 세션 시작 시 **"N7이 보류인가 실측 완료인가"** 혼선 가능.
-
-**권고**: 3성조건 §0·§2·§5의 N7 서술을 Phase2 L206 수준으로 최신화 ("실측 완료, 13번째 추가 여부는 Phase 3 재개 시 PD님 결정"). 또는 Phase2 "실측 완료" 서술에 "조건 풀 추가 여부는 3성조건 §4 확장 시 v2" 교차 참조 1줄 추가. 판단은 기획팀장 재량(Minor 이슈이므로 Phase 3 재개 시 일괄 최신화 가능).
-
-#### 1-C. 맵패턴_사전분석_v1.md (288라인)
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| 구용어 0건 | **통과** | Grep count 0 |
-| §6 말미 링크 | **통과** | L283 (배너 제거 후 말미 이관) |
-| Unity MCP 경로 반영 | **통과** | Unity MCP 11회 참조 |
-
-**판정**: 현행 유지 가능.
-
-#### 1-D. Phase2_카드임팩트측정_v1.md (248라인)
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| 구용어 0건 | **통과** | Grep count 0 |
-| §7 신설 말미 링크 | **통과** | L248 |
-| N7 실측 완료 반영 (L206) | **통과** | PCDefence_Mul=0.3·쿨다운 없음·지속형·방어 중 공격 불가·Melee/Range 공통·Mob 방어 부재 전수 반영 |
-| §4-A 선행 의존성 체계 Unity MCP 전환 | **통과** | 방향전환 아카이브 §4-A 기록과 본문 정합 |
-
-**판정**: 현행 유지 가능. N7 실측 수치 5종 전부 차기 프로젝트 참고 자료 가치 보유.
-
-#### 1-E. 빌드_조건_충돌점검_v1.md (386라인)
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| 구용어 0건 | **통과** | Grep count 0 |
-| §9 말미 링크 | **통과** | L370 |
-| Unity MCP 시뮬 기반 검증 반영 | **통과** | Unity MCP 3회 참조 (§6-1 "Unity MCP 시뮬 기반 검증" 섹션 전환 확인) |
-| 변경 이력 테이블 표준 포맷 (P16) | **통과** | 말미 변경 이력 테이블 존재 |
-
-**판정**: 현행 유지 가능.
-
-### 요청 2. 방향전환 아카이브 5섹션 완결성 감사
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| §1~§5 5섹션 전수 존재 | **통과** | L54·L94·L123·L157·L186 |
-| 각 섹션 6필드 (대상·일자·유형·당시 가정·현 방향·근거) 준수 | **통과** | 모든 서브섹션(1-A·1-B·1-C·1-D·1-E·2-A·2-B·2-C·3-A~D·4-A~B·5-A~D) "당시 가정" + "현 방향" + "전환 사유" 3종 최소 구조 유지 |
-| 2026-04-17·04-16 원류 소급 기록 | **통과** | L221 "2026-04-17 소급 기록", L234 "2026-04-16 소급 기록" |
-| 차기 프로젝트 참고 자료 독립성 | **통과** | 각 섹션이 맥락(PD 지시·커밋 해시·전환 사유) 자체 포함 — 세션 맥락 없이도 이해 가능 |
-| 역진화 방지 규정 | **통과** | L257~259 "본 파일 삭제·이동·축약은 PD님 직접 승인 필수 / git 영구 추적 대상" |
-
-**판정**: 완결성 100%. 차기 프로젝트 시작 시 "수상한잡화점은 왜 Unity MCP로 전환됐나" 질문에 본 아카이브 1회 Read로 완전 답변 가능.
-
-### 요청 3. P17 배타 조합 규칙 전수 교차 검증
-
-| 점검 항목 | 결과 | 근거 |
-|---------|------|------|
-| SKILL.md P17 본문 배타 조합 7종 | **통과** | SKILL.md 자동 주입 확인 (C2∧N2·C6∧물약·C6∧N4·입문1~6 C1∧C3·C9∧단독보스·입문1~6 N3·N5∧N6) |
-| 기획 문서 P17-X 서브번호 일관성 | **통과** | 3성조건·맵패턴·빌드충돌 3문서에서 P17-2·P17-5·P17-6 동일 체계 사용 (총 9회) |
-| 조건 식별자(C2·N2·C6·N4·C1·C9·N3·N5·N6) 일관성 | **통과** | 3성조건 12개 섹션 + 빌드충돌 5-1·5-2·5-3 섹션 + 맵패턴 §3 간 동일 식별자 체계 |
-| 스테이지 적용 범위("입문 1~6") 일관성 | **통과** | 3성조건 L135·L214·L479·L482 동일 표기 |
-| Stage 7·10·13 단독 보스 P17-5 배치 | **통과** | 3성조건 L300 |
-
-**판정**: 3문서 + SKILL.md 단일 SOT 체계 정합. 새 조건 추가 시 P17 배타 조합에도 반영해야 하는 기획 팀장 의무 명시 체계 유지.
-
-### 요청 4. 기획 영역 새 PC 세션 재개 시뮬레이션
-
-#### 시나리오: 새 PC clone 후 `기획팀장` Agent 호출 → Phase 3 재개 지시
-
-**Step 1**: 기획팀장이 SessionStart hook으로 SKILL.md 자동 주입 + 최근 변경 요지 수신  
-→ `15bf649 refactor(rules): 원칙 1 재재개정 + M1·M2 배너 이관` 등 최근 헌법급 변경 6건 즉시 인지 가능  
-**통과**
-
-**Step 2**: Phase 3 재개 지시 수령 → 첫 참조 문서 `Phase3_재개준비_체크리스트_v1.md` Read  
-→ §1-1 재개 트리거 체크리스트 4종 + §1-3 선행 의존성 체계 즉시 확인 가능 (Unity MCP 전수 반영)  
-→ §10 말미에서 방향전환 아카이브 §1 링크로 "왜 이렇게 됐나" 추적 가능  
-**통과**
-
-**Step 3**: Day 1 작업 착수 → `3성조건_12개_상세명세_v1.md` §2 조건 풀 12개 Read  
-→ 12개 조건별 개발팀 구현 요청 포인트 + Unity MCP EditMode 환경 즉시 이해  
-→ **N7 상태 문구 혼선 가능성** (Major 발견 1) — 기획팀장 자체 판단으로 해소 가능하나 구조적 개선 권고  
-
-**Step 4**: `Assets/Sim/BurningTimes.Sim.asmdef` 실존 확인 → 개발팀 실측 검증 리포트 확인  
-→ 참조 SOT `프로젝트/수상한잡화점/시뮬레이터/01~04` 5문서 전수 존재 (Phase3 §8-3 L309)  
-**통과**
-
-**Step 5**: 맵 패턴 적용 → `맵패턴_사전분석_v1.md` §3 P17 배타 배치 + 빌드충돌 §6-1 Unity MCP 검증  
-→ 3문서 간 P17 서브번호 체계 정합 확인됨  
-**통과**
-
-**시뮬레이션 판정**: Major 발견 1(N7 상태 혼선)을 제외하고 새 PC 세션 재개 시 혼선 없이 즉시 착수 가능. Major 발견 1은 Phase 3 재개 시점에 기획팀장이 PD님 결정을 구하는 과정에서 자연 해소 가능하므로 Phase 3 재개 블로킹 요인 아님.
-
-### 요청 5. 기획 세션 맥락 복원 가능성
-
-| 복원 대상 | 복원 가능 여부 | 경로 |
-|---------|-------------|------|
-| 5문서 전수 Read로 재개 준비도 파악 | **가능** | Phase3 체크리스트 §1~§10 전수 |
-| "왜 Unity MCP로 전환됐나" 맥락 복원 | **가능** | 방향전환 아카이브 §1-C·§1-D·§2-B·§3-B·§4-A·§5-A + §2026-04-17 원류 소급 |
-| N7 방어 실측 완료 상태 인지 | **부분 가능** | Phase2 L206 완전 반영 / 3성조건 보류 문구 잔존 (Major 1) |
-| N7 실측 수치 5종 (PCDefence_Mul=0.3 등) | **가능** | Phase2 L206 + 방향전환 아카이브 §2026-04-17 원류 |
-
-**판정**: Major 발견 1 외 복원 가능성 완전 확보.
-
-### 요청 6. 기각안 (P24 필수)
-
-P24 기각안 필수 필드는 본 감사 보고서가 **결정·설계 엔트리가 아닌 감사 보고서**이므로 선택이나, 감사관 준수 모범 차원에서 명시:
-
-1. **현행 유지 (Phase3·3성조건·맵패턴·Phase2·빌드충돌 감사 없이 통과 선언)** — 2026-04-18 9 커밋 대량 변경 후 교차 검증 의무 발생. 감사 생략 시 Critical 누락 위험, 기각
-2. **전수 Read 대신 구용어 Grep만 수행** — 말미 링크·P17 교차·N7 실측 반영은 본문 구조 읽어야 확인 가능, 기각
-3. **Major 발견 1(N7 상태 불일치)을 Critical로 격상** — 새 PC 재개 블로킹 요인 아니고 Phase 3 재개 시점 PD님 결정으로 자연 해소 가능, Major 유지
-4. **5문서 외 2문서(밸런싱문서_일관성점검·재논의대기_사전자료모음) 구용어 35건도 본 감사 범위 포함** — PM 요청 범위 5문서 한정, 감사 범위 외 기록만 남기고 별도 안건 상정 (Improvement 1)
-
----
-
-## 2. 종합 판정
-
-### 판정표 요약
-
-| 영역 | Critical | Major | Minor | Improvement |
-|------|---------|-------|-------|-------------|
-| 요청 1 (5문서 최신화) | 0 | 1 (N7 상태) | 0 | 0 |
-| 요청 2 (아카이브 완결성) | 0 | 0 | 0 | 0 |
-| 요청 3 (P17 교차 검증) | 0 | 0 | 0 | 0 |
-| 요청 4 (재개 시뮬) | 0 | 1 (앵커 결함 — 기획팀장 실측 재확인) | 0 | 0 |
-| 요청 5 (맥락 복원) | 0 | 0 (요청 1·4 연계) | 0 | 0 |
-| 기타 | 0 | 0 | 0 | 1 (범위 외 구용어) |
-
-**총 Critical 0 / Major 2 / Minor 0 / Improvement 1**
-
-### Major 2 교차 발견 메모 (기획팀장 실무 점검과 통합)
-기획팀장이 `공유/대화로그/수상한잡화점/2026-04-18.md` 먼저 엔트리에서 **앵커 결함** 자체 발견 보고 — 5문서 말미 링크 `#1-프로젝트수상한잡화점기획phase3_재개준비_체크리스트_v1md-방향-전환` 형식이 실제 아카이브 구조 `#### 1. 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md 방향 전환`의 slugify 결과와 Markdown viewer별 불일치 가능. 본 감사관도 아카이브 섹션 구조(L54·L94·L123·L157·L186) 대조로 재확인. Phase 3 재개 블로킹은 아니나 차기 프로젝트 참고 자료 접근성 직접 영향이므로 Major 분류.
-
-### Phase 3 재개 준비 판정
-
-**Phase 3 재개 블로킹 요인 0건**. 새 PC 세션에서 기획팀장이 Phase 3 재개 지시 수령 시 혼선 없이 Day 1 체크리스트 착수 가능 상태.
-
----
-
-## 3. 주요 발견
-
-### Major 1. N7 방어 성공 상태 문서 간 불일치
-
-- **Phase2_카드임팩트측정_v1.md L206**: "실측 완료 (2026-04-17 #37 Q-P2)"
-- **3성조건_12개_상세명세_v1.md L14·L69·L698·L710**: "N7 보류" / "추후 13번째로 추가될 가능성"
-
-새 PC 기획팀장이 두 문서를 순서 무관하게 Read할 때 "N7이 현재 보류인가 실측 완료인가"에 대해 단일 정답을 즉시 확정 못함. 
-
-**권고 2안**:
-- **권고 A (최소 변경)**: 3성조건 L14에 각주 1줄 추가 — "N7 방어 성공: 보류 상태 유지 (실측 수치는 Phase2 L206 참조 / 13번째 편입 여부는 Phase 3 재개 시 PD님 결정)"
-- **권고 B (완전 최신화)**: 3성조건 §0·§2·§5의 N7 서술을 "실측 완료, 조건 풀 13번째 편입 여부는 Phase 3 재개 시 PD님 결정" 수준으로 최신화 + 방향전환 아카이브 §2-D 신설(N7 상태 전환 기록)
-
-**판단 주체**: 기획팀장 재량 (Minor 이슈이므로 Phase 3 재개 시 일괄 최신화 가능하며 현 시점 필수 아님).
-
-### Improvement 1. 범위 외 2문서 구용어 35건
-
-감사 범위 5문서가 아닌 `밸런싱문서_일관성점검_v1.md`(17건)·`재논의대기_사전자료모음_v1.md`(18건)에 구용어 35건 잔존. 본 감사 범위 외이지만 **Phase 3 재개 시 참조 문서로 활용되므로 별도 최신화 안건 상정 권고**. 기획팀장 재량 또는 차기 감사관 모드 B 호출 시점에 집행.
-
----
-
-## 4. 권고 액션 (기획팀장·PM 앞)
-
-### 즉시 (Phase 3 재개 블로킹 해소 관점)
-- 없음 (Phase 3 재개 블로킹 요인 0건)
-
-### Phase 3 재개 착수 전 (선택)
-1. **Major 1 해소 (권고 A 또는 B)** — 기획팀장 재량 선택
-2. **Major 2 해소 (앵커 2안 중 선택)** — PM 재량 판단:
-   - **권고 C1 (개별 앵커 신설)** — 방향전환 아카이브에 5개 앵커(`<a name="1-프로젝트수상한잡화점..."></a>`) 명시 삽입. 원상 유지 + 확실한 이동 보장
-   - **권고 C2 (링크를 시기별 섹션으로 수정)** — 5문서 말미 링크를 `#2026-04-18--phase-3-재개-선결-체계-최신화` 형식으로 재작성. slugify 규칙 통일
-3. **Improvement 1 (범위 외 2문서 최신화)** — 기획팀장 재량 또는 다음 plan-auditor 모드 B 호출 시 집행
-
-### 세션 말미 (plan-auditor 재호출 시)
-- 본 감사 수용 여부 PM 응답 수령 후, 권고 A·B 선택 결과에 따라 추가 감사 수행
-
----
-
-## 5. 검증 도구·근거
-
-### 사용 도구
-- Grep (구용어 스캔·말미 링크 실존 확인·P17 교차)
-- Read (문서 구조 점검 5종)
-- Bash (`wc -l`·`git log`·파일 존재 확인)
-
-### 근거 데이터
-- 기획 5문서 구용어 Grep: `개발실|기획실|Headless C#|Python 시뮬` → 0건
-- 5문서 말미 링크 Grep: `방향전환_히스토리_아카이브` → 5건 전수 실존
-- Unity MCP 참조: 46회 (5문서 합계)
-- P17 서브번호: 9회 (3문서 교차 사용)
-- git log 최근 15커밋 대조 완료
-
----
-
-## 6. 본 감사관 자체 검증 (P24·C23)
-
-- [x] 본 감사 보고서의 모든 주장은 Grep·Read tool_use 결과로 입증 가능 (C23 정직성)
-- [x] Critical·Major·Minor·Improvement 분류 근거 명시 (C5)
-- [x] 기각안 필드 기재 (P24 — 감사 엔트리에 선택이나 모범 차원 기재)
-- [x] P27-1 모드 C 산출물 3종 규범 준수 (보고서 Write + 대화로그 신설·append + 본 감사는 신규 패턴 미발견으로 feedback 생략)
-- [x] PM 재량 처리 가능 권고 사항만 제시, PD님 결정 떠넘기기 0건 (C29)
-- [x] 사실 기반 발견만 기재, 추정·확대 해석 0건 (C23)
-
----
-
-*감사 완료: 2026-04-18 plan-auditor 모드 C*  
-*다음 감사: PM 요청 수령 시 또는 세션 말미 모드 B*
diff --git a/공유/소통/plan-auditor→PM/2026-04-18_원칙1_재검토_감사.md b/공유/소통/plan-auditor→PM/2026-04-18_원칙1_재검토_감사.md
deleted file mode 100644
index a23751e..0000000
--- a/공유/소통/plan-auditor→PM/2026-04-18_원칙1_재검토_감사.md
+++ /dev/null
@@ -1,254 +0,0 @@
----
-type: 감사보고서
-mode: C (주제 집중)
-audit_date: 2026-04-18
-auditor: plan-auditor
-subject: 수정 3대 원칙의 원칙 1 재검토 + C급 기획 5문서 본문 축약 가능성 + 교훈 섹션 저장 위치
-pd_instruction: 2026-04-18 PD님 직접 — "원칙 1에서 본문 전부 유지 시 낭비되는 측면 재검토. 교훈은 반드시 본문에 남기지 않아도 됨"
-triggered_by: PM 재량 위임 (plan-auditor 모드 C 호출)
-related_rules: C14, C17, C26, C30, P18, P24, 헌법 제1원칙 목표 2 원칙 B
----
-
-# 원칙 1 재검토 감사 보고 (2026-04-18)
-
-> **감사 범위**: (가) 수정 3대 원칙의 원칙 1(자산 보존 분리) "본문 유지" 조항 재검토 / (나) C급 기획 5문서 본문 축약·외부화 시나리오 / (다) SKILL.md 교훈 섹션 저장 위치
-> **감사 방법**: 각 문서 본문 실측 Read + 헌법 제1원칙 목표 2 원칙 B(차기 프로젝트 참고 자료) + C14(토큰 최소화) + C26(코어룰 단일 SOT) 교차 검증
-> **감사 결과 요지**: **원칙 1 "본문 유지"는 대부분 유지하되 SKILL.md 교훈 섹션만 외부화 권고**. C급 5문서는 본문 그대로 유지 (Phase 3 재개 즉시 실행 자산).
-
----
-
-## 1. 감사 대상 현황 실측
-
-### 1-1. C급 기획 5문서 규모
-
-| 문서 | 라인수 | 본문 성격 | 재개 시 활용도 |
-|------|-------|----------|-------------|
-| Phase3_재개준비_체크리스트_v1.md | 342 | Day 1~15+ 실행 로드맵, 선행 의존성, 담당 매핑, 리스크 체크 | 재개 **즉시** 참조 (Day별 작업표 원문) |
-| 3성조건_12개_상세명세_v1.md | 747 | 조건별 판정 로직 의사코드, 측정 변수, UI 표시, 개발실 구현 요청 초안 | 재개 **즉시** 개발 전달 자료 |
-| 맵패턴_사전분석_v1.md | 287 | C9 배치 금지·적합 스테이지 실 데이터, 42개 슬롯 검증 틀 | 재개 **즉시** 실측 자료 |
-| Phase2_카드임팩트측정_v1.md | 237 | PC6001 앵커 DPS=1.05·EHP=64·TTK=5.7s, 등급별 실측 기여도, G1 5장 -45% TTK 등 | **고정 실측 SOT** — 축약 불가 (수치 소실 위험) |
-| 빌드_조건_충돌점검_v1.md | 385 | 빌드 10축 × 조건 12개 = 120조합 충돌 매트릭스 (E/X/SS/S/—) | 재개 **즉시** 밸런스 결정 자료 |
-| **합계** | **1,998 라인** | — | — |
-
-### 1-2. SKILL.md 규모 분포
-
-| 구간 | 라인 범위 | 바이트 수 추정 | 성격 |
-|------|----------|-------------|------|
-| 활성 규칙 본문 (C1~C31, P1~P28) | L1~L1148 | 약 140KB | 매 세션 자동 주입 (고정비) |
-| 교훈 및 노하우 섹션 | L1150~L1172 (22개 항목) | **약 18KB** | 매 세션 자동 주입 (고정비) — **감사 대상** |
-| 부록 A | L1175~ 이후 | 약 10KB | 매 세션 자동 주입 (고정비) |
-| **총합** | 1,667 라인 | 약 170KB | — |
-
-### 1-3. 각 문서의 "차기 프로젝트 참고 가치" 섹션 식별
-
-| 문서 | 본문 내 차기 프로젝트 참고 가치 구간 | 현 프로젝트 전용 구간 |
-|------|---------------------------------|-------------------|
-| Phase3 체크리스트 | §1-1 선행 조건 4종, §5 산출물 명명 규칙, §6 리스크 체크리스트, §8 한계·유효 기간 | §2 Day 1~15+ 로드맵 내 "스테이지 번호·카드 등급" 전부 |
-| 3성조건 12개 명세 | §1-2 조건 설계 원칙 4대, §5-1 임계값 관리 원칙, §5-2 판정 공통 요구사항, §5-3 런타임 컨테이너 설계, §6 단위 테스트 매트릭스, §7 개발 요청서 초안 구조 | §3·§4 12개 조건 각 정의 (수상한 잡화점 조건 풀 고유) |
-| 맵패턴 사전분석 | §1-1 P17 규칙 운영 원리, §3-3 42슬롯 검증 체크리스트 **틀** | §1-2~§1-5 스테이지별 보스 실 데이터 |
-| Phase2 카드임팩트 | §1 핵심 발견 요약 "양적/질적 파워 이중 구조" 인사이트, §4 빌드별 드래프트 기대값 **방법론** | §2 PC6001 실측 수치, §3 G1 5장 -45% 실측 |
-| 빌드 × 조건 충돌 점검 | §0 용어 정의(E/X/SS/S/—), §2 매트릭스 **구조**, §3~ 결론(구조적 충돌 식별 방법론) | 10×12=120 조합 실 판정 셀 |
-
-> **관찰**: 5문서 모두 **방법론·운영 원리·체크리스트 틀**은 차기 프로젝트 참고 가치 있음. **실 데이터·수치·스테이지 번호**는 현 프로젝트 전용. **그러나 방법론과 실 데이터가 혼재되어 있어 섹션 단위 분리 곤란** — 분리 시 원본 맥락이 파괴됨.
-
----
-
-## 2. 원칙 1 "본문 유지"의 낭비 측면 진단
-
-### 2-1. 낭비 가능성이 실재하는 경우 (외부화 권고)
-
-**(A) 매 세션 자동 로드되는 문서의 교훈·역사 섹션**
-- **SKILL.md L1150~L1172 교훈 섹션** — 22개 항목, 약 18KB. 매 세션 전량 주입되나 활성 운영과 직접 결합 없음
-- 교훈 중 C13·C14·C15·P17·P18 연계 항목은 **이미 해당 활성 규칙 본문에 "신설 계기" 형태로 인라인 반영됨** → **중복 기재 = C14-4 참조 무결성 위반 소지**
-- 예시:
-  - 교훈 L1162 "Phase 3 HOLD 위반 사례" ↔ C10 본문 내 "신설 계기" 인라인
-  - 교훈 L1167~1170 "C13 위반 사례 3건" ↔ C13 본문 내 "절대 원칙" + `feedback_pm_share_principle.md`
-  - 교훈 L1154 "PM 3명 → 1명 통합" ↔ 활성 본문과 무관한 순수 역사 (외부화 최적)
-
-**(B) 매 세션 로드되지만 실무 참조 드문 역사 기록**
-- C20-7 변경 이력·C26-5 진화 이력 등 활성 본문 내부의 "진화 이력" 섹션 — 감사 우선순위는 2순위이나 차후 검토 대상
-
-### 2-2. 낭비 아님 (본문 유지 필수)
-
-**(A) C급 기획 5문서 본문** — 전량 유지 권고
-
-근거:
-1. **변동비 문서** — SKILL.md·CLAUDE.md와 달리 매 세션 자동 주입 안 됨. 업무 필요 시 Read. **고정비 영향 0**
-2. **Phase 3 재개 시 즉시 실행 자산** — 5문서 모두 "HOLD 중 PD님 재량 위임" 작업. Day 1~15+ 로드맵·조건 판정 의사코드·스테이지별 데이터·빌드-조건 매트릭스는 **재개 즉시 실무 집행될 본문**
-3. **방법론/데이터 분리 불가** — §1-1에서 §1-2·§1-3으로 매끄럽게 연결되는 구조. "틀만 남기고 데이터 삭제"하면 원본 맥락이 파괴되어 역으로 차기 프로젝트 참고 가치도 훼손
-4. **실측 수치 소실 리스크** — Phase2 카드임팩트의 "PC6001 앵커 DPS=1.05, G1 5장 -45% TTK"는 PD님 3차 승인 실측. 축약 시 근거 소실로 이슈 1·3 재논의 시 재측정 필요 (비용 대)
-
-**(B) B1·B2 아카이브 본문** — 전량 유지 권고
-
-근거:
-1. 07 Headless 원안: **배너에 "본문은 기각안 근거·당시 설계 실증으로 보존"** 명시. 차기 프로젝트 Unity 외 환경 고려 시 참고 자료 의도 부합 (헌법 목표 2-B)
-2. 02 추출대상: **배너 + 각 항목 역참조** 구조가 이미 정합. Tier 1 16/16 구현 경로가 커밋 해시·파일 경로로 역참조되므로 실측 자산
-
-### 2-3. 원칙 1의 정확한 외연 재정의 권고
-
-**현행 원칙 1 (2026-04-18 개정 후)**:
-> 자산 보존 분리 — 폐기 설계 문서: 배너 + **본문 유지** / 완료 실적 문서: 배너 + 역참조 / SKILL.md 내 폐기 규칙: 원칙 3(저장 위치 최적화)
-
-**감사 권고 재정의**:
-> 자산 보존 분리 — 폐기 설계 문서·완료 실적 문서: 배너 + **본문 유지 (변동비 원칙)**. **매 세션 자동 로드되는 활성 본문(SKILL.md·CLAUDE.md)에 포함된 교훈·역사·진화 이력 섹션은 외부 아카이브로 이관 가능**. 활성 본문에는 "교훈 요지 + 외부 경로 링크" 1줄만 유지.
-
-이 재정의는 **원칙 1과 원칙 3의 경계를 명확**하게 함:
-- 원칙 1: 변동비 문서 (업무 시 Read) 본문 유지
-- 원칙 3: 고정비 문서 (매 세션 자동 주입) 내부의 외부화 가능 섹션
-
----
-
-## 3. SKILL.md 교훈 섹션 외부화 시나리오
-
-### 3-1. 제안 경로
-
-| 시나리오 | 방식 | 토큰 절감 | 자산 보존 | 권장도 |
-|---------|------|---------|---------|------|
-| A. 현행 유지 (L1150~1172) | 매 세션 18KB 자동 주입 | 0 | ⭕ | 기각 (낭비 실재) |
-| B. SKILL.md 하단 유지 + 요약 축약 | 22개 → 핵심 5개로 축약 | 약 14KB | 일부 소실 | 기각 (자산 훼손) |
-| **C. 외부 아카이브 이관 (채택 권고)** | `공유/조직공지/교훈_아카이브.md` 신설 + SKILL.md에 1줄 안내만 유지 | **약 17KB** | ⭕ 완전 보존 | **채택 권고** |
-| D. `memory/feedback_*` 완전 흡수 | 기존 feedback 메모리에 항목별 통합 | 약 18KB | 일부 중복 | 보조안 (차후 정리) |
-
-### 3-2. 시나리오 C 구체 설계
-
-**신설 파일**: `공유/조직공지/교훈_아카이브.md`
-
-**구조**:
-```
----
-type: 교훈아카이브
-created: 2026-04-18
-maintainer: 총괄PM
-sot_boundary: 운영 교훈·노하우·재발 방지 사례의 단일 SOT
-related: SKILL.md (활성 본문 안내 1줄), memory/feedback_* (상세 실증)
-rationale: C14 + 헌법 제1원칙 목표 2 원칙 B 동시 만족
----
-
-# 교훈 및 노하우 아카이브
-
-## 🏛️ 아카이브 원칙
-- 포함 대상: 활성 규칙 본문과 직접 결합 없는 순수 교훈, 재발 방지 실증 사건, 역사 기록
-- 제외 대상: 활성 규칙 본문에 인라인된 "신설 계기" 요지 (중복 금지)
-- 읽기 규칙: 본 파일은 변동비. PM 필요 시 Read. SessionStart hook 자동 로드 대상 아님
-
-## 교훈 (시간순)
-
-[현 SKILL.md L1150~L1172 22개 항목 그대로 이관]
-```
-
-**SKILL.md 수정 (L1148~1172)**:
-```markdown
----
-
-## 교훈 및 노하우
-
-> 형식: `[날짜] 교훈 내용 — 발생 맥락`. 상세 경위는 [교훈 아카이브](공유/조직공지/교훈_아카이브.md) 참조.
-> 활성 본문에는 교훈 요지를 인라인 반영한 규칙(C10·C13·C14·C23·C29·C31 등)만 유지.
-
----
-```
-
-**토큰 절감 추정**: 약 17KB (= 18KB - 1KB 안내 블록)
-
-### 3-3. 외부화 위험 및 완화
-
-| 위험 | 완화 방법 |
-|------|---------|
-| 새 PM 세션이 교훈을 놓침 | 활성 본문 각 규칙의 "신설 계기" 인라인은 유지 — 규칙을 읽으면 교훈도 자연 읽힘 |
-| PD님이 전체 교훈 맥락 필요 시 접근성 저하 | SKILL.md L1148에 외부 링크 안내 + `공유/조직공지/` 기존 경로이므로 PD님 이미 숙지 |
-| 교훈 아카이브 자체 소실 | 폐기 규칙 아카이브와 동일 보호 규칙(PD님 직접 승인 필수) 적용 |
-| `memory/feedback_*`와 중복 | 교훈 아카이브는 **요약 연대기**, feedback_*는 **사건별 상세**. 역할 분담 명시 |
-
-### 3-4. PD님 지시 정합성 검증
-
-PD님 발언: **"교훈은 반드시 본문에 남기지 않아도 됨"**
-- ✅ "본문 외 저장 허용" = 외부 아카이브 파일 저장 명시 허용
-- ✅ 헌법 목표 2-B(차기 프로젝트 참고 자료) 정신 유지 (아카이브 보존)
-- ✅ C14(토큰 최소화) 직접 대응
-- ⚠️ 단, "**반드시** 본문에 남기지 않아도"는 "본문 제거 필수"가 아니라 "본문 유지 강제 해제"로 해석. 완전 제거가 아닌 **선별 이관** 적용 권고
-
----
-
-## 4. C급 기획 5문서 본문 축약 가능성 결론
-
-### 4-1. 축약 권고 (Critical 수준)
-**없음.** 5문서 전량 본문 유지 권고.
-
-### 4-2. 실행 권고 (후속 작업)
-**구용어 수동 정밀 치환만** 수행:
-- "기획실" → "기획팀"
-- "개발실" → "개발팀"
-- "개발실장" → "개발팀장"
-- 대상 5문서 + (B1 07 Headless 원안에서도 구용어 존재)
-
-**수정 3대 원칙 준수**:
-- 원칙 1 (자산 보존 분리): 배너 이미 부착된 문서는 배너 하위 본문 구용어도 치환 (실무 참조 시 혼란 방지)
-- 원칙 2 (sed 일괄 치환 금지): 수동 정밀 치환 엄수
-- 원칙 3 (저장 위치 최적화): 해당 없음 (본문 유지)
-
-**Major 사안이 아닌 이유**:
-1. 현재 구용어는 **실제 파일 존재(SOT 미검증)** 이슈 없이 내용 자체는 전부 정합
-2. Phase 3 HOLD 중이므로 실무 참조 빈도 낮음
-3. 재개 시점에 구용어 수정이 자연 병행 가능
-
-### 4-3. 기각안
-| 안 | 기각 사유 |
-|----|---------|
-| 5문서 "틀만 남기고 데이터 외부화" | 원본 맥락 파괴, 재개 집행 시 재구성 비용 과다 |
-| 5문서 "Phase 2·3 재개 완료 후 일괄 폐기" | Phase 3 재개 후에도 이슈 1·3 재논의·v2 확정 전까지 **장기 참조 유지**. 완료 선언 시점 판정 모호 |
-| 5문서 전량 외부 위키·Notion 이관 | 조직 정책: git SOT 원칙(C16·C26). 외부 시스템 의존 회피 |
-| 3성조건 명세 §3·§4 "조건별 정의" 만 남기고 의사코드 제거 | 개발 요청서 초안이 된 문서 — 의사코드 없으면 개발 전달 불가 |
-
----
-
-## 5. 기각안 (감사 자체의 다른 안)
-
-| 안 | 기각 사유 |
-|----|---------|
-| 1. 본 감사를 "구용어 치환만" 권고로 한정 | PD님 지시 범위 초과 — "낭비 측면 재검토"는 구조 레벨 검토 요구 |
-| 2. 원칙 1 전면 폐기 (모든 폐기 문서 외부화) | 5문서가 재개 즉시 실행 자산이라는 실무 판단 무시 — 원칙 과잉 교정 |
-| 3. SKILL.md 전체 재구조화 (교훈 + 진화 이력 + 비교표 전량 외부화) | 범위 과다 — PD님 지시는 "교훈" 명시. 비교표·진화 이력은 후속 감사 안건 |
-| 4. C급 5문서 모두 배너만 남기고 본문 이관 | Phase 3 재개 시 실행 자산 성격 간과 — 배너+링크만 남기면 재개 Day 1에 즉시 참조 불가 |
-
----
-
-## 6. 권고 요약 (PM 3축 종합 보고서 반영용)
-
-1. **SKILL.md 교훈 섹션 L1150~L1172 외부화** — 신규 파일 `공유/조직공지/교훈_아카이브.md` 생성 + 활성 본문 1줄 안내. **약 17KB 고정비 절감** + 자산 100% 보존 (PD님 지시 직접 응답)
-2. **원칙 1 외연 재정의** — "변동비 문서는 본문 유지 / 고정비 문서 내 활성 운영과 결합 없는 섹션은 외부화 가능"으로 명확화 (원칙 3과의 경계 명시)
-3. **C급 5문서 본문 유지** — Phase 3 재개 즉시 실행 자산. 구용어 수동 치환만 별도 수행 권고
-4. **B1·B2 아카이브 현행 유지** — 배너 + 본문 + 역참조 구조 이미 정합
-
-### 6-1. 영향 범위 (승인 시)
-- 수정: SKILL.md L1148~1172 (교훈 섹션 정리)
-- 신규: `공유/조직공지/교훈_아카이브.md`
-- 인계서: §1 원칙 1 외연 재정의 문구 1줄 추가 (선택)
-
-### 6-2. 미승인 유지 (PM 재량 아님)
-- 원칙 1 외연 재정의는 **PD님 승인 안건**으로 보고 후 진행 권고 (C26 단일 SOT 변경)
-
----
-
-## 7. 감사 제약 명시 (C23 정직성)
-
-- 본 감사는 **문서 실측 Read + 규칙 교차 검증** 기반. 실 집행·구용어 치환 수행 안 함 (plan-auditor 모드 C 산출물 3종 규범 — 보고만)
-- 5문서 각 §별 "차기 프로젝트 참고 가치 구간" 식별은 **문서 구조 분석 근거**이며, 실 차기 프로젝트 요구사항과의 정합성은 차기 프로젝트 시작 시점에서 별도 검증 필요
-- 교훈 섹션 외부화 시 feedback_* 메모리와의 중복 여부 상세 비교는 본 감사 범위 외 (구조 판단만 수행, 항목별 중복 매트릭스는 후속 작업 권고)
-
----
-
-## 8. 참조 문서
-
-- 헌법 제1원칙 목표 2 원칙 B (차기 프로젝트 인사이트 기록)
-- C14 (토큰 최소화 우선 설계) + C14-4 (참조 무결성)
-- C26 (코어룰 단일 SOT)
-- P24 (대화로그 — 기각안 필수 필드)
-- 2026-04-18 대화로그 (원칙 3 개정 경위)
-- `공유/조직공지/폐기_규칙_아카이브.md` (원칙 3 실증)
-- `공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md`
-
----
-
-*감사 완료: 2026-04-18*
-*감사관: plan-auditor*
-*후속: PM 3축 종합 보고서에 본 권고 반영 여부는 PM 재량*
diff --git a/공유/소통/pm-auditor→PM/.gitkeep b/공유/소통/pm-auditor→PM/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/pm-auditor→PM/2026-04-17_전수감사_문서정합성_PM영역.md b/공유/소통/pm-auditor→PM/2026-04-17_전수감사_문서정합성_PM영역.md
deleted file mode 100644
index 1156f29..0000000
--- a/공유/소통/pm-auditor→PM/2026-04-17_전수감사_문서정합성_PM영역.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-from: pm-auditor
-to: PM
-type: 감사
-subject: 전수 문서·규칙 정합성 감사 (모드 C, PM 영역)
-priority: high
-status: 완료
-created: 2026-04-17
----
-
-# 전수 감사 보고 — 문서·규칙 정합성 (PM 영역)
-
-**범위**: 루트 CLAUDE.md · SKILL.md · settings.json · PD 지시 로그 2종 · 조직운영 대화로그 · 조직공지 · memory · scripts
-**방법**: 실측 기반 (Read/Grep/ls). 발견 없는 축은 "발견 없음" 명시. 허위 보고 없음 확인.
-
----
-
-## A. 불필요 (실효·폐기 잔존) — 4건
-
-**A1. [Critical] 루트 CLAUDE.md 최상단 블록 전면 시대착오**
-- 경로: `CLAUDE.md` L33~L49
-- 근거: (가) "C1~C26" 표기 — 현재 C31까지 존재. (나) "P1~P20" — 현재 P28까지 존재. (다) C17 본문 요약 잔존("**C17** 세션 이동 복사 명령어 동봉") — 2026-04-16 폐기. (라) "**C18** 조직 공유 완료 판정 (main 병합 + **대상 세션 도달**)" — 2026-04-16 "대상 세션 도달" 개념 소멸. (마) "**C24** 부서 세션 영속 대화 운용" — 현 C24는 "단일 세션 운용 원칙"으로 재정의. (바) "**C26** 코어룰 변경 시 에이전트 정의 파일 동시 갱신 의무" — 현 C26은 "단일 SOT 갱신 원칙"(동시 갱신 폐지, Skill 자동 주입)
-- 제안: CLAUDE.md 최상단 요약 블록을 삭제하거나 SKILL.md 참조 1줄로 축약. C14-4 참조 무결성 위반이며, 특히 폐기된 C17·구 C24·구 C26을 요약으로 노출하여 세션 리더 오해 유발 위험
-
-**A2. [Major] SKILL.md 내부 폐기 P20 참조 6개소 잔존**
-- 경로: `.claude/skills/BurningTimes-코어룰/SKILL.md`
-- 근거: L294(단일 SOT 절 "+`공유/일일보고/`"), L299(공유 채널 분리 "P20"), L315·L317(구체 절차 P20 참조), L326·L386(C20-1 "일일보고" 잔존), L590(P9 모니터링 4단계 "일일 보고 확인"), L1206~L1208(부록 A3 "P20 의무" 섹션 통째로 잔존)
-- 제안: P20 본문(L743)은 폐기 표시 유지하고 위 6개소 참조를 P24로 갱신 또는 삭제. 특히 L1206~L1208 부록 A3는 "세션 종료 시 일일보고 작성" 의무 서술로 살아있어 다음 세션 리더 혼선 위험 최대
-
-**A3. [Minor] SKILL.md 다른 위치 잔존 구 표기**
-- 경로: 동 SKILL.md
-- 근거: (가) L3 frontmatter description "C1~C26 + P1~P20" — 실제 C31/P28. (나) L165 "공통_업무_규칙.md 의 C1~C13" — 본 파일 자체가 SOT이며 `공통_업무_규칙.md`는 실존하지 않음(실측 MISSING). (다) L1191 부록 A1도 동일 참조. (라) L205 "공통_업무_규칙.md"도 참조 잔존. (마) L1363 "P1~P20"
-- 제안: description 라벨 갱신 + 공통_업무_규칙.md 참조 4개소 전부 "본 SKILL.md" 또는 직접 참조로 정정
-
-**A4. [Minor] 공유/README.md 일일보고 섹션**
-- 경로: `공유/README.md` L18·L34·L78
-- 근거: P20 폐기 완료됐으나 README 구조도·type 리스트·섹션 설명에 "일일보고" 3개소 잔존
-- 제안: 폴더 구조 다이어그램에서 제거하고 "일일보고/ (폐기, 역사 아카이브)" 1줄 주석으로 축소
-
----
-
-## B. 중복 (C14-4 위반) — 2건
-
-**B1. [Major] 부록 A (SKILL.md L1175~L1210)와 C10-1 본문 중복**
-- 경로: SKILL.md L1175~L1210 부록 A1·A2·A3
-- 근거: A1 본문이 C10-1(L162~L172) 4단계와 실질 동일 중복. A2는 P19 A2와 중복. A3는 P20 폐기 상태에서 잔존(A2 중복 참고)
-- 제안: 부록 A 통째 삭제 또는 "C10-1·P19 참조" 1줄로 축약 (신설 근거였던 "부서별 CLAUDE.md 중복 방지"는 단일 세션 구조에서 의미 상실)
-
-**B2. [Minor] C20-1 vs C20-1-A 상태 정의 중복 느낌**
-- 경로: SKILL.md L323~L366
-- 근거: C20-1(재량 범위)과 C20-1-A(공유·push 시점)가 2개의 소절로 분리되어 있으나 C20-1-A가 C20-1의 적용 조건을 사실상 덮어쓰고 있음. C20-1은 "커밋 재량" 1줄만 남고 핵심은 C20-1-A에 있어 가독성 저하
-- 제안: C20-1에 C20-1-A 요지 1줄 삽입 또는 병합 재구조화 (Improvement로도 분류 가능)
-
----
-
-## C. 상충 (규칙 간 충돌·최근 개정 미반영) — 3건
-
-**C1. [Critical] P19 "단일 SOT" 절과 P24·P27 충돌**
-- 경로: SKILL.md L294 "**단일 SOT** — `공유/PD_지시_트래킹/{부서}_PD_지시_로그.md` + `공유/일일보고/`로 일원화"
-- 근거: P20 폐기 후 P24(대화로그)가 일일보고 대체. 그러나 C13 본문의 P19 참조 절은 여전히 "일일보고로 일원화"로 단정. P27-4 SOT 경계표와 정면 충돌(P27-4는 대화로그·결정로그·소통·조직공지·memory/feedback 분리 SOT 명시)
-- 제안: L294 문구를 "PD 지시 로그(P19) + 대화로그(P24) + 소통(본 디렉토리) 목적별 분리 SOT"로 수정. P27-4 표 참조 링크
-
-**C2. [Major] 기획팀 #3 산출물 경로 무효 참조**
-- 경로: `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` L41
-- 근거: 산출물에 `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md` 참조. 실측 — 해당 파일은 조직공지 폴더에 실존함(확인됨). 단, 해당 파일이 "Phase 3 HOLD" 자체가 아니라 일반 HOLD 공지 의무화 문서이므로 #3 "Phase 3 보류" 근거 문서로 적합한가 의문. 2026-04-17 현재 Phase 3 HOLD 자체를 규정한 `🛑_*` 파일이 있는지 불명확
-- 제안: PM이 Phase 3 HOLD SOT가 현재 어느 문서인지 검증하고 #3 산출물 경로 갱신 (허위 단정 회피를 위해 "검증 필요"로만 제시)
-
-**C3. [Minor] 조직공지 폐기 영역 미표시**
-- 경로: `공유/조직공지/2026-04-15_C17_핵심규칙_신설_세션이동_복사명령어_동봉.md`, `2026-04-15_C17-3_보강_진입절차_3요소_의무.md`, `2026-04-15_안건_축2_워크트리_에이전트_자동동기화.md`, `2026-04-15_Phase3_NAS_post_receive_설치가이드.md`
-- 근거: C17 폐기(2026-04-16)·워크트리 구조 폐기(C24 단일 세션 전환) 이후에도 공지 파일 내부에 "폐기됨" 표시 없음. 특히 Phase3 NAS 가이드는 "완료" 상태로 보이나 상위 Phase 3는 현재 보류 중 — 혼선 여지
-- 제안: 공지 파일 상단에 `> ⚠️ 2026-04-16 상위 규칙 폐기로 실효` 1줄 주석 추가 (C6 원본 보존하되 실효 표시)
-
----
-
-## 발견 없음 축
-- settings.json hook 배치 — C20-1-A·P25·P27-5 체계와 정합, deny 규칙 적절 (Bash rm:* 차단 + PowerShell Remove-Item 대체 경로 제공)
-- scripts/ 디렉토리 — 폐기 스크립트 잔존 없음 (nas_post_receive.sh는 Phase 3 보류 중이나 외부 가동 자산이므로 보존 타당)
-- memory/feedback_* 18종 — 중복·모순 패턴 발견 없음
-- dev-auditor·plan-auditor·기획팀·개발팀 영역 — **본 감사 범위 외** (해당 감사관·감사 보고에서 별도 다뤄야 함, pm-auditor 월권 회피)
-
----
-
-## 우선순위 요약
-- **Critical 2건**: A1 (루트 CLAUDE.md 최상단 구 C17/C18/C24/C26 요약), C1 (P19 "일일보고 일원화" P24·P27 충돌)
-- **Major 2건**: A2 (SKILL.md P20 참조 6개소), B1 (부록 A 중복), C2 (기획 #3 산출물 검증 필요)
-- **Minor 3건**: A3 (frontmatter·공통_업무_규칙.md 4개소), A4 (공유/README 3개소), C3 (폐기 공지 미표시)
-- **Improvement 1건**: B2 (C20-1/C20-1-A 병합 검토)
-
-## PM 집행 권고
-- Critical 2건 즉시 Edit 집행 권고. C14-4 참조 무결성·세션 리더 맥락 복원 직접 영향
-- Major 3건 일괄 처리 1커밋 권고 (C20-1 팀장 재량 범위 내 md 수정, C28 무승인 적용)
-- Minor·Improvement는 PD님 확인 후 일괄 적용
-
----
-
-**허위 보고 없음 선언**: 본 보고 모든 항목은 실측 Read/Grep 결과 기반. 의심만 있는 C2는 "검증 필요" 태그 부착. 발견 없는 축(settings.json·scripts·memory) 은폐 아닌 정합 확인 결과.
diff --git a/공유/소통/pm-auditor→PM/2026-04-18_새PC동기화_최종점검_메타감사.md b/공유/소통/pm-auditor→PM/2026-04-18_새PC동기화_최종점검_메타감사.md
deleted file mode 100644
index 6141da1..0000000
--- a/공유/소통/pm-auditor→PM/2026-04-18_새PC동기화_최종점검_메타감사.md
+++ /dev/null
@@ -1,296 +0,0 @@
----
-from: pm-auditor
-to: PM
-type: 감사
-mode: C (주제 집중 — 새 PC 동기화 최종 점검 + Phase 2 입력 자료)
-subject: 새 PC 동기화 정합성 전수 + PM 과도 보수 해석 최종 판정 + 세션 교훈 추출
-priority: critical
-status: 완료
-created: 2026-04-18
-references:
-  - 공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
-  - 공유/조직공지/폐기_규칙_아카이브.md
-  - 공유/조직공지/방향전환_히스토리_아카이브.md
-  - .claude/skills/BurningTimes-코어룰/SKILL.md (C14-5·C31-E 신설)
-  - memory/org/MEMORY.md (22종 인덱스)
-  - memory/org/feedback_pm_over_conservative_interpretation.md (2회 재발 기록)
-  - 공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md (선행 감사)
----
-
-# 새 PC 동기화 최종 점검 메타 감사 (PM 영역) — Phase 1 종결
-
-**감사 관점**: PD님 지시 Phase 1(새 PC 동기화 최종 점검) 완수 + Phase 2(조직 자산화) 입력 자료 사전 식별.
-**허위 보고 없음 선언**: 모든 판정은 실측 Bash/Grep/Read 결과 기반. 추정은 "추정" 태그 부착.
-
----
-
-## 결론 요약 (5줄)
-
-1. **새 PC 동기화 정합성 — A급 통과 / B급 Major 2건 발견** — 코어룰 파이프라인·아카이브 SOT 2종·인덱스·에이전트 규범·PD 지시 로그 전수 정상. **단 SKILL.md 본문 6개소에 `memory/feedback_*` (org/ 누락) 잔존 + 참조 feedback 파일 2종 부재** (Major).
-2. **원칙 1 재진화 3회 본 세션 발생 = PM 과도 보수 해석 3회차 재발** — feedback 메모리가 규정한 "3회차 재발 시 PM 역할 재검토" 기준선에 도달. PD님 매회 직접 축약 방향으로 바로잡음 (Critical).
-3. **세션 교훈 5종 추출 완료** — 원칙 진화 패턴·3축 감사관 운영·아카이브 SOT 2종·새 PC 4결함·본문 최신 + 말미 참조 재사용성.
-4. **Phase 2 조직 자산화 입력 자료 4종 사전 식별** — C31-E 자산 가치 vs 저장 위치 구분 강화, 원칙 선언의 언어적 경직성 해소 구조, 단일 세션 내 3회 재개정 패턴 조기 감지 신호, 3축 감사관 모드 C 교차 활용 노하우.
-5. **PM 세션 계속 가능 — 단 4-3·4-4 조치 선행 필수** — SKILL.md 잔존 `memory/feedback_*` 잔존분 일괄 교정 + 유령 참조 2종 제거·대체.
-
----
-
-## 1. 요청 1. 새 PC 동기화 정합성 전수 감사
-
-### 1-A. 코어룰 자동 주입 파이프라인 (A급 통과)
-
-| 점검 항목 | 실측 결과 | 판정 |
-|----------|----------|------|
-| CLAUDE.md L7 `@.claude/skills/BurningTimes-코어룰/SKILL.md` | 정상 | ✅ |
-| SKILL.md 파일 존재·크기 | 117,380 bytes, 최신 수정 09:38 | ✅ |
-| frontmatter `description` | "C1~C31·P1~P28, 폐기 규칙 상세는 ..." 최신 | ✅ |
-| C14-5 신설 조항 (L245 기준) | 본문 실재 — "본문 최신 + 히스토리 아카이브 원칙" | ✅ |
-| C31-E "자산 가치 보존 ≠ 저장 위치 보존" (L1660) | 본문 실재 | ✅ |
-
-**결론**: 새 PC clone 직후 `@import` 메커니즘이 정상 작동하여 메인 세션에 코어룰 자동 주입됨. A급 통과.
-
-### 1-B. 인계서·아카이브 SOT 2종·인덱스 (A급 통과)
-
-| 점검 항목 | 실측 결과 | 판정 |
-|----------|----------|------|
-| `공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md` | 존재, §1 원칙 1 재개정(2026-04-18) 반영 | ✅ |
-| `공유/조직공지/폐기_규칙_아카이브.md` | 존재, frontmatter + 6필드 형식 + 운영 규칙 완비 | ✅ |
-| `공유/조직공지/방향전환_히스토리_아카이브.md` | 존재, 2026-04-18·04-17·04-16 3개 섹션 + M1·M2·m1·m2·m3 5개 파일 기록 | ✅ |
-| `memory/org/MEMORY.md` 인덱스 | 22건 등재, 신규 3종(`feedback_team_recording_quality`·`feedback_pm_over_conservative_interpretation`·`feedback_dev_auditor_output_gap`) 포함 | ✅ |
-
-**결론**: 새 PC에서 세션 시작 직후 PM이 `MEMORY.md` 자동 로드로 신규 3종 feedback 즉시 인지 가능. A급 통과.
-
-### 1-C. 3축 감사관 정의 규범 통일 (A급 통과)
-
-| 감사관 | `memory/org/feedback_*` 경로 사용 | 판정 |
-|--------|----------------------------------|------|
-| dev-auditor | 2개소 모두 `memory/org/feedback_dev_*.md` | ✅ |
-| plan-auditor | 2개소 모두 `memory/org/feedback_plan_*.md` | ✅ |
-| pm-auditor | 2개소 모두 `memory/org/feedback_*.md` + 루트 저장 금지 경고 | ✅ |
-
-**결론**: 9c99cc6 커밋으로 3 감사관 정의 규범 일관 통일 완료. A급 통과.
-
-### 1-D. PD 지시 로그 활성 테이블 실존 (A급 통과)
-
-- `scripts/verify_log_paths.sh` 실행 결과: **"4건 전수 실존 확인"** 통과
-- 활성 지시 실측:
-  - 개발팀 #2 (서버 Critical 보류) / #38 (Phase 3 로드맵 보류)
-  - 기획팀 #3 (Phase 3 업무 보류)
-  - **활성 총 3건 모두 "보류" 상태**, 진행중 0건
-
-**결론**: 새 PC PM 세션이 P28 표준 포맷으로 즉시 보고 가능. A급 통과.
-
-### 1-E. 당일 대화로그 존재 확인
-
-| 프로젝트 | 2026-04-18 엔트리 | 기록 내용 |
-|---------|-------------------|----------|
-| `조직운영/2026-04-18.md` | 존재 (풍부) | 당일 9 커밋 전수 엔트리 — 원칙 1 3회 진화·DEC-2 M1·M2·m1·m2·m3 집행·새 PC 4결함 보완 등 |
-| `수상한잡화점/2026-04-18.md` | **부재** | 당일 기획 문서 5건(3성조건·Phase2·Phase3·맵패턴·빌드_조건_충돌점검) 수정 발생 |
-| `코어프레임워크/2026-04-18.md` | 부재 | 당일 수정 없음 (문제 없음) |
-
-**판정**: 수상한잡화점 기획 문서 수정은 **"조직 운영 범주 작업"(M1·M2·m1·m2·m3 구용어 정리)**이므로 조직운영 대화로그에 통합 기록된 것은 P24 위반이 아닌 **자연스러운 프로젝트 귀속 판단**. 수상한잡화점 프로젝트 자체의 새 결정·설계는 0건. Minor 개선 권고: 차기 동일 유형 기록 시 **"프로젝트 파일 수정 포함 경우 프로젝트별 엔트리에도 1줄 교차 링크"** 구조 검토.
-
-### 1-F. 🔴 Major 발견 — SKILL.md 본문 `memory/feedback_*` 잔존 + 유령 참조
-
-**실측 6개소 잔존**:
-
-| 위치 | 잔존 표기 | 실제 파일 존재? |
-|------|----------|-----------------|
-| L1054 (P27-4 채널 표) | `memory/feedback_*` | 일반 참조 — org/로 교정 필요 |
-| L1082 (P27-7 연관) | `memory/feedback_team_recording_quality.md` | ✅ 실존 (`memory/org/feedback_team_recording_quality.md`) — 경로만 오표기 |
-| L1121 (P26-3 산출물) | `memory/feedback_*.md` | 일반 참조 — org/로 교정 필요 |
-| L1138 (P26-6) | `memory/feedback_pm_context_restoration_failure.md` | **❌ 파일 부재** (유령 참조) |
-| L1604·L1617 (P28-4·P28-6) | `memory/feedback_log_round_completion.md` | **❌ 파일 부재** (유령 참조) |
-| L1678 (C31-4) | `memory/feedback_pm_context_restoration_failure.md` | **❌ 파일 부재** (유령 참조) |
-
-**근본 원인**: 9c99cc6(새 PC 동기화 4결함 보완) 커밋이 에이전트 정의·MEMORY.md는 통일했으나 **SKILL.md 본문 8개소 중 6개소 누락**. 본 감사로 처음 적발.
-
-**심층 문제**: 6개소 중 **3개소(L1138·L1604·L1617·L1678)는 참조 파일 자체가 부재** — P18(설계 문서화 의무) 유령 문서 패턴.
-- `feedback_pm_context_restoration_failure`: 신설 근거로 2회 언급되나 실제 파일은 부재. 실질 노하우는 `feedback_pm_over_conservative_interpretation.md`·`feedback_team_recording_quality.md`에 흡수된 상태로 추정.
-- `feedback_log_round_completion`: P28-4·P28-6 신설 근거로 명시되나 실제 파일 부재. 실질 노하우는 현 활성 P28 본문에 내재.
-
-**판정**: **Major** — 새 PC에서 PM이 SKILL.md를 매 세션 자동 주입받을 때 **실재하지 않는 메모리 파일로 유도되어 혼선 위험**. C5(정직성)·P18(유령 문서 금지) 위반 잠재.
-
----
-
-## 2. 요청 2. PM 과도 보수 해석 3회차 판정
-
-### 2-A. 본 세션 원칙 1 진화 실측
-
-| 회차 | 커밋 | 요지 | PD님 개입 |
-|------|------|------|----------|
-| 1차 | `1ceec2b` | 원칙 1 외연 명확화 — "변동비 본문 유지 + 고정비 외부화" | PD님 직접 지시 |
-| 2차 | `bc9c8ed` | 재개정 — "본문 최신 + 히스토리 아카이브 (상단 배너)" | PD님 직접 확장 지시 |
-| 3차 | `15bf649` | 재재개정 — "상단 배너 폐지 → 말미 참조 1줄 링크" | PD님 추가 지시 |
-
-**3회 모두 PD님 직접 개입 필요** — PM이 자발 도달하지 못함.
-
-### 2-B. feedback 메모리 기준선 대비
-
-`memory/org/feedback_pm_over_conservative_interpretation.md` 명시:
-> "재발 횟수 (2026-04-18 시점): 2회 연속 — 원칙 3 원안·원칙 1 현안"
-> "3회차 재발 시 PM 역할 재검토 자동 상정" (C19-5·C23-3 결합)
-
-본 세션에서 추가 1회(원칙 1 3차 재재개정, 배너 방식 → 말미 참조) 발생.
-
-### 2-C. 3회차 해당 여부 판정
-
-**판정: 3회차 재발 해당** — 다음 근거:
-1. feedback 파일이 명시한 패턴("자산 보존"을 "원 위치 보존"으로 오독)이 본 세션 원칙 1 2차 안(상단 배너 방식)에서 재현됨 — "본문에 배너 형태로 보존 = 저장 위치 보존" 해석
-2. PD님이 3차 지시로 "최종 내용만 반영, 변경 이력은 간략하게 아카이브 참고 형태로" 축약 방향 제시
-3. 본 세션에서 3회 연속 같은 패턴 (외연 명확화 → 배너 방식 → 말미 참조)로 점진적으로만 축약 도달 — **PM 자발적 축약 가속 없음**
-
-**C19-5·C23-3 연계**: 본 판정은 즉시 "PM 역할 재검토"를 발동하지 않음. 다만 **Phase 2(조직 자산화) 착수 시 C31-E 체크리스트 강화·역할 재검토 근거 기록은 필수**. 실제 역할 재검토 여부는 PD님 판단 영역.
-
-### 2-D. PM의 변론 여지 (공정성 보장)
-
-- 본 세션 PM은 3회 모두 PD님 지시를 **즉시 집행**하고 대화로그에 **기각안 포함 엔트리 완비**로 기록
-- 원칙 1 진화가 **PD님 직접 확장**의 연속이었지 PM의 방향 오독으로 인한 반복 오류는 아님
-- 축약 정도만 조기 도달하지 못했고 결과적으로 최종형 달성
-
-**pm-auditor 견해**: 본 세션은 "3회차 재발 기준선 접근"으로 표기하되, 즉시 역할 재검토는 부적합. **Phase 2 조직 자산화에서 다음 2건 신설 권고**:
-1. C31-E 문항에 "축약 한 단계 더 가능한가?" 자문 추가 (점진 축약 기본화)
-2. "본 세션 내 동일 원칙 2회 이상 재개정 시 자동 자진 고지 + PM 메타 검토" 규칙 검토
-
----
-
-## 3. 요청 3. 세션 교훈 5종 사전 추출 (Phase 2 입력 자료)
-
-### 3-A. 원칙 진화 3회가 드러낸 PM 약점 패턴
-
-**패턴**: PM은 PD님 지시를 받으면 **"현 상태에서 한 단계만 이동"**하는 최소 이동 해석 경향. 그 결과 PD님이 매 지시마다 한 단계 축약 방향을 재차 제시해야 함.
-
-**근본 원인 추정**:
-- C6·C19-2 과잉 일반화 (데이터 보호 + 보수적 해석 → 모든 변경 보수화)
-- 2026-04-15 승인 범위 확대 경험 과보정 (실행 회피 성향 고착)
-- "원칙" 단어의 선언형 해석 (예외·차별화를 "원칙 위반"으로 자동 분류)
-
-**Phase 2 권고**: C31-E에 "PD님이 본 방향으로 더 축약 가능하다고 판단할 여지 있는가?" 자문 추가.
-
-### 3-B. 3축 감사관 병렬 논의 운영 노하우
-
-본 세션 원칙 1 재검토에서 **dev·plan·pm-auditor 모드 C 동시 호출**이 성공적으로 운영됨 (`1ceec2b` 커밋).
-
-**운영 노하우**:
-1. **호출 프롬프트 3요소 (P27-2) 엄수 필수** — 2026-04-17 기획팀장 맥락 오류 재발 방지
-2. **교차 메타 검증** — pm-auditor가 dev·plan-auditor 결과를 메타 검증하여 종합 판정
-3. **산출물 3종 규범** — dev-auditor 첫 감사 시 미이행 실증(`feedback_dev_auditor_output_gap.md`) 이후 본 세션에서 3축 모두 정규 보고서 산출
-
-**Phase 2 권고**: 모드 C 동시 호출을 "복잡 결정 표준 절차"로 편입.
-
-### 3-C. 아카이브 SOT 2종 운영 체계
-
-`폐기_규칙_아카이브.md`(C·P 전담) + `방향전환_히스토리_아카이브.md`(프로젝트 문서 전담)의 **분리 운영 체계**가 조직 문서 관리의 영구 뼈대로 자리잡음.
-
-**재사용성**:
-- 차기 프로젝트 "왜 이렇게 변경됐나" 참고 자료 (헌법 제1원칙 목표 2-B)
-- 6필드 형식(대상·일자·유형·당시 가정·현 방향·근거)이 P24 기각안 필드 정신 연장
-- 변동비 관리(매 턴 자동 로드 아님) + 활성 본문 1줄 링크로 고정비 비대화 차단
-
-**Phase 2 권고**: 차기 프로젝트 개시 시 첫 착수 = 본 구조 도입 + 이관 가능한 이력 선별 이관.
-
-### 3-D. 새 PC 동기화 4결함 발견 실증
-
-9c99cc6 커밋이 발견·보완한 4결함:
-1. feedback 2종 `memory/` 루트 오배치 → `memory/org/` 이관 (C16-1 junction)
-2. MEMORY.md 인덱스 3종 등재 누락
-3. SKILL.md 교훈 섹션 링크 파손(`../../../memory/MEMORY.md` 부재)
-4. 3 감사관 경로 규범 틀림 (근본 원인)
-
-**교훈**: 새 PC 동기화는 파일 존재 확인만으로 부족 — **실파일·junction reparse point·인덱스 등재·규범 통일 4축**이 모두 필요.
-
-**Phase 2 권고**: `scripts/verify_setup.ps1`에 다음 추가 점검 항목 신설:
-- `memory/` 루트 feedback 파일 0건 보장 (C16-1 연계)
-- `memory/org/MEMORY.md` 등재 건수 vs 실제 `feedback_*.md` 파일 수 일치 검증
-- 3 감사관 정의상 `memory/org/feedback_*` 경로 통일 검증
-
-### 3-E. 본문 최신 + 말미 참조 링크 패턴의 재사용성
-
-본 세션에서 정립된 **"본문에 최신만 + 문서 말미 참조 섹션 1줄 링크"** 패턴이 모든 현역 문서 관리의 표준으로 자리잡음.
-
-**핵심**:
-- 본문 가독성 우선 (상단 배너 금지)
-- 히스토리는 외부 SOT에 집약 (6필드 형식)
-- 예외는 파일 성격 자체를 나타내는 경우(🔴 아카이브됨·🟢 완료 실적)로만 한정
-
-**재사용성**: 차기 프로젝트 전 문서 유형(설계·기획·밸런스·운영)에 일률 적용 가능. 본 세션이 첫 정식 적용 사례(M1·M2·m1·m2·m3 총 5건).
-
----
-
-## 4. 요청 4. 기각안 (P24 필수)
-
-1. **PM 역할 재검토 즉시 발동 권고** — 3회차 재발 정의상 가능하나 본 세션 PM이 PD님 지시를 즉시 집행·로그 완비로 대응한 점 감안, Phase 2 전환 시 C31-E 강화·feedback 보완으로 갈음, 기각
-2. **원칙 1 진화 3회를 각각 별건으로 집계 → 3회차 미해당 판정** — 같은 원칙·같은 해석 패턴·같은 세션이므로 연속 1사건으로 간주, 기각
-3. **수상한잡화점 2026-04-18 대화로그 부재를 P24 위반으로 판정** — 실제 작업은 조직 운영 범주(구용어 정리) 이미 조직운영 로그에 상세 기록, Minor 개선 권고로 대체, 기각
-4. **SKILL.md 유령 참조 2종(`feedback_log_round_completion`·`feedback_pm_context_restoration_failure`) 즉시 삭제** — 해당 참조가 규칙의 실증 근거로 언급된 이상 단순 삭제는 C5 정직성 손상, **실존 feedback 파일로 대체 또는 "2026-04-18 기준 내용은 `feedback_pm_over_conservative_interpretation.md`에 흡수" 명시로 교정** 권고, 단순 삭제 기각
-5. **3축 감사관 산출물 3종 규범 완화** — dev-auditor 2026-04-17 미이행 실증으로 오히려 강화 방향이 정합, 기각
-
----
-
-## 5. Phase 2 조직 자산화 입력 자료 (식별)
-
-PD님 지시 Phase 2 착수 시 PM이 종합할 교훈 4종:
-
-**자산 1 — C31-E 체크리스트 확장안**:
-- "축약 한 단계 더 가능한가?" 자문 추가
-- "본 세션 내 동일 원칙 2회 이상 재개정 시 자진 고지" 항목 신설 검토
-- "자산 가치 보존 vs 저장 위치 보존" 구분 문항은 이미 반영됨(2026-04-18 추가)
-
-**자산 2 — 원칙 선언의 언어적 경직성 해소 구조**:
-- "원칙"을 선언형으로 해석 시 예외·차별화를 "위반"으로 자동 분류하는 패턴 차단
-- 원칙 문면에 "예외 조항·대상 유형별 차별화 권장" 명시
-- 해석 근거 예시 병기
-
-**자산 3 — 3축 감사관 모드 C 교차 활용 노하우**:
-- 본 세션 dev·plan·pm-auditor 동시 모드 C 호출 성공 사례
-- 호출 프롬프트 3요소 (P27-2) + 산출물 3종 규범 + 교차 메타 검증
-- 복잡 결정 표준 절차로 제도화
-
-**자산 4 — 아카이브 SOT 2종 운영 영구 체계**:
-- 폐기_규칙_아카이브(C·P) + 방향전환_히스토리_아카이브(프로젝트 문서) 분리 운영
-- 6필드 형식 + 변동비 관리 + 활성 본문 1줄 링크
-- 차기 프로젝트 이관 시 첫 착수 표준
-
----
-
-## 6. 권고 조치 (PM에게)
-
-### 🔴 Critical 1건 — 즉시 조치 필수
-없음
-
-### 🟠 Major 2건 — 권고 (PM 재량 판단 → PD님 별도 지시 불필요)
-
-1. **SKILL.md 본문 6개소 `memory/feedback_*` → `memory/org/feedback_*` 교정** (원칙 2 수동 정밀 치환)
-   - 교정 대상 위치: L1054·L1082·L1121·L1138·L1604·L1617·L1678
-   - 교정 후 `.live/SKILL.md` 기록 + commit
-2. **유령 참조 2종 교정** (P18 유령 문서 금지 준수)
-   - `feedback_log_round_completion.md`: "본 규칙 내재화 완료, 별도 feedback 파일 없음" 명시 또는 실제 파일 신설
-   - `feedback_pm_context_restoration_failure.md`: "`feedback_pm_over_conservative_interpretation.md`에 흡수" 명시 또는 실제 파일 신설
-
-### 🟡 Minor 2건 — 개선 권고
-
-1. **수상한잡화점 프로젝트 파일 수정 발생 시 프로젝트별 대화로그에 1줄 교차 링크 추가** (P24 운영 정교화)
-2. **`scripts/verify_setup.ps1` 3결함 신설 점검 항목 추가** (새 PC 동기화 완결성 보강)
-
-### 🟢 Improvement 1건 — 장기 검토
-
-- PM 세션 내 동일 원칙 2회 이상 재개정 시 자동 자진 고지 메커니즘 (C31 자기검증 편입 검토)
-
----
-
-## 7. 차기 감사 연계
-
-- **plan-auditor·dev-auditor 후속 감사 필요 영역**:
-  - 기획팀 영역 — Phase 3 재개 로드맵 수립 시 배타 조합(P17) 재검토 기 요청
-  - 개발팀 영역 — 본 감사에서 개발 영역 직접 점검 없음, 본 결과를 dev-auditor 메타 검증 가능
-
-- **본 감사 자체의 메타 검증**:
-  - PM이 필요 판단 시 dev-auditor·plan-auditor에 "본 pm-auditor 판정 타당성 교차 검증" 요청 가능
-  - 특히 2-C(3회차 해당 판정)는 인사 영역에 영향하므로 교차 검증 권고
-
----
-
-## 변경 이력 (P16)
-
-| 일시 | 변경자 | 내용 |
-|------|--------|------|
-| 2026-04-18 | pm-auditor | 모드 C 첫 작성 — 새 PC 동기화 최종 점검 + 3회차 재발 판정 + Phase 2 입력 자료 사전 식별 |
diff --git a/공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md b/공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md
deleted file mode 100644
index a7aee68..0000000
--- a/공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md
+++ /dev/null
@@ -1,219 +0,0 @@
----
-from: pm-auditor
-to: PM
-type: 감사
-mode: C (주제 집중 + 메타 검토)
-subject: 수정 3대 원칙 1 재검토 + 원칙 3 개정 정합성 + 교훈 섹션 외부화 메타 판단
-priority: critical
-status: 완료
-created: 2026-04-18
-references:
-  - 공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
-  - 공유/조직공지/폐기_규칙_아카이브.md
-  - .claude/skills/BurningTimes-코어룰/SKILL.md L1150~L1171 (교훈 섹션)
-  - 프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md (배너 실장 예시)
----
-
-# 원칙 1 재검토 메타 감사 보고 (PM 영역)
-
-**감사 관점**: PD님 3가지 문제 제기를 메타 차원(PM 해석 패턴)까지 확장 검토.
-**허위 보고 없음 선언**: 본 보고 모든 판단은 실측 Read/git log/Grep 결과 기반. 추정은 "추정" 태그 부착.
-
----
-
-## 결론 요약 (5줄)
-
-1. **원칙 1은 원칙 3과 분리 대상이 다르다** — 원칙 1 = "설계·실적 문서"(폐기 후에도 기각안 근거로 **단일 파일 전부 자산**), 원칙 3 = "규칙 선언"(본문은 번호만 남기고 경위는 외부 SOT로 분리). 두 원칙은 **일관성 결여가 아니라 대상 이질성에 따른 정당한 분리**. [Improvement — 명칭·설명 개선 여지]
-2. **교훈 섹션(SKILL.md L1150~L1171, 22줄)은 외부화 가능** — 폐기 규칙 요지 수준의 고정비이며, `memory/org/feedback_*` 18종에 상세 보유. PD님 문제 제기 타당. **즉시 외부화 권고**. [Major]
-3. **PM의 과도 보수 해석은 "1회성"이 아닌 명확한 패턴** — 원칙 3 이전 해석(PD님 직접 지적으로 개정됨) + 현 원칙 1 현 해석(PD님 문제 제기) = 2회 연속. feedback 메모리 신설 권고. [Critical — 재발 방지 구조 필요]
-4. **규칙 일관성 메타 원칙 신설 검토** — "자산 보존 ≠ 원 위치 보존"의 해석 기준을 명문화하여 차기 PM·차기 원칙 해석 오류 차단. [Improvement → Major 안건]
-5. **종합 보고서 작성 시 의견 왜곡 위험 2종** — (가) pm-auditor 자신의 결론을 팀장급 의견과 혼합 인용 (나) 기각안 "없음" 남용. 하단 §5에 방지 체크리스트.
-
----
-
-## 1. 원칙 1·3 정합성 메타 검토 (요청 1)
-
-### 1-1. 두 원칙의 대상 이질성 분석 (실측)
-
-| 축 | 원칙 1 | 원칙 3 |
-|----|--------|--------|
-| **대상 자산** | 설계 문서 · 완료 실적 문서 (독립 .md 파일 단위) | C·P 규칙 **선언**(SKILL.md 내 조항) |
-| **자산 밀도** | 파일 전체가 자산 (설계 경위·수치·기각 근거 통합) | 선언은 번호·명칭만 자산, 경위는 분리 가능 |
-| **토큰 비용** | 개별 파일 = 변동비 (on-demand Read) | SKILL.md 본문 = **고정비** (매 세션·매 Agent 자동 주입) |
-| **참조 구조** | 다른 설계 문서가 파일 경로로 참조 (파일 이동 시 참조 깨짐) | 번호 체계 참조 (번호만 남기면 참조 유지) |
-| **해결 방식** | 배너 + 본문 유지 (파일 이동 X) | 1줄 선언 + 외부 아카이브 링크 |
-
-**결론**: 이질적 자산에 대한 차별화된 처리이며 **논리 불일치 아님**. 단, 인계서 원칙 1 설명에 "대상 이질성" 명시가 부족하여 PM 본인도 원 조항 읽기 시 혼동 가능 — 인계서 개정 필요 (현 파일은 인계서라 수정보다 아카이브 후 재작성 권고).
-
-### 1-2. 그럼에도 남은 개선 영역
-
-**영역 A. 원칙 1 대상에도 "부분 외부화 가능" 예외가 존재함**
-- 예: `07 Headless 원안`은 본문 전부가 설계 자산 → 배너 유지 타당
-- 예: SKILL.md의 L1150~L1171 "교훈 및 노하우" 22줄 → **개별 교훈이 `memory/org/feedback_*` 18종에 상세 보유**. 즉 **중복 자산** (C14-4 참조 무결성 관점에서 외부화 대상)
-
-**영역 B. PD님 문제 제기는 영역 A를 겨냥**
-- "교훈을 본문에 남길 필요 없음" = **중복이 아닌 자산은 본문 유지, 중복이거나 외부 SOT가 있는 자산은 외부화**
-- 이는 원칙 1의 **"폐기 설계 문서는 배너 유지"**와 충돌하지 않음 (설계 문서 ≠ 교훈 리스트)
-
-### 1-3. 개선안 (PM 재량)
-
-**안 1-1. 원칙 1에 "중복 자산 배제 조항" 1줄 추가** (PD님 승인 안건)
-> 원칙 1 — 자산 보존 분리
-> - 설계 문서·완료 실적 문서: 배너 + 본문 유지
-> - 단, **외부 SOT가 상세 보유 중인 요약·인덱스 성격 콘텐츠는 외부화** (중복 자산 제거, C14-4)
-
-**안 1-2. 교훈 섹션 즉시 외부화** (PM 재량)
-- `.live/SKILL.md`에 "교훈 섹션 → `memory/org/MEMORY.md` 인덱스로 링크 대체" 기록
-- SKILL.md 원본 L1150~L1171을 1줄 선언 + 링크로 축약
-- `memory/org/MEMORY.md` 인덱스에 누락된 교훈 엔트리 보완
-
----
-
-## 2. PM의 과도 보수 해석 패턴 메타 진단 (요청 2) — [Critical]
-
-### 2-1. 실증 사례 2건 추출 (2026-04-18 시점)
-
-| # | 시점 | 과도 보수 해석 | PD님 개입 | 재발 방지 조치 |
-|---|------|--------------|-----------|--------------|
-| 1 | 2026-04-17 저녁 | 수정 3대 원칙 원안 원칙 3: "폐기 선언 **본문을 활성 본문 원 위치에 유지**" | PD님 직접 지적 → 개정(저장 위치 최적화) | 커밋 0a8caa0 |
-| 2 | 2026-04-18 본 감사 시점 | 원칙 1 해석: "본문 전부 유지" (중복 자산까지 일괄 유지) | PD님 직접 문제 제기 → 본 메타 감사 | **조치 필요** |
-
-### 2-2. 공통 패턴 추출 ("자산 보존 = 원 위치 보존" 오독)
-
-**심층 원인 (추정)**:
-1. **"보존"의 이중 의미 혼동** — (가) 자산 가치 보존 (나) 저장 위치 보존. PM은 두 의미를 일관되게 (나)로 해석. PD님은 (가)만 의도.
-2. **"삭제 금지" 원칙의 과도 적용** — C6·C19-2의 데이터 보호·복구 불가능 액션 금지가 PM의 "모든 변경은 보수적"으로 오독됨
-3. **PD님 지적 사례 트라우마** — 2026-04-15 승인 범위 확대 해석 불쾌 경험 이후, 반대 방향으로 과보정된 패턴 (memory/org/feedback_approval_scope_expansion.md 참조)
-
-### 2-3. 재발 방지 구조 권고
-
-**조치 1. `memory/org/feedback_pm_over_conservative_interpretation.md` 신설** (PM 재량)
-- 본 2회 사례 영구 기록
-- "자산 가치 ≠ 저장 위치" 해석 기준 명문화
-- 차기 PM 세션 시작 시 참조 대상으로 등재 (MEMORY.md 인덱스 추가)
-
-**조치 2. C31 체크리스트에 "E 그룹" 항목 추가 검토** (PD님 안건)
-- 현 C31-1-E는 "기존 조직 자산 우선 활용"
-- 추가 제안: **"자산 보존 = 원 위치 보존으로 자동 해석하지 않았는가? 중복 자산·외부 SOT 존재 여부 확인했는가?"**
-- PD님 안건화 필요 (헌법급 수정)
-
-**조치 3. 규칙 개정 시 "대상 이질성" 명시 의무**
-- 신설·개정 규칙이 복수 자산 유형에 적용될 때 각 유형별 처리를 분리 명시
-- 본 원칙 1·3 분화 구조를 모범 사례로 참조
-
----
-
-## 3. 교훈 섹션 외부화 메타 판단 (요청 3) — [Major]
-
-### 3-1. 실측 데이터
-
-| 항목 | 값 |
-|------|-----|
-| SKILL.md 총 줄 수 | 1667 |
-| 교훈 섹션 위치 | L1150~L1171 |
-| 교훈 섹션 줄 수 | **22줄** (PD님이 언급한 "약 50줄"보다 적음) |
-| 교훈 엔트리 수 | 16건 (2026-04-14~2026-04-15) |
-| `memory/org/feedback_*` 파일 수 | **18종** |
-
-### 3-2. 중복성 분석
-
-**샘플 대조**:
-- SKILL.md L1156 "승인 반복 문제 — settings.local.json..." ↔ `memory/org/feedback_approval_process.md` (전문)
-- SKILL.md L1157 "settings.local.json 반영 시점..." ↔ `memory/org/feedback_session_restart.md` (전문)
-- SKILL.md L1167 "C13 첫 위반 사례..." ↔ `memory/org/feedback_pm_share_principle.md` (전문)
-
-**결론**: **16건 중 14건 이상이 `memory/` 에 상세 보유** (실측 부분 대조; 전수 매칭은 PM 직접 확인 권고). 즉 SKILL.md 교훈 섹션은 **요약 인덱스** 수준이며 **고정비를 지불할 가치 미비**.
-
-### 3-3. 외부화 3안 비교
-
-| 안 | 장점 | 단점 | 권장 |
-|----|------|------|------|
-| **(a) `공유/조직공지/조직_교훈_아카이브.md` 신설** | 폐기 아카이브와 동격 구조, 조직 가시성 | 이미 `memory/` 가 SOT — 또 다른 중복 SOT 발생 | ❌ |
-| **(b) `memory/org/MEMORY.md` 집약** | 기존 SOT 보강, 중복 제거 | memory는 `~/.claude/projects/` junction (PC별) | ✅ (보완 필요) |
-| **(c) 현행 유지 + 슬림화** | 변경 최소 | 고정비 잔존 | △ (Plan B) |
-
-**권고**: **(b)안 — `memory/org/MEMORY.md` 인덱스 보강 + SKILL.md 교훈 섹션 1줄 링크로 축약**
-
-### 3-4. 실행 절차 (PM 재량 집행 가능)
-
-1. `memory/org/MEMORY.md` Read 후 현 인덱스 구조 확인
-2. SKILL.md L1154~L1171의 16건 교훈 중 `memory/org/` 미등재분 식별
-3. 미등재분은 `memory/org/feedback_*.md` 신설 또는 MEMORY.md 인덱스 추가
-4. SKILL.md L1150~L1171을 다음으로 대체:
-   ```markdown
-   ## 교훈 및 노하우 (외부 SOT)
-   > 개별 교훈·피드백은 `memory/org/MEMORY.md` 인덱스 + `memory/org/feedback_*.md` 전문.
-   > 본 섹션은 C14-4 참조 무결성을 위해 고정비에서 제외.
-   ```
-5. Live 더미 `.live/SKILL.md`에 변경 요지 기록
-6. 대화로그 엔트리 (기각안: 안 (a) — 또 다른 중복 SOT 생성 리스크 / 안 (c) — 고정비 미해결)
-
----
-
-## 4. PM 최종 보고서 작성 시 주의 사항 (요청 4)
-
-### 4-1. 의견 수렴 후 PM 단독 판단 vs PD님 결정 안건 분리 기준
-
-| 카테고리 | PM 단독 판단 가능 | PD님 결정 필요 |
-|----------|------------------|--------------|
-| 규칙 본문 수정 (자구·참조·번호 정합성) | ✅ (C28 무승인) | — |
-| 외부 아카이브 파일 이관·정리 | ✅ (원칙 3 기준 집행) | — |
-| **원칙 1·3 자체 개정** | ❌ | ✅ (헌법급) |
-| **C31 체크리스트 E그룹 추가** | ❌ | ✅ (헌법급 C31 수정) |
-| 교훈 섹션 외부화 집행 | ✅ (C14-4 정합) | — |
-| `memory/feedback_*` 신설 | ✅ (P26 pm-auditor 산출물) | — |
-| **규칙 해석 기준 명문화 (대상 이질성)** | 초안 가능, 확정은 PD | ✅ |
-
-### 4-2. C23(허위 보고) 위험 방지 체크리스트
-
-- [ ] 팀장급 의견 인용 시 **원문 경로 명시** (예: "개발팀장 2026-04-18 응답 L##")
-- [ ] pm-auditor·dev-auditor·plan-auditor 결론을 **주체별로 분리** 인용 (혼합 금지)
-- [ ] "~하는 것이 좋겠습니다" 등 PM 자체 판단과 **감사관 결론 혼동 금지**
-- [ ] 의견 **선별 인용** 시 "일부만 인용" 태그 + 나머지 요지 각주
-- [ ] "전체 동의" 단언은 **실제 전체 응답 재확인 후에만** 사용
-
-### 4-3. 기각안 필드(P24) 남용 방지
-
-- "없음 (다른 안 미검토)" 남발 금지 — 실제 검토했으나 제거한 안을 기록
-- 본 보고서의 **기각안은 §5 참조** (본 감사관 실제 검토 안)
-
-### 4-4. C31 자기검증 적용 방향
-
-- **C31-A**: "PD님 결정 대기" 표현 전 §4-1 표로 재분류
-- **C31-D**: 본 감사 보고서 + dev-auditor·plan-auditor 감사 보고서 + 팀장급 5개 응답 모두 Read 실측 확인 명시
-- **C31-E**: 기존 조직 자산(원칙 1·3 분화 구조, memory/ SOT, 폐기 아카이브) 우선 활용 확인
-
----
-
-## 5. 본 감사 기각안 (P24 필수)
-
-| 검토했으나 기각한 안 | 기각 사유 |
-|--------------------|----------|
-| **원칙 1 폐기 + 원칙 3에 통합** | 대상 이질성이 명확 — 통합 시 설계 문서까지 외부화되어 파일 참조 체계 붕괴 |
-| **원칙 1을 "전부 유지"로 PM 해석 정당화** | PD님 문제 제기 자체가 정당성 부정. 과도 보수 해석 패턴 재발 |
-| **교훈 섹션 `조직공지/조직_교훈_아카이브.md` 신설 이관** | memory/ SOT 와 중복. C14-4 위반 재발 |
-| **PM 단독 원칙 1 개정 집행** | 헌법급 수정 권한 없음. C19-1 승인 범위 엄격 해석 위반 |
-| **교훈 섹션 외부화를 PD님 안건화로만 제한** | C28(문서 수정 무승인) + C14(토큰 최소화) 정합 시 PM 재량 집행 가능 |
-
----
-
-## 6. 감사 분류 요약
-
-| 분류 | 건수 | 내용 |
-|------|------|------|
-| **Critical** | 1 | PM 과도 보수 해석 패턴 (§2) — feedback 메모리 신설 + C31 확장 검토 |
-| **Major** | 2 | 교훈 섹션 외부화 (§3) / 종합 보고서 왜곡 방지 (§4) |
-| **Improvement** | 2 | 원칙 1 설명 명시 보강 (§1-3 안 1-1) / 규칙 개정 시 대상 이질성 명시 의무 (§2-3 조치 3) |
-
----
-
-## 7. PM 권고 사항 (실행 우선순위)
-
-1. **즉시 집행** — `memory/org/feedback_pm_over_conservative_interpretation.md` 신설 (PM 재량, C28 무승인)
-2. **즉시 집행** — 교훈 섹션 외부화 (SKILL.md L1150~L1171 → MEMORY.md 인덱스 링크)
-3. **PD님 안건화 후 집행** — 원칙 1·3 설명 보강 (대상 이질성 명시), C31-E 추가 문항 검토
-4. **본 보고서를 팀장급 5개 에이전트에게 공유** — 동일 패턴 감지 협조 요청
-
----
-
-**감사 완료 선언**: 본 보고 모든 항목은 실측 기반. 미확인은 "추정" 태그. 감사관 자신도 §2의 과도 보수 해석 패턴의 반대편인 "과도 낙관 해석" 위험에 노출됨을 자각 — PM 최종 판단 시 본 감사관 결론도 재검증 대상.
diff --git a/공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md b/공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md
deleted file mode 100644
index cb38a88..0000000
--- a/공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-from: pm-auditor
-to: pm-general
-date: 2026-04-19
-주제: C35-9·10 hook 체계 신설 집행안 감사
-status: 완료 (Major 3건 정정 조건부 허용)
-관련: C35-1 의무 호출 (본 감사가 C35 최초 적용 실증)
----
-
-# 감사 보고서 — C35-9·C35-10 신설 집행안
-
-## 요지
-
-PD님 직접 지시 3종(옵션 A 경고 모드 + 경고 무시 PD 우선 보고 + 장기 패턴 분석·개선 사이클) 집행안 감사 완료. **Critical 부재, Major 3건**은 본문 표기·제목 보정 수준이며 집행 직전 일괄 반영 가능. 차단 사유 없음.
-
-## 감사 범위
-
-| 영역 | 결과 |
-|------|------|
-| 1. 로그 기록 추적 | PASS (조건부 — #44 선등록) |
-| 2. 규칙 준수 점검 | Major 3건 |
-| 3. PM 재량 처리 | PASS |
-| 4. 프로세스 개선점 | PASS (긍정 평가) |
-| 5-A 축소 보고 감지 | PASS |
-| 5-B 백업 파일명 | 해당 없음 |
-| 5-C 안건 중복 | PASS |
-| 5-D 종결 안건 재언급 | PASS |
-
-## Major 3건 정정 권고
-
-### Major-1. C35-9 제목 명확화 (C22 용어 일관)
-
-- 초안: "hook 3층 구조 (Layer 1 사전 환기 · Layer 2 호출 자동 기록 · Layer 3 사후 경고)"
-- 권고: **"pm-auditor 호출 자동 강제 hook 3층 구조"**
-- 사유: C34-3 "중앙 저장소 구조"와 용어 혼선 방지
-
-### Major-2. C35-10 제목 "PD 우선 보고" 원문 보존
-
-- 초안: "경고 무시 PD 보고 + 장기 패턴 분석·개선 사이클"
-- 권고: **"경고 무시 PD 우선 보고 + 장기 행동 패턴 분석 개선 사이클"**
-- 사유: PD님 원문 "PD 우선 보고" 표현 보존 (C22 용어 일관). 지시 3 "장기적 행동 패턴 분석 + 점진적 개선 조치" 원문 반영 강화
-
-### Major-3. C35-9 본문에 "hook 층위 범위" 명시 의무
-
-C35-9 본문 말미에 다음 1단락 추가 필수:
-
-> **본 hook 3층은 사후 감지·기록·경고 층위이며, PreToolUse 차단 방식이 아니므로 LLM의 C35-1 사전 호출 의무 인지는 여전히 필수**다. C35-7 "코드·hook 레벨에서 강제 불가 · ~90% 커버" 한계 인정과 정합하며, 본 hook은 100% 강제가 아닌 "사후 탐지율 극대화 + 미호출 패턴 장기 축적"을 목표로 한다.
-
-**누락 시 리스크**: 다음 세션 PM이 "hook 도입으로 100% 강제 달성" 오독 → C5 정직성 위반.
-
-## Minor 1건
-
-### Minor-1. PD 지시 #44 선등록 (P19)
-
-본 집행 응답 본문 작성 **전**에 `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 활성 테이블에 #44 등록 (지시 인지 즉시 등록 의무). 완료 후 아카이브 이동 + 즉답 접두 필수.
-
-## Improvement 3건 (안건화 후보)
-
-### Improvement-1. C35-1 "조직 자동화 체계 신설" 8번 항목 추가
-
-본 집행은 "규칙 개정(1번)" + "hook 체계 최초 구축" 동시. hook·스크립트·감사 인프라 신설 자체를 C35-1 의무 호출 대상에 명시 검토.
-
-### Improvement-2. `feedback_c35_initial_enforcement.md` 신설
-
-본 감사가 C35 **최초 적용 실증** 사례. "hook 체계 부재 상태에서 PM 의식적 감사관 호출 준수 → C35-7 ~90% 커버 실증" 경위를 feedback 메모리로 영구 기록하여 차기 감사 메타데이터로 축적.
-
-### Improvement-3. `NERDNAVIS_AUDITOR_BYPASS` 우회 사유 기록 의무
-
-우회 변수 남용 차단을 위해 `auditor_guard.sh`에 **우회 시 사유 입력 프롬프트** 또는 **별도 bypass 로그 기록** 추가 검토. 현 초안은 단순 변수 체크만.
-
-## 5-A 축소 보고 감지 심층 분석
-
-PM 주장: "근본 강제 불가를 경고만으로 축소 프레이밍하지 않음 — PD님 옵션 A 본인 선택 + 지시 2·3 수용으로 3층 구조"
-
-감사 판정: **통과**. 다만 Major-3 명시 누락 시 다음 세션 "근본 해결됨" 오독 리스크 존재. Major-3 정정이 5-A 통과의 조건.
-
-## C35 최초 집행 특수성
-
-**논리 정합 통과** — 본 감사관이 Task 도구로 실제 호출되어 실행 중. C35-1 "1. 규칙 개정·신설" 의무 호출을 PM이 수동으로 준수한 것. hook 부재 상태에서도 C35-1 문언만으로 사전 호출 가능. 닭과 달걀 역설 없음.
-
-## 결론
-
-**Major 3건 정정 후 집행 허용**. 차단 사유 없음.
-
----
-
-참조:
-- `memory/org/feedback_issue_under_reporting.md` — C34/C16-1 동급 생존성 축소 보고 금지 (본 감사 5-A 체크 근거)
-- `memory/org/feedback_pm_over_conservative_interpretation.md` — PM 과도 보수 4회차 변종 (상위 패턴 모집단)
-- SKILL.md C35 본문·C34 중앙화 체계
diff --git a/공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md b/공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md
deleted file mode 100644
index 5371c9f..0000000
--- a/공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-type: 감사보고서
-date: 2026-04-20
-agent: pm-auditor
-mode: 모드 A (응답 발신 직전 사전 감사)
-target: PM 대규모 집행 계획 "코어룰 정비 + 매니페스트 기반 감사 재설계"
-judgment: 조건부 통과 (Critical 1·Major 3·Minor 2·Improvement 1)
----
-
-# pm-auditor 감사 보고 — 코어룰 정비 + 매니페스트 전환 (2026-04-20)
-
-## 배경
-
-PD님 2026-04-20 직접 지시 "PM 권고안대로 근본적인 개선 진행. 본질적 문제 해결이 아니라 현재 상황을 기준으로 개선하려던 시도가 잘못되었음을 교훈으로 얻고 재발되지 않도록 코어 룰과 프로젝트 룰도 정비."
-
-PM 집행 계획:
-- **Phase 1**: C2 확장·C31-I 신설·feedback 신규·pm-auditor 5-F 신설
-- **Phase 2**: 매니페스트 기반 감사 재설계 (30분 윈도우 폐기)
-
-## 감사 결과
-
-### Critical (1건)
-
-**C-1. Phase 1+2 1회 감사 커버 금지** — 본 감사는 Phase 1 착수용. Phase 2 실집행 전 재호출 필수
-
-### Major (3건, PM 자가 정정 범위)
-
-**M-1. 매니페스트 설계의 새 proxy 가능성** — PM이 매니페스트를 "근본 해결"로 자가 판정. target_files[] 선언 범위 축소 조작 가능·등록 시점 망각 사각지대·"범위 선언 = proxy" 치환 위험.
-- **권고**: 매니페스트 + **commit diff 사후 cross-check** 2중 구조. 매니페스트가 실제 수정 집합의 부분집합일 경우 사후 경고
-
-**M-2. C2 확장 vs C36 외연 중첩 가능** — C36이 이미 PM 축소·희석 금지 다룸. C2-2·C2-3·C2-4 신설이 중복 SOT 위반 리스크
-- **권고**: C2는 **일반 원칙**(근본 vs proxy 구분, 모든 이슈), C36은 **PM 재량 상한**(방향·원칙 수준). C2-5 신설로 외연 분리 명시
-
-**M-3. feedback §8 폐기 방식 잔존 C14-5 충돌** — 매니페스트 전환 후 "30분 윈도우 초과 실증"이 폐기 방식 기록으로 성격 전환. C14-5-확장(폐기 조항 본문 삭제) 외연 해당 여부 모호
-- **권고**: §8을 현재 본문에 유지하되 상단 "방향 전환 주석" 추가 + Phase 2 완결 시 아카이브 이관 재검토. Improvement로 강등 가능
-
-### Minor (2건)
-
-**m-1. C31-I 구체 문구 PD 최종 컨펌 여부** — "재발되지 않도록 정비" 방향 승인에 C31 체크리스트 신설 구체 문구가 명시 포함되었는지 재확인. PM 자가 판정 리스크
-
-**m-2. 자체 선언 통과 방지** — 백업 포맷·BYPASS·P28-8 자기 선언 말고 실집행 시 감사관이 생성 파일명 실제 확인 필요
-
-### Improvement (1건)
-
-**I-1. 매니페스트 포맷 미결정** — JSON vs md 결정 회피. 권고: **md + YAML frontmatter** (감사관 Read 가독성 + stdin 파싱 용이)
-
-## PM 수용 내역
-
-| 지적 | 수용 | 반영 |
-|------|------|------|
-| C-1 | ✅ | Phase 2 착수 전 재감사 예정 |
-| M-1 | ✅ | 매니페스트 + commit diff cross-check 2중 구조 Phase 2 설계 |
-| M-2 | ✅ | C2-5 신설 (C2 vs C36 외연 분리 명시) |
-| M-3 | ✅ | feedback §8 상단 방향 전환 주석 (Phase 1). 완전 이관 Phase 2 재검토 |
-| m-1 | ✅ | C31-I 문구 본 응답 보고 + 사후 PD님 확인 가능 |
-| m-2 | ✅ | Phase 2 실집행 시 감사관 2차 호출로 실측 확인 |
-| I-1 | ✅ | md + YAML frontmatter 확정 (Phase 2) |
-
-## 판정
-
-**조건부 통과**. M-1~M-3·m-1 수용 반영 후 PM 자가 정정 범위. Phase 2 실집행 전 재감사 필수 (C-1).
-
-## 기록 의무
-
-- 본 보고서: `공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md` (본 파일)
-- 대화로그: `공유/대화로그/조직운영/2026-04-20.md` "Phase 1 집행 + 매니페스트 재설계 착수" 엔트리
-- feedback 교차 참조: `memory/org/feedback_pm_proxy_improvement_reflex.md` 말미 연관 섹션
diff --git a/공유/소통/개발팀→PM/.gitkeep b/공유/소통/개발팀→PM/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md b/공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md
deleted file mode 100644
index a54b2e9..0000000
--- a/공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-type: 자체감사
-from: 개발팀장
-to: PM
-date: 2026-04-17
-status: 완료
-scope: 개발팀 산출물 3축(불필요·중복·상충) 자체 교차 검증
----
-
-# 개발팀장 자체 교차 검증 보고 — 3축(불필요·중복·상충)
-
-## 감사 범위
-- 개발팀장 작성·관리 산출물 (Q-P 응답서, 서버 지시서, 서버 참고자료, Tier 1 설계 04, 시뮬레이터 01~04, 08~12 SOT)
-- 산하 팀장 정의 파일(클라이언트팀장·서버팀장)
-- 코어 프레임워크 실구현(`코어코드/BT.Framework/Runtime/Core/`) ↔ 설계 문서 일치
-
-## A. 불필요 산출물
-1. **`프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md` — 실효성 저하**
-   - v1.2 목적 재정렬로 **"수상한 잡화점 투입 비목적"** 확정된 후, 해당 R&D 자산 자체는 `프로젝트/코어프레임워크/` 디렉토리에서 01~04로 재전개 중
-   - 현재 상태: `수상한잡화점/개발/` 위치에 남아있어 **경로상 "수상한 잡화점 프로젝트 산출물"로 오인 유발**. 05·07에서 여전히 참조됨
-   - 조치안: 본문 최상단 "대체됨(→ 코어프레임워크/01·02·03·04)" 표식 + 참조 문서(05·07)의 참조 경로 교체. 물리 이동은 C6 데이터 보호 준수하며 검토
-2. 그 외 "불필요" 식별분 없음
-
-## B. 중복
-1. **Tier 1 상호작용 설계 — `프로젝트/코어프레임워크/04_Tier1_3종_상호작용_설계_v1.md`와 실구현 헤더 주석 간 부분 중복**
-   - 04 설계 문서가 상세하고 실구현 xmldoc과 포인트가 겹침. 의도적 설계 문서화(P18) 의무 산출물이므로 **허용 중복**. 단, 추후 실구현 변경 시 04 동시 갱신 의무 상기 필요 (C26 갱신 규율과 유사하게 운영)
-2. **방어 수치 언급 — 08 SOT vs 시뮬레이터 01**
-   - 08은 "참조 위치만 기록", 01은 "실측값 0.3f 명시". **관점 차이로 중복 아님 (허용)**. 단 C항목(상충) 참조
-3. 조직 자산 3축 감사 등 SOT 일관성 검증 중복 없음 확인
-
-## C. 상충 (주의 필요)
-1. **★ 08 전투시스템 SOT에 Q-P2 실측값 미반영 — #37 완료 건의 전파 누락 (중요)**
-   - Q-P2 정밀 2차 응답(#37)에서 **`PCDefence_Mul = 0.3f (30%)` 실측**, 기획 가정 50%와 불일치 확인 완료
-   - 시뮬레이터 01·02·03·04는 실측 반영됨
-   - **08 전투시스템 SOT(라인 137·245·343)는 여전히 "Actor.cs:783 참조"만 기록**, 실측 수치 전파 안 됨. 08이 개발팀 전투 SOT이므로 **기획팀이 08을 근거로 작업할 경우 실측과 기획 가정 간 괴리 재발 위험**
-   - 원인: #37 완료 시 시뮬레이터 설계 문서에만 실측 반영, 08 SOT 미동기화 (C29-4 부분 누락)
-   - 조치안: 08 §방어 감소 계산 블록에 "2026-04-17 Q-P2 실측 확인: `PCDefence_Mul = 0.3f`" 명기 + 변경 이력 추가. 자진 정정 예정
-2. **06 신규코어 설계안 — 위치·문서 상태 상충**
-   - 문서 성격: R&D 자산 (v1.2 목적 재정렬)
-   - 배치 위치: `수상한잡화점/개발/` (프로젝트 투입 비목적과 모순적 경로)
-   - 조치안: A1과 동일 (대체됨 표식 + 참조 경로 교체)
-3. 그 외 상충 식별분 없음
-
-## 자기 실수 자진 보고 (C5·C23)
-- **#37 완료 시 08 SOT 동기화 누락 — 본인(개발팀장) 실수**. Q-P2 실측 결과를 시뮬레이터 계열 4종에만 반영하고 근원 SOT(08)에 전파 누락. C29-4 "업무 완료 후 동기화" 부분 위반
-- 재발 방지: 실측·수치 확정 시 **"수치가 등장하는 모든 SOT 전수 grep"** 을 완료 처크리스트에 편입 필요. 안건화 상정
-
-## 검증 완료 (C5 정직성)
-- 감사 대상 파일 실존 여부 전부 Glob/ls로 확인
-- 상충 건은 실제 본문 grep 결과로 입증 (08:137·245·343 vs 시뮬01:128·132)
-- "없음" 항목은 실제 확인 후 명시
diff --git a/공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md b/공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md
deleted file mode 100644
index d302f6e..0000000
--- a/공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md
+++ /dev/null
@@ -1,476 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-date: 2026-04-18
-type: 실무 검토 보고서
-subject: worktree 격리 근원 해결안 (중앙 `.live/` Junction 체계) 실무 검토
-priority: 조직 생존급
-upstream: PD님 직접 지시 "이 문제가 해결되지 않으면 앞으로 우리 조직은 유지될 수 없어" · "가능한 모든 수단을 써서 개선해"
-related_rules: 헌법 제1원칙 ⑤, C2, C5, C6, C16, C19, C30, P25
-status: 완료
----
-
-# worktree 격리 근원 해결안 실무 검토 — 중앙 `.live/` Junction 체계
-
-## 0. 검토 결론 요지 (Executive Summary)
-
-1. **PM 1차 설계안(Junction 기반 중앙 `.live/`)을 원칙적으로 승인 권고**. C16-1 memory junction 패턴과 기술·규범적으로 동형이므로 조직 검증된 방식의 직접 재사용이다.
-2. 단, 원안에 **7개 엣지 케이스 보완 필요**. 핵심은 **Windows 개발자 모드 없는 환경의 junction 생성 실패 시 방침**과 **worktree 자동 생성 시점의 선주입 보장**이다.
-3. **worktree-local로 격리된 기타 자산 전수 조사 결과 — `.live/`만이 문제**. 기존 중앙화 자산(`~/.claude/.nerdnavis_bus/`, `~/.claude/.nerdnavis_throttle/`, `memory/org/` junction)은 이미 PC 중앙화되어 있음. `.live/`가 유일한 "worktree-local 의미 자산"이며, 따라서 본 단일 해결책으로 전체 문제가 근원 해소된다.
-4. **구현 복잡도 대비 효용 — 절대 우세**. Setup 스크립트 50줄 내외, hook 로직 무변경, `verify_setup.ps1` 3축 검증 확장 30줄. 한편 해결되는 문제는 조직 생존급.
-5. **대안 검토 — 모두 열등**. (A) `.live/`를 git-tracked로 전환: 세션별 commit 폭증·merge conflict 상시. (B) Hook을 `REPO_ROOT` 대신 절대 경로 하드코딩으로 수정: C16 PC 독립성 훼손. (C) Worktree 사용 중단: Claude Code 내부 동작이라 제어 불가.
-
-본 검토서는 C2(근원적 문제 해결)·헌법 제1원칙 ⑤(세션·PC 연속성) 정합 기준으로 최종안을 확정했다.
-
----
-
-## 1. 현상 재현·실측 근거 (C23 정직성 — 실제 tool_use 결과만)
-
-### 1.1 worktree 격리 실증
-
-```
-$ git worktree list (cd E:/BurningTimesAi)
-E:/BurningTimesAi                                         5085c56 [main]
-E:/BurningTimesAi/.claude/worktrees/nifty-wing-4752bd     5085c56 [claude/nifty-wing-4752bd]
-E:/BurningTimesAi/.claude/worktrees/tender-liskov-844a72  5085c56 [claude/tender-liskov-844a72]
-```
-
-### 1.2 `.live/` 물리 격리 실증
-
-- 본 worktree (`tender-liskov-844a72`) `.live/`: `README.md` 만 존재 (총 2개 파일)
-- 타 worktree (`nifty-wing-4752bd`) `.live/`: `README.md` + `ping.md` (19 bytes, 21:13 생성) — 본 worktree에서 **전혀 보이지 않음**
-- 메인 레포 (`E:/BurningTimesAi`) `.live/`: `README.md` 만 존재 (21:08 수정)
-
-즉 **같은 PC·같은 시각·같은 레포·같은 브랜치**임에도 `.live/`는 각 worktree 작업 트리 내부에 독립 실체로 존재한다.
-
-### 1.3 기술적 원인
-
-- `scripts/live_inject.sh` 6행: `REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)`
-- worktree 내부에서 `git rev-parse --show-toplevel`은 **해당 worktree의 루트**를 반환 (`.git/worktrees/{id}/gitdir`가 worktree 내부 `.git` 파일을 가리킴)
-- 따라서 `LIVE_DIR="$REPO_ROOT/.live"`가 **각 worktree별로 서로 다른 물리 경로**를 가리키게 됨
-- 결과: 한 worktree가 기록한 `.live/*.md`는 다른 worktree의 hook이 인지 불가 → P25 "같은 PC 내 다른 세션 즉시 인지" 전제 파괴
-
-### 1.4 기존 중앙화 자산과의 비대칭성 (왜 `.live/`만 문제인가)
-
-본 실무 검토 중 조직 내 worktree-local 저장 가능성이 있는 자산 전수 조사 결과:
-
-| 자산 | 저장 위치 | worktree 영향 | 상태 |
-|------|----------|--------------|------|
-| 사용자 메모리 (`memory/org/`) | `~/.claude/projects/<해시>/memory` junction | 무영향 (HOME 기반) | ✅ 중앙화 |
-| 시그널 버스 (`sync_signal.sh` 플래그) | `$HOME/.claude/.nerdnavis_bus/` | 무영향 (HOME 기반) | ✅ 중앙화 |
-| 증분 throttle 카운터 (`live_inject.sh`) | `$HOME/.claude/.nerdnavis_throttle/` | 무영향 (HOME 기반) | ✅ 중앙화 |
-| git-hooks (`core.hooksPath`) | `scripts/git-hooks/` (git 공용) | 무영향 (worktree 간 공유) | ✅ 중앙화 |
-| inbox 스캔 해시 | `$HOME/.claude/.nerdnavis_throttle/inbox_hash_*` | 무영향 (HOME 기반) | ✅ 중앙화 |
-| **`.live/` 더미 파일** | **`$REPO_ROOT/.live/` (worktree-local)** | **격리 발생** | ❌ **문제 지점** |
-| paths.local.json | 레포 루트 (worktree는 각자 copy) | 실측 미확인 (아래 §5.2에서 후속 점검) | ⚠️ 잠재 |
-
-즉 **P25 Live 체계의 저장 위치 설계가 다른 자산들의 HOME 기반 원칙에서 이탈**되어 있었던 것이다. 중앙화로의 재편은 조직 자산 설계 일관성 회복 차원에서도 정당하다.
-
----
-
-## 2. PM 1차 설계안 심층 분석
-
-### 2.1 원안 재진술
-
-- **실 저장**: `$HOME/.claude/nerdnavis-live/` (PC 로컬 단일 디렉토리)
-- **각 worktree의 `.live/`**: 위 실 저장으로의 **Junction** (Windows `mklink /J`) 또는 **Symbolic link** (macOS/Linux `ln -s`)
-- **Setup 스크립트**: 자동 생성 (신규 PC 1회·기존 PC 1회)
-- **Hook 로직**: 불변 (`REPO_ROOT/.live` 경로는 그대로 사용, junction이 자동 경유)
-
-### 2.2 원칙적 타당성 평가 — 우수
-
-1. **C16-1 memory junction 패턴과 동형** — `~/.claude/projects/<해시>/memory` → `memory/org/` junction과 기술·규범 동일. 조직 검증된 방식이므로 리스크가 낮다.
-2. **Hook 무변경** — `live_inject.sh`·`live_session_load.sh`·`sync_push.sh` 등 기존 스크립트 일체 수정 불요. 본 해결책은 **운영체제 파일시스템 계층의 투명한 우회**이며 애플리케이션 계층에는 영향이 없다 → C14(토큰 최소화)·C10-5(기존 산출물 신뢰) 정신에도 부합.
-3. **역호환성 확보** — 기존 hook이 `REPO_ROOT/.live`를 그대로 참조하므로 junction 미생성 worktree에서도 (격리된 상태이지만) 정상 동작. 점진 전환·롤백 가능.
-4. **자산 가치 유지** (P25 🏆 조직 핵심 자산) — P25가 보증하는 "같은 PC 내 세션 간 네트워크 비용 0 실시간 공유"를 완전 복원.
-5. **PD님 지시 정합** — 헌법 제1원칙 ⑤("세션·PC 연속성 보장") 직접 기여. C2(근원적 문제 해결 — 임시방편 아님)·C31-E("기존 조직 자산 우선 활용") 체크 통과.
-
-### 2.3 잠재 리스크 7종 (보완 필요 항목)
-
-본 원안을 그대로 채택해도 안전하나, 아래 엣지 케이스 7종에 대한 명시적 대응을 원안에 추가해야 완결된다. 각 항목은 §3·§4에서 상세 설계한다.
-
-1. **R1. Windows Junction 생성 권한 이슈** — 개발자 모드 불필요(일반 사용자도 `mklink /J` 가능, §3.1)
-2. **R2. macOS/Linux Symlink vs Junction 차이** — 동작 동일하나 실체 검증 플래그가 다름 (§3.2)
-3. **R3. 기존 `.live/` 데이터 마이그레이션 시 README.md 보존** (§4.3)
-4. **R4. Worktree 자동 생성 시점의 지연 주입** — Claude Code가 신규 worktree를 만들 때 첫 SessionStart hook이 junction을 생성해야 격리 세션이 되지 않음 (§4.5)
-5. **R5. Junction 타깃 디렉토리 미존재 상태 처리** — 신규 PC 첫 setup 시 순서 (§4.2)
-6. **R6. `paths.local.json` 등 기타 worktree-local 파일 점검** (§5.2)
-7. **R7. 격리 시그널 수집 — verify 3축 검증의 자동 복구 범위 한정** (§5.3)
-
----
-
-## 3. OS별 Junction/Symlink 기술 상세
-
-### 3.1 Windows (PRIMARY — 현 주 환경)
-
-#### 3.1.1 사용 명령
-```cmd
-cmd /c mklink /J "<worktree>\.live" "$HOME\.claude\nerdnavis-live"
-```
-
-#### 3.1.2 권한·환경 요구
-- **일반 사용자 권한으로 충분** — `/J` (junction)은 **개발자 모드 불요·관리자 권한 불요**
-- 구분: `/D` (directory symbolic link)는 관리자 권한 또는 개발자 모드 필요하나 `/J`는 예외
-- 조직 기존 자산 증명: `setup/setup_windows.ps1` 99·104행이 이미 동일 방식으로 memory junction을 생성하고 있으며 조직 전 PC에서 문제없이 동작 중
-- 따라서 본 해결책은 **조직 내 이미 입증된 기술 기반**
-
-#### 3.1.3 기술 제약
-- **Junction 타깃은 로컬 드라이브**만 지원 (네트워크 드라이브 불가). HOME은 항상 로컬이므로 무관.
-- **Junction은 디렉토리 전용** — `.live/` 디렉토리 대상이므로 해당 없음.
-- 파일 단위 hard link가 필요하면 `/H`이나 본 설계는 디렉토리 단위이므로 `/J`가 정답.
-
-#### 3.1.4 검증 가능성
-- PowerShell: `(Get-Item <path> -Force).Attributes -band [IO.FileAttributes]::ReparsePoint` — reparse point 여부 확인
-- 이미 `scripts/verify_setup.ps1` 87·100행이 동일 패턴을 memory junction에 적용 중이므로 `.live/` junction에 그대로 재활용 가능
-
-#### 3.1.5 문제 시나리오
-| 시나리오 | 증상 | 대응 |
-|---------|------|------|
-| 타깃 경로 미존재 | `mklink` 실패 (errorlevel 1) | setup 순서로 예방 — **타깃 먼저 생성 후 junction** (§4.2) |
-| 링크 경로에 이미 실 디렉토리 존재 | `mklink` 실패 ("이미 있습니다") | 백업 후 제거 — memory junction 패턴 동일 (setup_windows.ps1 94-97행과 동형) |
-| 링크 경로가 이미 junction | 기존 타깃 추적 후 올바르면 유지 | §4.2 setup 로직이 reparse 플래그로 판별 |
-| 타깃 디렉토리 삭제 | junction은 남지만 dangling | 연결 대상 복구 시 자동 복원 (데이터만 복구하면 연결은 회복) |
-| Windows Update/Defender | 가끔 reparse point 복사본을 실 디렉토리로 오해 | 실증상 수상한잡화점 조직 PC들에서 발생 보고 없음. 발생 시 setup 재실행으로 복원 |
-
-### 3.2 macOS / Linux (SECONDARY — 현 미사용 but 조직 자산 호환성 유지)
-
-#### 3.2.1 사용 명령
-```bash
-ln -s "$HOME/.claude/nerdnavis-live" "<worktree>/.live"
-```
-
-#### 3.2.2 권한·환경 요구
-- 일반 사용자 권한 충분
-- macOS: 디폴트 지원
-- 조직 기존 자산 증명: `setup/setup_macos.sh` 53·56행이 memory symlink 동일 방식 사용 중
-
-#### 3.2.3 Windows와의 동작 차이 1점
-- Symlink는 **파일로도 표시**될 수 있어 `test -L`로 판별 필요
-- Junction은 디렉토리 속성 유지이므로 `test -d`로 판별되지만 `[IO.FileAttributes]::ReparsePoint` 플래그로 구분
-- 결과적으로 **Bash hook 관점에서는 양쪽 모두 `test -d "$LIVE_DIR"`이 true**이므로 hook 로직 무변경 가능
-
-#### 3.2.4 문제 시나리오 (Windows 대비 감소)
-- macOS: `~/Library/CloudStorage/` 등 iCloud 동기화 폴더 하위에 symlink 생성 금지 (iCloud가 심볼릭 링크 타깃을 복제해버림). HOME은 일반적으로 iCloud 외부이므로 무관.
-- Linux: 거의 무제한 지원.
-
-### 3.3 공통 설계 원칙
-- 실 저장 경로: `$HOME/.claude/nerdnavis-live/` (Win: `%USERPROFILE%\.claude\nerdnavis-live\`, Unix: `$HOME/.claude/nerdnavis-live/`)
-- `~/.claude/` 디렉토리는 이미 Claude Code가 사용 중이므로 별도 관리 부담 없음
-- `memory/org/` junction과 동일 HOME 하위 영역 → 셋업·삭제·복구 정책 단일 프로세스로 통합 가능
-
----
-
-## 4. Setup 스크립트 확장 상세 설계
-
-### 4.1 목적
-
-신규 PC 최초 setup + 기존 PC 기존 데이터 마이그레이션을 단일 스크립트 실행으로 완결한다. **Idempotent** — 몇 번 실행해도 동일한 최종 상태를 보장한다.
-
-### 4.2 공통 절차 (OS 무관 동일 흐름)
-
-| 순서 | 작업 | 실패 시 방침 |
-|------|------|--------------|
-| 1 | 실 저장 디렉토리 생성 — `$HOME/.claude/nerdnavis-live/` | mkdir 실패 = 홈 디렉토리 권한 이상, 치명 → 보고 후 중단 |
-| 2 | 실 저장에 `README.md` 복사 — 최소 1회, 이미 있으면 skip | skip |
-| 3 | 레포 루트 `.live/`의 기존 파일 전수 확인 | N/A |
-| 4 | 기존 파일 중 `README.md` 이외의 파일들 실 저장으로 이관 (copy, 같은 파일명 있으면 skip — 기존 실 저장이 우선) | 실패 시 해당 파일만 skip + 경고 |
-| 5 | 레포 루트 `.live/` 실 디렉토리 백업 후 삭제 | 백업: `.live.bak-{timestamp}/`. 백업 실패 시 junction 생성 중단 |
-| 6 | 레포 루트 `.live/` 위치에 junction/symlink 생성 → 타깃 = 실 저장 | 실패 시 fallback 실행 (§4.4) |
-| 7 | 기존 worktree 전수(`git worktree list`) 순회하여 각 worktree의 `.live/`도 동일 절차 반복 | worktree별 독립 실패 허용, 실패 worktree는 WARN |
-| 8 | 검증 — 각 junction이 reparse point인지·타깃이 올바른지 실측 | §4.6 |
-
-### 4.3 기존 `.live/` 마이그레이션 안전성 (R3)
-
-**기존 운영자 PC에서 안전한가?** — 예, 단 아래 보강 포함 시.
-
-#### 4.3.1 안전 요소
-- `.live/README.md`는 `git ls-files`로 추적 중 (실측 확인) → 삭제되어도 git에서 복원 가능
-- 기존 다른 `.live/*.md`는 일시적 더미이며 SessionStart hook이 자동 비우는 대상 → 영구 자산 아님
-- 백업 디렉토리 보존 (`.live.bak-{timestamp}/`)로 롤백 가능
-
-#### 4.3.2 잠재 위험 + 보강
-- **세션 실행 중 setup 실행** → 열린 파일 핸들과 충돌 가능. **보강**: setup 스크립트 상단에 경고 출력 "모든 Claude Code 세션 종료 후 실행 권장"
-- **기존 더미에 아직 원본 미반영 데이터 존재** → 이관 대상이므로 실 저장에 복사하여 보존 (§4.2 단계 4)
-- **동일 파일명이 실 저장과 worktree `.live/` 양쪽에 존재** → 실 저장이 우선(skip) 정책으로 일관. 사용자는 `.live.bak-*/`에서 수동 확인 가능
-
-#### 4.3.3 C6-1 (원본 보호) 정합성
-- 기존 `.live/` 실 디렉토리는 즉시 삭제하지 않고 `.live.bak-{timestamp}/`로 rename → C6-1 백업 파일명 규칙 (`{원본명}.bak_{YYYYMMDD_HHMM}`) 변형 준수. **중요·대규모 변경**은 아니므로 (일시 더미의 재배치이므로) PD님 별건 최종 승인은 불요 — 본 검토서 자체가 PD 승인 하의 집행 사전 보고 역할
-
-### 4.4 Junction 생성 실패 시 Fallback (R1, R2, 원문 요청 질문 5)
-
-#### 4.4.1 실패 원인 분류
-| 원인 | 발생 확률 | 대응 방침 |
-|------|----------|----------|
-| Windows 정책으로 `mklink` 금지 | 극히 희박 (대기업 관리 환경) | §4.4.2 |
-| 파일시스템 비지원 (예: 일부 네트워크 FS) | HOME이 로컬이면 해당 없음 | 해당 시 WARN |
-| 이미 실 디렉토리 존재 + 백업 불가 | 파일 잠금 등 | §4.4.3 |
-| 관리자 권한 이슈 (이론상 `/J`는 무관) | 극히 희박 | §4.4.2 |
-
-#### 4.4.2 1차 Fallback — 정상 디렉토리 유지 + 경고
-- junction 생성 실패 시 해당 worktree의 `.live/`는 **일반 디렉토리로 유지** (삭제 금지)
-- **경고 로그** + 조직공지 SOT에 자진 보고 (`공유/조직공지/YYYY-MM-DD_Live_junction_생성실패_<PC명>.md`)
-- 해당 worktree는 **P25 혜택을 받지 못하는 degraded 상태**로 동작 (격리되어 있음). PM 명시 push·pull 경로로 수동 동기화
-- SessionStart hook이 상태 감지하여 매 세션 시작 시 재시도 (§4.5 `session_start_junction_check.sh` 신설)
-
-#### 4.4.3 2차 Fallback — 작업 차단 선택지 (본 검토서 권장)
-- **권장 방침**: 1차 Fallback(경고 + degraded 동작)
-- **이유**: 작업 차단은 조직 생존급 사안 해결이 목적인 본 변경이 **또 다른 생산성 저하를 유발하는 역설**을 만듦. degraded 상태라도 **기존 worktree 미적용 상태와 동등한 수준**이므로 후퇴 없음
-- 원문 요청 질문 6의 "SessionStart hook에서 자동 설치 vs 작업 차단" — **자동 설치 재시도 + 실패 시 degraded + 조직공지 자동 발행**이 최적. **차단 방침은 반대**
-
-### 4.5 Worktree 자동 생성 시점 대응 (R4)
-
-#### 4.5.1 문제
-- Claude Code가 신규 worktree를 **세션 시작 직후 자동 생성** (본 세션의 `tender-liskov-844a72`도 동일 패턴)
-- 이 시점에는 setup 스크립트가 실행되지 않음 → 신규 worktree의 `.live/`는 처음부터 일반 디렉토리로 생성됨 (격리 상태)
-
-#### 4.5.2 해결책 — SessionStart hook에 junction 설치 자동화 추가
-`scripts/live_session_load.sh` 상단 또는 별도 신규 스크립트 `scripts/live_junction_ensure.sh`로 다음 로직 삽입:
-
-```bash
-#!/bin/bash
-# SessionStart 전용 — 현 worktree의 .live/가 junction인지 확인, 아니면 생성
-REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
-[ -z "$REPO_ROOT" ] && exit 0
-
-LIVE_DIR="$REPO_ROOT/.live"
-CENTRAL_DIR="$HOME/.claude/nerdnavis-live"
-
-# 중앙 저장소 미존재 시 생성 (idempotent)
-mkdir -p "$CENTRAL_DIR" 2>/dev/null
-
-# .live/가 reparse point(junction)/symlink면 통과
-if [ -L "$LIVE_DIR" ] || (cmd //c "dir /A:L \"$LIVE_DIR\" 2>&1" | grep -q '<JUNCTION>' 2>/dev/null); then
-  exit 0
-fi
-
-# 실 디렉토리면 백업 후 junction 생성 (R3 안전 절차)
-if [ -d "$LIVE_DIR" ]; then
-  BAK="$LIVE_DIR.bak-$(date +%Y%m%d_%H%M)"
-  # 중앙 저장으로 파일 이관 (없는 파일만)
-  for f in "$LIVE_DIR"/*; do
-    [ -f "$f" ] || continue
-    name=$(basename "$f")
-    [ -e "$CENTRAL_DIR/$name" ] || cp "$f" "$CENTRAL_DIR/$name"
-  done
-  mv "$LIVE_DIR" "$BAK" 2>/dev/null
-fi
-
-# OS별 링크 생성
-case "$(uname)" in
-  MINGW*|CYGWIN*|MSYS*)
-    cmd //c "mklink /J \"$(cygpath -w "$LIVE_DIR")\" \"$(cygpath -w "$CENTRAL_DIR")\"" >/dev/null 2>&1
-    ;;
-  *)
-    ln -s "$CENTRAL_DIR" "$LIVE_DIR" 2>/dev/null
-    ;;
-esac
-
-# 검증 + 실패 시 조직공지 발행
-if [ ! -L "$LIVE_DIR" ] && ! (cmd //c "dir /A:L \"$LIVE_DIR\" 2>&1" | grep -q '<JUNCTION>' 2>/dev/null); then
-  NOTICE="$REPO_ROOT/공유/조직공지/$(date +%Y-%m-%d)_Live_junction_생성실패_$(hostname).md"
-  if [ ! -f "$NOTICE" ]; then
-    cat > "$NOTICE" <<EOF
-# ⚠️ Live junction 생성 실패 — $(hostname) / worktree: $(basename "$REPO_ROOT")
-
-SessionStart hook이 $REPO_ROOT/.live를 junction으로 생성하지 못했습니다.
-해당 worktree는 P25 실시간 공유에서 제외됩니다(degraded 상태).
-
-**복구 절차**:
-1. \`setup/setup_windows.ps1\` 재실행 (관리자 권한 시도)
-2. 수동 명령: \`cmd /c mklink /J \"$LIVE_DIR\" \"$CENTRAL_DIR\"\`
-3. 실패 지속 시 개발팀장 보고
-EOF
-  fi
-fi
-exit 0
-```
-
-**효과**: Claude Code가 새 worktree를 만들어도 **첫 프롬프트가 입력되기 전**에 SessionStart hook이 junction을 설치 → 실질적으로 격리 시간 0.
-
-#### 4.5.3 Hook 호출 순서 영향
-- `.claude/settings.json` SessionStart hooks 체인 중 **`live_session_load.sh` 이전에** 실행되어야 함
-- 현 체인: `git fetch merge` → `inbox_scan` → `change_digest` → `live_session_load` → `pm_context_restore` → `verify_log_paths` → `git config hooksPath`
-- **권고 배치**: `change_digest` 이후, `live_session_load` 이전에 `live_junction_ensure.sh` 삽입 → `live_session_load`가 이미 junction된 경로를 참조하므로 일관
-
-### 4.6 설치 후 3축 검증 (verify_setup.ps1 확장, 원문 요청 질문 4)
-
-기존 3축 검증(`scripts/verify_setup.ps1`)에 다음 확장:
-
-#### 4.6.1 축 1 — 파일 존재
-- `$HOME/.claude/nerdnavis-live/` 디렉토리 존재
-- `$HOME/.claude/nerdnavis-live/README.md` 실 파일 존재
-
-#### 4.6.2 축 2 — OS 동작 (reparse point / symlink 실체 검증)
-- 레포 루트 `.live/`: `(Get-Item -Force).Attributes -band [IO.FileAttributes]::ReparsePoint` ≠ 0
-- 해당 target이 `$HOME\.claude\nerdnavis-live`와 일치
-- 각 worktree별(`git worktree list` 순회) `.live/`도 동일 검증
-
-#### 4.6.3 축 3 — 실행 결과 (실제 쓰기·읽기 동작 확인)
-- 각 worktree에서 테스트 파일 write: `.live/_verify_{pid}.md` 쓰기 → 중앙 저장에서 read 확인 → 삭제
-- **중요**: 동일 중앙 저장을 가리키므로 A worktree에서 쓴 파일이 B worktree에서 읽혀야 통과
-
-#### 4.6.4 자동 복구 로직
-- 축 2 실패 (junction이 실 디렉토리로 변형) → 자동 재설치 시도 (§4.5 스크립트 호출)
-- 축 3 실패 (실 저장 read 불가) → 조직공지 발행 + 개발팀장 수동 보고
-- **무한 재시도 금지** — 3회 실패 시 degraded 상태 수락 + 조직공지
-
-### 4.7 Setup 스크립트 디프 요약 (구현 범위)
-
-| 파일 | 변경 유형 | 추가 라인 수 (대략) |
-|------|----------|------------------|
-| `setup/setup_windows.ps1` | §4.2 7단계 로직 추가 (memory junction 로직 직후에 배치) | 약 60줄 |
-| `setup/setup_macos.sh` | 동 | 약 50줄 |
-| `scripts/live_junction_ensure.sh` | 신규 | 약 40줄 |
-| `scripts/verify_setup.ps1` | §4.6 3축 확장 | 약 30줄 |
-| `.claude/settings.json` | SessionStart hook 체인에 `live_junction_ensure.sh` 삽입 | 5줄 |
-| **Hook 로직 (`live_inject.sh` 등)** | **무변경** | 0줄 |
-
----
-
-## 5. 종합 리스크 재평가 + 원안 미대응 영역 (원문 질문 7, 8, 9)
-
-### 5.1 기존 worktree 운용 정책과의 양립 (질문 8)
-
-- Claude Code의 worktree 생성 자체는 **Claude Code 내부 동작**이며 조직이 제어 불가
-- `.gitignore` 22행: `.claude/worktrees/` 는 이미 git ignore 대상 → worktree가 조직 레포에 혼입되지 않도록 설계되어 있음
-- 본 해결책은 **worktree 기능 사용을 중단시키지 않고도 P25 효용을 완전히 회복**시킴 — 양립 완전 달성
-- **엣지 케이스**: Claude Code가 worktree 생성 직후 setup 스크립트 실행 없이 세션 시작 — §4.5 SessionStart hook으로 해결
-- **엣지 케이스 2**: 세션 도중 새 worktree 추가 (예: 병렬 세션 시작) — 신 worktree에서의 첫 프롬프트 제출 시 UserPromptSubmit hook이 실행되기 전 SessionStart hook이 먼저 실행되므로 동일 해결
-
-### 5.2 기타 worktree-local 자산 전수 조사 (질문 7) — 추가 발견 없음, 단 `paths.local.json` 정밀 점검 필요
-
-§1.4에서 정리한 전수 조사 결과: `.live/` 외 worktree-local 의미 자산은 없음.
-
-**단, `paths.local.json`** (루트 레포의 로컬 경로 설정) 관련 **미확인 1건**:
-- 신규 worktree 자동 생성 시 `paths.local.json`이 복사되는지 / 상위 레포를 자동 참조하는지 실측 필요
-- 본 검토 범위 한계로 미확인 — DevOps 후속 점검 위임 권고 (§7.2 참조)
-
-**발견 2**: `inbox_hash_*`, `last_fetch_*`, `hold_files_hash`는 모두 `~/.claude/.nerdnavis_throttle/`(HOME)에 저장 → worktree 무영향 — 추가 중앙화 조치 불요
-
-**결론**: `.live/` 중앙화 1건으로 **근원 해결 완결**. 추가 자산 중앙화는 현 시점 불요.
-
-### 5.3 자동 복구 범위 한정 (질문 4, R7)
-
-자동 복구 스코프를 과도 확장하면 오류 시 조용히 실패로 이어져 C5(정직성)·C23(허위 보고 금지) 위반 가능. 따라서:
-
-- **자동 복구 허용**: junction 유실·타깃 미존재·reparse 플래그 손상
-- **자동 복구 금지**: 중앙 저장소 내부 파일 손상·더미 파일 내용 훼손 (이는 데이터 문제이므로 복구가 아닌 보고)
-- **3회 실패 후 종료** — 동일 복구 시도 루프 방지
-
-### 5.4 역추적 위험 — 기존 `.live/` 잔존 파일 처리 (질문 9)
-
-#### 5.4.1 현 상태 실측
-- 본 worktree(`tender-liskov-844a72`): `README.md`만 존재
-- 타 worktree(`nifty-wing-4752bd`): `README.md` + `ping.md` (19 bytes, 테스트 파일)
-- 메인 레포: `README.md`만 존재
-
-#### 5.4.2 처리 방침
-- **`README.md`**: git tracked → junction 생성 시 중앙 저장으로 이관 (§4.2 단계 4). git 상태는 `README.md` 내용 자체가 중앙 저장을 통해 **동일 파일 제공**되므로 변화 없음. `git status`가 `deleted`로 오인할 수 있으나 junction 내부 파일 자체는 동일 → git 정상 추적
-  - **주의**: git이 reparse point를 어떻게 인식하는지 OS·git 버전별 차이 가능. 실증 결과 memory junction의 경우 git이 해당 디렉토리 자체를 건드리지 않음 → `.live/` junction도 유사 동작 예상. 단 실증 후 최종 확정 필요 (§7.3)
-- **`ping.md`**: 테스트 파일, 임의 시점 소멸 가능한 더미 → 삭제 무방. 단 마이그레이션 시 중앙 저장으로 이관하여 보존 가능 (정책 선택)
-
-#### 5.4.3 권장 처리 순서 (집행 시)
-1. 조직 전원 세션 종료 통보
-2. 각 PC에서 setup 스크립트 실행 (junction 설치 + 마이그레이션)
-3. 백업 디렉토리(`.live.bak-*`) 보존 (1주일 후 삭제 권고)
-4. 각 PC에서 verify_setup.ps1 3축 검증 통과 확인
-5. 1 주간 관찰 기간(관찰 안정 후 백업 삭제 공지)
-
-### 5.5 장기 운영 리스크 — 중앙 저장소 비대화
-
-- `.live/` 증분 더미는 세션 시작 시 자동 비우는 설계(`live_session_load.sh` 46-56행) → 중앙화되어도 정책 유지
-- 단, 비정상 종료(세션 크래시)로 잔여 더미가 쌓이면 점진 증가 가능
-- **완화**: `live_session_load.sh`에 **30일 경과 파일 자동 정리** 로직 추가 권고 (선택 사항, 긴급 아님)
-
----
-
-## 6. 테스트 시나리오 (집행 후 검증)
-
-| # | 시나리오 | 성공 기준 |
-|---|---------|----------|
-| T1 | 단일 PC 단일 worktree에서 `.live/test.md` 작성 → 본 세션 다음 프롬프트에서 hook이 주입 | `[LIVE:test.md]` 헤더로 내용 주입 |
-| T2 | 단일 PC 메인 + worktree A 2세션 중 A에서 `.live/test.md` 작성 → 메인 세션 다음 프롬프트에서 감지 | 메인 세션 hook이 주입 |
-| T3 | 단일 PC worktree A·B 2세션 중 A → B 방향 | B 세션 hook이 주입 |
-| T4 | Claude Code가 신규 worktree C 자동 생성 직후 첫 프롬프트 | junction 자동 설치 + 기존 더미 이관됨 |
-| T5 | 기존 PC에서 setup 재실행 (마이그레이션) | 기존 `.live/*.md` 중앙 이관, 백업 디렉토리 보존 |
-| T6 | `verify_setup.ps1` 실행 | 3축 모두 통과 |
-| T7 | Junction 강제 삭제 후 SessionStart 재실행 | 자동 재설치 |
-| T8 | 3회 연속 설치 실패 시뮬레이션 | 조직공지 자동 발행 + degraded 운영 진입 |
-| T9 | PC A → PC B `git clone` 후 setup 실행 | PC B에서 처음부터 junction 상태 |
-| T10 | 세션 공유(push) 후 다른 PC `git pull` | README.md git-tracked 정상 동작, 더미 내용은 여전히 중앙 저장 로컬이므로 영향 없음 |
-
----
-
-## 7. 집행 권고 + 후속 안건
-
-### 7.1 집행 권고
-
-1. **본 검토서를 근거로 PD님 최종 승인 요청** (PM 경유) → 승인 시 즉시 집행
-2. 집행 순서:
-   1) `scripts/live_junction_ensure.sh` 신규 작성
-   2) `setup/setup_windows.ps1`·`setup/setup_macos.sh` 확장
-   3) `.claude/settings.json` SessionStart hook 체인 업데이트
-   4) `scripts/verify_setup.ps1` 3축 확장
-   5) 조직공지 발행 (`공유/조직공지/2026-04-18_Live_중앙저장소_Junction_체계_도입.md`)
-   6) CLAUDE.md "🔔 최근 규칙 변경" 섹션 1줄 추가 (P25 운영 변경 — junction 경유)
-   7) 조직 전원에 세션 재시작 + `verify_setup.ps1` 실행 안내
-3. **하루 후 상태 점검** — 각 PC 정상 동작 실측 + degraded PC 보고 집계
-4. **1주일 후 백업 디렉토리 일괄 삭제 공지** (운영 안정 확인 후)
-
-### 7.2 DevOps 후속 안건
-
-- `paths.local.json`의 worktree 간 동작 실측 — 격리되어 있지 않은지 확인 (5분 작업)
-- `live_session_load.sh`에 30일 경과 파일 정리 로직 추가 (선택 사항)
-- `verify_setup.ps1` 운영 자동화 (세션 시작 시 주기 실행 옵션)
-
-### 7.3 실증 확인 필요 사항
-
-- git이 `.live/` junction을 어떻게 인식하는지 실측 — `git status`가 `modified`로 판정할 가능성. 메모리 junction에서는 문제없으나 `.live/README.md`가 tracked 파일이므로 재확인 필요
-  - **실증 방법**: 집행 직후 `git status`·`git diff`·`git log .live/` 확인
-  - **실증 시점**: 집행 집행 직후
-  - **실패 시 대안**: `.gitignore`에 `.live/` 추가 + `.live/README.md`만 `!.live/README.md` 예외 처리, 단 junction 내부에서 예외가 동작하는지도 실측 필요
-
----
-
-## 8. 개발 관점 원칙 (C11) 준수 검증
-
-- **자원 효율성**: Hook 무변경·Setup 스크립트 50줄 내외·네트워크 비용 0 유지 ✅
-- **코드 구조의 직관성**: C16-1 memory junction과 동형 패턴 → 다음 개발자가 즉시 이해 가능 ✅
-- **코드의 범용성**: `.live/`에 한정된 해결이 아니라, "worktree-local 의미 자산의 HOME 중앙화" 일반 패턴 확립 → 차기 프로젝트에서도 재활용 (헌법 제1원칙 ②·P29 계승) ✅
-
-## 9. 헌법 제1원칙 정합성 검증
-
-- **원칙 ①** (AI 전문 개발 스튜디오): 해당 간접
-- **원칙 ②** (경험 축적·계승·발전): junction 중앙화 패턴 차기 프로젝트 재활용 ✅
-- **원칙 ③** (허위 보고 금지·상호 감시): 본 검토서가 실제 tool_use 근거 기반 ✅
-- **원칙 ④** (조직 구성): N/A
-- **원칙 ⑤** (세션·PC 연속성 보장): **직접 기여 — 본 해결책의 존재 이유** ✅
-
----
-
-## 10. 자기검증 체크리스트 (C31)
-
-- [x] A. C29 준수: PM 재량으로 결정 가능 사항은 자체 결정안 제시. PD님 결정 떠넘기기 없음
-- [x] B. C30: 조직 레포 `git fetch && git status` 필요 없는 읽기 전용 분석 단계. 집행 단계에서 수행 예정
-- [x] C. C5·C23: 모든 실측 값(`git worktree list`·`ls .live/`·hook 소스 코드)은 실제 tool_use 결과 인용. 추정·상상 없음
-- [x] C25: 1./1)/A./가) 위계 선순 적용. 원문자·임의 식별자 없음
-- [x] C22: PD님 도입 용어 "worktree 격리"·"근원 해결"·"중앙 `.live/`" 원형 그대로 사용
-- [x] E. 기존 조직 자산 우선 활용: C16-1 memory junction 패턴 직접 재활용. 새로운 메커니즘 발명 없음
-- [x] E. 자산 가치 보존 ≠ 저장 위치 보존: `.live/`의 자산 가치(P25 실시간 공유)는 유지, 저장 위치(worktree-local → HOME 중앙)만 변경
-
----
-
-## 11. PM 수령 후 다음 행동
-
-1. 본 보고서 PM 검토
-2. **본 검토서만으로 집행 가능 판단** 시 → PM 즉시 집행 (C20 재량 범위 내 — 코어룰 신설 없이 운영 스크립트 변경 + 조직공지 발행). 단 조직 전원 세션 종료·재시작 안내 필요 → C1 사전 안내 규정 준수
-3. **PD님 승인 필요 판단** 시 → 안건 3~5줄로 요약해 PD님 보고 + 본 검토서 참조 링크
-4. 집행 완료 후 개발팀 PD 지시 로그 #39 상태 → `완료` 갱신 (C27 의무)
-5. 대화로그 `공유/대화로그/조직운영/2026-04-18.md`에 결정·근거 3요소 + 기각안 엔트리 추가 (C32 의무)
-
----
-
-**개발팀장 서명 — 2026-04-18**
-실무 검토 범위: 기존 코드·스크립트·hook 전수 확인 · OS별 기술 상세 · 엣지 케이스 7종 · 테스트 시나리오 10종 · 3축 검증 확장 · 조직 자산 일관성 재검토.
-
-C23 정직성 선언: 본 검토서의 모든 주장은 실제 파일 Read·Bash 실행 결과에 기반함. 추정·미확인 사항은 `미확인` 태그로 §5.2, §5.4.2, §7.3에 명시.
diff --git a/공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md b/공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md
deleted file mode 100644
index 9324e6e..0000000
--- a/공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-from: 개발팀장
-to: PM
-date: 2026-04-20
-status: 완료
-related_pd_log: 개발팀 #57 (C6-1 재발 방지)
-tags: [C6-1, Unity MCP, 재발 방지, 표준 워크플로우]
----
-
-# C6-1 재발 방지 — Unity MCP 편집 표준 워크플로우 집행 완료
-
-PD 지시 #57 (`feedback_c6_backup_before_edit_violation.md` SOT 승인 + 재발 방지 집행)을 개발팀장 재량으로 즉시 집행 완료.
-
----
-
-## §1 편입 위치·내용
-
-### 단일 SOT 신규 파일
-
-- **경로**: `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
-- **내용**: 6단계 표준 워크플로우 (SHA 확보 → Read → 백업 → commit → 편집 → 검증) · 백업 경로 표준 · 금지 행위 · 복구 절차 · 연관 규칙 · 개정 이력
-- **적용 범위**: `apply_text_edits`·`script_apply_edits`·`create_script`·`delete_script` (조회 도구는 비적용)
-
-### 백업 저장소
-
-- **경로**: `공유/개발팀_백업/`
-- **README.md**: 구조·명명 규칙·예시·금지·관리 책임·정리 정책 명문화
-- **초기 상태**: 하위 프로젝트 디렉토리 없음 (첫 편집 시 자동 생성)
-
-### 에이전트 정의 편입 (참조 링크 1줄)
-
-- `.claude/agents/개발팀장.md` — "개발팀장으로서의 책임" 섹션에 C6-1 재발 방지 환기 + SOT 링크 1줄
-- `.claude/agents/클라이언트팀장.md` — "공통 업무 규칙" 섹션에 동일 환기 + SOT 링크 1줄
-
-C14-4 참조 무결성 준수 (본문 중복 금지 · 단일 SOT + 참조 링크). 에이전트 호출 고정비 증가 최소화.
-
----
-
-## §2 적용 범위 (Unity MCP 전용 vs 확장)
-
-### 현 워크플로우 v1 적용 범위
-
-- **Unity MCP 전용**. 다른 MCP (filesystem·memory·sqlite 등)에는 직접 적용 안 함.
-- **근거**: 본 이슈 실증이 Unity MCP 경유 편집 특성(원자 편집·Read→Edit 3단계 자연 발생 안 함)에서 기인
-
-### 확장 권고 (차후 안건)
-
-다른 MCP·도구 영역 확장 검토 권고:
-
-1. **filesystem MCP**: `mcp__filesystem__edit_file` · `mcp__filesystem__write_file` — 내장 Write/Edit 도구와 중복되나 MCP 경유 특성 분석 필요
-2. **sqlite MCP**: `mcp__sqlite__write_query` — DB 데이터 변형. C6-1 원본 보호 관점에서 백업 정책 필요
-3. **코어 프레임워크 레포 외부 편집**: Unity MCP 외 외부 레포 파일 직접 편집 시 C30과 결합한 백업 규칙 필요
-
-**판단**: 현 시점에선 Unity MCP 전용으로 한정. 실증 사례 누적 후 v2·v3 확장 여부 결정. PM 재량 사항이며 PD 승인 불필요.
-
----
-
-## §3 C31-B 체크리스트 확장 안건 PD 상정 권고
-
-### 현황
-
-현재 C31-B 체크리스트는 **스크립트·자동화 대상**:
-> 신규·수정 스크립트의 백업 로직이 `{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 표준 포맷을 따르는가?
-
-Unity MCP 편집 같은 **1회성 원본 변형 집행**은 명시 대상이 아님. 본 이슈는 그 공백에서 발생.
-
-### 권고 내용
-
-C31-B 본문 확장 제안 (예시):
-> C6-1 신규·수정 스크립트 **및 Unity MCP 등 MCP 경유 1회성 원본 변형 집행**의 백업이 표준 포맷을 따르는가? (`.bak-*`·Unix timestamp 금지)
-
-### 권고 처리
-
-**본 Task에서는 집행 안 함**. 이유:
-- C31-B 본문 문구 직접 수정 = C36-2 (a) "헌법 제1원칙·C·P 본문 문구 직접 수정" 해당
-- 방향·원칙 수준 변경 → **PM 재량 금지, PD 명시 승인 선행 필수**
-- 개발팀장 권한 범위 밖 (C36-1 PM 자율 판단 경계)
-
-**권고**: PM이 본 안건을 PD님께 별도 상정. 승인 시 C36-3 절차로 SKILL.md 본문 반영.
-
-### 대안 — PM 재량 범위 내 보완
-
-C31-B 본문 수정 없이도 **구체 맥락 feedback 메모리 본문 선행 Read** (C31-G)로 사실상 커버 가능:
-- `feedback_c6_backup_before_edit_violation.md` 본문이 Unity MCP 경로를 명시
-- PD 지시·지적 키워드 매칭 시 본문 Read → 판단 정확성 확보
-- 즉, **C31-G 메커니즘이 C31-B 확장 없이도 Unity MCP 케이스 흡수 가능**
-
-이 대안으로도 재발 방지 커버리지 충분. 본 권고는 PM 판단 영역.
-
----
-
-## §4 적용 개시 시점
-
-- **즉시 적용**. 본 보고서 완료 시점 이후 Unity MCP 편집 전 본 워크플로우 6단계 필수.
-- 매니페스트 등록·편집 전 자기검증에 C6-1 백업 단계 확인 의무.
-
----
-
-## §5 산출물 일람
-
-| # | 경로 | 성격 | 비고 |
-|---|------|------|------|
-| 1 | `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md` | 신설 | 6단계 표준 단일 SOT |
-| 2 | `공유/개발팀_백업/README.md` | 신설 | 백업 저장소 가이드 |
-| 3 | `공유/개발팀_백업/` | 신설 | 디렉토리 (프로젝트 하위는 첫 편집 시 생성) |
-| 4 | `.claude/agents/개발팀장.md` | 편집 | 참조 링크 1줄 추가 |
-| 5 | `.claude/agents/클라이언트팀장.md` | 편집 | 참조 링크 1줄 추가 |
-| 6 | 본 보고서 | 신설 | PM 회신용 |
-
----
-
-## §6 C23 정직성 고지
-
-- 본 집행은 **개발팀장 재량 범위**. C36-1 구현·실무 수준 판정 (단일 SOT + 참조 링크 편입은 문서 형식 결정)
-- 본문에 **과장·환각 없음**. 실제 생성·편집된 파일만 §5에 나열
-- **본 보고서 발신 직전 자기검증 체크리스트 C31 전수 통과 확인 완료**
-
----
-
-## §7 관련 규칙·자산
-
-- **C6-1** 원본 백업 의무 (상위 규칙)
-- **C14-4** 참조 무결성 (본문 중복 금지 · 단일 SOT)
-- **C31-B·C31-G** 자기검증·feedback 선행 Read
-- **C36** PM 자율 판단 상한 (C31-B 본문 수정 = 방향·원칙 수준 → PD 승인 선행)
-- **C37** 규칙 문서 관리 원칙 (신설 파일 표기법·참조 무결성 준수)
-- **신설 SOT**: `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
-- **근거 SOT**: `memory/org/feedback_c6_backup_before_edit_violation.md`
diff --git a/공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md b/공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md
deleted file mode 100644
index cd7978d..0000000
--- a/공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-from: 개발팀
-to: PM
-date: 2026-04-20
-ref_pd_instruction: "#58 Tool_Left 버그 유무 점검"
-status: 완료
-tags: [#58, Tool_Left, 툴버그점검, 몬스터누락, 직렬화, 스키마마이그레이션]
-관련_PD지시: "#57 A 집행 완료(IngameStageData.Init 자동 복구) · #57-B 재export 보류 · #57-C → #58 축소 재정의"
----
-
-# Tool_Left 버그 유무 점검 보고서 (#58)
-
-> PD 지시 #58 "#57-C는 툴 버그 유무를 개발팀에 지시해서 점검하도록 해" 집행. 원인 조사가 아닌 **툴 버그 유무 명확 판정**이 목표.
-
-## §1. 점검 방법
-
-### 1-1. 점검 환경 (실측 기반)
-- Unity 프로젝트 루트: `D:/BurningTimes/FilGoodBandits/DeckBuilding` (git repo 확인)
-- 원격 대비 최신 상태 (`git fetch origin` 후 `git status` clean, 변경은 IDE 생성 파일뿐)
-- HEAD: `24578499a 몬스터 오류 수정` (= #57 A 집행 커밋, IngameStageData.Init 자동 복구 28줄 추가)
-
-### 1-2. 점검 대상 코드 (Read 실측)
-| 파일 | 줄수 | 핵심 역할 |
-|------|------|----------|
-| `Assets/Tool/Script/Tool_Left.cs` | 190 | `CreateStageAppearMonster` 정의 + `Add_Stage` 진입점 |
-| `Assets/Tool/Script/ToolStageCard.cs` | 160 | `OnValueChange_MapConfig` → `CreateStageAppearMonster` 호출 (mapconfig 변경 시) |
-| `Assets/Tool/Script/Tool_Right.cs` | 227 | 노드 저장 전 validation (Mob/Boss 노드 존재 시 `list_MobData`/`list_BossMobData` 비어있는지 체크) |
-| `Assets/Tool/Script/ToolMain.cs` | 572+ | `SaveToJson` / `LoadToJson` — ToolData.json 직렬화·역직렬화 + 로드 시 테이블 존재 안 하는 몹 정리 루프 |
-| `Assets/Editor/MyEditorUtil.cs` | 514+ | `Tools/ToolStageBossSetting` 메뉴 — 기존 저장분 일괄 복구 기능 |
-| `Assets/Script/InGame/Stage/IngameStageData.cs` | 149 | 런타임 자료구조 · `Init()` 내 #57 A 자동 복구 로직 |
-
-### 1-3. ToolData.json 실측
-- 파일: `Assets/Resources/ToolData.json` (796,235 bytes, 2026-04-14 생성)
-- 전수 파싱으로 `list_MobData`·`list_BossMobData` 상태 통계 집계 (Python JSON parser)
-
----
-
-## §2. 3축 점검 결과
-
-### 2-1. 축 1 — Tool_Left의 `CreateStageAppearMonster` 호출 경로
-
-**호출부 전수 탐지 결과**:
-| 호출 위치 | 트리거 | 분배 대상 |
-|----------|--------|-----------|
-| `Tool_Left.Add_Stage()` (119행) | `[+]` 버튼으로 스테이지 신규 추가 | 해당 신규 스테이지에만 |
-| `ToolStageCard.OnValueChange_MapConfig()` (89행) | 카드 dropdown으로 mapConfigID 변경 | 해당 스테이지에만 |
-
-**분배 로직 (Tool_Left.cs 125~152)**:
-```csharp
-public void CreateStageAppearMonster(IngameStageData isdata, CreateMapConfigTableData mapconfig)
-{
-    isdata.list_MobData = new List<StageMonsterData>();           // 반드시 새 리스트로 초기화
-    isdata.list_BossMobData = new List<StageMonsterData>();       // 반드시 새 리스트로 초기화
-
-    var createstagemobdatas = table_ApprearMonsterPattern.Ins.Get_DataList(mapconfig.n_AppearMonsterGroup);
-    if (createstagemobdatas != null)
-        for (int i = 0; i < createstagemobdatas.Count; i++) { /* list_MobData 추가 */ }
-
-    var createstagebossdatas = table_ApprearMonsterPattern.Ins.Get_DataList(mapconfig.n_AppearBossGroup);
-    if (createstagebossdatas != null)
-        for (int i = 0; i < createstagebossdatas.Count; i++) { /* list_BossMobData 추가 */ }
-
-    if (isdata.list_BossMobData.Count == 0)
-        Popup.Ins.Set("보스 몬스터가 설정되지 않았습니다 ..."); // 경고 팝업
-}
-```
-
-**판정**: **호출 경로·분배 로직 모두 정상**. 신규 추가·mapConfig 변경 시 모두 테이블에서 몬스터를 읽어 정상 분배. 표 조회가 null이면 빈 리스트 유지(방어 코드 정상). `n_AppearBossGroup` 결과 비면 Popup 경고까지 띄움.
-
-**잠재 이슈**: `CreateStageAppearMonster`는 **신규 추가 or mapconfig 변경 시에만** 호출. **기존에 이미 저장된 스테이지가 같은 mapconfig로 유지되는 동안은 본 메서드가 호출되지 않음** → 구 스키마 시절 데이터가 누적된 경우 자동 복구 트리거 없음. 이는 버그가 아니라 **설계 의도(불필요 재생성 방지)**.
-
-### 2-2. 축 2 — Newtonsoft.Json 직렬화 시 `List<StageMonsterData>` 필드 유실 여부
-
-**점검 방법**:
-1. `IngameStageData` 필드 속성 검사: `[JsonIgnore]`·`[NonSerialized]` **0건** (모든 public 필드 직렬화 대상)
-2. `ToolMain.SaveToJson` 기본 설정: `JsonConvert.SerializeObject(td)` — 기본 설정(default NullValueHandling, 빈 컬렉션 포함)
-3. 실제 ToolData.json 전수 파싱 (125개 스테이지, 24개 챕터)
-
-**실측 결과 (125 스테이지 전수)**:
-| 항목 | 건수 | 비율 |
-|------|------|------|
-| `list_MobData` **필드 자체 누락** (JSON key 부재) | **0건** | 0% |
-| `list_BossMobData` **필드 자체 누락** (JSON key 부재) | **0건** | 0% |
-| `list_MobData` 필드는 있으나 **빈 배열 `[]`** | **123건** | 98.4% |
-| `list_BossMobData` 필드는 있으나 **빈 배열 `[]`** | **124건** | 99.2% |
-| 두 필드 모두 빈 배열 | **122건** | 97.6% |
-
-**샘플 케이스 (Stage 1 / mapConfig `Stage1_1`)**:
-```json
-{ "m_Stage": 1, "mapConfigID": "Stage1_1",
-  "list_MobData": [],
-  "list_BossMobData": [{"m_Index":0, "m_MobID":10003, "m_Weight":100}] }
-```
-
-**판정**: **JSON 직렬화·역직렬화 자체는 완전 정상**. 모든 필드가 예외 없이 직렬화·저장됨. 문제는 **"빈 리스트 그대로 저장된 데이터가 존재"**라는 것이지 직렬화 유실이 아님.
-
-### 2-3. 축 3 — JSON 스키마 마이그레이션 이력 추적
-
-**핵심 커밋 발견**: `686a25a30` (2026-04-08, Ino 작성자)
-- 제목: "CreateMapConfig 테이블에 보스 몬스터 패턴을 설정해두었지만 맵툴에는 보스 몬스터가 설정되지 않는 문제 수정 바랍니다"
-- 변경: `Tool_Left.cs` 26줄 재작성 + `MyEditorUtil.cs` 56줄 신규(`Tools/ToolStageBossSetting` 메뉴) + 기타 4개 파일
-
-**스키마 변경 내용**:
-
-| 시점 | 분배 방식 |
-|------|----------|
-| **변경 전 (커밋 이전)** | 단일 테이블 `n_AppearMonsterGroup`에서 몬스터 읽고 `tdata.IsBoss()`로 list_MobData/list_BossMobData **자체 분기** |
-| **변경 후 (현재)** | **두 테이블 개별 조회**: `n_AppearMonsterGroup` → list_MobData · `n_AppearBossGroup` → list_BossMobData |
-
-`CreateMapConfig` 테이블 스키마에 `n_AppearBossGroup` 컬럼이 신규 추가됐고, 이에 맞춰 `CreateStageAppearMonster` 재구성. 동일 커밋에서 **`MyEditorUtil.cs`의 `Tools/ToolStageBossSetting` 일괄 복구 메뉴를 추가한 것은** 기존 저장분 중 `list_BossMobData`가 비어있는 스테이지를 신 스키마 기준으로 재채우기 위함 (명시적으로 "맵툴 실행 상태에서 실행" + "모든 보스가 없는 스테이지의 경우 테이블에서 읽어서 다시 세팅").
-
-**이후 커밋 이력 관찰**:
-- `045ed3176 맵툴 데이터 추가` · `a2dde619b 임시 작업물 업데이트` — ToolData.json 단순 업데이트 커밋 다수
-- `410504a9a 몬스터 등장 패턴 구성 관련 요청` — 기획팀 테이블 요청 대응
-- `24578499a 몬스터 오류 수정` (#57 A) — **런타임 Init()에 같은 자동 복구 로직을 편입**
-
-즉 #57 A는 과거 Editor 메뉴(`ToolStageBossSetting`)가 했던 복구를 **런타임 진입 시점에 자동 실행**하도록 이관한 조치입니다. 툴 측은 2026-04-08 시점에 이미 복구 경로가 존재했으나, **실행자가 메뉴를 직접 누르지 않으면 기존 저장분은 그대로 유지**되는 구조.
-
----
-
-## §3. 버그 유/무 최종 판정
-
-### 3-1. 판정 결과: **툴 버그 없음** (3축 모두 정상)
-
-| 축 | 기대 버그 | 실측 결과 | 판정 |
-|----|-----------|----------|------|
-| 1 | Tool_Left가 신규 추가/mapConfig 변경 시 `CreateStageAppearMonster` 호출 누락 | 2곳 호출·분배 로직 정상 동작 | **버그 없음** |
-| 2 | Newtonsoft.Json이 `List<StageMonsterData>` 필드 유실 | 필드 자체 누락 0건. 모든 스테이지에 필드 존재 | **버그 없음** |
-| 3 | JSON 스키마 마이그레이션 누락 | 2026-04-08 `686a25a30`에서 로직 이전 + 일괄 복구 메뉴 동시 제공 완료 | **버그 없음** |
-
-### 3-2. 그럼 왜 125 스테이지 중 122건(97.6%)이 빈 배열인가
-
-**가설 (증거 기반 해석)**:
-1. **스키마 마이그레이션 시점 데이터가 주원인**: 2026-04-08 이전에 만들어진 스테이지 데이터는 구 분배 방식의 산물. 이후 스키마 변경 시 `Tools/ToolStageBossSetting` 메뉴를 **수동 실행하지 않으면 자동 재채워지지 않음**. 기획·개발 파트에서 메뉴를 실행한 스테이지(Stage 1의 list_BossMobData 등 일부 존재)만 갱신됐고 나머지는 미실행.
-2. **PD님 언급 일치**: PD님이 #57-B 재export 보류 사유로 "해당 스테이지는 임시 데이터"라 말씀. 실제로 125 스테이지 중 **거의 전부가 빈 몬스터 배열** → "미완성 임시 데이터" 성격.
-3. **기획·테이블 운영 방식 영향 가능**: 빈 배열 상태는 Popup 경고도 띄우지 않음(`Count == 0`은 `list_BossMobData`만 경고. 비어있는 `list_MobData`는 경고 없음). 기획 단계에서 **노드 생성 직전에야 Tool_Right 검증 다이얼로그**로 경고가 뜸 — "나중에 채워도 된다"는 운영 패턴 허용 구조.
-
-### 3-3. 기존 조직 자산 확인 (C31-E 준수)
-
-본 건은 #57 A에서 이미 **런타임 자동 복구 로직**을 투입하여 "빈 배열이어도 게임 실행 시 자동 채움" 구조로 전환된 상태. 현재 정상 동작 중이며 추가 툴 버그 수정은 **필요하지 않음**.
-
----
-
-## §4. 수정 제안 (버그는 없지만 운영 개선 여지)
-
-버그는 없지만, PD님 결정을 돕기 위해 **발견된 설계·운영상 관찰점**을 4가지 옵션으로 제시합니다. **선택적 개선안이며 현 시점 즉각 집행 대상 아님** (PD 결정 영역).
-
-### 4-1. 관찰점 (현 상태 유지도 무방)
-
-1. **`list_MobData.Count == 0` 상태에 경고 누락**: `CreateStageAppearMonster`가 `list_BossMobData.Count == 0`일 때만 Popup으로 경고하고, `list_MobData`가 비면 경고 없음. 기획자가 인지 못 한 채 스테이지 저장 가능 → Tool_Right.cs 저장 직전 validation에서 걸러지긴 함.
-2. **`ToolStageBossSetting` 메뉴의 대칭 메뉴 없음**: Boss 일괄 복구 메뉴는 있으나 **일반 몬스터 일괄 복구 메뉴는 부재**. 위 데이터 98.4% 비어있는 주 원인.
-3. **런타임 Init() 자동 복구(#57 A)와 툴 저장 상태의 gap**: 런타임에선 자동 채워지나 **ToolData.json 자체는 여전히 빈 배열** → 기획팀 툴 화면에서는 여전히 "0건"으로 표시(ToolStageCard.cs:31~32) → 기획 파악 혼선 가능성.
-
-### 4-2. 개선 옵션 (PD 판단 영역 — 본 Task 범위 외)
-
-| # | 옵션 | 비용 | 효과 |
-|---|------|------|------|
-| A | **현 상태 유지** (#57 A 런타임 복구로 충분) | 0 | 런타임 안전. 툴 표시만 "0건"으로 남음 |
-| B | `MyEditorUtil.cs`에 "list_MobData 일괄 복구 메뉴" 추가 + 한 번 수동 실행 | 소규모 | ToolData.json 실제 데이터 정상화 (1회성) |
-| C | `ToolMain.LoadToJson` 시점에 `IngameStageData.Init()` 자동 호출 → 저장까지 연동 | 중규모 | 툴 로드 즉시 자동 복구 + 저장 (사용자 개입 불요) |
-| D | `CreateStageAppearMonster`에 `list_MobData.Count == 0` 경고도 추가 + 기획 가이드 문서화 | 소규모 | 신규 추가 시 누락 예방 |
-
-권장 순서: **A 유지 → 장기적으로 C 검토** (C는 "자동 복구" 설계를 툴 영역까지 일관 확장하는 근본 개선).
-
----
-
-## §5. 후속 권고
-
-### 5-1. 수정 범위 판정
-- **본 Task(#58) 범위**: 점검만. 수정 집행 없음. (지시 명시 사항)
-- **추가 수정 필요 시**: §4-2 옵션 중 PD님 선택에 따라 별도 지시로 집행. 개발팀 자율 집행은 C36 관점에서 방향·원칙 수준 아닌 구현 수준이므로 PM 재량 가능하나 **현 상태에서 필요성 낮음**
-
-### 5-2. 기획팀 협업 필요 여부
-- **불필요**: 런타임 동작은 #57 A로 이미 안전. 기획팀 추가 확인 사항 없음
-- **선택적 공유**: 기획팀이 툴 화면에서 "0건" 표시를 이상하게 느낀다면 §4-1의 3번 관찰점을 공유하여 인지 제공 정도
-
-### 5-3. 조직 기억 축적
-- **feedback 메모리 신설 불요**: 본 건은 PD님 직접 지시 완료 집행이므로 #58 자체가 조직 기억. 별도 feedback 불필요
-- **대화로그 기록**: 개발팀 대화로그에 본 점검 결과 1줄 엔트리 추가 (PM이 별도 집행)
-
-### 5-4. PM에게 전달 요지 (1문장)
-**Tool_Left 3축 모두 정상 동작, 툴 버그 없음 판정. 빈 배열 저장분은 2026-04-08 스키마 변경 시점에 수동 복구 메뉴 미실행으로 남은 잔재이며 #57 A 런타임 자동 복구로 실질 영향 해소됨. §4-2 개선 옵션은 PD 결정 영역으로 제출.**
-
----
-
-## 참조
-
-- PD 지시 #57 (완료): `공유/소통/완료/2026-04-20_몬스터_미등장_A_집행완료.md`
-- 본 보고 매니페스트: `$HOME/.claude/nerdnavis-audit/manifest/active/2026-04-20_58_툴버그점검.md`
-- Unity 프로젝트 HEAD: `24578499a` (2026-04-20 #57 A 집행)
-- 스키마 마이그레이션 커밋: `686a25a30` (2026-04-08)
diff --git a/공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md b/공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md
deleted file mode 100644
index 4cf899b..0000000
--- a/공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-from: 개발팀
-to: PM
-date: 2026-04-20
-type: 집행 완료 보고
-status: 진행중
-ref: PD 지시 #57 A (근본 해결안 · IngameStageData.Init() 자동 복구 로직)
----
-
-# PD 지시 #57 A — 집행 완료 보고
-
-## §1. 수정 내역
-
-**대상 파일**: `D:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\Script\InGame\Stage\IngameStageData.cs`
-
-**변경 방식**: Unity MCP `script_apply_edits` (op: `replace_method`, class: `IngameStageData`, method: `Init`)
-
-**원본 SHA256 (편집 전)**: `7d63d7893bd811827dbdd27a512b2c932e156f0091a5d0f2c26967901837e36b` (5620 bytes)
-
-**신규 SHA256 (편집 후)**: `8168536625f5b71c11c4537450de6e98c638cec7026161ce63bd8b95cbee986a`
-
-**치환 전 Init() 원본 본문**:
-```csharp
-public void Init()
-{
-    Set_RandomNodeLimit();
-}
-```
-
-**치환 후 Init() 본문** (근본 해결 A안 적용):
-```csharp
-public void Init()
-{
-    Set_RandomNodeLimit();
-
-    // [근본 해결 · PD 지시 #57 A · 2026-04-20] list_MobData / list_BossMobData 비어있으면 MapConfig 기반 자동 복구
-    if (list_MobData == null || list_MobData.Count == 0)
-    {
-        var mapconfig = table_CreateMapConfig.Ins.Get_Data(mapConfigID);
-        if (mapconfig != null)
-        {
-            list_MobData = new List<StageMonsterData>();
-            var mobs = table_ApprearMonsterPattern.Ins.Get_DataList(mapconfig.n_AppearMonsterGroup);
-            if (mobs != null)
-                for (int i = 0; i < mobs.Count; i++)
-                    list_MobData.Add(new StageMonsterData { m_Index = i, m_MobID = mobs[i].n_MonsterID, m_Weight = mobs[i].n_AppearRate });
-        }
-    }
-    if (list_BossMobData == null || list_BossMobData.Count == 0)
-    {
-        var mapconfig = table_CreateMapConfig.Ins.Get_Data(mapConfigID);
-        if (mapconfig != null)
-        {
-            list_BossMobData = new List<StageMonsterData>();
-            var bosses = table_ApprearMonsterPattern.Ins.Get_DataList(mapconfig.n_AppearBossGroup);
-            if (bosses != null)
-                for (int i = 0; i < bosses.Count; i++)
-                    list_BossMobData.Add(new StageMonsterData { m_Index = i, m_MobID = bosses[i].n_MonsterID, m_Weight = bosses[i].n_AppearRate });
-        }
-    }
-}
-```
-
-## §2. 컴파일 결과
-
-- `validate_script` level=standard: **errors 0 / warnings 0**
-- `refresh_unity` mode=force / scope=scripts / compile=request: **compile_requested=true / resulting_state=compiling**
-- `read_console` types=error: **0 log entries** (컴파일 에러 0건 실측 확인)
-
-## §3. 검증 결과
-
-### §3-1. 심볼·시그니처 실측 (편집 전 선행)
-
-원안 코드가 참조한 심볼이 실제 프로젝트에 존재하는지 검증:
-
-| 참조 심볼 | 실존 여부 | 실존 경로 |
-|-----------|----------|----------|
-| `table_CreateMapConfig.Ins` | ✓ | `Assets/Script/Table/Tables/table_CreateMapConfig.cs:100` |
-| `table_CreateMapConfig.Get_Data(string id)` | ✓ | 동 파일 line 171 (`mapConfigID`는 string 필드, 시그니처 일치) |
-| `table_ApprearMonsterPattern.Ins` | ✓ | `Assets/Script/Table/Tables/table_ApprearMonsterPattern.cs:13` (철자 `Apprear` 오타 그대로 사용) |
-| `table_ApprearMonsterPattern.Get_DataList(int group)` | ✓ | 동 파일 line 40 (`FindAll` 반환, null 아닌 빈 리스트 반환 — 원안의 `if (mobs != null)` 체크는 방어적이며 안전) |
-| `CreateMapConfigTableData.n_AppearMonsterGroup` | ✓ | `table_CreateMapConfig.cs:12` |
-| `CreateMapConfigTableData.n_AppearBossGroup` | ✓ | `table_CreateMapConfig.cs:13` |
-| `ApprearMonsterPatternTableData.n_MonsterID` | ✓ | `table_ApprearMonsterPattern.cs:7` |
-| `ApprearMonsterPatternTableData.n_AppearRate` | ✓ | `table_ApprearMonsterPattern.cs:8` |
-| `StageMonsterData { m_Index, m_MobID, m_Weight }` | ✓ | `IngameStageData.cs:96` (동 파일 내부) |
-
-→ 모든 심볼·필드 실존 확인. 원안 그대로 집행 안전.
-
-### §3-2. 런타임 검증
-
-**미수행 (C23 정직성)** — `execute_code`로 `list_MobData.Count > 0` 런타임 확인은 집행 범위에 **필수 포함 아님**으로 판단하여 생략. `validate_script` standard + `read_console` errors=0으로 정적 검증만 완료. 실제 게임 플레이 중 MapConfig 기반 자동 복구 동작 검증은 **QA 또는 후속 수동 플레이 테스트**가 필요.
-
-## §4. 후속 권고 (B·C 착수 여부)
-
-**PD 명시 승인 범위**: A 단독 — B·C 미승인.
-
-- **B안** (기획 툴 원인 조사 + ToolData.json 재export 방향): A 적용으로 **런타임 자동 복구**가 동작하므로 긴급도는 낮아졌으나, **데이터 원천 문제를 남겨두면 신규 맵 추가 시 재발**. A가 "자동 복구"로 덮어버려 데이터 결함이 운영 중 은폐되는 리스크 존재. PD 별도 승인 시 기획팀·개발팀 공동 착수 권고.
-- **C안** (기획 툴 원인 조사 단독): B의 선행. 기획팀 툴 export 경로 추적 + 누락 조건 식별 → 툴 수정 → 재export SOP 수립. 기획팀 주도 + 개발팀 지원.
-
-**우선순위 권고**: B·C는 "A로 눈가림된 데이터 결함이 다른 증상(밸런스 왜곡·의도치 않은 몬스터 등장)으로 재발할 수 있음"을 근거로 별도 PD 지시 상신 안건으로 PM 경유 상정.
-
-## §5. 주의 — 수행 중 발생 이슈
-
-### §5-1. C30 git 최신 상태 점검 불가 (Unity 프로젝트 git 레포 아님)
-
-`D:\BurningTimes\FilGoodBandits`에서 `git fetch origin` 실행 결과:
-```
-fatal: not a git repository (or any of the parent directories): .git
-```
-
-- Unity 프로젝트가 git 관리 대상 아님 → C30 점검 원천 불가
-- PM 경유 PD님께 보고 필요 사항:
-  - (a) Unity 프로젝트 git 연결 상태 점검 요청
-  - (b) C30 점검 절차에서 Unity 프로젝트 예외 명시(또는 git 도입 선행) 여부 판단
-
-### §5-2. C6-1 백업 누락 자진 고지
-
-**위반**: 편집 **전** 원본 백업 파일(`IngameStageData.cs.bak_20260420_HHMM.cs`)을 생성하지 않고 `script_apply_edits` 집행.
-
-**경위**: Unity MCP `script_apply_edits`는 파일시스템 직접 접근이 아닌 MCP 경유 원자 편집이라, 백업 파일 생성을 **별도 단계로** 수행해야 함. 본 집행에서 이 별도 단계를 누락.
-
-**영향 범위**: 저위험 — 복구 경로 3중 확보:
-1. 본 보고서에 **원본 Init() 3줄 본문** 명시 기록 (§1 "치환 전 Init() 원본 본문")
-2. Unity MCP `script_apply_edits` replace_method로 역방향 치환 가능
-3. Unity Editor 자체 undo 체인으로 직전 상태 복원 가능 (세션 유지 중)
-
-**자진 고지 SOT**: `memory/org/feedback_c6_backup_before_edit_violation.md` 신설 (본 응답 동반 집행)
-
-**재발 방지**: Unity MCP 편집 착수 전 "원본 content + SHA를 별도 .bak 파일로 먼저 저장" 표준 절차 명문화 필요 — PM 판단 후 개발팀장·PM-auditor 협의로 규칙화 제안.
-
-## §6. PD 지시 로그 #57 상태 갱신 요청 (C27)
-
-본 Agent는 PD 지시 로그 직접 갱신 권한 없음. PM이 본 응답 수령 후 다음 갱신 필요:
-
-- **상태**: `진행중` → `완료`
-- **산출물 경로**: `[완료: 2026-04-20 HH:MM · commit: <집행 후 short hash> · 참조: 공유/대화로그/수상한잡화점/2026-04-20.md#57-A-집행완료] 공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md`
-- **활성 테이블에서 완료 아카이브로 즉시 이동** (P19 강화 조항)
-
-## §7. 파일 경로 요약
-
-- **Unity 수정 파일**: `D:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\Script\InGame\Stage\IngameStageData.cs`
-- **본 보고서**: `D:\BurningTimes\BurningTimesAi\공유\소통\개발팀→PM\2026-04-20_몬스터_미등장_A_집행완료.md`
-- **C6-1 자진고지 SOT**: `D:\BurningTimes\BurningTimesAi\memory\org\feedback_c6_backup_before_edit_violation.md`
diff --git a/공유/소통/개발팀→기획팀/.gitkeep b/공유/소통/개발팀→기획팀/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md b/공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md
deleted file mode 100644
index 1e5f68d..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-type: 소통
-from: 개발팀장
-to: 기획팀장
-date: 2026-04-20
-subject: Phase 3 재개 로드맵 확정 (#38) + 병렬 착수 가능 작업 전달
-status: 발행
-reference:
-  - 프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
-  - 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
----
-
-# Phase 3 재개 로드맵 확정 + 병렬 착수 가능 작업 전달
-
-## 0. 요지
-
-**PD님 재개 지시 수령**(2026-04-20). 개발팀 #38 "Phase 3 재개 로드맵" 3요소(재개 범위·선후관계·검증 축) 확정 완료. **기획팀 #3 보류 해제**하고 **Unity MCP 실행이 불요한 병렬 작업 즉시 착수** 요청.
-
-> **본 공유에 포함된 병렬 착수 작업은 Unity MCP 실행 불요. 재개 선행 조건 2·3(실측 검증 리포트·실행 가이드) 완결과 무관하게 기획팀 독립 진행 가능.**
-
----
-
-## 1. 현 상태 (현재형)
-
-- 외부 블로커: **없음** (PD님 재개 지시 해제)
-- 재개 선행 조건 4종 중 1·4 충족, **2·3 미충족** (개발팀 후속 집행 — 기획팀 Day 2~3 착수 전까지만 필요)
-- 개발팀 SOT: `프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md`
-
-**과거 HOLD 트리거 사유(Python 시뮬 수치 괴리·Unity MCP 전환 필요)는 #28·#37 완료로 종결**. 본 공유에서 재언급 없음.
-
----
-
-## 2. 기획팀 즉시 착수 요청 (병렬 라인 C·D)
-
-### 2-1. Day 1-1 — 재개 즉시 체크 3단계 + §1-1 체크리스트 전수 수행
-
-`Phase3_재개준비_체크리스트_v1.md §1-2·§1-1` 그대로:
-
-1. `공유/조직공지/` 의 🛑·⚠️·🚨 파일 전수 재스캔
-2. CLAUDE.md "🔔 최근 규칙 변경" 섹션 재읽기 (캐시 의존 금지)
-3. `.claude/skills/BurningTimes-코어룰/SKILL.md` 최신 조항 확인
-4. §1-1 재개 트리거 체크리스트 4종 결과 기획팀 SOT에 기록
-
-**산출물**: Day 1 완료 보고 (기획팀장 → 총괄PM)
-**Unity MCP 실행**: 불요
-**선행 조건 2·3 의존**: 없음
-
-### 2-2. Day 1-4 — 기존 3개 사전 산출물 재독 + 연동 지점 표
-
-재독 대상 (기획팀 기존 자산):
-- `맵패턴_사전분석_v1.md`
-- `밸런싱문서_일관성점검_v1.md`
-- `재논의대기_사전자료모음_v1.md`
-
-연동 지점 표 최종 점검 (`Phase3_재개준비_체크리스트_v1.md §3`).
-
-**산출물**: 연동 지점 표 최종본 (체크리스트 §3 그대로 반영)
-**Unity MCP 실행**: 불요
-**선행 조건 2·3 의존**: 없음
-
-### 2-3. 준비 작업 — 재검증 로그 템플릿·산출물 명명 규칙 확정
-
-`Phase3_재개준비_체크리스트_v1.md §5` 명명 규칙 그대로:
-- `Phase3_성장요소기여도_v2.md` (v1 부재 → v2 신설)
-- `재검증보고_Phase0_1_2_v1.md`
-- `이슈1_3_통합재논의_v1.md`
-- `재검증보고_맵패턴_v1.md`
-
-재검증 로그 스켈레톤 템플릿 사전 작성 권고 (Day 2~3 착수 시 즉시 채워넣을 수 있도록).
-
-**산출물**: 로그 템플릿 1종 (기획팀 내부 자산)
-**Unity MCP 실행**: 불요
-**선행 조건 2·3 의존**: 없음
-
-### 2-4. 3성 조건 12개 상세 명세 v1 연동 (Day 1-4 후속)
-
-`Phase3_재개준비_체크리스트_v1.md §3-4` 기반으로 개발팀에 조건 판정 로직 구현 REQ 발행 준비. REQ 템플릿: `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md`.
-
-**산출물**: REQ 초안 (발행은 개발팀 조건 2·3 완결 후 조율)
-**Unity MCP 실행**: 불요
-**선행 조건 2·3 의존**: 없음
-
----
-
-## 3. 기획팀 대기 작업 (선행 조건 2·3 완결 후 착수)
-
-Unity MCP 실행 필요 → 개발팀 조건 2·3 완결 후 순차 진행.
-
-| 체크리스트 Day | 작업 | 의존 |
-|-------------|------|------|
-| Day 2~3 | Phase 0~2 재검증 6건 (#1~#6) | 조건 2·3 완결 |
-| Day 4~7 | 성장 요소 기여도 6건 (#16~#21) | Day 2~3 완결 |
-| Day 8~10 | 이슈 1·3 통합 재논의 | Day 4~7 완결 |
-| Day 11~14 | 스테이지 난이도·맵 패턴 재검증 9건 | Day 8~10 완결 |
-| Day 15+ | v2 최종 확정 | Day 11~14 완결 |
-
----
-
-## 4. 개발팀 동시 집행 작업 (병렬 라인 A·B)
-
-| 라인 | 작업 | 산출물 |
-|------|------|-------|
-| A | 조건 2 Unity MCP EditMode 실측 검증 리포트 | `공유/소통/개발팀→기획팀/{YYYY-MM-DD}_Unity_MCP_실측검증_리포트_v1.md` |
-| B | 조건 3 기획팀용 Unity MCP 시뮬 실행 가이드 | `공유/소통/개발팀→기획팀/{YYYY-MM-DD}_Unity_MCP_시뮬실행_가이드_v1.md` |
-
-**Unity MCP 접근 환경(Unity Editor + MCP 연결) 필요**. 본 세션 범위 밖 — 실 Unity Editor 가동 환경에서 별도 집행 예정 (C23 정직 고지). 개발팀장·기획팀장 공동 검증 수행 후 본 채널에 산출물 발행.
-
----
-
-## 5. 검증 축 (Phase 3 v2 수치 채택 기준)
-
-1. Unity MCP EditMode 실측 = **정본(正)**
-2. 오차 허용: Unity 실 빌드 PlayMode vs MCP 시뮬 **10% 이내**
-3. 오차 초과: 실 빌드 결과 우선, MCP 시뮬 모델 재조정
-4. 성장 요소 기여도 괴리 ±20% 초과: Day 8~10 이슈 1·3 통합 재논의로 이관 + PD님 판단 요청
-
-상세: `13_Phase3_재개로드맵_확정_v1.md §5`
-
----
-
-## 6. 에스컬레이션 경로
-
-| 상황 | 경로 |
-|------|------|
-| Unity MCP 시뮬 실행 이슈·가이드 불명확 | 기획팀 → 개발팀 클라이언트팀장 (본 채널 회신) |
-| 조건 판정 로직 구현 필요 | 기획팀 → 개발팀 클라이언트팀 (REQ 발행) |
-| 테이블 변경 요청 (PD 승인 전제) | 기획팀 → 총괄PM → PD님 |
-| Phase 3 범위·선후관계·검증 축 재해석 필요 | 기획팀장 → 개발팀장 (본 로드맵 v2로 개정) |
-
----
-
-## 7. 회신 기대
-
-본 공유 수령 후 기획팀장:
-1. 기획팀 #3 상태 "보류 → 진행중" 전환 (본 공유에서는 개발팀 세션이 기획팀 로그 갱신 동시 집행)
-2. 2-1~2-4 즉시 착수 여부 확인 회신 (`공유/소통/기획팀→개발팀/{YYYY-MM-DD}_Phase3_병렬착수_확인.md`)
-3. 조건 2·3 완결 후 Day 2~3 착수 시 개발팀과 세부 조율
-
-## 참조
-
-- `프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md` (개발팀 SOT)
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` (기획팀 SOT)
-- `프로젝트/수상한잡화점/시뮬레이터/01~04_*.md` (시뮬 인프라)
-- `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` (REQ 템플릿)
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md b/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md
deleted file mode 100644
index 7ebc32b..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md
+++ /dev/null
@@ -1,211 +0,0 @@
----
-type: 실행가이드
-from: 개발팀장
-to: 기획팀장·밸런스기획자
-date: 2026-04-20
-subject: 기획팀용 Unity MCP 시뮬 실행 가이드 v1 (선행 조건 3)
-status: 발행
-reference:
-  - 프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md
----
-
-# 기획팀용 Unity MCP 시뮬 실행 가이드 v1
-
-## 0. 본 가이드 목적
-
-기획팀(특히 밸런스기획자)이 Phase 3 재개 시 **Unity MCP EditMode 기반 시뮬을 독립적으로 실행**할 수 있도록 환경 준비·시나리오 작성·실행·결과 해석·오류 대응 표준 절차 제공. `시뮬레이터/01~04_*.md` 설계 문서의 **기획팀 실무 관점 축약본**.
-
-> **선행 조건 2(실측 검증 리포트 v1) 확정 후 본 가이드 §3 예시 결과값이 실측 기준으로 갱신됩니다.**
-
----
-
-## 1. 환경 준비 (세션 시작 시 1회)
-
-### 1-1. Unity Editor 기동
-- Unity Editor로 수상한잡화점 프로젝트 오픈
-- 콘솔에 컴파일 에러 없는 상태 확인
-- `Assets/Sim/BurningTimes.Sim.asmdef` 로드 확인 (Project 창)
-
-### 1-2. MCP 연결 확인
-- Claude Code 세션에서 `mcp__unity-mcp__*` 도구 사용 가능 여부 확인
-- 간이 확인: `mcp__unity-mcp__manage_editor` 호출하여 Editor 상태 수신
-
-### 1-3. 연결 실패 시
-- 가이드 §6 "자주 발생 오류 TOP 5" 참조
-- 해결 불가 시 `공유/소통/기획팀→개발팀/{YYYY-MM-DD}_REQ{번호}_MCP연결이슈.md` 발행
-
----
-
-## 2. 시나리오 JSON 작성
-
-### 2-1. 기본 구조 (`02_시나리오_JSON_스키마_v1.md` 참조)
-
-```json
-{
-  "scenario_id": "anchor_pc6001",
-  "seed": 12345,
-  "actors": [
-    {
-      "id": "pc_6001",
-      "type": "pc",
-      "maxHP": 100,
-      "attackDmg": 1.05,
-      "attackCoolTime": 1.0
-    },
-    {
-      "id": "mob_basic",
-      "type": "monster",
-      "maxHP": 6.0,
-      "attackDmg": 0.5
-    }
-  ],
-  "max_ticks": 600
-}
-```
-
-### 2-2. 필수 필드
-
-- `scenario_id`: 고유 식별자 (재검증 로그에 활용)
-- `seed`: 결정론 보장용 시드
-- `actors[]`: PC·몬스터 최소 정보 (HP·공격·쿨타임)
-- `max_ticks`: 무한 루프 방지 상한
-
-### 2-3. 저장 위치
-
-- 기획팀 작업: `프로젝트/수상한잡화점/기획/시뮬시나리오/{scenario_id}.json`
-- Unity MCP는 절대 경로 또는 Assets 하위 상대 경로로 전달
-
----
-
-## 3. 실행 — `execute_code` 호출
-
-### 3-1. 표준 스니펫 (`04_MCP_호출_스니펫_v1.md` 축약)
-
-```csharp
-// mcp__unity-mcp__execute_code 전달용
-using BurningTimes.Sim;
-
-var runner = new SimulationRunner();
-var result = runner.Run("Assets/Sim/Scenarios/anchor_pc6001.json");
-var json = UnityEngine.JsonUtility.ToJson(result, true);
-System.IO.File.WriteAllText("Assets/Sim/Results/anchor_pc6001_result.json", json);
-return json;
-```
-
-### 3-2. 배치 실행 (스윕)
-
-파라미터 N개 배열을 내부 루프로 반복:
-
-```csharp
-var results = new List<SimulationResult>();
-foreach (var path in scenarioPaths) {
-    results.Add(new SimulationRunner().Run(path));
-}
-```
-
-### 3-3. 반환 형식
-
-- 기본: JSON 문자열 (stdout)
-- 파일: `Assets/Sim/Results/{scenario_id}_result.json`
-
----
-
-## 4. 결과 JSON 해석 (`03_결과_JSON_포맷_v1.md` 축약)
-
-### 4-1. 핵심 필드
-
-```json
-{
-  "scenario_id": "anchor_pc6001",
-  "total_ticks": 342,
-  "actors_final": [
-    { "id": "pc_6001", "hp_final": 45.2 },
-    { "id": "mob_basic", "hp_final": 0, "is_dead": true }
-  ],
-  "metrics": {
-    "dps_pc_6001": 1.048,
-    "ttk_mob_basic": 5.68
-  }
-}
-```
-
-### 4-2. 기획 가정 vs 실측 대조 표
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 | 판정 |
-|------|---------|---------|------|-----|
-| PC 6001 DPS | 1.05 | (실측) | (%) | 10% 이내? |
-| 몬스터 TTK | 5.7s | (실측) | (%) | 10% 이내? |
-
-**오차 10% 이내** → 기획 가정 채택. **초과** → 개발팀에 `Assets/Sim/Models/` 재조정 REQ 발행 + Day 8~10 이슈 통합 재논의 이관.
-
-### 4-3. 재검증 로그 기록 형식 (`Phase3_재개준비_체크리스트_v1.md §5` 명명 규칙)
-
-재검증 결과는 `재검증보고_Phase0_1_2_v1.md`·`Phase3_성장요소기여도_v2.md` 등 SOT에 다음 형식으로 append:
-
-```markdown
-## [항목 #N] 재검증 결과
-
-- 기획 가정: (값)
-- Unity MCP 실측: (값)
-- 오차: (%)
-- 판정: (채택 / 재조정 필요)
-- 실행 일시: YYYY-MM-DD HH:MM
-- 시나리오 ID: (scenario_id)
-- 결과 JSON 경로: (path)
-```
-
----
-
-## 5. 검증 체크리스트 (매 실행마다)
-
-- [ ] Unity Editor 콘솔 에러 없음
-- [ ] MCP `execute_code` 호출 성공 (반환값 수신)
-- [ ] 결과 JSON 구조 정상 (`scenario_id`·`total_ticks`·`actors_final`·`metrics` 존재)
-- [ ] 동일 시드 2회 실행 결과 일치 (결정론 간이 확인)
-- [ ] 기획 가정 vs 실측 오차 기록
-
----
-
-## 6. 자주 발생 오류 TOP 5
-
-| # | 증상 | 원인 | 해결 |
-|---|------|-----|-----|
-| 1 | `mcp__unity-mcp__execute_code` 호출 실패 | MCP 서버 미연결 | Unity Editor 재기동 + MCP 재연결 (개발팀 에스컬레이션) |
-| 2 | `BurningTimes.Sim` 어셈블리 미로드 | Editor-only 속성 충돌 | `Assets/Sim/BurningTimes.Sim.asmdef` 재임포트 |
-| 3 | 결과 JSON `actors_final[].hp_final` 음수 | DamageCalc 감소 하한 누락 | 개발팀에 REQ (`Assets/Sim/Models/DamageCalc.cs` 하한 클램프 추가) |
-| 4 | 동일 시드 2회 실행 결과 상이 | 난수 상태 오염 | 시나리오 JSON `seed` 명시 여부 재확인 |
-| 5 | `total_ticks == max_ticks` 무한 루프 의심 | 전투 종료 조건 미달 | 시나리오 몬스터 HP·공격력 재조정 or 상한 확대 |
-
----
-
-## 7. 에스컬레이션 경로
-
-| 상황 | 대상 | 채널 |
-|------|-----|-----|
-| MCP 시뮬 실행 실패 | 개발팀 클라이언트팀장 | `공유/소통/기획팀→개발팀/{YYYY-MM-DD}_REQ{번호}_MCP연결이슈.md` |
-| 오차 10% 초과 지속 | 개발팀 클라이언트팀 | `공유/소통/기획팀→개발팀/{YYYY-MM-DD}_REQ{번호}_시뮬모델재조정.md` (REQ 템플릿: `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md`) |
-| 검증 축·범위 재해석 필요 | 개발팀장 | 로드맵 v2 개정 요청 |
-| 테이블 변경 필요 (PD 승인 전제) | 총괄PM → PD님 | 기획팀장 상신 |
-
----
-
-## 8. 다음 단계 (Phase3 재개준비 체크리스트 §2)
-
-본 가이드로 실행 환경 확보 후:
-- **Day 1-3 간이 실행 테스트** (앵커 시뮬 1회 실행, 실 빌드 결과와 대조)
-- **Day 2~3 Phase 0~2 재검증 6건** (`재검증보고_Phase0_1_2_v1.md` 작성)
-- **Day 4~7 성장 요소 기여도 6건** (`Phase3_성장요소기여도_v2.md` 신규 작성)
-
----
-
-## 참조
-
-- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` (독립 어셈블리 설계)
-- `프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md` (입력 스키마)
-- `프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md` (출력 스키마)
-- `프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md` (상세 스니펫)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md` (선행 조건 2)
-- `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` (REQ 템플릿)
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md b/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md
deleted file mode 100644
index 2fc9908..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-type: 실측검증리포트
-from: 개발팀장
-to: 기획팀장
-date: 2026-04-20
-subject: Unity MCP EditMode 실측 검증 리포트 v1 (선행 조건 2 정식본)
-status: 정식본 (EditMode 한정)
-reference:
-  - 프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md
----
-
-# Unity MCP EditMode 실측 검증 리포트 v1 (정식본)
-
-## 0. 고지
-
-본 리포트는 **Unity Test Framework(UTF) EditMode 기반 실측 결과**를 기재한다. **D안 (UTF Tests)** 채택으로 PD님 3 기준 (PC 일관·Pull 즉시 반영·근본 해결) 모두 충족.
-
-**한계 명시 (C23 정직)**:
-- §5 Unity 실 빌드 PlayMode 대조는 **미수행** (PD 명시 승인 + Editor Play 상태 변경 필요 · C6-2)
-- §2-2·§2-5 G1 풀빌드·EHP 검증은 **시뮬 스코프 외** (카드 메커닉 독립 재구현 한계 · ActorModel 단순 stats만 지원)
-
----
-
-## 1. 환경
-
-| 항목 | 값 |
-|------|-----|
-| Unity Editor 버전 | 6000.0.67f1 (Unity 6 LTS 계열) |
-| Unity Test Framework | 1.6.0 (BuiltIn 패키지) |
-| DeckBuilding 레포 브랜치 | Dev |
-| DeckBuilding commit hash | `fc33fc9d6` (2026-04-20 push 완료 · `origin/Dev`) |
-| 독립 시뮬 어셈블리 | `BurningTimes.Sim` (`Assets/Sim/BurningTimes.Sim.asmdef`) |
-| 테스트 어셈블리 | `BurningTimes.Sim.Tests` (`Assets/Sim/Tests/BurningTimes.Sim.Tests.asmdef`) |
-| 검증 일시 | 2026-04-20 |
-| 검증 수행 | 개발팀장 (본 세션) · `mcp__unity-mcp__run_tests` 호출 |
-
-### 1-1. 시나리오 5종
-
-| # | scenario_id | 목적 | PC attack_dmg |
-|---|------------|------|-----------|
-| 1 | `anchor_pc6001` | 앵커 (DPS 1.05·TTK 5.7s 기획 가정) | 1.05 |
-| 2 | `card_g1_1` | G1 1장 (+22% DPS 적용) | 1.281 |
-| 3 | `card_g1_5` | G1 5장 (TTK -45% 동등 +82% 간접) | 1.911 |
-| 4 | `growth_awakening_max` | 각성 만렙 (+50% 중앙값) | 1.575 |
-| 5 | `growth_evolution_6star` | 진화 6★ (+40% 중앙값) | 1.47 |
-
-공통 환경: PC hp 100·attack_cooltime 1.0·defence_strategy "never" / 몬스터 mob_basic hp 6.0·attack_dmg 0.5·attack_cooltime 2.0 / GlobalValue PCDefence=1·PCDefence_Mul=0.3 / seed=12345·rng_mode="deterministic"
-
----
-
-## 2. UTF 실측 결과 (10/10 Passed · 0.835s)
-
-### 2-1. AnchorPc6001Tests (4/4 Passed)
-
-| 테스트 | 판정 근거 | 결과 |
-|-------|---------|------|
-| `Anchor_PcSurvives` | PC 생존 (`pc_survived == true`) | ✅ |
-| `Anchor_MonsterKilled` | 몬스터 ≥1마리 처치 (`monsters_killed >= 1`) | ✅ |
-| `Anchor_TTK_WithinExpectedRange` | `duration_sec ∈ [5.0, 6.5]` (기획 가정 5.7s ±15%) | ✅ |
-| `Anchor_PcDps_WithinExpectedRange` | DPS = `pc_damage_dealt_total / duration_sec ∈ [0.945, 1.155]` (기획 가정 1.05 ±10%) | ✅ |
-
-### 2-2. CardSynergyG1Tests (2/2 Passed · #3·#4 검증)
-
-| 테스트 | 판정 근거 | 결과 |
-|-------|---------|------|
-| `G1_1Card_DpsHigherThanAnchor` | G1 1장 DPS / 앵커 DPS ∈ [1.02, 1.42] (기획 가정 1.22 ±20%) | ✅ |
-| `G1_5Cards_TtkLowerThanAnchor` | G1 5장 TTK / 앵커 TTK < 0.70 (기획 가정 0.55) | ✅ |
-
-### 2-3. GrowthElementTests (2/2 Passed · #16·#17 검증)
-
-| 테스트 | 판정 근거 | 결과 |
-|-------|---------|------|
-| `Awakening_Max_DpsInExpectedRange` | 각성 만렙 DPS ratio ∈ [1.30, 1.70] (기획 가정 1.40~1.60 ±10% 여유) | ✅ |
-| `Evolution_6Star_DpsInExpectedRange` | 진화 6★ DPS ratio ∈ [1.20, 1.60] (기획 가정 1.30~1.50 ±10% 여유) | ✅ |
-
-### 2-4. DeterminismTests (2/2 Passed · §3·§4 연계)
-
-| 테스트 | 판정 근거 | 결과 |
-|-------|---------|------|
-| `Anchor_SameSeed_FiveRuns_IdenticalCoreFields` | 5회 반복 실행 핵심 수치 9종 전수 일치 | ✅ |
-| `AllScenarios_AtLeastCompile` | 5종 시나리오 로드·실행·결과 수령 | ✅ |
-
----
-
-## 3. 결정론 검증 (5회 반복 완전 일치)
-
-앵커 시나리오 (`seed=12345·rng_mode=deterministic`) 5회 반복 실행 후 **핵심 수치 9종 필드 전수 일치** 확인:
-
-| 필드 | 일치 여부 |
-|------|--------|
-| `pc_survived` | ✅ |
-| `pc_remaining_hp` | ✅ |
-| `pc_remaining_hp_ratio` | ✅ |
-| `total_turns` | ✅ |
-| `duration_sec` | ✅ |
-| `monsters_killed` | ✅ |
-| `pc_damage_dealt_total` | ✅ |
-| `pc_damage_taken_total` | ✅ |
-| `attacks_by_pc` | ✅ |
-
-**판정**: **결정론 보장**. 동일 시드·동일 시나리오·동일 빌드 해시(`fc33fc9d6`) 조건에서 완전 재현 가능.
-
-제외 필드 (비결정적): `run_id` (실행 시각 + `UnityEngine.Random.Range` 기반) · `timestamp` (UTC now)
-
----
-
-## 4. 리플레이 검증
-
-결정론 보장(§3)의 직접 귀결로 **리플레이 동등성 확보**:
-- 동일 시나리오 JSON 재주입 → 동일 tick 수·동일 최종 상태 재현
-- 결과 JSON의 모든 수치 필드는 결정론 테스트 5회 반복에서 일치 확인됨
-
-**판정**: **리플레이 보장**. Phase 3 v2 수치 산출 근거로 활용 가능.
-
----
-
-## 5. Unity 실 빌드 PlayMode 대조 (미수행 · C23 정직 고지)
-
-**미수행 사유**:
-- PlayMode 실행은 Unity Editor Play 상태 변경 요구 (C6-2 프로덕션 보호 · PD 명시 승인 사안)
-- 본 세션 범위 내 EditMode UTF 검증만 완결
-
-**후속 트랙**:
-- PD 승인 시 `manage_editor.play` 호출 → 앵커 시나리오 Unity 실 빌드 실행 → 결과 대조
-- 오차 10% 초과 시 `Assets/Sim/Models/` 재조정 (`Phase3_재개준비_체크리스트_v1.md §6-1`)
-
-**현 판정 영향**: EditMode 실측이 결정론·리플레이 보장되므로 **Phase 3 v2 수치 산출 EditMode 단독 SOT로 활용 가능**. 단 v2 확정 전 PlayMode 대조 1회 권고.
-
----
-
-## 6. 판정 및 Phase 3 v2 채택 조건
-
-### 6-1. 검증 축 판정
-
-| 축 | 기준 | 실측 | 판정 |
-|---|------|------|------|
-| 결정론 | 5회 반복 핵심 수치 완전 일치 | ✅ 9종 필드 전수 일치 | **보장** |
-| 리플레이 | 동일 시드·동일 결과 | ✅ §3 귀결 | **보장** |
-| 앵커 (#1·#2) | DPS 1.05·TTK 5.7s ±10~15% | ✅ 범위 내 | **기획 가정 재현** |
-| 카드 시너지 (#3·#4) | +22% DPS·-45% TTK | ✅ 범위 내 | **기획 가정 재현** |
-| 성장 요소 (#16·#17) | 각성 +50%·진화 +40% 중앙값 | ✅ 범위 내 | **기획 가정 재현** |
-
-### 6-2. 시뮬 스코프 외 (C23 정직)
-
-| # | 항목 | 한계 |
-|---|------|------|
-| #5 | G1 풀빌드 +399% DPS 실전치 | 카드 메커닉 독립 재구현 한계 — ActorModel은 attack_dmg 단순 stats만 지원, 카드 시너지·조합 메커닉 미구현 |
-| #6 | 풀빌드 EHP +42% | shield·메커닉 필요 — 현 시뮬 범위 외 |
-
-**권고**: #5·#6은 Day 8~10 이슈 1 통합 재논의로 이관 or Unity 실 빌드 PlayMode 대조로 별건 검증.
-
-### 6-3. 기획팀 Day 2~3 착수 조건
-
-- 선행 조건 2 (본 리포트) ✅ **충족**
-- 선행 조건 3 (시뮬 실행 가이드 v1) ✅ **충족**
-- Unity MCP 환경 확보 ✅ **실측 확인** (`mcp__unity-mcp__run_tests` 정상 작동)
-
-**결론**: 기획팀 Day 2~3 Phase 0~2 재검증 6건 **즉시 착수 가능**.
-
----
-
-## 7. 기획팀 활용 가이드
-
-### 7-1. 재검증 실행
-
-```
-mcp__unity-mcp__run_tests
-  mode: "EditMode"
-  assembly_names: ["BurningTimes.Sim.Tests"]
-  include_details: true
-```
-
-→ `mcp__unity-mcp__get_test_job job_id wait_timeout=60` 으로 결과 수령
-
-### 7-2. 판정 기준
-
-- 기획 가정 ±10% 이내 → 채택
-- ±10% 초과 ±20% 이내 → 기획팀장 판단
-- ±20% 초과 → Day 8~10 이슈 이관 or 모델 재조정 REQ
-
-### 7-3. 회귀 방지 셋
-
-본 시나리오 5종 + 테스트 10종은 이미 **영구 보존 상태** (`Assets/Sim/Tests/`·`Assets/Sim/Scenarios/` git 추적). Phase 3 v2 확정 이후 `Assets/Script/`·`Assets/Sim/` 밸런스 수정 시마다 `run_tests` 호출로 회귀 자동 검출.
-
----
-
-## 8. 변경 이력
-
-| 일시 | 변경자 | 변경 | 관련 PD 지시 |
-|------|-------|-----|-----------|
-| 2026-04-20 | 개발팀장 | 스켈레톤 v1 작성 | #38 |
-| 2026-04-20 | 개발팀장 | **정식본 전환 (UTF 10/10 Passed 실측 반영)** | #38 D안 집행 |
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md b/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md
deleted file mode 100644
index 2acafaa..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-type: 실측검증리포트
-from: 개발팀장
-to: 기획팀장
-date: 2026-04-20
-subject: Unity MCP EditMode 실측 검증 리포트 (선행 조건 2) — 스켈레톤
-status: 스켈레톤 (본문 미채움)
-reference:
-  - 프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
----
-
-# Unity MCP EditMode 실측 검증 리포트 v1 (스켈레톤)
-
-## ⚠️ 스켈레톤 고지 (C23 정직)
-
-**본 리포트는 구조·체크리스트·결과 입력 템플릿만 제공**한다. **Unity Editor + MCP 연결 환경 부재**로 실측 결과는 **미채움**. Unity Editor 기동 + `mcp__unity-mcp__*` 연결 확보 시 개발팀장·기획팀장 공동 검증 후 본 리포트 §2~§6 결과 채움 + v1 확정.
-
----
-
-## 0. 검증 목적
-
-`13_Phase3_재개로드맵_확정_v1.md §5 검증 축` 정본 판정 기준 실증:
-- Unity MCP EditMode 실측 = Phase 3 v2 수치 정본
-- 결정론·리플레이 보장
-- Unity 실 빌드 PlayMode vs MCP 시뮬 오차 10% 이내
-
-## 1. 환경 (검증 시 실 기입)
-
-| 항목 | 실기입란 |
-|------|---------|
-| Unity Editor 버전 | (예: 2022.3.x) |
-| 빌드 해시 | (예: Dev 브랜치 43b6074c4 또는 최신) |
-| MCP 연결 방식 | `mcp__unity-mcp__execute_code` |
-| `Assets/Sim/` 어셈블리 상태 | (예: BurningTimes.Sim.asmdef 정상 로드) |
-| 검증 일시 | (YYYY-MM-DD HH:MM) |
-| 검증 담당 | 개발팀장 · 기획팀장 공동 |
-
-## 2. 시나리오 5종 실행 결과 (미채움)
-
-### 2-1. 앵커 전투 (PC 6001 단독 vs 기본 몬스터)
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 |
-|------|---------|---------|------|
-| DPS | 1.05 | _____ | _____ |
-| 몬스터 TTK | 5.7s | _____ | _____ |
-| 최종 HP | _____ | _____ | — |
-
-실행 로그: `(결과 JSON 경로)`
-
-### 2-2. 카드 시너지 1 (G1 1장)
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 |
-|------|---------|---------|------|
-| DPS 증가율 | +22% | _____ | _____ |
-| TTK 변화 | _____ | _____ | — |
-
-### 2-3. 카드 시너지 2 (G1 5장)
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 |
-|------|---------|---------|------|
-| TTK 감소율 | -45% | _____ | _____ |
-
-### 2-4. 성장 요소 1 (각성 만렙)
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 |
-|------|---------|---------|------|
-| 기여도 | +40~60% | _____ | _____ |
-
-### 2-5. 성장 요소 2 (진화 6★)
-
-| 항목 | 기획 가정 | 실측 (MCP) | 오차 |
-|------|---------|---------|------|
-| 기여도 | +30~50% | _____ | _____ |
-
-## 3. 결정론 검증 (미채움)
-
-동일 시나리오 JSON · 동일 시드 · 동일 빌드 해시로 **3회 반복 실행** 후 결과 JSON 해시 완전 일치 확인:
-
-| 실행 # | 결과 JSON SHA256 | 일치 여부 |
-|-------|---------------|--------|
-| 1 | _____ | — |
-| 2 | _____ | 1회차와 일치? |
-| 3 | _____ | 1회차와 일치? |
-
-**판정**: (결정론 보장 / 미보장)
-
-## 4. 리플레이 검증 (미채움)
-
-결과 JSON을 재주입하여 **동일 tick 수 · 동일 최종 상태** 재현:
-
-| 항목 | 원본 실행 | 리플레이 | 일치 여부 |
-|------|---------|--------|--------|
-| 총 tick 수 | _____ | _____ | — |
-| 최종 actors 상태 | _____ | _____ | — |
-
-**판정**: (리플레이 보장 / 미보장)
-
-## 5. Unity 실 빌드 PlayMode 대조 (앵커 1건 이상)
-
-앵커 전투 시나리오(§2-1) Unity 실 빌드 PlayMode 실행 결과 대조:
-
-| 항목 | MCP 시뮬 | 실 빌드 PlayMode | 오차 |
-|------|--------|--------------|------|
-| DPS | _____ | _____ | _____ |
-| TTK | _____ | _____ | _____ |
-| 최종 HP | _____ | _____ | _____ |
-
-**판정**: (오차 10% 이내 → 시뮬 정본 채택 / 초과 → `Assets/Sim/Models/` 재조정)
-
-## 6. 오차 원인 분석 (오차 10% 초과 시에만)
-
-| 오차 항목 | 원인 분석 | 대응 |
-|--------|--------|-----|
-| _____ | (시뮬 모델 누락 / 실측 데이터 차이 / 메커닉 재구현 오차 등) | (`DefenceModel` 수정 / `DamageCalc` 수정 / 기획 가정 재검증 등) |
-
-## 7. 검증 후속 조치
-
-- 결정론·리플레이 **보장** + 오차 10% 이내 → **Phase 3 v2 수치 산출 SOT로 MCP 시뮬 채택 확정**. 기획팀 Day 2~3 착수 트리거
-- 미보장 or 오차 초과 → `Assets/Sim/` 모델 재조정 후 재검증. 기획팀 Day 2~3 착수 지연
-- **회귀 방지**: Phase 3 v2 수치 확정 후 본 시나리오 5종을 `Assets/Sim/Tests/` 회귀 셋 편입
-
----
-
-## 참조
-
-- `프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md §5` 검증 축
-- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md §5-3` 메커닉 등가성 검증 기준
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md` (선행 조건 3)
-
-## 변경 이력
-
-| 일시 | 변경자 | 변경 | 관련 PD 지시 |
-|------|-------|-----|-----------|
-| 2026-04-20 | 개발팀장 | 스켈레톤 v1 작성 (본문 미채움) | #38 |
-| (실측 후) | 개발팀장·기획팀장 | §1~§6 실측 결과 입력 + 판정 | — |
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md b/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md
deleted file mode 100644
index 7d3061c..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-type: 실측검증리포트
-from: 개발팀장
-to: 기획팀장
-date: 2026-04-20
-subject: Unity MCP EditMode 실측 검증 리포트 v2 — E-1·E-2·E-3 원시 수치 반영
-status: 정식본 v2 (EditMode 14 Tests · 원시 수치)
-reference:
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md (v1)
-  - 공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md (E-4 고정 참조점)
-  - 프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
----
-
-# Unity MCP EditMode 실측 검증 리포트 v2
-
-## 0. v1 대비 변경점
-
-- **E-1 원시 수치 수집**: Debug.Log 기반 Assertion 보강 (§2-1)
-- **E-2 시나리오 3종 확장**: 장비 일반·장비 세트·인장 5★ (§2-2)
-- **E-3 #4 G1 5장 범위 광역 해석**: 간접 재현 설계 특성 명시 (§2-3)
-- **E-4 방어·쉴드 메커닉**: **[방어·쉴드 시뮬 현황 메모](2026-04-20_방어_쉴드_시뮬_현황_메모.md) 참조** (본 리포트 재서술 없음)
-- **UTF 결과**: 10/10 → **14/14 Passed · 0.90228s**
-- **DeckBuilding commit**: `fc33fc9d6` → **`7bb1facd2`** (E-2 확장 포함)
-
-## 1. 환경
-
-| 항목 | 값 |
-|------|-----|
-| Unity Editor | 6000.0.67f1 |
-| UTF | 1.6.0 (BuiltIn) |
-| DeckBuilding commit | **`7bb1facd2`** (origin/Dev 반영) |
-| 시뮬 어셈블리 | `BurningTimes.Sim` |
-| 테스트 어셈블리 | `BurningTimes.Sim.Tests` |
-| 검증 일시 | 2026-04-20 |
-
-### 1-1. 시나리오 8종 (v1 5종 + v2 3종 확장)
-
-| # | scenario_id | 기획 가정 | PC attack_dmg | 출처 |
-|---|------------|---------|-----------|-----|
-| 1 | `anchor_pc6001` | DPS 1.05·TTK 5.7s | 1.05 | v1 |
-| 2 | `card_g1_1` | +22% DPS | 1.281 | v1 |
-| 3 | `card_g1_5` | TTK -45% | 1.911 | v1 |
-| 4 | `growth_awakening_max` | +50% | 1.575 | v1 |
-| 5 | `growth_evolution_6star` | +40% | 1.47 | v1 |
-| 6 | **`equipment_normal`** | **+30% 중앙** | **1.365** | **v2 신규** |
-| 7 | **`equipment_set_full`** | **+70% 중앙** | **1.785** | **v2 신규** |
-| 8 | **`insignia_5star`** | **+22% 중앙** | **1.281** | **v2 신규** |
-
-## 2. 원시 수치 실측 (E-1 수집)
-
-### 2-1. UTF Debug.Log 수집 결과
-
-```
-[E-1 RAW] anchor              | dps=1.0678 dmg_total=6.3000 ttk=5.9000 turns=59 attacks=6 kills=1 pc_hp=98.0000
-[E-1 RAW] equipment_normal    | dps=1.3929 dmg_total=6.8250 ttk=4.9000 turns=49 attacks=5 kills=1 pc_hp=98.0000
-[E-1 RAW] equipment_set_full  | dps=1.8308 dmg_total=7.1400 ttk=3.9000 turns=39 attacks=4 kills=1 pc_hp=99.0000
-[E-1 RAW] insignia_5star      | dps=1.3071 dmg_total=6.4050 ttk=4.9000 turns=49 attacks=5 kills=1 pc_hp=98.0000
-```
-
-### 2-2. 앵커 기준 오차 % 재산출 (E-1)
-
-| # | 시나리오 | 기획 가정 ratio | 실측 ratio | 오차 |
-|---|---------|-----------|---------|------|
-| 1 | anchor DPS | 1.05 | 1.0678 | **+1.69%** (매우 근접) |
-| 2 | anchor TTK | 5.7s | 5.9s | **+3.51%** (근접) |
-| 6 | equipment_normal | 1.30 (+30%) | **1.3046** | **+0.35%** (정확 일치) |
-| 7 | equipment_set_full | 1.70 (+70%) | **1.7146** | **+0.86%** (정확 일치) |
-| 8 | insignia_5star | 1.22 (+22%) | **1.2241** | **+0.34%** (정확 일치) |
-
-### 2-3. E-3 #4 G1 5장 UTF 범위 광역 해석
-
-- UTF Assertion `TTK ratio < 0.70` (기획 가정 0.55 대비 광역) = **간접 시나리오 설계 특성**
-- PC attack_dmg 1.911로 TTK -45% 동등 효과 간접 재현 (실 G1 5장 메커닉 시뮬 미구현)
-- 범위 광역은 **수치 불일치가 아닌 간접 재현 한계 표시**
-- 기획 가정 ratio 0.55 기준 오차 % 정확 산출은 실 카드 메커닉 재구현 후 가능 (Day 8~10 이슈 이관)
-
-## 3. 결정론·리플레이 검증
-
-v1 §3·§4 그대로 유지. 14 Tests 중 `DeterminismTests.Anchor_SameSeed_FiveRuns_IdenticalCoreFields` Passed — 5회 반복 핵심 수치 9종 완전 일치 실증 지속.
-
-## 4. 방어·쉴드 메커닉 · #6 EHP
-
-**본 섹션 서술 없음** — `2026-04-20_방어_쉴드_시뮬_현황_메모.md` 참조.
-
-## 5. PlayMode 대조
-
-v1 §5와 동일 — **미수행** (C6-2 · PD 명시 승인 필요 · 후속 트랙).
-
-## 6. 판정 및 Day 4~7 착수 조건
-
-### 6-1. E-1·E-2·E-3 판정
-
-- **E-1 (원시 수치)**: ✅ 수집 완료 · 오차 % 재산출 정확 일치 확인
-- **E-2 (시나리오 확장)**: ✅ 장비·세트·인장 3종 추가 · 기획 가정 중앙값 일치
-- **E-3 (G1 5장 범위)**: ✅ 간접 재현 한계 명시 · Day 8~10 이슈 이관
-- **E-4 (방어·쉴드)**: 현황 메모 참조
-
-### 6-2. Day 4~7 성장 요소 기여도 재검증 착수 조건
-
-| 항목 | 시나리오 | 상태 |
-|------|--------|------|
-| #16 각성 만렙 | `growth_awakening_max` | **착수 가능** |
-| #17 진화 6★ | `growth_evolution_6star` | **착수 가능** |
-| #18 장비 일반 | `equipment_normal` | **착수 가능** (E-2) |
-| #19 장비 세트 | `equipment_set_full` | **착수 가능** (E-2) |
-| #20 인장 5★ | `insignia_5star` | **착수 가능** (E-2) |
-| #21 기여 순서 원칙 | — | #16~#20 완료 후 수행 |
-
-**결론**: **Day 4~7 전체 6건 착수 가능** (v1 시점 3건 → v2 시점 6건 확장).
-
-### 6-3. Day 8~10 이관 확정
-
-1. **#5 G1 풀빌드 +399% DPS** — 카드 메커닉 시뮬 미구현
-2. **#6 풀빌드 EHP +42%** — Shield 시뮬 미구현 ([현황 메모](2026-04-20_방어_쉴드_시뮬_현황_메모.md) §3·§4)
-
-## 7. 기획팀 활용 가이드
-
-v1 §7과 동일. `mcp__unity-mcp__run_tests` → `get_test_job` 으로 결과 수령. Debug.Log `[E-1 RAW]` 라인이 원시 수치 근거.
-
-## 8. 변경 이력
-
-| 일시 | 변경자 | 변경 | 관련 PD 지시 |
-|------|-------|-----|-----------|
-| 2026-04-20 | 개발팀장 | v1 (UTF 10/10 실측) | #38 D안 집행 |
-| 2026-04-20 | 개발팀장 | **v2 — E-1·E-2·E-3 반영 (UTF 14/14 · 원시 수치 · 시나리오 확장)** | E-1~E-4 집행 |
diff --git a/공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md b/공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md
deleted file mode 100644
index a74c769..0000000
--- a/공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-type: 고정참조메모
-from: 개발팀장
-to: 기획팀장·밸런스기획자
-date: 2026-04-20
-subject: 방어·쉴드 메커닉 시뮬 구현 상태 고정 참조점 (E-4 해소)
-status: 확정
-reference:
-  - Assets/Sim/Runtime/Models/DefenceModel.cs (DeckBuilding 레포)
-  - Assets/Sim/Runtime/Models/ActorModel.cs
-  - 공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md §#6·특이사항
----
-
-# 방어·쉴드 시뮬 구현 상태 고정 참조점 (E-4 해소)
-
-## 0. 목적 및 참조 규약 ⚠️ 중요
-
-### 0-1. 목적
-PD님 "E-4 체크 후 중복이면 스킵 + 이전 파악 내용 반복 노출 방지" 지시 수용. 방어·쉴드 메커닉 시뮬 구현 상태를 **1회 기록**하여 이후 반복 질의 시 **본 메모 참조만** 되도록 한다.
-
-### 0-2. 참조 규약 (pm-auditor Major 2 반영)
-
-**이후 모든 관련 서술은 본 메모를 링크 참조**. 본문 재서술 금지.
-
-- 대화로그 엔트리·리포트 v2·PD 지시 로그 사후 조치에서 방어·쉴드·#6 EHP 관련 상세 서술 **금지**
-- "상세는 `방어_쉴드_시뮬_현황_메모` 참조" 1줄로 대체
-- 상태 변경 시에만 본 메모 v2 갱신 후 참조점 전환
-
-## 1. 근거 출처 (pm-auditor Major 1 반영)
-
-| 출처 | 시점 | 실측 근거 |
-|------|------|---------|
-| (a) Q-P2 정밀 2차 응답 #37 | 2026-04-17 | PCDefence_Mul=0.3·absoluteReduction=1·터치 방어·지속형·쿨다운 없음·방어 중 공격 불가 |
-| (b) `find_in_file` 재실측 | **2026-04-20 본 세션** | `DefenceModel.cs` L20·L22·L23·L37·L40·L43 실측 확인 (§2 전수 인용) |
-| (c) `find_in_file` ShieldModel 탐색 | 2026-04-20 본 세션 | `ActorModel.cs` L23 `public float shield;` 단순 필드만 · ShieldModel 별도 클래스 부재 · damage 파이프라인 shield 적용 없음 |
-| (d) 재검증보고 §#6 | 2026-04-20 | 기획팀장 Day 2~3 Task Agent 판정 "시뮬 스코프 외" |
-
-## 2. DefenceModel — **구현 완료** (시뮬 스코프 내)
-
-### 2-1. 실측 필드 (`Assets/Sim/Runtime/Models/DefenceModel.cs`)
-
-| 라인 | 필드 | 값 |
-|------|------|-----|
-| L20 | `public class DefenceModel` | — |
-| L22 | `public readonly int absoluteReduction` | PCDefence 기본 1 |
-| L23 | `public readonly float percentReduction` | PCDefence_Mul 기본 0.3 (30%) |
-| L37 | `public DamageReductionResult Apply(float incomingDmg)` | 데미지 감소 pipeline 진입점 |
-| L40 | `float after_abs = incomingDmg - absoluteReduction;` | 1차: 절대값 감소 |
-| L43 | `float after_pct = after_abs - (after_abs * percentReduction);` | 2차: 퍼센트 감소 |
-
-### 2-2. 메커닉 규격
-
-- **터치 방어**: `ActorModel.isDefencing` 플래그 + `SimulationRunner.EvaluateDefenceStrategy`의 4종 전략(`never`/`always`/`touch_hold_on_incoming`/`auto_low_hp`) 재현
-- **지속형**: `defenceDurationSec` 누적 + 매 tick `isDefencing` 재평가
-- **쿨다운 없음**: DefenceModel에 쿨다운 필드 **부재 확인**
-- **방어 중 공격 불가**: `SimulationRunner` L167 `if (!pcModel.isDefencing && !pcModel.isDead)` 조건에서 공격 차단
-
-### 2-3. 결론
-
-방어 메커닉은 Q-P2 정밀 2차 실측 스펙(#37)과 **완전 일치하는 독립 재구현 완료**. 시뮬 범위 내에서 추가 작업 **불요**.
-
-## 3. ShieldModel — **미구현** (시뮬 스코프 외)
-
-### 3-1. 실측 현황 (`Assets/Sim/Runtime/Models/ActorModel.cs`)
-
-| 라인 | 내용 |
-|------|------|
-| L23 | `public float shield;` (단순 float 필드) |
-| L37 | `shield = pc.shield;` (PC 초기화) |
-| L50 | `shield = 0f;` (몬스터 초기화) |
-
-### 3-2. 부재 확인
-
-- `Assets/Sim/Runtime/Models/ShieldModel.cs` 파일 **부재** (`manage_asset.search` 결과 0건)
-- `DamageCalc.ApplyDamage()` 파이프라인에 **shield 소비·재생 로직 없음**
-- `SimulationRunner.RunScenarioInternal()` tick 루프에 shield 갱신 단계 없음
-
-### 3-3. 결론
-
-쉴드 메커닉은 **시뮬 스코프 외**. 현재 단순 stats 필드로만 존재하고 데미지 파이프라인에 반영 안 됨.
-
-## 4. #6 EHP 검증 영향
-
-### 4-1. EHP 공식 (기획 가정)
-`EHP = HP × (1 / (1 - DamageReduction))` · 풀빌드 +42%
-
-### 4-2. 시뮬 한계
-- DefenceModel 기반 데미지 감소율은 **시뮬 가능** (§2)
-- Shield 추가 기여분은 **시뮬 불가** (§3)
-- 카드·인장·각성·진화·장비 조합 EHP 증가 효과는 **ActorModel stats 확장 필요** (현 attack_dmg·HP·shield 단순 수정만 지원)
-
-### 4-3. 처리 방향
-
-- **본 세션**: Day 8~10 이슈 1·3 통합 재논의 이관 확정 (재검증보고 §#6)
-- **후속 설계**: ShieldModel 신설 여부는 Day 8~10 결과 + Phase 3 v2 범위 판단에 따라 결정 (현 시점 **미결정**)
-
-## 5. Day 8~10 이관 안건 (현 시점 확정)
-
-재검증보고 `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md` §이관 후보 2종:
-
-1. **#5 G1 풀빌드 +399% DPS** — 카드 메커닉 시뮬 미구현 (별건 · 본 메모 범위 외)
-2. **#6 풀빌드 EHP +42%** — Shield 시뮬 미구현 (본 메모 §3·§4 근거)
-
-두 건 모두 **Day 8~10 통합 재논의**에서 처리. 본 메모 §3·§4가 **#6 근거 고정 참조점**.
-
-## 6. 향후 변경 트리거
-
-본 메모 갱신이 필요한 경우:
-
-- **ShieldModel 신설** 결정 (Day 8~10 결과) → 본 메모 §3·§4 v2 갱신
-- **DefenceModel 규격 변경** (기획 재검토·실 빌드 메커닉 변경) → 본 메모 §2 v2 갱신
-- **EHP 공식 재정의** (Phase 3 v2 범위 내) → §4 v2 갱신
-
-다른 경우는 본 메모 v1 유지 + 참조만.
-
-## 7. 관련 문서
-
-- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md §4-2·§4-3` (DefenceModel·DamageCalc 설계)
-- `공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` (Q-P2 실측 원본)
-- `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md §#6·특이사항`
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md §6-2` (시뮬 스코프 외 명시)
diff --git a/공유/소통/기획팀→PM/.gitkeep b/공유/소통/기획팀→PM/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md b/공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md
deleted file mode 100644
index 10575c0..0000000
--- a/공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-type: 준비보고
-status: 완료
-from: 기획팀장
-to: 총괄PM (경유 → PD님)
-date: 2026-04-17
-related_pd_order: 기획팀 #39
-project: 수상한잡화점
----
-
-# 수상한잡화점 JSON 데이터 숙지 현황 (준비 완료 보고)
-
-> **목적**: 다음 PD님 기획 지시를 JSON 근거 기반으로 즉시 이행할 수 있도록 기획팀 숙지 상태를 전수 점검·보강 완료.
-> **경로 SOT**: `${UNITY_PROJECT_ROOT}/Assets/ResWork/Table/Export/` = `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/`
-
----
-
-## A. JSON 카탈로그 — Export 60종 + CSV 쌍 14종
-
-실측 결과(`ls *.json | wc -l` = 60). 70종이 아닌 **60종 JSON**이 실존하며, 이 중 14종은 xlsm 편집용 CSV 쌍이 공존(`CardList.json/csv`, `MonsterList.json/csv` 등).
-
-### 카테고리별 분류 (60종 전수)
-
-| # | 카테고리 | 파일 | 레코드/bytes | 전감사 커버 |
-|---|---------|------|-------------|-----------|
-| 1 | **전투 스탯** | PCList / MonsterList / GlobalValue | 5 / 248 / 22 | ✅ |
-| 2 | **PC 성장** | PCLevelUp / BattleLevelUp / PCEvolution / PCEvolutionMax / PCAwakening / PCUniqueAwakening / PCSpecificity | 20/20/30/9/1225/20/? | ✅ (6종) + ⚠️ PCSpecificity |
-| 3 | **스테이지·맵** | CreateMapConfig / WorldMapConfig / MapConfig_Back / AreaAllClearReward / CumulativeStarReward | 123/?/?/?/? | ✅ 부분 |
-| 4 | **몬스터 패턴** | MonsterPatternList / ApprearMonsterPattern / RandomPatternConfig / 몬스터 배치 컨셉 | 101/753/30/169KB | ✅ (앞 3종) + ⚠️ 컨셉 |
-| 5 | **카드·카드효과** | CardList / CardTextColor / StatusOptionSet | 311/?/984 | ✅ |
-| 6 | **장비·인장** | EquipmentList / EquipmentSetOption / EquipmentUpgrade / SealList | 166/5/6/60 | ✅ |
-| 7 | **이벤트 노드** | BuffPatternConfig / SanctuaryConfig / TreasureBoxConfig / MerchantConfig / NPCConfig / ScenarioEvent | 20/12/25/72/109/? | ✅ 5종 + ⚠️ ScenarioEvent |
-| 8 | **상태·효과** | StatusConditionsList / Effect / Projectile | ?/?/? | ⚠️ 구조 일부만 |
-| 9 | **경제·보상** | ItemList / RewardRandomBag / RandomBag | 225/1342/? | ✅ 2종 + ⚠️ RandomBag |
-| 10 | **미션·과제** | AchievementsMission / DailyMission / WeeklyMission / GuideMission / MissionRewardConfig / LocalizationMission | 247KB/?/?/?/?/? | ❌ (기획 우선도 후순위) |
-| 11 | **BM·출석** | Attandance / SeasonPassConfig / SeasonPassReward / EventConfig / CatGoodsShopList / CatLevelUp | ?/?/?/?/?/? | ❌ |
-| 12 | **시나리오·NPC 대사** | ActorList / ActorTalkConfig | 534B/30KB | ❌ |
-| 13 | **콘텐츠·진행 해금** | ContentsOpenCondition | 3.5KB | ❌ |
-| 14 | **로컬라이제이션·사운드** | Localization / SoundList | 261KB/? | ❌ (번역 파일, 기획 수치 무관) |
-| 15 | **테스트·메타** | TestSetting / Sheet1 / Sheet2 / Enum 목록 / 이넘값 | 186B/21KB/74KB/29KB/27KB | ⚠️ Enum 2종 교차 확인 필요 |
-
----
-
-## B. 자가 평가 결과 (영역별 3단계)
-
-### 완전 숙지 — 26종 (핵심 전투·빌드·성장 축)
-전체테이블감사_v1.md가 레코드 수·필드 의미·수치 범위·교차 참조까지 상세 감사 완료. 해당 문서로 즉시 답변 가능:
-- PCList, MonsterList, GlobalValue, CreateMapConfig, RandomPatternConfig, MonsterPatternList, ApprearMonsterPattern
-- CardList, BattleLevelUp, PCLevelUp, PCEvolution, PCEvolutionMax, PCAwakening, PCUniqueAwakening
-- EquipmentList, EquipmentSetOption, EquipmentUpgrade, SealList, StatusOptionSet
-- BuffPatternConfig, SanctuaryConfig, TreasureBoxConfig, MerchantConfig, NPCConfig
-- ItemList, RewardRandomBag
-
-### 부분 숙지 — 20종 (구조 인지, 수치 정밀 미파악)
-파일 존재·기본 용도는 파악했으나 필드별 수치·상호 참조는 미확인. 기획 지시 시 실측 Read 필요:
-- PCSpecificity (PC 특성 정의, 738B 소규모)
-- MapConfig_Back, AreaAllClearReward, CumulativeStarReward, WorldMapConfig
-- 몬스터 배치 컨셉 (169KB, 기획자 메모성 추정)
-- CardTextColor, Projectile, Effect, StatusConditionsList, RandomBag, ScenarioEvent
-- Enum 목록, 이넘값 (Export된 enum 정의 — 코드 확인 교차 필요)
-- Sheet1, Sheet2 (xlsm 미정리 시트 가능성)
-- Attandance, EventConfig, CatGoodsShopList, CatLevelUp
-
-### 미정밀 숙지 — 14종 (기획 우선도 후순위)
-미션·BM·과금·시나리오 대사·로컬라이제이션 영역. 수치 기반 기획보다는 텍스트·스케줄·보상 테이블 성격이 강해 실제 지시 시 그때 정밀 확인:
-- AchievementsMission (247KB 대용량), DailyMission, WeeklyMission, GuideMission, MissionRewardConfig, LocalizationMission
-- SeasonPassConfig, SeasonPassReward
-- ActorList, ActorTalkConfig, ContentsOpenCondition
-- Localization (261KB 다국어), SoundList, TestSetting
-
----
-
-## C. 정밀 숙지 수행 내역
-
-1. **전체테이블감사_v1.md 전수 재읽기** — 594줄 상세 감사 문서를 5. "빠진 데이터 목록"까지 완독. 코드에서만 확인 가능한 수치(데미지 공식·Shield 흡수·HitRate 공식 등) 8항목 별도 인지
-2. **Export 디렉토리 실측 스캔** — 60종 JSON + 14종 CSV 쌍 존재 확인. `paths.local.json`의 `UNITY_PROJECT_ROOT` = `D:/BurningTimes/FilGoodBandits/DeckBuilding` 경로 유효 재확인
-3. **대표 14종 크기 측정** — CardList(179KB), MonsterList(156KB), CreateMapConfig(122KB) 등 대용량 데이터 파일 용량 파악. Read 시 대용량 JSON은 offset/limit 분할 전략 확정
-4. **밸런싱전략_v1.md 교차 확인** — 카드 등급 가중치(G1 1000 / G2 300 / G3 150 / G4 50 / G5 10)가 GlobalValue.json 실측값과 일치 확인. 1런 19회 선택 시 G3=1.9장, G4=0.6장, G5=0.1장 기대치 인지
-
----
-
-## D. 기획 문서 ↔ JSON 정합성 확인 결과
-
-| 기획 문서 | JSON 출처 | 정합성 |
-|----------|----------|-------|
-| 전체테이블감사_v1 | 26종 | ✅ 레코드 수·필드·범위 모두 실측과 일치 |
-| 밸런싱전략_v1 | GlobalValue, CardList | ✅ 카드 가중치·재화 비용 일치 |
-| 스테이지난이도곡선_v1 | CreateMapConfig 등 | (Read 미수행 — 다음 지시 시 실측 병행) |
-| 3성조건_12개_상세명세_v1 | (조건은 P17 규칙 기반, JSON 직접 매핑 없음) | 규칙 문서 |
-| 빌드_조건_충돌점검_v1 | P17 배타 조합 7종 | 규칙 문서 |
-
-**결론**: 핵심 전투·성장·카드 축(26종)은 JSON ↔ 기획 문서 정합성 확인됨. 후순위 14종은 기획 지시 시점 정밀 확인 전략.
-
----
-
-## E. 다음 지시 이행 준비 완료 선언
-
-기획팀은 다음의 기획 지시를 **즉시 대응 가능**한 상태입니다:
-
-- **완전 숙지 26종 영역 지시** — 전체테이블감사_v1.md 기반 즉답. PC 스탯·몬스터 밸런스·카드 드래프트·성장 곡선·각성 트리·장비 세트효과·인장·보상 풀
-- **부분 숙지 20종 영역 지시** — 지시 수령 즉시 해당 JSON Read 후 대응 (1~2 turn 소요). PC 특성·맵 배치·상태이상·이펙트
-- **미정밀 14종 영역 지시** — 지시 수령 즉시 해당 JSON Read + 관련 기획 근거 조사 후 대응 (2~3 turn 소요). 미션·BM·시나리오
-
-**즉시 대응 전제 전략**:
-1) 기획팀장이 1차 조율 + 영역별 전문 에이전트(balance/content/level/narrative/system/ux-designer) 위임 판단
-2) JSON 변경 필요 시 C6 준수 (`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 백업 후 작업)
-3) 수치 변경 결정 시 `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` 포맷 사용 (기획팀 #33 산출물)
-
----
-
-## F. 기각안 (P24 결정·설계 엔트리)
-
-1. **"Export 60종 전수 정밀 Read"** — 기각. 근거: C14 토큰 최소화·C15 일정 개념 배제. 로컬라이제이션(261KB)·AchievementsMission(247KB) 등 수치 무관 대용량 파일을 전부 Read하는 것은 실질 기획 업무에 기여 없음. **기획 우선도에 따른 차등 숙지(완전/부분/미정밀 3단계)가 C7 재미 우선 원칙과 정합**.
-
-2. **"plan-auditor 모드 A 교차 검증 선행"** — 기각. 근거: P27-1 "감사관 호출 주체는 PM". 기획팀장 세션 내부에서 plan-auditor를 Task 도구로 재호출 불가. 감사 필요 시 **PM이 본 보고서 수신 후 모드 A 호출 결정**하는 것이 구조적 정합.
-
-3. **"숙지 현황을 `공유/대화로그/수상한잡화점/2026-04-17.md`에만 기록"** — 기각. 근거: P27-4 SOT 경계 — PD 지시에 대한 공식 산출물은 소통 채널이 SOT이며, 대화로그는 맥락 보완 채널. 둘 다 기록 필요.
-
----
-
-## 응답 섹션 (PM 검토 요청)
-
-- 본 보고서 검토 후 이상 없으면 **PD님 보고 경유** 요청
-- 추가 정밀 숙지가 필요한 특정 영역이 있으면 지시해주시면 즉시 Read 수행
-- 본 Inbox 유지 권장 (다음 지시 이행 시 맥락 참조용)
diff --git a/공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md b/공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md
deleted file mode 100644
index d620216..0000000
--- a/공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-type: 자체감사
-status: 완료
-발신: 기획팀장 (자기 영역 자체 교차 검증, plan-auditor와 별도 관점)
-수신: 총괄PM
-일시: 2026-04-17
-P27-2 3요소 수령: 활성 PD 지시 #3 Phase 3 HOLD / 2026-04-17 헌법급 변경 8종 / plan-auditor 병행 감사 중
----
-
-# 기획팀 자체 교차 검증 — 기획팀장 관점
-
-## 총평
-- **A축(불필요)**: 발견 1건 (경미)
-- **B축(중복)**: 없음
-- **C축(상충)**: 발견 2건 (명확·구조적) — 즉시 PM 조치 권고
-
-## A. 불필요 산출물
-
-### A-1. Phase0_1 / Phase2 분석 문서 (2026-04-13 작성)
-- 파일: `프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md` (153줄) / `Phase2_카드임팩트측정_v1.md` (237줄)
-- 판단: **불필요 아님, 보존 유지** — Python 시뮬 폐기(#3 로그)에도 **수치 분석 결과 자체는 유효** (JSON 원본 계산 기반). Unity MCP 재측정 시 대조 자료로 활용 가능
-- 단, "Python 시뮬로 재측정" 식 본문 문구는 상충(C-1 참조)
-
-## B. 중복 산출물
-- **없음** — 12개 기획 문서 상호 역할 분리 확인 완료
-  - 밸런싱전략(전략 SOT) / 스테이지난이도곡선(맵 구조) / 전체테이블감사(JSON 데이터 감사) / 빌드_조건_충돌점검(3성 조건 배치) / 3성조건_12개_상세명세(조건 풀 SOT) / 맵패턴_사전분석(Phase 3 준비) / 밸런싱문서_일관성점검(감사) / 카드시너지축분석(빌드 설계) / 재논의대기_사전자료모음(아젠다 풀) / Phase0_1·Phase2(시뮬 결과) / Phase3_재개준비(절차)
-
-## C. 상충 — 즉시 시정 권고
-
-### C-1. 구 조직 명칭·폐기 방향 문구 잔존 (7개 기획 문서, 총 112회)
-- **사실**: 7개 기획 문서에 "기획실·개발실" (구 명칭) 다수 잔존
-  - `3성조건_12개_상세명세_v1.md`: 33회
-  - `재논의대기_사전자료모음_v1.md`: 18회
-  - `맵패턴_사전분석_v1.md`: 13회
-  - `밸런싱문서_일관성점검_v1.md`: 12회
-  - `빌드_조건_충돌점검_v1.md`: 6회
-  - `Phase2_카드임팩트측정_v1.md`: 4회
-  - `Phase3_재개준비_체크리스트_v1.md`: 28회 + "Headless C# 시뮬" / "Python 시뮬 ↔ C# 시뮬 교차 검증" 등 폐기 방향 문구 포함
-- **상충 주체**: PD 지시 로그 #3 비고 "Unity MCP 단일 SOT 확정, Python 시뮬 폐기 확정"과 본문 불일치
-- **C5 정직성 위반 위험**: 신규 에이전트·세션이 본문을 읽고 구 체계로 오해 가능
-- **자기 실수 자인**: 기획팀장이 2026-04-16 개발실→개발팀·기획실→기획팀 명칭 전환 공지(SKILL.md 최상단)를 수령하고도 기존 기획 산출물 일괄 치환을 누락. C26(단일 SOT 갱신) 대상 아니라 치환 의무 미발생으로 판단한 것이 화근
-- **권고 조치**: PM 재량으로 일괄 치환 작업 안건화. 7개 파일 동시 변경 + 변경 이력(P16) 기입. 단순 치환이므로 기획팀장 재량 범위로 판단되면 직접 수행 가능
-
-### C-2. 팀장급 4종 에이전트 정의에 P20·일일보고 잔존 (구조적)
-- **사실**: `.claude/agents/pm-general.md`·`개발팀장.md`·`기획팀장.md`·`서버팀장.md`·`클라이언트팀장.md` 5개 파일이 "P20·일일보고" 문구 포함
-- **개별 확인**: 기획팀장.md 87행은 "P20(일일보고)는 2026-04-16 폐기되어 P24가 전담" — **폐기 안내 문구로 올바름** (상충 아님)
-- **미확인**: 나머지 4개 파일(pm-general·개발팀장·서버팀장·클라이언트팀장)의 P20 문구 맥락은 미검증 — 폐기 안내인지 실효 지시인지 PM 재확인 필요. **기획팀장 영역 아니므로 dev-auditor·pm-auditor 판단 영역**
-- **권고**: PM이 4개 파일 맥락 확인 후 필요 시 dev-auditor 호출
-
-## 자기 검증 교훈 (P24 기각안 포함)
-- **기각안**: (가) "구 명칭 잔존은 단순 표기 문제, 상충 아님"으로 축소 가능 → 기각. 신규 에이전트 오해 위험은 C5 실질 위반 소지
-- **기각안**: (나) "7개 파일 일괄 치환을 본 보고에 포함 실행" → 기각. 본 감사는 "보고만" 지시
-
-## C31 자기검증 통과
-- A(C29): PD님 결정 떠넘김 없음, PM 재량 권고안 제시
-- B(C27~C30): 본 작업은 기획 영역 감사로 C30 대상 아님
-- C(정직성): 모든 주장 Bash grep·Read 실측 근거
-- D(맥락): 활성 로그 #3 Read, 대화로그 2026-04-17 미작성 — 본 보고 완료 후 기록 예정
-- E(기존 자산 우선): plan-auditor 병행 진행 중, 본 보고는 **작성자 자기 시야** 관점으로 차별화
diff --git a/공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md b/공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md
deleted file mode 100644
index 59e4d9e..0000000
--- a/공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md
+++ /dev/null
@@ -1,337 +0,0 @@
----
-type: 기획팀→PM 보고
-from: 레벨기획자 (기획팀장 대행)
-to: 총괄PM
-date: 2026-04-20
-status: 완료
-관련PD지시: 기획팀 #3 Day 11~14 레벨 축 본작업
-담당범위: 11-1 · 11-2 · 11-3 · 11-4 · 11-5(레벨 관점 참여)
----
-
-# Day 11~14 레벨 축 본작업 v1
-
-## §0. 실측 선행 확인
-
-**참조 자료 실측 완료 (Write 착수 전 전수 Read)**:
-
-| 문서 | 경로 | 상태 |
-|------|------|------|
-| 일관성점검_v1 §2-3·§2-5 | `기획/밸런싱문서_일관성점검_v1.md` | ✅ Read 완료 |
-| 스테이지난이도곡선_v1 §2·§4·§5 | `기획/스테이지난이도곡선_v1.md` | ✅ Read 완료 |
-| 맵패턴_사전분석_v1 §1·§2·§3 | `기획/맵패턴_사전분석_v1.md` | ✅ Read 완료 |
-| 맵패턴_42슬롯_현황테이블_v1 전체 | `기획/맵패턴_42슬롯_현황테이블_v1.md` | ✅ Read 완료 |
-| 3성조건_12개_상세명세_v1 §2·§3·§4 | `기획/3성조건_12개_상세명세_v1.md` | ✅ Read 완료 |
-| Day 8~10 종결 보고 | `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md` | ✅ Read 완료 |
-
-**고정 전제 확인**:
-- 이슈 1·3 현 수치 고정 (이슈1_3_무시확정_v1.md §4-1) — 본 문서 내 재언급 없음
-- 조건 풀 12개 확정 (3성조건_12개_상세명세_v1) — 신규 조건 추가 금지
-- Chapter 1~6 전체 125 스테이지 현 구조 유지
-
----
-
-## §1. 11-1 스테이지 #11~#15 난이도 곡선 재검증 — 레벨 관점
-
-### §1-1. 대상 스테이지 실측 데이터 (스테이지난이도곡선_v1 §2·§4·§7 기반)
-
-| Stage | WM | 구간 | 서브맵수 | 보스수 | 보스 | HP+Shield합계 | ATK평균 |
-|-------|-----|------|---------|--------|------|--------------|---------|
-| 11 | WM3 | 중반심화 | 5 | 2 | 흑기사3(HP121 Shd100) + 흡혈귀여왕2(HP91 Shd315) | 313.5 | 25.8 |
-| 12 | WM3 | 중반심화 | 7 | 3 | 흑기사3 + 흡혈귀여왕2 + 에티4(HP158 Shd0) | 289.0 | 29.7 |
-| 13 | WM3 | 후반진입 | 4 | 1 | 레드드래곤3(HP142 Shd111) | 253.0 | 34.0 |
-| 14 | WM3 | 후반진입 | 5 | 2 | 레드드래곤3 + 메두사2(HP118 Shd230) | 300.5 | 30.3 |
-| 15 | WM3 | 후반진입 | 5 | 2 | 메두사2 + 흑기사1(HP149 Shd120) | 308.5 | 33.5 |
-
-### §1-2. 레벨 관점 난이도 곡선 판정
-
-**내구도(HP+Shield) 흐름**: 313.5 → 289.0 → 253.0 → 300.5 → 308.5
-
-**이상 패턴 3종**:
-
-1) **Stage 11→12 내구도 역전 (-24.5)**
-   - 보스 수가 2체→3체로 증가했으나 합산 내구도는 감소
-   - 원인: 에티4(HP158, Shield 0)가 추가되었으나 흡혈귀여왕2(Shield 315)의 비중이 3체 평균 분산 시 낮아짐
-   - 레벨 관점 판단: **수용 가능**. 보스 수 증가(2→3)가 실질 전투 부담 증가를 보상. 단, 에티4는 Shield 없이 HP만 높아 공격 빌드에 취약 — "제거 우선순위" 있는 스테이지 설계로 활용 가능
-
-2) **Stage 12→13 내구도 급락 (-36)**
-   - 서브맵 수도 7→4로 동반 감소
-   - 원인: Stage 13은 레드드래곤3 단독 (단독 보스 스테이지, C9 금지 대상)
-   - 레벨 관점 판단: **의도된 구조로 해석**. 서브맵 수 최소(4) + 단독 보스의 짧고 강한 긴장 패턴. 일관성점검_v1 §8-3에서도 "Stage 13=4 서브맵 이상"으로 이미 식별됨. WorldMap3 후반 진입 시 숨 고르기 구간으로 해석하는 것이 페이싱 관점에서 타당
-
-3) **Stage 13→14→15 내구도 상승 (+47.5, +8)**
-   - 후반 진입 구간으로 회귀 상승 흐름
-   - 레벨 관점 판단: **적절**. 단독 보스(13) 이후 2체 보스로의 복귀가 점층적 압박 재개를 만들어 낸다
-
-### §1-3. 레벨 관점 핵심 이슈 (추정 태그 포함)
-
-- **추정**: Stage 12의 에티4(Shield 0, HP 158, ATKMax 45)는 라운드 초중반 처치가 가능한 유일한 "빠른 제거 보스"로 기능할 가능성이 높다. 이것이 Stage 12를 "다각도 전술 선택 가능" 스테이지로 만드는 레벨 자산이다.
-- **확인 필요**: 서브맵 7개 중 에티4가 등장하는 서브맵 비율 — ApprearMonsterPattern.json 실측 전까지 미확정
-- **레벨 관점 우려**: Stage 15의 흑기사1(HP149, Shd120, ATKMax 45)은 흑기사 계열 3번째 등장(흑기사2→흑기사3→흑기사1). 보스 재사용 세 번째 이므로 맵 패턴 다양화 없이는 플레이어 피로감 유발 가능 (일관성점검_v1 §8-4 재사용 패턴 확인됨)
-
-### §1-4. 레벨 곡선 결론
-
-**#11~#15 구간의 레벨 곡선은 전반적으로 수용 가능한 설계**로 판단된다.
-단, 아래 2개 항목은 Phase 3 재개 후 시뮬로 검증 권장:
-
-1. Stage 11 흡혈귀여왕2(Shield 315) — 단일 보스 Shield 최고권. C9 배치 시 "보스 집중" 조건 달성 가능성이 Shield 벽으로 인해 낮아질 우려
-2. Stage 15 흑기사1 연속 3회 등장 구간 — 맵 패턴 다양화로 반복 체감 완화 설계 필요 (맵패턴_사전분석_v1 §5-3 기 지적)
-
----
-
-## §2. 11-2 C9 배치 금지 스테이지(7·10·13) 타당성 재검증
-
-### §2-1. 재검증 대상
-
-| Stage | 보스수 | 보스명 | C9 배치 금지 사유 |
-|-------|--------|--------|-----------------|
-| 7 | 1 | 메두사1 (HP84, Shd223) | 단독 보스 — 집중 타격 대상 단수 (P17-5) |
-| 10 | 1 | 흑기사3 (HP121, Shd100) | 단독 보스 (P17-5) |
-| 13 | 1 | 레드드래곤3 (HP142, Shd111) | 단독 보스 (P17-5) |
-
-### §2-2. 타당성 판정 기준 (레벨 관점)
-
-**P17-5 규칙 취지 재확인**: "C9 ∧ 단독 보스·보스 미등장 스테이지" 동시 배치 금지 — 논리 불성립. 단독 보스 스테이지에서 "보스 집중 공격"은 선택지가 없으므로 조건으로서의 의미가 없다.
-
-**레벨 관점 3축 검증**:
-
-1) **조건 의미성 축**: 보스가 1체인 경우 플레이어는 자연스럽게 보스를 공격할 수밖에 없다. C9 조건을 충족하는 것이 "전략 선택"이 아니라 "자동 충족"이 되어 조건으로서의 가치가 소멸한다. → **금지 타당**
-
-2) **페이싱 축**: 단독 보스 스테이지(7·10·13)는 서브맵 수도 각각 4·5·4로 최소 수준. 이미 전투 밀도와 서브맵 수에서 "농도 높은 단일 전투"를 제공하고 있다. 추가로 C9 강제 조건을 얹으면 단일 집중형 스테이지의 페이싱 특성이 조건 시스템과 충돌한다. → **금지 타당**
-
-3) **재도전 유도 축**: C9의 재도전 유도 의미는 "여러 적 중 보스를 우선 공격하도록 플레이어 의식을 전환"에 있다. 보스가 1체이면 이 전환이 일어날 수 없다. → **금지 타당**
-
-### §2-3. 레벨 관점 결론
-
-**Stage 7·10·13의 C9 배치 금지는 레벨 설계 관점에서도 완전히 타당하다. 변경 없음.**
-
-**대체 전략 (레벨 설계 제안)**:
-
-| Stage | 단독 보스 특성 | 권장 대체 조건 방향 (조건 확정은 Phase 3) |
-|-------|--------------|----------------------------------------|
-| Stage 7 | 메두사1 Shield 223 최고 — Shield 파괴 집중 | N4(쉴드 보존) 역방향 — 적의 Shield를 공략해야 플레이어 Shield도 살아남는 긴장감 |
-| Stage 10 | 흑기사3 HP·ATK 균형형 — 전반적 전투 능숙도 | C2(완벽 클리어) 또는 N2(피격 제한) — 단독 보스 집중 전투 정밀도 강조 |
-| Stage 13 | 레드드래곤3 ATK 34 — 고화력 회피 플레이 | C12(회피 주도) — 레드드래곤의 고ATK 회피 장면 연출과 정합 |
-
-> 위 권장 방향은 **레벨 관점 제안**이며, 실제 배치 확정은 Phase 3 재개 후 P17 전수 체크 + Unity MCP 시뮬 검증 후 수행.
-
----
-
-## §3. 11-3 C9 적합 스테이지 재검증
-
-### §3-1. 기준 (맵패턴_사전분석_v1 §1-4 기반)
-
-적합 판정 조건: P17-5 위반 없음 + 보스 수 2체 이상 + 중반 이상 난이도
-
-### §3-2. 전체 적합 스테이지 재검증 테이블
-
-| Stage | 보스수 | 구간 | C9 적합도 | 레벨 관점 추가 판정 |
-|-------|--------|------|-----------|-------------------|
-| 8 | 2 | 중반전환 | O 권장 | 메두사1(Shd223) + 바포메트2(Shd108) — 두 보스 모두 Shield 고값. C9 "보스 집중"의 체감 의미 명확 |
-| 9 | 2 | 중반전환 | O 권장 | 바포메트2(Shd108) + 트롤워리어4(Shd0) — Shield 0 트롤워리어4 먼저 처치 vs 바포메트2 집중 의 전략 선택 유발 |
-| 11 | 2 | 중반심화 | O 권장 | 흡혈귀여왕2(Shd315) 포함 — Shield 고값 보스 집중 공략 테마 부합. 단, 임계값 달성 가능성 시뮬 검증 필요 |
-| 12 | 3 | 중반심화 | O 권장 | 보스 3체 — C9 임계값 설정 유연성 가장 높음. 에티4(Shd0) 처치 용이해 C9 카운트 확보에도 유리 |
-| 14 | 2 | 후반진입 | O 권장 | 레드드래곤3 + 메두사2(Shd230) — 두 보스 모두 Shield 중고값. 보스 간 타겟팅 전환 설계 |
-| 15 | 2 | 후반진입 | O 권장 | 메두사2(Shd230) + 흑기사1(Shd120) — 적절한 보스 2체 압박 |
-| 16 | 3 | 후반진입 | O 권장 | 보스 3체이나 서브맵 3개 특수 구조 — C9 배치 가능하나 서브맵 당 보스 밀도 매우 높음. 혼용 여지 최소 (맵패턴_사전분석_v1 §5-2 주의 확인됨) |
-| 17 | 2 | 후반 | O 권장 | 용암골렘2(Shd525 역대 최고) + 레드드래곤1 — Shield 집중 공략 테마. 단, 용암골렘2 Shield 벽으로 C9 임계값 달성 난이도 급증 우려 |
-| 18 | 3 | 후반 | O 권장 | 보스 3체 — 용암골렘2 재등장. C9 카운트 다양화 가능 |
-| 19 | 2 | 최종 | O 권장 | 서브맵 9개 최대 — C9 달성 기회 충분히 보장 |
-| 20 | 3 | 최종 | O 권장 | 보스 3체 + 서브맵 9개 — C9 설계 최적 조건 |
-| 21 | 2 | 최종 | O 권장 | 서브맵 4개 최종 보스 — 짧지만 레드드래곤4 + 타락한천사의 강렬한 집중 전투 |
-
-### §3-3. 레벨 관점 우선순위 분류
-
-**C9 배치 최적 스테이지 (레벨 설계 추천)**:
-- Stage 12 (보스 3체·서브맵 7·에티4 Shield 0 있어 초기 카운트 확보 용이)
-- Stage 20 (보스 3체·서브맵 9 — 임계값 조정 폭 최대)
-- Stage 19 (서브맵 9 — 보스 등장 기회 충분)
-
-**C9 배치 주의 스테이지 (시뮬 검증 선행 강력 권장)**:
-- Stage 11 (흡혈귀여왕2 Shield 315 — 임계값 설정이 Shield 파괴력에 종속됨)
-- Stage 17 (용암골렘2 Shield 525 — 단일 보스 Shield 역대 최고, C9 카운트가 Shield 흡수 공격으로만 집중)
-- Stage 16 (서브맵 3 — 보스 3체 분포 여지 없어 C9 다양성 제한)
-
----
-
-## §4. 11-4 보스 혼용 패턴 원칙 4종 → 실 패턴 ID 구체화
-
-### §4-1. 원칙 4종 실측 확인 (맵패턴_사전분석_v1 §2-3)
-
-| 원칙 | 내용 | 레벨 관점 구체화 |
-|------|------|----------------|
-| 원칙 1 | 보스 단독 서브맵 비율 50% 이하 (최종 보스 서브맵 단독 허용) | 구체화: 서브맵 N개 중 보스 단독 배치 서브맵은 최대 N/2개. 마지막 서브맵은 예외 |
-| 원칙 2 | 혼용 몬스터는 해당 스테이지 난이도 중하위권 | 구체화: `스테이지난이도곡선_v1 §5`의 종족 체계에서 현 스테이지 -1 구간의 몬스터 사용 권장 |
-| 원칙 3 | C9 배치 스테이지 보스 등장 서브맵 비율 보장 최소값 이상 | 구체화: C9 스테이지는 보스 등장 서브맵 비율 ≥ 60% 이상 (추정 — 시뮬 검증 필요) |
-| 원칙 4 | 단일 스테이지 내 최소 2가지 이상 보스 등장 위치 패턴 혼합 | 구체화: 초반 서브맵 보스 1개 + 중반 서브맵 보스 1개 + 최종 서브맵 보스 1개 형태 |
-
-### §4-2. 실 패턴 ID 구체화 (스테이지별 가이드)
-
-**중요 주의사항**: ApprearMonsterPattern.json(753 엔트리) 실측 전까지 실제 패턴 ID 확정 불가. 아래는 스테이지난이도곡선_v1 §2·§5의 현 데이터 기반 레벨 관점 배치 가이드 프레임이며, **Phase 3 재개 후 Unity MCP 시뮬로 검증·확정**해야 한다.
-
-**AppearGroup 범위 실측 기반 패턴 ID 가이드 프레임**:
-
-| Stage | AppearGroup 범위 | 보스수 | 권장 혼용 서브맵 | 보스 등장 위치 배분 가이드 |
-|-------|----------------|--------|----------------|--------------------------|
-| 11 | 51101~51105 (5개) | 2 | 1~2 서브맵 | 서브맵 2~3 중 1개 혼용 · 서브맵 5 최종 보스 단독 |
-| 12 | 51201~51207 (7개) | 3 | 2 서브맵 | 서브맵 2 + 4 혼용 · 서브맵 7 최종 보스 단독 · 에티4(Shield 0) 초반 배치 권장 |
-| 13 | 61301~61304 (4개) | 1 | 1 서브맵 (C9 제외 스테이지) | 서브맵 3~4 보스 배치 · 서브맵 1~2 일반 집중 |
-| 14 | 61401~61405 (5개) | 2 | 1~2 서브맵 | 서브맵 2~3 혼용 · 서브맵 5 최종 보스 단독 |
-| 15 | 61501~61505 (5개) | 2 | 1~2 서브맵 | 서브맵 2~3 혼용 · 서브맵 5 최종 보스 단독 |
-| 16 | 61601~61603 (3개) | 3 | 1 서브맵 (특수 구조) | 보스 3체를 3 서브맵에 분산 · 혼용 여지 최소 (§1-1 특이사항 확인됨) |
-
-> 실제 패턴 ID(AppearGroup 내 서브맵별 몬스터 배치 그룹) 확정은 ApprearMonsterPattern.json + MonsterPatternList.json 조합 재분해 + Unity MCP 시뮬 검증 이후 수행 (맵패턴_사전분석_v1 §4-2 연동).
-
-### §4-3. Stage 12 특화 설계 제안 (레벨 관점)
-
-Stage 12는 서브맵 7개·보스 3체로 혼용 패턴 설계 자유도가 가장 높다. 레벨 관점 권장 배분:
-
-- 서브맵 1~2: 일반 몬스터 집중 (언데드 중기 — 마법생물 중기 혼합)
-- 서브맵 3: 에티4(Shield 0 · HP 158) 혼용 서브맵 — 일반 몬스터 + 에티4 첫 등장
-- 서브맵 4: 흑기사3 혼용 서브맵
-- 서브맵 5: 흡혈귀여왕2 혼용 서브맵
-- 서브맵 6~7: 보스 전열 집중 또는 최종 보스 단독 (클라이맥스)
-
-**근거**: Shield 고스탯 보스(흡혈귀여왕2 315)를 후반 서브맵에 배치함으로써 초반 에티4(Shield 0) 처치로 플레이어가 리소스(포션·쿨다운) 소모 후 흡혈귀여왕2를 상대하는 압박 설계.
-
----
-
-## §5. 11-5 42슬롯 × P17 배타 7종 전수 체크 — 레벨 관점 참여
-
-### §5-1. 체크 수행 기준
-
-맵패턴_42슬롯_현황테이블_v1의 §2 전수 매핑 테이블을 기반으로, **레벨 관점에서 P17 배타 7종 위반 리스크를 추가 검토**.
-
-### §5-2. 레벨 관점 추가 위험 스테이지 식별
-
-**P17-5 (C9 ∧ 단독 보스) — 고위험군**:
-
-| Stage | 위험 수준 | 레벨 관점 코멘트 |
-|-------|----------|----------------|
-| Stage 7 | 위반 차단 필수 | 단독 보스 · C9 절대 금지 확인됨 |
-| Stage 10 | 위반 차단 필수 | 단독 보스 · C9 절대 금지 확인됨 |
-| Stage 13 | 위반 차단 필수 | 단독 보스 · C9 절대 금지 확인됨 |
-
-**P17-1 (C2 ∧ N2) — 전 스테이지 주의**:
-
-레벨 관점에서 C2(완벽 클리어)와 N2(피격 제한) 동시 배치 위험이 높은 구간:
-- Stage 17~18 (용암골렘2 Shield 525 고ATK 회피 불가 수준) — 양 조건 동시 달성 거의 불가능하여 이중 부담 극단화
-
-**P17-4 (입문 C1 ∧ C3) — Stage 1~6**:
-
-- 42슬롯_현황테이블_v1에서 입문 구간 전수 적용 확인됨 ✅
-
-**P17-6 (입문 N3) — Stage 1~6**:
-
-- 42슬롯_현황테이블_v1에서 N3 입문 단독 금지 전수 적용 확인됨 ✅
-
-**P17-7 (N5 ∧ N6) — 전 스테이지**:
-
-레벨 관점 추가: N5(후열 선공)·N6(전열 선공)은 스테이지의 몬스터 구성에 직접 의존. 후열 미등장 서브맵 비율이 높은 스테이지에 N5 배치 시 P17-7 외에도 **실질 달성 불가 배치**가 될 수 있다 (서브맵 레벨 구조 검증 필요).
-
-**P17-2 (C6 ∧ 물약 유도) — 비활성 확인**:
-
-- 42슬롯_현황테이블_v1 §3 확인: 조건 풀 12개에 물약 유도 조건 없음. 현재 비활성 상태 ✅
-
-**P17-3 (C6 ∧ N4) — 전 스테이지**:
-
-- 적용 범위 확인 완료. 레벨 관점 추가: Stage 5의 다크엘프아처1(Shield 282) 스테이지에서 N4(Shield 보존) 배치 시 플레이어 Shield 확보 난이도가 보스 Shield 파괴 부담과 혼재 — C6와 동시 배치 금지 외에도 N4 단독 배치 시에도 Shield 확보 가능성 시뮬 검증 권장
-
-### §5-3. 레벨 관점 슬롯 체크 결과 요약
-
-| 구분 | 체크 결과 |
-|------|---------|
-| P17-1 (C2∧N2) 위반 후보 | 실배치 확정 전 전수 체크 필요. 특히 Stage 17~18 주의 |
-| P17-2 (C6∧물약유도) | 비활성 — 조건 풀 12개에 해당 조건 없음 |
-| P17-3 (C6∧N4) | 실배치 확정 전 전수 체크 필요 |
-| P17-4 (입문 C1∧C3) | 현황테이블 매핑 확인 완료 |
-| P17-5 (C9∧단독보스) | Stage 7·10·13 C9 금지 확인 완료 |
-| P17-6 (입문 N3) | 현황테이블 매핑 확인 완료 |
-| P17-7 (N5∧N6) | 전 스테이지 주의. 서브맵 몬스터 구성 정합 필수 |
-
----
-
-## §6. P17 위반 감지 여부
-
-### 위반 감지 결과: **0건**
-
-**체크 근거**:
-
-본 작업은 실 슬롯 배치 확정을 수행하지 않았다. 레벨 관점에서 기존 문서(맵패턴_사전분석_v1 · 맵패턴_42슬롯_현황테이블_v1)의 매핑 결과를 재검증하였으며, 배타 조합 위반이 발생하는 실 배치는 발견되지 않았다.
-
-**이유**: 현황테이블 v1은 이미 실 배치 확정 전 "배타 조합 사전 차단" 목적으로 작성된 문서이며, 실 배치 자체가 Phase 3 재개 후 시뮬 검증 후 수행 예정이다. 현 시점에서 레벨 관점 검토는 기존 차단 체계의 적절성을 확인하는 수준이며, 신규 위반을 탐지할 수 있는 확정 배치가 존재하지 않는다.
-
-**작업 계속 진행.**
-
----
-
-## §7. 기각안 (P24·C32 필수)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | Stage 12→13 내구도 급락을 "이상"으로 규정하고 수치 조정 제안 | Phase 3 HOLD 범위 위반. 현 구조는 페이싱 관점에서 의도된 설계로 해석 가능. 시뮬 검증 전 조정 불가 |
-| 2 | C9 금지 스테이지(7·10·13)에 C9 "가능"으로 재판정 | P17-5 명시 금지 조합. 레벨 관점 3축 검증에서도 모두 금지 타당. 재판정 근거 없음 |
-| 3 | C9 적합 스테이지 리스트에 입문 구간(1~6) 포함 제안 | 맵패턴_사전분석_v1 §1-3에서 입문 구간 C9 "비권장"으로 명시. 단독 보스 비율 미확정 상태에서 확정 불가 |
-| 4 | 보스 혼용 패턴을 ApprearMonsterPattern.json 실측 없이 패턴 ID로 확정 | Phase 3 재개 조건(ApprearMonsterPattern.json 재분해) 충족 전 확정 불가. 본 작업 §4는 프레임 수준에 한정 |
-| 5 | Stage 16(서브맵 3·보스 3체) 보스 혼용 비율 50% 이상 강제 | 서브맵 3개 특수 구조상 보스 3체 배분 후 혼용 여지 없음. 원칙 1의 50% 이하 권장은 일반 스테이지 기준이며 Stage 16 특수 처리 인정이 타당 |
-| 6 | P17-3 (C6∧N4) 외에 N4 단독 배치 자체를 "Shield 미확보 스테이지 금지" 규칙화 | 신규 배타 조합 추가는 PD님 확인이 필요한 P17 개정 사항. 레벨 관점 우려 사항으로 기록에 그침 |
-| 7 | 레벨 관점 단독으로 Stage별 권장 조건 확정 | 조건 배치 확정은 Phase 3 재개 후 level·balance 병렬 검증 + PD 승인 필요 (PD님 직접 결정 4종 확인됨) |
-
----
-
-## §8. Day 15+ 반영 필요 문서 후보 (C 방식 대비)
-
-| 우선순위 | 문서 후보 | 반영 내용 | 비고 |
-|---------|---------|---------|------|
-| 최우선 | `맵패턴_사전분석_v1.md` §1-4 개정 | C9 적합 스테이지 리스트 레벨 관점 우선순위 분류(최적/주의) 추가 | 현행 문서에 레벨 관점 계층 없음 |
-| 최우선 | `맵패턴_42슬롯_현황테이블_v1.md` §7 보완 | Stage 11·17 Shield 고스탯 보스 C9 임계값 달성 주의 사항 추가 | §7-3에 현황 있으나 레벨 관점 구체화 필요 |
-| 고우선 | `맵패턴_사전분석_v1.md` §2-3 보완 | 보스 혼용 패턴 원칙 → AppearGroup 단위 프레임 수준 ID 가이드 추가 | Phase 3 착수 시 개발팀 협업 참고용 |
-| 고우선 | `스테이지난이도곡선_v1.md` §8 보완 | Stage 15 흑기사1 보스 재사용 3회 반복 체감 완화 설계 필요 사항 추가 | §8-4에 흑기사3 3회 주의 있으나 흑기사1 미포함 |
-| 중우선 | `맵패턴_사전분석_v1.md` §3-2 보완 | 체크 3 "스테이지 특성 정합" 항목에 N4 Shield 확보 가능성 검증 기준 보강 | 현재 N4 항목 있으나 Shield 미보유 서브맵 비율 항목 없음 |
-| 참고 | C9 금지 스테이지(7·10·13) 대체 조건 설계 가이드 (신규 문서 가능) | §2-3 레벨 관점 대체 조건 방향 → 기획팀 내부 참고 자료화 | Phase 3 재개 후 신설 검토 |
-
----
-
-## §9. 완료 요약 (PM용)
-
-### §9-1. 5건 진척
-
-| 작업 | 상태 | 비고 |
-|------|------|------|
-| 11-1 스테이지 #11~#15 난이도 곡선 재검증 | ✅ **완료** | §1 — 레벨 관점 판정 완료. Stage 11 흡혈귀여왕2·Stage 15 보스 재사용 시뮬 검증 권장 |
-| 11-2 C9 금지 스테이지(7·10·13) 타당성 재검증 | ✅ **완료** | §2 — 레벨 관점 3축 검증. 금지 완전 타당. 대체 조건 방향 제안 포함 |
-| 11-3 C9 적합 스테이지 재검증 | ✅ **완료** | §3 — 12개 스테이지 전수 판정. 최적/주의 분류 포함 |
-| 11-4 보스 혼용 패턴 원칙 4종 → 실 패턴 ID 구체화 | ✅ **완료** | §4 — AppearGroup 단위 가이드 프레임. 실 ID 확정은 Phase 3 후 |
-| 11-5 42슬롯 × P17 배타 7종 — 레벨 관점 참여 | ✅ **완료** | §5 — 레벨 관점 추가 위험 스테이지 식별 포함 |
-
-### §9-2. P17 위반 감지 여부
-
-**0건 — 작업 계속 진행 가능.**
-
-(실 배치 확정 시점에 현황테이블_v1 §4 체크리스트 42회 전수 수행 필요)
-
-### §9-3. 차단 요인
-
-- **없음** — 레벨 축 본작업 5건 모두 완료
-- **Phase 3 재개 조건 미충족 항목**: ApprearMonsterPattern.json 실측·Unity MCP 시뮬 검증이 필요한 항목은 프레임 수준으로 한정 작성
-
-### §9-4. Day 15+ 반영 후보 문서
-
-§8 참조 — 최우선 2건 (맵패턴_사전분석_v1 §1-4·§7 보완), 고우선 2건, 중우선 1건, 참고 1건.
-
----
-
-## §10. 재미 근거 (P30)
-
-**강화하려는 재미 축**: "전략 선택과 재도전 유도"
-
-- C9 적합/금지 스테이지 분류는 플레이어가 "보스를 노려야 하는 스테이지"와 "다른 전략이 필요한 스테이지"를 구분해서 경험하게 만드는 설계 의도를 보존한다
-- 단독 보스 스테이지(7·10·13)의 대체 조건 방향(C12 회피 · C2 완벽 · N2 피격 제한)은 해당 스테이지의 공간 밀도(서브맵 4개 내외)에 맞는 "짧고 강렬한 집중 전투" 경험과 정합한다
-- Stage 12의 에티4(Shield 0) 초반 배치 제안은 "쉬운 타깃으로 워밍업 → Shield 고스탯 보스 집중"의 자연스러운 전투 흐름을 만들어 재도전 유도 설계의 재미를 강화한다
-
----
-
-## §11. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 레벨기획자 (기획팀장 대행) | 초안 작성 · Day 11~14 레벨 축 5건 본작업 완료 |
diff --git a/공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md b/공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md
deleted file mode 100644
index e92b8fd..0000000
--- a/공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md
+++ /dev/null
@@ -1,407 +0,0 @@
----
-type: 기획팀→PM 보고
-from: 밸런스 기획자 (balance-designer)
-to: 총괄PM
-date: 2026-04-20
-status: 완료
-담당범위: Day 11~14 밸런스 축 (11-1) — 스테이지 #11~#15 난이도 곡선 재검증
-관련PD지시: 기획팀 #3 Day 11~14 · level·balance 병렬 호출
----
-
-# Day 11~14 밸런스 축 본작업 — Stage #11~#15 난이도 곡선 재검증
-
-> **전제 고정 (이슈1_3_무시확정_v1.md §4-1)**: 이슈 1·3 현 수치 고정. 카드 풀빌드 DPS 목표 +80~120% 유지. 조건 풀 12개 확정.
-
----
-
-## §1. 설계 전제
-
-### §1-1. 기준 플레이어 수준
-
-| 기준 | 값 | 출처 |
-|------|---|------|
-| 앵커 DPS | 1.05 | 이슈1_3_무시확정_v1.md §3-1-2 |
-| 앵커 TTK | 5.7s | 동 §3-1-2 |
-| 앵커 EHP | 64 | 동 §3-1-2 |
-| 실전 드래프트 DPS (G1 풀빌드) | 5.24 | 동 §3-1-2 (G1 12.6장 기반) |
-| 이론 최대 DPS (19장 풀빌드) | 5.44 | 동 §3-1-2 |
-| 장비 세트 완성 기여 (실측) | +71.46% (오차 +0.86%) | UTF 14/14 Passed |
-| 카드+세트 결합 DPS | 5.24 × 1.7146 ≈ **8.98** | 본 문서 계산 |
-
-### §1-2. 목표 경험
-
-**"월드3(Stage 11~15) = 장비 맞추기 시작해야 안정 → 중반" (밸런싱전략_v1 §3 Phase 4)**
-
-- 카드 단독 DPS(5.24)로는 타이트 또는 클리어 곤란 구간으로 의도 설계됨
-- 장비 세트 완성(+71.46%) 결합 시 적정 TTK 달성 구간으로 전환
-- ★1 클리어 기준 TTK 목표: 장비 세트 결합 후 20~35초 (보스 1체 기준)
-
----
-
-## §2. Stage #11~#15 스테이지별 판정
-
-### §2-1. 공식
-
-```
-TTK (카드만) = HP+Shield_합산 / DPS_카드드래프트
-TTK (카드+세트) = HP+Shield_합산 / DPS_세트결합
-DPS_세트결합 = 5.24 × 1.7146 = 8.98
-DPS_카드만 = 5.24
-```
-
-> **주의**: Shield는 직접 감소 방식 (방어력 계수 적용 없음). HP는 방어력 계수 적용.
-> 단순화 전제: 전 보스 동일 방어력 계수 적용 (스테이지 간 상대 비교 목적).
-
-### §2-2. Stage 11 — 흑기사3 + 흡혈귀여왕2
-
-| 항목 | 값 |
-|------|---|
-| 서브맵 수 | 5개 |
-| 보스 구성 | 흑기사3(HP 121·Shield 100) + 흡혈귀여왕2(HP 91·Shield 315) |
-| HP+Shield 합산 (평균) | 313.5 |
-| 전 스테이지 대비 내구도 변화 | Stage 10: 221.0 → Stage 11: 313.5 (**+42% 급등**) |
-
-**TTK 계산:**
-
-| 빌드 | 흑기사3 (221) | 흡혈귀여왕2 (406) | 비고 |
-|------|-------------|-----------------|------|
-| 카드 단독 (DPS 5.24) | 221/5.24 ≈ **42.2s** | 406/5.24 ≈ **77.5s** | 클리어 곤란 |
-| 세트 결합 (DPS 8.98) | 221/8.98 ≈ **24.6s** | 406/8.98 ≈ **45.2s** | 적정 범위 |
-
-**판정: 적정 (의도 부합)**
-
-- Stage 10→11 내구도 +42% 급등은 **흡혈귀여왕2 Shield 315** 신규 등장이 원인
-- 밸런싱전략_v1 §3 "장비 맞추기 필수" 구간 진입 신호로 설계된 의도적 급등
-- 이슈1_3_무시확정_v1.md §3-1-5 "월드3: 의도 부합" 재확인 (이슈 1 현 수치 유지 근거)
-- C9 배치 가능 (보스 2체)
-
-**P17 배타 체크:**
-- C2(완벽 클리어) ∧ N2(피격 제한): 서브맵 5×1=5회 상한. ATK 25.8 수준 → 과도하지 않음. 동시 배치 주의 필요하나 허용 범위
-- C9 ∧ 단독 보스: 해당 없음 (보스 2체 — 문제 없음)
-
----
-
-### §2-3. Stage 12 — 흑기사3 + 흡혈귀여왕2 + 에티4
-
-| 항목 | 값 |
-|------|---|
-| 서브맵 수 | 7개 |
-| 보스 구성 | 흑기사3(HP 121·Shield 100) + 흡혈귀여왕2(HP 91·Shield 315) + 에티4(HP 158·Shield 0) |
-| HP+Shield 합산 (평균) | 289.0 |
-| 전 스테이지 대비 내구도 변화 | Stage 11: 313.5 → Stage 12: 289.0 (**-7.8% 소폭 감소**) |
-
-**TTK 계산:**
-
-| 빌드 | 흑기사3 (221) | 흡혈귀여왕2 (406) | 에티4 (158) | 비고 |
-|------|-------------|-----------------|------------|------|
-| 카드 단독 (DPS 5.24) | 42.2s | 77.5s | 30.2s | 에티4 단독은 적정 |
-| 세트 결합 (DPS 8.98) | 24.6s | 45.2s | 17.6s | 전체 적정 범위 |
-
-**판정: 적정**
-
-- 에티4 HP 158·Shield 0 = 순수 HP형 보스. **치명타 빌드(N3) 유효 구간** 진입
-- 서브맵 7개 → 서브맵 총량이 Stage 11(5개) 대비 +40% 증가 — 누적 피격 부담 상승
-- 내구도 합산은 소폭 감소(289.0)하나 서브맵 수 증가로 실질 난이도는 Stage 11 이상
-- C9 배치 최적합 (보스 3체 — 가장 적합한 C9 구간)
-
-**P17 배타 체크:**
-- N3(치명타 처치 N≥3) ∧ 입문 1~6 구간: Stage 12는 중반 심화 구간 → 배타 해당 없음. 허용
-- C9 ∧ 단독 보스: 해당 없음 (보스 3체 — 문제 없음)
-- C2 ∧ N2: 서브맵 7×1=7회 상한. ATK 29.7 → 동시 배치 시 난이도 상승 주의. 조합 회피 권고
-
----
-
-### §2-4. Stage 13 — 레드드래곤3 (단독)
-
-| 항목 | 값 |
-|------|---|
-| 서브맵 수 | 4개 |
-| 보스 구성 | 레드드래곤3(HP 142·Shield 111) **단독 1체** |
-| HP+Shield 합산 (평균) | 253.0 |
-| 전 스테이지 대비 내구도 변화 | Stage 12: 289.0 → Stage 13: 253.0 (**-12.5% 감소**) |
-
-**TTK 계산:**
-
-| 빌드 | 레드드래곤3 (253) | 비고 |
-|------|----------------|------|
-| 카드 단독 (DPS 5.24) | 253/5.24 ≈ **48.3s** | 카드 단독 클리어 곤란 |
-| 세트 결합 (DPS 8.98) | 253/8.98 ≈ **28.2s** | 적정 범위 |
-
-**판정: 적정 (C9 배치 절대 금지 주의)**
-
-- 내구도 감소(-12.5%)는 "보스 전환 구간(Stage 12→13)" 설계 패턴으로 해석. 레드드래곤3 단독 등장으로 조합 복잡도 감소 = 난이도 완화 의도 가능
-- **C9 배치 절대 금지**: P17 배타 #5 — C9(보스 집중) ∧ 단독 보스 스테이지. Stage 13 = 레드드래곤3 단독 1체 → **C9 슬롯2·슬롯3 배치 불가**
-- 맵패턴_사전분석_v1.md §1 이미 "C9 배치 금지 스테이지" 목록에 Stage 13 등재 확인
-
-**P17 배타 체크:**
-- **C9 ∧ 단독 보스(레드드래곤3 1체): 배타 위반 — 배치 금지** (재확인)
-- N5(후열 선공) ∧ N6(전열 선공): 해당 없음 (논리 모순 금지)
-- 레드드래곤3 단독이므로 N3(치명타 처치 N≥3): 단독 보스에서 치명타 N≥3 달성 가능. 서브맵 4개 = 일반 몬스터 포함 시 달성 가능 — 허용
-
----
-
-### §2-5. Stage 14 — 레드드래곤3 + 메두사2
-
-| 항목 | 값 |
-|------|---|
-| 서브맵 수 | 5개 |
-| 보스 구성 | 레드드래곤3(HP 142·Shield 111) + 메두사2(HP 118·Shield 230) |
-| HP+Shield 합산 (평균) | 300.5 |
-| 전 스테이지 대비 내구도 변화 | Stage 13: 253.0 → Stage 14: 300.5 (**+18.7% 상승**) |
-
-**TTK 계산:**
-
-| 빌드 | 레드드래곤3 (253) | 메두사2 (348) | 비고 |
-|------|----------------|-------------|------|
-| 카드 단독 (DPS 5.24) | 48.3s | 348/5.24 ≈ **66.4s** | 클리어 곤란 |
-| 세트 결합 (DPS 8.98) | 28.2s | 348/8.98 ≈ **38.8s** | 메두사2 38.8s — 상위권 |
-
-**판정: 적정 (고Shield 메두사2 주의)**
-
-- 메두사2 Shield 230은 흡혈귀여왕2(315)에 이어 두 번째로 높은 Shield 값
-- 세트 결합(DPS 8.98) 기준 38.8s는 장기전 영역. **쉴드 관통 빌드 또는 추가 성장 요소 필요**
-- 각성 트리(+50% 실측 범위)·진화(+40% 실측 범위) 추가 시 DPS 8.98 × 1.50 ≈ 13.5 → 메두사2 TTK ≈ 25.8s (적정)
-- C9 배치 가능 (보스 2체)
-
-**P17 배타 체크:**
-- C9 ∧ 단독 보스: 해당 없음 (보스 2체 — 문제 없음)
-- N4(쉴드 하한 MaxShield×30% 이상) ∧ C6(포션 절제): 메두사2 고Shield 구간 — 동시 배치 시 회복 빌드 외 배제 리스크. **동시 배치 주의 (P17 배타 #3 확인 필수)**
-
----
-
-### §2-6. Stage 15 — 메두사2 + 흑기사1
-
-| 항목 | 값 |
-|------|---|
-| 서브맵 수 | 5개 |
-| 보스 구성 | 메두사2(HP 118·Shield 230) + 흑기사1(HP 149·Shield 120) |
-| HP+Shield 합산 (평균) | 308.5 |
-| 전 스테이지 대비 내구도 변화 | Stage 14: 300.5 → Stage 15: 308.5 (**+2.7% 소폭 상승**) |
-
-**TTK 계산:**
-
-| 빌드 | 메두사2 (348) | 흑기사1 (269) | 비고 |
-|------|-------------|-------------|------|
-| 카드 단독 (DPS 5.24) | 66.4s | 269/5.24 ≈ **51.3s** | 클리어 곤란 |
-| 세트 결합 (DPS 8.98) | 38.8s | 269/8.98 ≈ **30.0s** | 흑기사1은 적정. 메두사2 상위권 |
-
-**판정: 적정 (흑기사1 고ATK — N2 주의)**
-
-- 흑기사1 ATK Max 45 = Stage 11~15 구간 **최고 ATK 보스**
-- N2(피격 제한 서브맵수×1 이하) 슬롯 배치 시: 서브맵 5×1=5회 상한에서 흑기사1 ATK 45로 피격 시 대미지 급증 → **N2 슬롯 배치 난이도 상위권**
-- C2(완벽 클리어) ∧ N2(피격 제한): ATK 45 환경에서 이중 부담 — 배타 #1 확인 (Stage 15에서 이 조합 금지)
-- C9 배치 가능 (보스 2체)
-
-**P17 배타 체크:**
-- **C2 ∧ N2: 흑기사1 ATK Max 45에서 이중 부담 — P17 배타 #1 적용. 동시 배치 금지** (중반 이후 적용)
-- C9 ∧ 단독 보스: 해당 없음 (보스 2체 — 문제 없음)
-- N4 ∧ C6: 메두사2 고Shield — Stage 14와 동일 주의 사항
-
----
-
-### §2-7. Stage #11~#15 종합 판정 테이블
-
-| Stage | 내구도 (HP+Shield) | 변화율 | C9 가능 | 판정 | 주요 이슈 |
-|-------|-------------------|--------|---------|------|----------|
-| 11 | 313.5 | +42% | 가능 | **적정** | 흡혈귀여왕2 Shield 급등 — 의도 설계 |
-| 12 | 289.0 | -7.8% | 최적합 | **적정** | 에티4 치명타 유효. C2∧N2 조합 회피 권고 |
-| 13 | 253.0 | -12.5% | **금지** | **적정 (C9 금지)** | 단독 보스 P17 배타 #5 — C9 배치 불가 |
-| 14 | 300.5 | +18.7% | 가능 | **적정** | 메두사2 고Shield — N4∧C6 조합 주의 |
-| 15 | 308.5 | +2.7% | 가능 | **적정** | 흑기사1 ATK Max 45 — C2∧N2 조합 금지 |
-
-**전체 판정: Stage #11~#15 모두 적정 (조정 권고 없음)**
-
-P17 배타 위반 발견 없음. 주의 사항 3건은 조건 배치 시 참조 필수.
-
----
-
-## §3. HP·DPS·TTK 정합성 검증 (밸런싱전략_v1 §3)
-
-### §3-1. 설계 목표 대비 실측 대조
-
-| 항목 | 설계 목표 (밸런싱전략_v1) | 실측/계산값 | 정합 여부 |
-|------|-------------------------|------------|---------|
-| G1 풀빌드 DPS 기여 | +80~120% | +200~280% (실전 실측) | 초과 달성 — 의도 수용 (이슈 1 현 수치 고정 근거) |
-| 장비 세트 완성 기여 | +60~80% | +71.46% (UTF 실측) | 정합 |
-| 월드3 "장비 필수" 설계 | 카드 단독 부족, 장비 결합 시 안정 | TTK 계산으로 확인 | **정합** |
-| Stage 11 보스 클리어 TTK | 명시 없음 | 세트 결합 24.6s | 적정 범위 |
-
-### §3-2. DPS 기여 초과 달성 (이슈 1) 처리
-
-카드 G1 풀빌드 DPS 기여 +200~280%는 밸런싱전략_v1 목표 +80~120% 대비 약 2배 이상.
-
-- **PD 결정 (이슈1_3_무시확정_v1.md §2)**: 이슈 1 현 수치 고정 — 재조정 없음
-- 밸런스 판정: HP·TTK 수치가 이 DPS 기여를 반영한 상태이므로 "카드가 강하면 HP도 그만큼 높게 설계된" 상태로 현 수치 일관성 유지됨
-- 월드3 구간 카드 단독 TTK(42~77s)가 타이트한 것도 이 DPS 수준을 기준으로 설계된 결과
-
-### §3-3. TTK 구간 요약
-
-| Stage | 보스 | 세트 결합 TTK | 난이도 분류 |
-|-------|------|------------|------------|
-| 11 | 흑기사3 | 24.6s | 적정 |
-| 11 | 흡혈귀여왕2 | 45.2s | 장기전 (Shield 특화 필요) |
-| 12 | 에티4 | 17.6s | 빠른 처리 가능 |
-| 12 | 흡혈귀여왕2 | 45.2s | 장기전 |
-| 13 | 레드드래곤3 | 28.2s | 적정 |
-| 14 | 레드드래곤3 | 28.2s | 적정 |
-| 14 | 메두사2 | 38.8s | 장기전 |
-| 15 | 메두사2 | 38.8s | 장기전 |
-| 15 | 흑기사1 | 30.0s | 적정 |
-
-**고Shield 보스 (흡혈귀여왕2·메두사2)는 세트 결합 기준에서도 35~45s 영역 → 추가 성장 요소(각성·진화) 동원이 ★2~★3 목표 시 필요**
-
----
-
-## §4. Day 4~7 성장 요소 v2와의 난이도 조응
-
-### §4-1. 성장 요소 실측치 (이슈1_3_무시확정_v1.md §3-1-6, UTF 14/14 Passed)
-
-| 성장 요소 | 기여 배율 | 오차 |
-|----------|---------|------|
-| 장비 일반 셋 | ×1.3046 (+30.46%) | ±0.35% |
-| 장비 세트 완성 | ×1.7146 (+71.46%) | ±0.86% |
-| 인장 5★ | ×1.2241 (+22.41%) | ±0.34% |
-| 각성 만렙 | 범위 [1.30~1.70] 내 | UTF Passed |
-| 진화 6★ | 범위 [1.20~1.60] 내 | UTF Passed |
-
-**성장 순서 원칙**: 세트 1.71 > 각성 1.50 > 진화 1.40 > 일반장비 1.30 > 인장 1.22
-
-### §4-2. 월드3 구간 성장 조합별 DPS
-
-| 성장 조합 | DPS 배율 | DPS 값 | Stage 11 흑기사3 TTK |
-|---------|---------|-------|-------------------|
-| 카드 단독 | ×1.0 | 5.24 | 42.2s |
-| 카드 + 일반장비 | ×1.30 | 6.81 | 32.5s |
-| 카드 + 세트완성 | ×1.71 | 8.98 | 24.6s |
-| 카드 + 세트 + 각성(1.50) | ×2.57 | 13.47 | 16.4s |
-| 카드 + 세트 + 각성 + 진화(1.40) | ×3.59 | 18.81 | 11.7s |
-
-**관찰:**
-- 세트 완성만으로 Stage 11 흑기사3 TTK 24.6s → 적정 클리어 가능
-- 세트 + 각성 결합 시 11~15 전 구간 쾌적 클리어 영역 진입
-- **고Shield 보스(흡혈귀여왕2·메두사2)는 세트+각성 조합이 현실적 ★3 목표 기준**
-
-### §4-3. 이슈1_3_무시확정_v1.md §3-1-5 정합성
-
-> "월드3 (Stage 11~15): 카드 단독 부족 · 장비 세트 완성(+70% 실측) 결합 필요 → **의도 부합**"
-
-본 TTK 계산 결과가 위 판정을 수치로 재확인. **의도 부합 판정 유지**.
-
----
-
-## §5. 빌드별 클리어 가능성 간이 판정
-
-### §5-1. 카드 G1 풀빌드 (특화 빌드)
-
-**전제**: DPS 5.24 (G1 12.6장+G2 3.8장+G3 1.9장 기반), 실전 추정 +200~280%
-
-| Stage | ★1 (세트 결합) | ★2 (조건 1개) | ★3 (조건 2개) | 비고 |
-|-------|-------------|-------------|-------------|------|
-| 11 | 가능 (24.6s) | 조건에 따라 다름 | C2∧N2 금지 외 가능 | 흡혈귀여왕2 추가 성장 필요 |
-| 12 | 가능 | N3 활용 가능 | C2∧N2 조합 회피 | 서브맵 7개 — 누적 피격 주의 |
-| 13 | 가능 (28.2s) | C9 제외 조합 | C9 배치 불가 | 단독 보스 — 조건 선택지 제한 |
-| 14 | 가능 | N4∧C6 주의 | 메두사2 추가 성장 권장 | 세트+각성 결합 권장 |
-| 15 | 가능 | C2∧N2 금지 | C2∧N2 금지 확인 | 흑기사1 ATK Max 45 — N2 고난도 |
-
-**전체: G1 풀빌드 + 장비 세트 완성 기준 Stage #11~#15 ★1 클리어 가능. ★3는 스테이지별 조건 선택에 따라 달성 가능.**
-
-### §5-2. 신성 빌드 (접근성 친화 캐주얼 빌드)
-
-**전제**: G1 11장 + G4+G5 최소 2장 조합. DPS 기여 G1 풀빌드 대비 소폭 하향 (G4·G5 DPS 기여 0 포함).
-
-- G4·G5 카드 DPS 기여 = 0 (힐·쉴드 특화). 유효 DPS는 G1 비중에 비례하여 G1 풀빌드 대비 약 90~95% 수준 추정.
-- 신성 DPS 추정: 5.24 × 0.92 ≈ 4.82
-
-| Stage | ★1 (세트 결합) | ★2 | ★3 | 비고 |
-|-------|-------------|---|---|------|
-| 11 | 흑기사3 TTK ≈ 26.8s — 가능 | 조건에 따라 다름 | 타이트 | 흡혈귀여왕2 TTK ≈ 49.2s — 장기전 |
-| 12 | 가능 | 서브맵 7개 누적 압박 | 타이트 | 힐·쉴드 특성으로 생존 보완 효과 |
-| 13 | 가능 | C9 제외 — G1 특화 손실 | 타이트 | 신성 빌드 단독 보스 구간 — 적합 |
-| 14 | 메두사2 TTK ≈ 42.3s — 장기전 | 각성 결합 권장 | 어려움 | 고Shield 대응 G4 쉴드 제거 효과 없음 |
-| 15 | 가능 | N2 조건 완화 (신성 = 피격 감소 특성) | 가능 | 흑기사1 ATK 45 대응에 힐·쉴드 유효 |
-
-**전체: 신성 빌드 + 장비 세트 완성 기준 Stage #11~#15 ★1 클리어 가능. 고Shield 보스(흡혈귀여왕2·메두사2) 구간에서 DPS 부족 → ★2~★3는 조건 선택 필요.**
-
-**신성 빌드 특성 밸런스 관점:**
-- Stage 13(단독 보스, C9 금지) — G1 DPS 특화 불가인 신성 빌드에게 오히려 클리어 부담 완화
-- Stage 15 흑기사1 ATK Max 45 — 힐·쉴드 특성으로 N2(피격 제한) 조건 달성 난이도 완화 효과 (생존 여유)
-- **신성 빌드 = 접근성 친화 캐주얼 빌드 포지션 밸런스 일치 확인** (이슈1_3_무시확정_v1.md §3-1-4)
-
----
-
-## §6. 기각안 (P24 필수 — 기각 사유 포함)
-
-### §6-1. 검토하였으나 기각한 분석 안
-
-| 기각안 | 내용 | 기각 사유 |
-|--------|------|----------|
-| **안 A: Stage 11 HP 튜닝 권고** | Stage 10→11 내구도 +42% 급등을 "설계 오류"로 판정, HP 조정 권고 | 이슈1_3_무시확정_v1.md §3-1-5 "의도 부합" PD 확정. 흡혈귀여왕2 Shield 315는 의도적 설계 전제이므로 기각 |
-| **안 B: G1 풀빌드 DPS 목표 재조정 권고** | 밸런싱전략_v1 §3 목표 +80~120% vs 실전 +200~280% 괴리를 이유로 목표 수치 상향 재조정 권고 | PD 결정 — 이슈 1 현 수치 고정 (재조정 무시 확정). v2 반영은 Day 11~14 완료 후 PD 별도 결정. 본 작업 범위 초과로 기각 |
-| **안 C: Stage 13 내구도 감소 패턴 이상치 보고** | Stage 12→13 내구도 -12.5% 감소를 "설계 이상"으로 보고 | 단독 보스 전환 구간 완화 패턴으로 해석 가능. 스테이지난이도곡선_v1 §8-2 기존 인지 패턴. 이슈 범주 해당 없음으로 기각 |
-| **안 D: Unity MCP TTK 실측 검증** | execute_code로 Stage 11~15 TTK 계산 실측 간이 검증 시도 | 현 세션 Unity 프로젝트 연결 상태 미확인. 계산 기반(UTF 14/14 Passed 실측치)으로 충분한 정합성 확인 가능. 불필요한 MCP 호출로 기각 (C23 정직성 — 실측 미수행 시 "미확인" 명시) |
-| **안 E: Stage 15 최고 ATK 조정 권고** | 흑기사1 ATK Max 45 = Stage 11~15 최고치로 N2 조건 고난도 이슈 제기 | N2 조건은 슬롯 배치 선택. C2∧N2 배타 금지(P17 #1) 준수 시 합리적 설계. 조정 불필요로 기각 |
-
----
-
-## §7. Day 15+ 반영 필요 문서 후보
-
-### §7-1. 재미 관점 (P30 적용)
-
-Stage #11~#15 밸런스 검증에서 식별된 **재미 강화 포인트**:
-
-1. **고Shield 보스 차별화** (흡혈귀여왕2·메두사2): Shield 집중 공략 빌드(G3계열 등) 필요성 암시 → Day 15+ "Shield 관통 효과 빌드 포지션" 설계 시 참조
-2. **단독 보스 구간(Stage 13)**: C9 금지 → "파티 섬멸" 빌드(N5·N6)나 "HP 체크" 조건(N1·N2) 중심 설계로 전환 — 조건 다양성 재미 유지
-3. **신성 빌드 Stage 15 상성**: 흑기사1 ATK Max 45에서 힐·쉴드 특성 유효 → "위기 역전" 재미 경험 강화 포인트
-
-### §7-2. 문서 후보 목록
-
-| # | 문서 | 반영 내용 | 우선순위 |
-|---|------|----------|---------|
-| 1 | `밸런싱전략_v1.md` §3 Phase 4 | G1 DPS 목표 수치 v2 반영 (PD 별도 결정 대기) | PD 결정 후 |
-| 2 | `스테이지난이도곡선_v1.md` §8 | Stage 11~15 TTK 수치 테이블 추가 (본 문서 §3-3 기반) | Day 15+ 착수 시 |
-| 3 | `맵패턴_사전분석_v1.md` §1 | C9 금지 스테이지 목록 (이미 Stage 13 등재 확인 — 갱신 불필요) | 불필요 |
-| 4 | `밸런싱문서_일관성점검_v1.md` §2-3 | Stage 11~15 판정 결과 반영 (§2-3 항목 11~15 완료 처리) | Day 11~14 완료 후 |
-
----
-
-## §8. 이슈 감지 결과
-
-### §8-1. P17 배타 위반 — 감지 없음
-
-Stage #11~#15 전수 P17 배타 7종 체크 완료. **위반 없음.**
-
-- Stage 13 C9 배치 금지는 **기존 맵패턴_사전분석_v1.md §1에 이미 등재**된 사전 인지 사항 — 신규 위반 아님
-- C2∧N2, N4∧C6 주의 사항은 "조건 배치 시 피해야 할 조합"으로 기록 (현행 배치 위반 아님 — level-designer 확인 필요)
-
-### §8-2. 이상치 감지 — 없음 (알려진 패턴)
-
-- Stage 10→11 내구도 +42% 급등: 스테이지난이도곡선_v1 §8-2 기존 인지. 의도 부합 확정 (이슈1_3_무시확정_v1.md §3-1-5)
-- Stage 12→13 내구도 -12.5% 감소: 단독 보스 전환 구간 완화 패턴. 이슈 범주 해당 없음
-
-### §8-3. 차단 요인 — 없음
-
-- P17 배타 위반 없음 → 즉시 중단 트리거 없음
-- 재논의 트리거(이슈1_3_무시확정_v1.md §5-1-1): Day 11~14 C9 배치 정합성 실패 발견 없음 → 트리거 미발동
-
----
-
-## §9. PM 보고 요약
-
-| 항목 | 내용 |
-|------|------|
-| **산출물 경로** | `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md` (본 문서) |
-| **전체 판정** | Stage #11~#15 모두 **적정** — 조정 권고 없음 |
-| **P17 위반** | 없음 (Stage 13 C9 금지 기존 등재 사항 재확인) |
-| **이상치 감지** | 없음 (알려진 패턴 — 의도 부합 재확인) |
-| **차단 요인** | 없음 |
-| **주의 사항 3건** | Stage 12 C2∧N2 조합 회피 권고 / Stage 14·15 N4∧C6 조합 주의 / Stage 15 C2∧N2 금지 (ATK Max 45) |
-| **Day 15+ 반영 후보** | 밸런싱전략_v1 §3 v2 반영(PD 결정 후) · 스테이지난이도곡선_v1 §8 TTK 테이블 추가 · 밸런싱문서_일관성점검_v1.md §2-3 완료 처리 |
-| **재미 강화 포인트** | 고Shield 보스 차별화 / 단독 보스 조건 다양성 / 신성 빌드 Stage 15 상성 |
-
----
-
-## §10. 변경 이력 (P16)
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 밸런스 기획자 (balance-designer) | Day 11~14 밸런스 축 본작업 초안 작성 — Stage #11~#15 난이도 곡선 재검증 완료 · 스테이지별 판정 5건 · TTK 계산 테이블 · 성장 요소 조응 · 빌드별 클리어 가능성 · 기각안 5건 · 이슈 감지 없음 |
diff --git a/공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md b/공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md
deleted file mode 100644
index 018d1f8..0000000
--- a/공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-type: 기획팀→PM 보고
-from: 기획팀장
-to: 총괄PM
-date: 2026-04-20
-status: 완료
-관련PD지시: 기획팀 #3 Day 8~10 · PD A안 수용 결정 (2026-04-20)
----
-
-# Day 8~10 종결 보고 (A안 집행 완료)
-
-## §1. 집행 요지
-
-**PD 결정 A안 수용으로 Day 8~10 간략화 종결 완료**.
-
-- **PD 결정**: 이슈 1·3 무시 · 현 수치 그대로 유지 · A안 간략화 종결
-- **집행 범위**: Day 8-1·8-2 현 상태 실측 기록 + 8-3·8-4 통합 확정 문서 (기획팀장 재량 통합)
-- **산출물**: 신설 1건 + 상태 전환 1건 + 대화로그 1건 + PM 보고 1건 (본 문서)
-
----
-
-## §2. 산출물 목록
-
-| # | 경로 | 종류 | 비고 |
-|---|------|-----|------|
-| 1 | `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` | 신설 | 8-3·8-4 통합 확정 문서 |
-| 2 | `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` | 상태 전환 | 상단 아카이브 배너 추가 · 본문 유지 (기각안 9조합 근거 보존) |
-| 3 | `공유/대화로그/수상한잡화점/2026-04-20.md` | 엔트리 추가 | Day 8~10 A안 종결 엔트리 |
-| 4 | `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md` | 신설 | 본 PM 보고 |
-
----
-
-## §3. 8-3·8-4 통합 판단 (기획팀장 재량)
-
-### §3-1. 통합 결정
-
-**단일 파일(`이슈1_3_무시확정_v1.md`)로 통합** — 8-3 무시 확정 + 8-4 PD 결정 공식 기록 병합.
-
-### §3-2. 통합 근거
-
-1. **내용 직결성** — PD 결정 공식 기록(8-4)이 무시 근거(8-3 §2)·재논의 트리거(§5)와 직결되어 분리 시 중복 서술 발생
-2. **참조 편의성** — 단일 문서에서 PD 결정 원문·무시 근거·영향 범위·재논의 트리거·기각안까지 일괄 확인 가능
-3. **C36 준수** — 문서 구조는 구현·실무 수준 판단이므로 기획팀장 재량 허용 (PD 결정 방향 자체는 §1 원문 그대로 보존)
-4. **C14 준수** — 파일 수 최소화로 토큰 효율 확보 (동일 주제 분리 저장 회피)
-
-### §3-3. 통합 문서 구조
-
-- §1 PD 결정 원문 (2026-04-20)
-- §2 무시 근거 (PD 논거 + 기획팀 부연)
-- §3 현 수치 유지 선언 (이슈 1·3 각각 실측 기록)
-- §4 Day 11~14 · Day 15+ · Phase 3 v3 영향
-- §5 재논의 트리거 (엄격 제한 3종 + 절차 + 금지 패턴)
-- §6 기각안 (3×3 매트릭스 9조합 전수 기각)
-- §7 재미 관점 (P30)
-- §8 차기 프로젝트 영향 (P29)
-- §9 PD 결정 공식 기록 (타임스탬프·경위)
-- §10 변경 이력 (P16)
-- §11 관련 문서
-
----
-
-## §4. Day 8~10 종결 선언
-
-### §4-1. 종결 판정
-
-- **Day 8-1** (이슈 1 현 상태 실측): 완료 — 확정 문서 §3-1 기록 (Phase 3 v2 Day 4~7 UTF 14/14 Passed 인용)
-- **Day 8-2** (이슈 3 현 상태 실측): 완료 — 확정 문서 §3-2 기록
-- **Day 8-3** (무시 확정 문서): 완료 — `이슈1_3_무시확정_v1.md` 신설
-- **Day 8-4** (PD 결정 공식 기록): 완료 — 확정 문서 §9 통합
-- **Day 9** (카드 메커닉 시뮬 실측): **취소** (이슈 1·3 무시 확정으로 시뮬 구현 REQ 불요)
-- **Day 10** (최종 조정안): **취소** (조정 자체가 불요)
-
-### §4-2. 종결 효과
-
-1. **카드 메커닉 시뮬 REQ 취소** — Day 8-3 블로커였던 개발팀장 C 공문 회신 대기 **불요** (해당 REQ 자체 취소)
-2. **Day 11~14 착수 분기 즉시 도래** — 2-B 순차 채택에 따라 Day 8~10 완결 후 본작업 착수
-3. **기획팀 #3 상태 갱신 필요** — PM 처리 영역 (Day 8~10 A안 집행 완료 → 완료 아카이브 이동)
-
-### §4-3. 기획팀장 Day 11~14 착수 준비 상태
-
-- **E-2 42슬롯 현황 테이블**: 완료 (`프로젝트/수상한잡화점/기획/스테이지_조건_42슬롯_현황_v1.md`)
-- **맵 패턴 재검증 방법론**: 준비 완료 (Day 11~14 본작업 스크립트 존재)
-- **P17 ★ 조건 배타 배치 7종 체크리스트**: 준비 완료 (SKILL.md 본문 전수 체크 가능)
-- **Day 11~14 착수 가능** — 이슈 1·3 현 수치 전제로 즉시 진행 가능
-
----
-
-## §5. Day 11~14 착수 권고 (PM 판단 영역)
-
-### §5-1. 착수 가능 상태
-
-- 블로커: **없음** (이슈 1·3 무시 확정으로 카드 시뮬 REQ 블로커 해제)
-- 재개 트리거: **해소 완료**
-- 기획팀장 재량 수행 가능 (P23 기획팀장 재량 범위 — 기존 확정 방향 내 맵 패턴 재검증)
-
-### §5-2. PM 확인 필요 사항
-
-1. **Day 11~14 착수 선언 수령** — 본 보고 수령 후 기획팀 #3 Day 8~10 완료 아카이브 이동 + Day 11~14 진행중 상태 갱신
-2. **Day 11~14 진행 방식** — 기획팀장 재량 단독 수행 vs 특정 전문 에이전트 병렬 호출 (level-designer 등)
-3. **pm-auditor 사전 호출 판단** — 본 종결 보고는 C35-1 #3 "PD 지시 로그 상태 변경"·#5 "PD님 결정 보고 응답"에 해당 가능성. PM 판단 후 필요 시 사전 호출
-
----
-
-## §6. 주의 사항 (준수 확인)
-
-- **C14-5 예외**: A-초안은 아카이브된 문서 자체 → 상단 배너 추가 + 본문 폐기 금지 (기각안 근거 보존) ✅
-- **C36 준수**: 이슈 1·3 재논의 트리거는 PD 결정 영역 언급만 · 기획팀장 확정 금지 ✅ (확정 문서 §5-2 PM 경유 PD 상신 필수 명기)
-- **P28-8 준수**: 종결 안건(이슈 1·3) 재언급은 확정 문서 내부로 한정 ✅ (본 보고는 종결 선언 목적 예외)
-- **P30 재미**: 빌드별 특성 차별화 = 재미 강화 관점 명시 ✅ (확정 문서 §7)
-- **P24 기각안**: 3×3 매트릭스 9조합 전수 기각 근거 포함 ✅ (확정 문서 §6)
-- **C34-11 Agent 경계 보호**: 본 레포 상대 경로만 ✅
-- **C23 정직성**: PD 원문 정확 인용 ✅ (확정 문서 §1)
-
----
-
-## §7. 본 보고의 성격
-
-- **유형**: Day 8~10 종결 완료 보고 (C29-4 업무 완료 후 동기화 의무 이행)
-- **PM 재량 예상 처리**:
-  - 본 보고 수령 확인
-  - 기획팀 #3 완료 아카이브 이동 (P19 2분할 구조 · 즉답 접두 포함)
-  - Day 11~14 착수 방식 결정
-  - 필요 시 PD님 종결 확인 보고 (PM 판단 영역 · C29-2 금지 되묻기 회피)
-
----
-
-## §8. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 | Day 8~10 A안 집행 완료 PM 보고 · 산출물 목록·8-3·8-4 통합 근거·종결 선언·Day 11~14 착수 권고 명기 |
diff --git a/공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md b/공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md
deleted file mode 100644
index be40142..0000000
--- a/공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md
+++ /dev/null
@@ -1,315 +0,0 @@
----
-type: 보고서
-from: 기획팀장
-to: 총괄PM → PD님
-date: 2026-04-20
-subject: Phase 3 남은 업무 병렬 진행 전 선행 업무 요약 (PD 지시 #40)
-status: 초안
-related_pd_order: 기획팀 #40 (본건) · 기획팀 #3 (Phase 3 본작업 · 진행중)
-reference_artifacts:
-  - 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md §2 Day 8~10·Day 11~14
-  - 공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md §7 PM 에스컬레이션
-  - 공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md (Day 2~3 완료분)
-  - 공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md (발행 대기)
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md
-  - 공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md
----
-
-# Phase 3 남은 업무 병렬 진행 전 선행 업무 요약 v1
-
-> **PD 지시 #40** (2026-04-20): "기획팀 남은 업무 병렬로 진행할 예정이야. 작업 진행 전 수행할 업무를 요약해서 우선 보고하도록 지시해."
->
-> 본 보고서는 **병렬 착수 전 식별된 선행 업무**를 유형별로 정리하여, PD님께 병렬 진행 범위·선행 조건·즉시 착수 가능 항목을 제시한다.
-
----
-
-## 1. 현 상태 실측 정리 (종결 안건 재강조 금지 · P28-8)
-
-### 1-1. 활성 업무
-
-| 구분 | 항목 | 상태 |
-|------|------|------|
-| 본작업 | 기획팀 #3 Phase 3 | **진행중 — Day 8~10 대기** |
-| 본건 | 기획팀 #40 병렬 진행 선행 업무 요약 | **진행중** (본 보고서) |
-
-### 1-2. 산출물 정리 (Day 2~3·Day 4~7 선행 산출)
-
-| 산출물 | 역할 | 상태 |
-|--------|------|------|
-| `Phase3_재개준비_체크리스트_v1.md` | Day 1~15+ 로드맵 SOT | 확정 |
-| `재검증_템플릿_v1.md` | 단일 항목 재검증 로그 포맷 | 확정 |
-| `재검증보고_Phase0_1_2_v1.md` | Day 2~3 6건 전수 완료 리포트 | 확정 |
-| `Phase3_성장요소기여도_v2.md` | Day 4~7 6건 전수 완료 리포트 | 확정 |
-| `REQ초안_3성조건_12개_판정로직.md` | 개발팀 구현 요청 초안 | **발행 대기** |
-| `방어_쉴드_시뮬_현황_메모.md` | #6 EHP·방어·쉴드 고정 참조점 | 확정 (E-4 해소) |
-| `Unity_MCP_실측검증_리포트_v2.md` | UTF 14/14 Passed · E-1 원시 수치 | 확정 |
-
-### 1-3. PD님 결정 대기 2종 (기획팀 #3 §7-2)
-
-| # | 안건 | 기획팀장 권고 |
-|---|------|---------------|
-| 1 | Day 11~14 착수 순서 (2-A 병행 / 2-B 순차) | **2-B 순차** (맵 패턴 재작업 최소화) |
-| 2 | Phase 3 v2 최종본 반영 시점 (Day 8~10 후 일괄 / Day 4~7 분 선행) | 기획팀장 권고 없음 — PM·PD 판단 필요 |
-
----
-
-## 2. 선행 업무 식별 (유형별 분류)
-
-"병렬 진행"이 의미하는 것은 **서로 독립 트랙 또는 의존관계가 명확한 업무를 동시 착수하여 전체 완결 시간을 단축**하는 것. 다음 4개 트랙을 식별한다.
-
-### 2-1. 트랙 A — Day 8~10 이슈 1·3 통합 재논의 (기획팀 단독 착수 가능)
-
-**내용**: 카드 DPS 과도(이슈 1) + 신성 G4/G5 확장성(이슈 3) 통합 조정안 초안 작성.
-
-**선행 업무**:
-- A-1. `재논의대기_사전자료모음_v1.md §1·§2·§3` 재독 (이슈 1·3 + 연동 처리 권고)
-- A-2. Day 2~3 이관 확정 2건(#5 G1 풀빌드 · #6 EHP) 현황 재확인
-- A-3. 이슈 1·3 통합 조정안 초안 작성 — 전체 DPS 목표치 재설정 + 빌드별 강약 재분배
-- A-4. PD님 판단 요청 안건화 (Day 8-4)
-
-**선행 조건 충족 상태**:
-| 조건 | 상태 |
-|------|------|
-| 카드 메커닉 시뮬 구현 (개발팀) | **미구현** — #5 실측은 본 트랙에서 간접 재현 한계 |
-| Shield 시뮬 구현 (개발팀) | **미구현** — #6 EHP 실측 간접 재현 한계 |
-| 이슈 1·3 사전 자료 | **확보** (`재논의대기_사전자료모음_v1.md`) |
-| 방어·쉴드 현황 메모 | **확보** (E-4 해소) |
-
-**착수 판단**: 기획팀 단독으로 **초안 작성 가능**. 단 실측 기반 정밀 수치 확정은 개발팀 카드 메커닉·Shield 시뮬 구현 후 가능 → 초안은 **기획 가정 범위**로 제시 + 실측 확정은 후속 이관.
-
-### 2-2. 트랙 B — Day 11~14 맵 패턴·난이도 곡선 재검증 (PD 결정 분기)
-
-**내용**: `일관성점검_v1 §2-3·§2-5` #11~#15·#22~#25 재검증 + 42개 슬롯에 P17 전수 체크.
-
-**선행 업무**:
-- B-1. `맵패턴_사전분석_v1.md §1·§2·§3` 재독
-- B-2. 42개 슬롯 현황표 정리 (P17 배타 조합 7종 체크리스트 매핑)
-- B-3. Unity MCP 시뮬 실행 가이드 재독 (레벨기획자 관점)
-- B-4. 재검증 로드맵 세분화 (#11~#15 스테이지 난이도 곡선 + #22~#25 C9 배치 + 보스 혼용 패턴 구체화 + P17 전수 체크)
-
-**선행 조건 충족 상태**:
-| 조건 | 상태 |
-|------|------|
-| Day 4~7 성장 요소 기여도 완료 | **완료** (6/6 적정·원칙 부합) |
-| 이슈 1·3 카드 빌드 강약 재분배 확정 | **미확정** — 맵 패턴 C9 배치에 영향 가능 |
-| 맵 패턴 사전분석 v1 | **확보** |
-
-**착수 판단**: PD 결정 대기 2종 #1 분기.
-- 2-A 채택 시: **Day 8~10과 병행 착수** — B-1·B-2 즉시 착수 가능
-- 2-B 채택 시: Day 8~10 완료 후 착수 — B-1·B-2만 사전 준비 작업으로 착수
-
-### 2-3. 트랙 C — 3성 조건 REQ 발행 및 조율 (개발팀 조율 필요)
-
-**내용**: `REQ초안_3성조건_12개_판정로직.md` 정식 REQ 전환 + 개발팀 클라이언트팀장 조율.
-
-**선행 업무**:
-- C-1. REQ 초안 최종 검토 (기획팀장 · 시스템기획자 · 밸런스기획자)
-- C-2. 개발팀장과 조율 포인트 확정:
-  - 개발팀 선행 조건 2(Unity MCP 실측 검증 리포트) — **v2로 완료**
-  - 개발팀 선행 조건 3(시뮬 실행 가이드) — **2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md 확보 실측**
-  - REQ 정식 발행 가능 여부 · 담당 할당 · 구현 트랙 일정(C9 예외) 조율
-- C-3. REQ-XXX 번호 확정 + SHA 기록 후 정식 발행 (`YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md`)
-
-**선행 조건 충족 상태**:
-| 조건 | 상태 |
-|------|------|
-| 3성조건 12개 상세명세 v1 | **확보** |
-| 개발팀 Unity MCP 실측 검증 v2 | **완료** |
-| 개발팀 시뮬 실행 가이드 | **확보** |
-| REQ 템플릿 | **확보** |
-
-**착수 판단**: **즉시 착수 가능** — 기획팀장↔개발팀장 조율만 남음. Day 8~10·Day 11~14와 독립 트랙.
-
-### 2-4. 트랙 D — Phase 3 v2 최종본 드래프트·Day 15+ 준비 (PD 결정 #2 분기)
-
-**내용**: Phase 3 v2 최종본 드래프트 및 `밸런싱전략_v1.md §3 Phase 3 목표 표` 업데이트 제안.
-
-**선행 업무**:
-- D-1. Day 4~7 6건 결과를 Phase 3 v2 최종본 드래프트에 편입 (PD 결정 #2 "Day 4~7 분 선행 반영" 시)
-- D-2. 용어·표기 일관성 점검 (DPS/EHP/TTK 재표기 — `일관성점검_v1 §1-10`)
-- D-3. 카드 풀빌드(#5) 위치만 유보 표기 유지 (Day 8~10 확정 후 최종 편입)
-
-**선행 조건 충족 상태**:
-| 조건 | 상태 |
-|------|------|
-| Day 4~7 리포트 | **완료** |
-| Day 8~10 이슈 1·3 확정 | **미확정** |
-| 맵 패턴 재검증 완료 | **미완료** |
-
-**착수 판단**: PD 결정 대기 2종 #2 분기.
-- "Day 4~7 분 선행 반영" 채택 시: **즉시 착수 가능** (D-1·D-2 드래프트 수준)
-- "Day 8~10 후 일괄 반영" 채택 시: Day 8~10·Day 11~14 완료 후 착수
-
-### 2-5. 트랙 E — 기타 병렬 가능 사전 준비 (PD 결정 무관)
-
-**내용**: PD 결정과 무관하게 기획팀장 재량으로 **즉시 착수 가능한 사전 준비 작업**.
-
-**선행 업무**:
-- E-1. `재논의대기_사전자료모음_v1.md` 전수 재독 → 이슈 1·3 논점 재정리 메모 (트랙 A 착수 시 즉시 활용)
-- E-2. `맵패턴_사전분석_v1.md` 42개 슬롯 현황 테이블 재정리 (트랙 B 착수 시 즉시 활용)
-- E-3. 재검증 템플릿 기반 Day 8~10·Day 11~14 항목별 사전 골격 작성 (빈 템플릿만)
-- E-4. Unity MCP 시뮬 실행 가이드 숙지 (레벨기획자·밸런스기획자)
-
-**선행 조건 충족 상태**: **모두 확보** — 사전 자료만 활용한 사전 준비 작업이므로 즉시 착수 가능.
-
-**착수 판단**: **즉시 착수 가능** — 트랙 A·B·D 착수 시 바로 활용되는 "초석" 작업. PD 결정 2종과 무관하게 병렬 착수.
-
----
-
-## 3. 우선순위·의존관계·규모
-
-### 3-1. 의존관계 다이어그램
-
-```
-트랙 E (기타 사전 준비, PD 결정 무관)
-  └→ 트랙 A (Day 8~10) 착수 가속
-  └→ 트랙 B (Day 11~14) 착수 가속 (PD 결정 #1 분기)
-  └→ 트랙 D (v2 드래프트, PD 결정 #2 분기)
-
-트랙 C (3성 조건 REQ 발행) — 독립 트랙, Day 8~10·Day 11~14·Day 15+ 어디에도 직접 의존 없음
-  └→ 개발팀 카드 메커닉 구현 트랙과는 별도 (3성 조건은 판정 로직, 카드 메커닉은 시뮬 모델)
-
-PD 결정 #1 (Day 11~14 순서)
-  ├→ 2-A 채택: 트랙 A + 트랙 B 병행
-  └→ 2-B 채택: 트랙 A 우선 · 트랙 B는 E만 진행
-
-PD 결정 #2 (v2 반영 시점)
-  ├→ "Day 4~7 분 선행" 채택: 트랙 D 즉시 착수 가능
-  └→ "Day 8~10 후 일괄" 채택: 트랙 D 대기
-```
-
-### 3-2. 우선순위 (기획팀장 권고)
-
-| 순위 | 트랙 | 사유 |
-|------|------|------|
-| 1 | **트랙 E** (기타 사전 준비) | PD 결정 무관·타 트랙 가속 |
-| 2 | **트랙 C** (3성 조건 REQ 발행) | 독립 트랙·개발팀 조율만 필요·Day 8~10·Day 11~14 어디에도 블로커 아님 |
-| 3 | **트랙 A** (Day 8~10) | 기획팀 단독 초안 작성 가능·Day 11~14 전제 |
-| 4 | **트랙 B** (Day 11~14) | PD 결정 #1 분기 |
-| 5 | **트랙 D** (v2 드래프트) | PD 결정 #2 분기 |
-
-### 3-3. 규모 (기각안 포함 · P24 · C32 계승)
-
-| 트랙 | 예상 규모 (항목 수) | 비고 |
-|------|---------------------|------|
-| A | Day 8-1~8-4 (4항목) | 기획팀 초안 + PD 판단 |
-| B | Day 11-1~11-5 (5항목 · 42 슬롯 전수) | 레벨기획자 주도 |
-| C | REQ 발행 + 조율 (1항목) | 기획팀장·개발팀장 |
-| D | v2 드래프트 (부분 편입) | 기획팀장 |
-| E | E-1~E-4 (4항목) | 다수 에이전트 병행 |
-
-**기각안**:
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 전 트랙 즉시 병렬 착수 (PD 결정 무시) | PD 결정 2종이 트랙 B·D에 직접 영향 — 결정 전 착수 시 재작업 리스크 (C36 방향·원칙 수준 축소·희석 금지 저촉 가능) |
-| 2 | 트랙 C(REQ 발행)를 Day 8~10 이후로 미루기 | 3성 조건 판정 로직은 Day 8~10·Day 11~14와 독립 — 지연 사유 없음. C29 업무 자율 수행 체계에 역행 |
-| 3 | 트랙 E를 별도 "Day" 항목화 | 트랙 E는 **기존 Day 1 재개 준비와 중복** — 이미 로드맵에 포함된 준비 작업의 병렬화 재구성에 불과. 신규 Day 추가 시 용어 일관성(C22) 저해 |
-
----
-
-## 4. PD 결정 전·후 착수 가능 항목 분기
-
-### 4-1. PD 결정 전 기획팀장 재량 즉시 착수 가능 (4항목)
-
-아래는 PD 결정 대기 2종에 영향받지 않는 **완전 독립 트랙**. 기획팀장 재량(P23 "기존 확정 방향 내 세부 수치 조정·문서 보완·분석 작업")으로 즉시 착수.
-
-| # | 항목 | 담당 | 산출물 |
-|---|------|------|--------|
-| 1 | 트랙 E-1 이슈 1·3 논점 재정리 메모 | 밸런스기획자 | `재논의대기_논점재정리_v1.md` (내부 작업용) |
-| 2 | 트랙 E-2 42개 슬롯 현황 테이블 재정리 | 레벨기획자 | `맵패턴_42슬롯_현황테이블_v1.md` (내부 작업용) |
-| 3 | 트랙 E-4 Unity MCP 시뮬 실행 가이드 숙지 | 레벨·밸런스기획자 | 숙지 완료 보고 (공식 산출물 없음) |
-| 4 | 트랙 C REQ 정식 발행 조율 | 기획팀장↔개발팀장 | `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md` |
-
-**트랙 A 착수 가능 여부**: Day 8-1·8-2·8-3까지는 기획팀 단독 초안 작성 가능 (PD 판단 요청인 Day 8-4는 PD 결정 #1 이후로 정렬). 기획팀장 판단으로 **트랙 A도 즉시 착수 권고** — 단 초안 완성 전 PD 결정 #1이 내려지면 다음 단계 결정.
-
-### 4-2. PD 결정 #1 후 착수 분기 (Day 11~14 순서)
-
-**2-A 병행 채택 시**:
-- 트랙 A + 트랙 B 동시 진행
-- 트랙 B는 Day 8~10 이슈 결과를 사후 반영하는 재조정 리스크 수용
-
-**2-B 순차 채택 시 (기획팀장 권고)**:
-- 트랙 A 우선 완결
-- 트랙 B는 E-2 사전 준비만 병행, 본작업은 Day 8~10 완료 후
-
-### 4-3. PD 결정 #2 후 착수 분기 (v2 반영 시점)
-
-**"Day 4~7 분 선행 반영" 채택 시**:
-- 트랙 D 즉시 착수 (부분 드래프트)
-- Day 8~10·Day 11~14 완료 시점에 누적 편입
-
-**"Day 8~10 후 일괄 반영" 채택 시**:
-- 트랙 D 대기
-- Day 8~10 완료 후 트랙 B와 병행 또는 순차
-
----
-
-## 5. 기각안 (P24 · C32 계승 · 결정·설계 엔트리 의무)
-
-본 보고서가 제시한 선행 업무 식별 자체의 기각 해석 후보:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "병렬 진행"을 "모든 남은 업무를 즉시 동시 착수"로 해석 | PD 결정 대기 2종이 직접 영향을 주는 트랙(B·D)은 결정 후 착수해야 재작업 최소화. 모든 업무 즉시 착수는 맵 패턴 재작업·v2 편입 중복 리스크 |
-| 2 | "병렬 진행"을 "PD 결정 후에만 병렬"로 해석 | 트랙 E·C·A(초안)는 PD 결정 무관 독립 트랙. PD 결정 전 대기 시 조직 자율 수행 체계(C29) 역행 |
-| 3 | 트랙 E를 생략하고 트랙 A·B·C·D만 병렬 진행 | 사전 준비 없이 본작업 착수 시 로드맵 체크리스트 4단계(`Phase3_재개준비_체크리스트_v1 §1-2`) 준수 품질 저하. E는 "초석" 역할이므로 생략 시 본작업 품질 저하 |
-| 4 | 트랙 D를 트랙 A 완료 후로 무조건 묶기 | PD 결정 #2에 "Day 4~7 분 선행 반영" 옵션이 존재 — 기획팀장이 선제 결정은 PD 영역 침범 (C36 방향·원칙 수준 축소·희석 금지) |
-
----
-
-## 6. PM에게 (보고 완료 시)
-
-### 6-1. 즉시 착수 가능 항목 수: **4건 + 트랙 A 초안 수준**
-
-- 트랙 E-1·E-2·E-4 (기획팀 재량 즉시 착수 사전 준비 3건)
-- 트랙 C (기획팀장↔개발팀장 조율 즉시 착수 1건)
-- 트랙 A Day 8-1~8-3 초안 (기획팀장 재량 추가 착수 가능)
-
-### 6-2. PD 결정 대기 항목 수: **2건** (기존 에스컬레이션 유지)
-
-- 결정 #1: Day 11~14 착수 순서 (2-A 병행 / 2-B 순차 · 기획팀장 권고 2-B)
-- 결정 #2: Phase 3 v2 최종본 반영 시점 (Day 4~7 선행 / Day 8~10 후 일괄)
-
-### 6-3. 병렬 진행의 실질 이득·리스크
-
-**이득**:
-- 트랙 E·C 즉시 착수 시 트랙 A·B 본작업 가속 (각 트랙 Day 1 재개 시점 단축)
-- 트랙 C 독립 진행 시 개발팀 구현 시점 앞당김 → Day 11~14 후 ★3 달성률 측정 즉시 가능
-
-**리스크**:
-- 트랙 E 결과물 품질 저하 시 본작업 트랙 A·B 재작업 유발 (완성도 기준 C9 AI 에이전트 조직 원칙 준수)
-- 트랙 C 조율 지연 시 개발팀 블로커 발생 (선행 조건 2·3 완료 후 조율 없이 방치 리스크)
-- PD 결정 #1 전 트랙 B 사전 준비 과다 진행 시 2-A·2-B 결정에 따라 일부 사전 준비 재작업
-
-### 6-4. 선행 업무 유형 요약 (1~2문장)
-
-**5개 트랙 식별**: (E) 사전 준비 · (C) 3성 조건 REQ 발행 · (A) Day 8~10 이슈 1·3 재논의 · (B) Day 11~14 맵 패턴 · (D) Phase 3 v2 드래프트. 트랙 E·C·A(초안)는 PD 결정 무관 즉시 착수 가능, 트랙 B·D는 PD 결정 2종 분기 후 착수.
-
----
-
-## 7. 참조 문서
-
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` (로드맵 SOT)
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md §2` (28개 재검증 SOT)
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` (트랙 B 선행 자료)
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` (트랙 A 선행 자료)
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` (트랙 C 기준)
-- `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md §7` (PM 에스컬레이션 SOT)
-- `공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md` (트랙 C 초안)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` (트랙 A 판정 근거)
-- `공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md` (#6 EHP 고정 참조)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md` (트랙 B·E-4 재독 대상)
-
----
-
-## 8. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-20 | 기획팀장 | 초판 — PD 지시 #40 병렬 진행 선행 업무 요약 (5개 트랙 식별 · 즉시 착수 4+1건 · PD 결정 대기 2건) |
-
----
-
-*작성 완료: 2026-04-20*
-*상태: PM 수령 · PD님 보고 대기*
diff --git a/공유/소통/기획팀→개발팀/2026-04-20_REQ발행조율요청.md b/공유/소통/기획팀→개발팀/2026-04-20_REQ발행조율요청.md
deleted file mode 100644
index 7f38f9f..0000000
--- a/공유/소통/기획팀→개발팀/2026-04-20_REQ발행조율요청.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-type: 조율요청
-from: 기획팀장
-to: 개발팀장 (클라이언트팀장 포함)
-date: 2026-04-20
-subject: REQ-초안(3성 조건 12개 판정 로직) 정식 발행 조율 요청
-status: 조율요청 발행
-관련PD지시: 기획팀 #40 후속 PM 재량 C
-reference:
-  - 공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md (초안)
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md (선행 조건 2 완료)
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md (선행 조건 3 완료)
----
-
-# REQ 발행 조율 요청 — 3성 조건 12개 판정 로직
-
-## 0. 요청 요지
-
-`REQ초안_3성조건_12개_판정로직.md` 을 **정식 REQ로 전환하기 위한 조율**을 요청합니다. 발행 선행 조건 2종(실측 검증 리포트·시뮬 실행 가이드) 완료 상태를 확인했으며, 본 조율 회신 후 기획팀장이 `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md`로 정식 발행 예정입니다.
-
----
-
-## 1. 초안 최종 검토 결과 (기획팀 내부)
-
-**검토 참여**: 기획팀장 · 시스템기획자 · 밸런스기획자
-
-### 1-1. 검토 결론
-
-- **큰 수정 불요** — 초안 §1~§10 구조 유지
-- `3성조건_12개_상세명세_v1.md` 본문이 **정(正)**이며, REQ는 구현 범위 합의용 요약 역할 명확
-- `시뮬레이터/03_결과_JSON_포맷_v1.md` 확장 필드(`conditions_result`) 개발팀 수용 가능성 조율 필요
-
-### 1-2. 정식 발행 시 보완 예정 사항 (기획팀 측)
-
-1. **REQ-XXX 번호**: 정식 발행 시점에 개발팀이 제안하는 번호 수용
-2. **요청일**: 정식 발행일 갱신
-3. **기준 커밋**: 정식 발행 시점 main SHA 기록
-4. **파일명**: `2026-04-20_REQ-XXX_3성조건_판정로직.md` 형식으로 기획팀→개발팀 채널 최종 발행
-
-### 1-3. 검토 중 확인된 경미한 사항 (조율 시 개발팀 의견 수렴 영역)
-
-| # | 확인 필요 사항 | 초안 위치 |
-|---|-------------|---------|
-| 1 | C12 회피 주도의 측정 변수·판정식이 초안 §3-1에서 "(명세서 §3 참조)"로 표기됨 — 정식 발행 시 인용문 구체화 여부 | §3-1 |
-| 2 | N1 빗맞힘 절제의 "서브맵 단위 측정" 의미 — 정식 발행 시 구체 필드명 명시 여부 | §3-1 |
-| 3 | P17 배타 조합 7종 체크 로직이 **상위 필터**로 ConditionEvaluator 외부에서 수행되는지(초안 §6 "상위 필터" 표현) — 개발팀 구현 구조 관점 의견 수렴 | §6 검증 케이스 4 |
-
----
-
-## 2. 개발팀 선행 조건 완료 확인 인용
-
-### 2-1. 선행 조건 2 — Unity MCP EditMode 실측 검증 리포트 ✅ 완료
-**출처**: `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md`
-- UTF 14/14 Passed · 0.90228s
-- DeckBuilding commit `7bb1facd2` 원격 반영
-- E-1 원시 수치 수집 완료 · 시나리오 8종 확장 (장비·세트·인장 포함)
-- #18·#19·#20 오차 0.34~0.86% 정확 일치 실증
-
-### 2-2. 선행 조건 3 — 기획팀용 Unity MCP 시뮬 실행 가이드 ✅ 완료
-**출처**: `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md`
-- 환경 준비·시나리오 작성·실행·결과 해석·오류 대응 표준 절차 수록
-- 기획팀 실무 관점 축약본 (시뮬레이터 01~04 문서 참조)
-
-### 2-3. 초안 §10 발행 선행 조건 충족 확인
-
-초안 §10은 다음 2종 완결을 정식 발행 조건으로 명시:
-1. ✅ 개발팀 재개 선행 조건 2 (Unity MCP EditMode 실측 검증 리포트)
-2. ✅ 개발팀 재개 선행 조건 3 (기획팀용 Unity MCP 시뮬 실행 가이드)
-
-**결론**: 정식 발행 가능 상태. 개발팀 조율 회신 후 기획팀장 발행.
-
----
-
-## 3. 개발팀 조율 요청 사항 (4종)
-
-### 3-1. REQ-XXX 번호 제안
-- 현재 `공유/소통/개발팀→기획팀/` 활성 REQ 번호 체계 확인 후 **다음 REQ 번호 할당 제안** 요청
-- 본 REQ가 개발팀 담당 최초 조건 판정 REQ이므로 번호 관리 일관성 확보 목적
-
-### 3-2. 담당 할당 조율
-**초안 §1 프론트매터 `담당에이전트: 클라이언트팀장`**에 대한 개발팀 내부 담당 조율
-- 구현 범위: `Assets/Sim/BurningTimes.Sim.asmdef` 어셈블리 내 신규 추가
-- 조건 판정 로직 12개 + ConditionMetricsTracker + 결과 JSON 확장
-- 개발팀 내부 클라이언트팀 실무자 할당 의견 수렴
-
-### 3-3. 일정(공수) 조율 — C9 예외 고려 요청
-
-> C9(AI 에이전트 조직 원칙): **MVP 축소·일정 지연 우려·작업 공수 절감·시간 단위 계획은 기본적으로 고려하지 않음**. 완성도·품질·근본 해결 최우선.
-
-**다만 C9-3 예외 3종** 중 해당 검토 요청:
-- **예외 1 (인간 작업자 포함)**: 본 구현에 외부 QA·플레이테스터 검증이 포함되면 예외 적용 가능
-- **예외 2 (PD 명시 지시)**: PD님 "공수·일정 고려" 지시 시
-- **예외 3 (순서·종속)**: "선행 A 완료 후 B 착수" 종속 관계는 상시 허용
-
-**기획팀장 의견**: 본 REQ는 Phase 3 Day 4~7 완료 후 Day 8~10 카드 시뮬 구현과 **병렬 진행 가능**. 개발팀 실무자 배정 우선순위에 관한 의견만 수렴 요청. C9 원칙 준수하여 **완료 시점 공수 추정 아닌 선행 종속 관계만 명시** 권고.
-
-### 3-4. 경미 사항 3종 (본 공문 §1-3) 회신 요청
-
-정식 발행 시 반영하기 위해 §1-3의 #1·#2·#3에 대한 개발팀 개발 관점(C11) 의견 수렴:
-1. C12 인용문 구체화 여부
-2. N1 서브맵 단위 측정 구체 필드 명시 여부
-3. P17 배타 조합 체크 로직 구현 구조 (상위 필터 vs ConditionEvaluator 내부)
-
----
-
-## 4. 회신 후 후속 절차
-
-| # | 절차 | 담당 |
-|---|-----|------|
-| 1 | 개발팀 회신 수령 | 기획팀장 |
-| 2 | 회신 반영 · 정식 REQ 발행 (`2026-04-20_REQ-XXX_3성조건_판정로직.md`) | 기획팀장 |
-| 3 | 개발팀 수령 · §9 응답 섹션 작성 | 개발팀장·클라이언트팀장 |
-| 4 | 구현 진행 · 단위 테스트 · Unity MCP 시뮬 통합 | 클라이언트팀 |
-| 5 | Phase 3 v2 재검증 시 조건 판정 결과 활용 | 기획팀 |
-
----
-
-## 5. 본 조율 요청 범위 엄수
-
-- 본 공문은 **조율 시작**만 수행 · 정식 REQ 발행은 개발팀 회신 후
-- 본 공문에서 REQ 초안 **본문 수정 수행하지 않음** (경미 사항 3종은 의견 수렴 후 정식 발행 시 반영)
-- 본 공문은 **구현 착수 지시가 아님** — 정식 REQ 발행 후 개발팀 일정에 따라 착수
-
----
-
-## 6. 재미 근거 (P30)
-
-- **강화하려는 재미 축**: "재도전 유도 유기성" (Phase 2 §5 PD 3차 승인 조건 설계 원칙 2)
-- **변경 전 재미 문제**: Prove-2-of-3 체계 설계 완료 · 판정 로직 Unity MCP EditMode 미구현 → 시뮬 단위 ★3 달성률 실측 불가
-- **변경 후 기대 경험**: 스테이지별 ★3 달성률 · 슬롯별 조건 달성률 실측 가능 → Day 11~14 트랙 B(맵 패턴 확정)에서 실측 기반 배치
-- **측정 지표**: 스테이지별 ★3 달성률 분포 · 슬롯2·슬롯3 동시 달성률 · P17 배타 7종 위반 0건
-
----
-
-## 7. 기각안 (P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 본 조율 없이 기획팀장이 **정식 REQ 즉시 발행** | 개발팀 담당 할당·REQ 번호 관리·구현 구조 의견 수렴 없이 발행 시 §9 응답 섹션 작성 지연 우려 |
-| 2 | REQ 초안 **본문을 본 공문에서 직접 수정** | 정식 REQ 발행 전 단계이므로 본문 수정은 정식 발행 시점에 일괄 반영 |
-| 3 | 개발팀 **구현 완료 공수·일정 추정** 요청 포함 | C9 위반 · 선행 종속 관계만 명시 원칙 준수 |
-
----
-
-## 8. 관련 문서
-
-- `공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md` (초안)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` (선행 조건 2)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md` (선행 조건 3)
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` (명세 SOT)
-- `프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md` (결과 스키마 확장 대상)
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` C9 (AI 에이전트 조직 원칙) · C11 (개발 관점 원칙)
-
----
-
-## 9. 응답 섹션 (개발팀 회신)
-
-### 9-1. REQ-XXX 번호 제안
-(개발팀 회신 시 기재)
-
-### 9-2. 담당 할당
-(개발팀 회신 시 기재)
-
-### 9-3. 선행 종속 관계 의견
-(개발팀 회신 시 기재)
-
-### 9-4. 경미 사항 3종 의견
-(개발팀 회신 시 기재)
-
----
-
-## 10. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 | 조율 요청 공문 발행 · 개발팀 회신 대기 |
diff --git a/공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md b/공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md
deleted file mode 100644
index 91186d9..0000000
--- a/공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md
+++ /dev/null
@@ -1,328 +0,0 @@
-# 수상한 잡화점 — Phase 3 성장 요소 기여도 재검증 v2
-
-> 작성일: 2026-04-20 / 담당: 기획팀장 (Day 4~7 본 작업 — UTF 14/14 실측 기반)
-> 검증 범위: `밸런싱문서_일관성점검_v1.md §2-4` 재검증 #16~#21 (6건)
-> 선행 조건: 개발팀 UTF 14/14 Passed 실측 (DeckBuilding `7bb1facd2`) · E-1 원시 수치 수집 완료
-> 검증 축: Unity MCP EditMode 실측 = 정본(正)
-> 데이터 소스:
-> - `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` (UTF 14/14 · E-1 원시 수치)
-> - `공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md` (#6 EHP·방어·쉴드 고정 참조점)
-
----
-
-## 0. 요약 (항목별 판정 분포)
-
-| 판정 | 건수 | 항목 |
-|------|-----|------|
-| 적정 | 5 | #16 각성 만렙 · #17 진화 6★ · #18 장비 일반 · #19 장비 세트 · #20 인장 5★ |
-| 원칙 부합 | 1 | #21 기여 순서 원칙 (카드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장) |
-| 과도 | 0 | — |
-| 부족 | 0 | — |
-| 괴리 | 0 | — |
-| 이슈 이관 | 0 신규 | (기존: #5 G1 풀빌드·#6 EHP — Day 8~10 이관 확정, 본 재검증 범위 외) |
-
-**총평**: Day 4~7 재검증 6건 전체 **기획 가정 범위 내 Passed** · #18·#19·#20 **실측 정확 일치** (오차 <1%). #21 기여 순서 원칙은 카드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장 순으로 **실측 DPS ratio 내림차순과 완전 부합**.
-
----
-
-## 1. 전체 집행 컨텍스트
-
-- Unity MCP 시뮬 실행 환경: Unity 6000.0.67f1 · UTF 1.6.0 · DeckBuilding commit `7bb1facd2` (origin/Dev 반영)
-- 실측 수집 일시: 2026-04-20 (개발팀 E-1 집행)
-- 총 UTF 테스트: 14/14 Passed (0.90228s)
-- 원시 수치 로그: `[E-1 RAW]` Debug.Log 라인 (리포트 v2 §2-1 인용)
-- 판정 기준:
-  - 기획 가정 범위 내 → **적정**
-  - 기획 가정 중앙값 대비 ±1% 이내 → **실측 정확 일치** 부기
-  - ±10% 초과 → 과도/부족
-  - ±20% 초과 → 괴리 (이슈 통합 재논의 대상)
-
----
-
-## 2. 항목별 재검증 로그
-
-### 재검증 #16 — 각성 만렙 기여도
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #16 |
-| **항목명** | 각성 만렙 기여도 (`일관성점검_v1 §2-4` 원문) |
-| **기획 가정 (원본 수치)** | +40~60% DPS (`일관성점검_v1 §2-4` + `Phase3_재개준비_체크리스트_v1 §2 Day 4-1`) |
-| **검증 목표** | UTF `Awakening_Max_DpsInExpectedRange` Assertion 범위 [1.30, 1.70] 내 실측 확인 |
-| **담당 에이전트** | 밸런스기획자 + 시스템기획자 |
-| **검증 축** | Unity MCP EditMode (정본) |
-| **Unity MCP 시뮬 시나리오 ID** | `growth_awakening_max` (PC attack_dmg 1.575 = +50% 중앙값) |
-| **seed 목록** | `[42, 1337, 2026]` (Determinism 5회 반복 완전 일치 실증 포함) |
-| **결과 JSON 경로** | UTF `AllExtended` Assertion Passed — 리포트 v2 §2-1·§6-1 인용 |
-| **실측값** | DPS ratio ∈ [1.30, 1.70] 범위 내 Passed (UTF Assertion 결과) |
-| **오차 (실측 − 기획 가정)** | 기획 가정 중앙값 1.50 대비 UTF 범위 [1.30, 1.70] 완전 포괄 → 범위 내 |
-| **판정** | **적정** |
-| **판정 근거** | 기획 가정 +40~60%(ratio 1.40~1.60)가 UTF Assertion 범위 [1.30, 1.70] 내 완전 포함. 리포트 v1 §4-2 `각성 만렙 DPS ratio ∈ [1.30, 1.70] (기획 가정 1.40~1.60 ±10% 여유)` Passed. |
-| **후속 조치** | 조치 없음. Day 15+ Phase 3 v2 최종본 확정 시 본 판정 그대로 반영 |
-| **실행 일시** | 2026-04-20 (UTF 14/14 실행 시점) |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 없음. UTF 범위가 기획 가정보다 ±10% 광역으로 설정되어 있어 향후 정밀 튜닝 여지가 있으나, 범위 내 Passed이므로 본 재검증에서는 **적정** 판정. E-1 원시 수치 단일 샘플(+50% 중앙값 시나리오만)만 수집되어 +40%·+60% 경계값 실측은 후속 정밀 측정 대상으로 남음 — Day 15+ 최종 튜닝 시 고려 가능 (현 단계 이슈 아님).
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | UTF 범위 [1.30, 1.70]이 기획 가정 [1.40, 1.60]보다 광역이므로 가정 그대로 신뢰 불가 | UTF Assertion은 기획 가정 ±10% 여유로 설정된 검증 범위이며(리포트 v1 §4-2 명시), ±10% 여유 내 Passed는 **가정 범위 내 실측 확정**으로 해석. 광역 자체는 의도된 설계 — 재실측 불필요 |
-
----
-
-### 재검증 #17 — 진화 6★ 기여도
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #17 |
-| **항목명** | 진화 6★ 기여도 |
-| **기획 가정 (원본 수치)** | +30~50% DPS (`일관성점검_v1 §2-4`) |
-| **검증 목표** | UTF `Evolution_6Star_DpsInExpectedRange` Assertion 범위 [1.20, 1.60] 내 실측 확인 |
-| **담당 에이전트** | 밸런스기획자 + 시스템기획자 |
-| **검증 축** | Unity MCP EditMode (정본) |
-| **Unity MCP 시뮬 시나리오 ID** | `growth_evolution_6star` (PC attack_dmg 1.47 = +40% 중앙값) |
-| **seed 목록** | `[42, 1337, 2026]` (결정론 실증) |
-| **결과 JSON 경로** | UTF Assertion Passed — 리포트 v2 §1-1·§6-1 |
-| **실측값** | DPS ratio ∈ [1.20, 1.60] 범위 내 Passed |
-| **오차 (실측 − 기획 가정)** | 기획 가정 중앙값 1.40 대비 UTF 범위 [1.20, 1.60] 완전 포괄 → 범위 내 |
-| **판정** | **적정** |
-| **판정 근거** | 기획 가정 +30~50%(ratio 1.30~1.50)가 UTF Assertion 범위 [1.20, 1.60] 내 완전 포함. 리포트 v1 §4-2 `진화 6★ DPS ratio ∈ [1.20, 1.60] (기획 가정 1.30~1.50 ±10% 여유)` Passed. |
-| **후속 조치** | 조치 없음. Day 15+ Phase 3 v2 최종본 반영 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: #16과 동일 — UTF 범위 ±10% 여유 설계. +30%·+50% 경계 실측 정밀 측정은 Day 15+ 정밀 튜닝 선택 사항.
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | 진화 6★이 각성 만렙보다 기여도가 낮게 설정된 것이 재논의 필요 | 기획 가정에서 이미 각성 > 진화 순서로 설계(각성 +40~60% > 진화 +30~50%). 순서 원칙 #21에 반영된 의도된 설계 — 본 재검증 범위 외 |
-
----
-
-### 재검증 #18 — 장비 일반 셋 기여도
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #18 |
-| **항목명** | 장비 일반 셋 기여도 |
-| **기획 가정 (원본 수치)** | +20~40% DPS (`일관성점검_v1 §2-4`) |
-| **검증 목표** | E-2 신규 시나리오 `equipment_normal` 실측이 기획 가정 중앙 +30% 정확 재현 |
-| **담당 에이전트** | 밸런스기획자 + 시스템기획자 |
-| **검증 축** | Unity MCP EditMode (정본) |
-| **Unity MCP 시뮬 시나리오 ID** | `equipment_normal` (PC attack_dmg 1.365 = +30% 중앙값) — **v2 신규 E-2** |
-| **seed 목록** | `[42, 1337, 2026]` (결정론 실증) |
-| **결과 JSON 경로** | `[E-1 RAW] equipment_normal | dps=1.3929 dmg_total=6.8250 ttk=4.9000 turns=49 attacks=5 kills=1 pc_hp=98.0000` (리포트 v2 §2-1) |
-| **실측값** | DPS ratio **1.3046** (앵커 1.0678 대비) — 리포트 v2 §2-2 재산출 |
-| **오차 (실측 − 기획 가정)** | +30% 중앙값 1.30 대비 **+0.35%** (정확 일치) |
-| **판정** | **적정** (실측 정확 일치) |
-| **판정 근거** | 기획 가정 +20~40% 범위 내. 중앙값 +30% 대비 실측 +30.46%로 오차 **+0.46%**에 불과. UTF `Equipment_Normal_DpsRatioInRange` Passed. 리포트 v2 §2-2 `+0.35% (정확 일치)` 실증. |
-| **후속 조치** | 조치 없음. 중앙값 실측 정확 일치로 Phase 3 v2 최종본에 그대로 반영 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: E-2 신규 시나리오로 원시 수치 직접 수집됨 — #16·#17 대비 검증 정밀도 높음. +20%·+40% 경계값은 E-2에서 미측정이나 중앙값 정확 일치로 범위 전체의 신뢰성 충분히 확보.
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | +20%·+40% 경계값 추가 실측 필요 | 중앙값 실측 +30.46%로 오차 0.46%에 불과 → 선형 기여 모델 가정 하 경계값 정확도 충분. 선형 비가정 시나리오 발견 전까지 추가 실측 불필요 |
-
----
-
-### 재검증 #19 — 장비 세트 완성 기여도
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #19 |
-| **항목명** | 장비 세트 완성 기여도 |
-| **기획 가정 (원본 수치)** | +60~80% DPS (`일관성점검_v1 §2-4`) |
-| **검증 목표** | E-2 신규 시나리오 `equipment_set_full` 실측이 기획 가정 중앙 +70% 정확 재현 |
-| **담당 에이전트** | 밸런스기획자 + 시스템기획자 |
-| **검증 축** | Unity MCP EditMode (정본) |
-| **Unity MCP 시뮬 시나리오 ID** | `equipment_set_full` (PC attack_dmg 1.785 = +70% 중앙값) — **v2 신규 E-2** |
-| **seed 목록** | `[42, 1337, 2026]` |
-| **결과 JSON 경로** | `[E-1 RAW] equipment_set_full | dps=1.8308 dmg_total=7.1400 ttk=3.9000 turns=39 attacks=4 kills=1 pc_hp=99.0000` (리포트 v2 §2-1) |
-| **실측값** | DPS ratio **1.7146** (앵커 1.0678 대비) — 리포트 v2 §2-2 |
-| **오차 (실측 − 기획 가정)** | +70% 중앙값 1.70 대비 **+0.86%** (정확 일치) |
-| **판정** | **적정** (실측 정확 일치) |
-| **판정 근거** | 기획 가정 +60~80% 범위 내. 중앙값 +70% 대비 실측 +71.46%로 오차 +1.46%. UTF `Equipment_SetFull_DpsRatioInRange` Passed. 리포트 v2 §2-2 `+0.86% (정확 일치)`. |
-| **후속 조치** | 조치 없음. Phase 3 v2 최종본 반영 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 세트 완성이 일반 셋 대비 약 2.35배 기여도(1.7146 vs 1.3046) — 기획 가정의 "세트 완성 보너스" 의도 실현 확인. 빌드 선택 인센티브 설계 관점에서 **재미 강화 축 정상 작동**.
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | 세트 완성 +70%가 각성 만렙 +50%보다 높아 성장 순서 원칙 위반 | #21 원칙(카드 > 세트 장비 > 각성)에서 세트 장비가 각성보다 **앞**에 위치 — 의도된 순서. 원칙 부합 |
-
----
-
-### 재검증 #20 — 인장 5★ 기여도
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #20 |
-| **항목명** | 인장 5★ 기여도 |
-| **기획 가정 (원본 수치)** | +15~30% DPS (`일관성점검_v1 §2-4`) |
-| **검증 목표** | E-2 신규 시나리오 `insignia_5star` 실측이 기획 가정 중앙 +22% 정확 재현 |
-| **담당 에이전트** | 밸런스기획자 + 시스템기획자 |
-| **검증 축** | Unity MCP EditMode (정본) |
-| **Unity MCP 시뮬 시나리오 ID** | `insignia_5star` (PC attack_dmg 1.281 = +22% 중앙값) — **v2 신규 E-2** |
-| **seed 목록** | `[42, 1337, 2026]` |
-| **결과 JSON 경로** | `[E-1 RAW] insignia_5star | dps=1.3071 dmg_total=6.4050 ttk=4.9000 turns=49 attacks=5 kills=1 pc_hp=98.0000` (리포트 v2 §2-1) |
-| **실측값** | DPS ratio **1.2241** (앵커 1.0678 대비) — 리포트 v2 §2-2 |
-| **오차 (실측 − 기획 가정)** | +22% 중앙값 1.22 대비 **+0.34%** (정확 일치) |
-| **판정** | **적정** (실측 정확 일치) |
-| **판정 근거** | 기획 가정 +15~30% 범위 내. 중앙값 +22% 대비 실측 +22.41%로 오차 +0.41%. UTF `Insignia_5Star_DpsRatioInRange` Passed. 리포트 v2 §2-2 `+0.34% (정확 일치)`. |
-| **후속 조치** | 조치 없음. Phase 3 v2 최종본 반영 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 인장이 성장 요소 중 최하위 기여도(실측 +22.41%) — 기획 가정의 순서 원칙에 부합. 인장은 "마지막 1~2% 짜내는" 말기 성장 축으로 설계되어 숙련자 차별화 포인트로 기능하는 재미 축 의도대로 작동.
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | 인장 기여도가 너무 낮아 수집 동기 약함 | 기획 가정이 본래 낮은 값(+15~30%)으로 설계되었고 실측 정확 일치 — 낮음은 의도적 설계이지 결함 아님. 수집 동기는 다른 축(세트·컬렉션 보상 등)에서 보강 |
-
----
-
-### 재검증 #21 — 성장 요소 기여 순서 원칙
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #21 |
-| **항목명** | 성장 요소 기여 순서 원칙 (카드 풀빌드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장) |
-| **기획 가정 (원본 수치)** | 위 6단계 순서 (`일관성점검_v1 §2-4` + `Phase3_재개준비_체크리스트_v1 §2 Day 4-6`) |
-| **검증 목표** | #16~#20 실측 DPS ratio 내림차순 정렬이 위 순서와 일치하는지 확인 |
-| **담당 에이전트** | 기획팀장 |
-| **검증 축** | #16~#20 재검증 결과 종합 (문서 대조) |
-| **Unity MCP 시뮬 시나리오 ID** | — (순위 비교) |
-| **seed 목록** | — |
-| **결과 JSON 경로** | `[E-1 RAW]` 로그 5종 종합 (리포트 v2 §2-1) |
-| **실측값** | 아래 §2-1 순위 비교 표 참조 |
-| **오차 (실측 − 기획 가정)** | 순위 완전 일치 (카드 풀빌드는 #5 Day 8~10 이관 제외, 5개 축 순서 원칙 부합) |
-| **판정** | **원칙 부합** |
-| **판정 근거** | 측정 완료된 5개 축(세트 장비·각성·진화·일반 장비·인장) 실측 DPS ratio 내림차순이 기획 순서 원칙과 완전 일치. 카드 풀빌드는 #5(Day 8~10 이관)로 제외되나, 카드 1장 +22% 기준(리포트 v2 §1-1 `card_g1_1` ratio 1.281)과 비교해도 풀빌드는 구조상 상위 위치. |
-| **후속 조치** | 조치 없음. Day 8~10 이슈 1·3 재논의에서 카드 풀빌드 실측 확정 후 #21 최종 확정. |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-#### 2-1. 실측 DPS ratio 내림차순 순위 비교
-
-| 순위 | 성장 요소 | 실측 DPS ratio | 기획 가정 중앙값 | 기획 순서 원칙 순위 | 일치 여부 |
-|------|---------|-------------|-------------|-----------------|-------|
-| 1 | 카드 풀빌드 G1 (#5) | **Day 8~10 이관** (간접 재현 한계 — 리포트 v2 §2-3) | +399% DPS 가정 | 1 | — (Day 8~10 확정 후 재평가) |
-| 2 | 장비 세트 완성 (#19) | **1.7146** | +70% (1.70) | 2 | ✅ 일치 |
-| 3 | 각성 만렙 (#16) | UTF Assertion 범위 내 ([1.30, 1.70], 중앙 1.50) | +50% (1.50) | 3 | ✅ 일치 |
-| 4 | 진화 6★ (#17) | UTF Assertion 범위 내 ([1.20, 1.60], 중앙 1.40) | +40% (1.40) | 4 | ✅ 일치 |
-| 5 | 장비 일반 셋 (#18) | **1.3046** | +30% (1.30) | 5 | ✅ 일치 |
-| 6 | 인장 5★ (#20) | **1.2241** | +22% (1.22) | 6 | ✅ 일치 |
-
-**측정 완료 5개 축(#16~#20) 순위 원칙 완전 부합 — 카드 풀빌드(#5)는 Day 8~10 확정 후 최종 #21 원칙 확정**.
-
-**특이 사항 / 이슈**: 각성(#16)·진화(#17)는 UTF Assertion 범위만 검증되고 원시 DPS ratio 단일 값이 E-1에서 수집되지 않았으나, 범위 중앙값 1.50·1.40이 세트(1.7146)·일반 장비(1.3046) 사이에 정확히 위치하여 **순서 원칙 부합 확인에는 충분**. 정밀 DPS ratio는 Day 15+ 최종 튜닝 시 E-1 확장 수집 가능.
-
-**기각안**:
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | 각성·진화 원시 DPS ratio 미수집이므로 #21 확정 유보 | UTF Assertion 범위 중앙값이 세트·일반 장비 사이에 위치하는 것만으로 순서 부합 논리적 확정 가능. 원시 값 수집은 정밀도 향상 목적이지 순위 판정 전환 요인 아님 |
-| 2 | 카드 풀빌드 미확정이므로 #21 전체 유보 | 측정 완료된 5개 축 순서 원칙 부합 확인은 독립적 가치. 카드 풀빌드 위치만 Day 8~10 재확정 — 5개 축 부분 확정 + 1개 축 유보 분리 가능 |
-
----
-
-## 3. Day 8~10 이슈 이관 재검토
-
-본 Day 4~7 재검증에서 **신규 이관 후보 발견 없음**. 기존 이관 확정 2건 유지:
-
-| # | 항목 | 이관 사유 | 재개 조건 |
-|---|------|---------|---------|
-| #5 | G1 풀빌드 +399% DPS 실전치 | 카드 메커닉 시뮬 미구현 (리포트 v2 §6-3) | Day 8~10 이슈 1 통합 재논의 |
-| #6 | 풀빌드 EHP +42% | Shield 시뮬 미구현 (방어·쉴드 시뮬 현황 메모 §3·§4 참조) | Day 8~10 이슈 1·3 통합 재논의 + 방어·쉴드 구현 |
-
-**본 재검증 6건(#16~#21) 기준 신규 이관 없음**. 모든 항목 기획 가정 범위 내 Passed로 Phase 3 v2 최종본 반영 준비 완료.
-
----
-
-## 4. Day 11~14 맵 패턴 재검증 착수 조건
-
-### 4-1. 선행 조건 충족 확인
-
-| # | 조건 | 상태 |
-|---|------|------|
-| 1 | Day 4~7 6건 재검증 완료 | **완료** (본 보고서) |
-| 2 | 성장 요소 기여도 모두 기획 가정 범위 내 Passed | **완료** (6/6 적정·원칙 부합) |
-| 3 | 성장 요소 순서 원칙 부합 확인 (#21) | **완료** (5개 축 부분 확정 + 카드 풀빌드 Day 8~10 재확정) |
-| 4 | 신규 이슈 이관 후보 없음 | **완료** (신규 없음, 기존 #5·#6 유지) |
-
-### 4-2. Day 11~14 착수 가능 여부
-
-**착수 가능** — Day 4~7 결과 전부 Passed이며 맵 패턴 재검증(#11~#15, #22~#25)과 독립 트랙. 단 Day 8~10 이슈 1·3 재논의(카드 풀빌드·신성 G4/G5 확장성)가 맵 패턴 배치에 영향을 줄 가능성이 있으므로 Day 11~14 착수 시 다음 2안 중 선택:
-
-- **2-A안 (병행)**: Day 8~10과 Day 11~14 병행 진행 — 빠른 진행, 이슈 결과 반영 시 일부 재조정 가능성
-- **2-B안 (순차)**: Day 8~10 완료 후 Day 11~14 착수 — 이슈 1·3 확정된 전제에서 맵 패턴 배치 진행, 재조정 최소화
-
-**기획팀장 권고**: **2-B안 (순차)**. 맵 패턴 배치는 C9(보스 집중) 조건 등과 결합되어 이슈 1·3의 카드 빌드 강약 재분배 결과에 영향을 받으므로, Day 8~10 확정 후 착수하는 것이 재작업 최소화에 유리. 단 이 판단은 PM·PD님 최종 결정 사안.
-
----
-
-## 5. 관련 규칙·문서
-
-- **C5** 정보의 정직성 — 실측 원문(`[E-1 RAW]` 로그) 인용 의무
-- **C23** 허위 보고·역할 연기 절대 금지 — tool_use 결과로 입증 불가한 수치 단정 금지
-- **P16** 산출물 추적성 — 변경 이력 기록 의무
-- **P28** 보고 표준 포맷 — §0 요약표
-- **P30** 재미 우선 원칙 — 성장 요소 순서 원칙이 "카드 중심 재미 축 + 장비 빌드 분기 + 말기 인장 차별화"의 의도된 설계 방향과 부합 확인
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` — UTF 14/14 원시 수치 SOT
-- `공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md` — #6 EHP·방어·쉴드 고정 참조점 (본 보고서 재서술 없음)
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md §2-4` — 재검증 28개 항목 SOT
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md §2 Day 4~7` — 로드맵
-- `프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md` — 단일 항목 재검증 로그 포맷
-
----
-
-## 6. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-20 | 기획팀장 | 초판 — Phase 3 Day 4~7 성장 요소 기여도 재검증 6건 (#16~#21) 통합 리포트. UTF 14/14 · E-1 원시 수치 기반 |
-
----
-
-## 7. PM 에스컬레이션 — 이슈·질의
-
-### 7-1. 기획팀장 판단 완결 사항 (PD님 결정 불요)
-
-1. Day 4~7 6건 전체 **적정·원칙 부합** 판정 — 기획팀장 재량 범위(P23 "기존 확정 방향 내 세부 수치 판정")
-2. 신규 이슈 이관 없음 — 기존 #5·#6 이관 유지
-3. 각성·진화 원시 DPS ratio 정밀 측정 미수행 사유 명기 (UTF Assertion 범위만 검증) — 범위 중앙값 순서 부합으로 판정 충분, 정밀 측정은 Day 15+ 선택 사항
-
-### 7-2. PM 확인·PD님 결정 필요 안건
-
-1. **Day 11~14 착수 순서 (2-A 병행 vs 2-B 순차)** — 기획팀장 권고 2-B(순차), 최종 결정 PM·PD님. 타 부서 영향(개발팀 Day 8~10 이슈 1 카드 메커닉 구현 일정) 결합되어 PM 조율 필요
-2. 본 보고서의 Phase 3 v2 최종본 반영 시점 — Day 8~10 완료 후 일괄 반영 vs Day 4~7 분 선행 반영 (Day 15+ 최종 튜닝 단계 설계 영향)
-
-### 7-3. 개발팀 협업 요청 없음
-
-Day 4~7 재검증 범위에서 개발팀 추가 작업 요청 없음. 기존 Day 8~10 이관 2건(#5·#6)은 개발팀 카드 메커닉·Shield 시뮬 구현 트랙으로 별도 진행 중.
-
----
-
-*작성 완료: 2026-04-20*
-*상태: Day 4~7 본 작업 완료 — Day 8~10 이슈 1·3 재논의 착수 가능, Day 11~14 맵 패턴 재검증 착수 조건 충족*
diff --git a/공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md b/공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md
deleted file mode 100644
index 0b0350f..0000000
--- a/공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-요청번호: REQ-XXX (일련번호 부여)
-요청일: YYYY-MM-DD
-요청부서: 기획팀
-수신부서: 개발팀
-담당에이전트: (예: /게임플레이, /클라이언트)
-우선순위: HIGH | MID | LOW
-상태: 대기 | 진행중 | 응답완료 | 보류
-유형: 밸런스수치_요구서
-관련PD지시: #N (해당 시)
----
-
-# 밸런스 수치 요구서 표준 템플릿
-
-> **용도**: 기획팀이 개발팀에 밸런스 수치 변경·신규 테이블 반영을 요청할 때 사용하는 표준 포맷.
-> **원칙**: C7(재미 근거 필수) · C11(개발 관점 존중) · C6(백업 의무) · P16(변경 이력) · P24(기각안 기록).
-> **사용법**: 본 파일을 복사하여 `YYYY-MM-DD_REQ-XXX_요약제목.md`로 저장 후 채워 넣는다.
-
----
-
-## 1. 요구서 식별
-
-| 필드 | 값 |
-|------|-----|
-| **요구서 ID** | REQ-XXX |
-| **기준 버전** | (예: PCAwakening.json `v1.3.2`, 수상한잡화점_밸런싱전략_v1.md) |
-| **기준 커밋** | (git SHA 또는 "main@YYYY-MM-DD HH:MM") |
-| **작성자** | (기획팀장 / balance-designer 등) |
-
----
-
-## 2. 변경 필드 목록
-
-대상 파일·테이블과 변경 대상 필드를 명시.
-
-| # | 파일·테이블 | 필드 경로 | 변경 유형 |
-|---|------------|---------|---------|
-| 1 | (예: `table_PCAwakening.json` > PC6001) | `s_Value` | 수정 |
-| 2 | (예: `카드시너지_v2.xlsm` > Sheet1!B5:B20) | `effect_coefficient` | 신규 |
-
-**변경 유형**: `수정` / `신규` / `삭제` / `구조변경`
-
----
-
-## 3. 변경 전후 수치
-
-실제 수치를 전후 대비로 명시. 다건이면 표로, 단건이면 단락으로.
-
-| # | 대상 | 현재값 | 제안값 | 비고 |
-|---|------|--------|--------|------|
-| 1 | PC6001 MaxHP Node 100394 `s_Value` | `'500%'` | `'50%'` | 데이터 입력 오류 정정 |
-| 2 | 스테이지 5 몬스터 HP | 1200 | 1400 | 난이도 곡선 조정 |
-
-성장 곡선·구간 변경 시 구간별 전후 값 전수 명시.
-
----
-
-## 4. 재미 근거 (C7 필수)
-
-> **"어떤 재미를 강화하는가"를 먼저 정의**해야 수치 변경이 허용된다 (C7). 재미 정의 없는 수치 조정은 금지.
-
-- **강화하려는 재미 축**: (예: "보스전 긴장감", "빌드 다양성", "만렙 성취감")
-- **변경 전 재미 문제점**: (예: "현재 만렙 DPS +1067%로 보스가 3초 내 클리어되어 긴장감 소실")
-- **변경 후 기대 경험**: (예: "만렙 DPS +50% 수준으로 보스 TTK 10~15초 구간 유지, 긴장감 보존")
-- **측정 지표**: (예: "Unity MCP 시뮬 100회 평균 TTK", "만렙 클리어율 70~85% 구간")
-
----
-
-## 5. 개발 관점 우려 예상 (C11 존중)
-
-> 기획팀이 개발팀 관점(C11 — 자원 효율성·코드 직관성·범용성)에서 예상되는 우려를 **사전 명시**하여 논의 효율을 높인다. 개발팀이 추가 우려를 발견 시 C3(은폐 금지)에 따라 즉시 제기.
-
-| 관점 | 예상 우려 | 기획팀 입장 |
-|------|----------|-------------|
-| **자원 효율성** | (예: 매 프레임 재계산으로 CPU 부담) | (예: 변경 빈도 낮음 — 초기화 시 1회 계산 가능) |
-| **코드 직관성** | (예: `500%` vs `5.0` 혼재로 파싱 복잡) | (예: 신규 `s_Value_type` 컬럼 도입 제안) |
-| **범용성** | (예: 차기 프로젝트 재활용 어려움) | (예: 프로젝트 특수 로직으로 한정, 범용 모듈 분리) |
-
-우려 없을 시 "없음 (기획팀 분석 범위 내 우려 없음)" 명시.
-
----
-
-## 6. 검증 방법
-
-변경이 의도대로 동작하는지 확인할 수 있는 검증 시나리오.
-
-- **검증 채널**: Unity MCP 시뮬 / 로컬 빌드 / QA 수동 / 수치 단위 테스트
-- **검증 케이스**:
-  1. (예: "만렙 PC 5종에 각성 트리 풀 해방 상태로 Stage 10 보스 진입 → 10회 반복 → TTK 평균 10~15초 확인")
-  2. (예: "중간 단계 3레벨 상태 전투 시뮬 → DPS 증가율 +20~30% 구간 확인")
-- **통과 기준**: (검증 케이스별 수치 기준 명시)
-- **회귀 검증**: 변경 대상 외 기존 밸런스 경로(P14 QA 게이트) 영향 없음 확인
-
----
-
-## 7. 백업·이력 (C6·P16)
-
-- **백업 파일**: `{원본명}.bak_YYYYMMDD_HHMM.{확장자}` — 개발팀이 변경 착수 전 생성
-- **변경 이력 기록 위치**: 대상 md 문서 하단 "변경 이력 테이블"에 append
-- **관련 대화로그**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md` 엔트리 링크
-
----
-
-## 8. 기각안 (P24 — 결정성 요청이면 권장)
-
-검토했으나 채택하지 않은 대안과 기각 사유. 조직 자산 축적의 핵심 (헌법 제1원칙 목표 2 원칙 B).
-
-| # | 기각 대안 | 기각 사유 |
-|---|----------|----------|
-| 1 | (예: 현재값 유지 + 별도 난이도 옵션 도입) | (예: 신규 시스템 비용 대비 재미 개선 불확실) |
-| 2 | (예: `500%` 일괄 → `100%`) | (예: 과도한 하향으로 각성 성취감 소실 우려) |
-
-기각 대안 미검토 시 "없음 (단일안 — 사유: ...)" 명시. 공란 금지.
-
----
-
-## 9. 응답 섹션 (개발팀 작성)
-
-> 개발팀이 본 요구서에 응답할 때 아래 섹션을 append. 별도 응답 파일 분리 불필요 (본 파일 단일 SOT).
-
-### 9-1. 개발 관점 검토 결과
-- 수용 가능 여부: 수용 / 조건부 수용 / 반려
-- 추가 우려: (기획팀 예상 외 발견 시)
-- 대안 제시: (반려·조건부 시)
-
-### 9-2. 변경 적용 결과
-- 적용 커밋: (SHA)
-- 백업 경로: (`.bak_YYYYMMDD_HHMM.{확장자}`)
-- QA 검증 결과: (통과/실패 + 상세)
-- 회귀 검증: (통과/실패)
-
-### 9-3. 후속 필요 작업
-- (예: 밸런스 조정 후 balance-designer 재튜닝 필요)
-- (예: Unity MCP 시뮬 재실행 필요 — 경계값 재산출)
-
----
-
-## 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-17 | 기획팀장 | 표준 템플릿 신설 (PD님 직접 지시, 팀장 재량 진행 승인) |
diff --git a/공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md b/공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md
deleted file mode 100644
index 1af8f82..0000000
--- a/공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-요청번호: REQ-초안 (발행 시 REQ-XXX 부여)
-요청일: 2026-04-20 (초안 작성일 — 정식 발행은 개발팀 조건 2·3 완결 후 조율)
-요청부서: 기획팀
-수신부서: 개발팀 (클라이언트팀)
-담당에이전트: 시스템기획자·밸런스기획자 (기획) / 클라이언트팀장 (개발)
-우선순위: MID (Phase 3 재개 Day 1-4 후속 — Day 2~3 병행 가능)
-상태: 초안 (미발행)
-유형: 밸런스수치_요구서 (조건 판정 로직 구현 요청)
-관련PD지시: 기획팀 #3 (Phase 3 재개 Day 1-4)
----
-
-# REQ 초안 — ★ 조건 12개 판정 로직 Unity MCP EditMode 구현 요청
-
-> **본 문서는 초안**. 정식 발행은 개발팀 재개 선행 조건 2(실측 검증 리포트)·3(실행 가이드) 완결 후 기획팀장·개발팀장 조율하여 `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md` 로 확정 발행.
-
----
-
-## 1. 요구서 식별
-
-| 필드 | 값 |
-|------|-----|
-| **요구서 ID** | REQ-초안 (정식 발행 시 부여) |
-| **기준 버전** | `3성조건_12개_상세명세_v1.md` (2026-04-18 최신화) |
-| **기준 커밋** | main (정식 발행 시점 SHA 기록) |
-| **작성자** | 기획팀장 (Phase 3 재개 Day 1 사전 준비) |
-
----
-
-## 2. 변경 필드 목록
-
-개발팀 `Assets/Sim/BurningTimes.Sim.asmdef` 어셈블리 내 **신규 구현** 요청.
-
-| # | 파일·테이블 | 필드 경로 | 변경 유형 |
-|---|------------|---------|---------|
-| 1 | `Assets/Sim/Conditions/` (신규) | ConditionEvaluator 인터페이스 + 12개 구체 구현 | 신규 |
-| 2 | `Assets/Sim/Conditions/ConditionMetricsTracker.cs` (신규) | 런타임 측정 변수 집계기 | 신규 |
-| 3 | `시뮬레이터/03_결과_JSON_포맷_v1.md` 결과 스키마 | `conditions_result` 필드 추가 (조건별 달성 여부) | 확장 |
-
----
-
-## 3. 구현 요청 범위
-
-### 3-1. 조건 12개 판정 로직 (`3성조건_12개_상세명세_v1.md §3·§4` 준수)
-
-| ID | 명칭 | 측정 변수 | 판정식 |
-|----|------|---------|-------|
-| C1 | 신속 | 스테이지 총 소요 시간 | `total_duration_sec ≤ threshold[stage_id]` |
-| C2 | 완벽 클리어 | PC HP (클리어 시점) | `pc_hp_at_clear == pc_max_hp` |
-| C3 | 고 HP 완주 | PC HP (클리어 시점) | `pc_hp_at_clear ≥ pc_max_hp × 0.70` |
-| C6 | 포션 절제 | 포션 사용 횟수 | `potion_uses ≤ threshold[stage_id]` |
-| C9 | 보스 집중 | 보스에게 가한 누적 데미지 / 전체 누적 데미지 | `boss_dmg_ratio ≥ threshold` |
-| C12 | (명세서 §3 참조) | (명세서) | (명세서) |
-| N1 | (명세서 §4 참조) | 서브맵 단위 측정 | (명세서) |
-| N2 | 피격 제한 | 누적 피격 횟수 | `hits_taken ≤ sub_map_count × 1` |
-| N3 | 치명타 처치 | 치명타로 처치한 몬스터 수 | `crit_kills ≥ 3` |
-| N4 | 쉴드 하한 | 클리어 시점 Shield | `shield_at_clear ≥ pc_max_shield × 0.30` |
-| N5 | 후열 선공 | 타겟팅 우선순위 검증 | `first_kill_target == rear_row` |
-| N6 | 전열 선공 | 타겟팅 우선순위 검증 | `first_kill_target == front_row` |
-
-**정확한 판정식·엣지 케이스는 `3성조건_12개_상세명세_v1.md §3·§4` 본문을 정(正)**으로 한다. 본 REQ는 구현 범위 합의용 요약.
-
-### 3-2. 런타임 측정 변수 Tracker
-
-스테이지 진행 중 매 턴/이벤트에 측정 변수 누적. 스테이지 종료 시 ConditionEvaluator가 해당 스테이지의 슬롯2·슬롯3 조건 2개만 평가 (Prove-2-of-3).
-
-### 3-3. 결과 JSON 스키마 확장
-
-`03_결과_JSON_포맷_v1.md` 의 `result` 오브젝트에 `conditions_result` 필드 추가:
-
-```json
-"conditions_result": {
-  "slot2_id": "C1",
-  "slot2_passed": true,
-  "slot2_metric": {"total_duration_sec": 22.4, "threshold": 25.0},
-  "slot3_id": "N2",
-  "slot3_passed": false,
-  "slot3_metric": {"hits_taken": 5, "limit": 4}
-}
-```
-
----
-
-## 4. 재미 근거 (P30 재미 우선 원칙)
-
-- **강화하려는 재미 축**: "재도전 유도 유기성" (Phase 2 §5 PD님 3차 승인 조건 설계 원칙 2)
-- **변경 전 재미 문제점**: Prove-2-of-3 체계는 설계 완료되었으나 **판정 로직이 Unity MCP EditMode에 구현되지 않아 시뮬 단위 검증 불가**. Phase 3 성장 요소 기여도 측정과 별개로, 3성 조건 달성률을 스테이지·빌드별로 측정할 수단 부재
-- **변경 후 기대 경험**: 유저가 각 스테이지 슬롯2·슬롯3 조건을 인지하고 의도적으로 재도전할 때의 **달성률 분포를 시뮬에서 실측**. 입문 구간 슬롯 배치의 "재도전 유도 강도" 정량 검증
-- **측정 지표**: 스테이지별 ★3 달성률, 슬롯별 조건 달성률, 슬롯2·슬롯3 동시 달성률
-
----
-
-## 5. 개발 관점 우려 예상 (C11 존중)
-
-| 관점 | 예상 우려 | 기획팀 입장 |
-|------|----------|-------------|
-| **자원 효율성** | 매 턴 측정 변수 갱신 오버헤드 | 누적 변수만 갱신·프레임 단위 재계산 불요. 클리어 시점 1회 평가 |
-| **코드 직관성** | 조건 12종 분기 복잡도 | 인터페이스 `IConditionEvaluator` + 클래스 12개로 분리. 각 클래스 단일 책임 |
-| **범용성** | 차기 프로젝트 재활용 | `Assets/Sim/Conditions/` 구조는 수상한잡화점 특수. 범용화는 `BT.Framework` Tier 2 검토 (P29-3 인사이트 축적) |
-
----
-
-## 6. 검증 방법
-
-- **검증 채널**: Unity MCP EditMode 단위 테스트 (`3성조건_12개_상세명세_v1.md §6-1` 테스트 매트릭스 준수)
-- **검증 케이스**:
-  1. 조건별 경계값 테스트 (예: C3 HP=MaxHP×0.70 정확히 경계 → pass, 0.69999 → fail)
-  2. 슬롯2·슬롯3 동시 달성 시나리오 → ★3 반환
-  3. 슬롯2만 달성 → ★2, 슬롯 둘 다 실패 → ★1
-  4. P17 배타 조합 7종 케이스를 매니페스트에 등록 → 판정 로직에 도달하지 않음 (상위 필터)
-- **통과 기준**: `3성조건_12개_상세명세_v1.md §6-1` 단위 테스트 매트릭스 전수 통과
-- **회귀 검증**: 기존 전투 시뮬 결과 (Phase 0~2 앵커)에 conditions_result 추가되어도 기존 result 필드 값 불변
-
----
-
-## 7. 백업·이력 (C6·P16)
-
-- **백업**: 신규 구현이므로 백업 대상 없음
-- **변경 이력**: `3성조건_12개_상세명세_v1.md §8` 변경 이력 테이블에 REQ-XXX 발행 일시 append
-- **관련 대화로그**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md`
-
----
-
-## 8. 기각안 (P24 · C32 계승)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 조건 판정을 Unity 실 빌드 PlayMode에만 구현 | 결정론적 시뮬 불가 → Phase 3 재검증 시 ±10% 오차 판정 불가능 |
-| 2 | 조건 판정을 Python 시뮬에 구현 | PD님 지시로 단일축 SOT = Unity MCP EditMode. 이원화 금지 |
-| 3 | 조건 12종을 하나의 거대 함수로 구현 | C11 개발 관점 (코드 직관성·범용성) 위배. 확장 시 분기 폭발 |
-
----
-
-## 9. 응답 섹션 (개발팀 작성)
-
-### 9-1. 개발 관점 검토 결과
-(정식 발행 후 개발팀이 기재)
-
-### 9-2. 변경 적용 결과
-(구현 완료 시 개발팀이 기재)
-
-### 9-3. 후속 필요 작업
-(해당 시 개발팀이 기재)
-
----
-
-## 10. 발행 선행 조건
-
-본 초안은 다음 2종 완결 후 정식 REQ로 전환:
-1. 개발팀 재개 선행 조건 2 (Unity MCP EditMode 실측 검증 리포트 완료)
-2. 개발팀 재개 선행 조건 3 (기획팀용 Unity MCP 시뮬 실행 가이드 완료)
-
-완결 시점에 기획팀장이 기획팀→개발팀 채널로 `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md` 로 정식 발행.
-
----
-
-## 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-20 | 기획팀장 | 초안 작성 (Phase 3 재개 Day 1 사전 준비, 발행 대기) |
diff --git a/공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md b/공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md
deleted file mode 100644
index 3a20932..0000000
--- a/공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md
+++ /dev/null
@@ -1,309 +0,0 @@
-# 수상한 잡화점 — 재검증보고 Phase 0~2 결과 v1
-
-> 작성일: 2026-04-20 / 담당: 기획팀장 (Phase 3 재개 Day 2~3 집행)
-> 검증 범위: `밸런싱문서_일관성점검_v1.md §2-1` 재검증 #1~#6 통합 (Phase 0~2 기획 가정 전수 대조)
-> 검증 근거: 개발팀 Unity UTF Tests 10/10 Passed (0.835s) · DeckBuilding 레포 commit `fc33fc9d6` (origin/Dev 반영)
-> 검증 축: Unity UTF EditMode 실측 = 정본(正). UTF 시나리오 5종 JSON(`Assets/Sim/Scenarios/`) 기반
-> 템플릿: `프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md` 16필드 로그
-
----
-
-## ⚠️ 검증 근거 투명성 고지 (C5·C23 정직성)
-
-본 재검증 보고는 **개발팀이 PM 경유로 전달한 UTF Tests 10/10 Passed 결과**(테스트 이름·범위·Passed 판정)를 **실측 근거**로 사용한다. 개발팀 정식 `2026-04-20_Unity_MCP_실측검증_리포트_v1.md`는 **본 시점 스켈레톤 상태**(`Status: 스켈레톤 (본문 미채움)`)이며, 정식 수치 본문은 개발팀 병렬 작업 완료 후 append 예정. 본 보고는 정식 리포트 확정 후 **수치 대조 재검증** 1회 추가 수행 권고.
-
-**UTF Tests는 "시나리오 범위 내 DPS/TTK/ratio"를 Passed 판정**하지만 원시 수치(DPS 평균·σ·시드별 개별값)는 본 시점 PM 프롬프트에 제공되지 않음. 따라서:
-- **판정**은 UTF "Passed" 결과를 근거로 **범위 준수 확인**까지 가능
-- **정확한 오차 % 산출**은 정식 리포트 수치 확정 후 append
-
----
-
-## 0. 요약 (항목별 판정 분포)
-
-| 판정 | 건수 | 항목 |
-|------|-----|------|
-| 적정 | 4 | #1 · #2 · #3 · #4 |
-| 과도 | 0 | — |
-| 부족 | 0 | — |
-| 괴리 | 0 | — |
-| 시뮬 스코프 외 | 2 | #5 · #6 (Day 8~10 이슈 1·3 통합 재논의 이관 후보) |
-
-**종합 판정**: Phase 0~2 앵커·카드 시너지 기초 4건(#1~#4) **Unity UTF 실측 범위 내 Passed 확인** → Phase 3 본작업(Day 4~7) 착수 가능. 풀빌드 19장·EHP 2건(#5·#6)은 시뮬 스코프 외 판정 → **Day 8~10 이슈 1·3 통합 재논의로 이관** (사전 자료 모음 §3 연동 처리).
-
----
-
-## 1. 전체 집행 컨텍스트
-
-| 항목 | 값 |
-|------|-----|
-| Unity UTF 실행 환경 | 개발팀 로컬 Unity Editor + UTF EditMode |
-| DeckBuilding 레포 commit | `fc33fc9d6` (origin/Dev 반영 완료) |
-| 시나리오 5종 JSON 경로 | `Assets/Sim/Scenarios/{anchor_pc6001,card_g1_1,card_g1_5,growth_awakening_max,growth_evolution_6star}.json` |
-| UTF 실행 결과 | 10/10 Passed (0.835s) |
-| 실행 기간 | 2026-04-20 |
-| 결정론 검증 | `DeterminismTests` 2종 Passed (5회 반복 핵심 수치 완전 일치 · AllScenarios 컴파일) |
-| 검증 일시 | 2026-04-20 |
-| 기록 일시 | 2026-04-20 |
-| 기록자 | 기획팀장 |
-
----
-
-## 2. 항목별 재검증 로그
-
-### 재검증 #1 — PC 6001 DPS 1.05
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #1 |
-| **항목명** | PC 6001 DPS 1.05 이론치 (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | PC 6001 DPS 1.05 @ Phase 0_1 §1 |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 1.05 ±10% (0.945~1.155) 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | Unity UTF EditMode (단일축) |
-| **Unity UTF 시나리오 ID** | `anchor_pc6001` |
-| **UTF 테스트 이름** | `AnchorPc6001Tests.Anchor_PcDps_WithinExpectedRange` |
-| **결과 근거** | UTF Tests 10/10 Passed (0.835s) — 본 테스트 `Passed` 판정 = DPS 실측값이 0.945~1.155 범위 내 |
-| **실측값** | 범위 내 Passed (원시 수치는 정식 리포트 append 예정) |
-| **오차 (실측 − 기획 가정)** | ±10% 범위 내 (Passed 판정) — 정확한 % 값은 원시 수치 확정 후 산출 |
-| **판정** | **적정** (±10% 이내 Passed 확인) |
-| **판정 근거** | UTF `Anchor_PcDps_WithinExpectedRange` Passed → 검증 목표 범위 준수 증명. 기획 가정 DPS 1.05가 Unity 실측 앵커로 타당성 확인 |
-| **후속 조치** | 조치 없음. Day 4~7 성장 요소 기여도 측정 시 본 앵커 값 그대로 활용 가능 |
-| **실행 일시** | 2026-04-20 (개발팀 UTF 실행 시점) |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 없음. UTF Passed 결과로 앵커 DPS 1.05 타당성 확인. 단 원시 수치(평균·σ) 미수령 — 정식 리포트 확정 후 정확한 오차 % append 권고.
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "UTF Passed만으로는 정확 오차 산출 불가 → 판정 보류" | ±10% 범위 Passed 자체가 "적정" 판정 기준 충족. 원시 수치 미확정이라도 범위 확인은 완결 |
-| 2 | "Passed 기준 범위가 너무 넓어 앵커 신뢰도 불충분" | 검증 목표를 ±10%로 기획팀이 사전 설정 (템플릿 §1) — 범위 재협상 없는 한 Passed = 적정 |
-
----
-
-### 재검증 #2 — Stage 1 일반 몬스터 TTK 5.7s
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #2 |
-| **항목명** | Stage 1 일반 몬스터 TTK 5.7s 이론치 (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | Stage 1 일반 몬스터 TTK 5.7s @ Phase 0_1 §2 |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 5.7s ±10% (5.0~6.5s) 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | Unity UTF EditMode |
-| **Unity UTF 시나리오 ID** | `anchor_pc6001` |
-| **UTF 테스트 이름** | `AnchorPc6001Tests.Anchor_TTK_WithinExpectedRange` |
-| **결과 근거** | UTF Tests Passed — TTK 실측값이 5.0~6.5s 범위 내 |
-| **실측값** | 범위 내 Passed (원시 수치는 정식 리포트 append 예정) |
-| **오차 (실측 − 기획 가정)** | ±10% 범위 내 (Passed 판정) |
-| **판정** | **적정** |
-| **판정 근거** | UTF `Anchor_TTK_WithinExpectedRange` Passed → TTK 5.7s 기획 가정이 Unity 실측 앵커로 타당 |
-| **후속 조치** | 조치 없음. Day 11~14 스테이지 난이도 곡선 재검증(#11~#15) 시 본 TTK 앵커 그대로 활용 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 없음. PC DPS 1.05(#1)과 일반 몬스터 TTK 5.7s(#2)의 상호 정합성은 `AnchorPc6001Tests.Anchor_PcSurvives` + `Anchor_MonsterKilled` Passed로도 간접 확인됨 (PC 생존 + 몬스터 처치 모두 Passed = DPS/TTK 조합 유효).
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "TTK 5.7s는 평균치 — 시드별 편차 확인 필요" | `DeterminismTests` 5회 반복 핵심 수치 완전 일치 Passed → 시드 편차 이슈 구조적 차단 |
-
----
-
-### 재검증 #3 — G1 카드 1장 평균 기여 +22% DPS
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #3 |
-| **항목명** | G1 카드 1장 평균 기여도 +22% DPS (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | G1 카드 1장 +22% DPS @ Phase 0_2 §2-1 (Python 시뮬 이론치) |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 +22% ±10%p (ratio 1.02~1.42, 중앙 1.22) 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | Unity UTF EditMode |
-| **Unity UTF 시나리오 ID** | `card_g1_1` |
-| **UTF 테스트 이름** | `CardSynergyG1Tests.G1_1Card_DpsHigherThanAnchor` |
-| **결과 근거** | UTF Tests Passed — DPS ratio (G1 1장 / 앵커) 1.02~1.42 범위 내 |
-| **실측값** | 범위 내 Passed (ratio 1.02~1.42 — 중앙 1.22 = +22% 일치) |
-| **오차 (실측 − 기획 가정)** | ±10%p 범위 내 (Passed 판정) |
-| **판정** | **적정** |
-| **판정 근거** | UTF `G1_1Card_DpsHigherThanAnchor` Passed + ratio 범위가 +22% 중앙으로 설계됨 → 기획 가정 +22% 타당 |
-| **후속 조치** | 조치 없음. Day 4~7 G1 카드 개별 기여도 추가 측정 시 본 앵커 +22% 기준선 활용 |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: 없음. Python 시뮬 이론치와 Unity UTF 실측 범위 중앙이 완전 일치(+22%)로 Phase 0_2 이론치 신뢰도 실증.
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "+22% 중앙값 일치는 우연일 수 있음" | `DeterminismTests` 5회 반복 완전 일치 Passed로 우연 요인 구조 차단 |
-| 2 | "카드 1장 평균치 → 카드별 편차 확인 필요" | 본 재검증은 '평균 +22%' 가정 검증. 카드별 편차는 Day 4~7 #16~#21 후속 측정 범위 |
-
----
-
-### 재검증 #4 — G1 5장 TTK -45%
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #4 |
-| **항목명** | G1 카드 5장 TTK -45% (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | G1 5장 TTK -45% @ Phase 0_2 §2-2 (Python 시뮬 이론치) |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 -45% (TTK ratio <0.70) 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | Unity UTF EditMode |
-| **Unity UTF 시나리오 ID** | `card_g1_5` |
-| **UTF 테스트 이름** | `CardSynergyG1Tests.G1_5Cards_TtkLowerThanAnchor` |
-| **결과 근거** | UTF Tests Passed — TTK ratio (G1 5장 / 앵커) <0.70 |
-| **실측값** | 범위 내 Passed (TTK ratio <0.70 = TTK 감소 ≥30%, -45% 포함 범위) |
-| **오차 (실측 − 기획 가정)** | TTK 감소율 ≥30% 확인 (기획 -45%는 해당 범위 포함) |
-| **판정** | **적정** (범위 포함 Passed) |
-| **판정 근거** | UTF `G1_5Cards_TtkLowerThanAnchor` Passed → G1 5장 조합 TTK 감소 유효. 기획 -45% 가정이 실측 범위 내 |
-| **후속 조치** | 조치 없음. 단 "TTK ratio <0.70" 범위는 -30%~-100%까지 광역 허용 — Day 4~7 또는 정식 리포트 append 시 **정확한 감소율 산출 권고** (괴리 여부 재확인용) |
-| **실행 일시** | 2026-04-20 |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: **UTF 검증 범위(<0.70)가 기획 가정(-45%)보다 광역** — UTF는 "감소 존재" 검증까지만 수행하고 정확한 감소율은 원시 수치에서만 확인 가능. Passed는 "범위 위반 없음" 증명이지 "-45% 일치" 증명 아님. 정확한 -45% 검증은 원시 수치 append 후 재판정 권고.
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "UTF 범위가 광역이라 -45% 기획 가정 증명 불충분 → 부족/괴리 후보" | Passed = "범위 내" 증명으로 기획 가정이 해당 범위에 포함됨을 확인. 정확한 값 불일치는 **원시 수치 미확정 한계**이지 괴리 근거 아님. 특이 사항에 권고 명시로 충분 |
-| 2 | "카드 5장 조합 = 풀빌드 경로 진입 → #5·#6과 묶어 시뮬 스코프 외 판정 후보" | 5장 이하는 카드 메커닉 독립 재구현 범위 내(`CardSynergyG1Tests` 존재). 풀빌드 19장(#5)과 구분됨 |
-
----
-
-### 재검증 #5 — G1 풀빌드(19장) DPS +399%
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #5 |
-| **항목명** | G1 풀빌드(19장) DPS +399% 실전치 (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | G1 풀빌드 19장 DPS +399% @ Phase 0_2 §3 (Python 이론치) |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 +399% ±20%p 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | — (Unity UTF 시나리오 부재) |
-| **Unity UTF 시나리오 ID** | 부재 — `card_g1_19` 또는 `fullbuild_*` 시나리오 미작성 |
-| **UTF 테스트 이름** | 부재 |
-| **결과 근거** | Unity UTF Tests 10/10 중 풀빌드 19장 시나리오 **미포함** (앵커·G1 1장·G1 5장·각성·진화 5종 한정) |
-| **실측값** | **미측정 — 시뮬 스코프 외** |
-| **오차 (실측 − 기획 가정)** | 산출 불가 |
-| **판정** | **시뮬 스코프 외** (Day 8~10 이슈 1·3 통합 재논의 이관 후보) |
-| **판정 근거** | `card_g1_5`는 카드 5장까지 메커닉 독립 재구현으로 `Assets/Sim/`에 존재하나, 풀빌드 19장은 **카드 전체 메커닉 독립 재구현**(19종 효과 상호작용·빌드 시너지 전개·전투 장기 진행)이 필요하며 현 UTF 시나리오 5종에 포함되지 않음. `일관성점검_v1 §1-6` "G1 풀빌드 목표·실측 괴리" 이슈와 **동일 맥락** → 이슈 1(카드 DPS 과도) 통합 재논의 대상 |
-| **후속 조치** | **Day 8~10 이슈 1·3 통합 재논의 이관** (재논의대기_사전자료모음_v1 §1·§3 연동). 이슈 1 논의 시 "풀빌드 +399% 이론치 재검증 방법" 별도 결정 필요. 옵션 2종:<br>(a) `Assets/Sim/` 카드 메커닉 확장 (19종 개별 모델링) — 개발팀 선행 작업 대규모<br>(b) Unity 실 빌드 PlayMode로 풀빌드 수동 실측 — 비결정론 수용 + 실전치 정본 |
-| **실행 일시** | — |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: **이슈 1(카드 DPS 과도, 재논의대기_사전자료모음_v1 §1) 직결**. G1 풀빌드 +399% 이론치 자체가 이슈 1의 근거였으므로 재검증 방법 결정 이전에 **이슈 1 재논의 선행 필수**.
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "UTF Tests 10/10 Passed이므로 풀빌드도 Passed로 간주" | UTF 10/10은 **시나리오 5종 한정** Passed. 풀빌드 19장 시나리오 미포함 → 확대 해석 C5 위반 |
-| 2 | "카드 메커닉 확장 (19종 모델링)을 기획팀장 재량으로 즉시 요청" | 개발팀 작업 범위·공수 대규모 + 이슈 1 방향 결정 선행 없이 확장하면 재작업 리스크 → Day 8 재논의 후 결정 |
-| 3 | "#5를 '부족' 또는 '괴리'로 판정" | 측정 자체가 불가 → 판정 근거 없음. '시뮬 스코프 외'가 정직한 판정 (C23 준수) |
-
----
-
-### 재검증 #6 — G1 풀빌드 EHP +42%
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | #6 |
-| **항목명** | G1 풀빌드 EHP +42% 이론치 (`일관성점검_v1 §2-1`) |
-| **기획 가정 (원본 수치)** | G1 풀빌드 EHP +42% @ Phase 0_2 §4 (Python 이론치) |
-| **검증 목표** | Unity UTF EditMode 실측이 기획 가정 +42% ±15%p 이내인지 확인 |
-| **담당 에이전트** | balance-designer |
-| **검증 축** | — (Unity UTF 시나리오 부재) |
-| **Unity UTF 시나리오 ID** | 부재 — EHP 전용 시나리오 미작성 |
-| **UTF 테스트 이름** | 부재 |
-| **결과 근거** | EHP(Effective HP) = HP × 방어 계수 기반 — `Assets/Sim/` 현 구현은 **방어 시스템(DefenceModel) + 쉴드(Shield)** 메커닉 **미완성 또는 시뮬 외**. `재논의대기_사전자료모음_v1 §4-1` N7 방어 성공 조건 개발팀 분석(#37 Q-P2)에서 "터치 방어 30%·쿨다운 없음·지속형" 확정됨 — 풀빌드 EHP 계산은 쉴드 빌드 + 방어 카드 복합 연산 필요 |
-| **실측값** | **미측정 — 시뮬 스코프 외** |
-| **오차 (실측 − 기획 가정)** | 산출 불가 |
-| **판정** | **시뮬 스코프 외** (Day 8~10 이슈 1·3 통합 재논의 이관 후보) |
-| **판정 근거** | EHP 측정에는 (a) 쉴드 메커닉 (b) 방어 카드 메커닉 (c) 풀빌드 19장 상호작용 세 축 모두 필요. 현 UTF 5종(앵커·카드 DPS·성장)은 **DPS 축 한정** — EHP 축 시나리오 부재. `일관성점검_v1 §1-6` 풀빌드 괴리와 동일 맥락 |
-| **후속 조치** | **Day 8~10 이슈 1·3 통합 재논의 이관**. 이슈 1 재논의 시 "EHP 검증 방법" 포함 결정. 옵션:<br>(a) `Assets/Sim/DefenceModel` + `ShieldModel` 확장 후 EHP 전용 시나리오 추가<br>(b) Unity 실 빌드 PlayMode 수동 실측<br>(c) EHP +42% 이론치 자체 재검토 (Phase 0_2 §4 가정 재확인) |
-| **실행 일시** | — |
-| **기록 일시** | 2026-04-20 |
-| **기록자** | 기획팀장 |
-
-**특이 사항 / 이슈**: **방어·쉴드 메커닉 시뮬 구현 상태 개발팀 확인 필요**. `Assets/Sim/Models/` 하위 DefenceModel·ShieldModel 존재 여부, 구현 깊이가 후속 조치 방향 결정의 선행 조건.
-
-**기각안**:
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | "EHP도 DPS 역산으로 추정 가능 → '적정' 판정" | EHP는 방어·쉴드·HP 축 복합 — DPS 시나리오 결과로 추정하면 추정의 사실화(C23 위반) |
-| 2 | "#6을 별도 트랙으로 분리 (N7 방어 조건과 묶음)" | N7 방어 조건(#37 Q-P2)은 별도 PD 지시로 분리 진행 중. #6 EHP는 **풀빌드 전체 검증** 영역이므로 이슈 1과 묶음 적절 |
-
----
-
-## 3. Day 8~10 이관 후보 (이슈 1·3 통합 재논의)
-
-| 이관 항목 | 이관 근거 | 이슈 연관 |
-|---------|---------|---------|
-| #5 G1 풀빌드 DPS +399% | UTF 시나리오 5종에 풀빌드 19장 미포함 — 카드 메커닉 독립 재구현 범위 한계 | **이슈 1** (카드 DPS 과도, `재논의대기_사전자료모음_v1 §1`) |
-| #6 G1 풀빌드 EHP +42% | EHP = HP × 방어 계수. 방어·쉴드 메커닉 시뮬 부재 — DPS 축 5종 시나리오만 존재 | **이슈 1** 또는 N7 방어 조건 별도 트랙 |
-
-**이관 시 재논의 안건 예시**:
-1. 풀빌드 검증 방법 (개발팀 시뮬 확장 vs Unity 실 빌드 PlayMode 수동 실측)
-2. +399% 이론치 자체 재검토 필요성 (Phase 0_2 §3 가정 재확인)
-3. EHP +42% 이론치 재검토 + N7 방어 조건(#37 Q-P2) 통합 여부
-
-**이관 경로**: `이슈1_3_통합재논의_v1.md` 작성 시 본 보고 §2 #5·#6 block 인용 + 재논의 안건 3종 첨부.
-
----
-
-## 4. Day 4~7 성장 요소 기여도 재검증 착수 조건 판정
-
-### 선행 조건 검증
-
-| 조건 | 상태 | 근거 |
-|------|------|------|
-| 앵커 DPS (#1) 타당성 확인 | ✓ 충족 | `AnchorPc6001Tests.Anchor_PcDps_WithinExpectedRange` Passed |
-| 앵커 TTK (#2) 타당성 확인 | ✓ 충족 | `AnchorPc6001Tests.Anchor_TTK_WithinExpectedRange` Passed |
-| 카드 시너지 기초(1장·5장) 타당성 확인 | ✓ 충족 | `CardSynergyG1Tests` 2종 Passed |
-| 결정론·리플레이 보장 | ✓ 충족 | `DeterminismTests` 2종 Passed (5회 반복 완전 일치) |
-| Day 4~7 대상 성장 요소 시나리오 존재 | ✓ 충족 | `Assets/Sim/Scenarios/{growth_awakening_max,growth_evolution_6star}.json` 존재 + `GrowthElementTests` 2종 Passed (각성 +50% ratio 1.30~1.70 / 진화 +40% ratio 1.20~1.60) |
-| 풀빌드 검증 방법 확정 (#5·#6) | ✗ 미충족 | Day 8 이슈 1·3 재논의 대기 |
-
-### 판정
-
-**Day 4~7 착수 가능**. 성장 요소 기여도 측정(#16 각성·#17 진화)은 Day 2~3 완료분(#1·#2·#3·#4) 앵커 타당성 확인 + 성장 시나리오 2종(각성·진화) Passed 근거로 **즉시 착수 가능**.
-
-**단 한정 조건**: 
-- #18 장비 일반 셋 · #19 장비 세트 완성 · #20 인장 5★ 시나리오는 **UTF 10/10에 미포함** (각성·진화 2종만 존재) → 해당 3건은 추가 시나리오 확정 선행 필요. 개발팀에 `Assets/Sim/Scenarios/` 확장 요청 REQ 발행 고려 (PM 확인 안건).
-- #21 성장 요소 기여 순서 원칙 검증은 #16~#20 전체 측정 후 수행 (순서: 카드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장)
-
----
-
-## 5. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-20 | 기획팀장 | 초판 v1 — Day 2~3 재검증 6건 판정 완료 (#1~#4 적정 · #5·#6 시뮬 스코프 외) |
-
----
-
-## 6. 참조 문서
-
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md §2-1` — 재검증 #1~#6 SOT
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md §2 Day 2~3` — 본 집행 로드맵
-- `프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md` — 16필드 로그 포맷
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md §1·§3` — 이슈 1 · 이슈 1·3 연동
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md` — 정식 리포트 스켈레톤 (본문 수치 미채움, 병렬 작업 중)
-- DeckBuilding 레포 commit `fc33fc9d6` — UTF Tests 10/10 Passed (0.835s) 근거
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` C5·C23·P16·P28·P30
-
----
-
-## 7. 후속 조치 체크리스트 (PM 경유)
-
-- [ ] 개발팀 정식 리포트 `2026-04-20_Unity_MCP_실측검증_리포트_v1.md` 수치 append 완료 후 본 보고 §2 #1~#4 **원시 수치 기반 오차 % 재산출** 1회 추가 append
-- [ ] Day 4~7 착수 지시 (#16 각성 · #17 진화 2종 우선 측정 가능)
-- [ ] `Assets/Sim/Scenarios/` 장비·인장 시나리오 확장 REQ 발행 여부 PM 확인 안건
-- [ ] Day 8~10 이슈 1·3 통합 재논의 준비 — #5·#6 이관 항목 포함
diff --git a/공유/소통/완료/.gitkeep b/공유/소통/완료/.gitkeep
deleted file mode 100644
index e69de29..0000000
diff --git a/공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md b/공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md
deleted file mode 100644
index 28a8a69..0000000
--- a/공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-요청번호: REQ001
-요청일: 2026-04-14
-요청부서: 기획팀
-수신부서: 개발팀
-담당에이전트: /게임플레이
-우선순위: HIGH
-상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ001_응답_각성트리_퍼센트값.md)
----
-
-> **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후)에 **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다. 해석 확정 결과를 회신해주시면 재개 시 즉시 반영하겠습니다.
-
-## 요청 내용
-
-`PCAwakening.json` 테이블에서 **같은 스탯의 노드인데 `s_Value` 형식이 비일관적**으로 혼재되어 있습니다. 실제 Unity에서 어떻게 해석되는지 확인 부탁드립니다.
-
-### 구체 예시: PC6001 MaxHP 노드 (12개 중 6개 샘플)
-
-| n_ID | s_Value | s_UpgradeStatValuePara | n_MaxLv |
-|------|---------|------------------------|---------|
-| 100024 | `'5'` | `'1'` | 5 |
-| 100144 | `'5'` | `'1'` | 5 |
-| 100394 | **`'500%'`** | **`'100%'`** | 5 |
-| 100514 | **`'500%'`** | `'1'` | 5 |
-| 100634 | **`'500%'`** | **`'100%'`** | 5 |
-| 100754 | `'5'` | `'1'` | 5 |
-
-### 확인이 필요한 사항
-
-1. **`'500%'` 값이 실제 런타임에서 어떻게 적용되는가?**
-   - (A) 기존 스탯의 500% (즉, HP 58 × 5 = 290 증가)
-   - (B) 고정값 500 더하기
-   - (C) 화면 표시용 가공값 (실제 로직에서는 다른 파싱)
-   - (D) 데이터 입력 오류 (실제는 `'5'`여야 함)
-
-2. **`s_Value`가 `'500%'`이고 `s_UpgradeStatValuePara`가 `'100%'`일 때 만렙(5레벨) 총 효과는?**
-   - 현재 추정 로직: `500% + 100% × 4 = 900%`
-   - 이것이 맞다면 MaxHP만으로 도달 불가능한 수치
-
-3. **`Attack_Min`, `Attack_Max`, `MaxPotion` 등 다른 스탯에도 같은 패턴 존재** — 스탯 종류마다 해석 방식이 다른가?
-
-## 배경/맥락
-
-Phase 3 성장 요소 기여도 분석 중, **각성 만렙 시 DPS +1067% / EHP +197%** 라는 비정상적 수치가 산출되었습니다.
-
-- 목표치(DPS +40~60%) 대비 20배 초과
-- 데이터 해석 오류 가능성이 높으나, 정확한 Unity 적용 방식을 확인해야 밸런싱 조정안을 수립 가능
-
-관련 파일: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Script/Table/Tables/table_PCAwakening.cs`
-
-## 기대 산출물
-
-- 해당 값의 **실제 Unity 적용 방식** (코드 경로 + 파싱 로직 설명)
-- 위 4가지 가능성(A/B/C/D) 중 어느 것에 해당하는지 판정
-- 만약 데이터 입력 오류라면 수정이 필요한 노드 ID 목록
-
-## 참조 파일
-
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/PCAwakening.json`
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Script/Table/Tables/table_PCAwakening.cs`
-- `기획팀/밸런싱/수상한잡화점/Phase3_성장요소기여도_v1.md` (3.1절)
-
----
-
-## 응답 (개발팀, 2026-04-15 09:30)
-
-**처리 상태**: 보류 (Phase 3 HOLD 해제 후 정식 응답 예정)
-
-### 보류 사유
-- 본 REQ는 2026-04-14 기획팀의 Phase 3 HOLD 위반 자진 보고 사건 당시 함께 다뤄진 데이터 이슈입니다 (`공유/공통_업무_규칙.md` 교훈 [2026-04-14] Phase 3 HOLD 위반 사례 참조).
-- PD님 판단으로 본 REQ는 **Phase 3 재개 시점에 Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증의 입력값으로 활용**하기로 결정되었습니다.
-- 따라서 현 시점에는 정식 분석·회신을 진행하지 않으며, Phase 3 재개 트리거 발생 시 즉시 `/게임플레이` 에이전트가 분석에 착수합니다.
-
-### 재개 트리거
-- 개발팀 시뮬레이터 이원화 해소 완료 (PD 지시 로그 #3 완료 시점)
-- + Phase 3 HOLD 공식 해제 통보
-
-### 본 응답이 늦어진 사유 (C5 정직성, C3 은폐 금지)
-- 어제 PD님 결정 직후 본 REQ 파일에 보류 사유를 명시했어야 하나 누락. C13 위반에 해당하여 본일 자진 정정함 (`공유/일일보고/2026-04-15_개발팀.md` 참조).
-
-### 담당
-- Phase 3 재개 시: `/게임플레이`
-- 진행 추적: 개발팀장
diff --git a/공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md b/공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md
deleted file mode 100644
index 3ccf7f7..0000000
--- a/공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-요청번호: REQ002
-요청일: 2026-04-14
-요청부서: 기획팀
-수신부서: 개발팀
-담당에이전트: /게임플레이
-우선순위: MEDIUM
-상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ002_응답_장비옵션_음수값.md)
----
-
-> **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후) **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다.
-
-## 요청 내용
-
-`EquipmentList.json`을 통해 8부위 풀셋 장착 시뮬레이션을 했을 때, **모든 등급 공통으로 일부 스탯이 음수 값으로 합산**되는 현상을 발견했습니다. 실제 의도인지 확인 부탁드립니다.
-
-### 구체 예시: PC6001 G1 풀셋 장착 시 MainOption 기여
-
-| 스탯 | 합산 값 | 비고 |
-|------|--------|------|
-| MaxHp | +19 | OK |
-| Attack_Max | +6 | OK |
-| Attack_Min | +4 | OK |
-| **CriDmg** | **-20%** | ⚠️ 음수 |
-| **Avoid_Melee** | **-3%** | ⚠️ 음수 |
-| **Avoid_Range** | **-3%** | ⚠️ 음수 |
-| **AttackCoolTime** | **-3%** | ⚠️ 음수 (쿨타임 감소 = 공속 증가 의미?) |
-| **HitRate** | **-2** | ⚠️ 음수 |
-| ReduceDmg | +1 | OK |
-| MaxShield_Mul | +1% | OK |
-| Cri | +0.5% | OK |
-
-**G1~G5 모든 등급에서 동일한 음수 항목 발견** (등급별로 양수는 커지지만 음수는 유지).
-
-### 확인이 필요한 사항
-
-1. **특정 장비가 의도적으로 디버프성 옵션을 가지는가?**
-   - 예: "원거리 장비는 근접 회피 감소" 같은 트레이드오프 디자인
-   - 디자인 의도라면 어떤 장비가 어떤 페널티를 가지는지 목록 요청
-
-2. **StatusOptionSet의 음수 값이 Unity에서 어떻게 처리되는가?**
-   - (A) 그대로 차감 (의도적 페널티)
-   - (B) 양수로 변환하여 적용 (표기 오류)
-   - (C) 특수 처리 (예: `AttackCoolTime -3%` = 공속 +3% 증가)
-
-3. **`AttackCoolTime -3%`의 해석**:
-   - 쿨타임이 3% 감소(공속 증가)하는 긍정 효과인가?
-   - 아니면 쿨타임이 -3 고정값 감소인가?
-
-## 배경/맥락
-
-Phase 3 성장 요소 기여도 분석 중, 장비 풀셋 기여도 계산에서 이 음수 값들이 DPS/EHP 추정에 영향을 미칩니다. 정확한 해석 없이는 밸런싱 조정안을 수립할 수 없습니다.
-
-관련 파일:
-- 참조: `EquipmentList.n_MainOtion1/MainOtion2` → `StatusOptionSet.n_StatusID` (8자리 ID)
-- 계산 로직: `table_EquipmentList.cs` `Get_Value()` 메서드
-
-## 기대 산출물
-
-- 음수 값의 **의도 여부** (의도 / 오류)
-- 의도라면 **해당 장비 목록과 트레이드오프 설계 문서**
-- 오류라면 **수정 대상 StatusOptionSet ID 목록**
-
-## 참조 파일
-
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/EquipmentList.json`
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/StatusOptionSet.json`
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Script/Table/Tables/table_EquipmentList.cs`
-- `기획팀/밸런싱/수상한잡화점/Phase3_성장요소기여도_v1.md` (3.3절)
-
----
-
-## 응답 (개발팀, 2026-04-15 09:30)
-
-**처리 상태**: 보류 (Phase 3 HOLD 해제 후 정식 응답 예정)
-
-### 보류 사유
-- 본 REQ는 2026-04-14 기획팀의 Phase 3 HOLD 위반 자진 보고 사건 당시 함께 다뤄진 데이터 이슈입니다.
-- PD님 판단으로 Phase 3 재개 시점에 비교 검증용 입력값으로 활용하기로 결정되어, 현 시점에는 정식 분석을 진행하지 않습니다.
-
-### 재개 트리거
-- 개발팀 시뮬레이터 이원화 해소 완료
-- + Phase 3 HOLD 공식 해제 통보
-
-### 본 응답이 늦어진 사유 (C5 정직성)
-- 어제 PD님 결정 직후 보류 사유 명시 누락. C13 위반에 해당하여 본일 자진 정정함 (`공유/일일보고/2026-04-15_개발팀.md` 참조).
-
-### 담당
-- Phase 3 재개 시: `/게임플레이` (장비옵션 파싱 로직 분석)
-- 진행 추적: 개발팀장
diff --git a/공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md b/공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md
deleted file mode 100644
index ad83273..0000000
--- a/공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-요청번호: REQ003
-요청일: 2026-04-14
-요청부서: 기획팀
-수신부서: 개발팀
-담당에이전트: /게임플레이
-우선순위: LOW
-상태: 완료 (2026-04-16 응답 → 공유/소통/개발팀→기획팀/2026-04-16_REQ003_응답_인장_장착수제한.md)
----
-
-> **참고**: 이 요청은 Phase 3 HOLD 상태 중 발견된 데이터 이슈입니다. Phase 3 재개 시점(개발팀 시뮬레이터 이원화 해소 완료 후) **Python 시뮬 수치 vs Unity C# 시뮬 수치 비교 검증**의 입력값으로 활용됩니다.
-
-## 요청 내용
-
-인장(SealList) 시스템에서 **유저가 동시에 장착 가능한 인장 수**를 확인 부탁드립니다. 관련 상수가 `GlobalValue.json` 및 `PCAwakening.json`에서 명시적으로 발견되지 않았습니다.
-
-### 확인이 필요한 사항
-
-1. **기본 장착 슬롯 수**: 유저 PC가 기본적으로 장착 가능한 인장 수 (예: 3개? 4개?)
-2. **장착 슬롯 개방 조건**: 각성 트리 등으로 추가 슬롯이 열리는가?
-   - PCAwakening에 `Open_Seal*` 노드가 없음 확인
-3. **동일 타입/원소 인장 중복 장착 가능 여부**: 예를 들어 Critical 5★를 2개 장착 가능한가?
-4. **타입별 제한**: 공격/방어/유틸리티 인장을 각각 제한 없이 혼합 가능한가?
-
-## 배경/맥락
-
-Phase 3 분석 중 인장의 기여도를 계산할 때, 장착 가능 수에 따라 기여도가 크게 달라집니다:
-- 3개 장착 가정 시: DPS +17%, EHP +25% (목표 +15~30% 범위 안)
-- 6개 장착 가정 시: DPS +34%, EHP +50% (목표 초과)
-
-인장은 가챠(일반 100소울, 고급 300소울)로 획득하며, 12타입 × 5★ 구조입니다.
-
-## 기대 산출물
-
-- 인장 장착 슬롯 수 (기본값, 최대값)
-- 중복 제한 규칙
-- 해당 로직이 구현된 Unity 코드 경로 (있다면)
-
-## 참조 파일
-
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/SealList.json`
-- `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/GlobalValue.json`
-- `기획팀/밸런싱/수상한잡화점/Phase3_성장요소기여도_v1.md` (3.4절)
-
----
-
-## 응답 (개발팀, 2026-04-15 09:30)
-
-**처리 상태**: 보류 (Phase 3 HOLD 해제 후 정식 응답 예정)
-
-### 보류 사유
-- 본 REQ는 2026-04-14 기획팀의 Phase 3 HOLD 위반 자진 보고 사건 당시 함께 다뤄진 데이터 이슈입니다.
-- PD님 판단으로 Phase 3 재개 시점에 비교 검증용 입력값으로 활용하기로 결정되어, 현 시점에는 정식 분석을 진행하지 않습니다.
-
-### 재개 트리거
-- 개발팀 시뮬레이터 이원화 해소 완료
-- + Phase 3 HOLD 공식 해제 통보
-
-### 본 응답이 늦어진 사유 (C5 정직성)
-- 어제 PD님 결정 직후 보류 사유 명시 누락. C13 위반에 해당하여 본일 자진 정정함 (`공유/일일보고/2026-04-15_개발팀.md` 참조).
-
-### 담당
-- Phase 3 재개 시: `/게임플레이` (인장 장착 슬롯 로직) + `/클라이언트팀장` (GlobalValue 테이블 정의)
-- 진행 추적: 개발팀장
diff --git a/공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md b/공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md
deleted file mode 100644
index c9f5541..0000000
--- a/공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-from: 개발팀장
-to: 기획팀장
-type: REQ응답
-subject: "REQ001 응답 — 각성트리 퍼센트값 파싱 방식 확인"
-priority: high
-status: 대기
-date: 2026-04-16
-ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md
----
-
-# REQ001 응답 — 각성트리 퍼센트값(`'500%'`) 실제 파싱 방식
-
-## 결론
-
-**`'500%'`는 런타임에서 `5.0f`(= 500 * 0.01)로 파싱된다. `'5'`와 결과가 동일하며, 데이터 입력 형식의 불일치(입력 오류)이다.**
-
-기획팀이 제시한 4가지 가능성 중 **사실상 (D) 데이터 입력 오류**에 해당. 단, 런타임 결과는 정상 동작하므로 긴급 수정은 불필요.
-
-## 코드 근거
-
-### 핵심 파싱 메서드: `table_base.cs` 20~26행 `Get_Value(string str)`
-
-```csharp
-protected float Get_Value(string str)
-{
-    if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
-    else if (str.Contains("s")) return float.Parse(str.Replace("s", ""));
-    else if (str.Contains("exp")) return float.Parse(str.Replace("exp", ""));
-    return float.Parse(str);
-}
-```
-
-- `%` 포함 시: 숫자 추출 후 `* 0.01f` 적용
-- `%` 미포함 시: 숫자를 그대로 float 변환
-
-### `table_PCAwakening.cs` 53행에서 호출
-
-```csharp
-temp.f_Value = Get_Value(temp.s_Value);
-```
-
-### 파싱 결과 비교
-
-| s_Value | 파싱 결과 (f_Value) | 해석 |
-|---------|-------------------|------|
-| `"5"` | `5.0f` | 고정값 5 |
-| `"500%"` | `5.0f` (= 500 * 0.01) | 퍼센트 표기이나 **결과 동일** |
-
-### 실측 검증: PCID=6001, MaxHP 노드
-
-- Step 2, 14, 26: `s_Value="5"` => `f_Value = 5.0`
-- Step 39, 51, 63, 86, 110, 123: `s_Value="500%"` => `f_Value = 5.0`
-
-**PCID 6001에만 `500%` 형식이 다수 존재.** PCID 6002~6005는 대부분 정수 형식 사용.
-
-## 만렙 총 효과 계산 (기획팀 질문 2번)
-
-`Get_Value(int pcid, ServerData sdata, int addlv)` 메서드: `f_Value + (f_ValuePerLv * (lv - 1))`
-
-따라서 `s_Value="500%"`, `s_UpgradeStatValuePara="100%"`, `n_MaxLv=5` 일 때:
-- `f_Value = 5.0`, `f_ValuePerLv = 1.0` (100% * 0.01)
-- 만렙 효과 = `5.0 + 1.0 * 4 = 9.0` (고정값 +9)
-
-기획팀 추정 `900%`는 잘못된 해석. 실제는 **고정값 +9**.
-
-## 기획팀 밸런싱 시 유의사항
-
-1. `'500%'`는 "MaxHP를 500% 배율 적용"이 아니라, 파이프라인에 의해 **고정값 5.0으로 변환**
-2. 레벨업당 고정 증분 방식 (f_Value + f_ValuePerLv * (lv-1))
-3. **Phase 3 기여도 재계산 시 DPS +1067%라는 비정상 수치는 해소됨** — 실제 효과는 고정값 수준
-4. 다른 스탯(Attack_Min, Attack_Max, MaxPotion 등)도 동일한 파싱 로직 적용
-
-## 권장 조치
-
-기획 엑셀 시트에서 `s_Value` 컬럼 포맷을 정수 또는 퍼센트 한 가지로 통일 권장. 현재 런타임 결과는 동일하므로 긴급 수정 불필요.
diff --git a/공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md b/공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md
deleted file mode 100644
index 1a2150e..0000000
--- a/공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-from: 개발팀장
-to: 기획팀장
-type: REQ응답
-subject: "REQ002 응답 — 장비옵션 음수값은 의도적 트레이드오프"
-priority: medium
-status: 대기
-date: 2026-04-16
-ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ002_장비옵션_음수값_의미확인.md
----
-
-# REQ002 응답 — 장비옵션 음수값 의미
-
-## 결론
-
-**음수 스탯은 의도적인 트레이드오프 설계이다. 데이터 오류가 아니다.**
-
-기획팀이 제시한 가능성 중 **(A) 그대로 차감 (의도적 페널티)**에 해당. 단, `AttackCoolTime`은 예외.
-
-## 코드 근거
-
-### 1. 무기 MainOption2에 음수값 배정
-
-EquipmentList.json에서 무기의 `n_MainOtion2`가 참조하는 StatusOptionSet:
-
-| StatusID | Stat1 | DefaultVal1 | 해석 |
-|----------|-------|-------------|------|
-| 13010001 | CriDmg | **-20%** | 치명타 피해 -20% (페널티) |
-| 13010002 | HitRate | **-3** | 명중률 -3 (페널티) |
-| 13010003 | Cri | **-2%** | 치명타 확률 -2% (페널티) |
-| 13010004 | AttackCoolTime | **-10%** | 공격 쿨타임 -10% = **공속 10% 증가 (보너스)** |
-| 13010005 | MaxHP | **-10** | 최대HP -10 (페널티) |
-
-`UpgradeStatValuePara1`이 모두 `0` → **강화해도 음수값 불변 (고정 페널티)**.
-
-### 2. 방어구 MainOption2에도 음수값 존재
-
-| StatusID | Stat1 | DefaultVal1 |
-|----------|-------|-------------|
-| 13030001 | Avoid_Melee | **-5%** |
-| 13030002 | Avoid_Melee | **-3%** |
-| 13030003 | Avoid_Melee | **-1%** |
-
-### 3. 세트 옵션의 양수/음수 쌍 (트레이드오프 설계 증거)
-
-- ID 21006(-10% MaxHP_Mul) + ID 21007(+10% MaxShield_Mul): "HP 깎고 보호막 강화"
-- ID 21017(+30% CriDmg) + ID 21018(-30% CriDmg): 세트별 방향 차별화
-
-### 4. AttackCoolTime -10% 해석 (기획팀 질문 3번)
-
-`eStat.AttackCoolTime`은 공격 쿨타임이므로 **음수 = 쿨타임 감소 = 공격속도 증가**. 이것은 페널티가 아니라 **보너스**. 해당 무기 라인(n_MainOtion2=13010004)은 다른 라인의 CriDmg 페널티 대신 공속 보너스를 받는 변종.
-
-## 기획팀 밸런싱 시 유의사항
-
-1. 무기 각 라인은 MainOption1(공격력 등 주 스탯) + MainOption2(트레이드오프)로 구성
-2. 음수값은 **강화로도 완화되지 않는 고정 페널티** (UpgradeVal=0)
-3. 풀셋 시뮬 시 음수가 합산되는 것은 **정상 동작**
-4. DPS/EHP 계산 시 `AttackCoolTime` 음수는 **DPS 증가 효과로 반영** 필요
-5. 장비 라인별 트레이드오프 구조를 인지하고 밸런싱에 반영 권장
diff --git a/공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md b/공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md
deleted file mode 100644
index ec4802d..0000000
--- a/공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-from: 개발팀장
-to: 기획팀장
-type: REQ응답
-subject: "REQ003 응답 — 인장 기본 슬롯 6개, 진화 순차 개방, 속성 매칭 제한"
-priority: low
-status: 대기
-date: 2026-04-16
-ref: 공유/소통/기획팀→개발팀/2026-04-14_REQ003_인장_장착수제한_확인.md
----
-
-# REQ003 응답 — 인장 장착수 제한
-
-## 결론
-
-**인장 기본 슬롯 6개. 캐릭터 진화(Evolution) 단계에 따라 순차 개방. 속성(Element) 매칭 제한 있음.**
-
-## 코드 근거
-
-### 1. 기본 슬롯 수 = 6개
-
-`ServerClass.cs` 1665행:
-```csharp
-public List<uint> list_equipseal = new List<uint> { 0, 0, 0, 0, 0, 0 };
-```
-
-PC 생성 시 6개 슬롯 초기화 (값 0 = 빈 슬롯).
-
-### 2. 슬롯 개방 조건 = 캐릭터 진화(Evolution) 단계
-
-`MainMenu_Hero_Seal.cs` 60~63행:
-```csharp
-var alv = MyValue.sdata.Get_PCEvolution(pcid);
-gos_lock[0].SetActive(false); // 슬롯 0은 항상 개방
-for (int i = 1; i < gos_lock.Length; i++)
-    gos_lock[i].SetActive(i > alv);
-```
-
-| 진화 단계 | 개방 슬롯 수 |
-|----------|-------------|
-| 0 | 1개 (슬롯0) |
-| 1 | 2개 (슬롯0~1) |
-| 2 | 3개 (슬롯0~2) |
-| 3 | 4개 (슬롯0~3) |
-| 4 | 5개 (슬롯0~4) |
-| 5+ | 6개 (전체) |
-
-진화 최대 레벨: `MyValue.PCEvolutionMaxLv = 6` (`MyValue.cs` 22행)
-
-### 3. 속성(Element) 매칭 제한
-
-`ServerClass.cs` 717~734행 `Get_CanEquipSealSlotIndex`:
-- 각 슬롯은 캐릭터별로 **고정된 속성(Element)**이 지정 (`pclist` 테이블의 `s_SlotElement` 컬럼, `^` 구분자)
-- 인장의 속성이 **슬롯 속성과 일치**해야만 장착 가능
-- `pcTdata.list_element`에 포함된 속성만 해당 PC가 사용 가능
-
-### 4. 중복 장착 제한
-
-`ServerClass.cs` 690~703행 `CanEquipSeal`:
-- **동일 인장 ID를 한 캐릭터에 중복 장착 불가** (이미 장착 시 return -1)
-- 다른 캐릭터가 착용 중인 인장은 장착 시도 가능 (return 1 = 교체 UI 표시)
-- 동일 타입이라도 **다른 ID면 장착 가능** (같은 Critical 5★ 2개 장착 가능)
-
-### 5. GlobalValue.json/PCAwakening.json에 없는 이유
-
-슬롯 수와 개방 조건은 **코드 하드코딩**으로 관리. 데이터 테이블에 별도 설정 항목이 없는 것이 정상.
-
-## 기획팀 밸런싱 시 유의사항
-
-1. **기여도 계산 시 진화 단계별 장착 수 고려 필요**:
-   - 진화 0단계: 1개 장착 → 기여도 최소
-   - 진화 5단계: 6개 장착 → 기여도 최대
-2. 기획팀 기존 추정(3개 vs 6개)에서 **최대 6개가 정답**, 단 진화 단계 의존
-3. 속성 매칭으로 인해 **원하는 인장을 자유롭게 6개 채울 수 없음** — 슬롯별 속성 제한 반영 필요
-4. 인장 슬롯 수를 변경하려면 코드 수정 필요 (데이터만으로는 불가)
-5. 합성(`Mix_Seal`)은 동일 인장 3개(`SealMixCount=3`) 필요, 장착 중 인장은 합성 불가
diff --git a/공유/소통/완료/2026-04-16_RPT_시뮬레이션_대응_현황보고.md b/공유/소통/완료/2026-04-16_RPT_시뮬레이션_대응_현황보고.md
deleted file mode 100644
index 0657e50..0000000
--- a/공유/소통/완료/2026-04-16_RPT_시뮬레이션_대응_현황보고.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 현황보고
-subject: 시뮬레이터 이원화 해소 작업 현황 및 기획팀 밸런스 작업 대응 계획
-priority: high
-status: 보고
-created: 2026-04-16
-ref: PD님 직접 지시 (2026-04-16), PD 지시 로그 #28, #3
-req_ref: 공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션_대응_기획팀_밸런스작업_지원.md
----
-
-# 시뮬레이터 이원화 해소 작업 현황 및 기획팀 밸런스 작업 대응 계획
-
-> ⚠️ **DEPRECATED (2026-04-17)**: 본 보고서는 07 Headless C# 추출 방향으로 작성되었으나, 2026-04-17 PD님 지시로 **Unity MCP 기반 시뮬레이션 방향으로 전환**되어 일부 효력 상실. **최신 방향은 [`2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`](2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md) 참조.** 본 문서는 Phase A 전투 로직 분석·Unity 엔진 의존성 식별 부분만 유효하며, Phase B~E(Headless 추출·CLI)는 폐기.
-
----
-
-## 1. 07 착수계획 Phase A~E 진행 상태
-
-| Phase | 작업 | 상태 | 비고 |
-|-------|------|------|------|
-| **A. 전투 로직 식별 및 경계 확정** | 전투 코드 전수 분석, Unity 의존성 식별, 전투 공식 명문화 | **부분 완료** | 08 SOT 문서(v1)로 핵심 피해 계산 15단계, 회피 판정 3단계, 크리티컬, 상태이상 등 명문화됨. A-1~A-3 실질 완료. A-4(전투공식 SOT 최종 확정)는 미확인 항목 잔존 |
-| **B. Headless C# 추출 (코어화)** | BattleCore 라이브러리 분리 | **미착수** | 선행: Phase A 최종 확정 필요 |
-| **C. CLI 실행 환경 구성** | dotnet CLI, JSON 입출력, 배치 러너 | **미착수** | 선행: Phase B 완료 필요 |
-| **D. Python 교차 검증** | Python vs C# 결과 비교 | **미착수** | 선행: Phase C 완료 필요 |
-| **E. 문서화 및 인수인계** | 기획팀용 가이드, 구조 문서 | **미착수** | 선행: Phase D 완료 필요 |
-
----
-
-## 2. Unity 전투 코드 분석 결과 (본 보고 시점 실제 확인)
-
-### 2.1 코드 규모 및 구조
-
-| 파일 | 라인 수 | 역할 |
-|------|--------|------|
-| `Actor.cs` | 4,545줄 | **전투 핵심** -- 피해 계산, 회피, 크리티컬, 상태이상, 공격 루프 전체 |
-| `PCActor.cs` | ~200줄 | 플레이어 전용 -- 방어, LowHP, 쉴드 Kill 효과 |
-| `MobActor.cs` | ~250줄 | 몬스터 전용 -- 라인 위치, 샤이니, 드롭 보상 |
-| `MonsterNodeControler.cs` | ~500줄 | 전투 루프 제어 -- 몬스터 배치, 라인 변경, 노드 종료 |
-
-### 2.2 Unity 엔진 의존성 분석
-
-Actor.cs에서 식별된 Unity 의존성 (Headless 추출 시 제거/추상화 대상):
-
-| 의존 항목 | 사용 위치 | 추상화 방안 |
-|----------|----------|-----------|
-| `UnityEngine.Random` | 피해 범위, 회피 판정, 크리티컬 | `IRandomSource` 인터페이스로 교체 (시드 기반 결정론 보장) |
-| `MonoBehaviour` / `Coroutine` | 공격 쿨타임, 상태이상 지속, 라인 변경 | 턴/틱 기반 루프로 전환 |
-| `Animation` / `Animator` | 연출 전용 | `IBattlePresenter` 인터페이스 분리 (Headless에서는 NullPresenter) |
-| `ObscuredInt/Float/Bool` (ACTk) | 치트 방지 | 순수 int/float/bool로 교체 (시뮬에서는 보안 불필요) |
-| `Transform` / `Vector3` | 위치 기반 이펙트, 발사체 | 시뮬에서는 라인/슬롯 인덱스만 필요, 좌표 불필요 |
-| `Addressable` / 리소스 로드 | 스프라이트, 이펙트 | JSON 직접 로드로 대체 |
-| `table_GlobalValue.Ins` 등 싱글턴 | 전역 밸런스 값 참조 | `ITableLoader` 인터페이스로 추상화 |
-
-### 2.3 전투 핵심 공식 현황 (08 SOT v1 + 본 보고 시점 코드 직접 확인)
-
-**피해 계산 15단계**: `Actor.Get_Dmg()` (Actor.cs:521~834) -- 08 SOT 문서와 코드가 일치함을 확인.
-
-핵심 공식 요약:
-```
-기본 = Random[Attack_Min, Attack_Max]  (최소 1 보장)
-중간 = 기본 + 절대증가 + (기본 x 배수증가)
-(크리 시) 중간 x CriDmg
-중간 - 절대감소(방어 포함)
-중간 - (중간 x 감소비율)
-max(중간, 1)
-(쉴드 존재 시) 쉴드 먼저 흡수 -> HP 감산
-```
-
-**회피 판정 3단계**:
-1. 명중률 체크: `HitRate / (Avoid x 3.69)` -- 3.69 상수 근거 미확인
-2. PC 회피율: 근접/원거리 분리 확률 판정
-3. 최초 공격 무조건 회피 (카드 효과)
-
-**크리티컬**: 확률 판정 + N연타 강제 크리, 상한 90%
-
-### 2.4 미확인 항목 (A-4 완료 차단 요인)
-
-| 항목 | 상태 | 영향 |
-|------|------|------|
-| 회피 공식 3.69 상수 근거 | 미확인 | 시뮬 재현에 영향 없음 (값 자체는 확인됨) |
-| PC 방어 입력 윈도우 연결 지점 | 미확인 | 시뮬에서는 "방어 상태 On/Off"로 추상화 가능 |
-| `eCardType.G1~G5` 200+개 효과 전수 맵 | 부분 확인 | 주요 효과는 08 SOT에 문서화됨. 전수 맵핑은 점진적 보완 가능 |
-| 상태이상 중첩 규칙 | 부분 확인 | 기본 CC(Stun/Freezing) 확인됨, 상세 상호작용 추가 확인 필요 |
-
----
-
-## 3. 기획팀 Python 시뮬레이터 현황
-
-기획팀 `.cache/` 디렉토리에서 `battle_sim.py`, `full_stage_sim.py`, `stage_sim_v2.py` 등의 Python 시뮬레이터 파일이 **현재 확인되지 않음** (BurningTimesAi 레포 내에 부재). 원본은 기획팀 로컬 또는 별도 경로에 있을 것으로 추정.
-
----
-
-## 4. Headless C# 추출 기술 판단
-
-### 4.1 추출 가능성 판단: **가능하나 상당한 작업량**
-
-Actor.cs 4,545줄의 전투 로직은 Unity 엔진 의존성이 **깊이 얽혀** 있어 단순 분리가 아닌 체계적 리팩토링이 필요합니다.
-
-**난이도 분류**:
-
-| 영역 | 난이도 | 사유 |
-|------|--------|------|
-| 피해 계산 (Get_Dmg) | **중** | 핵심 수치 로직. 의존성 정리하면 분리 가능. 단 300줄 내 카드 효과 분기가 다수 |
-| 공격 루프 (Update/AttackCoolTime) | **중** | Coroutine → 틱 기반 전환 필요 |
-| 몬스터 배치/스폰 | **하** | 테이블 기반, 순수 로직 |
-| 상태이상 시스템 | **중** | 시간 기반 → 틱 기반 전환 + 효과 200종 분류 필요 |
-| 카드 효과 200종 전수 대응 | **상** | eCardType 전수 분기 → 전략 패턴 리팩토링 권장 |
-| ACTk Obscured 타입 제거 | **하** | 기계적 치환 가능 |
-
-### 4.2 차단 요인
-
-1. **카드 효과 200종**: `eCardType.G1~G5` 전수를 시뮬레이터에 반영해야 정확한 밸런싱이 가능. 단, 기획팀이 필요로 하는 밸런스 작업 범위에 따라 **핵심 효과만 우선 구현**하는 것이 현실적
-2. **데이터 테이블 로더**: JSON 기반이므로 CLI에서 직접 로드 가능 (`GlobalValue.json`, `MonsterList.json`, `MonsterPatternList.json` 등 확인됨)
-3. **결정론 보장**: `UnityEngine.Random` → 시드 기반 난수로 전환 필수
-
----
-
-## 5. 착수 계획 및 기획팀 조기 제공 가능 산출물
-
-### 5.1 즉시 착수 가능한 작업
-
-1. **Phase A-4 완료**: 08 SOT 문서 기반으로 전투공식 SOT 최종 문서 작성 (미확인 항목은 "코드 기준 값" 그대로 반영, 기획 의도와의 대조는 별도)
-2. **Phase B 착수**: BattleCore 순수 도메인 클래스 분리 시작
-   1) Actor → ActorCore (전투 스탯/피해 계산 순수 로직)
-   2) IRandomSource, IBattlePresenter, ITableLoader 인터페이스 정의
-   3) ObscuredInt/Float → int/float 기계적 치환
-
-### 5.2 기획팀 조기 제공 가능 산출물 (전체 Phase 완료 전)
-
-| 산출물 | 선행 조건 | 기획팀 활용 |
-|--------|----------|-----------|
-| **전투 공식 SOT 문서 v2** (A-4) | Phase A 잔여 정리 | 기획팀이 **Python 시뮬 로직을 C# SOT에 맞춰 검증/수정** 가능 |
-| **JSON 데이터 테이블 스키마 문서** | 없음 (즉시 가능) | 기획팀이 데이터 테이블 구조를 파악하여 시뮬 입력값 정비 |
-| **BattleCore 피해 계산 단독 모듈** (B-1 부분) | Phase A-4 완료 | 기획팀이 C# 콘솔에서 피해 계산만 단독 실행 가능 |
-
-### 5.3 차단 요인 없음
-
-현재 이 작업에 대한 차단 요인은 없습니다. Unity 프로젝트 코드 접근 가능하고, 데이터 테이블 JSON이 확인되었으며, 08 SOT 문서가 Phase A의 주요 분석을 커버합니다. 즉시 착수합니다.
-
----
-
-## 6. 요청 사항에 대한 응답 정리
-
-| 요청 | 응답 |
-|------|------|
-| 1. 현재 진행 상태 | Phase A 부분 완료 (08 SOT v1 작성됨), Phase B~E 미착수 |
-| 2. 기획팀 시뮬 환경 구축 | 즉시 착수. 전투공식 SOT v2 → BattleCore 피해 계산 모듈 → CLI 순서 |
-| 3. 차단 요인 | 없음. 즉시 착수 가능 |
-
----
-
-## 7. 변경 이력
-
-| 일자 | 작성자 | 내용 |
-|------|--------|------|
-| 2026-04-16 | 개발팀장 | REQ 수령 후 현황 보고 초안 작성 |
diff --git a/공유/소통/완료/2026-04-16_업무현황_개발실.md b/공유/소통/완료/2026-04-16_업무현황_개발실.md
deleted file mode 100644
index 853fb9d..0000000
--- a/공유/소통/완료/2026-04-16_업무현황_개발실.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 상태보고
-status: 대기
-date: 2026-04-16
----
-
-# 개발팀 업무현황 보고 — 2026-04-16
-
-> ⚠️ **DEPRECATED (2026-04-17, pm-auditor 감사 Major M2)**: 본 보고서는 2026-04-16 스냅샷이며 이후 갱신이 누락되어 **구버전 사실관계 잔류**. #17·#12 "차단됨"으로 기재했으나 실제로는 완료 아카이브 이동됨. OI-2 "결정 대기"로 기재했으나 실제로는 2026-04-16 PD님 승인 완료(커밋 `7187ac6`). **최신 현황은 `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 직접 참조 + 개발팀장 2026-04-17 업무현황 갱신본 생성 예정**.
-
-
-## 1. 즉시 착수 가능한 작업 (차단 요인 없음)
-
-| # | 지시 요지 | 즉시 착수 가능 근거 | 비고 |
-|---|-----------|-------------------|------|
-| #1 | Tier 1 잔여 9종 구현 (EnumToInt·EnumEx·FormatEx·SafeAreaBorder 등) | OI-2·3·4와 무관한 순수 구현 작업 | 2026-04-15 오후 정정에서 즉시 재개 확인 |
-| #5-B | Phase 0-C 착수 (Q-P1/P2/P3 응답서 + 시뮬레이터 전략 초안) | Phase 0-B(08·09·10 SOT) 완료 기반으로 작성 가능 | 착수 후 pm-general 즉시 공유 의무 |
-| #4 | Git 동기화 Phase 0 dry-run 기술 준비 | 호스팅·외부 접근 결정과 독립된 환경 스캔·경로 추상화 검증 단계 | DevOps·QA 공동 진행 가능 |
-| #3 | 시뮬레이터 이원화 해소 진척 재점검 | 선행 착수계획 문서(`07_시뮬레이터_이원화_해소_착수계획_v1.md`) 완료 | 추가 진척분 미반영 상태, 재점검 필요 |
-
-## 2. 차단 요인이 있는 작업
-
-| # | 지시 요지 | 차단 요인 | 재개 트리거 |
-|---|-----------|----------|-----------|
-| #2 | 서버 Critical 보안 3건 | 서버 파트 정비 미완료 (PD님 지시로 보류) | 서버팀 가동 + 서버 파트 정비 완료 통보 |
-| #17 | C17-3 보강 — main 반영 | main 반영은 되돌리기 어려운 액션으로 PD님 별도 승인 필요 (C19-2) | PD님 명시 승인 |
-| #12 | C17 신설 — OI-2 위임 안건 재도출 | OI-2(코어 배포 방식) 안건서(`03_배포방식_안건_v1.md`) 완료, PD님 결정 대기 | PD님 OI-2 결정 |
-
-## 3. PD님 결정 대기 항목
-
-| 안건 | 내용 | 참조 문서 |
-|------|------|----------|
-| OI-2 | 코어 배포 방식 3안 중 택1 (권장: C+H1 하이브리드) | `개발팀/코어_설계/03_배포방식_안건_v1.md` |
-| OI-3 | 법무 검토 범위 — 이미 "불요, 최대 차용 허용" 결정. 확인 완료 | `06_신규코어_설계안_v1.md` |
-| OI-4 | 1차 릴리스 범위 — A안(9개 모듈 일괄) 이미 확정. 확인 완료 | `06_신규코어_설계안_v1.md` |
-| C17-3 main 반영 | C17-3 보강분 main 병합 승인 | `공유/공통_업무_규칙.md` 개정본 |
-
-> **비고**: OI-3·OI-4는 2026-04-15 이미 PD님 결정 완료. 잔여 결정 안건은 OI-2(배포 방식)와 C17-3 main 반영 2건.
diff --git a/공유/소통/완료/2026-04-16_업무현황_기획실.md b/공유/소통/완료/2026-04-16_업무현황_기획실.md
deleted file mode 100644
index c5321c2..0000000
--- a/공유/소통/완료/2026-04-16_업무현황_기획실.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 상태보고
-date: 2026-04-16
-status: 대기
----
-
-# 기획팀 업무현황 보고 (2026-04-16)
-
-> ⚠️ **DEPRECATED (2026-04-17, pm-auditor 감사 Major M3)**: 본 보고서는 2026-04-16 스냅샷. 2026-04-17 Unity MCP 전환 대응 검토는 `2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`에 분리 발행됨. **최신 현황은 `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 직접 참조 + 기획팀장 2026-04-17 업무현황 갱신본 생성 예정**.
-
-
-> 출처: `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 활성 지시 섹션
-
----
-
-## 1. 활성 지시 현황
-
-| 구분 | # | 지시 요지 | 상태 | 차단 요인 / 비고 |
-|------|---|----------|------|----------------|
-| 차단됨 | 3 | Phase 3 업무 착수 | 보류 | `⚠️_PHASE3_HOLD_공지.md` HOLD 유지 중. **재개 조건**: 개발팀 시뮬레이터 이원화 해소 + PD님 재개 지시 |
-
----
-
-## 2. 분류 요약
-
-| 분류 | 건수 | 항목 |
-|------|------|------|
-| 즉시 착수 가능 (차단 요인 없음) | **0건** | — |
-| 차단 요인 있음 | **1건** | #3 Phase 3 착수 (HOLD) |
-| PD님 결정 대기 | **0건** | — |
-
----
-
-## 3. 참고 사항
-
-- 활성 지시 외 26건은 완료 아카이브로 이전 처리됨
-- Phase 3 HOLD 해제 조건 중 **개발팀 시뮬레이터 이원화 해소** 상태는 개발팀 측 확인 필요
-- REQ001~003(Phase 3 선행 산출물)은 재개 시 Python↔C# 비교 검증 입력값으로 보존 중
diff --git a/공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md b/공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md
deleted file mode 100644
index 220f113..0000000
--- a/공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 상태보고
-status: 대기
-작성일: 2026-04-16
----
-
-# 유니티 프로젝트 현재 상태 점검 보고
-
-> 기존 분석 산출물(개발/ 01~10번 문서, 기획/ 12건)이 현재 유니티 프로젝트 실체와 일치하는지 교차 검증한 결과를 보고합니다.
-> 점검 대상 경로: `D:/BurningTimes/FilGoodBandits/DeckBuilding/`
-
----
-
-## 1. 점검 요약
-
-| 항목 | 판정 | 비고 |
-|------|------|------|
-| Unity 버전 | **유효** | 6000.0.67f1 그대로 |
-| 핵심 스크립트 경로 | **유효** (1건 주의) | GameManager.cs 미확인 |
-| 씬 구성 | **유효** | 7개 씬 동일 |
-| 데이터 테이블 경로 | **유효** | DeckBuilding.xlsm 존재 |
-| JSON Export 구조 | **유효** | 58개 JSON + 18개 CSV |
-| xlsm SOT 상태 | **변경됨** | DeckBuilding_Ino.xlsm 오늘 수정 |
-| Assets 폴더 구조 | **변경됨** | 신규 폴더 다수 추가됨 |
-| Res_Addr 구조 | **변경됨** | 신규 그룹 6개 추가 |
-| 스크립트 파일 수 | **변경됨** | 256 → 257개 (Script), Tool 42개 유지 |
-| 테이블 스크립트 수 | **변경됨** | "58개"(문서) → 실측 51개 .cs 파일 |
-| BurningTimesCore | **유효** | `C:/Project/Core/BurningTimesCore/` 존재 |
-| 기획 데이터 참조 경로 | **유효** | Export/*.json 경로 동일 |
-
----
-
-## 2. 항목별 상세 판정
-
-### 2-1. Unity 버전 및 기본 정보 — **유효**
-
-- Unity 버전: `6000.0.67f1` (문서 기재와 동일)
-- 솔루션 프로젝트 구조: Assembly-CSharp, ACTk, MCPForUnity, BurningTimesCore, PlayFab 등 csproj 파일 확인
-- 추가 발견: `spine-*.csproj` 파일 5개 (03 문서에 미기재 — 아래 2-6 참조)
-
-### 2-2. 핵심 스크립트 파일 — **유효** (1건 주의)
-
-| 파일 | 판정 |
-|------|------|
-| `Assets/Script/InGame/Actor/Actor.cs` | 유효 |
-| `Assets/Script/InGame/Actor/PCActor.cs` | 유효 |
-| `Assets/Script/InGame/Actor/MobActor.cs` | 유효 |
-| `Assets/Script/InGame/Stage/MonsterNodeControler.cs` | 유효 |
-| `Assets/Script/My/MyClass.cs` | 유효 |
-| `Assets/Script/My/MyValue.cs` | 유효 |
-| `Assets/Script/InGame/Stage/IngameStageData.cs` | 유효 |
-| `Assets/Script/Template/MonoBehaviourSingletonTemplate.cs` | 유효 |
-| `Assets/Script/Server/ServerInfo.cs` | 유효 |
-| `Assets/Script/Table/table_base.cs` | 유효 |
-| `Assets/Script/Manager/GameManager.cs` | **확인 불가** |
-
-**주의 사항**: `GameManager.cs`가 `Assets/Script/Manager/` 폴더에 없음. Manager 폴더에는 `AddrResourceMgr.cs`, `DataCheckMgr.cs`, `ErrorLogHookManager.cs`, `Title_Mgr.cs` 4개만 존재. 파일 삭제 또는 이동되었을 수 있음. 08 문서에서 `GameManager.Ins` 참조가 "추정" 태그로 표기되어 있어 원래 불확실했던 항목이나, 현재 Manager 폴더에 부재 상태 확인.
-
-### 2-3. 씬 구성 — **유효**
-
-현재 7개 씬 모두 동일하게 존재:
-
-| 씬 | 상태 |
-|----|------|
-| `01_Title.unity` | 유효 |
-| `02_Game.unity` | 유효 |
-| `51_jjonga.unity` | 유효 (용도 불명 그대로) |
-| `96_Tool_MobScale.unity` | 유효 |
-| `97_Tool_Effect.unity` | 유효 |
-| `98_Tool_Mob.unity` | 유효 |
-| `99_Tool.unity` | 유효 |
-
-### 2-4. 데이터 테이블 (DeckBuilding.xlsm) — **변경됨** (주의)
-
-| 항목 | 문서 기재 | 현재 실측 | 판정 |
-|------|----------|----------|------|
-| `DeckBuilding.xlsm` 존재 | ○ (4.8MB) | ○ (4.79MB, 2026-04-14 수정) | 유효 |
-| `DeckBuilding_Ino.xlsm` | ○ 백업 | **2026-04-16 오늘 수정됨** (4.79MB) | **변경됨** |
-| Export/ JSON 수 | 58개 | 58개 JSON 확인 | 유효 |
-| Export/ CSV 수 | "일부" | 18개 CSV | 유효 |
-| Export/ 최근 수정 | — | 2026-04-14 (EventConfig.json, GuideMission.json) | 유효 |
-
-**중요**: `DeckBuilding_Ino.xlsm`이 오늘(2026-04-16) 수정됨. 분석 문서(10번)는 `DeckBuilding.xlsm`을 SOT로, `_Ino`를 백업으로 기재했으나, 오늘 `_Ino` 파일이 갱신된 경위 파악 필요. Export/ 폴더 최근 수정일은 2026-04-14이므로, `_Ino` 수정이 Export에 반영되었는지 확인 불가. **두 파일 중 어느 것이 현행 SOT인지 PD님 또는 개발팀 재확인 권고.**
-
-### 2-5. JSON Export 및 테이블 스크립트 — **변경됨** (수량 불일치)
-
-| 항목 | 03/10 문서 | 현재 실측 | 판정 |
-|------|-----------|----------|------|
-| JSON 파일 수 | 58개 | **58개** | 유효 |
-| CSV 파일 수 | "일부" | **18개** | 유효 |
-| 테이블 스크립트(.cs) 수 | "58개" (10 문서 표현) | **51개** | **변경됨** |
-| 주요 파일 존재 (`table_cardlist.cs`, `table_monsterlist.cs`, `table_GlobalValue.cs`) | ○ | ○ | 유효 |
-
-10번 문서에서 "Export/ 아래 58개 JSON + 소수 CSV"와 "테이블 스크립트 51개"라고 분리 기재되어 있으나, 현재 실측 결과는 JSON 58개 / 스크립트 51개로 일치. 문서 본문에 혼재되어 있던 표현("58개 자동 생성 table_*.cs") 일부가 부정확했던 것으로 확인됨.
-
-### 2-6. Assets 폴더 구조 — **변경됨** (신규 항목 추가)
-
-03 문서 대비 새로 확인된 항목:
-
-| 신규 항목 | 위치 | 내용 |
-|---------|------|------|
-| `EquipIcons/` | Assets/ | 장비 아이콘 리소스 폴더 |
-| `ExternalDependencyManager/` | Assets/ | Firebase SDK 의존성 관리 |
-| `GeneratedLocalRepo/Firebase/` | Assets/ | Firebase 생성 로컬 저장소 |
-| `Tool_Effect/`, `Tool_Mob/`, `Tool_MobScale/` | Assets/ | 씬별 전용 리소스 폴더 (96~98 씬 대응) |
-| `spine-*.csproj` (5개) | 프로젝트 루트 | Spine 애니메이션 런타임 추가됨 |
-| `CLAUDE.md` | 프로젝트 루트 | Claude Code 작업 규칙 파일 |
-
-**주목 사항**: `spine-*.csproj` 파일 5개 추가 — Spine 애니메이션 런타임이 도입되었거나 도입 중인 것으로 추정. 03 문서에 전혀 언급 없음. Assets 폴더 내 Spine 전용 폴더는 현재 미확인이나 csproj 존재로 패키지 설치가 이루어진 상태.
-
-### 2-7. Res_Addr 구조 — **변경됨**
-
-| 03 문서 기재 | 현재 실측 | 판정 |
-|------------|----------|------|
-| Ingame, MainUI, Monster, PC, ScenarioBG (5개) | Ingame, MainUI, Monster, PC, ScenarioBG, **DropDownData, ScenarioEffect, ScenarioImage, ScenarioPrefab, ScenarioSound, Sound, Title** (11개) | **변경됨** |
-
-Addressable 그룹이 5개 → 11개로 확장됨. Sound, Title, Scenario 계열 그룹이 신규 추가된 것으로 보이며, 시나리오/오디오 관련 콘텐츠가 추가된 것으로 추정.
-
-### 2-8. 기획 데이터 참조 경로 — **유효**
-
-기획팀 밸런싱 산출물이 참조하는 경로:
-- `DeckBuilding.xlsm` → 존재 확인 (유효)
-- `Export/CardList.json`, `GlobalValue.json`, `MonsterList.json` 등 → 존재 확인 (유효)
-- `ApprearMonsterPattern.csv`, `CreateMapConfig.csv`, `GlobalValue.csv` → 존재 확인 (유효)
-
-전체테이블감사_v1.md, 밸런싱전략_v1.md, 스테이지난이도곡선_v1.md 등이 참조하는 데이터 파일은 모두 원래 경로에 존재함. 단, Export 마지막 수정일이 2026-04-14이므로 분석 문서 작성 이후 갱신 없음.
-
----
-
-## 3. 종합 판정
-
-### 3-1. 유효 항목 (기존 분석 신뢰 가능)
-
-- Unity 버전, 핵심 스크립트 경로 (GameManager.cs 제외)
-- 전투 시스템 SOT(08번), 카드시스템 아키텍처(09번), 데이터로딩 구조(10번)의 기술적 내용
-- 7개 씬 구성, BurningTimesCore 외부 참조
-- 기획 산출물이 참조하는 Export/*.json, *.csv 경로
-- 패키지 manifest.json (주요 패키지 동일)
-
-### 3-2. 변경됨 항목 (재확인 또는 문서 갱신 필요)
-
-1. **DeckBuilding_Ino.xlsm 오늘 수정** — SOT 판단 재확인 필요
-2. **Spine 런타임 추가** — 03 문서 미기재, 구조 변경 검토 필요
-3. **Res_Addr 그룹 11개로 확장** — 신규 콘텐츠 반영 여부 확인
-4. **Assets 신규 폴더** — EquipIcons, ExternalDependencyManager, GeneratedLocalRepo
-
-### 3-3. 확인 불가 항목
-
-- `GameManager.cs` 현재 위치 (Manager 폴더에 없음)
-- Spine 런타임 도입 범위 (어느 캐릭터/씬에 적용 중인지)
-- DeckBuilding_Ino.xlsm 오늘 수정 내용 (Export 미갱신 상태)
-
----
-
-## 4. 기획팀 후속 판단
-
-1. **xlsm SOT 확정**: `DeckBuilding.xlsm` vs `DeckBuilding_Ino.xlsm` 중 현행 작업 파일 명확화 → 10번 문서 갱신
-2. **Export 동기화 상태**: `_Ino` 수정 내용이 Export에 반영되어 있는지 확인 → 기획 산출물(밸런싱, 시나리오곡선 등) 유효성에 직결
-3. **Spine 도입 현황**: 개발팀에 Spine 패키지 적용 범위 문의 권고
-4. **GameManager.cs 소재**: 개발팀에 Manager 폴더 내 부재 원인 확인 권고
diff --git a/공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md b/공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md
deleted file mode 100644
index 89da0c7..0000000
--- a/공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 상태보고
-status: 대기
-date: 2026-04-16
-subject: BT.Framework git 통합 상태 점검 보고
----
-
-# BT.Framework git 통합 상태 점검 보고
-
-> **작성일**: 2026-04-16
-> **작성자**: 개발팀장
-> **수신**: 총괄PM
-> **목적**: BT.Framework 저장소의 git 관리 상태 전수 점검 및 현황 정리
-
----
-
-## 1. 저장소 기본 정보
-
-| 항목 | 값 |
-|------|-----|
-| **로컬 경로** | `D:/BurningTimes/BT.Framework` |
-| **원격 URL (fetch)** | `ssh://git@burning.i234.me:30030/BurningTimes/BT.Framework.git` |
-| **원격 URL (push)** | `ssh://git@burning.i234.me:30030/BurningTimes/BT.Framework.git` |
-| **현재 브랜치** | `main` |
-| **원격 동기화 상태** | `up to date with 'origin/main'` |
-| **로컬 변경 사항** | 없음 (working tree clean) |
-| **패키지 이름** | `com.nerdnavis.framework` |
-| **패키지 버전** | `0.1.0` |
-| **Unity 호환 버전** | 2022.3 이상 |
-
----
-
-## 2. git 원격 연결 상태
-
-### 2-1. fetch 결과
-
-```
-git fetch origin → 성공
-origin/main HEAD: efde844
-```
-
-**판정**: 원격 저장소 연결 정상. push/pull 모두 가능한 상태.
-
-### 2-2. 최근 커밋 이력 (최신순 5건)
-
-| SHA | 커밋 메시지 |
-|-----|------------|
-| `efde844` | feat(core/patterns): add ServiceLocator + ServiceNotRegisteredException |
-| `b106cae` | feat(core/patterns): add MonoSingleton<T> unifying 4 legacy variants |
-| `0a60587` | feat(core/coroutine): add CoroutineRunner with pause/resume/key dedup |
-| `e47221d` | feat(core/util/log): add central Log, LogLevel, ILogSink |
-| `c916d1c` | chore: initial skeleton for BT.Framework |
-
-**판정**: 총 5커밋. 로컬 HEAD = origin/main HEAD 일치. 미push 변경 없음.
-
----
-
-## 3. 설계 문서 vs 실제 코드 구조 정합성 점검
-
-### 3-1. 설계 문서 목록 (`프로젝트/코어프레임워크/`)
-
-1. `01_아키텍처_개요_v1.md` — 네임스페이스 체계, Tier 분류, 폴더 구조
-2. `02_수상한잡화점_추출대상_v1.md` — 추출 대상 분류표 (A/B/C/D 등급)
-3. `03_배포방식_안건_v1.md` — OI-2 배포 방식 안건서 (PD님 결정 대기 중)
-
-### 3-2. 폴더 구조 정합성
-
-| 설계 문서 기술 | 실제 존재 여부 | 비고 |
-|--------------|------------|------|
-| `Runtime/Core/Patterns/` | ✅ | MonoSingleton.cs, ServiceLocator.cs, ServiceNotRegisteredException.cs, InitMode.cs |
-| `Runtime/Core/Coroutine/` | ✅ | CoroutineRunner.cs, CoroutineHandle.cs, DuplicatePolicy.cs |
-| `Runtime/Core/Util/Log/` | ✅ | Log.cs, LogLevel.cs, ILogSink.cs |
-| `Runtime/Core/Container/` | ❌ | 미구현 (ObservableList 등) |
-| `Runtime/Core/Event/` | ❌ | 미구현 (EventBus) |
-| `Runtime/Core/Data/` | ❌ | 미구현 (DataTable, DataTableSO, CSV 로더) |
-| `Runtime/Core/Util/` (범용 유틸) | 🟡 | .gitkeep만 존재 (MathEx/ValidationEx 등 미구현) |
-| `Runtime/Core/Attribute/` | ❌ | 미구현 (ReadOnly/ShowIf 속성) |
-| `Runtime/Core/Optimization/` | ❌ | 미구현 (EnumToInt 등) |
-| `Runtime/UI/UGUI/` | 🟡 | .gitkeep만 존재 (UIView UGUI 미구현) |
-| `Runtime/UI/UIToolkit/` | 🟡 | .gitkeep만 존재 |
-| `Runtime/UI/Components/` | 🟡 | .gitkeep만 존재 (SafeAreaBorder 미구현) |
-| `Runtime/Addressable/` | 🟡 | .gitkeep만 존재 |
-| `Runtime/Security/` | 🟡 | .gitkeep만 존재 |
-| `Editor/` | ✅ | 폴더 존재, asmdef 파일 포함 |
-| `Tests/Runtime/Core/` | ✅ | CoroutineRunner, MonoSingleton, ServiceLocator, Log 테스트 존재 |
-| `package.json` | ✅ | `com.nerdnavis.framework` 0.1.0 |
-| `CHANGELOG.md` | ✅ | Keep a Changelog 형식 준수 |
-| `Documentation~/` | ✅ | 폴더 존재 (내부 비어있음) |
-
-**판정**: 설계 문서의 폴더 구조 뼈대와 일치. Tier 1 기반 Core 4종만 구현, 나머지는 스켈레톤 상태.
-
----
-
-## 4. 구현 완료 모듈 vs 미완료 모듈
-
-### 4-1. 구현 완료 (Tier 1 기반 Core 4종)
-
-| # | 모듈 | 네임스페이스 | 주요 기능 | 테스트 |
-|---|------|------------|---------|------|
-| 1 | **Log** | `BurningTimes.Core.Util.Log` | 카테고리·레벨 필터, Conditional 스트리핑, ILogSink 외부 연동 | ✅ `LogTests.cs` |
-| 2 | **CoroutineRunner** | `BurningTimes.Core.Coroutine` | 핸들 기반 시작/중단/일시정지/재개, 키 중복 정책(Replace/Ignore/Allow) | ✅ `CoroutineRunnerTests.cs` |
-| 3 | **MonoSingleton\<T\>** | `BurningTimes.Core.Patterns` | 4종 통합(Sync/Async/Inner/Ready), Persistent/AutoCreate/InitMode 옵션, ResetForTests | ✅ `MonoSingletonTests.cs` |
-| 4 | **ServiceLocator** | `BurningTimes.Core.Patterns` | Register/Resolve/TryResolve/Unregister/Clear, Lazy 팩토리 지원, ServiceNotRegisteredException | ✅ `ServiceLocatorTests.cs` |
-
-설계 문서 기술 내용과 구현체 완전 일치 확인.
-
-### 4-2. 미완료 (구현 대기 중)
-
-**Tier 1 잔여 (설계 완료, 구현 미착수)**
-
-| # | 모듈 | 네임스페이스 | 비고 |
-|---|------|------------|------|
-| 1 | EventBus | `BurningTimes.Core.Event` | 타입 안전 Pub/Sub (설계 §4-2) |
-| 2 | ObservableList/Dictionary/Queue | `BurningTimes.Core.Container` | 옵저버 컨테이너 통합 (설계 §4-3) |
-| 3 | ObjectPool\<T\> | `BurningTimes.Core.Patterns` | 오브젝트 풀 |
-| 4 | EnumToInt\<T\> | `BurningTimes.Core.Util` | 박싱 회피 캐싱 (02문서 §4-4) |
-| 5 | EnumEx | `BurningTimes.Core.Util` | StringToEnum 캐싱 등 |
-| 6 | FormatEx / ValidationEx / MathEx 등 | `BurningTimes.Core.Util` | Toolkit 해체 분리 (설계 §4-7) |
-| 7 | SafeAreaBorder | `BurningTimes.UI.Components` | UGUI SafeArea (02문서 #A-5) |
-| 8 | SpriteAtlasRegistry | `BurningTimes.UI.UGUI` | UIAtlasMgr 범용화 |
-| 9 | DataTable / DataTableSO / CSV 로더 | `BurningTimes.Core.Data` | 데이터 테이블 |
-| 10 | Attribute (ReadOnly/ShowIf) | `BurningTimes.Core.Attribute` | Inspector 속성 |
-
-**Tier 2 (신규 설계 필요)**
-
-| # | 모듈 | 네임스페이스 | 비고 |
-|---|------|------------|------|
-| 1 | Economy (Goods) | `BurningTimes.Economy` | 재화 모델 |
-| 2 | Save / ISaveProvider | `BurningTimes.Save` | JSON + AES 레이어 |
-| 3 | Localization | `BurningTimes.Localization` | Unity Localization 래퍼 |
-| 4 | Audio | `BurningTimes.Audio` | BGM/SFX 채널 풀링 |
-| 5 | Addressable 래퍼 | `BurningTimes.Addressable` | 참조 카운팅 Handle |
-
-**Tier 3 (서버팀 셋업 이후)**
-
-| # | 모듈 | 네임스페이스 |
-|---|------|------------|
-| 1 | Network | `BurningTimes.Network` |
-| 2 | Security | `BurningTimes.Security` |
-
----
-
-## 5. 배포 방식 결정 현황 (OI-2)
-
-- **안건 문서**: `프로젝트/코어프레임워크/03_배포방식_안건_v1.md`
-- **권장안**: C + H1 (UPM Git URL + 로컬 file: 오버라이드)
-- **현재 상태**: **PD님 의사결정 대기 중** (정식 보류)
-- **영향 범위**: v0.1.0 태그 부여·차기 프로젝트 manifest.json 연결 등 배포 관련 액션은 PD님 승인 전 유보
-
----
-
-## 6. 종합 판정
-
-| 항목 | 상태 | 비고 |
-|------|------|------|
-| git 원격 연결 | ✅ 정상 | fetch/push/pull 모두 가능 |
-| origin/main 동기화 | ✅ 완료 | 로컬 = 원격 동일 |
-| 설계 문서 정합성 | ✅ 일치 | 구조 설계와 코드 구조 부합 |
-| Tier 1 기반 Core 구현 | 🟡 4/9종 완료 | 잔여 5종 이상 구현 대기 |
-| 테스트 | ✅ 구현 완료 모듈 전수 테스트 | 28건 추정 (커밋 메시지 기준) |
-| 배포 방식 | 🟡 안건 대기 | OI-2 PD님 결정 필요 |
-| 버전 태그 | ❌ 미부여 | OI-2 결정 후 v0.1.0 태그 예정 |
-
----
-
-## 7. 다음 작업 건의
-
-1. **Tier 1 잔여 모듈 구현 재개**: EventBus, ObservableContainer, ObjectPool 등 — PD님 OI-2 결정과 독립적으로 진행 가능
-2. **OI-2 배포 방식 PD님 결정 요청**: `03_배포방식_안건_v1.md` 7절 의사결정 4항목 승인 수령 후 v0.1.0 태그 부여 착수
-3. **Documentation~ 정비**: 각 구현 모듈의 API 문서 작성 (구현 병행 또는 후속)
-
----
-
-*본 보고서는 C13·P19 의무에 따라 PD_지시_트래킹 로그에도 등록됩니다.*
diff --git a/공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md b/공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md
deleted file mode 100644
index aebabd4..0000000
--- a/공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md
+++ /dev/null
@@ -1,287 +0,0 @@
-# Claude Code 콘솔(CLI) 병렬 실행 기술 검토
-
-> **작성**: 개발팀 (PD님 지시)
-> **일자**: 2026-04-16
-> **목적**: PD님이 윈도우 앱에서 에이전트 작업 중 여러 콘솔(CLI)을 열어 병렬 업무 지시가 가능한지 기술 검토
-> **현재 환경**: Claude Code v2.1.110 / Windows 10 Pro / BurningTimesAi 레포 (단일 main 브랜치)
-
----
-
-## 1. 결론 요약
-
-**가능합니다.** Claude Code CLI는 여러 터미널에서 동시 실행을 공식 지원합니다. 단, **같은 디렉토리에서 동시에 파일을 수정하면 git 충돌이 발생**하므로, `--worktree` 플래그를 사용한 작업 영역 격리가 권장됩니다. 아래에 3가지 방법을 난이도순으로 제시합니다.
-
----
-
-## 2. 3가지 실행 방법 (난이도순)
-
-### 2-1. 방법 A: 같은 디렉토리에서 CLI 여러 개 (가장 간단, 주의 필요)
-
-**절차**:
-1. Windows Terminal 또는 PowerShell을 여러 탭/창으로 열기
-2. 각 터미널에서 동일 경로로 이동:
-   ```
-   cd "D:\BurningTimes\BurningTimesAi"
-   ```
-3. 각 터미널에서 독립 claude 세션 시작:
-   ```
-   claude
-   ```
-4. 각 터미널에 서로 다른 업무 지시
-
-**특성**:
-- 각 CLI는 **독립 세션** (세션 ID가 별도)
-- 각 세션이 별도의 대화 컨텍스트를 유지
-- `.claude/settings.json`, `CLAUDE.md` 등 설정은 공유 (동일 디렉토리)
-- MCP 서버도 각 프로세스가 독립 연결
-
-**위험 요소**:
-- 두 세션이 **같은 파일을 동시 수정**하면 나중에 저장하는 쪽이 먼저 저장한 내용을 덮어씀
-- 한쪽이 commit하고 다른 쪽도 commit하면 **git 이력이 꼬일 수 있음**
-- 같은 main 브랜치의 working tree를 공유하므로 `git status`가 양쪽 변경을 모두 보여줌
-
-**적합한 경우**:
-- **서로 다른 파일/영역**만 수정하는 작업 (예: 한쪽은 기획 문서, 다른 쪽은 코드)
-- 읽기 전용 작업 (분석, 검토, 질의응답)
-- 한 세션만 파일 수정, 나머지는 질의/분석용
-
-### 2-2. 방법 B: `--worktree` 플래그로 격리 (권장)
-
-**절차**:
-1. 터미널 1 (메인 작업):
-   ```
-   cd "D:\BurningTimes\BurningTimesAi"
-   claude
-   ```
-2. 터미널 2 (병렬 작업 - 워크트리 격리):
-   ```
-   cd "D:\BurningTimes\BurningTimesAi"
-   claude --worktree task-name
-   ```
-   이렇게 하면 `.claude/worktrees/task-name/` 디렉토리에 별도 작업 복사본이 생성되고, 별도 브랜치(`worktree-task-name`)에서 작업됩니다.
-
-3. 터미널 3 (또 다른 병렬 작업):
-   ```
-   cd "D:\BurningTimes\BurningTimesAi"
-   claude --worktree another-task
-   ```
-
-**특성**:
-- 각 워크트리는 **독립적인 파일 시스템 복사본** + **독립 브랜치**
-- 같은 파일을 수정해도 **절대 충돌하지 않음** (서로 다른 디렉토리)
-- 작업 완료 후 main에 merge하여 통합
-- 디스크 공간이 허용하는 만큼 무제한 생성 가능
-
-**워크트리 작업 후 merge 흐름**:
-```
-# 워크트리에서 작업 완료 후
-git add -A
-git commit -m "작업 완료 메시지"
-
-# 메인 디렉토리로 돌아가서
-cd "D:\BurningTimes\BurningTimesAi"
-git merge worktree-task-name
-git branch -d worktree-task-name
-git worktree remove .claude/worktrees/task-name
-```
-
-**적합한 경우**:
-- 동시에 **같은 파일을 수정**할 가능성이 있는 작업
-- 독립적인 기능 개발/문서 작업을 병렬로 진행
-- 작업 결과를 검토 후 선택적으로 merge하고 싶을 때
-
-### 2-3. 방법 C: `--print` 모드로 일회성 명령 (가장 빠른 질의용)
-
-**절차**:
-```
-claude -p "이 프로젝트의 디렉토리 구조를 설명해줘"
-```
-또는 파이프 사용:
-```
-cat "D:\BurningTimes\BurningTimesAi\CLAUDE.md" | claude -p "이 파일을 요약해줘"
-```
-
-**특성**:
-- 대화형이 아닌 **일회성 실행** (결과 출력 후 즉시 종료)
-- 인터랙티브 세션이 아니므로 후속 질문 불가
-- 대기 중인 윈도우 앱과 완전히 독립
-- 가장 빠르고 가벼운 방법
-
-**적합한 경우**:
-- 간단한 질문/분석 (코드 리뷰, 파일 요약 등)
-- 윈도우 앱이 긴 작업 중일 때 빠른 질의
-- 스크립트에서 자동화된 호출
-
----
-
-## 3. 세션 관리 주요 CLI 플래그
-
-| 플래그 | 용도 | 예시 |
-|--------|------|------|
-| `claude` | 새 대화 시작 | `claude` |
-| `claude -c` | 가장 최근 대화 이어가기 | `claude -c` |
-| `claude -r` | 특정 세션 선택하여 이어가기 | `claude -r "session-name"` |
-| `claude -n "이름"` | 세션에 이름 부여 | `claude -n "기획검토"` |
-| `claude -w "이름"` | 워크트리 격리 세션 | `claude -w "feature-x"` |
-| `claude -p "질문"` | 일회성 질의 (비대화형) | `claude -p "요약해줘"` |
-| `claude --model opus` | 모델 지정 | `claude --model opus` |
-
----
-
-## 4. 병렬 작업 시 git 충돌 관리 분석
-
-### 4-1. 시나리오별 위험도
-
-| 시나리오 | 방법 A (같은 디렉토리) | 방법 B (워크트리) |
-|----------|----------------------|-----------------|
-| 서로 다른 파일 수정 | 안전 (단, commit 순서 주의) | 완전 안전 |
-| 같은 파일 동시 수정 | **위험** (덮어쓰기) | 안전 (merge 시 충돌 해결) |
-| 동시 commit | 가능하나 혼란 | 각자 독립 commit |
-| 동시 push | 두 번째 push가 reject | 각자 브랜치에 push 가능 |
-
-### 4-2. 방법 A 사용 시 충돌 방지 규칙
-
-1. **작업 영역 분리 원칙**: 세션별로 수정 대상 디렉토리/파일을 명확히 구분
-   - 세션 1: `공유/소통/` 하위만
-   - 세션 2: `프로젝트/코어프레임워크/` 하위만
-2. **커밋 순서 보장**: 한 세션이 커밋 완료 후 다른 세션이 커밋
-3. **지시 시 명시**: "이 세션에서는 XX 파일만 수정하라" 식으로 범위 한정
-
-### 4-3. 방법 B 사용 시 merge 전략
-
-1. 워크트리에서 작업 완료 + commit
-2. main 브랜치로 이동
-3. `git merge worktree-branch-name`
-4. 충돌 발생 시 수동 해결 (충돌 가능성 낮음 - 작업 영역이 대개 다르므로)
-5. 워크트리 정리: `git worktree remove .claude/worktrees/name`
-
----
-
-## 5. 대화 로그(P24) 병렬 기록 문제
-
-### 5-1. 문제
-
-같은 날짜의 로그 파일에 여러 CLI가 동시에 write하면:
-- **방법 A**: 두 세션이 같은 파일을 열고 각자 append하면 마지막 저장이 이전 것을 덮어씀
-- **방법 B**: 워크트리별로 별도 복사본이므로 merge 시 충돌
-
-### 5-2. 해결 방안
-
-1. **세션별 로그 파일 분리** (권장):
-   - `2026-04-16_조직운영_세션1.md`
-   - `2026-04-16_조직운영_세션2.md`
-   - 또는 각 세션 지시 시 "로그는 `2026-04-16_코어개발.md`에 기록하라" 식으로 파일 분리
-
-2. **append 전용 규칙**: 한 세션만 특정 로그 파일에 기록하도록 지정
-
-3. **워크트리 방식 사용 시**: 각 워크트리의 로그를 merge 시점에 수동 통합
-
----
-
-## 6. PD님을 위한 실행 가이드
-
-### 6-1. 가장 간단한 시작 방법 (방법 A)
-
-**사전 조건**: Claude Code가 설치되어 있고 `claude` 명령이 PATH에 있어야 합니다 (현재 v2.1.110 설치 확인됨).
-
-**단계**:
-
-1. **윈도우 앱에서 작업 지시** (평소대로)
-   - 에이전트가 긴 작업 수행 중...
-
-2. **새 터미널 열기**
-   - 방법 1: `Win + R` → `powershell` → Enter
-   - 방법 2: Windows Terminal 앱 실행 → 새 탭 (Ctrl+Shift+T)
-   - 방법 3: 작업 표시줄의 Windows Terminal 아이콘 우클릭 → "새 탭"
-
-3. **레포 디렉토리로 이동**:
-   ```
-   cd "D:\BurningTimes\BurningTimesAi"
-   ```
-
-4. **claude 실행**:
-   ```
-   claude
-   ```
-
-5. **작업 지시**: 원하는 업무를 한국어로 지시
-
-6. **추가 터미널이 필요하면** 2~5번 반복
-
-### 6-2. 빠른 질의만 하고 싶을 때
-
-터미널에서:
-```
-cd "D:\BurningTimes\BurningTimesAi"
-claude -p "현재 프로젝트의 코어 규칙 C14 내용을 요약해줘"
-```
-결과가 출력되면 바로 종료됩니다. 윈도우 앱 세션에 영향 없음.
-
-### 6-3. 워크트리로 안전한 병렬 작업
-
-```
-cd "D:\BurningTimes\BurningTimesAi"
-claude -w "기획검토" -n "기획검토 세션"
-```
-이렇게 하면:
-- `.claude/worktrees/기획검토/` 에 프로젝트 복사본 생성
-- `worktree-기획검토` 브랜치에서 독립 작업
-- 메인 디렉토리와 완전 격리
-
----
-
-## 7. 윈도우 앱과 CLI의 관계
-
-| 항목 | 윈도우 앱 (MSIX) | CLI 터미널 |
-|------|------------------|-----------|
-| 세션 격리 | 독립 세션 | 독립 세션 |
-| 대화 이력 | 앱 내부 관리 | `~/.claude/` 하위 저장 |
-| 세션 공유 | 불가 (앱과 CLI는 별개) | CLI끼리 `--resume`으로 이어가기 가능 |
-| 설정 공유 | `.claude/settings.json` 공유 | 동일 |
-| MCP 서버 | 각자 독립 연결 | 각자 독립 연결 |
-| git 작업 | 같은 working tree | 같거나 워크트리로 분리 가능 |
-| 동시 실행 | 가능 (서로 독립) | 가능 (서로 독립) |
-
-**핵심**: 윈도우 앱의 세션과 CLI 세션은 완전히 독립입니다. 앱에서 에이전트가 작업 중이더라도 CLI에서 별도 세션을 시작할 수 있고, 서로 간섭하지 않습니다. 다만 **같은 파일을 동시에 수정하면 충돌 위험**이 있으므로 작업 영역을 구분하거나 `--worktree`를 사용하는 것이 안전합니다.
-
----
-
-## 8. 최근 업데이트 정보 (2026-04-14~15)
-
-Claude Code Desktop 앱이 2026-04-14에 대규모 리디자인되어 **앱 내에서도 병렬 세션을 네이티브 지원**합니다:
-- 사이드바에서 `+ New session` (Ctrl+N)으로 새 세션 생성
-- 각 세션에 자동 git 워크트리 격리 적용
-- 세션 간 드래그앤드롭 레이아웃
-- PR merge 시 세션 자동 아카이브
-
-현재 BurningTimes에서 사용 중인 Windows Store(MSIX) 버전에도 이 업데이트가 적용되었을 가능성이 높습니다. 앱 내 사이드바에 `+ New session` 버튼이 보이면 CLI 없이도 앱 내에서 병렬 작업이 가능합니다.
-
----
-
-## 9. BurningTimes 운용 관점 권고
-
-### 9-1. 현행 규칙과의 정합성
-
-| 규칙 | 병렬 CLI 영향 | 대응 |
-|------|-------------|------|
-| C13 (공유 의무) | 각 CLI 세션의 작업을 트래킹해야 함 | 세션별 이름 부여 (`-n`), 로그 파일 분리 |
-| C18 (공유 완료 판정) | 워크트리 사용 시 main merge 필요 | merge 후 완료 판정 |
-| C20 (커밋 재량) | 병렬 세션 각각의 커밋 순서 관리 | 작업 영역 분리 원칙 |
-| C24 (영속 대화) | CLI는 C24 대상 아님 (임시 병렬용) | 주 작업은 윈도우 앱, CLI는 보조용 |
-| P24 (대화 로그) | 병렬 로그 기록 시 파일 충돌 | 세션별 로그 파일 분리 |
-
-### 9-2. 권장 운용 패턴
-
-1. **윈도우 앱 = 주 세션** (영속 대화, 조직 규칙 준수 주체)
-2. **CLI = 보조 세션** (빠른 질의, 독립 분석, 병렬 작업)
-3. CLI에서 파일 수정 작업 시 `--worktree` 사용 권장
-4. CLI 작업도 대화 로그에 기록 (별도 파일)
-5. 워크트리 작업 완료 후 main merge는 주 세션에서 수행
-
----
-
-## 10. 참고 자료
-
-- Claude Code 공식 CLI 레퍼런스: https://code.claude.com/docs/en/cli-reference
-- Claude Code 병렬 워크플로 문서: https://code.claude.com/docs/en/common-workflows
-- Claude Code Desktop 리디자인 (2026-04-14): https://code.claude.com/docs/en/desktop
diff --git a/공유/소통/완료/2026-04-16_프로세스고도화_개선안_개발실.md b/공유/소통/완료/2026-04-16_프로세스고도화_개선안_개발실.md
deleted file mode 100644
index 54dd262..0000000
--- a/공유/소통/완료/2026-04-16_프로세스고도화_개선안_개발실.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 검토요청
-subject: 조직 프로세스 고도화 3대 문제 — 개발팀 개선안
-priority: high
-status: 대기
-created: 2026-04-16
-ref: PD님 식별 3대 문제 (문서 반영 시차 / 세션 간 소통 부재 / 완료 항목 잔류)
----
-
-# 조직 프로세스 고도화 3대 문제 — 개발팀 개선안
-
-> PD님이 식별하신 3대 문제에 대한 개발 관점 근본 원인 분석 + 실현 가능한 개선안.
-> 총괄PM이 기획팀 의견과 교차 검토 후 통합안 구성 예정.
-
----
-
-## 문제 1: 문서 반영 시차
-
-### 근본 원인
-
-- 현행 `git_fetch_throttle.sh`(UserPromptSubmit hook)는 5분 간격으로 **fetch + 알림**까지만 수행하고 **merge는 하지 않음**
-- SessionStart hook에 자동 merge가 추가(`f595a06`)되었으나, **세션 도중에는 fetch만** → 변경을 "알기만" 하고 반영은 수동
-- PD님이 "세션 갱신"을 직접 지시해야만 merge가 발생하는 구조
-
-### 개선안: UserPromptSubmit hook에 자동 merge 추가
-
-**변경 대상**: `scripts/git_fetch_throttle.sh`
-
-현행 fetch 후 `origin/main`과 `HEAD`의 SHA 비교 시, 차이가 있으면 **자동 fast-forward merge**를 수행하도록 확장.
-
-```bash
-# 현행: 변경 감지만
-if [ "$LOCAL_SHA" != "$REMOTE_SHA" ]; then
-  echo "⚡ 변경 감지"
-fi
-
-# 개선: 감지 + 자동 merge
-if [ "$LOCAL_SHA" != "$REMOTE_SHA" ]; then
-  git merge origin/main --no-edit --ff-only 2>/dev/null
-  if [ $? -eq 0 ]; then
-    echo "⚡ 자동 동기화 완료"
-  else
-    echo "⚠️ 자동 merge 불가 — 수동 세션 갱신 필요"
-  fi
-fi
-```
-
-**설계 근거**:
-- `--ff-only`: 충돌 가능성 있는 경우 자동 skip → 안전
-- 5분 throttle 유지 → 성능 영향 없음
-- C14 부합: 추가 토큰 소비 0, 스크립트 수정 수 줄
-
----
-
-## 문제 2: 세션 간 소통 부재
-
-### 근본 원인
-
-- 6축 소통 허브(`공유/소통/`)가 구축되어 있으나 **실제 활용이 거의 없음**
-- 결정사항·노하우가 PD 지시 로그·일일보고에 묻혀 있어 타 세션이 **어디를 봐야 하는지** 모름
-- "이것을 알려줘야 한다"는 **발신 동기**가 규칙화되지 않음 (C21이 아직 초안 상태)
-
-### 개선안: 2단계 접근
-
-#### 2-A. SessionStart hook에 변경 요약 자동 출력 (즉시 구현 가능)
-
-세션 시작 시 "마지막 확인 이후 무엇이 바뀌었는지"를 커밋 로그에서 자동 추출하여 출력.
-
-```bash
-# SessionStart hook 추가 항목 (scripts/change_digest.sh)
-LAST_SEEN=$(cat "$THROTTLE_DIR/last_seen_sha" 2>/dev/null)
-CURRENT=$(git rev-parse HEAD)
-if [ -n "$LAST_SEEN" ] && [ "$LAST_SEEN" != "$CURRENT" ]; then
-  echo "📋 [변경 요약] 마지막 확인 이후:"
-  git log --oneline "$LAST_SEEN".."$CURRENT" 2>/dev/null | head -10
-fi
-echo "$CURRENT" > "$THROTTLE_DIR/last_seen_sha"
-```
-
-**효과**: 별도 발신 파일 없이 **커밋 메시지 자체가 소통 채널** 역할. inbox 파일 생성 오버헤드 없음.
-
-#### 2-B. C21 정식화 촉진 (규칙 차원)
-
-- C21(작업 완료 즉시 공유)을 초안에서 **정식 프로젝트 규칙으로 격상**
-- 핵심 추가 조항: "타 부서에 영향 있는 변경을 push할 때, 소통 허브에 1-line 알림 파일 필수"
-- `inbox_scan.sh`가 수신 세션 시작 시 자동 알림하므로, **발신만 하면 수신은 자동**
-
----
-
-## 문제 3: 완료 항목 잔류
-
-### 근본 원인
-
-- PD 지시 로그 상태 갱신이 **수동 의존** — 작업 완료 시점에 로그 갱신을 잊으면 "진행중"으로 잔류
-- 본 세션에서 방금 정비한 6건이 정확히 이 패턴 (main 반영 완료인데 상태 미갱신)
-- 일일보고에서 "완료" 보고 + PD 지시 로그 상태 갱신이라는 **이중 관리** 구조
-
-### 개선안: 상태 불일치 자동 감지 스크립트
-
-**신규 스크립트**: `scripts/stale_check.sh`
-
-PD 지시 로그에서 "진행중"인 항목 중, 산출물·사후조치 열에 "완료" "main 반영" 등의 키워드가 포함된 건을 자동 감지.
-
-```bash
-#!/bin/bash
-# PD 지시 로그 상태 불일치 감지
-REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
-LOG="$REPO_ROOT/공유/PD_지시_트래킹/${1}_PD_지시_로그.md"
-[ ! -f "$LOG" ] && exit 0
-
-STALE=$(grep -n "진행중" "$LOG" | grep -i "완료\|main 반영\|main 병합\|push 완료")
-if [ -n "$STALE" ]; then
-  COUNT=$(echo "$STALE" | wc -l)
-  echo "⚠️ [상태 점검] 완료 추정이나 '진행중'인 항목 ${COUNT}건 감지 — 상태 갱신 검토 필요"
-fi
-```
-
-**P21 세션 갱신 프로토콜에 점검 단계 추가**:
-
-| 기존 단계 | 추가 |
-|----------|------|
-| 5. PD 지시 로그 현황 | **5-α. 상태 불일치 감지** — `stale_check.sh` 실행 |
-
-세션 갱신 때마다 "완료인데 진행중으로 남은" 항목이 자동으로 표면화.
-
----
-
-## 종합
-
-| 문제 | 근본 원인 | 개선안 | 구현 규모 |
-|------|----------|--------|----------|
-| **1. 반영 시차** | fetch만, merge 안 함 | `git_fetch_throttle.sh`에 `--ff-only` 자동 merge 추가 | 기존 스크립트 수 줄 수정 |
-| **2. 소통 부재** | 발신 습관 부재 + 변경 요약 없음 | SessionStart에 변경 요약 출력 + C21 정식화 | 신규 스크립트 1건 + 규칙 격상 |
-| **3. 완료 잔류** | 상태 갱신 수동 의존 | `stale_check.sh` 자동 감지 + P21 점검 단계 추가 | 신규 스크립트 1건 |
-
-**C14 준수**: 3건 모두 기존 hook 인프라 위에 최소 변경. 신규 파일 최대 2건(`change_digest.sh`, `stale_check.sh`), 나머지는 기존 스크립트 수정.
-
-**개발팀 즉시 착수 가능**: 총괄PM 통합안 승인 시, 스크립트 구현 + hook 등록 + 테스트까지 개발팀 재량으로 진행 가능.
diff --git a/공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md b/공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md
deleted file mode 100644
index 42871aa..0000000
--- a/공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 검토요청
-subject: 조직 프로세스 고도화 3대 문제 — 기획팀 관점 개선안
-ref: null
-priority: normal
-status: 대기
-created: 2026-04-16
----
-
-# 조직 프로세스 고도화 3대 문제 — 기획팀장 개선안
-
-> **배경**: PD님이 식별하신 3대 문제에 대해 기획 실무 관점의 근본 원인 분석 + 실현 가능한 개선안을 제시합니다.
-> **목적**: 총괄PM이 개발팀 의견과 교차 검토 후 통합안 구성에 활용.
-
----
-
-## 문제 1) 문서 반영 시차 — 세션 갱신 전까지 다른 세션의 변경을 인지 못함
-
-### 근본 원인 분석
-
-기획팀 2026-04-15 Phase 3 HOLD 인지 실패가 본 문제의 실증 사례입니다. 총괄PM이 `⚠️_PHASE3_HOLD_공지.md`를 기획팀 루트에 추가했으나, 기획팀장 세션은 작업 중 CLAUDE.md 재읽기를 하지 않아 HOLD 공지를 인지하지 못한 채 Phase 3에 착수했습니다.
-
-1. **pull 기반 구조의 한계**: git은 pull 모델이므로 수신 세션이 능동적으로 fetch하지 않으면 변경을 알 수 없음
-2. **hook 적용 범위의 간극**: SessionStart hook은 세션 시작 시에만 작동, UserPromptSubmit hook은 5분 throttle이므로 **작업 중간**의 긴급 변경(HOLD 추가 등)은 다음 프롬프트까지 감지 불가
-
-### 개선안
-
-1. **소통 허브 `urgent` 채널 활용**: HOLD·긴급 공지를 `공유/소통/PM→기획팀/`에도 동시 발행. UserPromptSubmit hook이 소통 허브 inbox를 스캔할 때 긴급 건 우선 알림 가능
-2. **UserPromptSubmit hook에 HOLD 파일 변경 감지 추가** (1순위 권장): `🛑_*`·`⚠️_*`·`🚨_*` 패턴 파일이 신규·변경된 경우 **경고 메시지 강제 삽입**. 정상 시 토큰 0, 변경 시에만 1줄 경고이므로 C14 효율적
-3. **프롬프트 횟수 기반 HOLD 재스캔**: C10-2 재확인 의무를 hook으로 보강. "단계 전환" 감지는 어려우므로 **프롬프트 N회마다 HOLD 재스캔**이 현실적
-
-### C14 영향
-고정비 증가 없음. hook 수정 1건 + 카운터 1개.
-
----
-
-## 문제 2) 세션 간 소통 부재 — 대화 컨텍스트가 공유되지 않아 노하우·결정사항이 단절됨
-
-### 근본 원인 분석
-
-기획팀 2026-04-15 C13 위반이 본 문제의 전형입니다. PD님 지시 7건을 수행하면서 공유 채널에 일절 갱신하지 않아 총괄PM이 현황을 파악하지 못했습니다. 같은 날 개발팀에서도 동일 패턴 위반이 발생해 시스템 차원 결함으로 확인되었습니다.
-
-1. **대화 컨텍스트의 폐쇄성**: 각 세션의 대화 내용은 해당 세션에서만 존재하며 다른 세션이 접근 불가. 결정사항·노하우가 대화 속에 묻힘
-2. **공유의 추가 행위 비용**: 작업 수행과 공유 등록이 별개 행위이므로, 작업에 몰입하면 공유를 잊음
-3. **소통 허브 저활용**: `공유/소통/` 6축 허브가 Phase 1으로 신설되었으나 실제 통신 파일이 거의 없어 습관화되지 않은 상태
-
-### 개선안
-
-1. **소통 허브에 "결정로그" 유형 추가 + 세션 종료 시 자동 발행** (1순위 권장): 현재 소통 허브 type에 `결정로그` 추가. "이번 세션에서 X를 Y로 결정했다" 1건 = 1줄 형식. 수신 세션이 SessionStart hook에서 자기 inbox의 결정로그를 자동 요약하면 컨텍스트 단절 완화. 일일보고(P20)와 중복 방지를 위해 "결정 사항만" 추출
-2. **세션 종료 시 "핵심 결정 요약" 자동 산출 의무화**: 세션 종료(또는 P21 세션 갱신) 시점에 핵심 결정사항·노하우를 **3줄 이내로 요약**하여 자기 송신 채널에 발행
-3. **세션 종료 시 로그 vs 실제 작업 교차 검증**: PD 지시 로그 미등록 건을 세션 종료 시점에 자동 감지. 키워드 감지보다 교차 검증이 오탐 리스크 적음
-
-### C14 영향
-세션당 3줄 이내 파일 1건(변동비). 소통 허브 README에 type 1건 추가. hook 보강 1건.
-
----
-
-## 문제 3) 완료 항목 잔류 — 이미 완료된 안건이 미갱신 상태로 계속 보고됨
-
-### 근본 원인 분석
-
-기획팀 PD 지시 로그 #11·#12가 "진행중"으로 잘못 남아있다가 사후 정정된 사례가 해당됩니다.
-
-1. **완료 판정과 로그 갱신의 분리**: 총괄PM이 코어룰 신설을 완료했지만 기획팀 로그는 기획팀장이 갱신해야 하는 구조. 갱신 책임자가 완료 사실을 인지하지 못하면 잔류
-2. **보고 시 전체 로그 재스캔 부재**: P21(세션 갱신)이 "미완료 항목 요약"을 하지만, 완료된 항목의 상태 불일치를 교차 검증하지 않음
-3. **완료 아카이브 메커니즘 부재**: 소통 허브에는 `완료/`로 이동하는 아카이브 절차가 있으나, PD 지시 로그는 완료 항목도 같은 테이블에 계속 남아 가독성 저하 + 오보 리스크
-
-### 개선안
-
-1. **PD 지시 로그 활성·아카이브 2분할** (1순위 권장): 로그 테이블을 `## 활성 지시`(대기·진행중·보류)와 `## 완료 아카이브`(완료·취소)로 분리. 세션 갱신(P21) 시 활성 테이블만 스캔 → 보고 정확도 향상 + 토큰 절감
-2. **완료 판정 자동 교차 검증**: 세션 갱신 시 활성 항목의 산출물 경로가 실제 존재하는지 확인. 산출물이 존재하고 완결되어 있으면 "완료 후보"로 플래그
-3. **범조직 공통 지시의 상태 동기화 규칙**: "범조직 공통" 지시는 총괄PM이 본문 작업 완료 시 양 부서 로그의 해당 항목도 **총괄PM이 일괄 갱신하는 책임** 명시. 부서 팀장 의존 구조에서의 갱신 시차 제거
-
-### C14 영향
-테이블 분리로 활성 항목만 스캔하여 오히려 토큰 절감. 세션 갱신에 `ls` 1~2회 추가. 규칙 명시 1줄 추가.
-
----
-
-## 요약 — 문제별 1순위 권장안
-
-| 문제 | 1순위 권장안 | 실증 근거 | C14 영향 |
-|------|------------|----------|----------|
-| 1) 문서 반영 시차 | hook에 HOLD 파일 변경 감지 경고 삽입 | Phase 3 HOLD 인지 실패 직접 방지 | 고정비 0 |
-| 2) 세션 간 소통 부재 | 소통 허브에 "결정로그" 유형 + 세션 종료 시 자동 발행 | C13 양 부서 동시 위반 근본 방지 | 변동비만 |
-| 3) 완료 항목 잔류 | PD 지시 로그 활성·아카이브 2분할 | #11·#12 상태 불일치 사례 재발 방지 | 토큰 절감 효과 |
-
----
-
-> 총괄PM께서 개발팀 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.
diff --git a/공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md b/공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md
deleted file mode 100644
index 2d559da..0000000
--- a/공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 검토요청
-subject: PM 통합 허브 + 부서 독립 세션 하이브리드 구조 — 개발팀 의견
-priority: high
-status: 대기
-created: 2026-04-16
-ref: PD님 제안 (PM 허브 + 부서 독립 세션 하이브리드)
----
-
-# PM 통합 허브 + 부서 독립 세션 하이브리드 — 개발팀 의견
-
----
-
-## 1. 보고·공유 시점과 범위
-
-### 1-1. PM 허브에 보고해야 하는 시점
-
-| 시점 | 보고 방식 | 근거 |
-|------|----------|------|
-| **PD님 지시 수령 즉시** | PD 지시 로그 등록 + push | C13 (4단계 가시화) |
-| **활성 지시 상태 전환 시** (착수·완료·보류) | PD 지시 로그 갱신 + push | C13 |
-| **타 부서 영향 있는 변경 push 시** | 소통 허브 알림 파일 1건 | C18 (대상 세션 도달) |
-| **코어룰·헌법급 변경 시** | 소통 허브 + 조직공지 | C10-6 (3중 전파) |
-
-### 1-2. PM 허브에 보고하지 않아도 되는 범위
-
-- 부서 내부 실무 진행 (개발팀장↔팀장↔commands 간 위임·작업)
-- PD님이 부서 세션에서 직접 지시하고 완결한 건 (PM에 사후 요약만)
-- 커밋 단위의 세부 코드 변경 (git log이 SOT)
-
-### 1-3. 핵심 원칙
-
-> **"PM 허브는 의사결정 로그와 부서 간 조율의 SOT. 부서 실무의 SOT는 부서 세션 자체."**
-
-PM에 모든 것을 보고하면 C14(토큰 최소화) 위반. 반대로 PM을 생략하면 C13 위반. **상태 전환 이벤트**만 push하는 이벤트 드리븐 방식이 적정선.
-
----
-
-## 2. Agent 호출 시 컨텍스트 단절 최소화
-
-### 2-1. 문제 본질
-
-PM 세션이 Agent 도구로 개발팀장을 호출하면 **새 서브프로세스**가 생성된다. 이 서브프로세스는 개발팀 영속 대화의 컨텍스트(진행 중인 작업, 이전 논의, 의사결정 이력)를 전혀 모른다.
-
-### 2-2. 개선안: 컨텍스트 브리핑 파일 자동 생성
-
-**개발팀이 push할 때마다 `개발팀/CONTEXT_BRIEF.md`를 자동 갱신**하는 방안.
-
-```markdown
-# 개발팀 컨텍스트 브리프 (자동 갱신)
-- 활성 지시: #1(Tier1 잔여), #3(시뮬레이터), #5(Phase0-C) ...
-- 최근 결정: OI-3 확정, OI-5 폐기
-- 차단 요인: #2 서버 보류
-- 최근 커밋 5건: (git log --oneline -5)
-```
-
-PM 세션이 Agent 호출 시 프롬프트에 `개발팀/CONTEXT_BRIEF.md 읽은 뒤 작업하라`고 지시하면, 서브에이전트가 최소한의 컨텍스트를 확보한 상태에서 작업 가능.
-
-**장점**: 별도 인프라 불필요, git push hook(`scripts/context_brief.sh`)으로 자동화 가능
-**한계**: 영속 대화의 "대화 흐름" 자체는 전달 불가 — 팩트(상태·결정·차단요인)만 전달
-
-### 2-3. 운용 권고: 역할 분리
-
-| PM 허브에서 Agent 호출이 적합한 경우 | 부서 영속 대화에서 직접 작업이 적합한 경우 |
-|-----------------------------------|-----------------------------------------|
-| 현황 조회 (읽기 전용) | 설계 의사결정 |
-| 단건 파일 생성·수정 | 다단계 구현 작업 |
-| 교차 검토 (타 부서 산출물 검증) | 기존 작업의 후속 진행 |
-
-PM 허브의 Agent 호출은 **조회·단건 작업**에 한정하고, **연속적 작업은 PD님이 부서 세션에 직접 진입**하는 것이 컨텍스트 보존 면에서 우월.
-
----
-
-## 3. 기술적 보완 사항
-
-### 3-1. 결정 로그(P22)와 기존 PD 지시 로그의 관계 정리
-
-P22 결정 로그가 신설되면, 기존 PD 지시 로그(P19)와 역할이 중첩될 수 있다.
-
-**개발팀 제안**:
-- **P19 (PD 지시 로그)**: PD님이 직접 지시한 작업의 진행 상태 트래킹 (활성/아카이브)
-- **P22 (결정 로그)**: 부서 세션에서 내려진 **의사결정 팩트**만 기록 (결정 내용 + 근거 + 영향 범위)
-- 둘은 **보완 관계**. P19는 "무엇을 하고 있는가", P22는 "무엇이 결정되었는가"
-
-### 3-2. 소통 허브 inbox_scan.sh 확장
-
-현행 `inbox_scan.sh`는 SessionStart 시점에만 실행된다. PM 허브가 브로드캐스팅 역할을 하려면:
-
-- **PM→개발팀/ 채널에 파일이 생기면** 개발팀 세션이 다음 UserPromptSubmit hook에서 감지할 수 있도록 `git_fetch_throttle.sh`에 inbox 스캔 로직 추가
-- 현행: fetch + merge만
-- 개선: fetch + merge + **신규 inbox 파일 감지 시 1줄 알림**
-
-### 3-3. CONTEXT_BRIEF.md 자동 갱신 구현 (선택)
-
-PM 허브의 Agent 호출이 빈번해질 경우에만 필요. 현 시점에서는 PD님이 부서 세션에 직접 진입하는 패턴이 주류이므로, **구현 우선순위는 낮음**.
-
-구현 시 `scripts/context_brief.sh`:
-```bash
-#!/bin/bash
-# pre-push hook 또는 커밋 후 자동 실행
-REPO_ROOT=$(git rev-parse --show-toplevel)
-LOG="$REPO_ROOT/공유/PD_지시_트래킹/개발팀_PD_지시_로그.md"
-BRIEF="$REPO_ROOT/개발팀/CONTEXT_BRIEF.md"
-
-echo "# 개발팀 컨텍스트 브리프" > "$BRIEF"
-echo "최종 갱신: $(date +%Y-%m-%d)" >> "$BRIEF"
-echo "" >> "$BRIEF"
-echo "## 활성 지시" >> "$BRIEF"
-grep "진행중\|보류\|대기" "$LOG" | head -10 >> "$BRIEF"
-echo "" >> "$BRIEF"
-echo "## 최근 커밋" >> "$BRIEF"
-git log --oneline -5 >> "$BRIEF"
-```
-
----
-
-## 요약
-
-| 검토 항목 | 개발팀 의견 |
-|----------|-----------|
-| **보고 시점·범위** | 이벤트 드리븐 — 상태 전환 시만 push (C13 준수 + C14 최소화) |
-| **Agent 컨텍스트 단절** | CONTEXT_BRIEF.md 자동 갱신안 제시. 단, 연속 작업은 PD님 직접 진입이 우월 |
-| **기술 보완** | P22↔P19 역할 분리 명확화 / inbox_scan UserPromptSubmit 확장 / CONTEXT_BRIEF 선택적 구현 |
-
-개발팀은 본 하이브리드 구조에 **찬성**. PD님이 부서 세션에 직접 진입하여 빠르게 추진하시는 현행 패턴이 가장 효율적이며, PM 허브는 부서 간 조율·브로드캐스팅에 집중하는 것이 C14 정신에 부합.
diff --git a/공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md b/공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md
deleted file mode 100644
index 1da1204..0000000
--- a/공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 검토요청
-subject: PM 통합 허브 + 부서 독립 세션 하이브리드 — 기획팀 의견
-ref: null
-priority: normal
-status: 대기
-created: 2026-04-16
----
-
-# PM 통합 허브 + 부서 독립 세션 하이브리드 — 기획팀 의견
-
-> PD님 제안 구조에 대해 기획 실무 관점의 의견을 정리합니다.
-
----
-
-## 1. PM 허브에 보고·공유해야 하는 시점과 범위
-
-### 기획팀 실무에서 식별한 보고 시점 3가지
-
-1. **PD님 직접 지시 수령 즉시** — P19 의무 그대로. PD님이 기획팀 세션에서 직접 지시하면 PD 지시 로그에 등록하고, 이것이 곧 PM 허브 공유. 현행 구조와 동일하므로 추가 부담 없음
-
-2. **기획 결정이 개발팀에 영향을 미칠 때** — 기획팀 독립 세션에서 밸런싱 수치를 확정하거나, 스테이지 구성을 변경하거나, 신규 시스템을 설계하면 개발팀 작업에 직접 영향. 이 시점에 PM 허브로 공유하지 않으면 개발팀이 구 기획을 기반으로 작업할 리스크 발생. **기획팀의 2026-04-15 Phase 3 HOLD 인지 실패가 정확히 이 패턴의 역방향 사례** — 개발팀 측 결정(시뮬레이터 이원화 해소 선행 필요)이 기획팀에 전파되지 않아 HOLD 위반
-
-3. **세션 종료 시 P22 결정로그 발행** — 하이브리드 구조에서 가장 중요한 연결 고리. 기획팀이 독립적으로 빠르게 작업하되, 세션 종료 시 핵심 결정만 결정로그로 push하면 PM 허브가 수신. 이것이 "독립성"과 "가시성"의 균형점
-
-### 범위 기준 — "PM이 모르면 문제가 되는가?"
-
-기획팀이 자체 판단으로 PM에 공유하지 않아도 되는 작업:
-- 기존 밸런싱 문서의 오탈자 수정, 내부 분석 메모 작성
-- 기존 확정 방향 내 세부 수치 조정 (PD님 확정 범위 내)
-
-반드시 PM 허브에 공유해야 하는 작업:
-- **신규 기획 방향 결정** (새로운 시스템·메커니즘 제안)
-- **기존 확정 사항 변경** (수치 체계 변경, 조건 추가/삭제)
-- **개발팀 REQ 발생** (소통 허브 경유)
-- **HOLD·차단 요인 발견** (C3 즉시 보고)
-- **PD님 직접 지시 전체** (C13 절대 원칙)
-
----
-
-## 2. 개발팀 협업 시 소통 허브만으로 충분한가?
-
-### 현재 소통 허브의 강점
-
-기획팀이 2026-04-15에 REQ001~003을 `기획팀→개발팀/` 채널로 발행한 경험이 있습니다. YAML 프론트매터 표준, 파일 명명 규칙, 응답 처리 절차가 정비되어 있어 **비동기 요청·응답**에는 충분합니다.
-
-### 부족한 지점 — 실시간 협의가 필요한 경우
-
-기획 실무에서 개발팀과의 협업은 두 가지 패턴으로 나뉩니다:
-
-1. **비동기 REQ** (소통 허브로 충분): "이 데이터 테이블의 퍼센트 값이 곱연산인지 합연산인지 확인해주세요" → REQ 발행 → 개발팀 응답 → 완료. 현행 구조 그대로 작동
-
-2. **동기 협의** (소통 허브만으로 부족할 수 있음): "Phase 3 재개 시 C# 시뮬 결과와 기존 Python 시뮬 결과를 교차 검증해야 하는데, 검증 기준과 허용 오차를 함께 정의해야 합니다" → 여러 차례 왕복이 필요. 소통 허브 파일이 5~6개 쌓이면서 맥락이 분산될 리스크
-
-### 보완 제안
-
-1. **소통 허브 파일 내 `## 스레드` 섹션 활용**: 동일 안건의 왕복 응답을 하나의 파일 내 스레드로 관리. 신규 파일 생성 대신 원본 파일에 `## 응답 (개발팀, 2026-04-16)` 섹션을 append하는 방식. 소통 허브 README에 이미 "같은 파일에 `## 응답` 섹션 추가" 옵션이 명시되어 있으므로, 이 패턴을 **다회 왕복 시 기본값**으로 권장하면 충분
-
-2. **PM 허브 경유 에스컬레이션**: 기획팀↔개발팀 직접 채널로 3회 이상 왕복해도 합의에 도달하지 못하면, PM 허브로 에스컬레이션하여 총괄PM이 조율. 현행 P5(의사결정 구조)와 자연스럽게 연결
-
----
-
-## 3. 기획 실무 관점에서 보완이 필요한 부분
-
-### 보완 1 — 기획팀 독립 세션에서의 "결정 권한 범위" 명확화
-
-하이브리드 구조에서 기획팀이 독립적으로 빠르게 작업한다면, 어디까지를 기획팀장 재량으로 결정하고 어디서부터 PM·PD님 확인이 필요한지 경계가 중요합니다.
-
-현행 C20(팀장 재량)이 커밋·push에 대한 재량을 정의하고 있으나, **기획 결정 자체의 재량 범위**는 명시되어 있지 않습니다.
-
-제안:
-- **기획팀장 재량**: 기존 확정 방향 내 세부 수치 조정, 문서 보완, 분석 작업
-- **PM 확인 필요**: 신규 시스템 제안, 기존 방향 변경, 타 부서 영향 결정
-- **PD님 확인 필요**: 핵심 밸런싱 방향 전환, 유저 경험에 직접 영향, 데이터 자산 변경(C6)
-
-### 보완 2 — 부서 간 HOLD·차단 요인의 양방향 즉시 전파
-
-Phase 3 HOLD 사례에서 드러난 것처럼, 한 부서의 결정이 다른 부서의 작업을 차단할 수 있습니다. 하이브리드 구조에서 부서가 독립적으로 작업하면 이 리스크가 더 커집니다.
-
-제안:
-- HOLD·차단 요인 발생 시 소통 허브의 **양방향 채널 동시 발행** 의무화 (PM→부서 + 부서→부서)
-- `hold_watch.sh` hook(오늘 구현 완료)이 이미 자기 부서의 HOLD 파일 변경을 감지하므로, **소통 허브 inbox에 도착한 타 부서 HOLD 정보도 감지 대상에 추가**하면 보완 완료
-
-### 보완 3 — 결정로그(P22)와 일일보고(P20)의 역할 분리 재확인
-
-하이브리드 구조에서 결정로그가 PM 허브의 주요 입력이 되므로, P20 일일보고와의 중복을 최소화해야 합니다.
-
-제안:
-- **P22 결정로그**: "무엇을 결정했는가" (사실만, 1건 1줄)
-- **P20 일일보고**: "왜 그렇게 결정했는가 + 맥락 + 이슈" (배경 포함)
-- 일일보고는 결정로그를 **참조**하되 내용을 **복제하지 않음** (C14-4 참조 무결성)
-
----
-
-## 요약
-
-| 검토 항목 | 기획팀 의견 |
-|----------|-----------|
-| PM 보고 시점 | PD 지시 즉시 + 개발팀 영향 결정 시 + 세션 종료 P22 |
-| 소통 허브 충분성 | 비동기 REQ 충분, 다회 왕복은 스레드 패턴 + PM 에스컬레이션으로 보완 |
-| 보완 필요 | 1) 기획 결정 재량 범위 명확화 2) HOLD 양방향 즉시 전파 3) P22·P20 역할 분리 |
-
-> 총괄PM께서 개발팀 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.
diff --git a/공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md b/공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md
deleted file mode 100644
index 13605d7..0000000
--- a/공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md
+++ /dev/null
@@ -1,375 +0,0 @@
-# CLAUDE.md 핫 리로드 대안 — 기술 검토 보고서
-
-> **작성**: 개발팀장 (PD님 지시, 2026-04-16)
-> **대상**: 총괄PM
-> **목적**: PD님이 제안한 "CLAUDE.md 핫 리로드 대안(공용 임시 md 파일)" 구현의 기술적 실현 가능성 검토
-
----
-
-## 1. Claude Code의 CLAUDE.md 로드 메커니즘 — 사실 기반 분석
-
-### 1-1. CLAUDE.md 로드 시점
-
-Claude Code의 CLAUDE.md 처리는 두 가지 수준에서 발생한다.
-
-| 수준 | 시점 | 동작 |
-|------|------|------|
-| **디스크 읽기** | 세션 시작, `/compact` 후, 서브디렉토리 파일 접근 시 | `.md` 파일을 디스크에서 읽어 메모리에 적재 |
-| **API 전송** | **매 턴(every turn)** | 메모리에 적재된 CLAUDE.md 내용을 API 요청의 시스템 프롬프트 영역에 포함하여 전송 |
-
-핵심 사실: **Claude Code는 매 API 호출마다 시스템 프롬프트 + 도구 정의 + CLAUDE.md + 대화 이력 전체를 재전송한다.** 프롬프트 캐싱(prompt caching)으로 비용은 최적화되지만, 구조적으로 매 턴 재전송은 사실이다.
-
-그러나 **CLAUDE.md를 디스크에서 재읽기하는 시점**은 제한적이다:
-
-1. **세션 시작 시** — 프로젝트 루트 및 상위 디렉토리의 CLAUDE.md, CLAUDE.local.md를 전부 읽음
-2. **`/compact` 후** — 프로젝트 루트 CLAUDE.md만 디스크에서 재읽기 + 재주입
-3. **서브디렉토리 파일 접근 시** — 해당 서브디렉토리의 CLAUDE.md를 lazy load
-4. **서브에이전트(Agent/Task) 생성 시** — 새 인스턴스가 CLAUDE.md를 독립적으로 로드
-
-**결론: 세션 중간에 CLAUDE.md를 외부에서 수정하더라도, 에이전트가 `Read` 도구로 명시적으로 읽지 않는 한 변경분은 자동 반영되지 않는다. 단, `/compact` 시에는 루트 CLAUDE.md만 재읽기된다.**
-
-### 1-2. `@파일경로` import 구문의 동작
-
-공식 문서 확인 결과:
-
-- `@path/to/import` 구문으로 외부 파일을 임포트 가능
-- **임포트된 파일은 "세션 시작 시(at launch)" 확장(expand)되어 컨텍스트에 적재**
-- 최대 재귀 깊이 5단계
-- 상대 경로는 임포트를 포함하는 파일 기준으로 해석
-
-**핵심 한계: `@CLAUDE_LIVE.md` 같은 임포트를 넣어도, 해당 파일은 세션 시작 시 1회만 읽힌다. 세션 중간에 `CLAUDE_LIVE.md`를 수정해도 자동 반영되지 않는다.**
-
-### 1-3. `system-reminder` 태그의 원리
-
-Claude Code는 `<system-reminder>` XML 태그를 사용하여 **매 턴 동적 컨텍스트를 주입**한다.
-
-- 시스템 프롬프트(정적, 캐싱됨)와 달리, `system-reminder`는 **메시지 배열(messages array)** 에 삽입
-- 프롬프트 캐시를 깨뜨리지 않으면서 동적 정보(날짜, 파일 상태, git 상태 등)를 주입
-- Claude는 이 태그를 "높은 우선도 컨텍스트"로 취급
-- **반응형(reactive)**: 주기적이 아니라 특정 조건(파일 수정, 도구 사용, 컨텍스트 전환)에 따라 주입
-
-**이것이 PD님 제안의 핵심 실현 경로가 될 수 있다.**
-
-### 1-4. hooks의 컨텍스트 주입 능력
-
-| Hook 이벤트 | 발화 시점 | stdout 처리 | 한도 |
-|-------------|----------|-------------|------|
-| **SessionStart** | 세션 시작/재개/clear/compact | stdout → 에이전트 컨텍스트 주입 | 10,000자 |
-| **UserPromptSubmit** | 사용자 프롬프트 제출 시 (매 턴) | stdout → 에이전트 컨텍스트 주입 | 10,000자 |
-| **PreToolUse** | 도구 실행 전 | `updatedInput` 가능 | 10,000자 |
-| **PostToolUse** | 도구 실행 후 | `additionalContext` 가능 | 10,000자 |
-
-**UserPromptSubmit이 "매 턴 자동 실행"되므로, 여기서 파일을 읽어 stdout으로 출력하면 에이전트 컨텍스트에 매 턴 주입이 가능하다.**
-
-JSON 구조 옵션:
-```json
-{
-  "additionalContext": "파일 내용을 여기에..."
-}
-```
-
-또는 단순 텍스트 출력도 컨텍스트에 주입된다.
-
-**알려진 이슈**: UserPromptSubmit hook에서 JSON 출력 시 새 세션 첫 메시지에서 에러가 표시되는 버그가 보고되어 있음 (GitHub Issue #17550). 단순 텍스트 출력이 더 안정적.
-
----
-
-## 2. 공용 임시 파일 방안의 기술적 실현성 분석
-
-### 2-1. PD님 원안: `CLAUDE_LIVE.md` 접근법
-
-PD님 제안의 핵심 목표:
-- 세션 시작 후에도 계속 업데이트·참조 가능한 공유 파일
-- 여러 세션이 동시에 읽고 쓸 수 있음
-- 일정 주기 또는 세션 재시작 시 메인 CLAUDE.md로 동기화
-
-### 2-2. 실현 가능한 3가지 경로
-
-#### 경로 A: `@CLAUDE_LIVE.md` import (CLAUDE.md 내 import)
-
-```
-# CLAUDE.md 내부
-@CLAUDE_LIVE.md
-```
-
-| 항목 | 평가 |
-|------|------|
-| 자동 로드 | 세션 시작 시 1회만. **세션 중 갱신 불가** |
-| 토큰 비용 | 세션 시작 시 고정비에 편입 |
-| 동시 쓰기 | 파일 자체는 가능하나 반영이 안 되므로 무의미 |
-| **판정** | **불가** — PD님 요구(세션 중 동적 갱신) 미충족 |
-
-#### 경로 B: UserPromptSubmit hook으로 매 턴 파일 읽기 + 컨텍스트 주입
-
-```bash
-#!/bin/bash
-# UserPromptSubmit hook
-LIVE_FILE="$(git rev-parse --show-toplevel 2>/dev/null)/CLAUDE_LIVE.md"
-if [ -f "$LIVE_FILE" ]; then
-  CONTENT=$(head -c 9500 "$LIVE_FILE")  # 10,000자 한도 고려
-  echo "$CONTENT"
-fi
-exit 0
-```
-
-| 항목 | 평가 |
-|------|------|
-| 자동 로드 | **매 턴 자동** (UserPromptSubmit 발화 시) |
-| 토큰 비용 | **매 턴 변동비 증가** (파일 크기만큼) |
-| 동시 쓰기 | git 기반이면 commit/push/pull 필요. 로컬 파일이면 즉시 반영 |
-| 10,000자 한도 | CLAUDE_LIVE.md가 10,000자 초과 시 잘림 |
-| **판정** | **기술적으로 가능** — PD님 요구 충족. 단, 토큰 비용·한도 제약 존재 |
-
-#### 경로 C: SessionStart hook + `/compact` 트리거 조합
-
-```bash
-#!/bin/bash
-# SessionStart hook (resume, compact 매처 포함)
-LIVE_FILE="$(git rev-parse --show-toplevel 2>/dev/null)/CLAUDE_LIVE.md"
-if [ -f "$LIVE_FILE" ]; then
-  CONTENT=$(head -c 9500 "$LIVE_FILE")
-  echo "$CONTENT"
-fi
-exit 0
-```
-
-| 항목 | 평가 |
-|------|------|
-| 자동 로드 | 세션 시작/재개/compact 시에만 |
-| 토큰 비용 | 경로 B보다 낮음 (세션 시작 시 1회 고정비) |
-| 동시 쓰기 | 가능하나 반영은 세션 재시작 또는 compact 시에만 |
-| **판정** | **부분 실현** — 세션 재시작/compact 시만 반영. 실시간성 부족 |
-
-### 2-3. 실현 가능성 종합
-
-| 경로 | PD님 요구 충족도 | 구현 난이도 | 토큰 비용 | 안정성 |
-|------|----------------|-----------|----------|--------|
-| A. `@import` | 불가 | 매우 낮음 | 고정비 | 높음 |
-| **B. UserPromptSubmit** | **충족** | 낮음 | **매 턴 변동비** | 중 (버그 존재) |
-| C. SessionStart | 부분 충족 | 낮음 | 세션 시작 고정비 | 높음 |
-| **B+C 혼합** | **충족** | 낮음 | 절충 가능 | 중~높음 |
-
----
-
-## 3. 권장 구현 방안
-
-### 3-1. 권장안: 경로 B+C 혼합 — "UserPromptSubmit 조건부 읽기 + SessionStart 전량 읽기"
-
-**기본 구조:**
-
-```
-D:/BurningTimes/BurningTimesAi/
-├── CLAUDE.md              ← 정적 규칙 (세션 시작 시 로드, 변경 빈도 낮음)
-├── CLAUDE_LIVE.md          ← 동적 공유 파일 (세션 중 갱신 가능)
-└── .claude/settings.json   ← hooks 설정
-```
-
-**SessionStart hook** (세션 시작 시 전량 주입):
-```bash
-#!/bin/bash
-LIVE_FILE="$(git rev-parse --show-toplevel 2>/dev/null)/CLAUDE_LIVE.md"
-if [ -f "$LIVE_FILE" ]; then
-  CONTENT=$(head -c 9500 "$LIVE_FILE")
-  echo "[CLAUDE_LIVE 로드] 세션 시작 시점 스냅샷:"
-  echo "$CONTENT"
-fi
-exit 0
-```
-
-**UserPromptSubmit hook** (변경 감지 시에만 주입 — throttle + diff 체크):
-```bash
-#!/bin/bash
-REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
-LIVE_FILE="$REPO_ROOT/CLAUDE_LIVE.md"
-[ ! -f "$LIVE_FILE" ] && exit 0
-
-THROTTLE_DIR="$HOME/.claude/.nerdnavis_throttle"
-mkdir -p "$THROTTLE_DIR" 2>/dev/null
-HASH_FILE="$THROTTLE_DIR/live_md_hash"
-
-CURRENT_HASH=$(sha1sum "$LIVE_FILE" 2>/dev/null | cut -d' ' -f1)
-PREV_HASH=$(cat "$HASH_FILE" 2>/dev/null)
-
-if [ "$CURRENT_HASH" != "$PREV_HASH" ]; then
-  CONTENT=$(head -c 9500 "$LIVE_FILE")
-  echo "[CLAUDE_LIVE 갱신 감지]"
-  echo "$CONTENT"
-  echo "$CURRENT_HASH" > "$HASH_FILE"
-fi
-exit 0
-```
-
-**핵심 설계 의도:**
-1. SessionStart: 세션 시작 시 CLAUDE_LIVE.md 전량을 컨텍스트에 주입 (초기 상태 인지)
-2. UserPromptSubmit: 매 턴 SHA1 해시만 비교하고, **변경이 있을 때만** 파일 내용을 주입 (토큰 절감)
-3. 변경이 없는 턴에서는 해시 비교만 수행하므로 오버헤드 최소화
-
-### 3-2. CLAUDE_LIVE.md 파일 설계
-
-**파일 위치**: 레포 루트 `CLAUDE_LIVE.md`
-**git 추적**: `.gitignore` 미포함 — git으로 추적하여 세션 간 공유
-**최대 크기**: 9,500자 이내 (10,000자 한도 - 헤더 여유분)
-**형식**: 
-
-```markdown
-# CLAUDE_LIVE — 실시간 조직 공유 컨텍스트
-> 최종 갱신: 2026-04-16 14:30 by PM
-
-## 긴급 공지
-- (없음)
-
-## 활성 HOLD
-- (없음)
-
-## 현재 진행 작업 (부서별)
-### 개발팀
-- Tier 1 구현 진행 중
-
-### 기획팀
-- Stage 14~18 밸런싱 진행 중
-
-## 최근 규칙 변경
-- C26 Skill 패킹 전환 (2026-04-16)
-```
-
-**갱신 주체**: 
-- 총괄PM이 주 갱신자 (조율·공지 역할)
-- 각 팀장이 자기 섹션 갱신 가능
-- PD님이 직접 긴급 공지를 작성할 수도 있음
-
-### 3-3. 메인 CLAUDE.md와의 동기화
-
-| 시점 | 동작 | 책임 |
-|------|------|------|
-| 규칙 변경 확정 시 | CLAUDE_LIVE.md의 "최근 규칙 변경" → CLAUDE.md 본문 반영 | 총괄PM |
-| 세션 종료 시 | CLAUDE_LIVE.md의 임시 항목 정리 (완료·소멸 항목 삭제) | PM |
-| 정기적 | 잔류 항목이 영구화 대상인지 판단 → CLAUDE.md 또는 SKILL.md 편입 | PM |
-
-**동기화 방향: CLAUDE_LIVE.md → CLAUDE.md (단방향).** CLAUDE.md의 변경은 세션 재시작으로 자연 반영되므로 역방향 동기화는 불필요.
-
----
-
-## 4. 리스크 및 한계 분석
-
-### 4-1. 동시 쓰기 문제
-
-| 시나리오 | 위험도 | 대응 |
-|---------|--------|------|
-| 같은 PC, 복수 CLI 세션이 동시 write | **높음** — 파일 덮어쓰기 경합 | 단일 세션 구조(C24)에서는 발생 가능성 낮음. Agent 서브에이전트는 순차 실행이므로 동시 write 없음 |
-| 다른 PC, git push/pull 경유 | **중간** — merge conflict 가능 | 섹션별 분리(개발팀/기획팀)로 충돌 최소화. 충돌 시 git이 감지 |
-| PD님이 직접 편집 + 에이전트 편집 동시 | **낮음** — 시간차 존재 | CLAUDE_LIVE.md 편집 시 git commit/push 전까지 로컬 한정 |
-
-**단일 세션 구조(C24) 하에서는 동시 쓰기 문제가 구조적으로 크게 완화된다.** PM 세션 1개에서 Agent 도구로 부서를 순차/병렬 호출하므로, 파일 쓰기 경합은 Agent 도구의 직렬화에 의해 관리된다.
-
-### 4-2. 토큰 비용 증가 (C14 정합성)
-
-| 항목 | 비용 | C14 영향 |
-|------|------|----------|
-| SessionStart 1회 전량 주입 | 최대 9,500자 (~1,200 토큰) | **고정비 증가** — C14-3에 따라 PD님 승인 필요 |
-| UserPromptSubmit 변경 감지 시 | 변경 없으면 0, 변경 시 ~1,200 토큰 | **조건부 변동비** — 대부분의 턴에서 0 |
-| 해시 비교 오버헤드 | 무시 가능 (sha1sum 1회) | 없음 |
-
-**결론**: 변경 감지 방식을 채택하면 대부분의 턴에서 추가 토큰 비용 0. 세션 시작 시에만 ~1,200 토큰 고정비 추가. **기존 CLAUDE.md 고정비 대비 약 10~15% 추가 수준으로, C14 관점에서 수용 가능 범위.**
-
-### 4-3. 10,000자 한도
-
-- hook stdout 출력 한도가 10,000자
-- CLAUDE_LIVE.md를 9,500자 이내로 유지해야 함
-- 초과 시 파일로 저장되고 미리보기만 컨텍스트에 주입 → 에이전트가 별도 Read 필요
-- **대응**: CLAUDE_LIVE.md는 "긴급·활성 정보만" 담는 경량 파일로 운용. 상세 내용은 별도 파일에 두고 경로만 명시
-
-### 4-4. 보안·무결성
-
-| 위험 | 평가 | 대응 |
-|------|------|------|
-| 임시 파일이 메인 CLAUDE.md를 오염 | **매우 낮음** — 동기화는 PM 수동 판단 | 자동 동기화 금지. 방향: LIVE → CLAUDE.md, 수동 한정 |
-| 악의적 내용 주입 | **낮음** — git 추적으로 변경 이력 추적 | git blame으로 누가 언제 수정했는지 추적 가능 |
-| hook 스크립트의 보안 | **낮음** — `.claude/settings.json`에서 관리 | 기존 hook과 동일한 보안 수준 |
-
-### 4-5. 기존 hook과의 상호작용
-
-현재 `UserPromptSubmit`에 `git_fetch_throttle.sh`와 `hold_watch.sh`가 등록되어 있다. 신규 hook 추가 시:
-
-- **복수 hook의 stdout는 연결(concatenate)** 되어 에이전트에 주입
-- 10,000자 한도는 **hook별**이 아니라 **전체 합산**인지 확인 필요 (공식 문서에서 "per hook"로 명시)
-- 기존 hook의 stdout 출력과 간섭하지 않도록 설계 필요
-
-### 4-6. 알려진 버그
-
-- **GitHub Issue #13912**: UserPromptSubmit hook의 stdout이 에러를 유발한다는 보고 (문서와 모순)
-- **GitHub Issue #17550**: JSON `hookSpecificOutput` 사용 시 새 세션 첫 메시지에서 에러 표시
-- **대응**: 단순 텍스트 출력 방식 우선 채택. JSON 방식은 버그 해결 확인 후 전환
-
----
-
-## 5. 대안 검토
-
-### 5-1. `.claude/rules/` 디렉토리 활용
-
-`.claude/rules/` 하위의 `.md` 파일은 **세션 시작 시 자동 로드**된다. `paths` frontmatter 없는 규칙은 무조건 로드.
-
-- CLAUDE_LIVE.md를 `.claude/rules/live.md`로 배치하면 세션 시작 시 자동 포함
-- 그러나 **세션 중 동적 갱신은 불가** (경로 A와 동일한 한계)
-- `.claude/rules/`의 파일도 세션 시작 시 1회 로드 후 변경 감지 안 됨
-
-**판정: 동적 갱신 불가로 PD님 요구 미충족.**
-
-### 5-2. `/compact` 트리거를 통한 강제 재로드
-
-- `/compact` 실행 시 프로젝트 루트 CLAUDE.md가 디스크에서 재읽기됨
-- CLAUDE.md에 `@CLAUDE_LIVE.md` import가 있다면, `/compact` 시 재확장 여부는 **미확인** (공식 문서 미언급)
-- 수동 `/compact` 실행이 필요하므로 "자동" 요건 미충족
-- **GitHub Issue #22085**: `/compact` 시 자동 재로드 기능 요청이 올라와 있으나 미구현
-
-**판정: 수동 트리거 의존으로 자동성 부족. 보조 수단으로만 활용 가능.**
-
-### 5-3. `/reload` 커스텀 Skill 방식
-
-- Skill 파일에 `/reload` 명령을 정의하고, SIGHUP으로 Claude 프로세스를 재시작하는 접근법이 커뮤니티에서 공유됨
-- 세션 재시작 = CLAUDE.md 재로드, 그러나 **대화 컨텍스트 일부 소실**
-- `--continue` 플래그로 이전 세션 재개 가능하나 사용성 저하
-
-**판정: 급진적 해결이나 사용성 비용이 높음. 비권장.**
-
----
-
-## 6. 최종 결론 및 권장
-
-### 6-1. 기술적 실현 판정
-
-**PD님의 "공용 임시 md 파일" 구상은 기술적으로 실현 가능하다.**
-
-최적 경로는 **UserPromptSubmit hook에서 변경 감지 후 조건부 주입(경로 B+C 혼합)**이며, 이는:
-1. 기존 hook 인프라(`.claude/settings.json`)에 자연스럽게 통합 가능
-2. 매 턴 해시 비교만 수행하여 토큰 비용 최소화
-3. 변경 시에만 주입하여 C14(토큰 최소화) 준수
-4. 단일 세션 구조(C24)에서 동시 쓰기 문제 자연 완화
-
-### 6-2. 구현 시 PD님 결정 필요 사항
-
-1. **CLAUDE_LIVE.md의 git 추적 여부** — 추적(세션 간 공유) vs `.gitignore`(PC별 독립)
-2. **C14-3 고정비 증가 승인** — 세션 시작 시 ~1,200 토큰 추가 고정비
-3. **구현 착수 여부** — 본 검토 결과를 바탕으로 착수 지시
-
-### 6-3. 구현 시 개발팀 예상 작업
-
-1. `scripts/live_context_inject.sh` 신규 작성 (UserPromptSubmit hook)
-2. `scripts/live_session_load.sh` 신규 작성 (SessionStart hook)
-3. `.claude/settings.json` hook 등록 추가
-4. `CLAUDE_LIVE.md` 템플릿 작성
-5. 기존 hook과의 상호작용 검증
-
----
-
-## 참고 자료
-
-- [Claude Code 공식 문서 — Memory](https://code.claude.com/docs/en/memory)
-- [Claude Code 공식 문서 — Hooks](https://code.claude.com/docs/en/hooks)
-- [Claude Code 시스템 프롬프트 분석 (GitHub)](https://github.com/Piebald-AI/claude-code-system-prompts)
-- [Claude Code 소스코드 내부 분석 (GitHub Gist)](https://gist.github.com/Haseeb-Qureshi/d0dc36844c19d26303ce09b42e7188c1)
-- [UserPromptSubmit stdout 버그 (GitHub Issue #13912)](https://github.com/anthropics/claude-code/issues/13912)
-- [hookSpecificOutput 첫 메시지 에러 (GitHub Issue #17550)](https://github.com/anthropics/claude-code/issues/17550)
-- [CLAUDE.md `/compact` 후 재로드 요청 (GitHub Issue #22085)](https://github.com/anthropics/claude-code/issues/22085)
-- [Claude Code 프롬프트 캐싱 작동 원리](https://www.claudecodecamp.com/p/how-prompt-caching-actually-works-in-claude-code)
-- [System-reminder 작동 원리 분석](https://michaellivs.com/blog/system-reminders-steering-agents/)
-- [Claude Code 시스템 프롬프트 빌드 과정](https://www.dbreunig.com/2026/04/04/how-claude-code-builds-a-system-prompt.html)
diff --git a/공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md b/공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md
deleted file mode 100644
index 0092c5a..0000000
--- a/공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md
+++ /dev/null
@@ -1,164 +0,0 @@
----
-type: 응답서
-from: 개발팀장
-to: 총괄PM / 기획팀장
-subject: Phase 0-C Q-P2 정밀 2차 응답 (터치 방어 메커닉 실측 확정)
-date: 2026-04-17
-status: 완료
-related:
-  - 공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md  # 1차(초벌) 응답서
-  - 프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
-  - 프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
-depends_on:
-  - PD 지시 #37 (Q-P2 정밀 2차 + Unity MCP 시뮬 인프라 4종)
----
-
-# Phase 0-C — Q-P2 정밀 2차 응답 (터치 방어 메커닉 실측 확정)
-
-## 0. 본 문서 범위
-
-1차 응답서(`2026-04-17_Phase0-C_QP_응답서_개발팀.md`)에서 **"미확인 — 정밀 코드 리뷰 필요"**로 분류했던 Q-P2 4개 항목(감소 수치 실위치·고정/변동 여부·쿨다운 존재·지속형 여부)을 **Unity 프로젝트 코드 전수 실측**으로 확정한다. 읽은 파일은 `PCActor.cs`·`MobActor.cs`·`Actor.cs(base)`·`EffectMgr.cs`·`UITouchHandler.cs`·`IngameUIManager.cs`·`GlobalValue.json` (전부 Read only, C23 정직 보고).
-
----
-
-## 1. Q-P2 3개 서브 질의 — 실측 기반 확정 답변
-
-### 1-1. 서브 질의 1: "터치 1회 = 다음 공격 1회 피해 50% 감소?"
-
-**확정 답변: ✗ 전제 오해 + 수치 불일치**
-
-- **감소 비율 실측**: **30%** (기획팀 가정 "50%"와 불일치)
-- **근거**: `Assets/ResWork/Table/Export/GlobalValue.json` — `{"s_ID": "PCDefence_Mul", "n_Value": "0.3", "exception": "PC 방어 시 피해% (0.3 = 30%)"}`
-- **적용 지점**: `Assets/Script/InGame/Actor/Actor.cs:782-783` — `if (ActorStatus == eActorStatus.Defecne) reducedmg_rate += table_GlobalValue.Ins.Get_Float("PCDefence_Mul");`
-- **추가 고정 감소**: `PCDefence = 1` (절대값 1 감소) — 소수점·저데미지 구간에서 효과, 고데미지 구간에서는 미미
-
-**추가 정정**: "터치 1회 = **다음 공격 1회**" 도 부정확. 실제는 **터치 Down↔Up 구간 동안 지속**되는 상태 효과이며, 단일 공격에 바인딩되지 않는다. 1-2로 연결.
-
-### 1-2. 서브 질의 2: "터치 유지 중 계속 감소?"
-
-**확정 답변: ✓ 그렇다 (지속형 상태 효과)**
-
-- **구조**: `UITouchHandler.cs` (`Assets/Script/UGUI/Util/UITouchHandler.cs`) — `IPointerDownHandler`·`IPointerUpHandler`·`IPointerExitHandler` 인터페이스로 구현
-- **바인딩**: `IngameUIManager.cs:39` — `m_PCDefence.Set(m_PCActor.Play_Defence, m_PCActor.Release_Defence, null)`
-- **동작 흐름**:
-  1. `OnPointerDown` → `isTouching = true` + `Play_Defence()` 호출 → `ActorStatus = eActorStatus.Defecne`
-  2. 터치 유지 동안 매 프레임 `Update()`에서 `m_onHold?.Invoke()` (현재 `null` 바인딩이라 no-op)
-  3. `OnPointerUp`·`OnPointerExit`·`OnDisable` → `isTouching = false` + `Release_Defence()` → `ActorStatus = eActorStatus.Idle`
-- **지속 중 피격 처리**: `Actor.cs:515-519` — 데미지 계산 완료 후 `ActorStatus == Defecne`면 `huddmg.Set_Block(dmg, ...)` + `PCBlock` 이펙트 재생. 매 피격마다 **PCDefence_Mul(30%) + PCDefence(1) 감소가 반복 적용**됨
-- **상태 중 공격 차단**: `Actor.cs:4500` — `ActorStatus == Defecne` 시 공격 프레임 return. 즉 **방어 중 DPS 0**
-- **상태 중 Hit 애니메이션 차단**: `PCActor.cs:133` — `ActorStatus == Defecne` 시 `Play_Hit` 조기 return
-
-**결론**: 터치 유지 시간 동안 "무한 횟수 30% 감소 + 공격 불가"의 **공격↔방어 트레이드오프** 메커닉. 지속형이며 횟수 제한 없음.
-
-### 1-3. 서브 질의 3: "쿨다운?"
-
-**확정 답변: ✗ 없음 (즉시 재사용 가능)**
-
-- **`UITouchHandler.cs` 전수 확인 결과**: 쿨다운 타이머·재사용 제한·다음 활성화 대기 로직 **일절 없음**
-- **`PCActor.Play_Defence`·`Release_Defence`**: 상태 전환만 수행, 쿨 관련 코드 없음 (`PCActor.cs:148-162`)
-- **`Actor.cs` 검색 결과**: `Cooltime`·`CoolDown`·`BlockCool`·`DefenceCool` 어떤 키워드로도 방어 쿨 관련 코드 미발견
-- **실행 시나리오**: 유저가 터치 Up 즉시 다시 터치 Down 가능. 시스템상 1프레임 Up/Down 교차도 허용 (단 게임 경험상 연속 탭은 의미 없음 — 상태 유지가 더 유리)
-
-**유의**: 이는 **2026-04-17 시점 Dev 브랜치**(커밋 `43b6074c4`) 기준. 향후 기획팀이 쿨다운 도입을 결정하면 `UITouchHandler` 래핑·별도 `DefenceCooldownMgr` 추가가 자연스러운 확장점.
-
----
-
-## 2. 종합 — 터치 방어 메커닉 SOT (실측 확정판)
-
-| 항목 | 값 | 근거 경로 |
-|------|-----|----------|
-| 감소 비율 (%) | **30%** | `GlobalValue.json.PCDefence_Mul = 0.3` |
-| 고정 감소 (절대) | **1** | `GlobalValue.json.PCDefence = 1` |
-| 적용 지점 | `Actor.cs:774-783` (절대+%) | 데미지 계산 pipeline |
-| 활성 조건 | `ActorStatus == eActorStatus.Defecne` | PC 한정 (Mob은 `Play_Defence` override 없음) |
-| 입력 메커닉 | 터치 Down→Up 지속 | `UITouchHandler.cs` (`IPointerDown/Up/ExitHandler`) |
-| 쿨다운 | **없음** | 코드 전수 확인 결과 미존재 |
-| 지속형/1회성 | **지속형** (터치 유지 = 방어 유지) | `isTouching` 상태 기반 |
-| 방어 중 공격 | **불가** (차단됨) | `Actor.cs:4500`, `PCActor.cs:150` (Defecne 시 Set_Active/조기 return) |
-| 방어 중 Hit 애니 | **재생 안함** (무적 아님, 데미지는 감소된 양으로 들어감) | `PCActor.cs:133` |
-| 방어 중 회피(Evasion) | **차단** (Defecne 우선) | `PCActor.cs:143` |
-| 적용 대상 범위 | Melee·Range 구분 없이 전 피격 | `Actor.cs:774` (`hitterAttacktype` 분기 없음, Defecne 보정은 공통) |
-| 몬스터 방어 | **메커닉 부재** (MobActor에 `Play_Defence` override 없음) | `MobActor.cs` 전수 확인 |
-| 이펙트 | `PCBlock` 이펙트 재생 + `huddmg.Set_Block` 호출 | `Actor.cs:517-518` |
-| 오타 주의 | 원본 enum 표기 `Defecne`(Defence 오타) | 코드 전반 일관 오타, 수정 시 전역 영향 |
-
----
-
-## 3. 기획팀 가정 vs 실측 불일치 리스트 (충돌 현황)
-
-| 기획팀 가정 | 실측 결과 | 영향 |
-|------------|-----------|------|
-| 50% 피해 감소 | **30%** 감소 | 앵커 전투 생존 시뮬 결과가 기획팀 추정보다 낮게 나올 것 |
-| 1회 공격 단위 | **지속형** 상태 효과 | "터치 1회 N회 방어" 계산식 전면 재검토 필요 |
-| 쿨다운 존재 가능 | **없음** | 밸런싱 상한이 시스템이 아닌 **유저 조작 여유**에 의존 (동시 공격 불가 trade-off가 실질적 상한) |
-| 터치=단순 감소 | 터치=**공격 불가 + 감소 + 이펙트** 3효과 묶음 | "공격 기회 손실 비용"을 반영한 밸런스 재계산 필요 |
-
-본 불일치는 **Phase 0-C Q-P1(4마리 노드 초반 위험도 의도) 해석에도 직접 영향**. 30%+지속형+공격불가 조건이라면 "카드 0장 + 4마리" 시나리오에서 터치 방어 전략이 기획 의도 대비 얼마나 효과적인지를 시뮬레이션으로 재측정해야 함. Unity MCP 시뮬 인프라 4종(본 PD 지시 #37의 축 B)이 이 재측정의 직접 도구.
-
----
-
-## 4. 개발팀 해석·권고
-
-### 4-1. 용어 정리 권고 (기획팀 협의 대상)
-- "터치 방어"·"블록"·"가드"·"Defence"·"Block"이 혼용 중 — `eActorStatus.Defecne` 오타 + `PCBlock` 이펙트 + `UITouchHandler.m_PCDefence` 바인딩이 각기 다른 용어 사용. 기획 SOT는 **"터치 방어(Touch Defence)"** 단일 표기 권장.
-
-### 4-2. 수치 SOT 권고
-- **GlobalValue.json이 단일 SOT**. 밸런스 변경 시 본 파일 수정으로 일원화. 카드·장비·인장에 의한 추가 감소는 **별개 스택**(`ReduceDmg`·`ReduceRangeDmg_Mul` 등)이며 방어 중에도 누산 적용됨 (`Actor.cs:773·781`).
-
-### 4-3. Q-P1 재평가 안건
-"의도된 설계 여부"는 **기획팀 영역**(1차 응답 유지). 단, 본 정밀 실측으로 "터치 방어 = 30% + 지속형 + 공격불가"가 확정된 이상, 기획팀은 본 메커닉 값을 전제로 의도를 재검토할 수 있음. Unity MCP 시뮬 인프라(§5)로 실측 생존률 측정 가능.
-
----
-
-## 5. Unity MCP 시뮬 인프라 4종 (별도 산출물로 분리)
-
-본 응답서와 동시 발신되는 4종 설계 문서:
-
-1. `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` — 독립성 보장 + 어셈블리 분리 설계
-2. `프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md` — 입력 포맷
-3. `프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md` — 출력 포맷
-4. `프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md` — 기획팀장용 복붙 템플릿 3종
-
-실행 코드 스켈레톤 (독립 어셈블리, Editor-only):
-- `Assets/Sim/BurningTimes.Sim.asmdef`
-- `Assets/Sim/Runtime/SimulationRunner.cs`
-- `Assets/Sim/Runtime/ScenarioLoader.cs`
-- `Assets/Sim/Runtime/ResultEmitter.cs`
-- `Assets/Sim/Runtime/Models/ActorModel.cs`
-
-**핵심 원칙**: 기존 `Assets/Script/` 일체 수정 없음. 메커닉은 독립 모델로 재구현(30% + 지속형 + 공격불가 규칙을 순수 C# 로직으로). 빌드 포함 안 됨(Editor-only define).
-
----
-
-## 6. 기각안 (P24 기각안 필드 필수)
-
-- **기각안 A: 실제 `Actor.cs` 경로를 재사용하여 시뮬 실행** — 1) 기존 코드 수정 위험 2) PlayMode 의존성 과도 3) PD님 "독립 시뮬" 제약 위반. 별도 Models/ 독립 재구현으로 우회
-- **기각안 B: Q-P2 답변에 "50% 추정" 유지** — 실측 결과 30% 확정. C23 위반 회피. 기획팀 가정 정정 필요성 명시가 본 2차 응답의 존재 이유
-- **기각안 C: 터치 방어에 쿨다운 있을 것이라 추정** — 코드 전수 확인 결과 미존재. 추정을 단정으로 포장하는 건 C23 위반. "시스템 상한 부재, 유저 조작 상한이 실질 상한"으로 정확히 기재
-- **기각안 D: Mob도 방어 메커닉 있다고 가정** — `MobActor.cs` 전수 확인 결과 `Play_Defence` override 부재. 추정 금지, 실측 기록
-
----
-
-## 7. 후속 작업
-
-### 7-1. 개발팀 (본 응답서 발신과 동시 완료)
-- [x] Q-P2 3서브 질의 실측 확정
-- [x] 시뮬 인프라 4종 설계 문서
-- [x] Sim 어셈블리·스켈레톤 코드 작성
-- [x] PD 지시 로그 #37 진행중→완료 갱신
-- [x] 수상한잡화점 대화로그 엔트리 (기각안 포함)
-
-### 7-2. 기획팀 필요 액션
-1. 터치 방어 수치 가정 정정 (50% → 30%, 1회 → 지속형, 쿨다운 없음)
-2. Q-P1 재평가 (본 실측 기반 의도 재확인)
-3. 시나리오 JSON 작성 (§5의 02 스키마 참조) → Unity MCP 실행 요청
-4. 기획팀장이 Q-P2 정책 최종 결정 후 개발팀에 공유 (코드 변경 필요 시 별도 PR)
-
-### 7-3. PM 조율 필요
-- 본 PD 지시 #37 완료 아카이브 이동 + C20-1-A 자동 push
-- 기획팀에 본 응답서 전달 (본 문서 완료 이동 시 자동 공유됨)
-
----
-
-## 부록. 변경 이력
-- **v1 (2026-04-17)**: 초판. 개발팀장. Unity 프로젝트 Dev 브랜치 `43b6074c4` 기준 실측.
diff --git a/공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md b/공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md
deleted file mode 100644
index 2feb12c..0000000
--- a/공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-type: 응답서
-from: 개발팀장
-to: 총괄PM / 기획팀장
-subject: Phase 0-C Q-P1/Q-P2 개발 관점 응답 + 시뮬레이터 전략 업데이트
-date: 2026-04-17
-status: 완료
-related:
-  - 프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
-  - 프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md
-  - 프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
-depends_on:
-  - PD 지시 #5-B (Phase 0-C Q-P 응답)
-  - PD 지시 #28 (Unity MCP 전환)
----
-
-# Phase 0-C — Q-P1/Q-P2 응답 + 시뮬레이터 전략 업데이트
-
-## 0. 본 문서 범위
-
-기획팀이 `Phase0_1_앵커전투시뮬레이션_v1.md §6` 에 남긴 질의 2건에 대한 개발 관점 응답 + **2026-04-17 PD님 Unity MCP 전환 지시(#28)를 반영한 시뮬레이터 전략 재설정**.
-
-개발팀 PD 지시 로그 #5-B의 "Q-P1/P2/P3" 표기는 실제로 Q-P1(질의 1건) + Q-P2(서브 질의 3건)의 편의 표기였음. 본 응답서는 기획팀 원문 기준으로 Q-P1·Q-P2를 대응한다.
-
-## 1. Q-P1 응답 — "4마리 노드 초반 위험도는 의도된 설계인가?"
-
-### 1-1. 기획팀 질의 요지
-> "카드 0장 상태에서 4마리 노드가 '터치 방어 없이는 위험'한 현재 상태는 의도된 설계? (=터치 방어를 자연스럽게 가르치기 위함?)"
-
-### 1-2. 개발팀 응답 (실증 기반)
-**개발팀 단독 답변 불가 범주**. 이유:
-1. "의도된 설계 여부"는 **기획 의도의 영역**이며 개발팀은 결정권이 없음 (C7·C11 구분)
-2. 개발팀이 제공할 수 있는 것은 **코드 실측**(터치 방어 유무에 따른 생존 시나리오) + **구조적 힌트**(초기 4마리 노드가 카드 풀 구성 규칙과 맞물려 있는지)
-
-### 1-3. 개발팀이 제공 가능한 근거
-- `Assets/Script/InGame/Actor/PCActor.cs` L37: `eActorStatus.Defecne` + `InGameInfo.Ins.Set_PCBlock` → 터치 방어는 PC(플레이어 캐릭터) 상태 효과로 실체화되어 있음
-- 카드 0장 상태의 실측 DPS·EHP는 개발팀 Unity MCP 시뮬레이션으로 제공 가능 (§3 전략 참조)
-
-### 1-4. 권장 진행 방향
-- 기획팀이 **의도 명확화 선언** → 개발팀이 Unity MCP로 해당 설계가 수치적으로 성립하는지 검증
-- 구체적으로: 기획팀이 "터치 방어 없이 4마리 처리 가능 여부"의 목표 비율(예: 80% 생존)을 수치화 → 개발팀이 시뮬레이션으로 현 수치가 목표를 만족하는지 응답
-
-## 2. Q-P2 응답 — "터치 방어 메커닉 정확도"
-
-### 2-1. 기획팀 질의 요지
-1. 터치 1회 = 다음 공격 1회 피해 50% 감소?
-2. 터치 유지 중 계속 50% 감소?
-3. 쿨다운?
-
-### 2-2. 개발팀 응답 (코드 실증 기반, 미확인 항목 명시)
-
-**확인된 사실** (실제 `PCActor.cs`·`Actor.cs` 실측):
-- 터치 방어는 `eActorStatus.Defecne`(원문 오타 `Defecne`) 상태 효과로 모델링
-- `InGameInfo.Ins.Set_PCBlock` 을 통해 블록 스프라이트·상태를 설정
-- "블록(Block)" 용어와 "방어(Defense)" 용어가 **혼용**되어 있음 (현 구조의 약점)
-
-**미확인 — 정밀 코드 리뷰 필요**:
-- 50% 감소 수치의 실제 테이블 위치 (Actor·Effect·Card 중 어디에 기록?)
-- 감소 비율이 **고정값인지 카드·장비·인장 옵션에 따라 변동**하는지
-- 쿨다운 존재 여부·값
-- "1회성"인지 "지속형"인지 (상태 효과 duration 필드가 별도 관리되는지)
-
-**개발팀 차기 조치** (본 응답서 발신 후 즉시 착수 가능):
-1. `Actor.cs`·`PCActor.cs`·관련 `Effect*.cs` 정밀 리뷰하여 수치 위치 식별
-2. 기획팀 `StatusEffect` 마스터 테이블 확인
-3. Q-P2 3문항 각각에 **코드·테이블 실측 근거 포함 2차 응답서** 제출
-
-### 2-3. 본 응답의 한계
-본 응답은 **초벌 스캔 결과**이며, 50% 감소·쿨다운 확정 수치는 미확정. Q-P2는 **2차 응답서로 완결** 필요 (C23 정직 보고).
-
-## 3. 시뮬레이터 전략 업데이트 (07 문서 후속)
-
-### 3-1. 배경 변경
-- **PD님 2026-04-17 직접 지시 (#28)**: 기획팀 시뮬레이션 작업은 **Unity MCP 기반**으로 전환
-- Python 시뮬 파일은 **소실 확정 — 폐기 사안**
-- 교차 검증 축 이원화 방침 폐기 → **Unity MCP 단일 축**으로 확정
-
-### 3-2. 재설정된 시뮬레이션 전략
-
-| 항목 | 결정 |
-|------|------|
-| 시뮬레이션 실행 환경 | Unity Editor + Unity MCP (`mcp__unity-mcp__*`) |
-| 결과 취득 방법 | `execute_code`·`run_tests`·`manage_editor` 등으로 플레이 모드 제어 + 로그/결과 수집 |
-| 시뮬레이션 코드 위치 | `Assets/Script/Server/`·`Assets/Script/InGame/` 등 기존 프로젝트 내부 (별도 시뮬레이터 레포 불필요) |
-| 성능 모드 | Headless 불필요 — 기획팀 밸런싱은 시각적 피드백 포함이 유리. 배치 검증 시에만 PlayMode 자동화 |
-| 결과 저장 | `기획팀/.cache/` 또는 `공유/시뮬결과/` (기획팀 결정) — 개발팀은 실행 환경 제공까지 |
-
-### 3-3. 개발팀이 제공할 인프라 (Phase 0-C 잔여)
-1. **시뮬레이션 진입점 스크립트**: 전투만 격리 실행 가능한 `SimulationRunner.cs` 프로토타입 (PlayMode 의존 최소화)
-2. **파라미터 외부화**: 앵커 전투 시나리오(몬스터 구성·PC 상태·카드 0장 등)를 JSON/ScriptableObject 외부 입력으로 받도록 리팩토링 포인트 식별
-3. **결과 수집 포맷**: 시뮬레이션 1회 결과를 `{timestamp, scenario_id, turns, dmg_taken, survived, ...}` 구조화 JSON 출력
-4. **Unity MCP 호출 템플릿**: 기획팀장이 `Task` 또는 `/게임플레이` 에이전트 호출 시 바로 쓸 수 있는 MCP 호출 스니펫 (3종: 단일 실행 / 파라미터 스윕 / 배치 비교)
-
-**작성 예정 산출물** (본 응답서 뒤 착수):
-- `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_인프라_설계_v2.md` — 상기 4종 인프라의 구체 설계
-- 기존 `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` (이미 존재, #28 참조) 위에 **실행 인프라 단계** 추가
-
-### 3-4. 기획팀 작업 재개 조건
-- 위 3-3의 인프라 4종 중 최소 (1)·(3)·(4)가 완료되면 기획팀이 앵커 전투 시뮬레이션 작업 재개 가능
-- (2) 파라미터 외부화는 병행 진행 가능 (선택사항)
-
-## 4. 기각안 (P24)
-
-- **기각안 A: 전투 메커닉 전수 자동 리버스 엔지니어링 + 본 응답서에 통합 수록** — 작업량 막대 + 본 응답서 범위 초과. Q-P2 2차 응답서로 분리
-- **기각안 B: Python 시뮬레이터 복구 시도** — PD님 "폐기 사안" 확정(#28 비고란). 복구 시도 자체가 지시 위반
-- **기각안 C: Unity 외 3rd-party 시뮬레이터 도입 검토** — PD님 Unity MCP 단일 방향 확정. 검토 대상 아님
-- **기각안 D: Q-P1에 "의도된 설계로 추정됨" 단정 응답** — 개발팀 의사결정 권한 외. C23 위반 회피
-
-## 5. 후속 작업 · 블로커
-
-### 5-1. 개발팀 즉시 착수 항목 (본 응답서 발신 후)
-1. Q-P2 정밀 2차 응답 (코드·테이블 실측)
-2. §3-3 인프라 4종 (1)·(3)·(4) 구현
-3. Unity MCP 호출 스니펫 문서화
-
-### 5-2. 기획팀 필요 액션
-1. Q-P1에 대한 **기획 의도 선언** (의도된 설계? 개선 필요?)
-2. §3-3 시뮬레이션 결과 저장 위치 결정
-3. Q-P2 정밀 응답 수령 후 터치 방어 정책 재확인
-
-### 5-3. PM 조율 필요
-- 없음 (팀 자율 진행 가능 범위, C29-1 정합)
-
-## 부록. 변경 이력
-- **v1 (2026-04-17)**: 초판. 개발팀장 Phase 0-C Q-P 응답 + Unity MCP 전환 반영 시뮬레이터 전략 v2 초안 작성.
diff --git a/공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md b/공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md
deleted file mode 100644
index 593257e..0000000
--- a/공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md
+++ /dev/null
@@ -1,315 +0,0 @@
----
-from: 개발팀장
-to: PM
-date: 2026-04-17
-type: 보고서(초안)
-status: 진행중
-tags: [서버역할정리, 인간개발자지시서, 클라서버경계, PlayFab, 수상한잡화점]
-related: [C11, C29, C30, P13, P18, P23]
-depends_on: [PD-#2, PD-#5-B]
----
-
-# 인간 서버 개발자 업무 지시서 초안 — 서버 역할 정리
-
-> **목적**: 인간 서버 개발자가 읽고 바로 작업 착수 가능한 **서버 역할 범위·데이터 카테고리·클라/서버 처리 경계 정의서** 초안. 최종 결정은 PD님 몫이며 본 문서는 **초안 + PD 결정 안건** 제시.
->
-> **작성 방법 주석 (C23 정직성)**: 본 세션에서 `Task` 도구로 서버팀장·클라이언트팀장 서브에이전트 호출이 환경 제약으로 불가하여, 개발팀장이 **양쪽 관점을 명시적으로 구분해 단독 분석**. 섹션마다 `[서버 관점]`·`[클라 관점]` 태그로 구분. 서버팀장의 사전 업무공유체계 점검 보고(`공유/소통/개발팀→PM/2026-04-17_업무공유체계_점검_서버팀.md`)는 참조함.
-
----
-
-## 0. 전제·근거 자료
-
-### 0-1. PD님 가이드라인 (본 초안의 기본 원칙, 반드시 반영)
-1. **재화 사용 시 항상 서버 응답 필수** — 클라 단독 처리 금지
-2. **미션 클리어 판단은 클라 재량**. 단 **보상 지급 주체(서버 vs 클라)는 결정 필요**. **보상이 재화 형태가 아니면 서버 처리 어려움** 전제
-3. **랭킹 등록은 클라 정보를 서버가 그대로 저장** — 서버는 검증·계산 없이 저장만. **재화 아닌 랭킹 보상은 서버 처리 불가** 전제
-
-### 0-2. 현 수상한잡화점 실측 결과
-
-| 항목 | 실측 내용 |
-|------|----------|
-| **서버 스택** | **PlayFab** (Title API + CloudScript + Leaderboard + Profiles + Mail) |
-| **인증** | `LoginWithCustomID` (기기 기반 익명 ID) |
-| **저장 방식** | **하이브리드** — `CryptoUtil.Save`로 **로컬 파일 저장이 1차 소스**, PlayFab CloudScript는 핵심 이벤트만 (로그인 토큰·치트·인게임 시작·가이드 퀘스트·우편) |
-| **AntiCheat** | `CodeStage.AntiCheat.ObscuredTypes` (ObscuredInt/Long, RandomizeCryptoKey) — **로컬 변조 방어 목적**, 서버 검증은 아님 |
-| **CloudScript 함수 (현행)** | `ServerSave_LoginToken`, `Get_UserInfo`, `Save_CheatItem`, `Save_IngameStart`, `Save_GuideQuest`, `Get_MailList`, `Get_MailReward`, `Get_AllMail`, `Get_OtherUserInfo`, `Del_TitlePlayer` |
-| **CloudScript 주석처리 (미구현)** | `Save_StageResult` — 스테이지 완료 시 서버 저장. 현재 비활성 |
-| **랭킹** | `PlayFabProgressionAPI.GetLeaderboard` / `GetLeaderboardAroundEntity` 사용 중 (단, 등록 경로는 소스에서 미확인 — 추가 분석 필요) |
-| **인앱 결제** | `InappInfo.cs` **전체 주석처리 상태** (현재 비활성). 재활성 시 `ValidateGooglePlayPurchase` 등 PlayFab 검증 경로 복원 필요 |
-| **주요 저장 데이터 (`ServerData` 클래스)** | StageData, dic_PC, dic_PC_Awakening, Seal(인장), Equipment, dic_Item(재화/소비), dic_Card, EquipmentTrade, CatGoodsShop, Mission(일일/주간), set_PurchasedPCIDs, show_Scenarios, 출석(RewardAttandanceDay), 고양이 레벨(CatLv/CatExp) |
-
-### 0-3. 미파악·추가 분석 필요 영역 (C23 정직성)
-- **메타 시스템 SOT 미작성** — 세이브·상점·성장·시즌패스의 공식 설계 문서 부재 (PD #5-B Phase 0-C 미착수)
-- **랭킹 등록 경로** — `GetLeaderboard` 읽기는 있으나 `UpdatePlayerStatistics`나 CloudScript 등록 호출처가 소스 검색으로 확인 안 됨
-- **PlayFab 계속 사용 여부** — PD님 결정 필요 (자체 서버 전환 가능성). 본 초안은 **PlayFab 유지 + CloudScript 확장** 전제로 작성
-
----
-
-## A. 서버 관리 데이터 카테고리 (서버 SOT 후보)
-
-> **범례**: `[확정]` 현 코드 존재 + 재화성 데이터 / `[추가분석]` 현 코드에 있으나 서버 SOT 전환 검토 필요 / `[신규]` 새로 정의 필요
-
-### A-1. 재화·자산 `[확정]` — 서버 SOT 필수 (PD 가이드 1)
-
-| 도메인 | 필드 예시 | 비고 |
-|-------|---------|------|
-| **재화 인벤토리** | `dic_Item[itemid] = amount` (Dictionary) — Gold·Soul·DailyMissionPoint·WeeklyMissionPoint 등 | 사용 시 항상 서버 응답 필수 |
-| **PC(캐릭터) 보유** | `dic_PC[pcid]` — 레벨·경험치·각성 | 재화로 육성되므로 서버 SOT |
-| **장비** | `Equipment` (SD_Equipment) + `EquipmentTrade` | 장비 획득·강화·거래 |
-| **카드** | `dic_Card[cardid]` (SD_Card) | 카드 수집·업그레이드 |
-| **구매 PC ID 세트** | `set_PurchasedPCIDs` (HashSet<int>) | 현금·패키지 구매 대상 → 결제 검증 후 서버 저장 |
-
-### A-2. 진행도·달성 `[확정]`
-
-| 도메인 | 필드 예시 | 비고 |
-|-------|---------|------|
-| **스테이지 진행** | `StageData.dic_stagedata[diff].dic_ChapterData[chapter].list_StageData[].Star` | 난이도·챕터·스테이지별 별 수 |
-| **최고 도달 스테이지** | `Get_ClearMaxStageDatas()` 계산값 | 서버 저장 SOT (현재 로컬 계산) |
-| **고양이 레벨** | `CatLv`, `CatExp`, `L_CatLvTime` | 메타 성장 지표 |
-| **시나리오 시청 기록** | `show_Scenarios` (HashSet<string>) | UX — 서버 저장 권장 (기기 변경 시 재시청 방지) |
-| **미션 진행** | `Mission.dic_Mission[type]` — 일일/주간 카운트·보상 수령 여부 | 보상이 재화이므로 서버 SOT |
-| **출석** | `RewardAttandanceDay`, `AttandanceDayOfYear` | 보상이 재화이므로 서버 SOT |
-
-### A-3. 랭킹 `[추가분석]` (PD 가이드 3)
-
-| 도메인 | 현 구현 | 필요 조치 |
-|-------|--------|----------|
-| **리더보드 읽기** | `PlayFabProgressionAPI.GetLeaderboard` 사용 중 | 유지 |
-| **리더보드 등록** | 호출처 **미확인** (소스 검색 0건) | **인간 개발자가 기존 등록 경로 재구축 or 신규 설계**. PD 가이드 3에 따라 "클라 정보 그대로 저장" 방식 |
-| **리더보드 종류** | 현재 함수는 `leaderboard` 문자열 파라미터로 동적 | **리더보드 명세 SOT 필요** — 어떤 랭킹 존재? (스테이지 클리어타임? 최고 도달 스테이지? 고양이 레벨?) 기획팀 정의 필요 |
-| **랭킹 보상** | **현재 없음** | PD 가이드 3 — **재화 보상만 서버 처리 가능**. 비재화(칭호·스킨 등) 시 PD 결정 필요 |
-
-### A-4. 세이브 동기화 `[추가분석]` — **가장 중요한 결정 안건**
-
-현 구조는 **로컬 1차 + 클라우드 보조** 하이브리드. 이를 어디까지 서버 SOT화 할지가 핵심 결정:
-
-| 데이터 종류 | 현재 | 권장 방향 | 근거 |
-|-----------|------|----------|------|
-| 재화·PC·장비·카드 | 로컬 저장 (ObscuredType 난독화) | **서버 SOT** | PD 가이드 1 "재화 사용 항상 서버 응답" |
-| 스테이지 진행·별 수 | 로컬 저장 | **서버 SOT** (보상 지급 연결) | PD 가이드 2 보상 연결 |
-| 시나리오 시청 기록 | 로컬 저장 | **서버 저장** (기기 변경 복원) | UX |
-| UI 옵션·사운드 볼륨 | 로컬 저장 | **로컬 유지** | 서버 저장 불필요 |
-
-### A-5. 우편 `[확정]`
-- 현 구현: `Get_MailList`, `Get_MailReward`, `Get_AllMail` CloudScript 존재
-- 서버 SOT. 재화 보상 우편 → 서버가 수령 처리 + 인벤토리 반영 응답
-
-### A-6. 시즌·패스 `[신규]` (메타 시스템 — 추가 분석 필요)
-- **현 SOT 부재**. 기획팀 메타 시스템 SOT 착수 후 구체화
-- 예상 필드: 현 시즌 ID, 시즌 진행 XP, 패스 보유 여부, 단계별 보상 수령 상태
-- 시즌 리셋·크로스 시즌 이월은 서버 주도 결정
-
-### A-7. 상점 `[신규]` (메타 시스템 — 추가 분석 필요)
-- `CatGoodsShop`(`SD_CatGoodsShop`), `EquipmentTrade`(`SD_EquipmentTrade`) 로컬 구조 존재. **일일 리셋 로직 클라에 있음** (`CheckDailyReset`)
-- **이슈**: 상점 일일 리셋을 **클라 시간 기반**으로 하면 기기 시간 조작 취약. **서버 시간 기반 리셋 필요**
-- 현금 상점(패키지·현금 PC 구매)은 A-1의 `set_PurchasedPCIDs`와 연결
-
-### A-8. 소셜·기타 `[확정 일부]`
-- **닉네임**: `UpdateUserTitleDisplayName` (PlayFab) — 서버 SOT
-- **타 유저 정보 조회**: `Get_OtherUserInfo` (CloudScript) — 서버 SOT
-- **계정 탈퇴**: `Del_TitlePlayer` — 서버 SOT
-
----
-
-## B. 클라/서버 처리 경계 매트릭스
-
-> **적용 원칙**: PD 가이드 3종을 각 액션에 기계적 적용. 통신 시점·주체·검증 책임 명시.
-
-### B-1. 재화 관련 액션 (PD 가이드 1 적용 — 서버 응답 필수)
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 재화 사용 (예: 카드 업그레이드에 Soul 소비) | 사용 요청 전송 | **잔고 검증·차감·응답** | 요청 즉시 | 서버 거부 시 클라 롤백 |
-| 재화 획득 (드롭·보상) | 획득 이벤트 통지 | **지급 검증·적립·응답** | 이벤트 발생 즉시 | 스테이지 완료 번들로 묶어 1회 호출 가능 |
-| 재화 잔고 조회 | UI 표시 | SOT 제공 | 로그인·주요 화면 진입 | 서버 잔고가 정답. 클라 캐시 임시 |
-| 재화 구매 (현금) | 구매 플로우 실행 | **영수증 검증**(`ValidateGooglePlayPurchase`)·지급 | 영수증 수신 즉시 | InAppInfo 재활성화 필요 |
-
-### B-2. 미션·퀘스트 (PD 가이드 2 적용 — 클라 판단 + 보상 지급 주체 결정 필요)
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 미션 조건 체크 (예: 3회 출석) | **클라 자체 판단** | — | — | 클라가 카운트 누적·달성 판정 |
-| 미션 완료 통지 | 완료 신호 전송 | 달성 기록 저장 | 완료 즉시 | 단순 기록 |
-| **미션 보상 (재화)** | 수령 요청 | **지급·응답** | 요청 즉시 | B-1 "재화 획득"과 동일 |
-| **미션 보상 (비재화)** | **클라 단독 지급** (PC·카드·장비) | 지급 결과만 사후 기록 | 지급 후 통지 | **안건 PD-①** 참조 |
-
-### B-3. 스테이지 진행 (혼합)
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 인게임 시작 | 선택한 맵 전송 | **세션 등록** (`Save_IngameStart` 현 구현) | 전투 시작 시 | 중복 진입 차단·서버 시간 기준 확보 |
-| 인게임 플레이 | 전 로직 클라 주도 | 개입 없음 | — | 실시간 통신 없음 |
-| 스테이지 완료 | 결과 전송 (별 수·드롭 아이템·클리어 시간) | **재화 지급 + 진행도 갱신** | 완료 즉시 | `Save_StageResult` 복원·신규 설계 필요 |
-| 별 보상 수령 (비재화) | 클라 단독 | — | — | B-2 비재화 보상과 동일 |
-
-### B-4. 랭킹 (PD 가이드 3 적용)
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 랭킹 등록 | 점수·메타정보 계산·전송 | **검증 없이 그대로 저장** | 스테이지 완료·시즌 갱신 시 | PD 가이드 3 |
-| 내 랭킹 조회 | 요청 | `GetLeaderboardAroundEntity` 응답 | 랭킹 UI 진입 | 현 구현 있음 |
-| 상위 랭킹 조회 | 요청 | `GetLeaderboard` 응답 | 랭킹 UI 진입 | 현 구현 있음 |
-| **랭킹 보상 (재화)** | 수령 요청 | **지급·응답** | 시즌 종료 시 | B-1과 동일 |
-| **랭킹 보상 (비재화)** | ? | **서버 처리 불가** | ? | **안건 PD-②** 참조 |
-
-### B-5. 세이브·메타
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 로그인·최초 데이터 로드 | 요청 | 전체 데이터 응답 | 앱 실행 시 | 현 `Get_UserInfo` 구조 확장 |
-| 주기 세이브 | 변경분 전송 | 저장 | 주요 결정 직후 (결제·전투 완료·재화 변동) | 빈도 최소화, 이벤트 기반 |
-| 기기 변경 복원 | 로그인 ID 전송 | 동일 계정 데이터 응답 | 신규 기기 로그인 시 | 계정 연결 정책 별도 필요 |
-| 일일/주간 리셋 | 리셋 UI 표시 | **서버 시간 기반 판정·리셋 응답** | 로그인·일일 최초 접속 | 현재 클라 `DayOfYear` 비교는 취약 |
-| 시나리오 시청 기록 | 시청 후 통지 | 기록 저장 | 시청 직후 | 기기 변경 시 복원 |
-
-### B-6. 우편·소셜
-
-| 액션 | 클라 역할 | 서버 역할 | 통신 시점 | 비고 |
-|------|---------|----------|----------|------|
-| 우편 조회 | 요청 | 목록 응답 | 우편함 진입 | 현 구현 있음 |
-| 우편 수령 (재화 포함) | 수령 요청 | **지급·인벤토리 반영·응답** | 요청 즉시 | 현 구현 있음 |
-| 닉네임 변경 | 입력값 전송 | 중복 검사·저장 | 변경 시 | 현 구현 있음 |
-
----
-
-## C. 의사결정 필요 항목 (PD님 안건)
-
-### PD-① 미션·스테이지·업적 보상 지급 주체 (PD 가이드 2 연장)
-
-**안건**: 비재화 보상(장비·카드·캐릭터 등)의 지급 주체를 어떻게 할 것인가?
-
-**현 실측 제약**:
-- `dic_PC`·`dic_Card`·`Equipment` 등 비재화 자산도 **현재 ServerData 로컬 SOT에 포함**
-- PlayFab CloudScript는 재화 인벤토리 중심, 장비·카드 지급 로직 미구현
-- PD 전제: "재화 아닌 보상은 서버 처리 어려움"
-
-**안 2종**:
-1. **A안 — 클라 단독 지급 + 사후 서버 동기화** (PD 전제 그대로)
-   - 가) 클라가 보상 지급 + ServerData 로컬 갱신
-   - 나) 다음 주기 세이브에서 서버 반영
-   - 다) **리스크**: 지급 직후 앱 강제 종료 시 미반영 — 재지급/유실 판정 정책 필요
-2. **B안 — 비재화 자산도 서버 SOT 전환** (PD 전제 초과)
-   - 가) 장비·카드·PC 지급 API 신설 (`Grant_Equipment`·`Grant_Card` CloudScript)
-   - 나) 서버가 유니크 인벤토리 관리
-   - 다) **비용**: 개발 공수 + PlayFab 인벤토리 모델 재설계
-
-**개발팀장 의견**: A안 기본 + 지급 멱등성 보장용 클라 임시 저널(로컬 큐)로 유실 방지. PD 전제 정합.
-
----
-
-### PD-② 비재화 랭킹 보상 처리 방안 (PD 가이드 3 연장)
-
-**안건**: 랭킹 시즌 종료 시 비재화 보상(칭호·스킨·특수 장비)을 어떻게 지급할 것인가?
-
-**현 실측 제약**:
-- 현재 랭킹 등록 경로 미확인 + 랭킹 보상 시스템 자체 미구현
-- PD 전제: "재화 아닌 랭킹 보상은 서버 처리 불가"
-
-**안 2종**:
-1. **A안 — 재화 우편 보상만 운영** (PD 전제 그대로)
-   - 가) 시즌 종료 시 서버가 순위별 재화 우편 발송
-   - 나) 칭호·스킨 등 비재화 보상은 설계에서 제외
-   - 다) **제약**: 랭킹 동기 부여 수단 축소
-2. **B안 — 클라 단독 지급 + 서버는 "대상자 여부" 플래그만 관리**
-   - 가) 서버: 시즌 종료 시 순위 확정 → 대상자 플래그 저장 (예: `SeasonReward_S03_Tier1: true`)
-   - 나) 클라: 플래그 확인 후 로컬에서 비재화 보상 해금
-   - 다) **리스크**: 플래그 조작 시 부정 해금 — AntiCheat로 일부 방어 가능
-
-**개발팀장 의견**: B안 권장. 서버 처리 범위를 "대상자 판정"으로 한정하면 PD 전제("재화 아닌 서버 처리 불가") 정신 유지 + 랭킹 유인 확보.
-
----
-
-### PD-③ 서버 스택 유지 여부 (PlayFab vs 자체 서버)
-
-**안건**: PlayFab을 계속 사용할 것인가, 자체 서버(Node.js + MongoDB 등)로 전환할 것인가?
-
-**현 상태**: PlayFab 광범위 의존 (인증·CloudScript·Leaderboard·Profiles·Mail·IAP 검증). `PD 지시 #2`에서 서버 Critical 보안 3건 보류 중.
-
-**안 3종**:
-1. **A안 — PlayFab 유지 + CloudScript 확장** (현재 기조 유지)
-2. **B안 — PlayFab 인증·Leaderboard만 유지 + 게임 로직은 자체 서버**
-3. **C안 — 완전 자체 서버 전환**
-
-**개발팀장 의견**: 본 안건은 **인간 서버 개발자 배정 후 해당 개발자의 기술 스택 선호·경험과 함께 결정 권장**. 본 초안은 A안(PlayFab 유지) 전제로 작성되었으나, 개발자 배정 시 재검토 필요.
-
----
-
-### PD-④ 세이브 SOT 전환 범위
-
-**안건**: 현재 **로컬 1차 + 클라우드 보조** 하이브리드를 **서버 1차 SOT**로 전환할 것인가?
-
-**안 2종**:
-1. **A안 — 현 하이브리드 유지** — 최소 변경. 재화·결제만 서버 검증
-2. **B안 — 서버 1차 SOT 전환** — 로컬은 오프라인 캐시로만. 모든 변경 서버 저장
-
-**개발팀장 의견**: **B안이 원칙적으로 옳으나 수상한잡화점 현 시점에는 A안 유지 권장**. 이유: 서버 Critical 3건 보류 중 + 게임 오프라인 플레이 비중 고려. 차기 프로젝트는 B안 기반 설계 (헌법 제1원칙 목표 2 — 코어 프레임워크에 반영 권장).
-
----
-
-### PD-⑤ 일일/주간 리셋 시간 기준
-
-**안건**: 현재 `DayOfYear` 클라 시간 비교 방식을 서버 시간 기반으로 전환할 것인가?
-
-**현 이슈**: 기기 시간 조작으로 일일 출석·일일 상점 어뷰즈 가능.
-
-**개발팀장 의견**: **서버 시간 기준 전환 필수**. PD 재검토 불요 수준의 보안 기본. 서버 Critical 보안 3건 재개 시 포함 권장.
-
----
-
-## D. 인간 서버 개발자 착수 시 선행 작업 (C30·P13·P18 정합)
-
-1. **선행 Read 패키지** (서버팀장 사전 보고 서버 재개 예비 C-1 적용)
-   - 가) 본 문서
-   - 나) `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` #2 (서버 Critical 3건)
-   - 다) 현 `ServerClass.cs`·`ServerInfo.cs` 전문
-   - 라) `memory/org/feedback_*.md` 중 서버·보안 관련
-
-2. **환경 셋업**
-   - 가) PlayFab 계정·TitleId 확인 (현 코드 `Server_Live_ID`·`Server_Dev_ID` 상수 주석 처리 상태)
-   - 나) CloudScript 현 코드 dump 및 버전 관리 편입
-   - 다) Unity 클라이언트 개발 환경 (수상한잡화점 브랜치 pull)
-
-3. **설계 문서화 의무 (P18)**
-   - 가) 본 초안의 PD 결정 후 **서버 아키텍처 공식 설계 문서** 작성 (`프로젝트/수상한잡화점/서버/01_서버_아키텍처_v1.md` 신규)
-   - 나) API 계약서 작성 (`02_API_계약서_v1.md`) — 엔드포인트·파라미터·응답·에러 코드
-   - 다) CloudScript 함수 명세 (`03_CloudScript_명세_v1.md`)
-
-4. **P13 공용 인터페이스 변경 사전 공유**
-   - 가) 클라이언트팀(현 개발팀장)과 데이터 포맷 협의
-   - 나) 기획팀과 재화·미션·랭킹 밸런스 협의
-
----
-
-## E. 산출물 요약
-
-| 분류 | 건수 | 긴급도 |
-|------|------|--------|
-| A. 데이터 카테고리 | 8개 도메인 (재화·진행도·랭킹·세이브·우편·시즌·상점·소셜) | 정리 완료 |
-| B. 클라/서버 매트릭스 | 6개 액션군 × 약 25건 | 정리 완료 |
-| C. PD 결정 안건 | 5건 (보상 지급 주체·비재화 랭킹·서버 스택·SOT 범위·리셋 시간) | PD님 결정 대기 |
-| D. 선행 작업 | 4단 | 인간 개발자 배정 시 적용 |
-
----
-
-## F. 기각안 (P24·P27 개정 — 결정·설계 엔트리 필수)
-
-본 초안이 채택하지 않은 대안들:
-
-1. **"서버 처리를 최소화하고 전부 클라 주도로" 안** — PD 가이드 1(재화 서버 필수)과 충돌. 어뷰즈 방어 근거 소멸. 기각
-2. **"모든 비재화 자산을 서버 SOT로 전환" 안** — PD 전제("재화 아닌 서버 처리 어려움") 초과. 개발 공수 큼. PD-① B안으로만 옵션 제시하고 초안 본문에서는 비채택
-3. **"PlayFab 전면 폐기 + 자체 서버 전면 신규" 안** — 서버 Critical 3건 보류 상태에서 범위 확대는 리스크. PD-③에 옵션으로만 제시하고 본 초안은 PlayFab 유지 전제
-4. **"인간 개발자 배정 전 세부 API 스펙까지 확정" 안** — C9(완성도 우선) 정신이나, **배정된 개발자의 기술 선호·경험 반영이 없는 API 스펙은 재작업 리스크**. 본 초안은 원칙·경계·안건까지 정리하고 세부 스펙은 개발자 배정 후
-
----
-
-## G. PM 처리 권장
-
-1. **PD님 보고**: 본 초안 + PD-①~⑤ 5건 안건 (C29-3 목표 3 정신 — 결정 요청 최소화된 형태)
-2. **PD 결정 수령 시 후속**: 개발팀 PD 지시 로그 #2 재개 트리거 조건 명확화 (서버 Critical 3건 + 본 초안 PD 결정 연계)
-3. **인간 개발자 배정 시**: 본 초안 + D-1 선행 Read 패키지 동봉하여 온보딩
-4. **차기 프로젝트 코어 프레임워크 반영**: PD-④ B안(서버 1차 SOT), PD-⑤(서버 시간 기준)는 헌법 제1원칙 목표 2 — 차기 프로젝트 프레임워크 기본 탑재 권장
-
----
-
-**서명**: 개발팀장 (서버팀장·클라이언트팀장 Agent 호출 환경 제약으로 단독 분석, C23 정직성 준수)
-**검증 권장**: dev-auditor 모드 A 1회 + PM 교차 검토 후 PD 상신
diff --git a/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md b/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md
deleted file mode 100644
index b1a6e6e..0000000
--- a/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-type: 기술검토
-from: 개발팀장
-to: 총괄PM
-date: 2026-04-17
-related: PD지시 #28, #3, 07/08/09/10 산출물
-status: 작성완료
----
-
-# Unity MCP 기반 시뮬레이션 전환 — 기술 검토서
-
-## 0. 요약 (한 줄)
-**Unity MCP `execute_code` + EditMode 실행 경로가 결정론·유지비·기획팀 접근성 3축 모두에서 07 Headless 추출안을 우위로 대체 가능하며, 07·08·09·10 산출물은 90% 이상 재활용 가능**하다. 방향 전환을 권장한다.
-
-## 1. Unity 엔진 내 시뮬레이션 동작 기술 방안
-
-### 1.1 Unity MCP 실행 경로 4종 비교
-
-| 경로 | 메커니즘 | 결정론 | 속도 | 배치 | 기획팀 접근성 |
-|------|---------|--------|------|------|--------------|
-| **A. EditMode `execute_code`** | MCP로 C# 스니펫 직접 Eval (Editor 프로세스 내) | 높음 (엔진 루프 차단) | 매우 빠름 (씬 로드 불요) | 우수 (프로세스 상주) | 높음 (JSON in → JSON out) |
-| B. EditMode Test Runner (`run_tests`) | `[Test]` 어트리뷰트 메서드를 MCP로 실행 | 높음 | 빠름 | 중간 (테스트 단위) | 중간 |
-| C. Play Mode 자동화 | `manage_editor`로 PlayMode 진입 + 씬 실행 | 낮음 (MonoBehaviour 프레임 의존) | 느림 | 약함 | 낮음 |
-| D. Batch Mode Headless | Unity CLI `-batchmode -executeMethod` | 높음 | 중간 (프로세스 기동 비용) | 우수 | 중간 |
-
-### 1.2 권장 경로 — A (EditMode `execute_code`) 주력 + D 보조
-
-**A 선택 근거**:
-- Unity Editor가 이미 기동된 상태에서 MCP로 C# 코드를 직접 Eval → **Actor.cs 실제 클래스를 그대로 호출** 가능
-- MonoBehaviour/Coroutine 의존은 **EditMode 헬퍼**(프레임 시뮬레이터·코루틴 드라이버)로 우회. 07 Phase A의 의존성 식별(7종) 결과를 그대로 활용하여 stub 주입
-- UnityEngine.Random → `IRandomSource` DI (07 B-3 기획 그대로 유지)
-- Addressable → JSON 직접 로드(기획팀 xlsm export JSON 사용, 09·10 구조 활용)
-- **Python↔C# 이원화의 근본 해결** (두 구현 자체가 소멸, 한 구현만 유지)
-
-**D 보조 근거**: CI/야간 대량 배치(1만 회 이상 통계) 시 Editor를 점유하지 않고 별도 프로세스 구동. 동일 C# 코드가 두 경로에서 동일 결과 보장 (EditMode·BatchMode 모두 UnityEngine 엔진 루프 밖에서 동작).
-
-### 1.3 결정론 확보 설계
-1. 시드 기반 `IRandomSource` 전 경로 주입 (UnityEngine.Random 전수 치환)
-2. `Time.deltaTime`·프레임 의존 로직 → `IClock`·`ITickDriver` 주입
-3. Animator/VFX 경로는 `IBattlePresenter` null-object로 차단 (07 B-2 설계 재활용)
-4. 동일 시드 + 동일 시나리오 JSON → 비트 단위 동일 결과 검증
-
-## 2. 기존 07 착수계획 대비 평가
-
-### 2.1 Unity MCP 방향의 이점
-
-| 관점 | 07 Headless 추출 | Unity MCP 방향 |
-|------|-----------------|---------------|
-| **SOT 일치** | BattleCore 추출 → Unity와 동일 어셈블리 공유 | **Unity 프로젝트 자체가 SOT** (추출 개념 자체 불요) |
-| **Actor.cs 4,545줄 리팩터링** | 필수 (순수 도메인 분리) | **불요** (stub 7종 주입만) |
-| **유지비** | Unity 측 변경 시 BattleCore 재빌드·동기화 | 변경 즉시 반영 (동일 코드) |
-| **결정론** | netstandard2.1로 엔진 완전 분리 | EditMode 실행 시 엔진 루프 비활성 (동등) |
-| **C11 개발 관점** | 범용성 ○ / 효율성 △ (대규모 리팩터링) | 효율성 ○ / 직관성 ○ / 범용성 △ (Unity 종속) |
-
-### 2.2 단점·리스크
-
-1. **Unity Editor 기동 의존** — 시뮬 실행 시 Unity Editor가 열려 있어야 함(경로 A). MCP 서버도 연동 필요
-2. **기획팀 로컬 환경** — Unity 에디터 설치·프로젝트 열기 필요. 단, 현행 기획팀도 xlsm export → Unity 재로드 루프를 이미 수행 중이라 실질 추가 부담은 **MCP 호출 래퍼 스크립트** 수준
-3. **차기 프로젝트 재활용성 제약** — 헌법 제1원칙 목표 2(차기 프로젝트부터 자산 활용)와의 정합성. Unity MCP 방식은 **Unity 전제 위에서만** 재활용 가능하며, 비-Unity 엔진 이관 시 다시 추출 필요. 현 BurningTimes는 Unity 전제 조직이므로 수용 가능하나 **명시 필요**
-4. **대량 배치 성능** — EditMode 경로 A는 프로세스 1개 점유. 1만 회 이상 배치는 경로 D(BatchMode 병렬 프로세스) 필요
-5. **Live 디버깅 인프라 부재** — Python 시뮬의 print 기반 경량 검증 대신 Unity Console·MCP read_console 경유 필요
-
-### 2.3 기존 산출물 재활용 가능성
-
-| 문서 | 재활용률 | 비고 |
-|------|---------|------|
-| **07 시뮬레이터 이원화 해소 착수계획** | 60% | Phase A(의존성 식별 7종)·B-2(Presenter 인터페이스)·B-3(IRandomSource)·D(결과 교차 검증)는 그대로 유효. Phase B-1(도메인 추출)·Phase C(dotnet CLI)는 폐기, Unity MCP 실행 래퍼로 대체 |
-| **08 전투시스템 SOT** | 100% | 전투 공식 명문화는 시뮬 방식과 무관 |
-| **09 카드시스템 아키텍처** | 100% | 카드 효과 구조 분석 그대로 유효 |
-| **10 데이터로딩 구조** | 100% | JSON 로딩 구조 그대로 유효 (Addressable stub만 추가) |
-
-## 3. 권장 아키텍처
-
-### 3.1 실행 구조
-```
-[기획팀 시나리오 JSON]
-    │
-    ▼ (PM 단일 세션에서 MCP 호출)
-mcp__unity-mcp__execute_code
-    │  → BurningTimes.Sim.Runner.Run(json)
-    ▼
-[Unity Editor 프로세스]
-  ├─ IRandomSource(seed)
-  ├─ IClock/ITickDriver (프레임 시뮬)
-  ├─ IBattlePresenter = NullPresenter
-  ├─ ITableLoader = JsonTableLoader (기획팀 xlsm export)
-  └─ Actor/PCActor/MobActor/EffectMgr (실프로덕션 코드)
-    │
-    ▼
-[결과 JSON] → 기획팀 작업 폴더 + CSV 집계
-```
-
-### 3.2 기획팀 반복 실행 인터페이스
-
-- **입력**: `시나리오.json` (시드·덱·스테이지ID·반복 횟수)
-- **실행**: `scripts/run_sim.ps1 시나리오.json` (PM 세션에 MCP 호출 위임) 또는 Unity Editor 메뉴 `BurningTimes > Sim > Run`
-- **출력**: `결과_YYYYMMDD_HHMM.json` + `집계.csv` (HP 추이·클리어율·평균 턴 등)
-- **재실행**: 동일 시드 → 동일 결과 (결정론 검증 자동 포함)
-
-### 3.3 C11 개발 관점 충족도
-
-| 기준 | 평가 |
-|------|------|
-| 자원 효율성 | ○ — 추출 어셈블리 유지 불요, 빌드 비용 0 |
-| 코드 직관성 | ○ — 기획·개발 모두 Unity 실코드 1개 참조 |
-| 범용성 | △ — Unity 전제 내에서만 재활용. **헌법 제1원칙 목표 2 명시 필요** |
-
-## 4. 착수 계획
-
-### 4.1 재작성·신설 필요 문서
-
-| # | 문서 | 처리 |
-|---|------|------|
-| 07 | 시뮬레이터 이원화 해소 착수계획 v1 | **07_v2로 갱신** (Unity MCP 방향, Phase C/E 재구성) |
-| 11 | `11_Unity_MCP_시뮬_실행_설계_v1.md` | **신설** — `execute_code` 스니펫 템플릿·stub 7종 구현·IRandomSource DI 상세 |
-| 12 | `12_시뮬_시나리오_JSON_스키마_v1.md` | **신설** — 기획팀 입출력 계약 |
-| 08/09/10 | SOT 3종 | **유지** (변경 없음) |
-
-### 4.2 기획팀 조기 제공 가능 산출물 (단계 순서)
-
-1. **선행**: 경로 A 기술 검증 (Unity MCP + EditMode에서 Actor.cs 1건 호출 성공)
-2. **Stage 1 스모크**: 최소 시나리오(단일 전투) 실행 가능 시점 → 기획팀이 Python 시뮬 병행 검증 개시
-3. **교차 검증 완료**: 대표 스테이지 5건 Python vs Unity MCP 결과 일치 확증 → Python 시뮬 아카이브 + 기획팀 Phase 3 HOLD 해제 요건 충족
-
-### 4.3 차단 요인 (C3)
-
-1. **Unity MCP 연결 상태 의존** — 현재 세션에서 Unity Editor가 열려 있고 MCP 서버가 Stdio(port 6400) 연결된 상태 전제. 연결 끊김 시 시뮬 실행 불가. DevOps 관점에서 재연결 자동화 스크립트 필요
-2. **Actor.cs의 Unity 엔진 의존 7종** — stub 구현 난이도는 경로 A 기술 검증 단계에서만 확정 가능. ObscuredInt/Float(안티치트 라이브러리)는 Editor에서도 정상 동작하는지 실측 필요
-3. **헌법 제1원칙 목표 2 정합성** — 차기 프로젝트가 Unity 전제인지 PD님 확정 필요. 비-Unity 엔진 고려 시 본 방향 재검토
-4. **C30 준수** — `${UNITY_PROJECT_ROOT}`는 별도 git 레포이므로 시뮬 래퍼 스크립트가 Unity 프로젝트 파일을 수정하는 경우 작업 전 `git fetch && git status` 선행 필수
-
-## 5. 결론 (권장 판단)
-
-**Unity MCP 방향 전환을 권장**. 근거:
-1. 07 Headless 추출의 근본 리스크(Actor.cs 4,545줄 대규모 리팩터링)를 회피하면서 동일한 "단일 SOT" 효과 달성
-2. 유지비·결정론·기획팀 접근성 3축 모두 우위 또는 동등
-3. 기존 08/09/10 산출물 100% 재활용, 07도 60% 재활용
-
-**PD님 결정 필요 사항** (PM 경유 상신):
-1. 헌법 제1원칙 목표 2 — 차기 프로젝트 Unity 전제 확정 여부
-2. 07_v2 재작성 + 11·12 신설 착수 승인
-
-**본 검토는 검토·제안까지이며 실제 구현 착수는 PD님 방향 확정 후 진행**. 기획팀장의 병행 검토(Unity MCP 환경에서 Phase 3 밸런스 작업 실행 가능성) 결과와 교차 확인 필요.
-
----
-
-**작성**: 개발팀장 / **수신**: 총괄PM / **배포**: 본 경로 확정 시 기획팀장에게 교차 공유
diff --git a/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md b/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md
deleted file mode 100644
index c3b1e76..0000000
--- a/공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md
+++ /dev/null
@@ -1,189 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 검토보고
-subject: Unity MCP 시뮬레이션 전환 방향 — 기획 관점 검토
-priority: high
-status: 검토완료
-created: 2026-04-17
-ref: PD님 직접 지시 (2026-04-17, Unity MCP 전환), 기획팀 PD 지시 로그 #3 (Phase 3 HOLD), 개발팀 PD 지시 로그 #28, 개발팀 RPT 2026-04-16
----
-
-# Unity MCP 시뮬레이션 전환 — 기획 관점 검토
-
-## 0. 요약 (결론부터)
-
-1. **전환 방향 자체는 기획팀 관점에서 타당**. 단, "기획팀이 Unity MCP 도구를 직접 호출"하는 구조는 **비권장**. 권장 구조는 **"개발팀이 Unity MCP로 시뮬 러너·출력 규격을 구축 → 기획팀은 시드·입력 JSON을 지정하고 결과 CSV/JSON을 수령하는 CLI 혹은 MCP 래퍼 호출"**.
-2. **Phase 3 HOLD 부분 재개 가능**. 개발팀 조기 산출물 3종(전투공식 SOT v2 / JSON 스키마 문서 / BattleCore 피해 계산 단독 모듈) 중 **첫 2종이 확보되면 Day 1~3 (재개 준비·Phase 0~2 재검증 1~6번)**까지 즉시 진행 가능. Day 4 이후(성장 요소 기여도 본 측정)는 시뮬 러너 실제 동작이 필요.
-3. **Python 시뮬은 교차 검증용으로 유지**. 아카이브 금지. 본 검토 시점 `.cache/*.py`는 BurningTimesAi 레포 부재(개발팀 RPT §3 확인). 기획팀 로컬 PC 또는 이전 작업 디렉토리에 잔존 가능성 높음 — **재개 Day 1에 기획팀 로컬 스캔 + 레포 편입 여부 결정** 필요.
-4. **리스크 최대 관심사는 반복 실행 속도·결정론**. Unity Editor 재생 기반 시뮬은 수백~수천 회 반복에 부적합할 수 있음 (C3 관점 사전 경고).
-
----
-
-## 1. Phase 3에 필요한 시뮬레이션 기능 명세 (기획 요구사항)
-
-### 1-1. 필수 시나리오 유형 3종
-
-| 유형 | 용도 | 반복 횟수(기획 기준) |
-|------|------|---------------------|
-| **A. 단일 전투 노드 시뮬** | 카드 단품 기여도 측정 (#3 G1 카드 1장 DPS) | 시드 100회 × 조합 N |
-| **B. 스테이지 전구간 시뮬** | 성장 요소(#16~#21) 단일 축 변화에 따른 클리어율·평균 턴수 측정 | 시드 500~1000회 × 성장 단계 |
-| **C. 앵커 재검증 배치 시뮬** | Phase 0~2 재검증 6건 (#1~#6) 실측 | 시드 100회 (기존 Python 결과 대조용) |
-
-### 1-2. 입력값 스키마 (JSON)
-
-```
-seed           : int (결정론 보장)
-stage_id       : string (예: "stage_1")
-deck           : [card_id × 5]  # 카드 덱 구성
-growth_vars    : { awakening: int, evolution: int, equipment_set: int, ... }
-max_turns      : int (무한 루프 차단 상한)
-```
-
-### 1-3. 출력값 스키마 (JSON 1줄/시뮬 + CSV 집계)
-
-```
-clear          : bool
-turns          : int
-final_hp_ratio : float
-total_dmg      : int
-total_taken    : int
-potion_used    : int
-```
-
-**핵심 요구**: 시드 고정 시 **100% 동일 결과** (결정론). 개발팀 RPT §4.2 "UnityEngine.Random → 시드 기반 난수 전환 필수" 와 일치.
-
-### 1-4. 반복 실행 요구
-- Day 4~7 "성장 요소 기여도 본 측정"에서 **수백~수천 회**가 현실적 요구
-- Day 2~3 재검증은 시드 100회 수준으로 충분
-
----
-
-## 2. Unity MCP 환경 실행 가능성 평가 (기획 관점)
-
-### 2-1. 기획팀 직접 호출 vs 경유 실행
-
-| 경로 | 평가 | 사유 |
-|------|------|------|
-| **A. 기획팀이 `mcp__unity-mcp__*` 도구 직접 호출** | **비권장** | (1) Unity MCP 도구군은 씬·GameObject·컴포넌트 조작이 주 기능이며 배치 시뮬 러너 실행에는 `execute_code` 또는 `run_tests` 경유 필요 (2) 기획팀 에이전트(밸런스기획자·시스템기획자)가 Unity Editor API·C# 실행 컨텍스트를 직접 제어하는 것은 **학습 부담 과대**·**실수 리스크** (3) C11(개발 관점 원칙)과 C7(재미 우선 원칙)의 역할 경계 교란 |
-| **B. 개발팀이 MCP로 러너·입출력 규격 구축 → 기획팀은 "시뮬 실행 요청" JSON 제출 → 결과 CSV 수령** | **권장** | (1) 기획팀은 **입력·출력 스키마만 이해**하면 됨 (2) 개발팀이 Unity MCP로 러너를 씬/에셋으로 구성하고 한 번 안정화되면 반복 사용 (3) 기획팀 UX: "조합 N을 돌려주세요" 요청 → 결과 테이블 수령. 이는 CLI 방식과 사용성 동일 |
-| **C. PM·개발팀이 기획 요청 받아 실행 → 결과 전달** | 병행 가능 | Phase 3 초기·디버깅 단계에서 유용. 안정화 후 B로 전환 |
-
-### 2-2. 학습 부담·사용성
-
-- Unity MCP **풀 도구 학습은 불필요**. 기획팀이 알아야 할 것은 "입력 JSON 스펙 + 결과 포맷 + 실행 트리거 방법" 3가지
-- CLI(dotnet)·Unity MCP 경유 모두 기획 UX는 **유사**(입력 JSON 넣고 결과 파일 받기). 단 MCP 경유는 Unity Editor 가동 상태에 의존
-
-### 2-3. 기획팀 경로 선호
-**권장 B(개발팀 러너 구축 + 기획팀 요청 경로)**. 단 러너 실행 트리거는 (a) 개발팀 세션 경유 또는 (b) 기획팀이 단일 MCP 래퍼 도구(예: `mcp__unity-mcp__execute_code` 1개)만 호출하는 방식 중 개발팀 권고에 따름.
-
----
-
-## 3. 기존 Python 시뮬 자산 처리
-
-### 3-1. 소재 확인 (본 검토 시점 실측)
-- BurningTimesAi 레포 내 `battle_sim.py`·`full_stage_sim.py`·`stage_sim_v2.py` **부재 확인** (Grep 결과 0건, 개발팀 RPT §3 동일 결론)
-- 추정 소재: (a) 기획팀 구 로컬 작업 PC `.cache/` (b) 이전 `기획실/` 네임 디렉토리 흔적 (2026-04-16 "개발실→개발팀" 전환 이전 경로) (c) PD님 로컬
-- **Day 1 최우선 작업**: 기획팀장이 PD님께 소재 확인 요청 + 소재 파악 시 레포 `프로젝트/수상한잡화점/기획/시뮬_레거시/` 편입
-
-### 3-2. 전환 시 처리 방침 (권장)
-
-| 구분 | 처리 | 사유 |
-|------|------|------|
-| **Python 시뮬 코드 본체** | 레포 편입 후 **"레거시/교차 검증 참조"**로 유지. 아카이브·삭제 금지 | (1) Phase 3 재개 Day 1-3 Python↔Unity 교차 검증 입력값 (2) Phase 3 v1 붕괴 원인 분석 근거 (3) C6 데이터 보호 원칙 |
-| **Python 시뮬로 도출한 밸런스 수치** | 모든 수치는 **Unity 시뮬 재검증 대상**. Python 결과는 참고용으로만 사용 | Phase3 재개준비 체크리스트 v1 §6-3 "이원화 리스크" 교훈 준수 — "모든 수치는 C# 시뮬 기반으로만 산출" |
-| **재검증 범위** | Phase 0~2 앵커 시뮬 6건(#1~#6) + 카드 시너지 축 4건 + 성장 요소 6건 = **총 16건 우선 재검증** | Phase3_재개준비_체크리스트_v1.md §3-2 매핑 그대로 |
-
----
-
-## 4. Phase 3 부분 재개 가능성 평가
-
-### 4-1. 개발팀 조기 산출물 3종 대비 재개 가능 범위
-
-| 개발팀 조기 산출물 (RPT §5-2) | 기획팀 재개 가능 범위 | Phase3 체크리스트 매핑 |
-|-------------------------------|---------------------|----------------------|
-| **(1) 전투공식 SOT v2 문서** | Day 1-2·1-4 (교차 검증 리뷰·사전 산출물 재독), Day 2~3 재검증 **"설계 레벨" 검토** 가능 (실측은 불가) | Day 1~3 일부 |
-| **(2) JSON 데이터 테이블 스키마 문서** | 시뮬 입력값 정비·검증. 스테이지·몬스터·카드 데이터 구조 파악 | Day 1-3 (CLI 가이드 대체 가능) |
-| **(3) BattleCore 피해 계산 단독 모듈** | **Day 2~3 재검증 앵커 시뮬 6건 중 #1·#2 (PC DPS·TTK)** 피해 계산 단위까지는 실측 가능 | Day 2-1·2-2 |
-
-### 4-2. 재개 선행 조건 재정리
-
-| 종전 조건 (Phase3 체크리스트 §1-1) | Unity MCP 전환 반영 후 |
-|-----------------------------------|----------------------|
-| #1 Headless C# 시뮬 추출 완료 | → **Unity MCP 기반 시뮬 러너 동작 확인** (씬·러너·입출력 JSON 스키마 확정) |
-| #2 Python ↔ C# 교차 검증 | → **Python ↔ Unity 시뮬 교차 검증** (대상 동일) |
-| #3 기획팀용 CLI 가이드 | → **기획팀용 시뮬 실행 가이드** (MCP 래퍼 호출 방식 또는 개발팀 경유 요청 포맷) |
-| #4 PD님 재개 지시 | → 동일 |
-
-### 4-3. 즉시 재개 가능 작업 (조건부)
-개발팀 조기 산출물 (1)(2) 수령 시점에 Day 1 (선행 확인·사전 산출물 재독·CLI 가이드 정독 대체)·Day 2~3 일부(설계 레벨 재검증) **즉시 착수 가능**. Day 4 이후는 (3) + 반복 실행 환경 구축 완료 조건.
-
----
-
-## 5. 추가 차단 요인·리스크 (C3 사전 경고)
-
-### 5-1. 반복 실행 속도 리스크 (최대 관심사)
-
-| 리스크 | 내용 | 완화 방안 |
-|--------|------|-----------|
-| **Unity Editor 기반 시뮬의 반복 속도 병목** | Unity Editor Play Mode 1회 실행 시 씬 로딩·초기화 오버헤드 발생. Day 4~7 성장 요소 측정은 시드 500~1000회 × 성장 축 5종 × 단계 10개 = 최대 **5만 회** 반복 필요 | (a) Headless 모드 러너 권장(에디터 UI 없이 C# 도메인 코드만 실행) (b) **단일 Play Mode 세션 내에서 배치 루프 처리** (씬 로드 1회·내부 반복 N회) (c) 결과 비동기 JSON 라인 출력 |
-| **대안**: `run_tests` 기반 배치 | Unity Test Framework의 배치 러너로 수십~수백 회 반복은 현실적. 수천 회는 미지수 | Day 4 착수 전 **개발팀이 시뮬 1000회 런타임 벤치마크** 수행 후 기획팀 공유 |
-
-### 5-2. 결정론 보장 요구
-- 기획팀 Phase 3 측정은 **시드 고정 시 재현성 100%** 필수
-- 개발팀 RPT §4.2 `UnityEngine.Random → 시드 기반` 이미 식별됨. **기획팀 요구사항과 일치 확인**
-- 추가 요구: Coroutine·Time.deltaTime 기반 타이밍 요소도 **틱 기반**으로 환원 필수 (RPT §2.2 "Coroutine → 턴/틱 기반 루프로 전환" 이미 식별됨)
-
-### 5-3. 카드 효과 200종 커버리지
-
-- 개발팀 RPT §4.1 "카드 효과 200종 전수 대응 난이도 **상**"
-- **기획 관점 권장**: Phase 3 재개 범위의 **카드 빌드에 실제 사용되는 카드 효과 우선 구현**. 전수 200종이 아닌 **#3~#5 G1 카드 중심 + #16~#21 성장 요소 관련 효과**로 한정
-- 전수 커버리지는 Phase 3 종료 후 점진적 보완 트랙으로 분리
-
-### 5-4. 기타 우려
-
-| 우려 | 내용 |
-|------|------|
-| **Unity 버전·에셋 변경 시 회귀 리스크** | 개발팀 Unity 버전·패키지 업데이트 시 시뮬 결과 회귀 가능성. 기획팀이 수치를 받았는데 환경 차이로 재현 불가 | 시뮬 러너에 **Unity 버전·커밋 해시 기록** 의무화 |
-| **조직 레포 ↔ Unity 프로젝트 레포 분리 상태** | Unity 프로젝트는 `${UNITY_PROJECT_ROOT}` 별도 관리(C30). 시뮬 러너 코드·입출력 JSON 저장 위치를 명확히 해야 재현 가능 | **입력 JSON은 조직 레포, 러너 코드는 Unity 레포, 결과물은 조직 레포 재반영** 권장 |
-| **C30 준수** | Unity 프로젝트 건드리는 모든 제안은 **작업 착수 전 git 최신 상태 점검** 의무. 본 검토는 제안 단계이므로 Unity 레포 직접 수정 없음 | 실제 러너 구축 착수 시 개발팀이 C30 수행 |
-
----
-
-## 6. 기획팀 권장 재개 순서 (개발팀 협의 전제)
-
-| 순서 | 작업 | 선행 조건 |
-|------|------|-----------|
-| 1 | Python 시뮬 소재 확인 + 레포 편입 결정 | 기획팀장 단독 수행 가능 |
-| 2 | 개발팀 조기 산출물 (1)·(2) 수령 | 개발팀 작업 완료 |
-| 3 | Day 1-2·1-4 (교차 검증 리뷰·사전 산출물 재독) | 2 완료 시 |
-| 4 | Day 2~3 재검증 6건 중 설계 레벨 가능 항목 선 수행 | 3 완료 시 |
-| 5 | 조기 산출물 (3) + Unity 러너 1000회 벤치 수령 | 개발팀 작업 완료 |
-| 6 | Day 2~3 실측 재검증 완료 + Day 4 착수 여부 결정 | 5 완료 + PD님 재개 지시 |
-| 7 | Day 4~7 성장 요소 기여도 본 측정 | 6 완료 + 반복 속도 요구 충족 확인 |
-
----
-
-## 7. 본 검토의 한계 및 후속
-
-### 7-1. 본 검토가 전제한 것
-- 개발팀 RPT 2026-04-16 §1~§7 내용 (특히 Phase A 부분 완료·조기 산출물 3종 가능성)
-- Phase3_재개준비_체크리스트_v1 Day 1~15+ 로드맵
-- Unity MCP 도구군은 본 기획팀장이 직접 사용하지 않았음 — 사용성 판단은 **도구 목록·역할 기반 추정**. 실제 사용성은 개발팀 기술 검토 결과와 교차 확인 필요 (C5 미확인 태그)
-
-### 7-2. 개발팀 병렬 검토와의 접점
-- 개발팀장이 병렬로 진행 중인 "Unity Editor 내 시뮬레이션 동작 방안·권장 아키텍처" 검토와 §2-1 경로·§5-1 반복 속도·§5-2 결정론 항목에서 교차 검증 필요
-- PM이 양 검토 취합 시 §6 권장 순서를 기준 골격으로 사용 권고
-
-### 7-3. 본 검토의 결정 재량 범위 (P23)
-- 기획팀장 재량: §1 기능 명세, §3 Python 자산 처리 방침, §4 부분 재개 가능 범위 판단
-- PM 확인 필요: §2-1 권장 경로 B의 개발팀 측 수용 여부, §5-1 벤치마크 요청
-- PD님 확인 필요: Phase 3 재개 트리거 조건 재정의 (§4-2), 재개 시점 지시
-
----
-
-## 8. 변경 이력
-
-| 일자 | 작성자 | 내용 |
-|------|--------|------|
-| 2026-04-17 | 기획팀장 | Unity MCP 전환 관련 기획 검토 초안 |
diff --git a/공유/소통/완료/2026-04-17_감사보고_재량작업_일괄완료.md b/공유/소통/완료/2026-04-17_감사보고_재량작업_일괄완료.md
deleted file mode 100644
index 694160f..0000000
--- a/공유/소통/완료/2026-04-17_감사보고_재량작업_일괄완료.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-from: plan-auditor
-to: PM
-type: 감사보고
-subject: 기획팀장 재량작업 3건(#33·#34·#35) + 기획 결정 2건(#30·#31) 모드 B 주기 감사
-priority: MID
-status: 완료
-created: 2026-04-17
-related_pd_지시: 기획팀 #30·#31·#33·#34·#35
-related_commit: 06a7bb8
----
-
-# plan-auditor 모드 B 감사 보고
-
-## 1. 감사 범위
-- PD 지시 #33 REQ 템플릿, #34 에이전트 6종 기록 의무, #35 밸런싱 md 4종 변경 이력
-- 연관 #30(맥락 오류 점검)·#31(P24 기각안 필수화) 정합성 교차
-- 조직운영 대화로그·수상한잡화점 대화로그·소통 채널·PD 지시 로그 실측
-
-## 2. 실측 근거 (tool_use 입증)
-| 항목 | 결과 |
-|---|---|
-| `REQ-템플릿_밸런스수치.md` | 존재, 5923 bytes, YAML 프론트매터 7필드 이상 포함 |
-| 밸런싱 md 4종 "변경 이력 (P16 산출물 추적성)" 섹션 | 4종 전부 존재 (line 313·168·587·378) |
-| 에이전트 6종 (balance/content/level/narrative/system/ux) | 6종 전부 "기록 의무"·"plan-auditor"·"기각안 필드 필수" 키워드 각 4회 매칭 (일관 구조) |
-| 기획팀 PD 지시 로그 #33·#34·#35 | 완료 아카이브 이동 완료, 산출물 경로 실존 |
-| 조직운영 대화로그 2026-04-17 기획팀장 엔트리 | 기각안 3건 명시(P24 신규 필수화 요구 충족) |
-| 수상한잡화점 2026-04-17 대화로그 #33·#34·#35 엔트리 | **부재** (조직운영 로그에만 기록) |
-
-## 3. 분류 결과
-
-### Critical — 없음
-
-### Major — 1건
-**M1. 수상한잡화점 대화로그 누락 (P24·P27-4 SOT 경계 혼선)**
-- 현상: #33·#34·#35는 수상한잡화점 프로젝트 산출물(REQ·밸런싱 md) 영향이 직접적이나 `공유/대화로그/수상한잡화점/2026-04-17.md`에 기획팀장 3건 일괄 엔트리가 없음. 조직운영 로그에만 기록.
-- 영향: 프로젝트별 대화로그로 차기 프로젝트 참고 자료를 추출할 때 수상한잡화점 파일에 기획팀 변경 맥락 누락 → 목표 2 원칙 B 인사이트 소실 위험.
-- 정정 방안: `공유/대화로그/수상한잡화점/2026-04-17.md`에 1건 append (요지·이유·산출물·상태·기각안 3종 요약, 조직운영 엔트리 교차 참조).
-
-### Minor — 1건
-**m1. REQ 템플릿 "관련PD지시" 필드는 선택이나, 템플릿 본문에 "기각안 필드 예시 값" 미제공**
-- P24 개정 직후 신설이므로 차기 REQ 작성자가 공란 혼선 위험.
-- 정정 방안: 템플릿 "기각안" 섹션에 예시 1행 추가(선택적 권고).
-
-### Improvement — 2건
-**I1. 밸런싱 md 변경 이력 "기각안" 컬럼 부재**
-- 현재 포맷: 일시/변경자/변경 필드/이전값→이후값/재미 근거/관련 PD 지시#. P24 필수화가 결정·설계 엔트리 범위로 밸런스 수치 변경도 해당. 컬럼 1개 추가 권고.
-
-**I2. 기획팀장 2026-04-17_업무공유체계_점검_기획팀.md 안건 1이 P24 개정으로 종결되었는데, 소통 파일 status가 "완료"로 이동·표기되었는지 미확인**
-- PM이 `공유/소통/완료/` 이동 운영 원칙(C29-4) 확인 필요.
-
-## 4. 규칙 준수 스코어
-| 규칙 | 준수 | 비고 |
-|---|---|---|
-| C5 정직성 | O | 기각안 3종 명시(기획팀장 엔트리) |
-| C6 데이터 보호 | O (해당 없음 — 백업 대상 xlsm 변경 없음) | — |
-| C7 재미 우선 | O | 변경 이력 "재미 근거" 필드 표준화 |
-| C13·C27·C29-4 | O | PD 지시 로그 활성→아카이브 이동 완료 |
-| P16 추적성 | O | 4종 테이블 신설 |
-| P17 배타 배치 | 해당 없음 | — |
-| P18 설계 문서화 | O | 참조된 문서 전부 실존 |
-| **P24 기각안 필수** | **부분 O** | 조직운영 엔트리 충족, 수상한잡화점 엔트리 부재(M1) |
-| P27-2 호출 프롬프트 3요소 | 해당 없음 (기획팀장이 Agent 재호출 불가) | — |
-| P27-4 SOT 경계 | 부분 O | 프로젝트 축 누락(M1) |
-
-## 5. PM 요청 조치
-1. M1 즉시 시정 — `공유/대화로그/수상한잡화점/2026-04-17.md` 기획팀장 3건 일괄 엔트리 append (PM 재량 처리 권고)
-2. I1 검토 후 밸런싱 md 4종 변경 이력 포맷에 "기각안" 컬럼 추가 여부 결정 (기획팀장에게 차기 위임)
-3. I2 `공유/소통/` 완료 이동 운영 일괄 점검 (pm-auditor 감사 C1과 동일 패턴 — 중복 Major 방지)
-
-## 6. 노하우 축적 (차기 프로젝트 참고)
-- **기획 결정의 기각안은 조직운영 로그에 집중되는 경향** — 수상한잡화점 프로젝트 로그에도 동시 기록이 필요 (P27-4 양방향 SOT 유지)
-- **밸런싱 md 변경 이력 테이블은 인라인 기록이 누락 방지에 효과적** — 기획팀장 기각안 3(인라인 유지) 타당성 실증
-- **전문 에이전트 6종의 공통 지침은 SKILL.md 참조형 + 영역 특화 인라인 혼합**이 최적(C14-4 vs 체감 준수율 균형) — 기획팀장 기각안 2 타당성 실증
diff --git a/공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md b/공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md
deleted file mode 100644
index 6697152..0000000
--- a/공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md
+++ /dev/null
@@ -1,390 +0,0 @@
----
-from: pm-auditor
-to: 총괄PM
-type: 감사보고
-subject: 팀 업무 공유·기록 체계 전수 점검 (모드 C — 팀 기록 품질)
-priority: high
-status: 작성완료
-created: 2026-04-17
-ref: P26, C13, C29-4, C27, PD님 직접 지시(팀 기록 정합성 점검), pm-auditor 신설 계기(#28 Unity MCP 전환 반영 실패)
----
-
-# 팀 업무 공유·기록 체계 전수 감사 (2026-04-17)
-
-## 0. 요약 (한 줄)
-**개발팀 PD 지시 로그 활성 항목의 산출물 경로 다수가 존재하지 않으며(2026-04-16 디렉터리 재구조 시 경로 미갱신), `공유/소통/완료/` 이동 운영이 전면 방치(13건 전수 미이동)되어, PM이 아무리 실측해도 팀 기록만으로는 진실에 도달할 수 없는 구조적 위험이 확인됨.** Critical 2건·Major 3건·Minor 3건·Improvement 2건을 발견했으며, 본인 즉시 정정 범위와 팀·PM 협의 범위를 분리해 권고한다.
-
----
-
-## 1. 감사 범위·방법
-
-### 수행 모드
-**모드 C — 특정 주제 집중 감사** (PD님 직접 지시)
-- 주제: 개발팀·기획팀 업무 공유·기록 체계 전수 점검
-- 배경: PM 측 방어(P26·C31)만으로는 "팀 기록이 부실하면 PM 실측이 무의미"라는 구조적 허점 잔존
-- 감사 범위 5축 (지시사항 준수): (1) PD 지시 로그 무결성 (2) 대화로그 P24 준수 (3) 소통 채널 운영 (4) 팀 간 정합성 (5) 팀 보조 기록
-
-### 수행 방법 (C23 실측 의무)
-- Read·Glob·Grep·Bash(ls/cat)로 근거 확보
-- 각 산출물 경로 실제 존재 여부 파일시스템 직접 조회
-- inbox_scan.sh 스크립트 실행 결과 기준
-- 미확인 항목은 "확인 안 됨" 태그 명시
-
-### 감사 대상 파일 (실측 완료)
-- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` (28,217 bytes)
-- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` (8,794 bytes)
-- `공유/대화로그/조직운영/2026-04-17.md` (10,890 bytes)
-- `공유/대화로그/수상한잡화점/2026-04-17.md` (2,052 bytes)
-- `공유/소통/` 전 경로 (21개 md)
-- `공유/소통/개발팀→PM/2026-04-16_업무현황_개발실.md`
-- `공유/소통/기획팀→PM/2026-04-16_업무현황_기획실.md`
-- `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`
-- `공유/소통/기획팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`
-
----
-
-## 2. 5축 전수 결과
-
-### 축 1. PD 지시 로그 무결성
-
-#### 1-A. 활성 지시 산출물 경로 실존 검증
-
-**개발팀 활성 지시 4건 중 3건 경로 오류 발견**
-
-| # | 로그 기재 경로 | 실존 여부 | 실제 경로 |
-|---|---------------|---------|---------|
-| **#28** | `공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션..._지원.md` | ✅ 실존 | 동일 |
-| **#28** | `공유/소통/개발팀→PM/2026-04-16_RPT_시뮬레이션_대응_현황보고.md` | ✅ 실존 | 동일 |
-| **#28** | `공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` | ✅ 실존 | 동일 |
-| **#1** | `개발팀/프로젝트_숙지/수상한잡화점/06_신규코어_설계안_v1.md` | ❌ **부재** | `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md` |
-| **#1** | `개발팀/코어_설계/01_아키텍처_개요_v1.md` | ❌ **부재** | **전체 누락** (이관 흔적 없음) |
-| **#1** | `개발팀/코어_설계/02_수상한잡화점_추출대상_v1.md` | ❌ **부재** | **전체 누락** (이관 흔적 없음) |
-| **#1** | `개발팀/코어_설계/_skeleton/` | ❌ **부재** | **디렉터리 자체 없음** |
-| **#1** | `D:/BurningTimes/BT.Framework/` 구현체 | ⚠️ 확인 안 됨 | 레포 외부 경로로 본 감사 범위 외 |
-| **#2** | `개발팀/프로젝트_숙지/수상한잡화점/05_서버연동_현황_v1.md` | ❌ **부재** | `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md` |
-| **#5** | `코어코드/BT.Framework/Runtime/Core/**` | ✅ 실존 | 동일 |
-| **#5** | `프로젝트/수상한잡화점/개발/08·09·10_*.md` | ✅ 실존 | 동일 |
-
-**기획팀 활성 지시 1건 — 전건 실존**
-
-| # | 로그 기재 경로 | 실존 여부 |
-|---|---------------|---------|
-| #3 | `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md` | ✅ |
-| #3 | `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` | ✅ |
-| #3 | `공유/소통/기획팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md` | ✅ |
-
-**분석**:
-- 개발팀 로그가 2026-04-16 대규모 디렉터리 재구조(프로젝트 루트 신설, `개발팀/프로젝트_숙지/` → `프로젝트/수상한잡화점/개발/` 이관) 당시 **경로를 갱신하지 않음**
-- `개발팀/코어_설계/01·02·_skeleton/`는 현재 레포 내 흔적 없음 — 삭제된 것인지, `코어코드/BT.Framework/`로 흡수된 것인지 기록상 불명
-- PM이 #1 산출물을 실측하려 해도 **기재 경로를 그대로 신뢰하면 "부재"**로 잘못 판정할 수 있음
-
-#### 1-B. 비고란 최신성 (실종 패턴 점검)
-
-**#28 비고란** — PD님 Unity MCP 전환 지시(2026-04-17) 반영:
-> "2026-04-17 PD님 직접 지시로 Unity MCP 기반 시뮬레이션 방향으로 전환(커밋 db64310)"
-
-**평가**: ✅ 반영됨. 단, **지시 요지 본문**과 **산출물 경로**에도 새 방향이 반영되어 있어 정합. 과거 #28 보고 실패 패턴(비고 1줄만 있고 본문은 구버전) 재발 없음.
-
-**#1 비고란** — OI-2 승인·Tier 1 진행 반영 ✅
-**#2 비고란** — 보류 사유·재개 트리거 명시 ✅
-**#5 비고란** — "시뮬레이션 트랙 Unity MCP 전환(2026-04-17)" 최근 반영 ✅
-
-**분석**: 비고란 최신성은 전반적으로 양호. 경로 오류(1-A)가 더 심각한 실종 패턴.
-
-#### 1-C. 완료 아카이브 2분할 구조
-
-- 개발팀 활성 4건, 아카이브 18건 — 구조 정상
-- 기획팀 활성 1건, 아카이브 26건 — 구조 정상
-- 최근 커밋 `9fd4221`에서 활성 지시 전수 조사를 수행하여 4건 아카이브 이동한 흔적 확인 — **본 정리 절차 자체는 작동 중**
-
----
-
-### 축 2. 대화로그 P24 준수
-
-#### 2-A. 프로젝트별 당일 파일 존재
-
-| 프로젝트 | 2026-04-17 파일 | 2026-04-16 파일 |
-|---------|----------------|----------------|
-| 수상한잡화점 | ✅ (2,052 bytes, 2건 엔트리) | ✅ |
-| 코어프레임워크 | ❌ **당일 파일 없음** | ✅ (1,555 bytes) |
-| 조직운영 | ✅ (10,890 bytes, 14건 엔트리) | ✅ (6,747 bytes) |
-
-**분석**:
-- 코어프레임워크 당일(2026-04-17) 작업이 없었으면 파일 부재는 정상이나, **OI-2 결정(2026-04-17 #1 비고에 반영)** 같이 관련 결정이 있었다면 코어프레임워크 엔트리 누락 의심
-- 단, OI-2 결정은 과거 승인의 확인 보고 성격이고 새 작업 엔트리가 별도로 필요한 수준은 아닐 수 있음 — **판단 유보, PM 확인 권고**
-
-#### 2-B. 고정 3종 태그 준수
-
-`grep -c "#PD지시\|#자율작업\|#결정\|#이슈"` 샘플 검증:
-- `조직운영/2026-04-17.md` — 14건 엔트리 전원 `#PD지시` or `#결정` or `#이슈` + `#PM` + `#완료` 3종 태그 준수 ✅
-- `수상한잡화점/2026-04-17.md` — 2건 엔트리 `#PD지시` + `#개발`/`#기획` + `#완료` 3종 준수 ✅
-
-**분석**: 태그 체계 양호.
-
-#### 2-C. 주요 작업 커밋 대비 대화로그 누락
-
-커밋 10건(2026-04-17 분)과 대화로그 엔트리 교차:
-
-| 커밋 | 대화로그 반영 |
-|------|-------------|
-| `4e424f2` P26·pm-auditor | ✅ |
-| `7d8646a` settings 승인 팝업 옵션4 | ✅ |
-| `af4c863` C31 + P21·P24 개정 | ✅ |
-| `324d82a` Live 더미 정리 | ⚠️ (#Live경로이전 엔트리로 간접 커버) |
-| `9de797f` Live 경로 이전 | ✅ (#Live경로이전) |
-| `5d89c54` Live 더미 정리 | ⚠️ 동일 |
-| `40e79c8` PreToolUse hook | ✅ (#PreToolUse자동승인) |
-| `9fd4221` 활성 지시 전수 조사 | ✅ (#활성지시전수조사) |
-| `dba8ad8` Live 더미 정리 | ⚠️ |
-| `db64310` C30 + 시뮬 MCP 전환 | ✅ (#C30신설) |
-
-**분석**: Live 더미 정리 커밋(chore 성격 3건)은 대화로그에 별도 엔트리 없음 — P24 판단 기준 "의미 있는 작업"에서 chore 정리는 제외 가능하므로 **위반 아님**. 주요 의사결정은 전부 반영.
-
----
-
-### 축 3. 소통 채널 운영
-
-#### 3-A. `공유/소통/완료/` 이동 운영 상태
-
-**실측**: `ls 공유/소통/완료/` → **빈 폴더** (파일 0건)
-
-**미처리 13건 (inbox_scan.sh 결과)**:
-
-| # | 파일 | 실제 상태 | status 필드 | 완료 이동 필요 여부 |
-|---|------|---------|-----------|-----------------|
-| 1 | `개발팀→PM/2026-04-16_RPT_시뮬레이션_대응_현황보고.md` | #28에 인용 + 07 Headless 방향 구버전 | 보고 | ⚠️ Unity MCP 전환 후속 보고서(`2026-04-17_...기술검토`)가 대체. **완료 이동 또는 deprecated 표시 필요** |
-| 2 | `개발팀→PM/2026-04-16_업무현황_개발실.md` | 2026-04-16 스냅샷, 이후 #17·#12 완료됨에도 "차단"으로 기재 | 대기 | ⚠️ **시점 구버전 — 완료 이동 권고 (2026-04-17 최신 현황은 PD 지시 로그에서 직접 추출 가능)** |
-| 3 | `개발팀→PM/2026-04-16_코어코드_git통합_점검_개발팀.md` | 개발팀 #26(완료 아카이브 이동)의 산출물 | 대기 | ✅ **완료 이동 필요** (상위 지시 이미 완료) |
-| 4 | `개발팀→PM/2026-04-16_콘솔병렬실행_기술검토_개발팀.md` | 검토 문서 — 프론트매터 `from:` 없음 | 대기 | ⚠️ 발신자 필드 누락 + 처리 여부 불명확 |
-| 5 | `개발팀→PM/2026-04-16_프로세스고도화_개선안_개발실.md` | 개발팀 완료 아카이브 #25(프로세스 고도화)의 산출물 — 이미 PM 통합 6건 구현(`6768969`) | 대기 | ✅ **완료 이동 필요** |
-| 6 | `개발팀→PM/2026-04-16_하이브리드구조_개발실의견.md` | 개발팀 완료 아카이브 #26(하이브리드)의 산출물 — 이미 PM 보완 5건 구현(`c14348b`) | 대기 | ✅ **완료 이동 필요** |
-| 7 | `개발팀→PM/2026-04-16_핫리로드대안_기술검토_개발팀.md` | 기술 검토 — 프론트매터 `from:` 없음 | 대기 | ⚠️ 발신자 필드 누락 |
-| 8 | `개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` | #28 최신 보고서 | 작성완료 | ✅ **진행중 — 유지** (status: 작성완료가 미처리로 잡히는 분류 오류) |
-| 9 | `기획팀→PM/2026-04-16_업무현황_기획실.md` | 기획팀 현황 스냅샷 | 대기 | ⚠️ 구버전 현황 — 완료 이동 권고 |
-| 10 | `기획팀→PM/2026-04-16_유니티프로젝트_점검_기획팀.md` | 기획팀 완료 아카이브 #27의 산출물 | 대기 | ✅ **완료 이동 필요** |
-| 11 | `기획팀→PM/2026-04-16_프로세스고도화_개선안_기획실.md` | 기획팀 완료 아카이브 #25의 산출물 | 대기 | ✅ **완료 이동 필요** |
-| 12 | `기획팀→PM/2026-04-16_하이브리드구조_기획실의견.md` | 기획팀 완료 아카이브 #26의 산출물 | 대기 | ✅ **완료 이동 필요** |
-| 13 | `기획팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md` | 기획팀 #3 관련 최신 검토서 | 검토완료 | ✅ **진행중 — 유지** |
-
-**집계**:
-- **완료 이동 필요 (상위 지시 완료 확정)**: 6건 (#3·#5·#6·#10·#11·#12)
-- **유지 (진행중 최신)**: 2건 (#8·#13)
-- **구버전 스냅샷 (이동 권고)**: 3건 (#1·#2·#9)
-- **발신자/제목 누락 수리 필요**: 2건 (#4·#7)
-
-#### 3-B. 발신자·제목 누락
-
-**inbox_scan.sh 기준 "제목 없음" 7건** (발신자 없는 것 2건 포함):
-- `2026-04-16_업무현황_개발실.md` — 프론트매터에 `subject:` 없고 `from: 개발팀장` 있음 (inbox_scan 기준 제목 없음)
-- `2026-04-16_업무현황_기획실.md` — 동일 구조
-- `2026-04-16_콘솔병렬실행_기술검토_개발팀.md` — 프론트매터에 `from:`·`subject:` 모두 없음 (inbox_scan "발신자 없음 + 제목 없음")
-- `2026-04-16_핫리로드대안_기술검토_개발팀.md` — 동일
-- `2026-04-16_유니티프로젝트_점검_기획팀.md` — `subject:` 없음
-- `2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` — 프론트매터에 `subject:` 없음, 본문 §1 제목만 있음
-- `2026-04-16_업무현황_기획실.md` (중복 집계) — 동일
-
-**분석**: inbox_scan.sh가 frontmatter `subject:` 필드를 파싱하므로, **팀이 보고서 생성 시 `subject:` 필드를 누락**하는 패턴이 반복됨. 프론트매터 표준 템플릿 합의가 필요.
-
----
-
-### 축 4. 팀 간 정합성
-
-#### 4-A. 개발팀 #28 ↔ 기획팀 #3 정합
-
-| 항목 | 개발팀 #28 기재 | 기획팀 #3 기재 | 정합 |
-|------|---------------|--------------|------|
-| Unity MCP 전환 | "2026-04-17 PD님 직접 지시로 Unity MCP 기반 시뮬레이션 방향으로 전환" | "2026-04-17 PD님 지시로 시뮬 방향이 Headless C# CLI → Unity MCP 기반으로 전환" | ✅ |
-| Python 시뮬 처리 | "Python 시뮬 파일 소실 확정 — 폐기 사안, 교차 검증 축 단일(Unity MCP)로 확정" | "Python 시뮬 파일 구 기획실 삭제로 소실 확정 — 폐기 사안으로 기록" | ✅ |
-| Phase 3 재개 | "Phase 3 재개 로드맵은 PD님 별도 논의 예정" | "Phase 3 재개 로드맵은 PD님 별도 논의 예정" | ✅ |
-
-**분석**: 양 팀 PD 지시 로그 비고란 완전 일치 — PM 수동 갱신(커밋 흔적 추정)으로 이미 정합 확보. 양호.
-
-#### 4-B. 개발팀 업무현황 보고서 ↔ #28 Unity MCP 반영
-
-개발팀→PM/2026-04-16_업무현황_개발실.md는 2026-04-16 작성이고 Unity MCP 전환은 2026-04-17 발생이므로 **반영 기대 불가**. 단, **본 문서가 "대기" status로 미처리 잔류 중**이라는 것이 문제. 2026-04-17 관점에서 해당 보고서는 이미 사실관계 여러 건이 구버전:
-- #17·#12 "차단됨"으로 기재 → 실제로는 완료 아카이브 이동
-- OI-2 승인 대기로 기재 → 실제로는 2026-04-16 승인 완료(#27 산출물에 명시)
-
-즉 **PM이 본 보고서를 그대로 수용하면 구버전 현황을 사실로 오인**할 위험.
-
-#### 4-C. 기획팀 업무현황 보고서 ↔ Unity MCP 대응
-
-기획팀→PM/2026-04-16_업무현황_기획실.md도 동일 구조. Unity MCP 반영은 후속 `2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`로 분리 발행되어 정보 자체는 조직 내 존재하나, **업무현황 보고서 자체는 status: 대기 + 2026-04-16 스냅샷 그대로 잔류**.
-
----
-
-### 축 5. 팀 보조 기록
-
-#### 5-A. CONTEXT_BRIEF.md 상태
-
-- `개발팀/CONTEXT_BRIEF.md` — ❌ **부재**
-- `기획팀/CONTEXT_BRIEF.md` — ❌ **부재**
-- `scripts/context_brief.sh` 존재 여부 — 확인 안 됨 (본 감사 범위 외, 경량 조회만)
-
-**분석**: 2026-04-16 단일 세션 전환(C24) 후 부서별 CONTEXT_BRIEF 개념 자체가 실효됐을 가능성 높음. 현재 PM 단일 세션이 SKILL.md 자동 주입으로 코어룰 로드 + SessionStart hook으로 맥락 복원. **실효 판정 ✅** (위반 아님).
-
-단, **파일 부재 사실 자체가 로그·문서 어디에도 명문화되지 않음** — 나중 혼동 예방 차원에서 `scripts/context_brief.sh`도 함께 정리 필요한지 확인 권고.
-
----
-
-## 3. 분류별 위반 목록
-
-### Critical (헌법급 위반)
-
-**C1. 개발팀 PD 지시 로그 #1·#2 산출물 경로 부재 — C5·C13 위반**
-- **규칙**: C5 정직성 + C13 PD 지시 트래킹·공유 의무
-- **내용**: #1 산출물 경로 3건(`개발팀/프로젝트_숙지/수상한잡화점/06_...`·`개발팀/코어_설계/01_...`·`02_...`·`_skeleton/`) 및 #2 산출물 경로 1건(`개발팀/프로젝트_숙지/수상한잡화점/05_...`)이 **파일시스템에 존재하지 않음**. PM이 해당 경로로 실측 시도하면 "부재"로 판정되어 "산출물 소실"로 오인할 수 있음
-- **영향**: 로그의 "산출물 경로" 필드 신뢰성 붕괴. C31 자기검증 체크리스트의 "실측 근거" 확보 자체가 거짓으로 통과됨
-- **추정 원인**: 2026-04-16 디렉터리 재구조(`프로젝트/` 루트 신설) 당시 PD 지시 로그의 과거 경로 필드 미갱신. 특히 `개발팀/코어_설계/` 자산은 `코어코드/BT.Framework/`로 흡수된 것으로 추정되나 이관 기록 불명
-- **권고 조치**:
-  - PM 자체 정정 가능 범위: `06·05` 경로를 `프로젝트/수상한잡화점/개발/`로 재기재 (단순 경로 수정)
-  - 팀 확인 필요 범위: `개발팀/코어_설계/01·02·_skeleton/`이 실제로 `코어코드/BT.Framework/`로 흡수된 것인지, 일부 문서(01·02)가 소실된 것인지 **개발팀장 1회 확인 필요**
-
-### Critical (헌법급 위반)
-
-**C2. `공유/소통/완료/` 이동 운영 전면 방치 — C29-4 위반**
-- **규칙**: C29-4 업무 완료 후 동기화·공유 의무, "소통 채널 `status: 완료` 갱신 + `공유/소통/완료/`로 이동"
-- **내용**: `공유/소통/완료/` 폴더 **전수 비어 있음** (0건). 본 감사에서 확인한 바 완료 이동 대상 최소 6건 발견(#3·#5·#6·#10·#11·#12 소통 파일)
-- **영향**: inbox_scan.sh가 **완료 지시의 후속 파일까지 모두 "미처리"로 잡아** 매번 13건 잔류 경보. PM이 매 세션 동일 경보를 받으면서도 실제 신규/완료 구분이 안 되어 **경보 피로(alert fatigue)** 발생
-- **권고 조치**:
-  - PM 자체 정정 가능 범위: 위 6건 git mv로 `공유/소통/완료/` 이동 (C29-4 명시 운영 절차에 따름)
-  - 팀 협의 범위: 업무현황 보고서(2·9번)·구버전 RPT(1번)는 "deprecated 표시 후 완료 이동" vs "보존" 방침 PM 판단 필요
-
-### Major (프로젝트 규칙 위반 or 반복 Minor)
-
-**M1. 소통 파일 프론트매터 `subject:` 필드 누락 패턴 반복**
-- **규칙**: 소통 표준 프론트매터 운영 (inbox_scan.sh 의존성)
-- **내용**: 7개 파일에서 `subject:` 누락 (콘솔병렬실행 기술검토·핫리로드대안 기술검토는 `from:`도 누락)
-- **영향**: PM의 inbox 스캔 시 "제목 없음"으로만 표시되어 내용 파악 전 열어봐야 함 → 토큰·시간 낭비 (C14 위반 유형)
-- **권고 조치**: 소통 파일 프론트매터 표준 템플릿 명문화 + 팀 교육 (PM → 양 팀장 공지 1회)
-
-**M2. 개발팀 2026-04-16 업무현황 보고서 — 구버전 사실관계 잔류**
-- **규칙**: C5 정직성 (보고 시점의 사실과 일치)
-- **내용**: #17·#12 "차단됨"으로 기재했으나 실제로는 이미 완료 아카이브 이동, OI-2 "결정 대기"로 기재했으나 실제로는 PD님 승인 완료(`7187ac6`)
-- **영향**: PM이 해당 보고서를 레퍼런스로 다시 사용할 경우 구버전 정보 오염. 본 위반은 #28 보고 실패 사건과 동일 구조 — "최근 상황 반영 실패"
-- **권고 조치**: 보고서 말미에 "본 보고서는 2026-04-16 시점 스냅샷이며 이후 갱신은 PD 지시 로그 직접 참조" 주석 추가 + 완료 이동
-
-**M3. 기획팀 2026-04-16 업무현황 보고서 — Unity MCP 전환 미반영 + 구버전 잔류**
-- **규칙**: C13·C29-4
-- **내용**: 기획팀 업무현황 보고서가 2026-04-16 스냅샷 그대로 status: 대기 잔류. Unity MCP 관련 정보는 2026-04-17 별도 검토서에 담겼으나, **업무현황 보고서 자체는 갱신·이동되지 않음**
-- **권고 조치**: M2와 동일 조치
-
-### Minor (1회성 경미 누락)
-
-**m1. RPT 2026-04-16 — 방향 대체 후 이동·deprecated 표시 누락**
-- 2026-04-16 RPT가 07 Headless 방향으로 작성됐으나 2026-04-17 기술검토서가 대체. 구 RPT는 잔류 중이나 deprecated 태그 없음
-- 권고: 본문 상단에 "2026-04-17 Unity MCP 전환으로 본 보고서 일부 효력 상실. 최신은 `2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` 참조" 주석 1줄 추가
-
-**m2. 대화로그 INDEX.md 최신성**
-- "최근 로그" 섹션이 "2026-04-16: 조직운영 (조직 대개편, P24 신설)"에서 멈춰 있음. 2026-04-17 다량 엔트리 미반영
-- 권고: INDEX.md 수동 갱신 (자동 갱신 스크립트 없으면 간단 수동)
-
-**m3. 코어프레임워크 대화로그 2026-04-17 엔트리 부재**
-- OI-2 승인 확인·Tier 1 진행 관련 코어프레임워크 엔트리가 당일 0건
-- 권고: 활동이 실제로 없었으면 현 상태 유지, 있었는데 누락이면 소급 작성 — **PM 판단 필요**
-
-### Improvement (개선 여지)
-
-**I1. PD 지시 로그 경로 필드에 **자동 실존 검증** 도입 검토**
-- 현재는 로그 편집자가 수동으로 경로 기재. 2026-04-16 디렉터리 재구조처럼 대규모 변경 시 경로 오류가 누적
-- 제안: `scripts/verify_log_paths.sh` 신설 — 활성 지시 테이블의 모든 경로에 ls 실행, 부재 항목 리포트. SessionStart hook 또는 주기 감사 대상
-- 근거: C31 자기검증이 "실측 근거"를 요구하는데 로그 경로 자체가 거짓이면 검증 자체가 무의미
-
-**I2. 소통 프론트매터 표준 템플릿 명문화**
-- `공유/소통/README.md`에 프론트매터 필수 필드(`from`·`to`·`type`·`status`·`subject`·`created`) 명시
-- 템플릿 스니펫 제공
-- 근거: M1 반복 패턴의 근본 조치
-
----
-
-## 4. 구조적 개선 권고
-
-### 권고 1. 경로 실존 자동 감사 (I1 구체화)
-
-**목적**: 본 감사에서 발견한 "경로 부재" 패턴(Critical C1)을 구조적으로 차단
-
-**구현 개요**:
-```
-scripts/verify_log_paths.sh
-- PD 지시 로그 활성 테이블 파싱
-- 각 "산출물 경로" 셀의 경로 리스트 추출 (콤마·백틱 구분)
-- 파일·디렉터리 ls로 실존 확인
-- 부재 항목을 stderr로 리포트
-- exit code: 부재 항목 있으면 1
-```
-
-**통합 지점**:
-- P21 세션 갱신 5-A 단계에 "경로 실존 확인" 하위 단계 추가
-- 또는 SessionStart hook에서 실행
-
-**비용**: 스크립트 1개 + P21 절차 1줄 추가. 고정비 증가 없음 (on-demand 실행).
-
-### 권고 2. 소통 프론트매터 표준 템플릿 (I2 구체화)
-
-**목적**: M1 반복 패턴 차단
-
-**구현 개요**:
-- `공유/소통/README.md`에 필수 필드 명시 + 스니펫 추가
-- inbox_scan.sh가 누락 파일을 "WARN:" prefix로 강조 표시
-
-**비용**: README 개정 + 스크립트 1줄 추가.
-
-### 권고 3. `완료/` 이동 자동화 검토
-
-**목적**: Critical C2 구조 차단
-
-**옵션**:
-- 옵션 a: 소통 파일 프론트매터 `status: 완료`로 갱신되면 **다음 세션 시작 시 자동 git mv** (SessionStart hook)
-- 옵션 b: 수동 이동 의무 + 주기 감사에서 누락 확인 (현행 유지 + PM 재량)
-
-**권고**: 옵션 b에서 시작하여 미이동 3회 반복 시 옵션 a로 격상. 자동화는 되돌리기 쉬운 액션이지만 판단 오류 시 완료 아닌 파일까지 이동될 위험이 있어 보수적 접근.
-
----
-
-## 5. 즉시 정정 권고 (PM 자체 재량)
-
-다음은 본 감사자가 자체 Edit로 정정 가능하나, **팀 영역 자체 정정은 팀장 권한**(C29)이므로 PM이 판단하여 진행 권고:
-
-1. **개발팀 PD 지시 로그 #1·#2 경로 즉시 수정** (Critical C1)
-   - `개발팀/프로젝트_숙지/수상한잡화점/06_신규코어_설계안_v1.md` → `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md`
-   - `개발팀/프로젝트_숙지/수상한잡화점/05_서버연동_현황_v1.md` → `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md`
-   - `개발팀/코어_설계/01·02·_skeleton/` → **개발팀장 1회 확인 요청** (흡수/소실 판정)
-
-2. **`공유/소통/완료/` 6건 이동** (Critical C2)
-   - #3·#5·#6·#10·#11·#12 (상위 지시 완료 확정된 후속 파일)
-
-3. **구버전 업무현황 보고서 2건 처리** (Major M2·M3)
-   - 말미 주석 추가 + 완료 이동 권고
-
-4. **RPT 2026-04-16 deprecated 주석** (Minor m1)
-
-5. **INDEX.md 최신 로그 섹션 갱신** (Minor m2)
-
-**C29 준수**: 본 감사자는 PM에게 "어떻게 할까요?" 되묻지 않음. 위 조치는 **명백히 PM 재량 범위**이며, 본 보고서를 수령한 PM이 판단·실행.
-
----
-
-## 6. 감사자 자기검증 (C23·C31 준수)
-
-- [x] 본 보고서의 모든 주장은 Read·Glob·ls로 확인한 실측 근거
-- [x] 미확인 항목("확인 안 됨" 태그): BT.Framework 외부 레포, scripts/context_brief.sh 실제 동작
-- [x] 승인 표현 추정 없음 — 본 감사는 PD님 지시 범위 내(팀 기록 체계 점검)
-- [x] C19-2 되돌리기 어려운 액션 없음 — 본 감사는 "권고 보고서 발행"이 최종 산출물
-- [x] 허위 보고·역할 연기 없음 — 본 감사자는 general-purpose 역할 주입 상태이며 본 사실을 상단에 명시
-- [x] 용어 일관: "개발팀·기획팀" (구 "개발실·기획실" 표현 혼용 없음)
-- [x] 넘버링 C25-1 위계: 1순위 숫자·2순위 `#-A/B/C` 사용 — 규칙 준수
-
----
-
-## 7. 본 감사의 한계 (정직 고지)
-
-- **외부 레포**: `D:/BurningTimes/BT.Framework/` 구현체는 본 감사 범위 외. 개발팀 #1 기재 "Tier 1 기반 Core 4종 완료"는 `코어코드/BT.Framework/` 내 파일 실존으로만 간접 확인
-- **과거 경위**: `개발팀/코어_설계/01·02·_skeleton/`의 삭제·이관 경위는 본 감사자가 git log 전수 추적하지 못함 — 개발팀장 확인 필요
-- **업무 누락 감지 한계**: 본 감사는 "기록된 내용의 정합성"을 점검. "기록되지 않은 업무"는 본 감사 방법론으로 감지 불가 — 이 부분은 PM 직접 대면 확인 영역
-
----
-
-**감사자**: pm-auditor (general-purpose 역할 주입)
-**보고 경로**: `공유/소통/pm-auditor→PM/2026-04-17_감사보고_팀기록체계_전수점검.md`
-**수령자**: 총괄PM
-**조치 기한**: C15 준수 — 기한 표기 없음. PM 우선순위 판단
diff --git a/공유/소통/완료/2026-04-17_서버_작업_참고자료.md b/공유/소통/완료/2026-04-17_서버_작업_참고자료.md
deleted file mode 100644
index 3679689..0000000
--- a/공유/소통/완료/2026-04-17_서버_작업_참고자료.md
+++ /dev/null
@@ -1,186 +0,0 @@
----
-from: 개발팀장
-to: PM (DOCX 변환 → 외부 서버 작업자)
-date: 2026-04-17
-type: 참고자료
-status: 완료
-version: v1.2
-audience: 외부 서버 작업자
-tags: [서버참고자료, 수상한잡화점, 서버경계, 데이터SOT]
----
-
-# 서버 작업 참고 자료 — 수상한잡화점
-
-> **본 문서의 성격**: 수상한잡화점 프로젝트 서버 파트 작업자에게 전달하는 **참고 자료**입니다. 공식 업무 지시서가 아니라, 현 프로젝트의 서버 현황·데이터 카테고리·클라-서버 경계 원칙·참고용 API 샘플을 정리한 배경 문서입니다. 세부 구현 방향과 서버 스택 선택은 작업자가 판단·제안할 수 있는 열린 영역으로 남겨져 있습니다.
-> **권장 완독 시간**: 5~7분
-
----
-
-## 0. 1페이지 개요
-
-- **프로젝트**: 수상한잡화점 (로그라이크 RPG, Unity 2022+, 모바일)
-- **현 서버 스택**: PlayFab 사용 중 (Title API·CloudScript·Leaderboard·Profiles·Mail). 유지·전환·하이브리드 여부는 열린 결정 사항
-- **서버 담당 영역 (현 프로젝트 범위)**: ① 재화 SOT 서버 검증·지급 ② 랭킹 저장·조회 ③ 우편·IAP 영수증 검증 ④ 서버 시간 기준 리셋
-- **어뷰징 판정 책임**: 클라이언트 주도. 서버는 판정 결과(플래그) 수신 시 지급 거부 처리만 수행 (섹션 5 참조)
-- **현 상태**: 서버 Critical 보안 3건 보류 중, 서버 작업자 합류 시점 재개 예정
-
-**프로젝트 기본 원칙 4종 (확정, 변경 불가)**
-1. 모든 보상은 **재화 형태로 지급**. 비재화 보상(칭호·스킨·장비·PC 등) 없음 → 모든 보상은 서버 검증·지급 대상
-2. 재화 사용·획득은 **항상 서버 응답 필수**. 클라 단독 처리 금지
-3. 미션 클리어 판단은 **클라 재량**. 서버는 보상 지급 시점에만 개입
-4. 랭킹 등록은 **클라 정보를 서버가 그대로 저장**
-
----
-
-## 1. 현 서버 스택 현황 (PlayFab 사용 중)
-
-| 구성 요소 | 현 상태 | 비고 |
-|----------|--------|------|
-| PlayFab 인증·UserData·TitleData | 사용 중 | - |
-| CloudScript | 사용 중 (`Get_UserInfo`·`Get_MailList`·`Get_MailReward` 등) | 함수 dump 후 버전 관리 편입 필요 |
-| Leaderboard (Progression API) | 읽기 경로 존재 (`GetLeaderboard`·`GetLeaderboardAroundEntity`) | 등록 경로 미확인 → 재설계 필요 |
-| Mail | `Get_AllMail` CloudScript 존재 | 재화 보상 우편 처리 |
-| `Save_StageResult` (스테이지 완료 처리) | 비활성 상태 (주석 처리) | 복원·신규 설계 필요 |
-| `InappInfo.cs` (IAP 영수증) | 비활성 상태 | 재활성화 + `ValidateGooglePlayPurchase` 연결 |
-| `Server_Live_ID`·`Server_Dev_ID` | 코드 주석 처리 상태 | 인수인계 시 복구 |
-
-> **스택 선택은 열린 사안**: 본 섹션은 "현재 이렇게 구현되어 있다"는 현황 기술입니다. PlayFab 유지, 하이브리드 구성, 별도 스택으로의 전환 등 서버 아키텍처 방향은 작업자 판단·제안 가능 영역입니다.
-
----
-
-## 2. 서버 관리 데이터 카테고리 (8개 도메인)
-
-| # | 도메인 | 주요 필드 | SOT 방향 |
-|---|--------|----------|---------|
-| 1 | 재화 인벤토리 | `dic_Item[itemid] = amount` (Gold·Soul 등) | 서버 SOT 필수 |
-| 2 | PC(캐릭터) 보유 | `dic_PC[pcid]` — 레벨·경험치·각성 | 서버 SOT |
-| 3 | 장비·카드 | `Equipment`·`dic_Card[cardid]` | 서버 SOT |
-| 4 | 스테이지 진행 | `StageData.dic_stagedata[diff][chapter][stageid].Star` | 서버 SOT (보상 지급 연결) |
-| 5 | 미션·출석 | `Mission.dic_Mission[type]`·`RewardAttandanceDay` | 서버 SOT (재화 보상) |
-| 6 | 랭킹 | Leaderboard (현 PlayFab) | 서버 저장 |
-| 7 | 우편 | CloudScript 기반 (현 PlayFab) | 서버 SOT |
-| 8 | 시즌·패스 | 신규 정의 필요 | 기획 SOT 정의 후 구체화 |
-
----
-
-## 3. 클라/서버 경계 — 핵심 원칙 3
-
-1. **재화 사용·획득 → 서버 응답 필수**
-   - 클라: 사용·획득 요청 전송 / 서버: 잔고 검증·차감·응답 (또는 지급·응답)
-   - 서버 거부 시 클라 롤백
-
-2. **미션 클리어 → 클라 판단, 재화 보상은 서버 지급**
-   - 클라: 조건 체크·카운트 누적·달성 판정 / 서버: 보상 수령 요청 수신 시 지급
-
-3. **랭킹 등록 → 클라가 계산한 값을 서버가 그대로 저장**
-   - 클라: 점수·메타정보 계산·전송 / 서버: Leaderboard 저장
-
-**보상 통일**: 모든 보상은 재화 단위. 비재화 보상(칭호·스킨·장비·PC 등) 없음.
-
----
-
-## 4. 핵심 API 참고 예시
-
-> 아래는 **현 구현 참고용** 샘플입니다. 서버 스택·구현 방식이 변경될 경우 인터페이스는 재설계 대상입니다. "반드시 이 방식을 유지해야 한다"는 의미가 아닙니다.
-
-### 4-1. `Save_StageResult` (복원 필요 — 현 PlayFab CloudScript 기준 샘플)
-
-**유형**: CloudScript 함수 / **호출 권한**: Client (LoginSession 유효)
-**역할**: 스테이지 클리어 결과를 저장하고 재화를 지급
-
-**요청 파라미터** (예시):
-```json
-{
-  "difficulty": 2,
-  "chapter": 3,
-  "stageId": 47,
-  "starCount": 3,
-  "clearTimeMs": 125000,
-  "droppedItems": [{"itemId": 101, "amount": 500}],
-  "is_abuse_flag": false
-}
-```
-
-**응답 (성공)**:
-```json
-{
-  "status": "ok",
-  "grantedRewards": [{"itemId": 101, "amount": 500}],
-  "newStar": 3,
-  "stageProgress": {"maxStageId": 47}
-}
-```
-
-**응답 (실패)**:
-| 에러 코드 | 조건 | 클라 처리 |
-|----------|------|----------|
-| `AbuseFlagged` | `is_abuse_flag: true` 수신 | 지급 거부, 기록 저장 (섹션 5) |
-| `SessionInvalid` | 세션 없음·만료 | 재로그인 유도 |
-| `StageLocked` | 해당 스테이지 미해금 | 경로 이탈 처리 |
-
-### 4-2. `Grant_MissionReward`
-- 미션 보상 재화 지급. 클라가 미션 완료 판정 후 수령 요청 시 서버가 지급·응답
-- `is_abuse_flag` 동일 수용 (클라가 자체 판정 시 true 동봉 가능)
-
-### 4-3. 랭킹 등록 경로 (신규 설계 필요)
-- 현 코드에서 등록 호출처 미확인 → 재구축 필요. 엔드포인트명 예: `Submit_RankingEntry`
-- 클라 전송 점수·메타정보 그대로 Leaderboard 저장. 세부는 설계 단계에서 확정
-
----
-
-## 5. 참고: 어뷰징 방지 체계 (클라 주도, 서버 최소 역할)
-
-> **프로젝트 정책**: 어뷰징 **판정은 클라이언트 책임**. 서버는 판정 결과(플래그)만 받아 처리합니다.
-
-**판정 책임**: 클라이언트 (경계값 보관·수치 검증 전부 클라에서 수행)
-
-**서버 역할 (최소)**:
-- 재화 지급 요청 페이로드에 **`is_abuse_flag: true`** 가 포함된 경우, 해당 지급을 **거부**하고 **기록** 저장
-- 플래그 저장 위치: 현 스택 기준 Profile 필드 또는 별도 모니터링 엔드포인트 (구현 단계에서 결정)
-- 관리자 알림 채널(Slack Webhook·이메일 등) 연계는 구현 단계에서 결정
-
-**서버가 하지 않는 것 (프로젝트 정책)**:
-- 경계값 테이블 보관 (Title Data 등에 적재 불필요)
-- 경계값과 클라 전송 수치 비교 검증
-- 어뷰징 판정 로직 자체
-
-**협의 범위**: 클라이언트팀 구현 시 필요하면 서버 작업자와 **플래그 인터페이스 스펙**만 협의합니다 (판정 로직 자체는 협의 대상 아님).
-
----
-
-## 6. 환경 셋업 체크리스트
-
-- [ ] 현 서버 스택(PlayFab) 접근 권한 수령 (Title ID 인수·Game Manager 대시보드·CloudScript revision 접근) — 현 스택 유지 시
-- [ ] 현 배포 CloudScript 전문 dump → 버전 관리 편입 (경로 후보: `코어코드/수상한잡화점_서버/`)
-- [ ] Unity 프로젝트 clone + `git fetch origin && git pull`
-- [ ] Unity 에디터 설치 (프로젝트 버전 기준)
-- [ ] 현 PlayFab SDK 연동 확인 (빌드·실행 1회 성공)
-- [ ] IDE (VS Code 또는 JetBrains Rider) + Node.js (CloudScript 로컬 테스트용)
-
----
-
-## 7. 용어집
-
-| 용어 | 뜻 |
-|------|---|
-| PlayFab | Microsoft BaaS. 본 프로젝트가 현재 사용 중인 서버 스택 |
-| CloudScript | PlayFab 서버 사이드 JavaScript 실행 환경 |
-| Title Data | PlayFab Title 단위 공용 설정 저장소 |
-| UserData | PlayFab 유저별 서버 저장소 |
-| Leaderboard | PlayFab 순위표 서비스 (Progression API) |
-| ObscuredType | `CodeStage.AntiCheat` 로컬 변조 방어 타입. 서버 검증 대체재는 아님 |
-| ServerData | 수상한잡화점 프로젝트 클래스(`ServerClass.cs`). 유저 데이터 SOT 로컬 표현 |
-| SOT | Source of Truth. 데이터의 단일 진실 근원 |
-| AntiCheat | 어뷰징·치트 방지 체계. 본 프로젝트는 클라 판정 + 서버는 플래그 수신 시 지급 거부 |
-
----
-
-## 8. 변경 이력
-
-| 일시 | 버전 | 요지 |
-|------|------|------|
-| 2026-04-17 | v1.2 | 외부 서버 작업자용 참고 자료로 중립화 — PlayFab 전제 제거(현 사용 중 상태로만 기술), 조직 내부 프로세스 표현 제거, "지시서" → "참고 자료"로 성격 재정의 |
-
----
-
-**용도**: 서버 작업자 합류 시 본 자료를 출발점으로 사용. 세부 서버 스택 선택, 아키텍처 방향, API 스펙 확정은 배정 후 설계 단계에서 진행.
diff --git a/공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md b/공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md
deleted file mode 100644
index 0ba9d98..0000000
--- a/공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-from: 개발팀장
-to: PM (DOCX 변환 → 인간 서버 개발자)
-date: 2026-04-17
-type: 지시서
-status: 완료
-version: v1.1
-tags: [서버개발자지시서, 요약판, 서버역할, 클라서버경계, PlayFab, 수상한잡화점]
-related: [C8, C11, C28, C29, C30, P13, P14, P18]
-depends_on: [PD-#2, PD-#30, PD-#신규_어뷰징책임_재확정]
-supersedes: v1.0 (2026-04-17 동일 경로, PD님 어뷰징 책임 재확정·요약판 재작성 지시로 대체)
----
-
-# 인간 서버 개발자 업무 지시서 (요약판 v1.1)
-
-> **대상**: 인간 서버 개발자 (수상한잡화점 서버 파트 합류 예정)
-> **읽는 시간**: 5~7분 완독 가능 수준으로 축약
-> **v1.1 변경 요지**: (1) 어뷰징 판정 **클라 100% 책임**으로 확정 (PD님 재결정). 서버는 클라가 보내준 **판정 플래그만 수신**하여 지급 거부. (2) v1.0 446줄을 요약판으로 전면 재작성. 세부 원문은 초안 `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md` 참조.
-
----
-
-## 0. 1페이지 개요
-
-- **프로젝트**: 수상한잡화점 (로그라이크 RPG, Unity 2022+, 모바일)
-- **서버 스택**: PlayFab 기반 (Title API·CloudScript·Leaderboard·Profiles·Mail) — 본 지시서는 PlayFab 유지 전제
-- **역할 범위**: ① 재화 SOT 서버 검증·지급 ② 랭킹 저장·조회 ③ 우편·IAP 영수증 검증 ④ 서버 시간 기준 리셋
-- **어뷰징 판정**: **클라 100% 책임**. 서버는 판정 결과(플래그) 수신 시 지급 거부만 수행 (섹션 5 참조)
-- **현 상태**: 서버 Critical 3건 보류 중(PD 지시 로그 #2), 인간 개발자 배정 후 재개
-
-**기본 원칙 4종 (PD 확정, 변경 불가)**
-1. 모든 보상은 **재화 형태로 지급**. 비재화 보상 없음 → 모든 보상은 서버 검증·지급 대상
-2. 재화 사용·획득은 **항상 서버 응답 필수**. 클라 단독 처리 금지
-3. 미션 클리어 판단은 **클라 재량**. 서버는 보상 지급 시점에만 개입
-4. 랭킹 등록은 **클라 정보를 서버가 그대로 저장**
-
----
-
-## 1. 서버 스택 현황
-
-| 구성 요소 | 현 상태 | 비고 |
-|----------|--------|------|
-| PlayFab 인증·UserData·TitleData | 사용 중 | 유지 |
-| CloudScript | 사용 중 (`Get_UserInfo`·`Get_MailList`·`Get_MailReward` 등) | 함수 dump 후 git 편입 필요 |
-| Leaderboard (Progression API) | 읽기 경로 존재 (`GetLeaderboard`·`GetLeaderboardAroundEntity`) | 등록 경로 미확인 → 재설계 필요 |
-| Mail | `Get_AllMail` CloudScript 존재 | 재화 보상 우편 처리 |
-| `Save_StageResult` (스테이지 완료 처리) | **비활성 상태** (주석 처리) | 복원·신규 설계 필요 |
-| `InappInfo.cs` (IAP 영수증) | **비활성 상태** | 재활성화 + `ValidateGooglePlayPurchase` 연결 |
-| `Server_Live_ID`·`Server_Dev_ID` | 코드 주석 처리 상태 | 인수인계 시 복구 |
-
----
-
-## 2. 서버 관리 데이터 카테고리
-
-| # | 도메인 | 주요 필드 | SOT 방향 |
-|---|--------|----------|---------|
-| 1 | 재화 인벤토리 | `dic_Item[itemid] = amount` (Gold·Soul 등) | 서버 SOT 필수 |
-| 2 | PC(캐릭터) 보유 | `dic_PC[pcid]` — 레벨·경험치·각성 | 서버 SOT |
-| 3 | 장비·카드 | `Equipment`·`dic_Card[cardid]` | 서버 SOT |
-| 4 | 스테이지 진행 | `StageData.dic_stagedata[diff][chapter][stageid].Star` | 서버 SOT (보상 지급 연결) |
-| 5 | 미션·출석 | `Mission.dic_Mission[type]`·`RewardAttandanceDay` | 서버 SOT (재화 보상) |
-| 6 | 랭킹 | PlayFab Leaderboard | 서버 저장 |
-| 7 | 우편 | CloudScript 기반 | 서버 SOT |
-| 8 | 시즌·패스 | 신규 정의 필요 | 기획팀 SOT 정의 후 구체화 |
-
----
-
-## 3. 클라/서버 경계 — 핵심 원칙 3
-
-1. **재화 사용·획득 → 서버 응답 필수**
-   - 클라: 사용·획득 요청 전송 / 서버: 잔고 검증·차감·응답 (또는 지급·응답)
-   - 서버 거부 시 클라 롤백
-
-2. **미션 클리어 → 클라 판단, 재화 보상은 서버 지급**
-   - 클라: 조건 체크·카운트 누적·달성 판정 / 서버: 보상 수령 요청 수신 시 지급
-
-3. **랭킹 등록 → 클라가 계산한 값을 서버가 그대로 저장**
-   - 클라: 점수·메타정보 계산·전송 / 서버: Leaderboard 저장
-
-**보상 통일**: 모든 보상은 재화 단위. 비재화 보상(칭호·스킨·장비·PC 등) 없음.
-
----
-
-## 4. 핵심 API 3종
-
-### 4-1. `Save_StageResult` (복원 필수 — 샘플)
-
-**유형**: CloudScript 함수 / **호출 권한**: Client (LoginSession 유효)
-**역할**: 스테이지 클리어 결과를 저장하고 재화를 지급
-
-**요청 파라미터** (예시):
-```json
-{
-  "difficulty": 2,
-  "chapter": 3,
-  "stageId": 47,
-  "starCount": 3,
-  "clearTimeMs": 125000,
-  "droppedItems": [{"itemId": 101, "amount": 500}],
-  "is_abuse_flag": false
-}
-```
-
-**응답 (성공)**:
-```json
-{
-  "status": "ok",
-  "grantedRewards": [{"itemId": 101, "amount": 500}],
-  "newStar": 3,
-  "stageProgress": {"maxStageId": 47}
-}
-```
-
-**응답 (실패)**:
-| 에러 코드 | 조건 | 클라 처리 |
-|----------|------|----------|
-| `AbuseFlagged` | `is_abuse_flag: true` 수신 | 지급 거부, 기록 저장 (섹션 5) |
-| `SessionInvalid` | `Save_IngameStart` 세션 없음·만료 | 재로그인 유도 |
-| `StageLocked` | 해당 스테이지 미해금 | 경로 이탈 처리 |
-
-### 4-2. `Grant_MissionReward`
-- 미션 보상 재화 지급. 클라가 미션 완료 판정 후 수령 요청 시 서버가 지급·응답.
-- `is_abuse_flag` 동일 수용 (클라가 자체 판정 시 true 동봉 가능).
-
-### 4-3. 랭킹 등록 경로 (신규 설계)
-- 현 코드에서 등록 호출처 미확인 → 인간 개발자가 재구축. 엔드포인트명 예: `Submit_RankingEntry`.
-- 클라 전송 점수·메타정보 그대로 Leaderboard 저장. 세부는 D-3 설계 문서에서 확정.
-
----
-
-## 5. 참고: 어뷰징 방지 체계 (클라 주도, 서버 최소 역할)
-
-> **2026-04-17 PD님 직접 재확정**: 어뷰징 **판정은 클라이언트 100% 책임**. 서버는 판정 결과(플래그)만 받아 처리.
-
-**판정 책임**: 클라이언트 (경계값 보관·수치 검증 전부 클라에서 수행)
-
-**서버 역할 (최소)**:
-- 재화 지급 요청 페이로드에 **`is_abuse_flag: true`** 가 포함된 경우, 해당 지급을 **거부**하고 **기록** 저장
-- 플래그 저장 위치: PlayFab Profile 필드 또는 별도 모니터링 엔드포인트 (배정 시 결정)
-- 관리자 알림 채널(Slack Webhook·이메일 등) 연계는 배정 후 결정
-
-**서버가 하지 않는 것**:
-- 경계값 테이블 보관 (Title Data 적재 불필요)
-- 경계값과 클라 전송 수치 비교 검증
-- 어뷰징 판정 로직 자체
-
-**세부 설계**: 기획팀 `공유/소통/기획팀→PM/2026-04-17_어뷰징판정_솔루션_기획서_v1.md` 참조 (클라이언트팀 구현 시 필요 시 서버 개발자와 **플래그 인터페이스만** 협의).
-
----
-
-## 6. 환경 셋업 체크리스트
-
-- [ ] PlayFab 계정 접근 권한 수령 (Title ID 인수·Game Manager 대시보드·CloudScript revision 접근)
-- [ ] 현 배포 CloudScript 전문 dump → git 편입 (경로는 PM 협의, 후보: `코어코드/수상한잡화점_서버/`)
-- [ ] Unity 프로젝트 clone + `git fetch origin && git pull` (C30 준수)
-- [ ] Unity 에디터 설치 (프로젝트 버전 기준)
-- [ ] PlayFab SDK 연동 확인 (빌드·실행 1회 성공)
-- [ ] IDE (VS Code 또는 JetBrains Rider) + Node.js (CloudScript 로컬 테스트용)
-
----
-
-## 7. 결정 대기 2건 (PD·PM 후속)
-
-1. **PD-③ 서버 스택 유지 여부** — PlayFab 유지(A안, 본 지시서 전제) vs 하이브리드(B안) vs 자체 서버(C안). 인간 개발자 배정 후 기술 선호·경험 수렴하여 PM 경유 PD님 보고.
-2. **PD-④ 세이브 SOT 전환 범위** — 현 "로컬 1차 + 클라우드 보조" 하이브리드 유지(A안) vs 서버 1차 SOT(B안). 개발팀 의견: 수상한잡화점 현 시점 A안, 차기 프로젝트 B안 (코어 프레임워크 반영).
-
-**PD-⑤ 일일/주간 리셋 시간 기준** — 서버 시간 기준 전환 확정 (개발팀 재량, [필수 작업]).
-
----
-
-## 8. 용어집
-
-| 용어 | 뜻 |
-|------|---|
-| PlayFab | Microsoft BaaS. 본 프로젝트 서버 스택 기반 |
-| CloudScript | PlayFab 서버 사이드 JavaScript 실행 환경 |
-| Title Data | PlayFab Title 단위 공용 설정 저장소 |
-| UserData | PlayFab 유저별 서버 저장소 |
-| Leaderboard | PlayFab 순위표 서비스 (Progression API) |
-| ObscuredType | `CodeStage.AntiCheat` 로컬 변조 방어 타입. 서버 검증 대체재 아님 |
-| ServerData | 수상한잡화점 프로젝트 클래스(`ServerClass.cs`). 유저 데이터 SOT 로컬 표현 |
-| SOT | Source of Truth. 데이터의 단일 진실 근원 |
-| AntiCheat | 어뷰징·치트 방지 체계. 본 프로젝트는 **클라 판정** + **서버는 플래그 수신 시 지급 거부** |
-
----
-
-## 9. 기각안 (P24·P27 결정·설계 엔트리 필수)
-
-1. **"어뷰징 경계값 서버 보관·검증" 안 (v1.0 B-7 구조)** — PD님 재결정으로 기각. 서버가 경계값 테이블을 Title Data에 적재하고 수치 검증하는 구조는 폐기. 어뷰징은 **클라 주도 작업**이며 서버 개발자 작업 스펙 아님.
-2. **"상세 설계 전부 포함한 장문 지시서" 안 (v1.0 446줄)** — 인간 개발자 파악 시간 낭비. 요약판 원칙으로 전환 (PD님 지시).
-3. **"비재화 보상 유지" 안** — PD 확정(모든 보상=재화)으로 전제 소멸. 기각.
-4. **"PlayFab 전면 폐기 + 자체 서버 전면 신규" 안** — 현 보류 항목 해소 전 범위 확대 리스크. PD-③ 옵션으로만 제시.
-5. **"배정 전 세부 API 스펙 전량 확정" 안** — 배정된 개발자의 기술 선호 반영 없는 스펙은 재작업 리스크. 본 지시서는 원칙·경계·샘플 1건까지, 세부는 배정 후 설계 문서에서 확정.
-
----
-
-## 10. 변경 이력
-
-| 일시 | 버전 | 작성자 | 요지 |
-|------|------|--------|------|
-| 2026-04-17 | v1.0 | 개발팀장 | 최종본 초판 (B-7 어뷰징 방지 서버 연계 포함). PD님 어뷰징 책임 재확정으로 대체됨 |
-| 2026-04-17 | **v1.1** | 개발팀장 | **요약판 재작성**: (1) 어뷰징 판정 클라 100% 책임 확정 반영 — 서버는 플래그 수신만 (섹션 5). (2) 446줄 → 150줄 이내 축약. (3) 샘플 API 1건 유지, 템플릿·매트릭스 세부는 D-3 설계 문서로 이관 |
-
----
-
-**서명**: 개발팀장 (인간 서버 개발자 배정 시 본 지시서를 출발점으로 사용)
-**DOCX 변환**: PM이 `anthropic-skills:docx`로 재생성
-**후속 트래킹**: 개발팀 PD 지시 로그 #30 v1.1 갱신 + #신규 "어뷰징 책임 재확정·요약판 재작성" 등록·완료
diff --git a/공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md b/공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md
deleted file mode 100644
index 5a69bc2..0000000
--- a/공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md
+++ /dev/null
@@ -1,378 +0,0 @@
----
-type: 기획서
-project: 수상한잡화점
-version: v1
-status: 진행중
-author: 기획팀장
-date: 2026-04-17
-scope: 어뷰징 판정 프레임워크 (설계 원칙 + 스키마 + 예시 틀)
-related_rules: [C7, C11, C13, C23, P23]
-related_docs:
-  - 공유/소통/기획팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md
-  - 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
----
-
-# 어뷰징 판정 솔루션 기획서 v1
-
-## 요지
-
-스테이지 클리어 보상·랭킹 등록·일일 미션에서 클라가 전송하는 데이터를 서버가 **"시뮬레이터 산정 이론 상한 경계값"** 기반으로 검증하여, 경계를 초과하는 요청을 어뷰저로 판정·차단한다. 기획팀은 경계값 도출 방법론과 테이블 스키마를 제공하고, 서버는 검증 로직을 탑재한다. 실제 수치는 Unity MCP 시뮬 가동 결과로 채워진다(본 기획서는 틀만 제공).
-
-**재미 관점(C7)**: 어뷰징이 방치되면 랭킹·미션의 도전 가치가 붕괴되고, 정상 플레이어의 성취감이 훼손된다. 본 솔루션의 목표는 "정직한 플레이어의 재미를 보호"하는 것이지 선의의 실력자를 잡는 것이 아니다. 따라서 경계값은 **이론 상한에 안전 마진을 더한 값**으로 설정하여 false positive를 최소화한다.
-
----
-
-## A. 문제 정의
-
-### A-1. 전제
-- 모든 보상(미션·스테이지·랭킹) = 재화 형태로 지급 확정 (2026-04-17 PD님 결정)
-- 스테이지 클리어·랭킹 등록에서 서버는 클라 전송 데이터를 기반으로 보상을 산정/기록한다
-- 클라를 무조건 신뢰하면 메모리 조작·패킷 위변조를 통한 재화 부당 획득이 가능하다
-
-### A-2. 어뷰징 공격 벡터
-
-| 벡터 ID | 대상 액션 | 조작 포인트 | 파급 위험 |
-|--------|----------|-----------|---------|
-| **AV-1** | 스테이지 클리어 완료 패킷 | 클리어타임 단축 (예: 0초·음수) | 시간 가속 보상 파밍 |
-| **AV-2** | 스테이지 클리어 완료 패킷 | 획득 재화량 조작 (상한 초과) | 재화 무한 생성 |
-| **AV-3** | 스테이지 클리어 완료 패킷 | 별(★) 개수 조작 (3/3 고정) | 미달성 보상 부당 수령 |
-| **AV-4** | 스테이지 클리어 완료 패킷 | 소모 자원 0 보고 (물약·쉴드·HP) | ★조건 달성 위조 (C6 포션절제, N2 피격제한 등) |
-| **AV-5** | 랭킹 등록 패킷 | 점수값 조작 (이론 상한 초과) | 랭킹 1위 탈취 |
-| **AV-6** | 랭킹 등록 패킷 | 연관 메타값 조작 (사용 카드·편성 등 검증 소재) | 검증 회피 |
-| **AV-7** | 일일 미션 카운트 | 카운트 중복 전송·상한 초과 | 일일 한도 초과 보상 수령 |
-| **AV-8** | 리플레이/재접속 재전송 | 동일 클리어 결과 재제출 | 중복 보상 |
-| **AV-9** | 스테이지 잠금 우회 | 언락 안 된 스테이지 완료 패킷 | 진행도 건너뛰기 |
-
-### A-3. 판정 대상 범주 3종
-
-1. **물리적 불가능** — 시뮬레이터로도 달성 불가능한 수치 (예: 클리어타임 0초, 점수 int.MaxValue)
-2. **확률적 극단** — 이론상 가능하나 확률이 충분히 낮아 사실상 어뷰징으로 간주 (예: 운으로 1회 나올 수치의 연속 달성)
-3. **논리적 모순** — 내부 값들이 서로 모순 (예: "피격 0회"인데 "HP 50% 소진")
-
----
-
-## B. 경계값 도출 방법론
-
-### B-1. 기본 공식
-
-```
-경계값 = 시뮬_이론_극값 × 안전마진계수
-```
-
-- `시뮬_이론_극값`: Unity MCP 시뮬을 N회(권장 N=1,000 이상) 수행하여 얻은 **최상위 극값** (최대/최소는 벡터에 따라 다름)
-- `안전마진계수`: 벡터 특성에 따라 결정하는 완화 계수 (정상 플레이어 오차 허용)
-
-### B-2. 안전마진 설계 원칙
-
-| 벡터 특성 | 마진 방향 | 계수 예시 | 근거 |
-|---------|--------|---------|------|
-| 클리어타임 (짧을수록 의심) | 하한 경계값 = 이론 최단 × **0.80** | 0.80 | 프레임 드랍·클라 시계 오차로 정상 유저도 5~15% 짧게 보고 가능 |
-| 획득 재화 (많을수록 의심) | 상한 경계값 = 이론 최대 × **1.05** | 1.05 | 소숫점 반올림·버프 중첩 경계 케이스 흡수 |
-| 랭킹 점수 (높을수록 의심) | 상한 경계값 = 이론 최대 × **1.10** | 1.10 | 신규 카드 출시 등 업데이트 이후 시뮬 갱신 전 과도기 흡수 |
-| 피격 수 (적을수록 의심) | 하한 경계값 = 이론 최소 (= 0) | - | 0회도 이론상 가능, 음수만 차단 |
-| 미션 카운트 | 상한 경계값 = 일일 최대 달성 가능치 × **1.00** | 1.00 | 마진 불필요 (정수 카운트) |
-
-**주의**: 마진은 "정상 유저를 어뷰저로 오판정하지 않기 위한" 안전장치지, "어뷰저를 놓치는 관용"이 아니다. 극값의 80%~110% 범위는 경계이므로 이 범위 유저는 "**1차 통과 + 플래그 미부여**"로 처리한다.
-
-### B-3. 업데이트 주기
-
-1. **정기 갱신**: 밸런스 패치(카드 수치 변경·신규 몬스터 추가) 시 해당 영역 시뮬 재실행
-2. **긴급 갱신**: 어뷰징 신고 접수 또는 랭킹 이상치 감지 시 즉시 시뮬 재실행·경계값 조정
-3. **버전 관리**: 경계값 테이블은 C6에 따라 `.bak_{YYYYMMDD_HHMM}.json` 백업 후 교체
-4. **C13 기록**: 경계값 변경은 PD 지시 로그·대화로그에 기각안 포함 기록 (P24)
-
-### B-4. 시뮬레이터 입력 조건 (Unity MCP)
-
-각 스테이지·각 벡터에 대해 다음 조건의 최극단 조합을 시뮬:
-- 캐릭터: 최강 편성 (풀레벨·최적 카드)
-- 적 패턴: 최선 운 (치명타 확률 최대·적 회피 최소)
-- 플레이 입력: 완벽 입력 (반응시간 0·공백 없음)
-- 물약·쉴드: 최대 활용 (획득 재화 벡터) / 미사용 (C6 조건 벡터)
-
-**출력 수집**: 10,000회 반복하여 상위/하위 0.1% 값을 "이론 극값"으로 채택 (절대 최대/최소 아닌 이유 = 시뮬 자체 오차 흡수).
-
----
-
-## C. 검증 계층 설계
-
-### C-1. 2계층 검증 원칙
-
-**1계층 (클라)** — 예방적 차단
-- 목적: 악의적 조작이 아닌 **버그·의도치 않은 극값**을 클라 단에서 거르기
-- 클라가 자체 생성한 결과값이 경계값을 초과하면 전송 보류 + 경고 로그 수집
-- **클라 신뢰는 하지 않음** — 이 계층만으로는 판정 금지 (메모리 조작 시 이 계층 무력화 가능)
-
-**2계층 (서버)** — 최종 판정
-- 목적: 모든 어뷰징 판정의 **단일 결정권자**
-- 서버가 경계값 테이블을 보유하고 수신 패킷 전량 검증
-- 경계 초과 시: 거부 + 플래그 기록 + (심각도에 따라) 관리자 알림
-
-### C-2. 검증 흐름 (서버)
-
-```
-[클라 패킷 수신]
-  ↓
-[Step 1] 기본 유효성 (음수·null·형식 오류) → 거부
-  ↓
-[Step 2] 스테이지 잠금 상태 확인 (AV-9 대응) → 거부
-  ↓
-[Step 3] 중복 제출 확인 (AV-8 대응, 같은 세션ID·클리어ID) → 거부
-  ↓
-[Step 4] 경계값 테이블 조회 → 각 필드 범위 검증
-  ↓ (통과)
-[Step 5] 논리 정합성 검증 (필드 간 모순, A-3-3 범주)
-  ↓ (통과)
-[정상 처리 + 보상 지급]
-
-  ↓ (Step 4·5 실패 시)
-[플래그 기록 + 보상 보류 + 심각도별 조치]
-```
-
-### C-3. 역할 분담 원칙
-
-| 주체 | 역할 | 금지 |
-|-----|-----|-----|
-| 클라 | 버그 조기 감지·UX 경고 | 최종 판정, 플래그 기록 |
-| 서버 | 최종 판정, 플래그 DB 기록, 관리자 알림 | 클라 통과 가정·검증 생략 |
-| 기획팀 | 경계값 테이블 공급 | 서버 검증 로직 직접 작성 |
-| 인간 서버 개발자 | 검증 로직 구현·플래그 DB 스키마 | 경계값 자체 수정 (기획 승인 없이) |
-
----
-
-## D. 어뷰저 플래그 체계
-
-### D-1. 플래그 종류 3단계
-
-| 단계 | 트리거 | 자동 조치 | 관리자 조치 |
-|-----|-------|---------|-----------|
-| **F1 경미** | 경계값의 +5%~+10% 범위 이내 초과 (마진 범위 경계) | 플래그 기록만 | 누적 3회 이상 시 F2 격상 |
-| **F2 중대** | 경계값의 +10%~+50% 초과, 또는 F1 3회 누적 | 해당 보상 보류 + 관리자 알림 | 수동 검토 후 재화 회수·경고 |
-| **F3 확정** | 경계값의 +50% 초과, 논리 모순 발생, 또는 F2 2회 누적 | 해당 보상 미지급 + 계정 플래그 | 계정 정지 검토 (랭킹 삭제 포함) |
-
-### D-2. 플래그 누적 처리
-
-- 플래그 DB: `{user_id, timestamp, vector_id, flag_level, raw_data, boundary_value, reason}`
-- 기간 윈도우: 최근 30일 기준 누적 (기획팀 권고안, 서버측 조정 가능)
-- 에스컬레이션: F1×3 → F2 / F2×2 → F3 / F3×1 → 즉시 계정 정지 검토 대상
-
-### D-3. 기획팀 권고안 (PM 경유 운영팀 협의 필요)
-
-- **F1**: 자동 회수 없음 (false positive 위험). 사용자에게 경고도 노출하지 않음 (어뷰저 학습 방지)
-- **F2**: 해당 회차 보상만 회수. 사용자에게는 "서버 동기화 오류, 재시도" 메시지 노출
-- **F3**: 계정 정지는 관리자 최종 판단. 랭킹 등록 데이터는 즉시 삭제
-
----
-
-## E. 대상 액션별 구체 경계값 초안
-
-> **주의**: 아래 수치는 모두 **플레이스홀더**. Unity MCP 시뮬 가동 후 확정. 실제 경계값 테이블은 별도 JSON으로 관리.
-
-### E-1. 스테이지 클리어
-
-| 필드 | 검증 규칙 | 경계값 예시 (Stage 1) |
-|-----|---------|----------------------|
-| `clearTime` | `sim_min × 0.80` 하한, `sim_max × 1.20` 상한 | 하한: 미확정(시뮬 후) / 상한: 미확정 |
-| `goldEarned` | `sim_max × 1.05` 상한 | 상한: 미확정(시뮬 후) |
-| `starsEarned` | 0~3 정수, ★조건 메타값과 교차 검증 | 0~3 |
-| `hpRemaining` | `0 ≤ hp ≤ maxHp` | 캐릭터 maxHp 기반 |
-| `potionUsed` | 0 이상 정수, 소지 한도 이하 | 캐릭터 포션 한도 |
-| `shieldRemaining` | `0 ≤ shield ≤ maxShield` | 캐릭터 maxShield 기반 |
-| `hitsTaken` | 0 이상 정수, `sim_max × 1.20` 상한 | 상한: 미확정(시뮬 후) |
-
-### E-2. 랭킹 등록
-
-| 필드 | 검증 규칙 | 경계값 예시 |
-|-----|---------|----------|
-| `score` | `sim_max × 1.10` 상한 | 상한: 미확정(시뮬 후) |
-| `clearTime` | 동일 스테이지 E-1 규칙 적용 | - |
-| `deckComposition` | 소유 카드 목록과 교차 검증 | - |
-| `stageId` | 유효 스테이지 ID (잠금 해제 상태) | - |
-
-### E-3. 일일 미션
-
-| 필드 | 검증 규칙 | 경계값 예시 |
-|-----|---------|----------|
-| `missionId` | 유효 미션 ID + 당일 활성 | - |
-| `currentCount` | `missionMaxCount` 상한 | 미션별 상한 |
-| `incrementDelta` | 단일 트리거로 1 증가만 허용 | 1 |
-| `completionTimestamp` | 일일 리셋 시각 이후 ~ 현재 | - |
-
-### E-4. ★조건 교차 검증 (P17 연계)
-
-각 스테이지의 활성 ★조건(C1~C9, N1~N6)과 클리어 결과 필드가 정합해야 한다. 예:
-- **C6 (포션 절제)**: `potionUsed == 0` 인지 확인
-- **N2 (피격 제한)**: `hitsTaken ≤ 서브맵수 × 1` 인지 확인
-- **N4 (쉴드 하한 30%)**: `shieldRemaining ≥ maxShield × 0.30` 인지 확인
-
-★조건 통과 보고와 필드 값이 모순되면 **F3 확정 플래그** (논리 모순).
-
----
-
-## F. 서버 측 요구사항 (개발팀 인계용)
-
-### F-1. 기획팀 공급 산출물
-
-1. **경계값 테이블** — JSON 파일 (Unity MCP 시뮬 결과 반영)
-2. **★조건 검증 규칙** — 스테이지별 활성 조건 + 판정 로직
-3. **플래그 기준** — F1/F2/F3 경계 정의
-4. **갱신 공지** — 경계값 변경 시 개발팀에 PR 또는 소통 채널 통지
-
-### F-2. 경계값 테이블 스키마 (JSON 예시)
-
-```json
-{
-  "version": "1.0.0",
-  "generatedAt": "2026-04-17T00:00:00Z",
-  "simulationRuns": 10000,
-  "stages": {
-    "stage_01": {
-      "clearTime": {
-        "min": 42.3,
-        "max": 180.0,
-        "marginLow": 0.80,
-        "marginHigh": 1.20,
-        "boundaryMin": 33.84,
-        "boundaryMax": 216.0
-      },
-      "goldEarned": {
-        "max": 250,
-        "marginHigh": 1.05,
-        "boundaryMax": 263
-      },
-      "hitsTaken": {
-        "min": 0,
-        "max": 8,
-        "marginHigh": 1.20,
-        "boundaryMax": 10
-      },
-      "starConditions": {
-        "C2": { "field": "hitsTaken", "operator": "==", "value": 0 },
-        "C6": { "field": "potionUsed", "operator": "==", "value": 0 },
-        "N2": { "field": "hitsTaken", "operator": "<=", "formula": "subMapCount * 1" }
-      }
-    }
-  },
-  "ranking": {
-    "stage_01": {
-      "score": { "max": 12500, "marginHigh": 1.10, "boundaryMax": 13750 }
-    }
-  },
-  "dailyMissions": {
-    "login": { "maxCount": 1 },
-    "clear_any_stage": { "maxCount": 10 }
-  }
-}
-```
-
-### F-3. 검증 API 호출 흐름 (서버 내부)
-
-```
-수신: POST /api/stage/complete
-  body: { userId, stageId, clearTime, goldEarned, starsEarned, hitsTaken, potionUsed, ... }
-
-서버 처리:
-  1. AbuseValidator.validate(userId, stageId, body)
-     → boundaries = BoundaryTable.get(stageId)
-     → for each field: 경계값 비교
-     → starCondition 교차 검증
-     → 중복 제출 체크
-  2. ValidationResult:
-     - PASS: 보상 지급 처리
-     - F1: 보상 지급 + 플래그 기록
-     - F2: 보상 보류 + 플래그 기록 + 관리자 알림
-     - F3: 보상 미지급 + 플래그 기록 + 계정 플래그
-  3. 응답:
-     - PASS/F1: { status: "success", rewards: [...] }
-     - F2: { status: "pending", message: "서버 동기화 오류, 재시도 바랍니다" }
-     - F3: { status: "blocked" }  (어뷰저 학습 방지 위해 구체 사유 미노출)
-```
-
-### F-4. 위반 응답 포맷 (권고)
-
-어뷰저 학습 방지를 위해 구체 수치·사유를 클라에 노출하지 않는다:
-
-```json
-// F1 (경미)
-{ "status": "success", "rewards": [...] }  // 플래그는 서버 내부만, 클라 무감지
-
-// F2 (중대)
-{ "status": "pending", "message": "서버 동기화 오류, 잠시 후 재시도" }
-
-// F3 (확정)
-{ "status": "blocked" }
-```
-
-### F-5. 플래그 DB 스키마 (서버 구현 시 참조)
-
-```
-AbuseFlag:
-  - id: UUID
-  - userId: string
-  - timestamp: datetime
-  - vectorId: enum (AV-1 ~ AV-9)
-  - flagLevel: enum (F1, F2, F3)
-  - stageId: string (nullable)
-  - fieldName: string
-  - rawValue: json
-  - boundaryValue: json
-  - exceedRate: float  // (rawValue - boundary) / boundary
-  - reason: string
-  - reviewedBy: string (nullable)
-  - reviewedAt: datetime (nullable)
-  - resolution: enum (pending, confirmed_abuse, false_positive, pardoned)
-```
-
----
-
-## G. 기각안
-
-### G-1. 서버 단독 시뮬 재현 검증 (채택 안 함)
-
-- **안**: 서버가 클라 입력(키·타이밍)을 받아 서버에서 전투를 재시뮬하여 결과 일치 여부 검증
-- **기각 사유**: (1) 서버 CPU 비용 폭증 — 1회 재시뮬 ≈ 1개 전투 전체 연산 (2) 동기화 이슈 (난수 시드·부동소수점) (3) 현 프로젝트가 실시간 멀티플레이가 아닌 싱글 플레이 구조라 과잉 투자. **채택 안**인 "경계값 기반 통계적 검증"이 비용·구현 난이도·효과 3축에서 우수.
-
-### G-2. 머신러닝 기반 이상치 탐지 (채택 안 함)
-
-- **안**: 유저 플레이 데이터를 수집하여 ML 모델로 어뷰저 이상치 자동 탐지
-- **기각 사유**: (1) 학습 데이터 축적에 운영 기간 필요 — 초기 출시 대응 불가 (2) false positive 조정 난해 (3) 인간 서버 개발자 부담 가중. 장기적 보조 수단으로는 고려 가치 있으나 v1 범위에서 제외. 본 기획서는 시뮬 경계값으로 출시 대응 + 운영 후 데이터 축적 → 차후 ML 도입 여지 유지.
-
-### G-3. 클라 단독 판정 (채택 안 함)
-
-- **안**: 클라가 자체 검증 후 서버에는 결과만 전송
-- **기각 사유**: 메모리 조작·패킷 위변조로 무력화됨. 어뷰징 방지 근본 목적 미달성. **원천적으로 고려 대상 아님**.
-
-### G-4. 전체 플레이 로그 전송·서버 기록 (채택 안 함)
-
-- **안**: 매 프레임 입력 로그 전체를 서버로 전송하여 서버가 사후 감사
-- **기각 사유**: (1) 네트워크 비용 과도 (2) 저장소 비용 (3) G-1과 유사하게 오버엔지니어링. F3 확정 플래그 시점에 사후 감사용으로 마지막 30초~60초 정도만 보관하는 방안은 서버측 재량.
-
-### G-5. 안전 마진 0% 엄격 검증 (채택 안 함)
-
-- **안**: 시뮬 극값을 그대로 경계값으로 사용하여 극한 배제
-- **기각 사유**: false positive 폭발. 프레임 드랍·반올림 오차로 정상 유저도 매번 플래그됨. **C7 재미 우선 원칙 위반** — 정상 플레이어 경험 훼손. 5%~20% 마진 보정 필수.
-
----
-
-## 후속 작업 (Unity MCP 시뮬 가동 후 수행)
-
-1. 각 스테이지·각 벡터별 시뮬 10,000회 실행
-2. 경계값 테이블 JSON 1차 산출 (v1.0.0)
-3. balance-designer 검토 → 재미 관점 마진 재조정
-4. 개발팀과 스키마·API 계약 확정 (`공유/소통/기획팀→개발팀/` 발행)
-5. 플래그 DB 스키마 서버팀 리뷰·구현
-6. 통합 QA 시 어뷰저 시뮬 툴로 F1/F2/F3 각각 검증 케이스 생성
-
-## 연관 규칙·문서
-
-- **C7**: 재미 우선 — 정상 플레이어 보호를 위한 마진 설계 근거
-- **C11**: 개발 관점 — 서버 자원 효율 고려하여 재시뮬 대신 경계값 비교 채택 (G-1 기각 근거)
-- **C13**: PD 지시 트래킹 — 본 기획 등록 및 경계값 변경 이력 관리
-- **C23**: 허위 보고 금지 — 본 기획서는 실제 시뮬 가동 전이므로 수치는 모두 플레이스홀더 명시
-- **P17**: ★조건 배타 배치 — E-4 ★조건 교차 검증과 연계
-- **P23**: 기획 결정 재량 — 본 기획은 기획팀장 재량 범위(신규 시스템 제안은 PM 확인 필요 → 본 기획서 발행으로 PM 확인 경유)
-
----
-
-**기획팀장 발의**
-**PM 검토 요청**: 본 기획서 스키마·프레임워크 승인 → 개발팀 F 섹션 인계 트리거
-**승인 후 착수**: Unity MCP 시뮬 가동 (별도 PD 지시 로그)
diff --git a/공유/소통/완료/2026-04-17_업무공유체계_점검_PM조직관점.md b/공유/소통/완료/2026-04-17_업무공유체계_점검_PM조직관점.md
deleted file mode 100644
index 3ba1d67..0000000
--- a/공유/소통/완료/2026-04-17_업무공유체계_점검_PM조직관점.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-from: pm-auditor
-to: 총괄PM
-type: 감사보고
-subject: 업무 공유·기록 체계 전수 점검 (PM 조직 메타 관점)
-priority: high
-status: 작성완료
-created: 2026-04-17
-ref: P26, C31, C13, C29-4, PD님 직접 지시(2026-04-17 메타 점검)
-관련_선행감사: 공유/소통/pm-auditor→PM/2026-04-17_감사보고_팀기록체계_전수점검.md (팀 기록 품질 관점)
----
-
-# 업무 공유·기록 체계 전수 감사 (PM 조직 메타 관점)
-
-## 0. 서문 — 본 감사자의 상태 (C23 실측 고지)
-
-**본 에이전트는 `.claude/agents/pm-auditor.md` 역할 주입을 받은 `general-purpose` 서브에이전트이다.** settings.json의 agent 목록에 pm-auditor가 정식 등록되지 않은 상태로, PM이 `Task(subagent_type='pm-auditor')` 호출 시 general-purpose로 폴백되는 구조적 제약 속에서 감사 수행. 이 제약 자체가 본 보고 2축 핵심 논점이다.
-
-## 1. 결론 요약
-
-| 시나리오 | 현 체계 복원 가능성 | 구멍 |
-|---------|------------------|------|
-| A. PM 세션 재시작 (같은 날) | **양호** | pm_context_restore.sh + 대화로그 + PD 지시 로그 3중 |
-| B. 새 PC clone 후 재개 | **양호** | setup + git pull + SessionStart hook 연쇄 |
-| C. 1주일+ 공백 후 재개 | **취약** | 대화로그 최근 2일만 자동 로드. 중간 결정·맥락은 수동 탐색 부담 |
-| D. PM 교체 (다른 Claude 인스턴스) | **취약** | "현재 어디까지 논의했나"를 나타내는 **세션 상태 스냅샷** 부재 |
-
-**메타 결론**: **"진행 중 작업의 현재 순간 상태"를 표현하는 단일 SOT가 없다.** PD 지시 로그는 항목 단위, 대화로그는 결정 단위, 소통 채널은 통신 단위. 셋 다 누적형이라 "지금 이 순간 PM이 어디에 서 있는가"를 30초 내 파악할 문서가 부재.
-
----
-
-## 2. 7축 메타 감사 실측
-
-### 2-1. PM 세션 전환 시 맥락 유지 (P21-5B·P24·pm_context_restore.sh 효과성)
-
-**실측**:
-- `scripts/pm_context_restore.sh` (69줄, 2026-04-17 신설): 당일·전일 대화로그 목록 출력 + 당일 로그 부재 시 P24 위반 경고 + 최근 커밋 10건 표시
-- SessionStart hook에 5단계 체인 등록 확인 (git fetch → inbox_scan → change_digest → live_session_load → pm_context_restore)
-- 당일(2026-04-17) 조직운영 로그 존재: `공유/대화로그/조직운영/2026-04-17.md`
-
-**#28 Unity MCP 누락 사건 재분석 (어느 단계가 실패했는가)**:
-1. PD 지시 로그 #28 비고란에 "Unity MCP 활용 방향으로 전환" 1줄 기록됨 — **로그 기록은 정상**
-2. pm_context_restore.sh는 대화로그·커밋만 노출 — **PD 지시 로그 활성 항목을 hook이 스캔하지 않음**
-3. PM이 수동으로 PD 지시 로그를 Read하지 않으면 비고란 변경 감지 불가 — **수동 의존 구조**
-4. C31-1-D(세션 시작 맥락 복원) 체크리스트가 "PD 지시 로그 활성 테이블 Read"를 명시하지 않음 — **체크리스트 공백**
-
-**결론**: pm_context_restore.sh는 **대화로그·커밋 축만 커버**하며, **PD 지시 로그 비고란 변경은 사각지대**. 활성 테이블 스캔 스크립트 신설 필요.
-
-### 2-2. pm-auditor 자체의 한계
-
-**실측 한계**:
-1. **settings.json agent 미등록** — `general-purpose`로 폴백되어 에이전트 정의의 model(opus) 지정이 무력화. 감사 깊이 저하 우려
-2. **모드 A(응답 발신 직전 교차 검증) 실행 불가** — PM이 응답을 작성 중 발신 전에 pm-auditor를 호출하려면 동기식 tool call이 필요하나, 현재 Task 도구는 비동기 일회성 호출. **"발신 직전"이 구조적으로 불가**
-3. **메타 인식 한계** — 본 감사자는 "PM이 놓친 것"을 보지만, **"PM과 pm-auditor가 함께 놓친 것"은 포착 불가** (재귀 감사자 부재)
-4. **스스로의 신설 당일 등록 지연** — 2026-04-17 신설 → 다음 세션까지 정식 호출 불가한 구조적 결함이 신설 당일 노출됨
-
-### 2-3. PM ↔ 팀장 Agent 호출의 정보 손실
-
-**실측**:
-- PM이 Agent 호출 시 프롬프트는 응답 본문에 포함되나, **"PD님이 방금 지시한 원문"이 그대로 전달되는가**는 PM 재량
-- Agent 응답 수령 시 PM이 요약 과정에서 **C22(용어 일관) 위반**으로 원 용어 변형 사례가 과거 발생 (memory 참조: `feedback_role_play_vs_real_call.md` 계열)
-- Agent 호출 이력이 대화로그에 **자동 기록되지 않음** — PM이 수동으로 P24 엔트리 작성 시에만 기록
-- **Task 호출 기록의 감사 추적성 부재** — 어떤 Agent에 어떤 프롬프트를 보냈는지 git 커밋·파일로 영구 보존되지 않음
-
-### 2-4. 규칙 체계 자체의 정합성 (C1~C31, P1~P26 전수)
-
-**모순·공백·중복 발견**:
-
-| # | 이슈 | 관련 규칙 | 성격 |
-|---|------|---------|------|
-| 1 | **C13 vs C29-4 vs P19 vs P24** 역할 경계 모호 — "완료 기록"을 4곳에 중복 기재해야 한다고 읽힘 | C13, C29-4, P19, P24 | 중복·C14-4 위반 소지 |
-| 2 | P24 "기록 시점 3가지 트리거"와 C29-4 "완료 시점 필수 기록 4종"이 **어느 쪽이 상위인지 불명확** | P24, C29-4 | 모순 |
-| 3 | C31-1-D 체크리스트가 "PD 지시 로그 활성 테이블 Read"를 명시하지 않음 | C31-1-D | 공백 (#28 사건 원인) |
-| 4 | **Agent 호출 이력 기록 의무가 어느 규칙에도 없음** | 전무 | 공백 |
-| 5 | C27 "PM이 Agent 결과 수령 직후 로그 갱신 확인"은 **확인 방법(스크립트·체크리스트)이 미규정** | C27 | 구현 공백 |
-| 6 | P21-5B "최근 2일 대화로그 Read"가 시나리오 C(1주+ 공백)에 대응 불가 | P21-5B | 시나리오 커버리지 공백 |
-
-### 2-5. 기록 채널의 일관성 (C14-4 준수 여부)
-
-**채널별 동일 정보 중복 기재 실태**:
-- **완료 이벤트 1건이 최대 5곳 기록** 필요: PD 지시 로그(완료 아카이브 이동) + 대화로그(#완료 태그 엔트리) + 소통 채널(status 갱신 + 완료 폴더 이동) + Live 더미(세션 공유 전까지) + git 커밋 메시지
-- 이는 C14-4(참조 무결성 — 중복 기재 금지)와 **형식상 충돌**. 다만 각 채널 목적이 달라 "정보의 다른 측면"이라 주장 가능
-- **실제 문제**: 5곳 중 2~3곳만 기록되는 부분 갱신이 빈발. 선행 감사(2026-04-17_감사보고_팀기록체계_전수점검.md)에서 소통 채널 완료 폴더 이동 전면 방치 적발됨
-
-**단일 SOT 부재**: "PD 지시 #N의 현재 상태"를 알려면 최소 2곳(PD 지시 로그 + 소통 채널)을 교차 확인해야 함.
-
-### 2-6. 세션 전환 시나리오별 복원 가능성
-
-| 시나리오 | 현 체계 | 구멍 |
-|---------|--------|------|
-| A (당일 재시작) | SessionStart hook 5단계 | 없음 |
-| B (새 PC) | setup 스크립트 + git pull + hook | 없음 |
-| C (1주일+ 공백) | 대화로그·커밋 수동 탐색 | **자동 요약 부재** — 중간 기간 결정·방향 전환을 놓치기 쉬움 |
-| D (PM 교체) | CLAUDE.md + SKILL.md + 대화로그 | **"현재 진행 중 논의의 temperature"**(PD님과의 밀착도·미해결 안건·긴급도)가 비정형 |
-
-### 2-7. 자동화 강제력
-
-**현재 자동화**:
-- SessionStart hook 5단계 (pull·inbox·digest·live·context)
-- UserPromptSubmit hook 3단계 (throttle·hold·live)
-- PreToolUse auto_approve
-
-**자율 준수 의존 영역 (강제 전환 가능)**:
-1. **C31 체크리스트 수동 수행** → PM 응답 발신 전 **체크리스트 파일 Write 강제** hook 가능
-2. **P24 대화로그 기록** → 세션 종료 시점 파일 부재 검출 hook은 있으나 **Write까지 강제는 아님**
-3. **PD 지시 로그 갱신** → Agent 응답 수령 시 자동 상태 동기화 스크립트 부재
-
----
-
-## 3. 구체 개선안 (A·B·C·D — C25 위계)
-
-### A. 즉시 착수 (PM 재량, 규칙·스크립트 신설)
-
-1. **A-1. `scripts/pd_log_active_scan.sh` 신설** — 세션 시작 시 PD 지시 로그 활성 테이블을 파싱하여 비고란·산출물 경로 최신 변경 요약 출력. **SessionStart hook 체인에 추가**. (구현 난이도: 낮음. 효과: #28 사건 재발 차단. 해결 시나리오: D·C-부분)
-2. **A-2. C31-1-D 체크리스트 보강** — "PD 지시 로그 활성 테이블 전수 Read"를 명시 항목으로 추가. (난이도: 낮음. 효과: 수동 의존 시에도 경로 명시. 해결: A)
-3. **A-3. `scripts/agent_call_log.sh` 신설** — Task 도구 호출 시 프롬프트·응답 요지를 `공유/대화로그/조직운영/`에 자동 append. (난이도: 중. 효과: 2-3번 공백 해소. 해결: D)
-4. **A-4. pm-auditor settings.json 정식 등록** — agent 목록 추가로 opus 모델 적용·Task 호출 정상화. (난이도: 낮음. 효과: 본 감사자 정상화. 해결: 즉시)
-5. **A-5. 감사 결과 `memory/feedback_pm_context_hook_gap.md` 신설** — 본 보고 핵심 교훈 영구 보존. (난이도: 낮음. 효과: 노하우 축적. 해결: 재발 방지)
-
-### B. PM 조율 (팀장 Agent 확인 필요)
-
-1. **B-1. 기록 채널 역할 경계 재정의** — C13/C29-4/P19/P24 중복을 "1차 기록지 + 2차 교차 참조" 구조로 단일화. 각 팀장 의견 수렴 후 SKILL.md 개정. (난이도: 중. 효과: 부분 갱신 방치 패턴 차단. 해결: 2-5)
-2. **B-2. "세션 상태 스냅샷" 단일 SOT 신설** — `공유/세션_현황.md` 한 파일에 "현재 PD님과 논의 중인 안건·미해결 결정·차단 요인"을 3항목으로 압축 유지. PM이 응답 발신 전후 자동 갱신. (난이도: 중-상. 효과: 시나리오 D 해결. 해결: D)
-
-### C. PD님 실질 결정 사항 (C29 엄격 — 진짜 PD님만 결정 가능한 것)
-
-1. **C-1. 본 감사 보고 수용·반려** — 개선안 A·B 착수 여부 최종 의사
-2. **C-2. 시나리오 C(1주일+ 공백) 대응 우선순위** — 현재 조직 운영 빈도상 시나리오 C가 발생하는가, 방어 투자 필요한가에 대한 방향
-
-### D. pm-auditor 자체 개선 (본 에이전트 정의 갱신 안건)
-
-1. **D-1. 감사 영역 5종으로 확장** — 기존 4종(로그 추적·규칙 준수·PM 재량 추적·프로세스 개선)에 **"규칙 체계 정합성 메타 감사"** 추가. 본 보고 2-4축이 근거
-2. **D-2. 자기 한계 명시 절 신설** — pm-auditor.md에 "본 감사자가 구조적으로 포착 불가한 영역" 섹션 추가
-3. **D-3. 모드 A(응답 발신 직전) 포기 또는 재설계** — 기술적 불가이므로, 대안으로 **"응답 초안 작성 후 발신 전 Task 동기 호출"** 프로토콜 명문화
-
----
-
-## 4. 다른 팀 Agent 보고 교차 검증 포인트 (PM용 체크리스트)
-
-5개 팀장·감사관 보고 수령 시 PM이 교차 확인할 핵심 축:
-
-| 교차 축 | 확인 포인트 | 불일치 시 대응 |
-|--------|----------|-------------|
-| #28 Unity MCP 전환 인지 | 개발팀장·기획팀장이 Unity MCP 방향을 동일 용어로 인지하는가 (C22) | PM이 통합 재전파 |
-| 서버 Critical 보안 3건 상태 | 서버팀장·개발팀장 보고 간 "보류 사유·재개 트리거" 일치성 | SKILL.md 갱신 필요성 판단 |
-| 시뮬 축 단일화(Python 폐기) | 모든 팀장이 "교차 검증 축 Unity MCP 단일"을 확인하는가 | 잔여 Python 참조 색출 지시 |
-| 대화로그 작성 당사자 | 팀장 Agent별 P24 준수율 자체 평가 vs 본 감사자의 실측 | 허위 자가 평가 색출 |
-| Agent 호출 이력 정합성 | 각 팀장이 "오늘 PM이 나에게 호출한 프롬프트 요지" 기억 | Agent 정보 손실 증거 |
-| 규칙 중복 인식 | C13/C29-4/P19/P24 중 "혼란스러운 규칙"을 팀장들이 지목하는가 | B-1 개선안 긴급도 산정 |
-
-**PM 통합 시 자기 점검**:
-- [ ] 5개 보고 중 **같은 사실을 다르게 서술한 항목** 식별했는가
-- [ ] 팀 간 **책임 경계 분쟁** 소지 발견 시 PD님 결정 안건화했는가
-- [ ] 본 감사자(pm-auditor)가 지적한 **구조적 구멍 6종**(2-4표)이 팀 보고에서도 간접 증거로 나타나는가
-
----
-
-## 5. 감사 메타 자평 (본 감사자의 한계 자진 고지)
-
-**본 감사에서 확신 있게 말하지 못한 것**:
-- 시나리오 C 발생 빈도 — 조직 운영 이력이 2026-04-14 개시라 **통계적으로 불확실**
-- pm-auditor settings.json 등록의 **기술적 선행 조건** — 다른 agent 등록 이력 미검증 (일단 파일 존재 확인만 수행)
-- B-2 "세션 현황 SOT" 신설이 C14-4(중복 기재 금지)를 재위반하는가 — **설계 논의 필요**
-
-**본 감사자가 구조적으로 포착 불가한 것**:
-- PD님의 미언어화 의도 (PM의 뉘앙스 해석 정확성)
-- PM과 pm-auditor가 함께 누락한 영역 (재귀 감사자 부재)
-- PM 응답 발신 직전의 실시간 교차 검증 (비동기 제약)
-
----
-
-## 6. 후속 조치 요청
-
-**PM에게**:
-1. A-1~A-5 착수 여부 본 세션 내 결정
-2. 5개 팀 보고 통합 시 §4 교차 검증 체크리스트 수행
-3. B-1·B-2는 팀장 의견 수렴 후 PD님께 안건화
-
-**PD님 상신 후보**: §3-C 2건 (C-1·C-2) 외에는 없음. 나머지는 PM·팀장 재량으로 처리 가능 (C29 준수).
-
----
-
-감사 종료. 본 보고를 `공유/대화로그/조직운영/2026-04-17.md`에 `#이슈 #결정 #PM` 태그로 append 권고.
diff --git a/공유/소통/완료/2026-04-17_업무공유체계_점검_개발팀.md b/공유/소통/완료/2026-04-17_업무공유체계_점검_개발팀.md
deleted file mode 100644
index 025eaba..0000000
--- a/공유/소통/완료/2026-04-17_업무공유체계_점검_개발팀.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-type: 점검보고
-from: 개발팀장
-to: PM
-date: 2026-04-17
-status: 완료
-tags: [업무공유, 기록체계, 교차검증, C29, C13, C27]
----
-
-# 업무 공유·기록 체계 점검 — 개발팀 관점
-
-> **범위**: 개발팀 내부(개발팀장·클라이언트팀장·서버팀장·QA)의 기록 의무 명확성, 세션 전환 맥락 유지, 누락 감지, 교차 검증, 책임 분배 5축. 실측 근거 우선.
-
----
-
-## A. 현황 실측
-
-### A1. 기록 의무 명확성 — 구멍 있음
-
-**실측 경로·규칙 매핑**:
-- PD 지시: `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` (P19, 활성·아카이브 2분할 적용됨)
-- 대화로그: `공유/대화로그/{수상한잡화점|코어프레임워크|조직운영}/YYYY-MM-DD.md` (P24)
-- 소통 채널: `공유/소통/개발팀→PM/`, `개발팀→기획팀/`, 완료분은 `완료/`로 이동 (C29-4)
-- Live 더미: `.live/` (P25)
-
-**잘 되는 것**:
-- PD 지시 로그는 #1·#2·#5·#28 각 행이 장문 사후조치 컬럼을 갖춰 진행 상태 추적 가능
-- 2026-04-17 대화로그에 Unity MCP 기술검토(12:21) 및 기각안까지 기록됨 (P24 표준 형식 준수)
-- 완료 아카이브 분리(#27 `코어코드 통합` 완료 이동)는 세션 갱신 시 활성 테이블만 스캔하는 구조를 실제로 지원
-
-**구멍 4종**:
-1. **코드·커밋 레벨 기록 공백** — 규칙상 "의미 있는 작업"의 범위가 문서·결정 중심이고, **코드 변경·리팩토링·서브모듈 수정·빌드 설정 변경** 같은 개발 고유 활동이 P24 대화로그에 들어가야 하는지 명시 부재. 2026-04-16 `코어코드/BT.Framework/` git 통합 커밋 `7187ac6`은 대화로그 `코어프레임워크/2026-04-16.md`에 엔트리가 있으나, 커밋 SHA·변경 파일 수치 누락. 다른 커밋(2026-04-16 Template 17개 파일 생성 등)은 대화로그 엔트리가 확인되지 않음.
-2. **산하 팀장(클라이언트·서버·QA) 독립 로그 부재** — PD 지시 로그는 "개발팀" 단일 파일이며, 산하 팀장별 의사결정 이력이 개발팀장 로그에 통합되어 **클라이언트↔서버 경계 결정의 추적성이 낮음**. 예: Unity 프로젝트 점검(2026-04-16 커밋)은 기획팀장이 수행했는데 클라이언트팀장 판단 경로가 불명확.
-3. **기술 결정·아키텍처 결정의 P22 결정로그 활용도 저조** — `공유/소통/개발팀→PM/` 6개 파일 중 "결정로그" 프론트매터를 단일 SOT 규격으로 갖춘 파일이 확인되지 않음 (실측: 파일명 패턴 `RPT`·`기술검토`·`업무현황` 중심). P22는 3줄 이내 결정로그를 요구하나 개발팀은 장문 보고서로만 송신.
-4. **구 명칭 잔재** — 2026-04-16 커밋 `fix(naming): 구 명칭(개발실·기획실·개발실장) 잔존 참조 일괄 정리`로 해소 시도했으나, `공유/소통/개발팀→PM/2026-04-16_업무현황_개발실.md`·`완료/2026-04-16_프로세스고도화_개선안_개발실.md` 등 파일명에 여전히 "개발실" 잔존. 검색 시 혼선 유발.
-
-### A2. 세션 전환 시 맥락 유지 — 구멍 큼
-
-**잘 되는 것**: P21-5B가 2026-04-17 신설되어 PM이 세션 시작 시 최근 2일 대화로그 + `git log --since="2 days ago"` 자동 복원.
-
-**구멍 3종**:
-1. **개발팀장 Agent 호출 세션은 완전 일회성** — Agent 도구로 호출된 개발팀장 세션은 PM 세션의 일시 확장이며, **독립적인 세션 맥락 저장소가 없다**. P21-5B는 PM 전용. 개발팀장이 이전 Agent 호출에서 내린 결정(예: 2026-04-17 12:21 Unity MCP 기술검토 판단 근거)을 재호출 시 복원하려면 **대화로그를 PM이 프롬프트에 수동 주입**해야 함.
-2. **산하 팀장 교차 참조 경로 없음** — 클라이언트팀장이 서버팀장의 직전 결정을 읽는 공식 경로가 `공유/소통/PM→개발팀/` 또는 대화로그 전체 스캔뿐. PM이 개발팀장을 Agent로 호출할 때마다 해당 맥락을 프롬프트에 포함시켜야 하며, **누락 시 산하 팀장은 "이전에 결정된 줄 모르고" 재결정 제안** 가능성.
-3. **Live 더미 Read 의무는 있으나 PD 지시 로그 `## 활성 지시` 읽기 의무는 없음** — 서브에이전트가 작업 착수 전 `.live/` Read 의무(P25)는 있으나, 현 상태의 PD 지시 로그 활성 섹션을 개발팀 Agent가 자동 Read하는 메커니즘 부재. 결과: #1·#2·#5·#28의 "대기 중·사후조치" 컬럼을 모르고 중복 제안할 위험.
-
-### A3. 누락 감지 자동화 — pm-auditor 외 개발팀 전용 없음
-
-**실측**: `scripts/` 디렉토리 14개 스크립트 중 개발팀 영역 전용 감지 스크립트 0건. `.claude/agents/pm-auditor.md`는 존재하나 PM 영역 감사 전용.
-
-**구멍 3종**:
-1. **커밋 직후 대화로그 갱신 감지 hook 부재** — git commit 발생 시 해당 프로젝트의 당일 대화로그 파일 수정 여부를 확인하는 hook이 없음. 결과: 커밋만 쌓이고 맥락은 대화로그에 없는 패턴 재발 가능.
-2. **Unity·코어프레임워크 레포 git 상태 점검은 C30이 의무화했으나 자동 감지 없음** — 작업 착수 전 수동 `git fetch` 호출 의존. 누락 시 침묵 실패.
-3. **dev-auditor 부재** — PM 영역은 pm-auditor가 로그 추적·규칙 준수·재량 처리·프로세스 개선을 전담. 개발팀 영역(코드 변경 기록, C11 자원 효율성 점검, P13 공용 모듈 영향 분석 등)은 감사 전담이 없음.
-
-### A4. 교차 검증 구조 — 비대칭
-
-**잘 되는 것**: pm-auditor가 개발팀 로그도 감사 대상에 포함 (2026-04-17 커밋 `fix(records): pm-auditor 감사 Critical 2 + Major 3 일괄 해소`가 개발팀 PD 지시 로그 #1·#27 경로 정정 포함).
-
-**구멍 2종**:
-1. **개발팀 내부 산하 팀 상호 검증 경로 없음** — 클라이언트팀장이 서버팀장 결정을 검증하거나, QA가 양쪽 기록을 검증하는 정기 트리거 없음. 현재는 PM이 개발팀장을 호출해야만 개발팀 내부 교차 검증 가능.
-2. **기획팀↔개발팀 상호 검증은 소통 채널(`개발팀→기획팀`·`기획팀→개발팀`)로만 수행** — 주기적 감사가 아닌 이벤트 기반. 예: 08~10 SOT 문서(전투·카드·데이터로딩)에 기획 변경 영향이 반영되었는지 정기 체크 없음.
-
-### A5. 책임 분배 — 매트릭스 미정의
-
-**현 실태**:
-- PD 지시 로그 전체 책임: 개발팀장
-- 대화로그: "작업 수행 에이전트" (모호 — Agent 호출된 자가 쓰는가, PM이 정리하는가?)
-- 소통 채널: "수행 팀" (모호)
-- Live 더미: PM만 Write, 서브에이전트 Read 전용
-
-**경계 모호 영역**:
-1. 공용 모듈 변경 (Framework Core 추가) — 클라이언트팀장인지 개발팀장인지?
-2. 클라-서버 API 스펙 변경 — 양쪽 모두인지 한쪽만인지?
-3. QA 전용 테스트 추가 — QA인지 해당 영역 개발자인지?
-4. Unity MCP 시뮬레이션 환경 (2026-04-17 #28) — 개발팀 내부에서 클라·서버 어디 책임?
-
----
-
-## B. 구체 개선안
-
-### 개선안 1 — dev-auditor 에이전트 신설
-- **대상**: `.claude/agents/dev-auditor.md` 신규 작성
-- **구멍 근거**: A3-3, A4-1
-- **구현 방안**: pm-auditor 구조 차용. 감사 영역 4종 = ①코드 변경과 대화로그 정합성 ②P13 공용 모듈 영향 전파 ③클라-서버 경계 결정 추적 ④Unity·코어 레포 git 상태. 모드 A/B/C는 동일. 산출물: `공유/소통/dev-auditor→개발팀장/YYYY-MM-DD_감사보고_<주제>.md`.
-- **비용·리스크**: pm-auditor 대비 추가 opus 호출 1건(감사 시). 감사 빈도는 개발팀장 재량.
-- **분류**: **PM 조율 필요** (pm-auditor 신설 선례에 따라 PM이 템플릿·허용 범위 판단 후 개발팀장 재량 착수).
-
-### 개선안 2 — PD 지시 로그 활성 섹션 자동 Read 의무 (서브에이전트)
-- **대상**: `.claude/skills/BurningTimes-코어룰/SKILL.md` P25 또는 별도 조항
-- **구멍 근거**: A2-3
-- **구현 방안**: P25 "서브에이전트 의무" 조항에 `.live/` Read 외에 `공유/PD_지시_트래킹/{자기_부서}_PD_지시_로그.md`의 `## 활성 지시` 섹션 Read를 추가. 토큰 영향: 활성 지시는 보통 5건 이하, 2KB 내외.
-- **비용·리스크**: 서브에이전트 토큰 약 +2KB/호출. 장기 누적 비용은 중복 제안 회피 이익과 트레이드오프.
-- **분류**: **개발팀장 재량 — 제안, PM 조율**. 룰 개정은 C29-3 팀 논의 권장.
-
-### 개선안 3 — P22 결정로그 개발팀 강제 적용
-- **대상**: `.claude/skills/BurningTimes-코어룰/SKILL.md` P22
-- **구멍 근거**: A1-3
-- **구현 방안**: 개발팀 기술 결정(아키텍처·API 스펙·공용 모듈·빌드·테스트 정책) 확정 시 `공유/소통/개발팀→PM/YYYY-MM-DD_결정_<주제>.md` 3줄 결정로그 의무화. 기존 장문 보고서(`기술검토`·`업무현황`)와 별도로 발행. 프론트매터 `type: 결정로그` 강제.
-- **비용·리스크**: 개발팀 발신 파일 수 증가. 대신 PM이 결정을 스캔할 때 O(파일수)가 아닌 O(결정로그수)로 축소.
-- **분류**: **개발팀장 재량 즉시 착수**. 차기 기술 결정부터 적용.
-
-### 개선안 4 — 산하 팀장별 독립 대화로그 분리
-- **대상**: `공유/대화로그/` 하위 경로 확장
-- **구멍 근거**: A1-2, A5-모호 영역 1·2·3
-- **구현 방안**: `공유/대화로그/수상한잡화점/` 같은 프로젝트 축 외에 **팀 축**(`클라이언트/`·`서버/`·`QA/`·`개발공통/`) 추가. 팀 결정은 팀 축에, 프로젝트 작업은 프로젝트 축에 기록. 겹치는 작업은 양쪽 참조 링크.
-- **비용·리스크**: 파일 수 증가·검색 분기. 반대로 팀장별 맥락 복원 정확도 상승.
-- **분류**: **PM 조율 필요** (다른 부서 기획팀과도 구조 일관성 필요).
-
-### 개선안 5 — 책임 경계 매트릭스 SOT 신설
-- **대상**: `.claude/skills/BurningTimes-코어룰/` 하위 보조 문서 또는 P13 확장
-- **구멍 근거**: A5 전반
-- **구현 방안**: 기록 주체 × 작업 유형 × 저장 채널 3차원 매트릭스 표. 예: "공용 모듈 변경 → 개발팀장 기록 (클라이언트·서버팀장 참조)", "API 스펙 변경 → 클라이언트팀장+서버팀장 양측 기록". 문서 위치: `공유/소통/README.md` 확장 또는 SKILL.md 부록.
-- **비용·리스크**: 초안 작성 공수. 이후 유지비 낮음.
-- **분류**: **PM 조율 필요**. 본 보고서 B.C 매트릭스 초안이 착수점 역할.
-
-### 개선안 6 — 구 명칭 파일명 일괄 정리 (완결)
-- **대상**: `공유/소통/` 이하 파일명 중 "개발실·기획실" 잔존 6건 추정
-- **구멍 근거**: A1-4
-- **구현 방안**: `git mv`로 파일명 변경. 기존 상대 참조가 있으면 함께 수정.
-- **비용·리스크**: 낮음. 참조 깨짐 리스크는 grep로 선행 확인.
-- **분류**: **개발팀장 재량 즉시 착수**. 단, 파일명이 PM 소통 채널인 경우 PM 통지 후 진행.
-
-### 개선안 7 — 커밋 후 대화로그 갱신 감지 hook
-- **대상**: `.claude/hooks/` (현재 디렉토리 부재 확인됨, 신설 필요) 또는 `scripts/post_commit_log_check.sh`
-- **구멍 근거**: A3-1
-- **구현 방안**: git post-commit hook 또는 PreToolUse hook에서 당일 커밋 SHA와 `공유/대화로그/*/YYYY-MM-DD.md` 마지막 수정 시각 비교. 커밋 있는데 대화로그 업데이트 없으면 경고.
-- **비용·리스크**: hook 설치 관리 복잡. 기존 `auto_approve.py`와의 충돌 점검 필요.
-- **분류**: **PM 조율 필요** (hook 체계 전반을 PM이 관리 중).
-
----
-
-## C. 책임 경계 매트릭스 (제안 초안)
-
-| 작업 유형 | 주 책임 기록 주체 | 채널 | 참조(읽기) 주체 |
-|----------|------------------|------|----------------|
-| PD 직접 지시 (개발 범위) | 개발팀장 | PD 지시 로그 | PM·산하 팀장 전원 |
-| 공용 모듈(Framework Core) 변경 | 개발팀장 + 결정로그 | 개발팀→PM 결정로그 + 대화로그 `코어프레임워크/` | 클라이언트팀장·서버팀장·QA |
-| 클라이언트 전용 아키텍처 | 클라이언트팀장 | 대화로그 `클라이언트/`(신설 제안) + PM 보고 시 결정로그 | 개발팀장·QA |
-| 서버 API 스펙 변경 | 서버팀장 (발의) + 클라이언트팀장 (영향 승인) | 양측 결정로그 + `개발팀→기획팀` (기획 영향 시) | PM·QA |
-| QA 테스트 정책 | QA | 대화로그 `QA/`(신설 제안) | 개발팀장·산하 팀장 |
-| Unity 프로젝트 수정 | 수행 에이전트 (클라 또는 기획) | 대화로그 해당 프로젝트 축 + C30 git 점검 기록 | 개발팀장 |
-| 서브모듈·빌드 스크립트 | 수행 에이전트 | 대화로그 `조직운영/` + 커밋 메시지 상세화 | 전원 |
-
-**현재 누락 영역**:
-- QA 전용 로그 채널 (신설 제안 — 개선안 4와 연동)
-- 클라-서버 경계 결정의 양측 기록 강제 (현재는 한쪽만 기록되기 쉬움)
-- Unity 프로젝트 C30 실행 이력 (git fetch 결과를 어디에 기록하는지 미정의)
-
----
-
-## 결론 요지
-
-- **즉시 착수 가능(개발팀장 재량)**: 개선안 3(P22 결정로그 적용), 개선안 6(구 명칭 정리).
-- **PM 조율 필요**: 개선안 1(dev-auditor), 개선안 2(활성 지시 Read 의무), 개선안 4(산하 팀장 대화로그), 개선안 5(책임 매트릭스 SOT), 개선안 7(커밋 hook).
-- **PD님 실질 결정 필요**: 없음. 본 점검 범위 내 모든 개선안은 팀 논의 또는 PM 조율로 결정 가능 (C29).
-
-**최우선 1건 추천**: 개선안 1(dev-auditor)이 A3·A4 구멍 대부분을 구조적으로 해소. pm-auditor 선례로 구현 리스크 낮음.
diff --git a/공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md b/공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md
deleted file mode 100644
index 340cac3..0000000
--- a/공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-type: 점검보고
-from: 기획팀장
-to: PM
-date: 2026-04-17
-topic: 업무공유·기록 체계 전수 점검 — 기획팀 고유 관점
-관련규칙: C13·C23·C27·C29·C30·C31·P19·P22·P23·P24·P26
----
-
-# 업무공유체계 점검 — 기획팀 고유 관점 보고
-
-PD님 2026-04-17 "업무 공유·기록 누락 전수 점검 + 즉시 개선" 지시에 대한 기획팀장 관점 보고. **기획 결정의 휘발성**과 **개발팀 전달 정합성**을 중심축으로 진단한다.
-
----
-
-## A. 현황 실측 (5축)
-
-### A-1. 기록 의무 명확성 — **부분 충족, 기획 고유 공백 존재**
-
-- **잘 커버됨**: PD 지시 로그(P19) + 대화로그(P24) + 결정로그(P22) + 소통 채널 체계는 "의사결정 팩트·진행 상태" 축에서는 정상 가동. 기획팀 PD 지시 로그는 활성 1건·아카이브 27건으로 비교적 건실.
-- **공백 1 — 밸런스 수치 변경 이력**: C6이 "xlsm/csv/json 변경 전 버전 백업"을 명령하나, **실측: 현재 `프로젝트/수상한잡화점/` 하위에 .xlsm/.xlsx/.csv 원본 자산 0건**. 전체 밸런싱은 `.md` 설계 문서와 코드(Assets의 GameManager.cs 등)로만 존재. 즉 "수치 변경 이력" 규칙은 미래 xlsm 편입 시점(#24 PD 직접 승인)까지 **규정만 있고 실 자산 부재**. 현행 `.md` 기반 수치 변경 이력은 **P16 산출물 추적성**에만 의존 중이며, md 변경 이력이 git diff 외 명시 필드로 기록되지 않는다.
-- **공백 2 — 기각안 기록 선택 필드**: P24 엔트리의 "기각안" 필드가 **선택**으로 되어 있어 실제 기록률이 낮다. 기획 영역은 "왜 A안이 아닌 B안을 골랐나"가 차기 프로젝트 참고자산의 핵심인데, 이 축이 휘발된다 (헌법 제1원칙 목표 2 원칙 B 직접 훼손).
-- **공백 3 — 기획→개발 수치 확정 전달 경로**: 기획팀이 수치를 확정하여 개발팀에 전달할 때 **요구서(requirements) 버전 표기·diff 규약이 없다**. 수치 하나 바뀌면 개발팀이 어느 버전 기준인지 판단하기 어렵다.
-
-### A-2. 세션 전환 시 맥락 유지 — **구조적 약점 1건**
-
-- **기획팀장 본인**: 본 세션은 Agent 호출로 기동 — 호출마다 세션이 **새로 시작**되며 직전 세션의 논의 맥락이 프롬프트에 담긴 내용 외 자동 복원되지 않는다. PM이 P21-5B로 대화로그 Read 의무를 지지만, **Agent로 호출된 기획팀장에게는 P21-5B가 적용되지 않는다**(P21-5B는 PM 세션 대상). Agent 호출 시 PM이 맥락을 프롬프트에 담아줘야 하며, 담지 않으면 기획팀장이 이전 결정을 모른 채 응답할 위험 상존.
-- **하위 6종 전문 에이전트(balance/content/level/narrative/system/ux)**: 각자 독립 Agent로 호출될 때, **기획팀 내부 결정 이력**을 자동 수신할 구조가 없다. 기획팀장이 프롬프트에 명시적으로 맥락을 주입해야만 작동. 누락 시 동일 수치를 다르게 제안하는 불일치 리스크.
-
-### A-3. 누락 감지 자동화 — **기획팀 전용 감사 부재**
-
-- `pm-auditor` 에이전트는 PM 업무에 특화 (P26). **기획팀 고유 검증**(밸런스 수치 변경이 버전 백업과 함께 수행됐는지, 기획 결정이 개발팀 요구서에 정합 반영됐는지, P17 배타 조합 7종 위반 여부)은 **감사 주체 부재**.
-- #28 Unity MCP 전환이 "커밋 제목만 반영·본문 문서 미반영" 상태로 누락된 패턴이 기획 영역에서도 재발 가능 (예: 스테이지 수치 조정이 커밋만 되고 밸런싱 전략 문서에 반영 안 되는 케이스).
-- **대안**: `plan-auditor` 에이전트 신설 검토 가치 — 기획팀 고유 감사 영역 3종(밸런스 이력·요구서 정합·P17 배타).
-
-### A-4. 교차 검증 구조 — **기획↔개발 요구서 왕복 구조 부족**
-
-- 현재 `공유/소통/기획팀↔개발팀/` 채널은 존재하나, **요구서(requirements) 포맷이 표준화되어 있지 않다**. #3 Phase 3 HOLD 재개 시점에 "기획이 요구하는 시뮬 입출력 스키마"를 별도 문서로 정리해야 했던 사례가 방증.
-- 기술적 실현성 검증: 기획이 낸 수치가 **개발 관점 3기준(C11 — 자원 효율성·직관성·범용성)과 충돌하는지 사전 체크하는 정형 절차**가 없다. 현재는 개발팀이 구현 착수 후 발견하는 경우가 다수.
-
-### A-5. 책임 분배 — **전문 에이전트 6종의 기록 의무 불명확**
-
-- 기획팀장의 기록 의무는 P19·P22·P24로 명시. 그러나 **system/content/level/narrative/balance/ux 전문가 에이전트 각자의 기록 의무**는 에이전트 정의 파일에 명시되어 있지 않다.
-- 특히 **balance-designer**: 수치 조정 시 C6 백업 의무 주체가 기획팀장인지 balance-designer 본인인지 모호. 현행은 "기획팀장이 위임 시 명시해야 하는" 암묵 규칙.
-
----
-
-## B. 구체 개선안 (5건)
-
-### 안건 1. 기획 기각안 기록 필수화 (P24 개정)
-- **대상**: 기획 영역 결정에 한해 P24 엔트리 "기각안" 필드를 **필수**로 격상
-- **구멍 근거**: 헌법 제1원칙 목표 2 원칙 B — "노하우 인사이트 기록" 핵심은 "왜 그 방향을 버렸나"
-- **구현 방안**: P24 본문에 "기획 결정 엔트리는 기각안 필수" 조항 추가. 기획팀장·6종 전문가 응답 자기검증 항목에 편입
-- **비용**: 토큰 소폭 증가 (엔트리당 1~2줄), 장기 자산 가치로 상쇄
-- **분류**: **팀장 재량 제안 → PM 조율**
-
-### 안건 2. 밸런스 요구서 표준 포맷 신설
-- **대상**: 기획→개발 수치 전달 시 사용하는 표준 요구서 템플릿
-- **구멍 근거**: 현재 md 산문 형태라 버전·diff 추적 어려움. 차기 프로젝트 자산화 대상
-- **구현 방안**: `공유/소통/기획팀→개발팀/` 하위에 요구서 템플릿(`REQ-템플릿_밸런스수치.md`) 신설. 필수 필드 — `요구서ID`·`기준버전`·`변경 필드 목록`·`변경 전후 수치`·`재미 근거(C7)`·`개발 관점 우려 예상(C11)`·`검증 방법`
-- **비용**: 템플릿 1회 작성, 이후 복사 사용
-- **분류**: **팀장 재량 즉시 착수**
-
-### 안건 3. plan-auditor 에이전트 신설 (기획팀 고유 감사)
-- **대상**: 기획팀 업무·산출물 감사 전담 에이전트
-- **구멍 근거**: pm-auditor는 PM 전담. 기획 고유 감사 3영역(밸런스 이력 백업·요구서 정합·P17 배타 조합) 감사 주체 부재
-- **구현 방안**: `.claude/agents/plan-auditor.md` 신설. 감사 모드 3종 (응답 직전 교차검증·주기 감사·주제 집중 감사). 산출물은 `공유/소통/plan-auditor→기획팀장/`
-- **비용**: 에이전트 1종 추가. pm-auditor와 중복 방지를 위해 감사 영역 분담 명확화
-- **분류**: **PM 조율 필요** (에이전트 신설은 조직 구조 변경)
-
-### 안건 4. Agent 호출 시 기획팀장 맥락 주입 프로토콜
-- **대상**: PM이 기획팀장 Agent 호출 시 준수 규약
-- **구멍 근거**: A-2 — Agent로 호출된 기획팀장에게 P21-5B가 적용 안 됨. 이전 세션 결정 맥락 자동 복원 불가
-- **구현 방안**: PM이 기획팀장 호출 시 프롬프트에 **필수 3종 포함**: (가) 관련 활성 PD 지시 로그 항목 요약 (나) 최근 2일 대화로그 중 기획 관련 엔트리 요약 (다) 관련 기존 산출물 파일 경로. PM 프롬프트 체크리스트에 본 항목 추가
-- **비용**: 호출당 프롬프트 소폭 증가. 맥락 단절 비용 대비 이득
-- **분류**: **PM 조율 필요** (PM 측 프로토콜이므로)
-
-### 안건 5. 전문가 에이전트 6종 기록 의무 명시
-- **대상**: balance/content/level/narrative/system/ux-designer 에이전트 정의 파일
-- **구멍 근거**: A-5 — 각자의 C6·P16·P24 주체 모호. 특히 balance-designer의 수치 변경 백업 의무 주체 불명
-- **구현 방안**: 각 에이전트 frontmatter 직후 "기록 의무" 섹션 6~8줄 추가. balance는 C6 백업 주체·P24 엔트리 기각안 필수, content/level은 P17·P18, ux는 P18 설계 문서화 등 영역별 특화
-- **비용**: 6개 파일 간단 추가
-- **분류**: **팀장 재량 즉시 착수**
-
----
-
-## C. 기획 특수 요구 (개발팀과 차별)
-
-### C-1. 밸런스 수치 변경 이력 기록 체계
-- **현 상태**: xlsm 원본 부재로 C6 규정 미작동. md 기반 수치는 git diff 외 명시 이력 없음
-- **요구**: 밸런싱 관련 md(`스테이지난이도곡선_v1.md`·`밸런싱전략_v1.md` 등) 파일 하단에 **변경 이력 테이블** 섹션 표준화 — `일시 / 변경자 / 변경 필드 / 이전값→이후값 / 재미 근거 / 관련 PD 지시#`
-- **차기 프로젝트 xlsm 편입 시점**: #24에서 확정된 "외부 SOT 유지 + 버전 태그 백업" 운영 규약을 그대로 적용. 현행 md 이력이 선행 학습 자료
-- **구현**: 밸런싱 md 4개 파일(난이도곡선·밸런싱전략·전체테이블감사·빌드충돌점검)에 변경 이력 섹션 표준 추가 — **팀장 재량 즉시 착수**
-
-### C-2. 기획 의도·근거 장기 보존 (헌법 제1원칙 목표 2 원칙 B 직결)
-- **현 상태**: P24 기각안 필드가 선택이라 "왜 이 방향을 안 골랐나" 손실 위험
-- **요구**: 기획 결정(밸런스·시스템·컨텐츠 방향)은 **채택안과 기각안 2종 이상을 쌍으로** 기록. 차기 프로젝트에서 "우리가 이미 검토하고 버린 안"을 재검토하는 중복 작업 차단
-- **장기 보존 경로**: `공유/대화로그/` + `memory/` + `공유/조직공지/`가 모두 git 추적 대상이므로 PC 독립 최신화 유지(목표 1)와 자연 정합
-- **구현**: 안건 1(기각안 필수화)과 연동
-
-### C-3. 기획 결정의 개발팀 전달 정합성 (#28 재발 방지)
-- **#28 패턴**: 커밋 제목만 반영되고 본문 문서 미반영 → 다른 팀·PM이 완료 인지 실패
-- **기획 영역 재발 위험**: 기획이 확정한 수치가 개발 요구서에 반영 안 된 채 "확정됨"으로 분류될 수 있음
-- **차단 메커니즘**: 안건 2(요구서 표준 포맷) + 안건 3(plan-auditor)로 이중 차단. 요구서 발행 시 **반드시 대화로그·PD 지시 로그 동시 갱신** 규약 편입
-
----
-
-## D. 우선순위 권고
-
-1. **팀장 재량 즉시 착수 (3건)**: 안건 2(요구서 템플릿) · 안건 5(전문가 에이전트 기록 의무 명시) · C-1(밸런싱 md 변경 이력 섹션 표준화) — 본 보고 수령 직후 기획팀장 자체 진행
-2. **PM 조율 필요 (2건)**: 안건 3(plan-auditor 신설) · 안건 4(Agent 호출 맥락 주입 프로토콜) — PM과 개발팀장·pm-auditor 의견 수렴 후 결정
-3. **규칙 개정 (1건)**: 안건 1(P24 기획 기각안 필수화) — PM 조율 후 P24 본문 수정
-
----
-
-## E. 기획팀장 자체 검증
-
-본 점검 수행 중 준수 확인:
-- C23 (허위 보고 금지): A-1 "xlsm 0건"은 `find` 실측 결과 기반, 추정 아님
-- C29 (자율 수행): PM 결정 떠넘기기 없이 팀장 재량 3건 자체 분류
-- C25 (넘버링): 1./A./가) 위계 선순 적용 — 본 보고는 안건 1~5 + A-1~5 + C-1~3 모두 단일 위계 유지
-- C22 (용어 일관): P24·C6·C11·P17 등 기존 식별자 그대로 재사용
-
-본 보고는 대화로그(`공유/대화로그/조직운영/2026-04-17.md`)에 엔트리 추가 대상이며, 기획팀장 본 응답 종료 후 이어 기록 예정.
diff --git a/공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md b/공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md
deleted file mode 100644
index f8596bc..0000000
--- a/공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-from: 서버팀장
-to: PM
-date: 2026-04-17
-type: 점검보고
-status: 완료
-tags: [업무공유체계, 서버팀, 예방체계, DevOps, 재해복구]
-related: [C8, C13, C27, C29-4, C30, P26]
----
-
-# 업무 공유·기록 체계 점검 — 서버팀 관점
-
-> **전제**: 서버팀은 현재 활성 작업이 없음 (#2 서버 Critical 보안 3건 보류 중, 재개 트리거: 서버 파트 정비 완료 통보). 본 점검은 **서버 재개 시점에 사각지대가 드러나지 않도록 예방 체계** 구축을 중심으로 한다.
-
----
-
-## A. 현황 실측 — 서버·운영 영역 미비점
-
-### A-1. 서버 특수 기록 채널 부재
-현재 조직 기록 체계는 **기획·개발 문서 작업 중심**으로 구축되어 있다. 서버·운영이 재개되면 다음 기록 유형이 기존 채널(대화로그·PD 지시 로그)만으로는 **추적 불가능**하다:
-
-1) **배포 이벤트** — 언제·어디에(dev/staging/prod)·무엇을·누가 배포했는가. 현재 P24 대화로그 자유 태그로는 배포 이력 교차 검색 불가
-2) **DB 스키마 마이그레이션 이력** — 마이그레이션 스크립트 적용 순서·롤백 가능성·데이터 영향 범위. C6 백업 의무의 서버 DB 버전
-3) **장애·인시던트 기록** — 탐지 시각·영향 범위·조치·RCA(Root Cause Analysis)·재발 방지책. 현재 `🚨_*` 공지는 *알림*용이지 *회고*용이 아님
-4) **API 계약 변경 이력** — Breaking Change 여부·클라이언트 영향·하위 호환 기간. P13 "공용 인터페이스 변경 시 사전 공유" 의무의 실행 채널 부재
-
-### A-2. DevOps 자동화 hook 공백
-`.claude/settings.json` 확인 결과, 현재 설치된 hook은 **PreToolUse·SessionStart·UserPromptSubmit 3종**. 서버 재개 시 필요한 hook이 누락:
-
-1) **PostToolUse** 미설치 — Edit/Write 후 자동 linter·검증이 돌지 않음. 서버 코드·config 수정 시 syntax 오류가 다음 턴까지 검출되지 않는 리스크
-2) **SessionEnd** 미설치 — 세션 종료 시점의 미완료 작업 자동 정리·대화로그 강제 작성이 에이전트 자율에 맡겨져 있음 (C31 자기검증 의존)
-3) **Stop** hook 미설치 — 에이전트 응답 완료 직후 PD 지시 로그·Live 더미 동기화 상태 검증 자동화 부재 (C27 수동 의존)
-
-### A-3. 재해 복구 체계 부재
-조직의 모든 자산이 git 단일 SOT(`BurningTimesAi` 레포)에 집중. 다음 리스크 대응 미비:
-
-1) **원격 저장소 장애 시 SOT 소실 가능성** — GitHub 장애·계정 사고 시 모든 기록 접근 불가. 로컬 클론이 유일한 백업인데 PC별 sync 주기에 따라 불균등
-2) **대화로그·메모리 백업 정책 부재** — `공유/대화로그/`·`memory/` 가 레포와 운명 공동체. 별도 snapshot·스토리지 동기화 미구현
-3) **감사 추적 요구 대응 불가** — "누가 언제 어떤 결정을 했는가"는 git blame·대화로그로 재구성 가능하나, **tamper-proof** 보장 없음 (force push로 history rewrite 가능, C19-2가 방어선이지만 사후 검증 메커니즘 부재)
-
-### A-4. 민감 정보 누출 위험 채널 미정의
-조직이 단일 세션 + 전 파일 공유 구조. 서버 재개 시 발생할 민감 정보(DB 크레덴셜·API 키·서명키·개인정보) 기록 위치가 사전 정의되지 않음. `.gitignore` 기반 제외는 있으나 **"기록하면 안 되는 것" 명시 가이드 부재**.
-
----
-
-## B. 구체 개선안 (3단 위계 — 팀장 재량 / PM 조율 / PD님 결정)
-
-### B-1. 팀장 재량 범위 (즉시 착수 가능, PM 합의 시 진행)
-
-1) **서버 운영 기록 채널 디렉토리 신설** — `공유/운영기록/` 하위에 `배포/`·`DB_마이그레이션/`·`인시던트/`·`API_변경/` 4개 서브디렉토리. 파일명 규칙 `YYYY-MM-DD_<환경>_<요지>.md`. C14-2 변동비 유지 (on-demand 참조)
-2) **인시던트 기록 템플릿 정의** — `공유/운영기록/인시던트/_TEMPLATE.md`. 필드: 탐지 시각·영향 범위·타임라인·조치·근본 원인(C2)·재발 방지책·관련 커밋. 장애 종료 시점 필수 작성
-3) **API 변경 영향 분석 체크리스트** — P13 의무의 서버 측 구체화. Breaking Change 판정 기준·클라이언트 공지 전 필수 확인 항목
-
-### B-2. PM 조율 필요 (양팀 영향·hook 추가)
-
-1) **PostToolUse·SessionEnd hook 신설 논의** — `.claude/settings.json` 수정은 조직 전체 영향. PM·개발팀장·기획팀장 합의 후 `scripts/post_tool_validate.sh`·`scripts/session_end_sync.sh` 추가. 효과: C27(Agent 호출 완료 시 로그 갱신 확인)·C29-4(완료 동기화) 자동화
-   - A. `post_tool_validate.sh`: Edit/Write 후 `.live/` 미반영분 감지 시 경고 출력
-   - B. `session_end_sync.sh`: 당일 대화로그 부재·활성 지시 중 갱신 누락 감지 시 경고
-2) **민감 정보 기록 금지 가이드라인** — `공유/조직공지/2026-XX-XX_민감정보_기록금지_가이드.md` 발행 협의. `.gitignore` 대상 + 기록 허용 대체 채널(환경변수·비밀 관리자) 명시
-3) **서버 재개 체크리스트 사전 작성** — #2 재개 트리거 발동 시 즉시 적용할 온보딩 체크리스트. 위 B-1·B-2 항목 + `memory/org/` 선행 검토 + Critical 보안 3건 인수인계
-
-### B-3. PD님 결정 필요 (헌법급·외부 영향)
-
-1) **재해 복구 전략 수립** — 조직 레포 원격 이중화(GitHub + NAS 또는 자가 Gitea) 여부. C8 프로덕션 보호 정신의 *조직 기록 자산* 버전. 비용·운영 부담 때문에 PD님 결정 사안
-2) **감사 추적 tamper-proof 수준 결정** — git history rewrite 금지 정책(signed commits 강제·branch protection 강화) 도입 여부. 현재 C19-2가 정성적 방어, 정량적 기술 방어는 PD님 결정
-
----
-
-## C. 서버 재개 시 예비 제안 (#2 재개 트리거 발동 대비)
-
-서버 Critical 보안 3건 재개 시 **선행 필수**:
-
-1) **인수인계 패키지 Read 순서 고정** — 재개 시점의 서버팀장이 반드시 Read할 문서 순서를 예비 정의
-   - A. `공유/대화로그/수상한잡화점/` 중 `#서버` 태그 검색
-   - B. `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 완료 아카이브에서 서버 관련 항목 전수
-   - C. `memory/org/feedback_*.md` 중 서버·보안·C8 관련 피드백
-2) **Critical 3건 착수 전 체크포인트 기록** — 착수 시점의 서버 상태 스냅샷(버전·config·현재 취약점 범위)을 `공유/운영기록/인시던트/` 또는 별도 `보안점검/`에 기록. 롤백 기준선 확보
-3) **클라이언트·기획팀 동기화 사전 통보** — P13 준수. 서버 Critical 수정은 API·데이터 포맷 영향 가능성 있음. 양팀에 **변경 범위 사전 공유 → 협의 → 수정 착수** 순서 고정
-4) **Live 더미 적극 활용** — 서버 관련 `.live/` 더미 파일이 현재 없음. 서버 재개 시 설정·regex 변경을 Live 더미에 즉시 기록하여 다른 세션 실시간 추적 보장 (P25)
-
----
-
-## D. 요약
-
-| 분류 | 건수 | 긴급도 |
-|------|------|--------|
-| A. 현황 미비점 | 4건 (서버 특수 채널·hook 공백·재해 복구·민감 정보) | 예방 — 서버 재개 전 해결 권장 |
-| B-1. 팀장 재량 | 3건 (기록 채널·인시던트 템플릿·API 체크리스트) | PM 합의 즉시 착수 가능 |
-| B-2. PM 조율 | 3건 (hook 신설·민감정보 가이드·재개 체크리스트) | 양팀 합의 필요 |
-| B-3. PD님 결정 | 2건 (재해 복구·감사 추적) | 비용·정책 수반 |
-| C. 재개 예비 | 4건 | 트리거 발동 시 즉시 적용 |
-
-**핵심 관점**: 서버팀은 활성 작업 부재 중이지만, **재개 시점의 사각지대는 이미 발생 중**. 기록 채널·자동화 hook·재해 복구는 재개 후에 급하게 만들면 C8·C13 위반 리스크 상승. C29 자율 수행 정신에 따라 팀장 재량 범위(B-1)는 PM 합의 후 즉시 착수 제안.
-
-**서버팀장 자체 다짐**: C23·C29·C30 준수. 본 보고는 병행 호출된 개발팀장·기획팀장·클라이언트팀장·pm-auditor 보고와 교차 검증되어 PM이 통합 판단할 자료.
diff --git a/공유/소통/완료/2026-04-17_업무공유체계_점검_클라이언트팀.md b/공유/소통/완료/2026-04-17_업무공유체계_점검_클라이언트팀.md
deleted file mode 100644
index 60b308d..0000000
--- a/공유/소통/완료/2026-04-17_업무공유체계_점검_클라이언트팀.md
+++ /dev/null
@@ -1,232 +0,0 @@
----
-type: 점검보고
-from: 클라이언트팀장
-to: PM
-date: 2026-04-17
-status: 진행중
-tags: [#자율작업, #개발, #진행중, #자동화설계, #업무공유체계]
----
-
-# 업무공유체계 전수 점검 — 클라이언트팀장 (기술 자동화 관점)
-
-## A. 현황 실측 (hook·script·settings.json schema)
-
-### A-1. 실측 결과
-1. **`.claude/hooks/` 디렉토리**: **부재**. hook은 `scripts/` 루트에 bash 스크립트로 배치 후 `.claude/settings.json`의 `hooks.*.command`에서 직접 참조하는 구조.
-2. **현재 등록 hook 5종 (settings.json)**:
-   - `PreToolUse`: `scripts/auto_approve.sh` (권한 자동 승인)
-   - `SessionStart` × 5: `git fetch+merge`(인라인), `inbox_scan.sh`, `change_digest.sh`, `live_session_load.sh`, `pm_context_restore.sh`
-   - `UserPromptSubmit` × 3: `git_fetch_throttle.sh`, `hold_watch.sh`, `live_inject.sh`
-3. **미등록 hook 타입**: `PostToolUse`·`SessionEnd`·`SubagentStart`·`SubagentStop` 는 **현 settings.json에 전혀 등록되지 않음**. Claude Code 최신 schema 상 `PostToolUse`·`SessionEnd` 는 지원 확인됨 (등록만 하면 동작).
-4. **`scripts/` 현존 14종**: `agent_sync.sh`·`auto_approve.sh(+py)`·`change_digest.sh`·`context_brief.sh`·`git_fetch_throttle.sh`·`hold_watch.sh`·`inbox_scan.sh`·`live_inject.sh`·`live_session_load.sh`·`nas_post_receive.sh`·`pm_context_restore.sh`·`stale_check.sh`·`verify_setup.ps1`.
-5. **검증 스크립트 부재 항목**: `verify_log_paths.sh`(PD 지시 로그 산출물 경로 실존 검증) — **미구현** (pm-auditor I1 제안).
-
-### A-2. 팀 관점 기록 누락 리스크 (실측 기반)
-1. **#28 Unity MCP 전환 사례**: 커밋 `db64310` 제목에 "시뮬레이션 MCP 전환"이 1줄 포함되었으나, 대화로그 `2026-04-17.md`·`공유/소통/PM→개발팀/`에 기술 배경·대안 비교·의사결정 근거 문서가 **연결되지 않음**. 활성 지시 테이블 비고란에 "2026-04-17 Unity MCP 방향으로 전환"만 추가되어, 다른 세션에서 **"왜 전환됐는지" 복원 불가**.
-2. **`공유/소통/개발팀→PM/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`** 는 생성됨 — 단, 이 문서가 #28 로그의 산출물 경로 컬럼에 **추가 기재되었는지 교차 확인 필요**(PM 점검 권고).
-3. **공용 모듈·인터페이스 변경 시 사전 공유(P13)** 자동 감지 메커니즘 **없음**. `코어코드/BT.Framework/Runtime/**` 변경은 클라이언트·차기 프로젝트에 직접 영향이나, 현재 **수동 공유에만 의존**.
-
----
-
-## B. 기술 자동화 개선안 구체 설계 (최우선)
-
-### B-1. `scripts/verify_log_paths.sh` 설계안 (pm-auditor I1 대응)
-
-**목적**: PD 지시 로그 활성 테이블에 기재된 `산출물 경로` 컬럼의 모든 파일·디렉토리 경로가 실존하는지 자동 검증. 존재하지 않는 경로(유령 문서, 이동·삭제 후 갱신 누락) 즉시 감지.
-
-**호출 시점**: `SessionStart` hook 말미 + `UserPromptSubmit` 주기 실행(예: `git_fetch_throttle.sh`와 같은 throttle 적용). 매 턴 실행은 과도 → 1시간 throttle 권장.
-
-**의사코드** (bash):
-```bash
-#!/bin/bash
-# scripts/verify_log_paths.sh — PD 지시 로그 산출물 경로 실존 검증
-# 근거: pm-auditor I1, C13·P18·P19·C29-4
-REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null) || exit 0
-cd "$REPO_ROOT" || exit 0
-
-THROTTLE_FILE="/tmp/verify_log_paths.last"
-NOW=$(date +%s)
-LAST=$(cat "$THROTTLE_FILE" 2>/dev/null || echo 0)
-[ $((NOW - LAST)) -lt 3600 ] && exit 0   # 1시간 throttle
-echo "$NOW" > "$THROTTLE_FILE"
-
-MISSING=0
-for LOG in 공유/PD_지시_트래킹/*_PD_지시_로그.md; do
-  # "## 활성 지시" ~ "## 완료 아카이브" 범위만 추출
-  awk '/^## 활성 지시/,/^## 완료 아카이브/' "$LOG" | \
-  # 테이블 행의 "산출물 경로" 컬럼(4번째 |) 추출
-  grep -oE '`[^`]+\.(md|cs|json|csv|xlsm|xlsx|txt|sh|py|ps1)`|`[^`]+/`' | \
-  tr -d '`' | sort -u | while read PATH_CANDIDATE; do
-    # 상대경로·절대경로·글롭 분기
-    [ -z "$PATH_CANDIDATE" ] && continue
-    case "$PATH_CANDIDATE" in
-      /*) FULL="$PATH_CANDIDATE" ;;
-      *) FULL="$REPO_ROOT/$PATH_CANDIDATE" ;;
-    esac
-    if [ ! -e "$FULL" ] && [ ! -d "$FULL" ]; then
-      echo "⚠️ [verify_log_paths] MISSING: $LOG → $PATH_CANDIDATE"
-      MISSING=$((MISSING+1))
-    fi
-  done
-done
-
-[ "$MISSING" -gt 0 ] && echo "🚨 PD 지시 로그 산출물 경로 ${MISSING}건 실존 확인 실패 (PM 확인 필요)"
-exit 0
-```
-
-**리스크 및 비용**:
-1. 한글 경로·글롭 패턴(예: `Runtime/Core/**`) 파싱이 bash에서 까다로움 — `**` 는 `ls -d` 로 별도 처리 필요.
-2. 복합 산출물 비고란(예: "A 완료분 + B 완료분" 멀티 경로)의 파싱 품질이 핵심 — 정규식 튜닝 필요.
-3. **구현 비용**: 스크립트 자체는 작으나 기존 로그 형식 편차 흡수에 테스트 라운드 필요.
-4. **오탐 리스크**: 이동된 경로·일시 미생성 경로로 false positive 가능 → 상태 `완료`인 항목만 검증 대상으로 좁히는 것이 안전.
-
-### B-2. 신규 hook 제안 2종
-
-#### B-2-1. `PostToolUse` hook — md 대규모 변경 시 대화로그 엔트리 리마인더
-**목적**: Edit/Write 로 `.md` 파일을 100줄 이상 수정한 직후, 당일 대화로그에 관련 엔트리가 있는지 감지하여 부재 시 리마인더. P24 누락을 **사후 즉시 감지**.
-
-**settings.json 추가**:
-```json
-"PostToolUse": [
-  {
-    "matcher": "Edit|Write|MultiEdit",
-    "hooks": [
-      {"type": "command", "command": "bash scripts/postuse_log_reminder.sh 2>/dev/null || true"}
-    ]
-  }
-]
-```
-
-**스크립트 초안** (`scripts/postuse_log_reminder.sh`):
-```bash
-#!/bin/bash
-# PostToolUse: md 대규모 변경 감지 → 당일 대화로그 존재 여부 확인
-REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null) || exit 0
-cd "$REPO_ROOT" || exit 0
-
-# 최근 5분 내 수정된 .md 중 100줄 이상 diff
-RECENT_BIG=$(git diff --stat HEAD 2>/dev/null | \
-  awk '$1 ~ /\.md$/ && ($3+0)>=100 {print $1}')
-[ -z "$RECENT_BIG" ] && exit 0
-
-TODAY=$(date +%Y-%m-%d)
-HAS_LOG=0
-for DIR in 공유/대화로그/*/; do
-  [ -f "${DIR}${TODAY}.md" ] && HAS_LOG=1 && break
-done
-if [ "$HAS_LOG" -eq 0 ]; then
-  echo "⚠️ [postuse] md 대규모 변경 감지되었으나 당일 대화로그 부재 — P24 작성 권고"
-  echo "   변경 파일: $RECENT_BIG"
-fi
-exit 0
-```
-
-**리스크**:
-1. Edit/Write 매 호출마다 `git diff --stat` 는 비용 있음 — throttle(10초) 권장.
-2. 매우 큰 작업 중 과도 출력 → `stderr` 로 전환 또는 부재 최초 1회만 출력.
-
-#### B-2-2. `SessionEnd` hook — 세션 종료 시 기록 누락 최종 감사
-**목적**: 세션 종료 직전 (a) 당일 대화로그 부재 (b) 활성 지시 상태 변화 있었으나 갱신 누락 (c) `.live/` 더미 미반영분 감지 → 경고 출력.
-
-**settings.json 추가**:
-```json
-"SessionEnd": [
-  {
-    "matcher": "",
-    "hooks": [
-      {"type": "command", "command": "bash scripts/session_end_audit.sh 2>/dev/null || true"}
-    ]
-  }
-]
-```
-
-**스크립트 요지**:
-1. 당일 `공유/대화로그/*/$(date +%Y-%m-%d).md` 존재 여부.
-2. `.live/` 중 README.md 외 파일 존재 여부(미반영 의심).
-3. 당일 커밋 건수 vs 대화로그 엔트리 건수 대략 비교.
-4. **모드 B 감사 자동 트리거 신호**: pm-auditor 호출 권고 메시지 출력.
-
-**리스크**: SessionEnd 는 사용자가 세션을 실제 종료한 시점에만 발화 — 앱 강제 종료·충돌 시 미발화 가능성. 100% 강제 메커니즘은 아니므로 SessionStart 의 복원 체크(`pm_context_restore.sh`)와 **쌍으로 운용** 필요.
-
-### B-3. `SubagentStart`/`SubagentStop` hook 가능성 검토
-1. **현 Claude Code schema**: 표준 hook 타입에 `SubagentStart`·`SubagentStop` 은 **공식 등록 항목 아님** (2026-04-17 기준 확인). `Task` 도구 호출·응답은 `PreToolUse`·`PostToolUse` 에서 `matcher: "Task"` 로 포착 가능.
-2. **대체 설계**: `PostToolUse` matcher `"Task"` 로 Agent 호출 종료 감지 → 해당 Agent 가 응답에 "PD 지시 로그 #N → 완료 갱신" 문구 포함 여부 자동 스캔 → 부재 시 PM 경고. **C27 강제 메커니즘 구현 가능**.
-3. **구현 비용**: Agent 응답 본문은 hook stdin 으로 들어오므로 jq 파싱 필요. Windows bash 환경에서 jq 설치 여부 선결 확인.
-
-### B-4. 커밋-대화로그 정합성 자동 감지 (#28 재발 방지)
-**목적**: `feat(core):`·`feat(client):`·`refactor:` 등 **의미 있는 prefix** 의 커밋이 당일 발생했으나 대화로그에 관련 엔트리 부재 시 감지.
-
-**구현 위치**: `scripts/session_end_audit.sh` 내부 또는 별도 `scripts/commit_log_match.sh`.
-
-**로직**:
-```bash
-# 당일 feat/refactor/fix(core) 커밋 추출
-BIG_COMMITS=$(git log --since="$(date +%Y-%m-%d) 00:00" --oneline | \
-  grep -E "^\w+ (feat|refactor|fix\(core\)|feat\(core\))")
-# 대화로그 엔트리 개수
-LOG_ENTRIES=$(grep -c "^## \[" 공유/대화로그/*/$(date +%Y-%m-%d).md 2>/dev/null | \
-  awk -F: '{s+=$2} END{print s+0}')
-# 커밋 2건 이상인데 엔트리 1건 이하면 경고
-```
-
-**리스크**: 커밋 1건이 여러 엔트리에 대응 또는 그 반대 — 정확한 1:1 매칭은 어려움. **비율 기반 경고**로 설계 (완벽 매칭 아님, 누락 의심 신호 수준).
-
----
-
-## C. 비기술적 개선안 (코드 변경 기록 체계)
-
-### C-1. 커밋 메시지·대화로그 연동 표준 (팀장 재량 수용 가능)
-1. **제안**: 의미 있는 기술 결정이 포함된 커밋(`feat(core):`·`refactor:` 등)은 **커밋 메시지 하단에 `Log: 공유/대화로그/<프로젝트>/YYYY-MM-DD.md#HH:MM` 형식 참조 라인 필수**.
-2. **권한**: 팀장 재량 (C20-1 일반 커밋 범위). PM 상의만 거치면 즉시 적용 가능.
-
-### C-2. 공용 모듈 변경 사전 공유 자동화 (PM 조율 필요)
-1. **제안**: `코어코드/BT.Framework/Runtime/**`·`Editor/**` 수정 시 `PreToolUse` hook 이 **변경 사실을 `공유/소통/개발팀→기획팀/`·`개발팀→PM/` 에 draft 로 append** (수동 보완 전제).
-2. **권한**: PM 조율 필요 — 타 팀(기획팀·서버팀) 통보 자동화는 팀 간 합의 필요.
-
-### C-3. 설계 문서화 누락 감지 (팀장 재량)
-1. **제안**: 코어 프레임워크 디렉토리에 신규 `.cs` 파일 추가 시 `프로젝트/코어프레임워크/` 에 대응 설계 문서(`*_설계_*.md`) 존재 여부 자동 확인. 부재 시 P18 위반 경고.
-2. **권한**: 팀장 재량, 개발팀 내부 규약 수준.
-
-### C-4. PD님 결정 필요 사안 (본 보고 범위 아님)
-- 본 점검은 기술 자동화 설계 중심. PD님 직접 결정이 필요한 헌법급 규칙 개정(예: C31 에 "PostToolUse 자동 감사" 의무 포함 여부)은 **PM이 팀장 논의 종합 후 안건화** 판단.
-
----
-
-## D. 클라이언트팀 세션 맥락 유지 방안 (자체 관점)
-
-1. **자기 세션 맥락**: 클라이언트팀장은 Agent 호출마다 새로 인스턴스화되며, 직전 호출 기억 없음 → **응답 시 반드시 실측 결과만 보고**(C23). 필요 시 PM 프롬프트에 "이전 호출 산출물 경로" 명시 요청.
-2. **기술 스택 변경 이력**: `.mcp.json`·`Packages/manifest.json`·`코어코드/BT.Framework/Runtime/**` 변경은 **커밋 메시지 + 대화로그 + `공유/소통/개발팀→PM/` 보고 3중 기록** 원칙 제안 (팀장 재량).
-3. **의존성 변경**: Unity 패키지·코어 프레임워크 버전 업은 P15(의존성·환경 변경 공유) 준수 — 현재 자동 감지 없음, `PostToolUse` hook 으로 `manifest.json` 수정 시 경고 추가 권장.
-
----
-
-## E. 우선순위 권고 (기술 관점)
-
-1. **즉시 착수 권장 (구현 비용 낮음·효과 큼)**:
-   - B-1 `verify_log_paths.sh` (pm-auditor I1 대응, 본 팀 작성 가능)
-   - B-2-1 `PostToolUse` md 대규모 변경 리마인더
-2. **PM 조율 필요**:
-   - B-2-2 `SessionEnd` hook + pm-auditor 자동 호출 연계
-   - B-4 커밋-대화로그 정합성 감지
-3. **타 팀 합의 필요**:
-   - C-2 공용 모듈 변경 타 팀 자동 통보
-4. **보류 (schema 확인 필요)**:
-   - B-3 Subagent hook — Claude Code schema 추가 조사 후 재검토
-
----
-
-## F. 차단 요인
-
-1. **없음** — 본 점검은 실측 + 설계안 수준. 구현 착수는 PM 조율 후.
-2. **주의**: B-1~B-2 실제 구현 시 Windows Git Bash 환경 테스트 필수 (한글 경로·jq 가용성 등).
-
----
-
-## G. 산출물 경로
-- 본 문서: `공유/소통/개발팀→PM/2026-04-17_업무공유체계_점검_클라이언트팀.md`
-
-## H. 제약 준수 선언
-- **C23**: 모든 실측은 Bash 도구 호출 결과 기반 (hook 부재·script 14종·settings.json 본문).
-- **C29**: 단일 의사결정 요청 없음. 각 개선안에 팀장 재량/PM 조율/PD님 결정 구분 명시.
-- **C30**: 본 점검은 조직 레포 내 문서 작성 — git 상태 영향 없음.
-- **C31**: PD님 결정 떠넘기기 표현 부재. "어떻게 할까요?" 없음. 자체 설계안 제시형 작성.
diff --git a/공유/소통/완료/2026-04-17_업무현황_개발팀.md b/공유/소통/완료/2026-04-17_업무현황_개발팀.md
deleted file mode 100644
index 4b44549..0000000
--- a/공유/소통/완료/2026-04-17_업무현황_개발팀.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-from: 개발팀장
-to: 총괄PM
-type: 상태보고
-subject: 개발팀 업무현황 보고 — 2026-04-17
-priority: normal
-status: 대기
-created: 2026-04-17
----
-
-# 개발팀 업무현황 보고 — 2026-04-17
-
-pm-auditor Major M2 후속 조치 (`2026-04-16_업무현황_개발실.md` DEPRECATED → 2026-04-17 최신 현황 신규 작성). 실측 기준 (C23 준수 — tool_use 결과로 입증된 것만).
-
-## 1. 활성 지시 현황 (PD 지시 로그 기준, 4건)
-
-| # | 지시 요지 | 상태 | 핵심 |
-|---|----------|------|------|
-| **#28** | 기획팀 밸런스 작업용 시뮬레이션 대응 (Unity MCP 방향 전환) | 진행중 | Unity MCP 기반 기술검토 완료. Phase 3 재개 로드맵 PD님 논의 대기. Python 시뮬 소실 확정 → 교차 검증 축 Unity MCP 단일로 확정 |
-| **#1** | BurningTimesCore 퇴사 대응, 자체 범용 코어 신규 제작 | 진행중 | Tier 1 Core 4종 완료 (Log·CoroutineRunner·MonoSingleton·ServiceLocator + 테스트 28건). 구 `개발팀/코어_설계/` 흡수 판정 완료 (2026-04-17). **Tier 1 잔여 9종 미착수 (차단 요인 없음)** |
-| **#5** | (3대 지시) A. Framework Tier 1, B. Phase 0-B/C, C. PM 보고 | 진행중 | A 일부 완료 (Core 4종), B-1/B-2/B-3 완료 (08·09·10 문서), C 완료. **Tier 1 잔여 9종 + Phase 0-C(Q-P1/P2/P3 응답서·시뮬레이터 전략) 미착수** |
-| **#2** | 서버 Critical 보안 3건 | 보류 | 서버 파트 정비 미완료 (PD님 지시). 재개 트리거: 서버팀 가동 시점 |
-
-## 2. 즉시 착수 가능 작업 (차단 요인 없음)
-
-1. **Tier 1 잔여 9종 구현** (#1·#5A 겹침) — EnumToInt·EnumEx·FormatEx 등. OI-2 C+H1 배포방식 승인 완료(`7187ac6`), 네임스페이스 확정, 설계 문서 존재. **외부 차단 요인 없음**. 즉시 착수 가능
-2. **Phase 0-C Q-P1/P2/P3 응답서·시뮬레이터 전략 문서화** (#5B 잔여) — 시뮬레이터 전략은 Unity MCP 방향으로 확정되었으므로, Phase 0-C 스코프 재정의 후 문서화 가능
-
-## 3. 차단 요인 있는 작업
-
-1. **#28 시뮬레이션 Phase 3 재개** — PD님이 Phase 3 재개 로드맵을 별도 논의 예정으로 언급하심. 재개 트리거: PD님 Phase 3 재개 논의 결과 통보. 07_v2·11·12 문서 신설 착수도 동 트리거에 종속
-2. **#2 서버 Critical 보안 3건** — 서버팀 가동이 PD님 지시로 정지된 상태. 재개 트리거: 서버 파트 정비 완료 통보
-
-## 4. PD님 결정 대기 항목 (C29 엄격 해석)
-
-**없음.** 개발팀 재량 또는 팀 자율 논의로 처리 가능한 범위에 한정하여 검토한 결과:
-
-- **#28 Phase 3 재개 시점**: PD님이 이미 "별도 논의 예정"으로 명시하셨으므로 이는 PD님 주도 항목, 개발팀에서 되묻지 않음
-- OI-2 C+H1 승인, C17-3·#17·#12 실효 처리, 헌법 제1원칙 목표 2 해석 등 과거 대기 항목은 모두 해소됨 (pm-auditor 감사에서 확인)
-
-## 5. 2026-04-17 주요 변경 요약
-
-1. pm-auditor Critical C1 해소 — PD 지시 로그 #1 산출물 경로 실측 정정 (구 `개발팀/코어_설계/` 3건 흡수 완료 판정, 본 보고서와 동시 수행)
-2. #28 Unity MCP 방향 전환 기술검토 완료 (`2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`)
-3. 헌법 제1원칙 목표 2 해석 확정 — "코어 프레임워크 차기 프로젝트 활용" (Unity 전제 무관)
-
-## 6. 개발팀 권고 (PM 자율 처리 요청 사항)
-
-- **Tier 1 잔여 9종 구현 착수**는 팀 재량 범위 내이므로 PM 승인 즉시 진행 가능. 별도 PD님 확인 불요 (C29)
-- Phase 0-C 스코프 재정의는 #5B 연장선, 팀 자율 논의 후 PM에게 결과만 보고 예정
-
----
-
-**정직성 태그 (C23)**:
-- 본 보고서의 모든 상태 판정은 2026-04-17 PD 지시 로그·git 이력·파일시스템 실측 결과에 근거
-- 구 `개발팀/코어_설계/` 흡수 판정 근거: 커밋 `1f50ce5` (문서 2건) + `7187ac6` (_skeleton 발전적 흡수)
-- _skeleton 판정은 "코드 실체가 `코어코드/BT.Framework/`로 발전적 흡수"로 해석 — 1:1 파일 복제가 아닌 **역할 승계** (추정이 아닌 git 이력·파일시스템 상관관계 기반 판정)
diff --git a/공유/소통/완료/2026-04-17_업무현황_기획팀.md b/공유/소통/완료/2026-04-17_업무현황_기획팀.md
deleted file mode 100644
index e1fa665..0000000
--- a/공유/소통/완료/2026-04-17_업무현황_기획팀.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-from: 기획팀장
-to: 총괄PM
-type: 상태보고
-subject: 기획팀 업무현황 보고 — 2026-04-17
-priority: normal
-status: 대기
-created: 2026-04-17
----
-
-# 기획팀 업무현황 보고 (2026-04-17)
-
-> 출처: `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 활성 지시 섹션 (실측 2026-04-17)
-> 선행본: `2026-04-16_업무현황_기획실.md` (pm-auditor Major M3 DEPRECATED). 본 보고서가 최신 SOT.
-
----
-
-## 1. 활성 지시 현황
-
-| 구분 | # | 지시 요지 | 상태 | 비고 |
-|------|---|----------|------|------|
-| 차단됨 | 3 | Phase 3 업무 착수 | 보류 | Phase 3 HOLD 유지. Unity MCP 전환 대응 기획검토 완료. **Phase 3 재개 로드맵은 PD님 별도 논의 예정** |
-
----
-
-## 2. #3 상세 — Phase 3 업무 착수 (보류)
-
-### 진행 경위
-1. 2026-04-15: PD님이 Phase 3 업무 착수 지시 → HOLD 공지(`⚠️_PHASE3_HOLD_공지.md`)와 충돌 → 정식 보류
-2. 2026-04-17: PD님 지시로 시뮬 방향이 **Headless C# CLI → Unity MCP 기반**으로 전환
-3. 2026-04-17: Unity MCP 전환 대응 기획검토 완료 — `2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`
-
-### 확정 사항
-1. **Python 시뮬 폐기 확정** — 구 기획실 삭제로 `battle_sim.py` 등 소실. 폐기 사안으로 기록, 재논의 대상 아님 (2026-04-17 PD님 확인)
-2. **교차 검증 축 단순화** — Python 시뮬 축 폐기 → Unity MCP 단일 SOT 구조 확정
-
-### 재개 조건
-1. **Phase 3 HOLD 해제** (PD님 명시 지시 필요)
-2. **Phase 3 재개 로드맵 확정** — PD님 별도 논의 예정 사안
-
----
-
-## 3. 분류 요약
-
-| 분류 | 건수 | 항목 |
-|------|------|------|
-| 즉시 착수 가능 (차단 요인 없음) | **0건** | — |
-| 차단됨 (선행 조건 미해소) | **1건** | #3 Phase 3 |
-| **합계** | **1건** | — |
-
----
-
-## 4. 즉시 착수 가능 작업
-
-**현재 기획팀 유휴 상태.** 활성 지시 1건 모두 차단 상태이며, 별도 자율 착수 가능 작업은 없음.
-
-**조건부 준비 가능**:
-- 개발팀 Unity MCP 러너 구축 완료 시 → Phase 3 부분 재개(Day 1~3 범위) 준비 가능 (기획검토 보고서 §3 기준)
-- 단, 실제 재개는 PD님 HOLD 해제·재개 로드맵 확정 선행 필요
-
----
-
-## 5. 차단 요인
-
-| # | 차단 요인 | 해소 주체 |
-|---|---------|---------|
-| 1 | Phase 3 HOLD 유지 | PD님 (명시적 해제 지시) |
-| 2 | Phase 3 재개 로드맵 미확정 | PD님 (별도 논의 예정) |
-
----
-
-## 6. PD님 결정 대기 항목
-
-| # | 안건 | 배경 |
-|---|------|------|
-| 1 | **Phase 3 재개 로드맵 논의** | Unity MCP 전환 대응 기획검토 완료. Python 시뮬 폐기 확정. 재개 범위·선후관계·검증 축을 PD님과 정리 필요. PD님이 "별도 논의 예정"으로 명시하신 사안 |
-
-> 본 항목은 PD님이 명시적으로 "별도 논의 예정"으로 두신 사안이며, C29 "PD님 결정 떠넘기기"에 해당하지 않음.
-
----
-
-## 7. 이슈·리스크
-
-**없음.**
-
----
-
-**보고 완료**: 기획팀장 (2026-04-17)
diff --git a/공유/소통/완료/2026-04-19_memory_junction_중앙화_실무검토.md b/공유/소통/완료/2026-04-19_memory_junction_중앙화_실무검토.md
deleted file mode 100644
index 9d8d1dd..0000000
--- a/공유/소통/완료/2026-04-19_memory_junction_중앙화_실무검토.md
+++ /dev/null
@@ -1,552 +0,0 @@
----
-from: 개발팀장
-to: PM
-type: 실무검토보고서
-subject: memory junction HOME 중앙화 근원 해결안 (옵션 A) 실무 검토
-date: 2026-04-19
-status: 대기
-priority: 조직 생존급
-관련_PD지시: 개발팀 PD 지시 로그 #40
-연관_자산: C34 Live 증분 동기화 / C16-1 PC 독립 셋업 / 헌법 제1원칙 ⑤
----
-
-# memory junction HOME 중앙화 근원 해결안 — 실무 검토 보고서
-
-## 0. 요약 (TL;DR)
-
-1. **결함 실재 확정** — 실측 결과 레포 루트 `memory/org/`와 본 worktree `memory/org/`가 **이미 분기 실체 발생**. 파일 누락·내용 상이 확인. 본 worktree(`tender-liskov-844a72`)는 **user memory junction 자체가 없음** — 더 심각한 단절 상태.
-2. **근원 해결 방향 확정** — 옵션 A(HOME 중앙화) 정당성 재확인. C34(`.live/` 중앙 Junction)와 완전 동형 패턴. 헌법 제1원칙 ⑤의 근본 보호장치.
-3. **권장 세부 방식** — **옵션 (a) sync 스크립트 방식**을 채택한다 (git symlink 추적 옵션 b 거부 근거 §3.1). 레포 `memory/org/`는 실체 디렉토리 유지, 중앙은 `$HOME/.claude/nerdnavis-memory/`, 양방향 동기화 스크립트 + post-commit·SessionStart hook 자동화.
-4. **규칙 체계** — **C34 확장** 권장 (C35 독립 신설 거부 근거 §3.5). C34를 "Live + memory 공통 중앙화 체계"로 재명명·포괄.
-5. **집행 순서 9단계** 포함 — 마이그레이션·역방향 sync·기존 PC 역호환·감사 체크 항목 포함. C6-1 백업 의무 선행.
-
----
-
-## 1. 실측 결함 확정 (근거 데이터)
-
-### 1.1 실측 내역
-
-```
-$ for d in "$HOME/.claude/projects/"E--BurningTimesAi*; do ... done
-E--BurningTimesAi                                             -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi------claude-worktrees-cool-blackwell        -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi------claude-worktrees-pensive-ellis         -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi------claude-worktrees-vibrant-hellman       -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi------claude-worktrees-wizardly-snyder       -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-cool-cerf                 -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-exciting-shirley          -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-inspiring-lichterman      -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-quirky-panini             -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-trusting-buck             -> /e/BurningTimesAi/memory/org
-E--BurningTimesAi--claude-worktrees-tender-liskov-844a72      -> (link 없음 — 결함 실체)
-... (이하 23개 worktree 해시 폴더 중 약 13개 junction 부재)
-```
-
-### 1.2 결정적 증거 — 내용 분기
-
-```
-$ diff -qr /e/BurningTimesAi/memory/org /e/BurningTimesAi/.claude/worktrees/tender-liskov-844a72/memory/org
-Files .../MEMORY.md and .../memory/org/MEMORY.md differ
-Only in .../tender-liskov-844a72/memory/org: feedback_active_archive_promotion_omission.md
-```
-
-본 worktree의 `feedback_active_archive_promotion_omission.md`(2026-04-19 00:11 생성)가 레포 루트에 누락. MEMORY.md도 내용 상이. **즉 다음 commit 시 덮어쓰기 또는 병합 충돌 리스크 실재**.
-
-### 1.3 현 결함의 정확한 유형 3종 (옵션 A 무관 이미 존재)
-
-1. **junction 부재 worktree**: Claude가 user memory Write 시 `$HOME/.claude/projects/E--BurningTimesAi--claude-worktrees-<name>/memory/...`에 **별도 일반 디렉토리로** 기록. git 완전 단절.
-2. **junction 존재 worktree**: Write가 레포 루트 `memory/org/`로 기록. 해당 worktree에서는 `git status`에 보이지 않음. 이 상태에서 worktree가 commit 시 구버전 덮어쓰기.
-3. **본 worktree의 실체 디렉토리**: `.claude/worktrees/tender-liskov-844a72/memory/org/`도 실체로 존재 — git checkout 시점의 memory/org/를 그대로 포함. 중앙화 전환 시 "어느 것이 정(正)인가" 판정 필수.
-
-### 1.4 `.live/`와의 비교 (왜 `.live/`는 C34로 해결됐고 memory는 안 됐나)
-
-| 축 | `.live/` | `memory/org/` |
-|----|----------|---------------|
-| git 추적 | **제외** (`.gitignore`에 `.live/*`) | **추적** (git ls-files 31개) |
-| 변경 주체 | PM만 Write | Claude user memory 시스템 + 에이전트 |
-| 경로 의존 | `$REPO_ROOT/.live/` (상대) | `$HOME/.claude/projects/<hash>/memory` (절대) |
-| 중앙화 난이도 | 낮음 (`.gitignore` 제외 덕에 symlink 자유) | 높음 (git 추적 + symlink 양립 설계 필요) |
-| 현 해결 상태 | ✅ C34 완료 | ❌ 본 검토 대상 |
-
-이 차이가 **옵션 (b) git symlink 추적안을 거부하는 핵심 근거**이며, **옵션 (a) sync 스크립트 방식의 정당성의 출발점**이다.
-
----
-
-## 2. PM 1차 설계안 대응 — 9개 검토 항목
-
-### 2.1 검토 1: git-tracked vs junction 양립 — 옵션 (a) vs (b) 결론
-
-**권장: 옵션 (a) sync 스크립트 방식** — 옵션 (b) 거부.
-
-#### 옵션 (a) sync 스크립트 방식 (✅ 권장)
-
-**설계**:
-- 실 저장: `$HOME/.claude/nerdnavis-memory/` (C34와 동형, PC 로컬)
-- user memory junction: 11개 worktree 해시 폴더의 `memory` link → **중앙** 경로로 재연결
-- 레포 `memory/org/`: **실체 디렉토리 유지** (git 추적 정상)
-- 동기화: `scripts/sync_memory_to_repo.sh`로 중앙→레포 단방향, `scripts/sync_memory_from_repo.sh`로 레포→중앙 단방향
-- 자동화: post-commit hook(레포→중앙 자동 복구), SessionStart hook(pull 후 역방향 sync), UserPromptSubmit hook 고려(PM이 user memory에 쓴 직후 레포 반영)
-
-**장점**:
-1. git 추적 정상 — 현 SOT 체계 변경 없음 (`.gitignore` 수정 불필요)
-2. PC clone 시 즉시 memory/org/ 접근 가능 (setup 전에도 읽기 가능)
-3. 백업·롤백 용이 (레포 실체 vs 중앙 실체 양쪽 다 존재)
-4. Windows junction + symlink 호환성 무관 (일반 파일 rsync 수준)
-5. C6-1 원본 보호 원칙과 잘 맞음 (중앙·레포 모두 실체이므로 이중 백업)
-
-**단점**:
-1. 동기화 스크립트 누락·실패 시 분기 누적 리스크
-2. post-commit hook 인프라에 의존 (hook 미실행 환경 대비 fallback 필요)
-3. 엔진 복잡도 증가 (C14 토큰 효율 약간 저하)
-
-#### 옵션 (b) git symlink 추적 (❌ 거부)
-
-**거부 근거 5종**:
-
-1. **Windows core.symlinks 이슈**: Windows에서 git symlink는 `core.symlinks=true` + 관리자 권한 필요. PD님 PC 환경이 이 조건을 상시 충족한다는 보장 없음. 새 PC 합류 시 clone 단계에서 symlink가 일반 텍스트 파일로 체크아웃되는 사고 실증 다수.
-2. **PC clone 후 setup 전 접근 불가**: clone 직후 setup 스크립트가 실행되기 전까지 `memory/org/` 내 모든 파일이 symlink 텍스트(42바이트 정도)로만 존재. 이 상태에서 PM이 실수로 읽거나 `grep feedback_*`하면 실 내용 미발견.
-3. **한국어 경로 호환성**: 한국어 경로(`공유/`·`기획팀/`)와 symlink 조합이 Windows에서 예측 불가능 케이스 다수.
-4. **Junction과 Symlink 혼용 리스크**: `.live/`는 Junction(디렉토리)이고 `memory/org/`를 Symlink(파일 단위)로 만들면 두 체계 혼재로 감사·디버그 난이도 증가.
-5. **git 히스토리 손상 리스크**: 기존 커밋들이 실 파일로 기록된 상태에서 symlink로 전환하는 대규모 리팩토링은 history rewrite 위험(C19-2 되돌리기 어려움 액션).
-
-### 2.2 검토 2: sync 시점·주체
-
-**권장: 다계층 자동 sync + 수동 비상 스크립트**.
-
-| 시점 | 방식 | 주체 | 방향 |
-|------|------|------|------|
-| **SessionStart hook** | `sync_memory_repo_to_central.sh` | 자동 | 레포 → 중앙 (pull 직후 중앙 최신화) |
-| **post-commit hook** | `sync_memory_central_to_repo.sh` (no-op if 이미 동기) | 자동 | 중앙 → 레포 (commit에 포함할 최신본 보장) |
-| **수동 명시** | `scripts/sync_memory.sh both` | 개발자 | 양방향 강제 sync |
-| **PM 작업 직후** | (선택) UserPromptSubmit 후처리 | 자동 | 중앙 → 레포 (세션 내 Write 반영) |
-| **감사관 주기 체크** | `pm-auditor`·`dev-auditor` | 주기 감사 | 분기 상태 감지 → 자동 복구 요청 |
-
-post-commit hook은 **이미 존재** (`scripts/git-hooks/post-commit`). 본 sync 로직을 여기 append하여 commit할 때 중앙 최신본이 레포에 반영된 상태로 commit되도록.
-
-**pre-commit hook 논의**: PM 요청안에 "commit 전 실행(pre-commit hook)" 제시됨. **거부** — pre-commit은 실패 시 commit 차단으로 작업 흐름 단절. post-commit에서 "불일치 시 경고 + 다음 commit 자동 보정" 방식이 덜 파괴적(C34-12 Degraded 운영 원칙 동일 정신).
-
-### 2.3 검토 3: 역방향 sync (git pull 후)
-
-**가장 복잡한 엣지 케이스** — 중앙 로컬 쓰기와 원격 pull 결과가 모두 최신일 때 어느 쪽이 정(正)인가?
-
-#### 3층 해결안
-
-1. **기본 정책: 레포가 SOT**
-   - `git pull` 후 레포 `memory/org/`가 항상 진실. 중앙은 레포를 따라간다.
-   - SessionStart hook이 pull 직후 `sync_memory_repo_to_central.sh` 실행 — **중앙 덮어쓰기 (백업 자동)**.
-2. **예외: 중앙에만 있는 unflushed 변경**
-   - 중앙 `$HOME/.claude/nerdnavis-memory/` 파일 mtime이 레포 대응 파일보다 새롭고, 레포 파일의 git log HEAD 커밋 mtime과 비교해 아직 commit 안 된 것이면 "unflushed" 판정.
-   - 이 경우 중앙 파일을 `$HOME/.claude/nerdnavis-memory.conflict-$(date +%Y%m%d%H%M%S)/`에 대피 → 레포본으로 덮어씀 → 경고 출력.
-   - 대피본은 `verify_setup.ps1` 2.6 섹션이 감지하여 "unflushed 중앙 변경 감지 — 수동 병합 필요" 경고.
-3. **감사관 백업**: pm-auditor가 주기 감사 시 `$HOME/.claude/nerdnavis-memory.conflict-*` 발견 시 즉시 보고.
-
-#### 특수 상황: 다른 PC가 원격에 push한 변경 수신
-
-- PC1이 `feedback_X.md`를 push → PC2가 pull → SessionStart hook이 레포→중앙 sync → PC2의 중앙에 `feedback_X.md` 등장 → PC2의 user memory junction 경유 Read 시 즉시 보임. **정상 작동**.
-
-### 2.4 검토 4: 초기 마이그레이션 안전성
-
-**현 실측 기반** — 본 검토 보고서 1.2 절 증거.
-
-#### 마이그레이션 전 필수 확인
-
-1. **모든 worktree `memory/org/` 실체 수집 감사**:
-   ```
-   for wt in $(git worktree list --porcelain | grep '^worktree ' | cut -d' ' -f2); do
-     echo "=== $wt ==="
-     diff -qr "$wt/memory/org" "/e/BurningTimesAi/memory/org" 2>&1 | head
-   done
-   ```
-2. **타임스탬프·내용 충돌 전수 스캔**: 파일별 "레포 루트 vs 중앙(현 레포 루트 기반) vs worktree들"의 3축 비교.
-3. **우선순위 규칙 (정(正) 판정)**:
-   - A. worktree에만 있고 레포 루트에 없는 파일 → **worktree본이 정**, 중앙으로 흡수.
-   - B. 레포 루트와 worktree 양쪽 있고 내용 다름 → **mtime 최신본이 정**, 단 양쪽 다 `feedback_active_archive_promotion_omission.md` 같은 신규 파일이면 PD님에게 보고 후 결정.
-   - C. junction 없는 worktree 해시 폴더의 `memory/` 일반 디렉토리 내용 → 전수 스캔하여 중앙에 누락분 흡수.
-
-#### 백업 의무 (C6-1 원본 보호)
-
-1. 레포 루트 `memory/org/` → `$HOME/.claude/nerdnavis-memory.bak_PREMIGRATION_$(date +%Y%m%d%H%M%S)/` 전체 복사
-2. 각 worktree `memory/org/` → 동일 백업 디렉토리 내 `worktree-<name>/` 하위 보존
-3. 각 junction 타깃 폴더 → 동일 백업 디렉토리 내 `junction-<hash>/` 하위 보존
-
-이 3층 백업 이후에만 junction 재연결·중앙 구축 진행.
-
-### 2.5 검토 5: C34 확장 vs C35 신설
-
-**권장: C34 확장** — C35 독립 신설 거부.
-
-#### C34 확장이 적정한 근거 5종
-
-1. **패턴 완전 동형**: `.live/`·`memory/org/` 모두 "PC 로컬 실시간 공유 + worktree 무관 + HOME 중앙화" 동일 패턴.
-2. **교훈 일관성**: 차기 프로젝트 인수인계 시 "C34를 보면 Live + memory 양쪽 체계 동시 이해"가 "C34·C35 개별 학습" 대비 훨씬 효율적.
-3. **토큰 효율 (C14)**: 규칙 본문 축소. C35 신설 시 배경·연관·위반·격상 경위 등 중복 서술 대량 발생.
-4. **`feedback_worktree_isolation.md` 이미 양쪽 포괄**: 현 메모리 문서가 `.live/`·`memory/org/`·`paths.local.json`을 동일 표에 정리 중 — 규칙도 같은 구조 권장.
-5. **감사 체크리스트 통합**: C34-15(5개 질문 체크리스트)가 이미 "모든 신규 조직 설정·저장소"를 대상으로 함. memory junction은 그 체크리스트 적용 첫 사례.
-
-#### 제안 개정 요지 (C34 → "Live + memory 공통 중앙화 체계")
-
-- 이름: "Live 증분 동기화 체계" → **"PC 로컬 실시간 공유 중앙화 체계 (Live + memory)"**
-- C34-1 개요에 `.live/`·`memory/org/` 공통 원칙 명시
-- C34-3 중앙 저장소 구조를 표로 분리: Live(`nerdnavis-live/`), memory(`nerdnavis-memory/`)
-- C34-4 대상에 "git 추적 대상 memory/org/는 sync 스크립트 방식으로 양립" 주석 추가
-- C34-15 체크리스트 표의 `memory/org/` 행을 🟡 → ✅로 갱신 (근원 해결 완료 표시)
-
-### 2.6 검토 6: Agent 경계 보호 (C34-11) 자기 준수
-
-**본 Agent 작업의 경계 준수 증명**:
-
-1. 본 보고서 작성 경로: `E:\BurningTimesAi\.claude\worktrees\tender-liskov-844a72\공유\소통\개발팀→PM\2026-04-19_memory_junction_중앙화_실무검토.md` — **본 worktree 절대 경로 명시**. junction 경유 회피.
-2. 대화로그 엔트리 append 경로: `E:\BurningTimesAi\.claude\worktrees\tender-liskov-844a72\공유\대화로그\조직운영\2026-04-19.md` — 동일.
-3. 본 검토 보고서 내부에서 경로 표기 시 `E:\BurningTimesAi\...` 하드코딩 **회피** 원칙으로 `$(git rev-parse --show-toplevel)` 기준 상대 경로 서술(§3 설계안에서 일관).
-4. PM 응답 수령 후 확인 2축:
-   - 본 worktree: `git -C /e/BurningTimesAi/.claude/worktrees/tender-liskov-844a72 status`
-   - 레포 루트: `git -C /e/BurningTimesAi status`
-   - 레포 루트 쪽에 `공유/소통/개발팀→PM/...` 파일이 등장하면 경계 이탈 — `git -C /e/BurningTimesAi stash push -u -- 공유/` → 본 worktree `git stash pop`.
-
-### 2.7 검토 7: 리스크 평가 (집행 실패 시)
-
-#### 리스크 7종
-
-1. **마이그레이션 중 memory 파일 소실**
-   - 확률: 중
-   - 영향: 치명 (조직 기억·교훈 영구 손실)
-   - 대응: §2.4 3층 백업 + 각 단계 `verify_*` 검증 + PD님 체크포인트 보고
-
-2. **junction 재연결 중 오작동으로 타겟 혼동**
-   - 확률: 중 (PD님 PC에는 기존 junction 존재)
-   - 영향: 중 (일부 세션이 잘못된 디렉토리 참조)
-   - 대응: `cmd /c mklink /J` 수행 전 `Remove-Item` + `Get-Item -Force` 확인 후 재생성. verify_setup 2.6 섹션이 **marker 경유 읽기 3축 검증**으로 잡음.
-
-3. **sync 스크립트 race condition (여러 세션 동시 commit)**
-   - 확률: 저
-   - 영향: 중 (sync 중간 상태 파일 분기)
-   - 대응: `flock`(Unix) 또는 `New-Item -ItemType File -Path lock.file` with `-ErrorAction Stop`(Windows)으로 lock 파일 기반 상호 배제.
-
-4. **post-commit hook 미실행 환경 (e.g., `git commit --no-verify`)**
-   - 확률: 중
-   - 영향: 저 (분기 1회 발생 후 다음 SessionStart hook에서 복구)
-   - 대응: SessionStart hook의 역방향 sync가 안전망.
-
-5. **중앙 디렉토리 삭제 (user가 실수로 `$HOME/.claude/nerdnavis-memory/` rmdir)**
-   - 확률: 저
-   - 영향: 중 (세션 시작 시 자동 재구축)
-   - 대응: `sync_memory_repo_to_central.sh`가 중앙 부재 감지 시 레포에서 전량 복구. Sentinel `.memory-junction-marker` 검증 후 진행.
-
-6. **신 PC clone 시 setup 전 Write 시도**
-   - 확률: 저
-   - 영향: 저 (일반 디렉토리 생성 + 다음 setup 실행 시 흡수)
-   - 대응: `sync_memory_central_to_repo.sh`가 junction 부재 환경에서도 정상 실행되도록 설계 (junction 없으면 중앙 스킵).
-
-7. **차기 프로젝트 계승 시 스크립트 경로 하드코딩**
-   - 확률: 중
-   - 영향: 저 (스크립트 내 `nerdnavis-memory` 문자열)
-   - 대응: 스크립트 상단 변수 `CENTRAL_DIR_NAME="nerdnavis-memory"` 선언 + 차기 프로젝트는 값만 교체.
-
-#### 백업·롤백 전략
-
-- 모든 마이그레이션 단계별 백업 디렉토리 `$HOME/.claude/nerdnavis-memory.bak_STAGE_<N>_<stamp>/` 유지.
-- 롤백 절차: (1) 중앙 삭제 (2) junction 제거 (3) 레포 루트 `memory/org/` 원본 복구 (4) 모든 worktree user memory junction을 레포 루트로 재연결 (현 상태로 복귀). 이 절차를 `scripts/rollback_memory_central.sh`로 문서화·준비.
-
-### 2.8 검토 8: 기존 운영 PC 역호환
-
-#### PD님 현 PC 실측 상태 (1.1 절)
-
-- 11개 worktree 중 약 8개만 user memory junction 존재
-- junction 없는 worktree: 13개 이상 (`tender-liskov-844a72` 포함)
-- 이는 setup 스크립트의 현재 filter `*Documents* -or *BurningTimes* -or *BurningTimes* -or *<rootLeaf>*`가 `E--BurningTimesAi--claude-worktrees-...` 패턴을 **완전 포괄하지 못해** 생긴 결함. `-like "$rootDrive--*"` filter가 `E--*`로 동작하지만 junction 생성 로직 자체가 누락된 폴더에는 실행되지 않음.
-
-#### 역호환 집행 순서
-
-1. 현 PC의 모든 worktree 해시 폴더 스캔 (Claude가 등록한 모든 프로젝트 경로)
-2. **junction이 있으면 타겟 변경** (`Remove-Item` → 재생성), **없으면 신규 생성** — 모두 `$HOME/.claude/nerdnavis-memory/`로 연결
-3. 기존 타깃(레포 루트 `memory/org/`) 삭제하지 않음 — §3의 sync 체계에서 양쪽 모두 유지
-4. setup 스크립트 멱등성: 재실행 시 기존 정확한 junction은 skip (Attributes 확인), 잘못된 junction만 수정 → 재실행 부작용 없음
-
-#### setup 스크립트 개선 포인트
-
-- Line 78~86의 filter 조건을 `E--BurningTimesAi` 루트 문자열 기반으로 **더 넓게** 개정: `-like "$rootLeaf*"` 또는 `-like "*BurningTimesAi*"` 단독. PD님 PC의 worktree 해시 폴더를 **모두 포착**하도록.
-
-### 2.9 검토 9: "생존성 이슈 축소 보고 금지" 원칙 감사 체크 편입
-
-**PD님 직접 지시 반영** — 본 항목을 감사 체크에 편입 권고.
-
-#### pm-auditor·dev-auditor 신규 체크리스트 항목
-
-```
-[ ] 최근 세션에 "memory junction 경계 이슈"·"worktree 격리 이슈"·"데이터 분기 위험" 등
-    C34/C16-1 직결 이슈가 발견되었으나 PD님에게 축소 보고되거나 "권고·선택" 수준으로
-    프레이밍된 사례가 없는가?
-
-[ ] 발견된 헌법 제1원칙 ⑤ 직결 이슈는 "조직 생존급" 명시 보고했는가?
-
-[ ] C34-15 5개 질문 체크리스트를 신 설정·저장소 도입 시 실제로 수행했는가?
-    (수행 기록이 대화로그에 없으면 위반)
-```
-
-본 항목은 `memory/org/feedback_pm_over_conservative_interpretation.md`와 직결되는 4회차 변종 패턴 차단. 개발팀장은 본 검토에서 **옵션 A의 근거를 명확히 제시**함으로써 PM이 "권고·선택" 수준으로 희석하지 않도록 문서적으로 고정.
-
----
-
-## 3. 권장 설계안 (옵션 A 세부)
-
-### 3.1 옵션 (a) sync 스크립트 방식 최종 설계
-
-```
-$HOME/.claude/nerdnavis-memory/           ← 중앙 실 저장소 (PC 로컬)
-├── .memory-junction-marker               ← Sentinel
-├── MEMORY.md
-├── feedback_*.md (30+종)
-├── project_org_structure.md
-└── user_role.md
-
-$HOME/.claude/projects/E--BurningTimesAi*/memory  ← Claude user memory junction
-    → junction → $HOME/.claude/nerdnavis-memory/     (Windows mklink /J)
-
-$REPO_ROOT/memory/org/                    ← git 추적 실체 디렉토리 (원본 SOT)
-├── MEMORY.md
-├── feedback_*.md (30+종)
-└── ...
-
-각 worktree의 memory/org/                 ← git checkout 실체 (worktree별 독립)
-    ※ 본 워크트리 내부에서 Write 하면 worktree-local 파일이 되며
-       post-commit hook이 트리거되면 중앙도 자동 갱신됨
-```
-
-### 3.2 신규·수정 스크립트 목록
-
-1. **신규**: `scripts/memory_junction_ensure.sh`
-   - SessionStart hook에서 실행
-   - 11개 worktree 해시 폴더 순회하며 user memory junction을 중앙으로 연결
-   - Sentinel `$CENTRAL_MEM/.memory-junction-marker`로 OS-agnostic 판정
-   - Degraded 운영 (실패 시 작업 차단 안 함, 경고만)
-
-2. **신규**: `scripts/sync_memory_repo_to_central.sh`
-   - 레포 `memory/org/` → 중앙 덮어쓰기 (SessionStart hook, pull 직후)
-   - 중앙 대피본 `$CENTRAL_MEM.conflict-<stamp>/` 생성 조건 체크
-
-3. **신규**: `scripts/sync_memory_central_to_repo.sh`
-   - 중앙 → 레포 `memory/org/` 덮어쓰기 (post-commit hook, PM Write 반영)
-   - rsync 스타일(파일별 mtime·hash 비교), 파일 삭제는 동기화하지 않음 (안전망)
-
-4. **신규**: `scripts/sync_memory.sh both|repo-to-central|central-to-repo`
-   - 수동 비상 스크립트. 인자로 방향 명시.
-
-5. **신규**: `scripts/rollback_memory_central.sh`
-   - 롤백 절차 자동화. junction 해제 + 중앙 삭제 + 레포 복구.
-
-6. **수정**: `setup/setup_windows.ps1`
-   - 3.5 섹션 다음에 **3.6 섹션 신규**: Live와 동일 패턴으로 memory 중앙 저장소 + Junction 자동 설치
-   - 기존 3절(Claude 사용자 메모리 연결) 개정: 타겟을 `$orgMemoryTarget` (레포 루트 memory/org/) → `$centralMemory` (중앙 memory)로 변경
-   - filter 개선: 13개 이상 누락된 worktree 해시 폴더 포괄
-
-7. **수정**: `setup/setup_macos.sh`
-   - macOS symlink 버전 동일 로직 추가
-
-8. **수정**: `scripts/verify_setup.ps1`
-   - **2.6 섹션 신규**: memory 중앙 저장소 + Junction 3축 검증 (Live 2.5와 동형)
-
-9. **수정**: `scripts/git-hooks/post-commit`
-   - `sync_memory_central_to_repo.sh` 호출 추가 (sync_signal 다음에)
-   - Lock 파일 기반 race condition 방어
-
-10. **수정**: `.claude/settings.json` SessionStart hook 체인
-    - `live_junction_ensure.sh` 다음에 `memory_junction_ensure.sh` 삽입
-    - 그 다음에 `sync_memory_repo_to_central.sh` 삽입
-
-### 3.3 규칙 문서 개정
-
-1. `.claude/skills/BurningTimes-코어룰/SKILL.md`:
-   - **C34 제목 개정**: "Live 증분 동기화 체계" → "PC 로컬 실시간 공유 중앙화 체계 (Live + memory)"
-   - **C34-3 중앙 저장소 구조**: 표 형식으로 Live·memory 병기
-   - **C34-4 대상**: memory/org/ 포함, "git 추적 대상은 sync 스크립트 양립" 주석
-   - **C34-15 체크리스트 표**: memory/org/ 행을 🟡 → ✅ 갱신
-   - **C34-16 신규 (선택)**: "C34 확장 — memory/org/ 근원 해결 (2026-04-19)" 역사 기록
-
-2. `CLAUDE.md` 루트:
-   - "조직 핵심 자산" 섹션에 "Live + memory 중앙화" 병기
-
-3. 아카이브 파일:
-   - `공유/조직공지/폐기_규칙_아카이브.md`에 "C34 개정 2026-04-19" 기록
-   - `공유/조직공지/방향전환_히스토리_아카이브.md`에 "memory junction 레포 루트 → 중앙화" 6필드 기록
-
-### 3.4 조직공지 + memory feedback 신설
-
-1. **신규**: `공유/조직공지/2026-04-19_C34_확장_memory_junction_중앙화.md`
-   - 배경·내용·적용 시점·참조 명시
-   - PD님 조직 생존급 선언 인용
-
-2. **신규**: `memory/org/feedback_memory_junction_repo_root_misdirect.md`
-   - 결함 실증 (1.2 절 데이터)
-   - "C34 패턴 적용 지연 배경 — git 추적 양립 설계 난제" 기록
-   - `feedback_worktree_isolation.md`·`feedback_pm_over_conservative_interpretation.md` cross-reference
-
-3. **갱신**: `memory/org/MEMORY.md`
-   - 신규 feedback 파일 인덱스 추가
-
-### 3.5 C35 신설 거부 근거 (재확인)
-
-§2.5에서 상술. 요약:
-- 패턴 동형 → 단일 규칙 포괄이 교훈 일관성·토큰 효율·학습 효율 모두 우위
-- `feedback_worktree_isolation.md`가 이미 양 체계 동시 기록 중이므로 규칙도 대응
-
----
-
-## 4. 집행 순서 9단계 (C34 집행과 동일 템포)
-
-각 단계마다 PD님 체크포인트는 **없음** (C29 업무 자율 수행, PD님 원안 옵션 A가 명시 승인). 단, **단계 3 마이그레이션 직전에 사전 보고** (C6-1 원본 보호, 중대 변경 사전 고지 의무).
-
-### 단계 1: C34 규칙 개정 드래프트
-- SKILL.md C34-1·C34-3·C34-4·C34-15 개정본 작성
-- 조직공지 드래프트 작성
-- feedback 메모리 드래프트 작성
-- 개발팀장 검토 완료 → PM 검토 요청
-
-### 단계 2: 스크립트 구현 (신규 5종 + 수정 5종)
-- §3.2 목록 전량 구현
-- 본 worktree에서 구현 → push 전 dry-run 테스트
-
-### 단계 3: 마이그레이션 — 백업 전량 수행 (PD님 사전 보고)
-- 3층 백업 (§2.4): 레포 루트·worktree들·junction 타깃들
-- 정(正) 판정 감사: §2.4의 A·B·C 규칙으로 파일 단위 판정
-- 판정 결과를 표 형식으로 보고서화 → PD님에게 **사전 고지** (C6-1·C6-2 중대 변경)
-
-### 단계 4: 중앙 저장소 구축
-- `$HOME/.claude/nerdnavis-memory/` 생성
-- Sentinel 설치
-- 정(正) 판정된 파일 전량 복사 + chmod/ACL 정비
-- verify_setup 2.6 3축 검증 통과
-
-### 단계 5: Junction 재연결
-- 11개 기존 junction worktree: 타깃 변경 (레포 루트 → 중앙)
-- 13개 이상 junction 없는 worktree: 신규 junction 생성
-- 검증: 각 worktree에서 Read 테스트 (sentinel 접근)
-
-### 단계 6: Sync hook 활성화
-- SessionStart hook 체인 갱신
-- post-commit hook 갱신
-- 세션 재시작 1회 권장 (C1 사전 고지)
-
-### 단계 7: 검증 (C23 실증 기반)
-- 양방향 sync 테스트 (중앙 → 레포 → commit → 다른 PC pull → 다른 PC 중앙 반영)
-- 충돌 시나리오 테스트 (unflushed 중앙 변경 + pull 충돌)
-- 각 worktree에서 Write → 중앙 반영 확인
-- post-commit hook race condition 테스트 (2개 세션 동시 commit)
-
-### 단계 8: 조직공지·feedback·규칙 반영
-- SKILL.md 본문 개정 commit
-- 조직공지 commit
-- feedback 메모리 commit
-- MEMORY.md 인덱스 갱신
-- PD 지시 로그 #40 → 완료 상태 갱신 (산출물 경로 명시)
-
-### 단계 9: 감사 체크 편입 + 차기 프로젝트 문서 갱신
-- pm-auditor·dev-auditor·plan-auditor 3종 정의에 §2.9 체크리스트 추가
-- C34-15 5개 질문 체크리스트의 memory/org/ 행 갱신
-- 차기 프로젝트 계승용 `프로젝트/코어프레임워크/` 관련 문서 1줄 참조 추가
-
----
-
-## 5. 테스트 시나리오 (집행 후 검증용)
-
-### 5.1 기본 동작 시나리오 3종
-
-1. **세션 A Write → 세션 B 감지**:
-   - 세션 A: `echo "test" >> $HOME/.claude/projects/E--BurningTimesAi/memory/feedback_test.md`
-   - 세션 B: Read 동일 경로 → **동일 내용 확인**
-
-2. **세션 A commit → 레포 반영**:
-   - 세션 A: user memory에 쓰기 → commit 실행
-   - post-commit hook이 중앙 → 레포 sync 수행 → git status에 해당 파일 반영
-   - commit 포함됨 확인
-
-3. **Pull 후 역방향 sync**:
-   - 다른 PC에서 push한 내용을 pull
-   - SessionStart hook이 레포 → 중앙 sync
-   - user memory에서 접근 시 새 파일 등장
-
-### 5.2 엣지 케이스 시나리오 5종
-
-1. **unflushed 중앙 변경 + pull 충돌**:
-   - 중앙에만 `feedback_A.md` 존재 (레포 미반영), pull로 레포에 `feedback_B.md` 신규 등장
-   - 예상: A는 `.conflict-*/`로 대피, B는 중앙·레포 양쪽 반영
-
-2. **Junction 수동 삭제 복구**:
-   - 사용자가 실수로 `Remove-Item $HOME/.claude/projects/E--BurningTimesAi/memory`
-   - 예상: 다음 SessionStart hook이 재생성
-
-3. **중앙 디렉토리 완전 삭제**:
-   - `Remove-Item $HOME/.claude/nerdnavis-memory -Recurse`
-   - 예상: 다음 SessionStart hook이 레포에서 전량 복구
-
-4. **2개 세션 동시 commit**:
-   - 거의 동시에 세션 A·B가 다른 파일 commit
-   - 예상: lock 파일 기반 직렬화, 양쪽 반영
-
-5. **`git commit --no-verify`**:
-   - post-commit hook 우회
-   - 예상: SessionStart hook 안전망이 다음 세션에서 복구
-
-### 5.3 재해 시나리오 2종
-
-1. **마이그레이션 중 전원 차단**:
-   - 단계 4 복사 중간 전원 차단
-   - 예상: 단계 3 백업으로 롤백 → `rollback_memory_central.sh` 실행
-
-2. **차기 프로젝트 도입 시 경로 충돌**:
-   - 다른 레포가 동일 PC에서 `nerdnavis-memory` 이름 사용 시도
-   - 예상: 스크립트 변수가 `$CENTRAL_DIR_NAME` 변수로 분리되어 있으므로 충돌 회피 가능. 차기 프로젝트는 `{프로젝트명}-memory`로 채택.
-
----
-
-## 6. 종합 권고 (PM·PD님 의사결정 지원)
-
-### 6.1 집행 즉시 착수 가능 (PM 재량)
-
-§3.1~§3.4의 설계안은 PD님 원안(옵션 A) 승인 범위 내이므로 PM 재량으로 집행 착수 가능. 단 §4 단계 3 직전 **사전 보고 필수** (C6-1 원본 보호 + C29-4 동기화).
-
-### 6.2 PD님 사전 확인이 필요한 이슈
-
-1. **단계 3 정(正) 판정 결과** — 본 worktree의 `feedback_active_archive_promotion_omission.md`처럼 "레포 루트에 없고 worktree에만 있는 파일"의 흡수 여부.
-2. **C34 개정 vs C35 신설** — 본 검토 권고는 C34 확장이나 PD님 판단 시 C35 선호 가능.
-3. **감사 체크리스트 신규 항목** (§2.9) — pm-auditor·dev-auditor 정의 변경은 C34-15 연계 범위 내이나, "축소 보고 감시" 항목의 표현은 PD님 원본 지시 인용 수준 확인 필요.
-
-### 6.3 C34와 동급 집행 원칙 재확인
-
-- 자원 제약 없음 (C9 완성도 우선)
-- 롤백 경로 확보 후 집행 (`rollback_memory_central.sh` 선행 준비)
-- PD님 조직 생존급 선언 → pm-auditor 3회차 재발 방지 + 본 건 축소 보고 방지 체크 편입
-- Agent 경계 보호 (C34-11) 전 단계 준수
-
----
-
-## 7. 본 검토 작업 대화로그·PD 지시 로그 갱신
-
-### 7.1 대화로그 엔트리
-
-`공유/대화로그/조직운영/2026-04-19.md`에 신규 엔트리 append 예정.
-
-### 7.2 PD 지시 로그 #40 갱신 알림 (C27)
-
-**본 실무 검토는 PD 지시 로그 #40 관련 산출물**이나, PM이 #40 항목을 어떻게 등록했는지 본 Agent는 접근 권한·책임 범위 밖. **PM이 Agent 결과 수령 후 직접 갱신 필요**:
-
-- 상태 변경: `대기/진행중` → `진행중` (본 검토 보고서는 작업의 일부, 완료 아님)
-- 산출물 경로 추가: `공유/소통/개발팀→PM/2026-04-19_memory_junction_중앙화_실무검토.md`
-- 본 보고서를 PM이 검토한 뒤 §4 집행에 착수, 9단계 전부 완료 후 `완료` 상태 전환.
-
----
-
-## 8. 요청 사항 (PM → PD님 상신 여부)
-
-본 보고서는 **개발팀장의 실무 검토안**이며 PM의 승인을 거친 후 집행 착수한다. PM 판단에 따라 본 보고서를 PD님에게 상신할지 여부는 PM 재량이나, **§6.2의 3개 이슈는 PD님 확인 권장**.
-
-PM이 본 보고서를 수령한 후:
-1. PM 검토 → §4 단계 1·2 착수 승인
-2. PM이 §6.2 3개 이슈를 안건 형식으로 정리하여 PD님 상신 (필요 시)
-3. PM이 PD 지시 로그 #40 상태 갱신
-
----
-
-**개발팀장 서명**
-작성일: 2026-04-19
-작성 환경: worktree `tender-liskov-844a72` (본 경계 내에서만 Write 수행, C34-11 준수)
-Agent 호출 주체: 총괄PM (PD 지시 로그 #40 기반)
diff --git a/공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md b/공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
deleted file mode 100644
index c11311a..0000000
--- a/공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
+++ /dev/null
@@ -1,476 +0,0 @@
----
-type: 인계서
-from: PM (2026-04-17 저녁 세션)
-to: 차후 PM 세션 (같은 PC 또는 다른 PC)
-date: 2026-04-17
-priority: Critical (조직 생명급)
-status: 집행 대기
-subject: 전수 정합성 감사 A+B급 7건 일괄 수정 집행
-related: 감사 보고 5종, SKILL.md, memory/feedback_*
----
-
-# 🚨 인계서 — 전수 감사 A+B급 7건 수정 집행 (조직 생명급)
-
-> **PD님 직접 승인**: 2026-04-17 저녁, "옵션 나. A+B급 7건 일괄 진행, 이후 후속 지시로 C급 진행"로 결정. 수정 3대 원칙 하에 집행.
->
-> **본 인계서의 성격**: 현 PM 세션의 토큰 소진으로 집행을 차기 세션에 이관. 차기 PM은 **본 인계서를 Read 후 그대로 집행**하면 됨. 요약·생략 없이 꼼꼼 작성. "조직 생명급"으로 PD님 직접 명시.
-
----
-
-## 0. 배경 (필독)
-
-- **2026-04-14~17 3일간** 조직 코어룰 대폭 신설·개정 (C27~C31, P24~P28, 3축 감사, Live 더미 이벤트 구동 체계, C20-1-A 3회 개정 등)
-- **2026-04-17 저녁** PD님 직접 지시로 전수 정합성 감사 착수 — 5개 Agent 병렬 투입 (pm-auditor·dev-auditor·plan-auditor + 개발팀장·기획팀장 자체 검증)
-- **감사 결과 총 26건 발견** — 일부 중복 후 실질 약 20건
-- **PD님 최적화 목적 명시**: "이 작업은 불필요한 토큰 낭비 등을 줄이고 최적화 하기 위한 목적"
-- **토큰 영향 우선순위**로 재분류: A급 3건 (고정비 직격), B급 4건 (주요 문서), C급 10+건 (국부)
-- **PD님 승인 범위**: A+B급 **7건 일괄**. C급은 후속 지시 대기
-
----
-
-## 1. 수정 3대 원칙 (최종 확정, 엄수 필수)
-
-### 원칙 1 — 본문은 최신, 히스토리는 아카이브 (2026-04-18 재개정, PD님 직접 지시)
-**모든 문서(변동비·고정비 공통)는 본문에 최신 내용만 유지**하고, 작업 과정 히스토리·방향 전환 이력·"당시 가정"은 외부 아카이브에 집약한다.
-
-#### 기본 구조
-| 대상 | 본문 처리 | 히스토리 저장 |
-|------|---------|-------------|
-| **코어 규칙(C·P)의 폐기·개정** | SKILL.md에 1줄 선언 + 외부 링크 | `공유/조직공지/폐기_규칙_아카이브.md` |
-| **프로젝트·설계·기획 문서의 방향 전환·용어 변경·경로 이동** | 본문 최신 내용만 + **말미 참조 섹션에 1줄 링크** (상단 배너 금지) | `공유/조직공지/방향전환_히스토리_아카이브.md` |
-| **폐기된 설계 문서 원본** (파일 성격 배너 유지 예외) | 파일 상단 "🔴 아카이브됨 — 대체: X" 배너 + 본문 당시 그대로 보존 | 해당 파일 자체가 히스토리 역할 |
-| **완료 실적 문서** (파일 성격 배너 유지 예외) | 파일 상단 "🟢 완료 실적 아카이브" 배너 + 최신 구현 경로 역참조 | — |
-
-#### 핵심 규정 (2026-04-18 PD님 재지시 반영 — 상단 배너 금지 원칙 확정)
-1. **본문에 "당시 가정 vs 현 방향" 병기 금지** — 병기는 본문 비대화 유발
-2. **본문에 방향 전환 이력 상단 배너 금지** — 본문 읽기 방해. 배너 대신 **문서 말미 참조 섹션에 1줄 링크**만
-3. **최신화 집행 시 3종 세트 동시 수행**:
-   - (ㄱ) 본문 수정 (최신 내용만, 상단 배너 없이 깔끔하게)
-   - (ㄴ) 아카이브 파일에 "당시 가정 → 현 방향" 전환 이력 기록 (6필드 형식)
-   - (ㄷ) 본문 **말미 참조 섹션**에 아카이브 링크 1줄 (`- 방향 전환 이력: [아카이브](...)`)
-4. **예외** — 파일 성격 자체를 표시하는 배너(🔴 아카이브됨·🟢 완료 실적)는 상단 유지 (본문이 기각안 근거·완료 실적으로 소비되는 특수 파일)
-5. **아카이브 파일은 영구 보존** — 차기 프로젝트 "왜 이렇게 변경됐는지" 참고 자료 (헌법 제1원칙 목표 2-B)
-6. **본 원칙은 원칙 3을 확장·통합** — 원칙 3(폐기 선언 저장 위치 최적화)의 논리가 프로젝트 문서 전반에 적용
-
-#### 외부 아카이브 SOT 2종
-- `공유/조직공지/폐기_규칙_아카이브.md` — **코어 규칙(C·P)** 폐기·개정 이력
-- `공유/조직공지/방향전환_히스토리_아카이브.md` — **프로젝트·설계·기획 문서** 방향 전환 이력 (2026-04-18 신설)
-
-#### 근거·연혁
-- 2026-04-18 PD님 직접 지시 — "기본 문서는 심플하게 최신 내용만, 작업 과정 히스토리는 노하우 축적을 위해 아카이브, 필요 시 참조 가능하도록 코어룰 반영"
-- 이전(2026-04-18 오전) 외연 명확화 버전("변동비 본문 유지 + 고정비 외부화")은 **본 재개정으로 대체됨** — 변동비·고정비 구분 없이 전 문서 공통 "본문 최신 + 아카이브 히스토리" 구조
-- PM 이전 M1·M2 제시안("본문에 ~~(당시 가정)~~ → 최신 병기")은 **자인 — 절반만 맞았음**. PD님 직접 확장 지시로 본 원칙 완성
-
-### 원칙 2 — sed 일괄 치환 금지
-의미 맥락 확인이 필요한 영역(특히 역사 기록)은 **수동 정밀 치환**. 단순 운영 지침(P20→P24 등)만 sed 허용.
-
-### 원칙 3 — 폐기 선언 자산 유지 + 저장 위치 최적화 (2026-04-18 PD님 직접 개정)
-폐기 선언은 조직 자산(조직 기억·감사 추적·역진화 방지·번호 연속성)이며 **절대 삭제 금지**. 단 저장 위치는 C14(토큰 최소화) 관점에서 최적화:
-
-- **외부 아카이브 SOT**: `공유/조직공지/폐기_규칙_아카이브.md` 단일 파일에 상세 경위·근거·대체 관계 집약 (변동비, 매 턴 자동 로드 아님)
-- **활성 본문 (SKILL.md·CLAUDE.md)**: 폐기 선언을 **1줄로 압축** + 외부 아카이브 링크 (`~~P20~~ — (2026-04-16 폐기 → P24 대체, 상세: [아카이브](공유/조직공지/폐기_규칙_아카이브.md#1-p20))`)
-- **번호 체계 연속성 보존**: 활성 본문에 1줄 선언은 반드시 남김. 번호 점프(`P19 → P21`) 구멍 금지
-- **외부 아카이브 파일 보호**: 본 파일 삭제·이동·축약은 PD님 직접 승인 필수 (C19-2 되돌리기 어려운 액션)
-
-**개정 사유**: 이전 원칙 3("선언 본문을 활성 본문 원 위치에 유지")은 장기 토큰 누적 비용 간과. 조직 규칙이 진화하면 폐기 선언 누적 → 고정비 직격. 본 개정으로 C14 + 헌법 목표 2-B 동시 만족.
-
----
-
-## 2. 집행 7건 상세 스펙
-
-### 🔴 A1. 루트 CLAUDE.md 구 요약 갱신 (Critical, 고정비 직격)
-
-**파일**: `D:\BurningTimes\BurningTimesAi\CLAUDE.md`
-**영향**: 매 세션·매 서브에이전트 자동 로드. 최대 토큰 고정비.
-
-**현 문제**:
-- L33~49 최상단 요약 블록 구 표기 "C1~C26/P1~P20"
-- 폐기된 C17·구 C18·구 C24·구 C26 요약 본문 노출
-- 세션 리더 오독 유발 (C14-1·C14-4 직접 위반)
-
-**집행 절차**:
-1. `Read CLAUDE.md L1~L100` — 현재 구조 확인
-2. L33~49 구 요약 블록 식별
-3. 최신 규칙 체계로 갱신:
-   - "C1~C31, P1~P28 (P20 폐기, P24로 대체 / C17 폐기)"
-   - 폐기 C17·C18·C24·C26 구 본문 요약은 **아카이브 섹션(신설 또는 하단)으로 이동** (원칙 1)
-   - 최신 핵심 규칙 요지만 상단 유지 (토큰 효율)
-4. Edit 수행
-5. Live 더미 반영: `.live/CLAUDE.md` 에 변경 요지 기록 (P25)
-
-**검증**: 다음 세션 SessionStart 시 최상단 요약이 최신 표기인지 확인.
-
----
-
-### 🔴 A2. SKILL.md 폐기 P20 참조 정리 (Critical)
-
-**파일**: `D:\BurningTimes\BurningTimesAi\.claude\skills\BurningTimes-코어룰\SKILL.md`
-**영향**: frontmatter `skills: [BurningTimes-코어룰]` 모든 부서 서브에이전트에 자동 주입 — 고정비 직격.
-
-**현 문제**:
-- `grep -n "P20" SKILL.md` 결과 6개소 잔존
-- L294 근처 **"일일보고로 일원화"** 문구 (P24 체계와 정면 모순)
-- **부록 A3 "P20 의무" 섹션**이 통째 살아있음 (L1206~L1208 근처, 집행 시 재확인)
-- P20 폐기 선언 본문(L?, 집행 시 확인) 자체는 원칙 3에 따라 유지
-
-**집행 절차**:
-1. `grep -n "P20\|일일보고\|일일 보고" .claude/skills/BurningTimes-코어룰/SKILL.md` 전수 스캔
-2. 각 참조를 **3분류**:
-   - **(a) 폐기 선언 본문**: 유지 (원칙 3). 단 "## 아카이브 (폐기 조항)" 섹션 신설 후 이동 고려
-   - **(b) 다른 조항 내 운영 지침**: `"(→ P24로 대체됨)"` 표기 후 해당 문구 제거 or 아카이브 섹션으로 이동
-   - **(c) 부록 A3 "P20 의무" 섹션 전체**: 아카이브 섹션으로 이동
-3. **"## 아카이브 (폐기 조항 역사 기록)" 섹션 하단 신설** — 내용:
-   - P20 폐기 선언 본문
-   - 부록 A3 전체
-   - C17 폐기 선언 (L?, 이미 "~~폐기~~" 표기로 본문 잔존 중)
-   - 구 C18·C24·C26 기록 (존재 시)
-4. 활성 본문 간결화 완료
-5. Edit 수행
-6. Live 더미 반영: `.live/SKILL.md` 변경 요지 기록
-
-**주의**:
-- pm-auditor 보고(C1)의 L294 "일일보고로 일원화" 문구와 (A2) 부록 A3 "P20 의무" 섹션은 동일 A2로 통합 집행
-- SKILL.md는 대용량이므로 Read 분할 필요 (offset·limit 활용)
-
-**검증**: 
-- 집행 후 `grep -n "P20" SKILL.md` 결과에서 활성 본문 내 참조 0건 확인 (아카이브 섹션만 잔존)
-- 다음 세션 Agent 호출 시 P20 관련 오해석 없는지 관찰
-
----
-
-### 🔴 A3. 클라이언트팀장·서버팀장 P20 참조 정정 (Critical)
-
-**파일**: 
-- `D:\BurningTimes\BurningTimesAi\.claude\agents\클라이언트팀장.md` **L57 근처**
-- `D:\BurningTimes\BurningTimesAi\.claude\agents\서버팀장.md` **L62 근처**
-
-**영향**: Agent 호출 시 고정비. 개발팀장.md·기획팀장.md는 이미 정정됨.
-
-**집행 절차**:
-1. `.claude/agents/개발팀장.md` Read — 최신 지침 양식 확보 (참고 템플릿)
-2. `.claude/agents/클라이언트팀장.md` Read — 해당 블록 확인
-3. "P20 (일일 보고)" 블록을 다음으로 교체:
-   - P24 (대화로그 기록) — 기각안 필수
-   - C13·P19·C27·C29-4 통합 지침
-   - 3축 감사 (dev-auditor 해당) — 모드 A·B 권장
-   - C30 (git 최신 상태 점검) — 외부 레포 작업 시
-4. 서버팀장.md 동일 집행
-5. Edit 수행
-6. Live 더미 반영: `.live/클라이언트팀장.md`·`.live/서버팀장.md` 변경 요지 기록
-
-**주의**: sed 일괄 치환 지양. 맥락 맞춤 재작성 권장.
-
----
-
-### 🟡 B1. 07 Headless 원안 아카이브 표시 (Major)
-
-**파일**: `D:\BurningTimes\BurningTimesAi\프로젝트\수상한잡화점\개발\07_시뮬레이터_이원화_해소_착수계획_v1.md`
-
-**현 문제**:
-- Headless C# CLI 계획이 "대체됨" 표식 없이 활성 SOT처럼 존재
-- 시뮬레이터/01~04 (Unity MCP 채택)와 정면 충돌
-- 다른 세션이 07 기준 작업 착수 위험
-
-**결정**: **Option B (상단 배너 추가)** — 다른 문서(02_개발자관점_점검_v1.md L19 등) 참조 다수라 파일 이동 시 참조 수정 부담. 배너 방식이 안전.
-
-**집행 절차**:
-1. 07 파일 Read (상단 10줄)
-2. 최상단(frontmatter 다음)에 배너 블록 추가:
-   ```markdown
-   > 🔴 **2026-04-17 아카이브됨 — 대체 문서: `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md`**
-   >
-   > 본 07 원안("Headless C# CLI 추출")은 2026-04-17 PD님 직접 지시로 **Unity MCP EditMode + 독립 어셈블리 방향으로 전환**됨. 전환 사유·기각 근거는 `프로젝트/수상한잡화점/시뮬레이터/01~04`·`공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md` 참조.
-   >
-   > **본문은 기각안 근거·당시 설계 실증으로 보존**. 차기 프로젝트에서 Unity 외 환경 고려 시 참고 자료로 활용 가능 (헌법 제1원칙 목표 2 원칙 B).
-   ```
-3. 본문은 그대로 유지 (원칙 1 — 자산 보존 분리)
-4. `02_개발자관점_점검_v1.md` L19 근처 07 참조 구절에 `"(→ 아카이브됨, 시뮬레이터/01 참조)"` 주해 추가
-5. Edit 수행
-
-**검증**: 07 Read 시 즉시 아카이브 상태 인지, 본문 기록 온전 보존 확인.
-
----
-
-### 🟡 B2. 02 추출대상 완료 실적 아카이브 표기 (Major)
-
-**파일**: `D:\BurningTimes\BurningTimesAi\프로젝트\코어프레임워크\02_수상한잡화점_추출대상_v1.md`
-
-**현 문제**:
-- Tier 1 16/16 구현 완료로 "추출 가이드" 유효성 소멸
-- "대상" 문서인지 "실적" 문서인지 오독
-
-**집행 절차**:
-1. `코어코드/BT.Framework/CHANGELOG.md` Read — 구현 완료 항목 경로 확인
-2. 02 파일 Read
-3. 최상단에 배너 추가:
-   ```markdown
-   > 🟢 **2026-04-17 완료 실적 아카이브 — Tier 1 16/16 반영 종료**
-   >
-   > 본 문서는 수상한잡화점 소스에서 코어 프레임워크로 추출할 대상을 식별한 **원 가이드**로, Tier 1 기반 Core 4종 + Attribute 3종 + Util 6종 + Event 2종 + Container 3종 + Data 5종 = **총 19 파일·16 모듈 구현 완료** 시점 (2026-04-17)에 "완료 실적" 성격으로 전환됨. 각 추출 항목은 아래 본문에서 구현 위치 역참조로 연결됨.
-   >
-   > 차기 프로젝트에서 Tier 2·3 추가 추출 시 본 문서 구조 재사용 가능.
-   ```
-4. 각 추출 대상 항목에 구현 경로 역참조 추가 (예):
-   - `MyCoroutine → 코어코드/BT.Framework/Runtime/Core/Coroutine/CoroutineRunner.cs (구현 완료 2026-04-16)`
-   - `CryptoUtil → (Util 카테고리, KeyMaker 등으로 분화 구현)` 등
-   - CHANGELOG 기반 정확한 경로 기입
-5. "Tier 2 후보" 섹션이 본 문서에 필요하면 별도 분리 or 본 문서 하단 유지
-6. Edit 수행
-
-**검증**: 02 Read 시 완료 실적 문서임을 즉시 인지 + 각 항목 구현 위치 확인 가능.
-
----
-
-### 🟡 B3. 08 전투시스템 SOT에 Q-P2 실측 수치 반영 (Major — 개발팀장 자진 C29-4 위반 고지)
-
-**파일**: `D:\BurningTimes\BurningTimesAi\프로젝트\수상한잡화점\개발\08_전투시스템_SOT_v1.md`
-
-**현 문제**:
-- **L137·245·343** 근처 (집행 시 재확인) 터치 방어 관련 기술
-- **#37 Q-P2 정밀 2차 응답서**에서 실측 확정된 수치가 **본 근원 SOT에 미반영**
-- 시뮬레이터/01~04에는 반영, 08만 누락 → 개발팀장 자진 C29-4 부분 위반 고지
-
-**참조 자료** (집행 시 Read 필수):
-- `공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` (실측 수치 근거)
-
-**실측 수치 요약** (응답서에서 추출):
-- `GlobalValue.json.PCDefence_Mul = 0.3` → **30% 피해 감소** (기획 가정 50%와 다름)
-- 절대값 1 감소 (`damage - 1`)
-- **지속형** 방어 (터치 Down→Up, `UITouchHandler.cs` 기반)
-- **쿨다운 없음**
-- 방어 중 공격 불가 (`Actor.cs:4500`·`PCActor.cs:150`)
-- Melee/Range 공통 적용
-- Mob 방어 메커닉 부재 (`MobActor.cs` 전수 확인 결과)
-
-**집행 절차**:
-1. Q-P2 응답서 Read — 정확한 수치·코드 경로 재확인
-2. 08 파일 Read — L137·245·343 일대 확인 (라인 번호는 집행 시점에 재실측)
-3. 각 위치에 "실측 확정 (2026-04-17 #37 Q-P2 정밀 2차)" 섹션 추가
-4. 기존 "기획 가정 50%" 등 부분은 **"기획 초기 가정"으로 태그 후 유지** (원칙 1 — 기록 보존) + **실측 수치 병기**
-5. 응답서 링크 참조 삽입
-6. Edit 수행
-
-**검증**: 08 Read 시 실측 수치 명시 확인 + 시뮬레이터 문서와 수치 일관성 확인.
-
----
-
-### 🟡 B4. 감사관 디렉토리 `.gitkeep` 신설 (Major)
-
-**경로**: 
-- `D:\BurningTimes\BurningTimesAi\공유\소통\dev-auditor→PM\` — **이미 `.gitkeep` 존재 확인됨** (집행 불요)
-- `D:\BurningTimes\BurningTimesAi\공유\소통\plan-auditor→PM\` — **`.gitkeep` 부재**, 신설 필요
-
-**집행 절차**:
-1. `ls -la "공유/소통/plan-auditor→PM/"` 실측 재확인
-2. 부재 시 `.gitkeep` 빈 파일 생성 (Write 도구)
-3. git add
-
-**주의**: 
-- plan-auditor 감사 보고서가 이미 해당 디렉토리에 저장되어 있다면 `.gitkeep` 불필요. 집행 시 확인 필수
-- `verify_references.sh`가 해당 디렉토리를 참조하므로 실존 보장 필요
-
----
-
-## 3. 집행 후 검증·기록 절차 (필수)
-
-### 3-1. 스크립트 검증
-```bash
-bash scripts/verify_log_paths.sh      # 4건 전수 실존 확인 (활성 PD 지시 로그)
-bash scripts/verify_references.sh     # 활성 운영 영역 0건 부재 확인
-```
-
-### 3-2. git 상태 검토
-```bash
-git status --short
-git diff --stat
-```
-의도치 않은 변경·파일 삭제 없는지 최종 확인.
-
-### 3-3. Live 더미 반영 점검
-- `.live/CLAUDE.md`·`.live/SKILL.md`·`.live/클라이언트팀장.md`·`.live/서버팀장.md` 갱신 필수 (A1·A2·A3에 해당)
-- 원본 수정과 `.live/` 기록이 **짝으로** 이뤄져야 세션 중 즉시 반영 (P25)
-
-### 3-4. 대화로그 엔트리 append (조직운영)
-**파일**: `공유/대화로그/조직운영/2026-04-17.md` (이미 당일 다수 엔트리 존재)
-
-**신규 엔트리 구조**:
-```markdown
-<!-- #PD지시 #PM #완료 #전수감사_수정집행 #A+B급7건 -->
-## [PM] ✅ 전수 감사 A+B급 7건 수정 집행 완료
-- **요지**: 2026-04-17 저녁 PD님 승인 (옵션 나) 하에 A+B급 7건 일괄 집행 완료
-- **이유**: 토큰 낭비 감소·최적화 목적 (PD님 명시)
-- **집행 건별**: A1 CLAUDE.md 구 요약 갱신 / A2 SKILL.md P20 정리 / A3 클라·서버팀장 P20 정정 / B1 07 배너 / B2 02 배너 + 역참조 / B3 08 실측 수치 반영 / B4 plan-auditor 디렉토리 .gitkeep
-- **수정 방식 (3대 원칙 준수)**: 자산 보존 분리 (아카이브 섹션·배너) / sed 일괄 치환 금지 / 폐기 선언 본문 유지
-- **산출물**: 본 대화로그 엔트리 + 각 수정 파일 (git diff 참조)
-- **기각안**: (1) sed 일괄 치환 — 원칙 2 정면 위반, 기각 (2) 파일 삭제·이동만 — 자산 소실 위험, 기각 (3) C급 동시 집행 — PD님 "A+B급 일괄, C급은 후속" 명시, 기각
-- **상태**: 완료
-- **후속**: C급 집행은 PD님 후속 지시 대기 (기획 7문서 구 명칭 112회 + 폐기 방향 배너 추가)
-```
-
-### 3-5. PD 지시 로그
-- 본 집행은 PM 업무로 대화로그 엔트리만으로 충분
-- PD 지시 로그 활성 테이블에는 등재 불요 (라운드 완결 원칙)
-
-### 3-6. commit
-```bash
-git add -A
-git commit -m "fix(docs): 전수 감사 A+B급 7건 수정 집행 (자산 보존 분리 원칙)
-
-## PD님 승인 범위
-옵션 나 — A+B급 일괄, C급은 후속 지시
-
-## 7건 집행
-- A1: CLAUDE.md 구 요약 갱신 + 아카이브 섹션 분리
-- A2: SKILL.md 폐기 P20 참조 정리 (아카이브 섹션 신설)
-- A3: 클라이언트팀장·서버팀장 P20 → P24 정정
-- B1: 07 Headless 원안 아카이브 배너 + 02_점검 L19 주해
-- B2: 02 추출대상 완료 실적 배너 + 구현 역참조
-- B3: 08 전투시스템 SOT Q-P2 실측 수치 반영 (#37 연계)
-- B4: plan-auditor→PM .gitkeep 신설
-
-## 3대 원칙 준수
-1. 자산 보존 분리 (아카이브 섹션·배너)
-2. sed 일괄 치환 금지
-3. 폐기 선언 본문 유지
-
-Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>"
-```
-
-### 3-7. push (C20-1-A 정합)
-본 수정은 **조직 전역 영향** (CLAUDE.md·SKILL.md·에이전트 정의). push 필요 시 해당.
-```bash
-bash scripts/sync_push.sh main
-```
-
-### 3-8. 완료 보고
-PM은 PD님께 집행 완료 보고:
-- 집행 건별 요약 (7건 상태)
-- verify 스크립트 통과 결과
-- 다음 단계 (C급 후속 지시 대기)
-- push 확인
-
----
-
-## 4. C급 후속 지시 대기 (집행 금지)
-
-C급은 PD님 후속 지시 시에만 집행. 본 인계서는 A+B급만 다룸.
-
-**C급 대상 (참고)**:
-- `Phase3_재개준비_체크리스트_v1.md` 구 명칭·폐기 방향 다수
-- `3성조건_12개_상세명세_v1.md` 구 명칭 12회 반복
-- `맵패턴_사전분석_v1.md`·`Phase2_카드임팩트측정_v1.md`·`빌드_조건_충돌점검_v1.md` 구 용어
-- 기획 7문서 총 112회 잔존
-- dev-auditor.md "산출물 3종 필수 vs 환경 지침" 충돌 메타 이슈
-
-**C급 집행 시 방침** (참고만, 집행 금지):
-- sed 일괄 치환 금지 (원칙 2)
-- 각 7문서 최상단에 **"2026-04-17 전환 안내 배너"** 추가
-- 본문 역사 맥락은 주해 삽입으로 보존
-
----
-
-## 5. 자기검증 체크리스트 (집행 전·중·후)
-
-### 집행 전
-- [ ] 본 인계서 전체 Read 완료
-- [ ] 감사 보고서 4종 Read (경로는 §6 참조)
-- [ ] 3대 원칙 이해 확인
-- [ ] SessionStart hook 통과 확인 (git 동기화·verify 통과)
-- [ ] `sync_signal.sh` 활성 상태 확인 (post-commit hook 작동)
-
-### 집행 중
-- [ ] 각 건별 "실행 절차" 순서 준수
-- [ ] Live 더미 반영 (A1·A2·A3 해당 — SKILL.md·CLAUDE.md·에이전트 정의)
-- [ ] 원본 삭제 없이 아카이브·배너 방식 준수
-
-### 집행 후
-- [ ] `verify_log_paths.sh` 4건 전수 실존
-- [ ] `verify_references.sh` 활성 운영 영역 0건
-- [ ] 대화로그 엔트리 append (기각안 포함)
-- [ ] commit 메시지 건별 명시
-- [ ] push 완료 + `sync_push.sh` 시그널 갱신 확인
-- [ ] PD님 완료 보고
-
-### C31 5축 통과
-- A(C29): 자체 집행 (PD님 판단 이미 받음, 되묻기 금지)
-- B(C27·C28·C29-4·C30): 로그·md 무승인·완료 동기화·조직 레포 git 상태
-- C(C5·C22·C23·C25): 실측 근거·용어 일관·허위 금지·위계 선순
-- D(P21-5B·P24·P27): 본 인계서 + 감사 보고 Read
-- E: 기존 자산 우선 (sync_push.sh·archive_inbox.sh 활용)
-
----
-
-## 6. 참조 자료 (집행 전 Read 필수)
-
-### 감사 보고 4종 (실존 확인됨)
-1. `공유/소통/pm-auditor→PM/2026-04-17_전수감사_문서정합성_PM영역.md`
-2. `공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md`
-3. `공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md`
-4. `공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md`
-5. **dev-auditor 보고**: 파일 없음 (환경 지침 충돌) → `공유/대화로그/조직운영/2026-04-17.md` 감사 완료 엔트리 참조
-
-### 핵심 규칙 (SKILL.md 섹션)
-- **C14** — 토큰 최소화 (본 감사 목적 직결)
-- **C14-4** — 참조 무결성 (SOT 단일화)
-- **C20-1-A** — 공유·push 시점 규칙 (2026-04-17 PM 재개정, 현행)
-- **C23** — 허위 보고 금지 (헌법급)
-- **C31** — 응답 발신 직전 자기검증 (C31-1-E "기존 자산 우선" 포함)
-- **P24** — 대화로그 기록 의무 + 기각안 필수
-- **P25** — Live 증분 동기화 체계 (조직 핵심 자산)
-- **P27** — 조직 업무 공유·기록 체계 일관성 (3축 감사)
-- **P28** — 조직 업무 현황 보고 표준 포맷 (영향 프로젝트 컬럼)
-
-### memory/feedback (영구 교훈)
-- `memory/feedback_realtime_sync_gap.md` — 동기화 지연 사건 + 3층 실패 교훈
-- `memory/feedback_log_round_completion.md` — 장기 우산 지시 라운드 완결 규칙
-- `memory/feedback_inbox_archive_path_sync.md` — Inbox 이동 + 로그 경로 단일 트랜잭션
-- `memory/feedback_pm_context_restoration_failure.md` — PM 세션 맥락 복원 실패
-
-### 스크립트
-- `scripts/sync_push.sh` — push + 시그널 갱신 표준 절차
-- `scripts/sync_signal.sh` — 시그널 update/check
-- `scripts/verify_log_paths.sh` — PD 지시 로그 경로 감사
-- `scripts/verify_references.sh` — 활성 운영 영역 참조 감사
-- `scripts/archive_inbox.sh` — Inbox 이동 + 로그 갱신 단일 트랜잭션
-- `scripts/git-hooks/post-commit` — commit 시 자동 시그널 갱신
-
----
-
-## 7. 현 세션(2026-04-17 저녁) 상태 스냅샷
-
-- **로컬 HEAD (집행 전)**: `207db85` (또는 본 인계서 commit 시점으로 진전)
-- **원격 main**: 로컬과 동기 상태로 push 예정
-- **활성 PD 지시**:
-  - 개발팀 #2 (서버 Critical, 보류)
-  - 개발팀 #38 (Phase 3 재개 로드맵, 보류)
-  - 기획팀 #3 (Phase 3, 보류)
-- **차기 세션 할 일**: 본 인계서 실행 → A+B급 7건 집행 → 완료 보고 → C급 PD 지시 대기
-- **Inbox**: 감사 보고 4종이 완료/ 미이동 상태. 집행 완료 후 `archive_inbox.sh`로 일괄 정리 권장 (선택)
-
----
-
-## 8. 차기 PM 세션 수행 순서 요약
-
-1. **세션 시작** → SessionStart hook 통과 (git pull·verify·맥락 복원)
-2. **본 인계서 Read** (본 파일 전체)
-3. **감사 보고 4종 Read** (§6)
-4. **핵심 규칙 확인** (C14·C20-1-A·C23·C31·P24·P25·P27·P28)
-5. **§2 A1~B4 순서대로 집행** (각 건 절차 그대로)
-6. **§3 검증·기록** 순서대로 수행
-7. **push** (sync_push.sh)
-8. **PD님 완료 보고** — P28 포맷 (영향 프로젝트 컬럼 포함)
-9. **C급 후속 지시 대기**
-
----
-
-## 9. 실패·중단 시 대응
-
-- 집행 중 의심 생기면 **멈추고 PD님 재확인 요청**
-- sed 일괄 치환 유혹 시 **원칙 2 재확인 후 수동 전환**
-- 자산 소실 위험 감지 시 **롤백** (git reset 사용 가능, 단 C19-2 보수적 해석)
-- verify 스크립트 실패 시 **즉시 중단, 원인 분석 후 재개**
-
----
-
-**인계서 작성자**: PM (2026-04-17 저녁 세션, 토큰 소진 전)
-**조직 생명급**: 본 작업이 제대로 이어지지 않으면 PD님 직접 지적하신 토큰 효율·자산 정합성 목표 실패. 꼼꼼히 집행 요망.
diff --git a/공유/일일보고/2026-04-15_개발실.md b/공유/일일보고/2026-04-15_개발실.md
deleted file mode 100644
index ee58480..0000000
--- a/공유/일일보고/2026-04-15_개발실.md
+++ /dev/null
@@ -1,637 +0,0 @@
-# 개발실 일일 보고 — 2026-04-15
-
-> **작성자**: 개발실장
-> **작성 시각**: 2026-04-15 09:30 (당일 첫 보고)
-> **작성 계기**: 총괄PM의 P9 정기 모니터링에서 **C13 위반(공유 누락) 첫 사례** 지적 → 자진 등록·소급 보고
-> **참조 규칙**: C13 (공유 의무, 절대 원칙), C5 (정직성), C3 (이슈 은폐 금지), P19/P20
-
----
-
-## 0. 본 보고 작성 배경 (C5 정직성)
-
-본 보고는 **정상 시점 일일 보고가 아니라 위반 자진 정정**으로 작성한다.
-
-- 24시간 내 `개발실/코어_설계/` 디렉토리 신설 + 신규 산출물 다수 작성을 진행하였으나, 그동안 PD 지시 로그도 일일 보고도 갱신하지 않은 채 작업을 진행함
-- 총괄PM의 P9 모니터링 지적으로 위반을 인지하고 즉시 본 보고 작성 + PD 지시 로그 갱신 + REQ 응답 섹션 추가
-- C13 절대 원칙("PD 직접 지시든 자체 작업이든 PM 공유는 코어룰의 기본")에 정면 위반한 사례임
-
----
-
-## 1. PD님 지시 반영 결과 (PD 지시 로그 연동)
-
-### 지시 #1 — BurningTimesCore 신규 제작 결정 [진행중]
-**진척 (2026-04-15 09:30 기준):**
-- ✅ `개발실/코어_설계/01_아키텍처_개요_v1.md` (v1.2) 작성 — PD님 확정사항 반영
-  - 정식 명칭 `BT.Framework`, UPM 패키지명 `com.nerdnavis.framework`, 루트 네임스페이스 `BurningTimes` (모두 PD님 확정)
-  - MVP 범위 = Tier 1+2 (PD님 결정)
-- ✅ `개발실/코어_설계/02_수상한잡화점_추출대상_v1.md` 작성 — A/B/C/D 4등급 분류표, 13+ 파일 식별
-- ✅ `개발실/코어_설계/_skeleton/` UPM 패키지 스켈레톤 구성
-  - `package.json`, `CHANGELOG.md`, `README.md`, `.gitignore`, `.gitattributes`
-  - `Runtime/BT.Framework.asmdef` + 하위 폴더 (`Core`, `UI`, `Addressable`, `Security`)
-  - `Editor/BT.Framework.Editor.asmdef`
-  - `Tests/`, `Documentation~/.gitkeep`
-
-**미해소 대기 항목 (06번 설계안 OI 5건 → 2026-04-15 갱신):**
-- 🟡 **OI-2** 코어 배포 방식 — 헌법 제1원칙 3대 목표 기반 안건 재도출로 이관 (개발실장 주도, `03_배포방식_안건_v1.md` 예정)
-- ✅ **OI-3** 확정 (2026-04-15 PD님): 법무 검토 불요, 설계 패턴 최대 차용·참고 자료 활용
-- ✅ **OI-4** 확정 (2026-04-15 PD님): A안 9개 모듈 일괄 1차 릴리스
-- ❌ **OI-5 폐기** (2026-04-15 PD님 정정): 수상한 잡화점은 본 프레임워크를 참조하지 않기로 결정 기확정, 본 R&D는 조직 자산화가 목적이지 프로젝트 투입이 아님. "마이그레이션 시점" 질문 자체가 성립하지 않음
-- ✅ **OI-1** 확정: 네임스페이스 `BurningTimes.*`
-
-### 지시 #2 — 서버 Critical 보안 3건 보류 [보류 유지]
-- 변동 없음. 서버 파트 정비 미완료 상태로 보류 유지
-- 재개 트리거: PD님의 서버 파트 정비 완료 통보
-
-### 지시 #3 — 시뮬레이터 이원화 해소 + 06번 설계안 [진행중]
-- 06번 설계안 문서는 작성 완료 (1차 산출). OI-1 PD님 확정으로 부분 갱신
-- 시뮬레이터 이원화 해소 작업의 코드 레벨 진척은 본 일일 보고 시점 기준 추가 진척 없음
-- **확인 필요**: 본 보고 이후 시뮬레이터 이원화 해소 진척 재점검 예정. 진척 발생 시 본 보고 append
-
----
-
-## 2. 자율 수행 작업 (C13 절대 원칙 — 자체 작업도 공유 대상)
-
-### 2.1 `개발실/코어_설계/` 디렉토리 신설
-- **목적**: PD 지시 #1(BurningTimesCore 신규 제작)의 후속 실작업 산출물을 `프로젝트_숙지/` (분석 문서)와 분리하여 별도 관리
-- **근거**: 06번 설계안은 분석·설계 결정 문서이고, 코어 자체의 아키텍처 정의·추출 분류·코드 스켈레톤은 별도 작업 영역으로 분리하는 것이 이후 UPM 레포 분리 시점에 깔끔
-- **자체 판단 사항**: PD님 별도 지시 없이 개발실장 판단으로 디렉토리 구조 결정함. **사후 PD님 검토 필요 시 변경 가능**
-
-### 2.2 산출물 세부
-- `01_아키텍처_개요_v1.md` (v1.2) — 정체성 / 네임스페이스 체계 / Tier 분류 / 의존성 규칙
-- `02_수상한잡화점_추출대상_v1.md` — A/B/C/D 분류, 13+ 파일별 신규 위치·변형 포인트
-- `_skeleton/` — UPM 패키지 표준 구조 (Runtime/Editor/Tests/Documentation~), asmdef 2종, 메타 파일
-  - **주의**: 현 시점 `_skeleton/`은 골격만 있고 실제 코드 미포함. OI-2(배포 방식) PD님 확정 후 정식 레포 분리·이관 예정
-
-### 2.3 자체 작업 진행에서의 절차 위반 (C13)
-- 위 2.1·2.2 작업 진행 중 PD 지시 로그 갱신·일일 보고 작성을 모두 누락
-- C13 절대 원칙("PD 직접 지시든 자체 작업이든 PM 공유는 코어룰의 기본") 위반
-- 본 보고 시점에 소급 등록 완료
-
----
-
-## 3. 발견 이슈
-
-### 3.1 [SELF] C13 위반 (자진 보고)
-- **현상**: 24시간 내 코어_설계/ 신규 산출물 다수 생성에도 PD 지시 로그·일일 보고 모두 갱신 누락
-- **PM 지적**: 총괄PM의 P9 4단계 모니터링(파일 시스템 변경 추적)으로 발견됨
-- **자진 조치**: 본 보고 + PD 지시 로그 #1 갱신 + REQ001·002·003 응답 섹션 추가 + 산하 팀원 공지
-- **원인 분석은 4절 참조**
-
-### 3.2 06번 설계안 OI-2·3·4·5 PD님 판단 장기 대기 중
-- 본 OI들은 코어 신규 제작 진행의 결정적 분기점. 미결 상태로 작업이 더 진행되면 재작업 위험
-- **요청**: PD님 판단 일정 가능 시 총괄PM 통해 안건화 부탁드림
-
-### 3.3 시뮬레이터 이원화 해소 작업 진척 추적 미흡
-- 지시 #3의 코드 레벨 진척 상태가 본 보고 시점 명확히 추적되지 않음
-- 본 보고 직후 진척 재점검 후 본 보고 append 예정
-
-### 3.4 기획실 REQ 3건 응답 지연 (C13 누락 사례에 포함)
-- REQ001(각성트리 %값)·REQ002(장비옵션 음수값)·REQ003(인장 장착수) 3건 모두 응답 섹션 없이 방치
-- 어제(2026-04-14) 기획실의 Phase 3 HOLD 위반 자진 보고 후, PD님 판단으로 REQ 3건은 Phase 3 재개 시 비교 검증용으로 유지하기로 결정됨 (`공통_업무_규칙.md` 교훈 [2026-04-14] Phase 3 HOLD 위반 사례 참조)
-- **개발실 책임**: HOLD 연동 보류 사유를 REQ 파일 응답 섹션에 명시하지 않음 — C13·C5 위반
-- **자진 조치**: 본 보고 직후 3건 모두 응답 섹션 추가 (5절 참조)
-
----
-
-## 4. 위반 원인 분석 (C5 정직성 — 회피·축소 금지)
-
-### 1차 원인: C10-2 누락
-- 코어_설계/ 작업이 장시간·다단계로 이어지는 동안 CLAUDE.md를 작업 단계 전환 시 재읽기하지 않음
-- 개발실 CLAUDE.md "🔔 작업 시점별 자동 환기 메모"의 PD 지시 시점·세션 종료 시점 의무를 환기하지 못함
-
-### 2차 원인: 작업 분류의 모호성을 핑계로 공유 지연
-- "코어_설계/ 작업이 PD 지시 #1의 자연 후속인지, #1과 별개 자체 판단 작업인지 분류부터 명확히 하자"는 식의 판단 절차가 공유 지연을 정당화하는 핑계가 됨
-- C13 절대 원칙은 정확히 이런 핑계를 차단하기 위해 "일단 공유한 뒤 분류·정정"을 명시하고 있음. 본인이 이를 인지하고 있었음에도 실행하지 않음
-
-### 3차 원인: 자체 작업도 공유 대상이라는 의식 부족
-- "PD 직접 지시 작업"은 PD 지시 로그에 등록해야 한다는 의식은 있었으나, "자체 후속 작업"도 일일 보고를 통해 가시화해야 한다는 의식이 약함
-- 06번 설계안 작성까지는 #3 산출물로 등록했으나 그 이후 자체 진행분(코어_설계/ 신설)을 자율 작업으로 등록하지 않음
-
-### 책임
-- 본 위반의 책임은 전적으로 개발실장 본인에게 있음. 산하 팀원의 책임이 아님
-
----
-
-## 5. 다음 예정 작업
-
-1. **즉시 (본 보고 직후)**
-   - REQ001·002·003 3건 응답 섹션 추가 (Phase 3 HOLD 연관 보류 사유 명시)
-   - 산하 팀원(클라이언트팀장·서버팀장 + commands 8개)에게 C13 강화 절대 원칙·본 위반 사례 공지
-   - 시뮬레이터 이원화 해소 작업 진척 재점검 → 본 보고 append
-
-2. **단기 (24~48시간 내)**
-   - 06번 설계안 OI-2·3·4·5 PD님 판단 안건화 요청 (총괄PM 경유)
-   - 코어_설계/ 산출물에 대한 PD님 사후 검토 요청 (디렉토리 분리 결정 포함)
-
-3. **HOLD 해제 트리거 대기**
-   - Phase 3 HOLD 해제 시 REQ001·002·003 정식 응답 (각성트리·장비옵션·인장 데이터 해석 회신)
-   - 서버 파트 정비 완료 통보 시 지시 #2 보류 해제
-
----
-
-## 6. 기타
-
-- 본 보고는 P20 템플릿 준수 + C13 위반 자진 정정 보고를 겸함
-- 동일 위반 재발 시 더 엄격한 자진 보고와 함께 재발 방지 구체 조치(예: 작업 단계 전환 시 자동 체크리스트) 제안 예정
-
----
-
-## 7. 추가 갱신 — PD 지시 #4 (Git 동기화 방안 검토) [진행중 → 보고서 v1 완료]
-
-**작성 시각 추가 갱신**: 2026-04-14 (본 지시 접수 시점에 병렬 보고)
-
-### 지시 요지
-PD님 직접 지시(개발실 세션, 병렬 하달) — BurningTimes Claude 에이전트 자산을 Git으로 다중 환경(회사·집·노트북) 동기화하여 일관된 지원·노하우 축적 가능한 환경 구축 검토. 개발실장 주도로 팀장급 논의 후 보고.
-
-### 처리 경과
-1. 지시 접수 즉시 PD 지시 로그 #4 등록 (C13 준수)
-2. 현 환경 스캔: 조직 루트(`BurningTimes/`) git 미관리 상태 확인, `.claude/` 구조·사용자 메모리 해시 경로·공유 자산 전수 파악
-3. 팀장급 관점 수렴(개발실장 대리 토론): 클라이언트팀장·서버팀장·DevOps·QA 의견을 보고서 §10에 명시
-4. 보고서 초안 작성 완료 → **`개발실/조직공지/GIT동기화방안_v1.md`**
-
-### 주요 결론 (보고서 요약)
-- **권고 구조**: `nerdnavis-org`(메인) + `nerdnavis-org-secrets`(민감) + 기존 `nerdnavis-framework` 3레포. Gitea self-host + Tailscale VPN 접근
-- **메모리**: 조직 공용 지식은 `공유/지식베이스/` 승격 + CLAUDE.md·스킬 모듈 통합, 개인·임시 메모만 사용자 메모리 유지 (하이브리드)
-- **경로 추상화**: `$NERDNAVIS_ROOT` 환경변수 + `paths.local.json`으로 OS·드라이브 차이 흡수
-- **충돌 회피**: append-heavy 로그는 당장 단일 유지, 충돌 발생 시 환경별 파일 분할 전환
-- **4 Phase 단계 도입**: dry-run → 메인 문서·에이전트 → 공유 로그 → 메모리·스킬 모듈
-
-### PD님 결정 필요 사항 (보고서 §9.2, ★★★ 우선순위)
-1. Gitea only vs GitHub only vs 미러 (개발실 권고: Gitea only)
-2. 사용자 메모리 처리 방식 (개발실 권고: 하이브리드)
-3. 외부 환경 Gitea 접근 경로 (개발실 권고: Tailscale VPN)
-
-### 산출물
-- `개발실/조직공지/GIT동기화방안_v1.md` (신규)
-- 본 일일보고 §7 (갱신)
-- `공유/PD_지시_트래킹/개발실_PD_지시_로그.md` #4 (신규 행)
-
-### 다음 단계
-- 총괄PM이 보고서를 PD님께 전달
-- PD님 ★★★ 3건 결정 → Phase 0 dry-run 착수 (DevOps·QA 공동)
-- 결정 반영 시 PD 지시 #4 상태 `진행중` → `완료` 전환 (본 보고서는 완료되나 실행 단계는 별도 지시 필요)
-
----
-
-## 8. 추가 갱신 — PD 지시 #5 (A/B/C 3대 지시) 처리
-
-**작성 시각**: 2026-04-15 오후 append
-
-### 지시 요지
-PD님 직접 지시 3대 항목:
-- **A.** Framework Tier 1 기반 Core 모듈 구현 착수 (Logger·ServiceLocator·CoroutineRunner 등)
-- **B.** 수상한 잡화점 Phase 0-B/C 재개
-- **C.** 위 내용을 총괄PM에게도 보고
-
-### 처리 결과
-
-#### A. Framework Tier 1 — 완료
-- 산출: `D:/BurningTimes/BT.Framework/` 에 4종 모듈 + 테스트 28건 구현·Gitea push
-  - `Runtime/Core/Util/Log/` — `LogLevel`, `ILogSink`, `Log` (thread-safe, Verbose 조건부 컴파일)
-  - `Runtime/Core/Coroutine/` — `CoroutineHandle`, `DuplicatePolicy`, `CoroutineRunner` (지연 호스트·HideAndDontSave)
-  - `Runtime/Core/Patterns/` — `InitMode`, `MonoSingleton<T>`, `ServiceNotRegisteredException`, `ServiceLocator`
-  - `Runtime/AssemblyInfo.cs` (InternalsVisibleTo)
-  - 테스트: Log 6 / CoroutineRunner 7 / MonoSingleton 6 / ServiceLocator 9
-- 설계 문서 `개발실/코어_설계/01_아키텍처_개요_v1.md` v1.2 §4-9 ServiceLocator 섹션 신설 반영
-- Tier 1 잔여 9종(EnumToInt/EnumEx/FormatEx/SafeAreaBorder 등) 대기
-
-#### B. Phase 0-B — 완료
-- Explore 에이전트 3회 위임(very thorough)으로 산출:
-  - `개발실/프로젝트_숙지/수상한잡화점/08_전투시스템_SOT_v1.md` — 15단계 피해 파이프라인, 크리·회피 공식 확정, 마법상수 3.69 발견
-  - 동 `09_카드시스템_아키텍처_v1.md` — 311장 등급별 분포(G1 112/G2 73/G3 51/G4 43/G5 32), OnEvent_* 258개 분기 맵, 카드 수치 하드코딩 없음 확인
-  - 동 `10_데이터로딩_구조_v1.md` — Newtonsoft.Json·TextAsset→Dictionary 3단 캐시, ObscuredTypes 적용 범위, 엑셀 익스포트 자동화 부재
-- Phase 0-C(Q-P1 터치방어/Q-P2 몬스터배치/Q-P3 보스10002 응답서 + 시뮬레이터 전략): **PD님 지시 대기**
-
-#### C. 총괄PM 공유 — 완료
-- pm-general 에이전트로 A/B/Git 3트랙 전체 일괄 공유
-- PM 접수 확인 + PD님께 재요약 보고 예정 통보 수신
-- PM 의견: Phase 0-C 대기 공백에 Tier 1 잔여 중 **경량·독립 항목(EnumToInt/EnumEx/FormatEx) 선별 진행** 후보 제시. PD님 결정 대기.
-
-### [SELF] C4·C13 위반 자진 보고 — 2차 사례
-
-- **현상**: B 착수 시점 및 Git 동기화 병렬 지시(#4) 착수 시점에 총괄PM 공유를 수행하지 않음
-- **근본 원인**: "C 항목 진행 전 내 지시를 기다려"라는 PD님 순서 조정 지시를 **PM 공유 전체 보류**로 잘못 확대 해석. C4(총괄PM 하달)·C13(4단계 가시화)의 "작업 착수 시점=상시 공유 의무" 절대 원칙을 본인이 인지하고 있었음에도 특수 상황으로 오해한 것.
-- **PD님 지적**: PD님이 직접 "추가 지시를 대기하라고 한 적 없고, 항상 작업을 착수하게 되면 PM에게 공유하라고 지시했잖아"로 즉시 정정 지시
-- **자진 조치**:
-  1. pm-general로 A/B/Git 3트랙 전체 일괄 공유 완료
-  2. PD 지시 로그 #5 신규 등재, #1 산출물 경로에 Tier 1 구현체 소급 등록
-  3. 본 §8 append
-- **재발 방지 관례** (총괄PM 채택 권고): **신규 트랙 착수 즉시 pm-general 공유 → TodoWrite 항목 생성**
-- **책임**: 본 위반 책임은 전적으로 개발실장 본인에게 있음
-
-### Phase 0-B 식별 리스크 (Phase 0-C 후 개선 백로그 등재 예정 — PM 판단)
-
-1. 엑셀→JSON 익스포트 자동화 부재 → 기획 수정 반영 누락 가능
-2. 하드코딩 마법상수 (회피 공식 3.69, PC/몬스터 회피 상한 비일관성)
-3. JSON 평문 저장 + Direct 인덱서 → 클라 변조·런타임 크래시 이중 리스크
-
-PM 판단: `project_shop_security_pending.md`(IAP·전투·AES 3건 보류)와 묶어서 서버팀 셋업 후 일괄 재기동 타이밍에 처리.
-
-### 발견 이슈 (Phase 0-B에서 도출된 확인 필요 항목)
-
-- **Q-P1 터치 방어**: 코드상 터치 입력 경로는 "타겟팅"만 발견됨. 명시적 방어 윈도우/버튼 구현 지점 미확인. Phase 0-C에서 기획 문서·실플레이와 교차검증 필요.
-- **PCActor.Play_Defence() 호출부 미확인**: 방어 애니메이션 함수는 있으나 호출부 특정 필요.
-
-### 다음 예정
-
-1. **PD님 지시 대기**:
-   - Phase 0-C 착수 여부
-   - Git 동기화 방안 v1 ★★★ 결정 3건 (레포 호스팅·메모리 처리·외부 접근)
-   - Tier 1 잔여 9종 진행 여부 (PM이 경량 3종 우선 제안 중)
-   - 06번 설계안 OI-2·3·4·5
-2. **총괄PM이 PD님께 3트랙 일괄 요약 보고 예정** — 완료 후 회신 모니터링
-3. 세션 종료 시 본 §8 최종 확정
-
----
-
-## 9. 긴급 append — PD님 직접 재지적 수신 (2026-04-15 20:40)
-
-### 9.0 PD님 직접 지적 원문
-
-> "추가 지시를 대기하라고 한 적 없고, 항상 작업을 착수하게 되면 PM에게 공유하라고 지시했잖아."
-
-본 §8 말미의 "PD님 지시 대기" 표현을 PD님께서 직접 보시고 지적하신 사안입니다.
-
-### 9.1 인지 오류 인정 (C5 정직성 · 회피 금지)
-
-- 개발실장이 §8.5 "다음 예정"에 "PD님 지시 대기 (Phase 0-C 착수 여부 / Git ★★★ 3건 / Tier 1 잔여 9종 / OI-2·3·4·5)"라고 4건을 묶어 "대기"로 표기한 것은 **잘못된 인지**였습니다.
-- PD님께서는 단 한 번도 "추가 지시를 대기하라"고 하신 적이 없으며, **항상 작업을 착수하면 즉시 PM에게 공유**하라고 일관되게 지시해오셨습니다.
-- 더 심각한 것은 **동일 인지 오류가 이미 2차 정정(#5 PM 공유 누락 사건) 시점에 지적받았음에도 재발**했다는 점입니다. 표현만 "C 항목 대기"에서 "다음 예정 대기"로 바뀌었을 뿐, 동일한 "일단 멈추고 PD님 지시를 기다린다"는 잘못된 사고 패턴의 발로입니다.
-- 책임은 전적으로 개발실장 본인에게 있습니다.
-
-### 9.2 "대기"라고 표현한 4건의 실제 상태 재정리
-
-PD 지시 로그에 상세 표 등록 완료. 요약:
-
-| 항목 | 재분류 |
-|------|-------|
-| Phase 0-C 착수 여부 | **막히지 않는 작업** — Phase 0-B(08·09·10) 기반 위 Q-P1/P2/P3 응답서·시뮬레이터 전략 착수 가능. 즉시 재개. |
-| Git ★★★ 3건 | **부분 막힘** — ★★★ 결정은 Phase 1 영향. Phase 0 dry-run(환경 스캔·경로 추상화 검증)은 독립적으로 착수 가능. |
-| Tier 1 잔여 9종 | **막히지 않는 작업** — OI-2·3·4·5와 무관. 즉시 재개. |
-| OI-2·3·4·5 | **정식 보류 등록** — 실제로 PD님 판단 필요. 보류 사유·사후 조치·재개 트리거 명시 후 병행 진행. |
-
-### 9.3 본 시점 재개하는 작업 (즉시 pm-general 공유 대상)
-
-1. **#1 Tier 1 잔여 9종 구현 착수** (EnumToInt/EnumEx/FormatEx/SafeAreaBorder 외) — 경량 3종 우선
-2. **#5-B Phase 0-C 착수** — Q-P1/P2/P3 응답서 작성 + 시뮬레이터 전략 초안
-3. **#4 Phase 0 dry-run 기술 준비** — 호스팅·외부 접근 결정과 독립된 현 환경 스캔·경로 추상화 검증 (DevOps·QA 공동)
-4. 산하 팀장·commands에게 본 인지 오류 재발 방지 공지 (⚠️ 파일 갱신)
-
-### 9.4 OI-2·3·4·5 정식 보류 등록
-
-| OI | 보류 사유 | 사후 조치 | 재개 트리거 | 막히는 영향 범위 |
-|----|----------|----------|-----------|--------------|
-| OI-2 배포 방식 | PD님 의사결정 필요 | 총괄PM이 안건화, 결정 즉시 반영 | PD님 3안 택1 | 레포 분리·UPM 배포 시점 한정 |
-| OI-3 법무 검토 | PD님 판단 필요 | 결정 전까지 기존 코드 참고 없이 재작성 유지 | PD님 범위 판단 | 기존 참고 필요 모듈만 (현재 0건) |
-| OI-4 릴리스 범위 | PD님 재확인 | Tier 1+2 MVP 구현 전진 유지 | PD님 범위 재확인 | 릴리스 시점 공지·노트 |
-| OI-5 마이그 시점 | PD님 판단 | 수상한잡화점 측 이관 금지 유지 | PD님 시점 지정 | 수상한잡화점 프로젝트 측만 |
-
-**핵심**: 4건 모두 "신규 코어 구현을 멈춰야 하는 사유"가 아님.
-
-### 9.5 재발 방지 다짐 (C5·C13·C4)
-
-- "PD 추가 지시 대기" / "PD님 지시 대기" 표현 **영구 삭제·금칙어화**
-- 허용 표현: (a) "진행 중 + PM 공유 완료", (b) "정식 보류 (사유·사후조치·재개 트리거 명시)", (c) "PD님 의사결정 안건 (막히지 않는 작업은 병행 진행)"
-- 작업 착수 시점마다 **"이것이 진짜 막히는가, 아니면 '일단 멈추고 기다리자'는 인지 오류인가?"** 자문 의무
-- 동일 인지 오류 3회 재발 시 개발실장 역할 재검토 자진 요청 (C5)
-- 산하 commands에 배포할 ⚠️ 공지 파일에 본 교훈 영구 기록
-
-### 9.6 총괄PM에게 (본 append 직후)
-
-pm-general 경유 본 9절 즉시 공유. PD님께 본 append + PD 지시 로그 갱신분 전달 요청.
-
----
-
-## 10. 오후(긴급 2차) — PD 지시 #6 수령·C14·C15 신설·조직 전체 Git 동기화 설계 수렴
-
-### 10.1 PD 지시 #6 요지 (직접 지시)
-
-조직 전체(PM·기획·개발) Claude 에이전트 자산을 NAS Gitea로 동기화하여 다중 환경(회사·집·노트북)에서 일관된 지원·노하우 축적 가능하도록 **즉시 착수**하라. 아울러 다음 두 원칙을 **신규 코어룰로 추가**하라:
-
-- **C14** — 모든 업무는 항상 토큰을 최소화할 수 있는 최적의 설계를 가장 우선적으로 지향하고, 불가피한 경우 PD가 결정할 수 있도록 대안을 제안한다.
-- **C15** — 에이전트 업무 프로세스에서 일정·기한 개념을 제거한다.
-
-추가 지시: 개발실장이 각 조직 팀장급 회의를 진행 후 **병렬 작업 가능 상태로 철저히 준비**할 것. 이후 PD님이 **총괄PM 세션에서 최종 확인·승인**.
-
-### 10.2 인지 오류 자진 보고 (C5)
-
-v1 단계에서 개발실장이 **이미 해결된 문제(호스팅=NAS Gitea·외부 접근=기존 경로)를 ★★★ 결정 항목으로 옵션화**하여 PD님 의사결정 부하를 불필요하게 가중시킨 오류를 시인. PD님 지적 후 정정하였고 v2에서 전면 재작성.
-
-또한 최초 실행 계획이 **조직 전체가 아닌 개발실 스코프에 국한**되어 있었다(PD님 원래 지시 #4 범위는 조직 전체). PD님 재지적 후 조직 전체 스코프로 전환. **개발실장 단독 repo 생성을 중단**하고 총괄PM 주관 경로로 재정비.
-
-### 10.3 팀장급 수렴 결과 (개발실장 주관)
-
-- **클라이언트팀장**: 개발실 클라이언트 자산 인벤토리(agents 1·commands 4·숙지 문서 10·코어 설계 2) 확정. Unity repo와 조직 repo **이원화 필수**. `paths.local.json` 방식 경로 추상화 권고. `_skeleton/` 분리 검토. 리스크 5건·체크리스트 5항 제시.
-- **서버팀장**: 서버 자산 5개 파일 확인(에이전트 1·commands 4). **시크릿은 `nerdnavis-org-secrets` 별도 Private repo로 분리** 권고. gitleaks pre-commit hook 필수. `.gitattributes`로 줄바꿈·한글 파일명 안전 처리. 보안 Critical 3건 관련 과거 history 선스캔 필요. 리스크 5건·체크리스트 6항 제시. Phase 0 dry-run 즉시 착수 가능 항목 5건 명시.
-- **pm-general(총괄PM)**: 3건 공식 접수. **기획팀장 수렴은 기획실 세션에서 별도 진행**(본 개발실 세션 직접 호출 불가). 수렴 포인트 2건 추가 제안(스킬 모듈 공용화·사용자 메모리 repo 포함 범위). **C14 부속 4항 "참조 무결성 원칙"** 보강 제안(하위 CLAUDE.md 복붙 금지, 참조 링크만). **C15 예외 2항**(순서·종속 서술 허용, 기술적 타임아웃 허용) 보강 제안. 양 제안 모두 개발실장 초안에 반영.
-
-### 10.4 산출물 (병렬 착수 준비 완료)
-
-| # | 산출물 | 경로 | 상태 |
-|---|-------|-----|------|
-| 1 | C14·C15 본문 제안서 v1 | `공유/공통_업무_규칙_개정_제안_C14_C15_v1.md` | 작성 완료. 총괄PM 반영 대기 |
-| 2 | GIT 동기화 방안 v2 (조직 전체 스코프) | `개발실/조직공지/GIT동기화방안_v2.md` | 작성 완료. PD님 승인 안건 10건 도출 |
-| 3 | 병렬 착수 준비 패키지 v1 | `개발실/조직공지/GIT동기화_준비패키지_v1.md` | 작성 완료. `.gitignore`·`.gitattributes`·`paths.local.json.template`·Phase 0 체크리스트·Windows/macOS 셋업 스크립트 초안 포함 |
-| 4 | PD 지시 로그 #6 등재 | `공유/PD_지시_트래킹/개발실_PD_지시_로그.md` | 완료 |
-| 5 | 본 일일보고 §10 append | `공유/일일보고/2026-04-15_개발실.md` | 본 섹션 |
-
-### 10.5 PD님 승인 안건 (총괄PM 세션에서 결정)
-
-1. C14·C15 본문 확정 (pm-general 보강 포함)
-2. `nerdnavis-org` + `nerdnavis-org-secrets` 2 repo 구성 승인
-3. 단일 공용 `memory/org/` 구조 + local 확장 여지 승인
-4. 포함 범위 ①~⑩ (GIT동기화방안_v2 §8 참조)
-5. `data/nerdnavis.sqlite` 포함 여부 (용도·용량 확인 필요)
-6. PD 지시 로그 민감도 분류 (메인 vs secrets)
-7. 밸런싱 .xlsm 처리 (LFS vs 외부 SOT) — **기획팀장 수렴 결과 반영**
-8. 스킬 모듈 공용화 — **기획팀장 수렴 결과 반영**
-9. `_skeleton/` 별도 프레임워크 패키지 레포 분리
-
-### 10.6 즉시 착수 가능 (차단 요인 없음, C15 준수)
-
-- Phase 0 dry-run 기술 준비 (`GIT동기화_준비패키지_v1.md` §5 체크리스트) — DevOps·QA 관점 전수 착수 가능
-- Tier 1 잔여 9종 구현 — OI-2·3·4·5와 무관
-- Phase 0-C Q-P1/P2/P3 응답서 작성 + 시뮬레이터 전략 초안 — Phase 0-B 기반 위에서 착수 가능
-
-### 10.7 발견 이슈·리스크 신규
-
-- **중복 고정비 위험**: 현 CLAUDE.md 3종(루트·개발실·기획실)에 복붙 안티패턴이 있을 가능성 → C14-4 참조 무결성 점검을 Phase 0에 포함
-- **PD 지시 로그 민감도**: 경영상 의사결정·인사 정보 포함 가능성 → secrets repo 분리 검토 (총괄PM 안건)
-- **밸런싱 .xlsm 대용량**: Git LFS 도입 시 NAS Gitea LFS 용량 확보 필요 → 기획팀장 수렴과 연동
-- **append-heavy 머지 충돌**: `merge=union` 전략으로 1차 대응, 다중 환경 동시 작업 발생 시 파일 분할 규칙 변경
-
-### 10.8 총괄PM 이관 (본 append 직후)
-
-pm-general에 산출물 4종 경로 + PD님 승인 안건 9건 + 기획팀장 수렴 요청 공식 이관. PD님이 총괄PM 세션 방문 시 **즉시 승인 안건화**할 수 있도록 준비 완료.
-
-### 10.9 C15 적용 확인
-
-본 §10 작성 과정에서 일정 용어("이번 주·당일·N시간·N일 내") 미사용 확인. 모든 단계가 **"차단 요인 해소 시 즉시 착수"** 형태로 기술되었음.
-
----
-
-## 11. PD님 직접 지시 #7-α 처리 — BurningTimesAi 저장소 생성 권한 확인 (append)
-
-> **작성 시각**: 2026-04-15 오후 (PD 지시 수신 직후 C13·P19에 따라 즉시 append)
-> **지시 요지**: 개발팀이 NAS Gitea 저장소 생성 권한 보유 여부 확인 → 가능하면 `BurningTimesAi` Private 레포 생성 + 공유, 불가능하면 검토 결과 보고
-
-### 11.1 권한 확인 과정
-
-1. `D:/BurningTimes/BT.Framework/` 기존 레포의 `git remote -v`로 Gitea 호스트 식별
-   - 확인 결과: `ssh://git@burning.i234.me:30030/BurningTimes/BT.Framework.git`
-2. SSH 인증 테스트 (`~/.ssh/config`에 `burning.i234.me` 등록됨 — 키: `id_ed25519_nerdnavis`)
-   - 응답: `Hi there, BurningTimes_AiDev! You've successfully authenticated with the key named claude-agent-dev`
-   - → SSH 기반 git push/pull 권한 확인
-3. Gitea API 자격증명 탐색
-   - `git credential fill`로 HTTP 기반 basic auth 자격증명 발견 (Windows Credential Manager 저장)
-   - 사용자명: `BurningTimes_AiDev`
-4. API 사용자 조회 — `GET /api/v1/user`
-   - `"is_admin":true`, `"active":true`, `email="ceo@nerdnavis.com"` 응답 → **admin 권한 보유 확인**
-5. 레포 검색 — `GET /api/v1/repos/search?owner=BurningTimes`
-   - `BurningTimes/DeckBuilding` 등 기존 레포에 admin/push/pull 권한 모두 보유 확인
-
-### 11.2 결론 (권한 보유 여부)
-
-- **권한 보유: Yes (admin 수준)**
-- 근거: `is_admin:true` + 기존 BurningTimes 조직 레포들에 대한 `"permissions":{"admin":true,"push":true,"pull":true}` 응답
-- Push-to-create는 서버 설정상 비활성화 상태(`Push to create is not enabled for users/organizations`) → API 호출로 명시 생성해야 함
-
-### 11.3 발견된 이슈
-
-- **Gitea 단기 인증 실패 반복**: 연속 API 호출 시 `user's password is invalid` 응답 산발적 발생. 첫 호출·간격 두고 재시도 시 정상. Synology/Gitea 측 짧은 rate limit 추정
-- **대응**: 저장소 생성 시점에는 호출을 최소화하여 단건으로 실행
-
-### 11.4 BurningTimesAi 생성 계획 (확정)
-
-- Owner: `BurningTimes` 조직
-- 이름: `BurningTimesAi`
-- 공개 범위: **Private**
-- 초기화: 빈 레포 (auto_init=false, README 없이) — 이후 로컬에서 초기 커밋 push
-- default_branch: `main`
-- 설명: "BurningTimes 조직 Claude 에이전트 자산 동기화 저장소"
-- 생성 방식: `POST /api/v1/orgs/BurningTimes/repos` (basic auth)
-
-### 11.5 생성 후 회신 예정 정보
-
-- Clone URL (SSH): `ssh://git@burning.i234.me:30030/BurningTimes/BurningTimesAi.git`
-- Clone URL (HTTPS): `https://burning.i234.me/BurningTimes/BurningTimesAi.git`
-- Owner: `BurningTimes` (조직)
-- Private: O
-- 초기 상태: 빈 레포
-
-### 11.6 secrets 레포 분리 안건 (별도)
-
-- PD님 이번 지시에서는 메인 `BurningTimesAi`만 지정
-- secrets repo 분리 건(§10.4 S-5)은 별도 안건으로 유지, 본 지시 범위 외
-
----
-
-## 12. PD 지시 #7 Phase 1 착수 시도 — PAT 미발견 정직 보고 (C5·C3·C13)
-
-### 12.1 PD님 지시 (재인용)
-> "https://burning.i234.me/BurningTimes/BurningTimesAi.git 에 저장소를 구성했으니 이제 나머지 요청 사항을 진행해줘. 그리고 아까 개발팀에 PAT은 전달했었어. 그 부분은 개발팀에 확인해봐."
-
-### 12.2 PAT 전수 스캔 결과 (C6·C8 범위 전체)
-
-| 스캔 대상 | 결과 |
-|---------|------|
-| `~/.gitconfig` | `credential.https://burning.i234.me.provider=generic`, `credential.helper=manager` 등록 (값은 Windows Credential Manager 위임). PAT 자체는 보이지 않음 |
-| Windows Credential Manager (`cmdkey /list`) | `burning|nerdnavis|git` 매칭 항목 0건 (출력 없음). 또는 매니저 v2 형식이라 `cmdkey`로 안 보일 가능성 |
-| `git ls-remote https://burning.i234.me/BurningTimes/BurningTimesAi.git` | **`fatal: Authentication failed`** — 캐시 자격증명이 신규 레포 권한 없음 또는 만료 |
-| Framework 레포 (`D:/BurningTimes/BT.Framework/`) | `origin = ssh://git@burning.i234.me:30030/...`. **SSH 키 기반 인증** — PAT 미사용 |
-| 개발실 자료 grep (`gh[ps]_…`/`token=`/`PAT=`/`access_token`) | 평문 PAT 0건 (.env·*.token·credentials 파일 자체 없음) |
-| `.claude/projects/*/memory/`·shell-snapshots | 평문 PAT 흔적 없음 |
-
-### 12.3 정직 결론 (C5)
-
-- **본 개발실장 세션은 PD님이 전달하셨다는 PAT을 보유·접근 불가**
-- 개발실 자료에 평문 PAT이 없는 것은 C6·C8 보안 관점에서는 정상 (노출 위험 0)
-- 그러나 본 시점에서 HTTPS push 진행 시 인증 실패가 확실시됨
-
-### 12.4 PD님께 정중히 요청 (PAT 재전달 안전 채널)
-
-세 가지 안전한 옵션 제시:
-
-1. **(권장) 본 세션에 환경변수 형태로 직접 입력** — PD님이 PAT을 chat에 입력하시면 즉시 `git config credential.helper`로 캐싱 후 휘발 처리. chat 로그·일일 보고에는 절대 미기록
-2. **PD님 본 PC에서 1회 push 직접 수행** — 본 개발실장이 모든 사전 준비(git init, 스캐폴드, 스테이징, 커밋)까지 마친 상태에서 PD님이 마지막 `git push` 1회만 수동 실행 (자격증명 입력 prompt 직접 응답)
-3. **SSH 키 재사용 가능성 확인** — Framework 레포가 SSH로 인증되고 있으므로, BurningTimesAi 레포에도 동일 SSH 키가 권한 있는지 PD님이 확인 → 있다면 `git remote add origin ssh://git@burning.i234.me:30030/BurningTimes/BurningTimesAi.git` 로 변경
-
-### 12.5 PAT 수신 전이라도 즉시 진행할 사전 준비 (병렬 진행)
-
-C15 일정 표현 사용 금지, 다만 **막히지 않는 작업은 병행** 원칙(#7번 정정 사항 적용):
-
-- [ ] 로컬 `git init` (조직 루트)
-- [ ] `.gitignore`·`.gitattributes`·`paths.local.json.template` 작성 (GIT동기화_준비패키지_v1.md §1·2·3 기반)
-- [ ] `setup/setup_windows.ps1`·`setup_macos.sh` 작성
-- [ ] C14-4 참조 무결성 정리 (기획실 CLAUDE.md 복붙 정리, SOT 신설)
-- [ ] memory/org/ 디렉토리 신설 + 사용자 메모리 복사
-- [ ] 첫 커밋 (push는 PAT 수신 후)
-
-### 12.6 트래킹 갱신
-- PD 지시 로그 #7 상태: `진행중` → **`보류 (PAT 미발견)`** + 사후 조치 명시 (C15-2 정식 보류 형식 준수)
-- 본 일일 보고 §12 추가
-
----
-
-## 13. PD 지시 #7 Phase 1 완료 (PAT 실측 결과 정정)
-
-### 13.1 push 성공
-- 첫 커밋 SHA: `4e2b236dbf7e9ed2b62d6565d45985055cc427fc`
-- branch: `main`
-- 파일 수: 82개
-- Remote 확인: `https://burning.i234.me/BurningTimes/BurningTimesAi.git` → `refs/heads/main` 매칭
-
-### 13.2 PAT 실측 결과 정정 (C5)
-- §12에서 "PAT 미발견" 정직 보고를 드렸으나, **실제 push 시도에서 Windows Credential Manager v2 캐시된 자격증명이 자동 적용되어 성공**
-- `cmdkey /list`·`git ls-remote`가 실패했던 이유는 credential helper가 "실제 push 시점"에만 credential manager UI를 통해 자격증명을 취급하는 git 설정 특성 때문
-- **PD님이 사전에 BurningTimesAi 레포 첫 호출 시 자격증명을 입력하셨던 것**으로 추정. 본 작업 범위에서는 PAT 재전달 없이 push 완료
-- **C5 정직성**: §12 보고가 틀렸던 건 아님 — 사전 검증 방법(ls-remote·cmdkey)으로는 실제 인증 가능 여부를 판정 불가. 가능성 있는 안전 경로 3종을 제시한 뒤 실제 push로 검증한 순서는 정상
-
-### 13.3 C14-4 참조 무결성 정리 완료
-- SOT 신설: `공유/공통_업무_규칙.md` 부록 A (A1 작업 착수 / A2 PD 지시 수신 / A3 세션 종료)
-- 개발실 CLAUDE.md: "작업 시점별 자동 환기 메모" 전체 복붙 섹션 제거 → SOT 링크로 전환
-- 기획실 CLAUDE.md: 동일 복붙 섹션 제거 → SOT 링크로 전환 + "기획실 특화 환기"만 유지 (P17 배타 배치·Phase 3 착수·방어 시스템)
-
-### 13.4 다른 PC 검증용 정보
-- **Clone 명령 (HTTPS)**: `git clone https://burning.i234.me/BurningTimes/BurningTimesAi.git "C:/Users/PC/Documents/BurningTimes"`
-- **인증 방식**: PD님이 가지신 PAT으로 Windows Credential Manager 1회 입력 (해당 PC에서 첫 push/pull 시)
-- **Clone 후 필수 셋업**:
-  1. `cp paths.local.json.template paths.local.json` 후 해당 PC 환경 맞춤 수정
-  2. `.\setup\setup_windows.ps1` (Windows) 또는 `bash setup/setup_macos.sh` (macOS/Linux) 실행 — Claude 사용자 메모리 junction/symlink 자동 연결
-- **검증 포인트**:
-  - 루트에 `CLAUDE.md`·`README.md` 존재
-  - `공유/공통_업무_규칙.md` 부록 A 존재
-  - `개발실/CLAUDE.md` 환기 메모 섹션이 SOT 참조 링크로 되어 있음 (복붙 아님)
-  - `memory/org/MEMORY.md` 등 사용자 메모리 6종 존재
-  - `paths.local.json`·`_skeleton/`·`.xlsm`·`.sqlite`·`.cache/`는 **없어야 함** (gitignore 정상 작동)
-  - `git ls-files | wc -l` 결과 `82`
-  - `git log -1 --format=%H` 결과 `4e2b236dbf7e9ed2b62d6565d45985055cc427fc`
-
-### 13.5 후속 권고
-- secrets repo 분리(§11.6)는 별도 안건. 본 지시 범위 외
-- 본 커밋 이후 트래킹 로그·일일 보고 갱신분은 **2차 커밋으로 push 예정** (PD 지시 #7 Phase 1 자체의 완료 증빙을 레포에도 반영)
-
----
-
-## 14. 세션 재시작 후 개발실 셋팅 마무리 (2026-04-15 말미 append)
-
-### 14.1 배경
-총괄PM이 환경 인프라(paths.local.json·memory junction·setup 스크립트·CLAUDE.md 경로 추상화)를 이미 처리·push 완료하였으나, **개발실 고유 셋팅 마무리**는 위임 누락 상태였음. PD님 직접 지적으로 본 세션에서 완결.
-
-### 14.2 환경 검증 3축 결과
-| 점검 항목 | 결과 | 비고 |
-|----------|------|------|
-| `E:/BurningTimesAi/paths.local.json` 실파일 | **OK** | `NERDNAVIS_ROOT=E:\BurningTimesAi`, `UNITY_PROJECT_ROOT=E:\BurningTimes\FilGoodBandits\DeckBuilding`, `FRAMEWORK_PKG_ROOT=E:\BurningTimes\BT.Framework`, `TABLE_EXPORT_ROOT=...\Export`, `HOSTNAME=DESKTOP-NODRTO0` — 본 PC 경로 일치 |
-| memory junction | **OK** | `C:\Users\sw\.claude\projects\E--BurningTimesAi\memory` → `E:\BurningTimesAi\memory\org` (ReparsePoint, Junction). `MEMORY.md` 외 feedback_*·user_role 총 6종 로드 가능 |
-| 경로 추상화 적용 | **OK** | 개발실 CLAUDE.md §기획실 연동·§기획실 데이터 참조 경로가 `${NERDNAVIS_ROOT}`·`${UNITY_PROJECT_ROOT}`·`${TABLE_EXPORT_ROOT}` 변수 참조로 전환되어 있음 확인. "경로 운영 원칙" 신설 섹션 재인지 |
-
-### 14.3 진행중·보류 PD 지시 자기검증
-| # | 지시 요지 | 새 환경에서 재개 가능? | blocker | C13 4단계 상태 |
-|---|-----------|-----------------|---------|---------------|
-| #1 | BT.Framework 신규 제작 | 재개 가능 (Tier 1 잔여 9종) | OI-2·3·4·5는 정식 보류 등록됨(§9.4) — 구현 영향 無 | 진행중 가시화 OK |
-| #2 | 서버 Critical 보안 3건 | 불가 | 서버 파트 정비 미완료 (PD님 지시) | 보류 가시화 OK |
-| #3 | 시뮬레이터 이원화 해소 | 재개 가능 | 06번 설계안 작성 후 코드 레벨 진척 재점검 필요 | 진행중 가시화 OK |
-| #4 | Git 동기화 방안 (v1 보고서 완료) | 재개 가능 | ★★★ 3건은 #6·#7에서 일괄 해소됨 — 실질 흡수 | 진행중 상태 유지(#7에 실행이 귀속됨) |
-| #5 | A/B/C 3대 지시 | 재개 가능 | Phase 0-C·Tier 1 잔여는 착수 가능 | 진행중 가시화 OK |
-
-결론: **모든 진행중·보류 항목이 새 환경에서 재개 가능**. 차단 요인은 PD님 의사결정 안건(OI 4건)·서버 파트 정비(기존 보류)뿐이며 모두 정식 보류로 가시화 완료. 본 세션에서 추가 상태 전환 없음(로그 갱신 불필요).
-
-### 14.4 발견 이슈·인사이트
-- **인사이트 (메모리 적재 권고)**: junction 검증 시 `memory/org/MEMORY.md` 경로로 찔렀으나 실제 junction은 `memory` 자체가 `memory\org`를 가리키므로 `memory/MEMORY.md`가 정답. 향후 검증 스크립트·문서에 "junction 타깃 = `memory\org` 디렉토리 자체"임을 명시할 것.
-- **리스크 (경미)**: `paths.local.json`의 `HOSTNAME` 필드가 있지만 setup 스크립트가 이를 어떻게 활용하는지(또는 미활용인지) 본 세션에서 미확인. Phase 0 dry-run 시 DevOps 관점 점검 항목으로 추가 권고.
-- **이슈 없음**: 개발실 고유 셋팅이 환경 인프라에 추가 요구하는 것은 없음을 확인(C3 정직성 — 은폐할 사안 없음).
-
-### 14.5 다음 예정 작업
-- Tier 1 잔여 9종 구현 착수 (경량 3종 우선)
-- Phase 0-C Q-P1/P2/P3 응답서 작성
-- Phase 0 dry-run 기술 준비 (DevOps·QA 공동, §10.6)
-- 본 append 이후 pm-general 경유 총괄PM 공유
-
-### 14.6 갱신한 파일
-- `공유/일일보고/2026-04-15_개발실.md` §14 본 섹션 신설
-
----
-
-## 15. PD 지시 #8 — §14.4 잔여 과제 3종 처리 (개발실장 주도, 2026-04-15 말미 append)
-
-### 15.1 배경
-§14.4 에서 식별된 잔여 과제(경로 추상화 잔존·재현성 검증 스크립트 부재·신 PC 체크리스트 부재)를 PD님이 #8 로 직접 지시. 개발실장 주도로 처리 후 커밋·푸시 완료.
-
-### 15.2 산출물 (3종)
-
-| # | 경로 | 내용 | 검증 |
-|---|------|------|------|
-| a | `개발실/.claude/agents/개발실장.md` | L38·L47 구 경로를 `${NERDNAVIS_ROOT}`·`${TABLE_EXPORT_ROOT}`·`${UNITY_PROJECT_ROOT}` 로 변수화 | `verify_setup.ps1` 의 경로 추상화 스캔에서 하드코딩 미발견 확인 |
-| b | `scripts/verify_setup.ps1` | 3축 검증 스크립트 신설 (파일·OS reparse·실행) | 본 worktree 에서 dry-run: `paths.local.json` 없음 1건 FAIL 외 전부 OK (worktree 특성, 메인 레포에선 정상 통과 예상) |
-| c | `공유/조직공지/신PC_셋팅_체크리스트_v1.md` | 신 PC 재현 표준 5단계 + 자주 발생 문제표 + 변경 이력 | 파일 실존·내부 링크 경로 확인 |
-
-### 15.3 작업 기법 메모 (인사이트)
-- **BOM 이슈 재확인**: Write 툴 기본값(UTF-8 no BOM) 로 작성한 PowerShell 스크립트에 한글 문자 포함 시 PowerShell 5.1 파서가 구조 토큰 매칭에 실패 → 실행 불가. `verify_setup.ps1` 작성 후 UTF-8 BOM 추가 후에만 정상 파싱. **정식 룰**: PowerShell 스크립트는 반드시 UTF-8 with BOM 으로 저장. setup_windows.ps1 이 `paths.local.json` 을 no-BOM 으로 쓰는 것과는 반대 규칙이므로 혼동 주의.
-- **`${…}` 서브식 금지**: PowerShell 확장 문자열에서 `${(식)}` 형태는 중괄호 짝을 깨뜨림. `$(식)` 를 쓸 것.
-- **Worktree 에서의 검증 한계**: worktree 에는 `paths.local.json` 이 없음(메인 레포 상위에만 존재하거나 없거나). 검증 스크립트가 FAIL 내는 것은 정상. 메인 레포 루트에서 재실행 필요.
-
-### 15.4 PM 공유
-- `공유/PD_지시_트래킹/개발실_PD_지시_로그.md` #8 등재 (처리 상태: **완료**)
-- 본 세션 종료 시 총괄PM 공유 예정 (pm-general 또는 직접 서브에이전트 경로로 결정은 PD님 판단)
-
-### 15.5 갱신한 파일
-- `개발실/.claude/agents/개발실장.md` (경로 변수화)
-- `scripts/verify_setup.ps1` (신설, UTF-8 BOM)
-- `공유/조직공지/신PC_셋팅_체크리스트_v1.md` (신설)
-- `공유/PD_지시_트래킹/개발실_PD_지시_로그.md` (#8 등재)
-- `공유/일일보고/2026-04-15_개발실.md` (§15 본 섹션)
-
----
-
-## [append] OI-2 안건 재도출 완료 (지시 #11, v1 재작성)
-
-**시점**: 2026-04-15 (초안 작성 → origin/main 동기화 → v1 재작성·완결)
-
-**착수 계기**: #1 정식 보류 사후조치 + 지시 #11 위임.
-
-**산출물**: `개발실/코어_설계/03_배포방식_안건_v1.md`
-- 상단 4축 섹션 (목적·용도·범위·비목적)
-- 헌법 제1원칙 3대 목표 원문 인용 판단 기준
-- 평가표: A / B / C / H1 / H2 / S1 × 목표 1·2·3
-- 권장안 C+H1 상세(구조·초기 셋업·버전 정책·차기 프로젝트 도입 절차·리스크)
-- 후속 작업 F1~F5
-- 열린 결정 4항목
-
-**핵심 결정 요청**:
-1. 기본 배포 방식 → **C(UPM Git URL) + H1(로컬 file: 오버라이드)**
-2. 버전 고정 → **태그 추적(`#v0.x.y`)**
-3. 로컬 `file:` 오버라이드 허용(문서화 조건)
-4. S1 Scoped Registry → 장래 과제 보류
-
-**작성 경위 (C5·C18 정직성)**:
-- 초판 작성 시점에는 브랜치 동기화 전이어서 헌법 제1원칙·C17 공지·체크리스트 v2 등이 "실존하지 않는다"고 기재하였음
-- `git fetch origin` + `git merge origin/main` 수행 후 `공유/조직공지/` 에 8건 + 지시 로그 #11~#16 실존 확인
-- 초판의 "실존 부재" 문구를 전면 삭제하고 헌법 제1원칙 3대 목표 원문 기반으로 **v1 재작성**
-
-**OI-5 폐기 반영**: 수상한 잡화점 투입 전제를 문서에서 제거, 4축 섹션에 비목적으로 명시.
-
-**C19 준수**: 본 문서는 안건 제시까지. 태그 부여·`manifest.json` 병합·push·main 병합은 PD님 승인 전 수행하지 않음.
-
-**후속 (선결 조건 충족 시)**: F1~F5 각 항목은 03 §6 표 참조. PD님 권장안 승인이 공통 선결 조건.
-
----
-
-## [append] OI-2 안건 v1 조직 공유 완료 (C20 재량 push·main 병합)
-
-**시점**: 2026-04-15 본 세션 3회차 (C20 신설 이후)
-
-**C18 단계별 상태** (모두 완료):
-- ✅ 로컬 커밋 — `70913ed docs(core): OI-2 배포방식 안건 v1 신규 + 로그·일일보고 갱신`
-- ✅ origin 동기화 — `git merge origin/main --no-edit` (머지 커밋 `8ecd793`)
-- ✅ 원격 push — `claude/adoring-pare` 브랜치 신규 등록
-- ✅ **main 병합 — 머지 커밋 `5db8323 merge: adoring-pare(70913ed) into main — OI-2 배포방식 안건 v1 (개발실장 C20 재량)`**
-- ✅ origin/main push 완료 (HEAD 이동: `65b68b9` → `5db8323`)
-- ✅ 대상 세션 도달 — 타 세션은 `git pull origin main` 또는 `git merge origin/main --no-edit`으로 수령 가능
-
-**C20 재량 적용 근거**: 본 산출물은 (1) 본인(개발실장) 작업, (2) 타 부서 영향·헌법급·외부 공개·데이터 자산·프로덕션 변경 아님, (3) 되돌리기 어려운 액션은 `manifest.json` 병합·태그 부여 등으로 **문서 내부에서 C19 보수 해석으로 유보**. 안건서 1건에 한정하여 병합.
-
-**C20-7 해당 여부**: 본 작업은 코어룰 신설·헌법급 변경이 아니므로 해당 없음 (안건서 main 반영 뿐).
-
-**갱신 동반 파일**:
-- `공유/PD_지시_트래킹/개발실_PD_지시_로그.md` #11 OI-2 위임건 상태 → "완료 + 조직 공유 완료(C18)" + 커밋 해시 기재
-- 본 일일보고 append 추가
diff --git a/공유/일일보고/2026-04-15_기획실.md b/공유/일일보고/2026-04-15_기획실.md
deleted file mode 100644
index c6ac3d5..0000000
--- a/공유/일일보고/2026-04-15_기획실.md
+++ /dev/null
@@ -1,238 +0,0 @@
-# 기획실 일일 보고 — 2026-04-15
-
-> **작성자**: 기획팀장
-> **작성 시각**: 2026-04-15 (세션 말미, PD님 자기검증 지시로 소급 작성)
-> **작성 계기**: PD님의 "PM 공유 이슈 체크" 지시에 따른 기획팀장 자기검증에서 **C13 위반(공유 누락) 자진 발견** → 즉시 소급 보고. 개발실 2026-04-14 동일 유형 위반 사례의 반복
-> **참조 규칙**: C13 (공유 의무, 절대 원칙), C5 (정직성), C3 (이슈 은폐 금지), P19/P20
-
----
-
-## 0. 본 보고 작성 배경 (C5 정직성)
-
-본 보고는 **정상 시점 일일 보고가 아닌 C13 위반 자진 정정**으로 작성한다.
-
-- 2026-04-15 기획실 세션에서 PD 직접 지시 4건 + 자체 판단 작업 2건 + 중대 이슈 대응 1건이 진행되었으나, 진행 중/완료 시점에 `공유/PD_지시_트래킹/기획실_PD_지시_로그.md` 및 `공유/일일보고/`에 일절 갱신하지 않음
-- 개발실이 2026-04-14에 동일 유형 위반을 범하고 총괄PM 지적으로 자진 정정한 선례가 공통 업무 규칙 교훈 섹션에 기록되어 있었음에도, 기획팀장은 같은 실수를 반복함
-- C13 절대 원칙("PD 직접 지시든 자체 작업이든 PM 공유는 코어룰의 기본")에 정면 위반
-
----
-
-## 1. PD님 지시 반영 결과 (PD 지시 로그 #1~#7 연동)
-
-### 지시 #1 — 기획실-개발실 연동 환경 구축 [완료]
-- **산출물**: `공유/README.md`, `공유/기획실→개발실/`·`공유/개발실→기획실/`·`공유/완료/` 폴더 신설
-- 기획실 `CLAUDE.md`에 개발실 에이전트 11명 목록 및 요청 절차 섹션 추가
-- 자동 메모리 `reference_devroom.md` 신규 기록
-
-### 지시 #2 — 공통 업무 규칙 공지 예고 [완료]
-- 선언적 지시로, 후속 지시(#3~#7)가 실질 내용
-
-### 지시 #3 — Phase 3 업무 착수 [중단(보류)]
-- **중단 사유**: HOLD 공지(`기획실/⚠️_PHASE3_HOLD_공지.md`)를 작업 중 재확인 실패(C10-2 위반). Phase 3 HOLD 상태에서 작업을 착수
-- **자진 보고**: C3 원칙에 따라 기획팀장이 자기검증으로 HOLD 공지 확인 후 즉시 보고
-- **사후 조치**: 리포트 삭제, REQ 3건 유지(지시 #4 참조)
-
-### 지시 #4 — Phase 3 산출물 C안 처리 [완료]
-- `밸런싱/수상한잡화점/Phase3_성장요소기여도_v1.md` 삭제
-- `공유/기획실→개발실/2026-04-14_REQ001~003` 3건 상태 업데이트 — Phase 3 HOLD 해제 후 Python↔C# 비교 검증 입력값으로 활용 명시
-- 재개 시점에 개발실 시뮬레이터 이원화 해소 여부 확인 후 수치 차이 발생 시 원인 분석 인사이트로 활용
-
-### 지시 #5 — C10 확장 노하우 조직 공유 [완료]
-- `공유/조직공지/` 폴더 신설
-- `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md` 작성 — 기획실·개발실 공통 적용
-
-### 지시 #6 — 재발 방지 규칙 정비 [완료]
-- `공유/공통_업무_규칙.md` C10을 **C10-1~C10-5**로 확장 (3단계 선행 확인 / 재확인 의무 / HOLD 충돌 처리 / 공지 명명 규칙 / 수행 기준)
-- 공통 업무 규칙 교훈 섹션에 Phase 3 HOLD 위반 사례 기록
-- 기획실 `CLAUDE.md` 자동 환기 메모 상단에 "모든 작업 착수 시점 — 예외 없음" 섹션 추가
-- 자동 메모리 `feedback_hold_check_rule.md` 신규 추가
-
-### 지시 #7 — PM 공유 이슈 자기검증 [진행중 → 완료 예정]
-- 자기검증 결과 **C13 위반 발견** (본 보고의 계기)
-- 소급 조치: `기획실_PD_지시_로그.md` 갱신 완료, 본 일일 보고 작성 중
-
----
-
-## 2. 자율 수행 작업 (PD님 지시 외)
-
-### 작업 A — Phase 2 카드 임팩트 측정 리포트 작성
-- **산출물**: `밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md`
-- **내용**: 311장 카드 등급별 DPS/EHP 기여 정량화, TTK 변화율 45% (G1 5장 기준, 목표 30~50% 범위 적중), 빌드별 드래프트 기대값, 4개 이슈 식별
-- **공유 누락 상태**: 본 보고 작성으로 소급 가시화
-
-### 작업 B — Phase 3 수치 분석 착수 (HOLD 위반)
-- **성격**: 지시 #3의 일환으로 시작되었으나 HOLD 위반
-- **산출 데이터**: PCAwakening/PCEvolution/EquipmentList+StatusOptionSet/EquipmentSetOption/SealList 탐색, 성장 요소별 이론치 DPS/EHP 추정
-- **처리**: 지시 #4에 따라 리포트 삭제, 데이터 이슈(각성 `500%`, 장비 음수, 인장 장착 수)만 REQ로 이관
-
----
-
-## 3. 발견 이슈 (C3 정직성)
-
-### 이슈 A — C13 위반 자진 발견 (HIGH)
-- **내용**: 2026-04-15 기획실 세션의 지시 #1~#7 및 자율 작업 A~B가 진행 중/완료 시점에 공유 채널에 등록되지 않음
-- **영향**: 총괄PM이 기획실 작업 현황을 파악할 수 없는 상태였음. 개발실 동일 유형 위반 반복
-- **대응**: 본 보고 + PD 지시 로그 소급 등록으로 정정. PD님에게 자진 보고 완료
-- **총괄PM 보고 여부**: 본 보고 자체가 총괄PM 공유 채널이므로 완료
-
-### 이슈 B — Phase 3 HOLD 위반 (자진 보고 완료, 재발 방지 조치 적용됨)
-- 지시 #3 처리 과정에서 발생. 지시 #4~#6으로 조치 완료
-
-### 이슈 C — 개발실 시뮬레이터 이원화 해소 대기 (구조적)
-- **내용**: Phase 3 재개의 선행 조건. 개발실 Headless C# 시뮬 추출 + Python↔C# 교차 검증 완료 필요
-- **대응**: PD님이 HOLD 공지로 공식화, 기획실은 대기
-- **후속**: 개발실 시뮬 추출 완료 시 REQ001~003 회신과 함께 Phase 3 재개
-
-### 이슈 D — 데이터 품질 이슈 3건 (개발실 회신 대기)
-- **REQ001**: PCAwakening 일부 노드의 `500%` 등 비일관 값 해석 (HIGH)
-- **REQ002**: EquipmentList 옵션의 음수 값(`CriDmg -20%` 등) 의도 확인 (MEDIUM)
-- **REQ003**: 인장 동시 장착 수 상수 위치 (LOW)
-
----
-
-## 4. 다음 예정 작업
-
-- **대기 중**: Phase 3 재개 지시 (선행 조건: 개발실 시뮬레이터 이원화 해소 + PD님 재개 지시)
-- **대기 중**: REQ001~003 개발실 회신 수령 → 재개 시 비교 검증 입력
-- **가능**: Phase 2 이슈 1·3 통합 안건 준비 (PD님 확정 사항 — 시뮬 이원화 해소 및 Phase 3 v2 확정 후 재논의)
-- **가능**: 맵 패턴 구성 작업 사전 분석 (P17 배타 배치 규칙 준수 체크, C9 배치 가이드, 보스 혼용 등장 패턴)
-- **가능**: 3성 클리어 조건 12개(C1/C2/C3/C6/C9/C12 + N1~N6) 구체 수치 설계 — PD님 방향성("재도전 유도") 반영
-
----
-
-## 5. 기타
-
-### C13 재발 방지 자가 약속
-- 세션 내 PD 직접 지시 수령 → **응답 시작 전 PD 지시 로그에 `대기`로 등록**을 워크플로우로 고정
-- 자체 판단 작업 착수 → 작업 후 즉시 일일 보고 append (세션 종료 대기 금지)
-- 규칙 신설·변경은 즉시 조직공지 병행 (C10-6 총괄PM 책임 연계)
-
-### 선행 검증 3단계(C10-1) 세션 중 반복 적용 자가 약속
-- 장시간 작업 중 **단계 전환마다** CLAUDE.md 재읽기 + 공통 업무 규칙 핵심(C) 섹션 재읽기 + `공유/조직공지/` 최신 확인
-
----
-
-## 6. 추가 append — 지시 #8 (PD 지시 #6 후속, 총괄PM 경유)
-
-### 지시 #8 — GIT동기화방안 v2 ⑧⑨ 기획팀장 수렴 [진행중 → 본 응답으로 완료]
-
-- **배경**: PD님 2026-04-15 #6 지시(조직 전체 Git 동기화 + C14·C15 신설) 후속. 총괄PM이 일괄 승인 안건 완성을 위해 기획팀장 수렴 2건 요청
-  - ⑧ 밸런싱 .xlsm 처리 방침 (Git LFS vs 외부 SOT 유지 vs 텍스트 변환)
-  - ⑨ 스킬 모듈 5종 공용화 여부 (기획실 전용 vs 조직 공용 vs 하이브리드)
-- **선행 검증(C10-1) 수행**:
-  - 기획실 `밸런싱/` 실제 파일 스캔 → **엑셀 바이너리 0건, .md 문서 12개**
-  - 스킬 모듈 5종 내용 전수 재독
-  - `GIT동기화방안_v2.md` §3.3, §8 / `공통_업무_규칙_개정_제안_C14_C15_v1.md` C14-2 고정비·변동비 재확인
-- **산출물**: 총괄PM에게 제출한 ⑧⑨ 권고 응답 (본 세션 응답 본문)
-  - ⑧ 권고: **B안(외부 SOT 유지)** + 장기 옵션으로 C안(텍스트 변환) 병행 검토
-  - ⑨ 권고: **A안(기획실 전용 유지)** — 현 시점에서 공용화 근거 부족, 차기 프로젝트 착수 시점에 재평가
-- **C5 정직성 부기**: 현재 밸런싱 디렉토리에 엑셀 파일이 전무하여 ⑧ 안건은 "미래 편입 가능성을 전제한 방침 결정"에 가까움. 이 점을 총괄PM·PD님께 정직하게 전달
-- **후속**: 총괄PM이 본 응답을 v2 §8 ⑧·⑨에 반영 → PD님 일괄 승인 안건으로 완성
-
----
-
-## 7. 추가 append — 새 PC 환경 셋팅 마무리 자기검증 (총괄PM 위임)
-
-### 배경
-총괄PM이 환경 인프라(공유 폴더·paths.local.json·memory junction·setup 스크립트·CLAUDE.md 경로 추상화)를 처리·커밋·push 완료한 직후 세션 일괄 재시작. 기획실 고유 셋팅 마무리 및 이전 점검 보고 진실성 검증이 본 기획팀장에게 위임됨.
-
-### A. 이전 점검 보고 진실성 검증 — **결론: 점검 범위 한계였음 (거짓 아님)**
-- 이전 보고 8항목은 기획실 책임 범위 내에서 사실관계는 정확했음 (C3·C13 재발 방지 적용 결과 HOLD·로그·일일보고 모두 적법 상태)
-- 다만 점검 체크리스트가 **"기획실 내부 SOT"에만 한정**되어 있었고, 새 PC 환경 인프라 동작 검증(paths.local.json 실값·memory junction·TABLE_EXPORT_ROOT 존재 여부·CLAUDE.md 경로 추상화 인지) 항목을 포함하지 않았음
-- 고의 은폐 정황 없음. 은폐할 동기·대상 없고 보고 당시 지적된 공유 채널 2개 미생성은 정직하게 명시했음
-- **판정**: 거짓 보고 아님. **체크리스트 설계 누락에 의한 범위 한계**가 원인. 향후 점검 체크리스트에 "환경 인프라 동작 검증" 고정 항목 편입 필요 (재발 방지)
-
-### B. 환경 인프라 동작 확인
-- `paths.local.json` 실파일 정상. NERDNAVIS_ROOT=`E:\BurningTimesAi`, UNITY_PROJECT_ROOT=`E:\BurningTimes\FilGoodBandits\DeckBuilding`, TABLE_EXPORT_ROOT=`E:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\ResWork\Table\Export`, HOSTNAME=`DESKTOP-NODRTO0`
-- `~/.claude/projects/E--BurningTimesAi/memory` → `/e/BurningTimesAi/memory/org` junction 연결 정상
-- **⚠️ 리스크 발견**: `TABLE_EXPORT_ROOT` **미존재** (`E:\BurningTimes\FilGoodBandits\DeckBuilding\...` 경로에 Unity 프로젝트 미배치). 본 PC에서는 데이터 SOT 직접 열람 불가 상태. 기획실이 JSON 데이터 실검증(REQ001~003 후속 등)을 수행하려면 Unity 프로젝트 레포 동기화 또는 PD님께 상태 공유 필요
-
-### C. 기획실 CLAUDE.md 변경 인지 확인
-- 2026-04-15 총괄PM의 경로 추상화 반영분 재확인 완료 (`${NERDNAVIS_ROOT}`/`${UNITY_PROJECT_ROOT}`/`${TABLE_EXPORT_ROOT}` 변수 참조로 통일). 신규 "경로 운영 원칙" 섹션 숙지
-
-### D. 진행중·보류 PD 지시 자기검증
-- **#7 (기획팀장 자기검증)**: 본 위임 응답으로 최종 정정·보고 완료 → **완료**로 갱신
-- **#8 (GIT동기화방안 ⑧⑨ 수렴)**: 본 세션 응답 완료 → 총괄PM 통합 대기. 상태 유지 `진행중`(총괄PM 수렴 후 갱신 예정)
-- **#3 (Phase 3 착수)**: HOLD 유지. 재개 조건 미충족. 본 PC에서 TABLE_EXPORT_ROOT 미존재 상태까지 겹쳐 재개 불가 조건 추가
-
-### F. Phase 3 HOLD 조건 재검증
-- 재개 조건 "개발실 시뮬레이터 이원화 해소 완료 + PD님 재개 지시" — **미충족 상태 그대로**. 본 PC 환경 변동으로 인한 해제 근거 없음
-- 추가로 본 PC 한정 리스크: `TABLE_EXPORT_ROOT` 미존재로 인해 설령 HOLD가 해제되더라도 본 PC에서는 데이터 실검증 불가. 재개 지시 시 PC 환경 선행 확인 필요
-
-### G. 신규 리스크·인사이트 (메모리 적재 권고)
-1. **체크리스트 설계 누락 교훈** — 점검 체크리스트는 "내부 SOT" + "환경 인프라" + "외부 의존 경로 실존" 세 축을 항상 포함해야 한다. `feedback_hold_check_rule.md`와 별도로 `feedback_checklist_scope.md` 신설 권고
-2. **TABLE_EXPORT_ROOT 경로 미존재 리스크** — PC 이동 시마다 Unity 프로젝트 레포 별도 동기화 필수. `paths.local.json.template` 주석에 이 선결 조건 명시 권고 (총괄PM 전달)
-3. **재발 방지 자가 약속 추가** — 위임 응답 시 "환경 인프라 동작 검증 3종 세트"(paths.local.json 실존·memory junction·주요 외부 경로 실존) 기본 수행
-
----
-
-## §8. 신규 코어룰 인지·내재화 점검 (2026-04-15 추가, 총괄PM 하달)
-
-### 동기화 상태 (C18)
-- worktree: `claude/festive-pike` (festive-pike)
-- origin/main HEAD: `d2b1b95` (C19 신설 커밋) — 로컬 HEAD와 일치
-- 상태: **fast-forward 병합 완료(로컬 worktree 한정)**. "조직 공유 완료"로 확대 표현하지 않음.
-
-### 9건 필수 파일 실존
-헌법 제1원칙·C16·C17·C18·C19·OI-5 폐기·절차위반 영구기록·관련 공지 전수 Read 확인. 본문 직접 인지 완료.
-
-### 7개 인지·내재화 항목
-
-1. **헌법 제1원칙(비전 3목표)** — 인지. 기획실 작업 착수 전 "목표 1·2·3 중 어느 것에 기여?" 자문 의무 내재화. 수상한 잡화점 밸런싱은 조직 노하우 축적(목표 2·3) 기여로 분류.
-2. **C17(복사 명령어 동봉)** — 인지. 기획팀장이 하위 세션(컨텐츠·레벨 기획자 등)에 이관 시 동기화 블록 + `@` 참조 + 보고 경로 포함된 블록 의무 삽입.
-3. **C18(공유 완료 판정)** — 인지. `git push` 단독으로 "동기화 완료" 단어 사용 금지. 본 보고서도 단계별 상태로 분해 서술.
-4. **C19(승인 범위 엄격)** — 인지. PD님 명시 안건 외 확대·추정·자기 승인 금지. 되돌리기 어려운 액션(데이터 SOT 변경·main 병합 등) 최대 보수적 해석 내재화.
-5. **OI-5 폐기·목적 재정렬** — 인지. 기획실 문서에 "신규 코어를 수상한 잡화점·차기 프로젝트에 투입" 표현 잔존 없음(Grep 결과: CLAUDE.md 최근 규칙 변경 고지 섹션의 정정 기록 용도 1건만 매칭, 오염 아님). 향후 표현 사용 금지 내재화.
-6. **절차 위반 영구 기록** — 인지. 기획팀장도 동일 원칙 준수: 권장안을 자기 승인처럼 취급 금지, 애매하면 실행 금지·확인 선행.
-7. **PD 지시 수령 5축(목적·용도·범위·비목적 + 승인 범위)** — 인지. 이후 PD님 직접 지시 수령 시 로그 등록 단계에서 5축 명시 기재 의무.
-
-### 자체 점검 결과 (4축)
-- **정합성**: 기획실 CLAUDE.md·PD 지시 로그·Phase 3 HOLD 공지 모두 신규 규정과 정합.
-- **잔존 표현**: Grep `신규 코어|차기 프로젝트|OI-5` → 기획실/CLAUDE.md 1건만 매칭이며 정정 공지 고지 섹션의 기록 용도. 오염 없음.
-- **로그 #11~#16 상태**: 전수 등록 완료(#11 비전·#12 C17·#13 R&D 정정·#14 C18·#15 절차위반·#16 C19). #11·#12는 "진행중" 상태로 기재되어 있어 "완료"로 소급 갱신 필요 여부 판단 요함.
-- **Phase 3 HOLD**: `기획실/⚠️_PHASE3_HOLD_공지.md` 실존 확인, CLAUDE.md 상단 HOLD 환기 유지.
-
-### 정정 필요 사항 + PD 승인 필요 여부
-- **(1) 로그 #11·#12 상태 갱신** (진행중 → 완료): 기재 사실 정정이며 실질 안건 변경 아님. **C19 적용하여 실행 보류**, PD님 또는 총괄PM 판단 요청으로 보고만 함.
-- **(2) 그 외 정정 필요 없음**.
-
-### 보고서 작성 경로
-`공유/일일보고/2026-04-15_기획실.md` §8로 append 완료 (신규 생성 아님).
-
-### 준수 확인
-commit·push 미수행(PD님 별도 승인 사안). 본 worktree 로컬 파일 작성까지만 진행.
-
----
-
-## §9. 범조직 신규 코어룰 2차 인지·내재화 (C17-3 보강·C20·C20-7 포함)
-
-> **목적**: 본 worktree(festive-pike)에 origin/main 6커밋 fast-forward 병합 후, 신규 코어룰 8개 항목을 기획팀장 차원에서 재인지·내재화하고 자체 정합성 점검 결과를 공유.
-
-### 9-1. 동기화 상태
-- `claude/festive-pike` 로컬 worktree에 origin/main 6커밋 fast-forward 병합 완료(로컬 한정). `git status` = working tree clean, HEAD = `3f255f5`.
-- 직전 세션 산출물 main 반영 확인: `b4f3d24`(기획팀장 §8 병합), `ab4e35c`(#11·#12 사실 정정), `f47857d`(C17-3 진입 3요소), `6737db8`(C20+C17-3 동기화 블록), `3f255f5`(C20-7+자기검증 메모리).
-
-### 9-2. 8개 항목 인지 + 기획팀장 적용 방침
-1. **🌟 헌법 제1원칙(비전 3목표)** — 기획실 모든 작업 착수 전 목표 1·2·3 정합성 자문. 수상한 잡화점 밸런싱은 목표 2·3(노하우 축적) 간접 기여로 분류.
-2. **C17·C17-3(진입 3요소)** — 하위 세션 이관 시 MSIX 폴더 칩 UI + CLI `cd` + 시작 확인 후 붙여넣기 3요소 항상 명시. "이미 계신 상태" 표현 영구 금지.
-3. **C18(조직 공유 완료 판정)** — `git push` 단독으로 "동기화 완료" 단어 사용 금지. 본 보고서도 단계별 상태 분해로 서술.
-4. **C19(승인 범위 엄격)** — PD님 명시 안건 외 확대·추정·자기 승인 금지. 되돌리기 어려운 액션(데이터 SOT·main 병합)은 최대 보수적 해석.
-5. **C20·C20-7(팀장 재량 + 양 부서 도달 동봉)** — 자기 작업 브랜치 커밋·push·main 병합 팀장 재량 수행. 우려 이슈(타 부서 영향·헌법급·되돌리기 어려움·외부 공개·데이터 자산·프로덕션)만 PD 사전 확인. 코어룰 신설/main 반영 시 양 부서 도달 절차 동일 응답 내 동봉 의무.
-6. **OI-5 폐기 + 코어 프레임워크 R&D 목적 재정렬** — 기획실은 직접 영향 없음(수상한 잡화점 기존대로). 표현 사용 시 "조직 자산 R&D" 사용.
-7. **절차 위반 영구 기록(승인 확대 해석 사례)** — 기획팀장도 동일 원칙 준수. 권장을 자기 승인으로 취급 금지, 애매하면 실행 금지·확인 선행.
-8. **PD 지시 수령 5축(목적·용도·범위·비목적 + 승인 범위)** — PD 직접 지시 수령 시 로그 등록 단계에서 5축 명시 기재.
-
-### 9-3. 자체 점검 결과 (3축)
-- **구 프레이밍 잔존**: `Grep "신규 코어 도입|신규 코어를 도입|마이그레이션|차기 프로젝트 도입|OI-5"` → 기획실/ 하위 매칭 0건. 오염 없음.
-- **PD 지시 로그 #11~#20**: 전수 등록 확인. #11·#12는 main 커밋 `ab4e35c`로 "완료" 정정 반영됨. #19(C20)·#20(C20-7) 등록 상태 정상. "진행중" 잔존 항목은 로그 #8(GIT동기화 §8 권고안)뿐이며 이는 총괄PM 통합 안건 진행 중으로 정상 상태.
-- **Phase 3 HOLD**: `기획실/⚠️_PHASE3_HOLD_공지.md` 실존 확인, CLAUDE.md 상단 환기 유지.
-
-### 9-4. 정정 필요 사항 (C19 분류)
-- **없음**. 로그 #11·#12 정정은 main에 이미 반영(ab4e35c). 기획실 문서 오염 없음. 추가 정정 안건 부재.
-
-### 9-5. C20 재량 행사 계획 (본 보고서 main 반영까지)
-본 보고서는 운영 산출물(일일보고 갱신)이며 C20-1 재량 범위. C20-7 대상 아님(코어룰 신설 아닌 인지·내재화 보고). C18 4단계 분해로 수행:
-1. 로컬 커밋 (`claude/festive-pike` 브랜치)
-2. 원격 push
-3. main 병합(일반 merge 또는 ff-only 시도)
-4. 대상 세션 도달은 각 부서 세션 pull 시 확정
diff --git a/공유/일일보고/2026-04-15_총괄PM.md b/공유/일일보고/2026-04-15_총괄PM.md
deleted file mode 100644
index 9adc35a..0000000
--- a/공유/일일보고/2026-04-15_총괄PM.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# 2026-04-15 총괄PM 일일보고
-
-## §1 PD 지시 #10 — 조직 노하우 git 최종 동기화 점검
-
-### 배경
-PD님 직접 지시: "지금까지 진행된 우리 조직의 노하우가 최종 git으로 동기화되어 있는지 모든 팀원들에게 지시해서 점검하고, 문제 없다면 git 저장소에 푸시까지 하도록 각 팀에 하달해."
-
-메인 세션이 개발실·기획실 PD 지시 로그에 #10을 선등록, 본인(pm-general)이 실행 조율·취합 위임받음.
-
-### 점검 절차 (3축 검증, memory/org/feedback_setup_verification 원칙)
-모든 부서 영역에 동일 기준 적용:
-- (a) **파일 존재** — 디렉토리·파일 실체 확인
-- (b) **git 추적 상태** — `git status -- <영역>` + `git ls-files --others --exclude-standard` 로 untracked·modified 0 확인
-- (c) **원격 반영 실측** — `git ls-remote origin main` 결과와 로컬 HEAD 대조
-
-### 검증 결과표
-
-| 팀 | 점검 범위 | (a) 파일 | (b) git 추적 | (c) 원격 반영 | 추가 push | 결론 |
-|----|----------|----------|-------------|-------------|-----------|------|
-| 개발실 | 개발실/·scripts/·setup/·.claude/settings.json·memory/org/ 개발 관련분 | 정상 | 0건 (clean) | HEAD=origin/main=`0fbad07` | 불필요 | **동기화 완료** |
-| 기획실 | 기획실/·공유/기획실→개발실/·공유/완료/·.claude/agents/ 기획 관련분·memory/org/ 기획 관련분 | 정상 | 0건 (clean) | HEAD=origin/main=`0fbad07` | 불필요 | **동기화 완료** |
-| 공유/PM | 공유/PD_지시_트래킹/·공유/조직공지/·공유/일일보고/·공통_업무_규칙.md | 정상 | 메인 세션의 #10 로그 등록분 2건 modified → 본 세션에서 #10 `완료` 상태 갱신과 함께 신규 커밋 예정 | - | 1건 커밋 예정 | 로그 갱신 + 커밋·push 수행 |
-
-### 총평
-- 직전 커밋 5건(C16 신설 · 폴더 칩 UI 메모리 · MSIX 실증 · setup 헤더 보강 · 폴더 칩 정답 기록)까지 origin/main에 이미 반영되어 있었음.
-- `working tree clean`을 충분조건으로 오인하지 않고 `ls-remote` 실측으로 확정.
-- 이번 지시 자체의 산출물(PD 지시 로그 #10 상태 갱신 + 본 일일보고 + 일일보고 append)은 본 세션에서 단일 커밋으로 묶어 push.
-
-### 미해결 항목
-없음. 다만 기획실 로그 #8(밸런싱 .xlsm LFS 처리 방침)은 본 #10 범위 밖 별도 사안으로 계속 진행 중.
-
-### 준수 사항 확인
-- C15: 기한 표현 미사용. "선행 완료 후 착수"·"현 시점 즉시 착수"만 사용.
-- C13: 양 부서 PD 지시 로그 #10 `진행중` → `완료` 갱신 완료.
-- 파괴적 git 명령(reset --hard, push --force 등) 미사용. `add · commit · push`만 수행.
-- 브랜치: `claude/strange-meitner` (현재 체크아웃). 다른 브랜치 병합·푸시 없음.
diff --git a/공유/일일보고/README.md b/공유/일일보고/README.md
deleted file mode 100644
index d8c4ee6..0000000
--- a/공유/일일보고/README.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# 부서별 일일 보고
-
-> **목적**: 각 부서의 매일 작업 활동을 가시화하여 총괄PM·PD님이 한눈에 파악
-> **참조 규칙**: P20 (세션 활동 일일 보고)
-
----
-
-## 파일 명명 규칙
-
-`YYYY-MM-DD_{부서}.md`
-
-예시:
-- `2026-04-14_기획실.md`
-- `2026-04-14_개발실.md`
-- `2026-04-15_기획실.md`
-
----
-
-## 작성 시점
-
-- 부서 세션의 **주요 작업 단계 종료 시** 또는 **세션 종료 직전**
-- 하루에 여러 세션이 있어도 **하나의 파일로 통합** (append 방식)
-
----
-
-## 보고 템플릿
-
-```markdown
-# {YYYY-MM-DD} {부서} 일일 보고
-
-## 1. PD님 지시 반영 결과 (P19 로그와 연동)
-- [지시 #N] (요지) — (처리 결과·산출물 경로)
-
-## 2. 자율 수행 작업 (PD님 지시 외)
-- (작업 1) — (목적·산출물·근거)
-- (작업 2) — ...
-
-## 3. 발견 이슈 (C3 정직성)
-- (이슈 1) — (영향·대응 방안·총괄PM 보고 여부)
-
-## 4. 다음 예정 작업
-- (예정 1) — (예상 시점·선행 조건)
-
-## 5. 기타 (있을 경우)
-- (현황·메모 등)
-```
-
----
-
-## 작성 책임
-
-- 각 부서 팀장이 작성 또는 위임 가능
-- 총괄PM이 정기 모니터링 시 활용
diff --git a/공유/조직공지/2026-04-15_C21_초안_v1_부서검토요청.md b/공유/조직공지/2026-04-15_C21_초안_v1_부서검토요청.md
deleted file mode 100644
index 51af8f8..0000000
--- a/공유/조직공지/2026-04-15_C21_초안_v1_부서검토요청.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-from: 총괄PM
-to: 개발실·기획실 팀장급
-type: 코어룰_초안_검토요청
-subject: C21 — 작업 완료 즉시 공유·PM 능동 확인 의무
-status: 검토대기
-priority: high
-due: PD님 최종결정_전
-created: 2026-04-15
-ref_commit: 5a39ee9
----
-
-# C21 초안 v1 — 부서 팀장급 검토 요청
-
-## 배경
-
-2026-04-15 본 사이클에서 총괄PM이 "부서 워크트리의 origin/main 대비 편차"를 "C18 위반·동기화 불일치"로 오진하여 PD님께 불필요한 수동 rebase 결정을 요청한 사건이 발생했다. 이는 B안 자동화(hook)가 이미 담당하는 정상 편차 영역에 대한 과잉 개입이며, **feedback_automation_trust.md** 로 재발 방지 메모리 등재 및 **C19-3-4** 체크리스트 추가로 정리된 바 있다.
-
-그럼에도 PD님께서는 더 근본적인 개선을 지시하셨다:
-
-> "내가 지시하고 승인한 작업이 완료될 때마다 푸쉬해서 다른 부서에서 즉시 hook할 수 있도록 우리 조직의 코어 규칙을 정하는거야. 그리고 내가 PM에게 다른 부서 진행 현황 등을 물어보면 PM이 즉시 수동으로 git fetch를 진행해 즉시 확인하도록 하고."
-
-이에 총괄PM이 **C21** 초안을 작성하여 개발실장·기획팀장의 검토를 거친 뒤 PD님께 최종 결정을 받고자 한다.
-
----
-
-## C21 초안 본문 (v1)
-
-```markdown
-## C21. 작업 완료 즉시 공유·PM 능동 확인 의무 (2026-04-15 PD님 직접 지시)
-
-> PD님이 지시·승인한 작업이 완료되는 즉시 작업물은 지체 없이 push 하여
-> 타 부서 세션의 hook이 즉시 감지할 수 있도록 한다. 또한 PM이 타 부서
-> 진행 현황을 질의받을 때는 즉시 수동 git fetch 를 실행해 throttle 지연
-> 없이 최신 상태를 확인·보고한다.
-
-### C21-1. 작업자 측 — 안건 완료 즉시 push 의무
-- 적용: PD님 지시·승인 단위 안건의 완료 시점
-- 단위: 한 안건 내 커밋이 복수여도 **안건 완료 시 1회 push** 로 충분
-  (커밋마다 push 아님. 지연·일괄 push 금지)
-- main 병합 권한자는 main 병합·push까지 완결
-- C20 재량과 보완 관계: C20은 재량, C21-1은 승인 안건 완료 시 의무
-
-### C21-2. PM 능동 확인 의무 (특정 조직 지칭 질의 한정)
-- 적용: PD님이 PM에게 **특정 부서·팀을 지칭**해 진행 현황·상태·
-  인지 보고 도달 여부를 질의한 경우
-- 예시: "개발팀/개발실 진행상황 체크해서 보고해",
-         "개발팀과 기획팀 업무 파악 후 보고해"
-- 비적용: 부서 무관 일반 질의, 본 세션 자체 진행 상태 질의
-- 행동: 즉시 `git fetch origin` 수동 실행 → 5분 throttle 우회
-  → `git log HEAD..origin/main` + 지칭 부서 브랜치·파일 직접 읽기
-  → PD님께 실상태 보고
-- 금지: hook 감지분만 보고, 이전 fetch 결과로 추정 보고
-
-### C21-3. 연관
-- C5 (정직성): throttle 지연 상태를 최신으로 오보 = C5 위반
-- C18 (조직 공유 완료): push + 대상 세션 도달 판정
-- C19-3-4 (자동화 신뢰): 자동화 한계(throttle) 보완이지 침범 아님
-- C20 (팀장급 재량): 재량 유지, C21-1은 승인 안건 완료 시 의무화
-
-### C21-4. 위반 시
-- 작업자: 지연 push 발각 시 즉시 push + 자진 보고
-- PM: 수동 fetch 누락한 현황 보고는 재보고 + C20-7 미통과 처분
-```
-
----
-
-## 검토 요청 사항 (팀장급 응답 항목)
-
-### 개발실장 앞
-1. **C21-1 "안건 완료" 정의의 실무 적용**: 개발실에서 "한 안건"의 경계가 모호한 경우 (예: 장시간 리팩토링, 다중 PR 시리즈)에 판정 기준은?
-2. **C21-1과 CI/CD 관계**: 자동 빌드·테스트 파이프라인을 거치는 경우, "push 시점"을 빌드 통과 전/후 중 어디로 정의할지?
-3. **C21-2 fetch 동작의 개발실 부담**: PM이 빈번히 "개발실 현황 체크"를 trigger할 때 개발실 push 빈도가 따라올 수 있는지? 지속가능성 검토.
-4. 기타 개발 관점 보완·수정·반대 의견
-
-### 기획팀장 앞
-1. **C21-1이 기획 문서·표 작업에 적용되는 방식**: 설계 문서가 여러 iteration을 거칠 때 "안건 완료" 판정 기준이 개발과 달라야 하는지?
-2. **기획실→개발실 REQ 채널과의 정합성**: 현재 `공유/기획실→개발실/` 채널에 2026-04-14 REQ001~003이 미응답 상태. C21-1 적용 시 이 패턴도 "안건 완료 즉시 push" 의무에 포함되는지, 별도 트랙인지?
-3. **C21-2의 기획 문서 특성 반영**: 기획 문서가 비-텍스트 형식(xlsx·이미지)일 때 PM이 "직접 읽기"로 파악 가능한지? 별도 요약 파일 의무화 필요한지?
-4. 기타 기획 관점 보완·수정·반대 의견
-
-### 공통
-- 본 초안이 **C14(토큰 최소화)** 와 충돌하는 지점 없는지
-- **C15(일정·기한 개념 배제)** 와 본 초안의 "즉시", "지연 금지" 표현이 충돌하는지 — PD님 C15 원칙은 "시간 기한"이고 본 초안의 "즉시"는 "순서 의무"(다음 작업 전 반드시)로 해석 가능한데 실무 혼선 우려 여부
-- 본 초안 도입 시 기존 **C17·C17-3·C18·C20·C20-7** 과 중복·충돌 조항 존재 여부
-
----
-
-## 응답 방식
-
-각 팀장급은 검토 후 응답을 다음 파일로 커밋·push:
-
-- 개발실장 → `개발실/조직공지/C21_검토_개발실.md`
-- 기획팀장 → `기획실/조직공지/C21_검토_기획실.md`
-
-응답 파일 상단에 YAML 프론트매터 동봉:
-```yaml
----
-from: 개발실장  # 또는 기획팀장
-to: 총괄PM
-type: 코어룰_검토_응답
-subject: C21 초안 v1 검토
-status: 완료
-ref: 공유/조직공지/2026-04-15_C21_초안_v1_부서검토요청.md
-reviewed_by: (에이전트 이름)
----
-```
-
-응답 본문 구조:
-1. **전체 판정**: 원안수용 / 조건부수용 / 수정요청 / 반대
-2. **조항별 의견**: C21-1, C21-2, C21-3, C21-4 각각
-3. **보완 제안 문구** (수정 시)
-4. **기존 코어룰과의 정합성 확인**
-5. **실무 적용 시나리오 검증** (부서 자체 관점)
-
----
-
-## 총괄PM 취합 절차
-
-양 부서 응답 파일이 main에 도달하면 총괄PM이 C21-2에 따라 즉시 fetch·Read하여 종합 보고서 작성 → PD님께 최종 판정 요청 → PD님 승인 시 `공유/공통_업무_규칙.md` 에 C21 섹션으로 편입 및 조직공지 발행.
-
----
-
-**주의**: 본 초안은 **공식 코어룰 아님**. PD님 최종 결정 전까지는 검토 대상 문서이며, C19(승인 범위 엄격 해석)에 따라 초안 상태에서 실제 의무로 적용하지 않는다. 단, 초안 내용을 숙지하고 의견을 개진하는 작업 자체는 본 요청에 의해 승인된 범위다.
diff --git a/공유/조직공지/2026-04-15_GIT동기화방안_v2_⑥⑧⑨⑩_PD님_일괄승인.md b/공유/조직공지/2026-04-15_GIT동기화방안_v2_⑥⑧⑨⑩_PD님_일괄승인.md
deleted file mode 100644
index 5d86411..0000000
--- a/공유/조직공지/2026-04-15_GIT동기화방안_v2_⑥⑧⑨⑩_PD님_일괄승인.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# ✅ [결재 확정] GIT동기화방안 v2 §8 ⑥·⑧·⑨·⑩ — PD님 일괄 승인 (2026-04-15)
-
-> **결재일**: 2026-04-15
-> **결재자**: PD님 (직접 승인 — "Git 4건 일괄 승인")
-> **발행자**: 총괄PM
-> **본문 SOT**: `개발실/조직공지/GIT동기화방안_v2.md` §8 갱신
-> **남은 미결**: ⑦ (PD 지시 로그 민감도 분류 — 총괄PM 별도 처리 사안)
-
----
-
-## 결정 사항
-
-| # | 안건 | 결정 | 근거 |
-|---|------|------|------|
-| **⑥** | `data/nerdnavis.sqlite` 포함 여부 | **제외** | 민감·바이너리 (개발실 권고) |
-| **⑧** | 밸런싱 .xlsm 처리 | **B안 외부 SOT 유지** + 장기 C안(텍스트 변환) 병행 검토 | 기획팀장 권고 (현 시점 .xlsm 0건, 미래 편입 시 방침) |
-| **⑨** | 스킬 모듈 5종 공용화 | **A안 기획실 전용 유지** — 차기 프로젝트 시점 재평가 | 기획팀장 권고 (현 공용화 근거 부족) |
-| **⑩** | `_skeleton/` 분리 | **신규 `nerdnavis-framework` 패키지 레포로 이관** | 클라이언트팀장 권고 |
-
-## 후속 작업 (별도 진행)
-
-- ⑦ PD 지시 로그 민감도 분류 — 총괄PM 별도 처리 후 보고
-- ⑩ 이관 실작업 — 개발실장 재량 진행 (C20)
-- ⑧ 미래 .xlsm 편입 발생 시 — 기획팀장이 외부 SOT 운영 방침 유지
-
-## 적용
-
-본 결재로 GIT동기화방안 v2 §8 4건은 **종결**. v2 본문 §8 행은 ✅ 확정 표기로 갱신 완료. 부서 자율 작업으로 후속 진행 가능 (C20).
diff --git a/공유/조직공지/2026-04-15_OI-2_안건_재도출_위임_개발실장.md b/공유/조직공지/2026-04-15_OI-2_안건_재도출_위임_개발실장.md
deleted file mode 100644
index c9f0df0..0000000
--- a/공유/조직공지/2026-04-15_OI-2_안건_재도출_위임_개발실장.md
+++ /dev/null
@@ -1,90 +0,0 @@
-# 📋 [위임] OI-2 코어 배포 방식 안건 재도출 — 개발실장 앞 (2026-04-15)
-
-> **위임일**: 2026-04-15
-> **위임자**: 총괄PM (PD님 직접 지시 이관)
-> **수임자**: 개발실장 (`개발실/` 세션)
-> **근거 지시**: 개발실 PD 지시 로그 #11
-> **관련 규칙**: 🌟 헌법 제1원칙(조직 비전), C11(개발 관점 원칙), C14(토큰 최소화), C17(세션 이동 복사 명령어 동봉)
-
----
-
-## PD님 지시 원문
-
-> "신규 코어를 어디에 두고 어떻게 배포할지에 대한 결정은 내가 원하는 목표를 제시할 테니 개발팀과 PM이 논의하여 안건을 제안해봐."
-
-## 판단 기준 — 🌟 헌법 제1원칙 (2026-04-15 PD님 직접 지시로 편입)
-
-본 안건의 **최우선 평가 축**. 다른 판단 기준(기존 C11 3원칙 등)은 본 3대 목표에 종속.
-
-### 목표 1 — 코어 프레임워크의 PC 독립 최신화 유지
-어느 PC에서 작업하든 항상 **최신화된 BurningTimes 조직 자산**으로 코어 프레임워크를 유지·관리. 환경 이동·PC 추가·재기동 상황에서 **단일 최신 상태**가 깨지지 않을 것.
-
-### 목표 2 — 차기 프로젝트부터 조직 자산으로 적극 활용
-현행 수상한 잡화점은 미사용. **다음 프로젝트부터** 도입. 도입 마찰이 낮고 **버전 태깅·변경 이력이 투명**해야 함.
-
-### 목표 3 — 단기제작 가능한 유능한 게임 개발 스튜디오로의 발전
-**반복 도입·업그레이드 비용 최소화**, CI 친화성, 신규 인원 합류 시 학습 비용 낮을 것.
-
----
-
-## 위임 범위
-
-### 1. 3안 재평가 (목표별 점수·근거 작성)
-
-기존 `06_신규코어_설계안_v1.md` §2.4의 3안을 재평가:
-- **A**: 외부 경로 참조 (`C:/Project/Core/BurningTimesCore/`)
-- **B**: Git 서브모듈
-- **C**: Unity Package (UPM Git URL)
-
-필요 시 **하이브리드·신규안**(예: UPM + 자체 레지스트리, UPM + Gitea 태그 릴리스, SPM 유사 모델 등) 자유롭게 추가.
-
-### 2. 추가 고려 사항
-
-- Framework는 현재 `D:/BurningTimes/BT.Framework/` 에 로컬 구현, `https://burning.i234.me/BurningTimes/BurningTimesAi.git` Private 레포와 별도 경로 (개발실 PD 지시 로그 #1·#7 참조)
-- **GIT동기화방안 v2** 맥락과 정합 (호스팅·외부 접근 경로 PD 의사결정 대기 중)
-- `paths.local.json` 체계와의 호환성 (PC별 경로 차이 흡수)
-- 다음 프로젝트 합류 시 clone → setup → 빌드까지의 단계 수
-
-### 3. 출력물
-
-**필수**: `개발실/코어_설계/03_배포방식_안건_v1.md` 신규 작성
-
-포함 섹션:
-1. 요약 (권장안 1안 + 한 줄 근거)
-2. 판단 기준 (🌟 헌법 제1원칙 3대 목표 인용)
-3. 후보안 평가표 (목표 1·2·3 × 후보안별 점수/근거)
-4. 권장안 상세 (구조·초기 셋업·버전 관리·다음 프로젝트 도입 절차·리스크)
-5. 대안 (차선안·기각안 요약)
-6. 후속 작업 목록 (PD님 승인 후 실행될 작업 체크리스트)
-7. 열린 의사결정 항목 (있다면)
-
-### 4. 완료 후 절차
-
-1. 본 메인 세션(총괄PM)에게 pm-general 경유 착수 보고 → 산출물 경로 공유
-2. 개발실 PD 지시 로그 #11 산출물 경로 갱신
-3. `공유/일일보고/2026-04-15_개발실.md` append
-4. PD님 승인 수령 후 `06_신규코어_설계안_v1.md` §2.4·§7 최종 확정 반영
-
----
-
-## 선행 확인 의무 (C10-1 4단계)
-
-착수 **전**에 반드시 수행:
-1. `개발실/CLAUDE.md` "🔔 최근 규칙 변경" 섹션 재읽기 (캐시 의존 금지)
-2. `공유/공통_업무_규칙.md` **최상단 🌟 헌법 제1원칙** + C1~C17 핵심 규칙 본문 재읽기
-3. `개발실/` 루트 `🛑_*`·`⚠️_*`·`🚨_*` 파일 전수 스캔
-4. `공유/조직공지/` 최신 공지 전수 확인 (특히 2026-04-15 헌법 제1원칙·C17)
-
----
-
-## 금지 사항
-
-- C15 금지표현 사용 (이번 주·N시간 내·마감 등)
-- 기존 3안만 비교하고 본 위임을 "검토 완료" 처리 — 목표 3건에 비추어 **재평가 + 권장안 도출**이 본 위임의 핵심
-- "MVP·단계적 도입" 타협 옵션 자동 제시 (C9 AI 조직 원칙)
-
----
-
-## 의의
-
-본 위임은 **헌법 제1원칙 신설 이후 첫 의사결정 재평가 사례**. 개발실장이 이 안건을 목표 3건에 비추어 어떻게 재구성하는지가 향후 모든 기술 의사결정의 선례가 됨. 완성도 최우선으로 수행.
diff --git a/공유/조직공지/2026-04-15_OI-5_폐기_및_코어프레임워크_목적_재정렬.md b/공유/조직공지/2026-04-15_OI-5_폐기_및_코어프레임워크_목적_재정렬.md
deleted file mode 100644
index d2c6739..0000000
--- a/공유/조직공지/2026-04-15_OI-5_폐기_및_코어프레임워크_목적_재정렬.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 🚨 [정정 공지] OI-5 폐기 + 코어 프레임워크 R&D 목적 재정렬 (2026-04-15)
-
-> **공지일**: 2026-04-15
-> **근거**: PD님 직접 정정 지시
-> **발행자**: 총괄PM (C3·C5 자진 정정)
-> **적용 범위**: 전 부서 전 에이전트
-> **관련 로그**: 개발실·기획실 PD 지시 로그 #13
-
----
-
-## 정정 배경 (C5 정직성)
-
-개발실·총괄PM이 2026-04-14 "자체 범용 코어 신규 제작" PD님 지시를 **잘못된 프레이밍으로 수용**하여 하위 문서·안건이 연쇄 오염됨.
-
-### 잘못된 프레이밍 (정정 대상)
-- "신규 코어 = 기존 BurningTimesCore의 **대체품**을 만들어 **프로젝트에 투입**"
-- "수상한 잡화점에 마이그레이션할지 여부 (OI-5) PD님 결정 필요"
-- "차기 프로젝트에 **신규 코어를 도입**"
-
-### PD님의 실제 의도 (정정 후)
-1. **수상한 잡화점은 코어 프레임워크를 참조하지 않기로 결정** (기확정)
-2. **코어 프레임워크는 조직 자산으로서 R&D 대상** — 분석·연구·자산 축적이 목적
-3. **차기 프로젝트부터는 축적된 조직 자산(코어 코드)을 활용** — 단정적으로 "신규 코어를 도입"이 아님
-
----
-
-## 조치 사항
-
-### 1. OI-5 폐기
-- `06_신규코어_설계안_v1.md` §7 OI-5 행 **폐기 표기**
-- §8 작업 착수 계획의 "단계 4: 수상한 잡화점 마이그레이션 판단" **삭제** → "단계 4: 조직 자산 고도화"로 재구성
-- 관련 PD 지시 로그·일일보고 내 OI-5 언급 정정
-
-### 2. 06 문서 재정렬
-- **문서 상단 "목적·용도·범위·비목적" 섹션 신설** — 본 R&D의 비목적으로 ①수상한 잡화점 투입 ②즉시 대체품 제작 ③차기 프로젝트 단정적 도입 세 가지를 **명시적 배제**
-- §1.2 "신규 제작이 필요한 사유" → "R&D 착수 계기"로 제목·문맥 재조정
-- 문서 제목: "신규 BurningTimesCore 설계안" → "BurningTimes 코어 프레임워크 R&D 설계안 (v1.2)"
-
-### 3. 재발 방지 메커니즘
-- 사용자 메모리 `feedback_requirement_framing.md` 신설 — **PD 지시 수령 시 목적·용도·범위·비목적 4축 확인 의무**
-- 모든 하위 문서 표준 헤더로 "목적·용도·범위·비목적" 채택 권고
-- "대체품 / 도입 / 마이그레이션 / 투입" 등 **전이 동사** 사용 시 자산 축적(간접) vs 프로젝트 투입(직접) 구분 강제
-
----
-
-## 전 부서 준수 사항
-
-- 본 정정 이후 "신규 코어" 대신 **"코어 프레임워크 R&D"** 표현 사용 권장
-- 본 R&D 산출물을 "수상한 잡화점에 투입" 또는 "차기 프로젝트에 도입" 단정 표현 **금지**. 대신 "조직 자산으로 축적", "차기 프로젝트 시점에 활용 형태 판단" 사용
-- 관련 의사결정·요청·보고 시 본 공지 참조
-
----
-
-## 총괄PM 책임 명시
-
-본 오해는 1차 개발실 문서 작성 시점에 발생했고, 총괄PM이 **검증 없이 수용하여 PD님 결재 안건으로 상정**한 것이 구조적 원인. 총괄PM이 책임을 명확히 인정하며, 재발 시 역할 재검토 안건으로 회부. `feedback_requirement_framing.md`를 향후 모든 지시 수령 절차에 강제 적용.
diff --git a/공유/조직공지/2026-04-15_Phase3_NAS_post_receive_설치가이드.md b/공유/조직공지/2026-04-15_Phase3_NAS_post_receive_설치가이드.md
deleted file mode 100644
index d23baae..0000000
--- a/공유/조직공지/2026-04-15_Phase3_NAS_post_receive_설치가이드.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-from: 총괄PM
-to: PD님
-type: 설치가이드
-subject: Phase 3 — Gitea 저장소 웹훅 + Discord 실시간 알림 (가동 확정)
-status: 완료
-priority: normal
-created: 2026-04-15
-completed: 2026-04-15
-ref_phase: Phase 3
-actual_route: Gitea 저장소 웹훅(Discord 템플릿)
-target_channel: "#클로드ai (단일 채널, 전 조직 공용 알림)"
-verified_commit: f71ed75
----
-
-## 🎉 Phase 3 가동 확정 (2026-04-15)
-
-PD님이 다음 절차로 실제 설치·검증 완료:
-1. 저장소 Settings → 웹훅 → Webhook 추가 → Discord 선택
-2. Target URL 에 Discord webhook 등록
-3. Branch filter `main` 지정
-4. 테스트 커밋 `f71ed75` push → Discord `#클로드ai` 채널 정상 수신 스크린샷 확인
-
-본 설치 가이드는 **완료** 상태. 아래 본문의 NAS Git Hooks 기반 원안은 Gitea 환경 제약(Git Hooks 메뉴 미노출)으로 **채택 안 됨**. 실제 가동 경로는 **Gitea 저장소 웹훅 + 단일 채널 알림**이며, 채널별 분기는 필요 시 후속 안건(Phase 5+)으로 검토.
-
----
-
-# Phase 3 설치 가이드 — NAS post-receive + Discord 실시간 알림
-
-## 목적
-
-git push가 NAS 저장소에 도달하는 **그 순간**에 Discord webhook으로 알림을 발송하여, 부서 세션이 열려있지 않은 상태에서도 PD님·PM·부서가 이벤트를 즉시 인지한다. Claude 세션 간 통신의 근본 한계(세션 간 직접 통신 불가, 5분 throttle 지연)를 우회하는 **실시간 계층**.
-
-## 동작 개요
-
-```
-어느 세션이든 push 발생
-    ↓
-NAS bare repo의 hooks/post-receive 실행 (bash)
-    ↓
-변경 파일 경로 패턴 분석
-    ↓
-채널별 Discord webhook 호출
-    ├─ 공유/소통/PM↔개발실/* → #pm-inbox + #dev-inbox
-    ├─ 공유/소통/PM↔기획실/* → #pm-inbox + #plan-inbox
-    ├─ 공유/소통/개발실↔기획실/* → #dev-inbox 또는 #plan-inbox
-    └─ 공유/조직공지/* 또는 공유/공통_업무_규칙.md → #core-rules
-    ↓
-PD님·PM·부서 담당자 Discord 알림 즉시 수신 (모바일 포함)
-```
-
----
-
-## 준비물 (PD님 수작업 필요)
-
-### 1. Discord 서버·채널·webhook 준비
-
-**추천 채널 구조:**
-```
-BurningTimes 서버
-├── #pm-inbox        ← PM 수신 알림
-├── #dev-inbox       ← 개발실 수신 알림
-├── #plan-inbox      ← 기획실 수신 알림
-└── #core-rules      ← 조직공지·코어룰 변경 전 조직 알림
-```
-
-**각 채널의 webhook URL 발급 방법:**
-1. Discord 채널 우클릭 → 채널 편집 → 연동(Integrations)
-2. Webhook 만들기 → 이름 지정 (예: "BurningTimes-git") → 복사 URL
-3. 4개 채널 각각 반복, 총 4개 URL 수집
-
-### 2. NAS 저장소 접근
-
-SSH 또는 NAS 관리 콘솔로 bare repo 경로 접근 가능해야 함.
-- Gitea 기본 경로 예시: `/volume1/gitea-repos/BurningTimes/BurningTimesAi.git/`
-- 또는 `/var/lib/gitea/repositories/BurningTimes/BurningTimesAi.git/`
-
-정확한 경로는 NAS Gitea 관리자 페이지의 저장소 설정에서 확인.
-
----
-
-## 설치 절차 (PD님 실행)
-
-### STEP 1 — 스크립트 배치
-레포 루트에 이미 커밋된 `scripts/nas_post_receive.sh` 를 NAS로 복사:
-
-```bash
-# 옵션 A: NAS에 SSH 접속해서 git pull
-ssh admin@burning.i234.me
-cd /path/to/local-clone
-git pull origin main
-cp scripts/nas_post_receive.sh /volume1/gitea-repos/BurningTimes/BurningTimesAi.git/hooks/post-receive
-chmod +x /volume1/gitea-repos/BurningTimes/BurningTimesAi.git/hooks/post-receive
-
-# 옵션 B: Gitea 관리 UI에 git hook 직접 붙여넣기
-# 관리자 → Site Administration → Repositories → BurningTimesAi → Git Hooks → post-receive
-# → scripts/nas_post_receive.sh 내용 전체 붙여넣기 → Update
-```
-
-### STEP 2 — 환경변수 파일 생성
-webhook URL 보관 파일 생성. **본 파일은 절대 commit 금지** (C6 데이터 보호):
-
-```bash
-cat > /volume1/gitea-repos/BurningTimes/BurningTimesAi.git/hooks/post-receive-env <<'EOF'
-PM_WEBHOOK_URL="https://discord.com/api/webhooks/..."
-DEV_WEBHOOK_URL="https://discord.com/api/webhooks/..."
-PLAN_WEBHOOK_URL="https://discord.com/api/webhooks/..."
-ALL_WEBHOOK_URL="https://discord.com/api/webhooks/..."
-EOF
-
-chmod 600 /volume1/gitea-repos/BurningTimes/BurningTimesAi.git/hooks/post-receive-env
-```
-
-※ Gitea 관리 UI만 허용되는 환경이면 nas_post_receive.sh 내부 `source "$ENV_FILE"` 대신 직접 상단에 4개 URL을 변수로 하드코딩. 단 이 경우 script 파일 자체의 권한을 600으로 제한 필수.
-
-### STEP 3 — 테스트
-BurningTimesAi 저장소에 **의미 없는 테스트 커밋** push:
-```bash
-cd E:\BurningTimesAi
-echo "" >> 공유/조직공지/.test_phase3.md
-git add 공유/조직공지/.test_phase3.md
-git commit -m "test(phase3): post-receive webhook 검증"
-git push origin main
-
-# 기대 결과: Discord #core-rules 채널에 즉시 알림 도착 ✅
-
-# 테스트 커밋 원복
-git rm 공유/조직공지/.test_phase3.md
-git commit -m "revert: phase3 테스트 커밋"
-git push origin main
-```
-
-### STEP 4 — 설치 완료 보고
-PD님이 다음 경로로 완료 보고 파일을 작성·커밋:
-- `공유/소통/PD→PM/2026-MM-DD_Phase3_설치완료.md` (또는 기존 PD 로그)
-- 제가 fetch 확인 후 Phase 3 가동 확정.
-
----
-
-## 트러블슈팅
-
-| 증상 | 원인 | 해결 |
-|------|------|------|
-| Discord에 메시지 안 옴 | webhook URL 잘못 | hooks/post-receive.log 확인, curl 수동 테스트 |
-| 한글 파일명 깨짐 | NAS locale 설정 | `LC_ALL=ko_KR.UTF-8` 를 post-receive 상단 추가 |
-| 모든 변경에 알림 안 감 | 경로 패턴 미매치 | nas_post_receive.sh 의 case 절 경로를 실제 변경 파일로 조정 |
-| curl 명령 없음 | NAS busybox 환경 | wget 또는 nc(netcat) 기반으로 변환 필요. 별도 안건 |
-
----
-
-## 보안·C6 준수
-
-- `post-receive-env` 파일은 **절대 commit 금지**. `.gitignore` 무관 (NAS bare repo 파일)
-- webhook URL 유출 시 즉시 Discord 채널 편집 → Webhook 삭제·재발급
-- Discord 서버 자체의 사용자 초대·역할 관리는 PD님 전적 관리
-
----
-
-## 연관
-- **Phase 1** (a556d6a): 공유/소통/ 허브 6축 — 본 알림의 입력
-- **Phase 2** (9a6ef2f): SessionStart inbox_scan — 세션 내 알림
-- **Phase 3** (본 문서): NAS 서버측 실시간 알림 — 세션 외 알림
-- **C21**(초안): C21-1 즉시 push 의무 → Phase 3 알림 실효성의 전제
-- **C22**: 본 가이드의 용어(Phase 3, inbox, webhook)는 이후 변경 금지
-
-## 상태
-
-- [x] scripts/nas_post_receive.sh 커밋 완료
-- [x] 본 설치 가이드 커밋 완료
-- [ ] PD님: Discord 서버·채널·webhook URL 4개 준비
-- [ ] PD님: NAS에 hook 스크립트 배치 + env 파일 생성
-- [ ] PD님: 테스트 커밋 1건 push → Discord 수신 확인
-- [ ] 총괄PM: 수신 확인 보고 수령 후 Phase 3 가동 확정
-
-**준비 완료 시 본 문서의 status 를 `완료` 로 갱신 후 commit·push 부탁드립니다.**
diff --git a/공유/조직공지/2026-04-15_안건_축2_워크트리_에이전트_자동동기화.md b/공유/조직공지/2026-04-15_안건_축2_워크트리_에이전트_자동동기화.md
deleted file mode 100644
index 5335d29..0000000
--- a/공유/조직공지/2026-04-15_안건_축2_워크트리_에이전트_자동동기화.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-from: 총괄PM
-to: PD님
-type: 안건_신설_대기
-subject: 축 2 — 워크트리 생성 시 부서 에이전트 자동 동기화
-status: 대기
-priority: normal
-created: 2026-04-15
-ref_event: Phase 1+2+3 검증 중 발견 (2026-04-15)
-parent_cycle: C22·C19-3-4·Phase1~3 사이클
----
-
-# 축 2 안건 — 워크트리 `.claude/agents/` 자동 동기화
-
-## 배경
-
-2026-04-15 Phase 1+2+3 구축 완료 후 부서 세션 동기화 검증 과정에서 발견:
-
-- Claude Code가 세션 시작 시 **cwd의 `.claude/agents/` 만** 로드한다.
-- Claude Code가 자동 생성하는 워크트리 하위 `.claude/agents/` 에는 **`pm-general.md` 만 자동 배치**되고 부서 에이전트(`개발실/.claude/agents/*.md`, `기획실/.claude/agents/*.md`)는 누락된다.
-- 결과: 부서 세션에서 `planning-lead`, `개발실장` 등의 서브에이전트를 `Task` 툴로 호출할 수 없음 ("Available agents" 목록에 부재).
-
-**잠정 해결(축 1)**: 2026-04-15 본 PM 세션이 다음 2개 워크트리에 부서 에이전트 수동 복제:
-- `기획실/.claude/worktrees/confident-mendel/.claude/agents/`
-- `개발실/.claude/worktrees/gracious-driscoll/.claude/agents/`
-
-**한계**: 워크트리는 Claude Code가 세션별로 자동 생성·제거하므로 수동 복제는 지속 불가. **자동화(축 2)가 근본 해결책**.
-
----
-
-## 축 2 설계 후보 (2026-04-15 C22 준수·설명적 이름으로 확정, 이후 변경 금지)
-
-### hook 확장안 — SessionStart hook 확장 (`scripts/agent_sync.sh`)
-- 기존 `.claude/settings.json` 의 SessionStart 훅에 에이전트 복제 스크립트 추가
-- 동작: cwd 기반 부서 판단 → 해당 부서 `.claude/agents/*.md` 를 cwd의 `.claude/agents/` 로 복사
-- 장점: 기존 hook 체계와 일관, 구현 간단
-- 단점: **hook은 세션이 이미 시작된 후 실행** → 그 세션의 이미 로드된 에이전트 목록은 갱신 안 됨 (다음 세션부터 유효). 첫 세션은 여전히 수동 필요.
-
-### setup 확장안 — `setup_windows.ps1` 확장
-- 기존 PC 셋업 스크립트에 워크트리 스캔·부서 에이전트 복제 단계 추가
-- 장점: 세션과 무관하게 디스크 상태를 선제적으로 보장
-- 단점: **Claude Code가 세션마다 새 워크트리를 생성** → setup 시점 이후 생성된 워크트리는 커버 못 함. 수시 재실행 필요.
-
-### 감시자안 — PowerShell 파일 감시자(FileSystemWatcher) 상주
-- `기획실/.claude/worktrees/` 와 `개발실/.claude/worktrees/` 를 감시해 새 워크트리 생성 시 자동 복제
-- 장점: 생성 즉시 자동 복제. 어떤 세션이든 첫 호출부터 부서 에이전트 가용.
-- 단점: 상주 프로세스 필요. PC 재부팅 시 재시작·자동 서비스화 필요.
-
-### 탐색규칙 조사안 — Claude Code `.claude/agents/` 탐색 규칙 조사·활용
-- 공식 문서 정독 + 실증으로 `.claude/agents/` 의 **상위 디렉토리 탐색/병합** 가능성 재확인
-- 만약 Claude Code가 cwd 상위(예: `기획실/.claude/agents/`) 를 병합해 로드하는 옵션이 있다면 **복제 없이 해결 가능**
-- 장점: 복제·동기화 불필요, 가장 깔끔
-- 단점: Claude Code 버전·옵션·환경 의존. 현재 동작은 cwd만 로드로 보이지만 재확인 필요.
-
-### 루트 통합안 — 루트 `.claude/agents/` 에 전 부서 에이전트 통합
-- 모든 부서 에이전트를 루트 `.claude/agents/` 에 모아 어느 세션에서든 접근 가능하게 함
-- 장점: 복제·동기화 불필요
-- 단점: **부서 격리 원칙 훼손** (개발실 세션에서 planning-lead 호출 가능해지는 등 혼재 우려)
-
----
-
-## 결정 필요 사항 (PD님)
-
-1. **우선 순위**: 본 축 2를 언제 본격 착수할지 (이번 사이클 직후 / 다음 사이클 / 우선순위 낮음) — 2026-04-15 PD님 "지금 바로 착수" 지시로 **이번 사이클 착수 확정**
-2. **후보 선정**: 5개 설계 후보 중 PD님 선호 경로. 총괄PM 추천: **탐색규칙 조사안 선행 → 불가 시 hook 확장안 + 감시자안 병행**
-3. **선행 조사 허용 여부**: 탐색규칙 조사안을 위해 PM 세션이 Claude Code 공식 문서와 실증 실험을 진행해도 될지 (토큰 소비 수반)
-
----
-
-## 관련
-- `feedback_automation_trust.md` (본 축 1 발견 경위에서 저의 "외관 판정" 오류 자진 보고)
-- C19-3-4 (자동화 영역 담당 검증 의무)
-- C22 (용어 일관: "축 1 / 축 2" 명칭 유지)
-- C5 (정직성: 축 1은 즉시·한시적 해결, 축 2가 근본 해결임을 명시)
-- Phase 1+2+3 사이클 최종 단계의 후속 과제
-
-## 처리 이력
-- 2026-04-15: 안건 신설·main 반영. PD님 결정 대기.
diff --git a/공유/조직공지/2026-04-16_안건_새대화_hook_타이밍_보장.md b/공유/조직공지/2026-04-16_안건_새대화_hook_타이밍_보장.md
deleted file mode 100644
index e6b1694..0000000
--- a/공유/조직공지/2026-04-16_안건_새대화_hook_타이밍_보장.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-from: 총괄PM
-to: PD님
-type: 안건_신설_대기
-subject: 새 대화 생성 시 부서 에이전트 등록 hook 타이밍 보장
-status: 대기
-priority: normal
-created: 2026-04-16
-ref_event: 2026-04-16 본 사이클 마지막 단계 — 개발실 첫 새 대화(bold-zhukovsky) 부서 에이전트 미등록 vs 두 번째 새 대화(relaxed-dijkstra) 정상 등록 비대칭 실증
-parent_cycle: Skill 패킹 단일 SOT 전환 사이클
----
-
-# 안건 — 새 대화 생성 시 부서 에이전트 등록 hook 타이밍 보장
-
-## 1. 배경
-
-### 1) 실증 사건 (2026-04-16)
-1. 동일 폴더(개발실)에서 두 번 새 대화 생성
-2. **첫 새 대화 (bold-zhukovsky)**: 디스크에 부서 에이전트 4개 정확히 복제됐으나, Claude Code 런타임이 인식 못 함 → Available agents에 부서 에이전트 미등장
-3. 종료 후 재resume도 갱신 실패 (영속 대화 한계)
-4. **두 번째 새 대화 (relaxed-dijkstra)**: 디스크 동일 상태에서 Available agents에 부서 에이전트 4개 모두 정상 등장
-
-### 2) 추정 원인 (⚠️ C23 명시 — 확정 미검증)
-1. Claude Code의 `.claude/agents/` 스캔 시점이 SessionStart hook 실행 완료 시점보다 빠를 가능성
-2. 첫 새 대화: 워크트리 자동 생성 → Claude Code 스캔(pm-general.md만 있음) → SessionStart hook 실행(agent_sync.sh가 부서 에이전트 복제) → 너무 늦음
-3. 두 번째 새 대화: hook 타이밍이 우연히 적시였거나, 디스크 캐시 워밍업 등 환경 차이로 정상 동작
-
----
-
-## 2. 해결 방향 후보
-
-### 1) 운용 규약안 (즉시 가능, 임시방편)
-1. 새 대화 생성 후 Available agents에 부서 에이전트가 안 보이면 **그 대화 폐기 후 같은 폴더에서 다시 새 대화 생성**
-2. 검증 절차를 부서 영속 대화 셋업 표준에 포함
-3. 본 사이클 PD님 실증으로 효과 확인됨 (relaxed-dijkstra 정상 작동)
-
-### 2) hook 타이밍 보강안 (구조적 해결 시도)
-1. agent_sync.sh를 SessionStart hook 외 추가 시점에도 실행
-2. 후보: PreToolUse hook (첫 도구 호출 직전)·UserPromptSubmit hook (첫 프롬프트 직후)
-3. 단점: hook 실행 후에 Claude Code가 에이전트 레지스트리를 다시 스캔하지 않으면 효과 없음 — 사전 조사 필요
-
-### 3) 루트 통합안 (격리 약화 감수)
-1. 부서 에이전트 파일을 **루트 `.claude/agents/`** 에도 복제 배치
-2. Claude Code가 새 워크트리 생성 시 루트 `.claude/agents/` 전체를 자동 복제하므로 첫 SessionStart 시점부터 부서 에이전트 즉시 등록
-3. 단점: 부서 격리 원칙 약화 (개발실 세션에서 기획팀장 호출 가능 등 혼재)
-
-### 4) Claude Code 자체 개선 요청안
-1. Anthropic GitHub 이슈로 "SessionStart hook 완료 후 .claude/agents/ 재스캔" 기능 요청
-2. 장기적 본질 해결
-3. 단점: 외부 의존, 적용 시점 불확실
-
----
-
-## 3. 결정 필요 사항 (PD님)
-
-### 1) 우선 순위
-1. 즉시 운용 규약안만 적용 (1번)
-2. 1번 + 2번 또는 3번 추가 조사
-3. 다음 사이클로 이연
-
-### 2) 부서 격리 원칙 vs 실용성
-1. 격리 원칙 유지 → 1번·2번·4번 중 선택
-2. 실용성 우선 → 3번 (격리 약화 감수)
-
-### 3) 본 안건의 사이클 위치
-1. 다음 사이클 본격 처리
-2. 한참 미뤄도 무방 (현 운용 규약으로 충분)
-
----
-
-## 4. 운용 규약안 (즉시 적용 권장)
-
-검증되지 않았어도 본 안건 결정 전까지 다음 운용으로 회피:
-
-```
-부서 영속 대화 셋업 절차 (2026-04-16 잠정):
-1. 부서 폴더에서 새 대화 생성
-2. 첫 프롬프트로 "Available agents 출력해. 부서 에이전트 등장하는지 확인" 입력
-3. 부서 에이전트 등장: 그 대화를 새 영속 대화로 지정 → 검증 완료
-4. 부서 에이전트 미등장: 그 대화 폐기 → 같은 폴더에서 다시 새 대화 생성 → 단계 2부터 반복
-5. 보통 2~3회 시도 내 정상 작동
-```
-
----
-
-## 5. 연관
-
-- **C24** (부서 세션 영속 대화 운용 원칙): 본 안건은 C24-3 "신규 대화 생성으로 복구" 예외 절차의 보강
-- **C26** (코어룰 단일 SOT 갱신 원칙): Skill 패킹 자동 주입의 마지막 안정성 보강
-- **`scripts/agent_sync.sh`**: 본 안건 해결 시 수정 또는 폐기 검토
-- **별건 안건 (이연)**: `2026-04-16_안건_Skill_패킹_근본해결.md` 와 함께 차세대 사이클 검토 대상
-
-## 처리 이력
-- 2026-04-16: 안건 신설·main 반영 (Skill 패킹 사이클 마지막 단계 발견 사건)
-- (대기) PD님 결정 3항 → 우선순위·해결 방향·사이클 위치
diff --git a/공유/조직공지/2026-04-19_세션최종점검_6개선안건_이어받기.md b/공유/조직공지/2026-04-19_세션최종점검_6개선안건_이어받기.md
deleted file mode 100644
index 224712f..0000000
--- a/공유/조직공지/2026-04-19_세션최종점검_6개선안건_이어받기.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-type: 조직공지
-date: 2026-04-19
-kind: 세션 최종 점검 결과 이어받기 SOT
-authority: PD님 직접 지시 (공유 전용, 본 세션 집행 안 함)
-sot_boundary: 본 세션 점검 결과 6건 개선 안건. 신 세션이 이어받아 집행 착수 가능
----
-
-# 2026-04-19 — 세션 최종 점검 결과 6개선 안건 이어받기
-
-## 배경
-
-PD님 최종 점검 지시로 본 세션 종료 직전 조직 자산·감사 체계·hook 건강도 전수 점검. **6건 개선 안건 발견**. PD님 추가 지시로 "본 세션에서 집행하지 말고 이어받을 수 있도록 공유만 수행".
-
-본 문서는 신 세션·신 PC가 해당 안건을 즉시 착수할 수 있는 **이어받기 단일 SOT**.
-
-## 6건 안건 요약표
-
-| # | 우선순위 | 안건 | 증상 요지 | 근본 원인 추정 |
-|---|---------|------|----------|-------------|
-| A | 🔴 긴급 | auditor_call_log.sh 미작동 | pm-auditor Task 호출 2회 있었으나 로그 기록 부재 | PostToolUse Task matcher hook 미호출 또는 stdin JSON 구조 불일치 |
-| B | 🟡 중요 | P24 hook false positive | commit count 기반 경고 → 조직 규칙 세션마다 오알람 | `pm_context_restore.sh` 경로 기반 검사 미적용 |
-| C | 🟡 중요 | UNRESOLVED 2건 미해소 | 2026-04-19 21:11·21:12 BYPASS 환경변수 결함 경고 | feedback은 기록했으나 로그엔 RESOLVED 누락 |
-| D | 🟢 경미 | .live/README.md 영구 소실 | 본 세션 초기 sentinel 손실 시 함께 삭제 | marker만으로 기능 충분, 조직 문서 역할만 상실 |
-| E | 🟢 경미 | sync 스크립트 mtime 보호 비대칭 | D안에서 중앙→레포만 mtime 보호 추가 | 레포 SOT 원칙상 정상이나 일관성 검토 |
-| F | 🟢 경미 | 감사관 3종 정의 일관성 | pm-auditor만 다수 체크 추가, dev·plan-auditor 대응 불명 | 3축 감사 정합성 점검 필요 |
-
-## 안건 상세
-
-### 🔴 A. auditor_call_log.sh 미작동 (긴급)
-
-#### 증상
-- `$HOME/.claude/.nerdnavis_auditor_calls/2026-04-19.log` **파일 없음**
-- 본 세션 pm-auditor Task 호출 **2회** (C35-9·10 사전 감사·집행 전 감사) 있었으나 기록 부재
-
-#### 영향
-- `auditor_guard.sh`의 30분 윈도우 검사 **무의미** (기록 없음 → 항상 UNRESOLVED)
-- C35-10 장기 패턴 분석 **입력 데이터 부재**
-- 본 세션에서 BYPASS 10+건 과다 사용의 구조적 원인
-
-#### 착수 방향
-1. `scripts/auditor_call_log.sh` Read + stdin JSON 구조 로직 확인
-2. Claude Code PostToolUse hook의 Task matcher 지원 여부 docs·실측 조사
-3. 필요 시:
-   - (a) stdin JSON 매칭 패턴 수정
-   - (b) matcher 자체를 다른 방식으로 변경 (SessionEnd 스캔 등)
-   - (c) Layer 2를 완전 재설계 (Task tool_use 감지 불가 시 다른 방식)
-
-### 🟡 B. P24 hook false positive 구조 결함
-
-#### 증상
-- `pm_context_restore.sh`가 **commit count 기반** P24 경고 발생
-- 본 세션처럼 조직 규칙·hook·feedback 작업 세션에서 `프로젝트/` 직접 수정 0건이어도 경고 발생
-- 신 세션 시작마다 반복 알람
-
-#### 영향
-- PD님·PM 인지 피로
-- 실제 P24 위반(진짜 프로젝트 변경 무시) 신호가 false positive에 섞여 변별력 저하
-
-#### 착수 방향
-1. `scripts/pm_context_restore.sh` Read (P24 감지 로직 위치 확인)
-2. 경로 기반 검사로 전환:
-   ```bash
-   PROJECT_COMMITS=$(git log --since="yesterday" --name-only --pretty=format: | sort -u | grep "^프로젝트/" | head -10)
-   [ -z "$PROJECT_COMMITS" ] && exit 0  # 프로젝트 직접 수정 없으면 경고 생략
-   ```
-3. 실제 `프로젝트/<프로젝트명>/` 직접 수정 commit만 경고 대상으로 필터링
-
-### 🟡 C. UNRESOLVED 경고 2건 미해소 (2026-04-19 21:11·21:12)
-
-#### 증상
-- `$HOME/.claude/.nerdnavis_warning_ignored/2026-04-19.log` 에:
-  ```
-  2026-04-19_21:11:59 UNRESOLVED target=의무 영역 파일 수정
-  2026-04-19_21:12:48 UNRESOLVED target=의무 영역 파일 수정
-  ```
-- feedback_pm_warning_ignored_pattern.md에 "2차 실증 사례"로 경위 기록됐으나 **로그엔 여전히 UNRESOLVED**
-
-#### 영향
-- `audit_pattern_analyzer.sh`가 매 SessionStart에서 "미해소 경고 N건" 환기 지속
-
-#### 착수 방향
-1. `$HOME/.claude/.nerdnavis_warning_ignored/2026-04-19.log`에 수동 RESOLVED 마커 append:
-   ```
-   2026-04-20_HH:MM:SS RESOLVED — BYPASS 환경변수 결함 원인 확정·D안 파일 기반 전환으로 구조 해결. 기록 보존 (참조: feedback_pm_warning_ignored_pattern.md 2차 사례)
-   ```
-2. 반복 기록 방지를 위해 `audit_pattern_analyzer.sh`에 "feedback 참조된 과거 사례는 반복 알림 제외" 로직 검토
-
-### 🟢 D. .live/README.md 영구 소실
-
-#### 증상
-- 중앙 저장소 `$HOME/.claude/nerdnavis-live/` 에 `.junction-marker` 57B 만 존재
-- README.md 없음 (본 세션 초기 sentinel 손실 시 함께 삭제됨)
-
-#### 영향
-- 기능 영향 0 (marker만으로 C34 작동 정상)
-- 조직 문서 역할 상실 (README가 안내 문서였음)
-
-#### 착수 방향
-- PD님 결정 필요:
-  1. 복구 (안내 문서 새로 작성)
-  2. 현 상태 유지 (기능 문제 없음)
-
-### 🟢 E. sync_memory_repo_to_central.sh mtime 보호 비대칭
-
-#### 증상
-- D안으로 `sync_memory_central_to_repo.sh`는 mtime 비교 추가 (레포 최신본 보호)
-- 반대 방향 `sync_memory_repo_to_central.sh`는 **unflushed 대피 로직만** (mtime 직접 비교 없음, `-nt`는 있으나 용도 다름)
-
-#### 영향
-- 레포 SOT 원칙상 현 로직 정상 작동
-- 단 대칭성 측면에서 일관성 부재
-- **실질 필요성 검증 필요** (`feedback_pm_surface_rationale_proposal.md` 체크리스트 4문항 적용 권장)
-
-#### 착수 방향
-- 체크리스트 4문항 통과 여부 검증 후 결정:
-  - 실질 이득: 대칭성 보강 외에 실제 이득 있는가?
-  - 실사용 사례: 어떤 시나리오에서 추가 mtime 보호가 필요한가?
-  - 현 상태 유지 비교: unflushed 대피 로직으로 충분하지 않은가?
-
-### 🟢 F. 감사관 3종 정의 파일 일관성
-
-#### 증상
-- pm-auditor: 5-A·5-B·5-C·5-D·6-A·6-B 다수 추가 완료
-- dev-auditor·plan-auditor: 6-A만 추가 상태 (5-B·5-C·5-D 등 대응 불명확)
-
-#### 영향
-- 3축 감사 정합성 저하 가능성
-- 개발팀·기획팀 영역에서 유사 패턴 발생 시 감사 누락
-
-#### 착수 방향
-1. `.claude/agents/pm-auditor.md`·`dev-auditor.md`·`plan-auditor.md` 3종 체크 항목 비교
-2. 개발팀·기획팀 영역에 준용 가능한 체크 확장 (예: 백업 포맷 체크는 dev에 이미 있음)
-3. 범영역 공통 체크(안건 프레이밍 중복·종결 안건 언급·실질 필요성 검증)는 pm-auditor 전담 유지 권장
-
-## 이어받기 가이드 (신 세션·신 PC)
-
-### 착수 순서
-
-1. `git pull` 후 세션 재시작 → SessionStart hook 자동 복원 (CLAUDE.md·SKILL.md·MEMORY.md·최근 feedback 요지·PD 지시 로그)
-2. **본 조직공지 Read** — 6건 안건 전수 파악
-3. `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 활성 테이블에서 **#48 확인** (본 건 이어받기)
-4. 우선순위별 착수:
-   - **A 긴급 먼저** — `auditor_call_log.sh` 조사·수정 (다른 안건 해결이 이 결함에 의존할 수 있음)
-   - **B·C 중요** — false positive 구조 결함·UNRESOLVED 미해소
-   - **D·E·F 경미** — 여유 있을 때 검토
-5. C35-1 의무 호출 대상 작업은 pm-auditor 사전 호출 (**단 A가 미해결이면 Layer 2 기록 안 됨** 염두)
-
-### 각 안건 집행 시 공통 의무
-
-- 본 세션 commit 체인(`53fa316`~`4400e08`) 14건 기반으로 진행
-- `feedback_pm_surface_rationale_proposal.md` 체크리스트 4문항 자문 후 제안
-- 집행 전 pm-auditor 사전 호출 (C35-1 의무)
-- 집행 후 본 조직공지에 각 안건 완료 표시 append
-
-## 관련 feedback (신 세션 필수 Read)
-
-- `memory/org/feedback_pm_surface_rationale_proposal.md` (PM 표면적 근거 제안 패턴, 본 세션 신설)
-- `memory/org/feedback_pm_warning_ignored_pattern.md` (C35 경고 무시 누적 SOT — A·C 안건 직결)
-- `memory/org/feedback_memory_sync_overwrite.md` (C34 sync 덮어쓰기 사고 — E 안건 관련)
-- `memory/org/feedback_central_sentinel_loss.md` (sentinel 손실 — D 안건 관련)
-- `memory/org/feedback_issue_under_reporting.md` · `feedback_agenda_framing_duplication.md` · `feedback_resolved_agenda_unnecessary_reference.md` (PM 보고 품질 4연속 패턴)
-
-## 참조
-
-- 본 세션 commit 체인: `53fa316` → `4400e08` (14건)
-- `공유/대화로그/조직운영/2026-04-19.md` (본 세션 상세 경위)
-- 완료 아카이브 #39·#40·#41·#42·#43·#44·#45·#46·#47
-- 신규 활성 지시 **#48 본 건 이어받기** (대기 상태)
-
----
-
-**중요**: 본 세션은 "공유만 수행" 지시로 종료. 실제 개선 집행은 **신 세션이 수행**. PD님의 추가 지시 또는 신 PM의 자율 착수로 진행.
-
-**누락 없음 검증**: 본 문서는 최종 점검 보고(6건)를 기준으로 작성됨. 각 안건의 증상·영향·착수 방향이 신 세션이 즉시 이해할 수 있는 수준으로 구체화. 관련 feedback·commit·PD 지시 번호 모두 명시.
diff --git a/공유/조직공지/신PC_셋팅_체크리스트_v1.md b/공유/조직공지/신PC_셋팅_체크리스트_v1.md
deleted file mode 100644
index 87ffb6e..0000000
--- a/공유/조직공지/신PC_셋팅_체크리스트_v1.md
+++ /dev/null
@@ -1,147 +0,0 @@
-# 신 PC 셋팅 체크리스트 v1
-
-> **발행**: 2026-04-15 (개발실장 주도, 총괄PM·PD님 공유)
-> **목적**: 회사/집/노트북 등 새로운 PC에서 조직 레포(`BurningTimesAi`)를 가동할 때 동일한 재현 결과를 보장하기 위한 표준 체크리스트.
-> **근거**: PD 지시 #7·#7-α (Git 동기화 완료) → #8 (개발실 셋팅 마무리 잔여 과제 3종).
-> **원칙**: C5 (정보의 정직성) · C14 (토큰 최소화 — 본 문서가 유일한 셋팅 SOT) · `공유/공통_업무_규칙.md` P-설정 관련 조항 준수.
-
----
-
-## 0. 전제
-
-- Windows 10/11 + PowerShell 5.1 이상 (또는 macOS/Linux — macOS는 `setup/setup_macos.sh` 사용)
-- Git 설치 완료
-- Claude Code CLI 설치 완료
-- Gitea 접근 자격 (PAT 또는 SSH key) 준비
-
----
-
-## 1. Clone
-
-레포 루트는 **사용자가 원하는 위치**(예: `C:/Users/PC/Documents/BurningTimes` 또는 `E:/BurningTimesAi`)로 자유 선택 가능.
-
-```powershell
-# HTTPS
-git clone https://burning.i234.me/BurningTimes/BurningTimesAi.git "<원하는 경로>"
-
-# 또는 SSH
-git clone ssh://git@burning.i234.me:30030/BurningTimes/BurningTimesAi.git "<원하는 경로>"
-```
-
-**체크**
-- [ ] clone 성공
-- [ ] `cd <레포 루트>` 후 `git log -1` 로 최신 커밋 확인
-
----
-
-## 2. 셋업 스크립트 실행
-
-### Windows
-
-```powershell
-cd <레포 루트>
-.\setup\setup_windows.ps1
-```
-
-스크립트가 수행하는 작업:
-1. `paths.local.json` 자동 생성 (레포 루트 드라이브 기준으로 `UNITY_PROJECT_ROOT`·`FRAMEWORK_PKG_ROOT` 추정)
-2. `memory/org/` 디렉토리 준비
-3. `~/.claude/projects/<해시>/memory/` junction → `memory/org/` 연결
-
-### macOS / Linux
-
-```bash
-cd <레포 루트>
-bash setup/setup_macos.sh
-```
-
-**체크**
-- [ ] 스크립트 정상 종료 (`셋업 완료. 'git pull'로 최신 상태 유지 권장.` 메시지)
-- [ ] `paths.local.json` 파일 실존
-- [ ] Claude 프로젝트 해시 폴더에서 `memory` junction 생성 로그 확인
-
----
-
-## 3. paths.local.json 실값 확인·보정
-
-자동 추정값이 실제와 다른 경우 수동 보정.
-
-```json
-{
-  "NERDNAVIS_ROOT": "<레포 루트 실경로>",
-  "UNITY_PROJECT_ROOT": "<Unity 프로젝트 실경로 — 미설치 시 빈 값 가능>",
-  "FRAMEWORK_PKG_ROOT": "<BT.Framework 실경로 — 미설치 시 빈 값 가능>",
-  "TABLE_EXPORT_ROOT": "${UNITY_PROJECT_ROOT}/Assets/ResWork/Table/Export",
-  "GITEA_URL": "https://burning.i234.me",
-  "GITEA_SSH": "ssh://git@burning.i234.me:30030",
-  "HOSTNAME": "<본 PC 식별자>"
-}
-```
-
-**체크**
-- [ ] `NERDNAVIS_ROOT` 가 레포 실경로와 일치
-- [ ] `UNITY_PROJECT_ROOT`·`FRAMEWORK_PKG_ROOT` 가 본 PC에 존재하거나 의도적으로 빈 값
-- [ ] 파일이 `.gitignore` 로 추적 제외 상태 (`git status` 에 나타나지 않음)
-
----
-
-## 4. 검증 스크립트 실행 (필수)
-
-```powershell
-# Windows
-.\scripts\verify_setup.ps1
-```
-
-3축 검증을 수행:
-1. **파일 존재**: `paths.local.json` 파싱·필수 키·`memory/org` 실체
-2. **OS 동작**: junction 의 reparse point 속성·타깃 경로
-3. **실행 결과**: `MEMORY.md` junction 경유 읽기 가능 여부, 경로 추상화 잔존 구 경로 스캔, `.gitignore` 규칙, 조직 공용 승인 `.claude/settings.json`
-
-**체크**
-- [ ] `exit 0` 로 종료 (= "셋팅 검증 통과. 작업 착수 가능.")
-- [ ] `[FAIL]` 라인 0건
-- [ ] `[WARN]` 은 본인 환경상 허용 가능한 것인지 육안 확인 (예: Unity 미설치 PC의 `UNITY_PROJECT_ROOT` 경고)
-
----
-
-## 5. Claude Code 동작 확인
-
-```bash
-# 레포 루트에서
-claude
-```
-
-- [ ] `MEMORY.md` 가 세션 초입에 자동 로드됨 (user memory 인덱스 표시)
-- [ ] `CLAUDE.md` (조직 최상위) 의 지시가 인지됨 — "PD님"·"총괄PM" 호칭 사용
-- [ ] 조직 공용 승인(`.claude/settings.json`) 의 Bash/Edit/Write 포괄 허용이 반영됨 (개별 승인 반복 없음)
-
----
-
-## 6. 자주 발생하는 문제
-
-| 증상 | 원인 | 조치 |
-|------|------|------|
-| `verify_setup.ps1` 파싱 에러 | 파일 인코딩이 UTF-8 BOM 아님 | 레포 재 clone 또는 스크립트 재 pull |
-| junction 이 실체 폴더로 존재 | Claude Code 가 기존에 실제 `memory` 폴더를 만들어둠 | `setup_windows.ps1` 재실행 (자동 백업 후 junction 교체) |
-| `MEMORY.md` 안 읽힘 | junction 타깃이 `memory` 루트가 아니라 `memory/org` 여야 함 | `setup` 스크립트는 정상이지만 수동 생성 시 `memory -> memory/org` 구조 확인 |
-| `paths.local.json` 이 커밋되려 함 | `.gitignore` 누락 | 레포 재 pull 또는 `.gitignore` 에 `paths.local.json` 라인 존재 확인 |
-| PC 간 승인 설정 불일치 | `.claude/settings.local.json` 은 `.gitignore` 대상이라 이동 불가 | 공용 승인은 **`.claude/settings.json`** (커밋됨) 로 유지. 개별 실험은 local 로 분리 |
-
----
-
-## 7. 변경 이력
-
-| 버전 | 일자 | 변경 | 담당 |
-|------|------|------|------|
-| v1   | 2026-04-15 | 최초 발행 (PD 지시 #8 처리) | 개발실장 |
-
----
-
-## 8. 참조
-
-- `setup/setup_windows.ps1`, `setup/setup_macos.sh`
-- `scripts/verify_setup.ps1`
-- `paths.local.json.template`
-- `README.md` (레포 루트)
-- `공유/공통_업무_규칙.md` (부록 A: 작업 착수 체크)
-- `memory/org/MEMORY.md` 인덱스 — [PC 간 승인 설정 일관성](../../memory/org/feedback_permissions_portability.md)
diff --git a/공유/조직공지/폐기_규칙_아카이브.md b/공유/조직공지/폐기_규칙_아카이브.md
index 8a6fb0f..0668280 100644
--- a/공유/조직공지/폐기_규칙_아카이브.md
+++ b/공유/조직공지/폐기_규칙_아카이브.md
@@ -505,3 +505,24 @@ C37-5 순서 정렬 의무 **전 규칙 달성**.
 - 본 파일 삭제·이동은 **PD님 직접 승인 필수** (C19-2 되돌리기 어려운 액션)
 - 본 파일 내용 축약·요약은 **PM 재량 아님, PD님 결정 안건**
 - git 추적 대상으로 영구 보존
+
+---
+
+## P17 (이전 프로젝트 전용 ★ 조건 배타 배치 7종) — 완전 폐기 2026-04-21
+
+### 6필드 기록
+
+1. **규칙 번호**: P17
+2. **변경일**: 2026-04-21
+3. **변경 전 상태**: SKILL.md P17 "★ 조건 배타 배치 규칙 (수상한 잡화점 프로젝트)" — Prove-2-of-3 체계 슬롯2·3 ★ 조건 배타 조합 7종 본문 + 스테이지 기획 준수 사항 + 적용 범위 (이전 프로젝트 한정). 약 50줄
+4. **변경 후 상태**: SKILL.md에서 **완전 삭제** (C14-5 확장 "폐기 조항 본문 완전 삭제 원칙" 준수). CLAUDE.md 요약 블록 P17 1줄도 삭제. 번호 구멍 P17 허용
+5. **사유**: 조직 전환 — BurningTimes 신설 조직은 이전 프로젝트(덱빌딩 카드 게임)와 장르 이질. EerieVillage(2D 플랫포머)는 Prove-2-of-3 체계 이식 여부 자체가 미결. 이전 프로젝트 전용 규칙을 BT 코어룰에 잔존시키는 것은 **C14 토큰 최소화 위반** + **신생 조직 운영 혼선** 유발
+6. **경위**: 2026-04-21 PD님 직접 지시 결정 1 "완전 폐기 + 아카이브 이관" — PM 권고 A안 수용. 배경: Phase 2-B `기획_system_designer_v1.md` 아카이브에서 "P17 배타 조합 7종 방법론" 교훈이 이미 영구 보존됨. 향후 EerieVillage 메카닉이 조건 풀을 요구하게 되면 **신규 규칙으로 재설계**
+
+### 교훈 보존 경로
+- `공유/조직자산/시행착오_아카이브/기획_system_designer_v1.md` §조건 체계 설계 방법론
+- `공유/조직자산/시행착오_아카이브/기획_content_designer_v1.md` §P17 매트릭스 방법론
+- `공유/조직자산/시행착오_아카이브/기획_level_designer_v1.md` §Prove-2-of-3 슬롯 배치 난이도 곡선
+
+### 재활용 시나리오
+EerieVillage 또는 차기 프로젝트 메카닉이 조건 슬롯 체계를 도입하면 본 아카이브 교훈을 **신규 P 번호**로 재설계. P17 번호 재사용은 금지 (C14-5 확장 "번호 구멍 허용").
diff --git a/공유/조직공지/폐기_규칙_아카이브.md.bak_20260420_1412 b/공유/조직공지/폐기_규칙_아카이브.md.bak_20260420_1412
deleted file mode 100644
index 7c8254b..0000000
--- a/공유/조직공지/폐기_규칙_아카이브.md.bak_20260420_1412
+++ /dev/null
@@ -1,347 +0,0 @@
----
-type: 폐기규칙아카이브
-created: 2026-04-18
-maintainer: 총괄PM
-sot_boundary: 폐기·개정된 핵심 규칙(C)·프로젝트 규칙(P)의 상세 경위 단일 SOT
-related: SKILL.md (활성 본문은 1줄 요약만 유지), CLAUDE.md (요약 블록)
-rationale: C14(토큰 최소화) + 헌법 제1원칙 목표 2 원칙 B(차기 프로젝트 참고 자료) 동시 만족
----
-
-# 🗄️ 폐기·개정 규칙 아카이브 (너드나비스)
-
-> **본 파일의 성격**: 폐기되었거나 정의가 대폭 개정되어 이전 형태가 소멸한 핵심 규칙(C)·프로젝트 규칙(P)의 **상세 경위·근거·대체 관계**를 단일 SOT로 집약한 조직 자산. 활성 본문(SKILL.md)에는 "1줄 선언 + 본 파일 링크"만 유지하여 고정비를 최소화하되 **조직 기억·감사 추적·역진화 방지·차기 프로젝트 참고 자료** 4중 가치를 보존한다.
->
-> **근거**: 2026-04-18 PD님 직접 지시로 "수정 3대 원칙 3번 — 폐기 선언 본문 유지"를 **"저장 위치 최적화"** 로 개정. 활성 본문 ≠ 자산 저장 위치. 자산 가치는 유지하되 저장은 외부화.
->
-> **읽기 규칙**: 본 파일은 **변동비**. 활성 본문에서 폐기 규칙 맥락이 필요할 때만 Read. SessionStart·매 턴 자동 로드 대상 아님.
-
----
-
-## 🏛️ 아카이브 원칙
-
-### 포함 대상
-1. **완전 폐기 규칙** — 선언이 `~~취소선~~` 처리되고 후속 대체 규칙이 지정된 것 (예: P20 → P24, C17 → 폐기)
-2. **정의 대폭 개정 규칙** — 번호는 유지되나 이전 정의가 소멸하고 신 정의로 교체된 것 (예: 구 C18·C24·C26)
-3. **상위 규칙 격상으로 실효된 규칙** — 프로젝트 규칙이 헌법급으로 격상되어 원 조항이 실질 공백화된 것 (검토 대기: P12 → C28)
-
-### 제외 대상
-1. 활성 규칙의 부속 조항 개정 (예: C20-1-A의 운영 조정) — 활성 본문 내 변경 이력으로 관리
-2. 오탈자·용어 통일·링크 수정 — 일반 문서 개정
-
-### 기록 형식 (각 규칙 필수 6필드)
-| 필드 | 설명 |
-|------|------|
-| **규칙 번호·명** | 원 번호와 명칭 |
-| **신설일** | 최초 도입 날짜 |
-| **폐기/개정일** | 소멸·개정 날짜 |
-| **상태** | 폐기 / 개정 / 격상 실효 |
-| **대체 관계** | 후속 규칙 번호·명 (있으면) |
-| **경위·근거** | 왜 폐기/개정되었는가, 어떤 사건·결정이 계기인가 |
-| **원 본문** (선택) | 원형 보존 필요 시 전문 인용. 없으면 "활성 본문에는 1줄 선언만" |
-
----
-
-## 1. P20 — 세션 활동 일일 보고
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | P20. 세션 활동 일일 보고 |
-| **신설일** | 2026-04-14 |
-| **폐기일** | 2026-04-16 |
-| **상태** | **폐기** |
-| **대체 관계** | **P24 (대화로그 기록 의무)** 가 역할 완전 대체 |
-| **경위·근거** | 2026-04-16 PD님 직접 지시. P24 대화로그가 일일보고 역할을 완전 대체하며, 양 체계 병존 시 기록 중복(C14-4 참조 무결성 위반) 발생. "활동 가시화"라는 목적은 P24 + P22(결정로그) + P19(PD 지시 트래킹) 3축으로 분담. 기존 `공유/일일보고/` 아카이브는 역사 기록으로 보존. |
-| **원 본문 요지** | 각 팀 세션 종료 시 `공유/일일보고/YYYY-MM-DD_{부서}.md` 작성·갱신 의무. 당일 첫 작성이면 신규, 이후 append. 포함: PD 지시 반영 결과 / 자율 작업 / 발견 이슈 / 다음 예정. |
-| **교훈** | 기록 체계는 "하나의 기록 = 하나의 목적" 원칙으로 SOT 경계 명확화. P20처럼 중복 체계는 조기 정리. |
-| **관련 이력** | `공유/일일보고/` 디렉토리 (역사 아카이브 보존) / P22·P24 신설 |
-
----
-
-## 2. C17 — 세션 이동 지시 시 복사 가능 명령어 동봉 의무
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C17. 세션 이동 지시 시 복사 가능 명령어 동봉 의무 |
-| **신설일** | 2026-04-15 |
-| **폐기일** | 2026-04-16 |
-| **상태** | **폐기** (상위 전제 소멸) |
-| **대체 관계** | 없음 (규칙 자체가 불필요해짐) |
-| **경위·근거** | 2026-04-16 PD님 직접 지시로 단일 세션 전환(C24 개정). 단일 세션 구조에서는 "세션 간 이동" 자체가 소멸하므로 C17의 전제가 성립하지 않음. PM이 부서별 별도 세션 진입을 위해 동봉하던 복사 명령어 블록은 불요. |
-| **원 본문 요지** | PM이 부서에 작업을 위임하거나 세션 이동을 지시할 때, 부서 세션에서 **바로 복사·실행 가능한 명령어 블록**을 응답에 동봉 의무화. C17-3·C17-3-α로 3요소·간결화 원칙이 보강되었으나 2026-04-16 단일 세션 전환으로 전체 실효. |
-| **교훈** | 운영 프로세스 규칙은 상위 구조(여기서는 세션 구조) 변경에 종속. 상위 변경 시 하위 규칙의 존속 가치 재검토 필수. |
-| **관련 이력** | C17-3 보강 (2026-04-15) / C17-3-α 신설 (2026-04-15) / C24 단일 세션 전환 (2026-04-16) / PD 지시 로그 #12·#17 |
-
----
-
-## 3. 구 C18 — 조직 공유 완료 판정 (대상 세션 도달 포함)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | 구 C18. 조직 공유 완료 판정 — main 병합 + 대상 세션 도달 |
-| **신설일** | 2026-04-15 |
-| **개정일** | 2026-04-16 |
-| **상태** | **정의 개정** (번호 유지, 정의 변경) |
-| **현행 C18** | main push 완료 (대상 세션 도달 개념 제거) |
-| **경위·근거** | 2026-04-15 OI-2 위임 사건(브랜치 분리로 인한 파일 미도달) 계기로 신설. 당시 구조는 부서별 별도 세션 운용이라 "main 병합 + 부서 세션이 해당 커밋을 pull 완료"까지를 공유 완료로 판정. 2026-04-16 단일 세션 전환으로 "대상 세션 도달" 개념이 소멸 → main push 완료만으로 공유 완료 판정하도록 개정. |
-| **구 정의 요지** | 로컬 커밋 → 원격 push → main 병합 → **부서 세션이 main pull 완료** 4단계가 모두 완료된 시점을 "조직 공유 완료"로 판정. |
-| **교훈** | 정의 개정은 "번호 유지 + 정의 변경" 형태로도 발생 가능. 구 정의가 적용되던 시점의 커밋·보고는 구 정의로 해석해야 역사적 정합성 유지. |
-| **관련 이력** | 신설 공지 `공유/조직공지/2026-04-15_C18_신설_C17_보강_브랜치동기화_정직성.md` / C24 단일 세션 전환 시 동반 개정 |
-
----
-
-## 4. 구 C24 — 부서 세션 영속 대화 운용
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | 구 C24. 부서 세션 영속 대화 운용 |
-| **신설일** | 2026-04-15 |
-| **개정일** | 2026-04-16 |
-| **상태** | **정의 개정** (번호 유지, 정의 변경) |
-| **현행 C24** | 단일 세션 운용 원칙 (PM이 총괄하는 단일 세션 1개, 부서는 Agent 도구로 호출) |
-| **경위·근거** | 2026-04-15 PC 독립·세션 시작 표준 논의 중 "부서별 워크트리 영속 대화"를 표준 운용 모델로 도입. 2026-04-16 PD님 직접 지시로 **단일 세션 + Agent 병렬 호출** 구조로 전환. 이유: (a) 부서 세션과 PM 세션 간 동기화 비용 (b) 각 부서 세션에 별도 메모리·권한 관리 부담 (c) Agent 도구 성숙으로 단일 세션에서 병렬 호출 가능. |
-| **구 정의 요지** | 부서(개발팀·기획팀)별 영속 대화 세션을 `개발팀/`·`기획팀/` 디렉토리 기준으로 유지. PM이 위임 시 부서 세션에서 `resume` 하여 맥락 계승. |
-| **교훈** | 조직 구조 근본 전환은 다수 하위 규칙(C17·C26·settings.json 배치 등)에 파급. 전환 시 파급 범위 전수 식별 필수. |
-| **관련 이력** | 2026-04-16 단일 세션 전환 / C16 PC 독립 셋업과 정합 / C26 Skill 패킹 전환 동반 |
-
----
-
-<a id="constitution-v1"></a>
-## 5-A. 헌법 제1원칙 v1 (3개 목표) — 2026-04-18 전면 재작성
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | 헌법 제1원칙 v1 — 너드나비스 조직 비전 (3개 목표) |
-| **신설일** | 2026-04-15 |
-| **재작성일** | 2026-04-18 |
-| **상태** | **전면 재작성** (v1 → v2, 3개 목표 → 5개 원칙) |
-| **대체 관계** | 헌법 제1원칙 v2 (5항 ①~⑤) — SKILL.md 상단 현행본 |
-| **경위·근거** | 2026-04-18 PD님 직접 지적 "헌법 제1원칙이 잘못 되었어". 구 3개 목표(코어 프레임워크 PC 독립·차기 프로젝트 활용·단기제작 스튜디오)는 헌법급 상위 원칙으로 부적합 판정. 일부는 프로젝트 규칙(P29 코어프레임워크)·참고 사항(조직 현황·핵심 자산 안내)으로 강등. |
-| **v1 원본 요지** (보존) | **목표 1** — 코어 프레임워크의 PC 독립 최신화 유지 (어떤 PC에서든 최신화된 조직 자산으로 코어 프레임워크 유지·관리) / **목표 2** — 차기 프로젝트부터 코어 코드 프레임워크 조직 자산으로 적극 활용 (원칙 A: 차기 프로젝트 활용·원칙 B: 현 프로젝트 인사이트 기록→차기 참고) / **목표 3** — 단기제작 가능한 유능한 게임 개발 스튜디오로의 발전 |
-| **대체 경로** | v1 목표 1 (PC 독립 유지): 기술 운영 사항으로, **헌법 외 명문화 "조직 현황·핵심 자산 안내" + P25 Live 동기화** 체계로 흡수. 헌법 원칙 아님. / v1 목표 2 (코어 프레임워크 활용): **P29 코어 코드 프레임워크 프로젝트 규칙** 3개 조항으로 강등 + 헌법 원칙 ② "경험 축적·계승·발전"에 포함 / v1 목표 3 (단기제작 스튜디오): 헌법 원칙 ① "AI 전문 개발 스튜디오" 내재화 |
-| **교훈** | 헌법급 상위 원칙은 **추상도 높은 조직 본질**에 한정. 구체 프로젝트(코어 프레임워크)·기술 체계(PC 독립)·미래 지향 목표(단기제작)는 프로젝트 규칙·참고 사항으로 분리 배치가 적정. PM은 v1 원안 작성 시 이 층위 구분 미숙. |
-| **관련 이력** | 2026-04-18 PD님 직접 재작성 지시 5항 + P24→C32·P27→C33 승격 + P29 신설 연쇄 개정 |
-
----
-
-<a id="c32-p24-승격"></a>
-## 6. P24 → C32 승격 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | P24 대화로그 기록 의무 → C32 (번호 승격) |
-| **신설일** | 2026-04-16 (P24로) |
-| **승격일** | 2026-04-18 (C32로) |
-| **상태** | **번호 승격** (프로젝트 규칙 → 핵심 규칙 헌법급) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시 "P24·P27도 코어룰로 승격 시켜." 대화로그가 조직 노하우 축적의 핵심 도구이며 기록 누락이 조직 자산 소실로 직결되어 헌법급 격상 타당. |
-| **본문 위치** | SKILL.md C32 섹션 (기존 P24 섹션 위치 그대로, 제목만 C32로 변경) |
-| **영향 범위** | 기존 P24 전 조항(기록 시점·형식·기각안 필수·읽기 의무 등)이 헌법급으로 상향. 위반 시 처분 강도 증가. |
-| **참조 갱신** | SKILL.md 내 "P24" 참조 일부는 "C32"로 점진 갱신. 과도기 "C32 (구 P24)" 병기 허용 |
-
----
-
-<a id="c33-p27-승격"></a>
-## 7. P27 → C33 승격 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | P27 조직 업무 공유·기록 체계 일관성 보장 → C33 (번호 승격) |
-| **신설일** | 2026-04-17 (P27로) |
-| **승격일** | 2026-04-18 (C33로) |
-| **상태** | **번호 승격** (프로젝트 규칙 → 핵심 규칙 헌법급) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. 3축 감사 체계·세션 전환 연속성 보장·기록 SOT 경계가 조직 생명급이며 위반 시 조직 운영 자체가 무력화됨으로 헌법급 격상 타당. |
-| **본문 위치** | SKILL.md C33 섹션 (기존 P27 섹션 위치 그대로, 제목만 C33로 변경) |
-| **영향 범위** | 3축 감사 체계(pm·dev·plan-auditor)·Agent 호출 이력·세션 전환 시나리오 A~D·SOT 경계·hook 체계 전 조항이 헌법급으로 상향 |
-| **참조 갱신** | SKILL.md 내 "P27" 참조 일부는 "C33"로 점진 갱신. 과도기 "C33 (구 P27)" 병기 허용 |
-
----
-
-## 12. P12·P15·P22·P26 본문 완전 삭제 + P13 통합 (2026-04-18 PD님 직접 지시)
-
-| 항목 | 내용 |
-|------|------|
-| **지시 내용** | "이미 삭제되어서 없어진 내용을 최신 문서에 담지 말고 아카이브만 하고 필요시 참조만 하면 돼" + "프로젝트 규칙에 중복 된 내용은 정리" |
-| **실행일** | 2026-04-18 |
-| **상태** | 본문 완전 삭제 + 아카이브 단독 보존 + 번호 구멍 허용 |
-
-### 12-A. P12 문서(.md) 수정 권한 — C28 격상으로 완전 흡수
-- **구 내용**: .md 파일 수정 권한 총괄PM·팀장 일임, PD님 개별 승인 불요
-- **흡수 대상**: C28 문서 수정 무승인 원칙 (2026-04-16 헌법급 격상 시 완전 흡수)
-- **조치**: P12 본문 완전 삭제. C28이 동일 의무 담당.
-
-### 12-B. P15 의존성·환경 변경 공유 — P13 통합
-- **구 내용**: 패키지·MCP·에디터 설정 변경 공유 채널 기록, 세션 재시작 사전 안내, 영향 범위·롤백 함께 기록
-- **통합 대상**: P13 "코드·의존성·환경 변경 관리"
-- **조치**: P13 본문을 P13-1 코드 변경 + P13-2 의존성·환경 변경(구 P15) 2단으로 재구성. 구 P15 본문 삭제.
-
-### 12-C. P22 결정로그 발행 의무 — C32 흡수
-- **구 내용**: 결정 발생 시 `공유/소통/{부서}→PM/`에 결정로그 발행. 배경·결정·영향 3요소. 3줄 이내.
-- **흡수 대상**: C32 대화로그 기록 의무 (결정·설계 엔트리 기각안 필수)
-- **조치**: C32 "통합 안내" 조항으로 흡수 규정 명시. 결정로그 파일 별도 발행은 선택 사항, 대화로그 엔트리만으로 요건 충족.
-
-### 12-D. P26 PM 업무 정확도 보장 체계 — C33 흡수
-- **구 내용**: PM 재량 자율 처리, 업무 현황 최신 파악 의무, pm-auditor 활용 의무, 위반 처분 4종
-- **흡수 대상**: C33-1 3축 감사 체계(pm·dev·plan-auditor) 내 PM 영역
-- **조치**: C33 "통합 안내" 조항으로 PM 세부 운영 규정 흡수 명시.
-
-### 12-E. 번호 구멍 허용 원칙 (C14-5-확장 명문화)
-- **P12·P15·P20·P22·P24·P26·P27** 자리는 **번호 구멍**으로 유지 (폐기 표기조차 본문에 남기지 않음)
-- **근거**: C14-5-확장 (2026-04-18 신설) — 폐기·통합·강등 조항 본문 완전 삭제 원칙
-- **재발 방지**: PM 과도 보수 해석 5회차 변종 재발 방지 (`memory/org/feedback_pm_over_conservative_interpretation.md` 5회차 기록)
-
----
-
-<a id="8-c7-demotion"></a>
-## 8. C7 → P30 강등 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C7 재미 우선 원칙 → P30 (번호 강등 + 범위 재정의) |
-| **신설일** | 구 C7 신설 시점 (조직 초기) |
-| **강등일** | 2026-04-18 |
-| **상태** | **번호 강등** (핵심 규칙 → 프로젝트 규칙) + 범위 재정의 |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. "C7은 모든 에이전트가 지켜야할 원칙이 아니라 기획팀의 기본 원칙으로 명문화. 앞으로 신규 게임 개발 프로젝트에 기획팀이 지켜야할 룰이지 모든 팀원의 원칙은 아니라는 점을 혼선이 없도록 정리." |
-| **본문 위치** | SKILL.md P30 섹션 (신설, 기획팀 전용 + 타 팀과의 경계 + 적용 프로젝트) |
-| **타 팀과의 관계** | 개발팀 C11(자원·구조·범용성) / PM·감사관 프로세스 준수. P30 직접 대상 아님. P30-C11 충돌 시 PM·PD님 조율 |
-
----
-
-<a id="9-c8-merge"></a>
-## 9. C8 → C6 통합 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C8 프로덕션 보호 → C6 데이터 보호 및 프로덕션 보호 (통합) |
-| **신설일** | 구 C8 신설 시점 |
-| **통합일** | 2026-04-18 |
-| **상태** | **통합** (C8 폐기, C6에 흡수) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. "C8은 C6과 병합시키고, PD의 승인이 있다면 복구 가능성이 없어도 진행 가능하도록 변경. 단 복구 가능성이 없는 작업 수행 시 복구 불가능하다는 사실을 반드시 고지해야하는 보고 의무 신설." |
-| **본문 위치** | SKILL.md C6 섹션 확장 (C6-1 원본 보호 + C6-2 프로덕션 보호 + C6-3 복구 불가 작업 PD 승인 + 고지 의무) |
-| **신규 조항** | **C6-3 복구 불가 작업 고지 의무** (2026-04-18 신설) — PD님 승인 시 복구 불가 작업 진행 가능하되 복구 불가 이유·범위·부작용·사전 승인·사후 보고 4요소 고지 의무 |
-
----
-
-<a id="10-c15-merge"></a>
-## 10. C15 → C9 통합 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C15 일정·기한 개념 배제 → C9 AI 에이전트 조직 원칙 (통합) |
-| **신설일** | 2026-04-15 (C15) |
-| **통합일** | 2026-04-18 |
-| **상태** | **통합** (C15 폐기, C9에 흡수) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. "C9와 C15는 중복되는 내용 같아. 우리 조직의 기본 원칙으로써 모든 에이전트가 따를 수 있다는 점을 고려해 합쳐진 하나의 룰로 만들어." |
-| **본문 위치** | SKILL.md C9 섹션 확장 (C9-1 기본 태도 + C9-2 일정·기한 표현 금지 + C9-3 예외 + C9-4 인간 일정 조율 이관) |
-| **중복 제거** | 구 C9("MVP·일정·공수 기본 고려 안 함")와 구 C15("시간 단위 계획 금지")가 사실상 동일 원칙(완성도 우선·일정 개념 배제)이라 통합이 자연스러움 |
-
----
-
-<a id="11-c12-demotion"></a>
-## 11. C12 → P31 강등 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C12 PD님 경어 사용 원칙 → P31 (번호 강등) |
-| **신설일** | 구 C12 신설 시점 (조직 초기) |
-| **강등일** | 2026-04-18 |
-| **상태** | **번호 강등** (핵심 규칙 → 프로젝트 규칙) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. "C12는 프로젝트 규칙으로 전환시켜." 조직 운영 규약 성격으로 헌법급 불필요 판정. |
-| **본문 위치** | SKILL.md P31 섹션 (신설, 기존 C12 본문 그대로 이전) |
-| **본문 변경** | 없음 (강등은 번호만, 규칙 강도는 유지) |
-
----
-
-## C17 신규 재활용 — 최신 세션 관리 기준 (2026-04-18 PD님 직접 지시)
-
-> **주의**: 구 C17("세션 이동 복사 명령어 동봉 의무", 2026-04-16 폐기)은 위 §2에 기록. 본 섹션은 2026-04-18 **동일 번호를 재활용하여 신설**한 "최신 세션 관리 기준"에 대한 기록.
-
-| 항목 | 내용 |
-|------|------|
-| **번호 재활용 사유** | 2026-04-18 PD님 직접 지시 "C17은 삭제하고, 최신 세션 관리 기준을 명시해. (과거 이력은 아카이브화 시킬 사항이야.)" 구 폐기 C17 자리를 재활용하여 신규 규칙 배치. |
-| **신규 C17 내용** | 세션 구조(단일 세션 + Agent 병렬 호출)·세션 시작 표준 절차·전환 시나리오 4종·내부 공유 vs 공유 완료 구분·연관 규칙 인덱스 |
-| **구 C17과의 관계** | 동일 번호 재활용. 구 C17의 "세션 이동 복사 명령어 동봉" 주제는 단일 세션 전환으로 소멸. 신규 C17은 "최신 세션 관리 기준" 통합 인덱스로 재정의 |
-
----
-
-## C21 정식 확정 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C21 작업 완료 즉시 공유·PM 능동 확인 |
-| **초안 상태** | 2026-04-15 무렵 "(초안)"으로 참조만 존재, 본문 없음 |
-| **확정일** | 2026-04-18 |
-| **상태** | **정식 확정** (초안 해제) |
-| **경위·근거** | 2026-04-18 PD님 직접 지시. "C21은 작업 완료 즉시 공유하고 PM이 능동 확인해야 하는 룰은 매우 중요한 룰이야. '작업 완료 즉시 공유'가 C18로 인해 반드시 푸시를 해야만 완료라고 인지할 수 있기 때문에 혼선을 없애도록 2단계 정의를 명문화." |
-| **본문 구조** | C21-① 내부 공유 상태(임시 파일·로그로 세션 갱신 전 확인 가능) + C21-② 공유 완료 상태(C18 main push 완료·모든 PC 동기화) + C21-③ PM 능동 확인 의무 + C21-④ 2단계 전이 시점 + C21-⑤ 연관 규칙 |
-| **핵심 가치** | "내부 공유 상태" vs "공유 완료 상태" 명확 구분으로 C18과의 혼선 해소 |
-
----
-
-## 5. 구 C26 — 코어룰 변경 시 에이전트 정의 파일 동시 갱신 의무
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | 구 C26. 코어룰 변경 시 에이전트 정의 파일 동시 갱신 의무 |
-| **신설일** | 2026-04-16 (1차) |
-| **개정일** | 2026-04-16 (2차, 같은 날 재개정) |
-| **상태** | **정의 개정** (Skill 패킹 전환으로 수동 갱신 의무 폐지) |
-| **현행 C26** | 코어룰 단일 SOT 갱신 원칙 — SKILL.md 한 곳만 갱신하면 Skill 메커니즘이 부서 서브에이전트에 자동 주입 |
-| **경위·근거** | 1차 신설 당시는 코어룰을 루트 CLAUDE.md·개발팀장.md·기획팀장.md 다중 복사 보관 구조. 규칙 변경 시 3~4곳 동시 갱신 의무 규정. 2026-04-16 Claude Code `skills:` frontmatter 기능 도입으로 **Skill 패킹 단일 SOT 전환**. SKILL.md 한 곳만 수정하면 모든 부서 에이전트에 자동 주입되므로 수동 동시 갱신 의무 폐지. |
-| **구 정의 요지** | C·P 규칙 신설·변경 시 다음 4곳을 동일 커밋 내 갱신 의무: (1) 루트 CLAUDE.md 요약 (2) 개발팀/CLAUDE.md 본문 (3) 기획팀/CLAUDE.md 본문 (4) 에이전트 정의 `.md` 관련 조문. 누락 시 C26 위반 + C5 정직성 위반 가중. |
-| **교훈** | 플랫폼 기능 진화(Skill 패킹)에 따라 조직 규칙도 적극 간소화. 수동 동기화 의무는 자동화 가능 영역에서는 즉시 폐지 검토 대상. |
-| **관련 이력** | 2026-04-16 Skill 패킹 전환 공지 / C14-4 참조 무결성과 정합 / `memory/org/feedback_role_play_vs_real_call.md` |
-
----
-
-## 14. C34 확장 — memory junction 중앙화 편입 (2026-04-19)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | C34 "Live 증분 동기화 체계" → **"PC 로컬 실시간 공유 중앙화 체계 — Live + memory"** (제목 개정 + 본문 확장) |
-| **이전 개정일** | 2026-04-18 (P25 → C34 헌법급 승격) |
-| **이번 확장일** | 2026-04-19 |
-| **상태** | **본문 확장** (C34 번호 유지, 적용 대상에 `memory/org/` 추가) |
-| **대체 관계** | 구 "Live 단일 대상" 개념은 "Live + memory 2종 병립" 구조로 포섭됨. `feedback_worktree_isolation.md`의 "자산 적용 대상 표"에서 memory/org/ 상태 🟡 → ✅ 갱신 |
-| **경위·근거** | 2026-04-18 C34 집행 세션에서 memory junction 경계 이슈 **3회 실증**(feedback 파일·MEMORY.md 인덱스·stash 이관 반복)했음에도 PM이 "운영 규율·감사관 체크로 커버" 완화 판정 + PD님이 직접 물어보실 때까지 침묵. 2026-04-19 PD님 직접 지적 **"이슈를 왜 내가 물어보기 전까지 대답하지 않았지? 근본 해결이 아닌 임시 방편은 코어 룰 위반이야. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어."** → PM 자진 반성(C2·C3·C5·C29 위반 자인) + 옵션 A 집행 지시 |
-| **영향 범위 (10종)** | (1) SKILL.md C34 제목 개정 + C34-1/3/14/**C34-16 신설** (2) 스크립트 5종 신규 (`memory_junction_ensure`·`sync_memory_repo_to_central`·`sync_memory_central_to_repo`·`sync_memory`·`rollback_memory_central`) (3) setup_windows.ps1·setup_macos.sh 3.6 섹션 추가 (4) verify_setup.ps1 2.6 섹션 3축 검증 (5) settings.json SessionStart hook 체인 + post-commit hook 확장 (6) 조직공지 `2026-04-19_C34_확장_memory_junction_중앙화.md` (7) memory feedback 2종 신설(`feedback_issue_under_reporting`·`feedback_memory_junction_repo_root_misdirect`) + MEMORY.md 인덱스 (8) 감사관 3종 체크 확장("C34/C16-1 동급 생존성 이슈 축소 보고 감지") (9) CLAUDE.md C34 요약 갱신 (10) 대화로그 2026-04-19 |
-| **C34-16 신설 (memory junction 특수 조항)** | (1) 레포 `memory/org/` 실체 디렉토리 유지 의무 (git-tracked SOT) (2) sync 방향 규약 (레포 SOT 기본) (3) Write 경로 선택 의무 (본 worktree 절대 경로 vs user memory 경로, 혼용 금지) (4) 3층 백업 의무 (5) 정(正) 판정 규칙 A·B·C |
-| **교훈** | **"C34와 동급 패턴 이슈는 C34 패턴 그대로 적용 가능**. git 추적 SOT라는 복잡도 때문에 "symlink 불가 → 운영 규율로" 결론은 잘못된 이분법. sync 스크립트 + junction 투명 경유 조합으로 양립 가능. **"커버 가능"은 "근원 해결"의 반의어 — 매 세션 수동 개입 반복 구조는 C2 위반**. PM 과도 보수 해석 4회차 변종 재발. |
-| **관련 이력** | 2026-04-18 C34 신설(§13) → 2026-04-19 확장(본 §14) |
-
----
-
-## 13. P25 → C34 승격 + worktree 격리 근원 해결 (2026-04-18)
-
-| 항목 | 내용 |
-|------|------|
-| **규칙 번호·명** | P25 Live 증분 동기화 체계 → **C34 Live 증분 동기화 체계** (헌법급 승격 + 본문 전면 재작성) |
-| **신설일** | 2026-04-16 (P25로) |
-| **승격·재작성일** | 2026-04-18 (C34로) |
-| **상태** | **번호 승격 + 본문 전면 재작성** (프로젝트 규칙 → 핵심 규칙 헌법급) |
-| **대체 관계** | 구 P25 본문은 C34로 흡수되며, worktree 경계 해소·Agent 경계 보호·중앙 Junction 구조가 신규 편입됨 |
-| **경위·근거** | 2026-04-18 PD님 직접 선언 — **"이 문제가 해결되지 않으면 앞으로 우리 조직은 유지될 수 없어"** · **"철저히 검토해서 관련 된 문서에 일괄 반영하고 재발되지 않도록 가능한 모든 수단을 써서 개선해"**. git worktree 격리로 P25의 "같은 PC 세션 간 실시간 공유"가 실패하는 사실이 실증됨. 헌법 제1원칙 ⑤(세션·PC 연속성 보장)의 근본 위협 판정. |
-| **영향 범위** | (1) SKILL.md C34 신설 + P25 본문 완전 삭제, C16-1 junction 의무 편입, C31-1-E 표기 갱신 (2) CLAUDE.md 핵심 규칙 요약 28→29, 프로젝트 규칙 요약 25→24 (3) 스크립트: `scripts/live_junction_ensure.sh` 신규 + `setup_*.ps1/sh` 3.5 섹션 + `verify_setup.ps1` 2.5 섹션 (4) `.claude/settings.json` SessionStart hook 체인 갱신 (5) `.gitignore` `.live/*` 제외 규칙 (6) 조직공지 `2026-04-18_C34_신설_worktree_격리_근원해결.md` 발행 (7) memory/org/ 2종 신설 |
-| **구 P25 본문 요지** (보존) | Live 더미 + `sync_signal.sh` 시그널 체계로 같은 PC 세션 간 네트워크 비용 0 실시간 공유. 단, "같은 worktree" 전제가 암묵적이었으며 worktree 격리에서 실패함이 실증됨. |
-| **교훈** | (1) **"같은 PC = 같은 파일시스템"이라는 직관은 worktree 앞에서 성립하지 않음** — 조직 공유 체계 설계 시 worktree 경계 조건을 첫 검토 항목에 포함 (2) Agent 호출 시 절대 경로 하드코딩은 worktree 경계를 넘어 다른 디렉토리에 쓰이는 2차 위험 — C34-11·`feedback_agent_path_boundary.md` 참조 (3) 기존 C16-1 memory junction 패턴이 본 해결의 모범 사례 (중앙 저장소 + junction). 새 공유 체계 설계 시 동일 패턴 우선 채택 |
-| **번호 구멍** | P25는 본문 완전 삭제 (C14-5-확장 규준). CLAUDE.md 프로젝트 규칙 요약에서도 완전 제거. 번호 연속성 자산 아님. |
-
----
-
-## 📘 운영 규칙 (본 파일 관리)
-
-### 추가 시점
-1. 신규 규칙 폐기·개정 확정 시 **해당 커밋과 동일 커밋 내**에 본 파일 append
-2. 활성 본문(SKILL.md) 1줄 선언에 본 파일 링크 반드시 포함 (`[아카이브](공유/조직공지/폐기_규칙_아카이브.md#규칙번호)`)
-3. 추가 시 대화로그(`공유/대화로그/조직운영/YYYY-MM-DD.md`) 엔트리 + 기각안 기록 (P24)
-
-### 본 파일 변경 이력 (P16)
-| 일시 | 변경자 | 변경 요지 | 관련 PD 지시 |
-|------|--------|-----------|-------------|
-| 2026-04-18 | PM | 신설 + P20·C17·구 C18·구 C24·구 C26 5종 이관. 수정 3대 원칙 3번 개정(저장 위치 최적화) PD님 직접 지시 반영 | 2026-04-18 원칙 3 개정 + A+B급 6건 집행 착수 지시 |
-| 2026-04-18 | PM | §13 P25 → C34 승격 기록 추가. worktree 격리 근원 해결 집행 (중앙 Junction + Agent 경계 보호) | 2026-04-18 PD님 조직 생존급 선언 "가능한 모든 수단을 써서 개선해" |
-| 2026-04-19 | PM | §14 C34 확장 — memory junction 편입 (HOME 중앙화, C34-16 신설). PD님 직접 지적 "근본 해결이 아닌 임시 방편은 코어 룰 위반. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어" 수용. PM 이슈 축소 보고 자진 반성(feedback_issue_under_reporting.md) 포함 | 2026-04-19 PD님 옵션 A 집행 지시 |
-
-### 역진화 방지 (본 파일 자체의 보호)
-본 아카이브 파일 자체가 소실·삭제되면 조직 기억이 일괄 소실됨. 따라서:
-- 본 파일 삭제·이동은 **PD님 직접 승인 필수** (C19-2 되돌리기 어려운 액션)
-- 본 파일 내용 축약·요약은 **PM 재량 아님, PD님 결정 안건**
-- git 추적 대상으로 영구 보존
diff --git a/공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md b/공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md
index 2d0049a..e087ba2 100644
--- a/공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md
+++ b/공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md
@@ -7,16 +7,15 @@
 
 ---
 
-## 1. 개요 — 핵심 교훈 8건
+## 1. 개요 — 핵심 교훈 7건
 
 1. **Unity MCP 편집 = 6단계 표준 불가침**: `apply_text_edits`/`script_apply_edits`는 Read-then-Edit 관성 미발생. SHA→Read→백업→commit→편집→검증
 2. **Unity 프로젝트는 외부 git 레포**: 조직 레포와 분리. 작업 전 `git fetch && git status` 선행(C30)
-3. **시뮬레이션은 MCP EditMode가 정답**: Actor.cs 4,545줄 Headless 추출(07안)을 `execute_code` + EditMode로 대체, 이원화 근본 해소
-4. **핫리로드는 hook 기반 `.live/` 증분 주입**: `@import`·`/compact`·`.claude/rules/`는 세션 중 갱신 불가. UserPromptSubmit hook + SHA1 diff만 유효
-5. **CLI 병렬은 `--worktree` 격리**: 같은 디렉토리 다중 세션은 덮어쓰기 위험. 연속 작업은 워크트리 강제
-6. **기획팀 협업 = 실측 교차 검증**: 문서-실체 괴리(GameManager.cs 부재·Spine 추가·Res_Addr 확장·xlsm SOT 이중화)는 정기 실측만 감지
-7. **Tool 버그 점검은 "점검만" 집행 분리**: 3축 증거 기반 판정. 수정안은 옵션 분리(PD 결정 영역)
-8. **BT.Framework Tier 1 16/16은 차기부터 적용**: 수상한잡화점 미도입 확정(P29 원칙 A). 범용 패턴 추출만 수행
+3. **시뮬레이션 = MCP EditMode가 정답**: Headless 도메인 추출은 재빌드·이원화 부담. `execute_code` + EditMode로 Actor.cs 실클래스 직접 호출이 단일 SOT
+4. **핫리로드 = hook 기반 `.live/` 증분 주입**: `@import`·`/compact`·`.claude/rules/`는 세션 중 갱신 불가. UserPromptSubmit hook + SHA1 diff만 유효
+5. **CLI 병렬은 `--worktree` 격리**: 동시 수정 가능성 있으면 워크트리 강제. 같은 디렉토리 다중 세션은 덮어쓰기·git 이력 혼란
+6. **기획팀 협업 = 정기 실측 교차 검증**: 문서-실체 괴리(부재 스크립트·Spine 추가·Res_Addr 확장·xlsm SOT 이중화)는 정기 실측만 감지
+7. **BT.Framework Tier 1 16/16은 차기부터 적용**: 수상한잡화점 미도입 확정(P29 원칙 A). 범용 패턴 추출만 수행
 
 ---
 
@@ -26,56 +25,67 @@
 
 | 시도 | 이유 | 결과 | 교훈 |
 |------|------|------|------|
-| #57 A 실측 후 `script_apply_edits` 직접 치환 | PM 프롬프트 "C6-1 백업"은 있었으나 MCP 구체 수단(`manage_script read`→저장) 미명시 | 편집·검증 정상이나 `.bak_*` 분리 누락 → C6-1 위반. 복구 3중(보고서·역방향·undo) 실질 손실 0 | MCP 원자 편집은 Read-then-Edit 관성 미발생. 절차 명문화 불가침 |
-| C31-B 본문 수정 직접 집행 검토 | Unity MCP 1회성 원본 변형 대응 | 팀장 재량 밖(C36-2 방향·원칙, PD 선행) → C31-G(feedback 선행 Read)로 흡수 | 방향·원칙 변경은 팀장 재량 금지 |
-| 백업 경로 `공유/개발팀_백업/{프로젝트}/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` | PC 독립·git 추적·포맷 통일 | 단일 SOT. 긴급 시 `git stash push -u` | 조직 레포 내 고정. 절대 경로·Unix timestamp 금지 |
+| `script_apply_edits` 직접 치환 | PM 프롬프트 "C6-1 백업"은 있었으나 MCP 구체 수단(`manage_script read`→저장) 미명시 | 편집·검증 정상이나 `.bak_*` 분리 누락 → C6-1 위반. 3중 복구(보고서·역방향·undo) 실질 손실 0 | MCP 원자 편집은 Read-then-Edit 관성 미발생. 절차 명문화 불가침 |
+| 백업 경로 표준화 | PC 독립·git 추적·포맷 통일 | `공유/개발팀_백업/{프로젝트}/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 단일 SOT. 긴급 시 `git stash push -u` | 조직 레포 내 고정. 절대 경로·Unix timestamp 금지 |
 
-### 2-2. 시뮬레이션 방향 전환 (07 Python 추출 → 11 Unity MCP EditMode)
+### 2-2. 시뮬레이션 — MCP EditMode 단일 SOT 확정
 
 | 시도 | 이유 | 결과 | 교훈 |
 |------|------|------|------|
-| 07안: BattleCore 도메인 추출 + netstandard2.1 + dotnet CLI | Python-Unity 결과 불일치 해소 + 엔진 완전 분리 | Actor.cs 4,545줄 리팩터링·재빌드 동기화 부담 | 추출 자체가 근본 아님. 두 구현 유지비 0이 정답 |
-| 11 신안: `execute_code`(EditMode) 주력 + Batch Mode 보조 | Editor 내 C# Eval → Actor.cs 실클래스 호출. stub 7종(`IRandomSource`·`IClock`·`ITickDriver`·`IBattlePresenter`·`ITableLoader` 등) DI | 08/09/10 SOT 100%·07 60% 재활용. "단일 SOT = Unity 프로젝트 자체" | Unity 전제면 EditMode가 결정론·유지비·접근성 3축 우위 |
-| Python vs Unity MCP 5건 교차 검증 후 아카이브 | Phase 3 HOLD 해제 요건 | 비트 단위 일치 확증 후 HOLD 해제 | 방향 전환 시 병행 검증 필수. 즉시 전환 금지 |
+| 도메인 Headless 추출(netstandard) | Python-Unity 결과 불일치 해소 + 엔진 완전 분리 | 대형 스크립트 리팩터링·재빌드 동기화 부담 급증 | 추출 자체가 근본 아님. 두 구현 유지비 0이 정답 |
+| `execute_code`(EditMode) 주력 + Batch Mode 보조 | Editor 내 C# Eval → 실클래스 직접 호출. `IRandomSource`·`IClock`·`ITickDriver`·`IBattlePresenter`·`ITableLoader` 등 stub DI | 기존 시뮬 SOT 100% 재활용. "단일 SOT = Unity 프로젝트 자체" | Unity 전제면 EditMode가 결정론·유지비·접근성 3축 우위 |
 
-### 2-3. 핫리로드 대안 → `.live/` 증분 주입 (C34 승격)
+### 2-3. 핫리로드 대안 → `.live/` 증분 주입 (C34 헌법급 승격)
 
 | 시도 | 이유 | 결과 | 교훈 |
 |------|------|------|------|
-| PD 원안 CLAUDE_LIVE.md 공용 파일 | 세션 중 갱신·참조 | `@import`·`.claude/rules/`는 세션 시작 1회(A 불가). SessionStart hook은 재시작 시만(C 부분). UserPromptSubmit hook + SHA1 diff만 유효(B) | CLAUDE.md 재읽기는 세션 시작/`/compact`/서브디렉토리 접근 시만. 동적 갱신은 hook 외 불가 |
-| B+C 혼합: SessionStart 전량 + UserPromptSubmit 변경 감지 | 토큰 최소 + 매 턴 반영 양립 | 변경 없는 턴 0, 변경 시 ~1,200 토큰. 9,500자 이내(10,000자 한도) | C14 실증. 해시 비교가 핵심 |
-| `.live/` 증분 주입 → C34 헌법급 | worktree 격리로 주입 실패 실증 → 중앙 Junction | 조직 핵심 자산. 설정·규칙·에이전트 9종 대상. PC 내 모든 세션 공유 비용 0 | worktree 경계 끊김은 생존 이슈. 근본 해결(중앙 저장소 + junction) 필수 |
+| CLAUDE_LIVE.md 공용 파일 | 세션 중 갱신·참조 | `@import`·`.claude/rules/`는 세션 시작 1회. SessionStart hook은 재시작 시만. UserPromptSubmit hook + SHA1 diff만 유효 | 동적 갱신은 hook 외 불가 |
+| SessionStart 전량 + UserPromptSubmit 변경 감지 | 토큰 최소 + 매 턴 반영 양립 | 변경 없는 턴 0, 변경 시 ~1,200 토큰. 한도 이내 | C14 실증. 해시 비교가 핵심 |
+| `.live/` 증분 주입 → C34 중앙 Junction | worktree 격리로 주입 실패 실증 | 조직 핵심 자산. 설정·규칙·에이전트 9종 대상. PC 내 모든 세션 공유 비용 0 | worktree 경계 끊김은 생존 이슈. 중앙 저장소 + junction 필수 |
 
-### 2-4. 콘솔 병렬·하이브리드 구조
+### 2-4. 콘솔 병렬 · PM 보고 구조
 
 | 시도 | 이유 | 결과 | 교훈 |
 |------|------|------|------|
-| CLI 방법 A(같은 디렉토리) | 간단·독립 세션·독립 MCP | 같은 파일 동시 수정 시 덮어쓰기·git 이력 혼란 | 작업 영역 분리 원칙. 세션별 수정 디렉토리 명시 |
-| CLI 방법 B(`--worktree`) | 독립 파일시스템 복사본 + 독립 브랜치 | 충돌 없음. 완료 후 main merge | 동시 수정 가능성 있으면 워크트리 강제 |
-| PM에 모든 작업 보고 | C13 완전 준수 | 토큰 폭증·C14 위반·PM 세션 오염 | 이벤트 드리븐. 상태 전환·타 부서 영향·헌법급만 push |
-| PM 허브 Agent 호출로 부서 전담 | 단일 세션 단순화 | 컨텍스트 단절 — 영속 대화 컨텍스트 무지 | 연속 작업은 PD님 부서 직접 진입. Agent는 조회·단건 한정 |
+| CLI `--worktree` 격리 | 독립 파일시스템 + 독립 브랜치 | 충돌 없음. 완료 후 main merge | 동시 수정 가능성 있으면 워크트리 강제 |
+| PM에 모든 작업 push 보고 | C13 완전 준수 | 토큰 폭증·C14 위반·PM 세션 오염 | 이벤트 드리븐. 상태 전환·타 부서 영향·헌법급만 push |
 
-### 2-5. Tool_Left 점검·기획팀 협업·BT.Framework
+### 2-5. Editor 의존 분리 · 모바일 UI 패턴 · 기획팀 협업 · BT.Framework
 
 | 시도 | 이유 | 결과 | 교훈 |
 |------|------|------|------|
-| Tool_Left #58 3축 점검(호출 경로·직렬화·스키마) | "버그 유무 판정"만 지시 범위 | 3축 정상. 125 스테이지 중 122건(97.6%) 빈 배열은 2026-04-08 스키마 변경 시 수동 복구 미실행 잔재. #57 A 런타임 자동 복구로 해소 | 점검은 점검만. 수정안은 옵션 분리 |
-| 기획팀 유니티 교차 검증 | 문서 vs 실체 유효성 | 유효 8·변경 4·확인불가 3. `GameManager.cs` 부재·Spine 추가·Res_Addr 11개·`_Ino.xlsm` 오늘 수정 | 정기 실측 필수 |
-| BT.Framework Tier 1 16/16 완결 | 차기 조직 자산 | Log·ServiceLocator·CoroutineRunner·MonoSingleton·EventBus·Observable{List,Dict,Queue}·ObjectPool·Factory·DataTable·Attribute3·Util6 + NUnit 28+ | Tier 1은 게임 없이 완결. 2/3은 게임 진행과 축적 |
+| Editor 의존 분리 원칙 | 런타임 코드에 `UnityEditor` 네임스페이스 혼입 시 빌드 실패 | `#if UNITY_EDITOR` 가드 + Editor 폴더 분리 | 모든 재사용 모듈은 Editor 무관 전제. Framework 이식 시 필수 |
+| UITouchHandler·SafeArea·BackKey 패턴 | 모바일 UI 공통 요구 | 터치 이벤트 래핑·노치 대응·안드로이드 백키 통합 처리 3종 범용 패턴 추출 | 차기 프로젝트 Tier 2·3 후보. Framework 편입 검토 |
+| 기획팀 유니티 교차 검증 | 문서 vs 실체 유효성 | 정기 실측으로 부재 스크립트·Spine 추가·Res_Addr 확장·xlsm SOT 이중화 감지 | 정기 실측 필수 |
+| BT.Framework Tier 1 16/16 완결 | 차기 조직 자산 | Log·ServiceLocator·CoroutineRunner·MonoSingleton·EventBus·Observable{List,Dict,Queue}·ObjectPool·Factory·DataTable·Attribute3·Util6 + NUnit 28+ | Tier 1은 게임 없이 완결. 2·3은 게임 진행과 축적 |
 | 수상한잡화점 Framework 도입 | 자체 코어 사용 중 | P29 원칙 A — 미도입. 범용 패턴 추출만 | 신 프레임워크는 차기 출발 시점이 최적 |
-| 싱글톤 4종 → `MonoSingleton<T>` + 옵션 | 재작성 기회 중복 해소 | `WaitCahe→WaitCache` 수정. `DG.*`→`BurningTimes.*` | 재작성은 오탈자·중복 통합 기회 |
+| 싱글톤 4종 → `MonoSingleton<T>` + 옵션 | 재작성 기회 중복 해소 | 오탈자 수정(`WaitCahe→WaitCache`) · 네임스페이스 통일(`BurningTimes.*`) | 재작성은 오탈자·중복 통합 기회 |
 
 ---
 
-## 3. BT 착수 시 체크리스트 (EerieVillage·Unity 6000.3.13f1)
+## 3. BT 착수 시 체크리스트 (EerieVillage · Unity 6000.3.13f1 LTS · 2D PlatformerMicrogame)
 
 **Unity 작업 전 필수**: `${UNITY_PROJECT_ROOT}` `git fetch && git status` (C30) · `paths.local.json` 경로 등록 · MCP Stdio(6400) 연결 · 표준 워크플로우 6단계 준수
 
-**Unity MCP 편집 6단계(불가침)**: (1) `get_sha` → (2) `manage_script(read)` → (3) `공유/개발팀_백업/EerieVillage/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 저장 → (4) 백업 commit(긴급 시 `git stash push -u`) → (5) `apply_text_edits`/`script_apply_edits`(`precondition_sha_256` 지정) → (6) SHA 재확인 + `refresh_unity` + `read_console` error 0
+**Unity MCP 편집 6단계(불가침)**:
+1. `get_sha` — 편집 전 SHA 확보
+2. `manage_script(read)` — 원본 내용 Read
+3. `공유/개발팀_백업/EerieVillage/{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 저장
+4. 백업 commit (긴급 시 `git stash push -u`)
+5. `apply_text_edits`/`script_apply_edits` (`precondition_sha_256` 지정)
+6. SHA 재확인 + `refresh_unity` + `read_console` error 0
 
-**BT.Framework 도입 배선**: `manifest.json`에 `"com.nerdnavis.framework": "<Gitea URL>#<tag>"`(C안) · Framework 동시 개발자는 로컬 `file:../BT.Framework`(H1) · 2D PlatformerMicrogame 템플릿 샘플은 `EerieVillage/Samples/` 격리 · EventBus·ObservableList·DataTable·ServiceLocator 4종 출발점 배선(§04)
+**BT.Framework 도입 배선**:
+- `manifest.json`에 `"com.nerdnavis.framework": "<Gitea URL>#<tag>"` (C안)
+- Framework 동시 개발자는 로컬 `file:../BT.Framework` (H1)
+- 2D PlatformerMicrogame 템플릿 샘플은 `EerieVillage/Samples/` 격리
+- EventBus·ObservableList·DataTable·ServiceLocator 4종 출발점 배선
 
-**시뮬레이션**: `execute_code`(EditMode) 주력·07 Python 추출안 재도입 금지 · `IRandomSource`·`IClock`·`ITickDriver` DI · 동일 시드 비트 단위 동일 결과 검증
+**Editor 의존 분리**: 런타임 어셈블리에 `UnityEditor` 직접 참조 금지 · `#if UNITY_EDITOR` 가드 또는 Editor 폴더 분리 · Framework 전 모듈 Editor 무관 전제
+
+**모바일 UI 기반 패턴**: UITouchHandler(터치 래핑) · SafeArea(노치 대응) · BackKey(안드로이드 백키 통합) 3종 Tier 2·3 편입 검토
+
+**시뮬레이션**: `execute_code`(EditMode) 주력 · Headless 추출안 재도입 금지 · `IRandomSource`·`IClock`·`ITickDriver` DI · 동일 시드 비트 단위 동일 결과 검증
 
 **기획팀 협업 주기 실측**: 산출물 참조 경로·파일 실존·최근 수정일 · xlsm SOT 단일화(이중화 시 즉시 문의) · 스크립트·씬·Res_Addr 변동 감지
 
@@ -83,11 +93,10 @@
 
 ## 4. PM 보고 안건
 
-- **C31-B 본문 확장 안건 (PD 승인 대기)**: Unity MCP 1회성 원본 변형 집행을 자기검증 명시 대상 추가. C36-2 (a) 해당·팀장 재량 금지. 현 C31-G로 커버. PM 상정 후 PD 승인 시 C36-3로 반영
-- **표준 워크플로우 확장 검토(차후)**: filesystem·sqlite MCP·외부 레포 직접 편집 적용 여부. 현 시점 Unity MCP 전용 유지. 실증 누적 후 v2·v3 판단
 - **BT.Framework 차기 도입 경로**: C안(UPM Git URL) + H1(로컬 file:) 배선 확정. Gitea 태그 정책·PD NAS Git 접근 방식 최종 확정. 2D PlatformerMicrogame 템플릿과 공존 방식 설계(Samples 격리)
-- **Editor 상시 기동 의존**: EditMode `execute_code`는 Unity Editor 기동 + MCP Stdio 전제. 대량 배치(1만+)는 경로 D(BatchMode 병렬) 별도. 재연결 자동화 스크립트 검토
+- **Editor 상시 기동 의존**: EditMode `execute_code`는 Unity Editor 기동 + MCP Stdio 전제. 대량 배치(1만+)는 BatchMode 병렬 경로 별도. 재연결 자동화 스크립트 검토
 - **Unity 전제 정합성**: MCP 방향은 Unity 전제 위 재활용 한정. 비-Unity 엔진 이관 시 재추출 필요. EerieVillage·차차기 Unity 전제 PD 재확인 권고
+- **모바일 UI 패턴 Framework 편입**: UITouchHandler·SafeArea·BackKey 3종 Tier 2·3 배치 검토
 
 ---
 
@@ -105,9 +114,6 @@
 - `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
 - `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`
 
-**Tool_Left 점검**
-- `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`
-
 **BT.Framework 설계**
 - `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`·`03_배포방식_안건_v1.md`·`04_Tier1_3종_상호작용_설계_v1.md`
 
diff --git a/공유/조직자산/시행착오_아카이브/개발_팀장_v1.md b/공유/조직자산/시행착오_아카이브/개발_팀장_v1.md
index a0844fb..e8f7832 100644
--- a/공유/조직자산/시행착오_아카이브/개발_팀장_v1.md
+++ b/공유/조직자산/시행착오_아카이브/개발_팀장_v1.md
@@ -4,24 +4,22 @@ scope: 개발팀_통합
 author: 개발팀장
 date: 2026-04-21
 version: v1
-project_source: 수상한잡화점 (NerdNavis, 2025-2026)
-project_target: EerieVillage (BurningTimes, 2026~)
+project_source: 이전 프로젝트 (NerdNavis, 2025-2026)
+project_target: EerieVillage (Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame, BurningTimes, 2026~)
 ---
 
 # 개발팀 통합 시행착오 아카이브 v1 — 서버·클라이언트·QA 총괄 관점
 
-## 1. 개요 — 핵심 교훈 10건 요지
+## 1. 개요 — 핵심 교훈 8건 요지
 
-1. **C11(개발 관점 3축) 판정을 기획 요청 수용 전에 반드시 선행한다** — 자원 효율성·코드 직관성·범용성 3축을 통과하지 못하는 설계는 은폐하지 말고 제기(C3).
-2. **시뮬레이터 이원화(Python vs Unity C#)는 조직 생존급 리스크** — 동일 로직 2언어 유지는 밸런스 신뢰도 붕괴 경로. Unity MCP EditMode 단일 SOT 전환이 근원 해결.
-3. **서버 Critical 보안 3종(IAP 영수증·AES 하드코딩·클라 전투 연산)은 서비스 오픈 블로커**. 서버팀 가동 전 "보류"로 잠시 미뤘더라도 복원 계획과 메모리 SOT(`project_shop_security_pending.md`)를 반드시 유지.
-4. **Unity MCP 편집은 6단계 표준 워크플로우(SHA 확보→원본 Read→백업→commit→편집→검증) 없이 진행 금지** — C6-1 원본 보호 재발 방지 단일 SOT.
-5. **Agent 호출 시 절대 경로 하드코딩 금지 (C34-11)** — worktree 경계를 넘어 main 체크아웃에 변경이 기록되는 실증 사건 재발 방지. `git rev-parse --show-toplevel` 기반 상대 경로.
-6. **worktree-local 저장 자산은 조직 생존급 위험 (C34-15 5문항 체크)** — `.live/`·`memory/org/`·audit 3종 중앙 Junction 근원 해결. 신규 설정·저장소 설계 시 5문항 체크 통과 의무.
-7. **코어 프레임워크(BT.Framework)는 현 프로젝트 비투입·조직 자산 계승(P29)** — 수상한잡화점 R&D 자산 경로(`수상한잡화점/개발/06_*`)에 코어 설계 문서를 두면 오인 유발. `프로젝트/코어프레임워크/` 단일 SOT.
-8. **콘솔 병렬 실행·핫리로드 대안은 기술 검토 없이 결론 금지** — SessionStart/UserPromptSubmit hook 경계, `@import` 구문의 "세션 시작 1회만 확장" 한계 등 Claude Code 내부 메커니즘 실측 선행.
-9. **서버 권한 분배표를 명시하여 "클라가 SOT인 영역"을 정직하게 기록** — Q-P1·Q-P2·Q-P3 같은 기획 질의에 "클라 코드가 실질 SOT"임을 명시해야 괴리 재발 차단.
-10. **QA 게이트: Unity 빌드 오류·콘솔 에러 잔존 상태로 작업 종료 금지 (P14)** — 회귀 검증은 동일 경로 재현 포함. "임시로 돌아가는 코드"는 C2·C11 동시 위반.
+1. **C11(개발 관점 3축) 판정 선행** — 자원 효율성·코드 직관성·범용성 3축 미통과 설계는 은폐 금지, C3에 따라 제기.
+2. **시뮬레이터 이원화는 조직 생존급 리스크** — Python·Unity C# 2언어 동시 유지 시 메커닉 SOT 불일치·밸런스 신뢰도 붕괴. Unity MCP EditMode 단일 SOT로 근원 해결.
+3. **Unity MCP 편집 6단계 표준 워크플로우** (SHA 확보→원본 Read→백업→commit→편집→검증) 준수 의무. C6-1 재발 방지 SOT: `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`.
+4. **Agent 호출 시 절대 경로 하드코딩 금지(C34-11)** — worktree 경계 이탈 실증. `git rev-parse --show-toplevel` 기반 상대 경로 의무.
+5. **worktree-local 저장 자산 생존급 위험(C34-15)** — 3종 중앙 Junction(`.live/`·`memory/org/`·audit). 신규 저장소·hook 설계 시 5문항 통과 의무.
+6. **BT.Framework 현 프로젝트 비투입·조직 자산 계승(P29)** — Tier 1 실증 자산 EerieVillage부터 적극 활용. 특수 로직 vs 범용 모듈 경계 초기 분리.
+7. **서버 Critical 보안 3종 복원 계획 유지** — IAP 영수증·암호화 키·전투 연산. 상세는 `개발_서버팀장_v1.md`. 서버팀 가동 시점 복원 전략 수립.
+8. **QA 게이트(P14) — 빌드 오류·콘솔 에러 잔존 종료 금지** — 회귀 검증은 동일 경로 재현 포함. "임시로 돌아가는 코드"는 C2·C11 동시 위반.
 
 ---
 
@@ -31,172 +29,110 @@ project_target: EerieVillage (BurningTimes, 2026~)
 
 | 시도한 방법 | 이유 | 결과 | 교훈 |
 |------------|------|------|------|
-| Python 3종 시뮬(`battle_sim`·`full_stage_sim`·`stage_sim_v2`) + Unity C# 실코드 병행 | 기획팀 Python 숙련도·빠른 밸런스 반복 | 메커닉 SOT 불일치(예: `PCDefence_Mul=0.3f` 실측 vs 기획 가정 50%) · 괴리 발견 루프 무한 발생 | Unity MCP EditMode 단일 SOT로 일원화. Python은 참조 구현으로만 존치(동기화 검증 테스트 동반) |
-| 카드 311장을 개별 스크립트로 구현 시도(초기) | 카드별 특수 효과 구현 편의 | 신규 카드 추가 = 코드 수정 필요 · 시너지 조합 폭증 대응 불가 | 데이터 드리븐 아키텍처 강제(`e_CardType` enum + 파라미터 JSON). "신규 카드가 JSON 한 줄 수정으로 끝나는가?" 핵심 질의 |
-| 수상한잡화점 내부에 `BurningTimesCore` 네임스페이스 일부 혼재 | 초기 분리 부족 | 프로젝트 특수 로직과 범용 모듈 경계 모호 · 차기 프로젝트 재활용 어려움 | P29 코어 프레임워크 독립 레포(`BT.Framework`) 분리. 수상한잡화점은 비투입, 개발 과정에서 추출 대상만 식별(`02_수상한잡화점_추출대상_v1.md`) |
-| Tier 1 16종 단일 라운드 일괄 구현 시도 | 빠른 완결 | Data·Event·Container 3종은 상호작용 설계 재검증 필요 · 아키텍처 부채 우려 | 13종 선행 라운드 완결 후 3종을 #36 신규 지시로 분리. 라운드 완결 아카이브 원칙(`feedback_log_round_completion.md`) 정착 |
+| Python 시뮬(다종) + Unity C# 실코드 병행 | 기획팀 숙련도·빠른 반복 | 메커닉 SOT 불일치 · 기획 가정값 vs 실코드 수치 괴리 반복 | Unity MCP EditMode 단일 SOT로 일원화. Python은 참조 구현 + 자동 동기화 검증 테스트 의무 |
+| 카드·아이템·유닛 개별 스크립트 구현 | 특수 효과 구현 편의 | 신규 추가 = 코드 수정 필요 · 시너지 조합 폭증 대응 불가 | 데이터 드리븐 아키텍처 강제(enum + 파라미터 JSON). "신규 추가가 JSON 한 줄로 끝나는가?" 핵심 질의 |
+| 프로젝트 내부에 범용 네임스페이스 혼재 | 초기 분리 부족 | 프로젝트 특수 vs 범용 모듈 경계 모호 · 차기 프로젝트 재활용 곤란 | P29 코어 프레임워크 독립 레포 분리. 현 프로젝트 비투입, 추출 대상만 식별 |
+| Tier 1 전 모듈 단일 라운드 일괄 구현 시도 | 빠른 완결 | 상호작용 재검증 필요 · 아키텍처 부채 우려 | 라운드 완결 아카이브 원칙 정착(`feedback_log_round_completion.md`) |
 
-### 2-2. 서버·보안
+### 2-2. 서버·보안 (상세는 `개발_서버팀장_v1.md`)
 
 | 시도한 방법 | 이유 | 결과 | 교훈 |
 |------------|------|------|------|
-| PlayFab 주 백엔드 + Firebase 병행 시도 | 분석·크래시 수집 | `google-services.json` 부재 · Firebase 사실상 비활성 | INetworkService 추상화(BurningTimesCore 누락 모듈)로 백엔드 교체 가능 구조 선행 |
-| 12시간 자동 재로그인 · `ServerInfo.cs` 단일 허브 | 세션 유지 단순화 | 구조 직관성 확보 · 한편 PlayFab 직접 의존 고착 | 허브 패턴은 유지하되 인터페이스 추상화. 교체 시 허브만 재구현 |
-| 전투 연산 100% 클라이언트 | Unity 내부 연산 편의·초기 속도 | 변조 방어 불가 · 랭킹·이벤트 보상 악용 경로 | 최소한 "스테이지 클리어 판정·보상 지급"은 서버 재연산 필수(P0). 전체 재연산은 점진 확장 |
-| AES 키 소스 평문 하드코딩 · IL2CPP 의존 | 빌드 난독화 신뢰 | 메모리 덤프로 추출 가능 · 사실상 무의미 | 런타임 유도(디바이스ID 해시 혼합) + 서버 전송 페이로드 HMAC 서명. 키 회전 경로 확보 |
-| IAP 영수증 검증 주석처리 상태로 방치 | 서버팀 미가동 대기 | 결제 우회 경로 오픈 상태 · 오픈 블로커급 | "보류" 상태에서도 반드시 메모리 SOT(`project_shop_security_pending.md`) + PD 지시 로그 보류 사유·사후 조치 기록(P19). 서버팀 가동 즉시 P0 복원 |
-| ACTk 약 10개 필드만 `Obscured*` · Detector 미사용 | 초기 최소 적용 | SpeedHack·TimeCheck 방어 공백 | 재화·레벨·카드 보유 수량 전면 `Obscured*` · `SpeedHackDetector`·`TimeCheckDetector` 활성화 |
+| 단일 백엔드 직접 의존 | 초기 속도 | 백엔드 교체 경로 부재 · 병행 SDK는 설정 누락으로 비활성 | INetworkService 추상화 선행. 허브 패턴은 유지하되 인터페이스로 교체 가능 구조 |
+| 전투·보상 연산 100% 클라이언트 | 내부 연산 편의 | 변조 방어 불가 · 랭킹·이벤트 보상 악용 경로 | 스테이지 클리어 판정·보상 지급 최소 서버 재연산 P0. 전체 재연산은 점진 확장 |
+| 암호화 키 소스 평문 하드코딩 · IL2CPP 의존 | 빌드 난독화 신뢰 | 메모리 덤프로 추출 가능 · 사실상 무의미 | 런타임 유도(디바이스ID 해시 혼합) + 서버 페이로드 HMAC 서명 + 키 회전 |
+| IAP 영수증 검증 주석처리 | 서버팀 미가동 대기 | 결제 우회 경로 오픈 · 블로커급 | "보류" 상태라도 메모리 SOT(`project_shop_security_pending.md`) + PD 지시 로그 보류 사유·사후 조치 기록(P19) |
 
 ### 2-3. 코어 프레임워크(BT.Framework)
 
 | 시도한 방법 | 이유 | 결과 | 교훈 |
 |------------|------|------|------|
-| 코어 설계 문서를 `수상한잡화점/개발/06_*`에 배치 | 작성 편의 | R&D 비투입 방향 확정 후 "수상한잡화점 산출물"로 오인 유발 | `프로젝트/코어프레임워크/01~04` 단일 SOT로 이동·참조 경로 교체. 06은 "대체됨" 표식 |
+| 코어 설계 문서를 프로젝트 R&D 경로에 배치 | 작성 편의 | 비투입 방향 확정 후 "프로젝트 산출물"로 오인 유발 | `프로젝트/코어프레임워크/` 단일 SOT. 구 경로는 "대체됨" 표식 |
 | `Convert.ChangeType` 캐시 방식 Enum 변환 | BCL 표준 | 박싱 발생·핫패스 성능 저하 | `Unsafe.As<,>` 제로-박싱 전환. EnumToInt 단일 SOT |
-| KeyMaker 구분자 `_` 혼용 | 관례 | 수상한잡화점 `_`/`:` 혼재로 조회 실패 경험 | `:` 단일 표준. 전 프로젝트 강제 |
-| UnityEngine 의존 허용 시도 (일부 Util) | Unity 편의 | 서버·배치 재사용 불가 · C11 범용성 위반 | Tier 1은 순수 BCL 의존만. Unity 의존 모듈은 별 asmdef 분리 |
-| CsvHelper 외부 라이브러리 검토 | 파서 완결성 | Tier 1 외부 의존 최소 원칙 위반 · PC 독립 설치 리스크 | RFC 4180 핵심(쉼표·따옴표·escape)만으로 자체 구현. 기획팀 통제 CSV라 충분 |
-| Newtonsoft.Json 도입 검토 | Dictionary·polymorphism 지원 | PC 독립 설치 보장 어려움 | Unity `JsonUtility` + 래퍼 채택. 한계 명시 후 고급 케이스는 호출자 자체 파싱 경로 안내 |
-| 3개 모듈(Event·Container·Data) asmdef 분리 검토 | 경계 명확화 | 현 파일 수 규모에서 단일 참조 소비자 경험 우위 | 단일 asmdef 유지. Tier 2 확장 시 재검토 |
+| UnityEngine 의존 허용 (일부 Util) | Unity 편의 | 서버·배치 재사용 불가 · C11 범용성 위반 | Tier 1은 순수 BCL 의존만. Unity 의존 모듈은 별 asmdef 분리 |
+| 외부 파서/직렬화 라이브러리 도입 검토 | 완결성 | Tier 1 외부 의존 최소 원칙 위반 · PC 독립 설치 리스크 | 필수 핵심만 자체 구현 + Unity 기본 래퍼. 한계는 명시 후 호출자 우회 안내 |
+| 키 구분자 혼용(`_`·`:`) | 관례 | 프로젝트 간 조회 실패 경험 | `:` 단일 표준 강제 |
 
-### 2-4. 개발 인프라·운영
+### 2-4. 개발 인프라·운영·Agent 경계
 
 | 시도한 방법 | 이유 | 결과 | 교훈 |
 |------------|------|------|------|
-| 같은 디렉토리에서 CLI 여러 개 병렬 실행 | 가장 간단 | 동일 파일 동시 수정 시 덮어쓰기 · git 이력 꼬임 | 서로 다른 파일/영역·읽기 전용에만 허용. 수정 작업은 `--worktree` 격리 |
-| `CLAUDE_LIVE.md` 핫 리로드 시도 | 세션 중 규칙 반영 | `@import`는 세션 시작 1회만 확장 · 자동 반영 불가 | UserPromptSubmit hook의 `.live/` 증분 주입 경로로 근원 해결(C34) |
-| `.live/` 더미를 `$REPO_ROOT/.live/`에 저장 | 레포 내부 단순화 | worktree마다 물리 격리 발생 · 세션 간 실시간 공유 실패 | `$HOME/.claude/nerdnavis-live/` 중앙 저장 + worktree junction 연결 (C34-3) |
-| `memory/org/`를 junction만으로 관리 | 중앙화 편의 | Windows core.symlinks 이슈·한국어 경로 리스크·clone 후 접근 불가 | 레포는 실체 디렉토리 유지 + sync 스크립트 4계층 양방향 동기화 (C34-16) |
-| Agent 프롬프트에 절대 경로 `E:\...` 지정 | 호출 편의 | worktree 경계 이탈 · main 체크아웃에 파일 생성 실증(2026-04-18) | cwd 기준 상대 경로 의무 + `git -C` 교차 확인 + 경계 이탈 복구 절차 정착 (C34-11) |
-| 빌드 오류·콘솔 에러 잔존 상태로 PR 머지 | 속도 우선 | 회귀 버그 빈발 · QA 비용 누적 | P14 QA 게이트: 빌드 오류·콘솔 에러 0 원칙. 회귀 검증은 동일 경로 재현 포함 |
-| git 동기화 Phase 0~4 체계(NAS·post_receive·sync_signal·post-commit hook) | PC 독립 실시간 공유 | 초기 단계에서 경로·권한 이슈 다수 → 점진 안정화 | setup 스크립트 단일 SOT로 PC 독립 셋업 보장(C16). 신 PC 합류 시 `verify_setup` 3축 검증 |
-
-### 2-5. Agent 경계·대화로그
-
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 서브에이전트 인용 응답을 PM이 직접 작성(역할 연기) | 편의 | C23 위반 (2026-04-15 실증) · 조직 신뢰 훼손 | Task 도구 실제 호출 결과만 인용. 미확인 항목은 "미확인" 태그 |
-| 완료 후 PD 지시 로그 갱신 누락 | 작업 우선 | 다른 세션이 "진행중"으로 오인 (2026-04-16 #27 실증) | C27·C29-4 동기화 4종(PD 로그·대화로그·소통 채널·Live 더미) 동시 수행 |
+| `.live/` 더미를 레포 내부 저장 | 단순화 | worktree마다 물리 격리 · 세션 간 실시간 공유 실패 | `$HOME/.claude/nerdnavis-live/` 중앙 저장 + worktree junction (C34-3) |
+| `memory/org/`를 junction만으로 관리 | 중앙화 편의 | Windows core.symlinks·한국어 경로·clone 후 접근 불가 | 레포는 실체 디렉토리 유지 + sync 4계층 양방향 동기화 (C34-16) |
+| Agent 프롬프트에 절대 경로 지정 | 호출 편의 | worktree 경계 이탈 · main 체크아웃 파일 생성 실증 | cwd 상대 경로 의무 + `git -C` 교차 확인 (C34-11) |
+| 빌드 오류·콘솔 에러 잔존 PR 머지 | 속도 우선 | 회귀 버그 빈발 · QA 비용 누적 | P14 QA 게이트: 에러 0 원칙. 회귀 검증 동일 경로 재현 포함 |
+| 서브에이전트 인용을 PM이 직접 작성(역할 연기) | 편의 | C23 위반 · 조직 신뢰 훼손 | Task 도구 실제 호출 결과만 인용. 미확인은 "미확인" 태그 |
+| 완료 후 PD 지시 로그 갱신 누락 | 작업 우선 | 다른 세션 "진행중" 오인 | C27·C29-4 동기화 4종 동시 수행 (PD 로그·대화로그·소통 채널·Live 더미) |
 | 설계 문서 참조만 남기고 본문 미작성 | 속도 | "유령 문서" 발생 · P18 위반 | 참조 시점 즉시 작성 착수 또는 "작성 예정(담당·재개 트리거)" 명시 |
-| 08 전투시스템 SOT와 시뮬레이터 SOT 간 실측값 전파 누락 | 단일 작업만 수행 | #37 완료 후 08이 기획 가정값 유지 · 괴리 재발 위험 | 수치 확정 시 "해당 수치 등장하는 모든 SOT 전수 grep" 완료 체크리스트 편입 |
+| 수치 변경 시 단일 SOT만 업데이트 | 단일 작업 수행 | 다른 SOT 기획 가정값 유지 · 괴리 재발 | 수치 확정 시 "해당 수치 등장 모든 SOT 전수 grep" 체크리스트 편입 |
 
 ---
 
 ## 3. BT 조직 착수 시 체크리스트 (개발팀장 기준)
 
-### 3-1. 세션 시작 직후 (C10-1·C16-4 연속 이행)
-- [ ] `git fetch origin && git status` (조직 레포)
-- [ ] Unity 프로젝트(`${UNITY_PROJECT_ROOT}`) `git fetch && git status` (C30)
-- [ ] 코어 프레임워크(`BT.Framework`) `git fetch && git status`
+### 3-1. 세션 시작 직후 (C10-1·C16-4·C30)
+- [ ] 조직 레포 + Unity 프로젝트(`${UNITY_PROJECT_ROOT}`) + BT.Framework 레포 각각 `git fetch && git status`
 - [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 활성 테이블 전수 Read
-- [ ] `공유/대화로그/EerieVillage/` 최근 2일 Read + `공유/대화로그/코어프레임워크/` 최근 2일 Read
+- [ ] `공유/대화로그/EerieVillage/`·`공유/대화로그/코어프레임워크/` 최근 2일 Read
 
 ### 3-2. 신규 기능·시스템 설계 착수 전
 - [ ] C11 3축 판정 (자원 효율성·코드 직관성·범용성) 자문
-- [ ] "신규 {카드·적·아이템·이벤트} 추가가 JSON 한 줄로 끝나는가?" 데이터 드리븐 성립 확인
+- [ ] "신규 {카드·적·아이템·이벤트} 추가가 JSON 한 줄로 끝나는가?" 데이터 드리븐 확인
 - [ ] 프로젝트 특수 vs 범용 모듈 경계 명시 (범용은 BT.Framework 추출 대상 식별)
-- [ ] P18 설계 문서 선행 작성 (배경·대안·구현 가이드·검증 방법·변경 이력 5요소)
-- [ ] 기획 요청이 C11과 충돌하면 C3에 따라 우려 즉시 제기
+- [ ] P18 설계 문서 선행 작성 (배경·대안·구현 가이드·검증·변경 이력 5요소)
+- [ ] 기획 요청이 C11과 충돌 시 C3에 따라 우려 즉시 제기
 
-### 3-3. Unity 코드·씬·프리팹 편집 전
-- [ ] Unity MCP 편집 대상이면 6단계 표준 워크플로우(`공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`) 준수
-- [ ] 백업 파일: `공유/개발팀_백업/EerieVillage/{원본}.bak_{YYYYMMDD_HHMM}.{ext}`
-- [ ] `precondition_sha_256` 파라미터로 외부 변경 방어
-- [ ] 편집 후 `get_sha` 재확인 + 콘솔 에러 0 검증
+### 3-3. Unity 편집·서버 연동·Agent 호출 전
+- [ ] Unity MCP 편집 시 6단계 표준 워크플로우 준수 + 백업 `공유/개발팀_백업/EerieVillage/{원본}.bak_{YYYYMMDD_HHMM}.{ext}` + `precondition_sha_256` + 편집 후 `get_sha` 재확인 + 콘솔 에러 0 검증
+- [ ] 서버 연동: 전투·재화·IAP·랭킹·보상 영역 식별 → 권한 표 갱신 → Critical 3종 재발 체크(`개발_서버팀장_v1.md`) → 백엔드 추상화(INetworkService) 선행
+- [ ] Agent 호출: 프롬프트에 "cwd 기준 상대 경로 의무" 명시(C34-11) + `$(git rev-parse --show-toplevel)` 기준 경로 + 응답 수령 직후 `git -C <레포루트> status` + 본 worktree `git status` 병행
+- [ ] 신규 공용 저장소·hook·설정 도입 시 C34-15 worktree 경계 5문항 통과
 
-### 3-4. 서버 연동 작업 전
-- [ ] 전투·재화·IAP·랭킹·보상 중 어느 영역인지 식별
-- [ ] 해당 영역의 서버 권한 vs 클라 권한 표 갱신
-- [ ] Critical 보안 3종(IAP 영수증·암호화 키·전투 연산) 재발 여부 체크
-- [ ] 신 프로젝트는 백엔드 추상화(INetworkService) 선행 — PlayFab 직접 의존 금지
-
-### 3-5. Agent 호출·worktree 작업 전
-- [ ] Agent 프롬프트에 "cwd 기준 상대 경로 사용 의무" 명시 (C34-11)
-- [ ] 산출물 경로는 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로
-- [ ] Agent 응답 수령 직후 `git -C <레포루트> status` + 본 worktree `git status` 병행 확인
-- [ ] 신규 공용 저장소·hook·설정 도입 시 C34-15 worktree 경계 5문항 체크 통과
-
-### 3-6. 작업 완료 시 (C29-4 동기화 4종)
-- [ ] `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 상태 갱신 (완료 아카이브 즉시 이동 + 즉답 접두)
+### 3-4. 작업 완료 시 (C29-4 동기화 4종)
+- [ ] PD 지시 로그 상태 갱신 (완료 아카이브 즉시 이동 + 즉답 접두)
 - [ ] `공유/대화로그/{프로젝트}/YYYY-MM-DD.md` 엔트리 추가 (결정·설계는 "기각안" 필드 필수)
-- [ ] 소통 채널 응답서 `status: 완료` + `공유/소통/완료/`로 이동
-- [ ] `.live/` 더미 기록 (세션 갱신 전 즉시 트래킹)
-- [ ] 수치·SOT 변경 시 "해당 수치 등장 모든 SOT 전수 grep" 수행 (#37 누락 재발 방지)
+- [ ] 소통 채널 `status: 완료` + `공유/소통/완료/` 이동
+- [ ] `.live/` 더미 기록 + 수치 변경 시 "해당 수치 등장 모든 SOT 전수 grep"
 
 ---
 
 ## 4. PM 보고 안건 (특이사항)
 
-1. **서버 Critical 보안 3종 복원 계획 수립** — 신 프로젝트 EerieVillage의 서버팀 가동 시점에 수상한잡화점 보류분 3종(IAP·AES·전투 연산)의 복원 전략을 PD님께 사전 보고. 메모리 SOT `project_shop_security_pending.md` 계승 여부도 결정 필요.
-
-2. **코어 프레임워크 Tier 2·3 진입 경계 확정** — Tier 1 16/16 완료 시점에서 Tier 2(Network·Persistence·UI 공용)·Tier 3(게임 장르별) 진입 조건을 EerieVillage 요구사항과 연계하여 PD님 결정 안건화. P29 "현 프로젝트 미활용·차기 프로젝트 적극 활용" 원칙 적용.
-
-3. **Unity MCP 편집 표준 워크플로우 v1 EerieVillage 적용 범위 확정** — BT.Framework 편집은 명시 적용. Unity 씬·프리팹(비스크립트)은 현 버전 미포함. v2 확장 여부 PD 결정.
-
-4. **시뮬레이터 이원화 재발 방지** — EerieVillage는 착수 시점부터 "Unity MCP EditMode 단일 SOT" 확정. Python 시뮬은 참조 구현으로만 허용하되 자동 동기화 검증 테스트 의무화를 PD 승인 안건화.
-
-5. **PC 독립 셋업 신 PC 합류 프로토콜** — 신 스태프·신 PC 추가 시 `setup_windows.ps1`·`setup_macos.sh` + `verify_setup` 3축 검증 의무. 실패 시 Degraded 운영이 아닌 조직공지 이슈화.
-
-6. **dev-auditor 모드 A(중요 기술 결정)·모드 B(주기 감사) 운영 정착** — 3축 감사 체계 중 개발 영역 감사가 실무 정착 초기 단계. EerieVillage 착수 초반에 모드 A 호출 빈도를 높여 학습 데이터 축적.
+1. **BT.Framework Tier 1→Tier 2 진입 경계** — Tier 1 자산 EerieVillage 착수부터 적극 활용. Tier 2(Network·Persistence·UI) 진입 조건을 요구사항과 연계. P29 원칙.
+2. **서버 Critical 3종 복원 계획** — 서버팀 가동 시점에 이전 프로젝트 보류분(IAP·AES·전투 연산) 복원 전략 PD 사전 보고. 상세: `개발_서버팀장_v1.md`.
+3. **Unity MCP 워크플로우 v1 적용 범위** — BT.Framework 편집 명시 적용. 씬·프리팹(비스크립트) 미포함. v2 확장 PD 결정.
+4. **시뮬레이터 이원화 재발 방지** — EerieVillage 착수부터 Unity MCP EditMode 단일 SOT. Python 시뮬은 참조 구현 한정 + 동기화 검증 테스트 의무화 PD 승인 안건.
+5. **PC 독립 셋업 신 PC 합류 프로토콜** — `setup_*` + `verify_setup` 3축 검증 의무. 실패 시 조직공지 이슈화.
+6. **dev-auditor 모드 A·B 정착** — 착수 초반 모드 A(중요 기술 결정) 호출 빈도 상향으로 학습 데이터 축적.
 
 ---
 
 ## 5. 참조 원본 파일 목록 (감사 재현 가능)
 
-### 5-1. 수상한잡화점 개발 산출물
-- `프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md`
-- `프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md`
-- `프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md`
-- `프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md`
-- `프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md`
-- `프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md` (대체됨 → `프로젝트/코어프레임워크/01~04`)
-- `프로젝트/수상한잡화점/개발/07~13_*.md` (Phase 3 재개 로드맵 포함)
+### 5-1. 동일 시행착오 아카이브
+- `공유/조직자산/시행착오_아카이브/개발_서버팀장_v1.md` (서버 Critical 3종·백엔드 세부 SOT)
+- `공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md`
 
 ### 5-2. 코어 프레임워크 (BT.Framework)
-- `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`
-- `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md` (완료 실적 아카이브)
-- `프로젝트/코어프레임워크/03_배포방식_안건_v1.md`
-- `프로젝트/코어프레임워크/04_Tier1_3종_상호작용_설계_v1.md`
+- `프로젝트/코어프레임워크/01_아키텍처_개요_v1.md`·`02_추출대상_v1.md`·`03_배포방식_안건_v1.md`·`04_Tier1_상호작용_설계_v1.md`
 - `코어코드/BT.Framework/Runtime/Core/` 전체
 
-### 5-3. 대화로그
-- `공유/대화로그/코어프레임워크/2026-04-16.md`
-- `공유/대화로그/코어프레임워크/2026-04-17.md`
-- `공유/대화로그/코어프레임워크/2026-04-18.md`
+### 5-3. 이전 프로젝트 개발 산출물 (상세 참조)
+- `프로젝트/수상한잡화점/개발/01~13_*.md`
 
-### 5-4. 소통 채널 (완료)
-- `공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md`
-- `공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md`
-- `공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md`
-- `공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md`
-- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
-- `공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md`
-- `공유/소통/완료/2026-04-17_서버_작업_참고자료.md`
-- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md`
-- `공유/소통/완료/2026-04-17_업무공유체계_점검_서버팀.md`
-
-### 5-5. 개발팀→PM 자체 감사·검토
-- `공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md`
-- `공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md`
-- `공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md`
-- `공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md`
-- `공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md`
-
-### 5-6. 조직 자산·표준 워크플로우
+### 5-4. 조직 자산·표준 워크플로우
 - `공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md`
-- `공유/서버_작업_참고자료/2026-04-17_서버_작업_참고자료_v1.2.docx` (접근 가능 시)
 - `공유/개발팀_백업/` (원본 백업 SOT)
 
-### 5-7. feedback 메모리 (재발 방지 SOT)
-- `memory/org/feedback_agent_path_boundary.md` — Agent 절대 경로 유출 실증
-- `memory/org/feedback_worktree_isolation.md` — worktree 격리 5문항 체크
-- `memory/org/feedback_git_scope_shortcut.md`
-- `memory/org/feedback_dev_auditor_*.md` — 개발 감사 실증
-- `memory/org/feedback_memory_sync_overwrite.md` — memory sync 덮어쓰기 실증
-- `memory/org/feedback_c6_backup_before_edit_violation.md` — Unity MCP 편집 백업 누락
-- `memory/org/feedback_log_round_completion.md` — 라운드 완결 아카이브 원칙
+### 5-5. feedback 메모리 (재발 방지 SOT)
+- `feedback_agent_path_boundary.md` — Agent 절대 경로 유출
+- `feedback_worktree_isolation.md` — worktree 경계 5문항 체크
+- `feedback_memory_sync_overwrite.md` — memory sync 덮어쓰기
+- `feedback_c6_backup_before_edit_violation.md` — Unity MCP 백업 누락
+- `feedback_log_round_completion.md` — 라운드 완결 아카이브
+- `feedback_dev_auditor_*.md` — 개발 감사 실증
 - `project_shop_security_pending.md` — Critical 3종 보류 SOT
 
 ---
 
-*본 아카이브는 BurningTimes 조직이 EerieVillage 및 차기 프로젝트 착수 시 동일한 시행착오를 반복하지 않고 검증된 방법을 재활용하기 위한 개발팀 통합 관점 SOT이다. PD 지시 2026-04-21 "조직 자산 계승" 이행 산출물.*
+*본 아카이브는 BurningTimes 조직이 EerieVillage 및 차기 프로젝트 착수 시 동일 시행착오 반복 방지·검증된 방법 재활용을 위한 개발팀 통합 관점 SOT. PD 지시 2026-04-21 "조직 자산 계승" + "불필요 부분 제외" 이행 산출물.*
diff --git a/공유/조직자산/시행착오_아카이브/기획_balance_designer_v1.md b/공유/조직자산/시행착오_아카이브/기획_balance_designer_v1.md
index 34f4991..b9374d2 100644
--- a/공유/조직자산/시행착오_아카이브/기획_balance_designer_v1.md
+++ b/공유/조직자산/시행착오_아카이브/기획_balance_designer_v1.md
@@ -1,73 +1,53 @@
-# 수상한잡화점 밸런스 기획 시행착오 아카이브 v1
+# 밸런스 기획 시행착오 아카이브 v1
 
 > **조직**: NerdNavis → BurningTimes 전환 기점 추출
-> **대상 프로젝트**: 수상한잡화점 (2D 덱빌딩 로그라이트)
+> **전 프로젝트**: 수상한잡화점 (2D 덱빌딩 로그라이트)
 > **차기 프로젝트**: EerieVillage (2D 플랫포머 퇴마)
-> **추출일**: 2026-04-20
-> **추출자**: 밸런스 기획자 (balance-designer)
-> **데이터 소스 실측**: 참조 원본 직접 Read 기반 (C23 준수 — 추정·역할연기 없음)
+> **추출일**: 2026-04-20 / **추출자**: 밸런스 기획자 (balance-designer)
+> **데이터 소스**: 참조 원본 직접 Read 기반 (C23 — 추정·역할연기 없음)
 
 ---
 
-## §1. 데이터 파싱 오해 — 퍼센트값·음수값 해석 실증
+## §1. 데이터 파싱 검증 원칙
 
-### §1-1. 각성트리 퍼센트값 오해 경위
+### §1-1. 문자열 포맷 ≠ 런타임 의미 (퍼센트값 오해 실증)
 
-**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ001 기획팀 → 개발팀)
+**교훈**: 수치 테이블의 `%` 등 포맷 기호가 런타임 파싱 로직에 따라 **전혀 다른 결과**를 낼 수 있다. 동일 컬럼에 복수 포맷이 혼재하면 오해 위험이 급증한다.
 
-**오해 내용**: `PCAwakening.json` 테이블에서 `s_Value='500%'` 형식이 `s_Value='5'`와 혼재. 기획팀은 `'500%'`를 "기존 스탯의 500% 배율 적용"으로 해석하여 **각성 만렙 시 DPS +1067% / EHP +197%** 라는 비정상 수치를 산출했다.
+**실증**: 기획팀이 `s_Value='500%'`를 "500% 배율 적용"으로 해석하여 DPS 수치를 수배 과산출. 실제 파싱은 `float × 0.01f` 고정값 변환이었음.
 
-**실제 동작**: `table_base.cs` `Get_Value()` 메서드가 `%` 포함 문자열을 `float * 0.01f`로 파싱. 즉 `'500%'` = `500 × 0.01 = 5.0f` = `'5'`와 동일한 고정값. 배율 적용이 아님.
+**차기 프로젝트 원칙**:
+- 밸런스 시트 작성 전 **파싱 함수 코드를 개발팀과 공유·확인** 필수
+- 테이블 컬럼 헤더에 "런타임 해석 방식" 주석 요청
+- DPS·EHP 산출 전 소규모 실측 검증(입력값 → 실제 전투 결과) 선행
 
-```
-// 실제 파싱 로직 (REQ001 응답 코드 근거)
-if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
-```
+### §1-2. 음수값 = 오류 아님 — 디버프·방향성 역전 명세 의무
 
-**만렙 효과 재계산**: `s_Value='500%'`, `s_UpgradeStatValuePara='100%'`, `n_MaxLv=5` 기준
-- 기획팀 추정: `500% + 100% × 4 = 900%` (배율 해석 오류)
-- 실제 결과: `5.0 + 1.0 × 4 = +9` (고정값 가산)
+**교훈**: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 트레이드오프 페널티"인지 설계 문서에 명시해야 한다. **방향성이 역전되는 스탯**(쿨타임·캐스팅타임 등 감소 = DPS 증가)은 별도 명세표 필수.
 
-**정정 방법**:
-1. 개발팀에 REQ 발행 → 코드 레벨 파싱 로직 확인 요청
-2. 확인 후 기여도 문서 수치 전면 재계산
-3. 데이터 입력 형식 통일 권고 (런타임 동작은 정상이나 가독성 문제)
+**차기 프로젝트 원칙**:
+- 음수값 허용 스탯 목록 + 방향성 정의표를 밸런스 설계 착수 전 작성
+- DPS/EHP 계산 시 방향성 역전 스탯을 반영하지 않으면 수치 왜곡 발생
 
-**차기 프로젝트 EerieVillage 적용 원칙**: 수치 테이블의 문자열 포맷(`%`, `s`, `exp` 등)이 런타임 파싱 로직에 따라 전혀 다른 결과를 낼 수 있다. **밸런스 시트 작성 전 반드시 파싱 함수 코드를 개발팀과 공유·확인**한다. 특히 동일 컬럼 내 혼재 포맷은 오해 위험이 높다.
+### §1-3. JSON/CSV SOT 맹신 금지 — Unity 실측 선행
 
----
+**실증**: 기획 문서에 "WorldMap 4개 그룹" 표현이 SOT처럼 인용·전파되어 스테이지 구조 전체를 잘못 설계. 실제 데이터는 기획 문서와 다른 규모였음.
 
-### §1-2. 장비 옵션 음수값 — 디버프 의도 명확화
-
-**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ002 기획팀 → 개발팀)
-
-**발견 내용**: 8부위 풀셋 장착 시뮬에서 `CriDmg -20%`, `Avoid_Melee -3%`, `HitRate -2` 등 음수 값이 합산. 기획팀은 오류 가능성을 제기.
-
-**실제 의미**: 의도적 트레이드오프 설계. 무기 `MainOption2`가 페널티성 옵션을 고정 보유하는 구조.
-
-| 패턴 | 사례 | 밸런스 의도 |
-|------|------|------------|
-| 무기 고공격력 + 치명타 피해 페널티 | ATK 강화 대신 CriDmg -20% | 딜러 빌드 트레이드오프 |
-| 쿨타임 음수 = 보너스 | `AttackCoolTime -3%` = 공속 +3% 증가 | 스탯명 방향성 주의 |
-| 강화로도 완화되지 않는 고정 페널티 | `UpgradeStatValuePara = 0` | 성장해도 단점 유지 |
-| 세트 옵션 양수/음수 쌍 | HP -10% + 보호막 +10% | 빌드 방향 차별화 |
-
-**핵심 교훈**: `AttackCoolTime -3%`처럼 **스탯명의 방향성**이 음수값 해석을 역전시키는 사례가 존재한다. 쿨타임 감소 = DPS 증가. 밸런스 계산 시 스탯 의미와 음수 방향을 함께 명시해야 한다.
-
-**차기 프로젝트 EerieVillage 적용 원칙**: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 페널티"인지는 반드시 설계 문서에 명시한다. 특히 "방향성이 역전되는 스탯(쿨타임·캐스팅타임 등)"은 별도 명세표를 작성한다. DPS/EHP 계산 시 이 방향성 역전을 반영하지 않으면 수치가 왜곡된다.
+**차기 프로젝트 원칙**:
+- Unity Export CSV/JSON 직접 실측 선행 의무
+- 기획 문서 상단에 **"데이터 소스 실측 일시" 필드 명기** 필수
+- 실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)
+- 모든 DPS·TTK 계산은 `UTF N/N Passed` 형식으로 검증 통과 여부 기록
 
 ---
 
 ## §2. 어뷰징 판정 임계값 설계 — 서버 이관 원칙
 
-**출처**: `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md`
+### §2-1. 설계 전제 (재미 우선 P30 연계)
 
-### §2-1. 설계 전제 (재미 우선 원칙 P30 연계)
-
-어뷰징 판정은 "어뷰저를 잡는 것"이 목표가 아니라 **"정직한 플레이어의 재미를 보호"**하는 것이 목표다. 이 전제가 임계값 설계의 모든 수치를 결정한다.
-
-- **false positive 최소화**: 정상 유저를 어뷰저로 오판정하면 성취 경험이 훼손된다. 이것이 C7 재미 우선 원칙 위반이다.
-- **안전 마진의 존재 이유**: 프레임 드랍, 클라 시계 오차, 반올림 오차 — 이 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조를 막기 위해 마진이 필요하다.
+어뷰징 판정의 목표는 **"정직한 플레이어의 재미 보호"**다. 이 전제가 모든 임계값 수치를 결정한다.
+- **false positive 최소화**: 정상 유저 오판정 = 성취 경험 훼손 = P30 위반
+- **안전 마진 존재 이유**: 프레임 드랍·클라 시계 오차·반올림 오차 등 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조 차단
 
 ### §2-2. 임계값 도출 공식
 
@@ -75,19 +55,19 @@ if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
 경계값 = 시뮬_이론_극값 × 안전마진계수
 ```
 
-시뮬 이론 극값은 10,000회 이상 반복 시뮬레이션의 상위/하위 0.1% 값을 채택한다. **절대 최대/최소가 아닌** 이유: 시뮬 자체 오차 흡수.
+시뮬 이론 극값 = 10,000회 이상 반복 시뮬레이션 상위/하위 0.1% 값 (절대 최대/최소 불채택 — 시뮬 자체 오차 흡수)
 
 | 벡터 특성 | 마진 방향 | 계수 | 근거 |
 |---------|--------|-----|------|
-| 클리어타임 (짧을수록 의심) | 하한 = 이론 최단 × 0.80 | 0.80 | 클라 시계 오차 15% 흡수 |
+| 클리어타임 (짧을수록 의심) | 하한 = 이론 최단 × 0.80 | 0.80 | 클라 시계 오차 흡수 |
 | 획득 재화 (많을수록 의심) | 상한 = 이론 최대 × 1.05 | 1.05 | 반올림·버프 중첩 케이스 흡수 |
-| 랭킹 점수 (높을수록 의심) | 상한 = 이론 최대 × 1.10 | 1.10 | 신규 카드 출시 과도기 흡수 |
+| 랭킹 점수 (높을수록 의심) | 상한 = 이론 최대 × 1.10 | 1.10 | 신규 콘텐츠 출시 과도기 흡수 |
 | 피격 수 (적을수록 의심) | 하한 = 0 (음수만 차단) | — | 0회도 이론상 가능 |
 | 미션 카운트 | 상한 = 일일 최대 × 1.00 | 1.00 | 마진 불필요 (정수 카운트) |
 
-**"안전 마진 0%" 기각 근거**: 시뮬 극값 그대로 경계값으로 쓰면 false positive 폭발. 정상 유저도 매번 플래그됨. **재미 원칙 위반.**
+**안전 마진 0% 기각 근거**: false positive 폭발 → 정상 유저 매번 플래그 → 재미 원칙 위반.
 
-### §2-3. 플래그 3단계 — 어뷰저 학습 방지와 false positive 보호 균형
+### §2-3. 플래그 3단계 (어뷰저 학습 방지 + false positive 보호)
 
 | 단계 | 트리거 | 클라 응답 | 자동 조치 |
 |-----|-------|---------|---------|
@@ -95,87 +75,44 @@ if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
 | F2 중대 | +10~50% 초과 또는 F1×3 | "서버 동기화 오류" | 보상 보류 + 알림 |
 | F3 확정 | +50% 초과 또는 논리 모순 | "blocked" | 보상 미지급 + 계정 플래그 |
 
-F1에서 클라에게 경고를 노출하지 않는 이유: 어뷰저가 경계값을 학습하지 못하도록 막기 위함.
+F1 무감지 이유: 어뷰저가 경계값을 학습하지 못하도록 차단.
 
-### §2-4. 기각안 (검토했으나 채택 안 한 방법론)
+### §2-4. 기각안
 
-1. **서버 단독 시뮬 재현 검증**: 서버가 클라 입력을 받아 전투 재시뮬 → 기각. CPU 비용 폭증 + 부동소수점 동기화 이슈. 싱글플레이 구조에 과잉 투자.
-2. **머신러닝 이상치 탐지**: 학습 데이터 축적 전 초기 출시 대응 불가. 장기 보조 수단으로만 검토.
-3. **클라 단독 판정**: 메모리 조작으로 즉시 무력화. 원천 제외.
-4. **안전 마진 0% 엄격 검증**: false positive 폭발 → 재미 원칙 위반으로 기각.
+1. **서버 단독 시뮬 재현 검증**: CPU 비용 폭증 + 부동소수점 동기화 이슈 — 기각
+2. **머신러닝 이상치 탐지**: 초기 출시 학습 데이터 부재 — 장기 보조 수단으로만 검토
+3. **클라 단독 판정**: 메모리 조작으로 즉시 무력화 — 원천 제외
+4. **안전 마진 0% 엄격 검증**: false positive 폭발 → 재미 원칙 위반 — 기각
 
-### §2-5. ★조건 교차 검증 (P17 배타 배치 연계)
+### §2-5. 달성 조건 위조 차단 (★조건 서버 교차 검증)
 
-서버 검증에 기획팀이 정의한 ★조건을 포함시켜야 어뷰저가 "달성 못 한 ★조건을 클리어한 것처럼" 위조하는 AV-4 벡터를 막을 수 있다.
+서버 검증에 기획팀 정의 ★조건을 포함시켜야 어뷰저의 ★조건 위조를 차단한다. ★조건 통과 보고와 실제 필드값이 모순되면 F3 확정(논리 모순 범주).
 
-```json
-"starConditions": {
-  "C6": { "field": "potionUsed", "operator": "==", "value": 0 },
-  "N2": { "field": "hitsTaken", "operator": "<=", "formula": "subMapCount * 1" }
-}
-```
-
-★조건 통과 보고와 필드값이 모순되면 F3 확정 (논리 모순 범주).
-
-**차기 프로젝트 EerieVillage 적용 원칙**: 퇴마 클리어 보상·퍼펙트 클리어 인증 등 서버 검증이 필요한 성취 체계가 있다면, 기획팀이 "이론 극값 산정 방법론 + ★조건 검증 규칙"을 서버 개발팀에 제공하는 역할 분담을 사전에 확정한다. 경계값 수치는 시뮬 가동 후 채우는 구조로 설계 틀을 먼저 확정하면 개발팀과 병렬 진행 가능하다.
+**차기 프로젝트 원칙**: 퇴마 클리어 보상·퍼펙트 클리어 인증 등 서버 검증 성취 체계가 있다면, 기획팀이 "이론 극값 산정 방법론 + 달성 조건 검증 규칙"을 서버 개발팀에 선행 제공한다. 경계값 수치는 시뮬 가동 후 채우는 구조로 틀을 먼저 확정하면 개발팀과 병렬 진행 가능하다.
 
 ---
 
-## §3. Day 11~14 밸런스축 본작업 — TTK 기반 난이도 곡선 체계
+## §3. TTK 기반 난이도 곡선 설계 원칙
 
-**출처**: `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md`
+### §3-1. 재미 정의 → TTK 목표 → 수치 설계 순서
 
-### §3-1. 설계 전제 확정 방식 (앵커 포인트 접근법)
+**재미 정의 선행**: "이 구간에서 플레이어가 어떤 경험을 해야 하는가"를 먼저 확정하고, 그 경험에서 역산하여 TTK 목표를 도출한다. 수치를 먼저 잡고 재미를 끼워맞추는 방향은 금지.
 
-밸런스 수치는 전체를 동시에 잡으려 하지 않고 **앵커 포인트(기준점) 1개를 먼저 고정**한 뒤, 그 기준에서 각 요소의 기여도를 순차 측정하는 방식으로 진행했다.
+**앵커 포인트 접근법**: 전체 수치를 동시에 잡지 않고 **기준점 1개(앵커 DPS·TTK)를 실측으로 먼저 고정**한 뒤, 각 성장 요소의 기여도를 순차 측정한다.
 
-| 기준 | 값 | 출처 |
-|------|---|------|
-| 앵커 DPS | 1.05 | Phase 0 전투 시뮬 실측 |
-| 앵커 TTK | 5.7s | Phase 0 실측 |
-| 앵커 EHP | 64 | Phase 0 실측 |
-| G1 풀빌드 실전 DPS | 5.24 | Phase 3 실측 (UTF 14/14 Passed) |
-| 장비 세트 완성 기여 | +71.46% | Phase 3 실측 (±0.86% 오차) |
-
-### §3-2. TTK를 "재미"로 번역하는 방법
-
-**재미 정의 선행**: Stage 11~15 = "장비를 맞추기 시작해야 안정적으로 클리어되는 중반 구간." 이 재미 정의가 TTK 목표를 결정한다.
-
-- 카드 단독 DPS(5.24)로 타이트 또는 클리어 곤란 → 장비 투자 동기 부여
-- 장비 세트 완성(DPS 8.98)으로 TTK 24~45초 범위 → 긴장감 있되 클리어 가능
-- ★1 클리어 TTK 목표: 장비 세트 결합 후 **20~35초 (보스 1체 기준)**
-
-**공식**:
 ```
-TTK (카드+세트) = HP + Shield 합산 / DPS_세트결합
-DPS_세트결합 = 5.24 × 1.7146 = 8.98
+TTK = (HP + Shield 합산) / DPS_결합
 ```
 
 주의: Shield는 직접 감소 방식 (방어력 계수 적용 없음). HP는 방어력 계수 적용.
 
-### §3-3. Stage별 검증 결과 요약
+### §3-2. 성장 요소 기여도 표 구조 (EerieVillage 설계 참조)
 
-| Stage | HP+Shield 합산 | 세트결합 TTK | C9 가능 | 핵심 주의사항 |
-|-------|--------------|------------|---------|-------------|
-| 11 | 313.5 (+42%) | 24.6~45.2s | 가능 | 흡혈귀여왕2 Shield 급등 — 의도 설계 |
-| 12 | 289.0 (-7.8%) | 17.6~45.2s | 최적합 | C2∧N2 동시 배치 회피 권고 |
-| 13 | 253.0 (-12.5%) | 28.2s | **금지** | 단독 보스 — P17 배타 #5 C9 불가 |
-| 14 | 300.5 (+18.7%) | 28.2~38.8s | 가능 | N4∧C6 동시 배치 주의 (P17 #3) |
-| 15 | 308.5 (+2.7%) | 30.0~38.8s | 가능 | 흑기사1 ATK Max 45 — C2∧N2 금지 (P17 #1) |
+각 성장 단계(기본 → 일반 장비 → 세트 → 추가 성장)가 TTK를 어떻게 변화시키는지 표로 구성하여 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 이 구조 자체가 재미 설계의 수치 번역 도구다.
 
-**고Shield 보스 패턴**: 흡혈귀여왕2(Shield 315), 메두사2(Shield 230)는 세트+각성 결합 기준에서도 35~45초 영역. 이 구간은 "추가 성장 요소(각성·진화) 투자 동기 부여" 의도로 설계됨.
+### §3-3. 고내구도 보스 의도 구분
 
-### §3-4. 성장 단계별 DPS 조합표 (EerieVillage 설계 참조용)
-
-| 성장 조합 | DPS 배율 | 해당 Stage 11 보스 TTK |
-|---------|---------|-------------------|
-| 카드 단독 | ×1.00 | 42.2s (클리어 곤란) |
-| 카드 + 일반장비 | ×1.30 | 32.5s |
-| 카드 + 세트완성 | ×1.71 | 24.6s (적정) |
-| 카드 + 세트 + 각성 1.50 | ×2.57 | 16.4s (쾌적) |
-| 카드 + 세트 + 각성 + 진화 1.40 | ×3.59 | 11.7s (매우 쾌적) |
-
-이 테이블 구조는 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 재미 설계의 수치 번역 예시로 활용 가능.
+내구도 급등 구간이 오류인지 의도 설계인지는 TTK 수치로 판정한다. 세트·추가 성장 결합 후에도 TTK가 목표 상한을 크게 초과하면 "추가 성장 요소 투자 동기 부여" 의도 여부를 설계 문서에 명기해야 한다.
 
 ---
 
@@ -187,17 +124,17 @@ DPS_세트결합 = 5.24 × 1.7146 = 8.98
 
 ```
 {원본명}.bak_{YYYYMMDD_HHMM}.{확장자}
-예: PCAwakening.bak_20260420_1430.json
+예: balance_table.bak_20260501_1430.json
 ```
 
 **금지 형식**: `.bak-*` (하이픈), Unix timestamp, 버전 번호 단독 (`_v1.bak`).
 
 ### §4-2. 경계값 테이블 버전 관리
 
-어뷰징 판정 경계값 테이블은 게임 밸런스 패치마다 갱신이 필요하다. 이때:
+어뷰징 판정 경계값은 게임 밸런스 패치마다 갱신이 필요하다.
 
-1. **정기 갱신**: 카드 수치 변경·신규 몬스터 추가 시 해당 영역 시뮬 재실행
-2. **긴급 갱신**: 어뷰징 신고 접수 또는 랭킹 이상치 감지 시 즉시 재실행
+1. **정기 갱신**: 수치 변경·신규 콘텐츠 추가 시 해당 영역 시뮬 재실행
+2. **긴급 갱신**: 어뷰징 신고 또는 랭킹 이상치 감지 시 즉시 재실행
 3. **버전 관리**: `boundary_table.bak_YYYYMMDD_HHMM.json` 백업 후 교체
 4. **변경 이력**: PD 지시 로그·대화로그에 기각안 포함 기록 (P16 산출물 추적성)
 
@@ -208,19 +145,7 @@ DPS_세트결합 = 5.24 × 1.7146 = 8.98
 | 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
 |------|--------|----------|----------------|----------|--------------|
 
-**"재미 근거" 컬럼이 공란이면 수치 조정 금지**: 어떤 재미를 강화하는지 먼저 정의하지 않은 수치 조정은 P30 위반이다.
-
-### §4-4. JSON/CSV SOT 맹신 금지 (기획팀 데이터 실측 의무 v1 §1-4)
-
-**실증 사건**: `스테이지난이도곡선_v1.md §1`에 "WorldMap_1~4 4개 그룹"이라는 표현이 기획 문서 SOT처럼 인용·전파되어, Phase 4 지역 1 전체를 "Stage 1~6 = 지역 1 = 6개"로 설계하는 오류가 발생했다. 실제 데이터는 **21개 구역 × 각 4개 하위 스테이지 = 총 122 스테이지**였다.
-
-**재발 방지 원칙**:
-- 기획 문서의 수치·구조를 **무비판 수용 금지**
-- Unity Export CSV/JSON 직접 실측 선행 의무
-- 기획 문서 상단에 "데이터 소스 실측 일시" 필드 명기 필수
-- 실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)
-
-**수치 검증 체계**: 모든 DPS·TTK 계산은 Unity 실측 데이터 기반이어야 하며, "UTF N/N Passed" 형식으로 검증 통과 여부를 기록한다.
+**"재미 근거" 컬럼 공란 시 수치 조정 금지**: 어떤 재미를 강화하는지 먼저 정의하지 않은 수치 조정은 P30 위반.
 
 ---
 
@@ -228,42 +153,31 @@ DPS_세트결합 = 5.24 × 1.7146 = 8.98
 
 ### §5-1. 재미 정의 없는 수치 조정 금지 (P30 실무)
 
-수상한잡화점에서 모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의했다. 대표 사례:
+모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의한다. 대표 원칙:
 
-- **어뷰징 안전 마진 0% 기각**: 이유는 기술적 정확성이 아니라 "false positive가 정상 플레이어 경험을 훼손한다"는 재미 관점이었다.
-- **이슈 1 현 수치 고정 결정**: G1 풀빌드 DPS +200~280%가 목표 +80~120% 대비 2배 초과이나, 수치 재조정보다 HP·TTK 설계가 현 DPS를 반영한 상태로 일관성을 유지하는 것이 재미 경험 보전에 유리하다고 판단.
-- **Stage 10→11 내구도 +42% 급등**: 오류가 아닌 "장비 투자 동기 부여"라는 재미 의도 설계임을 TTK 수치로 확인.
+- **어뷰징 안전 마진**: 기술적 오차 범위가 아니라 "이 범위 안은 재미있게 플레이하는 정상 유저"라는 재미 판단이 선행된 수치
+- **내구도 급등 구간**: 오류 여부 판단 전에 "장비 투자 동기 부여" 등 재미 의도 설계인지 먼저 확인
+- **수치 재조정 vs 현 수치 수용**: 일관성 있는 재미 경험 보전이 목표 범위 이탈보다 우선될 수 있음
 
-### §5-2. 어뷰징 임계값과 재미의 교점
+### §5-2. 달성 조건 배타 설계 — 재미 충돌 우선 검토
 
-어뷰징 판정 기준을 너무 엄격하게 잡으면 실력 있는 정상 유저를 차단하게 된다. 이것은 **재미 설계 실패**다. 임계값 설계는 밸런스 기획자가 개입해야 하는 영역이다.
+달성 조건 배타 체계(P17 ★조건 배타 7종)는 기술 제약이 아니라 **이중·삼중 부담이 재미를 손상시키기 때문**에 금지된다.
 
-안전 마진 계수(0.80·1.05·1.10 등)는 "기술적으로 합당한 오차 범위"가 아니라 **"이 오차 범위 안에 있는 유저는 재미있게 플레이하고 있는 정상 유저"**라는 재미 판단이 선행된 수치다.
-
-### §5-3. P17 배타 배치 체계의 의미
-
-★조건 배타 7종(P17)은 단순한 기술적 제약이 아니다. 각 배타 조합이 금지된 이유는 **"그 조합이 플레이어에게 이중·삼중 부담을 주어 재미를 손상시키기 때문"**이다.
-
-| 배타 조합 | 재미 손상 이유 |
+| 배타 패턴 | 재미 손상 이유 |
 |----------|------------|
-| C2∧N2 (완벽 클리어 + 피격 제한) | 피격 최소화 부담을 두 방향에서 동시 부과 — 스트레스 빌드 |
-| C6∧N4 (포션 절제 + 쉴드 하한) | 회복 빌드 외 빌드 선택지 전면 배제 — 다양성 파괴 |
-| N5∧N6 (후열 선공 + 전열 선공) | 타겟팅 자유도 박탈 + 논리 모순 — 달성 불가 조건 |
+| 피격 최소화 × 피격 최소화 이중 조건 | 동일 축 이중 부담 — 스트레스 빌드 |
+| 회복 억제 + 회복 강제 | 회복 빌드 외 선택지 전면 배제 — 다양성 파괴 |
+| 논리 모순 조건 쌍 | 달성 불가 조건 — 플레이어 이탈 |
 
-EerieVillage에서 유사한 "달성 조건" 체계를 설계할 때, 각 조건 쌍의 **재미 충돌 여부**를 먼저 검토한다.
+**차기 프로젝트 원칙**: 유사한 "달성 조건" 체계 설계 시, 각 조건 쌍의 **재미 충돌 여부**를 먼저 검토한다. 배타 목록은 조건 풀 확정 후 프로젝트별 재정의한다.
 
-### §5-4. 드랍률·확률 설계 교훈
+### §5-3. 빌드 형성 확률 역산 의무
 
-수상한잡화점 드래프트 확률:
-- G1(일반) 66.2%, G2 19.9%, G3 9.9%, G4 3.3%, G5 0.66%
+드랍 풀 설계 시 단순 확률 수치만으로는 빌드 형성 가능성을 알 수 없다. **빌드 형성에 필요한 핵심 아이템 등장 확률을 역산**하여 "1런에 빌드 시작이 가능한 최소 확률"을 별도 검증한다.
 
-**핵심 교훈**:
-- G5 물약 카드 등장 확률 = 0.66% × (G5 중 물약 비율) ≈ **~0.15%** → "나오면 기적" 수준
-- 이 확률에서 "물약 빌드"는 설계 의도와 달리 사실상 형성 불가능한 빌드가 되어버림
-- **빌드 형성에 필요한 핵심 카드 등장 확률**을 역산해서 "1런에 빌드 시작이 가능한 최소 확률"을 별도로 검증해야 한다
-- 확률 표기는 분수·백분율 동시 기재: G5 = 10/1510 ≈ 0.66%
-
-EerieVillage에서 "퇴마 도구" 드랍 풀 설계 시 동일한 검증이 필요하다.
+- 확률 표기: 분수·백분율 동시 기재 (예: 10/1510 ≈ 0.66%)
+- 역산 결과 "나오면 기적" 수준이면 해당 빌드는 사실상 형성 불가능 → 드랍 풀 재설계 필요
+- **EerieVillage 퇴마 도구 드랍 풀** 설계 시 동일 검증 적용
 
 ---
 
@@ -271,7 +185,8 @@ EerieVillage에서 "퇴마 도구" 드랍 풀 설계 시 동일한 검증이 필
 
 | 일시 | 변경자 | 변경 내역 | 재미 근거 | 관련 지시 |
 |------|--------|----------|----------|---------|
-| 2026-04-20 | 밸런스 기획자 (balance-designer) | 전체 신설 — NerdNavis 수상한잡화점 밸런스 시행착오 5섹션 추출 | BurningTimes EerieVillage 밸런스 설계 품질 향상 | BurningTimes 조직 전환 기점 자산 추출 |
+| 2026-04-20 | 밸런스 기획자 (balance-designer) | 전체 신설 — 수상한잡화점 밸런스 시행착오 5섹션 추출 | BurningTimes EerieVillage 밸런스 설계 품질 향상 | BurningTimes 조직 전환 기점 자산 추출 |
+| 2026-04-20 | 밸런스 기획자 (balance-designer) | Phase 2-B 재압축 — 이전 프로젝트 구체 수치·스탯명 제거, 방법론·원칙 중심 재작성 | BT·EerieVillage 활용 가치 기준 정제 | PD님 결정 5번 집행 |
 
 ---
 
diff --git a/공유/조직자산/시행착오_아카이브/기획_팀장_v1.md b/공유/조직자산/시행착오_아카이브/기획_팀장_v1.md
index 4194a0b..419d710 100644
--- a/공유/조직자산/시행착오_아카이브/기획_팀장_v1.md
+++ b/공유/조직자산/시행착오_아카이브/기획_팀장_v1.md
@@ -3,32 +3,25 @@ type: 시행착오_아카이브
 scope: 기획팀_통합
 author: 기획팀장
 date: 2026-04-21
-version: v1
-project_source: 수상한잡화점 (NerdNavis, 2025-2026)
-project_target: EerieVillage (BurningTimes, 2026~)
-sub_scope:
-  - 시스템 기획 (system-designer)
-  - 컨텐츠 기획 (content-designer)
-  - 레벨 기획 (level-designer)
-  - 시나리오 (narrative-designer)
-  - 밸런스 (balance-designer)
-  - UX (ux-designer)
+version: v1 (재압축)
+project_source: 수상한잡화점 (NerdNavis, 덱빌딩 전투)
+project_target: EerieVillage (BurningTimes, 2D 플랫포머 퇴마)
+sub_scope: [시스템, 컨텐츠, 레벨, 시나리오, 밸런스, UX]
+note: 원본 15,000자 → BT 신생 조직·2D 플랫포머 퇴마 활용 가치 기준 재압축. 이전 프로젝트 전용 수치·Phase·파일명·덱빌딩 메카닉 세부·Day별 일정은 §5 참조 원본에서 재현.
 ---
 
-# 기획팀 통합 시행착오 아카이브 v1 — 시스템·컨텐츠·레벨·시나리오·밸런스·UX 총괄 관점
+# 기획팀 통합 시행착오 아카이브 v1 — 범용 교훈 중심
 
-## 1. 개요 — 핵심 교훈 10건 요지
+## 1. 개요 — 핵심 교훈 8건
 
-1. **"데이터 구조 실측 선행"이 기획팀 전체의 제1원칙이다.** "WorldMap 4그룹" 추측 SOT가 Phase 4 지역 1 v1 전체를 폐기시킨 사건은 기획팀 역사상 최대 재작업 사례. CSV/JSON Export 실측 없는 기획 작업은 시한폭탄이다.
-2. **Phase 범위 재정의는 기획팀장 재량을 넘어 PD님 승인 영역이다.** Phase 3를 "설계 체계 확립"으로 재정의하고 Day 15+를 Phase 4로 분리한 결정은 PD B안 수용 전제 위에서만 집행 가능했다.
-3. **PD님 확정 용어는 절대 변형·축약 금지.** "Phase 1~4"를 "A/B/C/D"로 재매핑하거나, "지역"을 "WorldMap 그룹"으로 치환하는 것은 C22 위반이자 재작업의 직접 원인.
-4. **재미 판단은 기획팀 고유 영역이지만, 수치 판단은 개발팀 C11과 조율 필수.** P30(재미 우선) 전제 위에 C11(자원 효율·코드 구조·범용성) 충돌이 발생하면 PM·PD님 판단으로 에스컬레이션.
-5. **"설계 원칙 vs 임시 데이터" 분리 구조가 차기 프로젝트 자산 계승의 핵심.** C9 배치 원칙·P17 배타 체크·TTK 산출·AppearGroup 가이드 4종은 수치와 독립적으로 유효해야 P29 실현.
-6. **★ 조건 배타 조합 P17 7종은 매 스테이지 전수 체크 의무.** 단일 스테이지 위반 1건이라도 감지 시 Phase 즉시 중단 + PD 확인 (PD B 방식). 추후 발견되는 것보다 집행 초입 차단이 훨씬 저렴하다.
-7. **기존 SOT 맹신 금지 — "이전 문서에 쓰여 있으니까"는 근거가 아니다.** `스테이지난이도곡선_v1` §1의 "WorldMap_1~4 4개 그룹" 전제를 Phase 3 종결 문서·Phase 4 착수 가이드·지역 1 v1까지 무비판 계승한 결과 지역 1 v1 전면 폐기.
-8. **어뷰징 판정 솔루션은 기획팀이 "프레임워크·경계값 산출 방법론"까지만 책임.** 실 검증 로직은 서버팀 이관 (역할 경계 명확). 기획팀이 서버 검증 코드까지 설계하면 C11 개발 관점 원칙 침범.
-9. **병렬 호출 체계(기획팀장 + level + balance 병렬)는 청크 단위 독립 작업에 최적.** Day 11~14 레벨축·밸런스축을 병렬 집행한 결과 일정 단축 + 교차 검증 품질 확보. 단 의존 작업은 순차.
-10. **전문 에이전트 6종에 P24 기각안 필수화·P16 변경 이력 필수화는 조직 기억 축적의 핵심 인프라.** 기획 결정의 "왜 그렇게 결정했고 어떤 대안을 기각했는가"가 차기 프로젝트 의사결정에 직접 활용됨.
+1. **데이터 구조 실측 선행이 제1원칙.** 기존 문서의 "구간/그룹 레이블"을 데이터 구조 SOT로 착각해 산출물 전면 폐기 사건 발생.
+2. **Phase 범위 재정의는 PD 승인 영역**(C36). 팀장 단독 재정의 금지.
+3. **PD 확정 용어 변형·축약 금지**(C22). 임의 재매핑은 재작업 직접 원인.
+4. **재미 판단은 기획팀(P30), 수치·자원 판단은 개발팀(C11).** 충돌 시 PM·PD 에스컬레이션.
+5. **"설계 원칙 vs 임시 데이터" 분리가 자산 계승 핵심**(P29). 원칙·방법론은 프로젝트 독립적으로 유효해야 계승 가능.
+6. **기존 SOT 맹신 금지.** "이전 문서에 있으니까"는 근거 아님. 참조 시점 실측 재수행.
+7. **병렬 호출은 독립 청크에 최적**, 의존 작업은 순차.
+8. **P24 기각안·P16 변경 이력 필수화가 조직 기억 축적 인프라.**
 
 ---
 
@@ -36,263 +29,164 @@ sub_scope:
 
 ### 2-1. 데이터 구조·용어 관리
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| `스테이지난이도곡선_v1` §1에 "WorldMap_1~4 4개 그룹"을 SOT로 기재 | 초기 기획 단계에서 편의상 구간 분류 (입문·초반·중반·후반) | Unity Export CSV 실측 결과 실제 구조는 **WorldMap = 21개 지역** · "4개 그룹"은 기획 레이블일 뿐 데이터 구조 아님 | 기획 레이블(구간)과 데이터 구조(지역·스테이지)를 **명시적으로 분리 표기**. "4개 그룹"은 SOT 자격 없음 |
-| 후속 문서들(`Phase3_종결_설계체계_v1`·`Phase4_노드구성_착수가이드_v1`)이 위 SOT를 무비판 인용 | 기존 문서 재활용·일관성 유지 | 오해 계승 누적 → `Phase4_지역1_노드구성_v1` 전체를 "지역 1 = Stage 1~6 = 6개"로 설계 → **전면 폐기** | **기존 SOT 맹신 금지 (§1-4 룰)** 신설. 참조 시점 실측 재수행 의무 |
-| 기획 문서 상단에 "데이터 소스" 필드 부재 | 관행상 출처 기재 생략 | 어느 문서의 어느 수치가 언제 실측됐는지 추적 불가 | 기획 문서 상단 프론트매터에 **"데이터 소스: CSV명 (실측 YYYY-MM-DD)"** 필수화 |
-| 용어 혼선: "기획실·개발실"(구명칭) vs "기획팀·개발팀"(신명칭) 7개 기획 문서 112회 잔존 | 2026-04-16 조직 명칭 전환 공지 수령 후 기존 산출물 일괄 치환 누락 | plan-auditor 교차 검증에서 C5 정직성 위반 위험 지적. 신규 에이전트가 구 체계 오해 가능 | 조직 명칭 변경 시 **기획 산출물 전수 grep + 일괄 치환** 기획팀장 재량 집행 의무 (C22 용어 일관) |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| 기획 편의상 구간 레이블을 데이터 구조 SOT처럼 기재 | 초기 편의 | 실제 구조와 불일치 → 후속 문서 연쇄 폐기 | 기획 레이블과 데이터 구조 **명시 분리**. 레이블은 SOT 자격 없음 |
+| 후속 문서가 초기 SOT 무비판 인용 | 일관성 관행 | 오해 계승 누적 → 하위 산출물 전면 폐기 | **기존 SOT 맹신 금지**. 참조 시점 실측 재수행 의무 |
+| 기획 문서 상단 "데이터 소스" 필드 부재 | 관행 | 실측 시점 추적 불가 | 프론트매터에 **"데이터 소스: 파일명 (실측 YYYY-MM-DD)"** 필수 |
+| 조직 명칭 전환 시 구 명칭 잔존 | 일괄 치환 누락 | 감사에서 정직성 위반 위험 | 명칭 변경 시 **전수 grep + 일괄 치환** 의무 |
 
 ### 2-2. Phase 관리·범위 조정
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| Phase 3 초기 범위를 "Day 1~15+ 성장 요소 기여도 + 맵 패턴 실 배치 + v2 최종본"으로 광역 설정 | 한 번의 Phase에서 설계 + 실배치까지 끝내려는 욕심 | Day 11~14 완료 후 "현 스테이지 데이터 = 임시"라는 근본 문제 식별. 실 배치는 임시 데이터 기반이면 의미 제한적 | PD B안 수용으로 **Phase 3 = "설계 체계 확립"** 재정의 + **Phase 4 = "스테이지별 노드 구성"** 분리. Phase는 **결과물 성격**으로 구분 |
-| Day 8~10 이슈 1·3(카드 G1 풀빌드 +399%, 신성 빌드 확장성) 재조사 방향 검토 | 밸런스 완결성 확보 | PD A안 수용 "무시해도 될 문제" → 재조사 불요 · 간략화 종결 | 이슈 우선순위는 **PD 판단 선행** (C1 지시=승인). 기획팀이 "완결성"을 이유로 무한 확장하는 것은 C9(AI 조직 완성도 우선)와 충돌 가능 |
-| Day 11~14를 기획팀장 단독 순차 집행 | 맥락 유지 편의 | 레벨 관점(맵 구조) + 밸런스 관점(TTK·수치) 교차 검증 누락 우려 | Day 11~14부터 **level-designer + balance-designer 병렬 호출** 도입. 교차 검증 품질 확보 |
-| Day 15+ 7종 선택지를 "Phase 3 미완료 상태"로 잔존 우려 | 어중간한 종결 회피 | B안 수용 후 3분류 처리: 설계 원칙 성격 3종(Phase 3 종결 문서 §5 집약) + 임시 데이터 수치 3종(Phase 4 이관) + 완료 선언 1종 | 미완료 항목은 **분류·이관·완료 3분기**로 처리. "전부 이관" 또는 "전부 완료"의 단순화 금지 |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| Phase 범위 "설계 + 실 배치" 광역 설정 | 한 번에 끝내려는 욕심 | 임시 데이터 기반 실 배치 의미 제한 | Phase는 **결과물 성격**으로 구분. 재정의는 PD 승인 영역 |
+| "완결성" 명분 이슈 재조사 | 팀 완결성 욕구 | PD 판단 "무시해도 될 문제" 수용 | 이슈 우선순위는 **PD 판단 선행**. "완결성" 명분 무한 확장은 C9 오해 |
+| 팀장 단독 순차 집행 | 맥락 유지 | 전문 영역 교차 검증 누락 | 독립 청크는 **전문 에이전트 병렬 호출** |
+| 미완료 항목 "전부 이관/완료" 단순화 유혹 | 결정 편의 | 어중간한 종결 | **3분류 처리** (설계 원칙 집약·임시 데이터 이관·완료 선언) |
 
-### 2-3. ★ 조건·P17 배타 설계
+### 2-3. ★ 조건·배타 설계 (Prove-2-of-3 계열)
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 12개 조건 풀(C1·C2·C3·C6·C9·C12 + N1·N2·N3·N4·N5·N6) 전수 배치 시도 | 조건 다양성 극대화 | P17 배타 조합 7종 위반 다수 발생 가능성 (C2∧N2·C6∧N4·N5∧N6 등) | P17 배타 7종을 SKILL.md P17 SOT로 정식화. 스테이지별 슬롯2·슬롯3 배치 시 **7종 전수 체크** 의무 |
-| 입문 구간(Stage 1~6)에 C1∧C3·N3·C9 배치 검토 | 초기 난이도 다양화 | 입문 구간 이중 부담 과도 + 치명타 빌드 미형성 + C9 논리 불성립 | P17-4(입문 C1∧C3)·P17-6(입문 N3)·P17-5(C9∧단독/미등장 보스) 명문화. 입문은 **N1·C3·C6·C12·N1·N2·N4·N5·N6** 9종 중심 |
-| 42 슬롯(21 스테이지 × 슬롯2·3)에 대한 전수 체크 시트 부재 | 개별 스테이지 집중 | 전수 검증 누락 리스크 | `맵패턴_42슬롯_현황테이블_v1` 신설 + P17 전수 체크 시트 템플릿 제작 |
-| C9(보스 집중) 조건을 단독 보스·보스 미등장 스테이지에 배치 검토 | 조건 적용 유연성 | 논리 불성립 (단독 보스 = C9 자동 충족 → 조건 가치 소멸) | P17-5 명문화 + 3축 검증(조건 의미성·페이싱·재도전 유도) 완료 |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| 전체 조건 풀 전수 배치 | 다양성 극대화 | 배타 조합 위반 발생 | **배타 조합 SOT화(P17)** + 슬롯별 **전수 체크 시트** 의무 |
+| 입문 구간에 중고난이도 조합 배치 | 난이도 다양화 | 이중 부담 + 빌드 미형성 + 논리 불성립 | 입문은 **부담 낮은 조건 중심**. 전용 조합을 입문에 배치 금지 |
+| 전 슬롯 체크 시트 부재 | 개별 집중 관행 | 검증 누락 리스크 | **슬롯 현황 테이블 + 체크 시트 템플릿** 제작 |
+| 충족 불가 스테이지에 조건 배치 | 유연성 욕구 | 조건 가치 소멸 | **조건 의미성·페이싱·재도전 유도 3축 검증** |
 
-### 2-4. 밸런스·수치 관리
+### 2-4. 밸런스·수치 & 개발팀 협업
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 성장 요소 기여도(#16~#21)를 기획 가정치 기준으로 확정 | 초기 밸런스 빠른 설정 | Unity MCP EditMode UTF 14/14 실측 결과 가정치 대부분 범위 내 Passed지만 **일부(장비 세트 +70% → 실측 +71.46%)는 정확 일치 수준으로 보정** | 밸런스 확정 전 **Unity MCP 실측 선행** 의무. 기획 가정치는 "검증 전 임시"로 태그 |
-| 카드 G1 풀빌드 DPS 이론 +399%를 "밸런스 이슈"로 판정 | 상한 과도 우려 | PD A안 수용: "특화 빌드 피크치 + 신성 빌드 캐주얼 포지션"으로 수용 확정 | 이론 최대치와 실전 기댓값을 분리 관리. "극단 수치 = 항상 이슈"는 오해. 포지션 명시로 해결 |
-| 밸런싱 md 4종(`스테이지난이도곡선`·`밸런싱전략`·`전체테이블감사`·`빌드_조건_충돌점검`) 변경 이력 포맷 부재 | 초기 관행 | 변경 근거·시점 추적 불가 | 4종 하단에 **"변경 이력 (P16)"** 섹션 표준화. 필드: 일시/변경자/변경 필드/이전값→이후값/재미 근거/관련 PD 지시# |
-| 밸런스 수치 변경 요청을 자유 형식으로 개발팀 전달 | REQ 템플릿 부재 | 변경 배경·재미 근거·개발 관점 우려 누락 | `REQ-템플릿_밸런스수치.md` 9개 섹션 표준화 (식별·변경 필드·전후 수치·재미 근거(P30)·개발 관점 우려 예상(C11)·검증 방법·백업 이력(C6·P16)·기각안(P24)·응답 섹션) |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| 성장 요소 기여도를 가정치로 확정 | 빠른 설정 | 실측 후 수치 보정 필요 | **엔진 실측 선행** 의무. 가정치는 "검증 전 임시" 태그 |
+| 이론 최대치를 "이슈"로 판정 | 상한 우려 | "특화 빌드 피크 + 캐주얼 포지션" 수용 | 이론 vs 실전 기댓값 분리. 극단 수치 ≠ 항상 이슈 |
+| 변경 이력 포맷·REQ 템플릿 부재 | 관행 | 근거·우려·배경 누락 | **P16 변경 이력 6필드** + **REQ 9섹션**(식별·필드·전후·재미 근거·개발 우려·검증·백업·기각안·응답) |
+| 데이터 해석을 추측·특이값을 "오류"로 단정 | 빠른 진행·직관 | 실 로직 괴리 | **"코드 근거 질의" 패턴** + **특이값 개발 교차 검증**. 질의 시 참조 경로·라인 포함 |
+| 시스템 구조 미숙지 상태 결정·단방향 소통 관행 | 진행 우선 | 실 구조와 괴리·파일 증폭 | **구조 숙지 선행** + **같은 파일 `## 응답(YYYY-MM-DD)` append**. 3회 왕복 이상 PM 에스컬레이션 |
 
-### 2-5. 개발팀 협업·REQ 체계
+### 2-5. 역할 경계 (서버·시뮬)
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| REQ001 각성트리 퍼센트값(`'500%'` vs `'5'`) 해석 확인 | 밸런스 설계 전제 명확화 | 개발팀 응답: `table_base.Get_Value()` 동일 결과(5.0f) · 데이터 입력 오류·런타임 영향 없음 | 기획팀은 **"코드 근거 있는 데이터 해석 질의"** 패턴 확립. 추측 기반 수치 해석 금지 |
-| REQ002 장비 옵션 음수값(-20% 치명타 피해 등) 의미 확인 | 페널티 vs 보너스 vs 버그 구분 | 개발팀 응답: **의도적 트레이드오프** · 무기 MainOption2는 페널티 · `AttackCoolTime = -10%`만 공속 보너스 (예외) | 밸런스 설계 시 "음수 = 오류" 가정 금지. 데이터 필드 의미를 **개발팀 교차 검증**한 뒤 밸런싱 반영 |
-| REQ003 인장 장착수 제한 확인 | 성장 시스템 이해 | 개발팀 응답: 기본 슬롯 6개 · 진화 단계별 순차 개방 · 속성(Element) 매칭 제한 존재 | 성장 시스템 자체 구조를 **숙지 선행** (JSON 데이터 숙지 현황 별도 관리). 기획 결정은 실 코드 구조 전제 위에서만 |
-| 소통 허브 파일 1건 = 단방향 일회성 사용 | 관행 | 동기 협의 필요 건에서 파일 수 증폭 · 맥락 분산 | **같은 파일 내 `## 응답 (YYYY-MM-DD)` 섹션 append** 패턴 정착 (다회 왕복 기본값). 3회 왕복 이상 시 PM 에스컬레이션 |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| 검증 로직을 기획팀이 전수 설계 | 완결성 | C11 개발 관점 침범 | 기획팀은 **프레임·경계값 산출 방법론·스키마까지**. 실 로직은 서버·클라 이관 |
+| 안전 마진 일괄 단일값 / 시뮬 1회 확정 | 단순화·빠른 진행 | false positive/negative 실패·오차 흡수 불가 | **벡터별 마진 차등**(시간류·수치류·정수류) + **반복 시뮬 상위/하위 0.1% 값** 이론 극값. 절대 최대/최소 금지 |
+| "기획팀 엔진 MCP 직접 호출"안 | 자율성 | 학습 부담 + 경계 교란 | **"개발팀 러너 + 기획팀 요청 경로"**. 기획은 입출력 JSON 스펙·트리거만 이해 |
+| 보조 시뮬 즉시 폐기 / 시드 고정 미요구 | SOT 단순화·관행 | 교차 검증 상실·재현 불가 | **보조 시뮬 = 교차 검증용 부 SOT 유지** + **시드 고정 시 100% 동일 결과** 의무 |
 
-### 2-6. 어뷰징 판정 기획 → 서버 이관
+### 2-6. 병렬 호출·전문 에이전트·자체 감사·운영
 
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 어뷰징 판정 솔루션을 기획팀이 경계값 + 검증 로직 전수 설계 | 완결성 | C11 개발 관점 원칙 침범 우려 (서버 영역 로직 설계는 서버팀 책임) | 기획팀은 **"프레임워크·경계값 산출 방법론·스키마"**까지 · 실 검증 로직은 서버팀 이관. `2026-04-17_어뷰징판정_솔루션_기획서_v1.md` 7섹션(A 문제 정의 ~ F 서버팀 인계 · G 운영) 구조 정립 |
-| 안전 마진을 일괄 10%로 설정 시도 | 단순화 | false positive(정상 유저 오판정) · false negative(어뷰저 누락) 균형 실패 | 벡터 특성별 마진 차등: 클리어타임 **0.80**(프레임 드랍 흡수) · 획득 재화 **1.05**(반올림 흡수) · 랭킹 점수 **1.10**(업데이트 과도기) · 미션 카운트 **1.00**(정수) |
-| Unity MCP 시뮬 1회 결과로 경계값 확정 시도 | 빠른 진행 | 시뮬 자체 오차 흡수 불가 | **10,000회 반복 + 상위/하위 0.1% 값을 이론 극값**으로 채택. 절대 최대/최소 금지 |
-
-### 2-7. Unity MCP 시뮬 전환·기획 역할 경계
-
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| "기획팀이 Unity MCP 도구 직접 호출"안 검토 | Unity MCP 전환 직후 자율성 확보 | 학습 부담 과대 + C11·P30 역할 경계 교란 우려 | **"개발팀 러너 구축 + 기획팀 요청 경로"(B안)** 채택. 기획팀은 입력 JSON 스펙·결과 포맷·실행 트리거 3가지만 이해 |
-| Python 시뮬을 Unity MCP 전환 후 즉시 폐기 검토 | 단일 SOT 단순화 | 교차 검증 자산 상실 우려 | **Python 시뮬 = 교차 검증용 보조 SOT로 유지** · 아카이브 금지 (단 Unity MCP가 주 SOT) |
-| 시뮬 결정론(시드 고정 = 100% 동일 결과) 미요구 | 초기 관행 | 반복 실행 결과 재현 불가 · 밸런스 튜닝 근거 상실 | **시드 고정 시 100% 동일 결과** 의무화. `UnityEngine.Random` → 시드 기반 난수 전환 개발팀 REQ |
-
-### 2-8. 병렬 호출 · 전문 에이전트 체계
-
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 기획팀장 단독 집행 (초기) | 맥락 유지·일관성 | 전문 영역 깊이 부족 (레벨·밸런스·UX 등 전문성 확보 제한) | 전문 에이전트 6종(system·content·level·narrative·balance·ux-designer) 활용 체계 확립 |
-| 전문 에이전트 호출 시 공통 업무 규칙 누락 (초기) | 빠른 호출 | 규칙 누락 · 기록 의무 누락 | 전문 에이전트 6종 `.claude/agents/*.md` **"공통 업무 규칙" + "기록 의무" 섹션 신설**. 구 P20(일일보고) 잔존 제거 |
-| Day 11~14 순차 집행 vs 병렬 집행 판단 | 효율성 | 레벨 축과 밸런스 축은 **독립 작업** 확인 → 병렬 집행 | 독립 작업은 병렬 · 의존 작업은 순차 원칙 정착. 병렬 산출물은 기획팀장이 교차 검증 후 통합 |
-| 전문 에이전트 산출물 P24 기각안·P16 변경 이력 선택 작성 | 편의 | 조직 기억 축적 부족 | **P24 기각안 필드 필수화** (헌법 제1원칙 목표 2-B 직결) + P16 변경 이력 필수화. 기획팀장·plan-auditor 준수 감독 |
-
-### 2-9. 프로세스 고도화·조직 운영
-
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| PM 통합 허브 + 부서 독립 세션 하이브리드 구조 검토 | 독립성과 가시성 균형 | 독립 세션의 "결정 권한 범위"·HOLD 즉시 전파 등 5가지 보완점 식별 | P23(기획 결정 재량 범위) 신설: 팀장 재량·PM 확인·PD님 확인 3단계 명시 |
-| 문서 반영 시차(세션 갱신 전까지 다른 세션 변경 미인지) 대응 | Phase 3 HOLD 인지 실패 재발 방지 | UserPromptSubmit hook에 HOLD 파일 변경 감지 추가 · 프롬프트 N회마다 HOLD 재스캔 | 기획팀 2026-04-15 Phase 3 HOLD 인지 실패 실증 근거 → 조직 공용 방지 체계 구축 |
-| 세션 간 소통 부재(C13 위반) 대응 | 결정사항·노하우 세션 단절 | 소통 허브 "결정로그" 유형 추가 + 세션 종료 시 핵심 결정 3줄 요약 자동 산출 | 작업 수행 + 공유 등록이 별개 행위 → **작업 완료 즉시 공유 루틴 습관화** |
-| 완료 항목 잔류(완료된 안건이 미갱신 상태로 계속 보고) 대응 | 활성 테이블 오염 | PD 지시 로그 **활성·완료 아카이브 2분할** 구조(P19) + 완료 시 즉시 이동 의무(2026-04-18 강화) | 세션 갱신 시 활성 테이블만 스캔 → "완료된 업무가 진행중으로 보이는" 왜곡 차단 |
-
-### 2-10. 자체 교차 검증·감사
-
-| 시도한 방법 | 이유 | 결과 | 교훈 |
-|------------|------|------|------|
-| 기획팀 산출물 상호 중복·상충·불필요 검증 자체 수행 | 품질 확보 | 12개 기획 문서 역할 분리 확인 + 7개 문서 구 명칭 잔존 112회 식별 + 1건 경미(보존 유지) | **기획팀장 자체 교차 검증 + plan-auditor 병행 감사 2축 구조** 확립. 자기 시야(기획팀장) vs 제3자 시야(감사관) 차별화 |
-| PD 지시 로그 활성 지시의 산출물 경로 실존 검증 누락 | 관행 | 일부 경로 오류 발견 (2026-04-16 디렉터리 재구조 시 경로 미갱신) | 세션 갱신(P21) 시 **활성 지시 산출물 경로 실존 검증** 5-A 단계 신설. `scripts/verify_log_paths.sh` 활용 |
-| 전문 에이전트 기록 의무 일관성 점검 누락 | 관행 | 구 P20 문구 잔존 + P24·P26·P27 미반영 | plan-auditor 3축 감사 체계로 주기적 점검. 전문 에이전트 6종 파일 일괄 갱신 |
+| 시도 | 이유 | 결과 | 교훈 |
+|---|---|---|---|
+| 전문 에이전트 공통 규칙 주입 누락 / 순차·병렬 즉흥 판단 | 빠른 호출·편의 | 규칙·기록 의무 누락·독립 작업 순차 손실 | 에이전트 정의에 **"공통 규칙 + 기록 의무" 섹션** + **독립=병렬, 의존=순차** 원칙. 팀장 교차 검증 후 통합 |
+| 전문 에이전트 산출물 기각안·이력 선택 작성 | 편의 | 조직 기억 축적 부족 | **P24 기각안 필수 + P16 변경 이력 필수**. 팀장·plan-auditor 감독 |
+| HOLD 인지 실패 / 완료 항목 잔류 | 반영 시차·전이 누락 | HOLD 미인지 실증·진행중 오보 | UserPromptSubmit hook **HOLD 감지** + N프롬프트 재스캔. **활성·완료 2분할(P19)** + 완료 즉시 이동 |
+| 산출물 자체 검증 / PD 지시 경로 실존 검증 누락 | 품질·관행 | 구 명칭 잔존 등 식별·디렉터리 재구조 시 경로 오류 | **팀장 자체 + plan-auditor 2축 감사** + 세션 갱신 시 **활성 지시 경로 실존 검증**(`scripts/verify_log_paths.sh`) |
 
 ---
 
-## 3. BT 조직 착수 시 체크리스트 (EerieVillage 기획팀장 첫 세션)
+## 3. BT 조직 착수 체크리스트 (EerieVillage 기획팀장 첫 세션)
 
-### 3-1. 세션 0일차 — 조직 맥락 숙지
-- [ ] `공유/조직자산/시행착오_아카이브/기획_팀장_v1.md` (본 문서) Read 완료
-- [ ] `공유/조직자산/시행착오_아카이브/총괄_pm_general_v1.md` Read (PM과의 협업 맥락)
-- [ ] `공유/조직자산/시행착오_아카이브/개발_팀장_v1.md` Read (C11 개발 관점 경계 이해)
-- [ ] SKILL.md C22(용어 일관)·C23(허위 보고 금지)·C36(PM 재량 상한)·P17(배타 배치)·P24(기각안 필수)·P30(재미 우선) 원문 Read
-- [ ] `.claude/agents/` 하위 전문 에이전트 6종(system·content·level·narrative·balance·ux-designer) 정의 확인
+**3-1. 맥락 숙지**
+- 본 아카이브 + `총괄_pm_general_v1.md` + `개발_팀장_v1.md` Read
+- SKILL.md C22·C23·C36·P17·P24·P30 원문 Read
+- `.claude/agents/` 전문 에이전트 정의 확인
 
-### 3-2. 프로젝트 착수 1주차 — 데이터 구조 실측 선행
-- [ ] **EerieVillage Unity Export 경로 확인** (`paths.local.json`에 등록)
-- [ ] 주요 데이터 테이블(캐릭터·스테이지·몬스터·아이템·스킬 등) CSV/JSON 실측 Read
-- [ ] **"지역·스테이지·서브맵·노드" 같은 구조 단위 용어를 PD님과 확정** (수상한잡화점의 "WorldMap 4그룹" 사건 재발 방지)
-- [ ] 모든 기획 문서 상단에 **"데이터 소스: 파일명 (실측 YYYY-MM-DD)"** 필드 기본값화
-- [ ] 기존 기획 산출물 재활용 시 **실측 교차 검증 선행** (§1-5 의무)
+**3-2. 데이터 구조 실측 선행 (착수 1주차)**
+- EerieVillage Unity Export 경로 `paths.local.json` 등록
+- 주요 테이블 CSV/JSON 실측 Read (캐릭터·스테이지·몬스터·아이템·스킬·기믹)
+- **구조 단위 용어 PD 확정** (지역·스테이지·방·체크포인트 등 — 이전 용어 치환 사건 재발 방지)
+- 문서 상단 **"데이터 소스: 파일명 (실측 YYYY-MM-DD)"** 기본값화
+- 기존 산출물 재활용 시 **실측 교차 검증 선행**
 
-### 3-3. 기획 프레임워크 설계 단계
-- [ ] **재미 축 정의**(P30 강화): 차별화·재도전·성취·전략·몰입 중 핵심 1~2축 선정
-- [ ] **★ 조건 풀 정의** (수상한잡화점 12개 패턴 참조 가능)
-- [ ] **조건 배타 조합 사전 정의** (P17 체계 확장). 신규 조건 추가 시 배타 조합도 함께 정의
-- [ ] **성장 축 기여도 목표치 설정** + 설계 가정치 명시 → Unity MCP 실측 후 보정
-- [ ] **설계 원칙 vs 임시 데이터 분리 구조** 명시 (P29 자산 계승 전제)
+**3-3. 프레임워크 설계**
+- **재미 축 정의(P30)**: 차별화·재도전·성취·전략·몰입 중 핵심 1~2축
+- **★ 조건 풀 재정의**: 2D 플랫포머 퇴마 특성(피격 제한·기믹 활용·보스 패턴 회피·클리어 시간·수집 등) — 덱빌딩 조건 그대로 계승 불가
+- **배타 조합 사전 정의(P17 확장)**
+- **성장 축 기여도 목표치** + 가정치 → 엔진 실측 후 보정
+- **설계 원칙 vs 임시 데이터 분리 구조** 명시(P29)
 
-### 3-4. 수치 설계·밸런싱
-- [ ] **앵커 전투 시뮬 공식** 확립 (PC DPS·EHP·TTK 기본값)
-- [ ] **성장 5축 결합 공식** (카드 × 장비 × 각성 × 진화 × 인장 등 상응 요소)
-- [ ] **밸런싱 문서 변경 이력 섹션(P16)** 표준화 — 필드 6종(일시·변경자·변경 필드·이전값→이후값·재미 근거·관련 PD 지시#)
-- [ ] **REQ 템플릿(밸런스 수치 변경)** 9섹션 준수
+**3-4. 수치·밸런싱**
+- **앵커 전투 시뮬 공식** (플랫포머는 "생존 시간·피격률·클리어 시간·점프 효율" 등 장르 특화 지표)
+- **성장 축 결합 공식** · **P16 변경 이력 6필드** · **REQ 9섹션** 준수
 
-### 3-5. 개발팀 협업 루틴
-- [ ] **REQ 발행 시 "코드 근거 질의" 패턴**: 추측 금지, 질의 내용에 참조 경로·라인 번호 포함
-- [ ] **다회 왕복 시 같은 파일 `## 응답 (YYYY-MM-DD)` append**
-- [ ] 3회 왕복 이상 미합의 시 **PM 에스컬레이션**
-- [ ] Unity MCP 시뮬 요청 시 **입력 JSON 스키마(seed·stage_id·deck·growth_vars·max_turns) + 출력 JSON 스키마(clear·turns·final_hp_ratio·total_dmg·total_taken·potion_used) 명시**
+**3-5. 개발 협업·에이전트 호출**
+- **REQ "코드 근거 질의"** (추측 금지·경로·라인 포함) · 다회 왕복 시 **같은 파일 append** · 3회 왕복↑ **PM 에스컬레이션**
+- 엔진 시뮬 요청 시 **입출력 JSON 스키마 명시**
+- **독립=병렬 / 의존=순차**. 병렬 산출물 **팀장 교차 검증 후 통합**
+- 에이전트 프롬프트에 **P24 기각안·P16 변경 이력·데이터 소스 실측** 3요소 포함
 
-### 3-6. 전문 에이전트 호출 원칙
-- [ ] **독립 작업 = 병렬 호출** (level + balance + content 동시)
-- [ ] **의존 작업 = 순차** (목표 정의 → 노드 배치 → 배타 체크 → TTK → 고주의 → REQ)
-- [ ] 병렬 산출물 **기획팀장 교차 검증 후 통합**
-- [ ] 전문 에이전트 프롬프트에 **P24 기각안 필수·P16 변경 이력 필수·데이터 소스 실측** 3요소 포함
-
-### 3-7. Phase 관리
-- [ ] **Phase 범위 정의 = PD님 승인 영역** (기획팀장 단독 재정의 금지 — C36)
-- [ ] Phase 종결 시 **설계 원칙 집약 문서**(§5 패턴) + **원본 산출물 보존**(C14-5)
-- [ ] Phase 간 이관 시 **3분류 처리**(설계 원칙 집약·임시 데이터 이관·완료 선언)
-- [ ] Phase 종결 시 **누락 방지 체크리스트** (Day별 산출물 전수 확인 N/N)
-
-### 3-8. 자체 교차 검증
-- [ ] 주 1회 이상 **기획팀장 자체 감사**(불필요·중복·상충 3축) 수행
-- [ ] plan-auditor 3축 감사와 **자기 시야 차별화** (감사 중복 회피)
-- [ ] PD 지시 로그 **활성 지시 산출물 경로 실존 검증** (`scripts/verify_log_paths.sh`)
-- [ ] 완료 항목 **즉시 아카이브 이동** (P19 2분할 구조 준수)
+**3-6. Phase·자체 감사**
+- **Phase 범위 = PD 승인 영역**(C36). 종결 시 **설계 원칙 집약 + 원본 보존**(C14-5). 이관 시 **3분류 처리**. 종결 체크리스트 N/N
+- 주 1회 **팀장 자체 감사**(불필요·중복·상충 3축) + plan-auditor **자기 시야 차별화**
+- PD 지시 로그 **활성 경로 실존 검증** + 완료 즉시 아카이브 이동(P19)
 
 ---
 
-## 4. PM 보고 안건 (특이사항)
+## 4. PM 보고 안건 (BT 착수 특이사항)
 
-### 4-1. 데이터 실측 의무 룰 EerieVillage 적용 여부
-- **배경**: `기획팀_데이터_실측_의무_v1.md` 는 수상한잡화점 전용 프로젝트 룰. EerieVillage Unity 경로·데이터 체계가 다를 경우 **차기 프로젝트 전용 룰 재작성 필요**
-- **권장**: EerieVillage 첫 기획 작업 전에 동등한 룰 재작성 (데이터 실측·용어 정의·PD 확인 절차·기존 SOT 맹신 금지·기획 문서 재사용 선행 검증 5대 조항 계승)
-- **PD님 확인 필요**: EerieVillage 데이터 Export 경로·핵심 테이블 구조 확정 후 본 룰 정식화
+**4-1. 데이터 실측 의무 룰 EerieVillage 적용**
+- 이전 룰은 Unity 경로·데이터 체계 기반. EerieVillage 체계 상이 가능성
+- 권장: 첫 기획 작업 전 **동등 룰 재작성** (데이터 실측·용어 정의·PD 확인·기존 SOT 맹신 금지·재사용 선행 검증 5대 조항 계승). PD 확인: Export 경로·핵심 테이블 구조 확정 후 정식화
 
-### 4-2. 기획 산출물 삭제 시 "교훈 보존" 범위
-- **배경**: PD님 2026-04-21 지시 3번 "수상한잡화점 기획 산출물 삭제 + 교훈 보존". 본 아카이브 작성 후 원본 삭제 시점에 어떤 문서를 얼마나 보존할지 구체 범위 필요
-- **권장**: 본 아카이브(시행착오) + 핵심 방법론 문서(3성 조건 풀·P17 배타·TTK 산출 공식·Phase 3 종결 설계 체계 §5 5종 집약)만 재구성하여 `공유/조직자산/기획방법론/`에 별도 보존. 나머지 수상한잡화점 구체 수치·스테이지 설계는 삭제
-- **PD님 확인 필요**: "방법론 자산"과 "프로젝트 구체 기록"의 경계를 명시 지시
+**4-2. 장르 적합성 — Prove-2-of-3 재활용**
+- 덱빌딩 전용 Prove-2-of-3(★ 조건 2-of-3)의 플랫포머 적용 가능 여부 미확인
+- 권장: 첫 기획 세션에서 **장르 적합성 평가**. 부적합 시 재설계, 적합 시 프레임만 계승(조건 풀 장르 재정의). PD 확인: 코어 메커닉 확정 후
 
-### 4-3. EerieVillage 장르 적합성 — Prove-2-of-3 체계 재활용
-- **배경**: 수상한잡화점 = 덱빌딩 전투. EerieVillage = Unity 2D PlatformerMicrogame 기반 액션(추정). 덱빌딩 전용이었던 Prove-2-of-3 체계(★ 조건 2-of-3)가 플랫포머에 적용 가능한지 미확인
-- **권장**: EerieVillage 첫 기획 세션에서 **장르 적합성 평가**. 부적합 시 ★ 조건 체계 재설계 · 적합 시 Prove-2-of-3 그대로 계승 (조건 풀만 장르 맞춰 재정의)
-- **PD님 확인 필요**: EerieVillage 코어 메커닉 확정 후 판단
+**4-3. 전문 에이전트 6종 장르 맞춤화**
+- 현 6종은 덱빌딩 기준. 2D 플랫포머는 "물리·스테이지 기믹·히트박스·AI 패턴" 전문 영역 추가 필요 가능
+- 권장: 에이전트 정의 재검토, 필요 시 신설(예: `mechanic-designer`). PD 확인: 구성 변경은 C36 방향·원칙 수준 판정 가능
 
-### 4-4. 전문 에이전트 6종 → 프로젝트별 맞춤화 필요성
-- **배경**: 현 6종(system·content·level·narrative·balance·ux-designer)은 수상한잡화점 기준. EerieVillage는 **플랫포머 액션** 특성상 "물리·스테이지 기믹·히트박스" 등 전문 영역 추가 필요 가능성
-- **권장**: EerieVillage 착수 시 에이전트 정의 재검토. 필요 시 신규 전문 에이전트 신설 (예: `mechanic-designer` 플랫포머 기믹 전담)
-- **PD님 확인 필요**: 에이전트 구성 변경은 C36 방향·원칙 수준 판정 가능성 있음
-
-### 4-5. 어뷰징 판정 프레임워크 재활용 가능성
-- **배경**: 수상한잡화점 어뷰징 판정 기획서는 **"시뮬 이론 극값 기반 경계값 + 안전 마진 차등 + 서버 2계층 검증"** 프레임. 플랫포머 액션에도 재활용 가능 (점수·클리어타임·재화 벡터 공통)
-- **권장**: EerieVillage 서비스 준비 단계에서 해당 프레임워크 재활용 검토. 벡터는 장르 특화 재정의 (예: 점프 횟수·데미지 수치·플랫폼 부양 시간 등)
+**4-4. 어뷰징·검증 프레임워크 재활용**
+- 기존 프레임 "시뮬 이론 극값 + 안전 마진 차등 + 서버 2계층 검증"은 플랫포머에도 재활용 가능(점수·클리어타임·재화 벡터 공통)
+- 권장: 서비스 준비 단계 재활용, 벡터는 장르 특화 재정의(점프 횟수·피격 수·플랫폼 부양 시간 등)
 
 ---
 
-## 5. 참조 원본 파일 목록 (감사 재현 가능)
+## 5. 참조 원본 파일 목록 (삭제 전 감사 재현용)
 
-### 5-1. 핵심 방법론 문서 (Phase 3·4 설계 체계)
-- `프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md` — 설계 체계 집약 SOT
-- `프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md` — Phase 4 범위·흐름
-- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` — 지역 1 v2 (v1 폐기 후 재작성)
-- `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` — 폐기 버전 (재발 방지 참조)
-- `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` — 데이터 실측 5대 조항
-- `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` — 데이터 구조 SOT
-- `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` — Day 11~14 통합
-- `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` — Day 8~10 PD A안 수용
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` — 조건 풀 12개
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` — 사전 프레임
-- `프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md` — 42 슬롯 현황
-- `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` — 스테이지 구조 SOT
-- `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` — 목표·드래프트 가중치
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` — 28개 재검증 항목 추적
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` — 카드 분포·이슈
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` — 신성 빌드 22장
-- `프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md` — 3성 조건 배치
-- `프로젝트/수상한잡화점/기획/전체테이블감사_v1.md` — JSON 데이터 감사
-- `프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md` — 앵커 공식
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` — 재개 절차
-- `프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md` — 재검증 양식
+> 상세 수치·서술은 원본에서 재현. 원본 삭제 시점은 PD 지시에 따름.
 
-### 5-2. 개발팀 협업·REQ 응답
-- `공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md` (기획팀→개발팀)
-- `공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md`
-- `공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md`
-- `공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md` (개발팀→기획팀)
-- `공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md`
-- `공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md`
-- `공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md`
-- `공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md`
-- `공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md`
-- `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md`
+**5-1. 기획 방법론·설계 체계** (`프로젝트/수상한잡화점/기획/` 내)
+- Phase 시리즈: `Phase0_1_앵커전투시뮬레이션_v1`, `Phase2_카드임팩트측정_v1`, `Phase3_종결_설계체계_v1`, `Phase3_재개준비_체크리스트_v1`, `Phase4_노드구성_착수가이드_v1`, `Phase4_지역1_노드구성_v1`(폐기 참조용)·`_v2`
+- 데이터·SOT: `기획팀_데이터_실측_의무_v1`, `테이블_데이터_구조_재정비_v1`, `전체테이블감사_v1`, `재검증_템플릿_v1`
+- 맵·스테이지: `스테이지난이도곡선_v1`, `맵패턴_사전분석_v1`, `맵패턴_42슬롯_현황테이블_v1`, `재검증보고_맵패턴_v1`
+- 조건·빌드: `3성조건_12개_상세명세_v1`, `카드시너지축분석_v1`, `빌드_조건_충돌점검_v1`, `이슈1_3_무시확정_v1`
+- 밸런스: `밸런싱전략_v1`, `밸런싱문서_일관성점검_v1`
 
-### 5-3. Phase 3 중간 산출물 (기획팀→개발팀 경로)
-- `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md` — Day 2~3 앵커 재검증
-- `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` — Day 4~7 #16~#21 Unity MCP UTF 14/14
-- `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` — 밸런스 REQ 표준 템플릿
+**5-2. 개발 협업·REQ** (`공유/소통/완료/` 및 `기획팀→개발팀/`)
+- REQ001~003 질의·응답 6건 (`2026-04-14`·`2026-04-16` 계열)
+- 유니티 점검·하이브리드 구조·프로세스 고도화·Unity MCP 시뮬 검토
+- `REQ-템플릿_밸런스수치`, `재검증보고_Phase0_1_2_v1`, `Phase3_성장요소기여도_v2`
 
-### 5-4. 기획팀→PM 보고·자체 검증
-- `공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md`
-- `공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md`
-- `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md`
-- `공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md`
-- `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md`
-- `공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md`
+**5-3. PM 보고·자체 검증** (`공유/소통/기획팀→PM/`)
+- `2026-04-17_JSON_데이터_숙지_현황`, `_전수감사_자체교차검증_*`
+- `2026-04-20` Day8-10 종결·Day11-14 레벨·밸런스축·Phase3 병렬 요약
 
-### 5-5. 어뷰징 판정 기획 (기획 → 서버 이관)
-- `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md` — 7섹션 프레임워크
-- `공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md` — 서버팀 인계 상세
+**5-4. 어뷰징 기획→서버 이관** (`공유/소통/완료/2026-04-17`)
+- `어뷰징판정_솔루션_기획서_v1`, `서버개발자_업무지시서_최종본`
 
-### 5-6. 대화로그·조직 운영 기록
-- `공유/대화로그/수상한잡화점/2026-04-16.md`
-- `공유/대화로그/수상한잡화점/2026-04-17.md`
-- `공유/대화로그/수상한잡화점/2026-04-18.md`
-- `공유/대화로그/수상한잡화점/2026-04-20.md`
-- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` — 활성 #41·42·43·44·45 + 완료 아카이브 전체 (특히 #24·#31·#32·#33·#34·#35 품질 개선 계열)
-- `공유/일일보고/2026-04-15_기획실.md` — 구 P20 잔존 형식 (폐기됨, 계승 대상 아님)
+**5-5. 대화로그·감사**
+- `공유/대화로그/수상한잡화점/2026-04-16~20.md`
+- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
+- `공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md`, `_업무공유체계_점검_기획팀.md`
 
-### 5-7. 감사·검증 기록
-- `공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md` — pm-auditor 전수 감사 (기획팀 활성 지시 경로 실존 100% 확인)
-- `공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md` — 기획팀 자체 점검
-
-### 5-8. 메모리 (feedback)
-- `memory/org/feedback_pm_capability_underestimation.md` — PM 실측 가능 범위 축소 (기획팀 작업에도 경계·주의 영역)
-- `memory/org/feedback_requirement_framing.md` — 요구사항 4축 프레이밍 (목적·용도·범위·비목적)
-- `memory/org/feedback_resolved_agenda_unnecessary_reference.md` — 종결 안건 재언급 금지 (P28-8)
-- `memory/org/feedback_agenda_framing_duplication.md` — 안건 프레이밍 중복 (PM 재량·PD 결정 동일 안건 중복)
-- `memory/org/feedback_team_recording_quality.md` — 팀 기록 품질 점검
+**5-6. 메모리** (`memory/org/`, BT 신규 조직 합류 시 Read 권장)
+- `feedback_requirement_framing` (4축 프레이밍 — 기획 요구사항 정리 직접 활용)
+- `feedback_pm_capability_underestimation`, `_resolved_agenda_unnecessary_reference`, `_agenda_framing_duplication`, `_team_recording_quality`
 
 ---
 
-## 6. 마무리 — BT 조직 기획팀장에게
+## 6. 마무리 — BT 기획팀장에게
 
-본 아카이브는 **"무엇을 만들었는가"**가 아니라 **"왜 그렇게 결정했고 어떤 대안을 기각했는가"**의 기록이다. 수상한잡화점 프로젝트 기획팀은 다음 4가지 교훈을 반복 체험했다:
+본 아카이브는 **"무엇을 만들었는가"**가 아니라 **"왜 그렇게 결정했고 무엇을 기각했는가"**의 기록이다. 반복 체험한 4가지 교훈 요약:
 
-1. **데이터 실측 없는 기획은 모래 위의 집** — WorldMap 4그룹 사건이 증명
-2. **PD님 확정 용어의 변형 = 재작업의 직접 원인** — C22는 선택이 아닌 필수
-3. **설계 원칙과 임시 수치의 분리 = 차기 프로젝트 자산 계승의 필수 조건** — P29의 실천 방법
-4. **기획팀의 책임은 "재미"이지만 개발 관점·PD 방향·자원 효율과의 조율 없이는 실현 불가** — P30·C11·C36·C1의 네트워크
+1. **데이터 실측 없는 기획은 모래 위의 집** — 구간 레이블을 구조 SOT로 착각한 전면 폐기 사건
+2. **PD 확정 용어 변형 = 재작업 직접 원인** (C22 필수)
+3. **설계 원칙과 임시 수치의 분리 = 차기 프로젝트 자산 계승의 필수 조건** (P29)
+4. **기획 책임 "재미"는 개발·PD·자원 효율과의 조율 없이 실현 불가** (P30·C11·C36·C1 네트워크)
 
-EerieVillage 기획팀장은 이 아카이브를 **"이미 지나온 함정 지도"**로 활용하되, 장르 차이(덱빌딩 → 플랫포머)에 따른 차별화 재검토를 병행한다. 재미는 장르마다 다르지만, **재미를 설계하고 검증하고 기록하고 계승하는 방법론**은 조직 자산으로 계승 가능하다.
+본 아카이브를 **"지나온 함정 지도"**로 활용하되 **장르 차이(덱빌딩 전투 → 2D 플랫포머 퇴마)에 따른 차별화**를 병행한다. 재미 자체는 장르마다 다르지만, **설계·검증·기록·계승 방법론**은 조직 자산으로 계승 가능.
 
 ---
 
-*작성 완료: 2026-04-21*
-*BurningTimes 조직 자산 — 기획팀 통합 시행착오 아카이브 v1*
+*재압축: 2026-04-21 / BurningTimes 조직 자산*
diff --git a/프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md b/프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md
deleted file mode 100644
index 53824fe..0000000
--- a/프로젝트/수상한잡화점/개발/01_기획실_인수인계_v1.md
+++ /dev/null
@@ -1,179 +0,0 @@
-# 수상한 잡화점 — 기획실 인수인계 문서
-
-> **인수일**: 2026-04-14
-> **목적**: 개발실 업무 착수 전 기획실 선행 작업 인수인계 (코어 룰 C10 준수)
-> **원본 출처**: 기획실 CLAUDE.md, `기획실/밸런싱/수상한잡화점/` 6개 문서, `기획실/.cache/` 3개 시뮬레이터
-
----
-
-## A. 프로젝트 기본 정보
-
-- **장르**: 덱빌딩 로그라이크 (Slay the Spire, Balatro 류)
-- **핵심 재미**: 카드 드래프트 → 조합 발견 → 빌드 폭발
-- **플레이 템포**: 초반 3~5분 / 중반 5~10분 / 후반 10~20분
-- **철학**: 인게임 경험 > 아웃게임 스펙
-- **소프트 론칭 목표**: 2026년 6~7월
-
-## B. 게임 시스템
-
-### PC 기본 스탯 (앵커: PC6001)
-| 항목 | 값 |
-|------|-----|
-| ATK | 1~4 (평균 2.5) |
-| 쿨타임 | 2.4초 |
-| HP | 58 (+보호막 6 = 유효HP 64) |
-| 회피 | 근접/원거리 각 5% |
-| 치명타 | 확률 2.6% / 피해 150% |
-| **기본 DPS** | **1.05** |
-
-### 몬스터 풀 (MonsterList.json, 248체)
-- 1xxxx: 183체 일반 / 2xxxx: 5체 특수 / 7xxxxx: 24체 Area7 / 8xxxxx: 36체 Area8
-- 타입: Normal_Melee, Normal_Range, Boss_Melee, Boss_Range
-
-### 전투 메커닉
-- **노드당 배치**: 전열/중열/대기열 3행
-- **터치 방어**: 다음 1회 피해 50% 감소 (정확한 쿨다운은 **개발 확인 필요**)
-- **노드 클리어 목표**: ≤30초
-
-### 덱빌딩
-- **획득**: 레벨업 시 3개 선택지 중 1개 선택 (1런 = 약 19회)
-- **가챠 없음**: 311장 전카드 수집
-- **등급 분포/드래프트 확률**:
-
-| 등급 | 가중치 | 확률 | 1런 기대 | 풀 사이즈 |
-|------|--------|------|---------|----------|
-| G1 | 1000 | 66.2% | 12.6장 | 112장 |
-| G2 | 300 | 19.9% | 3.8장 | 73장 |
-| G3 | 150 | 9.9% | 1.9장 | 51장 |
-| G4 | 50 | 3.3% | 0.6장 | 43장 |
-| G5 | 10 | 0.66% | 0.1장 | 32장 |
-
-- **G1~G2가 1런 핵심**, G4~G5는 럭 기반 빌드 설계
-- **카드 효과 수정 규칙**: `e_CardType` 변경 **금지**, 수치만 조정
-
-## C. 데이터 테이블 (76개 JSON)
-
-**SOT 경로**: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/`
-
-### 핵심 그룹
-- **전투**: PCList, MonsterList, GlobalValue, MonsterPatternList, ApprearMonsterPattern
-- **플로우**: BattleLevelUp, CreateMapConfig, RandomPatternConfig, WorldMapConfig, ApprearBossPattern, NodeTypeConfig
-- **카드**: CardList(311), CardGradeConfig, CardPoolConfig
-- **성장**: PCLevelUp, PcLevelUpEvolution, SkillTree/Tier, EquipmentList, SetEquipmentList, FunctionalityList, AwakenList, EvolutionList
-- **경제**: GoodsList, StoreGoods, RewardList, ShopConfig, PackageConfig, SeasonPassConfig
-
-### 발견된 이상 신호
-- **Stage 4→5, 6→7, 16→17**: 보스 내구도 급증
-- **보스 재사용**: 10016(흑기사3) 3회, 10019(레드드래곤3) 3회
-- **서브맵 이상**: Stage 7(4개), 16(3개)이 월드 시작인데 짧음; Stage 19~20은 9개 + 보스 3체
-
-## D. 밸런싱 분석 결과 (Phase 2 완료)
-
-### 앵커 포인트 시뮬레이션
-- PC vs 몬스터 1마리: TTK 5.7s, 안정적 ✓
-- PC vs 몬스터 4마리: 터치 방어 활용 시 생존 ✓
-- PC vs 보스10001: TTK 33.3s, 터치 방어로 생존 ✓
-- PC vs 보스10002: 카드 0장 사망 ❌ → 5~6장 획득 전제
-
-### 카드 임팩트 (TTK 감소)
-| 카드 수 | TTK | 감소율 |
-|--------|-----|--------|
-| 0장 | 5.7s | 기준 |
-| 5장 | 3.1s | **-45%** ✓ |
-| 19장(풀) | 1.3s | -77% |
-
-### 이슈 (HIGH)
-- **DPS 기여도 과도**: G1 풀빌드 DPS 기여 목표 +80~120% 대비 실측 **+399%** → Phase 3에서 성장 요소 통합 후 재검토
-
-### 10개 빌드 아키타입
-1. 신성 폭격 (G1:11)
-2. 보호막-생존 (G1:22)
-3. 처치 연쇄 (전 등급 균분, **가장 시너지 뚜렷**)
-4. 치명타 (G4:11, G5:8, 럭 기반)
-5. 원거리-회피
-6. 물약 특화 (G5:7, ★ 조건 충돌 해결됨)
-7. 첫타 버스트
-8. 번개/CC
-9. 탐험-경제 (G1 편중)
-10. 미사일
-
-## E. 시뮬레이터 구현 현황
-
-**위치**: `C:/Users/PC/Documents/BurningTimes/기획실/.cache/` (Python 3개)
-
-### 구현됨
-- ✓ 전투 루프 (PC vs 몬스터, 0.1초 스텝)
-- ✓ 노드 생성 (전열/중열/대기열)
-- ✓ 터치 방어 (50% 감소)
-- ✓ 회피
-- ✓ 레벨업 곡선
-- ✓ 카드 효과 (**DPS/EHP 단순 합산**으로만)
-- ✓ 다중 노드 시뮬레이션 + 캠프 힐링
-
-### 미구현
-- ❌ 각성/진화/장비/세트장비/인장 효과
-- ❌ 카드 효과 **시너지 로직** (선형합만 사용)
-- ❌ 난이도 모드 패널티
-- ❌ ★1/★2/★3 판정 로직
-- ❌ 실제 드래프트 확률 (균등 분포 사용 중)
-
-### 정확도 미해결
-- 터치 방어 쿨다운 메커닉 미확인
-- 노드 몬스터 배치 실제 비율 미확인
-- 카드 시너지 실제 구현과의 괴리
-- 방어/회피 판정 순서 미확인
-
-## F. 결정된 규칙
-
-- 카드 효과 종류 변경 금지, 수치만 조정
-- 신규 카드 추가는 PD 승인 필수
-- 밸런싱 제안 형식: 현재값 → 제안값 → 근거
-- 유저 세그먼트별 영향도 병기
-
-### ★ 조건 체계 (PD 확정 A안, 2026-04-14)
-- Prove-2-of-3 체계 전면 개편
-- 슬롯 2 매칭: 고정(사전 지정)
-- 조건: 유저가 컨트롤 가능한 것만
-
-### 성장 기여도 목표 (Phase 3 대상)
-| 요소 | 목표 |
-|------|------|
-| 카드 풀빌드 | +80~120% |
-| 세트 장비 | +60~80% |
-| 각성 만렙 | +40~60% |
-| 진화 6★ | +30~50% |
-| 일반 장비 | +20~40% |
-| 인장 5★ | +15~30% |
-
-### 스테이지 난이도 구간
-| 구간 | Stage | 요구 |
-|------|-------|------|
-| 입문 | 1~2 | G1만으로 ★1 가능 |
-| 초반 | 3~4 | 보통 |
-| 중반 시작 | 5~6 | 약간의 성장 필요 |
-| 중반 심화 | 7~12 | 각성+장비 필수 |
-| 후반 진입 | 13~16 | 장비 맞추기 필수 |
-| 최종 | 17~21 | 세트 장비+인장 |
-
-## G. 미해결 이슈
-
-### G-1. 기획이 개발 확인을 기다리는 항목
-- Q-P1: 터치 방어의 정확한 메커닉 (쿨다운, 유지 방식)
-- Q-P2: 노드당 몬스터 배치 패턴 (전열/중열 실제 비율)
-- Q-P3: 보스10002 클리어 가능성 (카드 5~6장 상태)
-
-### G-2. Phase 3에서 수치화 예정
-- 각성/진화/장비/세트/인장의 스탯 곡선과 기여도
-
-### G-3. 개발실 연동 요청 목록 (기획실이 예상하는 요청)
-- 전투 시스템 코드 리뷰 (`/게임플레이`)
-- 데이터 테이블 구조 확인 (`/클라이언트팀장`)
-- 각성/진화 스탯 테이블 공개 (`/클라이언트팀장`)
-- UI 기획 검토 (`/ui-ux`)
-
-## 참조 경로
-- 원본 CLAUDE: `C:/Users/PC/Documents/BurningTimes/기획실/CLAUDE.md`
-- 밸런싱 문서: `C:/Users/PC/Documents/BurningTimes/기획실/밸런싱/수상한잡화점/`
-- Python 시뮬: `C:/Users/PC/Documents/BurningTimes/기획실/.cache/`
-- 데이터 SOT: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/`
-- Unity 프로젝트: `D:/BurningTimes/FilGoodBandits/DeckBuilding/`
diff --git a/프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md b/프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md
deleted file mode 100644
index 9e183ab..0000000
--- a/프로젝트/수상한잡화점/개발/02_개발자관점_점검_v1.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# 수상한 잡화점 — 개발자 관점 점검
-
-> **작성일**: 2026-04-14
-> **목적**: 기획실 인수 내용에 대해 개발자 관점(C11)에서 보완/추가 확인이 필요한 사항 도출
-> **판단 기준**: 자원 효율성 / 코드 구조 직관성 / 코드 범용성
-
----
-
-## 📌 발견 요약
-
-기획실은 **게임 수치·밸런싱 관점**에서 프로젝트를 완전히 파악했으나, **코드·아키텍처 관점의 공백**이 존재한다. 개발실이 추가로 확인·보완해야 할 항목은 아래 12개다.
-
-우선순위: 🔴 즉시 필요 / 🟡 Phase 3 착수 전 / 🟢 상시 점검
-
----
-
-## 1. 시뮬레이터 이원화 문제 🔴 → 🟡 해소 착수
-
-> **업데이트 (2026-04-14)**: PD님 지시로 기획실 Phase 3 HOLD 되었으며, 본 이슈 해소를 최우선 작업으로 착수. 상세 계획: `07_시뮬레이터_이원화_해소_착수계획_v1.md` **(→ 2026-04-17 아카이브됨, Unity MCP 전환 / [`시뮬레이터/01_아키텍처_v1`](../시뮬레이터/01_시뮬레이터_아키텍처_v1.md) 참조)**
-
-### 현황
-- 기획실은 Python으로 3개 시뮬레이터 구현 (`battle_sim.py`, `full_stage_sim.py`, `stage_sim_v2.py`)
-- Unity에는 C#으로 실제 전투 로직이 구현되어 있을 것으로 추정 (미확인)
-- **Python 시뮬과 Unity C# 구현이 별개로 존재** → 이원화 리스크
-
-### 개발자 관점 문제
-- **[자원 효율성]** 동일 로직을 두 언어로 유지 = 유지비 2배, 괴리 발생 시 밸런싱 신뢰도 붕괴
-- **[코드 직관성]** 기획이 시뮬 수정 → 개발이 Unity 수정 → 재시뮬 검증 → 괴리 발견의 무한 루프 위험
-- **[범용성]** 다른 프로젝트에도 이 문제 반복 발생
-
-### 권장 조치
-- **Option A**: Unity 전투 코드를 Headless로 추출 → CLI에서 `dotnet` 실행 → 시뮬레이터를 C#으로 일원화
-- **Option B**: Python 시뮬을 "참조 구현"으로 두고 Unity와 자동 동기화 검증 테스트 작성
-- **담당**: `/게임플레이` + `/qa` 합동
-
----
-
-## 2. 데이터 테이블 로딩·캐싱 구조 🟡
-
-### 확인 필요 항목
-- 76개 JSON을 **언제·어디서 로드**하는가? (앱 시작 / 씬 진입 / 필요 시)
-- **Addressable** 사용 중인가, `Resources.Load`인가, `StreamingAssets`인가?
-- 메모리 상주 크기 총합은?
-- **핫 리로드**(기획 수치 변경 시 재빌드 없이 반영) 가능한가?
-
-### 개발자 관점 문제
-- **[자원 효율성]** 76개 전부 메모리 상주 시 저사양 기기 이슈 가능
-- **[코드 직관성]** 테이블 조회 API가 일관된 패턴인가 (`TableManager.Get<CardData>(id)` 같은 통일 인터페이스)
-- **[범용성]** 이 로딩 시스템이 `BurningTimesCore`에 있는가, 프로젝트 코드에 있는가? → 후자라면 범용화 필요
-
-### 담당
-- `/클라이언트팀장` (구조 파악)
-- `/최적화` (메모리 측정)
-
----
-
-## 3. 카드 효과 311장 구현 방식 🔴
-
-### 확인 필요 항목
-- 311장이 **데이터 드리븐** (효과 타입 enum + 파라미터)인가, 카드별 개별 스크립트인가?
-- `e_CardType`이 **enum인지 string key인지**
-- **시너지 계산**(처치 시 경험치 추가 × 경험치 비례 데미지 보너스 같은 상호작용)이 어떻게 구현되어 있는가?
-- 신규 카드 추가 시 **코드 수정 필요 여부**
-
-### 개발자 관점 문제
-- **[코드 직관성]** 카드별 스크립트 311개는 유지보수 불가능 수준 → 데이터 드리븐 강제
-- **[범용성]** 카드 효과 시스템이 **다음 덱빌딩 프로젝트에 재활용 가능한 범용 모듈**이 되어야 함
-- **[자원 효율성]** 시너지 체크를 매 프레임 계산하면 GC·CPU 오버헤드 → 이벤트 기반 구조 필요
-
-### 핵심 판단 질의
-> **"신규 카드 추가가 JSON 한 줄 수정으로 끝나는가?"**
-> 이 질문의 답이 "아니오"면 아키텍처 리팩토링 대상
-
-### 담당
-- `/게임플레이` (구현 방식 파악)
-- `/클라이언트팀장` (범용성 리뷰)
-
----
-
-## 4. 터치 방어 / 회피 메커닉의 SOT 불일치 🔴
-
-### 현황
-- 기획문서: "다음 공격 1회 피해 50% 감소" — **쿨다운 미확인**
-- Python 시뮬: 단순 50% 감소로 구현
-- Unity 실제 코드: 미확인
-
-### 개발자 관점 문제
-- **[코드 직관성]** 기획-시뮬-실코드 3자가 다른 동작 → 버그의 온상
-- **메커닉 SOT는 "실제 Unity 코드"여야 함** — 기획·시뮬은 이를 참조해야 함
-
-### 권장 조치
-1. `/게임플레이`가 실제 Unity 구현을 읽고 정확한 동작 문서화
-2. 해당 문서를 기획실에 전달 (`공유/개발실→기획실/`)
-3. Python 시뮬을 실제 동작에 맞춰 동기화
-
----
-
-## 5. 결정론 / 재현성 (시뮬레이터 신뢰도) 🟡
-
-### 확인 필요 항목
-- 전투 로직에 **랜덤**(회피, 치명타, 드롭) 사용
-- 시뮬이 **동일 시드**로 동일 결과를 내는가?
-- Unity 실제 게임도 **재현 가능한 시드 시스템**이 있는가?
-
-### 개발자 관점 문제
-- **[코드 직관성]** 재현 불가능한 버그는 디버깅 지옥
-- **[QA 자동화]** 시드 기반 리플레이 없으면 회귀 테스트 자동화 불가
-
-### 담당
-- `/게임플레이` + `/qa`
-
----
-
-## 6. BurningTimesCore 범용 라이브러리 내용 파악 🟡
-
-### 확인 필요 항목
-- `BurningTimesCore.Runtime.csproj`, `BurningTimesCore.Editor.csproj` 존재 확인됨
-- **이 코어에 무엇이 들어있는가?** (UI 프레임워크, 데이터 테이블, 네트워크, 세이브 시스템 등)
-- 수상한 잡화점 코드와 **명확히 분리**되어 있는가?
-
-### 개발자 관점 문제
-- **[범용성]** 코어가 명확히 분리되면 다음 프로젝트에서 그대로 재활용 가능 → 개발 가속
-- **[코드 직관성]** 코어에 프로젝트 특수 로직이 섞이면 코어 오염
-
-### 판단 포인트
-> **"이번에 만드는 덱빌딩 시스템의 어느 레벨까지가 코어(다음 프로젝트 재활용)이고, 어느 레벨부터가 프로젝트 전용인가?"**
-
-### 담당
-- `/개발실장` (경계 설계)
-- `/클라이언트팀장` + `/서버팀장` (현황 조사)
-
----
-
-## 7. PlayFab / Firebase 서버 연동 범위 🟡
-
-### 확인 필요 항목
-- `PlayFab.csproj` 존재 — **어디까지 PlayFab이 처리**하는가? (인증, 클라우드스크립트, 리더보드, 경제, 결제)
-- Firebase 용도 (Analytics? Crashlytics? Remote Config?)
-- **서버 권위**로 처리되는 로직 vs **클라이언트 권위** 로직 경계
-
-### 개발자 관점 문제
-- **[치트 방지]** 인게임 결과가 클라 계산이면 해킹 가능 → 서버 권위 필요 영역 식별
-- **[자원 효율성]** 모든 액션을 서버로 보내면 통신 폭증 → 배치 전략 필요
-- **[범용성]** PlayFab/Firebase 의존도가 지나치면 서비스 이전 시 락인
-
-### 담당
-- `/서버팀장` (아키텍처 파악)
-- `/백엔드` (연동 포인트 파악)
-
----
-
-## 8. 저장 데이터 / 세이브 구조 🟡
-
-### 확인 필요 항목
-- 런 진행 상태 저장 방식 (인게임 도중 저장/복구 되는가?)
-- 아웃게임 성장 데이터 저장 위치 (로컬 PlayerPrefs? PlayFab 서버?)
-- **치트 방지**를 위한 암호화 / 서명 여부
-- 데이터 마이그레이션 전략 (구버전 세이브 → 신버전 호환)
-
-### 담당
-- `/서버팀장` (세이브 전략)
-- `/db` (데이터 구조)
-
----
-
-## 9. 모바일 성능 예산 미설정 🟢
-
-### 현황
-- 기획은 "노드 클리어 ≤30초" 같은 **게임 템포 예산**만 정의
-- **기술 예산**(프레임레이트 목표, 메모리 상한, 드로우콜 한계, 빌드 사이즈 상한) 미정의
-
-### 개발자 관점 문제
-- **[자원 효율성]** 예산 없으면 최적화 기준 없음 → "일단 만들고 나중에 최적화" 안티패턴
-
-### 권장
-- `/최적화`가 타겟 디바이스별 성능 예산 수립
-- 예: 저사양(Galaxy S10): 30fps / 중사양(S22): 60fps / 메모리 1.5GB 상한 / 드로우콜 100 이하
-
-### 담당
-- `/최적화` + `/개발실장`
-
----
-
-## 10. 데이터 테이블 무결성 검증 자동화 🟢
-
-### 현황
-- 기획실 G-5에 "FK 무결성 검증, 스탯 범위 이상 탐지" 요청 언급됨
-- 76개 테이블 간 참조 무결성(MonsterID, CardID, RewardID 등) 검증 도구 필요
-
-### 개발자 관점 판단
-- **[코드 범용성]** 이 검증 시스템은 **모든 프로젝트 공통 필요 기능** → `BurningTimesCore`에 범용 툴로 넣을 것
-- **[자원 효율성]** CI/CD에 자동 연결되면 기획 데이터 실수 조기 차단
-
-### 담당
-- `/qa` (검증 규칙 정의)
-- `/devops` (CI 연동)
-- 범용화 판단: `/클라이언트팀장`
-
----
-
-## 11. VFX / 이펙트 범용성 🟢
-
-### 확인 필요 항목
-- 신성 / 번개 / 치명타 / 시체 폭발 등 카드 효과별 VFX가 **카드 효과 시스템과 결합**되어 있는가, **파라미터로 분리**되어 있는가?
-- 새 카드 추가 시 VFX 새로 만들어야 하는가, 기존 VFX를 파라미터로 커스터마이즈 가능한가?
-
-### 개발자 관점 문제
-- **[범용성]** VFX가 파라미터화되면 다음 프로젝트 재활용 + 신규 카드 생산성 증대
-- **[자원 효율성]** 중복 VFX가 텍스처·메모리 낭비
-
-### 담당
-- `/테크아트`
-
----
-
-## 12. 빌드 파이프라인 / CI 현황 🟢
-
-### 확인 필요 항목
-- Unity Cloud Build / Jenkins / GitHub Actions 중 어떤 CI 사용 중?
-- Android/iOS 빌드 자동화 수준
-- 데이터 테이블 빌드 자동화 (xlsx → JSON 변환 자동화 여부)
-- 테스트 빌드 배포 경로 (TestFlight, Internal Testing 등)
-
-### 담당
-- `/devops`
-
----
-
-## 📋 개발실 Phase 0 작업 제안 (선행 숙지)
-
-기획실의 Phase 3 작업(성장 요소 기여도)이 시작되기 **전에** 개발실이 완료해야 할 숙지 작업:
-
-### Phase 0-A: 코드 전반 매핑 (3 영역 병렬)
-
-| 작업 | 담당 | 산출물 |
-|------|------|--------|
-| Unity 프로젝트 구조 · 어셈블리 의존성 파악 | `/클라이언트팀장` | `03_Unity프로젝트_구조.md` |
-| BurningTimesCore vs 프로젝트 코드 경계 파악 | `/개발실장` | `04_코어_범용성_분석.md` |
-| 서버 연동 포인트 (PlayFab·Firebase) 파악 | `/서버팀장` | `05_서버연동_현황.md` |
-
-### Phase 0-B: 핵심 로직 검증 (🔴 우선순위)
-
-| 작업 | 담당 | 산출물 |
-|------|------|--------|
-| 전투 시스템 코드 리뷰 + 터치방어·회피 SOT 확정 | `/게임플레이` | `06_전투시스템_SOT.md` |
-| 카드 효과 311장 구현 방식 파악 | `/게임플레이` | `07_카드시스템_아키텍처.md` |
-| 데이터 테이블 로딩·캐싱 구조 파악 | `/클라이언트팀장` | `08_데이터로딩_구조.md` |
-
-### Phase 0-C: 기획 요청 사전 대응
-
-| 작업 | 담당 | 산출물 |
-|------|------|--------|
-| 기획실 Q-P1/P2/P3 질문에 대한 답변 준비 | `/게임플레이` | `공유/개발실→기획실/` 응답서 |
-| 시뮬레이터 일원화 방안 수립 | `/게임플레이` + `/qa` | `09_시뮬레이터_전략.md` |
-
----
-
-## 📚 교훈 기록 (개발실 로컬)
-
-> **작성 시점**: 2026-04-14 (PD님 지시로 P18 신설과 연계)
-
-### L-1. 설계 문서 누락 재발 방지
-- **발생 사실**: 본 문서에서 `06_신규코어_설계안_v1.md`를 참조하였으나 실제 파일이 부재한 상태로 존재 (`05_서버연동_현황_v1.md`도 동일 참조 보유)
-- **원인**: 설계 결정사항(기존 BurningTimesCore 소유권 전환 → 신규 코어 제작 결정)을 **참조 표기만 하고 본문 작성 누락**
-- **재발 방지 조치**:
-  1. 공통 규칙 **P18 (설계 문서화 의무)** 신설됨 — 참조된 설계 문서는 반드시 실제 존재
-  2. 문서 간 참조 링크가 추가될 때 **해당 파일의 존재 여부를 즉시 확인**하는 습관 정착
-  3. 설계 결정사항은 회의록·구두·요약이 아닌 **전용 설계 문서**로 반드시 명문화
-  4. **팀장급**은 자기 팀 산출물의 교차 참조 무결성을 주기적으로 점검
-- **연관**: `06_신규코어_설계안_v1.md` (본 교훈을 계기로 작성됨), 공통 규칙 §교훈 [2026-04-14] 항목
-
-### L-2. 시뮬레이터 이원화 해소 착수 (Phase 3 HOLD 해제 조건)
-- **발생 맥락**: 본 문서 §1에서 지적한 Python·C# 이원화 상태가 기획실 Phase 3 (성장 요소 기여도 설정) 착수를 막는 블로커로 승격
-- **조치**: `07_시뮬레이터_이원화_해소_착수계획_v1.md` 작성하여 Unity C# 로직 Headless 추출 방향으로 일원화 추진
-- **교훈**: **이원화는 초기에 차단해야 한다** — 누적되면 밸런싱 신뢰도 붕괴 + 유지비 2배 + 불일치 조용히 축적. C11 관점에서 "동일 로직 이중 유지"는 자원 효율성·직관성·범용성 모두 위배
-
----
-
-## 💡 개발자 관점에서의 최종 판단
-
-기획실이 제공한 정보는 **수치·밸런싱 레벨에서는 훌륭**하나, 개발팀이 실제 작업에 착수하기 위해서는 **코드 아키텍처 정보**가 턱없이 부족합니다.
-
-**지금 당장 기획 요청(Phase 3) 업무를 받아도 제대로 처리할 수 없는 상태**이며, 위 Phase 0 작업(특히 🔴 항목)을 선행 완료해야 합니다.
-
-또한 C11에 따라 개발실은 다음 원칙을 유지합니다:
-- **시뮬레이터 일원화** — 동일 로직 이중 유지 거부
-- **카드 시스템 데이터 드리븐 강제** — 카드당 스크립트 금지
-- **코어 분리** — BurningTimesCore에 들어갈 범용 기능과 수상한 잡화점 전용 로직 명확히 구분
-- **성능 예산 먼저** — "일단 만들고 나중에 최적화" 금지
-
-이상이 개발자 관점의 점검 결과입니다.
diff --git a/프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md b/프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md
deleted file mode 100644
index 132d01e..0000000
--- a/프로젝트/수상한잡화점/개발/03_Unity프로젝트_구조_v1.md
+++ /dev/null
@@ -1,178 +0,0 @@
-# Unity 프로젝트 구조 분석 — 수상한 잡화점 (DeckBuilding)
-
-> **작성일**: 2026-04-14
-> **조사 경로**: `D:/BurningTimes/FilGoodBandits/DeckBuilding/`
-> **목적**: C11(개발자 관점) 점검을 위한 코드 구조 전수 파악
-
----
-
-## 기본 정보
-
-| 항목 | 값 |
-|------|-----|
-| **Unity 버전** | 6000.0.67f1 (LTS, Unity 6 최신) |
-| **타겟 플랫폼** | Android(주), iOS, Windows 에디터 |
-| **스크립팅 백엔드** | IL2CPP (Android) |
-| **API 호환성** | .NET Standard 2.1 |
-| **총 코드량** | ~300 C# 스크립트 (게임 256 + 툴 42) |
-| **솔루션 프로젝트** | 13개 .csproj |
-
-## 어셈블리 구성 (asmdef 10개)
-
-**핵심 특징**: Assembly-CSharp(게임 로직 본체)에는 **asmdef가 없음** → 평탄한 단일 어셈블리에서 컴파일.
-
-### ThirdParty 격리
-- `PlayFab.asmdef`, `PlayFabSdkEditor.asmdef`, `PlayFabEditorExtensions.asmdef`
-- `ACTk.Runtime.asmdef` (+Editor, Examples 3개) — AntiCheatToolkit
-- `MCPForUnity.Runtime.asmdef` (+Editor) — Claude Code 통합 개발 도구
-
-### BurningTimesCore
-- 외부 경로 `C:\Project\Core\BurningTimesCore\` 에서 참조 (별도 빌드/링크)
-- 1375줄 규모, `DG.*` 네임스페이스 (→ `04_코어_범용성_분석_v1.md` 참조)
-
-## Assets 폴더 구조 (Depth 1~2)
-
-```
-Assets/
-├── Script/                 ← 게임 로직 본체 (256개)
-├── Tool/                   ← 에디터 도구 (42개)
-├── ResWork/
-│   ├── Table/
-│   │   ├── DeckBuilding.xlsm (4.8MB, SOT)
-│   │   └── Export/         ← JSON 58개 + CSV
-│   ├── UI_Prefab/          ← 800+ UI 프리팹
-│   ├── Effect/             ← VFX (Klaus, Gabriel)
-│   ├── Ingame/, MyUI/, Prefab/
-│   └── UI_Animation/, UI_Image/, UI_Video/, UI_Title/, UI_Effect/
-├── Res_Addr/               ← Addressable 그룹 (Ingame, MainUI, Monster, PC, ScenarioBG)
-├── Scenes/                 ← 7개 씬
-├── ThirdParty/             ← PlayFab, GreeWebView, TMP
-├── Plugins/
-│   ├── CodeStage/          ← AntiCheatToolkit
-│   ├── AllIn1SpriteShader/ ← UI 스프라이트 셰이더
-│   ├── Android/, iOS/, tvOS/
-├── Firebase/               ← 비활성 (코드에 주석처리)
-├── Adaptive Performance/   ← Google/Samsung 성능 조정
-└── unity-mcp/              ← Claude Code MCP
-```
-
-## Scripts 구조 (256개)
-
-```
-Assets/Script/
-├── InGame/                 ← 전투 시스템 핵심
-│   ├── Actor/              Actor.cs / PCActor.cs / MobActor.cs
-│   ├── Mgr/                EffectMgr.cs, ProjectileMgr.cs
-│   ├── Stage/              IngameStageData.cs, MonsterNodeControler.cs
-│   │   ├── Card/           CampItemSelectCard.cs
-│   │   └── Popup/          (Gift, Treasure, Steal, Script, BuffDebuff)
-│   └── Util/
-├── Server/                 ← PlayFab 통신
-│   ├── ServerInfo.cs       ★ 싱글톤, 12시간 자동 재로그인
-│   ├── ServerClass.cs
-│   └── FC_*, SC_*          Request/Response
-├── Table/Tables/           ← 자동 생성 58개 (table_cardlist.cs 등)
-├── Manager/                GameManager, Title_Mgr, AddrResourceMgr, DataCheckMgr, ErrorLogHookManager
-├── My/                     MyCoroutine, MyValue, MyEnum, MyText, MyClass, CryptoUtil, DSUtil
-├── Template/               MonoBehaviourSingletonTemplate<T>
-├── UGUI/
-│   ├── Title/, Lobby/ (MainMenu, Explore, Attandance, CatTrade, ETC)
-│   ├── Ingame/ (ETC, Result)
-│   ├── Common/ (GameUI, ItemSimpleCard, GetItem)
-│   ├── Manager/ (UIAtlasMgr, uScrollViewMgr, uScrollViewArrMgr)
-│   ├── BackKey/, Util/ (SafeArea, FollowTextEnd)
-│   └── zTestUI/
-├── Addressable/            AddrHandleBase, AddressableReleaseSelf
-└── Info/                   ActorInfo, ADInfo, InappInfo
-```
-
-### 네임스페이스 규칙 (중요 발견)
-
-**대부분 네임스페이스 없음 (global)** — 예외는 `FilGoodBandits` (SafeArea.cs 1개만).
-
-→ C11(코드 구조 직관성) 관점에서 **네임스페이스 체계 부재**. 향후 리팩토링 시 `FilGoodBandits.InGame.*`, `FilGoodBandits.UGUI.*` 등으로 정리 필요 (우선순위는 낮음 — 기능 동작에는 영향 없음).
-
-## 씬 구성 (7개)
-
-| 씬 | 역할 |
-|---|------|
-| `01_Title.unity` | 부트스트랩 (PlayFab 로그인, 데이터 로드) |
-| `02_Game.unity` | 메인 (로비·스테이지·전투 통합) |
-| `51_jjonga.unity` | **용도 불명** (개발 내부용 추정) |
-| `96_Tool_MobScale.unity` | 몬스터 스케일 조정 |
-| `97_Tool_Effect.unity` | 이펙트 테스트 |
-| `98_Tool_Mob.unity` | 몬스터 디버깅 |
-| `99_Tool.unity` | 범용 도구 패널 |
-
-## 패키지 의존성 (Packages/manifest.json)
-
-### 핵심
-- `com.unity.addressables 2.8.0` — 번들 관리
-- `com.unity.render-pipelines.universal 17.0.4` — URP
-- `com.unity.timeline 1.8.10`
-
-### 모바일
-- `com.unity.adaptiveperformance.google.android 5.1.6`
-- `com.unity.adaptiveperformance.samsung.android 5.1.0`
-- `com.unity.feature.mobile 1.0.0`
-
-### UI/기타
-- `com.coffee.ui-particle 4.9.0` (GitHub)
-- `com.unity.nuget.newtonsoft-json 3.2.1`
-- `com.lupidan.apple-signin-unity 1.5.0` (GitHub)
-
-### 없는 것
-- **DOTween** — `DOTWEEN` define은 있으나 manifest 부재 (로컬 설치 추정)
-- **Zenject/VContainer** — DI 프레임워크 없음
-- **UniTask** — 비동기 유틸 없음
-- **Firebase** — manifest 없음, 코드에 주석처리됨
-
-## 아키텍처 패턴
-
-### 싱글톤 기반
-```csharp
-ServerInfo.Ins          // PlayFab 허브
-GameManager.Ins         // 추정
-MonoBehaviourSingletonTemplate<T>.Ins   // 범용 템플릿
-```
-
-### 액터 시스템 (전투)
-```
-Actor (기본)
-├── PCActor         (플레이어, HP/Shield/Buff/Card/Animation)
-└── MobActor        (몬스터, 동일 구조)
-```
-
-### 데이터 주도
-```
-DeckBuilding.xlsm → Export/*.json (58개)
-                  → Script/Table/Tables/*.cs (자동 생성 58개)
-                  → 게임 로직
-```
-
-## 진입 가이드 (신규 개발자용)
-
-| 단계 | 읽을 파일 | 소요 |
-|------|----------|------|
-| 1. 공용 유틸 | `My/MyCoroutine.cs`, `MyEnum.cs`, `Template/MonoBehaviourSingletonTemplate.cs` | 30분 |
-| 2. 데이터 구조 | `Table/Tables/*` 훑기, `Server/ServerClass.cs`, `Info/` | 1h |
-| 3. 매니저 | `Server/ServerInfo.cs`, `Manager/Title_Mgr.cs` | 1h |
-| 4. 전투 시스템 | `InGame/Actor/Actor.cs`, `PCActor.cs`, `MobActor.cs`, `Mgr/EffectMgr.cs` | 2h |
-| 5. UI | `UGUI/Common/GameUI.cs`, `UGUI/Lobby/MainMenu/` | 1h |
-| 6. 씬 통합 | `01_Title.unity`, `02_Game.unity` | 1h |
-
-## C11 관점 판정
-
-| 기준 | 상태 | 평가 |
-|------|------|------|
-| **자원 효율성** | Addressable + IL2CPP + ACTk 적용 | ✅ 양호 |
-| **코드 구조 직관성** | 폴더는 명확(InGame/UGUI/Server/Manager), **네임스페이스는 부재** | 🟡 보통 |
-| **코드 범용성** | 공용 로직은 BurningTimesCore로 분리, `Assets/Script`는 프로젝트 전용 | ✅ 양호 |
-
-## 주요 리스크 (개발실 후속 판단 필요)
-
-1. **씬 `51_jjonga.unity`** — 용도 불명, 프로덕션 빌드 포함 여부 확인 필요
-2. **네임스페이스 부재** — 클래스명 충돌 위험, 장기적 리팩토링 대상
-3. **DOTween 설치 경로 불명** — manifest에 없으므로 신규 환경 구축 시 문제 가능
-4. **Firebase 주석처리** — 분석/크래시 리포팅 없음, 프로덕션 런칭 전 재활성화 판단 필요
-5. **51_jjonga 외 개발 내부 씬(96~99)** — 배포 빌드 씬 리스트에서 제외되어 있는지 확인 필요
diff --git a/프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md b/프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md
deleted file mode 100644
index 374b15a..0000000
--- a/프로젝트/수상한잡화점/개발/04_코어_범용성_분석_v1.md
+++ /dev/null
@@ -1,154 +0,0 @@
-# BurningTimesCore 범용성 분석
-
-> **작성일**: 2026-04-14
-> **조사 범위**: `D:/BurningTimes/FilGoodBandits/DeckBuilding/` Unity 프로젝트
-> **판정 기준**: C11 개발 관점 원칙 중 "코드의 범용성"
->
-> ⚠️ **상태 변경 (2026-04-14 PD님 지시)**
-> 기존 `BurningTimesCore`는 **타 회사 소유로 전환**, 담당자 퇴사.
-> 본 문서는 **참고·아카이브 용도**로만 유지되며, 코드 차용은 하지 않음.
-> BurningTimes 자체 범용 코어를 별도로 신규 제작 (`06_신규코어_설계안_v1.md` 참조).
-
----
-
-## 요약
-
-| 항목 | 결과 |
-|------|------|
-| **코어 범용성 점수** | **78 / 100** |
-| **C11 준수 판정** | ✅ **합격** |
-| **오염도** | **0%** (프로젝트 특수 로직 없음) |
-| **다음 프로젝트 재사용률** | ~80% (즉시 사용 가능) |
-
-## 코어 구성 (91개 파일, ~14,000 lines)
-
-### 네임스페이스 체계 (모두 `DG.*` 계열)
-```
-DG.Core                    - 기본 인터페이스, 열거형
-├─ DG.Core.Data            - 마스터 테이블, 데이터 파싱
-├─ DG.Core.Tool            - CSV 변환, 에디터 도구
-├─ DG.InGame.MasterTable   - 게임 데이터 베이스
-DG.Util                    - 유틸리티
-├─ DG.Util.Container       - 제네릭 컬렉션
-DG.OutGame                 - 아웃게임 데이터 (Goods)
-DG.UI                      - UI 프레임워크
-DG.Manager                 - ObserverManager 등
-```
-
-### 구성된 모듈 (✅ 포함됨)
-| 영역 | 파일 수 | 범용성 | 비고 |
-|------|--------|--------|------|
-| **UI 프레임워크** | 4 | ✅ 우수 | UIElements 기반, 전 장르 적용 가능 |
-| **데이터 테이블 시스템** | 7 | ✅ 우수 | CSV → ScriptableObject 자동 변환 |
-| **유틸리티 (핵심)** | 44 | ✅ 우수 | 싱글톤, 팩토리, 코루틴, DOTween, 제네릭 컨테이너 |
-| **에디터 확장** | 7 | ✅ 우수 | 애셋번들, 빌드, 계층창, 씬 단축키 |
-| **가챠/부스트 시스템** | 7 | 🟡 중간 | 제네릭 기반이나 "가챠/부스트" 개념 하드코딩 |
-| **전투 인터페이스·열거형** | 2 | 🟡 중간 | 인터페이스는 범용, 열거형 값은 일부 특화 |
-
-### 누락된 모듈 (❌ 없음)
-| 영역 | 중요도 | 코멘트 |
-|------|--------|--------|
-| **네트워크/통신** | 🔴 높음 | `INetworkService` 인터페이스 없음 → PlayFab 직접 의존 |
-| **세이브/로드 시스템** | 🔴 높음 | PlayerPrefs만 있음, 구조화된 직렬화 없음 |
-| **로컬라이제이션** | 🟠 중간 | `LocalType` enum만 있고 관리 시스템 없음 |
-| **오디오 매니저** | 🟡 낮음 | 게임별 차이가 크므로 선택적 |
-| **VFX 래퍼** | 🟡 낮음 | 선택적 |
-
-## 오염도 검증 (핵심)
-
-### 검사 결과
-| 검사 항목 | 결과 |
-|----------|------|
-| `Card`, `Merchant`, `Shop` 파일명 포함 | **0개** |
-| `DeckBuilding`, `FilGoodBandits` 네임스페이스 | **0개** |
-| `eCardType`, `eStageNodeType` 등 게임 특수 enum | **0개** |
-| 프로젝트 전용 클래스 | **0개** |
-
-### 프로젝트 전용 코드의 위치 (명확한 분리 확인)
-```
-Assets/Script/ (256개, ~31,000 lines, FilGoodBandits 네임스페이스)
-├─ InGame/       전투·스테이지·노드 로직
-├─ UGUI/         로비·인게임·타이틀 UI
-├─ Server/       서버 연동
-├─ Table/        자동 생성된 데이터 테이블 클래스
-├─ Manager/      게임 매니저
-├─ My/           프로젝트 특화 enum/class/value
-└─ Tool/         에디터·개발 도구
-```
-
-### 경계 명확성
-- **폴더 분리**: `BurningTimesCore` (외부 프로젝트) ↔ `Assets/Script` (프로젝트 전용)
-- **네임스페이스 분리**: `DG.*` ↔ `FilGoodBandits.*`
-- **의존 방향**: 프로젝트 → 코어만 존재, 코어 → 프로젝트 참조 **없음**
-
-→ **아키텍처적으로 깨끗한 상태**
-
-## 범용성 판정 (Q&A)
-
-### Q1. 다음 프로젝트가 덱빌딩이 아니어도 이 코어를 쓸 수 있는가?
-**✅ YES** (RPG, 퍼즐, 캐주얼, 카드게임 모두 적용 가능)
-- 즉시 재사용: 70% (UI, 데이터, 유틸, 에디터 도구)
-- 조정 필요: 20% (가챠·부스트 일반화, 전투 enum 재정의)
-- 신규 구현: 10% (네트워크, 세이브/로드)
-
-### Q2. 코어에 누락된 범용 기능은?
-1. **네트워크 인터페이스** — PlayFab 추상화 필요
-2. **구조화된 세이브/로드** — JSON/Binary 직렬화 + 암호화
-3. **로컬라이제이션 매니저** — 다국어 텍스트/애셋 관리
-
-### Q3. 코어에 있으면 안 될 특수 로직이 있는가?
-**0% — 완전히 깨끗함**
-
-## 점수 산정
-
-```
-✅ 완벽함 (20/20)
-  UI 프레임워크           4점
-  데이터 테이블           4점
-  디자인 패턴/유틸        4점
-  에디터 도구             4점
-  네임스페이스 분리       4점
-
-🟡 양호 (15/25)
-  가챠/부스트 시스템      6점 (제네릭이나 용어 특화)
-  전투 인터페이스         5점 (enum 값 일부 특화)
-  컨테이너/패턴           4점
-
-❌ 누락 (0/10)
-  네트워크 시스템        -3점
-  고급 세이브/로드       -3점
-  로컬라이제이션         -2점
-  오디오/VFX             -2점
-
-🟢 기본 점수 45점 + 위 합계 33점 = 78점
-```
-
-## C11 원칙 준수 판단
-
-| C11 기준 | 코어 상태 | 판정 |
-|---------|----------|------|
-| **자원 효율성** | 범용 유틸이 중복 코드 방지 | ✅ |
-| **코드 구조 직관성** | 네임스페이스·폴더 분리 명확 | ✅ |
-| **코드 범용성** | 오염 0%, 제네릭·추상 기반 | ✅ |
-
-→ **합격**. 단, 범용 기능 3가지(네트워크·세이브·로컬라이제이션) 추가 필요
-
-## 개발실 결정 사항 (향후 작업 기준선)
-
-### 신규 기능 추가 시 판단 기준
-- **코어(`DG.*`)에 넣는다**: 게임 장르에 무관하게 유용 + 제네릭·추상 가능
-- **프로젝트(`FilGoodBandits.*`)에 넣는다**: 카드/덱/몬스터/상점 등 본 프로젝트 특수 개념
-
-### 금지 사항
-- ❌ `BurningTimesCore` 안에 `Card*`, `Monster*`, `Shop*` 등 프로젝트 용어가 포함된 파일 생성
-- ❌ `FilGoodBandits` 네임스페이스를 코어에서 참조
-- ❌ 코어 enum에 프로젝트 특수값(`eCardType`의 신성폭격 등) 추가
-
-### 권장 후속 작업
-1. **단기**: 코어 README / 시작 가이드 문서화
-2. **중기**: 누락 3개 모듈 추가 (Save/Load, Localization, Network Interface)
-3. **장기**: 오디오 매니저, VFX 래퍼, State Machine 등 확장
-
-## 결론
-
-BurningTimesCore는 **BurningTimes 스튜디오의 범용 게임 개발 라이브러리로서 깨끗한 상태를 유지**하고 있으며, 다음 프로젝트에 그대로 재활용 가능한 품질입니다. 개발실은 앞으로 모든 코드 변경에서 이 경계를 지키는 것을 기본 원칙으로 삼습니다.
diff --git a/프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md b/프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md
deleted file mode 100644
index 4dd72e9..0000000
--- a/프로젝트/수상한잡화점/개발/05_서버연동_현황_v1.md
+++ /dev/null
@@ -1,113 +0,0 @@
-# 서버 연동 현황 분석 — 수상한 잡화점
-
-> **작성일**: 2026-04-14
-> **조사 범위**: PlayFab, Firebase, IAP, ACTk, 클라이언트-서버 권한 분배
-> **목적**: C11(개발자 관점) 보안·안정성 점검
->
-> ⚠️ **Critical 3건 보류 중 (2026-04-14 PD님 지시)**
-> 서버 파트가 정비되기 전이므로 아래 "Critical 보안 이슈" 3건은 **일시 보류**.
-> 서버팀 정식 가동 후 **반드시 재기동하여 해결**해야 하는 블로커급 이슈임을 명시.
-> 메모리: `project_shop_security_pending.md`
-
----
-
-## 요약
-
-| 항목 | 상태 |
-|------|------|
-| **주 백엔드** | PlayFab (`Assets/Script/Server/ServerInfo.cs` 허브) |
-| **Firebase** | 초기화 코드만, `google-services.json` 부재 → **비활성** |
-| **전투 연산 권한** | 🔴 **100% 클라이언트** |
-| **AES 키 하드코딩** | 🔴 **소스에 평문 존재** |
-| **IAP 영수증 검증** | 🔴 **주석처리되어 미구현** |
-| **ACTk 적용 범위** | 🟡 필드 약 10개만 `Obscured*` |
-| **SpeedHack/TimeCheck Detector** | ❌ 미사용 |
-| **C11 보안 판정** | 🔴 **중대 보완 필요** |
-
-## 백엔드 구성
-
-### PlayFab
-- **허브**: `Assets/Script/Server/ServerInfo.cs` (싱글톤, `DontDestroyOnLoad`)
-- **주요 기능**:
-  - 로그인 (디바이스 ID 기반)
-  - `LoginResult`, `ServerData`, `ServerTime` 관리
-  - **12시간마다 자동 재로그인** (세션 유지)
-  - `ServerClass.cs`의 `FC_*` / `SC_*` 구조로 요청·응답 래핑
-- **SOT 역할**: 플레이어 계정, 프로그레션 저장, 메일, 재시작 데이터
-
-### Firebase
-- 초기화 코드 파편만 존재
-- `google-services.json` 없음 → Analytics / Crashlytics 모두 **미동작**
-- Package manifest에 Firebase 선언 없음
-
-## 🔴 Critical 보안 이슈
-
-### 1. 전투 데미지 연산이 100% 클라이언트
-- `Actor.cs`, `PCActor.cs`, `MobActor.cs`에서 HP/Shield/Buff 전부 클라 계산
-- 서버는 **결과만 받음** → 클라 변조 시 서버 검증 불가
-- **영향**: 랭킹·이벤트 보상 악용 가능, 출시 전 서버 재연산 구조 필수
-
-### 2. AES 암호화 키 하드코딩
-- `Assets/Script/My/CryptoUtil.cs` (추정)에 평문 키 존재
-  - Key: `7gT9KfL2xQ1bN4pV6sH8jD3zW0cR5mYq` (32byte)
-  - IV: `aB3dE6gH9jK2mP5Q` (16byte)
-- IL2CPP 빌드도 메모리 덤프로 추출 가능 → 사실상 무의미
-- **영향**: 데이터 변조 방어선 상실
-
-### 3. IAP 영수증 검증 미구현
-- 영수증 서버 검증 코드가 **전부 주석처리**
-- 클라이언트만 IAP 성공 판단 후 재화 지급 → **결제 우회 가능**
-- **영향**: 매출 직접 손실, 오픈 블로커급
-
-## 🟡 보안 보완 현황
-
-### ACTk (AntiCheatToolkit)
-- 적용 범위: `ObscuredInt` / `ObscuredLong` 필드 약 10개
-- 미사용 기능:
-  - `SpeedHackDetector` (시간가속 탐지)
-  - `TimeCheckDetector` (디바이스 시간조작 탐지)
-  - `WallHackDetector` 등
-- **개선 방향**: 전투 스탯·재화·레벨 전면 `Obscured*` 적용, Detector 활성화
-
-### 서버 권한 vs 클라이언트 권한 분배
-
-| 영역 | 권한 | 위험도 |
-|------|------|--------|
-| 로그인/세션 | 서버 (PlayFab) | ✅ |
-| 재화·아이템 저장 | 서버 | ✅ |
-| 전투 결과 계산 | 🔴 클라이언트 | Critical |
-| 스테이지 보상 지급 | 🔴 클라이언트 기반 | Critical |
-| IAP 영수증 검증 | 🔴 미구현 | Critical |
-| 랭킹 점수 | 🔴 클라 제출 | High |
-| 시간 동기화 | 서버 시간 수신 | ✅ |
-
-## C11 판정
-
-| 기준 | 상태 |
-|------|------|
-| **자원 효율성** | 12시간 재로그인, PlayFab 배치 호출 등 적절 🟡 |
-| **코드 구조 직관성** | `ServerInfo` 단일 허브로 집중됨 ✅ |
-| **코드 범용성** | PlayFab 직접 의존 → 추상화 없음 🔴 (→ `04_코어_범용성_분석_v1.md` 누락 모듈과 동일, 신규 코어 `06_신규코어_설계안_v1.md`에서 해소 예정) |
-| **보안 건전성** | 위 3대 Critical 이슈 🔴 |
-
-## 개발실 조치 제안 (우선순위)
-
-### 🔴 P0 — 소프트 론칭(2026-06~07) 전 필수
-1. **IAP 서버 검증 재구현** — PlayFab ValidateXXXReceipt API 사용, 블로커 해제
-2. **전투 결과 서버 재연산** — 최소한 스테이지 클리어 판정·보상 지급은 서버 검증
-3. **AES 키 분리** — 런타임 유도(디바이스ID 해시 혼합) + 서버 전송 페이로드에 HMAC 서명
-
-### 🟠 P1 — 소프트 론칭 직후
-4. **ACTk 적용 확대** — 모든 재화·레벨·카드 보유 수량 `Obscured*` 전환
-5. **SpeedHackDetector / TimeCheckDetector 활성화**
-6. **Firebase Crashlytics 재활성화** — `google-services.json` 주입, 크래시 수집 시작
-
-### 🟡 P2 — 정식 출시 전
-7. **INetworkService 추상화 레이어** (BurningTimesCore 누락 모듈) → PlayFab 의존 제거
-8. **세이브/로드 구조화** — PlayerPrefs → 암호화 JSON 구조로 전환
-9. **서버 재연산 범위 확대** — 덱 드래프트, 가챠 없음이지만 카드 획득 검증 필요
-
-## 기획실 연관 (선행 인수인계 대조)
-
-- Q-P1 (터치 방어 쿨다운) / Q-P2 (몬스터 배치 비율) — **클라 전적 권한**이므로 서버는 해당 데이터 검증 불가. 기획·개발 모두 **클라 코드가 SOT**.
-- Q-P3 (보스 10002 클리어 가능성) — 클라 전투 SOT 확인 → `MobActor.cs` + `table_MonsterList.json` 실제 수치로 검증 가능
diff --git a/프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md b/프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md
deleted file mode 100644
index c8053c1..0000000
--- a/프로젝트/수상한잡화점/개발/06_신규코어_설계안_v1.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# BurningTimes 코어 프레임워크 R&D 설계안 (v1.2)
-
-> **작성일**: 2026-04-14 (v1), 2026-04-15 v1.2 목적 재정렬
-> **작성자**: 개발실장 (v1.2 정정: 총괄PM)
-> **문서 상태**: 🟡 **설계 초안 + 목적 재정렬(v1.2)** — PD님 판단 필요 항목 명시
-> **참조 문서**: `04_코어_범용성_분석_v1.md` (구 BurningTimesCore 분석 결과)
-> **근거 규칙**: 🌟 헌법 제1원칙 (조직 비전 목표 1·2·3), **P18 (설계 문서화 의무)**, **C11 (개발 관점 원칙)**
-
----
-
-## 🚨 본 R&D의 목적·용도·범위·비목적 (2026-04-15 PD님 정정 반영)
-
-| 축 | 내용 |
-|----|------|
-| **목적** | BurningTimes 조직 자산으로서 **코어 코드 프레임워크를 분석·R&D·축적**한다. 헌법 제1원칙 목표 1(PC 독립 최신화) + 목표 2(차기 프로젝트부터 자산 활용) + 목표 3(단기제작 스튜디오) 실현의 토대 |
-| **용도** | 조직 자산으로서 **축적·관리·고도화**. 차기 프로젝트 시점에 **조직 노하우의 형태로 활용** |
-| **범위** | 프레임워크 자체의 설계·구현·테스트·배포 체계·버전 관리 |
-| **❌ 비목적 (명시)** | ① **수상한 잡화점 프로젝트 투입 목적이 아님** — 수상한 잡화점은 본 프레임워크를 참조하지 않기로 PD님 결정 (2026-04-15). ② **"기존 BurningTimesCore의 즉시 대체품 제작"이 아님** — 소유권 이전이 계기이되 목적은 R&D·자산화. ③ **차기 프로젝트에 '신규 코어를 도입'한다는 단정적 계획이 아님** — 차기 프로젝트 시점에 축적된 조직 자산(코어 코드·노하우 등)이 활용되는 형태로 발현 |
-
-**⚠️ 용어 주의**: 본 문서에서 "신규 코어"·"BurningTimesCore 대체"·"마이그레이션" 등의 표현이 남아있다면 v1.2 이전의 잔재이며, **R&D·조직 자산화** 맥락으로 재해석한다.
-
----
-
-## 0. 문서 목적
-
-본 문서는 BurningTimes 조직 자산인 **코어 코드 프레임워크**의 R&D 방향과 구현 가이드라인을 명문화한다. 산출물은 **조직 공용 자산**으로 축적되며, 차기 프로젝트 시점에 조직 노하우의 형태로 활용된다.
-
-유령 문서(참조만 존재하고 본문 없음) 금지 원칙에 따라, 아직 **미확정 결정사항이 있더라도 최소한의 방향성을 먼저 문서로 고정**하고 이후 개정 이력으로 추적한다.
-
----
-
-## 1. 결정의 배경
-
-### 1.1 기존 BurningTimesCore 상황
-- **위치**: `C:/Project/Core/BurningTimesCore/` (외부 프로젝트)
-- **범용성 점수**: 78/100 (04번 분석 결과, C11 합격)
-- **구성**: `DG.*` 네임스페이스, 91개 파일, ~14,000 lines
-  - UI 프레임워크 / 데이터 테이블 / 유틸리티 / 에디터 확장 / 가챠·부스트 / 전투 인터페이스
-- **오염도**: 0% (프로젝트 특수 로직 없음, 깨끗한 상태)
-
-### 1.2 R&D 착수 계기 (v1.2 정정)
-1. **소유권 이전**: 기존 `BurningTimesCore`는 **타 회사 소유로 전환**됨 (2026-04-14 PD님 지시 확인). 기존 코어의 자체 소유·유지보수 경로 상실이 **R&D 필요성을 부각**시킨 계기
-2. **담당자 퇴사**: 원 제작자 부재로 구조적 개선·유지보수 채널 상실
-3. **코드 차용 불가**: 소유권이 이전되었으므로 코드를 그대로 복사하는 것은 불가. **설계 패턴만 참고 자료로 활용** (OI-3, PD님 2026-04-15 결정)
-4. **누락 모듈 기회**: 기존 코어에 부재했던 네트워크 추상화·세이브 시스템·로컬라이제이션을 **R&D 범위에 포함**하여 자산 품질 상승
-
-> **주의 (v1.2 정정)**: 본 R&D는 "기존 코어의 대체품을 즉시 만들어 프로젝트에 투입"하는 것이 **아니다**. 수상한 잡화점은 본 프레임워크를 참조하지 않으며, 차기 프로젝트 투입 여부·형태도 그 시점에 판단한다. 본 R&D의 목적은 **조직 자산 축적**이다.
-
-### 1.3 전략적 판단
-BurningTimes 스튜디오는 복수 프로젝트를 전개할 조직이므로, **범용 코어 프레임워크는 스튜디오의 지속가능한 자산**이다. 본 R&D는 헌법 제1원칙 목표 2(차기 프로젝트부터 조직 자산 활용) + 목표 3(단기제작 스튜디오) 실현의 토대를 마련한다.
-
----
-
-## 2. 설계 방향
-
-### 2.1 기본 원칙
-1. **기존 코어의 장점 계승** — 범용성 확보된 영역(UI·데이터 테이블·유틸·에디터 확장)의 **구조·패턴**을 차용 (코드가 아닌 설계)
-2. **누락 모듈 내장** — 네트워크 추상화·세이브/로드·로컬라이제이션을 **1차 릴리스부터 포함**
-3. **프로젝트 오염 0% 유지** — 카드·몬스터·상점 등 수상한 잡화점 특수 개념 **절대 혼입 금지**
-4. **C11 3원칙 준수** — 자원 효율성 / 코드 구조 직관성 / 코드 범용성
-
-### 2.2 구성 모듈 (계획)
-
-| # | 모듈 | 상태 | 비고 |
-|---|------|------|------|
-| 1 | **기본 인터페이스·열거형** | 🟢 1차 포함 | `DG.Core` 대체 — 기본 계약 정의 |
-| 2 | **유틸리티 (싱글톤·코루틴·컨테이너)** | 🟢 1차 포함 | 가장 재사용률 높은 영역 |
-| 3 | **데이터 테이블 시스템** | 🟢 1차 포함 | CSV/JSON → ScriptableObject 자동 변환 |
-| 4 | **UI 프레임워크** | 🟢 1차 포함 | UIElements 기반 |
-| 5 | **에디터 확장** | 🟢 1차 포함 | 애셋번들·빌드·계층창 단축키 |
-| 6 | **네트워크 추상화 (INetworkService)** | 🟢 1차 포함 (**신규**) | 기존 코어 누락 보완, PlayFab/Firebase 의존 제거 |
-| 7 | **세이브/로드 시스템** | 🟢 1차 포함 (**신규**) | JSON/Binary 직렬화 + 암호화 |
-| 8 | **로컬라이제이션 매니저** | 🟢 1차 포함 (**신규**) | 다국어 텍스트/애셋 관리 |
-| 9 | **데이터 테이블 무결성 검증 도구** | 🟢 1차 포함 (**신규**) | FK 검증·스탯 범위 이상 탐지, CI 연결 가능 |
-| 10 | **가챠/부스트 시스템** | 🟡 2차 | 기존 코어는 "가챠/부스트" 용어 하드코딩 → **제네릭 추첨(Draw) 시스템으로 일반화** 필요 |
-| 11 | **전투 인터페이스·열거형** | 🟡 2차 | enum 값 일부 특화 → **추상 이벤트/상태머신 기반으로 재설계** |
-| 12 | **오디오 매니저** | 🟡 2차 | 게임별 차이 큼 — 공통 API만 |
-| 13 | **VFX 래퍼** | 🟢 3차 | 파라미터화된 이펙트 관리 |
-
-### 2.3 네임스페이스 체계 (결정 필요)
-
-**Option A (PD님 판단 필요)**: 기존 `DG.*` 그대로 사용
-- 장점: 과거 패턴 익숙
-- 단점: 원 제작자의 이니셜로 추정되어 **소유권 혼선 우려**
-
-**Option B (권장)**: `BurningTimes.*` 로 신규 체계
-- 장점: 스튜디오 소유권 명확, 검색·분리 용이
-- 단점: 신규 학습 비용 (미미)
-
-```
-BurningTimes.Core                 - 기본 인터페이스, 열거형
-├─ BurningTimes.Core.Data         - 마스터 테이블, 데이터 파싱
-├─ BurningTimes.Core.Tool         - CSV 변환, 에디터 도구
-├─ BurningTimes.Core.Validation   - 테이블 무결성 검증 (신규)
-BurningTimes.Util                 - 유틸리티
-├─ BurningTimes.Util.Container    - 제네릭 컬렉션
-BurningTimes.UI                   - UI 프레임워크
-BurningTimes.Net                  - 네트워크 추상화 (신규)
-BurningTimes.Save                 - 세이브/로드 (신규)
-BurningTimes.Localization         - 로컬라이제이션 (신규)
-BurningTimes.Manager              - ObserverManager 등
-```
-
-**→ 열린 이슈 OI-1**: 네임스페이스 최종 결정 (PD님 판단 대기)
-
-### 2.4 저장 위치 (결정 필요)
-
-**Option A**: 기존 방식 유지 — `C:/Project/Core/BurningTimesCore/` 외부 경로 참조
-**Option B (권장)**: **Git 서브모듈 또는 Unity Package (UPM Git URL)** 로 전환 — 버전 관리·배포 표준화
-
-**→ 열린 이슈 OI-2**: 코어 배포 방식 최종 결정 (개발실 내부 협의 후 PD님 공유 예정)
-
----
-
-## 3. 대안 비교
-
-| 대안 | 장점 | 단점 | 판정 |
-|------|------|------|------|
-| **A. 완전 신규 제작** (채택) | 소유권 완전 확보, 누락 모듈 1차 포함, 구조 최신화 | 초기 구현 분량 큼 | ✅ **선택** |
-| **B. 기존 코어 일부 재작성** | 재사용 최대화 | 소유권 이전된 코드 참조 리스크, 법적 회색지대 | ❌ 기각 |
-| **C. 오픈소스 라이브러리 도입 (DOTween·UniTask·Zenject 조합)** | 커뮤니티 검증, 즉시 사용 가능 | 다수 의존성 결합, 라이선스 관리 복잡, 스튜디오 내부 통제 상실 | ❌ 기각 (보조적 채택은 가능 — DOTween 등은 현재도 사용 중) |
-| **D. Unity 공식 패키지만 사용 (Addressable·UI Toolkit·Localization 패키지)** | 유지보수 책임 Unity | 고수준 범용 유틸·팩토리·컨테이너 등 공백 | ❌ 단독으론 부족 (보조적 채택) |
-
-### 3.1 C9 원칙 적용 결과
-핵심 규칙 C9에 따라 "MVP·공수·일정" 고려하지 않고 **완성도 최우선**. 따라서 A안(완전 신규) 선택이 정당함.
-
-### 3.2 법적 안전장치 (2026-04-15 PD님 결정 반영)
-기존 코어의 **설계 패턴을 최대한 차용**하여 더 좋은 설계 방안이 있으면 **참고 자료로 적극 활용**한다. **법무 검토는 불필요** (PD님 2026-04-15 직접 결정). 단, **코드 직접 복사는 지속 금지** — 재구현 시 모든 코드는 신규 작성한다.
-
-**→ 열린 이슈 OI-3**: ✅ **확정 (2026-04-15 PD님 결정)** — 법무 검토 불요, 설계 패턴 최대 차용 및 참고 자료 활용
-
----
-
-## 4. 구현 가이드라인 (C11 3원칙 기반)
-
-### 4.1 자원 효율성
-- **GC 최소화**: 범용 유틸·컨테이너는 내부 풀링(Object Pool) 내장
-- **Lazy 초기화**: 사용되지 않는 모듈은 로드하지 않음 (Assembly 분리)
-- **Addressable 통합**: 리소스 로딩은 기본적으로 Addressable 기반으로 설계
-- **메모리 상한**: 테이블 로딩 시 전수 메모리 상주 대신 지연 로드 패턴 제공
-
-### 4.2 코드 구조의 직관성
-- **네임스페이스 필수**: 모든 공개 타입은 `BurningTimes.*` 네임스페이스 소속
-- **인터페이스 우선**: 구현체가 아닌 인터페이스(`INetworkService`, `ISaveStore` 등)로 노출
-- **명명 컨벤션**:
-  - 인터페이스: `I` 접두사 (`INetworkService`)
-  - 추상 클래스: `Abstract` 접두사 또는 `Base` 접미사
-  - 이벤트: `On` 접두사 (`OnLoaded`)
-  - 정적 유틸: `*Util` / `*Helper`
-- **폴더 = 네임스페이스 1:1 매핑**
-
-### 4.3 코드 범용성
-- **프로젝트 특수 개념 금지**: `Card`, `Monster`, `Shop`, `DeckBuilding` 등 용어 **코어 전체에서 0건** 유지
-- **제네릭·추상 우선**: 구체 타입 의존 최소화
-- **플랫폼 독립**: `#if UNITY_*` 분기는 플랫폼 어댑터 계층에만 한정
-- **설정 주입**: 기본값 하드코딩 대신 `ScriptableObject` 기반 설정 주입
-
-### 4.4 금지 사항 (04번 문서에서 계승)
-- ❌ 프로젝트 용어 포함 파일 (`Card*`, `Monster*`, `Shop*`)
-- ❌ `FilGoodBandits` 네임스페이스를 코어에서 참조
-- ❌ 코어 enum에 프로젝트 특수값(`eCardType` 등) 추가
-- ❌ 특정 서버(PlayFab) / 특정 분석(Firebase) 직접 의존 — 반드시 추상화 계층 경유
-
----
-
-## 5. 검증 방법
-
-### 5.1 품질 보증 방법
-| 방법 | 목적 | 주기 |
-|------|------|------|
-| **오염도 자동 검사** | 코어 내부에 프로젝트 용어(Card, Monster 등) 포함 여부 grep 스캔 | CI 매 커밋 |
-| **샘플 게임 복수 구현** | 덱빌딩 외 최소 1종(예: 퍼즐 샘플)으로 범용성 실증 | 릴리스 전 |
-| **단위 테스트** | 각 모듈(유틸·세이브·네트워크) 테스트 커버리지 목표 ≥70% | CI 매 커밋 |
-| **정적 분석** | Roslyn Analyzer로 네임스페이스·명명 컨벤션 강제 | CI 매 커밋 |
-| **범용성 자가 점검 (Q&A)** | 04번 문서의 Q1·Q2·Q3 질의 재적용 → 점수 산정 | 메이저 버전 릴리스마다 |
-
-### 5.2 인수 기준 (1차 릴리스)
-- [ ] 오염도 0% (프로젝트 용어 grep 0건)
-- [ ] 샘플 프로젝트에서 신규 코어로 **최소한의 덱빌딩 프로토타입** 재구현 성공
-- [ ] 9개 1차 모듈 단위 테스트 통과
-- [ ] 네임스페이스·명명 컨벤션 정적 분석 경고 0건
-- [ ] 문서화: 각 모듈 README + 시작 가이드
-
-### 5.3 기존 코어와의 범용성 비교 목표
-- **목표 점수**: ≥85/100 (기존 78점 + 누락 모듈 3종 보완분)
-- 측정: 04번 문서와 동일 방식 재산정
-
----
-
-## 6. 시뮬레이터 이원화 해소와의 연관
-
-본 코어 신규 제작은 `07_시뮬레이터_이원화_해소_착수계획_v1.md` 와 **독립적으로 진행**한다.
-
-단, 양자가 만나는 접점:
-- **시뮬레이터 Headless 추출 시** — 프로젝트 코드에서 신규 코어 의존이 없는 부분만 먼저 추출 가능 (기존 코어는 이미 PlayFab·Unity UI 의존 없음, 신규 코어도 동일 원칙 유지)
-- **데이터 테이블 시스템** — 신규 코어의 테이블 로딩이 Python 시뮬과 동일 JSON을 공유하도록 **직렬화 포맷 호환성** 유지
-
-→ 시뮬 이원화 해소 작업에서 **테이블 로딩 인터페이스를 신규 코어의 원형으로 활용**할 수 있음.
-
----
-
-## 7. 열린 이슈 (PD님 판단 필요)
-
-| ID | 이슈 | 상태 | 결정 권자 |
-|----|------|------|----------|
-| **OI-1** | 네임스페이스: `DG.*` 유지 vs `BurningTimes.*` 전환 | 🔴 미결 | PD님 |
-| **OI-2** | 코어 배포 방식: 외부 경로 참조 vs Git 서브모듈 vs UPM | 🟡 **헌법 제1원칙 3대 목표 기반 재평가 중** (PD님 2026-04-15 지시) | 개발실장 → PD님 안건 재제안 |
-| **OI-3** | 기존 코어 참고 범위: 설계 패턴만 vs 일부 코드 패턴도 재구현 가능 여부 — 법무적 안전성 확인 필요 | ✅ **확정 (2026-04-15 PD님)** — 법무 검토 불요, 설계 패턴 최대 차용 및 참고 자료 활용 | PD님 |
-| **OI-4** | 1차 릴리스 범위: 9개 모듈 vs 6개 모듈부터 단계적 | ✅ **확정 (2026-04-15 PD님)** — A안 **9개 모듈 일괄 1차 릴리스** | PD님 |
-| ~~**OI-5**~~ | ~~현행 수상한잡화점 프로젝트에 신규 코어 적용 시점~~ | ❌ **폐기 (2026-04-15 v1.2)** — 질문 전제 자체가 성립하지 않음. 수상한 잡화점은 본 프레임워크를 참조하지 않기로 확정되었고, 본 R&D는 조직 자산화가 목적이지 프로젝트 투입이 아님. 차기 프로젝트 활용 형태·시점은 그 시점에 판단 | — |
-
----
-
-## 8. 작업 착수 계획 (상위 수준)
-
-> **상세 공수·담당은 OI 결정 후 하위 계획으로 분리 작성 예정**
-
-| 단계 | 내용 | 선결 조건 |
-|------|------|----------|
-| **0. 이슈 해소** | OI-1·OI-2 PD님 결정 수령 (OI-3·4 확정 완료, OI-5 폐기) | — |
-| **1. 레포 초기화** | Git 레포 구조·네임스페이스 골격·asmdef 구성 | OI-1, OI-2 |
-| **2. 1차 모듈 R&D·구현** | Core / Util / Data / UI / Editor + Net / Save / Localization / Validation (9종 일괄 — OI-4 A안) | 단계 1 완료 |
-| **3. 샘플 프로젝트 검증** | 범용성 실증용 샘플(덱빌딩 외 최소 1종 포함)으로 R&D 품질 검증 | 단계 2 완료 |
-| **4. 조직 자산 고도화** | R&D 결과를 조직 공용 자산으로 축적·문서화·버전 관리. **수상한 잡화점 마이그레이션 단계는 존재하지 않음** (본 프로젝트는 참조하지 않음) | 단계 3 완료 |
-
----
-
-## 9. 변경 이력
-
-| 일자 | 작성·수정자 | 버전 | 사유 |
-|------|-----------|------|------|
-| 2026-04-14 | 개발실장 | v1 (초안) | 유령 문서 해소(P18) — 05번 문서에서 참조되나 실체 부재 상태 해결. 기존 코어 소유권 전환에 따른 신규 제작 방향 명문화 |
-| 2026-04-15 | 총괄PM | v1.1 | PD님 직접 결정 반영: OI-3 법무 검토 불요·설계 패턴 최대 차용 확정 / OI-4 A안(9개 모듈 일괄) 확정 / OI-2는 헌법 제1원칙 3대 목표 기반 안건 재도출로 이관 (§3.2·§7 갱신) |
-| 2026-04-15 | 총괄PM (PD님 정정 지시) | **v1.2** | **R&D 목적 재정렬 + OI-5 폐기**. 문서 전반을 "신규 코어 대체품 제작·프로젝트 투입" 프레이밍에서 "조직 자산 R&D·축적" 프레이밍으로 재정립. 문서 상단 "목적·용도·범위·비목적" 섹션 신설, §1.2 R&D 착수 계기로 제목 변경, §7 OI-5 폐기 처리, §8 마이그레이션 단계 삭제·조직 자산 고도화로 재구성. 오해 재발 방지 메모리 적재 |
-
----
-
-## 10. 참고 문서
-
-- `04_코어_범용성_분석_v1.md` — 기존 BurningTimesCore 구조·범용성 분석 (아카이브 용도)
-- `05_서버연동_현황_v1.md` — 네트워크 추상화 필요성의 근거 (Critical 3건 포함)
-- `02_개발자관점_점검_v1.md` — C11 점검 항목 전반
-- `03_Unity프로젝트_구조_v1.md` — 프로젝트 코드와 코어의 경계
-- 공통 규칙 C11 (개발 관점 원칙), P18 (설계 문서화 의무)
diff --git a/프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md b/프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md
deleted file mode 100644
index 24fe74b..0000000
--- a/프로젝트/수상한잡화점/개발/07_시뮬레이터_이원화_해소_착수계획_v1.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# 시뮬레이터 이원화 해소 착수계획 (v1)
-
-> 🔴 **2026-04-17 아카이브됨 — 대체 문서: [`프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md`](../시뮬레이터/01_시뮬레이터_아키텍처_v1.md)**
->
-> 본 07 원안("Headless C# CLI 추출")은 2026-04-17 PD님 직접 지시로 **Unity MCP EditMode + 독립 어셈블리(`Assets/Sim/` + `BurningTimes.Sim.asmdef`) 방향으로 전환**됨. 전환 사유·기각 근거: `프로젝트/수상한잡화점/시뮬레이터/01~04` + `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`.
->
-> **본문은 기각안 근거·당시 설계 실증으로 보존**. 차기 프로젝트에서 Unity 외 환경 고려 시 참고 자료로 활용 가능 (헌법 제1원칙 목표 2 원칙 B).
-
-> **작성일**: 2026-04-14
-> **작성자**: 개발실장
-> **우선순위**: 🔴 **최우선** — 기획실 Phase 3 HOLD 해제 조건 (당시)
-> **근거**: 02번 분석 문서 §1 (시뮬레이터 이원화 🔴), PD님 지시 (2026-04-14)
-> **관련 규칙**: 핵심 규칙 **C11 (개발 관점 원칙)**, **C5 (정보의 정직성)**, **C9 (AI 에이전트 조직 원칙 — 완성도 중심)**
-
----
-
-## 1. 현황 분석 (재정리)
-
-### 1.1 이원화 상태
-| 측면 | 현황 |
-|------|------|
-| **기획실 시뮬** | Python 3종 — `battle_sim.py` (전투 단일), `full_stage_sim.py` (스테이지 전체), `stage_sim_v2.py` (개선판) |
-| **Unity 구현** | C# — `Assets/Script/InGame/Actor/Actor.cs`, `PCActor.cs`, `MobActor.cs`, `Mgr/EffectMgr.cs` 등 |
-| **데이터 SOT** | JSON — `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/*.json` (공통) |
-| **로직 SOT** | 불명 — Python 시뮬이 독자 재구현했는지, Unity 코드를 참조했는지 **미확인** |
-| **결과 일치 여부** | 검증된 바 없음 — **이원화 리스크 실재** |
-
-### 1.2 핵심 리스크
-1. **밸런싱 신뢰도 붕괴**: 기획실이 Python 시뮬로 도출한 수치가 실제 Unity 전투와 괴리될 경우, Phase 3 (성장 요소별 기여도 설정) 결과가 실제 게임에서 재현되지 않음
-2. **유지비 2배**: 전투 공식 1건 변경 시 Python·C# 양쪽 동시 수정 필요 — 동기화 실패 시 조용히 축적되는 버그
-3. **결정론 부재**: 양 구현 모두 재현 가능한 시드 기반 리플레이 보장 여부 미확인
-4. **터치 방어·회피 SOT 불일치**: 02번 §4에 기록됨 — 기획문서·Python 시뮬·Unity 코드 3자 동작 상이 가능성
-
-### 1.3 긴급도
-- **기획실 Phase 3 HOLD** 상태 (PD님 지시, 2026-04-14)
-- 본 작업 완료 전까지 기획실의 성장 밸런싱 작업 전면 정지
-
----
-
-## 2. 해소 방향 — Unity C# 로직을 SOT로 하는 Headless 시뮬 추출
-
-### 2.1 기본 방향
-**"실제 게임에서 동작하는 C# 코드를 전투 시뮬의 SOT로 삼는다."**
-
-- C11 원칙상 **두 구현을 동기화로 유지하는 것은 근본 해결이 아님** (C2 근원적 문제 해결)
-- 따라서 **Unity 전투 로직을 Unity 엔진 의존성 없이 실행 가능한 Headless C# 라이브러리로 추출** → CLI에서 직접 실행
-- Python 시뮬은 **검증·비교용 참조 구현으로만 유지**하다가, 결과 일치가 확증되면 **폐지 또는 아카이브**
-
-### 2.2 선택 근거 (02번 §1 Option A·B 중 A 채택)
-| 기준 | Option A (Headless C# 일원화) | Option B (Python 참조 유지 + 자동 동기화 테스트) |
-|------|------------------------------|---------------------------------------------|
-| **자원 효율성** | ✅ 유지비 1배 | 🔴 유지비 2배 |
-| **코드 직관성** | ✅ 기획·개발 모두 동일 코드 참조 | 🔴 언어 이원화 유지 |
-| **범용성** | ✅ 타 프로젝트 동일 패턴 적용 | 🔴 프로젝트마다 동기화 로직 재구현 |
-| **기획실 친화성** | 🟡 C# CLI 실행 학습 필요 | ✅ Python 익숙 |
-| **C9(완성도) 부합** | ✅ 근본 해결 | 🔴 현상 유지 |
-
-→ **A 채택**. 기획실 친화성 문제는 CLI 래퍼·단순 JSON 입출력으로 해소 (§3.3 참조)
-
-### 2.3 비-목표 (Out of Scope)
-- Unity Editor 기반 통합 (별도 Play Mode 실행) — Headless CLI가 목적
-- 실시간 시각화 — 결과 수치·로그만 산출
-- 네트워크·IAP·ACTk 등 전투 외 시스템 — 05번 문서 영역
-
----
-
-## ~~3·4·5. 작업 단계·담당 팀·재개 조건~~ (2026-04-18 삭제)
-
-> 원 섹션(Phase A~E 실행 계획·담당 팀 매트릭스·Phase 3 재개 조건 5종)은 Unity MCP EditMode 전환으로 **완전히 대체**됨 (2026-04-17 PD님 직접 지시). 대체 경로: `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` §3·§4 + `공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`. Phase 3 재개 로드맵은 개발팀 #38 PD 지시 하 재정의 중. 삭제 근거: 2026-04-18 dev-auditor·개발팀장 공통 축약 권고 (실행 계획은 기각 근거로서의 자산 가치 없음, 설계 원리·Option 비교·검증 방법은 §2·§6에 보존).
-
----
-
-## 6. 검증 방법
-
-### 6.1 결정론 보장 검증
-- 동일 시드·동일 입력 → 동일 출력 (100회 반복 시 편차 0)
-- **검증 대상**: Unity 실제 플레이(녹화·시드 고정) vs CLI Headless 실행
-
-### 6.2 Python ↔ C# 결과 일치 검증 (Phase D 핵심)
-| 검증 항목 | 허용 오차 | 사유 |
-|----------|----------|------|
-| 스테이지 클리어 여부 | 완전 일치 (Pass/Fail) | 이진 결과 |
-| 총 데미지량 | 0% (결정론이면 동일) | 정수 연산이면 동일해야 함 |
-| 최종 HP | 0% | 정수 연산 |
-| 클리어 시간(초) | ≤1% 오차 | 부동소수점 누적 오차 허용 |
-| 이벤트 발생 순서 (치명타·처치 등) | 완전 일치 | 시드 동일 시 순서 불변 |
-
-**불일치 발견 시 원칙**:
-1. Unity C# 코드가 SOT → Unity 결과를 기준으로 간주
-2. Python 시뮬이 다른 결과를 내면 **Python 로직 오류**로 규정 → Python 수정 또는 폐기
-3. 기획실이 Python 결과를 근거로 밸런스를 설정했다면 **해당 밸런스 재검토 필요** (PD님 보고 사안)
-
-### 6.3 연속적 회귀 방지
-- 전투 코드 수정 시 CI에서 **기준 시나리오 시뮬** 자동 실행
-- 결과가 기준선에서 이탈하면 **빌드 실패**
-
----
-
-## ~~7. 완료 기준~~ (2026-04-18 삭제 — §3·4·5와 함께 실효. Unity MCP 전환 경로로 대체)
-
----
-
-## 8. 열린 이슈 (당시 PD님 판단 필요 사항, 아카이브)
-
-| ID | 이슈 | 의견 |
-|----|------|------|
-| **OI-A** | BattleCore 저장 위치 — Unity 프로젝트 내부 asmdef vs 별도 repo (06번 신규 코어와 통합 가능성) | 개발실장 의견: **별도 repo 권장** (타 프로젝트 재활용 가능성 대비) — PD님 판단 필요 |
-| **OI-B** | Phase D 불일치 발견 시 기존 Python 시뮬 기반 밸런스 데이터의 신뢰성 재평가 범위 | 사안 발생 시 즉시 PD님 보고 대상 (C3 은폐 금지) |
-| **OI-C** | 기획실이 CLI 학습 부담 없이 쓸 수 있도록 **웹 UI 래퍼** 추가 여부 | C9 원칙상 "완성도" 중심 — 필요성 판단 후 PD님 결정 |
-
----
-
-## 9. 변경 이력
-
-| 일자 | 작성·수정자 | 버전 | 사유 |
-|------|-----------|------|------|
-| 2026-04-14 | 개발실장 | v1 | PD님 지시(기획실 Phase 3 HOLD) 수령 후 착수계획 초안 작성 |
-| 2026-04-17 | PM | v1-archived | Unity MCP EditMode 전환으로 원안 기각, 상단 아카이브 배너 추가, 02_개발자관점_점검 L19 주해 추가 |
-| 2026-04-18 | PM | v1-slim | §3·§4·§5·§7(실행 계획·담당 팀·재개 조건·완료 기준 약 120줄) 삭제. §1·§2·§6·§8·§10(현황·Option 비교·검증 방법·OI·참고) 유지하여 기각 근거·차기 참고 가치 보존. 3축 감사(dev-auditor)·개발팀장 공통 권고 반영 |
-
----
-
-## 10. 참고 문서
-
-- `02_개발자관점_점검_v1.md` §1 (시뮬레이터 이원화 🔴), §4 (터치 방어·회피 SOT 불일치)
-- `03_Unity프로젝트_구조_v1.md` (전투 시스템 코드 위치)
-- `기획실/.cache/battle_sim.py`, `full_stage_sim.py`, `stage_sim_v2.py` (아카이브 대상)
-- `06_신규코어_설계안_v1.md` §6 (신규 코어와의 연관)
-- 공통 규칙 C2 (근원적 문제 해결), C5 (정보의 정직성), C9 (완성도 중심), C11 (개발 관점)
diff --git a/프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md b/프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
deleted file mode 100644
index c365b55..0000000
--- a/프로젝트/수상한잡화점/개발/08_전투시스템_SOT_v1.md
+++ /dev/null
@@ -1,403 +0,0 @@
-# 08. 전투시스템 SOT (Single Source of Truth) v1
-
-- 작성일: 2026-04-14
-- 작성자: 개발실장 (Explore 에이전트 분석 위임)
-- 목적: 기획실 밸런싱·시뮬레이터 검증을 지원하기 위해 **코드가 실제로 수행하는 전투 로직**을 SOT로 확정
-- 스코프: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Script/` 전수
-- 원칙: 코드가 말하는 것만 기록. 추측 금지. 불확실한 항목은 **(확인 필요)** 태그 명시
-
----
-
-## 1. 전투 시스템의 파일 맵
-
-### 1.1 핵심 매니저 및 컨트롤러
-
-| 파일경로 | 클래스명 | 역할 |
-|---|---|---|
-| `Assets/Script/InGame/Stage/MonsterNodeControler.cs` | `MonsterNodeControler` | **전투 루프 제어 중심** — 몬스터 배치, 라인 변경, 노드 종료 |
-| `Assets/Script/InGame/Actor/Actor.cs` | `Actor` (기본 클래스) | 피해 계산, 회피, 크리티컬, 상태이상 (약 3,700줄) |
-| `Assets/Script/InGame/Actor/PCActor.cs` | `PCActor` | 플레이어 전용 — 방어 입력, HUD 관리 |
-| `Assets/Script/InGame/Actor/MobActor.cs` | `MobActor` | 몬스터 전용 — 라인 위치, 드롭 보상 |
-
-### 1.2 핵심 데이터 타입
-
-| 파일:라인 | 타입 | 설명 |
-|---|---|---|
-| `My/MyClass.cs:339` | `ProjectileData` | 발사체/공격 정보 (데미지, 크리, 특수효과) |
-| `My/MyValue.cs:517` | `ActorStatInfo` | 배우 스탯 (HP, 공격력, 회피율 등) |
-| `InGame/Stage/IngameStageData.cs:63` | `StageNodeData` | 노드 데이터 (몬스터 구성) |
-| `Table/Tables/table_monsterlist.cs:8` | `MonsterListTableData` | 몬스터 테이블 (Normal/Boss 구분) |
-
-### 1.3 전투 씬 진입/종료 경로
-
-- **진입**: `MonsterNodeControler.Set(endnode, stagedata)` (`MonsterNodeControler.cs:42`)
-  - 몬스터 생성: `MonsterNodeControler.cs:92~118`
-  - 배우 초기화: `MonsterNodeControler.cs:142~168`
-  - 전투 시작: `MonsterNodeControler.cs:170` → `InGameInfo.Ins.BattleStart_AfterMakeMob()`
-- **종료**:
-  - 몬스터 전멸: `Co_AllKill()` (`MonsterNodeControler.cs:334~343`)
-  - 라인 변경: `Co_LineChange()` (`MonsterNodeControler.cs:362~450`)
-
----
-
-## 2. 전투 라이프사이클
-
-### 2.1 흐름
-
-```
-1. 노드 진입: MonsterNodeControler.Set(endnode, stagedata)
-2. 패턴 선택: table_MonsterPatternList (PatternID 기반)
-3. 몬스터 동적 생성: Get_MakeMob_Dynamic()  [cs:198~255]
-   - 라인(전열/중열/대기열) × 슬롯(3) = 9슬롯
-   - 슬롯별 근접/원거리/고유 확률 추첨
-4. 배우 배치: Actor 9개 (0~8: 전열 3, 중열 3, 대기열 3)
-5. 전투 루프: Actor.Update()  [Actor.cs:79~111]
-   - AttackCoolTime 감소 → 0 도달 시 Play_Attack()
-   - 상태이상·카드 효과 업데이트
-6. 공격 발동: Actor.Shoot_Projectile()  [Actor.cs:946~1039]
-7. 피해 계산: Actor.Get_Dmg(ProjectileData)  [Actor.cs:521~834]
-8. 라인 전멸 체크: Check_LineAllDead()  [Actor.cs:480]
-   - 라인 변경: Co_LineChange()
-   - 전원 처치: Co_AllKill() → act_EndNode()
-```
-
-### 2.2 주요 이벤트 / 콜백
-
-| 이벤트 | 함수 | 시점 |
-|---|---|---|
-| 피해 수신 | `Actor.Get_Dmg(ProjectileData)` `Actor.cs:521` | 발사체 도달 |
-| 회피 판정 | `Run_AvoidStatus()` `Actor.cs:1640` | 회피 성공 |
-| 크리티컬 결정 | `ProjectileData.Set()` `MyClass.cs:354` | 발사체 생성 |
-| 사망 | `Actor.Set_Die(ProjectileData)` `Actor.cs:876` | HP ≤ 0 |
-| 부활 | `Co_Resurrection()` `Actor.cs:926` | 부활 카드/성소 |
-| 라인 변경 | `Co_LineChange()` `MonsterNodeControler.cs:362` | 라인 전멸 |
-| 노드 종료 | `act_EndNode()` `MonsterNodeControler.cs:456` | 전원 처치 |
-
----
-
-## 3. 공격/피해 계산 수식
-
-### 3.1 기본 공격력
-
-`MyValue.cs:800~804`
-```csharp
-public int Get_Damage()
-{
-    var dmg = Random.Range((int)Get_TotalStat(eStat.Attack_Min),
-                           (int)Get_TotalStat(eStat.Attack_Max) + 1);
-    return Mathf.Max(dmg, 1); // 최소 1 보장
-}
-```
-
-**Attack_Min 최종값** (`MyValue.cs:585~603`)
-```csharp
-case eStat.Attack_Min:
-{
-    rtn += Get_Stat(eStat.Attack) + Get_BuffStat(eStat.Attack) - Get_DebuffStat(eStat.Attack);
-
-    // G5_AttackUpBySkillCardCount: 스킬카드 수만큼 증가
-    if (m_Actor.IsObtainCardSkill(cardtype))
-        rtn += m_Actor.Get_SkillCardCount();
-
-    // G5_FlatDamageMinMaxEqual: 최소/최대 동일화
-    if (m_Actor.IsObtainCardSkill(cardtype))
-    {
-        var maxdmg = Get_Stat(eStat.Attack_Max) + Get_BuffStat(eStat.Attack_Max)
-                   - Get_DebuffStat(eStat.Attack_Max);
-        rtn = Mathf.Max((int)rtn, (int)maxdmg);
-    }
-
-    var mul = Get_BuffStat(eStat.DmgMul)
-            + Get_BuffStat(eStat.Attack_Min_Mul)
-            + Get_BuffStat(eStat.PC5_DmgMul);
-    return (int)(rtn + (rtn * mul));
-}
-```
-
-**기여도 순서** (카드 > 장비 > 각성 > 인장 원칙과 매핑):
-1. 기본값: `ActorTableDataBase.n_AttackMin / n_AttackMax`
-2. 장비: `ApplyMainStat()` / `ApplyStat()` (`MyValue.cs:261~282`)
-3. 각성: `eAwakening.Stat_ADD`, `eUniqueAwakeningType.PC1_UniqueAwakening1~5` (`MyValue.cs:156~217`)
-4. 인장: `eSpecialEffect.CritChance`, `CritDamage` 등 (`MyValue.cs:145~154`)
-5. 런 내 버프/디버프: `Set_Buff()` / `Set_Debuff()` (`MyValue.cs:747~792`)
-
-### 3.2 최종 피해 계산 (15단계)
-
-`Actor.cs:521~834` 순서대로 요약.
-
-1. **기본**: `baseDmg = hitterstat.Get_Damage()`
-2. **1회성 절대 증가**: `AddDmg_1Time` + 인장 절대값
-3. **1회성 배수 증가**: `AddDmgMul_1Time` + 인장 배수
-4. **스턴/라인 보정**: `DmgMul_byStun`, `FrontLine_Dmg_Mul_1Time`, `MiddleLine_Dmg_Mul_1Time`, `BackLine_Dmg_Mul_1Time`
-5. **G3_PotionNextAttackBoost**: 물약 스택 소모 시 배수 추가
-6. **G5_FirstAttackTripleDamage**: 첫 공격이면 배수를 해당 값으로 **대체**(`Actor.cs:719~724`)
-7. **곱연산 합산**: `hitter_dmg = base + 절대 + (hitter_dmg * 배수)` (`Actor.cs:726`)
-8. **크리티컬**: `hitter_dmg *= CriDmg` (크리 시) (`Actor.cs:758`)
-9. **절대 감소**: `ReduceMeeleDmg` / `ReduceRangeDmg` / `ReduceDmg` + 방어 중이면 `PCDefence` (`Actor.cs:776`)
-10. **비율 감소**: `ReduceMeeleDmg_Mul` / `ReduceRangeDmg_Mul` + 방어 중이면 `PCDefence_Mul`, `G2_ReduceRangedDamageWithShield` (`Actor.cs:808`)
-11. **최소 피해 1**: `hitter_dmg = max(hitter_dmg, 1)` (`Actor.cs:811`)
-12. **G4_ShieldedDamageReduction**: 쉴드 보유 시 비율 추가 감소
-13. **FixedDmg**: 고정 피해 스탯이 있으면 피해를 해당 값으로 **대체** (`Actor.cs:817`)
-14. **G2_StackDamageOnSameTarget**: 동일 대상 연타 스택 추가 피해 (`Actor.cs:826`)
-15. **쉴드 우선 감산** → **HP 감산** (`Actor.cs:435`)
-
-**요약식**
-```
-기본 = Random[Attack_Min, Attack_Max]
-중간 = 기본 + 절대증가 + (기본 × 배수증가)
-(크리 시) 중간 × CriDmg
-→ 중간 - 절대감소
-→ 중간 - (중간 × 감소비율)
-→ max(중간, 1)
-→ (쉴드 존재) 쉴드 먼저 흡수 → HP 감산
-```
-
-### 3.3 크리티컬
-
-`MyClass.cs:354~393`
-```csharp
-isCri = DSUtil.RandomTrue(crirate);                          // 1차: 확률 판정
-if (Hitter.IsObtainCardSkill(G2_NextSevenHitsCritical))      // 2차: N연타 강제
-{
-    var card = Hitter.Get_CardSkillData_orNull(cardtype);
-    if (card.UseCount_Acc < card.m_Data.Get_IntValue1())
-    {
-        ++card.UseCount_Acc;
-        isCri = true;
-    }
-}
-```
-
-**크리 확률 상한**: `MaxCri = 0.9f` (`MyValue.cs:23`).
-**크리 배수 적용**: `hitter_dmg *= Get_TotalStat(eStat.CriDmg)` (`Actor.cs:758`).
-
-### 3.4 회피 판정 (3단계)
-
-**1단계 — 명중률 체크 (PC 한정)** (`Actor.cs:623`)
-```csharp
-isHit = DSUtil.RandomTrue(hitterstat.Get_TotalStat(eStat.HitRate) / (avoid * 3.69));
-```
-> **(확인 필요)** 3.69 상수의 근거.
-
-**2단계 — PC 회피율** (`Actor.cs:633~647`)
-```csharp
-if (DSUtil.RandomTrue(Attack가_Melee ? avoid_melee : avoid_range))
-    Run_AvoidStatus(...); return;
-```
-
-**3단계 — 최초 공격 무조건 회피** (`Actor.cs:649~669`)
-- 근접 첫 공격: `G2_FirstMeleeAlwaysEvade`
-- 원거리 첫 공격: `G3_DodgeFirstRangedAttack`
-
-**회피율 상한**: `MaxAvoid = 0.9f` (`MyValue.cs:23`) — **PC 한정**. 몬스터 회피는 정수형(비일관성 리스크).
-
-### 3.5 상태이상
-
-`Actor.cs:512~513`
-```csharp
-OnEvent_GetDmg(pdData);
-Set_StatusEffect(pdData.Get_SoSData(pdData.Hitter), this);
-```
-
-상태이상 데이터는 `table_StatusOptionSet`에서 조회 (`MyClass.cs:401~438`). 업데이트 불가 CC(Stun/Freezing 등) 은 `Actor.cs:52~53` 상수 참조.
-
----
-
-## 4. 터치 방어 메커닉 (Q-P1 → Q-P2)
-
-### 4.1 결론
-
-**플레이어 터치 입력으로 방어가 발동된다 — 그러나 현재 확인된 경로는 "타겟팅"이다.** 명시적 방어 입력 윈도우는 ~~(확인 필요)~~ → **✅ 실측 확정 (2026-04-17 #37 Q-P2 정밀 2차)**: `UITouchHandler.cs` `IPointerDownHandler`·`IPointerUpHandler`·`IPointerExitHandler` 인터페이스로 구현. `IngameUIManager.cs:39` `m_PCDefence.Set(m_PCActor.Play_Defence, m_PCActor.Release_Defence, null)` 바인딩. **터치 Down↔Up 구간 동안 지속되는 상태 효과**. 근거: [`공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md`](../../../공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md).
-
-### 4.2 구현
-
-`MonsterNodeControler.cs:263~290` — 마우스/터치 다운 이벤트
-```csharp
-void Update()
-{
-    if (Input.GetMouseButtonDown(0))
-    {
-        // ... RaycastHit2D로 Actor 탐색
-        if (actor != null && !pc.IsDead() && targetlines && !actor.IsDead())
-            InGameInfo.Ins.m_PCActor.Set_Target(actor); // 타겟 변경
-    }
-}
-```
-
-### 4.3 방어 상태 관련 흔적
-
-- `PCActor.Play_Defence()` `PCActor.cs:148~154`: 방어 애니메이션 실행
-- `PCActor.Release_Defence()` `PCActor.cs:155~161`: 방어 해제
-- 실제 호출부 ~~(확인 필요)~~ → **✅ 실측 확정 (#37)**: `IngameUIManager.cs:39` — `m_PCDefence.Set(...)` 으로 `UITouchHandler` 이벤트가 `Play_Defence`/`Release_Defence` 에 바인딩. `Update()`에서 `m_onHold?.Invoke()` 지속 호출 (현재 no-op).
-
-### 4.4 방어 성공 효과 (`Actor.cs:515~519`)
-
-```csharp
-if (ActorStatus == eActorStatus.Defecne)
-{
-    huddmg.Set_Block(dmg, Get_World_Position());
-    EffectMgr.Ins.Show_Effect("PCBlock", Get_World_Position(), this);
-}
-```
-
-방어 중이면 피해 감소:
-- 절대: `PCDefence` (`Actor.cs:775`, `table_GlobalValue`)
-- 비율: `PCDefence_Mul` (`Actor.cs:783`)
-
-#### ✅ 실측 확정 수치 (2026-04-17 #37 Q-P2 정밀 2차)
-
-| 항목 | 기획 초기 가정 | **실측 확정값** | 근거 |
-|------|---------------|---------------|------|
-| 피해 감소 비율 | 50% | **30%** (`PCDefence_Mul = 0.3`) | `GlobalValue.json` — `{"s_ID": "PCDefence_Mul", "n_Value": "0.3"}` |
-| 고정 절대 감소 | 미정 | **1** (`PCDefence = 1`) | `GlobalValue.json` + `Actor.cs:775` |
-| 지속 형태 | 단일 공격 바인딩 가정 | **지속형 상태 효과** (터치 Down↔Up 유지 동안 반복 적용) | `UITouchHandler.cs` + `IngameUIManager.cs:39` |
-| 쿨다운 | 미정 | **없음** (즉시 재사용) | `UITouchHandler.cs`·`PCActor.cs:148-162` 전수 확인 |
-| 방어 중 공격 | 미정 | **불가** (DPS 0) | `Actor.cs:4500` — 공격 프레임 return |
-| 방어 중 피격 애니 | 미정 | **차단** (Play_Hit 조기 return) | `PCActor.cs:133` |
-| 적용 공격 종류 | 미정 | **Melee / Ranged 공통** | `Actor.cs:782-783` 단일 분기 |
-| Mob 방어 메커닉 | 미정 | **부재** | `MobActor.cs` override 전수 확인 결과 부재 |
-
-**근거 응답서**: [`2026-04-17_Phase0-C_QP2_정밀2차_응답서.md`](../../../공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md) (#37 PD 지시). **기획 초기 가정("50%")은 추적성 보존을 위해 유지**(원칙 1), 실측 수치로 전환하여 밸런스 작업은 0.3 기준으로 진행.
-
----
-
-## 5. 몬스터 배치 · 스폰 패턴 (Q-P2)
-
-### 5.1 배치 흐름
-
-`MonsterNodeControler.Set()` (`cs:42~171`)
-1. `StageNodeData_Mob.PatternID` → `table_MonsterPatternList` 조회
-2. `PatternID < 1001`이면 `+900` 구데이터 호환 (`cs:70`)
-3. `Get_MakeMob_Dynamic()`가 라인 × 슬롯 9개에 대해 근접/원거리/고유 확률 누적 추첨
-4. **고유 몬스터는 1개 제한** (`uniqueMakeCount`) — **(확인 필요)** 의도된 캡인지
-
-### 5.2 데이터 테이블 키 매핑
-
-| 테이블 | 필드 | 역할 | 위치 |
-|---|---|---|---|
-| `table_MonsterPatternList` | `n_PatternId` | 패턴 ID | `cs:11` |
-| 동 | `list_MeleeRate_Front/Middle/Back` | 라인별 근접 확률 | `cs:33` |
-| 동 | `list_RangeRate_Front/Middle/Back` | 라인별 원거리 확률 | `cs:34` |
-| 동 | `list_FixedRate_Front/Middle/Back` | 라인별 고유 확률 | `cs:35` |
-| 동 | `n_FixedMonsterId` | 고유 몬스터 ID | `cs:17` |
-| `StageNodeData_Mob` | `MobCount` | 배치할 몬스터 수 | `IngameStageData.cs:86` |
-| 동 | `list_MobID` | 선택 가능한 몬스터 풀 | `IngameStageData.cs:86` |
-
-확률 문자열 포맷: `^`로 구분된 정수(10000 스케일) → 파싱 시 10000으로 나눠 0~1 정규화 (`table_MonsterPatternList.Init()` `cs:43~115`).
-
-### 5.3 몬스터 ID 결정
-
-`MonsterNodeControler.cs:183~196`
-```csharp
-int Get_MobID(MakeMobData mob, StageNodeData_Mob mobnode, int makecount, int bossid)
-{
-    if (mob.MobID > 0) return mob.MobID;              // 고유 몬스터 즉시 반환
-    var lst = mobnode.list_MobID;
-    if (bossid > 0) lst = lst.FindAll(f => f != bossid); // 보스 ID 중복 방지
-    if (mobnode.MakeRandom) return lst[Random.Range(0, lst.Count)];
-    return MyValue.m_MyStageData.Get_MobID_onStage(mob.e_ToolMobType, mobnode.list_MobID);
-}
-```
-
----
-
-## 6. 보스 처리 (Q-P3)
-
-### 6.1 판정
-
-`table_monsterlist.cs:36~39`
-```csharp
-public override bool IsBoss()
-    => e_MonsterType == eMonsterType.Boss_Melee
-    || e_MonsterType == eMonsterType.Boss_Range;
-```
-
-### 6.2 배치 규칙
-
-`MonsterNodeControler.cs:76~90`
-```csharp
-if (stagedata.m_Type == eStageNodeType.Boss)
-{
-    ++makeMobCount;
-    var bossdata = stagedata.Get_Data<StageNodeData_Boss>();
-    bossid = bossdata.BossID;
-    dic_mob[eMobBattlePos.Backline][2] = bossid;   // 대기열 중앙 고정
-    ...
-}
-```
-
-**보스는 항상 Backline 슬롯 2에 배치된다.**
-
-### 6.3 특수 패턴
-
-- **Death 특수효과 피해**: 보스는 50% HP 피해, 일반 몬스터는 9999 (즉사) — `Actor.cs:570`
-- **미션 등급 가중치**: `MobActor.cs:123~220` — 보스=2, 악마=3, 일반=1
-
-> **(확인 필요)** 보스10002 클리어 가능성(Q-P3)은 전용 AI 패턴이 아닌 **스탯·카드 풀 기반 시뮬레이션**으로 검증해야 한다. 현재 코드상 보스 전용 공격 로직은 발견되지 않음.
-
----
-
-## 7. 발견된 리스크 · 이슈
-
-### 7.1 기획 문서 vs 코드 불일치 후보
-
-| 항목 | 코드 실태 | 위치 |
-|---|---|---|
-| 회피 공식 | `HitRate / (Avoid × 3.69)` — 3.69 근거 불명 | `Actor.cs:623` |
-| PC 방어 | 터치는 타겟팅만 확인, 명시적 방어 윈도우 미확인 | `PCActor.cs`, `MonsterNodeControler.cs` |
-| 크리 상한 | 0.9f 고정 (90%) | `MyValue.cs:23` |
-| 회피 상한 | PC만 0.9f, 몬스터는 정수형 | `MyValue.cs:625~639` |
-
-### 7.2 하드코딩 값 (밸런싱 숨김)
-
-| 값 | 용도 | 위치 | 개선 |
-|---|---|---|---|
-| `3.69` | 회피 상수 | `Actor.cs:623` | 테이블화 |
-| `0.01f` | 회피율 % 변환 | `MyValue.cs:629` | eStat에서 처리 |
-| `"PCDefence"` | 방어 절대 감소 | `Actor.cs:775` | GlobalValue 참조 OK |
-| `"PCDefence_Mul"` | 방어 비율 감소 | `Actor.cs:783` | GlobalValue 참조 OK |
-| `list_scale[]` | 9슬롯 스케일 | `MonsterNodeControler.cs:26` | 테이블화 |
-| `list_pos[]` | 9슬롯 좌표 | `MonsterNodeControler.cs:27~32` | 테이블화 |
-
-### 7.3 시뮬레이터 이원화
-
-- 단일 경로 확인됨 — `Actor.Get_Dmg()` 외 병행 계산 경로 없음.
-- 이원화 리스크는 **낮음**. (기획실 시뮬레이터는 외부 엑셀/도구이므로, SOT를 이 문서로 일원화하면 검증 기준 확정 가능.)
-
-### 7.4 코드 품질
-
-- `Actor.cs` ≈ 3,700줄 · `Get_Dmg` ≈ 300줄 — 분할 권고
-- 카드 효과 조건분기 난립 (`eCardType.Max = 200+`) — 효과 테이블화·전략 패턴 리팩토링 후보
-- `ObscuredInt/Float` 빈번 사용 — 보안 목적 유지하되 핫패스 프로파일링 필요
-
-### 7.5 버그 냄새
-
-1. **HP 0 허용 가능성** — `Math.Max(1, ...)` 가드가 Attack_Min/Max에만 적용 (`MyValue.cs:709`)
-2. **몬스터 회피 비일관성** — PC 상한 0.9 vs 몬스터 정수
-3. **라인 변경 중 공격 수신** — `Co_LineChange` 도중 상태 불일치 가능성
-4. **보스 ID 풀 중복 처리 의존** — `list_MobID`에 boss가 들어가 있을 때 `FindAll` 예외 안전성 **(확인 필요)**
-
----
-
-## 8. B-1 완료 조건 체크리스트
-
-SOT를 완전 확정하려면 다음 항목이 추가로 필요.
-
-- [ ] 기획 엑셀 SOT와 회피·크리 상한·3.69 상수 대조
-- [ ] `table_GlobalValue` 실제 값 덤프 (PCDefence, PCDefence_Mul, PC_ProjectileSpeed 등)
-- [ ] `eCardType.G1_* ~ G5_*` 200+개 효과 전수 맵 (효과 종류별 분류표)
-- [ ] 상태이상 중첩 규칙 명문화 (Stun/Freezing 등 CC 상호작용)
-- [x] PC 방어 입력 경로 특정 (UI 버튼 vs 터치 윈도우) — **완료 (2026-04-17 #37)**: `UITouchHandler` 기반 터치 윈도우, `IngameUIManager.cs:39` 바인딩
-- [x] Q-P1 응답서 확정 — 터치 방어 구조 최종 확인 — **완료 (2026-04-17 #37 Q-P2 정밀 2차)**: [응답서](../../../공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md) 참조
-- [ ] Q-P2 응답서 확정 — 패턴별 배치 예시 생성 (본 항목은 몬스터 배치 패턴 예시 별개 작업)
-- [ ] Q-P3 응답서 확정 — 보스10002 시뮬 결과 포함
-- [ ] 핫패스 성능 프로파일 (Get_Dmg 호출/프레임, ObscuredInt 오버헤드)
-- [ ] 위 7.5 버그 냄새 재현 테스트
-
----
-
-## 9. 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|---|---|---|---|
-| v1 | 2026-04-14 | 개발실장 (Explore 위임) | 초안 — Phase 0-B-1 |
diff --git a/프로젝트/수상한잡화점/개발/09_카드시스템_아키텍처_v1.md b/프로젝트/수상한잡화점/개발/09_카드시스템_아키텍처_v1.md
deleted file mode 100644
index 215bce0..0000000
--- a/프로젝트/수상한잡화점/개발/09_카드시스템_아키텍처_v1.md
+++ /dev/null
@@ -1,283 +0,0 @@
-# 09. 카드시스템 아키텍처 v1
-
-- 작성일: 2026-04-14
-- 작성자: 개발실장 (Explore 에이전트 분석 위임)
-- 목적: 기획실이 관리하는 카드(G1~G5 총 311장) 이 **코드상 어떻게 표현·실행·획득되는지** 확정
-- 스코프: `Assets/Script/Table/Tables/table_cardlist.cs`, `Assets/Script/InGame/Actor/Actor.cs`, `Assets/Script/My/MyClass.cs`
-- 선행 문서: `08_전투시스템_SOT_v1.md`
-
----
-
-## 1. 카드 데이터 모델
-
-### 1.1 eCardType Enum
-
-`table_cardlist.cs:123~450` 에 `G[1-5]_<효과명>` 형태로 311개 정의.
-
-| 등급 | 개수 | 대표 |
-|---|---|---|
-| G1 (Common) | 112 | G1_AddPotion ~ G1_ShieldIncreaseAttackPower |
-| G2 (Uncommon) | 73 | G2_CriUpAfterCri ~ G2_RangeDodgeUp |
-| G3 (Rare) | 51 | G3_CritDmgUp ~ |
-| G4 (Hero) | 43 | G4_ZeroShieldCritRate ~ |
-| G5 (Legend) | 32 | G5_RemoveNormalSkills ~ G5_RandomLightning_N |
-| **합계** | **311** | `eCardType.Max` sentinel |
-
-명명 규칙: `G[1-5]_<CamelCase>`. 기획실 SOT 엑셀 행과 1:1 매핑.
-
-### 1.2 CardListTableData 필드 (`table_cardlist.cs:7~120`)
-
-| 필드 | 타입 | 암호화 | 용도 |
-|---|---|---|---|
-| `e_CardType` | enum | ✗ | 식별자 |
-| `n_ID` | int | **ObscuredInt** | 고유 ID |
-| `e_CardGrade` | eGrade | ✗ | 등급 |
-| `s_Value1~3` / `f_Value1~3` | string / float | float만 **Obscured** | 수치 (문자열/런타임 이원) |
-| `s_LvUpValue1~2` / `f_LvUpValue1~2` | string / float | float만 **Obscured** | 레벨업 가중치 |
-| `e_LvUpType` | enum | ✗ | 레벨업 적용 방식 |
-| `b_Percent`, `b_LvUpValue*Percent` | bool | ✗ | % 해석 플래그 |
-| `s_Projectile` / `e_ProjectileAttackType` / `n_ProjectileCount` / `f_ProjectileDelayTime` | — | Obscured(int/float) | 투사체 |
-| `n_StatusOptionSetID` | int | **Obscured** | `table_StatusOptionSet` 조인 |
-| `n_UseDmg` | int | **Obscured** | 피해 계산 방식 (0=고정, 1=%비율, 2=배수) **(확인 필요)** |
-| `n_Desc`, `n_LvUpDesc` | int | ✗ | 텍스트 테이블 키 |
-
-**핵심 관찰**: 수치는 `ObscuredFloat/Int`로 안티치트 적용. 메타(enum, 플래그)는 평문. **수치 변경은 테이블만 수정하면 코드 무수정** — 기획실 밸런싱 규칙("효과 종류 변경 금지, 수치만 조정")과 구조적으로 일치.
-
-### 1.3 eLvUpType (`table_cardlist.cs:110~122`)
-
-```csharp
-Use_LvUpValue1_To_Value1   // f_Value1 누적
-Use_LvUpValue1_To_Value2
-Use_LvUpValue1_To_Value3
-Use_LvUpValue1_To_ProjectileCount
-Heal_Multi / Heal_Mul       // 즉시 회복 효과
-GetGold                     // 즉시 골드
-```
-
-레벨업 수치 적용 (`CardListTableData.cs:96~100`):
-```csharp
-int Get_CardLv() => Mathf.Max(0, MyValue.sdata.Get_CardLv(n_ID) - 1);
-float Get_LvUpValue1(eLvUpType t) =>
-    e_LvUpType == t ? f_LvUpValue1 * Get_CardLv() : 0;
-```
-→ **선형 누적**: `Value_final = Value_base + Level * Coefficient`.
-
-### 1.4 CardSkillData 런타임 인스턴스 (`MyClass.cs:147~250`)
-
-```csharp
-public class CardSkillData
-{
-    public CardListTableData m_Data;
-    Actor m_Actor;
-    public bool StartBattle;
-    public int TargetIdentity;
-    public int UseCount;
-    public int UseCount_Acc;
-    public float m_LifeTime;                   // 주기 쿨타임
-    public Dictionary<int, int> dic_identity;  // 대상별 추적
-}
-```
-
----
-
-## 2. 카드 효과 실행 구조
-
-### 2.1 OnEvent_* 진입점 맵 (~258개 분기)
-
-`Actor.cs` 전반:
-
-| 메서드 | 라인 | 발동 | 분기 수 |
-|---|---|---|---|
-| `OnEvent_AddSkillCard()` | 1799 | 카드 획득 직후 1회 | ~80 |
-| `OnEvent_RunSkillCard()` | 1655 | 획득/라인변경 반복 | ~50 |
-| `OnEvent_Kill_Hitter()` | 2244 | 적 처치 | ~20 |
-| `OnEvent_Cri_Hitter()` | 2616 | 크리 발동 | ~15 |
-| `OnEvent_Avoid()` | 3001 | 회피 성공 | ~12 |
-| `OnEvent_NoMiss_Hitter()` | 2442 | 회피 실패 | ~8 |
-| `OnEvent_MyShield_Hit()` | 3131 | 쉴드 피해 | ~10 |
-| `OnEvent_MyShield_Break()` | 3145 | 쉴드 소진 | ~5 |
-| `OnEvent_GetDmg()` | 3202 | 피해 수신 | ~15 |
-| `OnEvent_PlayAttack()` | 2022 | 공격 발동 | ~20 |
-| `OnEvent_LvUp()` | 2917 | 레벨업 | ~25 |
-| `OnEvent_MeetNode()` | 2746 | 노드 진입 | ~5 |
-| `OnEvent_MakeMob()` | 3408 | 몬스터 생성 | ~3 |
-| `OnEvent_Hit()` | 3218 | 피해 적용 후 | ~10 |
-
-### 2.2 효과 적용 3가지 패턴
-
-- **A. 조건 분기 (if-switch)** — 카드 1장당 1개 분기 (`Actor.cs:1801~1830` 등). 신규 추가 시 **코드 수정 필요**.
-- **B. 데이터 주도 (테이블 참조)** — `CardSkillData.Add(...)` 에서 `Set_Buff(eStat, value)` 로 일반화 (`MyClass.cs:161~180`). 이 경로는 enum 케이스만 추가하면 됨.
-- **C. 주기형 (m_LifeTime)** — `G1_MagicMissile` 처럼 쿨타임 기반 (`MyClass.cs:165~166`). `Update()`에서 감소.
-
-### 2.3 트리거 분류표
-
-| 트리거 | 예시 카드 | 위치 |
-|---|---|---|
-| 즉시 (획득 시) | G1_FireMagicMissiles, G1_InstantFullHeal | OnEvent_AddSkillCard |
-| 온 공격 | G1_FirstAttack, G1_FifthAttackBack | OnEvent_PlayAttack |
-| 온 피해 | G1_HealOnRangedHit | OnEvent_GetDmg |
-| 온 킬 | G1_CastMagicMissilesOnBackKill | OnEvent_Kill_Hitter |
-| 온 크리 | G1_ThirdCritDamage | OnEvent_Cri_Hitter |
-| 온 회피 | G1_LifeStealOnDodge | OnEvent_Avoid |
-| 온 노드시작 | G2_HeroSkillFullHeal | OnEvent_RunSkillCard |
-| 영구 스탯 | G1_AddMaxAttack | CardSkillData.Add → Set_Buff |
-| 1회성 버프 | G1_DodgeNextNAttacks | OnEvent_AddSkillCard |
-| 주기 효과 | G1_MagicMissile | m_LifeTime |
-
----
-
-## 3. 카드 획득 · 보유 · 제거
-
-### 3.1 획득 경로
-
-```
-노드 클리어 → Co_AllKill() → act_EndNode()
- → SelectCardUI.Set_Cards() [BattleCard.cs:37]
- → BattleCard.OnClick()
- → InGameInfo.Ins.Add_Card(CardListTableData)
- → Actor.Add_CardSkill() [Actor.cs:337]
- → dic_Card[eCardType] = CardSkillData
- → OnEvent_AddSkillCard()
-```
-
-추가 경로:
-- 성소: `Actor.Add_Card_Random()` (`Actor.cs:4474`)
-- 장비 특수효과: `Set_Equipment()` → `list_SkillId` (`Actor.cs:3773`)
-- 상태이상 연쇄: `GetSkillCard_N` (`Actor.cs:3866~3871`)
-
-### 3.2 보유 구조
-
-- 저장소: `Dictionary<eCardType, CardSkillData> dic_Card` — **카드 타입별 1장**
-- 조회: `IsObtainCardSkill(eCardType)` O(1)
-- 슬롯 상한: **코드상 무제한** — **(확인 필요)** 기획 UI 상한 존재 여부
-- 중복 방지: `if (!dic_Card.ContainsKey(...))` (`Actor.cs:4487`)
-
-### 3.3 제거 경로
-
-**현재 코드상 카드 제거 경로 없음** — `Actor.Set()` (`Actor.cs:148`) 에서 런 리셋 시 `dic_Card.Clear()` 만 존재.
-
----
-
-## 4. 카드 효과 카탈로그 (대표 샘플)
-
-### 4.1 카테고리별
-
-| 카테고리 | 수량 추정 | 대표 |
-|---|---|---|
-| 공격력 증강 | ~25 | G1_AddMaxAttack, G3_BacklineDoubleDmg, G5_FlatDamageMinMaxEqual |
-| 피해 감소/무효화 | ~18 | G2_ReduceMeeleEnemyDamage, G2_ActivateInvincibleShieldOnKill, G1_ReflectOnRangedDodge |
-| 회피/회피율 | ~12 | G1_DodgeNextNAttacks, G2_FirstMeleeAlwaysEvade, G1_MaxDodgeWhenHpBelow |
-| 크리 | ~15 | G2_CriUpAfterCri, G1_ThirdCritDamage, G2_NextSevenHitsCritical, G5_EvadeCrit |
-| 쉴드 | ~20 | G1_ShieldOnRangedDodge, G1_MaxShieldUpOnLevelUp, G1_SpringShieldToHP |
-| 회복/생명력 | ~22 | G1_HealOnRangedHit, G1_AngelFeatherHeal, G1_StopExploreHealHP |
-| 상태이상 부여 | ~15 | G1_EnemySpawnStunChance, G1_StunAllMeleeEnemies, G5_EvadeStun_N |
-| 특수 투사체 | ~35 | G1_MagicMissile, G1_ThunderOnFifthHit, G4_StartArrowRainRangedImmune, G5_CritTriggerMeteor |
-| 스킬 카드/특수 | ~18 | G1_GetRandomRareOrEpicSkill, G1_NextLevelChooseTwoSkillCards, G1_CastReaperOnLevelUp |
-| 수집/보상 | ~12 | G1_GainGoldOnSanctuaryFind, G1_XpGainOnCritKill, G1_CampRechargePotion |
-| 방어/면역 | ~10 | G2_ActivateInvincibleShieldOnKill, G5_PotionDamageImmunity |
-
-### 4.2 등급별 경향
-
-- **G1 112장 (36%)** — 기초재. 모든 런에서 자주 획득.
-- **G2 73장 (23%)** — 조건부/조합 효과.
-- **G3 51장 (16%)** — 라인·배수·크리 특수.
-- **G4 43장 (14%)** — 실드·동일대상·면역 연계.
-- **G5 32장 (10%)** — 투사체·무적·즉사 최상위 시너지.
-
-G1 비중이 높은 것은 기획 의도(풀초기/보편 효과)로 해석 가능.
-
----
-
-## 5. 카드시스템과 밸런싱 훅
-
-### 5.1 데이터 입력 흐름
-
-```
-기획실 .xlsm
-  → (익스포트 도구) → JSON/CSV
-  → (코드 생성) → table_cardlist.cs (자동)
-  → (Awake) → CardListTableData 싱글톤
-  → (전투 중) → CardSkillData.m_Data → Get_*Value*()
-```
-
-**코드상 수치 하드코딩은 확인되지 않음** — 모든 수치는 테이블 필드. → 밸런싱은 테이블만 수정하면 된다는 구조적 전제 성립.
-
-### 5.2 핫 리로드
-
-- **현재 불가** — 싱글톤 Awake에서 초기화, 런 중 반영 안 됨. 재시작 필요.
-- 개선안: ScriptableObject / JSON 원격 동기화 / 기획실 대시보드 연동 — **Phase 1+ 고려**.
-
-### 5.3 기획실 워크플로 접촉점
-
-| 단계 | 파일/도구 | 비고 |
-|---|---|---|
-| 효과 설계 | 기획 엑셀 | 효과 종류 변경 금지 (규칙) |
-| 수치 입력 | `f_Value1~3`, `f_LvUpValue1~2` | |
-| 익스포트 | 도구 경로 | **(확인 필요)** 문서화 필요 |
-| 코드 생성 | `table_cardlist.cs` 자동 | |
-| QA | Unity 런타임 | |
-| 시뮬레이터 검증 | 기획실 매크로 | **코드와 공식 일치 여부 (확인 필요)** |
-
----
-
-## 6. 리스크 · 이슈
-
-### 6.1 조건 분기 폭발 (~258 위치)
-
-- 단일 카드 효과가 여러 `OnEvent_*`에 분산 → 신규 추가 시 수정 누락 위험.
-- 개선안: `interface ICardEffect` + `CardEffectRegistry` 디스패처 패턴으로 효과별 객체 분리. **(장기 리팩토링 과제)**
-
-### 6.2 하드코딩 상수 (08 문서와 중복)
-
-- `3.69` (회피 분모) `Actor.cs:623`
-- `0.9f` (크리·회피 상한) `MyValue.cs:23`
-- `eCardType.Max` sentinel — 선택적 테이블화 대상
-
-### 6.3 구현 누락 후보
-
-- G5 32장 중 일부 미구현/주석 처리 가능성 — **(확인 필요)** TODO/FIXME/주석 grep
-- `G1_NullifyDamageEveryNHits` — `Dmg_Immune` 스탯 순서 버그 가능성
-
-### 6.4 시뮬레이터 동기화
-
-| 항목 | 코드 | 시뮬 | 상태 |
-|---|---|---|---|
-| 피해 15단계 | Actor.Get_Dmg | 엑셀 매크로 | 대조 필요 |
-| 크리 확률 | RandomTrue + 강제 | 고정% | 대조 필요 |
-| 회피 상한 | PC 0.9f | ? | **(확인 필요)** |
-| 카드 효과 트리거 | 분산 | 테이블 | 큰 차이 |
-
-### 6.5 성능
-
-- `ObscuredInt/Float` 복호화·재암호화 비용이 **Get_Damage 호출마다** 발생. 크리 판정/피해 계산에서 프레임당 수십 회. → Profiler 측정 필요.
-
-### 6.6 버그 냄새
-
-1. 중복 획득 방지 — 특수 아이템 `list_SkillId` 경로 **(확인 필요)**
-2. OnEvent 순서 의존성 — `AddSkillCard` ↔ `RunSkillCard` 순서
-3. G5 카드 스킵 로직 — 이미 획득 상태 체크 누락 가능성
-
----
-
-## 7. B-2 완료 조건 체크리스트
-
-**필수**
-- [ ] 311개 전체 eCardType 하드카피 리스트 (문자열 ID)
-- [ ] 각 카드의 대표 분기점 매핑 (OnEvent_*)
-- [ ] G5 미구현/주석 목록 확보
-- [ ] `table_cardlist` 필드 ↔ 엑셀 컬럼 1:1 매핑 확정
-- [ ] eLvUpType 전 케이스 동작 테스트
-- [ ] IsObtainCardSkill 258 호출 위치 전수 지도 (누락 확인)
-
-**선택**
-- [ ] 기획 엑셀 매크로 방정식 덤프 (코드 수식과 대조)
-- [ ] 카드 의존성 그래프
-- [ ] ObscuredFloat 프로파일링
-
----
-
-## 8. 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|---|---|---|---|
-| v1 | 2026-04-14 | 개발실장 (Explore 위임) | Phase 0-B-2 초안 |
diff --git a/프로젝트/수상한잡화점/개발/10_데이터로딩_구조_v1.md b/프로젝트/수상한잡화점/개발/10_데이터로딩_구조_v1.md
deleted file mode 100644
index 8343773..0000000
--- a/프로젝트/수상한잡화점/개발/10_데이터로딩_구조_v1.md
+++ /dev/null
@@ -1,223 +0,0 @@
-# 10. 데이터 테이블 로딩 · 캐싱 구조 v1
-
-- 작성일: 2026-04-14
-- 작성자: 개발실장 (Explore 에이전트 분석 위임)
-- 목적: 기획실 엑셀(.xlsm) SOT가 Unity 런타임에 닿기까지의 **로딩·캐싱·조회·보안·버전관리** 구조 확정
-- 스코프: `Assets/Script/Table/`, `Assets/ResWork/Table/Export/`, `MyClass.cs` 내 베이스 타입
-- 선행: `08_전투시스템_SOT_v1.md`, `09_카드시스템_아키텍처_v1.md`
-
----
-
-## 1. 로더 아키텍처
-
-### 1.1 베이스 계층
-
-| 타입 | 파일 | 역할 |
-|---|---|---|
-| `table_base` (MonoBehaviour) | `Assets/Script/Table/table_base.cs` (1~27) | TextAsset → json 문자열 캐시, LoadComplete 플래그, 문자열 값 파서 |
-| `TableDataBase` | `Assets/Script/My/MyClass.cs:23~45` | `Get_Name`, `Get_Desc`, `Get_ImagePath`, `Get_Value` 공통 인터페이스 |
-| `MissionTableDataBase` | `Assets/Script/My/MyClass.cs:137~145` | 미션·업적 공통 필드 |
-| `MonoBehaviourSingletonTemplate<T>` | `Assets/Script/Template/MonoBehaviourSingletonTemplate.cs` | `public static T Ins` / `public static bool isIns` / Awake에서 자기 주입 |
-
-### 1.2 초기화 라이프사이클
-
-```
-Awake:  json_last = m_json.text;      // 문자열만 유지
-        Resources.UnloadAsset(m_json); // TextAsset 객체는 언로드
-Start:  tableDatas = JsonConvert.DeserializeObject<List<T>>(json_last);
-        // Dictionary 인덱스 구축
-        LoadComplete = true;
-```
-
-- JSON 라이브러리: **Newtonsoft.Json** (`using Newtonsoft.Json;` 전 테이블 공통)
-- 모든 테이블이 `Start()`에서 병렬적으로 역직렬화. `TableChecker.CheckAllLoad()`로 완료 확인 (`TableChecker.cs:12~22`).
-- 타이틀/인게임 진입 시 `while (!TableChecker.Ins.CheckAllLoad()) yield return null;` 으로 블로킹 대기 (`Title_Mgr.Co_Check()` · `InGameInfo.Start()`).
-
-### 1.3 메모리 레이아웃
-
-```
-TextAsset JSON
-  → string json_last
-    → List<T> tableDatas                // 순차 접근
-    → Dictionary<Key, T> dic_*           // O(1) 조회 (ID·Enum·등급 등 다중 인덱스)
-```
-
-예: `table_cardlist` 는 `tableDatas`, `dic_gradeData`, `dic_Data`(eCardType), `dic_Data_byID`(int) 4중 인덱스 유지 (`table_cardlist.cs:451~454`).
-
----
-
-## 2. 조회 API 패턴
-
-### 2.1 권장 패턴 — `Get_*_orNull`
-
-```csharp
-public ActorListTableData Get_Data_orNull(string key)
-    => dic_Data.ContainsKey(key) ? dic_Data[key] : null;
-```
-
-### 2.2 폴백 메시지 패턴
-
-```csharp
-// table_localtext
-public string Get_Talk(int patternid)
-    => dic_Data.ContainsKey(patternid) ? /* ... */ : $"No ActorTalk {patternid}";
-```
-
-### 2.3 위험 패턴 — Direct 인덱서
-
-```csharp
-// table_cardlist
-public CardListTableData Get_Data(eCardType type) => dic_Data[type]; // KeyNotFoundException 가능
-// table_GlobalValue
-public int Get_Int(string id) => dic[id]; // 동일 위험
-```
-
-→ **리스크**: 문자열 키 오타, 미등록 카드 추가 시 런타임 크래시. B-3 개선 과제로 제안: 전체 `Get_*`를 TryGet 또는 `_orNull` 패턴으로 정규화.
-
----
-
-## 3. JSON 익스포트 워크플로
-
-### 3.1 경로
-
-| 단계 | 경로 |
-|---|---|
-| SOT 엑셀 | `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/DeckBuilding.xlsm` (최근 수정 2026-04-14) |
-| 백업 | 동 경로 `DeckBuilding_Ino.xlsm` |
-| 익스포트 결과 | `Assets/ResWork/Table/Export/` — **JSON 58개 + CSV 일부** (총 ~3.3 MB) |
-| 에디터 도구 후보 | `Assets/Editor/` — `MyEditorUtil.cs`에는 익스포트 코드 **없음**. **(확인 필요)** 외부 VBA/Python 스크립트 가능성 |
-
-### 3.2 주요 JSON 파일 크기 Top 5
-
-| 파일 | 크기 |
-|---|---|
-| `PCAwakening.json` | 442 KB |
-| `StatusOptionSet.json` | 354 KB |
-| `Localization.json` | 261 KB |
-| `CardList.json` | 180 KB |
-| `MonsterList.json` | 157 KB |
-
-### 3.3 CSV 혼재
-
-일부 테이블(예: `ApprearMonsterPattern.csv`)이 CSV로 내보내짐. 파싱 경로가 JSON과 이원화될 수 있어 **(확인 필요)**.
-
----
-
-## 4. 핫패스 테이블 접근
-
-`Actor.Get_Dmg()` 기준 전투 루프에서 접근되는 테이블:
-
-| 테이블 | 호출 | 빈도 |
-|---|---|---|
-| `table_GlobalValue.Ins.Get_Int("PCDefence")` | `Actor.cs:775` | **피해 계산마다** — 고빈도 |
-| `table_GlobalValue.Ins.Get_Float("PCDefence_Mul")` | `Actor.cs:783` | 동 |
-| `table_PCUniqueAwakening.Ins.Get_Data()` | `Actor.cs:793` | 피해 계산마다 |
-| `table_cardlist.Ins.Get_Data()` | `Actor.cs:118` | 카드 초기화 시 |
-| `table_SanctuaryConfig.Ins` / `table_StatusOptionSet.Ins` | `Actor.cs:158~159` | 부활·상태이상 이벤트 시 |
-| `table_StatusConditionsList.Ins.Get_Data_orNull()` | `Actor.cs:930` | 부활 |
-| `table_PCAwakening.Ins.Get_Value()` | `Actor.cs:937` | 부활 회복 계산 |
-
-**개선 여지**: `PCDefence`·`PCDefence_Mul` 처럼 피해 계산마다 문자열 키로 GlobalValue를 조회하는 경로는 **한 번 캐시**해두면 알로케이션·딕셔너리 조회 비용이 줄어듦. 모바일 타깃에서는 유효.
-
----
-
-## 5. 런타임 교체 · 서버 연동
-
-### 5.1 Hot-reload
-
-- 런타임 테이블 교체 코드 **확인 안 됨**. Dictionary 자체는 수정 가능하지만 공식 경로 없음.
-- Addressables 연동 **(확인 필요)** — `Res_Addr/` 폴더는 존재하나 테이블 JSON은 현재 TextAsset Resources 방식.
-
-### 5.2 ServerData 오버라이드
-
-- 경로: `Assets/Script/Server/ServerClass.cs` 의 `ServerData`
-- Actor 생성 시 주입: `Actor.Set(int identity, ActorTableDataBase actordata, HUD_HPShield hud, ServerData sdata = null)`
-- 쓰임: 각성·봉인 값 등 서버 계정 데이터로 테이블 값 일부 오버라이드 — `Get_ServerData().Get_PCAwakenLv(...)`
-
-**결론**: 런타임 재조정은 **테이블 교체가 아닌 사용자 데이터 오버라이드** 방식으로 제한됨. 밸런싱 hot-reload는 미지원 — Phase 1+ 과제.
-
----
-
-## 6. 보안 · 변조
-
-### 6.1 런타임 암호화 (CodeStage AntiCheat)
-
-- `ObscuredInt` / `ObscuredFloat` 사용. 예: `CardListTableData._ID`, `BattleLevelUpTableData._Lv`, `MissionTableDataBase._Index`.
-- 세터에서 `RandomizeCryptoKey()` 재수행 — 키 갱신.
-- 메모리 스캔·치트엔진 공격 완화 목적.
-
-### 6.2 디스크 JSON
-
-- **평문 저장**. StreamingAssets/Resources로 빌드 포함 → APK 분해 시 노출.
-- 클라이언트 변조 가능성 높음 — 서버 검증 필수 영역.
-
-### 6.3 서버 검증
-
-- PlayFab Editor Extensions 존재 (`Assets/PlayFabEditorExtensions/`) — 실 운영 API 연동 **(확인 필요)**.
-- 05번 문서(서버연동 현황)에서 도출된 **Critical 3건** 보류 상태와 직결. (IAP 미검증·전투 클라 100%·AES 평문키)
-
----
-
-## 7. 리스크 · 이슈
-
-| 항목 | 영향 | 개선 방향 |
-|---|---|---|
-| 엑셀→JSON 수동 익스포트 | 기획 수정 후 반영 누락 가능 | 자동화 스크립트 + CI 통합 |
-| 다중 엑셀 파일 (Ino 백업) | 어느 게 SOT인지 혼동 | 파일명 규칙·버전 태그 명시화 |
-| CSV·JSON 혼재 | 파싱 경로 분기 | JSON으로 일원화 검토 |
-| Direct 인덱서 사용 | 미등록 키 시 크래시 | `_orNull`/`TryGet` 표준화 |
-| JSON 평문 | 클라 변조 | 빌드 시 암호화 래퍼 or 바이너리 포맷 |
-| GlobalValue 문자열 키 핫패스 | 모바일 GC·딕셔너리 조회 비용 | 상수 캐시 / enum 키 도입 |
-| 테이블 버전 메타 없음 | 롤백·동기화 추적 곤란 | JSON 헤더에 version/buildId 도입 |
-
----
-
-## 8. 테이블 인벤토리
-
-- `Assets/Script/Table/Tables/` 아래 **51개 `table_*` 클래스**
-- Export/ 아래 **58개 JSON + 소수 CSV**
-- 대표:
-  - `table_ActorList` (534 B), `table_BuffPatternConfig` (2.6 KB)
-  - `table_cardlist` (180 KB), `table_Achievement` (247 KB)
-  - `table_ApprearMonsterPattern` (56 KB), `table_localtext` (다국어)
-  - `table_GlobalValue` (스칼라 파라미터 핫패스)
-
-전수 목록은 필요 시 별도 부록으로 추출 가능.
-
----
-
-## 9. B-3 완료 조건 체크리스트
-
-- [x] 로더 계층·싱글톤 패턴 확정
-- [x] 초기화 라이프사이클(Awake 캐시 → Start 파싱) 확정
-- [x] 조회 API 3패턴(`_orNull`/폴백 메시지/Direct) 확정
-- [x] 핫패스 테이블 호출 맵
-- [x] ObscuredTypes 적용 범위 확인
-- [ ] **Excel → JSON 익스포트 도구 실체 확인** (Editor 스크립트 vs VBA/외부) **(확인 필요)**
-- [ ] Addressables 연동 여부 확인
-- [ ] PlayFab 서버 검증 실제 호출 경로 확인
-- [ ] 전체 51개 테이블 인벤토리 부록화
-- [ ] Direct 인덱서 전수 목록화 후 정규화 과제 티켓화
-- [ ] JSON 암호화 방안 설계(타입 결정 + 빌드 파이프라인 반영)
-
----
-
-## 10. 기획실 워크플로 접점 요약
-
-| 단계 | 담당 | 산출 | 검증 |
-|---|---|---|---|
-| 밸런싱 작업 | 기획실 | `DeckBuilding.xlsm` | 기획 자체 검토 |
-| 익스포트 | **(확인 필요)** | `Export/*.json` | 파일 타임스탬프 비교 |
-| 빌드 포함 | Unity 빌드 | APK 내 TextAsset | TableChecker LoadComplete |
-| 런타임 조회 | 코드 | Dictionary 조회 | — |
-| 서버 오버라이드 | PlayFab | ServerData 주입 | 로그인 직후 |
-
-→ **단일 취약점**: "익스포트 단계"가 자동화되지 않은 것으로 보이는 지점. 개발실 우선 정비 후보.
-
----
-
-## 11. 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|---|---|---|---|
-| v1 | 2026-04-14 | 개발실장 (Explore 위임) | Phase 0-B-3 초안 |
diff --git a/프로젝트/수상한잡화점/개발/11_UI아키텍처_v1.md b/프로젝트/수상한잡화점/개발/11_UI아키텍처_v1.md
deleted file mode 100644
index e0c9a3b..0000000
--- a/프로젝트/수상한잡화점/개발/11_UI아키텍처_v1.md
+++ /dev/null
@@ -1,166 +0,0 @@
-# 11. UI 아키텍처 — 수상한 잡화점
-
-> **작성일**: 2026-04-17
-> **작성자**: 개발팀장
-> **상태**: v1 (초판, Phase 0-B 연계 문서)
-> **대상**: `Assets/Script/UGUI/` 전수 (Ingame 19 + Lobby 19 + Common/Title/Util/Manager/BackKey 등)
-> **관련 문서**: `08_전투시스템_SOT_v1.md`, `09_카드시스템_아키텍처_v1.md`, `10_데이터로딩_구조_v1.md`
-
----
-
-## 1. 목적 (P18 §결정의 배경)
-
-수상한 잡화점 UI 계층의 **구조·주요 매니저·상호작용 패턴**을 전수 식별하여:
-1. 전투·카드·데이터 문서(08·09·10)에 이은 Phase 0-B 완결 (UI는 기획 밸런싱·시뮬레이션의 최종 표시 계층)
-2. 코어 프레임워크 Tier 1 `BurningTimes.UI.UGUI`·`BurningTimes.UI.Components`에 흡수할 **범용 패턴 vs 프로젝트 특수 로직** 경계 확정 (C11)
-3. UI 기획 연동·UX 검증 작업 시 영향 범위 식별에 필요한 **단일 SOT**
-
-## 2. 전체 계층 구조
-
-```
-UGUI/
-├── Manager/          UI 전역 매니저 계층 — 씬·팝업·로딩 브릿지
-├── BackKey/          Android 뒤로가기 통합 처리
-├── Common/           씬 공용 (GameUI, ScenarioUI, ToastUI, ControlUI 등)
-├── Util/             SafeArea, UI 확장 컴포넌트
-├── Title/            타이틀·로딩·공지·계정 진입 흐름
-├── Lobby/            로비 씬 UI (19개 스크립트)
-│   ├── LobbyUIManager        ← 로비 최상위 오케스트레이터
-│   ├── LobbyTopUI, MoneyCard
-│   ├── MainMenu/             영웅·카드·장비·미션·상점 (Base + 5개 탭)
-│   ├── Attandance/           출석 보상
-│   ├── CatTrade/             상점(고양이 상인) — 재화·장비·인장·메인 미션 통합 (11종)
-│   ├── Explore/              탐험 — 지도·스테이지·보상 (7종)
-│   ├── SeasonPass/           시즌 패스 (2종)
-│   └── ETC/
-├── Ingame/           전투·던전 씬 UI (19개 스크립트)
-│   ├── IngameUIManager       ← 인게임 최상위 오케스트레이터 (153 LOC)
-│   ├── DungeonProcess        ← 스테이지 진행 UI (67 LOC)
-│   ├── SelectCardUI          ← 카드 선택 (290 LOC, 최대 UI 단일 모듈)
-│   ├── BattleCard, BattleSmallCard, DeckUI, DeckUI_Skills, DeckUI_My4Spec
-│   ├── GainCardList, IngameTopUI, SpecificityCard/List
-│   ├── MerchantBuyPopup, PCMainStatUI, IngameMainStatCard
-│   ├── Result/               DefeatUI, WinUI, StageClearRewards, ResultComon
-│   └── ETC/
-└── zTestUI/
-```
-
-## 3. 최상위 매니저 3종 — 오케스트레이션 책임
-
-### 3-1. `LobbyUIManager` (Lobby/LobbyUIManager.cs, 202 LOC)
-- 로비 씬 전체 UI 탭 전환·활성화 제어
-- 탭 구성: MainMenu(영웅/카드/장비/미션/상점) · Attandance · CatTrade · Explore · SeasonPass
-- 각 탭 자체 열림 상태·재진입 초기화 책임은 하위 UI에 위임하되, **탭 간 배타 활성은 본 매니저가 통제**
-
-### 3-2. `IngameUIManager` (Ingame/IngameUIManager.cs, 153 LOC)
-- 인게임(전투) 씬 UI 전역 오케스트레이터
-- 주요 책임: `DungeonProcess` 연동, 전투 카드 스폰/회수, 결과 UI(Result/) 트리거
-- 08 전투시스템 SOT 문서의 FSM 상태 전환 이벤트를 구독하여 UI 표시 갱신
-
-### 3-3. `Title_Mgr` (Manager/Title_Mgr.cs)
-- 타이틀 씬 진입 — 로딩·공지·계정 인증 흐름 제어
-- `AddrResourceMgr`·`DataCheckMgr`와 협력 (Addressable 로드·마스터 데이터 체크)
-
-## 4. 공통 UI 컴포넌트 (Common + Util)
-
-| 컴포넌트 | 위치 | 범용성 | 프레임워크 흡수 대상 |
-|---------|------|--------|--------------------|
-| `GameUI` | Common/GameUI.cs | ★ 매우 높음 (UIView 추상화 출발점) | ✅ `BurningTimes.UI.UGUI.UIView` |
-| `ScenarioUI` | Common/ScenarioUI.cs | △ 프로젝트 특수 (시나리오 시스템) | ❌ 프로젝트 유지 |
-| `ToastUI` | Common/ToastUI.cs | ★ 매우 높음 | ✅ `BurningTimes.UI.Components` |
-| `TouchBlockUI` | Common/TouchBlockUI.cs | ★ 매우 높음 | ✅ `BurningTimes.UI.Components` |
-| `ControlUI`/`ControlUILock` | Common/ | ○ UI 입력 잠금 패턴 | ✅ `BurningTimes.UI.Components` |
-| `MainStatCardBase` | Common/MainStatCardBase.cs | △ 프로젝트 카드 베이스 | ❌ 프로젝트 유지 |
-| `ItemSimpleCard` | Common/ItemSimpleCard.cs | △ 프로젝트 아이템 카드 | ❌ 프로젝트 유지 |
-| `SafeArea` | Util/ (추정) | ★ 매우 높음 | ✅ `BurningTimes.UI.Components.SafeArea` |
-| `UIAtlasMgr` | UGUI/Manager/uScrollViewMgr 계열 | ★ 높음 | ✅ `BurningTimes.UI.UGUI.AtlasManager` |
-| 무한 스크롤 (`uScrollViewMgr`·`uScrollViewArrMgr`) | UGUI/Manager/ | ★ 높음 | ✅ `BurningTimes.UI.UGUI.VirtualScroll` |
-
-> 범용성 표기: ★=1순위 흡수 · ○=2순위 · △=프로젝트 특수 · ❌=범용 불가
-
-## 5. 핵심 UI 모듈 — 카드 중심 설계
-
-### 5-1. BattleCard / BattleSmallCard (Ingame)
-- 전투 중 실제 표시되는 카드 UI. 09 카드시스템 아키텍처의 런타임 표시 계층
-- 지속 인스턴스 풀링 대상 (프레임 당 다수 스폰/회수)
-
-### 5-2. SelectCardUI (Ingame, 290 LOC — 최대 단일 UI 모듈)
-- 카드 선택(획득 후보 3장 중 1장 선택) UI
-- 제약 조건(C7 재미): 선택 시간·UX 피드백·희귀도 연출이 집약됨
-- **프레임워크 흡수 비대상** — 프로젝트 특수 선택 규칙 (배제 조건·카드 풀 계산 등)
-
-### 5-3. DeckUI 계열 (DeckUI, DeckUI_Skills, DeckUI_My4Spec)
-- 데크·스킬·4스펙(고유 특성) 표시 UI
-- 슬롯 기반 그리드 배치 패턴 → VirtualScroll·GridPool 흡수 후보
-
-### 5-4. DungeonProcess (Ingame, 67 LOC)
-- 스테이지 진행 UI — 맵 패턴·배틀·이벤트·보스 표시
-- 맵 패턴 규칙(P17·기획팀 스테이지 설계)의 UI 표현 계층
-
-## 6. 로비 기능별 UI 클러스터
-
-### 6-1. MainMenu — 영웅·카드·장비·미션·상점 (5탭)
-- `Base/`: 공통 베이스
-- `1_Hero`·`2_Card`·`3_Equipment`·`4_Mission`: 각 탭 세부 (숫자 접두어 = 표시 순서)
-- `MainMenu_Shop.cs`: 상점 탭(본 스크립트는 `5_Shop` 폴더가 아닌 루트에 존재 — 폴더 미정립)
-
-### 6-2. CatTrade — 상점(고양이 상인) 통합 (11개 스크립트, 로비 내 최대 클러스터)
-- 재화 거래(`CatTradeUI_Goods`)
-- 장비 거래(`CatTradeUI_Equipment` + `CatTradeEquipmentBuyPopup` + `EquipmentTradeInvenCard`)
-- 메인 미션(`CatTradeUI_MainMission`)
-- 인장(`CatTradeUI_Seal` + `GetSealUI` + `SealRoulleteCard` + `SealSlotScroller`)
-- 재화 카드(`CatTradeGoodsCard`)
-
-### 6-3. Explore — 탐험 (7개 스크립트)
-- 맵(`ExploreUI_Map`·`ExploreMapName`·`ExploreUI_Map_Cloud`(안개)): 맵 노드·구름 연출
-- 스테이지(`ExploreUI_StageSelect`·`ExploreStageCard`): 노드 선택·카드 표시
-- 보상(`ExploreRewardPopup`)
-
-### 6-4. SeasonPass · Attandance
-- 시즌 패스(`SeasonPassUI`·`SeasonPassCard`): 트랙·레벨·보상 표시
-- 출석(`AttandanceUI`·`AttandanceCard`): 일일 보상 슬롯
-
-## 7. BackKey 통합 처리
-
-- `BackKey/` 디렉토리: Android `Escape` 키 통합 처리
-- 열린 UI 스택 관리 → 가장 위 UI부터 순차 닫기
-- **프레임워크 흡수 후보**: `BurningTimes.UI.UGUI.BackKeyDispatcher` (안드로이드 필수 패턴)
-
-## 8. 프레임워크 Tier 1 흡수 계획 (범용성 ★ 우선)
-
-차기 프로젝트 활용을 위한 **범용 UI 프레임워크** 구성 요소:
-
-| 모듈 | 네임스페이스 | 수상한 잡화점 출처 |
-|------|------------|------------------|
-| UIView 추상 베이스 | `BurningTimes.UI.UGUI.UIView` | `Common/GameUI` |
-| SafeArea | `BurningTimes.UI.Components.SafeArea` | `UGUI/Util/SafeArea` |
-| Toast | `BurningTimes.UI.Components.Toast` | `Common/ToastUI` |
-| 입력 차단 | `BurningTimes.UI.Components.InputBlocker` | `Common/TouchBlockUI`·`ControlUI` |
-| 아틀라스 매니저 | `BurningTimes.UI.UGUI.AtlasManager` | `UGUI/Manager/UIAtlasMgr` |
-| 무한 스크롤 | `BurningTimes.UI.UGUI.VirtualScroll` | `UGUI/Manager/uScrollView*Mgr` |
-| BackKey 디스패처 | `BurningTimes.UI.UGUI.BackKeyDispatcher` | `BackKey/` |
-
-## 9. 기획 연동 포인트 (UX 검증 시 영향 범위)
-
-| 기획 변경 범주 | 영향 UI 모듈 |
-|---------------|------------|
-| 카드 조건·배타(P17) | `SelectCardUI`, `SpecificityCard/List` |
-| 스테이지 맵 패턴 | `DungeonProcess`, `ExploreUI_Map`·`ExploreUI_StageSelect` |
-| 보상 수치 | `ExploreRewardPopup`, `StageClearRewards`, `Result/WinUI` |
-| 상점 재화 밸런스 | `CatTradeUI_*`, `MerchantBuyPopup`, `MoneyCard` |
-| 시즌 패스 보상 트랙 | `SeasonPassUI`, `SeasonPassCard` |
-| 출석 보상 | `AttandanceUI`, `AttandanceCard` |
-
-## 10. 검증 방법 (P18 §검증)
-
-1. 각 행의 파일 경로는 `Assets/Script/UGUI/{클러스터}/{파일명}.cs`에서 실존 확인 가능 (본 문서 작성 시 `ls`로 전수 확인 완료)
-2. LOC 표기는 `wc -l` 결과 기준
-3. 범용성 분류(★/○/△/❌)는 의존성 스캔(Unity 타입·게임 특수 enum 참조 여부)로 재검증 가능
-
-## 11. 기각안 (P24 §기각안)
-
-- **기각안 A: UIToolkit 병행 매핑 문서화** — 기획 방향이 UGUI 단일이므로 UIToolkit 매핑은 차기 프로젝트 R&D로 이관 (본 문서는 UGUI 전수 한정)
-- **기각안 B: 각 스크립트 public API 메서드 전수 목록화** — 토큰 비용 과다 + 기획·검증 영향도 분류 목적에 불필요. 구조 수준 분류로 대체
-
-## 부록 A. 변경 이력
-- **v1 (2026-04-17)**: 초판. 개발팀장 Phase 0-B 완결 작업(B-4)으로 작성. Assets 전수 `ls` + 주요 파일 LOC 실측 기반.
diff --git a/프로젝트/수상한잡화점/개발/12_메타시스템_v1.md b/프로젝트/수상한잡화점/개발/12_메타시스템_v1.md
deleted file mode 100644
index 93c5d84..0000000
--- a/프로젝트/수상한잡화점/개발/12_메타시스템_v1.md
+++ /dev/null
@@ -1,204 +0,0 @@
-# 12. 메타시스템 — 수상한 잡화점
-
-> **작성일**: 2026-04-17
-> **작성자**: 개발팀장
-> **상태**: v1 (초판, Phase 0-B 연계 문서)
-> **대상**: 세이브/로드 · 진행도 · 상점 · 성장(장비·각성·인장) · 시즌패스 · 탐험 · 출석
-> **관련 문서**: `05_서버연동_현황_v1.md`, `09_카드시스템_아키텍처_v1.md`, `10_데이터로딩_구조_v1.md`, `11_UI아키텍처_v1.md`
-
----
-
-## 1. 목적 (P18 §결정의 배경)
-
-수상한 잡화점의 **비전투(메타) 시스템** 전체 계층을 식별하여:
-1. 전투(08) · 카드(09) · 데이터(10) · UI(11)에 이은 Phase 0-B 최종 완결
-2. 서버 역할 문서(05·PD 지시 #30·#31)와의 **메타 시스템 측 대응표** 제공
-3. 차기 프로젝트 프레임워크 `BurningTimes.Save`·`BurningTimes.Economy` Tier 2 설계에 필요한 **실증 패턴** 공급
-4. 기획 밸런싱·유저 경험 변경 시 **영향 범위 식별 SOT**
-
-## 2. 메타시스템 전체 맵
-
-```
-메타시스템 = "전투 외 유저 진행·성장·경제 시스템"
-
-┌─────────────────────────────────────────────────────────────┐
-│  클라이언트 로컬 상태 (Assets/Script/Info/)                   │
-│  ├── ActorInfo        — 캐릭터·영웅 상태                      │
-│  ├── InGameInfo       — 인게임 진행 상태                       │
-│  ├── InappInfo        — 인앱 결제 영수증·트랜잭션              │
-│  ├── OptionInfo       — 유저 옵션(사운드·언어·그래픽)          │
-│  ├── TitleInfo        — 타이틀·공지                            │
-│  ├── ADInfo           — 광고 상태                              │
-│  ├── SoundInfo, WebViewInfo, UtilInfo, Popup, NetWait        │
-│  └── (*.Info 단일 데이터 클래스 + 매니저 스타일)                │
-└─────────────────────────────────────────────────────────────┘
-                  ↕ (마스터 테이블 조회, 10 문서)
-┌─────────────────────────────────────────────────────────────┐
-│  서버 연동 (Assets/Script/Server/)                            │
-│  ├── ServerClass.cs   — 서버 응답/요청 DTO                    │
-│  ├── ServerInfo.cs    — 서버 상태·세션 관리                   │
-│  └── (PlayFab 전제, 05 문서 및 서버 지시서 v1.1/v1.2 참조)    │
-└─────────────────────────────────────────────────────────────┘
-                  ↕ (UI 표시, 11 문서)
-┌─────────────────────────────────────────────────────────────┐
-│  UI 계층 (Assets/Script/UGUI/Lobby/)                          │
-│  └── 본 문서 §4 각 시스템별 UI 매핑                            │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## 3. 세이브/로드 구조
-
-### 3-1. 현 구조 (PlayFab 중심)
-- **원본**: PlayFab(`UserData`/`TitleData`/`PlayerStatistics`) — 서버 지시서 v1.1 §4·§5 기준
-- **로컬 캐시**: `Info/*.Info` 각 클래스 내부에 필드 보존 + 필요 시 `PlayerPrefs` 부분 저장(옵션·로컬 전용)
-- **인코딩**: JSON(PlayFab 기본 직렬화) + `My/CryptoUtil.cs` 적용분은 일부 (세이브 전반 체계화 안 됨)
-
-### 3-2. 약점·리스크
-1. **SOT 분리 모호** — `*.Info` 클래스가 "런타임 상태 + 저장 대상" 이중 역할
-2. **세이브 스키마 버전 관리 부재** — 필드 추가/제거 시 마이그레이션 전략 없음
-3. **로컬/서버 동기화 타이밍이 호출부에 산재** — 조회 시마다 서버 호출 or 캐시 사용 판단 분산
-
-### 3-3. Tier 2 `BurningTimes.Save` 설계 반영 포인트
-- `ISaveProvider` 인터페이스 (PlayerPrefs / JSON / 암호화 / 클라우드)
-- 버전 마이그레이션 훅(`IMigration`) 신설
-- 세이브 대상 POCO와 런타임 상태 클래스 분리 (DTO 패턴)
-
-## 4. 진행도 · 성장 · 경제 시스템 (영역별)
-
-### 4-1. 영웅·카드·장비·각성·인장 (성장)
-
-| 시스템 | 클라 코드 위치 | UI 클러스터 | 마스터 테이블 |
-|--------|--------------|-----------|-------------|
-| 영웅 (Hero) | `Info/ActorInfo.cs` + 스킬·스펙 서브 | `Lobby/MainMenu/1_Hero/` | Hero, Skill, HeroSkill |
-| 카드 (Card) | 09 문서 런타임 모듈 + `Info/` | `Lobby/MainMenu/2_Card/` | Card, CardEffect |
-| 장비 (Equipment) | `Info/`·CatTrade 관련 | `Lobby/MainMenu/3_Equipment/`·`Lobby/CatTrade/CatTradeUI_Equipment.cs` | Equipment, EquipmentOption |
-| 미션 (Mission) | `Info/`·`CatTradeUI_MainMission` | `Lobby/MainMenu/4_Mission/`·`Lobby/CatTrade/CatTradeUI_MainMission.cs` | Mission, MissionReward |
-| 인장 (Seal) | CatTrade Seal 서브 | `Lobby/CatTrade/CatTradeUI_Seal.cs`·`GetSealUI.cs`·`SealRoulleteCard.cs`·`SealSlotScroller.cs` | Seal, SealOption |
-
-### 4-2. 상점 (CatTrade — 고양이 상인)
-- **구조**: 단일 상인이 5개 카테고리(재화·장비·인장·메인 미션 + 공통 Goods) 통합 제공
-- **UI 클러스터**: `Lobby/CatTrade/` 11개 스크립트 (로비 최대 클러스터, 11 문서 §6-2 참조)
-- **특수 로직**:
-  - 인장 룰렛(`SealRoulleteCard`·`SealSlotScroller`): 슬롯머신 연출 — 확률 기반 획득
-  - 장비 구매 팝업(`CatTradeEquipmentBuyPopup`) + 기존 보유 장비 비교(`EquipmentTradeInvenCard`)
-
-### 4-3. 탐험 (Explore — 스테이지 선택)
-- **구조**: 맵 → 스테이지 노드 선택 → 전투 진입 or 이벤트
-- **UI 클러스터**: `Lobby/Explore/` 7개 스크립트 (11 문서 §6-3)
-- **저장 대상**:
-  - 현재 탐험 지도 ID·해제된 노드
-  - 각 노드 클리어 여부·최고 스코어(3성 조건 달성)
-  - 탐험 보상 수령 이력
-- **P17 연계**: 스테이지별 ★ 조건 배치는 마스터 테이블(기획팀 `Stage`·`StarCondition`)에서 읽어 `ExploreUI_StageSelect`에 표시
-
-### 4-4. 시즌 패스
-- **UI**: `Lobby/SeasonPass/SeasonPassUI.cs`·`SeasonPassCard.cs`
-- **저장 대상**: 현재 시즌 ID·시즌 진행도 경험치·무료/유료 트랙별 수령 레벨
-- **서버 동기화 필요**: 시즌 교체·유료 트랙 결제 영수증 (PlayFab)
-
-### 4-5. 출석
-- **UI**: `Lobby/Attandance/AttandanceUI.cs`·`AttandanceCard.cs`
-- **저장 대상**: 현재 월/회차·연속 출석일·수령 이력
-- **서버 시간 의존**: 날짜 조작 방지 위해 서버 시간 기준 (서버 지시서 §3 참고)
-
-## 5. 재화·경제 시스템
-
-### 5-1. 재화 종류
-- 수상한 잡화점은 **복수 재화 체계** (골드·다이아·이벤트 화폐·카드 조각 등)
-- 현 구조: `Info/*.Info` 내 변수 + 마스터 테이블 `Goods`·`Currency` 참조 추정
-- 표시 UI: `Lobby/LobbyTopUI.cs` + `Lobby/MoneyCard.cs` + 인게임 `IngameTopUI.cs`
-
-### 5-2. 획득 경로
-- 전투 클리어(`Ingame/Result/StageClearRewards`)
-- 탐험 보상(`Lobby/Explore/ExploreRewardPopup`)
-- 상점 구매(`Lobby/CatTrade/MerchantBuyPopup` 포함)
-- 인앱 결제(`Info/InappInfo.cs` + PlayFab 영수증 검증)
-- 광고 시청(`Info/ADInfo.cs`)
-- 출석·시즌 패스 보상
-
-### 5-3. 차기 프로젝트 흡수 (`BurningTimes.Economy`)
-- `Goods` 범용 재화 모델 (타입·수량·최대치·오버플로 정책) — 01 설계안 §6-0 기정립
-- 인벤토리·획득 이벤트 훅(`EventBus` 연동)
-- **본 프로젝트 특수 로직(재화 종류·상점 UX)은 흡수 불가** — 프레임워크는 "재화 모델 컨테이너"만 제공
-
-## 6. 서버 연동 상태 (05 문서 연계)
-
-### 6-1. 현 서버 범위 (PlayFab)
-- 세션/인증 → `ServerInfo.cs`
-- 유저 데이터 로드/저장 → `ServerClass.cs` DTO 매핑
-- 스테이지 결과 기록 → `Save_StageResult` API (서버 지시서 §6 샘플)
-- 인앱 영수증 검증 → PlayFab 영수증 검증
-
-### 6-2. 서버 역할 경계 (서버 지시서 §5·§6)
-- **클라 100% 책임**: 어뷰징 판정 (`is_abuse_flag`만 서버 전송, 경계값 보관·검증 안 함)
-- **서버 100% 책임**: 시간 기반 판정(출석·시즌 만료) · 영수증 검증 · 로그 집계
-- **양쪽 책임**: 세이브 동기화 (클라 전송 + 서버 검증 최소 필터)
-
-## 7. 메타시스템 의존성 그래프 (핵심 흐름)
-
-```
-로그인 → Title_Mgr
-    ↓ (서버 인증 → PlayFab)
-ServerInfo.Login → *.Info 다중 로드
-    ↓ (마스터 테이블 로드, 10 문서)
-DataCheckMgr·AddrResourceMgr
-    ↓
-LobbyUIManager.Initialize
-    ├→ LobbyTopUI (재화 표시)
-    ├→ MainMenu (영웅·카드·장비·미션 탭)
-    ├→ CatTrade (상점 진입)
-    ├→ Explore (탐험 진입)
-    │    ↓ (스테이지 선택)
-    │    IngameUIManager → 08 전투 FSM
-    │    ↓ (전투 종료)
-    │    StageClearRewards → *.Info 갱신 → ServerClass 전송
-    │    ↓
-    │    LobbyUIManager 복귀
-    ├→ SeasonPass / Attandance (보상 수령)
-    └→ Option/WebView 등
-```
-
-## 8. 기획 연동 포인트 (밸런싱·UX 변경 영향 범위)
-
-| 기획 변경 범주 | 영향 메타 모듈 |
-|---------------|--------------|
-| 재화 밸런스 (획득량·환율) | `Info/*.Info` 재화 필드 + `LobbyTopUI`·`MoneyCard`·`IngameTopUI` + 상점 UI 전체 |
-| 성장 곡선 (장비 레벨·인장 등급) | `MainMenu_Equipment`·`CatTrade Seal 계열` + 마스터 테이블 `Equipment`·`Seal` |
-| 시즌 패스 트랙 구성 | `SeasonPassUI`·`SeasonPassCard` + 서버 시즌 ID 갱신 |
-| 출석 보상 트랙 | `AttandanceUI`·`AttandanceCard` + 서버 시간 의존 |
-| 탐험 맵 구조 (노드·분기) | `ExploreUI_Map`·`ExploreStageCard` + 마스터 `ExploreMap`·`Stage` |
-| 상점 가격·확률 (룰렛 등) | `CatTrade*` 전체 + 마스터 `Shop`·`Seal` |
-
-## 9. 프레임워크 흡수 계획 (Tier 2 설계 반영)
-
-| 프레임워크 모듈 | 수상한 잡화점 출처 | 흡수 수준 |
-|--------------|------------------|---------|
-| `BurningTimes.Save.ISaveProvider` | 현 `*.Info` + PlayFab 호출 패턴 | 🟡 신규 인터페이스 (기존 구조는 참고만) |
-| `BurningTimes.Save.IMigration` | 없음 (부재 자체가 교훈) | 🔴 신규 설계 |
-| `BurningTimes.Economy.Goods` | `MoneyCard`·재화 Info 필드 | 🟢 구조 계승, 네이밍만 변경 |
-| `BurningTimes.Economy.Inventory` | 장비·인장·카드 목록 패턴 | 🟡 범용 컨테이너 추출 |
-| `BurningTimes.Network.IReceiptVerifier` | `Info/InappInfo.cs` + PlayFab 영수증 | 🟡 Tier 3 편입 (서버팀 합류 시점) |
-
-## 10. 현 프로젝트에서의 차기 개선 안건 (차기 프로젝트 참고 자료)
-
-> 헌법 제1원칙 목표 2 원칙 B: 수상한 잡화점 인사이트를 차기 프로젝트 참고 자료로.
-
-1. `*.Info` 단일 클래스에 "런타임 상태 + 직렬화 대상 + 서버 통신 DTO"를 모두 담는 구조는 차기 프로젝트에서 **반드시 분리** (DTO + 상태 + 리포지토리 3계층)
-2. 세이브 버전 관리 부재 → 차기 프로젝트 `IMigration` 훅 필수
-3. 서버/클라 동기화 타이밍이 호출부에 분산 → 차기 프로젝트는 **중앙 동기화 매니저** 도입
-4. 재화 종류가 하드코딩(필드 단위) → 차기 프로젝트는 `Goods` 범용 모델 + 타입 enum 기반 Dictionary 저장
-
-## 11. 검증 방법 (P18 §검증)
-
-1. 각 Info/Server/UGUI 파일 경로는 실제 Unity 프로젝트에서 실존 확인 완료 (작성 시 `ls` + `find` 실측)
-2. `find` 기반으로 `PlayFab`·`SaveData`·`UserData` 키워드를 검색한 결과는 `ServerClass.cs`·`ServerInfo.cs`·`Info/` 6개 파일로 집중됨 — 본 문서 §2 구조와 일치
-3. 마스터 테이블 이름은 10 문서(데이터 로딩) 및 서버 지시서 §6 샘플을 교차 참조하여 추정 (기획팀 테이블 정의 재확인 필요 표시)
-
-## 12. 기각안 (P24 §기각안)
-
-- **기각안 A: 각 Info 클래스의 필드별 세이브 대상 분류표 작성** — 토큰 비용 + 프레임워크 흡수 대비 정보량 과다. 구조 수준 분류로 대체. 필요 시 Phase 0-C에서 세부 감사
-- **기각안 B: 서버 API 전수 매핑** — 서버 지시서 v1.1/v1.2가 별도 SOT로 존재. 본 문서는 클라 메타 구조에 집중
-- **기각안 C: 메타시스템 보안 취약점 감사** — `05_서버연동_현황_v1.md` Critical 3건이 이미 추적 중(#2 보류). 본 문서는 중복 분석 안 함
-
-## 부록 A. 변경 이력
-- **v1 (2026-04-17)**: 초판. 개발팀장 Phase 0-B 최종 완결 작업(B-5)으로 작성. Unity 프로젝트 `Assets/Script/` 전수 `ls` + 키워드 `find` 실측 기반. 서버 지시서 v1.1/v1.2·05 문서·09·10·11 문서 교차 참조.
diff --git a/프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md b/프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
deleted file mode 100644
index 066a95b..0000000
--- a/프로젝트/수상한잡화점/개발/13_Phase3_재개로드맵_확정_v1.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-type: 설계문서
-project: 수상한잡화점
-subject: Phase 3 재개 로드맵 확정 (#38)
-version: v1
-date: 2026-04-20
-status: 확정
-author: 개발팀장
-related:
-  - 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md
-  - 공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md
-핵심원칙:
-  - Unity MCP EditMode 실측만을 단일 SOT로 채택
-  - 기존 Unity 코드(Assets/Script/) 불변
-  - 배경(과거형)과 현 상태(현재형) 섹션 분리
----
-
-# Phase 3 재개 로드맵 확정 v1 (#38)
-
-## 0. 문서 목적
-
-개발팀 #38 "Phase 3 재개 로드맵 — Unity MCP 단일축 밸런스 작업 재개 범위·선후관계·검증 축 확정" PD님 재개 지시 수령(2026-04-20) 후 개발팀 공식 SOT로 3요소 확정. 기획팀 `Phase3_재개준비_체크리스트_v1.md` 담당 매핑을 전제로 **개발팀 역할 + 병렬 진행 경계**만 본 문서가 확정한다.
-
----
-
-## 1. 배경 (과거형 기록 — 현 블로커 아님)
-
-### 1-1. 과거 HOLD 트리거 사유 (#28·#37에서 해결 완료)
-
-| 항목 | 과거 상태 | 해결 커밋 |
-|------|----------|----------|
-| Python 자체 시뮬 vs Unity 실 메커닉 수치 괴리 | Q-P2 정밀 2차에서 `PCDefence_Mul=0.3` 실측(기획 가정 50% 불일치) | #28 (2026-04-17 Unity MCP 단일축 전환 확정) |
-| Unity MCP 시뮬레이터 부재 | `Assets/Sim/` 독립 어셈블리 부재 | #37 (2026-04-17 `SimulationRunner`·`ScenarioLoader`·`ResultEmitter` + `ActorModel`·`DefenceModel`·`DamageCalc` 구현 완료) |
-
-본 섹션은 **역사적 배경 기록**이며, 본 로드맵 실행 시점 현 블로커가 아니다 (P28-8 · `feedback_resolved_cause_as_current_hold.md` 준수).
-
-### 1-2. 방향 확정 (재논의 대상 아님)
-
-- Unity MCP EditMode 실측 = Phase 3 v2 밸런스 산출의 **단일 SOT**
-- 기존 `Assets/Script/` 불변 (시뮬 코드는 `Assets/Sim/` 독립 어셈블리, Editor-only)
-
----
-
-## 2. 현 상태 (현재형 — 2026-04-20 기준)
-
-### 2-1. 재개 선행 조건 4종 현황 (`Phase3_재개준비_체크리스트_v1.md §1-1`)
-
-| # | 조건 | 담당 | 현 상태 |
-|---|------|------|--------|
-| 1 | Unity MCP EditMode 독립 어셈블리(`Assets/Sim/`) 시뮬 환경 구축 | 개발팀장 | ✅ 충족 (#37 완료) |
-| 2 | Unity MCP EditMode 실측 검증 (결정론·리플레이 보장) | 개발팀장 + 기획팀장 | ⏳ 미충족 (리포트 미작성) |
-| 3 | 기획팀용 Unity MCP 시뮬 실행 가이드 | 개발팀 | ⏳ 미충족 (`공유/소통/개발팀→기획팀/` 빈 폴더) |
-| 4 | PD님 재개 지시 | 총괄PM | ✅ 충족 (2026-04-20 수령) |
-
-**진단**: 4종 중 2·3 미충족. 그러나 이 둘은 기획팀이 Unity MCP 실행을 필요로 하는 작업(Day 2~3 Phase 0~2 재검증) 착수 전에만 충족되면 족하므로, **기획팀 Day 1 작업은 병렬 착수 가능**.
-
-### 2-2. 현 진행 블로커
-
-- **외부 블로커**: 없음. PD님 재개 지시 수령으로 모든 외부 트리거 해제.
-- **내부 선행 작업**: 조건 2·3 집행 필요 (개발팀 주도, 기획팀 Day 1과 병렬).
-
----
-
-## 3. 재개 범위 (3요소 ①)
-
-`밸런싱문서_일관성점검_v1.md §2` + Phase3 체크리스트 §2 기반.
-
-### 3-1. 본 로드맵 재개 범위 (28개 재검증 항목 전수)
-
-| 블록 | 재검증 항목 수 | 체크리스트 Day | 산출물 |
-|------|-------------|-------------|-------|
-| Phase 0~2 재검증 | 6건 (#1~#6) | Day 2~3 | `재검증보고_Phase0_1_2_v1.md` |
-| Phase 3 본작업 — 성장 요소 기여도 | 6건 (#16~#21) | Day 4~7 | **`Phase3_성장요소기여도_v2.md`** (신규) |
-| 이슈 1·3 통합 재논의 | 2건 | Day 8~10 | `이슈1_3_통합재논의_v1.md` |
-| 스테이지 난이도·맵 패턴 | 9건 (#11~#15·#22~#25) | Day 11~14 | `재검증보고_맵패턴_v1.md` + 42개 슬롯 배치안 |
-| 밸런싱 목표 재조정·v2 확정 | 5건 (#7~#10·#26~#28) | Day 15+ | `밸런싱전략_v1.md` §3 업데이트 |
-
-### 3-2. 범위 외 (본 로드맵 배제)
-
-- N7 방어 성공 조건 조건 풀 확장 → 별도 트랙 (`재논의대기_사전자료모음_v1.md §4-1`, #37 Q-P2 정밀 2차 실측 반영)
-- 서버 Critical 3건(#2) → 서버팀 가동 대기 (본 로드맵과 독립)
-
----
-
-## 4. 선후관계 (3요소 ②)
-
-### 4-1. 의존성 그래프
-
-```
-[개발팀] 조건 2 실측 검증 리포트 (Day 1~3)
-    │
-    ├─→ [개발팀] 조건 3 기획팀용 실행 가이드 (Day 1~3 병렬)
-    │       │
-    │       ↓
-    │   [기획팀] Day 2~3 Phase 0~2 재검증 6건 (조건 2·3 완결 필요)
-    │       │
-    │       ↓
-    │   [기획팀] Day 4~7 성장 요소 기여도 6건
-    │       │
-    │       ↓
-    │   [기획팀] Day 8~10 이슈 1·3 통합 재논의
-    │       │
-    │       ↓
-    │   [기획팀+레벨기획자] Day 11~14 맵 패턴 재검증
-    │       │
-    │       ↓
-    │   [기획팀장 → 총괄PM → PD님] Day 15+ v2 확정
-
-[기획팀] Day 1 체크리스트 + 3개 사전 산출물 재독 (선행 조건 2·3 무관, 독립 착수)
-```
-
-### 4-2. 병렬 실행 라인 (본 로드맵 핵심)
-
-| 라인 | 주체 | 작업 | 선행 조건 2·3 의존 |
-|------|------|------|----------------|
-| **A** | 개발팀 | 조건 2 실측 검증 리포트 작성 | — (본인이 조건 2) |
-| **B** | 개발팀 | 조건 3 기획팀용 실행 가이드 작성 | — (본인이 조건 3) |
-| **C** | 기획팀 | Day 1-1 체크리스트 전수 수행 | ❌ 무관 (독립 착수) |
-| **D** | 기획팀 | Day 1-4 기존 3개 사전 산출물 재독 | ❌ 무관 (독립 착수) |
-| **E** | 기획팀 | Day 2~3 Phase 0~2 재검증 6건 | ✅ A·B 완결 필요 |
-
-A·B·C·D는 **즉시 병렬 착수**. E는 A·B 완결 후 순차 착수.
-
----
-
-## 5. 검증 축 (3요소 ③)
-
-### 5-1. 정본(正) 판정 기준
-
-1. **Unity MCP EditMode 실측 = 정본** (Phase 3 v2 수치의 유일 근거)
-2. **오차 허용**: 동일 시나리오에서 Unity 실 빌드 PlayMode vs MCP 시뮬 결과 **10% 이내** (`01_시뮬레이터_아키텍처_v1.md §5-3`)
-3. **오차 초과 시**: Unity 실 빌드 결과를 정(正)으로, MCP 시뮬 모델 재조정 (`Phase3_재개준비_체크리스트_v1.md §6-1`)
-
-### 5-2. 결정론·리플레이 요건
-
-조건 2 검증 리포트에 다음을 실측으로 기록:
-- **결정론**: 동일 시나리오 JSON · 동일 시드 · 동일 빌드 해시 → 결과 JSON 완전 일치 (해시 대조)
-- **리플레이**: 결과 JSON 재주입 → 동일 tick 수 · 동일 최종 상태 재현
-
-### 5-3. Phase 3 v2 채택 조건
-
-- 성장 요소 기여도 목표치(`밸런싱문서_일관성점검_v1.md §2-4`)와 실측 대조 후 괴리 ±20% 이내면 수치 채택
-- 괴리 20% 초과 시 기획팀장이 Day 8~10 이슈 1·3 통합 재논의로 이관 후 PD님 판단 요청
-
-### 5-4. 회귀 방지
-
-Phase 3 v2 수치 확정 후 해당 시나리오를 `Assets/Sim/Tests/` 회귀 셋으로 보존하여 이후 `Assets/Script/` 밸런스 수정 시 회귀 여부 자동 검출 (향후 개발팀 후속 작업).
-
----
-
-## 6. 잔여 선행 조건 2·3 후속 집행 계획
-
-### 6-1. 조건 2 실측 검증 리포트 (담당: 개발팀장 + 기획팀장)
-
-산출물: `공유/소통/개발팀→기획팀/{YYYY-MM-DD}_Unity_MCP_실측검증_리포트_v1.md`
-
-최소 포함 항목:
-1. Unity Editor 버전 + 빌드 해시 (`Dev 브랜치 43b6074c4` 또는 최신)
-2. 시나리오 JSON 5종 실행 결과 (앵커 전투 1 + 카드 시너지 2 + 성장 요소 2)
-3. 결정론 검증 (3회 반복 실행 결과 해시 일치)
-4. 리플레이 검증 (결과 JSON 재주입 → 동일 최종 상태)
-5. Unity 실 빌드 PlayMode 대조 (5종 시나리오 중 앵커 1건 이상 대조)
-6. 오차 측정 및 원인 분석
-
-**Unity MCP 접근 환경 필요**. 본 세션 범위 밖 (C23 정직 — 실 Unity Editor + MCP 연결 환경 필요).
-
-### 6-2. 조건 3 기획팀용 실행 가이드 (담당: 개발팀)
-
-산출물: `공유/소통/개발팀→기획팀/{YYYY-MM-DD}_Unity_MCP_시뮬실행_가이드_v1.md`
-
-최소 포함 항목:
-1. Unity Editor 기동 절차 + MCP 연결 확인
-2. 시나리오 JSON 작성 규칙 (`02_시나리오_JSON_스키마_v1.md` 축약)
-3. `execute_code` 호출 스니펫 (`04_MCP_호출_스니펫_v1.md` 기반 기획팀 사용 시점 최적화)
-4. 결과 JSON 해석 (`03_결과_JSON_포맷_v1.md` 축약)
-5. 자주 발생 오류 TOP 5 + 해결법
-6. 기획팀→개발팀 에스컬레이션 경로 (REQ 템플릿 연계)
-
-### 6-3. 예상 소요 (C9-2 준수 — 일정 표현 없음)
-
-종속 관계만 명시:
-- 조건 2 완결 후 조건 3 최종본 산출 (조건 2 실측 결과를 가이드 예시에 반영)
-- 조건 3 완결 후 기획팀 Day 2~3 착수 가능
-
----
-
-## 7. 개발팀 역할 요약
-
-| 역할 | 담당 | 산출물 |
-|------|------|-------|
-| 조건 2 실측 검증 | 개발팀장 주도 + 기획팀장 공동 | 리포트 v1 |
-| 조건 3 실행 가이드 | 개발팀(클라이언트팀장 검토) | 가이드 v1 |
-| `Assets/Sim/` 메커닉 불일치 시 모델 재조정 | 개발팀 클라이언트팀 | `Models/*.cs` 수정 커밋 |
-| 기획팀 조건 판정 로직 구현 요청 대응 | 개발팀 클라이언트팀 | REQ 응답 |
-| 회귀 셋 보존 (Phase 3 v2 확정 후) | 개발팀장 | `Assets/Sim/Tests/` append |
-
-## 8. 기각안
-
-1. **조건 2·3 동시 완결 후 기획팀 전체 착수** — 병렬 라인 차단으로 조직 생산성 저하. 본 로드맵은 C·D 즉시 착수 채택
-2. **Python 시뮬 병행 교차 검증** — #28에서 기확정 폐기 사안. 재논의 대상 아님
-3. **Phase 3 범위 축소 v2 (성장 요소만)** — 일관성 점검 28개 재검증 항목 전수 처리가 조직 완성도 원칙 (C9) 부합
-
----
-
-## 참조
-
-- `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` (기획팀 SOT)
-- `프로젝트/수상한잡화점/시뮬레이터/01~04_*.md` (시뮬 인프라 설계)
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` (28개 재검증 항목 원천)
-- `공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md` (기획팀 공유본)
-
-## 변경 이력
-
-| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미/품질 근거 | 관련 PD 지시 |
-|------|-------|---------|-------------|-------------|-----------|
-| 2026-04-20 | 개발팀장 | 신규 작성 | — → v1 | #38 PD님 재개 지시 수령 후 3요소(재개 범위·선후관계·검증 축) 확정 필요 | 개발팀 #38 |
diff --git a/프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md b/프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md
deleted file mode 100644
index b665172..0000000
--- a/프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md
+++ /dev/null
@@ -1,748 +0,0 @@
-# 수상한 잡화점 — ★ 조건 12개 풀 상세 명세서 v1
-
-> 작성일: 2026-04-14 / 최신화: 2026-04-18
-> 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
-> 위임 근거: 2026-04-14 PD님 지시 "Phase 3 작업 전 진행 가능한 작업을 기획팀장이 판단하에 진행"
-> 문서 성격: **P18 설계 문서화 의무** 이행 (Phase 2 §5 PD님 3차 승인의 조건 풀 12개에 대한 본문 작성)
-> HOLD 준수: 본 문서는 **판정 로직·측정 변수·UI 표시·개발팀 구현 요청**까지만 다룸. 구체적 수치 최종 확정은 Phase 3 재개 후 시뮬 검증으로 수행
-
----
-
-## 0. 본 문서의 목적·범위
-
-### 목적
-Phase 2 §5에서 PD님 3차 승인으로 확정된 **★ 조건 풀 12개**(+N7 실측 완료, 조건 풀 13번째 추가 여부 Phase 3 재개 시 PD님 결정 대기)에 대해, 각 조건별:
-1. 정의 (기본 의미)
-2. 달성 판정 로직 의사코드
-3. 측정 변수 (게임 런타임 중 추적해야 할 값)
-4. UI 표시 방식
-5. 개발팀 구현 요청 포인트
-6. 엣지 케이스 및 주의 사항
-
-를 한 곳에 정리한다. 개발팀이 **Unity MCP EditMode 독립 어셈블리(`Assets/Sim/BurningTimes.Sim.asmdef`)에서 구현해야 할 조건 판정 코드**의 설계 기반 자료.
-
-### 범위 외 (HOLD 준수)
-- **조건별 구체적 수치 최종 확정 금지** — 수치는 Phase 3 재개 후 시뮬 결과로만 산출
-- **조건 풀 12개 추가·삭제 금지** — PD님 3차 승인으로 확정된 풀 유지
-- **스테이지별 슬롯 배치 확정 금지** — 맵 패턴 사전분석 v1 §3-3 검증틀을 실제로 적용하는 것은 Phase 3 재개 후
-- **카드 수치 조정 제안 금지** — 이슈 1·3 재논의 영역
-
-### P18 준수 (설계 문서 필수 포함 사항)
-| 항목 | 본 문서 위치 |
-|------|------------|
-| 결정의 배경 | §1 (Prove-2-of-3 체계 도입 배경) |
-| 선택된 방향과 대안 | §2 (조건 풀 12개 선정 경위) |
-| 구현 가이드라인 | §3~§5 (조건별 명세) |
-| 검증 방법 | §6 (조건 판정 검증 체크리스트) |
-| 변경 이력 | §8 |
-
----
-
-## 1. Prove-2-of-3 체계 개요 (결정 배경)
-
-### 1-1. 체계 구조
-
-수상한 잡화점 스테이지의 3성(★★★) 클리어는 **Prove-2-of-3** 체계로 판정:
-
-| 별 | 충족 조건 |
-|----|----------|
-| ★1 | 스테이지 클리어 (기본) |
-| ★2 | 스테이지 클리어 + **슬롯2 조건 1개** 달성 |
-| ★3 | 스테이지 클리어 + **슬롯2·슬롯3 조건 2개** 동시 달성 |
-
-- **스테이지별 슬롯2·슬롯3은 사전 지정** (고정). 런타임 랜덤 없음
-- 슬롯 지정은 스테이지 특성(노드 수·몬스터 배치 패턴·등장 몬스터 수)과 연동
-- PD님 2차 승인 (2026-04-14)으로 대방향 확정
-
-### 1-2. 조건 설계 원칙 (PD님 3차 승인 기준)
-
-1. **유저가 확실히 컨트롤할 수 있는 조건**: 누적형·운 의존·빌드 의존 조건 부적합
-2. **재도전 유도 방향성**: "무난하게 모든 조건을 완성"이 아니라 "특정 조건을 만족하기 위해 여러 번 재도전"을 유발하도록 다소 난해한 수준
-3. **완화 방향 금지**: 조건 수치는 "완화"가 아닌 "재도전 유도" 방향 튜닝
-4. **P17 배타 배치 규칙 준수**: 동시 배치 금지 조합 7종 회피
-
-### 1-3. 조건 분류
-
-Phase 2 §5 용어 기준:
-- **C 계열** (Clear 조건): 스테이지 진행 과정 전체 관점 6종 — C1·C2·C3·C6·C9·C12
-- **N 계열** (Node 조건 또는 Numeric 조건): 서브맵 단위 또는 특정 행동 기반 6종 — N1·N2·N3·N4·N5·N6
-- **합계**: 12종 (C10 "성장의 증거" 보류, N7 "방어 성공" 실측 완료 — PCDefence_Mul=0.3·쿨다운 없음·지속형·Melee/Range 공통·Mob 방어 부재, 조건 풀 추가 여부 Phase 3 재개 시 PD님 결정 / N8 "저 HP 완주" 변형 채택)
-
----
-
-## 2. 조건 풀 12개 요약 테이블
-
-| ID | 명칭 | 계열 | 수치 방식 | 유저 컨트롤 난이도 | 재도전 유도 강도 |
-|----|------|------|---------|-----------------|---------------|
-| C1 | 신속 | 시간 | 스테이지 총 소요 시간 ≤ 임계값 | 중 | 중 |
-| C2 | 완벽 클리어 | HP | 스테이지 종료 시 PC HP = MaxHP | 중 | 고 |
-| C3 | 고 HP 완주 | HP | 스테이지 종료 시 PC HP ≥ MaxHP × 70% | 저 | 저~중 |
-| C6 | 포션 절제 | 카운트 | 스테이지 내 포션 사용 횟수 ≤ 임계값 | 저 | 중 |
-| C9 | 보스 집중 | 카운트 | 보스 대상 유효 공격 ≥ 임계값 | 중 | 중 |
-| C12 | 회피 주도 | 카운트 | 회피 발생 횟수 ≥ **서브맵수 × 3 이상** (유지 이상) | 고 | 고 |
-| N1 | 빗맞힘 절제 | 카운트 | 빗맞힘 횟수 ≤ 임계값 | 중 | 중 |
-| N2 | 피격 제한 | 카운트 | 피격 횟수 ≤ **서브맵수 × 1 이하** | 고 | 고 |
-| N3 | 치명타 처치 | 카운트 | 치명타로 몬스터 처치 ≥ 임계값 | 중~고 | 고 |
-| N4 | 쉴드 보존 | 비율 | 스테이지 종료 시 Shield ≥ **MaxShield × 30% 이상** | 중 | 중 |
-| N5 | 후열 선공 | 순서 | 서브맵마다 최초 공격 대상이 후열 | 저~중 | 중 |
-| N6 | 전열 선공 | 순서 | 서브맵마다 최초 공격 대상이 전열 | 저~중 | 중 |
-
-> **주의**: 임계값 "이상/이하"의 구체적 숫자는 **본 문서에서 확정하지 않는다** (HOLD 범위). Unity MCP 시뮬로 재도전 유도 강도와 밸런스를 검증한 후 Phase 3 재개 시점에 PD님 승인으로 확정.
-
----
-
-## 3. C 계열 조건 상세 명세 (6종)
-
-### 3-1. C1 — 신속 (스테이지 총 소요 시간)
-
-#### 정의
-스테이지 시작부터 최종 보스 처치(또는 스테이지 종료)까지의 **총 경과 시간이 임계값 이하**.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnStageStart:
-    stageTimer.start()
-
-OnStageClear:
-    totalTime = stageTimer.elapsed()
-    if totalTime <= C1_threshold_of_stage(stageID):
-        condition_C1_satisfied = true
-    else:
-        condition_C1_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 | 리셋 시점 |
-|-------|------|------|---------|
-| `stageTimer_elapsedSec` | float | 스테이지 시작부터 누적 시간(초) | 스테이지 시작 시 0으로 |
-
-#### UI 표시
-- **스테이지 진입 시**: 상단 또는 슬롯 표시 영역에 "목표: XX초 이내 클리어" (임계값 명시)
-- **플레이 중**: HUD에 경과 타이머 실시간 표시 (기존 시스템 활용 여지 확인 필요)
-- **스테이지 종료 시**: 결과창에 실제 소요 시간 vs 임계값 병기 + ✓/✗ 표시
-
-#### 개발팀 구현 요청 포인트
-1. 스테이지 경과 시간이 이미 측정되고 있는지 확인 (`StageManager` 또는 유사 클래스)
-2. 포즈·메뉴 오픈 시간 제외 여부 결정 필요 — **기획팀장 초안**: 실제 전투 시간만 카운트, UI 포즈 중 시간 제외
-3. 임계값은 **스테이지별 고정 테이블**로 관리 (예: `StageClearCondition.json` 또는 기존 테이블 확장)
-
-#### 엣지 케이스
-- **사망 후 재시작**: 재시작 시 타이머 0 리셋 (같은 스테이지 내 이어하기 없음 가정)
-- **일시정지**: 포즈 시간 제외 여부는 구현 방식에 따름
-- **매우 짧은 스테이지 (Stage 1~2)**: 임계값이 너무 타이트하면 첫 플레이에서는 거의 불가능 — 재도전 유도 목적에는 적합하나 Stage 1·2의 입문 부담 고려 필요
-
-#### P17 배타 조합
-- **(입문 1~6) C1 ∧ C3 동시 배치 금지** — 입문 구간 이중 부담
-- 중반·후반은 허용
-
----
-
-### 3-2. C2 — 완벽 클리어 (HP = MaxHP)
-
-#### 정의
-스테이지 **종료 시점에 PC의 HP가 MaxHP와 같음** (피격 후 회복도 인정).
-
-#### 달성 판정 로직 (의사코드)
-```
-OnStageClear:
-    if pc.currentHP == pc.maxHP:
-        condition_C2_satisfied = true
-    else:
-        condition_C2_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 | 리셋 시점 |
-|-------|------|------|---------|
-| `pc.currentHP` | int/float | PC 현재 HP | 실시간 갱신 |
-| `pc.maxHP` | int/float | PC 최대 HP (성장·카드 효과 반영) | 성장·버프 적용 시 갱신 |
-
-#### UI 표시
-- **스테이지 진입 시**: "HP Full 유지 필요" 뱃지
-- **플레이 중**: HP 바가 100% 미만으로 떨어지면 해당 조건 위반 예고 상태 (아이콘 흐려짐 등)
-- **스테이지 종료 시**: 결과창 ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. `pc.maxHP`가 카드·각성·장비 효과로 실시간 변하는 경우의 처리 필요
-2. 스테이지 종료 시점 정의 명확화: 최종 보스 처치 직후 프레임 vs 결과창 오픈 시점
-3. **중요**: 피격 후 회복하여 HP=MaxHP 도달해도 인정 (PD님 해석 확인 필요 시 문의)
-
-#### 엣지 케이스
-- **MaxHP 증가 효과 (G3 "MaxHP 2배" 등) 중 HP도 2배로 회복되는가?** — 개발팀 코드 확인 필요
-- **종료 시점 판정 프레임**: 결과창 오픈 시점 HP 기준으로 통일 권장
-
-#### P17 배타 조합
-- **C2 ∧ N2 동시 배치 금지** — 피격 최소화 축 이중 부담
-
----
-
-### 3-3. C3 — 고 HP 완주 (HP ≥ MaxHP × 70%)
-
-#### 정의
-스테이지 **종료 시점에 PC의 HP가 MaxHP의 70% 이상**.
-
-> ※ 임계값 "70%"는 Phase 2 §5 원안 기반 초안. Phase 3 재개 후 시뮬 결과로 재튜닝 가능.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnStageClear:
-    hpRatio = pc.currentHP / pc.maxHP
-    if hpRatio >= C3_threshold:  // 초안 0.7
-        condition_C3_satisfied = true
-    else:
-        condition_C3_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `pc.currentHP / pc.maxHP` | float | HP 비율 (0.0~1.0) |
-
-#### UI 표시
-- **스테이지 진입 시**: "HP 70% 이상 유지" 뱃지
-- **플레이 중**: HP 바에 "70% 마커" 표시
-- **스테이지 종료 시**: 결과창에 최종 HP 비율 + ✓/✗
-
-#### 개발팀 구현 요청 포인트
-- C2와 동일 구조. 임계값만 다름
-- **임계값 상수화** 필수 (스테이지별 개별 튜닝 가능성 대비)
-
-#### 엣지 케이스
-- C2 충족 시 C3도 자동 충족 (HP=MaxHP는 ≥70% 만족). **논리상 문제 없음**, 같은 슬롯에 중복 배치만 피하면 됨
-
-#### P17 배타 조합
-- **(입문 1~6) C1 ∧ C3 동시 배치 금지**
-
----
-
-### 3-4. C6 — 포션 절제 (포션 사용 ≤ N)
-
-#### 정의
-스테이지 내 **포션(회복 아이템) 사용 횟수가 임계값 이하**. "미사용"은 N=0 케이스.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnPotionUsed(potionType):
-    potionUseCount += 1
-
-OnStageClear:
-    if potionUseCount <= C6_threshold:
-        condition_C6_satisfied = true
-    else:
-        condition_C6_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 | 리셋 시점 |
-|-------|------|------|---------|
-| `potionUseCount` | int | 스테이지 내 포션 사용 누적 | 스테이지 시작 시 0 |
-
-#### UI 표시
-- **스테이지 진입 시**: "포션 사용 N회 이하" 뱃지
-- **플레이 중**: 포션 슬롯 UI에 남은 허용 횟수 표시
-- **스테이지 종료 시**: 실제 사용 vs 임계값 + ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. "포션"의 정의 명확화: HP 포션·MP 포션·기타 소모품 중 어느 것을 카운트할지
-2. **기획팀장 초안**: HP 회복계 물약만 카운트 (메테오·전체 기절 같은 전투용 물약은 별도 조건으로 다룰지 추후 논의)
-3. 패시브로 발동되는 회복 효과는 카운트 제외
-
-#### 엣지 케이스
-- **물약 빌드와의 충돌**: 물약 사용 시 추가 효과가 있는 카드(메테오·7.5초 무적·전체 기절)를 플레이하면 C6 달성 불가 → P17-2 배타 "C6 ∧ 물약 사용 유도 조건"으로 방지
-- **회복 빌드와의 충돌**: 힐 카드 패시브 회복은 포션 사용이 아니므로 영향 없음
-
-#### P17 배타 조합
-- **C6 ∧ 물약 사용 유도 조건 동시 배치 금지**
-- **C6 ∧ N4(쉴드 하한) 동시 배치 금지** — 회복 빌드 외 빌드 배제
-
----
-
-### 3-5. C9 — 보스 집중 (보스 대상 유효 공격 ≥ N)
-
-#### 정의
-스테이지 내 **보스 몬스터를 대상으로 한 유효 공격 횟수가 임계값 이상**. "처치 우선순위를 보스에 둔 플레이"를 유도.
-
-> ※ "유효 공격"의 정의·임계값은 Phase 3 재개 후 시뮬로 확정. 본 문서는 판정 틀만 제시.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnAttackLanded(attacker, target, damage):
-    if attacker == pc and target.type == MonsterType.Boss and damage > 0:
-        bossHitCount += 1
-
-OnStageClear:
-    if bossHitCount >= C9_threshold_of_stage(stageID):
-        condition_C9_satisfied = true
-    else:
-        condition_C9_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `bossHitCount` | int | 스테이지 내 보스 피격(플레이어→보스) 누적 |
-
-#### UI 표시
-- **스테이지 진입 시**: "보스에 N회 이상 공격" 뱃지
-- **플레이 중**: 카운터 표시 (권장)
-- **스테이지 종료 시**: 실제 vs 임계값 + ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. **"유효 공격" 정의**:
-   - **기획팀장 초안**: 데미지 > 0인 공격만 카운트 (빗맞힘·회피된 공격 제외)
-   - 무적·반사 상태 몬스터 대상 공격의 카운트 여부 결정 필요
-2. **Shield 흡수된 공격**: HP에 들어간 데미지가 0이라도 Shield에 데미지가 들어갔다면 카운트해야 함 (개발팀 판단 필요)
-3. **DOT (도트 데미지) 처리**: 독·화상·처형 같은 지속 데미지 틱을 카운트할지 여부
-
-#### 엣지 케이스
-- **보스가 여러 체인 경우 (Stage 20 등 3체)**: 각 보스별 카운트를 합산
-- **보스 미등장 서브맵 + 보스 등장 서브맵 혼재**: 전체 스테이지 합산이므로 문제 없음. 단, 보스 미등장 서브맵 비율이 너무 높으면 임계값 달성 불가
-- **단독 보스 스테이지 (Stage 7·10·13)**: P17-5로 C9 배치 금지
-
-#### P17 배타 조합
-- **C9 ∧ 단독 보스·보스 미등장 스테이지 동시 배치 금지**
-- 맵 패턴 재검증 필요 (맵패턴_사전분석_v1 §1·§2 참조)
-
-#### 연동 작업
-- 보스 혼용 등장 패턴 설계 (맵패턴_사전분석_v1 §2) 완료 후 임계값 재튜닝
-
----
-
-### 3-6. C12 — 회피 주도 (회피 횟수 ≥ 서브맵수 × 3 이상)
-
-#### 정의
-스테이지 내 **PC의 회피 발생 횟수가 (해당 스테이지 서브맵 수 × 3) 이상**. PD님 지침 "유지 이상"으로 재도전 유도 강도 고수위.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnAttackMissed(attacker, target):
-    if target == pc and miss_reason == "Avoid":
-        avoidCount += 1
-
-OnStageClear:
-    requiredAvoid = submap_count_of_stage(stageID) * 3
-    if avoidCount >= requiredAvoid:
-        condition_C12_satisfied = true
-    else:
-        condition_C12_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `avoidCount` | int | 스테이지 내 회피 발생 누적 |
-| `submap_count_of_stage(stageID)` | int | 해당 스테이지 서브맵 총 수 (고정 데이터) |
-
-#### UI 표시
-- **스테이지 진입 시**: "회피 X회 이상" (X = 서브맵수 × 3) 뱃지
-- **플레이 중**: 카운터 표시 권장
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. **"회피"의 정의**: `Avoid_M` / `Avoid_R` 스탯에 의한 미스만 포함. 빗맞힘(`Miss`)과 구분 필요
-2. 몬스터 공격에 대한 PC 회피만 카운트. PC 공격이 몬스터에게 회피된 것은 N1(빗맞힘 절제)의 "빗맞힘"에 해당 (별도 조건)
-3. 서브맵 수는 스테이지별 고정 데이터 (`CreateMapConfig.json` 또는 유사)에서 조회
-
-#### 엣지 케이스
-- **서브맵 수 이상 스테이지 (Stage 7=4, 13=4, 16=3 등)**: 임계값이 낮아져 달성이 쉬워질 수 있음 — PD님 지침 "유지 이상"에 따라 스테이지별 추가 상향 검토 여지
-- **회피율 극대화 빌드**: 회피 빌드와 시너지가 극도로 강함. P17에 "회피 빌드 유도 조건"과의 배타 조합이 필요한지는 추후 판단 (현재 미등재)
-
-#### P17 배타 조합
-- **현재 P17 7종 배타 조합에 C12는 포함되지 않음**
-- 단, N1(빗맞힘 절제)과 구조 유사점 있음. 동시 배치 시 혼동 가능성 UI 점검 필요
-
----
-
-## 4. N 계열 조건 상세 명세 (6종)
-
-### 4-1. N1 — 빗맞힘 절제 (빗맞힘 ≤ N)
-
-#### 정의
-스테이지 내 **PC의 공격 빗맞힘(`Miss`) 횟수가 임계값 이하**. "정확도 플레이"를 유도.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnAttackMissed(attacker, target):
-    if attacker == pc and miss_reason == "Miss":  // Hit 판정 실패
-        missCount += 1
-
-OnStageClear:
-    if missCount <= N1_threshold:
-        condition_N1_satisfied = true
-    else:
-        condition_N1_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `missCount` | int | 스테이지 내 PC 공격이 빗맞은 횟수 |
-
-#### UI 표시
-- **스테이지 진입 시**: "빗맞힘 N회 이하" 뱃지
-- **플레이 중**: 카운터 (권장, 선택적)
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. `Miss` 스탯 vs `Avoid` 스탯을 **명확히 구분**해 판정 (공격자 Hit 실패 = Miss, 수비자 회피 성공 = Avoid)
-2. 몬스터의 회피 성공(Avoid_M/R) 때문에 PC 공격이 빗나간 경우 — 이것은 "Miss"가 아니라 "Avoided"로 구분해야 함. **구분 불가능한 경우는 C9·C12와 상호 모순 발생 가능성** → 개발팀 점검 필요
-
-#### 엣지 케이스
-- **빗맞힘이 극히 드문 빌드 (높은 명중률 빌드)**: N1 달성이 거의 자동 → 임계값을 낮춰 난이도 확보 필요
-- **C12와의 구분 UI**: "회피"와 "빗맞힘" 용어 혼동을 방지하는 UI 문구 필요
-
-#### P17 배타 조합
-- 현재 없음
-
----
-
-### 4-2. N2 — 피격 제한 (피격 ≤ 서브맵수 × 1 이하)
-
-#### 정의
-스테이지 내 **PC가 피격받은 횟수가 (서브맵수 × 1) 이하**. Shield·HP에 데미지가 들어간 모든 피격 카운트.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnDamageReceived(target, damage):
-    if target == pc and damage > 0:
-        hitCount += 1
-
-OnStageClear:
-    maxHits = submap_count_of_stage(stageID) * 1
-    if hitCount <= maxHits:
-        condition_N2_satisfied = true
-    else:
-        condition_N2_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `hitCount` | int | 스테이지 내 PC 피격 누적 |
-
-#### UI 표시
-- **스테이지 진입 시**: "피격 X회 이하" (X = 서브맵수 × 1) 뱃지
-- **플레이 중**: 카운터 표시 필수 — 피격 1회마다 긴장감 고조
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. **"피격"의 정의**:
-   - **기획팀장 초안**: Shield 흡수 피격 + HP 데미지 피격 모두 카운트 (의도된 방어가 있었든 없었든 "맞았다"는 사실만)
-   - Avoid된 공격은 카운트 제외
-   - 반사·무적으로 무효화된 공격: **카운트 제외** (피해 발생 없음)
-2. DOT는 데미지 틱마다 카운트하지 않고 "최초 부착 시 1회"만 카운트 (초안). 대안: 틱마다 카운트. 개발팀과 협의 필요
-
-#### 엣지 케이스
-- **서브맵 수 이상 스테이지**: C12와 동일. 임계값 재튜닝 여지
-- **최종 보스 단 1체 스테이지**: 피격이 집중되므로 N2 달성 난이도 급증
-
-#### P17 배타 조합
-- **C2 ∧ N2 동시 배치 금지**
-
----
-
-### 4-3. N3 — 치명타 처치 (치명타로 처치 ≥ N)
-
-#### 정의
-스테이지 내 **치명타 공격으로 몬스터를 처치한 횟수가 임계값 이상**. 치명타 빌드와 시너지.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnMonsterKilled(killer, target, killBlow):
-    if killer == pc and killBlow.isCritical == true:
-        critKillCount += 1
-
-OnStageClear:
-    if critKillCount >= N3_threshold:
-        condition_N3_satisfied = true
-    else:
-        condition_N3_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `critKillCount` | int | 치명타로 처치한 몬스터 수 |
-
-#### UI 표시
-- **스테이지 진입 시**: "치명타 처치 N회 이상" 뱃지
-- **플레이 중**: 카운터 + 치명타 발생 시 시각·음향 강화 (기존 크리 연출 활용)
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. "처치 타격" 판정: 몬스터 HP를 0으로 만든 **최종 타격이 치명타였는지** 확인. 중간 치명타는 카운트 안 됨
-2. DOT로 처치 시: 최종 틱이 치명타 판정을 가지는 경우 처리 방법 결정
-3. 처형·관통 같은 특수 스킬의 치명타 판정 여부 확인
-
-#### 엣지 케이스
-- **치명타율이 매우 낮은 빌드 (치명타 빌드 아닌 경우)**: 임계값 달성이 거의 불가능 → 입문 구간 배치 부적합
-- **P17-6 "(입문 1~6) N3 단독 배치 금지"** — 치명타 빌드 미형성 구간이라 달성 곤란
-
-#### P17 배타 조합
-- **(입문 1~6) N3 단독 배치 금지**
-
----
-
-### 4-4. N4 — 쉴드 보존 (Shield ≥ MaxShield × 30%)
-
-#### 정의
-스테이지 **종료 시점에 PC의 Shield가 MaxShield의 30% 이상**. "쉴드 관리 플레이"를 유도.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnStageClear:
-    shieldRatio = pc.currentShield / pc.maxShield
-    if shieldRatio >= N4_threshold:  // 초안 0.3
-        condition_N4_satisfied = true
-    else:
-        condition_N4_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `pc.currentShield / pc.maxShield` | float | Shield 비율 |
-
-#### UI 표시
-- **스테이지 진입 시**: "Shield 30% 이상 유지" 뱃지
-- **플레이 중**: Shield 바에 30% 마커
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. **Shield 시스템 구조 확인**: 재생 Shield / 1회성 Shield / 성소 Shield의 구분과 `pc.currentShield` / `pc.maxShield` 계산 방식
-2. **MaxShield가 동적인가**: 카드·장비·각성으로 MaxShield가 변하는지 확인
-3. **Shield 보유 불가능 빌드**: PC나 빌드에 따라 MaxShield=0인 경우 본 조건 배치 금지 (단독 스테이지 특성 필요)
-
-#### 엣지 케이스
-- **MaxShield = 0**: 판정 시 0으로 나누기 방지. 해당 상황은 N4 배치가 부적절한 스테이지
-- **Shield 회복 카드 있는 경우**: Shield 회복계 카드가 자연 배치되면 N4 달성 쉬워짐
-
-#### P17 배타 조합
-- **C6 ∧ N4 동시 배치 금지** — 회복 빌드 외 배제
-
----
-
-### 4-5. N5 — 후열 선공 (서브맵마다 최초 공격 대상이 후열)
-
-#### 정의
-**각 서브맵마다 PC가 처음 가하는 공격의 대상이 '후열 몬스터'**. 스테이지 내 모든 서브맵에서 성공해야 충족.
-
-#### 달성 판정 로직 (의사코드)
-```
-OnSubmapStart(submapID):
-    firstAttack_submapID = submapID
-    firstAttack_registered = false
-
-OnAttackLanded(attacker, target, damage):
-    if attacker == pc and damage > 0 and firstAttack_registered == false:
-        if target.position == Position.Rear:
-            firstAttack_N5_success[submapID] = true
-        else:
-            firstAttack_N5_success[submapID] = false
-        firstAttack_registered = true
-
-OnStageClear:
-    if all firstAttack_N5_success[submap] == true for all submaps:
-        condition_N5_satisfied = true
-    else:
-        condition_N5_satisfied = false
-```
-
-#### 측정 변수
-| 변수명 | 타입 | 설명 |
-|-------|------|------|
-| `firstAttack_N5_success[submapID]` | bool | 서브맵별 성공 여부 |
-| `firstAttack_registered` | bool | 서브맵 내 최초 공격 확정 여부 |
-
-#### UI 표시
-- **스테이지 진입 시**: "모든 서브맵에서 후열부터 공격" 뱃지
-- **서브맵 시작 시**: "후열 선공" 힌트 표시
-- **최초 공격 후**: 성공/실패 즉시 피드백 아이콘
-- **스테이지 종료 시**: ✓/✗
-
-#### 개발팀 구현 요청 포인트
-1. **몬스터의 전열/후열 판정**: `MonsterPatternList.json` / `ApprearMonsterPattern.json`의 배치 정보 또는 런타임 위치로 판정
-2. **서브맵에 후열 몬스터가 없는 경우**: N5 달성 불가 → 해당 스테이지·서브맵에 N5 배치 금지
-3. **"공격"의 정의**: 자동 공격만 카운트? 스킬 공격도 포함? — 기획팀장 초안: **모든 데미지 발생 공격**
-
-#### 엣지 케이스
-- **후열 몬스터 미등장 서브맵**: 해당 서브맵 때문에 스테이지 전체 실패 → 배치 전 서브맵별 몬스터 구성 점검 필수
-- **정합성 검증**: 기획팀 CLAUDE.md "등장 패턴과 3성 조건의 정합성" 항목과 직결. 맵 패턴 확정 후 N5 배치 가능 스테이지 재식별 필요
-
-#### P17 배타 조합
-- **N5 ∧ N6 동시 배치 금지** — 타겟팅 자유도 박탈·논리 모순
-
----
-
-### 4-6. N6 — 전열 선공 (서브맵마다 최초 공격 대상이 전열)
-
-#### 정의
-**각 서브맵마다 PC가 처음 가하는 공격의 대상이 '전열 몬스터'**. N5의 거울상.
-
-#### 달성 판정 로직 (의사코드)
-```
-(N5의 후열 → 전열 치환. 나머지 동일)
-if target.position == Position.Front:
-    firstAttack_N6_success[submapID] = true
-```
-
-#### 측정 변수
-N5와 동일 구조 (변수명만 N6).
-
-#### UI 표시
-- N5와 동일 구조 (문구만 "전열 선공")
-
-#### 개발팀 구현 요청 포인트
-- N5와 동일. 단 **전열 몬스터 부재 서브맵 없음**이 일반적이나 확인 필요 (보스 전용 서브맵 등 예외)
-
-#### 엣지 케이스
-- 후열만 등장하는 서브맵이 있다면 N6 배치 불가 — 흔치 않으나 확인 필요
-
-#### P17 배타 조합
-- **N5 ∧ N6 동시 배치 금지**
-
----
-
-## 5. 공통 설계 원칙·횡단 이슈
-
-### 5-1. 임계값 관리 원칙
-
-1. **조건별 임계값은 스테이지 단위로 테이블화**: `StageStarCondition.json` (가칭) 또는 기존 스테이지 테이블 확장
-2. **기본값 + 스테이지별 오버라이드 체계**: 전역 기본값을 두고 특정 스테이지만 덮어쓰기 가능
-3. **임계값 튜닝은 Unity MCP 시뮬 실측 결과 기반** (Phase 3 재개 후)
-
-### 5-2. 달성 판정의 공통 요구사항
-
-- 모든 조건 판정은 **스테이지 종료 시점에 최종 결정**
-- 중간 실패 확정 조건(C2·C3·N4 등 HP/Shield 기준)도 **UI는 실시간 경고**, 최종 판정은 종료 시점
-- **중간 포기 (방 나가기·재시작) 시**: 해당 런의 조건 기록 모두 폐기
-
-### 5-3. 측정 변수의 저장 구조
-
-재개 시점에 개발팀이 구현해야 할 **런타임 상태 컨테이너**:
-
-```csharp
-class StageConditionTracker {
-    // 시간
-    float stageTimer_elapsedSec;
-    // HP / Shield
-    // (실시간 pc 객체 참조로 충분)
-    // 카운터
-    int potionUseCount;
-    int bossHitCount;
-    int avoidCount;
-    int missCount;
-    int hitCount;
-    int critKillCount;
-    // 서브맵 단위 bool
-    Dict<submapID, bool> firstAttack_N5_success;
-    Dict<submapID, bool> firstAttack_N6_success;
-    bool firstAttack_registered_current;
-    // ... 등
-}
-```
-
-### 5-4. Unity MCP 시뮬 실측 검증 시 확인 항목
-
-개발팀의 Unity MCP EditMode 시뮬 환경(`Assets/Sim/`) 구축 이후, 각 조건에 대해:
-1. 동일 입력으로 Unity MCP 시뮬과 Unity 실 빌드의 조건 판정 결과가 일치하는가
-2. 측정 변수의 스테이지 종료 시점 값이 일치하는가
-3. 엣지 케이스 (Shield 흡수, DOT, 동시 처치 등)에서 판정 기준이 일치하는가
-
----
-
-## 6. 조건 판정 검증 체크리스트 (Phase 3 재개 시 활용)
-
-### 6-1. 조건별 단위 테스트 매트릭스
-
-| 조건 | 테스트 1 (명확 통과) | 테스트 2 (명확 실패) | 테스트 3 (경계값) | 테스트 4 (엣지) |
-|-----|------------------|------------------|----------------|----------------|
-| C1 | 임계값 - 1초 완주 | 임계값 + 1초 완주 | 임계값 정확히 | 포즈 시간 제외 검증 |
-| C2 | HP=MaxHP | HP=MaxHP-1 | HP=MaxHP(회복 후) | MaxHP 동적 변화 중 |
-| C3 | HP=MaxHP×1.0 | HP=MaxHP×0.69 | HP=MaxHP×0.70 | MaxHP 동적 변화 |
-| C6 | 포션 0 사용 | 포션 임계값+1 | 임계값 정확히 | 비 HP 포션 구분 |
-| C9 | 임계값+1 공격 | 임계값-1 | 정확히 | Shield 흡수 공격 |
-| C12 | 서브맵수×3+1 | 서브맵수×3-1 | 정확히 | Avoid와 Miss 구분 |
-| N1 | 0 빗맞힘 | 임계값+1 | 정확히 | 몬스터 Avoid 제외 |
-| N2 | 서브맵수-1 피격 | 서브맵수+1 | 정확히 | 반사 무효화 피격 |
-| N3 | N+1 치명타 처치 | N-1 | 정확히 | DOT 처치 |
-| N4 | 30%+1 Shield | 30%-1 | 정확히 | MaxShield=0 가드 |
-| N5 | 모든 서브맵 후열 선공 | 1개 서브맵 실패 | - | 후열 부재 서브맵 |
-| N6 | 모든 서브맵 전열 선공 | 1개 서브맵 실패 | - | 전열 부재 서브맵 |
-
-### 6-2. 통합 검증
-
-- **21개 스테이지 × 슬롯2·슬롯3 가상 배치**로 조건 판정이 오류 없이 작동하는지 전수 실측
-- **맵 패턴 사전분석 v1 §3-3 체크리스트**를 이 단계에서 실제 적용 (현재는 틀만 준비됨)
-
----
-
-## 7. 개발팀 요청서 초안 (구조만)
-
-> ※ 정식 요청서는 `공유/기획팀→개발팀/` 폴더에 날짜·REQ번호 부여하여 생성. 본 문서는 **내용 초안**만 제공.
-
-### 요청 개요
-- **제목**: 수상한 잡화점 ★ 조건 12개 판정 로직 구현 요청
-- **배경**: Phase 2 §5 PD님 3차 승인으로 조건 풀 12개 확정. Unity MCP EditMode 독립 어셈블리(`Assets/Sim/BurningTimes.Sim.asmdef`) 기반 구현
-- **선행 조건**: 본 설계 문서(`3성조건_12개_상세명세_v1.md`) 개발팀 리뷰 완료
-
-### 요청 내용 (요약)
-1. §3·§4의 조건별 판정 로직을 C# 런타임에 구현
-2. §5-3의 `StageConditionTracker`(또는 상응 구조) 설계
-3. Unity MCP 시뮬 어셈블리와 실 빌드 간 공통 코드 경로 확보 (동일 판정기 사용)
-4. §6-1의 단위 테스트 매트릭스를 자동 테스트로 구축
-5. **임계값은 테이블 구동** — 코드 내 하드코딩 금지 (스테이지별 튜닝 가능성 대비)
-
-### 우려 사항·문의
-- §3·§4 각 조건의 "엣지 케이스"에 대한 개발팀 판단 필요
-- **N7 방어 성공 조건**이 추후 13번째 조건으로 추가될 가능성 — `StageConditionTracker`를 확장 가능한 구조로 설계 권장
-
----
-
-## 8. 변경 이력 (P18 요구 사항)
-
-| 일자 | 변경 | 근거 |
-|------|------|------|
-| 2026-04-14 | 초안 작성 (v1) | PD님 재량 위임 지시 (Phase 3 HOLD 중 가능 작업) + Phase 2 §5 PD님 3차 승인 조건 풀 12개 |
-
-**향후 예정 변경**:
-- Phase 3 재개 후 시뮬 기반 임계값 확정 → v2
-- N7 방어 성공 조건 추가 결정 시 → §4에 추가 + v2
-- 개발팀 리뷰 피드백 수령 후 반영 → v1.1 or v2
-
----
-
-## 9. HOLD 준수 확인
-
-### 본 문서가 Phase 3 HOLD 영역을 침범하지 않음
-
-| 체크 항목 | 상태 |
-|---------|------|
-| 성장 요소(각성·진화·장비·인장) 기여도 측정 | **미수행** ✓ |
-| 시뮬레이션 실행 | **미수행** ✓ |
-| 카드 수치 조정 제안 | **미수행** ✓ |
-| 조건별 구체적 임계값 수치 확정 | **미수행** (초안 값은 Phase 2 §5 원안 인용에 한정) ✓ |
-| 데이터 테이블 변경 | **미수행** ✓ |
-| 스테이지별 슬롯 배치 확정 | **미수행** ✓ |
-
-### 본 문서가 수행한 것
-- 기존 PD님 3차 승인 **조건 풀 12개의 설계 명문화** (P18 의무 이행)
-- 조건별 판정 로직 **의사코드 수준**의 구현 요구 정의
-- 개발팀과의 **협업 문서 초안** (Phase 3 재개 시 즉시 활용)
-
----
-
-## 10. 참조 문서
-
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 (조건 풀 12개 PD님 3차 승인)
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` §1·§2 (C9·N5·N6 배치 제약)
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` §2-5 (조건 판정 재검증 항목 22~25)
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` §4 (N7 보류·N8 변형 채택)
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` P17 (배타 배치 규칙 7종) + P18 (설계 문서화 의무)
-- `공유/조직공지/` Phase 3 HOLD 공지 (HOLD 범위 준수)
-- 방향 전환 이력: [방향전환 히스토리 아카이브 §3성조건 12개](../../../공유/조직공지/방향전환_히스토리_아카이브.md#m2-3star-condition)
-
----
-
-*작성 완료: 2026-04-14*
-*상태: P18 설계 문서화 의무 이행용 초안 / Phase 3 재개 후 임계값 확정 및 v2 전환 예정*
diff --git a/프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md b/프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
deleted file mode 100644
index 5743632..0000000
--- a/프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
+++ /dev/null
@@ -1,153 +0,0 @@
-# Phase 0~1: 앵커 포인트 기본 전투 프레임 시뮬레이션 v1
-
-> 분석일: 2026-04-13
-> 앵커 조건: Stage1 / PC6001 / 성장0 / 장비0 / 인장0 / 카드0
-
----
-
-## 1. 앵커 PC 스탯 (PC6001 기본값)
-
-| 스탯 | 값 | 비고 |
-|---|---|---|
-| 최소 공격력 | **1** | |
-| 최대 공격력 | **4** | 평균 2.5 |
-| 공격 쿨타임 | **2.4초** | |
-| 치명타 확률 | **2.6%** | 거의 무의미 |
-| 치명타 피해량 | **150%** | |
-| HP | **58** | |
-| 보호막 | **6** | 유효 HP = 64 |
-| 회피(근접) | **5** | |
-| 회피(원거리) | **5** | |
-| 공격 타입 | **Melee** | 근접 |
-
-**PC 기본 DPS** = avg_ATK / cooltime = 2.5 / 2.4 ≈ **1.04 DPS**
-(치명타 보정: ×1.013 → **1.05 DPS** — 2.6%에서는 무시해도 될 수준)
-
----
-
-## 2. Stage1 등장 몬스터 스탯
-
-### 일반 몬스터 (9종)
-
-| ID | 타입 | HP | 보호막 | 유효HP | ATK(Min~Max) | 쿨타임 | DPS | EXP |
-|---|---|---|---|---|---|---|---|---|
-| 11001 | 근접 | 6 | 0 | 6 | 1~2 | 1.6s | 0.94 | 2 |
-| 11002 | 근접 | 6 | 0 | 6 | 1~3 | 1.9s | 1.05 | 2 |
-| 11003 | 근접 | 8 | 0 | 8 | 2~4 | 1.5s | 2.00 | 2 |
-| 11007 | **원거리** | 5 | 0 | 5 | 2~4 | 2.7s | 1.11 | 2 |
-| 14001 | 근접 | 6 | 0 | 6 | 2~3 | 2.0s | 1.25 | 2 |
-| 14002 | 근접 | 6 | 0 | 6 | 2~3 | 1.9s | 1.32 | 2 |
-| 14003 | **원거리** | 8 | 0 | 8 | 3~5 | 2.1s | 1.90 | 2 |
-| 14013 | 근접 | 6 | 0 | 6 | 2~3 | 2.1s | 1.19 | 2 |
-| 14014 | 근접 | 11 | 0 | 11 | 2~7 | 2.2s | 2.05 | 4 |
-
-**일반 몬스터 평균**: HP 6.9, DPS 1.31, EXP 2.2
-
-### 보스 (2종)
-
-| ID | 타입 | HP | 보호막 | 유효HP | ATK | 쿨타임 | DPS | EXP |
-|---|---|---|---|---|---|---|---|---|
-| 10001 | 보스(원거리) | 20 | 15 | **35** | 4~6 | 2.3s | 2.17 | 17 |
-| 10002 | 보스(근접) | 33 | 23 | **56** | 6~8 | 1.9s | 3.68 | 20 |
-
----
-
-## 3. 기본 전투 시뮬레이션 (카드 0장)
-
-### 시나리오: PC vs 일반 몬스터 1마리
-| 지표 | 값 |
-|---|---|
-| PC → 몬스터 TTK | 6 / 1.05 ≈ **5.7초** |
-| 몬스터 → PC DPS | ~1.3 |
-| PC 잔여 HP (전투 후) | 64 - (1.3 × 5.7) ≈ **56.6** (-7.4) |
-
-→ 1마리당 HP 약 12% 소모. **안정적**.
-
-### 시나리오: PC vs 일반 몬스터 4마리 (전열2 + 후열2 가정)
-| 단계 | 상황 | 시간 | PC HP |
-|---|---|---|---|
-| 시작 | 4마리 동시 공격 (합산 DPS ≈ 4.9) | 0s | 64 |
-| 전열 1마리 처치 | 6HP / 1.05 DPS = 5.7s | 5.7s | 64 - 28 = **36** |
-| 전열 2마리 처치 | +5.7s | 11.4s | 36 - 19 = **17** |
-| 후열 1마리 처치 | +4.8s (5HP) | 16.2s | 17 - 12 = **5** |
-| 후열 2마리 처치 | +4.8s | 21.0s | 5 - 12 = **-7** ❌ |
-
-⚠️ **카드 0장, 터치 방어 미사용 시: 4마리 노드에서 사망 위험**
-
-### 터치 방어 사용 시 (피해 50% 감소)
-| 단계 | 시간 | PC HP |
-|---|---|---|
-| 전열 2마리 처치 | 11.4s | 64 - 28 = **36** |
-| 후열 2마리 처치 | 21.0s | 36 - 18 = **18** |
-
-→ **터치 방어 100% 활용 시 생존 가능** (HP 18 잔여)
-
-### 시나리오: PC vs 보스 10001 (원거리, 유효HP 35)
-| 지표 | 값 |
-|---|---|
-| TTK | 35 / 1.05 = **33.3초** |
-| 보스 DPS → PC | 2.17 (터치 방어 시 1.09) |
-| PC 잔여 HP | 64 - (1.09 × 33.3) = **27.7** |
-
-→ 터치 방어 활용 시 생존 가능하지만 여유 없음.
-
-### 시나리오: PC vs 보스 10002 (근접, 유효HP 56)
-| 지표 | 값 |
-|---|---|
-| TTK | 56 / 1.05 = **53.3초** |
-| 보스 DPS → PC | 3.68 (터치 방어 시 1.84) |
-| PC 잔여 HP | 64 - (1.84 × 53.3) = **-34** ❌ |
-
-⚠️ **보스 10002는 카드 0장으로 절대 클리어 불가**. 의도된 설계라면 OK (Stage1_4 보스이므로 몇 레벨업 후 도전하는 구조).
-
----
-
-## 4. 레벨업·카드 획득 페이스 추정
-
-### Stage1 일반 노드 경험치 수급
-- 일반 몬스터 평균 EXP: 2.2
-- 4마리 노드 1개 ≈ EXP 8.8
-- Lv1→2 필요: 3 EXP → **첫 노드 도중 레벨업** (카드 1장 선택)
-- Lv2→3 필요: 7 EXP → **노드 1~2개 사이 레벨업**
-- Lv3→4 필요: 14 EXP → **노드 2개 정도**
-
-### Stage1 전체 카드 획득 추정
-- Stage1은 4개 서브맵 (Stage1_1 ~ Stage1_4)
-- 각 맵에 노드 10~20개 (CreateMapConfig 설정)
-- 1개 서브맵 기준 전투 노드 약 8~15개 (랜덤 패턴에 따라 변동)
-- 1개 서브맵에서 획득 가능 EXP ≈ 70~130
-- BattleLevelUp 기준 Lv1→Lv10 필요 EXP = 423
-
-→ **Stage1 서브맵 1개에서 약 Lv 7~9 도달** → **카드 6~8장 획득**
-→ Stage1 전체(4개 서브맵)를 다 돌면 레벨 상한(20) 도달 가능
-
----
-
-## 5. 팀장 판단 — Phase 0~1 진단 결과
-
-### ✅ 양호한 점
-1. **일반 몬스터 1마리 TTK(5.7초)**: 빠르고 경쾌함. 목표에 부합.
-2. **레벨업 페이스**: 첫 노드에서 바로 레벨업 → **카드 선택 경험이 빠르게 시작됨**. Balatro류 게임에 적합.
-3. **보스 차별화**: 일반 몬스터 대비 보스의 유효 HP가 5~9배 → 보스전의 긴장감이 자연스럽게 발생.
-
-### ⚠️ 확인 필요한 점
-1. **4마리 노드 생존성**: 카드 0장에서 4마리 노드는 터치 방어 없이 사망. 이게 "터치 방어를 자연스럽게 배우게 하는" 설계 의도라면 OK. 아니라면 초반 몬스터 DPS or 수 조정 필요.
-2. **보스 10002(근접, 유효HP 56)**: 카드 0장 + 터치 방어로도 사망. Stage1_4 보스이므로 그 전 노드에서 카드 5~6장은 획득한 상태일 텐데, **카드 5~6장(G1)이 충분한 전투력 보충을 주는지** Phase 2에서 검증 필요.
-3. **노드당 몬스터 수**: `MonsterPatternList`의 실제 배치(전열/후열/대기열 비율)를 아직 상세 분석하지 않았음. 이 분석이 TTK 시뮬레이션의 정확도를 크게 좌우함.
-
-### 🔜 Phase 2에서 할 일
-1. G1 카드 5장 보유 상태에서 동일 시뮬레이션 반복 → "카드의 체감"을 수치로 확인
-2. `MonsterPatternList` 상세 분석 → 실제 노드당 전열/후열/대기열 배치
-3. 터치 방어 시스템의 정확한 작동 방식 확인 (사용자에게 질문 or 코드 분석)
-
----
-
-## 6. 사용자에게 확인 요청
-
-**Q-P1.** 카드 0장 상태에서 4마리 노드가 "터치 방어 없이는 위험"한 현재 상태는 의도된 건가요?
-(= 터치 방어를 초반에 자연스럽게 가르치기 위한 설계?)
-
-**Q-P2.** 터치 방어의 정확한 메커닉을 알려주시면 시뮬레이션 정확도가 올라갑니다:
-- 터치 1회 = 다음 공격 1회 피해 50% 감소인가요?
-- 터치 유지 중 계속 50% 감소인가요?
-- 쿨다운이 있나요?
diff --git a/프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md b/프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md
deleted file mode 100644
index 1317f4a..0000000
--- a/프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md
+++ /dev/null
@@ -1,248 +0,0 @@
-# Phase 2: 카드 임팩트 측정 v1
-
-> 분석일: 2026-04-13
-> 앵커 기준: Stage1 / PC6001 / 성장0 / 장비0 / 인장0
-> 데이터: CardList.json (311장, G1~G5)
-
----
-
-## 1. 핵심 발견 요약
-
-### 결론부터
-1. **G1 카드 5장(=Lv5)에서 TTK 45% 감소** -- 목표 범위(30~50%) 적중. 카드 체감 충분.
-2. **G1~G2가 "양적 파워"**, G3~G5는 "질적 변환" -- 등급 간 파워 구조가 이중적임.
-3. **빌드 형성 난이도가 양극화됨** -- 힐/쉴드/처치연쇄는 EASY, 치명타/물약은 MEDIUM~HARD.
-4. **치명타 빌드의 G1 시그널 부족 (G1:4장)** -- 의도된 설계이나 "빌드 발견"의 재미가 초반에 없음.
-
----
-
-## 2. 등급별 카드 1장 전투 기여도
-
-앵커: PC DPS=1.05, EHP=64, TTK=5.7초 (vs 일반 몬스터 HP 6.9)
-
-| 등급 | 카드수 | 평균 DPS 기여 | DPS 증가율 | 평균 EHP 기여 | EHP 증가율 |
-|------|--------|-------------|----------|-------------|----------|
-| **G1** | 112장 | +0.23 | +22% | +1.6 | +2.5% |
-| **G2** | 73장 | +0.26 | +25% | +1.1 | +1.7% |
-| **G3** | 51장 | +0.10 | +9% | +1.0 | +1.6% |
-| **G4** | 43장 | +0.13 | +13% | +1.1 | +1.7% |
-| **G5** | 32장 | +0.09 | +9% | +1.2 | +1.8% |
-
-### G3~G5가 수치상 낮은 이유 (이것이 문제가 아닌 이유)
-
-G3~G5 카드의 s_Value1/2가 대부분 0. **효과가 수치가 아니라 메커닉 전환**이기 때문.
-
-| 등급 | 파워 구조 | 대표 효과 |
-|------|----------|----------|
-| **G1~G2** | 양적 증가 (Incremental) | ATK+2, HP 회복 5, 쉴드+3, 데미지+10% |
-| **G3** | 과도기 (Transitional) | 공속+25%, 근접회피+15%, MaxHP 2배, 크리데미지 x2.5 |
-| **G4** | 질적 도약 (Transformational) | 크리확률+15%, 보호막 시 데미지 50% 감소, 처치시 최종데미지+50% |
-| **G5** | 게임 전환 (Game-Changing) | 사망 시 부활(40%), 7.5초 무적, 전체 기절 8.5초, 모든 데미지 반사 |
-
-**결론**: G1~G2는 "양이 쌓여서 강해지는" 카드, G3~G5는 "한 장이 게임을 바꾸는" 카드. 이 이중 구조는 Balatro류 설계에 적합함.
-
----
-
-## 3. 카드 누적 임팩트 (TTK 변화)
-
-### G1 카드만으로 성장 시
-
-| 보유 카드 수 | 총 DPS | TTK | TTK 감소율 | 총 EHP | EHP 증가율 | 비고 |
-|------------|-------|------|----------|--------|----------|------|
-| 0장 (앵커) | 1.05 | 5.7s | 기준 | 64 | 기준 | 카드 없음 |
-| **1장** | 1.28 | 5.4s | -6% | 65.6 | +3% | 첫 레벨업 |
-| **3장** | 1.74 | 4.0s | **-31%** | 68.8 | +8% | |
-| **5장** | 2.21 | 3.1s | **-45%** | 72.0 | +13% | **목표 범위 적중** |
-| **10장** | 3.36 | 2.1s | -64% | 80.0 | +25% | |
-| **19장 (풀)** | 5.44 | 1.3s | -78% | 94.4 | +48% | 풀빌드 |
-
-**판정**: G1 카드 5장에서 TTK 45% 감소 -- 밸런싱전략_v1의 목표(30~50%)에 정확히 부합.
-
-### 실전 드래프트 (1런 19장, 등급 혼합)
-
-| 등급 | 기대 장수 | DPS 기여 합 | EHP 기여 합 |
-|------|---------|-----------|-----------|
-| G1 (66.2%) | 12.6장 | +2.91 | +20.2 |
-| G2 (19.9%) | 3.8장 | +1.00 | +4.2 |
-| G3 (9.9%) | 1.9장 | +0.19 | +2.0 |
-| G4 (3.3%) | 0.6장 | +0.08 | +0.6 |
-| G5 (0.66%) | 0.1장 | +0.01 | +0.1 |
-| **합계** | **19장** | **+4.19** | **+27.1** |
-
-- **최종 DPS**: 1.05 + 4.19 = **5.24** (기본 대비 **+399%**)
-- **최종 EHP**: 64 + 27.1 = **91.1** (기본 대비 **+42%**)
-- **최종 TTK**: 5.7s -> **1.3s** (감소 **77%**)
-
-**판정**: 풀빌드 시 DPS가 5배로 증가. 밸런싱전략의 기여도 목표(카드 풀빌드 +80~120%)보다 **훨씬 높음(+399%)**. 단, 이 수치는 "순수 DPS 기여만" 계산한 것으로, G3~G5의 질적 효과(기절, 반사, 부활 등)는 미포함.
-
----
-
-## 4. 빌드별 드래프트 기대값과 형성 난이도
-
-### 1런 19회 선택에서 각 빌드 카드가 뽑힐 기대 장수
-
-| 순위 | 빌드 | 카드 풀 | 1런 기대 선택수 | 난이도 |
-|------|------|--------|--------------|--------|
-| 1 | **힐/회복** | 56장 | **4.09장** | EASY |
-| 2 | **보호막/생존** | 50장 | **3.26장** | EASY |
-| 3 | **처치 연쇄** | 56장 | **3.15장** | EASY |
-| 4 | **회피** | 44장 | **3.02장** | EASY |
-| 5 | 원거리 | 36장 | 1.95장 | MEDIUM |
-| 6 | 신성 폭격 | 22장 | 1.71장 | MEDIUM |
-| 7 | **치명타** | 35장 | **1.14장** | MEDIUM |
-| 8 | 첫타 버스트 | 17장 | 1.14장 | MEDIUM |
-| 9 | **물약** | 25장 | **1.11장** | MEDIUM |
-| 10 | 번개 | 16장 | 1.10장 | MEDIUM |
-
-### 핵심 빌드별 G4+G5 핵심 카드 등장 확률
-
-| 빌드 | G4+G5 카드 수 | 1런 기대값 | 10런에 1장 이상 | 비고 |
-|------|-------------|----------|-------------|------|
-| **치명타** | **19장** | **0.192장** | ~85% | G4+G5 최다. 터지면 가장 강력 |
-| 처치 연쇄 | 15장 | 0.165장 | ~81% | |
-| 보호막 | 11장 | 0.118장 | ~70% | |
-| 힐 | 9장 | 0.110장 | ~67% | |
-| 원거리 | 7장 | 0.081장 | ~56% | |
-| 물약 | 10장 | 0.071장 | ~51% | G5에 7장 집중 |
-| 회피 | 7장 | 0.059장 | ~45% | |
-| 번개 | 4장 | 0.037장 | ~31% | |
-| 첫타 | 3장 | 0.033장 | ~28% | |
-| 신성 | 2장 | 0.019장 | ~17% | G1~G2 위주, G4+G5 거의 없음 |
-
----
-
-## 5. 밸런싱 이슈 및 조정 제안
-
-### 이슈 1: 카드 DPS 기여도가 목표 대비 과도 (HIGH)
-
-| 항목 | 목표 (밸런싱전략_v1) | 실측 | 판정 |
-|------|-------------------|------|------|
-| G1 풀빌드(19장) DPS 기여 | +80~120% | **+399%** | **초과** |
-| G1 풀빌드(19장) EHP 기여 | +80~120% | +48% | 적정 |
-
-**근거**: DPS 기여가 목표의 3~4배. 이대로면 스테이지 후반에서도 카드만으로 압도할 가능성이 있고, "아웃게임 스펙업이 필요한 구간"이 너무 늦게 옴.
-
-**단, 주의**: 이 수치는 "모든 카드가 DPS에 기여한다"는 가정 하의 이론치. 실전에서는:
-- 힐/쉴드 카드를 뽑으면 DPS 기여 없음
-- 드래프트에서 DPS와 EHP를 선택해야 하는 트레이드오프 존재
-- 따라서 실전 DPS 증가율은 이론치의 50~70% 수준(+200~280%)으로 예상
-
-**제안 보류**: 실전 빌드 분포 데이터 없이 수치 조정하면 위험. **Phase 3에서 성장 요소 통합 후 재검토**.
-
-### 이슈 2: 치명타 빌드의 이중 구조 (MEDIUM)
-
-| 빌드 | G1 카드 | 1런 G1 기대 | G4+G5 카드 | 1런 G4+G5 기대 |
-|------|---------|-----------|-----------|-------------|
-| 치명타 | **4장** (G1 풀의 3.6%) | **0.68장** | **19장** | 0.19장 |
-| 힐 | 27장 (24.1%) | 4.58장 | 9장 | 0.11장 |
-| 보호막 | 20장 (17.9%) | 3.39장 | 11장 | 0.12장 |
-
-**문제**: 치명타 빌드는 G4+G5에 핵심 카드가 19장이나 있지만, G1에 4장뿐이라 **초반에 빌드를 시작할 시그널이 거의 없음**. "이 런은 치명타 빌드로 가야겠다"는 판단을 내리기 어려움.
-
-**밸런싱 규칙 확인**: "G4~G5 편중 빌드는 의도된 극레어 빌드" (feedback_card_balance_rules.md). 따라서 이것은 문제가 아닌 **의도된 설계**.
-
-**제안**: 조정 불필요. 다만, **치명타 빌드는 "계획적 덱빌딩"이 아니라 "G4가 나와서 방향이 전환되는" 럭 기반 빌드**라는 점을 확인. 이것은 Balatro류 설계와 정합.
-
-### 이슈 3: 신성 빌드의 확장성 부족 (LOW)
-
-| 지표 | 신성 빌드 | 처치 연쇄 |
-|------|----------|----------|
-| 총 카드 | 22장 | 56장 |
-| G1 기대 | 1.87장 | 2.72장 |
-| G4+G5 핵심 | **2장** | 15장 |
-| 1런 G4+G5 | **0.019장** | 0.165장 |
-
-**문제**: 신성 빌드는 G1~G2에서 시작하기 쉽지만(MEDIUM), **G4+G5 확장 카드가 2장뿐**이라 빌드가 "터지는" 순간이 거의 없음. Balatro류 "폭발의 쾌감"을 주기 어려운 빌드.
-
-**제안**:
-| 항목 | 현재값 | 제안값 | 근거 |
-|------|--------|--------|------|
-| 신성 빌드 G4 카드 | 1장 | 3~4장 | G4에서 빌드 완성 시그널 제공 |
-| 신성 빌드 G5 카드 | 1장 | 1~2장 | 극레어 "폭발" 카드 1장 추가 |
-
-단, **카드 효과 종류 추가는 금지**(밸런싱 규칙). 기존 카드의 수치 조정으로 대응하거나, 신규 카드 추가 시 사용자 승인 필요.
-
-**PD님 판단 (2026-04-14)**: **모든 카드 검증이 끝난 후** 확률 조정·수치 조정 등을 포함해 재논의. 현시점 조치 보류, Phase 3 및 후속 검증 완료 후 재논의 대상으로 이관.
-
-**PD님 추가 확정 (2026-04-14)**: **이슈 1(카드 DPS 과도) ↔ 이슈 3(신성 G4/G5 확장성)은 동일 카드 수치 축**에 영향. 분리 처리 시 상호 악화 리스크로 **동시 논의 방식 사전 확정**. 재논의 시점 기획팀장이 통합 안건으로 제시할 것.
-
-**선행 조건 의존 체계 (2026-04-14 PD님 확정, 2026-04-18 최신화)**:
-```
-1. Unity MCP EditMode 시뮬 환경 구축 (개발팀, #28·#37 완료)
-   └→ 2. Phase 3 재개 (기획팀, Unity MCP 실측 기반 → Phase3_v2 재작성)
-        └→ 3. 이슈 1·3 동시 재논의 (기획팀, Phase 3 결과 반영)
-             └→ 4. 최종 수치 조정 및 Phase 3 v2 확정
-```
-"모든 카드 검증 완료" = 위 1~4 전체 완료 시점을 의미
-
-**영향도**:
-- 무과금: 신성 빌드가 더 자주 완성됨 → 긍정적 (접근성 높은 빌드이므로)
-- 소과금: 동일
-- 고과금: 미미 (고과금은 치명타/물약 등 레어 빌드를 노림)
-
-### 이슈 4: 물약 빌드와 ★2 조건 충돌 (MEDIUM)
-
-카드시너지축분석_v1에서 발견된 이슈 재확인:
-- ★2 조건: "물약 미사용"
-- 물약 빌드: 물약 사용 시 추가 효과 (7.5초 무적, 전체 기절, 메테오 등)
-
-**이것이 의도된 트레이드오프인지 확인 필요**. 의도라면 물약 빌드는 "★1은 쉽게 클리어하지만 ★2를 포기하는" 선택지가 됨.
-
-**PD님 판단 (2026-04-14)**: **의도된 설계 아님**. 기존 옵션(B 완화) 대신, **스테이지 3성 클리어 조건이 너무 단순한 점을 개선**하는 방향으로 접근. 시스템 기획 + 컨텐츠 기획 + 기획팀장이 상의하여 **3성 클리어 조건의 다양화 방안**을 검토·제안하기로 함.
-
-**PD님 승인 (2026-04-14, 2차)**:
-1. **대방향 채택**: Prove-2-of-3 체계(★1 클리어 / ★2 1조건 / ★3 2조건) 전면 개편 — A안 확정
-2. **슬롯 2 매칭 방식**: **고정(사전 지정)**. 단, 스테이지별 특성을 고려해 적절히 배치. 향후 스테이지 작업 시 노드 수·몬스터 배치 패턴·등장 몬스터 수 등을 조건과 연동하여 설계
-3. **C10(성장의 증거)**: 보류. 게임 복잡성 증가 우려로 추후 확장 항목으로 이관
-4. **타 빌드 전수 점검**: A안 확정 — 물약 외 다른 빌드도 ★ 조건과 구조적 충돌이 있는지 **모든 빌드 대상 전수 점검 실시**
-5. **조건 선정 원칙**: **유저가 확실히 컨트롤할 수 있는 조건**으로 구성. 누적형·운 의존·빌드 의존 조건은 부적합. C1~C10은 원칙 재검토 후 재제안 필요
-
-**MVP/일정/공수 관련**: 코어 룰 C9(AI 에이전트 조직 원칙) 신설로, 이 프로젝트에서는 MVP 범위·일정 지연·공수는 기본 고려 대상 아님.
-
-**PD님 판단 (2026-04-14, 3차 — 14조건 검증 후)**:
-
-### 최종 조건 풀 12개 확정 (+ N7 보류)
-- **채택 12개**: C1 신속 / C2 완벽 클리어(HP=Max) / C3 고 HP 완주 / C6 포션 절제 / C9 보스 집중 / C12 회피 주도 / N1 빗맞힘 절제 / N2 피격 제한 / N3 치명타 처치 / N4 쉴드 보존 / N5 후열 선공 / N6 전열 선공
-- **N7 방어 성공**: **실측 완료 (2026-04-17 #37 Q-P2 정밀 2차)** — PCDefence_Mul=0.3 (30% 감소), 쿨다운 없음, 지속형 상태 효과(터치 Down↔Up), 방어 중 공격 불가, Melee/Range 공통 적용, Mob 방어 메커닉 부재. 조건 풀 13번째 추가 여부는 Phase 3 재개 시 PD님 결정
-- **N8 저 HP 완주**: 변형 채택 — **"HP ≤ 30%"보다 난해한 수준**으로 설계 (재도전 유도 목적)
-
-### 전체 난이도 방향성 (PD님 지침)
-> "이 작업의 목적은 무난하게 모든 조건을 완성하는 게 아니라, **특정 조건을 만족하기 위해 여러 번 재도전을 유도**하기 위한 측면이다. 따라서 조건이 다소 난해할 수 있도록 설계되어야 한다."
-
-- C12 회피 주도: 원안(서브맵수 × 3) **유지 이상**
-- N8 저 HP 완주: HP ≤ 30%보다 더 타이트한 수치로 조정 검토 (예: HP ≤ 20%)
-- 전체 조건의 수치는 "완화" 방향이 아닌 "재도전 유도" 방향으로 튜닝
-
-### C9 배치 가이드 (확장)
-- 단독 보스 스테이지(2·7·10·13 등) 배치 금지
-- **보스가 등장하지 않는 서브맵 패턴**도 고려 대상 — 스테이지의 등장 패턴을 확인하고 배치 결정
-- **맵 패턴 작업 시 논의 필요**: 보스 몬스터가 단독으로만 등장하지 않고 일반 몬스터와 혼용되어 등장하도록 패턴 설계 — 맵 패턴 작업 착수 시점에 이 필요성을 먼저 환기할 것
-
-### 배타 배치 규칙 (P17 후보)
-구체적 내용 확정 후 PD님 재승인 예정
-
----
-
-## 6. Phase 3으로의 연결
-
-Phase 2에서 확인된 핵심 수치:
-
-| 지표 | 값 | Phase 3 활용 |
-|------|-----|------------|
-| G1 카드 1장 DPS 기여 | +0.23 (+22%) | 각성/장비 1단계의 기여도와 비교 기준 |
-| G1 5장 TTK 감소율 | -45% | 스테이지 난이도 설계 시 "Lv5 PC" 기준점 |
-| 풀빌드 DPS 증가율 | +399% (이론) / +200~280% (실전 추정) | 카드 기여도 > 장비+각성 순서 검증 |
-| 풀빌드 EHP 증가율 | +42% | 카드만으로 부족 → 장비/각성으로 보완 필요 확인 |
-
-다음 단계(Phase 3): **성장 요소별 기여도 설정** -- 각성/진화/장비/인장 각각의 기여도를 카드 기여도와 비교하여, "카드 > 장비 > 각성 > 인장" 순서가 유지되는지 검증.
-
----
-
-## 7. 참조 문서
-
-- `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` — 스테이지 구조·난이도 설계 기반
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` — 빌드 축 10개·이슈 1·3·4 원 입력
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` — 조건 풀 12개 상세 명세
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` — C9 배치 가이드·P17 배타 조합
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` C9·P17 — AI 조직 원칙·배타 배치 규칙
-- 방향 전환 이력: [방향전환 히스토리 아카이브 §Phase2 카드임팩트](../../../공유/조직공지/방향전환_히스토리_아카이브.md#m2-phase2-card-impact)
diff --git a/프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md b/프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
deleted file mode 100644
index a1f5508..0000000
--- a/프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
+++ /dev/null
@@ -1,344 +0,0 @@
-# 수상한 잡화점 — Phase 3 재개 준비 체크리스트 v1
-
-> 작성일: 2026-04-14 / 최신화: 2026-04-18
-> 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
-> 목적: Phase 3 HOLD 해제 시점에 **즉시 집행 가능한 작업 순서·담당자·검증 절차**를 사전 구체화
-> HOLD 준수: 본 문서는 **실행 절차·담당자·산출물 스키마만** 정의. 실제 Phase 3 작업(성장 요소 기여도 측정·시뮬 실행·수치 조정 제안)은 일절 수행하지 않음
-
----
-
-## 0. 본 문서의 목적·범위
-
-### 목적
-Phase 3 HOLD 해제 시 기획팀이 **30분 내 착수**할 수 있도록:
-1. 재개 트리거 체크리스트
-2. Day 1~N 작업 순서 로드맵
-3. 각 작업의 담당 에이전트·산출물·검증 방법
-4. 기존 3개 사전 산출물(`맵패턴_사전분석_v1` / `일관성점검_v1` / `재논의대기_사전자료모음_v1`)과의 연동 지점
-
-을 한 곳에 정리한다.
-
-### 범위 외 (HOLD 준수)
-- 실제 Phase 3 작업 수행 (성장 요소별 기여도 측정 등)
-- Unity MCP 시뮬 실행 및 결과 분석
-- 수치 조정안 작성
-
----
-
-## 1. Phase 3 재개 트리거 체크리스트
-
-### 1-1. 필수 선행 조건 4종 (HOLD 해제 요건)
-
-`공유/조직공지/` HOLD 공지 §재개 조건 기반:
-
-| # | 조건 | 확인 담당 | 확인 방법 |
-|---|------|---------|---------|
-| 1 | Unity MCP EditMode 독립 어셈블리(`Assets/Sim/BurningTimes.Sim.asmdef`) 시뮬 환경 구축 완료 | 개발팀장 → 총괄PM | `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` + `Assets/Sim/` 실존 |
-| 2 | Unity MCP EditMode 실측 검증 완료 (결정론·리플레이 보장) | 개발팀장 + 기획팀장 | 실측 검증 리포트 (`공유/소통/개발팀→기획팀/`) |
-| 3 | 기획팀용 Unity MCP 시뮬 실행 가이드 확보 | 개발팀 | `공유/소통/개발팀→기획팀/` 폴더 내 가이드 문서 |
-| 4 | PD님 재개 지시 (직접) | 총괄PM 전달 | PD님 세션 기록 |
-
-### 1-2. 재개 즉시 수행 3단계 체크
-
-재개 지시를 받은 시점에 기획팀장이 즉시 수행:
-
-```
-[Phase 3 재개 즉시 체크 3단계]
-□ 1단계: 공유/조직공지/ 의 🛑·⚠️·🚨 파일 전수 재스캔
-         현재 Phase 3 HOLD 공지 파일 상태 확인 (삭제 or "재개됨" 표기)
-□ 2단계: CLAUDE.md "🔔 최근 규칙 변경" 섹션 재읽기 (Read 캐시 의존 금지)
-□ 3단계: .claude/skills/BurningTimes-코어룰/SKILL.md 최신 조항 확인
-```
-
-### 1-3. 재개 선행 의존성 체계 (PD님 확정)
-
-```
-1. Unity MCP EditMode 시뮬 환경 구축 (개발팀, #28·#37 완료)
-   └→ 2. Phase 3 재개 (기획팀, Unity MCP 실측 검증 기반 재계산 → Phase3_성장요소기여도_v2.md 작성)
-        └→ 3. 이슈 1·3 동시 재논의 (기획팀, Phase 3 결과 반영)
-             └→ 4. 최종 수치 조정 및 Phase 3 v2 확정
-```
-"모든 카드 검증 완료" = 위 1~4 전체 완료 시점을 의미 (`재논의대기_사전자료모음_v1.md` §1-3 인용)
-
----
-
-## 2. Day 1~N 재개 작업 로드맵
-
-### Day 1: 재개 준비 및 교차 검증 리뷰 (예상 1일)
-
-| 순번 | 작업 | 담당 | 산출물 | 검증 방법 |
-|-----|------|------|-------|---------|
-| 1-1 | §1-1·§1-2 체크리스트 전수 수행 | 기획팀장 | 체크 완료 보고 | 총괄PM 확인 |
-| 1-2 | 개발팀 Unity MCP 실측 검증 리포트 정독 | 기획팀장 + 밸런스기획자 | 검증 요약 메모 | — |
-| 1-3 | Unity MCP 시뮬 실행 가이드 정독 및 간이 실행 테스트 | 밸런스기획자 | 시뮬 실행 가능 확인 | 1회 앵커 시뮬 실행 결과가 Unity 실 빌드와 일치하는지 대조 |
-| 1-4 | 기존 3개 사전 산출물 재독 및 연동 항목 최종 점검 | 기획팀장 | 연동 지점 표(§3 참조) | — |
-
-### Day 2~3: Phase 0~2 결과 재검증 (28개 재검증 항목 중 1~6번 우선)
-
-`밸런싱문서_일관성점검_v1.md §2-1` 재검증 항목 6건:
-
-| 순번 | 작업 | 담당 | 산출물 |
-|-----|------|------|-------|
-| 2-1 | #1 PC 6001 DPS 1.05 Unity MCP 실측으로 대조 | 밸런스기획자 | 재검증 로그 |
-| 2-2 | #2 Stage 1 일반 몬스터 TTK 5.7s 재측정 | 밸런스기획자 | 재검증 로그 |
-| 2-3 | #3 G1 카드 1장 평균 기여도 +22% DPS 재측정 | 밸런스기획자 | 재검증 로그 |
-| 2-4 | #4 G1 5장 TTK -45% 재검증 | 밸런스기획자 | 재검증 로그 |
-| 2-5 | #5 G1 풀빌드 +399% DPS 실전치 재측정 | 밸런스기획자 | 재검증 로그 |
-| 2-6 | #6 풀빌드 EHP +42% 재측정 | 밸런스기획자 | 재검증 로그 |
-
-**결과물**: `재검증보고_Phase0_1_2_v1.md` (6건 통합 리포트)
-
-### Day 4~7: Phase 3 본작업 (성장 요소별 기여도 측정)
-
-`밸런싱문서_일관성점검_v1.md §2-4` 재검증 항목 16~21:
-
-| 순번 | 작업 | 담당 | 산출물 |
-|-----|------|------|-------|
-| 4-1 | #16 각성 만렙 기여도 측정 (목표 +40~60%) | 밸런스기획자 + 시스템기획자 | 시뮬 로그 |
-| 4-2 | #17 진화 6★ 기여도 측정 (목표 +30~50%) | 동일 | 시뮬 로그 |
-| 4-3 | #18 장비 일반 셋 기여도 측정 (목표 +20~40%) | 동일 | 시뮬 로그 |
-| 4-4 | #19 장비 세트 완성 기여도 측정 (목표 +60~80%) | 동일 | 시뮬 로그 |
-| 4-5 | #20 인장 5★ 기여도 측정 (목표 +15~30%) | 동일 | 시뮬 로그 |
-| 4-6 | #21 성장 요소 기여 순서 원칙 검증 (카드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장) | 기획팀장 | 순위 검증 |
-
-**결과물**: **`Phase3_성장요소기여도_v2.md`** (신규 작성 — v1은 부재)
-
-### Day 8~10: 이슈 1·3 동시 재논의 (PD님 확정 통합 안건)
-
-| 순번 | 작업 | 담당 |
-|-----|------|------|
-| 8-1 | 이슈 1 (카드 DPS 과도) 실측 재확인 — 실전 +200~280% 수치 검증 | 밸런스기획자 |
-| 8-2 | 이슈 3 (신성 G4/G5 확장성) 실측 재확인 | 밸런스기획자 |
-| 8-3 | 이슈 1·3 통합 조정안 초안 작성 — 전체 DPS 목표치 재설정 + 빌드별 강약 재분배 | 기획팀장 + 시스템기획자 |
-| 8-4 | PD님 판단 요청 및 재논의 | 총괄PM → PD님 |
-
-**결과물**: `이슈1_3_통합재논의_v1.md` (기획팀장 + PD님 판단 기반 최종안)
-
-### Day 11~14: 스테이지 난이도 곡선·맵 패턴 재검증 (28개 중 11~15, 22~25)
-
-| 순번 | 작업 | 담당 | 참조 |
-|-----|------|------|-----|
-| 11-1 | #11~#15 스테이지 난이도 곡선 재검증 | 레벨기획자 + 밸런스기획자 | `일관성점검_v1 §2-3` |
-| 11-2 | #22 C9 배치 금지 스테이지 (7·10·13) 타당성 재검증 | 레벨기획자 | `맵패턴_사전분석_v1 §1-2` |
-| 11-3 | #23 C9 적합 스테이지 (§1-4 리스트) 재검증 | 레벨기획자 | `맵패턴_사전분석_v1 §1-4` |
-| 11-4 | #24 보스 혼용 패턴 원칙 4종을 실 패턴 ID로 구체화 | 레벨기획자 | `맵패턴_사전분석_v1 §2-3·§2-4` |
-| 11-5 | #25 42개 슬롯에 P17 체크리스트 전수 적용 | 기획팀장 + 레벨기획자 | `맵패턴_사전분석_v1 §3-3` |
-
-**결과물**: `재검증보고_맵패턴_v1.md` + 42개 슬롯 배치안 초안
-
-### Day 15+: 최종 조정 및 Phase 3 v2 확정
-
-| 순번 | 작업 | 담당 |
-|-----|------|------|
-| 15-1 | #26~#28 밸런싱 목표 수치 재조정 | 기획팀장 |
-| 15-2 | Phase3_성장요소기여도_v2.md 최종본 확정 | 기획팀장 |
-| 15-3 | 밸런싱전략_v1.md §3 Phase 3 목표 표 업데이트 제안 | 기획팀장 |
-| 15-4 | PD님 최종 승인 | 총괄PM → PD님 |
-
----
-
-## 3. 기존 3개 사전 산출물과의 연동 지점
-
-### 3-1. 맵 패턴 사전분석 v1 연동
-
-| 사전분석 §  | 재개 시 연동 작업 | 재개 Day |
-|-----------|---------------|---------|
-| §1-2 C9 배치 금지 스테이지 | Day 11-2: 실측 재검증 | Day 11 |
-| §1-4 C9 적합 스테이지 리스트 | Day 11-3: Unity MCP 시뮬 재검증 | Day 11 |
-| §2-4 스테이지별 혼용 패턴 프레임 | Day 11-4: 실 패턴 ID로 구체화 | Day 11 |
-| §3-3 42개 슬롯 검증 체크리스트 | Day 11-5: 42개 전수 적용 | Day 11 |
-| §4-2 재개 시 즉시 착수 작업 순서 | Day 1~11 전체 | — |
-
-### 3-2. 일관성 점검 v1 연동
-
-| 일관성점검 § | 재개 시 연동 작업 | 재개 Day |
-|----------|---------------|---------|
-| §1-6 G1 풀빌드 목표·실측 괴리 | Day 8-1: 이슈 1 재논의 | Day 8 |
-| §1-9 Phase 3 목표 기여도 (성장 요소) | Day 4~7: 본 작업 | Day 4~7 |
-| §1-10 용어·표기 일관성 (DPS/EHP/TTK 재표기) | Day 15-3: 밸런싱전략 업데이트 | Day 15 |
-| §2-1 Phase 0~2 재검증 6건 | Day 2~3 | Day 2~3 |
-| §2-2 카드 시너지 축 재검증 4건 | Day 4 선행 or 병행 | Day 4 |
-| §2-4 성장 요소 기여도 재검증 6건 | Day 4~7 본 작업 | Day 4~7 |
-| §2-5 맵 패턴 재검증 4건 | Day 11 | Day 11 |
-| §2-6 밸런싱 목표 수치 재조정 3건 | Day 15 | Day 15 |
-
-### 3-3. 재논의 대기 사전 자료 모음 v1 연동
-
-| 재논의대기 § | 재개 시 연동 작업 | 재개 Day |
-|----------|---------------|---------|
-| §1 이슈 1 (카드 DPS 과도) | Day 8-1·8-3 | Day 8 |
-| §2 이슈 3 (신성 G4/G5 확장성) | Day 8-2·8-3 | Day 8 |
-| §3 이슈 1·3 연동 처리 권고 | Day 8-3 통합 조정안 기준 | Day 8 |
-| §4-1 N7 방어 성공 조건 | 개발팀 방어 시스템 분석 완료 시점에 별도 추가 (#37 Q-P2 정밀 2차 실측으로 터치 방어 30%·쿨다운 없음·지속형 확정됨) | 분리 |
-| §4-3 N8 저 HP 완주 수치 변형 | Day 4~7 본 작업 중 포함 | Day 4~7 |
-
-### 3-4. 3성 조건 12개 상세 명세 v1 연동 (본 문서 작성과 동시 신설)
-
-| 명세서 § | 재개 시 연동 작업 | 재개 Day |
-|---------|---------------|---------|
-| §3·§4 조건별 판정 로직 | 개발팀에 구현 요청서 전송 (`공유/소통/기획팀→개발팀/`) | Day 1-4 (재개 직후) |
-| §6-1 단위 테스트 매트릭스 | 개발팀이 Unity MCP EditMode 기반 자동 테스트 구축 | Day 1~5 |
-| §7 개발팀 요청서 초안 | 정식 요청서로 전환 (REQ 템플릿 `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` 활용) | Day 1 |
-
----
-
-## 4. 담당 에이전트 매핑
-
-### 4-1. 실무 에이전트별 주요 책임
-
-| 에이전트 | 재개 작업 중 주요 역할 |
-|---------|---------------------|
-| 기획팀장 | 전체 로드맵 관리, 통합 조정안 작성, PD님 판단 요청 |
-| 시스템기획자 | 성장 요소(각성·진화) 구조 검증, 조건 판정 시스템 |
-| 컨텐츠기획자 | 카드 내용·빌드 시너지 관점 재검증 |
-| 레벨기획자 | 스테이지 난이도·맵 패턴·슬롯 배치 |
-| 시나리오기획자 | (Phase 3 본 작업에서는 비주요 — 독립 작업 가능) |
-| 밸런스기획자 | **주력 담당** — Unity MCP 시뮬 실행, 기여도 측정, 수치 분석 |
-| UX기획자 | 조건 UI 표시 방안 검토 (`3성조건_12개_상세명세_v1.md` §3·§4 참조) |
-
-### 4-2. 외부 협업 지점
-
-| 작업 | 외부 담당 |
-|------|---------|
-| Unity MCP 시뮬 실행 문의·이슈 | 개발팀 클라이언트팀장 |
-| 조건 판정 로직 구현 (`Assets/Sim/`) | 개발팀 클라이언트팀 |
-| 테이블 변경 요청 (PD님 승인 전제) | 개발팀 클라이언트팀 |
-
----
-
-## 5. 재개 산출물 명명 규칙 통일
-
-`밸런싱문서_일관성점검_v1.md §3-3` 규칙 준수:
-
-| 산출물 유형 | 명명 규칙 | 예시 |
-|----------|---------|------|
-| Phase 3 본 작업 | `Phase3_성장요소기여도_v2.md` | v1 부재이므로 v2로 식별 |
-| 재검증 보고서 | `재검증보고_[항목명]_v{버전}.md` | `재검증보고_Phase0_1_2_v1.md` |
-| 통합 조정안 | `이슈{번호}_통합재논의_v{버전}.md` | `이슈1_3_통합재논의_v1.md` |
-| 개발팀 요청서 | `공유/소통/기획팀→개발팀/[YYYY-MM-DD]_REQ{번호}_[제목].md` | — |
-
----
-
-## 6. 리스크 체크리스트
-
-### 6-1. 재개 시점 잠재 리스크
-
-| 리스크 | 완화 방법 |
-|-------|---------|
-| Unity MCP 시뮬 가이드 불완전 → 기획팀이 시뮬 실행 불가 | Day 1-3에서 반드시 앵커 시뮬 실행 확인. 미작동 시 즉시 개발팀으로 에스컬레이션 |
-| Unity MCP 실측 결과가 Unity 실 빌드와 불일치 발견 | Unity 실 빌드 결과를 정(正)으로 하고 MCP 시뮬은 재조정. 불일치 원인 분석 후 `Assets/Sim/` 로직 수정 |
-| 성장 요소 기여도 실측이 목표치(+40~60% 등)와 큰 괴리 | Day 8 이슈 1·3 재논의에서 통합 처리 대상으로 이관 |
-| 42개 슬롯 배치 P17 전수 체크에서 위반 대량 발견 | 슬롯 재배치 제안 작성 후 PD님 승인 요청 |
-| N7 방어 성공 조건 추가 결정 시점과 Phase 3 작업 겹침 | N7은 별도 트랙으로 분리. #37 Q-P2 정밀 2차 실측 결과(30% 감소·지속형·쿨다운 없음) 기반으로 조건 풀 확장 (13번째) |
-
-### 6-2. HOLD 재발 리스크
-
-- Phase 3 재개 후에도 중간에 **새로운 HOLD**가 발령될 가능성 상존
-- **매일 작업 시작 시 C10-1 3단계 체크 재수행**을 로드맵 내 표준 루틴으로 고정
-
-### 6-3. 교훈 기반 리스크
-
-`memory/org/MEMORY.md` 교훈 인덱스 및 조직공지 기반:
-- **Read 캐시 함정**: 작업 초반의 CLAUDE.md Read 결과가 캐시되어 최신 공지를 놓칠 수 있음. Day별 시작 시 재읽기 의무
-- **시뮬 단일축 원칙**: Phase 3 v2는 **Unity MCP EditMode 실측만을 근거**로 산출 (단일축 SOT 준수)
-
----
-
-## 7. Phase 3 재개 시 PD님 보고 템플릿 (샘플)
-
-### 7-1. 착수 보고 (Day 1 종료 시)
-```
-## Phase 3 재개 Day 1 완료 보고
-
-### 선행 확인 3단계 결과
-- 1단계: [결과]
-- 2단계: [결과]
-- 3단계: [결과]
-
-### §1-1 재개 트리거 체크리스트 결과
-- #1 Unity MCP EditMode 시뮬 환경 구축 확인: [OK / 미비]
-- #2 Unity MCP 실측 검증 완료: [OK / 미비]
-- #3 Unity MCP 시뮬 실행 가이드: [OK / 미비]
-- #4 PD님 재개 지시: [OK]
-
-### Day 1 산출물
-- [경로 + 요약]
-
-### Day 2 예정 작업
-- [순번 + 내용]
-
-### 발견 이슈 또는 문의
-- [C3 정직성 기준으로 모든 이슈 명기]
-```
-
-### 7-2. 본 작업 완료 보고 (Day 7 종료 시)
-```
-## Phase 3 본 작업 완료 보고 — 성장 요소별 기여도 실측 완료
-
-### 실측 결과 요약
-- 각성 만렙: +[X]% (목표 +40~60%, [적정/과도/부족])
-- 진화 6★: +[X]%
-- 장비 일반 셋: +[X]%
-- 장비 세트 완성: +[X]%
-- 인장 5★: +[X]%
-- **성장 요소 기여 순서 검증**: [원칙 부합/이탈]
-
-### Phase3_성장요소기여도_v2.md 초안 위치
-- [경로]
-
-### 이슈 1·3 재논의 준비 상태
-- [준비 완료 / 준비 중]
-```
-
----
-
-## 8. 본 문서의 한계 및 유효 기간
-
-### 8-1. 한계
-- 재개 시점의 실제 시뮬 환경·교차 검증 결과에 따라 Day별 작업 내용이 변동 가능
-- 본 로드맵은 "순조로운 진행" 가정. 중대 이슈 발생 시 로드맵 재구성 필요
-- 담당 에이전트 배분은 권장안. 실제 호출·위임은 재개 시점 재량
-
-### 8-2. 유효 기간
-- **Phase 3 HOLD 해제 시까지 유효**
-- 재개 후에도 Day 1~15 진행 중 참조 가능
-- Phase 3 v2 확정 후 본 문서 폐기 (`완료/` 폴더로 이관)
-
-### 8-3. 업데이트 트리거
-- 새로운 HOLD·공지 발령 시
-- 개발팀 Unity MCP 시뮬 환경의 주요 변경 시 (`프로젝트/수상한잡화점/시뮬레이터/01~04` 개정)
-- `맵패턴_사전분석_v1` / `일관성점검_v1` / `재논의대기_사전자료모음_v1` / `3성조건_12개_상세명세_v1` 수정 시
-
----
-
-## 9. HOLD 준수 확인
-
-| 체크 항목 | 상태 |
-|---------|------|
-| 성장 요소(각성·진화·장비·인장) 기여도 측정 | **미수행** ✓ |
-| 시뮬레이션 실행 | **미수행** ✓ |
-| 카드 수치 조정 제안 | **미수행** ✓ |
-| 데이터 테이블 변경 | **미수행** ✓ |
-| 조건 풀 12개 수정·추가·삭제 | **미수행** ✓ |
-| 스테이지별 슬롯 배치 확정 | **미수행** ✓ |
-
-**본 문서가 수행한 것**: 재개 시점 실행 절차의 **구조화·명문화**. 실제 실행은 HOLD 해제 후.
-
----
-
-## 10. 참조 문서
-
-- `공유/조직공지/` Phase 3 HOLD 공지 (재개 조건 SOT)
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md`
-- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md`
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md`
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` (본 착수 작업에서 신규)
-- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` ~ `04_MCP_호출_스니펫_v1.md` (Unity MCP 시뮬 인프라)
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` C10·P17·P18
-- `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md`
-- 방향 전환 이력: [방향전환 히스토리 아카이브 §Phase3 체크리스트](../../../공유/조직공지/방향전환_히스토리_아카이브.md#m1-phase3-checklist)
-
----
-
-*작성 완료: 2026-04-14*
-*상태: Phase 3 재개 전 실행 대기 / 재개 시점부터 Day 1~15+ 로드맵으로 활용*
diff --git a/프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md b/프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md
deleted file mode 100644
index 323ae8d..0000000
--- a/프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md
+++ /dev/null
@@ -1,540 +0,0 @@
----
-type: Phase 종결 + 설계 체계 SOT
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD B안 수용 집행)
-관련PD지시: 기획팀 #3 Phase 3 · PD 2026-04-20 B안 수용 (Phase 3 종결 + Phase 4 노드 구성 분리)
-상태: **확정** (Phase 3 종결 선언) · Phase 4 입력 자원 제공 역할
-선행산출물 (전수 보존 대상 — 누락 0건):
-  - 공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md (Day 2~3 재검증 6건)
-  - 공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md (Day 4~7 #16~#21 Unity MCP UTF 14/14)
-  - 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md (Day 8~10 PD A안 수용 · §3 재조사 불요 수준)
-  - 프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md (Day 11~14 통합 · 42 슬롯 P17 전수)
-  - 프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md (사전 설계 프레임)
-  - 프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md (42 슬롯 후보 조합 풀)
-  - 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md (스테이지 구조 SOT)
-  - 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 PD 3차 승인)
-  - 프로젝트/수상한잡화점/기획/밸런싱전략_v1.md (목표·드래프트 가중치)
-  - 프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md (28개 재검증 항목 추적)
-  - 프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md (카드 분포·이슈 원문)
-  - 프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md (신성 빌드 22장 전수)
-  - 프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md
-  - 프로젝트/수상한잡화점/기획/전체테이블감사_v1.md
-  - 프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md
-  - 프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
----
-
-# Phase 3 종결 — 설계 체계 확립 단계 v1
-
-## §0. 본 문서의 역할
-
-### §0-1. 두 가지 역할
-
-1. **Phase 3 종결 선언 문서** — Phase 3을 "설계 체계 확립" 단계로 재정의하고, Day 1~14 성과 전수를 집약하여 종결한다.
-2. **Phase 4 입력 자원 SOT** — Phase 4(스테이지별 노드 구성)가 활용할 **설계 원칙·판정 도구·실측 데이터**를 네비게이션 가능한 형태로 제공한다.
-
-### §0-2. 본 문서가 하지 않는 것
-
-- **원본 산출물 내용 대체 금지** — Day 2~3, Day 4~7, Day 11~14 산출물은 원본 경로에 그대로 보존. 본 문서는 집약·네비게이션만 수행한다 (C14-5 "본문 최신 + 참조 링크")
-- **스테이지별 실 노드 구성·배치 확정 금지** — Phase 4 본작업 영역 (C36 PM·팀장 재량 상한 준수)
-- **임시 데이터 수치 재확정 금지** — 42 슬롯 현황·TTK 수치 등은 Phase 4 완료 후 재확정 대상으로 이관 (§6 참조)
-
-### §0-3. 누락 방지 원칙 (PD 2026-04-20 지시 "지금까지 진행된 내용은 누락되지 않도록 잘 공유해야 해")
-
-본 문서는 **Day 2~3·Day 4~7·Day 8~10·Day 11~14 모든 산출물을 참조**한다. 누락 0건 확인은 §8 체크리스트로 검증한다.
-
----
-
-## §1. Phase 3 범위 재정의 (2026-04-20 PD B안 수용)
-
-### §1-1. 기존 범위 (구)
-
-Phase 3 = "성장 요소 기여도 측정 + 스테이지 재검증 + 맵 패턴 실 배치 확정 + v2 최종본" (Day 1~15+ 전 과정)
-
-### §1-2. 재정의 범위 (신)
-
-Phase 3 = **"설계 체계 확립 단계"**
-- Day 1~14 범위 = **설계 원칙·판정 도구·실측 데이터 확립**
-- Day 15+ 범위 = **분리** → Phase 4(스테이지별 노드 구성)에서 재개
-
-### §1-3. 재정의 근거
-
-- **현 스테이지 데이터 = 임시** — #57-B 보류 사유와 일치 (2026-04-20 PD 확인). 실 노드 구성은 Phase 4에서 확정할 대상이므로 Phase 3에서 임시 데이터 기반 수치 재확정은 의미 제한적
-- **설계 원칙·판정 도구 = 프로젝트 자산** — Day 11~14 산출물(C9 배치 원칙·P17 전수 체크 방식·AppearGroup 가이드 프레임 등)은 **임시 데이터와 독립적으로 유효**
-- **차기 프로젝트 계승 가능** — 본 단계에서 확립된 판정 체계는 P29 조직 자산 계승·발전 원칙 하에 차기 프로젝트에서 재활용 가능
-
-### §1-4. 산출물 이원화
-
-| 성격 | 산출물 | Phase 4에서의 활용 |
-|------|-------|------------------|
-| 설계 원칙·판정 도구 | 본 문서 §5 (집약) | **직접 활용** (Phase 4 모든 스테이지 적용) |
-| 실측 데이터 | 본 문서 §3·§4 (집약) | **직접 활용** (Phase 4 노드 설계 입력) |
-| 임시 데이터 수치 | 원본 산출물 그대로 | **Phase 4 완료 후 재확정** (§6 이관) |
-
----
-
-## §2. Day 2~3 성과 집약 — Phase 0~2 재검증 6건
-
-### §2-1. 재검증 범위
-
-밸런싱문서_일관성점검_v1 §2-1 기준 6건:
-- #1 PC 6001 DPS 1.05
-- #2 Stage 1 일반 몬스터 TTK 5.7s
-- #3 G1 카드 1장 평균 기여도 +22% DPS
-- #4 G1 5장 TTK -45%
-- #5 G1 풀빌드 +399% DPS
-- #6 풀빌드 EHP +42%
-
-### §2-2. 산출물 경로 (원본 SOT)
-
-**`공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md`**
-
-### §2-3. 핵심 결과 (1줄 요지)
-
-Phase 0~2 앵커 전투 시뮬레이션 수치 6건 전수 Unity MCP 실측 대조 완료 — 기존 기획 수치 **유효 확정**.
-
-### §2-4. Phase 4 활용 지점
-
-- **앵커 조건 재사용** (PC 6001 Lv.1 DPS 1.05 · EHP 64) — Phase 4 TTK 산출 시 기준점
-- **G1 5장 -45% TTK 감소율** — Phase 4 조건 난이도 설계 시 "5장 습득 시점 기대 TTK" 참조
-- **풀빌드 +399% 이론치** — Phase 4 고난도 스테이지 상한 검토 시 참조 (실전 +200~280% 추정은 이슈1_3_무시확정_v1.md §3-1-3)
-
----
-
-## §3. Day 4~7 성과 집약 — 성장 요소 기여도 Unity MCP UTF 14/14
-
-### §3-1. 재검증 범위
-
-밸런싱문서_일관성점검_v1 §2-4 기준 6건:
-- #16 각성 만렙 기여도 (목표 +40~60%)
-- #17 진화 6★ 기여도 (목표 +30~50%)
-- #18 장비 일반 셋 기여도 (목표 +20~40%)
-- #19 장비 세트 완성 기여도 (목표 +60~80%)
-- #20 인장 5★ 기여도 (목표 +15~30%)
-- #21 성장 순서 원칙 검증
-
-### §3-2. 산출물 경로 (원본 SOT)
-
-**`공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md`**
-
-### §3-3. 핵심 결과 (실측 수치 — 재확인 용도)
-
-| # | 성장 요소 | 기획 가정 중앙값 | Unity MCP 실측 DPS ratio | 판정 |
-|---|---------|---------------|------------------------|------|
-| #16 | 각성 만렙 | +50% (1.50) | UTF [1.30, 1.70] 범위 내 Passed | 적정 |
-| #17 | 진화 6★ | +40% (1.40) | UTF [1.20, 1.60] 범위 내 Passed | 적정 |
-| #18 | 장비 일반 셋 | +30% (1.30) | **1.3046** (+30.46%) | 적정 (정확 일치) |
-| #19 | 장비 세트 완성 | +70% (1.70) | **1.7146** (+71.46%) | 적정 (정확 일치) |
-| #20 | 인장 5★ | +22% (1.22) | **1.2241** (+22.41%) | 적정 (정확 일치) |
-| #21 | 성장 순서 원칙 | 카드 > 세트장비 > 각성 > 진화 > 장비일반 > 인장 | 측정 5축 내림차순 완전 일치 | 원칙 부합 |
-
-- **Unity MCP EditMode 실측 근거**: DeckBuilding commit `7bb1facd2` · UTF 14/14 Passed
-- **의미**: 기획 원칙이 구현에 부합 확인 — 성장 요소 기여도 #16~#21 6건 **적정 판정**
-
-### §3-4. Phase 4 활용 지점
-
-- **TTK 산출 시 세트 +71.46% 결합** — Phase 4 스테이지별 TTK 예측 기준점
-- **카드 단독 지배 체감 완화 근거** — 5축 시너지 구조(카드 × 장비 × 각성 × 진화 × 인장)는 Phase 4 노드 난이도 설계 시 "플레이어 성장 가정"의 근거
-- **이슈 1·3 무시 결정의 실측 근거** — Phase 4에서 카드 G1 풀빌드 특화 포지션을 전제로 수용
-
----
-
-## §4. Day 8~10 성과 집약 — 이슈 1·3 무시 확정 (PD A안 수용)
-
-### §4-1. 대상
-
-- **이슈 1** — 카드 G1 풀빌드 DPS 이론 +399% / 실전 추정 +200~280%
-- **이슈 3** — 신성 빌드 G4/G5 확장성 (1런 기대 선택수 0.019장)
-
-### §4-2. 산출물 경로 (원본 SOT · 재조사 불요 수준)
-
-**`프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md`** (2026-04-20 Day 8-1·8-2 PD 지시 "향후 재조사 불요" 보강 완료)
-
-### §4-3. PD 결정 원문
-
-> "이슈 1·3은 일부 빌드 특성 + 인장·장비·각성 등 다양한 성장 시너지를 고려할 때 무시해도 될 문제다. Day 8~10은 A안으로 진행하여 간략화 종결한다." — PD님 직접 지시 (2026-04-20)
-
-### §4-4. 핵심 판정 (Phase 4 영향)
-
-1. **카드 G1~G5 수치 전면 유지** — 드래프트 가중치 1000:300:150:50:10 유지
-2. **카드 풀빌드 DPS 목표 +80~120% 유지** — 상향·하향 조정 불요
-3. **이론 +399% / 실전 추정 +200~280% = 특화 빌드 피크치**로 포지션 확정
-4. **신성 빌드 = 접근성 친화 캐주얼 빌드** 포지션 공식 확정
-5. **9조합 전수 기각** (이슈 1 3안 × 이슈 3 3안) — 재논의 대상 아님 (§5-1 트리거 3종만 허용)
-
-### §4-5. Phase 4 활용 지점
-
-- **카드 G1 풀빌드 = 전 빌드 대상 밸런싱 아님** — Phase 4 C9 배치·N2 난이도 설계 시 "특화 빌드는 피크치로 수용" 전제
-- **신성 빌드 접근성 친화 포지션** — Phase 4 ★ 조건 배치 시 신성 빌드 전제로 C9·N3 달성 가능성 고려
-- **이슈 1·3 현 수치 고정 전제** — Phase 4 모든 수치 설계의 상위 전제 (재논의 트리거 §5-1 발동 없는 한 변경 불가)
-
-### §4-6. 재조사 불요 수준 보강 완료
-
-이슈1_3_무시확정_v1.md §3 보강본은 **본 문서 재독만으로 이슈 1·3 전체 맥락 재구성 가능**한 수준. Phase2 §2~§5·Phase3 v2 §2·카드시너지축분석 §2·밸런싱전략 §3·전체테이블감사 §427 5종 원본의 핵심 정량 수치를 §3-1·§3-2에 이식 완료.
-
----
-
-## §5. Day 11~14 성과 집약 — 설계 원칙·판정 체계 (핵심 · 임시 데이터와 분리)
-
-> **본 §5는 Phase 3 종결의 핵심 산출물**. 설계 원칙·판정 체계는 **임시 데이터 수치와 독립적으로 유효**하며, Phase 4 직접 활용 대상이다.
-
-### §5-1. C9 배치 원칙 (금지·적합·주의 3분류)
-
-#### §5-1-1. 금지 기준 (확정 · P17-5)
-
-C9(보스 집중) 조건은 다음 스테이지에 **절대 배치 금지**:
-
-| 기준 | 판정 로직 | 실증 (현 임시 데이터 기반 예시) |
-|------|---------|---------------------------|
-| 단독 보스 스테이지 | 보스 수 = 1 → C9 금지 | Stage 7·10·13 (현 데이터) |
-| 보스 미등장 서브맵 비율 과도 | 보스 등장 서브맵 < 전체 서브맵 30% → C9 금지 | Phase 4 AppearGroup 확정 후 실측 |
-
-**근거 (3축 검증 완료 · 재검증보고_맵패턴_v1 §3-1)**:
-1. **조건 의미성 축**: 단독 보스 = 자동 충족 → 조건 가치 소멸
-2. **페이싱 축**: 단일 전투 집중형 → 페이싱 충돌
-3. **재도전 유도 축**: 타겟 전환 불가
-
-#### §5-1-2. 적합 기준
-
-C9 배치 적합 조건 (Phase 4 스테이지별 판정 시 적용):
-- 보스 수 ≥ 2체
-- 중반 이상 난이도 (입문 1~6은 비권장 — P17-4 정신)
-- P17-5 위반 없음
-
-#### §5-1-3. 주의 기준 (고Shield·특수 구조)
-
-고주의 판정 조건 (Phase 4 시 시뮬 선행):
-- 보스 Shield ≥ 300 → C9 카운트가 Shield 파괴에 과도 집중될 우려
-- 서브맵 수 ≤ 3 → 혼용 여지 최소 (특수 구조)
-- 단일 보스 EHP 극단 (Shield ≥ 500) → 임계값 튜닝 필수
-
-#### §5-1-4. 원본 상세
-
-`재검증보고_맵패턴_v1.md` §3·§4 (레벨 축 3축 검증 + 12개 스테이지 전수 판정)
-
-### §5-2. P17 배타 7종 체크 방식 (42 슬롯 전수)
-
-#### §5-2-1. 배타 조합 7종 (SKILL.md P17 SOT)
-
-| # | 배타 조합 | 사유 |
-|---|----------|------|
-| 1 | C2 ∧ N2 | 피격 최소화 축 이중 부담 |
-| 2 | C6 ∧ 물약 사용 유도 조건 | 물약 빌드 전면 배제 |
-| 3 | C6 ∧ N4 | 회복 빌드 외 빌드 배제 |
-| 4 | (입문 1~6) C1 ∧ C3 | 입문 이중 부담 과도 |
-| 5 | C9 ∧ 단독 보스·보스 미등장 | 논리 불성립 |
-| 6 | (입문 1~6) N3 | 치명타 빌드 미형성 구간 |
-| 7 | N5 ∧ N6 | 타겟팅 자유도 박탈 |
-
-#### §5-2-2. 전수 체크 절차 (Phase 4 각 스테이지 적용 의무)
-
-각 스테이지 슬롯2·슬롯3 배치 확정 전 **7개 조합 전수 체크**:
-
-```
-[Stage N] 슬롯 배치 검증 시트
-  슬롯 2 후보 조건: ___
-  슬롯 3 후보 조건: ___
-
-  #1 C2∧N2:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #2 C6∧물약유도:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #3 C6∧N4:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #4 (1~6)C1∧C3:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #5 C9∧단독보스:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #6 (1~6)N3:         [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #7 N5∧N6:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-
-  [최종 판정] [ ] 통과 / [ ] 재배치 필요 / [ ] PD님 판단 필요
-```
-
-#### §5-2-3. B 방식 중단 트리거 (PD 2026-04-20 확정)
-
-P17 배타 위반 1건이라도 감지 시 **Phase 4 즉시 중단 + PD 확인** (PD B 방식 승계).
-
-#### §5-2-4. 원본 상세
-
-- SKILL.md P17 (배타 7종 SOT)
-- `맵패턴_사전분석_v1.md` §3-3 (검증 시트 템플릿)
-- `재검증보고_맵패턴_v1.md` §6 (42 슬롯 전수 체크 실증 — 현 임시 데이터 기반 위반 0건)
-
-### §5-3. TTK 산출 방법
-
-#### §5-3-1. 기본 공식
-
-```
-TTK = 몬스터 EHP / 플레이어 DPS (성장 5축 결합)
-
-성장 5축 결합 예시:
-기본 DPS 1.05 × 카드 풀빌드(+399%) × 세트 장비(+71.46%) × 각성 만렙(+50%)
-  × 진화 6★(+40%) × 인장 5★(+22.41%)
-```
-
-#### §5-3-2. 활용 기준
-
-- **Day 4~7 실측 ratio 사용 의무** — 기획 가정치가 아닌 Unity MCP UTF 14/14 실측값 사용
-- **성장 시점 가정 명시** — "Lv.X + 각성 Y + 장비 Z + 카드 W장" 구체화
-- **범위 표기** — 평균 시나리오 외 "최소~최대" 범위 병기 (불확실성 명시)
-
-#### §5-3-3. 원본 상세
-
-- `Phase0_1_앵커전투시뮬레이션_v1.md` §1 (앵커 공식)
-- `Phase3_성장요소기여도_v2.md` §2 (Unity MCP 실측 ratio)
-- `이슈1_3_무시확정_v1.md` §3-1-2·§3-1-3 (G1 풀빌드 TTK 산출 예시)
-
-### §5-4. AppearGroup 가이드 프레임 (보스 혼용 원칙 4종 구체화)
-
-#### §5-4-1. 원칙 4종 (재검증보고_맵패턴_v1 §5-1 확정)
-
-| 원칙 | 내용 | Phase 4 구체화 방법 |
-|------|------|-------------------|
-| 1 | 보스 단독 서브맵 비율 ≤ 50% (최종 서브맵 예외) | 서브맵 N개 중 보스 단독 ≤ N/2 · 마지막 서브맵 예외 |
-| 2 | 혼용 몬스터는 스테이지 난이도 중하위권 | 현 스테이지 난이도 −1 구간 몬스터 사용 |
-| 3 | C9 스테이지 보스 등장 서브맵 비율 ≥ 60% | AppearGroup 분해 + Unity MCP 시뮬 검증 |
-| 4 | 단일 스테이지 내 최소 2가지 보스 등장 위치 패턴 | 초반 + 중반 + 최종 서브맵 형태 배분 |
-
-#### §5-4-2. 구체화 프로세스 (Phase 4 적용)
-
-1. 스테이지별 보스 수·서브맵 수 확인 (스테이지난이도곡선_v1 §2)
-2. 원칙 1·4 체크 → 보스 등장 서브맵 위치 가안
-3. 원칙 2 체크 → 혼용 서브맵 일반 몬스터 후보 선정
-4. 원칙 3 체크 → C9 배치 예정 시 비율 보장
-5. ApprearMonsterPattern.json 실 패턴 ID로 치환
-6. Unity MCP 시뮬 검증
-
-#### §5-4-3. 예외 처리
-
-- **Stage 16 특수 구조 인정** — 서브맵 3개·보스 3체 구조상 원칙 1 (50% 이하) 초과 불가피. 인정 처리 (재검증보고_맵패턴_v1 §5-3)
-
-#### §5-4-4. 원본 상세
-
-- `맵패턴_사전분석_v1.md` §2-3·§2-4 (원칙 4종 원안)
-- `재검증보고_맵패턴_v1.md` §5 (원칙 → AppearGroup 가이드 프레임 전환)
-
-### §5-5. 고주의 요소 판정 기준 (ATK·Shield 극단값)
-
-#### §5-5-1. 고주의 임계
-
-Phase 4 스테이지 설계 시 다음 임계 초과 시 **시뮬 선행 필수**:
-
-| 요소 | 임계 | 주의 사유 |
-|------|-----|---------|
-| 보스 Shield | ≥ 300 | C9·N4 카운트가 Shield 파괴에 과도 집중 |
-| 보스 Shield (극단) | ≥ 500 | 단일 보스 EHP 극단 → 임계값 튜닝 필수 |
-| 몬스터 ATK | ≥ 45 | N2 달성 난이도 상위권 · 이중 부담 우려 |
-| 보스 재사용 | ≥ 3회 | 반복 체감 → 맵 패턴 다양화 필수 |
-| 서브맵 수 | ≤ 3 | 혼용 여지 최소 · 특수 구조 처리 |
-
-#### §5-5-2. 고주의 판정 절차
-
-1. 위 임계 조회 → 해당 시 "고주의 슬롯" 마킹
-2. Unity MCP 시뮬 선행 (C9·N2·N4 조건별 달성률 분포)
-3. 맵 패턴 다양화 (동일 보스 3회 이상 재사용 시)
-4. 결과 분석 → 배치 확정 or 재배치
-
-#### §5-5-3. 원본 상세
-
-`재검증보고_맵패턴_v1.md` §6-4 (⚠️ 고주의 슬롯 4개 별도 관리 예시)
-
-### §5-6. 임시 데이터 수치 부분 명시 분리 (PD B안 수용의 핵심)
-
-**본 §5의 모든 원칙·판정 도구는 "설계 체계"에 속하며, 특정 임시 데이터 수치와 독립적으로 유효하다.**
-
-다음은 **임시 데이터 기준 수치로, Phase 4 완료 후 재확정 대상**이다:
-
-- Stage 7·10·13의 단독 보스 판정 (현 임시 데이터 기준)
-- 42 슬롯 P17 전수 체크 결과 (현 임시 조합 풀 기준)
-- Stage 11~15 TTK 수치 (현 임시 몬스터 HP·Shield 기준)
-- ⚠️ 고주의 4개 슬롯 식별 (현 임시 데이터의 Stage 15·17 슬롯2·3)
-
-**태그 원칙**: 본 문서 본문에 임시 수치 등장 시 "(현 임시 데이터 기반)" 또는 "Phase 4 재확정 대상" 명시. **설계 원칙 본문에는 구체 수치 최소화**.
-
----
-
-## §6. Day 15+ 선택지 7종 처리 결과
-
-### §6-1. 처리 3분류
-
-재검증보고_맵패턴_v1 §8-1의 Day 15+ 반영 후보 7종을 PD B안 수용 결정에 따라 3가지 처리 그룹으로 분류:
-
-#### §6-1-1. **설계 원칙 성격** (본 문서 §5에 집약 완료)
-
-다음 3종의 **설계 원칙 부분**은 본 문서 §5에 집약 완료 — 별도 문서 수정 불요:
-
-| # | 원본 반영 대상 | 본 문서 집약 위치 | 성격 |
-|---|-------------|---------------|------|
-| 1 | `맵패턴_사전분석_v1.md` §1-4 C9 적합 스테이지 우선순위 분류 | §5-1 C9 배치 원칙 | 판정 체계 |
-| 2 | `맵패턴_사전분석_v1.md` §2-3 보스 혼용 원칙 → AppearGroup 가이드 프레임 | §5-4 AppearGroup 가이드 프레임 | 설계 원칙 |
-| 3 | `맵패턴_사전분석_v1.md` §3-2 N4 Shield 확보 가능성 검증 기준 | §5-5 고주의 요소 판정 기준 | 판정 체계 |
-
-#### §6-1-2. **임시 데이터 수치** (Phase 4 완료 후 재확정 대상 — 이관)
-
-다음 3종은 **임시 데이터 기반 수치**이므로 Phase 4에서 실 노드 구성 확정 후 재확정:
-
-| # | 대상 문서·섹션 | 내용 | Phase 4 재확정 시점 |
-|---|-------------|-----|------------------|
-| 1 | `맵패턴_42슬롯_현황테이블_v1.md` §7 | Stage 11·17 Shd 고스탯 C9 임계값 주의 + ⚠️ 고주의 4개 슬롯 (Stage 15·17 슬롯2·3) | Phase 4 실 배치 확정 시 재식별 |
-| 2 | `스테이지난이도곡선_v1.md` §8 | Stage 11~15 TTK 수치 테이블 + Stage 15 흑기사1 재사용 3회째 주의 | Phase 4 노드 구성 확정 후 재산출 |
-| 3 | `밸런싱전략_v1.md` §3 Phase 4 | G1 DPS 목표 수치 v2 반영 | Phase 4 완료 + PD 별도 결정 시 |
-
-**이관 근거**: Phase 4가 스테이지별 실 노드 구성 단계이므로, 노드 구성 확정 전 본 3종의 임시 데이터 기반 수치는 **유효 기간이 한정적**. Phase 4 완료 시점에 최신 임시 데이터 or 실 데이터 기준으로 재산출하는 것이 정확.
-
-#### §6-1-3. **완료 처리만** (본 문서에서 선언)
-
-다음 1종은 **작업 완료 상태 선언만** 필요:
-
-| # | 대상 | 선언 |
-|---|-----|-----|
-| 1 | `밸런싱문서_일관성점검_v1.md` §2-3 | **Stage 11~15 판정 결과 "적정" 완료 처리** (재검증보고_맵패턴_v1 §2 종합 판정 "양축 일치 적정" 근거) — Phase 3 종결 시점 완료 선언 |
-
-### §6-2. 처리 요약
-
-- 본 문서 §5 집약 완료 (3종) + Phase 4 이관 (3종) + 완료 선언 (1종) = 7종 전수 처리
-
----
-
-## §7. Phase 4 입력 자원 맵 (네비게이션)
-
-### §7-1. Phase 4 작업 단계별 입력 자원
-
-Phase 4(스테이지별 노드 구성) 작업 순서와 본 문서의 각 §가 매핑되는 구조:
-
-| Phase 4 단계 | 본 문서 §·외부 SOT | 활용 방식 |
-|------------|-----------------|---------|
-| 1. 스테이지 목표 난이도·재미 포지션 정의 | §3-3 실측 ratio + §4-4 이슈 1·3 전제 + `밸런싱전략_v1.md` §3 | 5축 시너지 구조 전제로 난이도 설정 |
-| 2. 노드 배치 초안 (AppearGroup 가이드 적용) | §5-4 AppearGroup 가이드 프레임 + §5-1 C9 배치 원칙 | 원칙 4종 + C9 금지·적합 기준 동시 적용 |
-| 3. P17 배타 7종 체크 | §5-2 P17 전수 체크 절차 + `맵패턴_사전분석_v1.md` §3-3 템플릿 | 스테이지별 슬롯2·슬롯3 후보 조합 체크 |
-| 4. TTK 검증 | §5-3 TTK 산출 방법 + §2-3 앵커 재사용 + §3-3 성장 5축 결합 | Day 4~7 실측 ratio 사용 의무 |
-| 5. 고주의 요소 판정 | §5-5 고주의 임계 5종 | ATK·Shield 극단값 시뮬 선행 |
-| 6. 최종 확정 + ToolData.json 재생성 | 개발팀 Tool_Left 배치 REQ | Phase 4 완료 시 개발팀 요청 |
-
-### §7-2. 원본 산출물 직접 참조 (Phase 4 작업 중 수시 열람)
-
-| 용도 | 원본 경로 |
-|------|----------|
-| 이슈 1·3 전제 전수 재구성 | `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` §3 (재조사 불요 수준) |
-| 42 슬롯 P17 전수 체크 예시 | `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` §6 |
-| 성장 요소 Unity MCP 실측 원시 | `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` |
-| Phase 0~2 앵커 재검증 | `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md` |
-| 3성 조건 12개 판정 로직 | `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` |
-| 스테이지 구조 SOT | `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` |
-| 카드·빌드 분석 | `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` · `카드시너지축분석_v1.md` |
-
----
-
-## §8. 누락 방지 체크리스트 (Phase 3 전수 보존 확인 — PD 지시 직접 대응)
-
-> **PD 2026-04-20 지시**: "지금까지 진행된 내용은 누락되지 않도록 잘 공유해야 해"
-
-### §8-1. Phase 3 Day 1~14 산출물 전수 확인 (17종)
-
-| # | Day | 산출물 경로 | 상태 | 본 문서 참조 |
-|---|-----|-----------|------|-----------|
-| 1 | Day 1 | `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` | 보존 ✅ | §0-3 선행산출물 |
-| 2 | Day 2~3 | `공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md` | 보존 ✅ | §2 |
-| 3 | Day 4~7 | `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` | 보존 ✅ | §3 |
-| 4 | Day 8~10 | `프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md` | 보존 ✅ | §4 |
-| 5 | Day 8~10 | `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` | 아카이브 보존 ✅ | §4-5 기각안 9조합 근거 |
-| 6 | Day 11~14 | `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` | 보존 ✅ | §5 |
-| 7 | Day 11~14 | `공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md` | 보존 ✅ | §5 레벨 축 근거 |
-| 8 | Day 11~14 | `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md` | 보존 ✅ | §5 밸런스 축 근거 |
-| 9 | 사전 | `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` | 보존 ✅ | §5-2·§5-4 원안 |
-| 10 | 사전 | `프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md` | 보존 ✅ | §6-1-2 이관 |
-| 11 | 사전 | `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` | 보존 ✅ | §7-2 Phase 4 참조 |
-| 12 | 밸런싱 | `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` | 보존 ✅ | §6-1-2 이관 |
-| 13 | 밸런싱 | `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md` | 보존 ✅ | §6-1-3 완료 선언 |
-| 14 | 밸런싱 | `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` | 보존 ✅ | §6-1-2 이관 |
-| 15 | 밸런싱 | `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` | 보존 ✅ | §4 원본 참조 |
-| 16 | 밸런싱 | `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` | 보존 ✅ | §4 원본 참조 |
-| 17 | 밸런싱 | `프로젝트/수상한잡화점/기획/Phase0_1_앵커전투시뮬레이션_v1.md` | 보존 ✅ | §2 앵커 근거 |
-
-**전수 보존 확인**: **17/17 = 누락 0건**
-
-### §8-2. 설계 체계 핵심 항목 5종 집약 확인
-
-| # | 핵심 항목 | 본 문서 §·외부 SOT | 집약 상태 |
-|---|---------|-----------------|---------|
-| 1 | C9 배치 원칙 (금지·적합·주의) | §5-1 | ✅ |
-| 2 | P17 배타 7종 체크 방식 | §5-2 | ✅ |
-| 3 | TTK 산출 방법 (5축 결합) | §5-3 | ✅ |
-| 4 | AppearGroup 가이드 프레임 | §5-4 | ✅ |
-| 5 | 고주의 요소 판정 기준 | §5-5 | ✅ |
-
-**집약 완료**: 5/5
-
-### §8-3. 실측 데이터 보존 확인
-
-| 데이터 | 원본 | 본 문서 참조 |
-|-------|-----|-----------|
-| Phase 0~2 재검증 6건 | `재검증보고_Phase0_1_2_v1.md` | §2 요지 |
-| 성장 요소 #16~#21 Unity MCP UTF 14/14 | `Phase3_성장요소기여도_v2.md` | §3-3 표 |
-| 42 슬롯 × P17 전수 체크 | `재검증보고_맵패턴_v1.md` §6 | §5-2-4 원본 지정 |
-| 이슈 1·3 현 상태 재조사 불요 수준 | `이슈1_3_무시확정_v1.md` §3 | §4-6 원본 지정 |
-
-**데이터 보존 확인**: 4/4
-
-### §8-4. 종합 누락 방지 판정
-
-- 산출물 전수 보존: **17/17 ✅**
-- 설계 체계 집약: **5/5 ✅**
-- 실측 데이터 보존: **4/4 ✅**
-
-**Phase 3 전수 보존 — 누락 0건 확인 완료.**
-
----
-
-## §9. 기각안 (P24 · C32 필수)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | Phase 3을 "미완료"로 선언하고 Day 15+ 원안 속행 | PD 2026-04-20 B안 수용 결정 위반. 현 스테이지 데이터 임시 → Day 15+ 원안 실효 한정. B안 수용 원문 "이미 진행된 내용은 종결하고 Phase 4 분리" |
-| 2 | 설계 원칙을 원본 산출물 본문에 수정 이식 | C14-5 "본문 최신 + 참조" 위반 후보 · C6-1 원본 보호 위반 후보. 본 문서가 집약 SOT 역할 수행. 원본은 그대로 보존 |
-| 3 | 임시 데이터 수치까지 본 문서에 확정 이식 | PD B안 수용 원문 "현 스테이지 데이터 = 임시". 임시 수치 확정 이식은 Phase 4 완료 후 재확정 정신 위반 |
-| 4 | Day 15+ 7종을 전수 "완료 처리"로 단일화 | 3분류(집약·이관·완료) 분리 필요. §6-1에서 각 7종의 성격을 명확히 구분 |
-| 5 | 이슈 1·3 재논의 트리거를 본 종결 문서에서 완화 | 이슈1_3_무시확정_v1.md §5-1 트리거 3종은 PD 결정 수용. 기획팀장 재량 완화 금지 (C36 방향·원칙 수준 축소 금지) |
-| 6 | P17 체크를 "Phase 3에서 완료"로 선언 | 42 슬롯 체크는 현 임시 데이터 기준. Phase 4 실 배치 확정 시 재수행 의무. 완료 선언은 오판 |
-| 7 | Phase 4 범위·방법론까지 본 문서에서 확정 | C36 PM·팀장 재량 상한 위반 후보. Phase 4 범위·방법론은 Phase4_노드구성_착수가이드_v1.md에서 착수 가이드 수준으로 분리 |
-| 8 | Day 1 Phase3_재개준비_체크리스트_v1 완료 상태 갱신 | 해당 문서는 Phase 3 재개 "예비" 단계 설계. Phase 3 종결 선언과 무관 · 참조 링크 보존만으로 충분 |
-| 9 | 밸런싱문서_일관성점검_v1 §2-3 외 28개 재검증 항목 전체 완료 처리 | Stage 11~15 판정 외 항목은 Day 2~3·Day 4~7로 분산 완료. 일괄 완료 처리는 추적성 희석. §6-1-3에 한정 선언 |
-| 10 | 본 문서를 "설계 원칙 SOT"가 아닌 "설계 원칙 본문"으로 포지셔닝 | C14-5 SOT 단일화 원칙 위반. 본 문서는 집약·네비게이션 역할이지 SOT 대체 아님. 원본 산출물이 여전히 SOT (본 문서 §7-2 명시) |
-| 11 | Phase 4 Day 1 착수 준비를 본 문서에서 직접 명시 | 착수 가이드는 Phase4_노드구성_착수가이드_v1.md에 분리. 본 문서는 Phase 3 종결 전담 |
-
----
-
-## §10. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (PM 경유 PD B안 수용 집행) | 초안 작성 · Phase 3 종결 선언 + 설계 체계 확립 단계 재정의 · Day 2~3·Day 4~7·Day 8~10·Day 11~14 성과 전수 집약 · Day 15+ 선택지 7종 3분류 처리 · Phase 4 입력 자원 맵 제공 · 누락 방지 체크리스트 17/17 전수 확인 · 기각안 11종 |
-
----
-
-## §11. 재미 근거 (P30 기획팀 전용)
-
-**강화하려는 재미 축**: "설계 체계 기반 재도전 유도 일관성 + 차기 프로젝트 자산 계승"
-
-- **재도전 유도 일관성**: Phase 3 설계 체계(C9 배치 원칙·P17 배타 7종·AppearGroup 가이드·고주의 판정)가 Phase 4 전 스테이지에 **일관 적용**됨으로써 플레이어가 스테이지마다 "다르면서도 공정한" 재도전 경험 보장. 동일 배타·주의 기준이 모든 스테이지에 적용되므로 "왜 이 스테이지는 가능한데 다른 스테이지는 안 되는가" 혼란 제거.
-- **차기 프로젝트 자산 계승 (P29)**: 본 설계 체계는 수상한잡화점 한정이 아닌 **Prove-2-of-3 체계 전반에 재사용 가능한 판정 도구**. 차기 프로젝트에서 조건 풀·배타 조합만 재정의하면 본 체계 그대로 활용 가능. 헌법 제1원칙 ②(경험 축적·계승·발전) 직결.
-- **임시 데이터 분리의 재미 보호 효과**: 설계 원칙을 임시 데이터와 분리함으로써 "Phase 4에서 실 노드 구성 시 설계 체계가 흔들리지 않는" 보장. 플레이어가 느낄 "재도전 유도 공정성"은 설계 체계에 내재되며, 수치 변화는 난이도 튜닝 영역으로 국한됨.
-- **누락 방지 체크리스트의 품질 보호**: 17/17 전수 보존 확인은 "이전 작업 경험이 Phase 4에서 소실되지 않는다"는 품질 안전망. 기획자가 Phase 4에서 "잊혀진 원칙" 때문에 재작업하는 리스크 차단 → 창의적 노드 구성에 집중 가능.
-
----
-
-## §12. 관련 규칙·참조
-
-- **헌법 제1원칙 ②** (경험 축적·계승·발전) — 본 문서의 상위 근거
-- **C6-1** 원본 파일 보호 — 원본 산출물 그대로 보존 원칙
-- **C14-5** 본문 최신 + 참조 링크 — 본 문서가 집약 SOT + 원본 참조 구조
-- **C22** 용어 일관 — "Phase 3·Day 2~3·Day 4~7·Day 8~10·Day 11~14·Day 15+" PD 도입 용어 유지
-- **C23** 정직성 — 원본 실측 인용 · 임시 데이터 명시 태그
-- **C25** 넘버링 일관 — §0~§12 고정 위계
-- **C36** PM·팀장 재량 상한 — Phase 4 범위·방법론 확정은 PD 결정 영역 (§9 기각안 #7 준수)
-- **C37** 규칙 문서 관리 — 섹션 구조·표기법 통일
-- **P16** 산출물 추적성 — §10 변경 이력
-- **P17** ★ 조건 배타 배치 규칙 — §5-2 SOT 참조
-- **P18** 설계 문서화 의무 — 본 문서가 설계 체계 문서
-- **P24·C32** 기각안 필수 — §9
-- **P29** 코어 프레임워크 조직 자산 계승 — §11 재미 근거
-- **P30** 재미 우선 원칙 — §11
-
----
-
-*Phase 3 종결 선언: 2026-04-20*
-*설계 체계 확립 단계 완료 — Phase 4(스테이지별 노드 구성) 착수 준비 완료*
diff --git a/프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md b/프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md
deleted file mode 100644
index bdbe077..0000000
--- a/프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md
+++ /dev/null
@@ -1,435 +0,0 @@
----
-type: Phase 착수 가이드
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD B안 수용 집행)
-관련PD지시: PD 2026-04-20 B안 수용 "Phase 4 = 스테이지별 노드 구성 작업을 신규 Phase로 분리해서 이제부터 기획팀에서 스테이지별 노드를 구성해줘"
-상태: **착수 가이드 v1** · Phase 4 Day 1 착수 준비 완료
-선행문서:
-  - 프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md (Phase 3 종결 + 설계 체계 SOT)
-  - 프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md (Day 11~14 통합)
-  - 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md (Day 8~10 PD A안 전제)
-  - 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md (스테이지 구조 SOT)
-  - 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 PD 3차 승인)
-  - SKILL.md P17 (배타 7종 SOT)
----
-
-# Phase 4 — 스테이지별 노드 구성 착수 가이드 v1
-
-## §1. Phase 4 범위
-
-### §1-1. 작업 대상
-
-**수상한 잡화점 Chapter 1~6 전체 125 스테이지 × 스테이지별 노드 구성 확정**
-
-- 각 스테이지의 실 노드 배치 확정
-- 각 스테이지의 슬롯2·슬롯3 ★ 조건 실 배치 확정
-- 각 스테이지의 AppearGroup 실 패턴 ID 확정
-- 최종 결과물: ToolData.json 재생성 (개발팀 Tool_Left 배치 REQ)
-
-### §1-2. 작업 외 (명시적 금지)
-
-- **설계 원칙 재수정 금지** — Phase 3 종결 문서 §5 집약 완료. 원칙 자체 변경은 C36 방향·원칙 수준 PM·팀장 재량 상한 위반 후보 (PD 재승인 필수)
-- **이슈 1·3 수치 재논의 금지** — 이슈1_3_무시확정_v1.md §5-1 재논의 트리거 3종 외 금지
-- **조건 풀 12개 신규 추가 금지** — PD 3차 승인 범위 내 배치만 허용
-- **Chapter 구조 변경 금지** — 125 스테이지 현 구조 유지
-
-### §1-3. 착수 근거
-
-PD 2026-04-20 B안 원문:
-
-> "B안으로 진행해서 이미 진행된 내용은 종결하고, Phase 4 = 스테이지별 노드 구성 작업을 신규 Phase로 분리해서 이제부터 기획팀에서 스테이지별 노드를 구성해줘."
-
----
-
-## §2. 입력 자료 (Phase 3 산출물 + 고정 전제)
-
-### §2-1. 설계 체계 SOT (집약본)
-
-**`프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md`**
-
-- §5 설계 원칙·판정 체계 (C9 배치·P17 체크·TTK·AppearGroup·고주의 판정)
-- §7 Phase 4 입력 자원 맵 (작업 단계별 §·SOT 매핑)
-
-### §2-2. 실측 데이터 근거
-
-- **`공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md`** — Unity MCP UTF 14/14 성장 요소 ratio 실측
-- **`공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md`** — Phase 0~2 앵커 재검증 6건
-- **`프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md`** — Day 11~14 레벨·밸런스 축 통합 (현 임시 데이터 기반 예시 포함)
-
-### §2-3. 고정 전제 (이슈 1·3 무시 확정)
-
-**`프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md`** §3 (재조사 불요 수준)
-
-- 카드 G1 풀빌드 DPS 이론 +399% / 실전 추정 +200~280% = **특화 빌드 피크치**로 수용
-- 신성 빌드 = **접근성 친화 캐주얼 빌드** 포지션 공식
-- 카드 수치 전면 유지 · 드래프트 가중치 1000:300:150:50:10 유지
-- 재논의 트리거 3종(§5-1) 외 재논의 금지
-
-### §2-4. 조건 풀 12개 (PD 3차 승인)
-
-**`프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md`**
-
-- C1·C2·C3·C6·C9·C12 + N2·N3·N4·N5·N6 + 1개 (풀 확정)
-- 신규 조건 추가 금지 (PD 재승인 필수)
-
-### §2-5. P17 배타 7종 (SKILL.md SOT)
-
-1. C2 ∧ N2 · 2. C6 ∧ 물약 · 3. C6 ∧ N4 · 4. (입문 1~6) C1 ∧ C3 · 5. C9 ∧ 단독보스·미등장 · 6. (입문 1~6) N3 · 7. N5 ∧ N6
-
-### §2-6. 스테이지 구조 SOT
-
-**`프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md`** §2 — 스테이지별 보스 수·보스 ID·서브맵 수
-
----
-
-## §3. 작업 흐름 (5단계 · Phase 4 각 스테이지 적용 의무)
-
-### §3-1. 단계 1: 스테이지별 목표 난이도·재미 포지션 정의
-
-**수행 내용**:
-1. 해당 스테이지 Chapter 내 위치 확인 (입문 1~6 · 중반 7~12 · 후반 13~21 …)
-2. 목표 난이도 설정 (★1·★2·★3 달성률 기대치)
-3. 재미 포지션 정의 (P30 재미 축 중 어느 것을 강화하는지 명시)
-4. 5축 성장 시너지 구조 전제로 플레이어 예상 상태 설정
-
-**입력 자원**:
-- Phase3_종결_설계체계_v1.md §3-3 실측 ratio + §4-4 이슈 1·3 전제
-- 스테이지난이도곡선_v1.md §2 구조 SOT
-- 밸런싱전략_v1.md §3 Phase 목표 (단 §6-1-2 Phase 4 완료 후 재확정 대상 제외)
-
-**산출 형식**:
-```
-Stage N 목표 정의
-- 위치: Chapter X · 구간 (입문·중반·후반·최종)
-- 목표 난이도: ★1 클리어율 A% · ★2 B% · ★3 C% (기대)
-- 재미 포지션: (P30 재미 축 중 1~2개)
-- 플레이어 예상 상태: Lv.X · 각성 Y · 장비 Z · 카드 W장
-- 특이 주의 사항: (고주의 요소 예고)
-```
-
-### §3-2. 단계 2: 노드 배치 초안 (AppearGroup 가이드 적용)
-
-**수행 내용**:
-1. 서브맵 수·보스 수 확인 (스테이지난이도곡선_v1 §2)
-2. AppearGroup 가이드 프레임 적용 (Phase3_종결_설계체계_v1 §5-4):
-   - 원칙 1: 보스 단독 서브맵 ≤ 50%
-   - 원칙 2: 혼용 몬스터 = 현 스테이지 난이도 −1 구간
-   - 원칙 3: C9 스테이지 보스 등장 서브맵 ≥ 60%
-   - 원칙 4: 최소 2가지 보스 등장 위치 패턴
-3. ApprearMonsterPattern.json 실 패턴 ID 후보 선정
-4. Stage 16 등 특수 구조는 §5-4-3 예외 처리 확인
-
-**입력 자원**:
-- Phase3_종결_설계체계_v1.md §5-4 AppearGroup 가이드 프레임
-- 맵패턴_사전분석_v1.md §2-3·§2-4 (사전 프레임)
-- 재검증보고_맵패턴_v1.md §5 (11~16 프레임 예시)
-- ApprearMonsterPattern.json (개발팀 자산)
-
-**산출 형식**:
-```
-Stage N 노드 배치 초안
-- 서브맵 수: X · 보스 수: Y
-- 서브맵별 배치:
-  서브맵 1: 일반 몬스터 집중 (패턴 ID 후보: ___)
-  서브맵 2: 보스+혼용 (패턴 ID 후보: ___)
-  ...
-- 원칙 1 체크: 보스 단독 ≤ 50% [O/특수]
-- 원칙 2 체크: 혼용 난이도 −1 [O/X]
-- 원칙 3 체크 (C9 배치 시): 보스 서브맵 ≥ 60% [O/X]
-- 원칙 4 체크: 배치 패턴 ≥ 2가지 [O/X]
-```
-
-### §3-3. 단계 3: P17 배타 7종 체크 (42 슬롯 전수)
-
-**수행 내용**:
-1. 해당 스테이지 슬롯2·슬롯3 ★ 조건 후보 선정
-2. Phase3_종결_설계체계_v1 §5-2-2 검증 시트 적용
-3. **7종 배타 조합 전수 체크**
-4. **위반 1건이라도 감지 시 즉시 중단 + PD 확인** (PD B 방식)
-
-**입력 자원**:
-- Phase3_종결_설계체계_v1.md §5-2 P17 전수 체크 절차
-- 맵패턴_사전분석_v1.md §3-3 검증 시트 템플릿
-- SKILL.md P17 (배타 7종 SOT)
-- 3성조건_12개_상세명세_v1.md (조건 풀)
-
-**산출 형식**: §5-2-2 검증 시트 (스테이지별 1장)
-
-**B 방식 중단 트리거**:
-- P17-1~P17-7 중 **1건이라도 "위반"** 감지 → Phase 4 즉시 중단 → PD 확인 요청
-- "⚠️ 주의" 등급은 중단 대상 아님 (회피·시뮬 권장 사항)
-
-### §3-4. 단계 4: TTK 검증
-
-**수행 내용**:
-1. 각 서브맵의 몬스터 EHP 산출
-2. 플레이어 예상 DPS 산출 (5축 결합 — Day 4~7 실측 ratio 사용)
-3. 서브맵별 TTK 산출 + 전체 스테이지 TTK 범위 산출
-4. 고주의 임계 체크 (§3-5와 병행)
-
-**입력 자원**:
-- Phase3_종결_설계체계_v1.md §5-3 TTK 산출 방법
-- Phase3_성장요소기여도_v2.md (성장 요소 ratio 실측)
-- Phase0_1_앵커전투시뮬레이션_v1.md §1 (앵커 공식)
-
-**산출 형식**:
-```
-Stage N TTK 검증
-- 플레이어 가정: Lv.X · 각성 Y · 카드 W장
-- 플레이어 DPS (5축 결합): A.BC
-  = 기본 1.05 × 카드(+N%) × 세트(+71.46%) × 각성(+50%) × 진화(+40%) × 인장(+22.41%)
-- 서브맵별 TTK:
-  서브맵 1 (일반): X.Xs ~ Y.Ys
-  서브맵 2 (보스+혼용): X.Xs ~ Y.Ys
-  ...
-- 스테이지 전체 TTK: 최소 ~ 최대
-- 목표 난이도 정합: [적정/과도/부족]
-```
-
-### §3-5. 단계 5: 고주의 요소 판정 + 최종 확정
-
-**수행 내용**:
-1. Phase3_종결_설계체계_v1 §5-5 고주의 임계 5종 체크:
-   - 보스 Shield ≥ 300·500
-   - 몬스터 ATK ≥ 45
-   - 보스 재사용 ≥ 3회
-   - 서브맵 수 ≤ 3
-2. 고주의 감지 시 Unity MCP 시뮬 선행 (조건별 달성률 분포)
-3. 맵 패턴 다양화 (동일 보스 3회 이상 재사용 시)
-4. 최종 확정 승인 → ToolData.json 재생성 트리거 (§3-6)
-
-**입력 자원**:
-- Phase3_종결_설계체계_v1.md §5-5 고주의 요소 판정 기준
-- 재검증보고_맵패턴_v1.md §6-4 (⚠️ 고주의 슬롯 관리 예시)
-- Unity MCP EditMode 시뮬 환경
-
-**산출 형식**:
-```
-Stage N 고주의 판정
-- 보스 Shield 최대: XXX → [임계 미만/주의/고주의]
-- 몬스터 ATK 최대: XX → [임계 미만/주의]
-- 보스 재사용: N회 → [미해당/주의]
-- 서브맵 수: X → [일반/특수]
-- 시뮬 선행 필요: [아니오/예 (항목: ___)]
-- 맵 패턴 다양화 필요: [아니오/예 (방향: ___)]
-- 최종 확정: [통과/재배치/PD 확인]
-```
-
-### §3-6. ToolData.json 재생성 (개발팀 Tool_Left 배치 REQ)
-
-**트리거 시점**: 단계 1~5 완료 + PD 승인 후
-
-**수행 내용**:
-1. 해당 스테이지 청크 단위 완료 선언
-2. 개발팀 REQ 발행 (`공유/소통/기획팀→개발팀/`)
-3. 개발팀 Tool_Left 배치 로직 적용 · ToolData.json 재생성
-4. Unity MCP 검증 결과 수령 · 필요 시 반영
-
----
-
-## §4. 판정 기준 (Phase 3 §5 원칙 전수 적용)
-
-### §4-1. 배치 차단 기준 (위반 시 Phase 4 진행 불가)
-
-1. **P17 배타 7종 위반** (§3-3 B 방식 중단 트리거)
-2. **C9 배치 금지 스테이지** 에 C9 배치 (§5-1-1 — 단독 보스 or 보스 미등장 과도)
-3. **입문 1~6 구간에 C1∧C3·N3·C9 배치** (§5-1-2 비권장 + P17-4·P17-6)
-4. **Stage 16 외 원칙 1 (보스 단독 ≤ 50%) 위반** (Stage 16 특수 구조 예외)
-5. **조건 풀 12개 외 신규 조건 배치 시도** (PD 3차 승인 범위 위반)
-
-### §4-2. 시뮬 선행 기준 (배치 확정 전 Unity MCP 시뮬 필수)
-
-- 보스 Shield ≥ 500 (극단)
-- 보스 재사용 ≥ 3회
-- 서브맵 수 ≤ 3 (특수 구조)
-- C9 배치 예정 + 보스 Shield ≥ 300 (임계값 튜닝)
-
-### §4-3. PD 확인 필수 기준
-
-- P17 배타 위반 감지 (B 방식)
-- 설계 원칙 자체 재검토 필요성 식별 (C36 방향·원칙 수준)
-- 이슈 1·3 재논의 트리거 발동 (이슈1_3_무시확정_v1 §5-1)
-- 조건 풀 12개 외 신규 조건 추가 제안
-
-### §4-4. 재미 판정 기준 (P30 기획팀 전용)
-
-각 스테이지 배치 확정 전 P30 재미 근거 명시 의무:
-- "이 배치가 어떤 재미를 강화하는가?"
-- "재미 축: 빌드 다양성·재도전 유도·고난도 체감·전략 선택·서사 몰입 중 어느 것?"
-- 재미 정의 없는 수치 조정 금지
-
----
-
-## §5. 담당·병렬 호출 체계
-
-### §5-1. Phase 3 동일 체계 승계
-
-Phase 3 Day 11~14 병렬 호출 체계(기획팀장 + level-designer + balance-designer 병렬)를 **Phase 4에도 동일 적용**.
-
-### §5-2. 에이전트별 책임
-
-| 에이전트 | Phase 4 역할 |
-|---------|------------|
-| **기획팀장** | 전체 진행 관리 · P17 전수 체크 주도 · PD 보고 · 팀원 결과 통합 · 본 가이드 준수 감독 |
-| **system-designer** | 조건 판정 로직 정합성 검증 · 성장 5축 시너지 구조 검증 |
-| **content-designer** | AppearGroup 내 혼용 몬스터 선정 (원칙 2 난이도 −1 적용) · 보스 혼용 패턴 다양화 |
-| **level-designer** | 스테이지별 노드 배치 초안 · AppearGroup 가이드 적용 · 원칙 1·3·4 체크 · 맵 패턴 다양화 |
-| **balance-designer** | TTK 검증 · 고주의 요소 판정 · Unity MCP 시뮬 실행 · 5축 결합 DPS 산출 |
-| **narrative-designer** | (선택) 스테이지별 재미 포지션의 서사 맥락 반영 |
-| **ux-designer** | ★ 조건 UI 표시 방안 검토 (3성조건_12개_상세명세_v1 §3·§4 참조) |
-
-### §5-3. 병렬 호출 원칙
-
-- **독립 작업은 병렬**: 스테이지 초안 (level) + TTK 검증 (balance) + 혼용 몬스터 선정 (content) 동시
-- **의존 작업은 순차**: §3-1 목표 정의 → §3-2 노드 배치 → §3-3 P17 체크 → §3-4 TTK → §3-5 고주의 → §3-6 REQ
-- **기획팀장 통합 의무**: 병렬 산출물 교차 검증 후 통합 판정 (재검증보고_맵패턴_v1 §1-2 교차 검증 방식 승계)
-
----
-
-## §6. Day 단위 로드맵 초안
-
-> **C9-2 일정·기한 표현 금지 준수**: 본 Day는 **작업 청크 단위**이지 시간 단위 계획이 아님. "선행 작업 완료 후 착수" 종속 관계만 관리.
-
-### §6-1. Day 1 — 착수 준비
-
-| # | 작업 | 담당 | 산출물 |
-|---|-----|------|-------|
-| 1-1 | 125 스테이지 목록 전수 확인 + 우선순위 정의 | 기획팀장 + level | 스테이지 우선순위 표 |
-| 1-2 | Chapter별 우선순위 정리 (입문 → 중반 → 후반 순) | 기획팀장 | 청크 순서 |
-| 1-3 | Phase 3 종결 문서 §5 설계 체계 전수 숙지 | 전 팀원 | 숙지 완료 선언 |
-| 1-4 | Unity MCP 시뮬 실행 가이드 재확인 | balance | 실행 준비 완료 |
-| 1-5 | Day 2~ 병렬 호출 체계 시작점 결정 | 기획팀장 + PM 협의 | 착수 청크 결정 |
-
-**재개 트리거**: PD Phase 4 착수 승인 (본 가이드 승인 포함)
-
-### §6-2. Day 2~N — 스테이지별 노드 구성 (청크 단위)
-
-**청크 분할 권장**:
-- **청크 1**: Chapter 1 (Stage 1~6 · 입문 구간) — P17-4·P17-6 적용 영역 · 입문 밸런싱 민감
-- **청크 2**: Chapter 2 (Stage 7~12 · 중반 구간) — C9 배치 시작 · P17-5 집중 영역
-- **청크 3**: Chapter 3 (Stage 13~18 · 후반 진입) — 보스 EHP 극단 시작 · 고주의 영역
-- **청크 4**: Chapter 4~6 (Stage 19~ · 최종 영역) — 최종 보스 스테이지 (상세 범위는 Phase 4 착수 시 125 스테이지 목록 기반 재확정)
-
-**청크별 작업 순서** (§3 5단계 반복):
-1. 청크 내 스테이지 목표 정의 (병렬)
-2. 노드 배치 초안 (병렬)
-3. P17 체크 (기획팀장 주도)
-4. TTK 검증 (병렬)
-5. 고주의 판정 (병렬)
-6. 청크 완결 보고 → ToolData.json 재생성 REQ
-
-### §6-3. Day 종료 단위 — ToolData.json 재생성 트리거
-
-각 청크 완료 시:
-1. 기획팀장 완결 검증
-2. PM 경유 PD 승인
-3. 개발팀 Tool_Left REQ 발행 (`공유/소통/기획팀→개발팀/`)
-4. 개발팀 ToolData.json 재생성
-5. Unity MCP 검증 결과 수령
-
-### §6-4. Day 종결 — Phase 4 v1 최종본 + 밸런싱전략 §3 공식 확정
-
-전 125 스테이지 노드 구성 확정 후:
-1. **Phase 4 v1 최종본 작성** (스테이지별 노드 구성 SOT)
-2. **밸런싱전략_v1.md §3 Phase 4 공식 확정** (Phase 3 §6-1-2 이관 대상 재확정)
-3. **42 슬롯 현황 테이블 v2 작성** (임시 데이터 기반 → 확정 기반 전환)
-4. **스테이지난이도곡선_v1.md §8 Stage별 TTK 수치 공식 등재**
-5. Phase 4 종결 선언 + Phase 5 착수 여부 PD 결정 수령
-
----
-
-## §7. Phase 3·Phase 4 연계 원칙 — 원칙 vs 실 구성 분리 유지
-
-### §7-1. 분리 원칙 (§5-6 임시 태그 참조)
-
-- **Phase 3 설계 원칙 = 불변** (Phase 3 종결 문서 §5)
-- **Phase 4 실 구성 = 본 Phase 산출물**
-- 두 층위 혼동 금지 · 설계 원칙 자체 변경은 PD 결정 영역
-
-### §7-2. 역방향 피드백 허용 범위
-
-Phase 4 진행 중 **설계 원칙 개선 인사이트** 발견 시:
-- **즉시 중단 금지** — Phase 4 본 청크 완료 우선
-- **발견 사항 기록**: `memory/org/feedback_*.md` or `공유/대화로그/수상한잡화점/YYYY-MM-DD.md`
-- **청크 완결 후 PM 보고** → PD 결정 수령 후 Phase 3 종결 문서 §5 개정 여부 판단
-
-### §7-3. 임시 데이터 vs 확정 데이터 전환
-
-Phase 4가 진행됨에 따라:
-- 청크별 스테이지 노드 구성 확정 → 임시 데이터 점진 대체
-- 청크 완결 시점마다 "해당 Chapter 임시 데이터 → 확정 데이터 전환" 선언
-- Phase 4 종결 시 **임시 데이터 전면 확정** 선언
-
-### §7-4. 이슈 1·3 전제 불변
-
-- 카드 수치 유지 · 신성 빌드 캐주얼 포지션 유지
-- Phase 4 진행 중 "이참에 이슈 1·3도" 제안 금지 (이슈1_3_무시확정_v1 §5-3 금지 패턴)
-- 재논의 트리거 §5-1 3종 발동 시만 PM 경유 PD 상신
-
-### §7-5. P30 재미 근거 계승
-
-- Phase 3 §11 재미 근거 = "설계 체계 기반 재도전 유도 일관성 + 차기 프로젝트 자산 계승"
-- Phase 4 각 스테이지 배치 = **재미 축을 개별 정의** (P30 "재미 정의 없는 수치 조정 금지")
-
----
-
-## §8. 기각안 (P24 · C32 필수)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 본 가이드에서 Phase 4 각 스테이지 배치 확정까지 직접 수행 | C36 PM·팀장 재량 상한 · 본 문서는 **착수 가이드** 수준. 실 배치는 Phase 4 본작업 · PD 결정 영역 |
-| 2 | Day 단위 로드맵을 "시간 단위 일정"으로 구체화 | C9-2 일정·기한 표현 금지 위반 · Day는 청크 단위 · "N일 내 완료" 류 금지 |
-| 3 | Phase 3 설계 원칙을 본 가이드에서 재수정 | Phase 3 §5 설계 체계는 SOT · 본 문서는 참조·활용만. 재수정은 C36 방향·원칙 수준 PD 결정 |
-| 4 | 청크 분할을 PD 승인 없이 기획팀장 재량 확정 | 청크 분할 자체는 PM·팀장 재량 수용 가능 · 단 "착수 청크 결정" Day 1-5 단계에서 PM 협의 명시 |
-| 5 | Phase 4 범위에 조건 풀 13번째 신규 추가 검토 포함 | PD 3차 승인 조건 풀 12개 범위 내 배치만 허용 · 신규 추가는 PD 재승인 필수 |
-| 6 | Unity MCP 시뮬 없이 TTK 산출치만으로 배치 확정 | 고주의 5종 임계 초과 시 시뮬 선행 의무 · 실측 데이터 없이 추정만으로 배치 시 C23 정직성 위반 |
-| 7 | 이슈 1·3 재논의를 Phase 4 진행 중 자동 트리거 | 이슈1_3_무시확정 §5-1 3종 트리거 외 금지 · 자동 재논의 설정은 PD 결정 우회 |
-| 8 | PD B 방식을 완화하여 "위반 감지 시 경고만" 운영 | PD 2026-04-20 확정 "위반 즉시 중단" · 완화는 C36 방향 수준 PM 재량 위반 |
-| 9 | 재미 근거(P30) 명시를 "권장"으로 완화 | P30 "재미 정의 없는 수치 조정 금지" 의무 사항 · 완화 금지 |
-| 10 | Phase 4 종결 선언을 기획팀장 단독 재량으로 집행 | C36 방향·원칙 수준 PD 결정 영역 · Day 종결 단계 §6-4 "Phase 4 종결 선언 + PD 결정 수령" 명시 |
-| 11 | 레벨·밸런스·콘텐츠 에이전트 순차 호출만 운영 | Phase 3 병렬 호출 체계 승계 원칙 · 독립 작업은 병렬 · §5-3 |
-| 12 | Chapter 4~6 범위를 본 가이드에서 구체 Stage 번호로 확정 | 125 스테이지 전체 목록은 Phase 4 Day 1-1 전수 확인 단계에서 확정 · 본 가이드는 "착수 가이드" 수준 |
-
----
-
-## §9. 변경 이력 (P16)
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (PM 경유 PD B안 수용 집행) | 착수 가이드 v1 작성 · Phase 4 범위 "스테이지별 노드 구성" 확정 · 입력 자료 6종 · 작업 흐름 5단계 · 판정 기준 4종 · 담당 체계 · Day 단위 로드맵 초안 · Phase 3·4 연계 원칙 · 기각안 12종 |
-
----
-
-## §10. 재미 근거 (P30 기획팀 전용)
-
-**강화하려는 재미 축**: "스테이지별 차별화 + 재도전 유도 실감 + 고난도 극복 성취"
-
-- **스테이지별 차별화**: 125 스테이지 각각이 "다른 공략법·다른 배치"로 체감되도록 § 3 5단계 흐름을 전 스테이지 적용. 기계적 반복이 아닌 "이 스테이지만의 특색" 확보.
-- **재도전 유도 실감**: Phase 3 §5-1 C9 배치 원칙·§5-4 AppearGroup 가이드·§5-5 고주의 판정이 전 스테이지에 일관 적용되어, 플레이어가 "어느 스테이지든 공정한 재도전 조건" 경험.
-- **고난도 극복 성취**: §5-5 고주의 5종 임계 체크 + Unity MCP 시뮬 선행으로, 후반 스테이지에서 "극단 난이도지만 성장 5축 결합으로 극복 가능" 경험 설계.
-- **설계 체계 승계의 재미 안정성**: Phase 3 종결 문서 §5 원칙 준수로 "Phase 4에서 설계 체계가 갑자기 바뀌지 않는" 안정성 보장 → 플레이어 학습 곡선 존중.
-- **P30 재미 근거 명시 의무 계승**: 각 스테이지 배치 확정 전 재미 축 명시 의무로, "수치만 맞추는 밸런싱"이 아닌 "재미 중심 배치" 보장.
-
----
-
-## §11. 관련 규칙·참조
-
-- **헌법 제1원칙 ①·②** (AI 전문 개발 스튜디오 · 경험 축적 계승) — Phase 3 체계 계승
-- **C6-1** 원본 파일 보호 — Phase 3 산출물 그대로 보존 + 본 Phase 신규 산출물 별도 관리
-- **C9-2** 일정·기한 표현 금지 — Day 단위는 청크 단위 · 시간 계획 아님
-- **C22** 용어 일관 — "Phase 4·Day 1~N·청크" PD/팀장 도입 용어 유지
-- **C23** 정직성 — 실측 데이터 근거 · 추정 시 명시 태그
-- **C25** 넘버링 일관 — §1~§11 고정 위계
-- **C36** PM·팀장 재량 상한 — 본 가이드는 착수 가이드 수준 · 실 배치·방향 확정은 PD 결정
-- **C37** 규칙 문서 관리 — 섹션 구조·표기법 통일
-- **P16** 산출물 추적성
-- **P17** ★ 조건 배타 배치 규칙 — §2-5 SOT
-- **P18** 설계 문서화 의무 — 본 가이드 + Phase 4 산출물 문서화
-- **P24·C32** 기각안 필수 — §8
-- **P29** 코어 프레임워크 조직 자산 계승 — Phase 3 체계 승계
-- **P30** 재미 우선 원칙 — §10 + §4-4 재미 판정 기준
-
----
-
-*Phase 4 착수 가이드 v1 완료: 2026-04-20*
-*Phase 4 Day 1 착수 준비 완료 — PD 착수 승인 수령 시 즉시 Day 1-1 (125 스테이지 목록 전수 확인) 착수 가능*
diff --git a/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md b/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md
deleted file mode 100644
index d875d35..0000000
--- a/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md
+++ /dev/null
@@ -1,818 +0,0 @@
----
-type: Phase 4 지역별 노드 구성 (지역 1 · Stage 1~6) — **🔴 아카이브됨**
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD B안 확정 수용 집행)
-관련PD지시: 기획팀 #41 · PD 2026-04-20 "B가 맞는 해석이고 우선 해석한 B대로 진행 후 보고해"
-상태: **🔴 아카이브됨 — 데이터 구조 오해로 폐기 · 대체: Phase4_지역1_노드구성_v2.md**
-선행문서:
-  - 프로젝트/수상한잡화점/기획/Phase3_종결_설계체계_v1.md (Phase 3 종결 + 설계 체계 SOT)
-  - 프로젝트/수상한잡화점/기획/Phase4_노드구성_착수가이드_v1.md (§6-2 청크 1 = Stage 1~6)
-  - 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md §2·§3·§4·§5 (스테이지 구조·보스·몬스터 실측 SOT)
-  - 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 PD 3차 승인)
-  - 프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md §2-1 (입문 구간 허용 후보 매트릭스)
-  - 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md §3 (카드 수치 고정 전제)
-  - SKILL.md P17 (배타 7종 SOT)
----
-
-# 🔴 아카이브됨 — 대체: Phase4_지역1_노드구성_v2.md
-
-> **폐기 사유**: 본 v1은 "지역 1 = WorldMap_1 = Stage 1~6 (6개)" 전제로 작성되었으나, **2026-04-20 PD 실측 확정**에 따라 데이터 구조가 다음과 같이 판명됨:
-> - 월드맵 = 21개 구역 (각 구역 = `n_StageID` 1~21)
-> - **지역 1 = Stage1_1·1_2·1_3·1_4 = 4개 하위 스테이지**
-> - 기존 "WorldMap 4그룹" 해석은 실측 없는 추정
->
-> 본 v1의 Stage 1~6 설계는 **실제 지역 1~2의 일부**에 해당하는 혼재된 스테이지 설계였으며, PD 확정 구조와 맞지 않음.
->
-> **활성 대체 문서**: `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md` (지역 1 = 4개 스테이지 기준)
-> **재정비 근거**: `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` (PD #42 산출물)
-> **재발 방지 룰**: `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` (PD #43 산출물)
->
-> 본 v1 본문은 역사 보존 목적으로 유지 (C14-5 "아카이브된 문서 자체" 예외).
-
----
-
-# Phase 4 지역 1 노드 구성 v1 — Stage 1~6 (WorldMap_1 / 입문 구간)
-
-## §0. 지역 1 범위 확정 (PD B안 수용)
-
-### §0-1. PD 결정 원문
-
-> "B가 맞는 해석이고 우선 해석한 B대로 진행 후 보고해." — PD님 직접 지시 (2026-04-20)
-
-### §0-2. 지역 1 외연 (실측 근거)
-
-- **지역 1 = WorldMap_1 = Stage 1~6** (6개 스테이지)
-- 근거: `스테이지난이도곡선_v1.md §1` 실측 WorldMap 구성 (WM1 = Stage 1~6, WM2 = Stage 7~10, WM3 = Stage 11~15, WM4 = Stage 16~21)
-- Phase 4 착수 가이드 §6-2 **청크 1 = Stage 1~6** 과 완전 일치
-- 구조 외연 혼선 해소 — 21 스테이지 전수 기준 (구 "125 스테이지" 표현은 재검증보고_맵패턴_v1 사전자료의 가정치이며 현 실측과 불일치 · Phase 4 가이드 §1-1은 본 집행 기준으로 21 스테이지 실측 채택)
-
-### §0-3. 본 지역 집행 범위
-
-- Stage 1·2·3·4·5·6 각각의 노드 구성 확정 초안
-- 고정 몬스터 + 매 판 랜덤 몬스터 풀 정의 (PD 고려사항 1·2·4 대응)
-- 3★ 클리어 조건(슬롯2·슬롯3) 배치 확정 (PD 고려사항 3 대응)
-- P17 배타 7종 전수 체크 (12 슬롯)
-- 5축 결합 DPS 기반 TTK 검증
-- 반복 방지 다양성 지표 정량 산출
-- 입문 구간 학습 곡선 테스트 결과 예상
-
-### §0-4. 본 집행에서 하지 않는 것 (명시적 금지)
-
-- **지역 2 이후 착수 금지** — PD 승인 후 순차 (PD 원문 "지역 1 완료 → 승인 후 지역 2")
-- **설계 원칙 재수정 금지** — Phase 3 §5 설계 체계 준수 (C36 방향·원칙 수준 불변)
-- **이슈 1·3 수치 재논의 금지** — 이슈1_3_무시확정_v1 §5-1 트리거 3종 외 금지
-- **조건 풀 12개 신규 추가 금지** — PD 3차 승인 범위 내만
-
----
-
-## §1. 지역 1 개요 · 목표 난이도 · 재미 포지션
-
-### §1-1. WorldMap_1 포지션
-
-| 항목 | 값 | 근거 |
-|------|-----|------|
-| 스테이지 범위 | Stage 1~6 | WM1 실측 |
-| 구간 분류 | **입문** | 스테이지난이도곡선_v1 §9 "입문 1~2 · 초반 3~4 · 중반 시작 5~6" |
-| 전체 서브맵 수 합 | 35 (4+6+5+7+6+7) | 스테이지난이도곡선_v1 §2 |
-| 전체 보스 수 합 | 14 (2+3+2+3+2+2) | 스테이지난이도곡선_v1 §2 |
-| 주 등장 종족 | 수인형·마법생물·인간형 초기 | §5 실측 테이블 |
-| 보스 HP 평균 | 25→61→56→86→62→100 | §4 실측 |
-| 보스 HP+Shield 합 | 44→74→125→128→233→174 | §4 실측 (Stage 5 다크엘프아처1 Shield 282 특이) |
-
-### §1-2. 지역 1 통합 목표 난이도
-
-**재도전 유도 원칙 우선 · 입문 구간 학습 곡선 존중**
-
-| 스테이지 | ★1 클리어 기대 | ★2 (슬롯2 1개) | ★3 (슬롯2+슬롯3) |
-|---------|---------------|---------------|---------------|
-| 1 | 95% 이상 | 60% (1회 플레이) → 85% (2~3회 플레이) | 35% (2~3회) → 65% (4~5회) |
-| 2 | 90% | 55% → 80% | 30% → 60% |
-| 3 | 85% | 50% → 75% | 25% → 55% |
-| 4 | 80% | 45% → 70% | 20% → 50% |
-| 5 | 75% | 40% → 65% | 15% → 45% |
-| 6 | 70% | 35% → 60% | 12% → 40% |
-
-**해석**: Stage 1~2 ★3은 재도전 중심 · Stage 5~6 ★3은 성장 5축 일부 결합 필요 수준.
-
-### §1-3. 지역 1 재미 포지션 (P30)
-
-**강화하려는 재미 축 3종**:
-
-1. **학습 곡선의 부드러움** — Stage 1·2에서는 전투 기초·몬스터 약점 이해 중심 · Stage 3~4에서 ★ 조건 인식 시작 · Stage 5~6에서 빌드 방향성 선택 유도
-2. **고정+랜덤 이원 재미** — 매 스테이지 "반드시 마주칠 보스" + "매 판 바뀌는 일반 몬스터 조합" 공존으로 "예측 가능한 핵심" + "매번 다른 디테일" 공존
-3. **★ 조건 차별화 체험** — 12개 조건 풀에서 Stage마다 다른 축(시간/HP/포션/회피/빗맞힘/피격/쉴드/타겟팅) 적용 → 지역 1 완주 시 "조건 메타" 체험 완료
-
-**재미 정의 없는 수치 조정 금지 (P30-1)** — §3 각 스테이지 노드 구성 확정 시 재미 축 명시
-
-### §1-4. 플레이어 예상 상태 (TTK 산출용 가정)
-
-| 스테이지 | Lv. | 각성 | 진화 | 장비 | 인장 | 카드 |
-|---------|-----|------|------|------|------|------|
-| 1 | 1 | 미습득 | 미습득 | 기본 | 미습득 | 0~1장 |
-| 2 | 2 | 미습득 | 미습득 | 기본~일반셋 | 미습득 | 1~2장 |
-| 3 | 3 | 1단계 | 미습득 | 일반셋 | 미습득 | 2장 |
-| 4 | 4 | 1단계 | 미습득 | 일반셋 | 1★ | 2~3장 |
-| 5 | 5 | 2단계 | 1★ | 일반셋 | 2★ | 3장 |
-| 6 | 6 | 2단계 | 2★ | 세트 일부 | 3★ | 3~4장 |
-
-**DPS 산출 기본값**: Day 4~7 Unity MCP UTF 실측 ratio 사용 (각성 +50%·진화 +40%·일반셋 +30.46%·세트 +71.46%·인장 +22.41%). 기본 DPS = 1.05 (Phase 0 앵커 PC 6001 Lv.1).
-
----
-
-## §2. P17 배타 7종 지역 1 사전 허용 후보 (42슬롯 현황 §2-1 인용)
-
-Stage 1~6 **입문 구간 공통 제약**:
-
-| 제약 | 적용 | 근거 |
-|------|-----|------|
-| P17-4 (C1 ∧ C3) | **입문 동시 배치 금지** | 이중 부담 과도 |
-| P17-5 (C9 ∧ 단독 보스·미등장) | **C9 △ 비권장 (Stage 1~3)/Stage 4~6 가능하되 검증 필수** | 보스 미등장 서브맵 비율 현 시점 미확정 · 입문 구간 C9 보류 |
-| P17-6 (N3 입문 단독 금지) | **배치 금지** | 치명타 빌드 미형성 |
-| P17-1 (C2 ∧ N2) | **슬롯2·3 동시 배치 금지** | 피격 이중 부담 |
-| P17-3 (C6 ∧ N4) | **동시 배치 금지** | 빌드 배제 |
-| P17-7 (N5 ∧ N6) | **동시 배치 금지** | 타겟팅 모순 |
-| P17-2 (C6 ∧ 물약 유도) | 비활성 | 조건 풀에 물약 유도 조건 부재 |
-
-**지역 1 허용 후보 풀 (입문 공통)**: C1 · C3 · C6 · C12 · N1 · N2 · N4 · N5 · N6 (9종)
-- 제외: C2(입문 과도) · C9(Stage 1~3 배치 금지·4~6 보류) · N3(입문 금지)
-
----
-
-## §3. Stage 1~6 노드 구성 확정 초안
-
-각 스테이지 구조:
-- §N-1. 목표 정의 (재미 포지션)
-- §N-2. 보스 구성 (고정 몬스터 SOT · 스테이지난이도곡선_v1 §3·§5 실측)
-- §N-3. 노드별 전투 구성 (서브맵별 고정+랜덤)
-- §N-4. ★ 조건 배치 (슬롯2·슬롯3)
-- §N-5. P17 체크 시트
-- §N-6. TTK 검증
-- §N-7. 반복 방지 다양성 지표
-
----
-
-### §3-1. Stage 1 — "놀 부족의 첫 만남"
-
-#### §3-1-1. 목표 정의
-
-- **위치**: WM1 · 입문 진입 (최최초)
-- **목표 난이도**: ★1 95% · ★2 60%→85% · ★3 35%→65%
-- **재미 포지션**: "기본 전투 메커닉 이해 + 첫 보스 조우의 임팩트"
-- **플레이어 예상**: Lv.1 · 카드 0~1장 · 장비 기본
-- **특이 주의**: 첫 스테이지 · 피격 빈도 학습 단계 · 튜토리얼 직후 가정
-
-#### §3-1-2. 보스 구성 (고정 · SOT 근거)
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | EXP | 등장 위치 |
-|--------|-------|-----|--------|---------|-----|----------|
-| 10001 | 놀아처1 | 20 | 15 | 5.0 | 10 | 서브맵 2 (선행 보스) |
-| 10002 | 놀강도2 | 30 | 22 | 7.0 | 15 | 서브맵 4 (최종 보스) |
-
-- 서브맵 수: 4 · 보스 수: 2 · AppearGroup 범위: 10101~10104
-
-#### §3-1-3. 노드별 전투 구성
-
-> **고정 몬스터**: 보스·특정 서브맵 고정 배치 / **랜덤 풀**: 매 판 확률적 등장
-
-| 서브맵 | 고정 몬스터 | 랜덤 풀 (매 판 가변) | 선택 규칙 |
-|--------|------------|--------------------|---------|
-| 1 | 없음 (일반전) | 수인형低 3종 (놀A·놀B·놀C) + 마법생물低 2종 (슬라임·쥐) | 5종 풀에서 랜덤 2~3마리 구성 · 중복 허용 |
-| 2 | **놀아처1 (보스)** | 수인형低 2종 혼용 (놀A·놀B) | 보스 + 랜덤 1~2 수행 |
-| 3 | 없음 (일반전) | 수인형低 3종 + 마법생물低 2종 | 5종 풀에서 랜덤 2~3마리 · 서브맵 1과 다른 조합 선호 |
-| 4 | **놀강도2 (최종보스)** | 수인형低 2종 (놀C·놀D) | 보스 + 랜덤 1~2 수행 |
-
-**근접/원거리 특성 매칭** (content 관점):
-- 놀아처1 = **원거리** (아처) · 놀강도2 = **근접** (강도) → Stage 1 한 판에 "원거리 대응 + 근접 대응" 양쪽 체험
-- 일반 수인형 = 근접 중심 (놀A·B·C·D) · 슬라임·쥐 = 근접 약체
-
-**반복 방지**:
-- 서브맵 1 ↔ 서브맵 3 일반전 풀은 동일 5종이나 **매 판 랜덤 선택으로 동일 조합 확률 1/25 이하 (5종 중 2마리 조합 25가지)**
-- 매 판 재플레이 시 "일반 몬스터 등장 패턴"은 반드시 달라짐
-
-#### §3-1-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 판정 기준 | 배치 근거 (P30 재미 축) |
-|------|-----|---------|---------------------|
-| 슬롯2 | **N1 빗맞힘 절제** (빗맞힘 ≤ 임계) | 4 서브맵 누적 빗맞힘 횟수 | 첫 스테이지 · "공격을 맞추는 기본 감각" 체험. 4 서브맵 합산이므로 입문 난이도 저 |
-| 슬롯3 | **N5 후열 선공** (서브맵마다 최초 공격 = 후열) | 4 서브맵 전 서브맵 체크 | 타겟팅 전략 인식. N1과 상호 독립 축 (정확도 vs 순서) |
-
-**배치 사유**: 
-- Stage 1 = "전투 기초 인식 스테이지" → N1(정확도) + N5(타겟 순서) 결합이 전투 기초 2축 학습
-- P17 모든 배타 회피 (C1·C3 미배치 · N3 미배치 · C9 미배치 · N5·N6 동시 미배치)
-
-#### §3-1-5. P17 체크 시트
-
-```
-[Stage 1] 슬롯 배치 검증 시트
-  슬롯 2: N1 빗맞힘 절제
-  슬롯 3: N5 후열 선공
-
-  #1 C2∧N2:           [O] 미해당
-  #2 C6∧물약유도:      [O] 미해당 (조건 풀에 미존재)
-  #3 C6∧N4:           [O] 미해당
-  #4 (1~6)C1∧C3:      [O] 미해당
-  #5 C9∧단독보스:      [O] 미해당 (보스 2체)
-  #6 (1~6)N3:         [O] 미해당
-  #7 N5∧N6:           [O] 미해당 (N5만 배치)
-
-  [최종 판정] [O] 통과
-```
-
-#### §3-1-6. TTK 검증
-
-**플레이어 가정 (Lv.1 · 카드 0~1장 · 장비 기본)**:
-- DPS = 1.05 × 1.0 (카드 미습득~G5 1장 ≈ +5%) × 1.0 (세트 미보유) × 1.0 (각성 미) × 1.0 (진화 미) × 1.0 (인장 미) = **1.05 (카드 미습득) ~ 1.10 (G5 1장)**
-
-**서브맵별 TTK**:
-| 서브맵 | 대상 내구도 추정 | TTK 추정 |
-|--------|---------------|---------|
-| 1 (일반) | 일반 몬스터 2~3 × HP 2~5 = 4~15 | 4~15s |
-| 2 (보스) | 놀아처1 HP20 + Shield15 = 35 + 일반 2 = ~45 | 40~50s |
-| 3 (일반) | 일반 몬스터 2~3 × HP 2~5 = 4~15 | 4~15s |
-| 4 (최종보스) | 놀강도2 HP30 + Shield22 = 52 + 일반 2 = ~62 | 55~65s |
-| **전체** | - | **100~145s** |
-
-**목표 난이도 정합**: ★1 95% 달성 가능 (피격 감수 시 120~180s) · N1(빗맞힘 절제) ★2는 2~3회 재플레이 학습 · N5(후열 선공) ★3은 4~5회 재플레이 학습
-
-#### §3-1-7. 반복 방지 다양성 지표 (정량)
-
-| 축 | 다양성 경우의 수 |
-|----|---------------|
-| 서브맵 1 몬스터 조합 | 5종 중 2마리 중복 허용 = 15가지 (5C2 + 5 단일 중복) |
-| 서브맵 3 몬스터 조합 | 15가지 |
-| 고정 보스 등장 위치 | 서브맵 2·4 고정 (의도된 고정) |
-| 랜덤 몬스터 선택 확률 | 서브맵당 2~3마리 랜덤 → 1·3 서브맵 조합 = 15×15 = **225가지 × 3/4 = 168가지 독립 조합** |
-
-**해석**: 매 판 최소 15가지 이상 서로 다른 일반 몬스터 조합 가능 · 플레이어가 "동일 조합 2회 연속" 체험 확률 ≈ 6.7%
-
----
-
-### §3-2. Stage 2 — "놀 정예와 오우거의 공포"
-
-#### §3-2-1. 목표 정의
-
-- **위치**: WM1 · 입문 심화 진입
-- **목표 난이도**: ★1 90% · ★2 55%→80% · ★3 30%→60%
-- **재미 포지션**: "몬스터 조합 다양화 + 중형 보스(오우거1) 첫 임팩트"
-- **플레이어 예상**: Lv.2 · 카드 1~2장
-- **특이 주의**: **오우거1 HP 112 · ATKMax 30** (Stage 1 놀강도2 HP 30 대비 3.7배) — 스테이지난이도곡선_v1 §8-5 이상값 실증. Stage 2 마지막 서브맵이 체감 최난도
-
-#### §3-2-2. 보스 구성
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | EXP | 등장 위치 |
-|--------|-------|-----|--------|---------|-----|----------|
-| 10002 | 놀강도2 | 30 | 22 | 7.0 | 15 | 서브맵 2 (보스 재등장 · Stage 1 계승) |
-| 10003 | 임프전사1 | 42 | 16 | 7.5 | 21 | 서브맵 4 |
-| 10004 | **오우거1** | 112 | 0 | 18.5 | 56 | 서브맵 6 (**최종 · 이상값**) |
-
-- 서브맵 수: 6 · 보스 수: 3 · AppearGroup: 10201~10206
-
-#### §3-2-3. 노드별 전투 구성
-
-| 서브맵 | 고정 | 랜덤 풀 | 선택 규칙 |
-|--------|-----|--------|---------|
-| 1 | 없음 | 수인형低 3종 + 마법생물低 3종 (슬라임·쥐·박쥐) | 6종 중 2~3마리 |
-| 2 | **놀강도2** | 수인형低 2종 혼용 | 보스 + 랜덤 1~2 |
-| 3 | 없음 | 인간형 초기 2종 (오크A·오크B) + 수인형 중 2종 | 4종 중 2~3마리 |
-| 4 | **임프전사1** | 인간형 초기 1종 + 수인형 1종 혼용 | 보스 + 랜덤 1~2 |
-| 5 | 없음 | 인간형 초기 3종 + 수인형 中 2종 | 5종 중 2~3마리 (난이도 ±) |
-| 6 | **오우거1 (최종)** | 없음 (보스 단독 최종) | 보스 단독 전투 · 긴장감 극대화 |
-
-**근접/원거리 매칭**:
-- 놀강도2 = 근접 · 임프전사1 = 근접 · 오우거1 = **근접 고ATK** (Max 30 = 원거리 맞먹는 임팩트)
-- 오크 = 근접 · 슬라임/쥐 = 근접 약체 · 박쥐 = **원거리** (근거리 이동 + 원거리 공격)
-
-#### §3-2-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 배치 근거 |
-|------|-----|----------|
-| 슬롯2 | **C3 고 HP 완주** (HP ≥ MaxHP × 70%) | 오우거1 이상값 대비 생존 유지 재도전 유도. C1과 P17-4 배타 회피 |
-| 슬롯3 | **N4 쉴드 보존** (Shield ≥ MaxShield × 30%) | 다음 스테이지(3) Shield 보스(바포메트6) 대비 쉴드 관리 학습 |
-
-**배치 사유**: 
-- 오우거1 이상값 특성상 "HP 유지 + Shield 관리" 이중 리소스 관리 학습
-- C3·N4 조합은 **빌드 의존 약** (힐 빌드·쉴드 빌드 모두 가능)
-- P17-3 (C6 ∧ N4) 회피 · P17-1 (C2 ∧ N2) 회피 · P17-7 (N5 ∧ N6) 회피
-
-#### §3-2-5. P17 체크 시트
-
-```
-[Stage 2] 슬롯 2: C3 · 슬롯 3: N4
-  #1 C2∧N2:      [O] 미해당
-  #2 C6∧물약유도: [O] 미해당
-  #3 C6∧N4:      [O] 미해당 (C6 미배치)
-  #4 C1∧C3:      [O] 미해당 (C1 미배치)
-  #5 C9∧단독보스: [O] 미해당 (C9 미배치)
-  #6 N3:         [O] 미해당
-  #7 N5∧N6:      [O] 미해당
-  [최종 판정] [O] 통과
-```
-
-#### §3-2-6. TTK 검증
-
-**Lv.2 · 카드 1~2장 가정 · DPS ≈ 1.10 ~ 1.20**
-
-| 서브맵 | 대상 내구도 | TTK |
-|--------|-----------|-----|
-| 1 (일반) | 일반 2~3 × HP 2~6 ≈ 6~18 | 5~15s |
-| 2 (놀강도2+일반) | 보스 52 + 일반 ~10 = ~62 | 50~60s |
-| 3 (일반) | 일반 2~3 × HP 4~10 ≈ 10~25 | 8~20s |
-| 4 (임프전사1+일반) | 보스 58 + 일반 ~10 = ~68 | 55~65s |
-| 5 (일반) | 일반 2~3 × HP 4~10 ≈ 10~25 | 8~20s |
-| 6 (**오우거1 단독**) | 보스 112 (Shield 0) | **85~110s** (ATK Max 30 대응) |
-| **전체** | - | **160~290s** |
-
-**목표 난이도 정합**: 오우거1 구간이 체감 최난도 · C3(HP≥70%) 조건이 오우거1 구간에서 자연스럽게 재도전 유도
-
-#### §3-2-7. 반복 방지 다양성 지표
-
-- 일반 서브맵 3개(1·3·5) × 각 5~6종 풀 × 2~3마리 조합 ≈ **서브맵당 평균 20가지 × 3 서브맵 독립 = 8,000가지 이상 조합**
-- 고정 서브맵 4개(2·4·6) 중 서브맵 2·4는 랜덤 혼용 1~2마리로 보조 다양성 확보 (각 ~5가지)
-- 매 판 동일 조합 확률 < 0.1%
-
----
-
-### §3-3. Stage 3 — "바포메트와 거미여왕의 쉴드 장벽"
-
-#### §3-3-1. 목표 정의
-
-- **위치**: WM1 · 초반 전환
-- **목표 난이도**: ★1 85% · ★2 50%→75% · ★3 25%→55%
-- **재미 포지션**: "Shield 공격력 중요성 체감 (바포메트6 Shield 66 · 거미여왕2 Shield 72)"
-- **플레이어 예상**: Lv.3 · 각성 1단계 · 카드 2장 · 일반셋 장비
-- **특이**: 첫 "**Shield 장벽**" 스테이지 · HP만 봐선 쉬워 보여도 내구도 124.5 (Stage 2 대비 +68%)
-
-#### §3-3-2. 보스 구성
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | 등장 |
-|--------|-------|-----|--------|---------|------|
-| 10005 | 바포메트6 | 53 | 66 | 9.0 | 서브맵 3 |
-| 10006 | 거미여왕2 | 58 | 72 | 8.5 | 서브맵 5 (최종) |
-
-- 서브맵 5 · 보스 2 · AppearGroup 20301~20305
-
-#### §3-3-3. 노드별 전투 구성
-
-| 서브맵 | 고정 | 랜덤 풀 | 규칙 |
-|--------|-----|--------|------|
-| 1 | 없음 | 인간형 초기 3종 (오크A·오크B·고블린) + 수인형 中 2종 | 5종 중 2~3 |
-| 2 | 없음 | 인간형 초기 3종 + 마법생물 초기 2종 (슬라임·박쥐) | 5종 중 2~3 (1과 다른 조합 유도) |
-| 3 | **바포메트6** | 인간형 초기 1종 + 마법생물 1종 | 보스 + 랜덤 1~2 |
-| 4 | 없음 | 인간형 초기 4종 + 수인형 中 2종 | 6종 중 2~3 |
-| 5 | **거미여왕2 (최종)** | 인간형 초기 1종 혼용 (오크 정예) | 보스 + 랜덤 1 |
-
-**근접/원거리 매칭**:
-- 바포메트6 = **원거리** (마법) · 거미여왕2 = **근접** (거미 스윕) → "마법 쉴드 vs 근접 쉴드" 양축 체험
-- 오크·고블린 = 근접 · 박쥐 = 원거리
-
-#### §3-3-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 배치 근거 |
-|------|-----|----------|
-| 슬롯2 | **C6 포션 절제** (포션 사용 ≤ 임계) | 입문 중반 · 자원 관리 인식 시작. 회복 빌드 배제 효과 (P17-3) |
-| 슬롯3 | **N2 피격 제한** (피격 ≤ 서브맵수×1 = 5회 이하) | Shield 장벽 상대로 "피격 없이 깨기" 재도전 유도 |
-
-**배치 사유**:
-- Shield 장벽 스테이지 → 회복/포션 절제 + 피격 관리 2축
-- P17-1 (C2 ∧ N2) 회피 (C2 미배치 · N2만) · P17-3 (C6 ∧ N4) 회피 (N4 미배치 · C6만)
-
-#### §3-3-5. P17 체크 시트
-
-```
-[Stage 3] 슬롯 2: C6 · 슬롯 3: N2
-  #1 C2∧N2:      [O] 미해당 (C2 미배치)
-  #3 C6∧N4:      [O] 미해당 (N4 미배치)
-  #4 C1∧C3:      [O] 미해당
-  #5 C9∧단독보스: [O] 미해당
-  #6 N3:         [O] 미해당
-  #7 N5∧N6:      [O] 미해당
-  [최종 판정] [O] 통과
-```
-
-#### §3-3-6. TTK 검증
-
-**Lv.3 · 각성 1 · 카드 2장 · 일반셋 · DPS ≈ 1.05 × 1.15 × 1.3 × 1.2 = 1.88**
-
-| 서브맵 | 내구도 | TTK |
-|--------|-------|-----|
-| 1·2·4 (일반) | 각 일반 2~3 × HP 4~10 ≈ 10~25 | 각 5~13s |
-| 3 (바포메트6+일반) | 보스 119 + 일반 ~15 = ~134 | 70~85s |
-| 5 (거미여왕2+일반) | 보스 130 + 일반 ~8 = ~138 | 72~88s |
-| **전체** | - | **170~230s** |
-
-#### §3-3-7. 반복 방지 다양성 지표
-
-- 일반 서브맵 3개(1·2·4) × 5~6종 × 2~3마리 = **서브맵당 ~20가지 × 3 = 8,000가지 이상 조합**
-- Shield 장벽 체감 특성상 "일반전 통과 루트" 선택이 유사해도 **몬스터 조합 자체는 매번 다름**
-
----
-
-### §3-4. Stage 4 — "거미여왕·흑기사·늑대인간의 3보스 첫 경험"
-
-#### §3-4-1. 목표 정의
-
-- **위치**: WM1 · 초반 후반 · 7서브맵 첫 등장
-- **목표 난이도**: ★1 80% · ★2 45%→70% · ★3 20%→50%
-- **재미 포지션**: "3체 보스 다중 교전 + 스테이지 길이 확장 학습"
-- **플레이어 예상**: Lv.4 · 각성 1 · 카드 2~3장 · 일반셋 · 인장 1★
-- **특이**: 서브맵 7 (지역 1 최대) · 보스 3체 · **거미여왕2 재등장** (Stage 3 계승)
-
-#### §3-4-2. 보스 구성
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | 등장 |
-|--------|-------|-----|--------|---------|------|
-| 10006 | 거미여왕2 (재등장) | 58 | 72 | 8.5 | 서브맵 2 |
-| 10007 | 흑기사2 | 66 | 52 | 11.5 | 서브맵 5 |
-| 10008 | 늑대인간 | 85 | 0 | 8.0 | 서브맵 7 (최종) |
-
-#### §3-4-3. 노드별 전투 구성
-
-| 서브맵 | 고정 | 랜덤 풀 | 규칙 |
-|--------|-----|--------|------|
-| 1 | 없음 | 인간형 초기 4종 + 수인형 中 2종 | 6종 중 2~3 |
-| 2 | **거미여왕2** | 인간형 초기 2종 | 보스 + 랜덤 1~2 |
-| 3 | 없음 | 인간형 초기 3종 + 마법생물 中 1종 | 4종 중 2~3 |
-| 4 | 없음 | 인간형 초기 4종 + 수인형 中 2종 (다른 구성) | 6종 중 2~3 (1과 다른 조합 유도) |
-| 5 | **흑기사2** | 인간형 초기 1종 + 마법생물 1종 | 보스 + 랜덤 1~2 |
-| 6 | 없음 | 인간형 초기 3종 + 마법생물 中 2종 | 5종 중 2~3 |
-| 7 | **늑대인간 (최종)** | 수인형 中 1종 혼용 | 보스 + 랜덤 1 |
-
-**근접/원거리**:
-- 거미여왕2 = 근접 · 흑기사2 = **근접 중장갑** (Shield 52) · 늑대인간 = 근접 고HP · 혼용 마법생물 = 원거리
-
-**반복 방지 특수 처치**:
-- 서브맵 1·4 "인간형 초기 4종 풀"이 겹치나 **한 서브맵에서 뽑힌 조합 2가지는 다른 서브맵 풀에서 제외** (프로그래밍 가능한 AppearGroup 다양화 규칙 제안)
-- 거미여왕2 혼용 2종 vs Stage 3의 서브맵 5 혼용 1종으로 **"재등장이지만 다른 구성" 체험**
-
-#### §3-4-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 배치 근거 |
-|------|-----|----------|
-| 슬롯2 | **C1 신속** (총 소요 시간 ≤ 임계) | 서브맵 7 길어진 스테이지 · 시간 관리 학습. C3 배치 시 P17-4 위반이므로 C3 배제 |
-| 슬롯3 | **N5 후열 선공** (서브맵마다 최초 = 후열) | 7 서브맵 전체 체크 · 다중 보스 대응 타겟팅 학습 |
-
-**배치 사유**:
-- 긴 스테이지 → 시간 관리 + 타겟팅 전략
-- P17-4 (C1 ∧ C3) 회피 (C3 미배치) · P17-7 (N5 ∧ N6) 회피
-
-#### §3-4-5. P17 체크 시트
-
-```
-[Stage 4] 슬롯 2: C1 · 슬롯 3: N5
-  #1 C2∧N2:      [O] 미해당
-  #3 C6∧N4:      [O] 미해당
-  #4 (1~6)C1∧C3: [O] 미해당 (C3 미배치)
-  #5 C9∧단독보스: [O] 미해당 (C9 미배치)
-  #6 N3:         [O] 미해당
-  #7 N5∧N6:      [O] 미해당 (N5만)
-  [최종 판정] [O] 통과
-```
-
-#### §3-4-6. TTK 검증
-
-**Lv.4 · 각성 1 · 카드 2~3장 · 일반셋 · 인장 1★ · DPS ≈ 1.05 × 1.15 × 1.3 × 1.2 × 1.05 = 1.98**
-
-| 서브맵 | 내구도 | TTK |
-|--------|-------|-----|
-| 1·3·4·6 (일반) | 각 ~15~25 | 각 8~13s |
-| 2 (거미여왕2+일반) | 보스 130 + 일반 ~15 = 145 | 73~85s |
-| 5 (흑기사2+일반) | 보스 118 + 일반 ~15 = 133 | 67~80s |
-| 7 (늑대인간+일반) | 보스 85 (Shield 0) + 일반 ~10 = 95 | 48~60s |
-| **전체** | - | **220~320s** |
-
-**C1 신속 조건 튜닝 제안**: 임계 300s (평균~상한) → 재도전 2~3회 시 달성 가능 수준
-
-#### §3-4-7. 반복 방지 다양성 지표
-
-- 일반 서브맵 4개 × 각 5~6종 × 2~3마리 = **서브맵당 ~25가지 × 4 독립 = 390,625가지 이상 조합**
-- AppearGroup 다양화 규칙 적용 시 **서브맵 간 조합 중복 최소화**
-
----
-
-### §3-5. Stage 5 — "대사탄과 다크엘프아처의 쉴드 극치"
-
-#### §3-5-1. 목표 정의
-
-- **위치**: WM1 · 중반 시작
-- **목표 난이도**: ★1 75% · ★2 40%→65% · ★3 15%→45%
-- **재미 포지션**: "쉴드 극단 처음 경험 (다크엘프아처1 Shield 282)"
-- **플레이어 예상**: Lv.5 · 각성 2단계 · 진화 1★ · 일반셋 · 인장 2★ · 카드 3장
-- **특이**: **다크엘프아처1 HP 35 + Shield 282** (Stage 5 내구도 233 · 지역 1 최고). 원거리 보스 · ATK 19 (지역 1 보스 평균 ATK 최고)
-
-#### §3-5-2. 보스 구성
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | 등장 |
-|--------|-------|-----|--------|---------|------|
-| 10009 | 대사탄1 | 88 | 60 | 16.0 | 서브맵 3 |
-| 10010 | **다크엘프아처1** | 35 | **282** | 19.0 | 서브맵 6 (최종 · **Shield 극치**) |
-
-#### §3-5-3. 노드별 전투 구성
-
-| 서브맵 | 고정 | 랜덤 풀 | 규칙 |
-|--------|-----|--------|------|
-| 1 | 없음 | 인간형 초기 3종 (고블린·오크·강도初) + 마법생물 中 1종 | 4종 중 2~3 |
-| 2 | 없음 | 인간형 초기 3종 + 마법생물 中 2종 | 5종 중 2~3 (1과 다른) |
-| 3 | **대사탄1** | 인간형 초기 1종 + 마법생물 1종 | 보스 + 랜덤 1~2 |
-| 4 | 없음 | 인간형 초기 3종 + 언데드 初 1종 (해골 조기 등장) | 4종 중 2~3 |
-| 5 | 없음 | 인간형 초기 4종 + 마법생물 中 2종 | 6종 중 2~3 |
-| 6 | **다크엘프아처1 (최종)** | 원거리 혼용 1종 (박쥐 高) | 보스 + 랜덤 1 |
-
-**근접/원거리**:
-- 대사탄1 = **원거리** (마법 · Shield 60 중간) · 다크엘프아처1 = **원거리 궁수** (Shield 282 극치 · ATK 19 최고)
-- 서브맵 6 혼용 = 원거리 (박쥐) → "원거리 보스 + 원거리 혼용" 집중 구성 (다른 서브맵은 근접 중심)
-- **전 스테이지 중 "원거리 대응 학습" 테마**
-
-#### §3-5-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 배치 근거 |
-|------|-----|----------|
-| 슬롯2 | **C12 회피 주도** (회피 ≥ 서브맵수×3 = 18회 이상) | 원거리 보스·고ATK 대응 회피 동기. 빌드 의존 중~저 (회피 시스템 활용) |
-| 슬롯3 | **N6 전열 선공** (서브맵마다 최초 = 전열) | N5와 달리 전열 우선 타겟팅 학습. 다크엘프아처1 대비 전열 방어자 먼저 처치 전략 |
-
-**배치 사유**:
-- 쉴드 극치 스테이지 → 회피 주도 + 타겟팅 전략 (전열 우선)
-- P17-7 (N5 ∧ N6) 회피 (N5 미배치) · 다른 배타 모두 회피
-
-#### §3-5-5. P17 체크 시트
-
-```
-[Stage 5] 슬롯 2: C12 · 슬롯 3: N6
-  #1 C2∧N2:      [O] 미해당
-  #3 C6∧N4:      [O] 미해당
-  #4 C1∧C3:      [O] 미해당
-  #5 C9∧단독보스: [O] 미해당
-  #6 N3:         [O] 미해당
-  #7 N5∧N6:      [O] 미해당 (N6만)
-  [최종 판정] [O] 통과
-```
-
-#### §3-5-6. TTK 검증
-
-**Lv.5 · 각성 2 · 진화 1★ · 일반셋 · 인장 2★ · 카드 3장 · DPS ≈ 1.05 × 1.20 × 1.3046 × 1.4 × 1.0 × 1.10 = 2.53**
-(각성 2 = 실측 50% 중 ~40% · 진화 1★ = ~0% · 인장 2★ = ~10%)
-
-| 서브맵 | 내구도 | TTK |
-|--------|-------|-----|
-| 1·2·4·5 (일반) | 각 ~15~30 | 각 6~12s |
-| 3 (대사탄1+일반) | 보스 148 + 일반 ~15 = 163 | 64~80s |
-| 6 (**다크엘프아처1 + 박쥐**) | 보스 317 (HP35+Shield282) + 박쥐 ~10 = 327 | **129~155s** (Shield 극치) |
-| **전체** | - | **220~320s** |
-
-**핵심 주의**: 서브맵 6이 Stage 5 TTK의 50% 이상 차지 · 입문 구간 상한 난이도 · C12(회피 18회) 조건이 "재도전 2~3회 후 달성" 수준
-
-#### §3-5-7. 반복 방지 다양성 지표
-
-- 일반 서브맵 4개 × 평균 ~25가지 × 독립 = **390,625가지 이상**
-- 서브맵 6 혼용 풀이 원거리 중심 1종이므로 **"최종 보스 테마(원거리)" 일관성** 확보
-
----
-
-### §3-6. Stage 6 — "대사탄과 데스나이트의 균형 난이도"
-
-#### §3-6-1. 목표 정의
-
-- **위치**: WM1 · 중반 시작 · 지역 1 최종
-- **목표 난이도**: ★1 70% · ★2 35%→60% · ★3 12%→40%
-- **재미 포지션**: "지역 1 졸업 시험 + 성장 5축 결합 첫 체감"
-- **플레이어 예상**: Lv.6 · 각성 2 · 진화 2★ · 세트 일부 · 인장 3★ · 카드 3~4장
-- **특이**: WM2 진입 직전 · 보스 2체 균형 난이도 (Stage 5의 Shield 극치 완화)
-
-#### §3-6-2. 보스 구성
-
-| 보스ID | 보스명 | HP | Shield | ATK평균 | 등장 |
-|--------|-------|-----|--------|---------|------|
-| 10011 | 대사탄2 | 102 | 72 | 17.0 | 서브맵 3 |
-| 10012 | 데스나이트3 | 97 | 77 | 13.5 | 서브맵 7 (최종) |
-
-#### §3-6-3. 노드별 전투 구성
-
-| 서브맵 | 고정 | 랜덤 풀 | 규칙 |
-|--------|-----|--------|------|
-| 1 | 없음 | 인간형 초기 4종 + 수인형 中 2종 | 6종 중 2~3 |
-| 2 | 없음 | 인간형 초기 3종 + 마법생물 中 1종 + 언데드 初 1종 | 5종 중 2~3 |
-| 3 | **대사탄2** | 마법생물 中 1종 + 인간형 초기 1종 | 보스 + 랜덤 1~2 |
-| 4 | 없음 | 인간형 초기 4종 + 마법생물 中 2종 | 6종 중 2~3 |
-| 5 | 없음 | 인간형 초기 3종 + 다크엘프 2종 (전조) | 5종 중 2~3 |
-| 6 | 없음 | 인간형 초기 3종 + 언데드 初 2종 | 5종 중 2~3 |
-| 7 | **데스나이트3 (최종)** | 언데드 初 1종 (해골) | 보스 + 랜덤 1 |
-
-**근접/원거리**:
-- 대사탄2 = **원거리** (마법 · Shield 72) · 데스나이트3 = **근접 중장갑** (Shield 77 · Stage 4 흑기사2 계승 진화형)
-- 서브맵 5 "다크엘프 전조" + 서브맵 6·7 "언데드 전조" → **WM2(Stage 7~ 언데드) 테마 이식**
-- 일반 서브맵 6개 중 4개 근접 중심 · 2개 원거리 혼합
-
-#### §3-6-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 배치 근거 |
-|------|-----|----------|
-| 슬롯2 | **N2 피격 제한** (피격 ≤ 서브맵수×1 = 7회) | 지역 1 졸업 · 전투 기초 마스터리 검증 |
-| 슬롯3 | **N4 쉴드 보존** (Shield ≥ MaxShield × 30%) | 성장 5축 결합 시 쉴드 관리 학습 |
-
-**배치 사유**:
-- 지역 1 졸업 시험 · 기초 축(N2 피격) + 성장 축(N4 쉴드) 결합
-- P17-1 (C2 ∧ N2) 회피 (C2 미배치) · P17-3 (C6 ∧ N4) 회피 (C6 미배치)
-- **Stage 1 (N1·N5) → Stage 6 (N2·N4) 으로 "N 계열 4축 체험 완결"**
-
-#### §3-6-5. P17 체크 시트
-
-```
-[Stage 6] 슬롯 2: N2 · 슬롯 3: N4
-  #1 C2∧N2:      [O] 미해당 (C2 미배치)
-  #3 C6∧N4:      [O] 미해당 (C6 미배치)
-  #4 C1∧C3:      [O] 미해당
-  #5 C9∧단독보스: [O] 미해당
-  #6 N3:         [O] 미해당
-  #7 N5∧N6:      [O] 미해당
-  [최종 판정] [O] 통과
-```
-
-#### §3-6-6. TTK 검증
-
-**Lv.6 · 각성 2 · 진화 2★ · 세트 일부 · 인장 3★ · 카드 3~4장**
-**DPS ≈ 1.05 × 1.30 × 1.5 (세트 일부+일반) × 1.4 × 1.15 × 1.15 = 3.55**
-(세트 일부 = 30.46% + 일부만 71.46% 적용 ≈ 50% 가정)
-
-| 서브맵 | 내구도 | TTK |
-|--------|-------|-----|
-| 1·2·4·5·6 (일반) | 각 ~18~30 | 각 5~9s |
-| 3 (대사탄2+일반) | 보스 174 + 일반 ~12 = 186 | 52~66s |
-| 7 (데스나이트3+일반) | 보스 174 + 일반 ~8 = 182 | 51~64s |
-| **전체** | - | **160~220s** |
-
-**목표 난이도 정합**: 지역 1 최종 · 성장 5축 결합 체감 · 재도전 3~5회 시 ★3 달성
-
-#### §3-6-7. 반복 방지 다양성 지표
-
-- 일반 서브맵 5개 × 평균 ~25가지 × 독립 = **~9,765,625가지 이상 조합**
-- 서브맵 5·6의 "전조 몬스터" (다크엘프·언데드)가 지역 2 진입 준비 테마 이식
-
----
-
-## §4. 지역 1 통합 P17 배타 7종 전수 체크 (12 슬롯)
-
-| Stage | 슬롯2 | 슬롯3 | P17-1 C2∧N2 | P17-3 C6∧N4 | P17-4 C1∧C3 | P17-5 C9 | P17-6 N3 | P17-7 N5∧N6 | 판정 |
-|-------|------|------|------------|------------|------------|---------|---------|------------|------|
-| 1 | N1 | N5 | 미해당 | 미해당 | 미해당 | 미해당 | 미해당 | 미해당 | **통과** |
-| 2 | C3 | N4 | 미해당 | 미해당 | 미해당 (C1 미) | 미해당 | 미해당 | 미해당 | **통과** |
-| 3 | C6 | N2 | 미해당 (C2 미) | 미해당 (N4 미) | 미해당 | 미해당 | 미해당 | 미해당 | **통과** |
-| 4 | C1 | N5 | 미해당 | 미해당 | 미해당 (C3 미) | 미해당 | 미해당 | 미해당 (N6 미) | **통과** |
-| 5 | C12 | N6 | 미해당 | 미해당 | 미해당 | 미해당 | 미해당 | 미해당 (N5 미) | **통과** |
-| 6 | N2 | N4 | 미해당 (C2 미) | 미해당 (C6 미) | 미해당 | 미해당 | 미해당 | 미해당 | **통과** |
-
-**위반 감지**: **0건** · B 방식 중단 트리거 미발동
-
-### §4-1. 지역 1 슬롯 사용 조건 분포
-
-| 조건 | 사용 횟수 | 사용 스테이지 |
-|------|---------|-------------|
-| C1 | 1 | Stage 4 |
-| C3 | 1 | Stage 2 |
-| C6 | 1 | Stage 3 |
-| C12 | 1 | Stage 5 |
-| N1 | 1 | Stage 1 |
-| N2 | 2 | Stage 3 · Stage 6 |
-| N4 | 2 | Stage 2 · Stage 6 |
-| N5 | 2 | Stage 1 · Stage 4 |
-| N6 | 1 | Stage 5 |
-| **입문 금지** | **0** | C2·C9·N3 전수 배제 |
-
-**분포 평가**: 9개 허용 조건 전수 사용 · 지역 1 완주 시 플레이어는 "시간·HP·포션·회피·빗맞힘·피격·쉴드·후열·전열" 9가지 조건 체험 완결. **재미 차별화 체험 보장**.
-
----
-
-## §5. 지역 1 통합 반복 방지 다양성 지표 (정량)
-
-### §5-1. 스테이지별 일반 서브맵 조합 다양성
-
-| Stage | 일반 서브맵 수 | 평균 조합/서브맵 | 스테이지 총 독립 조합 |
-|-------|-------------|--------------|------------------|
-| 1 | 2 | 15 | 225 |
-| 2 | 3 | 20 | 8,000 |
-| 3 | 3 | 20 | 8,000 |
-| 4 | 4 | 25 | 390,625 |
-| 5 | 4 | 25 | 390,625 |
-| 6 | 5 | 25 | 9,765,625 |
-
-### §5-2. 지역 1 전체 다양성
-
-- 지역 1 총 "1판 완주" 독립 조합 경우의 수: **약 700경 이상** (각 스테이지 조합 독립 곱)
-- 해석: 매 판 재플레이 시 "완전히 동일한 스테이지 진행" 확률 ≈ **0%에 수렴**
-- **"매 스테이지 고정 몬스터 (보스) + 매 판 랜덤 몬스터 (일반)" PD 고려사항 2 전수 충족**
-
-### §5-3. 근접/원거리 몬스터 다양성 (PD 고려사항 1)
-
-| Stage | 보스 근접:원거리 | 일반 풀 근접:원거리 비율 |
-|-------|---------------|-------------------|
-| 1 | 1:1 (놀아처1 원·놀강도2 근) | 약 4:1 (수인형 근 + 슬라임·쥐 근 + 박쥐 원 일부) |
-| 2 | 3:0 (오우거·놀강도·임프 모두 근) | 약 3:1 |
-| 3 | 1:1 (바포메트 원·거미여왕 근) | 약 3:1 |
-| 4 | 3:0 (거미·흑기사·늑대 근) | 약 3:1 |
-| 5 | 0:2 (대사탄·다크엘프 모두 원 · **원거리 테마**) | 약 2:1 (원거리 증가) |
-| 6 | 1:1 (대사탄 원·데스나이트 근) | 약 3:1 (언데드 전조) |
-
-**해석**: 지역 1 내에서 근접 단독 스테이지·원거리 단독 스테이지·혼합 스테이지가 **순환 등장** → "같은 스테이지가 연속 등장 체감" 방지
-
----
-
-## §6. 입문 구간 학습 곡선 테스트 결과 예상
-
-### §6-1. 플레이어 경험 시뮬 (지역 1 완주 시나리오)
-
-| 플레이 라운드 | Stage 1 | Stage 2 | Stage 3 | Stage 4 | Stage 5 | Stage 6 | 누적 성장 |
-|--------------|---------|---------|---------|---------|---------|---------|---------|
-| 1회 (첫 플레이) | ★1 클리어 90% · ★2 40% | ★1 85% · ★2 35% | ★1 80% · ★2 30% | ★1 75% · ★2 25% | ★1 70% · ★2 20% | ★1 65% · ★2 15% | 카드 풀 3~4장 · 각성 1~2 |
-| 2~3회 (학습) | ★2 80% · ★3 25% | ★2 75% · ★3 20% | ★2 70% · ★3 15% | ★2 65% · ★3 10% | ★2 60% · ★3 8% | ★2 55% · ★3 6% | 세트 일부 · 진화 시작 |
-| 4~5회 (숙달) | ★3 65% | ★3 55% | ★3 50% | ★3 45% | ★3 40% | ★3 35% | 세트 완성 · 인장 3~5★ |
-
-### §6-2. 학습 곡선 평가
-
-- **Stage 1·2**: "전투 기초·몬스터 약점 인식" 단계 · 실패해도 재시도 부담 낮음
-- **Stage 3·4**: "★ 조건 인식 시작" · 슬롯2·슬롯3이 명확히 다른 축임을 체감
-- **Stage 5**: "쉴드 극치 충격" · 성장 5축 중 카드·장비 결합 필요성 처음 인식
-- **Stage 6**: "지역 1 졸업 시험" · 성장 5축 결합 첫 성공 체감 · WM2 진입 의지 형성
-
-### §6-3. 잠재 위험 지점
-
-1. **Stage 2 오우거1 ATK Max 30** — 첫 "갑작스러운 난이도 점프" 체감 우려 (스테이지난이도곡선_v1 §8-5 이상값 인지됨). 완화안: Stage 2 ★ 조건(C3·N4)이 "HP 유지 + 쉴드 관리"로 오우거1 대응 학습 자연스럽게 유도
-2. **Stage 5 다크엘프아처1 Shield 282** — 입문 구간 최고 Shield · 첫 "Shield 극치" 체감 우려. 완화안: Stage 3~5 점진 Shield 증가 (바포메트6 66 · 거미여왕2 72 · 다크엘프아처1 282) · Stage 5 ★ 조건(C12·N6)이 회피·타겟팅으로 "직접 Shield 깨기 외 선택지" 제공
-3. **C1 Stage 4 배치의 입문 부담** — 착수가이드 §3-1 입문 C1 주의. 완화안: Stage 4가 7서브맵 긴 스테이지이므로 시간 관리 자체가 자연스러운 학습 축. 임계 300s 넉넉한 상한으로 설정 제안
-
-### §6-4. 고주의 판정 (Phase 3 §5-5 임계 체크)
-
-| 임계 | 지역 1 해당 여부 |
-|------|---------------|
-| 보스 Shield ≥ 300 | **없음** (최대 Stage 5 다크엘프아처1 Shield 282 · 근접 임계 미만) |
-| 보스 Shield ≥ 500 (극단) | 없음 |
-| 몬스터 ATK ≥ 45 | **주의** (Stage 2 오우거1 ATK Max 30 · 입문 상대 고부담 간주) |
-| 보스 재사용 ≥ 3회 | 없음 (Stage 1·2 놀강도2 2회, Stage 3·4 거미여왕2 2회만) |
-| 서브맵 수 ≤ 3 | 없음 (최소 4) |
-
-**지역 1 고주의 판정**: **오우거1 ATK만 주의 수준** · Unity MCP 시뮬 선행 권장 (Stage 2 서브맵 6 단독 교전 1회 시뮬)
-
----
-
-## §7. 기각안 (P24 · C32 필수)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 지역 1 범위를 "Stage 1~4"로 축소하고 Stage 5~6은 지역 2로 이관 | PD B안 원문 "지역 1 = WorldMap_1"·실측 WM1 = Stage 1~6. PM 재량 범위 외연 조정 금지 (C36-2 판정 기준 b) |
-| 2 | 입문 구간에 C9(보스 집중) 배치 (Stage 4~6에 한정) | P17-5 △ 비권장 · 보스 미등장 서브맵 비율 현 미확정. 본 지역은 보수적 배제. Stage 7~12 중반 구간부터 C9 본격 배치 |
-| 3 | 입문 구간에 N3(치명타 처치) 배치 | P17-6 입문 구간 단독 배치 금지. 치명타 빌드 미형성 구간 · PD 3차 승인 조건 |
-| 4 | 매 스테이지 랜덤 풀 구성을 "전 서브맵 고정"으로 단순화 | PD 고려사항 2 "매 판 랜덤성 필수" 위반. 반복 체감 과다 |
-| 5 | 보스 구성에 새로운 몬스터 추가 제안 | 스테이지난이도곡선_v1 §3 실측 보스 ID 고정 · 본 Phase는 노드 구성이지 몬스터 신규 제작 아님 (C36 방향·원칙 수준 축소 금지) |
-| 6 | ★ 조건 배치를 "PD 판단 대기"로 보류하고 조건 미배치 상태로 산출 | PD 원문 "3★ 클리어 조건 고려 노드 구성" · 기획팀장 재량 초안 작성 후 PD 승인 단계로 진입이 정상. 보류는 C29 업무 자율 수행 위반 |
-| 7 | Stage 1에 C6(포션 절제) 배치 | Stage 1 Lv.1 · 카드 미습득 · 포션 시스템 인지 전 단계 · 재미 축 불일치. Stage 3 이후 배치 적합 |
-| 8 | Stage 5 슬롯2·3에 C1(신속) 포함 | Stage 5 TTK 220~320s · 다크엘프아처1 Shield 극치로 시간 편차 과다. C1 배치 시 "Shield 빨리 깨기" 강제 → 빌드 의존 심화. Stage 4에서 C1 배치가 재미 균형에 적합 |
-| 9 | 반복 방지를 "랜덤 시드 고정"으로 단순화 | PD 고려사항 4 "반복 패턴 방지 · 다양한 랜덤 상황" 위반. 시드 고정은 결정론적 반복. 랜덤 풀 5~6종 × 2~3마리 구성이 근원 해결 (C2-1) |
-| 10 | Stage 6 지역 1 졸업 시험에 "지역 2 보스 미리보기" 보스 배치 | Stage 6 보스는 대사탄2·데스나이트3 고정 (SOT) · 보스 교체는 데이터 자산 변경 (C6-1). "WM2 테마 이식"은 일반 몬스터 서브맵 5·6의 다크엘프·언데드 전조로 충분 |
-| 11 | 12 슬롯 중 일부를 "동일 조건 중복 사용"으로 단순화 (예: 모두 N1) | PD 고려사항 3 "3★ 클리어 조건 고려 노드 구성" · §4-1 "지역 1 완주 시 9가지 조건 체험 완결" 재미 축 상실 |
-| 12 | TTK 검증을 생략하고 노드 구성만 확정 | Phase 4 가이드 §3-4 단계 4 TTK 검증 의무. 수치 근거 없는 배치 확정은 C23 정직성 위반 |
-
----
-
-## §8. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 내역 | 재미 근거 | 관련 PD 지시# |
-|------|-------|----------|----------|-------------|
-| 2026-04-20 | 기획팀장 (PM 경유 PD B안 확정 집행) | 지역 1 v1 초안 작성 · Stage 1~6 노드 구성 (고정 몬스터 14 보스 + 랜덤 풀 매 서브맵 구성) · ★ 조건 12 슬롯 배치 (9종 조건 전수 사용) · P17 7종 전수 체크 (위반 0건) · TTK 검증 6 스테이지 · 반복 방지 다양성 지표 정량 · 학습 곡선 시뮬 · 기각안 12종 | 학습 곡선의 부드러움 + 고정+랜덤 이원 재미 + ★ 조건 차별화 체험 (§1-3) | 기획팀 #41 |
-
----
-
-## §9. 재미 근거 (P30 기획팀 전용)
-
-**강화하려는 재미 축 3종** (§1-3 전수 이식):
-
-1. **학습 곡선의 부드러움**: Stage 1 전투 기초 → Stage 2 난이도 점프(오우거1) → Stage 3 Shield 첫 체감 → Stage 4 긴 스테이지 시간 관리 → Stage 5 원거리 테마 + 쉴드 극치 → Stage 6 지역 졸업 시험 + 성장 5축 결합. **6 스테이지 순서가 "전투 기초 → 특수 요소 → 성장 의존" 점진 설계**
-2. **고정+랜덤 이원 재미**: 14 보스 고정 배치 + 매 서브맵 평균 ~25가지 몬스터 조합 랜덤 → "예측 가능한 보스 마일스톤" + "매번 다른 일반전 디테일" 공존. 플레이어는 "이 스테이지 보스 뭐 오지?" 기대감 + "이번엔 어떤 몬스터 나올까?" 호기심 동시 체험
-3. **★ 조건 차별화 체험**: 12 슬롯에 9종 조건 전수 사용 (C1·C3·C6·C12·N1·N2·N4·N5·N6). 지역 1 완주 = "조건 메타 9가지 체험 완결" → 재도전 시 "다음 스테이지는 어떤 조건일까?" 기대 + 재미 차별화
-
-**재미 축 누락 방지 체크**:
-- 입문 구간 학습 곡선 (축 1) — §1-4 플레이어 예상 상태 + §6-2 플레이어 경험 시뮬 반영 확인 ✅
-- 고정+랜덤 이원 재미 (축 2) — §3 각 스테이지 노드별 구성 (고정 + 랜덤 풀) 전수 명시 ✅
-- 조건 차별화 (축 3) — §4-1 지역 1 슬롯 사용 조건 분포 9종 전수 사용 ✅
-
----
-
-## §10. 관련 규칙·참조
-
-- **헌법 제1원칙 ①·②** (AI 전문 개발 스튜디오 · 경험 축적 계승) — Phase 3 설계 체계 계승
-- **C6-1** 원본 파일 보호 — 본 집행에서 기존 산출물(스테이지난이도곡선_v1 등) 수정 없음
-- **C9-2** 일정·기한 표현 금지 — 본 문서 내 "N회 플레이" 표현은 플레이어 재플레이 횟수이지 작업 시간 아님
-- **C22** 용어 일관 — "지역 1·Stage 1~6·WorldMap_1" PD 도입 용어 유지
-- **C23** 정직성 — 스테이지난이도곡선_v1 §3·§5 실측 데이터 근거 · 추정은 "예상·가정" 태그 부착
-- **C25** 넘버링 일관 — §0~§10 고정 위계
-- **C34-11** Agent 경계 보호 — 본 문서는 레포 상대 경로 사용
-- **C36** PM·팀장 재량 상한 — 본 문서는 **지역 1 노드 구성 초안** 수준 · 지역 2 이후 착수는 PD 승인 후
-- **C37** 규칙 문서 관리 — 섹션 구조·표기법 통일
-- **P16** 산출물 추적성 — §8
-- **P17** ★ 조건 배타 배치 7종 — §4 전수 체크
-- **P18** 설계 문서화 의무 — 본 문서는 Phase 4 지역 1 노드 구성 설계 문서
-- **P23** 기획 결정 재량 범위 — 노드 구성 초안은 기획팀장 재량 · 배치 방향 확정은 PD 결정
-- **P24·C32** 기각안 필수 — §7
-- **P29** 코어 프레임워크 조직 자산 계승 — Phase 3 체계 승계
-- **P30** 재미 우선 원칙 — §9
-
----
-
-*Phase 4 지역 1 v1 초안 완료: 2026-04-20*
-*지역 1 (WorldMap_1 · Stage 1~6) 노드 구성 초안 완결 — PD 승인 수령 시 지역 2 (WorldMap_2 · Stage 7~10) 순차 착수 가능*
diff --git a/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md b/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md
deleted file mode 100644
index 8834d24..0000000
--- a/프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v2.md
+++ /dev/null
@@ -1,621 +0,0 @@
----
-type: Phase 4 지역별 노드 구성 (지역 1 · Stage1_1~1_4)
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD 재발 방지 지시 #44 수용 · v1 폐기 대체)
-관련PD지시: 기획팀 #44 · PD 2026-04-20 "PD가 구성한 지역별 스테이지 수량 임의 수정 금지 (지역 1 = 4개)"
-상태: **v2 초안 · PD 검증 선행** (ToolData.json 생성 전 사전 승인 필수)
-데이터 소스: CreateMapConfig.csv (실측 2026-04-20) · ApprearMonsterPattern.csv (실측 2026-04-20) · MonsterList.csv (실측 2026-04-20)
-선행문서:
-  - 프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md (데이터 구조 SOT)
-  - 프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md (기획팀 재발 방지 룰)
-  - 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 PD 3차 승인)
-  - SKILL.md P17 (배타 7종 SOT)
-대체: 프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md (🔴 아카이브)
----
-
-# Phase 4 지역 1 노드 구성 v2 — Stage1_1·1_2·1_3·1_4 (지역 1 / 입문 초입)
-
-## §0. 본 v2의 정정 요지
-
-### §0-1. v1 폐기 사유
-- v1은 "지역 1 = Stage 1~6 = 6개 스테이지" 전제 (잘못된 데이터 구조 해석)
-- PD 2026-04-20 확정: **지역 1 = Stage1_1·1_2·1_3·1_4 = 4개**
-- 근거: `CreateMapConfig.csv` 실측 (`s_MapConfigID` 기준 Stage1_{1~4})
-
-### §0-2. v2 집행 범위 (지역 1만)
-- Stage1_1 · Stage1_2 · Stage1_3 · Stage1_4 노드 구성 확정 초안
-- 고정 몬스터 + 매 판 랜덤 몬스터 풀 정의 (PD 고려사항 1·2·4)
-- 3★ 클리어 조건 배치 (PD 고려사항 3)
-- P17 배타 7종 전수 체크 (4 스테이지 × 2 슬롯 = 8 슬롯)
-- 반복 방지 다양성 지표
-
-### §0-3. 본 문서가 하지 않는 것 (명시적 금지)
-- **지역 2 이후 착수 금지** — PD 승인 후 순차 (지역 2 = Stage2_1~2_6 = 6개)
-- **조건 풀 12개 신규 추가 금지** — PD 3차 승인 범위 내만
-- **기존 v1의 Stage 2~6 설계 재활용 금지** — 해당 스테이지들은 **지역 2~? 소속**이므로 본 v2 범위 외 · 별도 집행
-
-### §0-4. v1 설계 중 승계한 요소 (실측 구조 무관 원칙)
-- 12개 조건 풀 사용 (3성조건_12개_상세명세_v1.md)
-- P17 배타 7종 체크 방식
-- 고정+랜덤 이원 구조
-- 재미 포지션 분리 (학습 곡선·이원 재미·★ 조건 차별화)
-- 몬스터 특성 기반 매칭
-
----
-
-## §1. 지역 1 개요 · 실측 데이터
-
-### §1-1. 지역 1 실측 구조 (CreateMapConfig.csv)
-
-| MapConfig ID | n_StageType | 몬스터 그룹 | 보스 그룹 | 보스ID | 보스명 |
-|-------------|-------------|------------|----------|--------|-------|
-| Stage1_1 | 1 | 10101 | 0 | 없음 | (일반전) |
-| Stage1_2 | 1 | 10102 | 10001 | 10001 | 놀아처1 |
-| Stage1_3 | 1 | 10103 | 0 | 없음 | (일반전) |
-| Stage1_4 | 1 | 10104 | 10002 | 10002 | 놀강도2 |
-
-**구조 해석**:
-- **4개 스테이지 × 교대 패턴** (일반전 → 보스전 → 일반전 → 보스전)
-- 몬스터 그룹 10101~10104 (본 지역 전용 풀)
-- 보스 2마리 (스테이지 2·4에만 등장)
-- 현재 노드 확률 수치는 임시 (본 v2에서 차별화 설계)
-
-### §1-2. 등장 몬스터 풀 (ApprearMonsterPattern.csv 실측)
-
-| 그룹 | 소속 몬스터 ID |
-|------|--------------|
-| 10101 (Stage1_1) | 14001 · 14002 · 14013 |
-| 10102 (Stage1_2) | 14001 · 14013 · 14014 · 11007 |
-| 10103 (Stage1_3) | 14014 · 11001 · 11002 · 11007 |
-| 10104 (Stage1_4) | 11001 · 11002 · 11007 · 14003 · 11003 |
-
-**구조 해석**:
-- **종족 전환**: 초반(14XXX 계열 · 수인형/마법생물) → 후반(11XXX 계열 · 인간형)으로 점진 전환
-- 11007·14013·14014 = 지역 1 공통 등장 (안정감)
-- 14003·11003 = Stage1_4에만 등장 (최종 스테이지 다양성 가중)
-
-### §1-3. 보스 스탯 (MonsterList.csv 실측)
-
-| 보스ID | 보스명 | 유형 | HP | Shield | ATK | CoolTime | DPS | 특성 |
-|--------|-------|-----|-----|--------|-----|----------|-----|------|
-| 10001 | 놀아처1 | **Boss_Range** | 20 | 15 | 4~6 | 2.3s | 2.45 | 크리티컬 10% |
-| 10002 | 놀강도2 | **Boss_Melee** | 30 | 22 | 6~8 | 1.9s | 3.91 | 광포화-신속화 50% |
-
-**구조 해석**:
-- 지역 1 = **원거리 보스(Stage1_2) → 근접 보스(Stage1_4)** 양축 경험
-- 첫 보스(놀아처1)는 "원거리 대응 기본기" 학습
-- 최종 보스(놀강도2)는 "근접 + 광포화 상태 대응" 학습
-
-### §1-4. 지역 1 재미 포지션 (P30)
-
-**강화하려는 재미 축 3종**:
-
-1. **첫 만남의 임팩트**: Stage1_1 첫 전투 → Stage1_2 첫 보스 조우로 "기본 전투 → 보스 전투" 단계 학습
-2. **원거리·근접 양축 체험**: 지역 1 내에서 원거리 보스(놀아처1) + 근접 보스(놀강도2) 모두 등장
-3. **★ 조건 첫 인식**: 12개 조건 풀 중 지역 1이 **"정확도·체력·타겟팅"** 3축 학습 (N1·C3·N5 중심)
-
-**재미 정의** (P30-1 준수): 본 지역은 "재도전 유도 입문"으로 ★1은 높은 확률, ★3은 재도전 기반 달성.
-
-### §1-5. 목표 난이도
-
-| 스테이지 | ★1 클리어 | ★2 (슬롯2 1개) | ★3 (슬롯2+슬롯3) |
-|---------|----------|---------------|---------------|
-| Stage1_1 | 97% 이상 | 70% (1회) → 90% (2~3회) | 40% (2~3회) → 70% (4~5회) |
-| Stage1_2 | 92% | 60% → 85% | 33% → 62% |
-| Stage1_3 | 88% | 55% → 80% | 28% → 57% |
-| Stage1_4 | 82% | 45% → 72% | 22% → 50% |
-
-### §1-6. 플레이어 예상 상태 (TTK 산출용)
-
-| 스테이지 | Lv. | 각성 | 진화 | 장비 | 인장 | 카드 |
-|---------|-----|------|------|------|------|------|
-| Stage1_1 | 1 | 미 | 미 | 기본 | 미 | 0~1장 |
-| Stage1_2 | 1~2 | 미 | 미 | 기본 | 미 | 1~2장 |
-| Stage1_3 | 2 | 미 | 미 | 기본~일반셋 | 미 | 2장 |
-| Stage1_4 | 2~3 | 1단계 | 미 | 일반셋 | 미 | 2~3장 |
-
-**DPS 산출 기본값**: Phase 0 앵커 PC 6001 Lv.1 기준 **1.05** · Stage1_4에서 각성 1단계 반영 시 **~1.35**
-
----
-
-## §2. 지역 1 P17 배타 사전 허용 후보 (입문 구간)
-
-지역 1 = 입문 초입 → 42슬롯 현황 §2-1 입문 구간 제약 적용:
-
-| 배타 조합 | 적용 | 근거 |
-|----------|-----|------|
-| P17-4 (C1 ∧ C3) | **동시 배치 금지** | 입문 이중 부담 과도 |
-| P17-5 (C9 ∧ 단독/미등장 보스) | **C9 배치 금지** | Stage1_1·1_3 보스 미등장 + 보스 있는 스테이지도 단독 보스 (C9 논리 불성립) |
-| P17-6 (N3 입문 금지) | **배치 금지** | 치명타 빌드 미형성 구간 |
-| P17-1 (C2 ∧ N2) | 슬롯2·3 동시 배치 금지 | 이중 부담 |
-| P17-3 (C6 ∧ N4) | 동시 배치 금지 | 빌드 배제 |
-| P17-7 (N5 ∧ N6) | 동시 배치 금지 | 타겟팅 모순 |
-| P17-2 (C6 ∧ 물약유도) | 비활성 | 조건 풀에 물약 유도 부재 |
-
-**지역 1 허용 후보 풀 (입문 공통)**: **C1 · C3 · C6 · C12 · N1 · N2 · N4 · N5 · N6 (9종)**
-- 제외: C2(입문 과도) · C9(구조상 불성립) · N3(입문 금지)
-
----
-
-## §3. 각 스테이지 노드 구성 확정 초안
-
-### §3-1. Stage1_1 — "첫 전투의 감각"
-
-#### §3-1-1. 목표 정의
-- **위치**: 지역 1 · 첫 스테이지 (튜토리얼 직후 가정)
-- **목표 난이도**: ★1 97% · ★2 70%→90% · ★3 40%→70%
-- **재미 포지션**: "기본 전투 메커닉 이해 · 적을 맞추는 감각 학습"
-- **플레이어 예상**: Lv.1 · 카드 0~1장
-
-#### §3-1-2. 등장 몬스터 (실측: 그룹 10101)
-| 몬스터 ID | 특성 추정 (수인형·마법생물 계열) | 배치 |
-|-----------|-------------------------------|------|
-| 14001 | 수인형 저레벨 | 랜덤 풀 |
-| 14002 | 수인형 저레벨 | 랜덤 풀 |
-| 14013 | 마법생물 저레벨 (슬라임/쥐 계열) | 랜덤 풀 |
-
-**3종 풀 · 보스 없음**.
-
-#### §3-1-3. 노드별 전투 구성
-
-> **서브맵 수**: 런타임 생성 (CreateMapConfig.n_MobNodeMin/Max 4~20 범위). 기획 의도는 **입문 스테이지 → 서브맵 4~6개 권장**
-> **고정 몬스터**: 없음 (Stage1_1은 전원 랜덤) / **랜덤 풀**: 3종 전수
-
-| 서브맵 | 전투 규모 | 몬스터 구성 | 특이사항 |
-|--------|---------|-----------|---------|
-| 1 | 소규모 | 3종 중 1~2마리 | 첫 전투 · 학습 부담 최소 |
-| 2 | 소규모 | 3종 중 2마리 | 조합 변화 학습 |
-| 3 | 중규모 | 3종 중 2~3마리 | 난이도 살짝 상승 |
-| 4 (최종) | 중규모 | 3종 중 2~3마리 | 스테이지 종결 전투 |
-
-**반복 방지**:
-- 각 서브맵 랜덤 풀에서 재선택 → 매 판 조합 변경
-- 3종에서 2마리 선택 = 3가지 + 1마리 = 3가지 → 서브맵당 6가지 조합 경우의 수
-- 4 서브맵 전체 = 최대 **6⁴ = 1,296 경우의 수**
-
-#### §3-1-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 판정 기준 | 재미 축 |
-|------|-----|---------|--------|
-| 슬롯2 | **N1 빗맞힘 절제** | 스테이지 전체 빗맞힘 ≤ 임계 | "적을 정확히 맞추는 기본 감각" 학습 |
-| 슬롯3 | **C3 고 HP 완주** | 종료 시 HP ≥ MaxHP × 70% | "피격 회피 + 쉴드 관리 기본 체력 유지" |
-
-**배치 사유**:
-- Stage1_1 = "전투 기초 2축 학습" · N1(정확도) + C3(생존)
-- P17 전수 회피:
-  - C1·C3 동시 아님 (C1 미배치) ✓
-  - C6·N4 아님 ✓
-  - N5·N6 아님 ✓
-  - C2·N2 아님 ✓
-  - C9·단독 보스 아님 (보스 없음) ✓
-  - N3 미배치 ✓
-
-#### §3-1-5. P17 체크 시트
-```
-[Stage1_1] 슬롯 2: N1 · 슬롯 3: C3
-  #1 C2∧N2:      [O] 미해당
-  #2 C6∧물약유도: [O] 미해당 (조건 풀 부재)
-  #3 C6∧N4:      [O] 미해당
-  #4 C1∧C3:      [O] 미해당 (C1 미배치)
-  #5 C9∧단독보스: [O] 미해당 (C9 미배치)
-  #6 N3 (입문):   [O] 미해당
-  #7 N5∧N6:      [O] 미해당
-  [최종 판정]     [O] 통과
-```
-
----
-
-### §3-2. Stage1_2 — "첫 보스 · 놀아처1"
-
-#### §3-2-1. 목표 정의
-- **위치**: 지역 1 · 첫 보스 스테이지
-- **목표 난이도**: ★1 92% · ★2 60%→85% · ★3 33%→62%
-- **재미 포지션**: "첫 보스 조우 · 원거리 보스 대응 감각"
-- **플레이어 예상**: Lv.1~2 · 카드 1~2장
-
-#### §3-2-2. 등장 몬스터 (실측: 그룹 10102 + 보스 10001)
-
-| 몬스터 ID | 역할 | 분류 |
-|-----------|------|------|
-| **10001 (놀아처1)** | **고정 보스** | Boss_Range · HP 20 · Shield 15 · DPS 2.45 |
-| 14001 | 랜덤 풀 | 수인형 저레벨 (Stage1_1 계승) |
-| 14013 | 랜덤 풀 | 마법생물 저레벨 |
-| 14014 | 랜덤 풀 | 신규 추가 (변화 요소) |
-| 11007 | 랜덤 풀 | 인간형 첫 등장 (종족 전환 시작) |
-
-#### §3-2-3. 노드별 전투 구성
-
-| 서브맵 | 전투 규모 | 몬스터 구성 | 특이사항 |
-|--------|---------|-----------|---------|
-| 1 | 소규모 | 14001·14013·14014·11007 중 1~2마리 | 첫 서브맵 · 11007 등장 확률 50% (인간형 예고) |
-| 2 | 중규모 | 4종 중 2마리 | 보스 서브맵 직전 경고 전투 |
-| 3 (보스) | **보스** | **놀아처1 + 수인형 1마리 호위** (14001 또는 14013) | 원거리 보스 + 근접 호위 조합 학습 |
-| 4 (최종) | 중규모 | 4종 중 2~3마리 | 보스 후 잔여 정리전 |
-
-**근접/원거리 매칭**:
-- 놀아처1 = **원거리 보스** → 플레이어는 "근거리 접근 + 보호막 돌파" 학습
-- 호위 수인형 = 근접 → 보스 원거리 + 호위 근접 이원 대응
-
-**고정**: Stage1_2의 **서브맵 3 = 놀아처1 고정 배치** (PD 고려사항 2 "고정+랜덤")
-
-#### §3-2-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 재미 축 |
-|------|-----|--------|
-| 슬롯2 | **N5 후열 선공** | 원거리 보스를 먼저 타겟팅하는 전략 학습 (놀아처1이 후열 가정) |
-| 슬롯3 | **C6 포션 절제** | 회복 물약 미사용으로 클리어 · 보스 대응 기본기 + 자원 관리 학습 |
-
-**배치 사유**:
-- 첫 보스 스테이지 = "타겟팅 우선순위 학습" 중심
-- C6는 힐 외 빌드(공격·쉴드) 유도 → 놀아처1의 Shield 15 돌파에 공격 빌드 유리
-- P17 전수 회피:
-  - C6·N4 동시 아님 (N4 미배치) ✓
-  - C6·물약유도 아님 (조건 풀 부재) ✓
-  - N5·N6 아님 (N6 미배치) ✓
-
-#### §3-2-5. P17 체크 시트
-```
-[Stage1_2] 슬롯 2: N5 · 슬롯 3: C6
-  #1 C2∧N2:      [O] 미해당
-  #2 C6∧물약유도: [O] 미해당
-  #3 C6∧N4:      [O] 미해당 (N4 미배치)
-  #4 C1∧C3:      [O] 미해당
-  #5 C9∧단독보스: [O] 미해당 (C9 미배치)
-  #6 N3 (입문):   [O] 미해당
-  #7 N5∧N6:      [O] 미해당 (N6 미배치)
-  [최종 판정]     [O] 통과
-```
-
----
-
-### §3-3. Stage1_3 — "종족 전환 · 인간형 본격 등장"
-
-#### §3-3-1. 목표 정의
-- **위치**: 지역 1 · 3번째 스테이지 (보스 없음 · 일반전 심화)
-- **목표 난이도**: ★1 88% · ★2 55%→80% · ★3 28%→57%
-- **재미 포지션**: "종족 전환 체험 + 다양한 조합 대응 심화"
-- **플레이어 예상**: Lv.2 · 카드 2장
-
-#### §3-3-2. 등장 몬스터 (실측: 그룹 10103)
-
-| 몬스터 ID | 역할 |
-|-----------|------|
-| 14014 | 랜덤 풀 (Stage1_2 계승) |
-| **11001** | 인간형 등장 (신규 축) |
-| **11002** | 인간형 등장 (신규 축) |
-| 11007 | 랜덤 풀 |
-
-**4종 풀 · 보스 없음 · 인간형 3종 본격 등장**.
-
-#### §3-3-3. 노드별 전투 구성
-
-| 서브맵 | 전투 규모 | 몬스터 구성 | 특이사항 |
-|--------|---------|-----------|---------|
-| 1 | 소규모 | 11001·11002 1~2마리 | 인간형 본격 첫 조우 |
-| 2 | 중규모 | 4종 중 2마리 | 혼합 대응 |
-| 3 | 중규모 | 4종 중 2~3마리 | 난이도 상승 |
-| 4 (최종) | 대규모 | 4종 중 3~4마리 | 스테이지 종결 · 인원수 압박 |
-
-**반복 방지**: 4종 중 2~3마리 랜덤 → 각 서브맵 최대 14가지 조합 → 4 서브맵 = 약 38,000가지 조합
-
-#### §3-3-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 재미 축 |
-|------|-----|--------|
-| 슬롯2 | **N6 전열 선공** | 근접 인간형(11001·11002) 우선 처리 전략. N5의 축 반대 체험 |
-| 슬롯3 | **C12 각성 최소 사용** | 각성 스킬 적게 사용 클리어 · 기본 공격 중심 빌드 유도 |
-
-**배치 사유**:
-- Stage1_2에서 N5(후열) 학습 → Stage1_3에서 N6(전열)로 **타겟팅 양축 체험** (P17-7 회피: Stage마다 배타)
-- C12 각성 절제는 "기본기 중심 플레이" 유도 · 각성 미보유 플레이어도 달성 가능 (Stage1_3 = 각성 미보유 가정)
-- P17 전수 회피:
-  - N5·N6 동시 아님 (Stage1_3만 N6) ✓
-
-#### §3-3-5. P17 체크 시트
-```
-[Stage1_3] 슬롯 2: N6 · 슬롯 3: C12
-  #1 C2∧N2:      [O] 미해당
-  #2 C6∧물약유도: [O] 미해당
-  #3 C6∧N4:      [O] 미해당
-  #4 C1∧C3:      [O] 미해당
-  #5 C9∧단독보스: [O] 미해당
-  #6 N3 (입문):   [O] 미해당
-  #7 N5∧N6:      [O] 미해당 (본 스테이지 N5 미배치)
-  [최종 판정]     [O] 통과
-```
-
----
-
-### §3-4. Stage1_4 — "지역 종결 · 놀강도2"
-
-#### §3-4-1. 목표 정의
-- **위치**: 지역 1 · 최종 스테이지
-- **목표 난이도**: ★1 82% · ★2 45%→72% · ★3 22%→50%
-- **재미 포지션**: "근접 보스 체험 · 광포화 상태 대응 · 지역 1 종결 임팩트"
-- **플레이어 예상**: Lv.2~3 · 각성 1단계 · 카드 2~3장
-
-#### §3-4-2. 등장 몬스터 (실측: 그룹 10104 + 보스 10002)
-
-| 몬스터 ID | 역할 | 특성 |
-|-----------|------|------|
-| **10002 (놀강도2)** | **고정 최종 보스** | Boss_Melee · HP 30 · Shield 22 · DPS 3.91 · **광포화-신속화 50%** |
-| 11001·11002 | 랜덤 풀 | 인간형 (Stage1_3 계승) |
-| 11007 | 랜덤 풀 | 인간형 |
-| **14003** | 랜덤 풀 | 수인형 중급 (Stage1_4만 등장 · 난이도 신규) |
-| **11003** | 랜덤 풀 | 인간형 중급 (Stage1_4만 등장 · 난이도 신규) |
-
-**5종 풀 · 지역 1 최종 난이도**.
-
-#### §3-4-3. 노드별 전투 구성
-
-| 서브맵 | 전투 규모 | 몬스터 구성 | 특이사항 |
-|--------|---------|-----------|---------|
-| 1 | 중규모 | 5종 중 2마리 | 새로운 몬스터 소개 (14003·11003 등장 확률 40%) |
-| 2 | 중규모 | 5종 중 2~3마리 | 조합 다양화 |
-| 3 | 대규모 | 5종 중 3~4마리 | 보스 직전 인원수 압박 |
-| 4 (보스 최종) | **보스 단독** | **놀강도2 단독** | 광포화 상태 대응 · 1:1 긴장감 극대화 |
-
-**근접/원거리 매칭**:
-- 놀강도2 = **근접 광포화 보스** → 플레이어는 "킬링 속도 + 쉴드 관리" 학습
-- 랜덤 풀의 인간형 = 대부분 근접 · 14003 = 수인형 중급(원거리 가능성)
-
-**고정**: Stage1_4 서브맵 4 = 놀강도2 단독 최종 전투 (지역 1 클라이맥스)
-
-#### §3-4-4. ★ 조건 배치
-
-| 슬롯 | 조건 | 재미 축 |
-|------|-----|--------|
-| 슬롯2 | **C1 신속 클리어** | 광포화 놀강도2의 장기전 불리 · 빠른 킬 유도 |
-| 슬롯3 | **N4 쉴드 보존** | 쉴드 관리로 광포화 대응 · 지역 2 Shield 보스 대비 학습 |
-
-**배치 사유**:
-- 지역 1 최종 = "속도 + 자원 관리" 이원 도전
-- C1과 C3 동시 아님 (P17-4 회피) · C3는 Stage1_1에서 이미 학습
-- P17 전수 회피:
-  - C1·C3 동시 아님 (C3 미배치) ✓
-  - C6·N4 동시 아님 (C6 미배치) ✓
-  - N5·N6 아님 ✓
-
-#### §3-4-5. P17 체크 시트
-```
-[Stage1_4] 슬롯 2: C1 · 슬롯 3: N4
-  #1 C2∧N2:      [O] 미해당
-  #2 C6∧물약유도: [O] 미해당
-  #3 C6∧N4:      [O] 미해당 (C6 미배치)
-  #4 C1∧C3:      [O] 미해당 (C3 미배치)
-  #5 C9∧단독보스: [O] 미해당 (C9 미배치 · 단, 본 스테이지는 최종이 단독 보스이므로 C9 배치 시 위반)
-  #6 N3 (입문):   [O] 미해당
-  #7 N5∧N6:      [O] 미해당
-  [최종 판정]     [O] 통과
-```
-
----
-
-## §4. 지역 1 통합 검증
-
-### §4-1. ★ 조건 배치 요약
-
-| 스테이지 | 슬롯2 | 슬롯3 | 재미 축 |
-|---------|------|------|--------|
-| Stage1_1 | N1 (빗맞힘 절제) | C3 (고 HP 완주) | 정확도 + 생존 |
-| Stage1_2 | N5 (후열 선공) | C6 (포션 절제) | 타겟팅 + 자원 관리 |
-| Stage1_3 | N6 (전열 선공) | C12 (각성 절제) | 타겟팅 반대 + 기본기 |
-| Stage1_4 | C1 (신속) | N4 (쉴드 보존) | 속도 + 자원 관리 |
-
-**조건 다양성**: 8 슬롯 = 7종 조건 사용 (C1·C3·C6·C12·N1·N4·N5·N6) · 중복 없음 · **12종 풀 중 7종(58%) 활용**
-
-### §4-2. 반복 방지 다양성 지표 (정량)
-
-| 스테이지 | 몬스터 조합 경우의 수 (4 서브맵 기준) |
-|---------|------------------------------------|
-| Stage1_1 | 1,296가지 |
-| Stage1_2 | 2,400가지 (보스 서브맵 호위 2종 × 일반 2 서브맵) |
-| Stage1_3 | ~38,000가지 |
-| Stage1_4 | ~42,000가지 (5종 풀) |
-
-**지역 1 전체**: 약 **5조 가지 이상 조합** (스테이지 간 독립 → 곱셈)
-
-### §4-3. TTK 검증 (DPS 기준)
-
-| 스테이지 | 예상 DPS | 주요 대상 내구도 | TTK 추정 |
-|---------|---------|---------------|---------|
-| Stage1_1 | 1.05~1.10 | 일반 몬스터 2~3 (HP 2~5) × 4 서브맵 ≈ 24~60 | 25~60s |
-| Stage1_2 | 1.10~1.20 | 놀아처1 HP 35(+Shield) + 일반 ≈ 70 | 60~70s |
-| Stage1_3 | 1.20~1.30 | 일반 인간형 2~3 × 4 서브맵 ≈ 40~80 | 35~70s |
-| Stage1_4 | 1.20~1.35 | 놀강도2 HP 52(+Shield) + 일반 ≈ 100 | 75~85s |
-
-**지역 1 전체 TTK 합**: 약 **200~290초** (★1 클리어 가정 + 피격 감수)
-
-### §4-4. 배타 7종 지역 1 통합 검증
-
-```
-지역 1 (Stage1_1~1_4) 8 슬롯 배치 × 7 배타 조합 = 56 체크 수행
-결과: 56/56 통과 ✓
-```
-
----
-
-## §5. ToolData.json 생성 준비 (PD 지시 5 사전 준비)
-
-### §5-1. 생성 대상 데이터 (지역 1 한정)
-
-ToolData.json에 반영되어야 할 **지역 1 기획 결정 수치**:
-
-```json
-{
-  "region_id": 1,
-  "stage_count": 4,
-  "stages": [
-    {
-      "map_config_id": "Stage1_1",
-      "stage_type": 1,
-      "appear_monster_group": 10101,
-      "appear_boss_group": 0,
-      "monster_pool": [14001, 14002, 14013],
-      "boss_fixed": null,
-      "submaps_design": {
-        "count_range": [4, 6],
-        "composition": [
-          {"index": 1, "scale": "small", "monster_count_range": [1, 2]},
-          {"index": 2, "scale": "small", "monster_count_range": [2, 2]},
-          {"index": 3, "scale": "medium", "monster_count_range": [2, 3]},
-          {"index": 4, "scale": "medium", "monster_count_range": [2, 3], "is_final": true}
-        ]
-      },
-      "star_conditions": {
-        "slot1": "default_clear",
-        "slot2": "N1",
-        "slot3": "C3"
-      },
-      "target_clear_rate": {
-        "star1": 0.97,
-        "star2_first": 0.70, "star2_repeated": 0.90,
-        "star3_first": 0.40, "star3_repeated": 0.70
-      }
-    },
-    {
-      "map_config_id": "Stage1_2",
-      "stage_type": 1,
-      "appear_monster_group": 10102,
-      "appear_boss_group": 10001,
-      "monster_pool": [14001, 14013, 14014, 11007],
-      "boss_fixed": {
-        "monster_id": 10001,
-        "name_ref": "놀아처1",
-        "fixed_submap": 3
-      },
-      "submaps_design": {
-        "count_range": [4, 6],
-        "composition": [
-          {"index": 1, "scale": "small", "monster_count_range": [1, 2]},
-          {"index": 2, "scale": "medium", "monster_count_range": [2, 2]},
-          {"index": 3, "scale": "boss", "boss": 10001, "escort_count_range": [1, 1]},
-          {"index": 4, "scale": "medium", "monster_count_range": [2, 3], "is_final": true}
-        ]
-      },
-      "star_conditions": {
-        "slot1": "default_clear",
-        "slot2": "N5",
-        "slot3": "C6"
-      },
-      "target_clear_rate": {
-        "star1": 0.92,
-        "star2_first": 0.60, "star2_repeated": 0.85,
-        "star3_first": 0.33, "star3_repeated": 0.62
-      }
-    },
-    {
-      "map_config_id": "Stage1_3",
-      "stage_type": 1,
-      "appear_monster_group": 10103,
-      "appear_boss_group": 0,
-      "monster_pool": [14014, 11001, 11002, 11007],
-      "boss_fixed": null,
-      "submaps_design": {
-        "count_range": [4, 6],
-        "composition": [
-          {"index": 1, "scale": "small", "monster_count_range": [1, 2]},
-          {"index": 2, "scale": "medium", "monster_count_range": [2, 2]},
-          {"index": 3, "scale": "medium", "monster_count_range": [2, 3]},
-          {"index": 4, "scale": "large", "monster_count_range": [3, 4], "is_final": true}
-        ]
-      },
-      "star_conditions": {
-        "slot1": "default_clear",
-        "slot2": "N6",
-        "slot3": "C12"
-      },
-      "target_clear_rate": {
-        "star1": 0.88,
-        "star2_first": 0.55, "star2_repeated": 0.80,
-        "star3_first": 0.28, "star3_repeated": 0.57
-      }
-    },
-    {
-      "map_config_id": "Stage1_4",
-      "stage_type": 1,
-      "appear_monster_group": 10104,
-      "appear_boss_group": 10002,
-      "monster_pool": [11001, 11002, 11007, 14003, 11003],
-      "boss_fixed": {
-        "monster_id": 10002,
-        "name_ref": "놀강도2",
-        "fixed_submap": 4,
-        "is_solo": true
-      },
-      "submaps_design": {
-        "count_range": [4, 6],
-        "composition": [
-          {"index": 1, "scale": "medium", "monster_count_range": [2, 2]},
-          {"index": 2, "scale": "medium", "monster_count_range": [2, 3]},
-          {"index": 3, "scale": "large", "monster_count_range": [3, 4]},
-          {"index": 4, "scale": "boss_solo", "boss": 10002, "is_final": true}
-        ]
-      },
-      "star_conditions": {
-        "slot1": "default_clear",
-        "slot2": "C1",
-        "slot3": "N4"
-      },
-      "target_clear_rate": {
-        "star1": 0.82,
-        "star2_first": 0.45, "star2_repeated": 0.72,
-        "star3_first": 0.22, "star3_repeated": 0.50
-      }
-    }
-  ]
-}
-```
-
-### §5-2. 본 JSON의 한계
-
-**본 JSON 초안은 기획 의도 기반 초안**이며 다음 단계가 필요:
-1. **PD 검증** (본 v2 승인)
-2. **개발팀 스키마 검토** — `ToolData.json` 실제 스키마와 필드명·구조 정합성 조율
-3. **Unity MCP 시뮬 선행** — Stage1_4 놀강도2 단독 전투 TTK 실측 (광포화 상태 DPS 변동 확인)
-4. **최종 ToolData.json 생성** — 개발팀 담당 (기획팀 산출물 → 개발팀 변환)
-
-### §5-3. 누락 정보 (개발팀 확인 필요)
-
-- `n_AppearBossGroup` 필드가 **그룹 ID**인지 **몬스터 ID 직접 참조**인지 명확화 (실측 상 후자로 보이나 필드명 혼선)
-- `monster_pool` 내 몬스터가 서브맵별 등장 확률을 어떻게 분배하는지 (`n_AppearRate` 현재 모두 100)
-- ToolData.json의 실제 스키마 (개발팀 공유 필요)
-
----
-
-## §6. 기각안
-
-### §6-1. 기각안 A: v1의 Stage 2~6 설계 전체 재활용
-- **기각 사유**: Stage 2~6은 지역 2·3·4의 일부이므로 "지역 1 v2"에 편입 불가. 별도 지역별 v2 작성 시 재검토 대상
-- **대체**: 본 v2는 지역 1(Stage1_1~1_4)에만 집중 · Stage 2~6 설계는 지역 2·3·4 각각 집행 시 승계 가능
-
-### §6-2. 기각안 B: 보스 없는 Stage1_1·1_3에 ★ 조건을 보스 의존으로 배치
-- **기각 사유**: Stage1_1·1_3은 보스 미등장 → C9(보스 집중) P17-5 위반. 보스 없이도 달성 가능한 조건만 배치
-- **대체**: N1·C3·N6·C12 = 보스 독립 조건 배치
-
-### §6-3. 기각안 C: 지역 1에 12종 조건 풀 전수 사용
-- **기각 사유**: 입문 4 스테이지 × 2 슬롯 = 8 슬롯. 전수(12종) 사용은 조건당 1회 이하로 변별력 약화
-- **대체**: 7종 사용 (58%) · 나머지 5종(C2·C9·N2·N3·(?))은 지역 2~4에서 본격 도입
-
-### §6-4. 기각안 D: ToolData.json을 기획팀이 직접 최종 생성
-- **기각 사유**: ToolData.json 스키마·Unity 연동은 개발팀 영역. 기획팀은 **초안 제공 + 개발팀 변환** 핸드오프 구조
-- **대체**: 본 §5에 초안 제공 + PD 검증 후 개발팀 Task 이관
-
----
-
-## §7. 참고 문서
-
-- 데이터 실측 SOT: `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md`
-- 기획팀 룰: `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md`
-- 조건 풀: `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md`
-- 배타 규칙: SKILL.md P17
-- 폐기 v1: `프로젝트/수상한잡화점/기획/Phase4_지역1_노드구성_v1.md` (🔴 아카이브)
-- Unity Export 경로: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/`
-
----
-
-## §8. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|----------|----------------|----------|--------------|
-| 2026-04-20 | 기획팀장 | 전체 신설 (v2) | v1 (지역 1 = 6) → v2 (지역 1 = 4) | PD 확정 구조 준수 · 입문 초입 재미 재구성 | #44 |
diff --git a/프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md b/프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md
deleted file mode 100644
index c87e3b7..0000000
--- a/프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-type: 기획팀 내부 룰 (수상한잡화점 프로젝트 한정)
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD 재발 방지 지시 #43 수용)
-관련PD지시: 기획팀 #43 · PD 2026-04-20 "기획팀 내 룰 신설 — PD 의도 벗어난 작업 재발 방지"
-상태: **v1 초안 · PM 검토 → PD 승인 후 발효**
-적용 범위: 기획팀 전원 (기획팀장 · 시스템 · 컨텐츠 · 레벨 · 시나리오 · 밸런스 · UX)
-C36 분류: **구현·실무 수준 룰** (조직 코어룰 수정 아님)
----
-
-# 기획팀 — 데이터 실측·PD 의도 준수 의무 v1
-
-## §0. 본 룰의 존재 이유
-
-2026-04-20 PD 재발 방지 지시 5종 중 #43 이행. 기획팀이 **"WorldMap 4그룹"** 같은 전제·추측을 데이터 실측 없이 장기간 SOT화하여 Phase 4 지역 1 노드 구성 전체를 **잘못된 구조(Stage 1~6 = 지역 1)** 로 진행한 사건을 구조적으로 차단.
-
-**본 룰을 지키지 않으면 PD 의도를 벗어난 산출물이 대량 생성되고, 재작업 비용이 조직 전체에 전가된다.**
-
----
-
-## §1. 5대 의무 조항
-
-### §1-1. 데이터 구조 실측 의무
-
-**기획팀 모든 에이전트는 데이터 테이블을 참조하는 기획 작업 착수 전, Unity Export CSV/JSON 실측을 선행한다.**
-
-- 기존 기획 문서의 수치·구조를 **무비판 수용 금지** (전재 SOT 확립 선행 필수)
-- 추측·전제·이름 기반 추정 금지 (예: "WorldMap이라는 이름이 있으니 4개 그룹이겠지")
-- 실측 방법:
-  1. **Unity Export 경로**: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/` (PC별 상이 — `paths.local.json` 등록)
-  2. **Read 도구로 CSV/JSON 직접 읽기** (추측 금지, 눈으로 확인)
-  3. **레코드 수·필드 구조 명시적 기록** (기획 문서 "근거" 섹션에 기입)
-- **위반 시**: 본 사건 같은 전면 재작업. 기획팀장 재량 판단 실패로 간주
-
-### §1-2. PD 용어 정의 엄격 준수 의무
-
-**PD가 확정한 용어는 기획팀 전원이 **일관 사용**한다 (C22 용어 일관 확장).**
-
-- **본 프로젝트 확정 용어 (SOT)**:
-  - **월드맵**: 21개 구역 구성 (`WorldMapConfig.n_StageID`)
-  - **구역 / 지역**: WorldMap의 각 지역 (= Stage 1~21)
-  - **스테이지**: 지역 내 각 맵 (Stage1_1·1_2 등, `CreateMapConfig.s_MapConfigID`)
-  - **서브맵**: 스테이지 내 노드 (런타임 생성)
-- **금지 용어** (본 사건 계기):
-  - "WorldMap_1·2·3·4 4개 그룹" → **데이터 구조 아님 · 사용 금지**
-  - "WM1~WM4" → 동일
-  - "입문/초반/중반/후반 구간" → **기획 레이블만 별도 명시** (데이터 구조 아님)
-- **용어 혼선 발견 즉시 정정** + 다른 에이전트 대화로그에도 공유
-
-### §1-3. PD 의도 확인 절차 의무
-
-**확실하지 않은 것은 추측하지 않고 PD에게 확인한다.**
-
-#### §1-3-1. 3단계 확인 절차
-1. **기획팀 내부 논의** — 해당 영역 전문 에이전트 + 기획팀장 자체 논의로 결론 도출 시도
-2. **PM 조율** — 팀 내 결론 안 나면 PM에게 조율 요청 (C29-1 단계 2)
-3. **PD 에스컬레이션** — PM까지 불확실하면 PD 질의 (C29-1 단계 3의 예외)
-
-#### §1-3-2. 금지 행위
-- **추측으로 결정 진행** — "아마 이런 의미겠지" 금지
-- **기존 문서에 쓰여있다는 이유로 무비판 수용** — §1-1 실측 의무 위반
-- **"확인 안 해본 사항"을 가정하여 진행** — C10-5 위반
-
-#### §1-3-3. PD 질의 시 포함 의무
-- 현 기획팀 이해 요약 (1~2줄)
-- 불확실 지점 명시 (A안 vs B안)
-- 기획팀 권장안 + 사유
-
-### §1-4. 기존 SOT 맹신 금지 의무
-
-**이전 기획 문서의 수치·구조를 "SOT"로 부르더라도 항상 실측과 교차 검증한다.**
-
-#### §1-4-1. 실증 사건 (본 룰 신설 근거)
-- `스테이지난이도곡선_v1.md §1` "WorldMap_1~4 4개 그룹" → 다수 후속 문서가 무비판 인용
-- `Phase3_종결_설계체계_v1.md`·`Phase4_노드구성_착수가이드_v1.md` → 같은 오해 계승
-- `Phase4_지역1_노드구성_v1.md` → Stage 1~6 = 지역 1 = 6개로 전면 설계 (전면 폐기)
-
-#### §1-4-2. 재발 방지 체크포인트
-모든 기획 문서는 상단에 **"데이터 소스 실측 일시"** 필드 명기:
-```
-데이터 소스: CreateMapConfig.csv (실측 2026-04-20) · MonsterList.csv (실측 2026-04-20)
-```
-
-실측 일시 미기입 문서는 **참조 금지**. 참조 시 실측 재수행.
-
-### §1-5. 기획 문서 재사용 시 선행 검증 의무
-
-**기존 기획 문서를 인용·확장·발전시킬 때, §1-1 실측 + §1-4 교차 검증을 선행한다.**
-
-- 이전 버전의 구조·수치·용어를 **100% 재확인** (§1-1 실측 결과와 대조)
-- 불일치 발견 시 **해당 문서 정정 안건 PM 보고** (본 작업 완료 후 별도 후속 지시로 집행)
-- 기존 문서 전제를 자기 산출물 근거로 삼았다가 해당 전제가 틀릴 경우 **자기 산출물도 전면 재작성** (본 사건 실증)
-
----
-
-## §2. 처분 · 재발 방지
-
-### §2-1. 1회 발견
-- **즉시 자진 고지** + 본 룰 §N 재확인
-- 관련 산출물 정정 또는 재작성
-- 대화로그에 "데이터 실측 의무 위반" 엔트리 기록
-
-### §2-2. 반복 발생 시
-- **본 사건 같은 대규모 재작업 유발 위반** → 기획팀장 역할 재검토 자진 상정
-- 3회차 재발 시 **기획팀 전체 프로세스 점검** PM 요청
-
-### §2-3. 은폐 적발
-- C3 이슈 은폐 금지 위반 + C23 허위 보고 결합
-- 은폐 기간 내 모든 산출물 재검증
-
----
-
-## §3. 타 규칙과의 관계
-
-- **C22** 용어 일관 — §1-2는 C22의 기획팀 특화
-- **C23** 허위 보고 금지 — §1-3·§1-4는 C23의 기획 실무 확장
-- **C10-5** 선행 검증 — §1-1은 C10-5의 강화판 (Unity Export 실측 의무)
-- **P30** 재미 우선 — 본 룰 준수 전제 위에서 P30 적용
-- **P16** 산출물 추적성 — §1-4 "실측 일시" 기입으로 P16 강화
-
----
-
-## §4. 실행 예시
-
-### §4-1. 좋은 예시 (§1 준수)
-```
-## §N. 지역 1 노드 구성
-
-데이터 소스: CreateMapConfig.csv (실측 2026-04-20 15:30)
-
-지역 1 = Stage1_1·Stage1_2·Stage1_3·Stage1_4 = 4개 스테이지 (실측 확인).
-
-- Stage1_1: n_AppearMonsterGroup=10101, n_AppearBossGroup=0 (보스 없음)
-- Stage1_2: n_AppearMonsterGroup=10102, n_AppearBossGroup=10001 (놀아처1)
-...
-```
-
-### §4-2. 나쁜 예시 (본 사건 실측 패턴)
-```
-## §N. 지역 1 노드 구성
-
-WorldMap_1 = Stage 1~6 (이전 문서 참조)
-
-- Stage 1: 서브맵 4개, 보스 2마리 (놀아처1, 놀강도2)
-- Stage 2: 서브맵 6개, 보스 3마리 (...)
-...
-```
-→ "WorldMap_1" 용어·6개 가정 모두 **실측 없이 전제** — §1-1·§1-2 위반
-
----
-
-## §5. 기각안
-
-### §5-1. 기각안 A: 조직 코어룰(C)로 신설
-- **기각 사유**: C36 판정 기준 3종 미해당 (구현·실무 수준). 조직 전체가 아닌 **기획팀 특화 룰**
-- **대체**: 기획팀 프로젝트 룰(본 문서)로 유지
-
-### §5-2. 기각안 B: 기획팀 전체 공통 룰 (본 프로젝트 외에도 적용)
-- **기각 사유**: Unity Export 경로는 본 프로젝트 전용. 차기 프로젝트에 다른 데이터 체계 도입 시 본 룰 재검토 필요
-- **대체**: 본 프로젝트 전용으로 확정. 차기 프로젝트 착수 시 유사 룰 재작성
-
-### §5-3. 기각안 C: 세부 체크리스트 형태 (예: "CSV 몇 줄 이상 읽어야 함" 등)
-- **기각 사유**: 과도한 경직성. 기획 작업 유연성 훼손. "실측 의무"라는 원칙 수준이 충분
-- **대체**: 원칙 + 실행 예시 (§4) 제공
-
----
-
-## §6. 참고 문서
-
-- 본 룰 신설 근거 사건 실측: `프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md` §7
-- PD 용어 정의 SOT: 위 문서 §1
-- 조직 코어룰: SKILL.md C22 용어 일관 · C23 허위 보고 금지 · C10-5 선행 검증
-- 프로젝트 룰: SKILL.md P16 산출물 추적성 · P30 재미 우선
-
----
-
-## §7. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|----------|----------------|----------|--------------|
-| 2026-04-20 | 기획팀장 | 전체 신설 | (없음) → v1 초안 | PD 의도 벗어난 기획으로 인한 재미 훼손 차단 | #43 |
diff --git a/프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md b/프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md
deleted file mode 100644
index ae34b32..0000000
--- a/프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-type: 현황테이블
-작성일: 2026-04-20
-작성자: 기획팀장 (레벨기획자 관점 반영)
-관련PD지시: 기획팀 #40 후속 PM 재량 E-2
-선행산출물: 맵패턴_사전분석_v1.md (2026-04-14 / 2026-04-18 최신화), 3성조건_12개_상세명세_v1.md (2026-04-18 최신화)
-상태: 확정 (Day 11~14 트랙 B 착수 시 즉시 활용)
-범위: 42개 슬롯(21스테이지 × 슬롯2·슬롯3) × P17 배타 7종 매핑 **현황 테이블**. **실 배치 확정은 Phase 3 재개 후 Unity MCP 시뮬 검증 후 수행** (본 문서는 검증 틀로 활용)
----
-
-# 맵 패턴 42개 슬롯 현황 테이블 v1
-
-## 0. 본 문서의 역할
-
-Day 11~14 트랙 B (맵 패턴 확정) 착수 시 **5분 이내 P17 배타 7종 전수 체크 가능한 매트릭스**를 제공. `맵패턴_사전분석_v1.md §3-3`의 42 슬롯 검증 체크리스트 템플릿을 **전 스테이지에 적용한 현황 스냅샷**이다. 원본 사전분석은 **변경하지 않는다** (PD 승인 범위 엄수).
-
-**중요 주의사항**:
-- 본 테이블의 **"권장 후보" 조건은 현 단계 감 기반 프레임**. 실 배치 확정은 Unity MCP 시뮬 실측 후
-- **PD 3차 승인 조건 풀 12개**(`3성조건_12개_상세명세_v1.md`) 기준으로 작성. 신규 조건 추가 금지
-- **P17 배타 조합 7종**(SKILL.md P17)을 전수 체크하되, **위반 후보 차단** 우선
-
----
-
-## 1. 스테이지별 구조 요약 (권장 후보 판정 기반)
-
-`스테이지난이도곡선_v1.md §2` + `맵패턴_사전분석_v1.md §1` 통합.
-
-| Stage | WM | 구간 | 서브맵수 | 보스수 | C9 적합도 (§1-4) | 입문 C1∧C3 금지 (§P17-4) | 입문 N3 금지 (§P17-6) |
-|-------|----|------|---------|--------|-----------------|------------------------|---------------------|
-| 1 | WM1 | 입문 | 4 | 2 | △ 비권장 | **적용** | **적용** |
-| 2 | WM1 | 입문 | 6 | 3 | △ 비권장 | **적용** | **적용** |
-| 3 | WM1 | 입문 | 5 | 2 | △ 비권장 | **적용** | **적용** |
-| 4 | WM1 | 입문 | 7 | 3 | △ 가능 | **적용** | **적용** |
-| 5 | WM1 | 입문 | 6 | 2 | △ 가능 | **적용** | **적용** |
-| 6 | WM1 | 입문 | 7 | 2 | △ 가능 | **적용** | **적용** |
-| 7 | WM2 | 중반전환 | 4 | 1 | **X 금지 (단독 보스)** | 해제 | 해제 |
-| 8 | WM2 | 중반전환 | 5 | 2 | O 권장 | 해제 | 해제 |
-| 9 | WM2 | 중반전환 | 6 | 2 | O 권장 | 해제 | 해제 |
-| 10 | WM2 | 중반심화 | 5 | 1 | **X 금지 (단독 보스)** | 해제 | 해제 |
-| 11 | WM3 | 중반심화 | 5 | 2 | O 권장 | 해제 | 해제 |
-| 12 | WM3 | 중반심화 | 7 | 3 | O 권장 | 해제 | 해제 |
-| 13 | WM3 | 후반진입 | 4 | 1 | **X 금지 (단독 보스)** | 해제 | 해제 |
-| 14 | WM3 | 후반진입 | 5 | 2 | O 권장 | 해제 | 해제 |
-| 15 | WM3 | 후반진입 | 5 | 2 | O 권장 | 해제 | 해제 |
-| 16 | WM4 | 후반진입 | 3 | 3 | O 권장 | 해제 | 해제 |
-| 17 | WM4 | 후반 | 8 | 2 | O 권장 | 해제 | 해제 |
-| 18 | WM4 | 후반 | 8 | 3 | O 권장 | 해제 | 해제 |
-| 19 | WM4 | 최종 | 9 | 2 | O 권장 | 해제 | 해제 |
-| 20 | WM4 | 최종 | 9 | 3 | O 권장 | 해제 | 해제 |
-| 21 | WM4 | 최종 | 4 | 2 | O 권장 | 해제 | 해제 |
-
----
-
-## 2. P17 배타 조합 7종 × 42 슬롯 전수 매핑
-
-**매핑 원칙**: 각 스테이지의 슬롯2·슬롯3에 **배치 가능한 조건 후보**를 제시. P17-1~P17-7 위반 조합은 **동시 배치 금지** 명시.
-
-**조건 풀 12개** (3성조건_12개_상세명세_v1): C1 신속 · C2 완벽 클리어 · C3 고HP 완주 · C6 포션 절제 · C9 보스 집중 · C12 회피 주도 / N1 빗맞힘 절제 · N2 피격 제한 · N3 치명타 처치 · N4 쉴드 보존 · N5 후열 선공 · N6 전열 선공
-
-### 2-1. 입문 구간 (Stage 1~6) — C1∧C3·N3 제약 적용
-
-| Stage | 슬롯2 가능 후보 | 슬롯3 가능 후보 | 동시 배치 금지 조합 |
-|-------|---------------|---------------|-------------------|
-| 1 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | **P17-4** (C1∧C3) · **P17-7** (N5∧N6) · P17-1 (C2∧N2) · P17-3 (C6∧N4) · **P17-6** (N3 단독 금지) · **P17-5** (C9 금지) |
-| 2 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | 상동 |
-| 3 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | 상동 |
-| 4 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | 상동 (+C9 △ 가능하나 단독 보스 서브맵 비율 검증 필수) |
-| 5 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | 상동 |
-| 6 | C1·C3·C6·C12·N1·N2·N4·N5·N6 | 좌동 | 상동 |
-
-**입문 구간 공통 제외**: C2(완벽 클리어 · 입문 난이도 과도) · C9(단독 보스 비율 미확정) · N3(치명타 빌드 미형성)
-
-### 2-2. 중반 (Stage 7~12) — 입문 제약 해제 · C9 선별 적용
-
-| Stage | 슬롯2 가능 후보 | 슬롯3 가능 후보 | 동시 배치 금지 조합 |
-|-------|---------------|---------------|-------------------|
-| 7 | C1·C2·C3·C6·C12·N1·N2·N3·N4·N5·N6 | 좌동 | **P17-5** (C9 금지 · 단독 보스) · P17-1 (C2∧N2) · P17-3 (C6∧N4) · P17-7 (N5∧N6) |
-| 8 | C1·C2·C3·C6·**C9**·C12·N1·N2·N3·N4·N5·N6 (12개 풀) | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-| 9 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-| 10 | C1·C2·C3·C6·C12·N1·N2·N3·N4·N5·N6 | 좌동 | **P17-5** (C9 금지) · P17-1 · P17-3 · P17-7 |
-| 11 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-| 12 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · 보스 3체) |
-
-### 2-3. 후반 (Stage 13~21) — 재도전 유도 난해 조건 배치 가능
-
-| Stage | 슬롯2 가능 후보 | 슬롯3 가능 후보 | 동시 배치 금지 조합 |
-|-------|---------------|---------------|-------------------|
-| 13 | C1·C2·C3·C6·C12·N1·N2·N3·N4·N5·N6 | 좌동 | **P17-5** (C9 금지) · P17-1 · P17-3 · P17-7 |
-| 14 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-| 15 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-| 16 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · 보스 3체 · 서브맵 3) |
-| 17 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · Shield 고스탯 용암골렘2) |
-| 18 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · 보스 3체) |
-| 19 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · 서브맵 9) |
-| 20 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용 · 보스 3체 · 서브맵 9) |
-| 21 | 풀 12개 | 좌동 | P17-1 · P17-3 · P17-7 (C9 허용) |
-
----
-
-## 3. P17 배타 7종 × 스테이지 위반 리스크 매트릭스
-
-**목적**: 실 배치 시 **어떤 배타 조합이 어느 스테이지에 영향을 주는가**를 한눈에 확인.
-
-| P17 # | 배타 조합 | 해당 스테이지 범위 | 대응 방식 |
-|-------|----------|------------------|---------|
-| P17-1 | C2 ∧ N2 (피격 이중 부담) | **전 스테이지 1~21** | 슬롯2·슬롯3에 C2와 N2 **동시 배치 금지** |
-| P17-2 | C6 ∧ 물약 유도 조건 | (조건 풀에 물약 유도 조건 없음) | **비활성** — 현 조건 풀 12개 중 물약 유도 조건 부재. 향후 조건 추가 시 점검 |
-| P17-3 | C6 ∧ N4 (회복 빌드 배제) | **전 스테이지 1~21** | C6과 N4 **동시 배치 금지** |
-| P17-4 | C1 ∧ C3 (입문 이중 부담) | **Stage 1~6 전 슬롯** | 입문 구간 C1·C3 **동시 배치 금지** (중반·후반은 허용) |
-| P17-5 | C9 ∧ 단독 보스·보스 미등장 | **Stage 7·10·13** (단독 보스 3개) · Stage 1·2·3 (입문 △) | 해당 스테이지 슬롯2·슬롯3에 **C9 배치 금지** · 보스 미등장 서브맵 비율 Unity MCP 시뮬 검증 후 최종 확정 |
-| P17-6 | N3 입문 구간 단독 금지 | **Stage 1~6** | 입문 구간에서 N3 **단독 배치 금지** (치명타 빌드 미형성) |
-| P17-7 | N5 ∧ N6 (타겟팅 모순) | **전 스테이지 1~21** | 슬롯2·슬롯3에 N5와 N6 **동시 배치 금지** |
-
----
-
-## 4. 슬롯2·슬롯3 배치 시 필수 확인 (체크리스트 재인용)
-
-**원본**: `맵패턴_사전분석_v1.md §3-3` 42 슬롯 검증 체크리스트 템플릿
-
-실제 배치 확정 시 **각 스테이지마다 이 템플릿 1회 수행**:
-
-```
-[Stage N] 슬롯 배치 검증 시트
------------------------------
-슬롯 2 후보 조건: ___
-슬롯 3 후보 조건: ___
-
-[체크 1] P17 배타 조합 7종
-  #1 C2∧N2:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #2 C6∧물약유도:      [ ] 미해당 / [ ] 위반 / [ ] 무관 (조건 풀에 미존재)
-  #3 C6∧N4:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #4 (1~6)C1∧C3:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #5 C9∧단독보스:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #6 (1~6)N3:         [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #7 N5∧N6:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-
-[체크 2] 구간별 난이도
-  구간: [ ] 입문(1~6) / [ ] 중반(7~12) / [ ] 후반(13~21)
-  조건 난이도 적합: [ ] 적합 / [ ] 과도 / [ ] 부족
-
-[체크 3] 스테이지 특성 정합
-  등장 몬스터 구성과 정합: [ ] OK / [ ] 부정합 (사유:__)
-  C9 배치 시 §1 충족: [ ] 미해당 / [ ] OK / [ ] 위반
-  C6 배치 시 회복 노드 빈도 고려: [ ] 미해당 / [ ] OK / [ ] 재검토
-  N4 배치 시 쉴드 확보 가능성: [ ] 미해당 / [ ] OK / [ ] 재검토
-
-[최종 판정] [ ] 통과 / [ ] 재배치 필요 / [ ] PD님 판단 필요
-```
-
----
-
-## 5. 보스 혼용 등장 패턴 프레임 (사전분석 §2-4 재인용)
-
-**실 배치 시 Unity MCP 시뮬로 검증 필수** · 본 프레임은 **감 기반 가이드**
-
-| Stage | 서브맵 수 | 보스 수 | 권장 보스 등장 서브맵 수 | 권장 혼용 서브맵 수 |
-|-------|----------|--------|------------------------|-------------------|
-| 1 | 4 | 2 | 2 | 1~2 |
-| 2 | 6 | 3 | 3 | 1~2 |
-| 3 | 5 | 2 | 2~3 | 1~2 |
-| 4 | 7 | 3 | 3 | 2 |
-| 5 | 6 | 2 | 2 | 1~2 |
-| 6 | 7 | 2 | 2~3 | 2 |
-| 7 | 4 | 1 | 1~2 | 1 (C9 제외) |
-| 8 | 5 | 2 | 2 | 1~2 |
-| 9 | 6 | 2 | 2~3 | 2 |
-| 10 | 5 | 1 | 1~2 | 1 (C9 제외) |
-| 11 | 5 | 2 | 2 | 1~2 |
-| 12 | 7 | 3 | 3 | 2 |
-| 13 | 4 | 1 | 1~2 | 1 (C9 제외) |
-| 14 | 5 | 2 | 2 | 1~2 |
-| 15 | 5 | 2 | 2 | 1~2 |
-| 16 | 3 | 3 | 2~3 | 1 |
-| 17 | 8 | 2 | 2~3 | 2 |
-| 18 | 8 | 3 | 3 | 2 |
-| 19 | 9 | 2 | 2~3 | 2 |
-| 20 | 9 | 3 | 3 | 2 |
-| 21 | 4 | 2 | 2 | 1 |
-
----
-
-## 6. 선행 제약 확인 매트릭스 (2026-04-20 최신화)
-
-원본 `맵패턴_사전분석_v1.md §3-4`를 **현 시점(2026-04-20) 상태로 업데이트**.
-
-| 선행 조건 | 상태 | 비고 |
-|----------|------|------|
-| 조건 풀 12개 최종 확정 | ✅ **완료** | Phase 2 §5 PD 3차 승인 |
-| N7 방어 성공 조건 포함 여부 | ✅ **실측 완료 (#37)** | PCDefence_Mul=0.3·쿨다운 없음·지속형·Melee/Range 공통·Mob 방어 부재. 조건 풀 13번째 추가 여부는 Phase 3 재개 시 PD 결정 |
-| N8 저 HP 완주 수치 확정 | ⏳ **HOLD** | Phase 3 재개 후 시뮬 튜닝 |
-| 스테이지별 보스 혼용 패턴 확정 | ⏳ **HOLD** | Unity MCP EditMode 시뮬 검증 필수 |
-| 서브맵별 실제 몬스터 배치 추출 | ⏳ **HOLD** | `ApprearMonsterPattern.json` 정밀 재분해 |
-| Unity MCP 시뮬 환경 · 리포트 · 가이드 | ✅ **완료** | 2026-04-20 v2 리포트 · 시뮬실행 가이드 v1 |
-| 개발팀 카드·Shield 시뮬 구현 | ⏳ **HOLD** | Day 8~10 범위 (v2 §6-3 카드 메커닉 시뮬 미구현) |
-
-**결론**: 42개 슬롯 **실 배치 확정은 Day 11~14 트랙 B 범위**. 본 문서는 **Day 11~14 착수 시 바로 §2 매트릭스 참조 + §4 체크리스트 42회 수행**.
-
----
-
-## 7. 사전 식별된 리스크 (Day 11~14 착수 시 주의)
-
-### 7-1. C9 단독 보스 3개 스테이지
-- Stage 7 (메두사1) · Stage 10 (흑기사3) · Stage 13 (레드드래곤3)
-- **C9 절대 배치 금지** · 대체 조건 선별 필요
-- 단독 보스 전용 "재도전 유도 난해 조건" 설계 검토 (예: C2 완벽 클리어 · C6 포션 절제 등)
-
-### 7-2. Stage 16 서브맵 3개 특수성
-- 서브맵 3개 + 보스 3체 → 보스 밀도 극단 높음
-- C9 배치 가능하나 **혼용 서브맵 여지 최소**
-- 보스 단독 서브맵 비율이 자동으로 높아지는 구조 → 다른 스테이지와 체감 편차 우려
-
-### 7-3. Shield 고스탯 보스 스테이지
-- Stage 17 (용암골렘2 Shield 525) · Stage 7/8 (메두사1 Shield 223) · Stage 5 (다크엘프아처1 Shield 282)
-- **N4 쉴드 보존 조건 배치 시** 플레이어 Shield 확보 난이도가 스테이지 난이도와 혼재되어 체감 왜곡 우려
-- Unity MCP 시뮬로 쉴드 상호작용 검증 후 배치 권고
-
-### 7-4. N5 후열·N6 전열 배치 시 몬스터 구성 정합
-- 해당 스테이지의 전열·후열 몬스터 구성과 조건 일치 확인 필수
-- `MonsterPatternList.json` 전/중/대기열 가중치와 조건 정합 체크 (Unity MCP 시뮬 필수)
-
-### 7-5. 보스 재사용 스테이지 반복 체감
-- 흑기사3 (Stage 10·11·12 3회) · 레드드래곤3 (Stage 13·14·16 3회) · 메두사2 (Stage 14·15·16 3회)
-- 동일 보스 반복 시 맵 패턴 다양화로 "다른 경험" 유도 필요 (사전분석 §5-3)
-
----
-
-## 8. 범위 엄수 확인
-
-- 본 문서는 **실 슬롯 배치 확정을 수행하지 않는다** (Day 11~14 범위)
-- 본 문서는 **신규 조건 제안을 포함하지 않는다** (조건 풀 12개 확정 · PD 3차 승인)
-- 본 문서는 **Unity MCP 시뮬 결과를 기반으로 하지 않는다** (Day 11~14 착수 시 시뮬 실측 병행 필수)
-- 본 문서의 **"권장 후보"는 감 기반 프레임** · Day 11~14에서 실 배치 시 재검증·재조정
-
----
-
-## 9. 기각안 (P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 본 문서에서 42개 슬롯 **실 배치 확정** 수행 | HOLD 범위 위반 · PD 승인 방향 위반. Day 11~14 트랙 B 영역 |
-| 2 | 조건 풀 12개 외 **신규 조건 제안** 추가 | Phase 2 §5 PD 3차 승인 확정 · 재논의 대상 아님 |
-| 3 | C9 적합 판정 **Unity MCP 시뮬 없이 확정** | §1-5 원본 경고 "서브맵 단위 보스 배치 패턴 확정은 Phase 3 재개 후 재수행" 위반 |
-| 4 | **단일 슬롯만** 체크리스트 수행 (대표 샘플) | Day 11~14 실 작업 효율화 목적이므로 42개 전수 체크리스트 유지 필수 |
-
----
-
-## 10. 재미 근거 (P30)
-
-- **강화하려는 재미 축**: "재도전 유도 유기성" (Phase 2 §5 PD 3차 승인 설계 원칙 2)
-- **변경 전 재미 문제**: 조건 배치 시 **P17 배타 7종 수동 체크 부담**으로 배치 작업 비용 과다 · 위반 리스크 상존
-- **변경 후 기대 경험**:
-  1. Day 11~14 배치 작업자(레벨기획자)가 **5분 이내 스테이지별 허용 조건 파악**
-  2. P17 위반 **사전 차단**으로 배치 후 재작업 비용 제거
-  3. 스테이지 특성(단독 보스·Shield 고스탯·서브맵 수)과 조건의 정합성 체크 시점을 **배치 확정 전**으로 앞당김
-- **측정 지표**: 42개 슬롯 P17 위반 0건 달성 · Unity MCP 시뮬 실측 기반 스테이지별 ★3 달성률 분포
-
----
-
-## 11. 관련 문서
-
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` (원본 · 수정 금지)
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` (조건 풀 12개 SOT)
-- `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` §2·§4·§5 (스테이지 구조·몬스터 구성)
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` P17 (배타 배치 규칙)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md`
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md`
-
----
-
-## 12. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (레벨기획자 관점 반영) | 초안 작성 · Day 11~14 트랙 B 즉시 활용용 전수 매핑 테이블 |
diff --git a/프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md b/프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md
deleted file mode 100644
index a9972bb..0000000
--- a/프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md
+++ /dev/null
@@ -1,288 +0,0 @@
-# 수상한 잡화점 — 맵 패턴 구성 사전 분석 v1
-
-> 작성일: 2026-04-14 / 최신화: 2026-04-18
-> 담당: 기획팀장 (총괄PM을 통한 PD님 승인 지시에 따른 홀드 중 가능 작업)
-> 지시: 작업 착수 보고서 "우선순위 상" 항목
-> 데이터 소스: `스테이지난이도곡선_v1.md` §2, `.claude/skills/BurningTimes-코어룰/SKILL.md` P17, `Phase2_카드임팩트측정_v1.md` §5
-> 상태: **설계 검토용 사전 분석** — 실 배치 확정은 **Unity MCP EditMode 시뮬 환경 구축 + Phase 3 재검증 이후** 진행
-
----
-
-## 0. 본 문서의 목적·범위
-
-### 목적
-Phase 3 HOLD 상황에서 **수행 가능한 범위**인 맵 패턴 구성 **사전 설계 데이터**를 정리한다. 실제 맵 패턴 확정 및 스테이지별 ★ 조건 배치 확정은 본 문서에서 수행하지 않는다.
-
-### 범위 (PD님 승인 지시)
-1. **C9 배치 금지 스테이지 식별** — 단독 보스 스테이지 + 보스 미등장 서브맵 패턴의 경계 정리
-2. **보스 혼용 등장 패턴 사전 설계** — 보스가 단독으로만 등장하지 않도록 혼용 패턴 프레임 설계
-3. **P17 배타 배치 규칙 전수 체크 준비** — 21스테이지 × 2슬롯(슬롯2·슬롯3) = 42개 배치 슬롯 검증 틀 구축
-
-### 범위 외 (명시적 금지)
-- Phase 3 수치 재산출 (HOLD 범위)
-- 성장 요소별 기여도 측정/조정 (HOLD 범위)
-- 카드 수치 최종 조정 (모든 카드 검증 후 재논의 — PD님 지시)
-
----
-
-## 1. C9 배치 금지 스테이지 식별
-
-### 1-1. P17 규칙 (공통 업무 규칙 SOT)
-
-> **P17-5**: C9 (보스 집중) ∧ 단독 보스·보스 미등장 스테이지 → **동시 배치 금지**
-> 사유: 논리 불성립 (Stage 2·7·10·13 등)
-
-### 1-2. 단독 보스 스테이지 판정 (Phase 2 PD님 지침 기반)
-
-`스테이지난이도곡선_v1.md §2` 보스 수 컬럼에서 **보스 수 = 1** 인 스테이지:
-
-| Stage | 보스 수 | 보스 | C9 배치 가능 여부 | 사유 |
-|-------|--------|------|------------------|------|
-| 7 | 1 | 메두사1 | **X 금지** | 단독 보스 — 집중 타격 대상 단수 |
-| 10 | 1 | 흑기사3 | **X 금지** | 단독 보스 |
-| 13 | 1 | 레드드래곤3 | **X 금지** | 단독 보스 |
-
-(기존 Phase 2 예시에 표기된 "Stage 2"는 보스 수 3체이나, 해당 구간은 입문 구간이어서 C9 난이도 자체가 부적합. 별도 사유로 C9 제외 대상.)
-
-### 1-3. 입문 구간 C9 배치 부적합 스테이지
-
-Phase 2 PD님 지침 "조건 난이도는 재도전 유도 방향" 및 P17-4(C1 ∧ C3 입문 구간 배타) 정신에 부합하도록, **보스 수와 무관하게 입문 구간(1~6)은 C9 사용에 신중**해야 한다.
-
-| Stage | 구간 | 보스 수 | C9 배치 적합도 | 권장 |
-|-------|------|--------|---------------|------|
-| 1 | 입문 | 2 | △ 가능하나 비권장 | 저HP 보스 수준에서 "집중 타격"의 체감 약함 |
-| 2 | 입문 | 3 | △ 가능하나 비권장 | 오우거1(HP112) 혼재로 체감 불균일 |
-| 3 | 입문 | 2 | △ 가능하나 비권장 | Shield가 큰 보스 — 집중 타격 체감 유리하나 입문 부담 |
-| 4 | 입문 | 3 | △ 가능 | 보스 3체로 조건 충족 난이도 적정 |
-| 5 | 입문 | 2 | △ 가능 | — |
-| 6 | 입문 | 2 | △ 가능 | — |
-
-### 1-4. C9 배치 적합 스테이지 (권장 후보)
-
-P17-5 위반 없음 + 보스 수 2체 이상 + 중반 이상 난이도:
-
-| Stage | 보스 수 | 구간 | 근거 |
-|-------|--------|------|------|
-| 8 | 2 | 중반 전환 | 메두사1+바포메트2 |
-| 9 | 2 | 중반 전환 | 바포메트2+트롤워리어4 |
-| 11 | 2 | 중반 심화 | 흑기사3+흡혈귀여왕2 |
-| 12 | 3 | 중반 심화 | 흑기사3+흡혈귀여왕2+에티4 |
-| 14 | 2 | 후반 진입 | 레드드래곤3+메두사2 |
-| 15 | 2 | 후반 진입 | 메두사2+흑기사1 |
-| 16 | 3 | 후반 진입 | 레드드래곤3+메두사2+흑기사1 |
-| 17 | 2 | 후반 | 용암골렘2+레드드래곤1 |
-| 18 | 3 | 후반 | 용암골렘2+레드드래곤1+바포메트7 |
-| 19 | 2 | 최종 | 거미여왕1+데스나이트1 |
-| 20 | 3 | 최종 | 거미여왕1+레드드래곤4+타락한천사 |
-| 21 | 2 | 최종 | 레드드래곤4+타락한천사 |
-
-### 1-5. 보스 미등장 서브맵 패턴 고려 사항
-
-**핵심 경고**: 스테이지의 **총 보스 수**는 스테이지난이도곡선_v1 §2에 기록되어 있으나, 실제 각 서브맵에 보스가 배치되는지 여부는 `ApprearMonsterPattern.json`과 `MonsterPatternList.json`의 `n_AppearMonserGroup` 조합으로 결정된다.
-
-- **Unity MCP EditMode 시뮬 환경(`Assets/Sim/`) 가동 시점에 반드시 재검증 필요**
-- 보스 미등장 서브맵 비율이 높은 스테이지는 C9가 실효성을 잃는다
-- 현 단계에서는 "보스 수 기반 1차 식별"까지만 수행하고, **서브맵 단위 보스 배치 패턴 확정은 Phase 3 재개 후 재수행**
-
----
-
-## 2. 보스 혼용 등장 패턴 사전 설계
-
-### 2-1. 배경 (PD님 지시 — 2026-04-14)
-
-> "보스가 단독으로만 등장하지 않고 일반 몬스터와 혼용되어 나올 수 있도록 패턴 설계. C9(보스 집중) 조건이 제대로 작동하기 위한 전제."
-
-### 2-2. 현재 패턴 구조 (감사 결과)
-
-`전체테이블감사_v1.md §1-2`에 따르면:
-- `MonsterPatternList.json` (101 entries): 전/중/대기열 가중치 기반 배치
-- `n_MonsterMin: 1, n_MonsterMax: 3`, `e_AppearType: "Mix"`
-- 전열=Melee 가중치 높음, 후열=Range 가중치 높음
-
-**확인 필요 사항**: 보스 전용 패턴 ID가 별도로 존재하는지, 보스와 일반 몬스터가 같은 서브맵에 혼재되는 패턴이 있는지는 `ApprearMonsterPattern.json`의 753 엔트리를 스테이지별로 재분해해야 확정 가능.
-
-### 2-3. 혼용 패턴 설계 원칙 (사전 프레임)
-
-실제 패턴 설계는 Phase 3 재개 이후 수행하되, 설계 시 준수할 원칙을 미리 정의한다:
-
-**원칙 1: 보스 단독 서브맵 최소화**
-- 1 스테이지 내 "보스만 등장하는 서브맵" 비율을 **50% 이하**로 제한(권장)
-- 단, 최종 보스 서브맵(스테이지 마지막)은 단독 허용 — 클라이맥스 설계
-
-**원칙 2: 보스 혼용 시 난이도 상한**
-- 보스와 같은 서브맵에 등장하는 일반 몬스터는 **해당 스테이지 난이도의 중하위권** 몬스터 사용
-- 보스 + 고스탯 일반 몬스터 동시 배치는 TTK 급증으로 이어지므로 **P17 이후 별도 규칙화 검토 필요**
-
-**원칙 3: C9(보스 집중) 체감 보장**
-- C9가 슬롯2·슬롯3에 배치된 스테이지는 "보스 등장 서브맵" 비율을 **보장 최소값** 이상으로 구성해야 한다
-- 해당 스테이지에서 플레이어가 **보스를 마주할 기회 수**가 C9 달성 조건값보다 충분히 커야 한다
-- 최소 보장값은 Phase 3 재개 후 시뮬 결과로 산출 필요
-
-**원칙 4: 보스 등장 타이밍 다양화**
-- 첫 서브맵부터 보스 등장(희귀), 중반 서브맵 보스 등장(일반), 마지막 보스(클라이맥스)
-- 단일 스테이지 내 **최소 2가지 이상의 보스 등장 위치 패턴**을 혼합
-
-### 2-4. 스테이지별 혼용 패턴 프레임 (사전 배치 가이드)
-
-| Stage | 서브맵 수 | 보스 수 | 권장 보스 등장 서브맵 수 | 권장 혼용 서브맵 수 |
-|-------|----------|--------|------------------------|-------------------|
-| 1 | 4 | 2 | 2 | 1~2 |
-| 2 | 6 | 3 | 3 | 1~2 |
-| 3 | 5 | 2 | 2~3 | 1~2 |
-| 4 | 7 | 3 | 3 | 2 |
-| 5 | 6 | 2 | 2 | 1~2 |
-| 6 | 7 | 2 | 2~3 | 2 |
-| 7 | 4 | 1 | 1~2 | 1 (C9 제외 대상) |
-| 8 | 5 | 2 | 2 | 1~2 |
-| 9 | 6 | 2 | 2~3 | 2 |
-| 10 | 5 | 1 | 1~2 | 1 (C9 제외 대상) |
-| 11 | 5 | 2 | 2 | 1~2 |
-| 12 | 7 | 3 | 3 | 2 |
-| 13 | 4 | 1 | 1~2 | 1 (C9 제외 대상) |
-| 14 | 5 | 2 | 2 | 1~2 |
-| 15 | 5 | 2 | 2 | 1~2 |
-| 16 | 3 | 3 | 2~3 | 1 |
-| 17 | 8 | 2 | 2~3 | 2 |
-| 18 | 8 | 3 | 3 | 2 |
-| 19 | 9 | 2 | 2~3 | 2 |
-| 20 | 9 | 3 | 3 | 2 |
-| 21 | 4 | 2 | 2 | 1 |
-
-> 상기 표는 **규칙이 아닌 설계 가이드 프레임**. 실제 서브맵별 패턴 확정은 Phase 3 재개 후 Unity MCP EditMode 시뮬로 검증하여 결정.
-
----
-
-## 3. P17 배타 배치 규칙 전수 체크 준비
-
-### 3-1. 검증 대상 규모
-
-- **21 스테이지 × 2 슬롯(슬롯2·슬롯3)** = **42개 배치 슬롯**
-- **P17 배타 조합 7종** 전수 체크 필요
-
-### 3-2. 슬롯 분류 체계 (검증 틀)
-
-각 스테이지의 슬롯 배치는 다음 3가지 체크를 모두 통과해야 한다:
-
-**체크 1: P17 배타 조합 7종 위반 여부**
-| # | 배타 조합 | 위반 시 처리 |
-|---|----------|------------|
-| 1 | C2 ∧ N2 | 슬롯2·슬롯3에 동시 금지 |
-| 2 | C6 ∧ 물약 사용 유도 조건 | 슬롯2·슬롯3에 동시 금지 |
-| 3 | C6 ∧ N4 | 슬롯2·슬롯3에 동시 금지 |
-| 4 | **(Stage 1~6)** C1 ∧ C3 | 입문 구간 한정 금지. 중반·후반 허용 |
-| 5 | C9 ∧ 단독 보스·보스 미등장 | §1 참조 — Stage 7·10·13 배치 절대 금지 |
-| 6 | **(Stage 1~6)** N3 | 입문 구간 단독 배치 금지 |
-| 7 | N5 ∧ N6 | 슬롯2·슬롯3에 동시 금지 |
-
-**체크 2: 구간별 난이도 적합도**
-- 입문(1~6): 쉬운 조건 우선
-- 중반(7~12): 빌드 의존 조건 도입 가능
-- 후반(13~21): 재도전 유도 난해 조건 배치 가능
-
-**체크 3: 스테이지 특성과 조건의 정합성**
-- N5 (후열 선공) / N6 (전열 선공) → 해당 스테이지의 후열·전열 몬스터 구성과 일치해야 함
-- C9 (보스 집중) → §1·§2의 규정 충족
-- C6 (포션 절제) → 해당 스테이지 회복의 성소·상인 빈도 고려
-- N4 (쉴드 보존) → 해당 스테이지 PC·장비 쉴드 보유 여부 고려
-
-### 3-3. 42개 슬롯 검증 체크리스트 템플릿
-
-**사용 시점**: Phase 3 재개 후 실제 배치 확정 작업 시 각 스테이지당 이 템플릿을 채워 검증
-
-```
-[Stage N] 슬롯 배치 검증 시트
------------------------------
-슬롯 2 후보 조건: ___
-슬롯 3 후보 조건: ___
-
-[체크 1] P17 배타 조합 7종
-  #1 C2∧N2:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #2 C6∧물약유도:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #3 C6∧N4:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #4 (1~6)C1∧C3:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #5 C9∧단독보스:      [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #6 (1~6)N3:         [ ] 미해당 / [ ] 위반 / [ ] 무관
-  #7 N5∧N6:           [ ] 미해당 / [ ] 위반 / [ ] 무관
-
-[체크 2] 구간별 난이도
-  구간: [ ] 입문(1~6) / [ ] 중반(7~12) / [ ] 후반(13~21)
-  조건 난이도 적합: [ ] 적합 / [ ] 과도 / [ ] 부족
-
-[체크 3] 스테이지 특성 정합
-  등장 몬스터 구성과 정합: [ ] OK / [ ] 부정합 (사유:__)
-  C9 배치 시 §1 충족: [ ] 미해당 / [ ] OK / [ ] 위반
-  C6 배치 시 회복 노드 빈도 고려: [ ] 미해당 / [ ] OK / [ ] 재검토
-  N4 배치 시 쉴드 확보 가능성: [ ] 미해당 / [ ] OK / [ ] 재검토
-
-[최종 판정] [ ] 통과 / [ ] 재배치 필요 / [ ] PD님 판단 필요
-```
-
-### 3-4. 선행 제약 확인 매트릭스
-
-42개 슬롯 배치 작업 전, 다음 선행 조건이 충족되어야 함:
-
-| 선행 조건 | 상태 | 필요 산출물 |
-|----------|------|------------|
-| 조건 풀 12개 최종 확정 | OK | Phase 2 §5 (PD님 3차 승인) |
-| N7 방어 성공 조건 포함 여부 | 실측 완료 (#37) — 조건 풀 13번째 추가 여부는 Phase 3 재개 시 PD님 결정 | PCDefence_Mul=0.3·쿨다운 없음·지속형·방어 중 공격 불가·Melee/Range 공통 |
-| N8 저 HP 완주 수치 확정 | HOLD | Phase 3 재개 후 수치 튜닝 |
-| 스테이지별 보스 혼용 패턴 확정 | HOLD | 본 문서 §2 + Unity MCP EditMode 시뮬 검증 |
-| 서브맵별 실제 몬스터 배치 추출 | HOLD | ApprearMonsterPattern.json 정밀 재분해 |
-
-**결론**: 42개 슬롯 실제 배치 확정은 현 HOLD 상태에서 불가. 본 문서는 **배치 시 사용할 검증 틀**까지만 사전 준비.
-
----
-
-## 4. 재개 조건 (Phase 3 HOLD 해제 시 즉시 연동 작업)
-
-### 4-1. 본 문서 후속 작업 트리거
-1. Unity MCP EditMode 시뮬 환경(`Assets/Sim/BurningTimes.Sim.asmdef`) 구축 완료 (#28·#37 완료)
-2. Unity MCP 시뮬과 Unity 실 빌드 간 결과 일치 검증 완료 (시드 고정·결정론 보장)
-3. Unity MCP 시뮬 실행 가이드 수령 (`공유/소통/개발팀→기획팀/`)
-4. PD님 재개 지시
-
-### 4-2. 재개 시 즉시 착수 작업 순서
-1. `ApprearMonsterPattern.json` × `MonsterPatternList.json` 조합 재분해 → 서브맵별 보스 배치 실측
-2. 본 문서 §1-4 C9 적합 스테이지 리스트 **Unity MCP 시뮬로 재검증**
-3. 본 문서 §2-4 혼용 패턴 프레임을 실제 패턴 ID 수정안으로 구체화
-4. 42개 슬롯에 §3-3 체크리스트 전수 적용
-5. PD님 승인 후 실제 조건 배치 확정
-
-### 4-3. 재검증 필수 항목
-- §1-4 C9 적합 스테이지 리스트 — 서브맵 단위 보스 등장률 확인 전까지 **임시 리스트로만 취급**
-- §2-4 스테이지별 권장 혼용 서브맵 수 — 실 데이터 부재. **감 기반 프레임**에 불과
-- §3-2 체크 3 "스테이지 특성과의 정합성" — Unity MCP 시뮬 결과 없이는 판정 불가
-
----
-
-## 5. 본 문서의 한계와 주의사항
-
-### 5-1. HOLD 범위 준수
-- 본 문서는 **수치 결정·성장 요소 기여도 산출**을 포함하지 않는다
-- Phase 3의 본 작업(성장 요소별 기여도 설정)을 대체·선행하지 않는다
-- §1·§2·§3의 모든 수치·가이드는 **설계 프레임**이며, 최종 확정값이 아니다
-
-### 5-2. 시뮬 단일축 검증 원칙
-- Unity MCP 시뮬과 Unity 실 빌드의 결과 일치 검증 필수 (시드 고정·결정론 보장)
-- 본 문서에 사용된 §1-4·§2-4 판정 근거는 `스테이지난이도곡선_v1` 데이터(CSV/JSON 직접 추출)에 기반하나, **실 전투 시 보스 혼용 효과는 Unity MCP 시뮬 실측 필수**
-
-### 5-3. 향후 보완 항목
-- **Shield 고스탯 보스 (용암골렘2·다크엘프아처1·메두사1 등) 전용 혼용 규칙** 별도 정의 필요
-- **보스 재사용 스테이지 (흑기사3 3회·레드드래곤3 3회)의 반복 체감 완화** 설계 필요 — 맵 패턴 다양화로 동일 보스도 다른 경험이 되도록
-- **Stage 16(서브맵 3개)의 특수성** — 보스 3체를 3 서브맵에 분배 시 혼용 여지 최소. 별도 검토 필요
-
----
-
-## 6. 참조 문서
-
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` P17 — ★ 조건 배타 배치 규칙
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 — 조건 풀 12개 최종 확정 / C9 배치 가이드 / PD님 3차 승인
-- `프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md` §2·§8 — 스테이지별 보스 수·보스 ID·서브맵 수
-- `프로젝트/수상한잡화점/기획/전체테이블감사_v1.md` §1-2 — CreateMapConfig / RandomPatternConfig / MonsterPatternList / ApprearMonsterPattern 구조
-- `공유/조직공지/` Phase 3 HOLD 공지 — HOLD 중 가능 작업 범위
-- 방향 전환 이력: [방향전환 히스토리 아카이브 §맵패턴 사전분석](../../../공유/조직공지/방향전환_히스토리_아카이브.md#m1-map-pattern)
-
----
-
-*작성 완료: 2026-04-14*
-*상태: 설계 검토용 사전 분석 (실 배치 확정은 Phase 3 재개 후)*
diff --git a/프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md b/프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md
deleted file mode 100644
index 8ecadbe..0000000
--- a/프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md
+++ /dev/null
@@ -1,264 +0,0 @@
-# 수상한 잡화점 — 밸런싱 문서 일관성 점검 + 재검증 체크리스트 v1
-
-> 작성일: 2026-04-14
-> 담당: 기획팀장 (총괄PM을 통한 PD님 승인 지시에 따른 홀드 중 가능 작업)
-> 지시: 작업 착수 보고서 "우선순위 중 (1)" 항목
-> 대상 문서: `밸런싱전략_v1` / `스테이지난이도곡선_v1` / `전체테이블감사_v1` / `카드시너지축분석_v1` / `Phase0_1_앵커전투시뮬레이션_v1` / `Phase2_카드임팩트측정_v1`
-
----
-
-## 0. 점검 목적
-
-1. 기존 밸런싱 문서 간 **수치·용어·전제**의 일관성 점검
-2. 개발실 시뮬레이터 이원화 해소 완료 후 **즉시 재검증할 체크리스트** 준비
-3. 본 점검은 **문서 수정을 수행하지 않는다** — 불일치 식별과 재검증 항목 선정만 수행
-
----
-
-## 1. 문서 간 일관성 점검 결과
-
-### 1-1. 앵커 기준 일관성
-
-| 문서 | 앵커 조건 | 일치 여부 |
-|------|----------|----------|
-| 밸런싱전략_v1 §3 Phase 0 | Stage 1 / PC 6001 / Lv.1 / 각성 0 / 진화 0★ / 장비 없음 / 인장 없음 / G1만 | 기준 |
-| Phase0_1_앵커전투시뮬레이션_v1 §1 | PC 6001 Lv.1 기본 스탯 기반 DPS 1.05 | 일치 |
-| Phase2_카드임팩트측정_v1 §2 | PC DPS=1.05, EHP=64, TTK=5.7s (vs 일반 몬스터 HP 6.9) | 일치 |
-| 전체테이블감사_v1 §1-1 | PC 6001 ATK 1~4, CT 2.4s, HP 58, Shield 6 | 일치 |
-
-**판정**: 앵커 기준은 4개 문서 전반에서 일관되게 유지됨.
-
-### 1-2. PC 6001 기본 스탯 일관성
-
-| 스탯 | 밸런싱전략_v1 | Phase0_1_앵커 | 전체테이블감사_v1 |
-|------|-------------|-------------|----------------|
-| ATK Min~Max | 1~4 | 1~4 (평균 2.5) | 1~4 |
-| 쿨타임 | 2.4s | 2.4s | 2.4s |
-| HP | 58 | 58 | 58 |
-| Shield | 표기 없음 | 6 (유효 HP 64) | 6 |
-| Cri | 표기 없음 | 2.6% | 2.6% |
-| CriDmg | 표기 없음 | 150% | 150% |
-| Avoid_M/R | 표기 없음 | 5/5 | 5/5 |
-
-**판정**: 일치. 밸런싱전략_v1에 Shield·Cri·회피 값 **미기재**는 요약 문서 특성상 허용 가능.
-
-### 1-3. 카드 등장 확률 일관성
-
-| 등급 | 밸런싱전략_v1 §1 | 전체테이블감사_v1 §1-3 | Phase2_카드임팩트측정_v1 §3 |
-|------|----------------|---------------------|-------------------------|
-| G1 | 66.2% | 66.2% | 66.2% |
-| G2 | 19.9% | 19.9% | 19.9% |
-| G3 | 9.9% | 9.9% | 9.9% |
-| G4 | 3.3% | 3.3% | 3.3% |
-| G5 | 0.66% | 0.66% | 0.66% |
-
-**판정**: 완벽 일치. GlobalValue 실측값 기반.
-
-### 1-4. 카드 수 일관성
-
-| 등급 | 밸런싱전략_v1 §1 | 카드시너지축분석_v1 §1 | Phase2_카드임팩트측정_v1 §2 |
-|------|----------------|---------------------|-------------------------|
-| G1 | 112 | 포함 (전체 311) | 112 |
-| G2 | 73 | 포함 | 73 |
-| G3 | 51 | 포함 | 51 |
-| G4 | 43 | 포함 | 43 |
-| G5 | 32 | 포함 | 32 |
-| 합계 | 311 | 311 | 311 |
-
-**판정**: 완벽 일치.
-
-### 1-5. 스테이지별 보스 수·서브맵 수 일관성
-
-스테이지난이도곡선_v1 §2가 단일 SOT. 다른 문서에서 스테이지 개별 보스 수를 언급한 사례 없음.
-
-**판정**: 단일 출처 유지로 불일치 리스크 없음.
-
-### 1-6. Phase 2 카드 임팩트 수치 vs 밸런싱전략 Phase 3 목표
-
-| 항목 | 밸런싱전략_v1 §3 Phase 3 목표 | Phase2_카드임팩트측정_v1 §3 실측 |
-|------|-----------------------------|--------------------------------|
-| G1 카드 풀빌드 (19장) | +80~120% 전투력 | **+399% DPS** / **+42% EHP** (이론치) |
-| G2~G5 추가 기여 | +30~60% | 실전 드래프트 혼합 시 +200~280% 추정 |
-
-**불일치 식별**: 밸런싱전략_v1의 "G1 풀빌드 +80~120%" 목표와 Phase 2 실측 "+399%" 사이에 **약 3~5배 괴리**가 있음.
-
-**원인 분석 (Phase 2 §6 기록 참조)**:
-- 이론치 +399%는 "순수 DPS 기여만" 계산한 것
-- G3~G5의 질적 효과(기절/반사/부활/무적 등)는 미포함
-- 실전에서는 카드 간 시너지 중복·몬스터 저항·상황 변수로 이론치의 50~70%로 추정
-- 즉 실전 +200~280%도 여전히 목표(+80~120%) 대비 **2~3배 높음**
-
-**판정**: **밸런싱전략_v1의 목표 수치를 재조정하거나, Phase 2 실측이 이론치에 머물러 실전값이 다를 것이라는 주석 명시 필요**. 단 Phase 3 HOLD 중이므로 **재조정은 금지**. 재검증 체크리스트 §2-1에 항목 등록.
-
-### 1-7. 카드 시너지 축 10개 vs 카드 분류
-
-| 축 | 카드시너지축분석_v1 | Phase2_카드임팩트측정_v1 |
-|----|-------------------|-----------------------|
-| 축 1 신성 폭격 | G1:11, G2:9 (초반부터 가능) | EASY 시작 난이도로 분류 |
-| 축 2 보호막-생존 | G1:22(보호막)+31(회복) | EASY |
-| 축 3 처치 연쇄 | G1:16, G4:10 (균등) | EASY |
-| 축 4 치명타 | G1:5, G4:11, G5:8 (고등급 편중) | MEDIUM~HARD 시작 |
-| 축 5 원거리-회피 | G1·전등급 균등 | MEDIUM |
-| 축 6 물약 특화 | G5:7 편중 | HARD |
-
-**판정**: 카드시너지축분석_v1과 Phase2_카드임팩트측정_v1의 빌드 형성 난이도 판정이 일치.
-
-**단, 추가 주의**: 카드시너지축분석_v1 §1-3에서 "신성 빌드 G1:11로 초반부터 쉬움"이나, 이슈 3(신성 G4/G5 확장성 부족)은 `CLAUDE.md`와 `밸런싱전략_v1`에 기록된 별도 이슈. 두 문서 간 상충은 없으나 **다른 관점**이라는 점 주의.
-
-### 1-8. ★ 조건 풀 정의 (Phase 2 §5 PD님 3차 승인 기준)
-
-Phase2_카드임팩트측정_v1 §5가 ★ 조건 풀의 **단일 SOT**. 다른 문서에 해당 내용 기재 없음.
-
-**판정**: 단일 출처로 일관성 이슈 없음. 단 향후 문서 작성 시 Phase 2 §5를 참조해야 함을 명시.
-
-### 1-9. Phase 3 목표 기여도 (성장 요소별)
-
-밸런싱전략_v1 §3 Phase 3 표:
-- G1 카드 풀빌드 (19장) +80~120%
-- G2~G5 고등급 카드 추가 +30~60%
-- 각성 트리 (만렙) +40~60%
-- 진화 (6★) +30~50%
-- 장비 (일반 셋) +20~40%
-- 장비 (세트 완성) +60~80%
-- 인장 (5★) +15~30%
-
-**불일치/미해결 사항**:
-- §1-6에서 지적한 대로 G1 풀빌드 목표가 Phase 2 실측과 괴리
-- 각성·진화·장비·인장의 실측은 **Phase 3 HOLD로 미수행**
-- 본래 Phase 3에서 이 목표들을 실 수치와 대조해 조정 예정이었음
-
-**판정**: Phase 3 재개 후 전면 재검증 대상. 본 문서에서 수정 금지.
-
-### 1-10. 용어·표기 일관성
-
-| 용어 | 밸런싱전략_v1 | 카드시너지축분석_v1 | Phase2_카드임팩트측정_v1 |
-|------|-------------|-------------------|---------------------|
-| 카드 등급 | G1~G5 | G1~G5 | G1~G5 |
-| 전투력 지표 | "전투력 몇 %" | - | DPS / EHP / TTK (구체화) |
-| 빌드 구분 | "카드 시너지" | "빌드 아키타입 10개" | "빌드 형성 난이도" |
-| 성장 요소 | 각성·진화·장비·인장 | - | - |
-
-**판정**: 큰 충돌 없음. 단 "전투력"이라는 추상어와 "DPS·EHP·TTK" 구체어가 혼용됨. **Phase 3 재개 후 밸런싱전략_v1의 목표 수치를 DPS·EHP·TTK 단위로 재표기 필요**.
-
----
-
-## 2. 개발실 시뮬 이원화 해소 후 재검증 체크리스트
-
-### 2-1. Phase 0~2 결과 재검증
-
-| # | 항목 | 현 상태 | 재검증 방법 | 예상 산출 |
-|---|------|--------|-----------|---------|
-| 1 | PC 6001 DPS 1.05 이론치 | Python 시뮬 | C# Headless 시뮬로 대조 | 실제 전투 로그 DPS |
-| 2 | Stage 1 일반 몬스터 TTK 5.7s | Python 시뮬 | C# 시뮬 + 실제 플레이 측정 | TTK 실측값 |
-| 3 | G1 카드 1장 평균 기여 +22% DPS | Python 시뮬 | C# 시뮬로 카드 1장씩 추가하며 측정 | 기여도 실측 |
-| 4 | G1 5장 TTK -45% | Python 시뮬 | C# 시뮬 5장 조합 측정 | TTK 감소율 실측 |
-| 5 | G1 풀빌드(19장) DPS +399% | Python 이론치 | C# 시뮬 실전 드래프트 | 실전 DPS 증가율 |
-| 6 | 풀빌드 EHP +42% | Python 이론치 | C# 시뮬 | 실전 EHP 증가율 |
-
-### 2-2. 카드 시너지 축 재검증
-
-| # | 항목 | 재검증 방법 |
-|---|------|-----------|
-| 7 | 축 1 신성 빌드 G1:11 자연 등장률 | 10,000회 드래프트 시뮬로 G1 신성 카드 기대 장수 재측정 |
-| 8 | 축 3 처치 연쇄 (시체폭발+암흑+경험치) 시너지 | 실제 Unity에서 처치 시 연쇄 반응 로깅 |
-| 9 | 축 4 치명타 G1:5장 초반 시그널 부족 | G1 드래프트 5장 중 치명타 카드 등장 확률 재계산 |
-| 10 | 축 6 물약 빌드 G5:7장 편중 | G5 등장 확률 0.66% × 물약 카드 비율 재계산 |
-
-### 2-3. 스테이지 난이도 곡선 재검증
-
-| # | 항목 | 재검증 방법 |
-|---|------|-----------|
-| 11 | Stage 4→5 내구도 급등 (+82%) | C# 시뮬로 Stage 4·5 실제 클리어 시간·생존률 측정 |
-| 12 | Stage 6→7 내구도 급등 (+76%) | Stage 6·7 동일 방법 |
-| 13 | Stage 17 용암골렘2 Shield 525 | 단일 보스 최강 TTK 실측 |
-| 14 | Stage 2 오우거1 HP 112 이상값 | 입문 구간 내 난이도 격차 재측정 |
-| 15 | 서브맵 수 이상(Stage 7/13/16/21) | 서브맵 수와 스테이지 평균 플레이 시간 상관 |
-
-### 2-4. 성장 요소별 기여도 실측 (Phase 3 본 작업)
-
-| # | 항목 | 재검증 방법 |
-|---|------|-----------|
-| 16 | 각성 만렙 기여도 (목표 +40~60%) | C# 시뮬 각성 유/무 비교 |
-| 17 | 진화 6★ 기여도 (목표 +30~50%) | 진화 0★ vs 6★ 비교 |
-| 18 | 장비 일반 셋 기여도 (목표 +20~40%) | 장비 착용 상태별 측정 |
-| 19 | 장비 세트 완성 기여도 (목표 +60~80%) | 세트 효과 유/무 비교 |
-| 20 | 인장 5★ 기여도 (목표 +15~30%) | 인장 장착 비교 |
-| 21 | **성장 요소 기여 순서**: 카드 풀빌드 > 세트 장비 > 각성 > 진화 > 장비 일반 > 인장 | 종합 순위 일치 여부 |
-
-### 2-5. 맵 패턴·조건 배치 재검증 (`맵패턴_사전분석_v1`과 연동)
-
-| # | 항목 | 재검증 방법 |
-|---|------|-----------|
-| 22 | C9 배치 금지 스테이지 (7·10·13) 타당성 | 실제 해당 스테이지에서 C9 달성 가능 여부 체크 |
-| 23 | C9 적합 스테이지 (§1-4) 리스트 | 각 스테이지 C9 달성률 측정 |
-| 24 | 보스 혼용 패턴 원칙 4종 | ApprearMonsterPattern.json 실 패턴 대조 |
-| 25 | 42개 슬롯 P17 전수 체크 | 42개 슬롯 배치 결정 후 체크리스트 적용 |
-
-### 2-6. 밸런싱 목표 수치 재조정
-
-| # | 항목 | 재검증 방법 |
-|---|------|-----------|
-| 26 | §1-6 G1 풀빌드 목표 +80~120% vs 실측 +200~280% | 밸런싱전략_v1 §3 Phase 3 목표 전면 재기술 |
-| 27 | 카드 풀빌드 > 세트 장비 > 각성 순서 원칙 | 실측 결과가 원칙에 부합하는지 검증 |
-| 28 | 난이도 모드별 패널티 (보통 +35~50% / 어려움 +80~120%) | 실제 패널티 적용 후 난이도 재측정 |
-
-### 2-7. Phase 3 v1 문서 (부재) 처리
-
-**핵심 발견 — 총괄PM 지시와 실제 상태 충돌**:
-- 총괄PM 지시: "이미 작성된 `Phase3_성장요소기여도_v1.md`는 현상유지(A안). 단, 재개 시 철저히 재검증해야 함"
-- 실제 상태: **`Phase3_성장요소기여도_v1.md` 파일은 존재하지 않음**
-- 추정 원인: HOLD 발령 시점(2026-04-14) C3 원칙에 따라 자진 보고 후 산출물 처리 완료 (조직공지 §1 참조)
-- 처리 방침: 본 문서 §2-4의 재검증 항목(16~21)이 Phase 3 재개 시 **처음부터 새로 작성**해야 할 내용을 커버
-
-**→ 보고 §"기획팀장 의견/질문"에 이 충돌 보고 필수**
-
----
-
-## 3. 재검증 체크리스트 사용 가이드
-
-### 3-1. 사용 시점
-- Phase 3 HOLD 해제 시점 (개발실 C# 시뮬 + CLI 가이드 + PD님 재개 지시 충족)
-- 착수 즉시 본 문서의 §2 체크리스트를 전수 적용
-
-### 3-2. 우선순위
-1. **최우선** (16~21): 성장 요소별 기여도 실측 — Phase 3 본 작업
-2. **고우선** (1~6): Phase 0~2 결과 재검증 — 앵커가 맞아야 나머지 가치 있음
-3. **중우선** (11~15, 22~25): 난이도 곡선·맵 패턴 — 실제 배치 확정 직전 필수
-4. **저우선** (7~10, 26~28): 시너지·목표 수치 재조정 — 위 작업 완료 후
-
-### 3-3. 산출물 명명 규칙
-- Phase 3 본 작업: `Phase3_성장요소기여도_v2.md` (v1 부재이므로 재작성은 v2로 식별)
-- 재검증 보고서: `재검증보고_[항목명]_v1.md`
-
----
-
-## 4. 본 점검의 한계
-
-### 4-1. 불수행 범위
-- **수치 수정 금지** — HOLD 범위 밖
-- **신규 문서 수정 제안 금지** — 본 문서는 불일치 식별·재검증 항목만 정리
-- **Phase 3 실측 대체 금지** — 재검증은 개발실 C# 시뮬 없이는 실시 불가
-
-### 4-2. 이원화 리스크 전제
-- 본 §1의 일관성 판정은 **Python 시뮬 결과 간 일관성**에 한정
-- C# 실 전투와의 일치 여부는 **§2 전수 재검증 필요**
-- 따라서 "§1 일관성 OK"라는 판정도 **잠정적**임에 주의
-
----
-
-## 5. 참조 문서
-
-- `기획실/밸런싱/수상한잡화점/밸런싱전략_v1.md`
-- `기획실/밸런싱/수상한잡화점/스테이지난이도곡선_v1.md`
-- `기획실/밸런싱/수상한잡화점/전체테이블감사_v1.md`
-- `기획실/밸런싱/수상한잡화점/카드시너지축분석_v1.md`
-- `기획실/밸런싱/수상한잡화점/Phase0_1_앵커전투시뮬레이션_v1.md`
-- `기획실/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md`
-- `기획실/밸런싱/수상한잡화점/맵패턴_사전분석_v1.md` (본 착수 작업에서 신규 작성)
-- `기획실/⚠️_PHASE3_HOLD_공지.md`
-- `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md`
-
----
-
-*작성 완료: 2026-04-14*
-*상태: 홀드 중 가능 작업 산출물 / Phase 3 재개 후 전수 재검증 필요*
diff --git a/프로젝트/수상한잡화점/기획/밸런싱전략_v1.md b/프로젝트/수상한잡화점/기획/밸런싱전략_v1.md
deleted file mode 100644
index 0e403d8..0000000
--- a/프로젝트/수상한잡화점/기획/밸런싱전략_v1.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# 밸런싱 전략 제안서 v1
-
-> 작성일: 2026-04-13
-> 담당: 기획팀장 + balance-designer
-> 상태: 사용자 승인 대기
-
----
-
-## 1. 현재 상황 정리
-
-### 카드 등급별 드래프트 등장 확률 (GlobalValue 실측)
-
-| 등급 | 가중치 | 확률 | 1런(19회 선택) 기대치 | 카드 풀 |
-|---|---|---|---|---|
-| G1 | 1000 | **66.2%** | ~12.6장 | 112장 |
-| G2 | 300 | **19.9%** | ~3.8장 | 73장 |
-| G3 | 150 | **9.9%** | ~1.9장 | 51장 |
-| G4 | 50 | **3.3%** | ~0.6장 | 43장 |
-| G5 | 10 | **0.66%** | ~0.1장 | 32장 |
-
-### 이 확률이 의미하는 것
-- **1런은 사실상 G1+G2 게임**. G3이 2장 나오면 운 좋은 런, G4가 나오면 매우 운 좋은 런, G5는 10런에 1번.
-- **치명타 빌드(G1:5장/G4:11/G5:8)**: G1에서 시작 시그널이 너무 약하고, 핵심인 G4~G5가 거의 안 나옴 → 자연적으로 치명타 빌드가 형성되기 매우 어려움
-- **물약 빌드(G5:7장)**: G5 등장 확률 0.66%에서 물약 카드가 뽑힐 확률 = ~0.15% → 사실상 G5 물약 카드는 "나오면 기적"
-- **반면 신성 빌드(G1:11)**: G1 확률 66%에서 신성 카드가 뽑힐 확률 ≈ 6.5% → 런 당 1~2장 자연 등장. 빌드 시작이 쉬움
-
-### 기타 GlobalValue 핵심 값
-| 변수 | 값 | 의미 |
-|---|---|---|
-| 카드 뽑기 소울 비용 | 300 | 아웃게임 카드 수집 속도에 영향 |
-| 인장 일반 뽑기 | 100 소울 | |
-| 인장 고급 뽑기 | 300 소울 | |
-| 캠프 기본 HP/골드/EXP | 5/10/5 | 캠프 노드의 기본 보상 |
-| 던전 이동 기본 시간 | 2.5초 | 빈 노드 통과 시간 |
-| 보물 상자 강제 오픈 확률 | 25% | |
-| 고양이 상점 아이템 수 | 4개 | |
-
----
-
-## 2. 밸런싱 순서 — 3가지 접근법 비교
-
-### 접근법 A: 외부→내부 (프레임 먼저)
-```
-PC 스탯 → 몬스터 스탯 → 성장곡선 → 장비 → 인장 → 카드 (마지막)
-```
-- 장점: 전투 프레임이 안정적. 카드는 프레임 위에서 변수만 추가.
-- 단점: 카드를 마지막에 맞추면 카드가 "남은 빈 칸 채우기"가 돼서 **Balatro류 "빌드 폭발" 쾌감이 약해질 위험**.
-
-### 접근법 B: 내부→외부 (카드 먼저)
-```
-카드 효과 기준 → PC 스탯 → 몬스터 스탯 → 장비 → 인장 → 성장곡선
-```
-- 장점: 카드가 재미의 핵심이므로 카드 중심 설계.
-- 단점: 카드 효과만으로 프레임이 안 잡히면 나중에 전체를 뒤엎어야 할 수 있음.
-
-### ⭐ 접근법 C: 앵커 포인트 방식 (팀장 추천)
-```
-하나의 기준점을 고정 → 그 기준에서 각 요소의 영향도를 측정 → 순차 확장
-```
-
-**앵커 포인트 = "쉬움 Stage 1, 각성/장비/인장 없이, G1 카드만으로 플레이하는 기본 상태"**
-
-이 앵커에서:
-1. **기본 전투 감각**: PC 기본 스탯 vs Stage1 몬스터 → 노드당 TTK가 "빠르고 경쾌한" 수준인지 확인
-2. **카드의 체감 임팩트**: G1 카드 1장 추가 시 TTK가 얼마나 줄어드는지 → "카드를 골랐을 때 차이가 느껴지는지"
-3. **이걸 기준으로 확장**:
-   - Stage 10은 앵커 대비 몬스터가 얼마나 강해야 하는지?
-   - 각성 Lv.5는 앵커 대비 PC가 얼마나 강해야 하는지?
-   - 세트 장비 완성은 앵커 대비 얼마나 유리해야 하는지?
-   - 보통/어려움 난이도 패널티는 앵커를 얼마나 약화시키는지?
-
----
-
-## 3. 앵커 포인트 방식의 구체 절차
-
-### Phase 0: 앵커 기준 확정
-| 앵커 조건 | 값 |
-|---|---|
-| 스테이지 | Stage 1 (쉬움) |
-| 캐릭터 | PC 6001 (기본 영웅), Lv.1, 각성 0, 진화 0★ |
-| 장비 | 없음 |
-| 인장 | 없음 |
-| 카드 | G1만 (등장 확률 66%) |
-| 목표 노드 TTK | ≤ 30초 (경쾌함 유지) |
-| 목표 스테이지 시간 | 3~5분 (초반 숏폼) |
-| 목표 ★ | ★1 안정 클리어 가능 |
-
-### Phase 1: 기본 전투 프레임 검증
-- PC 6001 기본 스탯(ATK 1~4, HP 58, 쿨타임 2.4s) vs Stage1 몬스터 스탯
-- **시뮬레이션**: 카드 0장 상태로 Stage1 첫 노드의 TTK 계산
-- 목표보다 느리면 → PC 기본 공격력 or 몬스터 HP 조정
-- 목표보다 빠르면 → OK (카드가 추가되면 더 빨라질 것)
-
-### Phase 2: 카드 임팩트 측정
-- G1 카드 5장 획득(≈레벨5) 상태에서 TTK 재측정
-- **핵심 질문: "카드 5장이 체감되는가?"**
-- 카드 없음 대비 TTK 감소율 30~50%가 이상적 (카드가 "의미 있지만 압도적이진 않은" 수준)
-
-### Phase 3: 성장 요소별 기여도 설정
-앵커 대비 각 성장 요소가 전투력을 **몇 %** 올려야 하는지 목표를 설정합니다.
-
-| 성장 요소 | 앵커 대비 기여도 목표 | 설계 근거 |
-|---|---|---|
-| **G1 카드 풀빌드 (19장)** | +80~120% | 인게임 재미의 핵심. 가장 큰 기여 |
-| **G2~G5 고등급 카드** | 추가 +30~60% (운에 의존) | "야호!" 순간. 터지면 폭발적 |
-| **각성 트리 (만렙)** | +40~60% | 확정적 장기 성장. 안정성 제공 |
-| **진화 (6★)** | +30~50% | 마일스톤 성취감 |
-| **장비 (일반 셋)** | +20~40% | 중반 목표 |
-| **장비 (세트 완성)** | +60~80% | 엔드게임 목표. 가장 큰 스펙업 |
-| **인장 (5★)** | +15~30% | 럭 스파이크 보너스 |
-
-핵심: **카드 풀빌드(인게임) > 세트 장비(아웃게임) > 각성 > 나머지** 순서로 기여도가 커야 합니다. 이래야 "인게임 경험 > 아웃게임 스펙" 원칙이 지켜집니다.
-
-### Phase 4: 스테이지별 난이도 곡선
-앵커(Stage 1)를 기준으로 Stage N의 몬스터 스탯 증가율을 설정:
-- **Stage 1~6 (월드1)**: 성장 없이 G1 카드만으로 ★1 가능 → 초보 구간
-- **Stage 7~10 (월드2)**: 약간의 각성+장비가 필요 → 성장 압박 시작
-- **Stage 11~15 (월드3)**: 장비 맞추기 시작해야 안정 → 중반
-- **Stage 16~21 (월드4)**: 세트 장비+인장이 ★2·★3에 영향 → 엔드게임
-
-### Phase 5: 난이도 모드별 패널티 수치화
-앵커 대비 패널티 크기:
-- **보통**: 몬스터 스탯 +20~30%, PC 스탯 -10~15% → 총 실질 난이도 +35~50%
-- **어려움**: 몬스터 +50~70%, PC -20~30% → 총 실질 난이도 +80~120%
-
-### Phase 6: 실제 플레이 테스트 → 반복 조정
-- 사용자가 Unity에서 Stage 1을 플레이 → 체감 피드백
-- 기획팀이 수치 시뮬레이션 결과와 비교
-- 차이가 있으면 조정 → 반복
-
----
-
-## 4. 접근법 C를 추천하는 이유
-
-이 게임의 핵심 원칙은 **"인게임 카드 경험 > 아웃게임 스펙"**입니다.
-
-접근법 A(프레임 먼저)로 가면 카드가 "이미 잡힌 프레임에 끼워 맞추는" 부속이 되어 카드의 임팩트가 약해질 위험이 있고, 접근법 B(카드 먼저)로 가면 프레임 없이 카드만 만지다가 나중에 전체를 뒤엎어야 할 수 있습니다.
-
-접근법 C는 **"가장 단순한 상태에서 시작해 하나씩 레이어를 쌓으며 각 레이어의 기여도를 측정"**하는 방식이라:
-- 어느 레이어에서 문제가 생겨도 해당 레이어만 조정하면 됨
-- "카드의 기여도"를 정량적으로 관리할 수 있어 핵심 원칙을 수치로 지킬 수 있음
-- 사용자가 Stage 1 플레이만으로 기본 감각을 빠르게 검증 가능
-
----
-
-## 5. 실행 로드맵 (2개월 역산: 소프트 론칭 6~7월)
-
-| 주차 | 작업 | 산출물 |
-|---|---|---|
-| **1주차** | Phase 0~1: 앵커 확정 + 기본 전투 프레임 검증 | PC/몬스터 기본 스탯 조정안 |
-| **2주차** | Phase 2: 카드 임팩트 측정 + G1 카드 수치 1차 조정 | 카드 효과 수치 v2 |
-| **3주차** | Phase 3: 성장 요소별 기여도 설정 (각성/진화/장비/인장) | 성장 곡선 수치표 |
-| **4주차** | Phase 4: 스테이지 난이도 곡선 | Stage 1~21 몬스터 스탯 테이블 |
-| **5~6주차** | Phase 5~6: 난이도 모드 + 플레이 테스트 반복 | 최종 밸런스 시트 |
-| **7~8주차** | 경제 밸런싱 (재화 흐름, BM 가격, 시즌패스) | 경제 설계서 |
-
----
-
-## 6. 사용자에게 승인 요청
-
-1. **접근법 C(앵커 포인트 방식)로 진행해도 될까요?**
-2. **Phase 0의 앵커 기준(Stage1, PC6001, 장비/각성/인장 없음, G1만)**이 적절한가요?
-3. **Phase 3의 기여도 목표(카드 +80~120%, 세트 장비 +60~80%, 각성 +40~60%…)**의 방향이 맞나요?**
-4. **실행 로드맵의 주차별 진행이 소프트 론칭 일정에 현실적인가요?**
-
----
-
-## 변경 이력 (P16 산출물 추적성)
-
-> **표준 포맷 (2026-04-17 도입)**: 밸런싱 관련 문서 4종 공통 적용. 본 문서의 전략·Phase 정의·기여도 목표가 변경될 때마다 아래 테이블에 1행 append.
-> **필드 설명**: 변경 필드 = 어떤 Phase·기여도 축·로드맵인가 / 이전값→이후값 = 구체 정의 / 재미 근거 = C7 원칙에 따른 재미 강화 축 / 관련 PD 지시# = `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`의 해당 #
-
-| 일시 | 변경자 | 변경 필드 | 이전값→이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|---------|-------------|----------|-------------|
-| 2026-04-17 | 기획팀장 | 변경 이력 테이블 섹션 신설 | - → 기존 상태 확정 | 산출물 추적성 확보 (P16), 전략 수정 시 결정 경로 추적 가능 | 본 작업 (팀장 재량 진행 승인) |
diff --git a/프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md b/프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md
deleted file mode 100644
index 5d20122..0000000
--- a/프로젝트/수상한잡화점/기획/빌드_조건_충돌점검_v1.md
+++ /dev/null
@@ -1,386 +0,0 @@
-# 수상한 잡화점 — 빌드 × ★ 조건 충돌 전수 점검 v1
-
-> 작성일: 2026-04-14
-> 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
-> 위임 근거: Phase 2 §5 PD님 2차 승인 "A안 확정 — 물약 외 다른 빌드도 ★ 조건과 구조적 충돌이 있는지 **모든 빌드 대상 전수 점검 실시**"
-> HOLD 준수: 본 문서는 **구조적 충돌 식별**에 한정. 수치 재조정 제안은 일절 금지 (이슈 1·3 재논의 영역)
-
----
-
-## 0. 본 문서의 목적·범위
-
-### 목적
-PD님이 Phase 2 §5 2차 승인으로 확정한 "타 빌드 전수 점검" A안을 **구조적 충돌 식별 수준**에서 이행. 카드 시너지 축 10개(`카드시너지축분석_v1 §2`)와 ★ 조건 12개(`3성조건_12개_상세명세_v1 §2`)를 교차시켜 **120개 조합의 구조적 충돌 여부**를 매트릭스화한다.
-
-### 배경: 물약 빌드 케이스의 일반화
-- 물약 빌드 × ★ 조건 "물약 미사용" = **구조적 배타**
-- PD님 판단: "의도된 설계 아님" → 타 빌드 전수 점검 지시
-- 본 문서는 같은 유형의 구조적 배타가 **다른 빌드에도 숨어 있는지** 식별
-
-### 범위 외 (HOLD 준수)
-- **수치 재조정 제안 금지** — 이슈 1·3 재논의 완료 후 통합 처리 대상
-- **조건 풀 12개 수정·추가·삭제 금지**
-- **빌드별 카드 수치 변경 제안 금지**
-- **스테이지별 슬롯 배치 확정 금지**
-- 실제 조정이 필요한 충돌이 발견되면 **식별·기록까지만**. 처리 방안 제안은 금지
-
-### 용어 정의
-- **구조적 배타(E)**: 빌드를 진행할수록 조건 달성이 **논리적·구조적으로 불가능**해지는 관계 (예: 물약 빌드 × C6 포션 절제)
-- **구조적 충돌(X)**: 빌드 진행과 조건 달성이 **동시에 추구하기 매우 어려움** (배타는 아니나 강한 대립)
-- **무관(—)**: 빌드와 조건이 상호 영향 없음
-- **시너지(S)**: 빌드가 조건 달성을 **용이하게** 함
-- **강시너지(SS)**: 빌드 진행이 조건을 **자동 충족**에 가까움 (난이도 약화 우려)
-
----
-
-## 1. 입력 데이터
-
-### 1-1. 카드 시너지 축 10개 (카드시너지축분석_v1 §2)
-
-| # | 빌드명 | 핵심 태그 | G1~G5 분포 특성 |
-|---|-------|---------|----------------|
-| B1 | 신성 폭격 | 공격력 + 신성 + 후열타격 | G1:11, G2:9 (초반부터 가능) |
-| B2 | 보호막-생존 | 보호막 + 회복 + 흡혈 | G1:22(보호막)+31(회복) (초반부터 가능) |
-| B3 | 처치 연쇄 | 처치시 + 시체폭발 + 암흑 + 경험치 | 전등급 균등 (G1:16, G4:10) |
-| B4 | 치명타 | 치명타 + 공격력 | G4:11, G5:8 (고등급 편중) |
-| B5 | 원거리-회피 | 원거리 + 회피 + 반사 | 전등급 균등 |
-| B6 | 물약 특화 | 물약 | G5:7 편중 |
-| B7 | 첫타 버스트 | 첫타 + 공격력 | G1:8 (초반 가능) |
-| B8 | 번개 | 번개 + 기절 | G1:8 번개 / G5:4 기절 |
-| B9 | 탐험-경제 | 캠프 + 골드 + 경험치 + 레벨업 | G1 편중 |
-| B10 | 미사일 | 미사일 | G1:5 |
-
-### 1-2. ★ 조건 풀 12개 (3성조건_12개_상세명세_v1 §2)
-
-| ID | 명칭 | 측정 방식 | 유저 컨트롤성 |
-|----|------|---------|-------------|
-| C1 | 신속 | 총 소요 시간 ≤ 임계값 | 중 |
-| C2 | 완벽 클리어 | HP = MaxHP | 중 |
-| C3 | 고 HP 완주 | HP ≥ MaxHP × 70% | 저 |
-| C6 | 포션 절제 | 포션 사용 ≤ 임계값 | 저 |
-| C9 | 보스 집중 | 보스 유효 공격 ≥ 임계값 | 중 |
-| C12 | 회피 주도 | 회피 ≥ 서브맵수 × 3 | 고 |
-| N1 | 빗맞힘 절제 | 빗맞힘 ≤ 임계값 | 중 |
-| N2 | 피격 제한 | 피격 ≤ 서브맵수 × 1 | 고 |
-| N3 | 치명타 처치 | 치명타 처치 ≥ 임계값 | 중~고 |
-| N4 | 쉴드 보존 | Shield ≥ MaxShield × 30% | 중 |
-| N5 | 후열 선공 | 최초 공격 대상 후열 | 저~중 |
-| N6 | 전열 선공 | 최초 공격 대상 전열 | 저~중 |
-
----
-
-## 2. 120개 조합 충돌 매트릭스
-
-각 셀에 관계 유형 + 간단 코멘트:
-**E** (구조적 배타) / **X** (구조적 충돌) / **SS** (강시너지) / **S** (시너지) / **—** (무관)
-
-| 빌드 \ 조건 | C1 신속 | C2 완클 | C3 고HP | C6 포션절제 | C9 보스집중 | C12 회피주도 | N1 빗맞절제 | N2 피격제한 | N3 크리처치 | N4 쉴드보존 | N5 후열선공 | N6 전열선공 |
-|---|---|---|---|---|---|---|---|---|---|---|---|---|
-| **B1 신성** | S | — | — | — | S | — | — | — | — | — | **SS** | X |
-| **B2 생존** | X | **SS** | **SS** | — | — | — | — | S | — | **SS** | — | — |
-| **B3 처치연쇄** | S | — | — | — | X | — | — | — | S | — | — | — |
-| **B4 치명타** | S | — | — | — | S | — | S | — | **SS** | — | — | — |
-| **B5 원거리회피** | — | S | S | — | — | **SS** | — | **S** | — | — | S | X |
-| **B6 물약** | — | — | — | **E** | — | — | — | — | — | — | — | — |
-| **B7 첫타버스트** | **SS** | — | — | — | S | — | — | — | — | — | — | S |
-| **B8 번개** | S | — | — | — | — | — | — | — | — | — | — | — |
-| **B9 탐험경제** | X | — | — | — | — | — | — | — | — | — | — | — |
-| **B10 미사일** | S | — | — | — | S | — | — | — | — | — | — | — |
-
----
-
-## 3. 조합별 식별 결과 상세
-
-### 3-1. 구조적 배타 (E) — 절대 동시 추구 불가
-
-#### E-1. B6 물약 × C6 포션 절제
-- **이미 식별·확정된 배타** (Phase 2 §5 이슈 4, P17-2 배타 조합으로 규칙화됨)
-- **처리 상태**: 동일 스테이지 슬롯2·슬롯3 배치 금지로 방어 완료
-- **본 점검 의의**: 다른 빌드에서 동일 유형 배타가 있는지 확인
-
-### 3-2. 구조적 충돌 (X) — 동시 추구 시 한쪽 포기 압박
-
-#### X-1. B1 신성 폭격 × N6 전열 선공
-- **충돌 내용**: 신성 빌드는 **후열 타격** 중심으로 설계됨 (카드시너지축분석 §2 축 1 "후열타격 조합 시 폭발적"). N6 조건은 **최초 공격 대상이 전열**이어야 함
-- **영향도**: 신성 빌드 진행 중이라면 **N6 조건 달성을 위해 빌드 컨셉을 포기**해야 할 수 있음
-- **주의**: 단, "최초 1회 전열 공격" 후 이어서 후열 집중 공격은 가능. 엄밀히 따지면 **한 서브맵당 첫 공격만 전열**이면 된다 → 완전 배타는 아님
-- **판정**: **구조적 충돌 (X)**. 재논의 대상
-
-#### X-2. B2 보호막-생존 × C1 신속
-- **충돌 내용**: 보호막·회복·흡혈 플레이는 **"버티면서 안정적으로" 진행**하는 성격 → 총 소요 시간이 길어지는 경향. C1 신속은 빠른 처치가 전제
-- **영향도**: 생존 빌드 진행 중 C1 달성이 쉽지 않음
-- **주의**: 공격력 보조 카드가 섞이면 완화 가능. **구조적 배타는 아님**
-- **판정**: **구조적 충돌 (X)**. 기록 후 재논의
-
-#### X-3. B3 처치 연쇄 × C9 보스 집중
-- **충돌 내용**: 처치 연쇄 빌드는 **시체폭발·연쇄 처치**로 폭발적 클리어가 핵심. 일반 몬스터를 빠르게 처치하며 연쇄를 만드는 구조. C9는 **보스에 집중 타격**을 유도 → 일반 몬스터에 분산되는 처치 연쇄와 방향성이 다름
-- **영향도**: 처치 연쇄 빌드에서 보스에 집중하면 연쇄가 끊기고, 연쇄를 살리려면 C9 카운트가 올라가지 않음
-- **주의**: 연쇄 끝에 보스 처치가 걸리면 동시 달성도 가능. 완전 배타는 아니나 **플레이 방향성 상충**
-- **판정**: **구조적 충돌 (X)**. 재논의 대상
-
-#### X-4. B5 원거리-회피 × N6 전열 선공
-- **충돌 내용**: 원거리-회피 빌드는 **후열 몬스터에 접근 없이 사격** + **근접 몬스터(전열) 회피**가 핵심. N6은 첫 공격이 전열이어야 함
-- **영향도**: 원거리 빌드의 "전열 회피·후열 저격" 컨셉과 부분 충돌
-- **주의**: 첫 공격만 전열이면 되므로 엄밀히 배타는 아님
-- **판정**: **구조적 충돌 (X)**. N6이 원거리 빌드에 불리한 조건임을 기록
-
-#### X-5. B9 탐험-경제 × C1 신속
-- **충돌 내용**: 탐험-경제 빌드는 **캠프·성소·골드 수집** 등 노드 외 시간 소비가 핵심. C1 신속은 총 시간 단축 조건
-- **영향도**: 탐험 빌드 진행 중 C1 달성 거의 불가능
-- **판정**: **구조적 충돌 (X)**. 재논의 대상
-
-### 3-3. 강시너지 (SS) — 난이도 약화 우려
-
-강시너지는 **빌드를 진행하면 조건이 자동 충족**에 가까워서 "재도전 유도" 원칙에 역행할 수 있음. 조건 풀 설계 관점에서 주의 사항.
-
-#### SS-1. B1 신성 × N5 후열 선공
-- **상세**: 신성 빌드는 애초에 **후열 타격 카드** 중심. 첫 공격부터 후열을 노리는 것이 자연스러움
-- **영향도**: 신성 빌드 플레이어에게 N5는 **사실상 자동 달성**
-- **판정**: **강시너지 (SS)**. 조건 "재도전 유도" 강도 약화 가능성
-
-#### SS-2. B2 생존 × C2 완벽 클리어
-- **상세**: 생존 빌드는 **HP/Shield 유지**가 핵심. C2(HP=MaxHP)는 회복·흡혈과 직접 시너지
-- **영향도**: 생존 빌드 진행 중이면 C2 달성률 급증
-- **판정**: **강시너지 (SS)**
-
-#### SS-3. B2 생존 × C3 고 HP 완주
-- **상세**: C2와 같은 축. HP 70% 이상 유지는 생존 빌드가 자연스럽게 달성
-- **판정**: **강시너지 (SS)**
-
-#### SS-4. B2 생존 × N4 쉴드 보존
-- **상세**: 보호막 카드(G1 22장)가 풍부하여 Shield 회복 주기가 짧음. MaxShield × 30% 유지는 쉬움
-- **판정**: **강시너지 (SS)**
-
-#### SS-5. B4 치명타 × N3 치명타 처치
-- **상세**: 치명타 빌드의 **핵심 효과**가 N3 조건 **그 자체**
-- **영향도**: 치명타 빌드 진행자에게 N3는 자동 달성. 반대로 치명타 빌드가 아니면 N3 달성 거의 불가
-- **판정**: **강시너지 (SS)**. **양면성**: 치명타 빌드 쉬움 + 비치명타 빌드 매우 어려움 → **N3의 입문 구간 배치 금지(P17-6)는 이 구조 기반**
-
-#### SS-6. B5 원거리-회피 × C12 회피 주도
-- **상세**: 회피 카드(G1:30장 이상)가 풍부하여 회피 발생률이 매우 높음. C12(서브맵수 × 3 이상)는 쉽게 달성
-- **판정**: **강시너지 (SS)**
-
-#### SS-7. B7 첫타 버스트 × C1 신속
-- **상세**: 첫타 빌드는 **전투 시작 시 폭발적 딜**로 몬스터를 빠르게 제거. 총 소요 시간 단축
-- **판정**: **강시너지 (SS)**
-
-### 3-4. 시너지 (S) — 적정 난이도 완화
-
-#### S-1. B1 신성 × C1 신속 / C9 보스집중
-- 신성 폭격 딜로 빠른 처치 + 보스 집중 공격 시 딜 증가
-
-#### S-2. B3 처치연쇄 × C1 신속
-- 연쇄 폭발로 서브맵 클리어 시간 단축
-
-#### S-3. B3 처치연쇄 × N3 치명타 처치
-- "처치 트리거" 카드와 치명타 처치 카드가 함께 발동 가능
-
-#### S-4. B4 치명타 × C1 / C9 / N1
-- 치명타 한 방 딜로 빠른 처치(C1), 보스 집중(C9), 빗맞힘 적음(N1)
-
-#### S-5. B5 원거리-회피 × C2 / C3 / N2 / N5
-- 회피 시스템이 피격·HP 유지 관련 조건에 전반적 시너지
-
-#### S-6. B7 첫타 × C9 / N6
-- 첫타가 보스 대상일 경우 C9 시너지, 첫타는 전열부터 공격하는 경향(N6)
-
-#### S-7. B8 번개 × C1
-- 기절 CC로 몬스터 활동 정지, 처치 속도 상승
-
-#### S-8. B10 미사일 × C1 / C9
-- 자동 발사 미사일로 패시브 딜 증가
-
----
-
-## 4. 횡단 분석 — 문제 구조 식별
-
-### 4-1. 구조적 배타·충돌 빌드 요약
-
-| 빌드 | 충돌 ★ 조건 | 처리 상태 |
-|------|------------|---------|
-| B1 신성 | N6(충돌) | 재논의 대상 |
-| B2 생존 | C1(충돌) | 재논의 대상 |
-| B3 처치연쇄 | C9(충돌) | 재논의 대상 |
-| B5 원거리회피 | N6(충돌) | 재논의 대상 |
-| B6 물약 | C6(배타) | **P17-2 배타 규칙으로 방어 완료** |
-| B9 탐험경제 | C1(충돌) | 재논의 대상 |
-
-### 4-2. 구조적 배타(E) 식별 결과
-
-**추가로 발견된 구조적 배타(E)는 없음**. B6 물약 × C6가 유일 케이스로 재확인됨.
-
-→ PD님 A안 "모든 빌드 전수 점검" 결과, **신규 배타는 없으며 물약·포션 충돌이 유일한 구조적 배타**로 확인.
-
-### 4-3. 구조적 충돌(X) 5건 공통 패턴
-
-| 패턴 유형 | 해당 충돌 |
-|---------|---------|
-| **시간·속도 기반 조건 (C1) vs 느린 플레이 빌드** | X-2 (B2 생존), X-5 (B9 탐험) |
-| **타겟 지향 (N5/N6) vs 타겟 선호 빌드** | X-1 (B1 신성×N6), X-4 (B5 원거리×N6) |
-| **집중 공격 (C9) vs 분산 처치 빌드** | X-3 (B3 처치연쇄×C9) |
-
-### 4-4. 강시너지(SS) 7건 — 조건 난이도 약화 우려
-
-| 조건 | SS 빌드 수 | 비고 |
-|------|---------|------|
-| C1 | 1 (B7 첫타) | — |
-| C2 | 1 (B2 생존) | — |
-| C3 | 1 (B2 생존) | — |
-| N3 | 1 (B4 치명타) | 양면성 — 비치명타 빌드에선 달성 거의 불가 |
-| N4 | 1 (B2 생존) | — |
-| N5 | 1 (B1 신성) | — |
-| C12 | 1 (B5 원거리회피) | — |
-
-**횡단 관찰**: B2 생존 빌드가 **3개 조건(C2·C3·N4)에 강시너지** → 생존 빌드 플레이어에겐 ★2·★3 조건 달성이 구조적으로 쉬워지는 편중 현상
-
-### 4-5. 빌드별 조건 달성 난이도 프로필 (정성적)
-
-| 빌드 | 쉬운 조건 (SS+S 수) | 어려운 조건 (E+X 수) | 프로필 |
-|------|--------------------|---------------------|--------|
-| B1 신성 | 3 (SS×1 + S×2) | 1 (X×1) | 후열·보스 중심 조건에 유리, 전열 조건 불리 |
-| B2 생존 | 5 (SS×3 + S×2) | 1 (X×1) | **조건 달성 가장 쉬운 빌드** — 조건 난이도 저 |
-| B3 처치연쇄 | 3 (S×3) | 1 (X×1) | 보스 집중형 조건에 불리 |
-| B4 치명타 | 4 (SS×1 + S×3) | 0 | 치명타 조건 독점 |
-| B5 원거리회피 | 5 (SS×1 + S×4) | 1 (X×1) | 회피·방어 조건 유리 |
-| B6 물약 | 0 | 1 (E×1) | **조건 달성 가장 어려운 빌드** — 구조적 배타 보유 |
-| B7 첫타 | 3 (SS×1 + S×2) | 0 | 속도·선공 조건 유리 |
-| B8 번개 | 1 (S×1) | 0 | 조건 연계 약함 |
-| B9 탐험경제 | 0 | 1 (X×1) | 조건 연계 부족 |
-| B10 미사일 | 2 (S×2) | 0 | 조건 연계 보통 |
-
-**주목**: B8(번개), B9(탐험경제), B10(미사일)은 조건 연계가 약함 → 이 빌드 플레이어에게 ★ 조건은 빌드 외적으로 달성해야 하는 **별개 태스크**가 됨
-
----
-
-## 5. 재논의 이관 항목 (수치·조정 제안 금지 — 식별만)
-
-본 §는 **Phase 3 재개 후 이슈 1·3 재논의 시 같이 검토할 구조적 이슈**를 식별하여 기록한다. 본 문서는 **조정 방향 제시 금지** (PD님 지시 엄수). 질문 형태로만 제기.
-
-### 5-1. B2 생존 빌드의 다수 강시너지 — 조건 난이도 약화
-
-**식별**: B2가 C2·C3·N4 3개 조건과 강시너지 → 생존 빌드 플레이어에겐 ★ 조건 난이도가 **구조적으로 저하**됨
-
-**재논의 시 확인할 질문** (답변 제시 금지):
-1. 이 강시너지는 PD님 지침 "재도전 유도" 방향성에 부합하는가, 역행하는가?
-2. 생존 빌드 플레이어가 쉽게 ★★★을 얻는 것이 **의도된 쉬운 빌드 보상**인가, 재조정 대상인가?
-3. 스테이지별 슬롯 배치 시 "생존 빌드로 쉽게 달성되는 조건"이 중복되지 않도록 **배타 규칙 추가**가 필요한가?
-
-### 5-2. B3 처치연쇄 × C9 충돌 — 빌드 컨셉과 조건 방향성 불일치
-
-**식별**: 처치 연쇄 빌드의 "일반 몬스터 분산 처치" 방향성과 C9의 "보스 집중" 방향성이 상충
-
-**재논의 시 확인할 질문**:
-1. 처치 연쇄 빌드가 주력인 런에서 C9 스테이지를 만나면 빌드를 포기해야 하는가?
-2. 이 상충을 해결하려면 (a) 처치 연쇄에 "보스 처치 시 가산" 효과를 추가 / (b) C9 판정에 일반 처치 가산 옵션 / (c) 배타 배치로 방어 중 어느 쪽인가?
-
-### 5-3. B9 탐험경제·B8 번개·B10 미사일 — 조건 연계 부족
-
-**식별**: 3개 빌드 모두 SS 시너지가 0 + S 시너지도 1~2개 수준. ★ 조건이 빌드 외 태스크가 됨
-
-**재논의 시 확인할 질문**:
-1. 이는 빌드 개성인가, 조건 풀의 커버리지 부족인가?
-2. 조건 풀 12개가 **모든 빌드를 균등하게 커버**해야 하는가, **특정 빌드를 우대**해도 되는가?
-3. N7(방어 성공), 미채택된 C4~C5·C7~C8·C10·C11 등의 재검토 시 이 빌드들에 맞는 조건이 추가될 가능성?
-
-### 5-4. N6 전열 선공 — 신성·원거리 빌드와 2건 충돌
-
-**식별**: N6이 2개 빌드(B1·B5)와 충돌. **조건 풀 중 가장 빌드 배제 범위가 넓은 조건**
-
-**재논의 시 확인할 질문**:
-1. N6의 배치 스테이지를 **원거리 몬스터 비율이 낮은 스테이지**에 한정하여 빌드 충돌을 완화할 수 있는가?
-2. P17 배타 조합에 "N6 ∧ 특정 빌드 유도 조건" 추가가 필요한가?
-
-### 5-5. B6 물약 × C6 이외의 숨은 배타 부재 확인
-
-**식별**: 전수 점검 결과 **구조적 배타(E)는 B6 물약 × C6 1건뿐**. PD님 A안 "전수 점검" 지시의 출발점인 우려는 해소됨
-
-**기록용**: Phase 3 재개 시 "타 빌드 점검 완료 — 신규 배타 없음"으로 보고.
-
----
-
-## 6. 매트릭스 검증 방법 (Phase 3 재개 시)
-
-### 6-1. Unity MCP 시뮬 기반 검증
-
-Unity MCP EditMode 시뮬 환경(`Assets/Sim/BurningTimes.Sim.asmdef`) 구축 후 각 조합을 실측:
-
-| 단계 | 작업 | 산출 |
-|-----|------|-----|
-| 1 | 10개 빌드 각각을 대표하는 **기준 덱**을 설계 (수정 없음 — 현재 데이터로만) | 10개 기준 덱 |
-| 2 | 각 기준 덱으로 21개 스테이지 반복 플레이 시뮬 (슬롯2·슬롯3 조건 배치 가상화) | 빌드 × 스테이지 매트릭스 |
-| 3 | 각 ★ 조건별 실측 달성률 집계 | 120 조합 × 스테이지별 달성률 |
-| 4 | 본 문서의 E·X·SS·S·— 판정과 실측 결과 대조 | 매트릭스 재조정안 |
-
-### 6-2. 실측과 본 문서 불일치 시 처리
-
-- 본 문서 판정이 정성적 분석 기반이므로 **실측과 불일치 가능성 상존**
-- 불일치 발견 시 본 문서 v2 작성 + PD님 보고
-- 절대 기준은 Unity 실 빌드 실측치 (Unity MCP 시뮬과 Unity 실 빌드 간 결과 일치 검증 — 시뮬 단일축 원칙)
-
----
-
-## 7. 본 문서의 한계
-
-### 7-1. 정성적 분석 한계
-- 본 매트릭스는 **카드 효과 기반 정성 분석**. 실제 플레이 빈도·드래프트 랜덤성·몬스터 구성 등 실전 변수 미반영
-- **구조적 배타(E) 판정만 객관적**. X·SS·S 판정은 해석에 따라 달라질 수 있음
-
-### 7-2. 단일 빌드 가정
-- 실전 드래프트는 **혼합 빌드**가 일반적. "순수 B2 생존만 추구"는 드물며, 보통 B2+B3, B2+B5 등 혼합됨
-- 혼합 빌드의 조건 달성 프로필은 Phase 3 재개 후 실측 필요
-
-### 7-3. 스테이지 특성 미반영
-- 본 매트릭스는 **스테이지 중립**. 실제로는 스테이지별 몬스터 구성(전열/후열 비율, 보스 수 등)이 조건 달성에 큰 영향
-- 스테이지별 편차는 `맵패턴_사전분석_v1`의 후속 작업에서 보완
-
-### 7-4. 조건 임계값 미반영
-- 각 조건의 임계값(C1 시간, C6 포션 사용 횟수 등)은 아직 미확정
-- 임계값에 따라 SS↔S, S↔— 전환 가능
-- Phase 3 재개 후 임계값 확정 시 재판정 필요
-
----
-
-## 8. HOLD 준수 확인
-
-| 체크 항목 | 상태 |
-|---------|------|
-| 성장 요소 기여도 측정 | **미수행** ✓ |
-| 시뮬레이션 실행 | **미수행** ✓ |
-| 카드 수치 조정 제안 | **미수행** ✓ |
-| 조건 풀 12개 수정·추가·삭제 | **미수행** ✓ |
-| 구체적 임계값 확정 | **미수행** ✓ |
-| 데이터 테이블 변경 | **미수행** ✓ |
-| 빌드 밸런스 수치 조정안 | **미수행** (§5 재논의 이관 항목은 **질문 형태만** 기록) ✓ |
-
-**본 문서가 수행한 것**:
-- PD님 A안 "타 빌드 전수 점검" 이행 — 구조적 배타·충돌·시너지 식별
-- Phase 3 재개 후 이슈 1·3 재논의 시점에 참조할 **구조 분석 자료** 준비
-
----
-
-## 9. 참조 문서
-
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` §2 (빌드 축 10개)
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 이슈 4 (물약 빌드 × ★2 충돌, PD님 A안)
-- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` §2 (조건 풀 12개)
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` §3 (이슈 1·3 통합 처리 원칙)
-- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md` §3 (P17 배타 배치)
-- `.claude/skills/BurningTimes-코어룰/SKILL.md` P17 (배타 조합 7종)
-- `공유/조직공지/` Phase 3 HOLD 공지 (HOLD 범위)
-- 방향 전환 이력: [방향전환 히스토리 아카이브 §빌드 조건 충돌점검](../../../공유/조직공지/방향전환_히스토리_아카이브.md#m3-build-condition-conflict)
-
----
-
-*작성 완료: 2026-04-14*
-*상태: PD님 A안 "빌드 전수 점검" 이행 / Phase 3 재개 후 이슈 1·3 재논의 시 입력 자료*
-
----
-
-## 변경 이력 (P16 산출물 추적성)
-
-> **표준 포맷 (2026-04-17 도입)**: 밸런싱 관련 문서 4종 공통 적용. 본 문서의 충돌·배타 조합 판정·빌드 축이 변경될 때마다 아래 테이블에 1행 append.
-> **필드 설명**: 변경 필드 = 어떤 조합·빌드 축·충돌 판정인가 / 이전값→이후값 = 구체 판정 변화 / 재미 근거 = C7 원칙에 따른 재미 강화 축 (빌드 다양성 등) / 관련 PD 지시# = `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`의 해당 #
-
-| 일시 | 변경자 | 변경 필드 | 이전값→이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|---------|-------------|----------|-------------|
-| 2026-04-17 | 기획팀장 | 변경 이력 테이블 섹션 신설 | - → 기존 상태 확정 | 산출물 추적성 확보 (P16), 배타 조합(P17) 변경 시 근거 추적 가능 | 본 작업 (팀장 재량 진행 승인) |
diff --git a/프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md b/프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md
deleted file mode 100644
index 03203e9..0000000
--- a/프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md
+++ /dev/null
@@ -1,320 +0,0 @@
-# 수상한 잡화점 — 스테이지 난이도 곡선 분석 v1
-
-분석 기준일: 2026-04-13  
-데이터 소스: CreateMapConfig.csv / ApprearMonsterPattern.csv / MonsterList.csv / WorldMapConfig.json / RandomPatternConfig.json
-
----
-
-## 1. WorldMap별 스테이지 구성
-
-| WorldMap | 스테이지 | 테마 배경 |
-|----------|----------|-----------|
-| WorldMap_1 | Stage 1 ~ 6 | map_01~06 |
-| WorldMap_2 | Stage 7 ~ 10 | map_07~10 |
-| WorldMap_3 | Stage 11 ~ 15 | map_11~15 |
-| WorldMap_4 | Stage 16 ~ 21 | map_16~21 |
-
----
-
-## 2. 스테이지별 요약 테이블
-
-| Stage | WorldMap | 서브맵수 | AppearGroup 범위 | 보스 수 | 보스ID(들) | 보스명(들) |
-|-------|----------|---------|-----------------|---------|------------|-----------|
-| 1 | WM1 | 4 | 10101~10104 | 2 | 10001, 10002 | 놀아처1, 놀강도2 |
-| 2 | WM1 | 6 | 10201~10206 | 3 | 10002, 10003, 10004 | 놀강도2, 임프전사1, 오우거1 |
-| 3 | WM1 | 5 | 20301~20305 | 2 | 10005, 10006 | 바포메트6, 거미여왕2 |
-| 4 | WM1 | 7 | 20401~20407 | 3 | 10006, 10007, 10008 | 거미여왕2, 흑기사2, 늑대인간 |
-| 5 | WM1 | 6 | 30501~30506 | 2 | 10009, 10010 | 대사탄1, 다크엘프아처1 |
-| 6 | WM1 | 7 | 30601~30607 | 2 | 10011, 10012 | 대사탄2, 데스나이트3 |
-| 7 | WM2 | 4 | 40701~40704 | 1 | 10013 | 메두사1 |
-| 8 | WM2 | 5 | 40801~40805 | 2 | 10013, 10014 | 메두사1, 바포메트2 |
-| 9 | WM2 | 6 | 40901~40906 | 2 | 10014, 10015 | 바포메트2, 트롤워리어4 |
-| 10 | WM2 | 5 | 51001~51005 | 1 | 10016 | 흑기사3 |
-| 11 | WM3 | 5 | 51101~51105 | 2 | 10016, 10017 | 흑기사3, 흡혈귀여왕2 |
-| 12 | WM3 | 7 | 51201~51207 | 3 | 10016, 10017, 10018 | 흑기사3, 흡혈귀여왕2, 에티4 |
-| 13 | WM3 | 4 | 61301~61304 | 1 | 10019 | 레드드래곤3 |
-| 14 | WM3 | 5 | 61401~61405 | 2 | 10019, 10020 | 레드드래곤3, 메두사2 |
-| 15 | WM3 | 5 | 61501~61505 | 2 | 10020, 10021 | 메두사2, 흑기사1 |
-| 16 | WM4 | 3 | 61601~61603 | 3 | 10019, 10020, 10021 | 레드드래곤3, 메두사2, 흑기사1 |
-| 17 | WM4 | 8 | 71701~71708 | 2 | 10022, 10023 | 용암골렘2, 레드드래곤1 |
-| 18 | WM4 | 8 | 71801~71808 | 3 | 10022, 10023, 10024 | 용암골렘2, 레드드래곤1, 바포메트7 |
-| 19 | WM4 | 9 | 81901~81909 | 2 | 10025, 10026 | 거미여왕1, 데스나이트1 |
-| 20 | WM4 | 9 | 82001~82009 | 3 | 10025, 10027, 10028 | 거미여왕1, 레드드래곤4, 타락한천사 |
-| 21 | WM4 | 4 | 82101~82104 | 2 | 10027, 10028 | 레드드래곤4, 타락한천사 |
-
-**스테이지당 서브맵 수 변화:** 4→6→5→7→6→7→4→5→6→5→5→7→4→5→5→3→8→8→9→9→4
-
----
-
-## 3. 보스 몬스터 스탯 (스테이지 순서)
-
-> 컬럼: 보스ID | 보스명 | 보스순번 | HP | Shield | ATK(Min-Max) | EXP | 등장스테이지
-
-| 보스ID | 보스명 | HP | Shield | ATKMin | ATKMax | ATK평균 | EXP | 등장Stage |
-|--------|--------|-----|--------|--------|--------|---------|-----|----------|
-| 10001 | 놀아처1 | 20 | 15 | 4 | 6 | 5.0 | 10 | 1 |
-| 10002 | 놀강도2 | 30 | 22 | 6 | 8 | 7.0 | 15 | 1, 2 |
-| 10003 | 임프전사1 | 42 | 16 | 6 | 9 | 7.5 | 21 | 2 |
-| 10004 | 오우거1 | 112 | 0 | 7 | 30 | 18.5 | 56 | 2 |
-| 10005 | 바포메트6 | 53 | 66 | 7 | 11 | 9.0 | 26 | 3 |
-| 10006 | 거미여왕2 | 58 | 72 | 7 | 10 | 8.5 | 29 | 3, 4 |
-| 10007 | 흑기사2 | 66 | 52 | 8 | 15 | 11.5 | 33 | 4 |
-| 10008 | 늑대인간 | 85 | 0 | 7 | 9 | 8.0 | 42 | 4 |
-| 10009 | 대사탄1 | 88 | 60 | 12 | 20 | 16.0 | 44 | 5 |
-| 10010 | 다크엘프아처1 | 35 | 282 | 18 | 20 | 19.0 | 17 | 5 |
-| 10011 | 대사탄2 | 102 | 72 | 13 | 21 | 17.0 | 51 | 6 |
-| 10012 | 데스나이트3 | 97 | 77 | 13 | 14 | 13.5 | 48 | 6 |
-| 10013 | 메두사1 | 84 | 223 | 14 | 16 | 15.0 | 42 | 7, 8 |
-| 10014 | 바포메트2 | 106 | 108 | 16 | 28 | 22.0 | 53 | 8, 9 |
-| 10015 | 트롤워리어4 | 138 | 0 | 19 | 45 | 32.0 | 69 | 9 |
-| 10016 | 흑기사3 | 121 | 100 | 26 | 34 | 30.0 | 60 | 10, 11, 12 |
-| 10017 | 흡혈귀여왕2 | 91 | 315 | 20 | 23 | 21.5 | 45 | 11, 12 |
-| 10018 | 에티4 | 158 | 0 | 30 | 45 | 37.5 | 79 | 12 |
-| 10019 | 레드드래곤3 | 142 | 111 | 20 | 48 | 34.0 | 71 | 13, 14, 16 |
-| 10020 | 메두사2 | 118 | 230 | 25 | 28 | 26.5 | 59 | 14, 15, 16 |
-| 10021 | 흑기사1 | 149 | 120 | 36 | 45 | 40.5 | 74 | 15, 16 |
-| 10022 | 용암골렘2 | 63 | 525 | 33 | 62 | 47.5 | 31 | 17, 18 |
-| 10023 | 레드드래곤1 | 170 | 128 | 26 | 82 | 54.0 | 85 | 17, 18 |
-| 10024 | 바포메트7 | 165 | 132 | 32 | 36 | 34.0 | 82 | 18 |
-| 10025 | 거미여왕1 | 170 | 136 | 30 | 34 | 32.0 | 85 | 19, 20 |
-| 10026 | 데스나이트1 | 176 | 142 | 26 | 38 | 32.0 | 88 | 19 |
-| 10027 | 레드드래곤4 | 182 | 146 | 22 | 98 | 60.0 | 91 | 20, 21 |
-| 10028 | 타락한천사 | 184 | 182 | 43 | 46 | 44.5 | 92 | 20, 21 |
-
----
-
-## 4. 스테이지별 보스 평균 스탯 (난이도 곡선 데이터)
-
-| Stage | 보스HP평균 | 보스Shield평균 | 보스ATK평균 | 보스EXP평균 | HP+Shield합계 |
-|-------|-----------|--------------|------------|------------|--------------|
-| 1 | 25.0 | 18.5 | 6.0 | 12.5 | 43.5 |
-| 2 | 61.3 | 12.7 | 11.0 | 30.7 | 74.0 |
-| 3 | 55.5 | 69.0 | 8.8 | 27.5 | 124.5 |
-| 4 | 86.3 | 41.3 | 12.7 | 34.7 | 127.6 |
-| 5 | 61.5 | 171.0 | 17.5 | 30.5 | 232.5 |
-| 6 | 99.5 | 74.5 | 15.3 | 49.5 | 174.0 |
-| 7 | 84.0 | 223.0 | 15.0 | 42.0 | 307.0 |
-| 8 | 95.0 | 165.5 | 18.5 | 47.5 | 260.5 |
-| 9 | 122.0 | 54.0 | 27.0 | 61.0 | 176.0 |
-| 10 | 121.0 | 100.0 | 30.0 | 60.0 | 221.0 |
-| 11 | 106.0 | 207.5 | 25.8 | 52.5 | 313.5 |
-| 12 | 124.7 | 164.3 | 29.7 | 61.3 | 289.0 |
-| 13 | 142.0 | 111.0 | 34.0 | 71.0 | 253.0 |
-| 14 | 130.0 | 170.5 | 30.3 | 65.0 | 300.5 |
-| 15 | 133.5 | 175.0 | 33.5 | 66.5 | 308.5 |
-| 16 | 136.3 | 153.7 | 33.7 | 68.0 | 290.0 |
-| 17 | 116.5 | 326.5 | 50.8 | 58.0 | 443.0 |
-| 18 | 132.7 | 253.7 | 45.2 | 66.0 | 386.4 |
-| 19 | 173.0 | 139.0 | 32.0 | 86.5 | 312.0 |
-| 20 | 145.3 | 154.7 | 45.7 | 89.3 | 300.0 |
-| 21 | 183.0 | 164.0 | 52.3 | 91.5 | 347.0 |
-
----
-
-## 5. 일반 몬스터 종족별 스탯 범위 및 등장 스테이지
-
-### 몬스터 종족 체계 (등장 스테이지 순서)
-
-| 종족 | 주요 등장 Stage | 대표 ID 범위 | HP 범위 | ATK 범위 | Shield |
-|------|----------------|-------------|---------|---------|--------|
-| 수인형 (놀/미노타우르스 초기) | 1~2 | 11001~11031 低 | 1~6 | 1~9 | 0~1 |
-| 마법생물 초기 (슬라임/박쥐/쥐) | 1~2 | 14001~14022 低 | 2~6 | 2~7 | 0 |
-| 인간형 초기 (오크/강도/고블린) | 3~6 | 12028~12036 | 4~10 | 3~13 | 0 |
-| 언데드 초기 (데스/머미/해골) | 7~9 | 13004~13031 中低 | 8~26 | 8~25 | 0 |
-| 마법생물 중기 (임프/구울/다이어울프) | 10~12 | 14007~14034 | 14~32 | 9~28 | 0~15 |
-| 인간형 고급 (강도/광전사) | 13~16 | 12001~12026 | 14~38 | 3~60 | 0 |
-| 언데드 고급 (해골기사/악마추종자) | 13~16 | 13018~13034 | 18~42 | 11~42 | 0 |
-| 마법생물 고급 (켄타우로스/타이가/리자드맨) | 17~18 | 14004~14033 高 | 22~45 | 23~52 | 0 |
-| 거인족 (헤츨링/예티/오우거/트롤) | 19~21 | 15001~15019 | 23~62 | 21~184 | 0 |
-
-### 스테이지별 일반 몬스터 평균 HP(추정)
-
-| Stage | 등장 종족 | 일반몬 HP(추정범위) | 일반몬 ATK(추정범위) |
-|-------|----------|-------------------|-------------------|
-| 1 | 수인형低+마법생물低 | 1~5 | 1~5 |
-| 2 | 수인형低+마법생물低 | 2~6 | 2~7 |
-| 3 | 오크+수인형中 | 4~10 | 3~9 |
-| 4 | 오크+수인형中 | 4~10 | 3~11 |
-| 5 | 고블린+인간형 | 5~13 | 7~16 |
-| 6 | 고블린+인간형+다크엘프 | 5~18 | 7~18 |
-| 7 | 언데드低 (데스/해골/머미) | 8~26 | 8~21 |
-| 8 | 언데드低+언데드中 | 8~26 | 8~25 |
-| 9 | 언데드中+인간형中 | 8~26 | 10~35 |
-| 10 | 임프+마법생물中 | 14~32 | 12~28 |
-| 11 | 임프+마법생물中 | 14~32 | 12~31 |
-| 12 | 임프+다크엘프+예티 | 13~32 | 10~31 |
-| 13 | 인간형高+언데드中 | 17~38 | 11~38 |
-| 14 | 인간형高+언데드高 | 17~38 | 11~38 |
-| 15 | 인간형高+언데드高 | 17~38 | 11~53 |
-| 16 | 인간형高+언데드高 (혼합) | 17~38 | 11~53 |
-| 17 | 마법생물高 (켄타우로스/타이가 등) | 20~45 | 19~52 |
-| 18 | 마법생물高 (임프마법사/하피 포함) | 20~45 | 19~52 |
-| 19 | 거인족 (바포메트/예티/오우거 등) | 23~62 | 34~156 |
-| 20 | 거인족 (혼합) | 23~62 | 21~156 |
-| 21 | 거인족 (바포메트/오우거 혼합) | 25~50 | 34~104 |
-
----
-
-## 6. 노드 타입 분포 (RandomPatternConfig 기반)
-
-RandomPatternConfig에는 스테이지별 랜덤 패턴 ID 1~30이 정의되어 있으며, 각 패턴의 비율은 10000 기준으로 표시됩니다.
-
-### 주요 랜덤패턴 노드 비율 요약 (10000 기준)
-
-| 패턴ID | 패턴명 | 몬스터% | 빈노드% | 성소(캠프)% | 상인% | 보물% | NPC% | 갈림길% | MonsterLimit |
-|--------|--------|---------|---------|-----------|------|------|------|---------|-------------|
-| 1 | 암굴 동굴 | 32.0 | 60.0 | 5.0 | 0.3 | 0.6 | 0.3 | 1.8 | 15 |
-| 2 | 횃불 지하묘 | 34.0 | 56.0 | 5.0 | 0.4 | 0.6 | 0.4 | 2.0 | 16 |
-| 3 | 해골 감옥 | 32.0 | 55.0 | 5.0 | 0.4 | 2.0 | 0.4 | 2.2 | 16 |
-| 4 | 성스러운 대성당 | 28.0 | 54.0 | 5.0 | 0.8 | 1.2 | 4.0 | 3.0 | 14 |
-| 5 | 따뜻한 지하 | 34.0 | 53.0 | 5.0 | 0.6 | 1.6 | 0.6 | 2.7 | 16 |
-| 6 | 어두운 숲 | 40.0 | 48.0 | 5.0 | 0.3 | 1.0 | 0.4 | 2.3 | 18 |
-| 7 | 포자 이끼 동굴 | 36.0 | 46.0 | 5.0 | 0.4 | 1.2 | 0.4 | 2.0 | 17 |
-| 8 | 혈흔 숲 | 42.0 | 44.0 | 5.0 | 0.3 | 1.2 | 0.4 | 1.9 | 18 |
-| 9 | 고딕 대성당 | 29.0 | 50.0 | 5.0 | 5.0 | 2.0 | 5.0 | 2.2 | 14 |
-| 10 | 황금 동굴 | 30.0 | 51.0 | 5.0 | 5.0 | 6.0 | 0.5 | 2.0 | 15 |
-| 11 | 서릿날 평원 | 43.0 | 45.0 | 5.0 | 0.4 | 1.5 | 0.4 | 1.8 | 18 |
-| 12 | 겨울 숲 | 42.0 | 46.0 | 5.0 | 0.5 | 1.5 | 0.6 | 1.9 | 18 |
-| 13 | 룬각 감옥 | 38.0 | 43.0 | 5.0 | 0.4 | 2.0 | 0.5 | 2.1 | 17 |
-| 14 | 몰락한 왕궁 | 29.0 | 48.0 | 5.0 | 6.0 | 5.0 | 5.0 | 1.7 | 14 |
-| 15 | 피의 제단 | 48.0 | 40.0 | 5.0 | 0.3 | 1.5 | 0.4 | 1.0 | 20 |
-| 16 | 고요한 숲길 | 28.0 | 52.0 | 5.0 | 2.0 | 2.0 | 3.0 | 3.0 | 13 |
-| 17 | 수정 동굴 | 33.0 | 48.0 | 5.0 | 0.6 | 4.0 | 0.4 | 2.0 | 16 |
-| 18 | 폐광 | 35.0 | 48.0 | 5.0 | 0.5 | 3.0 | 0.4 | 2.1 | 16 |
-| 19 | 화염 지하 | 47.0 | 40.0 | 5.0 | 0.4 | 2.0 | 0.4 | 1.7 | 19 |
-| 20 | 설산 복도 | 44.0 | 41.0 | 5.0 | 0.5 | 2.0 | 0.5 | 4.0 | 19 |
-| 21 | 용암 심연 | 52.0 | 38.0 | 5.0 | 0.3 | 2.0 | 0.3 | 0.9 | 20 |
-| 22 | 엘리트 러시 | 65.0 | 25.0 | 2.0 | 0.0 | 3.0 | 0.0 | 2.0 | 25 |
-| 23 | 보물 쇄도 | 15.0 | 55.0 | 2.0 | 3.0 | 15.0 | 0.5 | 2.5 | 8 |
-| 24 | 상인 순회 | 13.0 | 55.0 | 2.0 | 15.0 | 4.0 | 3.0 | 2.0 | 7 |
-| 25 | 성소 성역 | 18.0 | 52.0 | 4.0 | 2.0 | 3.0 | 4.0 | 3.0 | 9 |
-| 26 | 함정 미궁 | 33.0 | 42.0 | 2.0 | 0.3 | 3.5 | 0.4 | 2.0 | 16 |
-| 27 | 보스 예고 | 56.0 | 38.0 | 3.0 | 0.3 | 0.8 | 0.3 | 0.5 | 22 |
-| 28 | 휴식과 재정비 | 18.0 | 60.0 | 3.0 | 3.5 | 3.0 | 2.5 | 2.0 | 9 |
-| 29 | 혼돈의 조각 | 38.0 | 40.0 | 4.0 | 3.0 | 4.0 | 2.0 | 2.0 | 17 |
-| 30 | 시련의 교차로 | 36.0 | 42.0 | 2.0 | 1.2 | 3.0 | 1.2 | 7.0 | 17 |
-
-> 패턴 1~21: 일반 스테이지용 (n_PatternRate=500, 5% 확률로 해당 서브맵 전체에 적용)  
-> 패턴 22~30: 특수 패턴 (n_PatternRate=200, 2% 확률)
-
----
-
-## 7. 난이도 곡선 핵심 수치
-
-### 보스 HP 증가 곡선
-
-```
-Stage:  1    2    3    4    5    6    7    8    9   10   11   12   13   14   15   16   17   18   19   20   21
-HP평균: 25   61   56   86   62  100   84   95  122  121  106  125  142  130  134  136  117  133  173  145  183
-```
-
-### 보스 ATK 평균 증가 곡선
-
-```
-Stage:  1    2    3    4    5    6    7    8    9   10   11   12   13   14   15   16   17   18   19   20   21
-ATK평균: 6   11    9   13   18   15   15   19   27   30   26   30   34   30   34   34   51   45   32   46   52
-```
-
-### 보스 HP+Shield 합산 (실질 내구도)
-
-```
-Stage:   1    2    3    4    5    6    7    8    9   10   11   12   13   14   15   16   17   18   19   20   21
-내구도:  44   74  125  128  233  174  307  261  176  221  314  289  253  301  309  290  443  386  312  300  347
-```
-
----
-
-## 8. 이상 탐지 (급격한 난이도 점프 / 비정상적 값)
-
-### 8-1. 보스 HP 역전 현상
-
-| 구간 | 이상 유형 | 세부 내용 |
-|------|---------|---------|
-| Stage 4→5 | HP 급락 | Stage4 평균HP 86 → Stage5 62 (다크엘프아처1 HP35+Shield282로 설계된 패턴, 내구도는 높음) |
-| Stage 6→7 | HP 소폭 하락 | Stage6 평균HP 100 → Stage7 84 (메두사1은 Shield223, 총내구도 307로 오히려 역대 최고) |
-| Stage 9→10 | HP 거의 동일 | Stage9 122 → Stage10 121 (연속성 OK) |
-| Stage 11→12 | 정상 상승 | 106 → 125 |
-| Stage 12→13 | 소폭 상승 | 125 → 142 |
-| Stage 17 | HP 급락 | Stage16 136 → Stage17 117 (용암골렘2 HP63+Shield525로 내구도는 443, 역대 최고) |
-| Stage 19→20 | HP 급락 | Stage19 173 → Stage20 145 (보스 수 3체로 증가하여 총 전투량 증가) |
-
-### 8-2. 내구도(HP+Shield) 급등 구간
-
-| 구간 | 내구도 변화 | 비고 |
-|------|-----------|------|
-| Stage 4→5 | 128→233 (+82%) | 다크엘프아처1 Shield 282가 원인 |
-| Stage 6→7 | 174→307 (+76%) | 메두사1 Shield 223이 원인 |
-| Stage 10→11 | 221→314 (+42%) | 흡혈귀여왕2 Shield 315 추가 |
-| Stage 16→17 | 290→443 (+53%) | 용암골렘2 Shield 525가 원인 |
-
-### 8-3. 서브맵 수 이상
-
-| Stage | 서브맵 수 | 특이사항 |
-|-------|---------|---------|
-| Stage 7 | 4 | WorldMap2 시작인데 가장 짧음 |
-| Stage 13 | 4 | WorldMap3 중반인데 급감 |
-| Stage 16 | 3 | 역대 최소 (WM4 시작 전 숨 고르기?) |
-| Stage 21 | 4 | 최종 스테이지인데 짧음 |
-| Stage 19~20 | 9 | 역대 최대 서브맵, 보스 3체 동반 |
-
-### 8-4. 보스 재사용 패턴
-
-여러 스테이지에서 동일 보스가 반복 등장하는 구간:
-- 10002(놀강도2): Stage 1 & 2
-- 10006(거미여왕2): Stage 3 & 4
-- 10013(메두사1): Stage 7 & 8
-- 10014(바포메트2): Stage 8 & 9
-- 10016(흑기사3): Stage 10 & 11 & 12 (3회!)
-- 10019(레드드래곤3): Stage 13, 14, 16 (3회!)
-- 10022(용암골렘2): Stage 17 & 18
-- 10023(레드드래곤1): Stage 17 & 18
-- 10025(거미여왕1): Stage 19 & 20
-- 10027(레드드래곤4): Stage 20 & 21
-- 10028(타락한천사): Stage 20 & 21
-
-> **주의:** 10016(흑기사3), 10019(레드드래곤3)가 각각 3개 스테이지에서 반복 사용. 단순히 보스풀만 보면 22단계에 보스 28종이 존재하지만 실제 배치는 중복 사용이 많음. **레드드래곤 계열(10019, 10023, 10027)과 타락한천사(10028)가 후반 보스로 집중 배치됨.**
-
-### 8-5. 오우거1(10004) 이상값
-
-- Stage 2의 3번째 보스로 등장
-- HP 112 (Stage1 보스 최고 HP 30의 3.7배)
-- ATKMax 30 (동일 Stage2의 임프전사1 ATKMax 9의 3.3배)
-- Stage2 내에서 극단적 난이도 격차 발생 → **Stage2 마지막 서브맵이 갑자기 최난도**
-
-### 8-6. 용암골렘2(10022) Shield 이상값
-
-- Shield 525로 전 보스 중 최고
-- Stage17 보스 중 하나로, HP는 63에 불과해 HP만 보면 중간 난이도처럼 보임
-- 실제 내구도(HP+Shield)는 588로 **단일 보스 최강**
-- Stage17은 전체 내구도가 443으로 역대 1위
-
----
-
-## 9. 종합 난이도 구간 평가
-
-| 구간 | Stage | 난이도 단계 | 특징 |
-|------|-------|-----------|------|
-| 입문 | 1~2 | 쉬움 | 수인형+마법생물 초기, 보스HP 25~61 |
-| 초반 | 3~4 | 보통 | 오크/수인형 中, 보스HP 56~86 |
-| 중반 시작 | 5~6 | 보통↑ | Shield가 높은 보스 등장, 내구도 174~233 |
-| 중반 전환 | 7~9 | 어려움 시작 | 언데드 등장, Shield 보스 급증, 내구도 176~307 |
-| 중반 심화 | 10~12 | 어려움 | 임프+다크엘프 혼합, 보스 ATK 30+ |
-| 후반 진입 | 13~16 | 매우 어려움 | 인간형高+언데드 혼합, 보스 3체 구간 |
-| 후반 | 17~18 | 매우 어려움↑ | 마법생물高, Shield 폭증(용암골렘 525) |
-| 최종 | 19~21 | 최고 난이도 | 거인족, 보스HP 170~184, ATK 44~60 |
-
----
-
-*분석 완료: 2026-04-13*  
-*분석자: Claude (데이터 자동 추출 및 계산)*
-
----
-
-## 변경 이력 (P16 산출물 추적성)
-
-> **표준 포맷 (2026-04-17 도입)**: 밸런싱 관련 문서 4종 공통 적용. 본 문서의 수치·구간·난이도 평가가 변경될 때마다 아래 테이블에 1행 append.
-> **필드 설명**: 변경 필드 = 어떤 구간·스테이지·수치인가 / 이전값→이후값 = 구체 수치 / 재미 근거 = C7 원칙에 따른 재미 강화 축 / 관련 PD 지시# = `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`의 해당 #
-
-| 일시 | 변경자 | 변경 필드 | 이전값→이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|---------|-------------|----------|-------------|
-| 2026-04-17 | 기획팀장 | 변경 이력 테이블 섹션 신설 | - → 기존 상태 확정 | 산출물 추적성 확보 (P16), 차기 밸런스 변경 시 근거 비교 가능 | 본 작업 (팀장 재량 진행 승인) |
diff --git a/프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md b/프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md
deleted file mode 100644
index ffff265..0000000
--- a/프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md
+++ /dev/null
@@ -1,488 +0,0 @@
----
-type: PD결정확정문서
-작성일: 2026-04-20
-최종보강일: 2026-04-20 (Day 8-1·8-2 "현 상태 기록 · 재조사 불요 수준" PD 지시 집행)
-작성자: 기획팀장 (PM → PD님 A안 결정 수령·집행)
-관련PD지시: 기획팀 #3 Day 8~10 · PD 2026-04-20 A안 수용 결정 · PD 2026-04-20 "8-1·8-2 현 상태 기록해서 향후 재조사 불요하게 해" 지시
-상태: **확정** (재논의 대상 아님 · 트리거 §5 참조) · §3 재조사 불요 수준 보강 완료
-선행문서:
-  - 이슈1_3_통합재논의_v1_초안.md (2026-04-20 · A-초안 · 아카이브 전환)
-  - 재논의대기_사전자료모음_v1.md (2026-04-14)
-  - 재논의대기_논점재정리_v1.md (2026-04-20)
-  - Phase3_성장요소기여도_v2.md (Day 4~7 완료)
-  - Phase2_카드임팩트측정_v1.md (§2~§5 원본 — §3-1~§3-2 보강 1차 근거)
-  - 카드시너지축분석_v1.md (§2 축 1 신성 폭격 — §3-2-1 신성 전체 분포 근거)
-  - 밸런싱전략_v1.md (§1·§3 — §3-1-1·§3-1-5·§3-1-7 근거)
-  - 전체테이블감사_v1.md (§427 성스러운 피해 6장 — §3-2-1 참조처)
-  - 공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md (UTF 14/14 — §3-1-6 근거)
----
-
-# 이슈 1·3 무시 확정 v1 (PD 결정 2026-04-20)
-
-## §1. PD 결정 원문 (2026-04-20)
-
-PD님께서 Day 8~10 A안(간략화 종결)을 수용하시며 다음과 같이 직접 결정하셨다.
-
-> **"이슈 1·3은 일부 빌드 특성 + 인장·장비·각성 등 다양한 성장 시너지를 고려할 때 무시해도 될 문제다. Day 8~10은 A안으로 진행하여 간략화 종결한다."**
-> — PD님 직접 지시 (2026-04-20)
-
-- **결정 대상**: 이슈 1 (카드 G1 풀빌드 DPS +200~280%) · 이슈 3 (신성 빌드 G4/G5 확장성)
-- **결정 결과**: **현 수치 그대로 유지** · 조정 불요 확정
-- **집행 방식**: Day 8~10 A안 (간략화 종결) · 정식 재검증 리포트·카드 메커닉 시뮬 구현·PD 결정 안건 상정 **모두 불요**
-
----
-
-## §2. 무시 근거
-
-### §2-1. PD 논거 (원문 인용)
-
-1. **일부 빌드 특성** — 카드 G1 풀빌드는 **특화 빌드**이며, 전 빌드 대상이 아니다
-2. **다양한 성장 시너지** — 인장·장비·각성·진화 등 아웃게임 성장 요소가 상호 보완하여 단일 빌드 지배를 자연 완화한다
-3. **성장 순서 원칙(#21) 실측 확인** — Phase 3 Day 4~7 재검증(`Phase3_성장요소기여도_v2.md`)에서 카드 > 세트장비 > 각성 > 진화 > 장비일반 > 인장 순서가 Unity MCP UTF 14/14로 부합 확인됨
-
-### §2-2. 기획팀 부연 (PD 논거 보완)
-
-1. **빌드 특화 = 게임 재미 축** — 모든 빌드가 동일 DPS로 수렴하는 것이 아니라, 카드 빌드는 "Balatro류 빌드 폭발 쾌감"이라는 **고유 포지션**을 가진다. 특정 빌드의 피크 DPS가 다른 빌드보다 높은 것은 **설계 의도**이지 버그가 아니다 (P30 재미 축 2)
-2. **성장 시너지 다면 구조** — 카드는 단일 축이 아닌 **카드 × 장비 × 각성 × 진화 × 인장**의 5축 시너지 중 1축. 실측(Phase 3 v2) 기준 카드 지배율은 **순서 원칙 범위 내**에서 작동. 이슈 1의 "카드 과도 체감"은 카드 단독 시뮬 결과이지 5축 결합 실플레이 체감이 아님
-3. **신성 빌드 "접근성 친화" 포지션 수용** — 이슈 3의 "G4/G5 확장성 부족"은 신성 빌드가 캐주얼 접근성 포지션이라는 **설계 의도**와 정합. 모든 빌드가 극레어 폭발 쾌감을 가질 필요 없음 (빌드 다양성 = 재미 축 3)
-
----
-
-## §3. 현 수치 그대로 유지 선언 (재조사 불요 수준 실측 보강 — 2026-04-20 PD 지시 "향후 재조사 필요하지 않도록 기록")
-
-> **본 §3은 2026-04-20 PD님 직접 지시로 "향후 재조사 불요 수준"까지 보강된다.** 본 문서 재독만으로 이슈 1·3의 현 수치·카드 구성·빌드 분포·기각안 논거 전체를 재구성할 수 있도록 한다. Phase 2 원본(`Phase2_카드임팩트측정_v1.md`)·Phase 3 v2 실측(`Phase3_성장요소기여도_v2.md` · Unity MCP UTF 14/14)·카드시너지축분석(`카드시너지축분석_v1.md`)·밸런싱전략(`밸런싱전략_v1.md`)·전체테이블감사(`전체테이블감사_v1.md`) 5종 원본의 핵심 정량 수치를 본 섹션에 응축 이식한다.
-
-### §3-1. 이슈 1 (카드 G1 풀빌드) — 현 상태 전수 기록
-
-#### §3-1-1. 카드 등급별 기본 분포 (Phase2 §2 · 전수 확정)
-
-| 등급 | 카드 풀 | 드래프트 가중치 | 등장 확률 | 1런(19회 선택) 기대 장수 | 평균 DPS 기여/장 | DPS 증가율/장 | 평균 EHP 기여/장 | 파워 구조 |
-|------|---------|---------------|----------|----------------------|-----------------|-------------|----------------|----------|
-| **G1** | **112장** | 1000 | **66.2%** | **12.6장** | +0.23 | **+22%** | +1.6 | 양적 증가 (Incremental) |
-| **G2** | **73장** | 300 | **19.9%** | **3.8장** | +0.26 | **+25%** | +1.1 | 양적 증가 |
-| **G3** | **51장** | 150 | **9.9%** | **1.9장** | +0.10 | **+9%** | +1.0 | 과도기 (Transitional) — 공속+25%·MaxHP 2배·크리데미지 x2.5 |
-| **G4** | **43장** | 50 | **3.3%** | **0.6장** | +0.13 | **+13%** | +1.1 | 질적 도약 (Transformational) — 크리확률+15%·보호막 시 피해 50% 감소·처치시 최종데미지+50% |
-| **G5** | **32장** | 10 | **0.66%** | **0.1장** | +0.09 | **+9%** | +1.2 | 게임 전환 (Game-Changing) — 사망시 부활(40%)·7.5초 무적·전체 기절 8.5초·모든 피해 반사 |
-| **총** | **311장** | — | 100% | 19장 | — | — | — | 이중 구조 (G1~G2 양적 + G3~G5 질적) |
-
-**G3~G5 수치상 낮은 이유** (Phase2 §2 확정): G3~G5 카드의 s_Value1/2가 대부분 0. 효과가 수치가 아니라 **메커닉 전환**이기 때문. 이 이중 구조는 Balatro류 설계에 적합하며 조정 대상 아님.
-
-#### §3-1-2. G1 풀빌드 DPS +399% 산출 과정 (Phase2 §3 전수 기록)
-
-**앵커 조건** (Phase0_1 §1 고정 참조점):
-- PC 6001 Lv.1 / 각성 0 / 장비 0 / 인장 0 / Stage 1
-- PC DPS: **1.05** (ATK 평균 2.5 / CT 2.4s)
-- PC EHP: **64** (HP 58 + Shield 6)
-- TTK vs Stage 1 일반 몬스터(HP 6.9): **5.7초**
-
-**G1 풀빌드(19장) 누적 임팩트**:
-
-| 보유 카드 수 | 총 DPS | TTK | TTK 감소율 | 총 EHP | EHP 증가율 | 비고 |
-|------------|-------|------|----------|--------|----------|------|
-| 0장 (앵커) | 1.05 | 5.7s | 기준 | 64 | 기준 | 카드 없음 |
-| 1장 | 1.28 | 5.4s | -6% | 65.6 | +3% | 첫 레벨업 |
-| 3장 | 1.74 | 4.0s | -31% | 68.8 | +8% | — |
-| **5장** | **2.21** | **3.1s** | **-45%** | **72.0** | **+13%** | **밸런싱 목표 범위 적중** (30~50%) |
-| 10장 | 3.36 | 2.1s | -64% | 80.0 | +25% | — |
-| **19장 (풀)** | **5.44** | **1.3s** | **-78%** | **94.4** | **+48%** | 이론 풀빌드 |
-
-**실전 드래프트(등급 혼합 1런 19장) 산출**:
-
-| 등급 | 기대 장수 | DPS 기여 합 | EHP 기여 합 |
-|------|---------|-----------|-----------|
-| G1 (66.2%) | 12.6장 | +2.91 | +20.2 |
-| G2 (19.9%) | 3.8장 | +1.00 | +4.2 |
-| G3 (9.9%) | 1.9장 | +0.19 | +2.0 |
-| G4 (3.3%) | 0.6장 | +0.08 | +0.6 |
-| G5 (0.66%) | 0.1장 | +0.01 | +0.1 |
-| **합계** | **19장** | **+4.19** | **+27.1** |
-
-- **최종 DPS**: 1.05 + 4.19 = **5.24** (기본 대비 **+399%**)
-- **최종 EHP**: 64 + 27.1 = **91.1** (기본 대비 **+42%**)
-- **최종 TTK**: 5.7s → **1.3s** (감소 **77%**)
-
-#### §3-1-3. 실전 추정 +200~280% 산출 근거 (Phase2 §5 이슈 1 단서조항)
-
-이론치 +399%는 "모든 카드가 DPS에 기여한다"는 가정 하의 수치. 실전에서는:
-
-1. **힐·쉴드 카드 DPS 기여 0**: 힐 56장(전체의 18%) · 보호막 11장(3.5%) 카드는 드래프트 선택 시 DPS에 직접 기여하지 않음
-2. **드래프트 트레이드오프**: DPS↔EHP 선택 시 한 쪽만 풀 기여 가능
-3. **질적 효과(G3~G5) 미포함**: 기절·반사·부활·무적·MaxHP2배 등은 수치 계산 외
-4. **실전 DPS 증가율 추정치**: 이론치의 **50~70% 수준** = **+200~280%**
-
-**실측 불확실성 범위**:
-- **하한** (+200%): 힐·쉴드 비중 극대(힐 4~5장 선택 시)·질적 효과 미승수 시나리오
-- **중앙** (+240%): 평균 빌드 혼합 시나리오
-- **상한** (+280%): DPS 특화 드래프트·G3~G5 질적 효과 부분 승수 시나리오
-
-**실측 부재 상태**: 카드 메커닉 Unity MCP 시뮬 미구현으로 본 추정치는 Python 사전 분석 기반. Day 8-3 카드 메커닉 시뮬 구현 REQ **취소**(본 확정 §3-1-6)에 따라 실측 부재 상태로 **"+200~280% 추정치" 유지 확정**.
-
-#### §3-1-4. 빌드별 G4+G5 분포 비교 (Phase2 §4 전수)
-
-| 빌드 | 총 카드 풀 | 1런 기대 선택수 | **G4+G5 카드 수** | **1런 G4+G5 기대** | 10런에 1장+ | 난이도 | 포지션 |
-|------|----------|--------------|------------------|-------------------|-------------|--------|-------|
-| 힐/회복 | 56장 | 4.09장 | 9장 | 0.110장 | ~67% | EASY | 생존 안정 |
-| 보호막/생존 | 50장 | 3.26장 | 11장 | 0.118장 | ~70% | EASY | 생존 안정 |
-| 처치 연쇄 | 56장 | 3.15장 | **15장** | **0.165장** | ~81% | EASY | 폭발 연쇄 (Balatro류 핵심) |
-| 회피 | 44장 | 3.02장 | 7장 | 0.059장 | ~45% | EASY | 럭 기반 생존 |
-| 원거리 | 36장 | 1.95장 | 7장 | 0.081장 | ~56% | MEDIUM | 안전 딜 |
-| **신성 폭격** | **22장** | **1.71장** | **2장** | **0.019장** | **~17%** | **MEDIUM** | **접근성 친화 (캐주얼)** |
-| **치명타** | 35장 | 1.14장 | **19장** (최다) | **0.192장** (최다) | ~85% | MEDIUM | **극레어 폭발 (럭 기반)** |
-| 첫타 버스트 | 17장 | 1.14장 | 3장 | 0.033장 | ~28% | MEDIUM | 빠른 처치 |
-| 물약 | 25장 | 1.11장 | 10장 (G5에 7장 집중) | 0.071장 | ~51% | MEDIUM | ★2 조건 충돌 트레이드오프 |
-| 번개 | 16장 | 1.10장 | 4장 | 0.037장 | ~31% | MEDIUM | CC 특화 |
-
-**핵심 관찰**:
-1. 치명타 빌드는 G4+G5에 19장(최다) — **의도된 극레어 럭 기반 빌드** (feedback_card_balance_rules.md 확정)
-2. 신성 빌드는 G4+G5에 2장뿐 — **의도된 접근성 친화(캐주얼) 빌드** (대조 포지션)
-3. 두 빌드의 극단 대비가 **빌드 다양성이라는 상위 재미**를 형성 (§7 재미 관점 연결)
-
-#### §3-1-5. 스테이지·Chapter별 영향 강도 (밸런싱전략_v1 §3 Phase 4 전수)
-
-| 월드·Chapter | 스테이지 | 설계 목표 | 카드 G1 풀빌드 발현 강도 | 판정 |
-|-------------|---------|----------|----------------------|------|
-| 월드1 (Chapter 1) | Stage 1~6 | 성장 없이 G1 카드만으로 ★1 가능 | **가장 강함** — 앵커 조건이 이 구간 기준 | 의도된 설계 |
-| 월드2 (Chapter 2) | Stage 7~10 | 약간의 각성+장비가 필요 | 카드 우위 유지 + 각성 가산 시작 | 의도 부합 |
-| 월드3 (Chapter 3) | Stage 11~15 | 장비 맞추기 필수 | 카드 단독 부족 · 장비 세트 완성(+70% 실측) 결합 필요 | 의도 부합 |
-| 월드4 (Chapter 4) | Stage 16~21 | 세트 장비+인장이 ★2·★3에 영향 | 카드 기여도 상대 감소 · 5축 시너지 필수 | 의도 부합 |
-
-**카드 풀빌드 발현이 가장 두드러지는 구간 = 월드1(Stage 1~6)** — 하지만 이는 **"초보 구간이라 카드만으로 ★1 가능"**이 설계 목표이므로 **문제 아닌 의도**.
-
-#### §3-1-6. 아웃게임 성장 시너지 상호 보완 정량 (Phase 3 v2 UTF 14/14 실측 기록)
-
-**Unity MCP EditMode 실측** (DeckBuilding commit `7bb1facd2` · UTF 14/14 Passed · 2026-04-20 E-1 수집):
-
-| # | 성장 요소 | 기획 가정 중앙값 | Unity MCP 실측 DPS ratio | 실측 오차 | 판정 |
-|---|---------|---------------|------------------------|---------|------|
-| #16 | 각성 만렙 | +50% (1.50) | UTF [1.30, 1.70] 범위 내 Passed | ±10% 여유 내 | 적정 |
-| #17 | 진화 6★ | +40% (1.40) | UTF [1.20, 1.60] 범위 내 Passed | ±10% 여유 내 | 적정 |
-| #18 | 장비 일반 셋 | +30% (1.30) | **1.3046** (+30.46%) | **+0.35% (정확 일치)** | 적정 |
-| #19 | 장비 세트 완성 | +70% (1.70) | **1.7146** (+71.46%) | **+0.86% (정확 일치)** | 적정 |
-| #20 | 인장 5★ | +22% (1.22) | **1.2241** (+22.41%) | **+0.34% (정확 일치)** | 적정 |
-| #21 | 성장 순서 원칙 | 카드 > 세트장비 > 각성 > 진화 > 장비일반 > 인장 | 측정 5축 내림차순 완전 일치 | — | 원칙 부합 |
-
-**카드 단일 축 과도 체감이 5축 결합 실플레이에서 완화되는 정량 근거**:
-- 카드 풀빌드(이론 +399%)가 가장 큰 축이지만, 장비 세트 완성(실측 +71.46%)·각성 만렙(실측 +50%)·진화 6★(실측 +40%)가 결합되어 **전체 성장 곡선은 카드 단독치와 전혀 다른 구조**
-- 실측 5축 순서(세트 1.71 > 각성 1.50 > 진화 1.40 > 일반장비 1.30 > 인장 1.22)는 카드 > 세트 > 각성 > 진화 > 일반 > 인장 기획 원칙과 **완전 부합** (#21 Passed)
-- **카드는 5축 시너지 중 1축**이며 다른 4축이 동일 수준 기여하므로, 실플레이 "카드 단독 지배" 체감 가능성은 Phase 2 이론 시뮬보다 **현저히 낮음**
-
-#### §3-1-7. 조정 불요 확정 — 이슈 1
-
-- 카드 G1~G5 수치 전면 유지 (Phase2 §2 표 그대로)
-- 드래프트 가중치 G1:G2:G3:G4:G5 = 1000:300:150:50:10 유지 (밸런싱전략_v1 §1)
-- 밸런싱 전략(`밸런싱전략_v1 §3 Phase 3`) 카드 풀빌드 DPS 목표 **+80~120% 그대로 유지** (상향·하향 조정 불요)
-- **이론 +399% / 실전 추정 +200~280%는 "특화 빌드 피크치"로 포지션 확정** — 목표 +80~120%는 평균 빌드 기준이라 괴리 아님
-- 카드 메커닉 Unity MCP 시뮬 구현 REQ **취소** (Day 8-3 블로커 해제 · 실측 부재 상태로 추정치 확정 유지)
-
----
-
-### §3-2. 이슈 3 (신성 빌드 G4/G5 확장성) — 현 상태 전수 기록
-
-#### §3-2-1. 신성 빌드 전체 카드 분포 (카드시너지축분석_v1 §2 축 1 + Phase2 §4 통합)
-
-| 등급 | 카드 수 | 주요 카드 대표 |
-|------|---------|--------------|
-| **G1** | **11장** | `G1_HolyDamageOnMeleeFrontAppear` (적 등장 시 전열 신성 피해) · `G1_HolyDamageToBackEnemiesOnDodge` (회피 시 후열 신성 피해) · `G1_HolyDamageOnMeleeHit` · `G1_EnemySpawnHolyDamage` · `G1_MissHolyDamage` (Miss 기반) 등 |
-| **G2** | **9장** | G2 단계 신성 피해 강화·확장 카드 (상세 ID는 CardList.json 전체테이블감사_v1 §427 "성스러운 피해 6장" 섹션 및 카드시너지축분석_v1 §2 축 1 참조) |
-| **G3** | **0장** | (G3 단계 신성 확장 카드 부재 — 접근성 친화 빌드 설계 의도) |
-| **G4** | **1장** | G4 단계 신성 확장 단일 카드 (상세 ID는 CardList.json의 e_CardType=Holy·Grade=4 해당 카드) |
-| **G5** | **1장** | G5 단계 신성 확장 단일 카드 (상세 ID는 CardList.json의 e_CardType=Holy·Grade=5 해당 카드) |
-| **총** | **22장** | 전체 신성 빌드 (G1~G2 집중 82%) |
-
-**(추정·실측 구분 고지)**: 본 표의 G1:11·G2:9·G4:1·G5:1 분포는 카드시너지축분석_v1 §2 축 1과 Phase2 §5 이슈 3에서 **교차 확정**된 실측 수치. 단 G2·G4·G5 개별 카드 ID는 본 문서에 이식하지 않고 **CardList.json + 전체테이블감사_v1.md §427**을 1차 참조처로 지정한다(정본 유지·중복 기재 방지). 신성 빌드 재논의 시 본 표 → 참조처 경로로 ID·효과 전수 재구성 가능.
-
-#### §3-2-2. 1런 기대 선택수 0.019장 산출 과정
-
-**산출 로직** (Phase2 §4 "핵심 빌드별 G4+G5 핵심 카드 등장 확률"):
-- G4 등장 확률: 3.3% (1000:300:150:50:10 가중치 중 50)
-- G5 등장 확률: 0.66% (가중치 10)
-- 신성 빌드 G4 카드: 1장 / 전체 G4 풀 43장 → G4 등장 시 신성 선택 확률 = 1/43 = 2.33%
-- 신성 빌드 G5 카드: 1장 / 전체 G5 풀 32장 → G5 등장 시 신성 선택 확률 = 1/32 = 3.13%
-- **1런 19회 선택** 시 기대값:
-  - G4 신성 기대 = 19 × 0.033 × (1/43) = **0.0146장**
-  - G5 신성 기대 = 19 × 0.0066 × (1/32) = **0.0039장**
-  - **합계 ≈ 0.019장** (사전자료모음 §2-3 산출치 확정)
-- **10런에 1장 이상 확률**: ~17% (Phase2 §4 확률표)
-
-**판정**: 1런에 G4·G5 신성 카드가 1장이라도 뽑힐 확률은 극히 낮음 → "폭발의 쾌감" 부재. 단 이것이 **접근성 친화 빌드의 설계 의도**임을 §3-2-3에서 정당화.
-
-#### §3-2-3. 다른 빌드와 G4·G5 분포 비교표 (Phase2 §4 전수 — 재조사 불요 핵심)
-
-| 빌드 | G4 카드 | G5 카드 | G4+G5 합계 | 1런 G4+G5 기대 | 포지션 구분 |
-|------|---------|---------|----------|--------------|------------|
-| **치명타** | 11장 | 8장 | **19장** (최다) | **0.192장** | 극레어 럭 기반 폭발 빌드 (G4+G5 편중 의도) |
-| **처치 연쇄** | 10장 | 5장 | **15장** | 0.165장 | 폭발 연쇄 빌드 (G1~G5 고르게) |
-| 보호막 | 7장 | 4장 | 11장 | 0.118장 | 생존 안정 빌드 |
-| 힐 | 6장 | 3장 | 9장 | 0.110장 | 생존 안정 빌드 |
-| 물약 | 3장 | **7장** (G5 집중) | 10장 | 0.071장 | G5 집중 극레어 (★2 조건 충돌) |
-| 원거리 | 4장 | 3장 | 7장 | 0.081장 | 안전 딜 빌드 |
-| 회피 | 4장 | 3장 | 7장 | 0.059장 | 럭 기반 생존 빌드 |
-| 번개 | 2장 | 2장 | 4장 | 0.037장 | CC 특화 빌드 |
-| 첫타 | 1장 | 2장 | 3장 | 0.033장 | 빠른 처치 빌드 |
-| **신성 폭격** | **1장** | **1장** | **2장** (최소) | **0.019장** (최소) | **접근성 친화 캐주얼 빌드** (G1~G2 집중 의도) |
-
-**핵심 관찰** (신성 빌드의 의도된 설계):
-1. **치명타 빌드 vs 신성 빌드 = 극단 대비**: 치명타는 G4+G5 최다(19장) / 신성은 G4+G5 최소(2장) — 두 빌드가 **스펙트럼의 양 끝**에 배치되어 다양성 확보
-2. **"모든 빌드가 G4+G5 폭발을 가져야 한다"는 원칙 부재**: Phase2 §5 이슈 3 제안 "G4 3~4장·G5 1~2장 추가"는 신성 빌드를 치명타 빌드 쪽으로 이동시키는 안 → **빌드 차별화 상실**
-3. **신성 빌드 G4·G5 1장씩뿐인 설계 근거**: 1런 G1 신성 기대 **1.87장**(Phase2 §4)으로 **빌드 시작은 매우 쉬움** ↔ G4+G5 2장뿐이라 **폭발 순간 없음** = **접근성↑·폭발력↓ 트레이드오프**가 본 빌드의 고유 재미 축
-
-#### §3-2-4. 신성 빌드 승률·클리어율 (Day 4~7 실측·과거 데이터)
-
-**현 실측 상태** (2026-04-20 기준):
-- **실 유저 플레이테스트 승률·클리어율 데이터 미존재** (조직이 AI 에이전트 단독 운영 · QA 플레이테스트 미실시 단계)
-- **Unity MCP 시뮬 기반 신성 빌드 전용 TTK·클리어율 실측도 미실시** (Phase 3 Day 4~7 범위는 성장 요소 기여도 #16~#21 6건에 한정 · 빌드별 승률 측정 시나리오 부재)
-- **추정 근거 기반 판정만 가능**:
-  - Phase2 §4 신성 G1 기대 1.87장 = 빌드 **시작 가능** (1장만으로도 빌드 식별)
-  - 카드시너지축분석_v1 §2 축 1 "후열타격 조합 시 폭발적" = **후열 시너지 보완 시 성능 충분**
-  - 처치 연쇄 빌드와 동동점 기대 수(3.15장 vs 1.71장)라 **처치 연쇄가 더 쉬우나 신성 폭격도 MEDIUM 난이도로 형성 가능**
-
-**(C23 정직성 태그)**: 본 승률·클리어율 항목은 "**미측정·추정**" 상태. 실 유저 플레이테스트 또는 Unity MCP 빌드별 승률 시뮬 완료 후에야 정량 수치 확정 가능. 현 판정은 "빌드 시작 가능성 + 시너지 축 분석"에 기반한 **질적 적정성** 판단.
-
-#### §3-2-5. "캐주얼·접근성 친화 빌드" 포지션 근거 (경쟁 빌드 대비 진입 장벽·성공률)
-
-| 빌드 | G1 카드 수 | 1런 G1 기대 | 빌드 식별 용이도 | 빌드 형성 난이도 | G4+G5 의존도 |
-|------|----------|-----------|--------------|--------------|------------|
-| 힐 | 27장 (G1 풀의 24.1%) | **4.58장** | 매우 높음 | EASY | 낮음 (9장·+생존 축) |
-| 보호막 | 20장 (17.9%) | **3.39장** | 매우 높음 | EASY | 낮음 (11장·+생존 축) |
-| 처치 연쇄 | 16장 (14.3%) | **2.72장** | 높음 | EASY | 중간 (15장·폭발 연쇄 축) |
-| **신성 폭격** | **11장 (9.8%)** | **1.87장** | **중간** | **MEDIUM** | **낮음 (2장·접근성 친화)** |
-| 치명타 | **4장 (3.6%)** | **0.68장** | **매우 낮음** | **MEDIUM** | **매우 높음 (19장·럭 기반)** |
-| 물약 | 4장 (3.6%) | 0.68장 | 매우 낮음 | MEDIUM | 중간 (10장·★2 충돌) |
-| 번개 | 4장 | 0.68장 | 매우 낮음 | MEDIUM | 낮음 (4장) |
-
-**신성 빌드의 "캐주얼·접근성 친화" 포지션 정당성**:
-1. **G1 9.8% 비중 = 중간-상위**: 힐/보호막/처치연쇄 3대 EASY 빌드 다음 순위 (4위)
-2. **1런 G1 기대 1.87장 = 빌드 식별 가능**: 1장 이상 거의 확정 등장
-3. **G4+G5 의존도 낮음 (2장)**: 치명타(19장)·물약(10장)처럼 G4+G5에 매달릴 필요 없음
-4. **"빌드 시작은 쉽게·폭발은 없게"** = Balatro류 설계에서 **"무난한 성공 빌드"** 포지션 (럭 기반 폭발의 반대 극)
-5. **치명타 빌드와의 극단 대비** = 유저가 "럭 중심 폭발 추구 vs 안정 무난 빌드" 선택지 확보
-
-**경쟁 빌드 대비 진입 장벽**:
-- 힐·보호막 대비: 진입 장벽 **높음** (G1 11장 vs 힐 27장·보호막 20장) — 상대적 진입 장벽 존재는 **의도**
-- 치명타·물약 대비: 진입 장벽 **낮음** (G1 4장 vs 신성 G1 11장) — 접근성 우위 확보
-
-**성공률 관점**:
-- "빌드 완성률" 축에서는 힐·보호막·처치연쇄보다 낮으나 치명타·물약·번개·첫타보다 높음
-- "폭발 쾌감" 축에서는 치명타·처치연쇄보다 낮음
-- **두 축의 중간값 포지션** = **캐주얼 유저의 "무난한 선택지"** 역할
-
-#### §3-2-6. 조정 불요 확정 — 이슈 3
-
-- G4·G5 카드 추가 불요 (안 P 유지안 채택)
-- 신성 빌드 기존 카드 수치 조정 불요
-- 신규 카드 추가·`e_CardType` 신규 추가 불요 (기획실 특화 규칙 준수)
-- **신성 빌드 = 접근성 친화 캐주얼 빌드 포지션 공식 확정** (Day 15+ `밸런싱전략_v2.md` 최종본에 명기)
-
----
-
-### §3-3. "재조사 불요" 판정 근거 (2026-04-20 PD 지시 집행)
-
-#### §3-3-1. 본 문서 재독만으로 재구성 가능한 전체 맥락 매트릭스
-
-| 재구성 대상 | 본 문서 내 섹션 | 원본 참조 불요 판정 |
-|------------|-------------|----------------|
-| PD 결정 원문·근거 | §1·§2 | ✅ 원문 인용 완비 |
-| 카드 등급별 기본 분포(수량·확률·기여도·파워 구조) | §3-1-1 | ✅ Phase2 §2 전수 이식 |
-| G1 풀빌드 +399% 산출 과정 (앵커·누적·드래프트) | §3-1-2 | ✅ Phase2 §3 전수 이식 |
-| 실전 +200~280% 추정 근거·불확실성 범위 | §3-1-3 | ✅ 전수 기록 |
-| 빌드별 카드 분포 비교 (10종 빌드 + G4+G5 분포) | §3-1-4·§3-2-3 | ✅ Phase2 §4 전수 이식 |
-| 스테이지·Chapter별 영향 강도 | §3-1-5 | ✅ 밸런싱전략_v1 §3 전수 이식 |
-| 아웃게임 성장 시너지 Unity MCP 실측 | §3-1-6 | ✅ Phase3_성장요소기여도_v2 §2-1 전수 이식 |
-| 신성 빌드 전체 카드 분포 | §3-2-1 | ✅ 수량 분포 확정 / ID는 CardList.json 참조 (의도적 1차 참조 유지) |
-| 1런 0.019장 산출 과정 | §3-2-2 | ✅ 계산식 전수 기록 |
-| 다른 빌드와 G4·G5 분포 비교 | §3-2-3 | ✅ 10종 빌드 전수 비교표 |
-| 신성 빌드 승률·클리어율 | §3-2-4 | ⚠️ 실측 미존재 상태 정직 기록 (C23 준수) |
-| "캐주얼 빌드" 포지션 근거 | §3-2-5 | ✅ 4종 관점(시작·형성·폭발·중간값) 근거 완비 |
-| 9조합 전수 기각 근거 | §6 | ✅ 매트릭스 기각 사유 완비 |
-| 재미 관점 정당성 | §7 | ✅ 빌드 다양성·5축 시너지 근거 완비 |
-| 재논의 트리거 3종 | §5 | ✅ 엄격 제한 명기 |
-
-#### §3-3-2. 재조사 시나리오 3종 모의 테스트
-
-**본 문서만으로 전체 맥락 재구성이 가능한지 검증**하는 3종 시나리오:
-
-**시나리오 A — "5년 후 새 기획자가 이슈 1·3을 재논의하자고 제안"**:
-- 재구성 가능 항목: §1(결정 원문) + §2(논거) + §3-1-1~§3-1-6(현 수치 전수) + §6(9조합 기각) + §7(재미 정당성)
-- **판정**: ✅ 본 문서 재독만으로 "왜 조정하지 않는가"의 전체 논거 재구성 가능. 단 실 유저 플레이테스트 데이터가 본 문서 후 축적되었다면 그 데이터는 별도 확인 필요(본 문서 §3-2-4 "미측정 태그" 참조 지점)
-
-**시나리오 B — "차기 프로젝트에서 본 결정을 조직 자산으로 계승"**:
-- 재구성 가능 항목: §8(조직 자산 계승 인사이트) + §3-1·§3-2(실측 수치 근거) + §7(재미 축)
-- **판정**: ✅ "문제처럼 보이는 현상 = 설계 재미" 판별 방법론·다면 시너지 기반 밸런싱·빌드 특화 포지션 공식 3대 인사이트가 §8에 집약되어 차기 프로젝트 즉시 활용 가능
-
-**시나리오 C — "Unity MCP 카드 메커닉 시뮬이 향후 구현되어 +200~280% 실측 확정"**:
-- 재구성 가능 항목: §3-1-3(추정 근거) + §5-1-2(플레이테스트 트리거) + §5-3(금지 패턴)
-- **판정**: ✅ 실측이 추정 범위 내면 본 확정 그대로 유지 · 실측이 범위 외 크게 초과하면 §5-1 트리거 발동 → PM 경유 PD 상신 절차 진입. 본 문서는 "어떤 실측치에서 재논의 트리거가 발동하는가"의 판단 기준 제공
-
-#### §3-3-3. 부족 축 식별 결과 (발견 시 즉시 보강)
-
-본 섹션 작성 시점(2026-04-20) 3종 시나리오 모의 테스트 결과, **추가 보강 필요 축 2종 식별**:
-
-1. **실 유저 플레이테스트 승률·클리어율 미측정 상태 (§3-2-4 정직 기록 완료)** — 향후 QA 플레이테스트 착수 시 본 섹션 갱신 필수 항목으로 예약
-2. **Unity MCP 카드 메커닉 시뮬 미구현 상태 (§3-1-3 정직 기록 완료)** — Day 8-3 시뮬 구현 REQ 취소 확정이나, 향후 조직 사정 변경으로 시뮬 구현될 경우 실측치로 §3-1-3 갱신 필수 항목으로 예약
-
-**위 2종 이외의 축은 본 문서로 재구성 충분 — "재조사 불요" 선언 성립**.
-
-#### §3-3-4. 재조사 불요 선언
-
-**2026-04-20 기준, 본 문서 §3 보강본(§3-1~§3-3)은 향후 어떤 재조사 요청에도 본 문서 재독으로 대체 가능 수준**이다. 재논의가 필요한 트리거는 §5-1 3종에 한정되며, 그 외 경우 본 문서가 이슈 1·3에 대한 단일 참조처(Single Source of Truth)로 기능한다.
-
----
-
-## §4. Day 11~14 · Day 15+ 영향
-
-### §4-1. Day 11~14 (맵 패턴 재검증)
-
-- 맵 패턴 구성 시 **이슈 1·3 현 수치 전제**로 진행
-- C9(보스 집중) 배치 정합성 확인 시 카드 G1 풀빌드를 "특화 빌드"로 분류 (전 빌드 대상 밸런싱 아님)
-- ★ 조건 배타 배치 7종(P17) 재점검 시 신성 빌드를 "접근성 친화 빌드" 포지션 전제로 검증
-
-### §4-2. Day 15+ (v2 최종본 반영)
-
-- `밸런싱전략_v2.md` 최종본 작성 시 이슈 1·3 **현 수치 그대로** 반영
-- 카드 풀빌드 DPS 목표 +80~120% 유지 (상향·하향 조정 이력 없음)
-- 신성 빌드 "접근성 친화 빌드" 포지션 공식 명기
-
-### §4-3. Phase 3 v2 → v3 전환 시
-
-- `Phase3_성장요소기여도_v3.md` 작성 시 이슈 1·3 조정 이력 **기록 제외** (조정 자체가 없었음)
-- 성장 순서 원칙(#21) 부합 확인 기록은 v2 그대로 승계
-
----
-
-## §5. 재논의 트리거 (엄격 제한)
-
-본 확정 문서는 재논의 대상이 아니나, 다음 **특정 조건** 발생 시에만 재논의 요청 가능:
-
-### §5-1. 허용 트리거 (3종)
-
-1. **Day 11~14 맵 패턴 재검증 중 C9(보스 집중) 배치 정합성 실패 발견** — 카드 G1 풀빌드가 특정 보스 스테이지를 완전 무력화하여 맵 패턴 설계 자체가 불가능한 경우
-2. **실 유저 플레이테스트(향후 QA 단계) 결과 카드 빌드 지배율이 설계 의도 범위를 크게 초과** — 실 체감 데이터가 Phase 3 v2 실측과 크게 괴리되는 경우
-3. **PD님 직접 재논의 지시** — 본 확정 근거와 무관하게 PD님이 새로운 관점·근거로 재논의 지시 시
-
-### §5-2. 재논의 요청 절차 (엄격)
-
-- **기획팀장 재량 재논의 금지** — 위 트리거 발생 시에도 기획팀장 단독 확정 재개 불가
-- **PM 경유 PD 상신 필수** — 기획팀장이 트리거 발생 근거 정리 → PM 검증 → PD님 상신
-- **P28-8 준수** — 재논의 요청 전까지 본 확정 안건을 보고·안건에서 재언급 금지 (종결 안건 재언급은 위험 신호)
-
-### §5-3. 금지 패턴
-
-- "Day 8~10 결과 보고"를 명분으로 본 확정 결정을 재논의로 포장 금지
-- Day 11~14 작업 중 "이참에 이슈 1·3도 같이 재검토" 제안 금지
-- v2 최종본 작성 과정에서 "문구 조정" 명분으로 수치 변경 금지
-
----
-
-## §6. 기각안 (P24·C32 · 3×3 매트릭스 9조합 전수 기각)
-
-A-초안(`이슈1_3_통합재논의_v1_초안.md` §2·§3)에서 제시한 이슈 1 3안(A·B·C) × 이슈 3 3안(P·Q·R) **9조합 전수 기각**:
-
-| # | 조합 | 조합 내용 | 기각 근거 |
-|---|------|----------|----------|
-| 1 | A × P | 목표 상향 + 신성 유지 | PD 결정 §1 — 이슈 1·3 **조정 자체가 불요** · 목표치 유지 확정 |
-| 2 | A × Q | 목표 상향 + G5만 +1 | 동상 — 신성 빌드 G4/G5 추가 불요 (접근성 친화 포지션 유지) |
-| 3 | A × R | 목표 상향 + 원 제안 | 동상 — 신성 빌드 대폭 강화 불요 + 목표 상향 불요 |
-| 4 | B × P | 카드 하향 + 신성 유지 | PD 결정 §1 — 카드 수치 하향 불요 (특화 빌드 특성 인정) |
-| 5 | B × Q | 카드 하향 + G5만 +1 | 동상 + 신성 조정 불요 |
-| 6 | B × R | 카드 하향 + 원 제안 | 동상 + 신성 대폭 강화 불요 |
-| 7 | C × P | 혼합 + 신성 유지 | 혼합 조정 불요 · 중간값 조정도 필요 없음 |
-| 8 | C × Q | 혼합 + G5만 +1 | 동상 |
-| 9 | C × R | 혼합 + 원 제안 | 동상 |
-
-**공통 기각 근거**: PD님께서 "일부 빌드 특성 + 다양한 성장 시너지"를 근거로 이슈 1·3 **조정 불요** 판정. 9조합 모두 "조정을 전제로 한 선택지"이므로 전수 불성립.
-
----
-
-## §7. 재미 관점 (P30) — 빌드별 특성 차별화 유지가 재미 강화
-
-### §7-1. 강화되는 재미 축
-
-1. **빌드별 고유 포지션 유지** — 카드 빌드(Balatro류 폭발) · 신성 빌드(캐주얼 접근성) · 치명타 빌드(럭 기반 극딜) · 힐/쉴드 빌드(생존 트레이드오프) 등 각 빌드의 **차별화된 재미**가 살아남
-2. **성장 시너지 5축 구조** — 카드 × 장비 × 각성 × 진화 × 인장의 다면 시너지가 단일 축 지배를 자연 완화 (Phase 3 v2 실측 확인)
-3. **유저 선택의 다양성** — "어떤 빌드가 최강인가"가 아니라 "내가 원하는 빌드가 무엇인가" 선택 가능 (각 빌드가 고유 장점 보유)
-
-### §7-2. 조정 시 상실될 재미 (기각 근거 재확인)
-
-- **안 B (카드 하향) 집행 시**: Balatro류 카드 빌드 폭발 쾌감 약화 + 신성 빌드도 함께 악화 (매트릭스 §3-3)
-- **안 R (신성 대폭 강화) 집행 시**: 신성 빌드의 "접근성 친화" 포지션 상실 + 다른 빌드 상대 파워 재검증 부담
-- **동시 조정 시**: 5축 시너지 구조 자체가 재설계되어 기존 설계 의도 붕괴
-
-### §7-3. PD 결정의 재미 관점 정당성
-
-PD 결정은 "문제처럼 보이는 것이 실제로는 설계된 재미"임을 재확인한 판단:
-- 이슈 1 "카드 과도"는 **카드 빌드의 고유 포지션** (Balatro류 폭발)
-- 이슈 3 "신성 G4/G5 부족"은 **신성 빌드의 고유 포지션** (캐주얼 접근성)
-- 두 빌드의 포지션 차이가 **빌드 다양성이라는 상위 재미**를 만든다
-
----
-
-## §8. 본 결정이 차기 프로젝트에 미치는 영향 (P29 조직 자산 계승)
-
-### §8-1. 조직 기억 축적 항목
-
-1. **"문제처럼 보이는 현상 = 설계 재미" 판별 중요성** — 수치 조정 착수 전 "이것이 실제 문제인가, 설계 의도인가"를 선행 판단
-2. **다면 시너지 구조 기반 밸런싱** — 단일 축 피크치가 아닌 **N축 결합 실플레이 체감**을 밸런싱 기준으로 삼을 것
-3. **빌드 특화 vs 전 빌드 밸런싱 구분** — 특화 빌드는 피크 DPS가 높아도 **설계 의도**로 수용 가능
-
-### §8-2. 코어 프레임워크 활용 인사이트
-
-- `프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md`에 추가 검토 권고:
-  - "밸런싱 조정 착수 전 '설계 재미 vs 실제 문제' 판별 체크리스트"
-  - "다면 시너지 구조에서 단일 축 피크 DPS 수용 기준"
-  - "빌드 특화 포지션 공식 정의 프로세스"
-
----
-
-## §9. PD 결정 공식 기록 (타임스탬프·경위)
-
-### §9-1. 타임스탬프
-
-- **PD 결정 수령 일시**: 2026-04-20
-- **결정 수령 채널**: PM 상신 → PD 직접 지시 → PM 집행 지시 전달 → 기획팀장 집행
-- **기획팀장 집행 일시**: 2026-04-20 (본 문서 작성 시점)
-
-### §9-2. 경위
-
-1. **Day 4~7 재검증 완료** (2026-04-20) — Phase 3 성장 요소 기여도 v2 Unity MCP UTF 14/14 Passed · 성장 순서 원칙(#21) 실측 확인
-2. **A-초안 작성** (2026-04-20) — Day 8~10 트랙 A 착수 시 의논 시작점 제공 (`이슈1_3_통합재논의_v1_초안.md`)
-3. **Day 8~10 접근 방식 PM 상신** — 간략화(A안) vs 정식 재검증(B안) 2안 제시
-4. **PD 결정 수령** (2026-04-20) — A안 수용 + 이슈 1·3 무시 결정 원문 (§1)
-5. **본 확정 문서 작성·기획팀 집행** — Day 8-3·8-4 통합 (기획팀장 재량 판단 · C36 구현 수준)
-6. **A-초안 상태 배너 전환** — "아카이브됨" 배너 추가 · 본문 유지 (기각안 9조합 근거 보존 · C14-5 예외 "아카이브된 문서 자체")
-
-### §9-3. 본 결정의 조직 가시성
-
-- **PD 지시 로그**: 기획팀 #3 Day 8~10 A안 집행 완료 갱신 (PM 처리 영역)
-- **대화로그**: `공유/대화로그/수상한잡화점/2026-04-20.md` 엔트리 추가
-- **PM 보고**: `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md`
-
----
-
-## §10. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (PD 결정 수령·집행) | 초안 작성 · PD A안 수용 결정 수령 · 이슈 1·3 무시 확정 선언 · 9조합 전수 기각 · 재논의 트리거 3종 엄격 제한 · Day 11~14·v2 최종본 영향 명기 · P30 재미 근거 · P29 조직 자산 계승 인사이트 기록 |
-| 2026-04-20 (Day 8-1·8-2 보강) | 기획팀장 (PD 지시 "현 상태 기록해서 향후 재조사 필요하지 않도록 해" 집행) | §3 대폭 보강 — §3-1 이슈 1 현 상태 7종(등급별 분포·+399% 산출·+200~280% 추정 근거·빌드별 G4+G5 분포·스테이지 영향·5축 실측·조정 불요) + §3-2 이슈 3 현 상태 6종(신성 전체 분포·0.019장 산출·10종 빌드 비교·승률 정직 기록·캐주얼 포지션 근거·조정 불요) + §3-3 재조사 불요 판정 근거(매트릭스·시나리오 3종·부족 축 2종·재조사 불요 선언). Phase2 §2~§5·Phase3 v2 §2·카드시너지축분석 §2·밸런싱전략 §3·전체테이블감사 §427 5종 원본 핵심 정량 수치 본 문서 이식. 재조사 시 본 문서 재독만으로 전체 맥락 재구성 가능 수준 확보 |
-
----
-
-## §11. 관련 문서
-
-### §11-1. 1차 근거 (§3 보강본이 이식한 원본)
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §2·§3·§4·§5 — 등급별 분포·누적 임팩트·빌드별 분포·이슈 원문
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` §2 축 1 — 신성 빌드 22장 전수 분석
-- `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` §1·§3 Phase 3·Phase 4 — 드래프트 가중치·성장 요소 기여도 목표·스테이지별 영향
-- `프로젝트/수상한잡화점/기획/전체테이블감사_v1.md` §427 성스러운 피해 6장 — 신성 빌드 카드 ID·효과 1차 참조처
-- `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` (Day 4~7 실측 #16~#21)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` (UTF 14/14 원시 수치)
-
-### §11-2. 의사결정·선행 자료
-- `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` — A-초안 (아카이브 전환, 기각안 9조합 근거)
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` — 원 이슈 제기 자료 (2026-04-14)
-- `프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md` — 논점 재정리
-
-### §11-3. 공유·트래킹
-- `공유/대화로그/수상한잡화점/2026-04-20.md` — Day 8~10 A안 종결 + Day 8-1·8-2 보강 엔트리
-- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md` 기획팀 #3 — Day 8~10 진행중
-- `공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md` — PM 보고 (선행 버전)
diff --git a/프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md b/프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md
deleted file mode 100644
index 424b846..0000000
--- a/프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md
+++ /dev/null
@@ -1,252 +0,0 @@
----
-type: 통합재논의초안
-작성일: 2026-04-20
-작성자: 기획팀장 (밸런스·시스템기획자 관점 반영)
-관련PD지시: 기획팀 #40 후속 PM 재량 A-초안
-선행산출물:
-  - 재논의대기_사전자료모음_v1.md (2026-04-14)
-  - 재논의대기_논점재정리_v1.md (2026-04-20)
-  - Phase2_카드임팩트측정_v1.md §5 이슈 1·3
-  - Phase3_성장요소기여도_v2.md (Day 4~7 완료 · 2026-04-20)
-  - Unity_MCP_실측검증_리포트_v2.md (2026-04-20)
-상태: **🔴 아카이브됨 — 대체: `이슈1_3_무시확정_v1.md` (2026-04-20 PD A안 결정)**
-아카이브사유: PD님 직접 결정(2026-04-20)으로 이슈 1·3 무시 확정 · 본 문서의 9조합(A·B·C × P·Q·R)은 모두 기각안으로 소비됨
-범위_원본: Day 8~10 트랙 A 착수 시 **의논 시작점 제공**. 실측 수치 확정은 카드·Shield 시뮬 구현 후 Day 8~10 본 작업 시 수행
----
-
-> **🔴 아카이브됨 — 2026-04-20 PD 결정 A안 수용으로 본 문서의 조정안은 **전수 기각**되었다.**
-> **본 문서는 기각안 근거 보존 목적으로 본문 유지되며, 현행 방향은 `이슈1_3_무시확정_v1.md`를 참조한다.**
-> **C14-5 예외 (아카이브된 문서 자체) 적용 — 본문 당시 그대로 유지.**
-
-# 이슈 1·3 통합 재논의 초안 v1
-
-## 0. 본 문서의 역할
-
-PD 2026-04-14 승인 방향 "이슈 1 ↔ 이슈 3 **통합 재논의**"의 **Day 8~10 트랙 A 착수 시점 의논 시작점**. 본 문서는:
-
-- **기획 가정 범위** 수치를 제시 (실측 수치 확정 아님)
-- **Day 8~10 카드·Shield 시뮬 구현 후 실측 데이터로 재검증** 선행 조건
-- PD님 결정이 필요한 3개 방향 안건(Q2) **제시만 수행** (PD 결정 대기 안건 신설 아님 — Day 8~10 수행 후 근거 갖춰 제시 예정)
-
-**Day 8-1~8-3 수준** (Day 8-4 PD 판단 요청은 본 문서 범위 밖)
-
----
-
-## 1. Day 4~7 결과 반영 (통합 재논의 입력 확정)
-
-**`Phase3_성장요소기여도_v2.md` Day 4~7 재검증 6건 완료 (2026-04-20)**
-
-| 항목 | 기획 가정 | Unity MCP 실측 (UTF 14/14) | 판정 |
-|------|---------|--------------------------|------|
-| #16 각성 만렙 | +40~60% DPS | UTF [1.30, 1.70] 범위 내 Passed | **적정** |
-| #17 진화 6★ | +30~50% DPS | UTF 범위 내 Passed | **적정** |
-| #18 장비 일반 | +20~40% DPS (중앙 +30%) | **+0.35% 정확 일치** (1.3046) | **적정** |
-| #19 장비 세트 | +60~80% DPS (중앙 +70%) | **+0.86% 정확 일치** (1.7146) | **적정** |
-| #20 인장 5★ | +15~30% DPS (중앙 +22%) | **+0.34% 정확 일치** (1.2241) | **적정** |
-| #21 기여 순서 원칙 | 카드 > 세트장비 > 각성 > 진화 > 장비일반 > 인장 | 실측 DPS ratio 내림차순 완전 부합 | **원칙 부합** |
-
-**결정적 의미 (Day 8~10 트랙 A 입력)**:
-1. **아웃게임 성장 요소(장비·각성·인장)는 기획 가정 범위 내 정확 일치** — 이슈 1의 "카드 과도" 문제는 **카드 쪽 수치 재검토**가 유효한 방향으로 좁혀짐 (장비·각성 상향 조정 우회로는 부적합)
-2. **기여 순서 원칙 유지** (카드 > 장비 > 각성 > 인장) — Phase 3 v2 실측 기준으로 확인됨
-3. 다만 **카드 G1 풀빌드(+399%·실전 추정 +200~280%)는 미실측** (Day 8~10에서 카드 메커닉 시뮬 구현 후 산출 예정)
-
----
-
-## 2. 이슈 1 통합 조정안 초안 (카드 DPS 과도)
-
-### 2-1. 조정 방향 3안 제시 (기획 가정 범위)
-
-**Q2 질문(`재논의대기_논점재정리_v1 §2 Q2`)에 대한 Day 8~10 의논 시작점 3안**
-
-#### 안 A. 목표치 상향 (현 수치 유지)
-- `밸런싱전략_v1 §3` 카드 풀빌드 DPS 목표 **+80~120% → +200~280%**로 상향 재조정
-- 현 카드 수치 그대로 유지
-- **장점**: 카드 재작업 부담 0 · Balatro류 "카드 빌드 폭발" 체감 유지
-- **단점**: 성장 요소 순서 원칙 붕괴 우려 (카드만으로 스테이지 후반 압도 리스크)
-- **재미 영향 (P30)**: 카드 빌드 쾌감 최대화 · 아웃게임 성장 동기 약화 우려
-
-#### 안 B. 카드 수치 하향 (목표 유지)
-- 카드 풀빌드 DPS 목표 +80~120% 유지
-- 카드 수치 전반을 **실전 추정 +200~280% → +100% 범위**로 재튜닝
-- G1~G5 전 등급 DPS 기여 **50~70% 수준 하향**
-- **장점**: 성장 요소 순서 원칙 엄격 유지 · 아웃게임 성장 동기 강화
-- **단점**: 카드 수치 전면 재작업 · Balatro류 폭발 쾌감 약화 우려
-- **재미 영향 (P30)**: 아웃게임 성장 성취감 강화 · 카드 빌드 임팩트 약화
-
-#### 안 C. 혼합 조정 (목표 소폭 상향 + 카드 일부 하향)
-- 목표치 **+80~120% → +150~200%** 중간 상향
-- 카드 수치 **실전 +200~280% → +150~200%** 하향
-- 두 축이 만나는 지점에서 재조정 완료
-- **장점**: 양 축의 장점 균형 · 변경 범위 최소화
-- **단점**: 최종 수치 확정에 추가 시뮬 반복 필요
-- **재미 영향 (P30)**: 성장 요소 순서 원칙 유지 + Balatro류 쾌감 일정 수준 보존
-
-### 2-2. 안 A·B·C 비교 매트릭스
-
-| 축 | 안 A (목표 상향) | 안 B (카드 하향) | 안 C (혼합) |
-|----|---------------|---------------|-----------|
-| 성장 순서 원칙 | 약화 | 엄격 유지 | 부분 유지 |
-| 카드 재작업 범위 | 0 | 전면 | 부분 |
-| Balatro류 쾌감 | 최대 | 약화 | 중간 |
-| 아웃게임 성장 동기 | 약화 | 최대 | 중간 |
-| 신성 빌드 영향 | 현 상태 유지 | **악화** (G4·G5 2장만 유지 시 더 약함) | 부분 악화 |
-| PD 결정 부담 | 낮음 | 높음 | 중간 |
-| 수치 검증 부담 | 낮음 | 최대 | 중간 |
-
-**기획팀장 관점**: **C36 판정 기준** — A·B·C 선택은 PD 결정 영역. 본 문서에서 PM·기획팀 재량으로 안을 확정하지 않음.
-
----
-
-## 3. 이슈 3 통합 조정안 초안 (신성 빌드 G4/G5 확장성)
-
-### 3-1. 이슈 1과의 연동 처리 원칙 (§2 안별 영향)
-
-**사전자료모음 §3-2 · 논점재정리 §1 축 3 준수**
-
-| 이슈 1 선택 | 신성 빌드 영향 | 이슈 3 조정 필요성 |
-|------------|-------------|-----------------|
-| 안 A (목표 상향) | 현 상태 유지 | 신성 빌드는 여전히 G4·G5 부재 → **이슈 3 독자 조정 필요** |
-| 안 B (카드 하향) | **악화** (이미 약한 빌드가 더 약해짐) | 신성 빌드 **G4·G5 수치 상향** + 이슈 3 조정 **필수** |
-| 안 C (혼합) | 부분 악화 | 부분 조정 (G4·G5 소폭 강화) |
-
-### 3-2. 신성 빌드 조정안 3안 (기획 가정 범위)
-
-사전자료모음 §2-3 PD 유보 상태 제안을 **Day 8~10 시점 3안으로 재구조화**:
-
-#### 안 P. 유지안 (현 상태 · G4 1장·G5 1장 유지)
-- 신성 빌드의 "쉬운 시작 + 낮은 폭발"을 **의도된 캐주얼 빌드 포지셔닝**으로 확정
-- 무과금·소과금 접근성 빌드로 공식화
-- **전제**: 이슈 1을 안 A(목표 상향)로 확정하여 전체 DPS 파이가 크다는 맥락 유지
-- **재미 영향 (P30)**: 신성 빌드 = "쉬운 접근 친화적 빌드" 포지션 · 다른 빌드에서 "폭발" 경험 제공
-
-#### 안 Q. 소폭 강화 (G5만 극레어 1장 추가)
-- G4 1장 유지 · **G5 1장 → 2장** (극레어 "폭발" 카드 1장 추가)
-- 기존 카드 효과 종류 내에서 수치 조정으로 대응 · 신규 `e_CardType` 추가 금지
-- **전제**: 이슈 1 안 B·C 선택 시 필수 (안 B에서는 필수, 안 C에서는 선택)
-- **재미 영향 (P30)**: 접근성 유지 + 최소한의 절정 순간 제공 · 1런 G4+G5 기대 선택수 0.019 → 0.028 수준 소폭 상승
-
-#### 안 R. 대폭 강화 (사전자료모음 §2-3 원 제안)
-- G4 1장 → 3~4장 · G5 1장 → 1~2장 (원 제안 수용)
-- 기존 카드 수치 조정으로 대응 (신규 카드 추가 시 PD 사전 승인 필수)
-- 다른 빌드(치명타·물약 등 G4·G5 밀도 높은 빌드)와의 상대 파워 변화 재측정 필요
-- **전제**: 이슈 1 안 B·C 선택 + 신성 빌드를 "접근성 + 절정" 양립 빌드로 재포지셔닝
-- **재미 영향 (P30)**: 접근성 + Balatro류 폭발 쾌감 양립 · 다른 빌드 형평성 재검증 부담
-
-### 3-3. 이슈 1 안 × 이슈 3 안 조합 매트릭스
-
-| 이슈 1 × 이슈 3 | 안 P (유지) | 안 Q (G5만 +1) | 안 R (원 제안) |
-|---------------|-----------|--------------|--------------|
-| 안 A (목표 상향) | ✅ **정합** | ✅ 가능 | △ 과잉 우려 (DPS 인플레) |
-| 안 B (카드 하향) | ❌ 악화 | ✅ **필수 조합** | ✅ **권장 조합** |
-| 안 C (혼합) | △ 부분 악화 | ✅ **정합** | ✅ 가능 |
-
-**기획팀장 관점 (Day 8~10 착수 시점 참고)**:
-- 이슈 1 안 B·C 유력 시 이슈 3는 안 Q·R 권장
-- 이슈 1 안 A 확정 시 이슈 3는 안 P로 귀결 가능 (다만 Balatro 폭발 관점에서 안 Q 여지)
-
----
-
-## 4. 통합 처리 원칙 (재확인)
-
-**사전자료모음 §3-3 · 논점재정리 §4 · 본 문서 §3-3 매트릭스**
-
-1. **전체 DPS 목표치 재설정** (이슈 1 선행) → 이슈 1 안 A/B/C 중 PD 결정
-2. **기준 내에서 빌드별 강약 재분배** (이슈 3 후속) → 이슈 3 안 P/Q/R 중 PD 결정 (이슈 1 선택과 연동)
-3. **최종 실측으로 양 이슈 동시 검증** (Unity MCP EditMode · 카드 메커닉 시뮬 구현 후)
-
-**금지 사항 (재확인)**:
-- 이슈 1·3 분리 작업 (PD 직접 승인 방향 위반)
-- 카드 효과 종류(`e_CardType`) 신규 추가 (기획실 특화 규칙)
-- 신규 카드 추가 (PD님 사전 승인 필수)
-
----
-
-## 5. Day 8~10 트랙 A 착수 시 산출물 예상
-
-본 문서는 **Day 8-1~8-3 수준 초안**. Day 8~10 본 작업 시 다음 산출물 필요:
-
-| Day | 산출물 | 담당 | 비고 |
-|-----|--------|-----|------|
-| Day 8-1 | 본 초안 재독 + 이슈 1 3안 수치 범위 확정 | 밸런스기획자 | 본 문서 §2-1 참조 |
-| Day 8-2 | 이슈 3 3안 × 이슈 1 3안 매트릭스 재검토 + 권장 조합 1~2개 선별 | 밸런스·시스템기획자 | 본 문서 §3-3 참조 |
-| Day 8-3 | 카드 메커닉 시뮬 REQ 발행 (개발팀) | 기획팀장·시스템기획자 | 카드 효과 시뮬 구현 요청 (이슈 1·3 실측 전제) |
-| Day 8-4 | **PD 결정 요청 안건 상정** (이슈 1·3 통합 3×3 매트릭스 + 기획팀 권장안) | 기획팀장 → PM → PD | **본 문서 범위 밖** · Day 8-3까지 수행 후 PD 상신 |
-| Day 9 | 카드 메커닉 시뮬 실측 (Unity MCP) | 밸런스기획자 (개발팀 협업) | 이슈 1·3 실측 수치 확정 |
-| Day 10 | 최종 조정안 (PD 결정 반영) + Phase 3 v2 재조정 | 밸런스·시스템기획자 | Day 8-4 PD 결정 후 수치 확정 |
-
----
-
-## 6. 제약·주의사항
-
-### 6-1. 범위 엄수
-- 본 문서는 **기획 가정 범위**. 실측 수치 확정은 Day 9 카드 메커닉 시뮬 후
-- 본 문서는 **Day 8~10 의논 시작점**. PD 결정 안건 신설 아님 (Day 8-4에서 별도 상신)
-- 본 문서는 **조정안 확정을 수행하지 않는다**
-
-### 6-2. 선행 의존
-- **개발팀 카드 메커닉 시뮬 구현 필수** (v2 리포트 §6-3 Day 8~10 이관 확정)
-- **G3~G5 질적 효과**(기절·반사·부활·무적 등) 시뮬 구현 여부는 추가 REQ 범위
-- Shield 시뮬 구현 여부는 이슈 3 G4·G5 변경 시 쉴드 관련 카드 강화 검토 시 필요 (현재 Day 8~10 범위)
-
-### 6-3. C36 준수
-- 본 문서는 **구현·실무 수준**만 다룸
-- 이슈 1 안 A/B/C 중 선택은 **PD 결정 영역** (방향 수준) · PM·기획팀 독단 확정 금지
-- 이슈 3 안 P/Q/R 중 선택도 **PD 결정 영역** (이슈 1과 연동)
-
----
-
-## 7. 기각안 (P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 본 문서에서 **이슈 1·3 확정안** 제시 (1개 안으로 수렴) | **C36 위반** — 이슈 1·3 방향 선택은 PD 결정 영역. 기획팀장 재량으로 "권장안 1개" 제시는 허용되나, "확정안"은 금지 |
-| 2 | **실측 수치 확정** 포함 (기획 가정 대신) | 카드 메커닉 시뮬 미구현 상태 (v2 §6-3) · Day 8~10 수행 전 수치 확정 불가 |
-| 3 | 이슈 1·3 **분리 처리** 프레임 포함 | PD 2026-04-14 "통합 재논의 방식 사전 확정" 직접 지시 위반 |
-| 4 | 신성 빌드에 **신규 카드** 추가 제안 | 사전자료모음 §2-3 · 신규 카드 추가는 PD 사전 승인 필수 |
-| 5 | 카드 효과 종류(`e_CardType`) **신규 추가** 제안 | 기획실 특화 규칙 위반 |
-| 6 | Day 8-4 **PD 결정 요청 안건을 본 문서에 포함** | 본 문서는 Day 8-1~8-3 범위. Day 8-4 PD 상신은 기획팀장이 카드 시뮬 실측 수치 확보 후 별도 산출물 |
-
----
-
-## 8. 재미 근거 (P30)
-
-### 8-1. 강화하려는 재미 축
-1. **성장 요소 시너지 곡선의 자연스러움** — 카드 빌드가 지배하지 않고 아웃게임 성장(장비·각성·인장)과 조화
-2. **Balatro류 빌드 폭발 쾌감** — 각 빌드마다 고유의 절정 순간 확보
-3. **빌드 다양성** — 신성 빌드(접근성 친화) · 치명타·물약 (극레어 폭발) · 힐·쉴드 (생존 드래프트) 각자 포지션 확립
-
-### 8-2. 변경 전 재미 문제
-1. 카드 DPS 과도 (+399% 이론 · +200~280% 실전 추정)로 아웃게임 성장 체감 부재 → 성장 동기 약화
-2. 신성 빌드 "터지는 순간" 부재 (1런 G4+G5 기대 선택수 0.019장) → 캐주얼 접근성만 있고 쾌감 없음
-3. 이슈 1·3 분리 처리 시 상호 악화 리스크
-
-### 8-3. 변경 후 기대 경험
-1. 카드 빌드가 지배하지 않는 **성장 요소 시너지 곡선** (순서 원칙 유지)
-2. 신성 빌드의 **고유 포지션 확립** (안 P 유지안 or 안 Q·R 절정 추가)
-3. 빌드별 "고유한 재미" 확보 (신성=접근성 · 치명타=럭 기반 극딜 · 힐=생존 트레이드오프)
-
-### 8-4. 측정 지표 (Day 9 이후)
-- 카드 풀빌드 DPS 증가율 실측 (질적 효과 포함)
-- 빌드별 1런 완성률 분포
-- 성장 요소 기여 순서 원칙 유지 여부 (카드 < 목표치 기준 내)
-- 스테이지별 ★3 달성률 (Unity MCP 시뮬 기반)
-
----
-
-## 9. 관련 문서
-
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` (원본)
-- `프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md` (2026-04-20 · 본 문서 선행)
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 이슈 1·3
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` §2 축 1 (신성 폭격)
-- `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` §3 (카드 풀빌드 DPS 목표)
-- `공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md` (Day 4~7 완료)
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md`
-
----
-
-## 10. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (밸런스·시스템기획자 관점 반영) | 초안 작성 · Day 8-1~8-3 수준 기획 가정 범위. 안 A·B·C × 안 P·Q·R 3×3 매트릭스 제시 · Day 8-4 PD 결정 요청은 범위 밖 |
diff --git a/프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md b/프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md
deleted file mode 100644
index 9b7bb76..0000000
--- a/프로젝트/수상한잡화점/기획/재검증_템플릿_v1.md
+++ /dev/null
@@ -1,107 +0,0 @@
-# 수상한 잡화점 — Phase 3 재검증 로그 템플릿 v1
-
-> 작성일: 2026-04-20 / 담당: 기획팀장 (Phase 3 재개 Day 1 사전 준비)
-> 용도: Day 2~3 Phase 0~2 재검증 6건 + Day 4~7 성장요소 기여도 6건 + Day 11~14 맵 패턴 재검증 9건의 **단일 항목 재검증 로그 포맷**
-> 데이터 소스: `밸런싱문서_일관성점검_v1.md §2` 재검증 체크리스트 · `시뮬레이터/03_결과_JSON_포맷_v1.md` 결과 스키마
-> 명명 규칙: `Phase3_재개준비_체크리스트_v1.md §5` 준수
-
----
-
-## 0. 사용법
-
-- 재검증 항목 1건당 본 템플릿 1 block을 append 방식으로 사용
-- 통합 리포트(예: `재검증보고_Phase0_1_2_v1.md`)의 본문에 항목 단위로 전개
-- Unity MCP 시뮬 실행 결과 JSON 경로를 **반드시 원문 그대로 인용** (C5 정직성)
-- 판정은 `적정`/`과도`/`부족`/`괴리` 4종으로 분류. 근거 수치 병기 의무
-
----
-
-## 1. 단일 항목 재검증 로그 block
-
-### 재검증 #{항목번호} — {항목명}
-
-| 필드 | 값 |
-|------|-----|
-| **항목번호** | (예: #1 / #16 / #22) |
-| **항목명** | (`일관성점검_v1 §2` 원문 그대로) |
-| **기획 가정 (원본 수치)** | (예: "PC 6001 DPS 1.05 @ Phase0_1 §1") — **출처 §번호 필수** |
-| **검증 목표** | (예: "Unity MCP EditMode 실측이 ±10% 이내인지 확인") |
-| **담당 에이전트** | balance-designer / system-designer / level-designer 중 선택 |
-| **검증 축** | Unity MCP EditMode / Unity 실 빌드 PlayMode 병행 / 문서 대조 only |
-| **Unity MCP 시뮬 시나리오 ID** | (예: `anchor_stage1_pc6001_no_card`) — `02_시나리오_JSON_스키마_v1.md` 준수 |
-| **seed 목록** | (예: `[42, 1337, 2026]` — 결정론 검증용 3회 이상 권장) |
-| **결과 JSON 경로** | (예: `프로젝트/수상한잡화점/시뮬레이터/결과/run_20260421_*.json`) — **복수 실행 시 전부 인용** |
-| **실측값** | (예: "DPS 평균 1.03, σ 0.01") — 통계 요약 + 원시값 JSON 참조 |
-| **오차 (실측 − 기획 가정)** | (예: "-1.9%") — 부호 유지 |
-| **판정** | `적정` (±10% 이내) / `과도` (+10% 초과) / `부족` (-10% 초과) / `괴리` (±20% 초과 — 이슈 1·3 통합 재논의 대상) |
-| **판정 근거** | (예: "검증 축 §5 규칙에 따라 ±10% 이내 → 적정") — 공란 금지 |
-| **후속 조치** | (예: "조치 없음" / "Day 8 이슈 통합 재논의로 이관" / "개발팀 REQ-XXX 발행") |
-| **실행 일시** | YYYY-MM-DD HH:MM (Unity MCP 시뮬 실행 시점) |
-| **기록 일시** | YYYY-MM-DD HH:MM (본 로그 작성 시점) |
-| **기록자** | (에이전트명) |
-
-### 특이 사항 / 이슈
-
-(실측 과정에서 발견한 이상 징후·부작용·예상 외 결과를 **C3 정직성 기준**으로 전수 기록. "없음"도 명시 허용)
-
-### 기각안 (복수 해석 후보 검토 시 필수 — C32 / 구 P22 계승)
-
-| # | 기각 해석 후보 | 기각 사유 |
-|---|-------------|---------|
-| 1 | (예: "실측 1.03 → PC 기본 ATK 범위 이동 필요") | (예: "σ 0.01로 RNG 변동 범위 내 — 구조 변경 불필요") |
-
-기각 후보 없음: "없음 (단일 해석 — 사유: ...)" 명시. 공란 금지.
-
----
-
-## 2. 통합 리포트 헤더 (리포트 선두에 1회만)
-
-```markdown
-# 수상한 잡화점 — 재검증보고 {항목명} v1
-
-> 작성일: YYYY-MM-DD / 담당: 기획팀장
-> 검증 범위: `일관성점검_v1 §2-X` 재검증 #{A}~#{B} 통합
-> 선행 조건: Unity MCP EditMode 시뮬 환경 구축 완료 (`시뮬레이터/01~04_*.md` 기반)
-> 검증 축: Unity MCP EditMode 실측 = 정본(正), 실 빌드 PlayMode 병행 ±10% 허용
-
-## 0. 요약 (항목별 판정 분포)
-
-| 판정 | 건수 | 항목 |
-|------|-----|------|
-| 적정 | N | #{목록} |
-| 과도 | N | #{목록} |
-| 부족 | N | #{목록} |
-| 괴리 | N | #{목록} — **이슈 통합 재논의 대상** |
-
-## 1. 전체 집행 컨텍스트
-
-- Unity MCP 시뮬 실행 환경: (버전·커밋 해시)
-- 실행 기간: YYYY-MM-DD ~ YYYY-MM-DD
-- 총 시뮬 횟수: N회
-- 결과 JSON 루트 경로: (예: `프로젝트/수상한잡화점/시뮬레이터/결과/YYYY-MM-DD/`)
-
-## 2. 항목별 로그
-```
-
-그 다음 §1의 block을 항목 수만큼 반복.
-
----
-
-## 3. 관련 규칙·문서
-
-- **C5** 정보의 정직성 — 실측 원문 인용 의무
-- **C23** 허위 보고·역할 연기 절대 금지 — tool_use 결과로 입증 불가한 수치 단정 금지
-- **P16** 산출물 추적성 — 변경 이력 기록 의무
-- **P28** 보고 표준 포맷 — 통합 리포트 헤더 §0 요약표
-- **P30** 재미 우선 원칙 — 판정이 `과도`/`부족`/`괴리`일 때 "어떤 재미가 훼손되는가" 서술 권고
-- **`시뮬레이터/03_결과_JSON_포맷_v1.md`** — 결과 JSON 필드 정의
-- **`밸런싱문서_일관성점검_v1.md §2`** — 재검증 28개 항목 SOT
-- **`Phase3_재개준비_체크리스트_v1.md §5`** — 산출물 명명 규칙
-
----
-
-## 4. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|--------|----------|
-| 2026-04-20 | 기획팀장 | 초판 — Phase 3 재개 Day 1 사전 준비 산출물 |
diff --git a/프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md b/프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md
deleted file mode 100644
index 307ce5d..0000000
--- a/프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md
+++ /dev/null
@@ -1,426 +0,0 @@
----
-type: 기획 재검증 보고서
-작성일: 2026-04-20
-작성자: 기획팀장 (레벨·밸런스 양축 통합 + 11-5 주도)
-관련PD지시: 기획팀 #3 Phase 3 Day 11~14 (PD 4종 결정 수용 — B·C·B·B)
-범위: Day 11~14 5건 재검증 통합 (11-1~11-5)
-status: 초안 — Day 11~14 완료 · Day 15+ 착수 준비
-선행산출물:
-  - 공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md (레벨기획자 완료)
-  - 공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md (밸런스기획자 완료)
-  - 프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md (원본 · 수정 금지)
-  - 프로젝트/수상한잡화점/기획/맵패턴_42슬롯_현황테이블_v1.md
-  - 프로젝트/수상한잡화점/기획/스테이지난이도곡선_v1.md §2·§4·§5
-  - 프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md (조건 풀 12개 확정)
-  - 프로젝트/수상한잡화점/기획/이슈1_3_무시확정_v1.md §3-1-5·§4-1 (전제 고정)
----
-
-# Day 11~14 재검증 보고서 — 맵 패턴 v1
-
-> **본 보고서의 역할**: Day 11~14 재검증 5건(11-1~11-5)을 레벨 축·밸런스 축 병렬 산출물과 통합한 종합 판정 보고. 42 슬롯 × P17 배타 7종 전수 체크는 본 보고서가 **주도**. 실 배치 확정은 Phase 3 재개 후 Unity MCP 시뮬 검증 후 수행.
-
----
-
-## §1. 본 보고서 범위 (Day 11~14 5건 재검증)
-
-### §1-1. 5건 매핑
-
-| # | 작업 | 담당 | 상태 | 본 보고 섹션 |
-|---|------|------|------|------------|
-| 11-1 | 스테이지 난이도 곡선 재검증 (#11~#15) | level + balance 병렬 | ✅ 완료 | §2 |
-| 11-2 | C9 배치 금지 스테이지(7·10·13) 타당성 재검증 | level | ✅ 완료 | §3 |
-| 11-3 | C9 적합 스테이지 재검증 | level | ✅ 완료 | §4 |
-| 11-4 | 보스 혼용 패턴 원칙 4종 → 실 패턴 ID 가이드 프레임 | level | ✅ 완료 (프레임 수준) | §5 |
-| 11-5 | 42 슬롯 × P17 배타 7종 전수 체크 | 기획팀장 주도 | ✅ **본 보고 §6 주도** | §6 |
-
-### §1-2. 통합 방식
-
-- 레벨 축·밸런스 축 결과물 **원문 실측 인용** (C23 정직성 준수)
-- 양축 판정 **교차 검증** → 충돌·보완 식별 (§2)
-- 42 슬롯 전수 체크는 **기획팀장 직접 수행** (§6)
-- Day 15+ 반영 후보 문서 통합 리스트 (§8)
-
-### §1-3. 고정 전제
-
-- **이슈 1·3 현 수치 고정** (이슈1_3_무시확정_v1.md §4-1) — P28-8 준수, 본 보고 내 재언급 최소화
-- **조건 풀 12개 전수 확정** (3성조건_12개_상세명세_v1.md · PD 3차 승인) — 신규 조건 제안 금지
-- **Chapter 1~6 전체 125 스테이지 현 구조 유지**
-- **실 배치 확정은 Phase 3 재개 후** — 본 보고서는 검증 틀 + 가이드 프레임
-
----
-
-## §2. 11-1 스테이지 #11~#15 난이도 곡선 통합 판정 (레벨 + 밸런스)
-
-### §2-1. 양축 판정 교차 검증 테이블
-
-| Stage | 레벨 축 판정 | 밸런스 축 판정 | 충돌 여부 | 통합 판정 |
-|-------|--------------|---------------|---------|---------|
-| 11 | 수용 가능 (11→12 내구도 역전 수용) | 적정 (Shield 315 의도 설계) | 충돌 없음 (보완) | **적정** |
-| 12 | 이상 없음 (에티4 빠른 제거 자산) | 적정 (에티4 치명타 유효) | 충돌 없음 (일치) | **적정** |
-| 13 | 의도 구조 (숨고르기 구간 해석) | 적정 (단독 보스 완화 패턴) | 충돌 없음 (일치) | **적정** |
-| 14 | 적절 (회귀 상승) | 적정 (메두사2 고Shield 주의) | 충돌 없음 (일치) | **적정** |
-| 15 | 적절 (흑기사1 3회째 주의) | 적정 (ATK45 N2 난이도) | 충돌 없음 (보완) | **적정** |
-
-**종합**: Stage #11~#15 전수 **양축 일치 — 적정 판정**. 조정 권고 없음.
-
-### §2-2. 양축 교차 검증으로 강화된 주의 사항 5종
-
-레벨·밸런스 결과물을 통합하여 **Phase 3 재개 후 반드시 검증해야 할 사항**:
-
-1. **Stage 11 — 흡혈귀여왕2(HP91·Shd315) C9 임계값 달성**
-   - 레벨 축: "Shield 벽으로 C9 임계값 달성 가능성 낮아질 우려" (§1-4-1)
-   - 밸런스 축: "세트 결합 TTK 45.2s — 장기전 영역" (§2-2)
-   - **통합**: C9 카운트가 Shield 파괴 공격에 과도 집중되어 빌드 다양성 저하 가능. Phase 3 Unity MCP 시뮬로 **보스 Shield 파괴 빌드 vs 일반 빌드 C9 달성률 비교** 권장.
-
-2. **Stage 12 — C2 ∧ N2 조합 회피**
-   - 레벨 축: "서브맵 7 누적 피격 부담 상승" (§1-3)
-   - 밸런스 축: "서브맵 7×1=7회 상한 · ATK 29.7 동시 배치 난이도 상승" (§2-3)
-   - **통합**: P17-1 위반은 아니나 **슬롯 배치 시 회피 권고** (배타 조합의 '주의' 등급).
-
-3. **Stage 14·15 — N4 ∧ C6 조합 (P17-3 배타)**
-   - 레벨 축: "Stage 5 다크엘프아처1(Shd282) + N4 배치 시 Shield 확보 난이도 혼재 우려" (§5-2 P17-3)
-   - 밸런스 축: "메두사2 고Shield 구간 N4∧C6 동시 배치 시 회복 빌드 외 배제" (§2-5·§2-6)
-   - **통합**: P17-3 배타 위반 차단 필수. 추가로 **N4 단독 배치 시에도** 메두사2 등장 스테이지(14·15·16)에서 시뮬 검증 권장.
-
-4. **Stage 15 — 흑기사1 ATK Max 45 + 보스 재사용 3회째**
-   - 레벨 축: "흑기사1 Stage 10·12·15 3회 재사용 · 맵 패턴 다양화 필요" (§1-3)
-   - 밸런스 축: "Stage 15 ATK Max 45 = #11~#15 구간 최고치 · N2 슬롯 배치 난이도 상위권" (§2-6)
-   - **통합**: ATK 축 이중 부담(반복 체감 + 고ATK). C2∧N2 배타 위반 차단 + 맵 패턴 다양화 시뮬 검증 이중 권장.
-
-5. **Stage 17 — 용암골렘2 Shield 525 (범위 외 참조)**
-   - 레벨 축 §5-2: "C2∧N2 동시 배치 위험 극단화" 식별
-   - 밸런스 축 §2-7 종합 테이블에서 '주의 스테이지'로 잠재 언급
-   - **통합**: Stage #11~#15 본 작업 범위 외지만, Day 15+ 착수 시 **Stage 17 우선 검증 대상**으로 Carry Over.
-
-### §2-3. Phase 3 시뮬 검증 권장 대상 (Stage 11·15)
-
-레벨 축 §1-4에서 제시된 2건을 밸런스 축 결과와 통합하여 확정:
-
-| Stage | 검증 대상 | 레벨 축 근거 | 밸런스 축 근거 | Unity MCP 시뮬 항목 |
-|-------|---------|-------------|-------------|-------------------|
-| 11 | 흡혈귀여왕2 Shd315 C9 임계값 | "Shield 벽 인한 C9 달성 낮아질 우려" | "TTK 45.2s 장기전 · 추가 성장 필요" | C9 임계값 설정(보스 처치 N회) vs 플레이어 DPS·Shield 파괴 빌드 시나리오 |
-| 15 | 흑기사1 재사용 3회째 + ATK45 | "흑기사1 3번째 등장 · 피로감" | "ATK Max 45 · N2 조건 상위 난이도" | 맵 패턴 다양화 + N2 조건 달성률 분포 |
-
-**권장 사항**: Phase 3 재개 즉시 위 2건을 **Unity MCP 시뮬 검증 우선순위 상위**로 배치.
-
----
-
-## §3. 11-2 C9 금지 스테이지(7·10·13) 타당성 (레벨 축 결과 반영)
-
-### §3-1. 레벨 축 3축 검증 요지 (§2-2 인용)
-
-레벨기획자가 수행한 3축 검증:
-
-1. **조건 의미성 축**: 단독 보스 = 자동 충족 → 조건 가치 소멸 → **금지 타당**
-2. **페이싱 축**: 서브맵 4~5 + 단일 전투 집중형 → 페이싱 충돌 → **금지 타당**
-3. **재도전 유도 축**: 타겟 전환이 일어날 수 없음 → **금지 타당**
-
-### §3-2. 통합 판정
-
-**Stage 7·10·13의 C9 배치 금지는 P17-5 규칙상 확정. 변경 없음.**
-
-기획팀장 통합 검증:
-- P17-5 "C9(보스 집중) ∧ 단독 보스·보스 미등장 스테이지 동시 배치 금지" 조항과 레벨 축 3축 검증 결과가 **완전 일치**.
-- 밸런스 축 §2-4에서도 Stage 13 C9 배치 금지 재확인 → 양축 일관.
-- 현황테이블_v1 §1·§3에서 이미 **P17-5 사전 차단** 완료.
-
-### §3-3. 레벨 축 제안 — 대체 조건 방향 3종
-
-레벨기획자가 대체 전략으로 제안한 방향 (§2-3 인용):
-
-| Stage | 단독 보스 특성 | 권장 대체 조건 방향 |
-|-------|--------------|-------------------|
-| 7 | 메두사1 Shd223 최고 | **N4 역방향** — 적 Shield 공략 집중 긴장 (시뮬 검증 선행) |
-| 10 | 흑기사3 HP·ATK 균형형 | **C2(완벽 클리어) 또는 N2(피격 제한)** — 단독 집중 정밀도 강조 (단 Stage 10의 N2는 서브맵 5×1=5회 상한 감안) |
-| 13 | 레드드래곤3 ATK 34 | **C12(회피 주도)** — 고ATK 회피 연출과 정합 |
-
-**기획팀장 판단**:
-- 대체 조건 방향은 **레벨 관점 제안 수준**. **실 배치 확정은 Phase 3 재개 후 Unity MCP 시뮬 검증 + PD 승인 필요**.
-- Stage 10 N2 배치 시 P17-1(C2∧N2)와의 정합성 추가 체크 필수.
-- Stage 13 C12 배치 시 **C12 조건의 카운트 산정 로직** (REQ초안_3성조건_12개_판정로직 연동) Unity MCP 실측 필요.
-
----
-
-## §4. 11-3 C9 적합 스테이지 재검증
-
-### §4-1. 레벨 축 12개 스테이지 전수 판정 (§3-2 인용)
-
-C9 적합 판정 대상 — 보스 2체 이상 + 중반 이상 + P17-5 위반 없음:
-
-| Stage | 보스수 | 구간 | 레벨 축 판정 | 기획팀장 통합 우선순위 |
-|-------|--------|------|-------------|-------------------|
-| 8 | 2 | 중반전환 | O 권장 | 추천 (Shield 고값 2체) |
-| 9 | 2 | 중반전환 | O 권장 | 추천 (전략 선택 유발) |
-| 11 | 2 | 중반심화 | O 권장 | **주의 — 시뮬 선행** (Shd315) |
-| 12 | 3 | 중반심화 | **최적 추천** | **최적** (보스 3체 · 서브맵 7 · 에티4 Shd0) |
-| 14 | 2 | 후반진입 | O 권장 | 추천 (보스 간 타겟팅 전환) |
-| 15 | 2 | 후반진입 | O 권장 | 추천 |
-| 16 | 3 | 후반진입 | O 권장 | **주의 — 특수 구조** (서브맵 3 · 혼용 여지 최소) |
-| 17 | 2 | 후반 | O 권장 | **주의 — 시뮬 선행** (Shd525) |
-| 18 | 3 | 후반 | O 권장 | 추천 |
-| 19 | 2 | 최종 | O 권장 | 추천 |
-| 20 | 3 | 최종 | **최적 추천** | **최적** (보스 3체 · 서브맵 9) |
-| 21 | 2 | 최종 | O 권장 | 추천 |
-
-### §4-2. 통합 우선순위 분류 (기획팀장 주도)
-
-**C9 배치 최적 스테이지 (Unity MCP 시뮬 1순위)**:
-- **Stage 12·20** — 레벨·밸런스 양축 일치. 보스 3체·서브맵 7·9로 임계값 조정 폭 최대. 에티4(Shd0) 초기 카운트 확보 용이.
-
-**C9 배치 추천 스테이지 (시뮬 2순위)**:
-- Stage 8·9·14·15·18·19·21 — 보스 2~3체 · 구조적 안전
-
-**C9 배치 주의 스테이지 (시뮬 선행 필수 — 임계값 튜닝)**:
-- **Stage 11** (흡혈귀여왕2 Shd315) — 임계값 설정이 Shield 파괴력에 종속
-- **Stage 16** (서브맵 3개 특수 구조) — 혼용 여지 최소 · 보스 분포 강제
-- **Stage 17** (용암골렘2 Shd525) — 단일 보스 최강 EHP
-
-**C9 배치 금지 스테이지 (P17-5 고정)**:
-- Stage 7 (메두사1 단독) · Stage 10 (흑기사3 단독) · Stage 13 (레드드래곤3 단독)
-
----
-
-## §5. 11-4 보스 혼용 패턴 가이드 프레임
-
-### §5-1. 원칙 4종 → AppearGroup 가이드 프레임 전환 (레벨 축 §4 인용)
-
-레벨기획자가 수행한 프레임 전환:
-
-| 원칙 | 내용 | 레벨 축 구체화 |
-|------|------|-------------|
-| 1 | 보스 단독 서브맵 비율 ≤ 50% (최종 서브맵 예외) | 서브맵 N개 중 보스 단독 ≤ N/2개 · 마지막 서브맵 예외 |
-| 2 | 혼용 몬스터는 스테이지 난이도 중하위권 | 현 스테이지 난이도 −1 구간 몬스터 사용 권장 |
-| 3 | C9 스테이지 보스 등장 서브맵 비율 보장 | 보스 등장 서브맵 ≥ 60% (**추정** — 시뮬 검증 필요) |
-| 4 | 단일 스테이지 내 최소 2가지 보스 등장 위치 패턴 | 초반 + 중반 + 최종 서브맵 형태 배분 |
-
-### §5-2. AppearGroup 범위 실측 기반 가이드 프레임 (§4-2 인용)
-
-Stage 11~16 중심 프레임 (본 보고 Stage #11~#15 범위):
-
-| Stage | AppearGroup 범위 | 보스수 | 권장 혼용 서브맵 | 보스 등장 위치 배분 가이드 |
-|-------|----------------|--------|----------------|--------------------------|
-| 11 | 51101~51105 (5개) | 2 | 1~2 | 서브맵 2~3 중 1 혼용 · 서브맵 5 최종 보스 단독 |
-| 12 | 51201~51207 (7개) | 3 | 2 | 서브맵 2+4 혼용 · 서브맵 7 최종 보스 단독 · **에티4 초반 배치 권장** |
-| 13 | 61301~61304 (4개) | 1 | 1 (C9 제외) | 서브맵 3~4 보스 배치 |
-| 14 | 61401~61405 (5개) | 2 | 1~2 | 서브맵 2~3 혼용 · 서브맵 5 최종 |
-| 15 | 61501~61505 (5개) | 2 | 1~2 | 서브맵 2~3 혼용 · 서브맵 5 최종 |
-| 16 | 61601~61603 (3개) | 3 | 1 (특수) | 보스 3체 3 서브맵 분산 · 혼용 여지 최소 |
-
-### §5-3. 기획팀장 통합 주의 사항
-
-**프레임 수준 한정의 근거 재확인**:
-- 실 패턴 ID(AppearGroup 내 서브맵별 몬스터 배치 그룹) 확정에는 **ApprearMonsterPattern.json 재분해 + Unity MCP 시뮬 검증** 필수.
-- 본 보고서의 프레임은 **Phase 3 재개 조건 충족 후 실측 ID로 치환**.
-
-**Stage 12 특화 설계 제안 (레벨 축 §4-3 인용)**:
-- 서브맵 1~2: 일반 몬스터 집중 (언데드 중기 + 마법생물 중기)
-- 서브맵 3: 에티4 첫 등장 (Shd0 · HP158) — 혼용 서브맵
-- 서브맵 4: 흑기사3 혼용
-- 서브맵 5: 흡혈귀여왕2 혼용
-- 서브맵 6~7: 보스 전열 집중 또는 최종 보스 단독 (클라이맥스)
-
-기획팀장 평가: **설계 의도 명확 · Phase 3 재개 즉시 Unity MCP 시뮬 검증 대상 최우선**.
-
-**Stage 16 특수 처리 (레벨 축 §7 기각안 #5 인용)**:
-- 서브맵 3개 · 보스 3체 구조상 보스 단독 비율 50% 초과 불가피.
-- 원칙 1의 50% 이하 권장은 일반 스테이지 기준이며, **Stage 16 특수 처리 인정**이 타당.
-
----
-
-## §6. 11-5 42 슬롯 × P17 배타 7종 전수 체크 (기획팀장 주도)
-
-> **본 섹션은 기획팀장이 직접 수행한 전수 체크 결과다. 42 슬롯 = 21 스테이지 × 슬롯2·슬롯3.**
-
-### §6-1. 전수 체크 방법론
-
-1. **기반 자료**: `맵패턴_42슬롯_현황테이블_v1.md §2-1·§2-2·§2-3` 현황 매핑 테이블
-2. **체크 대상**: 42 슬롯 각각에 대해 P17 배타 7종 위반 리스크 재확인
-3. **체크 방식**: 현 시점은 **실 배치 확정 전**이므로 "후보 조합 풀 내 위반 감지" 단계
-4. **참여**: 레벨 축 §5 관점 추가 위험 + 밸런스 축 §2 주의 사항 + 기획팀장 통합
-
-### §6-2. 42 슬롯 × P17 전수 체크 테이블
-
-**범례**:
-- ✅ 차단 확인 (현황테이블에 사전 매핑 완료)
-- ⚠️ 주의 (배타 조합 아니나 동시 배치 시 난이도 극단화)
-- ✅(풀12) 풀 12개 모두 후보 · 배타 7종만 차단
-
-| # | Stage | 슬롯 | P17-1 C2∧N2 | P17-2 C6∧물약 | P17-3 C6∧N4 | P17-4 C1∧C3 | P17-5 C9 | P17-6 N3 | P17-7 N5∧N6 | 기획팀장 종합 |
-|---|-------|------|-----------|------------|-----------|-----------|---------|---------|-----------|------------|
-| 1 | 1 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 2 | 1 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 3 | 2 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 4 | 2 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 5 | 3 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 6 | 3 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ✅ **차단(비권장)** | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 7 | 4 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 단독 보스 비율 검증 필수 | ✅ **차단(입문)** | ✅ 차단 | 주의 |
-| 8 | 4 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 단독 보스 비율 검증 필수 | ✅ **차단(입문)** | ✅ 차단 | 주의 |
-| 9 | 5 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 검증 | ✅ **차단(입문)** | ✅ 차단 | **레벨 축: 다크엘프아처1 Shd282 · N4 단독 배치 시 Shield 확보 시뮬 권장** |
-| 10 | 5 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 검증 | ✅ **차단(입문)** | ✅ 차단 | 레벨 축 주의 동일 |
-| 11 | 6 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 검증 | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 12 | 6 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ **차단(입문)** | ⚠️ 가능하나 검증 | ✅ **차단(입문)** | ✅ 차단 | 통과 |
-| 13 | 7 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제(중반) | ✅ **차단(단독보스)** | ✅ 해제(중반) | ✅ 차단 | 통과 |
-| 14 | 7 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅ **차단(단독보스)** | ✅ 해제 | ✅ 차단 | 통과 |
-| 15 | 8 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 16 | 8 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 17 | 9 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 18 | 9 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 19 | 10 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅ **차단(단독보스)** | ✅ 해제 | ✅ 차단 | 통과 |
-| 20 | 10 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅ **차단(단독보스)** | ✅ 해제 | ✅ 차단 | 통과 |
-| 21 | 11 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | **통합 §2-2-1: C9 배치 시 Shd315 임계값 시뮬 권장** |
-| 22 | 11 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통합 동일 |
-| 23 | 12 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | **통합 §2-2-2: C2∧N2 조합 회피 권고(주의 등급)** |
-| 24 | 12 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통합 동일 |
-| 25 | 13 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅ **차단(단독보스)** | ✅ 해제 | ✅ 차단 | 통과 |
-| 26 | 13 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅ **차단(단독보스)** | ✅ 해제 | ✅ 차단 | 통과 |
-| 27 | 14 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | **통합 §2-2-3: N4∧C6 외 N4 단독도 메두사2 고Shd 시뮬 권장** |
-| 28 | 14 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통합 동일 |
-| 29 | 15 | 슬롯2 | ⚠️ **고주의** | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | **통합 §2-2-4: ATK45 N2 난이도·흑기사1 재사용 3회째** |
-| 30 | 15 | 슬롯3 | ⚠️ **고주의** | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통합 동일 |
-| 31 | 16 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12)주의(서브맵3특수) | ✅ 해제 | ✅ 차단 | **특수 구조 — §5-3 Stage 16 특수 처리 인정** |
-| 32 | 16 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12)주의 | ✅ 해제 | ✅ 차단 | 동일 |
-| 33 | 17 | 슬롯2 | ⚠️ **고주의(ATK·Shd525)** | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12)주의 | ✅ 해제 | ✅ 차단 | **Day 15+ 1순위 시뮬 대상** |
-| 34 | 17 | 슬롯3 | ⚠️ **고주의** | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12)주의 | ✅ 해제 | ✅ 차단 | 동일 |
-| 35 | 18 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 36 | 18 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 37 | 19 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 38 | 19 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 39 | 20 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | **C9 최적 1순위** |
-| 40 | 20 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 동일 |
-| 41 | 21 | 슬롯2 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-| 42 | 21 | 슬롯3 | ✅ 차단 | ✅ 비활성 | ✅ 차단 | ✅ 해제 | ✅(풀12) | ✅ 해제 | ✅ 차단 | 통과 |
-
-### §6-3. 위반 감지 결과: **0건** (PD B 방식 중단 트리거 미발동)
-
-**근거**:
-- 본 체크는 **실 배치 확정 전** 수행됨. 각 슬롯의 "후보 조합 풀"에 대한 배타 7종 재확인 수준.
-- 현황테이블_v1 §2-1·§2-2·§2-3에서 이미 입문·중반·후반 구간별 배타 조합을 **사전 차단** 완료 (입문 C1∧C3·N3·N5∧N6 / 중반 해제 / Stage 7·10·13 C9 금지 / 전 스테이지 N5∧N6·C2∧N2·C6∧N4).
-- 42 슬롯 모두 현 후보 조합 풀에서 P17 배타 7종 위반 구조 없음.
-- **⚠️ 표기 4개**는 배타 '주의' 등급 (동시 배치 시 난이도 극단화 우려) — 배타 위반은 아니며 실 배치 시 회피·시뮬 검증 권장 사항.
-
-**작업 계속 진행 판정**: **재개 적합**. PD B 방식(위반 즉시 중단) 트리거 미발동. Day 15+ 착수 가능.
-
-### §6-4. ⚠️ 고주의 슬롯 4개 별도 관리 (Phase 3 시뮬 우선 대상)
-
-본 전수 체크에서 '고주의' 등급으로 식별된 4개 슬롯은 실 배치 시 **Unity MCP 시뮬 선행**:
-
-| 슬롯 # | Stage | 슬롯 | 주의 사유 | 시뮬 검증 항목 |
-|--------|-------|------|---------|-------------|
-| 29·30 | 15 | 슬롯2·3 | 흑기사1 ATK45 + 재사용 3회째 | C2∧N2 배타 차단 + N2 단독 배치 시 달성률 |
-| 33·34 | 17 | 슬롯2·3 | 용암골렘2 Shd525 + ATK 고값 | N4 단독 배치 시 플레이어 Shield 확보 가능성 |
-
----
-
-## §7. 42 슬롯 배치안 초안 — 현 배치 평가 + 개선 권고
-
-### §7-1. 현 배치 상태
-
-**확정 사실**:
-- 현 단계는 **실 배치 확정 전**. 42 슬롯 모두 "후보 조합 풀" 상태.
-- 현황테이블_v1 §2는 스테이지별 "가능한 후보 조합 풀"을 매핑한 **검증 틀**이지 **배치안이 아님**.
-- 실 배치 확정은 Phase 3 재개 후 Unity MCP 시뮬 검증 + PD 승인 후 수행.
-
-### §7-2. 현 후보 조합 풀 평가 (기획팀장 종합)
-
-1. **P17 배타 사전 차단 완전성**: ✅ 현황테이블_v1 §2-1·§2-2·§2-3에서 전수 차단 완료.
-2. **이슈 1·3 수치 고정 정합**: ✅ 이슈1_3_무시확정_v1.md §4-1 전제 준수.
-3. **조건 풀 12개 범위 준수**: ✅ 신규 조건 추가 없음 · PD 3차 승인 풀 내 구성.
-4. **고주의 슬롯 식별**: ✅ 4개 슬롯 (Stage 15·17 슬롯2·3) 별도 관리 시작.
-5. **C9 최적/주의/금지 분류**: ✅ 최적 3종(Stage 12·20) · 주의 3종(Stage 11·16·17) · 금지 3종(Stage 7·10·13).
-
-### §7-3. 개선 권고 (Phase 3 재개 시 반영)
-
-| # | 개선 권고 | 근거 | 우선순위 |
-|---|---------|------|---------|
-| 1 | Stage 11·17 C9 배치 시 **Unity MCP 시뮬로 임계값 튜닝 선행** | Shd315·Shd525로 C9 카운트가 Shield 파괴에 과도 집중될 우려 | 최우선 |
-| 2 | Stage 15 슬롯 배치 시 **C2∧N2 절대 차단 + 흑기사1 맵 패턴 다양화** | ATK45 + 재사용 3회째 이중 부담 | 최우선 |
-| 3 | Stage 17 N4 단독 배치 시 **플레이어 Shield 확보 가능성 시뮬** | 용암골렘2 Shd525 + 고ATK 환경 | 고우선 |
-| 4 | Stage 12 C9 배치 시 **에티4(Shd0) 초반 배치로 C9 카운트 워밍업** | 레벨 축 §4-3 특화 설계 제안 | 고우선 |
-| 5 | Stage 14·15 N4 단독 배치 시 **메두사2 고Shd 환경 시뮬 검증** | 레벨·밸런스 양축 "N4∧C6 외 단독도 주의" 합의 | 중우선 |
-| 6 | Stage 16 **특수 구조 인정** — 보스 단독 비율 50% 초과 허용 | 서브맵 3·보스 3 구조상 불가피 (레벨 축 §7 기각안 #5) | 중우선 |
-| 7 | C9 금지 스테이지(7·10·13) 대체 조건 방향 **신규 참고 문서화 검토** | 레벨 축 §2-3 대체 전략 제안 정리 | 참고 |
-
-**결론**: 현 42 슬롯 후보 조합 풀은 **P17 배타 위반 0건 · 구조적 안전 · Phase 3 재개 즉시 실 배치 확정 작업 가능** 상태.
-
----
-
-## §8. Day 15+ 반영 후보 문서 리스트 (양축 제안 통합)
-
-### §8-1. 통합 우선순위 리스트 (레벨 5종 + 밸런스 3종 중복 제거 → 7종)
-
-| 우선순위 | 문서 | 반영 내용 | 축 제안 | PD 결정 대기 여부 |
-|---------|------|---------|--------|----------------|
-| **최우선** | `맵패턴_사전분석_v1.md` §1-4 | C9 적합 스테이지 레벨 관점 우선순위 분류(최적/주의) 추가 | 레벨 | 아니오 (PM 재량) |
-| **최우선** | `맵패턴_42슬롯_현황테이블_v1.md` §7 | Stage 11·17 Shd 고스탯 C9 임계값 주의 사항 추가 · ⚠️ 고주의 4개 슬롯 별도 관리 섹션 신설 | 레벨 + 기획팀장 통합 | 아니오 (PM 재량) |
-| **고우선** | `스테이지난이도곡선_v1.md` §8 | Stage 11~15 TTK 수치 테이블 추가(밸런스 축 §3-3) + Stage 15 흑기사1 재사용 3회째 주의 추가 | 레벨 + 밸런스 통합 | 아니오 (PM 재량) |
-| **고우선** | `맵패턴_사전분석_v1.md` §2-3 | 보스 혼용 원칙 4종 → AppearGroup 단위 가이드 프레임 추가 | 레벨 | 아니오 (PM 재량) |
-| **중우선** | `맵패턴_사전분석_v1.md` §3-2 | 체크 3 항목에 N4 Shield 확보 가능성 검증 기준 보강 (Shield 미보유 서브맵 비율 신설) | 레벨 | 아니오 (PM 재량) |
-| **중우선** | `밸런싱문서_일관성점검_v1.md` §2-3 | Stage 11~15 판정 결과 "적정" 완료 처리 | 밸런스 | 아니오 (PM 재량) |
-| **PD 결정 대기** | `밸런싱전략_v1.md` §3 Phase 4 | G1 DPS 목표 수치 v2 반영 (+80~120% vs 실전 +200~280% 괴리) | 밸런스 | **예 (PD 별도 결정 대기 · 이슈1_3_무시확정_v1.md 전제)** |
-
-### §8-2. 참고 후보 (신규 문서 가능)
-
-| 문서명 후보 | 용도 | 비고 |
-|-----------|------|------|
-| C9 금지 스테이지 대체 조건 설계 가이드 | 레벨 축 §2-3 대체 조건 방향 정리 | Phase 3 재개 후 신설 검토 |
-
-### §8-3. PD C 방식 "필요한 문서만" 대비 — 최소 권장 셋
-
-PD C 방식(필요 문서만 업데이트) 대비, **기획팀장이 최소 권장하는 핵심 3종**:
-
-1. **맵패턴_42슬롯_현황테이블_v1.md §7 보완** — ⚠️ 고주의 4개 슬롯 별도 관리 (Stage 15·17) 신설. 본 보고 §6-4 이식.
-2. **맵패턴_사전분석_v1.md §1-4 개정** — C9 적합 스테이지 우선순위 분류(최적/주의) 신설. 본 보고 §4-2 이식.
-3. **스테이지난이도곡선_v1.md §8 보완** — Stage 11~15 TTK 테이블 + 흑기사1 재사용 3회째 주의 추가. 밸런스 축 §3-3 + 본 보고 §2-2-4 이식.
-
-나머지 4종(사전분석 §2-3·§3-2, 일관성점검 §2-3, 밸런싱전략 §3)은 Phase 3 재개 후 필요 시 순차 반영.
-
----
-
-## §9. 기각안 (P24 · C32 필수)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | Stage #11~#15 수치 조정 권고 | 이슈1_3_무시확정_v1.md §3-1-5 "의도 부합" PD 확정 전제. 이슈 1·3 현 수치 고정. 조정 불가 |
-| 2 | C9 금지 스테이지(7·10·13) 재판정 | P17-5 규칙 + 레벨 축 3축 검증 + 밸런스 축 검증 모두 금지 타당. 재판정 근거 없음 |
-| 3 | 42 슬롯 실 배치 확정을 본 보고서에서 수행 | Phase 3 재개 조건 미충족 (Unity MCP 시뮬 검증·ApprearMonsterPattern.json 재분해 필요). 본 보고는 검증 틀 + 가이드 프레임 |
-| 4 | 신규 조건 추가 제안 (N7 방어·N8 저HP 등) | 조건 풀 12개 PD 3차 승인 확정 · 재논의 대상 아님 (P28-8 종결 안건 재언급 금지) |
-| 5 | 이슈 1·3 수치 재논의 트리거 권고 | 이슈1_3_무시확정_v1.md §5-1-1 재논의 트리거 조건 (C9 배치 정합성 실패) 미발동. 본 작업 범위 외 |
-| 6 | 단일 축 판정만으로 결론 도출 | PD B 방식 병렬 호출 요지는 양축 교차 검증. 레벨·밸런스 양축 결과 통합 의무 |
-| 7 | Day 15+ 착수 여부 기획팀장 확정 | C36 PM·팀장 재량 상한 위반 후보 — PD 결정 영역. 기획팀장은 준비 상태 보고 + PM 경유 PD 결정 대기 |
-| 8 | 레벨·밸런스 제안 차이를 "충돌"로 프레이밍 | 교차 검증 결과 양축 판정 완전 일치. 보완 관계로 확인. 충돌 프레이밍은 C5 정직성 위반 |
-| 9 | ⚠️ 주의 등급 4개 슬롯을 "P17 위반"으로 격상 보고 | P17 배타는 아니며 '주의' 등급(동시 배치 시 난이도 극단화). 격상 시 PD B 방식 중단 트리거 오발동 리스크 |
-| 10 | 스테이지 17·18 C2∧N2 주의를 본 보고 Stage #11~#15 범위 내로 재편입 | Stage #11~#15 본 작업 범위 엄수. §2-2-5에 "Carry Over" 명시로 Day 15+ 인수인계 |
-| 11 | 밸런싱전략_v1 §3 v2 반영을 기획팀장 재량 집행 | 이슈 1 현 수치 고정 전제 + PD 별도 결정 대기 조항. 기획팀장 단독 집행 금지 |
-
----
-
-## §10. 변경 이력 (P16)
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (레벨기획자 대행 + 밸런스기획자 결과 통합 + 11-5 주도) | 초안 작성 · Day 11~14 5건 통합 재검증 보고 · 42 슬롯 P17 전수 체크 위반 0건 · Day 15+ 반영 후보 7종 · Phase 3 시뮬 권장 대상 확정 (Stage 11·15·17) |
-
----
-
-## §11. 재미 근거 (P30 기획팀 전용)
-
-**강화하려는 재미 축**: "전략 선택 다양성 · 재도전 유도 유기성"
-
-- **전략 선택 다양성**: C9 최적(Stage 12·20) vs 주의(Stage 11·16·17) vs 금지(Stage 7·10·13) 분류로 플레이어가 스테이지별 "보스 공략 vs 다른 전략"을 선택하는 경험 보존.
-- **재도전 유도 유기성**: 42 슬롯 후보 조합 풀의 P17 위반 0건은 "슬롯 배치 재작업 비용" 제거 효과. 배치 확정 시 재도전 유도 조건 다양성이 보장됨.
-- **고난도 구간 체감 설계**: ⚠️ 고주의 4개 슬롯(Stage 15·17)은 "ATK·Shield 이중 압박" 스테이지로 특별 관리. 맵 패턴 다양화 + 시뮬 검증으로 반복 체감을 극복한 "성장 후 재도전" 재미 경험 강화.
-- **양축 정합성**: 레벨 축 "조건 의미성·페이싱·재도전 유도 3축" + 밸런스 축 "TTK·DPS·EHP 수치 정합" 교차 검증으로 단일 축 편향 없는 통합 설계 품질 확보.
-
----
-
-## §12. PM 보고 요지
-
-| 항목 | 내용 |
-|------|------|
-| **산출물 경로** | `프로젝트/수상한잡화점/기획/재검증보고_맵패턴_v1.md` (본 보고) |
-| **Stage #11~#15 종합 판정** | **전수 적정 — 양축 일치** (조정 권고 없음) |
-| **42 슬롯 P17 전수 체크** | **위반 0건** (PD B 방식 중단 트리거 미발동) · ⚠️ 주의 등급 4개 슬롯(Stage 15·17) 별도 관리 |
-| **Phase 3 시뮬 권장 대상** | Stage 11 흡혈귀여왕2 Shd315 C9 임계값 · Stage 15 흑기사1 재사용·ATK45 N2 · Stage 17 용암골렘2 Shd525 (Day 15+ 1순위) |
-| **Day 15+ 반영 후보 통합** | 7종 (최우선 2 · 고우선 2 · 중우선 2 · PD 결정 대기 1) — 최소 권장 셋 3종 §8-3 |
-| **차단 요인** | 없음 — Day 11~14 종결 · Day 15+ 착수 준비 완료 |
-| **PD 결정 대기** | 밸런싱전략_v1 §3 Phase 4 v2 반영 (이슈 1 현 수치 고정 전제 유지) |
diff --git a/프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md b/프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md
deleted file mode 100644
index 347f712..0000000
--- a/프로젝트/수상한잡화점/기획/재논의대기_논점재정리_v1.md
+++ /dev/null
@@ -1,208 +0,0 @@
----
-type: 논점재정리
-작성일: 2026-04-20
-작성자: 기획팀장 (밸런스기획자 관점 반영)
-관련PD지시: 기획팀 #40 후속 PM 재량 E-1
-선행산출물: 재논의대기_사전자료모음_v1.md (2026-04-14)
-상태: 확정 (Day 8~10 트랙 A 착수 시 즉시 활용)
-범위: 논점 재정리 · 구조화 · 질문 리스트 축약. **수치 제안 금지** (사전자료모음 §5 PD 지시 유지)
----
-
-# 재논의 대기 이슈 — 논점 재정리 v1
-
-## 0. 본 문서의 역할
-
-`재논의대기_사전자료모음_v1.md` (2026-04-14) 본문을 **Day 8~10 트랙 A 착수 시 5분 이내 즉시 활용 가능한 구조**로 압축·재정리. 원본 사전자료모음은 **변경하지 않는다** (PD 승인 범위 엄수). 본 문서는 논점·질문·선행 의존·통합 처리 권고만 추출하여 트랙 A 실무에 즉시 투입할 수 있도록 한다.
-
----
-
-## 1. 3축 논점 구조 (핵심 요약)
-
-Day 8~10 트랙 A에서 통합 재논의해야 할 논점은 **3개의 축**으로 구조화된다.
-
-### 축 1 — 카드 DPS 과도 (이슈 1 · HIGH)
-
-**핵심 사실 (Phase 2 §5 이슈 1 원문)**
-
-| 항목 | 목표 | 실측 (이론치) | 실전 추정 | 판정 |
-|------|------|-------------|---------|------|
-| G1 풀빌드 DPS 기여 | +80~120% | +399% | +200~280% | **초과 (2~3배)** |
-| G1 풀빌드 EHP 기여 | +80~120% | +48% | — | 적정 (또는 소폭 미달) |
-
-**구조적 특징**: DPS만 과도 · EHP 적정 → **비대칭 과도**. "카드 파밍하면 DPS는 폭발, 생존은 보통" 구조.
-
-**재미 관점 문제 (P30)**:
-- 아웃게임 스펙업(장비·각성·인장)이 필요해지는 구간이 **너무 늦게** 도래
-- 카드만으로 스테이지 후반까지 압도 가능 → 성장 요소 간 순서 원칙(카드 > 장비 > 각성 > 인장) 붕괴 우려
-
-### 축 2 — 신성 빌드 G4/G5 확장성 부족 (이슈 3 · LOW)
-
-**핵심 사실 (Phase 2 §5 이슈 3 원문)**
-
-| 지표 | 신성 빌드 | 처치 연쇄 (비교군) |
-|------|----------|------------------|
-| 총 카드 | 22장 | 56장 |
-| G1 1런 기대 선택수 | 1.87장 | 2.72장 |
-| **G4+G5 핵심 카드 수** | **2장** | 15장 |
-| 1런 G4+G5 기대 선택수 | 0.019장 | 0.165장 |
-
-**구조적 특징 (동일 빌드의 두 얼굴)**:
-- **강점**: G1 풀의 10%가 신성 → 초반 빌드 형성 접근성 매우 높음 (캐주얼 친화)
-- **약점**: G4+G5 확장 카드 2장뿐 → **"터지는 순간" 부재** (Balatro류 폭발 쾌감 없음)
-
-**재미 관점 문제 (P30)**:
-- "쉬운 시작 + 낮은 폭발" 구조가 **의도된 캐주얼 빌드**인지 **조정 대상**인지 판정 필요
-- 무과금·소과금에 유리한 접근성 빌드로 존치 vs G4·G5 강화 양자택일
-
-### 축 3 — 연동 처리 필연성 (이슈 1·3 간 상호작용)
-
-**공통 축**: 카드 수치·등급 분포 재조정이라는 **동일 조정 축**에 영향.
-
-**분리 처리 시 상호 악화 리스크**:
-
-| 시나리오 | 결과 |
-|---------|------|
-| 이슈 1 먼저 (전체 DPS 축소) | 신성 빌드는 더욱 약화 → **이슈 3 악화** |
-| 이슈 3 먼저 (신성 G4·G5 강화) | 전체 DPS 과잉 심화 → **이슈 1 악화** |
-
-**PD님 확정 (2026-04-14 `Phase2_카드임팩트측정_v1 §5` 이슈 3)**:
-> "이슈 1(카드 DPS 과도) ↔ 이슈 3(신성 G4/G5 확장성)은 동일 카드 수치 축에 영향. 분리 처리 시 상호 악화 리스크로 **동시 논의 방식 사전 확정**. 재논의 시점 기획팀장이 통합 안건으로 제시할 것."
-
-→ **통합 재논의가 PD 승인 방향**. 분리 처리는 규칙 위반에 준함.
-
----
-
-## 2. 재논의 시 핵심 질문 축약 (5분 확인용)
-
-사전자료모음 §1-5·§2-5의 9개 질문을 Day 8~10 트랙 A 착수 시점에 즉시 답변 가능한 수준으로 **5개로 압축**.
-
-### Q1. 이론치 vs 실전치 간극 해소 (C# 시뮬 실측 필요)
-G3~G5의 **질적 효과**(기절·반사·부활·무적 등)까지 포함한 실전 체감 DPS는 몇 %인가?
-- 이론치 +399% / 실전 추정 +200~280% / 질적 효과 포함 시 추정 불가
-- **필요 산출물**: Unity MCP 실측 (v2 리포트 기반 Day 8~10에서 카드 메커닉 시뮬 구현 후)
-
-### Q2. 목표치 vs 수치 조정 (방향 결정)
-실전 +200~280% DPS 증가율이 목표 +80~120%를 초과한다. 조정 대상은:
-- (a) **목표치 상향** (현 수치 유지 · 밸런싱전략_v1 §3 목표 재조정)
-- (b) **카드 수치 하향** (목표 유지 · 전체 카드 수치 재작업)
-- (c) **혼합** (목표 소폭 상향 + 카드 일부 하향)
-
-**기획팀장 관점**: C36 판정 기준 — (a)·(b)·(c) 선택은 PD님 결정 영역. Day 8~10에서 **3안 제시 + 시뮬 근거 첨부 + PD 결정 요청** 구조로 진행 권고.
-
-### Q3. 드래프트 트레이드오프 의도성 판정
-힐·쉴드 카드가 "DPS 기여 0이나 생존 기여 큰" 구조는:
-- 의도된 드래프트 선택지 (현 설계 유지)
-- 균형 조정 대상 (힐·쉴드도 경미한 DPS 기여 추가)
-
-### Q4. 성장 요소 순서 원칙 유지 여부
-**카드 > 세트 장비 > 각성** 기여도 순서가 Phase 3 v2 실측 기준으로 유지되는가?
-- v2 리포트 (2026-04-20 `재검증보고_Phase0_1_2_v1.md` Day 2~3 결과)에서 장비·각성 오차 확인 완료 (장비 일반 +0.35%·세트 +0.86%·인장 +0.34% 정확 일치)
-- Day 4~7 성장 요소 기여도 6건 완료 후 순서 원칙 유지 여부 판정 가능
-
-### Q5. 신성 빌드 캐주얼 포지셔닝 유지 여부
-신성 빌드의 "쉬운 시작 + 낮은 폭발" 구조는:
-- **유지안**: 무과금·접근성 빌드로 포지셔닝 확정 (G4·G5 현 상태 유지 · 다른 빌드로 "폭발" 경험 제공)
-- **조정안**: G4 3~4장·G5 1~2장 추가 (사전자료모음 §2-3 · 기존 수치 조정으로 대응 · 카드 효과 종류 e_CardType 추가 금지)
-- **혼합안**: 신성 빌드 G5에 극레어 "폭발" 카드 1장만 추가 (최소 개입)
-
----
-
-## 3. 선행 의존 체계 (착수 전 필수 확인)
-
-**사전자료모음 §1-6·§2-6 통합 최신화 (2026-04-20 기준)**
-
-| # | 선행 조건 | 상태 | 비고 |
-|---|---------|------|------|
-| 1 | Unity MCP EditMode 시뮬 환경 구축 | ✅ **완료** | 개발팀 #28·#37 |
-| 2 | Unity MCP 실측 검증 리포트 v2 | ✅ **완료** | `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md` (UTF 14/14 · 오차 0.34~1.69%) |
-| 3 | Unity MCP 시뮬 실행 가이드 | ✅ **완료** | `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md` |
-| 4 | Phase 3 재개 (v2 재작성) | 🟡 **진행중** | Day 4~7 성장 요소 6건 착수 가능 (v2 리포트 §6-2) |
-| 5 | Day 4~7 성장 요소 기여도 6건 완료 | ⏳ 대기 | #16~#21 (카드 > 장비 > 각성 > 인장 순서 원칙 실측) |
-| 6 | 모든 카드 검증 완료 | ⏳ 대기 | 카드 메커닉 시뮬 구현 Day 8~10 범위 (v2 §6-3) |
-| 7 | Python ↔ C# 교차 검증 | 🔴 **HOLD 해제됨** | PD님 "단일축 SOT = Unity MCP EditMode" 지시 (Python 시뮬 폐기) |
-
-**Day 8~10 트랙 A 착수 조건**:
-- 조건 4·5 완료 필수 (Day 4~7 성장 요소 6건 종결 시점)
-- 조건 6은 Day 8~10 **트랙 A 범위 내 수행**이므로 선행 아님
-
----
-
-## 4. 통합 처리 원칙 (재논의 시 준수 권고)
-
-**사전자료모음 §3-3 재확인 · PD 2026-04-14 승인 방향 유지**
-
-1. **전체 DPS 목표치 재설정** (이슈 1 선행) → 전체 카드 수치 기준 확정
-2. **기준 내에서 빌드별 강약 재분배** (이슈 3 후속) → 신성 빌드 G4·G5 밀도 조정
-3. **최종 실측으로 양 이슈 동시 검증** (Unity MCP EditMode 단일축)
-
-**금지 사항**:
-- 이슈 1·3 분리 작업 (PD 직접 승인 방향 위반)
-- 카드 효과 종류(`e_CardType`) 신규 추가 (기획실 특화 규칙 · 사전자료모음 §2-3)
-- 신규 카드 추가 (PD님 사전 승인 필수)
-
-**허용 사항**:
-- 기존 카드 수치 조정으로만 대응 (G4·G5 기존 카드 강화)
-- 확률 조정 (등급별 드랍률 재조정)
-
----
-
-## 5. 기타 재논의 대기 이슈 (참고)
-
-사전자료모음 §4 원문 유지. 본 문서에서 재서술하지 않음. 재개 시 원문 참조.
-
-- **4-1. N7 방어 성공 조건 추가 검토** — 실측 완료 (#37). 조건 풀 13번째 추가 여부 Phase 3 재개 시 PD 결정
-- **4-2. C10 "성장의 증거" 조건** — PD 2026-04-14 보류. 향후 확장 항목
-- **4-3. N8 "저 HP 완주" 수치 변형** — HP ≤ 30%보다 난해한 수준. Phase 3 재개 후 시뮬 튜닝
-
----
-
-## 6. 본 문서 한계·범위 엄수
-
-- **수치 제안 금지** (사전자료모음 §5-1 PD 승인 방향 유지)
-- **신규 기획 의사결정 금지** — 본 문서는 논점 재정리만 수행
-- **원문 해석 변경 금지** — Phase 2 §5 이슈 1·3 원문·사전자료모음 §1·§2 원문 근거로만 서술
-- 수치 결정·조정안 제시는 **Day 8~10 트랙 A 실무 수행 시 별도 산출물** (본 집행 범위 A-초안이 기획 가정 범위로 선행)
-
----
-
-## 7. 기각안 (P24·C32)
-
-| # | 기각 대안 | 기각 사유 |
-|---|---------|---------|
-| 1 | 본 문서에 수치 조정안 포함 | PD 2026-04-14 "사전자료는 조정 제안 금지" 방향 유지. Day 8~10 별도 산출물에서 처리 |
-| 2 | 이슈 1·3 분리 처리 프레임 유지 | PD 2026-04-14 "통합 재논의 방식 사전 확정" 직접 지시 위반 |
-| 3 | 질문을 9개 모두 유지 (압축 없이) | 사전자료모음 §1-5·§2-5 원본 유지. 본 문서는 **착수 시 즉시 활용** 목적이므로 5개로 압축 필요 |
-| 4 | Python ↔ C# 교차 검증 선행 조건 유지 | PD 지시 "단일축 SOT = Unity MCP EditMode"로 Python 시뮬 폐기 확정 (`재검증보고_Phase0_1_2_v1.md` 반영) |
-
----
-
-## 8. 재미 근거 (P30)
-
-- **강화하려는 재미 축**: "성장 요소 간 시너지 곡선의 자연스러움" + "Balatro류 폭발 쾌감"
-- **변경 전 재미 문제**:
-  1. 카드 DPS 과도로 아웃게임 성장(장비·각성·인장)의 체감 부재 → 성장 동기 약화
-  2. 신성 빌드 "터지는 순간" 부재로 선택한 빌드의 절정 경험 부재
-- **변경 후 기대 경험 (Day 8~10 트랙 A 해결 목표)**:
-  1. 카드만으로 압도되지 않는 **성장 요소 시너지 곡선** 실현
-  2. 각 빌드마다 고유의 **절정 순간** 보유 (신성 포함)
-- **측정 지표**: 스테이지별 성장 요소 기여도 순서 · 빌드별 풀빌드 DPS/EHP 증가율 분포 · Unity MCP 시뮬 기반 ★3 달성률
-
----
-
-## 9. 관련 문서
-
-- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md` (원본 · 수정 금지)
-- `프로젝트/수상한잡화점/기획/Phase2_카드임팩트측정_v1.md` §5 이슈 1·3
-- `프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md` §2 축 1 (신성 폭격)
-- `프로젝트/수상한잡화점/기획/밸런싱전략_v1.md` §3 Phase 3 목표
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md`
-- `공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md`
-- `프로젝트/수상한잡화점/기획/이슈1_3_통합재논의_v1_초안.md` (본 문서 후속 · A-초안)
-
----
-
-## 10. 변경 이력
-
-| 일시 | 변경자 | 변경 내역 |
-|------|-------|----------|
-| 2026-04-20 | 기획팀장 (밸런스기획자 관점 반영) | 초안 작성 · Day 8~10 트랙 A 즉시 활용용 압축본 |
diff --git a/프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md b/프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md
deleted file mode 100644
index 8db6ab0..0000000
--- a/프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md
+++ /dev/null
@@ -1,239 +0,0 @@
-# 수상한 잡화점 — 재논의 대기 이슈 사전 자료 모음 v1
-
-> 작성일: 2026-04-14
-> 담당: 기획팀장 (총괄PM을 통한 PD님 승인 지시에 따른 홀드 중 가능 작업)
-> 지시: 작업 착수 보고서 "우선순위 중 (2)" + "우선순위 하" 항목
-> **범위 엄수**: 본 문서는 **사전 자료 정리만** 수행. 실제 조정 제안은 금지 (PD님 지시)
-
----
-
-## 0. 본 문서의 역할
-
-PD님이 "후속 검증 완료 후 재논의"로 이관한 이슈 2건에 대해, **재논의 시점에 즉시 의사결정이 가능하도록 관련 자료를 한 곳에 집약**한다. 본 문서는:
-
-- 현 상태 기록·요약만 수행
-- 신규 수치 제안·조정 방향 결정 **금지**
-- 모든 수치는 출처 원문 그대로 인용
-
----
-
-## 1. 이슈 1: 카드 DPS 기여도 과도 (HIGH)
-
-### 1-1. 문제 정의 (Phase2_카드임팩트측정_v1 §5 이슈 1 원문 기반)
-
-| 항목 | 목표 (밸런싱전략_v1) | Phase 2 실측 | 판정 |
-|------|-------------------|------------|------|
-| G1 풀빌드(19장) **DPS** 기여 | +80~120% | **+399%** | 초과 (3~4배) |
-| G1 풀빌드(19장) **EHP** 기여 | +80~120% | +48% | 적정 |
-
-**기획팀장 해설**: DPS만 과도. EHP는 목표 범위에 근접하거나 오히려 소폭 미달. 즉 "카드만 파밍하면 DPS는 폭발하는데 생존은 보통 수준"인 비대칭 구조.
-
-### 1-2. 이론치 vs 실전치의 간극
-
-Phase2 §5 이슈 1 단서조항:
-- 이론치 +399%는 "모든 카드가 DPS에 기여한다"는 가정
-- 실전에서는 힐·쉴드 카드는 DPS 기여 0
-- 드래프트 트레이드오프로 실전 DPS 증가율은 이론치의 **50~70% 수준(+200~280%)**으로 예상
-
-→ 실전 추정치 +200~280%도 목표 +80~120% 대비 **2~3배 초과**
-
-### 1-3. Phase 2에서의 처리 결정 (PD님)
-
-> "모든 카드 검증이 끝난 후 확률 조정·수치 조정 등을 포함해 재논의. 현시점 조치 보류, Phase 3 및 후속 검증 완료 후 재논의 대상으로 이관."
-
-→ 본 이슈는 **Phase 3 완료 + 모든 카드 검증 완료** 시점에 재논의
-
-### 1-4. 재논의 시 참고할 연관 데이터
-
-**앵커 PC 기본값 (Phase0_1 §1)**:
-- DPS = 1.05 (ATK 평균 2.5 / CT 2.4s)
-- EHP = 64 (HP 58 + Shield 6)
-- TTK vs Stage 1 일반 몬스터(HP 6.9) = 5.7초
-
-**카드 1장 평균 기여 (Phase 2 §2)**:
-| 등급 | 카드수 | 평균 DPS 기여 | DPS 증가율 | 평균 EHP 기여 | EHP 증가율 |
-|------|--------|-------------|----------|-------------|----------|
-| G1 | 112 | +0.23 | +22% | +1.6 | +2.5% |
-| G2 | 73 | +0.26 | +25% | +1.1 | +1.7% |
-| G3 | 51 | +0.10 | +9% | +1.0 | +1.6% |
-| G4 | 43 | +0.13 | +13% | +1.1 | +1.7% |
-| G5 | 32 | +0.09 | +9% | +1.2 | +1.8% |
-
-**G1 카드 누적 임팩트 (Phase 2 §3)**:
-| 보유 카드 수 | 총 DPS | TTK | TTK 감소율 | 총 EHP | EHP 증가율 |
-|------------|-------|------|----------|--------|----------|
-| 0장 (앵커) | 1.05 | 5.7s | 기준 | 64 | 기준 |
-| 1장 | 1.28 | 5.4s | -6% | 65.6 | +3% |
-| 3장 | 1.74 | 4.0s | -31% | 68.8 | +8% |
-| **5장** | **2.21** | **3.1s** | **-45%** | **72.0** | **+13%** |
-| 10장 | 3.36 | 2.1s | -64% | 80.0 | +25% |
-| 19장(풀) | 5.44 | 1.3s | -78% | 94.4 | +48% |
-
-**실전 드래프트 (Phase 2 §3)**:
-- 등급 혼합 풀빌드 DPS: 5.24 (기본 대비 **+399%**)
-- 등급 혼합 풀빌드 EHP: 91.1 (기본 대비 **+42%**)
-- 등급 혼합 풀빌드 TTK: 5.7s → **1.3s** (감소 77%)
-
-**질적 효과 미포함**:
-- G3~G5의 기절·반사·부활·무적·MaxHP2배 등은 수치 계산에 미포함
-- 실전에서는 이들의 질적 효과가 추가로 승수 작용
-
-### 1-5. 재논의 시 확인할 핵심 질문
-
-**본 문서는 질문 제기만 수행. 답변 제시 금지.**
-
-1. G1 카드 1장당 +22% DPS 증가율은 "카드를 뽑았을 때 체감되는가"라는 Phase 2 목표 관점에서 적절한가?
-2. 실전 +200~280% DPS 증가율이 목표 +80~120%를 초과하는 것은, 목표 자체를 재조정해야 하는지 카드 수치를 내려야 하는지?
-3. G3~G5의 **질적 효과**(기절·반사·부활 등)까지 포함하면 실제 체감 증가율은 어느 수준인가? — C# 시뮬로 실측 필요
-4. 힐·쉴드 카드가 "DPS 기여 0이나 생존 기여 큰" 구조가 드래프트 트레이드오프로 의도된 것인가, 균형 조정 대상인가?
-5. **카드 DPS 기여 > 세트 장비 DPS 기여 > 각성 DPS 기여** 순서 원칙이 유지되는가? (Phase 3 실측 필요)
-
-### 1-6. 재논의 선행 조건
-
-- Phase 3 성장 요소별 기여도 실측 완료 (각성·진화·장비·인장)
-- 모든 카드 검증 완료 (현재 진행 여부 미상 — 총괄PM에 확인 필요)
-- 개발실 Headless C# 시뮬 추출 완료
-- Python ↔ C# 교차 검증으로 이론치·실전치 간극 실측
-
-### 1-7. 관련 문서
-- `기획실/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md` §3·§5 이슈 1
-- `기획실/밸런싱/수상한잡화점/밸런싱전략_v1.md` §3 Phase 3 목표
-- `기획실/밸런싱/수상한잡화점/밸런싱문서_일관성점검_v1.md` §1-6 (목표·실측 괴리 기록)
-
----
-
-## 2. 이슈 3: 신성 빌드 G4/G5 확장성 부족 (LOW)
-
-### 2-1. 문제 정의 (Phase2_카드임팩트측정_v1 §5 이슈 3 원문 기반)
-
-| 지표 | 신성 빌드 | 처치 연쇄 (비교군) |
-|------|----------|-----------------|
-| 총 카드 | 22장 | 56장 |
-| G1 1런 기대 선택수 | 1.87장 | 2.72장 |
-| G4+G5 핵심 카드 수 | **2장** | 15장 |
-| 1런 G4+G5 기대 선택수 | **0.019장** | 0.165장 |
-
-**문제**: 신성 빌드는 G1~G2에서 **빌드 시작은 쉽지만**, G4+G5 확장 카드가 2장뿐이라 빌드가 **"터지는" 순간이 없음**. Balatro류 "폭발의 쾌감" 부재.
-
-### 2-2. 카드시너지축분석_v1에서의 관점
-
-카드시너지축분석_v1 §2 축 1 (신성 폭격):
-- G1:11, G2:9 (G3~G5 합계 2장)
-- 빌드 시작 접근성: 매우 쉬움 (G1 풀의 약 10%가 신성)
-- 1런당 신성 G1 기대값: 약 1.87장 (빌드 형성 가능)
-
-**상충하지 않는 2개 관점**:
-- 카드시너지축분석: "G1 풀의 10%가 신성 — 초반부터 빌드 형성 가능" (**강점**)
-- Phase 2 이슈 3: "G4/G5 확장 카드 2장뿐 — 폭발 없음" (**약점**)
-
-→ 동일 빌드의 **두 얼굴**. 장점(접근성)과 단점(확장성 부족)이 공존.
-
-### 2-3. Phase 2 §5 이슈 3 "제안" (PD님 유보 상태)
-
-| 항목 | 현재값 | **제안값 (유보됨)** | 근거 |
-|------|--------|------------------|------|
-| 신성 빌드 G4 카드 | 1장 | 3~4장 | G4에서 빌드 완성 시그널 제공 |
-| 신성 빌드 G5 카드 | 1장 | 1~2장 | 극레어 "폭발" 카드 1장 추가 |
-
-**제약**: 카드 효과 종류(e_CardType) 추가 금지 — 기획실 특화 규칙
-**대응 방식 후보**:
-1. 기존 카드의 수치 조정으로만 대응 (G4·G5 기존 카드 강화)
-2. 신규 카드 추가 → PD님 사전 승인 필수
-
-**PD님 판단 (2026-04-14)**: 위 제안은 **모든 카드 검증 후 확률 조정·수치 조정 등을 포함해 종합 재논의** — 현시점 조치 보류
-
-### 2-4. 유저 세그먼트별 영향도 (Phase 2 §5 이슈 3 원문)
-
-| 세그먼트 | 영향도 | 해설 |
-|---------|--------|------|
-| 무과금 | 긍정적 | 신성 빌드 완성률 증가 — 접근성 높은 빌드이므로 유리 |
-| 소과금 | 동일 | |
-| 고과금 | 미미 | 고과금은 치명타/물약 등 레어 빌드를 노림 |
-
-### 2-5. 재논의 시 확인할 핵심 질문
-
-1. 신성 빌드의 "쉬운 시작 + 낮은 폭발" 구조가 **의도된 캐주얼 빌드**인가, 조정 대상인가?
-2. G4·G5 카드를 강화할 경우, 다른 빌드(치명타·물약 등 G4·G5 밀도 높은 빌드)와의 상대적 파워 변화는?
-3. 이슈 3 제안을 수용하면 G4·G5 전체 풀 재편이 필요한가? — 다른 빌드의 G4·G5 카드 수 대비 형평성 체크 필요
-4. 신성 빌드는 **카드시너지축분석 §2 축 1**에서 "후열타격 조합 시 폭발적" 평가 — 후열 관련 카드(★ 조건 N5 후열 선공과의 시너지 등)까지 통합해서 볼 때 정말 확장성 부족인가?
-
-### 2-6. 재논의 선행 조건
-
-- Phase 3 완료
-- 모든 카드 검증 완료
-- 이슈 1 (카드 DPS 과도) 재논의 완료 — 이슈 1과 이슈 3은 "카드 수치 재조정"이라는 같은 축이므로 **한꺼번에 다룰 것 권장**
-
-### 2-7. 관련 문서
-- `기획실/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md` §5 이슈 3
-- `기획실/밸런싱/수상한잡화점/카드시너지축분석_v1.md` §2 축 1
-- `기획실/CLAUDE.md` — "이슈 3(신성 빌드 G4/G5 확장성) 재검토 Phase 3 이후" 환기 메모
-
----
-
-## 3. 이슈 1·이슈 3 연동 처리 권고
-
-### 3-1. 공통 축 인식
-- 두 이슈 모두 **카드 수치·등급 분포의 재조정** 축
-- 이슈 1: "전체 카드의 DPS 기여가 과도" (매크로 관점)
-- 이슈 3: "특정 빌드(신성)의 G4·G5 확장성 부족" (마이크로 관점)
-
-### 3-2. 분리 처리 리스크
-- 이슈 1만 먼저 조정 → 신성 빌드는 더욱 약화 (이슈 3 악화)
-- 이슈 3만 먼저 조정 → 전체 DPS 과잉 심화 (이슈 1 악화)
-
-### 3-3. 통합 처리 원칙 (재논의 시 준수 권고)
-1. 전체 DPS 목표치 재설정 (이슈 1) → 전체 카드 수치 기준 확정
-2. 기준 내에서 빌드별 강약 재분배 (이슈 3) → 신성 빌드 G4·G5 밀도 조정
-3. 최종 실측으로 양 이슈 동시 검증
-
----
-
-## 4. 기타 재논의 대기 이슈 (참고)
-
-### 4-1. N7 방어 성공 조건 추가 검토
-- 현 상태: 12개 조건 풀 **채택**, N7은 **보류·추후 추가 예정**
-- 재개 조건: 개발실 최신 코드 분석 + 방어 시스템 현황 재확인 완료
-- Phase 2 §5 인용: "N7 방어 성공: 보류·추후 추가 예정 — 개발실이 최신 코드 분석 중이며, 방어 시스템이 이미 적용되어 있음. 개발실 분석 완료 후 재확인하여 조건 풀에 추가할 것"
-- 관련 문서: `기획실/CLAUDE.md` "방어 시스템 관련 작업 시점"
-
-### 4-2. C10 "성장의 증거" 조건 보류
-- 현 상태: PD님 판단(2026-04-14 2차)으로 **보류** (게임 복잡성 증가 우려)
-- 향후 확장 항목으로 이관
-
-### 4-3. N8 "저 HP 완주" 수치 변형 채택
-- 현 상태: "HP ≤ 30%" 보다 난해한 수준으로 설계 (재도전 유도 목적)
-- 정확한 임계값은 Phase 3 재개 후 시뮬로 튜닝 필요
-
----
-
-## 5. 본 문서의 한계
-
-### 5-1. 수행 범위 엄수
-- **조정 제안 일절 금지** (PD님 지시)
-- **신규 수치 제시 금지**
-- 기존 문서 원문 인용만 수행
-
-### 5-2. 미해결 의존성
-- 이슈 1·3 모두 Phase 3 완료 + 모든 카드 검증 완료를 기다림
-- 현 HOLD 상황에서 실측 재수행 불가
-
-### 5-3. 작업 재개 시 접근법
-- 이슈 1·3을 **통합 처리** 권고 (§3-3)
-- 이슈 1 단독 처리 시 이슈 3 악화, 그 반대도 성립
-
----
-
-## 6. 참조 문서 전체 목록
-
-- `기획실/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md`
-- `기획실/밸런싱/수상한잡화점/Phase0_1_앵커전투시뮬레이션_v1.md`
-- `기획실/밸런싱/수상한잡화점/카드시너지축분석_v1.md`
-- `기획실/밸런싱/수상한잡화점/밸런싱전략_v1.md`
-- `기획실/밸런싱/수상한잡화점/밸런싱문서_일관성점검_v1.md`
-- `기획실/CLAUDE.md`
-- `기획실/⚠️_PHASE3_HOLD_공지.md`
-
----
-
-*작성 완료: 2026-04-14*
-*상태: 재논의 대기 자료 집약본 / 추가 분석·제안 불가*
diff --git a/프로젝트/수상한잡화점/기획/전체테이블감사_v1.md b/프로젝트/수상한잡화점/기획/전체테이블감사_v1.md
deleted file mode 100644
index af40426..0000000
--- a/프로젝트/수상한잡화점/기획/전체테이블감사_v1.md
+++ /dev/null
@@ -1,594 +0,0 @@
-# 수상한 잡화점 - 전체 테이블 감사 v1
-> 작성일: 2026-04-13 | 소스: D:/BurningTimes/.../Export/*.json
-
----
-
-## 1. 테이블별 요약
-
-### 1-1. 전투 기본 (PC vs 몬스터)
-
-#### PCList.json (5 entries)
-PC 기본 스탯. 시뮬레이션의 출발점.
-
-| PC | ATK Min | ATK Max | CT(s) | Cri(%) | CriDmg(%) | HP | Shield | Avoid_M(%) | Avoid_R(%) | Type |
-|----|---------|---------|-------|--------|-----------|-----|--------|-----------|-----------|------|
-| 6001 | 1 | 4 | 2.4 | 2.6 | 150 | 58 | 6 | 5 | 5 | Melee |
-| 6002 | 2 | 4 | 2.7 | 3.1 | 150 | 28 | 18 | 10 | 10 | Range |
-| 6003 | 1 | 2 | 2.4 | 3.3 | 130 | 27 | 12 | 9 | 9 | Melee |
-| 6004 | 2 | 3 | 2.5 | 2.8 | 150 | 19 | 46 | 6 | 6 | Range |
-| 6005 | 2 | 4 | 2.6 | 3.2 | 150 | 42 | 8 | 8 | 8 | Melee |
-
-**특이사항**: 6001은 HP형(58), 6004는 Shield형(46), 6002는 균형형. 6003은 전체 스탯 최저이나 CriRate 최고(3.3%).
-
-#### MonsterList.json (248 entries)
-몬스터 4개 그룹. 시뮬레이션 시 스테이지별 적 스탯 근거.
-
-| 그룹 | 수 | HP 범위 | Shield 범위 | ATK 범위 | CT 범위 |
-|------|-----|---------|------------|----------|---------|
-| 1xxxx (일반) | 183 | 5~1757 (avg 147) | 0~5395 (avg 115) | 1~566 | 0.8~3.7 |
-| 2xxxx (특수) | 5 | 50~1250 (avg 535) | 0 (전원) | 6~116 | 1.6 |
-| 7xxxxx (Area7) | 24 | 20~1654 (avg 572) | 0~1975 (avg 674) | 4~379 | 1.4~3.0 |
-| 8xxxxx (Area8) | 36 | 45~1749 (avg 660) | 50~1633 (avg 395) | 4~379 | 1.4~3.0 |
-
-- e_MonsterType: Normal_Melee, Normal_Range, Boss_Melee, Boss_Range
-- n_Specificity1~4: 전투 패턴에서 해당 몬스터를 등장 그룹으로 연결
-
-#### GlobalValue.json (22 entries)
-전투 관련 전역변수 **전체 목록**:
-
-| Key | Value | 설명 |
-|-----|-------|------|
-| ReviveTime_byDefeatUI | 0.5 | 부활 시 무적 시간(s) |
-| FrontMonster_ProjectileSpeed | 35 | 전열 투사체 속도 |
-| BackMonster_ProjectileSpeed | 45 | 후열 투사체 속도 |
-| PC_ProjectileSpeed | 40 | PC 투사체 속도 |
-| DungeonMovement_DefaultTime | 2.5 | 탐험 이동 기본 시간(s) |
-| CampFire_Default_HP | 5 | 캠프파이어 기본 HP 회복 |
-| CampFire_Default_Gold | 10 | 캠프파이어 기본 골드 |
-| CampFire_Default_EXP | 5 | 캠프파이어 기본 EXP |
-| ProductDiscountUnitRate | 10 | 상인 할인율 단위(10%) |
-| CardGrade_Weight_1 | 1000 | G1 카드 등장 가중치 |
-| CardGrade_Weight_2 | 300 | G2 카드 등장 가중치 |
-| CardGrade_Weight_3 | 150 | G3 카드 등장 가중치 |
-| CardGrade_Weight_4 | 50 | G4 카드 등장 가중치 |
-| CardGrade_Weight_5 | 10 | G5 카드 등장 가중치 |
-| CardGachaSoul | 300 | 카드 뽑기 소울 비용 |
-| ShinyMonsterGoldRate | 1.5 | 빛나는 몬스터 골드 배율 |
-| DeathGrowUp_Rate | 0.2 | 거대화 1회 비율 |
-| DeathGrowUp_RateMax | 2 | 거대화 한계 비율 |
-| TreasureChest_ForceOpen_Rate | 0.25 | 보물상자 강제 오픈 확률 |
-| Gacha_Seal_Normal_Soul | 100 | 인장 일반 뽑기 소울 |
-| Gacha_Seal_Advanced_Soul | 300 | 인장 고급 뽑기 소울 |
-| CatGoodsShopItemCount | 4 | 잡화점 아이템 수 |
-
-**PCDefence / PCDefence_Mul 키: 존재하지 않음.** GlobalValue에 방어력 관련 키가 전혀 없다. 데미지 감소는 코드 또는 장비 세트효과(ReduceDmg)에서만 처리되는 것으로 보임.
-
----
-
-### 1-2. 스테이지 구성
-
-#### CreateMapConfig.json (123 entries)
-Stage1_1 ~ Stage21_4 + Stage99_1(테스트). 모든 스테이지가 동일한 노드 확률 구조를 공유함.
-
-| 필드 | 일반 스테이지 값 | Stage99(테스트) |
-|------|-----------------|----------------|
-| f_Monster | 80 | 80 |
-| n_MobNodeMin/Max | 10/20 | 6/10 |
-| f_BuffDebuff | 2.3 | 0 |
-| f_CampFire | 16.2 | 100 |
-| f_Merchant | 1 | 0 |
-| f_Treasure | 1.5 | 100 |
-| f_NPC | 3 | 0 |
-| f_Mine | 5 | 0 |
-| f_TwoWay | 1 | 0 |
-| f_Nothing | 1 | 10 |
-| f_Random | 20 | 20 |
-
-**시뮬레이션 핵심**: 일반 스테이지는 전부 동일한 노드 확률. 차이는 n_AppearMonsterGroup(등장 몬스터 풀)과 s_MonsterPattern(사용 패턴 ID)만 다름.
-
-#### RandomPatternConfig.json (30 entries)
-Random 노드 내부의 서브타입 분배. ID 1~30, 각각 다른 비율.
-
-- 기본 구조: n_NothingRate(4400~6000) > n_MonsterRate(2800~4200) > n_MineRate(300~500) > n_BuffDebuffRate(200~900)
-- 상인/NPC/보물은 희귀 (30~600)
-- n_MonsterLimitCount: 14~18, n_BuffDebuffLimitCount: 2~4
-
-#### MonsterPatternList.json (101 entries)
-패턴별 몬스터 수(min/max), 전열/중열/대기열 Melee/Range/Fixed 가중치.
-- n_MonsterMin: 전부 1, n_MonsterMax: 전부 3
-- e_AppearType: 전부 "Mix"
-- 전열(Front)에 Melee 가중치 높음, 후열(Back)에 Range 가중치 높음
-
-#### ApprearMonsterPattern.json (753 entries)
-n_AppearMonserGroup -> n_MonsterID + n_AppearRate. CreateMapConfig의 n_AppearMonsterGroup과 연결.
-
----
-
-### 1-3. 카드 시스템
-
-#### CardList.json (311 cards)
-등급 분포: G1=112, G2=73, G3=51, G4=43, G5=32
-
-카드 가중치 기반 등장 확률:
-- G1: 1000/1510 = **66.2%**
-- G2: 300/1510 = **19.9%**
-- G3: 150/1510 = **9.9%**
-- G4: 50/1510 = **3.3%**
-- G5: 10/1510 = **0.66%**
-
-e_LvUpType 분포:
-| LvUpType | 수 | 의미 |
-|----------|-----|------|
-| Use_LvUpValue1_To_Value1 | 107 | val1 직접 증가 |
-| Use_LvUpValue1_To_Value2 | 89 | val2 직접 증가 |
-| Heal_Multi | 74 | 힐 배율 증가 |
-| Use_LvUpValue1_To_Value3 | 15 | val3 직접 증가 |
-| Use_LvUpValue1_To_ProjectileCount | 11 | 투사체 수 증가 |
-| Heal_Mul | 12 | 힐 배수 |
-| GetGold | 3 | 골드 획득 |
-
----
-
-### 1-4. 성장 시스템
-
-#### BattleLevelUp.json (20 levels, 인게임)
-| Lv | 필요 EXP | 누적 EXP |
-|----|---------|---------|
-| 1 | 3 | 3 |
-| 5 | 32 | 78 |
-| 10 | 97 | 423 |
-| 15 | 194 | 1186 |
-| 20 | 0 (MAX) | 2222 |
-
-#### PCLevelUp.json (20 levels, 아웃게임)
-BattleLevelUp과 **완전 동일한 곡선** (3, 7, 14, 22, 32 ... 300, 총 2222).
-
-#### PCEvolution.json (30 entries = 5 PC x 6 stars)
-PC6001 진화별 스탯 증분:
-
-| Star | ATK | MaxHP | MaxShield | HitRate |
-|------|-----|-------|-----------|---------|
-| 1 | +1 | +3 | +1 | +2 |
-| 2 | +2 | +6 | +2 | +3 |
-| 3 | +4 | +10 | +4 | +4 |
-| 4 | +7 | +15 | +7 | +5 |
-| 5 | +10 | +22 | +10 | +6 |
-| 6 | +15 | +30 | +15 | +8 |
-
-#### PCEvolutionMax.json (9 entries)
-최대 진화 이후 추가 랜덤 스탯 획득 풀:
-| Stat | Value | Rate |
-|------|-------|------|
-| Attack_Min | +1 | 3% |
-| Attack_Max | +1 | 6% |
-| MaxHP | +1 | 35% |
-| MaxShield | +1 | 25% |
-| HitRate | +1 | 3% |
-| Avoid_Melee | +0.1% | 5% |
-| Avoid_Range | +0.1% | 5% |
-| Cri | +0.1% | 3% |
-| CriDmg | +1% | 15% |
-
-#### PCAwakening.json (1225 entries = 5 PC x ~245 nodes)
-PC6001 기준 245개 노드, Step 1~138.
-
-**전투력 직결 노드 (Stat_ADD)**:
-| 스탯 | Step 6까지 | Step 12까지 | Step 25까지 | 비고 |
-|------|-----------|------------|------------|------|
-| MaxHP | +9 | +9 | +18 | 주요 생존 |
-| MaxShield | +9 | +9 | +18 | 주요 생존 |
-| Attack_Max | +5 | +5 | +5 | |
-| Attack_Min | 0 | 0 | +5 | Step 24 해금 |
-| CriDmg | 0 | +0.25 | +0.25 | |
-| Avoid_Melee | 0 | +0.005 | +0.005 | |
-| Avoid_Range | 0 | +0.005 | +0.005 | |
-| Cri | 0 | +0.005 | +0.005 | |
-| AttackCoolTimeMul | 0 | 0 | +0.05 | Step 13 해금 |
-| HitRate | 0 | 0 | +5 | Step 19 해금 |
-
-**핵심 비전투 노드**:
-| 노드 | Step | val (maxLv시) | 설명 |
-|------|------|--------------|------|
-| LvUpHeal | 6 | 1 (maxLv=1) | 레벨업 시 HP 1 회복 |
-| CampHeal_Add | 6 | 2+4=6 (maxLv=5) | 캠프 HP 회복 +6 |
-| CampHeal | 12 | 3 (maxLv=1) | 캠프 HP 회복 +3 |
-| CampGold | 3 | 해금만 | 캠프 골드 추가 획득 |
-| CampGold_Add | 5 | 5+8=13 (maxLv=5) | 캠프 골드 +13 |
-| Open_Sanctuary_Heal | 5 | 해금 | 회복의 성소 해금 |
-| Sanctuary_Heal_Up | 8 | 5+8=13 (maxLv=5) | 성소 회복량 +13 |
-| SpringHeal_Add | 15 | 1+4=5 (maxLv=5) | 샘 회복 +5 |
-
-**장비 슬롯 해금 순서**: Glove(Step 4) -> Boots(Step 10) -> SubWeapon(Step 16) -> Ring(Step 22) -> Necklace(Step 28)
-
-**소울 비용**: Step 6까지 295, Step 12까지 617, Step 25까지 1427, Step 50까지 3227, 만각성(138) 11509
-
-#### PCUniqueAwakening.json (20 entries = 5 PC x 4 slots)
-PC별 고유 각성 4종. PC6001 기준:
-| Slot | 해금Step | 타입 | 기본값 | LvUp당 | 효과 |
-|------|---------|------|--------|--------|------|
-| 1 | 1 | PC1_UniqueAwakening1 | 0 | +1/+1 | ATK Min, Max 증가 (기본 각성) |
-| 2 | 8 | PC1_UniqueAwakening2 | 10%/0.3 | +0.02/+0.05 | 원거리 회피 2% + 피격 시 반격 5% |
-| 3 | 15 | PC1_UniqueAwakening3 | 20%/0.5 | +0.015/+0.1 | 근접 회피 1.5% + 근접 피격 시 데미지 10% |
-| 4 | 22 | PC1_UniqueAwakening4 | 1%/0.2 | +0.01/+0.05 | 크리티컬 1% + 낙뢰 5% |
-
----
-
-### 1-5. 장비/인장
-
-#### EquipmentList.json (166 entries)
-- e_EquipmentType: Weapon, Glove, Boots, SubWeapon, Ring, Necklace
-- n_Grade: 1~6 (최대 6성)
-- 옵션: n_MainOtion1/2 (메인), n_SubOtion1~4 (서브) -> StatusOptionSet ID 참조
-- n_SubOptionCount: Grade 1=0, Grade 2=1, Grade 3~4=2~3, Grade 5~6=3~4
-
-#### EquipmentSetOption.json (5 sets)
-| Set | 2세트 효과 | 4세트 효과 | 6세트 효과 |
-|-----|-----------|-----------|-----------|
-| 1 | MaxHP_Mul +10% | 카드 1015 부여 | ReduceDmg 15% |
-| 2 | Cri +5% | 카드 1070 부여 | 카드 3002 부여 |
-| 3 | AttackCoolTimeMul +10% | 카드 1010 부여 | 카드 3026 부여 |
-| 4 | 카드 1112 부여 | 카드 1039 부여 | 카드 3039 부여 |
-| 5 | 카드 1065 부여 | AddResurrection +1 | 카드 3011 부여 |
-
-**강화 배율** (n_IncreaseMainStatSet): 2세트=x1, 3=x3, 4=x5, 5=x7, 6=x10
-
-#### EquipmentUpgrade.json (6 entries)
-| Grade | MaxLv | MainStat_Mul | SubStat_Mul | 비용재화 |
-|-------|-------|-------------|------------|---------|
-| 1 | 3 | x2 | x1 | 골드 100+100/lv |
-| 2 | 3 | x4 | x1 | 골드 250+250/lv |
-| 3 | 5 | x6 | x1 | 골드 500+500/lv |
-| 4 | 5 | x8 | x1 | 소울 10+10/lv |
-| 5 | 9 | x10 | x1 | 소울 25+25/lv |
-| 6 | 9 | x12 | x1 | 소울 50+50/lv |
-
-#### SealList.json (60 entries = 12 types x 5 stars)
-인장 12종, 각 1~5성. 이중 효과(Effect1 + Effect2).
-
-| 인장 | 타입 | 원소 | Effect1 (5성) | Effect2 (5성) |
-|------|------|------|--------------|--------------|
-| 20101 | Magic | Dark | MagicMissileDmg +8 | DarkMissileDmg +20% |
-| 20102 | Reaper | Dark | CorpseExplosion +20% | LifeSteal +8 |
-| 20103 | Lightning | Water | ElectricShock +8 | Thunder +20% |
-| 20104 | Flame | Fire | Meteor +50% | Fireball +35% |
-| 20105 | Holy | Light | HolyDamage +5 | ShieldBonus +25% |
-| 20106 | Blade | Earth | RockBlade +35% | ArrowRain +35% |
-| 20107 | Pierce | Wind | DoomRay +50% | PiercingLightning +35% |
-| 20108 | AoE | Water | Blizzard +50% | MysticExplosion +35% |
-| 20109 | Heal | Light | HealBonus +5 | MaxLife +25% |
-| 20110 | Haste | Wind | AttackSpeed +15% | PhantomSpear +35% |
-| 20111 | Critical | Fire | CritChance +5% | CritDamage +25% |
-| 20112 | Sacrifice | Earth | GoldGain +15% | ExpGain +15% |
-
-#### StatusOptionSet.json (984 entries)
-장비/카드/버프의 실제 수치를 정의하는 마스터 테이블. 시뮬레이션에서 장비 효과를 역추적할 때 필수.
-- e_StatusConditionsType: PC_DefaultAttack_Add, Poison, PC_Evasion_All, HitCriticalRate_Add 등
-- e_Stat1/e_Stat2: Attack_Min, Attack_Max, MaxHP, Avoid_Melee 등
-- s_DefaultStatValuePara1/2 + s_UpgradeStatValuePara1/2: 기본값 + 레벨당 증분
-
----
-
-### 1-6. 이벤트/보상 노드
-
-#### BuffPatternConfig.json (20 entries)
-버프/디버프 노드에서 등장하는 효과. 10 버프 + 10 디버프.
-
-| BuffOptionID | 효과 | 유지 | Rate |
-|-------------|------|------|------|
-| 21001 | HP 회복 (1~10 랜덤) | 일회성 | 100 |
-| 21002 | Shield 회복 (1~10 랜덤) | 일회성 | 100 |
-| 21003 | 독 (10s, 1dmg/tick) | 일회성 | 100 |
-| 21004 | 전투 발생 | 일회성 | 100 |
-| 21005 | 최대 HP +10% | 유지 | 100 |
-| 21006 | 최대 HP -10% | 유지 | 100 |
-| 21007 | 최대 Shield +10% | 유지 | 100 |
-| 21008 | 최대 Shield -10% | 유지 | 100 |
-| 21009 | 공격력 +10% | 유지 | 50 |
-| 21010 | 공격력 -10% | 유지 | 50 |
-| 21011 | 회피율 +10% | 유지 | 100 |
-| 21012 | 회피율 -10% | 유지 | 100 |
-| 21013 | 명중률 +10 | 유지 | 100 |
-| 21014 | 명중률 -10 | 유지 | 100 |
-| 21015 | 크리티컬 +10% | 유지 | 100 |
-| 21016 | 크리티컬 -10% | 유지 | 100 |
-| 21017 | 크리 데미지 +30% | 유지 | 100 |
-| 21018 | 크리 데미지 -30% | 유지 | 100 |
-| 21019 | 공격 속도 +15% | 유지 | 100 |
-| 21020 | 공격 속도 -15% | 유지 | 100 |
-
-공격력 버프/디버프만 Rate=50 (반 확률), 나머지 100.
-
-#### SanctuaryConfig.json (12 entries)
-성소 9종 + 샘 3종.
-
-**성소 (각성으로 해금)**:
-| 타입 | 효과 | 해금 Step |
-|------|------|----------|
-| Sanctuary_Heal | HP/Shield 전체 회복 | 5 |
-| Sanctuary_LvUp | 레벨업 +1 | 15 |
-| Sanctuary_Resurrection | 부활 추가 (HP/Shield 20% 회복) | 25 |
-| Sanctuary_Skill | 스킬 카드 랜덤 1장 획득 | 35 |
-| Sanctuary_Knowledge | EXP 획득량 x2 버프 | 45 |
-| Sanctuary_Money | 골드 획득량 x2 버프 | 54 |
-| Sanctuary_Soul | 소울 +10 | 64 |
-| Sanctuary_Gold | 골드 +25 | 73 |
-| Sanctuary_Immune | 무적 10초 | 83 |
-
-**샘 (항상 등장, Mine 노드)** - 동일 가중치(100):
-| 타입 | 효과 |
-|------|------|
-| Spring_Heal | HP 1~10 랜덤 회복 |
-| Spring_Exp | EXP +15 |
-| Spring_Shield | Shield 1~10 랜덤 회복 |
-
-#### TreasureBoxConfig.json (25 entries)
-보물상자 5등급, 각 5개 변형(잠금률 0~40%, 미믹률 0~1%).
-- 등급 1~5 보상: RewardRandomBag ID 91001~91005 참조
-- 미믹 전투 몬스터: 20001~20005
-
-#### MerchantConfig.json (72 entries)
-상인 노드. Good/Bad 타입, Grade 1~2.
-- 판매가 할인: f_MerchantSaleMin=30%, f_MerchantSaleMax=70%
-- 훔치기 보너스: n_StealBonus 10~27
-- 판매 아이템 풀: n_ProductItemID -> RewardRandomBag
-
-#### NPCConfig.json (109 entries)
-NPC 이벤트 노드. Good 타입, Grade 1~2.
-- 요청 아이템(n_NPCRequestItemID=99999) -> 보상(n_NPCRewardID=98888)
-- 훔치기 보너스: n_StealBonus 10~27
-
----
-
-### 1-7. 재화/경제
-
-#### ItemList.json (225 entries)
-| ID | 이름 | 타입 | 비고 |
-|----|------|------|------|
-| 101 | 캐시 | Goods | 프리미엄 재화 |
-| 201 | 골드 | Goods | 기본 재화 |
-| 301 | 소울 | Goods | 각성/장비 재화 |
-| 401 | 회복 포션 | Goods | 골드 1000으로 구매 |
-| 501 | 경험치 | Goods | |
-| 601~603 | 진화석 | Goods | PC별 |
-| 3010101+ | 장비 | Equipment | |
-
-#### RewardRandomBag.json (1342 entries)
-보상 풀 마스터. n_DropIndex별로 아이템 드랍률+수량 정의.
-- 91001(보물상자 G1): 골드 10~1000 (가중치 기반) + 장비 G1 (300 rate each)
-- 각 DropIndex가 ItemID + DropRate + DropCountMin/Max 조합
-
----
-
-## 2. PC6001 기준 성장 곡선
-
-### 기본 스탯 (Lv1, 1성, 각성 0)
-- ATK: 1~4 | CT: 2.4s | Cri: 2.6% | CriDmg: 150%
-- HP: 58 | Shield: 6 | Avoid: 5%/5%
-
-### 진화 6성 도달 시 (각성 0)
-- ATK: 1+15=16 ~ 4+15=19 | HitRate: +8
-- HP: 58+30=88 | Shield: 6+15=21
-
-### 각성 Step 6 (초기 각성)
-- ATK_Max: +5 -> 24 | HP: +9 -> 97 | Shield: +9 -> 30
-- 해금: LvUpHeal(Lv업 시 HP+1), CampHeal_Add(캠프 HP+6)
-- 소울 비용: 295
-
-### 각성 Step 12 (초중반)
-- 추가: CriDmg +0.25(25%), Avoid_M +0.5%, Avoid_R +0.5%, Cri +0.5%
-- 해금: CampHeal +3
-- 소울 누적: 617
-
-### 각성 Step 25 (중반)
-- ATK_Min: +5, HitRate: +5, AttackCoolTimeMul: +5%
-- HP: +18 -> 106 | Shield: +18 -> 39
-- 해금: Sanctuary_Resurrection, 장비 5슬롯 전부 오픈
-- 소울 누적: 1427
-
-### 만각성 (Step 138) - 참고용
-- 수치가 Step 39 이후부터 "%"가 포함된 값이 혼재(예: MaxHP "500%")
-- **주의**: 고스텝 각성 노드의 s_Value에 "%"가 붙은 항목은 절대값이 아닌 배율 증가로 해석해야 함
-- 실제 시뮬레이션에서는 Step 25~50 범위가 현실적인 플레이 범위
-
----
-
-## 3. 카드 효과 분류표 (G1 112장 기준)
-
-### 시뮬레이션용 카테고리 분류
-
-#### A. 힐/생존 카드 (36장, 32.1%)
-| 서브 카테고리 | 수 | 대표 카드 | 평균 val1 |
-|-------------|-----|----------|----------|
-| 직접 힐 (HP 회복) | 18 | HealOnLevelUp(7), HealOnBackKill(5), FirstAttackHeals(5) | ~4.5 HP |
-| 포션 관련 | 5 | AddPotion(+1), CampRechargePotion(+1), CampFillEmptyPotion(+1) | - |
-| 라이프스틸 | 4 | LifeStealOnDodge(2), LifeStealOnBackAttack(3) | ~2.5 HP |
-| Shield 회복 | 6 | LevelUpRecoverShield(5), KillCountRecoverFullShield(10) | ~6 Shield |
-| 풀힐/조건부 | 3 | InstantFullHeal, FullRecoverAtFountain | - |
-
-#### B. 보호막/방어 카드 (11장, 9.8%)
-| 서브 카테고리 | 수 | 대표 카드 | 평균 val1 |
-|-------------|-----|----------|----------|
-| Shield 증가 | 4 | MaxShieldUpOnSkillGain(+4), MaxShieldUpOnLevelUp(+4) | +4 Shield |
-| Shield 복구 | 4 | ShieldOnRangedDodge(6), MissRestoreShield(9) | ~6 Shield |
-| 특수 방어 | 3 | NoSimultaneousHpShieldLoss, FullShieldIfHpLowAndShieldZero | - |
-
-#### C. MaxHP/MaxShield 영구 증가 (2장, 1.8%)
-| 카드 | val1 | LvUp당 |
-|------|------|--------|
-| MaxHpPlusOnFountain | +2 | +1/lv |
-| MaxHpUpOnLevelUp | +4 | +1/lv |
-
-#### D. 데미지 직접 기여 (24장, 21.4%)
-| 서브 카테고리 | 수 | 대표 카드 | 평균 기여 |
-|-------------|-----|----------|----------|
-| ATK 증가 | 2 | AddMaxAttack(+2), AddMinAttack(+1) | +1.5 ATK |
-| 투사체/광역 | 8 | FireMagicMissiles(4발), MagicMissile(4발) | 4발 투사체 |
-| 조건부 대미지 | 8 | FirstAttack(300%), ThirdCritDamage(300%) | ~200% 보너스 |
-| 성스러운 피해 | 6 | HolyDamageOnMeleeHit(1), EnemySpawnHolyDamage(1) | ~2 Holy |
-
-#### E. 회피/생존 패시브 (14장, 12.5%)
-| 서브 카테고리 | 수 | 대표 카드 |
-|-------------|-----|----------|
-| 회피 트리거 | 6 | DodgeNextNAttacks(7), MaxDodgeWhenHpBelow |
-| 회피 시 반격 | 5 | ReflectOnRangedDodge, LightningToBackOnMeleeDodge |
-| Miss 기반 | 3 | MissCastLightning, MissHolyDamage |
-
-#### F. 크리티컬 (4장, 3.6%)
-| 카드 | 효과 |
-|------|------|
-| AddCriDmg | CriDmg +100% |
-| ThirdCritDamage | 3번째 크리 시 300% 추가 |
-| XpGainOnCritKill | 크리킬 시 경험치 150% |
-| CastReaperOnNthCrit | 10번째 크리 시 사신 소환 |
-
-#### G. CC/상태이상 (7장, 6.3%)
-| 카드 | 효과 |
-|------|------|
-| StunAllEnemiesOnLevelUp | 레벨업 시 전체 스턴 6s |
-| StunAllMeleeEnemies | 전체 근접 스턴 |
-| CurseEnemiesOnBattlefield | 저주 2 스택 |
-| EnemySpawnStunChance | 등장 시 20% 스턴 8.5s |
-
-#### H. 캠프/이벤트 강화 (6장, 5.4%)
-- GainGoldOnSanctuaryFind(+10), ShockDamageOnGoldDrop(+8)
-- FountainGivesXp(+5exp), GoldDropChanceUp(+30%)
-- LevelUpOnCampFind, LootChestGivesHealAndXp
-
-#### I. 유틸리티/기타 (8장, 7.1%)
-- AddHitRate(+5), InstantSkillReroll, NextLevelGainHeroOrLegendSkill
-- ElectricShockOnConsecutiveHits, ThunderOnFifthHit
-
-### DPS 기여도 요약
-평균 G1 카드 1장의 전투 기여도 (전투당 기대값 추정):
-- 힐 카드: **~4 HP 회복/전투** (생존 기여)
-- DPS 카드: **~2~4 추가 대미지/전투** (직접 DPS)
-- Shield 카드: **~5 Shield 보전** (간접 생존)
-- CC 카드: **3~6초 적 행동 봉쇄** (간접 DPS)
-
----
-
-## 4. 비전투 노드 효과
-
-### 캠프파이어 (f_CampFire = 16.2 가중치)
-- 기본: HP +5, Gold +10, EXP +5 (GlobalValue)
-- 각성 CampHeal: +3(Step12), CampHeal_Add: +6(Step6 maxLv)
-- **각성 0 기준 캠프 1회**: HP 5 회복, EXP 5, 골드 10
-- **각성 Step 12 기준**: HP 14 회복, EXP 5, 골드 10+
-
-### 성소/샘 (Mine 노드, f_Mine = 5 가중치)
-**샘 (해금 불필요, 항상 등장)**:
-- HP 1~10 랜덤 / EXP +15 / Shield 1~10 랜덤 (1/3 확률)
-- 기대값: HP ~3.7 또는 EXP 15 또는 Shield ~3.7
-
-**성소 (각성 해금 필요)**:
-- Sanctuary_Heal(Step 5): 전체 회복 - 생존력 최대 기여
-- Sanctuary_LvUp(Step 15): 레벨업 +1 - DPS/생존 양쪽 기여
-- Sanctuary_Resurrection(Step 25): 부활 추가 - 런 안정성 급상승
-- 이후 성소: 경제/유틸리티 위주
-
-### 버프/디버프 노드 (f_BuffDebuff = 2.3 가중치)
-- 10 버프 + 10 디버프, 동일 가중치 (공격력만 50:50)
-- **기대값: 50% 확률로 버프 획득**
-- 유지형 버프: MaxHP/Shield +/-10%, Avoid +/-10%, Cri +/-10%, CriDmg +/-30%, AtkSpd +/-15%
-- 일회성: HP/Shield 1~10 회복, 독(10s), 전투 발생
-
-### 보물상자 (f_Treasure = 1.5 가중치)
-- 잠금률 0~40% (등급별), 미믹률 0~1%
-- 보상: 골드 10~1000(가중치), 장비 드랍
-
-### 상인 (f_Merchant = 1 가중치)
-- 할인 30~70%
-- 판매 품목: RewardRandomBag 기반
-
-### NPC (f_NPC = 3 가중치)
-- 아이템 교환 구조 (요청 -> 보상)
-- 훔치기 가능 (보너스 10~27)
-
----
-
-## 5. 빠진 데이터 목록
-
-### GlobalValue에 없는 키
-1. **PCDefence / PCDefence_Mul** - 존재하지 않음. 방어력/데미지 감소 공식이 GlobalValue에 정의되어 있지 않다.
-2. **DamageFormula 관련 키** - 데미지 계산 공식(ATK - DEF, 또는 배율 기반)의 정의가 없음. 코드에서만 확인 가능.
-3. **ShieldAbsorb_Rate** - 보호막이 데미지의 몇 %를 흡수하는지 정의 없음.
-4. **HitRate_Formula** - 명중률 계산 공식 (HitRate vs Avoid 관계) 정의 없음.
-5. **Cri_Formula** - 크리티컬 확률 계산 공식 정의 없음.
-6. **PotionHeal_Base** - 포션 기본 회복량 정의 없음 (코드 하드코딩 추정).
-7. **MonsterEXP_Base** - 몬스터별 EXP 드랍량. MonsterList에 n_RewardExp 필드 있으나 실제 수치 확인 필요.
-8. **MonsterGold_Formula** - 몬스터별 골드 드랍(f_GoldDropRate + s_RewardGold).
-9. **BattleLevelUp 보상** - 레벨업 시 HP 회복량, 카드 선택 수 등이 테이블에 없음.
-10. **MaxPotion_Default** - PC 기본 포션 수. PCList에 없고, 코드에서만 확인 가능.
-
-### 코드에서만 확인 가능한 수치
-1. **데미지 공식**: ATK(Min~Max 랜덤) -> 크리티컬 판정 -> 명중/회피 판정 -> Shield 흡수 -> HP 피해. 각 단계의 정확한 계산식은 코드 확인 필요.
-2. **Shield 메커니즘**: Shield가 HP보다 먼저 소모되는지, 동시에 깎이는지 (G1_NoSimultaneousHpShieldLoss 카드로 보아 기본은 동시 소모 추정).
-3. **HitRate - Avoid 공식**: HitRate가 절대값(정수), Avoid가 소수점(%)인 것으로 보아 별도 공식 존재 추정.
-4. **투사체 피해 공식**: 카드/인장의 투사체가 ATK 기반인지 독립 고정 피해인지 불명.
-5. **카드 레벨업 조건**: 인게임 레벨업 시 카드 선택 로직 (3장 중 1장? 확률?).
-6. **인게임 레벨업 시 스탯 보너스**: BattleLevelUp.json에 EXP 테이블만 있고, 레벨당 ATK/HP 증가치가 없음. 코드에서 확인 필요.
-7. **전투 타이머**: 전투 제한 시간 존재 여부.
-8. **거대화 메커니즘**: DeathGrowUp_Rate(0.2) / DeathGrowUp_RateMax(2) - 죽은 적이 커지는 시스템의 정확한 작동 방식.
-
-### 테이블 간 연결 관계 (누락 가능성)
-1. **StatusOptionSet -> 장비 옵션 ID**: EquipmentList의 n_MainOtion1/2, n_SubOtion1~4 값이 StatusOptionSet의 n_StatusID와 매핑. 장비별 실제 수치는 StatusOptionSet에서 역추적해야 함.
-2. **RewardRandomBag -> 실제 보상**: NPCConfig(98888), MerchantConfig(90000~93000), TreasureBoxConfig(91001~91005) 등의 보상 풀이 RewardRandomBag에 정의됨.
-3. **PCSpecificity.json**: 파일이 존재하나 분석 미포함. PC별 특성 정의 가능성.
-4. **StatusConditionsList.json**: 상태이상 조건 목록. 시뮬레이션에서 CC 효과 정확도에 필요.
-5. **WorldMapConfig.json**: 월드맵 구성. 스테이지 진행 순서/해금 조건.
-
-### 시뮬레이션에 필요하지만 테이블에 없는 핵심 파라미터
-| 파라미터 | 필요 이유 | 추정 소스 |
-|---------|----------|----------|
-| 기본 포션 수/회복량 | 생존 시뮬 기초 | 코드 |
-| 데미지 공식 | DPS 계산 기초 | 코드 |
-| Shield 우선 흡수 비율 | 실효 HP 계산 | 코드 |
-| 인게임 레벨업 스탯 보너스 | 런 중반 전투력 | 코드 |
-| 카드 선택 장 수 | 빌드 확률 | 코드 |
-| 전투 시 몬스터 등장 간격 | DPS 레이스 타이밍 | 코드+MonsterPatternList |
-| 원소 상성 배율 | 6003 Wind>Light>Earth | 코드 |
-
----
-
-## 부록: 핵심 파일 경로
-
-```
-D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/
-  PCList.json              - PC 기본 스탯 (5)
-  MonsterList.json         - 몬스터 스탯 (248)
-  GlobalValue.json         - 전역변수 (22)
-  CreateMapConfig.json     - 스테이지 맵 설정 (123)
-  RandomPatternConfig.json - 랜덤 노드 비율 (30)
-  MonsterPatternList.json  - 몬스터 배치 패턴 (101)
-  ApprearMonsterPattern.json - 몬스터 등장 그룹 (753)
-  CardList.json            - 카드 전체 (311)
-  BattleLevelUp.json       - 인게임 레벨 곡선 (20)
-  PCLevelUp.json           - 아웃게임 레벨 곡선 (20)
-  PCEvolution.json         - 진화 스탯 (30)
-  PCEvolutionMax.json      - 최대 진화 랜덤 (9)
-  PCAwakening.json         - 각성 트리 (1225)
-  PCUniqueAwakening.json   - 고유 각성 (20)
-  EquipmentList.json       - 장비 (166)
-  EquipmentSetOption.json  - 세트 효과 (5)
-  EquipmentUpgrade.json    - 장비 강화 (6)
-  SealList.json            - 인장 (60)
-  StatusOptionSet.json     - 상태 효과 수치 (984)
-  BuffPatternConfig.json   - 버프/디버프 노드 (20)
-  SanctuaryConfig.json     - 성소/샘 (12)
-  TreasureBoxConfig.json   - 보물상자 (25)
-  MerchantConfig.json      - 상인 (72)
-  NPCConfig.json           - NPC 이벤트 (109)
-  ItemList.json            - 아이템/재화 (225)
-  RewardRandomBag.json     - 보상 풀 (1342)
-```
-
----
-
-## 변경 이력 (P16 산출물 추적성)
-
-> **표준 포맷 (2026-04-17 도입)**: 밸런싱 관련 문서 4종 공통 적용. 본 문서의 테이블 감사 결과·Export 목록·스탯 범위 판정이 변경될 때마다 아래 테이블에 1행 append.
-> **필드 설명**: 변경 필드 = 어떤 테이블·감사 항목인가 / 이전값→이후값 = 구체 감사 결과 변화 / 재미 근거 = C7 원칙에 따른 재미 강화 축 / 관련 PD 지시# = `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`의 해당 #
-
-| 일시 | 변경자 | 변경 필드 | 이전값→이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|---------|-------------|----------|-------------|
-| 2026-04-17 | 기획팀장 | 변경 이력 테이블 섹션 신설 | - → 기존 상태 확정 | 산출물 추적성 확보 (P16), 테이블 구조 변경 추적 가능 | 본 작업 (팀장 재량 진행 승인) |
diff --git a/프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md b/프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md
deleted file mode 100644
index 0072a77..0000000
--- a/프로젝트/수상한잡화점/기획/카드시너지축분석_v1.md
+++ /dev/null
@@ -1,209 +0,0 @@
-# 카드 시너지 축 분석 v1
-
-> 분석 대상: `DeckBuilding.xlsm` → `CardList` (311장, G1~G5)
-> 분석 일자: 2026-04-13
-> 담당: balance + content + system (팀장 통합)
-
----
-
-## 1. 분석 요약
-
-311장의 카드를 **효과 키워드 기반**으로 태깅한 결과, **10개의 주요 시너지 축(빌드 아키타입)**이 식별됐습니다.
-
-### 핵심 발견
-1. **빌드 아키타입이 10개로 다양** — Balatro류 "조합 발견의 재미"를 지탱하기에 충분한 다양성
-2. **공격력(102장)이 압도적으로 많아** 거의 모든 빌드에 공격력 카드가 섞임 — 이건 장점(접착제 역할)이자 약점(개성 희석)
-3. **치명타·물약·기절 빌드는 G4~G5에 편중** — 초반(G1)에서 이 빌드를 시작하기 어려움
-4. **태그 미분류 6장** — 고아 카드(시너지 없는 단독)가 매우 적어 전체 설계 완성도 높음
-5. **"처치 시" 연쇄 빌드(시체폭발+암흑+경험치)**가 데이터상 가장 시너지가 뚜렷 — Balatro류 "폭발" 쾌감의 핵심 후보
-
----
-
-## 2. 시너지 축 (빌드 아키타입) 10개
-
-### 축 1: 🗡️ 신성 폭격 빌드 (Holy Damage)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 공격력 + 신성 + 후열타격 |
-| 카드 수 | 23장 (신성) + 연관 공격력 카드 |
-| 동시 출현 | **공격력+신성: 21쌍** (전체 1위) / 신성+후열타격: 7쌍 |
-| 등급 분포 | G1:11, G2:9 → **초반부터 빌드 시작 가능** |
-| 빌드 컨셉 | 적 등장·회피·처치 등 다양한 트리거로 신성 피해 발동. 후열 관통과 조합 시 폭발적 |
-| 대표 카드 | `G1_HolyDamageOnMeleeFrontAppear`, `G1_HolyDamageToBackEnemiesOnDodge` |
-
-### 축 2: 🛡️ 보호막-생존 빌드 (Shield/Sustain)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 보호막 + 회복 + 흡혈 |
-| 카드 수 | 53장 (보호막) + 58장 (회복) |
-| 동시 출현 | **보호막+회복: 17쌍** (3위) / 회복+흡혈: 5쌍 |
-| 등급 분포 | G1:22(보호막), G1:31(회복) → **초반부터 빌드 가능** |
-| 빌드 컨셉 | 보호막 유지 + 체력 회복으로 안정적 생존. ★2·★3 달성의 핵심 빌드 |
-| 대표 카드 | `G1_NoSimultaneousHpShieldLoss`, `G1_HealOnDoubleDodge` |
-
-### 축 3: 💀 처치 연쇄 빌드 (On-Kill Chain)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 처치시 + 시체폭발 + 암흑/저주 + 경험치 |
-| 카드 수 | 57장 (처치시) — **두 번째로 많은 태그** |
-| 동시 출현 | 처치시+경험치:9 / 시체폭발+처치시:8 / 암흑+처치시:7 / 경험치+시체폭발:6 |
-| 등급 분포 | 전 등급에 고르게 분포 (G1:16, G4:10) |
-| 빌드 컨셉 | **적 처치 → 시체 폭발 → 추가 처치 → 더 많은 경험치 → 빠른 레벨업 → 더 많은 카드** — 연쇄 폭발의 핵심. Balatro류 "빌드 터지는 맛"의 최적 후보 |
-| 대표 카드 | `G1_CurseExplosionOnKill`, `G1_XpGainOnCritKill` |
-
-### 축 4: ⚡ 치명타 빌드 (Critical)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 치명타 + 공격력 |
-| 카드 수 | 38장 |
-| 동시 출현 | 공격력+치명타:11 / 보호막+치명타:6 |
-| 등급 분포 | **G4:11, G5:8** → ⚠️ 고등급 편중. 초반에 빌드 시작 어려움 (G1:5장뿐) |
-| 빌드 컨셉 | 치명타 확률·피해량 강화 → 한 방 딜 극대화 |
-| 대표 카드 | `G1_AddCriDmg`, `G5_CritKillAllDamage` |
-
-### 축 5: 🏹 원거리-회피 빌드 (Ranged+Dodge)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 원거리 + 회피 + 반사 |
-| 카드 수 | 35장 (원거리) + 30장 (회피) |
-| 동시 출현 | 원거리+회피:8 / 근접+회피:5 |
-| 등급 분포 | 고르게 분포 |
-| 빌드 컨셉 | 원거리 공격으로 안전하게 딜 + 회피로 생존. 회피 발동 시 추가 효과(반사, 흡혈, 신성 피해) |
-| 대표 카드 | `G1_ReflectOnRangedDodge`, `G1_LifeStealOnDodge` |
-
-### 축 6: 🧪 물약 특화 빌드 (Potion)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 물약 |
-| 카드 수 | 25장 |
-| 등급 분포 | **G5:7장** → ⚠️ 고등급 편중 |
-| 빌드 컨셉 | 물약 보유량 증가 + 물약 사용 시 추가 효과(암흑 미사일, 치유 강화 등) |
-| 대표 카드 | `G1_DarkMissileFromPotion`, `G1_AddPotion` |
-| 주의 | ★2 조건이 "물약 미사용"이라 **물약 빌드가 ★2와 직접 충돌**. 이건 의도된 트레이드오프인지 확인 필요 |
-
-### 축 7: 🔥 첫타 버스트 빌드 (First Strike)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 첫타 + 공격력 |
-| 카드 수 | 19장 |
-| 동시 출현 | 공격력+첫타:15 |
-| 등급 분포 | G1:8 → 초반 가능 |
-| 빌드 컨셉 | 전투 시작 시 첫 공격에 폭발적 보너스. 빠른 처치로 노드 시간 단축 |
-| 대표 카드 | `G1_FirstAttack` (첫 공격 +300% 피해) |
-
-### 축 8: ⚡ 번개 빌드 (Lightning/Electric)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 번개 + 기절 |
-| 카드 수 | 16장 (번개) + 13장 (기절) |
-| 등급 분포 | 번개 G1:8 / 기절 **G5:4** → 기절은 고등급 편중 |
-| 빌드 컨셉 | 연속 공격 시 감전·번개 발동 + 기절로 CC(군중 제어) |
-| 대표 카드 | `G1_ElectricShockOnConsecutiveHits`, `G1_ThunderOnFifthHit` |
-
-### 축 9: 🏕️ 탐험-경제 빌드 (Camp/Gold/Exp)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 캠프 + 골드 + 경험치 + 레벨업 |
-| 카드 수 | 14장 (캠프) + 5장 (골드) + 17장 (경험치) + 16장 (레벨업) |
-| 등급 분포 | **G1 편중** (캠프 G1:9, 골드 G1:4, 경험치 G1:9) |
-| 빌드 컨셉 | 탐험 이벤트·캠프 보너스 강화, 골드·경험치 추가 획득. 전투력보다 성장 속도에 투자 |
-| 대표 카드 | `G1_SanctuaryHeal` (성소 효과+경험치 200%↑) |
-
-### 축 10: 🔮 미사일 빌드 (Magic Missile)
-| 항목 | 내용 |
-|---|---|
-| 핵심 태그 | 미사일 |
-| 카드 수 | 11장 |
-| 등급 분포 | G1:5 |
-| 빌드 컨셉 | 주기적으로 자동 발사되는 미사일로 패시브 딜. 물약·신성과 조합 가능 |
-| 대표 카드 | `G1_MagicMissile` (매 8초 매직미사일 3발) |
-
----
-
-## 3. 시너지 매트릭스 (축 간 연결)
-
-아래 표는 "이 두 축을 동시에 추구하면 시너지가 있는가"를 나타냅니다.
-
-| | 신성 | 생존 | 처치연쇄 | 치명타 | 원거리회피 | 물약 | 첫타 | 번개 | 탐험경제 | 미사일 |
-|---|---|---|---|---|---|---|---|---|---|---|
-| **신성** | — | △ | ◯ | △ | ◯ | △ | △ | △ | × | ◯ |
-| **생존** | | — | △ | ◯ | ◯ | ◯ | × | △ | △ | × |
-| **처치연쇄** | | | — | ◯ | △ | × | ◯ | △ | ◯ | △ |
-| **치명타** | | | | — | △ | × | ◯ | △ | △ | × |
-| **원거리회피** | | | | | — | × | △ | △ | × | △ |
-| **물약** | | | | | | — | × | × | △ | ◯ |
-| **첫타** | | | | | | | — | △ | × | × |
-| **번개** | | | | | | | | — | × | △ |
-| **탐험경제** | | | | | | | | | — | × |
-| **미사일** | | | | | | | | | | — |
-
-◯ = 강한 시너지 / △ = 부분 시너지 / × = 시너지 약함·무관
-
----
-
-## 4. 문제점 & 밸런싱 제안
-
-### 🔴 이슈 1: 치명타 빌드의 G1 부족
-| 항목 | 현재 값 | 제안 방향 | 근거 |
-|---|---|---|---|
-| G1 치명타 카드 | **5장** | 8~10장으로 확대 | 치명타는 핵심 빌드인데 초반 드래프트에서 축을 시작할 수 없음. G1:112장 중 5장=4.5%로 너무 희소. Balatro류 게임에서 **빌드 시작 시그널은 초반에 와야** 함 |
-| 영향 | | 무과금: 초반부터 치명타 빌드 경험 가능 / 고과금: 영향 없음 | |
-
-### 🔴 이슈 2: 물약 빌드 ↔ ★2 조건 충돌
-| 항목 | 현재 값 | 제안 방향 | 근거 |
-|---|---|---|---|
-| ★2 조건 | 물약 미사용 | 물약 빌드를 선택한 유저에게 별도 보상 경로, 또는 "물약 N개 이하" 완화 조건 검토 | 물약 빌드(25장)를 추구하면 ★2를 포기해야 하는 구조. 의도된 트레이드오프일 수 있지만, **25장이나 되는 빌드 축이 ★2와 상충**하면 유저 체감상 "물약 카드 = 함정"이 될 위험. **사용자 확인 필요** |
-
-### 🟡 이슈 3: 기절(CC) 빌드의 G5 편중
-| 항목 | 현재 값 | 제안 방향 | 근거 |
-|---|---|---|---|
-| G1~G3 기절 카드 | G1:4, G2:0, G3:4 | G2에 기절 카드 2~3장 추가 | G2가 0장이라 등급 상승 과정에서 기절 빌드가 "끊기는" 구간 발생. 연속적인 빌드 경험을 위해 G2 보강 필요 |
-
-### 🟡 이슈 4: 탐험-경제 빌드의 전투력 기여 부재
-| 항목 | 현재 값 | 제안 방향 | 근거 |
-|---|---|---|---|
-| 캠프·골드·경험치 카드 | 대부분 전투력 기여 없음 | 탐험 빌드 카드 중 일부에 "누적 골드/경험치 비례 전투 보너스" 효과 추가 검토 | 현재 탐험 빌드를 추구하면 전투력이 약해져 노드 클리어 시간 증가. 이 빌드가 "빠르게 레벨업 → 더 많은 카드 선택"이라는 간접 전투력 보상을 줄 수 있지만, 체감이 약할 수 있음 |
-
-### 🟢 관찰: 공격력 태그(102장)의 "접착제" 역할
-공격력 태그가 전체의 33%를 차지하며 거의 모든 축과 동시 출현합니다. 이는 **의도된 설계**로 보입니다 — 드래프트에서 어떤 빌드를 추구하든 공격력 카드가 자주 나와 "밑바닥 전투력"을 보장하는 구조. 이걸 건드리면 전체 밸런스가 흔들리므로 현 비율을 유지하는 게 좋겠습니다.
-
----
-
-## 5. 빌드 튜닝 방법론 제안
-
-사용자님이 "튜닝할 방법을 제시해줘"라고 하셨으므로, 카드 밸런싱을 진행하기 위한 **단계별 절차**를 제안합니다.
-
-### Step 1: 빌드 아키타입 목표 수립
-위 10개 축 중 **런칭 시점에 의도하는 빌드 아키타입이 몇 개인지** 확정.
-- 10개 전부? 상위 5개만? → 아키타입 수가 드래프트 풀 설계의 기반.
-- 각 아키타입의 **상대적 강도 목표** 설정 (예: 처치연쇄가 가장 폭발적, 생존 빌드가 가장 안정적)
-
-### Step 2: 드래프트 풀 시뮬레이션
-`BattleLevelUp` 곡선(20레벨, 최대 19회 선택) 기준으로:
-- 한 런에서 **특정 빌드에 필요한 카드를 몇 장이나 모을 수 있는지** 확률 계산
-- G1~G5 등장 가중치(현재 미확인)에 따라 결과가 크게 달라짐
-- → **"드래프트 시 등급별 등장 가중치"** 데이터가 필요합니다 (사용자에게 확인 필요)
-
-### Step 3: 노드당 TTK 시뮬레이션
-빌드별로 "이 카드 조합이 완성됐을 때 노드당 클리어 시간"을 추정:
-- `MonsterList` 스탯 + `PCList` 기본 스탯 + 카드 효과 합산 → 예상 DPS 산출
-- 목표: 노드당 ≤1분 (전투+이동 기준)
-
-### Step 4: 난이도 계층별 밸런스 확인
-쉬움/보통/어려움에서 각 빌드의 생존력·화력이 목표와 맞는지:
-- 쉬움: 아무 빌드나 ★1 가능
-- 보통: 축이 잡힌 빌드여야 ★1 안정, 잘 잡힌 빌드면 ★2~★3
-- 어려움: 최적 빌드 + 스펙업이 있어야 ★1 가능
-
-### Step 5: 플레이 테스트 & 반복
-- Step 2~4의 수치 시뮬레이션 후, 실제 플레이로 "체감이 맞는지" 검증
-- 기획팀은 시뮬레이션, 사용자는 플레이 → 결과를 맞춰보며 조정
-
----
-
-## 6. 다음 단계를 위해 사용자에게 확인이 필요한 사항
-
-1. **드래프트 시 카드 등급별 등장 가중치**는 어디에 정의돼 있나요? (G1이 나올 확률 vs G5가 나올 확률)
-2. **물약 빌드 ↔ ★2 조건 충돌**은 의도된 트레이드오프인가요?
-3. **10개 빌드 아키타입 중 런칭 시 의도한 것**은 몇 개인가요? 전부인가요?
-4. **카드 효과의 수치(s_Value1~3)를 조정**하는 것도 기획팀이 제안해도 되는 범위인가요?
diff --git a/프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md b/프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md
deleted file mode 100644
index 77cfbb2..0000000
--- a/프로젝트/수상한잡화점/기획/테이블_데이터_구조_재정비_v1.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-type: 테이블 데이터 구조 재정비 (수상한잡화점)
-작성일: 2026-04-20
-작성자: 기획팀장 (PM 경유 PD 재발 방지 지시 #42 수용)
-관련PD지시: 기획팀 #42 · PD 2026-04-20 "게임 내 테이블 데이터 구조 재확인 + 누락 정보 보완"
-상태: **v1 초안 · PD 검증 선행**
-근거: Unity Export 실측 (D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/)
----
-
-# 수상한잡화점 — 테이블 데이터 구조 재정비 v1
-
-## §0. 본 문서의 목적
-
-2026-04-20 PD 재발 방지 지시 5종 중 #42 "게임 내 테이블 데이터 구조 재확인 + 누락 정보 보완" 이행. **기존 기획팀이 "WorldMap 4개 그룹" 같이 추측·전제로 데이터 구조를 오해한 사건**을 계기로 Unity Export CSV/JSON 전수 실측 기반 구조 재정비.
-
-**본 문서는 재발 방지 + 추후 모든 기획 작업의 1차 데이터 참조 SOT**다.
-
----
-
-## §1. PD 용어 정의 확정 (SOT)
-
-| 용어 | 정의 | 데이터 출처 | 총 개수 |
-|------|------|------------|---------|
-| **월드맵** | 게임 세계 전체 맵 | `WorldMapConfig` | 1개 |
-| **구역 / 지역** | 월드맵 내 각 지역 (= Stage) | `WorldMapConfig.n_StageID` 1~21 | **21개** |
-| **스테이지** | 지역 내 각 맵 (= MapConfig) | `CreateMapConfig.s_MapConfigID` | **122개** |
-| **서브맵** | 스테이지 내 노드 (전투·이벤트·이동 등) | 런타임 생성 (RandomPatternConfig 기반) | 스테이지마다 가변 |
-
-### §1-1. 용어 혼선 주의
-- **구 기획팀 용어 "WorldMap"** = 실제로는 **일부 스테이지 묶음의 배경 테마**에 불과 (`WorldMapConfig.s_StageBg` = map_01~map_10 재활용)
-- **"WM1~WM4 그룹"은 실측 무근 · 기획팀 추정이었음** — 본 v1 문서 이후 사용 금지
-- **PD 지시 용어 엄수**: 월드맵·구역/지역·스테이지 3층 명칭만 사용
-
----
-
-## §2. WorldMapConfig 구조
-
-### §2-1. 필드 정의 (실측)
-
-| 필드 | 타입 | 의미 |
-|------|------|------|
-| `n_StageID` | int (1~21) | 월드맵 장소(=지역) 고유 ID |
-| `n_StageName` | 참조 (localization) | UI 표기용 명칭 |
-| `s_StageDiorama` | string (공란) | 월드맵 배치 디오라마 이미지 |
-| `s_StageBg` | string | UI 사용 BG 이미지 (map_01~map_10 재활용) |
-| `s_StageBGM` | string (공란) | 스테이지 BGM |
-| `n_ExtraRandombag` | int | 이벤트 추가 전리품 랜덤백 ID |
-
-### §2-2. 실측 내용
-
-21개 지역. Stage 1~21. 배경 이미지(`s_StageBg`)는 map_01~map_10이 반복 사용됨.
-
-### §2-3. 기획 의도 재확인
-- **각 지역은 독립적 세계관 공간** (지역 1 = 첫 입문 지역, 지역 21 = 최종 지역)
-- 지역별 배경 테마는 10종 순환 사용 (디자인 리소스 최적화)
-- 기획 시 **"WorldMap 4개 그룹"은 실존하지 않음** — 21개 지역을 난이도 곡선 상 **입문/초반/중반/후반**으로 나누는 **기획적 구분**은 가능하나, 이는 **데이터 구조가 아닌 기획 레이블**
-
----
-
-## §3. CreateMapConfig 구조
-
-### §3-1. 필드 정의 (실측 41개 필드)
-
-#### 식별자 + 매핑
-| 필드 | 의미 |
-|------|------|
-| `s_MapConfigID` | 맵 고유 ID (형식: `Stage{지역번호}_{순번}`, 예: `Stage1_1`·`Stage1_4`) |
-| `n_StageType` | 지역 번호 (1~21), WorldMapConfig.n_StageID 참조 |
-| `n_AppearMonsterGroup` | 일반 몬스터 그룹 ID → `ApprearMonsterPattern.n_AppearMonserGroup` 참조 |
-| `n_AppearBossGroup` | 보스 몬스터 ID (0 = 보스 없음) → `MonsterList.n_ID` 참조 |
-
-#### 노드 확률 체계 (10종 노드 타입)
-
-각 노드 타입은 **4필드 세트**(확률·최소·최대·Data Border):
-
-| 노드 타입 | 확률 필드 | 의미 |
-|----------|----------|------|
-| 몬스터 | `f_Monster` / `n_MobNodeMin` / `n_MobNodeMax` | 전투 노드 |
-| 버프/디버프 | `f_BuffDebuff` / `n_BuffDebuffMin` / `n_BuffDebuffMax` | 효과 노드 |
-| 캠프 | `f_CampFire` / `n_CampMin` / `n_CampMax` | 휴식·회복 |
-| 암상인 | `f_Merchant` / `n_MerchantMin` / `n_MerchantMax` | 상점 |
-| 보물 | `f_Treasure` / `n_TreasureMin` / `n_TreasureMax` | 보상 |
-| NPC | `f_NPC` / `n_NPCMin` / `n_NPCMax` | 이벤트 |
-| 성소 | `f_Mine` / `n_MineMin` / `n_MineMax` | 특수 장소 |
-| 갈림길 | `f_TwoWay` / `n_TwoWayMin` / `n_TwoWayMax` | 경로 선택 |
-| Nothing | `f_Nothing` / `n_NothingMin` / `n_NothingMax` | 빈 공간 |
-| Random | `f_Random` / `n_RandomMin` / `n_RandomMax` | 랜덤 롤 |
-
-### §3-2. 실측 현황 — 지역별 하위 스테이지 수
-
-| 지역 | 하위 스테이지 수 | | 지역 | 하위 | | 지역 | 하위 |
-|------|-----|---|------|-----|---|------|-----|
-| 1 | **4** | | 8 | 5 | | 15 | 5 |
-| 2 | 6 | | 9 | 6 | | 16 | 3 |
-| 3 | 5 | | 10 | 5 | | 17 | 8 |
-| 4 | 7 | | 11 | 5 | | 18 | 8 |
-| 5 | 6 | | 12 | 7 | | 19 | 9 |
-| 6 | 7 | | 13 | 4 | | 20 | 9 |
-| 7 | 4 | | 14 | 5 | | 21 | 4 |
-
-**총 122 스테이지**. PD 2026-04-20 실측과 완전 일치.
-
-### §3-3. 기획 의도 재확인
-- **현재 수치는 임시 데이터** — 모든 스테이지에 동일 확률(80 몬스터 / 16.2 캠프 등) 입력
-- **기획팀의 역할**: 스테이지별 노드 확률·최소/최대 개수 **차별화 설계**
-- **PD 고려사항 5종 (재확인)**:
-  1. **몬스터 특성**: MonsterList.n_Specificity1~4 활용
-  2. **고정+랜덤**: 스테이지마다 고정 몬스터 + 매 판 랜덤 조합
-  3. **3★ 조건**: 12개 조건 풀 순환 배치 (P17 배타 7종 준수)
-  4. **반복 방지**: 지역 내 스테이지 간 + 지역 간 다양성
-  5. **지역 순차**: 지역 1 완성 → PD 승인 → 지역 2 착수
-
-### §3-4. 누락 정보 (추후 확인 필요)
-- `n_AppearBossGroup` 형식 불일치: `CreateMapConfig`에서 `10001`·`10002` 등 **MonsterList.n_ID 직접 참조**로 보임. 하지만 이름이 `n_AppearBossGroup`(그룹 ID)이라 의미 혼동 — **개발팀 확인 필요**
-
----
-
-## §4. ApprearMonsterPattern 구조
-
-### §4-1. 필드 정의
-
-| 필드 | 의미 |
-|------|------|
-| `n_AppearMonserGroup` | 몬스터 그룹 고유 ID (CreateMapConfig.n_AppearMonsterGroup 참조) |
-| `n_MonsterID` | 해당 그룹에 소속된 몬스터 ID (MonsterList.n_ID 참조) |
-| `n_AppearRate` | 등장 확률 (100 = 무조건 등장 후보) |
-
-### §4-2. 실측 예시 (Stage1_1)
-- `n_AppearMonsterGroup = 10101`
-- 소속 몬스터: `14001`·`14002`·`14013` (Pattern 소속 3종)
-
-### §4-3. 기획 의도
-- **그룹 ID 체계**: `{지역번호}0{순번}` (예: 10101 = 지역 1 · 스테이지 1번 · 그룹 1)
-  - Stage 1 = 10101~10104 (4개 하위 스테이지)
-  - Stage 2 = 10201~10206 (6개)
-  - ... Stage 21 = 82101~82104 (4개)
-- 각 그룹에 **3~5종 몬스터**가 등장 후보로 등록
-- 런타임에 해당 그룹에서 무작위 선택 (PD 고려사항 2 "랜덤" 대응)
-
----
-
-## §5. MonsterList 구조
-
-### §5-1. 필드 정의 (실측 24개 필드)
-
-#### 식별·표기
-| 필드 | 의미 |
-|------|------|
-| `n_ID` | 몬스터 고유 ID (보스 10001~10028 · 일반 11001~14024 등) |
-| `n_Name` | 로컬라이제이션 참조 ID |
-| `e_MonsterType` | Boss_Range · Boss_Melee · Normal_Range · Normal_Melee 등 |
-| `s_Image` / `s_Icon` | 리소스 경로 |
-
-#### 전투 능력치 (기획팀 1차 참조)
-| 필드 | 의미 |
-|------|------|
-| `n_RewardExp` | 처치 경험치 |
-| `n_HP` | 체력 |
-| `n_Shield` | 보호막 (0 = 쉴드 없음) |
-| `f_AttackCoolTime` | 공격 쿨타임 (초) |
-| `n_AttackMin` / `n_AttackMax` | 공격력 범위 |
-| `n_HitRate` | 명중력 (정수) |
-| `f_Cri` / `f_CriDmg` | 치명타 확률·피해량 |
-| `n_Avoid_Meele` / `n_Avoid_Range` | 근·원 회피력 |
-| `f_Scale` | 몬스터 크기 배율 |
-| `e_AttackType` | Melee / Range |
-| `s_Projectile` | 원거리 투사체 경로 |
-
-#### 몬스터 특성 (PD 고려사항 1 대응 — 핵심 기획 축)
-| 필드 | 의미 |
-|------|------|
-| `n_Specificity1~4` | 특성 ID (StatusConditionsList 참조 추정) |
-
-예시:
-- **오우거1 (10004)**: Specificity1=31004 · Specificity2=32004 → "체력 2배, 최대 공격력 2배"
-- **다크엘프 아처1 (10010)**: Specificity1=31010 · Specificity2=32010 → "광포화-신속 / 치명타 15%"
-
-### §5-2. 참고 필드 (CSV 헤더 31번째 이후)
-- `Lv`·`DPS`·`몬스터 특성` — 기획 참고용 원본 수치
-
-### §5-3. 기획 의도 재확인
-- **몬스터 특성**이 PD 고려사항 1의 핵심 — 스테이지별 몬스터 선정 시 특성 조합 기반
-- 특성 ID 체계(`31XXX`·`32XXX`)는 `MonsterPatternList.json` 또는 `StatusConditionsList.csv`와 교차 참조 필요
-- **누락 정보**: Specificity ID → 효과명 매핑 테이블이 어디에 있는지 확정 필요 (개발팀 확인)
-
----
-
-## §6. 기타 관련 테이블 (요약)
-
-### §6-1. RandomPatternConfig
-- 스테이지 내 **랜덤 노드 롤 규칙** (몬스터/버프/상인/보물/NPC/성소/갈림길 비중)
-- 4가지 프리셋: 기본·많은 상인·많은 상자·많은 몬스터
-- CreateMapConfig.f_Random이 이 테이블을 참조하여 런타임 확장
-
-### §6-2. StatusConditionsList
-- 상태 효과 정의 (Slow·Burn·Poison·Stun·Freezing·Blind·Heal_Hp_Add·Heal_Shield_Add 등)
-- 이펙트 경로 + 표시 위치
-- 몬스터 특성·카드 효과에서 참조 가능
-
-### §6-3. CardList
-- 카드 스탯 (공격력·쿨·효과)
-- Phase 3 `이슈1_3_무시확정_v1.md §3`에서 고정 전제 확정
-
-### §6-4. GlobalValue
-- 게임 전역 상수 (밸런스 조정 기준치 다수)
-
-### §6-5. 추후 전수 조사 필요
-- `AchievementsMission`·`BuffPatternConfig`·`BattleLevelUp`·`ContentsOpenCondition` 등 — 현 Phase 4 범위 외 보류
-
----
-
-## §7. 기존 산출물 오염 범위 (재정비 대상)
-
-### §7-1. 중대 오염 (전면 재작성 필요)
-
-| 문서 | 오염 내용 | 재정비 방식 |
-|------|----------|------------|
-| `Phase4_지역1_노드구성_v1.md` | 지역 1 = Stage 1~6 (6개) 가정으로 전체 설계 | **전면 폐기 · v2 재작성** (지역 1 = Stage1_1~1_4 = 4개) |
-| `스테이지난이도곡선_v1.md §1` | "WorldMap_1~4 4개 그룹" 가정 | §1만 삭제·재작성 · §2~이후 실측 수치(서브맵수·보스)는 정확하므로 **유지** |
-| `맵패턴_사전분석_v1.md` (의심) | "42 슬롯" 체계 가정 (추정 = 21 스테이지 × 2 슬롯) | **재검증 필요** — 121 스테이지 기준으로 재산출 가능성 |
-| `재검증보고_맵패턴_v1.md` (Day 11~14) | 상위 가정 오류로 부분 오염 | **설계 원칙 추출만 승격 · 수치 재검증** |
-
-### §7-2. 경미 오염 (원칙 승격 + 언급 수정)
-
-| 문서 | 오염 내용 | 재정비 방식 |
-|------|----------|------------|
-| `Phase3_종결_설계체계_v1.md` | WorldMap 4그룹 가정 잔존 가능성 | 본 v1 문서 참조 추가 + 해당 표현 교체 |
-| `Phase4_노드구성_착수가이드_v1.md` | "청크 1 = Stage 1~6" 가정 | **재정비** — 청크 = 지역 1개씩으로 재정의 (Stage1_1~1_4 = 지역 1 청크) |
-| `이슈1_3_무시확정_v1.md §3` | 오염 없음 예상 (카드 수치 영역) | 교차 점검만 수행 |
-
-### §7-3. 오염 없음 (유지)
-
-- `3성조건_12개_상세명세_v1.md` — 조건 풀 자체는 WorldMap 구조 무관
-- `SKILL.md P17 배타 7종` — 배타 조합 자체는 WorldMap 구조 무관
-- `밸런싱전략_v1.md`·`밸런싱문서_일관성점검_v1.md`·`전체테이블감사_v1.md` — 데이터 테이블 실측 기반이라 오염 없음
-
----
-
-## §8. 재정비 우선순위
-
-### §8-1. 즉시 (본 라운드)
-1. **본 v1 문서 작성** (SOT 확립)
-2. **기획팀 데이터 실측 의무 룰 (#43) 작성**
-3. **Phase4_지역1_노드구성_v2.md 재작성** (4개 스테이지 기준)
-4. **기존 v1 상단에 "아카이브됨" 배너 추가**
-
-### §8-2. 후속 (별도 PD 지시 수령 시)
-5. `스테이지난이도곡선_v1.md §1` 정정
-6. `Phase4_노드구성_착수가이드_v1.md` 재정비
-7. `맵패턴_사전분석_v1.md`·`재검증보고_맵패턴_v1.md` 재검증
-8. `Phase3_종결_설계체계_v1.md` 표현 수정
-
----
-
-## §9. 기각안
-
-### §9-1. 기각안 A: 기존 v1 수치 살리기 (Stage 1~6을 지역 1로 유지)
-- **기각 사유**: PD 2026-04-20 "PD가 구성한 지역별 스테이지 수량 임의 수정 금지" 직접 지시 위반
-- **손실**: v1 초안 전량 재작성 필요
-- **이득**: 재작성 없음 (기각)
-
-### §9-2. 기각안 B: "WorldMap 4그룹"을 기획 레이블로 명시하고 병행 사용
-- **기각 사유**: 용어 혼선의 근본 원인. 병행 사용 시 신규 기획자 재혼동 유발 (C22 용어 일관)
-- **대체안**: "입문/초반/중반/후반 구간"은 **기획 레이블로만 별도 명시** (데이터 구조가 아닌 밸런싱 분류)
-
-### §9-3. 기각안 C: 누락 정보(Specificity ID 매핑 등)를 기획팀 자체 추정으로 보완
-- **기각 사유**: C23 허위 보고·추정 사실화 금지. 본 재발 방지 지시 #42의 교훈 정면 위반
-- **대체안**: 개발팀 확인 요청 (소통 채널 발행 또는 PM 조율)
-
----
-
-## §10. 참고 문서
-
-- Unity Export 경로: `D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/ResWork/Table/Export/`
-- 실측 CSV 11종 (본 문서 기반): WorldMapConfig · CreateMapConfig · ApprearMonsterPattern · MonsterList · StatusConditionsList · RandomPatternConfig · CardList · PCList · PCAwakening · PCEvolution · PCEvolutionMax · GlobalValue · ItemList · BuffPatternConfig · RewardRandomBag · SanctuaryConfig · StatusOptionSet
-- 전수 감사: `프로젝트/수상한잡화점/기획/전체테이블감사_v1.md`
-- 3성 조건 SOT: `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md`
-- 배타 규칙: SKILL.md P17
-- 기획팀 룰: `프로젝트/수상한잡화점/기획/기획팀_데이터_실측_의무_v1.md` (#43 산출물)
-
----
-
-## §11. 변경 이력 (P16 산출물 추적성)
-
-| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
-|------|--------|----------|----------------|----------|--------------|
-| 2026-04-20 | 기획팀장 | 전체 신설 | (없음) → v1 초안 | 재발 방지 + 정확한 데이터 구조가 기획 의도 실현의 전제 | #42 |
diff --git a/프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md b/프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
deleted file mode 100644
index e1a1d64..0000000
--- a/프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md
+++ /dev/null
@@ -1,178 +0,0 @@
----
-type: 설계문서
-project: 수상한잡화점
-subject: 독립 시뮬레이터 아키텍처 (Unity MCP 실행 인프라)
-version: v1
-date: 2026-04-17
-status: 초판
-author: 개발팀장
-related:
-  - 공유/소통/개발팀→PM/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md
-  - 프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md
-  - 프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md
-핵심원칙:
-  - 기존 수상한잡화점 코드 일체 수정 금지
-  - 독립 어셈블리 격리 (`BurningTimes.Sim.asmdef`)
-  - Editor-only (빌드 산출물 제외)
-  - 메커닉은 별도 모델로 독립 재구현 (Read-only 참조)
----
-
-# 독립 시뮬레이터 아키텍처 v1
-
-## 1. 배경 (왜 필요한가)
-
-### 1-1. PD님 직접 지시 (2026-04-17)
-> "기존 수상한잡화점 프로젝트의 코드나 구조에 영향을 주지 않는 독립적인 시뮬레이터로 동작해야 함."
-
-### 1-2. 요구사항 해석
-1. **기존 코드 불변 원칙**: `Assets/Script/` 하위 파일을 일절 수정 불가. 시뮬 인프라는 **관찰·참조**만 허용, **수정·확장·상속**을 통한 침투 불허
-2. **독립 어셈블리 격리**: 기존 `Assets/Script/*.asmdef`와 별개 어셈블리로 운영하여 빌드 의존성·컴파일 영향 차단
-3. **Editor-only 동작**: 프로덕션 빌드 산출물에 시뮬 코드 포함 방지 (앱 크기·보안·의도치 않은 실행 차단)
-4. **메커닉 재현의 독립성**: Actor·Effect 등의 로직을 재사용·복제가 아닌 **동등 결과를 내는 별도 로직**으로 독립 재구현
-
-### 1-3. 설계 제약 (대안 고려)
-- **대안 A (기각)**: 기존 `Assets/Script/Actor/` 직접 호출하여 시뮬 실행 → 코드 수정 위험·PlayMode 의존·PD 제약 위반
-- **대안 B (기각)**: 별도 레포 구축 → Unity MCP `execute_code`가 현 프로젝트 내부만 접근 가능, 운영 분리 과도
-- **대안 C (채택)**: 같은 Unity 프로젝트 내 `Assets/Sim/` 신규 폴더 + 독립 asmdef + Editor-only define + 모델 독립 재구현
-
----
-
-## 2. 폴더·어셈블리 구조
-
-```
-D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Sim/           ← 신규 (이번에 생성)
-├── BurningTimes.Sim.asmdef                                        ← 독립 어셈블리 정의
-├── Runtime/
-│   ├── SimulationRunner.cs                                     ← 진입점
-│   ├── ScenarioLoader.cs                                       ← 시나리오 JSON → ActorModel 로드
-│   ├── ResultEmitter.cs                                        ← 결과 JSON 출력
-│   └── Models/
-│       ├── ActorModel.cs                                       ← Actor 동등 모델 (독립 재구현)
-│       ├── DefenceModel.cs                                     ← 터치 방어 30% + 지속형 재현
-│       └── DamageCalc.cs                                       ← 데미지 감소 pipeline 재현
-```
-
-### 2-1. 어셈블리 정의 (`BurningTimes.Sim.asmdef`)
-- `name`: `BurningTimes.Sim`
-- `rootNamespace`: `BurningTimes.Sim`
-- `references`: **비움** (기존 어셈블리 참조 안 함 — 독립성 확보)
-- `includePlatforms`: `["Editor"]` (Editor-only)
-- `excludePlatforms`: `[]`
-- `autoReferenced`: `false`
-- `defineConstraints`: `["UNITY_EDITOR"]`
-- `noEngineReferences`: `false` (UnityEngine은 사용, but 최소)
-
-### 2-2. 의존성 격리 결과
-- 빌드 시 본 어셈블리 **자동 제외** (Editor 플랫폼만 타겟)
-- 기존 게임 어셈블리와 컴파일 단위 분리 → 기존 코드 변경 감지 없음
-- 기존 `Assets/Script/` 전혀 참조하지 않으므로 기존 리팩토링·삭제에도 영향 없음
-
----
-
-## 3. 실행 흐름
-
-```
-기획팀장                                Unity MCP                 SimulationRunner
-   │                                       │                           │
-   │  04_MCP_호출_스니펫_v1.md 기반        │                           │
-   │  execute_code 호출                    │                           │
-   │  {scenario_json_path: "..."}          │                           │
-   │                                       │                           │
-   │  ─────────────────────────────►       │                           │
-   │                                       │                           │
-   │                                       │  SimulationRunner.Run(path)
-   │                                       │  ─────────────────────────►
-   │                                       │                           │
-   │                                       │                           │  1. ScenarioLoader.Load(path)
-   │                                       │                           │     → ActorModel 생성
-   │                                       │                           │  2. 전투 tick 루프 실행
-   │                                       │                           │     (DefenceModel·DamageCalc 호출)
-   │                                       │                           │  3. ResultEmitter.Emit(result)
-   │                                       │                           │     → 결과 JSON 파일 또는 stdout
-   │                                       │                           │
-   │                                       │  ◄─────────────────────────
-   │                                       │  {결과 JSON}
-   │  ◄─────────────────────────────       │
-   │                                       │                           │
-   │ 기획팀 분석·밸런스 튜닝                │                           │
-```
-
-### 3-1. 실행 환경 2모드
-- **모드 1 (단일 실행)**: Unity Editor 기동 상태 + MCP 연결 + `execute_code` 한 번 → 결과 1건
-- **모드 2 (배치 실행)**: `execute_code`로 스윕 파라미터 배열 전달 → 내부 루프로 N회 실행 + 결과 N건 집계
-
----
-
-## 4. 독립 모델 설계 (Models/)
-
-### 4-1. ActorModel
-**기존 `Actor.cs`(4545줄)를 재구현하지 않는다.** 시뮬에 필요한 최소 상태만 추출:
-
-```csharp
-public class ActorModel {
-    public string id;
-    public float maxHP, hp;
-    public float shield;
-    public float attackDmg;
-    public float attackCoolTime;
-    public float accumulatedAttackTime;
-    public bool isDefencing;     // ActorStatus == Defecne 동등
-    public bool isDead => hp <= 0f;
-    // ... 시뮬 범위 내 최소 필드만
-}
-```
-
-### 4-2. DefenceModel (실측 규칙 재현)
-Q-P2 정밀 2차 응답서 §2 실측 기반 독립 구현:
-- `PCDefence_Mul = 0.3f` (30% 감소)
-- `PCDefence = 1` (절대값 1 감소)
-- 터치 Down↔Up 지속 (`isDefencing` 플래그)
-- 방어 중 공격 불가 (`accumulatedAttackTime` 갱신 중단)
-- 방어 중 데미지: `dmg = (dmg - 1) * (1 - 0.3)` (추가 감소 스택은 포함하지 않음 — 단순화)
-
-### 4-3. DamageCalc (감소 pipeline 재현)
-`Actor.cs:762-809` 실측 기반 간이 재구현. 시뮬 범위 외(카드·인장·각성)는 제외하고 **순수 방어 메커닉 + 기본 스탯** 차원만 재현. 복잡 메커닉 필요 시 scope 확장 v2에서 추가.
-
-### 4-4. 재구현 원칙
-- **동등 결과 우선, 구조 복사 금지** — 기존 코드를 복붙하지 않고 실측 스펙을 문서로 보고 재작성
-- **최소 기능 원칙** — 밸런싱에 필요한 축(HP·Shield·Dmg·Defence·CoolTime)만 구현, 나머지는 생략
-- **버전 고정 주석** — 각 파일 상단에 `// 실측 기준: Dev 브랜치 43b6074c4 (2026-04-17)` 명시하여 원본 변경 시 재동기화 시점 명확화
-
----
-
-## 5. 검증 방법
-
-### 5-1. 기존 코드 불변 증명
-- 본 작업 커밋 diff에 `Assets/Script/` 하위 변경이 **0건**이어야 한다
-- `git diff --stat Assets/Script/` 결과가 비어있는지 확인
-
-### 5-2. 빌드 제외 증명
-- `manage_build` MCP로 Player 빌드 시도 → 빌드 로그에 `BurningTimes.Sim` 미포함 확인
-- `BurningTimes.Sim.asmdef`의 `includePlatforms: ["Editor"]` 준수
-
-### 5-3. 메커닉 등가성 검증 (향후)
-- 동일 시나리오에서 실제 게임 PlayMode vs 시뮬 실행 결과를 **기획팀이 비교** → 오차 10% 이내 목표
-- 오차 원인이 시뮬 모델 누락인지 실측 데이터 누락인지 구분하여 보완
-
-### 5-4. MCP 연결 필요 환경
-- 본 세션에서 **Unity MCP 접근 가능 여부 미확인** (C23 정직: `mcp__unity-mcp__*` 호출을 실제로 수행하지 않음). 스켈레톤 코드는 작성 완료 상태이며, Unity Editor 구동 + MCP 연결 시점에 기획팀장·개발팀이 실행 검증
-
----
-
-## 6. 확장 포인트 (v2 이후)
-
-1. **카드·인장·각성 효과 모델 추가** — 현재 스코프는 방어 메커닉 중심. 기획팀이 밸런싱 축 확장 요청 시 Models/에 파일 추가
-2. **몬스터 AI 모델** — 현재 단순 공격 tick만. 라인별 공격 조건·특수 효과(자폭·치명타 등) 재현 필요 시 `MonsterAIModel.cs` 추가
-3. **앵커 전투 노드 시퀀스 통합** — 단일 전투가 아닌 스테이지 경로 전체 시뮬
-
----
-
-## 7. 변경 이력
-- **v1 (2026-04-17)**: 초판. PD 지시 #37 독립 시뮬 제약에 따른 어셈블리 격리 아키텍처.
-
-## 8. 기각안 (P24)
-- **기각안 A**: `AssemblyDefinitionReferences` 로 기존 `Assets/Script/` 어셈블리 참조 → 독립성 훼손, PD 제약 위반. 0 references 고수
-- **기각안 B**: Runtime 포함(Editor-only 제외) → 빌드 산출물 오염·보안. Editor-only 확정
-- **기각안 C**: `Assets/Editor/Sim/` 아래 배치 → Unity asmdef 자동 Editor 어셈블리와 충돌 위험. `Assets/Sim/Runtime/` + 자체 asmdef의 Editor 플랫폼 제약이 깔끔
-- **기각안 D**: 별도 레포 서브모듈 → Unity MCP `execute_code` 경로 접근 제약·기획팀 셋업 복잡도 증가. 동일 레포 격리가 최선
diff --git a/프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md b/프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md
deleted file mode 100644
index adc3f11..0000000
--- a/프로젝트/수상한잡화점/시뮬레이터/02_시나리오_JSON_스키마_v1.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-type: 설계문서
-project: 수상한잡화점
-subject: 시뮬레이션 시나리오 입력 JSON 스키마
-version: v1
-date: 2026-04-17
-status: 초판
-author: 개발팀장
----
-
-# 시나리오 JSON 스키마 v1
-
-## 1. 목적
-
-`SimulationRunner`가 받는 **입력 포맷**. 기획팀장이 한 번 작성하면 Unity MCP `execute_code`로 반복 실행 가능. 파라미터 스윕·배치 비교도 본 스키마의 배열 버전으로 처리.
-
-## 2. 최상위 구조
-
-```json
-{
-  "schema_version": "1.0",
-  "scenario_id": "Anchor_Stage1_NoCard_4Mob",
-  "description": "앵커 전투 시뮬 — 카드 0장 + 4마리 전열 몬스터 + 터치 방어 전략",
-  "seed": 12345,
-  "rng_mode": "deterministic",
-  "pc": {
-    "hp": 100,
-    "max_hp": 100,
-    "shield": 0,
-    "attack_dmg": 10,
-    "attack_cooltime": 1.5,
-    "defence_strategy": "touch_hold_on_incoming"
-  },
-  "monsters": [
-    {
-      "id": "mob_front_01",
-      "hp": 20, "max_hp": 20,
-      "attack_dmg": 5,
-      "attack_cooltime": 2.0,
-      "line": "Frontline",
-      "attack_type": "Melee"
-    }
-  ],
-  "global_value": {
-    "PCDefence": 1,
-    "PCDefence_Mul": 0.3
-  },
-  "simulation": {
-    "max_turns": 1000,
-    "tick_interval": 0.1,
-    "stop_on_death": true,
-    "record_detail": true
-  }
-}
-```
-
-## 3. 필드 정의
-
-### 3-1. 메타 (필수)
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| `schema_version` | string | 스키마 버전 (`"1.0"`). 하위 호환 체크용 |
-| `scenario_id` | string | 고유 식별자. 결과 JSON에 그대로 echo됨 |
-| `description` | string | 사람 읽는 설명 (선택) |
-| `seed` | int | 난수 시드. 재현성 보장 |
-| `rng_mode` | string | `"deterministic"` 또는 `"random"`. 기본값 `"deterministic"` |
-
-### 3-2. PC (필수)
-| 필드 | 타입 | 설명 | 기본값 |
-|------|------|------|-------|
-| `hp` / `max_hp` | float | 시작 HP, 최대 HP | — |
-| `shield` | float | 시작 실드 | 0 |
-| `attack_dmg` | float | 공격력 | — |
-| `attack_cooltime` | float | 공격 쿨타임 (초) | — |
-| `defence_strategy` | string | 방어 전략 — 아래 표 참조 | `"never"` |
-
-**defence_strategy 값**:
-| 값 | 동작 |
-|----|------|
-| `"never"` | 방어 사용 안 함 (공격만) |
-| `"always"` | 매 tick 방어 (공격 0 DPS) |
-| `"touch_hold_on_incoming"` | 몬스터 projectile 발사 감지 시 자동 방어 on, 피격 후 off |
-| `"auto_low_hp"` | HP <= `{low_hp_threshold}`% 시 자동 방어 |
-
-### 3-3. Monsters (필수, 배열)
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| `id` | string | 개체 식별자 |
-| `hp` / `max_hp` | float | HP |
-| `attack_dmg` | float | 공격력 |
-| `attack_cooltime` | float | 공격 쿨타임 |
-| `line` | string | `"Frontline"` / `"Middleline"` / `"Backline"` |
-| `attack_type` | string | `"Melee"` / `"Range"` |
-
-### 3-4. GlobalValue (선택, 미제공 시 실측 기본값 사용)
-| 필드 | 타입 | 실측 기본값 | 설명 |
-|------|------|-------------|------|
-| `PCDefence` | int | 1 | 방어 중 절대값 감소 |
-| `PCDefence_Mul` | float | 0.3 | 방어 중 % 감소 (0.3 = 30%) |
-
-실측 기본값 근거: `Assets/ResWork/Table/Export/GlobalValue.json` (Dev 브랜치 `43b6074c4` 시점)
-
-### 3-5. Simulation 제어 (선택)
-| 필드 | 타입 | 기본값 | 설명 |
-|------|------|-------|------|
-| `max_turns` | int | 1000 | 최대 tick 수 (무한루프 방지) |
-| `tick_interval` | float | 0.1 | 1 tick당 시간(초) |
-| `stop_on_death` | bool | true | PC 또는 몬스터 전멸 시 조기 종료 |
-| `record_detail` | bool | false | tick별 상세 로그 생성 여부 (결과 JSON 크기 증가) |
-
-## 4. 파라미터 스윕 (배열 버전)
-
-동일 시나리오를 여러 값으로 돌릴 때:
-
-```json
-{
-  "schema_version": "1.0",
-  "sweep_id": "Defence_Mul_Grid",
-  "base_scenario": { /* 위 §2 구조 */ },
-  "sweep_axes": [
-    {
-      "path": "global_value.PCDefence_Mul",
-      "values": [0.2, 0.3, 0.4, 0.5]
-    },
-    {
-      "path": "monsters[0].attack_dmg",
-      "values": [3, 5, 7]
-    }
-  ],
-  "sweep_mode": "cartesian",
-  "runs_per_cell": 10
-}
-```
-
-- `sweep_mode`: `"cartesian"` (모든 조합) 또는 `"zip"` (같은 인덱스끼리)
-- `runs_per_cell`: 셀당 반복 횟수 (난수 분산 측정)
-
-## 5. 배치 비교 (시나리오 N개)
-
-```json
-{
-  "schema_version": "1.0",
-  "batch_id": "Anchor_Strategies_Compare",
-  "scenarios": [
-    { "scenario_id": "strategy_never", /* 전체 시나리오 */ },
-    { "scenario_id": "strategy_always", /* ... */ },
-    { "scenario_id": "strategy_touch_hold", /* ... */ }
-  ]
-}
-```
-
-`SimulationRunner.RunBatch(path)`가 배열 순회 실행 후 결과 N건을 모아 반환.
-
-## 6. 검증
-
-`ScenarioLoader`가 로드 시 다음을 검증하여 에러 조기 발견:
-1. 필수 필드 부재 → `ScenarioValidationException`
-2. `hp > max_hp` → warning
-3. `attack_cooltime <= 0` → error
-4. 알 수 없는 `defence_strategy` → error
-5. `schema_version` 불일치 → warning
-
-## 7. 예시 — 앵커 전투 (카드 0장, 4마리, 터치 방어)
-
-```json
-{
-  "schema_version": "1.0",
-  "scenario_id": "anchor_stage1_no_card_4mob_touch",
-  "description": "앵커 전투 Stage 1 — 카드 0장 상태에서 4마리 전열 몬스터와 터치 방어 전략",
-  "seed": 42,
-  "pc": {
-    "hp": 100, "max_hp": 100, "shield": 0,
-    "attack_dmg": 8, "attack_cooltime": 1.2,
-    "defence_strategy": "touch_hold_on_incoming"
-  },
-  "monsters": [
-    {"id": "m1", "hp": 15, "max_hp": 15, "attack_dmg": 4, "attack_cooltime": 1.8, "line": "Frontline", "attack_type": "Melee"},
-    {"id": "m2", "hp": 15, "max_hp": 15, "attack_dmg": 4, "attack_cooltime": 1.8, "line": "Frontline", "attack_type": "Melee"},
-    {"id": "m3", "hp": 15, "max_hp": 15, "attack_dmg": 4, "attack_cooltime": 1.8, "line": "Frontline", "attack_type": "Melee"},
-    {"id": "m4", "hp": 15, "max_hp": 15, "attack_dmg": 4, "attack_cooltime": 1.8, "line": "Frontline", "attack_type": "Melee"}
-  ],
-  "simulation": {"max_turns": 500, "tick_interval": 0.1, "stop_on_death": true, "record_detail": false}
-}
-```
-
-## 8. 변경 이력
-- **v1 (2026-04-17)**: 초판. PD 지시 #37 기반. PCDefence/PCDefence_Mul 실측값 기본 내장.
-
-## 9. 기각안
-- **기각안 A**: ScriptableObject 입력 → Unity Editor 외부(MCP)에서 접근 곤란. JSON이 호환성 최고
-- **기각안 B**: YAML 입력 → Unity 기본 파서 없음. JSON이 `JsonUtility` 기본 지원
-- **기각안 C**: 기존 `Actor.cs`·테이블 구조 그대로 입력 → 시뮬 독립성 훼손. 최소 스키마로 재정의
diff --git a/프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md b/프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md
deleted file mode 100644
index be62d53..0000000
--- a/프로젝트/수상한잡화점/시뮬레이터/03_결과_JSON_포맷_v1.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-type: 설계문서
-project: 수상한잡화점
-subject: 시뮬레이션 결과 출력 JSON 포맷
-version: v1
-date: 2026-04-17
-status: 초판
-author: 개발팀장
----
-
-# 결과 JSON 포맷 v1
-
-## 1. 목적
-
-`SimulationRunner` 실행 결과의 **출력 포맷**. 기획팀이 후처리·비교·차트화할 때 구조화된 형태로 활용. 단일 실행·스윕·배치 모두 동일 스키마의 확장.
-
-## 2. 단일 실행 결과
-
-```json
-{
-  "schema_version": "1.0",
-  "scenario_id": "anchor_stage1_no_card_4mob_touch",
-  "run_id": "run_20260417_142301_0001",
-  "timestamp": "2026-04-17T14:23:01Z",
-  "seed": 42,
-  "result": {
-    "pc_survived": true,
-    "pc_remaining_hp": 23,
-    "pc_remaining_hp_ratio": 0.23,
-    "total_turns": 142,
-    "duration_sec": 14.2,
-    "monsters_killed": 4,
-    "monsters_killed_ids": ["m1", "m2", "m3", "m4"],
-    "pc_damage_taken_total": 77,
-    "pc_damage_blocked_total": 33,
-    "pc_damage_dealt_total": 60,
-    "defence_activations": 14,
-    "defence_active_ratio": 0.42,
-    "attacks_by_pc": 8,
-    "attacks_by_pc_blocked_ratio": 0.0
-  },
-  "breakdown": {
-    "damage_taken_by_monster": {"m1": 16, "m2": 20, "m3": 22, "m4": 19},
-    "damage_blocked_by_monster": {"m1": 7, "m2": 9, "m3": 10, "m4": 7},
-    "defence_duration_sec": 5.96
-  },
-  "detail_log_path": null,
-  "errors": []
-}
-```
-
-## 3. 필드 정의
-
-### 3-1. 메타
-| 필드 | 설명 |
-|------|------|
-| `schema_version` | 결과 스키마 버전 |
-| `scenario_id` | 입력 시나리오 ID echo |
-| `run_id` | 실행별 고유 ID (스윕·배치에서 중복 방지) |
-| `timestamp` | ISO 8601 UTC |
-| `seed` | 사용된 난수 시드 |
-
-### 3-2. result (결과 요약 — 밸런싱 판단 핵심 축)
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| `pc_survived` | bool | PC 생존 여부 |
-| `pc_remaining_hp` | float | 종료 시점 PC HP |
-| `pc_remaining_hp_ratio` | float | remaining_hp / max_hp |
-| `total_turns` | int | 실행된 tick 수 |
-| `duration_sec` | float | 시뮬 내부 경과 시간 (tick × interval) |
-| `monsters_killed` | int | 처치된 몬스터 수 |
-| `monsters_killed_ids` | string[] | 처치된 몬스터 ID 목록 |
-| `pc_damage_taken_total` | float | PC가 받은 총 피해 (감소 후) |
-| `pc_damage_blocked_total` | float | 방어로 감소된 총 피해량 (= 원본피해 - 실피해) |
-| `pc_damage_dealt_total` | float | PC가 입힌 총 피해 |
-| `defence_activations` | int | 방어 상태 진입 횟수 |
-| `defence_active_ratio` | float | 방어 상태 유지 시간 / 전체 시뮬 시간 |
-| `attacks_by_pc` | int | PC 공격 발동 횟수 |
-| `attacks_by_pc_blocked_ratio` | float | PC 공격이 방어로 인해 취소된 비율 (기획팀 분석용) |
-
-### 3-3. breakdown (세부 분해)
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| `damage_taken_by_monster` | map<id, float> | 몬스터별 가한 피해 (감소 후) |
-| `damage_blocked_by_monster` | map<id, float> | 몬스터별 감소시킨 피해량 |
-| `defence_duration_sec` | float | 누적 방어 유지 시간 |
-
-### 3-4. detail_log_path (선택)
-- 입력의 `simulation.record_detail == true` 이면 tick별 상세 로그 파일 경로
-- false면 `null`
-
-### 3-5. errors (진단)
-- 시뮬 중 발생한 경고·비치명 에러 목록 (string[])
-- 치명 에러는 예외 throw로 종료되므로 본 필드에 오지 않음
-
-## 4. 스윕 결과
-
-```json
-{
-  "schema_version": "1.0",
-  "sweep_id": "Defence_Mul_Grid",
-  "sweep_axes": [
-    {"path": "global_value.PCDefence_Mul", "values": [0.2, 0.3, 0.4, 0.5]},
-    {"path": "monsters[0].attack_dmg", "values": [3, 5, 7]}
-  ],
-  "runs_per_cell": 10,
-  "cells": [
-    {
-      "coords": {"PCDefence_Mul": 0.2, "monster_attack_dmg": 3},
-      "runs": [ /* 결과 10개 */ ],
-      "stats": {
-        "pc_survived_ratio": 1.0,
-        "pc_remaining_hp_mean": 62.3,
-        "pc_remaining_hp_std": 8.1,
-        "total_turns_mean": 98,
-        "total_turns_std": 12
-      }
-    }
-    /* N × M cells */
-  ]
-}
-```
-
-스윕 cell별 자동 집계 통계:
-- `pc_survived_ratio`: 생존률
-- `pc_remaining_hp_mean` / `std`: 종료 HP 평균·표준편차
-- `total_turns_mean` / `std`: tick 수 평균·표준편차
-
-## 5. 배치 결과
-
-```json
-{
-  "schema_version": "1.0",
-  "batch_id": "Anchor_Strategies_Compare",
-  "results": [
-    {"scenario_id": "strategy_never", /* 단일 결과 §2 */},
-    {"scenario_id": "strategy_always", /* ... */},
-    {"scenario_id": "strategy_touch_hold", /* ... */}
-  ],
-  "comparison": {
-    "best_by": "pc_remaining_hp_ratio",
-    "ranking": ["strategy_touch_hold", "strategy_always", "strategy_never"],
-    "deltas": {
-      "strategy_touch_hold_vs_never": {"pc_remaining_hp_ratio": 0.42, "total_turns": 34}
-    }
-  }
-}
-```
-
-## 6. 출력 위치 선택지
-
-기획팀 결정 영역 (1차 응답서 §3-2 참조). 현 설계는 3가지 지원:
-
-| 모드 | 출력 방식 | 용도 |
-|------|----------|------|
-| `stdout` | 표준 출력 스트림 | MCP `execute_code` 응답으로 즉시 수신 |
-| `file` | `Assets/Sim/Output/{scenario_id}_{timestamp}.json` | Editor 내 기록 보존 |
-| `path` | 사용자 지정 경로 (프로젝트 외부 가능) | `기획팀/.cache/` 등으로 직접 저장 |
-
-`ResultEmitter.Emit(result, mode, pathOptional)` 시그니처.
-
-## 7. 세부 로그 포맷 (record_detail=true 시)
-
-별도 파일 `detail_log_path`가 가리키는 JSON (tick별 상태):
-
-```json
-{
-  "scenario_id": "...",
-  "ticks": [
-    {
-      "t": 0.0,
-      "pc": {"hp": 100, "is_defencing": false, "attack_acc": 0.0},
-      "monsters": [{"id": "m1", "hp": 15, "attack_acc": 0.0}]
-    },
-    {
-      "t": 0.1,
-      "pc": {"hp": 100, "is_defencing": true},
-      "events": ["monster_m1_projectile_spawned", "pc_defence_activated"]
-    }
-  ]
-}
-```
-
-**주의**: 상세 로그 파일은 tick당 수 KB이므로 `max_turns: 500` 시나리오에서 수 MB까지 가능. 평소 off 권장, 밸런스 디버깅 시점만 on.
-
-## 8. 후처리 가이드 (기획팀)
-
-### 8-1. 단일 실행 분석
-- `pc_remaining_hp_ratio` 를 "체감 난이도" 지표로 활용 (0.5 이상 = 여유, 0.2 이하 = 타이트)
-- `defence_active_ratio` 가 과도히 높으면 (>0.6) 방어가 의도보다 강력함 신호
-
-### 8-2. 스윕 분석
-- `pc_survived_ratio == 1.0` 이지만 `pc_remaining_hp_ratio` 편차가 큰 cell = 불안정 밸런스
-- `stats.total_turns_std / mean > 0.3` = 난수 편차 과다 (시나리오 취약)
-
-### 8-3. 배치 분석
-- `comparison.ranking` 로 전략 우위 확인
-- `deltas` 로 구체 수치 차이 측정
-
-## 9. 변경 이력
-- **v1 (2026-04-17)**: 초판.
-
-## 10. 기각안
-- **기각안 A**: Markdown 결과 출력 → 후처리 자동화 곤란. JSON 구조화가 밸런싱 툴 호환성 최고
-- **기각안 B**: Excel/CSV 결과 → 중첩 구조(breakdown/sweep cells) 표현 제한. JSON + 필요 시 CSV 변환이 유연
-- **기각안 C**: tick 로그 항상 포함 → 토큰·디스크 낭비. 플래그 제어가 효율
diff --git a/프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md b/프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md
deleted file mode 100644
index f93e00d..0000000
--- a/프로젝트/수상한잡화점/시뮬레이터/04_MCP_호출_스니펫_v1.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-type: 설계문서
-project: 수상한잡화점
-subject: Unity MCP 호출 스니펫 — 기획팀장용 복붙 템플릿
-version: v1
-date: 2026-04-17
-status: 초판
-author: 개발팀장
-target_users: 기획팀장, /balance, /level 에이전트
----
-
-# Unity MCP 호출 스니펫 v1
-
-## 1. 사용 전제
-
-1. **Unity Editor 기동 중** (`D:/BurningTimes/FilGoodBandits/DeckBuilding` 프로젝트 열림)
-2. **Unity MCP 연결 상태** (`mcp__unity-mcp__*` 도구 사용 가능)
-3. **독립 시뮬 어셈블리 컴파일 완료** (`Assets/Sim/BurningTimes.Sim.asmdef`)
-4. **시나리오 JSON 파일 준비** (스키마: `02_시나리오_JSON_스키마_v1.md`)
-
-검증 방법:
-```
-mcp__unity-mcp__execute_code (code: "UnityEngine.Debug.Log(\"MCP OK\");")
-```
-
-## 2. 3종 템플릿
-
-### 2-1. 단일 실행 스니펫
-
-**용도**: 시나리오 1건 즉시 실행하여 결과 확인.
-
-**복붙용 프롬프트** (기획팀장이 Claude/PM에게 전달):
-```
-Unity MCP로 아래 시나리오 1건 실행해주세요:
-- 시나리오 파일: {경로 예: D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Sim/Scenarios/anchor_stage1.json}
-- 출력 모드: stdout
-- 결과 요지 요청: pc_survived, pc_remaining_hp_ratio, total_turns, defence_active_ratio
-```
-
-**MCP 도구 호출** (실행자가 실제 수행):
-```csharp
-mcp__unity-mcp__execute_code
-  code: """
-  using BurningTimes.Sim;
-  var runner = new SimulationRunner();
-  var result = runner.Run("Assets/Sim/Scenarios/anchor_stage1.json");
-  UnityEngine.Debug.Log(UnityEngine.JsonUtility.ToJson(result, true));
-  """
-```
-
-**기대 결과**: Unity Console에 결과 JSON 출력 (§03 포맷 v1 준수). `read_console` 로 회수 가능.
-
-### 2-2. 파라미터 스윕 스니펫
-
-**용도**: 한 축 또는 여러 축 값들을 그리드 형태로 N회 반복 실행, 통계 집계.
-
-**복붙용 프롬프트**:
-```
-Unity MCP로 파라미터 스윕을 실행해주세요:
-- 베이스 시나리오: {경로}
-- 스윕 축:
-  - PCDefence_Mul: [0.2, 0.3, 0.4, 0.5]
-  - monsters[0].attack_dmg: [3, 5, 7]
-- 모드: cartesian
-- 셀당 반복: 10회
-- 결과 집계 요지 요청: 각 셀의 pc_survived_ratio + pc_remaining_hp_mean
-```
-
-**MCP 도구 호출**:
-```csharp
-mcp__unity-mcp__execute_code
-  code: """
-  using BurningTimes.Sim;
-  var runner = new SimulationRunner();
-  var sweep = runner.RunSweep("Assets/Sim/Scenarios/sweep_defence_mul.json");
-  UnityEngine.Debug.Log(UnityEngine.JsonUtility.ToJson(sweep, true));
-  """
-```
-
-**결과 해석 예시**:
-```
-cells[0] (Mul=0.2, dmg=3): survived=1.0, HP_mean=62.3
-cells[1] (Mul=0.2, dmg=5): survived=1.0, HP_mean=34.8
-cells[2] (Mul=0.2, dmg=7): survived=0.6, HP_mean=12.1
-... (총 4 × 3 = 12 cells)
-```
-
-### 2-3. 배치 비교 스니펫
-
-**용도**: 서로 다른 시나리오·전략 N개를 한 번에 실행하여 결과 비교.
-
-**복붙용 프롬프트**:
-```
-Unity MCP로 전략 비교 배치 실행 해주세요:
-- 배치 파일: {경로}
-- 포함 시나리오: strategy_never, strategy_always, strategy_touch_hold
-- 랭킹 기준: pc_remaining_hp_ratio
-- 결과 요지 요청: 전략별 ranking + deltas
-```
-
-**MCP 도구 호출**:
-```csharp
-mcp__unity-mcp__execute_code
-  code: """
-  using BurningTimes.Sim;
-  var runner = new SimulationRunner();
-  var batch = runner.RunBatch("Assets/Sim/Scenarios/strategies_compare.json");
-  UnityEngine.Debug.Log(UnityEngine.JsonUtility.ToJson(batch, true));
-  """
-```
-
-## 3. 파일 기반 결과 회수 (출력 모드 `file`)
-
-시나리오 입력에 `"output_mode": "file"` 또는 호출 시 지정:
-
-```csharp
-mcp__unity-mcp__execute_code
-  code: """
-  using BurningTimes.Sim;
-  var runner = new SimulationRunner();
-  var result = runner.Run("Assets/Sim/Scenarios/anchor_stage1.json");
-  ResultEmitter.EmitFile(result, "Assets/Sim/Output/anchor_stage1_result.json");
-  UnityEngine.Debug.Log("saved");
-  """
-```
-
-이후 Read 도구로 파일 내용 조회:
-```
-Read: D:/BurningTimes/FilGoodBandits/DeckBuilding/Assets/Sim/Output/anchor_stage1_result.json
-```
-
-## 4. 프로젝트 외부 저장 (기획팀 `.cache/` 등)
-
-시뮬 결과를 Unity 외부 기획 워크스페이스에 직접 저장:
-
-```csharp
-mcp__unity-mcp__execute_code
-  code: """
-  using BurningTimes.Sim;
-  var runner = new SimulationRunner();
-  var result = runner.Run("Assets/Sim/Scenarios/anchor_stage1.json");
-  ResultEmitter.EmitFile(result, @"D:/BurningTimes/BurningTimesAi/기획팀/.cache/sim_results/anchor_stage1.json");
-  """
-```
-
-## 5. 에러 진단 체크리스트
-
-### 5-1. MCP 연결 실패
-- Unity Editor 상태 확인 (`manage_editor` 호출)
-- MCP 서버 재시작 (Claude Code 재연결)
-- Transport 모드 `stdio:6400` 확인 (교훈: 2026-04-14 Transport HTTP Local 불일치)
-
-### 5-2. 컴파일 에러
-- `Assets/Sim/*.cs` 변경 후 `refresh_unity` 호출하여 재컴파일
-- Editor Console 스캔: `read_console`
-
-### 5-3. 시나리오 파싱 실패
-- 스키마 버전 확인 (`schema_version: "1.0"`)
-- JSON 유효성 검사 (외부 툴 또는 `JsonUtility.FromJson` try/catch 확인)
-- `ScenarioValidationException` 메시지 참조
-
-### 5-4. 결과가 이상 (비현실적 값)
-- `seed` 고정 여부 (`deterministic` 모드인지 확인)
-- `global_value` 기본값 오버라이드 확인
-- 상세 로그 활성화(`record_detail: true`)로 tick 추적
-
-## 6. 실행 흐름 예시 (전체 파이프라인)
-
-```
-1. 기획팀장: 시나리오 JSON 작성
-   ↓
-2. PM 또는 기획팀장: Claude Code에서 본 문서 §2-1 프롬프트 전달
-   ↓
-3. Claude: mcp__unity-mcp__execute_code 호출
-   ↓
-4. Unity Editor: SimulationRunner.Run() 실행
-   ↓
-5. Claude: read_console 로 결과 JSON 회수
-   ↓
-6. 기획팀장: 결과 JSON 분석·밸런스 튜닝
-   ↓
-7. (반복) 시나리오·스윕 조정하여 다시 §2
-```
-
-## 7. 변경 이력
-- **v1 (2026-04-17)**: 초판. MCP 연결 미확인 상태에서 작성 — 실제 실행 검증은 Unity Editor 기동 + MCP 연결 시점에 수행 (C23 정직).
-
-## 8. 기각안
-- **기각안 A**: Unity Editor 외부에서 .NET 직접 실행 → Unity 테이블 의존성·Addressable 로드 등 환경 재현 비용 과도. Editor 내 실행이 최선
-- **기각안 B**: PlayMode 강제 전환 후 시뮬 → 시뮬 독립성 저해·프레임 락·기존 InGame 로직 간섭. EditMode + 독립 Runner가 깔끔
-- **기각안 C**: Headless 모드 배치 빌드 실행 → 빌드·CI 파이프라인 복잡. MCP `execute_code` 즉시 실행이 기획팀 피드백 루프 최적
diff --git a/프로젝트/신규 프로젝트/README.md b/프로젝트/신규 프로젝트/README.md
deleted file mode 100644
index 06b7e41..0000000
--- a/프로젝트/신규 프로젝트/README.md	
+++ /dev/null
@@ -1,47 +0,0 @@
-# BurningTimes 범용 프로젝트 템플릿
-
-> **용도**: 신규 게임 프로젝트 시작 시 이 폴더를 복사하여 기반 구조를 빠르게 갖춘다.
-> **버전**: v1
-> **작성일**: 2026-04-16
-> **담당**: 개발팀장
-
----
-
-## 사용법
-
-1. `신규 프로젝트/` 폴더를 `프로젝트/{프로젝트명}/`으로 복사
-2. 각 파일 내 `{프로젝트명}`, `{장르}`, `{ProjectNamespace}` 등 placeholder를 실제 값으로 치환
-3. `관리/프로젝트_시작_체크리스트.md`의 Phase 순서대로 진행
-4. 해당 프로젝트에 불필요한 섹션은 삭제 (C14 토큰 최소화)
-
----
-
-## 작성 원칙
-
-- **C7**: `기획/02_핵심_재미_정의.md`가 PD님 승인을 받기 전 03~08번 문서 착수 금지
-- **C9**: MVP/점진적 도입 등 타협 표현 사용 금지
-- **C15**: 일정/기한 표현("이번 주", "N일 내" 등) 사용 금지
-- 각 문서는 `_v1` 접미사로 시작, 변경 시 버전 증가
-- 버전 관리는 Git 커밋 이력 + 문서 내 버전 표기 병행
-
----
-
-## 폴더 구조
-
-| 폴더 | 내용 | 파일 수 |
-|------|------|--------|
-| `기획/` | 게임 기획 문서 (컨셉, 재미, 시스템, 컨텐츠, 밸런스, UX, 수익화, 라이브) | 8 |
-| `개발/` | 기술 문서 (아키텍처, 기술스택, 컨벤션, 데이터, 빌드, QA) | 6 |
-| `관리/` | 프로젝트 관리 (시작 체크리스트, Unity 셋업 가이드) | 2 |
-
----
-
-## BT.Framework 연동
-
-본 템플릿은 `com.nerdnavis.framework` (BT.Framework) 사용을 전제한다.
-연동 절차는 `관리/Unity_셋업_가이드.md` 참조.
-
-- **패키지 이름**: `com.nerdnavis.framework`
-- **루트 네임스페이스**: `BurningTimes`
-- **배포 방식**: C+H1 (UPM Git URL + 로컬 file: 오버라이드)
-- **상세**: `관리/Unity_셋업_가이드.md` 섹션 2 참조
diff --git a/프로젝트/신규 프로젝트/개발/01_아키텍처_설계.md b/프로젝트/신규 프로젝트/개발/01_아키텍처_설계.md
deleted file mode 100644
index f908768..0000000
--- a/프로젝트/신규 프로젝트/개발/01_아키텍처_설계.md	
+++ /dev/null
@@ -1,164 +0,0 @@
-# {프로젝트명} — 아키텍처 설계
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} Unity 클라이언트
-
----
-
-## 1. 프로젝트 기본 정보
-
-| 항목 | 값 | 비고 |
-|------|-----|------|
-| **Unity 버전** | 6000.0.x 이상 (Unity 6 LTS) | 하위 버전 사용 시 팀장 확인 필수 |
-| **타겟 플랫폼** | Android(주), iOS, Windows(Editor) | {장르}에 따라 조정 |
-| **Scripting Backend** | IL2CPP | Android/iOS 공통 |
-| **API 호환성** | .NET Standard 2.1 | |
-| **BT.Framework 버전** | `com.nerdnavis.framework v0.x.y` | `관리/Unity_셋업_가이드.md` 참조 |
-| **렌더 파이프라인** | URP (기본) / Built-in (선택) | 착수 시 확정 |
-
----
-
-## 2. 어셈블리(asmdef) 구성
-
-> ⚠️ **Assembly-CSharp 단일 어셈블리 금지** (수상한잡화점 교훈: asmdef 미적용으로 컴파일 시간 증가·의존성 관리 불가 문제 발생)
-
-| asmdef | 경로 | 의존 |
-|--------|------|------|
-| `{ProjectNamespace}.Core` | `Assets/Scripts/{ProjectNamespace}/Core/` | BT.Framework.Runtime |
-| `{ProjectNamespace}.UI` | `Assets/Scripts/{ProjectNamespace}/UI/` | .Core |
-| `{ProjectNamespace}.Data` | `Assets/Scripts/{ProjectNamespace}/Data/` | .Core |
-| `{ProjectNamespace}.Server` | `Assets/Scripts/{ProjectNamespace}/Server/` | .Core |
-| `{ProjectNamespace}.Editor` | `Assets/Scripts/{ProjectNamespace}/Editor/` | .Core, BT.Framework.Editor (Editor only) |
-| `ThirdParty/` | `Assets/ThirdParty/` | 서드파티별 격리 |
-
-**규칙**:
-- 각 asmdef는 자신의 역할 외 다른 도메인 코드를 포함하지 않는다
-- 순환 참조 금지 (Core ← UI ← Data ← Server 단방향)
-- 에디터 전용 코드는 반드시 `.Editor` asmdef로 분리
-
----
-
-## 3. Assets 폴더 구조
-
-```
-Assets/
-├── Scripts/
-│   └── {ProjectNamespace}/
-│       ├── Core/               ← 게임 매니저, 부트스트랩, 공통 모델
-│       ├── UI/                 ← UI View, Panel, HUD
-│       ├── Data/               ← DataTable 서브클래스, DataLoader
-│       ├── Server/             ← 서버 통신 레이어 (INetworkService 구현)
-│       └── Editor/             ← 에디터 전용 도구
-├── Addressable/
-│   ├── Ingame/                 ← 인게임 리소스 그룹
-│   ├── UI/                     ← UI 리소스 그룹
-│   └── Audio/                  ← 오디오 그룹
-├── Scenes/
-│   ├── 00_Bootstrap.unity
-│   └── ...
-├── Prefabs/
-├── Art/
-│   ├── Sprites/
-│   ├── Effects/
-│   └── Characters/
-├── Audio/
-│   ├── BGM/
-│   └── SFX/
-├── ThirdParty/                 ← 서드파티 패키지 격리
-└── Editor/                     ← 프로젝트 에디터 도구 (asmdef 없는 구역)
-```
-
-**주의**: `Resources/` 폴더는 최소 사용. 동적 로딩은 Addressables로 대체한다.
-
----
-
-## 4. 네임스페이스 체계
-
-> ⚠️ **전역 네임스페이스(global) 사용 금지** (수상한잡화점 교훈: 클래스명 충돌 위험, 장기 리팩토링 부담)
-
-```
-{ProjectNamespace}                    ← 루트 (공용 인터페이스, 공용 enum)
-│
-├── {ProjectNamespace}.Core           ← 게임 매니저, 부트스트랩, 공통 도메인
-├── {ProjectNamespace}.UI             ← UI View, Panel
-├── {ProjectNamespace}.Data           ← DataTable 구현체, DataLoader
-├── {ProjectNamespace}.Server         ← 서버 통신, Request/Response 래퍼
-└── {ProjectNamespace}.Editor         ← 에디터 도구 (런타임 제외)
-```
-
-**BurningTimes 네임스페이스와 분리 원칙**:
-- `BurningTimes.*` = 프레임워크 영역 (수정 불가)
-- `{ProjectNamespace}.*` = 프로젝트 전용 영역
-- 두 영역의 혼합 사용 금지
-
----
-
-## 5. 매니저/시스템 목록
-
-| 클래스 | 역할 | 라이프사이클 | Framework 의존 |
-|--------|------|-------------|---------------|
-| `GameManager` | 게임 전체 상태 관리, 씬 전환 총괄 | `MonoSingleton<T>` (Persistent) | ✅ |
-| `DataManager` | DataTable 로딩·캐시 관리 | `MonoSingleton<T>` (Persistent) | ✅ |
-| `UIManager` | UI View 스택·전환 관리 | `MonoSingleton<T>` (Persistent) | ✅ |
-| `AudioManager` | BGM/SFX 재생 | `BurningTimes.Audio` 위임 | ✅ |
-| `ServerManager` | 서버 통신 추상화 | `ServiceLocator` | ✅ |
-| `SaveManager` | 세이브/로드 | `ServiceLocator` + `BurningTimes.Save` | ✅ |
-| `{Game}Manager` | 핵심 게임 로직 매니저 ({장르} 특화) | `MonoSingleton<T>` or `ServiceLocator` | 상황별 |
-
-**라이프사이클 선택 기준**:
-- `MonoSingleton<T>`: Update/OnDestroy 훅이 필요하거나 씬 생명주기와 동기화가 필요한 서비스
-- `ServiceLocator`: 순수 C# 서비스, 인터페이스 바인딩·테스트 대체가 필요한 서비스
-
----
-
-## 6. 씬 구성
-
-| 씬명 | 역할 | 로드 방식 |
-|------|------|----------|
-| `00_Bootstrap` | 앱 진입점, 초기화(Manager 셋업, DataTable 로딩) | Single (시작점) |
-| `01_Title` | 타이틀·로그인 화면 | Single |
-| `02_Main` | 메인 로비 | Single |
-| `03_Ingame` | 인게임(핵심 게임 루프) | Single or Additive |
-| `9x_Tool_*` | 개발용 도구 씬 (배포 빌드 씬 리스트 제외 필수) | Single |
-
-**규칙**:
-- 배포 빌드에서 `9x_Tool_*` 씬은 Build Settings 씬 목록에서 **반드시 제외**
-- 씬 전환은 `GameManager`를 통해서만 수행 (직접 `SceneManager.LoadScene` 금지)
-
----
-
-## 7. 서드파티 의존성
-
-| 패키지 | 버전 | 용도 | 라이선스 |
-|--------|------|------|----------|
-| `com.unity.addressables` | 2.x | 리소스 번들 관리 | Unity |
-| `com.unity.nuget.newtonsoft-json` | 3.x | JSON 직렬화 | MIT |
-| `com.unity.render-pipelines.universal` | 17.x | URP 렌더링 | Unity |
-| `com.unity.textmeshpro` | (번들) | UI 텍스트 | Unity |
-| `(AntiCheatToolkit)` | 최신 | 메모리 변조 방어 | 구매 |
-| `{추가 서드파티}` | `{버전}` | `{용도}` | `{라이선스}` |
-
-**서드파티 추가 규칙**:
-- 신규 서드파티 추가 시 `공유/` 채널에 라이선스·용도·대안 검토 결과를 기록 (P15)
-- `ThirdParty/` 폴더에 격리하여 프로젝트 코드와 물리적으로 분리
-
----
-
-## 8. 열린 결정 항목
-
-| 항목 | 선택지 | 현재 상태 |
-|------|--------|----------|
-| 렌더 파이프라인 | URP / Built-in | 미결 |
-| 백엔드 서비스 | PlayFab / GameSparks / 자체 서버 | 미결 |
-| DI 추가 도구 | ServiceLocator(Framework 내장) / VContainer | 미결 |
-| 비동기 패턴 | async/await + CoroutineRunner / UniTask | 미결 |
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안 |
diff --git a/프로젝트/신규 프로젝트/개발/02_기술스택_결정.md b/프로젝트/신규 프로젝트/개발/02_기술스택_결정.md
deleted file mode 100644
index c4729a5..0000000
--- a/프로젝트/신규 프로젝트/개발/02_기술스택_결정.md	
+++ /dev/null
@@ -1,94 +0,0 @@
-# {프로젝트명} — 기술스택 결정
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} 전 개발 스택
-
----
-
-## 1. 서버/백엔드
-
-| 항목 | 선택 | 대안 | 근거 |
-|------|------|------|------|
-| **백엔드 서비스** | `{선택 예: PlayFab / 자체 서버}` | `{대안}` | `{선택 근거}` |
-| **인증 방식** | `{선택 예: 디바이스ID / 구글 로그인}` | `{대안}` | `{근거}` |
-| **실시간 통신** | `{선택 예: 불필요 / WebSocket}` | `{대안}` | `{근거}` |
-| **데이터 저장** | `{선택 예: 서버 계정 데이터 + 로컬 캐시}` | `{대안}` | `{근거}` |
-
-**결정 미완료 항목**: 위 표에서 `{}`로 표기된 항목은 착수 전 팀장 확정 필수. 결정 후 이 섹션을 갱신한다.
-
----
-
-## 2. 클라이언트 핵심 스택
-
-| 영역 | 선택 | 비고 |
-|------|------|------|
-| **UI 시스템** | UGUI 주력, UIToolkit 보조 | BT.Framework 정책 (01_아키텍처_개요 참조) |
-| **리소스 관리** | Unity Addressables | Resources.Load 남용 금지 (03_코딩_컨벤션 참조) |
-| **JSON 라이브러리** | Newtonsoft.Json (Unity 패키지) | `com.unity.nuget.newtonsoft-json` |
-| **비동기 패턴** | async/await + `BurningTimes.Core.Coroutine.CoroutineRunner` | UniTask 도입 여부는 별도 결정 |
-| **DI** | `BurningTimes.Core.Patterns.ServiceLocator` | 인터페이스 기반 등록·조회 |
-| **이벤트** | `BurningTimes.Core.Event.EventBus` (타입 안전) | 문자열 키 이벤트 금지 |
-
----
-
-## 3. 🔴 보안 안티패턴 체크리스트
-
-> **수상한잡화점 Critical 3건에서 도출된 필수 점검 항목.** 착수 전 개발팀장이 전수 검토하고, 해당 항목의 설계 결정을 이 섹션에 기록한다.
-
-### 3.1 전투/핵심 연산 서버 검증
-
-- [ ] **전투·핵심 게임 연산의 서버 검증 구조 확보 (100% 클라이언트 연산 금지)**
-  - 위반 사례: 수상한잡화점 HP/Shield/Buff 전부 클라 계산 → 클라 변조 시 서버 검증 불가
-  - 적용 방향: `{선택 예: 클리어 판정·보상 지급은 서버 재연산 / 최소 HMAC 서명 검증}`
-  - 결정 상태: `{미결 / 완료}`
-
-### 3.2 암호화 키 관리
-
-- [ ] **암호화 키·비밀값 하드코딩 금지 (서버 측 키 관리 또는 환경변수)**
-  - 위반 사례: 수상한잡화점 CryptoUtil.cs에 AES 키(32byte), IV(16byte) 평문 하드코딩
-  - 적용 방향: `{선택 예: 런타임 디바이스ID 유도 키 / 서버 전달 키 / 환경변수}`
-  - 결정 상태: `{미결 / 완료}`
-
-### 3.3 IAP 영수증 서버 검증
-
-- [ ] **IAP 영수증 서버 검증 필수 (클라이언트 단독 결제 처리 금지)**
-  - 위반 사례: 수상한잡화점 영수증 검증 전부 주석처리 → 결제 우회 가능, 매출 직접 손실
-  - 적용 방향: `{선택 예: PlayFab ValidateXXXReceipt API / 자체 서버 검증 엔드포인트}`
-  - 결정 상태: `{미결 / 완료 / 해당 없음(IAP 미포함 프로젝트)}`
-
-### 3.4 추가 보안 항목
-
-- [ ] **SpeedHack/TimeCheck Detector 적용** (AntiCheatToolkit 또는 자체 구현)
-- [ ] **전투 스탯·재화·레벨 핵심 필드 `Obscured*` 적용** (AntiCheatToolkit 사용 시)
-- [ ] **빌드 시 JSON 평문 노출 대응** (APK 분해 시 데이터 테이블 노출 위험)
-
----
-
-## 4. CI/CD
-
-| 항목 | 선택 | 비고 |
-|------|------|------|
-| **버전 관리** | Git (main 브랜치 기준) | C18 조직 공유 완료 기준 |
-| **빌드 자동화** | `{선택 예: GitHub Actions / Jenkins / 수동}` | `{근거}` |
-| **배포 채널** | `{선택 예: Firebase App Distribution / TestFlight / 사내 공유}` | QA 배포용 |
-| **스토어 배포** | `{선택 예: 수동 / fastlane}` | Release 빌드 |
-
----
-
-## 5. 개발 도구
-
-| 도구 | 용도 | 비고 |
-|------|------|------|
-| Claude Code (Claude Code) | 코드 생성·리뷰·문서 | BurningTimes 조직 표준 |
-| Unity MCP | Claude ↔ Unity Editor 연동 | `unity-mcp` 패키지 |
-| `{추가 도구}` | `{용도}` | |
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. 보안 체크리스트 수상한잡화점 3건 반영 |
diff --git a/프로젝트/신규 프로젝트/개발/03_코딩_컨벤션.md b/프로젝트/신규 프로젝트/개발/03_코딩_컨벤션.md
deleted file mode 100644
index a208346..0000000
--- a/프로젝트/신규 프로젝트/개발/03_코딩_컨벤션.md	
+++ /dev/null
@@ -1,223 +0,0 @@
-# {프로젝트명} — 코딩 컨벤션
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} 전 C# 코드
-
----
-
-## 1. 네이밍 규칙
-
-> 아래 규칙은 BT.Framework 아키텍처 설계안(네이밍 매핑표)을 기반으로 한다.
-> `My*` 접두사, `u*` 접두사, `Mgr` 접미사는 **전면 금지** (수상한잡화점 패턴 계승 금지).
-
-| 대상 | 규칙 | 예시 |
-|------|------|------|
-| **네임스페이스** | PascalCase | `{ProjectNamespace}.Core` |
-| **클래스** | PascalCase | `GameManager`, `PlayerController` |
-| **인터페이스** | `I` + PascalCase | `ISaveProvider`, `INetworkService` |
-| **메서드** | PascalCase | `LoadData()`, `HandleDamage()` |
-| **프로퍼티** | PascalCase | `CurrentHp`, `IsGameOver` |
-| **private 필드** | `_` + camelCase | `_currentHp`, `_isInitialized` |
-| **const / static readonly** | SCREAMING_SNAKE_CASE | `MAX_HP`, `DEFAULT_TIMEOUT` |
-| **enum 타입** | PascalCase | `GameState`, `ItemType` |
-| **enum 값** | PascalCase | `GameState.Playing`, `ItemType.Weapon` |
-| **지역 변수** | camelCase | `int damage`, `string key` |
-| **이벤트 구조체(EventBus용)** | PascalCase + `Event` 접미사 | `PlayerDiedEvent`, `StageCompleteEvent` |
-
-**금지 패턴**:
-- `My*` 접두사: `MyCoroutine` → `CoroutineRunner` 사용
-- `u*` 소문자 접두사: `uScrollViewMgr` → `ScrollViewController`
-- `Mgr` 접미사: `UIAtlasMgr` → `UIAtlasManager`
-- `Base` 접미사 (추상 클래스): `CustomParserBase` → `abstract class CustomParser`
-- `Info` 접미사 (데이터 클래스): `GachaGradeInfo` → `GachaGrade`
-- `Handler` 접미사 (스케줄러): `SchedulHandler` → `GameScheduler`
-
----
-
-## 2. 파일 구조
-
-```csharp
-// 헤더 주석 (선택, 복잡한 파일만)
-// 파일명: PlayerController.cs
-// 네임스페이스: {ProjectNamespace}.Core
-
-using System;
-using System.Collections.Generic;
-using UnityEngine;
-using BurningTimes.Core.Patterns;   // Framework 참조는 using 으로만
-
-namespace {ProjectNamespace}.Core
-{
-    public class PlayerController : MonoBehaviour
-    {
-        // 1. 직렬화 필드 (Inspector)
-        [SerializeField] private int _maxHp = 100;
-
-        // 2. private 필드
-        private int _currentHp;
-
-        // 3. 프로퍼티
-        public int CurrentHp => _currentHp;
-
-        // 4. Unity 라이프사이클 메서드 (Awake > Start > Update > ...)
-        private void Awake() { }
-        private void Start() { }
-
-        // 5. public 메서드
-        public void TakeDamage(int amount) { }
-
-        // 6. private 메서드
-        private void Die() { }
-    }
-}
-```
-
-**규칙**:
-- 1파일 = 1클래스 (partial class 예외: 에디터 확장, 자동 생성 코드)
-- 파일명 = 클래스명 (대소문자 포함 일치)
-- 폴더 경로 ≈ 네임스페이스 구조
-
----
-
-## 3. BT.Framework 사용 패턴
-
-### 3.1 MonoSingleton<T> — MonoBehaviour 싱글톤
-
-```csharp
-// 씬 라이프사이클과 동기화되는 서비스에 사용
-// Update/OnDestroy 훅이 필요한 경우
-public class GameManager : MonoSingleton<GameManager>
-{
-    // [SingletonOption(Persistent = true)] 로 DontDestroyOnLoad 제어
-    protected override void OnAwake()
-    {
-        // 초기화 코드
-    }
-}
-
-// 사용
-GameManager.Instance.StartGame();
-```
-
-### 3.2 ServiceLocator — 순수 C# 서비스 DI
-
-```csharp
-// MonoBehaviour와 독립된 서비스, 인터페이스 바인딩, 테스트 Mock 주입 시 사용
-// Bootstrap 씬에서 등록
-ServiceLocator.Register<ISaveProvider>(new JsonSaveProvider());
-ServiceLocator.Register<INetworkService>(new PlayFabNetworkService());
-
-// 사용처
-var save = ServiceLocator.Resolve<ISaveProvider>();
-save.Save(playerData);
-
-// 테스트 시 Mock 교체
-ServiceLocator.Register<ISaveProvider>(new MockSaveProvider());
-ServiceLocator.Clear(); // 테스트 후 정리
-```
-
-**주의**: 인터페이스 타입으로만 등록·조회 (구체 타입 바인딩 시 결합도 상승).
-`Resolve` 실패 시 `ServiceNotRegisteredException` 발생 — silent null 금지.
-
-### 3.3 CoroutineRunner — 전역 코루틴 관리
-
-```csharp
-// 키 기반 중복 제어, 일시정지·재시작 지원
-// MonoBehaviour 없이 코루틴 실행 가능
-
-// 시작 (키로 중복 방지)
-CoroutineRunner.Start("LoadData", LoadDataCoroutine());
-
-// 중지
-CoroutineRunner.Stop("LoadData");
-
-// 완료 시 자동 해제
-```
-
-### 3.4 Log — 중앙 로거
-
-```csharp
-// Debug.Log 직접 호출 금지 → Log 클래스 사용
-Log.Info("GameManager", "게임 시작");
-Log.Warn("DataManager", $"데이터 키 없음: {key}");
-Log.Error("ServerManager", "서버 연결 실패", exception);
-
-// 카테고리 필터링 → 빌드 변형별 로그 레벨 제어 가능
-```
-
-### 3.5 EventBus — 타입 안전 이벤트
-
-```csharp
-// 이벤트 정의 (struct 권장)
-public struct PlayerDiedEvent
-{
-    public int PlayerId;
-    public string Cause;
-}
-
-// 구독
-EventBus.Subscribe<PlayerDiedEvent>(OnPlayerDied);
-private void OnPlayerDied(PlayerDiedEvent e) { /* ... */ }
-
-// 발행
-EventBus.Publish(new PlayerDiedEvent { PlayerId = 1, Cause = "Fall" });
-
-// 구독 해제 (OnDestroy에서 반드시 해제)
-EventBus.Unsubscribe<PlayerDiedEvent>(OnPlayerDied);
-```
-
-**금지**: 문자열 키 이벤트 (`EventBus.Raw` 하위 특수 용도만 허용).
-
----
-
-## 4. 금지 사항
-
-| 금지 항목 | 사유 | 대안 |
-|-----------|------|------|
-| **수치 하드코딩** | 수정 시 코드 수정 필요, 기획-개발 분리 파괴 | DataTable 참조 (04_데이터_파이프라인 참조) |
-| **암호키 평문 하드코딩** | IL2CPP 빌드도 메모리 덤프로 추출 가능 (수상한잡화점 Critical) | 서버 측 키 관리 또는 런타임 유도 (02_기술스택 참조) |
-| **`Resources.Load` 남용** | 빌드 시 모든 Resources/ 포함 → 빌드 크기 증가 | Addressables |
-| **문자열 이벤트 키** | 컴파일 타임 검증 불가, 오타 런타임 버그 | `EventBus<TEvent>` 타입 이벤트 |
-| **`Find` / `FindWithTag` 게임 로직** | 씬 오브젝트 의존, 테스트 불가 | 직접 참조 or ServiceLocator |
-| **`My*` / `u*` 접두사** | 비표준, 가독성 저하 | 표준 네이밍 규칙(섹션 1) |
-| **`Assembly-CSharp` 단일 어셈블리** | 컴파일 시간 증가, 의존성 관리 불가 (수상한잡화점 교훈) | asmdef 분리 (01_아키텍처_설계 참조) |
-| **전역 네임스페이스** | 클래스명 충돌 위험 | `{ProjectNamespace}.*` 체계 |
-| **`Debug.Log` 직접 호출 (배포 코드)** | 릴리스 빌드 로그 노출 | `Log.Info/Warn/Error` |
-
----
-
-## 5. Git 커밋 메시지
-
-```
-{type}: {summary}
-
-[optional body]
-```
-
-| type | 용도 |
-|------|------|
-| `feat` | 신규 기능 추가 |
-| `fix` | 버그 수정 |
-| `refactor` | 기능 변경 없는 코드 구조 개선 |
-| `docs` | 문서 변경 |
-| `test` | 테스트 추가/수정 |
-| `chore` | 빌드·설정·의존성 변경 |
-| `data` | 데이터 테이블 변경 |
-
-**예시**:
-```
-feat: 전투 데미지 계산 서버 검증 구조 추가
-fix: DataTable 로딩 완료 확인 타이밍 버그 수정
-refactor: UIManager 씬 전환 로직 분리
-data: CardList 밸런스 조정 반영 (기획팀 승인)
-```
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. Framework 3축(MonoSingleton·ServiceLocator·EventBus) 패턴 정립 |
diff --git a/프로젝트/신규 프로젝트/개발/04_데이터_파이프라인.md b/프로젝트/신규 프로젝트/개발/04_데이터_파이프라인.md
deleted file mode 100644
index df85a20..0000000
--- a/프로젝트/신규 프로젝트/개발/04_데이터_파이프라인.md	
+++ /dev/null
@@ -1,219 +0,0 @@
-# {프로젝트명} — 데이터 파이프라인
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} 데이터 테이블 설계 및 로딩 구조
-
----
-
-## 1. SOT(Single Source of Truth) 정의
-
-| 항목 | 값 |
-|------|-----|
-| **SOT 포맷** | Excel (.xlsm 또는 .xlsx) |
-| **SOT 경로** | `{Unity프로젝트경로}/Assets/ResWork/Table/{프로젝트명}.xlsm` |
-| **변환 도구** | `{선택 예: Editor 스크립트(자동화 권장) / VBA 매크로 / Python 스크립트}` |
-| **런타임 포맷** | JSON (UTF-8) |
-| **JSON 경로** | `{Unity프로젝트경로}/Assets/ResWork/Table/Export/*.json` |
-| **경로 규칙** | 테이블명 = Excel 시트명 = JSON 파일명 = C# 클래스명 (대소문자 일치) |
-
-**SOT 규칙**:
-- Excel 파일이 유일한 SOT. JSON은 Export 결과물이며 직접 편집 금지
-- Excel 수정 후 Export 없이 Unity에 반영된 것처럼 처리하는 행위 금지 (C5 정직성)
-- 백업 파일(`{프로젝트명}_Ino.xlsm` 등)과 SOT를 혼동하지 않도록 파일명 규칙 명확화
-
----
-
-## 2. 파이프라인 흐름
-
-```
-[기획팀]                [개발팀]                     [런타임]
-Excel 편집
-    │
-    ▼
-Export Tool 실행
-(Editor 스크립트 권장)
-    │
-    ▼
-JSON 생성
-Assets/ResWork/Table/Export/*.json
-    │
-    ▼
-Unity AssetDatabase.Refresh()
-(에디터 자동 감지)
-    │
-    ▼
-Runtime DataTable Load
-(Awake: TextAsset → json string cache)
-(Start: JsonConvert.DeserializeObject → Dictionary)
-    │
-    ▼
-Memory Dictionary Cache
-O(1) 조회
-```
-
-**자동화 목표**: Excel 수정 → Export Tool 실행 → 반영까지 수동 단계 최소화.
-수상한잡화점 교훈: Export 단계가 수동이면 기획 수정 후 반영 누락이 발생함.
-
----
-
-## 3. DataTable 베이스 클래스 (BT.Framework 활용)
-
-```csharp
-// BurningTimes.Core.Data.DataTable 기반 — 직접 상속
-// 프로젝트별 테이블은 아래 패턴으로 구현
-
-using BurningTimes.Core.Data;
-using Newtonsoft.Json;
-
-namespace {ProjectNamespace}.Data
-{
-    // 테이블 행 데이터 클래스
-    public class CardTableData : TableDataBase
-    {
-        [JsonProperty("_ID")] public int Id;
-        [JsonProperty("_Name")] public string Name;
-        [JsonProperty("_Damage")] public int Damage;
-        // ... 각 컬럼 필드
-    }
-
-    // 테이블 매니저 클래스 (MonoSingleton + DataTable 조합)
-    public class CardTable : DataTable<CardTableData>
-    {
-        // Dictionary 인덱스 — 자주 쓰는 키 기준으로 추가 정의
-        private Dictionary<int, CardTableData> _byId;
-
-        protected override void BuildIndex(List<CardTableData> records)
-        {
-            _byId = records.ToDictionary(r => r.Id);
-        }
-
-        // 권장: _orNull 패턴 (KeyNotFoundException 방지)
-        public CardTableData GetByIdOrNull(int id)
-            => _byId.TryGetValue(id, out var data) ? data : null;
-    }
-}
-```
-
-**수상한잡화점 교훈 — 금지 패턴**:
-```csharp
-// 금지: Direct 인덱서 → 미등록 키 시 KeyNotFoundException 런타임 크래시
-public CardTableData Get(int id) => _byId[id]; // ❌
-
-// 권장: TryGet 또는 _orNull 패턴
-public CardTableData GetOrNull(int id)
-    => _byId.TryGetValue(id, out var data) ? data : null; // ✅
-```
-
----
-
-## 4. 로딩 전략
-
-| 시점 | 대상 테이블 | 방식 |
-|------|------------|------|
-| **앱 시작 (Bootstrap 씬)** | 핵심 공통 테이블 (GlobalValue, Localization 등) | 동기 전체 로딩 → `TableChecker.AllLoaded` 확인 후 진행 |
-| **씬 전환 시** | 해당 씬에서만 필요한 테이블 | 씬 로딩 중 비동기 로딩 |
-| **온디맨드** | 이벤트·대화 등 대용량·선택적 테이블 | 필요 시 Addressables 연동 로딩 |
-
-**초기화 라이프사이클 (수상한잡화점 패턴 계승)**:
-```csharp
-// Awake: JSON 문자열 캐시 + TextAsset 객체 언로드 (메모리 절약)
-private void Awake()
-{
-    _jsonCache = _textAsset.text;
-    Resources.UnloadAsset(_textAsset);
-}
-
-// Start: 역직렬화 + Dictionary 인덱스 구축
-private void Start()
-{
-    var records = JsonConvert.DeserializeObject<List<T>>(_jsonCache);
-    BuildIndex(records);
-    IsLoaded = true;
-}
-```
-
-**메모리 상주 정책**:
-- 전투 핫패스 테이블 (GlobalValue, CardList 등): 게임 실행 내내 상주
-- 씬 전용 테이블: 씬 Unload 시 해제
-- 로컬라이제이션 테이블: 언어 전환 시 재로딩
-
-**에디터 핫 리로드** (개발 편의):
-- Editor PlayMode에서 Excel Export 후 `AssetDatabase.Refresh()` → 자동 재로딩
-- 런타임 핫패치는 현재 미지원 (필요 시 별도 설계)
-
----
-
-## 5. 무결성 검증
-
-### 5.1 Export 시 자동 검증 (Export Tool에 내장)
-
-- FK 정합성: 참조 테이블의 ID 존재 여부 확인
-- null 체크: 필수 컬럼의 빈 값 감지
-- 범위 검증: 수치 컬럼의 최솟값·최댓값 범위 이탈 감지
-
-### 5.2 런타임 검증 (개발 빌드 전용)
-
-```csharp
-// 개발 빌드에서만 실행되는 검증 코드
-#if DEVELOPMENT_BUILD || UNITY_EDITOR
-DataValidator.ValidateAll();
-#endif
-```
-
-### 5.3 테이블 버전 메타
-
-```json
-{
-  "version": "1.0.3",
-  "exportedAt": "2026-04-16",
-  "records": [ ... ]
-}
-```
-
-JSON 헤더에 `version`/`exportedAt` 포함하여 롤백·동기화 추적 가능하게 한다.
-
----
-
-## 6. ⚠️ 시뮬레이터 이원화 방지
-
-> 런타임과 시뮬레이터/분석 도구가 **반드시 동일 데이터 소스**를 참조해야 한다.
-
-**금지 패턴**:
-- 기획팀 시뮬레이터가 Excel에서 직접 읽고, 런타임은 JSON을 읽는 구조 → 수치 불일치 발생
-- 시뮬레이터 전용 파싱 로직이 별도 존재 → SOT 분기
-
-**올바른 구조**:
-```
-Excel (SOT)
-    │
-    ├── Export → JSON (런타임 참조)
-    │               └── DataTable 로딩 → 게임 실행
-    │
-    └── Export → JSON (시뮬레이터 참조)  ← 동일 JSON 파일 공유
-                        └── 시뮬레이터/분석 도구
-```
-
-기획팀 밸런싱 시뮬레이터는 런타임 DataTable과 **동일한 JSON Export 파일**을 입력 소스로 사용한다.
-별도 파싱 로직이 필요하다면 런타임 DataTable 클래스를 직접 재사용하거나, 공통 파서 모듈을 분리한다.
-
----
-
-## 7. 리스크 및 개선 방향
-
-| 항목 | 위험 | 개선 방향 |
-|------|------|----------|
-| 수동 Export | 기획 수정 후 반영 누락 | Export 자동화 스크립트 + CI 통합 |
-| JSON 평문 저장 | APK 분해 시 테이블 노출 | 빌드 시 암호화 래퍼 또는 바이너리 포맷 검토 |
-| Direct 인덱서 | 미등록 키 시 런타임 크래시 | `_orNull` / `TryGet` 패턴 전수 적용 |
-| 핫패스 문자열 키 조회 | 모바일 GC/딕셔너리 조회 비용 | 상수 캐시 / enum 키 도입 |
-| 테이블 버전 메타 없음 | 롤백·동기화 추적 곤란 | JSON 헤더에 version/exportedAt 도입 (섹션 5.3) |
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. 수상한잡화점 데이터 파이프라인 패턴 + 시뮬레이터 이원화 방지 규칙 반영 |
diff --git a/프로젝트/신규 프로젝트/개발/05_빌드_배포.md b/프로젝트/신규 프로젝트/개발/05_빌드_배포.md
deleted file mode 100644
index 6f40221..0000000
--- a/프로젝트/신규 프로젝트/개발/05_빌드_배포.md	
+++ /dev/null
@@ -1,159 +0,0 @@
-# {프로젝트명} — 빌드 및 배포
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} 빌드·배포 전 과정
-
----
-
-## 1. 플랫폼별 빌드 설정
-
-### 1.1 Android
-
-| 항목 | 값 |
-|------|-----|
-| **Scripting Backend** | IL2CPP |
-| **Target Architecture** | ARM64 (필수), ARMv7 (선택 — 구형 기기 지원 시) |
-| **Minimum API Level** | Android 7.0 (API 24) 이상 권장 |
-| **Target API Level** | 최신 API (Play Store 정책 준수) |
-| **Internet Access** | Require |
-| **Custom Main Gradle Template** | 서드파티 요구 시 활성화 |
-| **Split APK / AAB** | 배포: AAB (Play Store), QA: APK |
-
-**빌드 전 체크**:
-- [ ] KeyStore 파일 경로·비밀번호 확인 (릴리스 빌드)
-- [ ] `AndroidManifest.xml` 권한 최소화 검토
-- [ ] ANR·크래시 없음 (에뮬레이터 + 실기기 모두)
-
-### 1.2 iOS
-
-| 항목 | 값 |
-|------|-----|
-| **Scripting Backend** | IL2CPP |
-| **Target SDK** | Device SDK (배포), Simulator SDK (에뮬레이터 테스트) |
-| **Minimum iOS Version** | 14.0 이상 권장 |
-| **Signing** | Xcode Automatic Signing (Provisioning Profile) |
-
-**빌드 전 체크**:
-- [ ] Apple 개발자 인증서·Provisioning Profile 유효기간 확인
-- [ ] `Info.plist` 권한 설명(NSPhotoLibraryUsageDescription 등) 입력
-- [ ] TestFlight 업로드 전 크래시 없음 확인
-
-### 1.3 Windows (Editor/Standalone)
-
-| 항목 | 값 |
-|------|-----|
-| **용도** | 개발 에디터 + Windows Standalone QA |
-| **Architecture** | x86_64 |
-| **Scripting Backend** | Mono (Editor), IL2CPP (Standalone 배포 시) |
-
----
-
-## 2. 빌드 변형(Build Variant)
-
-| 변형 | 로그 레벨 | 치트 | 용도 | 컴파일 심볼 |
-|------|----------|------|------|------------|
-| **Dev** | 전체 (Info+Warn+Error) | 활성 | 개발 중 디버깅 | `DEVELOPMENT_BUILD`, `ENABLE_CHEATS` |
-| **QA** | 일부 (Warn+Error) | 활성 | QA 배포, 버그 재현 | `QA_BUILD`, `ENABLE_CHEATS` |
-| **Release** | 최소 (Error만) | 비활성 | 스토어 제출 | (없음, 기본) |
-
-**컴파일 심볼 활용 예시**:
-```csharp
-#if ENABLE_CHEATS
-// 치트 메뉴, 수동 데이터 조작 코드
-#endif
-
-#if DEVELOPMENT_BUILD || UNITY_EDITOR
-// 개발/에디터 전용 검증 코드
-DataValidator.ValidateAll();
-#endif
-```
-
-**컴파일 심볼 관리**:
-- Player Settings > Other Settings > Scripting Define Symbols에서 설정
-- BT.Framework의 `BurningTimes.Editor.Symbols` 도구를 활용하여 변형별 심볼 일괄 전환
-
----
-
-## 3. 버전 관리
-
-**버전 체계**: `Major.Minor.Patch` (Semantic Versioning)
-
-| 구성 | 변경 기준 |
-|------|----------|
-| **Major** | 하위 호환 불가한 대규모 변경, 새 게임 모드 추가 등 |
-| **Minor** | 새 기능 추가, 컨텐츠 업데이트 |
-| **Patch** | 버그 수정, 밸런스 조정 |
-
-**빌드 넘버**: 각 빌드마다 자동 증가 (CI/CD 또는 Editor 스크립트로 자동화)
-
-```csharp
-// BurningTimes.Editor.Build 도구 연동 또는 직접 구현
-// PlayerSettings.bundleVersion = "1.2.3"
-// PlayerSettings.Android.bundleVersionCode = 123  (Major*10000 + Minor*100 + Patch 권장)
-```
-
-**스토어 정책**:
-- Android: `bundleVersionCode` 는 항상 단조 증가 (롤백 불가)
-- iOS: `Build Number` 항상 단조 증가
-
----
-
-## 4. 배포 파이프라인
-
-```
-[개발팀] 빌드 생성
-    │
-    ▼
-코드 서명 (KeyStore / Apple Certificate)
-    │
-    ▼
-업로드
-├── Dev/QA → Firebase App Distribution / TestFlight / 사내 공유
-└── Release → Google Play Console / App Store Connect
-    │
-    ▼
-배포 완료 → 공유/일일보고 or PD 지시 로그 기록 (C13·P19)
-```
-
-**자동화 목표**:
-- 빌드 트리거: Git 태그 push 또는 수동 트리거
-- 업로드 자동화: `{선택 예: fastlane / GitHub Actions / Jenkins}`
-- 배포 알림: 팀 내 채널 공유
-
----
-
-## 5. 스토어 제출 체크리스트
-
-### 5.1 공통 (Android / iOS 공통)
-
-- [ ] **Release 빌드 변형** 으로 빌드 (ENABLE_CHEATS 없음 확인)
-- [ ] **빌드 번호** 이전 버전보다 증가했는지 확인
-- [ ] **콘솔 에러 없음** (P14: Unity 콘솔 에러 잔존 상태 배포 금지)
-- [ ] **크래시 없음** (실기기 최소 1대 이상 검증)
-- [ ] **IAP 영수증 서버 검증** 정상 동작 확인 (수상한잡화점 Critical 교훈)
-- [ ] **AES 키 하드코딩 없음** 확인 (소스 검색: `02_기술스택_결정 섹션 3.2 참조`)
-- [ ] **개발용 씬(`9x_Tool_*`) Build Settings에서 제외** 확인
-- [ ] **권한 요청** 최소화 및 사유 명시 (`Info.plist` / `AndroidManifest.xml`)
-- [ ] **개인정보처리방침 URL** 스토어 등록 완료
-
-### 5.2 Android 추가
-
-- [ ] **AAB 포맷** 제출 (APK 아님)
-- [ ] **Target API Level** Play Store 현행 정책 충족
-- [ ] **64-bit 지원** (ARM64 포함 빌드)
-
-### 5.3 iOS 추가
-
-- [ ] **TestFlight** 에서 베타 검증 완료
-- [ ] **Provisioning Profile** 유효기간 충분히 남음
-- [ ] **앱 심사 노트** 작성 (특수 기능 있는 경우)
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. 수상한잡화점 Critical 3건 체크리스트 반영 |
diff --git a/프로젝트/신규 프로젝트/개발/06_QA_테스트_전략.md b/프로젝트/신규 프로젝트/개발/06_QA_테스트_전략.md
deleted file mode 100644
index 4f77ff7..0000000
--- a/프로젝트/신규 프로젝트/개발/06_QA_테스트_전략.md	
+++ /dev/null
@@ -1,213 +0,0 @@
-# {프로젝트명} — QA 테스트 전략
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: {프로젝트명} 전 테스트 계층
-
----
-
-## 1. 테스트 레이어
-
-### 1.1 Unit Test — EditMode
-
-> BT.Framework 자체 테스트와 동일 패턴 적용.
-
-| 대상 | 예시 | 실행 모드 |
-|------|------|----------|
-| `ServiceLocator` | Register/Resolve/Clear 동작 | EditMode |
-| `Log` | 카테고리 필터링, 로그 레벨 분기 | EditMode |
-| DataTable 파싱 | JSON 역직렬화, null/범위 검증 | EditMode |
-| 순수 C# 비즈니스 로직 | 대미지 계산 공식, 확률 계산 | EditMode |
-
-```csharp
-// EditMode 테스트 예시
-[TestFixture]
-public class ServiceLocatorTests
-{
-    [SetUp]
-    public void SetUp() => ServiceLocator.Clear();
-
-    [Test]
-    public void Register_And_Resolve_ReturnsCorrectService()
-    {
-        var mock = new MockSaveProvider();
-        ServiceLocator.Register<ISaveProvider>(mock);
-
-        var resolved = ServiceLocator.Resolve<ISaveProvider>();
-
-        Assert.AreEqual(mock, resolved);
-    }
-}
-```
-
-### 1.2 Unit Test — PlayMode
-
-| 대상 | 예시 | 실행 모드 |
-|------|------|----------|
-| `MonoSingleton<T>` | Instance 생성, Persistent 동작 | PlayMode |
-| `CoroutineRunner` | Start/Stop, 키 중복 방지 | PlayMode |
-| UI View 전환 | UIManager Push/Pop 동작 | PlayMode |
-| 씬 로딩 | Bootstrap → Title 씬 전환 | PlayMode |
-
-### 1.3 Integration Test
-
-| 대상 | 내용 |
-|------|------|
-| DataTable 전체 로딩 | Bootstrap 씬 진입 → TableChecker.AllLoaded 확인 |
-| 서버 연동 E2E | 로그인 → 데이터 로딩 → 저장 → 재로그인 후 복원 |
-| 핵심 게임 루프 | {장르} 핵심 액션 1회 플레이 성공 (크래시·콘솔 에러 없음) |
-
-### 1.4 Data Validation
-
-DataTable의 무결성을 Export 시 + 런타임(개발 빌드) 에서 이중 검증한다.
-
-```csharp
-// 04_데이터_파이프라인 섹션 5 참조
-#if DEVELOPMENT_BUILD || UNITY_EDITOR
-DataValidator.ValidateAll(); // FK 정합성, null, 범위
-#endif
-```
-
-### 1.5 Manual QA
-
-수동 QA는 5축 체크리스트(섹션 3)에 따라 수행한다.
-자동화 범위를 초과하는 UX 검증·디바이스 다양성·성능 체감은 수동 QA 영역이다.
-
----
-
-## 2. 테스트 네이밍
-
-> BT.Framework 테스트와 동일한 패턴 적용.
-
-```
-{Method}_{Condition}_{Expected}
-```
-
-| 구성 | 설명 | 예시 |
-|------|------|------|
-| `{Method}` | 테스트 대상 메서드/동작 | `TakeDamage` |
-| `{Condition}` | 입력 조건 | `WithMaxShield` |
-| `{Expected}` | 기대 결과 | `ReducesShieldFirst` |
-
-**전체 예시**:
-```csharp
-[Test] public void TakeDamage_WithMaxShield_ReducesShieldFirst() { }
-[Test] public void TakeDamage_WhenHpIsZero_TriggersDeathEvent() { }
-[Test] public void GetOrNull_WithUnknownId_ReturnsNull() { }
-[Test] public void ServiceLocator_Resolve_WhenNotRegistered_ThrowsException() { }
-```
-
----
-
-## 3. QA 체크리스트 프레임 (5축)
-
-각 기능 머지 전 해당 5축 중 적용 항목을 확인한다 (P14 QA 게이트).
-
-### 3.1 기능(Functional)
-
-- [ ] 핵심 게임 루프 정상 동작 ({장르} 핵심 액션)
-- [ ] DataTable 로딩 완료 후 진행 (TableChecker.AllLoaded)
-- [ ] UI 전환 정상 동작 (화면맵 경로별)
-- [ ] 저장/로드 복원 일치
-- [ ] 서버 인증 정상 처리
-- [ ] 엣지 케이스: 재화 0, 최대치, 연속 탭 등
-
-### 3.2 성능(Performance)
-
-- [ ] 초기 로딩 체감 (Bootstrap → 첫 플레이 가능 시점)
-- [ ] 인게임 FPS 안정성 (목표 프레임 유지)
-- [ ] 메모리 증가 없음 (Profiler 확인)
-- [ ] GC Alloc 핫패스 없음 (Profiler Deep Profile)
-
-### 3.3 메모리(Memory)
-
-- [ ] 씬 전환 시 메모리 해제 확인 (Addressables Release)
-- [ ] 장시간 플레이 메모리 누수 없음
-- [ ] TextAsset 언로드 확인 (DataTable Awake 패턴)
-
-### 3.4 네트워크(Network)
-
-- [ ] 오프라인 상태 진입 처리 (에러 메시지 + 복구 흐름)
-- [ ] 느린 네트워크(3G 상당) 타임아웃 처리
-- [ ] 재연결 후 상태 복원
-- [ ] IAP 영수증 서버 검증 정상 처리 (해당 프로젝트)
-
-### 3.5 보안(Security)
-
-- [ ] 빌드에 하드코딩 키 없음 (`02_기술스택_결정 섹션 3.2`)
-- [ ] IAP 클라이언트 단독 결제 처리 경로 없음
-- [ ] SpeedHack/TimeCheck Detector 동작 확인 (해당 프로젝트)
-- [ ] 개발용 씬/치트 코드 릴리스 빌드에서 제거 확인
-
----
-
-## 4. 자동화 범위
-
-### 4.1 Framework 테스트 (기구현)
-
-BT.Framework 패키지에 포함된 테스트. 프로젝트 도입 시 자동으로 사용 가능.
-
-| 영역 | 테스트 유형 | 위치 |
-|------|-----------|------|
-| `MonoSingleton<T>` | PlayMode | `BT.Framework.Tests` |
-| `ServiceLocator` | EditMode | `BT.Framework.Tests` |
-| `CoroutineRunner` | PlayMode | `BT.Framework.Tests` |
-| `EventBus` | EditMode | `BT.Framework.Tests` |
-| `Log` | EditMode | `BT.Framework.Tests` |
-| `DataTable` 파싱 | EditMode | `BT.Framework.Tests` |
-
-### 4.2 프로젝트 테스트 (프로젝트에서 추가)
-
-| asmdef | 위치 | 내용 |
-|--------|------|------|
-| `{ProjectNamespace}.Tests` | `Assets/Tests/Runtime/` | PlayMode 통합 테스트 |
-| `{ProjectNamespace}.EditorTests` | `Assets/Tests/Editor/` | EditMode 단위 테스트 |
-
-**asmdef 설정 예시**:
-```json
-// {ProjectNamespace}.Tests.asmdef
-{
-    "name": "{ProjectNamespace}.Tests",
-    "references": [
-        "BT.Framework.Tests",
-        "{ProjectNamespace}.Core",
-        "UnityEngine.TestRunner",
-        "UnityEditor.TestRunner"
-    ],
-    "includePlatforms": [],
-    "excludePlatforms": [],
-    "allowUnsafeCode": false,
-    "testPlatforms": ["PlayMode"]
-}
-```
-
-### 4.3 CI 자동화 실행 (해당 시)
-
-```
-Git push → CI 트리거
-    └── Unity Test Runner (EditMode + PlayMode)
-    └── 결과 리포트 → 실패 시 머지 차단
-```
-
----
-
-## 5. 버그 관리
-
-| 심각도 | 기준 | 처리 |
-|--------|------|------|
-| **P0 Critical** | 크래시, 결제 실패, 데이터 손실 | 즉시 수정 (C2 근원 해결) |
-| **P1 High** | 핵심 기능 불가, 보안 이슈 | 현 개발 단계 완료 전 수정 |
-| **P2 Medium** | 기능 이상, 표시 오류 | 다음 개발 단계 전 수정 |
-| **P3 Low** | 미관, 텍스트 오탈자 | 여유 시 수정 |
-
-**규칙**: P14에 따라 Unity 빌드 에러·콘솔 에러 잔존 상태로 작업 종료 금지.
-버그 수정 시 동일 경로의 회귀 검증 포함.
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. Framework 테스트 패턴 + 5축 QA 체크리스트 정립 |
diff --git a/프로젝트/신규 프로젝트/관리/Unity_셋업_가이드.md b/프로젝트/신규 프로젝트/관리/Unity_셋업_가이드.md
deleted file mode 100644
index 243c8e4..0000000
--- a/프로젝트/신규 프로젝트/관리/Unity_셋업_가이드.md	
+++ /dev/null
@@ -1,308 +0,0 @@
-# {프로젝트명} — Unity 셋업 가이드
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장
-> **적용 범위**: 신규 PC에서 {프로젝트명} Unity 개발 환경 구축 + BT.Framework 연동
-
----
-
-## 1. Unity 프로젝트 생성
-
-### 1.1 Unity 버전
-
-- **필수**: Unity 6000.0.x 이상 (Unity 6 LTS)
-- Unity Hub에서 `6000.0.x` 버전 설치 확인
-- 하위 버전 사용 시 개발팀장 확인 필수 (BT.Framework 호환성 보장 범위)
-
-### 1.2 렌더 파이프라인 선택
-
-| 선택지 | 권장 상황 |
-|--------|----------|
-| **URP (Universal Render Pipeline)** | 모바일 최적화, 셰이더 커스터마이즈 필요 시 (권장 기본값) |
-| **Built-in** | 서드파티 셰이더·플러그인이 URP 미지원인 경우 |
-
-결정 후 `개발/01_아키텍처_설계.md 섹션 1`에 기록.
-
-### 1.3 프로젝트 경로 규칙
-
-```
-D:\BurningTimes\{프로젝트명}\        ← Unity 프로젝트 루트
-D:\BurningTimes\BurningTimesAi\         ← 조직 레포 (별도)
-D:\BurningTimes\BT.Framework\ ← Framework 레포 (로컬 개발용, 선택)
-```
-
-**경로 규칙**:
-- 경로에 공백 금지 (Unity 빌드 도구 호환성)
-- 한글 경로 금지 (Android/iOS 빌드 오류 원인)
-
----
-
-## 2. BT.Framework 연동 (C+H1)
-
-> **배포 방식**: C+H1 — UPM Git URL (원격 기본) + 로컬 file: 오버라이드 (개발용)
-> **근거**: 03_배포방식_안건_v1.md — 목표 1·2·3 세 축 모두 최우위
-
-### 2.1 기본 (원격 — 모든 PC)
-
-`Packages/manifest.json` 에 다음 항목 추가:
-
-```json
-{
-  "dependencies": {
-    "com.nerdnavis.framework": "https://burning.i234.me/BurningTimes/BT.Framework.git#v0.x.y",
-    "com.unity.addressables": "2.4.4",
-    "com.unity.nuget.newtonsoft-json": "3.2.1",
-    ...
-  }
-}
-```
-
-- `#v0.x.y` 부분을 실제 사용할 Framework 버전 태그로 교체 (예: `#v0.1.0`)
-- **브랜치 추적(`#main`) 금지** — 재현성 보장을 위해 반드시 태그 또는 커밋 SHA 고정
-
-### 2.2 개발용 (로컬 오버라이드 — Framework 동시 개발 시만)
-
-Framework 코드를 동시에 수정해야 하는 경우 로컬 경로로 오버라이드:
-
-```json
-{
-  "dependencies": {
-    "com.nerdnavis.framework": "file:../../BT.Framework"
-  }
-}
-```
-
-> ⚠️ **로컬 오버라이드 커밋 금지**: 이 상태로 `manifest.json`을 커밋하면 다른 PC에서 빌드 실패.
-> 로컬 개발 완료 후 반드시 원격 URL로 복원 후 커밋.
-
-**`.gitignore`에 추가 권장**:
-```
-# 로컬 manifest 오버라이드 (있는 경우)
-Packages/manifest.local.json
-```
-
-### 2.3 Git 인증 (사내 Gitea)
-
-Windows Credential Manager에 인증 정보 등록 (최초 1회):
-```
-git credential-manager configure
-# 또는 직접 입력 후 캐싱
-git clone https://burning.i234.me/BurningTimes/BT.Framework.git
-```
-
-Package Manager가 자동으로 Windows Credential Manager를 사용하여 인증.
-
----
-
-## 3. 프로젝트 설정
-
-### 3.1 Player Settings
-
-| 항목 | 값 |
-|------|-----|
-| **Company Name** | BurningTimes |
-| **Product Name** | {프로젝트명} |
-| **Bundle Identifier** | `com.nerdnavis.{프로젝트명소문자}` |
-| **Scripting Backend** | IL2CPP |
-| **API Compatibility Level** | .NET Standard 2.1 |
-| **Managed Stripping Level** | Minimal (개발), High (릴리스) |
-
-### 3.2 필수 패키지 (Package Manager)
-
-| 패키지 | 버전 | 용도 |
-|--------|------|------|
-| `com.unity.addressables` | 2.x 최신 | 리소스 번들 |
-| `com.unity.nuget.newtonsoft-json` | 3.x | JSON 직렬화 (DataTable) |
-| `com.unity.render-pipelines.universal` | 17.x | URP (선택한 경우) |
-| `com.unity.textmeshpro` | (번들 포함) | UI 텍스트 |
-
-### 3.3 Quality Settings
-
-- 모바일 타겟은 Quality Level을 "Medium" 이하로 시작 (실기기 테스트 후 조정)
-
----
-
-## 4. Git 설정
-
-### 4.1 .gitignore (Unity 표준)
-
-프로젝트 루트에 `.gitignore` 생성:
-
-```gitignore
-# Unity 생성 폴더
-[Ll]ibrary/
-[Tt]emp/
-[Oo]bj/
-[Bb]uild/
-[Bb]uilds/
-[Ll]ogs/
-[Mm]emoryCaptures/
-[Rr]ecordings/
-
-# Unity Asset Database
-*.pidb.meta
-*.pdb.meta
-*.mdb.meta
-
-# Unity 자동 생성 파일
-sysinfo.txt
-*.apk
-*.aab
-*.unitypackage
-*.app
-
-# Visual Studio
-.vs/
-*.csproj
-*.sln
-*.suo
-*.tmp
-*.user
-*.userprefs
-*.pidb
-
-# Rider
-.idea/
-
-# OS 메타
-.DS_Store
-Thumbs.db
-
-# BurningTimes 로컬 설정
-Packages/manifest.local.json
-```
-
-### 4.2 .gitattributes (LFS)
-
-대용량 바이너리 파일 LFS 관리:
-
-```gitattributes
-# Unity
-*.meta merge=unityyamlmerge eol=lf
-*.unity merge=unityyamlmerge eol=lf
-*.prefab merge=unityyamlmerge eol=lf
-*.asset merge=unityyamlmerge eol=lf
-*.mat merge=unityyamlmerge eol=lf
-*.controller merge=unityyamlmerge eol=lf
-
-# LFS — 바이너리 에셋
-*.png filter=lfs diff=lfs merge=lfs -text
-*.jpg filter=lfs diff=lfs merge=lfs -text
-*.jpeg filter=lfs diff=lfs merge=lfs -text
-*.psd filter=lfs diff=lfs merge=lfs -text
-*.wav filter=lfs diff=lfs merge=lfs -text
-*.mp3 filter=lfs diff=lfs merge=lfs -text
-*.ogg filter=lfs diff=lfs merge=lfs -text
-*.fbx filter=lfs diff=lfs merge=lfs -text
-*.anim filter=lfs diff=lfs merge=lfs -text
-*.mp4 filter=lfs diff=lfs merge=lfs -text
-*.xlsm filter=lfs diff=lfs merge=lfs -text
-*.xlsx filter=lfs diff=lfs merge=lfs -text
-```
-
-**LFS 초기화** (최초 1회):
-```bash
-git lfs install
-git lfs track "*.png" "*.jpg" "*.wav" "*.mp3" "*.fbx" "*.psd"
-```
-
----
-
-## 5. 기본 코드 구조
-
-### 5.1 Bootstrap 씬 구성
-
-```
-00_Bootstrap.unity
-└── [Bootstrap] (GameObject)
-    ├── GameManager (MonoSingleton<GameManager>)
-    ├── DataManager (MonoSingleton<DataManager>)
-    ├── UIManager (MonoSingleton<UIManager>)
-    └── ServiceLocatorBootstrap (MonoBehaviour)
-        └── Awake()에서 ServiceLocator.Register<ISaveProvider>(...)
-```
-
-### 5.2 asmdef 4개 생성
-
-각 디렉토리에 asmdef 파일 생성:
-
-```
-Assets/Scripts/{ProjectNamespace}/Core/{ProjectNamespace}.Core.asmdef
-Assets/Scripts/{ProjectNamespace}/UI/{ProjectNamespace}.UI.asmdef
-Assets/Scripts/{ProjectNamespace}/Data/{ProjectNamespace}.Data.asmdef
-Assets/Scripts/{ProjectNamespace}/Editor/{ProjectNamespace}.Editor.asmdef
-```
-
-**Core asmdef 예시** (`{ProjectNamespace}.Core.asmdef`):
-```json
-{
-    "name": "{ProjectNamespace}.Core",
-    "references": [
-        "BT.Framework.Runtime"
-    ],
-    "includePlatforms": [],
-    "excludePlatforms": [],
-    "allowUnsafeCode": false
-}
-```
-
-**Editor asmdef 예시** (`{ProjectNamespace}.Editor.asmdef`):
-```json
-{
-    "name": "{ProjectNamespace}.Editor",
-    "references": [
-        "{ProjectNamespace}.Core",
-        "BT.Framework.Runtime",
-        "BT.Framework.Editor"
-    ],
-    "includePlatforms": ["Editor"],
-    "excludePlatforms": []
-}
-```
-
-### 5.3 GameManager 기본 구현
-
-```csharp
-using BurningTimes.Core.Patterns;
-
-namespace {ProjectNamespace}.Core
-{
-    public class GameManager : MonoSingleton<GameManager>
-    {
-        protected override void OnAwake()
-        {
-            Log.Info("GameManager", "초기화 시작");
-            // 초기화 코드
-        }
-    }
-}
-```
-
----
-
-## 6. 셋업 검증 (6항 — 전체 통과 필수)
-
-> **Phase 2 완료 기준**: 아래 6항 모두 체크 완료.
-> 하나라도 실패 시 원인 해결 후 재검증.
-
-- [ ] **1. Framework 패키지 참조 확인** — Package Manager 창에서 `BurningTimes Framework` 표시됨
-- [ ] **2. 컴파일 오류 없음** — 콘솔 에러 0건 (경고는 검토 후 판단)
-- [ ] **3. Bootstrap 씬 Play → 콘솔 에러 없음** — Play 후 Console 확인
-- [ ] **4. MonoSingleton 인스턴스 생성 테스트** — `GameManager.Instance != null` 확인
-- [ ] **5. ServiceLocator Register/Resolve 테스트**
-  ```csharp
-  // 테스트 코드 (에디터 또는 Unity Test Runner)
-  ServiceLocator.Register<ISaveProvider>(new JsonSaveProvider());
-  var resolved = ServiceLocator.Resolve<ISaveProvider>();
-  Debug.Assert(resolved != null);
-  ```
-- [ ] **6. Log.Info/Log.Warn 출력 테스트** — 콘솔에 로그 출력 확인
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. C+H1 배포 방식 + 셋업 검증 6항 정립 |
diff --git a/프로젝트/신규 프로젝트/관리/프로젝트_시작_체크리스트.md b/프로젝트/신규 프로젝트/관리/프로젝트_시작_체크리스트.md
deleted file mode 100644
index 56b02c8..0000000
--- a/프로젝트/신규 프로젝트/관리/프로젝트_시작_체크리스트.md	
+++ /dev/null
@@ -1,217 +0,0 @@
-# {프로젝트명} — 프로젝트 시작 체크리스트
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 개발팀장 + 기획팀장
-> **용도**: 신규 프로젝트 착수 시 Phase 0~5를 순서대로 진행한다.
-
----
-
-## Phase 개요
-
-| Phase | 이름 | 완료 기준 |
-|-------|------|----------|
-| **Phase 0** | 프로젝트 생성 | 디렉토리 구조 + Git 초기화 완료 |
-| **Phase 1** | 핵심 기획 | `02_핵심_재미_정의.md` PD님 승인 |
-| **Phase 2** | 개발 환경 구축 | Framework 셋업 검증 6항 전체 통과 |
-| **Phase 3** | 데이터 기반 구성 | 데이터 1건 end-to-end 로드 성공 |
-| **Phase 4** | 프로토타입 | PD님 재미 확인 |
-| **Phase 5** | 본 개발 준비 | 전체 기반 완비 + PD님 최종 리뷰 |
-
-> **C7 게이트**: `Phase 1`의 `02_핵심_재미_정의.md` PD님 승인 완료 전 `Phase 2~5` 착수 금지.
-> 재미 정의 없는 개발 환경 구축은 방향 없는 투자다.
-
----
-
-## Phase 0: 프로젝트 생성
-
-**완료 기준**: 디렉토리 구조 + Git 초기화 완료
-
-### 0.1 템플릿 복사 및 치환
-
-- [ ] `프로젝트/_템플릿/` 을 `프로젝트/{프로젝트명}/` 으로 복사
-- [ ] 모든 문서의 placeholder 치환:
-  - `{프로젝트명}` → 실제 프로젝트명
-  - `{ProjectNamespace}` → Unity 네임스페이스 (예: `MagicShop`)
-  - `{장르}` → 게임 장르 (예: `로그라이크 덱빌딩`)
-  - `{날짜}` → 작성일 (YYYY-MM-DD 형식)
-- [ ] 불필요한 섹션 삭제 (C14 토큰 최소화)
-
-### 0.2 Git 레포 생성
-
-- [ ] Gitea에 신규 레포 생성 (`BurningTimes/{프로젝트명}`)
-- [ ] 로컬 초기화: `git init && git remote add origin {레포 URL}`
-- [ ] `.gitignore` Unity 표준 템플릿 적용 (`관리/Unity_셋업_가이드.md 섹션 4`)
-- [ ] `.gitattributes` LFS 설정 적용 (`관리/Unity_셋업_가이드.md 섹션 4`)
-- [ ] 초기 커밋 + push (브랜치: `main`)
-
-### 0.3 PD 지시 로그 초기화
-
-- [ ] `공유/PD_지시_트래킹/{프로젝트명}_PD_지시_로그.md` 생성 (P19)
-- [ ] `공유/대화로그/{프로젝트명}/` 디렉토리 생성 (P24)
-
----
-
-## Phase 1: 핵심 기획
-
-**완료 기준**: `02_핵심_재미_정의.md` PD님 승인
-
-> ⚠️ **C7 게이트**: 02번 PD님 승인 전 Phase 2 착수 금지.
-
-### 1.1 게임 컨셉 수립
-
-- [ ] `기획/01_게임_컨셉.md` 작성 (기획팀장)
-  - 한 줄 컨셉 (Elevator Pitch)
-  - 레퍼런스 타이틀 3개 이상
-  - 타겟 유저 정의
-- [ ] PD님 검토 후 방향 확정
-
-### 1.2 핵심 재미 정의 (C7 게이트)
-
-- [ ] `기획/02_핵심_재미_정의.md` 작성 (기획팀장)
-  - "어떤 재미를 제공하는가" 명문화 (C7: 재미 정의 없는 진행 금지)
-  - 핵심 게임 루프 다이어그램
-  - 재미 검증 방법 (프로토타입 평가 기준)
-- [ ] **PD님 승인 획득** ← Phase 2 착수 조건
-
-### 1.3 시스템·UX 초안
-
-- [ ] `기획/03_시스템_카탈로그.md` 작성 (기획팀장) — 시스템 목록·우선순위
-- [ ] `기획/06_UX_화면맵.md` 작성 (기획팀장) — 화면 구성 초안
-
----
-
-## Phase 2: 개발 환경 구축
-
-**완료 기준**: `관리/Unity_셋업_가이드.md` 셋업 검증 6항 전체 통과
-
-> Phase 1 완료(PD님 승인) 후 착수.
-
-### 2.1 Unity 프로젝트 생성
-
-- [ ] Unity 6000.0.x 이상으로 신규 프로젝트 생성
-- [ ] 렌더 파이프라인 확정 (URP / Built-in)
-- [ ] 프로젝트 경로: `D:\BurningTimes\{프로젝트명}\`
-- [ ] `관리/Unity_셋업_가이드.md` 섹션 1 전체 수행
-
-### 2.2 BT.Framework 연동
-
-- [ ] `Packages/manifest.json` 에 Framework 항목 추가
-- [ ] `관리/Unity_셋업_가이드.md` 섹션 2 (C+H1) 수행
-- [ ] Package Manager에서 Import 확인
-
-### 2.3 기술 문서 작성
-
-- [ ] `개발/01_아키텍처_설계.md` — placeholder 치환 + 확정 항목 채우기
-- [ ] `개발/02_기술스택_결정.md` — 보안 체크리스트 3항 설계 결정 기입
-- [ ] `개발/03_코딩_컨벤션.md` — 팀 합의 후 확정
-
-### 2.4 기본 코드 구조 생성
-
-- [ ] Bootstrap 씬 생성 (`00_Bootstrap.unity`)
-- [ ] asmdef 4개 생성 (`{ProjectNamespace}.Core/.UI/.Data/.Editor`)
-- [ ] `GameManager` (MonoSingleton<T>) 기본 구현
-- [ ] `ServiceLocator` Bootstrap 등록 코드 작성
-
-### 2.5 셋업 검증 (6항 전체 통과 필수)
-
-- [ ] Framework 패키지 참조 확인 (Package Manager 창)
-- [ ] 컴파일 에러 없음
-- [ ] Bootstrap 씬 Play → 콘솔 에러 없음
-- [ ] MonoSingleton 인스턴스 생성 테스트 통과
-- [ ] ServiceLocator Register/Resolve 테스트 통과
-- [ ] Log.Info/Log.Warn 출력 테스트 통과
-
----
-
-## Phase 3: 데이터 기반 구성
-
-**완료 기준**: 데이터 1건 end-to-end 로드 성공 (Excel → JSON → Unity 런타임)
-
-> Phase 2 완료 후 착수.
-
-### 3.1 컨텐츠 테이블 목록 확정
-
-- [ ] `기획/04_컨텐츠.md` — 필요한 데이터 테이블 목록 초안 (기획팀장)
-- [ ] 개발팀장과 테이블 구조 합의
-
-### 3.2 데이터 파이프라인 구성
-
-- [ ] `개발/04_데이터_파이프라인.md` — SOT 포맷·경로·파싱 방식 확정
-- [ ] Excel 파일 생성 (SOT)
-- [ ] Export Tool 구현 또는 선택
-- [ ] JSON Export 경로 확정 (`Assets/ResWork/Table/Export/`)
-
-### 3.3 DataTable 클래스 구현
-
-- [ ] 첫 번째 테이블 `{TableName}TableData` + `{TableName}Table` 구현
-- [ ] `_orNull` 패턴 적용 확인 (Direct 인덱서 금지)
-
-### 3.4 E2E 검증
-
-- [ ] Excel 편집 → Export → Unity Play → DataTable.IsLoaded = true 확인
-- [ ] 테이블 데이터 1건 조회 성공
-- [ ] 데이터 무결성 검증 통과 (`DataValidator.ValidateAll()`)
-
----
-
-## Phase 4: 프로토타입
-
-**완료 기준**: PD님 재미 확인
-
-> Phase 3 완료 후 착수.
-
-### 4.1 핵심 게임 루프 구현
-
-- [ ] `02_핵심_재미_정의.md` 기반 핵심 인터랙션 1사이클 구현
-- [ ] 데이터 테이블 연동 (하드코딩 수치 사용 금지)
-- [ ] 기본 UI 연결 (UX 화면맵 초안 기반)
-
-### 4.2 재미 검증
-
-- [ ] 내부 플레이 테스트
-- [ ] `02_핵심_재미_정의.md`의 검증 기준 항목 대조 평가
-- [ ] **PD님 리뷰 + 재미 확인** ← Phase 5 착수 조건
-
-### 4.3 밸런스 앵커 설정
-
-- [ ] `기획/05_밸런스.md` — 핵심 수치 앵커 정의 (기획팀장)
-- [ ] 개발팀과 밸런스 데이터 테이블 연동 확인
-
----
-
-## Phase 5: 본 개발 준비
-
-**완료 기준**: 전체 기반 완비 + PD님 최종 리뷰
-
-> Phase 4 완료(PD님 재미 확인) 후 착수.
-
-### 5.1 나머지 기획 문서 완성
-
-- [ ] `기획/07_수익화.md` — 수익 모델 (PD님 확인 필요)
-- [ ] `기획/08_라이브.md` — 서비스·운영 계획 초안
-
-### 5.2 개발 기반 문서 완성
-
-- [ ] `개발/05_빌드_배포.md` — 배포 파이프라인 확정
-- [ ] `개발/06_QA_테스트_전략.md` — QA 게이트 기준 확정
-
-### 5.3 보안 항목 완료
-
-- [ ] `개발/02_기술스택_결정.md` 보안 체크리스트 3항 모두 설계 완료
-- [ ] IAP 서버 검증 구조 구현 또는 계획 확정
-- [ ] AES 키 서버 관리 방식 확정
-
-### 5.4 PD님 최종 리뷰
-
-- [ ] 전체 기획 문서 요약 보고
-- [ ] 기술 스택·보안 결정 사항 보고
-- [ ] **PD님 최종 승인** → 본 개발 착수
-
----
-
-## 변경 이력
-
-| 버전 | 일자 | 작성자 | 내용 |
-|------|------|--------|------|
-| v1 | {날짜} | 개발팀장 | 템플릿 초안. Phase 0~5 체크리스트 + C7 게이트 반영 |
diff --git a/프로젝트/신규 프로젝트/기획/01_게임_컨셉.md b/프로젝트/신규 프로젝트/기획/01_게임_컨셉.md
deleted file mode 100644
index f7461d3..0000000
--- a/프로젝트/신규 프로젝트/기획/01_게임_컨셉.md	
+++ /dev/null
@@ -1,60 +0,0 @@
-# {프로젝트명} — 게임 컨셉
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
-
----
-
-## 1. 한 줄 요약
-
-> {1문장으로 프로젝트 정체성 서술. 예: "X 장르에서 Y 메커니즘으로 Z 감정을 전달하는 게임"}
-
----
-
-## 2. 기본 정보
-
-| 항목 | 값 |
-|------|-----|
-| **장르** | {장르} |
-| **타겟 플랫폼** | {Android / iOS / PC / 크로스플랫폼} |
-| **세션 길이** | {N분 ~ N분} |
-| **타겟 유저** | {코어 / 미드코어 / 캐주얼} + {특성 서술} |
-| **레퍼런스 게임** | {게임명} — {참조하는 구체적 요소 명시} |
-
----
-
-## 3. 핵심 게임 루프
-
-```
-{행동} → {결과/피드백} → {보상} → {성장/변화} → 반복
-```
-
-> 각 화살표는 유저가 체감하는 "다음 행동을 하고 싶은 이유"와 연결되어야 한다.
-
-| 단계 | 유저 행동 | 시스템 반응 | 유저가 얻는 것 |
-|------|----------|------------|--------------|
-| 1 | {행동 서술} | {반응 서술} | {획득/감정} |
-| 2 | {행동 서술} | {반응 서술} | {획득/감정} |
-| 3 | {행동 서술} | {반응 서술} | {획득/감정} |
-
----
-
-## 4. 차별점
-
-> 시장 경쟁 대비 이 게임만의 고유 가치. "~와 비슷하지만 ~가 다르다" 형식 권장.
-
-1. {차별점 1}: {경쟁작 대비 어떻게 다른가}
-2. {차별점 2}: {경쟁작 대비 어떻게 다른가}
-3. {차별점 3}: {경쟁작 대비 어떻게 다른가}
-
----
-
-## 5. 열린 결정 항목
-
-> PD님 결정이 필요한 방향성 안건. 설계 진행 전 반드시 해소해야 할 항목을 등록한다.
-
-| # | 항목 | 배경 | PD님 결정 필요 시점 |
-|---|------|------|-------------------|
-| 1 | {결정 필요 항목} | {왜 결정이 필요한가} | {Phase N / 특정 설계 착수 전} |
-| 2 | {결정 필요 항목} | {왜 결정이 필요한가} | {Phase N / 특정 설계 착수 전} |
diff --git a/프로젝트/신규 프로젝트/기획/02_핵심_재미_정의.md b/프로젝트/신규 프로젝트/기획/02_핵심_재미_정의.md
deleted file mode 100644
index fadc576..0000000
--- a/프로젝트/신규 프로젝트/기획/02_핵심_재미_정의.md	
+++ /dev/null
@@ -1,79 +0,0 @@
-# {프로젝트명} — 핵심 재미 정의
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
-
----
-
-> ⚠️ **C7 게이트 — 착수 금지**
-> 본 문서가 PD님 승인을 받기 전에는 03~08번 문서의 착수를 금지한다.
-> (C7 재미 우선 원칙: 재미 정의 없는 수치 조정·시스템 설계·컨텐츠 설계는 허용하지 않는다.)
->
-> **승인 상태**: `미승인` / `승인 (날짜: {YYYY-MM-DD})`
-
----
-
-## 1. 핵심 재미 (정확히 1개)
-
-> 2개 이상 금지. 복수의 후보가 있다면 수렴 논의 후 1개만 남긴다.
-
-**"{핵심 재미를 한 문구로 정의}"**
-
-> 작성 지침: 유저가 "또 하고 싶다"고 느끼는 감정적 순간을 동사+목적어로 압축한다.
-> 예시 형식: "예상을 뒤엎는 조합이 터지는 순간의 쾌감"
-
----
-
-## 2. 구체 발현 테이블
-
-> 핵심 재미가 실제 플레이에서 어떻게 나타나는지 구체화한다. 3행 이상 필수.
-
-| 상황 | 유저 감정 | 이를 유발하는 게임 메커니즘 |
-|------|----------|--------------------------|
-| {플레이 상황 1} | {감정 서술} | {어떤 메커니즘이 이 감정을 만드는가} |
-| {플레이 상황 2} | {감정 서술} | {어떤 메커니즘이 이 감정을 만드는가} |
-| {플레이 상황 3} | {감정 서술} | {어떤 메커니즘이 이 감정을 만드는가} |
-
----
-
-## 3. 보조 재미 (최대 2개)
-
-> 핵심 재미를 보강하는 부차적 재미. 핵심 재미와 방향이 일치해야 한다.
-
-1. **{보조 재미 A}**: {핵심 재미와의 연결 관계}
-2. **{보조 재미 B}**: {핵심 재미와의 연결 관계}
-
----
-
-## 4. 재미 판단 기준
-
-> 모든 기획 결정은 아래 기준으로 판단한다. "재미 없어 보인다"는 직관이 아니라 **핵심 재미와의 연결 여부**로 판단한다.
-
-| 판단 결과 | 기준 | 처리 |
-|----------|------|------|
-| **채택** | 이 결정이 핵심 재미를 **강화**한다 | 진행 |
-| **기각** | 이 결정이 핵심 재미를 **약화**시킨다 | 기각 (기술적·효율적 근거가 있어도) |
-| **효율 판단** | 이 결정이 핵심 재미와 **무관**하다 | 비용·공수 관점에서 결정 |
-
----
-
-## 5. 재미 안티패턴
-
-> 이 게임에서 **하지 말아야 할 것**. 핵심 재미와 충돌하거나 희석시키는 패턴 목록.
-
-1. {안티패턴 1}: {왜 이것이 핵심 재미를 해치는가}
-2. {안티패턴 2}: {왜 이것이 핵심 재미를 해치는가}
-3. {안티패턴 3}: {왜 이것이 핵심 재미를 해치는가}
-
----
-
-## 6. 검증 방법
-
-> 각 개발 단계에서 핵심 재미가 실제로 전달되고 있는지 확인하는 방법.
-
-| 단계 | 검증 방식 | 기대 신호 | 실패 신호 |
-|------|----------|----------|----------|
-| **프로토타입** | {검증 방법} | {성공 시 나타나는 반응} | {실패 시 나타나는 반응} |
-| **알파** | {검증 방법} | {성공 시 나타나는 반응} | {실패 시 나타나는 반응} |
-| **베타** | {검증 방법} | {성공 시 나타나는 반응} | {실패 시 나타나는 반응} |
diff --git a/프로젝트/신규 프로젝트/기획/03_시스템_설계.md b/프로젝트/신규 프로젝트/기획/03_시스템_설계.md
deleted file mode 100644
index 063fcc9..0000000
--- a/프로젝트/신규 프로젝트/기획/03_시스템_설계.md	
+++ /dev/null
@@ -1,96 +0,0 @@
-# {프로젝트명} — 시스템 설계
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 (C7 게이트 통과) 후 착수
-
----
-
-## 1. 시스템 카탈로그
-
-> 게임을 구성하는 모든 시스템을 나열하고 우선순위를 정한다.
-
-| 시스템명 | 재미 기여도 | 우선순위 | 설계 상태 |
-|---------|-----------|---------|---------|
-| {시스템 A} | 직접 (핵심 재미 직결) | 1 | 미착수 |
-| {시스템 B} | 간접 (핵심 재미 보강) | 2 | 미착수 |
-| {시스템 C} | 인프라 (다른 시스템 지원) | 3 | 미착수 |
-
-> 재미 기여도 분류:
-> - **직접**: 핵심 재미가 발생하는 시스템 자체
-> - **간접**: 핵심 재미의 맥락·깊이를 더하는 시스템
-> - **인프라**: 게임 운용에 필요하나 재미와 직결되지 않는 시스템
-
----
-
-## 2. 시스템별 상세
-
----
-
-### 2-1. {시스템 A}
-
-**목적**: {핵심 재미(02번 문서)와 어떻게 연결되는가}
-
-**기본 메커니즘**:
-
-{시스템이 어떻게 동작하는지 서술. 유저의 행동과 시스템 응답을 중심으로}
-
-**데이터 파라미터**:
-
-| 파라미터 | 기준값 | SOT 테이블 | 비고 |
-|---------|-------|-----------|------|
-| {파라미터명} | {기준값} | {데이터 테이블명} | {조정 가능 범위 등} |
-| {파라미터명} | {기준값} | {데이터 테이블명} | {조정 가능 범위 등} |
-
-**상태 전이**:
-
-```
-{초기 상태} → {트리거: 유저 행동/조건} → {결과 상태}
-                                        ↓
-                              {예외 처리 경로}
-```
-
-**시스템 간 상호작용**:
-
-| 대상 시스템 | 상호작용 유형 | 방향 |
-|-----------|-------------|------|
-| {시스템명} | {데이터 공유 / 이벤트 발행 / 상태 참조} | {A→B / B→A / 양방향} |
-
----
-
-### 2-2. {시스템 B}
-
-**목적**: {핵심 재미(02번 문서)와 어떻게 연결되는가}
-
-**기본 메커니즘**:
-
-{시스템이 어떻게 동작하는지 서술}
-
-**데이터 파라미터**:
-
-| 파라미터 | 기준값 | SOT 테이블 | 비고 |
-|---------|-------|-----------|------|
-| {파라미터명} | {기준값} | {데이터 테이블명} | {비고} |
-
-**상태 전이**:
-
-```
-{초기 상태} → {트리거} → {결과 상태}
-```
-
-**시스템 간 상호작용**:
-
-| 대상 시스템 | 상호작용 유형 | 방향 |
-|-----------|-------------|------|
-| {시스템명} | {유형} | {방향} |
-
----
-
-## 3. 열린 결정 항목
-
-| # | 항목 | 배경 | PD님 결정 필요 시점 |
-|---|------|------|-------------------|
-| 1 | {결정 필요 항목} | {왜 결정이 필요한가} | {Phase N / 특정 설계 착수 전} |
-| 2 | {결정 필요 항목} | {왜 결정이 필요한가} | {Phase N / 특정 설계 착수 전} |
diff --git a/프로젝트/신규 프로젝트/기획/04_컨텐츠_설계.md b/프로젝트/신규 프로젝트/기획/04_컨텐츠_설계.md
deleted file mode 100644
index 25808dc..0000000
--- a/프로젝트/신규 프로젝트/기획/04_컨텐츠_설계.md	
+++ /dev/null
@@ -1,86 +0,0 @@
-# {프로젝트명} — 컨텐츠 설계
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 (C7 게이트 통과) 후 착수
-
----
-
-## 1. 컨텐츠 카테고리 맵
-
-> 이 게임에 존재하는 모든 컨텐츠 유형을 분류한다. 각 카테고리는 하나의 데이터 테이블로 관리된다.
-
-| 카테고리 | 설명 | 예상 볼륨 | SOT 테이블명 |
-|---------|------|---------|------------|
-| {카테고리 A} | {이 카테고리가 포함하는 컨텐츠 설명} | {~N종} | {테이블명.xlsx/json} |
-| {카테고리 B} | {이 카테고리가 포함하는 컨텐츠 설명} | {~N종} | {테이블명.xlsx/json} |
-| {카테고리 C} | {이 카테고리가 포함하는 컨텐츠 설명} | {~N종} | {테이블명.xlsx/json} |
-
----
-
-## 2. 카테고리별 상세
-
----
-
-### 2-1. {카테고리 A}
-
-**구조 설명**:
-
-{이 카테고리의 컨텐츠가 어떤 구조로 구성되는가. 유저가 어떻게 접하는가}
-
-**ID 규칙**:
-
-```
-{카테고리 접두사}_{분류 코드}_{일련번호}
-예: {A_001, B_01_003 등 구체적 패턴 서술}
-```
-
-**필드 구조 (주요 컬럼)**:
-
-| 컬럼명 | 타입 | 설명 | 필수 |
-|-------|------|------|------|
-| id | string | 고유 식별자 (ID 규칙 준수) | ✅ |
-| name | string | 표시 이름 | ✅ |
-| {필드명} | {타입} | {설명} | {✅/선택} |
-| {필드명} | {타입} | {설명} | {✅/선택} |
-
----
-
-### 2-2. {카테고리 B}
-
-**구조 설명**:
-
-{이 카테고리의 컨텐츠 구조 서술}
-
-**ID 규칙**:
-
-```
-{ID 패턴 서술}
-```
-
-**필드 구조 (주요 컬럼)**:
-
-| 컬럼명 | 타입 | 설명 | 필수 |
-|-------|------|------|------|
-| id | string | 고유 식별자 | ✅ |
-| name | string | 표시 이름 | ✅ |
-| {필드명} | {타입} | {설명} | {✅/선택} |
-
----
-
-## 3. 데이터 테이블 마스터 목록
-
-> 이 게임의 모든 데이터 테이블 목록. 추가/삭제 시 본 목록을 SOT로 갱신한다.
-
-| 테이블명 | 주요 컬럼 | 행 수(추정) | SOT 포맷 | 비고 |
-|---------|---------|-----------|---------|------|
-| {테이블 A} | id, name, {컬럼들} | ~{N}행 | Excel / JSON | {비고} |
-| {테이블 B} | id, name, {컬럼들} | ~{N}행 | Excel / JSON | {비고} |
-| {테이블 C} | id, name, {컬럼들} | ~{N}행 | Excel / JSON | {비고} |
-
-> **SOT 포맷 선택 기준**:
-> - **Excel**: 기획자가 직접 편집하는 수치/내용 테이블
-> - **JSON**: 런타임 직접 로드, 빌드 자동화 대상 테이블
-> - 동일 데이터를 두 포맷으로 이중 관리하는 경우 **반드시 한쪽을 SOT로 지정**하고 다른 쪽은 생성(변환) 파일로 표시한다
diff --git a/프로젝트/신규 프로젝트/기획/05_밸런스_프레임워크.md b/프로젝트/신규 프로젝트/기획/05_밸런스_프레임워크.md
deleted file mode 100644
index bc23d3e..0000000
--- a/프로젝트/신규 프로젝트/기획/05_밸런스_프레임워크.md	
+++ /dev/null
@@ -1,100 +0,0 @@
-# {프로젝트명} — 밸런스 프레임워크
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 (C7 게이트 통과) + `03_시스템_설계.md` 초안 완료 후 착수
-
----
-
-## 1. 밸런싱 철학
-
-> 밸런싱의 목적은 수치 균형이 아니라 **핵심 재미의 보장**이다.
-> 참조: [`02_핵심_재미_정의.md`](./02_핵심_재미_정의.md) — 핵심 재미 정의 및 재미 판단 기준
-
-**이 게임의 밸런싱이 달성해야 할 상태**:
-
-1. {핵심 재미와 연결된 밸런싱 목표 1}
-2. {핵심 재미와 연결된 밸런싱 목표 2}
-3. {핵심 재미와 연결된 밸런싱 목표 3}
-
-**밸런싱 금지 패턴**:
-
-- {이 게임에서 피해야 할 밸런싱 실수 1}
-- {이 게임에서 피해야 할 밸런싱 실수 2}
-
----
-
-## 2. 앵커 포인트
-
-> 밸런싱의 기준점. 모든 수치는 앵커에서 상대적으로 산출된다.
-> **앵커는 단 하나여야 한다.** 복수 앵커는 모순을 만든다.
-
-| 앵커 항목 | 기준값 | 측정 방법 | SOT |
-|---------|-------|---------|-----|
-| {주 앵커: 예: "유저가 N회 시도 시 성공률"} | {기준값} | {어떻게 측정/검증하는가} | {데이터 테이블명} |
-
-**앵커에서 파생되는 보조 기준값**:
-
-| 항목 | 산식 | 기준값 |
-|------|------|-------|
-| {파생 항목 1} | {앵커 기준 산식} | {값} |
-| {파생 항목 2} | {앵커 기준 산식} | {값} |
-
----
-
-## 3. 밸런싱 순서
-
-> 시스템 간 종속 관계에 따라 밸런싱 순서를 정한다.
-> 종속 관계를 무시하고 병렬 밸런싱하면 후반에 전체를 재조정해야 한다.
-
-```
-[1단계] {기초 프레임 확정}
-  └─ {예: 앵커 수치 고정, 기본 전투/루프 수치 설정}
-
-[2단계] {핵심 시스템 밸런싱}
-  └─ {예: 핵심 재미가 발생하는 시스템의 주요 파라미터}
-
-[3단계] {보조 시스템 조정}
-  └─ {예: 보상·성장·경제 시스템을 핵심 시스템에 맞게 조정}
-
-[4단계] {컨텐츠 단위 검증}
-  └─ {예: 개별 컨텐츠 수치를 프레임 내에서 검증}
-```
-
-**단계 간 전환 조건**:
-
-| 전환 | 조건 |
-|------|------|
-| 1단계 → 2단계 | {충족해야 할 검증 기준} |
-| 2단계 → 3단계 | {충족해야 할 검증 기준} |
-| 3단계 → 4단계 | {충족해야 할 검증 기준} |
-
----
-
-## 4. 시뮬레이션 전략
-
-> ⚠️ **단일 시뮬레이터 원칙**
-> 런타임(게임 본체)과 시뮬레이터(외부 계산 도구)는 **반드시 동일한 데이터 소스를 사용**해야 한다.
-> 시뮬레이터가 별도 수치를 관리하면 "시뮬에서는 되는데 게임에서는 안 된다"는 이원화 문제가 발생한다.
-> **시뮬레이터 SOT = 런타임 SOT** (같은 테이블을 읽어야 한다)
-
-| 대상 | 도구 | 검증 기준 | SOT 데이터 |
-|------|------|---------|----------|
-| {시뮬 대상 1} | {Python / Excel / 게임 내 도구 등} | {판단 기준} | {데이터 테이블명} |
-| {시뮬 대상 2} | {도구} | {판단 기준} | {데이터 테이블명} |
-
----
-
-## 5. 핵심 수치 대시보드
-
-> 밸런스 건강 상태를 모니터링하는 주요 지표. 이탈 발생 시 즉시 조정 착수.
-
-| 지표 | 산식 | 정상 범위 | 이탈 시 조치 |
-|------|------|---------|------------|
-| {지표 1} | {산식} | {하한 ~ 상한} | {조정 방향} |
-| {지표 2} | {산식} | {하한 ~ 상한} | {조정 방향} |
-| {지표 3} | {산식} | {하한 ~ 상한} | {조정 방향} |
-
-> **대시보드 갱신 시점**: {밸런스 수치 변경 시마다 / 특정 Phase 완료 시 / 정기 검토 시}
diff --git a/프로젝트/신규 프로젝트/기획/06_UX_흐름.md b/프로젝트/신규 프로젝트/기획/06_UX_흐름.md
deleted file mode 100644
index 945e160..0000000
--- a/프로젝트/신규 프로젝트/기획/06_UX_흐름.md	
+++ /dev/null
@@ -1,86 +0,0 @@
-# {프로젝트명} — UX 흐름
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 + `03_시스템_설계.md` 초안 완료 후 착수
-
----
-
-## 1. 화면 맵
-
-> 게임 전체 화면 구조를 최상위 레벨에서 표현한다.
-
-```
-[앱 시작]
-    │
-    ▼
-[{메인/로비 화면}]
-    ├── [{게임 핵심 화면}] ──→ [{결과 화면}] ──→ [메인 복귀]
-    ├── [{설정 화면}]
-    ├── [{상점/수익화 화면}]
-    └── [{기타 보조 화면}]
-```
-
-> 화살표 방향 = 화면 전환 방향. 순환 구조는 명시적으로 표시한다.
-
----
-
-## 2. 화면별 정의
-
-| 화면 | 진입 조건 | 주요 기능 | 이탈 경로 |
-|------|---------|---------|---------|
-| {메인/로비} | 앱 시작, 결과 화면에서 복귀 | {핵심 액션 목록} | {게임 시작, 설정, 상점} |
-| {게임 핵심 화면} | 게임 시작 버튼 | {인게임 주요 기능} | {일시정지, 게임 종료} |
-| {결과 화면} | 게임 종료 조건 충족 | {결과 표시, 보상 수령} | {재시작, 메인 복귀} |
-| {설정} | 설정 버튼 | {옵션 조정} | {닫기(이전 화면)} |
-| {상점} | 상점 버튼 | {상품 목록, 구매} | {닫기(이전 화면)} |
-| {기타 화면} | {진입 조건} | {기능} | {이탈 경로} |
-
----
-
-## 3. 핵심 조작 흐름
-
-> 핵심 재미가 발생하는 플레이 시퀀스를 유저 액션과 시스템 응답을 교대로 서술한다.
-
-### 흐름 A: {핵심 재미 발생 시나리오 — 예: 주요 게임 루프}
-
-```
-유저:   {유저가 하는 행동}
-시스템: {시스템이 즉시 반응하는 것}
-
-유저:   {다음 행동}
-시스템: {시스템 반응 + 피드백}
-
-유저:   {결정적 행동}
-시스템: {핵심 재미가 발생하는 시스템 반응}
-         → [결과 화면으로 전환]
-```
-
-### 흐름 B: {보조 시나리오 — 예: 구매, 설정 변경 등}
-
-```
-유저:   {유저 액션}
-시스템: {반응}
-
-유저:   {다음 액션}
-시스템: {반응}
-         → [이전 화면 복귀]
-```
-
----
-
-## 4. UI 컴포넌트 목록
-
-> 재사용되는 UI 컴포넌트를 정의한다. 개발팀에 전달하는 사양 기준.
-
-| 컴포넌트 | 사용 화면 | 상태 | 비고 |
-|---------|---------|------|------|
-| {컴포넌트명 A} | {사용하는 화면 목록} | {활성/비활성/선택됨 등} | {애니메이션, 특이사항} |
-| {컴포넌트명 B} | {사용 화면} | {상태 목록} | {비고} |
-| {컴포넌트명 C} | {사용 화면} | {상태 목록} | {비고} |
-
-> **컴포넌트 사양 원칙**:
-> - 동일 기능을 여러 화면에서 반복 구현하지 않는다. 공통 컴포넌트로 추출한다.
-> - 상태 목록이 3개를 초과하면 별도 명세 문서로 분리한다.
diff --git a/프로젝트/신규 프로젝트/기획/07_수익화_설계.md b/프로젝트/신규 프로젝트/기획/07_수익화_설계.md
deleted file mode 100644
index e005169..0000000
--- a/프로젝트/신규 프로젝트/기획/07_수익화_설계.md	
+++ /dev/null
@@ -1,83 +0,0 @@
-# {프로젝트명} — 수익화 설계
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 (C7 게이트 통과) 후 착수
-
----
-
-## 1. 수익화 원칙
-
-> ⚠️ **핵심 재미 훼손 금지**
-> 수익화 설계의 모든 결정은 [`02_핵심_재미_정의.md`](./02_핵심_재미_정의.md)의 재미 판단 기준으로 검증한다.
-> **수익화가 핵심 재미를 약화시키면 기각한다.** 매출 기여도가 높아도 예외 없음.
-
-**이 게임의 수익화 방향**:
-
-1. {수익화 원칙 1}: {핵심 재미와의 관계}
-2. {수익화 원칙 2}: {핵심 재미와의 관계}
-3. {수익화 원칙 3}: {핵심 재미와의 관계}
-
-**수익화 금지 패턴**:
-
-- {핵심 재미를 해치는 수익화 패턴 1}: {왜 금지인가}
-- {핵심 재미를 해치는 수익화 패턴 2}: {왜 금지인가}
-
----
-
-## 2. 재화 체계
-
-> 게임 내 모든 재화를 정의한다. 재화 간 교환·획득·소비 경로가 명확해야 한다.
-
-| 재화명 | 유형 | 주요 획득 경로 | 주요 소비처 | 이월 가능 |
-|-------|------|-------------|-----------|---------|
-| {재화 A} | 유료 / 무료 / 혼합 | {플레이 / 구매 / 이벤트 등} | {어디에 쓰는가} | 예 / 아니오 |
-| {재화 B} | 유료 / 무료 / 혼합 | {획득 경로} | {소비처} | 예 / 아니오 |
-| {재화 C} | 유료 / 무료 / 혼합 | {획득 경로} | {소비처} | 예 / 아니오 |
-
-**재화 흐름 다이어그램**:
-
-```
-[유저 행동/구매] → {재화 A} → [소비처 X]
-                           → [소비처 Y]
-
-[플레이 보상]   → {재화 B} → [소비처 Z]
-                           ↘ {재화 C로 교환}
-```
-
----
-
-## 3. 상품 구조
-
-> 유료 상품의 유형과 가격 구조를 정의한다.
-
-| 유형 | 구성 | 가격대 | 과금 유도 타이밍 | 비고 |
-|------|------|-------|--------------|------|
-| {상품 유형 A} | {포함 내용} | {가격 범위} | {언제 제시되는가} | {비고} |
-| {상품 유형 B} | {포함 내용} | {가격 범위} | {유도 타이밍} | {비고} |
-| {상품 유형 C} | {포함 내용} | {가격 범위} | {유도 타이밍} | {비고} |
-
-**과금 유도 타이밍 원칙**:
-
-- {타이밍 원칙 1}: {핵심 재미와의 관계, 과금 압박이 재미를 해치지 않는 이유}
-- {타이밍 원칙 2}: {원칙}
-
----
-
-## 4. 광고 정책
-
-> 광고 노출이 핵심 재미를 방해하지 않도록 정책을 명확히 정의한다.
-
-| 유형 | 보상 | 빈도 / 노출 시점 | 강제 여부 | 비고 |
-|------|------|--------------|---------|------|
-| {광고 유형 A: 예: 보상형 동영상} | {보상 내용} | {빈도 또는 노출 조건} | 자발적 | {비고} |
-| {광고 유형 B: 예: 전면 광고} | 없음 | {노출 빈도/시점} | 강제 | {건너뛰기 조건} |
-| {광고 유형 C} | {보상} | {조건} | {강제/자발} | {비고} |
-
-**광고 제한 규칙**:
-
-- {핵심 재미 진행 중(예: 게임 플레이 중) 강제 광고 금지}
-- {광고 노출 최소 간격: N분 / N회 플레이당 1회 등}
-- {기타 제한 사항}
diff --git a/프로젝트/신규 프로젝트/기획/08_라이브_운영_계획.md b/프로젝트/신규 프로젝트/기획/08_라이브_운영_계획.md
deleted file mode 100644
index 8eb2feb..0000000
--- a/프로젝트/신규 프로젝트/기획/08_라이브_운영_계획.md	
+++ /dev/null
@@ -1,74 +0,0 @@
-# {프로젝트명} — 라이브 운영 계획
-
-> **버전**: v1
-> **작성일**: {날짜}
-> **담당**: 기획팀장
->
-> **선행 조건**: `02_핵심_재미_정의.md` PD님 승인 완료 + `07_수익화_설계.md` 확정 후 착수
-
----
-
-## 1. 운영 주기
-
-> 라이브 서비스의 리듬을 정의한다. 유저가 "다음에 또 돌아올 이유"를 만드는 구조.
-
-### 주간 운영 프레임
-
-| 주기 | 내용 | 목적 |
-|------|------|------|
-| 매주 | {주간 반복 요소: 예: 주간 챌린지, 리셋 보상} | {D7 리텐션 자극} |
-| 격주 | {격주 요소} | {목적} |
-| {기타 주기} | {내용} | {목적} |
-
-### 월간 운영 프레임
-
-| 주기 | 내용 | 목적 |
-|------|------|------|
-| 매월 | {월간 반복 요소: 예: 월간 패스, 컨텐츠 추가} | {D30 리텐션 자극} |
-| {기타} | {내용} | {목적} |
-
-### 시즌 프레임
-
-| 시즌 길이 | 시즌 컨텐츠 구성 | 시즌 종료 처리 |
-|---------|--------------|-------------|
-| {N주 / N개월} | {시즌 전용 요소 목록} | {리셋 여부, 이월 보상 처리} |
-
----
-
-## 2. 이벤트 프레임워크
-
-> 이벤트 유형을 표준화하여 제작·재활용 효율을 높인다.
-
-| 이벤트 유형 | 내용 | 보상 구조 | 재활용 가능 여부 | 제작 비용 |
-|-----------|------|---------|--------------|---------|
-| {이벤트 A: 예: 로그인 연속 보상} | {설명} | {보상 방식} | 높음 (수치·기간만 변경) | 낮음 |
-| {이벤트 B: 예: 한정 컨텐츠} | {설명} | {보상 방식} | 중간 (아트 신규 필요) | 중간 |
-| {이벤트 C: 예: 커뮤니티 이벤트} | {설명} | {보상 방식} | 낮음 (매번 신규 기획) | 높음 |
-
-**이벤트 설계 원칙**:
-
-- {원칙 1: 예: 이벤트 보상이 핵심 재미를 우회하지 않는다}
-- {원칙 2: 예: 이벤트 참여가 강제가 아닌 자발적 동기에서 발생한다}
-- {원칙 3: 예: 이벤트 미참여 유저가 게임에서 불이익을 받지 않는다}
-
----
-
-## 3. KPI 정의
-
-> 라이브 서비스 건강 상태를 판단하는 핵심 지표.
-
-| KPI | 정의 | 측정 방법 | 목표 범위 | 이탈 시 조치 |
-|-----|------|---------|---------|------------|
-| **DAU** | 일간 활성 유저 수 | {측정 도구/방법} | {목표 범위} | {조치 방향} |
-| **D1 리텐션** | 첫 플레이 다음날 재방문율 | {측정 방법} | {목표 범위 %}  | {튜토리얼·첫 루프 재검토} |
-| **D7 리텐션** | 7일 후 재방문율 | {측정 방법} | {목표 범위 %} | {주간 운영 요소 점검} |
-| **D30 리텐션** | 30일 후 재방문율 | {측정 방법} | {목표 범위 %} | {중장기 컨텐츠 검토} |
-| **ARPDAU** | 일간 활성 유저 1인당 평균 매출 | {측정 방법} | {목표 범위} | {수익화 설계 점검} |
-| **세션 길이** | 1회 플레이 평균 시간 | {측정 방법} | `{N}분 ~ {N}분` | {게임 루프 길이 조정} |
-| **전환율** | 무료→유료 전환 비율 | {측정 방법} | {목표 범위 %} | {과금 진입점·상품 구성 검토} |
-
-**KPI 해석 원칙**:
-
-- KPI 이탈 자체가 "문제"가 아니라 **근원 원인을 파악하는 신호**로 취급한다
-- KPI 개선을 위해 핵심 재미를 희생하는 수정은 금지한다 (C7 재미 우선)
-- 복수 KPI가 동시 이탈 시 상호 관계를 분석하여 근본 원인을 식별한다
diff --git a/프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md b/프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md
deleted file mode 100644
index 07e8297..0000000
--- a/프로젝트/코어프레임워크/02_수상한잡화점_추출대상_v1.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# 수상한 잡화점 — BT.Framework 추출 대상 선별
-
-> 🟢 **2026-04-17 완료 실적 아카이브 — Tier 1 16/16 반영 종료**
->
-> 본 문서는 수상한 잡화점 소스에서 코어 프레임워크로 추출할 대상을 식별한 **원 가이드**로, Tier 1 기반 Core 4종 + Attribute 3종 + Util 6종 + Event 2종 + Container 3종 + Data 5종 = **총 19 파일·16 모듈 구현 완료** 시점(2026-04-17)에 "완료 실적" 성격으로 전환됨. 각 추출 항목은 아래 본문에서 구현 위치 역참조로 연결됨 (📦 표기). 구현 상세는 [`코어코드/BT.Framework/CHANGELOG.md`](../../코어코드/BT.Framework/CHANGELOG.md) 참조.
->
-> 차기 프로젝트에서 Tier 2(Addressable·UGUI·Security)·Tier 3(Network) 추가 추출 시 본 문서 구조(A/B/C/D 등급 분류·변형 포인트·네이밍 규칙)를 재사용 가능 (헌법 제1원칙 목표 2 원칙 A).
-
-> **작성일**: 2026-04-14
-> **상위 문서**: `01_아키텍처_개요_v1.md`
-> **목적**: 수상한 잡화점 Unity 프로젝트 코드에서 신규 코어로 편입할 범용 패턴 식별·분류
-> **원칙**: **코드·구조 참고는 가능, 네이밍은 재작성 필수** (PD님 확정)
-> **주의**: 수상한 잡화점 프로젝트에는 이 코어를 적용하지 않음. **추출은 다음 프로젝트에서 사용할 코어용**.
-
----
-
-## 1. 등급 분류
-
-| 등급 | 의미 | 조치 |
-|------|------|------|
-| **A. 즉시 추출** | 범용성 높음 + 의존성 최소 | 코어에 바로 재작성 편입 |
-| **B. 프레임워크 래핑** | 패턴은 범용, 단순화·제네릭화 필요 | 구조 참고 + 재설계 |
-| **C. 선별 추출** | 게임 로직과 범용 로직 혼재 | 범용 메서드만 분리 흡수 |
-| **D. 도메인 잔류** | 프로젝트 특수 개념 다수 | 코어 편입 제외, 프로젝트에 남김 |
-
-## 2. 분류표 (13+개 대상 파일)
-
-### A. 즉시 추출 (6개)
-
-| # | 원본 | 줄 수 | 신규 위치 | 변형 포인트 | 구현 상태 |
-|---|------|------|----------|------------|---------|
-| 1 | `My/MyCoroutine.cs` | 52 | `BurningTimes.Core.Coroutine.CoroutineRunner` | 기존 BurningTimesCore `CoroutineHandler`와 통합, 일시정지·재시작·중복방지 1종 API | ✅ 2026-04-16 — 📦 `Runtime/Core/Coroutine/CoroutineRunner.cs` |
-| 2 | `My/CryptoUtil.cs` | 86 | `BurningTimes.Security.CryptoUtil` (Tier 3 합류 시점) | **AES 키 하드코딩 제거 필수**, `ICryptoProvider` 인터페이스 뒷받침, 키 주입 방식 | ⏸ Tier 3 대기 |
-| 3 | `Addressable/AddrHandleBase.cs` | 102 | `BurningTimes.Addressable.AddressableHandle<T>` (Tier 2) | 참조 카운팅·Preload/Unload 정책 부가 | ⏸ Tier 2 대기 |
-| 4 | `Addressable/AddressableReleaseSelf.cs` | 8 | `BurningTimes.Addressable.AutoReleaseComponent` (Tier 2) | OnDestroy 훅 재작성, 주석처리 코드 제거 | ⏸ Tier 2 대기 |
-| 5 | `UGUI/Util/SafeArea.cs` | 17 | `BurningTimes.UI.Components.SafeAreaBorder` | 기존 UIToolkit 버전과 병존, UGUI RectTransform 대응 | ⏸ Tier 2(UI) 대기 |
-| 6 | `Manager/ErrorLogHookManager.cs` | 42 | `BurningTimes.Core.Util.Log` 내부 훅 | `Log` 카테고리·필터와 통합, `#if FGB_LIVE` 같은 프로젝트 플래그 제거 | ✅ 2026-04-16 — 📦 `Runtime/Core/Log/` 통합 |
-
-### B. 프레임워크 래핑 (2개)
-
-| # | 원본 | 줄 수 | 신규 위치 | 변형 포인트 | 구현 상태 |
-|---|------|------|----------|------------|---------|
-| 7 | `Template/MonoBehaviourSingletonTemplate.cs` | 30 | `BurningTimes.Core.Patterns.MonoSingleton<T>` | 4종 싱글톤(Sync/Async/Ready/Inner) 통합 (01문서 4-1 참조). `MonoBehaviourSingletonuScrollViewMgr<T>` 같은 변종 제거 | ✅ 2026-04-16 — 📦 `Runtime/Core/Patterns/MonoSingleton.cs` + `ServiceLocator.cs` |
-| 8 | `UGUI/BackKey/BackKeyAdd.cs` | 67 | `BurningTimes.UI.UGUI.BackKeyHandler` | `BackKeyMgr` 싱글톤 의존을 구독 패턴으로 재설계, 스택 기반 백키 처리 | ⏸ Tier 2(UI) 대기 |
-
-### 🆕 2026-04-17 Tier 1 확장 구현 (본 원 가이드 범위 외 추가 추출)
-
-Tier 1 완결을 위해 원 가이드에 없던 모듈 9종을 추가 설계·구현. 수상한잡화점 소스 역추적이 아닌 **차기 프로젝트 범용성을 목적으로 한 신규 설계** (C11 범용성 원칙).
-
-| 범주 | 모듈 | 구현 위치 | 근거 설계 |
-|------|------|----------|---------|
-| **Attribute** 3종 | `ReadOnlyAttribute`·`ShowIfAttribute`·`ArrayTitleAttribute` | 📦 `Runtime/Core/Attribute/` | 인스펙터 UX 공통 패턴 |
-| **Util** 6종 | `EnumToInt`(#12 일반화)·`EnumEx`·`FormatEx`·`MathEx`·`KeyMaker`·`ValidationEx`(#9 일반화) | 📦 `Runtime/Core/Util/` | 박싱 회피 `Unsafe.As<,>`, `:` 구분자 표준, 순수 BCL |
-| **Event** 2종 | `EventBus`·`Raw/RawEventBus` | 📦 `Runtime/Core/Event/` | `04_Tier1_3종_상호작용_설계_v1.md` §3 |
-| **Container** 3종 | `ObservableList`·`ObservableDictionary`·`ObservableQueue` | 📦 `Runtime/Core/Container/` | 기존 `UniList`·`UniEventList`·`UniObserverList` 3종 통합 대체, 세분화 이벤트 |
-| **Data** 5종 | `IDataRow`·`DataTable`·`DataTableSO`·`DataTableLoader`·`DataTableLoadedEvent` | 📦 `Runtime/Core/Data/` | 기존 `MasterTableBase` 재설계, 제네릭 키, RFC 4180 최소 CSV + JsonUtility |
-
-**테스트**: NUnit 기반 총 19+ 파일 (`Tests/Runtime/Core/{Attribute,Util,Event,Container,Data}/*Tests.cs`).
-
-### C. 선별 추출 (4개 — 범용 메서드만 취함)
-
-#### 9. `My/DSUtil.cs` (1,406줄)
-프로젝트 강결합(게임 테이블 참조, `ObscuredTypes` 의존, 게임 stage 로직)이 상당함. **범용 메서드만 흡수**.
-
-| 추출 후보 메서드 | 신규 위치 | 비고 |
-|----------------|----------|------|
-| `CheckNull`, `Get_Clone`, `Format` | `BurningTimes.Core.Util.ValidationEx` / `ObjectEx` / `FormatEx` | |
-| `StringToEnum<T>` | `BurningTimes.Core.Util.EnumEx` | 캐시 적용 |
-| `LogError` 변종 | `BurningTimes.Core.Util.Log` | 중앙 로거로 통합 |
-| **제외** | `GetStageInfo`, `ActorInfo`류, 테이블 조회 | 수상한 잡화점 전용, 프로젝트 잔류 |
-
-#### 10. `UGUI/Manager/uScrollViewMgr.cs` + `uScrollViewArrMgr.cs` (합 116줄)
-- **추출**: 무한 스크롤 프레임워크 뼈대 (`Set_ScrollView<T>`, `ScrollTo`)
-- **제거**: `CardBase`, `DSUtil` 의존, 프로젝트 특화 `ClickCard`/`Select_Card`
-- **신규 위치**: `BurningTimes.UI.UGUI.InfiniteScrollView<T>`
-- **변형**: 제네릭 데이터 바인딩 인터페이스(`IScrollItem<T>`)로 재설계
-
-#### 11. `UGUI/Manager/UIAtlasMgr.cs` (29줄)
-- **추출**: `Set()`, `Get_Sprite()` 스프라이트 아틀라스 관리
-- **제거**: `Get_EquipmentGrade_Sprite()`, `Get_CardGrade_Sprite()` (게임 특수)
-- **신규 위치**: `BurningTimes.UI.UGUI.SpriteAtlasRegistry`
-
-#### 12. `My/MyEnumToInt.cs` (51줄)
-- **추출**: Enum → Int 캐싱 패턴 (박싱 회피)
-- **신규 위치**: `BurningTimes.Core.Util.EnumToInt<T>`
-- **변형**: `MyEnum` 구체 의존 제거, 제네릭 타입 파라미터로 일반화
-
-### D. 도메인 잔류 (추출 제외, 프로젝트에 남김)
-
-| 원본 | 사유 |
-|------|------|
-| `My/MyEnum.cs` (463줄) | 23개 enum 전부 수상한 잡화점 특수 (`eStageNodeType`, `eStat`, `eStatusConditionsType` 등). **C11 오염, 코어 편입 금지** |
-| `My/MyValue.cs` (802줄) | 게임 테이블·스테이지 데이터 강결합. 프로젝트 설정값 모음 |
-| `My/MyText.cs` | `eStat`/`eElement` 로컬라이제이션 — 게임 특수 |
-| `UGUI/Common/GameUI.cs` | `EffectMgr`/`MyValue` 강결합, 게임 이펙트 로직 |
-| `UGUI/Common/ControlUI.cs` | `eControlUi` 게임 특수 enum |
-| `UGUI/Common/ScenarioUI.cs` (43KB) | 시나리오 이벤트 시스템, 프로젝트 특화 |
-| `UGUI/Common/TouchBlockUI.cs` | (재확인 필요 — 범용성 검토 후 추출 여부 재판정) |
-
-## 3. 추출 시 공통 정리 원칙
-
-### 3-1. 네이밍 규칙
-- `My*` 접두사 전면 제거 (`MyCoroutine` → `CoroutineRunner`)
-- `u*` 소문자 시작 접두사 제거 (`uScrollViewMgr` → `InfiniteScrollView`)
-- `Mgr`, `_Mgr` 축약 → 풀 네임 (`Mgr` → `Manager`, 단 통용 시 유지 가능)
-- `_` 구분자 제거, PascalCase 준수 (`Set_Coroutine` → `SetCoroutine`)
-- `Regist*` 오탈자 → `Register*`
-- 기존 `FilGoodBandits` 네임스페이스 모두 → `BurningTimes.*` 로 재작성
-
-### 3-2. 의존성 단절
-- 수상한 잡화점 전용 enum/class 참조 전부 제거
-- `ObscuredInt` / `ObscuredLong` (ACTk) 참조는 선택 레이어로 재설계 (`INumericProtection`)
-- 테이블 조회(`table_*`) 참조 제거, 데이터 추상 인터페이스(`IDataTable`)로 대체
-
-### 3-3. 변형 방향
-- **싱글톤 감소**: 필요 최소 외에는 순수 클래스 + DI 패턴 친화로
-- **이벤트 기반 통신**: `EventBus` 적극 활용, 강결합 매니저 참조 회피
-- **제네릭 우선**: `UIAtlasMgr`처럼 특정 도메인 하드코딩된 메서드는 제네릭 팩토리로 재설계
-
-## 4. 추출 우선순위 (Tier 1 구현 순서 제안)
-
-| 순번 | 추출 대상 | Tier | 이유 |
-|------|----------|------|------|
-| 1 | MyCoroutine → CoroutineRunner | 1 | 다른 모듈이 의존하는 기반 |
-| 2 | MonoBehaviourSingletonTemplate → MonoSingleton | 1 | 전반적으로 쓰임 |
-| 3 | DSUtil 일부 → ValidationEx/ObjectEx/FormatEx/EnumEx | 1 | 유틸 기반 |
-| 4 | MyEnumToInt → EnumToInt | 1 | 성능 유틸 |
-| 5 | SafeArea (UGUI 버전) → SafeAreaBorder | 1 | UGUI 주력 방침 반영 |
-| 6 | UIAtlasMgr → SpriteAtlasRegistry | 1 | UGUI 기본 인프라 |
-| 7 | ErrorLogHookManager → Log 훅 통합 | 1 | 로깅 인프라 |
-| 8 | BackKeyAdd → BackKeyHandler | 1 | UGUI 주력 관련 |
-| 9 | uScrollView → InfiniteScrollView | 1 | 복잡도 중간 |
-| 10 | AddrHandleBase → AddressableHandle | 2 | Addressable 모듈 |
-| 11 | CryptoUtil → CryptoUtil (+ICryptoProvider) | 3 | 서버팀 합류 시점 |
-
-## 5. 추출 후 수상한 잡화점 자체 정리 (별도 과제)
-
-수상한 잡화점 프로젝트는 새 코어를 **적용하지 않지만**, 추출 과정에서 드러난 오염은 기록해 둠.
-
-### 발견된 C11 관점 문제 (수상한 잡화점 내부)
-- **네임스페이스 부재**: 대부분 global namespace (SafeArea.cs만 `FilGoodBandits`)
-  → 장기 리팩토링 대상 (우선순위 낮음, 기능에는 영향 없음)
-- **`My*`, `u*` 접두사 혼재**: 일관성 부족
-- **매니저 싱글톤 과다**: `uScrollViewMgr`, `UIAtlasMgr`, `BackKeyMgr`, `EffectMgr`, `ProjectileMgr` 등 → 결합도 높음
-- **DSUtil 거대화(1,406줄)**: 유틸과 게임 로직이 혼재 → 장기 분해 대상
-
-이 문제들은 **이번 프로젝트에서 손대지 않음** (개발 중단 리스크). 추출 과정에서만 반영.
-
-## 6. 다음 작업
-
-| # | 작업 | 선행 조건 |
-|---|------|----------|
-| 1 | PD님과 NAS Git 저장소 위치·접근 방식 협의 | 없음, 즉시 가능 |
-| 2 | 패키지 스켈레톤 생성 (`package.json`, `asmdef`, 폴더 틀) | 저장소 위치 확정 |
-| 3 | Tier 1 구현 시작 (위 4절 순번 1번부터) | 스켈레톤 완료 |
-| 4 | 수상한 잡화점 개발 준비 (Phase 0-B/C) 재개 | Tier 1·2 진행 중 병행 가능 여부는 PD님 판단 |