refactor(core): core:ui 의 when else 가 닫힌 타입의 새 분기를 삼킨다 — 3곳 #1771

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

core — 코어

개요

core:ui 의 when 세 곳이 자기 모듈이 정의한 닫힌 타입을 분기하면서 else 로 닫는다. 타입에 항목을 더해도 컴파일이 깨지지 않고, 새 항목은 조용히 기본값으로 흘러간다.

Kotlin 2.4.10 은 닫힌 타입을 subject 로 하는 when 의 분기 누락을 컴파일 에러로 잡는다. else 를 떼는 것만으로 안전망이 생기고, 두 타입 모두 하위가 적어 열거 비용이 거의 없다.

기준 리비전: c4ede8342

대상 3곳

AfternoteButton.kt:89 는 같은 파일 안에서도 어긋나 있다. 바로 위 containerColor 는 같은 enum 다섯 항목을 모두 적어 else 가 없는데, 아래 contentColor 만 else 로 닫혀 있다. 버튼 타입을 더하면 배경색은 컴파일 에러로 잡히고 글자색은 조용히 흰색이 된다.

완료 조건

• 세 곳에서 else 를 없애고 남은 항목을 이름으로 적는다
• 결과값은 그대로다. else 가 주던 값을 각 항목이 그대로 받는다
• :core:ui:compileDebugKotlin · :core:ui:testDebugUnitTest · validateDebugScreenshotTest · ktlintCheck · :konsist:test 통과

참고

• 저장소 전체를 훑은 결과 중 내 담당 모듈 몫이다. 남의 담당 몫은 refactor(mindrecord): when 의 else 가 닫힌 타입의 새 분기를 삼킨다 — 5곳 #1765(마음의 기록) · refactor(timeletter): 미디어 MIME 검증의 else 가 미처리 블록 타입을 「지원 0건」으로 바꿔 던진다 #1766(타임레터) · refactor(home): 수신자 홈 내려받기 상태 when 의 else 가 새 상태를 조용히 삼킨다 #1767(수신자 홈) 으로 갈라 냈다.
• 같은 조사에서 애프터노트·온보딩의 세 곳도 걸렸지만 else 를 뗄 수 없는 자리다. subject 가 Throwable 이라 닫혀 있지 않고, 이미 sealed 루트로 좁힌 안쪽 when 이 exhaustive 하다(toAfternoteEditorError · shouldReportInReceiverFlow · 구글 로그인 실패 매핑). 손대지 않는다.
• AfternoteEditorRoute 의 오류 채널 분기는 이 범위에서 뺐다. 「검증 실패는 팝업, 그 외는 스낵바」가 주석에 적힌 의도된 정책이고, 승인 대기 중인 fix(afternote): 발신 흐름의 무음 실패에 복구 수단과 진행 상태를 결선한다 (#705) #1608 이 같은 파일을 만지고 있다. fix(afternote): 발신 흐름의 무음 실패에 복구 수단과 진행 상태를 결선한다 (#705) #1608 머지 뒤에 따로 판단한다.