#1592 Phase 1 — 입력·탐색·편집·저장 경로 대상표
작성: 2026-09-14. 담당: /root/input_inventory. 조사 checkout: C:/Users/USER/Documents/Codex/2026-09-14/new-chat-4/work/app1592, 계약 checkout: 같은 work의 docs1592.
최종 목표는 모바일·PC 전체에서 입력 직후 의미 있는 반응, 데이터에 독립적인 탐색·닫기, 필수 데이터가 모두 준비된 영역의 일괄 공개, 지연·실패에서 끝나는 대기 상태다. 아래는 정적 소스 추적 결과이며 실제 화면 지연 시간·페인트 순서는 측정하지 않았다. await의 존재를 지연 결함으로 단정하지 않고 그 이전에 게시되는 표시 상태와 소비 경계를 함께 확인했다. 제품 코드·설정·원격 상태를 변경하거나 테스트를 실행하지 않았다.
읽은 지침: 앱·문서 최상위 AGENTS.md, 전역 설계·작업 원칙, docs/contracts/navigation-stack.md, completed-workout-write-pipeline.md, completed-session-write-source.md, feature-loading.md, session-screen-props.md. 리포트 상태·통계 코어는 주 담당자의 조사 범위다. 그룹/피드 등 모바일 전용 기능을 PC 미구현 결함으로 간주하지 않는다. 신규 기능·디자인 재설계는 범위 밖이다.
읽는 법
즉시 상태 있음: 비동기 작업 이전에 표시에 쓰이는 상태를 변경한다. 실제 페인트 지연 없음/최종 성능 합격을 뜻하지 않는다.빈틈 확인: 소스에서 준비 상태/완료 조건이 UI에 연결되지 않은 것을 확인했다. 사용자가 보고한 실제 지연의 원인이라는 확정은 아니다.추가 검증: 소스만으로 최종 공개 조건이나 실제 페인트 보장을 판정할 수 없다.- 파일 경로는 별도 표기가 없으면 앱 checkout 기준이다.
대상표
| ID·범위·동작 | 추적한 소스·함수 | 현재 즉시 반응·기다릴 대상 | 판정과 최소 구조 변경 | 기존 검사·추가할 실제 동작 검사 |
|---|---|---|---|---|
| N01 모바일 하단 탭/같은 탭 재선택 | appController.tsx:611 selectDashboardTab, features/navigation/MobileTabsRegion.tsx:23, controllers/navigationStore.ts:setTab/unwindAll | entry intent 취소→stack unwind→tab을 동기 변경. pressedTab은 즉시 탭바에, useDeferredValue는 무거운 pane 전환에 적용. 화면 코드·조회는 이후 준비 | 즉시 상태 있음. 기존 입력/pane 분리 유지. 데이터 지연 중에도 목표 탭 제목·fallback이 나타나는지 검증하고 미방문 pane의 boundary에 공통 준비 상태 연결 | navigationStore, navigationStack은 동기 상태·history·same-tab 보장. U05는 chunk 실패/뒤로 검증. 데이터 응답을 붙잡은 실제 클릭→강조/제목/닫기 페인트 검사 추가 |
| N02 PC 사이드바·홈 날짜/주간 이동 | features/navigation/desktopNavigation.tsx:20 desktopOnTab, openDesktopCalendarDate/openDesktopCalendarWeek, desktopApp.tsx:31 | 선택 상세/PR 상태 정리 후 즉시 tab/date/week 변경. 첫 방문 binding mount, 재방문 유지. 상위 Suspense가 본문 fallback 표시 | 즉시 상태 있음. 모바일과 같은 paint/complete 지표 필요. PC는 별도 deferred pane 구조가 없으므로 동기 렌더 부하 실측 후 판단 | featureLoadingGraph, U05. PC 첫 방문/재방문·느린 청크·느린 조회 각각 navigation 가용성 추가 |
| N03 모바일 메뉴 열기·닫기·메뉴 행 | appController.tsx:605 openDrawer/closeDrawer, pickDrawerTab, features/navigation/mobileNavigationBindings.tsx:MobileNavDrawerBinding | drawer state/history 즉시 변경. profile은 현재 props. 메뉴 행은 N01 공통 경로 | 즉시 상태 있음. 새 로더를 메뉴 열기 선행 조건으로 넣지 않음 | navigationStore drawer mirror, navigationStack 메뉴 아래 상세 정리. 조회 중 열기/닫기 실 브라우저 검사 |
| N04 모바일 드로워 도구 화면 | features/navigation/MobileDrawerBinding.tsx:23 openRecordsToolFromDrawer, MobileStackBindings.tsx:MobileRecordsToolOverlay | stack 정리/push 후 loadOwnCustomExercises, loadPrToolsData, manual 두 조회 발화. lazy 코드는 UiTabSkeleton fallback | 입력 상태 있음. 도구 코드가 아직 없을 때 fallback에 뒤로 affordance가 있는지 추가 검증. 데이터 준비 게이트는 도구별로 다름(T01 참조) | navigation registry/history 검사는 존재. 첫 방문 chunk hold와 data hold를 분리해 닫기·완성 공개 검사 |
| N05 모바일 depth back/OS back/swipe | controllers/navigationStore.ts:requestPop/finishPop/unwindAll, ui/mobile/lib/StackScreen.tsx:startBack, features/navigation/TabStackProvider.tsx | requestPop은 closing 동기 게시, animation end에서 finish. OS back은 같은 store. 데이터 완료 await 없음. exit fallback은 애니 유실 회수용 | 즉시 상태 있음. 새 준비 화면도 동일 stack/ID/owner guard에 연결하고 별도 history/state를 만들지 않음 | navigationStack, navigationStackNativeBack, registry. 모든 새 준비 surface에서 loading 중 4경로 back·늦은 응답 재열림 방지 |
| N06 모바일/PC 신규 운동·복귀 | features/active-workout/activeWorkoutEntryBinding.ts:160 startFreshActiveWorkout, resumeActiveWorkout, MobileWorkoutBinding.tsx:40 | snapshot/intent/layer를 먼저 설정. PC 선택 계획만 뒤에서 hydrate. 복귀는 intent/layer 즉시 변경. lazy workout은 skeleton | 즉시 상태 있음. 편집기 코드/카탈로그 준비를 navigation과 분리 유지 | activeWorkoutEntryPolicy, desktopWorkoutEntryContract, U05 입력 보존. 느린 catalog/chunk 중 시작·복귀/이탈 검사 |
| N07 모바일/PC 기존 세션으로 운동 시작 | activeWorkoutEntryBinding.ts:209 startSession, workoutSourceEntryBinding.ts:68 startActiveWorkoutFromSession | ensureCanonicalSessionDetail 후 snapshot/intent/layer 설정. 그 전 intent coordinator는 revision만 증가. 조회 함수의 label은 모바일 상단 안내만 표시 가능 | 빈틈 확인: 목표 운동 셸은 상세 응답 뒤에 열림. 기존 latest/owner guard를 보존한 준비 intent를 게시하고, 취소 가능한 운동 셸+본문 skeleton을 먼저 표시. 안전한 상세 하나로 draft 만든 뒤 교체 | 기존 정책·copy/source 검사는 있으나 이 진입 await 동안 목표 셸/뒤로가기를 검사하는 근거는 확인 못함. 양 플랫폼 detail hold→close→late reply·A/B 진입 경쟁 검사 |
| N08 모바일 그룹 보드로 운동 시작 | features/group/useMobileGroupStart.ts:41 onGroupBoardStart, workoutSourceEntryBinding.ts:startActiveWorkoutFromPrefill | catalog await→누락 커스텀 자동 등록 await→prefill 만들기→start. await 이전 표시 pending/intent가 없다 | 빈틈 확인. 그룹 시작 준비 작업을 공통 workout entry 수명에 연결. 사용자 입력 직후 목표 셸, catalog/필수 등록 완료 후 draft 공개. 취소/owner/date 변경 뒤 시작 금지 필요. 커스텀 등록 자체는 승인된 기존 의미 유지 | groupBoardPercentPrefill, groupBoardCustomRegister, composite roundtrip. catalog와 등록 응답 각각 hold·실패·닫기·다른 보드 선택 검사 |
| C01 모바일 일지 월 이동/오늘 | features/calendar/MobileCalendarBinding.tsx:onChangeMonth/onGoToday, ui/mobile/screens/SessionScreen.tsx | date/month 동기 변경. 화면 pending={!calendarHasVisibleMonth}. 월 navigation 버튼은 조회 await 없음 | 즉시 상태 있음. 달력 markers/summary가 새 월의 완성 데이터인지 주 담당자의 readiness와 연결 필요 | calendarMonthLoadSignal, calendarReadModelStore/resources, projection. 연속 월 이동·실패와 cached/invalidated 월의 공개 검사 |
| C02 모바일 일지 날짜/주/월 상세 | SessionScreen.tsx:227 onSelectDate+openDay, :296 UiDayOverlay; MobileCalendarBinding.tsx:selectedDateSessions, MobileCalendarJournalProvider | 선택/push 즉시, 이후 day/range hydrate. 날짜 title/prev/next/back은 바로 표시. UiDayOverlay는 받은 body를 바로 그림 | 빈틈 확인: 자체 일지 day 경로에 loading/error/readiness prop이 전달되지 않음. `sessions | |
| C03 모바일 홈 날짜 상세 | features/home/MobileHomeBinding.tsx:requestHomeDay/closeHomeDay | selected day와 {date,status:loading} 먼저 설정→force day details. request revision으로 최신 응답만 ready/error. close가 revision 무효화 | 즉시 상태 있음. 이미 명시적 loading/error/retry/close가 있으므로 공통 contract에 흡수하되 의미 유지 | 홈 관련 readiness 검사는 주 담당자 범위. 실제 day request 실패/재시도/close 후 late response 검사 |
| C04 PC 홈 날짜 모달 | features/home/DesktopHomeBinding.tsx:requestDesktopHomeDay, controllers/homeDayDetailCoordinator.ts | coordinator onStart가 즉시 modal loading을 설정. onComplete/onError가 최신 date에만 적용. close/cancel/owner/tab 변경 무효화 | 즉시 상태 있음. 본문 로딩은 현재 text/overlay를 skeleton 영역으로 통일 가능 | homeDayDetailCoordinator 성공·A/B·닫기·재시도. 실제 DOM의 title/back과 완성 본문 동시 공개 검사 |
| C05 PC 일지 날짜/주/월·세션 선택 | features/calendar/DesktopCalendarBinding.tsx:onSelectDate, ui/desktop/screens/DesktopSessionScreen.tsx:selectDate/selectWeek/selectMonth/toggleSession; DesktopSessionDetailParts.tsx:DkJDayPanel | 날짜/상세 선택 동기. day 조회도 별도 상태. session pending ID만 있어도 모달/X 표시, 본문은 loading overlay | 즉시 상태 있음. toggleSession는 닫기를 loading guard보다 먼저 처리. spinner/text를 완성 영역 skeleton contract로 연결 | 날짜/계획 계약 검사+session detail store. 실제 PC 날짜 이동 중 X·동일 항목 재클릭·다른 세션 선택과 dirty day data 검사 |
| S01 모바일/PC 완료 세션 상세 열기 | controllers/sessionDetailStore.ts:166 openCompletedWorkoutDetail, features/session/MobileSessionOverlayBinding.tsx, ui/mobile/lib/StackSessionOverlay.tsx | selected=null·pendingId·tab/layer를 먼저 게시→detail 조회→current request+owner 확인→full 변환→선택 공개. PC도 pending 모달 | 즉시 상태 있음. 안전한 data-ready 경계의 기준 사례. 실패는 모바일 stack을 유지하며 selected=null/pending=null이 되어 skeleton이 계속 남을 수 있음: error/not-found를 별도 view로 전달하거나 일관된 닫기 처리 필요 | sessionDetailStore 동기 pending·A/B·실패·OCC·owner. 모바일 error DOM/무한 skeleton 종료와 retry/닫기 추가 |
| S02 모바일/PC 계획 세션 상세 열기 | sessionDetailStore.ts:268 openPlannedWorkoutDetail; 모바일 StackSessionOverlay.tsx vs PC DesktopSessionDetailParts.tsx:607 | summary를 selectedSession에 먼저 넣고 needsDetail이면 pendingId 설정 후 load. PC는 pendingId로 본문 가림. 모바일은 session truthy만으로 본문 그림 | 모바일 빈틈 확인: 상세 준비 중 summary가 본문으로 공개됨. 모바일에 pending/error 전달하고 PC와 같은 full-ready 조건 적용. 실패를 성공 빈 상태로 만들지 않음 | dispatch·계획 자원 검사. 모바일 planned summary fixture+held detail로 본문 미공개, PC parity, 실패 후 상태 검사 |
| E01 신규 완료 기록/신규 계획 편집 | completedWorkoutEntryBinding.ts:120 create branch, workout-plan/planEntryBinding.ts:86 create branch | create intent를 바로 설정. PC editor request/calendar 이동, 모바일 runtime intent/layer. 데이터 await 없음 | 즉시 상태 있음. 코드와 picker/catalog 준비 영역만 가림. 편집 form 입력·close를 catalog query와 결합하지 않음 | desktop entry marker/편집기 모델 검사는 존재. cold chunk/catalog hold 중 form shell·닫기 검사 |
| E02 완료 세션 연필 편집 | completedWorkoutEntryBinding.ts:168 ensureSessionDetail(force:true), :187 desktop request, :220 mobile intent/layer; app.tsx:205 | force 상세 await 후 편집기 state를 설정. 모바일 상단 DataLoadingOverlay는 먼저 표시 가능하지만 목표 editor skeleton은 없음. PC는 해당 전역 overlay를 표시하지 않음 | 빈틈 확인. 준비/ready/error/cancel의 entry 상태를 기존 intent coordinator와 결합. forced detail 1개에서 revision/children를 만들기 전 editable body 공개 금지. 이전 source를 섞는 낙관 편집으로 해결 금지 | completedWorkoutEditCutover는 offline 전용 gate 부재 검사, write-source/OCC 검사. 실제 force query 보류 중 목표 editor/back·owner 바뀜·late result 검사 추가 |
| E03 계획 연필 편집 | planEntryBinding.ts:124 ensurePlannedSessionDetail(force:true), :143 desktop request, :155 startPlanEdit | read-only guard 후 force 상세를 기다리고 editor open. pending entry UI는 없음 | 빈틈 확인. E02와 공통 준비 entry. 서버 read-only 판정 전 입력 body는 가림. 권한/원본 의미는 유지 | plannedSessionRevisionContract, workoutPlanCommands, plan model/parity. held read-only 결과·실패·다른 entry/close race 검사 |
| W01 완료 기록 저장/완료 자동 저장 | controllers/workoutWriteController.ts:1240 setSaving, features/active-workout/mobileWorkoutFlow.ts:143 autoSave, ui/desktop/screens/DesktopPlanEditor.tsx:201 attemptSave | saving/autoSave pending/planSavePending를 await 전에 게시. 생성 wait, 수정 immediate는 durable queue/receipt 정책에 따라 기존 동작 유지 | 입력 상태 있음. saving 완료와 통계·상세 공개 준비는 별도 계약. draft 작성→IDB durable→receipt→read-model generation 각각 식별. 현재 sender 10초/queued/offline 의미 유지 | completed save/edit/delete cutover, receipt, pending resources. 실제 IDB·RPC 지연에 저장 버튼 즉시 상태, local durable 이전 성공 없음, 통계 부분 공개 없음 추가 |
| W02 세션 시간 수정/삭제 | ui/mobile/lib/SessionSheetBody.tsx:62 runDelete, :317 time save; controllers/workoutWriteController.ts:updateUiSession/deleteUiSession | 삭제 확인은 즉시 busy/삭제 중, durable 결과 뒤 닫힘. 시간 picker는 callback 발화 후 즉시 닫음; 데이터 update는 기존 파이프라인 | 반응 있음. 시간 수정 직후 영향을 받는 본문은 pending receipt/최신 revision에 맞춰 공개. 사용자 데이터/큐 정책 변경 불필요 | completed edit/delete cutover, OCC·pending freshness. 실제 화면에서 이전 시간/집계 공개 금지 및 실패/queued 안내의 명확성 검사 |
| W03 계획 저장/편집기 내부 변경/닫기 | mobileWorkoutFlow.ts:savePlan, DesktopPlanEditor.tsx:attemptSave, DesktopSessionScreen.tsx:closeCompose, activeWorkoutEntryBinding.ts:exitPlan | 제목·종목·세트 입력은 reducer/local state. 저장 busy 먼저 표시. 모바일 exit는 동기 state/history. PC compose.saving 동안 close가 무시되는 정책 존재 | 대부분 반응 상태 있음. PC 저장 중 닫기 차단은 실제 저장/추가 입력 수명 안전과 결합돼 있으므로 허용되는 이탈·보관 범위를 문서로 정하고 silent no-op 없게 처리. 단순 disabled 제거 금지 | plan editor model/parity, A12 저장 중 입력 보존. save hold 중 새 입력 보존·닫기/탭 이동·late reply 검사 |
| G01 모바일 그룹 목록→라운지→보드→날짜 | features/group/groupStore.ts:408 openGroup/openBoard/openGroupBoard/selectBoardDate/closeBoard/closeLounge | view/target 먼저 게시→resource 로드. close는 abort/state 후 optional 배경 refresh. board 본체와 day sessions 별도 요청 | 즉시 상태 있음. board와 day sessions가 함께 공개할 묶음인지 정의하고 ready 판단을 합침. 날짜/그룹 변경의 resource key/abort 유지 | groupResourceLifecycle, groupInteractionsStore, groupBoardDateNav. board RPC 하나만 완료했을 때 부분 본문/빈 운동이 공개되지 않는지 실제 DOM 검사 |
| G02 그룹 세션·작성/생성/초대/설정 | groupStore.ts:455 openDoneSession, runWrite, saveSettings, createGroup/saveBoard/sendInvites; features/group/MobileGroupBinding.tsx | detailTarget/emit 먼저; sheets/composer는 UI state. writePending를 API 전에 set. board 저장은 write 뒤 composer 닫기+reload | 입력 상태 있음. 데이터 공개는 resource별 readiness를 UI로 전달. 별도 reader가 늦는 동안 새 성공 내용으로 교체했다 다시 바뀌지 않는지 검사 | group lifecycle/continuity/date/input limits. 각 request hold 상태에서 shell/close·완료 묶음 공개·실패 종료 검사 |
| F01 친구 페이지·내부 탭·일지/세션 | features/social/friendScopeStore.ts:open/go/loadDay/openSession/close, MobileFeedBinding.tsx:openFeedFriend | friend/tab/sessionId를 먼저 게시, load는 뒤에서. slice별 abort/latest owner. day는 월 목록→해당 session detail 모두 await | 즉시 상태 있음. friends day의 error 재시도 surface가 없다는 기존 테스트가 있으므로 failure 구분을 공통 본문에 전달. 선택/닫기는 resource 완료와 무관하게 유지 | friendScopeStore 방문·재진입·A/B·닫기·owner·월 경계·실패. 실제 screen에서 준비 중 통계/빈 day 공개 금지 |
| F02 피드 좋아요·댓글 열기/작성/삭제 | features/social/feedSocialStore.ts:toggleLike/openComments/submitComment/removeComment/closeComments | 좋아요 optimistic overlay 동기, 댓글 sheet 동기; submitting/deletingId 먼저 게시. RPC 실패 rollback/error, owner/visit fence | 입력 상태 있음. 기존 optimistic 좋아요 의미를 skeleton 정책 때문에 없애지 않음. 댓글 목록의 current data/invalidated state 공개 조건 검토 | feedSocialStore optimistic/rollback·sheet race·owner·close. held comment list + cached invalidation·submit/delete 버튼 상태 실제 DOM 검사 |
| F03 신고 메뉴·신고/차단·차단 목록 | features/social/moderationStore.ts:openMenu/openReport/openBlockedList/closeBlockedList/unblockUser | menu/report/list state 동기. list 조회 전에 set, close abort. submit/unblock pending으로 현재 작업 식별 | 입력 상태 있음. 목록 코드/data별 skeleton 및 오류 종료 공통화; 권한·사용자 차단 의미 유지 | moderationStore 실패·close/late·owner. actual list skeleton/close 확인 |
| F04 알림 열기·대상 이동·더보기/읽음 | ui/mobile/lib/BrandRow.tsx:39 toggle, features/group/MobileNotificationShellBinding.tsx:onPick, notificationTargetStore.ts:open, notificationStore.ts:markRead | popover local open, 대상 tab 먼저 이동 후 target load. detail+social Promise.all 후 post 공개. 더보기 pending. markRead/readAll은 API 뒤 readIds emit이며 별도 pending state 없음 | 대상 이동은 즉시 상태 있음. 읽음 버튼은 현재 응답 피드백 부족 가능: 최소 readPending 표시/중복 정책 필요. target view는 loading/error 표시 유지 | group resource lifecycle/notification 관련 검사. held readAll 및 target detail/social 각각 지연·fail·close 후 late 검사 |
| P01 모바일 내 정보 텍스트/신체 변경 | ui/mobile/screens/ProfileScreen.tsx:ProfTextModal/ProfBodyModal, features/profile/profileFeatureBinding.ts:saveProfile* | 모달 local open, save 전에 saving; saved 응답 없으면 실패/입력 유지. body 변경 후 standards refresh는 callback 완료에 포함 | 입력 상태 있음. 프로필 확정과 영향 받은 PR/통계 준비의 공개를 구별. 저장 중 cancel disabled는 W03과 같은 명시적 이탈 정책 확인 | profile resource/design/sex/handle tests. 실제 form response hold·실패·owner·후처리 지연 검사 |
| P02 PC 내 정보 handle/성별 변경 | ui/desktop/screens/DesktopProfileScreen.tsx:150 handle save, :163 sex; profileFeatureBinding.ts:104/154 | UI onClick이 callback만 호출. handle/sex API await 이전 UI pending/toast 없음. body metrics는 binding이 저장 중 toast를 먼저 게시 | 빈틈 확인: handle/sex의 대기 피드백 없음. 작은 field별 mutation pending 상태를 UI에 연결, 선택은 draft/current 분리. 서버 확정 전 저장 성공을 표시하지 않음 | profile handle/sex/resource는 data 의미 중심. PC 실제 click/held mutation의 pending·중복·실패 복구 검사 |
| T01 나의 주요 종목·1RM 직접 입력·커스텀/회복 도구 | features/pr/MobileRecordsToolsBinding.tsx, ui/mobile/screens/PrTools.tsx, features/pr/manualRecordsBinding.ts | 도구 shell 즉시. favorites/manual 화면에는 data pending/error prop이 없음. manual list는 empty array면 ‘아직 없음’; save는 local saving 후 서버→목록→home→PR/detail refresh까지 await. custom은 loading/error/pending props 존재. recovery는 panel view model | 빈틈 확인: manual 두 조회 및 도구 catalog 준비를 완성 빈 상태와 구분하지 않음. 리스트/검색 준비 gate 추가, manual 저장 완료와 영향 영역의 준비를 분리해 사용자 대기를 줄임. 숫자 정책은 주 담당자와 연결 | manual record/favorite/custom/recovery 관련 검사는 소스 목록 추가 확인 필요. cold tool data hold, 두 목록 중 하나 늦음, save 후 refresh 지연·실패 검사 |
| Q01 검색 입력/종목 선택/초기 세션 검색 | controllers/searchController.ts:usePrExerciseSearchController/createSearchQueryCoordinator, features/search/MobileSetSearchBinding.tsx, DesktopSearchBinding.tsx | 입력 state 즉시, 실제 query는 220ms debounce/IME 후 commit, pending 따로 표시. 종목 pick은 local selection 즉시. session data loading은 selection/view prop | 입력 상태 있음. 입력 echo는 debounce하지 않음. 현재 결과가 어느 query/exercise/generation 소속인지 complete view와 결합 | search/exercise test군·loading graph. IME·빠른 입력·clear·이전 query 응답·초기 empty vs pending 실 UI 검사 |
| X01 법률/서비스 정보 열기·내보내기/가져오기 | appController.tsx:920 openLegalDocument/openServiceInformation/closeLegalDocument, app.tsx:73 legalDocumentOverlay, profileFeatureBinding.ts:exportUiData/importInbodyFile | legal path/layer 즉시. InBody는 파일 확인 중 toast 먼저. export는 API await 후 파일/공유 처리, 그 전 표시 상태는 이 함수에 없음 | legal 즉시 state 있음, 문서 내부 load skeleton은 추가 확인. export에 대기 피드백 전달 필요 가능: 호출 UI 포함하여 확인 후 공통 작업 상태 연결. import 작업 원본·서버 의미/와드업 제외 정책 보존 | profileDocumentLifecycle, import resource 검사. 실제 file read/export hold·실패·닫기/owner 검증 필요 |
우선 구현할 공통 구조와 경계
- 기존 입력 intent에 준비 상태를 연결한다. E02/E03/N07/N08은 새 coordinator를 또 만들기보다
workoutEntryIntent의 latest/owner 수명과 동일한 요청 ID로preparing → ready/error/cancelled를 노출한다. 목표 editor/workout의 셸과 취소가 준비 전에 존재하고, 데이터에 쓰기 권한을 부여할 본문은 canonical detail/catalog가 준비된 뒤에만 만든다. source card/신규 revision을 합성해 성급히 편집 가능하게 만드는 대안은 쓰기 원천 계약을 깨므로 기각한다. - 실제 공개 상태를 UI props로 보낸다.
session !== null,items.length,loading RPC 하나가 끝남은 완료 조건이 아니다. 먼저 모바일 session/day/tools의 pending/error 누락을 메우고, source/generation/readiness가 일치한 완성 view를 넘긴다. 서버 무효화와 통계 generation의 본체는 주 담당자 영역이다. - 코드 준비 shell과 data body를 분리한다. 기존 lazy/FeatureLoadBoundary/visited panes를 보존하며, lazy 실패/대기 중에도 navigation/닫기 가능한 fallback인지 각 등록 화면에서 확인한다. 전체 화면 선로딩을 재도입하는 대안은 U05의 청크·입력 보존 계약 및 비용을 깨므로 기본 해결책으로 채택하지 않는다.
- mutation의 대기 상태와 성공 의미를 분리한다. 저장·삭제는 기존 IDB/outbox
immediate/wait정책을 유지한다. PC profile/read-all/export 같은 상태 누락만 실제 pending과 연결한다. 새로운 대기열/재시도/타이머로 체감 문제를 가리지 않는다. - 실제 painter 검증을 별도로 둔다. store 상태 검사는 데이터 응답 이전 state가 게시됨을 보장할 뿐 실제 1st paint/메인스레드 비용은 보장하지 않는다. 양 플랫폼 production-format 앱에서 코드 응답과 데이터 응답을 각각 보류하고 input event→의미 있는 반응→complete view를 계측해야 한다. 시간 기준은 이 보고서에서 임의 확정하지 않는다.
알려진 구체적 빈틈과 재현 상태
- 목표 편집/템플릿 시작 화면이 detail await 뒤에 열리는 E02/E03/N07: 코드로 확인. 모바일 상단 loading label은 있어 완전 무반응이라고 단정하지 않음. PC global loading label은 명시적으로 제외됨. 실제 클릭 지연은 미실측.
- 그룹 운동 시작 N08: catalog/자동 등록 전 pending 표시 없음, current entry 수명 포획도 preparation 이전에는 없음. 늦은 성공이 다른 화면에서 운동을 열 가능성은 재현 전 가설.
- 모바일 계획 상세 S02: PC는 pendingId로 body를 가리지만 모바일은 selectedSession truthy로 body 공개하는 차이를 소스로 확인. 실제 잘못된 데이터 프레임은 미재현.
- 모바일 완료 상세 실패 S01: 실패 branch가 pendingId만 내리고 stack/session view error를 전달하지 않는 구조를 확인.
UiStackSessionOverlay는 session null 동안 계속 skeleton. 실제 실패 E2E 미실행. - 모바일 일지 day C02/manual tools T01: missing/loading/error와 완성 empty를 구별할 props 연결이 없음. 실제 데이터 0→완성 변화는 미재현.
- PC profile P02 및 알림 readAll F04: mutation await 전 UI pending가 해당 소스에 없음. OS/CSS pressed styling을 의미 있는 완료 피드백으로 간주하지 않음.
현재 산출물 한계와 다음 검증 입력
이 대상표는 화면 패밀리와 대표 진입점을 실제 소스에 연결한 조사 산출물이다. DOM에 존재하는 모든 개별 버튼의 전수 실행 결과가 아니다. 리포트·통계 코어는 의도적으로 중복 조사하지 않았으며, 초대/댓글·도구·profile의 모든 하위 폼, 법률 문서 내부 로드·파일 내보내기 호출 UI는 추가 검증이 남는다. 테스트 파일 존재와 읽은 assertion을 구분했으며, 위 표에서 제시한 검사 추가 필요는 이번에 확인한 범위 기준이다.
최종 합격은 이 표와 주 담당자의 전체 화면 목록을 합쳐 각 항목에 구현 경계·실제 slow/fail/race/cancel 동작 증거·확정 성능 조건·반영 상태를 채웠을 때만 판정한다. 일부 경로의 공통 준비 셸 구현을 앱 전체 완료로 보고하지 않는다.