4,724개를 옮기지 않고 Downloads에 관리계약부터 설치했습니다

한 줄 요약
파일과 패키지가 뒤섞인 Downloads를 곧바로 자동 정리하지 않고 유입 관문으로 다시 정의했습니다. 기존 4,724개 항목은 그대로 둔 채 상세 관리규칙과 얇은 AGENTS.md 진입점 두 개만 설치하고, 전후 metadata fingerprint와 25개 계약 검사로 비파괴 적용을 확인했습니다.

검증 상태
기존 파일 4,515개·디렉터리 209개, 합계 4,724개 항목의 경로·종류·크기·수정시각·장치·inode 기반 fingerprint가 전후 일치했습니다. 계약 검사 25/25 PASS, 새 제어 파일 2개, 기존 payload 이동·복사·개명·격리·삭제 0건입니다. 다만 모든 기존 파일의 내용을 전부 해시한 것은 아니므로, 이 결과는 metadata 표면 불변 증거이지 전체 payload의 byte-for-byte 내용 불변 증명은 아닙니다.

먼저 보는 결과

• Downloads를 canonical·보관소·폐기함이 아닌 유입 관문과 관찰 지점으로 정의했습니다.

• 상세 규칙 00_DOWNLOADS_관리규칙.md와 에이전트 발견용 AGENTS.md를 분리했습니다.

• 기존 4,724개 항목을 제외 기준이 고정된 전후 inventory로 비교했습니다.

• 기존 항목 수, 파일·디렉터리 구성, 논리 파일 용량, metadata fingerprint가 모두 일치했습니다.

• 관리 계약의 필수 항목과 금지 상태를 검사해 25/25 PASS를 확인했습니다.

• watcher, scheduler, 자동 이동·개명·격리·삭제, 실시간 자료사슬 바인딩은 모두 OFF입니다.

• 실제 절감 시간, 검색 성공률, 디스크 공간 회수량은 측정하지 않았습니다.

• 이 글의 발행 범위는 local Library이며, 외부 웹·커뮤니티 재게시는 NOT RUN입니다.

그림 1. 실행 영수증에서 생성한 데이터 파생 증거 카드. live UI 화면이 아니다. 1.80GB는 관찰된 파일의 논리 용량이며 실제 디스크 할당량이나 회수 가능 용량과 같지 않을 수 있다.

이 사례가 필요한 사람

다음과 같은 상황에 특히 유용합니다.

1. 다운로드 폴더가 오래되어 파일뿐 아니라 저장소·앱 패키지·중간 작업물까지 섞여 있는 경우

2. AI에게 “정리해 달라”고 맡겼다가 대량 이동이나 이름 변경이 일어날까 불안한 경우

3. 자동 정리보다 먼저 무엇을 해도 되고 무엇은 승인받아야 하는지 계약하고 싶은 경우

4. 규칙 파일을 만들었다는 사실과 실제 watcher가 가동 중이라는 사실을 구분하고 싶은 경우

5. “아무것도 망가뜨리지 않았다”는 말을 전후 증거로 확인하고 싶은 경우

이 사례의 핵심은 깔끔한 폴더 트리를 만든 것이 아닙니다. 혼합 유입 폴더를 건드리기 전에 에이전트의 권한, 처리 순서, 완료 조건과 증거 형식을 먼저 고정한 것입니다.

문제는 지저분한 화면보다 역할이 불명확하다는 데 있었습니다

일반적인 Downloads에는 서로 역할이 다른 자료가 같은 표면에 놓입니다.

• 브라우저에서 방금 받은 원본

• 메일이나 메신저에서 받은 근거 자료

• 변환 작업을 마친 중간 산출물

• 다른 곳에 canonical이 있는 전달용 복사본

• 설치 파일이나 실행 패키지

• 내부 링크와 manifest를 가진 프로젝트 디렉터리

• 목적을 아직 확인하지 못한 오래된 자료

이들을 확장자나 날짜만 보고 한꺼번에 분류하면 시각적으로는 정돈될 수 있습니다. 그러나 다음 질문에는 답하기 어렵습니다.

