research: Epoch/Brand 제안 — 사용자 회신으로 결정 4건 해소, 오버플로 근거 정정

- Brand.get 역조회는 불필요로 확정(코퍼스가 쓰는 건 전부 isX 멤버십 질문).
- "포함 관계가 생성자로 흩어진다"는 에이전트 착오라 철회 — 자기 등록이 여러
  브랜드 등록을 강제하지 않으므로 isRef = PreRefBrand:is(x) or ... 처럼
  predicate 합성으로 지금과 똑같이 한 곳에 쓸 수 있다.
- Epoch는 Source가 구조적으로 만족하는 것으로 확정(State를 만족하는 기존
  패턴과 같은 모양).
- 리비전 필드는 공개로 확정. 근거가 정확하다 — 비공개면 구조적 만족이 타입
  레벨에서 성립하지 않는다. Store와 달리 Source는 키가 사용자 것이 아니라
  예약 이름이 늘어도 무방. 이름은 코퍼스 PascalCase 관례를 따라 Revision
  (숫자안) 또는 Token(테이블안) 권고.
- 계약은 "직전 값과 다르다"만 요구(순서 비교는 규칙 어디에도 안 쓰임).
  ⚠️ 다만 "오버플로가 나든 이전값과 다르다"는 근거는 정정 — Luau 숫자는
  double이라 랩어라운드가 아니라 포화하고, 2^53에서 n+1 == n이 되어 보장이
  정확히 그 지점에서 깨진다. 도달 불가능해서 문제가 아닌 것이므로 근거를
  "도달 불가능"으로 적어둠.
- Brand 전환 범위/마일스톤 해소 — 커밋된 M1 코드는 Brand를 아직 안 쓴다
  (quad-base/src는 init/Relate/Debug뿐) 전환 비용은 문서뿐.

남은 열린 항목 셋: 숫자 리비전 vs 테이블 토큰(권고는 숫자 — 테이블은 Set
한 번마다 할당이라 매 프레임 Set하는 소스에서 GC 압력), State가 EpochMap을
둘 들고 :Sync가 필요한지, Observer 클로저 인자.

doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01TiW21rnti9SbLgF6twtn6D

.claude/README.md

@@ -86,7 +86,7 @@
 
 | 문서 | 내용 | 우선순위 |
 |---|---|---|
-| `epoch-brand-composition.md` | **[2026-08-21 신설]** 에포크 부기를 State에서 떼어내 `EpochMap`으로 컴포지션하고, emit 페이로드를 `Source` 대신 **`Epoch` 인터페이스**(`{Count: number}`, 그 자체로 키)로 일반화하며, 그걸 위해 `Brand`를 **인스턴스화 가능**하게(다중 태깅) 바꾸자는 사용자 제안. 발단은 다중 의존성 `Effect`에서 한 파동에 `fn`이 두 번 도는 갭 — `Effect`가 자기 `EpochMap`을 들면 닫힌다. 에이전트 평가: 방향 타당, 다만 `Brand.get` 역조회 상실과 서브타입 포함관계가 생성자로 흩어지는 대가가 있음. **결정 7건 열림** | 중 — M3(State) 전, `Brand` 부분은 M2 전 |
+| `epoch-brand-composition.md` | **[2026-08-21 신설]** 에포크 부기를 State에서 떼어내 `EpochMap`으로 컴포지션하고, emit 페이로드를 `Source` 대신 **`Epoch` 인터페이스**(`{Count: number}`, 그 자체로 키)로 일반화하며, 그걸 위해 `Brand`를 **인스턴스화 가능**하게(다중 태깅) 바꾸자는 사용자 제안. 발단은 다중 의존성 `Effect`에서 한 파동에 `fn`이 두 번 도는 갭 — `Effect`가 자기 `EpochMap`을 들면 닫힌다. 에이전트가 짚었던 대가 둘(`Brand.get` 역조회 상실 / 포함관계가 흩어짐)은 **같은 날 둘 다 해소**(전자는 필요 없고, 후자는 착오 — predicate 합성으로 그대로 쓰면 됨). `Epoch`는 `Source`가 구조적으로 만족하고 리비전 필드는 공개까지 확정. **남은 결정은 숫자 리비전 vs 테이블 토큰, State가 `EpochMap`을 둘 드는지, `Observer` 클로저 인자 셋** | 중 — M3(State) 전. `Brand` 전환은 M1 코드가 아직 `Brand`를 안 써서 문서 비용뿐 |
 | `debug-tooling-plan.md` | 실물 Instance→코드 위치 역추적 Studio 플러그인(`quad-debug`) — 채널 실현 가능성(BindableEvent/Function 크로스 컨텍스트)까지 실측 검증 완료, 세부 API 이름·구현만 남음 | 하 — 사용자가 "quad 개발 완료 전엔 착수 못 함"으로 직접 후순위 지정, base 설계 시 훅 확장 지점만 고려 |
 | `documentation-plan.md` | 문서 사이트 구조(초심자/api/심화/`quadnomicon` 4축, 백엔드별 트랙 분리) + UI 네이밍 컨벤션·Store 부작용 패턴·권장 이벤트 핸들링 3개 세부 문서 뼈대 | 하 — 착수 시점 미정, 구조/스코프만 합의된 상태 |
 | `documentation-content-map.md` | 위 4축에 실제로 뭘 채울지 `base/` 전체를 초심자/api/심화/skip으로 서베이한 콘텐츠 맵 — 초심자 core loop 목차 초안 포함 | 하 — 문서화 착수 시점의 목차/우선순위표로 쓸 것 |

