qwreey
3721692ed4
사용자 결정으로 .claude/agent-memory/(감사 에이전트의 영속 메모리)를 커밋해 추적하기로 함. 논거: 개발 환경이 다수라 메모리가 레포를 따라다녀야 하고, 실 기록이지 빌드 디펜던시가 아니며, 환경 노출 위험은 SAFETY.md의 파이프라인 (컨테이너 개발 → 프라이빗 git → 검토 후 머징)의 마지막 사람 감사가 방어선. 커밋 전 처리: - 절대경로/이메일/키/토큰 패턴 스캔 — 노출 소지 없음(히트는 전부 frontmatter name: 과 마크다운 링크) - project_agent_prompt_caching_bug_reproduced.md가 아직 "캐시 가설"로 서술돼 있어 커밋된 HEAD 모델로 다시 씀(같은 정정으로 memory: project → Write/Edit 진단이 지지됨을 반영), MEMORY.md 색인 줄도 갱신 README.md의 agent-memory/ 행에 결정과 사용자 논거를 기록 — 추적하는 쪽으로 정해졌으므로 이 폴더 내용도 감사 대상임을 명시. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.1 KiB
| name | description | metadata | ||
|---|---|---|---|---|
| feedback-self-referential-counts | 문서가 자기 자신의 줄 수/개수를 본문에 하드코딩하면 그 문서를 쓴 커밋 시점부터 이미 틀려 있는 경우가 실제로 반복됨 — 감사 시 최우선으로 확인할 것 |
|
quad .claude/ 코퍼스에서 어떤 문서가 자기 자신의 줄 수나 자기 자신이
포함된 색인의 항목 개수를 본문에 숫자로 적어두면(예: "CLAUDE.md는
39줄짜리 진입점", "session-summary.md는 1231줄", "세션별 요약 91개"),
이런 숫자는 그 문서를 커밋한 바로 그 시점부터 이미 틀려 있는 경우가
실제로 확인됨(2026-08-16 CLAUDE.md 4분할 커밋 8aeec76에서: 커밋 당시
CLAUDE.md 실제 43줄인데 "39줄"이라 적고, session-summary.md 실제 1276줄인데
"1231줄"이라 적고, session/ 실제 92개인데 "91개"라 적음 — 전부 3곳 이상에
중복 서술돼 있었음).
Why: 이런 숫자를 계산하는 시점(사람이 헤더 문구를 쓰는 시점)과 그
숫자가 설명하는 파일이 최종 커밋되는 시점 사이에 다른 편집(체크리스트
항목 추가, 배너 삽입 등)이 끼어들기 쉬움 — 자기 자신을 설명하는 숫자는
구조적으로 닭-달걀 문제라 사람이 아무리 조심해도 어긋난다.
conventions.md의 "개수·목록·상태는 소스 하나만" 원칙이 일반적으로는
"여러 문서에 같은 값을 반복 적지 말 것"을 말하지만, 이 변형(자기 자신을
설명하는 숫자)은 그 원칙조차 지켜도(값이 파일들 사이에 일치해도) 실제
파일 상태와는 다를 수 있다는 게 요점 — 일치 여부가 아니라 애초에
하드코딩하지 말아야 함.
How to apply: 감사 라운드에서 "이 문서가 N줄이다"/"이 폴더에 N개
있다" 류 서술을 보면, wc -l/ls | wc -l 등으로 실측 대조를 최우선
순위로 돌릴 것 — doc-check.py는 이 클래스를 못 잡음(정규식이 숫자
드리프트를 모름). 발견 시 fix 제안은 "숫자를 최신값으로 갱신"이 아니라
**"숫자 자체를 서술에서 빼고 정성적 표현으로 대체"**할 것 — 갱신은
다음 편집에서 또 깨짐(같은 실수의 재발), 삭제만이 구조적으로 안전.
변형(2026-08-16 재확인): 자기 자신이 아니라 다른(계속 자라는)
폴더를 가리키는 카운트도 같은 클래스임 — 예:
audit/luau-test-first-run-2026-08-13.md가 "재실측 전문(스파이크 44개):
audit/type-recursion-issue/"라고 적어둔 것. 같은 라운드에 다른 5곳
(typing-limits.md/README.md/STATUS.md/REPORT.md 자기 자신 등)에서
이 "44개"를 정확히 이 이유로 지웠는데 이 파일 하나만 놓쳤고, 실제 폴더는
그새 48개로 자라 있었음(ls spikes/ | wc -l로 확인). 감사 시 절차:
같은 라운드 diff에서 특정 하드코드 숫자를 여러 곳에서 지운 패턴을 보면,
그 숫자 문자열로 코퍼스 전체를 다시 grep해서 빠진 인스턴스가 없는지
확인할 것(archive/에 남은 동일 숫자는 스코프 밖이니 제외).