m1nga/iteration-close

iteration-close — 증류, 제거, 테이크오버 입증, 부트스트랩 리허설, 다음 단계 시드

영원히 반복되는 제품은 두 가지 침묵의 부채를 축적하며, 이 스킬은 모든 반복 주기 경계에서 이 부채를 안전하게(잃는 것은 없지만) 냉혹하게(죽은 것은 남기지 않음) 상환합니다:

• 죽은 파일은 남아 이중 진실로 썩습니다 — 사용 중단된 트리는 몇 주 동안 방치되고, 런북은 컴포넌트가 "구축되지 않았다"고 주장하는데 실제로는 이미 출시된 후입니다.
• 채팅 창에만 존재하는 지식은 그와 함께 사라집니다 — 전체 작동 파이프라인이 스크래치패드에서 사라진 적이 있으며; 힘겹게 얻은 결정은 세션과 함께 죽습니다. 결과물이 아닌 교훈을 간직하십시오.

이 스킬은 범용적입니다. 저장소 자체의 규칙을 읽어 모든 저장소에서 작동하며, 규칙이 없으면 가정하거나 오류를 발생시키지 않고 최소한의 것을 만듭니다. "새 창이나 새 머신이 계속할 수 있다"는 테스트되기 전까지는 희망일 뿐입니다; 최신 상태 유지(pull)는 항상 안전하지만, 게시(push)는 의도적인 선택입니다. 사용자가 작업 중인 언어로 응답하십시오.

두 가지 실행 방식

• 전체 종료(기본값): 다섯 단계 모두 순서대로 실행합니다. 반복/조각이 완료되어 사용자가 종료를 원할 때 사용합니다.
• 제거 전용(독립 실행형 정리): 사용자가 오래된/죽은/대체된 파일을 정리하도록 요청한 경우에만 2단계를 실행하십시오 — 전체 5단계 종료를 강요하지 마십시오. 전제 조건은 여전히 적용됩니다: 0단계(오리엔테이션) 실행, 실패 시 종료 거부 검사, 삭제 인벤토리 범위 내의 1단계 스팟 체크(교훈이나 결정이 채팅에만 있는 항목은 먼저 추적된 파일로 증류되거나 인벤토리에서 제외). 명시적 동의 게이트와 격리 규칙을 포함한 모든 2단계 규칙은 변경 없이 적용됩니다.

0단계 — 이 저장소에 오리엔테이션(발견, 없으면 생성 계획)

CLAUDE.md / AGENTS.md / README / docs/ 인덱스와 같은 진입 문서를 읽고 여섯 가지를 발견합니다. 찾은 것을 사용하고, 없는 것은 이 종료가 채울 간격으로 기록하십시오(각 단계는 아래에서 방법을 설명), 결코 존재하지 않는 경로를 발명하지 마십시오.

1. 교훈/결정 기록 — 이 저장소는 결정을 어디에 보관합니까? (CHANGELOG, docs/adr/, DECISIONS.md, 또는 저장소별 레지스터). 없으면 1단계에서 단일 DECISIONS.md를 만듭니다.
2. 확인된 업로드 명령 — 의도적인 푸시 단계(bin/sync, make deploy, 문서화된 git push 규칙)가 있습니까? 그렇다면 그것이 업로드 채널입니다. 절대로 우회하지 마십시오. 없으면 3a단계에서 diffstat + 확인 후 일반 git push를 사용합니다.
3. 부트스트랩 명령 — 새 클론이 어떻게 활성화됩니까? (bin/bootstrap, bin/sync-setup, install.sh, make setup, 패키지 관리자 설치). 없으면 4단계에서 하나를 만듭니다.
4. 테스트 명령 — CI 설정, package.json 스크립트, Makefile, 또는 언어 기본값(pytest / go test / cargo test / npm test)에서 찾습니다. 발견할 수 없으면 저장소에 아직 실행 가능한 스위트가 없는 것입니다: 아래 명시적 상태로 처리하십시오 — 절대 "녹색"으로 읽지 말고, 합법적으로 없는 저장소에서 REFUSE하지 마십시오.
5. 근거/게이트 스킬 — 제품 근거 또는 빌드 전 게이트 스킬이 있습니까? 그렇다면 "빌드 후" 체크리스트가 종료 전 게이트입니다. (제품별 게이트는 제품 저장소 내에 존재합니다; 이 스킬은 일반적으로 유지되며 이를 따릅니다.)
6. 선언된 데이터/복구/격리 디렉토리 — 진입 문서가 실제 데이터, 복구 자료 또는 격리된 파일을 보유한다고 명명한 디렉토리. 이 디렉토리는 아래의 "보관소 모양 디렉토리가 존재하지 않아야 함" 규칙에서 면제되며 삭제 인벤토리에 절대 나타나지 않아야 합니다.

