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

packages/skill/references/critique.md

@@ -10,8 +10,11 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 |---|---|
 | 스크린샷·코드·URL 중 무엇을 받았는지에 따라 어떻게 시작할지 | §1 |
 | 히어로·폼처럼 표면 종류에 따라 얼마나 깊이 볼지 | §2 |
+| 화면의 시각 품질을 축별로 판정할 때(첫인상·위계·타이포·리듬·카피·구분성 등) | §2-1 |
+| 자기 결과물을 스크린샷으로 평가하는 순서 | §2-2 |
 | finding 하나를 어떻게 적을지 | §3 |
 | 심각도를 어떻게 매길지, 무엇이 자동으로 심각도를 끌어올리는지 | §4 |
+| 템플릿 같다·브리프와 따로 논다·첫인상이 없다 같은 결함을 어떻게 판정할지 | §4 Direction |
 | 수정안을 어떤 순서로 고를지 | §5 |
 | 같은 문제가 여러 곳에서 나왔을 때, 또는 문제가 하나도 없을 때 | §6 |
 | 요청 범위가 너무 넓을 때 | §7 |
@@ -20,17 +23,18 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 | 보고서를 강점으로 마무리하는 법 | §10 |
 | 톤 | §11 |
 | 리뷰 중 자동으로 고쳐도 되는 항목 | §12 |
-| 그대로 쓸 한국어 보고 템플릿 | §13 |
+| 리뷰 보고 템플릿 | §13 |
+| 구현을 끝내고 사용자에게 납품을 보고한다 | §13-b |
 
 ---
 
 ## 0. 언제, 이 문서가 다루는 범위
 
-리뷰 경로는 **재구현이 목적이 아니다.** 사용자가 "이 화면 어때?", "이 코드 리뷰해줘", "여기 스크린샷 봐줘"처럼 평가만 요청했을 때 0단계에서 범위·입력을 확인한 뒤 곧장 5′(감사)로 가고, 4단계(구현)를 거치지 않는다. 고쳐 달라는 요청으로 바뀌면 그때 국소·연장 경로로 올린다.
+리뷰 경로는 **재구현이 목적이 아니다.** 사용자가 "이 화면 어때?", "이 코드 리뷰해줘", "여기 스크린샷 봐줘"처럼 평가만 요청했을 때 0단계에서 범위·입력을 확인한 뒤 곧장 5′(감사)로 가고, 4단계(구현)를 거치지 않는다. 고쳐 달라는 요청으로 바뀌면 그때 SKILL.md 0-2 표로 경로를 다시 판정한다(대개 국소·연장).
 
-5단계 프리플라이트에서도 이 문서를 쓴다. [preflight.md](preflight.md) §0~§4-3의 체크가 끝난 뒤, 실패·관찰 항목을 사용자에게 보고할 때 §3의 finding 형식과 §4의 심각도를 쓴다. 두 경로의 차이는 **깊이와 입구**뿐이다. 리뷰 경로는 구현이 없으니 입력(스크린샷·코드·URL)에서 바로 시작하고(§1), 프리플라이트는 자기 구현물을 대상으로 이미 렌더된 상태에서 시작한다.
+5단계 프리플라이트에서도 이 문서를 쓴다. [preflight.md](preflight.md) §0~§5의 체크가 끝난 뒤, 실패·관찰 항목을 사용자에게 보고할 때 §3의 finding 형식과 §4의 심각도를 쓴다. preflight §5의 시각 판정은 이 문서 §2-1 루브릭으로 한다. 두 경로의 차이는 **깊이와 입구**뿐이다. 리뷰 경로는 구현이 없으니 입력(스크린샷·코드·URL)에서 바로 시작하고(§1), 프리플라이트는 자기 구현물을 대상으로 이미 렌더된 상태에서 시작한다.
 
-이 문서는 designpaca가 내리는 판정의 근거인 **판정 위계**(하드 게이트 / 프로젝트 계약 / 스타일 휴리스틱, [SKILL.md](../SKILL.md))를 그대로 쓴다. 새 심각도 체계를 만들지 않는다 — §4가 하는 일은 그 3층을 리뷰 보고서의 언어로 옮기는 것뿐이다 [SKILL-DESIGN-REVIEW].
+이 문서는 designpaca가 내리는 판정의 근거인 **판정 위계**(하드 게이트 / 프로젝트 계약 / 스타일 휴리스틱, [SKILL.md](../SKILL.md))를 그대로 쓴다. §4가 하는 일은 그 3층을 리뷰 보고서의 언어로 옮기는 것이다 [SKILL-DESIGN-REVIEW]. 단 하나, 프로젝트 계약 중 **방향**(브리프의 한 문장 컨셉·톤·고유성)은 Direction이라는 별도 심각도로 뗀다. 이 결함은 기술 검사가 모두 통과한 상태에서도 생기고, 다른 계약 위반과 섞어 두면 "취향 문제"로 낮춰 보고되기 쉽기 때문이다. 근거는 [SKILL.md](../SKILL.md) 핵심 규칙 2(모든 시각적 결정은 브리프로 소급된다)와 "어떤 클라이언트의 것과도 혼동될 수 없다"는 약속이다.
 
 ---
 
