@flextudio/scenario 0.1.0

package/skill/references/spec-evolve/data-connection.md

@@ -0,0 +1,102 @@
+# data-connection — B 경로: 마스터-디테일 → 데이터연결 매핑
+
+B 경로(구조 제공 또는 목록/조회성 추론)에서 마스터-디테일을 데이터연결로 설계하는 규칙. **정확한 필드 문법은 같은 스킬의 `docs/group.md`·`docs/data-objects.md`·`docs/data-sources.md` 와 `intent-rules.md` 가 정본** — 여기서는 keyRole → DataUsage 매핑과 목업 계획만 다룬다.
+
+## DataUsage 4모드 (어떤 keyRole 이 어디로)
+
+| 상황 | DataUsage | 적용 |
+|---|---|---|
+| 목록/카드 반복 렌더 (디테일·마스터목록) | `query` | Group `UseDataConnection:true` + `DataConnection{TargetType:'category', DataUsage:'query', CategoryName}`. 섹터 수만큼 복제 |
+| **단건 마스터/헤더 바인딩** (반복 아님, 1건 표시) | `default` | Group `UseDataConnection:true` + `DataConnection{DataUsage:'default', CategoryName}`. 그 카테고리 1섹터를 단건 바인딩 |
+| 신규 입력 (빈 폼 저장) | `new` | mock 면제 — 빈 카테고리에 억지 addSector 금지 |
+| 리스트에서 1건 선택해 수정 | `update` | activeSector 받아 폼 채움 |
+| 선택 건 읽기전용 상세 | `detail` | `UseTargetSector:true` + `Status:['active']`, 입력 불가 표시 |
+
+## 마스터-디테일(1:N) = 부모 + 자식 query + (조인키)
+
+keyRole 매핑:
+- `master` → 부모 Group 바인딩. **목록형이면 `DataUsage:"query"`(섹터 수만큼 반복), 단건 헤더형(입력 화면 등)이면 `DataUsage:"default"`(1섹터 단건).**
+- `detail` → 부모 Group **안쪽**의 자식 Group `DataUsage:"query"` + `TargetSector.Filters:[{FilterType:"Parent"}]`.
+- `link` → 그 Parent 필터의 조인 키: 부모키 `DCParentKey` / 자식키 `DCChildKey` 로 지정.
+- `detail`(상세 보기 화면/영역) → `DataUsage:"detail"`.
+
+즉 sample_spec 의 "마스터 Group + 디테일 행 반복" 은 B 에서 **부모 Group(바인딩) 안에 자식 query Group(Parent 필터)** 으로 표현된다. 단순 1단 목록(부모-자식 아님)이면 자식 없이 query Group 하나.
+
+### ★ 마스터도 반드시 바인딩 + 부모-자식 조인 (정적 마스터 금지)
+
+입력/단건 화면이라도 **마스터(헤더)를 비연결 정적으로 두고 디테일만 query 하지 말 것**(S-03 실패). 마스터도 자기 카테고리에 바인딩하고, 디테일을 그 **자식**으로 조인한다:
+
+- 마스터 Group → `UseDataConnection:true`, `DataUsage:"default"`(단건) 또는 `"query"`(목록), `CategoryName:"CtgImport"`. 헤더 표시 라벨은 `LabelCKey` 로 마스터 섹터 필드 바인딩.
+- 디테일(품목정보) Group → 마스터 Group **안쪽**에서 `DataUsage:"query"`, `CategoryName:"CtgImportItem"`, `TargetSector.Filters:[{FilterType:"Parent"}]`, `DCParentKey`/`DCChildKey` 로 마스터 키와 조인.
+- Init `intent.mock` 에 마스터 카테고리 1섹터 + 그에 속한 자식 카테고리 N섹터(조인키 일치).
+
+### ★ 같은 카테고리를 여러 그룹이 쓰면 상위 그룹 하나로 묶어 연결
+
+마스터 카드와 요약(예: `MasterCard` + `MasterSummary`)이 **같은 카테고리를 각각 따로 연결**하면 안 된다(S-02 실패: CtgMaster 를 두 그룹이 중복 연결). **공통 상위 Group 하나로 감싸 그 상위 Group 에만 `DataConnection` 을 건다.** 안쪽 자식 그룹들은 같은 섹터 컨텍스트를 상속하므로 각자 연결하지 않고 `LabelCKey`/`Ckeys` 바인딩만 한다.
+
+```
+부모래퍼 Group(UseDataConnection:true, DataUsage:"default"/"query", CategoryName:"CtgMaster")   ← 연결은 여기 한 번
+  ├ MasterCard Group(UseDataConnection:false)   ← 같은 섹터 상속, Label LabelCKey 바인딩
+  └ MasterSummary Group(UseDataConnection:false) ← 같은 섹터 상속, Label LabelCKey 바인딩
+```
+
+## 그룹을 한두 겹 더 감싼다 (중첩 래핑 — 얕으면 실패)
+
+정답 시나리오는 반복/데이터연결 영역을 **여러 겹 Group 으로 감싼다**(관찰된 중첩 깊이 6~8). 생성물이 얕으면(깊이 2~3) 데이터연결 래핑이 부실해 레이아웃·바인딩이 깨진다. 표준 래핑:
+
+- **조회 결과**: `스크롤 Group(ScrollType:"ScrollY", UseDataConnection:false) > 리스트 Group(UseDataConnection:true, DataUsage:"query") > row Group > [마스터섹션 + 디테일섹션]`. row 안에서 마스터 정보와 자식 목록을 다시 Group 으로 분리(Border-bottom 으로 구분).
+- **입력**: `마스터 Group(흰 배경) + graybg Group(회색, ScrollY) > contentsWrap Group(흰 박스, padding/radius) > 리스트 Group > row Group`.
+- 데이터연결(`UseDataConnection:true` + `DataConnection`)은 **반복이 일어나는 그 Group** 에 붙인다(바깥 스크롤 래퍼는 false). 한 겹 더 감싸 query 그룹을 격리하면 헤더·요약을 같은 스크롤 안에 두면서도 반복만 바인딩된다.
+- 영역 분리는 `DisplayStyle.rowGapValue`(예 20px) + Padding + Border 로.
+
+## 마스터 영역도 데이터연결 + 선택 반영 (정적으로 두지 말 것)
+
+마스터/헤더 영역을 전부 정적으로만 두지 않는다. 선택·표시가 데이터로 흐르게 한다:
+
+- **단건 마스터 카드**(반복 아님)의 표시 라벨은 `LabelCKey` 로 마스터 카테고리 섹터에 바인딩(현실적 mock 1섹터). 정말 고정 문구만 정적.
+- **종속 선택(Combo→Combo)**: 출고창고 선택 → 입고창고 옵션이 달라지는 종속은, 자식 Combo 의 Dialog `ComboList` 에 `Ckeys` 를 바인딩하고 그 옵션 카테고리에 **mock 을 다중(최소 2 옵션 이상) 으로** 박아 선택 종속이 시각적으로 드러나게 한다. (프로토타입에선 실제 필터 로직 대신 mock 옵션으로 표현.)
+- 마스터 선택값을 다음 Step 으로 넘길 땐 카드/버튼 `UseMove:true` + `MoveSteps.MoveStepOrder` + 각 Step `MoveTo:"Next"`(네비 채널). 스크립트 흐름제어 금지.
+
+## 콜렉션키 바인딩 (정적 텍스트 금지)
+
+- 반복 Group 안에서 데이터가 흐르는 항목은 섹터 필드를 **`LabelCKey`/`Ckeys` 로 바인딩**한다. 정적 `labeltext` 로 박으면 모든 카드가 같은 문구가 된다.
+- 1번만 보일 요소(제목·총건수 요약·"신규" 버튼)는 **query Group 바깥** 비연결 래퍼에 둔다.
+- `CategoryName` 은 `Ctg` 접두 + PascalCase (예: `CtgOrder`, `CtgOrderItem`).
+- **콜렉션키(`Ckeys`/`LabelCKey`/`CtrlDisplayCkey`)에 `f` 접두 금지.** 스펙에 키/필드명이 명시되면 **대소문자·표기 그대로**(예 `LotNo`·`BLNO`, 임의 camelCase 변환 금지), 미제공이면 의미있는 camelCase. ❌ `fOrderNo`·`fLotNo`.
+- 예약어 금지: `status`/`isActive`/`length` 등 + JS 예약어 (정본: `schemas/naming-objects.schema.json`).
+
+## 목업 동반 (필수)
+
+DataConnection/Ckeys 를 박으면 **반드시 시작 Step.Init 에 `intent.mock` 으로 해당 카테고리 mock 섹터를 동반**한다 — 없으면 `[proto]` 차단(SKILL.md "데이터 표시 결정" 참조).
+
+- 부모·자식 둘 다 mock 을 박아 조인이 실제로 그려지게 한다 (부모 2건+ / 각 부모에 자식 여러 건).
+- `new` 모드 카테고리엔 빈 addSector 를 억지로 넣지 않는다(mock 면제).
+- 배치 = named handler: `Step.Events.Init:"Step1Init"` + `scenario.Events.Step1Init` 안에 `intent.mock`.
+
+## 스펙(.spec.md)에 적는 법
+
+frontmatter:
+```yaml
+route: B
+dcModes: [query, detail, parent-child]
+categories:
+  CtgOrder:       { role: master, keys: [주문번호], fields: [주문일자, 합계금액] }
+  CtgOrderItem:   { role: detail, parentKey: 주문번호, childKey: 주문번호, fields: [상품명, 수량, 단가] }
+```
+본문 Step 설명에 "부모 query → 자식 query(Parent 필터, 주문번호 조인) → 상세 detail" 와 "Init mock: 주문 2건 + 각 상품 3건" 을 적는다. 자세한 본문 형태는 `templates/master-detail.spec.md`.
+
+## ★ 생성 후 데이터연결 보장 게이트 (스펙 경로 Phase 2 직후, 블로킹)
+
+`/flex-spec` 스펙 경로는 Phase 2(시나리오 생성) 가 끝나면 **반드시** 이 게이트를 통과해야 한다. 이건 `lint.md` 의 비블로킹 보고와 다른 **블로킹 점검**이다 — 데이터연결이 빠졌으면 통과시키지 말고 **샘플 시나리오를 참조해 추가 수정으로 주입**한다.
+
+1. **점검** — 산출 시나리오를 본다. 화면이 **목록·카드·"~별"·"~내역"·조회·반복·선택지(Combo/Search)·마스터-디테일** 성격인데 시나리오 전체에 `UseDataConnection:true` + `DataConnection` + 시작 Step.Init `intent.mock` 이 **0건이면 게이트 실패** → 다음 단계로.
+2. **샘플 참조** — `examples/index.json` 에서 **구조(`stepCount`/`patterns`/`controlTypes`)가 유사한 `design/` 샘플 시나리오**를 고른다. 도메인 글자 일치가 아니라 구조로 고른다. **반드시 먼저 `flex-scenario validate --no-write <후보 example>` 로 `ok:true` 를 확인**해 baseline 자격을 검증한다(`ok:false` 예제를 기준 삼지 말 것. ★ example 검증엔 `--no-write` 필수 — 기본 validate 는 `ok:true` 시 본문을 입력 파일에 write-back 해 참조 예제를 변형시킨다).
+3. **key-diff → 주입** — 그 샘플의 데이터연결 노드와 내 산출물을 **키 단위로 diff** 한다. 빠진 것을 `Edit`(부분 수정, 전체 Write 금지)으로 주입한다:
+   - 반복/목록 Group → `UseDataConnection:true` + `DataConnection{TargetType:'category', DataUsage:'query', CategoryName:'Ctg…'}` + 자식 `Ckeys`/`LabelCKey`.
+   - 마스터-디테일이면 부모 query(또는 단건 `default`) + 자식 query(`TargetSector.Filters:[{FilterType:'Parent'}]`, `DCParentKey`/`DCChildKey` 조인) — 이 절 위쪽 "마스터-디테일(1:N)" 규칙대로.
+   - 시작 Step.Init 에 named handler(`Step.Events.Init:"Step1Init"` + `scenario.Events.Step1Init` 안 `intent.mock`)로 해당 카테고리 mock(부모 2~3건 × 자식 2~3건, 조인키 일치) 동반.
+   - **정적 Label 복제로 도망가지 않는다.** 단건 마스터/헤더도 정적으로 두지 말고 `DataUsage:"default"` + `LabelCKey` 로 바인딩한다.
+4. **예외 (게이트 면제)** — 진짜 단건 고정 문구만 있는 표시 화면이거나, 실제 `scenario.DataSources`(`Fixed`/`Grid`) 가 채워져 정상 바인딩인 경우만 데이터연결 없이 통과. 신규 입력(`DataUsage:"new"`) 폼은 mock 면제(빈 addSector 금지).
+5. **재검증** — 주입 후 `flex-scenario validate <scenario>` 를 다시 `ok:true` 까지 통과시킨다. (`[proto]`/`[mock-init]` 이 게이트와 같은 신호 — validate 가 동반 차단해 준다.)
+
+> 직접 생성(기본) 경로에도 빈/정적 회귀 금지는 적용되지만(SKILL.md "데이터 표시 결정"), 이 **"샘플 참조 후 추가 수정으로 주입"하는 블로킹 게이트는 스펙 경로 전용**이다 — 스펙 경로는 데이터연결을 끝까지 보장한다.

