release: v0.11.0

packages/skill/references/layout.md

@@ -25,7 +25,7 @@
 
 **`main` 폭에 고정값을 쓰지 마라.** `--measure` 는 3단계에서 언어와 폰트에 맞춰 정한 값이다.
 여기에 60rem 같은 숫자를 넣으면 본문이 measure 를 넘어가 이 문서의 통과 조건을 스스로 어긴다.
-한글은 보통 라틴보다 좁다(35ch ≈ 561px vs 640px).
+`ch`는 선택한 글꼴의 메트릭에 의존한다. 한글과 라틴의 실제 줄 길이는 글꼴·언어·내용으로 달라지므로, 예시 폭을 보편 수치로 쓰지 말고 대표 문단을 렌더해 확인한다.
 
 이 한 번의 정의로 **본문 폭 · 넓은 블록 · 전체 폭**이 전부 정렬된다. 섹션마다 `max-width` 와 `padding` 을 다시 쓰면 반드시 어긋난다.
 
@@ -39,7 +39,7 @@
 
 ### 벤토 그리드 주의
 
-벤토(크기가 다른 카드들의 격자)는 **더 이상 차별화가 아니라 새 기본값**이다. 효과는 있지만(스크롤 깊이 증가) 표준화가 끝나서 "고민 안 했음"의 신호로 읽힌다. 쓰려면 최소한 다음 중 하나는 해라:
+벤토(크기가 다른 카드들의 격자)는 정보를 묶거나 우선순위를 드러낼 때 쓸 수 있다. 카드 크기 변화만으로 고유성·스크롤 깊이·이탈을 예측할 수는 없다. 아래 장치는 선택지이며, 구조가 필요로 할 때만 쓴다:
 - 카드 경계를 없애고 여백만으로 구획
 - 그리드에서 한 칸을 의도적으로 비우기
 - 카드 하나만 규칙을 깨고 밖으로 나가기
@@ -50,10 +50,10 @@
 
 사람은 페이지를 읽지 않고 **훑는다.** 훑는 경로를 설계하는 것이 레이아웃의 본체다.
 
-1. **첫 화면에서 세 가지만** — 무엇인지 / 왜 좋은지 / 다음 행동. 넷 이상이면 아무것도 안 읽힌다
-2. **위계는 크기가 아니라 대비로 만든다** — 크기·굵기·색·여백 중 **둘 이상을 동시에** 바꿔야 위계가 보인다. 크기만 조금 키우는 것은 위계가 아니다
+1. 첫 화면이 대표 과업에 필요한 정체성·가치·다음 행동을 충분히 설명하는지 확인한다. 세 요소는 흔한 점검 틀이지 모든 화면의 최대 항목 수가 아니다
+2. 위계는 크기·굵기·색·여백·위치의 조합으로 만든다. 어떤 두 변수를 반드시 바꿔야 한다는 공식보다, 회색조와 실제 콘텐츠에서 우선순위가 읽히는지를 본다
 3. **시선을 한 번은 멈춰라** — 전부 같은 리듬으로 흐르면 아무것도 강조되지 않는다. 섹션 하나는 리듬을 깨야 한다
-4. **스크롤은 보상이어야 한다** — 다음 화면에 무언가 새로운 것이 있어야 한다. 같은 카드 그리드가 세 번 반복되면 거기서 이탈한다
+4. 스크롤 뒤에도 새 정보나 과업 진전이 있는지 확인한다. 반복 카드가 이탈을 만든다는 보편 증거는 없으므로, 실제 콘텐츠와 사용자 행동으로 판단한다
 
 ### 의미가 다르면 섹션 토폴로지도 달라야 한다
 
@@ -75,10 +75,10 @@
 
 한 액션 묶음의 **같은 행에 놓인 직접 자식**인 채운 버튼과 텍스트 링크는 `align-items:center`만으로 시각 중심이 맞지 않을 수 있다. 중첩된 아이콘·배지까지 한꺼번에 비교하거나, 모바일에서 세로로 쌓인 액션에 이 규칙을 적용하면 오탐이다.
 