@@ -42,11 +46,13 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 |---|---|
 | **스크린샷·이미지** | 바로 시각 판단으로 들어간다. 렌더가 이미 있으므로 추가 확보가 필요 없다 |
 | **코드 파일**(컴포넌트·스타일시트) | 파일을 읽되 그 파일만 보지 않는다. 관련 CSS·토큰([tokens.md](tokens.md) 역할 이름)까지 함께 열어 finding의 위치를 `path/to/file:line`으로 인용할 수 있게 한다 |
-| **URL만** | 텍스트 페처(WebFetch류)는 마크업·CSS는 가져와도 **렌더링은 보지 못한다.** 브라우저 도구가 있으면 390·1440 두 폭에서 직접 캡처한다(도구 목록은 [harness.md](harness.md) §6). 브라우저 도구가 없으면 데스크톱·모바일 스크린샷을 사용자에게 요청한다 |
+| **URL만** | 텍스트만 가져오는 페치 도구는 마크업·CSS는 가져와도 **렌더링은 보지 못한다.** 브라우저 도구가 있으면 390·1440 두 폭에서 직접 캡처한다(도구 목록은 [harness.md](harness.md) §6). 브라우저 도구가 없으면 데스크톱·모바일 스크린샷을 사용자에게 요청한다 |
 | **diff·PR·커밋 범위** | [change-review.md](change-review.md)로 넘긴다. 스코프 해석과 Introduced/Regression 구분은 거기서 하고, finding 자체는 이 문서 §3~§4를 그대로 쓴다 |
 
 시각 판단이 걸린 리뷰인데 스크린샷도 렌더도 브라우저 도구도 없으면 **추측하지 않는다.** 코드만 읽고 "아마 이렇게 보일 것"이라고 단정하는 것은 §9의 증거 방향성 위반이다. 질문 수단은 [SKILL.md 인터뷰 게이트](../SKILL.md)의 규칙 3(기계적 판정)을 그대로 따른다 — 구조화 질문 도구가 있으면 그것으로, 없으면 평문으로 스크린샷을 요청하고 턴을 끝낸다.
 
+**diff·PR 리뷰는 멈추지 않는다.** 변경분 리뷰는 코드로 확정되는 finding을 먼저 보고하고, 시각 주장은 미검증으로 남긴 뒤 보고 끝에서 "스크린샷이나 프리뷰 주소를 주시면 시각 평가를 이어서 하겠습니다"를 한 번 청한다([change-review.md](change-review.md)). 위의 "요청하고 턴을 끝낸다"는 화면 전체의 시각 평가만 요청받았고 볼 것이 하나도 없을 때다. diff를 준 사용자가 바라는 것은 대개 "확실히 말할 수 있는 것부터"이기 때문이다.
+
 ---
 
 ## 2. 표면별 깊이
@@ -60,7 +66,82 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 | 대시보드·관리 화면 | 밀도·데이터 정합·표(숫자 정렬, 관계 보존) |
 | 내비게이션 | 도달성(키보드·터치)·현재 위치 신호·좁은 화면 축약 |
 
