api-rule.mdc 14 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445
  1. ---
  2. alwaysApply: true
  3. ---
  4. # 최우선 규칙: 한글 응답 필수
  5. **모든 응답은 한글로만 작성해야 함. 이 규칙은 다른 모든 규칙보다 우선한다.**
  6. # companyId 사용 금지 규칙
  7. **companyId는 사용하지 않는 값이므로 모든 코드에서 제거해야 함. 프론트엔드, 백엔드 모두 해당.**
  8. - 대신 COMPANY_NUMBER를 직접 사용
  9. - companyId 관련 변수, 필드, 파라미터 모두 제거
  10. - API 요청/응답에서 companyId 사용 금지
  11. # 벤더-인플루언서 처리자 SEQ 인증 규칙
  12. **백엔드에서 processedBy, approvedBy, terminatedBy 등 처리자 SEQ를 받을 때는 반드시 다음 로직을 적용해야 함:**
  13. ## 처리자 SEQ 변환 표준 로직
  14. ```php
  15. // 처리자 확인 (벤더사 SEQ인지 사용자 SEQ인지 확인)
  16. $processingUser = null;
  17. // 1. 먼저 USER_LIST에서 확인 (인플루언서)
  18. $processingUser = $this->userModel
  19. ->where('SEQ', $processedBy)
  20. ->where('IS_ACT', 'Y')
  21. ->first();
  22. if ($processingUser) {
  23. // 사용자 SEQ인 경우 (인플루언서) - 바로 사용
  24. $approvedByUserSeq = $processedBy;
  25. } else {
  26. // 2. VENDOR_LIST에서 확인 (벤더사)
  27. $vendorInfo = $this->vendorModel
  28. ->where('SEQ', $processedBy)
  29. ->where('IS_ACT', 'Y')
  30. ->first();
  31. if ($vendorInfo) {
  32. // 벤더사 SEQ인 경우 - 벤더사가 직접 처리하는 것으로 간주
  33. $approvedByUserSeq = $processedBy;
  34. // 응답용 정보 설정 (필요시)
  35. $processingUser = [
  36. 'SEQ' => $vendorInfo['SEQ'],
  37. 'NICK_NAME' => $vendorInfo['COMPANY_NAME'] . ' (벤더사)',
  38. 'NAME' => $vendorInfo['COMPANY_NAME']
  39. ];
  40. } else {
  41. return $this->response->setStatusCode(400)->setJSON([
  42. 'success' => false,
  43. 'message' => "처리자 SEQ {$processedBy}는 USER_LIST나 VENDOR_LIST에서 찾을 수 없습니다."
  44. ]);
  45. }
  46. }
  47. // 최종적으로 $approvedByUserSeq를 데이터베이스에 저장
  48. ```
  49. ## 규칙 적용 필수 상황
  50. - **승인/거부 처리**: approveRequest() 함수
  51. - **해지 처리**: terminate() 함수
  52. - **취소 처리**: cancelRequest() 함수
  53. - **기타 모든 사용자 인증이 필요한 벤더-인플루언서 관련 API**
  54. ## 이유
  55. - **인플루언서**: USER_LIST 테이블에서 개인 계정으로 관리
  56. - **벤더사**: VENDOR_LIST 테이블에서 회사 계정으로 관리
  57. - 두 시스템을 구분하여 처리하되, 데이터베이스 저장 시에는 해당 SEQ를 그대로 사용
  58. - USER_LIST에는 COMPANY_NUMBER 컬럼이 불필요함 (인플루언서는 개인이므로)
  59. # API & Store Rules
  60. ## Pinia Store Rules
  61. ### 1. Setup Syntax Store Reset 구현
  62. - Setup 문법(`defineStore(() => {...})`)으로 작성된 store는 자동 `$reset()`이 제공되지 않음
  63. - 반드시 수동으로 `reset()` 함수를 구현해야 함
  64. ```typescript
  65. // Good
  66. export const useMyStore = defineStore('myStore', () => {
  67. const data = ref([])
  68. const loading = ref(false)
  69. // 수동으로 reset 함수 구현
  70. function reset() {
  71. data.value = []
  72. loading.value = false
  73. }
  74. return {
  75. data,
  76. loading,
  77. reset // reset 함수 반환 필수
  78. }
  79. })
  80. // Bad - reset 함수 없음
  81. export const useMyStore = defineStore('myStore', () => {
  82. const data = ref([])
  83. return { data }
  84. })
  85. ```
  86. ### 2. Reset 함수 구현 가이드
  87. - 모든 state를 초기값으로 되돌리는 로직 포함
  88. - 중첩된 객체의 경우 깊은 복사 고려
  89. - persist 옵션이 있는 경우 저장소 데이터도 정리
  90. ```typescript
  91. function reset() {
  92. // 단순 값 초기화
  93. simpleValue.value = null
  94. // 객체 초기화
  95. objectValue.value = {
  96. prop1: '',
  97. prop2: 0
  98. }
  99. // 배열 초기화
  100. arrayValue.value = []
  101. // 중첩 객체 초기화
  102. complexValue.value = JSON.parse(JSON.stringify(DEFAULT_STATE))
  103. }
  104. ```
  105. ### 3. Store 초기화 호출 방식
  106. - Setup 문법 store: `store.reset()`
  107. - Options 문법 store: `store.$reset()`
  108. ```typescript
  109. // Setup store
  110. const setupStore = useSetupStore()
  111. setupStore.reset() // O
  112. setupStore.$reset() // X - 에러 발생
  113. // Options store
  114. const optionsStore = useOptionsStore()
  115. optionsStore.$reset() // O
  116. ```
  117. ### 4. Store 초기화 시점
  118. - 로그아웃
  119. - 사용자 전환
  120. - 주요 상태 변경
  121. - 에러 복구
  122. ```typescript
  123. async function logout() {
  124. // 모든 store 초기화
  125. authStore.setLogout()
  126. setupStore.reset() // Setup syntax
  127. optionsStore.$reset() // Options syntax
  128. // 로컬 스토리지 정리
  129. localStorage.clear()
  130. }
  131. ```
  132. ## API Rules
  133. - api 서버는 코드이그나이터4 베이스의 벡엔드 기술로 구현되어있으며
  134. 기존 문서에사용되는 양식을 지키며 구현
  135. - 프론트에서 api신규 생성시 백엔드 코드이그나4 기반의 기술로 구현하는 예제를 함께 제공
  136. - 항상 페이지 구성이 완료되고 나면 제작에 필요한 쿼리를 DDL형태로 구성해서 ddl폴더에 만들어줘
  137. - api구성후 백엔드 예제를 backend-examples에 코드이그나이터4 형태로 구성해줘
  138. - MD파일을 생성해서 백엔드 구성과 DB생성을 하는 과정을 순서대로 작성해줘
  139. - 프론트화면 및 UI / API 구성시에는 항상 composition api 형태로 작성 css는 항상 scss형태로 분리해서 구성
  140. ## 프론트엔드 API 호출 규칙
  141. - **Nuxt.js server/api 사용 금지**: 프론트엔드에서 직접 백엔드 API 호출
  142. - **useAxios() 패턴 강제**: 기존 코드베이스와 일관성 유지
  143. - 반드시 다음 형태로 구성:
  144. ```javascript
  145. const loadData = async () => {
  146. try {
  147. const params = {
  148. // 파라미터들...
  149. }
  150. useAxios()
  151. .post('/api/endpoint', params)
  152. .then((res) => {
  153. if (res.data.success) {
  154. // 성공 처리
  155. data.value = res.data.data
  156. } else {
  157. // 실패 처리
  158. error.value = res.data.message
  159. }
  160. })
  161. .catch((err) => {
  162. // 에러 처리
  163. error.value = err.message
  164. })
  165. .finally(() => {
  166. // 완료 처리
  167. loading.value = false
  168. })
  169. } catch (err) {
  170. error.value = err.message
  171. }
  172. }
  173. ```
  174. ## API 구조 금지사항
  175. - **server/api 디렉토리 생성 금지**: Nuxt.js 서버 API 사용하지 않음
  176. - **mysql2, 데이터베이스 라이브러리 사용 금지**: 프론트엔드에서 직접 DB 연결 금지
  177. - **$fetch 사용 금지**: useAxios() 패턴만 사용
  178. - **async/await 패턴 지양**: .then().catch().finally() 체인 사용
  179. ## 백엔드 연동 방식
  180. - 프론트엔드 → CodeIgniter4 백엔드 직접 호출
  181. - useAxios()를 통한 HTTP 통신만 사용
  182. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  183. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어
  184. - useAxios()를 통한 HTTP 통신만 사용
  185. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  186. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어
  187. - useAxios()를 통한 HTTP 통신만 사용
  188. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  189. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어
  190. # 최우선 규칙: 한글 응답 필수
  191. **모든 응답은 한글로만 작성해야 함. 이 규칙은 다른 모든 규칙보다 우선한다.**
  192. # companyId 사용 금지 규칙
  193. **companyId는 사용하지 않는 값이므로 모든 코드에서 제거해야 함. 프론트엔드, 백엔드 모두 해당.**
  194. - 대신 COMPANY_NUMBER를 직접 사용
  195. - companyId 관련 변수, 필드, 파라미터 모두 제거
  196. - API 요청/응답에서 companyId 사용 금지
  197. # 벤더-인플루언서 처리자 SEQ 인증 규칙
  198. **백엔드에서 processedBy, approvedBy, terminatedBy 등 처리자 SEQ를 받을 때는 반드시 다음 로직을 적용해야 함:**
  199. ## 처리자 SEQ 변환 표준 로직
  200. ```php
  201. // 처리자 확인 (벤더사 SEQ인지 사용자 SEQ인지 확인)
  202. $processingUser = null;
  203. // 1. 먼저 USER_LIST에서 확인 (인플루언서)
  204. $processingUser = $this->userModel
  205. ->where('SEQ', $processedBy)
  206. ->where('IS_ACT', 'Y')
  207. ->first();
  208. if ($processingUser) {
  209. // 사용자 SEQ인 경우 (인플루언서) - 바로 사용
  210. $approvedByUserSeq = $processedBy;
  211. } else {
  212. // 2. VENDOR_LIST에서 확인 (벤더사)
  213. $vendorInfo = $this->vendorModel
  214. ->where('SEQ', $processedBy)
  215. ->where('IS_ACT', 'Y')
  216. ->first();
  217. if ($vendorInfo) {
  218. // 벤더사 SEQ인 경우 - 벤더사가 직접 처리하는 것으로 간주
  219. $approvedByUserSeq = $processedBy;
  220. // 응답용 정보 설정 (필요시)
  221. $processingUser = [
  222. 'SEQ' => $vendorInfo['SEQ'],
  223. 'NICK_NAME' => $vendorInfo['COMPANY_NAME'] . ' (벤더사)',
  224. 'NAME' => $vendorInfo['COMPANY_NAME']
  225. ];
  226. } else {
  227. return $this->response->setStatusCode(400)->setJSON([
  228. 'success' => false,
  229. 'message' => "처리자 SEQ {$processedBy}는 USER_LIST나 VENDOR_LIST에서 찾을 수 없습니다."
  230. ]);
  231. }
  232. }
  233. // 최종적으로 $approvedByUserSeq를 데이터베이스에 저장
  234. ```
  235. ## 규칙 적용 필수 상황
  236. - **승인/거부 처리**: approveRequest() 함수
  237. - **해지 처리**: terminate() 함수
  238. - **취소 처리**: cancelRequest() 함수
  239. - **기타 모든 사용자 인증이 필요한 벤더-인플루언서 관련 API**
  240. ## 이유
  241. - **인플루언서**: USER_LIST 테이블에서 개인 계정으로 관리
  242. - **벤더사**: VENDOR_LIST 테이블에서 회사 계정으로 관리
  243. - 두 시스템을 구분하여 처리하되, 데이터베이스 저장 시에는 해당 SEQ를 그대로 사용
  244. - USER_LIST에는 COMPANY_NUMBER 컬럼이 불필요함 (인플루언서는 개인이므로)
  245. # API & Store Rules
  246. ## Pinia Store Rules
  247. ### 1. Setup Syntax Store Reset 구현
  248. - Setup 문법(`defineStore(() => {...})`)으로 작성된 store는 자동 `$reset()`이 제공되지 않음
  249. - 반드시 수동으로 `reset()` 함수를 구현해야 함
  250. ```typescript
  251. // Good
  252. export const useMyStore = defineStore('myStore', () => {
  253. const data = ref([])
  254. const loading = ref(false)
  255. // 수동으로 reset 함수 구현
  256. function reset() {
  257. data.value = []
  258. loading.value = false
  259. }
  260. return {
  261. data,
  262. loading,
  263. reset // reset 함수 반환 필수
  264. }
  265. })
  266. // Bad - reset 함수 없음
  267. export const useMyStore = defineStore('myStore', () => {
  268. const data = ref([])
  269. return { data }
  270. })
  271. ```
  272. ### 2. Reset 함수 구현 가이드
  273. - 모든 state를 초기값으로 되돌리는 로직 포함
  274. - 중첩된 객체의 경우 깊은 복사 고려
  275. - persist 옵션이 있는 경우 저장소 데이터도 정리
  276. ```typescript
  277. function reset() {
  278. // 단순 값 초기화
  279. simpleValue.value = null
  280. // 객체 초기화
  281. objectValue.value = {
  282. prop1: '',
  283. prop2: 0
  284. }
  285. // 배열 초기화
  286. arrayValue.value = []
  287. // 중첩 객체 초기화
  288. complexValue.value = JSON.parse(JSON.stringify(DEFAULT_STATE))
  289. }
  290. ```
  291. ### 3. Store 초기화 호출 방식
  292. - Setup 문법 store: `store.reset()`
  293. - Options 문법 store: `store.$reset()`
  294. ```typescript
  295. // Setup store
  296. const setupStore = useSetupStore()
  297. setupStore.reset() // O
  298. setupStore.$reset() // X - 에러 발생
  299. // Options store
  300. const optionsStore = useOptionsStore()
  301. optionsStore.$reset() // O
  302. ```
  303. ### 4. Store 초기화 시점
  304. - 로그아웃
  305. - 사용자 전환
  306. - 주요 상태 변경
  307. - 에러 복구
  308. ```typescript
  309. async function logout() {
  310. // 모든 store 초기화
  311. authStore.setLogout()
  312. setupStore.reset() // Setup syntax
  313. optionsStore.$reset() // Options syntax
  314. // 로컬 스토리지 정리
  315. localStorage.clear()
  316. }
  317. ```
  318. ## API Rules
  319. - api 서버는 코드이그나이터4 베이스의 벡엔드 기술로 구현되어있으며
  320. 기존 문서에사용되는 양식을 지키며 구현
  321. - 프론트에서 api신규 생성시 백엔드 코드이그나4 기반의 기술로 구현하는 예제를 함께 제공
  322. - 항상 페이지 구성이 완료되고 나면 제작에 필요한 쿼리를 DDL형태로 구성해서 ddl폴더에 만들어줘
  323. - api구성후 백엔드 예제를 backend-examples에 코드이그나이터4 형태로 구성해줘
  324. - MD파일을 생성해서 백엔드 구성과 DB생성을 하는 과정을 순서대로 작성해줘
  325. - 프론트화면 및 UI / API 구성시에는 항상 composition api 형태로 작성 css는 항상 scss형태로 분리해서 구성
  326. ## 프론트엔드 API 호출 규칙
  327. - **Nuxt.js server/api 사용 금지**: 프론트엔드에서 직접 백엔드 API 호출
  328. - **useAxios() 패턴 강제**: 기존 코드베이스와 일관성 유지
  329. - 반드시 다음 형태로 구성:
  330. ```javascript
  331. const loadData = async () => {
  332. try {
  333. const params = {
  334. // 파라미터들...
  335. }
  336. useAxios()
  337. .post('/api/endpoint', params)
  338. .then((res) => {
  339. if (res.data.success) {
  340. // 성공 처리
  341. data.value = res.data.data
  342. } else {
  343. // 실패 처리
  344. error.value = res.data.message
  345. }
  346. })
  347. .catch((err) => {
  348. // 에러 처리
  349. error.value = err.message
  350. })
  351. .finally(() => {
  352. // 완료 처리
  353. loading.value = false
  354. })
  355. } catch (err) {
  356. error.value = err.message
  357. }
  358. }
  359. ```
  360. ## API 구조 금지사항
  361. - **server/api 디렉토리 생성 금지**: Nuxt.js 서버 API 사용하지 않음
  362. - **mysql2, 데이터베이스 라이브러리 사용 금지**: 프론트엔드에서 직접 DB 연결 금지
  363. - **$fetch 사용 금지**: useAxios() 패턴만 사용
  364. - **async/await 패턴 지양**: .then().catch().finally() 체인 사용
  365. ## 백엔드 연동 방식
  366. - 프론트엔드 → CodeIgniter4 백엔드 직접 호출
  367. - useAxios()를 통한 HTTP 통신만 사용
  368. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  369. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어
  370. - useAxios()를 통한 HTTP 통신만 사용
  371. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  372. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어
  373. - useAxios()를 통한 HTTP 통신만 사용
  374. - 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
  375. - 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어