Commit graph

201 commits

Author SHA1 Message Date
c58c97a877
design: Gate 표면 확정(state:Gate + GateNode) + State 에포크 채택, 두 문서 base/ 승격
사용자 확정 둘로 M2 착수를 막던 설계 항목이 전부 사라졌다.

1) Gate — 탑레벨 프리미티브를 만들지 않고 state:Gate(setup) 메소드로 확정.
   ComputeNode와 같은 층위의 GateNode를 만든다. Blocker는 그 위의 별개
   프리미티브로, 이미 확정돼 있던 state:Block(blocker)가 내부에서
   self:Gate(policy)를 부른다. Debounce/Throttle의 state:Apply(...) 관용구는
   그대로 — 팩토리가 내부에서 :Gate를 부르면 되기 때문. 이름 문제(Gater?)도
   메소드 자리로 가면서 소멸. Get()엔 영향 없음(통지만 막음)까지 확정.
   research/gate-primitive.md -> base/gate-plan.md.

2) State 에포크 — 채택 확정. 구현은 M3.
   research/state-epoch-validation.md -> base/state-epoch-plan.md.

에포크 채택으로 source-state-plan.md의 두 확정 서술("emit은 항상 전파" /
"quad가 접지 않는 것은 중복 통지뿐")이 역전됐다. 원문은
archive/always-propagate-no-dedup-superseded.md. 지금 계약은 "invalid로는
절대 안 접고, 같은 소스의 같은 에포크가 두 번째로 도착했을 때만 접는다" —
2026-08-14의 invalid 기반 dedup 금지를 되돌린 게 아니라는 점을 역전 문서와
source-state-plan.md, README 세 곳에 못박음(흐려지면 "영구 침묵" 버그로
되돌아감).

같이 갱신: architecture.md 전파 모델 요약, blocker-plan.md(:Gate 배선 +
Get 계약이 에포크 안의 전제라는 것), debounce-throttle-plan.md(공용 게이트
권고가 실현됨 / 파동 단위 최적화 서술 정정), reference/comparison-fusion-vide.md,
source-state-plan.md의 Observer 계약 각주(이제 "새 에포크는 항상 통과"에
의존), ROADMAP M0 각주·M2 각주·M3 체크박스, README/question/todos 인덱스.

스파이크 05-store-state-diamond-propagation은 done/ -> rewrite-required/ 로
되돌렸다 — 다이아몬드 Observer가 이제 변경당 1회만 울어야 해서 핵심 assert가
정반대가 됐다(살릴 것/새로 넣을 것은 STATUS.md에 기재).

처리 전량의 소스는 qa-request/pre-implementation-qa-round5-followup.md의 O절.
doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01TiW21rnti9SbLgF6twtn6D
2026-08-21 21:04:27 +09:00
76cf74e80d
design: 에포크 순회 처분을 sourceCountMap/sourceEmitMap 두 테이블로 확정
사용자가 열려 있던 마지막 자리를 제3안으로 닫음. 판정 기준을 둘로 나눈다 —
sourceCountMap(값 유효성)은 순회가 앞당겨 올리고, sourceEmitMap(전파 dedup)은
상류의 진짜 emit을 기다린다. emit 수신 규칙은 셋: count가 다르면 둘 다 갱신 +
rawInvalid + 전파 / count는 같은데 emit 기록이 다르면 전파만(순회가 앞질러
흡수한 경우) / 둘 다 같으면 삼킨다. 순회는 emit을 하지 않는다.

효과 — 통지가 죽는 "영구 침묵"이 사라지고, 순회가 emit을 안 하므로 게이트
누출 경로 자체가 없어져 source = nil 규약도 "게이트를 에포크 경계로" 같은
계약 반전도 불필요해진다. 직전 라운드에서 에이전트가 냈던 (c)안의 약점
(emit 도착 전까지 Get마다 재계산)도 sourceCountMap을 실제로 올리므로 없다.

같이 검토된 rawEmit+nil 안은 구조 위생(상류 emit과 내부 발생 emit의 진입점
통일)만 살리고 해법으로는 안 씀 — 막는 게이트는 보통 순회하는 노드 자신이
아니라 상류에 있어 자기 rawEmit을 태워도 누출이 남고, nil emit은 하류마다
전체 순회를 강제해 같은 문제를 연쇄시킨다.

M절에서 철회했던 seen/computedAt 분리가 다른 근거(순회가 값과 통지를
비대칭으로 앞당김)로 되살아난 것이라는 점도 명시. 이제 기제는 다 정해졌고
남은 건 채택 여부 자체 — README/question.md/ROADMAP 동기화.
doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01TiW21rnti9SbLgF6twtn6D
2026-08-21 20:49:28 +09:00
9627558046
design: 에포크 순회의 count 갱신 문제 정리 + Gate는 :Apply가 아니라 State 메소드로 확정
(1) research/state-epoch-validation.md §5-3 재작성. 사용자 지적대로 순회가
count를 올리면 뒤늦게 온 진짜 emit이 삼켜져 하류 통지가 영구히 죽는다
(2026-08-14에 폐기된 옛 dedup의 "영구 침묵"과 같은 계열). 두 해법을
대조로 남김 — (b) 순회도 emit(사용자 제안, 게이트 누출이 남고 그 누출을
막을 기제가 둘 다 대가가 큼: 에포크 경계는 blocker의 ":Get()엔 영향 없음"
확정 계약을 뒤집고, source = nil 규약은 사후 정합성만 맞춤) vs
(c) 순회는 rawInvalid만 세우고 count는 안 올림(에이전트 권고 — 원인만
제거하므로 누출도 nil 규약도 계약 반전도 안 생김, 대가는 emit 도착 전까지
Get마다 재계산과 OffWithoutEmit 캐비엇). 미결로 남김.

(2) research/gate-primitive.md 2번 해소. 사용자 확정으로 Gate는
state:Gate(setup) 메소드다. 경계는 "Apply가 노드를 못 만든다"가 아니라
"프리미티브는 메소드 / 유저랜드 조합 팩토리는 :Apply". 그래서
Debounce/Throttle의 Apply 관용구는 유지되고, Blocker 배선은 이미 확정된
state:Block(blocker)가 내부에서 :Gate를 부르는 것으로 자동 해소되며,
__call은 쓰지 않는다.

question.md/ROADMAP 인덱스 동기화. doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01TiW21rnti9SbLgF6twtn6D
2026-08-21 20:24:51 +09:00
4c395cd383
design: State 에포크 안 3차 정정 — rawInvalid 기제 반전, seen/computedAt 분리 철회
사용자가 research/state-epoch-validation.md를 직접 읽고 기제 서술 세 건을
정정. 채택 여부 자체는 여전히 미정(M3 전 결론 필요).

- sourceList 순회 조건이 반대였다: rawInvalid == false일 때만 돈다.
  true면 재계산이 이미 확정이라 훑을 이유가 없고, 순회의 목적은 오직
  "못 받은 emit(게이트에 막혔던 것)을 여기서 먼저 받는 것".
- emit은 (source, count)가 아니라 발행 source만 싣는다 — 받는 쪽이
  source의 count 필드를 그냥 읽으면 된다.
- 에이전트가 요구했던 seen/computedAt 두 카운트 분리는 철회. count 갱신과
  rawInvalid = true가 같은 스텝이라 캐시 오인 경로가 없다.
- emit 수신 규약 확정형: 같으면 삼킴 / 다르면 count 먼저 갱신 →
  rawInvalid = true → 그 다음 뒤로 emit. 다른 소스 항목은 안 건드림.
- 부수로 열린 것: 순회가 발견한 변경을 뒤로 emit 할 것인가. 다이아몬드
  쪽은 사용자가 스스로 안전으로 정정(D도 count를 갱신해 중복을 삼킴),
  게이트 쪽만 "해제 emit이 source = nil을 싣고 받는 쪽이 전체 확인"
  규약으로 남음 — 게이트는 보통 최종단이라 채택을 막지 않는다는 판단.
- 비용 서술도 뒤집었고(훑는 쪽이 흔한 경로), question.md에 남아 있던
  이미 뒤집힌 옛 결론("중복 통지는 안 고쳐짐 / UB 명문화 필요")도 정정.

처리 기록은 round5-followup.md M절. doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01TiW21rnti9SbLgF6twtn6D
2026-08-21 20:15:28 +09:00
a4b517aee2
design: native* 물리 조작 계층 확정 + C-7("부기가 물리보다 먼저") 역전
주입 op 셋(mountInst/unmountInst/disposeInst)으로는 Move/Swap을 아예 표현할
수 없다는 지적에서 시작해 물리 조작 계층 전체를 재설계했다.

층위 정의(사용자): raw*는 그 Slot 스코프 안의 연산(평탄화 전, _elements
인덱스), native*는 확정된 offset/length로 표현되는 물리 트리 연산(평탄화 후,
절대 좌표).

표면 여섯:
  nativeInsert (target, offset, elements)
  nativeExtract(target, offset, elements, newElements?)   -- 빼되 살림
  nativeRemove (target, offset, elements, newElements?)   -- 빼면서 파괴
  nativeMove   (target, fromOffset, elements, toOffset)
  nativeSwap   (target, offsetA, elementsA, offsetB, elementsB)
  nativeDispose(element)                                   -- 트리 밖 값 파괴

- Replace는 별도 op이 아니라 newElements가 있는 Remove/Extract(Splice도 동일)
  — 제거+삽입을 한 호출로 합쳐 리플로우 2회와 그 사이 인덱스가 어긋난 창을
  없앤다
- 파괴/비파괴를 불리언이 아니라 이름으로 가름 — 공개 CRUD의 Remove/Extract
  어휘를 물려받고, Roblox의 "Parent=nil 없이 그 자리에서 Destroy" 융합을 연다
