/* ==========================================================================
   세부카테고리 서브페이지(stone.html 등) 전용 스타일.

   2026-07-21: 6개 세부페이지(석재시공/미장/조적/트렌치공사/도로안전시설물/
   기타작업) 전부 "02 스타일"로 통일 확정 — 데스크톱(1025px 이상)은 왼쪽
   이미지 세로 갤러리(자체 스크롤) + 오른쪽 고정 정보카드(WORK/PROCESS/
   CONTACT/BLOG, Prev/Next) 2단 분할, 모바일도 동일한 원리로 세로 스크롤
   갤러리 + 화면 하단 고정 Prev/Next 오버레이. 처음엔 미장(plastering.html)
   페이지에서만 실험적으로 적용했었는데("미장 전용 실험" 섹션), 다양한 시공
   사진을 보여주기에 이 방식이 더 낫다는 판단으로 전 페이지 기본값으로
   승격함. 기존 01 스타일(모바일 가로 스와이프 + 평범한 페이지 스크롤)은
   혹시 몰라 backup-01style/ 폴더에 석재시공 페이지 1장만 스냅샷으로
   보관해둠(실제 사이트 내비게이션에는 연결 안 됨).

   사용자 피드백(2026-07-20, 소 사이즈 빨간펜 수정) 반영:
   1. 타이틀 영문 라벨은 별도 작은 서브타이틀이 아니라, 한글과 같은 줄·같은
      높이로 나란히 — 이후 22차 재조사에서 영문 라벨 자체를 전부 제거하기로
      결정(아래 .work-title 관련 주석 참고).
   2. WORK/PROCESS/CONTACT는 페이지 전체 다른 작은 텍스트(푸터 등)와 동일한
      폰트 스타일로 통일 — 그리고 소(모바일) 사이즈에서도 스택이 아니라
      레퍼런스처럼 3칸 나란히.
   3. 하단 공용 푸터(인스타/유튜브/...)는 서브페이지에 안 나와도 됨 → 제거.
   4. 이미지 갤러리는 세로 스크롤로 흐르며, 클릭한 WORK 항목에 해당하는
      사진으로 바로 이동. Prev/Next는 화면(또는 카드) 하단에 고정된 텍스트
      링크.

   색상: 01·03·05는 기본(베이지 bg/블랙 text — body 기본값 그대로),
        02·04·06은 <body class="work-dark">로 반전(다크 bg/베이지 text).

   PROCESS 항목, "Visit" 링크는 클릭 시 이동할 개별 세부페이지가 아직 없어서
   (이번 단계는 stone.html 등 큰 서브페이지까지만) 구조만 만들어두고 실제
   목적지는 비워둠(href="#") — .is-stub 클래스로 "추후 연결" 상태를 표시.
   ========================================================================== */

/* ---------- 다크 변형(02/04/06용) ---------- */
body.work-dark{
  background:var(--color-noir);
  color:var(--color-blanc);
}
body.work-dark .work-gallery-progress{ background:rgba(244,243,237,.25); }
body.work-dark .work-gallery-progress span{ background:var(--color-blanc); }

/* ---------- Hero: grid 3영역(info / gallery / actions) ----------
   모바일(소): 세로 1열, info → gallery → actions 순서.
   1025px 이상(중/대): 왼쪽 gallery(전체 높이) + 오른쪽 info/actions 2열,
   전체를 100vh 안에 가둬서 오른쪽은 고정, 왼쪽만 자체 스크롤. */
.work-hero{
  display:grid;
  grid-template-columns:1fr;
  grid-template-areas:
    "info"
    "gallery"
    "actions";
  gap:44px;
  /* 헤더→타이틀 간격 8차 재조사(2026-07-20): "석재시공이 가나다하우스 쪽으로
     훨씬 더 올라가야 한다"는 지적으로, 다른 3개 여백(타이틀→WORK 등)과
     마찬가지로 모바일에서는 좁을수록 더 촘촘하게, 1025px에서 76px에 도달
     하도록 비례 스케일로 변경. padding-top의 "추가분"과 실제 화면 간격 사이엔
     약 27.8px의 고정 오프셋이 있어서(헤더 자체 높이 때문 — Playwright
     실측으로 확인) 목표 간격 clamp(30px,7.415vw,76px)에 27.8px를 더해서
     padding-top 추가분으로 사용 */
  /* 9차 재조사(2026-07-20): "석재시공이 훨씬 더 올라가야 한다"는 재지적으로
     모바일 최소값을 30px→16px로 더 촘촘하게 낮춤(1025px 목표 76px는 동일) */
  /* 10차 재조사(2026-07-20): "지금 여백이 100%라면 85% 정도로" — 모바일 쪽
     간격 전체(최소값·vw 기울기)를 15% 더 줄임. 데스크톱(1025px 이상, 76px
     고정)은 이 규칙과 별개로 아래 media query가 그대로 덮어써서 영향 없음 */
  /* 11차: "위쪽 헤더가 맨 위에서 내려온 여백만큼, 맨 아래 Visit/Next도 바닥
     에서 그만큼만 띄우고 싶다" — 헤더(.app-header)의 top 위치를 실측하니
     뷰포트 상단에서 15.6px였음. 페이지 맨 아래 padding-bottom을 60px에서
     동일하게 16px로 맞춰서 위/아래 여백을 대칭으로 맞춤 */
  padding:calc(var(--grid-gutter) + 27.8px + clamp(14px, 6.3vw, 76px)) var(--grid-margin) 16px;
}
.work-hero-info{ grid-area:info; display:flex; flex-direction:column; }
.work-gallery,
.work-process{ grid-area:gallery; }
.work-actions{ grid-area:actions; }

.work-title{
  font:700 normal clamp(30px,4.4vw,68px)/1.08 var(--font-kr);
  letter-spacing:-.02em;
  /* 7차 재조사(2026-07-20): "이건 모바일에서만 이렇게 보이는 것 같고, 중/대
     에서는 다른 형태로 적용되고 있어"로 확정 — 모바일(이 base 규칙)은 좁은
     화면에 맞게 더 촘촘하게, 데스크톱(아래 1025px media query)은 76/53/36/50
     그대로 유지. 1025px에서 정확히 53px에 도달하도록 vw로 자연스럽게 스케일 */
  /* 9차 재조사: 모바일 최소값 20px→10px로 더 촘촘하게 */
  margin-bottom:clamp(10px, 5.171vw, 53px);
}
/* 22차 재조사(2026-07-20): "영문 라벨(Stone 등)이 서브페이지에서 너무 크게
   튀어서 제거하고 한글만 넣자"는 결정으로 .work-title .en과 HTML의
   <span class="en"> 자체를 6개 페이지 전부에서 삭제함. 예전 영문 라벨
   전용 스타일 규칙은 더 이상 쓰이지 않아 제거 */
/* 타이틀 글자 롤(hover) — 카테고리 h3와 동일한 "드르륵" 효과 재사용
   (js/category-subnav.js가 .work-title h1을 글자 단위 .roll로 감싸둠) */
.work-title .roll{ position:relative; display:inline-block; overflow:hidden; vertical-align:top; }
.work-title .roll .ra,
.work-title .roll .rb{ display:block; transition:transform .5s cubic-bezier(.16,.03,.08,1); transition-delay:var(--rd,0ms); }
.work-title .roll .rb{ position:absolute; left:0; top:100%; }
.work-title:hover .roll .ra,
.work-title:hover .roll .rb{ transform:translateY(-100%); }
@media (prefers-reduced-motion:reduce){
  .work-title .roll .ra,
  .work-title .roll .rb{ transition:none; }
}

/* WORK/PROCESS/CONTACT/BLOG — 13차 재조사(2026-07-20, 신규 레드라인):
   "블루박스친 부분(라벨+목록 전부) 전부 인덱스 푸터에 있는 한글 폰트와
   색상·자간·행간까지 완전히 동일하게". 처음엔 style.css의 body 기본값
   (500/font-kr/16~21px)으로 맞췄었는데, 실제 index.html의 footer-data
   엘리먼트는 <div class="footer-data t-big-text">로 t-big-text 클래스가
   직접 붙어 있어서 실측(getComputedStyle) 결과 body 기본값이 아니라
   .t-big-text(500 normal clamp(14px,1.1vw,19px)/normal var(--font-en))가
   실제로 적용되고 있었음 — 그 실측값 그대로 재적용(굵기 700·대문자·자간
   오버라이드는 전부 제거해서 라벨도 목록 내용과 완전히 동일하게) */