• 이 파일은 취득 원본인가, 작업본인가, 이미 발행된 복사본인가?

• 이 디렉터리를 평탄화하면 내부 링크나 저장소 상태가 깨지지 않는가?

• 같은 SHA-256인 두 파일이 정말 같은 역할인가?

• 목적지에 같은 파일이 있다는 사실만으로 이 파일을 지워도 되는가?

• 규칙 문서를 썼다는 것과 자동화가 실제로 켜졌다는 것을 어떻게 구분할 것인가?

그래서 출발점을 바꿨습니다.

Downloads에 있다는 사실은 여기에서 관찰되었다는 뜻이지, 이동·보존·삭제 권한을 뜻하지 않는다.

참고 사례의 하네스 구조를 그대로 복사하지 않고 경계부터 바꿨습니다

도움을 받은 글은 인박스 처리 업무를 다음 일곱 칸의 계약으로 만들었습니다.

그리고 실제 실행을 Trace / Proof / Verdict / Repair 영수증으로 남겼습니다.

원 글의 작은 정상 실행은 PDF 한 건을 읽고 정해진 레이어로 라우팅한 사례였습니다. 이번 적용 대상은 성격이 달랐습니다. 이미 수천 개 항목이 있고 패키지 경계도 불명확한 일반 다운로드 폴더였습니다. 따라서 “한 번 잘 옮겨 보기”보다 기존 payload를 먼저 보호하고 절차 제어면만 설치하는 것이 우선이었습니다.

적용 방향은 다음처럼 달라졌습니다.

참고 사례
사용자 Trigger → 자료 판독 → 원본·파생문서 라우팅 → lint → 영수증

이번 사례
사용자 Trigger → 기존 표면 동결 → 관리계약 설치 → 전후 불변 검증
             → 자동 집행 OFF 확인 → 절차 전용 Verdict

Downloads를 유입 관문으로 다시 정의했습니다

관리계약의 생명주기는 다음과 같습니다.

arrived
  → observed
  → classified
  → handed_off 또는 retained
  → cleanup_candidate
  → 별도 승인 후 quarantine 또는 delete

이 순서는 다음 두 가지 단축을 금지합니다.

arrived → auto-moved
same hash → auto-deleted

arrived

앱이 파일을 정상적으로 내려놓은 상태입니다. 도착만으로 이동·분류·삭제를 시작하지 않습니다.

observed

필요한 범위에서 경로, 종류, 크기, 수정시각, 패키지 경계와 이용 가능한 출처 단서를 읽습니다. 동일성이나 인계가 중요할 때만 전체 SHA-256을 계산합니다.

classified

확장자보다 역할을 우선합니다.

• source: 취득 원본 또는 근거 자료

• workbench: 처리 중인 입력·출력

• canonical: 도메인의 검증된 기준본

• backup: 의도적인 복제본

• publication: 전달·발행용 판본

• installer: DMG·PKG·앱·실행 패키지

• temporary_candidate: 재생성 가능성이 있는 임시 후보

• unknown: 목적이나 의존관계 확인이 필요한 자료

handed_off 또는 retained

명확한 목적지가 있으면 source·destination·bytes·SHA-256·역할·충돌 결과·rollback 좌표를 가진 영수증으로 인계합니다. 목적이 불명확하면 현 위치에 유지하고 needs-review로 남깁니다. 유지 상태는 실패가 아닙니다.

cleanup_candidate

후보 탐지와 실제 삭제를 분리합니다. 목적지와 hash, 활성 참조, 보존 역할, 복원 근거, 승인 여부를 확인하기 전에는 격리하거나 삭제하지 않습니다.

긴 규칙과 얇은 발견 진입점을 분리했습니다

한 파일에 모든 내용을 넣으면 에이전트가 진입점을 놓치기 쉽고, 반대로 AGENTS.md에 전체 정책을 복제하면 두 문서가 서로 다르게 변할 수 있습니다. 그래서 제어면을 두 층으로 나눴습니다.

