docs(audit): 코퍼스 전반 2차 감사 — 모순/stale 8건 정정

병렬 에이전트 5개(디스패치 코어/프리미티브/research·reference·archive/
인덱스 레이어/luau-test)로 재감사, 실제 문제만 수정:

- bind-system-plan.md/store-semantics.md: :Compute/:With lazy 핸들
  계약이 Luau 추론과 충돌한다는 사실(question.md 0-Y)이 정작 그 계약을
  서술하는 두 파일엔 경고 배너 없이 "확정"으로만 남아있던 것 수정
- slot-plan.md: process(inst,k,self) 3-인자 표기 5곳(현재는 4-인자
  process(inst,k,v,index)) 정정, rawUnmount의 index-기준 시그니처와
  reconcile 호출부의 element-기준 인자 불일치 캐비엇 추가, 폐기된
  "Handler.retract" 표현 정정
- README.md: question.md 0-A 오타(실제는 0-Z) 수정
- ROADMAP.md: M7 NoneHandler 항목에 M2/M4/M10과 같은 재디스패치 모델
  교체 경고 배너 누락돼 있던 것 추가
- documentation-content-map.md: 이미 확정된 Tween 옵션 질문이 "아직
  열림"으로 남아있던 것 정정, 예시 코드가 2026-08-10 폐기된 구 Tween
  특수 bind key 모델을 쓰고 있던 것에 캐비엇 추가
- luau-test/13 헤더: "런타임은 그냥 통과함" 예상이 실측(STATUS.md)과
  반대였던 것 정정
- luau-test/STATUS.md: 15번 파일이 🔴/🟠 두 테이블에 중복 등재돼
  건수가 안 맞던 것 정리

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.claude/README.md

@@ -66,7 +66,7 @@
 | `additional-primitives-plan.md` | **[2026-08-09 세 번째 세션, 전부 해소]** 마지막으로 남아있던 키 기반 동적 컬렉션 재조정도 `Slot:List(...)`로 확정되어 `base/slot-plan.md`로 승격 — 이 문서엔 새로 열린 설계 질문 없음, "빈 자리 아닌 것"/"문서화 백로그"/조사 소스 목록만 배경 자료로 유지 | 하 — 배경 리서치 기록용, 열린 결정 없음 |
 | `pre-implementation-audit.md` | M0 착수 직전 크리티컬 감사(2026-08-06 신설) — `base/` 전체를 모호성/지연결정리스크/단순화후보 세 렌즈로 재검토, 11개 우선순위1 + 11개 우선순위2 + 2개 단순화후보. **[2026-08-12 열일곱 번째 세션]** 우선순위1 11개 전원 해소 — 남은 건 `.claude/luau-test/` 스파이크 실측 확인뿐 | 상 — 설계는 전부 해소, `.claude/luau-test/` 스파이크 실측만 남음 |
 | `operator-sugar-plan.md` | **[2026-08-12 신설]** `Sum`/`Product`/`Not`/비트연산 등 `:Compute`/`:Apply`용 연산자 콤비네이터 슈가 — 메커니즘은 이미 확정된 계약(`Animate`와 동형 패턴) 재사용이라 확정, 네임스페이스 이름만 미정. **[2026-08-12 열아홉 번째 세션]** 서브 에이전트 외부 리서치로 다른 리액티브 라이브러리 선례와 대조 — `Operator`가 가장 강한 선례(Python `operator` 모듈), `Clamp`/`Min`/`Max`가 추가 후보로 부상, 비트연산·비교연산자·`Sub`/`Div`는 선례 전무로 드랍 후보, Debounce/Throttle은 `Blocker`와 다른 시간 기반 메커니즘이라 별도 질문으로 분리, `Filtered`의 Slot 안/밖 구분 판단이 ReactiveUI/SolidJS 선례로 뒷받침됨 — 최종 이름 결정은 여전히 사용자 몫. **[2026-08-13 세션, 두 번째]** Haskell 비교 리서치 중 `Alternative`(nil 대체값, coalesce류) 후보 신설 — 카탈로그 확정 규칙에 그대로 맞음, 이전엔 없던 게 확인됨 | 하 — 구현은 맨 마지막(순수 슈가, 없어도 무방, 함수 간 의존 없음), 사용자가 직접 후순위 지정  **[2026-08-13 여섯 번째 세션]** `State<State<T>|T>` → `State<T>` 평탄화 항목 신설(백로그) — `State<State<T>>`가 정상 동작하게 됐지만 `retractFrom`의 힌트가 직속 1단계에만 가서 깊은 중첩에선 깜빡임 방지가 꺼진다는 게 구체적 동기, 사용자 판단으로 "UB는 아니지만 원치 않는 방향". `Operator.*`가 아니라 `state:Flatten()` 메소드로 제공하는 게 맞아 보이며, **반환 노드가 동적 의존성을 갖는다는 난점**(quad가 의도적으로 비지원하기로 한 바로 그것)이 확정 전 최대 쟁점 |