-이것은 **다른 축을 생략해도 된다는 뜻이 아니다.** 하드 게이트는 표면 종류와 무관하게 전부 돈다([SKILL.md](../SKILL.md) 규범·기능 하드 게이트 표). 깊이 배분은 스타일 휴리스틱·프로젝트 계약 층의 시간 배분 문제다.
+이것은 **다른 축을 생략해도 된다는 뜻이 아니다.** 하드 게이트는 표면 종류와 무관하게 전부 돈다([SKILL.md](../SKILL.md) 규범·기능 하드 게이트 목록). 깊이 배분은 스타일 휴리스틱·프로젝트 계약 층의 시간 배분 문제다.
+
+---
+
+## 2-1. 시각 비평 루브릭
+
+접근성·계약 검사를 모두 통과해도 화면이 평범하거나 템플릿처럼 보일 수 있다. 이 루브릭은 그런 결함을 판정할 언어다. 품질을 증명하는 점수가 아니라 **납품할 수 있는 최저선**이다. 높은 합계가 좋은 디자인을 보장하지 않지만, 통과선 아래는 납품하지 않는다.
+
+**언제 쓰는가.** 전체·연장 경로의 5단계에서 자기 결과물에 반드시 쓴다. 리뷰 경로에서는 시각 판단이 요청에 포함될 때 쓴다. 국소 경로는 손댄 영역이 걸친 축만 채점한다.
+
+**척도.** 축마다 0·1·2 중 하나를 준다.
+
+- **0 = 실패**: 그 축의 실패 신호 중 하나라도 캡처에서 관찰된다.
+- **1 = 보통**: 실패 신호는 없지만 강 신호를 모두 갖추지는 못했다. **자기 결과물의 시작값은 1이다.**
+- **2 = 강**: 강 신호를 모두 관찰했고, 각각의 근거를 적었다.
+- **N/A**: 그 축의 대상이 화면에 없다(예: 사진·그림이 하나도 없는 운영 화면의 R6). 이유를 한 줄 적는다.
+
+**표면 유형에 따라 축을 다르게 읽는다.** 아래 표는 마케팅 표면(랜딩·소개·포트폴리오)을 기준으로 쓰였다. 제품 표면(로그인 뒤 화면·설정·목록·폼·관리자)에 그대로 대면 R1·R8·R10이 구조적으로 0~1점이 나오고, 점수를 맞추려고 앱 화면에 히어로와 브랜드 요소를 넣게 된다. 제품 표면은 다음 질문으로 바꿔 읽는다.
+
+| 축 | 제품 표면에서의 질문 |
+|---|---|
+| R1 | 3초 안에 "지금 어디이고, 무엇을 할 수 있고, 다음에 무엇을 누르는가"를 한 문장으로 쓸 수 있는가 |
+| R6 | 사진·그림이 없으면 N/A |
+| R7 | 라벨·오류·빈 상태 문구가 [product-copy.md](product-copy.md) §2·§4~§7을 지키는가(히어로 표제 기준은 적용하지 않는다) |
+| R8 | 같은 제품의 다른 화면과 토큰·컴포넌트·용어가 일관되고, 컴포넌트 라이브러리의 기본값(기본 radius·그림자·색)이 그대로 남아 있지 않은가. 반사실 치환은 적용하지 않는다 |
+| R10 | 390에서 이 화면의 주 과업을 끝낼 수 있는가(제목·주 행동·이동 수단이 보인다) |
+
+제품 표면의 통과선 2는 "R1과 R2 중 적어도 하나가 2점"이다.
+
+| 축 | 0 — 실패 신호 (하나라도 있으면) | 2 — 강 신호 (모두 있어야) |
+|---|---|---|
+| **R1 첫인상 (3초)** | 첫 화면 캡처만 3초 보고 "누구이고, 무엇이며, 왜 좋은가"를 한 문장으로 쓸 수 없다 / 첫 화면의 주된 문장이 면책 문구나 메타 서술("이 페이지는 ~를 보여 줍니다")이다 / 첫 화면에 브랜드와 제목 중 하나가 없다 | 3초 문장이 2단계 한 문장 컨셉의 핵심 명사·동사와 맞는다 / 1440과 390 첫 화면 모두에서 성립한다 |
+| **R2 위계·읽기 순서** | 회색조·흐림 캡처에서 첫 시선이 목표 행동이나 핵심 주장이 아니다 / 같은 시각 무게의 요소 셋 이상이 첫 시선을 다툰다 | 회색조·흐림 캡처의 시선 순서 1→2→3이 `design.md`에 적은 의도와 같다 / 주요 위계 단계가 크기·굵기·색·여백 중 두 가지 이상의 차이로 구분된다 |
+| **R3 묶음·정렬** | 한 화면의 주요 왼쪽 시작선이 넷 이상이고 그 차이를 의미로 설명할 수 없다 / 관련 없는 요소끼리가 관련 요소끼리보다 가깝다(근접 역전) | 주요 시작선이 셋 이하이고 각 선이 역할(제목·본문·수치 등)을 가진다 / 묶음 사이 간격이 묶음 안 간격보다 분명히 크다. 시작선 x 좌표를 실제로 쟀다 |
+| **R4 타이포 품질** | 합성 이탤릭·합성 볼드가 렌더된다 / 음수 자간으로 한글 글자가 닿는다 / 표제 마지막 줄에 한 어절만 남는다 / 한글에 고정폭 글꼴을 써서 글자 사이가 벌어진다 / 본문 측정폭이 [typography.md](typography.md) 정본 범위를 벗어난다 | 제목과 본문이 크기 외에 굵기·색·서체 중 하나 이상으로도 대비된다 / 본문 문단의 회색 농도가 고르다 / 왼쪽 실패 신호가 1440·390 어디에도 없다. 데스크톱 제목 대 본문 크기 비가 2.5배 이상이면 시작 신호로 보되 통과선은 아니다 |
+| **R5 여백 리듬·긴장** | 섹션 간격이 전부 같아 정보 전환이 보이지 않거나, 간격 변주가 정보 관계와 반대다 / 요소가 헤더·패널 테두리에 여백 0으로 붙는다 / 스케일·명암·여백 어느 축에도 의도된 극단이 없다(전부 중간값) | 간격의 변주가 정보 전환과 일치한다 / 스케일·명암·여백 중 하나 이상에서 `design.md`에 적은 의도된 극단(긴장)이 화면에서 보인다 |
+| **R6 이미지** | 이미지가 사업·브리프와 무관하다 / 크롭에서 주피사체가 사라진다 / 노출·색 보정이 어긋나 같은 페이지 사진이 서로 다른 세계처럼 보인다 / 같은 사진이 한 페이지에서 반복된다 / 컨셉이 "사진이 주연"인데 390 첫 화면에 사진이 없다 | 슬롯마다 역할이 적혀 있다 / 데스크톱·모바일 크롭 모두에서 주피사체가 안전 영역에 남는다 / 조도·색이 하나의 세계로 읽힌다([art-direction.md](art-direction.md) §4) |
+| **R7 카피 목소리** | 헤드라인이나 히어로 본문이 경쟁사 이름으로 바꿔도 그대로 성립한다 / 상투어(침묵·"말이 없다" 은유, "시간이 흘러도 변치 않는", 메타 서술)가 있다 / 표제·히어로 문단·섹션 제목에 [product-copy.md](product-copy.md) §13-c 지문이 있다 — 번역체(무생물 주어+사람 동사, `~를 통해`·`당신의`·`여정`·`재정의`), 무엇을 파는지 안 나오는 명사 종결 수수께끼 표제, 선언·잠언형 과장(`~는 ~보다 먼저 기록됩니다`), `~가 아니라 ~다` 대구 둘 이상, 감성 어휘(결·온도·숨·머무는·스미는·깃든) 반복, 내용 없는 영문 장식 라벨 / 진실 라벨·면책 문구가 히어로의 목소리를 대신한다 / 한 화면에서 해요체와 합니다체가 섞인다 | 소리 내 읽으면 한 화자가 말하고, 그 업종 대표가 손님에게 직접 할 말로 들린다 / 헤드라인에 이 브리프에만 있는 구체 재료(제품·장소·수치·행동)가 들어 있고, 경쟁사 치환에서 문장이 깨진다 / 은유는 페이지에 한 곳 이하다 |
+| **R8 구분성 (반사실·수렴)** | [art-direction.md](art-direction.md) §3-2 반사실 점검에서 실패한다 / 같은 저장소·세션의 다른 산출물과 구성 수렴 5축(히어로) 중 셋 이상, 또는 페이지 수렴 6축 중 넷 이상이 같다(art-direction §3-2 B-1·B-2) | 다른 클라이언트에게 그대로 옮기면 어색해지는 요소가 첫 화면에 둘 이상 있고 그 이름을 적었다 / 수렴 5축 중 같은 것이 하나 이하다 |
+| **R9 디테일 마감** | 아이콘과 텍스트의 광학 정렬이 어긋난다 / 캡션·라벨이 테두리에 여백 0으로 붙는다 / 숫자 열이 정렬되지 않는다 / 반복 컴포넌트끼리 radius·간격이 다르다 / 자리표시 그래픽이 실물처럼 남아 있다 | 1440·390 캡처를 200%로 확대해 훑어도 왼쪽 신호가 하나도 없다 |
+| **R10 모바일 완성도** | 390 첫 화면에 브랜드·컨셉 증거(대표 사진·데모)·제목·다음 행동 네 요소 중 둘 이하만 보인다 / 주요 섹션으로 가는 수단(내비 또는 메뉴 버튼)이 보이지 않는다 / h1이 첫 화면 밖에서 시작한다 | 네 요소가 모두 보이거나, 셋이 보이고 빠진 하나의 이유를 적었다 / 이동 수단이 보인다 / 데스크톱을 줄인 화면이 아니라 순서·크롭이 좁은 화면에 맞게 다시 편집됐다 |
+
+**통과선.** 셋을 모두 만족해야 한다.
+
+1. 0점 축이 없다(N/A 제외).
+2. R1과 R8 중 적어도 하나가 2점이다.
+3. 합계가 적용한 축 만점의 70% 이상이다(10축이면 14점 이상). 모든 축이 1점인 화면은 실패 신호가 없을 뿐 고유한 것도 없는 화면이다.
+
+**통과선 미달은 §4의 심각도로 옮긴다.** R1·R2·R7·R8의 0점과 통과선 2·3 미달은 **Direction**이다. 그 밖의 축(R3·R4·R5·R6·R9·R10)의 0점은 **Important**다. 1점 축은 finding으로 올리지 않아도 되지만, 가장 큰 효과를 낼 변경(§10)의 후보로 본다.
+
+### 자기 채점 편향 대응
+
+AI가 자기 결과물을 채점하면 후하게 매기는 경향이 있다. 의도를 알고 보면 의도한 것이 보이기 때문이다. 아래를 지킨다.
+
+1. **근거 없는 점수는 쓰지 않는다.** 점수마다 캡처 파일·화면 영역·관찰 사실(측정값 또는 화면 문장 인용)을 붙인다. 근거를 적을 수 없는 축은 점수 대신 미검증으로 둔다. "좋아 보인다", "균형 잡혀 있다"는 근거가 아니다.
+2. **가장 약한 축부터 쓴다.** 보고와 `design.md` 기록 모두 점수 오름차순으로 적는다. 강점은 §10 마무리에서만 쓴다.
+3. **의도를 가리고 먼저 본다.** R1·R2는 `design.md`와 코드를 열기 전에 캡처만 보고 채점한다. 의도와의 대조는 그다음이다.
+4. **2점에는 반례를 찾는다.** 2점을 준 축마다 "이 점수를 깎을 수 있는 관찰"을 하나 찾아 적는다. 찾지 못했으면 "찾지 못함"이라고 쓴다.
+5. **비교 기준을 옆에 둔다.** 1단계 레퍼런스(R1~R3) 캡처 하나를 같은 배율로 나란히 놓고 같은 축을 채점한다. 레퍼런스보다 높게 준 축에는 근거를 한 줄 더 적는다.
+6. **독립 검토가 가능하면 쓴다.** 다른 맥락의 검토자(서브에이전트 등, [harness.md](harness.md) §5)를 쓸 수 있으면 의도 문서 없이 캡처와 이 표만 주고 채점시킨다. 두 점수가 다른 축은 낮은 쪽을 채택한다.
+7. **승인은 채점이 아니다.** 사용자가 방향을 승인했어도 루브릭은 따로 돈다([audit-gate-rules.md](audit-gate-rules.md) G22).
+
+---
+
+## 2-2. 스크린샷 기반 자기 평가 절차
+
+루브릭은 실제 렌더 캡처로만 채점한다. 코드를 읽고 "이렇게 보일 것"이라고 채점하지 않는다(§9).
+
+1. **캡처한다.** 1440×900 첫 화면, 390×844 첫 화면, 두 폭의 전체 페이지를 찍는다. 지원하는 테마가 둘이면 두 테마를 각각 찍고 루브릭은 약한 쪽 점수를 쓴다. 화면이 여럿이면 대표 화면과 과업이 다른 화면을 채점하고, 같은 틀을 쓰는 화면은 캡처만 열어 본다([layout.md](layout.md) §4-m) — 무엇을 대표로 삼았는지 보고에 적는다. 폰트·이미지가 준비되고 등장 모션이 끝난 뒤에 찍는다([audit-gate.md](audit-gate.md) 렌더 측정 계약). 결과·오류·모달 같은 핵심 상태가 있으면 그 상태도 찍는다.
+2. **회색조·흐림 사본을 만든다.** 두 첫 화면 캡처를 회색조 + 약한 흐림(예: `filter: grayscale(1) blur(6px)`를 주입해 다시 찍거나 이미지를 처리)으로 한 장씩 더 만든다.
+3. **파일을 실제로 연다.** 이미지 보기 수단으로 캡처를 연다(도구는 [harness.md](harness.md) §6). 열 수 없으면 루브릭 전체를 미검증으로 두고 §1처럼 사용자에게 캡처를 요청한다. 저장했다는 사실은 본 것이 아니다.
+4. **3초 문장을 쓴다.** 첫 화면 원본만 보고 "누구이고, 무엇이며, 왜 좋은가"를 한 문장으로 쓴다. 그다음 2단계 한 문장 컨셉과 대조한다(R1).
+5. **시선 순서를 쓴다.** 회색조·흐림 사본에서 먼저 보이는 것 1→2→3을 적고, `design.md`의 의도와 대조한다(R2).
+6. **축별로 채점한다.** 이제 `design.md`를 열고 나머지 축을 채점한다. 가장 약한 축부터 근거와 함께 적는다.
+7. **반사실·수렴 점검을 돈다.** [art-direction.md](art-direction.md) §3-2 절차를 그대로 따른다(R8).
+8. **기록한다.** `design.md`의 시각 평가 표에 `축 | 점수 | 근거(파일·영역·관찰) | 다음 행동`을 남긴다. 통과선 미달은 §4 심각도로 finding을 만든다.
 
 ---
 