.work-cols{
  display:grid;
  grid-template-columns:repeat(3,1fr);
  gap:2.4em 28px;
}
.work-col-label{
  display:block;
  font:500 normal clamp(14px,1.1vw,19px)/normal var(--font-en);
  letter-spacing:normal;
  /* 라벨→내용 간격 — 모바일은 vw 비례(9차: 최소값 16px→8px 더 촘촘하게),
     1025px 이상은 36px 고정(위 주석 참고). WORK/PROCESS/CONTACT 라벨과
     BLOG 라벨(.work-blog도 이 클래스 재사용) 둘 다 이 규칙 하나만 적용받아서
     두 간격이 항상 정확히 같음(동일한 크기 요청 사항 반영) */
  margin-bottom:clamp(8px, 3.512vw, 36px);
}
.work-col ul,
.work-col ol{
  list-style:none;
  display:flex;
  flex-direction:column;
  gap:.3em;
}
.work-col li{
  /* 인덱스 footer-data(t-big-text)와 완전히 동일한 폰트. 색상은 별도
     지정이 없으므로 body 기본 색상을 그대로 상속(다크 모드(work-dark)에서도
     자동으로 맞는 색이 됨).
     14차 재조사(2026-07-20): "외부미장/레미콘타설/수평몰탈, CONTACT 밑 3개
     항목의 행간이 너무 넓다 — 80% 정도로 축소"로, line-height만 이 목록에
     한해 footer 기준값(normal, 실측 시 font-size의 약 1.4286배)에서 80%인
     1.14로 줄임(다른 폰트 값·색상은 그대로 footer와 동일하게 유지) */
  font:500 normal clamp(14px,1.1vw,19px)/1.14 var(--font-en);
  letter-spacing:normal;
}
.work-col-process a,
.work-col-contact a{
  /* 18차 재조사(2026-07-20): border-bottom(브라우저마다 줄 상자 기준 위치가
     달라 불안정) → text-decoration(사파리가 <button> 네이티브 렌더링에서는
     통째로 무시)까지 둘 다 요소 종류·브라우저에 따라 결과가 갈렸음.
     box-shadow는 border-box 바로 바깥에 순수하게 "그림"만 그리는 효과라
     line-height·네이티브 위젯 렌더링과 완전히 무관하게 항상 동일한 위치에
     그려짐 — <button>이든 <a>든, 크롬이든 사파리든 차이가 없어서 이걸로
     통일 */
  box-shadow:inset 0 -1px 0 0 transparent;
  transition:box-shadow .2s ease;
}

/* WORK 항목 클릭 → 아래 갤러리가 그 항목 사진으로 이동(js/category-detail.js).
   <button> 기본 스타일을 지워서 원래 텍스트 항목과 똑같이 보이게 하고,
   PROCESS/CONTACT 링크와 같은 밑줄 호버만 추가해서 "누를 수 있다"는 것만 표시 */
.work-item-trigger{
  display:inline;
  padding:0;
  margin:0;
  border:0;
  background:none;
  /* 사파리에서 <button>이 네이티브 OS 버튼 위젯으로 렌더링되는 것을 꺼서
     일반 텍스트 상자처럼 만듦(box-shadow 자체는 appearance와 무관하게
     항상 그려지지만, 네이티브 버튼 스킨이 남아있으면 배경/테두리 등
     예상 밖의 렌더링이 섞일 수 있어 안전하게 유지) */
  appearance:none;
  -webkit-appearance:none;
  font:inherit;
  color:inherit;
  text-align:left;
  cursor:pointer;
  box-shadow:inset 0 -1px 0 0 transparent;
  transition:box-shadow .2s ease;
}
.work-item-trigger:hover{ box-shadow:inset 0 -1px 0 0 currentColor; }
.work-col-process a:hover,
.work-col-contact a:hover{ box-shadow:inset 0 -1px 0 0 currentColor; }
/* PROCESS("공정순서")는 눌렀을 때 이동할 페이지를 만들 계획이 있는 실제 링크라
   시각적으로 다른 항목들과 다르게(흐리게) 보이면 안 됨 — 나머지와 완전히 동일한
   스타일 유지, href만 아직 "#"(추후 실제 페이지 주소로 교체) */

/* BLOG — 네이버 블로그 상세글 링크(실제 글 주소가 정해지면 href만 교체하면 됨).
   밑줄 없이 나머지 리스트 항목과 동일한 스타일.
   레이아웃 재조사(2026-07-20, 여백 크기 캡쳐 지시): WORK 목록 마지막 항목과
   BLOG 사이의 간격이 라벨→목록 간격(.work-col-label의 margin-bottom:1.3em,
   약 18~23px)보다 3배 이상 크게(약 57px, 전체 flex gap:3.6em이 그대로 적용되던 것)
   벌어져 있었음 — 라벨→내용 간격과 동일한 "여백 한 단위"를 재사용해서 통일 */
.work-blog{
  display:flex;
  flex-direction:column;
  /* 2026-07-20 재지적: "BLOG 라벨→링크 간격이 위쪽 WORK 라벨→항목 간격보다
     넓다" — 원인은 여기 gap:.3em이 .work-col-label의 margin-bottom(라벨→내용
     간격)에 추가로 더해지고 있었기 때문(WORK쪽 .work-col은 이런 gap이 없이
     라벨의 margin-bottom만 씀). WORK와 완전히 동일하게 margin-bottom
     하나로만 간격을 주도록 gap 제거 */
  /* WORK 목록 마지막 항목→BLOG 간격 — 모바일은 vw 비례(9차: 최소값 20px→12px),
     1025px 이상은 50px 고정(위 .work-title 주석 참고) */
  margin-top:clamp(12px, 4.878vw, 50px);
}
.work-blog a{
  /* WORK/PROCESS/CONTACT 목록 내용과 동일한 본문 스타일(인덱스 footer-data와 통일).
     19차 재조사(2026-07-20): "워크랑 블로그 밑줄 값이 다르냐" — box-shadow
     자체는 동일했지만, 이 링크만 line-height가 normal(WORK/CONTACT는 1.14로
     줄여둔 상태)로 남아있어서 줄 상자 자체가 더 컸음. 상자가 크면 텍스트가
     그 안에서 위아래로 살짝 더 뜬 채 배치돼서, 상자 바닥에 딱 붙는 밑줄도
     텍스트와 미세하게 더 떨어져 보일 수 있었음 — WORK/CONTACT와 완전히
     동일하게 1.14로 통일 */
  font:500 normal clamp(14px,1.1vw,19px)/1.14 var(--font-en);
  letter-spacing:normal;
  /* 15차 재조사: "블로그 상세 보기 밑줄이 오른쪽까지 쭉 이어진다" — 부모
     .work-blog가 flex-direction:column이라 이 a가 flex 아이템으로 취급되면서
     기본 align-items:stretch 때문에 너비가 컨테이너 전체로 늘어나
     밑줄도 텍스트 폭이 아니라 그 전체 너비만큼 그려지고 있었음 —
     align-self:flex-start로 내용물 너비만큼만 차지하도록 고정 */
  align-self:flex-start;
  /* 18차 재조사: WORK/PROCESS/CONTACT와 동일하게 box-shadow 기반으로 통일
     (line-height·네이티브 렌더링과 무관하게 항상 텍스트 바로 밑에 붙음) */
  box-shadow:inset 0 -1px 0 0 transparent;
  transition:box-shadow .2s ease;
}
.work-blog a:hover{ box-shadow:inset 0 -1px 0 0 currentColor; }

/* ---------- 이미지 갤러리 ----------
   현재 이미지는 크게, 다음 이미지는 오른쪽 끝에 살짝 걸쳐 보이는 "peek" 카드.
   js/category-detail.js가 requestAnimationFrame으로 일정한 속도로 계속
   흐르게 자동 스크롤(회전초밥처럼 멈췄다 밀리는 게 아니라 끊김 없이 쭉) —
   scroll-snap은 이 연속적인 흐름과 안 맞아서 뺌(사용자가 직접 스와이프/
   드래그할 땐 자동재생이 잠깐 멈추고 자유 스크롤, 손을 떼면 이어서 흐름).
   기본은 흑백(grayscale) — 오버(호버)하면 컬러로 */
