> **본 파일의 성격**: 폐기되었거나 정의가 대폭 개정되어 이전 형태가 소멸한 핵심 규칙(C)·프로젝트 규칙(P)의 **상세 경위·근거·대체 관계**를 단일 SOT로 집약한 조직 자산. 활성 본문(SKILL.md)에는 "1줄 선언 + 본 파일 링크"만 유지하여 고정비를 최소화하되 **조직 기억·감사 추적·역진화 방지·차기 프로젝트 참고 자료** 4중 가치를 보존한다.
>
> **근거**: 2026-04-18 PD님 직접 지시로 "수정 3대 원칙 3번 — 폐기 선언 본문 유지"를 **"저장 위치 최적화"** 로 개정. 활성 본문 ≠ 자산 저장 위치. 자산 가치는 유지하되 저장은 외부화.
>
> **읽기 규칙**: 본 파일은 **변동비**. 활성 본문에서 폐기 규칙 맥락이 필요할 때만 Read. SessionStart·매 턴 자동 로드 대상 아님.
---
## 🏛️ 아카이브 원칙
### 포함 대상
1.**완전 폐기 규칙** — 선언이 `~~취소선~~` 처리되고 후속 대체 규칙이 지정된 것 (예: P20 → P24, C17 → 폐기)
2.**정의 대폭 개정 규칙** — 번호는 유지되나 이전 정의가 소멸하고 신 정의로 교체된 것 (예: 구 C18·C24·C26)
3.**상위 규칙 격상으로 실효된 규칙** — 프로젝트 규칙이 헌법급으로 격상되어 원 조항이 실질 공백화된 것 (검토 대기: P12 → C28)
### 제외 대상
1. 활성 규칙의 부속 조항 개정 (예: C20-1-A의 운영 조정) — 활성 본문 내 변경 이력으로 관리
2. 오탈자·용어 통일·링크 수정 — 일반 문서 개정
### 기록 형식 (각 규칙 필수 6필드)
| 필드 | 설명 |
|------|------|
| **규칙 번호·명** | 원 번호와 명칭 |
| **신설일** | 최초 도입 날짜 |
| **폐기/개정일** | 소멸·개정 날짜 |
| **상태** | 폐기 / 개정 / 격상 실효 |
| **대체 관계** | 후속 규칙 번호·명 (있으면) |
| **경위·근거** | 왜 폐기/개정되었는가, 어떤 사건·결정이 계기인가 |
| **원 본문** (선택) | 원형 보존 필요 시 전문 인용. 없으면 "활성 본문에는 1줄 선언만" |
---
## 1. P20 — 세션 활동 일일 보고
| 항목 | 내용 |
|------|------|
| **규칙 번호·명** | P20. 세션 활동 일일 보고 |
| **신설일** | 2026-04-14 |
| **폐기일** | 2026-04-16 |
| **상태** | **폐기** |
| **대체 관계** | **P24 (대화로그 기록 의무)** 가 역할 완전 대체 |
| **경위·근거** | 2026-04-16 PD님 직접 지시. P24 대화로그가 일일보고 역할을 완전 대체하며, 양 체계 병존 시 기록 중복(C14-4 참조 무결성 위반) 발생. "활동 가시화"라는 목적은 P24 + P22(결정로그) + P19(PD 지시 트래킹) 3축으로 분담. 기존 `공유/일일보고/` 아카이브는 역사 기록으로 보존. |
| **원 본문 요지** | 각 팀 세션 종료 시 `공유/일일보고/YYYY-MM-DD_{부서}.md` 작성·갱신 의무. 당일 첫 작성이면 신규, 이후 append. 포함: PD 지시 반영 결과 / 자율 작업 / 발견 이슈 / 다음 예정. |
| **교훈** | 기록 체계는 "하나의 기록 = 하나의 목적" 원칙으로 SOT 경계 명확화. P20처럼 중복 체계는 조기 정리. |
| **경위·근거** | 2026-04-16 PD님 직접 지시로 단일 세션 전환(C24 개정). 단일 세션 구조에서는 "세션 간 이동" 자체가 소멸하므로 C17의 전제가 성립하지 않음. PM이 부서별 별도 세션 진입을 위해 동봉하던 복사 명령어 블록은 불요. |
| **원 본문 요지** | PM이 부서에 작업을 위임하거나 세션 이동을 지시할 때, 부서 세션에서 **바로 복사·실행 가능한 명령어 블록**을 응답에 동봉 의무화. C17-3·C17-3-α로 3요소·간결화 원칙이 보강되었으나 2026-04-16 단일 세션 전환으로 전체 실효. |
| **교훈** | 운영 프로세스 규칙은 상위 구조(여기서는 세션 구조) 변경에 종속. 상위 변경 시 하위 규칙의 존속 가치 재검토 필수. |
| **관련 이력** | C17-3 보강 (2026-04-15) / C17-3-α 신설 (2026-04-15) / C24 단일 세션 전환 (2026-04-16) / PD 지시 로그 #12·#17 |
---
## 3. 구 C18 — 조직 공유 완료 판정 (대상 세션 도달 포함)
| 항목 | 내용 |
|------|------|
| **규칙 번호·명** | 구 C18. 조직 공유 완료 판정 — main 병합 + 대상 세션 도달 |
| **신설일** | 2026-04-15 |
| **개정일** | 2026-04-16 |
| **상태** | **정의 개정** (번호 유지, 정의 변경) |
| **현행 C18** | main push 완료 (대상 세션 도달 개념 제거) |
| **경위·근거** | 2026-04-15 OI-2 위임 사건(브랜치 분리로 인한 파일 미도달) 계기로 신설. 당시 구조는 부서별 별도 세션 운용이라 "main 병합 + 부서 세션이 해당 커밋을 pull 완료"까지를 공유 완료로 판정. 2026-04-16 단일 세션 전환으로 "대상 세션 도달" 개념이 소멸 → main push 완료만으로 공유 완료 판정하도록 개정. |
| **구 정의 요지** | 로컬 커밋 → 원격 push → main 병합 → **부서 세션이 main pull 완료** 4단계가 모두 완료된 시점을 "조직 공유 완료"로 판정. |
| **교훈** | 정의 개정은 "번호 유지 + 정의 변경" 형태로도 발생 가능. 구 정의가 적용되던 시점의 커밋·보고는 구 정의로 해석해야 역사적 정합성 유지. |
| **관련 이력** | 신설 공지 `공유/조직공지/2026-04-15_C18_신설_C17_보강_브랜치동기화_정직성.md` / C24 단일 세션 전환 시 동반 개정 |
---
## 4. 구 C24 — 부서 세션 영속 대화 운용
| 항목 | 내용 |
|------|------|
| **규칙 번호·명** | 구 C24. 부서 세션 영속 대화 운용 |
| **신설일** | 2026-04-15 |
| **개정일** | 2026-04-16 |
| **상태** | **정의 개정** (번호 유지, 정의 변경) |
| **현행 C24** | 단일 세션 운용 원칙 (PM이 총괄하는 단일 세션 1개, 부서는 Agent 도구로 호출) |
| **경위·근거** | 2026-04-15 PC 독립·세션 시작 표준 논의 중 "부서별 워크트리 영속 대화"를 표준 운용 모델로 도입. 2026-04-16 PD님 직접 지시로 **단일 세션 + Agent 병렬 호출** 구조로 전환. 이유: (a) 부서 세션과 PM 세션 간 동기화 비용 (b) 각 부서 세션에 별도 메모리·권한 관리 부담 (c) Agent 도구 성숙으로 단일 세션에서 병렬 호출 가능. |
| **구 정의 요지** | 부서(개발팀·기획팀)별 영속 대화 세션을 `개발팀/`·`기획팀/` 디렉토리 기준으로 유지. PM이 위임 시 부서 세션에서 `resume` 하여 맥락 계승. |
| **교훈** | 조직 구조 근본 전환은 다수 하위 규칙(C17·C26·settings.json 배치 등)에 파급. 전환 시 파급 범위 전수 식별 필수. |
| **관련 이력** | 2026-04-16 단일 세션 전환 / C16 PC 독립 셋업과 정합 / C26 Skill 패킹 전환 동반 |
| **경위·근거** | 2026-04-18 PD님 직접 지적 "헌법 제1원칙이 잘못 되었어". 구 3개 목표(코어 프레임워크 PC 독립·차기 프로젝트 활용·단기제작 스튜디오)는 헌법급 상위 원칙으로 부적합 판정. 일부는 프로젝트 규칙(P29 코어프레임워크)·참고 사항(조직 현황·핵심 자산 안내)으로 강등. |
| **v1 원본 요지** (보존) | **목표 1** — 코어 프레임워크의 PC 독립 최신화 유지 (어떤 PC에서든 최신화된 조직 자산으로 코어 프레임워크 유지·관리) / **목표 2** — 차기 프로젝트부터 코어 코드 프레임워크 조직 자산으로 적극 활용 (원칙 A: 차기 프로젝트 활용·원칙 B: 현 프로젝트 인사이트 기록→차기 참고) / **목표 3** — 단기제작 가능한 유능한 게임 개발 스튜디오로의 발전 |
| **대체 경로** | v1 목표 1 (PC 독립 유지): 기술 운영 사항으로, **헌법 외 명문화 "조직 현황·핵심 자산 안내" + P25 Live 동기화** 체계로 흡수. 헌법 원칙 아님. / v1 목표 2 (코어 프레임워크 활용): **P29 코어 코드 프레임워크 프로젝트 규칙** 3개 조항으로 강등 + 헌법 원칙 ② "경험 축적·계승·발전"에 포함 / v1 목표 3 (단기제작 스튜디오): 헌법 원칙 ① "AI 전문 개발 스튜디오" 내재화 |
| **교훈** | 헌법급 상위 원칙은 **추상도 높은 조직 본질**에 한정. 구체 프로젝트(코어 프레임워크)·기술 체계(PC 독립)·미래 지향 목표(단기제작)는 프로젝트 규칙·참고 사항으로 분리 배치가 적정. PM은 v1 원안 작성 시 이 층위 구분 미숙. |
| **관련 이력** | 2026-04-18 PD님 직접 재작성 지시 5항 + P24→C32·P27→C33 승격 + P29 신설 연쇄 개정 |
---
<aid="c32-p24-승격"></a>
## 6. P24 → C32 승격 (2026-04-18)
| 항목 | 내용 |
|------|------|
| **규칙 번호·명** | P24 대화로그 기록 의무 → C32 (번호 승격) |
| **신설일** | 2026-04-16 (P24로) |
| **승격일** | 2026-04-18 (C32로) |
| **상태** | **번호 승격** (프로젝트 규칙 → 핵심 규칙 헌법급) |
| **경위·근거** | 2026-04-18 PD님 직접 지시 "P24·P27도 코어룰로 승격 시켜." 대화로그가 조직 노하우 축적의 핵심 도구이며 기록 누락이 조직 자산 소실로 직결되어 헌법급 격상 타당. |
| **경위·근거** | 2026-04-18 PD님 직접 지시. "C21은 작업 완료 즉시 공유하고 PM이 능동 확인해야 하는 룰은 매우 중요한 룰이야. '작업 완료 즉시 공유'가 C18로 인해 반드시 푸시를 해야만 완료라고 인지할 수 있기 때문에 혼선을 없애도록 2단계 정의를 명문화." |
| **본문 구조** | C21-① 내부 공유 상태(임시 파일·로그로 세션 갱신 전 확인 가능) + C21-② 공유 완료 상태(C18 main push 완료·모든 PC 동기화) + C21-③ PM 능동 확인 의무 + C21-④ 2단계 전이 시점 + C21-⑤ 연관 규칙 |
| **핵심 가치** | "내부 공유 상태" vs "공유 완료 상태" 명확 구분으로 C18과의 혼선 해소 |
| **현행 C26** | 코어룰 단일 SOT 갱신 원칙 — SKILL.md 한 곳만 갱신하면 Skill 메커니즘이 부서 서브에이전트에 자동 주입 |
| **경위·근거** | 1차 신설 당시는 코어룰을 루트 CLAUDE.md·개발팀장.md·기획팀장.md 다중 복사 보관 구조. 규칙 변경 시 3~4곳 동시 갱신 의무 규정. 2026-04-16 Claude Code `skills:` frontmatter 기능 도입으로 **Skill 패킹 단일 SOT 전환**. SKILL.md 한 곳만 수정하면 모든 부서 에이전트에 자동 주입되므로 수동 동시 갱신 의무 폐지. |
| **구 정의 요지** | C·P 규칙 신설·변경 시 다음 4곳을 동일 커밋 내 갱신 의무: (1) 루트 CLAUDE.md 요약 (2) 개발팀/CLAUDE.md 본문 (3) 기획팀/CLAUDE.md 본문 (4) 에이전트 정의 `.md` 관련 조문. 누락 시 C26 위반 + C5 정직성 위반 가중. |
| **교훈** | 플랫폼 기능 진화(Skill 패킹)에 따라 조직 규칙도 적극 간소화. 수동 동기화 의무는 자동화 가능 영역에서는 즉시 폐지 검토 대상. |
## 14. C34 확장 — memory junction 중앙화 편입 (2026-04-19)
| 항목 | 내용 |
|------|------|
| **규칙 번호·명** | C34 "Live 증분 동기화 체계" → **"PC 로컬 실시간 공유 중앙화 체계 — Live + memory"** (제목 개정 + 본문 확장) |
| **이전 개정일** | 2026-04-18 (P25 → C34 헌법급 승격) |
| **이번 확장일** | 2026-04-19 |
| **상태** | **본문 확장** (C34 번호 유지, 적용 대상에 `memory/org/` 추가) |
| **대체 관계** | 구 "Live 단일 대상" 개념은 "Live + memory 2종 병립" 구조로 포섭됨. `feedback_worktree_isolation.md`의 "자산 적용 대상 표"에서 memory/org/ 상태 🟡 → ✅ 갱신 |
| **경위·근거** | 2026-04-18 C34 집행 세션에서 memory junction 경계 이슈 **3회 실증**(feedback 파일·MEMORY.md 인덱스·stash 이관 반복)했음에도 PM이 "운영 규율·감사관 체크로 커버" 완화 판정 + PD님이 직접 물어보실 때까지 침묵. 2026-04-19 PD님 직접 지적 **"이슈를 왜 내가 물어보기 전까지 대답하지 않았지? 근본 해결이 아닌 임시 방편은 코어 룰 위반이야. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어."** → PM 자진 반성(C2·C3·C5·C29 위반 자인) + 옵션 A 집행 지시 |
| **C34-16 신설 (memory junction 특수 조항)** | (1) 레포 `memory/org/` 실체 디렉토리 유지 의무 (git-tracked SOT) (2) sync 방향 규약 (레포 SOT 기본) (3) Write 경로 선택 의무 (본 worktree 절대 경로 vs user memory 경로, 혼용 금지) (4) 3층 백업 의무 (5) 정(正) 판정 규칙 A·B·C |
| **교훈** | **"C34와 동급 패턴 이슈는 C34 패턴 그대로 적용 가능**. git 추적 SOT라는 복잡도 때문에 "symlink 불가 → 운영 규율로" 결론은 잘못된 이분법. sync 스크립트 + junction 투명 경유 조합으로 양립 가능. **"커버 가능"은 "근원 해결"의 반의어 — 매 세션 수동 개입 반복 구조는 C2 위반**. PM 과도 보수 해석 4회차 변종 재발. |
| **규칙 번호·명** | P25 Live 증분 동기화 체계 → **C34 Live 증분 동기화 체계** (헌법급 승격 + 본문 전면 재작성) |
| **신설일** | 2026-04-16 (P25로) |
| **승격·재작성일** | 2026-04-18 (C34로) |
| **상태** | **번호 승격 + 본문 전면 재작성** (프로젝트 규칙 → 핵심 규칙 헌법급) |
| **대체 관계** | 구 P25 본문은 C34로 흡수되며, worktree 경계 해소·Agent 경계 보호·중앙 Junction 구조가 신규 편입됨 |
| **경위·근거** | 2026-04-18 PD님 직접 선언 — **"이 문제가 해결되지 않으면 앞으로 우리 조직은 유지될 수 없어"** · **"철저히 검토해서 관련 된 문서에 일괄 반영하고 재발되지 않도록 가능한 모든 수단을 써서 개선해"**. git worktree 격리로 P25의 "같은 PC 세션 간 실시간 공유"가 실패하는 사실이 실증됨. 헌법 제1원칙 ⑤(세션·PC 연속성 보장)의 근본 위협 판정. |
| **영향 범위** | (1) SKILL.md C34 신설 + P25 본문 완전 삭제, C16-1 junction 의무 편입, C31-1-E 표기 갱신 (2) CLAUDE.md 핵심 규칙 요약 28→29, 프로젝트 규칙 요약 25→24 (3) 스크립트: `scripts/live_junction_ensure.sh` 신규 + `setup_*.ps1/sh` 3.5 섹션 + `verify_setup.ps1` 2.5 섹션 (4) `.claude/settings.json` SessionStart hook 체인 갱신 (5) `.gitignore``.live/*` 제외 규칙 (6) 조직공지 `2026-04-18_C34_신설_worktree_격리_근원해결.md` 발행 (7) memory/org/ 2종 신설 |
| **구 P25 본문 요지** (보존) | Live 더미 + `sync_signal.sh` 시그널 체계로 같은 PC 세션 간 네트워크 비용 0 실시간 공유. 단, "같은 worktree" 전제가 암묵적이었으며 worktree 격리에서 실패함이 실증됨. |
| **교훈** | (1) **"같은 PC = 같은 파일시스템"이라는 직관은 worktree 앞에서 성립하지 않음** — 조직 공유 체계 설계 시 worktree 경계 조건을 첫 검토 항목에 포함 (2) Agent 호출 시 절대 경로 하드코딩은 worktree 경계를 넘어 다른 디렉토리에 쓰이는 2차 위험 — C34-11·`feedback_agent_path_boundary.md` 참조 (3) 기존 C16-1 memory junction 패턴이 본 해결의 모범 사례 (중앙 저장소 + junction). 새 공유 체계 설계 시 동일 패턴 우선 채택 |
| **번호 구멍** | P25는 본문 완전 삭제 (C14-5-확장 규준). CLAUDE.md 프로젝트 규칙 요약에서도 완전 제거. 번호 연속성 자산 아님. |
| 2026-04-19 | PM | §14 C34 확장 — memory junction 편입 (HOME 중앙화, C34-16 신설). PD님 직접 지적 "근본 해결이 아닌 임시 방편은 코어 룰 위반. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어" 수용. PM 이슈 축소 보고 자진 반성(feedback_issue_under_reporting.md) 포함 | 2026-04-19 PD님 옵션 A 집행 지시 |
| 규칙 번호 | **C22·C23·C24·C25·C26·C27·C28·C29·C30** 9블록 덩어리 (329줄) |
| 변경일 | 2026-04-20 |
| 변경 전 배치 | P 섹션(P1~P31) 뒤에 C22~C30 고립 (line 1235~1563) |
| 변경 후 배치 | C21 뒤·P1 앞에 C22~C30 (line 735~1063), P1 이동(1064) |
| 사유 | C·P 영역 연속 배치 복구 (C37-5). C 섹션 내 C22~C30이 P 섹션 뒤에 분리된 구조 정리 |
| 경위 | commit `(후속 commit)`. Python line 기반 덩어리 이동 (단일 원자적 연산). 줄 수 2129 유지 (diff 0). PM 자율 판단으로 집행 (C36-2 미해당 — 구현·실무 수준. "PD 승인 필요" 오표기는 PM 과도 보수 해석 자진 정정) |
### C·P 최종 정렬 상태 (2026-04-20 #52+#52-B+#52-B2 완료)
- **C 섹션**: C1→C2→C3→C4→C5→C6→C9→C10→C11→C13→C14→C16→C17→C18→C19→C20→C21→**C22→C23→C24→C25→C26→C27→C28→C29→C30**→C31→C32→C34→C35→C36→C37 번호 구멍 허용 완전 순서
- **P 섹션**: P1~P11→P13·P14·P16·P17·P18→P19→P21·P23→P28→P29→P30→P31 완전 순서
## P17 (이전 프로젝트 전용 ★ 조건 배타 배치 7종) — 완전 폐기 2026-04-21
### 6필드 기록
1.**규칙 번호**: P17
2.**변경일**: 2026-04-21
3.**변경 전 상태**: SKILL.md P17 "★ 조건 배타 배치 규칙 (수상한 잡화점 프로젝트)" — Prove-2-of-3 체계 슬롯2·3 ★ 조건 배타 조합 7종 본문 + 스테이지 기획 준수 사항 + 적용 범위 (이전 프로젝트 한정). 약 50줄
4.**변경 후 상태**: SKILL.md에서 **완전 삭제** (C14-5 확장 "폐기 조항 본문 완전 삭제 원칙" 준수). CLAUDE.md 요약 블록 P17 1줄도 삭제. 번호 구멍 P17 허용
5.**사유**: 조직 전환 — BurningTimes 신설 조직은 이전 프로젝트(덱빌딩 카드 게임)와 장르 이질. EerieVillage(2D 플랫포머)는 Prove-2-of-3 체계 이식 여부 자체가 미결. 이전 프로젝트 전용 규칙을 BT 코어룰에 잔존시키는 것은 **C14 토큰 최소화 위반** + **신생 조직 운영 혼선** 유발
6.**경위**: 2026-04-21 PD님 직접 지시 결정 1 "완전 폐기 + 아카이브 이관" — PM 권고 A안 수용. 배경: Phase 2-B `기획_system_designer_v1.md` 아카이브에서 "P17 배타 조합 7종 방법론" 교훈이 이미 영구 보존됨. 향후 EerieVillage 메카닉이 조건 풀을 요구하게 되면 **신규 규칙으로 재설계**
### 교훈 보존 경로
-`공유/조직자산/시행착오_아카이브/기획_system_designer_v1.md` §조건 체계 설계 방법론
3.**변경 전 상태**: SKILL.md C31 "응답 발신 직전 자기검증 의무 (2026-04-17 PD님 직접 지시 — 조직 사활 걸린 중대 사안·헌법급)" — 부록 A 뒤 배치. C31-1 체크리스트 A~I 9그룹 (A C29 준수 · B C27~C30 준수 · C 정직성·용어 일관 · D 세션 시작 맥락 복원 · E 기존 조직 자산 우선 활용 · F C35 pm-auditor 의무 참여 · G 구체 맥락 feedback 본문 선행 Read · H 방향·원칙 수준 축소·희석 금지 · I Proxy 개선 회피 — 근본 해결 우선) + C31-2 실행 방식 + C31-3 위반 시 처분 + C31-4 연관 + C31-5 본 규칙의 무게. 약 93줄
4.**변경 후 상태**: SKILL.md에서 **완전 삭제** (C14-5 확장 "폐기 조항 본문 완전 삭제 원칙"). 9그룹 A~I 체크리스트는 **C42-7 BT 고유 9그룹 보강 체크리스트**로 원형 이관 (의미 보존 의무 C37-2 준수) + J 그룹(C39 시스템 반영 실측) · K 그룹(C41 병렬 진행 의무) 신설 추가. CLAUDE.md 요약 블록 C31 1줄도 삭제 (폐기 규칙에만 1줄 참조). 번호 구멍 C31 허용
5.**사유**: NerdNavis 조직 실증 — C31 (응답 발신 직전 자기검증)은 **가공된 결과 검증**이라 PM 가공 충동의 진입점 차단 부재. PM 누적 9회 변종 + 헌법급 2회 위반 재발. 강화 방안 5종 도입 직후도 즉시 재발. **C42 (지시 수행 전 사전 검증)**이 **가공 진입 전 PD 원문 강제 인지** + **가공 왜곡 진입점 직접 차단**으로 근본 해결. C31의 사후 검증 기능은 C42-7 9그룹 보강 체크리스트로 통합 · 폐기 필연
6.**경위**: 2026-04-24 BT9 PD 직접 결정 수용. PM 권고 "C42 신설 + C31 폐기 + 9그룹 C42-7 원형 이관". NerdNavis 조직 2026-04-23 C42 신설 당일 실증 경험 BT 계승. PD 명시 지시 "9그룹 원형 보존"으로 C42-7에 원형 이관 완료. C42-4 "C31 병립" 조항은 폐기 확정으로 삭제
### 원 본문 경위 (간략)
- 2026-04-17 PD 직접 지시로 신설 (C29 위반 재발 방지). 이후 2026-04-18 D·E 그룹 추가 → 2026-04-19 F·G 그룹 추가 → 2026-04-20 H·I 그룹 추가로 누적 9그룹 도달
- NerdNavis 조직에서 PM 위반 변종 누적으로 "사후 검증 한계" 확인 → 2026-04-23 C42 사전 검증 신설로 효과 단절 · C31 폐기 필연
### 대체 관계
- **C42**: 사전 검증 6항목 (응답 작성 시작 전)
- **C42-7**: BT 고유 9그룹 보강 체크리스트 (응답 발신 직전 · 구 C31-1 A~I 원형 보존 + J K 신설)
- **C42-8·C42-9·C42-10**: 실행 방식·위반 처분·본 규칙 무게 (구 C31-2·C31-3·C31-5 계승)
### 재활용 금지
C31 번호 재사용 금지 (C14-5 확장 "번호 구멍 허용"). 번호 체계 연속성은 조직 기억의 자산이 아님.
### 연관 자산
-`memory/org/feedback_pm_context_restoration_failure.md` (구 C31 신설 근거 영구 기록)
-`memory/org/feedback_pm_violation_data_archive.md` (C42 신설 근거 — PM 9회 변종 데이터)
---
## 17. P17 — 수상한잡화점 전용 ★ 조건 배타 조합 규칙 (2026-04-21 완전 폐기 · 2026-04-24 BT10 아카이브 등재)
3.**변경 전 상태**: 구 "수상한잡화점" 프로젝트 전용 **★ 조건 배타 조합 규칙**. 스테이지 기획 시 배타 조합 7종 전수 체크·위반 차단 의무. 기획팀장·레벨 디자이너 대상 고정비 규약으로 운용
4.**변경 후 상태**: 완전 폐기 (BT 조직 전환 후 수상한잡화점 프로젝트 자체 삭제 · 후속 대체 규칙 없음)
5.**사유**: (ㄱ) BT 조직 첫 게임 프로젝트가 **EerieVillage (2D PlatformerMicrogame)**로 확정되어 장르·장르 관습 이질 — 수상한잡화점 시뮬/경영 장르 전용 규약이 플랫포머 장르에 부합하지 않음 (ㄴ) BT 조직 전환 8개 지시 #3 "수상한잡화점 삭제"로 해당 프로젝트 자체 소멸 · 규칙 유지 근거 상실
6.**경위**: PD 직접 결정 2026-04-21 (BT 조직 출범 시 프로젝트 구성 재편). 2026-04-24 BT10 pm-auditor·plan-auditor 감사 중 아카이브 누락 발견 · PD 승인으로 본 등재
### 원 규칙 특성 (역사 보존)
- 대상 프로젝트: 수상한잡화점 (NerdNavis 조직 시절 프로젝트)
- 범위: 스테이지 기획 시 배타 조합 7종 전수 체크 의무
- 책임 주체: 기획팀장·레벨 디자이너
- 성격: 프로젝트 단위 고정비 규약 (조직 공용 아님)
### 대체 관계
- **후속 대체 규칙 없음** (EerieVillage 장르 이질로 장르별 고유 규약 각자 개발)
- **프로젝트별 고유 규약 접근 계승**: EerieVillage는 기획팀 6종 전문 에이전트가 장르 관습 기반 신규 규약 수립 (기존 P17 발상 계승)
### 재활용 금지
P17 번호 재사용 금지 (C14-5 확장 "번호 구멍 허용" · C37-2 "번호 체계 연속성은 자산 아님"). 차기 프로젝트에서 유사 규약 필요 시 신규 번호로 발급
### 연관 자산
- **P29-3** EerieVillage 활용 방침 (차기 프로젝트 고유 규약 신규 개발 원칙)