package/skill/references/spec-evolve/intake.md

@@ -0,0 +1,41 @@
+# intake — 입력 모달리티 무관 추출
+
+화면정의서는 **엑셀 / 표 / 자유 텍스트 / 캡처본(이미지) / 한 줄 요청** 어떤 형태로도 온다. 형식에 단정짓지 말 것. 목표는 형식이 아니라 거기서 **공통 필드 목록**을 뽑는 것이다.
+
+## 모달리티별 읽는 법
+
+| 모달리티 | 방법 |
+|---|---|
+| 캡처/이미지 | `Read` 로 이미지를 직접 본다 — 레이아웃·라벨·반복 블록·입력칸을 눈으로 읽어 필드/마스터-디테일을 추출 |
+| 엑셀(.xlsx) | 시트를 텍스트로 덤프해 표를 읽는다. 아래 "관찰된 엑셀 형태" 참고 (강제 아님) |
+| 표/마크다운 | 컬럼 헤더에서 항목명·컨트롤·설명을 매핑 |
+| 자유 텍스트 | 문장에서 항목·동작·반복("~목록", "~별로")·선택지를 식별 |
+| 한 줄 요청 | 추출할 게 거의 없음 → `routing.md` 의 "구조 미제공" 경로로 |
+
+## 추출 결과 = 모달리티 무관 필드 목록
+
+각 항목을 다음으로 정규화한다 (없으면 비움 → 후속 단계가 추론):
+
+- `name` — 항목명 (예: 거래처, Lot No, 수량)
+- `intent` — 입력 의도: 표시 / 선택 / 날짜 / 코드도움 / 숫자 / 텍스트 / 반복목록 중 하나 (의도→컨트롤은 `conventions.md`)
+- `section` — master / detail (또는 미상)
+- `visible` — 표시 / 숨김 / 강조(중요)
+- `usage` — 저장·수정 / 조회조건 / 표시전용 등 (있으면)
+- `default` — 기본값 단서 (예: "현재일 -1month", "특정 고정값 디폴트")
+- `note` — 동작/통제 설명 원문
+
+## 관찰된 엑셀 형태 (부록 — 만나면 쓰는 힌트, 강제 아님)
+
+단일 시트, 헤더 + 두 섹션 표로 오는 경우가 많다:
+
+- 헤더 행: `프로그램명` · `화면구분`(입력 / 조회(일반)) · `개발개요` · `화면명` · `이벤트`(저장/삭제/신규/조회)
+- `Master` 표: `항목사용여부 | 항목명 | 컨트롤타입 | 항목설명 | (용도)`
+- `Detail(품목정보)` 표: 동일 5컬럼
+- `추가공유내용`: 버튼 동작·통제 로직 자유 서술
+
+규칙:
+- `항목사용여부` = `숨김` → **노드 생성 제외**(저장 시 시스템이 채우는 키일 때가 많음 — 채번/현재일/로그인부서 등). `중요` → 강조 스타일. `표시` → 일반.
+- 마지막 컬럼 의미는 화면구분에 따라 다름: 입력=`저장/수정`, 조회 Master=`조회조건`, 조회 Detail=`조회여부`.
+- `항목설명` 에 기본값 단서·연결 로직(원천 화면 조회 등)이 들어있다 → `default`/`note` 로 옮긴다.
+
+> `컨트롤타입` 표기(label/ComboBox/DateBox/Codehelp/FloatBox/TextBox …)가 **명시되면 그대로 직역**한다 — `conventions.md` §1 "직역(고정 매핑)" 표. 항목설명의 "조회/원천/참조" 단어에 휘둘려 `label`→`Search` 같이 바꾸지 말 것(대표 오매핑). 표기가 없을 때만 `intent` 로 추론한다.