- 빠지는 요소는 반드시 배열로 넘김 — (target, offset, count)로 대상을 찾을 수
  있는 건 DOM뿐이고 Roblox는 자식이 순서 없는 집합이라 offset 역조회가 안 됨
- nativeSwap은 별도 — Move는 사이를 전부 밀지만 Swap은 가운데 고정
- 미주입이면 에러가 아니라 조합 폴백(addTag 계열과 갈리는 지점)
- 전제: 한 Slot의 물리 자식은 부모 안에서 연속 구간을 차지한다

그 여파로 4라운드 C-7 일반 계약이 역전됨 — "Length를 먼저 올려 밀어내고 그
공간에 넣는다"는 그림은 base에 물리적으로 자리를 비워둘 수단이 없어 성립하지
않는다. 규칙이 "빼기는 물리 먼저/넣기는 부기 먼저" 두 얼굴에서
"자기 자리를 정하는 것(setOffsetSource) 먼저 / 뒤를 미는 것(setLength→
recompute) 나중" 하나로 줄었다. 배치 경로(materializeSlotTree→mountSlotTree)의
부기-전량-먼저는 C6가 요구하는 별개 사안이라 그대로.
원문은 archive/bookkeeping-before-physical-reversed.md.

같이: getOffsetAt을 사용자 의사코드대로 단일 함수 + invalidAfter로 정정
(무효화는 min(invalidAfter, i) 하나, recompute도 그 캐시 위에 얹혀 O(N)).

doc-check.py ERROR 0. 상세는
qa-request/pre-implementation-qa-round5-followup.md의 L절.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 20:07:21 +09:00
c6fdf1b348
qa: 구현 전 QA 5라운드 — 문항지·회신·전량 반영 + 감사 2라운드
4라운드 종결 때 "안 만든다"고 했던 5라운드를 사용자 요청으로 신설(205문항).
범위를 셋으로 좁힘 — (1) 4라운드에 문항이 아예 없던 영역(project-setup /
quad-types, 그리고 문서가 아니라 실제 커밋된 M1 코드), (2) 그 이후 확정된 것
(Detach/KeyGone/Owned/attachSlot 분해), (3) 큰 문서의 심화. 회신을 4차에 걸쳐
받아 전량 반영했고, 커밋 전 감사를 각도를 바꿔 2라운드 돌렸다.

주요 확정/역전:
- slot._detached lazy화, KeyGone엔 새 값 반환도 error,
  Owned=false에서 Detach는 _detached에 안 들어감(rawUnmount)
- Slot:Replace 신설 + rawReplace/rawAdd 의사코드 신설(문서에 정의가 없었음)
- raw* 인자를 index로 전부 통일 — 오래 열려 있던 캐비엇 종결.
  래핑은 raw* 바깥에서만(공개 표면 + settle), raw*는 물리 요소만 다룸
- 물리 조작을 주입 op로(mountInst/unmountInst/disposeInst, 이름 가칭) —
  base는 Parent를 모른다는 지적. mountInst는 0-based 절대 offset을 받음
- Dispatch.setLength에 anchor(생략 시 ownerKey) — 부기 키와 생명주기 앵커
  분리, 4라운드 D-56 역전(archive로)
- Dispatch.getOffsetAt 신설(pull) + 접두합 캐시(offsetDirtyFrom),
  setOffsetSource(None)은 얼리 리턴, None의 뜻을 "발행 채널 없음"으로 정정
- recompute가 owner 베이스에서 시작(중첩 offset이 부모 베이스를 못 받던
  결함), _baseObserver로 깊은 전파, Offset Source identity 재사용(포탈),
  bk.N or 0(빈 Slot 크래시)
- Effect(fn, ...deps) 확정 — Ref도 의존성(옛 "trailing args sugar 안 만듦"
  역전), Tween:Mapped, groupClaimKeys 키 = (inst, groupValue) → k
- 게이팅 먼저(M2로 앞당김) — 다만 대상이 Blocker가 아니라 공용 Gate 노드로
  바뀌었고, 설계는 사용자 지시로 다음 세션(M2 착수를 막는 유일한 항목)

새 research 둘: gate-primitive.md(다음 세션이 이어받을 재료),
state-epoch-validation.md(전파 중 Get이 섞인 값을 캐시하는 glitch — 정확성
결정이라 M3 전 결론 필요).

감사가 잡은 것 중 큰 것: 확정한 Owned가 Slot:List 시그니처에 배선이 안 돼
코드에 도달 못 하던 것, effect-plan.md의 역전 배너 없는 자기모순,
그리고 손대지 않은 문서(ROADMAP 백로그·debounce-throttle-plan)가 "Gate는
M3에서"로 남아 있던 사각지대.

doc-check.py ERROR 0. 상세는 qa-request/pre-implementation-qa-round5-followup.md
(A~K절, 마지막이 최신).

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 18:19:58 +09:00
d5e5e1a1b9
fix: /code-review high 발견 2건 — plain-table :List 재마운트 크래시 등
quad-doc-auditor 6라운드 수렴 후 /code-review high로 diff 자체를 재검토한
결과. 감사자는 코퍼스 전체 정합성만 보고 diff 결함은 못 잡는다는 게
conventions.md가 이미 명시한 한계인데, 실제로 이번 diff 안의 결함이
나왔다.

- activateList의 재마운트 분기가 bindLifetime(physicalTarget, nil)로
  크래시할 수 있었음. _listObserver는 data가 reactive(State/Source)일 때만
  세팅되고 plain table data(문서가 지원하는 형태)면 영원히 nil인데,
  가드 없이 불렀음. 짝인 unmountSlotTree 쪽은 이미 방어돼 있었던 것과
  비대칭 — 가드 추가.
- "구독 시점" 절에 activateList의 옛 파라미터 이름 inst가 리네이밍 후에도
  남아 있어, 그 절만 읽는 구현자가 physicalTarget 리네이밍의 취지(owner
  키가 Slot일 수도 있는 문맥과의 혼동 방지)를 놓칠 위험 — 정정.

qa-request/pre-implementation-qa-round4-followup.md에 I-8로 기록.
doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 13:30:33 +09:00
4622fbeec8
qa: 반영 후 감사 6라운드 — 실제 크래시 3건 포함 18건 수정
커밋 9b7f847(Detach/KeyGone/Owned/attachSlot 분해) 반영 후 각도를 바꿔가며
quad-doc-auditor를 6라운드 돌린 결과. 라운드별 확실 발견 4/6/2/3/3/0으로
6라운드에서 새 발견 0건 — 수렴 확인 후 종료. 경위 전량은
qa-request/pre-implementation-qa-round4-followup.md의 I절이 소스.

트레이싱 라운드(4~5)가 잡은 실제 크래시 — 셋 다 Detach가 신설한 경로가
기존 불변식과 부딪히는데 그쪽이 안 고쳐진 것:

- I-1 (치명): rawDetach가 소유권을 유지하는데 재마운트는 rawAdd →
  claimOwner를 거치고, claimOwner는 같은 owner의 재클레임도 무조건 error다
  (2026-08-13 감사가 Slot{a,a}를 막으려고 넣은 것). 문서가 권장하는
  "prev를 그대로 반환하면 재마운트" 패턴이 그대로 죽었음. fromDetached
  플래그로 그 경로만 좁게 예외 처리.
- I-2: 재마운트된 자식 Slot이 activateList를 두 번 실행해 구독이 이중으로
  생기고 mounted/keyIndex 클로저 상태가 통째로 새로 만들어짐 → 멱등 가드.
  가드만으로는 :List 구독이 옛 physicalTarget에 앵커된 채 남아 포탈
  재마운트 후 조용히 멈추므로, _listObserver 핸들 보관 + 재앵커까지 처리.
- I-3: _detachCleanup이 releaseOwner를 안 불러 Owned=false 요소가 죽은
  Slot을 owner로 달고 남음 → 두 분기 공통으로 호출.
- I-6: 위 수정의 회귀 트레이싱 — destroySlotTree에 _listObserver 해제 누락,
  claimOwner의 옛 논증 두 문단이 fromDetached와 정면 모순, 소유권 예시
  코드가 C-4와 모순.
- I-7: 사용자가 별도 상의해 가져온 두 건 — _detachCleanup 설치를
  mountSlotTree → activateList로 이관(:List 없는 Slot마다 no-op Effect를
  트리 크기만큼 심고 있었음), activateList의 inst → physicalTarget 리네이밍.
  이관 근거가 멱등 가드 이전 동작을 전제하고 있어 가드 분기의 재앵커까지
  같이 반영. 이로써 _listObserver/_detachCleanup이 같은 범주로 통일됨.

I-4(materializeSlotTree 중 예외 시 Blocker 잔류)는 사용자 판단으로 pcall
없이 문서화만 — 아직 밟은 적 없는 경로이고 옛 단일 attachSlot에도 있었을
구조적 갭.

문서 정합성 라운드(1~3)에서 나온 것: slot-plan의 "값 교체는 비파괴" 잔존,
분해 완료 후에도 남아 있던 "논의 대기 중" 배너, attachSlot의 flush 루프를
가리키던 문장 5곳, README 색인 행이 2026-08-19에서 멈춰 있던 것,
qa-round4 문항지/followup의 "회신 대기" 상태줄, todos의 용어 목록 이중 소스,
dispatch-core의 raw* 일반 계약에 rawDetach 누락.

luau-test: 스파이크 01이 "재작성 필요" 마커를 단 채 done/에 남아 있어
STATUS.md 자신의 "폴더가 곧 상태" 규칙을 어기고 있었음 → rewrite-required/로
이동하고 개수 정정. "만들어야 할 스파이크" 절 신설(아직 파일조차 없는 실측
항목이 어느 폴더로도 표현되지 않아 구조적으로 잊히던 자리).

doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 13:20:42 +09:00
9b7f847014
design: Detach 보존 주체/KeyGone/Owned 확정 + attachSlot 분해
QA 4라운드 followup의 마지막 열린 항목(F-3)이 사용자 회신으로 전량
닫히면서 :List 요소 소유권 모델과 attachSlot 책임 분해를 base/에 반영.

