@conscience-technology/ctds 0.0.0-stage → 0.1.1

package/assets/prompts/GUIDE.md

@@ -0,0 +1,251 @@
+# CTDS 프롬프트 작성 가이드
+
+이 문서는 **CTDS의 프롬프트 컨텍스트 문서(Layer 2)를 어떻게 쓸지**에 대한 규칙이다.
+축(Axis), 토큰(Token), 컴포넌트(Component), 모션 프리미티브(Primitive) 문서를 작성할 때
+이 가이드를 따른다.
+
+---
+
+## 0. 전제
+
+이 가이드는 [[PRINCIPLES]]의 전역 원칙을 이미 읽었다고 가정한다.
+특히 §1(값과 판단의 분리), §6(하드코딩 금지)는 모든 섹션 문서 작성의 대전제다.
+
+---
+
+## 1. 소비 주체
+
+**1차 소비자는 AI다.** Claude/Cursor 등에 통째로 주입되거나 부분 인용된다.
+따라서:
+
+- 밀도 높게 쓴다. 서론·에필로그 없음.
+- 규칙은 명령형으로. "~하는 것이 좋습니다" ❌ → "~한다" ✅
+- 예시는 규칙당 최대 1개. 반복 예시는 컨텍스트 낭비.
+- Markdown 구조를 엄격히 따른다 (AI가 헤딩으로 섹션을 찾음).
+
+사람이 참고로 읽을 순 있지만, **사람이 읽기 편하려고 형식을 무너뜨리지 않는다.**
+
+---
+
+## 2. 공통 골격
+
+모든 섹션 문서는 아래 5개 헤딩을 **이 순서로, 빠짐없이** 갖는다.
+해당 사항이 없으면 헤딩 아래에 `N/A` 한 줄만 쓴다 (헤딩 자체를 생략하지 않는다).
+리스트 헤딩(`Do`, `Don't`, `관련`)에서도 불릿 없이 `N/A` 한 줄로 표시한다.
+
+```markdown
+## <섹션 이름>
+
+### 원칙
+<1~2줄. 이 규칙이 왜 존재하는가.>
+
+### Do
+- <명령형 규칙>
+- <명령형 규칙>
+
+### Don't
+- <하드 리젝 사유>
+
+### Fallback
+<규칙이 애매할 때의 기본값. 없으면 "규칙대로 판단 불가한 경우 사용자에게 확인".>
+
+### 관련
+- [[다른-섹션-이름]] — <왜 관련되는지 한 줄>
+```
+
+**N/A 예시:**
+```markdown
+### Don't
+N/A
+
+### 관련
+N/A
+```
+
+**왜 골격이 강제인가:**
+- AI가 항상 같은 위치에서 정보를 찾을 수 있음
+- 작성자가 "금지 규칙"을 빠뜨리지 않음 (빈칸이 눈에 띔)
+- 크로스 참조가 왕복으로 성립함
+
+---
+
+## 3. 섹션 타입별 추가 항목
+
+공통 골격 뒤에 타입별 추가 섹션을 붙인다.
+
+### 3.1 축(Axis) — 예: Shape, Density, Motion
+
+공통 골격 다음에:
+
+```markdown
+### 값
+- `<값1>` — <한 줄 설명>
+- `<값2>` — <한 줄 설명>
+
+### 기본값
+`<값>`
+
+### 페어링
+- `<이 축의 값>` + `<다른 축의 값>` — <권장/비권장 및 이유>
+```
+
+### 3.2 토큰(Token) — 예: Spacing, Radius, Shadow
+
+공통 골격 다음에:
+
+```markdown
+### 토큰 표
+| Token | 용도 |
+|---|---|
+| `<토큰명>` | <어디에 쓰는가 — 값이 아니라 용도> |
+```
+
+토큰 표에는 **값을 쓰지 않는다.** 값은 `PROJECT_OVERVIEW.md` 또는 실제 CSS에 있다.
+프롬프트에는 "언제 쓰는가"만 담는다.
+
+**그룹핑 허용:** 한 문서에 여러 토큰 계열이 포함되면 굵은 텍스트 그룹 헤딩으로 표를 나눌 수 있다 (예: color.md의 `**표면**`, `**텍스트**`, `**브랜드**`). 그룹 헤딩은 `###` 헤딩을 쓰지 않는다 — 골격 순서를 흐리기 때문. 굵은 텍스트만 사용.
+
+### 3.3 컴포넌트(Component) — 예: Button, Modal, Table
+
+공통 골격 다음에:
+
+```markdown
+### Props 시그니처
+```tsx
+<Component prop1="a | b | c" prop2={boolean} />
+```
+
+### Variant 매트릭스
+| variant | 용도 | 금지 조합 |
+|---|---|---|
+| `<이름>` | <언제 쓰는가> | <어떤 축/prop과 못 씀> |
+
+### 조합 예시
+<규칙을 종합한 최소 예시 1개. 코드 블록.>
+```
+
+### 3.4 모션 프리미티브(Primitive) — 예: fade, slide, scale
+
+공통 골격 다음에:
+
+```markdown
+### 축별 스왑
+| data-motion | 파라미터 |
+|---|---|
+| `expressive` | <이 프리미티브에서 뭐가 바뀌는가> |
+| `standard` | ... |
+| `subtle` | ... |
+| `none` | <보통 즉시 완료 또는 스킵> |
+
+### 겹침 규칙
+<다른 프리미티브와 조합 가능 여부. 예: "fade와 scale만 조합 허용, 그 외 단독 사용.">
+```
+
+### 3.5 테마(Theme) — 예: spare, expressive
+
+Theme은 **6개 축 preset 묶음 + 축 밖 산문 레이어**다. Palette / Hue / Voice는 Theme 바깥(같은 Theme × 다른 색·보이스 성립).
+공통 골격 다음에 아래 4블록을 **이 순서로** 붙인다. 자세한 스키마·셀프 체크리스트는 [[themes/_SCHEMA]].
+
+```markdown
+### Signature
+이 Theme IS ___. <비교 수사 1문장>
+
+### Preset
+| Axis | Value | Why |
+|---|---|---|
+| [[axes/mode]] | `<값>` | <한 줄 이유> |
+| ... | ... | ... |  # Mode / Shape / Density / Font / Icon / Motion 6행
+
+### Layout / Imagery / Decoration / Negative
+<수치 금지, 선호·태도만. Negative는 최소 3개. 없는 섹션은 N/A.>
+
+### Override / Known Gaps / Iteration Guide
+<override는 전부 자유, 책임은 사용자. Known Gaps·Iteration Guide 의무.>
+```
+
+---
+
+## 4. 크로스 참조
+
+다른 섹션을 참조할 땐 `[[섹션-이름]]` 형식을 쓴다 (kebab-case).
+`관련` 헤딩 외에도 본문에서 자유롭게 링크한다.
+
+```markdown
+`crisp`은 데이터 밀도 높은 화면에 권장. [[axes/density]]가 `compact`일 때 특히 잘 맞음.
+```
+
+**링크 원칙:**
+- 참조는 `[[폴더/이름]]` 형식. 폴더 접두어로 타입을 명시한다 (`[[axes/density]]`, `[[tokens/spacing]]`, `[[components/button]]`, `[[primitives/fade]]`, `[[presets/gov-formal]]`).
+- 최상위 문서(`GUIDE`, `PRINCIPLES`)는 폴더 없이 `[[PRINCIPLES]]`.
+- URL이나 상대 경로(`../axes/density.md`)로 걸지 않는다 — 파일 구조가 바뀌면 다 깨진다.
+- 아직 안 쓴 섹션도 링크 가능. 나중에 쓸 것의 표식이 된다.
+- `관련` 섹션에 링크가 없어도 됨 (`N/A`). 단, 정말 다른 어떤 섹션과도 무관한지 재검토한다.
+
+---
+
+## 5. 파일 구조
+
+```
+prompts/
+├── GUIDE.md              # 이 문서
+├── PRINCIPLES.md         # 전역 원칙 (모든 섹션의 상위 규칙)
+├── axes/
+│   ├── mode.md
+│   ├── palette.md
+│   ├── hue.md
+│   ├── shape.md
+│   ├── icon.md
+│   ├── density.md
+│   ├── motion.md
+│   ├── font.md
+│   └── voice.md
+├── tokens/
+│   ├── spacing.md
+│   ├── radius.md
+│   ├── typography.md
+│   ├── color.md
+│   ├── shadow.md
+│   ├── z-index.md
+│   └── breakpoint.md
+├── components/
+│   ├── button.md
+│   ├── input.md
+│   └── ...
+├── primitives/           # 모션 프리미티브
+│   ├── fade.md
+│   ├── slide.md
+│   └── ...
+├── themes/               # 6축 묶음 + 축 밖 산문 레이어 (Palette/Hue/Voice는 바깥)
+│   ├── _SCHEMA.md
+│   ├── _TEMPLATE.md
+│   └── <theme-slug>.md
+└── presets/
+    └── <preset-name>.md  # 프리셋 정의 + 프리셋 특유의 판단 규칙
+```
+
+**파일 하나 = 섹션 하나.** 여러 섹션을 한 파일에 묶지 않는다.
+AI에 부분 주입할 때 파일 단위로 자르는 게 가장 안전하다.
+
+---
+
+## 6. 작성 순서 권장
+
+1. `PRINCIPLES.md` — 대전제(§0)와 전역 규칙
+2. `axes/` 전 9개 — 축이 컴포넌트 규칙의 전제가 됨
+3. `tokens/` 전 7개 — 토큰 이름을 컴포넌트가 참조함
+4. `primitives/` — 컴포넌트가 프리미티브를 참조함
+5. `components/` — 우선순위 컴포넌트부터
+6. `presets/` — 축 조합 확정 후
+
+---
+
+## 7. 셀프 체크리스트
+
+새 프롬프트 문서를 커밋하기 전에 확인:
+
+- [ ] 공통 골격 5개 헤딩이 모두 있는가 (없으면 `N/A`)
+- [ ] [[PRINCIPLES]] §6 하드코딩 금지 목록을 위반하지 않는가
+- [ ] 규칙이 명령형인가
+- [ ] 예시는 규칙당 1개 이하인가
+- [ ] 섹션 타입별 추가 항목을 붙였는가
+- [ ] `관련` 링크가 있거나, 없다면 진짜 독립적인지 재확인 (§4 참고)