.work-gallery,
.work-process{
  display:flex;
  gap:14px;
  overflow-x:auto;
  scrollbar-width:none;
  -ms-overflow-style:none;
  /* 브라우저의 스크롤 앵커링(콘텐츠 로드 중 스크롤 위치 자동 보정)이
     JS로 매 프레임 움직이는 자동 스크롤과 겹치면 속도가 의도한 값보다
     빨라지는 문제가 있어서 끔 */
  overflow-anchor:none;
  /* 버그 수정(2026-07-20): "WORK 항목 클릭 시 짝수(다음) 사진부터 시작"
     — js/category-detail.js의 jumpToItem()이 item.offsetTop/Left을 그대로
     scrollTop/Left에 대입하는데, .work-gallery에 position이 지정돼 있지
     않아서 offsetParent가 body까지 거슬러 올라가 버림. 그래서 item.offsetTop이
     "갤러리 내부 스크롤 위치"가 아니라 "body 기준 절대 좌표"가 되어, 갤러리가
     페이지 아래쪽에 있을수록(특히 미장 페이지의 세로 갤러리처럼 위치가 많이
     내려가 있는 경우) 그 차이만큼 스크롤이 더 밀려서 다음 사진으로 넘어가
     버렸음. position:relative를 줘서 .work-gallery 자신이 offsetParent가
     되도록 하면 offsetTop/Left이 항상 갤러리 내부 기준으로 정확히 계산됨 */
  position:relative;
}
/* 2026-07-21: '공정순서' 클릭 시 사진 갤러리 자리를 공정순서 5단계로 교체
   (js/category-detail.js가 .is-visible/.is-open 토글) — 평소엔 숨겨두고,
   Work 항목 클릭 시엔 다시 사진 갤러리로 되돌아옴(같은 자리이므로 동시에
   둘 다 보일 필요가 없어 display로만 전환, 위 flex 관련 공통 규칙은 그대로
   물려받음).
   .is-visible(표시 여부)과 .is-open(아래→위 스르륵 등장)을 일부러 분리함 —
   하나의 클래스로 display:none→flex 전환과 opacity 0→1 트랜지션을 동시에
   걸면, 브라우저가 "원래부터 최종 상태"로 취급해 트랜지션 자체를 건너뛰어
   버림(아이템이 스르륵 없이 그냥 바로 나타나 보이는 원인). js에서 먼저
   .is-visible만 붙여 display:flex로 만들고(이때 아이템은 아직 opacity:0),
   강제로 레이아웃을 한 번 읽어(reflow) 이 "시작 상태"를 브라우저가 확실히
   그려두게 한 다음, 다음 프레임에 .is-open을 붙여야 실제로 전환이 재생됨 */
.work-process{ display:none; }
.work-process.is-visible{ display:flex; }
.work-gallery.is-hidden{ display:none; }
.work-gallery::-webkit-scrollbar,
.work-process::-webkit-scrollbar{ display:none; }
/* 42차: 대표님 요청 — "카테고리 안에 이미지들, 좌우 여백이 생기거든.
   어바웃 페이지의 book.mp4나 월간 나눔 시공 카드들에 적용해둔 방식으로
   바꿔줄 수 있어?" 기존엔 고정 비율 박스(4/5) 안에 object-fit:contain으로
   넣다 보니, 실제 사진 비율(3:2)과 박스 비율이 달라서 좌우(또는 상하)에
   여백(레터박스)이 생겼음. about.css의 .about-archive-card-media img/video
   (24·27차)와 완전히 동일한 방식으로 전환 — 박스의 aspect-ratio/
   object-fit을 전부 없애고 width:100%; height:auto;만 남겨서, 사진/영상이
   각자의 원본 비율 그대로 폭에 꽉 차게(여백 없이) 표시되도록 함. 사진마다
   세로 길이가 자연스럽게 달라짐(들쑥날쑥) — Archives 갤러리와 동일한
   원리이며, 화면 크기가 바뀌어도 자동으로 적용되고 페이지별 비율 값을
   따로 관리할 필요가 없어짐.
   12차 재조사(2026-07-20): "사진 아래에 시공항목/시공내용을 설명하는 2줄
   텍스트 넣기" 요청으로, 사진 박스(.work-gallery-photo)와 아이템 전체
   (.work-gallery-item, 클릭/자동스크롤 단위는 그대로 유지)를 분리 — 캡션이
   추가돼도 js/category-detail.js의 오토스크롤·jumpToItem 로직(아이템 단위로
   offsetTop/Left 측정)은 구조 변경 없이 그대로 작동함(실측 결과 이 로직은
   고정 비율이 아니어도 문제없이 동작 — offsetTop/Left를 매번 실측하기
   때문) */
.work-gallery-item{
  flex:0 0 86%;
  display:flex;
  flex-direction:column;
  gap:10px;
  cursor:pointer;
}
.work-gallery-photo{
  display:block;
  position:relative;
}
.work-gallery-photo img,
.work-gallery-photo video{
  display:block;
  width:100%;
  height:auto;
  filter:grayscale(1);
  transition:filter .5s ease;
}
.work-gallery-photo video{
  pointer-events:none; /* 클릭/자동스크롤은 항상 .work-gallery-item(a)이 처리 */
}
/* 호버 시 커지지 않고 색상만 컬러로 전환 */
.work-gallery-item:hover .work-gallery-photo img,
.work-gallery-item:hover .work-gallery-photo video{
  filter:grayscale(0);
}
@media (prefers-reduced-motion:reduce){
  .work-gallery-photo img,
  .work-gallery-photo video{ transition:none; }
}

/* 사진 아래 2줄 캡션 — 13차 재조사: "이미지 아래 2줄 설명도 마찬가지로
   [인덱스 푸터와] 동일하게" — 색상까지 동일해야 해서 opacity로 흐리게
   하던 것도 제거, 두 줄 다 footer-data와 완전히 같은 폰트로 통일 */
.work-gallery-caption{
  display:flex;
  flex-direction:column;
  gap:.2em;
}
.work-gallery-caption .cap-title,
.work-gallery-caption .cap-desc{
  font:500 normal clamp(14px,1.1vw,19px)/normal var(--font-en);
  letter-spacing:normal;
}
/* 2026-07-21: "01 현장답사"처럼 숫자+한글이 한 줄에 섞인 공정순서 캡션에서
   "숫자만 높이/크기가 달라 보인다"는 지적 — 원인은 var(--font-en) 폰트 스택
   (Switzer→Helvetica Neue→Helvetica→Arial→var(--font-kr))이 500 굵기 기준
   Switzer까지는 실제 폰트 파일이 있어서 숫자(라틴 문자)는 Switzer로 그려지는데,
   한글은 이 스택의 라틴 전용 폰트들에 글자가 아예 없어서 결국 맨 뒤
   var(--font-kr)(Pretendard)까지 밀려나 그려짐 — 같은 font-size라도 서로
   다른 두 서체(Switzer vs Pretendard)라 숫자와 한글의 실제 눈에 보이는
   크기·기준선(baseline)이 달라 보였던 것. 숫자 부분만 처음부터 한글과 같은
   폰트(Pretendard)를 쓰도록 지정해서 통일 — 다른 캡션(사진 갤러리 항목 등,
   전부 순수 한글이라 이미 Pretendard로만 그려지고 있었음)에는 영향 없음 */
.work-process .cap-title .cap-num{
  font-family:var(--font-kr);
}

/* ---------- 공정순서(.work-process) 등장 애니메이션 ----------
   인덱스 페이지의 카테고리 제목 hover 시 세부 항목이 "아래에서 위로" 순서대로
   슬라이드+페이드 등장하는 것과 동일한 느낌 — 가장 아래(마지막) 항목부터
   먼저 올라오도록 delay를 역순으로 줌(css/style.css의 .sub-list li와 동일 원리).
   항목 자체(사진+캡션)는 .work-gallery-item을 그대로 재사용하므로 크기/비율/
   호버 흑백↔컬러는 위 갤러리 규칙을 그대로 물려받고, 여기서는 등장 트랜지션만 추가 */
.work-process .work-gallery-item{
  opacity:0;
  transform:translateY(8px);
  transition:opacity .4s ease, transform .4s cubic-bezier(.16,1,.3,1);
}
.work-process.is-open .work-gallery-item{
  opacity:1;
  transform:translateY(0);
}
/* 2026-07-21: 자동 스크롤(컨베이어 벨트) 추가로 원본 5장 뒤에 복제본이 붙게
   되면서, 끝에서부터 세는 nth-last-child로는 복제본이 걸려버려 정작 화면에
   보이는 원본 5장은 스태거 없이 한 번에 나타나 버림 — 처음부터 세는
   nth-child로 바꿔서 복제 개수와 무관하게 항상 원본 5장에만 적용되도록 수정
   (지연 순서 자체는 기존과 동일하게 유지: 05→04→03→02→01)

   2026-07-27: 공정순서 텍스트를 실제 내용으로 교체하면서 5단계→4단계로
   축소(카테고리마다 04까지만) — 스태거 규칙도 4개 기준으로 조정
   (04→03→02→01 순으로 먼저 나타남) */
.work-process .work-gallery-item:nth-child(4){ transition-delay:0s; }
.work-process .work-gallery-item:nth-child(3){ transition-delay:.05s; }
.work-process .work-gallery-item:nth-child(2){ transition-delay:.1s; }
.work-process .work-gallery-item:nth-child(1){ transition-delay:.15s; }
.work-process:not(.is-open) .work-gallery-item{ transition-delay:0s !important; }
@media (prefers-reduced-motion:reduce){
  .work-process .work-gallery-item{ transition:none; }
}