- Detach 보존 주체를 userdata → slot._detached 필드로 전면 정정.
  근거는 gcconn 트릭 — detach된 quad-제작 Instance는 GC 폴백이 없어
  명시적 정리 경로가 필수인데 userdata는 :List에게 opaque라 처분 불가.
  재-Detach는 nop, prev 반환은 재마운트. raw 3형제(rawRemove/rawUnmount/
  rawDetach)로 "파괴하는가"와 "소유권을 놓는가"를 분리.
- KeyGone 센티널 신설 — 키가 사라진 자리도 조용히 처분하지 않고
  updateFn(KeyGone, 0, offset, prev, ud)로 한 번 더 묻는다. owner 사망
  시 최종 정리는 mountSlotTree가 거는 Effect가 담당.
- Owned 설치 플래그 신설 — Detach(사이클 단위)와 직교하는 축.
  state<Frame> 의미론 충돌(C-2)이 이걸로 닫힘.
- attachSlot을 materializeSlotTree(부기) + mountSlotTree(물리)로 분해.
  "부모에게 미는 길이는 최종값"(C6)과 "부기가 물리보다 먼저"(C7)가 한
  함수 안에선 동시 만족 불가라는 진단이 근거. 공개 표면은 두 줄짜리
  래퍼로 유지해 호출부 무변경. research/slot-attach-decomposition.md 확정.
- ROADMAP M6의 옛 Detach 서술 2건과 미결 마커 정정, question.md/todos.md
  해소 반영, session/2026-08-21-01 원문 + session-summary 색인 공백 4건 보강.

doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 11:55:11 +09:00
448b961e7f
research: attachSlot 분해 — 일괄 마운트 차이 검토, 판단을 추천으로 갱신
사용자가 짚은 "물리 마운트가 관측 이후 일괄로 밀린다"는 차이를 따져본 결과
감수하는 비용이 아니라 개선이라는 결론.

- 마운트 순서 자체는 안 바뀐다(둘 다 깊이 우선 같은 순서) — 바뀌는 건 각
  Parent 대입 시점에 부기가 얼마나 완성돼 있는가뿐.
- 그 차이를 실제로 관측하는 주체가 있다: Parent 대입이 ChildAdded/
  DescendantAdded를 동기 발화시키므로 사용자 핸들러가 마운트 도중에 끼어든다.
  현행은 A의 ChildAdded 시점에 inner.Length가 0이고 뒤 형제 offset도 stale인
  미완성 스냅샷을 보여주는데, 분해하면 첫 발화 때 서브트리 전체가 최종값이다.
  slot.Length 구독자도 0→최종 두 번이 아니라 최종값으로 한 번 발화.
- "합치는 거대 함수"는 만들어도 목적을 못 이룬다 — 완전 병합은 자식 길이를
  그 자식 재귀가 끝나야 알므로 C6를 못 지키고(그게 지금 코드), 부분 병합은
  인터리브는 유지하지만 부모 레벨 C7 위반이 그대로 남는다. 실질 선택지는
  (A) 인터리브+자기교정 / (B) 분해+일괄 둘뿐.
- 부수 이득 둘: Blocker가 materialize만 감싸게 되어 "배치 등록 게이팅"이라는
  정의와 코드 범위가 일치하고, mountSlotTree가 순수 walk라 일괄 삽입이
  유리한 백엔드(웹 DocumentFragment 등)가 그 함수 하나만 갈아끼울 수 있는
  seam이 생긴다.

판단을 "약한 추천"에서 "추천"으로 갱신 — RC-1/RC-3/RC-4가 전부 한 함수 안의
줄 순서를 잘못 잡아 난 버그였는데, 분해하면 C2/C3/C7이 함수 경계로 강제되어
그 실수 클래스가 구조적으로 사라진다는 사용자 지적이 결정적. 다만 M6 착수 전
실제로 짜보며 확정해도 늦지 않다는 판단은 유지.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 11:31:11 +09:00
6fd93c6dc2
research: attachSlot 분해 구체안 — 공개 표면은 유지, 재귀만 둘로
사용자 질문("혹시 쪼갠다면 어떻게 쪼갤것 같아?")에 대한 답을 6절로 추가.

핵심은 쪼개야 하는 게 호출부에 보이는 함수가 아니라 재귀 자체라는 것 —
(B)가 요구하는 "부기는 bottom-up, 물리는 top-down"을 하려면 재귀가 두 번
돌아야 하고, 그게 "쪼갠다"의 실체다. attachSlot이라는 이름이 정당하다는
판단에 동의하므로 공개 진입점은 이름/시그니처/호출부 전부 그대로 두고
몸통만 비공개 재귀 헬퍼 둘(materializeSlotTree/mountSlotTree — 코퍼스가
이미 쓰는 unmountSlotTree/destroySlotTree의 ...SlotTree 접미사를 따름)로
나누는 안을 제시. attachSlot의 몸통은 두 줄이 된다.

setLength가 materializeSlotTree의 끝으로 가는 게 관건 — 자기 서브트리
부기가 다 끝난 뒤라 처음부터 최종값이고, 그러면서도 모든 Parent 대입보다
먼저다. 그래서 C6(최종값 등록)와 C7(부기가 물리보다 먼저)이 동시에 만족되고
배치 밖 재마운트의 부모 recompute가 2회→1회로 준다. C1~C7 전부 유지되는지
표로 재점검했고, 비용(_elements 순회 2회)과 안 고쳐지는 것(부모 등록과 자식
배치가 여전히 한 함수), 비대칭 하나(materialize의 거울상은 함수가 아니라
호출부 관용구)도 같이 적었다.

판단은 약한 추천 — 값이 틀려지는 문제가 아니라 "일반 계약을 세워놓고 자기가
예외"인 상태와 _mounted의 애매한 중간 시점(RC-3/RC-4의 출처)이 정리되는
것이 이득. M6 착수 시점에 실제로 짜보며 정해도 늦지 않다.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 11:20:30 +09:00
1e6cb0111d
design: QA 4라운드 3차 회신 반영 + attachSlot 분해 논의 자료 준비
확인받은 것 반영:
- Owned 설치 플래그 확정 — "누가 요소를 만들었는가"는 사이클마다 달라지는 게
  아니라 설치 시점 속성이라는 사용자 판단. Detach(사이클 판단)와 직교하는
  축이므로 반환값 계열에 unowned 센티널을 더 만들지 않는다. destroySlotTree/
  dispose도 이 플래그를 봐야 해서 클로저가 아닌 Slot 필드여야 함.
- props 순회를 일반화 for 한 번으로 정정 — flattened는 항상 평범한 Luau
  테이블(__pairs/__ipairs를 갈아끼운 ud가 들어올 경로가 없음)이라 옛 근거
  "다른 백엔드가 Lua 테이블이 아닌 자료구조로"는 inst엔 해당해도 flattened엔
  해당하지 않았다. 계약(배열 먼저)은 그대로, 구현만 1회 순회로. 스파이크 01은
  두 루프 버전이라 재작성 필요로 STATUS에 표시.

attachSlot 분해는 research/slot-attach-decomposition.md로 준비:
setLength를 flush 앞/뒤 어디에 둘지가 안 풀린 이유가 자리 선택이 아니라
"한 함수가 책임 일곱을 지고 있어서"라는 사용자 진단에 따라, 책임 목록과
순서 제약(전부 RC-1/RC-3/RC-4 등 실제로 밟은 버그가 출처)을 모으고 C6(길이
최종값은 flush 뒤에야 정해짐)와 C7(부기가 물리보다 먼저)이 단일 함수로는
동시 만족 불가능함을 보인 뒤 분해 후보 넷을 대조. 확정은 아무것도 안 함.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 11:10:42 +09:00
f36bdcbe5d
design: QA 4라운드 2차 회신 반영 — B절 확인분 + C절 결정 7건
B절(설명 보강 재질문) 전부 확인됨. 확인 과정에서 나온 보강:
- B-1: (A) 분기는 "교체"라 stack-down이 아니고 retractFrom만 스택을 역순으로
  푼다는 구분을 명시. "자기 아래는 이미 정리된 뒤" 보장도 retractFrom 한정이고,
  (A)에서 아래가 살아 있는 게 깜빡임 없는 갈아끼우기의 근거.
- B-3: 고아 체인이 실제로 어떻게 생기는지 가상 위반 예시(MaybeWrapHandler) 추가.
- B-4: "Brand는 데이터 타입에 부작용 없이 런타임 명시 타이핑을 하기 위한 것"을
  존재 이유로 명시하고, duck-typing 기각 근거를 정확성/안전성 둘로 분리.

C절 결정 반영:
- C-3: flatten의 정확한 형태 확정 — in-place 뮤테이션(클론 안 함),
  ProcessedModifier로 소진, 인라인 우선이 `~= nil` 하나로 성립. 단 주신 코드의
  반복 방향은 역순이어야 "나중 modifier가 우선"이 성립해서 그것만 정정(F-4-2).
- C-4: destroySlotTree의 명시적 releaseOwner 제거. 파괴된 걸 재사용하는 코드는
  그 자체로 버그이므로 "비결정적으로 실패"보다 "항상 실패"가 낫다.
- C-6: recompute의 sourceList[i] == nil을 skip에서 즉시 error로 승격. 재추적
  결과 도달 경로가 없으므로 관측되면 부기가 깨진 것.
- C-7: "부기가 물리 트리 조작보다 항상 먼저"를 일반 계약으로 승격. 빼기는 물리
  먼저/넣기는 부기 먼저가 같은 원칙(좁은 쪽이 먼저)의 두 얼굴이라는 것과,
  yield 금지 덕에 프레임 경계가 안 끼므로 진짜 근거는 "백엔드가 전제할 수
  있게 하나로 고정"이라는 것까지.

