feat(skill): route fixes, delivery report, composition diversity, platform refresh

- route table: extension route for products with an existing visual
  language, feedback row, derived state tokens stay local
- completion: blocking 0 plus reported unverified; hard-gate surface is
  the touched scope; delivery report starts with what and how to open
- design.md created at step 0 with a skeleton, fingerprint line and
  change log; product-surface rubric reading; direction delegation
  states the chosen card and reason
- layout: hero families, nav forms, footer forms; art-direction page
  convergence 6 axes; genre sections; image treatments; placeholder
  conventions; multi-screen order; Tailwind theme mapping
- platform: scroll-driven examples, anchor positioning, canvas OT,
  three/R3F pins, shadcn style prefixes, Safari 26 notes, subgrid
- design-gate: four result states, exit codes, cwd module resolution,
  --url/--out-dir/--strict, oklch contrast, dead selector word match
- Korean font budget split from the Latin baseline
This commit is contained in:
Yun Chan 2026-10-06 16:55:38 +09:00
parent 9bcb45cbd3
commit 88c11682b1
51 changed files with 5834 additions and 2259 deletions

View file

@ -3,6 +3,19 @@
2단계에서 방향을 고르고, 3단계 토큰과 4단계 구현 전에 읽는다. 아트디렉션은 스타일 이름이나 색 견본을 고르는 일이 아니라, 실제 카피·자산·과업을 어떤 화면 질서로 보일지 결정하는 일이다.
이 문서는 원전을 그대로 옮긴 규칙도, 특정 효과의 실험적 성과 주장도 아니다. 아래 출처와 프로젝트 렌더를 바탕으로 합성한 작업 절차다.
## 이 문서를 읽는 법
| 상황 | 읽을 곳 |
|---|---|
| 구조가 다른 대안을 비교할지 정한다 | §1 |
| 섹션마다 답할 질문·주장·증거를 정한다 | §2 |
| 구도·타입·색 결정을 `design.md`에 기록한다 | §3, §3-1 |
| 다른 클라이언트·이전 결과물과 혼동되지 않는지 확인한다(2단계 직후, 5단계) | §3-2 — 반사실은 A, 구성 수렴 5축(히어로)은 B-1, 페이지 수렴 6축은 B-2 |
| 이미지 크롭을 정한다 | §4 |
| 서체·타입 계층을 proof sheet로 정한다 | §5 |
| 긴 스크롤의 리듬을 편집한다 | §6 |
| 실제 화면에서 비평한다 | §7, 축별 채점은 [critique.md](critique.md) §2-1 |
| 이 문서를 여는 때 | 여기서 얻는 결정 | 답이 부족할 때 필요한 추가 근거 |
|---|---|---|
| 첫 화면의 정보 순서·이미지 역할·섹션 리듬이 아직 불명확할 때 | 방문자 질문, 주장, 증거, 다음 행동과 그것의 화면 비중 | 실제 사용자 과업, 콘텐츠 소유자 확인, 브랜드 자산·권리·사실성, 지원 기기·상태별 렌더 |
@ -24,6 +37,8 @@
| 브랜드 방향과 핵심 구조가 확정됨 | 기존 방향 안에서 카피·크롭·밀도 후보를 고름 | 확정된 정체성을 매 화면마다 다시 경쟁시킴 |
| 국소 컴포넌트나 상태를 다듬음 | 그 화면의 과업과 상태를 기준으로 후보를 비교 | 전체 랜딩의 AIDA나 히어로 구도를 복사 |
이 표는 에이전트 내부의 비교 절차다. 사용자에게 방향을 보여 주고 고르게 하는 방향 체크포인트는 별개이며, 그 형식과 피드백 처리는 [feedback-loop.md](feedback-loop.md)를 따른다. 사용자에게 내는 방향 카드도 위와 같은 기준으로, 색·서체만 다른 안이 아니라 구조가 다른 안이어야 한다.
결정마다 `무엇이 불확실한가 / 구조 차이는 무엇인가 / 같은 조건은 무엇인가 / 채택 이유는 무엇인가`를 `design.md`에 남긴다. 대안 탐색은 좁은 문제를 확인하는 절차이며, 더 많은 안이 더 좋은 결과를 보장하지 않는다.
## 2. 콘텐츠 편집표로 화면의 일을 정한다
@ -57,12 +72,75 @@
### 3-1. 구도·타입·색 결정표
표의 "관점" 열에 적힌 이름(Arnheim·Hofmann·Warde·Ruder·Albers 등)은 **관찰할 때 쓸 렌즈**다. 결정의 근거가 아니다. `design.md`에 이 표를 옮길 때 지킨다.
- **근거 칸에는 이 브리프의 재료만 쓴다.** 실제 사진 파일 이름, 화면 문장, 수치, 상태 이름, 사용자가 인터뷰에서 한 말, 1단계 레퍼런스에서 잰 값 가운데 최소 하나가 행마다 들어가야 한다.
- **인명·사조 이름만으로 된 근거는 무효다.** "Hofmann의 대비를 참고해 구도를 잡았다", "Ruder처럼 그리드를 썼다", "Albers를 참고해 색을 정했다"는 관찰이 아니다. 어느 프로젝트에도 똑같이 쓸 수 있는 문장이다. 이런 행은 비어 있는 것으로 본다.
- **복사 검사.** 작성한 행에서 프로젝트 고유명사·수치·파일 이름을 지운다. 남은 문장이 다른 프로젝트의 `design.md`에 그대로 들어갈 수 있으면 그 행을 다시 쓴다. 같은 저장소의 다른 `design.md`와 문장이 같은 행이 있으면 그것도 다시 쓴다.
- **렌즈를 썼다면 무엇을 봤는지 쓴다.** 예: "Albers의 맥락색 관점으로 보니, 같은 `#C24B2A`가 크림 배경에서는 따뜻하고 흑청색 사진 위에서는 탁해졌다 → 사진 위 CTA에만 명도를 6% 올림". 인명은 생략해도 되지만 관찰은 생략하면 안 된다.
| 결정 축·관점 | 실제 재료와 렌더 확인 | 기록 한 행 예시 |
|---|---|---|
| 구도 — [Arnheim·Hofmann](visual-design-lineage.md) | 큰 면·정렬·군집이 주정보를 어떻게 지지하는지 실제 콘텐츠, 좁은 폭, 회색조 경계에서 본다. 이유 없는 비대칭이나 여백을 자동으로 선호하지 않는다. | 관찰: 제목과 증거가 경쟁함 → 원리 후보: 면적·군집 → 작은 대안: 증거를 제목 아래로 이동 → 채택: 좁은 폭과 회색조에서도 순서가 유지됨 / 기각: 증거 맥락이 사라짐 → 역할 토큰: `surface.evidence` |
| 타입 — [Warde·Ruder](visual-design-lineage.md), [Wallace](visual-perception-research.md) | display의 표현과 본문의 읽기 역할을 나누고, 실제 한글·숫자·긴 라벨을 proof 한다. 서체 비교 때 크기·폭·행간 차이는 고정하거나 기록한다. 같은 CSS px가 같은 광학 크기는 아니며 원인이 불명확하면 속도 효과를 주장하지 않는다. | 관찰: 긴 한국어 상태가 버튼을 밀어냄 → 원리 후보: 폭·행간·계층 → 작은 대안: 본문 폭과 보조 계층 조정 → 채택: 실제 상태에서 줄바꿈과 조작이 유지됨 / 기각: 숫자 열 비교가 흐려짐 → 역할 토큰: `type.status` |
| 색 — [Albers](visual-design-lineage.md) | 같은 전경색을 배경·면적·상태 조합에 놓고 역할 구분과 실제 대비를 함께 확인한다. 채도나 색 수를 일률적으로 정하지 않는다. | 관찰: 비활성 상태가 사진 위에서 활성과 섞임 → 원리 후보: 맥락색·상태 역할 → 작은 대안: 상태 surface와 전경 조합 변경 → 채택: 실제 합성에서 구분·대비가 유지됨 / 기각: 경고 역할과 충돌함 → 역할 토큰: `color.state.disabled` |
위 예시 행도 템플릿이 아니다. 예시의 관찰 문장("제목과 증거가 경쟁함")을 그대로 옮기지 말고, 이 프로젝트의 렌더에서 실제로 본 것을 쓴다.
### 3-2. 반사실·수렴 점검 — 같은 결과가 다른 클라이언트에게도 맞으면 실패다
2단계에서 방향을 정한 직후 한 번, 5단계에서 실제 렌더로 한 번 돈다. 5단계 결과는 [critique.md](critique.md) §2-1 루브릭의 R8과 Direction D1·D2의 근거가 된다.
**A. 반사실 점검 (한 프로젝트 안)**
1. **고유 요소 목록을 만든다.** 첫 화면(1440·390)에서 이 브리프에서만 나올 수 있는 요소를 적는다. 후보는 실제 제품·장소·사람의 사진, 브리프에만 있는 사실·수치가 들어간 헤드라인, 브랜드 자산(로고·고유 색·서체), 이 업종의 과업에서 나온 구조(예: 예약 가능한 시간이 첫 화면에 있음)다. 각 요소에 근거가 되는 브리프 문장이나 자산 파일을 붙인다.
2. **같은 업종 치환.** 브랜드 이름·로고를 같은 업종의 경쟁사로 바꿔 첫 화면을 읽는다. 헤드라인·주 시각물·구도가 **셋 다** 그대로 성립하면 실패다.
3. **다른 업종 치환.** 사진과 카피를 다른 업종의 재료로 바꾸는 상상을 한다(예: 꽃집 → 세무사무소). 레이아웃·서체 페어·색 3개·구도 실루엣이 **바꿀 필요 없이** 그대로 맞으면 실패다. 그 업종에 맞게 구조를 바꿔야 할 이유가 하나도 떠오르지 않는다는 뜻이기 때문이다.
4. **고유 요소 수를 센다.** 1의 목록에서 2·3의 치환을 견디지 못하는(=다른 클라이언트에게 옮기면 어색해지는) 요소가 첫 화면에 둘 이상 있어야 통과다. 하나 이하면 실패다.
**B. 수렴 점검 (프로젝트 사이)**
같은 저장소·같은 세션에서 만든 다른 산출물(`design.md`, 히어로 캡처)이 있으면 돈다. 없으면 "비교 대상 없음"이라고 적는다.
표가 둘이다. B-1은 히어로 한 화면 안을, B-2는 페이지 전체의 구성을 본다. 둘은 따로 세고 따로 판정한다. 토큰 값(서체·배경 명도·강조 hue·radius)의 수렴은 [presets/README.md](presets/README.md)의 4축 점검이 본다.
**B-1. 구성 수렴 5축(히어로)**
1. 히어로 첫 화면 캡처를 회색조 썸네일로 나란히 놓는다.
2. 아래 다섯 축을 각각 같음/다름으로 표시한다.
| 수렴 축 | "같음"의 기준 |
|---|---|
| 구도 | 구도 패밀리([layout.md](layout.md) §2-b)가 같다. 분할이면 좌우만 바꾼 것도 같음이다(예: 왼쪽 글·오른쪽 세로 사진, 약 5:7) |
| 표제 서체 | 같은 패밀리 또는 같은 분류의 같은 계열 |
| eyebrow 문법 | 같은 위치·대소문자·자간·구분 기호(예: 자간 넓힌 "가상 ○○ · ○○ 예시") |
| CTA 형태 | 같은 모양·채움 방식·개수 조합(예: 단색 버튼 1 + 외곽선 텍스트 링크 1) |
| 캡션 문법 | 같은 위치·크기·구두점 방식 |
3. 셋 이상이 "같음"이면 실패다. 2단계로 돌아가 같은 축 가운데 최소 두 축을 브리프 근거로 바꾼다.
**B-2. 페이지 수렴 6축**
B-1만으로는 히어로 밖이 보이지 않는다. 쇼케이스 19종 계측(2026-10-06)에서 상단 바 내비 19/19, 한 줄 고지 띠 푸터 14/19, 두 줄 표제 18/19, 3:4·4:3 직사각 크롭 + 아래 캡션이 대부분이었는데 B-1은 한 건도 잡지 못했다. 2단계에서는 방향 카드에 적은 계획으로, 5단계에서는 전체 페이지 캡처(1440·390)와 섹션 목록으로 본다.
| 페이지 축 | "같음"의 기준 | 선택지가 있는 곳 |
|---|---|---|
| 섹션 흐름 | 히어로를 포함해 앞에서부터 블록 종류 넷이 같은 순서다(예: 히어로 → 글+사진 → 색을 바꾼 띠의 표 → 문의) | [layout.md](layout.md) §2 토폴로지 표, [genre-conventions.md](genre-conventions.md) |
| 히어로 글 묶음 | 라벨 유무·표제 줄 수·리드 형태·행동 형태의 조합이 같다(예: 라벨 + 두 줄 표제 + 리드 문단 + 버튼 하나) | layout §2-b |
| 내비 형태 | 형태와 고정 방식이 같다(예: 상단 고정 바, 브랜드 왼쪽·앵커 오른쪽) | layout §2-c |
| 푸터 형태 | 형태와 담는 것이 같다(예: 고지 한 줄 띠) | layout §2-d |
| 이미지 비율·처리 | 주로 쓴 비율 둘과 처리·캡션 위치가 같다(예: 3:4·4:3 직사각 크롭 + 아래 캡션). 둘 다 이미지가 없는 것도 같음이다 | [images.md](images.md) §2 처리 표 |
| 모션 문법 | 등장 방식과 트리거가 같다(예: 스크롤하면 아래에서 떠오른다). 둘 다 "상태 변화에만 반응"인 것도 같음이다 | [motion.md](motion.md) |
**여섯 축 가운데 넷 이상이 "같음"이면 실패다.** 2단계로 돌아가 같은 축 가운데 최소 둘을 브리프 근거로 바꾼다. B-1의 "다섯 가운데 셋 이상"과 따로 판정하고, 둘 중 하나만 걸려도 수렴 실패다.
- 비교 대상은 서로 다른 프로젝트·브리프의 산출물이다. 한 사이트 안의 여러 화면이 내비·푸터를 같이 쓰는 것은 공통 셸이므로 세지 않는다(layout §4-m).
- 셋 이상을 비교할 때 어느 한 축이 전부 같은 값이면, 쌍마다의 판정을 통과했더라도 그 축을 바꾸거나 같아야 하는 이유를 적는다([presets/README.md](presets/README.md) 5번).
**C. 기록과 실패 처리**
`design.md`에 고유 요소 목록, 두 치환의 결과, B-1·B-2 두 표를 남긴다. 2단계에서 실패하면 방향을 다시 고른다. 5단계에서 실패하면 Direction finding(critique §4 D1·D2)이며, 국소 수정이 아니라 2단계로 되돌아간다. 사용자가 이 결과를 보고 방향을 수용하면 그 사실을 기록하고 닫는다(critique §4 해제 조건).
## 4. 이미지는 원본과 배포 크롭을 함께 검토한다
이미지의 품질은 원본 파일만으로 판정하지 않는다. 원본, 데스크톱 배포 크롭, 모바일 배포 크롭을 나란히 놓고 슬롯별로 아래를 기록한다.
@ -124,6 +202,8 @@ proof sheet는 멋의 순위를 매기는 카드가 아니라, 이 프로젝트
| 표현성 | 이 브랜드·과업·자산에서만 나올 이유와 과장·혼동 문제를 캡처로 적는다 | 낯선 효과 하나가 고유성을 증명한다 |
| 완성도 | 반복 규칙과 예외 처리가 끝까지 유지된 강점·문제를 캡처로 적는다 | 자동 심미 점수가 품질을 증명한다 |
세 관점의 판정을 축별로 쪼개 채점할 때는 [critique.md](critique.md) §2-1 시각 비평 루브릭과 §2-2 스크린샷 절차를 쓴다. 질서는 R2·R3·R5·R9, 표현성은 R1·R6·R7·R8, 완성도는 R4·R9·R10에 대응한다. 루브릭은 100점식 순위가 아니라 근거가 붙은 최저선이다.
완료 판정은 세 갈래로 분리한다: 사용성·접근성 규범, 프로젝트의 기능·성능 계약, 시각 평가.
한 갈래의 통과가 다른 갈래의 통과를 대신하지 않는다.
대표 실제 과업 시나리오로 회귀를 확인한다. 참여자 측정이 없으면 사용자 속도·이해도·전환은 미측정이며, 시각 판정으로 이를 주장하지 않는다.