/* Visit / Next — 이미지 위에 얹는 칩이 아니라 갤러리 아래 평범한 텍스트 링크.
   상단 헤더 MENU와 완전히 동일하게(가로폭 상관없이 항상) — 처음엔 .t-big-text가
   "선언"한 값(500/clamp 14~19px)을 그대로 복사했는데, 실제로는 .app-header가
   font-weight:700으로 덮어써서 MENU가 더 굵고 크게 렌더링됨(실측 완료).
   .app-header의 실제 font 값을 그대로 재사용 — 소/중/대 사이즈 구분 없이
   MENU 자체가 사이즈 구분 없는 하나의 clamp라서 여기도 media query 없이 base에 둠 */
.work-actions{
  display:flex;
  justify-content:space-between;
  align-items:center;
  font:700 normal clamp(22px,2.2vw,34px)/normal var(--font-en);
  /* 2026-07-20 재조사: 모바일에서 Visit/Next를 더 하단으로 내려달라는 요청.
     40px는 Playwright 실측으론 정확히 적용되고 있었음(자동 스크린샷으로
     확인) — "전혀 안 움직인다"는 피드백은 아마 1025px 이상(데스크톱, 이
     여백이 0으로 되돌려지는 구간)에서 테스트하셨을 가능성이 높음. 그래도
     확실히 눈에 띄도록 값을 더 키움 — 데스크톱은 원래도 문제없었던 부분이라
     아래 media query에서 여전히 0으로 되돌려 영향 없게 함 */
  margin-top:80px;
}
.work-actions a{
  border-bottom:1px solid transparent;
  transition:border-color .2s ease;
}
.work-actions a:hover{ border-color:currentColor; }
.work-actions a.is-stub{ cursor:default; }
.work-actions a.is-stub:hover{ border-color:transparent; }

/* ---------- 1025px 이상(중/대): 좌우 2단, 오른쪽 고정 ----------
   2026-07-21 전면 재구성(rxkstudio.com 레퍼런스 기준, 사용자 빨간펜 지시):
   1. 헤더(Ganada House/MENU)가 사진 위에 투명하게 떠 있는 오버레이로 바뀜
      (레퍼런스처럼) — 이 media query는 세부페이지(category-detail.css)에만
      로드되므로 인덱스 페이지 헤더는 전혀 영향받지 않음.
   2. 사진(갤러리)은 좌/상/하 전부 여백 없이 화면 끝까지 꽉 참 — 기존에는
      .work-hero 하나의 padding(상 111px대/하 40px)이 갤러리·정보 칼럼
      모두에게 똑같이 적용돼서 사진 위아래에도 똑같은 여백이 생겼었음.
      이제 .work-hero 자체의 상하 padding은 0으로 없애고, 그 값을 정보
      칼럼 쪽(.work-hero-info의 padding-top, .work-actions의 padding-bottom)
      으로 옮겨서 사진만 순수하게 화면 끝까지 채우게 함. 좌우 padding
      (grid-margin)은 그대로 유지 — 사진 왼쪽 끝이 헤더 "Ganada House"
      시작 지점과 동일한 x좌표에 오도록.
   3. 정보 칼럼을 "블루 라인"(타이틀/WORK/Prev 왼쪽 정렬선)과 "두 번째 라인"
      (PROCESS/CONTACT/BLOG가 같이 시작하는 정렬선) 두 그룹으로 재구성 —
      기존엔 WORK/PROCESS/CONTACT가 3칸으로 나란히 균등 배치였는데, 이제
      WORK는 왼쪽 칼럼 하나를 그대로 쓰고, PROCESS·CONTACT·BLOG는 그
      오른쪽에 두 번째 칼럼 하나로 세로로 쌓임(.work-cols를 display:contents로
      풀어서 .work-hero-info 전체를 하나의 grid로 만들고, 각 블록에
      grid-area를 지정) */
