두 감사자가 독립적으로 같은 확실 발견: 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>
12 KiB
지금 할 일 (우선순위순)
루트 CLAUDE.md가 @import 하는 파일. 가장 자주 바뀜 — 해소된 항목은
미루지 말고 그 자리에서 지우고, 개수·목록은 여기 적지 말고 소스를 가리킬 것
(.claude/question.md, luau-test/STATUS.md 등).
-
⭐ M0 착수를 막는 결정은 이제 없음 (2026-08-14 열한 번째 세션 기준).
question.md의 최우선 항목이 전부 비었음 —0-Y(:Computelazy 핸들 계약)는 13차 세션에,0-Z(Attribute 이름 소유권)와0-A(재디스패치 하강 diff)는 14차 세션에,0-B(dispose시그니처/범위)는 2026-08-14 열 번째 세션에 확정·base/반영 완료.0-W(같은Ref이중 배치, M8 구현 세부만 막던 항목)도 2026-08-14 열한 번째 세션에 해소 — 선택지 (a) 채택(즉시 error), 메커니즘은 새Relate없이bindLifetime/unbindLifetime재사용(base/ref-plan.md"이중 배치 방지" 절). 부수 결정으로canBound가canExecute와 별도 진입점으로 재도입됨(2026-08-14 다섯 번째 세션에 하나로 합쳤던 걸 부분적으로 되짚음 — "이미 묶여 있는가"(bound 문맥)와 "지금 발화해도 되는가" (execute 문맥)는 판정 로직은 공유해도 호출부의 질문이 다르다는 사용자 지적,base/lifecycle-pattern.md의 "canBoundvscanExecute" 절).question.md엔 이제 "결정 대기" 절 자체가 없음(비어서 헤딩째로 삭제).M0 착수 전 반드시 읽을 것 — 이 두 개는 "결정"이 아니라 "구현 규약"이라 여전히 유효:
base/typing-limits.md(0-Y의 산물) — 핵심은 "파생 State를 만드는 자리마다 결과 타입을 명시 주석으로 바인딩" + 7번 설계 체크리스트. 재귀 제네릭이 자기를 다른 타입 인자로 반환하면 Luau가 타입 안전성을 에러 없이 조용히 잃는 상위 한계라 quad 쪽에서 우회하지 않기로 확정(RFCrelax-recursive-type-restriction수혜 대기, 추적luau-lang/luau#2380). 실측 근거는audit/type-recursion-issue/.base/dispatch-core-plan.md(0-A/0-Z의 산물, 14차 세션에bind-system-plan.md에서 분리 신설) — 재디스패치가 "철거 후 재구축"이 아니라 하강 diff임,retractFrom은 3-인자, 클로저 인자는nil이거나 같은 핸들러가 처리할 값(타입 보장),HANDLER_PRIORITY_FALLBACK, "base가 소유하는 핸들러와 주입되는 엔진 op"(addTag/removeTag/setAttribute). Handler 작성 체크리스트 8개를 새 핸들러 짜기 전에 훑을 것 — 지난 세션들에서 실제로 반복된 실수 목록임.
해소 전 원문은
archive/question-resolved.md(0-Y/0-Z/0-A 절), 뒤집힌 옛 재디스패치 모델 전문은archive/dispatch-hintvalue-model-reversed.md. -
구현 시작 — 루트
ROADMAP.md의 M0부터. 설계 단계는 2026-08-04 로드맵 인수인계 라운드로 종료.research/pre-implementation-audit.md우선순위1은 2026-08-12 열일곱 번째 세션에 마지막 넷(1-3/1-4/1-10/1-11)까지 전부 해소되어 11개 전원 완료. [14차 세션 기준] 0-Y/0-Z/0-A까지 전부 해소돼 설계 게이트는 남아있지 않음 — 착수 전 읽을 것은 위 0번의 두 문서(typing-limits.md/dispatch-core-plan.md)뿐이고, 스파이크 상태는 아래 그대로:.claude/luau-test/(2026-08-09 신설) 스파이크 결과 — [2026-08-13 여섯 번째 세션에 첫 실측 완료, 대부분 닫힘]. 상태의 소스는 항상.claude/luau-test/STATUS.md(pass / 사람 결정 필요 / 스파이크 깨짐 / 미실행, 폴더 구조 자체가 상태) — 총 몇 개인지도, 지금 몇 개가 어느 폴더에 있는지도 여기서 세거나 나열 안 함(04/05/10/13/15/16/19가 여러 세션에 걸쳐 재설계로rewrite-required/에 들고나며 이 문단의 나열이 매번 stale해지는 패턴이 반복됐음, 최근엔 8차 세션의 "emit은 항상 전파" 정정으로05도 합류). 실행 결과 상세는.claude/audit/luau-test-first-run-2026-08-13.md. 첫 실측 요지만 (역사적 사실 — 이후 변동은 위처럼STATUS.md가 소스):- 런타임 12개 전원 통과(01~07/11/17/18/19/20, crash 0 / FAIL 0) —
특히
07이 연쇄 GC를,18이 두-Relate상호 순환 미해제를 실측 확정해 GC-native 아키텍처의 핵심 전제가 검증됨.04는 같은 세션 감사가 찾은chains:SetStrong순서 버그를 음성 대조군으로 재현. - 타입 쪽에서 하나가 걸렸었음 → 그게 구 0-Y, [13차 세션]
해소(Luau 현 한계로 확정,
base/typing-limits.md). 나머지 타입 스파이크는 판정 완료(08/09통과,12는 실패지만 문서가 이미 fallback으로 예비해둔 결과라 설계 영향 없음,14는 부분). 지금 M0 착수를 막는 설계 결정은 없고, 0-Y/0-A가 남긴 규약 (base/typing-limits.md/base/dispatch-core-plan.md)은 착수 전 필독.
- 런타임 12개 전원 통과(01~07/11/17/18/19/20, crash 0 / FAIL 0) —
특히
-
용어 정리 — 1차 제안 이후 대부분 확정, 소수만 남음. 최신 소스는
.claude/question.md1번(개수 반복 안 함, 항목 추가/해소될 때마다 여기가 stale해지는 패턴이 반복됐어서). [2026-08-13 정정]State는 2026-08-12 스무 번째 세션에 현재 이름 그대로 유지로 이미 확정됐음(이 목록이 "위험도 높음, 1순위 open"으로 stale하게 남아있던 걸 발견해 수정) — 아직 진짜로 열려있는 것만 짚으면:DI→D(1순위),Slot(2순위),canExecute(3순위 —isAlive는 검토 후 기각,can계열 접두 유지 방향으로 기울었으나 구체 대안 미정),Brand(3순위),Tag/Added/Removed/Merged(3순위),Attribute/AttributeKey(3순위). -
[2026-08-14 세션에 해소] 오래 열려 있던 "이미 생성된 인스턴스 재바인드"는 기각되어
archive/existing-instance-bind-rejected.md로 이전됨 — 더 이상 상의할 스코프 항목이 아님. -
[백로그] 범용 렌더 디버깅 도구
quad-mock(Tween mock 등 동적 동작 지원, M0 mock 테스트 하네스와는 별개), 런타임 디버깅 플러그인quad-debug(Studio 플러그인, 실물 Instance→코드 위치 역추적 — 채널 실현 가능성은 실측 검증 완료, 세부 API 이름만 남음), 문서 사이트 전체 구조(초심자/api/심화/quadnomicon4축 + 콘텐츠 맵),Operator콤비네이터 슈가(Sum/Product/Not/비트연산 등:Compute/:Apply용 — 메커니즘은 확정, 네임스페이스 이름만 미정, 구현은 순수 슈가라 맨 마지막), 컴포넌트 에러 격리 유틸Fallback/Traceback([2026-08-14 세션, 설계 확정 —research/에서base/fallback-plan.md로 승격]pcall기반Fallback과xpcall+debug.traceback기반Traceback으로 분리,err: any확정, 패키지·이름 전부 확정 — 설계만 끝났을 뿐 구현 우선순위는 그대로 맨 뒤), 생명주기 훅OnCreated/OnRendered/OnDestroyed([2026-08-14 아홉 번째 세션,research/에서base/lifecycle-hooks-plan.md로 승격] 각각PreRef/PostRef/Effect를 반환하는 순수 팩토리 함수 슈가 —OnRendered도 채택 확정, 그게 얹히는PostRef프리미티브 자체는 슈가가 아니라 디스패치 코어라 ROADMAP M8에서PreRef와 같이 구현됨 (백로그가 아님,base/ref-plan.md의 "PostRef" 절). 훅 슈가 셋만 후순위) — 전부 "quad 개발 상당 부분 끝난 뒤"로 사용자가 못박은 후순위. 상세는.claude/README.md의base/표(fallback-plan.md/lifecycle-hooks-plan.md)와research/표 (debug-tooling-plan.md/documentation-plan.md/documentation-content-map.md/framework-comparison-findings.md/operator-sugar-plan.md). [2026-08-14 추가, 성격이 다름] 시간 기반 전파 게이트Debounce/Throttle(research/debounce-throttle-plan.md)도 백로그이긴 하나 위 항목들과 달리 사용자가 직접 요청한 실제 기능 갭이고 순수 슈가가 아님 — M0/M3를 막지는 않지만, M3에서Blocker를 구현할 때 게이티드 노드를 공용Gate로 빼두는 것만은 그 시점에 해야 함(따로 하면 같은 설계를 두 번 함). 주입 op 2개(setTimeout/clearTimeout)가 백엔드 팩토리 표면에 추가될 예정이라는 것도 M1 설계 시 인지. 설계는 네 라운드로 대부분 확정됐고 남은 열린 질문은question.md3번(개수는 거기도 반복 안 함 — 소스는research/debounce-throttle-plan.md12절). -
자율 작업 루프/스케줄 설정 여부는 사용자 결정 대기 중 (
HUMAN_TODO.md2번 항목). -
[신규 백로그, 2026-08-14 열네 번째 세션] 문서 stale 감소용 include 도구
doc-include.py(가칭,doc-check.py와 짝) —research/ doc-include-plan.md참고(상태의 소스는 그 문서). [2026-08-16 기준] 같은 날 CLAUDE.md 분할로 파일럿이 "session-summary.md를 통째로 생성"하는 단방향 설계로 단순화돼 플랜이 갱신됨(목적지 마커 불필요). 여전히 구현 착수 전. M0/설계 게이트와 무관. -
[2026-08-16 신설, (a)~(d) 전부 닫힘 — 다만 아래 두 건이 미해결로 남음] 감사 툴링 검증. (a)
@import3개(conventions.md/project-context.md/todos.md) 실제 로드 — 확인됨, (b)quad-doc-auditor레지스트리 등록 — 확인됨(첫 실측 때 전원agentType not found였던 건.claude/agents/가 세션 도중 생긴 디렉토리였기 때문, 재시작으로 해소), (c) frontmattermodel: sonnet반영 — 확인됨(서브에이전트 트랜스크립트에claude-sonnet-5기록), (d) 해소 — 읽기 전용인데 Write/Edit이 주어지던 원인은memory: project가 맞았음(근거는.claude/agents/quad-doc-auditor.md상단 배너). 다만tools:필드가 그대로 반영되지 않는 건 여전히 미해결이라, 읽기 전용은 도구 유무가 아니라 프롬프트의 행동 규약으로 계속 지킨다.미해결 1 — 정의 파일이 언제 반영되는지 모른다. 감사자가 실제로 받은 정의 텍스트가 실행마다 달랐다: 세션 시작 상태 → 그 시점 HEAD 커밋 → 어느 커밋과도 일치하지 않는 중간 워킹트리 상태(커밋된 적 없음,
git log -S로 확인). 이 세션이 "세션 시작 스냅샷", 이어서 "커밋된 HEAD에서 읽힌다"로 두 번 결론을 냈다가 두 번 다 반증됐으니 세 번째 가설을 세우지 말 것. 실무 규칙은 하나 — 정의를 고쳐도 반영됐다고 가정하지 말고, 중요하면 마커 문구를 넣어 감사자에게 물어 확인할 것. 상세 관측표는.claude/agents/quad-doc-auditor.md상단 배너가 소스. (워크플로 쪽은Workflow({scriptPath})가 디스크에서 실시간으로 읽는 게 확인돼 있으나, 지금 워크플로를 안 쓰므로 당장 쓸 일은 없음.)미해결 2 —
tools:필드가 그대로 반영되지 않는다: frontmatter에 적힌 Grep/Glob이 안 주어지고, 적지 않은advisor가 주어진다. 그래서 감사자의 읽기 전용은 도구 유무가 아니라 프롬프트의 행동 규약으로 지킨다.[2026-08-16 닫힘] 재감사 안 됐던 수정 6건은 확인 완료 — 첫 실동이 수렴 못 하고 끊겨 마지막 라운드분이 재감사 없이 커밋됐었는데, 새 절차의 첫 라운드(감사 2개 병렬)가 그 셋(spikes 개수 단일화,
slot-plan.md재역전 배너,doc-check.pydocstring)을 다시 훑어 회귀 없음으로 확인했다. 한 패스는 구세대 트리(8aeec76)와 현재본의 WARN 목록을 직접 diff해서 대조했고, 그 구간에 오히려 절 참조 오류 2건이 해소된 것도 확인됨. M0/설계 게이트와 무관.