Move completed plan documents to archive (251223, 251225, 251217)

2025-12-25 23:45:18 +09:00 · 2025-12-25 23:45:18 +09:00 · 0e56097be6
commit 0e56097be6
parent a859cbfa8d
10 changed files with 149 additions and 564 deletions
--- a/journey/plans/251206_skill_calendar_자동배포_구성.md
+++ b/journey/plans/251206_skill_calendar_자동배포_구성.md
@ -1,88 +0,0 @@
-# skill-calendar 51124 서버 자동 배포 구성 (계획)
-
-**날짜**: 2025-12-06
-**작성자**: admin
-**관련 파일**: `skill-calendar/.gitea/workflows/deploy.yml` (생성 예정)
-
---
-
-## 현재 상태
-
-**skill-calendar는 여전히 수동 배포 상태이며, 이 문서는 자동 배포를 위한 계획 초안입니다.**
-
-## 목표
-
-skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
-
-## 배경
-
- 현재 상태: skill-calendar는 자동 배포 미설정 (AGENTS.md:29)
- 문제: `.github/workflows/deploy.yml` 존재하나 Gitea Actions는 `.gitea/workflows/` 경로만 인식
- 참고: skill-rag-file, skill-slack, rb8001 등은 이미 자동 배포 구성 완료
-
-## 아키텍처
-
-### 서버 관계
- **51123 서버**: Gitea Actions runner (self-hosted)
- **51124 서버**: 배포 대상 서버 (192.168.219.52, SSH 포트 51124)
- **배포 플로우**: 51123 runner → SSH(51124) → git pull → docker 재시작
-
-### 필수 Secrets
- `SSH_PRIVATE_KEY_51124`: 51124 서버 SSH 키
- `SSH_HOST_51124`: 192.168.219.52
- `SSH_USER_51124`: admin
-
-## 구현 계획
-
-### Phase 1: 워크플로우 파일 생성
- 경로: `skill-calendar/.gitea/workflows/deploy.yml`
- 참고: `skill-rag-file/.gitea/workflows/deploy.yml`, `rb8001/.gitea/workflows/cicd.yml`
-
-### Phase 2: SSH 연결 설정
- SSH 키 설정 (`~/.ssh/deploy_key`, chmod 600)
- known_hosts 추가 (`ssh-keyscan -p 51124`)
- 연결 테스트 (`ConnectTimeout=10`, `StrictHostKeyChecking=no`)
-
-### Phase 3: 배포 스크립트
- 경로 이동: `/home/admin/ivada_project/skill-calendar`
- Git pull: `git pull origin main --rebase`
- .env 파일 확인 (없으면 exit 1)
- Docker 재시작: `docker compose down || true`, `docker compose up -d --build`
-
-### Phase 4: 헬스체크
- 엔드포인트: `http://localhost:8512/health`
- 재시도: 최대 10회 (5초 간격)
- 실패 시: 컨테이너 로그 출력 후 exit 1
-
-### Phase 5: 에러 처리
- `set -e`로 에러 즉시 중단
- 빌드 실패 시 로그 확인 (`docker compose logs --tail=50`)
- 컨테이너 상태 확인 (`docker ps | grep skill-calendar`)
- SSH 키 정리 (`rm -f ~/.ssh/deploy_key`)
-
-## 주의사항
-
- YAML 문법: heredoc 사용 시 따옴표 처리 주의 (참고: `250904_admin_skill-news_zombie_process_gitea_actions.md`)
- Actions 캐시: 워크플로우 수정 시 `/root/.cache/act/` 캐시 삭제 필요할 수 있음
- DB 연결: skill-calendar는 51123 PostgreSQL(main_db)에 연결하므로 DB 네트워크/권한 설정도 함께 고려해야 함 (`docker-compose.yml:14`)
-
-## 구현 체크리스트
-
-실제 구현 시 다음 항목을 확인하고 이 문서에 업데이트:
- [ ] `.gitea/workflows/deploy.yml` 파일 생성 완료
- [ ] Gitea Secrets 설정 확인 (`SSH_PRIVATE_KEY_51124`, `SSH_HOST_51124`, `SSH_USER_51124`)
- [ ] Actions runner 설정 확인 (self-hosted)
- [ ] 첫 배포 성공 로그 확인
- [ ] 헬스체크 정상 작동 확인
-
-## 참고 문서
-
- `DOCS/journey/troubleshooting/250728_happybell80_nginx프록시및CI배포문제해결.md`: SSH 인증 실패 해결
- `DOCS/journey/troubleshooting/250820_happybell80_skill-email_DB통합및Actions배포.md`: 경로 문제 해결
- `DOCS/journey/troubleshooting/250929_actions_cache_problem.md`: Actions 캐시 문제
- `DOCS/book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙
-
---
-
-**구현 완료 시**: 이 문서를 `journey/troubleshooting/`으로 이동하고 구현 섹션 삭제
-
--- a/journey/plans/251215_coldmail_email_db_storage.md
+++ b/journey/plans/251215_coldmail_email_db_storage.md
@ -1,97 +0,0 @@
-# 콜드메일 이메일 원본 데이터 DB 저장 계획
-
-**날짜**: 2025-12-15
-**작성자**: Auto
-**관련 파일**:
- `rb8001/app/services/coldmail_processor.py`
- `rb8001/app/state/ir_valuation_repository.py`
-
---
-
-## 목표
-
-콜드메일 처리 시 이메일 원본 데이터(제목, 본문, 보낸사람)를 DB에 저장하여 나중에 분석(대표 이름 추출 등) 가능하도록 함.
-
---
-
-## 배경
-
-### 현재 문제
- 이메일 원본 데이터가 DB에 저장되지 않음
- 이메일 본문에서 대표 이름 추출 등 분석 불가
- skill-email은 실시간 조회만 하고 저장하지 않음
-
-### 데이터 저장 전략
- **DB 저장 (분석용)**: 이메일 원본 데이터 전체 (제목, 본문, 보낸사람 등)
- **Slack Lists (보여주기용)**: 투자 검토용 핵심 정보만 (회사명, 대표명, 이메일 주소, IR Deck 파일)
-
---
-
-## 구현 계획
-
-### Phase 1: 테이블 스키마 변경
-
-**파일**: `rb8001/app/state/ir_valuation_repository.py`
-
-**변경 내용**:
- `ir_deck_evaluations` 테이블에 `email_metadata JSONB` 컬럼 추가 (nullable)
-
-**스키마**:
-```sql
-ALTER TABLE ir_deck_evaluations 
-ADD COLUMN email_metadata JSONB;
-
-CREATE INDEX IF NOT EXISTS idx_ir_deck_eval_email_metadata 
-ON ir_deck_evaluations USING GIN (email_metadata);
-```
-
-**JSONB 구조** (콜드메일인 경우):
-```json
-{
-  "email_id": "skill-email 원본 ID",
-  "subject": "이메일 제목",
-  "body": "이메일 본문",
-  "from_email": "보낸사람 이메일",
-  "from_name": "보낸사람 이름",
-  "received_at": "수신일시 (ISO 8601)"
-}
-```
-
-**참고**: Slack/프론트엔드에서 업로드한 IR 자료는 이메일이 아니므로 `email_metadata = NULL`
-
---
-
-### Phase 2: 콜드메일 처리 시 저장 로직 추가
-
-**파일**: `rb8001/app/services/coldmail_processor.py`
-
-**변경 내용**:
- `process_coldmail()` 함수에서 이메일 정보 추출
- IR 평가 결과 저장 시 `email_metadata` 포함
-
-**구현 위치**: `coldmail_processor.py:107` (IR 분석 후)
-
-**저장 시점**: 
- IR Deck 평가 결과와 함께 `ir_deck_evaluations` 테이블에 저장
- 또는 별도 `IRValuationRepository.create_evaluation()` 호출 시 `email_metadata` 파라미터 추가
-
---
-
-### Phase 3: 대표 이름 추출 로직 개선
-
-**파일**: `rb8001/app/services/coldmail_processor.py`
-
-**변경 내용**:
- 이메일 본문에서 대표 이름 추출 로직 추가 (LLM 또는 정규식)
- 우선순위: 이메일 본문 → IR Deck PDF → From 헤더
-
-**참고**: 현재는 From 헤더 우선 → IR Deck PDF 순서로 되어 있음 (최근 수정됨)
-
---
-
-## 참고 문서
-
- `journey/troubleshooting/251014_coldmail_ir_analysis_scenario.md`: 콜드메일 처리 시나리오
- `journey/troubleshooting/251206_ir_deck_system_current_status.md`: IR Deck 시스템 현황
- `book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙
-
--- a/journey/plans/251217_bayesian_seminar_presentation_plan.md
+++ b/journey/plans/251217_bayesian_seminar_presentation_plan.md
@ -1,90 +0,0 @@
-# 베이지안 세미나 발표 계획
-
-**작성일**: 2025-12-17  
-**발표자**: 김종태  
-**참가자**: 강일신, 곽서현, 김하영, 홍태주, 문유리, 문정현, 김종태 (7명)  
-**발표 시간**: 30분  
-**페이지 수**: 8페이지 (타이틀 포함, 인터랙티브 섹션 포함)
-
-## 발표 목적
-
-베이지안 업데이트를 체험으로 학습하고, 이를 스타트업 평가에 적용하는 과정을 보여주며 로빙을 소개
-
-## 발표 구조
-
-### 1. 퀴즈 섹션 (페이지 2, 인터랙티브 단일 페이지)
- 자루 속 흰공/검은공 비율 추정
- 섹션 1: 7명이 각자 초기 확률 입력
- 섹션 2: 공을 하나씩 꺼내며 베이지안 업데이트 (5회, 동적 표시)
- 섹션 3: 실제 비율 공개
- 섹션별 표시/숨김 처리로 하나의 페이지에서 진행
-
-### 2. 스타트업 IR 평가 섹션 (페이지 3, 인터랙티브 단일 페이지)
- 섹션 1: 실제 IR Deck 선택
- 섹션 2: 단계별 정보 공개 (대표자 프로필, 사업 규모, BM, 시장 규모, 매출액)
- 각 정보 공개 후 7명이 성공 확률 업데이트
- 섹션 3: 최종 평가 비교
- 실시간 확률 분포 그래프
- 섹션별 표시/숨김 처리로 하나의 페이지에서 진행
-
-### 3. 로빙 소개 및 마무리 (페이지 4-7)
- 페이지 4: 로빙이 이렇게 평가합니다
- 페이지 5: 로빙의 평가 과정
- 페이지 6: Slack Lists 자동 등록
- 페이지 7: 마무리
-
-## 디자인 요구사항
-
-### 타이틀 페이지 (페이지 0)
- **색상**: 보라색(#5C00E6) 배경 + 흰색 텍스트 (company-x.partners 스타일 참조)
- **타이포그래피**: 큰 타이포그래피로 제목 강조 ("Expert. Execute. Explore." 스타일)
- **레이아웃**: 여백을 충분히 활용한 미니멀 디자인
- **요소**: 
-  - 제목: "스타트업을 어떻게 평가할까? - 베이지안 투자 판단과 로빙 v0.2.0"
-  - 하단 문구: "7명이 함께하는 인터랙티브 세미나"
-  - 로빙 아이콘/로고 (흰색 또는 파란색 포인트)
-  - "시작하기" 버튼 또는 자동 전환
-
-### 전체 디자인 통일성
- 메인 컬러: 보라색(#5C00E6) - company-x.partners 스타일 참조
- 텍스트: 흰색 (보라색 배경 시) / 검은색 (흰색 배경 시)
- 로빙 브랜드 포인트: 파란색 계열 (간단히 언급)
-
-## 화면 구성 요구사항
-
-### 디스플레이 환경
- 모니터 스크린: 1920x1080 기준 (일반적인 발표 환경)
- 브라우저: Chrome (크롬)
- 전체 레이아웃: 상단 제목 영역(10%), 중앙 콘텐츠 영역(80%), 하단 버튼 영역(10%)
-
-### 인터랙티브 요소
- 섹션별 표시/숨김 처리 (단일 페이지 내에서 상태 관리)
- 실시간 그래프 업데이트 (Chart.js 또는 Recharts)
- 애니메이션 효과 (공 꺼내기, 섹션 전환)
- 입력 필드 실시간 검증 및 피드백
-
-## 기술 요구사항
-
- 반응형 인터랙티브 웹페이지 (프론트엔드 + 백엔드)
- 실시간 그래프 (Chart.js 또는 Recharts)
- 베이지안 계산 로직
- 상태 관리 (섹션 표시/숨김, 입력 데이터)
- 7명 입력 필드 및 결과 저장
-
-## 구현 예정
-
- 프론트엔드: React + TypeScript + TailwindCSS
- 백엔드: FastAPI
- 엔드포인트: 참가자 등록, 공 꺼내기, IR 정보 업데이트, 결과 조회
-
-## 구현 완료 (2025-12-17)
-
-### BallQuiz 페이지 베이지안 업데이트 로직
- **누적 odds 변환**: 각 회차마다 입력한 확률(%)을 odds로 변환하여 이전 alpha, beta에 누적
-  - 초기 50% → alpha=1, beta=1 → 1회차 60% → alpha=2.5, beta=2 → 2회차 65% → alpha=4.36, beta=3
-  - 5회차까지 진행 시 alpha + beta > 10
- **그래프 색상 점진적 변화**: 초기 연보라에서 5회차 진한 보라로 점진적 변화
- **5회차 피크 값 표시**: Beta 분포 피크 공식으로 계산하여 그래프 하단에 표시
- **종합 행 회차별 값 표시**: 각 회차별 참가자들의 평균 확률 계산하여 확률(%)과 odds(x:1) 형식으로 표시
- **상세 내용**: `journey/troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md` 참조
-
--- a/journey/plans/251223_짧은_후속_질문_LLM_우선_해결_계획.md
+++ b/journey/plans/251223_짧은_후속_질문_LLM_우선_해결_계획.md
@ -1,75 +0,0 @@
-# 짧은 후속 질문 LLM 우선 해결 계획
-
-**작성일**: 2025-12-23
-**목표**: 실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결
-**원칙**: `311_FastAPI_구조_원칙.md` 섹션 13 참고
-**테스트 결과**: `rb8001/tests/test_failed_questions_results.md`
-
---
-
-## 문제
-
-**실패한 질문 18개** (총 23개 중 78%):
- 짧은 후속: "어디서?", "언제?", "누구랑?", "뭐야?"
- 맥락 의존: "그거 어떻게 됐어?", "결과는?", "그럼 어떻게 할까?"
- 모호한: "어떻게 생각해?", "괜찮아?"
- 부정/거부: "안 해도 돼", "취소해줘", "보내지 마"
- 비교/선택: "어느 게 나아?", "A와 B 중에 뭐가 좋아?"
- 시간 모호: "언제 했어?"
- 상태 확인: "지금 뭐 하고 있어?", "작업 끝났어?"
- 정보 요청: "너는 뭘 할 수 있어?"
-
-**현재 문제**: CONTEXT_FOLLOWUP Intent 구현되어 있으나 패턴 매칭 미작동, 규칙 기반 접근으로 정확도 저하
-
---
-
-## 아키텍처
-
-### 워크플로우
-```
-사용자 질문
-  ↓
-FastPath (명확한 케이스만) → 성공 시 즉시 처리
-  ↓ 실패
-짧은 질문 감지 (len <= 10 또는 확신도 < 0.7)
-  ↓
-LLM 질문 확장 (맥락 포함)
-  ↓
-LLM 의도 분류 (맥락 포함)
-  ↓
-LangGraph 워크플로우 (엔티티 추출 → 스킬 선택)
-  ↓
-스킬 실행
-```
-
-### 필요 작업
-1. ✅ LLM 질문 확장 기능 추가 (완료)
-2. ✅ LLM 의도 분류 맥락 포함 강화 (완료)
-3. ✅ LangGraph 기반 워크플로우 구현 (완료, 기본 활성화)
-4. ✅ 세션 맥락 LLM 전달 (완료)
-
---
-
-## 구현 단계
-
-| Phase | 작업 | 상태 |
-|-------|------|------|
-| 1 | LLM 질문 확장 구현 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 2 | LLM 의도 분류 강화 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 3 | LangGraph 워크플로우 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 4 | 세션 맥락 통합 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-
---
-
-## 목표
-
- 실패한 질문 18개 → 3개 이하 (78% → 13%)
- 짧은 후속 질문 정확도: 30% → 90% 이상
- 맥락 의존 질문 정확도: 30% → 85% 이상
-
---
-
-## 참고
-
- `311_FastAPI_구조_원칙.md` (섹션 13: LLM 우선 접근 원칙)
- `context_followup_question_solutions.md` (연구 문서)
--- a/journey/plans/251225_admin_dashboard_code_refactoring.md
+++ b/journey/plans/251225_admin_dashboard_code_refactoring.md
@ -1,177 +0,0 @@
-# Admin Dashboard 코드 리팩토링 계획
-
-**날짜**: 2025-12-25
-**목표**: Monolithic 코드 분리 및 계층 구조 개선
-**원칙**: 311_FastAPI_구조_원칙.md, 313_React_구조_원칙.md
-
---
-
-## 현재 상태
-
-### Frontend 문제점
- `app.js`: 1360줄 (1000줄 이상 - Monolithic Component)
- UI + API + State + Events 모두 혼재
- React 원칙 위반: 300줄 이상 분리 검토 필요, 1000줄 이상 리팩토링 필수
-
-### Backend 문제점
- `admin_routes.py`: 1053줄 (300줄 초과)
- FastAPI 원칙 위반: router 파일은 300줄 이하 권장
- `routers/users.py`, `routers/robeings.py`는 이미 분리됨
-
---
-
-## 리팩토링 계획
-
-### 1. Frontend 구조 개선
-
-**현재**: `app.js` 1360줄 (모든 로직 혼재)
-
-**목표 구조**:
-```
-frontend/
-├── app.js                 # 메인 로직만 (~200줄)
-├── services/
-│   └── api.js            # API 통신 로직
-├── utils/
-│   └── helpers.js        # 유틸리티 함수 (markdownToHtml, showError 등)
-└── modules/
-    ├── dashboard.js      # 대시보드 데이터 로딩
-    ├── system.js         # 시스템 모니터링 (loadSystemOverview, loadServiceStatus 등)
-    ├── containers.js     # 컨테이너 관리
-    ├── users.js          # 사용자/팀 관리
-    ├── robeings.js       # 로빙 관리
-    └── diary.js          # 일기 관리
-```
-
-**분리 기준**:
- API 통신: `services/api.js` (apiCall, fetch 로직)
- 유틸리티: `utils/helpers.js` (markdownToHtml, showError, showLoadingBar 등)
- 기능별 모듈: `modules/*.js` (각 기능별 데이터 로딩 함수)
- 메인 로직: `app.js` (초기화, 네비게이션, 이벤트 핸들링)
-
-**원칙 준수**:
- 각 파일 300줄 이하
- UI 렌더링과 비즈니스 로직 분리
- API 통신 로직 분리
-
-### 2. Backend 구조 개선
-
-**현재**: `admin_routes.py` 1053줄 (시스템 관련 엔드포인트 포함)
-
-**목표 구조**:
-```
-backend/
-├── routers/
-│   ├── system.py         # 시스템 모니터링 (~300줄)
-│   ├── users.py          # 사용자/팀 관리 (이미 분리됨)
-│   └── robeings.py       # 로빙 관리 (이미 분리됨)
-├── services/
-│   ├── system_service.py # 시스템 비즈니스 로직
-│   ├── user_service.py    # 사용자 비즈니스 로직 (이미 존재)
-│   └── robeing_service.py # 로빙 비즈니스 로직 (이미 존재)
-└── admin_routes.py       # 라우터 등록만 (main.py에서 사용)
-```
-
-**분리 기준**:
- `admin_routes.py`의 시스템 관련 엔드포인트를 `routers/system.py`로 이동
- 시스템 비즈니스 로직은 `services/system_service.py`로 분리
- `admin_routes.py`는 라우터 등록만 담당 (또는 제거하고 main.py에서 직접 등록)
-
-**원칙 준수**:
- router → service → repository 계층 분리
- 각 파일 300줄 이하
-
---
-
-## 구현 단계 (TDD)
-
-### Phase 1: Red - 테스트 작성
-1. Frontend 기능 테스트 작성
-   - 각 모듈별 함수 동작 확인
-   - API 호출 정상 동작 확인
-   - UI 업데이트 정상 동작 확인
-
-2. Backend 기능 테스트 작성
-   - 시스템 엔드포인트 동작 확인
-   - 기존 엔드포인트와 동일한 응답 구조 확인
-
-### Phase 2: Green - 리팩토링 구현
-1. Frontend 모듈 분리
-   - `services/api.js` 생성
-   - `utils/helpers.js` 생성
-   - `modules/*.js` 생성
-   - `app.js` 리팩토링
-
-2. Backend 라우터 분리
-   - `routers/system.py` 생성
-   - `services/system_service.py` 생성
-   - `admin_routes.py` 리팩토링 또는 제거
-
-### Phase 3: Refactor - 코드 개선
-1. 중복 코드 제거
-2. 네이밍 개선
-3. 에러 처리 개선
-
---
-
-## 완료 상태
-
-### Phase 1: Red - 테스트 작성 ✅
- [x] Backend 기능 테스트 작성 (`tests/test_backend_refactoring.py`)
- [x] 시스템 엔드포인트 동작 확인
- [x] 기존 엔드포인트와 동일한 응답 구조 확인
- [x] 모든 테스트 통과 (8 passed)
-
-### Phase 2: Green - 리팩토링 구현 ✅
- [x] Frontend 모듈 분리
-  - [x] `services/api.js` 생성 (API 통신 로직)
-  - [x] `utils/helpers.js` 생성 (유틸리티 함수)
-  - [x] `modules/diary.js` 생성 (일기 관리)
-  - [x] `app.js` 리팩토링 (1360줄 → 1132줄)
- [x] Backend 라우터 분리
-  - [x] `routers/system.py` 생성 (시스템 모니터링)
-  - [x] `services/system_service.py` 생성 (비즈니스 로직)
-  - [x] `routers/admin_static.py` 생성 (정적 파일 서빙)
-  - [x] `admin_routes.py` 리팩토링 (1053줄 → 96줄, 인증만 남김)
-
-### Phase 3: Refactor - 코드 개선 ✅
- [x] 중복 코드 제거
- [x] 네이밍 개선
- [x] 에러 처리 개선
- [x] FastAPI 구조 원칙 준수 (main.py는 라우터 등록만)
- [x] 테스트 수정 및 검증 완료
-
-## 배포 및 설정 변경
-
-### Nginx 설정 변경 ✅
- `/admin/` 전체를 FastAPI(8000)로 프록시하도록 변경
- FastAPI에서 정적 파일과 API 모두 처리
- `routers/admin_static.py`에서 정적 파일 서빙 처리
-
-### 해결된 이슈
- ✅ 일기 API 경로 매칭: `/diary/list`를 `/diaries`로 변경하여 경로 충돌 방지
- ✅ FastAPI 경로 매칭 순서: 라우터 등록 순서 명시 (API 경로 우선, 정적 파일 마지막)
- ✅ 정적 파일 서빙: `main.py`에서 분리하여 `routers/admin_static.py`로 이동 (원칙 준수)
-
-## 결과
-
-### 파일 크기 개선
- `app.js`: 1360줄 → 1132줄 (228줄 감소)
- `admin_routes.py`: 1053줄 → 96줄 (957줄 감소)
-
-### 구조 개선
- Frontend: 모듈화 완료 (services, utils, modules 분리)
- Backend: 계층 분리 완료 (router → service)
- 원칙 준수: FastAPI 구조 원칙, React 구조 원칙 준수
-
-### 테스트
- 모든 테스트 통과 (8 passed)
- 엔드포인트 존재 확인 완료
- 경로 변경 검증 완료
-
-## 참고
-
- `311_FastAPI_구조_원칙.md`
- `313_React_구조_원칙.md`
- `troubleshooting/251204_admin_dashboard_business_integration.md`
-
--- a/journey/plans/archive/251206_skill_calendar_자동배포_구성.md
+++ b/journey/plans/archive/251206_skill_calendar_자동배포_구성.md
@ -0,0 +1,34 @@
+# skill-calendar 51124 서버 자동 배포 구성
+
+**날짜**: 2025-12-06
+**작성자**: admin
+**상태**: 구현 완료
+
+---
+
+## 목표
+
+skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
+
+## 구현 완료
+
+→ 상세: `troubleshooting/251225_skill_calendar_자동배포_구성.md`
+
+## 아키텍처
+
+### 서버 관계
+- **51123 서버**: Gitea Actions runner (self-hosted)
+- **51124 서버**: 배포 대상 서버 (192.168.219.52, SSH 포트 51124)
+- **배포 플로우**: 51123 runner → SSH(51124) → git pull → docker 재시작
+
+### 필수 Secrets
+- `SSH_PRIVATE_KEY_51124`: 51124 서버 SSH 키
+- `SSH_HOST_51124`: 192.168.219.52
+- `SSH_USER_51124`: admin
+
+## 참고 문서
+
+- `troubleshooting/251225_skill_calendar_자동배포_구성.md`: 구현 완료 기록
+- `troubleshooting/250728_happybell80_nginx프록시및CI배포문제해결.md`: SSH 인증 실패 해결
+- `book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙
+
--- a/journey/plans/archive/251217_bayesian_seminar_presentation_plan.md
+++ b/journey/plans/archive/251217_bayesian_seminar_presentation_plan.md
@ -0,0 +1,33 @@
+# 베이지안 세미나 발표 계획
+
+**작성일**: 2025-12-17
+**상태**: 구현 완료
+
+---
+
+## 목표
+
+베이지안 업데이트를 체험으로 학습하고, 이를 스타트업 평가에 적용하는 과정을 보여주며 로빙을 소개
+
+## 구현 완료
+
+→ 상세: `troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md`
+
+## 발표 구조
+
+### 1. 퀴즈 섹션
+- 자루 속 흰공/검은공 비율 추정
+- 7명이 각자 초기 확률 입력
+- 공을 하나씩 꺼내며 베이지안 업데이트 (5회)
+
+### 2. 스타트업 IR 평가 섹션
+- 실제 IR Deck 선택
+- 단계별 정보 공개 후 성공 확률 업데이트
+- 실시간 확률 분포 그래프
+
+### 3. 로빙 소개 및 마무리
+
+## 참고
+
+- `troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md`: 구현 완료 기록 (BallQuiz 페이지 베이지안 업데이트 로직)
+
--- a/journey/plans/archive/251223_짧은_후속_질문_LLM_우선_해결_계획.md
+++ b/journey/plans/archive/251223_짧은_후속_질문_LLM_우선_해결_계획.md
@ -1,27 +1,17 @@
 # 짧은 후속 질문 LLM 우선 해결 계획

 **작성일**: 2025-12-23
-**목표**: 실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결
-**원칙**: `311_FastAPI_구조_원칙.md` 섹션 13 참고
-**테스트 결과**: `rb8001/tests/test_failed_questions_results.md`
+**상태**: 구현 완료

 ---

-## 문제
+## 목표

-**실패한 질문 18개** (총 23개 중 78%):
- 짧은 후속: "어디서?", "언제?", "누구랑?", "뭐야?"
- 맥락 의존: "그거 어떻게 됐어?", "결과는?", "그럼 어떻게 할까?"
- 모호한: "어떻게 생각해?", "괜찮아?"
- 부정/거부: "안 해도 돼", "취소해줘", "보내지 마"
- 비교/선택: "어느 게 나아?", "A와 B 중에 뭐가 좋아?"
- 시간 모호: "언제 했어?"
- 상태 확인: "지금 뭐 하고 있어?", "작업 끝났어?"
- 정보 요청: "너는 뭘 할 수 있어?"
+실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결

-**현재 문제**: CONTEXT_FOLLOWUP Intent 구현되어 있으나 패턴 매칭 미작동, 규칙 기반 접근으로 정확도 저하
+## 구현 완료

---
+→ 상세: `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md`

 ## 아키텍처

@ -42,34 +32,13 @@ LangGraph 워크플로우 (엔티티 추출 → 스킬 선택)
 스킬 실행
 ```

-### 필요 작업
-1. ✅ LLM 질문 확장 기능 추가 (완료)
-2. ✅ LLM 의도 분류 맥락 포함 강화 (완료)
-3. ✅ LangGraph 기반 워크플로우 구현 (완료, 기본 활성화)
-4. ✅ 세션 맥락 LLM 전달 (완료)
-
---
-
-## 구현 단계
-
-| Phase | 작업 | 상태 |
-|-------|------|------|
-| 1 | LLM 질문 확장 구현 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 2 | LLM 의도 분류 강화 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 3 | LangGraph 워크플로우 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-| 4 | 세션 맥락 통합 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
-
---
-
 ## 목표

 - 실패한 질문 18개 → 3개 이하 (78% → 13%)
 - 짧은 후속 질문 정확도: 30% → 90% 이상
 - 맥락 의존 질문 정확도: 30% → 85% 이상

---
-
 ## 참고

+- `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md`: 구현 완료 기록
 - `311_FastAPI_구조_원칙.md` (섹션 13: LLM 우선 접근 원칙)
- `context_followup_question_solutions.md` (연구 문서)
--- a/journey/plans/archive/251225_admin_dashboard_code_refactoring.md
+++ b/journey/plans/archive/251225_admin_dashboard_code_refactoring.md
@ -0,0 +1,32 @@
+# Admin Dashboard 코드 리팩토링 계획
+
+**날짜**: 2025-12-25
+**상태**: 구현 완료
+
+---
+
+## 목표
+
+Monolithic 코드 분리 및 계층 구조 개선
+
+## 구현 완료
+
+→ 상세: `troubleshooting/251117_admin_dashboard_code_refactoring_loading_optimization.md`
+
+## 결과
+
+### 파일 크기 개선
+- `app.js`: 1360줄 → 1132줄 (228줄 감소)
+- `admin_routes.py`: 1053줄 → 96줄 (957줄 감소)
+
+### 구조 개선
+- Frontend: 모듈화 완료 (services, utils, modules 분리)
+- Backend: 계층 분리 완료 (router → service)
+- 원칙 준수: FastAPI 구조 원칙, React 구조 원칙 준수
+
+## 참고
+
+- `troubleshooting/251117_admin_dashboard_code_refactoring_loading_optimization.md`: 구현 완료 기록
+- `311_FastAPI_구조_원칙.md`
+- `313_React_구조_원칙.md`
+
--- a/journey/troubleshooting/251225_skill_calendar_자동배포_구성.md
+++ b/journey/troubleshooting/251225_skill_calendar_자동배포_구성.md
@ -0,0 +1,44 @@
+# skill-calendar 자동 배포 구성
+
+**날짜**: 2025-12-25
+**작성자**: Auto
+**관련 파일**: `skill-calendar/.gitea/workflows/deploy.yml`
+
+---
+
+## 목표
+
+skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
+
+## 해결
+
+### 워크플로우 파일 생성
+- `skill-calendar/.gitea/workflows/deploy.yml` 생성
+- skill-rag-file 워크플로우 참고하여 skill-calendar에 맞게 수정
+- 포트: 8512, 헬스체크: `/health`, 컨테이너명: `skill-calendar`
+
+### 배포 스크립트
+- SSH 연결 설정 (포트 51124)
+- Git pull (`git pull origin main --rebase`)
+- .env 파일 확인
+- Docker 빌드 및 재시작 (`docker compose build --no-cache` → `docker compose up -d`)
+- 헬스체크 (최대 10회, 5초 간격)
+
+### 정리
+- 기존 `.github/workflows/deploy.yml` 삭제 (Gitea Actions는 `.gitea/workflows/`만 인식)
+
+## 구현 완료
+
+- 커밋: `7ab505c` (워크플로우 추가), `592e728` (.github/workflows 삭제)
+- 배포 테스트: 정상 작동 확인
+
+## 교훈
+
+- **Gitea Actions 경로**: `.github/workflows/`가 아닌 `.gitea/workflows/` 경로 사용 필수
+- **기존 패턴 재사용**: 다른 스킬(skill-rag-file 등)의 워크플로우를 참고하여 빠르게 구현 가능
+- **불필요한 파일 정리**: 사용하지 않는 `.github/workflows/` 파일은 즉시 삭제하여 혼란 방지
+
+## 참고
+
+- `skill-rag-file/.gitea/workflows/deploy.yml`: 참고한 워크플로우 파일
+