feat(release): 장소 검색 개편과 여행 날짜 달력·동선 이동 개선

.github/pull_request_template.md

@@ -1,3 +1,7 @@
+## 노션
+<!-- 작업 배경·전후 스크린샷이 있는 노션 페이지 링크. 없으면 이 칸을 지운다. -->
+- 
+
 ## 변경 내용
 - 
 
@@ -8,4 +12,5 @@
 - [ ] `npm run lint`
 - [ ] `npm test`
 - [ ] `npm run build`
+- [ ] 화면 확인:
 - [ ] 그 외 수동 검증:

.gitignore

@@ -31,6 +31,9 @@ SERVICE_CONTEXT.md
 # Local git worktrees used for isolated feature development
 .worktrees/
 
+# Claude Code personal settings
+.claude/settings.local.json
+
 # misc
 .DS_Store
 .idea/

AGENTS.md

@@ -9,6 +9,11 @@
 
 브랜치 생성, PR 작성, 병합 작업은 반드시 [CONTRIBUTING.md](./CONTRIBUTING.md)를 따른다.
 
+## 프론트엔드 코드 작성 원칙
+
+- 프론트엔드·퍼블리싱 코드를 쓰기 전에 [핵심 원칙](docs/code-conventions/principles.md)을 읽는다.
+- 마치기 전에 변경한 코드를 [안티패턴](docs/code-conventions/anti-patterns.md)에 대어 보고 고친다.
+
 ## 로딩 UI 원칙
 
 - 화면 전환과 데이터 조회 중에 `불러오는 중…`, `확인 중…` 같은 문장형 로딩 안내를 화면에 노출하지 않는다.

CONTRIBUTING.md

@@ -14,16 +14,30 @@ docs: 개발자 온보딩 보완
 
 - `main`은 배포 기준 브랜치입니다. 직접 push하지 않고 모든 변경을 PR로 병합합니다.
 - `dev`는 기능을 통합하고 릴리스 전에 함께 검증하는 브랜치입니다.
-- 일반 작업은 최신 `dev`에서 `feature/<topic>` 브랜치를 만들고 `dev`를 대상으로 PR을 엽니다. 브랜치는 하나의 작업 단위로 짧게 유지하며, squash 병합이 끝난 feature 브랜치는 다시 사용하지 않습니다.
-- 긴급 수정은 최신 `main`에서 `hotfix/<topic>` 브랜치를 만들고 `main`을 대상으로 PR을 엽니다.
+- 작업 브랜치는 아래 `브랜치 종류` 표의 기준 브랜치 최신 상태에서 만들고, 같은 표의 PR 대상으로 PR을 엽니다.
+- 브랜치는 하나의 작업 단위로 짧게 유지하며, squash 병합이 끝난 브랜치는 다시 사용하지 않습니다.
+
+## 브랜치 종류
+
+| 브랜치 | 용도 | 기준 브랜치 | PR 대상 | 커밋·PR 타입 |
+| :-- | :-- | :-- | :-- | :-- |
+| `feature/<topic>` | 새 기능, 화면·디자인 변경 | `dev` | `dev` | `feat` |
+| `fix/<topic>` | 다음 배포에 함께 나가도 되는 버그 수정 | `dev` | `dev` | `fix` |
+| `refactor/<topic>` | 동작이 바뀌지 않는 구조 개선 | `dev` | `dev` | `refactor` |
+| `chore/<topic>` | 빌드·설정·의존성·개발 도구 | `dev` | `dev` | `chore` |
+| `docs/<topic>` | 문서만 변경 | `dev` | `dev` | `docs` |
+| `hotfix/<topic>` | 운영 장애처럼 바로 배포해야 하는 수정 | `main` | `main` | `fix` |
+
+- `<topic>`은 영어 소문자 kebab-case로 짧게 씁니다. 예: `feature/calendar-design`, `fix/logout-session`
+- 표에 없는 접두사(`feat/`, `codex/` 등)로 새 브랜치를 만들지 않습니다.
 
 ## 공통 브랜치 흐름
 
 브랜치 병합에는 다음 공통 흐름을 적용합니다.
 
 | 병합 방향 | 방식 |
 | :-- | :-- |
-| `feature/*` → `dev` | Squash and merge |
+| `feature/*`, `fix/*`, `refactor/*`, `chore/*`, `docs/*` → `dev` | Squash and merge |
 | `dev` → `main` | Create a merge commit |
 | `hotfix/*` → `main` | Squash and merge |
 | `main` → `dev` 백머지 | Create a merge commit |
@@ -39,3 +53,21 @@ docs: 개발자 온보딩 보완
 - main으로 직접 merge 전 최소 1명의 리뷰가 필요하다.
 - PR 본문은 .github/pull_request_template.md 형식을 그대로 따른다.
 - PR 본문에 변경 이유와 테스트 방법을 간략히 적는다.
