/cc-blueprint:sync — 디자인과 구현이 어긋나지 않게#

한마디로#

Figma 에 있는 화면 목록과 코드(위젯북)에 있는 화면 목록을 기계로 맞대 보고, "디자인에만 있는 화면 / 코드에만 있는 화면 / 짝은 맞는데 어긋난 화면"을 세 갈래로 세어 주는 명령입니다. 사람이 기억으로 짝을 맞추는 것은 화면이 수십 개일 때까지만 통합니다 — 이 명령이 그 대조를 상시화합니다.

누가·언제 쓰나요#

• 디자이너가 시안을 고친 뒤 어느 화면을 다시 구현해야 하는지 목록이 필요할 때
• PR 올리기 전 디자인↔구현 정렬 게이트를 돌리고 싶을 때 (L0 은 PR 차단감)
• 기획·디자인 피드백(코멘트)을 추적 가능한 작업 이슈로 바꾸고 싶을 때

무엇을 해주나요#

• 양쪽 목록을 모아 집합 대조합니다 — 결합은 이름이 아니라 node ID·designLink 기준이라 이름을 바꿔도 안 끊깁니다
• 판정을 L0(차단)/L1(경고)/L2(위생) 로 나눠, 무엇이 막고 무엇이 밀려도 되는지 구분합니다
• 디자인 변경을 감지해 재작업 목록을 만들고, 항목마다 ZenHub 이슈로 만들 제안을 붙입니다
• 피드백 코멘트를 수집해 해당 화면의 재작업 항목에 매답니다

어떻게 쓰나요#

# 전체 대조 (레지스트리 기준)
/cc-blueprint:sync --app {앱 워크스페이스 경로}

# 특정 Surface 만
/cc-blueprint:sync --app apps/unibook --surface App

# 대조 + 재작업 이슈 일괄 생성 제안까지
/cc-blueprint:sync --app apps/unibook --propose-issues

안에서 무슨 일이 벌어지나요#

1. 목록 수집 — 레지스트리(리포 원본)와 Figma 페이지·섹션, 코드의 use_case 목록을 모읍니다.
2. 집합 대조 — 3단 대응으로 짝을 맞추고 L0/L1/L2 판정을 냅니다.
3. 변경 감지 — 프레임 버전을 비교해 "짝은 있는데 어긋난" 화면을 찾습니다.
4. 재작업 목록 — 3분류 표 + 항목별 다음 행동(design/build/이슈화)을 제안합니다.

/cc-blueprint:sync --app {path} [--surface {surface}] [--propose-issues] [--level {L0|L1|L2}]

1. 레지스트리(리포 원본) — 화면 레지스트리 파일의 행 전수
2. Figma — 레지스트리가 가리키는 파일의 Project/Page/Section 트리 + 프레임 node ID·version
   (figma:figma-design-to-code 로드 → get_design_context. 읽기 전용)
3. 코드 — --app 에서 @UseCase 어노테이션 전수 스캔: name · path · designLink

디자인만 있음  — Figma 섹션 O · use_case X  → /cc-blueprint:build 대상
코드만 있음    — use_case O · Figma 섹션 X  → /cc-blueprint:design 소급 대상(또는 폐기 판단)
어긋남         — 짝 O · 프레임 version 이 레지스트리 기록보다 새로움 → 재구현/재확인 대상

## 🔁 sync 결과 — {대상}
| 분류 | 화면 | 근거 | 다음 행동 |
|------|------|------|-----------|
| 디자인만 | 구매 완료 | 섹션 O · use_case X | /cc-blueprint:build --frames  " 구매 완료 "   |
| 어긋남 | 도서 목록 | frame v18  >   기록 v15 | 재확인 → 필요 시 build 재실행 |
**판정: L0 {n} · L1 {n} · L2 {n}** · 어긋남 {n} · 미구현 {n} · 미설계 {n}