1. 상세 관리규칙
   생명주기, 역할 어휘, 중복·충돌 정책, 승인 경계, 영수증 구조, 완료 Gate와 현재 집행 상태를 담습니다.

2. 얇은 AGENTS.md 진입점
   에이전트가 폴더에서 작업하기 전에 상세 규칙을 읽도록 연결하고, 이동·삭제·실행·외부 게시 같은 절대 금지만 짧게 반복합니다.

그림 2. 상세 규칙은 10,006바이트, 발견 진입점은 1,991바이트였다. 두 파일 모두 작성 후 bytes·SHA-256 read-back을 수행했고 계약 필수 항목·금지 상태 검사 25개를 모두 통과했다.

두 파일은 일반 유입 payload가 아니라 제어면입니다. 따라서 일반 분류·중복 patrol·cleanup candidate 처리에서 제외합니다. 하위 패키지에 더 가까운 AGENTS.md가 있다면 그 로컬 계약도 함께 존중합니다.

“아무것도 망가뜨리지 않았다”를 exclusion-stable fingerprint로 확인했습니다

제어 파일을 두 개 추가하면 폴더 전체 항목 수는 당연히 변합니다. 단순히 전후 전체 hash를 비교하면 정상적인 제어면 추가도 변경으로 잡힙니다. 반대로 새 파일을 제외한다는 이유로 매번 다른 기준을 사용하면 원하는 결과를 만들 수 있습니다.

그래서 쓰기 전에 제외할 제어 파일명 두 개를 먼저 고정하고, 그 두 파일만 제외한 동일한 inventory 알고리즘을 전후에 적용했습니다.

각 기존 항목에 대해 정렬된 다음 표면을 fingerprint에 포함했습니다.

relative path
kind
size
mtime_ns
device
inode

전후 결과는 다음과 같았습니다.

최상위 항목은 128개에서 130개가 되었습니다. 증가분은 의도한 제어 파일 두 개와 정확히 일치했습니다.

여기에는 중요한 증거 경계가 있습니다.

이 fingerprint는 관찰된 경로·종류·크기·수정시각·장치·inode 표면이 같다는 증거입니다. 기존 4,515개 파일의 전체 내용을 모두 읽어 byte-for-byte 불변을 증명한 것은 아닙니다.

전체 payload hash는 비용이 크고 이번 목적에 필요하지 않았습니다. 대신 파일 인계, 동일성 판정, 발행처럼 bytes가 중요한 순간에만 전체 SHA-256을 요구합니다.

같은 SHA-256과 삭제 권한을 분리했습니다

관리규칙에는 다음 세 줄을 명시했습니다.

같은 SHA-256 = 같은 bytes
같은 SHA-256 ≠ 같은 역할
같은 SHA-256 ≠ 삭제 허가

같은 내용이어도 다음 복제는 의도적으로 남을 수 있습니다.

• 취득 원본과 canonical

• 작업본과 publication

• 서로 다른 장애영역의 backup

• 자체완결형 전달 패키지

• 법률·계약·증거 자료

• 독립 심사를 통과한 이전판

따라서 중복 후보는 자동 삭제 목록이 아닙니다. 역할, 참조, 보존 의무, 생존본, rollback과 실제 공간 회수 가능성을 검토하기 위한 review queue입니다.

정책과 실제 집행 상태를 따로 기록했습니다

규칙 파일이 존재해도 watcher나 scheduler가 가동되는 것은 아닙니다. 이 구분을 흐리면 문서만 만든 상태를 “자동화 완료”라고 과장하게 됩니다.

그림 3. 활성화된 범위와 실행하지 않은 범위를 분리한 카드. 현재 Verdict는 자동 정리 시스템 가동이 아니라 PASS_WITH_PROCEDURAL_ENFORCEMENT_ONLY이다.

도착은 관찰의 Trigger가 될 수 있지만 이동·삭제 허가는 아닙니다. 현재의 자동화 범위는 사용자가 처리를 요청한 뒤 에이전트가 정해진 절차와 완료 Gate를 따라가는 데까지입니다.

