[OnlyReadOneBook]

Closes #1514

한 모듈 안에서 작성자와 수신자가 서로 다른 규칙을 쓰고 있었다. 수신자는 Route·Screen·VM·UiState·매퍼가 기능 폴더에 모여 있는데, 작성자는 조립부만 author/navigation/ 에 따로 있어 상세 화면 하나를 고치려면 두 폴더를 오갔다.

이름도 내용과 달랐다 — author/navigation/ 의 9파일 중 NavGraphBuilder 확장을 가진 것은 2개뿐이고, 나머지 6개는 「NavGraph」라는 이름을 단 화면 조립부였다.

이동

현재	이동 후
AfternoteNavGraphDetail.kt	author/detail/AfternoteDetailRoute.kt
AfternoteNavGraphHome.kt	author/home/AfternoteHomeRoute.kt
AfternoteNavGraphEditor.kt	author/editor/AfternoteEditorRoute.kt (+ 헬퍼 4종은 AfternoteEditorRouteHelpers.kt)
AfternoteNavGraphAddSong.kt	author/editor/memorial/playlist/AddSongRoute.kt
AfternoteNavGraphSelectReceiver.kt	author/editor/receiver/select/SelectReceiverRoute.kt
AfternoteNavGraphFingerprint.kt	shared/fingerprint/FingerprintLoginRoute.kt

공용 컴포넌트 DetailLoadErrorContent·DesignPendingDetailContent 는 shared/detail/DetailStateContents.kt 로 올렸다 — 수신자 화면 2곳이 쓰는 자원이 작성자의 내비게이션 폴더에 얹혀 있었다.

author/navigation/ 에는 진짜 NavGraph 2개(AfternoteNavGraph·AfternoteNavGraphTheme)와 model/, AfternoteNavActions.kt 만 남는다. 이슈 작업 범위 3번 그대로다 — AfternoteNavActions 는 NavGraphBuilder 확장이 아니지만 내비 액션 홀더라 이 폴더가 제자리다.

함께 옮긴 것

스크린샷 골든. 골든은 패키지 경로에 저장되므로 두 screenshotTest 와 골든 디렉터리를 같이 옮겼다.

• DeleteInProgressOverlayScreenshotTest → author/detail
• DetailLoadErrorContentScreenshotTest → shared/detail (컴포넌트를 따라간다)

파일명은 그대로다. 이름의 해시(748aa731)는 렌더 설정 기반이라 모듈·패키지를 가로질러 반복된다(저장소 전체 골든 175건 중 142건이 같은 값) — 골든 재생성이 필요 없다. screenshot-baseline 라벨도 필요 없다.

MemorialVideoLauncherTest 는 launchMemorialVideo 를 따라 author/detail 로 옮겼다.

검증

• :feature:afternote:presentation:compileDebugKotlin · compileDebugUnitTestKotlin · compileDebugScreenshotTestKotlin · :app:compileDebugKotlin · :app:compileDebugUnitTestKotlin → BUILD SUCCESSFUL
• :feature:afternote:presentation:testDebugUnitTest → 177 tests / 0 failures
• :feature:afternote:presentation:ktlintCheck → BUILD SUCCESSFUL (exit code 직접 확인 — 파이프로 삼키지 않았다)
• 완료 조건 실측 — author/navigation/ 잔여 3파일 중 NavGraphBuilder 를 가진 것 2개 + 액션 홀더 1개 / 수신자 화면(receiver/detail/ReceivedAfternoteDetailRoute.kt)의 author.navigation import 0건

리뷰어에게

• receiver/navigation/ReceivedAfternoteNavGraph.kt 는 author.navigation.afternoteComposable 을 계속 import 한다. 그건 진짜 NavGraphBuilder 확장 공용 헬퍼라 이슈가 「남긴다」고 지정한 2개 중 하나다. 완료 조건이 말한 「수신자 화면」은 위에서 0건이 됐다.
• refactor(core): 추모 영상 실행 가드를 core:common 한 벌로 승격한다 (#1436) #1522(refactor(core): 추모 영상 실행 가드가 발신자·수신자 2벌 — 37줄 문자 단위 동일본을 core:common 으로 승격 #1436, 추모 영상 가드 core:common 승격)가 같은 파일(AfternoteNavGraphDetail.kt)을 건드린다. 먼저 머지되는 쪽에 맞춰 이쪽을 rebase 하겠다 — 양쪽 다 그 파일의 서로 다른 구간이라 충돌은 기계적이다.

CI Test Plan

{
  "androidTest": {
    "mode": "selected",
    "reason": "author/navigation 아래 조립부 파일을 옮겨 규칙상 selected 가 필요하다. 이동으로 깨질 수 있는 것은 «어느 Route 가 어느 목적지에 붙는가» 이므로 목적지 라우팅을 실기기에서 확인하는 계측 테스트 4건을 고른다. androidTest 소스는 건드리지 않았다.",
    "tests": [
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/AppAndReceiverCompletionAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.ReceiverRuntimeCompletionAndroidTest#homeActions_routeImplementedEntryPointsToExactDestinations",
        "device": "api30"
      },
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/AppAndReceiverCompletionAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.ReceiverRuntimeCompletionAndroidTest#receivedGalleryDetail_routesGalleryContractInsteadOfSocialCredentials",
        "device": "api30"
      },
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/AppAndReceiverCompletionAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.ReceiverRuntimeCompletionAndroidTest#receivedMemorialDetail_routesPlaylistContractAndForwardsExactId",
        "device": "api30"
      },
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/AppAndReceiverCompletionAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.AppAndReceiverCompletionAndroidTest#welcomeCheckRecords_opensActualReceivedRecordsStartDestination",
        "device": "api30"
      }
    ]
  }
}

[github-actions]

이 PR 은 develop 와 충돌 상태이고, 그래서 CI 가 돌지 않는다.

pull_request 워크플로는 base 와 head 를 합친 가상 머지 커밋(refs/pull/<N>/merge)에서
실행되는데, 충돌이면 GitHub 이 그 ref 를 만들지 못해 워크플로가 트리거조차 되지 않는다.
체크가 실패하는 것이 아니라 아예 생성되지 않으므로, 새 커밋을 올려도 no checks reported
인 채 최신 커밋이 한 번도 검증되지 않은 상태로 남는다 (#1028).

develop 를 병합해 충돌을 풀면 검증이 다시 돈다. 해소되면 이 라벨은 자동으로 떨어진다.