memory-tidy

메모리 정리

0. 왜 필요한가

상시 규범은 계속 늘어난다 — 사용자가 계속 입력하고, 비서도 관측을 적는다. 오래 쓴 설치에서는 메모리 인덱스가 매 턴 실리는 상수 중 가장 큰 조각이 되고 캡에 닿는다 (개발 인스턴스 실측: 3주에 약 4배). ★네 설치의 값은 /status 와 아래 §1 로 직접 재라 — 이 숫자를 그대로 옮겨 적지 마라.

★캡을 내리는 건 답이 아니다. 같은 날 재보니 캡을 반으로 내리면 사람이 쓴 77건이 잘리고 그 안에 상시 행동 규칙이 있었다(style-never-auto-push-… 등). 경계도 촘촘했다 — 잘리는 것 최대 access 19 / 남는 것 최소 20.

★진짜 여유는 중복에 있다. 같은 실측에서 나온 것:

• 「답글 형식」이 3건(access 287·278·257 — 상위 3개가 전부 한 주제다)
• 「스킬화」 3건 · 「위임」 3건 · 「위키 커밋·푸시」 2건(거의 같은 문장) · 「system-reminder」 2건
• 자동 생성 feedback_growth_* 24건 5.1KB(15%) — 기계 해시 이름
• 만료된 것 — 지나간 일정·끝난 작업처럼 시효가 있는 사실이 아직 매 턴 실린다

1. 하드룰 (여기부터 읽어라)

• ★지우지 않는다. archive_memory 를 쓴다 — 인덱스에서만 내리고 검색으로는 계속 찾히며(FTS 는 아카이브 무관) 되돌릴 수 있다(restore:true). delete_memory 는 이 스킬에서 쓰지 마라.
• ★한 판은 한 호출이다. archive_memory 는 names 배열을 받는다 — 승인받은 묶음을 한 번에 넘겨라(건별로 20번 부르지 마라: 왕복도 승인도 스무 배고, 중간에 턴이 끊기면 «절반만 정리된» 상태가 남는다).
• ★자동으로 합치지 않는다. 「이건 중복이다」가 틀리면 규칙이 조용히 사라지고, 다음 사고 때야 알게 된다. 제안까지가 이 스킬의 일이고, 고르는 건 사람이다.
• ★재고 나서 말한다. "많다"·"중복이다"는 숫자를 대고 하는 말이다(§2 가 그 숫자다).
• ★★내린 것은 스스로 돌아오지 않는다 (2026-09-06 실행으로 확인, 정태님 지적). 여기엔 "사실형은 잘려도 자가 회복된다 — retrieveContext → searchMemories → bumpAccess 로 access 가 올라 인덱스로 돌아온다(실측 확인)" 고 적혀 있었는데 코드에 그 경로가 없다. bumpAccess 호출처는 getMemory 하나뿐이고, 검색은 touchSeen(=last_accessed 만) 을 부른다. 게다가 인덱스 정렬은 access_count DESC 라 last_accessed 는 순서에 영향도 없다. 실측: 아카이브한 뒤 검색으로 5번 도달해도 인덱스로 안 돌아왔다(찾히기는 한다). ★그래서 아카이브는 되돌리려면 사람이 archive_memory(restore:true) 를 불러야 한다. 이 문장이 틀린 채로 있으면 «사실형은 내려도 안전하다» 는 근거가 거짓이 되고, 정리할 때마다 사실이 조용히 사라진다.
• ★그래도 규범과 사실은 다르게 다룬다 — 규범은 애초에 여기 있으면 안 된다(add_memory 도구 설명: "여기는 «사실» 자리다 … 「항상 존댓말」·「자동 푸시 금지」는 <home>/AGENT.md"). §4 가 그걸 가려 승격시킨다. 남아 있는 규범은 병합하되 내리지 마라 — 「자동 푸시 금지」는 push 얘기가 나와야 살아나는데 그때는 이미 늦다.

2. 먼저 잰다

list_memories 도구를 쓴다. 이름·종류·설명·읽힌 횟수·인덱스 바이트 + 총량·캡을 한 번에 준다(읽기 전용, 본문 제외).

★셸로 DB 를 직접 읽지 마라. 승인 게이트에 걸려 여기서 멈춘다 — 이 스킬의 첫 판이 실제로 그렇게 멈췄고(2026-09-02), 그래서 이 도구가 생겼다. 그리고 DB 를 직접 세면 SQLite length() 가 문자 수라 한국어에서 3배 틀린다(같은 날 내가 그 착시로 «포맷이 1.70배» 라고 잘못 보고했다). 도구는 바이트로 준다.