어디서 막혔고 무엇을 고쳤나

1. “관리규칙”과 “자동 정리 가동”을 혼동할 뻔했습니다

규칙을 만든다는 요청을 watcher 설치로 해석하면 지속적인 파일 관찰과 이동이 시작될 수 있습니다. 그러나 자동 집행의 범위, 오탐 처리, 중지 절차와 삭제 승인 정책은 별도 검증이 필요했습니다.

수정: 이번 단계의 산출물을 절차 계약으로 제한하고 watcher·scheduler·파괴적 작업을 모두 OFF / NOT RUN으로 명시했습니다.

2. 새 제어 파일 때문에 전후 항목 수가 달라졌습니다

전체 항목 수만 보면 설치 전후가 다릅니다. 그렇다고 설치 후에 새 파일을 임의로 빼면 검증 기준이 사후 변경됩니다.

수정: 쓰기 전에 제외 파일명을 고정하고, 동일한 제외 기준으로 기존 4,724개 항목만 전후 비교했습니다. 최상위 +2도 의도한 제어 파일과 대조했습니다.

3. 한 문서가 너무 길거나 두 문서가 서로 드리프트할 수 있었습니다

상세 정책만 두면 에이전트가 발견하지 못할 수 있고, 두 파일에 전체 내용을 복제하면 서로 다른 규칙이 생길 수 있습니다.

수정: AGENTS.md는 상세 정본을 가리키는 얇은 진입점으로 두고 절대 금지선만 반복했습니다.

4. 최초 웹 추출 경로가 실패했습니다

참고 글을 읽는 첫 추출 경로에서 upstream 오류가 발생했습니다. 실패를 숨기거나 글 내용을 추정하지 않았습니다.

수정: 같은 공개 페이지를 대화형 브라우저로 다시 읽고 제목과 본문을 확인했습니다. 이 Repair는 최초 실행 영수증에 남겼습니다.

Before / After

시간 절감이나 장기적인 파일 감소 효과는 아직 측정하지 않았습니다. 이번 사례가 증명한 것은 기존 payload의 관찰 표면을 바꾸지 않고 관리계약을 설치할 수 있었다는 점입니다.

실제로 재사용할 수 있는 운영 규칙

규칙 1 — 폴더를 먼저 정리하지 말고 역할을 먼저 정합니다

경로는 현재 위치를 보여줄 뿐 source·canonical·backup·publication 역할을 자동으로 결정하지 않습니다.

규칙 2 — 도착·관찰·인계·정리를 서로 다른 권한으로 나눕니다

파일 도착은 관찰을 시작할 수 있지만 이동이나 삭제를 허가하지 않습니다.

규칙 3 — 패키지 경계를 모르면 그대로 둡니다

저장소, 앱 상태, manifest와 상대 링크가 있을 수 있는 디렉터리는 시각적 정돈을 위해 해체하지 않습니다.

규칙 4 — 인계는 영수증으로 증명합니다

source·destination·bytes·SHA-256·역할·충돌·rollback을 남기지 못하면 인계 완료라고 하지 않습니다.

규칙 5 — 정책과 enforcement를 다른 표로 씁니다

규칙 파일, watcher, scheduler, 자동 이동, 삭제, 외부 게시와 실시간 registry 바인딩을 각각 별도 상태로 기록합니다.

규칙 6 — 실패를 지우지 말고 최소 단계만 Repair합니다

추출 실패, 검사 실패나 충돌이 있으면 원기록을 남기고 깨진 최소 단계만 수리한 뒤 같은 Gate를 다시 실행합니다.

재사용 가능한 프롬프트