실행 거부(실패 시 폐쇄)

반복 주기 중간에 종료하지 마십시오 — 피부와 살을 모두 잃습니다. 다음 경우에 거부하십시오(두 실행 모드 모두): 디렉토리가 git 저장소가 아닌 경우(멈추고 알리십시오 — git init 실행은 사용자의 결정입니다); 테스트 스위트가 존재하고 실제로 실패하는 경우(없는 스위트는 실패하는 스위트가 아닙니다 — 0.4단계 참조); 적대적 게이트가 있고(저장소에 있는 경우) 보류 중이거나 CHANGES-REQUIRED인 경우; 다른 에이전트/레인이 건드릴 경로에서 커밋되지 않은 중간 조각 작업이 있는 경우. 무엇이 차단되고 있는지 말하고 중지하십시오.

전체 종료에서는 단계를 순서대로 실행하십시오. 각 단계에는 종료 테스트가 있습니다. 실패한 종료를 넘어 진행하지 마십시오.

1단계 — 증류(구조 게이트: 교훈이 저장되기 전에는 아무것도 사라지지 않음)

1. 이 반복 주기 동안 채팅에서 나온 결정을 저장소의 결정 기록(0.1단계)으로 스위프하고, 각 결정에 상태와 출처를 포함합니다. 저장소가 아무데도 결정을 저장하지 않는 경우, 기록을 만드는 것이 이 단계의 일부입니다 — 저장소 루트에 단일 DECISIONS.md이면 충분합니다. 채팅 창에만 존재하는 결정은 존재하지 않는 것입니다; 추적된 집이 없는 증류된 결정을 남기지 마십시오.
2. 이 반복 주기에서 발견된 새로운 불변/규칙 → 저장소의 계약 파일, 또는 그것이 없으면 결정 기록 — 이상적으로는 각각 테스트로. 둘 다 없으면 결정 기록을 만들고 거기에 넣으십시오. 결과물을 삭제하고 불변을 유지하십시오.
3. 세션 전용 기능 확인: 이 반복 주기가 프롬프트, 스크래치패드 또는 누군가의 기억에만 존재하는 것에 의존했습니까? 이를 저장소(코드/스킬/문서)로 승격시키거나 의도적인 제외를 기록하십시오. 각각을 명시적으로 명명하십시오 — 이것이 파이프라인이 죽는 곳입니다.
4. STRUCTURE가 변경된 경우, 업데이트하거나 — 없고 구조가 이제 사소하지 않은 경우 — 현실을 설명하는 짧은 아키텍처/시스템 노트를 만드십시오. 저장소에 진행 상황 보드(예: 진행 문서)가 있으면 최신 상태로 만드십시오.

종료 테스트: 이 반복 주기의 핵심 결정과 불변을 저장소 내에서 grep하십시오 — 모든 것이 추적된 파일에서 찾을 수 있어야 합니다. 채팅에서만 찾을 수 있는 것이 있으면 1단계가 완료되지 않은 것입니다.

2단계 — 제거(냉혹한 삭제; git 히스토리가 유일한 아카이브)