.claude/research/epoch-brand-composition.md

@@ -1,7 +1,8 @@
 # `Epoch` 인터페이스 + `EpochMap` 컴포지션, 그리고 `Brand` 인스턴스화 (2026-08-21 신설)
 
-**상태**: research — **사용자 제안, 에이전트 평가 완료. 방향에는 동의하나
-아래 §4의 결정 항목들이 열려 있어 아직 아무것도 확정 안 함.**
+**상태**: research — **사용자 제안, 에이전트 평가 완료, [2026-08-21] 사용자
+회신으로 §4의 1·2·3·6·7이 닫힘. 남은 열린 항목은 4·5와 "리비전을 숫자로 둘지
+테이블로 둘지"뿐.** 그래도 `base/`엔 아직 아무것도 안 옮겼다.
 `base/state-epoch-plan.md`/`base/gate-plan.md`/`base/brand-plan.md`가 여전히
 정본이다. 발단은 "다중 의존성 `Effect`에서 한 파동에 `fn`이 두 번 도는" 갭
 (`base/effect-plan.md`의 다중 deps 절, 2026-08-21 대화에서 에이전트가 제기).
@@ -57,44 +58,71 @@
   (`isState = isSource(x) or Brand.get(x) == StateTag`)인데, 자기 등록
   방식이면 `StateBrand:is(x)` **한 번**으로 끝나 조회 수도 준다.
 
-## 3. 대가 — 잃는 것 하나는 명시해둘 것
+## 3. 대가 — [2026-08-21] 둘 다 사용자 회신으로 해소됨
 
-**`Brand.get(x)`의 역조회가 사라진다.** 현행 설계는 *"nil이면 quad가 모르는
-값"*이라는 성질과 "이 값이 대체 뭔가"를 한 번에 답하는 능력을 갖는데,
-브랜드별 레지스트리로 쪼개면 전 브랜드를 훑기 전엔 답을 못 한다.
+에이전트가 대가로 짚었던 둘은 **둘 다 실제 비용이 아니었다.**
 