[대상 Downloads 또는 유입 폴더]를 자동 정리하지 말고 먼저 비파괴형 유입 관문으로 진단해 주세요.
기존 항목을 이동·개명·복사·격리·삭제하지 않은 상태에서 패키지·저장소 경계와 적용되는 AGENTS.md를 확인해 주세요.
Goal / Trigger / Context / Tree·Route / Criteria / Approval / Repair 계약을 만들고, 상세 규칙과 얇은 에이전트 발견 진입점을 분리해 주세요.
쓰기 전에 새 제어 파일을 제외할 전후 inventory 기준을 고정하고, 기존 항목의 경로·종류·크기·mtime_ns·device·inode fingerprint와 논리 파일 용량을 비교해 주세요.
정책과 실제 watcher·scheduler·자동 이동·삭제·외부 게시 상태를 분리하고, Trace / Proof / Verdict / Repair 실행 영수증으로 결과를 남겨 주세요.
같은 SHA-256은 같은 bytes일 뿐 같은 역할이나 삭제 허가가 아님을 명시해 주세요.

검증 영수증

• 참고 글 확인 — PASS
  공개 원문의 정확한 제목과 본문을 브라우저에서 확인했습니다. 최초 추출 실패와 대체 경로를 Repair로 보존했습니다.

• 기존 표면 inventory — PASS
  기존 4,724개 항목, 파일 4,515개, 디렉터리 209개, 논리 파일 용량 1,800,694,837바이트를 관찰했습니다. stat 오류는 0건이었습니다.

• 제어면 설치 — PASS
  상세 관리규칙과 얇은 AGENTS.md 진입점 두 파일을 생성하고 bytes·SHA-256으로 read-back했습니다.

• 계약 검사 — 25/25 PASS
  유입 관문 성격, 생명주기, 역할, 패키지 보호, 승인 경계, 영수증, 완료 Gate와 현재 집행 상태를 검사했습니다.

• 비파괴 rollout — PASS
  제어 파일 두 개를 일관되게 제외한 기존 항목의 전후 metadata fingerprint와 구성·논리 용량이 일치했습니다.

• 전체 payload byte hash — NOT RUN
  모든 기존 파일을 전체 해시하지 않았습니다. metadata 표면 불변 이상으로 과장하지 않습니다.

• 이동·복사·개명·격리·삭제 — NOT RUN
  기존 payload에 대한 해당 작업은 수행하지 않았습니다.

• watcher·scheduler·실시간 registry 바인딩 — NOT RUN
  절차 계약만 활성화했습니다.

• 시간 절감·검색 성공률·실제 공간 회수 — NOT MEASURED
  효과 수치를 만들거나 추정하지 않았습니다.

📚 도움받은 글

• 인박스 정리를 하네스 계약으로 만들고, 실행 영수증까지 발행했다

원 글에서 가져온 것은 Goal / Trigger / Context / Tree·Route / Criteria / Approval / Repair 계약과 Trace / Proof / Verdict / Repair 영수증 구조입니다. 원 글의 PDF 분류 결과를 이번 사례의 결과로 옮겨 쓰지 않았습니다. 이번 사례의 수치와 Verdict는 별도의 Downloads 실행 영수증에서만 가져왔습니다.

발행 경계

• 이 글과 데이터 파생 증거 카드 3장만 local Library 발행 대상으로 삼습니다.

• 실제 파일명·상대경로 목록·로컬 절대경로·내부 실행 영수증은 공개 본문과 카드에 넣지 않았습니다.

• 카드 3장은 정제된 실행 증거 JSON에서 결정적으로 생성했으며 live UI screenshot이 아닙니다.

• 관리 계약은 활성화했지만 자동 정리 시스템은 가동하지 않았습니다.

• 외부 웹·커뮤니티·이메일 재게시는 수행하지 않았습니다.

• 상시 관찰이나 자동 후보 보고를 추가하려면 읽기 전용 canary, 오탐·미탐 검증, 중지 절차와 별도 승인이 필요합니다.

이번 적용에서 가장 중요한 결과는 폴더가 깨끗해진 것이 아닙니다. 정리를 시작하기 전에 무엇을 관찰하고, 어디까지 처리하며, 무엇은 승인 없이는 하지 않고, 완료를 어떤 증거로 판정할지 계약했다는 것입니다.