docs: PLAN.md 추가

[Hyun731]

작업 내용

• SprintOps Agent용 PLAN.md 추가
• User 서비스 역할, 저장소 유형, 주요 디렉터리, 완료 판단 기준, 주간 점검 경로 문서화

검증

• 문서 변경만 포함
• README 브랜치/커밋 컨벤션 적용: docs/#7, docs: PLAN.md 추가

Closes #7

Summary by CodeRabbit

릴리스 노트

• 문서화
  • 프로젝트 계획 및 구조 관련 종합 문서를 추가했습니다. 저장소의 역할, 기술 스택, 주요 디렉터리 구조, API 명세 소스, 라우트 네이밍 규칙 등이 정리되어 개발 진행 상황 추적이 용이해졌습니다.

[coderabbitai]

📝 Walkthrough

Walkthrough

사용자 서비스 저장소 루트에 PLAN.md 문서가 새로 추가됨. 저장소 역할, 기술 스택, 디렉터리 구조, 도메인 책임, 완료 판정 규칙, SprintOps Agent 체크포인트, 라우트 네이밍 규칙을 93줄로 정리함.

Changes

PLAN.md 문서 추가

Layer / File(s)	Summary
PLAN.md 전체 문서 PLAN.md	서비스 역할(백엔드, 사용자 서비스), 기술 스택(Java 21, Spring Boot 4.0.5, JPA/Security/JWT/PostgreSQL 등), 주요 디렉터리 구조, 도메인 책임(가입/조회/수정/삭제/OAuth), API 소스 오브 트루스(Apidog, API_SPEC.yaml), 완료 판정 규칙, SprintOps Agent 체크포인트, 라우트 네이밍 규칙(/users 공개, /internal/users 내부)이 정의됨.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related issues

• docs: SprintOps PLAN.md 추가 Auth#7: 동일한 SprintOps Agent 통합을 위한 PLAN.md 추가 작업으로, Auth 서비스에도 같은 목적의 문서 추가가 계획되어 있음.

Poem

🐇 토끼가 문서를 펼쳤네,
PLAN.md 한 장에 모든 게 담겼어!
기술 스택, 라우트, 완료 규칙까지,
SprintOps Agent도 이제 길을 알겠지. 🗺️
깡충깡충, 코드보다 글이 먼저! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR 제목이 변경 사항의 핵심을 명확하게 요약하고 있습니다. 'docs: PLAN.md 추가'는 문서 추가에 대한 구체적이고 명확한 설명을 제공합니다.
Description check	✅ Passed	PR 설명이 필수 섹션인 '작업 내용'과 '검증'을 포함하고 있으며, 변경 사항을 명확하게 설명하고 관련 이슈(#7)를 참조하고 있습니다.
Linked Issues check	✅ Passed	PR이 이슈 #7의 모든 완료 조건을 충족합니다: PLAN.md가 서비스 루트에 추가되었고, 브랜치/커밋 컨벤션을 따르며, main 브랜치를 대상으로 합니다.
Out of Scope Changes check	✅ Passed	모든 변경 사항이 PLAN.md 문서 추가에 한정되어 있으며, 이슈 #7의 범위 내에 있습니다. 범위를 벗어난 변경 사항이 없습니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/#7

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

PLAN.md (1)

49-55: ⚡ Quick win

API Source of Truth 정의에서 권위 관계 명확화 필요

PLAN.md에서는 Apidog를 기본 관리 도구로, API_SPEC.yaml을 "로컬 저장소 측" 스펙으로 표현하고 있으나, AGENTS.md는 "API_SPEC.yaml이 이 서비스 API 계약의 소스 오브 트루스(Source of Truth)"라고 명시하고 있습니다.

이 두 문서 간의 권위 관계가 불명확할 경우, 개발자가 API 변경 시 어느 문서를 먼저 업데이트해야 하는지 혼동할 수 있습니다. 예를 들어:

• Apidog에서만 변경하고 API_SPEC.yaml 미동기화 가능성
• PR 검토 시 어느 문서의 일관성을 검증할지 불명확

현재 상태를 더 명확히 하기 위해 "Apidog is the primary specification tool, and API_SPEC.yaml must be kept in sync as the repository's source of truth"와 같이 동기화 책임을 명시적으로 정의하는 것을 권장합니다.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@PLAN.md` around lines 49 - 55, The "API Source of Truth" section in PLAN.md
currently presents Apidog and API_SPEC.yaml without clarifying which is
authoritative, creating confusion about update priorities. Update the section to
explicitly state that Apidog is the primary specification tool while
API_SPEC.yaml must be kept in sync as the repository's source of truth, making
synchronization responsibility clear so developers know to update API_SPEC.yaml
whenever Apidog specifications change.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@PLAN.md`:
- Around line 57-69: The Completion Rule section in PLAN.md (lines 57-69) does
not account for API specifications marked with "Needs confirmation" in
API_SPEC.yaml, which means incomplete specs may be incorrectly treated as
complete. Add a new status rule to the Completion Rule section that identifies
when an API spec contains "Needs confirmation" marks (found at locations like
server URLs, error response mappings, network boundaries, and authentication
logic) and explicitly state that such features should be marked as "spec
incomplete" (or define an alternative status name). This new rule should prevent
specs with unresolved confirmation marks from being considered as completed
until those marks are resolved.

---

Nitpick comments:
In `@PLAN.md`:
- Around line 49-55: The "API Source of Truth" section in PLAN.md currently
presents Apidog and API_SPEC.yaml without clarifying which is authoritative,
creating confusion about update priorities. Update the section to explicitly
state that Apidog is the primary specification tool while API_SPEC.yaml must be
kept in sync as the repository's source of truth, making synchronization
responsibility clear so developers know to update API_SPEC.yaml whenever Apidog
specifications change.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: baa6a846-fd2e-437f-8fae-d6275e2c8ad3

📥 Commits

Reviewing files that changed from the base of the PR and between d26a2df and 204e3df.

📒 Files selected for processing (1)

• PLAN.md