feat(BT·Phase2C): 수상한잡화점 삭제 + feedback 추상화 + 아카이브 재압축 + 조직 전환 완결

PD님 2026-04-21 결정 1~5 집행.

## 결정 1·P17 완전 폐기
- SKILL.md P17 섹션 완전 삭제
- 폐기_규칙_아카이브.md에 6필드 기록
- CLAUDE.md 요약 P17 1줄 제거

## 결정 2·P29 EerieVillage용 재작성
- P29-3 "현 프로젝트(수상한 잡화점) 활용 방침" → "EerieVillage 활용 방침" B안
- Tier 1 16종 중 플랫포머 유효 항목 선별 가이드
- 2D 플랫포머 특화 컴포넌트 Tier 2 신규 검토

## 결정 3·조직공지 필터링 (팀장급 논의)
- 개발팀장·기획팀장 Task 병렬 논의 수행
- 두 팀 모두 삭제 합의 10건 삭제 (OI-2·OI-5·Phase3 NAS·GIT v2 결재·초안·임시 안건·세션 이어받기·v1 체크리스트·bak 등)
- 규칙 진화사 공지 18건 + 폐기/방향전환 아카이브 + v2 체크리스트 보존

## 결정 4·feedback 단순 치환
- memory/org/ 6개 파일 "수상한잡화점" → "이전 프로젝트" sed

## 결정 5·분량 초과 4건 재압축
- 기획팀장: 12,359자 → 7,911자 (36% 감축)
- balance-designer: 5,500자 → 4,448자
- 개발팀장: 11,800자 → 6,978자 (41% 감축)
- 클라이언트팀장: 6,609자 → 6,077자
- 모두 목표 범위 달성

## 삭제 실측
- 프로젝트/수상한잡화점/ (41파일) · 신규 프로젝트/ · 02_수상한잡화점_추출대상_v1.md
- 공유/대화로그/수상한잡화점/ (4파일) · 소통/완료/ 35건 · 소통 허브 허브 파일들
- 공유/개발팀_자산/Unity_MCP_v1 · 서버_작업_참고자료 · 개발팀_백업 · 일일보고 · 인계서
- PD 지시 로그 완료 아카이브 97건 (개발 57 + 기획 40) 일괄 삭제
- 조직공지 10건 · 공통_업무_규칙_개정_제안 · 신PC_v1
- .gitignore 구 개발실/·기획실/ 경로 4줄 삭제

## 기타 정리
- CLAUDE.md 프로젝트 3종 → 2종 (BT.Framework + EerieVillage)
- agents·scripts 수상한잡화점 경로 참조 → EerieVillage 교체
- feedback_agent_path_boundary.md content-designer 2회차 위반 append
- INDEX.md BT 기준 재작성

## 변경 규모
184 files, 671 insertions, 31786 deletions.

## NerdNavis 의도적 잔존 (C5 정직성)
- GIT_REMOTE URL (paths.local.json·paths.local.json.template)
- UNITY_PROJECT_ROOT 실값 E:/NerdNavis/EerieVillage
- 역사 표기 (EerieVillage README, 시행착오 아카이브, 대화로그)

## 태그
- phase-2a-complete @ 5d5b1dd
- phase-2b-complete @ 44f7fb1
- phase-2c-complete @ (본 commit)

## 보류 (Phase 3 이관)
EerieVillage 착수 안건 7종 — 서버·Framework Tier 2·Unity MCP v2·세계관 SOT·2D 플랫포머 UX·Prove-2-of-3 이식성·어뷰징 경계값 재평가 (PD 결정 6)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.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 위반.

.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`
 
 ## 행동 지침

.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` — `#기획` 태그 엔트리
+- **2순위**: `공유/대화로그/EerieVillage/YYYY-MM-DD.md` — `#기획` 태그 엔트리
-- **3순위**: `프로젝트/수상한잡화점/기획/**/변경이력_*.md` — 밸런스 수치 변경 이력 (C6 자산 보호)
+- **3순위**: `프로젝트/EerieVillage/기획/**/변경이력_*.md` — 밸런스 수치 변경 이력 (C6 자산 보호)
 
 ## 감사 영역 5종
 
@@ -41,8 +41,8 @@ pm-auditor(PM 전담)·dev-auditor(개발 전담)만으로는 기획 고유 영
 - balance·content·level·narrative·system·ux 각자의 기록 의무
 - 전문 에이전트가 독립 호출될 때 내부 결정이 팀장·PM에 반영되는 경로
 