package/assets/prompts/OVERRIDE.md

@@ -0,0 +1,170 @@
+# 컴포넌트 Override 체크리스트
+
+CTDS 공통 컴포넌트(`web/components/<Name>/`)를 로컬에서 override·확장할 때 쓰는 문서.
+템플릿·페이지·앱 조립에서 "작은 수정인데 왜 안 먹지?"가 반복되는 걸 막는다.
+
+이 문서의 모든 규칙은 **override 전**에 통과해야 한다. 추측으로 CSS를 던지지 말고 체인을 먼저 특정한다.
+
+---
+
+## 0. 왜 이 문서가 필요한가
+
+CTDS 공통 컴포넌트는 **여러 가정**을 깔고 설계돼 있다. 예:
+
+- Sidebar `.profile`은 Sidebar Root의 `padding-inline: var(--space-4)`를 **음수 margin으로 상쇄**해서 hover 영역을 사이드바 끝까지 늘린다.
+- MenuItem `.root`는 `position: relative`를 active일 때만 걸고, active bar를 `::before`로 그린다.
+- Sidebar.Body는 `mask-image`로 상단 fade + `overflow-x: hidden`으로 음수 margin 삐져나감을 clip한다.
+
+이 가정들을 **모르고** 로컬에서 Root padding을 0으로 바꾸거나 `width: 100%`만 추가하면:
+
+- Profile이 사이드바 바깥으로 삐져나가 오른쪽이 잘림
+- active bar가 전혀 안 보임
+- Body에 추가한 콘텐츠가 mask에 가려 사라짐
+
+이런 사고가 **매번 반복된다**. 아래 체크리스트가 그걸 끊는다.
+
+---
+
+## 1. Override 전 선행 체크 (하드룰)
+
+### 1-1. 공통 컴포넌트의 현재 CSS를 **파일로 읽어라**
+
+머리에 저장된 "원래 그랬던 모습"으로 override 금지. 세션 중에 사용자/린터가 수정했을 수 있다.
+
+- 수정할 대상 컴포넌트 `<Name>.module.css`를 **Read 툴로 열어 현재 선언 전부 확인**
+- 특히 **다음 속성들**이 걸려있는지 반드시 체크:
+  - `position` (`absolute`·`sticky`의 containing block 결정)
+  - `margin-inline` 음수 값 (상위 padding 상쇄 패턴)
+  - `padding-inline`
+  - `width`·`max-width`
+  - `overflow-x`·`overflow-y` (음수 margin / `::before` clip 여부)
+  - `mask-image` (콘텐츠 가림 여부)
+  - `border-radius` (full-bleed와 충돌)
+
+### 1-2. 사용자가 DOM·computed style·스크린샷을 주면 **범인 후보부터 특정하라**
+
+```
+사용자가 computed style 붙여줌 → 눈으로 훑고 "Footer padding 때문이겠지" 추측 금지
+→ computed style 안의 모든 선언을 범인 후보로 올림
+→ 하나씩 소거해서 진짜 범인 찾음 → 그제서야 수정
+```
+
+이번 세션 실제 사례:
+- 사용자가 Profile computed style을 붙여줌 → `margin-inline: calc(var(--space-4) * -1)` 적혀있음
+- 그걸 못 보고 Footer padding을 넣었다 뺐다 반복
+- 결국 사용자가 "원복해"를 세 번 외친 뒤에야 원인 특정
+
+### 1-3. 요청의 **타겟 요소**를 상상으로 치환하지 마라
+
+"좌우 여백 없애" → 어느 요소의? 어느 축의?
+사용자가 DOM을 가리키면 **그 DOM을 그대로** 수정 대상으로 삼는다.
+
+- ❌ 사용자: `<div class="profile">` 가리키며 "여백 없애"
+  AI: Footer padding을 뺌 (엉뚱한 요소)
+- ✅ 같은 요청
+  AI: `.profile`의 `margin-inline` 음수값을 확인하고 그걸 상쇄
+
+---
+
+## 2. 자주 틀리는 패턴 레시피
+
+### Case A. Hover 영역이 작아 보임 / 오른쪽만 잘려 보임
+
+증상: 아바타+텍스트까지만 hover 배경이 깔리고 사이드바 가장자리 빈 공간엔 반응 없음.
+
+범인 후보 (우선순위):
+1. **`.profile`의 `margin-inline` 음수값**이 상위 Root padding과 짝지어 있는데, **상위 padding을 0으로 바꿔** 음수 margin만 남아 overflow 발생 → `overflow-x: hidden`이 그걸 clip
+2. `width: auto`로 자식 크기만큼만 늘어남 → `width: 100%` 필요
+3. `border-radius`가 있어서 양쪽 끝이 둥글어 "안 꽉 찬" 느낌
+
+처방:
+```css
+/* 상위 Root padding을 0으로 바꿨다면 음수 margin도 함께 0으로 */
+.profile {
+  margin-inline: 0;
+  width: 100%;
+  /* 필요하면 자체 padding으로 내부 들여쓰기 */
+  padding-inline: var(--space-4);
+  border-radius: 0; /* full-bleed일 땐 각지게 */
+}
+```
+
+### Case B. Full-bleed가 안 됨 (음수 margin으로 뚫어도)
+
+증상: `.item`에 `margin-inline: -16px`를 걸었는데 사이드바 가장자리까지 안 가고 중간에 잘림.
+
+범인 후보:
+1. 상위 **스크롤 컨테이너의 `overflow-x: hidden`** — 음수 margin이 그 경계에서 clip
+2. 상위에 걸린 **`mask-image`** — 가장자리 콘텐츠가 fade로 사라짐
+3. 상위의 **`padding-inline`이 음수 margin보다 작음** — 음수가 모자람
+
+처방: full-bleed가 필요한 섹션(Divider·Profile·메뉴 리스트)은 **스크롤 컨테이너 밖**(Header/Footer)으로 뺀다. 못 빼면 **상위의 padding을 로컬 override로 0으로 두고** 자식에 자체 padding을 넣는다.
+
+### Case C. Active 스타일이 안 먹음
+
+증상: `active activeStyle="accent-bar"`를 넘겼는데 좌측 bar가 안 나오고 hover 배경(fill)만 보임.
+
+범인 후보:
+1. **wrapper 컴포넌트(`Sidebar.Item`, `Menu.Item` 등)가 `activeStyle` prop을 통과시키지 않음** → MenuItem까지 전달 안 됨
+2. CSS 변수 `--menu-active-fg`가 **투명 색**으로 떨어져 bar는 그려졌지만 안 보임
+3. `::before` containing block의 `position: relative`가 사라져 bar가 엉뚱한 좌표에 그려짐
+
+처방: wrapper를 거치지 말고 **MenuItem을 직접 사용**하거나, wrapper에 `activeStyle` 전달 로직을 추가. 색은 `.nav { --menu-active-fg: var(--primary); }`로 명시.
+
+### Case D. Body에 넣은 콘텐츠(Header 역할)가 스크롤에 묻힘
+
+증상: Sidebar.Body에 Profile/divider를 넣었더니 메뉴 스크롤 따라 올라가 사라짐.
+
+범인 후보: Sidebar.Body는 **스크롤 영역**이다. 거기 넣은 콘텐츠는 당연히 스크롤됨.
+
+처방: 고정이 필요한 섹션(Brand/Profile/divider 모두)은 **Sidebar.Header 안에 몰아넣고** flex column으로 세로 스택. Body엔 스크롤될 메뉴만.
+
+### Case E. Mask에 콘텐츠 첫/마지막 아이템이 잘림
+
+증상: Body 상단 `mask-image: linear-gradient(transparent 0, black --space-3, ...)` 때문에 첫 메뉴 아이템 윗부분이 fade로 반쯤 가려짐.
+
+처방: Body에 **mask 투명 구간과 같은 양의 padding**(`padding-top: var(--space-3)`)을 넣어 콘텐츠를 fade 구간 아래로 밀어낸다. mask 자체는 유지 — 스크롤 시 fade 효과는 그대로.
+
+### Case F. 사이즈 override했는데 과하게 커짐
+
+증상: "메뉴 아이템 세로 좀 늘려" → `min-height: calc(--control-h-lg + --space-3)` → 너무 큼.
+
+처방: 공통 컴포넌트의 **원래 size별 값**을 먼저 확인. CTDS는 size 토큰(`sm`/`md`/`lg`)이 이미 있고 각각 `--menu-item-h-*`를 쓴다. 원래 값 + 작은 증분(`--space-1` 수준)으로 시작, 사용자 반응 보고 조정.
+
+### Case G. 왕복 수정 (넣었다 뺐다 반복)
+
+증상: Footer padding을 넣고 → 사용자 "오른쪽 잘림" → 뺐다 → 사용자 "안 됨" → 넣었다 …
+
+처방: **왕복하기 전에 체인을 끝까지 추적**. 같은 요소에서 2번 왕복이면 멈추고, 1-1·1-2를 다시 수행. 어디가 범인인지 특정될 때까지 CSS 수정 금지.
+
+---
+
+## 3. 사용자가 "원복"을 요청하면
+
+- 어떤 변경을 원복할지 **범위를 먼저 복창**하고 확인받는다 (한 줄? 섹션? 전체?)
+- 원복 범위를 또 잘못 잡으면 사용자 분노 2배
+
+---
+
+## 4. 사용자가 "건들지 마"라고 명시한 영역
+
+- 디자인·사이즈·텍스트·아이콘 등 **명시적으로 유지하라고 한 것**은 다른 수정의 사이드이펙트로도 바꾸지 않는다
+- "메뉴만 늘려"에 아이콘·텍스트를 임의로 바꾸는 식의 넘겨짚기 금지
+
+---
+
+## 5. 디버깅 플로우 (요약)
+
+```
+증상 접수
+  ↓
+공통 컴포넌트 .module.css Read  ← 1-1
+  ↓
+사용자가 준 DOM/computed style 전부 훑기  ← 1-2
+  ↓
+범인 후보 리스트업 (position, margin-inline, overflow, mask, radius, width)
+  ↓
+한 번에 한 줄만 수정, 사용자 확인
+  ↓
+안 되면 1-1로 돌아가서 다른 범인 특정  ← 왕복 금지, 체인 재추적
+```