followup F절에 남은 것: KeyGone 홀드 + Owned 설치 플래그 설계 제안(F-3),
단일 일반화 for 전환 여부/flatten 반복 방향/setLength 위치(F-4).

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-21 10:47:45 +09:00
9642cf8f18
qa: QA 4라운드 followup — 회신 처리 결과 + 재질문 정리
사용자 회신을 (a) 바로 반영 (b) 설명 부족으로 재질문 (c) 사용자 판단 필요
(d) 조사로 닫힘으로 갈라 followup 문서로 정리했다. A절(반영 완료)은 앞
커밋에서 이미 base/에 들어갔고, 이 커밋은 그 기록과 남은 항목이다.

가장 큰 두 미결:

- C-1 KeyGone 센티널 — 키 소멸 시 updateFn을 한 번 더 불러 처분을 묻는
  사용자 제안. SL-45의 "파괴도 반환도 안 되고 참조만 끊기는" 상태를 정확히
  메우지만, 반환값 의미/userdata 수명/소멸 루프 순회 대상/index 인자 넷이
  안 정해지면 구현이 못 나감.
- C-2 "밀려난 prev는 dispose" vs state<Frame> 의미론 충돌 — 회신의 SL-43과
  SL-51이 서로 반대를 가리켰는데, 따져보니 둘 다 맞고 갈리는 축이 "누가 그
  요소를 만들었는가"였다. :List의 updateFn이 만든 건 reconcile이 지워야 하고
  (만든 쪽이 자기 손으로 못 지움), Slot:Add(state) sugar로 온 건 사용자
  소유라 죽이면 안 됨. 지금 설계엔 후자를 표현할 방법이 없어 선택지 셋을
  올리고 per-installation 소유권 옵션을 추천.

부수로 사용자가 문서에 아예 없던 갭 둘을 찾아냄 — Attribute 생성자 자신의
이름 겹침 정책(앞 커밋에서 "뒤가 이김"으로 명시)과, flatten이 소진한
Modifier 자리 처리(C-3, ProcessedModifier 센티널 vs flatten 압축).

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-20 00:57:19 +09:00
41b96e6917
design: QA 4라운드 회신 1차 반영 — 즉시 처리 가능한 정정 20건
사용자 회신(pre-implementation-qa-round4-response.md) 중 판단이 명확한
항목을 base/에 반영. 굵직한 것만:

- LP-1: quad의 `Connected`는 "계산된 속성"이 아니라 그냥 RBXScriptConnection의
  네이티브 필드다 — rbvm 프록시 사정을 잘못 옮겨온 서술이었음. 실제 판정은
  "gcconn이 없음" / "있는데 Connected==false" 두 상태뿐.
- D-56: `bindLifetime`의 첫 인자가 Instance가 아닐 수 있다(Slot-in-Slot의
  ownerKey) — 백엔드가 반드시 핸들링해야 하는 요구사항으로 신설. gcconn
  트릭이 안 통하므로 세 번째 판정 분기가 필요하다는 것까지 명시.
- SL-75/D-60: 언마운트 시 `slot.Offset = nil`은 포탈을 깨뜨림(이미 구독
  중인 다운스트림이 영구히 끊김) — stale하게 두는 게 맞고, 마운트 전 기본값도
  nil이 아니라 0.
- SL-74: `SetAndDispose`는 `source:SetAndDispose(value)` 콜론 메서드로 확정.
  `Apply` 오버라이딩은 Source→State 단방향 때문에 타입이 안 성립.
- E-11: leaf 바인딩된 Effect엔 `:Unsubscribe()`가 아예 안 먹는 것으로
  Observer와 통일. 옛 "(3) 이후 leaf가 죽어도 중복 호출 안 됨"은 이중 바인딩
  게이트상 성립할 수 없는 문장이라 삭제.
- AT-20: 생존 이름 최적화는 "부품이 늘어나서 안 하는" 게 아니라 값 비교가
  필요해 **원리적으로 불가능**하다(State 계약상 `:Get()` 비교 금지).
- UI-8: `mapTweenValue` 로컬 헬퍼를 `Tween<T>:Map(fn)` 공개 메소드로 승격.

부수로 D-3(retract가 깊은 인덱스부터인 이유)/D-10(두 패스를 명시하는 진짜
이유는 순서를 못 믿어서가 아니라 이식성)/LH-8(자기 아래 vs 자기 위)을 코드
예시로 풀어 썼고, TW-16으로 HUMAN_TODO에 initValue 항목을 신설했다.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-20 00:48:07 +09:00
e80aa11c4f
qa: 구현 전 QA 4라운드 문항지 — base/ 전 문서 확정 주장 전수 문항화
사용자 요청("모든 확정 부분에 있어서 예가 되어야하는 질문들을 계속")으로
base/ 26개 문서를 서브에이전트 없이 한 맥락에서 의존성 순서로 읽으며,
확정으로 적힌 주장을 전부 "예가 나와야 정상인 단정문"으로 뽑았다.
결론만이 아니라 근거까지 문항에 넣었는데, 코퍼스에 "결론은 그대로인데
근거가 뒤집힌" 사례가 여럿 있어서 결론만 물으면 그런 걸 못 잡기 때문.

⚠️로 열려 있다고 적힌 항목은 "확정이 맞나"가 아니라 "아직 열려 있다는
인식이 맞나"를 묻는 문항으로 따로 표시했다.

정정은 하나도 안 했다 — 사용자 지시대로 기록만 하고 회신 대기 상태.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-20 00:33:49 +09:00
871c582771
tooling: 핸드오버 준비 — session-summary.md 색인 공백 + ROADMAP/CLAUDE.md stale 정정
session-summary.md에 오늘 세션 04~08 색인 항목이 통째로 빠져 있던 걸 발견해
신설. 더 크게는 CLAUDE.md/project-context.md/ROADMAP.md가 "구현 아직 시작
전"이라는 낡은 전제를 깔고 있었는데, 실측해보니 M0 스파이크 4개와 M1
스캐폴딩 대부분이 이미 완료돼 있어 전부 정정(ROADMAP 체크박스 갱신 포함,
wally.toml→pesde.toml 표기도 같이 정정). quad-roblox-types 백로그는
todos.md/ROADMAP.md M5에 짧은 포인터 보강.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 20:47:31 +09:00
5dfc9b9a43
design: type-version-check 패키지 추출 — CheckedQuad<T, Pattern> 글롭/캐럿 확장
quad-spring-roblox류 독립 게시 플러그인엔 정확 버전 일치가 과하다는 지적에
따라, 버전 패턴 매칭(글롭 "*"/캐럿 "N^")을 quad에 종속되지 않은 범용
워크스페이스 멤버 type-version-check로 분리하고 quad-types의 CheckedQuad를
CheckedQuad<T, Pattern>으로 확장. 새 Luau 함정 2건(type function의 outer
local 참조 불가, cross-package엔 export type function + 이중 꺾쇠 제네릭
인스턴스화 필요) 발견·문서화. 독립 저장소 분리는 HUMAN_TODO로 위임.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 17:39:57 +09:00
297c4d459c
design: quad-types 패키지 신설 — AddPlugin<Self,P> + CheckedQuad<T> 실측 설계
quad-roblox가 quad-base를 런타임 주입(QuadRoblox(Quad): QuadRoblox)으로만
받으면 pesde 의존 선언이 필요 없어 보이지만, 타입 참조용 require도
런타임에 실제 실행됨을 실측 확인 — dev-dependency로 두면 게시 후
소비자 환경에서 크래시함. 해법으로 구현 없는 타입 계약 전용 워크스페이스
패키지 quad-types 신설, quad-base/quad-roblox 모두 이것만 의존하도록
전환.

AddPlugin<Self,P>(self:Self,fn:(Self)->P):Self&P — 제네릭 self로 둬야
체이닝이 누적됨을 실측 확인(고정하면 이전 확장을 잃음), quad-base에
실제 mutate 기반 구현 반영.

CheckedQuad<T> 버전 체크는 배선하며 세 번 깨짐 — error() 대신
print+types.never, 함수 본문 로컬 별칭 대신 리턴 타입 표현식에 직접,
그리고 가장 중요하게 type function을 한 번이라도 거친 값(패스스루
포함)은 이후 AddPlugin 같은 제네릭 self 체이닝이 조용히 깨진다는 새
Luau 함정 발견 — typing-limits.md §6으로 승격. 최종 설계(검증 결과를
원본과 격리된 가상 필드로)만 AddPlugin과 완전히 호환.

부수로 quad-base 자신도 quad-types workspace 의존 때문에 CLI symlink
함정(지난 세션 발견)에 걸림 — 로컬 테스트용 symlink 실체화로 임시 우회.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 17:09:16 +09:00
1de031e139
design: RunInit vs 백엔드 유일 슬롯 가드 분리 확정 — _initializedBy 유지
사용자 결정: RunInit(함수 identity 추적)은 backend 설치 진입점
(QuadRoblox 등)에 재사용하지 않는다. 대신 bind-system-plan.md 3차
라운드가 이미 정해둔 _initializedBy 문자열 마커(같은 팩토리 재호출=
no-op, 다른 팩토리=에러)를 그대로 별도 메커니즘으로 유지 — "멱등 실행"과
"유일 슬롯 점유"는 의미가 달라 억지로 합치면 RunInit의 단순함만 깨짐.
실제 InitRoblox 구현 예시 의사코드 추가(M5 실착수 시 RobloxFactory.luau
참고용).

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 16:26:34 +09:00
9c3bfc890a
design: RunInit 재설계(함수를 릴레이션 키로) + darklua 경계 실측 정밀화
New()의 멱등 Init 가드를 파일마다 Relate+센티널을 두던 방식에서
module:RunInit(initFn) 하나로 통합 — 함수 자체를 릴레이션 키로 써서
"이 함수, 이 모듈에 실행했는가"를 (module, initFn) -> boolean? 하나로
표현(사용자 제안). Debug/init.luau는 가드 없이 순수 뮤테이션만 하도록
단순화. smoke.init.luau로 재호출 무시/인스턴스별 독립/함수별 독립 3개
시나리오 검증(luau/luau-analyze/selene 클린).