-### 5. P17 조건 배타 배치 규칙 등 프로젝트 규칙 준수
+### 5. 프로젝트 규칙 준수
-- 수상한 잡화점 고유 규칙(P17) 위반 감지
+- 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`
 
 ## 행동 지침

.claude/skills/BurningTimes-코어룰/SKILL.md

@@ -50,11 +50,10 @@ description: BurningTimes 조직의 헌법 제1원칙(5항 ①~⑤) + 헌법급
 
 ### 조직 현황 — 프로젝트 구성
 
-추후 프로젝트가 확장되면 점차 프로젝트 구성은 늘어날 수 있으며, 현재 우리 조직의 프로젝트는 **3종**으로 구성되어 있다:
+추후 프로젝트가 확장되면 점차 프로젝트 구성은 늘어날 수 있으며, 현재 BurningTimes 조직의 프로젝트는 **2종**으로 구성되어 있다:
 
-1. **코어 코드 프레임워크 개발** (`코어코드/BT.Framework/`) — 조직 자산 구축 프로젝트
+1. **코어 코드 프레임워크 개발** (`코어코드/BT.Framework/`) — 조직 자산 구축 프로젝트 (Tier 1 16/16 완결, Tier 2·3 확장 예정)
-2. **수상한 잡화점** (`프로젝트/수상한잡화점/`) — 현행 게임 개발 프로젝트
+2. **기묘한 고을 : 조선퇴마뎐 (EerieVillage)** (`프로젝트/EerieVillage/`) — BurningTimes 조직의 첫 번째 게임 개발 프로젝트 (Unity 6000.3.13f1 LTS, 2D PlatformerMicrogame 템플릿 기반)
-3. **신규 프로젝트** — 차기 프로젝트 (구체 내용 미정, 결정 시 본 섹션 갱신)
 
 ### 조직 핵심 자산 — 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`)로 개정 이력 영구 보존
+- 버전 태그·CHANGELOG·설계 문서(`프로젝트/코어프레임워크/01·03·04_*.md`)로 개정 이력 영구 보존
-- Tier 1 16/16 구현 완료 상태(2026-04-17)를 출발점으로 Tier 2·3 확장
+- **Tier 1 16/16 구현 완료** (2026-04-17 NerdNavis 조직 시절 완결 · BurningTimes 계승)을 출발점으로 Tier 2·3 확장
 
-### P29-2. 차기 프로젝트 적극 활용
+### P29-2. 차기·신규 프로젝트 적극 활용
 