-- 두 액션 모두 `inline-flex; align-items:center; min-height:44px`의 실제 hitbox를 가진다
+- 두 액션의 실제 hitbox와 정렬을 함께 측정한다. 44px은 편안한 시작값일 수 있지만, WCAG 2.2 AA의 포인터 target 최소 기준은 예외를 포함해 24×24 CSS px다 (`evidence-ledger.md`의 `WCAG-TARGET`)
 - `getBoundingClientRect()`의 중심 y 차이가 브라우저 CSS 픽셀 기준 2px 이하여야 한다
 - 텍스트 baseline이 아니라 클릭 가능한 박스 전체를 비교한다
-- 보조 링크를 44px로 키우면서 빈 padding이 과해지면 액션을 세로로 쌓는다
+- 보조 링크의 hitbox를 키운 결과 밀도가 나빠지면, 행동 중요도·오입력·레이아웃을 보고 세로 배치나 다른 구조를 검토한다
 
 ### 패널을 숨기면 그리드 트랙도 회수한다
 
@@ -104,7 +104,7 @@
 
 ### 본문이 주인공이다
 헤드라인은 눈에 띄기 쉽다. **본문이 읽히는지**가 실력이다.
-- 한 줄 길이(`--measure`)를 반드시 적용해라. 전체 폭 본문은 읽을 수 없다
+- 한 줄 길이(`--measure`)를 본문 역할에 적용하고, 실제 언어·글꼴·확대 상태에서 읽기 리듬을 검토한다. 전체 폭이 항상 실패인 것은 아니지만 긴 산문에 무심코 적용하지 않는다
 - 문단 간격은 줄간격의 1.5배 이상. 들여쓰기와 문단 간격을 동시에 쓰지 마라
 - 링크는 색만으로 구분하지 마라(밑줄 또는 다른 신호 병행)
 
@@ -112,7 +112,7 @@
 `references/antipatterns.md` 의 한글 조판 섹션을 읽어라. 요약:
 - `word-break: keep-all` — 없으면 단어가 아무 데서나 잘린다
 - line-height 1.6~1.8 (라틴보다 넉넉하게)
-- 음수 자간 금지
+- 자간은 글꼴·크기·스크립트별로 실제 렌더를 보고 조정한다. 한글 음수 자간은 기본 처방으로 쓰지 않으며, 적용했다면 작은 크기·확대·줄바꿈에서 검증한다
 - 한 줄 25~40자
 - 라틴 폰트를 폴백 스택 **앞**에 둔다 (숫자·영문이 한글 폰트로 렌더되면 조악해진다)
 - **한글 폰트를 지정하지 않는 것 자체가 완성도 미달 신호다**
