fix(memory,P1): setup.sh가 secure_fs.py를 배포하지 않아 local-memory commit이 전 노드에서 실패

[jinon86]

증상

전 노드(12/12)에서 매 distill 실행마다 다음 에러가 발생합니다.

local-memory commit failed: [Errno 2] No such file or directory: '/root/.claude/utils/secure_fs.py'

곽가 기준 ~/.claude/state/distill.log에서 반복 확인되며, sogyo 등 다른 노드도 동일합니다.

근본 원인 — 복사 후 상대경로가 깨짐

setup.sh:373이 모듈을 복사합니다.

run cp "$SRC/bridge/memory/local_memory_transaction.py" "$CLAUDE_DIR/hooks/ccc_local_memory_transaction.py"

그런데 복사되는 local_memory_transaction.py 안에서 secure_fs를 자기 위치 기준 상대경로로 찾습니다.

# bridge/memory/local_memory_transaction.py:40
secure_fs_source = Path(__file__).resolve().parents[1] / "utils/secure_fs.py"

위치	parents[1]/utils/secure_fs.py	결과
원본 bridge/memory/	bridge/utils/secure_fs.py	✅ 존재
복사본 ~/.claude/hooks/	~/.claude/utils/secure_fs.py	❌ 없음

의존 파일(bridge/utils/secure_fs.py)을 함께 배포하지 않아 복사본에서 항상 실패합니다.

폴백 체인도 모두 막힙니다.

1. from telegram_bot.utils.secure_fs import ... — telegram_bot 패키지가 sys.path에 없어 실패
2. from ccc_secure_fs import ... — 선로드된 모듈 없어 실패
3. parents[1]/utils/secure_fs.py — 위 표대로 경로 불일치

영향 범위

• 12개 노드 전부 (~/.claude/utils/secure_fs.py 부재 확인)
• distill의 local-memory commit 단계만 실패합니다. wiki-candidates 생성과 Honcho push는 정상 동작하므로 증상이 로그에만 남고 겉으로 드러나지 않습니다.

재현

ls ~/.claude/utils/secure_fs.py            # 없음
ls ~/.claude/hooks/ccc_local_memory_transaction.py   # 있음 (setup.sh가 복사)
grep -c "local-memory commit failed" ~/.claude/state/distill.log

수정 방향 (택1)

1. 의존 파일 동반 배포 — setup.sh에서 bridge/utils/secure_fs.py → $CLAUDE_DIR/utils/secure_fs.py도 복사. 상대경로 구조를 보존하므로 코드 변경 불필요.
2. 탐색 경로 보강 — local_memory_transaction.py의 폴백에 parents[1]/"ccc_secure_fs.py" 또는 설치 레이아웃 경로를 추가.
3. 환경변수 주입 — CCC_SECURE_FS_PY 같은 명시 경로 지원.

1번이 가장 작고 기존 로딩 로직을 건드리지 않습니다.

검증 기준

수정 후 임의 노드에서 distill 1회 실행 시 distill.log에 local-memory commit failed가 남지 않아야 합니다.

---

조사 시점: 2026-08-05. distill 백로그 실사 중 발견했습니다.

[jinon86]

진단 정정 — 원인이 배포 누락이 아닙니다

이슈 본문의 근본 원인 분석이 틀렸습니다. 수정 PR을 만들면서 확인했습니다.

틀린 부분

setup.sh가 의존 파일(bridge/utils/secure_fs.py)을 함께 배포하지 않아 복사본에서 항상 실패합니다.

setup.sh:325가 이미 배포하고 있습니다.

run cp "$SRC/bridge/utils/secure_fs.py" "$CLAUDE_DIR/hooks/ccc_secure_fs.py"

제가 배포 경로(~/.claude/hooks/ccc_secure_fs.py)가 아니라 에러 메시지에 찍힌 경로(~/.claude/utils/secure_fs.py)를 기준으로 존재 여부를 확인해서 "12개 노드 전부 없음"이라고 판단했습니다. 실제로는 전 노드에 배포돼 있습니다.

실제 근본 원인

distill committer가 spec_from_file_location으로 모듈을 로드하므로 ~/.claude/hooks/가 sys.path에 올라가지 않습니다. 그래서 폴백 2단계가 무력화됩니다.

단계	코드	실제
1	from telegram_bot.utils.secure_fs	bridge editable install이 있는 노드만 성공
2	from ccc_secure_fs	hooks/가 sys.path에 없어 항상 실패
3	parents[1]/utils/secure_fs.py	설치 레이아웃에선 존재하지 않는 경로

즉 2단계가 설계 의도대로 동작하지 않고, 1단계로 우회되는 노드에서만 증상이 가려집니다.

영향 범위도 정정합니다

12개 노드 전부 / 매 distill마다 실패

실측 결과입니다.

노드	telegram_bot	마지막 실패
gwakga	가능	2026-08-01
nosuk	—	2026-08-03
gongyung	—	2026-08-03
dungae	—	2026-08-03
sogyo	불가	2026-08-05 04:05
daegyo / seoseo	—	실패 0건

08-04 harness 업데이트로 ccc_secure_fs.py가 배포되면서 대부분 노드는 증상이 멎었고, 1단계 우회가 안 되는 sogyo에서만 계속 발생합니다. "매 distill마다 전 노드"는 과장이었습니다.

수정

PR #956 — 3단계 폴백에서 형제 ccc_secure_fs.py를 먼저 탐색합니다. sogyo에서 수정 전 실패 / 수정 후 성공을 직접 확인했고, 소스 체크아웃 레이아웃 회귀 없음 + 기존 테스트 13 passed입니다.

우선순위는 P1 → P2가 적절해 보입니다. 실제 영향 노드가 1곳이고 나머지는 이미 멎은 상태입니다.