qwreey-bot/quad
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
quad/.claude/session/2026-08-08-05-terminology-round.md
qwreey 1f56c75978
chore(docs): split CLAUDE.md session log into .claude/session/, keep 2-4 line summaries 
CLAUDE.md had grown to 3196 lines of accumulated session logs, causing
context bloat. Full session narratives (including trial-and-error and
later-corrected reasoning — quadnomicon devlog raw material) now live
as 39 individual files under .claude/session/. CLAUDE.md keeps only a
short "지금 할 일" (re-synced against question.md/pre-implementation-audit.md,
stale detail dropped) and a compact per-session summary+link table.
No design decisions changed; base/research/question.md were already
in sync with every session (verified against README.md/question.md
before archiving), so no unreflected content needed migrating first.
2026-08-11 14:40:43 +09:00

3.4 KiB
Raw Permalink Blame History

2026-08-08 다섯 번째 세션 — 용어 정리 라운드 정리: Handler/None·

NoneHandler/Ref/PreRef/Peek/isState 이름 확정, DI→D/ canExecute→isAlive는 계속 미정으로 재확인

사용자가 .claude/question.md의 3순위(사소함) 용어 재검토 목록을 훑으며 한 번에 여러 개를 정리 — 전부 .claude/question.md "1. 용어 정리" 절과 base/module-lifecycle-plan.md에 반영 완료:

  • Ref/PreRef/Peek/isState — 전부 현재 이름 그대로 확정(더 나은 대안 없음). Ref는 "지연 없는 확정된 값 박스"라는 정의를 재확인 — leaf 노드를 담는 용도로도, leaf 노드에 바인딩하는 용도로도 쓰인다는 게 넓어진 정의에도 여전히 맞다는 근거.
  • None/NoneHandler — 확정. Undefined/Null/Nothing도 검토했으나 Null은 보통 "포인터가 비어있음"(0)을 뜻해 "값이 없음"이라는 의도와 미묘하게 안 맞는다는 이유로 기각, None이 나음.
  • "프로바이더" → Handler로 확정, 기각 이유 보강. 이미 module-lifecycle-plan.md에 [해소됨]으로 반영은 돼 있었으나 question.md 목록에 stale로 남아있던 걸 정리. Processor는 계약 메소드 자체가 process라 이름이 겹쳐 거슬림, Provider는 canProvide처럼 "공급한다"는 늬앙스인데 실제로는 처리/반응하는 쪽이라 안 맞고 React Context.Provider류와도 헷갈릴 수 있음, Plug는 "꽂힌다"는 어감은 맞지만 "처리한다"는 의미가 빠져있음 — Handler가 계약(isHandlable/priority/process/retract) 전체를 가장 정확히 담는다는 결론.
  • DI → D는 아직 미확정. 사용자가 "Declarative만 남기고 D로 줄이자"는 안을 제안 — Instance 전용이 아니라 quad-* 전반의 declare 요소로 확장 가능하고, 엔진 종속 없이 재사용 가능하며, D.FrameModifier 류 타입 프리픽스가 짧아야 한다는 실용적 이유까지 근거로 나쁘지 않은 제안이나, 한 글자 식별자의 검색성/자기설명력 트레이드오프를 문서에서 어떻게 보완할지가 남아 다음에 마저 결정하기로 함.
  • canExecute → isAlive도 계속 미정, 방향만 정리. isAlive가 의미는 더 정확하지만 top-level isX 타입 판별자 계열(isState/isRef/ isPreRef/isModifier/isObserver)과 접두어가 겹쳐 "이것도 타입 체크인가" 오해를 유발할 위험이 지적됨 — canExecute는 타입이 아니라 liveness를 묻는 질문이라 is보다 can 계열 접두를 유지하는 쪽으로 사용자가 기욺, 구체 대안(canRun 등)은 다음에.
  • Brand는 이번에도 다시 짚었지만 여전히 미정으로 재확인만 함.

다음 세션이 할 일: 안 바뀜(ROADMAP.md M0부터). DI/D와 canExecute/isAlive 두 개만 용어 정리 라운드에 계속 남음 — question.md 1순위/3순위 목록 참고.