package/assets/prompts/PRINCIPLES.md

@@ -0,0 +1,130 @@
+# CTDS 전역 원칙
+
+모든 CTDS 프롬프트 문서(축·토큰·컴포넌트·프리미티브·프리셋)의 상위 규칙.
+개별 섹션 문서는 이 원칙을 다시 쓰지 않는다. 충돌 시 이 문서가 우선한다.
+
+> **컴포넌트를 override·수정하기 전에 반드시 [OVERRIDE.md](./OVERRIDE.md)의 선행 체크리스트를 통과할 것.**
+> 공통 컴포넌트에 이미 걸린 선언을 모른 채 로컬에서 덮으면 "이상한 지점에서 잘림·안 먹힘·오버플로우"가 반복된다.
+
+---
+
+## 1. 값과 판단의 분리
+
+**토큰은 값을, 프롬프트는 판단을 담는다.**
+
+- CSS 변수로 스왑되는 것: 프롬프트에 쓰지 않는다.
+- AI가 "어떤 컴포넌트를 골라 어떻게 배치할지" 판단할 때 필요한 규칙: 프롬프트에 쓴다.
+
+프롬프트에 등장 가능한 것: 토큰 이름(`space-6`), 축 이름(`density`), 축 값(`compact`), 컴포넌트 이름(`Button`), variant 이름(`primary`).
+프롬프트에 등장 금지: 픽셀 값, 밀리초, 색상 hex/oklch 값, 폰트 이름.
+
+---
+
+## 2. 축을 먼저 존중한다
+
+CTDS는 9개 축(Mode, Palette, Hue, Shape, Icon, Density, Motion, Font, Voice)으로 테마가 정의된다.
+컴포넌트나 페이지를 만들 때, 먼저 **현재 축 값이 뭔지 확인**하고 그에 맞는 선택을 한다.
+
+- 축 값을 무시한 하드코딩 금지 (예: density와 무관하게 항상 3열 그리드)
+- 축 값에 따라 **컴포넌트 선택 자체가 바뀔 수 있음** (예: `density=comfortable`이면 테이블 대신 카드)
+- 축 값을 알 수 없으면 프리셋 기본값 또는 `default` 값으로 가정
+
+---
+
+## 3. 프리셋은 시작점, 축은 오버라이드
+
+프리셋(`gov-formal`, `startup-vivid` 등)은 9축 중 Theme이 묶는 6축(Mode/Shape/Icon/Density/Motion/Font)의 검증된 조합이다. Palette·Hue·Voice는 프리셋 밖에서 자유 선택.
+사용자가 "gov-formal에서 shape만 soft로"처럼 지시하면, **프리셋을 기준으로 축을 부분 오버라이드**한다.
+
+- 프리셋 이름이 있으면 그것으로 시작
+- 개별 축 지시가 있으면 해당 축만 덮어씀
+- 나머지 축은 프리셋 값 유지
+
+---
+
+## 4. 충돌 시 우선순위
+
+여러 프롬프트 문서가 동시에 로드되어 규칙이 충돌할 때, 아래 순서로 위쪽이 이긴다.
+
+1. **접근성 규칙** (§5 참고. `prefers-reduced-motion`, WCAG, 포커스)
+2. **PRINCIPLES** (이 문서)
+3. **컴포넌트별 `Don't`** (해당 컴포넌트 문서의 하드 리젝 규칙)
+4. **축별 규칙** (Axis 문서의 Do/Don't)
+5. **프리셋 기본값** (Preset 문서)
+6. **사용자 지시** (프롬프트로 들어온 요청)
+
+**해석 원칙:**
+- 상위 규칙이 하위 규칙을 명시적으로 허용하는 경우엔 하위가 유효 (예: PRINCIPLES가 "축이 허용하는 예외"를 인정할 때)
+- 사용자 지시가 접근성이나 PRINCIPLES를 어기려 할 땐 따르지 않고 사용자에게 확인 (§8 참고)
+- 같은 계층 내 충돌은 §8에 따라 사용자에게 확인
+
+---
+
+## 5. 접근성이 축보다 우선한다
+
+- `prefers-reduced-motion: reduce` → `motion=none` 강제. Motion 축 설정을 무시한다.
+- 색상 대비: `mode=high-contrast` 외에도 WCAG AA 미달 조합은 만들지 않는다.
+- 키보드 포커스: 모든 인터랙티브 컴포넌트는 `ring` 토큰으로 포커스 표시.
+
+접근성 규칙과 축 규칙이 충돌하면 접근성이 이긴다.
+
+---
+
+## 6. 하드코딩 금지
+
+컴포넌트/템플릿 코드에서 다음은 하드코딩 금지 (프롬프트에서 이런 코드를 생성하지 않는다):
+
+- 색상값 (hex, rgb, oklch 리터럴)
+- 크기값 (px, rem, em) — 단, 1px border, 100% 등 구조적 값은 예외
+- 시간값 (ms, s)
+- 그림자 리터럴 (`box-shadow: 0 4px 12px ...`)
+- 폰트 이름
+
+모두 토큰 또는 CSS 변수를 경유한다. 하드코딩된 코드는 리뷰에서 거절한다.
+
+**예외:** 축·프리미티브 문서의 "값" 또는 "축별 스왑" 표는 스펙 자체가 값이므로 허용된다.
+예: Motion 축의 `expressive/standard/subtle/none`이 각각 어떤 duration/scale로 스왑되는지 명시하는 표.
+이 값들은 CSS 변수 정의의 원본이지, 컴포넌트 코드에 하드코딩되는 리터럴이 아니다.
+컴포넌트나 템플릿 코드에서 이 값을 리터럴로 쓰는 것은 여전히 금지.
+
+**예외:** `Don't` 섹션에서 **부정 예시**로 리터럴을 인용하는 것은 허용된다.
+예: "`#fff` 직접 지정 금지", "`font-family: "Pretendard"` 하드코딩 금지", "임의 정수(`9999` 등) 금지".
+"이렇게 쓰지 마"를 보여주기 위한 인용이므로 리터럴 생성이 아니다.
+단, 인용은 규칙당 1개로 최소화한다.
+
+## 6a. 유령 토큰 금지
+
+존재하지 않는 CSS 변수를 참조하는 것은 하드코딩보다 **더 위험하다** — 폴백 없이 `var(--없는-이름)`을 쓰면 브라우저가 상속된 base로 조용히 렌더해 사이즈·간격·색이 어긋나지만 **에러는 안 난다**. 그래서 리뷰에서도 쉽게 놓친다.
+
+**규칙:** 각 토큰 문서의 "CSS 변수 whitelist"에 명시된 이름만 사용. 흔한 유령 접두어 — `--font-size-*`(실제는 `--text-*`), `--text-size-*`, `--fs-*`, `--spacing-*`(실제는 `--space-*`), `--duration-*` 외 임의 motion 이름.
+
+**새 토큰이 필요하면:** 쓰지 말고, 먼저 토큰 문서와 globals.css에 정식 추가. 추측해서 쓰지 않는다.
+
+---
+
+## 7. 조합의 완성도 보증 범위
+
+- **프리셋 조합**: 시각적 완성도 공식 보증
+- **비프리셋 조합**: 동작은 하지만 완성도 미보증 — AI가 이런 조합으로 화면을 만들 땐 "비프리셋 조합입니다"를 사용자에게 알림
+- **금지 조합**: 각 축·컴포넌트 문서의 `Don't`에 명시된 것 — 만들지 않는다
+
+---
+
+## 8. 애매할 때는 물어본다
+
+프롬프트 규칙만으로 판단이 안 서면 임의 결정하지 않고 사용자에게 확인한다.
+특히:
+
+- 두 축 값 사이에서 어느 쪽 규칙을 우선할지 불명확할 때
+- 컴포넌트 선택지가 여러 개이고 각각의 근거가 비슷할 때
+- 프리셋이 지정되지 않았고 축 값도 부분적으로만 주어졌을 때
+
+임의 판단으로 만든 화면은 재작업 비용이 크다. 확인 비용이 항상 더 싸다.
+
+---
+
+## 9. 언어
+
+- 프롬프트 문서는 한국어로 쓴다 (팀 언어).
+- 코드 식별자·토큰명·축명은 영어 (`space-6`, `data-density="compact"`).
+- 컴포넌트가 화면에 표시하는 문구는 프로젝트별 `data-lang`을 따른다 — CTDS 프롬프트에는 화면 문구를 하드코딩하지 않는다.

package/assets/prompts/axes/density.md

@@ -0,0 +1,38 @@
+# Density
+
+### 원칙
+정보 밀도를 결정. `--space-scale`은 spacing·컨트롤 높이를, `--font-scale`은 폰트 사이즈 스케일을 연쇄 스왑.
+폰트 스케일은 위계를 흔들지 않도록 spacing보다 좁은 폭으로 조절한다 (0.95× / 1× / 1.05×).
+
+### Do
+- 데이터 테이블·관리 도구는 `compact`. 정보량이 승부.
+- 태블릿·터치 인터페이스는 `comfortable`. hitbox 확보.
+- Density가 바뀌면 컴포넌트 선택 자체가 바뀔 수 있음. 예: `comfortable`이면 폼 필드 한 줄 2개 이하.
+
+### Don't
+- Density를 무시하고 항상 같은 그리드/한 줄 필드 수를 강제하지 않는다.
+- 컨트롤 높이(`--control-h-*`)를 하드코딩하지 않는다.
+- 폰트 스케일 폭을 spacing과 같은 비율(0.85×/1.15×)로 넓히지 않는다 — 위계·가독성 붕괴.
+
+### Fallback
+`default`
+
+### 값
+| Density | `--space-scale` | `--font-scale` | 용도 |
+|---|---|---|---|
+| `compact` | 0.85× | 0.95× | 관리 도구·데이터 테이블. Excel 대체 UI. |
+| `default` | 1× | 1× | 일반 웹 UI. |
+| `comfortable` | 1.15× | 1.05× | 태블릿·터치·콘텐츠 중심. |
+
+### 기본값
+`default`
+
+### 페어링
+- `compact` + [[axes/shape]] `crisp` — 데이터 밀도 화면 표준 조합
+- `compact` + [[axes/motion]] `calm` — 밀도 높을수록 모션 이동 거리도 축소돼야 어색하지 않음
+- `comfortable` + [[axes/shape]] `soft` — 태블릿·터치·콘텐츠 중심에 자연스러움
+- `comfortable` + [[axes/motion]] `bouncy` — 여유 있는 화면에서 표현력 있는 모션 가능
+
+### 관련
+- [[tokens/spacing]] — Density가 스왑하는 spacing 토큰
+- [[tokens/typography]] — Density가 `--font-scale`로 사이즈 스케일 연동 (line-height는 스케일에 포함되어 함께 조절, weight·letter-spacing은 불변)

package/assets/prompts/axes/font.md

@@ -0,0 +1,36 @@
+# Font
+
+### 원칙
+**의미 기반 슬롯**으로 관리. 컴포넌트는 슬롯(`--font-normal/code`)만 참조.
+Language 축이 슬롯의 스택을 언어별로 스왑한다.
+
+특별 요구가 없으면 **한 폰트만 사용**한다 — 본문·헤딩·강조 전부 `--font-normal`.
+포인트/세리프 이중 폰트 체계는 사용하지 않는다.
+
+### Do
+- 본문·헤딩·강조는 `--font-normal`, 코드·숫자 정렬은 `--font-code`.
+- 위계는 size/weight/color로만 만든다 (font-family 스왑 아님).
+- 프로젝트에서 새 폰트를 쓰고 싶으면 슬롯 매핑을 갈아끼운다 (컴포넌트 코드 안 건드림).
+- `html.lang`을 `data-lang`과 동기화한다 (스크린 리더 정확도).
+
+### Don't
+- `font-family: "Pretendard", ...`처럼 폰트 이름 하드코딩 금지.
+- 헤딩·hero·인용문을 "예쁘게 하려고" 세리프/명조로 바꾸지 않는다.
+- 컴포넌트가 특정 폰트 특성(예: 세리프)에 의존하는 레이아웃 만들지 않는다.
+
+### Fallback
+`lang=ko`
+
+### 값
+
+**Language** (`data-lang`) — 슬롯의 폰트 스택을 언어별로 스왑
+- `ko` · `en` · `ja` · `zh`
+
+### 기본값
+`lang=ko`
+
+### 페어링
+- Language는 다른 축과 독립적 (한 프로젝트가 여러 언어 동시 지원해도 다른 축은 그대로)
+
+### 관련
+- [[tokens/typography]] — 사이즈·라인하이트·웨이트 토큰

package/assets/prompts/axes/hue.md

@@ -0,0 +1,36 @@
+# Hue
+
+### 원칙
+브랜드 컬러의 **색상**을 결정. 프리셋 이름으로 시작하고 필요 시 다이얼(0~360°)로 미세조정.
+`--hue` CSS 변수 하나가 primary·ring·chart 계열 hue를 동시 결정 — CTDS는 "한 프로젝트 = 한 hue, 한 브랜드 색"이 원칙.
+
+### Do
+- 프리셋 이름(`ocean`, `forest` 등)을 우선 사용. AI 지시도 이름이 명확.
+- 다이얼은 프리셋과 조금 다른 브랜드 컬러가 필요할 때만.
+
+### Don't
+- 컴포넌트마다 개별 hue를 쓰지 않는다. 한 프로젝트 = 한 hue.
+- Chart 팔레트를 hue와 별개로 재정의하지 않는다 (Chart는 hue 기준 자동 분산).
+
+### Fallback
+`ocean` (210°)
+
+### 값
+- `ocean` (210°) — 신뢰. 금융·공공.
+- `forest` (145°) — 안정. 헬스케어.
+- `sunset` (25°) — 활력. 스타트업·이커머스.
+- `lavender` (280°) — 창의. 교육·문화.
+- `crimson` (355°) — 강조. 프로모션.
+- `slate` (260°, 낮은 chroma) — 무채색 계열. 관리 도구.
+
+### 기본값
+`ocean`
+
+### 페어링
+- `ocean`·`forest`·`slate` + [[axes/palette]] `calm` — 차분한 브랜드 인상
+- `sunset`·`crimson` + [[axes/palette]] `vivid` — 강한 강조
+- `lavender` + [[axes/palette]] `pastel` — 부드러움
+- `slate`는 낮은 chroma가 특성 — [[axes/palette]] `vivid`와 조합 시 원래 강도가 안 나옴 (비권장)
+
+### 관련
+- [[axes/palette]] — chroma·lightness와 결합해 최종 색 생성