@@ -70,7 +151,7 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 
 - **무엇(What)**: 요소를 인용하거나 `path/to/file:line`을 인용한다. 스크린샷만 있으면 화면 영역과 컴포넌트 이름으로 특정한다.
 - **왜(Why)**: 한 줄로 위계 3층 중 어디에 해당하는지 밝히고, 규범·근거가 있으면 출처 ID를 붙인다. "이상해 보여서"는 이유가 아니다.
-- **고침(Fix)**: 정확한 값이나 선택자를 준다. "늘려라", "더 낫게" 같은 방향만 있는 지시는 finding이 아니다 [SKILL-DESIGN-REVIEW].
+- **고침(Fix)**: 정확한 값이나 선택자를 준다. "늘려라", "더 낫게" 같은 방향만 있는 지시는 finding이 아니다 [SKILL-DESIGN-REVIEW]. 단, 구도·위계·방향 결함(Direction, 루브릭 R2·R5·R8 등)은 한 값으로 고쳐지지 않는다. 이때는 **구조가 다른 대안 2개와 채택 기준**(무엇을 보면 어느 쪽을 고르는가)을 Fix로 쓴다.
 
 표로 묶어 보고한다. 컬럼은 심각도·위치·무엇·왜·고침이다.
 
@@ -78,8 +159,8 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 | 심각도 | 위치 | 무엇 | 왜 | 고침 |
 |---|---|---|---|---|
 | Blocking | `Button.tsx:42` | 아이콘 전용 버튼에 접근성 이름 없음 | 하드 게이트 — 스크린리더가 컨트롤 목적을 못 읽음 [WCAG-NRV] | `aria-label="검색"` 추가 |
