디자인 SSOT 를 세우고 3D 를 배경 재질로 되돌린다

지적받은 것: 모바일 마진·패딩, 폰트 웨이트, 버튼 스타일 불일치, SSOT,
스크롤바, 모바일 메뉴, 그리고 3D 를 왜 상자에 넣었는지.

3D 의 역할을 잘못 잡았다
  lusion.co 의 "3D 는 액자 안"은 3D 자체가 상품일 때의 규칙이다.
  우리는 절차를 파는데 액자에 넣을 상품이 없어 "저 상자는 뭐냐"가 됐고,
  의미를 게이트 판독기가 자막으로 설명하고 있었다.
  이 씬의 역할은 재질이다. 배경으로 되돌리고 값을 전부 낮췄다 —
  테두리 광 0.85->0.42, 알파 0.72->0.34, UV 경계 0.05->0.17, 이동 60%
  ResizeObserver 로 캔버스를 따라가게 했다. window.resize 만 듣는 동안
  히어로 높이 변화를 놓쳐 배경이 화면의 3분의 2만 덮었다

SSOT
  웨이트 6종(400/500/560/600/620/660) -> 3종. 셋은 토큰에 없던 값이었다
  .btn + btn-solid/btn-quiet. 두 버튼이 높이 36 vs 44, 패딩 16 vs 8,
    테두리 1px vs 0, 웨이트 400 vs 500 이었다
  --header-h. 간격을 clamp 로 바꾸자 관계가 끊겨 h1 이 헤더 뒤로 들어갔다
  --space-5~8 과 --gutter 를 clamp 로. 고정이면 모바일 여백이 화면의 26%
  scrollbar-color 지정

모바일
  좌우 여백 24 -> 32px, 섹션 상하 112 -> 56px
  헤더에 섹션 앵커 4개. 900px 미만은 details 기반 메뉴(JS 0바이트)

패럴랙스는 섹션마다 다른 말을 한다
  히어로   글자 상승 / 배경 하강 — 반대 방향이라야 시차가 보인다
  파이프라인 단계명 고정, 산출물만 지연 — 인과
  재료     타일이 서로 다른 깊이 — 표면은 한 겹이 아니다
  프리플라이트 뒤 항목일수록 늦게 — 로그는 흐른다
  수치     없음. 의도적 정지 — 계기판의 바늘은 떨지 않는다

스킬
  three.md  §0-A 를 역할별로 갈랐다. "액자 안"만 적어둔 것이 잘못된
            일반화였고 내가 거기 그대로 걸렸다. 재질일 때의 값 교정을 실측으로 남김
  tokens.md 웨이트·컨트롤·헤더 높이·반응형 간격 — 토큰이 아예 없던 네 축
  motion.md 섹션별 패럴랙스 배정표. 움직이지 않는 것도 결정이다

390px 실렌더: 가로 스크롤 0, 대비 실패 0, 웨이트 3종, radius 2종. 테스트 22개 통과

packages/skill/references/tokens.md

@@ -165,6 +165,68 @@
 
 ---
 
+## 웨이트와 컨트롤 — 자주 빠지는 두 축
+
+타입 스케일·색·간격은 대부분 토큰으로 잡는다. **웨이트와 컨트롤 치수는 거의 안 잡는다.**
+그래서 SSOT 가 거기서 먼저 깨진다.
+
+### 웨이트는 세 개다
+
+```css
+--weight-body:   400;
+--weight-medium: 500;
+--weight-strong: 600;
+```
+
+컴포넌트마다 `font-weight: 560` 같은 값을 직접 쓰기 시작하면 페이지에 웨이트가 여섯 종이 된다.
+실측 사례: designpaca 소개 페이지가 `400 / 500 / 560 / 600 / 620 / 660` 을 동시에 쓰고 있었고,
+그중 셋은 토큰에 없는 값이었다.
+
+가변폰트는 660 같은 중간값도 그려준다. 그래서 더 위험하다 — **표준 축(400/500/600/700)을
+벗어나면 힌팅이 흐려지고, 폴백 폰트에서는 아예 다른 굵기로 떨어진다.**
+
+**웨이트로 위계를 만들려 들지 마라.** R1 실측(zed.dev 모바일)에서 `font-weight: 400` 이 832회,
+나머지 전부 합쳐 12회였다. 위계는 크기와 색이 만든다.
+
+### 버튼처럼 생긴 것은 전부 같은 치수를 쓴다
+
+```css
+--control-h:     2.75rem;   /* 44px — 터치 타깃 */
+--control-h-sm:  2.25rem;   /* 36px — 헤더 등 조밀한 자리 */
+--control-pad-x: var(--space-3);
+```
+
+컴포넌트마다 높이와 패딩을 다시 정하면 그때부터 SSOT 가 아니다.
+실측 사례: 같은 페이지의 두 버튼이 높이 36 vs 44, 패딩 16 vs 8, 테두리 1px vs 0,
+웨이트 400 vs 500 이었다. 규칙이 없으니 전부 달랐다.
+반대로 R1 의 두 버튼은 `h36 · pad-x10 · r4 · w400 · 14px` 로 **픽셀 단위까지 같았다.**
+
+### 떠 있는 헤더는 높이를 토큰으로 내놔야 한다
+
+```css
+--header-h: calc(var(--space-3) + var(--space-2) * 2 + var(--control-h-sm));
+```
+
+`position: fixed` 헤더는 문서 흐름에서 빠져 있어서, 첫 섹션의 상단 여백과 앵커 목적지
+(`scroll-margin-top`)가 그 높이를 알아야 한다. 값을 각자 손으로 맞춰두면
+**간격 토큰을 `clamp()` 로 바꾸는 순간 관계가 끊어져 제목이 헤더 뒤로 들어간다.**
+값이 아니라 관계를 토큰으로 둬라.
+
+### 큰 간격은 화면에 반응해야 한다
+
+작은 값(4~24px)은 고정, 큰 값만 `clamp()`.
+
+```css
+--space-6: clamp(2.5rem, 1.6rem + 2.6vw, 4rem);
+--space-7: clamp(3.5rem, 1.9rem + 4.6vw, 7rem);
+--gutter:  clamp(2rem, 1.4rem + 1.8vw, 2.5rem);
+```
+
+고정으로 두면 모바일에서 섹션 상하 여백 112px 이 그대로 들어가 **화면 높이의 26% 를 여백이 먹는다.**
+좌우 여백도 마찬가지다 — R1 모바일 실측은 32px 이었다.
+
+---
+
 ## 5. 성능 예산
 
 **여기서 정한다. 구현 후에 재면 이미 늦었다.**