-| `dispatch-redispatch-diff-plan.md` | **[2026-08-13 여섯 번째 세션 신설]** 현행 `hintValue`가 "곧 디스패치될 raw 값"이라 `None` 센티널/`State`/`Tween` 래퍼가 그대로 넘어가 말단 핸들러의 `isX(hint)` 가드를 거짓으로 만들고 깜빡임/재생성 방지를 조용히 끄는 결함을 재현·확인(사용자 제기). **채택 모델**: 래핑 핸들러의 `retractFrom` 선행 호출을 폐기하고 `Dispatch.process` 안에서 **핸들러를 먼저 비교** — 같으면 그 자리 클로저에 새 값을 넘기고 자기 `process` 재호출, 다르면 그 자리부터 전량 철거. 이걸로 힌트 타입이 구조적으로 보장되고 깊은 체인의 힌트 유실도 사라짐(각 레벨이 자기 재프로세스에서 자기 힌트를 받으므로). `oldValue` 전달/`HandlerChanged` 마커는 둘 다 불필요로 판명 (클로저가 이미 old를 캡처, `chains`에 더할 건 비교용 `handler` 하나). **남은 열린 항목은 Attribute 이름 소유권 하나** — `question.md` 0-A |
+| `dispatch-redispatch-diff-plan.md` | **[2026-08-13 여섯 번째 세션 신설]** 현행 `hintValue`가 "곧 디스패치될 raw 값"이라 `None` 센티널/`State`/`Tween` 래퍼가 그대로 넘어가 말단 핸들러의 `isX(hint)` 가드를 거짓으로 만들고 깜빡임/재생성 방지를 조용히 끄는 결함을 재현·확인(사용자 제기). **채택 모델**: 래핑 핸들러의 `retractFrom` 선행 호출을 폐기하고 `Dispatch.process` 안에서 **핸들러를 먼저 비교** — 같으면 그 자리 클로저에 새 값을 넘기고 자기 `process` 재호출, 다르면 그 자리부터 전량 철거. 이걸로 힌트 타입이 구조적으로 보장되고 깊은 체인의 힌트 유실도 사라짐(각 레벨이 자기 재프로세스에서 자기 힌트를 받으므로). `oldValue` 전달/`HandlerChanged` 마커는 둘 다 불필요로 판명 (클로저가 이미 old를 캡처, `chains`에 더할 건 비교용 `handler` 하나). **남은 열린 항목은 Attribute 이름 소유권 하나** — `question.md` 0-Z |
 | `v1-compat-plan.md` | v1 하위호환(compat) 레이어 — `quad-roblox-v1-compat` 패키지, v2→v1 단방향 브리지(`state:Observer()`+v1 프로퍼티 재대입), v2-in-v1/v1-in-v2 두 임베딩 방향의 기술 규칙까지 확정. quad2-try의 `quad-compat`은 빈 폴더로 실제 시도된 적 없었음을 확인 | 하 — Slot이 foreign Instance를 어떻게 다루는지만 Slot 코어 구현 시점까지 미결 |
 
 ## `archive/` — 완료됐거나 완전히 뒤집힌 것, 능동 참고 불필요

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

@@ -2458,6 +2458,15 @@ Modifier처럼 플래튼하지 않는가"는 설계 근거를 알고 싶은 사
 
 **`:With`/`:Compute` — self 인자도 lazy 핸들로 통일**
 