darklua process를 실제로 돌려 @self/@game은 안 건드리고 커스텀 .luaurc
alias(@pkg)만 script.Parent류로 치환한다는 걸 확인 — project-setup-plan.md의
darklua 기각 근거를 "지금은 커스텀 alias를 안 쓰니 불필요, 나중에 도입하면
그때 필요해짐"으로 정밀화.

⚠️ 미결: RunInit을 backend 설치 진입점(QuadRoblox(Quad))에도 재사용할지
— 함수 identity 추적으로는 "다른 팩토리 재호출은 에러" 계약을 못 만족.
module-lifecycle-plan.md에 반영, M2/M5 착수 전 확인 필요.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 16:17:08 +09:00
ef3d952dd4
tooling: rokit → mise 전환 + selene 린터 도입 (roblox-project-example 벤치마킹)
Word30210/roblox-project-example(initreq/에 클론)를 참고해 두 가지 채택:
(1) rokit.toml → mise.toml — mise install이 pesde/rojo/luau-lsp/selene을
GitHub attestation+SLSA provenance 검증까지 거쳐 설치하는 걸 이 샌드박스
에서 직접 확인(rokit은 끝내 검증 불가), 이 환경 자체가 이미 mise로
luau를 관리 중이라 더 자연스러움. (2) selene 린터 — 참고 레포의
selene.toml을 패키지별로 채택, 단 CWD 상대 config 탐색 함정을 발견
(루트 단일 설정으로 두면 다른 디렉토리에서 실행 시 조용히 Lua 5.1
std로 폴백해 Luau 타입 문법 전체가 파싱 에러로 잘못 보임) — 참고 레포
그대로 패키지별 selene.toml + 패키지 안에서 실행하는 걸로 확정. 도입
즉시 smoke.mock.luau의 assert 메시지 누락 3건을 잡아 수정.

darklua의 convert_require 변환은 검토 후 기각 — 사용자 판단: Roblox
엔진 자체도 이미 같은 require-by-string 의미론(@self/@game)을 지원해
변환 계층이 불필요.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 15:09:35 +09:00
2de2f99cc4
tooling: 에디터 Luau 솔버 설정 확정 — luau-lsp 설치해 새 솔버 필요성 실측
luau-lsp 1.69.0을 pesde/rojo와 같은 방식으로 직접 설치해
--flag:LuauSolverV2=true/false로 spike 08을 대조(옛 솔버 에러 3건 vs
새 솔버 1건) — HUMAN_TODO 6번이 사람에게 넘겨뒀던 "실제 에디터에서
확인"을 CLI 분석 모드로 대신 검증. quad/.vscode/settings.json에
enableNewSolver:true 반영, rokit.toml에 luau-lsp 핀 추가. 부수로
typing-limits.md 1번의 핵심 주장(0 진단으로 조용히 새는 것)이 Luau
0.734에서도 그대로 재현됨을 별도로 재확인(정정 불필요).

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 14:37:17 +09:00
0b471535a3
qa: luau-test 스파이크 13 재작성 — 타입/런타임 분리 + PostRef까지 확장
13은 타입(A)/런타임(B) 두 섹션이 한 파일에 있었는데 A의 더미 스텁이
런타임 실행 시 크래시를 내 B가 전혀 검증되지 못하고 있었음(STATUS.md
지적 사항). 13은 타입 전용으로 남기고(PostRef<T>도 Ref<T>를 만족하는지
추가), 런타임 절반은 신규 22로 분리 — isPreRef/isPostRef가 서로 배타적
형제이고 Leaf 핸들러 흉내가 Ref/PreRef/PostRef 셋을 정확히 갈라내는지
확인. 둘 다 done/으로.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 14:31:56 +09:00
7e4f2a77fe
tooling: Rojo 설치·검증 — pesde workspace symlink는 Studio 배포와 무관함 확인
pesde처럼 rojo도 /code/.local/bin에 직접 설치(7.7.0, rokit.toml 핀과
일치). rojo sourcemap/build가 quad-roblox/roblox_packages의 심볼릭
링크(quad-base로의 workspace 의존성)를 실제 파일까지 투명하게 따라감을
확인 — 이전 세션이 찾은 "luau CLI가 symlink를 안 따라간다"는 문제는
standalone CLI 전용이고 Rojo/Studio 배포 경로엔 영향 없음이 확정됨.
덤으로 luau-lsp가 rojo를 감지해 자동으로 sourcemap을 watch하는 것도
확인 — wally가 안고 있던 에디터 타입 링킹 단절 문제가 이 구성에서
재현 안 됨.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 14:27:43 +09:00
0c4c4a0537
qa: M0 luau-test 스파이크 05 재작성 통과 + 21 신규(Store 미선언 키) 반영
05는 "emit은 항상 전파, 재계산만 :Get() 캐시로 dedup" 현행 모델로
재작성해 rewrite-required/ -> done/ 이동. 21은 todos.md 00번이 요구하던
"Store 미선언 키 타입 에러" 확인 신규 스파이크 — ProcessStoreType 결과
타입이 미선언 키 접근을 정확히 TypeError로 거부함을 확인, store-plan.md의
"아마" 표시를 해소. STATUS.md/README.md/todos.md 텍스트도 같이 갱신.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 14:24:19 +09:00
205af32da4
tooling: 프로젝트 셋업 문서화 + wally→pesde 전환, M1 스캐폴딩 골격
pesde 워크스페이스 실제 설치·검증(패키지명 하이픈 금지, workspace 의존성
문법, per-package pesde.lock), init.luau의 @self require 규칙(Luau RFC
확인), 워크스페이스 의존성이 심볼릭 링크라 luau CLI의 require-by-string과
충돌하는 함정을 base/project-setup-plan.md로 정리. architecture.md
패키징 방식 절도 같이 정정. Relate.luau/New()-InitXxx 골격/mock 하네스는
이 구조를 실제로 검증하는 과정에서 나온 최소 스캐폴딩.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 14:01:07 +09:00
14f733dde1
design: Debounce/Throttle 마지막 판단 대기 4개 닫고 base/로 승격
의미론은 (A) emit-gate로 확정(value-hold 안은 laziness와 상충해 철회),
제어 핸들은 개별 Ref 아웃파라미터 + 전체 팩토리 브로드캐스트(weak
레지스트리)로 수렴, Time/MaxTime은 number|State<number> 허용(스케줄
시점에만 폴링), 이름은 Debounce/Throttle 유지로 확정. 전부 닫히면서
quad-base에 새 코어 메커니즘을 안 더하는 순수 슈가로 재평가됨(Blocker의
gated state + Ref + 주입 op 2개 위에 전부 얹힘) — 우선순위 서술도 갱신.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 02:11:11 +09:00
2348ea8058
design: PopOnly 가칭을 Detach로 리네임 확정 + 공개 표면 위치 확정
`:List` reconcile의 비파괴 반환 sentinel 이름을 사용자와 후보 검토(Bench/
Stash/Hold/Detach 등) 끝에 Detach로 확정 — 이미 있는 Extract(호출자 직접
호출, 명령형 소유권 이관)와 동사가 겹쳐도 "화면에서만 떼고 관리 주체는
reconcile"이라는 의미가 자연스럽게 구분됨. 공개 표면 위치도 같이 확정 —
Slot이 함수라 Slot.Detach로 못 붙이므로, None sentinel의 선례(공개 표면은
패키지 최상위 export, 정의는 관련 로직 옆)를 그대로 따름.

base/slot-plan.md 전량 반영(가칭 표기 제거, 이름/배치 두 결정 불릿 신설),
question.md/todos.md/ROADMAP.md/archive/question-resolved.md/README.md
인덱스 갱신, session/2026-08-19-02-*.md로 논의 원문 남김. 키 소멸 시 홀드
중이던 요소 처분 문제는 이름과 무관한 별개 항목으로 여전히 미결.

quad-doc-auditor 1라운드(무발견) 거쳐 doc-check.py ERROR 0 확인 후 커밋.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 01:46:18 +09:00
93cf408eb3
tooling: 세션 종료 전 session/ 원문 작성을 conventions.md에 명문화
2026-08-19 세션이 점검해보니 2026-08-18(커밋 10개, QA 1~2라운드 포함)에
session/ 파일이 1개뿐이었고 2026-08-19도 이 점검 전까지 0개였음 — 설계
결정이 오간 세션이 원문을 안 남기는 일이 실제로 반복됐다는 뜻. 사용자
판단: 이미 지난 공백은 재구성하지 말고(대화 원문 없이 지어내면 그 자체가
허위 기록) 인정하고 넘어가되, 앞으로 반복 안 되도록 규율을 명문화.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 01:24:28 +09:00
4be9373124
design: New()의 내부 구성 확정 — InitXxx 팩토리 체이닝 + Relate 기반 멱등 Init 가드
InitRoblox(Module) backend 주입 패턴을 quad-base 자기 내부(Dispatch 등)에도
대칭 적용 — 각 서브시스템이 InitXxx(module)로 module을 뮤테이션. 서브시스템
간 호출 순서 문제는 각 InitXxx 파일 톱레벨에 Relate() 하나를 두고 module을
weak key 삼아 인스턴스별 완료 여부를 기록해 require처럼 멱등하게 만들어
해소(relate-plan.md 체크리스트에도 용례 추가). module-lifecycle-plan.md에
"New()의 내부 구성" 절 신설, architecture.md/dispatch-core-plan.md/
ROADMAP.md(M1 체크리스트)에서 상호 참조.

