qwreey
7f5868302e
Q4 EffectHandle 네 진입점 의사코드(Observer 것 재사용, Unsubscribe만 게이트 통과 뒤 cleanup) / Q5 M2 공통 기반에 Ref 최소형(+ Quad.Ref 필드) / Q6 WeakUnsubscribe 관대 명문화 / Q7 폐기 블록 archive/effect-internal-observer-cascade-reversed.md / Q8 InstanceChildHandler 부기(Parent → setLength(1), retractor는 Parent=nil → 해제) / Q9 문항 전제 정정 — Tween 절 스케치 hint==nil 줄은 복사 오류, retractor는 function() end / Q10 :List reconcile 재실행도 배치 Blocker(ownsGate — 네스팅 불가) / H-138 숏핸드 우선순위 > PropertyHandler, 충돌 방지는 UI 접두어 / H-139 New(name)(props)·Dispatch.drive 파이프라인 의사코드(bind-system-plan) — 쓰면서 빈 배열 파트 가드와 H-142 발견 / H-142 props에 Parent 금지(부모가 하는 일) — 순서 문제 소멸, D·Modifier 타입 제외 + PropertyHandler 거부(배선은 에이전트 선택으로 갈라 적음). H-129/H-131 정정. 감사 8라운드(5→3→4→5→3→1→3→1) — 1라운드가 drive 의사코드의 H-17 위반(post-pass 포함 전체 감쌈)을 잡음, 이후는 기록 문서 표기. /code-review high 10건 — 여섯 반영(그중 셋이 이 세션의 H-134 반영이 만든 것), 넷은 새 메커니즘이라 문항 H-143~H-146으로(question.md 최우선 절). doc-check ERROR 0. Claude-Session: https://claude.ai/code/session_01546hjsYNLSMZdHdPyTZaGb Co-authored-by: qwreey <me@qwreey.moe>
5.6 KiB
5.6 KiB
2026-08-27 — 9라운드 Q4~Q10 결정·반영 + H-138/H-139/H-142
무엇을 했나: 앞 세션(session/2026-08-27-01-handtrace-round9-q1-q3.md)이
Q1Q3까지 반영하고 남긴 Q4Q10을 사용자와 두 턴으로 처리해 base/·ROADMAP.md에
반영했다. 결정의 소스는 qa-request/pre-implementation-handtrace-round9-followup.md
(사용자 회신 원문 두 개도 거기 인용). 여기는 흐름과, 문서에 안 들어간 시행착오.
흐름
- 판단 불필요한
H-129(ROADMAP:Callback잔재)·H-131(*"for d in seen은 죽는다"*는 거짓)을 먼저 닫고 Q4~Q10 + 🟢 둘(H-138/H-139)을 갈래·권고와 함께 한 번에 올렸다. - 사용자 1차 회신 — Q4/Q5/Q8/Q10 권고대로, Q6 (a)(약한 홀드를 강제하지 않으므로),
Q7 (b)(컨벤션대로
archive/), Q9는 "뭔가 이상한데?" — 문항의 전제를 정정.H-138은 숏핸드 우선순위가 높다(역방향 의존 논거 +UI접두어의 역할),H-139는 "실 구현 전에 의사코드를 써보자 … 감추어졌던 설계 결함이나 폭탄이 발견된 경우가 많아서". - Q9 재고: 두 "확정"이 경쟁하는 게 아니라 Tween 절 스케치의
hint == nil줄이v == nil규칙의 복사 오류였고, 내가 (B) 분기의 "트윈이 끊긴다"를 피해로 든 것이 틀렸다(자식 파괴가 트윈을 지우는 건 당연). 파괴 경로는process(nil)하나. 사용자 확인("9 맞음 … 우린 파괴에 대해서 retract 안하던게 맞아서"). H-139파이프라인 의사코드(New①④ +(c))를 쓰면서 셋이 드러났다 — 배치 닫는 자리 미정(루프 뒤로), 자식 없는 Instance의 eager Blocker/drive(a)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-checkERROR — 한 줄로 합쳤다(conventions.md의 blockquote 주의와 같은 부류, 코드 주석도 마찬가지).
감사 루프와 code-review
quad-doc-auditor8라운드(5→3→4→5→3→1→3→1, 각도:base/정합성 → 인덱스 레이어 → 주변 폴더·인용문 역방향 → 수정분·발견/결정 문서 내부 → 델타 밖base/→ 신설 규칙 vs 기존 규정 → 세션 기록 사실성 → 7라운드 수정분). 단조 수렴은 아니었지만 1라운드(H-17) 이후 설계 내용 발견은 0이고 나머지는 기록 문서 표기라 8라운드에서 멈추고 code-review로 넘어갔다(처분 표는 followup 끝)./code-review high10건 — 여섯 반영(InstanceChildHandlerretractor의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.