87 lines
5.1 KiB
Markdown
87 lines
5.1 KiB
Markdown
# 🚀 서버 정책 (Server Policy)
|
|
|
|
**서버 구동 시 반드시 아래 명령어를 사용한다:**
|
|
```bash
|
|
uvicorn server:app --host 0.0.0.0 --port 8000 --reload
|
|
```
|
|
- **Host**: `0.0.0.0` (외부 접속 허용)
|
|
- **Port**: `8000`
|
|
- **Reload**: 코드 수정 시 자동 재시작 활성화
|
|
|
|
---
|
|
|
|
# 🤖 메일시스템 AI판단가이드 (AI Reasoning Guide)
|
|
|
|
AI는 파일을 분류할 때 단순한 키워드 매칭이 아닌, 아래의 **5단계 통합 추론 모델**을 사용하여 '실무자처럼' 생각하고 판단한다.
|
|
|
|
### 1단계: 전수 데이터 수집 (Holistic Reading)
|
|
- **무제한 스캔**: 페이지 수에 관계없이 문서 전체를 전수 조사한다.
|
|
- **무조건적 OCR**: 디지털 텍스트 유무와 상관없이 모든 페이지에 고해상도(300 DPI) OCR을 실행하여 이미지 속 도장, 수기, 표 데이터까지 완벽히 수집한다.
|
|
|
|
### 2단계: 파일명 가중치 적용 (Title Steering)
|
|
- **파일명 = 보관 의도**: 사용자가 지은 파일명은 분류의 가장 강력한 '방향타'이다.
|
|
- **최종 조율**: 본문의 데이터가 다른 도메인에 쏠려 있더라도, 파일명에 명확한 업무 용어(`실정보고`, `하도급` 등)가 있다면 이를 최종 분류의 가장 큰 무게추로 삼는다.
|
|
|
|
### 3단계: 문서의 물리적 틀(Format) 분석
|
|
- **공문 골격 확인**: 문서의 시작(`수신/발신`)과 끝(`직인/끝.`)의 구조를 확인한다.
|
|
- **껍데기 vs 알맹이**:
|
|
- **공문 본체**: 골격이 완벽하고 뒤따르는 기술 데이터가 적은 경우 → **[공사관리 > 공문]**
|
|
- **첨부 본체**: 공문 뒤에 대량의 산출서, 계약서, 도면이 붙어 있는 경우 → **[해당 기술 카테고리]** (공문은 전달 수단으로만 간주)
|
|
|
|
### 4단계: 비즈니스 도메인 상식 결합 (Common Sense)
|
|
- **지명 교차 검증**: 파일명과 본문의 지명(어천, 공주, 대술, 정안 등)을 대조하여 정확한 프로젝트를 선택한다. (임의 기본값 지정 금지)
|
|
- **실무 맥락 매칭**: '임대료/연장'은 사업비 성격의 '기타'로, '비계'는 '구조물'로 연결하는 등 건설 실무 상식을 추론에 반영한다.
|
|
|
|
### 5단계: 최종 지도 매칭 (Hierarchy Mapping)
|
|
- 수집된 모든 정보를 종합하여 사용자가 정의한 **표준 분류 체계(Tab > Category > Sub)** 지도 위에서 가장 논리적이고 실무적인 위치를 최종 확정한다.
|
|
|
|
---
|
|
|
|
# 🛠️ 개발 및 관리 규칙 (Strict Development Rules)
|
|
|
|
1. **언어 설정**: 영어로 생각하되, 모든 답변은 **한국어**로 작성한다.
|
|
2. **임의 수정 절대 금지 (Zero-Arbitrary Change)**:
|
|
- 사용자가 명시적으로 지시한 부분 외에는 **단 한 줄의 코드도, 그 어떤 파일도 임의로 수정, 정리, 리팩토링하지 않는다.**
|
|
- 지시받지 않은 다른 파트의 코드는 절대 건드리지 않으며, 영향 범위가 요청 범위를 벗어나지 않도록 '외과 수술식(Surgical) 수정'을 원칙으로 한다.
|
|
3. **개선 작업 절차 (Test-First Approach)**:
|
|
- 사용자가 개선(Refactoring, Optimization 등)을 지시한 경우, **수정 전 현재 시스템이 정상적으로 잘 작동하는지 먼저 전수 확인**한다.
|
|
- 기존 동작 방식과 성능을 기준(Baseline)으로 삼고, 수정 후에도 **기존의 모든 기능이 무결하게 유지되는지 반드시 테스트하여 입증**한다.
|
|
- 검증 결과를 바탕으로 "무엇을, 왜, 어떻게" 바꿀지 상세 보고 후, 사용자로부터 **'진행시켜'** 승인을 얻은 뒤에만 집행한다.
|
|
4. **선보고 후승인**: 모든 기능 수정 및 코드 변경 전에는 예상 방안을 먼저 보고하고 승인 절차를 거친다.
|
|
5. **로그 기록 철저**: 진행 상황(로그인, 수집, 오류 등)을 실시간 로그에 상세히 표시하여 투명성을 확보한다.
|
|
|
|
---
|
|
|
|
## 🎨 디자인 가이드 (Design System)
|
|
|
|
이 프로젝트는 `tokens.json`에 정의된 디자인 시스템을 준수합니다.
|
|
|
|
### 1. 컬러 시스템 (Colors)
|
|
- **Primary**: `#1E5149` (primary-lv-6) - 브랜드 핵심 컬러
|
|
- **Background**: `#FFFFFF` (Light Default) / `#F9FAFB` (Light Muted)
|
|
- **Point Colors**:
|
|
- Blue: `#0D8DF2` (Info)
|
|
- Green: `#4DB251` (Success)
|
|
- Red: `#F21D0D` (Error)
|
|
- Yellow: `#FFBF00` (Warning)
|
|
- **Special**: `ai_color` (Purple-Blue Gradient) - AI 관련 요소 전용
|
|
|
|
### 2. 타이포그래피 (Typography)
|
|
- **Font Family**: `Pretendard`, `sans-serif`
|
|
- **Scale**:
|
|
- **H1**: 20px / ExtraBold (pretendard-0)
|
|
- **H2**: 16px / SemiBold (pretendard-1)
|
|
- **H3/H4**: 14px / SemiBold or Regular
|
|
- **Body/P**: 12px / Regular (pretendard-2)
|
|
|
|
### 3. 레이아웃 및 간격 (Dimensions)
|
|
- **Spacing Unit**: Base 4px (xs: 4px, sm: 8px, md: 16px, lg: 32px, xl: 64px)
|
|
- **Border Radius**: sm: 4px, lg: 8px, xl: 16px
|
|
- **Shadow**: `0 8px 24px rgba(0,0,0,0.16)` (box__drop-shadow)
|
|
|
|
### 4. 컴포넌트 규칙
|
|
- **Buttons**: `borderRadius.lg (8px)` 적용, Primary 배경색 사용
|
|
- **Cards**: `borderRadius.lg (8px)` 적용, Subtle Shadow 활용
|
|
- **Topbar**: Height 36px, `headercolor` 그라데이션 적용 가능
|
|
|