fix(slot,docs): 리뷰 지적 5건 정정 — 언마운트/파괴 모순, 계약 개수 모순, 해제 순서 역전

다른 에이전트 리뷰가 짚은 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>

.claude/base/bind-system-plan.md

@@ -2669,9 +2669,15 @@ State/스트림)를 다뤘던 이전 시도가 있어 조사함 — **확인된
 
 ## 확정된 것 (더 이상 열린 질문 아님)
 
-- **핸들러 계약**: `isHandlable(inst,k,v)` + `priority` + `process`(구
-  `bind`) + `retract`(구 `cleanup`) 4종 조합으로 확정 — tbox식 6-hook 세분화는 지금은
+- **핸들러 계약**: `isHandlable(inst,k,v)` + `priority` +
+  `process(inst,k,v,index)` **3종**으로 확정 — tbox식 6-hook 세분화는 지금은
   안 함. 실제 구현하며 부족한 지점이 보이면 그때 hook 추가(점진적 확장).
+  **[정정, 2026-08-13 다섯 번째 세션 — 이 항목이 갱신에서 누락돼 문서 상단
+  "핸들러 계약" 절과 모순돼 있던 걸 같은 날 리뷰에서 발견]** 예전엔
+  `process`(구 `bind`) + `retract`(구 `cleanup`) 4종이었으나, `retract`가
+  별도 필드에서 **`process`의 반환값(retractor 클로저)** 으로 합쳐짐 —
+  이름과 개념은 그대로 유효하고 자리만 옮겨온 것(위 "핸들러 계약" 절이
+  정본).
 - **Signal 클래스**: 안 만듦, 콜백 + `Connected` 계산 속성만(`base/
   lifecycle-pattern.md`).
 - **Ref**: 도입 확정(위 절 참고), 용도는 "id 기반 조회 대체"가 아니라 "외부

.claude/base/slot-plan.md

@@ -340,13 +340,27 @@ function SlotHandler.process(inst, k, slotValue, index)
     -- no-op을 심어두면 그 다음 진짜 교체 때 이전 서브트리를 정리할 주체가 사라짐.
     return function(hintValue)
         if slotValue == hintValue then return end  -- 같은 Slot 재발행 → no-op
-        destroySlotTree(slotValue)  -- 재귀 파괴(자식 정리), 폐기·옮기지 않음 — slot 자신의 GC 앵커는 안 건드림(top-level 전용)
-        unbindLifetime(inst, slotValue)  -- top-level 자신의 GC 앵커 해제 — attachSlot의 top-level bindLifetime과 짝
-        releaseOwner(slotValue, inst)
+        -- [정정, 2026-08-13 감사 후속] 파괴가 아니라 **언마운트** —
+        -- 아래 "`State<Slot>` 교체는 파괴가 아니라 언마운트" 절이 확정한
+        -- 결정이 적용돼야 하는 자리가 바로 여기(최상위 dispatch 경로).
+        -- 예전엔 destroySlotTree를 불러 그 결정과 정면으로 모순됐음.
+        unmountSlotTree(slotValue)
+        -- 이 위치가 더 이상 기여하지 않음을 owner에게 알림 — **순서 고정**
+        -- (setLength가 끝에서 recompute를 돌리므로 offsetSource를 먼저 비워야
+        -- 죽는 중인 Source에 헛된 :Set()이 안 감, 아래 ⚠️ 절 참고)
+        Dispatch.setOffsetSource(inst, k, None)
+        Dispatch.setLength(inst, k, 0)
+        unbindLifetime(inst, slotValue)  -- top-level 자신의 GC 앵커 해제 — SlotHandler.process의 bindLifetime과 짝
+        releaseOwner(slotValue, inst)    -- 이제 이 Slot은 아무에게도 안 묶임(다른 곳에 다시 넣을 수 있음)
     end
 end
 ```
 
+**언마운트된 Slot은 그대로 재사용 가능** — `_elements`와 그 안의 소유권이
+전부 보존되므로(아래 `unmountSlotTree` 참고), `slot`을 들고 있던 코드가
+다른 곳에 다시 넣으면 `attachSlot`이 새 물리 부모로 다시 flush함. 아무도
+안 들고 있으면 그냥 GC. 지금 확실히 죽이려면 `dispose`(아래 절).
+
 **[전면 정정, 2026-08-13 감사] `claimOwner`를 nested/top-level 두 함수로
 쪼개고, top-level은 `(inst, k)`까지 본다.** 원래는 하나의 `claimOwner`가
 "같은 ownerKey면 `false` 반환(no-op)"을 양쪽에 공유했는데, 그 분기가
@@ -1390,6 +1404,32 @@ Slot=그 `.Length`)이 됨. plain 요소만 있는 흔한 경우엔 항상 합==
 대해서만 한 번 돎:**
 
 ```lua
