quad/.claude/qa-request/pre-implementation-qa-round2.md

구현 전 QA 2라운드 — 의사코드 손 트레이싱

상태: 완료 — 핵심 발견(RC-1)까지 같은 날 후속 세션에서 해결· base/ 반영 완료. 1라운드는 "확정된 주장이 맞는가"를 물었을 뿐 의사코드를 실제로 실행해보진 않았음(pre-implementation-qa-round1.md 맨 아래 "진행 로그" 절). 2라운드는 그 갭을 메우는 작업 — base/slot-plan.md의 :List reconcile과 base/dispatch-core-plan.md의 recompute를 구체 시나리오로 직접 손으로 실행해보고, 부수로 reference/ 인용 정확성과 ROADMAP.md 마일스톤 정합성도 훑었다.

이 문서의 용도: 1라운드와 달리 "예/아니오 판정" 문항이 아니라 트레이싱 결과 자체가 산출물 — 버그를 찾으면 그 자리에서 기록하고, 방향이 갈리는 것만 사용자에게 물었다. 새로 발견된 결함은 RC-1 하나뿐이고, 나머지는 "트레이싱했지만 문제 없음 확인"으로 아래 각 절에 남긴다(재작업 방지용 기록 — conventions.md의 "작업이 끝나면(또는 방향이 바뀌면) 항상 자기 문서화" 원칙).

---

RC-1 — recompute의 트리거 모델 자체가 재검토 대상 ✅ 해결(2026-08-18 후속 세션)

판정: 트레이싱으로 실제 크래시 경로를 확인 — 사용자도 진단은 맞다고 동의했고, 같은 날 후속 대화에서 Blocker를 재사용하는 배치 게이팅 설계로 확정됐다(아래 "해결 — Blocker 게이팅" 절). 해법이 실제 반영된 곳은 base/dispatch-core-plan.md의 "배치 등록을 안전하게 만드는 Blocker 게이팅" 절, base/slot-plan.md의 "재귀 메커니즘" 절, base/blocker-plan.md의 "state:Apply(blocker) 없이 직접 쓰는 두 번째 용례"(2026-08-28 H-158로 개명 — 당시 이름은 state:Block()) 절 — 이 문서는 그 결론에 이르는 논의 원문만 보존한다.

발견한 크래시 경로

base/dispatch-core-plan.md의 "Length/Offset — 여러 Slot이 형제로 섞일 때 순서 보장" 절의 recompute 의사코드:

local function recompute(ownerKey, bk)
    local sum = 0
    for i = 1, bk.N do
        local offset = bk.sourceList[i]
        if offset ~= nil and offset ~= None and offset:Get() ~= sum then
            offset:Set(sum)
        end
        local v = bk.lengthList[i]
        sum += (if isState(v) then v:Get() else v)   -- ← v가 nil이면 여기서 산술 에러
    end
    ...
end

구체 시나리오 — Frame{A, B}(정적 자식 2개, 반응형 없음, N=2).

1. Dispatch.drive(inst, flattened)가 배열 파트를 순서대로 순회 — bk.N은 "그 inst의 array part 크기" 이므로 순회를 시작하는 시점에 이미 2로 정해져 있음(같은 절의 "저장 위치" 문단).
2. position 1(A)을 담당하는 말단 Handler가 Dispatch.setLength(inst,1,1)을 부름. setLength의 의사코드는 끝에서 무조건 recompute(inst,bk)를 호출(같은 절 "setLength 구현" 문단 — "등록 즉시 1회(Observer 자체의 '등록 즉시 1회 실행'과 겹쳐도 무해)").
3. 이 시점의 recompute 루프가 i=1..bk.N(=2)을 돎 — i=1은 bk.lengthList[1]=1이라 정상. i=2는 position 2(B)가 아직 처리되기 전이라 bk.lengthList[2]가 nil — sum += (if isState(v) then v:Get() else v)에서 sum += nil이 되어 산술 에러로 크래시.