@media (min-width:1025px){
  /* 헤더가 사진 위에 투명하게 떠 있는 오버레이로 — 이 media query 안에서만
     적용되므로 모바일 헤더(위치/레이아웃)는 전혀 영향받지 않음.
     2026-07-21: "이 라인에 맞춰서 메뉴탭을 아래로 이동" — 화면 맨 위(y=0)에
     딱 붙어있던 걸, 기본 .app-header 규칙과 동일한 top 오프셋
     (calc(grid-gutter - .2em), 기존 absolute일 때 쓰던 값)만큼 아래로 내림 */
  .app-header{
    position:fixed;
    top:calc(var(--grid-gutter) - .2em);
    left:0;
    right:0;
    z-index:30;
    background:none;
  }

  .work-hero{
    /* 2026-07-21: "사진 가로사이즈가 지금 100%면 50%로 축소" — 갤러리
       칼럼 폭 자체를 줄이는 것(사진 박스만 안에서 작아지는 게 아니라)이라는
       지시로, 고정 380px 사이드바 대신 갤러리:정보 칼럼을 1:1로 균등 분할.
       레퍼런스 사이트처럼 정보 카드(WORK/PROCESS/CONTACT/BLOG)가 화면
       중앙 쪽으로 더 넓게 이동함. 이 media query 안에서만 적용되므로
       모바일(가로 스크롤 갤러리)은 전혀 영향받지 않음.
       33차 재조사(2026-07-21, rxkstudio.com/field-day-sound 구조 분석):
       한때 "맥스튜디오 큰 모니터에서 이동이 안 보인다" 문제 대응으로
       max-width:1760px; margin:0 auto;를 걸어서 큰 화면에서 콘텐츠 폭 자체를
       고정·중앙정렬했었는데, 35차 재조사에서 "이미지 박스가 깨졌다, 예전처럼
       돌려야" 피드백으로 전면 삭제 — 사진 칼럼이 다시 뷰포트 폭 그대로
       1:1로 늘어나는 원래 구조로 복귀. (Process/Contact/Blog의 좌측 이동폭은
       34차에서 margin-left 자체에 별도 clamp 상한을 걸어뒀으므로, 이 max-width
       삭제와 무관하게 큰 화면에서도 안전하게 유지됨 — 재실측으로 확인) */
    grid-template-columns:1fr 1fr;
    /* 정보 칼럼(info)이 유연하게 줄어들고, Visit/Next(actions)는 항상 원래
       크기 그대로 맨 아래 확보 — redline(세부페이지7-3.jpg) 세 번째 창에서
       실제로 재현: 브라우저 창 높이가 낮으면(노트북 창을 작게 줄인 경우 등)
       info 쪽 내용(타이틀~WORK~BLOG)이 다 안 들어가면서 Visit/Next가 BLOG
       텍스트와 겹쳐버리는 버그가 있었음(X 표시로 지적). auto 1fr였던 걸
       minmax(0,1fr) auto로 바꿔서 info가 부족한 공간만큼 스스로 스크롤되게
       하고, actions는 항상 자기 높이만큼 자리를 보장받아 절대 겹치지 않음 */
    grid-template-rows:minmax(0,1fr) auto;
    grid-template-areas:
      "gallery info"
      "gallery actions";
    align-items:start;
    height:100vh;
    /* 상하 padding을 없애고 좌우(grid-margin)만 유지 — 사진이 위아래로
       완전히 flush하게 채워지도록. 아래로 옮겨진 111px/40px 값은
       .work-hero-info의 padding-top, .work-actions의 padding-bottom 참고 */
    padding:0 var(--grid-margin);
    /* 2026-07-21: "WORK/Prev는 사진에서부터 우측으로 멀어지는 형태" —
       사진과 WORK 사이 간격을 기존 grid-gutter(20px)에서 훨씬 넓게 키워서
       WORK가 사진에서 더 떨어지도록 함(반대로 WORK↔PROCESS/CONTACT/BLOG
       사이 간격은 아래 .work-hero-info의 column-gap에서 좁힘) */
    gap:0 64px;
    box-sizing:border-box;
  }
  .work-hero-info{
    grid-row:1;
    /* 23차 재조사(2026-07-21): "석재시공 글씨의 윗쪽 라인이 헤더 메뉴 글씨의
       윗쪽 라인과 동일한 위치선상" — 이전(76px 간격, 아래 옛 주석 참고) 요청을
       뒤집는 새 지시. .app-header의 top 공식(calc(grid-gutter - .2em), 단
       em은 .app-header 자신의 font-size=clamp(22px,2.2vw,34px) 기준)을 여기서도
       그대로 재사용해서, 헤더 텍스트 박스 top과 타이틀(h1) 박스 top이 항상
       (뷰포트 폭이 바뀌어도) 정확히 같은 y좌표를 갖도록 함 —
       실측(Playwright, 1280px): 헤더/MENU box top=14.36px, 이 공식 적용 후
       타이틀 h1 box top도 동일하게 14.36px로 일치 확인.
       예전 값(옛 주석): "헤더→타이틀 간격 목표 76px... calc(grid-gutter+111px)" */
    padding-top:calc(var(--grid-gutter) - (clamp(22px,2.2vw,34px) * .2));
    padding-right:4px;
    /* .work-hero의 align-items:start 때문에 grid row(minmax(0,1fr))만큼
       늘어나지 않고 내용 크기 그대로 커져버려서 overflow-y:auto가 전혀
       작동하지 않는 문제가 있었음 — align-self:stretch로 실제 행 높이만큼
       채우도록 강제해야 스크롤이 정상 작동함 */
    align-self:stretch;
    min-height:0;
    overflow-y:auto;
    scrollbar-width:none;
    -ms-overflow-style:none;
    /* 정보 칼럼 내부를 "타이틀(전체 폭)" → "WORK(왼쪽 칼럼) / PROCESS·CONTACT·
       BLOG(오른쪽 칼럼, 세로로 쌓임)" 2단 grid로 재구성. .work-cols는
       display:contents로 풀어서 그 자식(WORK/PROCESS/CONTACT)이 이 grid에
       직접 참여하게 하고, 원래 .work-cols 바깥에 있던 .work-blog도 같은
       grid 안에서 오른쪽 칼럼 맨 아래 자리를 차지하도록 함 */
    display:grid;
    grid-template-columns:1fr 1fr;
    grid-template-rows:auto auto auto auto;
    grid-template-areas:
      "title   title"
      "work    process"
      "work    contact"
      "work    blog";
    /* 2026-07-21: "Process/Contact/Blog는 이미지 쪽으로 가까워지는 형태"
       — WORK와 PROCESS/CONTACT/BLOG 사이 간격을 기존 28px보다 좁혀서
       두 그룹이 서로 더 붙게 함(사진↔WORK 간격은 반대로 위 .work-hero의
       gap에서 넓힘) */
    column-gap:16px;
    row-gap:0;
    align-content:start;
  }
  .work-hero-info::-webkit-scrollbar{ display:none; }
  .work-actions{
    grid-row:2;
    align-self:end;
    margin-top:0;
    /* 원래 .work-hero의 padding-bottom(40px)이었던 값 — Prev/Next가 화면
       맨 아래에서 이만큼 떠 있어야 하는데, 이제 .work-hero 자체엔 하단
       padding이 없으니(사진이 바닥까지 꽉 차야 해서) 여기로 옮김 */
    padding-bottom:40px;
  }

  /* 타이틀 폰트 크기 재확인(2026-07-20, "스톤 폰트 이상하다" 문의 조사 결과):
     .en(STONE)의 font-family·font-weight·font-style는 MENU와 실측(getComputedStyle)
     결과 완전히 동일(둘 다 Switzer 700). 다만 모바일용 사이즈(clamp(30,4.4vw,68))를
     그대로 데스크톱에서도 쓰다 보니, 이 사이드바 칼럼 폭(380~420px 고정)에는
     "석재시공"만으로도 한 줄이 거의 꽉 차서 "STONE"이 통째로 다음 줄로 밀려나
     버림 — 요청사항 1번("영문 라벨은 별도 서브타이틀이 아니라 한글과 같은 줄에
     나란히")과 반대로, 마치 작은 서브타이틀처럼 아래에 걸려 보이는 게 "이상하다"의
     실제 원인이었음. 뷰포트 폭이 아니라 이 칼럼의 고정 폭 기준으로 최대
     한 줄에 들어가는 크기를 실측(Playwright 이진탐색)해서 여유있게 줄임 */
  /* 24차 재조사(2026-07-21): "석재시공 폰트가 더 커지고 굵어져야" —
     48px/weight 700(상속) → 60px/800(Pretendard ExtraBold, 실제 로드된
     굵기 파일 있음)로 확대. 1440px 이상은 아래 별도 media query에서 66px.
     30차 재조사(2026-07-21): "중 사이즈(1025~1439px)에서는 석재시공 폰트가
     좀 더 작아져야" — 고정 60px 대신 뷰포트 폭에 비례해 1025px에서 더 작게
     시작해서 1440px에서 66px에 자연스럽게 도달하는 값으로 변경 */
  /* 38차 재조사(2026-07-21): "석재시공 폰트 사이즈를 지금 기준 85%로 축소,
     위치는 그대로" — clamp의 세 값(최소/vw비례/최대) 전부에 0.85를 곱해서
     비율은 그대로 유지한 채 전체적으로 85% 축소(44→37.4, 4.6vw→3.91vw,
     66→56.1). 위치(정렬 기준)는 padding/margin 쪽이라 이 규칙과 무관 —
     그대로 유지됨. 모바일(위 base .work-title, 1025px 미만)은 이 media
     query 밖이라 영향 없음 */
  /* 47차 재조사(2026-07-21): "헤더 위로 그은 빨간 라인에 석재시공 텍스트가
     미세하게 더 위로 튀어나온다 — 튀어나오지 않게 밑으로 조금만 더" —
     중·대 사이즈 공통(미디어쿼리로 나뉘지 않은 이 블록이라 자동 적용).
     타이틀 박스 top은 헤더와 정확히 같은 지점인데, 타이틀 폰트가 훨씬
     크고 줄간격(line-height:1.08)이 빡빡해서 글자 잉크가 박스 위쪽으로
     살짝 넘쳐 보이는 것 — margin-top으로 아주 조금만 내림 */
  .work-title{ grid-area:title; font-size:clamp(37.4px, 3.91vw, 56.1px); font-weight:800; margin-top:8px; margin-bottom:53px; }
  /* 모바일은 위 base 규칙(clamp)에서 화면 폭에 비례해 촘촘하게, 데스크톱은
     여기서 76(헤더 간격은 이미 폭 무관 고정)/53/36/50으로 명시 고정 —
     "모바일에서만 촘촘하고 중/대에서는 다르게" 요청 반영 */
  /* 46차 재조사(2026-07-21): "라벨(Work/Process/Contact/Blog)과 그 아래
     내용(목록·링크) 사이 간격을 85%로 축소" — 36px × 0.85 = 30.6px */
  .work-col-label{ margin-bottom:30.6px; }

  /* 2026-07-21: WORK는 왼쪽 칼럼(블루 라인) 전체를 세로로 차지, PROCESS·
     CONTACT·BLOG는 오른쪽 칼럼(두 번째 라인)에서 서로 세로로 쌓임 —
     .work-cols(원래 3칸 grid 컨테이너)를 display:contents로 풀어서 그
     자식들이 부모(.work-hero-info)의 grid에 직접 참여하게 함 */
  .work-cols{ display:contents; }
  /* 39차 재조사(2026-07-21, 파란선 시안): "Work/Process/Contact/Blog 라벨
     4개 전체를(타이틀은 그대로 두고) 아래로만 이동 — 포토샵에서 전체선택해서
     내리는 느낌". Work는 grid-area가 work/process/contact/blog 3개 행을
     세로로 전부 차지(rowspan)하고 Process는 그 중 첫 행만 차지하는 구조라,
     "그룹 전체를 아래로"는 Work와 Process 둘 다에 똑같은 margin-top을 줘야
     구현됨 — Process(행 기준 auto-height)에 margin-top을 주면 그 행 높이
     자체가 늘어나서 Contact/Blog(다음 행들)도 자동으로 같이 내려가지만,
     Work는 별도로 자기 content가 항상 자기 칸의 맨 위에 붙어버리므로 Work
     자신에게도 같은 margin-top을 줘야 Process랑 같은 높이에서 다시 나란해짐.
     맥스튜디오 2560px 기준 시안 실측으로 약 51px 필요 */
  .work-col-work{ grid-area:work; margin-top:51px; }
  .work-col-process{ grid-area:process; margin-top:51px; }
  .work-col-contact{
    grid-area:contact;
    /* 25차 재조사(2026-07-21): "라벨과 라벨 사이(예: 공정순서→컨택) 간격은
       라벨의 영문과 한글 사이 간격(36px, 위 .work-col-label margin-bottom)보다
       2.5배 정도 넓게" — 50px → 36*2.5=90px로 확대 */
    /* 44차 재조사(2026-07-21): "Process→Contact, Contact→Blog 간격을 각각
       85%로 축소" — 중간 사이즈·대 사이즈 두 구간 모두 해당(이 규칙이
       미디어쿼리로 나뉘지 않은 공통 1025px+ 블록이라 자동으로 둘 다 적용됨).
       46차 재조사(2026-07-21): 44차에서 "85% 축소"를 "85%만큼 줄여라(15%만
       남기기)"로 잘못 이해해서 90px→13.5px까지 너무 많이(절반 넘게) 줄었음
       — 실제 의도는 "90px의 85%만큼만 남기고 줄여라(15%만 줄이기)"였음.
       90px × 0.85 = 76.5px로 수정 */
    margin-top:76.5px;
  }
  .work-blog{ grid-area:blog; margin-top:76.5px; } /* 46차: 위와 동일한 이유로 13.5px→76.5px(90px×0.85) */

  /* 26차 재조사(2026-07-21, 빨간선/파란선 시안): "석재시공/Work/외벽석재/Prev는
     빨간선쪽(오른쪽)으로, Process/Contact/Blog는 파란선쪽(왼쪽)으로 이동해서
     두 그룹이 서로 더 가까워지되, 사진↔Work 시작 지점과 Next 오른쪽 끝은
     그대로" — 각 그룹의 grid 트랙(column) 폭 자체는 안 건드리고, 트랙 안에서
     텍스트만 안쪽으로 들여쓰기(padding-left/margin-left)해서 두 그룹이
     서로에게 다가가는 효과를 냄. Prev는 .work-actions가 space-between이라
     padding-left만 줘도 Next(오른쪽 고정)는 전혀 영향받지 않음.
     27차 재조사(2026-07-21): "이동이 부족하다, 지금 이미지박스 간격(사진↔정보
     칼럼 64px, 위 .work-hero의 gap)보다 2배 더 우측으로" — 64px → 128px.
     28차 재조사(2026-07-21): "지금(128px)이 100%라면 130%로 좀 더" — 128*1.3=166.4px.
     단, 고정 166px를 그대로 쓰면 1025~1100px처럼 좁은 데스크톱/태블릿 폭에서
     칼럼 자체가 좁아져서 Work 텍스트와 Process가 겹치는 문제 발견(실측:
     1025px에서 clearance -28.9px, 1100px에서 -22.2px — 진짜 겹침).
     그래서 고정 px 대신 뷰포트 폭에 비례해 커지는 값으로 변경(Playwright로
     각 폭에서 "겹치지 않는 최대 여백" 실측 후 두 지점을 잇는 1차식).
     29차 재조사(2026-07-21, 핑크선 시안): "Process/Contact/Blog를 핑크선까지
     더 왼쪽으로" — 처음엔 핑크선 위치를 과하게 추정해서 Work 쪽까지 양보
     시켰었는데(93~216→63~186, margin -80), 31차 재조사에서 "석재시공의
     '공' 아래 부분과 비슷하게"라는 훨씬 명확한 기준점을 주셔서 재측정해보니
     실제 목표는 그렇게 멀지 않았음(원래 위치 972px에서 '공' 좌측 939px로
     33px만 이동하면 됨) — Work 쪽을 양보할 필요가 없어서 93~216px 원래
     값으로 되돌림.
     32차 재조사(2026-07-21): "맥스튜디오 큰 모니터로 창을 최대한 넓히면
     하나도 이동 안 된 것처럼 보인다" — 상한선(216px)이 원인이었음(넓은
     화면에서는 사진 칼럼 자체도 넓어지는데 이동폭은 216px에서 멈춰버려서
     상대적으로 무시할 만큼 작아 보였음).
     34차 재조사(2026-07-21): "석재시공/Work/외벽석재/Prev는 원래 위치 그대로
     두고 Process/Contact/Blog 3개만 이동해야 하는데 전부 이동했다" — 강한
     피드백으로 위 26~33차의 Work측 우측 이동(padding-left)을 전면 취소.
     Work/타이틀/Prev는 이제 다시 원래 위치(이동 없음, padding-left 삭제).
     Process/Contact/Blog 쪽 좌측 이동만 유지하되, Work가 더 이상 오른쪽으로
     비켜주지 않으므로 '공' 기준점을 새로 실측(Playwright, Range API로 Work
     목록 중 가장 긴 텍스트 "건물 석재시공"의 실제 글자 끝 위치 vs "공" 위치)해서
     재계산함 — 실측 결과 "공" 글자가 Work의 실제 텍스트 끝보다 이미 더
     오른쪽(그리드 트랙 안 여유 공간)에 있어서, Work 텍스트와 안 겹치면서도
     '공' 아래에 맞출 수 있는 여지가 있었음(1025px 기준 여유 55px 이상,
     1760px 기준 74px 이상 — 전 구간 실측 확인). 1025px→1760px 두 지점 실측
     회귀(linear regression)로 구한 식, 1760px 이후는 .work-hero의
     max-width:1760px와 함께 멈추도록 상한 고정 */
  /* 39차 재조사(2026-07-21, 핑크선 시안 3차): "Process/Contact/Blog 3개 라벨을
     지금보다 더 오른쪽, 새로 그은 핑크 세로선에 맞춰서" — 기존 식은 1760px
     이후 -241px에서 그대로 고정(플랫)되어 있었는데, 맥스튜디오 2560px 기준
     시안 실측으로 그 지점에서 +39px 정도 더 오른쪽(덜 음수)으로 가야 함.
     1760px 미만 구간은 이미 확인된 값이라 그대로 두고, 1760px부터만 추가로
     커지는 보정항을 max()로 더해서(1760px 이전엔 0, 이후에만 작동) 2560px에서
     정확히 그 목표에 도달하도록 함 */
  .work-col-process,
  .work-col-contact,
  .work-blog{
    margin-left:calc(clamp(-241px, 82.74px - 18.393vw, -105px) + max(0px, 4.875vw - 85.8px));
  }

  /* 42차 재조사(2026-07-21): "대 사이즈(1769px 이상)는 확정, 중간 사이즈
     (1028~1769px)에서 파란박스(Process/Contact/Blog) 3개를 빨간선 쪽으로
     화살표만큼만 우측 이동" — 도로안전시설물 페이지 스크린샷 기준, 화살표
     길이를 그 화면에서 같이 보이는 Work→Process 라벨 간격 비율(약 48%)로
     환산한 값을 그대로 더했더니, 1769px 경계에서 이미 확정된 대 사이즈 값과
     안 이어지고 뚝 끊기는(순간적으로 오히려 왼쪽으로 튀는) 문제 발견 — 실측
     결과 1760px에서 새 값이 대 사이즈 시작점(1769px)의 확정값보다 더 오른쪽에
     있어서 생긴 역전 현상. 그래서 보정항 자체를 1028px에서 최대(약 42px)로
     시작해서 1769px 경계로 갈수록 점점 0으로 줄어들게(경계에서 정확히
     이어지도록) 다시 설계함 — 1769px 이상(대 사이즈, 확정본)은 이 미디어쿼리
     범위 밖이라 전혀 영향 없음. Process가 Work 반대쪽(오른쪽)으로 이동하는
     것이라 Work와의 겹침 위험은 없음(오히려 여유가 늘어남) */
  /* 45차 재조사(2026-07-21, 석재시공 페이지 실측 기준): "43차에서 우측으로
     너무 밀었더니, 좁은 쪽(1028~1300px 부근)에서는 라벨3개 박스가 타이틀
     ('석재시공'의 마지막 글자 '공')보다 오히려 더 오른쪽으로 넘어가버림 —
     '공' 옆 파란줄에 맞춰 왼쪽으로 당길 것" 요청 반영. 1300px에서는 이미
     정확히 '공'의 오른쪽 끝과 일치(43차 계산 자체가 1300px 기준이었어서
     우연히 딱 맞음)하지만, 1300px보다 좁아질수록 위 43차 공식이 '공'을
     지나쳐 계속 우측으로 튀어나감(1100px에서 실측 약 50px 초과, 1028px에서
     최대 약 68px 초과) — 그래서 "라벨박스 왼쪽 끝이 '공'의 오른쪽 끝을
     넘지 않도록" 상한선 역할을 하는 두 번째 공식을 만들어 min()으로 43차
     공식과 비교해서 더 작은(더 왼쪽) 값을 쓰도록 함:
     - 1300px 이상에서는 43차 공식이 이미 이 상한선보다 작아서(그전부터
       '공'보다 왼쪽에 있었으므로) 아무 변화 없음(1769px 경계 이어짐도 그대로 유지).
     - 1300px 미만에서는 이 상한선이 작동해서 정확히 '공'의 오른쪽 끝에
       맞춰짐 — 폭이 좁아질수록 원래(42차) 위치에 가까워지는 형태라(42차는
       이미 6페이지 전체 안전 검증 완료본), 트렌치/도로안전시설물 등 Work
       목록이 긴 페이지에서도 겹침 위험 없음(오히려 42차보다 살짝 더 여유
       있는 방향) — Playwright로 전 페이지·전 구간 재확인 완료 */
  /* 49차 재조사(2026-07-21, 도로안전시설물 페이지 window.innerWidth=1758
     실측 기준): "1758px 부근에서도 라벨3개(Process/Contact/Blog)가 텍스트
     1글자 폭 정도 우측으로 더 가면 좋겠다" — 45차(공 정렬) 공식이 1300px
     이상에서는 43차 타협 공식이 그대로 쓰이는데, 그 공식 자체가 1769px
     경계로 갈수록 보정량이 거의 0으로 줄어들어서(1758px에서 실측 약 1.7px
     밖에 안 남음), 1769px 바로 아래 구간(대략 1600~1769px)에서 사실상
     "대 사이즈와 거의 같은 위치"가 되어버려 사용자가 느끼기엔 부족해 보임.
     실측한 목록 텍스트 한 글자 폭(약 16.4px, 여유 둬서 18px로 반올림)만큼
     "삼각형(텐트) 모양" 보정을 추가: 1600px에서 0 → 1758px에서 최대(18px)
     → 1769px 경계에서 다시 정확히 0(대 사이즈 확정본과 계속 이어짐, 1300px
     이하 '공' 정렬 구간은 1600px 밖이라 전혀 영향 없음) */
  @media (min-width:1025px) and (max-width:1768.98px){
    .work-col-process,
    .work-col-contact,
    .work-blog{
      margin-left:calc(
        min(
          calc(clamp(-241px, 82.74px - 18.393vw, -105px) + 277.31px - 15.676vw),
          calc(30.81px - 8.743vw)
        )
        +
        min(
          clamp(0px, 11.392vw - 182.28px, 18px),
          clamp(0px, 2894.7px - 163.6vw, 18px)
        )
      );
    }
  }

  /* 35차 재조사(2026-07-21, 포토샵 시안): "프로세스/컨택/블로그는 지금 위치 그대로
     두고, 석재시공/Work/외벽석재/Prev만 오른쪽으로 더 이동 — 사진과의 여백이
     지금(.work-hero의 gap 64px)의 2배(128px)는 되도록"이라는 새 지시. 위
     .work-col-process 등의 margin-left는 이 요청과 무관하므로 그대로 둠(수정 안 함).
     Work 그룹에만 padding-left를 다시 추가하되, 이번엔 6개 페이지 전부와
     1025~1760px 전 구간에서 Work 텍스트 끝~Process 시작 사이 실제 여유(clearance)를
     다시 실측해보니, 트렌치/도로안전시설물(항목 텍스트가 더 길어서 여유가 가장
     좁음) 기준 1025px에서 겨우 45.8px, 1280~1760px 구간에서도 60~62px 정도뿐이라,
     고정 64px를 그대로 더하면 바로 이 두 페이지에서 겹침 발생(실측: 1025px에서
     -18px 정도 겹침). 그래서 고정값 대신, 좁은 화면에서는 더 작게(약 27px, 안전
     여유 20px+ 확보), 넓어질수록 커져서 아주 넓은 화면(맥스튜디오 등, 실측상
     3000px 이상)에서 정확히 요청하신 64px(=사진과의 여백 128px, 정확히 2배)에
     도달하도록 뷰포트 폭 비례식으로 변경 — 6개 페이지 전 구간 재측정으로
     겹치지 않음 확인 완료 */
  /* 36차 재조사(2026-07-21): "지금의 여백의 2배로 더 안쪽으로 이동, 텍스트
     길이는 내가 맞춰서 축소할 것" — Work→Process 사이의 실제 여유(clearance,
     이게 겹침을 막는 진짜 한계선)를 6개 페이지 기준으로 다시 재보니, 문자
     그대로 이전 이동폭을 2배(52~128px)로 하면 트렌치/도로안전시설물뿐 아니라
     지금 보고 계신 스톤 페이지에서도 1600~1760px 구간에서 실제로 겹침
     (최대 -18px)이 발생함 — 사진↔Work 사이 여백은 옆에 아무 것도 없어서
     무한정 키워도 되지만, Work↔Process 사이는 Process가 그 자리에 그대로
     있어서 여유가 정해져 있는 한계임. 그래서 스톤/미장/조적/기타작업(여유가
     넉넉한 4개 페이지) 기준으로 안전 여유(약 10~12px)를 남기고 최대한 크게
     늘림(약 43px→63px, 1025→1760px). 트렌치/도로안전시설물은 지금 텍스트
     기준으로는 1760px 부근에서 아주 미세하게(약 1px, 렌더링 오차 수준) 스칠
     수 있는데, 말씀하신 대로 그 두 페이지 텍스트를 줄이면 완전히 해소됨 */
  /* 37차 재조사(2026-07-21, 핑크선 시안 2차): "석재시공 타이틀도 같이 동그라미쳤다 —
     타이틀/Work/목록/Prev 전부 핑크선에 왼쪽 정렬. 지금 실제 쓰는 맥스튜디오
     창폭(window.innerWidth=2560px) 기준으로." 2560px에서 Work→Process 사이
     실제 여유가 171~204px(6개 페이지 전부, 트렌치/도로안전이 가장 좁아도
     171px)라서, 이 폭에서는 훨씬 크게 밀어도 안전함 — 시안 이미지 비례
     추정으로 2560px에서 필요한 이동폭이 기존(약 85px)보다 113px 더 커야 함
     (합계 약 198px). 다만 1440~1900px 구간은 여유가 60px 안팎으로 여전히
     좁아서, 36차 공식을 그 구간까지 그대로 유지하고, 1920px부터만 추가로
     더 커지는 항을 더해서(calc의 max()로 "1920px 이전엔 0, 이후엔 커짐"을
     구현) 2560px에서 정확히 목표(약 198px)에 도달하도록 함 — 1920px 경계에서
     두 식이 매끄럽게 이어지도록 계산, 6개 페이지 1920~2560px 전 구간 재검증 */
  .work-title,
  .work-col-work,
  .work-actions{
    padding-left:calc(clamp(30px, 15.11px + 2.721vw, 128px) + max(0px, 20.4vw - 391.68px));
  }

  /* 여백 5차 재조사(2026-07-20): margin-bottom(title/label)·margin-top(blog)는
     이제 base 규칙에서 clamp(...,vw,목표px)로 1025px에서 정확히 53/36/50에
     도달하도록 만들어서 여기서 다시 고정할 필요가 없어짐(그대로 이어받음) —
     좁은 화면(약 600~900px)에서 텍스트가 안 줄바꿈되면서 여백만 상대적으로
     넓어 보이던 문제 때문에 고정 px 대신 비례 스케일로 변경 */
  /* 행간(li line-height)·Visit-Next 폰트는 소 사이즈에도 동일하게 적용해야 해서
     base 규칙으로 옮김 — 위쪽 .work-col li, .work-actions 참고 */

  /* 왼쪽: 세로 방향 자체 스크롤(레퍼런스처럼 아래→위로 슬라이드하며 지나감).
     오른쪽 info/actions는 grid 자리에 고정된 채 그대로 보임.
     고정 박스 + object-fit:contain은 모바일과 동일 원칙, 축만 세로로 전환 */
  .work-gallery,
  .work-process{
    grid-row:1 / -1;
    height:100%;
    flex-direction:column;
    overflow-x:hidden;
    overflow-y:auto;
    /* 13차 재조사(2026-07-20): "이미지 사이의 간격 훨씬 더 늘리고" —
       var(--grid-gutter)(약 16~20px)로는 부족하다는 지적으로 고정값으로
       크게 키움.
       14차 재조사(2026-07-21): "슬라이드되는 이미지 사이의 여백을 115%
       정도로" — 기존 56px에서 15% 더 키움(56 * 1.15 = 64.4 → 64px).
       15차 재조사(2026-07-21): "이미지 사이의 간격은 50% 축소" — 중/대
       사이즈에만 적용, 64px→32px(모바일은 64px 그대로 유지).
       16차 재조사(2026-07-21, 마젠타 표시): "간격이 아직 너무 넓다, 약 -60%
       더 줄여라" — 32px * 0.4 = 12.8 → 13px(모바일은 여전히 64px 그대로).
       39차 재조사(2026-07-21): "이미지 사이 간격을 50%로 줄여줘" — 13px→6.5px
       (모바일 64px는 이번에도 무관, 그대로 유지).
       40차 재조사(2026-07-21): 위 flex-basis 버그를 고치고 나니 실제 gap이
       6.5px 그대로 보여서 "이제 아예 여백이 없어 보인다, 캡션 2줄 높이만큼
       (전체적으로 4줄 분량처럼 보이게) 여백을 넣어달라"는 요청 — 캡션
       (.work-gallery-caption, cap-title+cap-desc 2줄)의 실제 렌더링 높이를
       실측해보니 항상 그 캡션 폰트 크기(clamp(14px,1.1vw,19px))의 약 2.95배였음
       (1025px:41.2px, 1760px 이상:56.2px) — 캡션과 완전히 같은 비율로 커지는
       gap 공식으로 변경해서, 화면 폭이 바뀌어도 "캡션 2줄 높이만큼의 여백"이
       항상 정확히 유지되도록 함.
       41차 재조사(2026-07-21): "여백을 50% 더 늘려줘" — 위 40차 값 전체(최소/
       vw비례/최대)에 1.5를 곱함(41.3→61.95, 3.245vw→4.8675vw, 56.05→84.075) */
    gap:clamp(61.95px, 4.8675vw, 84.075px);
  }
  /* 39차 재조사(2026-07-21): "사진 사이 간격을 50%로 줄였는데도 여전히
     넓다" — 원인은 .work-gallery의 gap(6.5px)이 아니라, 이 flex:0 0 86%가
     모바일(가로 캐러셀, 86%가 "폭") 값을 세로 방향인 데스크톱에도 그대로
     물려받아서 각 아이템의 "높이"가 세로 컨테이너 전체의 86%로 고정되고
     있었던 것 — 실제 사진+캡션 내용은 그보다 훨씬 짧아서, 그 차이만큼
     아이템 박스 안에 안 보이는 빈 여백이 생겨 마치 간격이 넓은 것처럼 보임.
     flex-basis를 auto로 바꿔서 아이템 높이가 실제 내용(사진+캡션)만큼만
     차지하도록 수정 — 이제 위아래 간격이 진짜 gap(6.5px)값 그대로 보임 */
  .work-gallery-item{
    flex:0 0 auto;
    width:100%;
  }
  /* 42차: 대표님 요청으로 고정 비율 박스 자체를 없앰(위 base 규칙 주석 참고) —
     width:100%만 남기고 aspect-ratio는 base와 마찬가지로 지정하지 않아서
     사진/영상마다 원본 비율 그대로 표시됨. object-fit:contain으로 인한
     레터박스 여백 문제가 애초에 없어져서, 아래 있던 페이지별 3:2 오버라이드
     블록도 함께 삭제(더 이상 필요 없음 — img/video 자체 규칙은 base의
     width:100%;height:auto;를 그대로 상속받음) */
  .work-gallery-photo{
    width:100%;
  }
}

