설정 사후 전달 조건 메뉴의 최종 진입 경로 확정

작업 유형

documentation — 문서

주 담당 모듈

setting — 설정

개요

설정 메인의 ‘사후 전달 조건’ 바로가기를 유지할지, 유지한다면 어떤 화면 순서로 진입할지 PM에게 확인하고 확정 근거를 기록한다. 현재 앱 구현을 제품 승인 근거로 삼지 않는다.

확인된 현재 상태

develop의 SettingNavGraph.kt부터 selectForDeliveryConditions=true이면 수신자 선택 화면을 거쳐 해당 수신자의 전달 조건을 열고, false이면 수신자 관리 화면에서 수정으로 이동한다.
#1962는 이 기존 분기를 Nav3로 옮긴다. 선택 우선 흐름을 새로 도입한 PR은 아니지만, 기존 코드라는 이유만으로 제품 경로가 확정된 것은 아니다.
현재 Figma ‘정리 Screen Design > 설정’에서 설정 메인, 수신인 목록, 수신인 설정, 사후 전달 조건 화면을 확인했다. 수신인 설정에는 ‘사후 전달 조건 설정’ 항목이 있다.
확인한 설정 영역에서는 설정 메인 → 전용 수신자 선택 → 전달 조건의 연결을 명시한 시안·프로토타입 근거를 찾지 못했다. 시안에 없다는 것만으로 해당 경로가 폐기됐다고 단정하지 않는다.

추가 확인한 기획 근거

Figma 기존 댓글 #201이 연결한 Notion ‘사후 관리’를 직접 확인했다. 문서는 조건을 수신자 × 콘텐츠 단위로 정하며 수신자 상세 안에서 콘텐츠별 조건을 편집하는 구조를 명시한다. 따라서 수신자별 조건인지 전체 공통인지부터 다시 결정해 달라고 묻는 대신, 현재 기획에서 남은 설정 메인 메뉴의 연결을 확인한다.

기존 댓글 #201도 설정 메인의 해당 항목이 어디로 이어질지 정리를 요청했지만 답변은 없었다. 전용 수신자 선택을 거치는 바로가기를 유지한다는 근거는 여전히 확인되지 않았다.

PM에게 필요한 결정

설정 메인의 ‘사후 전달 조건’을 현재처럼 수신자 선택 → 조건 설정 바로가기로 유지하는가? 수신자 상세를 거치게 하거나 메뉴를 제거해야 한다면 최종 화면 순서를 확인한다.
수신인 설정의 진입과 설정 메인의 진입을 모두 제공하는가?

범위와 재개 조건

이 이슈는 결정과 근거 기록만 담당한다. 특정 대체 화면·플래그·라우트 구현을 미리 예약하지 않는다.
답변 전 기존 진입을 임의로 제거하거나 비활성화하지 않는다. 기존 동작 보존을 PM 승인으로 표현하지 않는다.
PM 결정이 기존과 다르면 RecipientListRoute.selectForDeliveryConditions, 설정 진입 액션, SettingNavHost의 목록 분기·전달 조건 목적지 및 해당 검증을 다시 대조한다. 이 재작성 가능성을 숨긴 채 #1962가 제품 결정과 무관하다고 단정하지 않는다.
현재 동작을 유지한다는 결정이면 그 근거를 남긴다. 변경 결정이면 당시 최신 코드에서 실제 필요한 변경만 별도 범위로 정한다.

완료 조건

PM 답변 원문 링크와 설정 메인 메뉴의 유지 여부·최종 화면 순서를 기록한다.
현재 구현 및 #1962와 차이가 있는지 확인하고, 차이가 있으면 영향 범위를 정한다.
관련 PR의 범위 설명에 확정 결과를 반영한다.

참고

설정 Navigation 3 이관: refactor(setting): 설정 흐름을 Navigation 3 로컬 스택으로 이관 #1695 / refactor(setting): 설정 로컬 Navigation 3 스택 이관 (#1695) #1962
전건호 PM에게 질문한 Figma 댓글 #251 — 2026-09-13 등록. 답변 대기 중이며 해결됨 처리하지 않았다.