핸드오버 감사 루프 4라운드(무발견 1회로 수렴) — 라운드 1~2는 절 인용
사각지대·상호참조 누락·SetWeak/SetStrong 일관성을 잡았고, 라운드 3~4는 그
수정 자체가 남긴 커밋 개수/날짜 오기, 원문 인용 파라프레이즈 등을 추가로
잡음. 부수로 session/ 기록 공백(2026-08-18/19 다수 커밋에 원문 누락)을
발견해 이번 세션분만 session/2026-08-19-01-*.md로 남김 — 과거 공백 처리는
사용자 확인 대기.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 01:16:26 +09:00
96c8c2eaa1
qa: 구현 전 QA 3라운드 — attachSlot/bk.N 트레이싱으로 RC-3/RC-4 발견·해결
RC-1 Blocker 게이팅이 실제로 attachSlot에 반영된 걸 손으로 트레이싱하다
:List 최초 population이 이중 처리되는 결함(RC-3/RC-4)과 recompute가
의존하는 bk.N의 수명주기가 문서에 없던 갭을 발견. 필자의 최초 분석
오류(bk.N을 그때그때 실제 개수로 두면 크래시가 되돌아온다는 판단)를
사용자가 직접 정정 — Blocker 게이팅은 bk.N이 아니라 blocker:IsOn()만
보므로 무관함이 밝혀졌고, RC-3/RC-4도 slot._mounted를 activateList
호출 뒤로 미루는 사용자 설계로 해결됨. ROADMAP M2가 M3의 Blocker.luau에
의존하게 된 마일스톤 순서 불일치도 발견해 각주로 반영.

quad-doc-auditor 감사 루프 4라운드(1~3라운드 총 9건 발견·수정, 4라운드
무발견으로 종료) 거쳐 doc-check.py ERROR 0 확인 후 커밋.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-19 00:07:30 +09:00
b419d8c5e5
qa: New()/Quad() 다중 인스턴스화 이름 정정 — 이전 커밋의 오역 정정
직전 커밋에서 New()를 전부 Quad()로 치환했던 게 사용자 의도를 잘못 읽은
것이었음 — 사용자가 직접 바로잡음. 실제 설계: Quad(require의 반환값)는
이미 만들어진 기본 싱글톤 인스턴스이고, 그 안의 New 필드를 명시적으로
호출해야만 별도의 새 Quad 네임스페이스가 생긴다. "그냥 Quad()를 부르면
매번 새 인스턴스"였다면, 컴포넌트를 여러 모듈로 쪼갠 앱에서 각자
인스턴스를 "얻는" 것 자체가 "새로 만들기"가 되어 서로 다른 인스턴스가
생기는 사고로 이어졌을 것.

architecture.md/dispatch-core-plan.md/bind-system-plan.md/
module-lifecycle-plan.md의 New() 서술을 되돌리고, qa-request round1의
A-3 절에 후속 정정 문단을 추가했다. quad-doc-auditor로 두 라운드 감사해
새 발견 0건까지 수렴시켰다.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 22:23:32 +09:00
a1f948ae34
qa: 구현 전 QA 2라운드 — recompute 손 트레이싱으로 RC-1 발견·해결
`:List` reconcile과 dispatch-core-plan.md의 recompute를 실제로 손으로
실행해보다 RC-1(배열 위치가 순차 등록되는 동안 아직 안 채워진 자리를
읽어 산술 에러가 나는 크래시, 정적 자식 2개짜리 Frame도 재현)을 찾았다.
같은 세션 후속 대화에서 사용자가 제시한 Blocker 재사용 게이팅 설계로
해결 — owner별 전용 Blocker가 배치 등록 동안 recompute를 막고,
setOffsetSource는 등록 즉시 앞선 형제 합을 직접 계산하며, attachSlot의
호출 순서(setOffsetSource→실체화→setLength→물리 마운트)도 바로잡고
코루틴 yield 금지 불변식을 명문화했다. Blocker에는 IsOn()/
OffWithoutEmit()이 새로 생겼다.

/code-review high가 이 diff에서 10건을 더 찾아 반영 — D-7 재역전과의
정합성, filter/nil 재역전 반영 누락, PreRef 가드의 typeof(k) 누락,
New()→Quad() 리네임 전파 누락, M6/M8 마일스톤 오기 등. quad-doc-auditor
감사 루프도 여러 라운드 돌려 새 발견 0건까지 수렴시켰다.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 22:11:59 +09:00
d768e4cbc5
tooling: 감사 루프를 병렬 다패스에서 순차 1패스/턴으로 재설계
사용자 지침 — "시간이 걸려도 상관 없으니, 차라리 병렬 에이전트를 덜 써줘.
그냥 한 턴에 하나씩만 사용하고, 0 이 나올때 까지 턴 수를 늘리는게
나아보임. 토큰을 너무 많이 소비해서 다른 작업을 못 하고, 세션 한도에
닿더라고."

- quad-doc-auditor는 한 턴에 하나만 호출(병렬 금지) — 2026-08-16의
  "최소 2개, 변경이 많으면 3~4개" 지침을 대체. 커버리지는 병렬 폭이
  아니라 턴 수로 얻는다. 근거 실측: 전 코퍼스 한 패스가 서브에이전트
  토큰 21만/툴 호출 82회, 4개 병렬이면 한 번에 80만대.
- 프롬프트로 범위를 diff로 좁힐 것을 신설(바뀐 파일 + 그걸 인용하는 곳).
  전 코퍼스 스윕은 오래 안 돌렸을 때만. 라운드마다 각도를 바꿔 병렬로
  얻던 폭을 턴으로 대체.
- 종료 조건을 "무발견 2연속"에서 "무발견 1회"로 완화(2연속은 병렬 다패스
  전제였음). 비용 때문에 중간에 멈출 때도 몇 라운드에서 왜 멈췄는지
  반드시 보고.
- /code-review는 감사자를 대체하지 않는다를 실측과 함께 명문화 — 이번
  핸드오버에서 감사자 1패스(1건) 뒤 /code-review high가 10건을 더 잡았고
  전부 유효했다(보는 축이 다름). 사용자만 호출 가능하므로 큰 변경 커밋
  전엔 돌릴지 물어볼 것.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 19:45:36 +09:00
8b57cfbb3c
qa: 구현 전 QA 1라운드 결과를 base/에 전량 반영
`.claude/pre-implementation-qa.md`(사용자가 base/ 확정 문서를 문항으로
재심사한 결과)를 실제 문서에 반영하고, 그 문서를 qa-request/로 옮기며
1라운드임을 파일명·제목에 명시(2라운드는 새 파일).

그대로 구현하면 반대로 돌던 것 2건:
- canBound의 판정 방향이 이름과 반대였음 → canBound(v) == not
  isBoundAlive(v), 게이트는 전부 `if not canBound(v) then error(...)`.
  canExecute와는 값이 같은 게 아니라 서로의 부정이고, 그게 오히려 이름
  분리의 명분이 됨(옛 근거 "값이 항상 같다"는 폐기).
- gcconn/gchold 보관이 SetStrong으로 적혀 있었음 → SetWeak. 근거 문장까지
  틀렸던 것이라 같이 교체(그대로 짰으면 두-Relate 상호 강참조 누수).

설계가 바뀐 것:
- Dispatch.drive의 None 스킵 분기 폐기 → NoneHandler는 재귀 전담,
  NilHandler 신설(k=number and v==nil 말단이 setLength/setOffsetSource
  등록). 깨진 전제는 "배열 파트의 None은 process를 안 탄다".
- Length/Offset 등록 책임이 "처음 매치한 Handler" → 말단 Handler.
- 이벤트 disconnect 센티널 false → None/nil.
- Ref 내부 구조를 .Callbacks 분리 + 평범한 .Value 필드로 단순화,
  RefLeafHandler에 빠져 있던 type(k)=="number" 추가(leaf는 배열 전용).
- :List reconcile의 nil 리턴은 다시 파괴가 기본, 값 교체와 PopOnly(가칭)만
  비파괴.
- base 소유 Fallback Handler 등록 주체를 백엔드 팩토리 → quad-base 자신으로
  재역전(백엔드 미로드 시 안내 에러 경로가 안 돌았음).
- "이벤트 콜백 시그니처는 Luau가 검증 못 한다"가 거짓임이 사용자 반례로
  확인 → onchange-plan.md의 파생 근거까지 교체(결론은 유지).

이름/표면: DI → D(Declarative) 확정 및 전수 반영, New 커링 + D는 전량
코드 생성, Attribute.Merged/Overridden 둘 다 제공, Quad.debug 신설,
store "key" 문자열 커링 기각(→ store:GetDynamic).

판단이 갈리던 4건(PopOnly 채택 / D-7 재역전 / NoneHandler·NilHandler 역할
분담 / 동적 키 경로)은 사용자에게 물어 확정.

커밋 전 검증: quad-doc-auditor 1패스가 1건, 사용자가 돌린
`/code-review high`가 10건을 더 잡아 전부 반영(ROADMAP이 SL-3 역전을 안
따라오던 것, 설계 갭 2건은 새 열린 질문으로 등록). doc-check.py ERROR 0.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 19:39:03 +09:00
d499a68044
qa: 구현 전 QA 1라운드 — base/ 확정 문서 전수 심사 결과 신설
사용자가 "확정으로 적혀 있는 것"을 전부 다시 심사하겠다고 해서,
base/ 25개 문서를 의존성 순서로 훑으며 표면 타입계약/내부 구현
메커니즘/동작 원리 세 층위로 주장을 뽑아 문항으로 확인받았다.
"아니오"가 나온 것만 .claude/pre-implementation-qa.md에 모은다.

정정은 이 커밋에 없다 — 사용자가 "어디가·어떻게·왜 틀렸고 원래 뭐가
맞는지"를 따로 회신하기로 했고, 그 전까지 해당 항목은 미해결 결함으로
두기로 했다. 에이전트가 임의로 고치면 이 QA를 한 이유가 없어진다.