+-- [신설, 2026-08-13 감사 후속] 비파괴 언마운트 — `State<Slot>` 교체/`Extract`
+-- 계열이 쓰는 경로. `destroySlotTree`와 **딱 하나만 다름: 실제로 안 죽인다.**
+-- 물리 트리에서만 떼어내고 `_elements`/자식 소유권은 통째로 보존하므로,
+-- 같은 Slot을 나중에 다른 곳에 다시 마운트할 수 있음(= 포탈).
+local function unmountSlotTree(slot)
+    for i, element in ipairs(slot._elements) do
+        if isSlot(element) then
+            unmountSlotTree(element)   -- 재귀 — 중첩 Slot도 똑같이 비파괴
+        else
+            element.Parent = nil       -- Destroy 아님(quad-roblox 글루가 수행)
+        end
+        -- releaseOwner를 **안 부름** — 자식들은 여전히 이 slot의 소유. 이게
+        -- destroySlotTree와의 핵심 차이(파괴는 소유권까지 반납, 언마운트는 유지).
+    end
+    local bk = getBookkeeping(slot)
+    if bk then
+        for i, observer in pairs(bk.observers) do
+            unbindLifetime(slot._mountedInst, observer)   -- 물리 target에 걸린 배관만 해제
+        end
+    end
+    slot._mounted, slot._mountedInst = false, nil
+    slot.Offset = nil   -- 마운트 전 상태로 복원(위 "`Slot.Offset`은 마운트 전엔 nil")
+    -- slot 자신의 unbindLifetime / releaseOwner / owner쪽 setLength·setOffsetSource는
+    -- 호출부 몫 — destroySlotTree와 동일한 층위 분리.
+end
+
 local function destroySlotTree(slot)
     for i, element in ipairs(slot._elements) do
         -- [정정, 2026-08-13 감사] 소유권 반납을 먼저 — 아래 "소유권 반납은
@@ -1696,11 +1736,28 @@ Slot이 마운트될 때 **자기 하위 요소들까지 `bindLifetime`으로
 
 #### 구현상 바뀌어야 하는 것
 
-`reconcile`이 교체/소멸 시 `rawRemove`(파괴) 대신 **비파괴 경로**를 타야
-하고, 그 경로는 `destroySlotTree`가 지금 하는 일 중 **파괴만 빼고 나머지는
-그대로 해야 함**(자식 observer `unbindLifetime`, 옛 owner에 등록해둔
-`Dispatch.setLength`/`setOffsetSource` 해제, `_mounted`/`_mountedInst`
-복원, `releaseOwner`).
+**[반영 완료, 2026-08-13 감사 후속]** 비파괴 경로를 `unmountSlotTree`로
+신설하고(아래 "파괴" 절), 이걸 쓰는 자리를 둘로 못박음:
+
+1. **`SlotHandler.process`가 반환하는 클로저**(최상위 dispatch 경로) —
+   **이 결정이 적용돼야 하는 바로 그 자리인데 처음엔 빠뜨려서
+   `destroySlotTree`를 계속 부르고 있었음**(다른 에이전트 리뷰가 지적,
+   그대로 뒀으면 언마운트 결정 자체가 무의미해질 뻔함). 지금은 위 절의
+   코드가 `unmountSlotTree` + `setOffsetSource(None)`/`setLength(0)` +
+   `unbindLifetime` + `releaseOwner`를 부름.
+2. **`:List`의 `reconcile`** — 교체/소멸 시 `rawRemove`(파괴) 대신 같은
+   비파괴 경로. 데이터에서 빠진 아이템도 파괴되지 않고 언마운트만 되며,
+   아무도 안 들고 있으면 GC(quad 전역의 GC-native 원칙 그대로).
+
+**여전히 파괴인 것**: 명시적 CRUD `Slot:Remove(index)`/`Slot:Clear()`
+(CRUD 표가 "제거 **+ 파괴**"로 이미 정의)와 `dispose`. 즉 **"자동 경로는
+언마운트, 명시적으로 지우라고 한 것만 파괴"**로 갈림 — `Ref`/`Attribute`의
+"지울 거면 명시적으로" 철학과 정확히 같은 결.
+
+`unmountSlotTree`는 `destroySlotTree`가 하는 일 중 **실제 파괴와 자식
+소유권 반납만 빼고 나머지는 그대로 함**(자식 observer `unbindLifetime`,
+`_mounted`/`_mountedInst` 복원, `slot.Offset = nil`). 옛 owner에 등록해둔
+`Dispatch.setLength`/`setOffsetSource` 해제는 호출부 몫(아래).
 
 **[정정, 사용자 지적] "해제 짝"이라는 새 API는 필요 없음** — 옛 owner에
 대해 그냥 **`Dispatch.setOffsetSource(ownerKey, position, None)` +

