• Backend 없음: 모든 API는 Mock interceptor 경유 (useApi() 호출 유지)
• 생성 방식: test-data 가이드 코드를 기준 골격으로 참조 후 Mock 특화 적응
• 컴포넌트 사용: 케밥케이스 사용 (예:

  <u-button>

  ,

  <u-modal>

  ,

  <my-component>

  )
• 완료 기준: vue-tsc + lint + build 모두 통과
• 프로덕션 전환 대비: API 시그니처 유지, Mock 교체만으로 실서버 연동 가능
• 저장소 분리 (2026-04-27 결정): 본 프로젝트가 아닌 별도 ui-proto 저장소의

  src/modules-task/{년월}/{태스크폴더}/

  에 누적
• Spec 원천 자료: Vue 화면 + Mock 데이터 + overview 설명 페이지가 후속

  peach-gen-spec

  의 입력이 됨
• 1차 완성도 지원: 화면 목록, 주요 액션, 완료/오류 상태를 남겨

  peach-gen-spec

  이 확정 Spec을 만들 수 있게 함
• 기획 구체화 우선: Spec 없이 기획자가 직접 구체화하는 경우에는 단독/대화형 흐름을 우선하고, AI 팀이 임의로 요구를 증폭하지 않는다

1. 사용자의 화면/흐름 요구가 모두 반영되었는가
2. NuxtUI v4 컴포넌트 사용 규칙 준수 여부
3. 본 프로젝트(

   peach-{도메인}

   )의 컴포넌트 패턴과 일치 여부
4. AI Slop 패턴(그라데이션, 보라색 등) 회피 여부
5. modules-task 폴더 구조 규칙 준수 (

   _task-meta.ts

   ,

   _routes.ts

   , layout 분리 등)
6. 라우트 통합 규칙 준수 (

   _task.routes.ts

   의 taskDetailRoutes에 추가)
7. DESIGN.md가 있을 경우 디자인 시스템 규칙(색상, 컴포넌트 네이밍, 타이포그래피) 준수 여부
8. 화면 목록과 주요 기능이 overview에서 설명되어 있는가
9. 주요 액션(검색/저장/승인/반려/업로드/다운로드 등)의 완료 상태와 오류 상태가 화면에 표현되어 있는가
10. 후속

    peach-gen-spec

    이 E2E 시나리오 후보를 정리할 수 있도록 화면 전환 흐름의 단서가 충분한가
11. 후속

    peach-gen-spec

    이 개발용 Spec을 만들 수 있도록 화면/Store/API 기대가 충분히 드러나는가

• 요구사항 본문과 사용자 입력에서

  planner

  ,

  date

  ,

  title

  후보를 추출
• 태스크 폴더명:

  {YYMMDD}-{planner}-{영문슬러그}

  형식 (한글 금지)
• 확정된 메타로

  _task-meta.ts

  를 생성한다. 이후

  peach-gen-spec proto=<경로>

  는 이 메타와 화면 파일을 읽어 개발용 Spec을 생성한다
• 사용자에게 자동 추출 결과 보여주고 확정 받기

• AI가 1~3개 후보 제안 → 사용자 선택

• Backend 없이 Mock interceptor로

  useApi()

  호출을 처리한다.
• Mock 데이터는

  mock/

  에 분리하고, 실제 API 전환 시 시그니처를 유지한다.
• 시각 품질과 AI Slop 방지 상세는

  peach-gen-ui/references/core/visual-guide.md

  를 따른다. 공유 UI 패턴은

  peach-gen-ui

  가 SoT다.

경고: 아래 패턴은 모든 UI 패턴에서 반드시 적용해야 합니다. 누락 시 검색, 페이징, URL 상태관리가 동작하지 않습니다.

<form @submit.prevent="listAction">

@change="listAction"

@update:modelValue="listAction"

@update:page="listMovePage"

listAction()

resetAction()

listMovePage()

상세 코드와 금지 패턴:

peach-gen-ui/references/core/common-patterns.md

참조 (필수, 공유 SoT)

cat DESIGN.md 2>/dev/null | head -200

• 있으면: 컴포넌트 규칙·색상·타이포그래피를 컨텍스트에 주입하여 이후 단계에 반영
• 없으면: 아래 경고 출력 후 계속 진행

⚠️ DESIGN.md 없음 — 디자인 시스템 문서가 없습니다. 작성을 권장합니다.
   참고: peach-harness/templates/DESIGN-template.md (또는 /peach-gen-design)

이 단계는 생략 불가! 기획자에게 반드시 UI 패턴을 질문하고 선택을 받은 후 진행합니다. 선택 없이 코드 생성을 시작하면 안 됩니다.

undefined

대상 프로젝트에

_common/components/

