# 2026-08-31-01 — 체크포인트 재개: 단위 2 `/code-review high` 완주와 반영 ## 맥락 2026-08-29 아침 체크포인트(`session/2026-08-28-03-m2-unit1-common-base.md` 마지막 절)의 재개 지점 둘 중, 사용자가 *"미완인 것 먼저 처리해줘"*로 (2) 단위 2 파일 리뷰를 먼저 지시했다. §4 문항 여섯(`H-182`~`H-187`)의 회신은 이 세션 시작 시점에 아직 없음. 부수 결정 하나 — 사용자: *"이건 pre-implementation 은 아닌듯 하네, 이름은 나중에 바꾸자"*. `pre-implementation-handtrace-round11*.md`는 구현 **중** 발견 문서라 이름이 안 맞는다는 것. **이름 변경은 §4 회신 처리 뒤로 미룸**(문항지·brief와 인용처를 한꺼번에 옮겨야 해서) — 아직 안 했고, 잊지 말 것. ## 포크 조기 반환과 재개 `/code-review high` + 경로 넷(`EpochMap`/`Source`/`State`/`Store`)으로 실행. 체크포인트가 기록한 실패 모드(하위 탐색자 완료 전 포크 조기 반환)가 **이번에도 재현**됐다 — 첫 notification 시점에 파인더 4개가 미완인 채 멈춤. 이번엔 opus 대체가 아니라 **`SendMessage`로 포크를 재개**(나머지 파인더 수거 → dedup → 검증 → `ReportFindings`까지 끝내고 턴을 닫으라고 명시)했고, 그걸로 완주했다. 다음에 같은 패턴이 나오면 이 방법을 먼저 쓸 것 — 재실행보다 싸고(이미 돈 파인더 결과를 버리지 않음) 잘 듣는다. ## 결과 — 8각도, 후보 22 → 검증 생존 10 정확성 8건 전부 실제 코드에 재현 스크립트로 확인. 효율 배치는 리뷰 스스로 "관측된 병목에만 구조" 원칙 위반으로 기각, 약한 정리 항목들은 심각도 미달 기각. 발견 상세와 처리의 소스는 `qa-request/pre-implementation-handtrace-round11.md`(요약 표 `H-198`~`H-207`, 상세 절 "단위 2 — `/code-review high`") — 여기선 갈래만: - **① 여섯**(같은 커밋에서 반영): `H-199`(nil dep 조용한 탈락 — `collectDeps` + error), `H-201`(`Of` 이름 문자열 검증), `H-202`(`Compute` fn 검증), `H-204`(`defaults` 평범한 테이블 검증), `H-206`(`implsOf` 세 벌 → `ImplRegistry.luau` 신설), `H-207`(`Source.Set`이 `Emit` 꼬리 위임). 검증 셋은 `H-190`·단위 3 `fn` 검사와 같은 급(형제 검증과 동급), 중복 제거 둘은 conventions 설계 원칙의 공유 허용 범위(데이터/순수 접근, 같은 타입). - **② 넷**(§4 문항 + `TODO` 마커): `H-198` 🔴(닫힌 게이트 너머 `fn` 도중 `Set` → 영구 stale 캐시 — **`state-epoch-plan.md` §4 확정 의사코드 자체의 구멍**, `H-85`와 같은 실패 계열의 게이트 경유 변형), `H-200`(`Gate` setup throw 좀비 노드 — 예외 계약 UB냐 `H-188` 연장이냐), `H-203`(`Blocker:Off` 순회 중 재차단 무시 — 탐사자는 §5에서 미지원 연장으로 봤고 리뷰는 `IsOn` 불변식 위반으로 봄), `H-205`(Modifier 가드 level — lazy 체인이라 어떤 고정 level도 항상은 유저 코드에 못 닿음). 리뷰가 확인한 "이상 없음" 목록과 기각 중 기록할 것 하나(Effect `Ref` dep의 생성 중 `onRefFire` 즉시 발화 — 신선한 Effect는 `canExecute` 거짓이라 실패 불가)는 round11.md의 "단위 2 리뷰가 이상 없다고 확인한 것" 절로. ## 이 시점 상태 `./scripts/test.sh` 전부 통과(`spec.state` 13절·`spec.store` 2·3절에 새 가드 테스트 추가), `luau-analyze` 진단 0, 코드 마커 `TODO(H-)` 열 개 = §4 문항 열 개와 1:1. **재개 지점은 §4 배치 회신 하나로 줄었다**(여섯 + 이번 넷). M2 종료 보고는 그 회신 처리 뒤. ## 같은 날 후속 — §4 배치 회신 1차 처리 (2026-08-31) 사용자가 §4 열 문항(+ 앞 라운드 셋 재확인)을 자유서술로 회신. 갈래: **확정 일곱** (`H-182` (a)+`_dying` 네이밍 / `H-183` (a) Observer `_running` / `H-184` (a) `_assertBindable` 커밋 전 문의 / `H-185` 권고 기각 — 단일 cleanup 문서화 / `H-187` (a) / `H-200` (b) detach-중-setup / `H-203` (a) 순회 중 `IsBlocked` 재확인), **재질문 둘**(`H-186` — "새 메커니즘 불가피하지 않나?", `H-198` — 재시작 루프 대안), **보류 하나**(`H-205`). 인용 원문과 반영 위치는 `round11.md` §4의 "[2026-08-31 회신 2]" 블록이 소스. 구현 요지: `Effect._dying`(Destroying 콜백이 세움, 재바인드·`Subscribe`류가 내림 — 죽은 바인딩 재사용 계약과의 충돌 때문에 재무장 자리가 셋), Observer `_running` (모든 fn 실행 둘레 + 네 진입점 첫 줄, error 시 잔류는 설계상 인정), 공통 훅 `_assertBindable`(mock bindLifetime이 커밋 전 문의 — `H-147` 가드는 `_bindDestroying` 첫 줄에서 이 훅으로 이동, level 3), Gate 생성이 setup 동안 `_subs`에서 떼었다 성공 후 재등록, `Blocker.runHandles`가 핸들마다 `IsBlocked` 재확인. 문서는 `effect-plan`/ `lifecycle-pattern`/`source-state-plan`/`gate-plan`/`blocker-plan`/`ref-plan`(+ `documentation-content-map` 22번, `quad-types-plan` `H-187`)에 반영. 스펙 넷 추가 (`spec.effect` 10 / `spec.observer` 9 / `spec.gate` 1 확장 / `spec.blocker` 8). 코드 마커는 셋 남음(`H-186`/`H-198`/`H-205`). `H-186` 답변(메인): 비교 자체는 메타테이블 신원(임플 테이블 = `module._impl` 경유)으로 새 per-노드 등록 없이 가능하나 어쨌든 형제 임플 노출이 필요하고, §6 이웃(교차 `bindLifetime`)은 그걸로도 못 막음 — (b) UB 문서화를 권고로 되돌림. `H-198` 답변(메인): 재시작 루프는 성립하되 게이트 너머 움직임의 탐지는 결국 fn 직전 스냅샷 비교로 귀결 — 사용자 안 = 스냅샷 탐지 + `Get` 재시작 루프, 캐비엇은 자기-dep `Set`의 무한 재시작 (UB로 접을지 함께 결정 필요).