-**차기 프로젝트부터** 우리 조직의 핵심 자산인 코어 코드 프레임워크 조직 자산으로 **적극 활용**하도록 한다.
+조직 핵심 자산인 BT.Framework를 **신규 프로젝트에 적극 활용**한다.
-- 차기 프로젝트 착수 시 `BT.Framework` 1순위 도입 검토
+- 프로젝트 착수 시 `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번)
+- **조직 현황·핵심 자산 안내** (BT 조직 프로젝트 2종 중 1번)
-- **방향전환 히스토리 아카이브** — 코어프레임워크 관련 방향 전환 기록
+- **방향전환 히스토리 아카이브** — BT.Framework 관련 방향 전환 기록
-- **P17** — 수상한잡화점 전용 프로젝트 규칙 (동일 층위)
+- **폐기 규칙 아카이브** — 구 P17(수상한잡화점 전용 ★ 조건 배타 규칙) 폐기 기록
 - **C14-5** — 본문 최신 + 히스토리 아카이브 (프레임워크 문서도 동일 원칙)
 
 ---
@@ -1509,9 +1486,9 @@ BurningTimes의 게임 개발 프로젝트에서 **기획팀은 모든 산출물
 - P30과 C11이 충돌하면 **총괄PM·PD님 판단 하에 조율** (기존 C7-C11 조율 규정 계승)
 
 ### P30-3. 적용 프로젝트
-- **수상한잡화점**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정
+- **EerieVillage (기묘한 고을: 조선퇴마뎐)**: 기획팀이 재미 우선 원칙으로 밸런싱·컨텐츠 결정 (BurningTimes 첫 게임 개발 프로젝트)
 - **차기 신규 프로젝트**: 동일 원칙 계승
-- **코어 프레임워크 프로젝트**: P29 계승·발전이 최우선 (재미는 상위 프로젝트 영역)
+- **BT.Framework**: P29 계승·발전이 최우선 (재미는 상위 프로젝트 영역)
 
 ---
 

.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

CLAUDE.md

@@ -68,7 +68,6 @@ PD님
 ### 프로젝트 규칙 요약 (활성 24개, 번호 구멍 허용)
 - **P1~P11** 기본 운영 (호칭·현황·이슈·토큰·의사결정·커뮤니케이션·위임·모델·트래킹·노하우·자율효율화)
 - **P13** 코드·의존성·환경 변경 관리 (구 P15 통합) / **P14** QA 게이트 / **P16** 산출물 추적성
-- **P17** 수상한잡화점 전용 ★ 조건 배타 배치 7종
 - **P18** 설계 문서화 의무 / **P19** PD님 직접 지시 트래킹 및 공유 의무
 - **P21** 세션 갱신 프로토콜 / **P21-2** 세션 공유 프로토콜
 - **P23** 기획 결정 재량 범위

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 호출 프롬프트 경로 규약 명시 의무

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 안건)

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}.{확장자}`)
 

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 역할 재검토 자진 상정 의무** |

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축을 함께 기록**한다

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 재량으로 작성 예정" 위임 우회
+### 오류 1 — 이전 프로젝트: "PM 재량으로 작성 예정" 위임 우회
-- **PM 명시 판단**: "수상한잡화점 대화로그 작성 필요 → PM 재량으로 작성 예정 (M1·M2·m1·m2·m3 영향 기록)"
+- **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 개정)

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하면 **부재로 판정**되어 "산출물 소실"로 오인할 위험.
 
 **근본 원인**: 대규모 파일 이관 시 로그·문서의 경로 레퍼런스를 동시 업데이트하는 **자동화된 참조 무결성 체크 부재**.
 

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
+if [[ "$FILE" == *"프로젝트/EerieVillage"* ]]; then
-  PROJECT="수상한잡화점"
+  PROJECT="EerieVillage"
 elif [[ "$FILE" == *"프로젝트/코어프레임워크"* || "$FILE" == *"코어코드/"* ]]; then
   PROJECT="코어프레임워크"
 elif [[ "$FILE" == *"공유/PD_지시_트래킹"* || "$FILE" == *"공유/조직공지"* || "$FILE" == *"공유/소통"* ]]; then

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
+  if [ "$NEEDS_SUSANG" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/EerieVillage/$TODAY.md" ]; then
-    ISSUES="${ISSUES}- 수상한잡화점 프로젝트 파일 수정 커밋 있으나 수상한잡화점 대화로그 부재 (P24 기록 대상 기준: 커밋이 프로젝트/ 하위 수정 시 필수)\n"
+    ISSUES="${ISSUES}- EerieVillage 프로젝트 파일 수정 커밋 있으나 EerieVillage 대화로그 부재 (P24 기록 대상 기준: 커밋이 프로젝트/ 하위 수정 시 필수)\n"
   fi
   if [ "$NEEDS_CORE" -eq 1 ] && [ ! -f "$REPO_ROOT/공유/대화로그/코어프레임워크/$TODAY.md" ]; then
     ISSUES="${ISSUES}- 코어프레임워크 프로젝트 파일 또는 조직 룰 수정 커밋 있으나 코어프레임워크 대화로그 부재 (차기 프로젝트 참고 자산 영향)\n"

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
 

공유/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 순차 진행 |
+| 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개 지시: ①기존 프로젝트 제거 + 시행착오 노하우 조직 자산화 (전 에이전트 동원) ②너드나비스→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님 결정 대기 |
+| 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) |
-| 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 섹션 참조
 
 ---
 
 ## 완료 아카이브
 