디렉토리가 존재하면 NuxtUI 직접 사용 대신 래퍼 컴포넌트를 우선 사용합니다.

<UInput>

<p-input-box>

<USelect>

<p-nuxt-select>

<UFormField>

<p-form-field>

<UFileInput>

<p-file-upload>

• _common/components/

  없으면 → NuxtUI 직접 사용 (기존 방식 유지)

1. UI 복잡도 판단: 필드 수, 검색 조건, 테이블 컬럼 구성
2. Mock 데이터 설계: 도메인에 맞는 현실적인 샘플 데이터 구상
3. 적응 결정:
   • Must Follow → 그대로 (script setup, 필수 패턴, AI Slop 금지)
   • May Adapt → 도메인 맞춤 (테이블 컬럼, 검색 폼, 모달 폼 구성)
4. 구조 제안 (May Suggest): 분석 결과 가이드코드와 다른 구조가 더 적합하면 사용자에게 제안:
   • 컴포넌트 분리 (예: 복잡한 폼을 step별 컴포넌트로)
   • 페이지 구성 변경 (예: 탭 내 리스트, 상세 페이지 분리)
   • 사용자 확인 후 적용. Must Follow 침범 금지.

test-data/pages/crud/

${SHARED_UI_REFS}/basic/page-pattern.md

${SHARED_UI_REFS}/basic/modal-pattern.md

test-data/pages/crud/

detail-page.vue

${SHARED_UI_REFS}/basic/page-pattern.md

test-data/pages/two-depth/

${SHARED_UI_REFS}/basic/two-depth-pattern.md

test-data/pages/infinite-scroll-list/

${SHARED_UI_REFS}/basic/infinite-scroll-pattern.md

test-data/pages/select-list/

${SHARED_UI_REFS}/basic/select-list-pattern.md

test-data/modals/list-table-progress.modal.vue

${SHARED_UI_REFS}/basic/batch-process-pattern.md

${SHARED_UI_REFS}/core/common-patterns.md

• Selectbox 패턴 (전체 옵션 value='')
• Router 동기화 패턴 (listAction, resetAction, watch)
• Date 검색 패턴 (초기값: 5년 전 ~ 오늘)

• <script setup>

  필수
• NuxtUI 컴포넌트 우선, AI Slop 금지
• 필수 패턴:

  listAction

  ,

  resetAction

  ,

  listMovePage

  , watch 패턴

• @submit.prevent="listAction"

  ,

  @change="listAction"

  패턴
• 모듈 경계:

  _common

  만 import
• Mock 데이터는

  mock/

  디렉토리에 분리
• useApi() 경유 패턴 유지 (프로덕션 전환 대비)

• 테이블 컬럼 구성 (도메인 필드에 맞춤)
• 검색 폼 구성 (필드 수에 따른 레이아웃)
• 모달/페이지 폼 구성 (입력 필드 그룹핑)
• Mock 데이터 구성 (도메인 특수 샘플)
• UI 상호작용 흐름 (도메인 특수 UX)

• 컴포넌트 분리 (예: 복잡한 폼을 step별 컴포넌트로)
• 페이지 구성 변경 (예: 탭 내 리스트, 상세 페이지 분리)
• UI 패턴 변경 제안 (예: crud → page가 더 적합)

• UI 패턴 선택 완료
• Mock 데이터, Store, 페이지/모달 컴포넌트 생성 완료

• vue-tsc

  ,

  lint

  ,

  build

  통과
• 팀 모드는

  proto-ui-qa

  APPROVED 또는 사용자 승인된 CONDITIONAL 필요

중요: 선택된 패턴의 참조 파일만 읽으세요! 모든 references를 한 번에 로드하지 마세요.

경고: 아래 파일은 어떤 패턴을 선택하든 반드시 먼저 읽어야 합니다! 이 파일을 읽지 않으면 검색, 페이징, URL 상태관리 패턴이 누락됩니다.

• ${SHARED_UI_REFS}/core/common-patterns.md

  - URL Watch 패턴, Selectbox, Router 동기화, Date 검색, 모달 오픈 패턴

• ${PROTO_REFS}/core/mock-service-pattern.md

  - Mock 데이터 정의, 동적 생성, API 시그니처 유지

• ${PROTO_REFS}/core/mock-store-pattern.md

  - Mock useApi() 경유 Store 패턴

• 가이드 코드 (우선):

  src/modules/test-data/

  또는 기존

  src/modules-task/{년월}/{태스크폴더}/

• Mock 데이터:

  src/modules-task/{년월}/{태스크폴더}/{서브모듈}/mock/

• Store:

  src/modules-task/{년월}/{태스크폴더}/{서브모듈}/store/

test-data 가이드 코드를 기준 골격으로 참조하되, Mock 특화 + 도메인 특성에 맞게 Bounded Autonomy 범위 내에서 적응