sanitize-for-releaselisted

# 공개 전환 정제 (sanitize for release) 개인용으로 만든 것을 불특정 다수가 클론하는 자리에 올리는 순간, 두 종류의 사고가 동시에 열린다. 하나는 **개인정보 유출**(실명·연락처·주소·크리덴셜)이고, 다른 하나는 **자기완결성 붕괴**(저자 컴퓨터에만 존재하는 경로·스킬·계정을 가리켜 외부 사용자에겐 아무것도 동작하지 않음)다. 둘은 원인이 같다: 만들 때는 독자가 자기 자신뿐이었다는 것. 공개는 되돌릴 수 없다. 비공개로 되돌려도 fork·클론·캐시·검색 색인에는 닿지 않는다. 그래서 이 절차는 **공개 전환 직전이 아니라 공개를 결정한 시점에** 돌린다. ## 0단계: 대상과 저장소 유형 판정 먼저 무엇을 공개하는지 확정한다: 저장소 경로, 공개 대상(GitHub Public·npm·PyPI·npx skills), 이미 원격이 있는지, 히스토리가 있는지. 그다음 **유형을 가른다**. 유형이 다르면 절차 자체가 다르므로 한 체크리스트로 뭉개지 않는다. 판정 질문 하나면 된다. > **민감한 것이 이 저장소에서 무엇인가?** | 답 | 유형 | 뜻 | |---|---|---| | 사고로 섞여 들어간 **흔적** | **A. 동일 파일 공개형** (in-place) | 정본 = 공개본. 민감 정보는 애초에 없어야 했다. 발견하면 그 자리에서 제거하고 이후 편집마다 상시 점검한다 | | 정본의 **정당한 내용** | **B. 정본/반출본 분리형** (export) | 저자는 실명·기관명이 든 정본을 계속 실사용해야 한다. 공개본은 그것의 치환 사본이고, 정본은 공개 저장소에 두지 않는다 | | 코드가 먹는 **입력 데이터** | **C. 원본 격리형** (isolate) | 코드는 공개하고 데이터는 못 한다. 원본을 저장소 밖으로 옮기고 익명화 fixture만 커밋한다 | 한 저장소가 둘 이상에 해당하는 것은 정상이다(코드는 A인데 테스트 데이터만 C인 경우). 그때는 축별로 나눠 적용하고, 어느 부분이 어느 유형인지 판정 근거를 한 줄 남긴다. 유형별 상세 절차는 [references/repo-types.md](references/repo-types.md)를 읽는다. 유형이 정해진 뒤에만 읽으면 된다. ### 세 유형과 히스토리 재작성은 경쟁이 아니라 층이다 A·B·C가 **앞으로 들어올 것**을 막는 층이라면, 히스토리 재작성(3단계)은 **이미 들어온 것**을 되돌리는 소급 층이다. 공개 시점에는 둘이 거의 항상 함께 간다. 격리 없이 재작성만 하면 다음 커밋에 같은 것이 다시 들어오고, 재작성 없이 격리만 하면 과거 커밋이 그대로 남는다. 그래서 유형을 골랐다고 3단계를 건너뛸 수 없다. 두 층은 **같은 치환표를 쓴다.** B의 반출 치환과 소급 치환은 "무엇을 무엇으로 바꾸나"가 같은 질문이고, 표가 둘로 갈리는 순간 한쪽에만 등록된 표기 변형이 생겨 그것이 이력에 남는다. 패턴 파일 하나를 두 자리에 쓴다(1단계). ## 1단계: 패턴 파일 확보 실명·주소·계정 같은 **실제 식