-| Important | `Card.module.css:18` | radius가 4px·8px·12px 세 종류 혼재 | 프로젝트 계약 — `design.md`가 `--radius-md`(8px) 단일 체계로 확정 | `--radius-md`로 통일 |
-| Polish | 히어로 이미지 좌측 | 섹션 간 여백이 위 40px(`--space-5`)·아래 64px(`--space-6`)로 비대칭 | 스타일 휴리스틱 — 리듬 관찰 후보, 브리프 근거가 없으면 대칭이 시작값 [SKILL-BETTER-LAYOUT] | 상하 모두 `--space-6`(64px)으로 통일 검토 |
+| Important | `Card.module.css:18` | 같은 카드 역할인데 radius가 4px·8px·12px로 파일마다 다름 | 프로젝트 계약 — `design.md`가 역할 토큰 체계(`--radius-surface` 등, [tokens.md](tokens.md) §3-b)로 확정 | 카드는 `--radius-surface`(8px)로 통일 |
+| Polish | 히어로 이미지 좌측 | 섹션 간 여백이 위 48px(`--space-12`)·아래 64px(`--space-16`)로 비대칭 | 스타일 휴리스틱 — 리듬 관찰 후보, 브리프 근거가 없으면 대칭이 시작값 [SKILL-BETTER-LAYOUT] | 상하 모두 `--space-16`(64px)으로 통일 검토 |
 ```
 
 **UI 코드 자체의 수정 전/후를 비교하는 리뷰**(모션 커브 교체, 트랜지션 재조준 등)에는 위 표 대신 `Before | After | Why` 3열 표를 쓴다. 목록형으로 "Before:"와 "After:"를 줄바꿈해 나열하지 않는다 — 나란히 비교해야 차이가 보인다 [SKILL-EMIL-DESIGN-ENG].
@@ -96,16 +177,44 @@ diff·PR·커밋 범위처럼 **변경분**을 지목받았다면 스코프 계
 
 ## 4. 심각도
 
-판정 위계를 그대로 3단계 언어로 옮긴다. 새 규칙을 만드는 게 아니라 이미 있는 위계에 이름을 붙이는 것이다.
+판정 위계를 4단계 언어로 옮긴다. 하드 게이트·프로젝트 계약·스타일 휴리스틱에 이름을 붙이고, 프로젝트 계약 중 방향 계약만 Direction으로 뗀다(§0).
 
 | 심각도 | 판정 위계 | 기준 |
 |---|---|---|
 | **Blocking** | 하드 게이트 위반 | WCAG·키보드·포커스·대비·감소 모션·진실성처럼 규범·기능에 근거한 항목의 실패. 출시를 막는다 |
-| **Important** | 프로젝트 계약 위반 또는 과업 방해 | 브리프·`design.md`·토큰·성능 예산과 어긋나거나, 계약 위반이 아니어도 사용자가 과업을 완수하지 못하게 막음 |
+| **Direction** | 프로젝트 계약 중 방향 계약 위반 | 화면이 브리프의 한 문장 컨셉·톤·고유성을 증명하지 못한다. 아래 "Direction 판정 기준" 중 하나 이상이 근거와 함께 관찰될 때만 매긴다. **납품을 막는다** — 접근성 검사와 별개의 축이라, 하드 게이트를 모두 충족해도 Direction이 열려 있으면 완료가 아니다 |
+| **Important** | 프로젝트 계약 위반 또는 과업 방해 | 브리프·`design.md`·토큰·성능 예산과 어긋나거나, 계약 위반이 아니어도 사용자가 과업을 완수하지 못하게 막음. 루브릭(§2-1)에서 방향 축이 아닌 축의 0점도 여기다 |
 | **Polish** | 스타일 휴리스틱 관찰(관찰 후보) | 색·radius·정렬·리듬 같은 취향 후보의 다듬기. 통과·보류·채택은 맥락과 렌더로 판단한다 |
 
+보고 순서는 Blocking → Direction → Important → Polish다. Blocking과 Direction은 서로 대체하지 않는다. 하나를 해결했다고 다른 하나가 풀리지 않는다.
+
 **전부 나열하지 않는다.** 중요한 순으로 소수만 앞세운다. 몇 개까지인지 숫자로 정하지 않는다 — §7의 스코프 규율을 따른다.
 
+### Direction 판정 기준 — 관찰할 수 있는 것만
+
+Direction은 취향 판정이 아니다. 아래 중 하나 이상을 캡처·인용·측정으로 보여줄 수 있을 때만 매긴다. "내 취향과 다르다", "더 세련될 수 있다"는 Direction이 아니라 Polish 후보다.
+
+| ID | 결함 | 관찰 기준 |
+|---|---|---|
+| **D1** | 반사실 실패 — 다른 클라이언트에게도 맞는다 | [art-direction.md](art-direction.md) §3-2 반사실 점검의 실패 조건에 걸린다 |
+| **D2** | 수렴 — 이전 결과물·템플릿과 혼동된다 | 같은 저장소·세션의 다른 산출물과 나란히 놓았을 때 구성 수렴 5축(구도, 표제 서체, eyebrow 문법, CTA 형태, 캡션 문법) 중 셋 이상, 또는 페이지 수렴 6축(섹션 흐름, 히어로 글 묶음, 내비, 푸터, 이미지 비율·처리, 모션 문법) 중 넷 이상이 같다(art-direction §3-2) |
+| **D3** | 첫인상 실패 | 루브릭 R1이 0점이다 |
+| **D4** | 첫 시선 배반 | 루브릭 R2가 0점이다. 회색조·흐림 캡처에서 첫 시선이 목표 행동이나 핵심 주장이 아니다 |
+| **D5** | 컨셉 부재 | 2단계 한 문장 컨셉의 핵심 명사가 1440 또는 390 첫 화면에서 시각적으로 증명되지 않는다(예: 컨셉이 "사진이 주연"인데 390 첫 화면에 사진이 없다) |
+| **D6** | 톤 불일치 | 브리프의 톤 형용사마다 화면 증거를 하나씩 짝지었을 때 반대 증거가 있는 형용사가 하나 이상이다(예: "따뜻한"인데 냉색 단색과 대문자 고정폭 eyebrow). 또는 루브릭 R7이 0점이다(번역체·과장 카피로 인한 0점 포함 — What에 해당 문장을 그대로 인용하고, Fix의 대안마다 [product-copy.md](product-copy.md) §13-c 기준으로 고친 문장을 넣는다) |
+| **D7** | 평균 수렴 | 루브릭 통과선 2(R1·R8 중 2점 하나 이상) 또는 3(합계 70%)에 미달한다 |
+
+**Direction finding의 What·Why·Fix.** What에는 D 번호와 캡처 영역을 쓴다. Why에는 위배된 브리프 문장(한 문장 컨셉·톤 형용사·목표 행동)을 인용한다. Fix는 §3의 예외대로 구조가 다른 대안 2개와 채택 기준을 쓴다.
+
+**해제 조건.** Direction은 둘 중 하나로만 닫힌다.
+
+1. 2단계(방향)로 돌아가 다시 만든 뒤, 같은 캡처 조건에서 같은 기준으로 재평가해 사라졌다. 재작업 시도는 [audit-gate.md](audit-gate.md) "루프와 재작업 상한"의 3회 상한을 따른다.
+2. 사용자가 캡처와 finding을 보고 그 방향을 명시적으로 수용했다. 수용 문장과 날짜를 `design.md`에 남긴다. 취향·방향의 최종 승인권자는 사용자다. 사용자의 불만이 반복되는 경우의 절차는 [feedback-loop.md](feedback-loop.md)를 따른다.
+
+**연장·국소 경로의 Direction.** 이 경로에서 방향은 `design.md`(또는 확인받은 현행 계약 요약)가 이미 정했다. Direction은 "산출물이 그 계약과 어긋난다"일 때만 매기고, 고칠 곳은 2단계가 아니라 3·4단계다. 계약 자체가 이 화면에 맞지 않는다고 판단되면 고치지 말고 사용자에게 승격을 확인받는다(SKILL.md 2단계 통과 조건).
+
+에이전트가 스스로 "의도한 것"이라며 Direction을 닫지 않는다. 의도였다면 그 의도를 브리프 문장과 함께 사용자에게 보이고 2번을 거친다.
+
 ### 에스컬레이션 트리거 — 확인되면 표면이 사소해도 낮추지 않는다
 
 아래 항목은 확인되는 즉시 표에 적힌 위계로 매긴다(대부분 Blocking). "화면 전체는 괜찮으니 평균 내면 Important"처럼 다른 항목과 평균을 내어 낮추지 않는다 — 트리거는 심각도만 정할 뿐 새 하드 게이트를 만들지는 않는다. 실제 하드 게이트 정의는 [SKILL.md](../SKILL.md)·[accessibility.md](accessibility.md)가 갖고 있고, 이 표는 그 정의를 리뷰 시점에 놓치지 않기 위한 점검표다 [SKILL-BETTER-INTERFACE].
@@ -169,6 +278,8 @@ Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로
 
 둘 다 finding 개수·심각도 집계에 넣지 않는다. 통과한 체크와 나란히, 별도 목록으로 둔다.
 
+**미검증은 충족이 아니다.** 하드 게이트가 미검증이면 그 항목을 충족으로 세지 않고, 보고 첫 줄을 `하드 게이트: 충족 N / 미검증 M / 차단 K` 형식으로 쓴다. M이 0이 아니면 "모두 통과", "완료" 같은 말을 쓰지 않는다. 집계 규칙과 재작업 상한(같은 결함 3회)은 [audit-gate.md](audit-gate.md)를 따른다. 캡처를 열 수 없어 루브릭(§2-1)을 채점하지 못한 경우도 미검증이다.
+
 ---
 
 ## 9. 증거 방향성
@@ -200,6 +311,8 @@ Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로
 
 ## 12. 리뷰 중 자동 적용 범위
 
+**자동 적용도 국소 경로다** — 수정을 시작하는 순간 리뷰(읽기 전용) 경로를 벗어난다. 손댄 섹션 수로 경로를 다시 판정하고, 5단계 하드 게이트와 6단계 한 줄 추기를 생략하지 않는다([change-review.md](change-review.md) §1-1).
+
 사용자가 리뷰와 함께 수정 적용을 요청했을 때(`--apply`류 의도), 안전하게 자동 적용 가능한 범주와 확인이 필요한 범주를 구분한다.
 
 | 자동 적용 가능 | 확인 필요 |
@@ -215,9 +328,13 @@ Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로
 
 ---
 
-## 13. 한국어 보고 템플릿
+## 13. 리뷰 보고 템플릿
+
+한국어 예다. 다른 언어로 보고할 때는 같은 구조로 옮긴다(용어의 영어 대응은 audit-gate).
 
 ```markdown
