# Store — 이름 붙은 Source 모음, 그 이상 아님 > **📄 [2026-08-14 신설] `bind-system-plan.md` 3단계 분할 + store-semantics.md > 흡수.** Store가 "Source들을 담고, 없으면 만들어주는 도구"로 좁혀지고 나서도 > 관련 서술이 store-semantics.md(부작용 허용, 값 설정 문법)와 > `bind-system-plan.md`(dot-access 타이핑, Store가 Store를 담는가)에 반씩 > 흩어져 있었음 — 한 군데로 합쳤고 **내용/결정은 이동·병합 자체로는 안 > 바뀜**. 반응형 코어(Source/State 자체)는 짝 문서 > **`base/source-state-plan.md`**. **상태**: base — Store가 부작용을 허용한다는 핵심 결정, "이름 붙은 Source 모음"이라는 정의, `store.key` dot-access 타이핑까지 전부 확정. **⭐ [2026-08-25] 두 가지가 바뀌었다** — (1) 생성이 **명시적 초기화**로 확정되고 옛 lazy `__index`가 폐기됐다, (2) 타입은 **타입 함수를 안 쓰고** 평범한 레코드로 짓는다(`WrapStore`/`ProcessStoreType` 폐기). 같은 날 "`store.key`를 값으로" 재설계를 넣었다가 철회한 경위는 `archive/store-value-field-redesign-withdrawn.md`. 원본: `.claude/initreq/raw-userinput.md` "store는 부작용을 허용함" / "스토어는 스토어를 저장 가능한가" 절. ## Store는 부작용을 허용하는 게 기본 디자인 부작용 없이(파라메터 패싱만으로) 쓰는 것도 물론 가능하지만, 라이브러리 차원에서 막지 않는다. 부작용 유무는 **사용자가 직접 문서화**하는 관례로 둔다 — 라이브러리가 순수성을 강제하지 않음. 다만 한 가지는 명확히 구분: **렌더 리턴 위에서 무언가를 observe하는 것은 그냥 부작용**이다 (`useEffect`와 유사한 것으로 문서화). 이건 "허용되는 부작용"이 아니라 "당연히 부작용"이라는 뜻 — 문서화 시 이 경계를 분명히 할 것 (`base/ purity-and-effects-plan.md`와 연결됨). **보강(2026-08-04 검증 라운드): 부작용은 심각도가 다른 두 갈래로 나뉜다.** 1. **국소적 부작용** — 입력으로 받았거나 자신이 만들어 소유한 대상에 대한 부작용(예: 렌더 리턴 아래에서 옵저빙해서 자기 slot을 갱신). 이건 편의성이 커서 적극 환영하는 영역. 2. **경계를 넘는 부작용** — globalStore처럼 컴포넌트 바깥의 전역 상태를 다루는 경우. 게임 UI 특성상(스킬/주변 환경에 영향받는 UI 등) 완전히 막을 수는 없지만, 라이브러리로 재사용하려는 컴포넌트가 이런 부작용을 가지면 이식성이 떨어짐(`base/purity-and-effects-plan.md`와 연결). **해소됨(2026-08-04 2차 라운드)**: "state를 옵저빙해서 나온 결과로 slot에 `clear`/`add` 같은 연산을 할 때, 그 시점에 대상 slot이 이미 죽어있으면 어떻게 되는가"는 별도 메커니즘 없이 `canExecute` 재사용으로 해결됨 — `base/source-state-plan.md`의 "Slot 생존 확인" 절이 소스. ## Store = Source들의 이름 붙은 모음 (명시적 초기화) > **⭐⭐ [2026-08-25] 같은 날 두 번 바뀌었다 — 최종은 이 절이다.** > 오전에 "`store.key`가 값이고 `store:Of(k)`가 프리미티브"라는 재설계를 > 넣었다가 **같은 날 철회**했다. 철회된 시도의 원문과 이유는 > `archive/store-value-field-redesign-withdrawn.md`. 그 시도가 남긴 것은 > **명시적 초기화**(eager/lazy 이중 모델 폐기) 하나이고, 나머지(값 필드, > `__index`/`__newindex` 슈가, 팬텀 필드, `index<>`/`keyof<>`)는 전부 > 되돌렸다. **Store의 타입 인자에는 `Source`를 직접 쓰고, `defaults`에도 `Source(v)`를 직접 넣는다.** ```lua local store = quad.Store<<{ hp: Source, name: Source, }>>({ hp = Source(100), name = Source(""), }) store.hp:Get() -- 평범한 레코드 필드 접근 → Source store.hp:Set(5) store.hp:Compute(function(s) ... end) ``` - **`store.key`는 평범한 레코드 필드다** — `Store`가 `T`(그 자체로 `{hp: Source, ...}`)를 그대로 포함하므로 **타입 함수가 하나도 안 든다.** 마법이 없고, 읽기/쓰기 의미론이 `Source`의 기존 계약 (`:Get()`/`:Set()`) 그대로다. - **⭐ 명시적 초기화가 기본** — 선언한 키는 생성 시 `Source`를 준다. `defaults`에 없는 키는 **필드 자체가 없어** 타입에서 걸리고, 런타임에도 `nil` 역참조로 즉시 드러난다. 옛 lazy `__index`(없는 키를 그 자리에서 만들어 저장)는 **폐기**됐다 — **사용자 근거**: *"lazy 로 만들어낸다는 발상 자체가 약간 문제가 있어요. Set 을 안 해주면, 초기 값이 타입에 어긋날 수 있거든요. 애초에, `Source` 인데, nil을 조용히 가지고 있을수도 있고, 타입으로 못 막네요."* - **부수 효과**: 선언 키 집합의 **런타임 소스가 `defaults` 하나**로 확정된다. 그래서 `store:Names()`가 `pairs`로 성립한다 — 옛 lazy 모델에선 키 집합이 접근 이력에 좌우돼 0개/1개/2개로 갈렸다 (7라운드 `H-79`). - **부모가 값을 다 안 넘겨도 되게 하려면 컴포넌트가 자기 `DEFAULTS`로 채운다** — 타입에 `?`를 다는 게 아니라 **호출 규약**으로 표현한다 (**사용자 아이디어**: *"기본 값인 소스는 한 곳에 `Defaults = {}` 해두고 쓰는거죠"*). 그래야 생성자가 항상 완전한 테이블을 받는다. - **외부에서 만든 `Source`를 나중에 끼워 넣는 표면은 없다** — 생성 시점에 넣는 게 전부다(**사용자 판단**: *"다른곳에서 생성된 Source 를 다시 넣는다는게, 가능하게 해야할 표면적 이유가 없습니다"*). - **값이 없는 상태가 필요하면 `None`이 이미 그 자리다** — attribute를 실제로 지우는 것도 `Source → None → nil`로 핸들러 계열을 타고 말단에서 set nil 된다. Store 키를 nilable로 만들 이유가 아니다. - **구현 스케치**: 생성 시 `table.clone(defaults or {})`로 그림자 테이블을 만든다(**[2026-08-28 확정, 10라운드 `H-153`]** 그림자 = **store 자신** — `store.key`가 평범한 레코드 필드라는 계약과 맞고, 메소드는 `__index`에 있어 `Names()`가 안 센다; 별도 테이블 + 프록시 안은 기각. `table.clone`이 원본의 해시/배열 슬롯 구조를 재사용해 빈 테이블에 키를 하나씩 넣는 것보다 쌈 — 2026-08-07 성능 근거 그대로). 값이 이미 `Source`이므로 **슬롯 교체 순회가 없다**. **`or {}`가 필수다** — 무인자 `Store<<{}>>()`도 유효한데 `table.clone(nil)`은 `table expected, got nil`로 죽는다(**[2026-08-25]** 7라운드 `H-83` 실측). - **⭐ [2026-08-26 신설, 8라운드 `H-122`] 생성자가 `defaults` 값 전량을 런타임 검증한다 — `isSource` 화이트리스트.** 타입은 `Source` 필드를 요구하지만 `--!nocheck`/동적 코드가 `{hp = 100}`(raw 값)을 넘기면 지금 스케치(`table.clone`)는 **조용히 받고** 첫 `store.hp:Get()`에서 엉뚱한 에러로 죽는다. `H-40`이 `:List` 요소 검증을 블랙리스트에서 화이트리스트로 뒤집은 것과 같은 성격의 자리다 — **사용자 확정**으로 여기도 화이트리스트를 둔다. `defaults`를 한 번 순회하며 `isSource(v)`가 거짓이면 **`error(..., 2)`**(**[2026-08-28 10라운드 `H-153`]** 같은 순회에서 **예약 이름** (`RESERVED` 테이블 — 아래 `Of` 절의 리터럴이 런타임 단일 소스; `__reservedCheck`는 팬텀이라 `__index`에서 도출할 수 없다)도 `error(..., 2)` — `Store({ Of = Source(1) })`가 통과하면 첫 `s:Of(…)`가 *attempt to call a table value*로 엉뚱한 자리에서 죽는다, 실측 `t23`; 사용자 확정 *"나도 a 동의"*)(사용자 입력 검증이므로 `level 2`, 메시지는 영어 — `base/architecture.md`의 error 계약). 생성 시 1회라 hot path가 아니다. `isModifier` 쪽 가드는 여기가 아니라 **`Source` 생성자**가 맡는다 (`base/modifier-plan.md` 7번). - **`store:Names()`** — 그 시점의 키 집합을 준다(그림자 테이블의 키). 그룹 `Attribute(...)`/`attr:NameMap()`이 이걸 요구한다 (`base/attribute-plan.md`, 7라운드 `H-79`). **⚠️ "선언된 키"와 정확히 같지는 않다** — `defaults`의 키에 **동적 키 창구 `store:Of(name)`이 만든 것**이 더해진다(아래 "타입 추론 문제" 절). 둘의 차이는 `Of`를 쓴 Store에서만 생기고, `Of`는 "타입 보장을 포기했다"가 호출부에 드러나는 명시적 자리다. **그룹 `Attribute`에 미치는 영향**: 이미 배치된 `Attribute(store)` 바인딩은 그 시점의 `NameMap()` 스냅샷으로 구성되므로, 나중에 `Of`로 늘어난 키는 **다음 재디스패치 때** 반영된다 (`base/attribute-plan.md`의 그룹 절). v1이 모든 값을 Store 하나에 몰아넣던 습관은 "당시 정적 타입이 없어 단순하게 쓰는 게 편해서"였다는 게 사용자의 회고적 재평가 — 지금은 타입이 핵심 제약이라 그 전제 자체가 더 이상 안 맞고, 2026-08-06 후속 세션의 정리로 Store는 "이름 붙은 Source 모음, 그 이상 아님"으로 더 단순해짐. 값 하나만 반응형으로 다루고 싶으면 Store를 통째로 만들지 말고 독립 `Source(default)`를 쓸 것(`base/source-state-plan.md`의 "Source는 독립 공개 프리미티브로 격상" 절). ## Store 값 설정 문법 — `myStore.key = value` 폐기, `store.key:Set(value)` (2026-08-06 후속 세션, 확정 유지) > **[2026-08-25] 이 결정은 유지된다.** 같은 날 오전에 한 번 뒤집었다가 > (`store.key`를 값으로 만들면서 대입이 되살아났었다) **같은 날 철회**했다 — > `archive/store-value-field-redesign-withdrawn.md`. `store.key`가 다시 > `Source`이므로 아래 근거 셋이 전부 그대로 성립한다. **`store.key = value`는 안 쓴다.** 값을 쓰는 경로는 `store.key:Set(value)`다. 1. **타입 대칭성**: `store.key`가 `Source`를 직접 반환하는 평범한 레코드 필드(`{key: Source}`)로 타이핑되는데, 레코드 필드는 읽기/쓰기 타입이 같아야 Luau 구조적 타이핑이 깨끗하게 성립한다. `store.key = value`(raw `T` 대입)를 유지하면 읽기(`Source`)/쓰기(`T`) 타입이 갈려 mismatch가 남는다 — `:Set(value)`로 통일하면 필드 타입이 항상 `Source`로 대칭적이라 문제 자체가 안 생긴다(사용자 지적). 2. **의미론적 정직성**: `=` 대입 문법은 관례상 "그 자리에서 즉시 확정되는 부작용 없는 값 쓰기"를 암시하는데, quad의 실제 동작은 **lazy** — `Set`은 무효화 신호만 쏘고, 실제 재계산은 나중에 누군가 관측(`Get()`)할 때만 일어난다. 메소드 호출(`:Set()`)이 "이건 프로세스를 트리거하는 연산"이라는 걸 더 정직하게 신호한다(사용자 확정 논거). **[2026-08-25 보강]** 철회된 재설계가 이 논거를 실제로 검증해줬다 — `store.key = v`를 되살리자 *"`.Value = 1`이 정적 쓰기처럼 보이는데 거기서 error trace가 나오면 당황스럽고 약간 마법적"*(사용자)이라는 문제가 바로 드러났다. 3. `:Set()`은 이미 확정된 "값을 바꾸는 연산엔 `:` 체이닝 허용" 원칙 (`base/architecture.md`)에도 자연스럽게 들어맞는다. **`myStore "key"`(문자열 커링)는 기각**이다(2026-08-18 사용자 판정) — *"저러면 "a" 가 string 으로 들어가서, Source 의 타입을 모르기도 하고, 우린 더이상 필요하지 않게 된 요소임."* 동적 키는 아래 `:Of`로 간다. `base/architecture.md`의 "복사(clone) 구현 지양, 팩토리 함수로 대체" 원칙과 함께 읽을 것 — v1의 문제는 metatable 체이닝으로 매번 새 테이블을 할당하며 "불변 빌더"를 흉내낸 것이었지, `:` 체이닝 문법 자체나 커링 문법 자체가 아니었음. ## 타입 추론 문제 — `store.key`(dot-access)를 1급 경로로 확정 (2026-08-04 3차 라운드) - `store "key"`(문자열 커링)로 `state`를 오버로드 함수 타입으로 정확히 추론하려는 시도는 포기하고(그 문자열 커링 자체도 **[2026-08-18] 기각**, 위 절), **`store.key`(dot-access)를 1급 경로로 확정**. Store 타입을 `{key: Source, other: Source}`류 **평범한 레코드 타입**으로 지으면 일반 구조적 필드 타이핑으로 자동 해결되고, 문자열 리터럴 narrowing 문제 자체가 안 생긴다. - **⭐ [2026-08-25] 동적 키는 `store:Of<>(name): Source` 하나다** — 옛 이름 `GetDynamic`을 **흡수**했다(표면 둘을 유지할 이유가 없다). 선언되지 않은 이름은 레코드 타입에 없어서 dot-access는 타입 에러가 난다(그게 방어선이라는 게 사용자 확정). 그래서 "런타임에 이름이 정해지는" 정당한 용도를 위해 **타입을 호출자가 직접 주는 명시적 창구**를 둔다 — 사용자 판정: *"이는 GetDynamic(name): Source 로 제공하는게 최선으로 보임."* 이름이 명시적이라 "여기서 타입 보장을 포기했다"가 호출부에 드러나는 것도 문자열 커링보다 나은 점. - **⭐⭐ [2026-08-25 신설] `Of`는 없는 이름이면 그 자리에서 만들어 저장한다 — 여기가 lazy 생성이 남는 유일한 자리다.** 명시적 초기화로 dot-access 쪽 lazy `__index`는 폐기됐지만(위 절), **동적 키 창구는 그 위에 서 있었다** (`/code-review high` 발견) — `defaults`에 없는 이름을 `Of`가 그냥 조회하면 `nil`을 `Source` 타입으로 돌려주고 호출부가 `:Get()`에서 타입 에러 없이 nil 역참조한다. ```lua -- ⭐ [2026-08-28 `H-153`] 예약 이름의 **런타임 단일 소스**. 세 이름을 리터럴로 — -- `__reservedCheck`는 팬텀이라 `__index`에서 도출할 수 없다(아래 주석). -- 타입 함수 `CheckReservedKeys`의 목록은 이 테이블의 사본이라 이름을 바꿀 땐 -- 둘을 같이(코퍼스의 다른 산문 나열은 전부 이 테이블을 가리키기만 할 것). local RESERVED = { Of = true, Names = true, __reservedCheck = true } function Store:Of(name) -- 동적 키 전용 if RESERVED[name] then -- 동적 키는 타입이 못 막는다 error("reserved store key: " .. name, 2) end local src = rawget(self, name) -- 그림자 = store 자신(`H-153`) — `__index`를 안 타게 raw if src == nil then src = Source() -- == Source(nil) self[name] = src end return src end ``` - **`__index` lazy와 다른 점**: 그건 **암묵**이었고(오타가 조용히 새 Source를 만들었다) 이건 **명시**다 — 이름을 문자열로 넘기고 타입을 `<>`로 직접 주는 자리라 "여기서 타입 보장을 포기했다"가 호출부에 드러난다. 그게 애초에 이 창구를 둔 이유다. - **`store:Names()`는 그대로 성립한다** — 선언 키(`defaults`)에 `Of`가 만든 동적 키가 더해진 것이 그 시점의 실제 키 집합이고, `Names()`가 돌려주는 것도 그것이다. - **오타 방어는 여전히 타입이 한다** — dot-access는 레코드 타입에 없는 이름을 거부한다. `Of`는 그 방어를 **의도적으로** 우회하는 창구다. - **⭐ [2026-08-25 실측] `<>`는 값 호출부에서 동작한다.** 7라운드 `H-73`이 *"Luau엔 호출부 명시 타입 인자 문법이 없다"*고 단정했으나 **틀렸다** — Luau의 **generic type instantiation** (`luau.org/types/generics/#generic-type-instantiation`)이 값 호출부에서도, 콜론 메소드에서도 `T`를 실제로 묶는다. `luau-analyze` 실측: ```lua local ok: Source = store:Of<>("x") -- 진단 없음 local bad: Source = store:Of<>("y") -- 정확히 걸림 local none: Source = store:Of("z") -- Source ``` 원문은 **인스턴스화를 생략한 호출만** 돌려보고 단정했다. 따라서 `base/quad-types-plan.md`의 이중 꺾쇠 관례는 타입 자리 전용이 아니다. - **⭐ [2026-08-25, 2026-08-26 개수 정정] 예약 키는 `Of`/`Names`/`__reservedCheck` 셋이고, 충돌은 조용히 죽는다.** (**[2026-08-26, `/code-review high`]** 한때 *"`Of`/`Names` 둘뿐"*이라 적혔는데, 진단용 팬텀 필드가 교집합 **안에** 살므로 그 이름 자신도 예약해야 자기 충돌이 조용히 지나가지 않는다 — 아래 타입 선언이 소스.) 실측: 사용자 키가 예약 이름과 겹치면 교집합이 뭉개져 **그 필드의 타입 검사가 통째로 꺼진다**(음성 대조군이 진단 0건으로 통과했다). 시끄럽게 막히는 게 아니라 그냥 지나간다. - **그래서 예약 키를 검증만 하는 작은 `type function`을 둔다** (**⚠️ [2026-08-26 정정, 8라운드 `H-112`]** 여기 한때 *"`T`를 검증만 하고 그대로 통과시키는"*이라고 적혀 있었는데 **`T`를 통째로 넘기는 배선은 실사용 `T`에서 아예 안 돈다** — 확정된 인자는 `keyof`이고, 근거와 실측은 아래 "`store.key` 레코드 필드 타이핑" 절이 소스). 겹치면 사용 지점에 `TypeError: quad.Store: "Of" is a reserved key`가 뜬다. **`error()`는 못 쓴다** — `type function` 자체가 실패한 걸로 판정돼 버려진다. `print(...)` + `return types.never` 조합만 된다 (`luau-test/rewrite-required/23-...`가 기록해둔 사실이고 `type-version-check`가 이미 쓰는 패턴). - **이건 아래 §0 원칙의 허용 범위 안이다** — 타입 함수를 **진단을 띄우는 데만** 쓰고 접근 타입을 합성하는 데는 안 쓴다 (`base/typing-limits.md`). - 이 패턴은 Store에만 국한되지 않고 **인스턴스 생성까지 관통하는 프로젝트 전역 관습으로 확정**됨 — 단 이벤트는 이후 4차 라운드에서 이 관습의 **유일한 예외**로 빠졌음(PA님 방식인 문자열 키+런타임 리플렉션으로 전환). `base/bind-system-plan.md`의 "인스턴스 생성 / 이벤트 네이밍 인체공학" 절이 최신 확정 내용. ### `store.key` 레코드 필드 타이핑 — 타입 함수가 필요 없다 (2026-08-25 재확정) > **⭐⭐ [2026-08-25] 타입 함수로 접근 타입을 짓는 접근은 **두 번** 시도됐고 > **두 번 다 폐기**됐다.** (1) `WrapStore`/`ProcessStoreType`로 결과 타입을 > **합성**하는 안(2026-08-12~2026-08-15) — 7라운드 `H-75`/`H-76`이 두 > 한계를 실측해 폐기. (2) `index<>`/`keyof<>` + 팬텀 필드로 짓는 안 > (2026-08-25 오전) — 같은 날 철회 > (`archive/store-value-field-redesign-withdrawn.md`). **지금은 타입 함수를 안 쓴다.** `Store`의 `T`가 이미 `{hp: Source, ...}`이므로 `store.hp`는 **평범한 레코드 필드 접근**이고, Luau가 그냥 해준다. ```lua type Store = T & { Of: (self: any, name: string) -> Source, -- 동적 키 전용 Names: (self: any) -> { string }, __reservedCheck: CheckReservedKeys>, -- 팬텀 필드(진단 전용) } -- 검증 목록은 `Of` · `Names` · `__reservedCheck` 셋이다 — 팬텀 필드 자신도 -- 교집합 안에 있으므로 자기 이름을 예약 목록에 넣어야 자기 충돌이 조용히 -- 지나가지 않는다. -- -- ⚠️ [2026-08-26, `/code-review high` 5차] **`__reservedCheck`는 런타임 -- 대응물이 없다.** 생성자는 `table.clone(defaults or {})`뿐이라 -- `store.__reservedCheck`는 **타입은 `true`, 런타임은 `nil`**이다 — 이 -- 문서가 옆에서 "선언 안 된 키 접근은 타입 에러"임을 스파이크로 증명해두는 -- 것과 대비되는 unsound한 자리다. 팬텀 필드의 존재 이유가 진단 하나뿐이라 -- 감수하되, 두 가지를 문서화한다: -- (1) **읽지 말 것** — 사용자 표면이 아니다. -- (2) `store:Names()`(그림자 테이블의 키)에는 **안 들어간다**. 그래서 -- `store:Of("__reservedCheck")`는 타입 쪽 `CheckReservedKeys`가 못 막는다 -- (**동적 키는 이름이 타입에 안 실린다**) — 그래서 **[2026-08-28 `H-153`]** -- `Of(name)`과 생성자가 런타임 예약 이름 가드로 `error(…, 2)`한다(위). ``` **⭐⭐ [2026-08-26 확정, 8라운드 `H-112`] 예약 키 진단 타입 함수는 `T`가 아니라 `keyof`를 받는다.** 2026-08-25엔 *"`T`를 검증만 하고 그대로 통과시키는 작은 `type function`"*으로 확정돼 있었는데, **그 배선은 실사용 `T`에서 아예 돌지 않는다**(실측 재현): - 최종 Store의 타입 인자는 정의상 `{hp: Source, …}` — **모든 실사용 `T`에 `Source` 필드가 들어간다.** - 확정 선언 스타일(`base/typing-limits.md` §1②의 인라인 쪼개기 — 콜백 파라미터 무주석 추론이 사는 유일한 스타일)에서 `Source`는 `Compute`의 `-> State` 재귀 반환 누수 때문에 내부에 `*error-type*`을 품는다. - **Luau 타입 함수는 `*error-type*`이 든 타입을 받는 순간 실패한다** — 그래서 `CheckReserved`를 어디에 배선하든 **예약 키가 없는 완전히 유효한 Store 사용 지점 전부**에 `TypeError: Type functions do not currently support types of the form '*error-type*'`가 뜬다. 접근 경로에 배선하면 (`Store = CheckReserved & {…}`) 거기 더해 `does not have key 'hp'`로 **필드 접근까지 전멸**한다. - 7라운드가 이걸 못 본 이유: 그때 돌린 스파이크 (`audit/type-store-index-keyof/spikes/05-checkreserved.luau`)의 `T`가 **철회된 재설계의 스칼라 필드**(`{hp: number}`)였다. 최종형에선 필드가 스칼라가 아니라 `Source`다. **통과하는 배선**(실측 완료 — `keyof`는 키 싱글톤 유니온이라 `Source` 타입이 인자에 아예 안 실리고, `*error-type*` 직렬화 문제가 원천 소멸한다): ```lua type function CheckReservedKeys(keys: type) -- keys: "hp" | "name" 같은 싱글톤 유니온. -- "Of"/"Names"/"__reservedCheck"가 섞여 있으면 print(...) + return types.never. -- (error()는 못 쓴다 — 타입 함수 자체가 실패한 걸로 판정돼 버려진다) return types.singleton(true) end ``` 측정 결과: 예약 키 충돌 시 `TypeError: quad.Store: "Of" is a reserved key`가 **캐스트 지점과 생성자 호출 지점 양쪽에서** 강제 평가 없이 뜨고, `store.hp:Get()` 양성 통과 / 음성 대조군 정확히 걸림, 그리고 `store.hp:Compute(function(x) return x:Get() * 2 end)`의 **무주석 콜백 추론이 생존**한다. `base/typing-limits.md` §0(*타입 함수는 진단까지만*)의 허용 범위 안이다 — 결과가 접근 타입에 안 섞이고(팬텀 필드 값은 `types.singleton(true)`), 같은 §0이 경고하는 내장 `index<>`/`keyof<>`도 **형제 필드의 `*error-type*`에 오염되지 않는다**는 것이 별도 실측(`CheckedQuad`)으로 재확인됐다. **✅ [2026-08-28 실측 완료, 10라운드 `H-157`] 빈 Store(`Store<<{}>>()`)는 클린이다** — 최종형(`StateData`/`State` 쪼개기, `Source` 필드, `CheckReservedKeys>`) 에 `Store({} :: {})`를 넣으면 진단 0(`keyof<{}>`는 에러가 아니라 빈 유니온이라 검사가 그냥 통과), `Names()`/`Of("dyn")` 정상(`audit/handtrace-round10-reference-impl/` `ty11`). 아래는 실측 전 서술: **[2026-08-26, `/code-review high`] 빈 Store는 아직 실측 안 됐다.** `H-83`은 무인자 생성이 유효해야 한다고 확정했는데(`or {}` 방어의 존재 이유), 위 실측은 **키가 있는 `T`로만** 돌았다. `keyof<{}>`가 Luau에서 빈 유니온이 되는지 에러가 되는지에 따라 **무인자 Store 전체가 스퓨리어스 타입 에러를 뒤집어쓸 수 있다** — `H-112`가 `CheckReserved`에서 찾은 실패 모드와 정확히 같은 형태다. `luau-test/STATUS.md`의 `16`/`21` 재작성 때 `Store<{}>`를 대조군으로 넣을 것. **기각된 대안**: (b) `CheckReserved` 자체를 포기하고 "예약 키가 겹치면 그 필드의 타입 검사가 조용히 꺼진다"를 문서 경고로만 남기는 안, (c) 선언 스타일을 §1③(`typeof`)으로 전환하는 안 — ③ 전면 전환은 `Get()`이 `unknown`으로 붕괴하고 하이브리드는 무주석 콜백 추론이 깨지는 것이 실측됐다 (둘 다 `CheckReserved` 유무와 무관한 선언 스타일 자체의 문제 — 대조군 확인). 즉 **"콜백 추론 + 예약 키 진단" 동시 성립 배선은 `T`를 통째로 넘기는 한 존재하지 않는다.** **`luau-analyze` 실측**(양성 + 음성 대조군): | 검사 | 결과 | |---|---| | `store.hp` | `Source` ✅ (`Source` 대조군 걸림) | | `store.hp:Get()` / `:Set(5)` | ✅ (틀린 타입 대조군 둘 다 걸림) | | `store.nope` | **거부** ✅ | | `store:Of<>("dyn")` | `Source` ✅ (대조군 걸림) | | 콜백 파라미터 추론(`store.hp:Compute(function(s) ... end)`) | ✅ `s`가 `StateData`로 잡힘(`s:NoSuchField()`가 정확히 걸림) | - **⚠️ `Compute`/`Apply`의 반환 타입은 여전히 명시 주석이 필요하다** — 이건 Store와 무관한 `base/typing-limits.md` §1의 **문제 B**이고, `store.hp`든 독립 `Source`든 **똑같이** 조용히 안전성을 잃는다(실측: 틀린 주석 `local x: State = src:Compute(...)`이 양쪽 다 안 걸림). `audit/type-recursion-issue/REPORT.md` 3-1절이 확정한 대로 **명시 주석 이후 다운스트림 전체는 정상 체크**되고 구멍은 그 한 줄뿐이다. 살아나는 건 **콜백 파라미터** 쪽이다 — 그리고 철회된 재설계의 `Self` 제네릭을 거치면 **그것마저 깨졌다**(`s`가 `unknown`으로 떨어짐). - **`__call` 경로는 죽었다** — 타입 레벨 `__call`은 `self`를 못 받고, `typeof(f<>)`로 타입 인자를 넘기는 것도 실패한다(실측). 같은 사실이 `base/source-state-plan.md`의 `:Apply`에도 적용된다(7라운드 `H-94`). 실측 전량은 `audit/type-store-index-keyof/`가 소스. **⚠️ [2026-08-26, 8라운드 `H-115`] 다만 그 폴더에 최종형 결합을 도는 파일이 없다** — 대부분이 철회된 재설계(`__store` 팬텀 + `keyof>`, 값 필드가 스칼라)를 대상으로 한다(REPORT 상단 배너도 철회를 명시). 위 표의 측정값 자체는 8라운드 스파이크로 대체 재확인됐고(단 `CheckReserved` 결합은 표와 달리 실패 — `H-112`), **출처 문제는 `luau-test/STATUS.md`의 `16`/`21` 재작성 때 최종형 + `CheckReservedKeys` 배선을 같이 넣으면 닫힌다.** 그 폴더의 `02`와 `06`은 최종형에서도 유효한 측정이니(필드가 `Source`이고 `__store` 팬텀도 `keyof`/`index`도 없다) **재작성 때 버리지 말 것.** **⚠️ [2026-08-26 보강, 8라운드 `H-117`] `store:Of("k")`를 인스턴스화 없이 부르면 주석까지도 무력하다.** 위 실측 블록의 `local none: Source = s:Of("z")`가 `Source`이 된다는 것만 적혀 있었는데, `Source`은 **아무 구체 타입 주석과도 충돌하지 않는다** — 실측에서 `local d: Source = s:Of("dyn")`이 진단 0건으로 통과했다. 즉 *"`Of`는 타입 보장을 포기했다가 호출부에 드러나는 자리"*는 **`<>`를 실제로 적었을 때** 얘기고, 빠뜨리면 조용히 unsound하다(§1의 명시 바인딩 구멍과 같은 부류지만 자리가 다르다). ## Store가 Store를 저장 가능한가 사용자 원 메모: "슬롯을 스토어처럼 생각 가능하다면 이건 가능하다고 봐야하는가? 아니면 아예 다른 값으로 둬야 하는가? table/number 같은 프리미티브 타입이나 ref 타입처럼 생각하는 게 맞는 거 같음 — 그걸 처리하는 플러그를 만드는 걸로." **2026-08-04 6차 확정: 그런 경우는 없다고 본다.** "재실행 래핑으로 기계적으로는 커버 가능하다"는 제안은 메커니즘상 틀리지 않지만, 실제 설계 의도와 안 맞음 — Store는 Source에 준하는 존재로 모든 반응형 값의 "시작점" 역할만 함. 시작점은 다른 변화하는 무언가에 연결되는 것을 제공하고자 하지 않음(= Store가 다른 Store/State를 값으로 담아 자동으로 따라가게 하는 용도로 쓰지 않음). Store에서 값을 꺼내 State를 옵저빙하다가 콜백으로 다른 Store 값을 바꾸는 식의 수동 연결은 있을 수 있지만, 잘 짜인 UI에서 실사용 사례를 거의 보지 못했다는 게 사용자 판단 — 그래서 이 케이스를 위해 별도로 신경 쓰지 않음. **[2026-08-13 세션, 스코프 명확화, 같은 날 다섯 번째 세션에 결론 갱신]** 이 절은 "Store *필드*가 Store/State를 담는가"(예: `store.a = otherStore`) 얘기이고, "State가 *emit하는 값*이 State/Source인가"(`State>`, 예: `store.key`에 대입된 값 자체가 State)는 다른 축. 이 절의 "별도로 신경 쓰지 않음"(Store 필드 얘기)은 그대로 유지 — 후자(`State>`)는 한때 실제 체인 파손 버그로 확인돼 `Dispatch.process`가 명시적으로 error 하도록 막았었으나, 같은 날 다섯 번째 세션에 `chains`의 인덱스 기반 재설계로 그 버그의 근본 원인이 없어져 **지금은 정상 지원 대상** (`base/dispatch-core-plan.md`의 "Dispatch 체인" 절 참고 — 열네 번째 세션의 하강 diff로 깜빡임 방지 힌트까지 깊은 체인에서 유지됨) — "신경 안 씀"의 의미가 "조용히 UB"도 "즉시 실패"도 아니라 "그냥 정상적으로 동작함"으로 다시 한번 바뀜. **따라서 "Store가 Store를 담는 경우 이중 해제(double-dispose) 방지가 필요한가"라는 질문도 성립 안 함으로 종결** — 두 가지 독립적인 이유로 이중 해소됨. (1) 애초에 그런 경우를 만들지 않기로 확정(위 문단). (2) 설령 발생해도 State/Source 그래프 구독에 **명시적 `dispose()` 호출이 아예 없어서** (`base/lifecycle-pattern.md`의 GC 위임 원칙 재사용) "같은 걸 두 번 해제"할 행위 자체가 존재하지 않음(GC는 멱등). > **⚠️ [근거 정정, 2026-08-24 6라운드 손 트레이싱 `H-36`]** 위 (2)번은 원래 > *"그래프 구독이 **전부** weak-keyed GC-native"*라고 적혀 있었다. 그 명제는 > `base/source-state-plan.md`가 **스스로 미확정이라고 선언한 항목**(중간 > State가 살아남는가 — 구독 엣지의 방향성, 상류가 strong인지 weak인지)이라 > 근거로 쓸 수 없다. 사용자가 지목한 해법 방향("하류로 weak, 상류로 strong") > 으로 닫히면 그래프는 더 이상 "전부 weak"가 아니게 된다. > **결론(이중 해제 불가)은 안 뒤집힌다** — (1)번만으로도 성립하고, (2)번도 > "해제 호출 자체가 없다"로 다시 쓰면 방향성과 무관하게 참이다. 그 미해결이 > 닫힐 때 이 문단을 같이 훑을 것. ## Store가 담을 수 없는 값 — Modifier `Store`/`Source`의 `T`는 Modifier가 될 수 없음(런타임 `error`) — 근거와 검사 지점은 `base/source-state-plan.md`의 "따름정리" 절이 소스. ## 여러 스토어 값을 묶어 처리하는 것 (dependency array) — 확정 `useEffect`처럼 여러 store 값을 디펜던시로 묶어 파생값을 계산하고 싶다는 요구는 `:With(...)`로 의존성을 모으고 `:Compute(fn)`으로 파생 State를 만드는 것으로 확정 — `Store.Combine({a,b}, fn)`류 포지셔널 인자 방식은 기각됨. 정확한 lazy 인자 규칙(self/with 값 둘 다 State 핸들로 넘기고 `:Get()`을 실제로 읽을 때만 계산), v1 `myStore "a,b"` 콤마-조인 문자열 방식의 폐기, 여러 값을 한 번에 바꿀 때 재계산을 한 번으로 묶는 `Blocker` 연결은 전부 `base/source-state-plan.md`의 "여러 값을 묶어 파생값 만들기" 절이 소스.