+> **⚠️ [2026-08-13 첫 실측에서 발견, `question.md` 0-Y] 아래 lazy 핸들
+> 계약이 Luau 양방향 추론과 충돌함이 확인됨.** 가장 흔한 관용구
+> (`state:Compute(function(s) return s:Get() * 2 end)`)가 타입 에러를
+> 낸다 — 콜백이 raw 값을 받는 형태면 완전히 클린하다는 것까지 최소
+> 재현으로 확인됨(`.claude/luau-test/15-type-compute-trailing-deps-typepack.luau`,
+> `audit/luau-test-first-run-2026-08-13.md`). `Effect`/`Observer`/`Animate`/
+> `Operator` 등 같은 계약을 공유하는 API 전부에 걸림 — 아래 서술은 M0
+> 착수 전 사용자가 확정해야 할 미해결 사안이지 확정된 계약이 아님.
+
 - 최초안(self 값은 포지셔널 raw 값, with한 값만 클로저로 읽음)에는 실제
   단점이 있었음 — self가 raw 값이면 `fn` 호출 전에 항상 self를 먼저
   `Get()`해야 하므로, `fn` 내부 로직이 with한 다른 값을 보고 "이 경우엔 self

.claude/base/slot-plan.md

@@ -40,7 +40,7 @@ unmount(`Remove`) 둘이 아니라 **reposition(`Move`/`Swap`)까지 셋** —
 (`LayoutOrder` 기반 정렬이라) 사실상 no-op으로 둘지는 구현 선택.
 
 **[2026-08-09 일곱 번째 세션 보강]** `Dispatch/Slot.luau`의 mount 훅
-(`process(inst,k,self)`)은 `Dispatch.setLength(inst,i,self.Length)` 호출과
+(`process(inst,k,self,index)`)은 `Dispatch.setLength(inst,i,self.Length)` 호출과
 같은 자리에서 `self._listed`면 `activateList(self,inst)`도 트리거해야 함 —
 `:List`의 `data:Observer(fn)` 구독을 Slot 마운트 시점까지 lazy하게 미루는
 것도 이 mount 훅의 책임(아래 "`Slot:List(...)`"의 "구독 시점" 절 참고).
@@ -137,7 +137,7 @@ Fusion의 `Children` SpecialKey는 이걸 "특정 SpecialKey 하나의 내부
 서로 다른 두 대상을 추적해야 함 — 명시적으로 분리:
 
 - **Slot 컨테이너 자신**: `self._mounted: boolean`(Slot 인스턴스 필드
-  하나). **트리거 시점은 `Dispatch.process(inst,k,self)`가 이 Slot
+  하나). **트리거 시점은 `Dispatch.process(inst,k,self,index)`가 이 Slot
   객체에 대해 실제로 호출된 순간**(핸들러 매치 시점) — Instance
   `Parent` 대입 완료를 기다리지 않음. 다른 모든 "마운트됨" 판정(PreRef
   소진, Ref 콜백 fire 등)이 전부 dispatch-process 시점 기준이라 여기만
@@ -1021,7 +1021,7 @@ GC-native 원칙(`lifecycle-pattern.md`)을 `:List`라는 구체적 지점에
 **구독 시점은 `:List()` 호출이 아니라 Slot 마운트 시점 — lazy `bindLifetime`
 (2026-08-09 일곱 번째 세션, 아래 "구독 시점" 절 참고).** `:List()`는 설정만
 저장하고 반환, 실제 `data:Observer(fn)` 구독과 최초 `reconcile`은 Slot
-자신이 마운트되는 순간(`Dispatch/Slot.luau`의 `process(inst,k,self)`)에
+자신이 마운트되는 순간(`Dispatch/Slot.luau`의 `process(inst,k,self,index)`)에
 `activateList`가 수행 — `Dispatch.setLength`가 이미 쓰고 있는 것과 같은
 패턴(마운트 시점까지 미뤘다가 그 자리에서 `bindLifetime`).
 
@@ -1039,7 +1039,7 @@ function Slot:List(data, updateFn, keyFn)
     return self
 end
 
--- Dispatch/Slot.luau의 process(inst,k,self)가 마운트 시점에 1회 호출
+-- Dispatch/Slot.luau의 process(inst,k,self,index)가 마운트 시점에 1회 호출
 -- (self._mounted=true/self._mountedInst=inst, self.Offset 세팅과 같은 자리)
 function activateList(self, inst)
     local keyFn, updateFn = self._keyFn, self._updateFn