-> **🎯 즉답 체계 (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님이 완료 작업을 재보고 받는 상황은 조직 운영 전제(완료는 지시자가 이미 인지) 위반.
+> 이전 아카이브 구조 참조 필요 시 `git log --follow` + `git show phase-2b-complete:공유/PD_지시_트래킹/개발팀_PD_지시_로그.md` 경로로 역사 접근 가능 (tag 기반 롤백 경로 확보).
->
-> **감사 체크**: pm-auditor·dev-auditor·plan-auditor가 주기 감사 시 "활성 테이블의 완료 상태 잔류" + "즉답 접두 누락" 감지. 반복 발견 시 역할 재검토 안건 (C29-4 헌법급 위반).
 
 | # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
 |---|------|----------|----------|-----------|----------|----------|
-| 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 발행 규칙(버전 표기·변경 이력 섹션) 준수 |
 
-## 작성 예시
+(BurningTimes 조직 신규 — 완료 아카이브 초기화 상태)
-
-| # | 일시 | 지시 요지 | 처리 상태 | 산출물 경로 | 중단 사유 | 사후 조치 |
-|---|------|----------|----------|-----------|----------|----------|
-| N | 2026-04-15 09:00 | 빌드 파이프라인 점검 | 완료 | `공유/개발팀→기획팀/2026-04-15_REQ010_빌드점검.md` | - | - |

공유/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에서 교훈 추출 후 일괄 아카이브·삭제 예정 |
+| BT1 | 2026-04-21 | BurningTimes 조직 신설 — 기획팀 영역 전환 | 진행중 | Phase 1·2-A·2-B commit · 기획팀 아카이브 7종 `공유/조직자산/시행착오_아카이브/기획_*.md` | — | 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님 결정 대기 |
+| 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) |
-| 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 범위 외** (기획 → 개발 핸드오프 대상) |
 
 ---
 
 ## 완료 아카이브
 
+> **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+) |
+(BurningTimes 조직 신규 — 완료 아카이브 초기화 상태)
-| 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 섹션·메모리 기록 | - | - |

공유/개발팀_백업/README.md

@@ -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)

공유/개발팀_백업/개발_팀장_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 "조직 자산 계승" 이행 산출물.*

공유/개발팀_자산/Unity_MCP_편집_표준_워크플로우_v1.md

@@ -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 재발 방지 |

공유/공통_업무_규칙_개정_제안_C14_C15_v1.md

@@ -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님 최종 승인 대기 |

공유/대화로그/INDEX.md

@@ -1,10 +1,10 @@
-# 대화로그 태그 인덱스
+# 대화로그 태그 인덱스 (BurningTimes)
 
 > 자동 갱신 또는 수동 갱신. `grep -r "#태그" 공유/대화로그/`로 검색 가능.
 
 ## 프로젝트
-- `수상한잡화점/` — 현행 게임 프로젝트
+- `EerieVillage/` — 기묘한 고을: 조선퇴마뎐 (BurningTimes 첫 게임 프로젝트, 2026-04-21 출범)
-- `코어프레임워크/` — R&D 조직 자산
+- `코어프레임워크/` — BT.Framework 조직 자산
 - `조직운영/` — 프로세스·규칙·구조 관련
 
 ## 고정 태그
@@ -13,7 +13,9 @@
 - `#완료` `#진행중` `#보류` — 상태
 
 ## 최근 로그
-- **2026-04-17: 조직운영** (C27·C28·C29·C30·C31 신설, P21·P24 개정, P26 신설 + pm-auditor 에이전트 신설, 헌법 제1원칙 목표 2 명확화, Python 시뮬 폐기, 팀 기록 체계 감사)
+- **2026-04-21: 조직운영** — BurningTimes 조직 출범 (Phase 1·2-A·2-B·2-C 집행, NerdNavis → BurningTimes 전환)
-- 2026-04-17: 수상한잡화점 (#28 Unity MCP 전환 개발팀·기획팀 검토)
+- 이전 NerdNavis 조직 기록(2026-04-16 ~ 2026-04-20 조직운영 대화로그)은 조직 기억 자산으로 보존 (당시 시점 이벤트 기록)
-- 2026-04-16: 조직운영 (조직 대개편, P24 신설)
+
-- 2026-04-16: 수상한잡화점·코어프레임워크
+## 참고
+- 이전 NerdNavis 조직의 수상한잡화점 프로젝트 진행 과정 교훈은 `공유/조직자산/시행착오_아카이브/` 14종에 영구 보존
+- BurningTimes 조직 착수 시점 기록은 `조직운영/2026-04-21.md`가 기준점

공유/대화로그/수상한잡화점/2026-04-16.md

@@ -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 소재 파악

공유/대화로그/수상한잡화점/2026-04-17.md

@@ -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` 즉시 실행 채택
-

공유/대화로그/수상한잡화점/2026-04-18.md

@@ -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 기 작성 엔트리(상단)와 중복되지 않도록 개발 영역 작업에 한정 기록
-- **상태**: 완료 (소급 집행)

공유/대화로그/수상한잡화점/2026-04-20.md

@@ -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 승인 상신에 적합

공유/소통/PM→개발팀/2026-04-16_REQ_시뮬레이션_대응_기획팀_밸런스작업_지원.md

@@ -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)

공유/소통/dev-auditor→PM/2026-04-18_새PC동기화_최종점검_개발영역.md

@@ -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 병기 재판정 집행 후 완결 확인)

공유/소통/dev-auditor→PM/2026-04-18_원칙1_재검토_감사.md

@@ -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 허위 포장 배제.

공유/소통/plan-auditor→PM/2026-04-17_전수감사_문서정합성_기획영역.md

@@ -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):` — 본 보고 발행.

공유/소통/plan-auditor→PM/2026-04-18_새PC동기화_최종점검_기획영역.md

@@ -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*

공유/소통/plan-auditor→PM/2026-04-18_원칙1_재검토_감사.md

@@ -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 재량*

공유/소통/pm-auditor→PM/2026-04-17_전수감사_문서정합성_PM영역.md

@@ -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) 은폐 아닌 정합 확인 결과.