@media (min-width:1440px){
  /* 2026-07-21: 갤러리:정보 칼럼이 이제 1025px 이상에서 항상 1fr 1fr(균등
     분할)이라, 1440px 이상에서만 정보 칼럼을 더 넓히던(420px 고정) 예전
     로직은 더 이상 필요 없어 제거 — 폭이 넓어져도 그대로 절반씩 나눠 가짐 */
  .work-title{ font-size:56.1px; } /* 38차: 66*0.85=56.1, 위 base clamp와 동일 비율 유지(중복이지만 무해) */

  /* 참고: 최근 redline(세부페이지7-2/7-3.jpg) 실물 확인 결과, 소/대 두 브라우저
     창 모두에서 여백 76/53/36/50px로 동일한 숫자가 찍혀 있었음 — "소 일때와
     대 일때 기준으로 지금 보낸거야"는 두 사이즈에 서로 다른 값을 쓰라는
     뜻이 아니라, 두 사이즈 모두에서 이 값이 똑같이 지켜져야 한다는 확인이었음.
     그래서 1440px 이상 전용 여백 오버라이드는 따로 두지 않음(위 1025px
     규칙의 76/53/36/50이 1440px 이상에도 그대로 이어짐) */
}

/* ---------- 모바일(1024.98px 이하): 갤러리 세로 스크롤 + 하단 고정 Prev/Next ----------
   2026-07-21: 원래 미장(plastering.html) 페이지에서만 실험했던 방식("소에서
   중/대로 창을 늘리면 이미지가 아래에서 위로 올라가듯, 모바일에서도 위→아래로
   흐르게" 요청에서 출발)을 6개 페이지 전체 기본값으로 승격. 데스크톱(1025px
   이상)의 세로 갤러리 구현과 동일한 원리 — grid의 1fr 행이 100dvh 박스 안을
   끝까지 채워서 그 안에서 세로로 흐름. js/category-detail.js의 isVertical()이
   flex-direction을 그대로 읽어서 자동으로 세로 스크롤 방향으로 흘러가게
   처리해줌(코드 수정 불필요). 좌우 여백(.work-hero의 grid-margin padding)은
   그대로 유지 — 갤러리 내부 레이아웃만 바꾸고 바깥 여백은 건드리지 않음 */