package/skill/references/spec-evolve/key-roles.md

@@ -0,0 +1,44 @@
+# key-roles — 필드별 keyRole 판정 (비블로킹)
+
+스펙 진화 단계에서 각 필드에 `keyRole` 을 붙인다. 이는 중간 스펙(`.spec.md`)의 분석 산출물이며, 최종 시나리오 JSON 에는 들어가지 않는다(시나리오엔 자리 없음) — keyRole 은 마스터-디테일/데이터연결을 **어떻게 설계할지 결정하는 근거**다.
+
+## 다섯 가지 keyRole
+
+| keyRole | 의미 | 판정 근거 |
+|---|---|---|
+| `master` | 마스터(부모) 식별 키 — 1쪽 | 한 건이 여러 디테일을 거느림. 헤더/요약 영역의 식별자 (예: 주문번호, 반품요청번호) |
+| `detail` | 디테일(자식) 식별 키 — N쪽 | 마스터 1건 안에서 여러 건 반복 (예: 품목 Lot No, 라인번호) |
+| `link` | 부모-자식 조인 키 | 마스터키가 디테일에도 나타나 둘을 잇는 외래키 (예: 디테일의 주문번호) |
+| `none` | 키 아님 | 일반 표시/입력 필드 (품명, 수량, 금액 등) |
+| `provisional` | 임시 — 확신 없음 | 카디널리티가 안 잡히거나 마스터/디테일 어느 쪽인지 모호. **추측하지 말고 여기 둔다** |
+
+## 판정은 카디널리티로
+
+- 한 화면 안에서 **1건만 보이면 master 후보**(헤더/요약), **여러 건 반복되면 detail 후보**.
+- 마스터에도 디테일에도 같은 이름의 키가 보이면 그건 `link`(조인 키).
+- 디테일이 또 하위 디테일을 가지면(3단) 상위는 그 하위에 대해 master 역할 — 가장 가까운 부모 기준으로 판정.
+
+## 비블로킹 규칙 (중요)
+
+- 카디널리티가 안 서거나 마스터/디테일이 모호하면 **추측하지 말고 `provisional` + flag** 한다.
+- **불확실한 키 때문에 진행을 멈추지 않는다.** provisional 이 있어도 Phase 1 스펙 작성·Phase 2 생성은 계속한다.
+- provisional 필드는 **가장 그럴듯한 쪽으로 일단 렌더**하되(보통 detail 또는 none), 그 가정을 `.spec.md` frontmatter `provisional` 에 기록한다.
+- 최종 응답에서 lint 가 provisional 잔존을 "미해결"로 보고한다 (`lint.md`). 사용자가 정정하면 그때 확정.
+
+## .spec.md 에 기록하는 법
+
+frontmatter:
+```yaml
+keyRoles:
+  주문번호: master
+  주문일자: none
+  상품_주문번호: link        # 자식의 조인 키
+  상품명: none
+  Lot No: detail
+provisional:
+  - field: 검사구분
+    guess: none
+    why: 마스터 헤더에 단건이지만 조회조건일 수도 있어 카디널리티 불명
+```
+
+본문에서는 keyRole 을 직접 쓰지 않고, master→헤더/요약 Group, detail→반복 Group(B 경로면 DataUsage:"query"), link→부모-자식 조인키(`data-connection.md`)로 **반영**한다.