+<검증 줄 — 형식의 정본은 audit-gate.md "완료 보고 첫 줄 — 정본">
+
 ## 리뷰 범위
 
 - 대상: <URL/파일/스크린샷>
@@ -231,13 +348,26 @@ Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로
 |---|---|---|---|---|
 | ... | ... | ... | ... | ... |
 
-발견 없음이면: "이 흐름에서 Blocking·Important 발견 없음. Polish 관찰 후보는 <있으면 나열, 없으면 없음>."
+발견 없음이면: "이 흐름에서 Blocking·Direction·Important 발견 없음. Polish 관찰 후보는 <있으면 나열, 없으면 없음>."
+
+## 시각 루브릭 (§2-1, 약한 축부터)
+
+| 축 | 점수 | 근거(캡처·영역·관찰) | 다음 행동 |
+|---|---|---|---|
+| ... | 0/1/2/N/A | ... | ... |
+
+3초 문장: <첫 화면만 보고 쓴 한 문장> · 시선 순서: <1→2→3>
+반사실·수렴: <art-direction §3-2 결과>
 
 ## 미검증 · 미점검
 
 - 미검증: <시도했으나 확인 못 한 항목과 이유>
 - 미점검: <스코프에서 뺀 표면>
 
+## 기존 결함 (이번 변경·요청 범위 밖, 집계 제외)
+
+- <위치 — 기준 — 제안. 없으면 절을 뺀다>
+
 ## 잘된 점
 
 - <강점 1>
