# `Gate` — emit을 가로채는 게이트 노드 (2026-08-21 확정) **상태**: **표면 확정.** `Blocker`/`Debounce`/`Throttle`이 공유하는 게이팅 메커니즘을 `state:Gate(setup)` **메소드**로 확정했다 — *"Gate 는 따로 프리미티브 없이 `state:Gate( (emit) -> ()->() )` 처럼 선언되고 마치 Compute 처럼 GateNode(ComputeNode 처럼) 생성된다 그리고 Blocker 는 해당 내부 배선을 따른다 ← 동의합니다 해당 방법대로 확정하면 됩니다."* 구현은 **M2**(반응형 코어 — **[2026-08-24 정정]** 2026-08-22에 디스패치 쪽으로 앞당겼다가 마일스톤 순서 교체로 되돌아옴, `ROADMAP.md`). **남은 것은 아래 "아직 안 정한 것"의 생명주기와 마일스톤 범위뿐이고, 둘 다 구현 시 정하면 되는 것들이다 — 사용자 판단이 필요한 항목은 없다** — `/code-review high`가 잡았던 4번(유보된 emit이 싣는 출처)은 같은 날 흡수 집합으로 닫혔고, **`setup` 시그니처는 안 바뀌었다.** (**[2026-08-22 표기 정정]** 여기와 4번 제목에 `emit(self)`라 적혀 있었으나 그건 `Epoch` 일반화 **이전** 표기다 — 지금 싣는 건 떼어낸 `EpochSet` 스냅샷이고 게이트 노드 자신은 안 싣는다, 바로 아래 ⚠️ 문단이 소스.) **⚠️ 처음 방향이 한 번 바뀌었다.** 신설 당시엔 *"공용 `Gate` 프리미티브를 꺼내고 `Blocker`가 그걸 컴포지션한다"*였는데, 확정된 형태는 **프리미티브를 따로 안 만들고 State 메소드 하나로 끝낸다**이다 — *"Gate 프리미티브를 만들고 Blocker 가 컴포지션 하는걸 생각했는데, 그럴 필요가 없네요. `:Gate` 는 또 Apply 에서 쓸만한 표면을 주기도 하구요."* 아래 본문 중 "공개 프리미티브로 꺼낸다"류 서술은 그 이전 시점 표현이니 이 배너 기준으로 읽을 것. **⚠️ [2026-08-21 반영 완료] emit 페이로드는 `Epoch | EpochSet`이다** (`EpochSet = { [Epoch]: true }` — **배열이 아니라 집합**, `base/state-epoch-plan.md` §3) — 하류가 게이트 identity를 한 번도 안 쓰므로 게이트 노드 자체는 안 싣고 **떼어낸 `Epoch` 집합 스냅샷**만 넘긴다(근거 기록은 `reference/epoch-brand-composition.md`). 아래 4번의 기제(흡수 집합, flush 시 스왑, 게이트-게이트 unfold, 빈 배치 무통지)는 그대로다. **한 줄**: `Blocker`가 쓰던 "게이티드 State 노드"를 한 겹 일반화해서, **상류 emit을 가로채 내려보낼지 말지를 정책이 정하는** 노드를 **`state:Gate(setup)` 공개 메소드**로 낸다(탑레벨 생성자가 아니라 — 위 배너 참고). `Blocker`/`Debounce`/`Throttle`이 그 위에 얹히는 서로 다른 정책이 된다. ## 왜 지금인가 — 두 갈래가 같은 자리를 가리켰다 1. **`CR-3`(마일스톤 순서)** — `Dispatch.drive`의 배치 등록이 Blocker 게이팅을 전제하므로 M3가 M2의 `Blocker.luau`에 구조적으로 의존한다. 사용자 결정: **게이팅을 먼저 만든다.** (이건 그 결정에 이르게 된 *당시* 상태 서술이다 — **[2026-08-24] 지금은 `Blocker.luau`가 M2(반응형 코어)에 있고 그 M2가 먼저 지어진다**, 아래 9번. 2026-08-22에 잠깐 디스패치 쪽으로 옮겼던 것은 마일스톤 순서 교체로 되돌려졌다 — `state:Gate`가 State 메소드이고 `GateNode`/`Blocker`가 State 위에 얹히는 이상 게이팅을 State보다 먼저 둘 수는 없었고, 그래서 **반응형 전체를 앞으로 옮기는** 쪽으로 풀렸다.) 2. **`DT-4`(Debounce/Throttle)** — 공개 `Blocker` API 위에는 시간 기반 게이트를 못 얹는다. `base/debounce-throttle-plan.md`가 이미 "게이티드 노드를 내부 공용 `Gate`로 일반화하고 그 위에 정책을 얹으라"고 권고해뒀고, Blocker를 만들 때 같이 해두지 않으면 같은 설계를 두 번 하게 된다(항목 1과 마찬가지로 **당시** 서술은 "반응형 마일스톤에서 Blocker를 만들 때"였다 — **[2026-08-24]** 지금은 `Blocker.luau`도 M2다, 아래 9번). **사용자 논거(`DT-4`)** — Blocker + Observer 조합으로는 왜 안 되는가: *"스로틀/디바운싱에 Observer 를 걸어야하는데, 이 옵저버의 emit 이 먼저이냐 후행 Blocker 로 생성된 요소의 emit 이 먼저이냐가 문제되기 때문에 Blocker/Observer 가지고는 구현 못 한다. 순서를 보존해야한다는 전재가 생기는데 중간이 비어 해시가 되면 이를 전혀 못 지키기 때문."* → 게이트가 **emit 경로 자체에 끼어들어야** 하고, 바깥에서 관측만 해서는 순서를 보장할 수 없다. **공개 여부**: 사용자 판단 — *"이 API가 비공개일 이유는 없어보인다."* 즉 내부 배관이 아니라 **공개 표면**으로 낸다. **[2026-08-21]** 다만 그 표면은 탑레벨 프리미티브가 아니라 **State 메소드 `:Gate`** 다(아래 2번). ## 제안된 모양 (사용자 스케치 그대로) ```lua Gate(function(emit) -- 이 `emit`은 setup 밖으로 캡처해 **언제든** 부를 수 있다(타이머 콜백 등). return function() -- 상류 emit이 도착할 때마다 호출된다. -- 여기서 `emit()`을 부를지 말지는 정책 마음. end end) ``` - `setup(emit) -> onUpstreamEmit` 2단 구조. 바깥 함수는 게이트 인스턴스가 만들어질 때 1회, 반환된 함수는 상류 emit마다. - `Blocker`는 이 위의 정책 하나가 된다 — "켜져 있으면 `emit()`을 안 부르고 플래그만 세워두고, 꺼질 때 한 번 부른다"(`HasBlockedEmit`이 그 플래그). - `Debounce`/`Throttle`도 정책 — 타이머를 걸고 창이 끝날 때 `emit()`. ## 아직 안 정한 것 (사용자 판단 필요) 1. **[2026-08-21 해소] 이름 — `Gate`.** 원래 걸림돌은 *"프리미티브 명을 Gater? 뭔가 이상하게 들어간다"*였는데, **탑레벨 프리미티브를 안 만들기로 하면서 문제 자체가 사라졌다** — 이름이 놓이는 자리가 `Blocker()` 같은 생성자가 아니라 `state:Gate(...)` **메소드**이고, 메소드 자리에서 `Gate`는 `:With`/`:Compute`/`:Observer`와 나란히 자연스럽다. 노드 타입 이름은 `ComputeNode`와 짝을 맞춘 **`GateNode`**. 2. **[2026-08-21 해소] `:Apply`가 아니라 State의 메소드다 — `state:Gate(setup)`.** **확정 형태**: ```lua -- setup: (emit: () -> ()) -> (onUpstreamEmit: () -> ()) local gated = state:Gate(setup) -- ComputeNode처럼 GateNode를 하나 만든다 ``` `Blocker`는 **그 위에 얹히는 별개 프리미티브**로, `state:Block(blocker)`가 내부에서 이 배선을 그대로 쓴다. 탑레벨 `Gate(...)` 생성자는 **안 만든다.** `:Gate`가 메소드라고 `:Apply`와 배타적인 것도 아니다 — 사용자 지적대로 *"`:Gate` 는 또 Apply 에서 쓸만한 표면을 주기도"* 하므로, `Debounce{...}` 같은 유저랜드 팩토리가 내부에서 `s:Gate(policy)`를 부르는 형태로 `state:Apply(Debounce{...})` 관용구가 그대로 성립한다. **사용자 확정**: *"gate 는 apply 불가하다고 판단함. 순수 슈가가 아니기 때문, state 의 전파를 손대는 작업이라 with 처럼 다른 노드가 나는게 맞음."* - **정확한 경계**: `Apply`는 `factory(self)`일 뿐이라(`base/source-state-plan.md`의 "`state:Apply(factory)`" 절) 팩토리가 노드를 만드는 것 **자체는** 금지가 아니다 — 확정 예시의 `capAt(100)`도 `:With` 노드를 만든다. 갈리는 지점은 **누가 프리미티브인가**다: `:With`/`:Compute`처럼 **전파 경로에 새 종류의 노드를 끼우는 것은 State의 메소드**, 그 프리미티브들을 조합한 **유저랜드 팩토리는 `:Apply`**. `Gate`는 전자다. - **그래서 `Debounce`/`Throttle`은 `:Apply` 그대로 둔다** — `Debounce{...}`가 돌려주는 팩토리가 내부에서 `s:Gate(policy)`를 부르면 되므로 `base/debounce-throttle-plan.md`의 확정 관용구는 안 건드려도 된다. - **`Blocker` 배선 문제도 같이 사라진다.** `base/blocker-plan.md`가 이미 **`state:Block(blocker) -> state`(새 gated state 반환)** 라는 **메소드**로 확정해뒀으므로, `Block`이 내부에서 `self:Gate(blocker의 정책)`을 부르는 것으로 끝난다 — `blocker` 객체를 `Apply`에 넘길 일이 없다. - **`__call`은 안 쓴다.** 사용자도 *"이상적이여 보이지는 않음"*이라 했고, 타입 쪽 근거가 하나 더 있다 — `__call` 테이블이 Luau에서 `(State) -> U` 함수 타입 자리에 그대로 들어가는지가 불확실하다(들어가지 않는 쪽이 유력). `Apply`를 쓸 이유 자체가 없어졌으므로 확인할 필요도 없어졌지만, 혹시 되살아나면 `luau-test` 스파이크 한 개로 판정할 것. - **2단 구조는 그대로 유효하다** — 사용자 관찰(*"Gate 의 callback 으로 얻어진 emit과, 리턴해낸 클로저가 호출되는걸로 배선은 가능"*) 대로, 바깥 함수가 **그 노드의 `emit`을 캡처**하고 반환 클로저가 상류 emit마다 정책을 태운다. `Blocker`처럼 **여러 노드가 공유하는 정책**은 공유 상태를 바깥 객체가 들고, 노드별 `emit`만 2단 구조로 받아 등록하면 된다. 3. **[2026-08-21 확정] `Get()`과의 관계 — 값이 아니라 통지만 막는다.** `Blocker`가 이미 그렇고(`base/blocker-plan.md`의 "`:Get()`엔 영향 없음"), `Debounce`/`Throttle`도 emit-gate로 확정돼 있어(`base/debounce-throttle-plan.md` §4) `Gate`도 같은 계약으로 통일한다. 공개 계약 문구: **"게이트를 통과하지 않은 값도 `:Get()`으로는 보인다."** `base/state-epoch-plan.md`가 이 계약에 **의존**한다 — 그 문서가 "게이트를 에포크 경계로 만드는" 대안을 기각한 이유가 정확히 이 계약을 뒤집지 않기 위해서다 — 그 문서 §8의 "기각된 대안 — 게이트를 에포크 경계로" 항목. 4. **[2026-08-21 해소] 게이트가 유보했다 내보내는 emit — 흡수 집합 스냅샷.** 문제는 실재했다: 확정 `setup`은 `(emit: () -> ()) -> (() -> ())`라 양쪽 다 출처를 안 받는데 `base/state-epoch-plan.md`의 수신 규칙은 전부 `[epoch]` 키로 판정하므로, `blocker:Off()`가 묶어뒀던 배치 emit이 아무 원천도 못 지목한 채 도착해 **하류에서 삼켜진다**(2026-08-21 `/code-review high` 발견). **확정 기제**(사용자 안, 에이전트가 냈던 (a) `nil` 전체 확인 / (b) 소스마다 개별 emit은 기각 — 각각 O(1) 판정을 깨거나 `Blocker`의 "정확히 1회"를 깬다): - `GateNode`가 **자기를 거쳐간 `Epoch` 집합**을 들고 있는다 — `withheld : { [epoch] : true }`, **weak key**(`EpochMap`과 같은 이유, `state-epoch-plan.md` §3). - **⭐ [2026-08-21 단순화] 통과와 유보를 구분하지 않는다.** 상류 emit이 오면 **정책을 실행하기 전에 무조건** 그 출처를 `withheld`에 넣고, 그 다음 정책을 실행한다. 정책이 `emit()`을 부르면 게이트가 하류에 전파하고, 안 부르면 집합에 그대로 쌓인다. - **⚠️ [2026-08-21 `/code-review high`] "무조건"은 *정책의 통과/유보와 무관하게*라는 뜻이지 *수신 규칙을 건너뛴다*는 뜻이 아니다.** 게이트도 평범한 노드처럼 `state-epoch-plan.md` §4의 규칙 1~3을 **먼저** 적용하고, 3번(둘 다 같음)으로 삼켜진 emit은 **정책도 안 돌고 집합에도 안 들어간다.** 안 그러면 다이아몬드(`A→B→G`, `A→C→G`)에서 `A:Set()` 한 번에 정책이 두 번 돌아, `Throttle`의 leading 통과 직후 두 번째 emit이 `pending`을 세워 **이미 전달한 변경에 대한 유령 trailing emit**이 나간다. - **⭐⭐ 정책이 받는 `emit`은 "이 값을 내보내라"가 아니라 "쌓인 걸 지금 흘려보내라"(flush)** — 페이로드를 정책이 정하지 않는다. 그래서 배치를 떼어내는 것도 **그 핸들 안**에서 일어난다. `base/debounce-throttle-plan.md`가 이미 같은 것을 `gate:passThrough()` ("invalid 세팅 + 아래로 1회 전파")로 부르고 있다. - **전파 페이로드는 `withheld` 자체가 아니라 flush 진입 시점에 떼어낸 스냅샷이다.** **[2026-08-21 정정]** 여기 한때 "전파가 반환된 뒤에 `table.clear`"라고 적었는데 그게 틀렸다 — 전파가 스택에 남아 있는 동안 제어가 같은 게이트로 되돌아오면(하류 Observer가 상류를 `:Set()`, `debounce-throttle-plan.md`의 `onWindowEnd` 주석이 이미 대비하는 경우) 중첩 flush의 `clear`가 돌아 **바깥 전파의 남은 갈래가 빈 집합**을 받는다. **모델이 아니라 그 의사코드가 문제였다** — `emit()`이 flush인 이상 들어가는 순간 떼어내는 게 원래 모양이고, 그러면 그 경로 자체가 없다: ``` local batch = self._withheld self._withheld = newWithheld() -- 새 테이블. clear가 아니다 emitDownstream(self, batch) -- 떼어낸 batch를 페이로드로 넘긴다 ``` **⚠️ [정정, 2026-08-24 6라운드 손 트레이싱 `H-9`] 그 새 테이블도 weak여야 한다.** 여기 원래 `self._withheld = {}`라고 적혀 있었는데, 그러면 위에서 **weak key로 확정한 집합이 첫 flush 스왑에서 평범한 테이블로 바뀐다** — 그 뒤로는 그 게이트가 죽은 `Epoch`를 붙잡을 수 있다. `OffWithoutEmit`의 스왑도 같다. `newWithheld()`(= `setmetatable({}, {__mode = "k"})`) 헬퍼 하나로 생성 지점을 통일한다. 하류가 순회하는 것은 `gate._withheld`가 아니라 **받은 `batch`** 다. 중첩 파동은 새 테이블에 쌓이므로 바깥 전파와 안 섞인다. 같은 리비전이 중첩으로 두 번 도달하는 경우는 애초에 문제가 아니다 — 하류 맵이 이미 최신이라 규칙 3으로 삼켜진다. - **그래서 게이트는 언제나 자기(와 그 배치)를 출처로 낸다** — 그냥 통과시킬 때도 상류 출처를 그대로 넘기지 않는다. 사용자: *"후행 노드들은 한개가 지연된거로 생각이 될 수 있겠지만, 사실 여기서 지연과 비지연을 구분할 이유가 없습니다."* 하류가 보는 차이는 집합의 원소가 하나냐 여럿이냐뿐이고 판정 규칙은 완전히 같다. - 하류가 **평범한 노드**면 그냥 `EpochMap:Update(batch)`가 집합을 순회하고, 하나라도 걸리면 **받은 배치를 그대로** 더 아래로 넘긴다 (`state-epoch-plan.md` §4 — 단일이든 집합이든 같은 규칙이다). - **⭐ [2026-08-21 신설] 하류가 또 다른 게이트면 — 받은 집합을 풀어 자기 `withheld`에 합친다.** 게이트가 게이트 emit을 받는 경우가 정의돼 있지 않던 구멍이었다(사용자 발견). **출처를 그대로 넘기면 안 된다** — 상류 게이트가 넘기는 배치는 **그 전파에만 쓰이는 일회성 스냅샷**이라, 하류 게이트가 그 참조만 들고 유보했다가 나중에 풀면 이미 지나간 배치를 내보내게 된다. 그래서 수신 시점에 **풀어서 옮겨 담아야** 한다: ``` -- 출처가 Epoch 하나면 그 하나를, 배치면 그 배치 전부를 편다 for epoch in unfold(from) do self._withheld[epoch] = true end -- 그 다음 평소대로 정책 실행 ``` 게이트가 몇 겹으로 겹쳐도 각 층이 자기 집합을 들고 있으므로 어느 층이 먼저 풀리든 정보가 안 샌다. - **게이트의 `emitEpochMap`은 수신 때가 아니라 실제로 전파할 때** 갱신한다 (집합 전체에 대해 한꺼번에, `:Sync(batch)`). **이건 `state-epoch-plan.md` §4 의사코드의 유일한 예외이고, 그 문서에 예외로 기록돼 있다.** 그래야 "내가 하류로 던진 리비전"이라는 맵의 뜻이 게이트에서도 참이 된다 — 유보 중 같은 리비전이 다른 경로로 또 오면 규칙 2로 걸려 정책을 한 번 더 태우는데, 이미 집합에 있으므로 무해하다. - **⭐ [2026-08-21 `/code-review high`] emit 없이 푸는 경로는 집합을 *버려야* 한다.** `blocker:OffWithoutEmit()`은 정의상 "밀린 전파를 버리며 끈다"(`base/blocker-plan.md`)이므로, 그 경로도 **`withheld`를 비운다** (전파는 안 하고 새 테이블로 스왑). 안 그러면 `Dispatch.drive`의 배치 게이팅이 매 프레임 `On()` → … → `OffWithoutEmit()`을 도는 동안 집합이 **단조 증가**하고, 나중에 아무 `Epoch`나 한 번 통과하는 순간 **버리기로 했던 옛 원천들이 같이 실려 나가** 하류가 폐기된 통지로 무효화된다. - 그렇게 비우고 나면 하류의 `emitEpochMap`은 뒤에 남지만, 그 `Epoch`의 다음 진짜 emit이 규칙 1/2로 걸려 **스스로 낫는다** — 별도 조치 불필요. **⭐ 그래서 `setup` 시그니처는 안 바뀐다.** 집합을 채우는 건 정책이 아니라 **노드**이고, 노드는 정책이 뭘 하는지 들여다볼 필요조차 없다(위 단순화). 정책은 소스를 몰라도 되고, `Throttle`처럼 나중에 타이머에서 `emit()`을 부르는 경우도 그대로 동작한다 — 그때 쌓여 있던 집합이 그대로 나간다. 5. **생명주기.** 게이트 노드가 잡는 자원(타이머/플래그)이 언제 죽는가 — 지금 설계대로면 다운스트림이 다 죽으면 GC(팩토리는 weak 추적, `debounce-throttle-plan.md` 5-4). **⭐ [2026-08-24 해소, 6라운드 손 트레이싱 `H-33`/`H-49`] `Gate` 노드엔 `Flush`/`Cancel` 같은 표면을 두지 않는다 — 정책이 `Blocker`를 조종한다.** 확정된 `state:Gate(setup)`는 **State 하나만** 돌려주고 노드 객체를 노출하지 않으므로, 제어 표면을 얹으려면 그 확정을 되돌려야 했다. 사용자 확정으로 방향이 반대로 잡혔다: - **`Blocker`가 자기 정책을 값으로 낸다 — `blocker:Policy(emit) -> onUpstreamEmit`.** `state:Block(b)`는 그 위의 얇은 래퍼가 된다. 노출되는 새 표면은 이 하나뿐이다. **⚠️ [2026-08-24 표기 정정, `/code-review high` 지적]** 여기 한때 `state:Gate(b:Policy)`라고 적었는데 **그건 문법 오류다**(인자 목록 없는 `b:Policy`). `b.Policy`로 고쳐도 **언바운드 메소드**라 `Gate`가 `setup(emit)`으로 부르면 `emit`이 `self` 자리에 들어가 정책의 `emit`이 `nil`이 된다. 정확한 형태는 클로저로 묶는 것이다: ```lua state:Block(b) == state:Gate(function(emit) return b:Policy(emit) end) ``` - **`Debounce`/`Throttle`은 `emit`을 아예 안 쥔다.** 자기 `Blocker`를 사적으로 하나 갖고 **언제 `On()`/`Off()`할지만** 정하며, 실제 발화/보류 판정은 전부 Blocker에 위임한다. 동기 실행이라 같은 호출 안에서 정책이 바꾼 Blocker 상태를 그 다음 줄의 `pass()`가 그대로 본다: ```lua state:Gate(function(emit) local b = Blocker() local pass = b:Policy(emit) -- 실제 emit/보류는 전부 여기 위임 return function() -- 상류 emit 도착 (동기) -- ...타이머 리셋 / b:On() / b:Off() 시점 판단만... pass() end end) ``` - **Blocker는 설정당 하나가 아니라 적용 핸들당 하나**다(사용자 지적) — `Debounce{...}` 커링 결과는 여러 곳에 적용될 수 있으므로 `Apply` 시점에 생성된다. - **`pending` 같은 정책 상태는 `HasBlockedEmit`으로 흡수한다** — "보류된 게 있는가"를 Blocker가 이미 들고 있으므로 중복 상태를 안 만든다. `Trailing = false`는 `OffWithoutEmit()`, `Flush`는 `Off()`로 매핑된다. - **정책 합성은 손으로 중첩한다** — `setup`이 곧 `(emit) -> onUpstreamEmit` 이라 그 자체가 합성 가능한 타입이다. `state:Gate(p1, p2, ...)` 같은 가변인자 슈가는 **두지 않는다**(누가 상류인지가 코드에 그대로 드러나는 편이 낫다). - **기각된 배선(기록)**: "블로커를 바깥에 중첩" (`blocker:Policy(debounceOnEmit)`)은 unblock 시 흘러나온 emit이 디바운스 창을 **새로 시작**시켜 창이 안 끝난다(사용자 지적). 6. **[2026-08-21 정리 — 열린 항목 아님] 재진입.** 여기 한때 *"`onUpstreamEmit` 안에서 같은 게이트의 `emit()`을 재귀적으로 부르는 경우"*라고 적혀 있었는데 **잘못 옮긴 서술이었다**(사용자 지적). `blocker-plan.md`의 "재진입(네스팅)" 절이 말하는 건 **같은 `Blocker` 인스턴스를 중첩해 `On()`/`Off()` 하는 것** 이고, 정책이 `emit()`을 호출하는 것과는 무관하다 — 애초에 정책이 flush를 부르는 건 재귀가 아니라 **평범한 통과 경로**다. 지금 계약은 셋으로 정리된다: - **끝나지 않는 되먹임은 UB.** `base/dispatch-core-plan.md`의 2026-08-04 확정 원칙 그대로 — *"일반적인 재진입/무한루프는 방어 안 함, provider/사용자 코드 버그로 간주"*. 게이트가 따로 가드를 두지 않는다. - **유한한 재진입은 지원한다.** 전파 도중 소비자가 동기적으로 상류를 `:Set()`하는 건 이미 대비된 경우이고(`debounce-throttle-plan.md`의 `onWindowEnd` 주석), 게이트 쪽에서 그걸 안전하게 만드는 장치가 위 4번의 **flush 진입 시 스왑**이다. - **같은 게이트/`Blocker` 인스턴스를 중첩해 쓰지 않는다** — `Blocker`의 기존 규칙이 그대로 적용된다(겹치는 배치는 새 인스턴스). 7. **[2026-08-21 해소] `Effect(fn, ...deps)`의 최초 1회 억제는 `Gate` 소비자가 **아니다**.** 한때 이 용례까지 게이트가 커버해야 한다고 적어뒀으나, 위 8번(빈 배치는 통지 안 함)으로 **성립하지 않는 게 확인됐다** — 설치 구간엔 어떤 `Set`도 안 일어나 쌓이는 소스가 없으므로 게이트가 내보낼 것 자체가 없다. `Effect`가 **자기 내부 플래그로** 설치 중 발화를 누르고 마지막에 한 번 직접 실행하면 되고, 새 메커니즘이 필요 없다. `base/effect-plan.md`의 그 항목에 달려 있던 "⚠️ `Gate` 설계에 딸려 있다"도 같이 해소됐다. 아래는 원 서술: 2026-08-21 5라운드 `C-6`에서 확정된 다중 의존성 `Effect`는, 의존성마다 구독을 걸면 각 구독의 "등록 즉시 1회 실행"이 N번 발화하므로 **설치 구간 동안 발화를 눌러뒀다가 마지막에 한 번만 실행**해야 한다(`base/effect-plan.md`의 그 절). 즉 `Gate`(또는 `Blocker`의 직접 사용)가 **"설치 구간을 감싸 최초 발화를 한 번으로 접는" 용례까지 커버해야** 한다 — 설계할 때 이 소비자를 같이 볼 것. 8. **[2026-08-21 해소] 소스 없는 emit(빈 배치) — 아무것도 안 한다.** `/code-review high`가 "정책이 상류 신호와 무관하게 flush를 부르면 빈 배치가 나가 하류가 조용히 삼킨다"를 문제로 제기했고, 에이전트는 "빈 배치 = 무조건 통지"를 권고했다. **사용자 기각**: > *"빈 배치면 이미 하류로 한번 다 던져서 더 던질게 없다는 의미입니다. 마치 > 두번 흘러들어온 같은 카운트의 emit 과 유사한데요. 그건 전파 안 합니다. … > 애초에 Gate 는 중간에 emit 을 할 수 있는 핸들을 노출하는, `Source:Emit` > 같은걸 주는 요소도 아니고, 쌓아두다 뒤로 넘기는건데, 쌓아둔것 자체가 > 없는데 뒤로 넘긴다는건 이상합니다."* **확정: `next(withheld) == nil`이면 통지 자체를 안 한다.** 그래야 다른 State와 동작이 같아진다 — 빈 배치를 흘리는 건 표면적으로 **State 중간에 `Source:Emit`을 추가하는 격**이고, `Gate`는 그런 요소가 아니다. - **새 규칙이 아니라 기존 계약의 일반화다.** `base/blocker-plan.md`는 이미 *"이미 `HasBlockedEmit`이 false면 `emit` 값과 무관하게 아무 것도 안 함 (idempotent)"*이라고 확정해뒀다 — 즉 `HasBlockedEmit`은 `next(withheld) ~= nil`의 특수형이다. `Debounce`/`Throttle`도 `if pending`일 때만 `passThrough()`를 부른다 (`base/debounce-throttle-plan.md`의 `onWindowEnd`). - **3번 항목의 "`emit`은 언제든 부를 수 있다"는 그대로 유효하다** — 언제 불러도 되지만, 쌓인 게 없으면 그 호출은 no-op이라는 뜻으로 읽는다. - **따름정리: `Effect(fn, ...deps)`의 설치 구간 억제는 `Gate` 소비자가 아니다** — 아래 7번 참고. 9. **마일스톤 범위 — [2026-08-24 재확정] `Gate`와 `Blocker` 둘 다 M2(반응형 코어)다.** `Dispatch.drive`의 배치 등록이 실제로 쓰는 건 `blocker:On()`/`OffWithoutEmit()`/`IsOn()`이므로(배치 게이팅 절) 최소한 그 세 메서드가 도는 형태까지는 M3(디스패치)가 요구한다. 2026-08-22엔 그래서 `EpochMap.luau`/`GateNode`/`Blocker.luau` 체크박스를 디스패치 쪽으로 **앞당겼는데**, 셋 다 State 위에 얹히는 이상 그걸로는 순환이 안 닫혔다 — 디스패치가 여전히 `Source.luau`/`State.luau`를 필요로 했다. **2026-08-24에 마일스톤 순서 자체를 교체**(반응형이 M2, 디스패치가 M3)해 그 앞당김은 되돌려졌고, 셋은 반응형 쪽으로 복귀했다. 결과적으로 "게이팅 먼저"는 그대로 지켜진다 — 게이팅이 디스패치보다 먼저 지어진다. `Blocker`는 `GateNode`를 다시 만들지 말고 그 위의 정책으로 얹을 것. ## 관련 문서 - `base/blocker-plan.md` — 현행 `Blocker` 확정(이 문서가 일반화하려는 대상). - `base/debounce-throttle-plan.md` — "공개 `Blocker` API 위엔 못 얹음" 절이 `Gate` 일반화를 처음 권고한 자리, 그리고 정책 쪽 설계 전량. - `base/dispatch-core-plan.md` — "배치 등록을 안전하게 만드는 Blocker 게이팅" 절이 M3가 실제로 요구하는 표면. - `ROADMAP.md` M2/M3.