@@ -1184,7 +1184,7 @@ raw `i`를 그대로 위치 인자로 썼는데, 앞쪽 item이 filter로 마운
 **해법 — `Dispatch.setLength`가 이미 쓰고 있는 패턴 그대로 재사용**: 새
 메커니즘 발명 아님. `:List()`는 `data`/`updateFn`/`keyFn`만 저장하고 반환,
 실제 `data:Observer(fn)` 구독 + 최초 `reconcile`은 Slot 컨테이너 자신이
-마운트되는 순간(`Dispatch/Slot.luau`의 `process(inst,k,self)` — 위
+마운트되는 순간(`Dispatch/Slot.luau`의 `process(inst,k,self,index)` — 위
 "`isMounted` 이중 추적 분리" 절이 이미 `self._mounted`를 세팅하는 바로 그
 지점)에 `activateList(self, inst)`가 수행. `Dispatch.setLength(inst,i,
 self.Length)`를 부르는 것과 같은 자리에서 같이 트리거되면 됨.
@@ -1372,7 +1372,7 @@ local function attachSlot(slot, physicalTarget, ownerKey, position)
     -- top-level/nested 어느 깊이에서 불려도 완전히 동일하게 동작하는 순수 구조적
     -- mount 로직만 담당(레이어 구분은 오직 이 함수를 부르는 쪽의 책임) — retract
     -- 쪽(destroySlotTree)이 이미 이 원칙대로였는데(자기 자신의 unbindLifetime은
-    -- 안 하고 Handler.retract에서만 짝을 맞춤) process 쪽만 attachSlot 내부에
+    -- 안 하고 process가 반환하는 retract 클로저에서만 짝을 맞춤) process 쪽만 attachSlot 내부에
     -- ownerKey==physicalTarget 분기로 anchor 로직이 새어들어와 있던 비대칭이었음.
     slot._mounted = true
     slot._mountedInst = physicalTarget
@@ -1400,7 +1400,7 @@ end
 
 **최상위 마운트(`Dispatch/Slot.luau`)는 이제 이 함수 호출 한 줄:**
 ```lua
--- process(inst, k, slotValue)
+-- process(inst, k, slotValue, index)
 attachSlot(slotValue, inst, inst, k)   -- ownerKey = 물리 inst 자신
 ```
 
@@ -1482,10 +1482,14 @@ local function destroySlotTree(slot)
     -- destroySlotTree는 재귀 전체에서 항상 이 위치까지만(자식 Observer 정리) 담당.
 end
 
--- [명확화] 아래 시그니처는 index 기준 예시 — 위 "raw* 내부 호출 규약" 절이
--- 이미 못박았듯 reconcile(위 "여러 Slot이 섞일 때" 절 근처)은 element 기준으로
--- rawRemove(self, prev)를 부름. 둘 중 하나로 통일할지 얇은 변환 계층을 둘지는
--- 아직 M6 구현 세부로 열려 있음 — 이 블록은 그 결정 전 illustrative 예시.
+-- [명확화, 2026-08-13 감사에서 index/element 불일치 발견해 보강] 아래
+-- 시그니처는 index 기준 예시 — 위 "raw* 내부 호출 규약" 절이 이미
+-- 못박았듯 reconcile(위 "여러 Slot이 섞일 때" 절 근처)은 element 기준으로
+-- rawRemove(self, prev)를 부름. **같은 불일치가 rawUnmount에도 그대로
+-- 있음** — 아래 reconcile 예시의 rawUnmount(self, prev) 호출도 prev가
+-- element(mounted[key])이지 index가 아님. 둘 중 하나로 통일할지 얇은
+-- 변환 계층을 둘지는 아직 M6 구현 세부로 열려 있음 — 이 블록/아래
+-- reconcile 블록 둘 다 그 결정 전 illustrative 예시.
 -- [신설, 2026-08-13 여섯 번째 세션] rawRemove의 비파괴 짝 — `:List`의
 -- reconcile과 `Extract` 계열이 씀. rawRemove와 **딱 하나만 다름: 안 죽인다.**
 function rawUnmount(self, index)

.claude/base/store-semantics.md

@@ -5,6 +5,12 @@
 상세는 `base/bind-system-plan.md` 참고. 원본: `.claude/initreq/raw-userinput.md`
 "store는 부작용을 허용함" / "state는 어떻게 구현하는가" 절.
 
