Repository navigation
refactor(setting): 합본 UserRepository 대신 좁은 계약 UserReceiverRepository·MyProfileRepository 를 주입한다 (#1282 분리) #1739
Description
작업 유형
refactor — 동작 변경 없는 구조·책임·경계 개선
주 담당 모듈
setting — 설정
개요
설정의 프로필·수신자 소비자를 PR #2123에서 기존 MyProfileRepository·UserReceiverRepository로 전환한다. 현재 ViewModel의 상태·라우팅을 유지하면서 실제 사용하는 최종 저장소 계약만 전환한다.
구현 범위
- 프로필 수정·설정 홈은 MyProfileRepository를, 수신자 목록·등록·수정·전달조건은 UserReceiverRepository를 주입한다.
- 계정·연결 계정과 서비스 알림·마케팅 동의는 같은 PR의 refactor(setting): 계정·서비스 알림·마케팅 동의 8멤버를 설정 모듈로 이동 #1429 최종 설정 계약을 사용한다.
- 테스트를 좁은 fake로 전환하고 호출 기록 타입도 해당 fake로 옮겨 합본 fake 제거 시 재작성하지 않는다.
- 설정 presentation 69개와 core domain 12개 테스트, 앱 컴파일을 검증했다.
병합 및 의존 순서
#1429와 #1739의 저장소 책임 분리와 실제 소비를 develop 기준 PR #2123에 함께 담았다. 닫힌 #1967에서는 이 범위만 추출했고 MVI·Nav3 구현은 복구하지 않았다. 이 이슈는 #2123 머지로 종료한다. 로컬 검증과 최신 CI가 통과했다. API 30 계측 테스트 57개도 실패 없이 통과했으며, 필수 리뷰와 병합을 기다린다.
Activity
OnlyReadOneBook commentedon Sep 13, 2026
이 이슈를 맡은 PR 은 #1967 이다 (base
codex/1695-setting-nav3). 본문에 수신자·프로필 소비자가UserReceiverRepository와MyProfileRepository만 주입받도록 바꾸고, 좁은 fixture 와 호출 기록 타입까지 실제 소비자에 연결해 합본 fake 를 걷어낼 때 같은 테스트를 다시 고치지 않게 했다고 적혀 있다.pr-open라벨을 손으로 붙였다. 라벨러가 PR 제목의(#N)하나만 보기 때문에, 본문에서 #1502 · #1691 · 이 이슈 · #1429 를 닫는 #1967 에서 대표 이슈만 라벨을 받았다(#2082).base 가 기본 브랜치가 아니라 Development 칸도 비어 있다. 라벨이 유일한 신호인데 그 신호가 안 나오는 자리였다.
라벨러 마커를 이 코멘트에 함께 넣어 두어, #2082 가 머지된 뒤 리컨사일러가 중복으로 달지 않는다. 라벨 자체는 수정이 머지되기 전까지 배포본이 스테일로 보고 떼어 간다.