사용자 지적: 2989줄이라 검토가 불가능하고 한 곳의 실수가 미치는 범위가 너무 큼. 특히 "이벤트 연결은 다른 base 문서가 되어야 할 듯"이라고 직접 지목. **1단계 (완료, 2989 → 2263줄)** — 인바운드 참조가 적고 자기 완결적인 것부터: - base/ref-plan.md (509줄) — Ref/PreRef 전체 - base/event-plan.md (103줄) — 이벤트 self 미전달, false로 disconnect - base/brand-plan.md (137줄) — Brand 런타임 nominal 판별 내용은 **순수 이동, 결정은 하나도 안 바뀜**. 원위치엔 포인터 스텁을 남기고, 이 절들을 지목하던 인바운드 참조 20곳을 새 파일로 갱신(잔존 0 확인). README 색인에 3개 행 추가. **2단계는 의도적으로 미룸** — 남은 디스패치 코어(~1000줄)/반응형 코어 (~950줄)는 0-Z 확정 시 어차피 전면 재작성 대상이라, 재작성하는 그 패스에서 파일을 가르는 게 총 변경량과 실수 위험이 모두 작음(인바운드 ~37곳을 한 번만 고침). dispatch-redispatch-diff-plan.md 6절에 그 지시를 명시했고, bind-system-plan.md 헤더에도 분할 현황표를 남김. 부수: 이벤트 *네이밍* 관례는 인스턴스 생성과 한 절에 섞여 있어 쪼개면 양쪽이 반토막 나므로 원위치 유지(event-plan.md 헤더에 명시). luau-test/README의 "에이전트가 직접 실행 못 함" stale 서술도 정정. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6hzeUi5QdLPEk69B6cXFa
2.4 KiB
[에이전트 실수] 에이전트 실수 기록
CLAUDE.md 세션 로그 안에 흩어져 있던 "에이전트가 같은 세션 안에서 스스로
정정한 실수" 서술을 여기로 모음 — 최종 결론은 이미 각 base/ 문서에
정확히 반영돼 있어서 CLAUDE.md에 전체 문단을 남겨둘 필요는 없지만(중복),
같은 실수를 반복하지 않기 위한 기록 자체는 남겨둘 가치가 있음. 다른 archive
문서(*-reversed.md/*-rejected.md)와 달리 이건 "설계 결정의 반전"이
아니라 "에이전트가 문서를 쓰다가 실제로 개념을 혼동했던 사례" 전용.
1. canExecute와 isHandlable을 같은 개념으로 혼동 (2026-08-07 여덟 번째 세션)
실수: NoneHandler(값을 None에서 nil로 바꿔 재디스패치하는 base
내장 핸들러)를 설계하며 그 매치 조건을 canExecute로 잘못 서술함.
정정: 둘은 완전히 다른 계층 — isHandlable(k,v)는 KV 매치
predicate(핸들러가 이 키/값을 담당하는지 판단, 핸들러 계약 4종 중 하나),
canExecute(handle)는 특정 바인딩 하나가 "지금 살아있어 실행돼도
되는가"만 보는 별개의 라이프타임 게이트(base/lifecycle-pattern.md).
NoneHandler가 구현해야 하는 건 isHandlable이지 canExecute가 아님.
현재 유효한 설계: base/bind-system-plan.md의 None 센티널 절과
"매치 predicate는 isHandlable" 절이 최종 소스.
2. isSource가 불필요하다고 잘못 판단 (다섯 번째 세션 → 여덟 번째 세션에서 정정)
실수: 2026-08-07 다섯 번째 세션에서 isState/isSource predicate를
설계하며 "State면 충분한 용도만 있으니 isSource는 따로 안 만들어도
된다"고 서술. 이때 base/component-composition-plan.md 4번 절은 이미
isSource가 존재한다고 가정하고 쓰여 있었는데, 그 모순을 그때는 못
찾아냄.
정정: Source는 State보다 실제로 더 많은 능력(:Set/:Emit)을
가진 서브타입이라, "쓰기도 되는 원천인가"를 알아야 하는 코드는
isState만으론 부족함 — isSource를 별도로 제공해야 함. isState는
여전히 {State, Source} 둘 다 통과시킴(상위집합 판별 유지).
현재 유효한 설계: base/brand-plan.md의 Brand 절
(isState/isSource가 둘 다 존재, 전자는 집합 멤버십, 후자는 단순 항등)이
최종 소스.