qwreey-bot/quad
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
quad/.claude/session/2026-08-19-06-runinit-redesign-and-darklua-precision.md
qwreey-agent-selene 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

4.3 KiB
Raw Blame History

2026-08-19, 여섯 번째 세션 — RunInit 재설계, darklua 경계 정밀화

요약: 사용자가 두 가지를 요청. (1) 지난 darklua 기각 근거를 실측으로 정밀화, (2) New()의 멱등 Init 가드를 파일마다 Relate+센티널을 두는 대신 **함수 자체를 릴레이션 키로 쓰는 공유 module:RunInit(initFn)**로 재설계. 둘 다 실제로 구현·검증까지 완료. 이후 대화는 한국어로 진행하기로 합의.

1. darklua 경계 실측 — @self/@game은 안 건드리고, 커스텀 alias만 변환

darklua 0.19.0을 직접 설치해 참고 레포(initreq/roblox-project-example)에서 pesde install+rojo sourcemap+darklua process를 실제로 돌려봄:

  • require("@self/X")/require("@game/...")는 convert_require가 손을 안 대고 경고만 찍은 채 원문 그대로 통과(unknown source name).
  • 커스텀 .luaurc alias(@pkg)는 실제로 require(game:GetService('ReplicatedStorage'):WaitForChild('roblox_packages'):WaitForChild('assets'))로 치환됨 — .luaurc 매핑 + Rojo sourcemap을 같이 읽어 해석.

결론: quad는 상대경로+@self만 쓰므로 지금 darklua는 정말 불필요하지만, 나중에 @pkg/quad_base류 축약 alias를 쓰고 싶어지면 그때는 darklua가 실질적으로 필요해진다 — project-setup-plan.md에 이 경계를 정확히 반영.

2. RunInit 재설계

사용자 제안: 모듈 설정 완료 여부 릴레이션을 파일마다(INITED 센티널 + Relate()) 따로 두지 말고, 함수 자체를 릴레이션 키로 쓰고 module.RunInit(initfun: (module)->any)를 구현해 "실행한 적 없으면 실행"을 전담시키자는 것. 근거: (any)->any : boolean? 형태의 릴레이션이 간단하고, 파일마다 보일러플레이트를 반복할 이유가 없음.

실제로 반영:

  • quad-base/src/init.luau — 최상위에 runInitRelate = Relate() 하나만 두고, module.RunInit(self, initFn)이 (module, initFn) -> boolean? 릴레이션으로 실행 여부를 판정. Quad 타입에 RunInit 필드 추가.
  • quad-base/src/Debug/init.luau — 가드 보일러플레이트 전부 삭제, 그냥 무조건 module.debug = false만(멱등은 호출부 RunInit이 보장).
  • quad-base/test/smoke.init.luau 신설 — 같은 initFn 재호출 시 1회만 실행, 서로 다른 New() 인스턴스는 기록 비공유, 서로 다른 initFn은 서로 무간섭 — 3개 시나리오 전부 검증. selene이 assert 메시지 누락/미사용 매개변수 몇 건을 잡아 같이 수정.
  • luau/luau-analyze/selene 셋 다 클린.
  • module-lifecycle-plan.md "New()의 내부 구성" 절 — 옛 파일별 센티널 의사코드를 새 RunInit 의사코드로 교체, 근거·GC 특성· _initializedBy와의 층위 차이 재서술.

3. 미결 — RunInit을 backend 설치 진입점에도 재사용할지

사용자 질문: RunInit을 QuadRoblox(Quad) -> QuadRoblox(backend 주입 진입점) 내부에서도 그대로 써도 되는지. 답은 아직 안 냄 — RunInit은 함수 identity로만 추적하는데, backend 가드(base/bind-system-plan.md의 "Bind는 누가, 어떻게 구현하는가" 절)는 "같은 팩토리 재호출=no-op, 다른 팩토리=에러"라는 계약이 있어서, InitRoblox/InitGtk처럼 서로 다른 함수가 같은 "백엔드 슬롯"을 다투는 상황을 RunInit은 구분 못함(둘 다 "아직 안 돈 함수"라 각자 조용히 실행되어 버림 — 에러가 나야 하는데 안 남). 슬롯 키를 별도로 감싸는 방안을 떠올렸으나 결론은 안 냄 — module-lifecycle-plan.md에 ⚠️ 미결로 반영, M2/M5 착수 전 확인 필요.

4. 타입 관련 질문 — 답변 보류

사용자가 "pesde가 타입만 뽑아주는 게 있다고 들었다"며 quad-roblox가 quad-base 타입을 그걸로 갖게 되는지 물음. 워크스페이스 링크(심볼릭 링크로 연결된 실제 소스)를 통한 타입 추론은 이미 지난 세션에 실측 확인됐고 이 메커니즘과는 무관해 보이지만, HUMAN_TODO.md 8번이 말하는 "pesde의 타입 추출"(d.ts류, const 지원과 엮인) 기능 자체를 이 세션이 따로 조사하지 않아 정확한 답은 다음 턴에서 이어감.

5. 이후 진행

사용자 요청으로 이제부터 대화를 한국어로 진행.