package/skill/references/spec-evolve/lint.md

@@ -0,0 +1,27 @@
+# lint — provisional/미해결 보고 (비블로킹)
+
+스펙 진화·생성은 불확실성 때문에 멈추지 않는다. 대신 **최종 응답에서 미해결 항목을 모아 보고**해 사용자가 정정할 수 있게 한다. 산출물(스펙·시나리오)은 그대로 낸다.
+
+## 무엇을 미해결로 잡나
+
+| 항목 | 출처 | 메시지 예 |
+|---|---|---|
+| `provisional` keyRole 잔존 | `key-roles.md` | "필드 '검사구분' keyRole 미확정(none 으로 가정) — 조회조건이면 알려주세요" |
+| 구조 미제공 추론 가정 | `routing.md` / frontmatter `assumptions` | "마스터-디테일을 주문↔주문상품으로 추론함 — 다르면 알려주세요" |
+| 모호한 화면 종류 | `routing.md` | "'재고'를 현황조회로 해석함" |
+| 기본값 단서 없음 | `conventions.md` | "기간 기본값 단서가 없어 최근 1개월로 가정" |
+
+## 출력 형식 (최종 응답에 1블록)
+
+```
+미해결 (비블로킹):
+- [provisional] 검사구분 → none 으로 가정. 조회조건이면 알려주세요.
+- [assumption]  마스터-디테일 = 주문 ↔ 주문상품 (추론). 다르면 정정 가능.
+산출물은 위 가정 위에서 생성했습니다. 정정하면 해당 부분만 다시 진화합니다.
+```
+
+## 규칙
+
+- 미해결이 **있어도** 스펙(`.spec.md`)·시나리오(`-scenario.json`)는 산출하고 `flex-scenario validate` 까지 통과시킨다.
+- 미해결이 **없으면** 이 블록을 생략한다.
+- 이 lint 는 `flex-scenario validate` 의 cross-check(스키마/구조 검증)와 별개다 — validate 는 "형식이 맞나", lint 는 "추론이 맞나"를 본다. 둘 다 통과/보고해야 완료.

package/skill/references/spec-evolve/mockup.md

@@ -0,0 +1,50 @@
+# mockup — 목업데이터 추정·세팅 (구조 미제공 포함)
+
+프로토타입 화면은 **항상 목업데이터로 채워야** 한다. 구조가 제공되지 않아도 마찬가지 — 도메인에서 카테고리·필드·현실적 값을 **알아서 추정**해 세팅한다. 빈 리스트·빈 폼·placeholder 만 있는 화면으로 끝내지 않는다.
+
+## ★ M-D 구조가 제공되면 목업 카테고리는 필수 (위반 = 대표 실패)
+
+화면정의서/요청에 **Master/Detail(또는 반복 항목) 구조가 명시**되면, 그 구조의 **목업데이터(Ctg 카테고리 + 시작 Step.Init `intent.mock`)는 반드시 생성**한다. 정적 Label 복제로 끝내면 안 된다.
+
+- Master → `Ctg<Entity>` (1섹터 이상), Detail → `Ctg<Entity>Item` (부모마다 2~3섹터, 조인키 일치).
+- 두 카테고리 모두 `intent.mock` 으로 채우고, 표시 항목은 `LabelCKey`/`Ckeys` 바인딩(정적 텍스트 금지).
+- **실패 사례(S-02)**: Master/Detail 표가 있는 입력 화면을 `DataConnection` 0건·`Events:{}`·정적 Label 57개로 생성 → "데이터연결이 안 된" 화면. M-D 가 명시됐으면 이건 오답이다.
+- 자체 점검: M-D 가 제공됐는데 산출물에 `UseDataConnection:true`/`DataConnection`/`intent.mock` 이 0건이면 다시 만든다.
+
+## 언제 무엇을
+
+| 상황 | 목업 형태 |
+|---|---|
+| 목록/반복/조회 결과 (B) | 시작 Step.Init `intent.mock` 으로 카테고리 섹터 **3건 이상** |
+| 부모-자식(마스터-디테일, B) | 부모 2~3건 × 각 부모에 자식 2~3건 (조인키 일치) |
+| 선택지(Combo/Search, B) | 그 카테고리 옵션 mock (3~6개) |
+| 단건 정적 표시 (A) | 각 Label 에 현실적 `labeltext` 리터럴 |
+| 신규 입력 폼 (new) | mock 면제 — 빈 섹터 자동 생성(`DataUsage:"new"`), Init addSector 금지 |
+
+## 구조 미제공 시 추정 절차
+
+1. **화면 종류·도메인 식별** — "주문 목록", "회원 조회", "재고 현황" 등에서 주체 엔티티를 잡는다.
+2. **카테고리·필드 추정** — 그 엔티티의 자연스러운 필드를 코퍼스/상식으로 구성. 예: 주문 → 주문번호/주문일자/주문상태/합계금액; 회원 → 이름/연락처/이메일/가입유형. 마스터-디테일이면 자식 엔티티도(주문→주문상품: 상품명/수량/단가).
+3. **카테고리명** — `Ctg` 접두 PascalCase (`CtgOrder`, `CtgOrderItem`). 예약어 금지.
+4. **현실적 값 생성** — 아래 "값 현실성".
+5. **개수** — 리스트 최소 3건(부모-자식이면 부모 2~3 × 자식 2~3). 상태/유형은 서로 다르게 섞어 다양성 확보(전부 같은 값 금지).
+6. **가정 기록** — 추정한 카테고리·필드를 `spec-format.md` frontmatter `categories` + `assumptions` 에. keyRole 애매하면 `provisional`.
+
+## 값 현실성
+
+- 한국어 도메인 값: 이름(홍길동/김영희), 거래처(거래처A/대성물산), 상품명(무선마우스/A4용지).
+- 날짜: 현재일 근방의 실제 형식 `YYYY-MM-DD` (예: 2026-06-01). 기간 기본값은 `conventions.md` 패턴.
+- 금액/수량: 천단위 콤마 가능한 현실적 숫자. **합계 = 항목 합** 으로 산술 일치(예: 합계금액 = 자식 금액들의 합).
+- 상태/유형: 그 화면의 enum 중에서(접수/배송중/완료, 합격/불합격 등).
+- 조인키: 부모-자식 `DCParentKey`/`DCChildKey` 값이 실제로 매칭되게(자식의 주문번호 = 부모 주문번호).
+
+## 배치 (B 경로)
+
+- named handler: `Step.Events.Init:"Step1Init"` + `scenario.Events.Step1Init` 안에 `intent.mock`.
+- 인라인 배열(`Step.Events.Init:[...]`) 금지 — schema 충돌 (SKILL.md "데이터 표시 결정" 참조).
+- 부모·자식 카테고리 모두 mock 을 박아 조인이 실제로 그려지게.
+- `intent.mock` 없이 `DataConnection`/`Ckeys` 만 박으면 `[proto]`·`[mock-init]` 차단.
+
+## .spec.md 에 적는 법
+
+frontmatter `categories` 로 카테고리·필드·키를 명시하고, 본문 "데이터 / 목업" 절에 **구체적 mock 값**(현실적 리터럴 N건)을 적는다. 템플릿의 mock 예시(`templates/master-detail.spec.md` 등) 형태를 따른다. Phase 2 가 이 mock 을 `intent.mock`(B) 또는 `labeltext`(A)로 펼친다.

