[FEAT] 프로젝트 목록 meetingCount 실집계 연결 + teamNames 배치 조회 추가

[MNPPI223]

📌 연관 이슈

• Closes #

(PR #258·#253 후속 작업 — 별도 이슈 없음)

---

⚠️ 의존 관계 (머지 순서 중요)

이 PR은 develop이 아니라 PR #258(feat/mo-meetingdata) 위에서 시작했고, PR #253
(feat/mnppi-project-list-action-counts)도 merge해서 포함하고 있습니다.
#258과 #253이 먼저 develop에 머지된 뒤에, 이 PR의 베이스를 develop으로 다시 잡거나
그대로 순차 머지해주세요. base를 feat/mo-meetingdata로 잡아둔 건 성진님 PR의 새
countMeetingsByProjectIds 계약 없이는 컴파일이 안 되기 때문입니다.

---

📝 작업 내용

• 성진(D) PR #258이 제공하는 meeting.application.port.in.MeetingQueryPort.countMeetingsByProjectIds(companyId, projectIds) 계약을 project(C)가 호출
• project 쪽에 자체 아웃바운드 포트 project.application.port.MeetingQueryPort 신설 + MeetingQueryPortDelegatingAdapter로 위임 — handover(E)의 MeetingQueryPortDelegatingAdapter와 동일한 ACL 패턴(별도 빈 이름 지정 — 같은 단순 클래스명이 이미 handover에 있어서 기본 빈 이름이 충돌함)
• ProjectSummaryResponse.meetingCount가 더 이상 0 고정이 아니라 실제 회의 수 반환(취소 회의 제외, D 계약 그대로)
• (추가) ProjectSummaryResponse.teamNames 배치 조회 연결 — 종호(B) 확인 회신 반영. project가 이미 소유한 TeamReferenceRepository(팀 소속 검증용, team 테이블 읽기전용 참조)에 findTeamNames 계약 추가, 목록 조회 시 전체 프로젝트의 teamIds를 한 번에 모아 배치 조회(N+1 없음) 후 id→name 매핑. 신규 크로스 도메인 호출 없음 — 기존 참조 엔티티 재사용
• (추가) TeamReferenceEntity.@Id에 @GeneratedValue(IDENTITY) 누락 수정 — 종호(B) 지적. 실제 쓰기 엔티티(B의 Team)와 ID 생성 전략이 다르면 같은 team 테이블에 insert하는 다른 도메인 테스트가 Hibernate 세션 충돌로 깨질 수 있음(action 도메인 참조엔티티에서 이미 겪은 문제와 동일 패턴)

---

🖥️ 프론트엔드 연동 가이드 (API 명세)

1. 주요 엔드포인트

• GET /api/projects : meetingCount가 이제 실제 값입니다(기존엔 항상 0). teamNames(부서 이름 배열, 목록 행 부서 칩 표시용) 필드가 새로 추가됐습니다.

4. ⚠️ 프론트엔드 참고 및 주의사항

• meetingCount는 취소(CANCELED)된 회의는 제외하고 셉니다(SCHEDULED·IN_PROGRESS·DONE만 포함).
• teamNames는 teamIds와 같은 순서로 내려갑니다. 생성/수정 직후 응답(POST/PATCH)에는 빈 배열로 옵니다 — 목록 조회(GET /api/projects)에서만 채워집니다.

---

💡 백엔드 리뷰 포인트 (Backend Review)

• 아키텍처 및 도메인: C→D 방향(meetingCount) 조회는 handover(E)가 이미 쓰고 있는 "자체 아웃바운드 포트 + Delegating Adapter" 패턴을 그대로 재사용했습니다. companyId는 handover와 달리 project 쪽 메서드 시그니처에 이미 있어서 SecurityContext에서 따로 꺼낼 필요가 없었습니다. teamNames는 별도 Port 신설 없이 project가 이미 소유한 로컬 참조 엔티티(TeamReferenceEntity)로 처리해 크로스 도메인 애플리케이션 계층 호출 자체가 없습니다(BC 경계 그대로 유지).
• 우려되는 부분이나 고민: 이 PR 자체보다 위 의존 관계(머지 순서)가 제일 중요한 리뷰 포인트입니다. teamNames 배치조회는 신규 쿼리 없이 기존 findAllByIdInAndCompanyId 재사용이라 리스크가 낮습니다.

✅ 체크리스트

• 코드 컨벤션을 준수했습니다.
• 불필요한 주석 및 콘솔 로그를 제거했습니다.
• API 기능이 정상 동작하는지 테스트했습니다.
• 예외(잘못된 값) 상황에 대한 검증 및 테스트를 통과했습니다.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fc21610e-4bf5-4c4a-ac90-874bb6b37e3a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

[mosungjin]

확인했습니다.