@@ -248,4 +378,25 @@ Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로
 <하나, 이유 한 줄>
 ```
 
-이 템플릿은 뼈대다. 리뷰 규모가 작으면 섹션을 생략할 수 있지만(예: 발견이 없으면 "미검증" 섹션도 빈 채로 명시), 거짓으로 채우지는 않는다.
+이 템플릿은 뼈대다. 리뷰 규모가 작으면 섹션을 생략할 수 있지만(예: 발견이 없으면 "미검증" 섹션도 빈 채로 명시), 거짓으로 채우지는 않는다. 시각 판단이 요청에 없는 코드 리뷰라면 시각 루브릭 섹션은 "범위 밖"이라고 적고 뺀다. 렌더가 없는 리뷰에서는 시각 루브릭 절을 "미검증 — 렌더 없음" 한 줄로 쓰고 표를 비운 채 두지 않는다.
+
+## 13-b. 납품 보고 (구현 경로)
+
+구현을 끝낸 보고는 감사 집계가 아니라 **무엇을 만들었고 어떻게 보는지**로 시작한다. 사용자가 긴 작업 끝에 처음 읽는 줄이 내부 집계이면 정작 필요한 정보(여는 법, 정해야 할 것)를 찾지 못한다.
+
+```markdown
+<무엇을 만들었는지 한 문장. 고른 방향 카드 이름을 쓴다>
+<방향을 위임받아 직접 골랐으면: 고른 카드 이름 — 브리프·레퍼런스에서 온 이유 한 문장. "design.md 참고"로 대신하지 않는다>
+
+**보는 법**: <명령 한 줄과 주소, 또는 파일 경로> · 캡처: <1440·390 파일 경로 또는 첨부>
+**정해 주셔야 할 것**: <placeholder·가정 목록(이름 · 어디에 보이는지). 없으면 "없음">
+**검증**: <검증 줄 — 정본은 audit-gate.md "완료 보고 첫 줄 — 정본">
+- 미검증 M건: <항목 — 무엇이 있으면 확인되는지>
+**하지 않은 것**: <의도적으로 뺀 것과 이유 한 줄씩>
+**기존 결함**: <범위 밖에서 본 것. 없으면 생략>
+```
+
+- 검증 줄의 형식과 규칙은 audit-gate 그대로다. 위치만 첫 줄에서 넷째 줄로 옮긴다.
+- **보는 법**: 정적이면 파일 경로나 정적 서버 명령 한 줄, 프레임워크면 프로젝트의 dev 명령이다. 서버를 띄워 둔 채 끝내면 그렇다고 적는다.
+- **국소 경로**는 첫 문장, 보는 법, 검증 줄(하드 게이트만), `design.md` 한 줄 추기까지만 쓴다. 루브릭은 손댄 축에 0점이 있을 때만 적는다 — hover 하나를 고친 보고에 열 축 표를 붙이면 읽히지 않는다.
+- 미검증이 사람·실기기가 있어야만 확인되는 항목뿐이면 "에이전트가 확인할 수 있는 범위는 전부 충족, 사람 확인 필요 M건"이라고 쓴다. 도구가 있었는데 돌리지 않은 미검증과 구분하기 위해서다.