sourceList(offset) 쪽은 같은 절에 이미 nil 가드가 있음("[방어, 2026-08-13 여섯 번째 세션] nil도 같이 배제") — lengthList 쪽엔 그 대칭 가드가 없다. 정적 자식 2개짜리 Frame처럼 가장 흔한 경우에서 바로 재현되는 경로라, 별도 Slot/반응형 값 없이도 걸림.

왜 지금까지 안 잡혔나

기존 luau-test/ 스파이크 중 이 함수를 다루는 건 done/20-slot-splice-index-arithmetic.luau 하나뿐인데, 이건 Splice의 순수 배열 인덱스 산술(제거/삽입 시 뒤 요소가 몇 칸 밀리는지)만 검증하고 Dispatch.drive가 여러 position을 순차 처리하며 bk.lengthList를 점진적으로 채우는 과정 자체는 다루지 않음 — 이 경로를 실행해본 스파이크가 없었다. 같은 함수의 다른 버그(offset이 자기 자신을 포함해 누적되던 off-by-one)는 2026-08-11 세션에 이미 한 번 발견·수정됐지만(같은 문서 "recompute — 매번 전체 순회" 문단), 이번 것은 그와 별개의 문제.

사용자 답변 원문 — 진단은 맞다고 확인, 그러나 더 큰 재설계 필요

setLength/setOffset 자체는 리레이아웃을 트리거하진 않아야한다고 생각함. 명시 리트리거를 해야하는게, 이러면 첫 실행에서 계속 recompute 비용이 쌓임. 옵져버 생성 시 클로저 위쪽에 init = true 두고 처리할 필요가 있는듯 하고, 각각의 process 가 setLength 를 나중에 수행했을 때는 recompute 를 어떻게 할지 생각해봐야할듯. 등록을 배치로 미룸은 맞는데, State<None|Slot> 이 오는건 어쩌냐를 잘 모르겠음. 각각 처음에 바운딩 할 땐 그럼 offset/length 어떻게 계산할지는 이것도 아직 모르겠음.. 생각을 더 해

애초에 열려 있던 세 갈래(사용자가 처음엔 하나로 안 좁힘) — (1) setLength/setOffsetSource 자체는 recompute를 트리거하지 않아야 한다(명시적 리트리거 필요), (2) 등록을 배치로 미루는 방향은 맞지만 State<Slot|None>처럼 값이 나중에 도착하는 경우를 어떻게 커버할지 불명, (3) 최초 바인딩 시점의 offset/length 계산 방식 자체가 안 잡힘 — 아래가 같은 날 후속 대화에서 이 세 갈래를 하나로 합친 결과다.

해결 — Blocker 게이팅 (2026-08-18, 같은 날 후속 세션)

사용자가 직접 제시한 설계 원문:

각각의 length 들을 그냥 받아서 바인딩 하는게 아니야. 각 Frame 에 대한 Blocker 를 릴레이션으로 가지고 있고 이건 드라이빙 함수가 실행될 때 생성돼. Offset/Length 소스가 설정 될 때, 특히 Length 에 있어서는 이 Frame->Blocker 로 있는걸 얻어와서 한번 적용하고 넣어둬. 그리고 Observer callback 에서도 Blocker 가 IsOn 상태면 무시해줘. 드라이브 함수가 실행되어 Blocker 가 생성될 때 기본으로 On 을 해줘. 이러면 length 가 변경되며 계속 recompute 되지 않아. 그런 다음 OffWithoutEmit 을 해. 맨 마지막으로 recompute 를 한번 하면 되는식이야.

다만, 이러면 초기에 레이아웃이 이상해져. 주의할 점은 setOffsetSource 를 하게 되면 이건 자기 자신 위쪽으로 있는 요소들의 length 를 합해서 설정해줘야할거야. 이건 첫 for 루프에서도 작동한다고 봄. 즉, 사실 첫 루프 상 recompute 자체는 필요 없어. 그리고 setOffsetSource 는 여전히 slot 의 실체화로 List 가 수행되기 전에 설정되어야하고, length 가 확정 된 다음에 다음 요소로 넘어가야해.