@@ -131,31 +131,28 @@
 .cards { grid-template-columns: repeat(auto-fit, minmax(18rem, 1fr)); }
 ```
 
-`auto-fit` + `minmax` 로 해결되는 것을 미디어쿼리로 만들지 마라. 미디어쿼리는 **레이아웃 구조 자체가 바뀔 때만** 쓴다.
+`auto-fit` + `minmax`는 유동 반복 grid에 유용하다. 미디어쿼리와 container query는 구조·밀도·행동이 바뀌는 실제 실패 지점에서 선택한다.
 
 ### 모바일에서 먼저 확인해라
 데스크톱에서 아름다운 것이 모바일에서 무너지는 것이 기본이고, 그 반대는 드물다. 특히:
-- 큰 타이포는 모바일에서 반드시 줄여라 (`clamp` 의 최소값)
+- 큰 타이포는 모바일에서 줄 수·가려짐·다음 행동의 가시성을 보고 크기·폭·문구·구도를 함께 조정한다. 단순 축소가 유일한 해법은 아니다
 - 가로 스크롤이 생기는 요소를 찾아라 (`overflow-x: hidden` 으로 덮지 말고 원인을 고쳐라)
-- 터치 타깃 44×44px 이상
+- 터치 타깃은 과업 빈도·오입력 위험과 WCAG 2.2 AA의 24×24 CSS px 최소 기준(예외 포함)을 함께 검토한다
 - 호버로만 접근되는 기능을 만들지 마라
 
 ---
 
 ## 4-b. 모바일 내비 — 햄버거를 기본값으로 삼지 마라
 
-내비 항목 수는 0단계에서 이미 정해져 있다(= 섹션 수). 구현하다 발견하면 늦다.
+내비 구조는 섹션 수가 아니라 대표 과업, 라벨 길이, 우선순위, locale, 화면 폭을 함께 보고 0단계에서 정한다. Hick의 연구를 항목 수 공식으로 쓰지 않는다.
 
-| 항목 수 | 처리 | 비용 |
+| 관찰한 조건 | 검토할 구조 | 검증 |
 |---|---|---|
-| **2~4개** | 한 줄 유지. 자간을 줄이고 `space-between` 으로 편다 | 0 |
-| **5~6개** | 가로 스크롤 줄, 또는 하단 고정 바 | 낮음 |
-| **7개 이상** | 여는 메뉴 | `<details>` 로 JS 0바이트 |
+| 모든 우선 행동이 한 줄에서 읽히고 hitbox가 확보됨 | 직접 노출된 내비 | 작은 폭·키보드에서 라벨 접힘과 순서를 본다 |
+| 라벨이 길거나 행동 우선순위가 갈림 | 일부 노출 + 추가 메뉴 또는 하단 행동 | 자주 쓰는 행동의 탐색 시간·오입력을 본다 |
+| 문맥별 명령이 많음 | 컨텍스트 메뉴·검색·계층적 IA | 메뉴 열기/닫기·포커스·Esc·현재 위치를 시험한다 |
 
-**넷인데 햄버거를 쓰면 탭 한 번을 공짜로 뺏는 것이다.** 반대로 여섯을 한 줄에
-욱여넣으면 접힌다 — 실측에서 링크가 두 줄(top 46/77)에 걸렸고, 워드마크까지 3줄이 됐다.
-
-### 2~4개 — 쌓는 것이 접히는 것보다 낫다
+### 항목 수 대신 실제 라벨·과업으로 결정한다
 
 워드마크와 내비를 한 줄에 두면 둘 다 접힌다. 좁은 화면에서는 **위아래로 쌓아라.**
 
@@ -169,10 +166,9 @@
 라벨 자간(`0.14em`)이 좁은 화면에서 폭을 크게 먹는다. **자간부터 줄여라** —
 폰트 크기를 줄이는 것보다 읽기에 덜 해롭다.
 
-### 7개 이상 — `<details>` 면 JS 가 필요 없다
+### 단순 공개/접기에는 `<details>`를 검토한다
 
-키보드 조작·`Esc`·포커스 이동이 브라우저 기본으로 온다.
-직접 만든 토글은 그걸 전부 다시 구현해야 하고, 대개 빠뜨린다.
+`<details>`는 간단한 공개/접기에는 유용하지만, 복잡한 메뉴의 포커스 이동·Esc·모달 동작을 자동으로 완성하지 않는다. 실제 키보드와 보조기술에서 목표 행동을 시험하고, 필요한 패턴을 선택한다.
 
 ```html
 <details class="nav-mobile">