1. 증거와 함께 삭제 인벤토리를 작성하십시오, 한 줄에 하나씩: 경로 | 죽은 이유 | 대체하는 것. 대체된 모듈/사양, 죽은/빈 디렉토리, 개발 잔여물(스크래치 파일, mktemp 스타일 쓰레기, 실제 모양 저장소의 테스트 행), 완료된 계획/TODO 문서, STALE DOCS를 포함하십시오 — 문서 대 코드 모순 검사를 실행하십시오; 코드와 모순되는 것을 주장하는 문서는 없는 것보다 나쁩니다. 각 줄을 TRACKED 또는 UNTRACKED(git ls-files --error-unmatch <path>)로 표시하십시오, 왜냐하면 두 가지는 다른 운명을 가지기 때문입니다(규칙 3 및 4).
2. 사용자에게 COMPLETE 인벤토리를 제시하고 아무것도 삭제하기 전에 명시적인 동의를 기다리십시오. 부분 승인은 괜찮습니다 — 승인된 줄에 대해서만 작업하십시오. 에이전트는 스스로 되돌릴 수 없는 버튼을 누르지 않습니다; "사용자가 정리를 요청했습니다"는 목록 작성을 승인하는 것이지 실행을 승인하는 것이 아닙니다.
3. 추적된 파일: git rm만 사용하십시오. _archive/ 디렉토리, .bak, old-/legacy- 이름 변경, 주석 처리된 시체는 NO입니다. 복구 = git 히스토리, 한 번의 git revert로 — 그것이 아카이브입니다; 삭제 전 체크포인트 커밋은 이를 확실하게 만듭니다.
4. 추적되지 않거나 gitignored된 파일: 직접 rm하지 마십시오 — git 히스토리는 커밋되지 않은 것을 복구할 수 없습니다. 이것이 데이터 안전 라인입니다. 대신 저장소의 선언된 격리 디렉토리(0.6단계)로 이동하십시오. 선언된 것이 없으면 지금 하나를 만드십시오: 저장소 루트에 .iteration-quarantine/, .gitignore에 추가, 진입 문서에 한 줄로 선언("삭제 보류 중인 추적되지 않은 파일을 위한 격리 — 사용자가 수동으로 비움"). 격리 비우기는 사용자의 행위입니다 — 다음 종료 시 자체 명시적 동의와 함께 제공하십시오; 절대 조용히 하지 마십시오.
5. 제품의 실제 DATA를 개발 잔여물처럼 제거하지 마십시오. 사용자/고객 상태, 저장된 세션, 사용자 콘텐츠의 실제 아카이브는 쓰레기처럼 보일 수 있지만 제품의 핵심입니다. 디렉토리가 둘 중 하나일 수 있는 경우 데이터로 취급하고 유지하십시오; git rm 전에 확인하십시오.
6. 삭제를 주제별 그룹으로 커밋하십시오; 각 메시지는 WHY + 대체하는 것을 말합니다.
7. 삭제 후 검사(해당하는 모든 것 통과): 저장소에 테스트 스위트가 있으면 녹색입니다; 삭제된 모든 모듈/심볼에 대한 매달린 참조 grep이 비어 있습니다(삭제된 파일의 import는 시작 시 충돌합니다 — 실제 상처); 진입 문서와 스킬 문서가 삭제된 경로를 참조하지 않습니다.

종료 테스트: git status가 깨끗하고, 보관소 모양 디렉토리가 존재하지 않습니다 — 진입 문서가 데이터, 복구 또는 격리(0.6단계)로 선언한 디렉토리는 제외 — 매달린 grep이 비어 있고, 테스트 스위트가 있으면 녹색입니다.

3단계 — 두 가지 준비 채널(다른 요구 사항; 별도로 확인)

업로드와 지속 가능성은 동일한 문제가 아닙니다. 이 둘을 혼동하면 저장소가 "클라우드에 푸시"되었지만 실제 상태는 여전히 채팅 로그에 남아있는 상황이 발생합니다. 각각을 독립적으로 확인하십시오.

3a. 확인된 클라우드 업로드(전송 문제)