package/skill/references/spec-evolve/query-screens.md

@@ -0,0 +1,66 @@
+# query-screens — 조회 화면: 상단 진입 + 조회조건 별도 Step
+
+조회(조회/검색) 화면은 "조회조건 입력"과 "결과 리스트"가 한 화면에 다 들어가면 복잡해진다. 코퍼스 컨벤션상 **조회조건은 화면 상단에서 진입**하고, **조건이 많으면 조회조건을 별도 Step 으로 분리**한다.
+
+## 핵심 원칙 (사용자 규칙)
+
+1. **상단 진입만.** 조회조건/필터 진입은 **결과 화면의 상단 고정영역(`Step.FixedContentsTop`)** 에 둔다. **하단에 '조회조건' 버튼을 만들지 않는다.**
+2. **부가 네비 버튼 금지.** `바로가기` · `메인메뉴` · `조회조건 펼치기/접기` 같은 **네비/토글 버튼을 만들지 않는다**. 화면 이동은 Step 전환 채널로만(`navigation` 규칙, 아래).
+3. **표준 복귀.** 조회조건 Step → 결과 복귀는 **헤더 `UseBackButton:true`(표준 BackButton)** 또는 `BottomButtons[*].MoveTo:"Prev"` 로. ⚠ `Current.step.moveToPrev(...)` 같은 **스크립트 호출은 금지**(`[script-allow]`/`[back-button]` 차단). 표준 백버튼이 `IsRestored:true` 로 조건값을 유지한다.
+4. **조건은 카테고리로 수집.** 공통 조회조건은 `CtgSearchCond` 같은 **query-condition 카테고리 1섹터**에 모아 바인딩하고, 결과 query 가 그 조건을 참조하는 형태로 둔다(프로토타입에선 mock 1섹터).
+
+## 임계 규칙
+
+- 조회조건(Combo / InputDate / Search / RadioBox / CheckBox 등) **5개 이상** → **별도 Step** 으로 분리.
+- 4개 이하 → 결과 Step 의 **`FixedContentsTop` 고정영역**에 인라인(스크롤되지 않는 상단). 펼치기/접기 토글 버튼으로 만들지 말 것.
+
+## Step 구성 (코퍼스 패턴, AI 생성 안전형)
+
+- **Step1 (결과 리스트)** — 결과가 메인. 상단 `FixedContentsTop` 에 핵심 조건 1~2개(예: 사업단위 Combo) + **필터 진입 컨트롤**(라벨/아이콘에 `UseMove:true` + `MoveSteps.MoveStepOrder:["Step2"]` + `MoveTo:"Next"`). 활성 조건 수는 badge 로 표시 가능. 결과는 별도 스크롤 Group(`ScrollType:"ScrollY"`)에 query 반복.
+- **Step2 (조회조건 폼)** — 나머지 전체 조회조건 컨트롤을 모아 배치. `UseBackButton:true` 표준 헤더로 결과 복귀, 또는 BottomButton "조회" `MoveTo:"Prev"`. 조건값은 BackButton `IsRestored:true` 로 유지.
+- **Step3 (상세, 선택 시)** — 결과 행 클릭(카드 Group `UseMove:true` + `MoveSteps`) → `DataUsage:"detail"` 읽기전용 상세.
+
+> 관찰된 정답 형태: `Step1(결과+상단조건 1~2) → Step2(전체 조회조건 10여 개) → Step3(상세)` 선형. 조회조건이 Step2 에 몰리고, Step1 상단에서 진입한다.
+
+### Step 흐름 — 분기 혼란 금지 (S-07 실패 교정)
+
+- **`Step1.Next` 에는 조회조건 Step(Step2) 만** 둔다. 상세(Step3)는 `Step1.Next` 에 같이 넣지 말고 **결과 카드 Group `UseMove:true` + `MoveSteps.MoveStepOrder:["Step3"]`** 로 간다. 한 Step1 에서 조건·상세를 동시에 `Next` 분기하면 흐름이 모호해진다(S-07).
+- **조회조건은 케이스에 있는 개수만큼만** 만든다 — 같은 조건을 중복 생성하지 말 것(S-07: 13개를 19개로 부풀림). 조건 컨트롤 수 = 스펙 조건 수.
+- Step2 는 조건 폼 한 벌(위 CtgSearchCond 그룹) + 복귀(UseBackButton). Step3 는 detail.
+
+## 조회조건 컨트롤 매핑 (의도 → v1)
+
+- 기간/일자 → `InputDate` (+Dialog `Calendar`, FromTo). 기본값은 `conventions.md` 날짜 패턴.
+- 선택(사업단위/구분/상태) → `Combo` (+Dialog `ComboList`).
+- 코드도움(거래처/품번/Lot No/번호류) → **`Search` (+Dialog `List`) + `CtrlDisplayCkey`(선택값 표시키)**. ⚠ `InputText` 로 떨어뜨리지 말 것 — 키 연결이 끊겨 "조회조건 키 연결 안 됨" 실패가 난다(S-05). 케이스에 `Codehelp` 로 적혔으면 무조건 Search.
+- 다중 선택/플래그 → `CheckBox` / `RadioBox`.
+
+Combo/Search/InputDate 는 Dialog host(`Dialog.Layouts[0].Controls[0]`) 필수. Combo/Search 본체엔 `CtrlDisplayCkey` 또는 `DisplayValue` 가 있어야 선택 후 값이 보인다(`display-key`).
+
+## 조회조건도 데이터연결한다 (CtgSearchCond) — 빠뜨리지 말 것
+
+조회조건 컨트롤을 그냥 화면에만 두지 말고 **데이터연결**한다(S-09 실패: 조건 Step DC 0건).
+
+- 조회조건들을 감싸는 **조건 폼 Group 에 `UseDataConnection:true` + `DataConnection{TargetType:'category', DataUsage:'default', CategoryName:'CtgSearchCond'}`** (단건 1섹터).
+- 각 조건 컨트롤은 그 카테고리 필드에 바인딩: 입력류(InputDate/InputText)는 `Ckeys`, Combo/Search 는 `CtrlDisplayCkey`(+ 자식 SaveKey 매칭, `conventions.md` §1 고정모드 규칙).
+- 시작 Step.Init `intent.mock` 에 `CtgSearchCond` **1섹터**(기본 조건값: 기간 기본값 등)를 박는다 — 없으면 `[proto]`/`[bind]`.
+- 결과 리스트 query 카테고리(예: `CtgInspection`)는 별도 — 조건은 프로토타입에선 표시·전달 용도(실제 필터링 로직은 범위 밖).
+- **키에 `f` 접두 금지**, 스펙에 키가 명시되면 대소문자 그대로(`conventions.md` §1).
+
+## 결과 리스트는 B(query) + 중첩 래핑
+
+결과 리스트는 마스터-디테일이면 `data-connection.md` 의 **부모 query + 자식 query**, 단순 목록이면 query Group 하나. **반복 영역은 스크롤 Group 으로 한두 겹 감싼다**: `스크롤(ScrollY) > 리스트 Group(query) > row Group > 내용`. Init 에 mock 동반(`mockup.md`).
+
+## .spec.md 에 적는 법
+
+```yaml
+screenKind: query
+queryConditions: 12          # 5 이상 → 별도 Step
+queryCondCategory: CtgSearchCond
+steps:
+  - { id: Step1, role: 결과리스트, topConditions: [사업단위], filterEntry: "FixedContentsTop→Step2(UseMove)", next: Step2 }
+  - { id: Step2, role: 조회조건폼, back: "UseBackButton(IsRestored)", conditions: [검사일, 출하검사의뢰일, 납기일, 거래처, 품번, ...] }
+  - { id: Step3, role: 상세(detail), back: UseBackButton }   # 필요 시
+forbidButtons: [바로가기, 메인메뉴, 조회조건펼치기]   # 생성 금지 — 명시 기록
+```
+본문 형태는 `templates/query-screen.spec.md`.

