프로젝트 개요, 구조, 명령어, 핵심 패턴은 @AGENTS.md 참조.
- 요청이 모호하면 먼저 질문한다
- 수정할 파일은 반드시 읽고 기존 패턴을 파악한 뒤 작업한다
- 솔루션 로직을 스스로 검토한 후 제시한다
- 기존 프로젝트 스타일과 DDD 구조를 엄격히 따른다
- 요청된 작업 범위만 수정한다 (불필요한 리팩토링 금지)
- 완전히 실행 가능한 코드만 제공한다 (의사코드 금지)
@Valid,@NotNull등 DTO 검증 어노테이션 적용- secrets/환경변수 하드코딩 절대 금지
- 변수명은 의미를 알 수 있도록 작성한다 —
dto,r,p같은 축약 금지, 역할이 드러나는 이름 사용 (예:dto→rawRanking,r→ranking)
- (DB 변경 시)
resources/db/migration/에 Flyway 마이그레이션 파일 추가 api/패키지에 Swagger 인터페이스 정의controller/구현 (인터페이스 implements)service/+ command/query DTO 작성repository/쿼리 추가- 테스트 작성 (RestAssured + Fixture)
- 코드 작성 후
./gradlew test로 검증한다 - 버그 수정/기능 추가 시 반드시 테스트 추가
- TestContainers 사용 — Docker 실행 상태 필요
- FixtureMonkey 사용 금지 — 테스트 데이터는
common/fixture/의 static 메서드로만 생성한다 @DisplayName에 메서드명을 넣지 않고, 테스트만 보고 요구사항을 파악할 수 있는 문장으로 작성한다- 좋은 예:
"피드가 없으면 모든 집계가 0이다","삭제된 피드는 조회되지 않는다" - 나쁜 예:
"findMyFeedStat - 피드가 없으면 0","getAllFeeds는 삭제된 피드 제외"
- 좋은 예:
- 브랜치명:
{type}/{DDING-이슈번호}-{설명}(예:feat/DDING-123-club-search) - 커밋 메시지: 한국어,
[DDING-000] 작업 내용형식 - PR 템플릿: 🚀 작업 내용 / 🤔 고민했던 내용 / 💬 리뷰 중점사항
- PR 본문 작성 시 특정 클래스명, 메서드명을 나열하지 않고 작업 내용 중심의 자연스러운 글로 작성한다 (가독성 우선)
여러 API를 한 기능에서 개발할 때 PR이 커지는 것을 방지하기 위해 API 1개 = 브랜치 1개 = PR 1개 원칙을 따른다.
규칙
- 각 브랜치는 plan 파일 1개에 대응 (구현 + 테스트 포함)
- 브랜치는
develop에서 분기,develop으로 PR - 의존 관계가 있는 경우 앞 브랜치 merge 후 다음 브랜치 분기
- 브랜치명:
feat/{DDING-이슈번호}-{도메인}-{api-설명}(예:feat/DDING-000-feed-comment-api)
작업 순서 (피드 추가 기능 예시)
develop
└─ feat/DDING-000-feed-comment-api # 01 댓글 작성/삭제
└─ feat/DDING-000-feed-admin-monthly-rank # 02 총동연 월별 랭킹
└─ feat/DDING-000-feed-admin-rank-winners # 03 총동연 지난 1위
└─ feat/DDING-000-feed-club-ranking # 04 동아리 개별 랭킹
└─ feat/DDING-000-feed-club-monthly-best # 05 동아리 이달의 현황
└─ feat/DDING-000-feed-modify-existing # 06 기존 API 수정
- Flyway 기존 마이그레이션 파일 수정
- 엔티티 물리 삭제 (
DELETE직접 실행) api/인터페이스 없이 Controller 단독 작성- application.yml 내 시크릿 값 직접 기재