요지 두 갈래로 나뉜다:

1. recompute를 배치가 끝날 때까지 아예 안 돈다 — owner(inst 또는 Slot)마다 Relate로 들고 있는 전용 Blocker를 배치 시작 시 On, setLength의 Observer 콜백(등록 즉시 1회 실행 포함)이 blocker:IsOn()이면 recompute를 건너뜀. 배치가 끝나면 OffWithoutEmit() + 명시적 recompute 딱 1회.
2. setOffsetSource는 그 즉시 앞선 형제들의 길이 합을 직접 계산해 :Set한다 — recompute를 미루는 것만으로는 "초기 레이아웃이 이상해지는" 문제(배치 도중 :List가 실체화되며 옛/기본값 offset을 읽어버림)가 남기 때문에, offset 자체는 즉시 계산으로 옮겨 recompute를 기다리지 않게 함.

뒤이은 확인 질문 3개와 답변(AskUserQuestion, 같은 세션):

• 중첩된 Slot이 attachSlot을 재귀할 때도 각자 별도 Blocker가 필요한가? → "예 — 중첩마다 별도 Blocker (권장)" — base/blocker-plan.md의 재진입(네스팅) 미지원 규칙 그대로 적용.
• 런타임에 이미 마운트된 Slot에 한 번에 하나씩 :Add()하는 경우도 같은 위험이 있는가? → "그건 이미 마운트가 된 이후라서 별 상관 없음. 가장 큰 문제는 마운트 중간에 후행 nil 이 있는데 recompute 가 난다는게 문제... 정확한 내 의견은 이래: setLength 는 recompute 를 직접 수행하진 않고, Observer 에서 recompute 를 수행해. 맨 처음 emit 에서도 blocker 가 on 이면 무시하는식. 그럼에도 새로운 개체가 뒤에 붙는 현상에서는 위 요소들로 하여금 위치를 구하면 돼, 뒷 요소를 밀어내는게 아니라서, setLength 가 emit 되지 않는것에 영향 안 받고 수행 가능함" — 크래시는 오직 "N이 미리 정해진 채 배치로 등록"되는 두 자리(Dispatch.drive, attachSlot의 flush)에서만 나고, 런타임 단건 append는 이미 안정된 앞선 position만 참조하므로 무관함이 확정. setLength가 recompute를 직접 안 부르고 Observer 콜백(첫 실행 포함)만을 경유한다는 것도 이 답변에서 확정됨.
• IsOn/HasBlocked를 기존 IsBlocked/HasBlockedEmit과 어떻게 관계지을까? → "IsBlocked가 있다면 그냥 두어도 될듯 함. HasBlockedEmit 만 처리된다면 괜찮다 생각" — 기존 필드는 그대로 두고, IsOn()은 IsBlocked를 읽는 얇은 조회 메소드로만 추가. 처음 요청했던 HasBlocked(Blocker 자신의 새 최상위 플래그)는 신설하지 않음 — OffWithoutEmit()이 각 gated state의 기존 HasBlockedEmit을 그대로 리셋해주는 것으로 충분하다고 판단.

후속 정정 — attachSlot의 호출 순서가 뒤집혀 있었음 (같은 세션, RC-1 반영 직후)

위 설계를 attachSlot에 실제로 반영하는 과정에서 사용자가 직접 짚은 추가 결함: attachSlot의 기존 의사코드는 setLength를 먼저, setOffsetSource를 나중에 불렀는데, 이건 base/dispatch-core-plan.md의 "NilHandler" 절이 이미 확정해둔 "호출 순서는 setOffsetSource → setLength" 일반 규칙과 어긋나 있었다(RC-1로 setOffsetSource가 즉시 계산을 하게 되면서 이 불일치가 드러남 — 그 전엔 둘 다 recompute에 얹혀 있어서 순서가 겉으로 안 드러났었다). 사용자 확정 원문:

length 를 알게되는 시점은 각 요소가 생성된 이후인데, 그럼 setOffset 이 먼저 안 되어있으면 offset 전파가 한번 더 일어나게됨. 따라서 위가 맞음

