다른 에이전트 리뷰가 짚은 5건을 전부 사실 확인 후 수정.
1. (가장 심각) slot-plan.md의 SlotHandler.process 반환 클로저가 여전히
destroySlotTree를 불러, 같은 커밋에서 확정한 "State<Slot> 교체는 파괴가
아니라 언마운트" 결정과 정면 모순 — 그 결정이 적용돼야 할 최상위 dispatch
경로가 바로 이 클로저인데 "구현상 바뀌어야 하는 것" 절이 reconcile만
언급하고 빠뜨렸음. 그대로 뒀으면 언마운트 결정 자체가 무의미해질 뻔함.
→ 비파괴 경로 unmountSlotTree 신설(destroySlotTree와의 차이는 딱 둘:
실제 Destroy 안 함, 자식 releaseOwner 안 함 — 자식이 계속 그 slot
소유라 통째로 재마운트 가능 = 포탈). 클로저를 unmountSlotTree +
setOffsetSource(None) -> setLength(0) + unbindLifetime + releaseOwner로
교체. "자동 경로는 언마운트, 명시적 Remove/Clear/dispose만 파괴"로 정리.
2. bind-system-plan.md "확정된 것" 절이 폐기된 4-메소드 계약을 여전히 확정
사실로 서술 — 같은 파일 상단은 이미 3-메소드로 갱신돼 자기 문서 내 모순.
3. question.md의 Slot 해제 순서가 거꾸로 — setLength(0)을 먼저 부르라고 돼
있었는데, 같은 커밋이 slot-plan.md에 추가한 경고가 정확히 그 순서가
죽어가는 서브트리 Source에 헛된 :Set()을 날린다고 명시.
4. ROADMAP.md M6에 이번 세션 Slot 결정이 전혀 미반영(M0/M2/M4/M10엔 반영됨)
— 언마운트 전환/dispose/claimOwner vs claimOwnerAt 분리/버그 4건 추가.
5. CLAUDE.md 여섯 번째 세션 항목이 자체 규칙(2~4줄+링크) 위반, 63줄까지
불어남 — 과거 3000줄 비대화를 유발한 패턴 재발. 15줄로 압축.
6번(StoreBind가 최초 발화에서도 retractFrom을 부르는 것)은 사용자 판단으로
그대로 둠 — 빈 슬롯 retractFrom은 무시 가능하고 일관성이 낫다는 결정.
추가: question.md 0-Y에 사용자 방향 기록 — 순환 타입을 만들기보다 State 타입
자체를 구울 때 인라이닝하는 쪽(Modifier flat 타입 생성과 같은 결). 사람이
직접 확인할 부분이라 0-Z(Attribute)와 함께 사용자 판단 목록으로 이관.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
qwreey
b90b3a6b94