-또 하나, `base/brand-plan.md`가 2026-08-09에 **의도적으로 설계한 성질**이
-흐려진다 — *"어느 predicate가 다른 predicate를 내포하는지(포함 관계의
-방향)가 코드 모양 자체에 드러나게 함"*. 자기 등록 방식에서는 그 포함 관계가
-각 타입의 **생성자에 흩어진다**(`PreRef` 생성자가 `RefBrand`에도 등록).
-"올바른 자리"라고 볼 수도 있지만, 한 곳에서 관계를 읽던 것은 못 하게 된다.
+- **`Brand.get(x)` 역조회 상실** — *"확실히 의미가 없어진것 같습니다 필요하진
+  않아요."* 코퍼스가 실제로 쓰는 건 전부 `isX` 형태의 멤버십 질문이고, "이
+  값이 대체 뭔가"를 되묻는 자리는 없다.
+- **"포함 관계가 코드 모양에 드러난다"는 성질이 흩어진다** — **에이전트 착오,
+  철회.** 사용자 지적: *"여전합니다. `PreRefBrand` 가 존재할테니. 거기에
+  `is()` 를 해서, 코드에 전부 드러나는거 똑같습니다."* 자기 등록 방식이
+  **여러 브랜드에 등록하기를 강제하는 게 아니므로**, 지금처럼 각 타입이
+  자기 브랜드에만 등록하고 포함 관계는 predicate 합성으로 한 곳에 쓰면 된다:
+  ```lua
+  local function isRef(x)
+      return PreRefBrand:is(x) or PostRefBrand:is(x) or RefBrand:is(x)
+  end
+  ```
+  `base/brand-plan.md`가 2026-08-09에 세운 성질이 그대로 유지된다.
 
-## 4. 결정이 필요한 것 (전부 열림)
+## 4. 결정 상태
 
-1. **`Epoch`를 `Source`가 구조적으로 만족하게 할 것인가, 별도 객체로 들 것인가.**
-   전자 권고 — `Source`가 `State`를 구조적으로 만족하는 기존 패턴과 같고,
-   후자면 그 Epoch 객체가 Source를 **되참조하면 안 된다**는 weak-key 제약이
-   하나 더 생긴다(`base/relate-plan.md`).
-2. **`Count`를 공개 필드로 낼 것인가.** `type Epoch = { Count: number }`를
-   인터페이스로 두면 `source.Count`가 사실상 공개 표면이 되고, `Source`에
-   예약 이름이 하나 는다.
-3. **`Epoch` 인터페이스의 계약** — 단조 증가만 요구하는가, 시작값/오버플로는
-   무엇으로 하는가. `Source:Set`/`:Emit` 외의 구현자가 지켜야 할 것.
-4. **State는 `EpochMap`을 **둘** 컴포지션하는가.** 지금 맵이 둘이므로
+1. **[해소] `Epoch`는 `Source`가 구조적으로 만족한다** — 사용자: *"전자를
+   처음부터 생각했고"*. `Source`가 `State`를 구조적으로 만족하는 기존 패턴과
+   같은 모양.
+2. **[해소] 리비전 필드는 공개로 둔다** — *"`Source` 는 예약 이름이 늘어나도
+   됩니다(store 아님) 그냥 공개 필드로 두는게 맞는게, 그래야 타입 상 `Source`
+   가 `Epoch`를 만족해요."* **근거가 정확하다** — 필드가 비공개면 구조적
+   만족이 타입 레벨에서 성립하지 않는다. `Store`와 달리 `Source`는 키가 사용자
+   것이 아니므로 예약 이름이 늘어도 충돌하지 않는다.
+   - **이름**: 사용자가 `Count` 대신 `token`/`revision` 제안. 공개 필드는
+     코퍼스 관례가 PascalCase(`Slot.Length`/`Slot.Offset`/`Ref.Value`/
+     `blocker.IsBlocked`)이므로 **`Revision`**(숫자안) 또는 **`Token`**
+     (테이블안)을 권고.
+3. **[해소] 계약은 "직전 값과 다르다"만 요구한다** — 순서 비교(`<`)는 지금
+   규칙 어디에도 안 쓰이고 전부 `==`/`~=`뿐이라, 단조 증가조차 계약으로는
+   과하다.
+   - **⚠️ 다만 사용자 근거 한 줄은 정정이 필요하다**: *"오버플로가 나든 뭐가
+     되든, 이전값과 다르다는 보장될거예요."* — Luau 숫자는 double이라
+     **랩어라운드가 아니라 포화**한다. `2^53`을 넘으면 `n + 1 == n`이 되어
+     **다르다는 보장이 정확히 그 지점에서 깨진다.** 실제로는 도달 불가능하고
+     (초당 100만 `Set`으로 285년), 그래서 **문제로 보지 않는다** — 근거만
+     "오버플로해도 다르다"가 아니라 **"도달 불가능하다"**로 적어둘 것.
+4. **[열림] 숫자 리비전 vs 테이블 토큰.** 사용자 대안: *"아니면 안전하게 그냥
+   테이블을 비교자로 씁시다. 별로 무겁지 않다고 보여요."* 비교가 identity
+   동등성이라 **기능적으로는 둘 다 성립한다.**
+   - **테이블**: 포화 문제 자체가 없음. 대신 **`Set` 한 번마다 테이블 하나를
+     할당**한다 — 트윈처럼 매 프레임 `Set`하는 소스가 여럿이면 GC 압력이
+     생긴다(quad는 GC-native 아키텍처라 이 축을 신경 써왔다).
+   - **숫자**: 할당 0, 비교도 더 쌈. 위험은 도달 불가능한 `2^53`뿐.
+   - **에이전트 권고: 숫자(`Revision`)**. 다만 이건 실측 없이도 판단 가능한
+     자리라 사용자 취향으로 정해도 무방.
+5. **[열림] State는 `EpochMap`을 둘 컴포지션하는가.** 지금 맵이 둘이므로
    자연스럽게는 `_valueEpochs`/`_emitEpochs` 두 인스턴스다. 그러면