즉 Slot의 진짜 .Length는 activateList가 자기 :List를 최초 reconcile한 뒤에야 확정되므로, 순서는 setOffsetSource(즉시 계산) → (Slot이면) activateList 실체화 → setLength(그제서야 확정된 값으로 등록) → 물리 마운트여야 한다 — setLength를 실체화 전에 부르면 등록 직후 값이 또 바뀌어 전파가 한 번 낭비된다. 평범한 Instance 요소도 같은 순서(setOffsetSource(None) → setLength(1) → Parent 대입)를 따르며, 이 경로는 기존 의사코드에 아예 안 보이던 것도 이번에 같이 채워짐.

부수 확정 — 코루틴 yield 금지 불변식. 사용자가 이 논의 말미에 지적:

모든 컴포넌트든 뭐든 yield 되면 안되는 sync 함수이여야 할듯. 안 그럼 꼬이는 문제가 발생하지 않나 생각함

이 배치 게이팅 전체가 "position이 항상 순서대로, 끼어드는 코드 없이 동기로 처리된다"는 전제 위에 있어서, Dispatch.process/attachSlot 호출 체인 도중 코루틴 yield가 끼면 같은 owner의 Blocker를 다른 코드가 그 사이에 건드릴 수 있다 — 명시적 불변식(UB 선언)으로 문서화하기로 확정.

반영된 곳:

• base/blocker-plan.md — IsOn()/OffWithoutEmit() 신설, onunblock 핸들이 emit: boolean을 받도록 변경, state:Block() 없이 직접 쓰는 용례 신설, 재진입 규칙에 이 용례의 실제 사례 추가.
• base/dispatch-core-plan.md — "Length/Offset" 절에 "배치 등록을 안전하게 만드는 Blocker 게이팅" 절 신설(setLength/setOffsetSource 재작성, Dispatch.drive도 자기 Blocker로 배열 파트 순회를 감쌈), 코루틴 yield 금지 불변식 추가.
• base/slot-plan.md — "재귀 메커니즘" 절의 attachSlot이 자기 flush 루프를 자기 자신의 Blocker로 감싸도록, 그리고 setOffsetSource→setLength 순서로 재작성(평범한 Instance 요소의 등록도 명시적으로 채움), 런타임 단건 Add 경로는 게이팅 불필요함을 명시.

---

SL — base/slot-plan.md의 :List reconcile 트레이싱 — 새 결함 없음, 기존 미해결 갭만 재확인

base/slot-plan.md의 "구현" 절(activateList/reconcile 의사코드)을 아래 시나리오로 손으로 실행:

• 재정렬([A,B,C] → [C,A,B], 값 동일) — pos/keyIndex 비교가 rawMove를 정확한 절대 위치로 호출, 정상.
• 키 제거([A,B,C] → [A,C]) — 소멸 루프가 keyIndex(직전 사이클 전체 key 집합)를 순회해 B를 rawRemove, 나머지 pos 압축도 정상.
• 필터 토글(updateFn이 특정 key에 nil 반환) — rawRemove(파괴) 경로를 타고, pos가 그 키만큼 증가 안 해 뒤 요소가 정상 압축됨.
• PopOnly 반환 후 재등장 — mounted[key]=nil이지만 userdata[key]가 {old=...}를 강하게 붙잡아 GC를 막고, 다음 사이클에 prev=nil로 받은 updateFn이 ud.old를 그대로 반환하면 rawAdd로 재마운트됨 — 문서 서술대로 정상 동작.
• nested Slot 반환(isSlot(result)) — pos = candidateIndex - 1 + result.Length:Get()으로 다음 형제의 위치가 정확히 밀림, ":List의 index도 nested-Slot 결과의 .Length만큼 건너뛰어야 함" 절의 결론과 일치.
• 중복 key — seen[key] 체크가 updateFn 호출 전에 있어 즉시 error, 상태 오염 없음.