@media (max-width:1024.98px){
  /* 13차 재조사(2026-07-20): "이미지는 바닥에서 여백없이 출발, 이미지 슬라이드
     위로 하단 영어버튼(Prev/Next)이 위치" — 사진이 화면(섹션) 맨 아래까지 꽉
     차게 하고, 고정 Prev/Next 바가 그 사진 위에 오버레이로 얹히도록 함.
     데스크톱(1025px 이상)에서 이미 검증된 "grid 1fr 행이 100vh 박스 안에서
     갤러리를 끝까지 채우는" 방식을 모바일 1열 레이아웃에도 그대로 재사용 —
     actions는 어차피 position:fixed라 grid 흐름에서 완전히 빠지므로
     grid-template-areas에서도 아예 제외해서 gallery-actions 사이의 44px
     행 간격(gap)이 남지 않게 함 */
  .work-hero{
    height:100vh;
    /* 실제 모바일 브라우저(주소창이 스크롤에 따라 늘었다 줄었다 하는 iOS
       Safari 등)에서는 100vh가 주소창까지 포함한 최대 높이로 계산돼서
       실제 눈에 보이는 화면보다 커지거나 작아지는 오차가 생길 수 있음 —
       실제 표시 영역 기준인 100dvh를 지원하는 브라우저에서는 그 값으로
       덮어써서 실기기에서도 정확히 화면 끝까지 맞도록 함(100vh는 dvh
       미지원 구형 브라우저용 폴백으로 남겨둠) */
    height:100dvh;
    grid-template-rows:auto minmax(0,1fr);
    grid-template-areas:
      "info"
      "gallery";
    box-sizing:border-box;
    padding-bottom:0;
  }
  .work-gallery,
  .work-process{
    flex-direction:column;
    overflow-x:hidden;
    overflow-y:auto;
    height:100%;
    /* "이미지 사이의 간격 훨씬 더 늘리고" — 데스크톱 세로 갤러리와 동일하게 확대.
       2026-07-21: "115% 정도로" 재요청 — 56px → 64px(데스크톱과 동일하게 유지) */
    gap:64px;
    /* 실기기(특히 iOS Safari)의 elastic/러버밴드 바운스 스크롤이 이 컨테이너의
       스크롤 경계를 넘어서면 순간적으로 배경색이 비쳐 보여서 "사진이 바닥에
       안 붙어 있다"처럼 보일 수 있음 — 컨테이너 자체 스크롤에서 바운스가
       바깥(페이지)으로 번지지 않게 막음 */
    overscroll-behavior-y:contain;
  }
  .work-gallery-item{
    flex:0 0 auto;
    width:100%;
  }
  /* 42차: 데스크톱 블록과 동일하게 고정 비율 박스를 없앰 — 페이지별 3:2
     오버라이드 블록 전체 삭제(더 이상 필요 없음, base 규칙의
     width:100%;height:auto;만으로 각 사진/영상 원본 비율이 그대로 나옴) */

  /* 2026-07-20: "푸터 형식의 Visit/Next(Prev/Next) 버튼은 고정되어 있어야지"
     — 갤러리가 이제 자체 스크롤(overflow-y:auto)이라 데스크톱처럼 Prev/Next도
     화면 하단에 고정된 푸터 바 형태로 항상 보이게 함. */
  .work-actions{
    position:fixed;
    left:0;
    right:0;
    bottom:0;
    z-index:20;
    /* 20차 재조사(2026-07-20): 포토샵 합성 레퍼런스 확인 결과, Prev/Next
       뒤에 불투명한 색상 띠(배경)가 있는 게 아니라 사진 위에 텍스트만 바로
       얹혀 있어야 했음 — 지금까지 "이미지가 바닥에 안 붙는다"는 지적이
       계속됐던 진짜 원인이, 실제로 사진이 안 붙어있던 게 아니라 이 불투명
       배경 띠 자체가 사진과 다른 색상 블록으로 보여서 마치 여백처럼 보였던
       것으로 보임. 배경을 없애고 사진 위에 바로 얹음.
       21차: text-shadow(흰색 광원 효과)는 "촌스럽다"는 피드백으로 제거 —
       배경 없이 텍스트만 순수하게 얹힘 */
    background:none;
    padding:16px var(--grid-margin);
    margin-top:0;
  }
}