공유/소통/pm-auditor→PM/2026-04-18_새PC동기화_최종점검_메타감사.md

@@ -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 입력 자료 사전 식별 |

공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md

@@ -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 최종 판단 시 본 감사관 결론도 재검증 대상.

공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md

@@ -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 중앙화 체계

공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md

@@ -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` 말미 연관 섹션

공유/소통/개발팀→PM/2026-04-17_전수감사_자체교차검증_개발팀장관점.md

@@ -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)
-- "없음" 항목은 실제 확인 후 명시

공유/소통/개발팀→PM/2026-04-18_worktree_격리_근원해결_실무검토.md

@@ -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에 명시.

공유/소통/개발팀→PM/2026-04-20_C6-1_재발방지_Unity_MCP_워크플로우.md

@@ -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`

공유/소통/개발팀→PM/2026-04-20_Tool_Left_버그유무_점검.md

@@ -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)

공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md

@@ -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`

공유/소통/개발팀→기획팀/2026-04-20_Phase3_재개_로드맵_병렬착수.md

@@ -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 템플릿)

공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_시뮬실행_가이드_v1.md

@@ -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 템플릿)

공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1.md

@@ -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안 집행 |

공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v1_스켈레톤.md

@@ -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 실측 결과 입력 + 판정 | — |

공유/소통/개발팀→기획팀/2026-04-20_Unity_MCP_실측검증_리포트_v2.md

@@ -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 집행 |

공유/소통/개발팀→기획팀/2026-04-20_방어_쉴드_시뮬_현황_메모.md

@@ -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` (시뮬 스코프 외 명시)

공유/소통/기획팀→PM/2026-04-17_JSON_데이터_숙지_현황.md

@@ -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 유지 권장 (다음 지시 이행 시 맥락 참조용)

공유/소통/기획팀→PM/2026-04-17_전수감사_자체교차검증_기획팀장관점.md

@@ -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 병행 진행 중, 본 보고는 **작성자 자기 시야** 관점으로 차별화

공유/소통/기획팀→PM/2026-04-20_Day11-14_레벨축_본작업_v1.md

@@ -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건 본작업 완료 |

공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md

@@ -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건 · 이슈 감지 없음 |

공유/소통/기획팀→PM/2026-04-20_Day8-10_종결보고.md

@@ -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 착수 권고 명기 |

공유/소통/기획팀→PM/2026-04-20_Phase3_병렬진행_선행업무_요약_v1.md

@@ -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님 보고 대기*

공유/소통/기획팀→개발팀/2026-04-20_REQ발행조율요청.md

@@ -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 | 기획팀장 | 조율 요청 공문 발행 · 개발팀 회신 대기 |

공유/소통/기획팀→개발팀/Phase3_성장요소기여도_v2.md

@@ -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 맵 패턴 재검증 착수 조건 충족*

공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md

@@ -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님 직접 지시, 팀장 재량 진행 승인) |

공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md

@@ -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 사전 준비, 발행 대기) |

공유/소통/기획팀→개발팀/재검증보고_Phase0_1_2_v1.md

@@ -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 이관 항목 포함

공유/소통/완료/2026-04-14_REQ001_각성트리_퍼센트값_해석확인.md

@@ -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 재개 시: `/게임플레이`
-- 진행 추적: 개발팀장

공유/소통/완료/2026-04-14_REQ002_장비옵션_음수값_의미확인.md

@@ -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 재개 시: `/게임플레이` (장비옵션 파싱 로직 분석)
-- 진행 추적: 개발팀장

공유/소통/완료/2026-04-14_REQ003_인장_장착수제한_확인.md

@@ -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 테이블 정의)
-- 진행 추적: 개발팀장

공유/소통/완료/2026-04-16_REQ001_응답_각성트리_퍼센트값.md

@@ -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` 컬럼 포맷을 정수 또는 퍼센트 한 가지로 통일 권장. 현재 런타임 결과는 동일하므로 긴급 수정 불필요.

공유/소통/완료/2026-04-16_REQ002_응답_장비옵션_음수값.md

@@ -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. 장비 라인별 트레이드오프 구조를 인지하고 밸런싱에 반영 권장

공유/소통/완료/2026-04-16_REQ003_응답_인장_장착수제한.md

@@ -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`) 필요, 장착 중 인장은 합성 불가

공유/소통/완료/2026-04-16_RPT_시뮬레이션_대응_현황보고.md

@@ -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 수령 후 현황 보고 초안 작성 |

공유/소통/완료/2026-04-16_업무현황_개발실.md

@@ -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건.

공유/소통/완료/2026-04-16_업무현황_기획실.md

@@ -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# 비교 검증 입력값으로 보존 중

공유/소통/완료/2026-04-16_유니티프로젝트_점검_기획팀.md

@@ -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 폴더 내 부재 원인 확인 권고

공유/소통/완료/2026-04-16_코어코드_git통합_점검_개발팀.md

@@ -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_지시_트래킹 로그에도 등록됩니다.*

공유/소통/완료/2026-04-16_콘솔병렬실행_기술검토_개발팀.md

@@ -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

공유/소통/완료/2026-04-16_프로세스고도화_개선안_개발실.md

@@ -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 등록 + 테스트까지 개발팀 재량으로 진행 가능.

공유/소통/완료/2026-04-16_프로세스고도화_개선안_기획실.md

@@ -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께서 개발팀 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.

공유/소통/완료/2026-04-16_하이브리드구조_개발실의견.md

@@ -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 정신에 부합.

공유/소통/완료/2026-04-16_하이브리드구조_기획실의견.md

@@ -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께서 개발팀 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.

공유/소통/완료/2026-04-16_핫리로드대안_기술검토_개발팀.md

@@ -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)

공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md

@@ -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` 기준 실측.

공유/소통/완료/2026-04-17_Phase0-C_QP_응답서_개발팀.md

@@ -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 초안 작성.

공유/소통/완료/2026-04-17_RPT_서버역할_정리_초안.md

@@ -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 상신

공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md

@@ -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 / **배포**: 본 경로 확정 시 기획팀장에게 교차 공유

공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기획검토_기획팀.md

@@ -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 전환 관련 기획 검토 초안 |

공유/소통/완료/2026-04-17_감사보고_재량작업_일괄완료.md

@@ -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 타당성 실증

공유/소통/완료/2026-04-17_감사보고_팀기록체계_전수점검.md

@@ -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 우선순위 판단

공유/소통/완료/2026-04-17_서버_작업_참고자료.md

@@ -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 스펙 확정은 배정 후 설계 단계에서 진행.

공유/소통/완료/2026-04-17_서버개발자_업무지시서_최종본.md

@@ -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 갱신 + #신규 "어뷰징 책임 재확정·요약판 재작성" 등록·완료

공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md

@@ -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 지시 로그)

공유/소통/완료/2026-04-17_업무공유체계_점검_PM조직관점.md

@@ -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 권고.

공유/소통/완료/2026-04-17_업무공유체계_점검_개발팀.md

@@ -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 선례로 구현 리스크 낮음.

공유/소통/완료/2026-04-17_업무공유체계_점검_기획팀.md

@@ -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`)에 엔트리 추가 대상이며, 기획팀장 본 응답 종료 후 이어 기록 예정.