qwreey
3d9e48f5f1
사용자 확정 사항 반영: 브리지는 v2→v1 단방향만, 패키지명 quad-roblox-v1-compat. v1 mount.lua/class.lua(Update 재렌더 시 __child 재부모, Clone 트리거 조건, cascading destroy 의존)와 v2 slot-plan.md(단일 마운트 소유권, retract=폐기, foreign Instance 처리 미명시)를 대조 조사해 두 임베딩 방향(v2 트리에 v1 리프 박기 / v1 트리 요소를 v2로 점진 교체)에 대한 구체적 안전 규칙을 도출. Slot이 quad 밖에서 만들어진 Instance를 어떻게 다루는지만 Slot 코어 구현 시점까지 결정 불가로 남겨 question.md에 교차 참조 추가. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| base | ||
| research | ||
| question.md | ||
| README.md | ||
.claude/ — quad-v2 계획/설계 문서 색인
이 레포 전체가 quad-v2(재작성) 프로젝트이므로, webmanager류 서브프로젝트 구분 없이
.claude/ 바로 아래에 전부 있음. 루트 CLAUDE.md가 현재 상태+TODO 색인의
최종 소스 — 먼저 그걸 보고, 특정 결정의 자세한 근거/논의가 필요할 때만 아래
개별 문서를 열어볼 것.
폴더 기준
| 폴더 | 기준 |
|---|---|
base/ |
결정 완료 + 프로젝트 전체에 걸치는 컨텍스트 — plan/done 개념 없음, 계속 참조되는 배경지식 |
research/ |
아직 착수 전, 사용자와 스코프/설계를 더 상의해야 함 |
qa-request/ |
구현 완료(코드/에이전트 검증까지 끝남) + 사용자 본인의 실기기(Roblox Studio) QA만 남음 — 지금은 구현 자체가 시작 전이라 비어있음 |
archive/ |
완료 + 사용자가 실사용/실기기로 직접 검증까지 마침 — 지금은 비어있음 |
feedback/ |
실사용 피드백을 정리한 긴 로그 — 지금은 비어있음(구현 시작 전) |
initreq/ |
프로젝트 착수 시 클론해둔 참고 레포(quad v1, fusion, vide, rbvm, tbox, code-docker) + PA님 실 코드(artworks/, 4차 라운드 교차검증 근거) + 원본 요청(req.md, raw-userinput.md) + quad2-try(이전에 시도했다 폐기한 v2 재작성 시도 — 리서치 완료, 결론은 base/bind-system-plan.md) — 읽기 전용 리서치 소스, 여기 내용을 옮기지 말고 항상 원본 그대로 유지 |
research/의 문서가 설계 확정되면 base/로 승격(또는 구현 착수 시
qa-request/행). 지금은 구현 라운드 전(설계 단계)이라 전부 base//research/에만
있음.
base/ — 결정된 것, 프로젝트 전체 컨텍스트
| 문서 | 내용 |
|---|---|
architecture.md |
quad-v2 전체 아키텍처 확정 사항 요약(제일 먼저 볼 문서) |
quad-v1-architecture.md |
v1(initreq/quad) 내부 동작 스냅샷 — "이 문제를 안 반복하려면"의 기준선 |
comparison-fusion-vide.md |
Fusion/Vide 아키텍처 비교 리서치 — 설계 결정 근거 자료(전파 모델 등 일부 서술은 이후 라운드에서 뒤집혔으니 bind-system-plan.md 쪽을 최신으로 볼 것) |
lifecycle-pattern.md |
rbvm의 Connected+GC 관용구를 quad-v2가 채택하는 방식 |
store-semantics.md |
Store는 부작용 허용이 기본. State는 Store 위의 조합 가능한 캐시 레이어로 실제로 필요함(2026-08-04 정정) — 온톨로지 핵심 메커니즘은 2026-08-04 2차 라운드에서 확정, 최신 상세는 base/bind-system-plan.md |
bind-system-plan.md |
pluggable key/value 핸들러 레지스트리 — process/retract 디스패치 모델, Ref, Store/State/Source 온톨로지 + 인체공학 질문 전부 확정. 디스패치 엔진은 quad-base가 인터페이스로 소유(2026-08-04 5차 라운드) |
module-lifecycle-plan.md |
프로바이더 패턴, bind/store 구현 책임 분리 — 확정 |
slot-plan.md |
뮤터블 자식 배열, 엄격한 단일 마운트 소유권, 재마운트 시 throw, base/roblox 패키지 경계까지 확정 |
modifier-plan.md |
Modifier는 런타임 plug 아닌 정적 merge, immutable+clone 기반 체이닝 — 메커니즘 확정, getter 이름만 남음 |
purity-and-effects-plan.md |
컴포넌트 "순수성"이 아니라 "이식성" 문제로 재정의 — 문서 경고 수준으로 확정 |
research/ — 아직 착수 전, 상의 필요
| 문서 | 내용 | 우선순위 |
|---|---|---|
tween-plan.md |
트윈을 Store 밖 특수 bind key로 처리, 기본 오버라이드는 Cancel | 중 — 세부 옵션만 남음 |
existing-instance-bind-plan.md |
이미 생성된 인스턴스 재바인드 — 착수 안 하되 "미지원" 확정도 안 함, 열린 가능성 유지 | 하 — v2 초기 스코프 제외 |
component-composition-plan.md |
컴포넌트=플레인 함수, State/Source 읽기·쓰기 경계, StoreSource 프록시 — 핵심 골격 수렴, modifier/Ref가 컴포넌트 경계를 어떻게 통과하는지만 남음 |
상 — 사용자가 "가장 문제되는 부분"으로 직접 지목 |
debug-tooling-plan.md |
실물 Instance→코드 위치 역추적 Studio 플러그인(quad-debug) — 채널 실현 가능성(BindableEvent/Function 크로스 컨텍스트)까지 실측 검증 완료, 세부 API 이름·구현만 남음 |
하 — 사용자가 "quad 개발 완료 전엔 착수 못 함"으로 직접 후순위 지정, base 설계 시 훅 확장 지점만 고려 |
documentation-plan.md |
UI 네이밍 컨벤션 문서 + Store 부작용을 게임 시스템에서 깔끔하게 쓰는 패턴 문서 — 뼈대만, debug-tooling-plan.md 논의에서 파생 |
하 — 착수 시점 미정, 뼈대만 기록해둔 상태 |
ui-shorthand-plan.md |
UICorner/UIPadding/UIScale 인라인 편의 키(v1 Corner/PaddingAll/Scale 선례) — 여전히 필요한 기능으로 재확정(RoundSize만 네이티브 UICorner로 대체돼 불필요), 메커니즘(Handler)·패키지 배치(quad-roblox 코어) 확정 |
하 — 결론 남, M10 전후 구현하면 됨 |
v1-compat-plan.md |
v1 하위호환(compat) 레이어 — quad-roblox-v1-compat 패키지, v2→v1 단방향 브리지(state:Observer()+v1 프로퍼티 재대입), v2-in-v1/v1-in-v2 두 임베딩 방향의 기술 규칙까지 확정. quad2-try의 quad-compat은 빈 폴더로 실제 시도된 적 없었음을 확인 |
하 — Slot이 foreign Instance를 어떻게 다루는지만 Slot 코어 구현 시점까지 미결 |
참고
- 저장소 소유자가 답해야 할 질문 전체 취합:
.claude/question.md - 사람만 할 수 있는 일(로컬 조작/결정): 루트
HUMAN_TODO.md - 원본 브레인스토밍(raw chain-of-thought):
.claude/initreq/raw-userinput.md,.claude/initreq/req.md— 위 문서들로 나누기 전의 원본, 참고용 백업이니 그대로 둘 것