--- alwaysApply: true --- # 최우선 규칙: 한글 응답 필수 **모든 응답은 한글로만 작성해야 함. 이 규칙은 다른 모든 규칙보다 우선한다.** # companyId 사용 금지 규칙 **companyId는 사용하지 않는 값이므로 모든 코드에서 제거해야 함. 프론트엔드, 백엔드 모두 해당.** - 대신 COMPANY_NUMBER를 직접 사용 - companyId 관련 변수, 필드, 파라미터 모두 제거 - API 요청/응답에서 companyId 사용 금지 # 벤더-인플루언서 처리자 SEQ 인증 규칙 **백엔드에서 processedBy, approvedBy, terminatedBy 등 처리자 SEQ를 받을 때는 반드시 다음 로직을 적용해야 함:** ## 처리자 SEQ 변환 표준 로직 ```php // 처리자 확인 (벤더사 SEQ인지 사용자 SEQ인지 확인) $processingUser = null; // 1. 먼저 USER_LIST에서 확인 (인플루언서) $processingUser = $this->userModel ->where('SEQ', $processedBy) ->where('IS_ACT', 'Y') ->first(); if ($processingUser) { // 사용자 SEQ인 경우 (인플루언서) - 바로 사용 $approvedByUserSeq = $processedBy; } else { // 2. VENDOR_LIST에서 확인 (벤더사) $vendorInfo = $this->vendorModel ->where('SEQ', $processedBy) ->where('IS_ACT', 'Y') ->first(); if ($vendorInfo) { // 벤더사 SEQ인 경우 - 벤더사가 직접 처리하는 것으로 간주 $approvedByUserSeq = $processedBy; // 응답용 정보 설정 (필요시) $processingUser = [ 'SEQ' => $vendorInfo['SEQ'], 'NICK_NAME' => $vendorInfo['COMPANY_NAME'] . ' (벤더사)', 'NAME' => $vendorInfo['COMPANY_NAME'] ]; } else { return $this->response->setStatusCode(400)->setJSON([ 'success' => false, 'message' => "처리자 SEQ {$processedBy}는 USER_LIST나 VENDOR_LIST에서 찾을 수 없습니다." ]); } } // 최종적으로 $approvedByUserSeq를 데이터베이스에 저장 ``` ## 규칙 적용 필수 상황 - **승인/거부 처리**: approveRequest() 함수 - **해지 처리**: terminate() 함수 - **취소 처리**: cancelRequest() 함수 - **기타 모든 사용자 인증이 필요한 벤더-인플루언서 관련 API** ## 이유 - **인플루언서**: USER_LIST 테이블에서 개인 계정으로 관리 - **벤더사**: VENDOR_LIST 테이블에서 회사 계정으로 관리 - 두 시스템을 구분하여 처리하되, 데이터베이스 저장 시에는 해당 SEQ를 그대로 사용 - USER_LIST에는 COMPANY_NUMBER 컬럼이 불필요함 (인플루언서는 개인이므로) # API & Store Rules ## Pinia Store Rules ### 1. Setup Syntax Store Reset 구현 - Setup 문법(`defineStore(() => {...})`)으로 작성된 store는 자동 `$reset()`이 제공되지 않음 - 반드시 수동으로 `reset()` 함수를 구현해야 함 ```typescript // Good export const useMyStore = defineStore('myStore', () => { const data = ref([]) const loading = ref(false) // 수동으로 reset 함수 구현 function reset() { data.value = [] loading.value = false } return { data, loading, reset // reset 함수 반환 필수 } }) // Bad - reset 함수 없음 export const useMyStore = defineStore('myStore', () => { const data = ref([]) return { data } }) ``` ### 2. Reset 함수 구현 가이드 - 모든 state를 초기값으로 되돌리는 로직 포함 - 중첩된 객체의 경우 깊은 복사 고려 - persist 옵션이 있는 경우 저장소 데이터도 정리 ```typescript function reset() { // 단순 값 초기화 simpleValue.value = null // 객체 초기화 objectValue.value = { prop1: '', prop2: 0 } // 배열 초기화 arrayValue.value = [] // 중첩 객체 초기화 complexValue.value = JSON.parse(JSON.stringify(DEFAULT_STATE)) } ``` ### 3. Store 초기화 호출 방식 - Setup 문법 store: `store.reset()` - Options 문법 store: `store.$reset()` ```typescript // Setup store const setupStore = useSetupStore() setupStore.reset() // O setupStore.$reset() // X - 에러 발생 // Options store const optionsStore = useOptionsStore() optionsStore.$reset() // O ``` ### 4. Store 초기화 시점 - 로그아웃 - 사용자 전환 - 주요 상태 변경 - 에러 복구 ```typescript async function logout() { // 모든 store 초기화 authStore.setLogout() setupStore.reset() // Setup syntax optionsStore.$reset() // Options syntax // 로컬 스토리지 정리 localStorage.clear() } ``` ## API Rules - api 서버는 코드이그나이터4 베이스의 벡엔드 기술로 구현되어있으며 기존 문서에사용되는 양식을 지키며 구현 - 프론트에서 api신규 생성시 백엔드 코드이그나4 기반의 기술로 구현하는 예제를 함께 제공 - 항상 페이지 구성이 완료되고 나면 제작에 필요한 쿼리를 DDL형태로 구성해서 ddl폴더에 만들어줘 - api구성후 백엔드 예제를 backend-examples에 코드이그나이터4 형태로 구성해줘 - MD파일을 생성해서 백엔드 구성과 DB생성을 하는 과정을 순서대로 작성해줘 - 프론트화면 및 UI / API 구성시에는 항상 composition api 형태로 작성 css는 항상 scss형태로 분리해서 구성 ## 프론트엔드 API 호출 규칙 - **Nuxt.js server/api 사용 금지**: 프론트엔드에서 직접 백엔드 API 호출 - **useAxios() 패턴 강제**: 기존 코드베이스와 일관성 유지 - 반드시 다음 형태로 구성: ```javascript const loadData = async () => { try { const params = { // 파라미터들... } useAxios() .post('/api/endpoint', params) .then((res) => { if (res.data.success) { // 성공 처리 data.value = res.data.data } else { // 실패 처리 error.value = res.data.message } }) .catch((err) => { // 에러 처리 error.value = err.message }) .finally(() => { // 완료 처리 loading.value = false }) } catch (err) { error.value = err.message } } ``` ## API 구조 금지사항 - **server/api 디렉토리 생성 금지**: Nuxt.js 서버 API 사용하지 않음 - **mysql2, 데이터베이스 라이브러리 사용 금지**: 프론트엔드에서 직접 DB 연결 금지 - **$fetch 사용 금지**: useAxios() 패턴만 사용 - **async/await 패턴 지양**: .then().catch().finally() 체인 사용 ## 백엔드 연동 방식 - 프론트엔드 → CodeIgniter4 백엔드 직접 호출 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어 # 최우선 규칙: 한글 응답 필수 **모든 응답은 한글로만 작성해야 함. 이 규칙은 다른 모든 규칙보다 우선한다.** # companyId 사용 금지 규칙 **companyId는 사용하지 않는 값이므로 모든 코드에서 제거해야 함. 프론트엔드, 백엔드 모두 해당.** - 대신 COMPANY_NUMBER를 직접 사용 - companyId 관련 변수, 필드, 파라미터 모두 제거 - API 요청/응답에서 companyId 사용 금지 # 벤더-인플루언서 처리자 SEQ 인증 규칙 **백엔드에서 processedBy, approvedBy, terminatedBy 등 처리자 SEQ를 받을 때는 반드시 다음 로직을 적용해야 함:** ## 처리자 SEQ 변환 표준 로직 ```php // 처리자 확인 (벤더사 SEQ인지 사용자 SEQ인지 확인) $processingUser = null; // 1. 먼저 USER_LIST에서 확인 (인플루언서) $processingUser = $this->userModel ->where('SEQ', $processedBy) ->where('IS_ACT', 'Y') ->first(); if ($processingUser) { // 사용자 SEQ인 경우 (인플루언서) - 바로 사용 $approvedByUserSeq = $processedBy; } else { // 2. VENDOR_LIST에서 확인 (벤더사) $vendorInfo = $this->vendorModel ->where('SEQ', $processedBy) ->where('IS_ACT', 'Y') ->first(); if ($vendorInfo) { // 벤더사 SEQ인 경우 - 벤더사가 직접 처리하는 것으로 간주 $approvedByUserSeq = $processedBy; // 응답용 정보 설정 (필요시) $processingUser = [ 'SEQ' => $vendorInfo['SEQ'], 'NICK_NAME' => $vendorInfo['COMPANY_NAME'] . ' (벤더사)', 'NAME' => $vendorInfo['COMPANY_NAME'] ]; } else { return $this->response->setStatusCode(400)->setJSON([ 'success' => false, 'message' => "처리자 SEQ {$processedBy}는 USER_LIST나 VENDOR_LIST에서 찾을 수 없습니다." ]); } } // 최종적으로 $approvedByUserSeq를 데이터베이스에 저장 ``` ## 규칙 적용 필수 상황 - **승인/거부 처리**: approveRequest() 함수 - **해지 처리**: terminate() 함수 - **취소 처리**: cancelRequest() 함수 - **기타 모든 사용자 인증이 필요한 벤더-인플루언서 관련 API** ## 이유 - **인플루언서**: USER_LIST 테이블에서 개인 계정으로 관리 - **벤더사**: VENDOR_LIST 테이블에서 회사 계정으로 관리 - 두 시스템을 구분하여 처리하되, 데이터베이스 저장 시에는 해당 SEQ를 그대로 사용 - USER_LIST에는 COMPANY_NUMBER 컬럼이 불필요함 (인플루언서는 개인이므로) # API & Store Rules ## Pinia Store Rules ### 1. Setup Syntax Store Reset 구현 - Setup 문법(`defineStore(() => {...})`)으로 작성된 store는 자동 `$reset()`이 제공되지 않음 - 반드시 수동으로 `reset()` 함수를 구현해야 함 ```typescript // Good export const useMyStore = defineStore('myStore', () => { const data = ref([]) const loading = ref(false) // 수동으로 reset 함수 구현 function reset() { data.value = [] loading.value = false } return { data, loading, reset // reset 함수 반환 필수 } }) // Bad - reset 함수 없음 export const useMyStore = defineStore('myStore', () => { const data = ref([]) return { data } }) ``` ### 2. Reset 함수 구현 가이드 - 모든 state를 초기값으로 되돌리는 로직 포함 - 중첩된 객체의 경우 깊은 복사 고려 - persist 옵션이 있는 경우 저장소 데이터도 정리 ```typescript function reset() { // 단순 값 초기화 simpleValue.value = null // 객체 초기화 objectValue.value = { prop1: '', prop2: 0 } // 배열 초기화 arrayValue.value = [] // 중첩 객체 초기화 complexValue.value = JSON.parse(JSON.stringify(DEFAULT_STATE)) } ``` ### 3. Store 초기화 호출 방식 - Setup 문법 store: `store.reset()` - Options 문법 store: `store.$reset()` ```typescript // Setup store const setupStore = useSetupStore() setupStore.reset() // O setupStore.$reset() // X - 에러 발생 // Options store const optionsStore = useOptionsStore() optionsStore.$reset() // O ``` ### 4. Store 초기화 시점 - 로그아웃 - 사용자 전환 - 주요 상태 변경 - 에러 복구 ```typescript async function logout() { // 모든 store 초기화 authStore.setLogout() setupStore.reset() // Setup syntax optionsStore.$reset() // Options syntax // 로컬 스토리지 정리 localStorage.clear() } ``` ## API Rules - api 서버는 코드이그나이터4 베이스의 벡엔드 기술로 구현되어있으며 기존 문서에사용되는 양식을 지키며 구현 - 프론트에서 api신규 생성시 백엔드 코드이그나4 기반의 기술로 구현하는 예제를 함께 제공 - 항상 페이지 구성이 완료되고 나면 제작에 필요한 쿼리를 DDL형태로 구성해서 ddl폴더에 만들어줘 - api구성후 백엔드 예제를 backend-examples에 코드이그나이터4 형태로 구성해줘 - MD파일을 생성해서 백엔드 구성과 DB생성을 하는 과정을 순서대로 작성해줘 - 프론트화면 및 UI / API 구성시에는 항상 composition api 형태로 작성 css는 항상 scss형태로 분리해서 구성 ## 프론트엔드 API 호출 규칙 - **Nuxt.js server/api 사용 금지**: 프론트엔드에서 직접 백엔드 API 호출 - **useAxios() 패턴 강제**: 기존 코드베이스와 일관성 유지 - 반드시 다음 형태로 구성: ```javascript const loadData = async () => { try { const params = { // 파라미터들... } useAxios() .post('/api/endpoint', params) .then((res) => { if (res.data.success) { // 성공 처리 data.value = res.data.data } else { // 실패 처리 error.value = res.data.message } }) .catch((err) => { // 에러 처리 error.value = err.message }) .finally(() => { // 완료 처리 loading.value = false }) } catch (err) { error.value = err.message } } ``` ## API 구조 금지사항 - **server/api 디렉토리 생성 금지**: Nuxt.js 서버 API 사용하지 않음 - **mysql2, 데이터베이스 라이브러리 사용 금지**: 프론트엔드에서 직접 DB 연결 금지 - **$fetch 사용 금지**: useAxios() 패턴만 사용 - **async/await 패턴 지양**: .then().catch().finally() 체인 사용 ## 백엔드 연동 방식 - 프론트엔드 → CodeIgniter4 백엔드 직접 호출 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어 - useAxios()를 통한 HTTP 통신만 사용 - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message` - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어