# 2026-08-27 — 9라운드 Q4~Q10 결정·반영 + `H-138`/`H-139`/`H-142` **무엇을 했나**: 앞 세션(`session/2026-08-27-01-handtrace-round9-q1-q3.md`)이 Q1~Q3까지 반영하고 남긴 Q4~Q10을 사용자와 두 턴으로 처리해 `base/`·`ROADMAP.md`에 반영했다. 결정의 소스는 `qa-request/pre-implementation-handtrace-round9-followup.md` (사용자 회신 원문 두 개도 거기 인용). 여기는 흐름과, 문서에 안 들어간 시행착오. ## 흐름 1. 판단 불필요한 `H-129`(ROADMAP `:Callback` 잔재)·`H-131`(*"`for d in seen`은 죽는다"*는 거짓)을 먼저 닫고 Q4~Q10 + 🟢 둘(`H-138`/`H-139`)을 갈래·권고와 함께 한 번에 올렸다. 2. 사용자 1차 회신 — Q4/Q5/Q8/Q10 권고대로, Q6 (a)(약한 홀드를 강제하지 않으므로), Q7 (b)(컨벤션대로 `archive/`), **Q9는 "뭔가 이상한데?"** — 문항의 전제를 정정. `H-138`은 숏핸드 우선순위가 높다(역방향 의존 논거 + `UI` 접두어의 역할), `H-139`는 *"실 구현 전에 의사코드를 써보자 … 감추어졌던 설계 결함이나 폭탄이 발견된 경우가 많아서"*. 3. Q9 재고: 두 "확정"이 경쟁하는 게 아니라 Tween 절 스케치의 `hint == nil` 줄이 `v == nil` 규칙의 **복사 오류**였고, 내가 (B) 분기의 "트윈이 끊긴다"를 피해로 든 것이 틀렸다(자식 파괴가 트윈을 지우는 건 당연). 파괴 경로는 `process(nil)` 하나. 사용자 확인(*"9 맞음 … 우린 파괴에 대해서 retract 안하던게 맞아서"*). 4. `H-139` 파이프라인 의사코드(`New` ①~④ + `drive` (a)~(c))를 쓰면서 셋이 드러났다 — 배치 닫는 자리 미정(루프 뒤로), 자식 없는 Instance의 eager Blocker/`bk`(`flattened[1] ~= nil` 가드), 해시 파트 `Parent` 순서(`H-142`). 사용자 2차 회신: 1·2 확인, **`H-142`는 순서가 아니라 키 금지**(*"Parent대입 자체가 오면 안 돼. 그건 부모에서 할 일이거든 … '외부에서 직접 Parent 설정해주지 말것' 을 해치는 요인"*). 2에 대한 의심(*"bk없는게 Slot 안에 멀쩡히 들어가는데 문제 없을까"*)은 호출부 전수로 확인 — owner 키는 코퍼스 전체에서 Slot 자신 또는 최상위 `inst`뿐이고 요소 Frame은 앵커(gchold)/요소로만 나온다, `bk.base`는 이미 걷어낸 필드, `getBookkeeping`은 lazy. ## 시행착오 (문서엔 결론만) - **Q9의 문항 자체가 잘못 세워져 있었다.** `H-135`는 "같은 문서의 두 확정이 갈린다"로 썼는데 실제론 한쪽이 그 절의 주제 밖 스케치 한 줄이었다. 그 줄을 "확정"으로 격상해 갈래를 만든 건 나였다 — 스케치 안의 코드 한 줄을 산문의 확정과 같은 무게로 읽지 말 것. - **`H-142`에서 제시한 세 갈래가 전부 틀린 축이었다.** 순서 (a)/(b)/(c)를 물었는데 답은 "그 키가 존재하면 안 된다"였다 — 증상(순서)에서 처방을 찾지 말고 그 키가 거기 있어야 하는지부터 물었어야 했다. 반영한 런타임 배선(`PropertyHandler`가 `"Parent"` 거부 → 기존 no-handler error)은 내 선택이라 문서에 갈라 적었다. - **Blocker 네스팅.** Q10을 반영하며 `reconcile`에 `blocker:On()`을 넣으려다 `blocker-plan.md`의 "네스팅 미지원(불리언)"에 걸렸다 — 최초 population은 바깥 배치 안에서 `reconcile`에 오므로 무조건 `On()`이면 안쪽이 먼저 꺼서 바깥 등록이 게이팅을 잃는다. `ownsGate = not blocker:IsOn()`으로 갈랐다. - **`H-17`을 못 보고 "배치 닫는 자리가 미정"이라고 써서 사용자 확인까지 받았다.** 감사 1라운드가 잡음 — `dispatch-core-plan.md`가 `drive` 전체(post-pass 포함)를 감싸고 `PostRef` 콜백이 게이트 안에서 돈다고 이미 계약해뒀다. 의사코드를 그대로 고쳤고 사용자 확인 1번은 무효로 표기. "어디에도 없다"는 주장은 grep 한 번이면 반증됐을 것 — 없다고 쓰기 전에 그 단어(`post-pass`)로 찾을 것. - 절 인용이 Lua 주석 두 줄에 걸쳐 `--` 마커가 인용문 안으로 들어가 `doc-check` ERROR — 한 줄로 합쳤다(`conventions.md`의 blockquote 주의와 같은 부류, 코드 주석도 마찬가지). ## 감사 루프와 code-review - `quad-doc-auditor` 8라운드(5→3→4→5→3→1→3→1, 각도: `base/` 정합성 → 인덱스 레이어 → 주변 폴더·인용문 역방향 → 수정분·발견/결정 문서 내부 → 델타 밖 `base/` → 신설 규칙 vs 기존 규정 → 세션 기록 사실성 → 7라운드 수정분). 단조 수렴은 아니었지만 1라운드(`H-17`) 이후 설계 내용 발견은 0이고 나머지는 기록 문서 표기라 8라운드에서 멈추고 code-review로 넘어갔다(처분 표는 followup 끝). - `/code-review high` 10건 — 여섯 반영(`InstanceChildHandler` retractor의 `Parent = nil`·순서·5번째 인자 / `H-17` 빈 배열 가드 / `Quad.Ref` 필드 M2 / Modifier 메소드 목록 `Parent` 제외 / `effect-plan` 목록 재정렬), **넷은 새 메커니즘이라 문항으로**(`H-143`~`H-146` — `fn` 안 `Unsubscribe` 고아 cleanup / 재`Subscribe` 재설치 / `indexOfElement` 잔존 / 루트 마운트 경로). 이번에도 **반영분 자체가 새 결함을 만든 것**(`H-134`의 순서와 5번째 인자 둘 다 내가 넣은 것)이 반복됐다 — `conventions.md`의 2026-08-26 실측 그대로. ## 남은 것 커밋, 그리고 `question.md` 최우선 절의 `H-143`~`H-146` 결정. M2 착수 게이트는 여전히 0.