실측: #1962 는 그 분기를 동작 그대로 옮겼다

완료 조건 2번("현재 구현 및 #1962 와 차이가 있는지 확인")을 이번에 직접 재 봤습니다. 기준은 origin/develop 86ab223, PR #1962 head 999612c 입니다.

분기 본체

develop SettingNavGraph.kt:120-134 과 PR SettingNavHost.kt:138-152 이 같은 조건, 같은 두 갈래, 같은 인자입니다.

	develop	#1962
조건	`route.selectForDeliveryConditions`	같음
true 갈래	`ReceiverListScreen(receivers, onBackClick, onConfirmClick)`	같음
false 갈래	`ReceiverManageScreen(receivers, onBackClick, onReceiverClick)`	같음
선택 확정 시	`onNavigateToAfterDelivery(receiver.receiverId)`	`onDeliveryConditionsRecipientSelected(receiver.receiverId)`

플래그와 진입 액션

플래그 선언은 그대로입니다. develop SettingRoute.kt:25-26, PR SettingRoute.kt:26-27 둘 다 RecipientListRoute(val selectForDeliveryConditions: Boolean = false) 입니다.
설정 메인에서 오는 진입도 그대로입니다. develop AppNavigationActions.kt:220-224 의 onNavigateToRecipientListForDeliveryConditions() 가 PR SettingLocalNavActions.kt:47-51 의 onDeliveryConditionsClick() 로 이름만 바뀌었고, 둘 다 RecipientListRoute(selectForDeliveryConditions = true) 를 쌓습니다.
조건 화면 라우트는 AfterDeliveryRoute 에서 DeliveryConditionsRoute 로 이름이 바뀌었고 receiverId: Long 필드는 같습니다.
selectForDeliveryConditions 가 나오는 곳은 양쪽 다 네 자리뿐입니다(선언, 진입 액션, 분기, ReceiverListScreen KDoc).

그래서 완료 조건 2번의 실측 답

현재 구현과 #1962 사이에 사후 전달 조건 진입의 동작 차이는 없습니다. 다른 것은 심볼 이름과 백스택 자료구조(NavController 그래프에서 NavKey 백스택으로)입니다.

동작이 보존됐다는 것이 이 경로를 승인한 근거는 아닙니다. PM 답변이 가르는 것은 이 분기의 존폐이고, 제거 결정이면 위 네 자리와 DeliveryConditionsRoute 목적지가 함께 움직입니다. 그 시점의 최신 코드로 다시 대조할 자리입니다.

이 이슈 하나가 설정 계열 스택 전체를 세우고 있다

오늘 설정 계열을 훑다가 확인했습니다. #1998 은 자신을 막는 이슈가 없고(blocked_by 0건) 대신 #1695 를 막고 있는데, 그 아래로 열린 PR 여덟 개가 줄줄이 매달려 있습니다. 기다리는 것은 코드가 아니라 PM 답변 한 줄입니다. 답변이 왔을 때 다음 사람이 순서를 다시 조사하지 않아도 되도록 지금 상태를 실측해 둡니다. 재확인 시각은 2026-09-13 22:28 KST, develop 은 7d87aa3f4 입니다.

기다리는 답변

창구는 본문 참고란에 건 Figma 댓글 #251(id 1923797606, node 4327:64430)이고 2026-09-13T01:48:06Z 에 전건호 PM 앞으로 등록했습니다. 대댓글 0건이고 resolved_at 은 null 입니다. 오늘 조사에서 Figma REST 로 그 파일의 댓글 391건을 전수로 받아 확인한 값입니다.