결함/열린항목 20건 + 신규 요구사항 9건 + 부수 오탈자 2건.
특히 두 건은 그대로 구현하면 반대로 돈다:
- S-1  canBound 게이트 호출부 반전 (정상 첫 바인드가 전부 에러,
       이중 바인드는 통과). lifecycle-pattern.md가 진원지고
       source-state-plan/ref-plan이 전부 이걸 인용한다.
- RE-1 gcconn/gchold를 SetStrong으로 적은 두 곳. 그대로 짜면
       같은 문서가 경고하는 두-Relate 상호 강참조 누수에 걸린다.

이 라운드에서 같이 확정된 이름/표면 결정 둘:
- N-8 DI -> D 리네임 (question.md 1순위였던 항목). 네임스페이스는 D로,
      "특수 DI 키"라는 설명 표현은 "특수 키"로 단순화. 라이브 문서
      19개 파일 전수 목록을 표로 넣어둠 — onchange-plan.md의 헤딩과
      lifecycle-hooks-plan.md의 절 인용이 짝으로 묶여 있어 한쪽만
      고치면 doc-check.py가 ERROR로 잡는다.
- N-9 New는 커링(New(name)({...})), D는 전량 코드 생성 산출물.
      index<UIInstances, ClassName> 방식으로는 MouseButton1Click이
      시그널 타입이 돼 콜백 시그니처가 안 나온다는 게 근거 — BS-2가
      요구한 것과 같은 문제의 양면이다. 생성 범위는 GUI에 쓰이는
      인스턴스 전부, 그 밖은 any로 열고 필요하면 사용자가 직접 캐스트.