1. TRACKED 파일만 비밀 스캔(sk-ant / ghp_ / gho_ / github_pat / AKIA / xox[baprs] / consumer_secret / access_token / Bearer / BEGIN PRIVATE KEY / .env 형태). 적중 시 → 중지, 스크럽, 재스캔.
2. git remote를 확인하십시오. 원격이 없으면 업로드에 사용자가 제공하는 것이 필요합니다 — 원격 추가는 설정 변경이므로 사용자에게 확인하거나 "아직 원격 없음 — 게시 연기됨"을 기록하고 3b로 건너뛰고 기본 git 명령에서 오류를 내지 마십시오.
3. 원격이 있는 경우: git log @{u}..HEAD --oneline + diffstat를 표시하십시오(업스트림이 아직 없으면 "모든 로컬 커밋"으로 대체) — 이 머신을 떠날 정확한 내용입니다.
4. 사용자 확인 후 저장소의 확인된 업로드 명령(0.2단계)을 통해 업로드하십시오; 저장소에 없으면 diffstat 및 동의 후 git push하십시오. 절대 자동 푸시하지 마십시오.

3b. 제로 컨텍스트 테이크오버(지식 완전성 문제) — 콜드 스타트 프로브

1. 저장소에 대해 진정으로 컨텍스트가 없는 독자를 하나 얻으십시오 — Claude Code: 새 하위 에이전트 생성(Task 도구); Codex: 새 codex exec 또는 이전 컨텍스트가 없는 새 세션 실행; 모든 베어 하네스에서: 새 세션을 열고 저장소 경로와 질문만 붙여넣고, 이 대화는 절대 붙여넣지 마십시오. 저장소 경로와 함께 다음만 제공하십시오: "이 저장소를 진입 문서에서 콜드로 읽으십시오. 그런 다음 답변하십시오: (1) 이 제품은 무엇입니까, 한 문장으로; (2) 작업은 어디에 있습니까(완료/다음); (3) 다음에 무엇을 할 것이며 왜 그렇습니까; (4) 여기서 절대 해서는 안 되는 세 가지를 말하십시오."
2. 저장소의 표준 문서를 기준으로 답변을 평가하십시오. 저장소에 진입/표준 문서가 전혀 없으면 최소한의 문서(제품을 한 문장으로, 현재 상태 완료/다음, 세 가지 절대 금지 사항)를 만드는 것이 이 종료의 일부입니다 — 프로브가 평가하는 결과물입니다. 아무것도 없는 상태에서 프로브를 실행하지 마십시오.
3. 모든 잘못되거나 누락된 답변은 프로브의 잘못이 아닌 TAKEOVER-DOC BUG입니다. 문서를 수정(또는 생성)하고, 새로운 독자로 다시 실행하십시오. 콜드 독자가 4/4를 얻을 때까지 반복하되 최대 3회로 제한하십시오 — 3회 후에도 실패하면 남은 격차를 나열하고 결정을 사용자에게 맡기십시오.

종료 테스트: 프로브가 4/4를 통과합니다. 그래야만 "새 창/머신이 계속할 수 있다"가 테스트된 사실이 됩니다.

4단계 — 단일 명령 부트스트랩(리허설, 가정 아님)

1. 저장소의 부트스트랩(0.3단계)이 존재하고 최신인지 확인하십시오 — 멱등적이고, 다시 실행해도 안전합니다: 도구 체인 버전 확인; 동기화/설정 연결; 종속성 설치; 테스트 스위트가 있으면 실행; 현재 상태 + 누락된 로컬 시크릿의 이름(절대 값, 예: "config.local.json 없음 — 라이브 게시에만 필요")을 출력; 실패 시 0이 아닌 종료 코드와 한 줄 이유를 반환. 아직 부트스트랩이 없으면 이 반복 주기에서 만드십시오.
2. 리허설: 저장소를 스크래치 디렉토리(원본 URL에서, 또는 아직 원격이 없는 경우 로컬 저장소 경로에서)로 클론하고 거기서 부트스트랩을 실행하십시오. 수동 단계 없이 녹색으로 끝나야 합니다. 리허설 클론을 삭제하십시오.
3. 새 머신 스토리는 한 줄이어야 하며 이 리허설 후에 TRUE여야 합니다: git clone <origin-url> <dir> && cd <dir> && <bootstrap command>. 아직 원격이 없으면 이 줄이 사용자가 설정할 때까지 참이 아니라는 점을 기록하십시오 — 작동하는 것처럼 게시하지 마십시오.