+- PR을 열기 전에 대상 브랜치의 최신 상태를 작업 브랜치에 merge로 반영한다. 이미 push한 작업 브랜치는 rebase하거나 force-push하지 않는다.
+- 병합은 리뷰어가 확인한 뒤 위 `공통 브랜치 흐름`의 방식으로 한다.
+
+## PR 전 검증
+
+- 작업 중에는 전체 테스트를 돌리지 않는다. 필요한 확인만 한다.
+- PR을 열기 전에 `npm run lint` → `npm test` → `npm run build`를 한 번 실행하고, 결과를 PR 본문 테스트 칸에 체크한다.
+- 문서(`*.md`)·`.claude/`·`.github/`만 바뀐 PR은 생략할 수 있다. 생략하면 테스트 칸에 생략했다고 적는다.
+
+## 작업 공유
+
+| 위치 | 내용 |
+| :-- | :-- |
+| 노션 작업 페이지 | 작업 배경(왜 시작했는지), 논의 내용, 전후 스크린샷, 개발 메모 |
+| PR | 변경 내용, 짧은 변경 이유, 테스트 결과, 노션 페이지 링크 |
+| 디스코드 | PR을 열면 GitHub Actions가 자동으로 알린다. 작업 내역을 따로 보내지 않는다. |
+
+- 노션 페이지가 없는 작은 작업은 PR 본문의 `노션` 칸을 지운다.

Design.md

@@ -5,8 +5,8 @@
 ## 1. 공통 원칙
 
 ### 1-1. 토큰 우선순위
-1. 시맨틱 토큰 — `primary`, `surface`, `border`, `danger` …
-2. 원시 토큰 — `blue-100` 등. 1에 마땅한 게 없을 때만
+1. 시맨틱 토큰 — `primary`, `text`, `fill`, `border`, `status-negative` …
+2. 원시 토큰 — `--blue-100` 같은 CSS 변수. 1에 마땅한 게 없을 때만 `bg-[var(--blue-100)]`처럼 쓴다(`bg-blue-100`은 Tailwind 기본 팔레트라 색이 다르다)
 3. 임의값 — `text-[17px]`, `#3B82F6`
 
 - 값의 정의는 전부 `tailwind.config.js`(+ `src/app/globals.css`)에 있다. 이 문서에 값을 적지 않는다.
@@ -17,9 +17,10 @@
 예를들어서 피그마 페이지에 폰트가 17px이고 시멘틱 토큰과 css변수가 없다면 임의값을 사용한다.
 
 ### 1-3. 컴포넌트
-- 공통 컴포넌트는 `src/components/<도메인>/`(`layout`, `place`, `map`, `settings` …)에 있다. 있으면 쓴다
-- 특정 페이지 전용 컴포넌트는 `src/app/**/_components/`에 둔다
-- 없으면 Tailwind로 직접 작업한다
+목표는 shadcn이다. 아직 설치 전이라 기존 공용 컴포넌트와 병행하고, 무엇을 쓸지는 [핵심 원칙 1-1](docs/code-conventions/principles.md)을 따른다.
+- 공용: `src/components/<도메인>/`(`layout`, `place`, `map`, `settings` …)
+- shadcn: 설치 후 `src/components/ui/`
+- 특정 페이지 전용: `src/app/**/_components/`
 
 ### 1-4. Figma 디자인 시스템
 [Design System](https://www.figma.com/design/Va7ys9C4lx9PIHOGvlaAID/Design-System) 파일은 확정된 내용만 모아 둔 곳이다. 퍼블리싱할 때 해당 페이지의 컴포넌트·토큰을 기준으로 맞춘다.
@@ -102,19 +103,16 @@ import { MapPinIcon } from "@/assets/icons";
 
 ### 3-1. 상태
 - 서버 상태 → TanStack Query
-- 클라이언트 상태 → Zustand
-- 서버에서 온 데이터를 Zustand에 복사해두지 않는다
+- 클라이언트 상태 → 둘 곳은 [핵심 원칙 2-2](docs/code-conventions/principles.md)의 표를 따른다
+- 서버에서 온 데이터를 `useState`·Zustand·Context에 복사해두지 않는다
 
 ### 3-2. 필수 상태 처리
-데이터를 다루는 화면은 다음을 빠짐없이:
-- loading
-- error
-- empty
+데이터를 다루는 화면은 로딩·오류·빈 상태·재조회를 빠짐없이 그린다. 판정 순서와 상태별 UI는 [핵심 원칙 2-4](docs/code-conventions/principles.md) 표를 따른다(`data`부터 판정).
 
 ### 3-3. 이벤트 피드백
 - 사용자 액션에는 결과 피드백이 있어야 한다
-- 현재 alert 는 toast를 사용하고, confirm은 시스템confirm 과 dialog가 혼용되고 있는 상태이다. 새로 작성하는 코드는 dialog를 우선시하되 요구조건에 맞춰서 해라
-- 비동기 동작 중 중복 실행 방지
+- alert는 toast, confirm은 `ConfirmDialog`를 쓰고 요구조건에 맞춘다(shadcn 설치 후 기준은 [핵심 원칙 1-1](docs/code-conventions/principles.md))
+- 비동기 동작 중 중복 실행 방지(핵심 원칙 2-4)
 
 
 ---