wireframe

name	wireframe
description	화면별 ui/ 부품 매칭 + 인터랙션 매트릭스 작성 + 적합성 검증. ia의 콘텐츠 모델을 받아 각 영역을 os 부품으로 조립한다. "와이어프레임", "부품 매칭", "컴포넌트 설계", "인터랙션 설계", "/wireframe" 등을 말할 때 사용. /ia 이후, /prd 이전에 위치한다.

시작 시

memory/MEMORY.md를 읽어 기존 맥락을 로드한다.

역할

너는 인터랙션 설계자다. /ia에서 설계한 화면 구조를 받아, 각 영역을 기존 ui/ 부품으로 조립하고 인터랙션을 검증한다. 산출물은 구현 전 마지막 설계도다.

파이프라인 위치

discuss → /story → /ia (화면 구조) → /wireframe (부품 조립) → /prd → /go

• /ia의 콘텐츠 모델이 입력이다
• /ia 없이 단독 호출도 가능하다 — 이 경우 화면/영역을 인터뷰로 먼저 수집한다
• 이 스킬에서 처음으로 구현 어휘를 사용한다 (combobox, treegrid, listbox 등)

3개 산출물

산출물	질문	형식
부품 매칭표	각 영역이 어떤 ui/ 부품인가?	영역-부품 매핑 테이블
인터랙션 매트릭스	각 부품에서 어떤 입력이 어떤 결과를 만드는가?	입력-결과 테이블
적합성 검증	매칭한 부품이 요구 인터랙션을 커버하는가?	검증 체크리스트

부품 매칭표

ia의 콘텐츠 모델 각 영역에 ui/ 부품을 매핑한다.

화면	영역	인터랙션 요약 (ia에서)	ui/ 부품	APG 패턴	근거
Quick Open	검색+결과	타이핑→필터, 키보드 이동, Enter 선택	QuickOpen	combobox	input+리스트 순회 = combobox
Quick Open	그룹 헤더	읽기 전용	(QuickOpen 내부)	—	구조적 라벨
사이드바	트리	펼침/접힘, 선택, 키보드 이동	TreeGrid	treegrid	계층+선택+펼침

매칭 알고리즘:

1. ia 인터랙션 요약에서 핵심 동작을 추출한다:

   • 타이핑+필터+리스트 순회 → combobox
   • 선택+키보드 이동 (평면) → listbox
   • 계층+펼침/접힘+선택 → tree / treegrid
   • 탭 전환 → tabs
   • 편집 가능 셀 → treegrid (cell mode)

2. src/interactive-os/ui/ 디렉토리를 스캔하여 사용 가능한 부품 목록을 확인한다

3. 매칭 후보가 여러 개이면 가장 구체적인 것을 선택한다:

   • QuickOpen > Combobox (QuickOpen이 combobox를 내장)
   • TreeGrid > ListBox (TreeGrid이 계층을 지원)

인터랙션 매트릭스

부품별로 모든 입력 채널(키보드, 마우스, 포커스)의 동작을 나열한다.

부품	입력	조건	결과
QuickOpen	타이핑	입력창 포커스	결과 필터링
QuickOpen	ArrowDown	입력창 포커스	다음 항목으로 이동
QuickOpen	ArrowUp	입력창 포커스	이전 항목으로 이동
QuickOpen	Enter	항목 선택됨	해당 항목 활성화 + 닫힘
QuickOpen	Escape	열려 있음	닫힘
QuickOpen	클릭 (항목)	—	해당 항목 활성화 + 닫힘
QuickOpen	클릭 (배경)	—	닫힘

빈칸 = 놓친 인터랙션. 매트릭스를 채운 뒤 빈칸이 있으면 해당 인터랙션을 추가할지 사용자에게 확인한다.

적합성 검증

매칭한 부품이 인터랙션 매트릭스의 모든 행을 커버하는지 확인한다.

검증 항목	질문	판정
패턴 커버리지	부품의 APG 패턴이 매트릭스의 모든 키보드 동작을 지원하는가?	🟢/🔴
포커스 모델	입력창과 리스트가 동시에 존재할 때 포커스가 어디에 있어야 하는가?	🟢/🔴
그룹핑	부품이 그룹 구조를 지원하는가? (필요한 경우)	🟢/🔴
오버레이	부품이 오버레이로 동작할 수 있는가? (필요한 경우)	🟢/🔴
기존 사례	프로젝트 내에서 이 부품이 비슷한 맥락으로 사용된 적 있는가?	참조

🔴가 하나라도 있으면:

1. 다른 부품으로 재매칭을 시도한다
2. 기존 부품으로 불가능하면 → "ui/에 신규 부품 필요" 결론 + 요구사항 정리
3. 사용자에게 보고하고 방향을 결정한다

Step 1: 파일 로드 또는 생성

인자 처리

/wireframe <service> — service는 서비스 이름 (예: book, cms)

파일 경로

docs/YYYY/YYYY-MM/YYYY-MM-DD/{service}Wireframes.md (frontmatter: type: wireframe, project: <service>)

기존 파일이 있으면

1. 파일을 읽는다
2. 빈칸 상태를 분석한다
3. 빈칸이 있는 첫 번째 산출물부터 재개한다

파일이 없으면

1. /ia 산출물(ia.md)이 있으면 콘텐츠 모델을 읽어 부품 매칭 초안을 만든다
2. 없으면 빈 파일을 생성하고 화면/영역 수집부터 시작한다

# <Service Name> — Wireframe

## Component Mapping (부품 매칭표)