-   `Update`만으로는 부족하고 **재계산 후 "읽은 것 전부 최신으로" 동기화하는
-   연산**(가칭 `:Sync`)이 하나 더 필요하다(`state-epoch-plan.md` §2의
+   `Update`만으론 부족하고 **재계산 후 "읽은 것 전부 최신으로" 동기화하는
+   연산**(가칭 `:Sync`)이 하나 더 필요하다(`base/state-epoch-plan.md` §2의
    재계산 규칙).
-5. **`Observer` 클로저 인자 추가** — 지금 계약은 *"값을 안 실어주는 구독"*
-   이라 인자가 없다. 출처를 넘기는 건 값이 아니라 메타데이터라 취지에는
-   안 어긋나지만, `base/source-state-plan.md`의 그 절과
-   `state:Observer()`(인자 없는 "항상 관측" 유틸)까지 같이 손봐야 한다.
-6. **`Brand` 전환 범위** — 인스턴스 브랜드로 전면 전환할지, `Brand.get`
-   역조회를 남긴 채 다중 태깅만 얹을지. `Brand`는 **이름 자체가 아직 용어
-   정리 대기**(`question.md` 1번)라 같이 정하는 게 낫다.
-7. **마일스톤** — `EpochMap`/`Epoch`는 M3(State 구현)에 걸리고, `Brand`
-   변경은 M2 이전 코드에도 영향이 있다(이미 커밋된 M1 코드가 `Brand`를
-   쓰는지 확인 필요).
+6. **[열림] `Observer` 클로저 인자 추가.** 지금 계약은 *"값을 안 실어주는
+   구독"*이라 인자가 없다. 출처를 넘기는 건 값이 아니라 메타데이터라 취지에는
+   안 어긋나지만, `base/source-state-plan.md`의 그 절과 인자 없는
+   `state:Observer()` 유틸까지 같이 손봐야 한다.
+7. **[해소] `Brand` 전환 범위와 마일스톤** — 역조회가 불필요하고 포함 관계
+   성질도 유지되므로 **인스턴스 브랜드로 전면 전환**이면 된다. **커밋된 M1
+   코드는 `Brand`를 아직 안 쓴다**(`quad-base/src`는 `init.luau`/`Relate.luau`/
+   `Debug`뿐, 2026-08-21 확인) — 전환 비용은 **문서뿐**이다. `Brand`라는 이름
+   자체는 여전히 용어 정리 대기(`question.md` 1번).
 
 ## 관련 문서