.claude/question.md

@@ -45,6 +45,20 @@ API 전부에 걸리며, 2026-08-07 일곱 번째 세션(커링 스타일 확정
 
 **M0 착수 전에 정하는 게 맞음** — 2번을 고르면 base 문서 다수가 영향받음.
 
+**[사용자 방향, 2026-08-13]** 순환 타입을 만드는 것보다 **`State` 타입
+자체를 구울 때(코드 생성 시점) 인라이닝**해주는 쪽이 맞아 보인다는 의견 —
+즉 `State<T>`가 자기 자신을 재귀 참조하는 선언을 피하고, 타입 생성기가
+각 `T`에 대해 평탄한 타입을 뽑아주는 방향(`Modifier`의 클래스별 flat 타입을
+생성기로 뽑는 이미 확정된 패턴과 같은 결). 이러면 `08`에서 걸린
+`Recursive type being used with different parameters` 제약도 같이 비켜감.
+**다만 이건 사람이 직접 확인해야 할 부분으로 사용자가 보류** — 0-Z(Attribute)와
+함께 사용자가 직접 스케치하며 판단할 목록.
+
+**관련 실측 근거**: `08`(재귀 타입 제약), `15`(read-only/read-write `Get`
+불일치 — 파싱 실패로 검증불가 상태라 재작성 필요), `14`(Ref 생성자 오버로드가
+정상 nilable 사용례까지 막음), `16`(`type function` API 불일치). 전부
+`audit/luau-test-first-run-2026-08-13.md`.
+
 ### 0-Z. ⭐ **최우선 — Attribute 이름 소유권을 무엇으로 판정할 것인가** (2026-08-13 여섯 번째 세션, 사용자가 다음 세션 심층 분석으로 이관)
 
 **이게 지금 유일하게 `base/` 반영을 막고 있는 결정.** 아래 0-A의
@@ -157,9 +171,13 @@ Slot이 됨. 막는 게 소유권 규칙이 아니라 "제거 = 파괴"라는 re
 판단이라, 포탈은 별도 기능이 아니라 그 결정의 귀결. 안 지운 Slot은
 아무도 안 들고 있으면 GC되고, 지금 죽이려면 `dispose`(위 0-B).
 **[해소, 사용자 지적] "해제 짝"이라는 새 API는 필요 없음** — 옛 owner에
-대해 그냥 `setLength(ownerKey, position, 0)` + `setOffsetSource(ownerKey,
-position, None)`을 다시 부르면 됨(이미 확정된 "마운트 안 하는 위치는
-`0`/`None` 등록" 관용구 그대로). 즉 **해제 = 0/`None`으로 재등록**.
+대해 그냥 `setOffsetSource(ownerKey, position, None)` **다음에**
+`setLength(ownerKey, position, 0)`을 부르면 됨(이미 확정된 "마운트 안 하는
+위치는 `0`/`None` 등록" 관용구 그대로). 즉 **해제 = `None`/0으로 재등록**.
+**순서가 중요** — `setLength`가 끝에서 `recompute`를 돌리므로 먼저 부르면
+아직 남아있는 옛 `Source`(죽는 중인 서브트리의 것)에 헛된 `:Set()`이 날아감
+(`base/slot-plan.md`의 ⚠️ 절). 이 줄이 한때 순서를 거꾸로 적어놔서 같은 날
+리뷰에서 지적됨.
 `state<state<Frame>>`류로 offset이 밀리는 문제는 `state<state<Tag>>`와
 같은 범주로 **"그냥 확인된 것"으로 수용**(평탄화 도구가 처리, 케이스 드묾).
 상세는 `base/slot-plan.md` "`State<Slot>` 교체는 파괴가 아니라 언마운트" 절.

CLAUDE.md

@@ -121,6 +121,9 @@ modifier/Ref의 컴포넌트 경계 통과 방식) 논의도 2026-08-04 세션
    `Effect`/`Observer`/`Animate`/`Operator` 등 같은 계약을 공유하는 API
    전부에 걸림 — 선택지는 (1) 계약 유지 + 파라미터 주석 필수, (2) raw 값
    전환(**구조 변경 규모 큼**), (3) 혼합. **M0 착수 전에 정할 것.**
+   사용자 방향: 순환 타입을 만들기보다 **`State` 타입을 구울 때 인라이닝**
+   하는 쪽(생성기가 `T`별 평탄 타입을 뽑는, `Modifier` flat 타입과 같은 결)
+   — 다만 사람이 직접 확인할 부분이라 0-Z와 함께 사용자 판단 대기.
 
    **0-Z: Attribute 이름 소유권 결정.**
    2026-08-13 여섯 번째 세션에 `Dispatch` 재디스패치 모델이 "하강 diff"로
@@ -885,66 +888,18 @@ handoff용 저장이 불필요해짐 — `Relate`는 여러 위치/사이클을
 `modifier-plan.md` 전부 반영, `archive/checkpoint-handler-pattern-reversed.md`
 신설.
 
-**2026-08-13 여섯 번째 세션 — c33ae04 커밋 전체 감사(버그 4건), Slot
-언마운트 전환, 재디스패치 모델 재설계**
-(`session/2026-08-13-06-commit-audit-dispatch-redesign-bugs.md`)
-사용자 지시로 직전 커밋을 메인 컨텍스트에서 직접 정독 — 인덱스 재설계
-**방향은 옳지만 새로 쓴 의사코드가 손 트레이싱을 안 거친 채 커밋**됐음이
-드러나 실제 버그 4건 발견·수정: (1) `Dispatch.process`의 `chains:SetStrong`이
-`h.process` 뒤에 있어 최초 마운트에서 하위 retractor가 통째로 유실,
-(2) Attribute 그룹이 `process`에서 `retractFrom`을 선행 호출해 점유
-체크(=소유권 충돌 감지)가 전혀 작동 안 함, (3) `SlotHandler`가 claim
-실패에도 파괴적 클로저를 반환해 `Frame{slot,slot}`에서 이중 파괴,
-(4) `Ref` retractor가 spurious 재발행에서도 `relate`를 지워 dedup 무력화.
-Slot 소유권은 nested=엄격 `claimOwner`/top-level=`claimOwnerAt(inst,k)`로
-분리하고 `rawRemove`의 `releaseOwner` 누락·`destroySlotTree`의 GC 타이밍
-의존 오류도 수정. `ROADMAP.md`가 2026-08-08 이전 모델로 남아있던 것, base
-내 "3종 vs 4종 계약" 모순, `luau-test/04`가 없어진 가드를 검증하던 것도
-정리(`04`는 인덱스 모델 + 버그 (1) 재현 음성 대조군으로 재작성).
-재발 방지로 `bind-system-plan.md`에 "Handler 작성 체크리스트"(7항목),
-`relate-plan.md`에 "언제 `Relate`를 쓰고 언제 쓰면 안 되는가" 신설.
-
-**이어진 사용자 설계 결정(같은 세션, 최종 상태만)**:
-- **`State<Slot>` 교체 = 파괴가 아니라 언마운트**(`state<Frame>`와 동일,
-  비파괴 추출은 `Splice`로 이미 지원) — **포탈이 별도 기능이 아니라 이
-  결정의 귀결이 됨**. 해제는 `setOffsetSource(None)` → `setLength(0)`
-  **순서 고정**(반대면 죽는 중인 서브트리의 offset `Source`에 헛된 `:Set()`이
-  날아감) + `recompute`의 `nil` 관대 처리/`slot.Offset = nil` 방어.
-  별도 unregister API는 불필요. `base/slot-plan.md`에 **확정 반영 완료**.
-- **`dispose(value)` 신설** — "트리가 아직 살아있길 요구하면 파괴를 거부하고
-  error"(엔진은 조용히 넘어가지만 quad 자료구조가 깨지므로). 시그니처/범위는
-  `question.md` 0-B.
-- **재디스패치를 "하강 diff"로 재설계** — 래핑 핸들러의 `retractFrom` 선행
-  호출을 폐기하고 `Dispatch.process`가 **핸들러를 먼저 비교**(같으면 그 자리
-  클로저에 새 값 넘기고 자기 process 재호출, 다르면 아래 전량 철거). 계기는
-  힌트가 `None`/래퍼로 오염돼 깜빡임 방지가 조용히 꺼지는 결함(사용자 제기).
-  이 모델이면 **힌트 타입이 구조적으로 보장되고 깊은 체인 힌트 유실까지
-  사라짐**. 내가 낸 반론("StoreBind 구독 갈아타기")과 보완안(`oldValue` 전달)은
-  둘 다 사용자 지적으로 철회 — 클로저가 이미 old를 캡처하고 있음.
-  **아직 `research/dispatch-redispatch-diff-plan.md`에만 있음, base 미반영.**
-- **평탄화**(`state:Flatten()`)는 백로그 상세화만 — 반환 노드의 **동적
-  의존성**이 최대 쟁점(`research/operator-sugar-plan.md`).
-- **남은 결정 하나: Attribute 이름 소유권** — 새 모델에선 양쪽 다
-  `StoreBind`라 "같은 핸들러"로 판정돼 조용히 갈아탐. 사용자가 "이전
-  결정(claimant `Relate`)을 다시 가져오는 게 맞아 보이나 다음 세션에 직접
-  스케치하며 심층 분석"으로 이관 — `question.md` **0-Z(최우선)**.
-
-**이어진 첫 실측 라운드(같은 세션)** — `luau`/`luau-analyze` 바이너리가
-사용 가능해져 **스파이크를 만들기 시작한 2026-08-09 이래 처음으로 실제로
-돌림**(CLAUDE.md가 "M0 착수 전 남은 유일한 게이트"로 꼽아온 항목). 결과
-전문은 `audit/luau-test-first-run-2026-08-13.md`.
-- **런타임 12개 전원 통과**(01~07/11/17~20). **`04`가 이번 세션 감사의
-  버그를 음성 대조군으로 재현** — 체인 깊이가 3 대신 1로 무너지고 죽은
-  store가 나중에 UI를 덮어쓰는 것까지 실측돼 감사→수정 사이클이 닫힘.
-  **`07`은 보강해야 실제 검증이 됐음**(연쇄 GC 미검증 상태였고, 파일이
-  스스로 적어둔 "weak 엔트리를 셀 방법 없음" 전제가 틀렸음) — GC-native
-  아키텍처의 핵심 전제가 이걸로 실측 확정. **`18`이 `Relate` 상호 순환
-  경고를 실증**(추측이 아니라 실제로 GC 안 됨).
-- **타입 쪽에서 진짜 이슈 하나 발견 → `question.md` 0-Y 신설**(위 참고).
-- `modifier-plan.md`의 "데이터를 테이블에 직접 두고"가 두 갈래로 읽히는
-  **문서 결함**이 드러남 — self 최상위 리터럴 키에 두면 `__index`가
-  `rawget` 성공 시 안 불려 같은 필드 재호출이 죽음(문서 3·4절 대표 용례가
-  바로 그 패턴). 경고 문단 추가 + `17` 재작성으로 해소.
-- 스파이크 결함 수정: `17`(크래시), `11`(엉뚱한 이유로 통과), `19` B/C
-  (폐기 설계 검증 → 현행 설계로 재작성, 음성 대조군 포함), `07`(보강).
-  남은 것은 `13`/`15`/`16`의 스파이크 격리·API 재확인(설계 문제 아님).
+**2026-08-13 여섯 번째 세션 — c33ae04 감사(버그 4건), Slot 언마운트 전환,
+재디스패치 재설계안, 첫 실측 라운드**
+(`session/2026-08-13-06-commit-audit-dispatch-redesign-bugs.md`,
+실측 결과는 `audit/luau-test-first-run-2026-08-13.md`)
+직전 커밋을 직접 정독해 인덱스 재설계 의사코드의 실제 버그 4건 발견·수정
+(`chains:SetStrong` 순서로 하위 retractor 유실, Attribute 그룹의 점유 체크
+무력화, `SlotHandler`의 claim 실패 시 이중 파괴, `Ref` dedup 무력화).
+이어 사용자 결정으로 **`State<Slot>` 교체를 파괴→언마운트로 전환**(포탈이
+그 귀결이 됨), **`dispose(value)`**(트리가 요구하면 파괴 거부·error) 신설,
+**재디스패치를 "하강 diff"로 재설계**(`research/dispatch-redispatch-diff-plan.md`,
+**base 미반영 — `question.md` 0-Z 하나 남음**). `ROADMAP.md`/base 계약 개수
+모순/`luau-test` stale도 정리. 마지막으로 `luau` 바이너리가 생겨 **첫 실측**
+— 런타임 12개 전원 통과, `04`가 위 버그를 음성 대조군으로 재현, `07` 보강으로
+GC-native 전제 확정, `18`이 `Relate` 순환 경고 실증. 타입에선 `:Compute(fn)`
+lazy 핸들 계약이 Luau 추론과 충돌하는 게 드러나 `question.md` **0-Y** 신설.

ROADMAP.md

@@ -252,6 +252,38 @@ Luau 코드로 부딪혀본 적 없는 세 가지**를 던지는 코드로 검
 
 ## M6 — Slot
 
+- [ ] **[2026-08-13 여섯 번째 세션 — 이 세션의 Slot 결정 전부, 구현 전 필독]**
+      - **`State<Slot>` 교체 = 파괴가 아니라 언마운트**(`state<Frame>`와 동일).
+        비파괴 경로 `unmountSlotTree`를 `destroySlotTree`와 별도로 구현 —
+        차이는 딱 둘: 실제 `Destroy()`를 안 하고, 자식 `releaseOwner`도 안 함
+        (자식은 계속 그 slot 소유라 통째로 재마운트 가능 = 포탈).
+        **쓰는 자리 둘**: `SlotHandler.process`가 반환하는 클로저, `:List`의
+        `reconcile`. **여전히 파괴인 것**: 명시적 `Remove`/`Clear`/`dispose`.
+      - **해제 시 owner 등록 되돌리는 순서 고정** —
+        `setOffsetSource(inst,k,None)` **먼저**, `setLength(inst,k,0)` **나중**.
+        반대로 하면 `setLength` 안의 `recompute`가 죽는 중인 서브트리의 offset
+        `Source`에 헛된 `:Set()`을 날림. `recompute`는 `sourceList[i]`가 `nil`
+        이어도 `None`처럼 skip(방어), 해제 시 `slot.Offset = nil`.
+      - **소유권 판정을 둘로 분리** — nested(`rawAdd`)는 엄격 `claimOwner`
+        (같은 owner 재클레임도 error, `Slot{a,a}` 차단, 반환값 없음),
+        top-level은 `claimOwnerAt(element, inst, k)`(정확히 같은 `(inst,k)`의
+        spurious 재발행만 `false`, `Frame{slot,slot}`은 error).
+        `releaseOwner`는 불일치 시 즉시 error.
+      - **`rawRemove`가 `releaseOwner`를 부를 것**(옛 의사코드에서 누락돼 있었음),
+        **`destroySlotTree`가 자식 소유권 반납 + `_mounted`/`_mountedInst` 복원**
+        (GC에 맡기면 재사용이 GC 타이밍 의존으로 비결정적 실패).
+      - **`SlotHandler.process`는 claim 실패 시에도 파괴적 클로저를 반환해야 함**
+        — no-op을 반환하면 다음 진짜 교체 때 정리 주체가 사라짐(`retractFrom`은
+        클로저가 early-return해도 체인에서 항상 소비하므로).
+      - 전부 `base/slot-plan.md`에 반영돼 있고, `luau-test/19` C 섹션이
+        소유권 분기를 음성 대조군까지 포함해 실측 검증함.
+- [ ] **`dispose(value)`** — 대상이 아직 어느 트리에 의해 살아있길 요구되면
+      **파괴를 거부하고 즉시 error**(떼어내주지 않음 — 떼는 건 `Set`=언마운트의
+      몫). 엔진은 `Destroy`/`Clear`에 에러를 안 내지만 quad 자료구조가 깨지므로,
+      quad가 관리 중인 값을 안전하게 지우는 유일한 경로. 마운트 위치는
+      `elementOwner`가 이미 알고 있어 새 부기 불필요. 시그니처/대상 범위는
+      `.claude/question.md` 0-B에서 미확정
+
 - [x] **"여러 Slot이 형제로 섞일 때 순서 보장" 해소**(2026-08-09 여섯 번째
       세션) — `Dispatch.setLength`/`setOffsetSource` 메커니즘, `base/
       bind-system-plan.md` "Length/Offset" 절. `Slot.Length: State<number>`도