@zalkera/client 0.17.0 → 0.18.0

package/dist/index.d.ts

@@ -161,8 +161,10 @@ interface ListPagesParams {
  * 여기에 형상을 다시 적지 않는다 — 두 벌이면 갈라진다(사본 넷이 주석 규약으로 갈라진 사고가 실재).
  * 아는 타입 목록은 [SECTION_CONTRACT] 로 제공한다.
  *
- * `SERVICE_MENU` 의 `{ categorySlug }` 변형만 예외적으로 여기 적어 둔다 — 공개 상품 API 에 카테고리
- * 필터가 없어 **스펙에는 있으나 소비자가 아직 지원하지 않는** 상태라, 스펙만 봐서는 알 수 없다.
+ * ⚠ **섹션은 업무 데이터(상품·갈래)를 가리키지 않는다**(계약 rev 6 · memo142 §1). 종전에는
+ * `SERVICE_MENU { categorySlug }` 같은 조회형 변형을 여기 예외로 적어 뒀는데, 그 타입들이 어휘에서
+ * 삭제됐다. 진열은 소스가 [listProducts]·[listProductCategories] 를 **직접 호출**해 그린다 — 어디에
+ * 뿌릴지도 어떻게 그릴지도 소스의 몫이다.
  */
 interface PageSection {
     type: string;
@@ -950,14 +952,25 @@ declare class ZalkeraError extends Error {
  * 그래서 아래 `SECTION_CONTRACT` 리터럴은 rev 3 과 **바이트 동일**하다(동기 스크립트가 확인한다).
  *
  * rev 5 = **`categorySlug` 를 대등 참조로**(memo139). `SERVICE_MENU`·`BOOKING_CTA` 의 필수성 단위가
- * "productIds 가 있는가"에서 **"참조가 하나라도 있는가"**(`requiredRefsAnyOf`)로 옮겨갔다. 이유는
- * 외양의 출처가 자유이기 때문이다: 배송된 예제가 상품을 handle 로 박아 두면 그 소스를 받은 사람의
- * 카탈로그에는 그 handle 이 없어 섹션이 **영구히** 빈다. 갈래로 가리키면 자기 상품을 등록하는 대로
- * 채워진다. rev 3 이 막으려던 것(참조 0 = 조용히 사라지는 섹션)은 그대로 막히고 **막는 단위만
- * 넓어졌다.** `BOOKING_CTA` 의 갈래형은 `/c/{slug}` 로 보낸다 — 어느 상품이 CTA 를 받을지는
- * 머천다이징이라 껍데기가 정하지 않는다.
+ * "productIds 가 있는가"에서 **"참조가 하나라도 있는가"**(`requiredRefsAnyOf`)로 옮겨갔다. 그 시대의
+ * 판단이었고 rev 6 이 뒤집었다(아래).
+ *
+ * rev 6 = **`SERVICE_MENU`·`BOOKING_CTA` 완전 삭제 — 12종 → 10종**(memo142 §오너확정2-1). rev 3·5 가
+ * "조회형 섹션은 참조를 반드시 실어라"로 조이던 잣대가 **"조회형 섹션을 싣지 마라"로 반전**됐다.
+ * 경계 규칙(memo142 §1): 값이 콘텐츠 파일에 사는 저작물은 **선언 섹션**의 소관이고, 값이 업무 DB 에
+ * 살고 화면이 비추기만 하는 조회는 **소스가 이 패키지를 직접 호출**해 그린다(`listProducts()`·
+ * `listProductCategories()`). 절반 선언(`SERVICE_MENU`)은 "어디에"만 선언에 두고 "어떻게"(카드 그리드·
+ * 필드·개수)를 공유 렌더러에 얼려 두는 형태였고, 그것이 자연어로 다양한 디자인을 만든다는 방향과 반대다.
+ *
+ * **`retired` 표기가 아니라 삭제**인 이유: 실측상 정당한 잔존 소비자가 0이었고(상용 `page_section`·
+ * `product`·`product_category` 전부 0행), memo128 이 이미 `page_section` 계열을 퇴역 방향으로 잡아 뒀다.
+ * 제3 상태는 계약·검사기·팩 게이트·콘솔이 각자 해석해야 하는 축을 새로 만든다.
+ *
+ * ⚠ **계약이 스큐 내성이라 이 삭제가 구 사이트를 깨지 않는다** — 렌더러는 미지 타입을 조용히 스킵한다.
+ * 어휘를 강제하지도 않는다(memo125 요건 1): 자기 소스에 무엇을 적든 자유이고, 집행은 **우리 산출물인
+ * 팩**에만 선다.
  */
-declare const SECTION_CONTRACT_REV = 5;
+declare const SECTION_CONTRACT_REV = 6;
 /** 업종 분류 — 콘솔 섹션 픽커의 그룹핑에 쓴다(테넌트 업종 필드는 아직 없다·memo102 §5). */
 type SectionVertical = "BEAUTY" | "GENERAL";
 interface SectionSpec {
@@ -970,12 +983,16 @@ interface SectionSpec {
      *
      * 계약 전체를 실어 나르지 않고 이 축만 뽑아 오는 이유: 이 값을 읽는 소비자가 **팩 게이트 하나**이고,
      * 그가 답해야 하는 질문이 정확히 "이 섹션이 아무것도 안 가리킨 채 시드에 들어와 있는가"이기 때문이다.
-     * 상품 참조 0 인 `SERVICE_MENU` 는 렌더러가 `return null` 해서 **개시 직후 조용히 사라지는 섹션**이
+     * 아무것도 안 가리킨 참조형 섹션은 렌더러가 `return null` 해서 **개시 직후 조용히 사라지는 섹션**이
      * 된다 — 그 결함이 고객 개시 순간이 아니라 우리 터미널에서 죽게 하는 것이 이 필드의 전부다.
      *
-     * 키 이름은 정본 그대로 **id 형**(`productIds`)이다. 시드가 쓰는 참조형 키(`products`)로 미리
-     * 바꿔 두지 않는 이유: 이 패키지는 정본의 운반체이지 시드 문법의 번역기가 아니고, id↔참조 대응
-     * 규칙은 백엔드 `SeedProductReferences` 와 팩 게이트가 각자 자기 자리에서 안다.
+     * ⚠ **rev 6 기준 이 축을 쓰는 타입은 0 이다.** 그 요구를 갖던 둘이 어휘에서 삭제됐기 때문이다.
+     * 필드를 남겨 두는 것은 계약 기계를 유지하기 위해서다 — 참조가 필수인 **저작물** 타입이 앞으로
+     * 생길 수 있고(에셋 축), 팩 게이트가 이 선언을 읽는 코드도 그대로 선다. 다만 **조회형 타입의 증설로**
+     * 이 축이 되살아나는 일은 없다(memo142 §6-2 가 그 문을 닫았다).
+     *
+     * 키 이름은 정본 그대로 **id 형**이다. 시드가 쓰는 참조형 키로 미리 바꿔 두지 않는 이유: 이 패키지는
+     * 정본의 운반체이지 시드 문법의 번역기가 아니고, id↔참조 대응 규칙은 팩 게이트가 자기 자리에서 안다.
      *
      * **필수성의 집행 지점은 팩/시드뿐이다** — 런타임은 그대로 관용이다(렌더러 스킵·콘솔 raw 편집 허용).
      */
@@ -987,13 +1004,16 @@ interface SectionSpec {
      * 역할을 하게 되면서 필수의 단위가 **"참조 존재"**로 옮겨갔다. 막으려는 것은 그대로다 — 아무것도
      * 안 가리킨 채 시드에 들어와 개시 직후 조용히 사라지는 섹션.
      *
+     * ⚠ `requiredRefs` 와 같이 **rev 6 기준 이 축을 쓰는 타입도 0 이다**(그 둘이 삭제됐다). 남기는
+     * 이유도 같다 — 계약 기계는 유지하고, 되살릴 문은 memo142 §6-2 가 닫았다.
+     *
      * `requiredRefs`(무조건 필수)와 **함께** 쓴다: 그룹으로 표현되는 섹션은 `requiredRefs` 가 빈 배열이고,
      * 종전처럼 단일 키가 무조건 필수인 섹션은 이 필드가 빈 배열이다. 둘 다 빈 배열이면 참조 요구가 없다.
      */
     readonly requiredRefsAnyOf: readonly (readonly string[])[];
 }
 /**
- * 아는 섹션 전량. **순서는 콘솔 픽커의 노출 순서**(관행 아크: 주목→가치→신뢰→행동).
+ * 아는 섹션 전량(rev 6 기준 **10종**). **순서는 콘솔 픽커의 노출 순서**(관행 아크: 주목→가치→신뢰→행동).
  * 값 추가는 백엔드 스펙을 먼저 고친 뒤 여기로 옮긴다.
  *
  * `requiredRefs` 는 빈 배열이라도 **반드시 적는다**. 생략을 허용하면 동기 스크립트의 리터럴 정규식이
@@ -1001,23 +1021,11 @@ interface SectionSpec {
  * 길이 열린다 — 빠뜨림이 침묵이 아니라 실패가 되는 형상을 고른다.
  */
 declare const SECTION_CONTRACT: readonly [{
-    readonly type: "SERVICE_MENU";
-    readonly vertical: "BEAUTY";
-    readonly jsonLd: "ItemList";
-    readonly requiredRefs: readonly [];
-    readonly requiredRefsAnyOf: readonly [readonly ["productIds", "categorySlug"]];
-}, {
     readonly type: "BEFORE_AFTER_GALLERY";
     readonly vertical: "BEAUTY";
     readonly jsonLd: null;
     readonly requiredRefs: readonly [];
     readonly requiredRefsAnyOf: readonly [];
-}, {
-    readonly type: "BOOKING_CTA";
-    readonly vertical: "BEAUTY";
-    readonly jsonLd: null;
-    readonly requiredRefs: readonly [];
-    readonly requiredRefsAnyOf: readonly [readonly ["productId", "categorySlug"]];
 }, {
     readonly type: "DOCTOR_INTRO";
     readonly vertical: "BEAUTY";
@@ -1127,10 +1135,14 @@ declare function mediaSrc(assetId: number): string;
 /** 상품 handle 하나. 문자열이 아니거나 공백뿐이면 `undefined` — 형식은 검사하지 않는다(런타임은 관용). */
 declare function asHandle(value: unknown): string | undefined;
 /**
- * 상품 handle 배열. **배열 순서를 보존한다** — 콘텐츠 파일에서 이 배열이 노출 순서의 원장이다
- * (`SERVICE_MENU` 의 ItemList 가 이 순서 그대로 나가야 한다).
+ * 상품 handle 배열. **배열 순서를 보존한다** — 이 배열이 노출 순서의 원장이고, 같은 배열에서 만든
+ * ItemList 가 화면과 같은 순서로 나가야 한다.
  * 배열이 아니면 빈 배열, 원소 중 handle 이 아닌 것만 떨군다. 중복은 남긴다 — 같은 상품을 두 번
  * 진열하는 것이 계약 위반은 아니다.
+ *
+ * ⚠ **어휘 rev 6 이후 이 헬퍼의 소비자는 섹션 config 가 아니라 소스다.** 조회형 섹션 타입이 삭제되면서
+ * "선언에 적힌 handle 목록"이라는 입력이 계약에서 사라졌다. 헬퍼를 남기는 이유는 소스가 자기 큐레이션
+ * (자기 카탈로그 안의 자기 handle — 정당하다)을 배열로 들고 다닐 때 여전히 쓰이기 때문이다.
  */
 declare function asHandleArray(value: unknown): string[];
 /**

package/dist/index.js

@@ -304,17 +304,12 @@ function safeJsonParse(text) {
 }
 
 // src/sections.ts
-var SECTION_CONTRACT_REV = 5;
+var SECTION_CONTRACT_REV = 6;
 var SECTION_CONTRACT = [
-  // 뷰티(memo47) — append-only 계약상 불변
-  // SERVICE_MENU 의 ItemList 는 rev 2 에서 올라왔다(memo119 T6-ⓒ): 쇼핑몰 유형엔 상품 목록 표면을
-  // 요구하면서 예약 유형엔 시술 목록 표면이 없던 비대칭의 해소다. 뷰티 사이트에서 시술 목록의
-  // 정위치는 별도 라우트가 아니라 홈의 이 섹션이라, FAQ_LIST→FAQPage 와 같은 형태로 섹션이 직접 낸다.
-  // rev 3 에서 productIds 의 `?` 가 떨어졌다 — 목록을 내겠다고 선언한 섹션이 목록을 안 가리키는 상태가
-  // 계약상 성립하지 않게 됐다(BOOKING_CTA.productId 는 rev 1 부터 필수였다·비대칭 해소).
-  { type: "SERVICE_MENU", vertical: "BEAUTY", jsonLd: "ItemList", requiredRefs: [], requiredRefsAnyOf: [["productIds", "categorySlug"]] },
+  // 뷰티(memo47) — 조회형 둘(SERVICE_MENU·BOOKING_CTA)은 rev 6 에서 삭제됐다(위 KDoc).
+  // 시술 목록의 ItemList 는 사라진 것이 아니라 거처가 바뀌었다: `/products` 라우트와 소스가 조합하는
+  // 진열이 낸다(보장표 `service-menu-itemlist` 의 route 는 원래 `any` — 판정 지점은 산출물이다).
   { type: "BEFORE_AFTER_GALLERY", vertical: "BEAUTY", jsonLd: null, requiredRefs: [], requiredRefsAnyOf: [] },
-  { type: "BOOKING_CTA", vertical: "BEAUTY", jsonLd: null, requiredRefs: [], requiredRefsAnyOf: [["productId", "categorySlug"]] },
   { type: "DOCTOR_INTRO", vertical: "BEAUTY", jsonLd: null, requiredRefs: [], requiredRefsAnyOf: [] },
   // 기업 마케팅(memo102 §2)
   { type: "HERO", vertical: "GENERAL", jsonLd: null, requiredRefs: [], requiredRefsAnyOf: [] },