package/skill/references/spec-evolve/routing.md

@@ -0,0 +1,43 @@
+# routing — 구조 제공 여부로 A/B 결정
+
+분기 기준은 "화면정의서냐 아니냐"가 **아니라** "데이터 구조 신호가 있느냐"다. 화면정의서는 구조 신호가 강한 입력의 한 종류일 뿐이고, 일반 요청도 같은 파이프라인을 탄다.
+
+## 구조 신호란
+
+입력에 다음 중 하나라도 명시되어 있으면 "구조 제공"이다:
+- 필드 목록 (항목명 + 컨트롤/타입)
+- 마스터-디테일 구분 (헤더 vs 반복 품목, "~별 목록")
+- 키/조인 (마스터키, 디테일키, "주문번호로 상품 조회" 같은 부모-자식 관계)
+
+## 두 경로
+
+### 구조 제공 → 그대로 따른다 (보조정보는 병합)
+
+- **제공된 데이터 구조 = 1차 진실.** 필드/키/카디널리티를 **임의로 바꾸거나 추가하지 않는다.**
+- 화면정의서의 부가 정보(컨트롤 의도·기본값·버튼 동작·통제 로직)는 **보조로 병합**한다 — 구조를 덮어쓰지 않고 살을 붙이는 용도.
+- 마스터-디테일(1:N)·반복 목록·선택지 데이터가 있으면 **B 경로(데이터연결)** 로 진화한다 → `data-connection.md`. 시나리오에 `DataConnection`+`Ckeys`+`intent.mock`.
+- 단건 정적 표시뿐이면 굳이 데이터연결하지 않고 `Label` 로 (정적, A).
+
+> "엑셀처럼 데이터 형식을 주는 경우" = 이 경로. 준 구조에 맞게 쓰고, 추가적인 건 보조로만.
+
+### 구조 미제공 → 묻지 말고 추론 (지금처럼 생성)
+
+- "재고 조회 화면 만들어줘" 처럼 구조가 없으면 **사용자에게 마스터-디테일·키를 묻지 않는다.**
+- `conventions.md` + `templates/` 의 코퍼스 컨벤션을 근거로 마스터-디테일·키를 **알아서 추론·구성**한다.
+- 반복/선택지 데이터가 자연스러운 화면(목록·조회·주문 등)이면 B, 단순 단건 표시 화면이면 정적 A.
+- 추론한 마스터-디테일·키 구성은 **추론 가정으로 기록**(`spec-format.md` frontmatter `assumptions`)하고 keyRole 이 애매하면 `provisional`.
+- **질문은 화면의 종류/목적이 정말 모호할 때만 최소로** 한다 (예: "재고"가 입출고인지 현황조회인지 한쪽으로도 못 좁힐 때). 키·필드·마스터-디테일 자체는 질문 대상이 아니라 추론 대상이다.
+- **목업데이터를 반드시 추정해 세팅한다 (빈 화면 금지).** 구조가 없어도 도메인에 맞는 카테고리·필드·현실적 값을 **알아서** 만들어 채운다 — 기존 생성과 동일하게. 목록/반복(B)이면 시작 Step.Init 에 `intent.mock` 으로 3건+(부모-자식이면 부모 2~3 × 자식 2~3), 단건 표시(A)면 각 Label 에 현실적 `labeltext` 리터럴. 구체 추정 규칙은 `mockup.md`. 빈 리스트·빈 폼·placeholder 만 있는 화면으로 끝내지 말 것.
+
+## 결정 요약
+
+| 입력 | 경로 | 시나리오 산출 |
+|---|---|---|
+| 구조 제공 + 마스터-디테일/반복/선택지 | **B** | DataConnection + Ckeys + intent.mock |
+| 구조 제공 + 단건 정적 표시 | A | Label.labeltext |
+| 구조 미제공 + 목록/조회성 | **B**(추론) | DataConnection + intent.mock (가정 기록) |
+| 구조 미제공 + 단순 표시성 | A(추론) | Label (가정 기록) |
+
+A/B 는 한 화면 안에서 **혼재**할 수 있다 — 헤더·요약은 정적 Label, 반복 목록·선택지는 B. 노드별로 판정한다(SKILL.md "데이터 표시 결정" 과 동일 기준).
+
+> **공통**: 구조 제공이든 미제공이든, 화면은 항상 목업데이터로 채워 "살아있는" 프로토타입이어야 한다. 미제공이라고 비워두지 않는다 — 추정해서 채우는 게 기본값이다 (`mockup.md`).

package/skill/references/spec-evolve/spec-format.md

