docs: 계획 문서 보강 — 리서치 결과 기반 현재 상태·Phase 1~2 갱신

- 현재 상태를 리서치 링크 기반으로 갱신 (약 40개 → 24건 확정)
- Phase 1 완료 항목 표시
- Phase 2 실행 경로를 리서치 §6, §9 링크로 구체화
- SSOT 원칙: 상세는 리서치에만 두고 계획은 링크+요약

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

journey/plans/251225_프롬프트_동적관리_계획.md

@@ -35,14 +35,14 @@
 
 ---
 
-## 2. 현재 상태 요약 (2026-03-03 기준)
+## 2. 현재 상태 요약 (2026-03-19 갱신)
 
-- rb8001 코드 하드코딩 프롬프트 템플릿: 약 40개
-- 사용자 핵심 UX 경로 프롬프트 유형: 약 8~10종
-  - chat(감정 반영), summarize, analyze, extract, calendar_confirm 등
+- 하드코딩 프롬프트: **24건** 확인 (P1: 3건, P2: 8건, P3: 13건). 상세 인벤토리·gap 분석은 [전수 조사 리서치](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md) §3~5 참조.
+- DB 골격(테이블·API·추적): 구현 완료. 운영 프롬프트 DB 적재: **0건**.
+- 폐루프: 미연결. 주입 방식은 리서치 §6에서 확정 (`process_request()` 진입 시 `context` 주입, 기존 RAG 검증 패턴 재사용).
 - 현재 문제:
   - 프롬프트 수정 시 코드 배포 필요
-  - 버전/실험/성과 추적이 일관되지 않음
+  - DB 버전을 바꿔도 실제 응답에 반영 안 됨
   - 회귀 시 신속 롤백이 어려움
 
 ---
@@ -197,16 +197,15 @@
 ## 7. 구현 단계
 
 ### Phase 1: 인벤토리/스키마/TDD
-- 하드코딩 프롬프트 인벤토리 확정(파일/함수/용도)
-- `prompt_templates`, `prompt_versions` 생성
-- Repository + Service 뼈대 구현
-- 테스트:
-  - 스키마 생성/마이그레이션
-  - 버전 조회/활성 버전 선택
+- ~~하드코딩 프롬프트 인벤토리 확정(파일/함수/용도)~~ → **완료** (2026-03-19, 24건. [리서치 §3](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md))
+- `prompt_templates`, `prompt_versions` 생성 → **완료** (`prompt_management_repository.py`)
+- Repository + Service 뼈대 구현 → **완료** (`prompt_db_endpoint.py`, `message_tracking_service.py`)
+- 테스트: 스키마 생성/버전 조회/활성 버전 선택 → **완료**
 
 ### Phase 2: 읽기 경로 전환 (safe fallback)
-- `llm_service.py`, `gemini_handler.py`에 DB 조회 연결
-- 기존 하드코딩은 fallback로 유지
+- `llm_service.py`의 `process_request()` 진입 시 DB 활성 프롬프트 조회 → `context['system_instruction']` + `context['skip_default_prompt']` 주입. 상세는 [리서치 §6](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md).
+- 캐싱: 모듈 레벨 dict, TTL 60초. 상세는 [리서치 §9](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md).
+- 기존 하드코딩은 fallback로 유지 (`safe_prod` 모드)
 - 테스트:
   - DB 성공 시 DB 프롬프트 사용
   - DB 실패 시 하드코딩 fallback