chore: 설계 문서 동기화 슬래시 커맨드 추가

이슈 번호를 받아 docs/design/의 해당 설계 문서를 실제 코드와
대조해 갱신하는 /update-design-doc 커맨드를 추가한다.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: kangcheolung

.claude/commands/update-design-doc.md

@@ -0,0 +1,21 @@
+# 설계 문서 동기화 커맨드
+
+이슈 번호($ARGUMENTS)를 받아, 코드 리팩토링/수정 이후 낡아진 `docs/design/` 설계 문서를 실제 코드에 맞게 갱신합니다.
+
+## 절차
+
+1. `docs/design/*-#{이슈번호}-*.md` 패턴으로 해당 이슈의 설계 문서를 찾는다. 없으면 사용자에게 알리고 중단한다(새 설계 문서 작성은 이 커맨드의 범위가 아님 — `docs-management.md` 규칙에 따라 기능 구현 PR과 함께 사람이 작성).
+2. 문서에 등장하는 코드 스니펫·파일 경로·메서드 시그니처를 실제 소스 코드와 하나씩 대조한다. 문서가 인용하는 파일들을 전부 읽는다.
+3. 다음을 갱신 대상으로 삼는다:
+   - 문서의 코드 스니펫이 실제 코드와 달라진 부분 (시그니처 변경, 로직 변경, 삭제된 메서드 등)
+   - "남은 이슈 / TODO" 섹션 중 이번 변경으로 실제로 해결된 항목 — 삭제하지 말고 `~~취소선~~` 처리 후 "→ 해결됨(어떻게 해결됐는지 한 줄)"로 남긴다 (기존 `#18` 문서의 Swagger 설명 수정 이력이 이 패턴을 이미 쓰고 있으니 그대로 따른다)
+   - 새로 추가된 메서드/엔드포인트가 있는데 문서에 없으면 "신규 파일" 또는 관련 섹션에 추가
+   - "설계 결정 요약"에 이번 변경으로 새로 생긴 결정(예: 오버로드 분리, status 필터링 방식)이 있으면 한 항목 추가
+4. **바꾸지 않는 것**: 문서 제목, `closes #{이슈번호}`, 배경(왜 만들었는지) 섹션의 원래 취지, "로컬 검증"에 기록된 과거 수동 테스트 기록(사실 기록이므로 보존). 테스트 결과 문서(`docs/test-results/`)는 별도 이슈로 관리되므로 건드리지 않는다.
+5. 수정은 Edit 도구로 최소 diff만 반영한다 — 문서 전체를 새로 쓰지 않는다.
+6. 완료 후 어떤 섹션을 왜 고쳤는지 3~5줄로 요약해서 보고한다. 이 커맨드는 git add/commit을 하지 않는다 — 커밋 여부는 `git-conventions.md`대로 사용자 확인 후 별도로 진행한다.
+
+## 주의
+
+- 이슈 하나에 문서가 여러 개 걸릴 수 있다(예: `#16`/`#29`처럼 같은 서비스를 다루는 후속 이슈). `$ARGUMENTS`로 지정한 이슈 번호의 문서만 갱신하고, 관련된 다른 이슈 문서가 있으면 "관련 문서 `#N`도 같은 이유로 낡았을 수 있음"이라고 언급만 하고 자동으로 같이 고치지 않는다 — 범위를 명시적으로 지정받는다.
+- 코드에서 확인이 안 되는 내용(의도인지 버그인지 불확실한 부분)은 문서에 임의로 단정해서 쓰지 않는다. 확인이 필요하면 사용자에게 먼저 묻는다.