PopOnly 홀드 중 키가 데이터에서 완전히 사라지는 경우만 트레이싱으로도 재현됨 — 소멸 루프가 mounted[key](이미 nil)만 보고 rawRemove를 건너뛰어, 그 요소가 파괴도 반환도 안 되고 참조만 끊겨 GC된다. 이건 이미 base/slot-plan.md의 "nil 리턴은 파괴가 기본" 절과 question.md 3번(PopOnly로 홀드 중이던 요소의 키가 사라지면 어떻게 처분하는가)이 알고 있는 미해결 갭 — 이번 트레이싱은 그 갭이 실제로 재현됨을 손으로 다시 확인했을 뿐, 새 발견이 아니다. 결론은 그대로 question.md 3번의 (a)/(b)/(c) 선택지에 맡긴다.

---

D — base/dispatch-core-plan.md의 하강 diff 재디스패치 트레이싱 — 문제 없음

"Dispatch 체인" 절의 Dispatch.process/Dispatch.retractFrom을 아래 시나리오로 트레이싱:

• 최초 마운트(store.key = a, a: State<Tag>) — StoreBind가 index=1을 잡고 a:Get()을 들고 Dispatch.process(inst,k,realv,2)를 재귀, chains에 [1]=StoreBind, [2]=TagHandler가 순서대로 쌓임. 정상.
• 같은 핸들러로 값 교체(a가 새 Tag를 내놓음) — Dispatch.process의 (A) 분기가 인덱스 2 슬롯의 기존 retractor에 새 값을 넘기고 클로저를 교체, 인덱스 1은 안 건드림. chains 구조·재귀 깊이 전부 문서 서술과 일치.
• State<State<Tag>> — 안쪽 재귀가 index+1이라는 별개 슬롯을 쓰므로 StoreBind 싱글톤이 같은 (inst,k)에 두 번 매치돼도 슬롯이 안 겹침 — "State<State<T>>는 정상 지원 대상" 절의 결론과 일치.

새로 발견된 문제 없음.

---

reference/ 인용 정확성 — 표본 점검, 불일치 없음

base/ 문서가 reference/quad-v1-architecture.md/reference/ comparison-fusion-vide.md를 인용하는 자리 중 표본 3곳을 원문과 대조:

• base/lifecycle-pattern.md가 v1의 GC 방지 핫팩을 인용한 자리 — 원문 (PropertyChangedSignal("ClassName")에 연결해 참조를 붙잡아두는 관용구)과 일치.
• base/slot-plan.md가 v1 mount.lua를 분석한 자리("부모/자식 부기까지 했지만 다중 마운트 방지는 없었음") — 원문(mount.lua는 실제로 부모/자식 부기(bookkeeping) + 라이프사이클 파괴까지 담당하는 무거운 모듈)과 정합(다중 마운트 방지 부재는 문서 전체 맥락상 타당한 요약).
• base/tween-plan.md가 Fusion의 Tween/Spring을 반면교사로 인용한 자리 — reference/comparison-fusion-vide.md의 해당 문구와 일치.

