You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
enhancement(core): 수신자 App Link 식별자·인증 관문 계약을 공통 URI 파서에서 분리한다 #1951
#1857/PR #1859의 URI 계약 중 수신자 경로만 분리한다. 엔진 중립 파서의 공통 입력 검증은 독립적이지만, 로컬 SenderRegistry UUID를 외부 발신자 식별자로 고정하거나 로그인/수신자 본인인증 관문을 계약으로 선언하는 것은 #607/#598의 미정 권한·컨텍스트 결정에 의존한다.
분리 범위:
/received, /received/senders/{senderId}, /received/afternote/{id}의 목적지·정규 URL·ID 형식·인증 관문 및 그 계약 테스트.
PR #1859의 수신자 선언·UUID 규칙·관문·성공 계약 테스트는 실제 diff에서 제거했다(2026-09-08). #1857은 공통 파서·비수신자 6개 목적지만 소유하며 독립 완료한다. 그 이슈의 임시 blocked_by #1951은 제거한다. 이 이슈는 #1949/#1950의 계약 산출물을 계속 기다리고, 확정 후 #1859의 공통 입력 검증을 재사용한다.
카카오 초대 URI는 #944의 계약을 별도로 따르며, 현재 일반 수신자 경로 전체를 초대 구현 완료까지 묶지는 않는다.
참고
분리 원본: #1857. 사용자 요청에 따른 수신자 블로킹 범위 분리(2026-09-08). 원본의 구현 책임은 유지하며 본 이슈는 선행 계약·결정 범위만 소유한다.
이 파서를 호출하는 소비처가 아직 하나도 없다. MainActivity 인텐트 필터(#924), 알림 목적지 배선(#1111), 서버 FCM 링크 계약 모두 미착수라, 여기서 고정한 정규 URL 규칙과 거절 사유가 실제 발송 링크와 맞는지 검증할 길이 없다.
닫음 코멘트는 "파서 단독으로는 머지하지 않기로 했으니 열어 둘 이유가 없다" 입니다. #924·#1111 은 지금도 열려 있습니다. 여기서 수신자 목적지를 먼저 만들면 이틀 전 결정을 그대로 뒤집는 것이 됩니다.
4. 로컬 UUID 를 고정하면 안 되는 이유는 코드에 남아 있다
지금 /received/senders/{senderId} 를 확정하면 그 senderId 는 SenderRegistry.kt:37 의 UUID.randomUUID() 입니다. @Singleton(23) + MutableStateFlow(27) 로 프로세스 메모리에만 사는 stub 이고, ReceiverRoute.kt:41-42 KDoc 도 "로컬 식별자" 라고 못박아 두었습니다. 앱 재시작이면 사라지는 값이라 외부 링크 식별자로 쓸 수 없습니다. #1949 가 record-boxes 의 서버 식별자를 확정하는 순간 전부 다시 고쳐야 합니다.
5. 남은 것과 풀려야 할 것
열린 PR 62건의 파일 목록을 전량 확인했습니다. deeplink·App Link·NavigationTarget 경로를 건드리는 PR 은 0건입니다. 담당자나 스택 충돌 때문이 아니라, 계약 미확정과 소비처 부재로만 막혀 있습니다.
그래서 다음 착수자가 볼 것은 세 가지입니다. 첫째, 파서는 새로 쓰지 말고 origin/feat/924-app-links 에서 가져옵니다. 둘째, 이 이슈의 산출물은 #924 의 PR 단위 안에 들어가야 합니다. 링크를 눌러 화면이 열리는 데까지가 머지 단위입니다. 셋째, 서버 식별자는 #1949 가 확정하기 전에는 무엇으로도 고정하지 않습니다.
Activity
OnlyReadOneBook commentedon Sep 13, 2026
착수 전 점검: 본문이 딛고 선 PR #1859 가 닫혔다. 지금은 코드로 뗄 조각이 없다
기준 리비전은
origin/develop7d87aa3f4이고, 관계는 GraphQL 의존성으로 직접 조회했습니다(2026-09-13).1. 본문 전제 두 줄이 깨졌다
본문(2026-09-08)은 "#1857은 공통 파서·비수신자 6개 목적지만 소유하며 독립 완료한다", "확정 후 #1859의 공통 입력 검증을 재사용한다" 로 적혀 있습니다. 둘 다 지금은 성립하지 않습니다.
mergedAtnull,closedAt2026-09-11T07:08:33Z). Sadturtleman 승인(2026-09-04)까지 받은 상태였습니다.- [ ] PR #1859 병합.은 체크되지 않은 채입니다. 독립 완료가 아니라 feat(platform): App Links URI 계약·인텐트 수신·인증 후 목적지 재개 #924 로 흡수되며 닫힌 것입니다.따라서 이 이슈가 재사용하려던 "#1859의 공통 입력 검증" 은 develop 에 존재하지 않는 코드입니다.
2. develop 에는 붙일 자리가 없다. 파서는 브랜치에만 있다
origin/develop에 딥링크 코드가 0줄입니다.파서 일체는
origin/feat/924-app-links(54b322a4) 에만 있습니다. 프로덕션 5파일 311줄, 테스트 2파일 299줄입니다.core/common/.../deeplink/AfternoteAppLinkParser.ktcore/common/.../deeplink/NavigationTarget.ktcore/common/.../deeplink/AppLinkRejectionReason.ktcore/common/.../deeplink/AppLinkResolution.ktcore/common/.../deeplink/AuthGate.ktcore/common/src/test/.../deeplink/AfternoteAppLinkParserTest.ktcore/common/src/test/.../deeplink/NavigationTargetContractTest.kt이 이슈가 맡은 수신자 목적지와 거부 회귀 테스트는 #1859 위가 아니라 #924 의 PR 안에, 또는 그 뒤에 붙습니다. 지금 develop 에서 시작하면 파서부터 다시 세우게 되는데, 그건 #1859 가 이미 한 일입니다.
3. 닫은 사유가 그대로 이 이슈의 판정 근거다
#1859 드래프트 전환 코멘트에 적은 사유는 이렇습니다.
닫음 코멘트는 "파서 단독으로는 머지하지 않기로 했으니 열어 둘 이유가 없다" 입니다. #924·#1111 은 지금도 열려 있습니다. 여기서 수신자 목적지를 먼저 만들면 이틀 전 결정을 그대로 뒤집는 것이 됩니다.
4. 로컬 UUID 를 고정하면 안 되는 이유는 코드에 남아 있다
지금
/received/senders/{senderId}를 확정하면 그senderId는SenderRegistry.kt:37의UUID.randomUUID()입니다.@Singleton(23) +MutableStateFlow(27) 로 프로세스 메모리에만 사는 stub 이고,ReceiverRoute.kt:41-42KDoc 도 "로컬 식별자" 라고 못박아 두었습니다. 앱 재시작이면 사라지는 값이라 외부 링크 식별자로 쓸 수 없습니다. #1949 가 record-boxes 의 서버 식별자를 확정하는 순간 전부 다시 고쳐야 합니다.5. 남은 것과 풀려야 할 것
열린 PR 62건의 파일 목록을 전량 확인했습니다.
deeplink·App Link·NavigationTarget경로를 건드리는 PR 은 0건입니다. 담당자나 스택 충돌 때문이 아니라, 계약 미확정과 소비처 부재로만 막혀 있습니다.풀려야 하는 순서는 조회한 의존성 그대로입니다.
그래서 다음 착수자가 볼 것은 세 가지입니다. 첫째, 파서는 새로 쓰지 말고
origin/feat/924-app-links에서 가져옵니다. 둘째, 이 이슈의 산출물은 #924 의 PR 단위 안에 들어가야 합니다. 링크를 눌러 화면이 열리는 데까지가 머지 단위입니다. 셋째, 서버 식별자는 #1949 가 확정하기 전에는 무엇으로도 고정하지 않습니다.본문·라벨·상태는 그대로 둡니다.
OnlyReadOneBook commentedon Sep 19, 2026
2026-09-19 정리로 닫는다. 이 이슈의 완료 조건은 PM의 결정에 달려 있어 결정 전에는 FE 가 무엇을 만들지 쓸 수 없다. 그런 이슈는 FE 저장소에 열어 두지 않고 결정이 나면 그때 새 이슈로 다시 연다.
기다리는 결정: 기록함 권한·컨텍스트(#1949·#1950).
PM 질문은 창구가 정해지는 대로 보낸다(일혁이 목록 보관).