인덱스 2층 갱신: .claude/README.md 색인, todos.md에 M0 착수 전
이 문서부터 읽으라는 최우선 항목(기존 0번의 "착수를 막는 결정은
없음"보다 우선한다는 것까지 명시).

doc-check.py ERROR 0 확인.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 15:35:53 +09:00
99d9f2c4a3
tooling: 이 레포는 Claude co-author 트레일러 생략, qwreey만 유지
includeCoAuthoredBy: false를 .claude/settings.json에 선언(하네스 버그로
무시되는 게 확인됐지만 고쳐질 때 대비). 실제 억제는 conventions.md 지침을
세션이 지키는 방식으로 보장 — qwreey-bot 계정 자체가 에이전트 커밋임을
드러내므로 이중 표기가 불필요하다는 사용자 판단.

Co-authored-by: qwreey <me@qwreey.moe>
2026-08-18 11:30:55 +09:00
870fa508b6
tooling: 커밋 시 사용자 GitHub 계정 co-author 추가 관례 신설
Co-authored-by: qwreey <me@qwreey.moe>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-18 11:18:49 +09:00
8281f096f9
research: spring-plan에 quad-spring 구현 형태 아이디어 추가
Source<number> 기반 Spring 프리미티브, Springify Apply 체인 슈가,
다필드 타입(UDim2 등)용 타입별 바인딩 필요성, quad-spring/
quad-spring-roblox 패키지 분리안(검토 필요)을 사용자 메모로 반영.
spring.lua 임베딩 의도와 정확성 검증 필요성도 명시.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-18 11:10:23 +09:00
0942c1ca2c
research: 스크롤 최적화(quad-roblox-fastscroll)/스프링(quad-spring) 아이디어 메모 추가
서명을 위해 재커밋

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-18 10:09:39 +09:00
40a5daf694
tooling: 절 인용 규약 신설 + doc-check 절 참조를 ERROR 게이트로 승격
사용자 제기 — doc-check.py가 정규식으로 결정론적 판정을 하는데 표기가 흔들리면
문제가 커지니, 정규식을 늘리기보다 "예상 가능 범위"를 컨벤션으로 좁히는 게 싸지
않냐. 실측해보니 날짜 표기는 이미 100% 균일해서 고칠 게 없었고(강제 장치 없이),
드리프트는 절 인용 쪽이었다 — WARN 86건 중 78건(91%)이 절 참조 불일치.

핵심은 그 78건이 코퍼스가 지저분한 게 아니라 **검사기가 못 읽는 것**이었다는
점이다. 이 코퍼스는 `**볼드**` 줄을 하위 절로 쓰는데 headings()가 `#`만 봤다.

## 동작 변화 (문서 정정으로만 보이지만 게이트가 바뀐다)

- 절 참조 불일치가 **WARN → ERROR**. 이제 절 인용 오류가 커밋을 막는다.
- 절 인식이 `#` 헤딩 + `**볼드**` 절로 확장. 단 볼드는 **빈 줄 다음이나
  리스트 항목 머리**만 인정 — 문단이 줄바꿈되며 우연히 줄머리에 걸린 강조를
  절로 오인하던 걸 커밋 전 감사가 잡아 조였다.
- 인용 길이 상한 60→160자. 60자를 넘으면 매칭 자체가 안 걸려 검사에서
  **조용히** 빠져나갔음(위양성보다 나쁜 구멍).
- 비교를 공백 무시로(줄바꿈 인용 대응), 선두 장식·상태/날짜 태그 정규화,
  `initreq/` 대상 인용은 절 검사 면제(읽기 전용 외부 원본).

## 규약

`conventions.md`에 "문서 표기 규약" 절 신설 — 절 인용 규약(의역 금지, 헤딩은
부분문자열/볼드는 앞부분일치, 태그로 닫히는 볼드 캐비엇, blockquote 함정),
세션은 산문 서수 말고 파일 ID로 지칭. 날짜 마커 라벨 어휘 닫기는 사용자 판단
으로 기각(기계 검사 대상이 아니라 읽는 쪽 판단 재료).

## 결과

절 참조 불일치 78 → 0. 36건은 검사기 수정으로 사라졌고(애초에 위양성), 42건은
인용을 실제 절 제목으로 손으로 고쳤다. 마지막 15건은 서브에이전트 3개에 병렬
위임해 추적 — **설계 서술이 유실된 건은 0건**, 대부분 코드 주석·본문 산문·
주제명처럼 애초에 절이 아닌 걸 절로 인용해온 것이었다.

부수로 드러나 같이 고친 것: onchange-plan이 9차 분할 때 일부러 안 옮긴 절을
잘못된 파일로 가리키던 것, brand-plan이 이미 이행된 정정을 "정정 대상"이라
부르던 것, ROADMAP의 blockquote가 인용 줄바꿈 때문에 깨져 있던 것,
pre-implementation-audit의 해소된 항목이 "아직 안 고침" 절에 남아 있던 것
(사용자 결정으로 "이미 고침"으로 이동).

커밋 전 감사 4라운드(에이전트 8개)를 돌렸고, 발견 추이는 2→2→1→0이다.
매 라운드 발견이 "직전 라운드 수정이 만든 새 결함"이었던 게 특징 — 규약을
세우는 커밋이 그 규약의 첫 위반자가 된다는 걸 실측으로 확인했다. 상세는
.claude/session/2026-08-16-03-doc-check-section-convention.md.

부수: __pycache__를 .gitignore에 추가하고 추적 해제(32e9db0에 실수로 딸려
들어가 있었음). quad-doc-auditor에 작업 트리를 바꾸는 git 명령 금지 규약 추가
— 감사자가 git stash를 걸어 메인 세션 스테이지가 반복적으로 풀렸다.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011zk7XHkSfiBfdPLZUQHdZf
2026-08-16 10:47:29 +09:00
d23d46f746
docs: 감사 루프 4라운드에서 중단(사용자 결정) + 다음 세션 핸드오버 정리
수렴 조건(무발견 2연속)은 못 채웠으나 사용자 결정으로 중단. 발견 추이
6→5→2→2이고 3·4라운드분은 이 세션 변경의 stale이 아니라 코퍼스에 오래
있던 일반 부채(개수 하드코딩, 날짜 없는 시한부 주장)라, 계속 돌리면 수렴이
아니라 옛 부채를 끝없이 캐는 쪽이 된다는 판단. 이 세션 변경분 자체는
안정적(4라운드 설계 코퍼스 각도에서 확실 발견 0건).

todos.md 7번에 중단 사유와 "이번 미수렴 때문에 이어서 돌릴 필요 없음"을
명시하고, 세션 로그에 다음 세션 핸드오버 절(§18) 추가.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 04:05:05 +09:00
01c4abf727
docs: 감사 4라운드 반영 + const는 HUMAN_TODO로 이관(사용자 결정)
사용자 결정 — const 바인딩 재검토는 에이전트가 정할 문제가 아님. 논거:
pesde의 타입 추출(d.ts처럼 types emit)류 툴링이 미성숙해 const를 제공 못
하고 언제 가능해지는지도 불명확하며, 이는 사용자가 확인된 정보로 제공하는
게 맞다는 것. question.md에서 닫고 archive로 옮긴 뒤 HUMAN_TODO.md 8번
신설 — 사용자가 시점을 파악하거나 가능해질 때 에이전트에 알림. 그때까지
에이전트는 "일단 local로" 원칙 유지. architecture.md에 날짜와 논거 반영.

감사 4라운드(설계 코퍼스 각도):
- todos.md의 개수 하드코딩 2건 제거("체크리스트 8개", "11개 전원 완료")
  — 이 프로젝트 자신의 "개수는 소스 하나만" 규칙 위반이던 기존 항목
- 코퍼스 확실 발견 0건(설계 문서 쪽은 깨끗)

주입 경로 실측 둘:
- 에이전트 정의는 이번엔 HEAD보다 1커밋 전 — 뒤처지는 폭이 실행마다 다름을
  관측표에 4번째 행으로 추가
- CLAUDE.md @import 컨텍스트는 세션 시작 시점에 고정됨(감사자가 받은 것이
  세션 시작 커밋과 일치, 그 사이 7커밋). 메인 세션도 동일해 옛 conventions.md
  를 들고 있었음. 동작이 명확한 별개 경로라 conventions.md에 규칙으로 명시 —
  @import 파일을 고친 세션은 기억이 아니라 파일을 직접 Read해서 따를 것

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 04:01:29 +09:00
ebb1fd0f5a
docs: 감사 3라운드 반영 — agent-memory가 재재정정을 안 따라온 사각지대
두 감사자가 독립적으로 같은 확실 발견: agent-memory의 caching 메모리가
"커밋된 HEAD에서 읽힌다"를 여전히 확정 사실로 서술. 그 결론을 반증한 커밋
1935dd4가 agent-memory/ 아래를 하나도 안 건드린 탓 — "변경한 세션 자신은
자기가 뭘 안 건드렸는지 모른다"의 교과서적 사례이고, 같은 파일이 한 세션에
두 번 연속 stale이 된 것이기도 함.

고치면서 그 메모리가 결론을 복제하지 않고 정의 배너를 가리키게만 바꿈 —
같은 사실이 두 곳에 있어 두 번 갈라졌으므로 근본 원인 제거.

그 외:
- todos.md의 매달린 포인터("아래 부수 확정 참고" → 그 헤딩이 직전 라운드에
  "미해결 1/2"로 개명됨)를 정의 배너 참조로 교체
- 관측표에 3라운드 행 추가: 감사자 2개가 마커로 확인한 결과 디스크 현재
  내용과 바이트 동일 → 일관되게 낡은 게 아님이 확인돼 "모른다" 유지 근거가
  늘고, 마커 확인 방식이 작동한다는 것도 재확인

감사자 둘 다 자기 모델을 claude-sonnet-5로 보고 — 트랜스크립트 실측과 일치.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:50:38 +09:00
e0b6c992fa
docs: '감사자가 opus' 관측은 뷰잉 이슈로 해소 — 최상단 배너는 세션 헤더
서브에이전트 뷰 최상단의 'Opus 5 · Claude Max'는 Claude Code 세션 헤더(메인
모델)이지 서브에이전트 모델이 아님(사용자가 화면 직접 확인). 감사자는 다섯
실행 전부 message.model=claude-sonnet-5이고 frontmatter model: sonnet은 정상
동작. 모델을 잘못 읽을 자리 셋(문자열 grep이 usage.iterations에 낚임 / 세션
헤더 / 폐기된 워크플로의 픽스 에이전트는 실제 opus였음)과 신뢰할 소스
하나(트랜스크립트 최상위 message.model)를 세션 로그에 기록.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:48:49 +09:00
1935dd4670
docs: "커밋된 HEAD에서 읽힌다"도 반증 — 가설 세우지 않고 관측표만 남김
2라운드 감사자 둘이 독립적으로 같은 반증을 가져옴: 그들이 받은 정의
지시문이 어느 커밋과도 일치하지 않는 하이브리드였음(배너는 구버전,
"출력 형식"의 사용자 판단 문단은 신버전). git log -S로 독립 확인 — 그
텍스트는 커밋된 적 없는 중간 워킹트리 상태였다.

이 세션은 같은 문제에 세 번 결론을 냈고 앞의 둘("세션 시작 스냅샷",
"커밋된 HEAD")이 다 틀렸으므로 세 번째 가설을 세우지 않는다. 관측표와
실무 규칙 하나만 남김 — 정의를 고쳐도 반영됐다고 가정하지 말고, 중요하면
마커 문구를 넣어 감사자에게 물어 확인할 것(이 반증이 정확히 그 방법으로
나왔음: 2라운드 프롬프트에 마커 확인을 끼워 물었다).

memory: project → Write/Edit 결론은 유지 — 제거 이후 후보 텍스트가 전부
그 옵션을 안 가지므로 정의 불확실성의 영향을 안 받음. 미해결은 tools:
필드 미반영뿐.

2라운드 감사 발견 반영:
- todos.md 항목 7 헤더가 "남은 건 (d) 하나"인데 본문은 (d) 해소라 자기모순
- README.md의 conventions.md 색인 행에 신설된 "설계 원칙" 절 누락
- conventions.md의 "출처 없는 원칙" 경위 서술 중복 축약
- 사용자 판단 등급 판정 기준을 quad-doc-auditor.md "출력 형식"으로 단일화
- session 로그 §2에 "뒤에서 정정됨" 포인터(구체 결론은 안 적음 — 두 번
  뒤집힌 자리라 또 stale해짐)

감사자 모델 재확인: 다섯 실행 전부 message.model=sonnet. 실행마다
message.usage.iterations[]에 opus 항목이 1개씩 붙는 게 오독 원인.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:43:38 +09:00
3721692ed4
chore: agent-memory 추적 시작 — 커밋 전 노출 스캔 + 낡은 결론 정정
사용자 결정으로 .claude/agent-memory/(감사 에이전트의 영속 메모리)를 커밋해
추적하기로 함. 논거: 개발 환경이 다수라 메모리가 레포를 따라다녀야 하고,
실 기록이지 빌드 디펜던시가 아니며, 환경 노출 위험은 SAFETY.md의 파이프라인
(컨테이너 개발 → 프라이빗 git → 검토 후 머징)의 마지막 사람 감사가 방어선.

커밋 전 처리:
- 절대경로/이메일/키/토큰 패턴 스캔 — 노출 소지 없음(히트는 전부 frontmatter
  name: 과 마크다운 링크)
- project_agent_prompt_caching_bug_reproduced.md가 아직 "캐시 가설"로 서술돼
  있어 커밋된 HEAD 모델로 다시 씀(같은 정정으로 memory: project → Write/Edit
  진단이 지지됨을 반영), MEMORY.md 색인 줄도 갱신

README.md의 agent-memory/ 행에 결정과 사용자 논거를 기록 — 추적하는 쪽으로
정해졌으므로 이 폴더 내용도 감사 대상임을 명시.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:38:07 +09:00
07c77e5a5a
docs: 감사 루프 재설계(워크플로 폐기) + 정의 파일은 커밋된 HEAD에서 읽힘으로 재정정
사용자 결정 반영:
- 감사 루프를 Workflow에서 "메인이 quad-doc-auditor를 병렬 호출 → 메인이
  일괄 수정 → 반복"으로 재설계. .claude/workflows/quad-handover-audit.js 삭제,
  절차 소스는 conventions.md "작업 방식". 폐기 근거 셋 — 토큰 과다, 파일별
  픽스 에이전트가 또 부정확한 서술을 생산, 서브에이전트는 사용자에게 못 물음.
- 패스 수는 최소 2에서 변경 규모에 따라 증가. 감사자 모델은 sonnet 유지
  (haiku 배제).
- 출처 없던 원칙 "드문 오용/가상 미래 요구까지 방어·최적화하려고 구조를
  복잡하게 만들지 않는다"를 conventions.md "설계 원칙" 절로 명문화(선택지 a).
  modifier-plan.md 인용을 그쪽으로 재조준, question.md 항목은 archive로 이전.
- 신설 관례: 사용자 발언을 근거로 인용할 때 결론만 적지 말고 논거까지 남길 것
  (논거 원문은 session/에, 라이브 문서는 결론+짧은 논거+포인터).

 재정정 — 직전 커밋의 "정의 파일은 세션 시작 시점 스냅샷" 결론은 틀렸음.
정의는 워킹트리가 아니라 **커밋된 HEAD**에서 읽힌다(감사 패스가 받은 지시문이
세션 도중 만든 HEAD 커밋의 blob과 바이트 단위로 동일, git rev-parse로 독립
확인). 규칙이 "재시작"에서 "고쳤으면 커밋 후 실행"으로 싸짐. 이 정정으로
오래 미확정이던 (d)도 해소 — memory: project가 Write/Edit을 딸려온다는 진단이
맞았고, "빼도 그대로"로 보였던 건 제거가 아직 커밋 안 됐던 탓. 남은 미해결은
tools: 필드 미반영뿐.

첫 감사 라운드(새 절차) 반영: 자기 메모리 2건의 stale 서술,
documentation-content-map.md "943줄, 최대 문서"(실측 203줄, 최대는 slot-plan
1970줄), README.md 패스 수 하드코딩. 직전 커밋의 미재감사 6건은 회귀 없음으로
확인해 todos.md ⚠️ 블록 닫음.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:32:09 +09:00
134379632f
docs: 스냅샷 주장 축소 — 워크플로는 name=스냅샷/scriptPath=실시간, 재감사 누락 명시
직전 커밋(298dac2)이 "정의 파일은 세션 시작 시점 스냅샷으로 고정된다
(에이전트·워크플로 공통)"고 일반화했는데, 그건 증거보다 센 주장이었다 —
scriptPath 경로를 테스트한 적이 없었다. 프로브로 갈랐음:

- Workflow({name}) = 세션 시작 시점 스냅샷 (실행된 스크립트가 세션 시작
  상태와 바이트 단위 동일, 같은 세션 편집 반영 0)
- Workflow({scriptPath}) = 디스크 실시간 (세션 시작 후 새로 만든 스크립트가
  실행되고, 고친 뒤 다시 부르니 고친 값이 반환됨)

따라서 워크플로 쪽 해법은 세션 재시작이 아니라 scriptPath다 — conventions.md의
핸드오버 감사 절차에 반영. 에이전트 정의 stale은 자기 보고뿐이라 근거 등급이
낮음을 명시하고(Grep/Glob 불일치와 같은 등급), 우회 수단이 없으니 재시작을
보수적 해법으로 유지.

또 첫 실동이 수렴 못 하고 최대 라운드로 끊긴 결과, 마지막 라운드의 발견
6건이 반영만 되고 재감사되지 않은 채 커밋됐다는 것을 todos.md/세션 로그에
명시 — 다음 실동의 첫 임무. README.md의 audit/ "현재 6개"(실제 7개)도
폴더-소스로 전환.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 03:05:40 +09:00