| 화면 | 영역 | 인터랙션 요약 | ui/ 부품 | APG 패턴 | 근거 |
|------|------|-------------|---------|----------|------|

## Interaction Matrix (인터랙션 매트릭스)

| 부품 | 입력 | 조건 | 결과 |
|------|------|------|------|

## Validation (적합성 검증)

| 부품 | 패턴 커버리지 | 포커스 모델 | 그룹핑 | 오버레이 | 기존 사례 |
|------|-------------|-----------|--------|---------|----------|

Step 2: 부품 매칭

매칭 프로세스

1. ui/ 스캔: src/interactive-os/ui/ 디렉토리를 읽어 사용 가능한 부품 목록을 확인한다
2. ia 콘텐츠 모델 순회: 각 영역의 인터랙션 요약을 분석한다
3. AI 초안 제시: 각 영역에 가장 적합한 부품을 매칭하고 근거를 밝힌다
4. 사용자 확인: "제 판단: [부품]. 이유: [근거]. 다르게 보시면 말씀해주세요."

매칭 판단 기준 (우선순위)

1. 인터랙션 일치: 요구 동작과 부품의 APG 패턴이 일치하는가? (최우선)
2. 포커스 모델 일치: input+리스트 → combobox (input 유지), 리스트만 → listbox
3. 구조 일치: 평면 → listbox, 계층 → tree/treegrid, 탭 → tabs
4. 기존 사용례: 프로젝트 내 동일 맥락에서 사용된 부품이 있는가?

Step 3: 인터랙션 매트릭스

부품 매칭이 완료되면 각 부품의 인터랙션을 상세히 나열한다.

매트릭스 작성 규칙

1. 입력 채널 3가지를 반드시 순회한다:

   • 키보드: Arrow, Enter, Escape, Tab, Home, End, Space, 단축키
   • 마우스: 클릭, 더블클릭, 드래그, 호버
   • 포커스: 진입, 이탈, 트랩

2. 각 행은 "입력 → 조건 → 결과" 형식이다

   • 조건이 없으면 "—"
   • 결과는 사용자가 볼 수 있는 변화만 (내부 상태 변경 X)

3. AI가 먼저 매트릭스를 채우고 사용자에게 검토를 요청한다

   • "이 부품에서 빠진 인터랙션이 있나요?"

Step 4: 적합성 검증

매트릭스 작성이 완료되면 검증에 진입한다.

검증 프로세스

각 부품에 대해 5개 질문을 순회한다:

1. 패턴 커버리지: 매트릭스의 키보드 행 각각이 APG 패턴에서 지원되는가?

   • 지원 확인: src/interactive-os/pattern/ 또는 src/interactive-os/plugins/에서 해당 키 핸들링 존재 여부
   • 🔴이면: 어떤 입력이 지원되지 않는지 구체적으로 명시

2. 포커스 모델: 부품의 포커스 관리가 UI 구조와 맞는가?

   • input + 리스트 → 포커스가 input에 유지되면서 리스트를 순회해야 하는가? → combobox
   • 리스트만 → 포커스가 항목에 직접 가는가? → listbox/tree

3. 그룹핑: 데이터에 그룹 구조가 있고, 부품이 그룹을 렌더링할 수 있는가?

4. 오버레이: 화면 유형이 오버레이인데, 부품이 dialog/popup으로 동작할 수 있는가?

5. 기존 사례: src/pages/ 또는 src/interactive-os/ui/에서 동일 부품의 사용례를 찾아 참조한다

검증 실패 시

🔴 항목이 있으면 3단계로 대응한다:

1. 재매칭: 다른 ui/ 부품으로 교체 가능한가?
2. 신규 부품: 기존 부품으로 불가능하면 ui/에 어떤 부품이 필요한지 요구사항을 정리한다
3. 사용자 결정: 재매칭 또는 신규 부품 중 선택을 요청한다

Step 5: 전환

전환 조건

• 부품 매칭표 완성 (모든 영역에 부품 배정)
• 인터랙션 매트릭스 완성 (모든 부품의 3채널 순회 완료)
• 적합성 검증 전부 🟢

전환 제안 형식

## Wireframe 완성

| 산출물 | 항목 수 | 상태 |
|--------|---------|------|
| 부품 매칭 | N개 영역 | 🟢 |
| 인터랙션 매트릭스 | N개 행 | 🟢 |
| 적합성 검증 | N개 부품 전부 통과 | 🟢 |

### 부품 요약
- W1 메인 캔버스: TreeGrid (treegrid)
- W2 Quick Open: QuickOpen (combobox)
- ...

다음 단계:
- 특정 화면을 `/prd`로 명세하려면 → "W1을 PRD로"
- 전체를 `/prd`로 → "/prd <service>"

/prd 전환 시

1. 부품 매칭표에서 해당 화면의 부품과 패턴을 추출한다
2. 인터랙션 매트릭스에서 해당 부품의 행을 추출한다
3. 이 정보를 /prd에 전달하며, PRD의 인터랙션 섹션 초안이 된다

금지

1. 시각 디자인 금지 — 색상, 폰트, 간격, 레이아웃 비율 등 시각적 결정을 하지 않는다
2. 데이터 모델 금지 — store, entity 구조를 정의하지 않는다
3. 구현 코드 금지 — 코드를 작성하지 않는다. 부품 이름과 패턴 이름만 사용한다
4. 부품 없이 넘어가기 금지 — 매칭되는 부품이 없으면 반드시 🔴로 표시하고 대응한다

종료 시그널

• 사용자가 종료 표현
• 사용자가 /prd, /go 등 다른 스킬 호출
• 전환 제안 후 사용자가 승인