같은 파일에서 PM 의 마지막 활동은 2026-09-11T03:23 이고, 09-12 부터 09-13 사이에 올라간 다른 질문 약 20건도 함께 미답입니다. 이 질문만 밀린 것이 아닙니다.
다른 경로로 온 답변도 없습니다. Slack 공개 채널에서 "사후 전달 조건" 을 after:2026-09-01 로 검색하면 0건입니다(게시 직전 재실행). 이 이슈의 코멘트도 제가 쓴 1건뿐입니다.
이 세션은 Figma MCP 가 미인증이라 게시 직전에 스레드를 다시 열지는 못했습니다. 위 숫자의 마지막 실측 시각이 오늘 조사 시점이라는 뜻입니다.
독촉 말고 당길 수 있는 레버는 없습니다.

막혀 있는 사슬

blocked_by 는 GitHub dependencies API 로, PR 상태는 gh pr view 로, guard 문구는 워크플로 로그에서 그대로 떴습니다.

develop 7d87aa3f4
└ #1962 codex/1695-setting-nav3         Draft · guard fail · APPROVED(Sadturtleman, 09-11) · closes #1695
  ├ #1967 refactor/1502-setting-state-mvi    guard fail · APPROVED(09-11) · closes #1502 #1691 #1739 #1429
  │ ├ #2018 refactor/1805-receiver-list-mvi      guard pass · 리뷰 전 · closes #1805
  │ │ └ #2034 fix/579-receiver-reentry             guard pass · 리뷰 전 · closes #579
  │ │   └ #2051 fix/1281-receiver-list-state         guard fail · 리뷰 전 · closes #1281 #2045
  │ ├ #1927 handoff/555-setting-1hyok           guard fail · APPROVED · closes #1944
  │ └ #1925 handoff/708-setting-1hyok           guard fail · CHANGES_REQUESTED · closes #708
  │   └ #1930 handoff/1920-setting-1hyok          guard fail · APPROVED · closes #1920

이슈 쪽 의존성은 #1998 → #1695 → #1502 → {#708, #1944} 와 #708 → #1920 한 줄로 이어집니다. #1695 는 #1502 말고 #1702 와 #1793 도 막고 있어서 영향은 위 여덟 개보다 넓습니다.

merge-order-guard 가 낸 실제 문구입니다.

#1962  #1695 이 아직 열린 #1998 에 blocked — 머지 순서 위반. 선행 이슈를 먼저 완료할 것 (base: develop)
#1967  #1502 이 아직 열린 #1695 에 blocked — 머지 순서 위반. 선행 이슈를 먼저 완료할 것 (base: codex/1695-setting-nav3)
#1927  #1944 이 아직 열린 #1502 에 blocked — 머지 순서 위반. 선행 이슈를 먼저 완료할 것 (base: refactor/1502-setting-state-mvi)
#1925   #708 이 아직 열린 #1502 에 blocked — 머지 순서 위반. 선행 이슈를 먼저 완료할 것 (base: refactor/1502-setting-state-mvi)
#1930  #1920 이 아직 열린  #708 에 blocked — 머지 순서 위반. 선행 이슈를 먼저 완료할 것 (base: handoff/708-setting-1hyok)

맨 위 한 줄이 이 이슈입니다. 아래 네 줄은 그 한 줄이 풀려야 차례로 풀립니다.

#2051 의 guard 실패만 계보가 다릅니다. 문구가 #1281 이 아직 열린 #579 에 blocked 이고 #579 의 blocked_by 는 0건이라, #2034 가 머지되면 스스로 풀립니다. #2018 과 #2034 는 guard 자체는 통과하지만 base 가 이 스택 위라 순서로는 같이 묶여 있습니다.

답변이 오면 풀리는 순서

