# `quad-spring` — 스프링 물리 기반 지속 업데이트 프리미티브 (아이디어 메모)

**상태**: research 착수 전 — 사용자 노트를 그대로 옮겨 적은 **아이디어
메모**. 설계 논의는 아직 없었고, 사용자가 "모든게 완성된 후, 별도
모듈로 분화"라고 직접 못박은 **아주 나중** 항목.

## 아이디어

특정 Spring 설정을 받아 이전 상태와 비교해 스프링 물리 연산을 수행해주는
**중간 핸들러**(intermediate handler). StoreBind와 비슷한 구조로 별도
핸들러 하나를 만들 수 있을 것으로 보인다는 원문 메모(원문: "스토어바인드도
비슷하게 핸들러 하나 생성 가능할 수 있음").

기각된 직접 `Tween` 접근(과거 특수 bind key 모델, `archive/tween-special-bind-key-reversed.md`)과는
성격이 다르다 — 이건 `Tween`만으로 간결히 해결되지 않는 **인터랙티브
디자인** 상황(사용자 입력에 실시간으로 반응하는 감쇠/타겟 추적)을 위한
**지속 업데이트되는** primitive를 염두에 둔 것. 확정된 `Tween<T>` 모델
(`base/tween-plan.md`)과는 별도 트랙으로 취급.

## 참고 구현

[qwreey/spring.lua](https://github.com/qwreey/spring.lua/blob/master/main.lua) —
사용자 본인의 기존 구현. 사용 가능 여부(라이선스/의존성/quad 아키텍처와의
정합성) 확인이 필요하다고 원문에 명시.

## 구현 방향 후보 (미정)

두 갈래가 거론됐고 아직 어느 쪽도 확정되지 않았다:

1. **엔진 중립 후킹**: `quad-base`가 `onStep`류 프레임 단위 처리 후킹
   인터페이스를 제공하고, 그 위에 스프링 primitive를 얹는 방식. 원문에서
   사용자가 "기본 생각으론 후킹이 맞다 보긴 하는데"로 약하게 기운
   방향이지만 확정은 아님.
2. **엔진별 개별 구현**: `quad-roblox-spring`처럼 엔진마다 각자 맞게
   개발하는 방식.

또는 별도 방향으로 — `Source<number>`를 확장해 damping/target 등 스프링
파라미터를 가진, **자기 자신에 계속 emit하는** 프리미티브를 primitive
레벨에 두는 안도 언급됨. 이 형태면 다른 `:Compute` 체인과 자연스럽게
엮일 수 있다는 게 사용자 관찰.

**결정 시점**: quad 코어가 충분히 개발되어 이런 pluggable 요소가 더
필요해지는 시점에 판단 — 지금은 방향을 좁히지 않고 후보만 기록.

## 우선순위

최하 — "모든게 완성된 후, 별도 모듈로 분화"라고 사용자가 직접 명시. M0
설계 게이트와 무관.