@@ -215,6 +211,47 @@ new Set([...document.querySelectorAll('.nav a')]
 
 ---
 
+## 4-d. 초광폭은 여백이 아니라 별도 레이아웃 상태다
+
+1440px에서 멀쩡한 페이지가 1920·2560px에서 깨지는 방식은 반대다. 모바일처럼 넘치지는 않지만, 본문은 끝없이 늘어나고 고정 폭 헤드라인은 빈 여백에 밀려나며 표는 너무 좁아진다. **컨테이너 하나를 무조건 풀거나 조이지 마라.** 읽는 표면과 비교·명세 표면의 요구가 다르다.
+
+```css
+:root { --measure: 42rem; --container-wide: 74rem; }
+.prose { max-width: var(--measure); }
+.specification { width: min(100% - 2 * var(--pad-inline), var(--container-wide)); }
+
+@media (min-width: 120rem) {
+  .specification { --container-wide: 86rem; } /* 데이터 표면만 확장 */
+}
+```
+
+- 본문·설명·폼은 `--measure`를 지켜 행 길이와 label-입력 관계를 읽을 수 있게 둔다
+- 표·도면·비교 작업대는 더 넓어도 되지만, 어떤 surface가 넓어지는지 이름으로 구분한다. 전역 `max-width` 해제는 해결이 아니다
+- 1920과 2560에서 h1 폭·히어로 칼럼·table/flex 셀의 실제 rect를 재고, 빈 공간이 필요한지와 내용 폭이 부족한지를 별도로 판정한다
+
+Apple도 다양한 화면 크기에서 적응형 레이아웃과 읽기 좋은 텍스트 폭의 제한을 권한다. 여기의 정확한 수치는 제품 토큰으로 정하고, 넓은 폭을 시험하지 않은 상태를 통과로 부르지 않는다. [Apple HIG Layout](https://developer.apple.com/design/human-interface-guidelines/layout)
+
+### 4-e. 분할 히어로의 사진에는 상한이 있고, 카피에는 최소 폭이 있다
+
+초광폭에서 `1fr 1fr`을 그대로 두면 사진은 창과 함께 계속 커지는데 카피는 상대적으로 가늘어져, 화면의 절반을 차지한 이미지와 읽을 수 없는 작은 설명이 공존한다. 풀블리드 편집 사진이 **의도적으로** 화면을 점유하는 경우가 아니라면, 분할 히어로를 wide surface처럼 별도 계약으로 둔다.
+
+```css
+@media (min-width: 120rem) {
+  .hero { width: min(100%, var(--stage-wide)); margin-inline: auto; }
+  .hero-copy { width: min(100%, var(--copy-wide)); justify-self: end; }
+  .hero-media { width: min(100%, var(--media-wide)); justify-self: end; }
+}
+```
+
+- `--stage-wide`, `--copy-wide`, `--media-wide`, 후속 `--workbench-wide`를 따로 이름 짓는다. 한 `--wrap`을 무한히 키우지 않는다
+- 1920·2560에서 hero·copy·media·다음 정보 레일의 실제 rect를 기록한다. media의 상한, copy의 최소 폭, hero의 중앙/의도된 정렬을 **그 페이지의 계약**으로 단언한다
+- 이미지가 넓어질 자격은 이미지 자체의 편집적 역할에 있다. 정보·주문·비교가 뒤따르는 제품 화면에서는 후속 레일도 같은 밀도로 확장해, 첫 장면만 거대하고 본문은 점처럼 보이는 단절을 만들지 않는다
+- 이 계약은 hero만의 면허가 아니다. 과정·추천·가맹 같은 별도 text-media split은 각각 원래의 padding/`max-width` 규칙을 가진다. wide에서 새 stage를 넣을 때는 inherited `padding-inline`의 **양쪽 값**과 상위 container selector의 specificity를 함께 확인한다. 한쪽에 `calc((100vw - --wrap) / 2)`가 남으면 grid rect는 멀쩡해도 실제 텍스트 폭이 한 글자까지 붕괴할 수 있다. 각 split마다 heading의 실제 폭·줄 수와 copy/media rect를 별도로 측정한다.
+
+이 규칙은 읽기 폭을 지키는 기존 wide-surface 원칙의 구체형이다. 사람의 시선은 이미지 크기보다 이미지·카피·행동의 비례에서 우선순위를 읽는다.
+
+---
+
 ## 5. 이 단계의 통과 조건
 
 - [ ] CSS/HTML만으로 페이지가 완성됐다. JS를 꺼도 읽힌다
@@ -224,7 +261,7 @@ new Set([...document.querySelectorAll('.nav a')]
 - [ ] 본문에 `--measure` 가 적용됐다
 - [ ] 모바일 폭 **320px**(iPhone SE 세로)에서 가로 스크롤이 없다
 - [ ] 키보드 Tab 만으로 모든 인터랙티브 요소에 도달한다. 포커스 링이 보인다
-- [ ] 같은 행 액션 묶음의 직접 자식 hitbox가 44px 이상이고 중심 y 차이가 CSS 픽셀 2px 이하다
+- [ ] 같은 행 액션 묶음의 직접 자식 hitbox가 과업·WCAG target 기준에 맞고, 중심 y 차이를 실제 CSS 픽셀로 기록했다
 - [ ] 데스크톱 분할 패널을 숨긴 상태에서 빈 그리드 트랙이 남지 않고 주 표면이 전체 폭을 회수한다. 모바일 시트는 닫힘·배경·포커스 복원을 따로 검증한다
 - [ ] 한글이 있다면 조판 규칙이 적용됐다