설정 사후 전달 조건 메뉴의 최종 진입 경로 확정 #1998 을 닫는다. refactor(setting): 설정 흐름을 Navigation 3 로컬 스택으로 이관 #1695 의 blocked_by 가 비고 refactor(setting): 설정 로컬 Navigation 3 스택 이관 (#1695) #1962 의 guard 가 초록이 된다.
refactor(setting): 설정 로컬 Navigation 3 스택 이관 (#1695) #1962 는 Draft 다. 본문이 "PM 결정 후 이관 범위·코드·검증을 재검토하기 전에는 Ready로 전환하지 않습니다" 라고 적어 뒀으니 Ready 전환 판단이 머지보다 먼저다. 승인은 2026-09-11 에 이미 받아 뒀다.
refactor(setting): 설정 로컬 Navigation 3 스택 이관 (#1695) #1962 머지로 refactor(setting): 설정 흐름을 Navigation 3 로컬 스택으로 이관 #1695 가 닫히면 refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 이 풀린다. 스택 PR 은 base 를 develop 으로 PATCH 한 뒤 머지하라는 경고가 guard 로그에 매번 같이 뜬다.
refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 머지로 refactor(setting): 남은 이벤트 스트림 2곳을 UiState·MVI로 전환하고 재유입을 막는다 #1502 가 닫히면 fix(setting): 패스키 목록·등록 호출과 실패 처리를 연결한다 (#1944) #1927 과 fix(setting): 오류 상태 처리를 안정화한다 (#708) #1925 가 함께 풀린다. fix(setting): 오류 상태 처리를 안정화한다 (#708) #1925 는 CHANGES_REQUESTED 라 리뷰 반영이 먼저다.
fix(setting): 오류 상태 처리를 안정화한다 (#708) #1925 머지로 서버 조회 실패가 로그아웃·빈 목록·OFF 기본값으로 위장 — 오류·재시도 상태 미결선 #708 이 닫히면 fix(setting): 설정 하위 화면 4종의 재진입 갱신 (#1920) #1930 이 풀린다.
refactor(setting): 수신자 목록을 MVI와 lifecycle Intent로 전환 (#1805) #2018, fix(setting): 빠른 수신자 목록 재진입 시 다시 조회 (#579) #2034, fix(setting): 수신자 목록 조회 상태와 재시도 연결 (#1281) #2051 은 base 순서대로 간다. fix(setting): 수신자 목록 조회 상태와 재시도 연결 (#1281) #2051 은 fix(setting): 빠른 수신자 목록 재진입 시 다시 조회 (#579) #2034 머지로 수신자 목록이 화면 재진입 시 미갱신 — 앱 재시작 전까지 stale #579 가 닫혀야 guard 가 초록이 된다.

사슬 안에서 구현이 끝나 머지만 기다리는 이슈

오늘 확인한 것만 적습니다. 아래 넷은 자기 PR 이 따로 없고 다른 PR 본문의 Closes 로만 잡혀 있어서, GitHub 의 연결된 PR 패널로는 찾아지지 않습니다. 이 저장소는 auto-close-issue 워크플로가 PR 본문의 close 키워드를 직접 파싱해 닫기 때문에 링크가 없어도 머지 시 닫힙니다.

refactor(setting): 수신자 저장·전달조건 정책을 UseCase로 분리한다 #1691 수신자 저장·전달조건 정책을 UseCase 로 분리 (refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 본문 Closes)
refactor(setting): 합본 UserRepository 대신 좁은 계약 UserReceiverRepository·MyProfileRepository 를 주입한다 (#1282 분리) #1739 좁은 계약 UserReceiverRepository·MyProfileRepository 주입 (refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 본문 Closes)
refactor(setting): 계정·서비스 알림·마케팅 동의 8멤버를 설정 모듈로 이동 #1429 계정·서비스 알림·마케팅 동의 8멤버를 설정 모듈로 이동 (refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 본문 Closes)
fix(core): 수신자 목록의 로딩·실패 결과를 보존한다 (#1281 분리) #2045 수신자 목록의 로딩·실패 결과 보존 (fix(setting): 수신자 목록 조회 상태와 재시도 연결 (#1281) #2051 본문 Closes)

자기 PR 이 있는 쪽은 #1695(#1962), #1502(#1967), #1944(#1927), #1920(#1930), #1805(#2018), #579(#2034), #1281(#2051) 입니다. 이 중 승인까지 끝난 PR 은 #1962, #1967, #1927, #1930 네 건입니다.

답변 내용별로 손댈 자리

완료 조건 2번은 앞 코멘트에서 끝냈고 그 측정은 지금도 유효합니다. git diff 86ab223 origin/develop -- feature/setting app/src/main/java/com/afternote/afternote_fe/navigation 이 빈 출력입니다.

"현재 유지" 로 오면 코드는 0줄입니다. 답변 링크와 최종 화면 순서를 여기 적고 #1962 본문의 "확인 중" 문장을 확정 결과로 바꾸면 완료 조건 1번과 3번이 채워집니다.

"제거" 나 "수신자 상세 경유" 로 오면 움직일 자리는 7d87aa3f4 기준 네 곳입니다. selectForDeliveryConditions 전수 grep 결과가 딱 이 넷이라 범위는 닫혀 있습니다.

SettingRoute.kt:25-26 플래그 선언.
SettingNavGraph.kt:51-53 설정 메인 진입. 인터페이스 선언은 SettingNavActions.kt:36, 구현은 AppNavigationActions.kt:220-224 입니다.
SettingNavGraph.kt:116-135 목록 분기(조건은 120행). 제거면 ReceiverManageScreen 단일 갈래만 남고, 바로 아래 composable<SettingRoute.AfterDeliveryRoute>(151행)의 진입 주체가 수신자 상세뿐이 되는지 같이 봅니다.
ReceiverListScreen.kt:21 KDoc.

#1962 가 먼저 머지된 뒤라면 같은 네 자리가 SettingNavHost.kt 와 SettingLocalNavActions.kt 로 이름만 바뀌어 있습니다. 그 시점의 최신 코드로 다시 대조할 자리입니다.

못 본 것

시안은 열지 못했습니다. 이 세션은 Figma MCP 가 미인증입니다. 본문에 건 설정 메인, 수신인 목록, 수신인 설정, 사후 전달 조건 네 노드가 09-13 이후에 바뀌었는지는 착수 시점에 다시 열어 확인해야 합니다.

PM 결정 대기 항목은 깃허브 이슈로 두지 않는다(2026-09-18 결정). 이 이슈의 질문은 2026-07-12 회의록에 답이 있어 피그마 질문에서 뺐다: 사후 전달 조건은 설정 메인 바로가기가 아니라 수신자 목록에서 수신자별로 설정한다(회의록 https://www.notion.so/39b09829378780e3b599e5c05c2965de, 기획 문서 「사후 관리」와 같은 방향). 회의록 표현이 확정문이 아니라 구현 이슈는 아직 만들지 않았다.

Navigation Menu

Repository navigation

설정 사후 전달 조건 메뉴의 최종 진입 경로 확정 #1998

작업 유형

주 담당 모듈

개요

확인된 현재 상태

추가 확인한 기획 근거

PM에게 필요한 결정

범위와 재개 조건

완료 조건

참고

실측: #1962 는 그 분기를 동작 그대로 옮겼다

분기 본체

플래그와 진입 액션

그래서 완료 조건 2번의 실측 답

이 이슈 하나가 설정 계열 스택 전체를 세우고 있다

기다리는 답변

막혀 있는 사슬

답변이 오면 풀리는 순서

사슬 안에서 구현이 끝나 머지만 기다리는 이슈

답변 내용별로 손댈 자리

못 본 것

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

설정 사후 전달 조건 메뉴의 최종 진입 경로 확정 #1998

Description

작업 유형

주 담당 모듈

개요

확인된 현재 상태

추가 확인한 기획 근거

PM에게 필요한 결정

범위와 재개 조건

완료 조건

참고

Activity

OnlyReadOneBook commented on Sep 13, 2026

실측: #1962 는 그 분기를 동작 그대로 옮겼다

분기 본체

플래그와 진입 액션

그래서 완료 조건 2번의 실측 답

OnlyReadOneBook commented on Sep 13, 2026

이 이슈 하나가 설정 계열 스택 전체를 세우고 있다

기다리는 답변

막혀 있는 사슬

답변이 오면 풀리는 순서

사슬 안에서 구현이 끝나 머지만 기다리는 이슈

답변 내용별로 손댈 자리

못 본 것

OnlyReadOneBook commented on Sep 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions