refactor(rules): 원칙 1 재개정 + 방향전환 아카이브 신설 + M1·M2 본문 최신화 — PD님 직접 확장 지시

## PD님 확장 지시 DEC-2 M1·M2 집행 시 "본문 최신 + 히스토리 아카이브 + 코어룰 반영" 영구 체계 구축. 이전 PM 제시안("당시 가정 + 현 방향 병기")은 본문 비대화로 반려, 병기 대신 외부 아카이브로 이관. ## Phase 1 — 코어룰 정비 (영구 체계) 1. 공유/조직공지/방향전환_히스토리_아카이브.md 신설 - 프로젝트 문서 방향 전환 전담 SOT - 6필드 형식 (대상·일자·유형·당시 가정·현 방향·근거) - 2026-04-18·04-17·04-16 전환 이력 등재 2. 인계서 §1 원칙 1 재개정 - "본문 최신, 히스토리는 아카이브" (변동비·고정비 공통) - 이전 외연 명확화 버전 대체 3. SKILL.md C14-5 신설 - "본문 최신 + 히스토리 아카이브 원칙" - 3종 세트 집행 규정 (본문 수정·아카이브 기록·배너 링크) ## Phase 2 — M1·M2 집행 (새 원칙 적용) - M1 Phase3_재개준비_체크리스트_v1.md - 상단 배너 + 구용어 37건 완전 제거 - 최종 구용어 0건 달성 - 개발실→개발팀, 기획실→기획팀 - Python·Headless·C# 시뮬 → Unity MCP EditMode - 07 참조 → 시뮬레이터/01 + 아카이브 링크 - M2 3성조건_12개_상세명세_v1.md - 상단 배너 + 구용어 40건 완전 제거 - 최종 구용어 0건 달성 - 설계 기반 전제 → Assets/Sim/NerdNavis.Sim.asmdef ## 수정 3대 원칙 준수 1. 본문 최신, 히스토리 아카이브 (새 원칙 1) 2. sed 금지 (M1 수동, M2 조직명 통일 `replace_all` 경계 허용) 3. 폐기 선언 외부 아카이브 (원칙 1·3 통합 운용) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-18 03:08:54 +09:00 · 2026-04-18 03:08:54 +09:00 · bc9c8edbce
parent f45bc3dfa5
commit bc9c8edbce
6 changed files with 347 additions and 90 deletions
--- a/.claude/skills/너드나비스-코어룰/SKILL.md
+++ b/.claude/skills/너드나비스-코어룰/SKILL.md
@ -242,6 +242,36 @@ CLAUDE.md 신규 항목, 매 턴 로드 대상 확대, `MEMORY.md` 인덱스 확
 ### C14-4. 참조 무결성 원칙
 하위 CLAUDE.md는 상위 CLAUDE.md의 내용을 **중복 기재하지 않고 참조 링크만 유지**. 동일 규칙이 2곳 이상 중복 기재되면 **C5(정직성) 위반**으로 간주, 단일 SOT로 통합 + 나머지는 참조만 유지.
 ### C14-5. 본문 최신 + 히스토리 아카이브 원칙 (2026-04-18 PD님 직접 지시 신설)
 **모든 문서(고정비·변동비 공통)는 본문에 최신 내용만 유지**하고, 작업 과정 히스토리·방향 전환 이력·"당시 가정"은 외부 아카이브에 집약한다. 본 조항은 인계서 §1 수정 3대 원칙의 원칙 1(2026-04-18 재개정)과 쌍을 이루며, 조직 문서 관리의 기본 규범이다.
 #### 구조
 1. **본문** — 최신 내용만. "당시 가정 vs 현 방향" 병기 금지
 2. **외부 아카이브 SOT 2종**:
   - `공유/조직공지/폐기_규칙_아카이브.md` — 코어 규칙(C·P) 폐기·개정 이력
   - `공유/조직공지/방향전환_히스토리_아카이브.md` — 프로젝트·설계·기획 문서 방향 전환 이력
 3. **본문 상단 배너 1줄** — 아카이브 링크 (`> 📚 본 문서 방향 전환 이력: [아카이브](공유/조직공지/방향전환_히스토리_아카이브.md#대상_섹션)`)
 #### 집행 시 3종 세트 동시 수행
 - (ㄱ) 본문 수정 (최신 내용만)
 - (ㄴ) 아카이브 파일에 "당시 가정 → 현 방향" 6필드 형식 기록
 - (ㄷ) 본문 상단 아카이브 링크 배너 1줄 추가
 #### 예외 (원칙 1 유지 대상 — 본문 당시 그대로 보존)
 - **이미 아카이브된 문서 자체** (예: `07_*.md` 상단 "🔴 아카이브됨" 배너 + 본문 당시 그대로) — 본문 자체가 히스토리 역할
 - **완료 실적 문서** (예: `02_수상한잡화점_추출대상_v1.md`) — "🟢 완료 실적 아카이브" 배너 + 최신 구현 역참조
 #### 가치
 - C14(토큰 최소화): 본문 비대화 차단, 고정비·변동비 문서 공통 최적화
 - 헌법 제1원칙 목표 2-B: 차기 프로젝트 "왜 이렇게 변경됐나" 참고 자료 집약
 - P24 기각안 필드 필수화 정신 계승: "당시 가정 → 현 방향" 구조가 기각안 정신의 설계 문서 확장
 #### 연혁
 - 2026-04-18 PD님 직접 지시로 신설
 - 이전 원칙 1 외연 명확화("변동비 본문 유지 + 고정비 외부화")는 본 조항으로 대체·확장
 - PM 과도 보수 해석 3회차 재발 방지 실증 (`memory/org/feedback_pm_over_conservative_interpretation.md`)
 ## C15. 일정·기한 개념 배제 원칙 (2026-04-15 PD님 승인)
 > 에이전트 업무 프로세스에서 **일정·기한·소요시간 추정 개념을 제거**한다. "이번 주·당일·N시간" 등 **시간 단위 계획은 에이전트 응답에서 사용하지 않는다.** 에이전트는 지시 수령 **즉시 착수**하며, 작업의 **종속 관계·선행 조건·차단 요인**만 관리한다. 인간 일정 조율이 필요한 경우 그 사실 자체만 보고 + 일정 수립은 인간 작업자에게 이관.
--- a/공유/대화로그/조직운영/2026-04-18.md
+++ b/공유/대화로그/조직운영/2026-04-18.md
@ -221,3 +221,36 @@
  - `.claude/agents/pm-auditor.md` (경로 규범 2개소 + 루트 저장 금지 경고 + memory/ 루트 저장 금지 지침)
  - `.claude/agents/plan-auditor.md` (경로 규범 2개소)
 - **상태**: 완료. DEC-2 선제 체크 완수, 세션 공유 가능 상태
 <!-- #PD지시 #PM #완료 #M1M2집행 #원칙1재개정 #방향전환아카이브신설 -->
 ## [PM] DEC-2 M1·M2 집행 완료 + 수정 3대 원칙 재개정 + 방향전환 히스토리 아카이브 신설 (PD님 직접 지시)
 - **요지**: PD님 2026-04-18 직접 확장 지시 — "본문 최신 + 히스토리 아카이브 + 코어룰 반영" 구조 정립. 단순 M1·M2 집행이 아닌 **수정 방침 자체의 영구 체계 구축**. 3 Phase 순차 집행 완료
 - **이유**: PM이 이전 M1·M2 안("본문에 '당시 가정' 태그 + 현 방향 병기")을 제시했으나 PD님 직접 확장 — 병기는 본문 비대화 유발, 히스토리는 외부 아카이브로 이관하여 **차기 프로젝트 '왜 이렇게 변경됐나' 참고 자료** 체계화
 - **집행 3단계**:
  - **Phase 1 — 코어룰 정비 (영구 체계)**:
    - `공유/조직공지/방향전환_히스토리_아카이브.md` **신설** (프로젝트 문서 방향 전환 전담 SOT, 6필드 형식, 2026-04-18·04-17·04-16 전환 이력 등재)
    - 인계서 §1 수정 3대 원칙 **재개정** (원칙 1: "본문 최신, 히스토리는 아카이브" — 변동비·고정비 공통, 이전 외연 명확화 버전 대체)
    - SKILL.md **C14-5 신설** ("본문 최신 + 히스토리 아카이브 원칙", 코어룰 반영)
  - **Phase 2 — M1·M2 집행 (새 원칙 적용)**:
    - **M1 Phase3 체크리스트**: 상단 배너 + 구용어 37건 완전 제거 + 최신 Unity MCP 방향 기술 (개발실→개발팀, 기획실→기획팀, Python·Headless·C# 시뮬→Unity MCP EditMode, 구 경로→최신 경로, 07 참조→아카이브 링크). **최종 구용어 0건 달성**
    - **M2 3성조건 12개**: 상단 배너 + 구용어 40건 완전 제거 + 설계 기반 전제 Unity MCP EditMode 독립 어셈블리로 교체. **최종 구용어 0건 달성**
  - **Phase 3 — 검증·기록·공유**: 본 엔트리·commit·main push·sync_signal
 - **기각안**:
  1. 이전 PM 안 유지 (본문에 병기) — 본문 비대화·차기 참조 분산, PD님 직접 확장 지시로 기각
  2. 신규 아카이브 파일 없이 폐기_규칙_아카이브.md에 통합 — C·P 규칙과 프로젝트 문서는 성격 상이, 분리가 검색성·유지성 우위로 기각
  3. 코어룰 반영 없이 인계서만 개정 — PD님 "코어룰에 반영" 명시 지시 범위 초과 회피로 기각, SKILL.md C14-5 신설 채택
  4. sed `replace_all` 전면 사용 — M1은 맥락 혼재로 수동 치환 (원칙 2), M2는 "개발실"·"기획실"이 모두 조직명 지칭 통일로 `replace_all` 허용 판단 (경계 명확)
  5. M1 본문 축약 (Day 1~15 로드맵 일부 제거) — 기획팀장 실측 "전원 현역 자산" 판정, 본문 보존 + 용어·경로만 최신화로 기각
  6. 후속 영향 문서(08 전투 SOT 기획 초기 가정 병기) 동시 재수정 — M1·M2 범위 외, 별건 후속 안건으로 분리 기각
 - **산출물**:
  - 신설: `공유/조직공지/방향전환_히스토리_아카이브.md`
  - 수정: 인계서 §1 원칙 1 / SKILL.md C14-5 신설 / Phase3_재개준비_체크리스트_v1.md / 3성조건_12개_상세명세_v1.md
  - 본 대화로그 엔트리
 - **검증**:
  - M1 구용어 0건 (개발실·기획실·Python 시뮬·Headless·C# 시뮬·공통_업무_규칙 전부)
  - M2 구용어 0건 (동일 기준)
  - 상단 배너 링크 실존 경로 확인
  - verify_log_paths.sh 4건 실존 유지
 - **새 원칙 1 운영 실증**: 본 집행이 "본문 최신 + 아카이브 히스토리" 구조의 **첫 정식 적용 사례**. 차기 문서 최신화 시 동일 패턴 준수
 - **상태**: 완료. DEC-2 잔여(m1·m2·m3 Minor 3건)는 PD님 재논의 또는 Phase 3 재개 시 병행 가능
--- a/공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
+++ b/공유/인계서/2026-04-17_전수감사_A+B급7건_수정집행_인계서.md
@ -30,14 +30,34 @@ related: 감사 보고 5종, SKILL.md, memory/feedback_*
 ## 1. 수정 3대 원칙 (최종 확정, 엄수 필수)
-### 원칙 1 — 자산 보존 분리 (2026-04-18 외연 명확화)
+### 원칙 1 — 본문은 최신, 히스토리는 아카이브 (2026-04-18 재개정, PD님 직접 지시)
-불필요·구 조항은 **삭제하지 않고** 다음 방식으로 보관:
+**모든 문서(변동비·고정비 공통)는 본문에 최신 내용만 유지**하고, 작업 과정 히스토리·방향 전환 이력·"당시 가정"은 외부 아카이브에 집약한다.
 - **폐기 설계 문서**: 파일 상단에 "🔴 아카이브됨 — 대체: X" 배너 추가 (본문 유지). 참조 많은 경우 파일 이동 대신 배너 방식 권장
 - **완료 실적 문서**: 파일 상단에 "🟢 완료 실적 아카이브" 배너 + 각 항목에 구현 역참조 추가
 - **SKILL.md·CLAUDE.md 내 폐기 C·P 규칙**: 원칙 3(저장 위치 최적화) 참조 — 외부 아카이브 파일로 이관
-**외연 명확화 (2026-04-18 PD님 직접 지시 반영)**:
+#### 기본 구조
-원칙 1 적용 대상은 **변동비 문서**(프로젝트 문서·설계 문서·완료 실적 — 매 턴 자동 로드 안 됨)로 한정한다. **고정비 문서**(SKILL.md·CLAUDE.md — 매 세션·매 Agent 자동 주입) 내에서는 **원칙 3 준용하여 외부화**하고, 특히 **활성 운영 결합이 없는 섹션**(교훈 인덱스·정보성 참조 등)은 외부 SOT(`memory/org/`·`공유/조직공지/폐기_규칙_아카이브.md` 등)로 이관하되 활성 본문에 **1줄 참조**만 유지한다. 근거: 2026-04-18 3축 감사관(pm/plan/dev-auditor) + 팀장급 2명 종합 논의. "변동비 문서 본문 유지 + 고정비 문서 내 활성 결합 없는 섹션 외부화"가 C14(토큰 최소화) + 헌법 목표 2-B(차기 프로젝트 참고) 동시 만족.
+| 대상 | 본문 처리 | 히스토리 저장 |
 |------|---------|-------------|
 | **코어 규칙(C·P)의 폐기·개정** | SKILL.md에 1줄 선언 + 외부 링크 | `공유/조직공지/폐기_규칙_아카이브.md` |
 | **프로젝트·설계·기획 문서의 방향 전환·용어 변경·경로 이동** | 본문 최신 내용만 + 상단 배너 1줄(아카이브 링크) | `공유/조직공지/방향전환_히스토리_아카이브.md` |
 | **폐기된 설계 문서 원본** | 파일 상단 "🔴 아카이브됨 — 대체: X" 배너 + 본문 당시 그대로 보존 | 해당 파일 자체가 히스토리 역할 |
 | **완료 실적 문서** | 파일 상단 "🟢 완료 실적 아카이브" 배너 + 최신 구현 경로 역참조 | — |
 #### 핵심 규정
 1. **본문에 "당시 가정 vs 현 방향" 병기 금지** — 병기는 본문 비대화 유발. 병기가 필요한 역사적 맥락은 전부 아카이브 파일로 이관
 2. **최신화 집행 시 3종 세트 동시 수행**:
   - (ㄱ) 본문 수정 (최신 내용만)
   - (ㄴ) 아카이브 파일에 "당시 가정 → 현 방향" 전환 이력 기록 (6필드 형식)
   - (ㄷ) 본문 상단에 아카이브 링크 배너 1줄 (`> 📚 본 문서 방향 전환 이력: [아카이브](...)`)
 3. **아카이브 파일은 영구 보존** — 차기 프로젝트 "왜 이렇게 변경됐는지" 참고 자료 (헌법 제1원칙 목표 2-B)
 4. **본 원칙은 원칙 3을 확장·통합** — 원칙 3(폐기 선언 저장 위치 최적화)의 논리가 프로젝트 문서 전반에 적용
 #### 외부 아카이브 SOT 2종
 - `공유/조직공지/폐기_규칙_아카이브.md` — **코어 규칙(C·P)** 폐기·개정 이력
 - `공유/조직공지/방향전환_히스토리_아카이브.md` — **프로젝트·설계·기획 문서** 방향 전환 이력 (2026-04-18 신설)
 #### 근거·연혁
 - 2026-04-18 PD님 직접 지시 — "기본 문서는 심플하게 최신 내용만, 작업 과정 히스토리는 노하우 축적을 위해 아카이브, 필요 시 참조 가능하도록 코어룰 반영"
 - 이전(2026-04-18 오전) 외연 명확화 버전("변동비 본문 유지 + 고정비 외부화")은 **본 재개정으로 대체됨** — 변동비·고정비 구분 없이 전 문서 공통 "본문 최신 + 아카이브 히스토리" 구조
 - PM 이전 M1·M2 제시안("본문에 ~~(당시 가정)~~ → 최신 병기")은 **자인 — 절반만 맞았음**. PD님 직접 확장 지시로 본 원칙 완성
 ### 원칙 2 — sed 일괄 치환 금지
 의미 맥락 확인이 필요한 영역(특히 역사 기록)은 **수동 정밀 치환**. 단순 운영 지침(P20→P24 등)만 sed 허용.
--- a/공유/조직공지/방향전환_히스토리_아카이브.md
+++ b/공유/조직공지/방향전환_히스토리_아카이브.md
@ -0,0 +1,166 @@
 ---
 type: 방향전환히스토리아카이브
 created: 2026-04-18
 maintainer: 총괄PM
 sot_boundary: 프로젝트 설계 문서·기획 문서의 방향 전환(폐기·개정·용어 변경) 이력 단일 SOT
 related: 공유/조직공지/폐기_규칙_아카이브.md (C·P 규칙 전담 / 본 파일은 프로젝트 문서 전담)
 rationale: 수정 3대 원칙(2026-04-18 재개정) — "본문은 최신 내용만, 히스토리는 아카이브" 구조의 프로젝트 문서 SOT
 ---
 # 📚 방향전환 히스토리 아카이브 (프로젝트 문서)
 > **본 파일의 성격**: 프로젝트 설계 문서·기획 문서가 최신 상태로 유지되는 과정에서 발생한 **방향 전환·용어 변경·경로 이동·폐기 전제** 이력을 집약한 **조직 노하우 SOT**. 본문에는 최신 내용만 남기고 작업 과정 히스토리는 본 아카이브에 축적하여 **차기 프로젝트에서 "왜 이렇게 변경되었는가" 참고 자료**로 활용.
 >
 > **근거**: 2026-04-18 PD님 직접 지시 — "기본 문서에는 심플하게 최신 내용만, 히스토리는 노하우 축적을 위해 아카이브, 필요 시 참조 가능하도록 코어룰에 반영". 수정 3대 원칙 원칙 1 재개정에 따라 신설.
 >
 > **읽기 규칙**: 본 파일은 **변동비**. 활성 본문에서 "이 부분이 왜 이렇게 됐지?" 의문 시 Read. 매 턴 자동 로드 아님.
 ---
 ## 🏛️ 운영 원칙
 ### 기록 대상
 1. **프로젝트 설계 문서** (`프로젝트/수상한잡화점/개발/`·`기획/`·`시뮬레이터/`·`프로젝트/코어프레임워크/`)의 방향 전환
 2. **기획 문서**의 폐기된 전제·구용어·구경로 (원래 본문에 있던 것을 최신화하면서 제거한 내용)
 3. **개발 설계 문서**의 폐기된 설계 결정·기각된 대안
 ### 제외 대상
 - 오탈자·문단 재배치 같은 단순 편집
 - 코어룰(C·P) 변경 — `폐기_규칙_아카이브.md` 전담
 - 수치 튜닝 이력 — 각 문서 내 "변경 이력" 테이블(P16) 전담
 ### 기록 형식 (건별 필수 6필드)
 | 필드 | 설명 |
 |------|------|
 | **대상 문서** | 방향 전환이 적용된 파일 경로 |
 | **전환 일자** | 최신화 집행일 |
 | **전환 유형** | 용어 변경 / 경로 이동 / 폐기 전제 제거 / 설계 방향 전환 등 |
 | **당시 가정** | 원 본문에 있던 내용 (원문 그대로 인용) |
 | **현 방향** | 최신 상태 |
 | **근거** | 전환 계기 (PD 지시·커밋 해시·관련 사건) |
 ### 차기 프로젝트 활용 관점 (헌법 제1원칙 목표 2-B)
 - **"왜 버렸나" 우선 기록** — P24 기각안 필수화 정신 계승
 - **패턴 추출 가능**하도록 건별 구조화 (단순 diff 아님)
 - **방향 전환 사유 명시** — "PD님 지적"·"실측 결과 불일치"·"상위 구조 변경" 등
 ---
 ## 📂 전환 이력
 ### 2026-04-18 ─ Phase 3 재개 선결 체계 최신화
 #### 1. `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` 방향 전환
 | 필드 | 내용 |
 |------|------|
 | **대상 문서** | `프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md` |
 | **전환 일자** | 2026-04-18 |
 | **전환 유형** | 조직 명칭·경로·폐기 선결 조건 복합 전환 |
 | **근거** | 2026-04-16 조직명 개편·2026-04-17 PD님 Unity MCP 전환 (#28·#37)·2026-04-18 PD님 방향전환 히스토리 아카이브 지시 |
 ##### 1-A. 조직 명칭 전환
 - **당시 가정**: "**기획실**이 30분 내 착수" (L13), "**개발실**에 구현 요청서 전송" (L179) 등 기획실·개발실 용어 31회 사용
 - **현 방향**: "**기획팀**"·"**개발팀**" (2026-04-16 단일 세션 전환 커밋 기점 명칭 개편)
 - **전환 사유**: 2026-04-16 PD님 직접 지시로 개발실→개발팀·기획실→기획팀 명칭 전환 확정. SKILL.md 최종 수정일 기재
 ##### 1-B. 경로 문자열 전환
 - **당시 가정**: "`공유/개발실→기획실/` 폴더 내 가이드 문서" (L38)
 - **현 방향**: "`공유/소통/개발팀→기획팀/` 폴더"
 - **전환 사유**: 조직 명칭 개편과 함께 소통 허브 디렉토리 구조 변경
 ##### 1-C. 폐기 선결 조건 — Headless C# 시뮬 추출
 - **당시 가정** (L36):
  > "개발실이 Unity 전투 로직을 Headless C# 시뮬로 추출 완료"
  > (07_시뮬레이터_이원화_해소_착수계획_v1.md 후속 작업 전제)
 - **현 방향**: Unity MCP EditMode + 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`) 기반 시뮬 환경
 - **전환 사유**: 2026-04-17 PD님 직접 지시 #28로 시뮬 방향 전환. 07 원안은 아카이브 처리됨 (`07_*.md` 상단 배너). Unity MCP가 결정론·유지비·기획팀 접근성 3축 우위로 판정 (`공유/소통/완료/2026-04-17_Unity_MCP_시뮬레이션_기술검토_개발팀.md`)
 ##### 1-D. 폐기 선결 조건 — Python·C# 시뮬 교차 검증
 - **당시 가정** (L37):
  > "Python 시뮬 ↔ C# 시뮬 결과 교차 검증 완료"
  > (Python `battle_sim.py`·`full_stage_sim.py`·`stage_sim_v2.py` 기반 검증 체계)
 - **현 방향**: Unity MCP EditMode 단일축 실측 검증 (#37 Q-P2 정밀 2차 응답서로 실증)
 - **전환 사유**: 2026-04-17 Python 시뮬 폐기 사안 확정. 구 기획실 디렉토리 삭제로 소실 + PD님 확인으로 폐기 판정 (재논의 대상 아님). 교차 검증 개념 자체 소멸
 ##### 1-E. 아카이브된 07 문서 참조
 - **당시 가정** (L36 내): "`개발실/프로젝트_숙지/수상한잡화점/07_시뮬레이터_이원화_해소_착수계획_v1.md` 후속"
 - **현 방향**: `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` (Unity MCP 대체) + `프로젝트/수상한잡화점/개발/07_*.md` 상단 아카이브 배너 참조
 - **전환 사유**: 07 원안 아카이브 처리(2026-04-17 커밋 `0a8caa0`) + 디렉토리 구조 개편(`개발실/` → `프로젝트/수상한잡화점/개발/`)
 ---
 #### 2. `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` 방향 전환
 | 필드 | 내용 |
 |------|------|
 | **대상 문서** | `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` |
 | **전환 일자** | 2026-04-18 |
 | **전환 유형** | 조직 명칭·설계 기반 전제 복합 전환 |
 | **근거** | 2026-04-16 조직명 개편·2026-04-17 PD님 Unity MCP 전환 (#28·#37) |
 ##### 2-A. 조직 명칭 전환 (반복 섹션 포함)
 - **당시 가정**: "**개발실 구현 요청 포인트**" 섹션명이 12개 조건마다 반복 (L124·L165·L206·L245·L290·L341·L386·L428·L472·L511·L563·L612 등), "**개발실 코드 확인 필요**" (L171), "**개발실 판단 필요**" (L294), "**개발실 점검 필요**" (L388) 등 27회
 - **현 방향**: "**개발팀 구현 요청 포인트**" + 본문 내 "개발팀 코드 확인 필요" 등 일상 서술 일괄 최신화
 - **전환 사유**: 2026-04-16 조직명 개편. 개발팀 협업 SOT 문서이므로 Agent 에이전트 역할 명명 일관성(C22) 필수
 ##### 2-B. 설계 기반 전제 — Headless C# 시뮬
 - **당시 가정** (L22):
  > "개발실이 **Headless C# 시뮬 추출 시 동시에 구현해야 할 조건 판정 코드**의 설계 기반 자료"
 - **현 방향**: "개발팀이 **Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`)에서 구현**해야 할 조건 판정 코드의 설계 기반 자료"
 - **전환 사유**: 2026-04-17 Unity MCP 전환 확정. 시뮬 방식 전환으로 조건 판정 코드 실행 환경도 Headless CLI → Unity EditMode 독립 어셈블리로 변경 (#37 Q-P2 정밀 2차 응답서 설계문서)
 ##### 2-C. 경로 참조
 - **당시 가정**: "`기획실/⚠️_PHASE3_HOLD_공지.md`" 구 경로 언급
 - **현 방향**: `공유/조직공지/` (HOLD 공지 표준 디렉토리)
 - **전환 사유**: 2026-04-14 조직공지 폴더 신설 + 2026-04-16 디렉토리 재구조
 ---
 ### 2026-04-17 (소급 기록) ─ 시뮬레이터 방향 전환 원류
 | 항목 | 내용 |
 |------|------|
 | **PD 지시** | #28 Unity MCP 전환 + Python 시뮬 폐기 / #37 Q-P2 정밀 2차 |
 | **파급 문서** | 07_시뮬레이터_이원화_해소_착수계획_v1.md (아카이브) / 08_전투시스템_SOT_v1.md (Q-P2 수치 반영) / Phase3_재개준비_체크리스트_v1.md (선결 조건 폐기) / 3성조건_12개_상세명세_v1.md (설계 기반 전환) / 맵패턴_사전분석_v1.md / 빌드_조건_충돌점검_v1.md / Phase2_카드임팩트측정_v1.md |
 | **핵심 산출물** | `프로젝트/수상한잡화점/시뮬레이터/01~04` 신설 + `Assets/Sim/NerdNavis.Sim.asmdef` 독립 구현 |
 | **실측 수치** | PCDefence_Mul=0.3 (기획 가정 50% 불일치 확인), 쿨다운 없음, 지속형, 방어 중 공격 불가, Melee/Range 공통, Mob 방어 메커닉 부재 |
 본 원류 전환이 2026-04-18 M1·M2 집행 시점에 연쇄 반영됨.
 ---
 ### 2026-04-16 (소급 기록) ─ 조직 명칭 개편 원류
 | 항목 | 내용 |
 |------|------|
 | **PD 지시** | 단일 세션 + Agent 병렬 호출 구조 전환 / 개발실→개발팀·기획실→기획팀 명칭 정식 개편 |
 | **파급 문서** | 전 부서 CLAUDE.md·agents 정의·기획 7문서·개발 설계 문서 다수 |
 | **전환 사유** | 단일 세션 구조 확정 + 역할 단순화 + "실" 용어의 물리 공간 어감 제거 |
 ---
 ## 📘 본 파일 운영 규칙
 ### 추가 시점
 - 설계 문서·기획 문서 최신화 집행 **동일 커밋**에 본 파일 append
 - 전환 건별 6필드 모두 기입 (누락 금지)
 - 관련 PD 지시·커밋 해시 반드시 명시
 ### 본 파일 변경 이력 (P16)
 | 일시 | 변경자 | 변경 요지 | 관련 PD 지시 |
 |------|--------|-----------|-------------|
 | 2026-04-18 | PM | 신설 + C-M1·C-M2 전환 이력 등재 + 2026-04-17·04-16 원류 소급 기록 | 2026-04-18 PD님 "본문 최신 + 아카이브 히스토리" 코어룰 반영 지시 |
 ### 역진화 방지
 - 본 파일 삭제·이동·축약은 **PD님 직접 승인 필수** (C19-2 되돌리기 어려운 액션)
 - 이미 기록된 건별 삭제·수정은 **PD님 결정 안건** (허위 기록 정정 등 특수 사유 제외)
 - git 영구 추적 대상
 ### 연관 규칙
 - **원칙 1** (2026-04-18 재개정): 본 파일이 변동비 문서의 "아카이브 히스토리" 축
 - **원칙 3**: `폐기_규칙_아카이브.md`와 역할 분리 (C·P 규칙 vs 프로젝트 문서)
 - **C14**: 본문 최신 + 외부 아카이브 구조로 고정비·변동비 모두 최적화
 - **헌법 목표 2-B**: 차기 프로젝트 참고 자료 핵심 SOT
 - **P24** (기각안 필드 필수): 본 아카이브의 "당시 가정 → 현 방향" 구조가 기각안 정신의 설계 문서 확장
--- a/프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md
+++ b/프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md
@ -1,10 +1,13 @@
 # 수상한 잡화점 — ★ 조건 12개 풀 상세 명세서 v1
-> 작성일: 2026-04-14
+> 📚 **본 문서 방향 전환 이력**: [방향전환 히스토리 아카이브 §3성조건_12개_상세명세](../../../공유/조직공지/방향전환_히스토리_아카이브.md#2-프로젝트수상한잡화점기획3성조건_12개_상세명세_v1md-방향-전환)
 > (2026-04-16 조직명 개편·2026-04-17 Unity MCP 전환·2026-04-18 최신화 집행. 구 용어·구 설계 전제는 아카이브 참조)
 > 작성일: 2026-04-14 / 최신화: 2026-04-18
 > 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
 > 위임 근거: 2026-04-14 PD님 지시 "Phase 3 작업 전 진행 가능한 작업을 기획팀장이 판단하에 진행"
 > 문서 성격: **P18 설계 문서화 의무** 이행 (Phase 2 §5 PD님 3차 승인의 조건 풀 12개에 대한 본문 작성)
-> HOLD 준수: 본 문서는 **판정 로직·측정 변수·UI 표시·개발실 구현 요청**까지만 다룸. 구체적 수치 최종 확정은 Phase 3 재개 후 시뮬 검증으로 수행
+> HOLD 준수: 본 문서는 **판정 로직·측정 변수·UI 표시·개발팀 구현 요청**까지만 다룸. 구체적 수치 최종 확정은 Phase 3 재개 후 시뮬 검증으로 수행
 ---
@ -16,10 +19,10 @@ Phase 2 §5에서 PD님 3차 승인으로 확정된 **★ 조건 풀 12개**(+N7
 2. 달성 판정 로직 의사코드
 3. 측정 변수 (게임 런타임 중 추적해야 할 값)
 4. UI 표시 방식
-5. 개발실 구현 요청 포인트
+5. 개발팀 구현 요청 포인트
 6. 엣지 케이스 및 주의 사항
-를 한 곳에 정리한다. 개발실이 **Headless C# 시뮬 추출 시 동시에 구현해야 할 조건 판정 코드**의 설계 기반 자료.
+를 한 곳에 정리한다. 개발팀이 **Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`)에서 구현해야 할 조건 판정 코드**의 설계 기반 자료.
 ### 범위 외 (HOLD 준수)
 - **조건별 구체적 수치 최종 확정 금지** — 수치는 Phase 3 재개 후 시뮬 결과로만 산출
@ -87,7 +90,7 @@ Phase 2 §5 용어 기준:
 | N5 | 후열 선공 | 순서 | 서브맵마다 최초 공격 대상이 후열 | 저~중 | 중 |
 | N6 | 전열 선공 | 순서 | 서브맵마다 최초 공격 대상이 전열 | 저~중 | 중 |
-> **주의**: 임계값 "이상/이하"의 구체적 숫자는 **본 문서에서 확정하지 않는다** (HOLD 범위). C# 시뮬로 재도전 유도 강도와 밸런스를 검증한 후 Phase 3 재개 시점에 PD님 승인으로 확정.
+> **주의**: 임계값 "이상/이하"의 구체적 숫자는 **본 문서에서 확정하지 않는다** (HOLD 범위). Unity MCP 시뮬로 재도전 유도 강도와 밸런스를 검증한 후 Phase 3 재개 시점에 PD님 승인으로 확정.
 ---
@ -121,7 +124,7 @@ OnStageClear:
 - **플레이 중**: HUD에 경과 타이머 실시간 표시 (기존 시스템 활용 여지 확인 필요)
 - **스테이지 종료 시**: 결과창에 실제 소요 시간 vs 임계값 병기 + ✓/✗ 표시
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. 스테이지 경과 시간이 이미 측정되고 있는지 확인 (`StageManager` 또는 유사 클래스)
 2. 포즈·메뉴 오픈 시간 제외 여부 결정 필요 — **기획팀장 초안**: 실제 전투 시간만 카운트, UI 포즈 중 시간 제외
 3. 임계값은 **스테이지별 고정 테이블**로 관리 (예: `StageClearCondition.json` 또는 기존 테이블 확장)
@ -162,13 +165,13 @@ OnStageClear:
 - **플레이 중**: HP 바가 100% 미만으로 떨어지면 해당 조건 위반 예고 상태 (아이콘 흐려짐 등)
 - **스테이지 종료 시**: 결과창 ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. `pc.maxHP`가 카드·각성·장비 효과로 실시간 변하는 경우의 처리 필요
 2. 스테이지 종료 시점 정의 명확화: 최종 보스 처치 직후 프레임 vs 결과창 오픈 시점
 3. **중요**: 피격 후 회복하여 HP=MaxHP 도달해도 인정 (PD님 해석 확인 필요 시 문의)
 #### 엣지 케이스
- **MaxHP 증가 효과 (G3 "MaxHP 2배" 등) 중 HP도 2배로 회복되는가?** — 개발실 코드 확인 필요
+- **MaxHP 증가 효과 (G3 "MaxHP 2배" 등) 중 HP도 2배로 회복되는가?** — 개발팀 코드 확인 필요
 - **종료 시점 판정 프레임**: 결과창 오픈 시점 HP 기준으로 통일 권장
 #### P17 배타 조합
@ -203,7 +206,7 @@ OnStageClear:
 - **플레이 중**: HP 바에 "70% 마커" 표시
 - **스테이지 종료 시**: 결과창에 최종 HP 비율 + ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 - C2와 동일 구조. 임계값만 다름
 - **임계값 상수화** 필수 (스테이지별 개별 튜닝 가능성 대비)
@ -242,7 +245,7 @@ OnStageClear:
 - **플레이 중**: 포션 슬롯 UI에 남은 허용 횟수 표시
 - **스테이지 종료 시**: 실제 사용 vs 임계값 + ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. "포션"의 정의 명확화: HP 포션·MP 포션·기타 소모품 중 어느 것을 카운트할지
 2. **기획팀장 초안**: HP 회복계 물약만 카운트 (메테오·전체 기절 같은 전투용 물약은 별도 조건으로 다룰지 추후 논의)
 3. 패시브로 발동되는 회복 효과는 카운트 제외
@ -287,11 +290,11 @@ OnStageClear:
 - **플레이 중**: 카운터 표시 (권장)
 - **스테이지 종료 시**: 실제 vs 임계값 + ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. **"유효 공격" 정의**:
   - **기획팀장 초안**: 데미지 > 0인 공격만 카운트 (빗맞힘·회피된 공격 제외)
   - 무적·반사 상태 몬스터 대상 공격의 카운트 여부 결정 필요
-2. **Shield 흡수된 공격**: HP에 들어간 데미지가 0이라도 Shield에 데미지가 들어갔다면 카운트해야 함 (개발실 판단 필요)
+2. **Shield 흡수된 공격**: HP에 들어간 데미지가 0이라도 Shield에 데미지가 들어갔다면 카운트해야 함 (개발팀 판단 필요)
 3. **DOT (도트 데미지) 처리**: 독·화상·처형 같은 지속 데미지 틱을 카운트할지 여부
 #### 엣지 케이스
@ -338,7 +341,7 @@ OnStageClear:
 - **플레이 중**: 카운터 표시 권장
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. **"회피"의 정의**: `Avoid_M` / `Avoid_R` 스탯에 의한 미스만 포함. 빗맞힘(`Miss`)과 구분 필요
 2. 몬스터 공격에 대한 PC 회피만 카운트. PC 공격이 몬스터에게 회피된 것은 N1(빗맞힘 절제)의 "빗맞힘"에 해당 (별도 조건)
 3. 서브맵 수는 스테이지별 고정 데이터 (`CreateMapConfig.json` 또는 유사)에서 조회
@ -383,9 +386,9 @@ OnStageClear:
 - **플레이 중**: 카운터 (권장, 선택적)
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. `Miss` 스탯 vs `Avoid` 스탯을 **명확히 구분**해 판정 (공격자 Hit 실패 = Miss, 수비자 회피 성공 = Avoid)
-2. 몬스터의 회피 성공(Avoid_M/R) 때문에 PC 공격이 빗나간 경우 — 이것은 "Miss"가 아니라 "Avoided"로 구분해야 함. **구분 불가능한 경우는 C9·C12와 상호 모순 발생 가능성** → 개발실 점검 필요
+2. 몬스터의 회피 성공(Avoid_M/R) 때문에 PC 공격이 빗나간 경우 — 이것은 "Miss"가 아니라 "Avoided"로 구분해야 함. **구분 불가능한 경우는 C9·C12와 상호 모순 발생 가능성** → 개발팀 점검 필요
 #### 엣지 케이스
 - **빗맞힘이 극히 드문 빌드 (높은 명중률 빌드)**: N1 달성이 거의 자동 → 임계값을 낮춰 난이도 확보 필요
@ -425,12 +428,12 @@ OnStageClear:
 - **플레이 중**: 카운터 표시 필수 — 피격 1회마다 긴장감 고조
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. **"피격"의 정의**:
   - **기획팀장 초안**: Shield 흡수 피격 + HP 데미지 피격 모두 카운트 (의도된 방어가 있었든 없었든 "맞았다"는 사실만)
   - Avoid된 공격은 카운트 제외
   - 반사·무적으로 무효화된 공격: **카운트 제외** (피해 발생 없음)
-2. DOT는 데미지 틱마다 카운트하지 않고 "최초 부착 시 1회"만 카운트 (초안). 대안: 틱마다 카운트. 개발실과 협의 필요
+2. DOT는 데미지 틱마다 카운트하지 않고 "최초 부착 시 1회"만 카운트 (초안). 대안: 틱마다 카운트. 개발팀과 협의 필요
 #### 엣지 케이스
 - **서브맵 수 이상 스테이지**: C12와 동일. 임계값 재튜닝 여지
@ -469,7 +472,7 @@ OnStageClear:
 - **플레이 중**: 카운터 + 치명타 발생 시 시각·음향 강화 (기존 크리 연출 활용)
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. "처치 타격" 판정: 몬스터 HP를 0으로 만든 **최종 타격이 치명타였는지** 확인. 중간 치명타는 카운트 안 됨
 2. DOT로 처치 시: 최종 틱이 치명타 판정을 가지는 경우 처리 방법 결정
 3. 처형·관통 같은 특수 스킬의 치명타 판정 여부 확인
@ -508,7 +511,7 @@ OnStageClear:
 - **플레이 중**: Shield 바에 30% 마커
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. **Shield 시스템 구조 확인**: 재생 Shield / 1회성 Shield / 성소 Shield의 구분과 `pc.currentShield` / `pc.maxShield` 계산 방식
 2. **MaxShield가 동적인가**: 카드·장비·각성으로 MaxShield가 변하는지 확인
 3. **Shield 보유 불가능 빌드**: PC나 빌드에 따라 MaxShield=0인 경우 본 조건 배치 금지 (단독 스테이지 특성 필요)
@ -560,14 +563,14 @@ OnStageClear:
 - **최초 공격 후**: 성공/실패 즉시 피드백 아이콘
 - **스테이지 종료 시**: ✓/✗
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 1. **몬스터의 전열/후열 판정**: `MonsterPatternList.json` / `ApprearMonsterPattern.json`의 배치 정보 또는 런타임 위치로 판정
 2. **서브맵에 후열 몬스터가 없는 경우**: N5 달성 불가 → 해당 스테이지·서브맵에 N5 배치 금지
 3. **"공격"의 정의**: 자동 공격만 카운트? 스킬 공격도 포함? — 기획팀장 초안: **모든 데미지 발생 공격**
 #### 엣지 케이스
 - **후열 몬스터 미등장 서브맵**: 해당 서브맵 때문에 스테이지 전체 실패 → 배치 전 서브맵별 몬스터 구성 점검 필수
- **정합성 검증**: 기획실 CLAUDE.md "등장 패턴과 3성 조건의 정합성" 항목과 직결. 맵 패턴 확정 후 N5 배치 가능 스테이지 재식별 필요
+- **정합성 검증**: 기획팀 CLAUDE.md "등장 패턴과 3성 조건의 정합성" 항목과 직결. 맵 패턴 확정 후 N5 배치 가능 스테이지 재식별 필요
 #### P17 배타 조합
 - **N5 ∧ N6 동시 배치 금지** — 타겟팅 자유도 박탈·논리 모순
@ -592,7 +595,7 @@ N5와 동일 구조 (변수명만 N6).
 #### UI 표시
 - N5와 동일 구조 (문구만 "전열 선공")
-#### 개발실 구현 요청 포인트
+#### 개발팀 구현 요청 포인트
 - N5와 동일. 단 **전열 몬스터 부재 서브맵 없음**이 일반적이나 확인 필요 (보스 전용 서브맵 등 예외)
 #### 엣지 케이스
@ -609,7 +612,7 @@ N5와 동일 구조 (변수명만 N6).
 1. **조건별 임계값은 스테이지 단위로 테이블화**: `StageStarCondition.json` (가칭) 또는 기존 스테이지 테이블 확장
 2. **기본값 + 스테이지별 오버라이드 체계**: 전역 기본값을 두고 특정 스테이지만 덮어쓰기 가능
-3. **임계값 튜닝은 C# 시뮬 결과 기반** (Phase 3 재개 후)
+3. **임계값 튜닝은 Unity MCP 시뮬 실측 결과 기반** (Phase 3 재개 후)
 ### 5-2. 달성 판정의 공통 요구사항
@ -619,7 +622,7 @@ N5와 동일 구조 (변수명만 N6).
 ### 5-3. 측정 변수의 저장 구조
-재개 시점에 개발실이 구현해야 할 **런타임 상태 컨테이너**:
+재개 시점에 개발팀이 구현해야 할 **런타임 상태 컨테이너**:
 ```csharp
 class StageConditionTracker {
@ -642,10 +645,10 @@ class StageConditionTracker {
 }
 ```
-### 5-4. Python 시뮬 ↔ C# 시뮬 교차 검증 시 확인 항목
+### 5-4. Unity MCP 시뮬 실측 검증 시 확인 항목
-개발실의 Headless C# 시뮬 추출 이후, 각 조건에 대해:
+개발팀의 Unity MCP EditMode 시뮬 환경(`Assets/Sim/`) 구축 이후, 각 조건에 대해:
-1. 동일 입력으로 Python 시뮬과 C# 시뮬의 조건 판정 결과가 일치하는가
+1. 동일 입력으로 Unity MCP 시뮬과 Unity 실 빌드의 조건 판정 결과가 일치하는가
 2. 측정 변수의 스테이지 종료 시점 값이 일치하는가
 3. 엣지 케이스 (Shield 흡수, DOT, 동시 처치 등)에서 판정 기준이 일치하는가
@ -677,24 +680,24 @@ class StageConditionTracker {
 ---
-## 7. 개발실 요청서 초안 (구조만)
+## 7. 개발팀 요청서 초안 (구조만)
-> ※ 정식 요청서는 `공유/기획실→개발실/` 폴더에 날짜·REQ번호 부여하여 생성. 본 문서는 **내용 초안**만 제공.
+> ※ 정식 요청서는 `공유/기획팀→개발팀/` 폴더에 날짜·REQ번호 부여하여 생성. 본 문서는 **내용 초안**만 제공.
 ### 요청 개요
 - **제목**: 수상한 잡화점 ★ 조건 12개 판정 로직 구현 요청
- **배경**: Phase 2 §5 PD님 3차 승인으로 조건 풀 12개 확정. Headless C# 시뮬 추출과 **동시 구현**이 필요
+- **배경**: Phase 2 §5 PD님 3차 승인으로 조건 풀 12개 확정. Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`) 기반 구현
- **선행 조건**: 본 설계 문서(`3성조건_12개_상세명세_v1.md`) 개발실 리뷰 완료
+- **선행 조건**: 본 설계 문서(`3성조건_12개_상세명세_v1.md`) 개발팀 리뷰 완료
 ### 요청 내용 (요약)
 1. §3·§4의 조건별 판정 로직을 C# 런타임에 구현
 2. §5-3의 `StageConditionTracker`(또는 상응 구조) 설계
-3. Headless C# 시뮬과의 공통 코드 경로 확보 (실제 전투·시뮬이 동일 판정기 사용)
+3. Unity MCP 시뮬 어셈블리와 실 빌드 간 공통 코드 경로 확보 (동일 판정기 사용)
 4. §6-1의 단위 테스트 매트릭스를 자동 테스트로 구축
 5. **임계값은 테이블 구동** — 코드 내 하드코딩 금지 (스테이지별 튜닝 가능성 대비)
 ### 우려 사항·문의
- §3·§4 각 조건의 "엣지 케이스"에 대한 개발실 판단 필요
+- §3·§4 각 조건의 "엣지 케이스"에 대한 개발팀 판단 필요
 - **N7 방어 성공 조건**이 추후 13번째 조건으로 추가될 가능성 — `StageConditionTracker`를 확장 가능한 구조로 설계 권장
 ---
@ -708,7 +711,7 @@ class StageConditionTracker {
 **향후 예정 변경**:
 - Phase 3 재개 후 시뮬 기반 임계값 확정 → v2
 - N7 방어 성공 조건 추가 결정 시 → §4에 추가 + v2
- 개발실 리뷰 피드백 수령 후 반영 → v1.1 or v2
+- 개발팀 리뷰 피드백 수령 후 반영 → v1.1 or v2
 ---
@ -728,18 +731,18 @@ class StageConditionTracker {
 ### 본 문서가 수행한 것
 - 기존 PD님 3차 승인 **조건 풀 12개의 설계 명문화** (P18 의무 이행)
 - 조건별 판정 로직 **의사코드 수준**의 구현 요구 정의
- 개발실과의 **협업 문서 초안** (Phase 3 재개 시 즉시 활용)
+- 개발팀과의 **협업 문서 초안** (Phase 3 재개 시 즉시 활용)
 ---
 ## 10. 참조 문서
- `기획실/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md` §5 (조건 풀 12개 PD님 3차 승인)
+- `기획팀/밸런싱/수상한잡화점/Phase2_카드임팩트측정_v1.md` §5 (조건 풀 12개 PD님 3차 승인)
- `기획실/밸런싱/수상한잡화점/맵패턴_사전분석_v1.md` §1·§2 (C9·N5·N6 배치 제약)
+- `기획팀/밸런싱/수상한잡화점/맵패턴_사전분석_v1.md` §1·§2 (C9·N5·N6 배치 제약)
- `기획실/밸런싱/수상한잡화점/밸런싱문서_일관성점검_v1.md` §2-5 (조건 판정 재검증 항목 22~25)
+- `기획팀/밸런싱/수상한잡화점/밸런싱문서_일관성점검_v1.md` §2-5 (조건 판정 재검증 항목 22~25)
- `기획실/밸런싱/수상한잡화점/재논의대기_사전자료모음_v1.md` §4 (N7 보류·N8 변형 채택)
+- `기획팀/밸런싱/수상한잡화점/재논의대기_사전자료모음_v1.md` §4 (N7 보류·N8 변형 채택)
- `공유/공통_업무_규칙.md` P17 (배타 배치 규칙 7종) + P18 (설계 문서화 의무)
+- `.claude/skills/너드나비스-코어룰/SKILL.md` P17 (배타 배치 규칙 7종) + P18 (설계 문서화 의무)
- `기획실/⚠️_PHASE3_HOLD_공지.md` (HOLD 범위 준수)
+- `기획팀/⚠️_PHASE3_HOLD_공지.md` (HOLD 범위 준수)
 ---
--- a/프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
+++ b/프로젝트/수상한잡화점/기획/Phase3_재개준비_체크리스트_v1.md
@ -1,6 +1,9 @@
 # 수상한 잡화점 — Phase 3 재개 준비 체크리스트 v1
-> 작성일: 2026-04-14
+> 📚 **본 문서 방향 전환 이력**: [방향전환 히스토리 아카이브 §Phase3_재개준비_체크리스트](../../../공유/조직공지/방향전환_히스토리_아카이브.md#1-프로젝트수상한잡화점기획phase3_재개준비_체크리스트_v1md-방향-전환)
 > (2026-04-16 조직명 개편·2026-04-17 Unity MCP 전환·2026-04-18 최신화 집행. 구 용어·구 경로·폐기 전제는 아카이브 참조)
 > 작성일: 2026-04-14 / 최신화: 2026-04-18
 > 담당: 기획팀장 (PD님 재량 위임 — Phase 3 HOLD 중 가능 작업)
 > 목적: Phase 3 HOLD 해제 시점에 **즉시 집행 가능한 작업 순서·담당자·검증 절차**를 사전 구체화
 > HOLD 준수: 본 문서는 **실행 절차·담당자·산출물 스키마만** 정의. 실제 Phase 3 작업(성장 요소 기여도 측정·시뮬 실행·수치 조정 제안)은 일절 수행하지 않음
@ -10,7 +13,7 @@
 ## 0. 본 문서의 목적·범위
 ### 목적
-Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
+Phase 3 HOLD 해제 시 기획팀이 **30분 내 착수**할 수 있도록:
 1. 재개 트리거 체크리스트
 2. Day 1~N 작업 순서 로드맵
 3. 각 작업의 담당 에이전트·산출물·검증 방법
@ -20,7 +23,7 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ### 범위 외 (HOLD 준수)
 - 실제 Phase 3 작업 수행 (성장 요소별 기여도 측정 등)
- C# 시뮬 실행 및 결과 분석
+- Unity MCP 시뮬 실행 및 결과 분석
 - 수치 조정안 작성
 ---
@ -29,13 +32,13 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ### 1-1. 필수 선행 조건 4종 (HOLD 해제 요건)
-`⚠️_PHASE3_HOLD_공지.md` §재개 조건 기반:
+`공유/조직공지/` HOLD 공지 §재개 조건 기반:
 | # | 조건 | 확인 담당 | 확인 방법 |
 |---|------|---------|---------|
-| 1 | 개발실이 Unity 전투 로직을 Headless C# 시뮬로 추출 완료 | 개발실장 → 총괄PM | 개발실 산출물(`개발실/프로젝트_숙지/수상한잡화점/07_시뮬레이터_이원화_해소_착수계획_v1.md` 후속) 존재 |
+| 1 | Unity MCP EditMode 독립 어셈블리(`Assets/Sim/NerdNavis.Sim.asmdef`) 시뮬 환경 구축 완료 | 개발팀장 → 총괄PM | `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` + `Assets/Sim/` 실존 |
-| 2 | Python 시뮬 ↔ C# 시뮬 결과 교차 검증 완료 | 개발실장 + 기획팀장 | 교차 검증 리포트(공유 채널) |
+| 2 | Unity MCP EditMode 실측 검증 완료 (결정론·리플레이 보장) | 개발팀장 + 기획팀장 | 실측 검증 리포트 (`공유/소통/개발팀→기획팀/`) |
-| 3 | 기획실용 CLI 사용 가이드 확보 | 개발실 | `공유/개발실→기획실/` 폴더 내 가이드 문서 |
+| 3 | 기획팀용 Unity MCP 시뮬 실행 가이드 확보 | 개발팀 | `공유/소통/개발팀→기획팀/` 폴더 내 가이드 문서 |
 | 4 | PD님 재개 지시 (직접) | 총괄PM 전달 | PD님 세션 기록 |
 ### 1-2. 재개 즉시 수행 3단계 체크
@ -44,18 +47,18 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ```
 [Phase 3 재개 즉시 체크 3단계]
-□ 1단계: 기획실 루트의 🛑·⚠️·🚨 파일 전수 재스캔
+□ 1단계: 공유/조직공지/ 의 🛑·⚠️·🚨 파일 전수 재스캔
-         현재 ⚠️_PHASE3_HOLD_공지.md 파일 상태 확인 (삭제 or "재개됨" 표기)
+         현재 Phase 3 HOLD 공지 파일 상태 확인 (삭제 or "재개됨" 표기)
-□ 2단계: 기획실/CLAUDE.md 최상단 긴급 섹션 재읽기
+□ 2단계: CLAUDE.md "🔔 최근 규칙 변경" 섹션 재읽기 (Read 캐시 의존 금지)
-□ 3단계: 공유/조직공지/ 최신 공지 확인
+□ 3단계: .claude/skills/너드나비스-코어룰/SKILL.md 최신 조항 확인
 ```
 ### 1-3. 재개 선행 의존성 체계 (PD님 확정)
 ```
-1. 시뮬레이터 이원화 해소 (개발실, 착수 예정)
+1. Unity MCP EditMode 시뮬 환경 구축 (개발팀, #28·#37 완료)
-   └→ 2. Phase 3 재개 (기획실, 시뮬 검증 기반 재계산 → Phase3_성장요소기여도_v2.md 작성)
+   └→ 2. Phase 3 재개 (기획팀, Unity MCP 실측 검증 기반 재계산 → Phase3_성장요소기여도_v2.md 작성)
-        └→ 3. 이슈 1·3 동시 재논의 (기획실, Phase 3 결과 반영)
+        └→ 3. 이슈 1·3 동시 재논의 (기획팀, Phase 3 결과 반영)
             └→ 4. 최종 수치 조정 및 Phase 3 v2 확정
 ```
 "모든 카드 검증 완료" = 위 1~4 전체 완료 시점을 의미 (`재논의대기_사전자료모음_v1.md` §1-3 인용)
@ -69,8 +72,8 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | 순번 | 작업 | 담당 | 산출물 | 검증 방법 |
 |-----|------|------|-------|---------|
 | 1-1 | §1-1·§1-2 체크리스트 전수 수행 | 기획팀장 | 체크 완료 보고 | 총괄PM 확인 |
-| 1-2 | 개발실 Python↔C# 교차 검증 리포트 정독 | 기획팀장 + 밸런스기획자 | 검증 요약 메모 | — |
+| 1-2 | 개발팀 Unity MCP 실측 검증 리포트 정독 | 기획팀장 + 밸런스기획자 | 검증 요약 메모 | — |
-| 1-3 | 기획실용 CLI 가이드 정독 및 간이 실행 테스트 | 밸런스기획자 | 시뮬 실행 가능 확인 | 1회 앵커 시뮬 실행 결과가 Python 기존 결과와 일치하는지 대조 |
+| 1-3 | Unity MCP 시뮬 실행 가이드 정독 및 간이 실행 테스트 | 밸런스기획자 | 시뮬 실행 가능 확인 | 1회 앵커 시뮬 실행 결과가 Unity 실 빌드와 일치하는지 대조 |
 | 1-4 | 기존 3개 사전 산출물 재독 및 연동 항목 최종 점검 | 기획팀장 | 연동 지점 표(§3 참조) | — |
 ### Day 2~3: Phase 0~2 결과 재검증 (28개 재검증 항목 중 1~6번 우선)
@ -79,7 +82,7 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | 순번 | 작업 | 담당 | 산출물 |
 |-----|------|------|-------|
-| 2-1 | #1 PC 6001 DPS 1.05 C# 시뮬로 대조 | 밸런스기획자 | 재검증 로그 |
+| 2-1 | #1 PC 6001 DPS 1.05 Unity MCP 실측으로 대조 | 밸런스기획자 | 재검증 로그 |
 | 2-2 | #2 Stage 1 일반 몬스터 TTK 5.7s 재측정 | 밸런스기획자 | 재검증 로그 |
 | 2-3 | #3 G1 카드 1장 평균 기여도 +22% DPS 재측정 | 밸런스기획자 | 재검증 로그 |
 | 2-4 | #4 G1 5장 TTK -45% 재검증 | 밸런스기획자 | 재검증 로그 |
@ -144,7 +147,7 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | 사전분석 §  | 재개 시 연동 작업 | 재개 Day |
 |-----------|---------------|---------|
 | §1-2 C9 배치 금지 스테이지 | Day 11-2: 실측 재검증 | Day 11 |
-| §1-4 C9 적합 스테이지 리스트 | Day 11-3: C# 시뮬 재검증 | Day 11 |
+| §1-4 C9 적합 스테이지 리스트 | Day 11-3: Unity MCP 시뮬 재검증 | Day 11 |
 | §2-4 스테이지별 혼용 패턴 프레임 | Day 11-4: 실 패턴 ID로 구체화 | Day 11 |
 | §3-3 42개 슬롯 검증 체크리스트 | Day 11-5: 42개 전수 적용 | Day 11 |
 | §4-2 재개 시 즉시 착수 작업 순서 | Day 1~11 전체 | — |
@ -169,16 +172,16 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | §1 이슈 1 (카드 DPS 과도) | Day 8-1·8-3 | Day 8 |
 | §2 이슈 3 (신성 G4/G5 확장성) | Day 8-2·8-3 | Day 8 |
 | §3 이슈 1·3 연동 처리 권고 | Day 8-3 통합 조정안 기준 | Day 8 |
-| §4-1 N7 방어 성공 조건 | 개발실 방어 시스템 분석 완료 시점에 별도 추가 | 분리 |
+| §4-1 N7 방어 성공 조건 | 개발팀 방어 시스템 분석 완료 시점에 별도 추가 (#37 Q-P2 정밀 2차 실측으로 터치 방어 30%·쿨다운 없음·지속형 확정됨) | 분리 |
 | §4-3 N8 저 HP 완주 수치 변형 | Day 4~7 본 작업 중 포함 | Day 4~7 |
 ### 3-4. 3성 조건 12개 상세 명세 v1 연동 (본 문서 작성과 동시 신설)
 | 명세서 § | 재개 시 연동 작업 | 재개 Day |
 |---------|---------------|---------|
-| §3·§4 조건별 판정 로직 | 개발실에 구현 요청서 전송 | Day 1-4 (재개 직후) |
+| §3·§4 조건별 판정 로직 | 개발팀에 구현 요청서 전송 (`공유/소통/기획팀→개발팀/`) | Day 1-4 (재개 직후) |
-| §6-1 단위 테스트 매트릭스 | 개발실이 자동 테스트 구축 | Day 1~5 |
+| §6-1 단위 테스트 매트릭스 | 개발팀이 Unity MCP EditMode 기반 자동 테스트 구축 | Day 1~5 |
-| §7 개발실 요청서 초안 | 정식 요청서로 전환 | Day 1 |
+| §7 개발팀 요청서 초안 | 정식 요청서로 전환 (REQ 템플릿 `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` 활용) | Day 1 |
 ---
@ -193,16 +196,16 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | 컨텐츠기획자 | 카드 내용·빌드 시너지 관점 재검증 |
 | 레벨기획자 | 스테이지 난이도·맵 패턴·슬롯 배치 |
 | 시나리오기획자 | (Phase 3 본 작업에서는 비주요 — 독립 작업 가능) |
-| 밸런스기획자 | **주력 담당** — C# 시뮬 실행, 기여도 측정, 수치 분석 |
+| 밸런스기획자 | **주력 담당** — Unity MCP 시뮬 실행, 기여도 측정, 수치 분석 |
 | UX기획자 | 조건 UI 표시 방안 검토 (`3성조건_12개_상세명세_v1.md` §3·§4 참조) |
 ### 4-2. 외부 협업 지점
 | 작업 | 외부 담당 |
 |------|---------|
-| C# 시뮬 CLI 문의·이슈 | 개발실 서버팀장 (클라이언트팀장일 수도) |
+| Unity MCP 시뮬 실행 문의·이슈 | 개발팀 클라이언트팀장 |
-| 조건 판정 로직 구현 | 개발실 클라이언트팀 |
+| 조건 판정 로직 구현 (`Assets/Sim/`) | 개발팀 클라이언트팀 |
-| 테이블 변경 요청 (PD님 승인 전제) | 개발실 클라이언트팀 |
+| 테이블 변경 요청 (PD님 승인 전제) | 개발팀 클라이언트팀 |
 ---
@ -215,7 +218,7 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | Phase 3 본 작업 | `Phase3_성장요소기여도_v2.md` | v1 부재이므로 v2로 식별 |
 | 재검증 보고서 | `재검증보고_[항목명]_v{버전}.md` | `재검증보고_Phase0_1_2_v1.md` |
 | 통합 조정안 | `이슈{번호}_통합재논의_v{버전}.md` | `이슈1_3_통합재논의_v1.md` |
-| 개발실 요청서 | `공유/기획실→개발실/[YYYY-MM-DD]_REQ{번호}_[제목].md` | — |
+| 개발팀 요청서 | `공유/소통/기획팀→개발팀/[YYYY-MM-DD]_REQ{번호}_[제목].md` | — |
 ---
@ -225,11 +228,11 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 | 리스크 | 완화 방법 |
 |-------|---------|
-| 시뮬 CLI 가이드 불완전 → 기획실이 시뮬 실행 불가 | Day 1-3에서 반드시 앵커 시뮬 실행 확인. 미작동 시 즉시 개발실로 에스컬레이션 |
+| Unity MCP 시뮬 가이드 불완전 → 기획팀이 시뮬 실행 불가 | Day 1-3에서 반드시 앵커 시뮬 실행 확인. 미작동 시 즉시 개발팀으로 에스컬레이션 |
-| Python ↔ C# 시뮬 교차 검증에서 불일치 발견 | C# 시뮬 결과를 정(正)으로 하고 Python 결과는 참고용으로만 사용. 불일치 원인 분석 후 Python 측 문서 주석 처리 |
+| Unity MCP 실측 결과가 Unity 실 빌드와 불일치 발견 | Unity 실 빌드 결과를 정(正)으로 하고 MCP 시뮬은 재조정. 불일치 원인 분석 후 `Assets/Sim/` 로직 수정 |
 | 성장 요소 기여도 실측이 목표치(+40~60% 등)와 큰 괴리 | Day 8 이슈 1·3 재논의에서 통합 처리 대상으로 이관 |
 | 42개 슬롯 배치 P17 전수 체크에서 위반 대량 발견 | 슬롯 재배치 제안 작성 후 PD님 승인 요청 |
-| N7 방어 성공 조건 추가 결정 시점과 Phase 3 작업 겹침 | N7은 별도 트랙으로 분리. 개발실 방어 시스템 분석 완료 시점에 조건 풀 확장 (13번째) |
+| N7 방어 성공 조건 추가 결정 시점과 Phase 3 작업 겹침 | N7은 별도 트랙으로 분리. #37 Q-P2 정밀 2차 실측 결과(30% 감소·지속형·쿨다운 없음) 기반으로 조건 풀 확장 (13번째) |
 ### 6-2. HOLD 재발 리스크
@ -238,9 +241,9 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ### 6-3. 교훈 기반 리스크
-`공유/공통_업무_규칙.md` 교훈 섹션 및 본 조직공지 기반:
+`memory/org/MEMORY.md` 교훈 인덱스 및 조직공지 기반:
 - **Read 캐시 함정**: 작업 초반의 CLAUDE.md Read 결과가 캐시되어 최신 공지를 놓칠 수 있음. Day별 시작 시 재읽기 의무
- **이원화 리스크**: Python 시뮬 결과와 C# 실전의 괴리가 Phase 3 v1 붕괴의 원인이었음. v2에서는 **모든 수치는 C# 시뮬 기반**으로만 산출 (Python 이론치 금지)
+- **시뮬 단일축 원칙**: Phase 3 v2는 **Unity MCP EditMode 실측만을 근거**로 산출 (단일축 SOT 준수)
 ---
@ -256,9 +259,9 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 - 3단계: [결과]
 ### §1-1 재개 트리거 체크리스트 결과
- #1 Headless C# 시뮬 추출 완료 확인: [OK / 미비]
+- #1 Unity MCP EditMode 시뮬 환경 구축 확인: [OK / 미비]
- #2 Python ↔ C# 교차 검증: [OK / 미비]
+- #2 Unity MCP 실측 검증 완료: [OK / 미비]
- #3 기획실 CLI 가이드: [OK / 미비]
+- #3 Unity MCP 시뮬 실행 가이드: [OK / 미비]
 - #4 PD님 재개 지시: [OK]
 ### Day 1 산출물
@ -306,7 +309,7 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ### 8-3. 업데이트 트리거
 - 새로운 HOLD·공지 발령 시
- 개발실 시뮬레이터 이원화 착수 계획의 주요 변경 시
+- 개발팀 Unity MCP 시뮬 환경의 주요 변경 시 (`프로젝트/수상한잡화점/시뮬레이터/01~04` 개정)
 - `맵패턴_사전분석_v1` / `일관성점검_v1` / `재논의대기_사전자료모음_v1` / `3성조건_12개_상세명세_v1` 수정 시
 ---
@ -328,13 +331,15 @@ Phase 3 HOLD 해제 시 기획실이 **30분 내 착수**할 수 있도록:
 ## 10. 참조 문서
- `기획실/⚠️_PHASE3_HOLD_공지.md` (재개 조건 SOT)
+- `공유/조직공지/` Phase 3 HOLD 공지 (재개 조건 SOT)
- `기획실/밸런싱/수상한잡화점/맵패턴_사전분석_v1.md`
+- `프로젝트/수상한잡화점/기획/맵패턴_사전분석_v1.md`
- `기획실/밸런싱/수상한잡화점/밸런싱문서_일관성점검_v1.md`
+- `프로젝트/수상한잡화점/기획/밸런싱문서_일관성점검_v1.md`
- `기획실/밸런싱/수상한잡화점/재논의대기_사전자료모음_v1.md`
+- `프로젝트/수상한잡화점/기획/재논의대기_사전자료모음_v1.md`
- `기획실/밸런싱/수상한잡화점/3성조건_12개_상세명세_v1.md` (본 착수 작업에서 신규)
+- `프로젝트/수상한잡화점/기획/3성조건_12개_상세명세_v1.md` (본 착수 작업에서 신규)
- `공유/공통_업무_규칙.md` C10·P17·P18
+- `프로젝트/수상한잡화점/시뮬레이터/01_시뮬레이터_아키텍처_v1.md` ~ `04_MCP_호출_스니펫_v1.md` (Unity MCP 시뮬 인프라)
 - `.claude/skills/너드나비스-코어룰/SKILL.md` C10·P17·P18
 - `공유/조직공지/2026-04-14_작업착수전_HOLD공지_전수확인_의무화.md`
 - `공유/조직공지/방향전환_히스토리_아카이브.md` (본 문서 방향 전환 이력)
 ---