종료 테스트: 리허설 클론이 수동 개입 없이 녹색으로 부트스트랩됩니다.

5단계 — 종료 + 시드(연속성)

1. 반복 주기에 태그를 붙이십시오: git tag iter-<N>-<slug>(주석, 한 줄 요약). N = 1 + 기존 iter-* 태그 수(git tag --list "iter-*"); 첫 번째 종료는 iter-1입니다.
2. 저장소에 상태 보드/로그가 있으면 한 줄로 업데이트하십시오: 증류된 것, 제거된 파일 수, 프로브 4/4, 부트스트랩 리허설.
3. 다음 반복 주기 시드를 채팅으로 내보내십시오: 이 반복 주기에서 제기된 열린 질문 + 다음 조각을 위한 붙여넣기 가능한 시작 프롬프트(목표, 승인 기준, 그리고 저장소에 근거 게이트가 있으면 빌드 전에 실행하라는 알림).

주요 반복 주기 — STRUCTURE 자체가 교체되는 경우(동일한 규칙, 더 큰 규모)

구조적 개편 — 새 아키텍처, 새 모듈 트리, 심지어 "이전 접근 방식이 잘못되었습니다"와 같은 경우 — 여전히 하나의 유기체의 ITERATION일 뿐, 다시 시작이 아닙니다. git 히스토리, 결정, 교훈을 유지합니다; 피부만 새 것입니다. 다시 시작은 출혈을 유발합니다: 프로젝트가 새 저장소에서 다시 태어날 때마다 교훈 수준의 자료가 뒤에 남겨집니다. 따라서:

• 이 저장소 내에서 기존 구조 옆에 새 구조를 성장시키십시오(strangler 패턴): 새 트리는 먼저 테스트와 소유권을 획득합니다; 기존 트리는 아무것도 참조하지 않을 때만 2단계에서 사망합니다.
• 새 저장소를 여는 것은 비용이 많이 드는 예외이며 기본값이 아닙니다 — 이 히스토리를 포기해야 하는 이유를 명시한 기록된 결정이 필요하며, 파일 이동 전에 승인되어야 합니다.
• 동일한 다섯 단계; 삭제 인벤토리는 더 크고 콜드 스타트 프로브는 더 중요합니다 — 새 구조의 문서는 낯선 사람을 만난 적이 없습니다.
• 제품의 이름이나 진입 명령이 변경되면 4단계의 한 줄 스토리가 동일한 반복 주기에서 업데이트됩니다. 두 개의 활성 이름은 이중 진실 버그입니다.

가드레일(협상 불가)

• 단계 순서는 안전 메커니즘입니다: 증류(1단계)가 종료되기 전에 제거(2단계)하지 마십시오 — 제거 전용 모드에서는 인벤토리에 대한 1단계 스팟 체크가 그 게이트입니다.
• 완전한 삭제 인벤토리가 사용자에게 표시되며, 명시적 동의 없이는 아무것도 삭제되지 않습니다. 에이전트는 스스로 되돌릴 수 없는 버튼을 누르지 않습니다.
• 추적되지 않거나 gitignored된 파일은 격리되며, rm되지 않습니다 — git 히스토리는 이를 복구할 수 없습니다.
• 삭제에는 증거가 필요하며 느낌이 아닙니다. 진정으로 확실하지 않습니까? 한 번 더 반복 주기 동안 유지하고 의심을 기록하십시오.

삭제 인벤토리에 있는 모든 항목은 대체 항목이 필요합니다. 대체 항목은 이것을 무효화하는 것, 변경된 사양, 리팩토링, 아키텍처 결정 등입니다. 정당화할 수 없으면 유지하십시오.