influence/.cursor/rules/api-rule.mdc

# 최우선 규칙: 한글 응답 필수

**모든 응답은 한글로만 작성해야 함. 이 규칙은 다른 모든 규칙보다 우선한다.**

# 🛡️ 기존 기능 안전성 보장 규칙 (최우선)

**모든 기능 수정, 추가, 버그 수정 시 기존 정상 기능들이 영향받지 않도록 사전 체크 및 안전장치 적용 필수**

## 필수 준수사항
1. **기존 API 엔드포인트 직접 수정 금지** - 새 엔드포인트 생성 
2. **기존 데이터베이스 스키마 파괴적 변경 금지** - 아카이브 방식 사용
3. **기존 컨트롤러/모델 메서드 직접 수정 금지** - 새 메서드 생성
4. **기존 프론트엔드 컴포넌트 직접 수정 최소화** - 조건부 렌더링 활용
5. **모든 변경사항은 독립적 구조로 설계** - 기존 기능과 분리

## 사전 체크 필수
- [ ] 기존 기능 영향도 분석
- [ ] 독립적 구조 설계 확인  
- [ ] 롤백 계획 수립
- [ ] 기존 기능 회귀 테스트

# 변경 로그 관리 규칙

**모든 작업 완료 후 반드시 md 폴더에 날짜별 변경 로그를 작성해야 함.**

## 작성 규칙
- **파일명**: `md/YYYY-MM-DD.md` 형식
- **언어**: 한글로 작성
- **템플릿**: `md/README.md` 참조

## 필수 작성 시점
- ✅ 새로운 기능 구현 후
- ✅ 버그 수정 후  
- ✅ 리팩토링 완료 후
- ✅ API 추가/수정 후
- ✅ 데이터베이스 스키마 변경 후
- ✅ UI/UX 개선 후

## 작성 내용
- 🎯 주요 변경사항 요약
- 📝 변경된 파일 목록과 상세 내용
- 🧪 테스트 확인 결과
- 📌 다음 작업 예정사항

# 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예제를 만들어
- useAxios()를 통한 HTTP 통신만 사용
- 응답 형태: `res.data.success`, `res.data.data`, `res.data.message`
- 백엔드는 직접 만들거야 다만 너가 backend-examples 폴더에 프론트와 수신할수는있는 형태의 api예제를 만들어