+> **⚠️ [2026-08-13 첫 실측에서 발견, `question.md` 0-Y]** 아래에서
+> "확정"으로 서술하는 self/deps lazy `State` 핸들 계약이 Luau 양방향
+> 추론과 충돌함이 실측으로 확인됨 — 상세는
+> `base/bind-system-plan.md`의 동일 배너, M0 착수 전 사용자가 확정해야
+> 할 미해결 사안.
+
 ## Store는 부작용을 허용하는 게 기본 디자인
 
 부작용 없이(파라메터 패싱만으로) 쓰는 것도 물론 가능하지만, 라이브러리 차원에서

.claude/luau-test/13-type-ref-preref-subtype.luau

@@ -22,10 +22,15 @@
 
 	실행:
 	  A) `luau-analyze 13-type-ref-preref-subtype.luau` (또는 luau-lsp)
-	  B) `luau 13-type-ref-preref-subtype.luau` (런타임 부분은 그냥 통과함,
-	     타입 에러가 있어도 런타임 실행 자체는 대부분 luau CLI가 그냥
-	     진행시켜줌 — 확실히 하려면 A/B를 따로 luau-analyze/luau로 각각
-	     돌려볼 것)
+	  B) `luau 13-type-ref-preref-subtype.luau`
+
+	[정정, 2026-08-13 첫 실측 라운드] 위 "런타임 부분은 그냥 통과함" 예상은
+	틀렸음 — 실제로 돌려보니 A섹션의 `fakePreRef(0)`가 런타임에 `nil`을
+	반환하는 더미 스텁이라, B섹션이 시작하기 전에 `useAsRef(myPreRef)`의
+	`r.Value` 접근에서 "attempt to index nil"로 죽어 B섹션 런타임 검증까지
+	도달하지 못함. 타입 A섹션(luau-analyze)은 별개로 통과. 상세는
+	`luau-test/STATUS.md` 🟠 항목 — A/B를 별도 파일로 분리해야 함(재작성
+	대기).
 ]]
 
 -- ===== A) 타입 체크 대상 =====

.claude/luau-test/STATUS.md

@@ -4,19 +4,23 @@
 > 상세 결과는 `.claude/audit/luau-test-first-run-2026-08-13.md`.
 > 실행법: `luau <파일>` (런타임) / `luau-analyze <파일>` (타입 전용).
 
-## 🔴 사람 결정 필요 — 설계가 걸린 것 (2건)
+## 🔴 사람 결정 필요 — 설계가 걸린 것 (1건)
 
 | 파일 | 무엇이 걸렸나 | 어디로 |
 |---|---|---|
-| `15-type-compute-trailing-deps-typepack.luau` | **`:Compute(fn)`의 lazy 핸들 계약이 Luau 추론과 충돌.** `state:Compute(function(s) return s:Get()*2 end)`가 타입 에러. 콜백이 raw 값을 받으면 완전 클린 — 즉 표기 조정이 아니라 계약 자체가 원인. `Effect`/`Observer`/`Animate`/`Operator` 등 같은 계약 공유 API 전부에 걸림 | `question.md` **0-Y** |
 | `08-type-source-satisfies-state.luau` | 핵심 질문(Source⊇State)은 통과. 다만 `State<T>`가 **자기 자신**을 다른 타입 인자로 재귀 참조하면 `Recursive type being used with different parameters` — 사용자 방향은 "구울 때 인라이닝" | `question.md` **0-Y** 하단 |
 
+`15`의 `:Compute(fn)` lazy 핸들 계약 충돌(**`question.md` 0-Y** 본 항목)도
+같은 종류의 사람 결정 필요 사안이지만, 스파이크 자체가 파싱 실패라 아직
+그 결과를 신뢰할 수 없는 상태 — 아래 🟠 표에서 재작성 대기 중, 재작성 후
+다시 여기로 승격할 것.
+
 ## 🟠 스파이크 자체가 깨져 있음 — 재작성 필요 (3건, 설계 문제 아님)
 
 | 파일 | 상태 | 무엇을 고쳐야 하나 |
 |---|---|---|
 | `13-type-ref-preref-subtype.luau` | 타입 A섹션은 ✅ 통과 / **런타임 B섹션 실행 불가** | B가 A의 더미 스텁(`fakePreRef = nil`)에 막혀 도달 못 함 — 두 섹션 분리 |