전수 대조는 아니고(reference/를 인용하는 자리 전체는 base/*.md에서 reference/로 grep한 결과 10여 곳 — 정확한 개수는 grep 결과 자체가 소스), 표본에서 불일치가 안 나와 전수 대조로 확장하지 않음.

ROADMAP.md 마일스톤 정합성 — 1라운드 반영분 확인, 불일치 없음

1라운드에서 뒤집힌 것 중 ROADMAP.md가 언급하는 것들이 갱신됐는지 확인: NilHandler/NoneHandler 분리([정정, 2026-08-18 /code-review high] M2가 아니라 M7 — Modifier 마일스톤에 체크박스가 있음, M2엔 서술 문단 안에서만 이름이 언급될 뿐 별도 체크리스트 항목이 없음), PopOnly 반환 경로(M6), store:GetDynamic 탑레벨/콜론 미정 표시(M3), DI→D 리네임(전역) — 전부 반영 확인됨. D-6(setLength/setOffsetSource 호출 책임자를 "처음 매치한 Handler"로 서술하던 옛 오류)의 흔적도 ROADMAP.md엔 없음(애초에 그 정도 구현 디테일은 base/만 갖고 있고 ROADMAP.md는 체크박스 수준이라 옮겨붙을 자리가 없었음).

---

[중간 상태 기록, Blocker 해법 확정 이전] 반영

⚠️ 이 절은 낡았다 — RC-1이 아직 "미해결"이던 시점(사용자가 "생각을 더 해"라며 방향을 안 정했을 때)에 세워둔 임시 조치 목록이다. 그 뒤 같은 세션 후속 대화에서 Blocker 게이팅 설계가 확정되며 아래 내용 대부분이 다시 뒤집히거나 대체됐다 — 지금 유효한 반영 목록은 위 "해결 — Blocker 게이팅" 절의 "반영된 곳" 문단이 소스, 여기서 다시 정리하지 않는다. question.md는 이 중간 단계에서 RC-1을 추가했다가 해소 단계에서 다시 뺀 것이라 최종 diff엔 흔적이 안 남는다(2026-08-18 감사에서 확인) — 다음 세션이 "question.md가 바뀌었어야 하는데 안 바뀌었다"고 오해하지 않도록 남겨둠. 아래는 그 시점의 원문 그대로 보존(역사 기록):

• question.md 3번에 RC-1을 M2 착수 전 결론 필요 항목으로 추가(→ 이후 해소되며 제거, archive/question-resolved.md로).
• .claude/todos.md 00번(구현 전 QA 결과 요약)의 미해결 목록에 RC-1 추가, 머리말을 "M2/M3 착수 전 필요"로 갱신(→ 이후 해소 반영으로 다시 갱신).
• base/dispatch-core-plan.md의 "Length/Offset" 절 recompute/setLength 의사코드 자체엔 손대지 않음(nil 가드 같은 국소 수선도 넣지 않기로 함) — 대신 그 절 바로 위에 미해결 배너를 추가(→ 이후 의사코드 자체가 Blocker 게이팅으로 재작성됨).
• base/slot-plan.md의 "재귀 메커니즘" 절 서두에 RC-1 포인터 추가(→ 이후 attachSlot 의사코드 자체가 재작성됨).
• ROADMAP.md M2/M6 체크박스 3곳에 RC-1 경고/각주 추가(→ 이후 해결 표시로 갱신).
• .claude/README.md/project-context.md의 qa-request/ 서술을 round2 진행 중 상태로 갱신(→ 이후 완료 상태로 갱신).

---

진행 로그

2라운드(2026-08-18) — :List reconcile + recompute 손 트레이싱, reference/ 표본 대조, ROADMAP.md 정합성 확인, 그리고 같은 날 후속 세션에서 RC-1 해결까지 완료. 1라운드가 "아직 안 본 것"으로 남겨둔 항목 중:

• slot-plan.md의 :List 내부 — 트레이싱 완료(위 "SL" 절).
• dispatch-core-plan.md의 recompute — 트레이싱 완료, RC-1 발견 → 같은 날 Blocker 게이팅 설계로 해결(위 "해결 — Blocker 게이팅" 절).
• reference/ — 표본 점검 완료(전수는 아님, 위 참고).
• research/ 13개(1라운드 기록 당시 11개였으나 같은 날 세션 중 fastscroll-plan.md/spring-plan.md가 추가돼 지금은 13개 — 정확한 개수는 research/ 폴더 자체가 소스) — 이번 라운드에서도 제외, 확정 전 문서라 우선순위 낮음(.claude/README.md의 research/ 표 참고).
• 루트 ROADMAP.md 마일스톤 분할 — 확인 완료(위 "ROADMAP.md 마일스톤 정합성" 절).

남은 일: 없음 — RC-1까지 닫혀 2라운드 자체가 완료됐다. 3라운드가 필요해지면(예: 이번에 새로 들어간 attachSlot/recompute/Blocker 의사코드를 다시 손으로 트레이싱하는 검증) 새 파일 pre-implementation-qa-round3.md를 만들 것.