@@ -0,0 +1,76 @@
+# spec-format — 중간 스펙 `<name>.spec.md` 형식
+
+Phase 1 산출물의 형식. `---` frontmatter(분석 메타) + 본문(Step별 자연어 명세). 본문은 Phase 2 에서 "요청"으로 그대로 소비된다.
+
+## frontmatter 키
+
+```yaml
+---
+id: <짧은 식별자>              # 예: pda-inspection-request
+domain: <도메인>               # 예: 품질/물류
+feature: <한 줄 기능>           # 예: 출하검사의뢰 입력 — 스캔으로 품목 적재
+screenKind: input | query | mixed
+route: A | B | mixed           # routing.md 결정 (정적 / 데이터연결 / 혼재)
+events: [저장, 삭제, 신규, 조회]  # 있으면
+steps:                         # Step 분해 — 권장 3~5 · 최대 7 (아래 "Step 수 규칙")
+  - { id: Step1, role: ..., next: Step2 }
+keyRoles:                      # key-roles.md — 필드 → master/detail/link/none
+  <필드>: <role>
+categories:                    # route 에 B 가 포함될 때 — data-connection.md
+  Ctg<Name>: { role: master|detail, keys: [...], parentKey: ..., childKey: ..., fields: [...] }
+assumptions:                   # 구조 미제공 시 추론한 가정 (사람 검토용)
+  - <가정 문장>
+provisional:                   # 비블로킹 미해결 (key-roles.md / lint.md)
+  - { field: ..., guess: ..., why: ... }
+expect:                        # Phase 2 가 만족해야 할 체크리스트 (검증·자기점검용)
+  - <기대 조건>
+---
+```
+
+`expect` 는 bench 케이스(T-/D-)의 그것과 같은 역할 — 생성 결과가 맞는지 스스로 점검하는 목록. 예: "Step1→2→3 reachability 1회", "디테일은 DataUsage:query (UseInnerBlock 금지)", "Init mock 부모2+자식", "Collections:{} 유지", "조회조건 12개 → Step2 분리".
+
+## 본문 (Step별 명세)
+
+각 Step 을 헤더로 나누고, 그 안에 영역(마스터/디테일/조회조건/요약)과 항목을 적는다. 항목은 `이름 — 의도(컨트롤) [기본값/바인딩]` 형태. 데이터연결·목업·네비게이션 규칙을 문장으로 명시.
+
+**"데이터 / 목업" 절은 필수**다 — 구조 제공이든 미제공이든 화면을 채울 **구체적 mock 값**(현실적 리터럴 N건, 부모-자식이면 조인 일치)을 적는다. 미제공이면 `mockup.md` 절차로 카테고리·필드·값을 추정해 적고 frontmatter `categories`/`assumptions` 에 기록. 빈 화면으로 끝내지 않는다.
+
+본문 작성 시 참고 템플릿:
+- 마스터-디테일(B, 부모-자식) → `templates/master-detail.spec.md`
+- 조회 화면(조건 분리) → `templates/query-screen.spec.md`
+- 정적 프로토타입(A, 구조 미제공/단건) → `templates/static-prototype.spec.md`
+
+## Step 수 규칙 (스펙기반 생성)
+
+스펙으로 진화한 화면은 **3~5 Step 권장 · 최대 7 Step** 으로 구성한다. 한 Step 에 모든 걸 욱여넣지도, 과하게 잘게 쪼개지도 말 것 — 흐름을 자연스러운 단계로 분해하되 **7개를 넘기지 않는다**(넘으면 서브 흐름을 합치거나 Step 안 영역으로 묶는다). 정말 단순한 단건 화면이면 2 Step 이하도 가능하나, 그 근거를 `assumptions` 에 적는다.
+
+- **목록/조회**: 결과 리스트 + (조회조건 폼 분리) + 상세(detail) → 자연히 2~3 Step. 조회조건 ≥5 면 조건 폼을 별도 Step (`query-screens.md`).
+- **입력**: 기본정보 → 상세/항목 → 확인/완료 처럼 입력 흐름을 단계화 → 3 Step.
+- **단건 표시(A)**: 표시 + 결과/확인 등으로 2~3 Step. 정말 1화면이면 적게 둘 수 있으나 근거를 `assumptions` 에 적는다.
+- StartSteps + 각 Step.Next 합집합으로 reachability 가 정확히 1회 되도록(끊기거나 중복 금지). 헤더 BackButton 표준 적용.
+
+## Step 전환 / 네비 (스펙 본문에 반드시 기술)
+
+각 Step 에 대해 **어떻게 들어오고 나가는지**를 스펙 본문에 명시한다(샘플 수준으로 구체적으로). 모호하게 두면 흐름이 끊긴 생성물(예: 조회조건 Step 에서 결과로 못 돌아옴)이 나온다.
+
+- **StartSteps**: 보통 `["Step1"]`. 다중 진입이 필요하면 나열.
+- **전진**: `BottomButtons[*].MoveTo:"Next"` + `Next.MoveStepOrder:["StepN"]`, 또는 리스트 카드 `UseMove:true` + `MoveSteps.MoveStepOrder`.
+- **복귀**: 헤더 `UseBackButton:true`(표준 BackButton, `IsRestored:true` 로 값 유지) 또는 `BottomButtons[*].MoveTo:"Prev"`. ⚠ `Current.step.moveToPrev/moveToNext` 스크립트 **금지**.
+- **조회조건 진입**: 결과 Step `FixedContentsTop` 에서 진입(상단). 하단 '조회조건' 버튼·`바로가기`·`메인메뉴`·`펼치기/접기` 라벨 버튼 **생성 금지**.
+- 각 Step 줄에 `next:`/`back:`/`filterEntry:` 를 적어 reachability 가 정확히 1회 되게 한다.
+
+## expect 에 넣을 자체 점검 항목 (해당 시)
+
+- M-D 제공 → `intent.mock`(부모+자식 카테고리) 동반, `UseDataConnection:true`/`DataConnection` ≥1 (0이면 실패).
+- 반복 영역은 `DataUsage:"query"` + 스크롤 그룹으로 한두 겹 래핑(중첩 깊이 ≥5 목표), 정적 Label 복제 아님.
+- 조회조건은 상단(`FixedContentsTop`)/별도 Step, 하단 진입 버튼 없음, 부가 네비 버튼(바로가기/메인메뉴/펼치기) **0개**.
+- 마스터 표시 라벨 바인딩(가능 시) + 종속 선택 mock.
+- Step reachability 정확히 1회, 복귀 채널은 표준(스크립트 흐름제어 0).
+- Collections:{} 유지, validate 통과.
+
+## 작성 원칙
+
+- **구조 제공 시**: 준 필드/키/카디널리티를 그대로 옮기고 임의 추가 금지. 부가정보는 보조 병합.
+- **구조 미제공 시**: 추론한 마스터-디테일·키를 채우되 `assumptions` 에 근거를 남긴다.
+- provisional 은 멈춤 사유가 아니다 — 기록하고 진행.
+- 본문은 Phase 2 가 읽고 노드를 만들 수 있을 만큼 구체적이되, **시나리오 JSON 을 여기 쓰지 않는다**(그건 Phase 2). 스펙은 "무엇을"이고 Phase 2 가 "어떻게".

package/skill/references/spec-evolve/templates/master-detail.spec.md