-| `15-type-compute-trailing-deps-typepack.luau` | **파싱 실패**(SyntaxError) | 음성 대조군의 타입 표기가 `TypeError`가 아니라 `SyntaxError`로 걸려 **파일 전체가 아무것도 검증 못 함** — 대조군을 별도 파일/블록으로 격리 |
+| `15-type-compute-trailing-deps-typepack.luau` | **파싱 실패**(SyntaxError) | 음성 대조군의 타입 표기가 `TypeError`가 아니라 `SyntaxError`로 걸려 **파일 전체가 아무것도 검증 못 함** — 대조군을 별도 파일/블록으로 격리. 재작성 후에도 `:Compute` 계약 충돌 자체는 이미 다른 최소 재현으로 확인됐으므로(`question.md` 0-Y) 재작성은 확인 사살일 뿐 0-Y 판단을 바꾸지 않음 |
 | `16-type-store-key-typefunction.luau` | ❌ 실패 | `types.newfunction` 시그니처가 설치된 버전의 실제 API와 안 맞음 — 실제 API 재확인 후 재시도 |
 
 ## ⚪ 아직 안 돌림

.claude/research/documentation-content-map.md

@@ -251,8 +251,17 @@ additional-primitives-plan.md`의 "문서화 백로그" 절이 원자료)**:
 - **[해소됨]** Slot 형제 순서 보장 — `Dispatch.setLength`/
   `setOffsetSource`(Length/Offset)로 2026-08-09 여섯 번째 세션에 확정,
   `bind-system-plan.md` "Length/Offset" 절 참고.
-- Tween 오버라이드/삭제후재시작/끝점이동 세부 옵션 키 이름, 트윈 옵션 값
-  모양(TweenInfo vs 편의 필드) (`base/tween-plan.md`) — 아직 열림.
+- **[해소됨, 2026-08-13 정정]** Tween 오버라이드/옵션 값 모양 —
+  2026-08-12 첫 번째 세션에 `Info: TweenInfo?`+편의 필드 폴백,
+  override 정책은 `Tween.Cancel`(기본)/`Tween.Finish` 2값으로 확정,
+  `tween-plan.md` 자체가 `research/`에서 `base/`로 승격됨(이 줄이 그
+  갱신을 놓치고 있었음). **다만 아래 §1/§2의 Tween 예시(`[Tween(key,
+  ...)] = storeValue` 특수 바인드 키, "Tween 핸들러가 Instance
+  직접 받음", "반응 그래프 밖 특수 bind key로 둔 이유")는 전부
+  2026-08-10 두 번째 세션에 폐기된 구모델
+  (`archive/tween-special-bind-key-reversed.md`) 서술 — 이 문서를
+  실제로 쓸 때 `Tween(opts) -> Tween<T>` 값-레벨 래퍼 모델로 다시
+  써야 함.**
 - **[해소됨]** `Attribute<T>` 제네릭 vs 타입별 정적 생성자 — 2026-08-09
   열한 번째 세션에 "둘 다 채택"으로 확정, `base/attribute-plan.md` 참고.
 - provider/processor 네이밍 — **[해소됨]** `Handler`로 이미 오래전 확정

ROADMAP.md

@@ -479,7 +479,10 @@ Luau 코드로 부딪혀본 적 없는 세 가지**를 던지는 코드로 검
       이를 `nil`로 재디스패치하는 base 내장 `NoneHandler`
       (`bind-system-plan.md`의 `None` 센티널 절, M2 dispatch 엔진의
       "이전 매치 핸들러 추적" 항목과 함께 구현 — `StoreBind` 핸들러와
-      동일한 재귀 재디스패치 패턴이라 새 메커니즘 아님) — 확정 완료
+      동일한 재귀 재디스패치 패턴이라 새 메커니즘 아님) — `None` 센티널
+      자체는 확정 완료지만, **⚠️ M2 배너와 같은 주의**: `NoneHandler`가
+      쓰는 재-dispatch 배관(선행 `retractFrom` 호출)은 재디스패치 모델
+      교체 대상이라 `question.md` 0-Z 먼저 해소할 것
 - [ ] 프로퍼티류 필드 타입에 `T' = T | Tween<T>` 치환 반영(타입 생성
       스크립트가 `Position: UDim2` 자리를 `UDim2 | Tween<UDim2>`로 만들면
       끝, Modifier 런타임/`__index` 자체엔 변경 없음 — `modifier-plan.md`