🛠️ 개발 및 관리 규칙 (Strict Development Rules)

1. 언어 설정: 영어로 생각하되, 모든 답변은 한국어로 작성한다.
2. 임의 수정 절대 금지 (Zero-Arbitrary Change):
   • 사용자가 명시적으로 지시한 부분 외에는 단 한 줄의 코드도, 그 어떤 파일도 임의로 수정, 정리, 리팩토링하지 않는다.
   • 지시받지 않은 다른 파트의 코드는 절대 건드리지 않으며, 영향 범위가 요청 범위를 벗어나지 않도록 '외과 수술식(Surgical) 수정'을 원칙으로 한다.
3. 개선 작업 절차 (Test-First Approach):
   • 사용자가 개선(Refactoring, Optimization 등)을 지시한 경우, 수정 전 현재 시스템이 정상적으로 잘 작동하는지 먼저 전수 확인한다.
   • 기존 동작 방식과 성능을 기준(Baseline)으로 삼고, 수정 후에도 기존의 모든 기능이 무결하게 유지되는지 반드시 테스트하여 입증한다.
   • 검증 결과를 바탕으로 "무엇을, 왜, 어떻게" 바꿀지 상세 보고 후, 사용자로부터 '진행시켜' 승인을 얻은 뒤에만 집행한다.
4. 선보고 후승인: 모든 기능 수정 및 코드 변경 전에는 예상 방안을 먼저 보고하고 승인 절차를 거친다.
5. DB 삭제 및 초기화 절대 엄금 (Strict DB Deletion Policy):
   • 어떠한 경우에도 DELETE, DROP, TRUNCATE 등 데이터를 삭제하거나 테이블을 초기화하는 작업은 사전에 사용자에게 상세 사유를 보고하고 명시적 승인을 얻은 후에만 시행한다.
   • 기존 데이터의 가치를 최우선으로 하며, 작업 전 백업 여부를 반드시 확인한다.
6. RED–GREEN–Refactor 개발 원칙:
   • 모든 기능 개발과 버그 수정은 RED → GREEN → Refactor 순서로 진행한다.
   • RED: 요구사항을 명확히 표현하는 테스트를 먼저 작성하고, 해당 테스트가 기능 미구현 또는 결함으로 인해 실패하는지 확인한다.
   • GREEN: 실패한 테스트를 통과시키는 데 필요한 최소한의 코드만 구현하며, 불필요한 기능 추가나 구조 변경을 하지 않는다.
   • Refactor: 관련 테스트와 기존 테스트가 모두 통과하는 상태에서만 중복 제거, 명칭 개선, 책임 분리 등 코드 구조를 개선하며 동작은 변경하지 않는다.
   • 각 단계가 끝날 때마다 관련 테스트와 기존 기능의 회귀 여부를 검증한다.
   • 테스트 작성이 현실적으로 불가능한 경우에는 그 사유와 대체 검증 방법을 먼저 보고하고 승인을 받은 후 진행한다.
   • 본 원칙을 적용할 때에도 기존의 선보고 후승인 및 외과 수술식 수정 규칙을 준수한다.

---

🚀 서버 구동 및 외부 접속 규칙 (Server Run & External Access)

1. 포트 고정: 개발 서버는 반드시 8080 포트를 사용한다. (vite.config.ts 설정 준수)
2. 외부 접속 허용 (Host): 사무실 내 타 직원이 접속할 수 있도록 --host 모드로 구동한다.
3. 구동 명령어:

   npm run dev
   

   • 해당 명령어 실행 시 0.0.0.0 또는 Network: http://[내-IP]:8080/ 경로로 타인 접속이 가능하다.
4. IP 확인 방법:
   • Windows: ipconfig 명령어로 'IPv4 주소' 확인 후 공유.

---

🎨 ITAM 시스템 디자인 가이드 (Design Guide)

디자인 일관성 및 시각적 원칙에 관한 상세 내용은 아래 문서를 참조하십시오.

👉 디자인 가이드 바로가기 (design_rule.md)