@@ -0,0 +1,97 @@
+---
+id: order-with-items
+domain: 주문관리
+feature: 주문 + 주문상품(부모-자식 DC) + 상세 보기
+screenKind: mixed
+route: B
+events: [조회, 상세]
+steps:
+  - { id: Step1, role: 주문목록(부모query+자식query), next: Step2 }
+  - { id: Step2, role: 주문상세(detail, 읽기전용), back: Step1 }
+keyRoles:
+  주문번호: master
+  주문일자: none
+  주문상태: none
+  합계금액: none
+  상품_주문번호: link
+  상품명: none
+  수량: none
+  단가: none
+  금액: none
+categories:
+  CtgOrder:
+    role: master
+    keys: [주문번호]
+    fields: [주문일자, 주문상태, 합계금액]
+  CtgOrderItem:
+    role: detail
+    parentKey: 주문번호
+    childKey: 주문번호
+    fields: [상품명, 수량, 단가, 금액]
+assumptions:
+  - 주문 1건이 여러 주문상품을 가진다(1:N)고 추론
+  - 합계금액 = 그 주문 상품들의 금액 합 (mock 에서 산술 일치시킴)
+provisional: []
+expect:
+  - 부모 주문 Group DataUsage:"query" — CtgOrder 섹터 수만큼 카드 반복
+  - 자식 주문상품 Group 이 부모 카드 안에서 DataUsage:"query" + TargetSector.Filters:[{FilterType:"Parent"}]
+  - Parent 필터에 DCParentKey(주문번호)/DCChildKey(주문번호) 지정
+  - 부모/자식 모든 표시 항목이 LabelCKey/Ckeys 로 바인딩(정적 labeltext 금지)
+  - 제목·총주문건수 요약·"신규" 버튼은 query 그룹 바깥 비연결 래퍼(UseDataConnection:false)
+  - query 그룹 Height.MatchText:true + ScrollType:"ScrollY"
+  - 상세 Step2 는 DataUsage:"detail" (UseTargetSector:true + Status:["active"], 읽기전용)
+  - Step2 헤더 BackButton 표준(Step.UseBackButton:true, BackButton.Next:"None"), {=Field} 토큰 금지 — 값은 script 전달
+  - 시작 Step Init(named handler)가 intent.mock 으로 CtgOrder 3건 + 각 주문에 CtgOrderItem 2~3건
+  - 합계금액 mock 이 그 주문 상품 금액 합과 일치
+  - CategoryName 'Ctg' 접두 PascalCase, 예약어 미사용
+  - StartSteps + Step.Next 로 Step1↔Step2 reachability 정확히 1회, Collections:{} 유지, validate 통과
+---
+주문과 그 주문의 상품들을 함께 보여주는 화면. **부모-자식 데이터연결(1:N)** 구조다.
+
+# Step 1 — 주문 목록 (부모 query + 자식 query)
+
+## 상단 (비연결 래퍼 — 1번만 표시, query 그룹 바깥)
+- 제목 "주문 목록" — Label(labeltext). 굵게/큰 글씨(design: font 슬롯).
+- 총 주문건수 요약 "총 N건" — Label. 회색 보조 텍스트.
+- "신규 주문" 버튼 — Button. 우측 정렬. (동작은 프로토타입 범위 밖이어도 배치)
+
+## 주문 카드 (부모 query, CtgOrder — 스크롤 래핑)
+- **중첩 래핑**: `스크롤 Group(ScrollType:"ScrollY", UseDataConnection:false) > 리스트 Group(UseDataConnection:true, DataConnection{TargetType:"category", DataUsage:"query", CategoryName:"CtgOrder"}) > row Group(카드)`. 데이터연결은 반복하는 리스트 Group 에만, 바깥 스크롤은 false.
+- 카드 스타일: 라운드 + 옅은 테두리 + 카드 사이 간격(design: radius/border/m 슬롯).
+- 표시 항목(모두 섹터 필드 바인딩):
+  - 주문번호 — Label(LabelCKey: 주문번호). 카드 헤더, 굵게.
+  - 주문일자 — Label(LabelCKey: 주문일자). 보조 텍스트.
+  - 주문상태 — Label(LabelCKey: 주문상태). 상태 배지 느낌(접수/배송중/완료).
+  - 합계금액 — Label(LabelCKey: 합계금액). 우측, 강조.
+
+### 주문상품 목록 (자식 query — 카드 안)
+- 부모 카드 Group **안쪽**에 자식 Group UseDataConnection:true, DataUsage:"query", CategoryName:"CtgOrderItem".
+- TargetSector.Filters:[{FilterType:"Parent"}], DCParentKey:"주문번호" / DCChildKey:"주문번호" 로 조인.
+- 행 항목(반복, 섹터 필드 바인딩):
+  - 상품명 — Label(LabelCKey: 상품명).
+  - 수량 — Label(LabelCKey: 수량). "x N" 형태.
+  - 단가 / 금액 — Label(Ckeys). 우측 정렬.
+- 카드의 "상세" 버튼 → Step 2 (선택 주문이 activeSector 가 됨).
+
+# Step 2 — 주문 상세 (detail, 읽기전용)
+- 헤더 BackButton(Step.UseBackButton:true) — Step 1 로 회귀.
+- 선택한 주문(activeSector)을 DataUsage:"detail"(UseTargetSector:true + Status:["active"])로 읽기전용 표시.
+- 주문번호 / 주문일자 / 주문상태 / 합계금액 + 상품 목록(상품명·수량·단가·금액). 입력 불가, 표시만.
+- 값은 {=Field} 토큰이 아니라 onShow/Next script 로 전달(template-script 규칙).
+
+# 데이터 / 목업 (시작 Step Init, named handler)
+- `Step.Events.Init:"Step1Init"` + `scenario.Events.Step1Init` 안에 intent.mock.
+- CtgOrder 3건 (현실적 값):
+  - ORD-2026-001 / 2026-06-01 / 배송중 / 합계 128,000
+  - ORD-2026-002 / 2026-06-03 / 접수 / 합계 54,000
+  - ORD-2026-003 / 2026-06-04 / 완료 / 합계 210,000
+- CtgOrderItem (각 주문 주문번호로 연결, 금액 합 = 부모 합계금액):
+  - ORD-2026-001: 무선마우스 x2 @24,000=48,000 / USB허브 x1 @80,000=80,000
+  - ORD-2026-002: A4용지 x3 @18,000=54,000
+  - ORD-2026-003: 기계식키보드 x1 @150,000=150,000 / 마우스패드 x2 @30,000=60,000
+
+# 규칙
+- Collections:{} 유지 · UseInnerBlock 금지(반복은 모두 DataUsage:"query")
+- 1번만 보일 요소는 query 그룹 바깥, 비연결 그룹도 UseDataConnection:false 명시
+- 정적 텍스트로 카드 내용을 박지 말 것(모든 카드가 같은 문구가 되면 안 됨)
+- validate 통과 필수